12024-01-29 Indu Bhagat <indu.bhagat@oracle.com> 2 3 x86: testsuite: scfi: adjust COFI testcase and gas: scfi: untraceable control flow should be a hard error 4 52024-01-29 Nick Clifton <nickc@redhat.com> 6 7 Updated French translations for GOLD and LD 8 9 LoongArch: update test cases about TLS 10 112024-01-29 GDB Administrator <gdbadmin@sourceware.org> 12 13 Automatic date update in version.in 14 152024-01-28 GDB Administrator <gdbadmin@sourceware.org> 16 17 Automatic date update in version.in 18 192024-01-27 GDB Administrator <gdbadmin@sourceware.org> 20 21 Automatic date update in version.in 22 232024-01-26 mengqinggang <mengqinggang@loongson.cn> 24 25 Backport commits 969f5c0e1 (LoongArch: gas: Add support for s9 register) and a0aa6f4ab (LoongArch: ld: Add support for TLS LE symbol with addend) to 2.42 branch. 26 272024-01-26 GDB Administrator <gdbadmin@sourceware.org> 28 29 Automatic date update in version.in 30 312024-01-25 Andrew Carlotti <andrew.carlotti@arm.com> 32 33 gas: Update NEWS 34 Groups entries by architecture, and update AArch64 content. 35 36 aarch64: Update Architecture Extensions documentation 37 Restructure the architecture extensions table, add a new table for architecture 38 version dependencies, add missing architecture extensions, and improve some 39 extension descriptions. 40 412024-01-25 mengqinggang <mengqinggang@loongson.cn> 42 43 LoongArch: gas: Start a new frag after instructions that can be relaxed 44 For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20} 45 relocations, start a new frag to get correct eh_frame Call Frame Information 46 FDE DW_CFA_advance_loc info. 47 482024-01-25 mengqinggang <mengqinggang@loongson.cn> 49 50 LoongArch: gas: Don't define LoongArch .align 51 Gcc may generate "\t.align\t%d,54525952,4\n" before commit 52 b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object 53 file, we call s_align_ptwo (-4). It result in alignment padding must be a 54 multiple of 4 if .align has second parameter. 55 56 Use default s_align_ptwo for .align. 57 582024-01-25 Xi Ruoyao <xry111@xry111.site> 59 60 LoongArch: Fix some test failures about TLS desc and TLS relaxation 61 There are two issues causing 11 test failures: 62 63 1. The TLS desc tests are matching the entire disassemble of a linked 64 executable. But if ld is configured --enable-default-hash-style=gnu 65 (note that most modern distros use this option), the layout of the 66 linked executables will be different and the immediate operands in 67 the linked executables will also be different. So we add 68 "--hash-style=both" for these tests to cancel the effect of 69 --enable-default-hash-style=gnu, like [x86_64 mark-plt tests]. 70 2. By default objdump disassemble uses [pseudo-instructions] so "addi.w" 71 is outputed as "li.w", causing mismatches in TLS relaxation tests. 72 We can turn off the pseudo-instruction usage in objdump using "-M 73 no-aliases" to fix them. 74 75 [x86_64 mark-plt tests]: 16666ccc91295d1568c5c2cb0e7600694840dfd9 76 [pseudo-instructions]: 17f9439038257b1de0c130a416a9a7645c653cb0 77 782024-01-25 mengqinggang <mengqinggang@loongson.cn> 79 80 LoongArch: Do not emit R_LARCH_RELAX for two register macros 81 For two register macros (e.g. la.local $t0, $t1, symbol) used in extreme code 82 model, do not emit R_LARCH_RELAX relocations. 83 842024-01-25 GDB Administrator <gdbadmin@sourceware.org> 85 86 Automatic date update in version.in 87 882024-01-24 Andrew Carlotti <andrew.carlotti@arm.com> 89 90 aarch64: Eliminate unused variable warnings with -DNDEBUG 91 922024-01-24 GDB Administrator <gdbadmin@sourceware.org> 93 94 Automatic date update in version.in 95 962024-01-23 Andrew Carlotti <andrew.carlotti@arm.com> 97 98 aarch64: Include +predres2 in -march=armv8.9-a 99 This matches the dependencies in the architecture, in LLVM, and even in the 100 original Binutils commit message that mistakenly included it only in armv9.4-a. 101 1022024-01-23 Xi Ruoyao <xry111@xry111.site> 103 104 [PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42 105 1062024-01-23 Jan Beulich <jbeulich@suse.com> 107 108 x86/APX: also amend the PUSH2/POP2 testcase 109 Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be 110 encoded") took care of only half of the remaining issue. Add #pass here 111 as well. 112 1132024-01-23 GDB Administrator <gdbadmin@sourceware.org> 114 115 Automatic date update in version.in 116 1172024-01-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 118 119 Fix 31252 gprofng causes testsuite parallel jobs fail 120 Before running our tests, we made a fake installation into ./tmpdir. 121 This installation changes libopcodes.la in the build area. 122 Gas testing may fail if gas and gprofng tests are run in parallel. 123 124 I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH, 125 GPROFNG_SYSCONFDIR are set. 126 putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create 127 directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used 128 to set up LD_PRELOAD). 129 130 gprofng/ChangeLog 131 2024-01-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 132 133 PR gprofng/31252 134 PR gprofng/30808 135 * src/envsets.cc (putenv_libcollector_ld_misc): Use 136 $GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH. 137 * testsuite/config/default.exp: Create a script to run gprofng. 138 * testsuite/lib/display-lib.exp: Fix typo. 139 1402024-01-22 Nick Clifton <nickc@redhat.com> 141 142 Updated Serbian translations for th bfd, gold and opcodes directories 143 1442024-01-22 GDB Administrator <gdbadmin@sourceware.org> 145 146 Automatic date update in version.in 147 1482024-01-21 GDB Administrator <gdbadmin@sourceware.org> 149 150 Automatic date update in version.in 151 1522024-01-20 GDB Administrator <gdbadmin@sourceware.org> 153 154 Automatic date update in version.in 155 1562024-01-19 H.J. Lu <hjl.tools@gmail.com> 157 158 Update x86/APX: VROUND{P,S}{S,D} can generally be encoded 159 Append "#pass" to APX tests for targets which pad text sections with NOPs. 160 161 * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Append 162 "#pass". 163 * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. 164 165 (cherry picked from commit f530d5f1bab6eb5adc65f422ef811fb278a21a4b) 166 1672024-01-19 Jan Beulich <jbeulich@suse.com> 168 169 x86/APX: VROUND{P,S}{S,D} can generally be encoded 170 VRNDSCALE{P,S}{S,D} is the AVX512 generalization of these AVX insns. As 171 long as the immediate has the top 4 bits clear, they are equivalent to 172 the earlier VEX-encoded insns, and hence can be used to permit use of 173 eGPR-s in the memory operand. Since this is the normal way of using 174 these insns, also alter the resulting diagnostic to complain about the 175 immediate, not the eGPR use. 176 177 x86/APX: be consistent with insn suffixes 178 When there's a suitably disambiguating register operand, suffixes are 179 generally omitted (unless in suffix-always mode). All NDD insns have a 180 suitable register operand, so they shouldn't have suffixes by default. 181 182 x86: support APX forms of U{RD,WR}MSR 183 This was missed in 6177c84d5edc ("Support APX GPR32 with extend evex 184 prefix"). 185 1862024-01-19 Nick Clifton <nickc@redhat.com> 187 188 Add multilib.am to the list of top level files included in any release created by the src-release.sh script 189 1902024-01-19 GDB Administrator <gdbadmin@sourceware.org> 191 192 Automatic date update in version.in 193 1942024-01-18 Xi Ruoyao <xry111@xry111.site> 195 196 LoongArch: Adapt R_LARCH_{PCALA,GOT,TLS_IE,TLS_DESC}64_* handling per psABI v2.30 197 In LoongArch psABI v2.30, an offset (-8 for LO20 and -12 for HI12) 198 should be applied on PC for these reloc types to avoid wrong relocation 199 when the instruction sequence crosses a page boundary. 200 201 The lld linker has already adapted the change. Make it for the bfd 202 linker too. 203 204 Link: https://github.com/loongson/la-abi-specs/releases/v2.30 205 Link: https://github.com/loongson-community/discussions/issues/17 206 Link: https://github.com/llvm/llvm-project/pull/73387 207 2082024-01-18 Nick Clifton <nickc@redhat.com> 209 210 Updated translations for various sub-directories 211 2122024-01-17 Alan Modra <amodra@gmail.com> 213 214 PR30824 internal error with -z pack-relative-relocs 215 This corrects a counting problem, where prior to relocate_section relr 216 encoded relative relocs were allowed when it was known they were on 217 even boundaries, but relocate_section can only put relative relocs 218 (non-relr) on eight byte boundaries. 219 220 PR 30824 221 * elf64-ppc.c (RELR_ALIGN): Define, use throughout. 222 (maybe_relr): New function, use throughout. 223 224 (cherry picked from commit f91074ebd8dc8077c9c778a42360e77a636dce5e) 225 2262024-01-17 H.J. Lu <hjl.tools@gmail.com> 227 228 Update x86-64: Add -z mark-plt and -z nomark-plt 229 Pass --hash-style=both to ld for -z mark-plt tests to support linker 230 configured with --enable-default-hash-style=gnu. 231 232 * testsuite/ld-x86-64/mark-plt-1b-x32.d: Pass --hash-style=both 233 to ld. 234 * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. 235 * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. 236 * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. 237 238 (cherry picked from commit 16666ccc91295d1568c5c2cb0e7600694840dfd9) 239 2402024-01-17 Nick Clifton <nickc@redhat.com> 241 242 Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling. 243 2442024-01-15 H.J. Lu <hjl.tools@gmail.com> 245 246 x86-64: Skip SCFI tests for x32 targets 247 Since SCFI isn't supported on x32: 248 249 Fatal error: SCFI is not supported for this ABI 250 251 skip SCFI tests for x32 targets. 252 253 PR gas/31245 254 * testsuite/gas/scfi/x86_64/scfi-x86-64.exp: Skip for x32 255 targets. 256 257 (cherry picked from commit 7bd344dd0e0469a93cbbf50f797155278cb76a0b) 258 2592024-01-15 Nick Clifton <nickc@redhat.com> 260 261 fix typo 262 263 Update version number and regenerate configure files 264 265 Add markers for 2.42 branch 266 267 Update branch/release creation documentation 268 2692024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 270 271 aarch64: rcpc3: Regenerate aarch64-*-2.c files 272 2732024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 274 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 275 276 aarch64: rcpc3: Add FP load/store insns 277 Along with the relevant unit-tests, this adds the following rcpc3 278 instructions: 279 280 STL1 { <Vt>.D }[<index>], [<Xn|SP>] 281 LDAP1 { <Vt>.D }[<index>], [<Xn|SP>] 282 283 LDAPUR <Bt>, [<Xn|SP>{, #<simm>}] 284 LDAPUR <Ht>, [<Xn|SP>{, #<simm>}] 285 LDAPUR <St>, [<Xn|SP>{, #<simm>}] 286 LDAPUR <Dt>, [<Xn|SP>{, #<simm>}] 287 LDAPUR <Qt>, [<Xn|SP>{, #<simm>}] 288 289 STLUR <Bt>, [<Xn|SP>{, #<simm>}] 290 STLUR <Ht>, [<Xn|SP>{, #<simm>}] 291 STLUR <St>, [<Xn|SP>{, #<simm>}] 292 STLUR <Dt>, [<Xn|SP>{, #<simm>}] 293 STLUR <Qt>, [<Xn|SP>{, #<simm>}] 294 295 with `#<simm>' taking on a signed 8-bit integer value in the range 296 [-256,255] and `index' the values 0 or 1. 297 2982024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 299 300 aarch64: rcpc3: Add integer load/store insns 301 Along with the relevant unit tests and updates to the existing 302 regression tests, this adds support for the following novel rcpc3 303 insns: 304 305 LDIAPP <Wt1>, <Wt2>, [<Xn|SP>] 306 LDIAPP <Wt1>, <Wt2>, [<Xn|SP>], #8 307 LDIAPP <Xt1>, <Xt2>, [<Xn|SP>] 308 LDIAPP <Xt1>, <Xt2>, [<Xn|SP>], #16 309 310 STILP <Wt1>, <Wt2>, [<Xn|SP>] 311 STILP <Wt1>, <Wt2>, [<Xn|SP>, #-8]! 312 STILP <Xt1>, <Xt2>, [<Xn|SP>] 313 STILP <Xt1>, <Xt2>, [<Xn|SP>, #-16]! 314 315 LDAPR <Wt>, [<Xn|SP>], #4 316 LDAPR <Xt>, [<Xn|SP>], #8 317 318 STLR <Wt>, [<Xn|SP>, #-4]! 319 STLR <Xt>, [<Xn|SP>, #-8]! 320 3212024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 322 323 aarch64: rcpc3: Define RCPC3_INSN macro 324 This patch adds the necessary macro for encoding FEAT_RCPC3-dependent 325 instructions in Binutils. 326 327 aarch64: rcpc3: add support in general_constraint_met_p 328 Given the introduction of the new address operand types for rcpc3 329 instructions, this patch adds the necessary logic to teach 330 `general_constraint_met_p` how to proper handle these. 331 3322024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 333 334 aarch64: rcpc3: New RCPC3_ADDR operand types 335 The particular choices of address indexing, along with their encoding 336 for RCPC3 instructions lead to the requirement of a new set of operand 337 descriptions, along with the relevant inserter/extractor set. 338 339 That is, for the integer load/stores, there is only a single valid 340 indexing offset quantity and offset mode is allowed - The value is 341 always equivalent to the amount of data read/stored by the 342 operation and the offset is post-indexed for Load-Acquire RCpc, and 343 pre-indexed with writeback for Store-Release insns. 344 345 This indexing quantity/mode pair is selected by the setting of a 346 single bit in the instruction. To represent these insns, we add the 347 following operand types: 348 349 - AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND 350 - AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB 351 352 In the case of loads and stores involving SIMD/FP registers, the 353 optional offset is encoded as an 8-bit signed immediate, but neither 354 post-indexing or pre-indexing with writeback is available. This 355 created the need for an operand type similar to 356 AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should 357 not be checked. 358 359 We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a 360 variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield. 361 3622024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 363 364 aarch64: rcpc3: Define address operand fields and inserter/extractors 365 Beyond the need to encode any registers involved in data transfer and 366 the address base register for load/stores, it is necessary to specify 367 the data register addressing mode and whether the address register is 368 to be pre/post-indexed, whereby loads may be post-indexed and stores 369 pre-indexed with write-back. 370 371 The use of a single bit to specify both the indexing mode and indexing 372 value requires a novel function be written to accommodate this for 373 address operand insertion in assembly and another for extraction in 374 disassembly, along with the definition of two insn fields for use with 375 these instructions. 376 377 This therefore defines the following functions: 378 379 - aarch64_ins_rcpc3_addr_opt_offset 380 - aarch64_ins_rcpc3_addr_offset 381 - aarch64_ext_rcpc3_addr_opt_offset 382 - aarch64_ext_rcpc3_addr_offset 383 384 It extends the `do_special_{encoding|decoding}' functions and defines 385 two rcpc3 instruction fields: 386 387 - FLD_opc2 388 - FLD_rcpc3_size 389 3902024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 391 392 aarch64: rcpc3: Create implicit load/store size calc function 393 The allowed immediate offsets in integer rcpc3 load store instructions 394 are not encoded explicitly in the instruction itself, being rather 395 implicitly equivalent to the amount of data loaded/stored by the 396 instruction. 397 398 This leads to the requirement that this quantity be calculated based on 399 the number of registers involved in the transfer, either as data 400 source or destination registers and their respective qualifiers. 401 402 This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)' 403 implemented here, using a cumulative sum of qualifier sizes preceding 404 the address operand in the OPNDS operand list argument. 405 4062024-01-15 Victor Do Nascimento <victor.donascimento@arm.com> 407 408 aarch64: rcpc3: Add +rcpc3 architectural feature support flag 409 Indicating the presence of the Armv8.2-a feature adding further 410 support for the Release Consistency Model, the `+rcpc3' architectural 411 extension flag is added to the list of possible `-march' options in 412 Binutils, together with the necessary macro for encoding rcpc3 413 instructions. 414 4152024-01-15 Mark Wielaard <mark@klomp.org> 416 417 bfd: riscv_maybe_function_sym check _bfd_elf_is_local_label_name 418 This fixes the ld "Handle no DWARF information" testcase. Which 419 currently fails on riscv because a local label name is assumed 420 to be the current function name. 421 422 bfd/ChangeLog: 423 424 * elfnn-riscv.c (riscv_maybe_function_sym): Also check 425 _bfd_elf_is_local_label_name. 426 4272024-01-15 Andrew Carlotti <andrew.carlotti@arm.com> 428 429 aarch64: Fix tlbi and tlbip instructions 430 There are some tlbi operations that don't have a corresponding tlbip operation, 431 but we were incorrectly using the same list for both. Add the missing tlbi 432 *nxs operations, and use the F_REG_128 flag to filter tlbi operations that 433 don't have a tlbip analogue. For increased clarity, I have also used a macro 434 to reduce duplication between the 'nxs' and non-'nxs' variants, and added a 435 test to verify that no invalid combinations are accepted. 436 437 Additionally, fix two missing checks for AARCH64_OPND_SYSREG_TLBIP that were 438 preventing disassembly of tlbip instructions. 439 4402024-01-15 Andrew Carlotti <andrew.carlotti@arm.com> 441 442 aarch64: Refactor aarch64_sys_ins_reg_supported_p 443 Add an aarch64_feature_set field to aarch64_sys_ins_reg, and use this for 444 feature checks instead of testing against a list of operand codes. 445 4462024-01-15 Nick Clifton <nickc@redhat.com> 447 448 nm: Replace --with-symbol-versions with --without-symbol-versions in --help output 449 PR 31243 450 nm: Fix --help output 451 4522024-01-15 Andrew Carlotti <andrew.carlotti@arm.com> 453 454 aarch64: Remove unused BTI feature bit 455 OK for master? 456 4572024-01-15 Nick Clifton <nickc@redhat.com> 458 459 Add generated source files and fix thinko in aarch64-asm.c 460 4612024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 462 463 aarch64: Add SVE2.1 Contiguous load/store instructions. 464 Hi, 465 466 This patch add support for SVE2.1 instructions ld1q, 467 ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q. 468 469 Regression testing for aarch64-none-elf target and found no regressions. 470 471 Ok for binutils-master? 472 473 Regards, 474 Srinath. 475 4762024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 477 478 PATCH 5/6][Binutils] aarch64: Add SVE2.1 fmin and fmax instructions. 479 Hi, 480 481 This patch add support for SVE2.1 instruction faddqv, 482 fmaxnmqv, fmaxqv, fminnmqv and fminqv. 483 484 Regression testing for aarch64-none-elf target and found no regressions. 485 486 Ok for binutils-master? 487 488 Regards, 489 Srinath. 490 4912024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 492 493 aarch64: Add SVE2.1 dupq, eorqv and extq instructions. 494 Hi, 495 496 This patch add support for SVE2.1 instruction dupq, eorqv and extq. 497 498 Regression testing for aarch64-none-elf target and found no regressions. 499 500 Ok for binutils-master? 501 502 Regards, 503 Srinath. 504 5052024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 506 507 aarch64: Add support for FEAT_SVE2p1. 508 Hi, 509 510 This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature 511 along with +sve2p1 optional flag to enabe this feature. 512 513 Also support for following SVE2p1 instructions is added 514 addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv. 515 516 Regression testing for aarch64-none-elf target and found no regressions. 517 518 Ok for binutils-master? 519 520 Regards, 521 Srinath. 522 5232024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 524 525 aarch64: Add support for FEAT_SME2p1 instructions. 526 Hi, 527 528 This patch add support for FEAT_SME2p1 and "movaz" instructions 529 along with the optional flag +sme2p1. 530 531 Following "movaz" instructions are add: 532 Move and zero two ZA tile slices to vector registers. 533 Move and zero four ZA tile slices to vector registers. 534 535 Regression testing for aarch64-none-elf target and found no regressions. 536 537 Ok for binutils-master? 538 539 Regards, 540 Srinath. 541 5422024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 543 544 aarch64: Add support for FEAT_B16B16 instructions. 545 Hi, 546 547 This patch add support for SVE2.1 and SME2.1 non-widening BFloat16 548 (FEAT_B16B16) instructions. 549 550 Following instructions predicated, unpredicated and indexed 551 variants are added in this patch. 552 553 bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm, 554 bfmla,bfmls,bfmul and bfsub. 555 556 Regression testing for aarch64-none-elf target and found no regressions. 557 558 Ok for binutils-master? 559 560 Regards, 561 Srinath. 562 5632024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 564 565 gas/NEWS: announce the new SCFI command line option 566 5672024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 568 569 gas: testsuite: add an x86 testsuite for SCFI 570 The testsuite for SCFI contains target-specific tests. 571 572 When a test is executed with --scfi=experimental command line option, 573 the CFI annotations in the test .s files are skipped altogether by the 574 GAS for processing. The CFI directives in the input assembly files are, 575 however, validated by running the assembler one more time without 576 --scfi=experimental. 577 578 Some testcases are used to highlight those asm constructs that the SCFI 579 machinery in GAS currently does not support: 580 581 - Only System V AMD64 ABI is supported for now. Using either --32 or 582 --x32 with SCFI results in hard error. 583 See scfi-unsupported-1.s. 584 585 - Untraceable stack-pointer manipulation in function epilougue and prologue. 586 See scfi-unsupported-2.s. 587 588 - Using Dynamically Realigned Arguement Pointer (DRAP) register to 589 realign the stack. For SCFI, the CFA must be only REG_SP or REG_FP 590 based. See scfi-unsupported-drap-1.s 591 592 Some testcases are used to highlight some diagnostics that the SCFI 593 machinery in GAS currently issues, with an intent to help user correct 594 inadvertent errors in their hand-written asm. An error is issued when 595 GAS finds that input asm is not amenable to correct CFI synthesis. 596 597 - (#1) "Warning: SCFI: Asymetrical register restore" 598 - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" 599 - (#3) "Error: SCFI: unsupported stack manipulation pattern" 600 601 In case of (#2) and (#3), SCFI generation is skipped for the respective 602 function. Above is a subset of the warnings/errors implemented in the 603 code. 604 605 gas/testsuite/: 606 * gas/scfi/README: New test. 607 * gas/scfi/x86_64/ginsn-add-1.l: New test. 608 * gas/scfi/x86_64/ginsn-add-1.s: New test. 609 * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: New test. 610 * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: New test. 611 * gas/scfi/x86_64/ginsn-pop-1.l: New test. 612 * gas/scfi/x86_64/ginsn-pop-1.s: New test. 613 * gas/scfi/x86_64/ginsn-push-1.l: New test. 614 * gas/scfi/x86_64/ginsn-push-1.s: New test. 615 * gas/scfi/x86_64/scfi-add-1.d: New test. 616 * gas/scfi/x86_64/scfi-add-1.l: New test. 617 * gas/scfi/x86_64/scfi-add-1.s: New test. 618 * gas/scfi/x86_64/scfi-add-2.d: New test. 619 * gas/scfi/x86_64/scfi-add-2.l: New test. 620 * gas/scfi/x86_64/scfi-add-2.s: New test. 621 * gas/scfi/x86_64/scfi-asm-marker-1.d: New test. 622 * gas/scfi/x86_64/scfi-asm-marker-1.l: New test. 623 * gas/scfi/x86_64/scfi-asm-marker-1.s: New test. 624 * gas/scfi/x86_64/scfi-asm-marker-2.d: New test. 625 * gas/scfi/x86_64/scfi-asm-marker-2.l: New test. 626 * gas/scfi/x86_64/scfi-asm-marker-2.s: New test. 627 * gas/scfi/x86_64/scfi-asm-marker-3.d: New test. 628 * gas/scfi/x86_64/scfi-asm-marker-3.l: New test. 629 * gas/scfi/x86_64/scfi-asm-marker-3.s: New test. 630 * gas/scfi/x86_64/scfi-bp-sp-1.d: New test. 631 * gas/scfi/x86_64/scfi-bp-sp-1.l: New test. 632 * gas/scfi/x86_64/scfi-bp-sp-1.s: New test. 633 * gas/scfi/x86_64/scfi-bp-sp-2.d: New test. 634 * gas/scfi/x86_64/scfi-bp-sp-2.l: New test. 635 * gas/scfi/x86_64/scfi-bp-sp-2.s: New test. 636 * gas/scfi/x86_64/scfi-callee-saved-1.d: New test. 637 * gas/scfi/x86_64/scfi-callee-saved-1.l: New test. 638 * gas/scfi/x86_64/scfi-callee-saved-1.s: New test. 639 * gas/scfi/x86_64/scfi-callee-saved-2.d: New test. 640 * gas/scfi/x86_64/scfi-callee-saved-2.l: New test. 641 * gas/scfi/x86_64/scfi-callee-saved-2.s: New test. 642 * gas/scfi/x86_64/scfi-callee-saved-3.d: New test. 643 * gas/scfi/x86_64/scfi-callee-saved-3.l: New test. 644 * gas/scfi/x86_64/scfi-callee-saved-3.s: New test. 645 * gas/scfi/x86_64/scfi-callee-saved-4.d: New test. 646 * gas/scfi/x86_64/scfi-callee-saved-4.l: New test. 647 * gas/scfi/x86_64/scfi-callee-saved-4.s: New test. 648 * gas/scfi/x86_64/scfi-cfg-1.d: New test. 649 * gas/scfi/x86_64/scfi-cfg-1.l: New test. 650 * gas/scfi/x86_64/scfi-cfg-1.s: New test. 651 * gas/scfi/x86_64/scfi-cfg-2.d: New test. 652 * gas/scfi/x86_64/scfi-cfg-2.l: New test. 653 * gas/scfi/x86_64/scfi-cfg-2.s: New test. 654 * gas/scfi/x86_64/scfi-cfi-label-1.d: New test. 655 * gas/scfi/x86_64/scfi-cfi-label-1.l: New test. 656 * gas/scfi/x86_64/scfi-cfi-label-1.s: New test. 657 * gas/scfi/x86_64/scfi-cfi-sections-1.d: New test. 658 * gas/scfi/x86_64/scfi-cfi-sections-1.l: New test. 659 * gas/scfi/x86_64/scfi-cfi-sections-1.s: New test. 660 * gas/scfi/x86_64/scfi-cofi-1.d: New test. 661 * gas/scfi/x86_64/scfi-cofi-1.l: New test. 662 * gas/scfi/x86_64/scfi-cofi-1.s: New test. 663 * gas/scfi/x86_64/scfi-diag-1.l: New test. 664 * gas/scfi/x86_64/scfi-diag-1.s: New test. 665 * gas/scfi/x86_64/scfi-diag-2.l: New test. 666 * gas/scfi/x86_64/scfi-diag-2.s: New test. 667 * gas/scfi/x86_64/scfi-dyn-stack-1.d: New test. 668 * gas/scfi/x86_64/scfi-dyn-stack-1.l: New test. 669 * gas/scfi/x86_64/scfi-dyn-stack-1.s: New test. 670 * gas/scfi/x86_64/scfi-enter-1.d: New test. 671 * gas/scfi/x86_64/scfi-enter-1.l: New test. 672 * gas/scfi/x86_64/scfi-enter-1.s: New test. 673 * gas/scfi/x86_64/scfi-fp-diag-2.l: New test. 674 * gas/scfi/x86_64/scfi-fp-diag-2.s: New test. 675 * gas/scfi/x86_64/scfi-indirect-mov-1.d: New test. 676 * gas/scfi/x86_64/scfi-indirect-mov-1.l: New test. 677 * gas/scfi/x86_64/scfi-indirect-mov-1.s: New test. 678 * gas/scfi/x86_64/scfi-indirect-mov-2.d: New test. 679 * gas/scfi/x86_64/scfi-indirect-mov-2.l: New test. 680 * gas/scfi/x86_64/scfi-indirect-mov-2.s: New test. 681 * gas/scfi/x86_64/scfi-indirect-mov-3.d: New test. 682 * gas/scfi/x86_64/scfi-indirect-mov-3.l: New test. 683 * gas/scfi/x86_64/scfi-indirect-mov-3.s: New test. 684 * gas/scfi/x86_64/scfi-indirect-mov-4.d: New test. 685 * gas/scfi/x86_64/scfi-indirect-mov-4.l: New test. 686 * gas/scfi/x86_64/scfi-indirect-mov-4.s: New test. 687 * gas/scfi/x86_64/scfi-indirect-mov-5.s: New test. 688 * gas/scfi/x86_64/scfi-lea-1.d: New test. 689 * gas/scfi/x86_64/scfi-lea-1.l: New test. 690 * gas/scfi/x86_64/scfi-lea-1.s: New test. 691 * gas/scfi/x86_64/scfi-leave-1.d: New test. 692 * gas/scfi/x86_64/scfi-leave-1.l: New test. 693 * gas/scfi/x86_64/scfi-leave-1.s: New test. 694 * gas/scfi/x86_64/scfi-pushq-1.d: New test. 695 * gas/scfi/x86_64/scfi-pushq-1.l: New test. 696 * gas/scfi/x86_64/scfi-pushq-1.s: New test. 697 * gas/scfi/x86_64/scfi-pushsection-1.d: New test. 698 * gas/scfi/x86_64/scfi-pushsection-1.l: New test. 699 * gas/scfi/x86_64/scfi-pushsection-1.s: New test. 700 * gas/scfi/x86_64/scfi-pushsection-2.d: New test. 701 * gas/scfi/x86_64/scfi-pushsection-2.l: New test. 702 * gas/scfi/x86_64/scfi-pushsection-2.s: New test. 703 * gas/scfi/x86_64/scfi-selfalign-func-1.d: New test. 704 * gas/scfi/x86_64/scfi-selfalign-func-1.l: New test. 705 * gas/scfi/x86_64/scfi-selfalign-func-1.s: New test. 706 * gas/scfi/x86_64/scfi-simple-1.d: New test. 707 * gas/scfi/x86_64/scfi-simple-1.l: New test. 708 * gas/scfi/x86_64/scfi-simple-1.s: New test. 709 * gas/scfi/x86_64/scfi-simple-2.d: New test. 710 * gas/scfi/x86_64/scfi-simple-2.l: New test. 711 * gas/scfi/x86_64/scfi-simple-2.s: New test. 712 * gas/scfi/x86_64/scfi-sub-1.d: New test. 713 * gas/scfi/x86_64/scfi-sub-1.l: New test. 714 * gas/scfi/x86_64/scfi-sub-1.s: New test. 715 * gas/scfi/x86_64/scfi-sub-2.d: New test. 716 * gas/scfi/x86_64/scfi-sub-2.l: New test. 717 * gas/scfi/x86_64/scfi-sub-2.s: New test. 718 * gas/scfi/x86_64/scfi-unsupported-1.l: New test. 719 * gas/scfi/x86_64/scfi-unsupported-1.s: New test. 720 * gas/scfi/x86_64/scfi-unsupported-2.l: New test. 721 * gas/scfi/x86_64/scfi-unsupported-2.s: New test. 722 * gas/scfi/x86_64/scfi-unsupported-3.l: New test. 723 * gas/scfi/x86_64/scfi-unsupported-3.s: New test. 724 * gas/scfi/x86_64/scfi-unsupported-4.l: New test. 725 * gas/scfi/x86_64/scfi-unsupported-4.s: New test. 726 * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: New test. 727 * gas/scfi/x86_64/scfi-unsupported-cfg-1.s: New test. 728 * gas/scfi/x86_64/scfi-unsupported-cfg-2.l: New test. 729 * gas/scfi/x86_64/scfi-unsupported-cfg-2.s: New test. 730 * gas/scfi/x86_64/scfi-unsupported-drap-1.l: New test. 731 * gas/scfi/x86_64/scfi-unsupported-drap-1.s: New test. 732 * gas/scfi/x86_64/scfi-unsupported-insn-1.l: New test. 733 * gas/scfi/x86_64/scfi-unsupported-insn-1.s: New test. 734 * gas/scfi/x86_64/scfi-x86-64.exp: New file. 735 7362024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 737 738 opcodes: i386-reg.tbl: Add a comment to reflect dependency on ordering 739 The ginsn representation keeps the DWARF register number of the 740 operands. The API ginsn_dw2_regnum relies on the the relative ordering 741 of these register entries in the table. Add a comment to make it clear. 742 743 opcodes/ 744 * i386-reg.tbl: Add a comment. 745 7462024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 747 748 gas: doc: update documentation for the new listing option 749 Add a new listing option, -i, to emit ginsn in the listing output. We 750 may also emit other SCFI information if necessary in the future. 751 752 ginsn are most useful when seen alongside the assembly instructions. 753 Hence, they are emitted when the user includes the assembly instructions 754 in the listing output, i.e., "-ali=FILE". 755 756 gas/doc/: 757 * as.texi: Add documentation for the new listing option, -i. 758 7592024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 760 761 gas: x86: synthesize CFI for hand-written asm 762 This patch adds support in GAS to create generic GAS instructions 763 (a.k.a., the ginsn) for the x86 backend (AMD64 ABI only at this time). 764 Using this ginsn infrastructure, GAS can then synthesize CFI for 765 hand-written asm for x86_64. 766 767 A ginsn is a target-independent representation of the machine 768 instructions. One machine instruction may need one or more ginsn. 769 770 This patch also adds skeleton support for printing ginsn in the listing 771 output for debugging purposes. 772 773 Since the current use-case of ginsn is to synthesize CFI, the x86 target 774 needs to generate ginsns necessary for the following machine 775 instructions only: 776 777 - All change of flow instructions, including all conditional and 778 unconditional branches, call and return from functions. 779 - All register saves and unsaves to the stack. 780 - All instructions affecting the two registers that could potentially 781 be used as the base register for CFA tracking. For SCFI, the base 782 register for CFA tracking is limited to REG_SP and REG_FP only for 783 now. 784 785 The representation of ginsn is kept simple: 786 787 - GAS instruction has GINSN_NUM_SRC_OPNDS (defined to be 2 at this time) 788 number of source operands and one destination operand at this time. 789 - GAS instruction uses DWARF register numbers in its representation and 790 does not track register size. 791 - GAS instructions carry location information (file name and line 792 number). 793 - GAS instructions are ID's with a natural number in order of their 794 addtion to the list. This can be used as a proxy for the static 795 program order of the corresponding machine instructions. 796 797 Note that, GAS instruction (ginsn) format does not support 798 GINSN_TYPE_PUSH and GINSN_TYPE_POP. Some architectures, like aarch64, 799 do not have push and pop instructions, but rather STP/LDP/STR/LDR etc. 800 instructions. Further these instructions have a variety of addressing 801 modes, like offset, pre-indexing and post-indexing etc. Among other 802 things, one of differences in these addressing modes is _when_ the addr 803 register is updated with the result of the address calculation: before 804 or after the memory operation. To best support such needs, the generic 805 instructions like GINSN_TYPE_LOAD, GINSN_TYPE_STORE together with 806 GINSN_TYPE_ADD, and GINSN_TYPE_SUB may be used. 807 808 The functionality provided in ginsn.c and scfi.c is compiled in when a 809 target defines TARGET_USE_SCFI and TARGET_USE_GINSN. This can be 810 revisited later when there are other use-cases of creating ginsn's in 811 GAS, apart from the current use-case of synthesizing CFI for 812 hand-written asm. 813 814 Support is added only for System V AMD64 ABI for ELF at this time. If 815 the user enables SCFI with --32, GAS issues an error: 816 817 "Fatal error: SCFI is not supported for this ABI" 818 819 For synthesizing (DWARF) CFI, the SCFI machinery requires the programmer 820 to adhere to some pre-requisites for their asm: 821 - Hand-written asm block must begin with a .type foo, @function 822 It is highly recommended to, additionally, also ensure that: 823 - Hand-written asm block ends with a .size foo, .-foo 824 825 The SCFI machinery encodes some rules which align with the standard 826 calling convention specified by the ABI. Apart from the rules, the SCFI 827 machinery employs some heuristics. For example: 828 - The base register for CFA tracking may be either REG_SP or REG_FP. 829 - If the base register for CFA tracking is REG_SP, the precise amount of 830 stack usage (and hence, the value of REG_SP) must be known at all times. 831 - If using dynamic stack allocation, the function must switch to 832 FP-based CFA. This means using instructions like the following (in 833 AMD64) in prologue: 834 pushq %rbp 835 movq %rsp, %rbp 836 and analogous instructions in epilogue. 837 - Save and Restore of callee-saved registers must be symmetrical. 838 However, the SCFI machinery at this time only warns if any such 839 asymmetry is seen. 840 841 These heuristics/rules are architecture-independent and are meant to 842 employed for all architectures/ABIs using SCFI in the future. 843 844 gas/ 845 * Makefile.am: Add new files. 846 * Makefile.in: Regenerated. 847 * as.c (defined): Handle documentation and listing option for 848 ginsns and SCFI. 849 * config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end. 850 (obj_elf_type): Invoke ginsn_data_begin. 851 * config/tc-i386.c (x86_scfi_callee_saved_p): New function. 852 (ginsn_prefix_66H_p): Likewise. 853 (ginsn_dw2_regnum): Likewise. 854 (x86_ginsn_addsub_reg_mem): Likewise. 855 (x86_ginsn_addsub_mem_reg): Likewise. 856 (x86_ginsn_alu_imm): Likewise. 857 (x86_ginsn_move): Likewise. 858 (x86_ginsn_lea): Likewise. 859 (x86_ginsn_jump): Likewise. 860 (x86_ginsn_jump_cond): Likewise. 861 (x86_ginsn_enter): Likewise. 862 (x86_ginsn_safe_to_skip): Likewise. 863 (x86_ginsn_unhandled): Likewise. 864 (x86_ginsn_new): New functionality to generate ginsns. 865 (md_assemble): Invoke x86_ginsn_new. 866 (s_insn): Likewise. 867 (i386_target_format): Add hard error for usage of SCFI with non AMD64 ABIs. 868 * config/tc-i386.h (TARGET_USE_GINSN): New definition. 869 (TARGET_USE_SCFI): Likewise. 870 (SCFI_MAX_REG_ID): Likewise. 871 (REG_FP): Likewise. 872 (REG_SP): Likewise. 873 (SCFI_INIT_CFA_OFFSET): Likewise. 874 (SCFI_CALLEE_SAVED_REG_P): Likewise. 875 (x86_scfi_callee_saved_p): Likewise. 876 * gas/listing.h (LISTING_GINSN_SCFI): New define for ginsn and 877 SCFI. 878 * gas/read.c (read_a_source_file): Close SCFI processing at end 879 of file read. 880 * gas/scfidw2gen.c (scfi_process_cfi_label): Add implementation. 881 (scfi_process_cfi_signal_frame): Likewise. 882 * subsegs.h (struct frch_ginsn_data): New forward declaration. 883 (struct frchain): New member for ginsn data. 884 * gas/subsegs.c (subseg_set_rest): Initialize the new member. 885 * symbols.c (colon): Invoke ginsn_frob_label to convey 886 user-defined labels to ginsn infrastructure. 887 * ginsn.c: New file. 888 * ginsn.h: New file. 889 * scfi.c: New file. 890 * scfi.h: New file. 891 8922024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 893 894 opcodes: x86: new marker for insns that implicitly update stack pointer 895 Some x86 instructions affect the stack pointer implicitly. Add a new 896 operand constraint to reflect this. This will be useful for SCFI 897 implmentation to ensure its correctness. 898 899 Mark all push, pop, call, ret, enter, leave, INT, iret instructions. 900 901 opcodes/ 902 * i386-gen.c: Update opcode_modifiers. 903 * i386-opc.h: Add a new constraint. 904 * i386-opc.tbl: Update the affected instructions. 905 * i386-tbl.h: Regenerated. 906 9072024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 908 909 opcodes: gas: x86: define and use Rex2 as attribute not constraint 910 Rex2 is currently an operand constraint. For the upcoming SCFI 911 implementation in GAS, we need to identify operations which implicitly 912 update the stack pointer. An operand constraint enumerator for implicit 913 stack op seems more appropriate than an attribute. However, two opcodes 914 currently necessitate both Rex2 and an implicit stack op marker; this 915 prompts revisiting the current representations a bit. 916 917 Make Rex2 a standalone attribute, so that later a new operand constraint 918 may be added for IMPLICIT_STACK_OP. 919 920 ChangeLog: 921 * gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check. 922 * opcodes/i386-gen.c: Add a new BITFIELD for Rex2. 923 * opcodes/i386-opc.h (REX2_REQUIRED): Remove. 924 * opcodes/i386-opc.tbl: Remove Rex2 operand constraint. 925 * opcodes/i386-tbl.h: Regenerated. 926 9272024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 928 929 gas: scfidw2gen: new functionality to prepare for SCFI 930 Define a new set of handlers for CFI directives for the purpose of SCFI. 931 The SCFI machinery ignores many of the user-specified CFI direcives when 932 SCFI is in effect. A warning ("Warning: SCFI ignores most 933 user-specified CFI directives") is issued once per file. The following 934 CFI directives, however, are not ignored: 935 - .cfi_sections 936 - .cfi_label 937 - .cfi_signal_frame 938 939 gas/ 940 * Makefile.am: Add new files to GAS_CFILES and HFILES. 941 * Makefile.in: Likewise. 942 * gas/read.c (scfi_pop_insert): New define. 943 (pobegin): Use the SCFI handlers. 944 * scfidw2gen.c: New file. 945 * scfidw2gen.h: New file. 946 9472024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 948 949 gas: add new command line option --scfi=experimental 950 When the command line option --scfi=experimenta is passed to the GNU 951 assembler, it will synthesize DWARF call frame information (CFI) for the 952 input assembly. 953 954 The option --scfi=experimental will also ignore most of the existing 955 .cfi_* directives, if already contained in the provided input file. 956 Only the following CFI directives will not be ignored: 957 - .cfi_sections, 958 - .cfi_label, 959 - .cfi_signal_frame 960 961 To use SCFI, a target will need to: 962 - define TARGET_USE_SCFI and TARGET_USE_GINSN, and other necessary 963 definitions, 964 - provide means to help GAS understand the target specific instruction 965 semantics by creating ginsns. 966 967 The upcoming support for SCFI is inteded to be experimental, hence the 968 option --scfi=experimental. The --scfi= may see more options like 969 --scfi=[all,none] added in future, once the SCFI support in GAS is 970 mature and robust. The offering may also see for example, an 971 --scfi=inline option for dealing with inline asm may be added in the 972 future. In --scfi=inline option, the GNU assembler may consume (and not 973 ignore) the compiler generated CFI for the code surrounding the inline 974 asm. 975 976 Also document the option. 977 978 gas/ 979 * as.c (show_usage): Add support for --scfi=experimental. 980 (parse_args): Likewise. 981 * as.h (enum synth_cfi_type): Define new type. 982 * doc/as.texi: Document the new option. 983 9842024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 985 986 gas: dw2gencfi: externalize the all_cfi_sections 987 gas/ 988 * dw2gencfi.h: Declare all_cfi_sections as extern. 989 9902024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 991 992 gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen 993 scfidw2gen will use this for processing the .cfi_sections directive. 994 995 gas/ 996 * dw2gencfi.c (dot_cfi_sections): Not static anymore. 997 * dw2gencfi.h (dot_cfi_sections): Mark as extern. 998 9992024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 1000 1001 gas: dw2gencfi: move some tc_* defines to the header file 1002 Move the following three defines to the header file, so the SCFI 1003 machinery can use them: 1004 - tc_cfi_frame_initial_instructions 1005 - tc_cfi_startproc 1006 - tc_cfi_endproc 1007 1008 gas/ 1009 * dw2gencfi.c: Move from ... 1010 * dw2gencfi.h: ... to here. 1011 10122024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 1013 1014 gas: dw2gencfi: expose a new cfi_set_last_fde API 1015 gas/ 1016 * dw2gencfi.c (cfi_set_last_fde): New definition. 1017 (dot_cfi_endproc): Use it. 1018 (dot_cfi_fde_data): Likewise. 1019 (dot_cfi_inline_lsda): Likewise. 1020 * dw2gencfi.h (struct fde_entry): New declaration. 1021 (cfi_set_last_fde): Likewise. 1022 10232024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 1024 1025 gas: dw2gencfi: use all_cfi_sections instead of cfi_sections 1026 The code in dw2gencfi.c was checking variable cfi_sections and 1027 all_cfi_sections seemingly randomly. Accessing all_cfi_sections seems 1028 to the correct variable to access. 1029 1030 The data in cfi_sections has already been propagated to all_cfi_sections 1031 once cfi_dot_startproc () has been called. 1032 1033 gas/ 1034 * dw2gencfi.c (dot_cfi_startproc): Use all_cfi_sections 1035 instead. 1036 (dot_cfi_endproc): Likewise. 1037 (dot_cfi_fde_data): Likewise. 1038 10392024-01-15 Indu Bhagat <indu.bhagat@oracle.com> 1040 1041 gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections 1042 cfi_sections_set is best set to true in cfi_dot_startproc (). Setting 1043 it to true again in other APIs (dot_cfi_endproc, dot_cfi_fde_data, and 1044 cfi_finish) is unnecessary. Also, move setting the global var 1045 all_cfi_sections into cfi_set_sections (). 1046 1047 gas/ 1048 * dw2gencfi.c (cfi_set_sections): Set cfi_sections_set and 1049 cfi_sections here. 1050 (dot_cfi_startproc): Remove unnecessarily setting 1051 cfi_set_sections to true. 1052 (dot_cfi_endproc): Likewise. 1053 (dot_cfi_fde_data): Likewise. 1054 (cfi_finish): Likewise. 1055 10562024-01-15 GDB Administrator <gdbadmin@sourceware.org> 1057 1058 Automatic date update in version.in 1059 10602024-01-14 Tom de Vries <tdevries@suse.de> 1061 1062 [gdb/testsuite] Fix gdb.mi/mi-dprintf.exp with read1 1063 When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into: 1064 ... 1065 (gdb) ^M 1066 PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop 1067 -data-evaluate-expression stderr^M 1068 ^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M 1069 (gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check 1070 ... 1071 1072 The problem is in proc mi_gdb_is_stderr_available: 1073 ... 1074 proc mi_gdb_is_stderr_available {} { 1075 set has_stderr_symbol false 1076 gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" { 1077 -re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" { 1078 } 1079 -re "$::mi_gdb_prompt$" { 1080 set has_stderr_symbol true 1081 } 1082 } 1083 ... 1084 which uses a gdb_test_multiple that is supposed to use the mi prompt, but 1085 doesn't use -prompt to indicate this. Consequently, the default patterns use 1086 the regular gdb prompt, which trigger earlier than the two custom patterns 1087 which use "$::mi_gdb_prompt$". 1088 1089 Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments. 1090 1091 While we're at it, make the gdb_test_multiple call a bit more readable by 1092 using variables, and by using -wrap. 1093 1094 Tested on x86_64-linux, with: 1095 - gcc and clang (to trigger both the has_stderr_symbol true and false cases) 1096 - make check and make check-read1. 1097 10982024-01-14 Tom de Vries <tdevries@suse.de> 1099 1100 [gdb/testsuite] Fix gdb.cp/namespace.exp with read1 1101 With check-read1 we run into: 1102 ... 1103 (gdb) break DNE>::DNE^M 1104 Function "DNE>::DNE" not defined.^M 1105 Make breakpoint pending on future shared library load? (y or [n]) y^M 1106 Breakpoint 9 (DNE>::DNE) pending.^M 1107 n^M 1108 (gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt) 1109 n^M 1110 ... 1111 1112 The question is supposed to be handled by the question and response arguments 1113 to this gdb_test call: 1114 ... 1115 gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \ 1116 "Make breakpoint pending on future shared library load?.*" "y" 1117 ... 1118 but both this and the builtin handling in gdb_test_multiple triggers. 1119 1120 The cause of this is that the question argument regexp is incomplete. 1121 1122 Fix this by making sure that the entire question is matched in the regexp: 1123 ... 1124 set yn_re [string_to_regexp {(y or [n])}] 1125 ... 1126 "Make breakpoint pending on future shared library load\\? $yn_re " "Y" 1127 ... 1128 1129 Tested on x86_64-linux. 1130 11312024-01-14 GDB Administrator <gdbadmin@sourceware.org> 1132 1133 Automatic date update in version.in 1134 11352024-01-13 Yang Liu <liuyang22@iscas.ac.cn> 1136 1137 gdb: RISC-V: Refine lr/sc sequence support 1138 Per RISC-V spec, the lr/sc sequence can consist of up to 16 instructions, and we 1139 cannot insert breakpoints in the middle of this sequence. Before this, we only 1140 detected a specific pattern (the most common one). This patch improves this part 1141 and now supports more complex pattern detection. 1142 1143 Approved-By: Andrew Burgess <aburgess@redhat.com> 1144 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 1145 11462024-01-13 Yang Liu <liuyang22@iscas.ac.cn> 1147 1148 Add myself to gdb/MAINTAINERS 1149 11502024-01-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1151 1152 gprofng: 30889 can't compile without large file support 1153 gprofng/ChangeLog 1154 2024-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1155 1156 PR 30889 1157 * src/util.h (O_LARGEFILE): Define to 0, if not defined. 1158 11592024-01-13 GDB Administrator <gdbadmin@sourceware.org> 1160 1161 Automatic date update in version.in 1162 11632024-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1164 1165 gprofng: fix 3 bugzillas against gp-display-html 1166 Fix two cases where gp-display-html terminates prematurely because the 1167 input format is not recognized. This problem occurs in the function 1168 overview and caller-callee parts of the code. 1169 The fix consists of new regular expressions and a different approach 1170 in handling the input from gp-display-text. 1171 Also fix a performance problem in the caller-callee part that has a 1172 noticeable impact on the performance for large applications. 1173 1174 gprofng/ChangeLog 1175 2024-01-10 Ruud van der Pas <ruud.vanderpas@oracle.com> 1176 1177 PR gprofng/30438 1178 PR gprofng/30439 1179 PR gprofng/30942 1180 * gp-display-html/gp-display-html.in: fixes the issues. 1181 11822024-01-12 Dimitar Dimitrov <dimitar@dinux.eu> 1183 1184 sim: Fix compile errors 1185 The following change broke simulator testsuite with host GCC 13: 1186 commit 435ad222b3de93fa647fba7221eece36b1b395eb 1187 sim: warnings: compile build tools with -Werror too 1188 1189 Host GCC13 complains about missing function prototypes: 1190 1191 binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes] 1192 26 | gen_struct (void) 1193 | ^~~~~~~~~~ 1194 1195 Fix by making the functions static, which instructs the compiler that 1196 there is no need for a prototype. 1197 11982024-01-12 David Faust <david.faust@oracle.com> 1199 1200 bpf: fix relocation addend incorrect symbol value 1201 Relocations installed by the BPF ELF backend were sometimes incorrectly 1202 adding the symbol value to the relocation entry addend, when the correct 1203 relocation value was already stored in the addend. This could lead to a 1204 relocation effectively adding the symbol value twice. 1205 1206 Fix that by making bpf_elf_generic_reloc () more similar to the flow of 1207 bfd_install_relocation in the case where howto->install_addend is set, 1208 which is how it ought to behave. 1209 1210 bfd/ 1211 * bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64) 1212 (R_BPF_64_NODYLD32): Set partial_inplace to true. 1213 * elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value 1214 of the symbol when installing relocation. Copy some additional 1215 logic from bfd_elf_generic_reloc. 1216 1217 gas/ 1218 * testsuite/gas/bpf/bpf.exp: Run new test. 1219 * testsuite/gas/bpf/elf-relo-1.d: New. 1220 * testsuite/gas/bpf/elf-relo-1.s: New. 1221 12222024-01-12 Andrew Burgess <aburgess@redhat.com> 1223 1224 gdb/testsuite: fix failure in gdb.python/py-inferior.exp 1225 After this commit: 1226 1227 commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72 1228 Date: Thu Jan 4 10:01:24 2024 +0000 1229 1230 gdb/python: add gdb.InferiorThread.__repr__() method 1231 1232 failures were reported for gdb.python/py-inferior.exp. 1233 1234 The test grabs a gdb.InferiorThread object representing an inferior 1235 thread, and then, later in the test, expects this Python object to 1236 become invalid when the inferior thread has exited. 1237 1238 The gdb.InferiorThread object was obtained from the list returned by 1239 calling gdb.Inferior.threads(). 1240 1241 The mistake I made in the original commit was to assume that the order 1242 of the threads returned from gdb.Inferior.threads() somehow reflected 1243 the thread creation order. Specifically, I was expecting the main 1244 thread to be first in the list, and "other" threads to appear ... not 1245 first. 1246 1247 However, the gdb.Inferior.threads() function creates a list and 1248 populates it from a map. The order of the threads in the returned 1249 list has no obvious relationship to the thread creation order, and can 1250 vary from host to host. 1251 1252 On my machine the ordering was as I expected, so the test passed for 1253 me. For others the ordering was not as expected, and it just happened 1254 that we ended up recording the gdb.InferiorThread for the main thread. 1255 1256 As the main thread doesn't exit (until the test is over), the 1257 gdb.InferiorThread object never became invalid, and the test failed. 1258 1259 Fixed in this commit by taking more care to correctly find a non-main 1260 thread. I do this by recording the main thread early on (when there 1261 is only one inferior thread), and then finding any thread that is not 1262 this main thread. 1263 1264 Then, once all of the secondary threads have exited, I know that the 1265 second InferiorThread object I found should now be invalid. 1266 1267 The test still passes for me, and I believe this should fix the issue 1268 for everyone else too. 1269 1270 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238 1271 12722024-01-12 Andrew Burgess <aburgess@redhat.com> 1273 1274 Update copyright year range in header of all files managed by GDB 1275 This commit is the result of the following actions: 1276 1277 - Running gdb/copyright.py to update all of the copyright headers to 1278 include 2024, 1279 1280 - Manually updating a few files the copyright.py script told me to 1281 update, these files had copyright headers embedded within the 1282 file, 1283 1284 - Regenerating gdbsupport/Makefile.in to refresh it's copyright 1285 date, 1286 1287 - Using grep to find other files that still mentioned 2023. If 1288 these files were updated last year from 2022 to 2023 then I've 1289 updated them this year to 2024. 1290 1291 I'm sure I've probably missed some dates. Feel free to fix them up as 1292 you spot them. 1293 12942024-01-12 Andrew Carlotti <andrew.carlotti@arm.com> 1295 1296 aarch64: Remove unused code 1297 Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was 1298 already dead when it was first added. 1299 1300 aarch64: Make FEAT_ASMv8p2 instruction aliases always available 1301 There's no reason to disallow the aliases when the aliased instructions are 1302 always available. The new behaviour matches existing LLVM behaviour. 1303 1304 aarch64: Add +xs flag for existing instructions 1305 Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of 1306 "+d128". This is an incremental improvement; there are still some FEAT_XS tlbi 1307 variants that are gated incorrectly or missing entirely. 1308 1309 aarch64: Add +wfxt flag for existing instructions 1310 1311 aarch64: Add +rcpc2 flag for existing instructions 1312 1313 aarch64: Add +flagm2 flag for existing instructions 1314 1315 aarch64: Add +frintts flag for existing instructions 1316 1317 aarch64: Add +jscvt flag for existing fjcvtzs instruction 1318 1319 aarch64: Fix option parsing to disallow prefixes of valid options 1320 Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility 1321 with Clang. 1322 1323 aarch64: Add +fcma alias for +compnum 1324 1325 aarch64: Fix +lse feature flag dependency 1326 13272024-01-12 Andrew Burgess <aburgess@redhat.com> 1328 1329 gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs 1330 This commit updates the Python example code in the gdb.Progspace and 1331 gdb.Objfile sections of the docs. Changes made: 1332 1333 1. Use @value{GDBP} for the GDB prompt rather than 1334 hard-coding (gdB), 1335 1336 2. Use @group...@end group to split the example code into 1337 unbreakable chunks, and 1338 1339 3. Add parenthesis to the Python print() calls in the examples. In 1340 Python 2 it was OK to drop the parenthesis, but now GDB is Python 3 1341 only, example code should include the parenthesis. 1342 1343 Approved-By: Eli Zaretskii <eliz@gnu.org> 1344 Approved-By: Tom Tromey <tom@tromey.com> 1345 13462024-01-12 Andrew Burgess <aburgess@redhat.com> 1347 1348 gdb/doc: add some notes on selecting suitable attribute names 1349 In previous commits I've added Object.__dict__ support to gdb.Inferior 1350 and gdb.InferiorThread, this is similar to the existing support for 1351 gdb.Objfile and gdb.Progspace. 1352 1353 This commit extends the documentation to offer the user some guidance 1354 on selecting good names for their custom attributes so they 1355 can (hopefully) avoid conflicting with any future attributes that GDB 1356 might add. 1357 1358 The rules I've proposed are: 1359 1360 1. Don't start user attributes with a lower case letter, all the 1361 current GDB attributes start with a lower case letter, and I suspect 1362 all future attributes would also start with a lower case letter, and 1363 1364 2. Don't start user attributes with a double underscore, this risks 1365 conflicting with Python built in attributes (e.g. __dict__) - though 1366 clearly the user would need to start and end with a double 1367 underscore, but it seemed easier just to say no double underscores. 1368 1369 I'm doing this as a separate commit as I've updated the docs for the 1370 existing gdb.Objfile and gdb.Progspace so they all reference a single 1371 paragraph on selecting attribute names. 1372 1373 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 1374 Approved-By: Tom Tromey <tom@tromey.com> 1375 13762024-01-12 Andrew Burgess <aburgess@redhat.com> 1377 1378 gdb/python: Add gdb.InferiorThread.__dict__ attribute 1379 The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python 1380 types already have a __dict__ attribute, which allows users to create 1381 user defined attributes within the objects. This is useful if the 1382 user wants to cache information within an object. 1383 1384 This commit adds the same functionality to the gdb.InferiorThread 1385 type. 1386 1387 After this commit there is a new gdb.InferiorThread.__dict__ 1388 attribute, which is a dictionary. A user can, for example, do this: 1389 1390 (gdb) pi 1391 >>> t = gdb.selected_thread() 1392 >>> t._user_attribute = 123 1393 >>> t._user_attribute 1394 123 1395 >>> 1396 1397 There's a new test included. 1398 1399 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 1400 Approved-By: Tom Tromey <tom@tromey.com> 1401 14022024-01-12 Andrew Burgess <aburgess@redhat.com> 1403 1404 gdb/python: Add gdb.Inferior.__dict__ attribute 1405 The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have 1406 a __dict__ attribute, which allows users to create user defined 1407 attributes within the objects. This is useful if the user wants to 1408 cache information within an object. 1409 1410 This commit adds the same functionality to the gdb.Inferior type. 1411 1412 After this commit there is a new gdb.Inferior.__dict__ attribute, 1413 which is a dictionary. A user can, for example, do this: 1414 1415 (gdb) pi 1416 >>> i = gdb.selected_inferior() 1417 >>> i._user_attribute = 123 1418 >>> i._user_attribute 1419 123 1420 >>> 1421 1422 There's a new test included. 1423 1424 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 1425 Approved-By: Tom Tromey <tom@tromey.com> 1426 14272024-01-12 Andrew Burgess <aburgess@redhat.com> 1428 1429 gdb/python: remove users ability to create gdb.Progspace objects 1430 I noticed that it is possible for the user to create a new 1431 gdb.Progspace object, like this: 1432 1433 (gdb) pi 1434 >>> p = gdb.Progspace() 1435 >>> p 1436 <gdb.Progspace object at 0x7ffad4219c10> 1437 >>> p.is_valid() 1438 False 1439 1440 As the new gdb.Progspace object is not associated with an actual C++ 1441 program_space object within GDB core, then the new gdb.Progspace is 1442 created invalid, and there is no way in which the new object can ever 1443 become valid. 1444 1445 Nor do I believe there's anywhere in the Python API where it makes 1446 sense to consume an invalid gdb.Progspace created in this way, for 1447 example, the gdb.Progspace could be passed as the locus to 1448 register_type_printer, but all that would happen is that the 1449 registered printer would never be used. 1450 1451 In this commit I propose to remove the ability to create new 1452 gdb.Progspace objects. Attempting to do so now gives an error, like 1453 this: 1454 1455 (gdb) pi 1456 >>> gdb.Progspace() 1457 Traceback (most recent call last): 1458 File "<stdin>", line 1, in <module> 1459 TypeError: cannot create 'gdb.Progspace' instances 1460 1461 Of course, there is a small risk here that some existing user code 1462 might break ... but if that happens I don't believe the user code can 1463 have been doing anything useful, so I see this as a small risk. 1464 1465 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 1466 Approved-By: Tom Tromey <tom@tromey.com> 1467 14682024-01-12 Andrew Burgess <aburgess@redhat.com> 1469 1470 gdb/python: add gdb.Frame.__repr__() method 1471 Add a gdb.Frame.__repr__() method. Before this patch we would see 1472 output like this: 1473 1474 (gdb) pi 1475 >>> gdb.selected_frame() 1476 <gdb.Frame object at 0x7fa8cc2df270> 1477 1478 After this patch, we now see: 1479 1480 (gdb) pi 1481 >>> gdb.selected_frame() 1482 <gdb.Frame level=0 frame-id={stack=0x7ffff7da0ed0,code=0x000000000040115d,!special}> 1483 1484 More verbose, but, I hope, more useful. 1485 1486 If the gdb.Frame becomes invalid, then we will see: 1487 1488 (gdb) pi 1489 >>> invalid_frame_variable 1490 <gdb.Frame (invalid)> 1491 1492 which is inline with how other invalid objects are displayed. 1493 1494 Approved-By: Tom Tromey <tom@tromey.com> 1495 14962024-01-12 Andrew Burgess <aburgess@redhat.com> 1497 1498 gdb/python: add gdb.InferiorThread.__repr__() method 1499 Add a gdb.InferiorThread.__repr__() method. Before this patch we 1500 would see output like this: 1501 1502 (gdb) pi 1503 >>> gdb.selected_thread() 1504 <gdb.InferiorThread object at 0x7f4dcc49b970> 1505 1506 After this patch, we now see: 1507 1508 (gdb) pi 1509 >>> gdb.selected_thread() 1510 <gdb.InferiorThread id=1.2 target-id="Thread 0x7ffff7da1700 (LWP 458134)"> 1511 1512 More verbose, but, I hope, more useful. 1513 1514 If the gdb.InferiorThread becomes invalid, then we will see: 1515 1516 (gdb) pi 1517 >>> invalid_thread_variable 1518 <gdb.InferiorThread (invalid)> 1519 1520 Which is inline with how other invalid objects are displayed. 1521 1522 Approved-By: Tom Tromey <tom@tromey.com> 1523 15242024-01-12 Andrew Burgess <aburgess@redhat.com> 1525 1526 gdb/python: hoist common invalid object repr code into py-utils.c 1527 Many object types now have a __repr__() function implementation. A 1528 common pattern is that, if an object is invalid, we print its 1529 representation as: <TYPENAME (invalid)>. 1530 1531 I thought it might be a good idea to move the formatting of this 1532 specific representation into a utility function, and then update all 1533 of our existing code to call the new function. 1534 1535 The only place where I haven't made use of the new function is in 1536 unwind_infopy_repr, where we currently return a different string. 1537 This case is a little different as the UnwindInfo is invalid because 1538 it references a frame, and it is the frame itself which is invalid. 1539 That said, I think it would be fine to switch to using the standard 1540 format; if the UnwindInfo references an invalid frame, then the 1541 UnwindInfo is itself invalid. But changing this would be an actual 1542 change in behaviour, while all the other changes in this commit are 1543 just refactoring. 1544 1545 Approved-By: Tom Tromey <tom@tromey.com> 1546 15472024-01-12 Andrew Burgess <aburgess@redhat.com> 1548 1549 gdb: add trailing '/' when using 'complete' with directory names 1550 This patch contains work pulled from this previously proposed patch: 1551 1552 https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/ 1553 1554 But has been modified by me. Credit for the original idea and 1555 implementation goes to Lancelot, any bugs in this new iteration belong 1556 to me. 1557 1558 Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is 1559 empty other than the `foo' sub-directory, then currently within GDB, 1560 if I type: 1561 1562 (gdb) file /tmp/f 1563 1564 and then hit TAB, GDB completes this to: 1565 1566 (gdb) file /tmp/foo/ 1567 1568 notice that not only did GDB fill in the whole of `foo', but GDB also 1569 added a trailing '/' character. This is done within readline when the 1570 path that was just completed is a directory. However, if I instead 1571 do: 1572 1573 (gdb) complete file /tmp/f 1574 file /tmp/foo 1575 1576 I now see the completed directory name, but the trailing '/' is 1577 missing. The reason is that, in this case, the completions are not 1578 offered via readline, but are handled entirely within GDB, and so 1579 readline never gets the chance to add the trailing '/' character. 1580 1581 The above patch added filename option support to GDB, which included 1582 completion of the filename options. This initially suffered from the 1583 same problem that I've outlined above, but the above patch proposed a 1584 solution to this problem, but this solution only applied to filename 1585 options (which have still not been added to GDB), and was mixed in 1586 with the complete filename options support. 1587 1588 This patch pulls out just the fix for the trailing "/" problem, and 1589 applies it to GDB's general filename completion. This patch does not 1590 add filename options to GDB, that can always be done later, but I 1591 think this small part is itself a useful fix. 1592 1593 One of the biggest changes I made in this version is that I got rid of 1594 the set_from_readline member function, instead, I now pass the value 1595 of m_from_readline into the completion_tracker constructor. 1596 1597 I then moved the addition of the trailing '/' into filename_completer 1598 so that it is applied in the general filename completion case. I also 1599 added a call to gdb_tilde_expand which was missing from the original 1600 patch, I haven't tested, but I suspect that this meant that the 1601 original patch would not add the trailing '/' if the user entered a 1602 path starting with a tilde character. 1603 1604 When writing the test for this patch I ran into two problems. 1605 1606 The first was that the procedures in lib/completion-support.exp relied 1607 on the command being completed for the test name. This is fine for 1608 many commands, but not when completing a filename, if we use the 1609 command in this case the test name will (potentially) include the name 1610 of the directory in which the test is being run, which means we can't 1611 compare results between two runs of GDB from different directories. 1612 1613 So in this commit I've gone through completion-support.exp and added a 1614 new (optional) testname argument to many of the procedures, this 1615 allows me to give a unique test name, that doesn't include the path 1616 for my new tests. 1617 1618 The second issue was in the procedure make_tab_completion_list_re, 1619 this builds the completion list which is displayed after a double tab 1620 when there are multiple possible completions. 1621 1622 The procedure added the regexp ' +' after each completion, and then 1623 added another ' +' at the very end of the expected output. So, if we 1624 expected to match the name of two functions 'f1' and 'f2' the 1625 generated regexp would be: 'f1 +f2 + +'. This would match just fine, 1626 the actual output would be: 'f1 f2 ', notice that we get two spaces 1627 after each function name. 1628 1629 However, if we complete two directory names 'd1' and 'd2' then the 1630 output will be 'd1/ d2/ '. Notice that now we only have a single 1631 space between each match, however, we do get the '/' added instead. 1632 1633 What happens is that when presenting the matches, readline always adds 1634 the appropriate trailing character; if we performed tab completion of 1635 'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with 1636 a trailing space added. However, if we complete 'file d1' then we get 1637 'file d1/'. Then readline is adding a single space after each 1638 possible match, including the last one, which accounts for the 1639 trailing space character. 1640 1641 To resolve this I've simply remove the addition o the second ' +' 1642 within make_tab_completion_list_re, for the function completion 1643 example I gave above the expected pattern is now 'f1 +f2 +', which for 1644 the directory case we expect 'd1/ +d2/ +', both of which work just 1645 fine. 1646 1647 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265 1648 Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com> 1649 Approved-By: Tom Tromey <tom@tromey.com> 1650 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 1651 16522024-01-12 Andrew Burgess <aburgess@redhat.com> 1653 1654 gdb/python: New InferiorThread.ptid_string attribute 1655 This commit adds a new InferiorThread.ptid_string attribute. This 1656 read-only attribute contains the string returned by target_pid_to_str, 1657 which actually converts a ptid (not pid) to a string. 1658 1659 This is the string that appears (at least in part) in the output of 1660 'info threads' in the 'Target Id' column, but also in the thread 1661 exited message that GDB prints. 1662 1663 Having access to this string from Python is useful for allowing 1664 extensions identify threads in a similar way to how GDB core would 1665 identify the thread. 1666 1667 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 1668 Approved-By: Tom Tromey <tom@tromey.com> 1669 16702024-01-12 Tom de Vries <tdevries@suse.de> 1671 1672 [gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp 1673 In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is 1674 missing here after the unsupported: 1675 ... 1676 if { ![is_x86_64_m64_target] } { 1677 unsupported "unsupported architecture" 1678 } 1679 ... 1680 and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3 1681 FAILs. 1682 1683 Fix this by simply using require: 1684 ... 1685 require is_x86_64_m64_target 1686 ... 1687 1688 Tested on x86_64-linux and aarch64-linux. 1689 16902024-01-12 Indu Bhagat <indu.bhagat@oracle.com> 1691 1692 gas: sframe: warn when skipping SFrame FDE generation 1693 Fix PR gas/31213. 1694 1695 gas/ 1696 PR gas/31213 1697 * gen-sframe.c (sframe_do_cfi_insn): Add new warning. 1698 1699 gas/testsuite/ 1700 * gas/cfi-sframe/common-empty-1.d: Test the new warning as well. 1701 * gas/cfi-sframe/common-empty-2.d: Likewise. 1702 17032024-01-12 mengqinggang <mengqinggang@loongson.cn> 1704 1705 LoongArch: Fix relaxation overflow caused by section alignment 1706 When deleting NOP instructions addend by .align at second pass, this may cause 1707 the PC decrease but the symbol address to remain unchanged due to section 1708 alignment. 1709 1710 To solve this question, we subtract a maximux alignment of all sections like 1711 RISC-V. 1712 17132024-01-12 Cui, Lili <lili.cui@intel.com> 1714 1715 x86: Fix indentation and use true/false instead of 1/0 1716 gas/ChangeLog: 1717 1718 * config/tc-i386.c (establish_rex): Fix indentation. 1719 (check_EgprOperands): Use true/false instead of 1/0. 1720 17212024-01-12 GDB Administrator <gdbadmin@sourceware.org> 1722 1723 Automatic date update in version.in 1724 17252024-01-11 Simon Marchi <simon.marchi@efficios.com> 1726 1727 gdb: fix frame passed to gdbarch_value_to_register in value_assign 1728 Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum") 1729 introduced an unexpected change in value_assign. It replaced 1730 `get_prev_frame_always (next_frame)` with `next_frame`in the call to 1731 gdbarch_value_to_register. 1732 1733 This is the result of a merge error, since I previously had a patch to 1734 change gdbarch_value_to_register to take the next frame, and later 1735 decided to drop it. Revert that change. 1736 1737 Add a test based on the DWARF assembler to expose the problem and test 1738 the fix. I also tested on ppc64le to make sure the problem reported in 1739 PR 31231 was fixed. 1740 1741 Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6 1742 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231 1743 17442024-01-11 Tom de Vries <tdevries@suse.de> 1745 1746 [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le 1747 On ppc64le-linux, I run into: 1748 ... 1749 (gdb) bt^M 1750 #0 0x00000000100006dc in foobar (J=2)^M 1751 #1 0x000000001000070c in prog ()^M 1752 (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo 1753 ... 1754 1755 The test-case attemps to emulate additional entry points of a function, with 1756 function bar having entry points foo and foobar: 1757 ... 1758 (gdb) p bar 1759 $1 = {void (int, int)} 0x1000064c <bar> 1760 (gdb) p foo 1761 $2 = {void (int, int)} 0x10000698 <foo> 1762 (gdb) p foobar 1763 $3 = {void (int)} 0x100006d0 <foobar> 1764 ... 1765 1766 However, when setting a breakpoint on the entry point foo: 1767 ... 1768 (gdb) b foo 1769 Breakpoint 1 at 0x100006dc 1770 ... 1771 it ends up in foobar instead of in foo, due to prologue skipping, and 1772 consequently the backtrace show foobar instead foo. 1773 1774 The problem is that the test-case does not emulate an actual prologue at each 1775 entry point. 1776 1777 Fix this by disabling the prologue skipping when setting a breakpoint, using 1778 "break *foo". 1779 1780 Tested on ppc64le-linux and x86_64-linux. 1781 1782 Tested-By: Guinevere Larsen <blarsen@redhat.com> 1783 Approved-By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com> 1784 1785 PR testsuite/31232 1786 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 1787 17882024-01-11 Tom de Vries <tdevries@suse.de> 1789 1790 [gdb/testsuite] Extend gdb.base/kill-during-detach.exp 1791 I ran into the following FAIL: 1792 ... 1793 (gdb) python kill_and_detach()^M 1794 Traceback (most recent call last):^M 1795 File "<string>", line 1, in <module>^M 1796 File "<string>", line 7, in kill_and_detach^M 1797 gdb.error: Selected thread is running.^M 1798 Error while executing Python code.^M 1799 (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \ 1800 python kill_and_detach() 1801 ... 1802 1803 The FAIL happens as follows: 1804 - gdb is debugging a process A 1805 - a checkpoint is created, in other words, fork is called in the inferior, 1806 after which we have: 1807 - checkpoint 0 (the fork parent, process A), and 1808 - checkpoint 1 (the fork child, process B). 1809 - during checkpoint creation, lseek is called in the inferior (process A) for 1810 all file descriptors, and it returns != -1 for at least one file descriptor. 1811 - the process A continues in the background 1812 - gdb detaches, from process A 1813 - gdb switches to process B, in other words, it restarts checkpoint 1 1814 - while restarting checkpoint 1, gdb tries to call lseek in the inferior 1815 (process B), but this fails because gdb incorrectly thinks that inferior B 1816 is running. 1817 1818 This happens because linux_nat_switch_fork patches the pid of process B into 1819 the current inferior and current thread which where originally representing 1820 process A. So, because process A was running in the background, the 1821 thread_info fields executing and resumed are set accordingly, but they are not 1822 correct for process B. 1823 1824 There's a line in fork_load_infrun_state that fixes up the thread_info field 1825 stop_pc, so fix this by adding similar fixups for the executing and resumed 1826 fields alongside. 1827 1828 The FAIL did not always reproduce, so extend the test-case to reliably 1829 trigger this scenario. 1830 1831 Tested on x86_64-linux. 1832 1833 Approved-By: Kevin Buettner <kevinb@redhat.com> 1834 1835 PR gdb/31203 1836 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203 1837 18382024-01-11 changjiachen <changjiachen@stu.xupt.edu.cn> 1839 1840 LoongArch: ld: Adjusted some code order in relax.exp. 1841 ld/testsuite/ChangeLog: 1842 1843 * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test. 1844 18452024-01-11 Lulu Cai <cailulu@loongson.cn> 1846 1847 LoongArch: Discard extra spaces in objdump output 1848 Due to the formatted output of objdump, some instructions 1849 that do not require output operands (such as nop/ret) will 1850 have extra spaces added after them. 1851 1852 Determine whether to output operands through the format 1853 of opcodes. When opc->format is an empty string, no extra 1854 spaces are output. 1855 18562024-01-11 Mike Frysinger <vapier@gentoo.org> 1857 1858 sim: ppc: return register error when unhandled 1859 We don't want to fallthru and use cooked_buf when we haven't initialized 1860 it to anything. Returning 0 indicates the register wasn't recognized. 1861 1862 sim: m32r: enable warnings in traps.c 1863 File should be clean now! 1864 18652024-01-11 Mike Frysinger <vapier@gentoo.org> 1866 1867 sim: m32r: fixup some of the int<->pointer casts 1868 The m32r trap code was written for a 32-bit Linux host (and really, one 1869 whose Linux ABI matched pretty exactly). This has lead to conversions 1870 between integers and pointers which breaks down hard on 64-bit hosts. 1871 1872 Clean up some of the functions where possible to avoid unnecessary 1873 conversions, use uintptr_t to cast 32-bit target pointers to host 1874 pointers in some places, and just stub out a few functions that can't 1875 easily be salvaged currently when sizeof(void*) is not 32-bits. This 1876 is a bit ugly, but lets us enable warnings for the whole file. 1877 18782024-01-11 Mike Frysinger <vapier@gentoo.org> 1879 1880 sim: m32r: fix missing break statement 1881 The ftime syscall should not fallthrough to the sync syscall. 1882 Clearly the code was missing a break statement. 1883 18842024-01-11 Mike Frysinger <vapier@gentoo.org> 1885 1886 sim: m32r: migrate ftime() to clock_gettime() 1887 The ftime() function has been deprecated since POSIX-1-2004, and 1888 removed in POSIX.1-2008. It's also been deprecated/removed in glibc 1889 since 2.33. POSIX has always said the function is not portable, and 1890 its return value, timezone, and dstflag fields are unspecified. Even 1891 if Linux/glibc & m32r had defined behavior, those aren't the host for 1892 the sim runtime. 1893 1894 So let's stop using the function and switch to clock_gettime. gnulib 1895 already has detection support for it, and it's been around since at 1896 least POSIX-1-2004. 1897 18982024-01-11 Mike Frysinger <vapier@gentoo.org> 1899 1900 sim: m32r: cleanup unused variables 1901 We've been building this file with -Wno-error, so clean up unused 1902 variable warnings. 1903 1904 sim: igen: add printf attributes to the prototypes too 1905 While gcc propagates the printf attribute via the typedef, clang 1906 doesn't seem to, so add it to the prototypes themselves too. We 1907 still keep it on the prototype for cases where it's used as a 1908 variable. 1909 19102024-01-11 Mike Frysinger <vapier@gentoo.org> 1911 1912 gdbsupport: tighten up libiberty code a bit with dnl 1913 No functional change here, just touch up generated output slightly. 1914 1915 Approved-By: Tom Tromey <tom@tromey.com> 1916 19172024-01-11 Mike Frysinger <vapier@gentoo.org> 1918 1919 sim: build: switch to gdbsupport/libiberty.m4 1920 Leverage this common logic to find all the libiberty settings rather 1921 than duplicate it ourselves. 1922 1923 sim: ppc: rework defines.h to handle HAVE symbols defined to 0 1924 The HAVE_DECL_xxx defines are always defined to 0 or 1. The current 1925 defines.h logic assumes every HAVE_xxx symbol is only defined iff it's 1926 defined to 1 which causes this to break. Tweak the sed logic to only 1927 match defines of 1. 1928 19292024-01-11 Mike Frysinger <vapier@gentoo.org> 1930 1931 gdb: libiberty: switch to AC_CHECK_DECLS_ONCE 1932 Only check these decls once in case other m4 macros also look for them. 1933 1934 Approved-By: Tom Tromey <tom@tromey.com> 1935 19362024-01-11 Mike Frysinger <vapier@gentoo.org> 1937 1938 gdb: move libiberty.m4 to gdbsupport 1939 This is used by gdb, gdbsupport, and gdbserver. We want to use it 1940 in the sim tree too. Move it to gdbsupport which is meant as the 1941 common sharing space for these projects. 1942 1943 Approved-By: Tom Tromey <tom@tromey.com> 1944 19452024-01-11 GDB Administrator <gdbadmin@sourceware.org> 1946 1947 Automatic date update in version.in 1948 19492024-01-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1950 1951 gprofng: add an examples directory 1952 This directory contains example programs for the user to experiment with. 1953 Initially there is one application written in C. The plan is to include 1954 more examples, also in other langauges, over time. 1955 In addition to the sources and a make file, a sample script how to make 1956 a profile is included. There is also a README.md file. 1957 1958 gprofng/ChangeLog 1959 2024-01-08 Ruud van der Pas <ruud.vanderpas@oracle.com> 1960 1961 * examples: Top level directory. 1962 * examples/mxv-pthreads: Example program written in C. 1963 19642024-01-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1965 1966 gprofng: 31123 improvements to hardware event implementation 1967 Our hardware counter profiling is based on perf_event_open(). 1968 Our HWC tables are absent for new machines. 1969 I have added HWC tables for the following events: PERF_TYPE_HARDWARE, 1970 PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. 1971 1972 Did a little cleaning: marked the symbols as static, used Stringbuilder, 1973 created a function to read /proc/cpuinfo. 1974 1975 gprofng/ChangeLog 1976 2024-01-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 1977 1978 PR gprofng/31123 1979 * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. 1980 * common/hwc_cpus.h: Declare a new function read_cpuinfo. 1981 * common/hwcdrv.c: Add a new parameter in init_perf_event(). 1982 * common/hwcentry.h: Add use_perf_event_type in Hwcentry. 1983 * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, 1984 type, config. 1985 * common/hwctable.c: Add a new HWC table generic_list[]. 1986 * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. 1987 * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). 1988 Add a new function read_cpuinfo. 1989 19902024-01-10 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 1991 1992 Fix AIX catchpoint warning during fork () event 1993 In AIX we were missing some hooks needed to catch a fork () event 1994 in rs6000-aix-nat.c. Due to their absence we were returning 1 while we 1995 insert the breakpoint/catchpoint location. This patch is a fix to the same. 1996 19972024-01-10 Nick Clifton <nickc@redhat.com> 1998 1999 Sync top level configure and makefiles 2000 This update brings in the following commits from the gcc mainline: 2001 2002 commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f 2003 Author: Tom Tromey <tom@tromey.com> 2004 Date: Tue Jan 9 06:25:26 2024 -0700 2005 2006 Pass GUILE down to subdirectories 2007 2008 When I enable cgen rebuilding in the binutils-gdb tree, the default is 2009 to run cgen using 'guile'. However, on my host, guile is guile 2.2, 2010 which doesn't work for me -- I have to use guile3.0. 2011 2012 This patch arranges to pass "GUILE" down to subdirectories, so I can 2013 use 'make GUILE=guile3.0'. 2014 2015 commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb 2016 Author: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com> 2017 Date: Wed Oct 25 13:06:48 2023 +0200 2018 2019 build: Add libgrust as compilation modules 2020 2021 Define the libgrust directory as a host compilation module as well as 2022 for targets. Disable target libgrust if we're not building target 2023 libstdc++. 2024 2025 commit 56ca59a03150cf44cea340f58967c990ed6bf43c 2026 Author: Lewis Hyatt <lhyatt@gmail.com> 2027 Date: Thu Nov 16 11:18:37 2023 -0500 2028 2029 Makefile.tpl: Avoid race condition in generating site.exp from the top level 2030 2031 A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of 2032 a fresh build directory does not work reliably. That will spawn two 2033 independent make processes inside the "gcc" directory, and each of those 2034 will attempt to create site.exp if it doesn't exist and will interfere with 2035 each other, producing often a corrupted or empty site.exp. Resolve that by 2036 making these targets depend on a new phony target which makes sure site.exp 2037 is created first before starting the recursive makes. 2038 2039 commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1 2040 Author: Iain Sandoe <iain@sandoe.co.uk> 2041 Date: Sun Mar 28 14:48:17 2021 +0100 2042 2043 Config,Darwin: Allow for configuring Darwin to use embedded runpath. 2044 2045 Recent Darwin versions place contraints on the use of run paths 2046 specified in environment variables. This breaks some assumptions 2047 in the GCC build. 2048 2049 This change allows the user to configure a Darwin build to use 2050 '@rpath/libraryname.dylib' in library names and then to add an 2051 embedded runpath to executables (and libraries with dependents). 2052 2053 The embedded runpath is added by default unless the user adds 2054 '-nodefaultrpaths' to the link line. 2055 2056 For an installed compiler, it means that any executable built with 2057 that compiler will reference the runtimes installed with the 2058 compiler (equivalent to hard-coding the library path into the name 2059 of the library). 2060 2061 During build-time configurations any "-B" entries will be added to 2062 the runpath thus the newly-built libraries will be found by exes. 2063 2064 Since the install name is set in libtool, that decision needs to be 2065 available here (but might also cause dependent ones in Makefiles, 2066 so we need to export a conditional). 2067 2068 This facility is not available for Darwin 8 or earlier, however the 2069 existing environment variable runpath does work there. 2070 2071 We default this on for systems where the external DYLD_LIBRARY_PATH 2072 does not work and off for Darwin 8 or earlier. For systems that can 2073 use either method, if the value is unset, we use the default (which 2074 is currently DYLD_LIBRARY_PATH). 2075 2076 commit 2551e10038a70901f30b2168e6e3af4536748f3c 2077 Author: Sergei Trofimovich <siarheit@google.com> 2078 Date: Mon Oct 2 12:08:17 2023 +0100 2079 2080 Makefile.tpl: disable -Werror for feedback stage [PR111663] 2081 2082 Without the change profiled bootstrap fails for various warnings on 2083 master branch as: 2084 2085 $ ../gcc/configure 2086 $ make profiledbootstrap 2087 ... 2088 gcc/genmodes.cc: In function ‘int main(int, char**)’: 2089 gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] 2090 ... 2091 gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: 2092 gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] 2093 2094 The change removes -Werror just like autofeedback does today. 2095 2096 commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a 2097 Author: Thomas Schwinge <thomas@codesourcery.com> 2098 Date: Thu Jun 1 23:07:37 2023 +0200 2099 2100 Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] 2101 2102 ..., where we need to use it (separate commits) for build-tree testing, similar 2103 to 'gcc/Makefile.in:site.exp': 2104 2105 # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation. 2106 # They are passed first to allow individual tests to override them. 2107 @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp 2108 2109 PR testsuite/109951 2110 * Makefile.tpl (BASE_TARGET_EXPORTS): Add 2111 'SYSROOT_CFLAGS_FOR_TARGET'. 2112 * Makefile.in: Regenerate. 2113 21142024-01-10 Saurabh Jha <saurabh.jha@arm.com> 2115 2116 gas: aarch64: Add system registers for Debug and PMU extensions 2117 This patch adds support for the new AArch64 system registers that are part of the following extensions: 2118 * FEAT_DEBUGv8p9 2119 * FEAT_PMUv3p9 2120 * FEAT_PMUv3_SS 2121 * FEAT_PMUv3_ICNTR 2122 * FEAT_SEBEP 2123 21242024-01-10 Tom de Vries <tdevries@suse.de> 2125 2126 [gdb] Fix assertion failure for checkpoint delete 0 2127 When doing "checkpoint delete 0" we run into an assertion failure: 2128 ... 2129 +delete checkpoint 0 2130 inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed. 2131 ... 2132 2133 Fix this by handling the "pptid == null_ptid" case in 2134 delete_checkpoint_command. 2135 2136 Tested on x86_64-linux. 2137 2138 Approved-By: Kevin Buettner <kevinb@redhat.com> 2139 2140 PR gdb/31209 2141 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209 2142 21432024-01-10 Tom de Vries <tdevries@suse.de> 2144 2145 [gdb] Fix info checkpoints 2146 Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info 2147 checkpoints command: 2148 ... 2149 (gdb) info checkpoints^M 2150 * 0 process 30570 (main process) at 0x0^M 2151 1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M 2152 2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M 2153 3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M 2154 4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M 2155 5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M 2156 6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M 2157 7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M 2158 8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M 2159 9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M 2160 10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M 2161 ... 2162 2163 According to the docs, each of these (0-10) is a checkpoint. 2164 2165 But the pc address (as well as the file name and line number) is missing for 2166 checkpoint 0. 2167 2168 Fix this by sampling the pc value for the current process in 2169 info_checkpoints_command, such that we have instead: 2170 ... 2171 * 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M 2172 ... 2173 2174 Tested on x86_64-linux. 2175 2176 Approved-By: Kevin Buettner <kevinb@redhat.com> 2177 2178 PR gdb/31211 2179 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211 2180 21812024-01-10 Tom de Vries <tdevries@suse.de> 2182 2183 [gdb] Make variable printed bool in info_checkpoints_command 2184 While reading info_checkpoints_command, I noticed variable printed: 2185 ... 2186 const fork_info *printed = NULL; 2187 ... 2188 for (const fork_info &fi : fork_list) 2189 { 2190 if (requested > 0 && fi.num != requested) 2191 continue; 2192 2193 printed = &fi; 2194 ... 2195 } 2196 if (printed == NULL) 2197 ... 2198 has pointer type, but is just used as bool. 2199 2200 Make this explicit by changing the variable type to bool. 2201 2202 Tested on x86_64-linux. 2203 2204 Approved-By: Kevin Buettner <kevinb@redhat.com> 2205 22062024-01-10 Tom de Vries <tdevries@suse.de> 2207 2208 gdb/symtab: Eliminate deferred_entry 2209 Currently cooked_index entry creation is either: 2210 - done immediately if the parent_entry is known, or 2211 - deferred if the parent_entry is not yet known, and done later while 2212 resolving the deferred entries. 2213 2214 Instead, create all cooked_index entries immediately, and keep track of which 2215 entries have a parent_entry that needs resolving later using the new 2216 IS_PARENT_DEFERRED flag. 2217 2218 Tested on x86_64-linux. 2219 2220 Approved-By: Tom Tromey <tom@tromey.com> 2221 22222024-01-10 Tom de Vries <tdevries@suse.de> 2223 2224 gdb/symtab: Make cooked_index_entry::parent_entry private 2225 Make cooked_index_entry::parent_entry private, and add member functions to 2226 access it. 2227 2228 Tested on x86_64-linux and ppc64le-linux. 2229 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 2230 Approved-By: Tom Tromey <tom@tromey.com> 2231 22322024-01-10 Tom de Vries <tdevries@suse.de> 2233 2234 gdb/symtab: Allow changing of added cooked_index entries 2235 Make cooked_index_storage::add and cooked_index_entry::add return a 2236 "cooked_index_entry *" instead of a "const cooked_index_entry *". 2237 2238 Tested on x86_64-linux and ppc64le-linux. 2239 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 2240 Approved-By: Tom Tromey <tom@tromey.com> 2241 22422024-01-10 Tom Tromey <tom@tromey.com> 2243 2244 Fix ASAN failure in DWO code 2245 Simon pointed out that my recent change to the DWO code caused a 2246 failure in ASAN testing. 2247 2248 The bug here was I updated the code to use a different search type in 2249 the hash table; but then did not change the search code to use 2250 htab_find_slot_with_hash. 2251 2252 Note that this bug would not be possible with my type-safe hash table 2253 series, hint, hint. 2254 2255 Approved-By: Simon Marchi <simon.marchi@efficios.com> 2256 22572024-01-10 GDB Administrator <gdbadmin@sourceware.org> 2258 2259 Automatic date update in version.in 2260 22612024-01-09 Tom Tromey <tom@tromey.com> 2262 2263 Fix thread-less build 2264 A user pointed out that the recent background DWARF reader series 2265 broke the build when --disable-threading is in use. This patch fixes 2266 the problem. I am checking it in. 2267 2268 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223 2269 22702024-01-09 Tom Tromey <tom@tromey.com> 2271 2272 Pass GUILE down to subdirectories 2273 When I enable cgen rebuilding in the binutils-gdb tree, the default is 2274 to run cgen using 'guile'. However, on my host, guile is guile 2.2, 2275 which doesn't work for me -- I have to use guile3.0. 2276 2277 This patch arranges to pass "GUILE" down to subdirectories, so I can 2278 use 'make GUILE=guile3.0'. 2279 2280 * Makefile.in: Rebuild. 2281 * Makefile.tpl (BASE_EXPORTS): Add GUILE. 2282 (GUILE): New variable. 2283 * Makefile.def (flags_to_pass): Add GUILE. 2284 22852024-01-09 H.J. Lu <hjl.tools@gmail.com> 2286 2287 ld: Add --enable-mark-plt configure option 2288 Add --enable-mark-plt linker configure option to mark PLT entries with 2289 DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by 2290 default. 2291 2292 * NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt. 2293 * config.in: Regenerated. 2294 * configure: Likewise. 2295 * configure.ac: Add --enable-mark-plt. 2296 (DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED. 2297 * emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT): 2298 Support DEFAULT_LD_Z_MARK_PLT. 2299 * emultempl/elf-x86.em (elf_x86_64_before_parse): New function. 2300 (LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for 2301 x86-64 targets. 2302 23032024-01-09 H.J. Lu <hjl.tools@gmail.com> 2304 2305 elf: Add elf_backend_add_glibc_version_dependency 2306 When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and 2307 DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation 2308 stores the offset of the indirect branch instruction. However, glibc 2309 versions which don't have this commit in glibc 2.36: 2310 2311 commit f8587a61892cbafd98ce599131bf4f103466f084 2312 Author: H.J. Lu <hjl.tools@gmail.com> 2313 Date: Fri May 20 19:21:48 2022 -0700 2314 2315 x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT 2316 2317 According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT 2318 and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we 2319 can ignore their r_addends. 2320 2321 Reviewed-by: Fangrui Song <maskray@google.com> 2322 2323 won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. 2324 Although this commit has been backported to glibc 2.33/2.34/2.35 release 2325 branches, it is safer to require glibc 2.36 for such binaries. 2326 2327 Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to 2328 also add GLIBC_2.36 version dependency for -z mark-plt on the shared C 2329 library if it provides a GLIBC_2.XX symbol version. 2330 2331 * elflink.c (elf_find_verdep_info): Moved to ... 2332 * elf-bfd.h (elf_find_verdep_info): Here. 2333 (elf_backend_data): Add elf_backend_add_glibc_version_dependency. 2334 (_bfd_elf_link_add_glibc_version_dependency): New function. 2335 (_bfd_elf_link_add_dt_relr_dependency): Likewise. 2336 * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): 2337 Likewise. 2338 (elf_backend_add_glibc_version_dependency): New. 2339 * elflink.c (elf_link_add_dt_relr_dependency): Renamed to ... 2340 (elf_link_add_glibc_verneed): This. Modified to support other 2341 glibc dependencies. 2342 (_bfd_elf_link_add_glibc_version_dependency): Likewise. 2343 (_bfd_elf_link_add_dt_relr_dependency): Likewise. 2344 (bfd_elf_size_dynamic_sections): Call 2345 elf_backend_add_glibc_version_dependency instead of 2346 elf_link_add_dt_relr_dependency. 2347 * elfxx-target.h (elf_backend_add_glibc_version_dependency): New. 2348 (elfNN_bed): Add elf_backend_add_glibc_version_dependency. 2349 2350 ld/ 2351 2352 * testsuite/ld-x86-64/mark-plt-1a.rd: New file. 2353 * testsuite/ld-x86-64/mark-plt-1b.rd: Likewise. 2354 * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for 2355 GLIBC_2.36 dependency. 2356 23572024-01-09 H.J. Lu <hjl.tools@gmail.com> 2358 2359 x86: Don't check R_386_NONE nor R_X86_64_NONE 2360 Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning 2361 relocations. 2362 2363 bfd/ 2364 2365 * PR ld/31047 2366 * elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE. 2367 * elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check 2368 R_X86_64_NONE. 2369 2370 ld/ 2371 2372 * PR ld/31047 2373 * testsuite/ld-i386/i386.exp: Run PR ld/31047 test. 2374 * testsuite/ld-x86-64/x86-64.exp: Likewise. 2375 * testsuite/ld-i386/pr31047.d: New file. 2376 * testsuite/ld-x86-64/pr31047-x32.d: Likewise. 2377 * testsuite/ld-x86-64/pr31047.d: Likewise. 2378 * testsuite/ld-x86-64/pr31047a.s: Likewise. 2379 * testsuite/ld-x86-64/pr31047b.s: Likewise. 2380 23812024-01-09 Tom Tromey <tromey@adacore.com> 2382 2383 Fix two bugs in gdbserver thread name handling 2384 Simon pointed out that my earlier patch to gdbserver's thread name 2385 code: 2386 2387 commit 07b3255c3bae7126a0d679f957788560351eb236 2388 Author: Tom Tromey <tom@tromey.com> 2389 Date: Thu Jul 13 17:28:48 2023 -0600 2390 2391 Filter invalid encodings from Linux thread names 2392 2393 ... introduced a regression. This bug was that the iconv output was 2394 not \0-terminated. 2395 2396 Looking at it, I found another bug as well -- replace_non_ascii would 2397 not \0-terminate, and also would return the wrong pointer 2398 2399 This patch fixes both of them. 2400 2401 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153 2402 24032024-01-09 Tom Tromey <tromey@adacore.com> 2404 2405 Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu 2406 dwarf2_base_index_functions::find_per_cu is documented as using an 2407 unrelocated address. This patch changes the interface to use the 2408 unrelocated_addr type, just to be a bit more type-safe. 2409 2410 Regression tested on x86-64 Fedora 38. 2411 24122024-01-09 Jan Beulich <jbeulich@suse.com> 2413 2414 x86: add missing APX logic to cpu_flags_match() 2415 As already indicated during review, we can't get away without certain 2416 adjustments here: Without these, respective {evex}-prefixed insns are 2417 assembled to APX encodings even when APX_F is turned off. 2418 2419 While there also extend the respective comment in the opcode table, to 2420 explain why this construct is used. 2421 24222024-01-09 Jan Beulich <jbeulich@suse.com> 2423 2424 x86: FMA insns aren't eligible to VEX2 encoding 2425 PR gas/31178 2426 2427 In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked 2428 that C aliases StaticRounding, and hence build_vex_prefix() now needs to 2429 be aware of that aliasing. Disambiguation is easy, as StaticRounding is 2430 only ever used together with SAE (hence why the overlaying works in the 2431 first place). 2432 24332024-01-09 Jan Beulich <jbeulich@suse.com> 2434 2435 PPC64/ELF: adjust comment wrt ABI versions 2436 While having been moved a couple of times since its introduction in 2437 f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"), 2438 the wording has always remained the same. In particular ELFv1 and ELFv2 2439 have always been the wrong way round. 2440 24412024-01-09 Nick Clifton <nickc@redhat.com> 2442 2443 Synchronize sourceware version of the libiberty sources with the master gcc versions. 2444 This brings in the following commits: 2445 2446 commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a 2447 Author: Jakub Jelinek <jakub@redhat.com> 2448 Date: Tue Dec 5 23:32:19 2023 +0100 2449 2450 libiberty: Fix build with GCC < 7 2451 2452 Tobias reported on IRC that the linker fails to build with GCC 4.8.5. 2453 In configure I've tried to use everything actually used in the sha1.c 2454 x86 hw implementation, but unfortunately I forgot about implicit function 2455 declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define 2456 and __get_cpuid function defined inline, but it didn't define 2457 __get_cpuid_count, which compiled fine (and the configure test is 2458 intentionally compile time only) due to implicit function declaration, 2459 but then failed to link when linking the linker, because 2460 __get_cpuid_count wasn't defined anywhere. 2461 2462 The following patch fixes that by using what autoconf uses in AC_CHECK_DECL 2463 to make sure the functions are declared. 2464 2465 commit 691858d279335eeeeed3afafdf872b1c5f8f4201 2466 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 2467 Date: Tue Dec 5 11:04:06 2023 +0100 2468 2469 libiberty: Fix pex_unix_wait return type 2470 2471 The recent warning patches broke Solaris bootstrap: 2472 2473 /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] 2474 326 | pex_unix_wait, 2475 | ^~~~~~~~~~~~~ 2476 /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') 2477 2478 While pex_funcs.wait expects a function returning pid_t, pex_unix_wait 2479 currently returns int. However, on Solaris pid_t is long for 32-bit, 2480 but int for 64-bit. 2481 2482 This patches fixes this by having pex_unix_wait return pid_t as 2483 expected, and like every other variant already does. 2484 2485 Bootstrapped without regressions on i386-pc-solaris2.11, 2486 sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and 2487 x86_64-apple-darwin23.1.0. 2488 2489 commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 2490 Author: Jason Merrill <jason@redhat.com> 2491 Date: Mon Sep 25 10:15:02 2023 +0100 2492 2493 c++: mangle function template constraints 2494 2495 Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and 2496 https://github.com/itanium-cxx-abi/cxx-abi/pull/166 2497 2498 We need to mangle constraints to be able to distinguish between function 2499 templates that only differ in constraints. From the latter link, we want to 2500 use the template parameter mangling previously specified for lambdas to also 2501 make explicit the form of a template parameter where the argument is not a 2502 "natural" fit for it, such as when the parameter is constrained or deduced. 2503 2504 I'm concerned about how the latter link changes the mangling for some C++98 2505 and C++11 patterns, so I've limited template_parm_natural_p to avoid two 2506 cases found by running the testsuite with -Wabi forced on: 2507 2508 template <class T, T V> T f() { return V; } 2509 int main() { return f<int,42>(); } 2510 2511 template <int i> int max() { return i; } 2512 template <int i, int j, int... rest> int max() 2513 { 2514 int sub = max<j, rest...>(); 2515 return i > sub ? i : sub; 2516 } 2517 int main() { return max<1,2,3>(); } 2518 2519 A third C++11 pattern is changed by this patch: 2520 2521 template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); 2522 template <typename> struct A { }; 2523 int main() { f<A,int>(); } 2524 2525 I aim to resolve these with the ABI committee before GCC 14.1. 2526 2527 We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38 2528 (mangling references to dependent template-ids where the name is fully 2529 resolved) as references to concepts in std:: will consistently run into this 2530 area. This is why mangle-concepts1.C only refers to concepts in the global 2531 namespace so far. 2532 2533 The library changes are to avoid trying to mangle builtins, which fails. 2534 2535 Demangler support and test coverage is not complete yet. 2536 2537 commit f2c52c0dfde581461959b0e2b423ad106aadf179 2538 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 2539 Date: Thu Nov 30 10:06:23 2023 +0100 2540 2541 libiberty: Disable hwcaps for sha1.o 2542 2543 This patch 2544 2545 commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e 2546 Author: Jakub Jelinek <jakub@redhat.com> 2547 Date: Tue Nov 28 13:14:05 2023 +0100 2548 2549 libiberty: Use x86 HW optimized sha1 2550 2551 broke Solaris/x86 bootstrap with the native as: 2552 2553 libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go 2554 ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ] 2555 gccgo: fatal error: Killed signal terminated program go1 2556 2557 As is already done in a couple of other similar cases, this patches 2558 disables hwcaps support for libiberty. 2559 2560 Initially, this didn't work because config/hwcaps.m4 uses target_os, but 2561 didn't ensure it is defined. 2562 2563 Tested on i386-pc-solaris2.11 with as and gas. 2564 2565 commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e 2566 Author: Jakub Jelinek <jakub@redhat.com> 2567 Date: Tue Nov 28 13:14:05 2023 +0100 2568 2569 libiberty: Use x86 HW optimized sha1 2570 2571 Nick has approved this patch (+ small ld change to use it for --build-id=), 2572 so I'm commiting it to GCC as master as well. 2573 2574 If anyone from ARM would be willing to implement it similarly with 2575 vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker 2576 speedup on those hosts as well, the intent in sha1.c was that 2577 sha1_hw_process_bytes, sha1_hw_process_block functions 2578 would be defined whenever 2579 defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) 2580 but the body of sha1_hw_process_block and sha1_choose_process_bytes 2581 would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for 2582 the other arch support, similarly for any target attributes on 2583 sha1_hw_process_block if needed. 2584 2585 commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942 2586 Author: Mark Wielaard <mjw@redhat.com> 2587 Date: Wed Nov 15 20:27:08 2023 +0100 2588 2589 Regenerate libiberty/aclocal.m4 with aclocal 1.15.1 2590 2591 There is a new buildbot check that all autotool files are generated 2592 with the correct versions (automake 1.15.1 and autoconf 2.69). 2593 https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen 2594 2595 Correct one file that was generated with the wrong version. 2596 2597 commit 879cf9ff45d94065d89e24b71c6b27c7076ac518 2598 Author: Brendan Shanks <bshanks@codeweavers.com> 2599 Date: Thu Nov 9 21:01:07 2023 -0700 2600 2601 [PATCH v3] libiberty: Use posix_spawn in pex-unix when available. 2602 2603 Hi, 2604 2605 This patch implements pex_unix_exec_child using posix_spawn when 2606 available. 2607 2608 This should especially benefit recent macOS (where vfork just calls 2609 fork), but should have equivalent or faster performance on all 2610 platforms. 2611 In addition, the implementation is substantially simpler than the 2612 vfork+exec code path. 2613 2614 Tested on x86_64-linux. 2615 2616 v2: Fix error handling (previously the function would be run twice in 2617 case of error), and don't use a macro that changes control flow. 2618 2619 v3: Match file style for error-handling blocks, don't close 2620 in/out/errdes on error, and check close() for errors. 2621 2622 commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450 2623 Author: Jason Merrill <jason@redhat.com> 2624 Date: Thu Aug 17 11:36:23 2023 -0400 2625 2626 c++: constrained hidden friends [PR109751] 2627 2628 r13-4035 avoided a problem with overloading of constrained hidden friends by 2629 checking satisfaction, but checking satisfaction early is inconsistent with 2630 the usual late checking and can lead to hard errors, so let's not do that 2631 after all. 2632 2633 We were wrongly treating the different instantiations of the same friend 2634 template as the same function because maybe_substitute_reqs_for was failing 2635 to actually substitute in the case of a non-template friend. But we don't 2636 actually need to do the substitution anyway, because [temp.friend] says that 2637 such a friend can't be the same as any other declaration. 2638 2639 After fixing that, instead of a redefinition error we got an ambiguous 2640 overload error, fixed by allowing constrained hidden friends to coexist 2641 until overload resolution, at which point they probably won't be in the same 2642 ADL overload set anyway. 2643 2644 And we avoid mangling collisions by following the proposed mangling for 2645 these friends as a member function with an extra 'F' before the name. I 2646 demangle this by just adding [friend] to the name of the function because 2647 it's not feasible to reconstruct the actual scope of the function since the 2648 mangling ABI doesn't distinguish between class and namespace scopes. 2649 2650 PR c++/109751 2651 26522024-01-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 2653 2654 aarch64: ADD FEAT_THE RCWCAS instructions. 2655 This patch adds support for FEAT_THE doubleword and quadword instructions. 2656 doubleword insturctions are enabled by "+the" flag whereas quadword 2657 instructions are enabled on passing both "+the and +d128" flags. 2658 2659 Support for following sets of instructions is added in this patch. 2660 Read check write compare and swap doubleword: 2661 (rcwcas, rcwcasa, rcwcasal, rcwcasl) 2662 Read check write compare and swap quadword: 2663 (rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl) 2664 Read check write software compare and swap doubleword: 2665 (rcwscas, rcwscasa, rcwscasal, rcwscasl) 2666 Read check write software compare and swap quadword: 2667 (rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl) 2668 Read check write atomic bit clear on doubleword: 2669 (rcwclr, rcwclra, rcwclral, rcwclrl) 2670 Read check write atomic bit clear on quadword: 2671 (rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl) 2672 Read check write software atomic bit clear on doubleword: 2673 (rcwsclr, rcwsclra, rcwsclral, rcwsclrl) 2674 Read check write software atomic bit clear on quadword: 2675 (rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl) 2676 Read check write atomic bit set on doubleword: 2677 (rcwset,rcwseta, rcwsetal,rcwsetl) 2678 Read check write atomic bit set on quadword: 2679 (rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl) 2680 Read check write software atomic bit set on doubleword: 2681 (rcwsset,rcwsseta,rcwssetal,rcwssetl) 2682 Read check write software atomic bit set on quadword: 2683 (rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl) 2684 Read check write swap doubleword: 2685 (rcwswp,rcwswpa,rcwswpal,rcwswpl) 2686 Read check write swap quadword: 2687 (rcwswpp,rcwswppa, rcwswppal,rcwswppl) 2688 Read check write software swap doubleword: 2689 (rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl) 2690 Read check write software swap quadword: 2691 (rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl) 2692 26932024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2694 2695 aarch64: Regenerate aarch64-*-2.c files 2696 26972024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2698 2699 arch64: Add optional operand register pair support tests 2700 Add tests to cover the full range of behaviors observed around 2701 optional register operands for the `tlbip' and `sysp' instructions, 2702 namely: 2703 2704 * Not all `tlbip' operations take GPR operands. When this is the 2705 case, we should check that neither optional operand was supplied. 2706 * When a `tlbip' operation is labeled with the `F_HASXT' flag, xzr 2707 is not a valid optional operand. In such case, at least the fist 2708 optional register needs to be specified with a non-xzr value. 2709 * The first operand for both insns should be either xzr or an 2710 even-numbered register (n % 2 == 0). In the former scenario, the 2711 second operand should default to xzr too, while in the latter, it 2712 should default to n + 1. 2713 27142024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2715 2716 aarch64: Add support for 128-bit system register mrrs and msrr insns 2717 With the addition of 128-bit system registers to the Arm architecture 2718 starting with Armv9.4-a, a mechanism for manipulating their contents 2719 is introduced with the `msrr' and `mrrs' instruction pair. 2720 2721 These move values from one such 128-bit system register into a pair of 2722 contiguous general-purpose registers and vice-versa, as for example: 2723 2724 msrr ttlb0_el1, x0, x1 2725 mrrs x0, x1, ttlb0_el1 2726 2727 This patch adds the necessary support for these instructions, adding 2728 checks for system-register width by defining a new operand type in the 2729 form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p' 2730 predicate, responsible for checking whether the requested system 2731 register table entry is marked as implemented in the 128-bit mode via 2732 the F_REG_128 flag. 2733 27342024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2735 2736 aarch64: Add TLBIP tests 2737 27382024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2739 2740 aarch64: Add xs variants of tlbip operands 2741 The 2020 Architecture Extensions to the Arm A-profile architecture 2742 added FEAT_XS, the XS attribute feature, giving cores the ability to 2743 identify devices which can be subject to long response delays. TLB 2744 invalidate (TLBI) operations and barriers can also be annotated with 2745 this attribute[1]. 2746 2747 With the introduction of the 128-bit translation tables with the 2748 Armv8.9-a/Armv9.4-a Translation Hardening Extension, a series of new 2749 TLB invalidate operations are introduced which make use of this 2750 extension. These are added to aarch64_sys_regs_tlbi[] for use 2751 with the `tlbip' insn. 2752 2753 [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020 2754 27552024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2756 2757 aarch64: Implement TLBIP 128-bit instruction 2758 The addition of 128-bit page table descriptors and, with it, the 2759 addition of 128-bit system registers for these means that special 2760 "invalidate translation table entry" instructions are needed to cope 2761 with the new 128-bit model. This is introduced with the `tlbpi' 2762 instruction, implemented here. 2763 27642024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2765 2766 aarch64: Create QL_SRC_X2 and QL_DEST_X2 qualifier macros 2767 Some 128-bit system operations (mrrs, msrr, tlbip, and sysp) take two 2768 qualified operands and one of unqualified type (e.g. system register 2769 name, tlbip operation). This creates the need for adequate qualifiers 2770 to handle this. 2771 2772 This patch therefore introduces the `QL_SRC_X2' and `QL_DST_X2' qualifier 2773 specifiers, which expand to `QLF3(NIL,X,X)' and `QLF3(X,X,NIL)', 2774 respectively. 2775 27762024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2777 2778 aarch64: Apply narrowing of allowed immediate values for SYSP 2779 While CRn and CRm fields in the SYSP instruction are 4-bit wide and 2780 are thus able to accommodate values in the range 0-15, the 2781 specifications for the SYSP instructions limit their ranges to 8-9 for 2782 CRm and 0-7 in the case of CRn. 2783 2784 This led to the need to signal in some way to the operand parser that 2785 a given operand is under special restrictions regarding its use. This 2786 is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the 2787 range of operand values for fields in the instruction tagged with the 2788 flag. 2789 2790 The flag is then used in `parse_operands' when the instruction is 2791 assembled, but needs not be taken into consideration during 2792 disassembly. 2793 27942024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2795 2796 aarch64: Add support for the SYSP 128-bit system instruction 2797 Mirroring the use of the `sys' - System Instruction assembly 2798 instruction, this implements its 128-bit counterpart, `sysp'. 2799 2800 This optionally takes two contiguous general-purpose registers 2801 starting at an even number or, when these are omitted, by default 2802 sets both of these to xzr. 2803 2804 Syntax: 2805 2806 sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>} 2807 28082024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2809 2810 aarch64: Add support for optional operand pairs 2811 Two of the instructions added by the `+d128' architectural extension 2812 add the flexibility to have two optional operands. Prior to the 2813 addition of the `tlbip' and `sysp' instructions, no mnemonic allowed 2814 more than one such optional operand. 2815 2816 With `tlbip' as an example, some TLBIP instruction names do not allow 2817 for any optional operands, while others allow for both to be optional. 2818 In the latter case, it is possible that either the second operand 2819 alone is omitted or both operands are omitted. 2820 Therefore, a considerable degree of flexibility needed to be added to 2821 the way operands were parsed. It was, however, possible to achieve 2822 this with relatively few changes to existing code. 2823 2824 it is noteworthy that opcode flags specifying the optional operand 2825 number are non-orthogonal. For example, we have: 2826 2827 #define F_OPD1_OPT (2 << 12) : 0b10 << 12 2828 #define F_OPD2_OPT (3 << 12) : 0b11 << 12 2829 2830 such that by virtue of the observation that 2831 2832 (F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT 2833 2834 it is impossible to mark both operands 1 and 2 as optional for an 2835 instruction and it is assumed that a maximum of 1 operand can ever be 2836 optional. This is not overly-problematic given that, for optional 2837 pairs, the second optional operand is always found immediately after 2838 the first. Thus, it suffices for us to flag that there is a second 2839 optional operand. With this fact, we can infer its position in the 2840 mnemonic from the position of the first (e.g. if the second operand in 2841 the mnemonic is optional, we know the third is too). We therefore 2842 define the `F_OPD_PAIR_OPT' flag and calculate its position in the 2843 mnemonic from the value encoded by the `F_OPD<n>_OPT' flag. 2844 2845 Another observation is that there is a tight coupling between default 2846 values assigned to the two registers when one (or both) are omitted 2847 from the mnemonic. Namely, if Xt1 has a value of 0x1f (the zero 2848 register is specified), Xt2 defaults to the same value, otherwise Xt2 2849 will be assigned Xt + 1. This meant that where you have default value 2850 validation, in checking the second optional operand's value, it is 2851 also necessary to look at the value assigned to the 2852 previously-processed operand value before deciding its validity. Thus 2853 `process_omitted_operand' needs not only access to its `operand' 2854 argument, but also to the global `inst' struct. 2855 28562024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2857 2858 aarch64: Add support for xzr register in register pair operands 2859 Analysis of the allowed operand values for `sysp' and `tlbip' reveals 2860 a significant departure from the allowed behavior for operand register 2861 pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other 2862 insns in this category. 2863 2864 For instructions `casp', `mrrs' and `msrr' the register pair must 2865 always start at an even index and the second register in the pair is 2866 the index + 1. This precludes the use of xzr as the first register, 2867 given it corresponds to register number 31. 2868 2869 This is different in the case of `sysp' and `tlbip', however. These 2870 allow the use of xzr and, where the first operand in the pair is 2871 omitted, this is the default value assigned to it. When this 2872 operand is assigned xzr, it is expected that the second operand will 2873 likewise take on a value of xzr. 2874 2875 These two instructions therefore "break" two rules of register pairs: 2876 2877 * The first of the two registers is odd-numbered. 2878 * The index of the second register is equal to that of the first, 2879 and not n+1. 2880 2881 To allow for this departure from hitherto standard behavior, we 2882 extend the functionality of the assembler by defining an extension of 2883 the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR. 2884 2885 It is used in defining `sysp' and `tlbip' and allows 2886 `operand_general_constraint_met_p' to allow the pair to both take on 2887 the value of xzr. 2888 28892024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2890 2891 aarch64: Expand maximum number of operands from 5 to 6 2892 Given the introduction of the new Armv9.4-a `sysp' insn using the 2893 following syntax: 2894 2895 sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>} 2896 2897 and by extension the need to encode 6 assembly operands, extend 2898 Binutils to handle instructions taking 6 operands, up from a previous 2899 maximum of 5. 2900 29012024-01-09 Victor Do Nascimento <victor.donascimento@arm.com> 2902 2903 aarch64: Add +d128 architectural feature support 2904 Indicating the presence of the Armv9.4-a features concerning 128-bit 2905 Page Table Descriptors, 128-bit System Registers and Instructions, 2906 the "+d128" architectural extension flag is added to the list of 2907 possible -march options in Binutils, together with the necessary macro 2908 for encoding d128 instructions. 2909 29102024-01-09 Mike Frysinger <vapier@gentoo.org> 2911 2912 sim: warnings: compile build tools with -Werror too 2913 Add support for compiling build tools with various -Werror settings. 2914 Since the tools don't compile cleanly with the same set of flags as 2915 the rest of the sim code, we need to maintain & test a separate list. 2916 2917 Only bother when not cross-compiling so we don't have to test all the 2918 flags against the build compiler. This should be good enough for our 2919 actual development flows. 2920 29212024-01-09 Mike Frysinger <vapier@gentoo.org> 2922 2923 sim: igen: fix format-zero-length warnings 2924 Fix warnings from calling printf functions with "" which normally 2925 is useless. 2926 2927 sim: m68hc11: gencode: add printf markings 2928 2929 sim: m32c: fix declaration-after-statement warnings 2930 29312024-01-09 Mike Frysinger <vapier@gentoo.org> 2932 2933 sim: warnings: fix unused variable warnings 2934 Leave the igen code in place as it's meant to be used with newer 2935 (to-be-written) code ported from the ppc version. 2936 2937 The sh code isn't really necessary as the opcodes enums have been 2938 maintained independently from here, and the lists are out-of-sync 2939 already. 2940 29412024-01-09 Mike Frysinger <vapier@gentoo.org> 2942 2943 sim: warnings: mark local funcs/vars as static 2944 These are only used in the respective files, so mark them as static. 2945 This fixes missing prototype warnings at build time. 2946 29472024-01-09 Tom Tromey <tom@tromey.com> 2948 2949 Back out some parallel_for_each features 2950 Now that the DWARF reader does not use parallel_for_each, we can 2951 remove some of the features that were added just for it: return values 2952 and task sizing. 2953 2954 The thread_pool typed tasks feature could also be removed, but I 2955 haven't done so here. This one seemed less intrusive and perhaps more 2956 likely to be needed at some point. 2957 29582024-01-09 Tom Tromey <tom@tromey.com> 2959 2960 Avoid language-based lookups in startup path 2961 The previous patches are nearly enough to enable background DWARF 2962 reading. However, this hack in language_defn::get_symbol_name_matcher 2963 causes an early computation of current_language: 2964 2965 /* If currently in Ada mode, and the lookup name is wrapped in 2966 '<...>', hijack all symbol name comparisons using the Ada 2967 matcher, which handles the verbatim matching. */ 2968 if (current_language->la_language == language_ada 2969 && lookup_name.ada ().verbatim_p ()) 2970 return current_language->get_symbol_name_matcher_inner (lookup_name); 2971 2972 I considered various options here -- reversing the order of the 2973 checks, or promoting the verbatim mode to not be a purely Ada feature 2974 -- but in the end found that the few calls to this during startup 2975 could be handled more directly. 2976 2977 In the JIT code, and in create_exception_master_breakpoint_hook, gdb 2978 is really looking for a certain kind of symbol (text or data) using a 2979 linkage name. Changing the lookup here is clearer and probably more 2980 efficient as well. 2981 2982 In create_std_terminate_master_breakpoint, the lookup can't really be 2983 done by linkage name (it would require relying on a certain mangling 2984 scheme, and also may trip over versioned symbols) -- but we know that 2985 this spot is C++-specific, and so the language ought to be temporarily 2986 set to C++ here. 2987 2988 After this patch, the "file" case is much faster: 2989 2990 (gdb) file /tmp/gdb 2991 2023-10-23 13:16:54.456 - command started 2992 Reading symbols from /tmp/gdb... 2993 2023-10-23 13:16:54.520 - command finished 2994 Command execution time: 0.225906 (cpu), 0.064313 (wall) 2995 29962024-01-09 Tom Tromey <tom@tromey.com> 2997 2998 Optimize lookup_minimal_symbol_text 2999 lookup_minimal_symbol_text always loops over all objfiles, even when 3000 an objfile is passed in as an argument. This patch changes the 3001 function to loop over the minimal number of objfiles in the latter 3002 situation. 3003 30042024-01-09 Tom Tromey <tom@tromey.com> 3005 3006 Lazy language setting 3007 When gdb starts up with a symbol file, it uses the program's "main" to 3008 decide the "static context" and the initial language. With background 3009 DWARF reading, this means that gdb has to wait for a significant 3010 amount of DWARF to be read synchronously. 3011 3012 This patch introduces lazy language setting. The idea here is that in 3013 many cases, the prompt can show up early, making gdb feel more 3014 responsive. 3015 30162024-01-09 Tom Tromey <tom@tromey.com> 3017 3018 Change current_language to be a macro 3019 This changes the 'current_language' global to be a macro that wraps a 3020 function call. This change will let a subsequent patch introduce lazy 3021 language setting. 3022 30232024-01-09 Tom Tromey <tom@tromey.com> 3024 3025 Remove two quick_symbol_functions methods 3026 quick_symbol_functions::read_partial_symbols is no longer implemented, 3027 so both it and quick_symbol_functions::can_lazily_read_symbols can be 3028 removed. This allows for other functions to be removed as well. 3029 3030 Note that SYMFILE_NO_READ is now pretty much dead. I haven't removed 3031 it here -- but could if that's desirable. I tend to think that this 3032 functionality would be better implemented in the core; but whenever I 3033 dive into the non-DWARF readers it is pretty depressing. 3034 30352024-01-09 Tom Tromey <tom@tromey.com> 3036 3037 Simplify the public DWARF API 3038 dwarf2_has_info and dwarf2_initialize_objfile are only separate 3039 because the DWARF reader implemented lazy psymtab reading. However, 3040 now that this is gone, we can simplify the public DWARF API again. 3041 30422024-01-09 Tom Tromey <tom@tromey.com> 3043 3044 Do more DWARF reading in the background 3045 This patch rearranges the DWARF reader so that more work is done in 3046 the background. This is PR symtab/29942. 3047 3048 The idea here is that there is only a small amount of work that must 3049 be done on the main thread when scanning DWARF -- before the main 3050 scan, the only part is mapping the section data. 3051 3052 Currently, the DWARF reader uses the quick_symbol_functions "lazy" 3053 functionality to defer even starting to read. This patch instead 3054 changes the reader to start reading immediately, but doing more in 3055 worker tasks. 3056 3057 Before this patch, "file" on my machine: 3058 3059 (gdb) file /tmp/gdb 3060 2023-10-23 12:29:56.885 - command started 3061 Reading symbols from /tmp/gdb... 3062 2023-10-23 12:29:58.047 - command finished 3063 Command execution time: 5.867228 (cpu), 1.162444 (wall) 3064 3065 After the patch, more work is done in the background and so this takes 3066 a bit less time: 3067 3068 (gdb) file /tmp/gdb 3069 2023-10-23 13:25:51.391 - command started 3070 Reading symbols from /tmp/gdb... 3071 2023-10-23 13:25:51.712 - command finished 3072 Command execution time: 1.894500 (cpu), 0.320306 (wall) 3073 3074 I think this could be further sped up by using the shared library load 3075 map to avoid objfile loops like the one in expand_symtab_containing_pc 3076 -- it seems like the correct objfile could be chosen more directly. 3077 3078 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942 3079 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174 3080 30812024-01-09 Tom Tromey <tom@tromey.com> 3082 3083 Change how cooked index waits for threads 3084 This changes the cooked index code to wait for threads in its 3085 public-facing API. That is, the waits are done in cooked_index now, 3086 and never in the cooked_index_shard. Centralizing this decision makes 3087 it easier to wait for other events here as well. 3088 30892024-01-09 Tom Tromey <tom@tromey.com> 3090 3091 Add "maint set dwarf synchronous" 3092 For testing, it's sometimes convenient to be able to request that 3093 DWARF reading be done synchronously. This patch adds a new "maint" 3094 setting for this purpose. 3095 3096 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 3097 30982024-01-09 Tom Tromey <tom@tromey.com> 3099 3100 Move cooked_index_storage to cooked-index.h 3101 This moves cooked_index_storage to cooked-index.h. This is needed by 3102 a subsequent patch. 3103 3104 Add gdb::task_group 3105 This adds gdb::task_group, a convenient way to group background tasks 3106 and then call a function when all the tasks have completed. 3107 3108 Add quick_symbol_functions::compute_main_name 3109 This adds a new compute_main_name method to quick_symbol_functions. 3110 Currently there are no implementations of this, but a subsequent patch 3111 will add one. 3112 3113 Add deferred_warnings parameter to read_addrmap_from_aranges 3114 When DWARF reading is done in the background, 3115 read_addrmap_from_aranges will be called from a worker thread. 3116 Because warnings can't be emitted from these threads, this patch adds 3117 a new deferred_warnings parameter to the function, letting the caller 3118 control exactly how the warnings are emitted. 3119 3120 Refactor complaint thread-safety approach 3121 This patch changes the way complaint works in a background thread. 3122 The new approach requires installing a complaint interceptor in each 3123 worker, and then the resulting complaints are treated as one of the 3124 results of the computation. This change is needed for a subsequent 3125 patch, where installing a complaint interceptor around a parallel-for 3126 is no longer a viable approach. 3127 31282024-01-09 Tom Tromey <tom@tromey.com> 3129 3130 Add thread-safety to gdb's BFD wrappers 3131 This changes gdb to ensure that gdb's BFD cache is guarded by a lock. 3132 This avoids any races when multiple threads might open a BFD (and thus 3133 use the BFD cache) at the same time. 3134 3135 Currently, this change is not needed because the the main thread waits 3136 for some DWARF scanning to be completed before returning. The only 3137 locking that's required is when opening DWO files, and there's a local 3138 lock to this end in dwarf2/read.c. 3139 3140 However, in the coming patches, the DWARF reader will begin its work 3141 earlier, in the background. This means there is the potential for the 3142 DWARF reader and other code on the main thread to both attempt to open 3143 BFDs at the same time. 3144 31452024-01-09 Tom Tromey <tom@tromey.com> 3146 3147 Add a couple of bfd_cache_close calls 3148 This adds a couple of calls to bfd_cache_close at points where a BFD 3149 isn't actively needed by gdb. Normally at these points, all the 3150 needed section data is already mapped, so we can simply close the file 3151 descriptor. This is harmless at worst, because if this is needed 3152 after all, the BFD file descriptor cache will reopen it. 3153 3154 Pre-read DWZ section data 3155 This changes the DWZ code to pre-read the section data and somewhat 3156 simplify the DWZ API. This makes it easier to add the bfd_cache_close 3157 call to the new dwarf2_read_dwz_file function -- after this is done, 3158 there shouldn't be a reason to keep the BFD's file descriptor open. 3159 31602024-01-09 Tom Tromey <tom@tromey.com> 3161 3162 Don't use objfile::intern in DWO code 3163 The DWO code in the DWARF reader currently uses objfile::intern. This 3164 accesses a shared data structure and so would be racy when used from 3165 multiple threads. I don't believe this can happen right now, but 3166 background reading could provoke this, and in any case it's better to 3167 avoid this, just to be sure. 3168 3169 This patch changes this code to just use a std::string. A new type is 3170 introduced to do hash table lookups, to avoid unnecessary copies. 3171 31722024-01-09 Mike Frysinger <vapier@gentoo.org> 3173 3174 sim: build: clean more generated outputs 3175 3176 sim: mips: drop old clean workaround 3177 This logic dates back to the original import, and seems to be for 3178 handling systems where `rm -f` (i.e. no files) would error out. 3179 None of that is relevant for us with current automake, so drop it. 3180 3181 sim: ppc: workaround uninitialized variable compiler warnings 3182 Some compilers don't understand the semctl API and think it's an input 3183 argument even when it's used as an output, and then complains that it 3184 is being used uninitialized. Zero it out explicitly to workaround it. 3185 This adds some runtime overhead, but should be fairly minor as it's a 3186 small stack buffer, and shouldn't be that relevant relative to all the 3187 other logic in these functions. 3188 3189 sim: warnings: enable -Wshift-negative-value 3190 Now that all the relevant sources are fixed, enable the warning. 3191 3192 sim: sh: avoid left shifting negative values 3193 We just want to create a bitmask here, so cast the mask to unsigned 3194 to avoid left shifting a negative value which is undefined behavior. 3195 3196 sim: bfin: avoid left shifting negative values 3197 We just want to create a bitmask here, so cast the mask to unsigned 3198 to avoid left shifting a negative value which is undefined behavior. 3199 32002024-01-09 Mike Frysinger <vapier@gentoo.org> 3201 3202 sim: cgen: rework DI macros to avoid signed left shifts 3203 The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros 3204 are used to construct 64-bit values from 32-bit values (for the low 3205 and high parts). The MAKEDI macro casts the high 32-bit value to a 3206 signed 32-bit value before shifting. If this created a negative 3207 value, this would be undefined behavior according to the C standard. 3208 All we care about is shifting the 32-bits as they are to the high 3209 32-bits, not caring about sign extension (since there's nothing left 3210 to shift into), and the low 32-bits being empty. This is what we 3211 get from shifting an unsigned value, so cast it to unsigned 32-bit 3212 to avoid undefined behavior. 3213 3214 While we're here, change the SETLODI macro to truncate the lower 3215 value to 32-bits before we set it. If it was passing in a 64-bit 3216 value, those high bits would get included too, and that's not what 3217 we want. 3218 3219 Similarly, tweak the SETHIDI macro to cast the value to an unsigned 3220 64-bit instead of a signed 64-bit. If the value was only 32-bits, 3221 the behavior would be the same. If it happened to be signed 64-bit, 3222 it would trigger the undefined behavior too. 3223 32242024-01-09 GDB Administrator <gdbadmin@sourceware.org> 3225 3226 Automatic date update in version.in 3227 32282024-01-08 Cupertino Miranda <cupertino.miranda@oracle.com> 3229 3230 bpf: Added linker support for R_BPF_64_NODYLD32. 3231 This patch adds linker support to patch R_BPF_64_NODYLD32 relocations. 3232 The implementation was based on comments and code in LLVM, as the GNU 3233 toolchain does not uses this relocation type. 3234 32352024-01-08 Joseph Myers <josmyers@redhat.com> 3236 3237 MAINTAINERS: Update my email address 3238 32392024-01-08 YunQiang Su <yunqiang.su@cipunited.com> 3240 3241 MIPS/GAS: mips.exp, mark all mipsisa32*-linux as addr32 3242 Currently, only mipsisa32-linux and mipsisa32el-linux is marked 3243 as addr32, which make mipsisa32rN(el) not marked. 3244 3245 This change can fix 2 test failures on mipsisa32rN(el)-linux: 3246 FAIL: MIPS MIPS64 MIPS-3D ASE instructions (-mips3d flag) 3247 FAIL: MIPS MIPS64 MDMX ASE instructions (-mdmx flag) 3248 3249 These failures don't happen for mipsisa32rN-mti-elf etc, 3250 due to that, the output is set as NO_ABI instead of O32, then 3251 gas won't warn: 3252 `fp=64' used with a 32-bit ABI 3253 Maybe, we should change this behaivour in future. 3254 32552024-01-08 srinath <srinath.parvathaneni@arm.com> 3256 3257 arm: Add support for Armv8.9-A and Armv9.4-A 3258 This patch adds AArch32 support for -march=armv8.9-a and 3259 -march=armv9.4-a. The behaviour of the new options can be 3260 expressed using a combination of existing feature flags 3261 and tables. 3262 3263 The cpu_arch_ver entries for ARM_ARCH_V9_4A and ARM_ARCH_V8_9A 3264 are technically redundant but it including them for macro code 3265 consistency across architectures. 3266 32672024-01-08 srinath <srinath.parvathaneni@arm.com> 3268 3269 aarch64: Add ite feature system registers. 3270 This patch adds ite feature (FEAT_ITE) system registers, 3271 trcitecr_el1, trcitecr_el12, trcitecr_el2 and trciteedcr. 3272 32732024-01-08 Samuel Tardieu <sam@rfc1149.net> 3274 3275 gas/doc: fix several typos 3276 32772024-01-08 Tom de Vries <tdevries@suse.de> 3278 3279 [gdb/testsuite] Add missing -no-prompt-anchor in gdb.base/vfork-follow-parent.exp 3280 When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but 3281 when running it with "taskset -c 0" I run into: 3282 ... 3283 (gdb) inferior 1^M 3284 [Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M 3285 [Switching to thread 1.1 (process 26606)]^M 3286 (gdb) Reading symbols from vfork-follow-parent-exit...^M 3287 FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \ 3288 non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout) 3289 ... 3290 3291 Fix this by using -no-prompt-anchor. 3292 3293 Tested on x86_64-linux. 3294 3295 PR testsuite/31166 3296 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31166 3297 32982024-01-08 Sergey Bugaev <bugaevc@gmail.com> 3299 3300 Add support for the aarch64-gnu target (GNU/Hurd on AArch64) 3301 Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or 3302 aarch64-unknown-gnu. 3303 3304 The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh, 3305 or to aarch64linux.sh with Linux-specific logic removed; and mainly different 3306 from the generic aarch64elf.sh in that it does not set EMBEDDED=yes. 3307 3308 Coupled with a corresponding GCC patch, this produces a toolchain that can 3309 sucessfully build working binaries targeting aarch64-gnu. 3310 33112024-01-08 Tom de Vries <tdevries@suse.de> 3312 3313 [gdb/testsuite] Make gdb.base/solib-search.exp more robust 3314 On aarch64-linux, with gcc 13.2.1, I run into: 3315 ... 3316 (gdb) backtrace^M 3317 #0 break_here () at solib-search.c:30^M 3318 #1 0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M 3319 #2 0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M 3320 #3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M 3321 #4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M 3322 #5 0x00000000004101b4 in main () at solib-search.c:23^M 3323 (gdb) PASS: gdb.base/solib-search.exp: \ 3324 backtrace (with wrong libs) (data collection) 3325 FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs) 3326 ... 3327 3328 The FAIL is generated by this code in the test-case: 3329 ... 3330 if { $expect_fail } { 3331 # If the backtrace output is correct the test isn't sufficiently 3332 # testing what it should. 3333 if { $count == $total_expected } { 3334 set fail 1 3335 } 3336 ... 3337 3338 The test-case: 3339 - builds two versions of two shared libs, a "right" and "wrong" version, the 3340 difference being an additional dummy function (called spacer function), 3341 - uses the "right" version to generate a core file, 3342 - uses the "wrong" version to interpret the core file, and 3343 - generates a backtrace. 3344 3345 The intent is that the backtrace is incorrect due to using the "wrong" 3346 version, but actually it's correct. This is because the spacer functions 3347 aren't large enough. 3348 3349 Fix this by increasing the size of the spacer functions by adding a dummy 3350 loop, after which we have, as expected, an incorrect backtrace: 3351 ... 3352 (gdb) backtrace^M 3353 #0 break_here () at solib-search.c:30^M 3354 #1 0x0000fffff7f201c0 in ?? ()^M 3355 #2 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M 3356 #3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M 3357 #4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M 3358 #5 0x00000000004101b4 in main () at solib-search.c:23^M 3359 (gdb) PASS: gdb.base/solib-search.exp: \ 3360 backtrace (with wrong libs) (data collection) 3361 PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) 3362 ... 3363 3364 Tested on aarch64-linux. 3365 33662024-01-08 Hu, Lin1 <lin1.hu@intel.com> 3367 3368 i386: Use .insn describe jmpabs's testcases. 3369 gas/ChangeLog: 3370 3371 * testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Use .insn instead 3372 of .byte to describe test cases. 3373 33742024-01-08 GDB Administrator <gdbadmin@sourceware.org> 3375 3376 Automatic date update in version.in 3377 33782024-01-07 H.J. Lu <hjl.tools@gmail.com> 3379 3380 i386: Correct adcx suffix in disassembler 3381 Since 0x66 is the opcode prefix for adcx, it is wrong to use the 'S' 3382 prefix: 3383 3384 'S' => print 'w', 'l' or 'q' if suffix_always is true 3385 3386 on adcx. Add 3387 3388 'L' => print 'l' or 'q' if suffix_always is true 3389 3390 replace S with L on adcx and adox. 3391 3392 gas/ 3393 3394 PR binutils/31219 3395 * testsuite/gas/i386/suffix.d: Updated. 3396 * testsuite/gas/i386/x86-64-suffix.d: Likewise. 3397 * testsuite/gas/i386/suffix.s: Add tests for adcx and adox. 3398 * testsuite/gas/i386/x86-64-suffix.s: Likewise. 3399 3400 opcodes/ 3401 3402 PR binutils/31219 3403 * i386-dis.c: Add the 'L' suffix. 3404 (prefix_table): Replace S with L on adcx and adox. 3405 (putop): Handle the 'L' suffix. 3406 34072024-01-07 Mike Frysinger <vapier@gentoo.org> 3408 3409 sim: warnings: enable -Wshadow=local 3410 This brings us in sync with current set of gdb warnings (for C). 3411 34122024-01-07 Mike Frysinger <vapier@gentoo.org> 3413 3414 sim: cris: change temp var name slightly to avoid shadowing 3415 Rename the temp var to avoid shadowing another one: 3416 3417 .../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local] 3418 11032 | tmp_tmpb = ({ SI tmp_tmpb; 3419 | ^~~~~~~~ 3420 .../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here 3421 11031 | tmp_tmpres = ({ SI tmp_tmpb; 3422 | ^~~~~~~~ 3423 34242024-01-07 Mike Frysinger <vapier@gentoo.org> 3425 3426 sim: cris: add error fallbacks when decoding condition & swap codes 3427 The condition & swap code decoder only checks known bits and sets 3428 based on that. If the variable is out of range, it ends up returning 3429 uninitialized data. Turn that case into a hard error. 3430 3431 This fixes build warnings like: 3432 sim/cris/semcrisv10f-switch.c:13115:11: error: 3433 variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 3434 34352024-01-07 GDB Administrator <gdbadmin@sourceware.org> 3436 3437 Automatic date update in version.in 3438 34392024-01-06 H.J. Lu <hjl.tools@gmail.com> 3440 3441 ld: Adjust x86 and x86-64 tests for -z mark-plt 3442 To support -z mark-plt enabled by default, adjust x86 tests to accept 3443 non-zero r_addend for JUMP_SLOT relocation and pass -z nomark-plt to 3444 x86-64 tests if -z mark-plt changes the expected outputs. 3445 3446 * testsuite/ld-elf/indirect-extern-access-2.rd: Allow non-zero 3447 r_addend for JUMP_SLOT relocation. 3448 * testsuite/ld-elf/pr23161d.rd: Likewise. 3449 * testsuite/ld-ifunc/ifunc-25c-x86.d: Likewise. 3450 * testsuite/ld-ifunc/ifunc-16-x86-64-now.d: Pass -z nomark-plt 3451 to linker. 3452 * testsuite/ld-ifunc/ifunc-16-x86-64.d: Likewise. 3453 * testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise. 3454 * testsuite/ld-ifunc/ifunc-2-local-x86-64.d: Likewise. 3455 * testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise. 3456 * testsuite/ld-ifunc/ifunc-2-x86-64.d: Likewise. 3457 * testsuite/ld-ifunc/ifunc-20-x86-64.d: Likewise. 3458 * testsuite/ld-ifunc/ifunc-5b-x86-64.d: Likewise. 3459 * testsuite/ld-ifunc/pr17154-x86-64-now.d: Likewise. 3460 * testsuite/ld-ifunc/pr17154-x86-64.d: Likewise. 3461 * testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise. 3462 * testsuite/ld-x86-64/dt-relr-1a.d: Likewise. 3463 * testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise. 3464 * testsuite/ld-x86-64/dt-relr-1b.d: Likewise. 3465 * testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise. 3466 * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise. 3467 * testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise. 3468 * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise. 3469 * testsuite/ld-x86-64/pr19636-2d.d: Likewise. 3470 * testsuite/ld-x86-64/pr19636-2e.d: Likewise. 3471 * testsuite/ld-x86-64/pr19636-2f.d: Likewise. 3472 * testsuite/ld-x86-64/pr19636-2l.d: Likewise. 3473 * testsuite/ld-x86-64/x86-64.exp: Pass -z nomark-plt to linker 3474 in 6 tests. 3475 34762024-01-06 Indu Bhagat <indu.bhagat@oracle.com> 3477 3478 gas: sframe: fix some typos in code comments 3479 34802024-01-06 GDB Administrator <gdbadmin@sourceware.org> 3481 3482 Automatic date update in version.in 3483 34842024-01-05 Jan Beulich <jbeulich@suse.com> 3485 3486 x86: relax AMD Zen5 testcase expectations 3487 One item was too strict for PE/COFF, and there's really no need to check 3488 for specific comment contents here. 3489 34902024-01-05 Tejas Joshi <TejasSanjay.Joshi@amd.com> 3491 3492 Add AMD znver5 processor support 3493 gas/ 3494 3495 * config/tc-i386.c (cpu_arch): Add znver5 ARCH. 3496 * doc/c-i386.texi: Add znver5. 3497 * testsuite/gas/i386/arch-15.d: New. 3498 * testsuite/gas/i386/arch-15.s: Likewise. 3499 * testsuite/gas/i386/arch-15-znver5.d: Likewise. 3500 * testsuite/gas/i386/i386.exp: Add new znver5 test cases. 3501 * testsuite/gas/i386/x86-64.exp: Likewise. 3502 * testsuite/gas/i386/x86-64-arch-5.d: Likewise. 3503 * testsuite/gas/i386/x86-64-arch-5.s: Likewise. 3504 * testsuite/gas/i386/x86-64-arch-5-znver5.d: Likewise. 3505 3506 opcodes/ 3507 3508 * i386-gen.c (isa_dependencies): Add ZNVER5 dependencies. 3509 * i386-init.h: Re-generated. 3510 35112024-01-05 Jan Beulich <jbeulich@suse.com> 3512 3513 Arm/doc: separate @code from @item for older makeinfo 3514 At least 4.12 doesn't like the constructs without a separator. 3515 3516 x86: corrections to CPU attribute/flags splitting 3517 There are a number of issues with 734dfd1cc966 ("x86: pack CPU flags in 3518 opcode table"): 3519 - the condition when two array slots need writing wasn't correct (with 3520 enough new Cpu* added an out of bounds array access would validly have 3521 been complained about by the compiler), 3522 - table generation didn't take into account CpuAttrUnused and CpuUnused 3523 being independent, and hence there not always (not) being an "unused" 3524 bitfield member in both structures, 3525 - cpu_flags_from_attr() wasn't ready for use on big-endian hosts, 3526 - there were two style violations. 3527 3528 ELF: test certain .text/.data usages 3529 Various targets have / had overrides for .text and/or .data. Make sure 3530 that in such cases sub-section specifiers are accepted, as mandated by 3531 the doc. 3532 3533 ELF: test certain .bss usages 3534 Various targets have / had overrides for .bss. Make sure that in such 3535 cases 3536 - .previous still works correctly (requiring such targets to invoke 3537 obj_elf_section_change_hook() from their overriding handlers), 3538 - sub-section specifiers are accepted as far as feasible (mandated by 3539 the doc). 3540 3541 gas: correct .bss documentation for non-ELF 3542 Only ELF permits the specification of a subsection, and even there not 3543 consistently: csky, mcore, and spu handle .bss similar to .lcomm. 3544 3545 z80: drop .bss override 3546 It doesn't look to be a good idea to override the custom handlers that 3547 ELF and COFF have; afaict doing so broke .previous on ELF, and a sub- 3548 section specifier wasn't accepted either. 3549 35502024-01-05 Jan Beulich <jbeulich@suse.com> 3551 3552 visium: drop .bss and .skip overrides 3553 The comment in s_bss() looks bogus (perhaps simply stale, or wrongly 3554 copied from another target). It also doesn't look to be a good idea to 3555 override the custom handler that ELF has (afaict doing so broke 3556 .previous as well as sub-section specification). 3557 3558 The override for .skip is simply pointless, for read.c having exactly 3559 the same. 3560 3561 While there also drop two adjacent redundant (with read.h) declarations 3562 (which would be outright dangerous if read.h wasn't included anyway). 3563 35642024-01-05 Jan Beulich <jbeulich@suse.com> 3565 3566 v850: drop .bss override 3567 While there doesn't look to be anything wrong with this override, 3568 there's also no apparent reason why this override would be needed. Drop 3569 it, reducing overall size a tiny bit. 3570 35712024-01-05 Jan Beulich <jbeulich@suse.com> 3572 3573 score: drop .bss override 3574 The comment looks bogus (perhaps simply stale, or wrongly copied from 3575 another target). It also doesn't look to be a good idea to override the 3576 custom handler that ELF has (afaict doing so broke .previous as well as 3577 sub-section specification). 3578 3579 While there also fold the identical handlers for .text (there likely is 3580 more room for such folding). 3581 35822024-01-05 Jan Beulich <jbeulich@suse.com> 3583 3584 s390: drop .bss override 3585 The comment looks bogus (perhaps simply stale), and there are also no 3586 other precautions against subsections being used on ELF with .bss. It 3587 also doesn't look to be a good idea to override the custom handler that 3588 ELF has (afaict doing so further broke .previous). 3589 3590 rx: drop .bss override 3591 It doesn't look to be a good idea to override the custom handler that 3592 ELF has; afaict doing so broke .previous. 3593 3594 rl78: drop .bss override 3595 It doesn't look to be a good idea to override the custom handler that 3596 ELF has; afaict doing so broke .previous. 3597 3598 pru: fix .text/.data interaction with .previous 3599 Just like obj_elf_section() is called for .section, obj_elf_{text,data}() 3600 need calling for .text/.data. 3601 3602 microblaze: drop/restrict override of .text, .data, and .bss 3603 While only ELF is supported right now, (stub) code generally is in place 3604 for the non-ELF case as well. Don't override .bss for ELF - that's 3605 unlikely to be a good idea anyway and prevented the sub-section 3606 specifier from being usable. Don't override .text and .data at all - for 3607 .data and ELF for the same reason, while for .text and ELF obj-elf.c's is 3608 all we need, and for (hypothetical) non-ELF read.c's identical handling 3609 would have been invoked anyway. 3610 3611 m68k: drop .bss override 3612 The comment looks bogus (perhaps simply stale), and there are also no 3613 other precautions against subsections being used on ELF with .bss. It 3614 also doesn't look to be a good idea to override the custom handler that 3615 ELF has (afaict doing so further broke .previous). 3616 3617 m32c: drop .bss override 3618 It doesn't look to be a good idea to override the custom handler that 3619 ELF has; afaict doing so broke .previous. 3620 3621 IA64: drop .bss override 3622 It doesn't look to be a good idea to override the custom handlers that 3623 ELF and COFF have. While in this case interaction with ELF's .previous 3624 wasn't screwed, the sub-section specifier wasn't permitted. 3625 3626 d30v: fix .text/.data interaction with .previous 3627 Just like obj_elf_section() is called for .section, obj_elf_{text,data}() 3628 need calling for .text/.data. 3629 3630 bfin: drop .bss override 3631 It doesn't look to be a good idea to override the custom handler that 3632 ELF has; afaict doing so broke .previous. 3633 36342024-01-05 Jan Beulich <jbeulich@suse.com> 3635 3636 Arm64: drop .bss override 3637 The comment looks bogus (perhaps simply stale, perhaps wrongly copied 3638 from Arm in the first place), and there are also no other precautions 3639 against subsections being used on ELF with .bss. It also doesn't look 3640 to be a good idea to override the custom handlers that ELF and COFF 3641 have (afaict doing so further broke .previous on ELF). 3642 3643 As to the mapping state update - such also doesn't appear to be done 3644 for other section switching, so its original purpose was at best 3645 questionable as well. 3646 36472024-01-05 Jan Beulich <jbeulich@suse.com> 3648 3649 Arm: drop .bss override 3650 The comment looks bogus (perhaps simply stale), and there are also no 3651 other precautions against subsections being used on ELF with .bss. It 3652 also doesn't look to be a good idea to override the custom handlers that 3653 ELF and COFF have (afaict doing so further broke .previous on ELF). 3654 36552024-01-05 Tamar Christina <tamar.christina@arm.com> 3656 3657 Enforce C++11 as a minimum for building gold [PR30867] 3658 The attempt in 5e9091dab885 to correct gold for modern LLVM has broken 3659 gold for older compilers. This commit introduced C++11 types without 3660 changing the build system to require a C++ compiler. More importantly 3661 it depends on the compiler having at least C++11 as the default 3662 language. Older compilers which support C++11 but not as the default 3663 language needlessly break. Fix that. 3664 3665 PR gold/30867 3666 * configure.ac (AX_CXX_COMPILE_STDCXX): Require C++11. 3667 * Makefile.in: Regenerate. 3668 * aclocal.m4: Regenerate. 3669 * config.in: Regenerate. 3670 * configure: Regenerate. 3671 * testsuite/Makefile.in: Regenerate. 3672 36732024-01-05 Alan Modra <amodra@gmail.com> 3674 3675 loongarch: 'index' shadows global 3676 Avoid an error when compiling with older versions of gcc. 3677 3678 * elfnn-loongarch.c (loongarch_relax_align): Rename "index" to 3679 "sym_index". 3680 36812024-01-05 Alan Modra <amodra@gmail.com> 3682 3683 Tidy bfd_scan_vma 3684 In commit 83c79df86bf4 I removed configure tests for strtoull among 3685 other library functions part of C99, but didn't remove what is now 3686 dead code. 3687 3688 * bfd.c (bfd_scan_vma): Delete fall-back for strtoull. 3689 36902024-01-05 Alan Modra <amodra@gmail.com> 3691 3692 PR31120, ld-scripts/fill2 fails when bfd_vma is 32 bits 3693 The ld lexer converts strings to integers without overflow checking, 3694 so I don't think there is any problem in truncating an integer that 3695 exceeds the size of a bfd_vma rather than using (bfd_vma) -1. 3696 3697 PR 31120 3698 * ldlex.l: Don't use bfd_scan_vma for integer conversion, use 3699 strtoull. 3700 37012024-01-05 Jin Ma <jinma@linux.alibaba.com> 3702 3703 RISC-V: T-HEAD: Fix wrong instruction encoding for th.vsetvli 3704 Since the particularity of "th.vsetvli" was not taken into account in the 3705 initial support patches for XTheadVector, the program operation failed 3706 due to instruction coding errors. According to T-Head SPEC ([1]), the 3707 "vsetvl" in the XTheadVector extension consists of SEW, LMUL and EDIV, 3708 which is quite different from the "V" extension. Therefore, we cannot 3709 simply reuse the processing of vsetvl in V extension. 3710 3711 We have set up tens of thousands of test cases to ensure that no 3712 further encoding issues are there, and and execute all compiled test 3713 files on real HW and make sure they don't trigger SIGILL. 3714 3715 Ref: 3716 [1] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf 3717 3718 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 3719 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 3720 3721 gas/ChangeLog: 3722 3723 * config/tc-riscv.c (validate_riscv_insn): Add handling for 3724 th.vsetvli. 3725 (my_getThVsetvliExpression): New function. 3726 (riscv_ip): Likewise. 3727 * testsuite/gas/riscv/x-thead-vector.d: Likewise. 3728 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 3729 3730 include/ChangeLog: 3731 3732 * opcode/riscv.h (OP_MASK_XTHEADVLMUL): New macro. 3733 (OP_SH_XTHEADVLMUL): Likewise. 3734 (OP_MASK_XTHEADVSEW): Likewise. 3735 (OP_SH_XTHEADVSEW): Likewise. 3736 (OP_MASK_XTHEADVEDIV): Likewise. 3737 (OP_SH_XTHEADVEDIV): Likewise. 3738 (OP_MASK_XTHEADVTYPE_RES): Likewise. 3739 (OP_SH_XTHEADVTYPE_RES): Likewise. 3740 3741 opcodes/ChangeLog: 3742 3743 * riscv-dis.c (print_insn_args): Likewise. 3744 * riscv-opc.c: Likewise. 3745 37462024-01-05 GDB Administrator <gdbadmin@sourceware.org> 3747 3748 Automatic date update in version.in 3749 37502024-01-04 Tom de Vries <tdevries@suse.de> 3751 3752 [gdb/testsuite] Handle PAC marker 3753 On aarch64-linux, I run into: 3754 ... 3755 FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout) 3756 ... 3757 due to the PAC marker showing up: 3758 ... 3759 ^Z^Zframe-address^M 3760 0x000000000041025c [PAC]^M 3761 ^Z^Zframe-address-end^M 3762 ... 3763 3764 In the docs the marker is documented as follows: 3765 ... 3766 When GDB is debugging the AArch64 architecture, and the program is using the 3767 v8.3-A feature Pointer Authentication (PAC), then whenever the link register 3768 $lr is pointing to an PAC function its value will be masked. When GDB prints 3769 a backtrace, any addresses that required unmasking will be postfixed with the 3770 marker [PAC]. When using the MI, this is printed as part of the addr_flags 3771 field. 3772 ... 3773 3774 Update the test-case to allow the PAC marker. 3775 3776 Likewise in a few other test-cases. 3777 3778 While we're at it, rewrite the affected pattern pat_begin in annota1.exp into 3779 a more readable form. Likewise for the corresponding pat_end. 3780 3781 Tested on aarch64-linux. 3782 3783 Approved-By: Luis Machado <luis.machado@arm.com> 3784 3785 PR testsuite/31202 3786 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202 3787 37882024-01-04 Alan Modra <amodra@gmail.com> 3789 3790 Update year range in copyright notice of binutils files 3791 Adds two new external authors to etc/update-copyright.py to cover 3792 bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then 3793 updates copyright messages as follows: 3794 3795 1) Update cgen/utils.scm emitted copyrights. 3796 2) Run "etc/update-copyright.py --this-year" with an extra external 3797 author I haven't committed, 'Kalray SA.', to cover gas testsuite 3798 files (which should have their copyright message removed). 3799 3) Build with --enable-maintainer-mode --enable-cgen-maint=yes. 3800 4) Check out */po/*.pot which we don't update frequently. 3801 38022024-01-04 Nick Clifton <nickc@redhat.com> 3803 3804 Synchronize config.sub and config.guess with their upstream master versions. 3805 Brings in: 3806 commit 28ea239c53a2d5d8800c472bc2452eaa16e37af2 config.sub: Remove windows-gnu 3807 commit a6976af01b0c6206561782183a0db42124b19f7b config.sub: recognise ARM64EC machine type 3808 commit 4e60c54be77f743ff8018ab58fb36fd8bc055e2a config.sub: allow aarch64c-unknown-freebsd 3809 commit e4786449e1c26716e3f9ea182caf472e4dbc96e0 config.guess: invoke "uname -p" from PATH for non-arm FreeBSD 3810 commit 021155df7fad97a5ae1baa354e15a03ea14500b4 config.guess: Detect Android (as opposed to GNU/Linux) 3811 commit 6c78704d542cebfb56d17474fe9f8395e9defb94 config.sub: add javascript-*-ghcjs 3812 commit 2a7c4b64d4aec5c3a8a975625f0f8c369d365667 testsuite: add coverage for vendor-clobbering 3813 commit 39c49ea712cba8ae6613ef85ab22fe7c552b48b0 config.sub: Systematize parsing of machine code formats 3814 commit d4e37b5868ef910e3e52744c34408084bb13051c config.sub: Handle arbitrary MIPS CPU names 3815 commit af8d803a82436779d35ea389888788c78677804e config.guess (aarch64:Linux:*:*): Detect 32-bit ABI 3816 commit 602766470c886df7ae07bcfd7dcf532f0783d3e0 Add KVX MPPA detection 3817 commit be68d790b6bc7dd84982fa6760f1448e92849e63 config.sub: Add Apple tvOS and watchOS 3818 commit 998ba1414387b4ce1a519be234e1609bc7912e0c config.sub: Accept $cpu-$vendor-none-{coff,elf} 3819 38202024-01-04 mengqinggang <mengqinggang@loongson.cn> 3821 3822 LoongArch: Fix linker generate PLT entry for data symbol 3823 With old "medium" code model, we call a function with a pair of PCALAU12I 3824 and JIRL instructions. The assembler produces something like: 3825 3826 8: 1a00000c pcalau12i $t0, 0 3827 8: R_LARCH_PCALA_HI20 g 3828 c: 4c000181 jirl $ra, $t0, 0 3829 c: R_LARCH_PCALA_LO12 g 3830 3831 The linker generates a "PLT entry" for data without any diagnostic. 3832 If "g" is a data symbol and ld with -shared option, it may load two 3833 instructions in the PLT. 3834 3835 Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT 3836 entry. 3837 3838 For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC 3839 and STT_GNU_IFUNC symbols. 3840 38412024-01-04 Andrew Burgess <aburgess@redhat.com> 3842 3843 gdb: improve error reporting from expression parser 3844 This commits changes how errors are reported from the expression 3845 parser. Previously, parser errors were reported like this: 3846 3847 (gdb) p a1 +}= 432 3848 A syntax error in expression, near `}= 432'. 3849 (gdb) p a1 + 3850 A syntax error in expression, near `'. 3851 3852 The first case is fine, a user can figure out what's going wrong, but 3853 the second case is a little confusing; as the error occurred at the 3854 end of the expression GDB just reports the empty string to the user. 3855 3856 After this commit the first case is unchanged, but the second case now 3857 reports like this: 3858 3859 (gdb) p a1 + 3860 A syntax error in expression, near the end of `a1 +'. 3861 3862 Which I think is clearer. There is a possible issue if the expression 3863 being parsed is very long, GDB will repeat the whole expression. But 3864 this issue already exists in the standard case; if the error occurs 3865 early in a long expression GDB will repeat everything after the syntax 3866 error. So I've not worried about this case in my new code either, 3867 which keeps things simpler. 3868 3869 I did consider trying to have multi-line errors here, in the style 3870 that gcc produces, with some kind of '~~~~~^' marker on the second 3871 line to indicate where the error occurred; but I rejected this due to 3872 the places in GDB where we catch an error and repackage the message 3873 within some longer string, I don't think multi-line error messages 3874 would work well in that case. At a minimum it would require some 3875 significant work in order to make all our error handling multi-line 3876 aware. 3877 3878 I've added a couple of extra tests in gdb.base/exprs.exp. 3879 3880 Approved-By: John Baldwin <jhb@FreeBSD.org> 3881 38822024-01-04 Andrew Burgess <aburgess@redhat.com> 3883 3884 gdb: merge error handling from different expression parsers 3885 Many (all?) of the expression parsers implement yyerror to handle 3886 parser errors, and all of these functions are basically identical. 3887 3888 This commit adds a new parser_state::parse_error() function, which 3889 implements the common error handling code, this function can then be 3890 called from all the different yyerror functions. 3891 3892 The benefit of this is that (in a future commit) I can improve the 3893 error output, and all the expression parsers will benefit. 3894 3895 This commit is pure refactoring though, and so, there should be no 3896 user visible changes after this commit. 3897 3898 Approved-By: John Baldwin <jhb@FreeBSD.org> 3899 39002024-01-04 Andrew Burgess <aburgess@redhat.com> 3901 3902 gdb: don't try to style content in error calls 3903 While working on a later commit in this series I realised that the 3904 error() function doesn't support output styling. Due to the way that 3905 output from error() calls is passed around within the exception 3906 object and often combined with other output, it's not immediately 3907 obvious to me if we should be trying to support styling in this 3908 context or not. 3909 3910 On inspection, I found one place in GDB where we apparently try to 3911 apply styling within the error() output (in procfs.c). I suspect this 3912 error() call might not be tested. 3913 3914 Rather than try to implement styling in the error() output, right now 3915 I'm proposing to just remove the attempt to style error() output. 3916 3917 This doesn't mean that someone shouldn't add error() styling in the 3918 future, but right now, I'm not planning to do that, I just wanted to 3919 fix this in passing. 3920 3921 Approved-By: John Baldwin <jhb@FreeBSD.org> 3922 39232024-01-04 Lulu Cai <cailulu@loongson.cn> 3924 3925 LoongArch: Fix loongarch*-elf target ld testsuite failure 3926 The loongarch*-elf target does not support SHARED and PIE, so this 3927 target is skipped for some tests that require these options. 3928 39292024-01-04 Lulu Cai <cailulu@loongson.cn> 3930 3931 LoongArch: Fix some macro that cannot be expanded properly 3932 Suppose we want to use la.got to generate 32 pcrel and 3933 32 abs instruction sequences respectively. According to 3934 the existing conditions, to generate 32 pcrel sequences 3935 use -mabi=ilp32*, and to generate 32 abs use -mabi=ilp32* 3936 and -mla-global-with-abs. 3937 3938 Due to the fact that the conditions for generating 32 abs 3939 also satisfy 32 pcrel, using -mabi=ilp32* and -mla-global-with-abs 3940 will result in only generating instruction sequences of 32 pcrel. 3941 3942 By modifying the conditions for macro expansion and adjusting 3943 the matching order of macro instructions, it is ensured that 3944 the correct sequence of instructions can be generated. 3945 39462024-01-04 GDB Administrator <gdbadmin@sourceware.org> 3947 3948 Automatic date update in version.in 3949 39502024-01-03 Mike Frysinger <vapier@gentoo.org> 3951 3952 sim: ppc: unify igen filter modules 3953 The common igen code was forked from the ppc long ago. The filter 3954 module is still pretty similar in API, so we can unfork them with 3955 a little bit of effort. 3956 3957 The filter.c module is still here because of the unique it_is API. 3958 The common igen code doesn't seem to have an equiv API as this only 3959 operates on two strings and not an actual filter object, and it's 3960 easy enough to leave behind to unfork the rest. 3961 39622024-01-03 Mike Frysinger <vapier@gentoo.org> 3963 3964 sim: ppc: unify igen line number output modules 3965 The common igen code was forked from the ppc long ago. The lf module 3966 is still pretty similar in API, so we can unfork them with a little 3967 bit of effort. 3968 3969 Some of the generated ppc code is now slightly different, but that's 3970 because of fixes the common igen code has gained, but not the ppc igen 3971 code (e.g. fixing of #line numbers). 3972 3973 The ppc code retains lf_print__c_code because the common igen code 3974 rewrote the logic to a new table.c API. Let's delay that in the ppc 3975 code to at least unfork all this code. 3976 39772024-01-03 Mike Frysinger <vapier@gentoo.org> 3978 3979 sim: igen: clean up headers a bit 3980 Add standard multiple inclusion protection, and add a few missing 3981 local includes when one header uses another. This isn't complete, 3982 but fixes some short comings seen when merging the ppc igen. 3983 3984 sim: ppc: switch to common endian code 3985 The common sim-endian is a forked & updated version of the ppc code. 3986 Fortunately, they didn't diverge from the basic APIs, so they are 3987 still compatible, which means we can just delete the ppc version now 3988 that the build env is merged at the top-level. 3989 3990 sim: common: include sim-types.h in the endian header directly 3991 This is a bit redundant for most ports as they go through sim-basics.h 3992 which always includes sim-types.h before including sim-endian.h, but in 3993 order to unify ppc's sim-endian code, we need this include here. Plus, 3994 it's the directly we generally want to go to get away from one header 3995 that defines all APIs and causes hard to untangle dependencies. 3996 3997 sim: ppc: rename local ALU SIGNED64 macros 3998 The common/ code has macros with the same name but different behavior: 3999 it's for declaring integer constants as 64-bit, not for casting them. 4000 Rename ppc's local variant since it's only used in this file in order 4001 to avoid conflicts. 4002 4003 sim: ppc: sync WITH_TARGET_{ADDRESS,CELL}_BITSIZE with common/ 4004 This will make it easier to share common/ code that rely on these 4005 additional defines. 4006 4007 sim: cr16: cleanup unused variable compiler warnings 4008 4009 sim: configure: switch to m4_map 4010 Minor reduction in boilerplate here. No real functional changes. 4011 4012 sim: drop support for recursive makes entirely 4013 Now that all ports have been merged to the top-level, we no longer need 4014 this framework to pass settings down to sub-makefiles. Delete it all. 4015 4016 sim: ppc: hoist compilation up to top-level 4017 This removes all recursive makes from the ppc port. 4018 4019 sim: drop support for automatic subdir recursion 4020 No port relies on this anymore, so we can scrub it all. 4021 40222024-01-03 Mike Frysinger <vapier@gentoo.org> 4023 4024 sim: ppc: move libsim.a creation to top-level 4025 The objects are still compiled in the subdir, but the creation of the 4026 archive itself is in the top-level. This is a required step before we 4027 can move compilation itself up, and makes it easier to review. 4028 4029 The downside is that each object compile is a recursive make instead of 4030 a single one. It adds some overhead, so it's not great, but it shouldn't 4031 be a big deal. This will go away once compilation is hoisted up. 4032 40332024-01-03 Mike Frysinger <vapier@gentoo.org> 4034 4035 sim: ppc: move main.o compilation to top-level 4036 40372024-01-03 mengqinggang <mengqinggang@loongson.cn> 4038 4039 LoongArch: delete bfd/.elfnn-loongarch.c.swp 4040 40412024-01-03 GDB Administrator <gdbadmin@sourceware.org> 4042 4043 Automatic date update in version.in 4044 40452024-01-02 Carl Love <cel@linux.ibm.com> 4046 4047 Fix GDB reverse-step and reverse-next command behavior 4048 Currently GDB when executing in reverse over multiple statements in a single 4049 line of source code, GDB stops in the middle of the line. Thus requiring 4050 multiple commands to reach the previous line. GDB should stop at the first 4051 instruction of the line, not in the middle of the line. 4052 4053 The following description of the incorrect behavior was taken from an 4054 earlier message by Pedro Alves <pedro@palves.net>: 4055 4056 https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html 4057 4058 --------------------------------- 4059 4060 The source line looks like: 4061 4062 func1 (); func2 (); 4063 4064 in the test case: 4065 4066 (gdb) list 1 4067 1 void func1 () 4068 2 { 4069 3 } 4070 4 4071 5 void func2 () 4072 6 { 4073 7 } 4074 8 4075 9 int main () 4076 10 { 4077 11 func1 (); func2 (); 4078 12 } 4079 4080 compiled with: 4081 4082 $ gcc reverse.c -o reverse -g3 -O0 4083 $ gcc -v 4084 ... 4085 gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) 4086 4087 Now let's debug it with target record, using current gdb git master 4088 (f3d8ae90b236), 4089 4090 $ gdb ~/reverse 4091 GNU gdb (GDB) 14.0.50.20230124-git 4092 ... 4093 Reading symbols from /home/pedro/reverse... 4094 (gdb) start 4095 Temporary breakpoint 1 at 0x1147: file reverse.c, line 11. 4096 Starting program: /home/pedro/reverse 4097 [Thread debugging using libthread_db enabled] 4098 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 4099 4100 Temporary breakpoint 1, main () at reverse.c:11 4101 11 func1 (); func2 (); 4102 (gdb) record 4103 4104 (gdb) disassemble /s 4105 Dump of assembler code for function main: 4106 reverse.c: 4107 10 { 4108 0x000055555555513f <+0>: endbr64 4109 0x0000555555555143 <+4>: push %rbp 4110 0x0000555555555144 <+5>: mov %rsp,%rbp 4111 4112 11 func1 (); func2 (); 4113 => 0x0000555555555147 <+8>: mov $0x0,%eax 4114 0x000055555555514c <+13>: call 0x555555555129 <func1> 4115 0x0000555555555151 <+18>: mov $0x0,%eax 4116 0x0000555555555156 <+23>: call 0x555555555134 <func2> 4117 0x000055555555515b <+28>: mov $0x0,%eax 4118 4119 12 } 4120 0x0000555555555160 <+33>: pop %rbp 4121 0x0000555555555161 <+34>: ret 4122 End of assembler dump. 4123 4124 (gdb) n 4125 12 } 4126 4127 So far so good, a "next" stepped over the whole of line 11 and stopped at 4128 line 12. 4129 4130 Let's confirm where we are now: 4131 4132 (gdb) disassemble /s 4133 Dump of assembler code for function main: 4134 reverse.c: 4135 10 { 4136 0x000055555555513f <+0>: endbr64 4137 0x0000555555555143 <+4>: push %rbp 4138 0x0000555555555144 <+5>: mov %rsp,%rbp 4139 4140 11 func1 (); func2 (); 4141 0x0000555555555147 <+8>: mov $0x0,%eax 4142 0x000055555555514c <+13>: call 0x555555555129 <func1> 4143 0x0000555555555151 <+18>: mov $0x0,%eax 4144 0x0000555555555156 <+23>: call 0x555555555134 <func2> 4145 0x000055555555515b <+28>: mov $0x0,%eax 4146 4147 12 } 4148 => 0x0000555555555160 <+33>: pop %rbp 4149 0x0000555555555161 <+34>: ret 4150 End of assembler dump. 4151 4152 Good, we're at the first instruction of line 12. 4153 4154 Now let's undo the "next", with "reverse-next": 4155 4156 (gdb) reverse-next 4157 11 func1 (); func2 (); 4158 4159 Seemingly stopped at line 11. Let's see exactly where: 4160 4161 (gdb) disassemble /s 4162 Dump of assembler code for function main: 4163 reverse.c: 4164 10 { 4165 0x000055555555513f <+0>: endbr64 4166 0x0000555555555143 <+4>: push %rbp 4167 0x0000555555555144 <+5>: mov %rsp,%rbp 4168 4169 11 func1 (); func2 (); 4170 0x0000555555555147 <+8>: mov $0x0,%eax 4171 0x000055555555514c <+13>: call 0x555555555129 <func1> 4172 => 0x0000555555555151 <+18>: mov $0x0,%eax 4173 0x0000555555555156 <+23>: call 0x555555555134 <func2> 4174 0x000055555555515b <+28>: mov $0x0,%eax 4175 4176 12 } 4177 0x0000555555555160 <+33>: pop %rbp 4178 0x0000555555555161 <+34>: ret 4179 End of assembler dump. 4180 (gdb) 4181 4182 And lo, we stopped in the middle of line 11! That is a bug, we should have 4183 stepped back all the way to the beginning of the line. The "reverse-next" 4184 should have fully undone the prior "next" command. 4185 4186 -------------------- 4187 4188 This patch fixes the incorrect GDB behavior by ensuring that GDB stops at 4189 the first instruction in the line. 4190 4191 The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite 4192 to verify this fix when the line table information is and is not available. 4193 41942024-01-02 Carl Love <cel@linux.ibm.com> 4195 4196 PowerPC and aarch64: Fix reverse stepping failure 4197 When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on 4198 the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and 4199 gdb.reverse/solib-reverse.exp. 4200 4201 The failure happens around the following code: 4202 4203 38 b[1] = shr2(17); /* middle part two */ 4204 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ 4205 42 shr1 ("message 1\n"); /* shr1 one */ 4206 4207 Normal execution: 4208 4209 - step from line 38 will land on line 40. 4210 - step from line 40 will land on line 42. 4211 4212 Reverse execution: 4213 - step from line 42 will land on line 40. 4214 - step from line 40 will land on line 40. 4215 - step from line 40 will land on line 38. 4216 4217 The problem here is that line 40 contains two contiguous but distinct 4218 PC ranges in the line table, like so: 4219 4220 Line 40 - [0x7ec ~ 0x7f4] 4221 Line 40 - [0x7f4 ~ 0x7fc] 4222 4223 The two distinct ranges are generated because GCC started outputting source 4224 column information, which GDB doesn't take into account at the moment. 4225 4226 When stepping forward from line 40, we skip both of these ranges and land on 4227 line 42. When stepping backward from line 42, we stop at the start PC of the 4228 second (or first, going backwards) range of line 40. 4229 4230 Since we've reached ecs->event_thread->control.step_range_start, we stop 4231 stepping backwards. 4232 4233 The above issues were fixed by introducing a new function that looks for 4234 adjacent PC ranges for the same line, until we notice a line change. Then 4235 we take that as the start PC of the range. The new start PC for the range 4236 is used for the control.step_range_start when setting up a step range. 4237 4238 The test case gdb.reverse/map-to-same-line.exp is added to test the fix 4239 for the above reverse step issues. 4240 4241 Patch has been tested on PowerPC, X86 and AArch64 with no regressions. 4242 42432024-01-02 Carl Love <cel@us.ibm.com> 4244 4245 Add gdb_compile options column-info and no-column-info 4246 This patch adds two new options to gdb_compile to specify if the compile 4247 should or should not generate the line table information. The 4248 options are supported on clang and gcc version 7 and newer. 4249 4250 Patch has been tested on PowerPC with both gcc and clang. 4251 42522024-01-02 Guinevere Larsen <blarsen@redhat.com> 4253 4254 gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table 4255 This commit adds a mechanism for GDB to detect the linetable opcode 4256 DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate 4257 that a certain instruction marks the point where the frame is destroyed. 4258 4259 While the standard allows for multiple points marked with epilogue_begin 4260 in the same function, for performance reasons, the function that 4261 searches for the epilogue address will only find the last address that 4262 sets this flag for a given block. 4263 4264 This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to 4265 use the epilogue begin directly, and only if an epilogue can't be found 4266 will it attempt heuristics based on the current instruction. 4267 4268 Finally, this commit also changes the dwarf assembler to be able to emit 4269 epilogue-begin instructions, to make it easier to test this patch 4270 4271 Approved-By: Tom Tromey <tom@tromey.com> 4272 42732024-01-02 Mike Frysinger <vapier@gentoo.org> 4274 4275 sim: ppc: hoist pk.h creation to top-level 4276 4277 sim: ppc: hoist hw.[ch] creation to top-level 4278 4279 sim: ppc: hoist igen execution to top-level 4280 Invoke ppc's igen from the top-level like we do for all other ports. 4281 4282 sim: ppc: merge configure logic into top-level 4283 Now that the ppc configure script is just namespaced options, we can 4284 move it to ppc/acinclude.m4 and include it directly in the top-level 4285 configure script and kill off the last subdir configure script. 4286 4287 sim: ppc: scope configure options to --enable-sim-ppc-xxx 4288 To prepare for moving these into the top-level configure, namespace 4289 then with the port name like we do with all other ports. 4290 4291 sim: ppc: standardize configure option processing 4292 Switch from ad-hoc $silent checks & echo calls to standard 4293 AC_MSG_CHECKING & AC_MSG_RESULT calls. Also delete pointless 4294 variable setting after calling AC_MSG_ERROR. 4295 4296 sim: ppc: switch to AS_HELP_STRING for automatic formatting 4297 4298 sim: ppc: drop now unused config.in 4299 4300 sim: ppc: move defines.h generation to the top-level 4301 Since we rely on the top-level config.h now, the defines.h generation 4302 step should live here too. 4303 4304 sim: ppc: drop configure compiler checks 4305 Now that the ppc script only checks configure options and sets up 4306 variables in the Makefile from those, delete all the compile related 4307 logic to greatly simplify the configure script. 4308 4309 sim: ppc: drop custom config.h header 4310 Now that everything has moved to the top-level, we can drop the 4311 custom ppc config.h and reuse the common one. 4312 4313 sim: ppc: stop including headers from gdb/ 4314 The common sim code doesn't snoop in gdb/, and the ppc code doesn't 4315 need to either. Any common code we pull from gnulib/ now only. 4316 4317 sim: ppc: move termios probes to top-level 4318 This is the last compile-time logic in the ppc subdir. 4319 4320 sim: ppc: switch to AC_CACHE_CHECK 4321 This macro replaces the AC_MSG_CHECKING+AC_CACHE_VAL+AC_MSG_RESULT 4322 which reduces the boilerplate in here a little bit. 4323 4324 sim: ppc: switch struct member checks to AC_CHECK_MEMBER 4325 This covers a lot of the AC_MSG_CHECKING+AC_TRY_COMPILE+AC_MSG_RESULT 4326 boilerplate and matches what we do in the top-level platform checks. 4327 4328 sim: ppc: move termio defines to config.h 4329 Move the defines from explicit -D options to config.h defines to simplify 4330 the build and make it easier to move to the top-level configure. 4331 4332 sim: ppc: move struct statfs to top-level 4333 4334 sim: ppc: move long long test to top-level 4335 While the sim code doesn't utilize HAVE_LONG_LONG itself, other code 4336 (like libiberty) seem to, so check for it in the top-level for all 4337 ports to leverage. 4338 4339 sim: ppc: hoist sysv tests to top-level 4340 Now that the sysv tests turn into config.h defines and everything 4341 checks that, we can move the tests to the top-level and out of the 4342 ppc subdir. 4343 43442024-01-02 Mike Frysinger <vapier@gentoo.org> 4345 4346 sim: ppc: always compile in the sysv sem & shm device files 4347 Move the stub logic to the device files themselves. This makes the 4348 configure & build logic more static which will make it easier to move 4349 to the top-level build, and matches what we did with the common/ hw 4350 tree already. 4351 4352 This also decouples the logic from the two -- in the past, you needed 4353 both sem & shm in order to enable the device models, but now each one 4354 is tied to its own independent knob. Practically speaking, this will 4355 probably not make a difference, but it simplifies the build a bit. 4356 43572024-01-02 Mike Frysinger <vapier@gentoo.org> 4358 4359 sim: ppc: change SysV sem & shm tests to compile-time 4360 Instead of executing code to see if SysV semaphores & shared memory 4361 are available, switch to just a compile-time test. The system used 4362 to compile might not match the system used to run the code wrt the 4363 current kernel & OS settings, but the library APIs should. So move 4364 the failures from compile-time to runtime so the program is more 4365 portable, and works correctly even when cross-compiling. 4366 43672024-01-02 Mike Frysinger <vapier@gentoo.org> 4368 4369 sim: ppc: merge System V semaphores checks 4370 Compile tests can use earlier defines, so hoist the HAVE_UNION_SEMUN 4371 define to before the semaphore check, and use it in the test so that 4372 we can merge the 2 versions into one. 4373 4374 This also defines HAVE_UNION_SEMUN even when ac_cv_sysv_sem is not 4375 set, but that's OK as this define is only about a type existing, not 4376 about whether the overall code is usable. 4377 43782024-01-02 Mike Frysinger <vapier@gentoo.org> 4379 4380 sim: ppc: fix bad AC_CACHE_CHECK call with semun 4381 The first arg is the cache var name, and this one was typoed relative 4382 to what the call actually set. We also don't need the manual call to 4383 AC_MSG_RESULT as the AC_CACHE_CHECK takes care of it for us. 4384 4385 sim: ppc: delete unused build compile & link settings 4386 These should have been removed as part of the ppc/igen merging into the 4387 top-level, but they were missed. Clean up now. 4388 43892024-01-02 GDB Administrator <gdbadmin@sourceware.org> 4390 4391 Automatic date update in version.in 4392 43932024-01-01 Mike Frysinger <vapier@gentoo.org> 4394 4395 sim: ppc: merge misc igen APIs 4396 The common igen code provides the same misc APIs as the ppc version, 4397 so delete the ppc code and pull in the common one. There is one 4398 minor difference: the ppc code has a unique dumpf function. The 4399 common code switched to lf_printf for the same functionality, but 4400 since that requires changes throughout the igen codebase, delay that 4401 cleanup for now so we can merge the rest. 4402 4403 sim: ppc: rework igen error to match common 4404 Switch to an ERROR macro and tweak the error signature to match the 4405 common igen version in preparation for merging the two implementations. 4406 4407 sim: igen: extend error to take arguments 4408 The ppc igen error helper allows arbitrary printf calls, so extend 4409 the common one to do the same. 4410 4411 sim: ppc: rename igen max_insn_bit_size 4412 We want to avoid conflicts with the common igen enums. This should 4413 get migrated over to the common parsing logic, but for now, switch 4414 the name to avoid redefinition. 4415 4416 sim: igen: minor constify logic 4417 Copy some improvements from the ppc igen code. 4418 4419 sim: ppc: unify igen filter_filename implementations 4420 Now that both igen implementations are in the top-level, we can unify 4421 the filter_filename implementation between them since they're the same 4422 (literally the same code). 4423 4424 sim: ppc: replace filter_filename with lbasename 4425 The lbasename function from libiberty provides the same API as this 4426 custom function. The common/ code already made the switch, so make 4427 the same change to the ppc code to avoid target duplication. 4428 4429 sim: ppc: hoist igen compilation into top-level 4430 This simplifies the build a bit (especially for deps in port subdirs), 4431 and avoids recursive make. This in turn speeds up the build, and lets 4432 us reuse existing build-time vs host-time logic from Makefile.am. 4433 4434 sim: ppc: drop build-config.h usage 4435 This header is only used by the igen tool, and none of the igen code 4436 depends on the configure-time checks. Delete the logic to simplify 4437 to prepare for moving it to the local.mk code. 4438 4439 sim: ppc: simplify filter_host.c logic 4440 Switch this from a build-time generation to a static include. This 4441 makes the build rules a bit simpler, especially as we move them to 4442 Automake from hand-written makefiles. 4443 4444 sim: igen: remove libigen.a when cleaning 4445 4446 sim: ppc: drop unused host bitsize settings 4447 This is never set anywhere, so it's always empty. Scrub it. 4448 4449 sim: frv: fix cmpb uninitialized variable usage 4450 This code sets up the cc variable based on the comparison of other 4451 registers, but it does so incrementally with bit operations, and it 4452 never initializes the cc variable. Initialize it to 0 which the 4453 cmpba insn is already doing. 4454 4455 sim: arm: mark local read-only arrays as static const 4456 Move it into read-only data sections to avoid constructing them on the 4457 stack at runtime. 4458 4459 sim: warnings: enable -Wunused-variable 4460 4461 cpu: or1k: drop unused l.swa flag 4462 The "flag" argument isn't set/used in this insn, so drop it. 4463 This fixes an unused variable warning in the generated sim. 4464 44652024-01-01 Tom Tromey <tom@tromey.com> 4466 4467 sim: fix pervasive typo 4468 I noticed a typo in a sim constant. This patch fixes it. 4469 permenant -> permanent 4470 44712024-01-01 GDB Administrator <gdbadmin@sourceware.org> 4472 4473 Automatic date update in version.in 4474 44752023-12-31 Tom Tromey <tom@tromey.com> 4476 4477 Run 'black' on tui-window.py 4478 Mark pointed out that a recent patch of mine caused the buildbot to 4479 complain about the formatting of some Python test code. This patch 4480 re-runs 'black' to fix the problem. 4481 44822023-12-31 Tom de Vries <tdevries@suse.de> 4483 4484 [gdb/testsuite] Fix typo in gdb.base/catch-syscall.exp 4485 On aarch64-linux with a gdb build without libexpat, I run into: 4486 ... 4487 (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \ 4488 catch syscall 59 4489 continue 4490 Continuing. 4491 4492 Catchpoint 5 (call to syscall 59), 0x0000fffff7e04578 in pipe () from \ 4493 /lib64/libc.so.6 4494 (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue 4495 ... 4496 4497 In the test-case, this pattern handles either the syscall name or number for 4498 the pipe syscall: 4499 ... 4500 -re -wrap "Catchpoint $decimal \\(call to syscall (pipe|$SYS_pipe)\\).*" { 4501 ... 4502 but the pattern for the pipe2 syscall mistakenly uses SYS_pipe instead of 4503 SYS_pipe2: 4504 ... 4505 -re -wrap "Catchpoint $decimal \\(call to syscall (pipe2|$SYS_pipe)\\).*" { 4506 ... 4507 and consequently doesn't handle the pipe2 syscall number. 4508 4509 Fix the typo by using SYS_pipe2 instead. 4510 4511 Tested on aarch64-linux. 4512 45132023-12-31 GDB Administrator <gdbadmin@sourceware.org> 4514 4515 Automatic date update in version.in 4516 45172023-12-30 Tom Tromey <tom@tromey.com> 4518 4519 Add keywords to TuiWindow.write 4520 The gdb docs promise that methods with more than two or more arguments 4521 will accept keywords. However, I found that TuiWindow.write didn't 4522 allow them. This patch adds the missing support. 4523 45242023-12-30 Tom de Vries <tdevries@suse.de> 4525 4526 [gdb/testsuite] Fix gdb.base/gdb-index-err.exp for root user 4527 When running test-case gdb.base/gdb-index-err.exp in a container as root user, 4528 I run into: 4529 ... 4530 FAIL: gdb.base/gdb-index-err.exp: flag=: \ 4531 try to write index to a non-writable directory 4532 FAIL: gdb.base/gdb-index-err.exp: flag=-dwarf-5: \ 4533 try to write index to a non-writable directory 4534 ... 4535 4536 The test-case creates a directory without write permissions: 4537 ... 4538 $ ls -ald private 4539 dr-xr-xr-x 2 root root 4096 Dec 29 06:26 private/ 4540 ... 4541 but apparently the root user is still able to write in it. 4542 4543 Fix this by making the test unsupported for the root user. 4544 4545 Tested on x86_64-linux. 4546 4547 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 4548 4549 PR testsuite/31197 4550 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31197 4551 45522023-12-30 Alan Modra <amodra@gmail.com> 4553 4554 LoongArch: Commas inside double quotes 4555 This adds an extra feature: Commas inside double quotes are not an 4556 arg delimiter, and thus can be part of the arg. 4557 4558 * loongarch-coder.c (loongarch_split_args_by_comma): Commas 4559 inside quotes are not arg delimiters. 4560 45612023-12-30 Alan Modra <amodra@gmail.com> 4562 4563 Regen bfd-in2.h 4564 Please DON'T edit this file. READ THE COMMENT! 4565 45662023-12-30 Joseph Myers <jsm@polyomino.org.uk> 4567 4568 MAINTAINERS: Update my email address 4569 There will be another update in January. 4570 45712023-12-30 GDB Administrator <gdbadmin@sourceware.org> 4572 4573 Automatic date update in version.in 4574 45752023-12-29 H.J. Lu <hjl.tools@gmail.com> 4576 4577 x86: Append "#pass" to APX tests 4578 Append "#pass" to APX tests for targets which pad text sections with NOPs. 4579 4580 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Append 4581 "#pass". 4582 * testsuite/gas/i386/x86-64-apx-ndd-optimize.d: Likewise. 4583 * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. 4584 * testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: Likewise. 4585 * testsuite/gas/i386/x86-64-apx-pushp-popp.d: Likewise. 4586 45872023-12-29 H.J. Lu <hjl.tools@gmail.com> 4588 4589 x86: Don't use .insn with '/' 4590 '/' starts a comment for some targets. Use .byte instead of .insn with 4591 '/'. 4592 4593 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Use .byte 4594 instead of .insn with '/'. 4595 45962023-12-29 H.J. Lu <hjl.tools@gmail.com> 4597 4598 Fix x86-64: Add R_X86_64_CODE_4_GOTPCRELX 4599 commit 3d5a60de52556f6a53d71d7e607c6696450ae3e4 4600 Author: H.J. Lu <hjl.tools@gmail.com> 4601 Date: Thu Jun 8 10:01:03 2023 -0700 4602 4603 x86-64: Add R_X86_64_CODE_4_GOTPCRELX 4604 4605 added a new field, fx_tcbit3, to fix. But it didn't initialize it. 4606 Fix it by clearing it in fix_new_internal. 4607 4608 * wrtite.c (fix_new_internal): Clear fx_tcbit3. 4609 46102023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com> 4611 Bernhard Heckel <bernhard.heckel@intel.com> 4612 Tim Wiederhake <tim.wiederhake@intel.com> 4613 4614 dwarf, fortran: add support for DW_TAG_entry_point 4615 Fortran provides additional entry points for subroutines and functions. 4616 These entry points may use only a subset (or a different set) of the 4617 parameters of the original subroutine. The entry points may be described 4618 via the DWARF tag DW_TAG_entry_point. 4619 4620 This commit adds support for parsing the DW_TAG_entry_point DWARF tag. 4621 Currently, between ifx/ifort/gfortran, only ifort is actually emitting 4622 this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as 4623 workaround/alternative. Thus, this patch really only adds more ifort 4624 support. Even so, some of the attached tests still fail for ifort, due 4625 to some wrong line info generated for the entry points in ifort. 4626 4627 After this patch it is possible to set a breakpoint in gdb with the 4628 ifort compiled example at the entry points 'foo' and 'foobar', which was not 4629 possible before. 4630 4631 As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2 4632 which uses some underlying c compiled code and adds some Fortran style DWARF 4633 to it emitting the DW_TAG_entry_point. Before this patch it was not 4634 possible to actually define breakpoint at the entry point tags. 4635 4636 For gfortran there actually exists a bug on bugzilla, asking for the use 4637 of DW_TAG_entry_point over DW_TAG_subprogram: 4638 4639 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134 4640 4641 This patch was originally posted here 4642 4643 https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html 4644 4645 but its review/pinging got lost after a while. I reworked it to fit the 4646 current GDB. 4647 4648 Approved-by: Tom Tromey <tom@tromey.com> 4649 46502023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com> 4651 4652 gdb, dwarf: add assert to dwarf2_get_pc_bounds 4653 In dwarf2_get_pc_bounds we were writing unchecked to *lowpc. This 4654 commit adds a gdb_assert to first check that lowpc != nullptr. 4655 4656 Approved-by: Tom Tromey <tom@tromey.com> 4657 46582023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com> 4659 4660 gdb, dwarf: move part of dwarf2_get_pc_bounds into separate function 4661 This commit is in preparation of the next commit. There, we will add 4662 a second variation to retrieve the pc bounds for DIEs tagged with 4663 DW_TAG_entry_point. Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc 4664 we will call a separate method for entry points. As the validity checks 4665 at the endo f dwarf2_get_pc_bounds are the same for both variants, 4666 we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method, 4667 outsourcing part of dwarf2_get_pc_bounds. 4668 4669 This commit should have no functional impact on GDB. 4670 4671 Approved-by: Tom Tromey <tom@tromey.com> 4672 46732023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn> 4674 4675 LoongArch: ld: Add support for tls le relax. 4676 Add tls le relax related testsuites in ld. 4677 4678 The new test cases are mainly tested in three aspects: 4679 4680 1. tls le relax function correctness test. 4681 2. tls le relax boundary check test. 4682 3. tls le relax function compatibility test. 4683 4684 ld/testsuite/ChangeLog: 4685 4686 * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test. 4687 * ld/testsuite/ld-loongarch-elf/old-tls-le.s: New test. 4688 * ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s: Likewise. 4689 * ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s: Likewise. 4690 * ld/testsuite/ld-loongarch-elf/relax-tls-le.s: Likewise. 4691 * ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s: Likewise. 4692 46932023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn> 4694 4695 LoongArch: gas: Add support for tls le relax. 4696 Add tls le relax related relocs support and testsuites in gas. 4697 4698 The main test is three new relocation items, 4699 R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_HI20_R, 4700 R_LARCH_TLS_LE_LO12_R can be generated properly 4701 and tls le insn format check. 4702 4703 gas/ChangeLog: 4704 4705 * config/tc-loongarch.c: 4706 (loongarch_args_parser_can_match_arg_helper): Add support for relax. 4707 * gas/testsuite/gas/loongarch/reloc.d: Likewise. 4708 * gas/testsuite/gas/loongarch/reloc.s: Likewise. 4709 * gas/testsuite/gas/loongarch/loongarch.exp: Likewise. 4710 * gas/testsuite/gas/loongarch/tls_le_insn_format_check.s: New test. 4711 47122023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn> 4713 4714 LoongArch: opcodes: Add support for tls le relax. 4715 Add new opcode for tls le relax. 4716 4717 opcode/ChangeLog: 4718 4719 * loongarch-opc.c: Add new loongarch opcode. 4720 47212023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn> 4722 4723 LoongArch: include: Add support for tls le relax. 4724 Add new relocs number for tls le relax. 4725 4726 include/ChangeLog: 4727 4728 * elf/loongarch.h: 4729 (RELOC_NUMBER (R_LARCH_TLS_LE_HI20_R, 121)): New relocs number. 4730 (RELOC_NUMBER (R_LARCH_TLS_LE_ADD_R, 122)): Likewise. 4731 (RELOC_NUMBER (R_LARCH_TLS_LE_LO12_R, 123)): Likewise. 4732 47332023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn> 4734 4735 LoongArch: bfd: Add support for tls le relax. 4736 Add tls le relax support and related relocs in bfd. 4737 4738 New relocation related explanation can refer to the following url: 4739 https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc 4740 4741 This support does two main things: 4742 4743 1. Implement support for three new relocation items in bfd. 4744 4745 The three new relocation items are shown below: 4746 4747 R_LARCH_TLS_LE_ADD_R 4748 R_LARCH_TLS_LE_HI20_R 4749 R_LARCH_TLS_LE_LO12_R 4750 4751 2. ADD a new macro RELOCATE_TLS_TP32_HI20 4752 4753 Handle problems caused by symbol extensions in TLS LE, The processing 4754 is similar to the macro RELOCATE_CALC_PC32_HI20 method. 4755 4756 3. Implement the tls le relax function. 4757 4758 bfd/ChangeLog: 4759 4760 * bfd-in2.h: Add relocs related to tls le relax. 4761 * elfnn-loongarch.c: 4762 (loongarch_relax_tls_le): New function. 4763 (RELOCATE_TLS_TP32_HI20): New macro. 4764 (loongarch_elf_check_relocs): Add new reloc support. 4765 (perform_relocation): Likewise. 4766 (loongarch_elf_relocate_section): Handle new relocs related to relax. 4767 (loongarch_elf_relax_section): Likewise. 4768 * elfxx-loongarch.c: 4769 (LOONGARCH_HOWTO (R_LARCH_TLS_LE_ADD_R)): New reloc how to type. 4770 (LOONGARCH_HOWTO (R_LARCH_TLS_LE_HI20_R)): Likewise. 4771 (LOONGARCH_HOWTO (R_LARCH_TLS_LE_LO12_R)): Likewise. 4772 * libbfd.h: Add relocs related to tls le relax. 4773 * reloc.c: Likewise. 4774 47752023-12-29 Jin Ma <jinma@linux.alibaba.com> 4776 4777 RISC-V: THEAD: Add 5 assembly pseudoinstructions for XTheadVector extension 4778 In order to make it easier to complete the compiler's support for 4779 the XTheadVector extension and to be as compatible as possible 4780 with the programming model of the 'V' extension ([1]), we consider 4781 adding a few pseudo instructions ([2]). 4782 4783 th.vmmv.m vd,vs => th.vmand.mm vd,vs,vs 4784 th.vneg.v vd,vs => th.vrsub.vx vd,vs,x0 4785 th.vncvt.x.x.v vd,vs,vm => th.vnsrl.vx vd,vs,x0,vm 4786 th.vfneg.v vd,vs => th.vfsgnjn.vv vd,vs,vs 4787 th.vfabs.v vd,vs => th.vfsgnjx.vv vd,vs,vs 4788 4789 Ref: 4790 [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641302.html 4791 [2] https://github.com/T-head-Semi/thead-extension-spec/pull/40 4792 4793 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 4794 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 4795 4796 gas/ChangeLog: 4797 4798 * testsuite/gas/riscv/x-thead-vector.d: Add tests for new 4799 pseudoinstructions. 4800 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 4801 4802 opcodes/ChangeLog: 4803 4804 * riscv-opc.c: Add new pseudoinstructions. 4805 48062023-12-29 GDB Administrator <gdbadmin@sourceware.org> 4807 4808 Automatic date update in version.in 4809 48102023-12-28 H.J. Lu <hjl.tools@gmail.com> 4811 4812 ld: Mention support for Intel APX relocations in NEWS 4813 48142023-12-28 H.J. Lu <hjl.tools@gmail.com> 4815 4816 Gold: Handle R_X86_64_CODE_4_GOTPC32_TLSDESC/R_X86_64_CODE_4_GOTTPOFF 4817 Handle R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC. 4818 Convert 4819 4820 add name@gottpoff(%rip), %reg 4821 mov name@gottpoff(%rip), %reg 4822 4823 to 4824 4825 add $name@tpoff, %reg 4826 mov $name@tpoff, %reg 4827 4828 and 4829 4830 lea name@tlsdesc(%rip), %reg 4831 4832 to 4833 4834 mov $name@tpoff, %reg 4835 mov name@gottpoff(%rip), %reg 4836 4837 if the instruction is encoded with the REX2 prefix when possible. 4838 4839 elfcpp/ 4840 4841 * x86_64.h (R_X86_64_CODE_4_GOTTPOFF): New. 4842 (R_X86_64_CODE_4_GOTPC32_TLSDESC): Likewise. 4843 4844 gold/ 4845 4846 * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle 4847 R_X86_64_CODE_4_GOTPC32_TLSDESC and R_X86_64_CODE_4_GOTTPOFF. 4848 (Target_x86_64::Scan::get_reference_flags): Likewise. 4849 (Target_x86_64::Scan::local): Likewise. 4850 (Target_x86_64::Scan::global): Likewise. 4851 (Target_x86_64::Relocate::relocate): Likewise. 4852 (Target_x86_64::Relocate::relocate_tls): Likewise. 4853 (Target_x86_64::Relocate::tls_desc_gd_to_ie): Handle 4854 R_X86_64_CODE_4_GOTPC32_TLSDESC. 4855 (Target_x86_64::Relocate::tls_desc_gd_to_le): Likewise. 4856 (Target_x86_64::Relocate::tls_ie_to_le): Handle. 4857 R_X86_64_CODE_4_GOTTPOFF. 4858 * testsuite/Makefile.am: Add x86_64_ie_to_le test. 4859 * testsuite/Makefile.in: Regenerated. 4860 * testsuite/x86_64_gd_to_le.s: Add R_X86_64_CODE_4_GOTPC32_TLSDESC 4861 test. 4862 * testsuite/x86_64_gd_to_le.sh: Check GDesc to LE conversion. 4863 * testsuite/x86_64_ie_to_le.s: New file. 4864 * testsuite/x86_64_ie_to_le.sh: Likewise. 4865 48662023-12-28 H.J. Lu <hjl.tools@gmail.com> 4867 4868 x86-64: Add R_X86_64_CODE_4_GOTTPOFF/R_X86_64_CODE_4_GOTPC32_TLSDESC 4869 For 4870 4871 add name@gottpoff(%rip), %reg 4872 mov name@gottpoff(%rip), %reg 4873 4874 add 4875 4876 # define R_X86_64_CODE_4_GOTTPOFF 44 4877 4878 and for 4879 4880 lea name@tlsdesc(%rip), %reg 4881 4882 add 4883 4884 # define R_X86_64_CODE_4_GOTPC32_TLSDESC 45 4885 4886 if the instruction starts at 4 bytes before the relocation offset. 4887 They are similar to R_X86_64_GOTTPOFF and R_X86_64_GOTPC32_TLSDESC, 4888 respectively. Linker can covert GOTTPOFF to 4889 4890 add $name@tpoff, %reg 4891 mov $name@tpoff, %reg 4892 4893 and GOTPC32_TLSDESC to 4894 4895 mov $name@tpoff, %reg 4896 mov name@gottpoff(%rip), %reg 4897 4898 if the instruction is encoded with the REX2 prefix when possible. 4899 4900 bfd/ 4901 4902 * elf64-x86-64.c (x86_64_elf_howto_table): Add 4903 R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC. 4904 (R_X86_64_standard): Updated. 4905 (x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTTPOFF 4906 and BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC. 4907 (elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_4_GOTTPOFF 4908 and R_X86_64_CODE_4_GOTPC32_TLSDESC. 4909 (elf_x86_64_tls_transition): Likewise. 4910 (elf_x86_64_scan_relocs): Likewise. 4911 (elf_x86_64_relocate_section): Likewise. 4912 * reloc.c (bfd_reloc_code_real): Add 4913 BFD_RELOC_X86_64_CODE_4_GOTTPOFF and 4914 BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC. 4915 * bfd-in2.h: Regenerated. 4916 * libbfd.h: Likewise. 4917 4918 gas/ 4919 4920 * config/tc-i386.c (tc_i386_fix_adjustable): Handle 4921 BFD_RELOC_X86_64_CODE_4_GOTTPOFF and 4922 BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC. 4923 (md_assemble): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF. 4924 (output_insn): Don't add empty REX prefix with REX2 prefix. 4925 (output_disp): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and 4926 BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC. 4927 (md_apply_fix): Likewise. 4928 (i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTTPOFF or 4929 BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC if ixp->fx_tcbit3 is set. 4930 (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and 4931 BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC. 4932 * testsuite/gas/i386/x86-64-gottpoff.d: New file. 4933 * testsuite/gas/i386/x86-64-gottpoff.s: Likewise. 4934 * testsuite/gas/i386/x86-64-tlsdesc.d: Likewise. 4935 * testsuite/gas/i386/x86-64-tlsdesc.s: Likewise. 4936 4937 include/ 4938 4939 * elf/x86-64.h (elf_x86_64_reloc_type): Add 4940 R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC 4941 4942 ld/ 4943 4944 * testsuite/ld-x86-64/tlsbindesc.d: Updated. 4945 * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. 4946 * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_4_GOTTPOFF 4947 and R_X86_64_CODE_4_GOTPC32_TLSDESC tests. 4948 49492023-12-28 H.J. Lu <hjl.tools@gmail.com> 4950 4951 gold: Handle R_X86_64_CODE_4_GOTPCRELX 4952 Handle R_X86_64_CODE_4_GOTPCRELX and convert 4953 4954 mov name@GOTPCREL(%rip), %r31 4955 4956 to 4957 4958 lea name@GOTPCREL(%rip), %r31 4959 4960 if the instruction is encoded with the REX2 prefix when possible. 4961 4962 elfcpp/ 4963 4964 * x86_64.h (R_X86_64_CODE_4_GOTPCRELX): New. 4965 4966 gold/ 4967 4968 * x86_64.cc (Target_x86_64::can_convert_mov_to_lea): Handle 4969 R_X86_64_CODE_4_GOTPCRELX. 4970 (Target_x86_64::Scan::get_reference_flags): Likewise. 4971 (Target_x86_64::Scan::local): Likewise. 4972 (Target_x86_64::Scan::possible_function_pointer_reloc): Likewise. 4973 (Target_x86_64::Scan::global): Likewise. 4974 (Target_x86_64::Relocate::relocate): Likewise. 4975 * testsuite/x86_64_mov_to_lea1.s: Add a test for 4976 R_X86_64_CODE_4_GOTPCRELX. 4977 * testsuite/x86_64_mov_to_lea2.s: Likewise. 4978 * testsuite/x86_64_mov_to_lea3.s: Likewise. 4979 * testsuite/x86_64_mov_to_lea4.s: Likewise. 4980 * testsuite/x86_64_mov_to_lea5.s: Likewise. 4981 * testsuite/x86_64_mov_to_lea.sh: Updated. 4982 49832023-12-28 H.J. Lu <hjl.tools@gmail.com> 4984 4985 x86-64: Add R_X86_64_CODE_4_GOTPCRELX 4986 For 4987 4988 mov name@GOTPCREL(%rip), %reg 4989 test %reg, name@GOTPCREL(%rip) 4990 binop name@GOTPCREL(%rip), %reg 4991 4992 where binop is one of adc, add, add, cmp, or, sbb, sub, xor instructions, 4993 add 4994 4995 # define R_X86_64_CODE_4_GOTPCRELX 43 4996 4997 if the instruction starts at 4 bytes before the relocation offset. It 4998 similar to R_X86_64_GOTPCRELX. Linker can treat R_X86_64_CODE_4_GOTPCRELX 4999 as R_X86_64_GOTPCREL or convert the above instructions to 5000 5001 lea name(%rip), %reg 5002 mov $name, %reg 5003 test $name, %reg 5004 binop $name, %reg 5005 5006 if the instruction is encoded with the REX2 prefix when possible. 5007 5008 bfd/ 5009 5010 * elf64-x86-64.c (x86_64_elf_howto_table): Add 5011 R_X86_64_CODE_4_GOTPCRELX. 5012 (R_X86_64_standard): Updated. 5013 (x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTPCRELX. 5014 (elf_x86_64_convert_load_reloc): Handle R_X86_64_CODE_4_GOTPCRELX. 5015 (elf_x86_64_scan_relocs): Likewise. 5016 (elf_x86_64_relocate_section): Likewise. 5017 * reloc.c (bfd_reloc_code_real): Add 5018 BFD_RELOC_X86_64_CODE_4_GOTPCRELX. 5019 * bfd-in2.h: Regenerated. 5020 * libbfd.h: Likewise. 5021 5022 gas/ 5023 5024 * write.h (fix): Add fx_tcbit3. Change fx_unused to 1 bit. 5025 * config/tc-i386.c (tc_i386_fix_adjustable): Handle 5026 BFD_RELOC_X86_64_CODE_4_GOTPCRELX. 5027 (tc_gen_reloc): Likewise. 5028 (output_disp): Set fixP->fx_tcbit3 for REX2 prefix. 5029 (i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTPCRELX 5030 if fixp->fx_tcbit3 is set. 5031 * config/tc-i386.h (TC_FORCE_RELOCATION_LOCAL): Add 5032 BFD_RELOC_X86_64_CODE_4_GOTPCRELX. 5033 (TC_FORCE_RELOCATION_ABS): Likewise. 5034 * testsuite/gas/i386/x86-64-gotpcrel.s: Add tests for 5035 R_X86_64_CODE_4_GOTPCRELX. 5036 * testsuite/gas/i386/x86-64-localpic.s: Likewise. 5037 * testsuite/gas/i386/x86-64-gotpcrel.d: Updated. 5038 * testsuite/gas/i386/x86-64-localpic.d: Likewise. 5039 * testsuite/gas/i386/ilp32/x86-64-localpic.d: Likewise. 5040 5041 include/ 5042 5043 * elf/x86-64.h (elf_x86_64_reloc_type): Add 5044 R_X86_64_CODE_4_GOTPCRELX. 5045 5046 ld/ 5047 5048 * testsuite/ld-x86-64/apx-load1.s: New file. 5049 * testsuite/ld-x86-64/apx-load1a.d: Likewise. 5050 * testsuite/ld-x86-64/apx-load1b.d: Likewise. 5051 * testsuite/ld-x86-64/apx-load1c.d: Likewise. 5052 * testsuite/ld-x86-64/apx-load1d.d: Likewise. 5053 * testsuite/ld-x86-64/x86-64.exp: Run apx-load1a, apx-load1b, 5054 apx-load1c and apx-load1d. 5055 50562023-12-28 H.J. Lu <hjl.tools@gmail.com> 5057 5058 gas: Mention initial support for Intel APX in NEWS 5059 50602023-12-28 Schimpe, Christina <christina.schimpe@intel.com> 5061 5062 x86: Add NT_X86_SHSTK note 5063 Define NT_X86_SHSTK which is the note for x86 Shadow Stack (SHSTK) to 5064 support Intel SHSTK in Linux kernel. 5065 For now only userspace shadow stack and kernel IBT are supported by the 5066 linux kernel. This note should be used instead of NT_X86_CET introduced 5067 in the commit "x86: Add NT_X86_CET note", as it is outdated and only 5068 used by old binutils versions. 5069 50702023-12-28 Hu, Lin1 <lin1.hu@intel.com> 5071 5072 Support APX JMPABS for disassembler 5073 gas/ChangeLog: 5074 5075 * testsuite/gas/i386/x86-64.exp: Ditto. 5076 * testsuite/gas/i386/x86-64-apx-jmpabs-intel.d: Ditto. 5077 * testsuite/gas/i386/x86-64-apx-jmpabs-inval.d: Ditto. 5078 * testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Ditto. 5079 * testsuite/gas/i386/x86-64-apx-jmpabs.d: Ditto. 5080 * testsuite/gas/i386/x86-64-apx-jmpabs.s: Ditto. 5081 5082 opcodes/ChangeLog: 5083 5084 * i386-dis.c (JMPABS_Fixup): New Fixup function to disassemble jmpabs. 5085 (print_insn): Add #UD exception for jmpabs. 5086 (dis386): Modify a1 unit for support jmpabs. 5087 * i386-mnem.h: Regenerated. 5088 * i386-opc.tbl: New insns. 5089 * i386-tbl.h: Regenerated. 5090 50912023-12-28 Hu, Lin1 <lin1.hu@intel.com> 5092 5093 Support APX NDD optimized encoding. 5094 This patch aims to optimize: 5095 5096 add %r16, %r15, %r15 -> add %r16, %r15 5097 5098 gas/ChangeLog: 5099 5100 * config/tc-i386.c (check_Rex_required): New function. 5101 (can_convert_NDD_to_legacy): Ditto. 5102 (match_template): If we can optimzie APX NDD insns, so rematch 5103 template. 5104 * testsuite/gas/i386/x86-64.exp: Add test. 5105 * testsuite/gas/i386/x86-64-apx-ndd-optimize.d: New test. 5106 * testsuite/gas/i386/x86-64-apx-ndd-optimize.s: Ditto. 5107 51082023-12-28 Cui, Lili <lili.cui@intel.com> 5109 5110 Support APX pushp/popp 5111 gas/ChangeLog: 5112 5113 * config/tc-i386.c (process_operands): Handle "PUSHP/POPP requires 5114 rex2.w == 1." 5115 * testsuite/gas/i386/x86-64.exp: Add new test for PUSHP/POPP. 5116 * testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: New test. 5117 * testsuite/gas/i386/x86-64-apx-pushp-popp-inval.l: Ditto. 5118 * testsuite/gas/i386/x86-64-apx-pushp-popp-inval.s: Ditto. 5119 * testsuite/gas/i386/x86-64-apx-pushp-popp.d: Ditto. 5120 * testsuite/gas/i386/x86-64-apx-pushp-popp.s: Ditto. 5121 5122 opcodes/ChangeLog: 5123 5124 * i386-dis.c (putop): print pushp and popp. 5125 * i386-opc.tbl: Added new insns. 5126 * i386-init.h : Regenerated. 5127 * i386-mnem.h : Regenerated. 5128 * i386-tbl.h: Regenerated. 5129 51302023-12-28 Mo, Zewei <zewei.mo@intel.com> 5131 5132 Support APX Push2/Pop2 5133 PPX functionality for PUSH/POP is not implemented in this patch 5134 and will be implemented separately. 5135 5136 gas/ChangeLog: 5137 5138 2023-12-28 Zewei Mo <zewei.mo@intel.com> 5139 H.J. Lu <hongjiu.lu@intel.com> 5140 Lili Cui <lili.cui@intel.com> 5141 5142 * config/tc-i386.c: (enum i386_error): 5143 New unsupported_rsp_register and invalid_src_register_set. 5144 (md_assemble): Add handler for unsupported_rsp_register and 5145 invalid_src_register_set. 5146 (check_APX_operands): Add invalid check for push2/pop2. 5147 (match_template): Handle check_APX_operands. 5148 * testsuite/gas/i386/i386.exp: Add apx-push2pop2 tests. 5149 * testsuite/gas/i386/x86-64.exp: Ditto. 5150 * testsuite/gas/i386/x86-64-apx-push2pop2.d: New test. 5151 * testsuite/gas/i386/x86-64-apx-push2pop2.s: Ditto. 5152 * testsuite/gas/i386/x86-64-apx-push2pop2-intel.d: Ditto. 5153 * testsuite/gas/i386/x86-64-apx-push2pop2-inval.l: Ditto. 5154 * testsuite/gas/i386/x86-64-apx-push2pop2-inval.s: Ditto. 5155 * testsuite/gas/i386/apx-push2pop2-inval.s: Ditto. 5156 * testsuite/gas/i386/apx-push2pop2-inval.d: Ditto. 5157 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added bad 5158 testcases for POP2. 5159 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. 5160 5161 opcodes/ChangeLog: 5162 5163 * i386-dis-evex-reg.h: Add REG_EVEX_MAP4_8F. 5164 * i386-dis-evex-w.h: Add EVEX_W_MAP4_8F_R_0 and EVEX_W_MAP4_FF_R_6 5165 * i386-dis-evex.h: Add REG_EVEX_MAP4_8F. 5166 * i386-dis.c (PUSH2_POP2_Fixup): Add special handling for PUSH2/POP2. 5167 (get_valid_dis386): Add handler for vector length and address_mode for 5168 APX-Push2/Pop2 insn. 5169 (nd): define nd as b for EVEX-promoted instrutions. 5170 (OP_VEX): Add handler of 64-bit vvvv register for APX-Push2/Pop2 insn. 5171 * i386-gen.c: Add Push2Pop2 bitfield. 5172 * i386-opc.h: Regenerated. 5173 * i386-opc.tbl: Regenerated. 5174 51752023-12-28 konglin1 <lingling.kong@intel.com> 5176 5177 Support APX NDD 5178 opcodes/ChangeLog: 5179 5180 * opcodes/i386-dis-evex-reg.h: Handle for REG_EVEX_MAP4_80, 5181 REG_EVEX_MAP4_81, REG_EVEX_MAP4_83, REG_EVEX_MAP4_F6, 5182 REG_EVEX_MAP4_F7, REG_EVEX_MAP4_FE, REG_EVEX_MAP4_FF. 5183 * opcodes/i386-dis-evex.h: Add NDD insn. 5184 * opcodes/i386-dis.c (nd): New define. 5185 (VexGb): Ditto. 5186 (VexGv): Ditto. 5187 (get_valid_dis386): Change for NDD decode. 5188 (print_insn): Ditto. 5189 (putop): Ditto. 5190 (intel_operand_size): Ditto. 5191 (OP_E_memory): Ditto. 5192 (OP_VEX): Ditto. 5193 * opcodes/i386-opc.h (VexVVVV_DST): New. 5194 * opcodes/i386-opc.tbl: Add APX NDD instructions and adjust VexVVVV. 5195 * opcodes/i386-tbl.h: Regenerated. 5196 5197 gas/ChangeLog: 5198 5199 * gas/config/tc-i386.c (operand_size_match): 5200 Support APX NDD that the number of operands is 3. 5201 (build_apx_evex_prefix): Change for ndd encode. 5202 (process_operands): Ditto. 5203 (build_modrm_byte): Ditto. 5204 (match_template): Support swap the first two operands for 5205 APX NDD. 5206 * testsuite/gas/i386/x86-64.exp: Add x86-64-apx-ndd. 5207 * testsuite/gas/i386/x86-64-apx-ndd.d: New test. 5208 * testsuite/gas/i386/x86-64-apx-ndd.s: Ditto. 5209 * testsuite/gas/i386/x86-64-pseudos.d: Add test. 5210 * testsuite/gas/i386/x86-64-pseudos.s: Ditto. 5211 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d : Ditto. 5212 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s : Ditto. 5213 52142023-12-28 Cui, Lili <lili.cui@intel.com> 5215 5216 Add tests for APX GPR32 with extend evex prefix 5217 gas/ChangeLog: 5218 5219 2023-12-28 Lingling Kong <lingling.kong@intel.com> 5220 H.J. Lu <hongjiu.lu@intel.com> 5221 Lili Cui <lili.cui@intel.com> 5222 Lin Hu <lin1.hu@intel.com> 5223 5224 * testsuite/gas/i386/x86-64-apx-egpr-inval.l: Add some insn don't 5225 support gpr32. 5226 * testsuite/gas/i386/x86-64-apx-egpr-inval.s: Ditto. 5227 * testsuite/gas/i386/x86-64.exp: Add new test. 5228 * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: New test. 5229 * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: New test. 5230 * testsuite/gas/i386/x86-64-apx-evex-egpr.d: New test. 5231 * testsuite/gas/i386/x86-64-apx-evex-egpr.s: New test. 5232 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: New test. 5233 * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: New test. 5234 * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: New test. 5235 * testsuite/gas/i386/x86-64-apx-evex-promoted.d: New test. 5236 * testsuite/gas/i386/x86-64-apx-evex-promoted.s: New test. 5237 52382023-12-28 Cui, Lili <lili.cui@intel.com> 5239 5240 Support APX GPR32 with extend evex prefix 5241 This patch adds non-ND, non-NF forms of EVEX promotion insn. 5242 5243 EVEX extension of legacy instructions: 5244 All promoted legacy instructions are placed in EVEX map 4, which is 5245 currently reserved. 5246 EVEX extension of EVEX instructions: 5247 All existing EVEX instructions are extended by APX using the extended 5248 EVEX prefix, so that they can access all 32 GPRs. 5249 EVEX extension of VEX instructions: 5250 Promoting a VEX instruction into the EVEX space does not change the map 5251 id, the opcode, or the operand encoding of the VEX instruction. 5252 5253 Note: The promoted versions of MOVBE will be extended to include the “MOVBE 5254 reg1, reg2”. 5255 5256 gas/ChangeLog: 5257 5258 2023-12-28 Lingling Kong <lingling.kong@intel.com> 5259 H.J. Lu <hongjiu.lu@intel.com> 5260 Lili Cui <lili.cui@intel.com> 5261 Lin Hu <lin1.hu@intel.com> 5262 5263 * config/tc-i386.c (struct _i386_insn): Add has_egpr. 5264 (need_evex_encoding): Adjusted for apx. 5265 (cpu_flags_match): Ditto. 5266 (install_template): Handled APX combines. 5267 (is_apx_evex_encoding): Test apx evex encoding. 5268 (build_apx_evex_prefix): Enabe APX evex prefix. 5269 (md_assemble): Handle apx with evex encoding. 5270 (process_suffix): Handle apx map4 prefix. 5271 (check_register): Assign i.vec_encoding for APX evex instructions. 5272 * testsuite/gas/i386/x86-64-evex.d: Adjust test cases. 5273 * testsuite/gas/i386/x86-64.exp: Adjust x86-64-inval-movbe. 5274 5275 opcodes/ChangeLog: 5276 5277 * i386-dis-evex-len.h: Handle EVEX_LEN_0F38F2, EVEX_LEN_0F38F3. 5278 * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_0F38F2_L_0, 5279 PREFIX_EVEX_0F38F3_L_0, PREFIX_EVEX_MAP4_D8, 5280 PREFIX_EVEX_MAP4_DA, PREFIX_EVEX_MAP4_DB, 5281 PREFIX_EVEX_MAP4_DC, PREFIX_EVEX_MAP4_DD, 5282 PREFIX_EVEX_MAP4_DE, PREFIX_EVEX_MAP4_DF, 5283 PREFIX_EVEX_MAP4_F0, PREFIX_EVEX_MAP4_F1, 5284 PREFIX_EVEX_MAP4_F2, PREFIX_EVEX_MAP4_F8. 5285 * i386-dis-evex-reg.h: Handle REG_EVEX_0F38F3_L_0_P_0. 5286 * i386-dis-evex.h: Add EVEX_MAP4_ for legacy insn 5287 promote to apx to use gpr32 5288 * opcodes/i386-dis-evex-x86-64.h: Handle Add X86_64_EVEX_0F90, 5289 X86_64_EVEX_0F92, X86_64_EVEX_0F93, X86_64_EVEX_0F38F2, 5290 X86_64_EVEX_0F38F3, X86_64_EVEX_0F38F5, X86_64_EVEX_0F38F6, 5291 X86_64_EVEX_0F38F7, X86_64_EVEX_0F3AF0, X86_64_EVEX_0F91. 5292 * i386-dis.c 5293 (struct instr_info): Deleted bool r. 5294 (PREFIX_NP_OR_DATA): New. 5295 (NO_PREFIX): New. 5296 (putop): Ditto. 5297 (X86_64_EVEX_FROM_VEX_TABLE): Diito. 5298 (get_valid_dis386): Decode insn erex in extend evex prefix. 5299 Handle EVEX_MAP4 5300 (print_insn): Handle PREFIX_DATA_AND_NP_ONLY. 5301 (print_register): Handle apx instructions decode. 5302 (OP_E_memory): Diito. 5303 (OP_G): Diito. 5304 (OP_XMM): Diito. 5305 (DistinctDest_Fixup): Diito. 5306 * i386-gen.c (process_i386_opcode_modifier): Add EVEXMAP4. 5307 * i386-opc.h (SPACE_EVEXMAP4): Add legacy insn 5308 promote to evex. 5309 * i386-opc.tbl: Handle some legacy and vex insns don't 5310 support gpr32. And add some legacy insn (map2 / 3) promote 5311 to evex. 5312 53132023-12-28 Cui, Lili <lili.cui@intel.com> 5314 5315 Created an empty EVEX_MAP4_ sub-table for EVEX instructions. 5316 opcode/ChangeLog: 5317 5318 * i386-dis-evex.hi: Added an empty EVEX_MAP4_ sub-table for 5319 legacy insn promote to EVEX insn. 5320 * opcodes/i386-dis-evex.h: Add EVEX_MAP4. 5321 53222023-12-28 Cui, Lili <lili.cui@intel.com> 5323 5324 Support APX GPR32 with rex2 prefix 5325 APX uses the REX2 prefix to support EGPR for map0 and map1 of legacy 5326 instructions. We added the NoEgpr flag in i386-gen.c for instructions 5327 that do not support EGPR. 5328 5329 gas/ChangeLog: 5330 5331 2023-12-28 Lingling Kong <lingling.kong@intel.com> 5332 H.J. Lu <hongjiu.lu@intel.com> 5333 Lili Cui <lili.cui@intel.com> 5334 Lin Hu <lin1.hu@intel.com> 5335 5336 * config/tc-i386.c 5337 (enum i386_error): Add unsupported_EGPR_for_addressing 5338 and invalid_pseudo_prefix. 5339 (struct _i386_insn): Add rex2 and rex2_encoding for 5340 gpr32. 5341 (cpu_arch): Add apx_f. 5342 (is_cpu): Ditto. 5343 (register_number): Handle RegRex2 for gpr32. 5344 (is_apx_rex2_encoding): New func. Test rex2 prefix encoding. 5345 (build_rex2_prefix): New func. Build legacy insn in 5346 opcode 0/1 use gpr32 with rex2 prefix. 5347 (establish_rex): Handle rex2 and rex2_encoding. 5348 (optimize_encoding): Handel add r16-r31 for registers. 5349 (md_assemble): Handle apx encoding. 5350 (parse_insn): Handle Prefix_REX2. 5351 (check_EgprOperands): New func. Check if Egprs operands 5352 are valid for the instruction 5353 (match_template): Handle Egpr operands check. 5354 (set_rex_rex2): New func. set i.rex and i.rex2. 5355 (build_modrm_byte): Ditto. 5356 (output_insn): Handle rex2 2-byte prefix output. 5357 (check_register): Handle check egpr illegal without 5358 target apx, 64-bit mode and with rex_prefix. 5359 * doc/c-i386.texi: Document .apx. 5360 * testsuite/gas/i386/ilp32/x86-64-opcode-inval-intel.d: D5 valid 5361 in 64-bit mode. 5362 * testsuite/gas/i386/ilp32/x86-64-opcode-inval.d: Ditto. 5363 * testsuite/gas/i386/rex-bad: Adjust rex testcase. 5364 * testsuite/gas/i386/x86-64-opcode-inval-intel.d: Ditto. 5365 * testsuite/gas/i386/x86-64-opcode-inval.d: Ditto. 5366 * testsuite/gas/i386/x86-64-opcode-inval.s: Ditto. 5367 * testsuite/gas/i386/x86-64-pseudos-bad.l: Add illegal rex2 test. 5368 * testsuite/gas/i386/x86-64-pseudos-bad.s: Ditto. 5369 * testsuite/gas/i386/x86-64-pseudos.d: Add rex2 test. 5370 * testsuite/gas/i386/x86-64-pseudos.s: Ditto. 5371 * testsuite/gas/i386/x86-64.exp: Run APX tests. 5372 * testsuite/gas/i386/x86-64-apx-egpr-inval.l: New test. 5373 * testsuite/gas/i386/x86-64-apx-egpr-inval.s: New test. 5374 * testsuite/gas/i386/x86-64-apx-rex2.d: New test. 5375 * testsuite/gas/i386/x86-64-apx-rex2.s: New test. 5376 5377 include/ChangeLog: 5378 5379 * opcode/i386.h (REX2_OPCODE): New. 5380 (REX2_M): Ditto. 5381 5382 opcodes/ChangeLog: 5383 5384 * i386-dis.c (struct instr_info): Add erex for gpr32. 5385 Add last_erex_prefix for rex2 prefix. 5386 (REX2_M): Extend for gpr32. 5387 (PREFIX_REX2): Ditto. 5388 (PREFIX_REX2_ILLEGAL): Ditto. 5389 (ckprefix): Ditto. 5390 (prefix_name): Ditto. 5391 (print_insn): Ditto. 5392 (print_register): Ditto. 5393 (OP_E_memory): Ditto. 5394 (OP_REG): Ditto. 5395 (OP_EX): Ditto. 5396 * i386-gen.c (rex2_disallowed): Some instructions are not allowed rex2 prefix. 5397 (process_i386_opcode_modifier): Set NoEgpr for VEX and some special instructions. 5398 (output_i386_opcode): Handle if_entry_needs_special_handle. 5399 * i386-init.h : Regenerated. 5400 * i386-mnem.h : Regenerated. 5401 * i386-opc.h (enum i386_cpu): Add CpuAPX_F. 5402 (NoEgpr): New. 5403 (Prefix_NoOptimize): Ditto. 5404 (Prefix_REX2): Ditto. 5405 (RegRex2): Ditto. 5406 * i386-opc.tbl: Add rex2 prefix. 5407 * i386-reg.tbl: Add egprs (r16-r31). 5408 * i386-tbl.h: Regenerated. 5409 54102023-12-28 Dimitar Dimitrov <dimitar@dinux.eu> 5411 5412 sim: pru: Fix emulation of carry bit 5413 The PRU architecture documentation [1] was used for the initial GNU 5414 simulator implementation. But recently [2] TI confirmed the carry 5415 behaviour was wrongly documented. In reality, the PRU carry behaves 5416 like the carry in ARM processors. 5417 5418 This patch fixes simulator to align with latest recommendations from TI. 5419 5420 The new carry.s test was also validated to pass on real hardware - 5421 a BeaglePlay board [3]. That test is a bit long because TI still 5422 has not released official updates for the PRU documents. And I wanted 5423 to ensure simulator handles all edge cases exactly as the real hardware 5424 does. 5425 5426 [1] https://www.ti.com/lit/pdf/spruij2 5427 [2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1244359/sk-am64b-am64x-pru-assembler-how-works-this-bloody-carry 5428 [3] https://www.beagleboard.org/boards/beagleplay 5429 54302023-12-28 Nelson Chu <nelson@rivosinc.com> 5431 5432 RISC-V: PR31179, The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects 5433 * Problematic fix commit, 5434 2029e13917d53d2289d3ebb390c4f40bd2112d21 5435 RISC-V: Clarify the behaviors of SET/ADD/SUB relocations 5436 5437 * Bugzilla, 5438 https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5 5439 5440 The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it 5441 non-zero by accident in assembler before. This causes troubles by applying 5442 the above commit, since the calculation is changed to support .reloc *SUB* 5443 relocations with non-zero addend. 5444 5445 We encourage people to rebuild their stuff to get the non-zero addend of 5446 SUB_ULEB128, but that might need some times, so report warnings to inform 5447 people need to rebuild their stuff if --check-uleb128 is enabled. 5448 5449 Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use, 5450 it may acceptable that stop supproting them until people rebuld their stuff, 5451 maybe half-year or a year later. Or maybe we should teach people that don't 5452 write the .reloc R_RISCV_SUB* with non-zero constant, and then report 5453 warnings/errors in assembler. 5454 5455 bfd/ 5456 * elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of 5457 R_RISCV_SUB_ULEB128. 5458 (riscv_elf_relocate_section): Report warnings to inform people need 5459 to rebuild their stuff if --check-uleb128 is enabled. So that can 5460 get the right non-zero addend of R_RISCV_SUB_ULEB128. 5461 * elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128. 5462 ld/ 5463 * NEWS: Updated. 5464 * emultempl/riscvelf.em: Added linker risc-v target options, 5465 --[no-]check-uleb128, to enable/disable checking if the addend of 5466 uleb128 is non-zero or not. So that people will know they need to 5467 rebuild the objects with binutils 2.42 and up, to get the right zero 5468 addend of SUB_ULEB128 relocation, or they may get troubles if using 5469 .reloc. 5470 * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 5471 * ld/testsuite/ld-riscv-elf/pr31179*: New test cases. 5472 54732023-12-28 GDB Administrator <gdbadmin@sourceware.org> 5474 5475 Automatic date update in version.in 5476 54772023-12-27 Alan Modra <amodra@gmail.com> 5478 5479 asan: buffer overflow in loongarch_elf_rtype_to_howto 5480 Seen when running ld-loongarch-elf/tlsdesc-dso test. 5481 elfxx-loongarch.c:1844:32: runtime error: index 125 out of bounds for 5482 type 'loongarch_reloc_howto_type [124]' 5483 5484 So either the loongarch_howto_table needs three more 5485 LOONGARCH_EMPTY_HOWTO entries, or loongarch_elf_rtype_to_howto should 5486 be testing for r_type < ARRAY_SIZE (loongarch_howto_table). I figure 5487 it's worth wasting a little more space to get faster lookup. 5488 5489 * elfxx-loongarch.c (loongarch_howto_table): Add 5490 LOONGARCH_EMPTY_HOWTO entries for 121..123. 5491 (loongarch_elf_rtype_to_howto): Don't support slow lookup. 5492 Assert exact table size and r_type indexing. Omit return cast. 5493 (loongarch_reloc_name_lookup): Omit assertion and return cast. 5494 (loongarch_reloc_type_lookup): Likewise. 5495 54962023-12-27 Alan Modra <amodra@gmail.com> 5497 5498 PR31191, objcopy leaves temporary files 5499 Fix the ENOTDIR rmdir too. 5500 5501 PR 31191 5502 * objcopy.c (copy_archive): Localise uses of "l". Remove 5503 const from name_list.name. Unlink output element on bfd_close 5504 error, and NULL list->name to indicate file is removed. Adjust 5505 cleanup to prevent rmdir on non-existent file. 5506 55072023-12-27 Mike Frysinger <vapier@gentoo.org> 5508 5509 sim: common: pull in newlib extensions for Linux compatibility 5510 Since newlib allows people to opt-in to extra errno names, pull them 5511 into our table too. The values don't conflict with each other -- the 5512 newlib names & values are distinct from newlib's Linux compatibility. 5513 55142023-12-27 GDB Administrator <gdbadmin@sourceware.org> 5515 5516 Automatic date update in version.in 5517 55182023-12-26 GDB Administrator <gdbadmin@sourceware.org> 5519 5520 Automatic date update in version.in 5521 55222023-12-25 Mike Frysinger <vapier@gentoo.org> 5523 5524 binutils: SECURITY: use https URI 5525 55262023-12-25 Lulu Cai <cailulu@loongson.cn> 5527 5528 LoongArch: Add testsuit for DESC and tls transition and tls relaxation. 5529 55302023-12-25 mengqinggang <mengqinggang@loongson.cn> 5531 5532 LoongArch: Add support for TLS LD/GD/DESC relaxation 5533 The pcalau12i + addi.d of TLS LD/GD/DESC relax to pcaddi. 5534 Relaxation is only performed when the TLS model transition is not possible. 5535 55362023-12-25 Lulu Cai <cailulu@loongson.cn> 5537 5538 LoongArch: Add tls transition support. 5539 Transitions between DESC->IE/LE and IE->LE are supported now. 5540 1. For DESC -> LE: 5541 pcalau12i $a0,%desc_pc_hi20(var) => lu12i.w $a0,%le_hi20(var) 5542 addi.d $a0,$a0,%desc_pc_lo12(var) => ori $a0,$a0,%le_lo12(var) 5543 ld.d $a1,$a0,%desc_ld(var) => NOP 5544 jirl $ra,$a1,%desc_call(var) => NOP 5545 add.d $a0,$a0,$tp 5546 2. For DESC -> IE: 5547 pcalau12i $a0,%desc_pc_hi20(var) => pcalau12i $a0,%ie_pc_hi20(var) 5548 addi.d $a0,$a0,%desc_pc_lo12(var) => ld.d $a0,$a0,%ie_pc_lo12(var) 5549 ld.d $a1,$a0,%desc_ld(var) => NOP 5550 jirl $ra,$a1,%desc_call(var) => NOP 5551 add.d $a0,$a0,$tp 5552 3. For IE -> LE: 5553 pcalau12i $a0,%ie_pc_hi20(var) => lu12i.w $a0,%le_hi20(var) 5554 ld.d $a0,$a0,%ie_pc_lo12(var) => ori $a0,$a0,%le_lo12(var) 5555 add.d $a0,$a0,$tp 5556 4. When a tls variable is accessed using both DESC and IE, DESC transitions 5557 to IE and uses the same GOT entry as IE. 5558 5559 LoongArch: Add support for TLSDESC in ld. 5560 1.The linker for each DESC generates a R_LARCH_TLS_DESC64 dynamic 5561 relocation, which relocation is placed at .rela.dyn. 5562 TLSDESC always allocates two GOT slots and one dynamic relocation 5563 space to TLSDESC. 5564 2. When using multiple ways to access the same TLS variable, a 5565 maximum of 5 GOT slots are used. For example, using GD, TLSDESC, 5566 and IE to access the same TLS variable, GD always uses the first 5567 two of the five GOT, TLSDESC uses the third and fourth, and IE 5568 uses the last. 5569 5570 LoongArch: Add new relocs and macro for TLSDESC. 5571 The normal DESC instruction sequence is: 5572 pcalau12i $a0,%desc_pc_hi20(var) #R_LARCH_TLS_DESC_PC_HI20 5573 addi.d $a0,$a0,%desc_pc_lo12(var) #R_LARCH_TLS_DESC_PC_LO12 5574 ld.d $ra,$a0,%desc_ld(var) #R_LARCH_TLS_DESC_LD 5575 jirl $ra,$ra,%desc_call(var) #R_LARCH_TLS_DESC_CALL 5576 add.d $a0,$a0,$tp 5577 55782023-12-25 GDB Administrator <gdbadmin@sourceware.org> 5579 5580 Automatic date update in version.in 5581 55822023-12-24 Alan Modra <amodra@gmail.com> 5583 5584 Re: LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1"> 5585 This fixes the buffer overflow added in commit 22b78fad28, and a few 5586 other problems. 5587 5588 * loongarch-coder.c (loongarch_split_args_by_comma): Don't 5589 overflow buffer when args == "". Don't remove unbalanced 5590 quotes. Don't trim last arg if max number of args exceeded. 5591 55922023-12-24 Simon Marchi <simon.marchi@efficios.com> 5593 5594 gdb: make value::allocate_register_lazy store id of next non-inline frame 5595 Some spots loop on the frame chain to find the first next non-inline 5596 frame, and pass that as the "next frame" to 5597 value::allocate_register_lazy / value::allocate_register. This is 5598 necessary if the value is used in the process of computing the id of 5599 "this frame". If the frame next to "this frame" is inlined into "this 5600 frame", then you that next frame won't have a computed id yet. You have 5601 to go past that to find the next non-inline frame, which will have a 5602 computed id. 5603 5604 In other cases, it's fine to store the id of an inline frame as the 5605 "next frame id" in a register struct value. When trying to unwind a 5606 register from it, it will just call inline_frame_prev_register, which 5607 will forward the request to the next next frame, until we hit the next 5608 physical frame. 5609 5610 I think it would make things simpler to just never store the id of an 5611 inline frame as the next frame id of register struct values, and go with 5612 the first next non-inline frame directly. This way, we don't have to 5613 wonder which code paths have to skip inline frames when creating 5614 register values and which don't. 5615 5616 So, change value::allocate_register_lazy to do that work, and remove the 5617 loops for the callers that did it. 5618 5619 Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310 5620 56212023-12-24 Simon Marchi <simon.marchi@polymtl.ca> 5622 5623 gdb: remove VALUE_REGNUM, add value::regnum 5624 Remove VALUE_REGNUM, replace it with a method on struct value. Set 5625 `m_location.reg.regnum` directly from value::allocate_register_lazy, 5626 which is fine because allocate_register_lazy is a static creation 5627 function for struct value. 5628 5629 Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d 5630 56312023-12-24 Simon Marchi <simon.marchi@efficios.com> 5632 5633 gdb: remove VALUE_NEXT_FRAME_ID, add value::next_frame_id 5634 Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set 5635 `m_location.reg.next_frame_id` directly from value::allocate_register_lazy, 5636 which is fine because allocate_register_lazy is a static creation 5637 function for struct value. 5638 5639 Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6 5640 56412023-12-24 Simon Marchi <simon.marchi@efficios.com> 5642 5643 gdb: implement address_from_register using value_from_register 5644 As explained in the comment removed by the previous commit "gdb: pass 5645 non-nullptr frame to gdbarch_value_from_register in 5646 address_from_register", address_from_register copies some implementation 5647 bits from value_from_register: 5648 5649 /* This routine may be called during early unwinding, at a time 5650 where the ID of FRAME is not yet known. Calling value_from_register 5651 would therefore abort in get_frame_id. However, since we only need 5652 a temporary value that is never used as lvalue, we actually do not 5653 really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement 5654 the core of value_from_register, but use the null_frame_id. */ 5655 5656 This is no longer relevant, since we now create a value with a valid next 5657 frame id, so change address_from_register to use value_from_register. 5658 5659 Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43 5660 56612023-12-24 Simon Marchi <simon.marchi@efficios.com> 5662 5663 gdb: remove read_frame_register_value's frame parameter 5664 By now, all register struct values should have a valid next frame id 5665 (assuming they are created using value::allocate_register or 5666 value::allocate_register_lazy), so there should be no need to pass a 5667 frame alongside the value to read_frame_register_value. Remove the 5668 frame parameter and adjust read_frame_register_value accordingly. 5669 5670 While at it, make read_frame_register_value static, it's only used in 5671 findvar.c. 5672 5673 Change-Id: I118959ef8c628499297c67810916e8ba9934bfac 5674 56752023-12-24 Simon Marchi <simon.marchi@efficios.com> 5676 5677 gdb: add type parameter to value::allocate_register and add value::allocate_register_lazy 5678 Some places that create register struct values don't use register_type 5679 to obtain the value type. This prevents them from using the current 5680 version of value::allocate_register. One spot (value_of_register_lazy) 5681 also creates a lazy register value. 5682 5683 Add a value::allocate_register_lazy method. Add some type parameters 5684 to value::allocate_register and value::allocate_register_lazy, to let 5685 the caller specify the type to use for the value. The parameters 5686 default to nullptr, in which case we use register_type to obtain the 5687 type. 5688 5689 Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec 5690 56912023-12-24 Simon Marchi <simon.marchi@efficios.com> 5692 5693 gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register 5694 address_from_register used to pass null_frame_id to 5695 gdbarch_value_from_register as "this frame"'s id, because it's possible 5696 for it to be called during unwind, when "this frame"'s id is not yet 5697 known. This create an oddity where those register struct values are 5698 created without a valid next frame id. I would much prefer for things 5699 to be consistent and have all register struct values to have a valid 5700 next frame id. 5701 5702 Since gdbarch_value_from_register takes a frame_info_ptr now, rather 5703 than a frame_id, we can pass down "this frame", even if it doesn't have 5704 a valid id. gdbarch_value_from_register implementations can obtain the 5705 next frame from it. 5706 5707 However, it's possible for the "this frame"'s next frame to be an 5708 inline frame, inlined in "this frame", in which case that next frame's 5709 id is also not known. So, loop until we get to the next non-inline 5710 frame (which is actually the frame where registers for "this frame" are 5711 unwound from). This is the same thing that we do in 5712 value_of_register_lazy, for the same reason. A later patch will factor 5713 out this "while next frame is inline" loop to apply it to all register 5714 struct values, so this is somewhat temporary. 5715 5716 Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078 5717 57182023-12-24 Simon Marchi <simon.marchi@efficios.com> 5719 5720 gdb: pass frame_info_ptr to gdbarch_value_from_register 5721 Pass a frame_info_ptr rather than a frame_id. This avoids having to do 5722 a frame lookup on the callee side, when we can just pass the frame down 5723 directly. 5724 5725 I think this fixes a bug in rs6000-tdep.c where the id of the wrong 5726 frame was set to `VALUE_NEXT_FRAME_ID (v)`. 5727 5728 Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565 5729 57302023-12-24 Simon Marchi <simon.marchi@efficios.com> 5731 5732 gdb: don't set frame id after calling cooked_read_value 5733 I don't think that setting the next frame id is needed there, all code 5734 paths in cooked_read_value do set it properly, AFAIK. 5735 5736 Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d 5737 57382023-12-24 Mike Frysinger <vapier@gentoo.org> 5739 5740 sim: cris: rvdummy: delete unused variable 5741 57422023-12-24 Mike Frysinger <vapier@gentoo.org> 5743 5744 sim: cgen: mark cgen_rtx_error noreturn 5745 Since this function never returns, mark it as such to fix some unused 5746 variable warnings in error code paths. 5747 5748 For example, cris triggers: 5749 sim/cris/semcrisv10f-switch.c:3558:11: error: 5750 variable 'tmp_newval' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 5751 5752 Even though it has an "else" path that calls this error function. 5753 57542023-12-24 Mike Frysinger <vapier@gentoo.org> 5755 5756 sim: cgen: regenerate decode tables 5757 Integrate some changes from upstream cgen that tightened up the 5758 generated output. Shouldn't be any functional changes here. 5759 5760 sim: sh: refine pwsb & pwad nops 5761 Since these insns don't do anything and are effectively ignored, 5762 return early to avoid doing any common processing at the end as 5763 that requires initializing variables like "res" with something. 5764 5765 sim: sh: fix plds Dz,MACL implementation 5766 The plds Dz,MACL insn stores the Dz bit into MACL. The current code 5767 was storing the "res" variable into Dz and then into MACL, but not 5768 setting "res" to anything. Delete that logic and make it match the 5769 existing plds Dz,MACH insn. 5770 57712023-12-24 GDB Administrator <gdbadmin@sourceware.org> 5772 5773 Automatic date update in version.in 5774 57752023-12-23 Mike Frysinger <vapier@gentoo.org> 5776 5777 sim: warnings: rework individual flag disable into dedicated vars 5778 The -Wshadow=local is too new for some compilers, so move it to a var 5779 that we test at configure time. 5780 57812023-12-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 5782 5783 gprofng: fix build problems on linux-musl 5784 ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl. 5785 Fixed by declaring these types for linux-musl. 5786 5787 2023-12-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 5788 5789 PR gprofng/30779 5790 PR gprofng/29593 5791 * common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl. 5792 * libcollector/unwind.c: Define __u64 for linux-musl. 5793 * src/util.h: Define dbe_stat_t. 5794 * src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64". 5795 * src/Dbe.cc: Likewise. 5796 * src/DbeFile.cc: Likewise. 5797 * src/DbeFile.h: Likewise. 5798 * src/DbeSession.cc: Likewise. 5799 * src/Experiment.cc: Likewise. 5800 * src/checks.cc: Likewise. 5801 * src/util.cc: Likewise. 5802 58032023-12-23 Mike Frysinger <vapier@gentoo.org> 5804 5805 sim: sh: fix -Wshadow=local warnings 5806 Rename the var to avoid shadowing & clobbering the higher context. 5807 5808 sim: riscv: fix -Wshadow=local warnings 5809 Inline the one usage of sd in these macros to avoid possible shadowing. 5810 5811 sim: ppc: fix -Wshadow=local warnings 5812 Use a local name in the macro to avoid shadowing wherever it's used. 5813 5814 sim: mips: fix -Wshadow=local warnings 5815 Delete redundant decls when the existing scope has the same var and 5816 type available for use. 5817 5818 sim: m68hc11: fix -Wshadow=local warnings 5819 Delete redundant decls when the existing scope has the same var and 5820 type available for use. 5821 5822 sim: m32c: fix -Wshadow=local warnings 5823 These decoders declare a lot of common variables for use by substeps, 5824 and then shadows a few because of how the opc generator is implemented. 5825 Easiest way around it is to rename the per-substep vars as needed as 5826 anything more would require substantial changes to the opc logic. 5827 5828 sim: iq2000: fix -Wshadow=local warnings 5829 Delete redundant decls. 5830 5831 sim: h8300: fix -Wshadow=local warnings 5832 Delete conflicting decls when the existing scope has vars of the same 5833 name & type for this exact use. 5834 5835 sim: frv: fix -Wshadow=local warnings 5836 Delete redundant decls, and rename conflicting vars. 5837 5838 sim: erc32: fix -Wshadow=local warnings 5839 Rename shadowed vars with different types to avoid confusion. 5840 58412023-12-23 Mike Frysinger <vapier@gentoo.org> 5842 5843 sim: cris: disable -Wshadow=local in generated mloop files 5844 The mloop files include CGEN generated switch files which have some 5845 nested assignments that expand into repeated shadowed variables. 5846 Fixing this looks fairly non-trivial as it appears to be interplay 5847 between the common CGEN code and how this particular set of cris 5848 insns are defined. Disable the warning instead. 5849 5850 In file included from sim/cris/mloop.in:286: 5851 sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’: 5852 sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local] 5853 12383 | SI opval = tmp_addr; 5854 | ^~~~~ 5855 sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here 5856 12371 | USI opval = ({ SI tmp_addr; 5857 | ^~~~~ 5858 5859 And the code looks like: 5860 USI opval = ({ 5861 ... 5862 { 5863 SI opval = tmp_addr; 5864 ... 5865 } 5866 ... 5867 }); 5868 5869 Since the CGEN code treats "opval" as an internal variable that the cpu 5870 definitions don't have direct access to, the likelihood of this being a 5871 real bug is low, so leave it be. The warning is suppressed for more code 5872 that is hand written (e.g. the mloop logic), but disabling for the entire 5873 file is the easiest way to suppress while keeping it on everywhere else in 5874 the sim. 5875 58762023-12-23 Mike Frysinger <vapier@gentoo.org> 5877 5878 sim: cris: fix -Wshadow=local warnings 5879 Delete redundant local decls. 5880 5881 sim: common: fix -Wshadow=local warnings 5882 Rename shadowed vars with different types, and delete redundant decls. 5883 5884 sim: bfin: fix -Wshadow=local warnings 5885 Rename the shadowed var to avoid confusion with the function argument 5886 as to which address this code is using. 5887 5888 sim: arm: fix -Wshadow=local warnings 5889 Remove duplicate nested variable declarations, rename some to avoid 5890 confusion when the type is different or the original value should be 5891 retained, and fix some weirdness with nested enums in structs. 5892 5893 sim: aarch64: fix -Wshadow=local warnings 5894 These functions have local vars named "val" of type float, and 5895 then create nested vars named "val" of type double. This is a 5896 bit confusing and causes build time warnings. 5897 58982023-12-23 GDB Administrator <gdbadmin@sourceware.org> 5899 5900 Automatic date update in version.in 5901 59022023-12-22 Tom Tromey <tromey@adacore.com> 5903 5904 Check for rogue DAP exceptions in test suite 5905 This changes the test suite to look for rogue DAP exceptions in the 5906 log file, and issue a "fail" if one is found. 5907 5908 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 5909 59102023-12-22 Tom Tromey <tromey@adacore.com> 5911 5912 Avoid exception from attach in DAP 5913 I noticed that the DAP attach test case (and similarly 5914 remoted-dap.exp) had a rogue exception stack trace in the log. It 5915 turns out that an attach will generate a stop that does not have a 5916 reason. 5917 5918 This patch fixes the problem in the _on_stop event listener by making 5919 it a bit more careful when examining the event reason. It also adds 5920 some machinery so that attach stops can be suppressed, which I think 5921 is the right thing to do. 5922 5923 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 5924 59252023-12-22 Tom Tromey <tromey@adacore.com> 5926 5927 Add DAP log level parameter 5928 This adds a new parameter to control the DAP logging level. By 5929 default, "expected" exceptions are not logged, but the parameter lets 5930 the user change this when more logging is desired. 5931 5932 This also changes a couple of spots to avoid logging the stack trace 5933 for a DAPException. 5934 5935 This patch also documents the existing DAP logging parameter. I 5936 forgot to document this before. 5937 5938 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 5939 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 5940 59412023-12-22 Tom Tromey <tromey@adacore.com> 5942 5943 Introduce and use DAPException 5944 This introduces a new DAPException class, and then changes various 5945 spots in the DAP implementation to wrap "expected" exceptions in this. 5946 This class will help detect rogue exceptions caused by bugs in the 5947 implementation. 5948 5949 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 5950 59512023-12-22 Tom Tromey <tromey@adacore.com> 5952 5953 Fix build with clang 16 5954 clang 16 reports a missing declaration in new-op.cc. We believed 5955 these operators to be declared starting with C++14, but apparently 5956 that is not the case. 5957 5958 This patch reverts the earlier change and then updates the comment to 5959 reflect the current state. 5960 5961 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31141 5962 59632023-12-22 Kévin Le Gouguec <legouguec@adacore.com> 5964 5965 gdb: fix refactoring hiccup in rs6000_register_to_value 5966 In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame" 5967 (9fc79b42369), *_register_to_value functions were made to (a) call 5968 get_next_frame_sentinel_okay (frame) (b) pass that next frame to 5969 get_frame_register_bytes. 5970 5971 Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on 5972 PPC platforms for e.g. O2_float_param: instead of seeing… 5973 5974 Temporary breakpoint 1, callee.increment (val=val@entry=99.0, msg=...) at callee.adb:19 5975 5976 … we get "optimized_out" for val. Passing next_frame to 5977 get_frame_register_bytes fixes the issue. 5978 5979 Approved-By: Simon Marchi <simon.marchi@efficios.com> 5980 59812023-12-22 Tom Tromey <tromey@adacore.com> 5982 5983 Add 'program' to DAP 'attach' request 5984 In many cases, it's not possible for gdb to discover the executable 5985 when a DAP 'attach' request is used. This patch lets the IDE supply 5986 this information. 5987 5988 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 5989 59902023-12-22 Mike Frysinger <vapier@gentoo.org> 5991 5992 sim: cgen: regenerate decode tables to avoid shadow warnings 5993 Use latest cgen to regenerate the decode tables which has some shadow 5994 warning fixes with "val" variables. 5995 5996 sim: cris: regen cgen decoders to fix build warnings [PR sim/31181] 5997 Bug: https://sourceware.org/PR31181 5998 59992023-12-22 Guinevere Larsen <blarsen@redhat.com> 6000 6001 gdb: add git trailer information on gdb/MAINTAINERS 6002 The project has been using Tested-By (tb), Reviewed-By (rb) and 6003 Approved-By (ab) for some time, but there has been no information to be 6004 found in the actual repository. This commit changes that by adding 6005 information about all git trailers to the MAINTAINERS file, so that it 6006 can be easily double-checked. Simply put, the trailers in use work as 6007 follows: 6008 6009 * Tested-by: The person tested the patch and it fixes the problem, or 6010 introduces no regressions (or both). 6011 * Acked-by: The general outline looks good, but the maintainer hasn't 6012 looked at the code 6013 * Reviewed-by: The code looks good, but the reviewer has not approved 6014 the patch to go upstream 6015 * Approved-by: The patch is ready to be pushed to master 6016 6017 These last 3 trailers can also be restricted to one or more areas of GDB 6018 by adding the areas in a comma separated list in parenthesis after the 6019 trailers. 6020 6021 Finally, for completeness sake, the trailers Co-Authored-By and Bug 6022 were added, even though they have been in use for a long time already 6023 6024 Reviewed-By: Kevin Buettner <kevinb@redhat.com> 6025 Reviewed-By: Luis Machado <luis.machado@arm.com> 6026 Approved-By: John Baldwin <jhb@FreeBSD.org> 6027 60282023-12-22 Jan Beulich <jbeulich@suse.com> 6029 6030 nios2: fix .text/.data interaction with .previous 6031 Just like obj_elf_section() is called for .section, obj_elf_{text,data}() 6032 need calling for .text/.data. 6033 60342023-12-22 Jan Beulich <jbeulich@suse.com> 6035 6036 hppa/ELF: fix .text/.data interaction with .previous 6037 For some ELF targets .text/.data are overridden. In that case 6038 obj_elf_{text,data}() need calling, just like .code vectors to that 6039 function for the remaining ELF targets. 6040 6041 While there also hand on the function arguments, even if right now 6042 they're meaningless. This matches what other targets' code does. 6043 60442023-12-22 Jan Beulich <jbeulich@suse.com> 6045 6046 RISC-V: drop .bss override 6047 It doesn't look to be a good idea to override the custom handler that 6048 ELF has; afaict doing so broke .previous, and a sub-section specifier 6049 wasn't accepted either. 6050 60512023-12-22 Jan Beulich <jbeulich@suse.com> 6052 6053 x86-64: refuse "high" 8-bit regs with .insn and VEX/XOP/EVEX encodings 6054 Much like REX, those encodings - if permitting 8-bit regs at all, i.e. 6055 only starting with APX - permit use of "new" 8-bit registers only. %ah, 6056 %ch, %dh, and %bh cannot be encoded and hence should be rejected. 6057 6058 Permit their use outside of 64-bit code though, as "new" registers 6059 simply don't exist there. 6060 60612023-12-22 Jan Beulich <jbeulich@suse.com> 6062 6063 x86: properly respect rex/{rex} 6064 This addresses two issues: For one, a user specified "rex" did not cause 6065 the diagnostic to trigger when there was no other need for a REX prefix; 6066 instead, another than the specified insn+operands was encoded. And then 6067 (which is what this started from) .insn didn't respect {rex} (and was 6068 otherwise similarly flawed as ordinary insns). 6069 6070 The latter requires splitting out code from md_assemble(), for it to 6071 become re-usable. Besides the addition to address the first issue, that 6072 code then also needs generalizing to account for immediate operands, as 6073 with .insn we can't make assumptions anymore on all respective templates 6074 having at most two operands (we still can build upon there being at most 6075 two non-immediate operands, though). While moving the code also simplify 6076 the first if(), by folding redundant checks. 6077 6078 In the new testcase also test a few more things which afaics weren't 6079 tested till now. 6080 60812023-12-22 mengqinggang <mengqinggang@loongson.cn> 6082 6083 LoongArch: Add support for the third expression of .align for R_LARCH_ALIGN 6084 If the symbol index is not zero, the addend is used to represent 6085 the first and the third expressions of the .align. 6086 6087 The lowest 8 bits are used to represent the first expression. 6088 Other bits are used to represent the third expression. 6089 6090 The addend of R_LARCH_ALIGN for ".align 5, ,4" is 0x405. 6091 The addend of R_LARCH_ALIGN for ".balign 32, ,4" is 0x405. 6092 60932023-12-22 Mike Frysinger <vapier@gentoo.org> 6094 6095 sim: ppc: igen: fix -G handling 6096 We weren't using the enable_p flag to see whether the option should 6097 be enabled or disabled, and we weren't breaking out when done parsing. 6098 6099 sim: warnings: enable -Wreturn-type 6100 Older versions of gcc support this warning flag. We're already clean. 6101 6102 sim: warnings: fix -Wreturn-mismatch typo 6103 6104 sim: m32c: fix initial #line number in generated code 6105 This emits #line 2 for the first line in the output when it should be 1. 6106 6107 sim: mloop: add #line pragmas everywhere 6108 This will make compiler diagnostics much better with generated code 6109 so people can understand the original source file. 6110 61112023-12-22 Mike Frysinger <vapier@gentoo.org> 6112 6113 sim: common: add $LINENO rewriting support to genmloop scripts 6114 The generated mloop files can trigger compile time warnings. It can 6115 be difficult to see/understand where the original code is coming from 6116 as all the diagnostics point to the generated output. Using #line 6117 pragmas, we can point people to the original source files. 6118 6119 Unfortunately, this code is written in POSIX shell, and that lacks 6120 support for line number tracking. The $LINENO variable, even when 6121 available, can just be plain wrong. For example, when using dash 6122 and subshells, $LINENO can end up having negative values. Add a 6123 wrapper script that will uses awk to rewrite the $LINENO variable 6124 to the right value to avoid all that. 6125 6126 Basically lineno.sh takes an input script, rewrites all uses of 6127 $LINENO into the actual line number (and $0 into the original file 6128 name), and then executes the temporary script. 6129 6130 This commit doesn't actually add #line pragmas to any files. That 6131 comes next. 6132 61332023-12-22 GDB Administrator <gdbadmin@sourceware.org> 6134 6135 Automatic date update in version.in 6136 61372023-12-21 Tom Tromey <tom@tromey.com> 6138 6139 Rename TUI locator window -> status 6140 The TUI status window is called the "locator" in the source, but 6141 "status" in the documentation. Whenever I've needed to find the code, 6142 I've had to search to "locate" it (ha, ha). This patch renames the 6143 window to match the public name of the window. 6144 6145 Rename tui-stack -> tui-status 6146 The TUI status line is called the "status" window in the 6147 documentation, but not in the source. There, the relevant files are 6148 named "tui-stack", which to me makes it sound like they have something 6149 to do with backtraces. This patch renames them to "tui-status". 6150 61512023-12-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 6152 6153 ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64 6154 GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when 6155 the linked libraries have dependencies on shared objects themselves: 6156 6157 $ gcc -m32 -o ei ei.c -lexecinfo 6158 /var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld: 6159 warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found 6160 (try using -rpath or -rpath-link) 6161 /var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld: 6162 /usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0' 6163 [...] 6164 6165 Fixed by handling FreeBSD/amd64 like Linux/x86. 6166 6167 Tested on amd64-pc-freebsd14.0. 6168 61692023-12-21 Pedro Alves <pedro@palves.net> 6170 6171 Fix Clang build issue with flexible array member and non-trivial dtor 6172 Commit d5cebea18e7a ("Make cached_reg_t own its data") added a 6173 destructor to cached_reg_t. 6174 6175 That caused a build problem with Clang, which errors out like so: 6176 6177 > CXX python/py-unwind.o 6178 > gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction 6179 > 126 | cached_reg_t reg[]; 6180 > | ^ 6181 6182 This is is not really a problem for our code, which allocates the 6183 whole structure with xmalloc, and then initializes the array elements 6184 with in-place new, and then takes care to call the destructor 6185 manually. Like, commit d5cebea18e7a did: 6186 6187 @@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache) 6188 cached_frame_info *cached_frame = (cached_frame_info *) cache; 6189 6190 for (int i = 0; i < cached_frame->reg_count; i++) 6191 - xfree (cached_frame->reg[i].data); 6192 + cached_frame->reg[i].~cached_reg_t (); 6193 6194 Maybe we should get rid of the flexible array member and use a bog 6195 standard std::vector. I doubt this would cause any visible 6196 performance issue. 6197 6198 Meanwhile, to unbreak the build, this commit switches from C99-style 6199 flexible array member to 0-length array. It behaves the same, and 6200 Clang doesn't complain. I got the idea from here: 6201 6202 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11 6203 6204 GCC 9, our oldest support version, already supported this: 6205 6206 https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html 6207 6208 but the extension is actually much older than that. Note that 6209 C99-style flexible array members are not standard C++ either. 6210 6211 Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce 6212 62132023-12-21 Mike Frysinger <vapier@gentoo.org> 6214 6215 sim: warnings: enable -Wimplicit-fallthrough=5 6216 It caught some legitimate bugs, so clearly it's helpful. 6217 6218 sim: sh: fix -Wimplicit-fallthrough warnings 6219 These generate conditional insns where it tests, then fallsthru. 6220 6221 sim: rx: fix -Wimplicit-fallthrough warnings 6222 Replace some fall through comments with the attribute. 6223 6224 sim: rl78: fix -Wimplicit-fallthrough warnings 6225 Seems like this code was meant to fallthru. 6226 6227 sim: riscv: fix -Wimplicit-fallthrough warnings 6228 6229 sim: ppc: fix -Wimplicit-fallthrough warnings 6230 Replace some fall through comments with the attribute. 6231 6232 sim: or1k: fix -Wimplicit-fallthrough warnings 6233 Replace some fall through comments with the attribute. 6234 6235 sim: mips: fix -Wimplicit-fallthrough warnings 6236 Seems like these cases were meant to fallthru. 6237 6238 sim: mcore: fix Wimplicit-fallthrough warnings 6239 Seems like these decodes were intended to fallthru. 6240 6241 sim: m68hc11: fix -Wimplicit-fallthrough warnings 6242 Seems like these register operations intended on falling thru. 6243 6244 sim: frv: fix -Wimplicit-fallthrough warnings 6245 Replace some fall through comments with the attribute. 6246 6247 sim: erc32: fix -Wimplicit-fallthrough warnings 6248 Add the attribute where it seems to make sense. 6249 6250 sim: cris: fix -Wimplicit-fallthrough warnings 6251 Replace some fall through comments with the attribute. 6252 6253 sim: bfin: fix -Wimplicit-fallthrough warnings 6254 Add the attribute to places where we want to fall thru. 6255 6256 sim: avr: fix -Wimplicit-fallthrough warnings 6257 Replace some fall through comments with the attribute. 6258 6259 sim: arm: fix -Wimplicit-fallthrough warnings 6260 Replace some fall through comments with the attribute. 6261 6262 sim: aarch64: fix -Wimplicit-fallthrough warnings 6263 Replace some fall through comments with the attribute, and add some 6264 default abort calls when the compiler can't figure out that the set 6265 of values were already fully enumerated in the switch statement. 6266 6267 sim: common: fix -Wimplicit-fallthrough warnings 6268 Replace some fall through comments with the attribute. 6269 6270 sim: add ATTRIBUTE_FALLTHROUGH for local code 6271 We'll replace various /* fall through */ comments so compilers can 6272 actually understand what the code is doing. 6273 6274 sim: signal: mark signal callback funcs as noreturn since they don't return 6275 All funcs already call other funcs that don't return. The mips port is 6276 the only exception because its generic exception handler can return in 6277 the case of normal exceptions. So while the exceptions its signal handler 6278 triggers doesn't return, we can't express that conditional logic. So add 6279 some useless abort calls to make the compiler happy. 6280 6281 sim: sh: add missing breaks to bit processing 6282 Doesn't seem like we want to cascade in this section when bit processing. 6283 6284 sim: rx: mark abort func as noreturn since it doesn't 6285 6286 sim: rx: add missing break to memory write 6287 It doesn't seem like we want to keep executing the next block of code 6288 after processing the request. 6289 6290 sim: iq2000: add fallback for exit syscall 6291 Make sure this syscall always exits regardless of the exit code. 6292 6293 sim: cr16: add missing break statement 6294 Doesn't seem to make sense for this to fall through 6295 (although I'm not an expert in this ISA). 6296 6297 sim: arm: add missing breaks to SWI processing 6298 Seems unlikely we want the remove syscall to fallthrough into the 6299 rename syscall since we can't rename files that have been removed. 6300 6301 sim: common: mark engine restart as noreturn 6302 This helps the compiler with optimization and fixes fallthru warnings. 6303 6304 sim: ppc: phb: add missing break to address decoder 6305 I don't know what this emulation does exactly, but it missing a break 6306 statement seems kind of obvious based on the 32-bit case above it. 6307 6308 sim: ppc: mark halt & restart funcs as noreturn 6309 This helps the compiler with optimization and fixes fallthru warnings. 6310 6311 sim: warnings: enable -Wduplicated-cond 6312 6313 sim: mn10300: fix LAST_TIMER_REG typo 6314 The compiler pointed out that we're testing LAST_TIMER_REG and 6315 LAST_COUNTER which are the same value ... and that's because we 6316 set LAST_TIMER_REG to the wrong register. Fix the typo. 6317 63182023-12-21 Mike Frysinger <vapier@gentoo.org> 6319 6320 sim: bfin: clean up astat reg name decode a little 6321 The compiler pointed out we checked AZ twice. Sort by name to avoid 6322 that in the future, and to make it clearer that we have coverage of 6323 all the bits. And add the bits we were missing. 6324 6325 The order here doesn't matter as it's just turning a pointer into a 6326 human readable string when store tracing is enabled. 6327 63282023-12-21 Mike Frysinger <vapier@gentoo.org> 6329 6330 sim: common: delete unused scache in some mloop paths 6331 The scache vars aren't used by ports in the pbb & fast codepaths, 6332 nor are they documented as inputs to the callbacks, so delete them 6333 to avoid unused variable compiler warnings. 6334 6335 sim: cgen: unify the genmloop logic a bit 6336 Pull out the common parts of the genmloop invocation into the common 6337 code. This will make it easier to add more, and make the per-port 6338 differences a little more obvious. 6339 63402023-12-21 GDB Administrator <gdbadmin@sourceware.org> 6341 6342 Automatic date update in version.in 6343 63442023-12-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 6345 6346 gprofng: 31169 Source code locations can not be found in a C++ application 6347 gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF 6348 Version 3 or later. 6349 From DWARF specification: 6350 References that use the attribute form DW_FORM_ref_addr are specified to 6351 be four bytes in the DWARF 32-bit format and eight bytes in the DWARF 6352 64-bit format, while DWARF Version 2 specifies that such references have 6353 the same size as an address on the target system. 6354 6355 2023-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 6356 6357 PR gprofng/31169 6358 * src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr. 6359 63602023-12-20 Pedro Alves <pedro@palves.net> 6361 6362 Fix handling of vanishing threads that were stepping/stopping 6363 Downstream, AMD is carrying a testcase 6364 (gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues 6365 with the amd-dbgapi target's handling of exited threads. The test 6366 can't be added upstream yet, unfortunately, due to dependency on DWARF 6367 extensions that can't be upstreamed yet. However, it can be found on 6368 the mailing list on the same series as this patch. 6369 6370 The test spawns a kernel with a number of waves. The waves do nothing 6371 but exit. There is a breakpoint on the s_endpgm instruction. Once 6372 that breakpoint is hit, the test issues a "continue" command. We 6373 should see one breakpoint hit per wave, and then the whole program 6374 exiting. We do see that, however we also see this: 6375 6376 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?] 6377 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] 6378 *repeat for other waves* 6379 ... 6380 [Thread 0x7ffff626f640 (LWP 3048491) exited] 6381 [Thread 0x7fffeb7ff640 (LWP 3048488) exited] 6382 [Inferior 1 (process 3048475) exited normally] 6383 6384 That "New AMDGPU Wave" output comes from infrun.c itself adding the 6385 thread to the GDB thread list, because it got an event for a thread 6386 not on the thread list yet. The output shows "?"s instead of proper 6387 coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED, 6388 i.e., the wave was already gone when infrun.c added the thread to the 6389 thread list. 6390 6391 That shouldn't ever happen for the amd-dbgapi target, threads should 6392 only ever be added by the backend. 6393 6394 Note "New AMDGPU Wave ?:?:?:1" is for wave 1. What happened was that 6395 wave 1 terminated previously, and a previous call to 6396 amd_dbgapi_target::update_thread_list() noticed the wave had vanished 6397 and removed it from the GDB thread list. However, because the wave 6398 was stepping when it terminated (due to the displaced step over the 6399 s_endpgm) instruction, it is guaranteed that the amd-dbgapi library 6400 queues a WAVE_COMMAND_TERMINATED event for the exit. 6401 6402 When we process that WAVE_COMMAND_TERMINATED event, in 6403 amd-dbgapi-target.c:process_one_event, we return it to the core as a 6404 TARGET_WAITKIND_THREAD_EXITED event: 6405 6406 static void 6407 process_one_event (amd_dbgapi_event_id_t event_id, 6408 amd_dbgapi_event_kind_t event_kind) 6409 { 6410 ... 6411 if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID 6412 && event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED) 6413 ws.set_thread_exited (0); 6414 ... 6415 } 6416 6417 Recall the wave is already gone from the GDB thread list. So when GDB 6418 sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't 6419 know about, it adds the thread to the thread list, resulting in that: 6420 6421 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?] 6422 6423 and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB 6424 marks the thread exited right afterwards: 6425 6426 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] 6427 6428 The fix is to make amd_dbgapi_target::update_thread_list() _not_ 6429 delete vanishing waves iff they were stepping or in progress of being 6430 stopped. These two cases are the ones dbgapi guarantees will result 6431 in a WAVE_COMMAND_TERMINATED event if the wave terminates: 6432 6433 /** 6434 * A command for a wave was not able to complete because the wave has 6435 * terminated. 6436 * 6437 * Commands that can result in this event are ::amd_dbgapi_wave_stop and 6438 * ::amd_dbgapi_wave_resume in single step mode. Since the wave terminated 6439 * before stopping, this event will be reported instead of 6440 * ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP. 6441 * 6442 * The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE 6443 * query. However, the wave will be invalid since it has already terminated. 6444 * It is the client's responsibility to know what command was being performed 6445 * and was unable to complete due to the wave terminating. 6446 */ 6447 AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2, 6448 6449 As the comment says, it's GDB's responsability to know whether the 6450 wave was stepping or being stopped. Since we now have a wave_info map 6451 with one entry for each wave, that seems like the place to store that 6452 information. However, I still decided to put all the coordinate 6453 information in its own structure. I.e., basically renamed the 6454 existing wave_info to wave_coordinates, and then added a new wave_info 6455 structure that holds the new state, plus a wave_coordinates object. 6456 This seemed cleaner as there are places where we only need to 6457 instantiate a wave_coordinates object. 6458 6459 There's an extra twist. The testcase also exercises stopping at a new 6460 kernel right after the first kernel fully exits. In that scenario, we 6461 were hitting this assertion after the first kernel fully exits and the 6462 hit of the breakpoint at the second kernel is handled: 6463 6464 [amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP 6465 [amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list) 6466 ../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed. 6467 A problem internal to GDB has been detected, 6468 further debugging may prove unreliable. 6469 6470 This is the exact same problem as above, just a different 6471 manifestation. In this scenario, we end up in update_thread_list 6472 successfully deleting the exited thread (because it was no longer the 6473 current thread) that was incorrectly added by infrun.c. Because it 6474 was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread, 6475 it doesn't have an entry in the wave_info map, so 6476 amd_dbgapi_thread_deleted trips on this assertion: 6477 6478 gdb_assert (it != info->wave_info_map.end ()); 6479 6480 here: 6481 6482 ... 6483 -> stop_all_threads 6484 -> update_thread_list 6485 -> target_update_thread_list 6486 -> amd_dbgapi_target::update_thread_list 6487 -> thread_db_target::update_thread_list 6488 -> linux_nat_target::update_thread_list 6489 -> delete_exited_threads 6490 -> delete_thread 6491 -> delete_thread_1 6492 -> gdb::observers::observable<thread_info*>::notify 6493 -> amd_dbgapi_thread_deleted 6494 -> internal_error_loc 6495 6496 The testcase thus tries both running to exit after the first kernel 6497 exits, and running to a breakpoint in a second kernel after the first 6498 kernel exits. 6499 6500 Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) 6501 Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028 6502 65032023-12-20 Pedro Alves <pedro@palves.net> 6504 6505 Fix thread target ID of exited waves 6506 Currently, if you step over kernel exit, you see: 6507 6508 stepi 6509 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] 6510 Command aborted, thread exited. 6511 (gdb) 6512 6513 Those '?' are because the thread/wave is already gone by the time GDB 6514 prints the "exited" notification, we can't ask dbgapi for any info 6515 about the wave anymore. 6516 6517 This commit fixes it by caching the wave's coordinates as soon as GDB 6518 sees the wave for the first time, and making 6519 amd_dbgapi_target::pid_to_str use the cached info. 6520 6521 At first I thought of clearing the wave_info object from a 6522 thread_exited observer. However, that is too soon, resulting in this: 6523 6524 (gdb) si 6525 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] 6526 Command aborted, thread exited. 6527 (gdb) thread 6528 [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)] 6529 6530 We need instead to clear the wave info when the thread is ultimately 6531 deleted, so we get: 6532 6533 (gdb) si 6534 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] 6535 Command aborted, thread exited. 6536 (gdb) thread 6537 [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)] 6538 6539 And for that, we need a new thread_deleted observable. 6540 6541 Approved-By: Simon Marchi <simon.marchi@efficios.com> 6542 Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) 6543 Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580 6544 65452023-12-20 Pedro Alves <pedro@palves.net> 6546 6547 Step over thread exit, always delete the thread non-silently 6548 With AMD GPU debugging, I noticed that when stepping over a breakpoint 6549 placed on top of the s_endpgm instruction inline (displaced=off), GDB 6550 would behave differently -- it wouldn't print the wave exit. E.g: 6551 6552 With displaced stepping, or no breakpoint at all: 6553 6554 stepi 6555 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] 6556 Command aborted, thread exited. 6557 (gdb) 6558 6559 With inline stepping: 6560 6561 stepi 6562 Command aborted, thread exited. 6563 (gdb) 6564 6565 In the cases we see the "exited" notification, handle_thread_exit is 6566 what first called delete_thread on the exiting thread, which is 6567 non-silent. 6568 6569 With inline stepping, however, handle_thread_exit ends up in 6570 update_thread_list (via restart_threads) before any delete_thread 6571 call. Thus, amd_dbgapi_target::update_thread_list notices that the 6572 wave is gone and deletes it with delete_thread_silent. 6573 6574 This commit fixes it, by making handle_thread_exited call 6575 set_thread_exited (with the default silent=false) early, which emits 6576 the user-visible notification. 6577 6578 Approved-By: Simon Marchi <simon.marchi@efficios.com> 6579 Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f 6580 65812023-12-20 Pedro Alves <pedro@palves.net> 6582 6583 displaced_step_finish: Don't fetch the regcache of exited threads 6584 displaced_step_finish can be called with event_status.kind == 6585 TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to 6586 get at the already-exited thread's registers. 6587 6588 This patch moves the get_thread_regcache calls to branches that 6589 actually need it, where we know the thread is still alive. 6590 6591 It also adds an assertion to get_thread_regcache, to help catching 6592 these broken cases sooner. 6593 6594 Approved-By: Simon Marchi <simon.marchi@efficios.com> 6595 Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3 6596 65972023-12-20 Pedro Alves <pedro@palves.net> 6598 6599 Ensure selected thread after thread exit stop 6600 While making step over thread exit work properly on AMDGPU, I noticed 6601 that if there's a breakpoint on top of the exit syscall, and, 6602 displaced stepping is off, then when GDB reports "Command aborted, 6603 thread exited.", GDB also switches focus to a random thread, instead 6604 of leaving the exited thread as selected: 6605 6606 (gdb) thread 6607 [Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])] 6608 (gdb) si 6609 Command aborted, thread exited. 6610 (gdb) thread 6611 [Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))] 6612 (gdb) 6613 6614 The previous patch extended gdb.threads/step-over-thread-exit.exp to 6615 exercise this on GNU/Linux (on the CPU side), and there, after that 6616 "si", we always end up with the exiting thread as selected even 6617 without this fix, but that's just a concidence, there's a code path 6618 that happens to select the exiting thread for an unrelated reason. 6619 6620 This commit add the explict switch, fixing the latent problem for 6621 GNU/Linux, and the actual problem on AMDGPU. I wrote a gdb.rocm/ 6622 testcase for this, but it can't be upstreamed yet, until more pieces 6623 of the DWARF machinery are upstream as well. 6624 6625 Approved-By: Simon Marchi <simon.marchi@efficios.com> 6626 Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51 6627 66282023-12-20 Pedro Alves <pedro@palves.net> 6629 6630 gdb.threads/step-over-thread-exit.exp improvements 6631 This commit makes the following improvements to 6632 gdb.threads/step-over-thread-exit.exp: 6633 6634 - Add a third axis to stepping over the breakpoint with displaced vs 6635 inline stepping -- also test with no breakpoint at all. 6636 6637 - Check that when GDB reports "Command aborted, thread exited.", the 6638 selected thread is the thread that exited. This is always true 6639 currently on GNU/Linux by coincidence, but a similar testcase on AMD 6640 GPU exposed a problem here. Better make the testcase catch any 6641 potential regression. 6642 6643 - Fixes a race that Simon ran into with GDBserver testing. 6644 6645 (gdb) next 6646 [New Thread 2143071.2143438] 6647 6648 Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74 6649 74 SYSCALL (my_exit, __NR_exit) 6650 (gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits 6651 6652 I was not able to reproduce it, but I believe that what happens is 6653 the following: 6654 6655 Once we continue, the thread 2 exits, and the main thread thus 6656 unblocks from its pthread_join, and spawns a new thread. That new 6657 thread may hit the breakpoint at my_exit_syscall very quickly. GDB 6658 could then see/process that breakpoint event before the thread exit 6659 event for the thread we care about, which would result in the 6660 failure seen above. 6661 6662 The fix here is to not loop and start a new thread at all in the 6663 scenario where the race can happen. We only need to loop and spawn 6664 new threads when testing with "cmd=continue" and schedlock off, in 6665 which case GDB doesn't abort the command when the thread exits. 6666 6667 Approved-By: Simon Marchi <simon.marchi@efficios.com> 6668 Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6 6669 66702023-12-20 Pedro Alves <pedro@palves.net> 6671 6672 Fix bug in previous remote unique_ptr change 6673 By inspection, I noticed that the previous patch went too far, here: 6674 6675 @@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior *inf) 6676 if (rs->remote_desc == NULL) 6677 return; 6678 6679 - reply = (struct stop_reply *) rns->pending_event[notif_client_stop.id]; 6680 + stop_reply_up reply 6681 + = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id])); 6682 6683 /* Discard the in-flight notification. */ 6684 if (reply != NULL && reply->ptid.pid () == inf->pid) 6685 6686 That is always moving the stop reply from pending_event, when we only 6687 really want to peek into it. The code further below that even says: 6688 6689 /* Discard the in-flight notification. */ 6690 if (reply != NULL && reply->ptid.pid () == inf->pid) 6691 { 6692 /* Leave the notification pending, since the server expects that 6693 we acknowledge it with vStopped. But clear its contents, so 6694 that later on when we acknowledge it, we also discard it. */ 6695 6696 This commit reverts that hunk back, adjusted to use unique_ptr::get(). 6697 6698 Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24 6699 67002023-12-20 Pedro Alves <pedro@palves.net> 6701 6702 Complete use of unique_ptr with notif_event and stop_reply 6703 We already use unique_ptr with notif_event and stop_reply in some 6704 places around the remote target, but not fully. There are several 6705 code paths that still use raw pointers. This commit makes all of the 6706 ownership of these objects tracked by unique pointers, making the 6707 lifetime flow much more obvious, IMHO. 6708 6709 I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't 6710 destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE 6711 kind. 6712 6713 Approved-By: Tom Tromey <tom@tromey.com> 6714 Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c 6715 67162023-12-20 Pedro Alves <pedro@palves.net> 6717 6718 Make cached_reg_t own its data 6719 struct cached_reg_t owns its data buffer, but currently that is 6720 managed manually. Convert it to use a unique_xmalloc_ptr. 6721 6722 Approved-By: Tom Tromey <tom@tromey.com> 6723 Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b 6724 67252023-12-20 Simon Marchi <simon.marchi@efficios.com> 6726 6727 gdb: remove stale comment and ctor in gdbarch_info 6728 tdesc_data is not part of a union, since commit 4f3681cc3361 ("Fix thread's 6729 gdbarch when SVE vector length changes"). Remove the stale comment and 6730 constructor. 6731 6732 Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503 6733 67342023-12-20 Jens Remus <jremus@linux.ibm.com> 6735 6736 s390: Add suffix to conditional branch instruction descriptions 6737 Suffix the instruction description of conditional branch extended 6738 mnemonics with their condition (e.g. "on A high"). This complements 6739 the optional printing of instruction descriptions as comments in the 6740 disassembly. 6741 6742 Due to the added text the maximum description length is increased from 6743 80 to 128 characters (including the trailing '\0' character). 6744 6745 opcodes/ 6746 * s390-mkopc.c: Add suffix to conditional branch extended 6747 mnemonic instruction descriptions. 6748 6749 gas/ 6750 * testsuite/gas/s390/zarch-insndesc.s: Add test cases for 6751 printing of suffixed instruction description of conditional 6752 branch extended mnemonics. 6753 * testsuite/gas/s390/zarch-insndesc.d: Likewise. 6754 6755 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6756 67572023-12-20 Jens Remus <jremus@linux.ibm.com> 6758 6759 s390: Optionally print instruction description in disassembly 6760 Print instruction description as comment in disassembly with s390 6761 architecture specific option "insndesc": 6762 6763 - For objdump it can be enabled with option "-M insndesc" 6764 - In gdb it can be enabled with "set disassembler-options insndesc" 6765 6766 Since comments are not column aligned the output can enhanced for 6767 readability by postprocessing using a filter such as "expand": 6768 6769 ... | expand -t 8,16,24,32,40,80 6770 6771 Or when using in combination with objdump option --visualize-jumps: 6772 6773 ... | expand | sed -e 's/ *#/\t#/' | expand -t 1,80 6774 6775 Note that the instruction descriptions add about 128 KB to s390-opc.o: 6776 6777 s390-opc.o without instruction descriptions: 216368 bytes 6778 s390-opc.o with instruction descriptions : 348432 bytes 6779 6780 binutils/ 6781 * NEWS: Mention new s390-specific disassembler option 6782 "insndesc". 6783 6784 include/ 6785 * opcode/s390.h (struct s390_opcode): Add field to hold 6786 instruction description. 6787 6788 opcodes/ 6789 * s390-mkopc.c: Copy instruction description from s390-opc.txt 6790 into generated operation code table s390-opc.tab. 6791 * s390-opc.c (s390_opformats): Provide NULL as description in 6792 .insn pseudo-mnemonics opcode table. 6793 * s390-dis.c: Add s390-specific disassembler option "insndesc" 6794 and optionally print the instruction description as comment in 6795 the disassembly when it is specified. 6796 6797 gas/ 6798 * testsuite/gas/s390/s390.exp: Add new test disassembly test 6799 case "zarch-insndesc". 6800 * testsuite/gas/s390/zarch-insndesc.s: New test case for s390- 6801 specific disassembler option "insndesc". 6802 * testsuite/gas/s390/zarch-insndesc.d: Likewise. 6803 6804 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6805 68062023-12-20 Jens Remus <jremus@linux.ibm.com> 6807 6808 s390: Use safe string functions and length macros in s390-mkopc 6809 Use strncpy() and snprintf() instead of strcpy() and strcat(). Define 6810 and use macros for string lengths, such as mnemonic, instruction 6811 format, and instruction description. 6812 6813 This is a mechanical change, although some buffers have increased in 6814 length by one character. This has been confirmed by verifying that the 6815 generated opcode/s390-opc.tab is unchanged. 6816 6817 opcodes/ 6818 * s390-mkopc.c: Use strncpy() and strncat(). 6819 6820 Suggested-by: Nick Clifton <nickc@redhat.com> 6821 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6822 68232023-12-20 Jens Remus <jremus@linux.ibm.com> 6824 6825 s390: Enhance error handling in s390-mkopc 6826 When the s390-mkopc utility detects an error it prints an error message 6827 to strerr and either continues processing or exists with a non-zero 6828 return code. If it continues without detecting any further error the 6829 final return code was zero, potentially hiding the detected error. 6830 6831 Introduce a global variable to hold the final return code and initialize 6832 it to EXIT_SUCCESS. Introduce a helper function print_error() that 6833 prints an error message to stderr and sets the final return code to 6834 EXIT_FAILURE. Use it to print all error messages. Return the final 6835 return code at the end of the processing. 6836 6837 While at it enhance error messages to state more clearly which mnemonic 6838 an error was detected for. Also continue processing for cases where 6839 subsequent mnemonics can be processed. 6840 6841 opcodes/ 6842 * s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE 6843 in case of an error, otherwise EXIT_SUCCESS. 6844 6845 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6846 68472023-12-20 Jens Remus <jremus@linux.ibm.com> 6848 6849 s390: Provide IBM z16 (arch14) instruction descriptions 6850 Provide descriptions for instructions introduced with commit ba2b480f103 6851 ("IBM Z: Implement instruction set extensions"). This complements commit 6852 69341966def ("IBM zSystems: Add support for z16 as CPU name."). Use 6853 instruction names from IBM z/Architecture Principles of Operation [1] as 6854 instruction description. 6855 6856 [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, 6857 https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf 6858 6859 opcodes/ 6860 * s390-opc.txt: Add descriptions for IBM z16 (arch14) 6861 instructions. 6862 6863 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6864 68652023-12-20 Jens Remus <jremus@linux.ibm.com> 6866 6867 s390: Align letter case of instruction descriptions 6868 Change the bitwise operations names "and" and "or" to lower case. Change 6869 the register name abbreviations "FPR", "GR", and "VR" to upper case. 6870 6871 opcodes/ 6872 * s390-opc.txt: Align letter case of instruction descriptions. 6873 6874 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6875 68762023-12-20 Jens Remus <jremus@linux.ibm.com> 6877 6878 s390: Fix build when using EXEEXT_FOR_BUILD 6879 Suffix the s390-mkopc build utility executable file name with 6880 EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with 6881 EXEEXT_FOR_BUILD. Use pattern used for other architecture build 6882 utilities and compile and link s390-mkopc in two steps. 6883 6884 While at it also specify the dependencies of s390-mkopc.c. 6885 6886 opcodes/ 6887 * Makefile.am: Add target to build s390-mkopc.o. Correct 6888 target to build s390-mkopc$(EXEEXT_FOR_BUILD). 6889 * Makefile.in: Regenerate. 6890 6891 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 6892 68932023-12-20 Mike Frysinger <vapier@gentoo.org> 6894 6895 sim: frv: enable warnings in memory.c 6896 Fix one minor pointer-sign warning to enable warnings in general 6897 for this file. Reading the data as signed and then returning it 6898 as unsigned should be functionally the same in this case. 6899 69002023-12-20 GDB Administrator <gdbadmin@sourceware.org> 6901 6902 Automatic date update in version.in 6903 69042023-12-19 Alan Modra <amodra@gmail.com> 6905 6906 Re: PR31145, potential memory leak in binutils/ld 6907 Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY 6908 iostream in io_reinit. 6909 6910 PR 31145 6911 * format.c (io_reinit): Revert last change. Comment. 6912 * opncls.c (_bfd_delete_bfd): Likewise. 6913 69142023-12-19 Simon Marchi <simon.marchi@efficios.com> 6915 6916 gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw 6917 Here, we write single complete registers, we don't need the 6918 functionality of put_frame_register_bytes, use put_frame_register 6919 instead. 6920 6921 Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08 6922 Approved-By: Tom Tromey <tom@tromey.com> 6923 69242023-12-19 Simon Marchi <simon.marchi@efficios.com> 6925 6926 gdb: remove stale comment in value_assign 6927 This comment is no longer relevant, put_frame_register_bytes now accepts 6928 the "next frame". 6929 6930 Change-Id: I077933a03f8bdb886f8ba10a98d1202a38bce0a9 6931 Approved-By: Tom Tromey <tom@tromey.com> 6932 69332023-12-19 Andrea Corallo <andrea.corallo@arm.com> 6934 6935 aarch64: Add FEAT_ITE support 6936 This patch add support for FEAT_ITE "Instrumentation Extension" adding 6937 the "trcit" instruction. 6938 6939 This is enabled by the +ite march flag. 6940 69412023-12-19 Andrea Corallo <andrea.corallo@arm.com> 6942 6943 aarch64: Add FEAT_ECBHB support 6944 This patch add support for FEAT_ECBHB "Exploitative control using 6945 branch history information" adding the "clrbhb" instruction. AFAIU 6946 the same alias was originally added as "clearbhb" before the 6947 architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional 6948 v8.0-a+/v9.0-a+). 6949 69502023-12-19 Andrea Corallo <andrea.corallo@arm.com> 6951 6952 aarch64: Add FEAT_SPECRES2 support 6953 This patch add supports for FEAT_SPECRES2 "Enhanced speculation 6954 restriction instructions" adding the "cosp" instruction. 6955 6956 This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+. It is 6957 enabled by the +predres2 march flag. 6958 69592023-12-19 Guinevere Larsen <blarsen@redhat.com> 6960 6961 gdb: register frame_destroyed function for amd64 gdbarch 6962 gdbarches usually register functions to check when a frame is destroyed 6963 which is used with software watchpoints, since the expression of the 6964 watchpoint is no longer vlaid at this point. On amd64, this wasn't done 6965 anymore because GCC started using CFA for variable locations instead. 6966 6967 However, clang doesn't use the CFA and instead relies on specifying when 6968 an epilogue has started, meaning software watchpoints get a spurious hit 6969 when a frame is destroyed. This patch re-adds the code to register the 6970 function that detects when a frame is destroyed, but only uses this when 6971 the producer is LLVM, so gcc code isn't affected. The logic that 6972 identifies the epilogue has been factored out into the new function 6973 amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it 6974 directly, and its behavior isn't changed. 6975 6976 This can also remove the XFAIL added to gdb.python/pq-watchpoint tests 6977 that handled this exact flaw in clang. 6978 6979 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 6980 Approved-By: Andrew Burgess <aburgess@redhat.com> 6981 69822023-12-19 Mike Frysinger <vapier@gentoo.org> 6983 6984 sim: common: delete unused argbuf in generated mloop code 6985 This function only uses prev_abuf, not abuf, and doesn't inline code 6986 from the various ports on the fly, so abuf will never be used. 6987 6988 sim: v850: fix -Wunused-variable warnings 6989 6990 sim: sh: fix -Wunused-variable warnings 6991 6992 sim: moxie: fix -Wunused-variable warnings 6993 6994 sim: msp430: fix -Wunused-variable warnings 6995 6996 sim: mn10300: fix -Wunused-variable warnings 6997 6998 sim: mips: fix -Wunused-variable warnings 6999 7000 sim: microblaze: fix -Wunused-variable warnings 7001 7002 sim: mcore: fix -Wunused-variable warnings 7003 7004 sim: m32r: fix -Wunused-variable warnings 7005 7006 sim: lm32: fix -Wunused-variable warnings 7007 7008 sim: iq2000: fix -Wunused-variable warnings 7009 7010 sim: h8300: fix -Wunused-variable warnings 7011 7012 sim: ft32: fix -Wunused-variable warnings 7013 7014 sim: frv: fix -Wunused-variable warnings 7015 7016 sim: erc32: fix -Wunused-variable warnings 7017 7018 sim: cris: fix -Wunused-variable warnings 7019 7020 sim: cr16: fix -Wunused-variable warnings 7021 7022 sim: bpf: fix -Wunused-variable warnings 7023 7024 sim: bfin: fix -Wunused-variable warnings 7025 7026 sim: aarch64: fix -Wunused-variable warnings 7027 7028 sim: common: fix -Wunused-variable warnings 7029 7030 cpu: cris: drop some unused vars 7031 These fix unused variable warnings in the generated sim. 7032 70332023-12-19 Haochen Jiang <haochen.jiang@intel.com> 7034 7035 x86: Remove the restriction for size of the mask register in AVX10 7036 Since AVX10.1/256 will also allow 64 bit mask register, we will 7037 remove the restriction for size of the mask register in AVX10. 7038 7039 gas/ChangeLog: 7040 7041 * config/tc-i386.c (VSZ128, VSZ256, VSZ512): New. 7042 (VEX_check_encoding): Remove opcode_modifier check for vsz. 7043 * testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask 7044 registers since they are not needed. 7045 * testsuite/gas/i386/avx10-vsz.s: Ditto. 7046 7047 opcodes/ChangeLog: 7048 7049 * i386-gen.c: Remove Vsz. 7050 * i386-opc.h: Ditto. 7051 * i386-opc.tbl: Remove kvsz. 7052 * i386-tbl.h: Regenerated. 7053 70542023-12-19 Xi Ruoyao <xry111@xry111.site> 7055 7056 LoongArch: Allow la.got -> la.pcrel relaxation for shared object 7057 Even in shared objects, la.got -> la.pcrel relaxation can still be 7058 performed for symbols with hidden visibility. For example, if a.c is: 7059 7060 extern int x; 7061 int f() { return x++; } 7062 7063 and b.c is: 7064 7065 int x = 114514; 7066 7067 If compiling and linking with: 7068 7069 gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c 7070 7071 Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f 7072 should be like: 7073 7074 pcaddi $t0, x 7075 ldptr.w $a0, $t0, 0 7076 addi.w $t1, $a0, 1 7077 stptr.w $t1, $t0, 0 7078 ret 7079 7080 Remove bfd_link_executable from the condition of la.got -> la.pcrel 7081 relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL 7082 check is enough not to wrongly relax preemptable symbols (for e.g. 7083 when -fvisibility=hidden is not used). 7084 7085 Note that on x86_64 this is also relaxed and the produced code is like: 7086 7087 lea x(%rip), %rdx 7088 mov (%rdx), %rax 7089 lea 1(%rax), %ecx 7090 mov %ecx, (%rdx) 7091 ret 7092 7093 Tested by running ld test suite, bootstrapping and regtesting GCC with 7094 the patched ld, and building and testing Glibc with the patched ld. No 7095 regression is observed. 7096 70972023-12-19 Jeff Law <jeffreyalaw@gmail.com> 7098 7099 Yet another fix for mcore-sim (rotli) 7100 This came up testing the CRC optimization work from Mariam@RAU. 7101 Basically to optimize some CRC loops into table lookups or carryless 7102 multiplies, we may need to do a bit reflection, which on the mcore 7103 processor is done using a rotate instruction. 7104 7105 Unfortunately the simulator implementation of rotates has the exact same 7106 problem as we saw with right shifts. The input value may have been sign 7107 extended from 32 to 64 bits. When we rotate the extended value, we get 7108 those sign extension bits and thus the wrong result. 7109 7110 The fix is the same. Rather than using a "long", use a uint32_t for the 7111 type of the temporary. This fixes a handful of tests in the GCC testsuite: 7112 71132023-12-19 GDB Administrator <gdbadmin@sourceware.org> 7114 7115 Automatic date update in version.in 7116 71172023-12-18 Arsen Arsenović <arsen@aarsen.me> 7118 7119 gettext: disable install, docs targets, libasprintf, threads 7120 This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by 7121 Eric Gallager <egallager@gcc.gnu.org>. 7122 7123 ChangeLog: 7124 7125 * Makefile.def (gettext): Disable (via missing) 7126 {install-,}{pdf,html,info,dvi} and TAGS targets. Set no_install 7127 to true. Add --disable-threads --disable-libasprintf. 7128 * Makefile.in: Regenerate. 7129 71302023-12-18 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 7131 7132 ld: Print 0 size in B and not in GB 7133 When using --print-memory-usage, the printed size can be zero and in 7134 that case, the unit should be B and not GB. 7135 7136 ld/ 7137 * ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB. 7138 * testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region. 7139 * testsuite/ld-scripts/print-memory-usage-1.t: Define empty region. 7140 71412023-12-18 Alan Modra <amodra@gmail.com> 7142 7143 PR31162, Memory Leak in ldwrite.c 7144 This isn't a particularly worrying memory leak, but fix it anyway. 7145 7146 PR 31162 7147 * ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc. 7148 Add %E to error messages. 7149 71502023-12-18 Andrew Burgess <aburgess@redhat.com> 7151 7152 gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp 7153 The gdb.threads/thread-specific-bp.exp test has been a little 7154 problematic, see commits: 7155 7156 commit 89702edd933a5595557bcd9cc4a0dcc3262226d4 7157 Date: Thu Mar 9 12:31:26 2023 +0100 7158 7159 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver 7160 7161 and 7162 7163 commit 2e5843d87c4050bf1109921481fb29e1c470827f 7164 Date: Fri Nov 19 14:33:39 2021 +0100 7165 7166 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp 7167 7168 But I recently saw a test failure for that test, which looked like 7169 this: 7170 7171 ... 7172 (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected 7173 continue -a 7174 Continuing. 7175 7176 Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 7177 29 } 7178 (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited] 7179 Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. 7180 FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout) 7181 ... 7182 7183 This only crops up (for me) when running on a loaded machine, and 7184 still only occurs sometimes. I've had to leave the test running in a 7185 loop for 10+ minutes sometimes in order to see the failure. 7186 7187 The problem is that we use gdb_test_multiple to try and match two 7188 patterns: 7189 7190 (1) The 'Thread-specific breakpoint 3 deleted ....' message, and 7191 (2) The GDB prompt. 7192 7193 As written in the test, we understand that these patterns can occur in 7194 any order, and we have a flag for each pattern. Once both patterns 7195 have been seen then we PASS the test. 7196 7197 The problem is that once expect has matched a pattern, everything up 7198 to, and including the matched text is discarded from the input 7199 buffer. Thus, if the input buffer contains: 7200 7201 <PATTERN 2><PATTERN 1> 7202 7203 Then expect will first try to match <PATTERN 1>, which succeeds, and 7204 then expect discards the entire input buffer up to the end of the 7205 <PATTERN 1>. As a result, we will never spot <PATTERN 2>. 7206 7207 Obviously we can't just reorder the patterns within the 7208 gdb_test_multiple, as the output can legitimately (and most often 7209 does) occur in the other order, in which case the test would mostly 7210 fail, and only occasionally pass! 7211 7212 I think the easiest solution here is just to have the 7213 gdb_test_multiple contain two patterns, each pattern consists of the 7214 two parts, but in the alternative orders, thus, for a particular 7215 output configuration, only one regexp will match. With this change in 7216 place, I no longer see the intermittent failure. 7217 7218 Approved-By: Tom Tromey <tom@tromey.com> 7219 72202023-12-18 mengqinggang <mengqinggang@loongson.cn> 7221 7222 LoongArch: Add call36 and tail36 pseudo instructions for medium code model 7223 For tail36, it is necessary to explicitly indicate the temporary register. 7224 Therefore, the compiler and users will know that the tail will use a register. 7225 7226 call36 func 7227 pcalau18i $ra, %call36(func) 7228 jirl $ra, $ra, 0; 7229 7230 tail36 $t0, func 7231 pcalau18i $t0, %call36(func) 7232 jirl $zero, $t0, 0; 7233 72342023-12-18 mengqinggang <mengqinggang@loongson.cn> 7235 7236 LoongArch: Add new relocation R_LARCH_CALL36 7237 R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and 7238 these two instructions must adjacent. 7239 7240 The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs. 7241 72422023-12-18 Georg-Johann Lay <avr@gjlay.de> 7243 7244 PR31177: Let region text start at __TEXT_REGION_ORIGIN___ 7245 The start of MEMORY region text currently starts hard-coded at 0. 7246 7247 The linker can produce more exact diagnostics when it knows the exact placements of the memory regions. 7248 7249 For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described. 7250 7251 If ok, please apply to master. 7252 This one is also fine to back-port. 7253 7254 Johann 7255 7256 -- 7257 7258 AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text. 7259 7260 ld/ 7261 PR 31177 7262 * scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol. 7263 (MEMORY): Use as start address for the text region. 7264 72652023-12-18 GDB Administrator <gdbadmin@sourceware.org> 7266 7267 Automatic date update in version.in 7268 72692023-12-17 Mike Frysinger <vapier@gentoo.org> 7270 7271 sim: warnings: add more flags 7272 We already build cleanly with these. 7273 72742023-12-17 GDB Administrator <gdbadmin@sourceware.org> 7275 7276 Automatic date update in version.in 7277 72782023-12-16 Hannes Domani <ssbssa@yahoo.de> 7279 7280 Use function entry point record only for entry values 7281 PR28987 notes that optimized code sometimes shows the wrong 7282 value of variables at the entry point of a function, if some 7283 code was optimized away and the variable has multiple values 7284 stored in the debug info for this location. 7285 7286 In this example: 7287 ``` 7288 void foo() 7289 { 7290 int l_3 = 5, i = 0; 7291 for (; i < 8; i++) 7292 ; 7293 test(l_3, i); 7294 } 7295 ``` 7296 When compiled with optimization, the entry point of foo is at 7297 the test() function call, since everything else is optimized 7298 away. 7299 The debug info of i looks like this: 7300 ``` 7301 (gdb) info address i 7302 Symbol "i" is multi-location: 7303 Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0 7304 Range 0x13fd41600-0x13fd41600: the constant 1 7305 Range 0x13fd41600-0x13fd41600: the constant 2 7306 Range 0x13fd41600-0x13fd41600: the constant 3 7307 Range 0x13fd41600-0x13fd41600: the constant 4 7308 Range 0x13fd41600-0x13fd41600: the constant 5 7309 Range 0x13fd41600-0x13fd41600: the constant 6 7310 Range 0x13fd41600-0x13fd41600: the constant 7 7311 Range 0x13fd41600-0x13fd4160f: the constant 8 7312 (gdb) p i 7313 $1 = 0 7314 ``` 7315 7316 Currently, when at the entry point of a function, it will 7317 always show the initial value (here 0), while the user would 7318 expect the last value (here 8). 7319 This logic was introduced for showing the entry-values of 7320 function arguments if they are available, but for some 7321 reason this was added for non-entry-values as well. 7322 7323 One of the tests of amd64-entry-value.exp shows the same 7324 problem for function arguments, if you "break stacktest" 7325 in the following example, you stop at this line: 7326 ``` 7327 124 static void __attribute__((noinline, noclone)) 7328 125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2, 7329 126 double d1, double d2, double d3, double d4, double d5, double d6, 7330 127 double d7, double d8, double d9, double da) 7331 128 { 7332 129 s1 = 3; 7333 130 s2 = 4; 7334 131 d9 = 3.5; 7335 132 da = 4.5; 7336 133 -> e (v, v); 7337 134 asm ("breakhere_stacktest:"); 7338 135 e (v, v); 7339 136 } 7340 ``` 7341 But `bt` still shows the entry values: 7342 ``` 7343 s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5 7344 ``` 7345 7346 I've fixed this by only using the initial values when 7347 explicitely looking for entry values. 7348 7349 Now the local variable of the first example is as expected: 7350 ``` 7351 (gdb) p i 7352 $1 = 8 7353 ``` 7354 7355 And the test of amd64-entry-value.exp shows the expected 7356 current and entry values of the function arguments: 7357 ``` 7358 s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5 7359 ``` 7360 7361 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987 7362 Tested-By: Guinevere Larsen <blarsen@redhat.com> 7363 Approved-By: Tom Tromey <tom@tromey.com> 7364 73652023-12-16 Tom de Vries <tdevries@suse.de> 7366 7367 [gdb/build] Remove dependency on _rl_term_autowrap 7368 Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a 7369 dependency on readline private variable _rl_term_autowrap. 7370 7371 There is precedent for this, but it's something we want to get rid of 7372 (PR build/10723). 7373 7374 Remove the dependency on _rl_term_autowrap, and instead calculate 7375 readline_hidden_cols by comparing the environment variable COLS with cols as 7376 returned by rl_get_screen_size. 7377 7378 Tested on x86_64-linux. 7379 7380 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10723 7381 73822023-12-16 Tom de Vries <tdevries@suse.de> 7383 7384 [gdb/tui] Show regs when switching to regs layout 7385 When starting gdb in CLI mode, running to main and switching into the TUI regs 7386 layout: 7387 ... 7388 $ gdb -q a.out -ex start -ex "layout regs" 7389 ... 7390 we get: 7391 ... 7392 +---------------------------------+ 7393 | | 7394 | [ Register Values Unavailable ] | 7395 | | 7396 +---------------------------------+ 7397 ... 7398 7399 Fix this by handling this case in tui_data_window::rerender. 7400 7401 Tested on x86_64-linux. 7402 7403 Approved-By: Tom Tromey <tom@tromey.com> 7404 7405 PR tui/28600 7406 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600 7407 74082023-12-16 Tom de Vries <tdevries@suse.de> 7409 7410 [gdb/tui] Use more box_width in tui-regs.c 7411 While experimenting with can_box () == false by default, I noticed two places 7412 in tui-regs.c where we can replace a hardcoded 1 with box_width (). 7413 7414 It also turned out to be necessary to set scrollok to false, otherwise writing 7415 the last char of the last line with register info will cause a scroll. 7416 7417 Tested on x86_64-linux. 7418 7419 Approved-By: Tom Tromey <tom@tromey.com> 7420 74212023-12-16 Mike Frysinger <vapier@gentoo.org> 7422 7423 sim: cr16: clean up unused insn operands 7424 The push/pop insns only have 2 operands, so delete unused "c". 7425 7426 The pushret/popret insns use 2 operands, but they don't implement the 7427 logic directly, they call the push/pop implementations. So delete the 7428 unused "a" & "b". 7429 74302023-12-16 Mike Frysinger <vapier@gentoo.org> 7431 7432 sim: sh: adjust some dsp insn masks 7433 The pmuls encoding is incorrect -- it looks like a copy & paste error 7434 from the padd pmuls variant. The SuperH software manual covers this. 7435 7436 On the flip side, the manual lists pwsb & pwad as insns that exist, 7437 but no description of what they do, what the insn name means, or the 7438 actual encoding. Our sim implementation stubs them both out as nops. 7439 Let's mark the fields to avoid unused variable warnings. 7440 74412023-12-16 Mike Frysinger <vapier@gentoo.org> 7442 7443 sim: sh: tidy up gencode slightly 7444 Mark a few things static/const, and clean up trailing whitespace. 7445 7446 sim: bfin: fix typo in bf52x ports 7447 These should be using the BF52x set of ports, not BF51x. 7448 7449 sim: warnings: enable -Wunused-but-set-variable 7450 7451 sim: mn10300: fix incorrect implementation of a few insns 7452 Fix a few problems caught by compiler warnings: 7453 * Some of the asr & lsr insns were setting up the c state flag, 7454 but then forgetting to set it in the PSW. Add it like the other 7455 asr & lsr variants. 7456 * Some of the dmulh insns were multiplying one of the source regs 7457 against itself instead of against the other source reg. 7458 * The sat16_cmp parallel insn was using the wrong register in the 7459 compare -- the reg1 src/dst pair are used in the sat16 op, and 7460 the reg2 src/dst pair are used in the add op. 7461 74622023-12-16 GDB Administrator <gdbadmin@sourceware.org> 7463 7464 Automatic date update in version.in 7465 74662023-12-15 Tom Tromey <tromey@adacore.com> 7467 7468 Refine Ada overload matching 7469 Currently, the overload handling in Ada assumes that any two array 7470 types are compatible. However, this is obviously untrue, and a user 7471 reported an oddity where comparing two Ada strings resulted in a call 7472 to the "=" function for packed boolean arrays. 7473 7474 This patch improves the situation somewhat, by requiring that the two 7475 arrays have the same arity and compatible base element types. This is 7476 still over-broad, but it seems safe and is better than the status quo. 7477 74782023-12-15 Tom Tromey <tromey@adacore.com> 7479 7480 Boolify ada_type_match 7481 This changes ada_type_match to return bool. 7482 74832023-12-15 John David Anglin <danglin@gcc.gnu.org> 7484 7485 Fix segmentation fault in bfd/elf32-hppa.c 7486 2023-12-15 John David Anglin <danglin@gcc.gnu.org> 7487 7488 PR ld/31148 7489 7490 bfd/ChangeLog: 7491 7492 * elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output 7493 relative reloc only when eh->root.type is bfd_link_hash_defined 7494 or bfd_link_hash_defweak. 7495 74962023-12-15 Matthieu Longo <matthieu.longo@arm.com> 7497 7498 arm: reformat -march option section in gas documentation 7499 Hi, 7500 7501 This patch contains a reformatting of -march option section in gas documentation. 7502 7503 For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options), 7504 before all the options were on one line: 7505 For armv8-a: 7506 +crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables 7507 Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier 7508 Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction 7509 Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions. 7510 +nocrypto: Disables Cryptography Extensions. 7511 7512 Now, the readability is improved thanks to the itemization of the options: 7513 For armv8-a: 7514 +crc: Enables CRC32 Extension. 7515 +simd: Enables VFP and NEON for Armv8-A. 7516 +crypto: Enables Cryptography Extensions for Armv8-A, implies +simd. 7517 +sb: Enables Speculation Barrier Instruction for Armv8-A. 7518 +predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A. 7519 +nofp: Disables all FPU, NEON and Cryptography Extensions. 7520 +nocrypto: Disables Cryptography Extensions. 7521 7522 Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf. 7523 7524 Regards, 7525 Matthieu. 7526 75272023-12-15 Matthieu Longo <matthieu.longo@arm.com> 7528 7529 aarch64: Enable Cortex-X3 CPU 7530 Hi, 7531 7532 This patch adds support for the Cortex-X3 CPU to binutils. 7533 7534 Gas regression testing for aarch64-none-linux-gnu target and found no regressions. 7535 7536 Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf. 7537 7538 Regards, 7539 7540 Matthieu. 7541 75422023-12-15 Matthieu Longo <matthieu.longo@arm.com> 7543 7544 arm: document -march=armv9.[123]-a binutils options 7545 75462023-12-15 Jan Beulich <jbeulich@suse.com> 7547 7548 x86: last-insn recording should be per-subsection 7549 Otherwise intermediate subsection switches result in inconsistent 7550 behavior. Leverage ELF's section change hook to switch state as 7551 necessary, limiting overhead to the bare minimum when subsections aren't 7552 used. 7553 75542023-12-15 Jan Beulich <jbeulich@suse.com> 7555 7556 ELF: reliably invoke md_elf_section_change_hook() 7557 ... after any (sub)section change. While certain existing target hooks 7558 only look at now_seg, for a few others it looks as if failing to do so 7559 could have caused anomalies if sub-sections were used. In any event a 7560 subsequent x86 change is going to require the sub-section to be properly 7561 in place at the time the hook is invoked. 7562 7563 This primarily means for obj_elf_section() to pass the new subsection 7564 into change_section(), for it to be set right away (ahead of invoking 7565 the hook). 7566 7567 Also adjust obj_elf_ident() to invoke the hook after all section 7568 changes. (Note that obj_elf_version(), which also changes sections and 7569 then changes them back, has no hook invocation at all so far, so none 7570 are added. Presumably there is a reason for this difference in 7571 behavior.) 7572 75732023-12-15 Jan Beulich <jbeulich@suse.com> 7574 7575 ELF: drop "push" parameter from obj_elf_change_section() 7576 No caller outside of obj-elf.c cares about the parameter - drop it by 7577 introducing an obj-elf.c-internal wrapper. 7578 7579 While adding the new function parameter, take the opportunity and change 7580 the adjacent boolean one to "bool". 7581 75822023-12-15 Jan Beulich <jbeulich@suse.com> 7583 7584 x86: don't needlessly override .bss 7585 ELF, COFF, and Mach-O all have custom handlers for .bss. Don't override 7586 those; install a handler only for a.out. 7587 7588 revert "x86: allow 32-bit reg to be used with U{RD,WR}MSR" 7589 This reverts commit 1f865bae65db9588f6994c02a92355bfb4e3d955. The 7590 specification is going to by updated in a way rendering this change 7591 wrong. 7592 7593 x86: fold assembly dialect attributes 7594 Now that ATTSyntax and ATTMnemonic aren't use in combination anymore, 7595 fold them and IntelSyntax into a single, enum-like attribute. Note that 7596 this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's 7597 not for long, seeing in-flight additions for APX). 7598 75992023-12-15 Jan Beulich <jbeulich@suse.com> 7600 7601 x86: Intel syntax implies Intel mnemonics 7602 As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly 7603 of fsub*/fdiv*") there's no such thing as Intel syntax without Intel 7604 mnemonics. Enforce this on the assembler side, and disentangle command 7605 line option handling on the disassembler side accordingly. 7606 7607 As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes 7608 redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and 7609 remove the then no longer accessible templates. 7610 76112023-12-15 Jan Beulich <jbeulich@suse.com> 7612 7613 Arm64: fix build for certain gcc versions 7614 Some complain (by default) about isalpha shadowing ctype.h's isalpha(). 7615 Some also complain about signed/unsigned comparison a few lines later. 7616 76172023-12-15 Georg-Johann Lay <avr@gjlay.de> 7618 7619 Addendum to PR31124 7620 This is a small addendum to PR31124 "rodata in flash for 7621 more AVR devices". 7622 7623 It adds some symbols so the startup code can set a lock 7624 on the FLMAP bit field as specified by the user. 7625 7626 New symbols are introduced because otherwise, all the 7627 computations / decisions would have to be performed at 7628 run-time. 7629 7630 It approved, please apply to master. 7631 7632 Johann 7633 7634 -- 7635 7636 ld/ 7637 PR 31124 7638 * scripttempl/avr.sc: Adjust comments. 7639 [MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock. 7640 Remove __flmap_lsl4. 7641 76422023-12-15 Mike Frysinger <vapier@gentoo.org> 7643 7644 sim: m32r: fix mloop.in variant stamp deps 7645 The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053 7646 accidentally listed the deps for all mloop steps as mloop.in instead of the 7647 various variants that m32r uses. 7648 7649 Reported-by: Simon Marchi <simon.marchi@polymtl.ca> 7650 76512023-12-15 Mike Frysinger <vapier@gentoo.org> 7652 7653 sim: m32r: use @cpu@_fill_argbuf_tp to set trace & profile state 7654 The mloop.in code does this, but these variants do not. Use it to 7655 avoid unused function warnings. The fast_p logic in these files 7656 also looks off, but that'll require a bit more work to fixup. 7657 7658 CC m32r/mloopx.o 7659 m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function] 7660 37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf, 7661 | ^~~~~~~~~~~~~~~~~~~~~ 7662 7663 CC m32r/mloop2.o 7664 m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function] 7665 37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf, 7666 | ^~~~~~~~~~~~~~~~~~~~~ 7667 7668 Reported-by: Simon Marchi <simon.marchi@polymtl.ca> 7669 Tested-By: Simon Marchi <simon.marchi@polymtl.ca> 7670 76712023-12-15 Mike Frysinger <vapier@gentoo.org> 7672 7673 sim: igen: do not reindent literal semantics output 7674 When generating semantics.c from .igen source files, indenting the code 7675 makes it more readable, but confuses compiler diagnostics. The latter 7676 is a bit more important than the former, so bias towards that. 7677 7678 For example, with an introduced error, we can see w/gcc-13: 7679 7680 (before this change) 7681 CC mn10300/semantics.o 7682 ../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’: 7683 ../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function) 7684 11 | srcreg = translate_rreg (SD_, RN2); 7685 | ^~~~~~ 7686 7687 (with this change) 7688 CC mn10300/semantics.o 7689 ../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’: 7690 ../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function) 7691 11 | srcreg = translate_rreg (SD_, RN2); 7692 | ^~~~~~ 7693 76942023-12-15 Alan Modra <amodra@gmail.com> 7695 7696 regen ld POTFILES 7697 7698 PR31145, potential memory leak in binutils/ld 7699 PR 31145 7700 * bfd.c (BFD_IN_MEMORY): Mention that bim is malloc'd. 7701 * format.c (io_reinit): Free BFD_IN_MEMORY iostream. 7702 * opncls.c (_bfd_delete_bfd): Likewise. 7703 (bfd_make_readable): Delete unnecessary code. 7704 * bfd-in2.h: Regenerate. 7705 7706 Re: readelf..debug-dump=loc displays bogus base addresses 7707 Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to 7708 prevent segfaults when debug_info_p is NULL, which can be the case 7709 with fuzzed objects. Restore those checks. Also, for dwo look at 7710 rnglists_dwo rather than rnglists. 7711 77122023-12-15 Xiao Zeng <zengxiao@eswincomputing.com> 7713 7714 RISC-V: Imply 'Zicntr' and 'Zihpm' implicitly depended on 'Zicsr' 7715 This commit adds support for ratified extensions: 7716 'Zicntr' and 'Zihpm', Which are all implicitly depend on 'Zicsr'. 7717 7718 This is based on: 7719 <https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf> 7720 7721 bfd/ChangeLog: 7722 7723 * elfxx-riscv.c: Add 'Zicntr' and 'Zihpm' -> 'Zicsr'. 7724 (riscv_supported_std_z_ext) Add 'Zicntr' and 'Zihpm' to the list. 7725 77262023-12-15 GDB Administrator <gdbadmin@sourceware.org> 7727 7728 Automatic date update in version.in 7729 77302023-12-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 7731 7732 gprofng: fix -Wuse-after-free warning 7733 Removed incorrect unnecessary code. 7734 7735 gprofng/ChangeLog 7736 2023-12-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 7737 7738 * src/collctrl.cc (set_synctrace): Fix -Wuse-after-free warning. 7739 77402023-12-14 Andrew Burgess <aburgess@redhat.com> 7741 7742 gdb/options: fix copy&paste error in string_option_def 7743 Spotted what appears to be a copy&paste error in string_option_def, 7744 the code for string handling writes the address fetching callback 7745 function into the option_def::var_address::enumeration location, 7746 rather than option_def::var_address::string. 7747 7748 Of course, this works just fine as option_def::var_address is a union, 7749 and all of its members are function pointers, so they're going to be 7750 the same size on every target GDB cares about. 7751 7752 But it doesn't hurt to be correct, so fixed in this commit. 7753 7754 There should be no user visible changes after this commit. 7755 77562023-12-14 Simon Marchi <simon.marchi@polymtl.ca> 7757 7758 gdb/testsuite: add tests for unwinding of pseudo registers 7759 This patch adds tests to exercise the previous patches' changes. 7760 7761 All three tests: 7762 7763 - aarch64-pseudo-unwind 7764 - amd64-pseudo-unwind 7765 - arm-pseudo-unwind 7766 7767 follow the same pattern, just with different registers. 7768 7769 The other test, arm-pseudo-unwind-legacy, tests the special case where 7770 the unwind information contains an entry for a register considered a 7771 pseudo-register by GDB. 7772 7773 Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f 7774 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7775 Reviewed-by: Luis Machado <luis.machado@arm.com> 7776 Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm) 7777 Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm) 7778 77792023-12-14 Simon Marchi <simon.marchi@efficios.com> 7780 7781 gdb: migrate arm to new gdbarch_pseudo_register_write 7782 Make arm use the new gdbarch_pseudo_register_write. This fixes writing 7783 pseudo registers to non-current frames for that architecture. 7784 7785 Change-Id: Icb2a649ab6394817844230e9e94c3d0564d2f765 7786 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7787 Approved-by: Luis Machado <luis.machado@arm.com> 7788 77892023-12-14 Simon Marchi <simon.marchi@efficios.com> 7790 7791 gdb: migrate arm to gdbarch_pseudo_register_read_value 7792 Make arm use the "newer" gdbarch_pseudo_register_read_value. This fixes 7793 reading pseudo registers in non-current frames on that architecture. 7794 7795 Change-Id: Ic4d3d5d96957a4addfa3443c7b567dc4a31794a9 7796 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7797 Approved-by: Luis Machado <luis.machado@arm.com> 7798 77992023-12-14 Simon Marchi <simon.marchi@efficios.com> 7800 7801 gdb: migrate aarch64 to new gdbarch_pseudo_register_write 7802 Make aarch64 use the new gdbarch_pseudo_register_write. This fixes 7803 writing pseudo registers to non-current frames on this architecture. 7804 7805 Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e 7806 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7807 Approved-By: Luis Machado <luis.machado@arm.com> 7808 Tested-By: Luis Machado <luis.machado@arm.com> 7809 78102023-12-14 Simon Marchi <simon.marchi@efficios.com> 7811 7812 gdb: add missing raw register read in aarch64_sme_pseudo_register_write 7813 It seems like the intention here is to read the contents of the ZA 7814 register and only write part of it. However, there's no actual read of 7815 the ZA register, so it looks like we'll write uninitialized bytes to the 7816 target, for the portion of the raw register where we don't write the 7817 pseudo register. Add a call to raw_read to fix this. 7818 7819 I don't know how to test this though. 7820 7821 Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e 7822 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7823 Approved-by: Luis Machado <luis.machado@arm.com> 7824 78252023-12-14 Simon Marchi <simon.marchi@efficios.com> 7826 7827 gdb: make aarch64_za_offsets_from_regnum return za_offsets 7828 This is not necessary, but it seems more natural to me to make 7829 aarch64_za_offsets_from_regnum return a za_offsets object, rather than 7830 fill an instance passed by parameter. 7831 7832 Change-Id: I40a185f055727da887ce7774be193eef1f4b9147 7833 Approved-by: Luis Machado <luis.machado@arm.com> 7834 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7835 78362023-12-14 Simon Marchi <simon.marchi@efficios.com> 7837 7838 gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_write 7839 Make i386 and amd64 use the new gdbarch_pseudo_register_write. This 7840 fixes writing to pseudo registers in non-current frames for those 7841 architectures. 7842 7843 Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f 7844 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7845 78462023-12-14 Simon Marchi <simon.marchi@efficios.com> 7847 7848 gdb: add gdbarch_pseudo_register_write that takes a frame 7849 Add a new variant of gdbarch_pseudo_register_write that takes a 7850 frame_info in order to write raw registers. Use this new method when 7851 available: 7852 7853 - in put_frame_register, when trying to write a pseudo register to a given frame 7854 - in regcache::cooked_write 7855 7856 No implementation is migrated to use this new method (that will come in 7857 subsequent patches), so no behavior change is expected here. 7858 7859 The objective is to fix writing pseudo registers to non-current 7860 frames. See previous commit "gdb: read pseudo register through 7861 frame" for a more detailed explanation. 7862 7863 Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac 7864 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7865 78662023-12-14 Simon Marchi <simon.marchi@efficios.com> 7867 7868 gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write 7869 The next patch introduces a new variant of gdbarch_pseudo_register_write 7870 that takes a frame instead of a regcache for implementations to write 7871 raw registers. Rename to old one to make it clear it's deprecated. 7872 7873 Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115 7874 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7875 78762023-12-14 Simon Marchi <simon.marchi@efficios.com> 7877 7878 gdb: change parameter name in frame_unwind_register_unsigned declaration 7879 For consistency with the declarations around. 7880 7881 Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4 7882 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7883 78842023-12-14 Simon Marchi <simon.marchi@efficios.com> 7885 7886 gdb: read pseudo register through frame 7887 Change gdbarch_pseudo_register_read_value to take a frame instead of a 7888 regcache. The frame (and formerly the regcache) is used to read raw 7889 registers needed to make up the pseudo register value. The problem with 7890 using the regcache is that it always provides raw register values for 7891 the current frame (frame 0). 7892 7893 Let's say the user wants to read the ebx register on amd64. ebx is a pseudo 7894 register, obtained by reading the bottom half (bottom 4 bytes) of the 7895 rbx register, which is a raw register. If the currently selected frame 7896 is frame 0, it works fine: 7897 7898 (gdb) frame 0 7899 #0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36 7900 36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S 7901 (gdb) p/x $ebx 7902 $1 = 0x24252627 7903 (gdb) p/x $rbx 7904 $2 = 0x2021222324252627 7905 7906 But if the user is looking at another frame, and the raw register behind 7907 the pseudo register has been saved at some point in the call stack, then 7908 we get a wrong answer: 7909 7910 (gdb) frame 1 7911 #1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56 7912 56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S 7913 (gdb) p/x $ebx 7914 $3 = 0x24252627 7915 (gdb) p/x $rbx 7916 $4 = 0x1011121314151617 7917 7918 Here, the value of ebx was computed using the value of rbx in frame 0 7919 (through the regcache), it should have been computed using the value of 7920 rbx in frame 1. 7921 7922 In other to make this work properly, make the following changes: 7923 7924 - Make dwarf2_frame_prev_register return nullptr if it doesn't know how 7925 to unwind a register and that register is a pseudo register. 7926 Previously, it returned `frame_unwind_got_register`, meaning, in our 7927 example, "the value of ebx in frame 1 is the same as the value of ebx 7928 in frame 0", which is obviously false. Return nullptr as a way to 7929 say "I don't know". 7930 7931 - In frame_unwind_register_value, when prev_register (for instance 7932 dwarf2_frame_prev_register) returns nullptr, and we are trying to 7933 read a pseudo register, try to get the register value through 7934 gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read. 7935 If using gdbarch_pseudo_register_read, the behavior is known to be 7936 broken. Implementations should be migrated to use 7937 gdbarch_pseudo_register_read_value to fix that. 7938 7939 - Change gdbarch_pseudo_register_read_value to take a frame_info 7940 instead of a regcache, update implementations (aarch64, amd64, i386). 7941 In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that 7942 uses a frame instead of a regcache. The version using the regcache 7943 is still used by i386_pseudo_register_write. It will get removed in 7944 a subsequent patch. 7945 7946 - Add some helpers in value.{c,h} to implement the common cases of 7947 pseudo registers: taking part of a raw register and concatenating 7948 multiple raw registers. 7949 7950 - Update readable_regcache::{cooked_read,cooked_read_value} to pass the 7951 current frame to gdbarch_pseudo_register_read_value. Passing the 7952 current frame will give the same behavior as before: for frame 0, raw 7953 registers will be read from the current thread's regcache. 7954 7955 Notes: 7956 7957 - I do not plan on changing gdbarch_pseudo_register_read to receive a 7958 frame instead of a regcache. That method is considered deprecated. 7959 Instead, we should be working on migrating implementations to use 7960 gdbarch_pseudo_register_read_value instead. 7961 7962 - In frame_unwind_register_value, we still ask the unwinder to try to 7963 unwind pseudo register values. It's apparently possible for the 7964 debug info to provide information about [1] pseudo registers, so we 7965 want to try that first, before falling back to computing them 7966 ourselves. 7967 7968 [1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/ 7969 7970 Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca 7971 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 7972 79732023-12-14 Simon Marchi <simon.marchi@efficios.com> 7974 7975 gdb: add value::allocate_register 7976 Add value::allocate_register, to facilitate allocating a value 7977 representing a register in a given frame (or rather, in the given 7978 frame's previous frame). It will be used in a subsequent patch. I 7979 changed one relatively obvious spot that could use it, to at least 7980 exercise the code path. 7981 7982 Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772 7983 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7984 79852023-12-14 Simon Marchi <simon.marchi@efficios.com> 7986 7987 gdb: make get_frame_register_bytes take the next frame 7988 Similar to the previous patches, change get_frame_register_bytes to take 7989 the "next frame" instead of "this frame". 7990 7991 Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f 7992 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 7993 79942023-12-14 Simon Marchi <simon.marchi@efficios.com> 7995 7996 gdb: make put_frame_register_bytes take the next frame 7997 Similar to the previous patches, change put_frame_register_bytes to take 7998 the "next frame" instead of "this frame". 7999 8000 Change-Id: I27bcb26573686d99b231230823cff8db6405a788 8001 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8002 80032023-12-14 Simon Marchi <simon.marchi@efficios.com> 8004 8005 gdb: make put_frame_register take the next frame 8006 Similar to the previous patches, change put_frame_register to take the 8007 "next frame" instead of "this frame". 8008 8009 Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b 8010 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8011 80122023-12-14 Simon Marchi <simon.marchi@efficios.com> 8013 8014 gdb: remove frame_register 8015 I was going to change frame_register to take the "next frame", but I 8016 realized that doing so would make it a useless wrapper around 8017 frame_register_unwind. So, just remove frame_register and replace uses 8018 with frame_register_unwind. 8019 8020 Change-Id: I185868bc69f8e098124775d0550d069220a4678a 8021 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8022 80232023-12-14 Simon Marchi <simon.marchi@efficios.com> 8024 8025 gdb: change value_of_register and value_of_register_lazy to take the next frame 8026 Some functions related to the handling of registers in frames accept 8027 "this frame", for which we want to read or write the register values, 8028 while other functions accept "the next frame", which is the frame next 8029 to that. The later is needed because we sometimes need to read register 8030 values for a frame that does not exist yet (usually when trying to 8031 unwind that frame-to-be). 8032 8033 value_of_register and value_of_register_lazy both take "this frame", 8034 even if what they ultimately want internally is "the next frame". This 8035 is annoying if you are in a spot that currently has "the next frame" and 8036 need to call one of these functions (which happens later in this 8037 series). You need to get the previous frame only for those functions to 8038 get the next frame again. This is more manipulations, more chances of 8039 mistake. 8040 8041 I propose to change these functions (and a few more functions in the 8042 subsequent patches) to operate on "the next frame". Things become a bit 8043 less awkward when all these functions agree on which frame they take. 8044 8045 So, in this patch, change value_of_register_lazy and value_of_register 8046 to take "the next frame" instead of "this frame". This adds a lot of 8047 get_next_frame_sentinel_okay, but if we convert the user registers API 8048 to also use "the next frame" instead of "this frame", it will get simple 8049 again. 8050 8051 Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd 8052 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8053 80542023-12-14 Simon Marchi <simon.marchi@efficios.com> 8055 8056 gdb: make put_frame_register take an array_view 8057 Change put_frame_register to take an array_view instead of a raw 8058 pointer. 8059 8060 Add an assertion to verify that the number of bytes we try to write 8061 matches the length of the register. 8062 8063 Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae 8064 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8065 80662023-12-14 Simon Marchi <simon.marchi@efficios.com> 8067 8068 gdb: fix bugs in {get,put}_frame_register_bytes 8069 I found this only by inspection: the myaddr pointer in 8070 {get,put}_frame_register_bytes is reset to `buffer.data ()` at each 8071 iteration. This means that we will always use the bytes at the 8072 beginning of `buffer` to read or write to the registers, instead of 8073 progressing in `buffer`. 8074 8075 Fix this by re-writing the functions to chip away the beginning of the 8076 buffer array_view as we progress in reading or writing the data. 8077 8078 These bugs was introduced almost 3 years ago [1], and yet nobody 8079 complained. I'm wondering which architecture relies on that register 8080 "overflow" behavior (reading or writing multiple consecutive registers 8081 with one {get,put}_frame_register_bytes calls), and in which situation. 8082 I find these functions a bit dangerous, if a caller mis-calculates 8083 things, it could end up silently reading or writing to the next 8084 register, even if it's not the intent. 8085 8086 If I could change it, I would prefer to have functions specifically made 8087 for that ({get,put}_frame_register_bytes_consecutive or something like 8088 that) and make {get,put}_frame_register_bytes only able to write within 8089 a single register (which I presume represents most of the use cases of 8090 the current {get,put}_frame_register_bytes). If a caller mis-calculates 8091 things and an overflow occurs while calling 8092 {get,put}_frame_register_bytes, it would hit an assert. The problem is 8093 knowing which callers rely on the overflow behavior and which don't. 8094 8095 [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43 8096 8097 Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8 8098 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8099 Approved-By: Andrew Burgess <aburgess@redhat.com> 8100 81012023-12-14 Simon Marchi <simon.marchi@efficios.com> 8102 8103 gdb: change regcache interface to use array_view 8104 Change most of regcache (and base classes) to use array_view when 8105 possible, instead of raw pointers. By propagating the use of array_view 8106 further, it enables having some runtime checks to make sure the what we 8107 read from or write to regcaches has the expected length (such as the one 8108 in the `copy(array_view, array_view)` function. It also integrates well 8109 when connecting with other APIs already using gdb::array_view. 8110 8111 Add some overloads of the methods using raw pointers to avoid having to 8112 change all call sites at once (which is both a lot of work and risky). 8113 8114 I tried to do this change in small increments, but since many of these 8115 functions use each other, it ended up simpler to do it in one shot than 8116 having a lot of intermediary / transient changes. 8117 8118 This change extends into gdbserver as well, because there is some part 8119 of the regcache interface that is shared. 8120 8121 Changing the reg_buffer_common interface to use array_view caused some 8122 build failures in nat/aarch64-scalable-linux-ptrace.c. That file 8123 currently "takes advantage" of the fact that 8124 reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which 8125 IMO is dangerous. It uses raw_supply/raw_collect directly on 8126 uint64_t's, which I guess is fine because it is expected that native 8127 code will have the same endianness as the debugged process. To 8128 accomodate that, add some overloads of raw_collect and raw_supply that 8129 work on uint64_t. 8130 8131 This file also uses raw_collect and raw_supply on `char` pointers. 8132 Change it to use `gdb_byte` pointers instead. Add overloads of 8133 raw_collect and raw_supply that work on `gdb_byte *` and make an 8134 array_view on the fly using the register's size. Those call sites could 8135 be converted to use array_view with not much work, in which case these 8136 overloads could be removed, but I didn't want to do it in this patch, to 8137 avoid starting to dig in arch-specific code. 8138 8139 During development, I inadvertently changed reg_buffer::raw_compare's 8140 behavior to not accept an offset equal to the register size. This 8141 behavior (effectively comparing 0 bytes, returning true) change was 8142 caught by the AArch64 SME core tests. Add a selftest to make sure that 8143 this raw_compare behavior is preserved in the future. 8144 8145 Change-Id: I9005f04114543ddff738949e12d85a31855304c2 8146 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8147 81482023-12-14 Simon Marchi <simon.marchi@efficios.com> 8149 8150 gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part 8151 Make a few simplifications in these functions. 8152 8153 1. When checking if we need to do nothing, if the length is 0, we don't 8154 need to do anything, regardless of the value of offset. Remove the 8155 offset check. 8156 8157 2. When check if transferring the whole register, if the length is equal 8158 to the register size, then we transfer the whole register, no need to 8159 check the offset. Remove the offset check. 8160 8161 3. In the gdb_asserts, it is unnecessary to check for: 8162 8163 offset <= reg_size 8164 8165 given that right after we check for: 8166 8167 len >= 0 && offset + len <= reg_size 8168 8169 If `offset + len` is <= reg_size and len is >= 0, then necessarily 8170 offset is <= reg_size. Remove the `offset <= reg_size` check. 8171 8172 Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8 8173 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8174 81752023-12-14 Simon Marchi <simon.marchi@efficios.com> 8176 8177 gdb: make store_integer take an array_view 8178 Change store_integer, store_signed_integer and store_unsigned_integer to 8179 accept an array_view. Add some backwards compatibility overloads to 8180 avoid changing all callers at once. 8181 8182 Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03 8183 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8184 81852023-12-14 Simon Marchi <simon.marchi@efficios.com> 8186 8187 gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h 8188 Right now, gdbsupport/common-regcache.h contains two abstractons for a 8189 regcache. An opaque type `regcache` (gdb and gdbserver both have their 8190 own regcache that is the concrete version of this) and an abstract base 8191 class `reg_buffer_common`, that is the base of regcaches on both sides. 8192 These abstractions allow code to be written for both gdb and gdbserver, 8193 for instance in the gdb/arch sub-directory. 8194 8195 However, having two 8196 different abstractions is impractical. If some common code has a regcache, 8197 and wants to use an operation defined on reg_buffer_common, it can't. 8198 It would be better to have just one. Change all instances of `regcache 8199 *` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix 8200 fallouts. 8201 8202 Implementations in gdb and gdbserver now need to down-cast (using 8203 gdb::checked_static_cast) from reg_buffer_common to their concrete 8204 regcache type. Some of them could be avoided by changing free functions 8205 (like regcache_register_size) to be virtual methods on 8206 reg_buffer_common. I tried it, it seems to work, but I did not include 8207 it in this series to avoid adding unnecessary changes. 8208 8209 Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd 8210 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 8211 82122023-12-14 Simon Marchi <simon.marchi@efficios.com> 8213 8214 gdb: don't handle i386 k registers as pseudo registers 8215 I think that i386 k registers are raw registers, and therefore shouldn't 8216 be handled in the various functions handling pseudo registers. 8217 8218 What tipped me off is the code in i386_pseudo_register_read_into_value: 8219 8220 else if (i386_k_regnum_p (gdbarch, regnum)) 8221 { 8222 regnum -= tdep->k0_regnum; 8223 8224 /* Extract (always little endian). */ 8225 status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf); 8226 8227 We take regnum (the pseudo register number we want to read), subtract 8228 k0_regnum, add k0_regnum, and pass the result to raw_read. So we would 8229 end up calling raw_read with the same regnum as the function received 8230 which is supposedly a pseudo register number. 8231 8232 Other hints are: 8233 8234 - The command `maint print raw-registers` shows the k registers. 8235 - Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be 8236 called. 8237 - There's code in i387-tdep.c to save/restore the k registers. 8238 8239 Remove handling of the k registers from: 8240 8241 - i386_pseudo_register_read_into_value 8242 - i386_pseudo_register_write 8243 - i386_ax_pseudo_register_collect 8244 8245 Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562 8246 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 8247 82482023-12-14 Hannes Domani <ssbssa@yahoo.de> 8249 8250 Allow calling of variadic C++ functions 8251 Currently, it's not possible to call a variadic C++ function: 8252 ``` 8253 (gdb) print sum_vararg_int(1, 10) 8254 Cannot resolve function sum_vararg_int to any overloaded instance 8255 (gdb) print sum_vararg_int(2, 20, 30) 8256 Cannot resolve function sum_vararg_int to any overloaded instance 8257 ``` 8258 8259 It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS 8260 rank by rank_function, which disqualifies the function. 8261 8262 To fix this, I've created the new VARARG_BADNESS rank, which is 8263 used only for additional arguments of variadic functions, allowing 8264 them to be called: 8265 ``` 8266 (gdb) print sum_vararg_int(1, 10) 8267 $1 = 10 8268 (gdb) print sum_vararg_int(2, 20, 30) 8269 $2 = 50 8270 ``` 8271 8272 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589 8273 Approved-By: Tom Tromey <tom@tromey.com> 8274 82752023-12-14 Jin Ma <jinma@linux.alibaba.com> 8276 8277 RISC-V: Fix the wrong encoding and operand of the XTheadFmv extension. 8278 The description of instructions 'th.fmv.hw.x' and 'th.fmv.x.hw' of the 8279 XTheadFmv extension in T-Head specific is incorrect, and it also has 8280 some impact on the implementation of the binutils, so this patch 8281 corrects this. 8282 8283 For details see: 8284 https://github.com/T-head-Semi/thead-extension-spec/pull/34 8285 8286 gas/ChangeLog: 8287 8288 * testsuite/gas/riscv/x-thead-fmv.d: Correct test. 8289 * testsuite/gas/riscv/x-thead-fmv.s: Likewise. 8290 8291 include/ChangeLog: 8292 8293 * opcode/riscv-opc.h (MATCH_TH_FMV_HW_X): Correct coding. 8294 (MASK_TH_FMV_HW_X): Likewise. 8295 (MATCH_TH_FMV_X_HW): Likewise. 8296 (MASK_TH_FMV_X_HW): Likewise. 8297 8298 opcodes/ChangeLog: 8299 8300 * riscv-opc.c: Correct operands. 8301 83022023-12-14 Cui, Lili <lili.cui@intel.com> 8303 8304 Remove redundant Byte, Word, Dword and Qword from insn templates. 8305 opcodes/ChangeLog: 8306 8307 * i386-opc.tbl: Remove redundant Byte, Word, Dword and Qword. 8308 83092023-12-14 GDB Administrator <gdbadmin@sourceware.org> 8310 8311 Automatic date update in version.in 8312 83132023-12-13 Tom Tromey <tom@tromey.com> 8314 8315 Use unique_xmalloc_ptr in explicit_location_spec 8316 This changes explicit_location_spec to use unique_xmalloc_ptr, 8317 removing some manual memory management. 8318 8319 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8320 83212023-12-13 Tom Tromey <tom@tromey.com> 8322 8323 Use unique_xmalloc_ptr in linespec_location_spec 8324 This changes linespec_location_spec to use unique_xmalloc_ptr, 8325 removing some manual memory management. 8326 8327 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 8328 83292023-12-13 H.J. Lu <hjl.tools@gmail.com> 8330 8331 Update Make const_1_mode print $1 in AT&T syntax 8332 commit b70a487d5945b13e5ab503be4fc37b964819ec0e 8333 Author: Cui, Lili <lili.cui@intel.com> 8334 Date: Wed Dec 13 06:07:36 2023 +0000 8335 8336 Make const_1_mode print $1 in AT&T syntax 8337 8338 changes disassembler output from 8339 8340 d1 f8 sar %eax 8341 8342 to 8343 8344 d1 f8 sar $1,%eax 8345 8346 Adjust pe-x86-64-6.od accordingly. 8347 8348 * testsuite/ld-x86-64/pe-x86-64-6.od: Adjusted. 8349 83502023-12-13 Magne Hov <mhov@undo.io> 8351 8352 [gdb/tui] add SingleKey bindings for reverse execution commands 8353 The bindings for the reverse execution commands are the same letters 8354 as the forward execution command, but with the opposite case. This way 8355 one can simply hold down the Shift modifier key or tap the Caps Lock key 8356 to change the direction of execution. 8357 8358 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 8359 Approved-By: Tom Tromey <tom@tromey.com> 8360 83612023-12-13 Andrew Burgess <aburgess@redhat.com> 8362 8363 gdb/python: avoid use of _PyOS_ReadlineTState 8364 In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState, 8365 however, this variable is no longer public in Python 3.13, and so GDB 8366 no longer builds. 8367 8368 We are making use of _PyOS_ReadlineTState in order to re-acquire the 8369 Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState 8370 variable is set in Python's outer readline code prior to calling the 8371 user (GDB) supplied readline callback function, which for us is 8372 gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called 8373 without the GIL held. 8374 8375 Instead of using _PyOS_ReadlineTState, I propose that we switch to 8376 calling PyGILState_Ensure() and PyGILState_Release(). These functions 8377 will acquire the GIL based on the current thread. I think this should 8378 be sufficient; I can't imagine why we'd be running 8379 gdbpy_readline_wrapper on one thread on behalf of a different Python 8380 thread.... that would be unexpected I think. 8381 8382 Approved-By: Tom Tromey <tom@tromey.com> 8383 83842023-12-13 Alexandra Hájková <ahajkova@redhat.com> 8385 8386 gdb: move gdbpy_gil into python-internal.h 8387 Move gdbpy_gil class into python-internal.h, the next 8388 commit wants to make use of this class from a file other 8389 than python.c. 8390 8391 Approved-By: Tom Tromey <tom@tromey.com> 8392 83932023-12-13 Andrew Burgess <aburgess@redhat.com> 8394 8395 gdb: improve error reporting for 'save gdb-index' 8396 While making recent changes to 'save gdb-index' command I triggered 8397 some errors -- of the kind a user might be expected to trigger if they 8398 do something wrong -- and I didn't find GDB's output as helpful as it 8399 might be. 8400 8401 For example: 8402 8403 $ gdb -q /tmp/hello.x 8404 ... 8405 (gdb) save gdb-index /non_existing_dir 8406 Error while writing index for `/tmp/hello': mkstemp: No such file or directory. 8407 8408 That the error message mentions '/tmp/hello', which does exist, but 8409 doesn't mention '/non_existing_dir', which doesn't is, I think, 8410 confusing. 8411 8412 Also, I find the 'mkstemp' in the error message confusing for a user 8413 facing error. A user might not know what mkstemp means, and even if 8414 they do, that it appears in the error message is an internal GDB 8415 detail. The user doesn't care what function failed, but wants to know 8416 what was wrong with their input, and what they should do to fix 8417 things. 8418 8419 Similarly, for a directory that does exist, but can't be written to: 8420 8421 (gdb) save gdb-index /no_access_dir 8422 Error while writing index for `/tmp/hello': mkstemp: Permission denied. 8423 8424 In this case, the 'Permission denied' might make the user thing there 8425 is a permissions issue with '/tmp/hello', which is not the case. 8426 8427 After this patch, the new errors are: 8428 8429 (gdb) save gdb-index /non_existing_dir 8430 Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory. 8431 8432 and: 8433 8434 (gdb) save gdb-index /no_access_dir 8435 Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied. 8436 8437 we also have: 8438 8439 (gdb) save gdb-index /tmp/not_a_directory 8440 Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory. 8441 8442 I think these do a better job of guiding the user towards fixing the 8443 problem. 8444 8445 I've added a new test that exercises all of these cases, and also 8446 checks the case where a user tries to use an executable that already 8447 contains an index in order to generate an index. As part of the new 8448 test I've factored out some code from ensure_gdb_index (lib/gdb.exp) 8449 into a new proc (get_index_type), which I've then used in the new 8450 test. I've confirmed that all the tests that use ensure_gdb_index 8451 still pass. 8452 8453 During review it was pointed out that the testsuite proc 8454 have_index (lib/gdb.exp) is similar to the new get_index_type proc, so 8455 I've rewritten have_index to also use get_index_type, I've confirmed 8456 that all the tests that use have_index still pass. 8457 8458 Nothing that worked correctly before this patch should give an error 8459 after this patch; I've only changed the output when the user was going 8460 to get an error anyway. 8461 8462 Reviewed-By: Tom de Vries <tdevries@suse.de> 8463 Reviewed-By: Tom Tromey <tom@tromey.com> 8464 Approved-By: Tom Tromey <tom@tromey.com> 8465 84662023-12-13 Cui, Lili <lili.cui@intel.com> 8467 8468 Make const_1_mode print $1 in AT&T syntax 8469 Make const_1_mode print $1 in AT&T syntax, otherwise 8470 there will be correctness issues when it is extended 8471 to support APX NDD, 8472 8473 gas/ChangeLog: 8474 8475 * testsuite/gas/i386/intel.d: Adjust testcase. 8476 * testsuite/gas/i386/lfence-load.d: Ditto. 8477 * testsuite/gas/i386/noreg16-data32.d: Ditto. 8478 * testsuite/gas/i386/noreg16.d: Ditto. 8479 * testsuite/gas/i386/noreg32-data16.d: Ditto. 8480 * testsuite/gas/i386/noreg32.d: Ditto. 8481 * testsuite/gas/i386/noreg64-data16.d: Ditto. 8482 * testsuite/gas/i386/noreg64-rex64.d: Ditto. 8483 * testsuite/gas/i386/noreg64.d: Ditto. 8484 * testsuite/gas/i386/opcode-suffix.d: Ditto. 8485 * testsuite/gas/i386/opcode.d: Ditto. 8486 * testsuite/gas/i386/x86-64-lfence-load.d: Ditto. 8487 * testsuite/gas/i386/x86-64-opcode.d: Ditto. 8488 8489 opcodes/ChangeLog: 8490 8491 * i386-dis.c (OP_I): Make const_1_mode print $1 in AT&T syntax. 8492 84932023-12-13 Cui, Lili <lili.cui@intel.com> 8494 8495 Clean base_reg and assign correct values to regs for input_output_operand (%dx). 8496 For special processing of input and output operands (%dx), 8497 the state of some variables needs to be cleaned. 8498 8499 gas/ChangeLog: 8500 8501 * config/tc-i386.c (i386_att_operand): Assign values to regs and 8502 clean i.base_reg for input output operand (%dx). 8503 85042023-12-13 GDB Administrator <gdbadmin@sourceware.org> 8505 8506 Automatic date update in version.in 8507 85082023-12-12 Stefano Moioli <smxdev4@gmail.com> 8509 8510 gdbserver/win32: fix crash on detach 8511 this patch fixes a crash in gdbserver whenever a process is detached. 8512 the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors` 8513 8514 error message: 8515 8516 Detaching from process 184 8517 ../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec 8518 ted. 8519 remove_process: Assertion `find_thread_process (process) == NULL' failed. 8520 8521 This application has requested the Runtime to terminate it in an unusual way. 8522 Please contact the application's support team for more information. 8523 8524 Approved-By: Tom Tromey <tom@tromey.com> 8525 85262023-12-12 Hannes Domani <ssbssa@yahoo.de> 8527 8528 Fix gdb.FinishBreakpoint when returning to an inlined function 8529 Currently, when creating a gdb.FinishBreakpoint in a function 8530 called from an inline frame, it will never be hit: 8531 ``` 8532 (gdb) py fb=gdb.FinishBreakpoint() 8533 Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47. 8534 (gdb) c 8535 Continuing. 8536 Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list. 8537 [Inferior 1 (process 1208) exited normally] 8538 ``` 8539 8540 The reason is that the frame_id of a breakpoint has to be the 8541 ID of a real frame, ignoring any inline frames. 8542 8543 With this fixed, it's working correctly: 8544 ``` 8545 (gdb) py fb=gdb.FinishBreakpoint() 8546 Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47. 8547 (gdb) c 8548 Continuing. 8549 8550 Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47 8551 (gdb) py print(fb.return_value) 8552 -8 8553 ``` 8554 8555 Approved-By: Tom Tromey <tom@tromey.com> 8556 85572023-12-12 Hannes Domani <ssbssa@yahoo.de> 8558 8559 Support dynamically computed convenience variables in get_internalvar_integer 8560 When using $_thread in info threads to showonly the current thread, 8561 you get this error: 8562 ``` 8563 (gdb) info thread $_thread 8564 Convenience variable must have integer value. 8565 Args must be numbers or '$' variables. 8566 ``` 8567 8568 It's because $_thread is a dynamically computed convenience 8569 variable, which isn't supported yet by get_internalvar_integer. 8570 8571 Now the output looks like this: 8572 ``` 8573 (gdb) info threads $_thread 8574 Id Target Id Frame 8575 * 1 Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21 8576 ``` 8577 8578 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600 8579 Approved-By: Tom Tromey <tom@tromey.com> 8580 85812023-12-12 Georg-Johann Lay <avr@gjlay.de> 8582 8583 Support rodata in flash for more AVR devices 8584 PR 31124 8585 * Makefile.am (ALL_EMULATION_SOURCES): Add eavrxmega2_flmap.c and eavrxmega4_flmap.c. 8586 * Makefile.in: Regenerate. 8587 * configure.tgt: Add eavrxmega2_flmap and eavrxmega4_flmap to avr's targ_extra_emuls list. 8588 * emulparams/avrxmega2.sh (MAYBE_FLMAP): Define. 8589 * emulparams/avrxmega2_flmap.sh: New file. 8590 * emulparams/avrxmega4.sh (MAYBE_FLMAP): Define. 8591 * emulparams/avrxmega4_flmap.sh: New file. 8592 * scripttempl/avr.sc: Add support for HAVE_FLMAP. 8593 85942023-12-12 Nick Clifton <nickc@redhat.com> 8595 8596 Fix whitespace snafu in tc-riscv.c 8597 85982023-12-12 Rui Ueyama <rui314@gmail.com> 8599 8600 RISC-V: Emit R_RISCV_RELAX for the la/lga pseudo instruction 8601 Some psABIs define a relaxation to turn a GOT load into a PC-relative 8602 address materialization. For example, the AArch64's psABI allows 8603 adrp+ldr to be rewritten to nop+adr to eliminate the memory load. 8604 This patch is part of the effort to make such optimization possible 8605 for RISC-V. 8606 8607 For RISC-V, we use the la assembly pseudo instruction to load a symbol 8608 address from the GOT. The pseudo instruction is expanded to auipc+ld. 8609 If the address loaded by the instruction pair is actually a PC-relative 8610 link-time constant, we want the linker to rewrite the instruction pair 8611 with auipc+addi. 8612 8613 We can't rewrite all existing auipc+ld pairs with auipc+addi in the 8614 linker because there might be code that jumps to the middle of the 8615 instruction pair. That should be extremely rare, if ever exists, but 8616 you can at least in theory write a program in assembly that jumps to 8617 the ld instruction of the instruction pair. We need a marker to 8618 identify that an auipc+ld can be safely relaxed (i.e. they are emitted 8619 for la). 8620 8621 This patch is to annotate R_RISCV_GOT_HI20 with R_RISCV_RELAX only 8622 when the relocation is emitted for the la pseudo instruction. The 8623 linker will use it as a signal that the instruction pair can be safely 8624 relaxed. 8625 8626 Proposal to the RISC-V psABI: 8627 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/397 8628 8629 gas/ 8630 * config/tc-riscv.c (source_macro): New static int variable. 8631 The identifier of the assembler macro we are expanding, if any. 8632 (append_insn): Updated source_macro to tc_fix_data, to record 8633 which macro expands, if any. 8634 (macro): Record which macro expands into source_macro. Reset 8635 source_macro to -1 at the end. 8636 (md_apply_fix): Apply R_RISCV_RELAX if pcrel_got_hi is expanded 8637 from macro LA/LGA. 8638 * config/tc-riscv.h (struct riscv_fix, TC_FIX_TYPE, TC_INIT_FIX_DATA): 8639 Defined to record source_macro into fixups for riscv target. 8640 * testsuite/gas/riscv/la-variants.d: Updated. 8641 86422023-12-12 Lifang Xia <lifang_xia@linux.alibaba.com> 8643 8644 RISC-V: Resolve PCREL_HI20/LO12_I/S fixups with local symbols while `-mno-relax' 8645 In the scenario of generating .ko files, the kernel does not relax the .ko 8646 files. However, due to the large amount of relax and local relocation 8647 information, this increases the size of the .ko files. In this patch, it 8648 will finish the fixup of the local relocations while with `-mno-relax' option. 8649 This can reduce the size of the relocation table. 8650 8651 The implemntation is based on the code from bfd/elfnn-riscv.c. We probably 8652 can move the code to bfd/elfxx-riscv.c, so that can reduce duplicate code, 8653 just like what we did for the architecture parser. 8654 8655 Besides, maybe not only pcrel_hi/lo12 relocation with local symbols can be 8656 resolved at assembler time. Other pc-relative relocation, like branch, 8657 may also be able to perform related optimizations. 8658 8659 Passed the gcc/binutils regressions of riscv-gnu-toolchain. 8660 8661 gas/ 8662 * config/tc-riscv.c (riscv_pcrel_hi_reloc): New structure. Record all 8663 PC-relative high-part relocation that we have encountered to help us 8664 resolve the corresponding low-part relocation later. 8665 (riscv_pcrel_hi_fixup_hash): The hash table to record pcrel_hi fixups. 8666 (riscv_pcrel_fixup_hash): New function. Likewise. 8667 (riscv_pcrel_fixup_eq): Likewise. 8668 (riscv_record_pcrel_fixup): Likewise. 8669 (md_begin): Init pcrel_hi hash table. 8670 (md_apply_fix): For PCREL_HI20 relocation, do fixup and record 8671 the pcrel_hi relocs, mark as done while with `-mno-relax'. For 8672 PCREL_LO12_I/S relocation, do fixup and mark as done while with 8673 `-mno-relax'. 8674 (riscv_md_end): New function. Free pcrel_hi hash table. 8675 * config/tc-riscv.h (md_end): Define md_end with riscv_md_end. 8676 gas/ 8677 * testsuite/gas/riscv/fixup-local*: New tests. 8678 86792023-12-12 GDB Administrator <gdbadmin@sourceware.org> 8680 8681 Automatic date update in version.in 8682 86832023-12-11 Tom Tromey <tromey@adacore.com> 8684 8685 Implement DAP cancellation 8686 This implements DAP cancellation. A new object is introduced that 8687 handles the details of cancellation. While cancellation is inherently 8688 racy, this code attempts to make it so that gdb doesn't inadvertently 8689 cancel the wrong request. 8690 8691 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472 8692 Approved-By: Eli Zaretskii <eliz@gnu.org> 8693 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8694 86952023-12-11 Tom Tromey <tromey@adacore.com> 8696 8697 Catch KeyboardInterrupt in send_gdb_with_response 8698 Cancellation will generally be seen by the DAP code as a 8699 KeyboardInterrupt. However, this derives from BaseException and not 8700 Exception, so a small change is needed to send_gdb_with_response, to 8701 forward the exception to the DAP server thread. 8702 8703 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8704 87052023-12-11 Tom Tromey <tromey@adacore.com> 8706 8707 Rename a couple of DAP procs in the testsuite 8708 This renames a couple of DAP procs in the testsuite, to clarify that 8709 they are now exported. The cancellation test will need these. 8710 8711 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8712 87132023-12-11 Tom Tromey <tromey@adacore.com> 8714 8715 Introduce gdb.interrupt 8716 DAP cancellation needs a way to interrupt whatever is happening on 8717 gdb's main thread -- whether that is the inferior, a gdb CLI command, 8718 or Python code. 8719 8720 This patch adds a new gdb.interrupt() function for this purpose. It 8721 simply sets the quit flag and lets gdb do the rest. 8722 8723 No tests in this patch -- instead this is tested via the DAP 8724 cancellation tests. 8725 8726 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 8727 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8728 87292023-12-11 Tom Tromey <tromey@adacore.com> 8730 8731 Move DAP JSON reader to its own thread 8732 This changes the DAP server to move the JSON reader to a new thread. 8733 This is key to implementing request cancellation, as now requests can 8734 be read while an earlier one is being serviced. 8735 8736 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8737 87382023-12-11 Tom Tromey <tromey@adacore.com> 8739 8740 Clean up handling of DAP not-stopped response 8741 This patch introduces a new NotStoppedException type and changes the 8742 DAP implementation of "not stopped" to use it. I was already touching 8743 some code in this area and I thought this looked a little cleaner. 8744 This also has the advantage that we can now choose not to log the 8745 exception -- previously I was sometimes a bit alarmed when seeing this 8746 in the logs, even though it is harmless. 8747 8748 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> 8749 87502023-12-11 Tom Tromey <tromey@adacore.com> 8751 8752 Simplify DAP stop-reason code 8753 Now that gdb adds stop-reason details to stop events, we can simplify 8754 the DAP code to emit correct stop reasons in its own events. For the 8755 most part a simple renaming of gdb reasons is sufficient; however, 8756 "pause" must still be handled specially. 8757 87582023-12-11 Tom Tromey <tromey@adacore.com> 8759 8760 Emit stop reason details in Python stop events 8761 This changes Python stop events to carry a "details" dictionary, that 8762 holds any relevant information about the stop. The details are 8763 constructed using more or less the same procedure as is done for MI. 8764 8765 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587 8766 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 8767 87682023-12-11 Tom Tromey <tromey@adacore.com> 8769 8770 Move py_ui_out to a new header 8771 This moves the declaration of py_ui_out to a new header, so that it 8772 can more readily be used by other code. 8773 87742023-12-11 Tom de Vries <tdevries@suse.de> 8775 8776 [gdb/testsuite] Fix $eol regexp usage in some test-cases 8777 Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced: 8778 ... 8779 set eol "\[\r\n\]+" 8780 ... 8781 with the more strict: 8782 ... 8783 set eol "\r\n" 8784 ... 8785 in a few test-cases, but didn't update all uses of eol accordingly. 8786 8787 Fix this in three gdb.ada test-cases. 8788 8789 Tested on x86_64-linux. 8790 8791 Approved-By: Andrew Burgess <aburgess@redhat.com> 8792 87932023-12-11 Tom Tromey <tom@tromey.com> 8794 8795 Use TARGET_SYSROOT_PREFIX in more places 8796 I found some spots using "target:"; I think it's better to use the 8797 define everywhere, so this changes these to use TARGET_SYSROOT_PREFIX. 8798 In some spots, is_target_filename is used rather than an explicit 8799 check. 8800 8801 Approved-By: Andrew Burgess <aburgess@redhat.com> 8802 88032023-12-11 Tom Tromey <tromey@adacore.com> 8804 8805 Add DAP items to NEWS 8806 Now that DAP is in GDB 14, significant changes to it should be noted 8807 in NEWS. This patch adds a note for a fix that's already gone in. I 8808 started a new section in NEWS because more changes are coming. 8809 8810 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473 8811 Approved-By: Eli Zaretskii <eliz@gnu.org> 8812 88132023-12-11 Hannes Domani <ssbssa@yahoo.de> 8814 8815 Fix dynamic_cast 8816 PR29011 notes that dynamic_cast does not work correctly if 8817 classes with virtual methods are involved, some of the results 8818 wrongly point into the vtable of the derived class: 8819 ``` 8820 (gdb) p vlr 8821 $1 = (VirtualLeftRight *) 0x162240 8822 (gdb) p vl 8823 $2 = (VirtualLeft *) 0x162240 8824 (gdb) p vr 8825 $3 = (VirtualRight *) 0x162250 8826 (gdb) p dynamic_cast<VirtualLeftRight*>(vlr) 8827 $4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16> 8828 (gdb) p dynamic_cast<VirtualLeftRight*>(vl) 8829 $5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16> 8830 (gdb) p dynamic_cast<VirtualLeftRight*>(vr) 8831 $6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16> 8832 (gdb) p dynamic_cast<VirtualLeft*>(vlr) 8833 $7 = (VirtualLeft *) 0x162240 8834 (gdb) p dynamic_cast<VirtualLeft*>(vl) 8835 $8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16> 8836 (gdb) p dynamic_cast<VirtualLeft*>(vr) 8837 $9 = (VirtualLeft *) 0x162240 8838 (gdb) p dynamic_cast<VirtualRight*>(vlr) 8839 $10 = (VirtualRight *) 0x162250 8840 (gdb) p dynamic_cast<VirtualRight*>(vl) 8841 $11 = (VirtualRight *) 0x162250 8842 (gdb) p dynamic_cast<VirtualRight*>(vr) 8843 $12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16> 8844 ``` 8845 8846 For the cases where the dynamic_cast type is the same as the 8847 original type, it used the ARG value for the result, which in 8848 case of pointer types was already the dereferenced value. 8849 8850 And the TEM value at the value address was created with the 8851 pointer/reference type, not the actual class type. 8852 8853 With these fixed, the dynamic_cast results make more sense: 8854 ``` 8855 (gdb) p vlr 8856 $1 = (VirtualLeftRight *) 0x692240 8857 (gdb) p vl 8858 $2 = (VirtualLeft *) 0x692240 8859 (gdb) p vr 8860 $3 = (VirtualRight *) 0x692250 8861 (gdb) p dynamic_cast<VirtualLeftRight*>(vlr) 8862 $4 = (VirtualLeftRight *) 0x692240 8863 (gdb) p dynamic_cast<VirtualLeftRight*>(vl) 8864 $5 = (VirtualLeftRight *) 0x692240 8865 (gdb) p dynamic_cast<VirtualLeftRight*>(vr) 8866 $6 = (VirtualLeftRight *) 0x692240 8867 (gdb) p dynamic_cast<VirtualLeft*>(vlr) 8868 $7 = (VirtualLeft *) 0x692240 8869 (gdb) p dynamic_cast<VirtualLeft*>(vl) 8870 $8 = (VirtualLeft *) 0x692240 8871 (gdb) p dynamic_cast<VirtualLeft*>(vr) 8872 $9 = (VirtualLeft *) 0x692240 8873 (gdb) p dynamic_cast<VirtualRight*>(vlr) 8874 $10 = (VirtualRight *) 0x692250 8875 (gdb) p dynamic_cast<VirtualRight*>(vl) 8876 $11 = (VirtualRight *) 0x692250 8877 (gdb) p dynamic_cast<VirtualRight*>(vr) 8878 $12 = (VirtualRight *) 0x692250 8879 ``` 8880 8881 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011 8882 Approved-By: Tom Tromey <tom@tromey.com> 8883 88842023-12-11 mengqinggang <mengqinggang@loongson.cn> 8885 8886 LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1"> 8887 Support symbol names enclosed in double quotation marks. 8888 88892023-12-11 Konstantin Isakov <ikm@zbackup.org> 8890 8891 bfd_find_nearest_line leaks dwarf_rnglists_buffer 8892 * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free dwarf_rnglists_buffer. 8893 88942023-12-11 Alan Modra <amodra@gmail.com> 8895 8896 regen bfd POTFILES 8897 88982023-12-11 Nelson Chu <nelson@rivosinc.com> 8899 8900 RISC-V/gas: Clarify the definition of `relaxable' in md_apply_fix 8901 The `relaxable' in md_apply_fix means if the relocation can be relaxed or not 8902 in link-time generally. We can use `.option relax/norelax' to enable/disable 8903 relaxations for some specific areas, so the value of `riscv_opts.relax' 8904 will be changed dynamically. The `fixP->fx_tcbit' records the correct value 8905 of `riscv_opts.relax' for every relocation. Therefore, set `relaxable' to 8906 `riscv_opts.relax' will cause unexpected behavior for the following case, 8907 8908 .option norelax 8909 lla a1, foo1 8910 .option relax 8911 lla a2, foo2 8912 .option norelax 8913 lla a3, foo3 8914 8915 For the current assembler, the final value of `riscv_opts.relax' is false, so 8916 the second `lla a2, foo2' won't have R_RISCV_RELAX relocation, but should have. 8917 8918 gas/ 8919 * config/tc-riscv.c (md_apply_fix): Set the value of `relaxable' to 8920 `riscv_opts.relax' is wrong. It should be `true' generally. 8921 89222023-12-11 Alan Modra <amodra@gmail.com> 8923 8924 R_MICROMIPS_GPREL7_S2 8925 This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00 8926 match/mask encoding in `micromips_opcodes'. It is correctly specified 8927 to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c 8928 and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in 8929 code like _bfd_mips_elf32_gprel16_reloc. 8930 8931 Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44 8932 is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33 8933 when little-endian. Big-endian behaviour is unchanged after this 8934 patch and little-endian correctly applies the reloc to byte 0x11. 8935 8936 The patch also corrects REL addend extraction from section contents, 8937 and overflow checking. gold had all of the bfd problems with this 8938 reloc and additionally did not apply the rightshift by two. 8939 8940 bfd/ 8941 * elfxx-mips.c (micromips_reloc_shuffle_p): Return false for 8942 R_MICROMIPS_GPREL7_S2. 8943 (mips_elf_calculate_relocation): Correct sign extension and 8944 overflow calculation for R_MICROMIPS_GPREL7_S2. 8945 (_bfd_mips_elf_relocate_section): Update small-data overflow 8946 message. 8947 gold/ 8948 * mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc): 8949 Return false for R_MICROMIPS_GPREL7_S2. 8950 (Mips_relocate_functions::mips_reloc_unshuffle): Update comment. 8951 (Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2 8952 handling. 8953 (Mips_relocate_functions::relgprel7): New function. 8954 (Target_mips::Relocate::relocate): Adjust to suit. 8955 ld/ 8956 * testsuite/ld-mips-elf/reloc-4.d: Adjust expected error. 8957 * testsuite/ld-mips-elf/reloc-5.d: Likewise. 8958 89592023-12-11 GDB Administrator <gdbadmin@sourceware.org> 8960 8961 Automatic date update in version.in 8962 89632023-12-10 Tom Tromey <tom@tromey.com> 8964 8965 Fix "not not" in Python documentation 8966 I noticed a "not not" in the Python documentation where just "not" was 8967 meant. This patch fixes the error. 8968 89692023-12-10 Tom Tromey <tom@tromey.com> 8970 8971 Add some new DW_IDX_* constants 8972 I've reimplemented the .debug_names code in GDB -- it was quite far 8973 from being correct, and the new implementation is much closer to what 8974 is specified by DWARF. 8975 8976 However, the new writer in GDB needs to emit some symbol properties, 8977 so that the reader can be fully functional. This patch adds a few new 8978 DW_IDX_* constants, and tries to document the existing extensions as 8979 well. (My patch series add more documentation of these to the GDB 8980 manual as well.) 8981 8982 2023-12-10 Tom Tromey <tom@tromey.com> 8983 8984 * dwarf2.def (DW_IDX_GNU_internal, DW_IDX_GNU_external): Comment. 8985 (DW_IDX_GNU_main, DW_IDX_GNU_language, DW_IDX_GNU_linkage_name): 8986 New constants. 8987 89882023-12-10 Jeff Law <jeffreyalaw@gmail.com> 8989 8990 Improve performance of the H8 simulator 8991 Running the H8 port through the GCC testsuite currently takes 4h 30m on my 8992 fastest server -- that's roughly 1.5hrs per multilib tested and many tests are 8993 disabled for various reasons. 8994 8995 To put that 1.5hr/multilib in perspective, that's roughly 3X the time for other 8996 embedded targets. Clearly something isn't working as well as it should. 8997 8998 A bit of digging with perf shows that we're spending a crazy amount of time 8999 decoding instructions in the H8 simulator. It's not hard to see why -- 9000 basically we take a blob of instruction data, then try to match it to every 9001 instruction in the H8 opcode table starting at the beginning. That table has 9002 ~8000 entries (each different addressing mode is considered a different 9003 instruction in the table). 9004 9005 Naturally my first thought was to sort the table and use a binary search to 9006 find the right entry. That's made excessively complex due to the encoding on 9007 the H8. Just getting the sort right would be much more complex than I'd 9008 consider advisable. 9009 9010 Another thought was to build a mapping to the right entry for all the 9011 instructions that can be disambiguated based on the first nibble (4 bits) of 9012 instruction data and a mapping for those which can be disambiguated based on 9013 the first byte of instruction data. 9014 9015 That seemed feasible until I realized that the H8/SX did some truly horrid 9016 things with encoding branches in the 0x4XYY opcode space. It uses an "always 9017 zero" bit in the offset to encode new semantic information. So we can't select 9018 on just 0x4X. Ugh! 9019 9020 We could always to a custom decoder. I've done several through the years, they 9021 can be very fast. But no way I can justify the time to do that. 9022 9023 So what I settled on was to first sort the opcode table by the first nibble, 9024 then find the index of the first instruction for each nibble. Decoding uses 9025 that index to start its search. This cuts the overall build/test by more than 9026 half. 9027 9028 Next I adjusted the sort so that instructions that are not available on the 9029 current sub architecture are put at the end of the table. This shaves another 9030 ~15% off the total cycle time. 9031 9032 The net of the two changes is on my fastest server we've gone from 4:30 to 1:40 9033 running the GCC testsuite. Same test results before/after, of course. It's 9034 still not fast, but it's a hell of a lot better. 9035 90362023-12-10 GDB Administrator <gdbadmin@sourceware.org> 9037 9038 Automatic date update in version.in 9039 90402023-12-09 Tom de Vries <tdevries@suse.de> 9041 9042 [gdb/tui] Handle shared border in fixed-sized layout 9043 In tui_layout_split::apply I noticed that for variable-size layouts we take 9044 share_box into account by decreasing used_size: 9045 ... 9046 used_size += info[i].size; 9047 if (info[i].share_box) 9048 --used_size; 9049 ... 9050 but not for fixed-size layouts: 9051 ... 9052 if (info[i].min_size == info[i].max_size) 9053 available_size -= info[i].min_size; 9054 ... 9055 9056 Fix this by increasing available_size for fixed-size layouts with shared box. 9057 9058 Tested on x86_64-linux. 9059 9060 Approved-By: Tom Tromey <tom@tromey.com> 9061 90622023-12-09 GDB Administrator <gdbadmin@sourceware.org> 9063 9064 Automatic date update in version.in 9065 90662023-12-08 Tom de Vries <tdevries@suse.de> 9067 9068 [gdb/tui] Show focus window in status line 9069 The focused window is highlighted by using active-border-kind instead of 9070 border-kind. 9071 9072 But if the focused window is the cmd window (which is an unboxed window), then 9073 no highlighting is done, and it's not obvious from looking at the screen which 9074 window has the focus. Instead, you have to notice the absence of highlighting 9075 on boxed windows, and then infer that the focus is on the unboxed window. 9076 9077 That approach stops working if there are multiple unboxed windows. 9078 9079 Likewise if highlighting is switched off by setting active-border-kind to the 9080 same value as border-kind. 9081 9082 Make it more explicit which window has the focus by mentioning it in the status 9083 window, like so: 9084 ... 9085 native process 8282 (src) In: main L7 PC: 0x400525 9086 ... 9087 9088 Tested on x86_64-linux and ppc64le-linux. 9089 9090 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 9091 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 9092 Approved-By: Tom Tromey <tom@tromey.com> 9093 90942023-12-08 Hannes Domani <ssbssa@yahoo.de> 9095 9096 Fix printing of global variable stubs if no inferior is running 9097 Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying 9098 to print a global variable stub without a running inferior, because of 9099 a missing nullptr-check (the block_scope function took care of that 9100 check before it was converted to a method). 9101 9102 With this check it works again: 9103 ``` 9104 (gdb) print s 9105 $1 = <incomplete type> 9106 ``` 9107 9108 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128 9109 Approved-By: Tom Tromey <tom@tromey.com> 9110 91112023-12-08 Andrew Burgess <aburgess@redhat.com> 9112 9113 gdb/testsuite: tighten up some end-of-line patterns 9114 Following on from the previous commit, I searched the testsuite for 9115 places where we did: 9116 9117 set eol "<some pattern>" 9118 9119 in most cases the <some pattern> could be replaced with "\r\n" though 9120 in the stabs test I've switched to using the multi_line proc as that 9121 seemed like a better choice. 9122 9123 In gdb.ada/info_types.exp I did need to add an extra use of $eol as 9124 the previous pattern would match multiple newlines, and in this one 9125 place we were actually expecting to match multiple newlines. The 9126 tighter pattern only matches a single newline, so we now need to be 9127 explicit when multiple newlines are expected -- I think this is a good 9128 thing. 9129 9130 All the tests are still passing for me after these changes. 9131 9132 Approved-By: Tom Tromey <tom@tromey.com> 9133 91342023-12-08 Andrew Burgess <aburgess@redhat.com> 9135 9136 gdb/testsuite: fix gdb.ada/complete.exp timeout in READ1 mode 9137 While reviewing another patch I spotted a timeout in 9138 gdb.ada/complete.exp when testing in READ1 mode, e.g.: 9139 9140 $ make check-read1 TESTS="gdb.ada/complete.exp" 9141 ... 9142 FAIL: gdb.ada/complete.exp: complete break ada (timeout) 9143 ... 9144 9145 The problem is an attempt to match the entire output from GDB within a 9146 single gdb_test_multiple pattern, for a completion command that 9147 returns a large number of completions. 9148 9149 This commit changes the gdb_test_multiple to process the output line 9150 by line. I don't use the gdb_test_multiple -lbl option, as I've 9151 always found that option backward -- it checks for the \r\n at the 9152 start of each line rather than the end, I think it's much clearer to 9153 use '^' at the start of each pattern, and '\r\n' at the end, so that's 9154 what I've done here. 9155 9156 .... Or I would, if this test didn't already define $eol as the end of 9157 line regexp ... except that $eol was set to '[\r\n]*', which isn't 9158 that helpful, so I've updated $eol to be just '\r\n' the actual end of 9159 line regexp. 9160 9161 And now, the test passes without a timeout when using READ1. 9162 9163 There should be no change in what is tested after this commit. 9164 9165 Approved-By: Tom Tromey <tom@tromey.com> 9166 91672023-12-08 Andrew Burgess <aburgess@redhat.com> 9168 9169 gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use 9170 Building on the last commit, which added a general --debug=COMPONENT 9171 option to the gdbserver command line, this commit updates the monitor 9172 command to allow for general: 9173 9174 (gdb) monitor set debug COMPONENT off|on 9175 9176 style commands. Just like with the previous commit, the COMPONENT can 9177 be any one of all, threads, remote, event-loop, and correspond to the 9178 same set of global debug flags. 9179 9180 While on the command line it is possible to do: 9181 9182 --debug=remote,event-loop,threads 9183 9184 the components have to be entered one at a time with the monitor 9185 command. I guess there's no reason why we couldn't allow component 9186 grouping within the monitor command, but (to me) what I have here 9187 seemed more in the spirit of GDB's existing 'set debug ...' commands. 9188 If people want it then we can always add component grouping later. 9189 9190 Notice in the above that I use 'off' and 'on' instead of '0' and '1', 9191 which is what the 'monitor set debug' command used to use. The 0/1 9192 can still be used, but I now advertise off/on in all the docs and help 9193 text, again, this feels more inline with GDB's existing boolean 9194 settings. 9195 9196 I have removed the two existing monitor commands: 9197 9198 monitor set remote-debug 0|1 9199 monitor set event-loop-debug 0|1 9200 9201 These are replaced by: 9202 9203 monitor set debug remote off|on 9204 monitor set debug event-loop off|on 9205 9206 respectively. 9207 9208 Approved-By: Tom Tromey <tom@tromey.com> 9209 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 9210 92112023-12-08 Andrew Burgess <aburgess@redhat.com> 9212 9213 gdbserver: allow the --debug command line option to take a value 9214 Currently, gdbserver has the following command line options related to 9215 debugging output: 9216 9217 --debug 9218 --remote-debug 9219 --event-loop-debug 9220 9221 This doesn't scale well. If I want an extra debug component I need to 9222 add another command line flag. 9223 9224 This commit changes --debug to take a list of components. 9225 9226 The currently supported components are: all, threads, remote, and 9227 event-loop. The 'threads' component represents the debug we currently 9228 get from the --debug option. And if --debug is used without a 9229 component list then the threads component is assumed as the default. 9230 9231 Currently the threads component actually includes a lot of output that 9232 is not really threads related. In the future I'd like to split this 9233 up into some new, separate components. But that is not part of this 9234 commit, or even this series. 9235 9236 The special component 'all' does what you'd expect: enables debug 9237 output from all supported components. 9238 9239 The component list is parsed left to write, and you can prefix a 9240 component with '-' to disable that component, so I can write: 9241 9242 target> gdbserver --debug=all,-event-loop 9243 9244 to get debug for all components except the event-loop component. 9245 9246 I've removed the existing --remote-debug and --event-loop-debug 9247 command line options, these are equivalent to --debug=remote and 9248 --debug=event-loop respectively, or --debug=remote,event-loop to 9249 enable both components. 9250 9251 In this commit I've only update the command line options, in the next 9252 commit I'll update the monitor commands to support a similar 9253 interface. 9254 9255 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 9256 Approved-By: Tom Tromey <tom@tromey.com> 9257 92582023-12-08 Andrew Burgess <aburgess@redhat.com> 9259 9260 gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables 9261 The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG 9262 flags, which can be passed to make in order to enable debugging within 9263 GDB or gdbserver respectively. 9264 9265 However, when I do: 9266 9267 make check-gdb GDB_DEBUG=infrun 9268 9269 I don't see the corresponding debug feature within GDB being enabled. 9270 Nor does: 9271 9272 make check-gdb GDBSERVER_DEBUG=debug \ 9273 RUNTESTFLAGS="--target_board=native-extended-gdbserver" 9274 9275 Appear to enable gdbserver debugging. 9276 9277 I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being 9278 missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This 9279 variable already contains lots of testing related flags, like 9280 RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and 9281 GDBSERVER_DEBUG here too. 9282 9283 With this done, this debug feature is now working as expected. 9284 9285 Approved-By: Tom Tromey <tom@tromey.com> 9286 92872023-12-08 Hannes Domani <ssbssa@yahoo.de> 9288 9289 Use pretty printers for struct member stubs 9290 PR29079 shows that pretty printers can be used for an incomplete 9291 type (stub), but only when printing it directly, not if it's 9292 part of another struct: 9293 ``` 9294 (gdb) p s 9295 $1 = {pp m_i = 5} 9296 (gdb) p s2 9297 $2 = {m_s = <incomplete type>, m_l = 20} 9298 ``` 9299 9300 The reason is simply that in common_val_print the check for stubs 9301 is before any pretty printer is tried. 9302 It works if the pretty printer is tried before the stub check: 9303 ``` 9304 (gdb) p s 9305 $1 = {pp m_i = 5} 9306 (gdb) p s2 9307 $2 = {m_s = {pp m_i = 10}, m_l = 20} 9308 ``` 9309 9310 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079 9311 Approved-By: Tom Tromey <tom@tromey.com> 9312 93132023-12-08 Tom de Vries <tdevries@suse.de> 9314 9315 [gdb/tui] Fix displaying main after resizing 9316 A TUI src window is displaying either: 9317 - the source for the current frame, 9318 - the source for main, or 9319 - the string "[ No Source Available ]". 9320 9321 Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines") 9322 we're able to resize the TUI to 1 line without crashing. 9323 9324 I noticed that if TUI is displaying main, and we resize to 1 line (destroying 9325 the src window) and then back to a larger terminal (reconstructing the src 9326 window), the TUI displays "[ No Source Available ]" instead of main. 9327 9328 Fix this by moving the responsibility for showing main from tui_enable to 9329 tui_source_window_base::rerender. 9330 9331 Tested on x86_64-linux. 9332 9333 Approved-By: Tom Tromey <tom@tromey.com> 9334 93352023-12-08 Tom Tromey <tom@tromey.com> 9336 9337 Allow cast of 128-bit integer to pointer 9338 PR rust/31082 points out that casting a 128-bit integer to a pointer 9339 will fail. This happens because a case in value_cast was not 9340 converted to use GMP. 9341 9342 This patch fixes the problem. I am not really sure that testing 9343 against the negative value here makes sense, but I opted to just 9344 preserve the existing behavior rather than change it. 9345 9346 Regression tested on x86-64 Fedora 38. 9347 9348 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082 9349 93502023-12-08 Tom Tromey <tom@tromey.com> 9351 9352 Fix dynamic type resolution for LOC_CONST and LOC_CONST_BYTES symbols 9353 PR rust/31005 points out that dynamic type resolution of a LOC_CONST 9354 or LOC_CONST_BYTES symbol will fail, leading to output like: 9355 9356 from_index=<error reading variable: Cannot access memory at address 0x0> 9357 9358 This patch fixes the problem by using the constant value or bytes when 9359 performing type resolution. 9360 9361 Thanks to tpzker@thepuzzlemaker.info for a first version of this 9362 patch. 9363 9364 I also tested this on a big-endian PPC system (cfarm203). 9365 9366 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005 9367 93682023-12-08 Guinevere Larsen <blarsen@redhat.com> 9369 9370 gdb: Guarantee that an SAL's end is right before the next statement 9371 When examining a failure that happens when testing 9372 gdb.python/py-symtab.c with clang, I noticed that it was going wrong 9373 because the test assumed that whenever we get an SAL, its end would 9374 always be right before statement in the line table. This is true for GCC 9375 compiled binaries, since gcc only adds statements to the line table, but 9376 not true for clang compiled binaries. 9377 9378 This is the second time I run into a problem where GDB doesn't handle 9379 non-statement line table entries correctly. The other was eventually 9380 committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until 9381 behavior with trailing !is_stmt lines", but that commit only changes the 9382 behavior for the 'until' command. In this patch I propose a more general 9383 solution, making it so every time we generate the SAL for a given pc, we 9384 set the end of the SAL to before the next statement or the first 9385 instruciton in the next line, instead of naively assuming that to be the 9386 case. 9387 9388 With this new change, the edge case is removed from the processing of 9389 the 'until' command without regressing the accompanying test case, and 9390 no other regressions were observed in the testsuite. 9391 9392 Approved-By: Tom Tromey <tom@tromey.com> 9393 93942023-12-08 Mike Frysinger <vapier@gentoo.org> 9395 9396 sim: aarch64: fix -Wunused-but-set-variable warnings 9397 9398 sim: common: fix -Wunused-but-set-variable warnings 9399 9400 sim: ppc: fix -Wunused-but-set-variable warnings 9401 9402 sim: v850: fix -Wunused-but-set-variable warnings 9403 9404 sim: sh: fix -Wunused-but-set-variable warnings 9405 9406 sim: msp430: fix -Wunused-but-set-variable warnings 9407 9408 sim: mips: fix -Wunused-but-set-variable warnings 9409 9410 sim: mcore: fix -Wunused-but-set-variable warnings 9411 9412 sim: m68hc11: fix -Wunused-but-set-variable warnings 9413 9414 sim: h8300: fix -Wunused-but-set-variable warnings 9415 9416 sim: ft32: fix -Wunused-but-set-variable warnings 9417 9418 sim: frv: fix -Wunused-but-set-variable warnings 9419 9420 sim: erc32: fix -Wunused-but-set-variable warnings 9421 9422 sim: d10v: fix -Wunused-but-set-variable warnings 9423 9424 sim: cris: fix -Wunused-but-set-variable warnings 9425 We suppress the warning in the generated switch file because the cris 9426 cpu file has a hack to workaround a cgen bug, but that generates a set 9427 but unused variable which makes the compiler upset. 9428 9429 sim: bfin: fix -Wunused-but-set-variable warnings 9430 9431 sim: bfin: gui: fix -Wunused-but-set-variable warnings 9432 Rework the code to use static inline functions when it's disabled 9433 rather than macros so the compiler knows the various function args 9434 are always used. The ifdef macros are a bit ugly, but get the job 9435 done without duplicating the function prototypes. 9436 9437 sim: arm: fix -Wunused-but-set-variable warnings 9438 9439 sim: m32r: fix syslog call 9440 The function returns void, not int. We only pass one argument to 9441 syslog (the format), so use %s as the static format instead since 9442 the emulation layer doesn't handle passing additional arguments. 9443 94442023-12-08 Mike Frysinger <vapier@gentoo.org> 9445 9446 sim: m32r: include more glibc headers for the funcs we use [PR sim/29752] 9447 Not exactly portable, but doesn't make the situation worse here, and 9448 fixes a lot of implicit function warnings. 9449 9450 Bug: https://sourceware.org/PR29752 9451 94522023-12-08 Mike Frysinger <vapier@gentoo.org> 9453 9454 sim: m32r: add more cgen prototypes for traps 9455 The traps file uses a bunch of functions directly without prototypes, 9456 and we can't safely include the relevant cpu*.h files for them. 9457 94582023-12-08 GDB Administrator <gdbadmin@sourceware.org> 9459 9460 Automatic date update in version.in 9461 94622023-12-07 Mike Frysinger <vapier@gentoo.org> 9463 9464 sim: m32r: add more cgen prototypes to enable -Werror in most files 9465 94662023-12-07 Mike Frysinger <vapier@gentoo.org> 9467 9468 sim: warnings: disable -Wenum-conversion fow now [PR sim/29752] 9469 The cgen code mixes virtual insn enums with insn enums, and there isn't 9470 an obvious (to me) way to unravel this atm, so disable the warning. 9471 9472 sim/lm32/decode.c:45:5: error: 9473 implicit conversion from enumeration type 'CGEN_INSN_VIRTUAL_TYPE' 9474 to different enumeration type 'CGEN_INSN_TYPE' (aka 'enum cgen_insn_type') 9475 [-Werror,-Wenum-conversion] 9476 45 | { VIRTUAL_INSN_X_INVALID, LM32BF_INSN_X_INVALID, LM32BF_SFMT_EMPTY }, 9477 | ~ ^~~~~~~~~~~~~~~~~~~~~~ 9478 9479 Bug: https://sourceware.org/PR29752 9480 94812023-12-07 Cupertino Miranda <cupertino.miranda@oracle.com> 9482 9483 gdb/record: Support for rdtscp in i386_process_record. 9484 This patch adds support for process recording of the instruction rdtscp in 9485 x86 architecture. 9486 Debugging applications with "record full" fail to record with the error 9487 message "Process record does not support instruction 0xf01f9". 9488 9489 Approved-by: Guinevere Larsen <blarsen@redhat.com> 9490 94912023-12-07 Mike Frysinger <vapier@gentoo.org> 9492 9493 sim: support dlopen in -lc 9494 Stop assuming that dlopen is only available via -ldl. Newer versions 9495 of glibc have merged it into -lc which broke this configure test. 9496 9497 sim: cris: move generated file to right place 9498 Not sure why this ended up in the topdir, but it belongs under cris/. 9499 9500 sim: warnings: add more flags 9501 Sync with the list of flags from gdbsupport, and add a few more of 9502 our own to catch recent issues. Comment out the C++-specific flags 9503 as we don't build with C++. 9504 95052023-12-07 Kevin Buettner <kevinb@redhat.com> 9506 9507 Add more 'step' tests to gdb.base/watchpoint.exp 9508 The test gdb.base/watchpoint.exp has a proc named 'test_stepping' 9509 which claims to "Test stepping and other mundane operations with 9510 watchpoints enabled". It sets a watchpoint on ival2, performs an 9511 inferior function call (which is not at all mundane), and uses 'next', 9512 'until', and, finally, does a 'step'. 9513 9514 However, that final 'step' command steps to (but not over/through) the 9515 line at which the assignment to ival2 takes place. At no time while 9516 performing these operations is a watchpoint hit. 9517 9518 This commit adds a test to see what happens when stepping over/through 9519 the assignment to ival2. The watchpoint on ival2 should be triggered 9520 during this step. I've added another 'step' to make sure that the 9521 correct statement is reached after performing the watchpoint-hitting 9522 step. 9523 9524 After running the 'test_stepping' proc, gdb.base/watchpoint.exp does 9525 a clean_restart before doing further tests, so nothing depends upon 9526 'test_stepping' to stop at the particular statement at which it had 9527 been stopping. 9528 9529 I've examined all tests which set watchpoints and step. I haven't 9530 been able to identify a(nother) test case which tests what happens 9531 when stepping over/through a statement which triggers a watchpoint. 9532 Therefore, adding these new 'step' tests is testing something which 9533 hasn't being tested elsewhere. 9534 9535 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 9536 95372023-12-07 Palmer Dabbelt <palmer@rivosinc.com> 9538 9539 RISC-V: Fix "withand" in LEB128 error messages 9540 This was split over multiple lines and ended up missing a space. 9541 9542 Reported-by: David Abdurachmanov <davidlt@rivosinc.com> 9543 95442023-12-07 GDB Administrator <gdbadmin@sourceware.org> 9545 9546 Automatic date update in version.in 9547 95482023-12-06 Hannes Domani <ssbssa@yahoo.de> 9549 9550 Fix DLL export forwarding 9551 I noticed it when I was trying to set a breakpoint at ExitProcess: 9552 ``` 9553 (gdb) b ExitProcess 9554 Breakpoint 1 at 0x14001fdd0 9555 (gdb) r 9556 Starting program: C:\qiewer\heob\heob64.exe 9557 Warning: 9558 Cannot insert breakpoint 1. 9559 Cannot access memory at address 0x3dbf4120 9560 Cannot insert breakpoint 1. 9561 Cannot access memory at address 0x77644120 9562 ``` 9563 9564 The problem doesn't exist in gdb 13.2, and the difference can easily be 9565 seen when printing ExitProcess. 9566 gdb 14.1: 9567 ``` 9568 (gdb) p ExitProcess 9569 $1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128> 9570 ``` 9571 gdb 13.2: 9572 ``` 9573 (gdb) p ExitProcess 9574 $1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess> 9575 ``` 9576 9577 The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a, 9578 where VMA was then calculated relative to FORWARD_DLL_NAME, while it was 9579 relative to DLL_NAME before. 9580 9581 Fixed by calculating VMA relative to DLL_NAME again. 9582 9583 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112 9584 Approved-By: Tom Tromey <tom@tromey.com> 9585 95862023-12-06 Tom Tromey <tromey@adacore.com> 9587 9588 Fix minor grammar error in gdb.texinfo 9589 This fixes a small grammar issue in gdb.texinfo -- "additional" was 9590 written where "additionally" is correct. 9591 9592 Remove quick_symbol_functions::expand_matching_symbols 9593 The only caller of quick_symbol_functions::expand_matching_symbols was 9594 removed, so now this method and all implementations of it can be 9595 removed. 9596 9597 Remove split_style::UNDERSCORE 9598 The recent changes to the way Ada names are matched means that 9599 split_style::UNDERSCORE is no longer used. This patch removes it. 9600 96012023-12-06 Tom Tromey <tromey@adacore.com> 9602 9603 Always use expand_symtabs_matching in ada-lang.c 9604 The previous patch fixed the immediate performance problem with Ada 9605 name matching, by having a subset of matches call 9606 expand_symtabs_matching rather than expand_matching_symbols. However, 9607 it seemed to me that expand_matching_symbols should not be needed at 9608 all. 9609 9610 To achieve this, this patch changes ada_lookup_name_info::split_name 9611 to use the decoded name, rather than the encoded name. In order to 9612 make this work correctly, a new decoded form is used: one that does 9613 not decode operators (this is already done) and also does not decode 9614 wide characters. The latter change is done so that changes to the Ada 9615 source charset don't affect the DWARF index. 9616 9617 With this in place, we can change ada-lang.c to always use 9618 expand_symtabs_matching rather than expand_matching_symbols. 9619 96202023-12-06 Tom Tromey <tromey@adacore.com> 9621 9622 Improve performance of Ada name searches 9623 A user reported that certain operations -- like printing a large 9624 structure -- could be slow. I tracked this down to 9625 ada-lang.c:map_matching_symbols taking an inordinate amount of time. 9626 Specifically, calls like the one to look for a parallel "__XVZ" 9627 variable, in ada_to_fixed_type_1, could result in gdb walking over all 9628 the entries in the cooked index over and over. 9629 9630 Looking into this reveals that 9631 cooked_index_functions::expand_matching_symbols is not written 9632 efficiently -- it ignores its "ordered_compare" parameter. While 9633 fixing this would be good, it turns out that this entire method isn't 9634 needed; so this series removes it. 9635 9636 However, the deletion is not done in this patch. This one, instead, 9637 fixes the immediate cause of the slowdown, by using 9638 objfile::expand_symtabs_matching when possible. This approach is 9639 faster because it is more selective about which index entries to 9640 examine. 9641 96422023-12-06 Tom Tromey <tom@tromey.com> 9643 9644 Start abbrevs at 1 in DWARF assembler 9645 I noticed that the DWARF assembler starts abbrevs at 2. 9646 I think 1 should be preferred. 9647 9648 Co-Authored-By: Tom de Vries <tdevries@suse.de> 9649 96502023-12-06 Hannes Domani <ssbssa@yahoo.de> 9651 9652 Fix hardware watchpoints in replay mode 9653 Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597 9654 caused a regression that meant hardware watchpoint stops would not 9655 trigger in reverse execution or replay mode. This was documented in 9656 PR breakpoints/21969. 9657 The problem is that record_check_stopped_by_breakpoint always overwrites 9658 record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT 9659 value which would be checked afterwards. 9660 9661 This commit fixes that by not overwriting the stop-reason in 9662 record_full_stop_reason if we're not stopped at a breakpoint. 9663 9664 And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually 9665 tested sw watchpoints again, since "set can-use-hw-watchpoints 1" 9666 doesn't convert enabled watchpoints to use hardware. 9667 This is fixed by disabling said watchpoint while enabling hw watchpoints. 9668 The same is not done for gdb.reverse/watch-precsave.exp, since it's not 9669 possible to use hw watchpoints in restored recordings anyways. 9670 9671 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969 9672 Approved-by: Guinevere Larsen <blarsen@redhat.com> 9673 96742023-12-06 Andrew Burgess <aburgess@redhat.com> 9675 9676 gdb: fix libstdc++ assert caused by invalid use of std::clamp 9677 After this commit: 9678 9679 commit 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2 9680 Date: Mon Dec 4 14:23:17 2023 +0000 9681 9682 gdb: Enable early init of thread pool size 9683 9684 I am now seeing this assert from libstdc++: 9685 9686 /usr/include/c++/9/bits/stl_algo.h:3715: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed. 9687 9688 This may only be visible because I compile with: 9689 9690 -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 9691 9692 but I haven't checked. The issue the assert is highlighting is real, 9693 and is caused by this block of code: 9694 9695 if (n_threads < 0) 9696 { 9697 const int hardware_threads = std::thread::hardware_concurrency (); 9698 /* Testing in #29959 indicates that parallel efficiency drops between 9699 n_threads=5 to 8. Therefore, clamp the default value to 8 to avoid an 9700 excessive number of threads in the pool on many-core systems. */ 9701 const int throttle = 8; 9702 n_threads = std::clamp (hardware_threads, hardware_threads, throttle); 9703 } 9704 9705 The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if 9706 we have more than 8 hardware threads available the LOW will be greater 9707 than the HIGH, which is triggering the assert I see above. 9708 9709 I believe std::clamp is the wrong tool to use here. Instead std::min 9710 would be a better choice; we want the smaller value of 9711 HARDWARE_THREADS or THROTTLE. If h/w threads is 2, then we want 2, 9712 but if h/w threads is 16 we want 8, this is what std::min gives us. 9713 9714 After this commit, I no longer see the assert. 9715 97162023-12-06 Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> 9717 9718 [gdb/symtab] Redo "Fix assert in set_length" 9719 This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due 9720 to a regression reported in PR29572, and implements a different fix for PR29453. 9721 9722 The fix is to not use the CU table in a .debug_names section to construct 9723 all_units, but instead use create_all_units, and then verify the CU 9724 table from .debug_names. This also fixes PR25969, so remove the KFAIL. 9725 9726 Approved-By: Tom Tromey <tom@tromey.com> 9727 9728 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572 9729 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969 9730 97312023-12-06 Mike Frysinger <vapier@gentoo.org> 9732 9733 sim: warnings: sync some build logic from gdbsupport 9734 This fixes testing of -Wno flags, and adds some more portable ones. 9735 97362023-12-06 Alan Modra <amodra@gmail.com> 9737 9738 PR31096, nm shows 32bit addresses as 64bit addresses 9739 Prior to commit 0e3c1eebb2 nm output depended on the host unsigned 9740 long when printing "negative" symbol values for 32-bit targets. 9741 Commit 0e3c1eebb22 made the output match that seen with a 64-bit host 9742 unsigned long. The fact that nm output changed depending on host is 9743 of course a bug, but it is reasonable to expect 32-bit target output 9744 is only 32 bits. So this patch makes 32-bit target output the same as 9745 it was on 32-bit hosts prior to 0e3c1eebb2. 9746 9747 PR 31096 9748 * nm.c (print_format_string): Make it a static buffer. 9749 (get_print_format): Merge into.. 9750 (set_print_format): ..this, renamed from set_print_width. When 9751 print_width is 32, set up print_format_string for an int32_t 9752 value. Don't malloc print_format_string. Adjust calls. 9753 (print_value): Correct printing of 32-bit values. 9754 97552023-12-06 GDB Administrator <gdbadmin@sourceware.org> 9756 9757 Automatic date update in version.in 9758 97592023-12-05 Jakub Jelinek <jakub@redhat.com> 9760 9761 libiberty: Fix build with GCC < 7 9762 Tobias reported on IRC that the linker fails to build with GCC 4.8.5. 9763 In configure I've tried to use everything actually used in the sha1.c 9764 x86 hw implementation, but unfortunately I forgot about implicit function 9765 declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define 9766 and __get_cpuid function defined inline, but it didn't define 9767 __get_cpuid_count, which compiled fine (and the configure test is 9768 intentionally compile time only) due to implicit function declaration, 9769 but then failed to link when linking the linker, because 9770 __get_cpuid_count wasn't defined anywhere. 9771 9772 The following patch fixes that by using what autoconf uses in AC_CHECK_DECL 9773 to make sure the functions are declared. 9774 9775 2023-12-05 Jakub Jelinek <jakub@redhat.com> 9776 9777 * configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and 9778 __get_cpuid_count are not implicitly declared. 9779 * configure: Regenerated. 9780 97812023-12-05 Hannes Domani <ssbssa@yahoo.de> 9782 9783 Fix breakpoints on symbols with multiple trampoline symbols 9784 On mingw targets it's possible that there are multiple trampoline 9785 symbols for __cxa_throw, in each module where a throw is done, but 9786 without a corresponding global symbol. 9787 Since commit 77f2120b200be6cabbf6f610942fc1173a8df6d3 they cancel each 9788 other out in search_minsyms_for_name, which makes it impossible to set 9789 a breakpoint there: 9790 9791 (gdb) b __cxa_throw 9792 Function "__cxa_throw" not defined. 9793 Make breakpoint pending on future shared library load? (y or [n]) y 9794 Breakpoint 2 (__cxa_throw) pending. 9795 (gdb) c 9796 Continuing. 9797 [Inferior 1 (process 10004) exited with code 03] 9798 9799 With catch throw it also doesn't work, and you don't even get an error 9800 message: 9801 9802 (gdb) catch throw 9803 Catchpoint 2 (throw) 9804 (gdb) c 9805 Continuing. 9806 [Inferior 1 (process 5532) exited with code 03] 9807 (gdb) 9808 9809 The fix is to simply ignore other trampoline symbols when looking for 9810 corresponding global symbols, and it's working as expected: 9811 9812 (gdb) b __cxa_throw 9813 Breakpoint 2 at 0x13f091590 (2 locations) 9814 (gdb) c 9815 Continuing. 9816 9817 Breakpoint 2.1, 0x000000013f091590 in __cxa_throw () 9818 (gdb) 9819 9820 And catch throw also works again: 9821 9822 (gdb) catch throw 9823 Catchpoint 2 (throw) 9824 (gdb) c 9825 Continuing. 9826 9827 Catchpoint 2.1 (exception thrown), 0x000000013f181590 in __cxa_throw () 9828 (gdb) 9829 9830 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29548 9831 Approved-By: Tom Tromey <tom@tromey.com> 9832 98332023-12-05 Richard Bunt <richard.bunt@linaro.org> 9834 9835 gdb/testsuite: Update worker thread show assertion 9836 Commit 33ae45434d0 updated the text reported by GDB when showing the 9837 number of worker threads. However, it neglected to update the assertions 9838 using this text, which caused index-file.exp to fail. This commit 9839 corrects this omission. 9840 9841 Tested index-file.exp is fixed on my local machine. 9842 9843 Approved-By: Tom Tromey <tom@tromey.com> 9844 98452023-12-05 Tom Tromey <tromey@adacore.com> 9846 9847 Remove some DAP helper functions 9848 Now that DAP requests are normally run on the gdb thread, some DAP 9849 helper functions are no longer needed. Removing these simplifies the 9850 code. 9851 98522023-12-05 Nick Clifton <nickc@redhat.com> 9853 9854 Fix: strip --strip-debug breaks relocations 9855 PR 31106 9856 * elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation. 9857 98582023-12-05 Tom Tromey <tom@tromey.com> 9859 9860 Fix off-by-one error in compute_delayed_physnames 9861 compute_delayed_physnames does this: 9862 9863 size_t len = strlen (physname); 9864 ... 9865 if (physname[len] == ')') /* shortcut */ 9866 break; 9867 9868 However, physname[len] will always be \0. 9869 9870 This patch changes it to the correct len-1. 9871 98722023-12-05 Mike Frysinger <vapier@gentoo.org> 9873 9874 sim: mips: fix sim_fpu usage 9875 Fix some of the sim_fpu calls to use the right types. While I'm 9876 not familiar with the MIPS ISA in these cases, these look like 9877 simple oversights due to the name/type mismatches. This at least 9878 fixes compiling with -Wenum-conversion. 9879 9880 sim: sh: trim trailing whitespace in generated code 9881 No functional change here, but makes it a little easier to read the 9882 generated code when editors aren't highlighting all the spurious 9883 trailing whitespace on lines. 9884 9885 sim: mn10300: fix sim_engine_halt call 9886 The sim_stop argument is an enum and should only be one of those 9887 values, not a signal constant. Fix the logic to pass the right 9888 sim_xxx & SIM_xxx values in the right arguments. 9889 98902023-12-05 Mike Frysinger <vapier@gentoo.org> 9891 9892 sim: m32c: use UTF-8 encoding 9893 We only support UTF-8 nowadays, so stop using ISO-8859-1. 9894 9895 Maybe we should delete this logic entirely, but for now, 9896 do the bare min conversion to keep it compiling. 9897 98982023-12-05 Andreas Schwab <schwab@suse.de> 9899 9900 Add basic support for RISC-V 64-bit EFI objects 9901 This adds a new PEI target pei-riscv64-little. Only objdump and objcopy 9902 are supported. 9903 9904 bfd: 9905 * .gitignore: Add pe-riscv64igen.c. 9906 * Makefile.am (BFD64_BACKENDS): Add pei-riscv64.lo, 9907 pe-riscv64igen.lo. 9908 (BFD64_BACKENDS_CFILES): Add pei-riscv64.c. 9909 (BUILD_CFILES): Add pe-riscv64igen.c. 9910 (pe-riscv64igen.c): New rule. 9911 * Makefile.in: Regenerate. 9912 * bfd.c (bfd_get_sign_extend_vma): Add pei-riscv64-little. 9913 * coff-riscv64.c: New file. 9914 * coffcode.h (coff_set_arch_mach_hook, coff_set_flags) 9915 (coff_write_object_contents): Add riscv64 (riscv64_pei_vec) 9916 support. 9917 * config.bfd (targ_selvecs): Add riscv64_pei_vec to all riscv* 9918 targets. 9919 * configure.ac: Handle riscv64_pei_vec. 9920 * configure: Regenerate. 9921 * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE) 9922 (GET_OPTHDR_SIZE_OF_STACK_RESERVE) 9923 (PUT_OPTHDR_SIZE_OF_STACK_RESERVE) 9924 (GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT) 9925 (GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE) 9926 (GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT) 9927 (GET_PDATA_ENTRY, _bfd_XX_bfd_copy_private_bfd_data_common) 9928 (_bfd_XX_bfd_copy_private_section_data) 9929 (_bfd_XX_get_symbol_info, _bfd_XX_only_swap_filehdr_out) 9930 (_bfd_XX_print_private_bfd_data_common) 9931 (_bfd_XXi_final_link_postscript, _bfd_XXi_only_swap_filehdr_out) 9932 (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out) 9933 (_bfd_XXi_swap_aux_in, _bfd_XXi_swap_aux_out) 9934 (_bfd_XXi_swap_lineno_in, _bfd_XXi_swap_lineno_out) 9935 (_bfd_XXi_swap_scnhdr_out, _bfd_XXi_swap_sym_in) 9936 (_bfd_XXi_swap_sym_out, _bfd_XXi_swap_debugdir_in) 9937 (_bfd_XXi_swap_debugdir_out, _bfd_XXi_write_codeview_record) 9938 (_bfd_XXi_slurp_codeview_record) [COFF_WITH_peRiscV64]: Define. 9939 (_bfd_peRiscV64_print_ce_compressed_pdata): Declare. 9940 * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out) 9941 (_bfd_XXi_swap_scnhdr_out, pe_print_pdata) 9942 (_bfd_XX_print_private_bfd_data_common) 9943 (_bfd_XX_bfd_copy_private_section_data) 9944 (_bfd_XXi_final_link_postscript): Support COFF_WITH_peRiscV64. 9945 * pei-riscv64.c: New file. 9946 * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd) 9947 (pe_ILF_object_p): Support COFF_WITH_peRiscV64. 9948 (jtab): Add dummy entry that traps. 9949 * targets.c (_bfd_target_vector): Add riscv64_pei_vec. 9950 9951 binutils: 9952 * testsuite/binutils-all/riscv/pei-riscv64.d: New. 9953 * testsuite/binutils-all/riscv/pei-riscv64.s: New. 9954 9955 include: 9956 * coff/riscv64.h: New file. 9957 * coff/pe.h (IMAGE_FILE_MACHINE_RISCV32) 9958 (IMAGE_FILE_MACHINE_RISCV64): Define. 9959 99602023-12-05 Alan Modra <amodra@gmail.com> 9961 9962 alpha_ecoff_get_relocated_section_contents buffer overflow 9963 This is aimed at fixing holes in two alpha-ecoff relocation functions 9964 that access section contents without first bounds checking offsets. 9965 I've also rewritten ALPHA_R_OP_STORE handling to support writing to 9966 the bytes near the end of the section. 9967 9968 * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't 9969 bother checking ALPHA_R_LITERAL insn. Range check before reading 9970 contents for ALPHA_R_GPDISP, and simplify handling. Rewrite 9971 ALPHA_R_OP_STORE handling. Correct error callback args. 9972 (alpha_relocate_section): Similarly. Don't abort, report errors. 9973 99742023-12-05 Alan Modra <amodra@gmail.com> 9975 9976 memory leak in display_debug_addr 9977 * dwarf.c (display_debug_addr): Free dummy debug_addr_info entry. 9978 Don't return without freeing debug_addr_info on error paths. 9979 99802023-12-05 Alan Modra <amodra@gmail.com> 9981 9982 Don't use free_contents in _bfd_elf_slurp_version_tables 9983 In commit 7ac6d0c38c36 I made more use of free_contents in 9984 _bfd_elf_slurp_version_tables, a variable added to tag the case where 9985 raw verneed and verdefs have been read locally by the function, and 9986 thus should be freed before returning. In retrospect it may have been 9987 better to do without the extra variable entirely. It's easy to infer 9988 when "contents" should be freed, costing a little extra on an error 9989 path but costing less elsewhere. 9990 9991 * elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents. 9992 99932023-12-05 Peter Jones <pjones@redhat.com> 9994 9995 Handle "efi-app-riscv64" and similar targets in objcopy. 9996 This adds the efi target name handling for riscv64 to objcopy. 9997 9998 binutils: 9999 * binutils/objcopy.c: add riscv64 handling to 10000 convert_efi_target() 10001 10002 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 10003 100042023-12-05 Mike Frysinger <vapier@gentoo.org> 10005 10006 sim: rx: mark unused static var as unused 10007 This seems like a useful utility func that mirrors the int2float 10008 helper, so mark it as unused rather than delete. 10009 10010 sim: rx: constify some read-only global vars 10011 10012 sim: warnings: enable only for development builds 10013 Reuse the bfd/development.sh script like most other project to 10014 determine whether the current source tree is a dev build (e.g. 10015 git) or a release build, and disable the warnings for releases. 10016 100172023-12-05 Mike Frysinger <vapier@gentoo.org> 10018 10019 sim: ppc: fix implicit enum conversion 10020 This code tries to use attach_type enums as hw_phb_decode, and while 10021 they're setup to have compatible values, the compiler doesn't like it 10022 when the cast is missing. So cast it explicitly and then use that. 10023 10024 sim/ppc/hw_phb.c:322:28: error: 10025 implicit conversion from enumeration type 'attach_type' 10026 (aka 'enum _attach_type') to different enumeration type 10027 'hw_phb_decode' [-Werror,-Wenum-conversion] 10028 100292023-12-05 Mike Frysinger <vapier@gentoo.org> 10030 10031 sim: ppc: fix -Wmisleading-indentation warnings 10032 Fix building with -Wmisleading-indentation. 10033 100342023-12-05 Mike Frysinger <vapier@gentoo.org> 10035 10036 sim: ppc: cleanup getrusage decls 10037 Don't conflate HAVE_GETRUSAGE & HAVE_SYS_RESOURCE_H. Use the latter 10038 to include the header and nothing else. Use the former to determine 10039 whether to use the function and nothing else. If we find a system 10040 that doesn't follow POSIX and provides only one of these, we can 10041 figure out how to support it then. The manual local definition is 10042 clashing with the system ones and leading to build failures with 10043 newer C standards. 10044 10045 sim/ppc/emul_netbsd.c:51:5: error: a function declaration without a 10046 prototype is deprecated in all versions of C and is treated as a 10047 zero-parameter prototype in C2x, conflicting with a previous 10048 declaration [-Werror,-Wdeprecated-non-prototype] 10049 100502023-12-05 Alan Modra <amodra@gmail.com> 10051 10052 aarch64-elf: FAIL: indirect call stub to BTI stub relaxation 10053 aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs 10054 being emitted in a different order to that of aarch64-linux. They are 10055 emitted in a different order due to stub names for local symbols 10056 having the section id in the stub name. aarch64-linux-ld generates 10057 one more section than aarch64-elf-ld. That section is .gnu.hash. So 10058 the stub names differ and are hashed to different slots in 10059 stub_hash_table. 10060 10061 Fix this by running the test with --hash-style=sysv, and adjust 10062 expected output. I've also changed the branch over stubs emitted at 10063 the start of a group of stubs to not care about the symbol, for all 10064 groups not just the one that needed changing. 10065 10066 * ld-aarch64/bti-far-3.d: Add --hash-style=sysv. Adjust 10067 expected output. 10068 100692023-12-05 GDB Administrator <gdbadmin@sourceware.org> 10070 10071 Automatic date update in version.in 10072 100732023-12-04 Andrew Burgess <aburgess@redhat.com> 10074 10075 gdb/testsuite: fix directory name in test name 10076 In the commit: 10077 10078 commit 4793f551a5aa68522fd5fbbb7e8f621148f410cd 10079 Date: Mon Nov 27 13:33:17 2023 +0000 10080 10081 gdb: allow use of ~ in 'save gdb-index' command 10082 10083 I added a test which has a directory name within the GDB command, 10084 which then appears in the test name as I failed to give the test a 10085 better name. 10086 10087 Fixed in this commit. 10088 100892023-12-04 Ciaran Woodward <ciaranwoodward@xmos.com> 10090 10091 [gdb/doc] Escape the '@' symbols in generated texinfo files. 10092 '@' is a special symbol meaning 'command' in GNU texinfo. 10093 10094 If the GDBINIT or GDBINIT_DIR path during configuration 10095 included an '@' character, the makeinfo command would fail, 10096 as it interpreted the '@' in the path as a start of a command 10097 when expanding the path in the docs. 10098 10099 This patch simply escapes any '@' characters in the path, 10100 by replacing them with '@@'. This was already done for the 10101 bugurl variable. 10102 10103 This was detected because the 'Jenkins' tool sometimes puts 10104 an '@' in the workspace path. 10105 10106 Approved-By: Tom Tromey <tom@tromey.com> 10107 101082023-12-04 Tom Tromey <tom@tromey.com> 10109 10110 Fix two buglets in .debug_names dumping 10111 While working on gdb's .debug_names writer, I found a couple of small 10112 bugs in binutils .debug_names dumping. 10113 10114 First, the DWARF spec (section 6.1.1.4.6 Name Table) says: 10115 10116 These two arrays are indexed starting at 1, [...] 10117 10118 I think it is clearer for binutils to follow this, particularly 10119 because DW_IDX_parent refers to this number. 10120 10121 Second, I think the handling of an empty hash table is slightly wrong. 10122 Currently the dumping code assumes there is always an array of hashes. 10123 However, section 6.1.1.4.5 Hash Lookup Table says: 10124 10125 The optional hash lookup table immediately follows the list of 10126 type signatures. 10127 10128 and then: 10129 10130 The hash lookup table is actually two separate arrays: an array of 10131 buckets, followed immediately by an array of hashes. 10132 10133 My reading of this is that the hash table as a whole is optional, and 10134 so the hashes will not exist in this case. (This also makes sense 10135 because the hashes are not useful without the buckets anyway.) 10136 10137 This patch fixes both of these problems. FWIW I have some gdb patches 10138 in progress that change gdb both to omit the hash table and to use 10139 DW_IDX_parent. 10140 10141 2023-12-04 Tom Tromey <tom@tromey.com> 10142 10143 * dwarf.c (display_debug_names): Handle empty .debug_names hash 10144 table. Name entries start at 1. 10145 101462023-12-04 Ciaran Woodward <ciaranwoodward@xmos.com> 10147 10148 gdb: add Ciaran Woodward to gdb/MAINTAINERS 10149 101502023-12-04 Jens Remus <jremus@linux.ibm.com> 10151 10152 s390: Support for jump visualization in disassembly 10153 Add support for jump visualization for the s390 architecture in 10154 disassembly: 10155 10156 objdump -d --visualize-jumps ... 10157 10158 Annotate the (conditional) jump and branch relative instructions with 10159 information required for jump visualization: 10160 - jump: Unconditional jump / branch relative. 10161 - condjump: Conditional jump / branch relative. 10162 - jumpsr: Jump / branch relative to subroutine. 10163 10164 Unconditional jump and branch relative instructions are annotated as 10165 jump. 10166 Conditional jump and branch relative instructions, jump / branch 10167 relative on count/index, and compare and jump / branch relative 10168 instructions are annotated as condjump. 10169 Jump and save (jas, jasl) and branch relative and save (bras, brasl) 10170 instructions are annotated as jumpsr (jump to subroutine). 10171 10172 Provide instruction information required for jump visualization during 10173 disassembly. 10174 The instruction type is provided after determining the opcode. 10175 For non-code it is set to dis_noninsn. Otherwise it defaults to 10176 dis_nonbranch. No annotation is done for data reference instructions 10177 (i.e. instruction types dis_dref and dis_dref2). Note that the 10178 instruction type needs to be provided before printing of the 10179 instruction, as it is used in print_address_func() to translate the 10180 argument value into an address if it is assumed to be a PC-relative 10181 offset. Note that this is never the case on s390, as 10182 print_address_func() is only called with addresses and never with 10183 offsets. 10184 The target of the (conditional) jump and branch relative instructions 10185 is provided during print, when the PC relative operand is decoded. 10186 10187 include/ 10188 * opcode/s390.h: Define opcode flags to annotate instruction 10189 class information for jump visualization: 10190 S390_INSTR_FLAG_CLASS_BRANCH, S390_INSTR_FLAG_CLASS_RELATIVE, 10191 S390_INSTR_FLAG_CLASS_CONDITIONAL, and 10192 S390_INSTR_FLAG_CLASS_SUBROUTINE. 10193 Define opcode flags mask S390_INSTR_FLAG_CLASS_MASK for above 10194 instruction class information. 10195 Define helpers for common instruction class flag combinations: 10196 S390_INSTR_FLAGS_CLASS_JUMP, S390_INSTR_FLAGS_CLASS_CONDJUMP, 10197 and S390_INSTR_FLAGS_CLASS_JUMPSR. 10198 10199 opcodes/ 10200 * s390-mkopc.c: Add opcode flags to annotate information 10201 for jump visualization: jump, condjump, and jumpsr. 10202 * s390-opc.txt: Annotate (conditional) jump and branch relative 10203 instructions with information for jump visualization. 10204 * s390-dis.c (print_insn_s390, s390_print_insn_with_opcode): 10205 Provide instruction information for jump visualization. 10206 10207 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 10208 102092023-12-04 Tom Tromey <tromey@adacore.com> 10210 10211 Remove incorrect "fall-through" comment 10212 I found a "fall-through" comment in gdb/remote.c that was incorrect -- 10213 the code here cannot in fact fall through. 10214 102152023-12-04 Tom Tromey <tromey@adacore.com> 10216 10217 Update fall-through comment in gdbserver 10218 I noticed that gdbserver/win32-low.cc has a fall-through comment that 10219 should have been converted to use the annotation instead. 10220 10221 This patch makes the change. 10222 102232023-12-04 Richard Bunt <richard.bunt@linaro.org> 10224 10225 gdb: Enable early init of thread pool size 10226 This commit enables the early initialization commands (92e4e97a9f5) to 10227 modify the number of threads used by gdb's thread pool. 10228 10229 The motivation here is to prevent gdb from spawning a detrimental number 10230 of threads on many-core systems under environments with restrictive 10231 ulimits. 10232 10233 With gdb before this commit, the thread pool takes the following sizes: 10234 10235 1. Thread pool size is initialized to 0. 10236 10237 2. After the maintenance commands are defined, the thread pool size is 10238 set to the number of system cores (if it has not already been set). 10239 10240 3. Using early initialization commands, the thread pool size can be 10241 changed using "maint set worker-threads". 10242 10243 4. After the first prompt, the thread pool size can be changed as in the 10244 previous step. 10245 10246 Therefore after step 2. gdb has potentially launched hundreds of threads 10247 on a many-core system. 10248 10249 After this change, step 2 and 3 are reversed so there is an opportunity 10250 to set the required number of threads without needing to default to the 10251 number of system cores first. 10252 10253 There does exist a configure option (added in 261b07488b9) to disable 10254 multithreading, but this does not allow for an already deployed gdb to 10255 be configured. 10256 10257 Additionally, the default number of worker threads is clamped at eight 10258 to control the number of worker threads spawned on many-core systems. 10259 This value was chosen as testing recorded on bugzilla issue 29959 10260 indicates that parallel efficiency drops past this point. 10261 10262 GDB built with GCC 13. 10263 10264 No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel 10265 LLVM, NVHPC; Platforms: x86_64, aarch64. 10266 10267 The scenario that interests me the most involves preventing GDB from 10268 spawning any worker threads at all. This was tested by counting the 10269 number of clones observed by strace: 10270 10271 strace -e clone,clone3 gdb/gdb -q \ 10272 --early-init-eval-command="maint set worker-threads 0" \ 10273 -ex q ./gdb/gdb |& grep --count clone 10274 10275 The new test relies on "gdb: install CLI uiout while processing early 10276 init files" developed by Andrew Burgess. This patch will need pushing 10277 prior to this change. 10278 10279 The clamping was tested on machines with both 16 cores and a single 10280 core. "maint show worker-threads" correctly reported eight and one 10281 respectively. 10282 10283 Approved-By: Tom Tromey <tom@tromey.com> 10284 102852023-12-04 Andrew Burgess <aburgess@redhat.com> 10286 10287 gdb: install CLI uiout while processing early init files 10288 The next commit wants to use a 'show' command within an early 10289 initialisation file, despite these commands not being in the list of 10290 acceptable commands for use within an early initialisation file. 10291 10292 The problem we run into is that the early initialisation files are 10293 processed before GDB has installed the top level interpreter. The 10294 interpreter is responsible to installing the default uiout (accessed 10295 through current_uiout), and as a result code that depends on 10296 uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and 10297 crashing GDB. 10298 10299 I did consider moving the interpreter installation before the early 10300 initialisation, and this would work fine except for the new DAP 10301 interpreter, which relies on having Python available during its 10302 initialisation. Which means we can't install the interpreter until 10303 after Python has been initialised, and the early initialisation 10304 handling has to occur before Python is setup -- that's the whole point 10305 of this feature (to allow customisation of how Python is setup). 10306 10307 So, what I propose is that early within captured_main_1, we install a 10308 temporary cli_ui_out as the current_uiout. This will remain in place 10309 until the top-level interpreter is installed, at which point the 10310 temporary will be replaced. 10311 10312 What this means is that current_uiout will no longer be nullptr, 10313 instead, any commands within an early initialisation file that trigger 10314 output, will perform that output in a CLI style. 10315 10316 I propose that we don't update the documentation for early 10317 initialisation files, we leave the user advice as being only 'set' and 10318 'source' commands are acceptable. But now, if a user does try a 10319 'show' command, then instead of crashing, GDB will do something 10320 predictable. 10321 10322 I've not added a test in this commit. The next commit relies on this 10323 patch and will serve as a test. 10324 10325 Tested-By: Richard Bunt <richard.bunt@linaro.org> 10326 103272023-12-04 Tom de Vries <tdevries@suse.de> 10328 10329 [gdb/tui] Fix wrapping strings 10330 I noticed that after resizing to a narrow window, I got: 10331 ... 10332 ┌────────────────┐ 10333 │ │ 10334 │[ No Source Avail 10335 able ] │ 10336 │ │ 10337 └────────────────┘ 10338 ... 10339 10340 Fix this by adding two new functions: 10341 - tui_win_info::display_string (int y, int x, const char *str) 10342 - tui_win_info::display_string (const char *str) 10343 that make sure that borders are not overwritten, which get us instead: 10344 ... 10345 ┌────────────────┐ 10346 │ │ 10347 │[ No Source Avai│ 10348 │ │ 10349 │ │ 10350 └────────────────┘ 10351 ... 10352 10353 Tested on x86_64-linux. 10354 103552023-12-04 GDB Administrator <gdbadmin@sourceware.org> 10356 10357 Automatic date update in version.in 10358 103592023-12-03 Kevin Buettner <kevinb@redhat.com> 10360 10361 Fix detach bug when lwp has exited/terminated 10362 When using GDB on native linux, it can happen that, while attempting 10363 to detach an inferior, the inferior may have been exited or have been 10364 killed, yet still be in the list of lwps. Should that happen, the 10365 assert in x86_linux_update_debug_registers in 10366 gdb/nat/x86-linux-dregs.c will trigger. The line in question looks 10367 like this: 10368 10369 gdb_assert (lwp_is_stopped (lwp)); 10370 10371 For this case, the lwp isn't stopped - it's dead. 10372 10373 The bug which brought this problem to my attention is one in which the 10374 pwntools library uses GDB to to debug a process; as the script is 10375 shutting things down, it kills the process that GDB is debugging and 10376 also sends GDB a SIGTERM signal, which causes GDB to detach all 10377 inferiors prior to exiting. Here's a link to the bug: 10378 10379 https://bugzilla.redhat.com/show_bug.cgi?id=2192169 10380 10381 The following shell command mimics part of what the pwntools 10382 reproducer script does (with regard to shutting things down), but 10383 reproduces the bug much less reliably. I have found it necessary to 10384 run the command a bunch of times before seeing the bug. (I usually 10385 see it within 5-10 repetitions.) If you choose to try this command, 10386 make sure that you have no running "cat" or "gdb" processes first! 10387 10388 cat </dev/zero >/dev/null & \ 10389 (sleep 5; (kill -KILL `pgrep cat` & kill -TERM `pgrep gdb`)) & \ 10390 sleep 1 ; \ 10391 gdb -q -iex 'set debuginfod enabled off' -ex 'set height 0' \ 10392 -ex c /usr/bin/cat `pgrep cat` 10393 10394 So, basically, the idea here is to kill both gdb and cat at roughly 10395 the same time. If we happen to attempt the detach before the process 10396 lwp has been deleted from GDB's (linux native) LWP data structures, 10397 then the assert will trigger. The relevant part of the backtrace 10398 looks like this: 10399 10400 #8 0x00000000008a83ae in x86_linux_update_debug_registers (lwp=0x1873280) 10401 at gdb/nat/x86-linux-dregs.c:146 10402 #9 0x00000000008a862f in x86_linux_prepare_to_resume (lwp=0x1873280) 10403 at gdb/nat/x86-linux.c:81 10404 #10 0x000000000048ea42 in x86_linux_nat_target::low_prepare_to_resume ( 10405 this=0x121eee0 <the_amd64_linux_nat_target>, lwp=0x1873280) 10406 at gdb/x86-linux-nat.h:70 10407 #11 0x000000000081a452 in detach_one_lwp (lp=0x1873280, signo_p=0x7fff8ca3441c) 10408 at gdb/linux-nat.c:1374 10409 #12 0x000000000081a85f in linux_nat_target::detach ( 10410 this=0x121eee0 <the_amd64_linux_nat_target>, inf=0x16e8f70, from_tty=0) 10411 at gdb/linux-nat.c:1450 10412 #13 0x000000000083a23b in thread_db_target::detach ( 10413 this=0x1206ae0 <the_thread_db_target>, inf=0x16e8f70, from_tty=0) 10414 at gdb/linux-thread-db.c:1385 10415 #14 0x0000000000a66722 in target_detach (inf=0x16e8f70, from_tty=0) 10416 at gdb/target.c:2526 10417 #15 0x0000000000a8f0ad in kill_or_detach (inf=0x16e8f70, from_tty=0) 10418 at gdb/top.c:1659 10419 #16 0x0000000000a8f4fa in quit_force (exit_arg=0x0, from_tty=0) 10420 at gdb/top.c:1762 10421 #17 0x000000000070829c in async_sigterm_handler (arg=0x0) 10422 at gdb/event-top.c:1141 10423 10424 My colleague, Andrew Burgess, has done some recent work on other 10425 problems with detach. Upon hearing of this problem, he came up a test 10426 case which reliably reproduces the problem and tests for a few other 10427 problems as well. In addition to testing detach when the inferior has 10428 terminated due to a signal, it also tests detach when the inferior has 10429 exited normally. Andrew observed that the linux-native-only 10430 "checkpoint" command would be affected too, so the test also tests 10431 those cases when there's an active checkpoint. 10432 10433 For the LWP exit / termination case with no checkpoint, that's handled 10434 via newly added checks of the waitstatus in detach_one_lwp in 10435 linux-nat.c. 10436 10437 For the checkpoint detach problem, I chose to pass the lwp_info 10438 to linux_fork_detach in linux-fork.c. With that in place, suitable 10439 tests were added before attempting a PTRACE_DETACH operation. 10440 10441 I added a few asserts at the beginning of linux_fork_detach and 10442 modified the caller code so that the newly added asserts shouldn't 10443 trigger. (That's what the 'pid == inferior_ptid.pid' check is about 10444 in gdb/linux-nat.c.) 10445 10446 Lastly, I'll note that the checkpoint code needs some work with regard 10447 to background execution. This patch doesn't attempt to fix that 10448 problem, but it doesn't make it any worse. It does slightly improve 10449 the situation with detach because, due to the check noted above, 10450 linux_fork_detach() won't be called for the wrong inferior when there 10451 are multiple inferiors. (There are at least two other problems with 10452 the checkpoint code when there are multiple inferiors. See: 10453 https://sourceware.org/bugzilla/show_bug.cgi?id=31065) 10454 10455 This commit also adds a new test, 10456 gdb.base/process-dies-while-detaching.exp. Andrew Burgess is the 10457 primary author of this test case. Its design is similar to that of 10458 gdb.threads/main-thread-exit-during-detach.exp, which was also written 10459 by Andrew. 10460 10461 This test checks that GDB correctly handles several cases that can 10462 occur when GDB attempts to detach an inferior process. The process 10463 can exit or be terminated (e.g. via SIGKILL) prior to GDB's event 10464 loop getting a chance to remove it from GDB's internal data 10465 structures. To complicate things even more, detach works differently 10466 when a checkpoint (created via GDB's "checkpoint" command) exists for 10467 the inferior. This test checks all four possibilities: process exit 10468 with no checkpoint, process termination with no checkpoint, process 10469 exit with a checkpoint, and process termination with a checkpoint. 10470 10471 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 10472 Approved-By: Andrew Burgess <aburgess@redhat.com> 10473 104742023-12-03 GDB Administrator <gdbadmin@sourceware.org> 10475 10476 Automatic date update in version.in 10477 104782023-12-02 Petr Tesarik <petr@tesarici.cz> 10479 10480 binutils: Fix documentation typo in the --set-sect-name option 10481 Fix a --set-sect-name typo in the description of objcopy 10482 --rename-section. 10483 10484 gdb: Update Petr Tesarik's email address in gdb/MAINTAINERS 10485 104862023-12-02 H.J. Lu <hjl.tools@gmail.com> 10487 10488 Fix ld/x86: reduce testsuite dependency on system object files 10489 commit eab996435fe65a421541f59557c5f1fd427573a3 10490 Author: Jan Beulich <jbeulich@suse.com> 10491 Date: Tue Nov 7 13:58:32 2023 +0100 10492 10493 ld/x86: reduce testsuite dependency on system object files 10494 10495 changed some C compiler tests to assembler/linker tests which introduced 10496 2 problems: 10497 10498 1. It broke x32 binutils tests since --64 was passed to assembler, but 10499 -m elf_x86_64 wasn't passed to linker. 10500 2. -nostdlib was passed to C compiler driver to exclude standard run-time 10501 files which should be avoided with -r option for linker tests. 10502 10503 Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for 10504 linker tests with -r. 10505 10506 PR ld/30722 10507 * testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker 10508 for tests with --64. Remove -nostdlib for tests with -r. 10509 105102023-12-02 GDB Administrator <gdbadmin@sourceware.org> 10511 10512 Automatic date update in version.in 10513 105142023-12-01 Tom Tromey <tromey@adacore.com> 10515 10516 Bail out of "attach" if a thread cannot be traced 10517 On Linux, threads are treated much like separate processes by the 10518 kernel. In particular, it's possible to ptrace just a single thread. 10519 If gdb tries to attach to a multi-threaded inferior, where a non-main 10520 thread is already being traced (e.g., by strace), then gdb will get 10521 into an infinite loop attempting to attach. 10522 10523 This patch fixes this problem by having the attach fail if ptrace 10524 fails to attach to any thread of the inferior. 10525 105262023-12-01 Tom Tromey <tromey@adacore.com> 10527 10528 Use gdb_dir_up in linux_proc_attach_tgid_threads 10529 This changes linux_proc_attach_tgid_threads to use gdb_dir_up. This 10530 makes it robust against exceptions. 10531 10532 Approved-By: Simon Marchi <simon.marchi@efficios.com> 10533 105342023-12-01 Tom Tromey <tromey@adacore.com> 10535 10536 Minor cleanup in linux_proc_attach_tgid_threads 10537 linux_proc_attach_tgid_threads computes a file name, and then 10538 re-computes it for a warning. It is better to reuse the 10539 already-computed name here. 10540 10541 Approved-By: Simon Marchi <simon.marchi@efficios.com> 10542 105432023-12-01 Simon Marchi <simon.marchi@efficios.com> 10544 10545 gdb: add missing regcache_map_entry array null terminators in aarch64-linux-tdep.c 10546 Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry 10547 arrays without a null terminator. The null terminators are needed for 10548 regcache::transfer_regset and regcache_map_entry_size to work properly. 10549 10550 Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105 10551 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 10552 Approved-By: Luis Machado <luis.machado@arm.com> 10553 105542023-12-01 Simon Marchi <simon.marchi@efficios.com> 10555 10556 gdb: return when exceeding buffer size in regcache::transfer_regset 10557 regcache::transfer_regset iterates over an array of regcache_map_entry, 10558 transferring the registers (between regcache and buffer) described by 10559 those entries. It stops either when it reaches the end of the 10560 regcache_map_entry array (marked by a null entry) or (it seems like the 10561 intent is) when it reaches the end of the buffer (in which case not all 10562 described registers are transferred). 10563 10564 I said "seems like the intent is", because there appears to be a small 10565 bug. transfer_regset is made of two loops: 10566 10567 foreach regcache_map_entry: 10568 foreach register described by the regcache_map_entry: 10569 if the register doesn't fit in the remainder of the buffer: 10570 break 10571 10572 transfer register 10573 10574 When stopping because we have reached the end of the buffer, the break 10575 only breaks out of the inner loop. 10576 10577 This problem causes some failures when I run tests such as 10578 gdb.arch/aarch64-sme-core-3.exp (on AArch64 Linux, in qemu). This is 10579 partly due to aarch64_linux_iterate_over_regset_sections failing to add 10580 a null terminator in its regcache_map_entry array, but I think there is 10581 still a problem in transfer_regset. 10582 10583 The sequence to the crash is: 10584 10585 - The `regcache_map_entry za_regmap` object built in 10586 aarch64_linux_iterate_over_regset_sections does not have a null 10587 terminator. 10588 - When the target does not have a ZA register, 10589 aarch64_linux_collect_za_regset calls `regcache->collect_regset` with 10590 a size of 0 (it's actually pointless, but still it should work). 10591 - transfer_regset gets called with a buffer size of 0. 10592 - transfer_regset detects that the register to transfer wouldn't fit in 10593 0 bytes, so it breaks out of the inner loop. 10594 - The outer loop tries to go read the next regcache_map_entry, but 10595 there isn't one, and we start reading garbage. 10596 10597 Obviously, this would get fixed by making 10598 aarch64_linux_iterate_over_regset_sections use a null terminator (which 10599 is what the following patch does). But I think that when detecting that 10600 there is not enough buffer left for the current register, 10601 transfer_regset should return, not only break out of the inner loop. 10602 10603 This is a kind of contrived scenario, but imagine we have these two 10604 regcache_map_entry objects: 10605 10606 - 2 registers of 8 bytes 10607 - 2 registers of 4 bytes 10608 10609 For some reason, the caller passes a buffer of 12 bytes. 10610 transfer_regset will detect that the second 8 byte register does not 10611 fit, and break out of the inner loop. However, it will then go try the 10612 next regcache_map_entry. It will see that it can fit one 4 byte 10613 register in the remaining buffer space, and transfer it from/to there. 10614 This is very likely not an expected behavior, we wouldn't expect to 10615 read/write this sequence of registers from/to the buffer. 10616 10617 In this example, whether passing a 12 bytes buffer makes sense or 10618 whether it is a size computation bug in the caller, we don't know, but I 10619 think that exiting as soon as a register doesn't fit is the sane thing 10620 to do. 10621 10622 Change-Id: Ia349627d2e5d281822ade92a8e7a4dea4f839e07 10623 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 10624 Reviewed-By: Luis Machado <luis.machado@arm.com> 10625 106262023-12-01 Tom Tromey <tromey@adacore.com> 10627 10628 Add link to Debugger Adapter Protocol node in documentation 10629 I noticed that the interpreters node in the docs links to the DAP 10630 protocol docs, but I thought the DAP node ought to as well. This 10631 patch adds a bit of introductory text there. 10632 10633 Approved-By: Eli Zaretskii <eliz@gnu.org> 10634 106352023-12-01 Jeff Law <jeffreyalaw@gmail.com> 10636 10637 Fix right shifts in mcore simulator on 64 bit hosts. 10638 If the value to be shifted has the sign bit set, the sign 10639 bit would get copied into bits 32..63 of the temporary. Those 10640 would then be right shifted into the final value giving an 10641 incorrect final result. 10642 10643 This was observed with upcoming GCC improvements which eliminate 10644 unnecessary extensions. 10645 106462023-12-01 Guinevere Larsen <blarsen@redhat.com> 10647 10648 gdb/testsuite: fix completion tests when using READ1 10649 The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced 10650 regressions when testing using the READ1 mechanism. The reason for that 10651 is the new failure path in proc test_gdb_complete_tab_unique, which 10652 looks for GDB suggesting more than what the test inputted, but not the 10653 correct answer, followed by a white space. Consider the following case: 10654 10655 int foo(int bar, int baz); 10656 10657 Sending the command "break foo<tab>" to GDB will return 10658 10659 break foo(int, int) 10660 10661 which easily fits the buffer in normal testing, so everything works, but 10662 when reading one character at a time, the test will find the partial 10663 "break foo(int, " and assume that there was a mistake, so we get a 10664 spurious FAIL. 10665 10666 That change was added because we wanted to avoid forcing a completion 10667 failure to fail through timeout, which it had to do because there is no 10668 way to verify that the output is done, mostly because when I was trying 10669 to solve a different problem I kept getting reading errors and testing 10670 completion was frustrating. 10671 10672 This commit implements a better way to avoid that frustration, by first 10673 testing gdb's complete command and only if that passes we will test tab 10674 completion. The difference is that when testing with the complete 10675 command, we can tell when the output is over when we receive the GDB 10676 prompt again, so we don't need to rely on timeouts. With this, the 10677 change to test_gdb_complete_tab_unique has been removed as that test 10678 will only be run and fail in the very unlikely scenario that tab 10679 completion is different than command completion. 10680 10681 Approved-By: Andrew Burgess <aburgess@redhat.com> 10682 106832023-12-01 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 10684 10685 Remove unnecessary returns and unused variables in AIX. 10686 This is a patch to simplify the pd_activate () in aix-thread.c incase of a failure to start a thread session 10687 , since pd_activate () now has return type void. 10688 10689 Also this patch fixes the shadow declarartion warning in sync-threadlists. 10690 106912023-12-01 Nick Clifton <nickc@redhat.com> 10692 10693 Fix: nm -U short flag erroneously consumes argument 10694 PR 31105 10695 * nm.c (main): Remove spurious colon after U in the call to getopt_long 10696 106972023-12-01 Jan Beulich <jbeulich@suse.com> 10698 10699 ld: fix build with old makeinfo 10700 Makeinfo 4.12 is unhappy about the new "Special Sections" without that 10701 also having a @chapter line. 10702 10703 binutils/Dwarf: avoid "shadowing" of glibc function name 10704 Yet once again: Old enough glibc has an (unguarded) declaration of 10705 index() in string.h, which triggers a "shadows a global declaration" 10706 warning with at least some gcc versions. 10707 10708 gas: drop unused fields from struct segment_info_struct 10709 user_stuff, dot, and lineno_list_{head,tail} have no users (left), while 10710 bfd_section was only ever written. 10711 10712 x86: adjust NOP generation after potential non-insn 10713 Just like avoiding to do certain transformations potentially affected by 10714 stand-alone prefixes or direct data emission, also avoid emitting 10715 optimized NOPs right afterwards; insert a plain old NOP first in such 10716 cases. 10717 10718 x86: i386_cons_align() badly affects diagnostics 10719 Warning without knowing what's going to follow isn't useful, the more 10720 that appropriate warnings are emitted elsewhere in all cases. Not 10721 updating state (file/line in particular) also isn't helpful, as it's 10722 always the last directive ahead of a construct potentially needing 10723 fiddling with that's "guilty" in that fiddling being suppressed. 10724 10725 gas: no md_cons_align() for .nop{,s} 10726 .nop and .nops generate code, not data. Hence them invoking 10727 md_cons_align() is at best inappropriate. In fact it actually gets in 10728 the of x86'es state maintenance involving i386_cons_align(). 10729 10730 x86: suppress optimization after potential non-insn 10731 Just like avoiding to do other transformations potentially affected by 10732 stand-alone prefixes or direct data emission, also avoid optimization 10733 on the following insn. 10734 107352023-12-01 Jan Beulich <jbeulich@suse.com> 10736 10737 x86: last-insn recording should be per-section 10738 Otherwise intermediate section switches result in inconsistent behavior. 10739 Note, however, that intermediate sub-section switches will continue to 10740 result in inconsistent or even inappropriate behavior. 10741 10742 While there also add recording of state to s_insn(). 10743 107442023-12-01 Jan Beulich <jbeulich@suse.com> 10745 10746 x86: allow 32-bit reg to be used with U{RD,WR}MSR 10747 ... as MSR index specifier: It is unreasonable to demand that people 10748 write less readable / understandable code, just because the present 10749 documentation mentions only Reg64. Whether to also adjust the 10750 disassembler is a separate question, perhaps indeed more tightly tied 10751 to what the spec says. 10752 107532023-12-01 Simon Marchi <simon.marchi@efficios.com> 10754 10755 gdb: fix warnings about invalid [[fallthrough]] usage 10756 Fix these two warnings, when building on macos: 10757 10758 CXX cp-name-parser.o 10759 /Users/smarchi/src/binutils-gdb/gdb/cp-name-parser.y:1644:7: error: fallthrough annotation does not directly precede switch label 10760 [[fallthrough]]; 10761 ^ 10762 10763 CXX dbxread.o 10764 /Users/smarchi/src/binutils-gdb/gdb/dbxread.c:2809:7: error: fallthrough annotation does not directly precede switch label 10765 [[fallthrough]]; 10766 ^ 10767 10768 In these two cases, we [[fallthrough]], followed by a regular label, 10769 followed by a case label. Move the [[fallthrough]] below the regular 10770 label. 10771 10772 Change-Id: If4a3145139e050bdb6950c7f239badd5778e6f64 10773 Approved-By: Tom Tromey <tom@tromey.com> 10774 107752023-12-01 Patrick O'Neill <patrick@rivosinc.com> 10776 10777 RISC-V: Make riscv_is_mapping_symbol stricter 10778 riscv_is_mapping_symbol currently accepts any symbol that starts with $x 10779 or $d. This patch makes the check more strict, requiring exactly $x, $d, 10780 or $xrv. It also makes use of this stricter mapping in 10781 riscv_is_valid_mapping_symbol. 10782 10783 ChangeLog: 10784 10785 * bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only 10786 strings that are exactly $x, $d, or $xrv. 10787 * opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use 10788 riscv_elf_is_mapping_symbols. 10789 107902023-12-01 Nelson Chu <nelson@rivosinc.com> 10791 10792 RISC-V: Update gas/NEWS for RISC-V vendor extension news. 10793 gas/ 10794 * NEWS: Update RISC-V vendor extension news. 10795 107962023-12-01 Nelson Chu <nelson.chu@sifive.com> 10797 Hau Hsu <hau.hsu@sifive.com> 10798 Kito Cheng <kito.cheng@sifive.com> 10799 10800 RISC-V: Add SiFive custom vector coprocessor interface instructions v1.0 10801 SiFive has define as set of flexible instruction for extending vector 10802 coprocessor, it able to encoding opcode like .insn but with predefined 10803 format. 10804 10805 List of instructions: 10806 sf.vc.x 10807 sf.vc.i 10808 sf.vc.vv 10809 sf.vc.xv 10810 sf.vc.iv 10811 sf.vc.fv 10812 sf.vc.vvv 10813 sf.vc.xvv 10814 sf.vc.ivv 10815 sf.vc.fvv 10816 sf.vc.vvw 10817 sf.vc.xvw 10818 sf.vc.ivw 10819 sf.vc.fvw 10820 sf.vc.v.x 10821 sf.vc.v.i 10822 sf.vc.v.vv 10823 sf.vc.v.xv 10824 sf.vc.v.iv 10825 sf.vc.v.fv 10826 sf.vc.v.vvv 10827 sf.vc.v.xvv 10828 sf.vc.v.ivv 10829 sf.vc.v.fvv 10830 sf.vc.v.vvw 10831 sf.vc.v.xvw 10832 sf.vc.v.ivw 10833 sf.vc.v.fvw 10834 10835 Spec of Xsfvcp 10836 https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software 10837 108382023-12-01 Christoph Müllner <christoph.muellner@vrull.eu> 10839 10840 RISC-V: Zv*: Add support for Zvkb ISA extension 10841 Back then when the support for the RISC-V vector crypto extensions 10842 was merged, the specification was frozen, but not ratified. 10843 A frozen specification is allowed to change within tight bounds 10844 before ratification and this has happend with the vector crypto 10845 extensions. 10846 10847 The following changes were applied: 10848 * A new extension Zvkb was defined, which is a strict subset of Zvbb. 10849 * Zvkn and Zvks include now Zvkb instead of Zvbb. 10850 10851 This patch implements these changes between the frozen and the 10852 ratified specification. 10853 10854 Note, that this technically an incompatible change of Zvkn and Zvks, 10855 but I am not aware of any project that depends on the currently 10856 implemented behaviour of Zvkn and Zvks. So this patch should be fine. 10857 10858 Reported-By: Jerry Shih <jerry.shih@sifive.com> 10859 Reported-By: Eric Biggers <ebiggers@kernel.org> 10860 108612023-12-01 GDB Administrator <gdbadmin@sourceware.org> 10862 10863 Automatic date update in version.in 10864 108652023-11-30 Tom de Vries <tdevries@suse.de> 10866 10867 [gdb/build] Fix adding -DNDEBUG to python flags of release build 10868 In gdb/configure the line: 10869 ... 10870 $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" 10871 ... 10872 intends to ensure that -DNDEBUG is added to the python flags of a release 10873 build. 10874 10875 However, when building gdb-14-branch we have: 10876 ... 10877 configure:22024: checking compiler flags for python code 10878 ... 10879 configure:22047: result: -fno-strict-aliasing -fwrapv 10880 ... 10881 10882 This is a regression since commit db6878ac553 ("Move sourcing of development.sh 10883 to GDB_AC_COMMON"), which introduced a reference before assignment: 10884 ... 10885 $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" 10886 ... 10887 . $srcdir/../bfd/development.sh 10888 ... 10889 and consequently -DNDEBUG is never added. 10890 10891 [ This was not obvious to me, but apparently evaluating an empty or undefined 10892 variable in this context is similar to using ':' or 'true', so the line is 10893 evaluated as: 10894 ... 10895 true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" 10896 ... ] 10897 10898 Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that 10899 was done for gdbserver/configure.ac in commit db6878ac553. 10900 10901 [ Unfortunately, the move might introduce issues similar to the one we're 10902 fixing, and I'm not sure how to check for this. Shellcheck doesn't detect 10903 this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the 10904 src/gdb directory to make sure ../bfd/development.sh is taken into account) 10905 before and after and observed that the number of lines/words/chars in the 10906 shellcheck output is identical. ] 10907 10908 Build & tested on top of trunk. 10909 10910 Also build on top of gdb-14-branch, and observed this in gdb/config.log: 10911 ... 10912 configure:25214: checking compiler flags for python code 10913 ... 10914 configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG 10915 ... 10916 10917 Approved-By: Tom Tromey <tom@tromey.com> 10918 10919 PR build/31099 10920 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099 10921 109222023-11-30 YunQiang Su <yunqiang.su@cipunited.com> 10923 10924 MIPS/GAS: Add -march=loongson2f to loongson-2f-3 test 10925 On MIPSr6, the encoding of JR instruction has been chaned. 10926 This patch can fix these failures for r6 default triples: 10927 ST Microelectronics Loongson-2F workarounds of Jump Instruction issue 10928 109292023-11-30 YunQiang Su <yunqiang.su@cipunited.com> 10930 10931 MIPS: Set r6 as default arch if vendor is img 10932 This behavior is used by downstream toolchain since 2014, 10933 and has been in GCC since the same year. 10934 10935 We don't support mips64*-img* due to GCC doesn't support it, 10936 and we believe that the multilib should be used for this case. 10937 109382023-11-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 10939 10940 Fix procfs.c compilation 10941 procfs.c doesn't currently compile on Solaris: 10942 10943 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’: 10944 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’? 10945 3017 | type *ptr_type 10946 | ^~~~~~~~ 10947 | var_types 10948 10949 This was caused by this patch: 10950 10951 commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee 10952 Author: Simon Marchi <simon.marchi@efficios.com> 10953 Date: Fri Sep 29 14:24:38 2023 -0400 10954 10955 gdb: remove target_gdbarch 10956 10957 Partially undoing it restores the build. 10958 10959 Tested on amd64-pc-solaris2.11. 10960 109612023-11-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 10962 10963 libiberty: Disable hwcaps for sha1.o 10964 This patch 10965 10966 commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e 10967 Author: Jakub Jelinek <jakub@redhat.com> 10968 Date: Tue Nov 28 13:14:05 2023 +0100 10969 10970 libiberty: Use x86 HW optimized sha1 10971 10972 broke Solaris/x86 bootstrap with the native as: 10973 10974 libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go 10975 ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ] 10976 gccgo: fatal error: Killed signal terminated program go1 10977 10978 As is already done in a couple of other similar cases, this patches 10979 disables hwcaps support for libiberty. 10980 10981 Initially, this didn't work because config/hwcaps.m4 uses target_os, but 10982 didn't ensure it is defined. 10983 10984 Tested on i386-pc-solaris2.11 with as and gas. 10985 10986 2023-11-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 10987 10988 config: 10989 * hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require 10990 AC_CANONICAL_TARGET. 10991 10992 libiberty: 10993 * configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke. 10994 * configure, aclocal.m4: Regenerate. 10995 * Makefile.in (COMPILE.c): Add HWCAP_CFLAGS. 10996 109972023-11-30 Patrick O'Neill <patrick@rivosinc.com> 10998 10999 RISC-V: Avoid updating state until symbol is found 11000 Currently objdump gets and updates the map state once per symbol. Updating the 11001 state (partiularly riscv_parse_subset) is expensive and grows quadratically 11002 since we iterate over all symbols. By deferring this until once we've found the 11003 symbol of interest, we can reduce the time to dump a 4k insn file of .norvc and 11004 .rvc insns from ~47 seconds to ~0.13 seconds. 11005 11006 opcodes/ChangeLog: 11007 11008 * riscv-dis.c (riscv_get_map_state): Remove state updating logic 11009 and rename to riscv_is_valid_mapping_symbol. 11010 (riscv_update_map_state): Add state updating logic to seperate function. 11011 (riscv_search_mapping_symbol): Use new riscv_update_map_state. 11012 (riscv_data_length): Ditto. 11013 110142023-11-30 Jose E. Marchesi <jose.marchesi@oracle.com> 11015 11016 gas: support double-slash line comments in BPF assembly 11017 This patch makes the BPF assembler to support double-slash line 11018 comments, like the llvm BPF assembler does. At this point both 11019 assemblers support the same commenting styles: 11020 11021 - Line comments preceded by # or //. 11022 - Non-nestable block comments delimited by /* and */. 11023 11024 This patch also adds a couple of tests to make sure all the comment 11025 styles work in both normal and pseudoc syntax. The manual is also 11026 updated to mention double-slash line comments. 11027 110282023-11-30 GDB Administrator <gdbadmin@sourceware.org> 11029 11030 Automatic date update in version.in 11031 110322023-11-29 Tom Tromey <tom@tromey.com> 11033 11034 Remove gdb_static_assert 11035 C++17 makes the second parameter to static_assert optional, so we can 11036 remove gdb_static_assert now. 11037 110382023-11-29 Tom Tromey <tom@tromey.com> 11039 11040 Use C++17 void_t 11041 C++17 has void_t and make_void, so gdbsupport/traits.h can be 11042 simplified. 11043 11044 Approved-By: Pedro Alves <pedro@palves.net> 11045 110462023-11-29 Tom Tromey <tom@tromey.com> 11047 11048 Rely on copy elision in scope-exit.h 11049 gdbsupport/scope-exit.h has a couple of comments about being able to 11050 rely on copy elision in C++17. This patch makes the change. 11051 11052 Approved-By: Pedro Alves <pedro@palves.net> 11053 110542023-11-29 Tom Tromey <tom@tromey.com> 11055 11056 Rely on C++17 <new> in new-op.cc 11057 gdbsupport/new-op.cc has a comment about relying on the C++-17 <new> 11058 header. This patch implements the suggestion. 11059 11060 Approved-By: Pedro Alves <pedro@palves.net> 11061 110622023-11-29 Tom Tromey <tom@tromey.com> 11063 11064 Use try_emplace in index-write.c 11065 index-write.c has a comment indicating that C++17's try_emplace could 11066 be used. This patch makes the change. 11067 11068 Approved-By: Pedro Alves <pedro@palves.net> 11069 110702023-11-29 Tom Tromey <tom@tromey.com> 11071 11072 Enable some C++14 code in array-view.h 11073 This changes gdbsupport/array-view.h to enable some code that is 11074 C++14-specific. 11075 11076 Approved-By: Pedro Alves <pedro@palves.net> 11077 110782023-11-29 Tom Tromey <tom@tromey.com> 11079 11080 Switch to -Wimplicit-fallthrough=5 11081 This changes the various gdb-related directories to use 11082 -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute 11083 can be used in switches -- special 'fallthrough' comments will no 11084 longer be usable. 11085 11086 Approved-By: Pedro Alves <pedro@palves.net> 11087 110882023-11-29 Tom Tromey <tom@tromey.com> 11089 11090 Use C++17 [[fallthrough]] attribute 11091 This changes gdb to use the C++17 [[fallthrough]] attribute rather 11092 than special comments. 11093 11094 This was mostly done by script, but I neglected a few spellings and so 11095 also fixed it up by hand. 11096 11097 I suspect this fixes the bug mentioned below, by switching to a 11098 standard approach that, presumably, clang supports. 11099 11100 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 11101 Approved-By: John Baldwin <jhb@FreeBSD.org> 11102 Approved-By: Luis Machado <luis.machado@arm.com> 11103 Approved-By: Pedro Alves <pedro@palves.net> 11104 111052023-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 11106 11107 gprofng: support GNU option syntax in gp-display-html, plus various fixes 11108 This is a major update of gp-display-html. The option handling has been 11109 modified to support the GNU style long option syntax. Compatibility with 11110 the previous syntax has been preserved. If still used, a warning is issued. 11111 Through the --nowarnings option, this can be suppressed. 11112 In addition to this, various lay-out changes have been implemented. In 11113 particular to reduce the number of lines that extend beyond column 79. 11114 Several bugs have been fixed, for example in the handling of directory names. 11115 11116 gprofng/ChangeLog 11117 2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com> 11118 11119 * gp-display-html/gp-display-html.in: Change option syntax plus fixes. 11120 111212023-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 11122 11123 gprofng: updated man pages and user guide 11124 This is a major update of all the man pages. Bugs 30679 and 30895 are 11125 addressed. In addition to fixes for typos, the texts have been expanded 11126 and clarified, and line lengths no longer extend beyond column 79. In 11127 case of gp-display-html, the new option syntax is documented. The user 11128 guide has a new section on the gprofng GUI. 11129 11130 gprofng/ChangeLog 11131 2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com> 11132 11133 PR 30679 11134 PR 30895 11135 * doc/gp-archive.texi: Expand the description of the options. 11136 * doc/gp-collect-app.texi: Fix various typos and textual improvements. 11137 * doc/gp-display-html.texi: Cover the new GNU long option syntax. 11138 * doc/gp-display-src.texi: Fix various typos and textual improvements. 11139 * doc/gp-display-text.texi: Fix typos fixed and textual improvements. 11140 * doc/gp-macros.texi: Fix a bug in the vspace macro and add new macro. 11141 * doc/gprofng.texi: Cover the GPROFNG_SYSCONFDIR environment variable. 11142 * doc/gprofng_ug.texi: Fix various typos and textual improvements. 11143 * doc/version.texi: Adapt the date and version number. 11144 111452023-11-29 GDB Administrator <gdbadmin@sourceware.org> 11146 11147 Automatic date update in version.in 11148 111492023-11-28 Andrew Burgess <aburgess@redhat.com> 11150 11151 gdb/python: display errors from command completion 11152 This commit makes the gdb.Command.complete methods more verbose when 11153 it comes to error handling. 11154 11155 Previous to this commit if any commands implemented in Python 11156 implemented the complete method, and if there were any errors 11157 encountered when calling that complete method, then GDB would silently 11158 hide the error and continue as if there were no completions. 11159 11160 This makes is difficult to debug any errors encountered when writing 11161 completion methods, and encourages the idea that Python extensions can 11162 be broken, and GDB will just silently work around them. 11163 11164 I don't think this is a good idea. GDB should encourage extensions to 11165 be written correctly, and robustly, and one way in which GDB can (I 11166 think) support this, is by pointing out when an extension goes wrong. 11167 11168 In this commit I've gone through the Python command completion code, 11169 and added calls to gdbpy_print_stack() or gdbpy_print_stack_or_quit() 11170 in places where we were either clearing the Python error, or, in some 11171 cases, just not handling the error at all. 11172 11173 One thing I have not changed is in cmdpy_completer (py-cmd.c) where we 11174 process the list of completions returned from the Command.complete 11175 method; this routine includes a call to gdbpy_is_string to check a 11176 possible completion is a string, if not the completion is ignored. 11177 11178 I was tempted to remove this check, attempt to complete each result to 11179 a string, and display an error if the conversion fails. After all, 11180 returning anything but a string is surely a mistake by the extension 11181 author. 11182 11183 However, the docs clearly say that only strings within the returned 11184 list will be considered as completions. Anything else is ignored. As 11185 such, and to avoid (what I think is pretty unlikely) breakage of 11186 existing code, I've retained the gdbpy_is_string check. 11187 11188 After the gdbpy_is_string check we call python_string_to_host_string, 11189 if this call fails then I do now print the error, where before we 11190 ignored the error. I think this is OK; if GDB thinks something is a 11191 string, but still can't convert it to a string, then I think it's OK 11192 to display the error in that case. 11193 11194 Another case which I was a little unsure about was in 11195 cmdpy_completer_helper, and the call to PyObject_CallMethodObjArgs, 11196 which is when we actually call Command.complete. Previously, if this 11197 call resulted in an exception then we would ignore this and just 11198 pretend there were no completions. 11199 11200 Of all the changes, this is possibly the one with the biggest 11201 potential for breaking existing scripts, but also, is, I think, the 11202 most useful change. If the user code is wrong in some way, such that 11203 an exception is raised, then previously the user would have no obvious 11204 feedback about this breakage. Now GDB will print the exception for 11205 them, making it, I think, much easier to debug their extension. But, 11206 if there is user code in the wild that relies on raising an exception 11207 as a means to indicate there are no completions .... well, that code 11208 is going to break after this commit. I think we can live with this 11209 though, the exceptions means no completions thing was never documented 11210 behaviour. 11211 11212 I also added a new error() call if the PyObject_CallMethodObjArgs call 11213 raises an exception. This causes the completion mechanism within GDB 11214 to stop. Within GDB the completion code is called twice, the first 11215 time to compute the work break characters, and then a second time to 11216 compute the actual completions. 11217 11218 If PyObject_CallMethodObjArgs raises an exception when computing the 11219 word break character, and we print it by calling 11220 gdbpy_print_stack_or_quit(), but then carry on as if 11221 PyObject_CallMethodObjArgs had returns no completions, GDB will 11222 call the Python completion code again, which results in another call 11223 to PyObject_CallMethodObjArgs, which might raise the same exception 11224 again. This results in the Python exception being printed twice. 11225 11226 By throwing a C++ exception after the failed 11227 PyObject_CallMethodObjArgs call, the completion mechanism is aborted, 11228 and no completions are offered. But importantly, the Python exception 11229 is only printed once. I think this gives a much better user 11230 experience. 11231 11232 I've added some tests to cover this case, as I think this is the most 11233 likely case that a user will run into. 11234 11235 Approved-By: Tom Tromey <tom@tromey.com> 11236 112372023-11-28 Andrew Burgess <aburgess@redhat.com> 11238 11239 gdb/testsuite: improve test regexp in gdb_get_worker_threads 11240 I spotted I made a small mistake in this commit: 11241 11242 commit aff250145af6c7a8ea9332bc1306c1219f4a63db 11243 Date: Fri Nov 24 12:04:36 2023 +0000 11244 11245 gdb: generate gdb-index identically regardless of work thread count 11246 11247 In this commit I added a new proc in testsuite/lib/gdb.exp called 11248 gdb_get_worker_threads. This proc uses gdb_test_multiple with two 11249 possible patterns. One pattern is anchored with '^', while the other 11250 is missing the '^' which it could use. 11251 11252 This commit adds the missing '^'. 11253 112542023-11-28 Mike Frysinger <vapier@gentoo.org> 11255 11256 gnulib: mark configure +x 11257 112582023-11-28 Simon Marchi <simon.marchi@efficios.com> 11259 11260 gdb: fix call to breakpoint_inserted_here_p in darwin-nat.c 11261 Fixes this issue, introduced by f9582a22dba7 ("[gdb] Fix segfault in 11262 for_each_block, part 1"): 11263 11264 CXX darwin-nat.o 11265 /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1169:7: error: no matching function for call to 'breakpoint_inserted_here_p' 11266 if (breakpoint_inserted_here_p (inf->aspace, pc)) 11267 ^~~~~~~~~~~~~~~~~~~~~~~~~~ 11268 11269 Change-Id: I3bb6be75b650319f0fa1dbdceb379b18531da96c 11270 112712023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com> 11272 11273 gas: add NEWS entry for change of comment syntax in BPF assembler 11274 2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com> 11275 11276 * NEWS: Add entry about change of comment syntax in the BPF 11277 assembler. 11278 112792023-11-28 Tom Tromey <tromey@adacore.com> 11280 11281 Emit DAP "process" event 11282 DAP specifies a "process" event that is sent when a process is started 11283 or attached to. gdb was not emitting this (several DAP clients appear 11284 to ignore it entirely), but it looked easy and harmless to implement. 11285 11286 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473 11287 112882023-11-28 Tom de Vries <tdevries@suse.de> 11289 11290 [gdb/tui] Use const std::string for string literals in tui-stack.c 11291 I noticed in gdb/tui/tui-stack.c a source-level micro-optimization where 11292 strlen with a string literal argument: 11293 ... 11294 strlen ("bla") 11295 ... 11296 is replaced with sizeof: 11297 ... 11298 sizeof ("bla") - 1 11299 ... 11300 11301 The benefit of this is that the optimization is also done at O0, but the 11302 drawback is that it makes the expression harder to read. 11303 11304 Use const std::string to encapsulate the string literals, and use 11305 std::string::size () instead. 11306 11307 I tried making the string names (PROC_PREFIX, LINE_PREFIX, PC_PREFIX and 11308 SINGLE_KEY) lower-case, but that clashed with a pre-existing pc_prefix, so 11309 I've left them upper-case. 11310 11311 Tested on x86_64-linux. 11312 11313 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 11314 113152023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com> 11316 11317 sim: bpf: do not use semicolon to begin comments 11318 The BPF assembler has been updated to follow the clang convention in 11319 the interpretation of semicolons: they separate statements and 11320 directives, and do not start line comments. 11321 113222023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com> 11323 11324 gas: change meaning of ; in the BPF assembler 11325 The BPF assembler in clang uses semi-colon (;) to separate statements, 11326 not to be begin line comments. This patch adapts the GNU assembler 11327 accordingly. 11328 11329 Testsuite and documentation updated accordingly. 11330 11331 2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com> 11332 11333 * config/tc-bpf.c: Semicolon does not start a comment, but 11334 separates multiple commands on a single line. 11335 * testsuite/gas/bpf/alu-pseudoc.s: Adapt test accordingly. 11336 * testsuite/gas/bpf/spacing-pseudoc.s: Likewise. 11337 * testsuite/gas/bpf/offset16-overflow.s: Likewise. 11338 * testsuite/gas/bpf/jump-relax-jump.s: Likewise. 11339 * testsuite/gas/bpf/jump-relax-ja.s: Likewise. 11340 * testsuite/gas/bpf/imm32-overflow.s: Likewise. 11341 * testsuite/gas/bpf/disp32-overflow.s: Likewise. 11342 * testsuite/gas/bpf/disp16-overflow-relax.s: Likewise. 11343 * testsuite/gas/bpf/disp16-overflow.s: Likewise. 11344 * doc/c-bpf.texi (BPF Special Characters): Update. 11345 113462023-11-28 Jakub Jelinek <jakub@redhat.com> 11347 11348 libiberty, ld: Use x86 HW optimized sha1 11349 The following patch attempts to use x86 SHA ISA if available to speed 11350 up in my testing about 2.5x sha1 build-id processing (in my case on 11351 AMD Ryzen 5 3600) while producing the same result. 11352 I believe AArch64 has similar HW acceleration for SHA1, perhaps it 11353 could be added similarly. 11354 11355 Note, seems lld uses BLAKE3 rather than md5/sha1. I think it would be 11356 a bad idea to lie to users, if they choose --buildid=sha1, we should 11357 be using SHA1, not some other checksum, but perhaps we could add some other 11358 --buildid= styles and perhaps make one of the new the default. 11359 11360 Tested on x86_64-linux, both on Intel i9-7960X (which doesn't have 11361 sha_ni ISA support) without/with the patch and on AMD Ryzen 5 3600 11362 (which does have it) without/with the patch. 11363 11364 2023-11-28 Jakub Jelinek <jakub@redhat.com> 11365 11366 include/ 11367 * sha1.h (sha1_process_bytes_fn): New typedef. 11368 (sha1_choose_process_bytes): Declare. 11369 libiberty/ 11370 * configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check. 11371 * sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h 11372 and cpuid.h. 11373 (sha1_hw_process_bytes, sha1_hw_process_block, 11374 sha1_choose_process_bytes): New functions. 11375 * config.in: Regenerated. 11376 * configure: Regenerated. 11377 ld/ 11378 * ldbuildid.c (generate_build_id): Use sha1_choose_process_bytes () 11379 instead of &sha1_process_bytes. 11380 113812023-11-28 Andrew Burgess <aburgess@redhat.com> 11382 11383 gdb/testsuite: add a new check-all-boards target 11384 The make-check-all.sh script (gdb/testsuite/make-check-all.sh) is 11385 great, it makes it super easy to run some test(s) using all the 11386 available board files. 11387 11388 This commit aims to make this script even easier to access by adding a 11389 check-all-boards target to the GDB Makefile. This new target checks 11390 for (and requires) a number of environment variables, so the target 11391 should be used like this: 11392 11393 make check-all-boards GDB_TARGET_USERNAME=remote-target \ 11394 GDB_HOST_USERNAME=remote-host \ 11395 TESTS="gdb.base/break.exp" 11396 11397 Where GDB_TARGET_USERNAME and GDB_HOST_USERNAME are the user names 11398 that should be passed to the make-check-all.sh --target-user and 11399 --host-user command line options respectively. 11400 11401 My personal intention is to set these variables in my environment, so 11402 all I'll need to do is: 11403 11404 make check-all-boards TESTS="gdb.base/break.exp" 11405 11406 The make rule always passes --keep-results to the make-check-all.sh 11407 script, as I find that the most useful. It's super frustrating to run 11408 the tests and realise you forgot that option and the results have been 11409 discarded. 11410 114112023-11-28 Andrew Burgess <aburgess@redhat.com> 11412 11413 gdb/testsuite: log 'make check' command in make-check-all.sh 11414 I have been making more use of the make-check-all.sh script to run 11415 tests against all boards. 11416 11417 But one thing is pretty annoying. When a test fails on some random 11418 board, I have to run make-check-all.sh with --verbose and --dry-run in 11419 order to see what RUNTESTFLAGS I should be using. 11420 11421 I always run with --keep-results on, so, in this commit, I propose 11422 that, when --keep-results is on the 'make check' command will be 11423 written out to a file within the stored results directory, like: 11424 11425 check-all/BOARD_NAME/make-check.sh 11426 11427 then, if I want to rerun a test, I can just: 11428 11429 sh check-all/BOARD_NAME/make-check.sh 11430 11431 and the test will be re-run for me. 11432 114332023-11-28 Andrew Burgess <aburgess@redhat.com> 11434 11435 gdb: generate dwarf-5 index identically as worker-thread count changes 11436 Similar to the previous commit, this commit ensures that the dwarf-5 11437 index files are generated identically as the number of worker-threads 11438 changes. 11439 11440 Building the dwarf-5 index makes use of a closed hash table, the 11441 bucket_hash local within debug_names::build(). Entries are added to 11442 bucket_hash from m_name_to_value_set, which, in turn, is populated 11443 by calls to debug_names::insert() in write_debug_names. The insert 11444 calls are ordered based on the entries within the cooked_index, and 11445 the ordering within cooked_index depends on the number of worker 11446 threads that GDB is using. 11447 11448 My proposal is to sort each chain within the bucket_hash closed hash 11449 table prior to using this to build the dwarf-5 index. 11450 11451 The buckets within bucket_hash will always have the same ordering (for 11452 a given GDB build with a given executable), and by sorting the chains 11453 within each bucket, we can be sure that GDB will see each entry in a 11454 deterministic order. 11455 11456 I've extended the index creation test to cover this case. 11457 11458 Approved-By: Tom Tromey <tom@tromey.com> 11459 114602023-11-28 Andrew Burgess <aburgess@redhat.com> 11461 11462 gdb: generate gdb-index identically regardless of work thread count 11463 It was observed that changing the number of worker threads that GDB 11464 uses (maintenance set worker-threads NUM) would have an impact on the 11465 layout of the generated gdb-index. 11466 11467 The cause seems to be how the CU are distributed between threads, and 11468 then symbols that appear in multiple CU can be encountered earlier or 11469 later depending on whether a particular CU moves between threads. 11470 11471 I certainly found this behaviour was reproducible when generating an 11472 index for GDB itself, like: 11473 11474 gdb -q -nx -nh -batch \ 11475 -eiex 'maint set worker-threads NUM' \ 11476 -ex 'save gdb-index /tmp/' 11477 11478 And then setting different values for NUM will change the generated 11479 index. 11480 11481 Now, the question is: does this matter? 11482 11483 I would like to suggest that yes, this does matter. At Red Hat we 11484 generate a gdb-index as part of the build process, and we would 11485 ideally like to have reproducible builds: for the same source, 11486 compiled with the same tool-chain, we should get the exact same output 11487 binary. And we do .... except for the index. 11488 11489 Now we could simply force GDB to only use a single worker thread when 11490 we build the index, but, I don't think the idea of reproducible builds 11491 is that strange, so I think we should ensure that our generated 11492 indexes are always reproducible. 11493 11494 To achieve this, I propose that we add an extra step when building the 11495 gdb-index file. After constructing the initial symbol hash table 11496 contents, we will pull all the symbols out of the hash, sort them, 11497 then re-insert them in sorted order. This will ensure that the 11498 structure of the generated hash will remain consistent (given the same 11499 set of symbols). 11500 11501 I've extended the existing index-file test to check that the generated 11502 index doesn't change if we adjust the number of worker threads used. 11503 Given that this test is already rather slow, I've only made one change 11504 to the worker-thread count. Maybe this test should be changed to use 11505 a smaller binary, which is quicker to load, and for which we could 11506 then try many different worker thread counts. 11507 11508 Approved-By: Tom Tromey <tom@tromey.com> 11509 115102023-11-28 Andrew Burgess <aburgess@redhat.com> 11511 11512 gdb: C++-ify mapped_symtab from dwarf2/index-write.c 11513 Make static the functions add_index_entry, find_slot, and hash_expand, 11514 member functions of the mapped_symtab class. 11515 11516 Fold an additional snippet of code from write_gdbindex into 11517 mapped_symtab::minimize, this code relates to minimisation, so this 11518 seems like a good home for it. 11519 11520 Make the n_elements, data, and m_string_obstack member variables of 11521 mapped_symtab private. Provide a new obstack() member function to 11522 provide access to the obstack when needed, and also add member 11523 functions begin(), end(), cbegin(), and cend() so that the 11524 mapped_symtab class can be treated like a contained and iterated 11525 over. 11526 11527 I've also taken this opportunity to split out the logic for whether 11528 the hash table (m_data) needs expanding, this is the new function 11529 hash_needs_expanding. This will be useful in a later commit. 11530 11531 There should be no user visible changes after this commit. 11532 11533 Approved-By: Tom Tromey <tom@tromey.com> 11534 115352023-11-28 Andrew Burgess <aburgess@redhat.com> 11536 11537 gdb: reduce size of generated gdb-index file 11538 I noticed in passing that out algorithm for generating the gdb-index 11539 file is incorrect. When building the hash table in add_index_entry we 11540 count every incoming entry rehash when the number of entries gets too 11541 large. However, some of the incoming entries will be duplicates, 11542 which don't actually result in new items being added to the hash 11543 table. 11544 11545 As a result, we grow the gdb-index hash table far too often. 11546 11547 With an unmodified GDB, generating a gdb-index for GDB, I see a file 11548 size of 90M, with a hash usage (in the generated index file) of just 11549 2.6%. 11550 11551 With a patched GDB, generating a gdb-index for the _same_ GDB binary, 11552 I now see a gdb-index file size of 30M, with a hash usage of 41.9%. 11553 11554 This is a 67% reduction in gdb-index file size. 11555 11556 Obviously, not every gdb-index file is going to see such big savings, 11557 however, the larger a program, and the more symbols that are 11558 duplicated between compilation units, the more GDB would over count, 11559 and so, over-grow the index. 11560 11561 The gdb-index hash table we create has a minimum size of 1024, and 11562 then we grow the hash when it is 75% full, doubling the hash table at 11563 that time. Given this, then we expect that either: 11564 11565 a. The hash table is size 1024, and less than 75% full, or 11566 b. The hash table is between 37.5% and 75% full. 11567 11568 I've include a test that checks some of these constraints -- I've not 11569 bothered to check the upper limit, and over full hash table isn't 11570 really a problem here, but if the fill percentage is less than 37.5% 11571 then this indicates that we've done something wrong (obviously, I also 11572 check for the 1024 minimum size). 11573 11574 Approved-By: Tom Tromey <tom@tromey.com> 11575 115762023-11-28 Andrew Burgess <aburgess@redhat.com> 11577 11578 gdb/testsuite: small refactor in selftest-support.exp 11579 Split out the code that makes a copy of the GDB executable ready for 11580 self testing into a new proc. A later commit in this series wants to 11581 load the GDB executable into GDB (for creating an on-disk debug 11582 index), but doesn't need to make use of the full do_self_tests proc. 11583 11584 There should be no changes in what is tested after this commit. 11585 11586 Approved-By: Tom Tromey <tom@tromey.com> 11587 115882023-11-28 Andrew Burgess <aburgess@redhat.com> 11589 11590 gdb: option completion for 'save gdb-index' command 11591 Add proper support for option completion to the 'save gdb-index' 11592 command. Update save_gdb_index_command function to make use of the 11593 new option_def data structures for parsing the '-dwarf-5' option. 11594 11595 Approved-By: Tom Tromey <tom@tromey.com> 11596 115972023-11-28 Andrew Burgess <aburgess@redhat.com> 11598 11599 gdb: allow use of ~ in 'save gdb-index' command 11600 Add a call to gdb_tilde_expand in the save_gdb_index_command function, 11601 this means that we can now do: 11602 11603 (gdb) save gdb-index ~/blah/ 11604 11605 Previous this wouldn't work. 11606 11607 Approved-By: Tom Tromey <tom@tromey.com> 11608 116092023-11-28 Nick Clifton <nickc@redhat.com> 11610 11611 New Romanian translation for ld 11612 116132023-11-28 Tom de Vries <tdevries@suse.de> 11614 11615 [gdb] Fix segfault in for_each_block, part 2 11616 The previous commit describes PR gdb/30547, a segfault when running test-case 11617 gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x). 11618 11619 The root cause for the segmentation fault is that linux_is_uclinux gives an 11620 incorrect result: it returns true instead of false. 11621 11622 So, why does linux_is_uclinux: 11623 ... 11624 int 11625 linux_is_uclinux (void) 11626 { 11627 CORE_ADDR dummy; 11628 11629 return (target_auxv_search (AT_NULL, &dummy) > 0 11630 && target_auxv_search (AT_PAGESZ, &dummy) == 0); 11631 ... 11632 return true? 11633 11634 This is because ppc_linux_target_wordsize returns 4 instead of 8, causing 11635 ppc_linux_nat_target::auxv_parse to misinterpret the auxv vector. 11636 11637 So, why does ppc_linux_target_wordsize: 11638 ... 11639 int 11640 ppc_linux_target_wordsize (int tid) 11641 { 11642 int wordsize = 4; 11643 11644 /* Check for 64-bit inferior process. This is the case when the host is 11645 64-bit, and in addition the top bit of the MSR register is set. */ 11646 long msr; 11647 11648 errno = 0; 11649 msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0); 11650 if (errno == 0 && ppc64_64bit_inferior_p (msr)) 11651 wordsize = 8; 11652 11653 return wordsize; 11654 } 11655 ... 11656 return 4? 11657 11658 Specifically, we get this result because because tid == 0, so we get 11659 errno == ESRCH. 11660 11661 The tid == 0 is caused by the switch_to_no_thread in 11662 handle_vfork_child_exec_or_exit: 11663 ... 11664 /* Switch to no-thread while running clone_program_space, so 11665 that clone_program_space doesn't want to read the 11666 selected frame of a dead process. */ 11667 scoped_restore_current_thread restore_thread; 11668 switch_to_no_thread (); 11669 11670 inf->pspace = new program_space (maybe_new_address_space ()); 11671 ... 11672 but moving the maybe_new_address_space call to before that gives us the 11673 same result. The tid is no longer 0, but we still get ESRCH because the 11674 thread has exited. 11675 11676 Fix this in handle_vfork_child_exec_or_exit by doing the 11677 maybe_new_address_space call in the context of the vfork parent. 11678 11679 Tested on top of trunk on x86_64-linux and ppc64le-linux. 11680 Tested on top of gdb-14-branch on ppc64-linux. 11681 11682 Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> 11683 11684 PR gdb/30547 11685 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547 11686 116872023-11-28 Tom de Vries <tdevries@suse.de> 11688 11689 [gdb] Fix segfault in for_each_block, part 1 11690 When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise 11691 on s390x), I run into: 11692 ... 11693 (gdb) PASS: gdb.base/vfork-follow-parent.exp: \ 11694 exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \ 11695 resolution_method=schedule-multiple: print unblock_parent = 1 11696 continue^M 11697 Continuing.^M 11698 Reading symbols from vfork-follow-parent-exit...^M 11699 ^M 11700 ^M 11701 Fatal signal: Segmentation fault^M 11702 ----- Backtrace -----^M 11703 0x1027d3e7 gdb_internal_backtrace_1^M 11704 src/gdb/bt-utils.c:122^M 11705 0x1027d54f _Z22gdb_internal_backtracev^M 11706 src/gdb/bt-utils.c:168^M 11707 0x1057643f handle_fatal_signal^M 11708 src/gdb/event-top.c:889^M 11709 0x10576677 handle_sigsegv^M 11710 src/gdb/event-top.c:962^M 11711 0x3fffa7610477 ???^M 11712 0x103f2144 for_each_block^M 11713 src/gdb/dcache.c:199^M 11714 0x103f235b _Z17dcache_invalidateP13dcache_struct^M 11715 src/gdb/dcache.c:251^M 11716 0x10bde8c7 _Z24target_dcache_invalidatev^M 11717 src/gdb/target-dcache.c:50^M 11718 ... 11719 or similar. 11720 11721 The root cause for the segmentation fault is that linux_is_uclinux gives an 11722 incorrect result: it should always return false, given that we're running on a 11723 regular linux system, but instead it returns first true, then false. 11724 11725 In more detail, the segmentation fault happens as follows: 11726 - a program space with an address space is created 11727 - a second program space is about to be created. maybe_new_address_space 11728 is called, and because linux_is_uclinux returns true, maybe_new_address_space 11729 returns false, and no new address space is created 11730 - a second program space with the same address space is created 11731 - a program space is deleted. Because linux_is_uclinux now returns false, 11732 gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns 11733 false, and the address space is deleted 11734 - when gdb uses the address space of the remaining program space, we run into 11735 the segfault, because the address space is deleted. 11736 11737 Hardcoding linux_is_uclinux to false makes the test-case pass. 11738 11739 We leave addressing the root cause for the following commit in this series. 11740 11741 For now, prevent the segmentation fault by making the address space a refcounted 11742 object. 11743 11744 This was already suggested here [1]: 11745 ... 11746 A better solution might be to have the address spaces be reference counted 11747 ... 11748 11749 Tested on top of trunk on x86_64-linux and ppc64le-linux. 11750 Tested on top of gdb-14-branch on ppc64-linux. 11751 11752 Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> 11753 11754 PR gdb/30547 11755 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547 11756 11757 [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html 11758 117592023-11-28 Haochen Jiang <haochen.jiang@intel.com> 11760 11761 testsuite: Clean up .allow_index_reg in i386 tests 11762 gas/ChangeLog: 11763 11764 * testsuite/gas/i386/adx.s: Remove .allow_index_reg. 11765 * testsuite/gas/i386/amx-complex-inval.l: Ditto. 11766 * testsuite/gas/i386/amx-complex-inval.s: Ditto. 11767 * testsuite/gas/i386/avx-ifma.s: Ditto. 11768 * testsuite/gas/i386/avx-ne-convert.s: Ditto. 11769 * testsuite/gas/i386/avx-scalar-2.s: Ditto. 11770 * testsuite/gas/i386/avx-vnni-int8.s: Ditto. 11771 * testsuite/gas/i386/avx-vnni.s: Ditto. 11772 * testsuite/gas/i386/avx-wig.s: Ditto. 11773 * testsuite/gas/i386/avx2-wig.s: Ditto. 11774 * testsuite/gas/i386/avx2.s: Ditto. 11775 * testsuite/gas/i386/avx256int.s: Ditto. 11776 * testsuite/gas/i386/avx512_4fmaps.s: Ditto. 11777 * testsuite/gas/i386/avx512_4vnniw.s: Ditto. 11778 * testsuite/gas/i386/avx512_bf16.s: Ditto. 11779 * testsuite/gas/i386/avx512_bf16_vl-inval.l: Ditto. 11780 * testsuite/gas/i386/avx512_bf16_vl-inval.s: Ditto. 11781 * testsuite/gas/i386/avx512_bf16_vl.s: Ditto. 11782 * testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto. 11783 * testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto. 11784 * testsuite/gas/i386/avx512_fp16.s: Ditto. 11785 * testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto. 11786 * testsuite/gas/i386/avx512_fp16_vl.s: Ditto. 11787 * testsuite/gas/i386/avx512_vpopcntdq.s: Ditto. 11788 * testsuite/gas/i386/avx512bitalg.s: Ditto. 11789 * testsuite/gas/i386/avx512bitalg_vl.s: Ditto. 11790 * testsuite/gas/i386/avx512bw-opts.s: Ditto. 11791 * testsuite/gas/i386/avx512bw-wig.s: Ditto. 11792 * testsuite/gas/i386/avx512bw.s: Ditto. 11793 * testsuite/gas/i386/avx512bw_vl-opts.s: Ditto. 11794 * testsuite/gas/i386/avx512bw_vl-wig.s: Ditto. 11795 * testsuite/gas/i386/avx512bw_vl.s: Ditto. 11796 * testsuite/gas/i386/avx512cd.s: Ditto. 11797 * testsuite/gas/i386/avx512cd_vl.s: Ditto. 11798 * testsuite/gas/i386/avx512dq-rcig.s: Ditto. 11799 * testsuite/gas/i386/avx512dq.s: Ditto. 11800 * testsuite/gas/i386/avx512dq_vl.s: Ditto. 11801 * testsuite/gas/i386/avx512er-rcig.s: Ditto. 11802 * testsuite/gas/i386/avx512er.s: Ditto. 11803 * testsuite/gas/i386/avx512f-opts.s: Ditto. 11804 * testsuite/gas/i386/avx512f-rcig.s: Ditto. 11805 * testsuite/gas/i386/avx512f.s: Ditto. 11806 * testsuite/gas/i386/avx512f_gfni.s: Ditto. 11807 * testsuite/gas/i386/avx512f_vaes.s: Ditto. 11808 * testsuite/gas/i386/avx512f_vl-opts.s: Ditto. 11809 * testsuite/gas/i386/avx512f_vl-wig.s: Ditto. 11810 * testsuite/gas/i386/avx512f_vl.s: Ditto. 11811 * testsuite/gas/i386/avx512f_vpclmulqdq.s: Ditto. 11812 * testsuite/gas/i386/avx512ifma.s: Ditto. 11813 * testsuite/gas/i386/avx512ifma_vl.s: Ditto. 11814 * testsuite/gas/i386/avx512pf.s: Ditto. 11815 * testsuite/gas/i386/avx512vbmi.s: Ditto. 11816 * testsuite/gas/i386/avx512vbmi2.s: Ditto. 11817 * testsuite/gas/i386/avx512vbmi2_vl.s: Ditto. 11818 * testsuite/gas/i386/avx512vbmi_vl.s: Ditto. 11819 * testsuite/gas/i386/avx512vl_gfni.s: Ditto. 11820 * testsuite/gas/i386/avx512vl_vaes.s: Ditto. 11821 * testsuite/gas/i386/avx512vl_vpclmulqdq.s: Ditto. 11822 * testsuite/gas/i386/avx512vnni.s: Ditto. 11823 * testsuite/gas/i386/avx512vnni_vl.s: Ditto. 11824 * testsuite/gas/i386/bmi.s: Ditto. 11825 * testsuite/gas/i386/bmi2.s: Ditto. 11826 * testsuite/gas/i386/cldemote.s: Ditto. 11827 * testsuite/gas/i386/clflushopt.s: Ditto. 11828 * testsuite/gas/i386/clwb.s: Ditto. 11829 * testsuite/gas/i386/cmpccxadd-inval.l: Ditto. 11830 * testsuite/gas/i386/cmpccxadd-inval.s: Ditto. 11831 * testsuite/gas/i386/enqcmd-inval.l: Ditto. 11832 * testsuite/gas/i386/enqcmd-inval.s: Ditto. 11833 * testsuite/gas/i386/enqcmd.s: Ditto. 11834 * testsuite/gas/i386/evex-lig-2.s: Ditto. 11835 * testsuite/gas/i386/evex-lig.s: Ditto. 11836 * testsuite/gas/i386/evex-wig.s: Ditto. 11837 * testsuite/gas/i386/evex.s: Ditto. 11838 * testsuite/gas/i386/fma-scalar.s: Ditto. 11839 * testsuite/gas/i386/fma.s: Ditto. 11840 * testsuite/gas/i386/fma4.s: Ditto. 11841 * testsuite/gas/i386/gfni.s: Ditto. 11842 * testsuite/gas/i386/hle.s: Ditto. 11843 * testsuite/gas/i386/ilp32/enqcmd.s: Ditto. 11844 * testsuite/gas/i386/ilp32/movdir.s: Ditto. 11845 * testsuite/gas/i386/lwp.s: Ditto. 11846 * testsuite/gas/i386/movdir.s: Ditto. 11847 * testsuite/gas/i386/movdir64b-reg.l: Ditto. 11848 * testsuite/gas/i386/movdir64b-reg.s: Ditto. 11849 * testsuite/gas/i386/mpx-inval-1.l: Ditto. 11850 * testsuite/gas/i386/mpx-inval-1.s: Ditto. 11851 * testsuite/gas/i386/mpx.s: Ditto. 11852 * testsuite/gas/i386/msrlist-inval.l: Ditto. 11853 * testsuite/gas/i386/msrlist-inval.s: Ditto. 11854 * testsuite/gas/i386/notrack.s: Ditto. 11855 * testsuite/gas/i386/notrackbad.l: Ditto. 11856 * testsuite/gas/i386/notrackbad.s: Ditto. 11857 * testsuite/gas/i386/optimize-1.s: Ditto. 11858 * testsuite/gas/i386/optimize-2.s: Ditto. 11859 * testsuite/gas/i386/optimize-3.s: Ditto. 11860 * testsuite/gas/i386/optimize-6.s: Ditto. 11861 * testsuite/gas/i386/optimize-6a.l: Ditto. 11862 * testsuite/gas/i386/optimize-7.l: Ditto. 11863 * testsuite/gas/i386/optimize-7.s: Ditto. 11864 * testsuite/gas/i386/opts.s: Ditto. 11865 * testsuite/gas/i386/prefetchwt1.s: Ditto. 11866 * testsuite/gas/i386/raoint.s: Ditto. 11867 * testsuite/gas/i386/sha.s: Ditto. 11868 * testsuite/gas/i386/sse2avx.s: Ditto. 11869 * testsuite/gas/i386/tbm.s: Ditto. 11870 * testsuite/gas/i386/vaes.s: Ditto. 11871 * testsuite/gas/i386/vex-lig-2.s: Ditto. 11872 * testsuite/gas/i386/vp2intersect-inval-bcast.l: Ditto. 11873 * testsuite/gas/i386/vp2intersect-inval-bcast.s: Ditto. 11874 * testsuite/gas/i386/vpclmulqdq.s: Ditto. 11875 * testsuite/gas/i386/x86-64-adx.s: Ditto. 11876 * testsuite/gas/i386/x86-64-amx-complex.s: Ditto. 11877 * testsuite/gas/i386/x86-64-amx-fp16.s: Ditto. 11878 * testsuite/gas/i386/x86-64-avx-ifma.s: Ditto. 11879 * testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto. 11880 * testsuite/gas/i386/x86-64-avx-scalar-2.s: Ditto. 11881 * testsuite/gas/i386/x86-64-avx-swap.s: Ditto. 11882 * testsuite/gas/i386/x86-64-avx-vnni-int8.s: Ditto. 11883 * testsuite/gas/i386/x86-64-avx-vnni.s: Ditto. 11884 * testsuite/gas/i386/x86-64-avx-wig.s: Ditto. 11885 * testsuite/gas/i386/x86-64-avx2-wig.s: Ditto. 11886 * testsuite/gas/i386/x86-64-avx2.s: Ditto. 11887 * testsuite/gas/i386/x86-64-avx256int.s: Ditto. 11888 * testsuite/gas/i386/x86-64-avx512_4fmaps.s: Ditto. 11889 * testsuite/gas/i386/x86-64-avx512_4vnniw.s: Ditto. 11890 * testsuite/gas/i386/x86-64-avx512_bf16.s: Ditto. 11891 * testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.l: Ditto. 11892 * testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.s: Ditto. 11893 * testsuite/gas/i386/x86-64-avx512_bf16_vl.s: Ditto. 11894 * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto. 11895 * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto. 11896 * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto. 11897 * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto. 11898 * testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto. 11899 * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto. 11900 * testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto. 11901 * testsuite/gas/i386/x86-64-avx512_vpopcntdq.s: Ditto. 11902 * testsuite/gas/i386/x86-64-avx512bitalg.s: Ditto. 11903 * testsuite/gas/i386/x86-64-avx512bitalg_vl.s: Ditto. 11904 * testsuite/gas/i386/x86-64-avx512bw-opts.s: Ditto. 11905 * testsuite/gas/i386/x86-64-avx512bw-wig.s: Ditto. 11906 * testsuite/gas/i386/x86-64-avx512bw.s: Ditto. 11907 * testsuite/gas/i386/x86-64-avx512bw_vl-opts.s: Ditto. 11908 * testsuite/gas/i386/x86-64-avx512bw_vl-wig.s: Ditto. 11909 * testsuite/gas/i386/x86-64-avx512bw_vl.s: Ditto. 11910 * testsuite/gas/i386/x86-64-avx512cd.s: Ditto. 11911 * testsuite/gas/i386/x86-64-avx512cd_vl.s: Ditto. 11912 * testsuite/gas/i386/x86-64-avx512dq-rcig.s: Ditto. 11913 * testsuite/gas/i386/x86-64-avx512dq.s: Ditto. 11914 * testsuite/gas/i386/x86-64-avx512dq_vl.s: Ditto. 11915 * testsuite/gas/i386/x86-64-avx512er-rcig.s: Ditto. 11916 * testsuite/gas/i386/x86-64-avx512er.s: Ditto. 11917 * testsuite/gas/i386/x86-64-avx512f-opts.s: Ditto. 11918 * testsuite/gas/i386/x86-64-avx512f-rcig.s: Ditto. 11919 * testsuite/gas/i386/x86-64-avx512f.s: Ditto. 11920 * testsuite/gas/i386/x86-64-avx512f_gfni.s: Ditto. 11921 * testsuite/gas/i386/x86-64-avx512f_vaes.s: Ditto. 11922 * testsuite/gas/i386/x86-64-avx512f_vl-opts.s: Ditto. 11923 * testsuite/gas/i386/x86-64-avx512f_vl-wig.s: Ditto. 11924 * testsuite/gas/i386/x86-64-avx512f_vl.s: Ditto. 11925 * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.s: Ditto. 11926 * testsuite/gas/i386/x86-64-avx512ifma.s: Ditto. 11927 * testsuite/gas/i386/x86-64-avx512ifma_vl.s: Ditto. 11928 * testsuite/gas/i386/x86-64-avx512pf.s: Ditto. 11929 * testsuite/gas/i386/x86-64-avx512vbmi.s: Ditto. 11930 * testsuite/gas/i386/x86-64-avx512vbmi2.s: Ditto. 11931 * testsuite/gas/i386/x86-64-avx512vbmi2_vl.s: Ditto. 11932 * testsuite/gas/i386/x86-64-avx512vbmi_vl.s: Ditto. 11933 * testsuite/gas/i386/x86-64-avx512vl_gfni.s: Ditto. 11934 * testsuite/gas/i386/x86-64-avx512vl_vaes.s: Ditto. 11935 * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.s: Ditto. 11936 * testsuite/gas/i386/x86-64-avx512vnni.s: Ditto. 11937 * testsuite/gas/i386/x86-64-avx512vnni_vl.s: Ditto. 11938 * testsuite/gas/i386/x86-64-avx_gfni.s: Ditto. 11939 * testsuite/gas/i386/x86-64-bmi.s: Ditto. 11940 * testsuite/gas/i386/x86-64-bmi2.s: Ditto. 11941 * testsuite/gas/i386/x86-64-cldemote.s: Ditto. 11942 * testsuite/gas/i386/x86-64-clflushopt.s: Ditto. 11943 * testsuite/gas/i386/x86-64-clwb.s: Ditto. 11944 * testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto. 11945 * testsuite/gas/i386/x86-64-enqcmd-inval.l: Ditto. 11946 * testsuite/gas/i386/x86-64-enqcmd-inval.s: Ditto. 11947 * testsuite/gas/i386/x86-64-enqcmd.s: Ditto. 11948 * testsuite/gas/i386/x86-64-evex-lig-2.s: Ditto. 11949 * testsuite/gas/i386/x86-64-evex-lig.s: Ditto. 11950 * testsuite/gas/i386/x86-64-evex-wig.s: Ditto. 11951 * testsuite/gas/i386/x86-64-evex-wig2.s: Ditto. 11952 * testsuite/gas/i386/x86-64-fma-scalar.s: Ditto. 11953 * testsuite/gas/i386/x86-64-fma.s: Ditto. 11954 * testsuite/gas/i386/x86-64-fma4.s: Ditto. 11955 * testsuite/gas/i386/x86-64-fred.s: Ditto. 11956 * testsuite/gas/i386/x86-64-gfni.s: Ditto. 11957 * testsuite/gas/i386/x86-64-hle.s: Ditto. 11958 * testsuite/gas/i386/x86-64-lkgs.s: Ditto. 11959 * testsuite/gas/i386/x86-64-lwp.s: Ditto. 11960 * testsuite/gas/i386/x86-64-movdir.s: Ditto. 11961 * testsuite/gas/i386/x86-64-movdir64b-reg.l: Ditto. 11962 * testsuite/gas/i386/x86-64-movdir64b-reg.s: Ditto. 11963 * testsuite/gas/i386/x86-64-mpx-inval-1.l: Ditto. 11964 * testsuite/gas/i386/x86-64-mpx-inval-1.s: Ditto. 11965 * testsuite/gas/i386/x86-64-mpx-inval-2.l: Ditto. 11966 * testsuite/gas/i386/x86-64-mpx-inval-2.s: Ditto. 11967 * testsuite/gas/i386/x86-64-mpx.s: Ditto. 11968 * testsuite/gas/i386/x86-64-notrack.s: Ditto. 11969 * testsuite/gas/i386/x86-64-notrackbad.l: Ditto. 11970 * testsuite/gas/i386/x86-64-notrackbad.s: Ditto. 11971 * testsuite/gas/i386/x86-64-optimize-1.s: Ditto. 11972 * testsuite/gas/i386/x86-64-optimize-2.s: Ditto. 11973 * testsuite/gas/i386/x86-64-optimize-3.s: Ditto. 11974 * testsuite/gas/i386/x86-64-optimize-4.s: Ditto. 11975 * testsuite/gas/i386/x86-64-optimize-7.s: Ditto. 11976 * testsuite/gas/i386/x86-64-optimize-7a.l: Ditto. 11977 * testsuite/gas/i386/x86-64-optimize-8.l: Ditto. 11978 * testsuite/gas/i386/x86-64-optimize-8.s: Ditto. 11979 * testsuite/gas/i386/x86-64-opts.s: Ditto. 11980 * testsuite/gas/i386/x86-64-prefetchi-warn.s: Ditto. 11981 * testsuite/gas/i386/x86-64-prefetchi.s: Ditto. 11982 * testsuite/gas/i386/x86-64-prefetchwt1.s: Ditto. 11983 * testsuite/gas/i386/x86-64-raoint.s: Ditto. 11984 * testsuite/gas/i386/x86-64-sha.s: Ditto. 11985 * testsuite/gas/i386/x86-64-sse2avx.s: Ditto. 11986 * testsuite/gas/i386/x86-64-tbm.s: Ditto. 11987 * testsuite/gas/i386/x86-64-vaes.s: Ditto. 11988 * testsuite/gas/i386/x86-64-vex-lig-2.s: Ditto. 11989 * testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.l: Ditto. 11990 * testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.s: Ditto. 11991 * testsuite/gas/i386/x86-64-vpclmulqdq.s: Ditto. 11992 * testsuite/gas/i386/x86-64-xop.s: Ditto. 11993 * testsuite/gas/i386/x86-64-xsavec.s: Ditto. 11994 * testsuite/gas/i386/x86-64-xsaves.s: Ditto. 11995 * testsuite/gas/i386/xop.s: Ditto. 11996 * testsuite/gas/i386/xsavec.s: Ditto. 11997 * testsuite/gas/i386/xsaves.s: Ditto. 11998 119992023-11-28 Haochen Jiang <haochen.jiang@intel.com> 12000 12001 testsuite: Clean up #as in dump file for i386 tests 12002 gas/ChangeLog: 12003 12004 * testsuite/gas/i386/avx-gather-intel.d: Remove unused #as. 12005 * testsuite/gas/i386/avx-gather.d: Ditto. 12006 * testsuite/gas/i386/avx-ifma-intel.d: Ditto. 12007 * testsuite/gas/i386/avx-ifma.d: Ditto. 12008 * testsuite/gas/i386/avx-ne-convert-intel.d: Ditto. 12009 * testsuite/gas/i386/avx-ne-convert.d: Ditto. 12010 * testsuite/gas/i386/avx-vnni-int8-intel.d: Ditto. 12011 * testsuite/gas/i386/avx-vnni-int8.d: Ditto. 12012 * testsuite/gas/i386/avx512_bf16.d: Ditto. 12013 * testsuite/gas/i386/avx512_bf16_vl.d: Ditto. 12014 * testsuite/gas/i386/avx512_fp16-intel.d: Ditto. 12015 * testsuite/gas/i386/avx512_fp16.d: Ditto. 12016 * testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto. 12017 * testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto. 12018 * testsuite/gas/i386/avx512_fp16_vl.d: Ditto. 12019 * testsuite/gas/i386/avx512_vpopcntdq-intel.d: Ditto. 12020 * testsuite/gas/i386/avx512_vpopcntdq.d: Ditto. 12021 * testsuite/gas/i386/avx512bitalg-intel.d: Ditto. 12022 * testsuite/gas/i386/avx512bitalg.d: Ditto. 12023 * testsuite/gas/i386/avx512bitalg_vl-intel.d: Ditto. 12024 * testsuite/gas/i386/avx512bitalg_vl.d: Ditto. 12025 * testsuite/gas/i386/avx512bw-opts-intel.d: Ditto. 12026 * testsuite/gas/i386/avx512bw-opts.d: Ditto. 12027 * testsuite/gas/i386/avx512bw_vl-intel.d: Ditto. 12028 * testsuite/gas/i386/avx512bw_vl-opts-intel.d: Ditto. 12029 * testsuite/gas/i386/avx512bw_vl-opts.d: Ditto. 12030 * testsuite/gas/i386/avx512bw_vl.d: Ditto. 12031 * testsuite/gas/i386/avx512cd-intel.d: Ditto. 12032 * testsuite/gas/i386/avx512cd.d: Ditto. 12033 * testsuite/gas/i386/avx512cd_vl-intel.d: Ditto. 12034 * testsuite/gas/i386/avx512cd_vl.d: Ditto. 12035 * testsuite/gas/i386/avx512dq-intel.d: Ditto. 12036 * testsuite/gas/i386/avx512dq.d: Ditto. 12037 * testsuite/gas/i386/avx512dq_vl-intel.d: Ditto. 12038 * testsuite/gas/i386/avx512dq_vl.d: Ditto. 12039 * testsuite/gas/i386/avx512er-intel.d: Ditto. 12040 * testsuite/gas/i386/avx512er.d: Ditto. 12041 * testsuite/gas/i386/avx512f-nondef.d: Ditto. 12042 * testsuite/gas/i386/avx512f-opts-intel.d: Ditto. 12043 * testsuite/gas/i386/avx512f-opts.d: Ditto. 12044 * testsuite/gas/i386/avx512f_gfni-intel.d: Ditto. 12045 * testsuite/gas/i386/avx512f_gfni.d: Ditto. 12046 * testsuite/gas/i386/avx512f_vaes-intel.d: Ditto. 12047 * testsuite/gas/i386/avx512f_vaes.d: Ditto. 12048 * testsuite/gas/i386/avx512f_vl-intel.d: Ditto. 12049 * testsuite/gas/i386/avx512f_vl-opts-intel.d: Ditto. 12050 * testsuite/gas/i386/avx512f_vl-opts.d: Ditto. 12051 * testsuite/gas/i386/avx512f_vl.d: Ditto. 12052 * testsuite/gas/i386/avx512f_vpclmulqdq-intel.d: Ditto. 12053 * testsuite/gas/i386/avx512f_vpclmulqdq.d: Ditto. 12054 * testsuite/gas/i386/avx512ifma-intel.d: Ditto. 12055 * testsuite/gas/i386/avx512ifma.d: Ditto. 12056 * testsuite/gas/i386/avx512ifma_vl-intel.d: Ditto. 12057 * testsuite/gas/i386/avx512ifma_vl.d: Ditto. 12058 * testsuite/gas/i386/avx512pf-intel.d: Ditto. 12059 * testsuite/gas/i386/avx512pf.d: Ditto. 12060 * testsuite/gas/i386/avx512vbmi-intel.d: Ditto. 12061 * testsuite/gas/i386/avx512vbmi.d: Ditto. 12062 * testsuite/gas/i386/avx512vbmi2-intel.d: Ditto. 12063 * testsuite/gas/i386/avx512vbmi2.d: Ditto. 12064 * testsuite/gas/i386/avx512vbmi2_vl-intel.d: Ditto. 12065 * testsuite/gas/i386/avx512vbmi2_vl.d: Ditto. 12066 * testsuite/gas/i386/avx512vbmi_vl-intel.d: Ditto. 12067 * testsuite/gas/i386/avx512vbmi_vl.d: Ditto. 12068 * testsuite/gas/i386/avx512vl_gfni-intel.d: Ditto. 12069 * testsuite/gas/i386/avx512vl_gfni.d: Ditto. 12070 * testsuite/gas/i386/avx512vl_vaes-intel.d: Ditto. 12071 * testsuite/gas/i386/avx512vl_vaes.d: Ditto. 12072 * testsuite/gas/i386/avx512vl_vpclmulqdq-intel.d: Ditto. 12073 * testsuite/gas/i386/avx512vl_vpclmulqdq.d: Ditto. 12074 * testsuite/gas/i386/avx512vnni-intel.d: Ditto. 12075 * testsuite/gas/i386/avx512vnni.d: Ditto. 12076 * testsuite/gas/i386/avx512vnni_vl-intel.d: Ditto. 12077 * testsuite/gas/i386/avx512vnni_vl.d: Ditto. 12078 * testsuite/gas/i386/bmi-intel.d: Ditto. 12079 * testsuite/gas/i386/bmi.d: Ditto. 12080 * testsuite/gas/i386/bmi2-intel.d: Ditto. 12081 * testsuite/gas/i386/bmi2.d: Ditto. 12082 * testsuite/gas/i386/cldemote-intel.d: Ditto. 12083 * testsuite/gas/i386/cldemote.d: Ditto. 12084 * testsuite/gas/i386/clflushopt-intel.d: Ditto. 12085 * testsuite/gas/i386/clflushopt.d: Ditto. 12086 * testsuite/gas/i386/clwb-intel.d: Ditto. 12087 * testsuite/gas/i386/clwb.d: Ditto. 12088 * testsuite/gas/i386/enqcmd-intel.d: Ditto. 12089 * testsuite/gas/i386/enqcmd.d: Ditto. 12090 * testsuite/gas/i386/gfni-intel.d: Ditto. 12091 * testsuite/gas/i386/gfni.d: Ditto. 12092 * testsuite/gas/i386/hreset.d: Ditto. 12093 * testsuite/gas/i386/invpcid-intel.d: Ditto. 12094 * testsuite/gas/i386/invpcid.d: Ditto. 12095 * testsuite/gas/i386/keylocker-intel.d: Ditto. 12096 * testsuite/gas/i386/keylocker.d: Ditto. 12097 * testsuite/gas/i386/movdir-intel.d: Ditto. 12098 * testsuite/gas/i386/movdir.d: Ditto. 12099 * testsuite/gas/i386/pr27198.d: Ditto. 12100 * testsuite/gas/i386/pr30248.d: Ditto. 12101 * testsuite/gas/i386/prefetchwt1-intel.d: Ditto. 12102 * testsuite/gas/i386/prefetchwt1.d: Ditto. 12103 * testsuite/gas/i386/ptwrite-intel.d: Ditto. 12104 * testsuite/gas/i386/ptwrite.d: Ditto. 12105 * testsuite/gas/i386/raoint-intel.d: Ditto. 12106 * testsuite/gas/i386/raoint.d: Ditto. 12107 * testsuite/gas/i386/serialize.d: Ditto. 12108 * testsuite/gas/i386/tbm-intel.d: Ditto. 12109 * testsuite/gas/i386/tdx.d: Ditto. 12110 * testsuite/gas/i386/tsxldtrk.d: Ditto. 12111 * testsuite/gas/i386/vp2intersect-intel.d: Ditto. 12112 * testsuite/gas/i386/vp2intersect.d: Ditto. 12113 * testsuite/gas/i386/vpclmulqdq-intel.d: Ditto. 12114 * testsuite/gas/i386/vpclmulqdq.d: Ditto. 12115 * testsuite/gas/i386/waitpkg-intel.d: Ditto. 12116 * testsuite/gas/i386/waitpkg.d: Ditto. 12117 * testsuite/gas/i386/wrmsrns-intel.d: Ditto. 12118 * testsuite/gas/i386/wrmsrns.d: Ditto. 12119 * testsuite/gas/i386/x86-64-amx-bad.d: Ditto. 12120 * testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto. 12121 * testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto. 12122 * testsuite/gas/i386/x86-64-amx-complex.d: Ditto. 12123 * testsuite/gas/i386/x86-64-amx-fp16-bad.d: Ditto. 12124 * testsuite/gas/i386/x86-64-amx-fp16-intel.d: Ditto. 12125 * testsuite/gas/i386/x86-64-amx-fp16.d: Ditto. 12126 * testsuite/gas/i386/x86-64-amx-intel.d: Ditto. 12127 * testsuite/gas/i386/x86-64-amx.d: Ditto. 12128 * testsuite/gas/i386/x86-64-avx-gather-intel.d: Ditto. 12129 * testsuite/gas/i386/x86-64-avx-gather.d: Ditto. 12130 * testsuite/gas/i386/x86-64-avx-ifma-intel.d: Ditto. 12131 * testsuite/gas/i386/x86-64-avx-ifma.d: Ditto. 12132 * testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto. 12133 * testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto. 12134 * testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Ditto. 12135 * testsuite/gas/i386/x86-64-avx-vnni-int8.d: Ditto. 12136 * testsuite/gas/i386/x86-64-avx512_bf16.d: Ditto. 12137 * testsuite/gas/i386/x86-64-avx512_bf16_vl.d: Ditto. 12138 * testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto. 12139 * testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto. 12140 * testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto. 12141 * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto. 12142 * testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto. 12143 * testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto. 12144 * testsuite/gas/i386/x86-64-avx512_vpopcntdq-intel.d: Ditto. 12145 * testsuite/gas/i386/x86-64-avx512_vpopcntdq.d: Ditto. 12146 * testsuite/gas/i386/x86-64-avx512bitalg-intel.d: Ditto. 12147 * testsuite/gas/i386/x86-64-avx512bitalg.d: Ditto. 12148 * testsuite/gas/i386/x86-64-avx512bitalg_vl-intel.d: Ditto. 12149 * testsuite/gas/i386/x86-64-avx512bitalg_vl.d: Ditto. 12150 * testsuite/gas/i386/x86-64-avx512bw-intel.d: Ditto. 12151 * testsuite/gas/i386/x86-64-avx512bw-opts-intel.d: Ditto. 12152 * testsuite/gas/i386/x86-64-avx512bw-opts.d: Ditto. 12153 * testsuite/gas/i386/x86-64-avx512bw.d: Ditto. 12154 * testsuite/gas/i386/x86-64-avx512bw_vl-intel.d: Ditto. 12155 * testsuite/gas/i386/x86-64-avx512bw_vl-opts-intel.d: Ditto. 12156 * testsuite/gas/i386/x86-64-avx512bw_vl-opts.d: Ditto. 12157 * testsuite/gas/i386/x86-64-avx512bw_vl.d: Ditto. 12158 * testsuite/gas/i386/x86-64-avx512cd-intel.d: Ditto. 12159 * testsuite/gas/i386/x86-64-avx512cd.d: Ditto. 12160 * testsuite/gas/i386/x86-64-avx512cd_vl-intel.d: Ditto. 12161 * testsuite/gas/i386/x86-64-avx512cd_vl.d: Ditto. 12162 * testsuite/gas/i386/x86-64-avx512dq-intel.d: Ditto. 12163 * testsuite/gas/i386/x86-64-avx512dq.d: Ditto. 12164 * testsuite/gas/i386/x86-64-avx512dq_vl-intel.d: Ditto. 12165 * testsuite/gas/i386/x86-64-avx512dq_vl.d: Ditto. 12166 * testsuite/gas/i386/x86-64-avx512er-intel.d: Ditto. 12167 * testsuite/gas/i386/x86-64-avx512er.d: Ditto. 12168 * testsuite/gas/i386/x86-64-avx512f-intel.d: Ditto. 12169 * testsuite/gas/i386/x86-64-avx512f-nondef.d: Ditto. 12170 * testsuite/gas/i386/x86-64-avx512f-opts-intel.d: Ditto. 12171 * testsuite/gas/i386/x86-64-avx512f-opts.d: Ditto. 12172 * testsuite/gas/i386/x86-64-avx512f.d: Ditto. 12173 * testsuite/gas/i386/x86-64-avx512f_gfni-intel.d: Ditto. 12174 * testsuite/gas/i386/x86-64-avx512f_gfni.d: Ditto. 12175 * testsuite/gas/i386/x86-64-avx512f_vaes-intel.d: Ditto. 12176 * testsuite/gas/i386/x86-64-avx512f_vaes.d: Ditto. 12177 * testsuite/gas/i386/x86-64-avx512f_vl-intel.d: Ditto. 12178 * testsuite/gas/i386/x86-64-avx512f_vl-opts-intel.d: Ditto. 12179 * testsuite/gas/i386/x86-64-avx512f_vl-opts.d: Ditto. 12180 * testsuite/gas/i386/x86-64-avx512f_vl.d: Ditto. 12181 * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq-intel.d: Ditto. 12182 * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.d: Ditto. 12183 * testsuite/gas/i386/x86-64-avx512ifma-intel.d: Ditto. 12184 * testsuite/gas/i386/x86-64-avx512ifma.d: Ditto. 12185 * testsuite/gas/i386/x86-64-avx512ifma_vl-intel.d: Ditto. 12186 * testsuite/gas/i386/x86-64-avx512ifma_vl.d: Ditto. 12187 * testsuite/gas/i386/x86-64-avx512pf-intel.d: Ditto. 12188 * testsuite/gas/i386/x86-64-avx512pf.d: Ditto. 12189 * testsuite/gas/i386/x86-64-avx512vbmi-intel.d: Ditto. 12190 * testsuite/gas/i386/x86-64-avx512vbmi.d: Ditto. 12191 * testsuite/gas/i386/x86-64-avx512vbmi2-intel.d: Ditto. 12192 * testsuite/gas/i386/x86-64-avx512vbmi2.d: Ditto. 12193 * testsuite/gas/i386/x86-64-avx512vbmi2_vl-intel.d: Ditto. 12194 * testsuite/gas/i386/x86-64-avx512vbmi2_vl.d: Ditto. 12195 * testsuite/gas/i386/x86-64-avx512vbmi_vl-intel.d: Ditto. 12196 * testsuite/gas/i386/x86-64-avx512vbmi_vl.d: Ditto. 12197 * testsuite/gas/i386/x86-64-avx512vl_gfni-intel.d: Ditto. 12198 * testsuite/gas/i386/x86-64-avx512vl_gfni.d: Ditto. 12199 * testsuite/gas/i386/x86-64-avx512vl_vaes-intel.d: Ditto. 12200 * testsuite/gas/i386/x86-64-avx512vl_vaes.d: Ditto. 12201 * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq-intel.d: Ditto. 12202 * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.d: Ditto. 12203 * testsuite/gas/i386/x86-64-avx512vnni-intel.d: Ditto. 12204 * testsuite/gas/i386/x86-64-avx512vnni.d: Ditto. 12205 * testsuite/gas/i386/x86-64-avx512vnni_vl-intel.d: Ditto. 12206 * testsuite/gas/i386/x86-64-avx512vnni_vl.d: Ditto. 12207 * testsuite/gas/i386/x86-64-avx_gfni-intel.d: Ditto. 12208 * testsuite/gas/i386/x86-64-avx_gfni.d: Ditto. 12209 * testsuite/gas/i386/x86-64-bmi-intel.d: Ditto. 12210 * testsuite/gas/i386/x86-64-bmi.d: Ditto. 12211 * testsuite/gas/i386/x86-64-bmi2-intel.d: Ditto. 12212 * testsuite/gas/i386/x86-64-bmi2.d: Ditto. 12213 * testsuite/gas/i386/x86-64-cldemote-intel.d: Ditto. 12214 * testsuite/gas/i386/x86-64-cldemote.d: Ditto. 12215 * testsuite/gas/i386/x86-64-clflushopt-intel.d: Ditto. 12216 * testsuite/gas/i386/x86-64-clflushopt.d: Ditto. 12217 * testsuite/gas/i386/x86-64-clwb-intel.d: Ditto. 12218 * testsuite/gas/i386/x86-64-clwb.d: Ditto. 12219 * testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto. 12220 * testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto. 12221 * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. 12222 * testsuite/gas/i386/x86-64-fred.d: Ditto. 12223 * testsuite/gas/i386/x86-64-gfni-intel.d: Ditto. 12224 * testsuite/gas/i386/x86-64-gfni.d: Ditto. 12225 * testsuite/gas/i386/x86-64-hreset.d: Ditto. 12226 * testsuite/gas/i386/x86-64-invpcid-intel.d: Ditto. 12227 * testsuite/gas/i386/x86-64-invpcid.d: Ditto. 12228 * testsuite/gas/i386/x86-64-keylocker-intel.d: Ditto. 12229 * testsuite/gas/i386/x86-64-keylocker.d: Ditto. 12230 * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. 12231 * testsuite/gas/i386/x86-64-lkgs.d: Ditto. 12232 * testsuite/gas/i386/x86-64-movsxd-intel.d: Ditto. 12233 * testsuite/gas/i386/x86-64-movsxd.d: Ditto. 12234 * testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto. 12235 * testsuite/gas/i386/x86-64-msrlist.d: Ditto. 12236 * testsuite/gas/i386/x86-64-prefetchi-intel.d: Ditto. 12237 * testsuite/gas/i386/x86-64-prefetchi.d: Ditto. 12238 * testsuite/gas/i386/x86-64-prefetchwt1-intel.d: Ditto. 12239 * testsuite/gas/i386/x86-64-prefetchwt1.d: Ditto. 12240 * testsuite/gas/i386/x86-64-ptwrite-intel.d: Ditto. 12241 * testsuite/gas/i386/x86-64-ptwrite.d: Ditto. 12242 * testsuite/gas/i386/x86-64-raoint-intel.d: Ditto. 12243 * testsuite/gas/i386/x86-64-raoint.d: Ditto. 12244 * testsuite/gas/i386/x86-64-serialize.d: Ditto. 12245 * testsuite/gas/i386/x86-64-sysenter.d: Ditto. 12246 * testsuite/gas/i386/x86-64-tbm-intel.d: Ditto. 12247 * testsuite/gas/i386/x86-64-tdx.d: Ditto. 12248 * testsuite/gas/i386/x86-64-tsxldtrk.d: Ditto. 12249 * testsuite/gas/i386/x86-64-uintr.d: Ditto. 12250 * testsuite/gas/i386/x86-64-vp2intersect-intel.d: Ditto. 12251 * testsuite/gas/i386/x86-64-vp2intersect.d: Ditto. 12252 * testsuite/gas/i386/x86-64-vpclmulqdq-intel.d: Ditto. 12253 * testsuite/gas/i386/x86-64-vpclmulqdq.d: Ditto. 12254 * testsuite/gas/i386/x86-64-waitpkg-intel.d: Ditto. 12255 * testsuite/gas/i386/x86-64-waitpkg.d: Ditto. 12256 * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto. 12257 * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto. 12258 * testsuite/gas/i386/x86-64-xsavec-intel.d: Ditto. 12259 * testsuite/gas/i386/x86-64-xsavec.d: Ditto. 12260 * testsuite/gas/i386/x86-64-xsaves-intel.d: Ditto. 12261 * testsuite/gas/i386/x86-64-xsaves.d: Ditto. 12262 * testsuite/gas/i386/xsavec-intel.d: Ditto. 12263 * testsuite/gas/i386/xsavec.d: Ditto. 12264 * testsuite/gas/i386/xsaves-intel.d: Ditto. 12265 * testsuite/gas/i386/xsaves.d: Ditto. 12266 122672023-11-28 GDB Administrator <gdbadmin@sourceware.org> 12268 12269 Automatic date update in version.in 12270 122712023-11-27 John Baldwin <jhb@FreeBSD.org> 12272 12273 i386: Use a fallback XSAVE layout for remote targets 12274 If a target provides a target description including registers from the 12275 XSAVE extended region, but does not provide an XSAVE layout, use a 12276 fallback XSAVE layout based on the included registers. This fallback 12277 layout matches GDB's behavior in earlier releases which assumes the 12278 layout from Intel CPUs. 12279 12280 This fallback layout is currently only used for remote targets since 12281 native targets which support XSAVE provide an explicit layout derived 12282 from CPUID. 12283 12284 PR gdb/30912 12285 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912 12286 Approved-By: Simon Marchi <simon.marchi@efficios.com> 12287 122882023-11-27 Tom de Vries <tdevries@suse.de> 12289 12290 [gdb/testsuite] Add boards/cc-with-index-cache.exp 12291 We have a target board cc-with-gdb-index that uses the gdb-add-index script to 12292 add a .gdb_index index to an exec. 12293 12294 There is however an alternative way of adding a .gdb_index: the index-cache. 12295 12296 Add a new target board cc-with-index-cache. 12297 12298 This is not superfluous for two reasons: 12299 - there is functionality that gdb-add-index doesn't support, but the 12300 index-cache does: the index-cache can add an index to an exec with a 12301 .gnu_debugaltlink (note that when using the cc-with-gdb-index board this 12302 case is quietly ignored), and 12303 - using the index-cache is excercised in only a few test-cases, and having 12304 this target board extends the test coverage to the entire test suite. This 12305 is for instance relevant because the index-cache is written by a worker 12306 thread in the background, so we can check more thoroughly for data races 12307 (see PR symtab/30837). 12308 12309 Tested on x86_64-linux. 12310 12311 Shell script changes checked with shellcheck. 12312 12313 Approved-By: Tom Tromey <tom@tromey.com> 12314 123152023-11-27 Tom Tromey <tromey@adacore.com> 12316 12317 Change serial_readchar to throw 12318 This changes serial_readchar to throw an exception rather than trying 12319 to set and preserve errno. 12320 12321 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12322 123232023-11-27 Tom Tromey <tromey@adacore.com> 12324 12325 Change serial_send_break and serial_write to throw 12326 This changes serial_send_break and serial_write to throw exceptions 12327 rather than attempt to set errno and return an error indicator. This 12328 lets us correctly report failures on Windows. 12329 12330 Both functions had to be converted in a single patch because one 12331 implementation of send_break works via write. 12332 12333 This also introduces remote_serial_send_break to handle error checking 12334 when attempting to send a break. This was previously ignored. 12335 12336 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12337 123382023-11-27 Tom Tromey <tromey@adacore.com> 12339 12340 Change serial "open" functions to throw exception 12341 remote.c assumes that a failure to open the serial connection will set 12342 errno. This is somewhat true, because the Windows code tries to set 12343 errno appropriately -- but only somewhat, because it isn't clear that 12344 the "pex" code sets it, and the tcp code seems to do the wrong thing. 12345 It seems better to simply have the serial open functions throw on 12346 error. 12347 12348 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12349 123502023-11-27 Tom Tromey <tromey@adacore.com> 12351 12352 Change serial_setbaudrate to throw exception 12353 remote.c has this code: 12354 12355 if (serial_setbaudrate (rs->remote_desc, baud_rate)) 12356 { 12357 /* The requested speed could not be set. Error out to 12358 top level after closing remote_desc. Take care to 12359 set remote_desc to NULL to avoid closing remote_desc 12360 more than once. */ 12361 serial_close (rs->remote_desc); 12362 rs->remote_desc = NULL; 12363 perror_with_name (name); 12364 12365 The perror here cannot be correct, because if serial_setbaudrate did 12366 set errno, it may be obscured by serial_close. 12367 12368 This patch changes serial_setbaudrate to throw an exception instead. 12369 12370 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12371 123722023-11-27 Tom Tromey <tromey@adacore.com> 12373 12374 Introduce throw_winerror_with_name 12375 This introduces throw_winerror_with_name, a Windows analog of 12376 perror_with_name, and changes various places in gdb to call it. 12377 12378 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12379 123802023-11-27 Tom Tromey <tromey@adacore.com> 12381 12382 Fix latent bug in ser_windows_send_break 12383 The ClearCommBreak documentation says: 12384 12385 If the function fails, the return value is zero. 12386 12387 ser_windows_send_break inverts this check. This has never been 12388 noticed because the caller doesn't check the result. 12389 12390 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 12391 123922023-11-27 Tom Tromey <tromey@adacore.com> 12393 12394 Fix bug in DAP handling of 'pause' requests 12395 While working on cancellation, I noticed that a DAP 'pause' request 12396 would set the "do not emit the continue" flag. This meant that a 12397 subsequent request that should provoke a 'continue' event would 12398 instead suppress the event. 12399 12400 I then tried writing a more obvious test case for this, involving an 12401 inferior call -- and discovered that gdb.events.cont does not fire for 12402 an inferior call. 12403 12404 This patch installs a new event listener for gdb.events.inferior_call 12405 and arranges for this to emit continue and stop events when 12406 appropriate. It also fixes the original bug, by adding a check to 12407 exec_and_expect_stop. 12408 124092023-11-27 Simon Marchi <simon.marchi@efficios.com> 12410 12411 gdb: make catch_syscall_enabled return bool 12412 Make it return a bool and adjust a few comparisons where it's used. 12413 12414 Change-Id: Ic77d23b0dcfcfc9195dfe65e4c7ff9cf3229f6fb 12415 124162023-11-27 Andrew Burgess <aburgess@redhat.com> 12417 12418 gdb/python: handle completion returning a non-sequence 12419 GDB's Python API documentation for gdb.Command.complete() says: 12420 12421 The 'complete' method can return several values: 12422 * If the return value is a sequence, the contents of the 12423 sequence are used as the completions. It is up to 'complete' 12424 to ensure that the contents actually do complete the word. A 12425 zero-length sequence is allowed, it means that there were no 12426 completions available. Only string elements of the sequence 12427 are used; other elements in the sequence are ignored. 12428 12429 * If the return value is one of the 'COMPLETE_' constants 12430 defined below, then the corresponding GDB-internal completion 12431 function is invoked, and its result is used. 12432 12433 * All other results are treated as though there were no 12434 available completions. 12435 12436 So, returning a non-sequence, and non-integer from a complete method 12437 should be fine; it should just be treated as though there are no 12438 completions. 12439 12440 However, if I write a complete method that returns None, I see this 12441 behaviour: 12442 12443 (gdb) complete completefilenone x 12444 Python Exception <class 'TypeError'>: 'NoneType' object is not iterable 12445 warning: internal error: Unhandled Python exception 12446 (gdb) 12447 12448 Which is caused because we currently assume that anything that is not 12449 an integer must be iterable, and we call PyObject_GetIter on it. When 12450 this call fails a Python exception is set, but instead of 12451 clearing (and therefore ignoring) this exception as we do everywhere 12452 else in the Python completion code, we instead just return with the 12453 exception set. 12454 12455 In this commit I add a PySequence_Check call. If this call returns 12456 false (and we've already checked the integer case) then we can assume 12457 there are no completion results. 12458 12459 I've added a test which checks returning a non-sequence. 12460 12461 Approved-By: Tom Tromey <tom@tromey.com> 12462 124632023-11-27 Jiajie Chen <c@jia.je> 12464 12465 as: Add new estimated reciprocal instructions in LoongArch v1.1 12466 New estimated reciprocal instructions in LoongArch v1.1: 12467 12468 - frecipe.s/d 12469 - frsqrte.s/d 12470 - vfrecipe.s/d 12471 - vfrsqrte.s/d 12472 - xvfrecipe.s/d 12473 - xvfrsqrte.s/d 12474 124752023-11-27 Jiajie Chen <c@jia.je> 12476 12477 as: Add new atomic instructions in LoongArch v1.1 12478 LoongArch V1.1 release is out at 12479 https://github.com/loongson/LoongArch-Documentation. 12480 12481 New atomic instructions in LoongArch v1.1: 12482 12483 - sc.q 12484 - llacq.w/d 12485 - screl.w/d 12486 - amcas{_db}.b/h/w/d 12487 - amswap{_db}.b/h 12488 - amadd{_db}.b/h 12489 124902023-11-27 GDB Administrator <gdbadmin@sourceware.org> 12491 12492 Automatic date update in version.in 12493 124942023-11-26 GDB Administrator <gdbadmin@sourceware.org> 12495 12496 Automatic date update in version.in 12497 124982023-11-25 GDB Administrator <gdbadmin@sourceware.org> 12499 12500 Automatic date update in version.in 12501 125022023-11-24 Tom de Vries <tdevries@suse.de> 12503 12504 [gdb/testsuite] Use more %progbits for arm 12505 On pinebook I ran into: 12506 ... 12507 Running gdb.tui/tui-layout-asm-short-prog.exp ... 12508 gdb compile failed, gdb.tui/tui-layout-asm-short-prog.S: Assembler messages: 12509 gdb.tui/tui-layout-asm-short-prog.S:23: Error: \ 12510 junk at end of line, first unrecognized character is `,' 12511 ... 12512 12513 Fix this by using %progbits instead of @progbits for arm. 12514 12515 Approved-by: Luis Machado <luis.machado@arm.com> 12516 12517 Tested on x86_64-linux and pinebook. 12518 125192023-11-24 Tom de Vries <tdevries@suse.de> 12520 12521 [gdb/testsuite] Two fixes in gdb.python/tui-window-disabled.exp 12522 I ran test-case gdb.python/tui-window-disabled.exp on a configuration without 12523 python support, and ran into: 12524 ... 12525 PASS: $exp: cleanup_properly=True: initial restart: set pagination off 12526 UNSUPPORTED: $exp: cleanup_properly=True: couldn't restart GDB 12527 PASS: $exp: cleanup_properly=False: initial restart: set pagination off 12528 UNSUPPORTED: $exp: cleanup_properly=False: couldn't restart GDB 12529 ... 12530 12531 After looking into the test-case, I realized that this is a consequence of 12532 !allow_python_tests. 12533 12534 Handle this instead by requiring allow_python_tests, such that we get the usual 12535 and more clear: 12536 ... 12537 UNSUPPORTED: $exp: require failed: allow_python_tests 12538 ... 12539 12540 Also fix a return without value in clean_restart_and_setup, which if triggered 12541 would cause: 12542 ... 12543 ERROR: expected boolean value but got "" 12544 ... 12545 12546 Tested on x86_64-linux. 12547 125482023-11-24 Ilya Leoshkevich <iii@linux.ibm.com> 12549 12550 gdb: Fix "target file /proc/.../cmdline contained unexpected null characters" 12551 When using the gcore command, GDB prints the following warning: 12552 12553 (gdb) gcore 12554 warning: target file /proc/.../cmdline contained unexpected null characters 12555 12556 The reason is that cmdline is read with target_fileio_read_stralloc(), 12557 which warns on seeing null characters. However, it's perfectly valid 12558 for cmdline to contain \0s, so switch to target_fileio_read_alloc(). 12559 12560 Approved-By: Tom Tromey <tom@tromey.com> 12561 125622023-11-24 Jan Beulich <jbeulich@suse.com> 12563 12564 RISC-V: drop leftover match_never() references 12565 Commit 27b33966b18e "RISC-V: disallow x0 with certain macro-insns" 12566 wasn't properly re-based over recent opcode table additions. 12567 12568 x86: shrink opcode sets table 12569 Have i386-gen produce merely the offsets into i386_optab[]. Besides 12570 allowing to shrink the table even on 32-bit builds, this results in 12571 removing a level of indirection from the frequently accessed 12572 current_templates, in return for adding a level of indirection when 12573 looking up mnemonics (commonly happening just once per insn). Plus for 12574 PIE builds of gas it also reduces the number of relocations by about two 12575 thousand. Finally a somewhat ugly static variable can also be eliminated 12576 from i386_displacement(). 12577 12578 x86: also prefer VEX encoding over EVEX one for VCVTNEPS2BF16 when possible 12579 Deal with what 58bceb182740 ("x86: prefer VEX encodings over EVEX ones 12580 when possible") left out, for being slightly less straightforward. 12581 125822023-11-24 Jan Beulich <jbeulich@suse.com> 12583 12584 RISC-V: reduce redundancy in sign/zero extension macro insn handling 12585 Fold M_{S,Z}EXTH, deriving signed-ness from the incoming mnemonic. Fold 12586 riscv_ext()'s calls md_assemblef(), the first of which were entirely 12587 identical, while the other pair differed in just a single character. 12588 12589 Acked-by: Palmer Dabbelt <palmer@rivosinc.com> 12590 125912023-11-24 Jan Beulich <jbeulich@suse.com> 12592 12593 RISC-V: disallow x0 with certain macro-insns 12594 While for some of the macro insns using x0 is kind of okay, as they 12595 would merely resolve to a sequence of hint insns (and hence not cause 12596 misbehavior at runtime), several of them have the degenerate AUIPC 12597 followed by a load, store, or branch using other than the designated 12598 symbol as address and hence causing runtime issues. Refuse to assemble 12599 those, leveraging that the matching function so far wasn't really used 12600 for macro insns: NULL is now allowed, indicating a match (which imo is 12601 preferable over converting match_never() to match_always()), while 12602 other matching functions now (also) used for macro insns need to avoid 12603 calling match_opcode(). 12604 12605 Note that for LA the restriction is slightly too strict: In non-PIC mode 12606 using x0 would be okay-ish as per above (as it's just LLA there). Yet 12607 libopcodes doesn't know what mode gas is presently assembling for, so we 12608 want to err on the safe side. 12609 12610 Acked-by: Palmer Dabbelt <palmer@rivosinc.com> 12611 126122023-11-24 Nick Clifton <nickc@redhat.com> 12613 12614 Fix building for the s390 target with clang 12615 126162023-11-24 zengxiao <zengxiao@eswincomputing.com> 12617 12618 RISC-V: Update 'Zfa' extension version 12619 Because the 'Zfa' extension has a version number of 1.0 12620 (not 0.1). This commit updates the number. 12621 12622 bfd/ChangeLog: 12623 12624 * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version 12625 number of the 'Zfa' extension since it's ratified. 12626 126272023-11-24 GDB Administrator <gdbadmin@sourceware.org> 12628 12629 Automatic date update in version.in 12630 126312023-11-23 Jens Remus <jremus@linux.ibm.com> 12632 12633 s390: Correct prno instruction name 12634 IBM z13 (arch11) introduced ppno (Perform Pseudorandom Number Operation). 12635 IBM z14 (arch12) introduced prno (Perform Random Number Operation) and 12636 deprecated ppno. 12637 12638 opcodes/ 12639 * s390-opc.txt: Correct prno instruction name. 12640 12641 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12642 126432023-11-23 Jens Remus <jremus@linux.ibm.com> 12644 12645 s390: Add missing extended mnemonics 12646 Add extended mnemonics specified in the z/Architecture Principles of 12647 Operation [1] and z/Architecture Reference Summary [2], that were 12648 previously missing from the opcode table. 12649 12650 The following added extended mnemonics are synonyms to a base mnemonic 12651 and therefore disassemble into their base mnemonic: 12652 jc, jcth, lfi, llgfi, llghi 12653 12654 The following added extended mnemonics are more specific than their base 12655 mnemonic and therefore disassemble into the added extended mnemonic: 12656 risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt 12657 12658 The following added extended mnemonics are more specific than their base 12659 mnemonic, but disassemble into their base mnemonic due to design 12660 constraints: 12661 notr, notgr 12662 12663 The missing extended mnemonic jl* conditional jump long flavors cannot 12664 be added, as they would clash with the existing non-standard extended 12665 mnemonic j* conditional jump flavors jle and jlh. The missing extended 12666 mnemonic jlc jump long conditional is not added, as the related jl* 12667 flavors cannot be added. 12668 Note that these missing jl* conditional jump long flavors are already 12669 defined as non-standard jg* flavors instead. While the related missing 12670 extended mnemonic jlc could be added as non-standard jgc instead it is 12671 forgone in favor of not adding further non-standard mnemonics. 12672 12673 The missing extended mnemonics sllhh, sllhl, slllh, srlhh, srlhl, and 12674 srllh cannot be implemented using the current design, as they require 12675 computed operands. For that reason the following missing extended 12676 mnemonics are not added as well, as they fall into the same category of 12677 instructions that operate on high and low words of registers. They 12678 should better be added together, not to confuse the user, which of those 12679 instructions are currently implemented or not. 12680 lhhr, lhlr, llhfr, llchhr, llchlr, llclhr, llhhhr, llhhlr, llhlhr, 12681 nhhr, nhlr, nlhr, ohhr, ohlr, olhr, xhhr, xhlr, xlhr 12682 12683 [1] IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, 12684 https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf 12685 [2] IBM z/Architecture Reference Summary, SA22-7871-11, 12686 https://www.ibm.com/support/pages/sites/default/files/2022-09/SA22-7871-11.pdf 12687 12688 opcodes/ 12689 * s390-opc.c: Define operand formats R_CP16_28, U6_18, and 12690 U5_27. Define instruction formats RIE_RRUUU3, RIE_RRUUU4, 12691 and RRF_R0RR4. 12692 * s390-opc.txt: Add extended mnemonics jc, jcth, lfi, llgfi, 12693 llghi, notgr, notr, risbhgz, risblgz, rnsbgt, rosbgt, and 12694 rxsbgt. 12695 12696 gas/ 12697 * config/tc-s390.c: Add support to insert operand for format 12698 R_CP16_28, reusing existing logic for format V_CP16_12. 12699 * testsuite/gas/s390/esa-g5.s: Add test for extended mnemonic 12700 jc. 12701 * testsuite/gas/s390/esa-g5.d: Likewise. 12702 * testsuite/gas/s390/zarch-z900.s: Add test for extended 12703 mnemonic llghi. 12704 * testsuite/gas/s390/zarch-z900.d: Likewise. 12705 * testsuite/gas/s390/zarch-z9-109.s: Add tests for extended 12706 mnemonics lfi and llgfi. 12707 * testsuite/gas/s390/zarch-z9-109.d: Likewise. 12708 * testsuite/gas/s390/zarch-z10.s: Add tests for extended 12709 mnemonics rnsbgt, rosbgt, and rxsbgt. 12710 * testsuite/gas/s390/zarch-z10.d: Likewise. 12711 * testsuite/gas/s390/zarch-z196.s: Add tests for extended 12712 mnemonics jcth, risbhgz, and risblgz. 12713 * testsuite/gas/s390/zarch-z196.d: Likewise. 12714 * testsuite/gas/s390/zarch-arch13.s: Add tests for extended 12715 mnemonics notr and notgr. 12716 * testsuite/gas/s390/zarch-arch13.d: Likewise. 12717 12718 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12719 127202023-11-23 Jens Remus <jremus@linux.ibm.com> 12721 12722 s390: Align optional operand definition to specs 12723 The IBM z/Architecture Principle of Operation [1] specifies the last 12724 operand(s) of some (extended) mnemonics to be optional. Align the 12725 mnemonic definitions in the opcode table according to specification. 12726 12727 This changes the last operand of the following (extended) mnemonics to 12728 be optional: 12729 risbg, risbgz, risbgn, risbgnz, risbhg, risblg, rnsbg, rosbg, rxsbg 12730 12731 Note that efpc and sfpc actually have only one operand, but had 12732 erroneously been defined to have two. For backwards compatibility the 12733 wrong RR register format must be retained. Since the superfluous second 12734 operand is defined as optional the instruction can still be coded as 12735 specified. 12736 12737 [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, 12738 https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf 12739 12740 opcodes/ 12741 * s390-opc.txt: Align optional operand definition to 12742 specification. 12743 12744 testsuite/ 12745 * zarch-z10.s: Add test cases for risbg, risbgz, rnsbg, rosbg, 12746 and rxsbg. 12747 * zarch-z10.d: Likewise. 12748 * zarch-z196.s: Add test cases for risbhg and risblg. 12749 * zarch-z196.d: Likewise. 12750 * zarch-zEC12.s: Add test cases for risbgn and risbgnz. 12751 * zarch-zEC12.d: Likewise. 12752 12753 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12754 127552023-11-23 Jens Remus <jremus@linux.ibm.com> 12756 12757 s390: Make operand table indices relative to each other 12758 This is a purely mechanical change. It allows subsequent insertions into 12759 the operands table without having to renumber all operand indices. 12760 12761 The only differences in the resulting ELF object are in the .debug_info 12762 section. This has been confirmed by diffing the following xxd and readelf 12763 output: 12764 12765 xxd s390-opc.o 12766 readelf -aW -x .text -x .data -x .bss -x .rodata -x .debug_info \ 12767 -x .symtab -x .strtab -x .shstrtab --debug-dump s390-opc.o 12768 12769 opcodes/ 12770 * s390-opc.c: Make operand table indices relative to each other. 12771 12772 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12773 127742023-11-23 Jens Remus <jremus@linux.ibm.com> 12775 12776 s390: Add brasl edge test cases from ESA to z/Architecture 12777 The ESA opcode test cases for IBM z900 contain a few edge cases. They 12778 exercise the brasl mnemonic with its largest allowed negative and 12779 positive offsets. Linux on zSeries in ESA mode executes in 31-bit 12780 addressing mode. Therefore the ESA test cases are assembled with -m31. 12781 In 31-bit addressing mode the address computation using those large 12782 offsets wraps, which is correctly reflected in the disassembly. 12783 12784 Linux on Z in z/Architecture mode executes in 64-bit addressing mode. 12785 Therefore the z/Architecture (zarch) test cases are assembled with -m64. 12786 In 64-bit addressing mode the address computation using those large 12787 offsets does not necessarily wrap. 12788 12789 gas/ 12790 * testsuite/gas/s390/zarch-z900.s: Add brasl tests from ESA that 12791 exercise edge cases. 12792 * testsuite/gas/s390/zarch-z900.d: Likewise. 12793 12794 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12795 127962023-11-23 Jens Remus <jremus@linux.ibm.com> 12797 12798 s390: Position independent verification of relative addressing 12799 Opcode test cases for z/Architecture instructions that use relative 12800 addressing contained hardcoded offsets in the test verification 12801 patterns. Inserting or reordering of instructions into those test cases 12802 therefore required updating of those hardcoded offsets. 12803 12804 Use regular expressions with backreferences to verify results of test 12805 cases containing instructions with relative addressing. This makes the 12806 verification position independent. 12807 12808 gas/ 12809 * testsuite/gas/s390/esa-g5.d: Make opcode test verification 12810 pattern position independent where possible. 12811 * testsuite/gas/s390/esa-z900.d: Likewise. 12812 * testsuite/gas/s390/zarch-z900.d: Likewise. 12813 * testsuite/gas/s390/zarch-z10.d: Likewise. 12814 * testsuite/gas/s390/zarch-z196.d: Likewise. 12815 * testsuite/gas/s390/zarch-zEC12.d: Likewise. 12816 12817 Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> 12818 128192023-11-23 YunQiang Su <yunqiang.su@cipunited.com> 12820 12821 MIPS/GAS: Use addiu instead of addi in test elf-rel. 12822 12823 MIPS/GAS: Fix test failures due to jr encoding changes on r6 12824 128252023-11-23 Tom de Vries <tdevries@suse.de> 12826 12827 [gdb/python] Reformat missing_debug.py using black 12828 Reformat gdb/python/lib/gdb/missing_debug.py with black after commit 12829 e8c3dafa5f5 ("[gdb/python] Don't import curses.ascii module unless necessary"). 12830 128312023-11-23 Tom Tromey <tromey@adacore.com> 12832 12833 Fix build with GCC 7.5 12834 A recent change to 'struct field' caused a build failure with GCC 12835 7.5.0, as reported by Tom de Vries: 12836 12837 /data/vries/gdb/src/gdb/gdbtypes.h:721:51: error: 12838 ‘field::m_accessibility’ is too small to hold all values of ‘enum 12839 class accessibility’ [-Werror] 12840 ENUM_BITFIELD (accessibility) m_accessibility : 2; 12841 ^ 12842 12843 Mark Wielaard pointed out that this was a GCC bug: 12844 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 12845 12846 This patch works around the bug by changing several members not to be 12847 bitfields. It reduces the size of the enum's underlying type, 12848 instead. 12849 12850 I also changed m_bitsize to no longer be a bitfield -- that was done 12851 for packing reasons in ancient times, but with m_accessibility not 12852 being a bitfield, this no longer matters. 12853 12854 I removed fn_field::dummy. In earlier times it was somewhat normal in 12855 gdb to have these dummy fields to keep track of any available padding. 12856 However, since the advent of "ptype/o", there doesn't seem to be any 12857 need for this. 12858 12859 This patch does not change the size of struct field, fn_field, or 12860 decl_field on 64-bit hosts. 12861 128622023-11-23 Jin Ma <jinma@linux.alibaba.com> 12863 12864 RISC-V: Add vector permutation instructions for T-Head VECTOR vendor extension 12865 T-Head has a range of vendor-specific instructions. Therefore 12866 it makes sense to group them into smaller chunks in form of 12867 vendor extensions. 12868 12869 This patch adds permutation instructions for the "XTheadVector" 12870 extension. The 'th' prefix and the "XTheadVector" extension 12871 are documented in a PR for the RISC-V toolchain conventions ([1]). 12872 12873 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 12874 12875 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 12876 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 12877 12878 gas/ChangeLog: 12879 12880 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 12881 permutation instructions. 12882 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 12883 12884 include/ChangeLog: 12885 12886 * opcode/riscv-opc.h (MATCH_TH_VMVXS): New. 12887 12888 opcodes/ChangeLog: 12889 12890 * riscv-opc.c: Likewise. 12891 128922023-11-23 Jin Ma <jinma@linux.alibaba.com> 12893 12894 RISC-V: Add vector mask instructions for T-Head VECTOR vendor extension 12895 T-Head has a range of vendor-specific instructions. Therefore 12896 it makes sense to group them into smaller chunks in form of 12897 vendor extensions. 12898 12899 This patch adds mask instructions for the "XTheadVector" 12900 extension. The 'th' prefix and the "XTheadVector" extension 12901 are documented in a PR for the RISC-V toolchain conventions ([1]). 12902 12903 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 12904 12905 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 12906 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 12907 12908 gas/ChangeLog: 12909 12910 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 12911 mask instructions. 12912 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 12913 12914 include/ChangeLog: 12915 12916 * opcode/riscv-opc.h (MATCH_TH_VMPOPCM): New. 12917 12918 opcodes/ChangeLog: 12919 12920 * riscv-opc.c: Likewise. 12921 129222023-11-23 Jin Ma <jinma@linux.alibaba.com> 12923 12924 RISC-V: Add reductions instructions for T-Head VECTOR vendor extension 12925 T-Head has a range of vendor-specific instructions. Therefore 12926 it makes sense to group them into smaller chunks in form of 12927 vendor extensions. 12928 12929 This patch adds reductions instructions for the "XTheadVector" 12930 extension. The 'th' prefix and the "XTheadVector" extension 12931 are documented in a PR for the RISC-V toolchain conventions ([1]). 12932 12933 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 12934 12935 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 12936 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 12937 12938 gas/ChangeLog: 12939 12940 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 12941 reductions instructions. 12942 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 12943 12944 opcodes/ChangeLog: 12945 12946 * riscv-opc.c: Likewise. 12947 129482023-11-23 Jin Ma <jinma@linux.alibaba.com> 12949 12950 RISC-V: Add floating-point arithmetic instructions for T-Head VECTOR vendor extension 12951 T-Head has a range of vendor-specific instructions. Therefore 12952 it makes sense to group them into smaller chunks in form of 12953 vendor extensions. 12954 12955 This patch adds floating-point arithmetic instructions for the 12956 "XTheadVector" extension. The 'th' prefix and the 12957 "XTheadVector" extension are documented in a PR for the 12958 RISC-V toolchain conventions ([1]). 12959 12960 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 12961 12962 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 12963 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 12964 12965 gas/ChangeLog: 12966 12967 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 12968 floating-point arithmetic instructions. 12969 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 12970 12971 include/ChangeLog: 12972 12973 * opcode/riscv-opc.h (MATCH_TH_VFSQRTV): New. 12974 12975 opcodes/ChangeLog: 12976 12977 * riscv-opc.c: Likewise. 12978 129792023-11-23 Jin Ma <jinma@linux.alibaba.com> 12980 12981 RISC-V: Add fixed-point arithmetic instructions for T-Head VECTOR vendor extension 12982 T-Head has a range of vendor-specific instructions. Therefore 12983 it makes sense to group them into smaller chunks in form of 12984 vendor extensions. 12985 12986 This patch adds fixed-point arithmetic instructions for the 12987 "XTheadVector" extension. The 'th' prefix and the 12988 "XTheadVector" extension are documented in a PR for the 12989 RISC-V toolchain conventions ([1]). 12990 12991 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 12992 12993 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 12994 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 12995 12996 gas/ChangeLog: 12997 12998 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 12999 fixed-point arithmetic instructions. 13000 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 13001 13002 include/ChangeLog: 13003 13004 * opcode/riscv-opc.h (MATCH_TH_VAADDVV): New. 13005 13006 opcodes/ChangeLog: 13007 13008 * riscv-opc.c: Likewise. 13009 130102023-11-23 Jin Ma <jinma@linux.alibaba.com> 13011 13012 RISC-V: Add integer arithmetic instructions for T-Head VECTOR vendor extension 13013 T-Head has a range of vendor-specific instructions. Therefore 13014 it makes sense to group them into smaller chunks in form of 13015 vendor extensions. 13016 13017 This patch adds integer arithmetic instructions for the 13018 "XTheadVector" extension. The 'th' prefix and the 13019 "XTheadVector" extension are documented in a PR for the 13020 RISC-V toolchain conventions ([1]). 13021 13022 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13023 13024 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13025 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13026 13027 gas/ChangeLog: 13028 13029 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 13030 integer arithmetic instructions. 13031 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 13032 13033 include/ChangeLog: 13034 13035 * opcode/riscv-opc.h (MATCH_TH_VADCVVM): New. 13036 13037 opcodes/ChangeLog: 13038 13039 * riscv-opc.c: Likewise. 13040 130412023-11-23 Jin Ma <jinma@linux.alibaba.com> 13042 13043 RISC-V: Add sub-extension XTheadZvamo for T-Head VECTOR vendor extension 13044 T-Head has a range of vendor-specific instructions. Therefore 13045 it makes sense to group them into smaller chunks in form of 13046 vendor extensions. 13047 13048 This patch adds the sub-extension "XTheadZvamo" for the 13049 "XTheadVector" extension, and it provides AMO instructions 13050 for T-Head VECTOR vendor extension. The 'th' prefix and the 13051 "XTheadVector" extension are documented in a PR for the 13052 RISC-V toolchain conventions ([1]). 13053 13054 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13055 13056 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13057 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13058 13059 bfd/ChangeLog: 13060 13061 * elfxx-riscv.c (riscv_multi_subset_supports): Add support 13062 for "XTheadZvamo" extension. 13063 (riscv_multi_subset_supports_ext): Likewise. 13064 13065 gas/ChangeLog: 13066 13067 * doc/c-riscv.texi: 13068 * testsuite/gas/riscv/x-thead-vector-zvamo.d: New test. 13069 * testsuite/gas/riscv/x-thead-vector-zvamo.s: New test. 13070 13071 include/ChangeLog: 13072 13073 * opcode/riscv-opc.h (MATCH_TH_VAMOADDWV): New. 13074 * opcode/riscv.h (enum riscv_insn_class): Add insn class. 13075 13076 opcodes/ChangeLog: 13077 13078 * riscv-opc.c: Likewise. 13079 130802023-11-23 Jin Ma <jinma@linux.alibaba.com> 13081 13082 RISC-V: Add load/store segment instructions for T-Head VECTOR vendor extension 13083 T-Head has a range of vendor-specific instructions. Therefore it 13084 makes sense to group them into smaller chunks in form of vendor 13085 extensions. 13086 13087 This patch adds provides load/store segment instructions for T-Head VECTOR 13088 vendor extension, which same as the "Zvlsseg" extension in RVI 0.71 vector 13089 extension, but belongs to the "XTheadVector" extension. The 'th' prefix 13090 and the "XTheadVector" extension are documented in a PR for the 13091 RISC-V toolchain conventions ([1]). 13092 13093 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13094 13095 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13096 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13097 13098 gas/ChangeLog: 13099 13100 * testsuite/gas/riscv/x-thead-vector.d: Add test. 13101 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 13102 13103 include/ChangeLog: 13104 13105 * opcode/riscv-opc.h (MATCH_TH_VLSEG2BV): New. 13106 13107 opcodes/ChangeLog: 13108 13109 * riscv-opc.c: Likewise. 13110 131112023-11-23 Jin Ma <jinma@linux.alibaba.com> 13112 13113 RISC-V: Add load/store instructions for T-Head VECTOR vendor extension 13114 T-Head has a range of vendor-specific instructions. Therefore 13115 it makes sense to group them into smaller chunks in form of 13116 vendor extensions. 13117 13118 This patch adds load/store instructions for the "XTheadVector" 13119 extension. The 'th' prefix and the "XTheadVector" extension are 13120 documented in a PR for the RISC-V toolchain conventions ([1]). 13121 13122 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13123 13124 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13125 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13126 13127 gas/ChangeLog: 13128 13129 * testsuite/gas/riscv/x-thead-vector.d: Add tests for 13130 load/store instructions. 13131 * testsuite/gas/riscv/x-thead-vector.s: Likewise. 13132 13133 include/ChangeLog: 13134 13135 * opcode/riscv-opc.h (MATCH_TH_VLBV): New. 13136 13137 opcodes/ChangeLog: 13138 13139 * riscv-opc.c: Likewise. 13140 131412023-11-23 Jin Ma <jinma@linux.alibaba.com> 13142 13143 RISC-V: Add configuration-setting instructions for T-Head VECTOR vendor extension 13144 T-Head has a range of vendor-specific instructions. 13145 Therefore it makes sense to group them into smaller chunks 13146 in form of vendor extensions. 13147 13148 This patch adds configuration-setting instructions for the "XTheadVector" 13149 extension. The 'th' prefix and the "XTheadVector" extension are documented 13150 in a PR for the RISC-V toolchain conventions ([1]). 13151 13152 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13153 13154 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13155 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13156 13157 gas/ChangeLog: 13158 13159 * testsuite/gas/riscv/x-thead-vector.d: New test. 13160 * testsuite/gas/riscv/x-thead-vector.s: New test. 13161 13162 opcodes/ChangeLog: 13163 13164 * riscv-opc.c: Likewise.. 13165 131662023-11-23 Jin Ma <jinma@linux.alibaba.com> 13167 13168 RISC-V: Add CSRs for T-Head VECTOR vendor extension 13169 T-Head has a range of vendor-specific instructions. 13170 Therefore it makes sense to group them into smaller chunks 13171 in form of vendor extensions. 13172 13173 This patch adds the CSRs for XTheadVector. Because of the 13174 conflict between encoding and teh 'V' extension, it is implemented 13175 by alias. The 'th' prefix and the "XTheadVector" extension are 13176 documented in a PR for the RISC-V toolchain conventions ([1]). 13177 13178 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13179 13180 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13181 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13182 13183 gas/ChangeLog: 13184 13185 * config/tc-riscv.c (enum riscv_csr_class): Add the class for 13186 the CSRs of the "XTheadVector" extension. 13187 (riscv_csr_address): Likewise. 13188 * testsuite/gas/riscv/x-thead-vector-csr-warn.d: New test. 13189 * testsuite/gas/riscv/x-thead-vector-csr-warn.l: New test. 13190 * testsuite/gas/riscv/x-thead-vector-csr.d: New test. 13191 * testsuite/gas/riscv/x-thead-vector-csr.s: New test. 13192 13193 include/ChangeLog: 13194 13195 * opcode/riscv-opc.h (DECLARE_CSR_ALIAS): Likewise. 13196 13197 opcodes/ChangeLog: 13198 13199 * riscv-dis.c (print_insn_args): Prefix the CSRs disassembly with 'th'. 13200 132012023-11-23 Jin Ma <jinma@linux.alibaba.com> 13202 13203 RISC-V: Add T-Head VECTOR vendor extension. 13204 T-Head has a range of vendor-specific instructions ([2]). 13205 Therefore it makes sense to group them into smaller chunks 13206 in form of vendor extensions. 13207 13208 This patch adds the "XTheadVector" extension, a collection of 13209 T-Head-specific vector instructions. The 'th' prefix and the 13210 "XTheadVector" extension are documented in a PR for the RISC-V 13211 toolchain conventions ([1]). 13212 13213 Here are some things that need to be explained: 13214 The "XTheadVector" extension is not a custom-extension, but 13215 a non-standard non-conforming extension. The encoding space 13216 of the "TheadVector" instructions overlaps with those of 13217 the 'V' extension. This encoding space conflict is not on 13218 purpose, but the result of issues in the past that have 13219 been resolved since. Therefore, the "XTheadVector" extension 13220 and the 'V' extension are in conflict. 13221 13222 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 13223 [2] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf 13224 13225 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 13226 Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu> 13227 13228 bfd/ChangeLog: 13229 13230 * elfxx-riscv.c (riscv_parse_check_conflicts): The 13231 "XTheadVector" extension and the 'V' extension are in conflict. 13232 (riscv_multi_subset_supports): Likewise.. 13233 (riscv_multi_subset_supports_ext): Likewise. 13234 13235 gas/ChangeLog: 13236 13237 * doc/c-riscv.texi: 13238 * testsuite/gas/riscv/x-thead-vector-fail.d: New test. 13239 * testsuite/gas/riscv/x-thead-vector-fail.l: New test. 13240 * testsuite/gas/riscv/x-thead-vector.s: New test. 13241 13242 include/ChangeLog: 13243 13244 * opcode/riscv.h (enum riscv_insn_class): 13245 132462023-11-23 GDB Administrator <gdbadmin@sourceware.org> 13247 13248 Automatic date update in version.in 13249 132502023-11-22 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 13251 13252 Fix AIX thr!= NULL assertion failure during fork. 13253 In AIX, while we followed the child process and detach on fork was on we hit thr!= NULL assertion failure. 13254 13255 The reason for the same was GDB core trying to switch to a child thread with tid not set that does not 13256 exist, since child's ptid was changed to ptid_t (pid, 0, tid) in sync_threadlists() as it was threaded. 13257 13258 The way this happened was when a new child process is born, its object file will be loaded, calling the new_objfile () 13259 in aix-thread.c file from clone_program_space, which is 13260 called from within follow_fork_inferior. Therefore it end ups syncing threadlists via pd_update (). 13261 13262 This patch is a fix for the same where pd_update () is called in the wait () or in update_thread_list() hook only. 13263 132642023-11-22 Tom de Vries <tdevries@suse.de> 13265 13266 [gdb/tui] Fix resizing of terminal to 1 or 2 lines 13267 When starting TUI in a terminal with 3 lines: 13268 ... 13269 $ echo $LINES 13270 3 13271 $ gdb -q -tui 13272 ... 13273 and resizing the terminal to 2 lines we run into a segfault. 13274 13275 The problem is that for the source window: 13276 - the minimum height is 3 (the default), but 13277 - the maximum height is only 2 because there are only 2 lines. 13278 13279 This discrepancy eventually leads to a call to newwin in make_window with: 13280 ... 13281 (gdb) p height 13282 $1 = 3 13283 (gdb) p width 13284 $2 = 56 13285 (gdb) p y 13286 $3 = -1 13287 (gdb) p x 13288 $4 = 0 13289 ... 13290 which results in a nullptr. 13291 13292 This violates the assumption here in tui_apply_current_layout: 13293 .... 13294 /* Get the new list of currently visible windows. */ 13295 std::vector<tui_win_info *> new_tui_windows; 13296 applied_layout->get_windows (&new_tui_windows); 13297 ... 13298 that get_windows only returns visible windows, which leads to tui_windows 13299 holding a dangling pointer, which results in the segfault. 13300 13301 Fix this by: 13302 - making sure get_windows only returns visible windows, and 13303 - detecting the situation and dropping windows from the layout if 13304 there's no room for them. 13305 13306 Tested on x86_64-linux. 13307 13308 Approved-By: Tom Tromey <tom@tromey.com> 13309 13310 PR tui/31044 13311 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044 13312 133132023-11-22 Tom de Vries <tdevries@suse.de> 13314 13315 [gdb/tui] Allow command window of 1 or 2 lines 13316 When starting TUI in a terminal with 2 lines (likewise with 1 line): 13317 ... 13318 $ echo $LINES 13319 2 13320 $ gdb -q -tui 13321 ... 13322 we run into this assert in tui_apply_current_layout: 13323 ... 13324 /* This should always be made visible by a layout. */ 13325 gdb_assert (TUI_CMD_WIN != nullptr); 13326 ... 13327 13328 The problem is that for the command window: 13329 - the minimum height is 3 (the default), but 13330 - the maximum height is only 2 because there are only 2 lines. 13331 13332 This discrepancy eventually leads to a call to newwin in make_window with: 13333 ... 13334 (gdb) p height 13335 $1 = 3 13336 (gdb) p width 13337 $2 = 66 13338 (gdb) p y 13339 $3 = -1 13340 (gdb) p x 13341 $4 = 0 13342 (gdb) 13343 ... 13344 which results in a nullptr, which eventually triggers the assert. 13345 13346 The easiest way to fix this is to change the minimum height of the command 13347 window to 1. However, that would also change behaviour for the case that the 13348 screen size is 3 lines or more. For instance, in gdb.tui/winheight.exp the 13349 number of lines in the terminal is 24, and the test-case checks that the user 13350 cannot increase the source window height to the point that the command window 13351 height would be less than 3. 13352 13353 Fix this by calculating the minimum height of the command window as follows: 13354 - the default (3) if max_height () allows it, and 13355 - max_height () otherwise. 13356 13357 Tested on x86_64-linux. 13358 13359 Approved-By: Tom Tromey <tom@tromey.com> 13360 13361 PR tui/31044 13362 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044 13363 133642023-11-22 Tom de Vries <tdevries@suse.de> 13365 13366 [gdb/python] Don't import curses.ascii module unless necessary 13367 I ran into a failure in test-case gdb.python/py-missing-debug.exp with python 13368 3.6, which was fixed by commit 7db795bc67a ("gdb/python: remove use of 13369 str.isascii()"). 13370 13371 However, I subsequently ran into a failure with python 3.11: 13372 ... 13373 (gdb) PASS: $exp: initial checks: debug info no longer found 13374 source py-missing-debug.py^M 13375 Traceback (most recent call last):^M 13376 File "py-missing-debug.py", line 17, in <module>^M 13377 from gdb.missing_debug import MissingDebugHandler^M 13378 File "missing_debug.py", line 21, in <module>^M 13379 from curses.ascii import isascii, isalnum^M 13380 File "/usr/lib64/python3.11/_import_failed/curses.py", line 16, in <module>^M 13381 raise ImportError(f"""Module '{failed_name}' is not installed.^M 13382 ImportError: Module 'curses' is not installed.^M 13383 Use:^M 13384 sudo zypper install python311-curses^M 13385 to install it.^M 13386 (gdb) FAIL: $exp: source python script 13387 ... 13388 13389 Apparently I have the curses module installed for 3.6, but not 3.11. 13390 13391 I could just install it, but the test-case worked fine with 3.11 before commit 13392 7db795bc67a. 13393 13394 Fix this by only using the curses module when necessary, for python <= 3.7. 13395 13396 Tested on x86_64-linux, with both python 3.6 and 3.11. 13397 133982023-11-22 Andrew Burgess <aburgess@redhat.com> 13399 13400 gdbserver: cleanup monitor_show_help 13401 After this commit: 13402 13403 commit 0b04e52316079981b2b77124198a405d826a05cd 13404 Date: Sun Jan 19 14:33:37 2014 -0700 13405 13406 link gdbserver against libiberty 13407 13408 we can cleanup how the help text is generated in monitor_show_help. 13409 This doesn't change the output that the user will see -- it just folds 13410 multiple monitor_output calls into one. 13411 13412 There should be no user visible change after this commit. 13413 134142023-11-22 Lulu Cai <cailulu@loongson.cn> 13415 13416 LoongArch: fix internal error when as handling unsupported modifier. 13417 134182023-11-22 GDB Administrator <gdbadmin@sourceware.org> 13419 13420 Automatic date update in version.in 13421 134222023-11-21 Tom Tromey <tromey@adacore.com> 13423 13424 Simplify C++ type-printing 13425 The C++ type-printing code had its own variant of the accessibility 13426 enum. This patch removes this and changes the code to use the new one 13427 from gdbtypes.h. 13428 13429 This patch also changes the C++ code to recognize the default 13430 accessibility of a class. This makes ptype a bit more C++-like, and 13431 lets us remove a chunk of questionable code. 13432 13433 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13434 Reviewed-by: Keith Seitz <keiths@redhat.com> 13435 134362023-11-21 Tom Tromey <tromey@adacore.com> 13437 13438 Use enum accessibility in types and member functions 13439 This changes nested types and member functions to use the new 13440 'accessibility' enum, rather than separate private/protected flags. 13441 This is done for consistency, but it also lets us simplify some other 13442 code in the next patch. 13443 13444 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13445 Reviewed-by: Keith Seitz <keiths@redhat.com> 13446 134472023-11-21 Tom Tromey <tromey@adacore.com> 13448 13449 Remove char-based bitfield macros 13450 This removes the char-based bitfield macros from gdbtypes.h, as they 13451 are no longer used. 13452 13453 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13454 Reviewed-by: Keith Seitz <keiths@redhat.com> 13455 134562023-11-21 Tom Tromey <tromey@adacore.com> 13457 13458 Remove some type field accessor macros 13459 This removes TYPE_FIELD_PRIVATE, TYPE_FIELD_PROTECTED, 13460 TYPE_FIELD_IGNORE, and TYPE_FIELD_VIRTUAL. 13461 13462 In c-varobj.c, match_accessibility can be removed entirely now. Note 13463 that the comment before this function was incorrect. 13464 13465 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13466 Reviewed-by: Keith Seitz <keiths@redhat.com> 13467 134682023-11-21 Tom Tromey <tromey@adacore.com> 13469 13470 Remove some QUIT calls from need_access_label_p 13471 I think these invocations of QUIT in need_access_label_p are overkill. 13472 QUIT is already called from its caller. This just removes them. 13473 13474 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13475 Reviewed-by: Keith Seitz <keiths@redhat.com> 13476 134772023-11-21 Tom Tromey <tromey@adacore.com> 13478 13479 Add field::is_public 13480 This adds a field::is_public convenience method, and updates one spot 13481 to use it. 13482 13483 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13484 Reviewed-by: Keith Seitz <keiths@redhat.com> 13485 134862023-11-21 Tom Tromey <tromey@adacore.com> 13487 13488 Remove byte vectors from cplus_struct_type 13489 This removes some byte vectors from cplus_struct_type, moving the 13490 information into bitfields in holes in struct field. 13491 13492 A new 'enum accessibility' is added to hold some of this information. 13493 A similar enum is removed from c-varobj.c. 13494 13495 Note that the stabs reader treats "ignored" as an accessibility. 13496 However, the stabs texinfo documents this as a public field that is 13497 optimized out -- unfortunately nobody has updated the stabs reader to 13498 use the better value-based optimized-out machinery. I looked and 13499 apparently gcc never emitted this visibility value, so whatever 13500 compiler generated this stab is unknown. I left a comment in 13501 gdbtypes.h to this effect. 13502 13503 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13504 Reviewed-by: Keith Seitz <keiths@redhat.com> 13505 135062023-11-21 Tom Tromey <tromey@adacore.com> 13507 13508 Print field accessibility inline 13509 This changes recursive_dump_type to print field accessibility 13510 information "inline". This is clearer and preserves the information 13511 when the byte vectors are removed. 13512 13513 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13514 Reviewed-by: Keith Seitz <keiths@redhat.com> 13515 135162023-11-21 Tom Tromey <tromey@adacore.com> 13517 13518 Use .def file to stringify type codes 13519 This changes recursive_dump_type to reuse the type-codes.def file when 13520 stringifying type codes. 13521 13522 This version of the patch changes the "unknown" case to an assert. 13523 13524 Acked-By: Simon Marchi <simon.marchi@efficios.com> 13525 Reviewed-by: Keith Seitz <keiths@redhat.com> 13526 135272023-11-21 Cupertino Miranda <cupertino.miranda@oracle.com> 13528 13529 bpf: Fixed register parsing disambiguating with possible symbol. 13530 This changes parse_bpf_register to detect possible symbols that start with valid 13531 register name, however due some following characters are not. 13532 Also changed the regs-for-symbols-pseudo.s, adding some entries that 13533 should not error if parser is properly detecting the symbol. 13534 135352023-11-21 Jan-Benedict Glaw <jbglaw@lug-owl.de> 13536 13537 [opcodes] ARC + PPC: Fix -Walloc-size warnings 13538 Recently, -Walloc-size warnings started to kick in. Fix these two 13539 calloc() calls to match the intended usage pattern. 13540 13541 opcodes/ChangeLog: 13542 13543 * arc-dis.c (init_arc_disasm_info): Fix calloc() call. 13544 * ppc-dis.c (powerpc_init_dialect): Ditto. 13545 135462023-11-21 Simon Marchi <simon.marchi@efficios.com> 13547 13548 gdb: fix build of darwin-nat.c 13549 Patch 743877128 ("gdb: remove regcache's address space") changed the 13550 signature of darwin_nat_target::cancel_breakpoint, but missing updating 13551 the class declaration, resulting in: 13552 13553 CXX darwin-nat.o 13554 /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1154:20: error: out-of-line definition of 'cancel_breakpoint' does not match any declaration in 'darwin_nat_target' 13555 darwin_nat_target::cancel_breakpoint (inferior *inf, ptid_t ptid) 13556 ^~~~~~~~~~~~~~~~~ 13557 /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1290:9: error: too many arguments to function call, expected single argument 'ptid', have 2 arguments 13558 ptid_t (inf->pid, 0, thread->gdb_port))) 13559 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13560 /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.h:129:7: note: 'cancel_breakpoint' declared here 13561 int cancel_breakpoint (ptid_t ptid); 13562 ^ 13563 13564 Fix that. 13565 13566 Change-Id: Iedd58b36777eb77bca9e23f94882b217c9c87059 13567 135682023-11-21 Tom Tromey <tromey@adacore.com> 13569 13570 Refactor DAP queue handling 13571 A couple of spots in the DAP code use the same workaround for the 13572 absence of queue.SimpleQueue before Python 3.6. This patch 13573 consolidates these into a single spot. 13574 135752023-11-21 Tom de Vries <tdevries@suse.de> 13576 13577 [gdb/tdep] Handle memory error in s390_linux_get_syscall_number 13578 In s390_linux_get_syscall_number, we use read_memory_unsigned_integer, which 13579 can throw a memory error. 13580 13581 According to the function comment though, it should return -1 on error: 13582 ... 13583 /* Retrieve the syscall number at a ptrace syscall-stop. Return -1 13584 upon error. */ 13585 ... 13586 13587 Catch the memory error by using safe_read_memory_unsigned_integer instead, 13588 similar to how that was fixed for arm in commit eb42bb14895 ("[gdb/tdep] Fix 13589 catching syscall execve exit for arm"). 13590 13591 Approved-By: Ulrich Weigand <uweigand@de.ibm.com> 13592 135932023-11-21 Tom de Vries <tdevries@suse.de> 13594 13595 [gdb/testsuite] Fix spurious FAILs with examine-backward.exp, again 13596 Commit 59a561480d5 ("Fix spurious FAILs with examine-backward.exp") describes 13597 the problem that: 13598 ... 13599 The test case examine-backward.exp issues the command "x/-s" after the end 13600 of the first string in TestStrings, but without making sure that this 13601 string is preceded by a string terminator. Thus GDB may spuriously print 13602 some random characters from before that string, and then the test fails. 13603 ... 13604 13605 The commit fixes the problem by adding a Barrier variable before the TestStrings 13606 variable: 13607 ... 13608 +const char Barrier[] = { 0x0 }; 13609 const char TestStrings[] = { 13610 ... 13611 13612 There is however no guarantee that Barrier is placed immediately before 13613 TestStrings. 13614 13615 Before recent commit 169fe7ab54b ("Change gdb.base/examine-backwards.exp for 13616 AIX.") on x86_64-linux, I see: 13617 ... 13618 0000000000400660 R Barrier 13619 0000000000400680 R TestStrings 13620 ... 13621 13622 So while the Barrier variable is the first before the TestStrings variable, 13623 it's not immediately preceding TestStrings. 13624 13625 After commit 169fe7ab54b: 13626 ... 13627 0000000000402259 B Barrier 13628 0000000000402020 D TestStrings 13629 ... 13630 they're not even in the same section anymore. 13631 13632 Fix this reliably by adding the zero in the array itself: 13633 ... 13634 char TestStringsBase[] = { 13635 0x0, 13636 ... 13637 }; 13638 char *TestStrings = &TestStringsBase[1]; 13639 ... 13640 and do likewise for TestStringsH and TestStringsW. 13641 13642 Tested on x86_64-linux. 13643 13644 PR testsuite/31064 13645 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31064 13646 136472023-11-21 Lancelot Six <lancelot.six@amd.com> 13648 13649 gdb: Use initializers in lambda captures unconditionally 13650 Initializers in lambda captures were introduced in C++14, and 13651 conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c. 13652 13653 Since C++17 is now required by GDB, use this feature unconditionally. 13654 13655 Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d 13656 Approved-By: Tom Tromey <tom@tromey.com> 13657 Approved-By: Pedro Alves <pedro@palves.net> 13658 136592023-11-21 Lancelot Six <lancelot.six@amd.com> 13660 13661 gdb/disasm.h: Mark callbacks noexcept unconditionally 13662 Given that C++17 is now a requirement for GDB, update gdb/disasm.h to 13663 define callback function types noexcept unconditionally. The pre-C++17 13664 configuration is not supported anymore. 13665 13666 Change-Id: I0a38e22b7912c70a11425363a991f0b01614343e 13667 Approved-By: Tom Tromey <tom@tromey.com> 13668 Approved-By: Pedro Alves <pedro@palves.net> 13669 136702023-11-21 Lancelot Six <lancelot.six@amd.com> 13671 13672 gdbsupport: Replace gdb::invoke_result with std::invoke_result 13673 Given that GDB now requires C++17, we can replace gdb::invoke_result 13674 with std::invoke_result which is provided by <type_traits>. 13675 13676 This patch also removes gdbsupport/invoke-result.h as it is not used 13677 anymore. 13678 13679 Change-Id: I7e567356d38d6b3d85d8797d61cfc83f6f933f22 13680 Approved-By: Tom Tromey <tom@tromey.com> 13681 Approved-By: Pedro Alves <pedro@palves.net> 13682 136832023-11-21 Lancelot Six <lancelot.six@amd.com> 13684 13685 gdbsupport: Remove gdb::string_view 13686 Now that all places using gdb::string_view have been updated to use 13687 std::string_view, this patch drops the gdb::string_view implementation 13688 and the tests which came with it. 13689 13690 As this drops the unittests/string_view-selftests.c, this also 13691 implicitly solves PR build/23676, as pointed-out by Tom Tromey. 13692 13693 Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0 13694 Approved-By: Tom Tromey <tom@tromey.com> 13695 Approved-By: Pedro Alves <pedro@palves.net> 13696 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676 13697 136982023-11-21 Lancelot Six <lancelot.six@amd.com> 13699 13700 gdb: Remove uses of gdb::to_string (const std::string_view &) 13701 This patch removes all uses of to_string(const std::string_view&) and 13702 use the std::string ctor or implicit conversion from std::string_view to 13703 std::string instead. 13704 13705 A later patch will remove this gdb::to_string while removing 13706 gdbsupport/gdb_string_view.h. 13707 13708 Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895 13709 Approved-By: Tom Tromey <tom@tromey.com> 13710 Approved-By: Pedro Alves <pedro@palves.net> 13711 137122023-11-21 Lancelot Six <lancelot.six@amd.com> 13713 13714 gdb: Use std::string_view instead of gdb::string_view 13715 Given that GDB now requires a C++17, replace all uses of 13716 gdb::string_view with std::string_view. 13717 13718 This change has mostly been done automatically: 13719 - gdb::string_view -> std::string_view 13720 - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> 13721 13722 One things which got brought up during review is that gdb::stging_view 13723 does support being built from "nullptr" while std::sting_view does not. 13724 Two places are manually adjusted to account for this difference: 13725 gdb/tui/tui-io.c:tui_getc_1 and 13726 gdbsupport/format.h:format_piece::format_piece. 13727 13728 The above automatic change transformed 13729 "gdb::to_string (const gdb::string_view &)" into 13730 "gdb::to_string (const std::string_view &)". The various direct users 13731 of this function are now explicitly including 13732 "gdbsupport/gdb_string_view.h". A later patch will remove the users of 13733 gdb::to_string. 13734 13735 The implementation and tests of gdb::string_view are unchanged, they will 13736 be removed in a following patch. 13737 13738 Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 13739 Approved-By: Tom Tromey <tom@tromey.com> 13740 Approved-By: Pedro Alves <pedro@palves.net> 13741 137422023-11-21 Lancelot Six <lancelot.six@amd.com> 13743 13744 gdbsupport: remove gdb::optional 13745 The previous patch migrated all the uses of gdb::optional to use 13746 std::optional instead, so gdb::optional can be removed entirely 13747 as well as the self-tests which came with it. 13748 13749 Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7 13750 Approved-By: Tom Tromey <tom@tromey.com> 13751 Approved-By: Pedro Alves <pedro@palves.net> 13752 137532023-11-21 Lancelot Six <lancelot.six@amd.com> 13754 13755 gdb: Replace gdb::optional with std::optional 13756 Since GDB now requires C++17, we don't need the internally maintained 13757 gdb::optional implementation. This patch does the following replacing: 13758 - gdb::optional -> std::optional 13759 - gdb::in_place -> std::in_place 13760 - #include "gdbsupport/gdb_optional.h" -> #include <optional> 13761 13762 This change has mostly been done automatically. One exception is 13763 gdbsupport/thread-pool.* which did not use the gdb:: prefix as it 13764 already lives in the gdb namespace. 13765 13766 Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 13767 Approved-By: Tom Tromey <tom@tromey.com> 13768 Approved-By: Pedro Alves <pedro@palves.net> 13769 137702023-11-21 Lancelot Six <lancelot.six@amd.com> 13771 13772 gdb: Use C++17's std::make_unique instead of gdb::make_unique 13773 gdb::make_unique is a wrapper around std::make_unique when compiled with 13774 C++17. Now that C++17 is required, use std::make_unique directly in the 13775 codebase, and remove gdb::make_unique. 13776 13777 Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab 13778 Approved-By: Tom Tromey <tom@tromey.com> 13779 Approved-By: Pedro Alves <pedro@palves.net 13780 137812023-11-21 Nick Clifton <nickc@redhat.com> 13782 13783 Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM 13784 PR 31067 13785 Fix typo in previous delta: defined -> referenced. 13786 137872023-11-21 Tom de Vries <tdevries@suse.de> 13788 13789 [gdb/tdep] Fix catching syscall execve exit for arm 13790 When running test-case gdb.base/catch-syscall.exp on a pinebook (64-bit 13791 aarch64 kernel, 32-bit userland) I run into: 13792 ... 13793 (gdb) PASS: $exp: execve: syscall(s) execve appears in 'info breakpoints' 13794 continue^M 13795 Continuing.^M 13796 ^M 13797 Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from \ 13798 /lib/arm-linux-gnueabihf/libc.so.6^M 13799 (gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve 13800 continue^M 13801 Continuing.^M 13802 process 32392 is executing new program: catch-syscall^M 13803 Cannot access memory at address 0xf77c6a7c^M 13804 (gdb) FAIL: $exp: execve: syscall execve has returned 13805 ... 13806 13807 The memory error is thrown by arm_linux_get_syscall_number, when doing: 13808 ... 13809 /* PC gets incremented before the syscall-stop, so read the 13810 previous instruction. */ 13811 unsigned long this_instr = 13812 read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code); 13813 ... 13814 13815 The reason for the error is that we're stopped at the syscall exit of syscall 13816 execve, and the pc is at the first insn of the new exec, which also happens to 13817 be the first insn in the code segment, so consequently we cannot read the 13818 previous insn. 13819 13820 Fix this by detecting the situation by looking at the register state, similar 13821 to what is done in aarch64_linux_get_syscall_number. 13822 13823 Furthermore, catch the memory error by using safe_read_memory_unsigned_integer 13824 and return -1 instead, matching the documented behaviour of 13825 arm_linux_get_syscall_number. 13826 13827 Finally, rather than using a hardcoded constant 11, introduce an ad-hoc 13828 arm_sys_execve. 13829 13830 Tested on pinebook. 13831 13832 PR tdep/31071 13833 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31071 13834 138352023-11-21 Nick Clifton <nickc@redhat.com> 13836 13837 Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM 13838 PR 31067 13839 * linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton. 13840 * ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave. 13841 138422023-11-21 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 13843 13844 Fix gdb.bas/sigall.exp testcase in AIX. 13845 In AIX, we are not able to see the message of a signal recieved if a debugee recieves a signal. 13846 This is a patch to fix the signal handling done incorrectly in AIX. 13847 13848 We remove the status that represent program recieving a signal and allow host_status_to_waitstatus to 13849 handle it for us. 13850 138512023-11-21 Felix Willgerodt <felix.willgerodt@intel.com> 13852 13853 gdb: Fix segfault with a big .dynamic section size 13854 Consider a binary with an erroneous size of the .dynamic section: 13855 13856 $ readelf -S a.out 13857 ... 13858 [24] .dynamic DYNAMIC 0000000000004c20 00003c20 13859 000000fffffffa40 0000000000000010 WA 7 0 8 13860 ... 13861 13862 This binary causes a segfault in GDB. GDB is trying to write the .dynamic 13863 section into memory allocated on the stack with alloca(). However, the 13864 allocation silently fails and the subsequent access to the memory is 13865 causing the segfault. (On my node at least.) 13866 13867 Stack allocation is a bad idea for something of variable size that GDB has 13868 no control over. So I changed the code to heap allocation. 13869 13870 In addition, I changed the type of sect_size to the type that bfd actually 13871 returns. 13872 13873 There should be no user visible change after this. 13874 13875 Approved-By: Tom Tromey <tom@tromey.com> 13876 138772023-11-21 GDB Administrator <gdbadmin@sourceware.org> 13878 13879 Automatic date update in version.in 13880 138812023-11-20 Tom Tromey <tom@tromey.com> 13882 13883 Restore .gdb_index v9 display in readelf 13884 An earlier patch (commit b05efa39 "readelf..debug-dump=loc displays 13885 bogus base addresses") inadvertently removed support for displaying 13886 .gdb_index v9 sections. 13887 13888 This patch corrects the oversight. I tested this by using readelf on 13889 an appropriate file. 13890 13891 * dwarf.c (display_gdb_index): Restore v9 display code. 13892 138932023-11-20 Carl Love <cel@linux.ibm.com> 13894 13895 PowerPC: Fix test gdb.ada/finish-large.exp 13896 Function Create_large returns a large data structure. On PowerPC, register 13897 r3 contains the address of where the data structure to be returned is to 13898 be stored. However, on exit the ABI does not guarantee that r3 has not 13899 been changed. The GDB finish command prints the return value of the 13900 function at the end of the function. GDB needs to use the 13901 DW_TAG_call_site information to determine the value of r3 on entry to 13902 the function to correctly print the return value at the end of the 13903 function. The test must be compiled with -fvar-tracking for the 13904 DW_TAG_call_site information to be included in the executable file. 13905 13906 This patch adds the -fvar-tracking option to the compile line if the 13907 option is supported. 13908 13909 The patch fixes the one regression error for the test on PowerPC. 13910 13911 The patch has been tested on Power 10 and X86-64 with no regressions. 13912 139132023-11-20 Nick Alcock <nick.alcock@oracle.com> 13914 13915 libctf: adding CU mappings should be idempotent 13916 When CTF finds conflicting types, it usually shoves each definition 13917 into a CTF dictionary named after the compilation unit. 13918 13919 The intent of the obscure "cu-mapped link" feature is to allow you to 13920 implement custom linkers that shove the definitions into other, more 13921 coarse-grained units (say, one per kernel module, even if a module consists 13922 of more than one compilation unit): conflicting types within one of these 13923 larger components are hidden from name lookup so you can only look up (an 13924 arbitrary one of) them by name, but can still be found by chasing type graph 13925 links and are still fully deduplicated. 13926 13927 You do this by calling 13928 ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly, 13929 with different "CU name"s: the ctf_link() following that will put all 13930 conflicting types found in "CU name"s sharing a "bigger lump name" into a 13931 child dict in an archive member named "bigger lump name". 13932 13933 So it's clear enough what happens if you call it repeatedly with the same 13934 "bigger lump name" more than once, because that's the whole point of it: but 13935 what if you call it with the same "CU name" repeatedly? 13936 13937 ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"); 13938 ctf_link_add_cu_mapping (fp, "CU name", "other name"); 13939 13940 This is meant to be the same as just doing the second of these, as if the 13941 first was never called. Alas, this isn't what happens, and what you get is 13942 instead a bit of an inconsistent mess: more or less, the first takes 13943 precedence, which is the exact opposite of what we wanted. 13944 13945 Fix this to work the right way round. 13946 13947 (I plan to add support for CU-mapped links to GNU ld, mainly so that we can 13948 properly *test* this machinery.) 13949 13950 libctf/ChangeLog: 13951 13952 * ctf-link.c (ctf_create_per_cu): Note the behaviour of 13953 repeatedly adding FROMs. 13954 (ctf_link_add_cu_mapping): Implement that behavour. 13955 139562023-11-20 Andrew Burgess <aburgess@redhat.com> 13957 13958 gdb: fix reopen_exec_file for files with target: prefix 13959 Following on from this commit: 13960 13961 commit f2c4f78c813a9cef38b7e9c9ad18822fb9e19345 13962 Date: Thu Sep 21 16:35:30 2023 +0100 13963 13964 gdb: fix reread_symbols when an objfile has target: prefix 13965 13966 In this commit I update reopen_exec_file to correctly handle 13967 executables with a target: prefix. Before this commit we used the 13968 system 'stat' call, which obviously isn't going to work for files with 13969 a target: prefix (files located on a possibly remote target machine). 13970 13971 By switching to bfd_stat we will use remote fileio to stat the remote 13972 files, which means we should now correctly detect changes in a remote 13973 executable. 13974 13975 The program_space::ebfd_mtime variable, with which we compare the 13976 result of bfd_stat is set with a call to bfd_get_mtime, which in turn 13977 calls bfd_stat, so comparing to the result of calling bfd_stat makes 13978 sense (I think). 13979 13980 As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory 13981 BFD, then calling bfd_stat will always return 0, while bfd_get_mtime 13982 will always return the time at which the BFD was created. As a result 13983 comparing the results will always show the file having changed. 13984 13985 I don't believe that GDB can set the main executable to an in-memory 13986 BFD object, so, in this commit, I simply assert that the executable is 13987 not in-memory. If this ever changes then we would need to decide how 13988 to handle this case -- always reload, or never reload. The assert 13989 doesn't appear to trigger for our current test suite. 13990 13991 Approved-By: Tom Tromey <tom@tromey.com> 13992 139932023-11-20 Andrew Burgess <aburgess@redhat.com> 13994 13995 gdb: move all bfd_cache_close_all calls in gdb_bfd.c 13996 In the following commit I ran into a problem. The next commit aims to 13997 improve GDB's handling of the main executable being a file on a remote 13998 target (i.e. one with a 'target:' prefix). 13999 14000 To do this I have replaced a system 'stat' call with a bfd_stat call. 14001 14002 However, doing this caused a regression in gdb.base/attach.exp. 14003 14004 The problem is that the bfd library caches open FILE* handles for bfd 14005 objects that it has accessed, which is great for short-lived, non 14006 interactive programs (e.g. the assembler, or objcopy, etc), however, 14007 for GDB this caching causes us a problem. 14008 14009 If we open the main executable as a bfd then the bfd library will 14010 cache the open FILE*. If some time passes, maybe just sat at the GDB 14011 prompt, or with the inferior running, and then later we use bfd_stat 14012 to check if the underlying, on-disk file has changed, then the bfd 14013 library will actually use fstat on the underlying file descriptor. 14014 This is of course slightly different than using system stat on with 14015 the on-disk file name. 14016 14017 If the on-disk file has changed then system stat will give results for 14018 the current on-disk file. But, if the bfd cache is still holding open 14019 the file descriptor for the original on-disk file (from before the 14020 change) then fstat will return a result based on the original file, 14021 and so show no change as having happened. 14022 14023 This is a known problem in GDB, and so far this has been solved by 14024 scattering bfd_cache_close_all() calls throughout GDB. But, as I 14025 said, in the next commit I've made a change and run into a 14026 problem (gdb.base/attach.exp) where we are apparently missing a 14027 bfd_cache_close_all() call. 14028 14029 Now I could solve this problem by adding a bfd_cache_close_all() call 14030 before the bfd_stat call that I plan to add in the next commit, that 14031 would for sure solve the problem, but feels a little crude. 14032 14033 Better I think would be to track down where the bfd is being opened 14034 and add a corresponding bfd_cache_close_all() call elsewhere in GDB 14035 once we've finished doing whatever it is that caused us to open the 14036 bfd in the first place. 14037 14038 This second solution felt like the better choice, so I tracked the 14039 problem down to elf_locate_base and fixed that. But that just exposed 14040 another problem in gdb_bfd_map_section which was also re-opening the 14041 bfd, so I fixed this (with another bfd_cache_close_all() call), and 14042 that exposed another issue in gdbarch_lookup_osabi... and at this 14043 point I wondered if I was approaching this problem the wrong way... 14044 14045 .... And so, I wonder, is there a _better_ way to handle these 14046 bfd_cache_close_all() calls? 14047 14048 I see two problems with the current approach: 14049 14050 1. It's fragile. Folk aren't always aware that they need to clear 14051 the bfd cache, and this feels like something that is easy to 14052 overlook in review. So adding new code to GDB can innocently touch 14053 a bfd, which populates the cache, which will then be a bug that can 14054 lie hidden until an on-disk file just happens to change at the wrong 14055 time ... and GDB fails to spot the change. Additionally, 14056 14057 2. It's in efficient. The caching is intended to stop the bfd 14058 library from continually having to re-open the on-disk file. If we 14059 have a function that touches a bfd then often that function is the 14060 obvious place to call bfd_cache_close_all. But if a single GDB 14061 command calls multiple functions, each of which touch the bfd, then 14062 we will end up opening and closing the same on-disk file multiple 14063 times. It feels like we would be better postponing the 14064 bfd_cache_close_all call until some later point, then we can benefit 14065 from the bfd cache. 14066 14067 So, in this commit I propose a new approach. We now clear the bfd 14068 cache in two places: 14069 14070 (a) Just before we display a GDB prompt. We display a prompt after 14071 completing a command, and GDB is about to enter an idle state 14072 waiting for further input from the user (or in async mode, for an 14073 inferior event). If while we are in this idle state the user 14074 changes the on-disk file(s) then we would like GDB to notice this 14075 the next time it leaves its idle state, e.g. the next time the user 14076 executes a command, or when an inferior event arrives, 14077 14078 (b) When we resume the inferior. In synchronous mode, resuming the 14079 inferior is another time when GDB is blocked and sitting idle, but 14080 in this case we don't display a prompt. As with (a) above, when an 14081 inferior event arrives we want GDB to notice any changes to on-disk 14082 files. 14083 14084 It turns out that there are existing observers for both of these 14085 cases (before_prompt and target_resumed respectively), so my initial 14086 thought was that I should attach to these observers in gdb_bfd.c, and 14087 in both cases call bfd_cache_close_all(). 14088 14089 And this does indeed solve the gdb.base/attach.exp problem that I see 14090 with the following commit. 14091 14092 However, I see a problem with this solution. 14093 14094 Both of the observers I'm using are exposed through the Python API as 14095 events that a user can hook into. The user can potentially run any 14096 GDB command (using gdb.execute), so Python code might end up causing 14097 some bfds to be reopened, and inserted into the cache. 14098 14099 To solve this one solution would be to add a bfd_cache_close_all() 14100 call into gdbpy_enter::~gdbpy_enter(). Unfortunately, there's no 14101 similar enter/exit object for Guile, though right now Guile doesn't 14102 offer the same event API, so maybe we could just ignore that 14103 problem... but this doesn't feel great. 14104 14105 So instead, I think a better solution might be to not use observers 14106 for the bfd_cache_close_all() calls. Instead, I'll call 14107 bfd_cache_close_all() directly from core GDB after we've notified the 14108 before_prompt and target_resumed observers, this was we can be sure 14109 that the cache is cleared after the observers have run, and before GDB 14110 enters an idle state. 14111 14112 This commit also removes all of the other bfd_cache_close_all() calls 14113 from GDB. My claim is that these are no longer needed. 14114 14115 Approved-By: Tom Tromey <tom@tromey.com> 14116 141172023-11-20 Guinevere Larsen <blarsen@redhat.com> 14118 14119 gdb/infrun: simplify process_event_stop_test 14120 The previous commit introduced some local variables to make some if 14121 statements simpler. This commit uses them more liberally throughout the 14122 process_event_stop_test in order to simplify the function a little more. 14123 No functional changes are expected. 14124 14125 Approved-By: Tom Tromey <tom@tromey.com> 14126 141272023-11-20 Guinevere Larsen <blarsen@redhat.com> 14128 14129 gdb/record: print frame information when exiting a recursive call 14130 Currently, when GDB is reverse stepping out of a function into the same 14131 function due to a recursive call, it doesn't print frame information, as 14132 reported by PR record/29178. This happens because when the inferior 14133 leaves the current frame, GDB decides to refresh the step information, 14134 clobbering the original step_frame_id, making it impossible to figure 14135 out later on that the frame has been changed. 14136 14137 This commit changes GDB so that, if we notice we're in this exact 14138 situation, we won't refresh the step information. 14139 14140 Because of implementation details, this change can cause some debug 14141 information to be read when it normally wouldn't before, which showed up 14142 as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that 14143 isn't a problem, the test was changed to allow for the new output. 14144 14145 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 14146 Approved-By: Tom Tromey <tom@tromey.com> 14147 141482023-11-20 GDB Administrator <gdbadmin@sourceware.org> 14149 14150 Automatic date update in version.in 14151 141522023-11-19 GDB Administrator <gdbadmin@sourceware.org> 14153 14154 Automatic date update in version.in 14155 141562023-11-18 Jose E. Marchesi <jose.marchesi@oracle.com> 14157 14158 gas: bpf: do not allow referring to register names as symbols in operands 14159 2023-11-18 Jose E. Marchesi <jemarch@gnu.org> 14160 14161 * config/tc-bpf.c (parse_bpf_register): Move before 14162 bpf_parse_name. 14163 (bpf_parse_name): Do not allow using symbols that are also 14164 register names as operands in pseudo-c syntax. 14165 * testsuite/gas/bpf/regs-for-symbols-pseudoc.d: New file. 14166 * testsuite/gas/bpf/regs-for-symbols-pseudoc.s: Likewise. 14167 * testsuite/gas/bpf/regs-for-symbols-pseudoc.l: Likewise. 14168 * doc/c-bpf.texi (BPF Registers): Document that it is not possible 14169 to refer to register names as symbols in instruction operands. 14170 141712023-11-18 GDB Administrator <gdbadmin@sourceware.org> 14172 14173 Automatic date update in version.in 14174 141752023-11-17 David Faust <david.faust@oracle.com> 14176 14177 bpf: avoid creating wrong symbols while parsing 14178 To support the "pseudo-C" asm dialect in BPF, the BPF parser must often 14179 attempt multiple different templates for a single instruction. In some 14180 cases this can cause the parser to incorrectly parse part of the 14181 instruction opcode as an expression, which leads to the creation of a 14182 new undefined symbol. 14183 14184 Once the parser recognizes the error, the expression is discarded and it 14185 tries again with a new instruction template. However, symbols created 14186 during the process are added to the symbol table and are not removed 14187 even if the expression is discarded. 14188 14189 This is a problem for BPF: generally the assembled object will be loaded 14190 directly to the Linux kernel, without being linked. These erroneous 14191 parser-created symbols are rejected by the kernel BPF loader, and the 14192 entire object is refused. 14193 14194 This patch remedies the issue by tentatively creating symbols while 14195 parsing instruction operands, and storing them in a temporary list 14196 rather than immediately inserting them into the symbol table. Later, 14197 after the parser is sure that it has correctly parsed the instruction, 14198 those symbols are committed to the real symbol table. 14199 14200 This approach is modeled directly after Jan Beulich's patch for RISC-V: 14201 14202 commit 7a29ee290307087e1749ce610207e93a15d0b78d 14203 RISC-V: adjust logic to avoid register name symbols 14204 14205 Many thanks to Jan for recognizing the problem as similar, and pointing 14206 me to that patch. 14207 14208 gas/ 14209 14210 * config/tc-bpf.c (parsing_insn_operands): New. 14211 (parse_expression): Set it here. 14212 (deferred_sym_rootP, deferred_sym_lastP): New. 14213 (orphan_sym_rootP, orphan_sym_lastP): New. 14214 (bpf_parse_name): New. 14215 (parse_error): Clear deferred symbol list on error. 14216 (md_assemble): Clear parsing_insn_operands. Commit deferred 14217 symbols to symbol table on successful parse. 14218 * config/tc-bpf.h (md_parse_name): Define to... 14219 (bpf_parse_name): ...this. New prototype. 14220 * testsuite/gas/bpf/asm-extra-sym-1.s: New test source. 14221 * testsuite/gas/bpf/asm-extra-sym-1.d: New test. 14222 * testsuite/gas/bpf/bpf.exp: Run new test. 14223 142242023-11-17 Simon Marchi <simon.marchi@efficios.com> 14225 14226 gdb: pass address_space to target dcache functions 14227 A simple refactor to make the reference to current_program_space bubble 14228 up one level. No behavior changes expected. 14229 14230 Change-Id: I237cf2f45ae73c35bcb433ce40e3c03cef6b87e2 14231 142322023-11-17 Simon Marchi <simon.marchi@efficios.com> 14233 14234 gdb: remove get_current_regcache 14235 Remove get_current_regcache, inlining the call to get_thread_regcache in 14236 callers. When possible, pass the right thread_info object known from 14237 the local context. Otherwise, fall back to passing `inferior_thread ()`. 14238 14239 This makes the reference to global context bubble up one level, a small 14240 step towards the long term goal of reducing the number of references to 14241 global context (or rather, moving those references as close as possible 14242 to the top of the call tree). 14243 14244 No behavior change expected. 14245 14246 Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6 14247 142482023-11-17 Simon Marchi <simon.marchi@efficios.com> 14249 14250 gdb: remove regcache's address space 14251 While looking at the regcache code, I noticed that the address space 14252 (passed to regcache when constructing it, and available through 14253 regcache::aspace) wasn't relevant for the regcache itself. Callers of 14254 regcache::aspace use that method because it appears to be a convenient 14255 way of getting the address space for a thread, if you already have the 14256 regcache. But there is always another way to get the address space, as 14257 the callers pretty much always know which thread they are dealing with. 14258 The regcache code itself doesn't use the address space. 14259 14260 This patch removes anything related to address_space from the regcache 14261 code, and updates callers to get it from the thread in context. This 14262 removes a bit of unnecessary complexity from the regcache code. 14263 14264 The current get_thread_arch_regcache function gets an address_space for 14265 the given thread using the target_thread_address_space function (which 14266 calls the target_ops::thread_address_space method). This suggest that 14267 there might have been the intention of supporting per-thread address 14268 spaces. But digging through the history, I did not find any such case. 14269 Maybe this method was just added because we needed a way to get an 14270 address space from a ptid (because constructing a regcache required an 14271 address space), and this seemed like the right way to do it, I don't 14272 know. 14273 14274 The only implementations of thread_address_space and 14275 process_stratum_target::thread_address_space and 14276 linux_nat_target::thread_address_space, which essentially just return 14277 the inferior's address space. And thread_address_space is only used in 14278 the current get_thread_arch_regcache, which gets removed. So, I think 14279 that the thread_address_space target method can be removed, and we can 14280 assume that it's fine to use the inferior's address space everywhere. 14281 Callers of regcache::aspace are updated to get the address space from 14282 the relevant inferior, either using some context they already know 14283 about, or in last resort using the current global context. 14284 14285 So, to summarize: 14286 14287 - remove everything in regcache related to address spaces 14288 - in particular, remove get_thread_arch_regcache, and rename 14289 get_thread_arch_aspace_regcache to get_thread_arch_regcache 14290 - remove target_ops::thread_address_space, and 14291 target_thread_address_space 14292 - adjust all users of regcache::aspace to get the address space another 14293 way 14294 14295 Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7 14296 142972023-11-17 Tom Tromey <tom@tromey.com> 14298 14299 Remove extraneous blocks from dwarf2/read.c:new_symbol 14300 dwarf2/read.c:new_symbol has some extra braces in a couple of 'case's. 14301 These read weirdly to me, and since they aren't necessary, this patch 14302 removes the braces and reindents the bodies. Tested by rebuilding. 14303 143042023-11-17 Joseph Myers <joseph@codesourcery.com> 14305 14306 Fix read_ranges for 32-bit long 14307 bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which 14308 doesn't work correctly when long is 32-bit and bfd_vma is 64-bit 14309 (observed as "nm -l" being very slow for mingw64 host; probably causes 14310 issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64). 14311 Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere. 14312 143132023-11-17 Tom Tromey <tromey@adacore.com> 14314 14315 Ignore static members in NoOpStructPrinter 14316 Hannes' patch to show local variables in the TUI pointed out that 14317 NoOpStructPrinter should ignore static members. This patch implements 14318 this. 14319 143202023-11-17 Tom Tromey <tromey@adacore.com> 14321 14322 Implement the notStopped DAP response 14323 DAP specifies that a request can fail with the "notStopped" message if 14324 the inferior is running but the request requires that it first be 14325 stopped. 14326 14327 This patch implements this for gdb. Most requests are assumed to 14328 require a stopped inferior, and the exceptions are noted by a new 14329 'request' parameter. 14330 14331 You may notice that the implementation is a bit racy. I think this is 14332 inherent -- unless the client waits for a stop event before sending a 14333 request, the request may be processed at any time relative to a stop. 14334 14335 https://sourceware.org/bugzilla/show_bug.cgi?id=31037 14336 14337 Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com> 14338 143392023-11-17 Tom Tromey <tromey@adacore.com> 14340 14341 Remove ExecutionInvoker 14342 ExecutionInvoker is no longer really needed, due to the previous DAP 14343 refactoring. This patch removes it in favor of an ordinary function. 14344 One spot (the 'continue' request) could still have used it, but is 14345 more succinctly expressed as a lambda. 14346 14347 Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com> 14348 143492023-11-17 Tom Tromey <tromey@adacore.com> 14350 14351 Automatically run (most) DAP requests in gdb thread 14352 Nearly every DAP request implementation forwards its work to the gdb 14353 thread, using send_gdb_with_response. This patch refactors the 14354 'request' decorator to make this automatic, and to provide some 14355 parameters so that the unusual requests can express their needs as 14356 well. 14357 14358 In a few spots this simplifies the code by removing an unnecessary 14359 helper function. This could be done in more places as well if we 14360 wanted. 14361 14362 The main motivation for this patch is that I thought it would be 14363 helpful for cancellation. I am still working on that, but meanwhile 14364 the parameterization of 'request' makes it easy to handle the 14365 'notStopped' response as well. 14366 14367 Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com> 14368 143692023-11-17 YunQiang Su <yunqiang.su@cipunited.com> 14370 14371 Gold/MIPS: Add targ_extra_size=64 for mips32 triples 14372 143732023-11-17 Tom Tromey <tromey@adacore.com> 14374 14375 Handle StackFrameFormat in DAP 14376 DAP specifies a StackFrameFormat object that can be used to change how 14377 the "name" part of a stack frame is constructed. While this output 14378 can already be done in a nicer way (and also letting the client choose 14379 the formatting), nevertheless it is in the spec, so I figured I'd 14380 implement it. 14381 14382 While implementing this, I discovered that the current code does not 14383 correctly preserve frame IDs across requests. I rewrote frame 14384 iteration to preserve this, and it turned out to be simpler to combine 14385 these patches. 14386 14387 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475 14388 143892023-11-17 Pedro Alves <pedro@palves.net> 14390 14391 Fix AMD_DBGAPI_SCOPED_DEBUG_START_END wrong setting 14392 The AMD_DBGAPI_SCOPED_DEBUG_START_END macro in gdb/amd-dbgapi-target.c 14393 is incorrectly controlled by "set debug infrun", while it should be 14394 controlled by "set debug amd-dbgapi" instead. This commit fixes it. 14395 14396 Change-Id: I8ec2b1a4b9980c2d565a8aafd060ed070eeb3b29 14397 143982023-11-17 Jan Beulich <jbeulich@suse.com> 14399 14400 x86: improve a few diagnostics 14401 PR gas/31043 14402 "unsupported instruction ..." can mean about anything, and can also be 14403 mistaken to mean something that isn't meant. Replace most of its uses by 14404 more specific diagnostics, 14405 14406 While there also take the opportunity and purge the no longer used 14407 invalid_register_operand enumerator. 14408 144092023-11-17 Jan Beulich <jbeulich@suse.com> 14410 14411 x86: don't allow pseudo-prefixes to be overridden by legacy suffixes 14412 Deprecated functionality would better not win over its modern 14413 counterparts. 14414 14415 x86: CPU-qualify {disp16} / {disp32} 14416 {disp16} is invalid to use in 64-bit mode, while {disp32} is invalid to 14417 use on pre-386 CPUs. The latter, also affecting other (real) prefixes, 14418 further requires that like for insns we fully check the CPU flags; till 14419 now only Cpu64/CpuNo64 were taken into consideration. 14420 14421 x86: use IS_ELF 14422 ... instead of (inefficiently) open-coding it. 14423 144242023-11-17 Jan Beulich <jbeulich@suse.com> 14425 14426 x86: conditionally hide object-format-specific functions 14427 ELF-only functions don't need to be built when dealing with a non-ELF 14428 target. md_section_align() also doesn't need to be a function when 14429 dealing with non-AOUT targets. Similarly tc_fix_adjustable() can be a 14430 simple macro when building non-ELF targets. 14431 14432 Furthermore x86_elf_abi is already used in ELF-only code sections, with 14433 one exception. By adjusting that, the otherwise bogusly named variable 14434 can also be confined to just ELF builds. 14435 144362023-11-17 Jan Beulich <jbeulich@suse.com> 14437 14438 x86: fold conditionals in check_long_reg() 14439 Simplify the code follow ing what check_{,q}word_reg() already do. This 14440 the also eliminates a stale comment talking about a warning when an 14441 error is raised. While there, correct a similarly stale comment in 14442 check_qword_reg() while there. 14443 144442023-11-17 Jan Beulich <jbeulich@suse.com> 14445 14446 x86-64: extend expected-size check in check_qword_reg() 14447 Due to a missing check "crc32q %al, %rax" was wrongly translated to the 14448 encoding of "crc32q %rax, %rax", rather than being rejected as invalid. 14449 (The mnemonic suffix describes the source operand, not the destination 14450 one.) 14451 14452 Note that check_{word,long}_reg() do not (currently) appear to require 14453 similar amending, as there are no insn templates permitting an L or W 14454 suffix and having an operand which allows for Reg8 and Reg64, but 14455 neither Reg16 nor Reg32. 14456 144572023-11-17 mengqinggang <mengqinggang@loongson.cn> 14458 14459 LoongArch: Add more relaxation testcases 14460 1. .so relaxation testcase 14461 2. ld --no-relax testcase 14462 3. segment alignment testcase 14463 14464 LoongArch: Modify link_info.relax_pass from 3 to 2 14465 The first pass handles R_LARCH_RELAX relocations, the second pass 14466 handles R_LARCH_ALIGN relocations. 14467 14468 LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition 14469 Previously the condition prevented shared objects from being relaxed. 14470 To remove the limitation, we need to update program header size and 14471 .eh_frame_hdr size before relaxation. 14472 14473 LoongArch: Multiple relax_trip in one relax_pass 14474 If deleting instructions in one relax_trip, set again to true to start the 14475 next relax_trip. 14476 14477 LoongArch: Directly delete relaxed instuctions in first relaxation pass 14478 Directly delete relaxed instuctions in first relaxation pass, not use 14479 R_LARCH_DELETE relocation. If not, the PC-relative offset may increase. 14480 14481 LoongArch: Fix ld --no-relax bug 14482 When calling ld with --no-relax, pcalau12i + ld.d still can be relaxed. 14483 This patch fix this bug and pcalau12i + ld.d can be relaxed with --relax. 14484 144852023-11-17 Simon Marchi <simon.marchi@efficios.com> 14486 14487 gdb: remove two uses of obstack 14488 Remove uses of obstack in the code generating the libraries XML for 14489 Windows and AIX. Use std::string instead. I'm not able to test this 14490 change, unfortunately. 14491 14492 Change-Id: I28480913337e3fe8d6c31e551626931e6b1367ef 14493 Approved-By: Tom Tromey <tom@tromey.com> 14494 144952023-11-17 GDB Administrator <gdbadmin@sourceware.org> 14496 14497 Automatic date update in version.in 14498 144992023-11-16 Tom Tromey <tom@tromey.com> 14500 14501 Fix small bug in compile.exp 14502 compile.exp generally does not work for me on Fedora 38. However, I 14503 sent a GCC patch to fix the plugin crash. With that patch, I get this 14504 error from one test in compile.exp: 14505 14506 gdb command line:1:22: warning: initialization of 'int (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types] 14507 14508 This patch adds a cast to compile.exp. This makes the test pass. 14509 14510 Reviewed-by: Keith Seitz <keiths@redhat.com> 14511 145122023-11-16 Andrew Burgess <aburgess@redhat.com> 14513 14514 gdb/python: remove use of str.isascii() 14515 This commit: 14516 14517 commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 14518 Date: Sun Oct 15 22:48:42 2023 +0100 14519 14520 gdb: implement missing debug handler hook for Python 14521 14522 introduced a use of str.isascii(), which was only added in Python 3.7. 14523 14524 This commit switches to use curses.ascii.isascii(), as this was 14525 available in 3.6. 14526 14527 The same is true for str.isalnum(), which is replaced with 14528 curses.ascii.isalnum(). 14529 14530 There should be no user visible changes after this commit. 14531 145322023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 14533 14534 aarch64: Add support for VMSA feature enhancements. 14535 This patch adds the permission model enhancement and memory 14536 attribute index enhancement features and their corresponding 14537 system registers in AArch64 assembler. 14538 Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE) 14539 Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE) 14540 Memory Attribute Index Enhancement (FEAT_AIE) 14541 Extension to Translation Control Registers (FEAT_TCR2) 14542 14543 These features are available by default from Armv9.4-A architecture. 14544 145452023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 14546 14547 aarch64: Add new AT system instructions. 14548 This patch adds 3 new AT system instructions through FEAT_ATS1A 14549 feature, which are available by default from Armv9.4-A architecture. 14550 145512023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 14552 14553 aarch64: Add support to new features in RAS extension. 14554 This patch also adds support for: 14555 1. FEAT_RASv2 feature and "ERXGSR_EL1" system register. 14556 RASv2 feature is enabled by passing +rasv2 to -march 14557 (eg: -march=armv8-a+rasv2). 14558 14559 2. FEAT_SCTLR2 and following system registers. 14560 SCTLR2_EL1, SCTLR2_EL12, SCTLR2_EL2 and SCTLR2_EL3. 14561 14562 3. FEAT_FGT2 and following system registers. 14563 HDFGRTR2_EL2, HDFGWTR2_EL2, HFGRTR2_EL2, HFGWTR2_EL2 14564 14565 4. FEAT_PFAR and following system registers. 14566 PFAR_EL1, PFAR_EL2 and PFAR_EL12. 14567 14568 FEAT_RASv2, FEAT_SCTLR2, FEAT_FGT2 and FEAT_PFAR features are by default 14569 enabled from Armv9.4-A architecture. 14570 14571 This patch also adds support for two read only system registers 14572 id_aa64mmfr3_el1 and id_aa64mmfr4_el1, which are available from 14573 Armv8-A Architecture. 14574 145752023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 14576 14577 aarch64: Add features to the Statistical Profiling Extension. 14578 This patch adds features to the Statistical Profiling Extension, 14579 identified as FEAT_SPEv1p4, FEAT_SPE_FDS, and FEAT_SPE_CRR, which 14580 are enabled by default from Armv9.4-A. 14581 14582 Also adds support for system register "pmsdsfr_el1". 14583 145842023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 14585 14586 aarch64: Add SLC target for PRFM instruction. 14587 This patch adds support for FEAT_PRFMSLC feature which enables 14588 SLC target for PRFM instructions. 14589 145902023-11-16 Andrew Burgess <aburgess@redhat.com> 14591 14592 gdb/NEWS: merge two 'New commands' sections 14593 Spotted that we'd gained two 'New commands' sections in our 'Changes 14594 since GDB 14' NEWS file block. I've merged them together. 14595 14596 Also, one of these two sections was actually called 'New Commands', 14597 however, all the other places in the NEWS file use 'New commands', so 14598 I've changed to use that. 14599 146002023-11-16 Vladislav Khmelevsky <och95@yandex.ru> 14601 14602 Fix emit-relocs for aarch64 gold 14603 Fix relocation offsets values for the relaxed input sections the same 14604 way it was fixed for the sections in PR21430. 14605 146062023-11-16 Ying Huang <ying.huang@oss.cipunited.com> 14607 14608 sim: mips: Change E_MIPS_* to EF_MIPS_* 14609 According to we have changed all E_MIPS_* to EF_MIPS_* in binutils 14610 and glibc, we also need to change it here to keep same style. 14611 We can refer to this commit record: 14612 https://sourceware.org/pipermail/binutils/2023-October/129904.html 14613 14614 Approved-By: Pedro Alves <pedro@palves.net> 14615 146162023-11-16 Ying Huang <ying.huang@oss.cipunited.com> 14617 14618 gdb: mips: Change E_MIPS_* to EF_MIPS_* 14619 According to we have changed all E_MIPS_* to EF_MIPS_* in binutils 14620 and glibc, we also need to change it here to keep same style. 14621 We can refer to this commit record: 14622 https://sourceware.org/pipermail/binutils/2023-October/129904.html 14623 14624 Approved-By: Pedro Alves <pedro@palves.net> 14625 146262023-11-16 GDB Administrator <gdbadmin@sourceware.org> 14627 14628 Automatic date update in version.in 14629 146302023-11-15 Pedro Alves <pedro@palves.net> 14631 14632 Fix gdb.threads/threads-after-exec.exp race 14633 Simon noticed that gdb.threads/threads-after-exec.exp was racy. You 14634 can consistenly reproduce it (at git hash 14635 319b460545dc79280e2904dcc280057cf71fb753), with: 14636 14637 $ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp" 14638 14639 gdb.log shows: 14640 14641 (...) 14642 Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290 14643 in _start () from /lib64/ld-linux-x86-64.so.2 14644 (gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec 14645 info threads 14646 Id Target Id Frame 14647 * 3 process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2 14648 (gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads 14649 (...) 14650 maint info linux-lwps 14651 LWP Ptid Thread ID 14652 1443269.1443269.0 1.3 14653 (gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps 14654 14655 The FAILs happen because the .exp file expects that after the exec, 14656 the only thread has GDB thread number 1, but it has instead 3. 14657 14658 This is yet another case of zombie leader detection making things a 14659 bit fuzzy. 14660 14661 In the passing case, we have: 14662 14663 continue 14664 Continuing. 14665 [New Thread 0x7ffff7bff640 (LWP 603183)] 14666 [Thread 0x7ffff7bff640 (LWP 603183) exited] 14667 process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec 14668 14669 While in the failing case, we have (note remarks on the rhs): 14670 14671 continue 14672 Continuing. 14673 [New Thread 0x7ffff7bff640 (LWP 600205)] 14674 [Thread 0x7ffff7f95740 (LWP 600202) exited] <<< gdb deletes leader thread, thread 1. 14675 [New LWP 600202] <<< gdb adds it back -- this is now thread 3. 14676 [Thread 0x7ffff7bff640 (LWP 600205) exited] 14677 process 600202 is executing new program: .../threads-after-exec/threads-after-exec 14678 14679 The testcase only has two threads, yet GDB presented the exec for 14680 thread 3. This is GDB deleting the leader (the backend detected it 14681 was zombie, due to the exec), and then adding the leader back when it 14682 saw the exec event. 14683 14684 I've recorded some thoughts about this in PR gdb/31069. 14685 14686 For now, this commit just makes the testcase cope with the non-one 14687 thread number, as the number is not important for what this test is 14688 exercising. 14689 14690 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069 14691 Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae 14692 146932023-11-15 Tom Tromey <tromey@adacore.com> 14694 14695 Check gdb_python_module in gdbpy_handle_missing_debuginfo 14696 If you run gdb in the build tree without --data-directory, on a 14697 program that does not have debug info, it will crash, because 14698 gdbpy_handle_missing_debuginfo unconditionally uses gdb_python_module. 14699 14700 Other code in gdb using gdb_python_module checks it first and it 14701 seemes harmless to do the same thing here. (gdb_python_initialized 14702 does not cover this case so that python can be partially initialized 14703 and still somewhat work.) 14704 147052023-11-15 Tom Tromey <tromey@adacore.com> 14706 14707 Minor cleanups in ada-nested.exp 14708 This changes ada-nested.exp to fix a test name (the test expects three 14709 variables but is named "two"), and to iterate over all the variables 14710 that are found. It also adds a workaround to a problem Tom de Vries 14711 found with an older version of GNAT -- it emits a duplicate "x". 14712 147132023-11-15 Sam James <sam@gentoo.org> 14714 14715 Finalized intl-update patches (trois) 14716 Doing this on behalf of Arsen as obvious. Hopefully the last fixup. 14717 14718 * gdb: Regenerate. 14719 * gnulib: Regenerate. 14720 147212023-11-15 Sam James <sam@gentoo.org> 14722 14723 Finalized intl-update patches (deux) 14724 Doing this on behalf of Arsen as obvious. 14725 14726 * gdb: Regenerate. 14727 * gdbserver: Regenerate. 14728 * gprofng: Regenerate. 14729 147302023-11-15 YunQiang Su <yunqiang.su@cipunited.com> 14731 14732 GAS/MIPS: add "--defsym r6=" for default when it's r6 14733 * testsuite/gas/mips/mips.exp (mips_arch_create): Add "--defsym r6=" to as_flags for r6 targets. 14734 147352023-11-15 Arsen Arsenovi? <arsen@aarsen.me> 14736 14737 Finalized intl-update patches 14738 * intl: Remove directory. Replaced with out-of-tree GNU gettext. 14739 * .gitignore: Add '/gettext*'. 14740 * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. 14741 * configure: Regenerate. 14742 * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. 14743 * Makefile.in: Regenerate. 14744 * src-release.sh: Remove references to the intl/ directory. 14745 147462023-11-15 YunQiang Su <yunqiang.su@cipunited.com> 14747 14748 MIPS: Fix Irix gas testcases about pdr section 14749 * testsuite/gas/elf/elf.exp (section2): Add -mpdr option to assembler command line for mips-irix targets. 14750 * testsuite/gas/mips/elf-rel26.d: Add -mpdr command line option. 14751 * testsuite/gas/mips/mips16-e.d: Likewise. 14752 * testsuite/gas/mips/mips16-f.d: Likewise. 14753 * testsuite/gas/mips/mips16-hilo-match.d: Likewise. 14754 * testsuite/gas/mips/mips16-e-irix.d: Likewise. 14755 * testsuite/gas/mips/call-nonpic-1.d: Adjust regexp to allow for mips-irix targets. 14756 * testsuite/gas/mips/irix-no-pdr.d: New test file. 14757 * testsuite/gas/mips/mips.exp: Run new test for mips-irix targets. 14758 147592023-11-15 GDB Administrator <gdbadmin@sourceware.org> 14760 14761 Automatic date update in version.in 14762 147632023-11-14 Tom Tromey <tromey@adacore.com> 14764 14765 Remove path name from test case 14766 'runtest' complains about a path in a test name, from the new test 14767 case py-missing-debug.exp. 14768 14769 This patch fixes the problem by providing an explicit test name to 14770 gdb_test. I chose something very basic because the block in question 14771 is already wrapped in with_test_prefix. 14772 147732023-11-14 Tom Tromey <tromey@adacore.com> 14774 14775 Remove some redundant "break"s 14776 I found some "break" statements that follow "return" or a call to a 14777 noreturn function. These aren't needed, and the compiler would warn 14778 if they were. So, this patch removes them. 14779 14780 Tested by rebuilding. 14781 147822023-11-14 Tom Tromey <tom@tromey.com> 14783 14784 Filter invalid encodings from Linux thread names 14785 On Linux, a thread can only be 16 bytes (including the trailing \0). 14786 A user sent in a test case where this causes a truncated UTF-8 14787 sequence, causing gdbserver to create invalid XML. 14788 14789 I went back and forth about different ways to solve this, and in the 14790 end decided to fix it in gdbserver, with the reason being that it 14791 seems important to generate correct XML for the <thread> response. 14792 14793 I am not totally sure whether the call to setlocale could have 14794 unplanned consequences. This is needed, though, for nl_langinfo to 14795 return the correct result. 14796 14797 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618 14798 147992023-11-14 Tom Tromey <tromey@adacore.com> 14800 14801 Update gdb.Symbol.is_variable documentation 14802 Kévin found a bug in an earlier version of this series that was based 14803 on a misconception I had about Symbol.is_variable. This patch fixes 14804 the documentation to explain the method a bit better. 14805 14806 Approved-By: Eli Zaretskii <eliz@gnu.org> 14807 148082023-11-14 Tom Tromey <tromey@adacore.com> 14809 14810 Handle the static link in FrameDecorator 14811 A co-worker requested that the DAP scope for a nested function's frame 14812 also show the variables from outer frames. DAP doesn't directly 14813 support this notion, so this patch arranges to put these variables 14814 into the inner frames "Locals" scope. 14815 14816 I chose to do this only for DAP. For CLI and MI, gdb currently does 14817 not do this, so this preserves the behavior. 14818 14819 Note that an earlier patch (see commit 4a1311ba) removed some code 14820 that seemed to do something similar. However, that code did not 14821 actually work. 14822 148232023-11-14 Tom Tromey <tromey@adacore.com> 14824 14825 Fix a bug in DAP scopes code 14826 While working on static links, I noticed that the DAP scopes code does 14827 not handle the scenario where a frame decorator returns None. This 14828 situation should be handled identically to a frame decorator returning 14829 an empty iterator. 14830 148312023-11-14 Tom Tromey <tromey@adacore.com> 14832 14833 Add gdb.Frame.static_link method 14834 This adds a new gdb.Frame.static_link method to the gdb Python layer. 14835 This can be used to find the static link frame for a given frame. 14836 14837 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 14838 148392023-11-14 Tom Tromey <tromey@adacore.com> 14840 14841 Move follow_static_link to frame.c 14842 This moves the follow_static_link function to frame.c and exports it 14843 for use elsewhere. The API is changed slightly to make it more 14844 generically useful. 14845 14846 Add block::function_block 14847 This adds the method block::function_block, to easily access a block's 14848 enclosing function block. 14849 14850 Add two convenience methods to block 14851 This adds a couple of convenience methods, block::is_static_block and 14852 block::is_global_block. 14853 148542023-11-14 Simon Marchi <simon.marchi@efficios.com> 14855 14856 gdb/MAINTAINERS: add Guinevere Larsen as record-full maintainer 14857 Change-Id: I67d8361560ce0fa553b2983184c9d18df8dbeb4a 14858 14859 gdb/MAINTAINERS: add Luis Machado as global maintainer 14860 Change-Id: I211d64393f5c0da3c9ce1fcf5486504d34ed38f4 14861 14862 gdb/MAINTAINERS: add John Baldwin as global maintainer 14863 Change-Id: Ic9164fd19c3da1381302a17176e8f0f814e9ac6c 14864 148652023-11-14 Simon Marchi <simon.marchi@efficios.com> 14866 14867 gdb: normalize whitespaces in MAINTAINERS 14868 Replace some spaces with tabs. 14869 14870 Change-Id: I89bbabd6610219649e7e99cd0dd7b0ed66d69b09 14871 148722023-11-14 Tom de Vries <tdevries@suse.de> 14873 14874 [gdb/tui] Factor out tui_noscroll_window et al 14875 I noticed that tui_locator_window has an empty do_scroll_vertical and 14876 do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't 14877 have: 14878 ... 14879 bool can_scroll () const override 14880 { 14881 return false; 14882 } 14883 ... 14884 14885 I suspect that it probably doesn't matter, but regardless it's good to have 14886 the same implementations of basic properties in all windows. 14887 14888 Ensure this by adding a class tui_noscroll_window, that has: 14889 - an empty do_scroll_vertical and do_scroll_horizontal, and 14890 - a can_scroll returning false 14891 which both tui_locator_window and tui_cmd_window inherit. 14892 14893 Make all methods final to ensure no accidental overrides are left in the 14894 inheriting classes. 14895 14896 Likewise add new classes representing basic window properties: 14897 - tui_nofocus_window, 14898 - tui_oneline_window, 14899 - tui_nobox_window, 14900 - tui_norefresh_window, and 14901 - tui_always_visible_window. 14902 14903 The changes are only a refactoring, apart from adding the "final", which does 14904 limit the range of behaviours for subclasses. 14905 14906 Tested on x86_64-linux. 14907 14908 Approved-By: Tom Tromey <tom@tromey.com> 14909 149102023-11-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 14911 14912 gdb: refactor make-target-delegates.py's ARGTYPES 14913 Refactor the ARGTYPES regular expression in make-target-delegates.py 14914 to eliminate '.*' for better control on what is matched. Also, 14915 simplify the "E" match group, for which the optional SYMBOL becomes 14916 redundant because that case can be matched by the "T" group. 14917 14918 After applying this patch, running './make-target-delegates.py' does not 14919 change anything in 'target-delegates.c'. 14920 14921 Approved-By: Pedro Alves <pedro@palves.net> 14922 149232023-11-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 14924 14925 gdb: regenerate target-delegates.c 14926 I ran './make-target-delegates.py' and there is one minor difference, 14927 where an older style declaration is converted to a newer 14928 initialization style. Add this change. 14929 14930 Approved-By: Pedro Alves <pedro@palves.net> 14931 149322023-11-14 Tom de Vries <tdevries@suse.de> 14933 14934 [gdb/testsuite] Fix gdb.threads/stepi-over-clone.exp regexp 14935 I ran into the following FAIL: 14936 ... 14937 (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls 14938 continue^M 14939 Continuing.^M 14940 ^M 14941 Catchpoint 2 (call to syscall clone), clone () at \ 14942 ../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M 14943 warning: 78 ../sysdeps/unix/sysv/linux/x86_64/clone.S: \ 14944 No such file or directory^M 14945 (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue 14946 ... 14947 14948 All but one regexps in the .exp file use "clone\[23\]?" with "?" to 14949 also accept "clone", except the failing case. This commit fixes that 14950 case to also use "?". 14951 14952 Furthermore, there are FAILs like this: 14953 ... 14954 (gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \ 14955 non-stop=on: displaced=off: i=0: continue 14956 stepi^M 14957 [New Thread 0x7ffff7ff8700 (LWP 15301)]^M 14958 Hello from the first thread.^M 14959 78 in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M 14960 (gdb) XXX: Consume the initial command 14961 XXX: Consume new thread line 14962 XXX: Consume first worker thread message 14963 FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \ 14964 displaced=off: i=0: stepi 14965 ... 14966 because this output is expected instead: 14967 ... 14968 Hello from the first thread.^M 14969 0x00000000004212cd in clone3 ()^M 14970 ... 14971 14972 The root cause for the difference is the presence of .debug_line info for 14973 clone. 14974 14975 Fix this by updating the relevant regexps. 14976 14977 Tested on x86_64-linux, specifically: 14978 - openSUSE Leap 15.4 (where the FAILs where observed), and 14979 - openSUSE Tumbleweed (where the FAILs where not observed). 14980 14981 Co-Authored-By: Pedro Alves <pedro@palves.net> 14982 Approved-By: Pedro Alves <pedro@palves.net> 14983 14984 Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c 14985 149862023-11-14 Andrew Burgess <aburgess@redhat.com> 14987 14988 gdb: implement missing debug handler hook for Python 14989 This commit builds on the previous commit, and implements the 14990 extension_language_ops::handle_missing_debuginfo function for Python. 14991 This hook will give user supplied Python code a chance to help find 14992 missing debug information. 14993 14994 The implementation of the new hook is pretty minimal within GDB's C++ 14995 code; most of the work is out-sourced to a Python implementation which 14996 is modelled heavily on how GDB's Python frame unwinders are 14997 implemented. 14998 14999 The following new commands are added as commands implemented in 15000 Python, this is similar to how the Python unwinder commands are 15001 implemented: 15002 15003 info missing-debug-handlers 15004 enable missing-debug-handler LOCUS HANDLER 15005 disable missing-debug-handler LOCUS HANDLER 15006 15007 To make use of this extension hook a user will create missing debug 15008 information handler objects, and registers these handlers with GDB. 15009 When GDB encounters an objfile that is missing debug information, each 15010 handler is called in turn until one is able to help. Here is a 15011 minimal handler that does nothing useful: 15012 15013 import gdb 15014 import gdb.missing_debug 15015 15016 class MyFirstHandler(gdb.missing_debug.MissingDebugHandler): 15017 def __init__(self): 15018 super().__init__("my_first_handler") 15019 15020 def __call__(self, objfile): 15021 # This handler does nothing useful. 15022 return None 15023 15024 gdb.missing_debug.register_handler(None, MyFirstHandler()) 15025 15026 Returning None from the __call__ method tells GDB that this handler 15027 was unable to find the missing debug information, and GDB should ask 15028 any other registered handlers. 15029 15030 By extending the __call__ method it is possible for the Python 15031 extension to locate the debug information for objfile and return a 15032 value that tells GDB how to use the information that has been located. 15033 15034 Possible return values from a handler: 15035 15036 - None: This means the handler couldn't help. GDB will call other 15037 registered handlers to see if they can help instead. 15038 15039 - False: The handler has done all it can, but the debug information 15040 for the objfile still couldn't be found. GDB will not call 15041 any other handlers, and will continue without the debug 15042 information for objfile. 15043 15044 - True: The handler has installed the debug information into a 15045 location where GDB would normally expect to find it. GDB 15046 should look again for the debug information. 15047 15048 - A string: The handler can return a filename, which is the file 15049 containing the missing debug information. GDB will load 15050 this file. 15051 15052 When a handler returns True, GDB will look again for the debug 15053 information, but only using the standard built-in build-id and 15054 .gnu_debuglink based lookup strategies. It is not possible for an 15055 extension to trigger another debuginfod lookup; the assumption is that 15056 the debuginfod server is remote, and out of the control of extensions 15057 running within GDB. 15058 15059 Handlers can be registered globally, or per program space. GDB checks 15060 the handlers for the current program space first, and then all of the 15061 global handles. The first handler that returns a value that is not 15062 None, has "handled" the objfile, at which point GDB continues. 15063 15064 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 15065 Approved-By: Tom Tromey <tom@tromey.com> 15066 150672023-11-14 Andrew Burgess <aburgess@redhat.com> 15068 15069 gdb: add an extension language hook for missing debug info 15070 This commit adds a new extension_language_ops hook which allows an 15071 extension to handle the case where GDB can't find a separate debug 15072 information file for a particular objfile. 15073 15074 This commit doesn't actually implement the hook for any of GDB's 15075 extension languages, the next commit will do that. This commit just 15076 adds support for the hook to extension-priv.h and extension.[ch], and 15077 then reworks symfile-debug.c to call the hook. 15078 15079 Right now the hook will always return its default value, which means 15080 GDB should do nothing different. As such, there should be no user 15081 visible changes after this commit. 15082 15083 I'll give a brief description of what the hook does here so that we 15084 can understand the changes in symfile-debug.c. The next commit adds a 15085 Python implementation for this new hook, and gives a fuller 15086 description of the new functionality. 15087 15088 Currently, when looking for separate debug information GDB tries three 15089 things, in this order: 15090 15091 1. Use the build-id to find the required debug information, 15092 15093 2. Check for .gnu_debuglink section and use that to look up the 15094 required debug information, 15095 15096 3. Check with debuginfod to see if it can supply the required 15097 information. 15098 15099 The new extension_language_ops::handle_missing_debuginfo hook is 15100 called if all three steps fail to find any debug information. The 15101 hook has three possible return values: 15102 15103 a. Nothing, no debug information is found, GDB continues without the 15104 debug information for this objfile. This matches the current 15105 behaviour of GDB, and is the default if nothing is implementing this 15106 new hook, 15107 15108 b. Install debug information into a location that step #1 or #2 15109 above would normally check, and then request that GDB repeats steps 15110 #1 and #2 in the hope that GDB will now find the debug information. 15111 If the debug information is still not found then GDB carries on 15112 without the debug information. If the debug information is found 15113 the GDB loads it and carries on, 15114 15115 c. Return a filename for a file containing the required debug 15116 information. GDB loads the contents of this file and carries on. 15117 15118 The changes in this commit mostly involve placing the core of 15119 objfile::find_and_add_separate_symbol_file into a loop which allows 15120 for steps #1 and #2 to be repeated. 15121 15122 We take care to ensure that debuginfod is only queried once, the first 15123 time through. The assumption is that no extension is going to be able 15124 to control the replies from debuginfod, so there's no point making a 15125 second request -- and as these requests go over the network, they 15126 could potentially be slow. 15127 15128 The warnings that find_and_add_separate_symbol_file collects are 15129 displayed only once assuming that no debug information is found. If 15130 debug information is found, even after the extension has operated, 15131 then the warnings are not shown; remember, these are warnings from GDB 15132 about failure to find any suitable debug information, so it makes 15133 sense to hide these if debug information is found. 15134 15135 Approved-By: Tom Tromey <tom@tromey.com> 15136 151372023-11-14 Andrew Burgess <aburgess@redhat.com> 15138 15139 gdb: refactor objfile::find_and_add_separate_symbol_file 15140 This is purely a refactoring commit. 15141 15142 This commit splits objfile::find_and_add_separate_symbol_file into 15143 some separate helper functions. My hope is that the steps for looking 15144 up separate debug information are now clearer. 15145 15146 In a later commit I'm going to extend 15147 objfile::find_and_add_separate_symbol_file, with some additional 15148 logic, so starting with a simpler function will make the following 15149 changes easier. 15150 15151 When reading objfile::find_and_add_separate_symbol_file after this 15152 commit, you might be tempted to think that removing the `has_dwarf` 15153 local variable would be a good additional cleanup. After the next 15154 commit though it makes more sense to retain this local, so I've left 15155 this in place for now. 15156 15157 There should be no user visible changes after this commit. 15158 15159 Approved-By: Tom Tromey <tom@tromey.com> 15160 151612023-11-14 Andrew Burgess <aburgess@redhat.com> 15162 15163 gdb: merge debug symbol file lookup code from coffread & elfread paths 15164 This commit merges the code that looks for and loads the separate 15165 debug symbol files from coffread.c and elfread.c. The factored out 15166 code is moved into a new objfile::find_and_add_separate_symbol_file() 15167 method. 15168 15169 For the elfread.c path there should be no user visible changes after 15170 this commit. 15171 15172 For the coffread.c path GDB will now attempt to perform a debuginfod 15173 lookup for the missing debug information, assuming that GDB can find a 15174 build-id in the COFF file. 15175 15176 I don't know if COFF files can include a build-id, but I the existing 15177 coffread.c code already includes a call to 15178 find_separate_debug_file_by_build-id, so I know that it is at least OK 15179 for GDB to ask a COFF file for a build-id. If the COFF file doesn't 15180 include a build-id then the debuginfod lookup code will not trigger 15181 and the new code is harmless. 15182 15183 If the COFF file does include a build-id, then we're going to end up 15184 asking debuginfod for the debug file. As build-ids should be unique, 15185 this should be harmless, even if debuginfod doesn't contain any 15186 suitable debug data, it just costs us one debuginfod lookup, so I'm 15187 not too worried about this for now. 15188 15189 As with the previous commit, I've done some minimal testing using the 15190 mingw toolchain on a Linux machine, GDB seems to still access the 15191 split debug information just fine. 15192 15193 Approved-By: Tom Tromey <tom@tromey.com> 15194 151952023-11-14 Andrew Burgess <aburgess@redhat.com> 15196 15197 gdb/coffread: bring separate debug file logic into line with elfread.c 15198 In this commit: 15199 15200 commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07 15201 Date: Fri Feb 1 19:39:04 2013 +0000 15202 15203 the logic for when we try to load a separate debug file in elfread.c 15204 was extended. The new code checks that the objfile doesn't already 15205 have a separate debug objfile linked to it, and that the objfile isn't 15206 itself a separate debug objfile for some other objfile. 15207 15208 The coffread code wasn't extended at the same time. 15209 15210 I don't know if it's possible for the coffread code to get into the 15211 same state where these checks are needed, but I don't see why having 15212 these checks would be a problem. In a later commit I plan to merge 15213 this part of the elfread and coffread code, so bringing these two 15214 pieces of code into line first makes that job easier. 15215 15216 I've tested this with a simple test binary compiled with the mingw 15217 toolchain on a Linux host. After compiling the binary and splitting 15218 out the debug info GDB still finds and loads the separate debug info. 15219 15220 Approved-By: Tom Tromey <tom@tromey.com> 15221 152222023-11-14 Nick Clifton <nickc@redhat.com> 15223 15224 Fix another linker command line option that was not being recognised in its long form. 15225 PR 28910 15226 * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised. 15227 15228 Improve objdump's handling of compressed sections. 15229 PR 31062 15230 * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option. 15231 * NEWS: Mention the new feature. 15232 * doc/binutils.texi: Document the new feature. 15233 * testsuite/binutils-all/objdump.s: Update expected output. 15234 * testsuite/binutils-all/objdump.exp: Add test of -Z -s. 15235 * testsuite/binutils-all/objdump.Zs: New file. 15236 * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions. Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise. 15237 152382023-11-14 GDB Administrator <gdbadmin@sourceware.org> 15239 15240 Automatic date update in version.in 15241 152422023-11-13 Tom de Vries <tdevries@suse.de> 15243 15244 [gdb/tui] Don't include border_width in left_margin 15245 Currently left_margin does not match its documentation: 15246 ... 15247 /* Return the size of the left margin space, this is the space used to 15248 display things like breakpoint markers. */ 15249 int left_margin () const 15250 { return box_width () + TUI_EXECINFO_SIZE + extra_margin (); } 15251 ... 15252 15253 It is stated that the left margin is reserved to display things, but 15254 the box_width is not used for that. 15255 15256 Fix this by dropping box_width () from the left_margin calculation. 15257 15258 Tested on x86_64-linux. 15259 15260 Approved-By: Tom Tromey <tom@tromey.com> 15261 152622023-11-13 Tom de Vries <tdevries@suse.de> 15263 15264 [gdb/tui] Add tui_win_info::{box_width,box_size} 15265 In tui_source_window::set_contents we have: 15266 ... 15267 /* Take hilite (window border) into account, when 15268 calculating the number of lines. */ 15269 int nlines = height - 2; 15270 ... 15271 15272 The '2' represents the total size of the window border (or box, in can_box 15273 terms), in this case one line at the top and one line at the bottom. 15274 15275 Likewise, '1' is used to represent the width of the window border. 15276 15277 Introduce new functions: 15278 - tui_win_info::box_width () and 15279 - tui_win_info::box_size () 15280 that can be used instead instead of these hardcoded constants. 15281 15282 Implement these such that they return 0 when can_box () == false. 15283 15284 Tested patch completeness by making all windows unboxed: 15285 ... 15286 @@ -85,7 +85,7 @@ struct tui_win_info 15287 /* Return true if this window can be boxed. */ 15288 virtual bool can_box () const 15289 { 15290 - return true; 15291 + return false; 15292 } 15293 15294 int box_width () const 15295 ... 15296 and test-driving TUI. 15297 15298 This required eliminating an assert in 15299 tui_source_window_base::show_source_content, I've included that part as well. 15300 15301 Tested on x86_64-linux. 15302 15303 Approved-By: Tom Tromey <tom@tromey.com> 15304 153052023-11-13 Tom de Vries <tdevries@suse.de> 15306 15307 [gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_window 15308 Currently the call to prefresh in tui_source_window_base::refresh_window looks 15309 like: 15310 ... 15311 prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin, 15312 y + m_content.size (), x + left_margin + view_width - 1); 15313 ... 15314 15315 This is hard to parse. It's not obvious what the arguments mean, and there's 15316 repetition in the argument calculation. 15317 15318 Fix this by rewriting the call as follows: 15319 - use sminrow, smincol, smaxrow and smaxcol variables for the last 15320 4 arguments, and 15321 - calculate the smaxrow and smaxcol variables based on the sminrow and 15322 smincol variables. 15323 15324 Tested on x86_64-linux. 15325 15326 Approved-By: Tom Tromey <tom@tromey.com> 15327 153282023-11-13 Carl Love <cel@linux.ibm.com> 15329 15330 Fix the gdb.ada/inline-section-gc.exp test 15331 The original intention of the test appears to be checking to make sure 15332 setting a breakpoint in an inlined function didn't set multiple 15333 breakpoints where one of them was at address 0. 15334 15335 The gdb.ada/inline-section-gc.exp test may pass or fail depending on the 15336 version of gnat. Per the discussion on IRC, the ada inlining appears to 15337 have some target dependencies. In this test there are two functions, 15338 callee and caller. Function calee is inlined into caller. The test sets 15339 a breakpoint in function callee. The reported location where the 15340 breakpoint is set may be at the requested location in callee or the 15341 location in caller after callee has been inlined. The test needs to 15342 accept either location as correct provided the breakpoint address is not 15343 zero. 15344 15345 This patch checks to see if the reported breakpoint is in function callee 15346 or function caller and fails if the breakpoint address is 0x0. The line 15347 number where the breakpoint is set will match the requested line if the 15348 breakpoint location is reported is callee.adb. If the breakpoint is 15349 reported in caller.adb, the line number in caller is the breakpoint 15350 location in callee where it is inlined into caller. 15351 15352 This patch fixes the single regression failure for the test on PowerPC. 15353 It does not introduce any failures on X86-64. 15354 153552023-11-13 Nick Clifton <nickc@redhat.com> 15356 15357 GNU-ld: ARM: Issues when trying to set target output architecture 15358 PR 28910 15359 * lexsup.c (ld_options): Ensure that the --format option is correctly recognised. 15360 153612023-11-13 Mark Wielaard <mark@klomp.org> 15362 15363 Regenerate gas/config.in and ld/configure 15364 commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*" 15365 changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32 15366 this new name sorts differently when regenerating gas/config.in 15367 15368 commit e922d1eaa "Add ability to change linker warning messages into 15369 errors when reporting executable stacks and/or executable segments." 15370 Introduced two new help strings for --enable-error-execstack and 15371 --enable-error-rwx-segments in configure.ac which weren't included 15372 in ld/configure when regenerated. 15373 15374 * gas/config.in: Regenerate. 15375 * ld/configure: Likewise. 15376 153772023-11-13 Nick Clifton <nickc@redhat.com> 15378 15379 Add documentation for the MIPS assembler's -march=from-abi command line option 15380 153812023-11-13 YunQiang Su <yunqiang.su@cipunited.com> 15382 15383 MIPS: Fix binutils-all tests for r6 triples 15384 153852023-11-13 Chung-Ju Wu <jasonwucj@gmail.com> 15386 15387 Fix redundant space typo in linker documentation. 15388 153892023-11-13 Pedro Alves <pedro@palves.net> 15390 15391 Cancel execution command on thread exit, when stepping, nexting, etc. 15392 If your target has no support for TARGET_WAITKIND_NO_RESUMED events 15393 (and no way to support them, such as the yet-unsubmitted AMDGPU 15394 target), and you step over thread exit with scheduler-locking on, this 15395 is what you get: 15396 15397 (gdb) n 15398 [Thread ... exited] 15399 *hang* 15400 15401 Getting back the prompt by typing Ctrl-C may not even work, since no 15402 inferior thread is running to receive the SIGINT. Even if it works, 15403 it seems unnecessarily harsh. If you started an execution command for 15404 which there's a clear thread of interest (step, next, until, etc.), 15405 and that thread disappears, then I think it's more user friendly if 15406 GDB just detects the situation and aborts the command, giving back the 15407 prompt. 15408 15409 That is what this commit implements. It does this by explicitly 15410 requesting the target to report thread exit events whenever the main 15411 resumed thread has a thread_fsm. Note that unlike stepping over a 15412 breakpoint, we don't need to enable clone events in this case. 15413 15414 With this patch, we get: 15415 15416 (gdb) n 15417 [Thread 0x7ffff7d89700 (LWP 3961883) exited] 15418 Command aborted, thread exited. 15419 (gdb) 15420 15421 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15422 Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95 15423 154242023-11-13 Pedro Alves <pedro@palves.net> 15425 15426 Document remote clone events, and QThreadOptions packet 15427 This commit documents in both manual and NEWS: 15428 15429 - the new remote clone event stop reply, 15430 - the new QThreadOptions packet and its current defined options, 15431 - the associated "set/show remote thread-events-packet" command, 15432 - and the associated QThreadOptions qSupported feature. 15433 15434 Approved-By: Eli Zaretskii <eliz@gnu.org> 15435 Change-Id: Ic1c8de1fefba95729bbd242969284265de42427e 15436 154372023-11-13 Simon Marchi <simon.marchi@efficios.com> 15438 Pedro Alves <pedro@palves.net> 15439 15440 Testcases for stepping over thread exit syscall (PR gdb/27338) 15441 Add new gdb.threads/step-over-thread-exit.exp and 15442 gdb.threads/step-over-thread-exit-while-stop-all-threads.exp 15443 testcases, exercising stepping over thread exit syscall. These make 15444 use of lib/my-syscalls.S to define the exit syscall. 15445 15446 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15447 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 15448 Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9 15449 154502023-11-13 Pedro Alves <pedro@palves.net> 15451 15452 gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro 15453 Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S 15454 behind a SYSCALL macro so that it's easy to add new syscalls without 15455 duplicating code. 15456 15457 Note that the way the macro is implemented, it only works correctly 15458 for syscalls with up to 3 arguments, and, if the syscall doesn't 15459 return (the macro doesn't bother to save/restore callee-saved 15460 registers). 15461 15462 The following patch will want to use the macro to define a wrapper for 15463 the "exit" syscall, so the limitations continue to be sufficient. 15464 15465 Change-Id: I8acf1463b11a084d6b4579aaffb49b5d0dea3bba 15466 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15467 154682023-11-13 Pedro Alves <pedro@palves.net> 15469 15470 Report thread exit event for leader if reporting thread exit events 15471 If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the 15472 thread disappears from the thread list, GDB expects to shortly see a 15473 thread exit event for it. See e.g., here, in 15474 remote_target::update_thread_list(): 15475 15476 /* Do not remove the thread if we've requested to be 15477 notified of its exit. For example, the thread may be 15478 displaced stepping, infrun will need to handle the 15479 exit event, and displaced stepping info is recorded 15480 in the thread object. If we deleted the thread now, 15481 we'd lose that info. */ 15482 if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0) 15483 continue; 15484 15485 There's one scenario that is deleting a thread from the 15486 remote/gdbserver thread list without ever reporting a corresponding 15487 thread exit event though -- check_zombie_leaders. This can lead to 15488 GDB getting confused. For example, with a following patch that 15489 enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see 15490 this regression: 15491 15492 $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp" 15493 ... 15494 Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ... 15495 FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) 15496 ... some more cascading FAILs ... 15497 15498 gdb.log shows: 15499 15500 (gdb) continue 15501 Continuing. 15502 FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) 15503 15504 A passing run would have resulted in: 15505 15506 (gdb) continue 15507 Continuing. 15508 No unwaited-for children left. 15509 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits 15510 15511 note how the leader thread is not listed in the remote-reported XML 15512 thread list below: 15513 15514 (gdb) set debug remote 1 15515 (gdb) set debug infrun 1 15516 (gdb) info threads 15517 Id Target Id Frame 15518 * 1 Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65 15519 3 Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39 15520 (gdb) c 15521 Continuing. 15522 [infrun] clear_proceed_status_thread: 1163850.1163850.0 15523 ... 15524 [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f 15525 [remote] Sending packet: $QPassSignals:#f3 15526 [remote] Packet received: OK 15527 [remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3 15528 [remote] Packet received: OK 15529 ... 15530 [infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3] 15531 ... 15532 [infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0 15533 [remote] Sending packet: $vCont;c:p11c24a.11c24a#98 15534 [infrun] prepare_to_wait: prepare_to_wait 15535 [infrun] reset: reason=handling event 15536 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote 15537 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote 15538 [infrun] fetch_inferior_event: exit 15539 [infrun] fetch_inferior_event: enter 15540 [infrun] scoped_disable_commit_resumed: reason=handling event 15541 [infrun] random_pending_event_thread: None found. 15542 [remote] wait: enter 15543 [remote] Packet received: N 15544 [remote] wait: exit 15545 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 15546 [infrun] print_target_wait_results: -1.0.0 [process -1], 15547 [infrun] print_target_wait_results: status->kind = NO_RESUMED 15548 [infrun] handle_inferior_event: status->kind = NO_RESUMED 15549 [remote] Sending packet: $Hgp0.0#ad 15550 [remote] Packet received: OK 15551 [remote] Sending packet: $qXfer:threads:read::0,1000#92 15552 [remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n 15553 [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed) 15554 ... 15555 15556 ... however, infrun decided there was a resumed thread still, so 15557 ignored the TARGET_WAITKIND_NO_RESUMED event. Debugging GDB, we see 15558 that the "found resumed" thread that GDB finds, is the leader thread. 15559 Even though that thread is not on the remote-reported thread list, it 15560 is still on the GDB thread list, due to the special case in remote.c 15561 mentioned above. 15562 15563 This commit addresses the issue by fixing GDBserver to report a thread 15564 exit event for the zombie leader too, i.e., making GDBserver respect 15565 the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit" 15566 invariant. To do that, it takes a bit more code than one would 15567 imagine off hand, due to the fact that we currently always report LWP 15568 exit pending events as TARGET_WAITKIND_EXITED, and then decide whether 15569 to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting 15570 the event to GDBserver core. For the zombie leader scenario 15571 described, we need to record early on that we want to report a 15572 THREAD_EXITED event, and then make sure that decision isn't lost along 15573 the way to reporting the event to GDBserver core. 15574 15575 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15576 Change-Id: I1e68fccdbc9534434dee07163d3fd19744c8403b 15577 155782023-11-13 Pedro Alves <pedro@palves.net> 15579 15580 Don't resume new threads if scheduler-locking is in effect 15581 If scheduler-locking is in effect, e.g., with "set scheduler-locking 15582 on", and you step over a function that spawns a new thread, the new 15583 thread is allowed to run free, at least until some event is hit, at 15584 which point, whether the new thread is re-resumed depends on a number 15585 of seemingly random factors. E.g., if the target is all-stop, and the 15586 parent thread hits a breakpoint, and GDB decides the breakpoint isn't 15587 interesting to report to the user, then the parent thread is resumed, 15588 but the new thread is left stopped. 15589 15590 I think that letting the new threads run with scheduler-locking 15591 enabled is a defect. This commit fixes that, making use of the new 15592 clone events on Linux, and of target_thread_events() on targets where 15593 new threads have no connection to the thread that spawned them. 15594 15595 Testcase and documentation changes included. 15596 15597 Approved-By: Eli Zaretskii <eliz@gnu.org> 15598 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15599 Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce 15600 156012023-11-13 Pedro Alves <pedro@palves.net> 15602 15603 gdbserver: Queue no-resumed event after thread exit 15604 Normally, if the last resumed thread on the target exits, the server 15605 sends a no-resumed event to GDB. If however, GDB enables the 15606 GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the 15607 server sends a thread exit event for that thread instead. 15608 15609 In all-stop RSP mode, since events can only be forwarded to GDB one at 15610 a time, and the whole target stops whenever an event is reported, GDB 15611 resumes the target again after getting a THREAD_EXITED event, and then 15612 the server finally reports back a no-resumed event if/when 15613 appropriate. 15614 15615 For non-stop RSP though, events are asynchronous, and if the server 15616 sends a thread-exit event for the last resumed thread, the no-resumed 15617 event is never sent. This patch makes sure that in non-stop mode, the 15618 server queues a no-resumed event after the thread-exit event if it was 15619 the last resumed thread that exited. 15620 15621 Without this, we'd see failures in step-over-thread-exit testcases 15622 added later in the series, like so: 15623 15624 continue 15625 Continuing. 15626 - No unwaited-for children left. 15627 - (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits 15628 + FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout) 15629 15630 (and other similar ones) 15631 15632 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15633 Change-Id: I927d78b30f88236dbd5634b051a716f72420e7c7 15634 156352023-11-13 Pedro Alves <pedro@palves.net> 15636 15637 stop_all_threads: (re-)enable async before waiting for stops 15638 Running the 15639 gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcase 15640 added later in the series against gdbserver, after the 15641 TARGET_WAITKIND_NO_RESUMED fix from the following patch, would run 15642 into an infinite loop in stop_all_threads, leading to a timeout: 15643 15644 FAIL: gdb.threads/step-over-thread-exit-while-stop-all-threads.exp: displaced-stepping=off: target-non-stop=on: iter 0: continue (timeout) 15645 15646 The is really a latent bug, and it is about the fact that 15647 stop_all_threads stops listening to events from a target as soon as it 15648 sees a TARGET_WAITKIND_NO_RESUMED, ignoring that 15649 TARGET_WAITKIND_NO_RESUMED may be delayed. handle_no_resumed knows 15650 how to handle delayed no-resumed events, but stop_all_threads was 15651 never taught to. 15652 15653 In more detail, here's what happens with that testcase: 15654 15655 #1 - Multiple threads report breakpoint hits to gdb. 15656 15657 #2 - gdb picks one events, and it's for thread 1. All other stops are 15658 left pending. thread 1 needs to move past a breakpoint, so gdb 15659 stops all threads to start an inline step over for thread 1. 15660 While stopping threads, some of the threads that were still 15661 running report events that are also left pending. 15662 15663 #2 - gdb steps thread 1 15664 15665 #3 - Thread 1 exits while stepping (it steps over an exit syscall), 15666 gdbserver reports thread exit for thread 1 15667 15668 #4 - Thread 1 was the last resumed thread, so gdbserver also reports 15669 no-resumed: 15670 15671 [remote] Notification received: Stop:w0;p3445d0.3445d3 15672 [remote] Sending packet: $vStopped#55 15673 [remote] Packet received: N 15674 [remote] Sending packet: $vStopped#55 15675 [remote] Packet received: OK 15676 15677 #5 - gdb processes the thread exit for thread 1, finishes the step 15678 over and restarts threads. 15679 15680 #6 - gdb picks the next event to process out of one of the resumed 15681 threads with pending events: 15682 15683 [infrun] random_resumed_with_pending_wait_status: Found 32 events, selecting #11 15684 15685 #7 - This is again a breakpoint hit and the breakpoint needs to be 15686 stepped over too, so gdb starts a step-over dance again. 15687 15688 #8 - We reach stop_all_threads, which finds that some threads need to 15689 be stopped. 15690 15691 #9 - wait_one finally consumes the no-resumed event queue by #4. 15692 Seeing this, wait_one disable target async, to stop listening for 15693 events out of the remote target. 15694 15695 #10 - We still haven't seen all the stops expected, so 15696 stop_all_threads tries another iteration. 15697 15698 #11 - Because the remote target is no longer async, and there are no 15699 other targets, wait_one return no-resumed immediately without 15700 polling the remote target. 15701 15702 #12 - We still haven't seen all the stops expected, so 15703 stop_all_threads tries another iteration. goto #11, looping 15704 forever. 15705 15706 Fix this by explicitly enabling/re-enabling target async on targets 15707 that can async, before waiting for stops. 15708 15709 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15710 Change-Id: Ie3ffb0df89635585a6631aa842689cecc989e33f 15711 157122023-11-13 Pedro Alves <pedro@palves.net> 15713 Simon Marchi <simon.marchi@efficios.com> 15714 15715 gdb: clear step over information on thread exit (PR gdb/27338) 15716 GDB doesn't handle correctly the case where a thread steps over a 15717 breakpoint (using either in-line or displaced stepping), and the 15718 executed instruction causes the thread to exit. 15719 15720 Using the test program included later in the series, this is what it 15721 looks like with displaced-stepping, on x86-64 Linux, where we have two 15722 displaced-step buffers: 15723 15724 $ ./gdb -q -nx --data-directory=data-directory build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit -ex "b my_exit_syscall" -ex r 15725 Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit... 15726 Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68. 15727 Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit 15728 [Thread debugging using libthread_db enabled] 15729 Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 15730 [New Thread 0x7ffff7c5f640 (LWP 2915510)] 15731 [Switching to Thread 0x7ffff7c5f640 (LWP 2915510)] 15732 15733 Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 15734 68 syscall 15735 (gdb) c 15736 Continuing. 15737 [New Thread 0x7ffff7c5f640 (LWP 2915524)] 15738 [Thread 0x7ffff7c5f640 (LWP 2915510) exited] 15739 [Switching to Thread 0x7ffff7c5f640 (LWP 2915524)] 15740 15741 Thread 3 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 15742 68 syscall 15743 (gdb) c 15744 Continuing. 15745 [New Thread 0x7ffff7c5f640 (LWP 2915616)] 15746 [Thread 0x7ffff7c5f640 (LWP 2915524) exited] 15747 [Switching to Thread 0x7ffff7c5f640 (LWP 2915616)] 15748 15749 Thread 4 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 15750 68 syscall 15751 (gdb) c 15752 Continuing. 15753 ... hangs ... 15754 15755 The first two times we do "continue", we displaced-step the syscall 15756 instruction that causes the thread to exit. When the thread exits, 15757 the main thread, waiting on pthread_join, is unblocked. It spawns a 15758 new thread, which hits the breakpoint on the syscall again. However, 15759 infrun was never notified that the displaced-stepping threads are done 15760 using the displaced-step buffer, so now both buffers are marked as 15761 used. So when we do the third continue, there are no buffers 15762 available to displaced-step the syscall, so the thread waits forever 15763 for its turn. 15764 15765 When trying the same but with in-line step over (displaced-stepping 15766 disabled): 15767 15768 $ ./gdb -q -nx --data-directory=data-directory \ 15769 build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit \ 15770 -ex "b my_exit_syscall" -ex "set displaced-stepping off" -ex r 15771 Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit... 15772 Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68. 15773 Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit 15774 [Thread debugging using libthread_db enabled] 15775 Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 15776 [New Thread 0x7ffff7c5f640 (LWP 2928290)] 15777 [Switching to Thread 0x7ffff7c5f640 (LWP 2928290)] 15778 15779 Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 15780 68 syscall 15781 (gdb) c 15782 Continuing. 15783 [Thread 0x7ffff7c5f640 (LWP 2928290) exited] 15784 No unwaited-for children left. 15785 (gdb) i th 15786 Id Target Id Frame 15787 1 Thread 0x7ffff7c60740 (LWP 2928285) "step-over-threa" 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0 15788 15789 The current thread <Thread ID 2> has terminated. See `help thread'. 15790 (gdb) thread 1 15791 [Switching to thread 1 (Thread 0x7ffff7c60740 (LWP 2928285))] 15792 #0 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0 15793 (gdb) c 15794 Continuing. 15795 ^C^C 15796 ... hangs ... 15797 15798 The "continue" causes an in-line step to occur, meaning the main 15799 thread is stopped while we step the syscall. The stepped thread exits 15800 when executing the syscall, the linux-nat target notices there are no 15801 more resumed threads to be waited for, so returns 15802 TARGET_WAITKIND_NO_RESUMED, which causes the prompt to return. But 15803 infrun never clears the in-line step over info. So if we try 15804 continuing the main thread, GDB doesn't resume it, because it thinks 15805 there's an in-line step in progress that we need to wait for to 15806 finish, and we are stuck there. 15807 15808 To fix this, infrun needs to be informed when a thread doing a 15809 displaced or in-line step over exits. We can do that with the new 15810 target_set_thread_options mechanism which is optimal for only enabling 15811 exit events of the thread that needs it; or, if that is not supported, 15812 by using target_thread_events, which enables thread exit events for 15813 all threads. This is done by this commit. 15814 15815 This patch then modifies handle_inferior_event in infrun.c to clean up 15816 any step-over the exiting thread might have been doing at the time of 15817 the exit. The cases to consider are: 15818 15819 - the exiting thread was doing an in-line step-over with an all-stop 15820 target 15821 - the exiting thread was doing an in-line step-over with a non-stop 15822 target 15823 - the exiting thread was doing a displaced step-over with a non-stop 15824 target 15825 15826 The displaced-stepping buffer implementation in displaced-stepping.c 15827 is modified to account for the fact that it's possible that we 15828 "finish" a displaced step after a thread exit event. The buffer that 15829 the exiting thread was using is marked as available again and the 15830 original instructions under the scratch pad are restored. However, it 15831 skips applying the fixup, which wouldn't make sense since the thread 15832 does not exist anymore. 15833 15834 Another case that needs handling is if a displaced-stepping thread 15835 exits, and the event is reported while we are in stop_all_threads. We 15836 should call displaced_step_finish in the handle_one function, in that 15837 case. It was already called in other code paths, just not the "thread 15838 exited" path. 15839 15840 This commit doesn't make infrun ask the target to report the 15841 TARGET_WAITKIND_THREAD_EXITED events yet, that'll be done later in the 15842 series. 15843 15844 Note that "stop_print_frame = false;" line is moved to normal_stop, 15845 because TARGET_WAITKIND_THREAD_EXITED can also end up with the event 15846 transmorphed into TARGET_WAITKIND_NO_RESUMED. Moving it to 15847 normal_stop keeps it centralized. 15848 15849 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 15850 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15851 Change-Id: I745c6955d7ef90beb83bcf0ff1d1ac8b9b6285a5 15852 158532023-11-13 Pedro Alves <pedro@palves.net> 15854 15855 Implement GDB_THREAD_OPTION_EXIT support for native Linux 15856 This implements support for the new GDB_THREAD_OPTION_EXIT thread 15857 option for native Linux. 15858 15859 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15860 Change-Id: Ia69fc0b9b96f9af7de7cefc1ddb1fba9bbb0bb90 15861 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 15862 158632023-11-13 Pedro Alves <pedro@palves.net> 15864 15865 Implement GDB_THREAD_OPTION_EXIT support for Linux GDBserver 15866 This implements support for the new GDB_THREAD_OPTION_EXIT thread 15867 option for Linux GDBserver. 15868 15869 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15870 Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38 15871 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 15872 158732023-11-13 Pedro Alves <pedro@palves.net> 15874 15875 Introduce GDB_THREAD_OPTION_EXIT thread option, fix step-over-thread-exit 15876 When stepping over a breakpoint with displaced stepping, GDB needs to 15877 be informed if the stepped thread exits, otherwise the displaced 15878 stepping buffer that was allocated to that thread leaks, and this can 15879 result in deadlock, with other threads waiting for their turn to 15880 displaced step, but their turn never comes. 15881 15882 Similarly, when stepping over a breakpoint in line, GDB also needs to 15883 be informed if the stepped thread exits, so that is can clear the step 15884 over state and re-resume threads. 15885 15886 This commit makes it possible for GDB to ask the target to report 15887 thread exit events for a given thread, using the new "thread options" 15888 mechanism introduced by a previous patch. 15889 15890 This only adds the core bits. Following patches in the series will 15891 teach the Linux backends (native & gdbserver) to handle the 15892 GDB_THREAD_OPTION_EXIT option, and then a later patch will make use of 15893 these thread exit events to clean up displaced stepping and inline 15894 stepping state properly. 15895 15896 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15897 Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38 15898 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 15899 159002023-11-13 Pedro Alves <pedro@palves.net> 15901 15902 Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to core 15903 Currently, infrun assumes that when TARGET_WAITKIND_THREAD_EXITED is 15904 reported, the corresponding GDB thread has already been removed from 15905 the GDB thread list. 15906 15907 Later in the series, that will no longer work, as infrun will need to 15908 refer to the thread's thread_info when it processes 15909 TARGET_WAITKIND_THREAD_EXITED. 15910 15911 As preparation, this patch makes deleting the GDB thread 15912 responsibility of infrun, instead of the target. 15913 15914 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15915 Change-Id: I013d87f61ffc9aaca49f0d6ce2a43e3ea69274de 15916 159172023-11-13 Pedro Alves <pedro@palves.net> 15918 15919 gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE 15920 gdbserver's linux_process_target::wait loops if: 15921 15922 - called in sync mode, and, 15923 - wait_1 returns TARGET_WAITKIND_IGNORE, _and_, 15924 - wait_1 also returns null_ptid. 15925 15926 The null_ptid check fails however when this path is taken: 15927 15928 ptid_t 15929 linux_process_target::filter_exit_event (lwp_info *event_child, 15930 target_waitstatus *ourstatus) 15931 { 15932 ... 15933 if (!is_leader (thread)) 15934 { 15935 if (report_exit_events_for (thread)) 15936 ourstatus->set_thread_exited (0); 15937 else 15938 ourstatus->set_ignore (); <<<<<<< 15939 15940 delete_lwp (event_child); 15941 } 15942 return ptid; 15943 } 15944 15945 This makes linux_process_target::wait return TARGET_WAITKIND_IGNORE in 15946 sync mode, which is unexpected by the core and fails an assertion. 15947 15948 This commit fixes it by just making linux_process_target::wait loop if 15949 it got a TARGET_WAITKIND_IGNORE, irrespective of event_ptid. 15950 15951 Change-Id: I39776908a6c75cbd68aa04139ffcf7be334868cf 15952 159532023-11-13 Pedro Alves <pedro@palves.net> 15954 15955 all-stop/synchronous RSP support thread-exit events 15956 Currently, GDB does not understand the THREAD_EXITED stop reply in 15957 remote all-stop mode. There's no good reason for this, it just 15958 happened that THREAD_EXITED was only ever reported in non-stop mode so 15959 far. This patch teaches GDB to parse that event in all-stop RSP too. 15960 There is no need to add a qSupported feature for this, because the 15961 server won't send a THREAD_EXITED event unless GDB explicitly asks for 15962 it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT 15963 QThreadOptions option added in the next patch. 15964 15965 Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966 15966 159672023-11-13 Pedro Alves <pedro@palves.net> 15968 15969 Remove gdb/19675 kfails (displaced stepping + clone) 15970 Now that gdb/19675 is fixed for both native and gdbserver GNU/Linux, 15971 remove the gdb/19675 kfails. 15972 15973 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 15974 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15975 Change-Id: I95c1c38ca370100675d303cd3c8995860bef465d 15976 159772023-11-13 Pedro Alves <pedro@palves.net> 15978 15979 gdbserver: Hide and don't detach pending clone children 15980 This commit extends the logic added by these two commits from a while 15981 ago: 15982 15983 #1 7b961964f866 (gdbserver: hide fork child threads from GDB), 15984 #2 df5ad102009c (gdb, gdbserver: detach fork child when detaching from fork parent) 15985 15986 ... to handle thread clone events, which are very similar to (v)fork 15987 events. 15988 15989 For #1, we want to hide clone children as well, so just update the 15990 comments. 15991 15992 For #2, unlike (v)fork children, pending clone children aren't full 15993 processes, they're just threads, so don't detach them in 15994 handle_detach. linux-low.cc will take care of detaching them along 15995 with all other threads of the process, there's nothing special that 15996 needs to be done. 15997 15998 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 15999 Change-Id: I7f5901d07efda576a2522d03e183994e071b8ffc 16000 160012023-11-13 Pedro Alves <pedro@palves.net> 16002 16003 Thread options & clone events (Linux GDBserver) 16004 This patch teaches the Linux GDBserver backend to report clone events 16005 to GDB, when GDB has requested them with the GDB_THREAD_OPTION_CLONE 16006 thread option, via the new QThreadOptions packet. 16007 16008 This shuffles code in linux_process_target::handle_extended_wait 16009 around to a more logical order when we now have to handle and 16010 potentially report all of fork/vfork/clone. 16011 16012 Raname lwp_info::fork_relative -> lwp_info::relative as the field is 16013 no longer only about (v)fork. 16014 16015 With this, gdb.threads/stepi-over-clone.exp now cleanly passes against 16016 GDBserver, so remove the native-target-only requirement from that 16017 testcase. 16018 16019 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 16020 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830 16021 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16022 Change-Id: I3a19bc98801ec31e5c6fdbe1ebe17df855142bb2 16023 160242023-11-13 Pedro Alves <pedro@palves.net> 16025 16026 Thread options & clone events (native Linux) 16027 This commit teaches the native Linux target about the 16028 GDB_THREAD_OPTION_CLONE thread option. It's actually simpler to just 16029 continue reporting all clone events unconditionally to the core. 16030 There's never any harm in reporting a clone event when the option is 16031 disabled. All we need to do is to report support for the option, 16032 otherwise GDB falls back to use target_thread_events(). 16033 16034 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 16035 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830 16036 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16037 Change-Id: If90316e2dcd0c61d0fefa0d463c046011698acf9 16038 160392023-11-13 Pedro Alves <pedro@palves.net> 16040 16041 Thread options & clone events (core + remote) 16042 A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED 16043 event kind, and made the Linux target report clone events. 16044 16045 A following patch will teach Linux GDBserver to do the same thing. 16046 16047 However, for remote debugging, it wouldn't be ideal for GDBserver to 16048 report every clone event to GDB, when GDB only cares about such events 16049 in some specific situations. Reporting clone events all the time 16050 would be potentially chatty. We don't enable thread create/exit 16051 events all the time for the same reason. Instead we have the 16052 QThreadEvents packet. QThreadEvents is target-wide, though. 16053 16054 This patch makes GDB instead explicitly request that the target 16055 reports clone events or not, on a per-thread basis. 16056 16057 In order to be able to do that with GDBserver, we need a new remote 16058 protocol feature. Since a following patch will want to enable thread 16059 exit events on per-thread basis too, the packet introduced here is 16060 more generic than just for clone events. It lets you enable/disable a 16061 set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS. 16062 16063 IOW, this commit introduces a new QThreadOptions packet, that lets you 16064 specify a set of per-thread event options you want to enable. The 16065 packet accepts a list of options/thread-id pairs, similarly to vCont, 16066 processed left to right, with the options field being a number 16067 interpreted as a bit mask of options. The only option defined in this 16068 commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target 16069 to report clone events. Another patch later in the series will 16070 introduce another option. 16071 16072 For example, this packet sets option "1" (clone events) on thread 16073 p1000.2345: 16074 16075 QThreadOptions;1:p1000.2345 16076 16077 and this clears options for all threads of process 1000, and then sets 16078 option "1" (clone events) on thread p1000.2345: 16079 16080 QThreadOptions;0:p1000.-1;1:p1000.2345 16081 16082 This clears options of all threads of all processes: 16083 16084 QThreadOptions;0 16085 16086 The target reports the set of supported options by including 16087 "QThreadOptions=<supported options>" in its qSupported response. 16088 16089 infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping 16090 over a breakpoint. 16091 16092 Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit 16093 their parent's thread options. This is so that GDB can send e.g., 16094 "QThreadOptions;0;1:TID" without worrying about threads it doesn't 16095 know about yet. 16096 16097 Documentation for this new remote protocol feature is included in a 16098 documentation patch later in the series. 16099 16100 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 16101 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830 16102 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16103 Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e 16104 161052023-11-13 Pedro Alves <pedro@palves.net> 16106 16107 Avoid duplicate QThreadEvents packets 16108 Similarly to QProgramSignals and QPassSignals, avoid sending duplicate 16109 QThreadEvents packets. 16110 16111 Approved-By: Andrew Burgess <aburgess@redhat.com> 16112 Change-Id: Iaf5babb0b64e1527ba4db31aac8674d82b17e8b4 16113 161142023-11-13 Pedro Alves <pedro@palves.net> 16115 16116 Support clone events in the remote protocol 16117 The previous patch taught GDB about a new 16118 TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target 16119 report clone events. 16120 16121 A following patch will teach Linux GDBserver to do the same thing. 16122 16123 But before we get there, we need to teach the remote protocol about 16124 TARGET_WAITKIND_THREAD_CLONED. That's what this patch does. Clone is 16125 very similar to vfork and fork, and the new stop reply is likewise 16126 handled similarly. The stub reports "T05clone:...". 16127 16128 GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and 16129 forward it to GDB in this patch, but no backend actually emits it yet. 16130 That will be done in a following patch. 16131 16132 Documentation for this new remote protocol feature is included in a 16133 documentation patch later in the series. 16134 16135 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16136 Change-Id: If271f20320d864f074d8ac0d531cc1a323da847f 16137 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 16138 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830 16139 161402023-11-13 Pedro Alves <pedro@palves.net> 16141 Andrew Burgess <aburgess@redhat.com> 16142 16143 Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED 16144 (A good chunk of the problem statement in the commit log below is 16145 Andrew's, adjusted for a different solution, and for covering 16146 displaced stepping too. The testcase is mostly Andrew's too.) 16147 16148 This commit addresses bugs gdb/19675 and gdb/27830, which are about 16149 stepping over a breakpoint set at a clone syscall instruction, one is 16150 about displaced stepping, and the other about in-line stepping. 16151 16152 Currently, when a new thread is created through a clone syscall, GDB 16153 sets the new thread running. With 'continue' this makes sense 16154 (assuming no schedlock): 16155 16156 - all-stop mode, user issues 'continue', all threads are set running, 16157 a newly created thread should also be set running. 16158 16159 - non-stop mode, user issues 'continue', other pre-existing threads 16160 are not affected, but as the new thread is (sort-of) a child of the 16161 thread the user asked to run, it makes sense that the new threads 16162 should be created in the running state. 16163 16164 Similarly, if we are stopped at the clone syscall, and there's no 16165 software breakpoint at this address, then the current behaviour is 16166 fine: 16167 16168 - all-stop mode, user issues 'stepi', stepping will be done in place 16169 (as there's no breakpoint to step over). While stepping the thread 16170 of interest all the other threads will be allowed to continue. A 16171 newly created thread will be set running, and then stopped once the 16172 thread of interest has completed its step. 16173 16174 - non-stop mode, user issues 'stepi', stepping will be done in place 16175 (as there's no breakpoint to step over). Other threads might be 16176 running or stopped, but as with the continue case above, the new 16177 thread will be created running. The only possible issue here is 16178 that the new thread will be left running after the initial thread 16179 has completed its stepi. The user would need to manually select 16180 the thread and interrupt it, this might not be what the user 16181 expects. However, this is not something this commit tries to 16182 change. 16183 16184 The problem then is what happens when we try to step over a clone 16185 syscall if there is a breakpoint at the syscall address. 16186 16187 - For both all-stop and non-stop modes, with in-line stepping: 16188 16189 + user issues 'stepi', 16190 + [non-stop mode only] GDB stops all threads. In all-stop mode all 16191 threads are already stopped. 16192 + GDB removes s/w breakpoint at syscall address, 16193 + GDB single steps just the thread of interest, all other threads 16194 are left stopped, 16195 + New thread is created running, 16196 + Initial thread completes its step, 16197 + [non-stop mode only] GDB resumes all threads that it previously 16198 stopped. 16199 16200 There are two problems in the in-line stepping scenario above: 16201 16202 1. The new thread might pass through the same code that the initial 16203 thread is in (i.e. the clone syscall code), in which case it will 16204 fail to hit the breakpoint in clone as this was removed so the 16205 first thread can single step, 16206 16207 2. The new thread might trigger some other stop event before the 16208 initial thread reports its step completion. If this happens we 16209 end up triggering an assertion as GDB assumes that only the 16210 thread being stepped should stop. The assert looks like this: 16211 16212 infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. 16213 16214 - For both all-stop and non-stop modes, with displaced stepping: 16215 16216 + user issues 'stepi', 16217 + GDB starts the displaced step, moves thread's PC to the 16218 out-of-line scratch pad, maybe adjusts registers, 16219 + GDB single steps the thread of interest, [non-stop mode only] all 16220 other threads are left as they were, either running or stopped. 16221 In all-stop, all other threads are left stopped. 16222 + New thread is created running, 16223 + Initial thread completes its step, GDB re-adjusts its PC, 16224 restores/releases scratchpad, 16225 + [non-stop mode only] GDB resumes the thread, now past its 16226 breakpoint. 16227 + [all-stop mode only] GDB resumes all threads. 16228 16229 There is one problem with the displaced stepping scenario above: 16230 16231 3. When the parent thread completed its step, GDB adjusted its PC, 16232 but did not adjust the child's PC, thus that new child thread 16233 will continue execution in the scratch pad, invoking undefined 16234 behavior. If you're lucky, you see a crash. If unlucky, the 16235 inferior gets silently corrupted. 16236 16237 What is needed is for GDB to have more control over whether the new 16238 thread is created running or not. Issue #1 above requires that the 16239 new thread not be allowed to run until the breakpoint has been 16240 reinserted. The only way to guarantee this is if the new thread is 16241 held in a stopped state until the single step has completed. Issue #3 16242 above requires that GDB is informed of when a thread clones itself, 16243 and of what is the child's ptid, so that GDB can fixup both the parent 16244 and the child. 16245 16246 When looking for solutions to this problem I considered how GDB 16247 handles fork/vfork as these have some of the same issues. The main 16248 difference between fork/vfork and clone is that the clone events are 16249 not reported back to core GDB. Instead, the clone event is handled 16250 automatically in the target code and the child thread is immediately 16251 set running. 16252 16253 Note we have support for requesting thread creation events out of the 16254 target (TARGET_WAITKIND_THREAD_CREATED). However, those are reported 16255 for the new/child thread. That would be sufficient to address in-line 16256 stepping (issue #1), but not for displaced-stepping (issue #3). To 16257 handle displaced-stepping, we need an event that is reported to the 16258 _parent_ of the clone, as the information about the displaced step is 16259 associated with the clone parent. TARGET_WAITKIND_THREAD_CREATED 16260 includes no indication of which thread is the parent that spawned the 16261 new child. In fact, for some targets, like e.g., Windows, it would be 16262 impossible to know which thread that was, as thread creation there 16263 doesn't work by "cloning". 16264 16265 The solution implemented here is to model clone on fork/vfork, and 16266 introduce a new TARGET_WAITKIND_THREAD_CLONED event. This event is 16267 similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except 16268 that we end up with a new thread in the same process, instead of a new 16269 thread of a new process. Like FORKED and VFORKED, THREAD_CLONED 16270 waitstatuses have a child_ptid property, and the child is held stopped 16271 until GDB explicitly resumes it. This addresses the in-line stepping 16272 case (issues #1 and #2). 16273 16274 The infrun code that handles displaced stepping fixup for the child 16275 after a fork/vfork event is thus reused for THREAD_CLONE, with some 16276 minimal conditions added, addressing the displaced stepping case 16277 (issue #3). 16278 16279 The native Linux backend is adjusted to unconditionally report 16280 TARGET_WAITKIND_THREAD_CLONED events to the core. 16281 16282 Following the follow_fork model in core GDB, we introduce a 16283 target_follow_clone target method, which is responsible for making the 16284 new clone child visible to the rest of GDB. 16285 16286 Subsequent patches will add clone events support to the remote 16287 protocol and gdbserver. 16288 16289 displaced_step_in_progress_thread becomes unused with this patch, but 16290 a new use will reappear later in the series. To avoid deleting it and 16291 readding it back, this patch marks it with attribute unused, and the 16292 latter patch removes the attribute again. We need to do this because 16293 the function is static, and with no callers, the compiler would warn, 16294 (error with -Werror), breaking the build. 16295 16296 This adds a new gdb.threads/stepi-over-clone.exp testcase, which 16297 exercises stepping over a clone syscall, with displaced stepping vs 16298 inline stepping, and all-stop vs non-stop. We already test stepping 16299 over clone syscalls with gdb.base/step-over-syscall.exp, but this test 16300 uses pthreads, while the other test uses raw clone, and this one is 16301 more thorough. The testcase passes on native GNU/Linux, but fails 16302 against GDBserver. GDBserver will be fixed by a later patch in the 16303 series. 16304 16305 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 16306 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830 16307 Change-Id: I95c06024736384ae8542a67ed9fdf6534c325c8e 16308 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16309 163102023-11-13 Pedro Alves <pedro@palves.net> 16311 16312 gdb/linux: Delete all other LWPs immediately on ptrace exec event 16313 I noticed that on an Ubuntu 20.04 system, after a following patch 16314 ("Step over clone syscall w/ breakpoint, 16315 TARGET_WAITKIND_THREAD_CLONED"), the gdb.threads/step-over-exec.exp 16316 was passing cleanly, but still, we'd end up with four new unexpected 16317 GDB core dumps: 16318 16319 === gdb Summary === 16320 16321 # of unexpected core files 4 16322 # of expected passes 48 16323 16324 That said patch is making the pre-existing 16325 gdb.threads/step-over-exec.exp testcase (almost silently) expose a 16326 latent problem in gdb/linux-nat.c, resulting in a GDB crash when: 16327 16328 #1 - a non-leader thread execs 16329 #2 - the post-exec program stops somewhere 16330 #3 - you kill the inferior 16331 16332 Instead of #3 directly, the testcase just returns, which ends up in 16333 gdb_exit, tearing down GDB, which kills the inferior, and is thus 16334 equivalent to #3 above. 16335 16336 Vis (after said patch is applied): 16337 16338 $ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true 16339 ... 16340 (top-gdb) r 16341 ... 16342 (gdb) b main 16343 ... 16344 (gdb) r 16345 ... 16346 Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69 16347 69 argv0 = argv[0]; 16348 (gdb) c 16349 Continuing. 16350 [New Thread 0x7ffff7d89700 (LWP 2506975)] 16351 Other going in exec. 16352 Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd 16353 process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd 16354 16355 Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28 16356 28 foo (); 16357 (gdb) k 16358 ... 16359 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 16360 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393 16361 393 return m_suspend.waitstatus_pending_p; 16362 (top-gdb) bt 16363 #0 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393 16364 #1 0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345 16365 #2 0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564 16366 #3 0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284 16367 #4 0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278 16368 #5 0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247 16369 #6 0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864 16370 #7 0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590 16371 #8 0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911 16372 ... 16373 16374 The root of the problem is that when a non-leader LWP execs, it just 16375 changes its tid to the tgid, replacing the pre-exec leader thread, 16376 becoming the new leader. There's no thread exit event for the execing 16377 thread. It's as if the old pre-exec LWP vanishes without trace. The 16378 ptrace man page says: 16379 16380 "PTRACE_O_TRACEEXEC (since Linux 2.5.46) 16381 Stop the tracee at the next execve(2). A waitpid(2) by the 16382 tracer will return a status value such that 16383 16384 status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8)) 16385 16386 If the execing thread is not a thread group leader, the thread 16387 ID is reset to thread group leader's ID before this stop. 16388 Since Linux 3.0, the former thread ID can be retrieved with 16389 PTRACE_GETEVENTMSG." 16390 16391 When the core of GDB processes an exec events, it deletes all the 16392 threads of the inferior. But, that is too late -- deleting the thread 16393 does not delete the corresponding LWP, so we end leaving the pre-exec 16394 non-leader LWP stale in the LWP list. That's what leads to the crash 16395 above -- linux_nat_target::kill iterates over all LWPs, and after the 16396 patch in question, that code will look for the corresponding 16397 thread_info for each LWP. For the pre-exec non-leader LWP still 16398 listed, won't find one. 16399 16400 This patch fixes it, by deleting the pre-exec non-leader LWP (and 16401 thread) from the LWP/thread lists as soon as we get an exec event out 16402 of ptrace. 16403 16404 GDBserver does not need an equivalent fix, because it is already doing 16405 this, as side effect of mourning the pre-exec process, in 16406 gdbserver/linux-low.cc: 16407 16408 else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events) 16409 { 16410 ... 16411 /* Delete the execing process and all its threads. */ 16412 mourn (proc); 16413 switch_to_thread (nullptr); 16414 16415 16416 The crash with gdb.threads/step-over-exec.exp is not observable on 16417 newer systems, which postdate the glibc change to move "libpthread.so" 16418 internals to "libc.so.6", because right after the exec, GDB traps a 16419 load event for "libc.so.6", which leads to GDB trying to open 16420 libthread_db for the post-exec inferior, and, on such systems that 16421 succeeds. When we load libthread_db, we call 16422 linux_stop_and_wait_all_lwps, which, as the name suggests, stops all 16423 lwps, and then waits to see their stops. While doing this, GDB 16424 detects that the pre-exec stale LWP is gone, and deletes it. 16425 16426 If we use "catch exec" to stop right at the exec before the 16427 "libc.so.6" load event ever happens, and issue "kill" right there, 16428 then GDB crashes on newer systems as well. So instead of tweaking 16429 gdb.threads/step-over-exec.exp to cover the fix, add a new 16430 gdb.threads/threads-after-exec.exp testcase that uses "catch exec". 16431 The test also uses the new "maint info linux-lwps" command if testing 16432 on Linux native, which also exposes the stale LWP problem with an 16433 unfixed GDB. 16434 16435 Also tweak a comment in infrun.c:follow_exec referring to how 16436 linux-nat.c used to behave, as it would become stale otherwise. 16437 16438 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 16439 Change-Id: I21ec18072c7750f3a972160ae6b9e46590376643 16440 164412023-11-13 Andrew Burgess <aburgess@redhat.com> 16442 16443 Add "maint info linux-lwps" command 16444 This adds a maintenance command that lets you list all the LWPs under 16445 control of the linux-nat target. 16446 16447 For example: 16448 16449 (gdb) maint info linux-lwps 16450 LWP Ptid Thread ID 16451 560948.561047.0 None 16452 560948.560948.0 1.1 16453 16454 This shows that "560948.561047.0" LWP doesn't map to any thread_info 16455 object, which is bogus. We'll be using this in a testcase in a 16456 following patch. 16457 16458 Co-Authored-By: Pedro Alves <pedro@palves.net> 16459 Change-Id: Ic4e9e123385976e5cd054391990124b7a20fb3f5 16460 164612023-11-13 Tom de Vries <tdevries@suse.de> 16462 16463 [gdb/tui] Fix Wmaybe-uninitialized in tui_find_disassembly_address 16464 When building gdb with -O2, we run into: 16465 ... 16466 gdb/tui/tui-disasm.c: In function ‘CORE_ADDR tui_find_disassembly_address \ 16467 (gdbarch*, CORE_ADDR, int)’: 16468 gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used uninitialized \ 16469 in this function [-Wmaybe-uninitialized] 16470 if (last_addr < pc) 16471 ^~ 16472 ... 16473 16474 The warning triggers since commit 72535eb14bd ("[gdb/tui] Fix segfault in 16475 tui_find_disassembly_address"). 16476 16477 Fix the warning by ensuring that last_addr is initialized at the point of 16478 use: 16479 ... 16480 + last_addr = asm_lines.back ().addr; 16481 if (last_addr < pc) 16482 ... 16483 16484 Tested on x86_64-linux. 16485 164862023-11-13 Tom de Vries <tdevries@suse.de> 16487 16488 [gdb/tui] Make assert in tui_find_disassembly_address more strict 16489 In tui_find_disassembly_address we find an assert: 16490 ... 16491 if (asm_lines.size () < max_lines) 16492 { 16493 if (!possible_new_low.has_value ()) 16494 return new_low; 16495 16496 /* Take the best possible match we have. */ 16497 new_low = *possible_new_low; 16498 next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines); 16499 last_addr = asm_lines.back ().addr; 16500 gdb_assert (asm_lines.size () >= max_lines); 16501 } 16502 ... 16503 16504 The comment right above: 16505 ... 16506 /* If we failed to disassemble the required number of lines then the 16507 following walk forward is not going to work, it assumes that 16508 ASM_LINES contains exactly MAX_LINES entries. Instead we should 16509 consider falling back to a previous possible start address in 16510 POSSIBLE_NEW_LOW. */ 16511 ... 16512 claims that the more strict asm_lines.size () == max_line is required. 16513 16514 Update the assert to reflect this, and move it to after the if because it's 16515 supposed to hold in general, not just when entering the if. 16516 16517 Tested on x86_64-linux. 16518 165192023-11-13 Tom Tromey <tom@tromey.com> 16520 16521 Remove declaration of re_comp 16522 defs.h declares re_comp, but it shouldn't. If this is needed, it 16523 should be picked up from xregex.h via gdb_regex.h. 16524 16525 Tested by rebuilding. 16526 16527 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 16528 165292023-11-13 GDB Administrator <gdbadmin@sourceware.org> 16530 16531 Automatic date update in version.in 16532 165332023-11-12 GDB Administrator <gdbadmin@sourceware.org> 16534 16535 Automatic date update in version.in 16536 165372023-11-11 GDB Administrator <gdbadmin@sourceware.org> 16538 16539 Automatic date update in version.in 16540 165412023-11-10 Simon Marchi <simon.marchi@efficios.com> 16542 16543 bfd, binutils: add gfx11 amdgpu architectures 16544 Teach bfd and readelf about some recent gfx11 architectures. This code 16545 is taken from the rocgdb 5.7.x branch [1]. 16546 16547 [1] https://github.com/rocm-Developer-Tools/rocgdb/tree/rocm-5.7.x 16548 16549 bfd/ChangeLog: 16550 16551 * archures.c (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101, 16552 bfd_mach_amdgcn_gfx1102): New. 16553 * bfd-in2.h (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101, 16554 bfd_mach_amdgcn_gfx1102): New. 16555 * cpu-amdgcn.c (arch_info_struct): Add entries for 16556 bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101, 16557 bfd_mach_amdgcn_gfx1102. 16558 16559 binutils/ChangeLog: 16560 16561 * readelf.c (decode_AMDGPU_machine_flags): Handle gfx1100, 16562 gfx1101, gfx1102. 16563 16564 include/ChangeLog: 16565 16566 * elf/amdgpu.h (EF_AMDGPU_MACH_AMDGCN_GFX1100, 16567 EF_AMDGPU_MACH_AMDGCN_GFX1101, 16568 EF_AMDGPU_MACH_AMDGCN_GFX1102): New. 16569 16570 Change-Id: I95a8a62942e359781a1c9fa2079950fbcf2a78b8 16571 Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com> 16572 Cc: Lancelot Six <lancelot.six@amd.com> 16573 165742023-11-10 Michael J. Eager <eager@eagercon.com> 16575 16576 Correct formatting errors in elf32-microblaze.c 16577 165782023-11-10 YunQiang Su <yunqiang.su@cipunited.com> 16579 16580 Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian 16581 16582 GAS/MIPS: Fix testcase module-defer-warn2 for r2+ triples 16583 165842023-11-10 Vsevolod Alekseyev <sevaa@sprynet.com> 16585 16586 readelf..debug-dump=loc displays bogus base addresses 16587 PR 30880 16588 * dwarf.c (read_and_display_attr_value): Fix loclist handling. (display_loclists_list): Likewise. 16589 165902023-11-10 YunQiang Su <yunqiang.su@cipunited.com> 16591 16592 GAS/MIPS: Add mips16-e-irix.d testcase 16593 165942023-11-10 Ying Huang <ying.huang@oss.cipunited.com> 16595 16596 MIPS: Change all E_MIPS_* to EF_MIPS_* 16597 165982023-11-10 Nick Clifton <nickc@redhat.com> 16599 16600 Add ability to change linker warning messages into errors when reporting executable stacks and/or executable segments. 16601 include 16602 * bfdlink.h (struct bfd_link_info): Update descriptions of the 'execstack', 'noexecstack' and 'warn_execstack' fields. Add 'error_exectack' and 'warn_is_error_for_rwx_segments' fields. 16603 16604 bfd 16605 * elf.c (assign_file_positions_except_relocs): Turn warnings about executable segments into errors if so requested. 16606 * elflink.c (bfd_elf_size_dynamic_sections): Turn warnings about executable stacks into errors if so requested. 16607 16608 ld 16609 * ldlex.h (enum option_values): Add OPTION_ERROR_EXECSTACK, OPTION_NO_ERROR_EXECSTACK, OPTION_WARN_EXECSTACK_OBJECTS, OPTION_ERROR_RWX_SEGMENTS and OPTION_NO_ERROR_RWX_SEGMENTS. (struct ld_option): Add new long options. (parse_args): Parse new long options. (elf_static_list_options): Display the new options. 16610 * ld.texi: Document the new command line options. 16611 * configure.ac (error-execstack): New configuration option. (error-rwx-segments): New configuration option. 16612 * emultempl/elf.em (_before_parse): Initialse the new linkinfo fields. 16613 * NEWS: Mention the new features. 16614 * config.in: Regenerate. 16615 * configure: Regenerate. 16616 * testsuite/ld-elf/commonpage2.d: Disable errors for RWX segments and/or executable stacks. 16617 * testsuite/ld-elf/elf.exp: Likewise. 16618 * testsuite/ld-elf/header.d: Likewise. 16619 * testsuite/ld-elf/loadaddr1.d: Likewise. 16620 * testsuite/ld-elf/loadaddr2.d: Likewise. 16621 * testsuite/ld-elf/maxpage4.d: Likewise. 16622 * testsuite/ld-elf/nobits-1.d: Likewise. 16623 * testsuite/ld-elf/note-1.d: Likewise. 16624 * testsuite/ld-elf/orphan-10.d: Likewise. 16625 * testsuite/ld-elf/orphan-11.d: Likewise. 16626 * testsuite/ld-elf/orphan-12.d: Likewise. 16627 * testsuite/ld-elf/orphan-5.d: Likewise. 16628 * testsuite/ld-elf/orphan-7.d: Likewise. 16629 * testsuite/ld-elf/orphan-8.d: Likewise. 16630 * testsuite/ld-elf/orphan-9.d: Likewise. 16631 * testsuite/ld-elf/orphan-region.d: Likewise. 16632 * testsuite/ld-elf/orphan.d: Likewise. 16633 * testsuite/ld-elf/pr19539.d: Likewise. 16634 * testsuite/ld-elf/pr26256-1a.d: Likewise. 16635 * testsuite/ld-elf/pr26907.d: Likewise. 16636 * testsuite/ld-elf/pr28597.d: Likewise. 16637 * testsuite/ld-elf/retain2.d: Likewise. 16638 * testsuite/ld-elf/shared.exp: Likewise. 16639 * testsuite/ld-elf/size-1.d: Likewise. 16640 * testsuite/ld-elf/textaddr7.d: Likewise. 16641 * testsuite/ld-elf/warn1.d: Likewise. 16642 * testsuite/ld-elf/warn2.d: Likewise. 16643 * testsuite/ld-i386/discarded1.d: Likewise. 16644 * testsuite/ld-i386/pr19175.d: Likewise. 16645 * testsuite/ld-i386/pr19539.d: Likewise. 16646 * testsuite/ld-i386/pr23189.d: Likewise. 16647 * testsuite/ld-plugin/lto-3r.d: Likewise. 16648 * testsuite/ld-plugin/lto-5r.d: Likewise. 16649 * testsuite/ld-plugin/lto.exp: Likewise. 16650 * testsuite/ld-powerpc/ppc476-shared.d: Likewise. 16651 * testsuite/ld-powerpc/ppc476-shared2.d: Likewise. 16652 * testsuite/ld-powerpc/pr28827-2.d: Likewise. 16653 * testsuite/ld-s390/s390.exp: Likewise. 16654 * testsuite/ld-scripts/align2a.d: Likewise. 16655 * testsuite/ld-scripts/align2b.d: Likewise. 16656 * testsuite/ld-scripts/align5.d: Likewise. 16657 * testsuite/ld-scripts/alignof.exp: Likewise. 16658 * testsuite/ld-scripts/crossref.exp: Likewise. 16659 * testsuite/ld-scripts/defined2.d: Likewise. 16660 * testsuite/ld-scripts/defined3.d: Likewise. 16661 * testsuite/ld-scripts/defined5.d: Likewise. 16662 * testsuite/ld-scripts/pr14962.d: Likewise. 16663 * testsuite/ld-scripts/pr18963.d: Likewise. 16664 * testsuite/ld-scripts/pr20302.d: Likewise. 16665 * testsuite/ld-scripts/print-memory-usage.exp: Likewise. 16666 * testsuite/ld-scripts/rgn-at1.d: Likewise. 16667 * testsuite/ld-scripts/rgn-at10.d: Likewise. 16668 * testsuite/ld-scripts/rgn-at4.d: Likewise. 16669 * testsuite/ld-scripts/rgn-at6.d: Likewise. 16670 * testsuite/ld-scripts/rgn-at8.d: Likewise. 16671 * testsuite/ld-scripts/rgn-at9.d: Likewise. 16672 * testsuite/ld-scripts/rgn-over1.d: Likewise. 16673 * testsuite/ld-scripts/rgn-over2.d: Likewise. 16674 * testsuite/ld-scripts/rgn-over4.d: Likewise. 16675 * testsuite/ld-scripts/rgn-over5.d: Likewise. 16676 * testsuite/ld-scripts/rgn-over6.d: Likewise. 16677 * testsuite/ld-scripts/script.exp: Likewise. 16678 * testsuite/ld-scripts/sizeof.exp: Likewise. 16679 * testsuite/ld-scripts/sort-file.d: Likewise. 16680 * testsuite/ld-x86-64/discarded1.d: Likewise. 16681 * testsuite/ld-x86-64/pr19175.d: Likewise. 16682 * testsuite/ld-x86-64/pr19539a.d: Likewise. 16683 * testsuite/ld-x86-64/pr19539b.d: Likewise. 16684 * testsuite/ld-x86-64/pr23189.d: Likewise. 16685 166862023-11-10 Nick Clifton <nickc@redhat.com> 16687 16688 Move new features above the 'Changes in 2.41' comment 16689 166902023-11-10 Lulu Cai <cailulu@loongson.cn> 16691 16692 Add support for ilp32 register alias. 16693 166942023-11-10 GDB Administrator <gdbadmin@sourceware.org> 16695 16696 Automatic date update in version.in 16697 166982023-11-09 Michael Matz <matz@suse.de> 16699 16700 bfd: use less memory in string merging 16701 the offset-to-entry mappings are allocated in blocks, which may 16702 become a bit wasteful in case there are extremely many small 16703 input files or sections. This made it so that a large project 16704 (Qt5WebEngine) didn't build anymore on x86 32bit due to address 16705 space limits. It barely fit into address space before the new 16706 string merging, and then got pushed over the limit by this. 16707 16708 So instead of leaving the waste reallocate the maps to their final 16709 size once known. Now the link barely fits again. 16710 16711 bfd/ 16712 * merge.c (record_section): Reallocate offset maps to their 16713 final size. 16714 167152023-11-09 Michael Matz <matz@suse.de> 16716 16717 ld: Avoid overflows in string merging 16718 as the bug report shows we had an overflow in the test if 16719 hash table resizing is needed. Reorder the expression to avoid 16720 that. There's still a bug somewhere in gracefully handling 16721 failure in resizing (e.g. out of memory), but this pushes the 16722 boundary for that occurring somewhen into the future and 16723 immediately helps the reporter. 16724 16725 bfd/ 16726 16727 PR ld/31009 16728 * merge.c (NEEDS_RESIZE): New macro avoiding overflow. 16729 (sec_merge_maybe_resize): Use it. 16730 (sec_merge_hash_insert): Ditto. 16731 167322023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16733 16734 ld: aarch64: Use lp64 abi in recent BTI stub tests 16735 The tests are not compatible with ilp32 abi: the GNU property 16736 note is ABI dependent (size changes) and the disasm is ABI 16737 dependent too. Making the test portable between the ABIs is 16738 not trivial. 16739 16740 For now force lp64 abi. 16741 167422023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16743 16744 ld: aarch64: Add BTI stub insertion test PR30930 16745 The test creates a large shared library and covers a number of 16746 BTI stub insertion cases. 16747 167482023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16749 16750 bfd: aarch64: Avoid BTI stub for a PLT that has BTI 16751 We decide to emit BTI stubs based on the instruction at the target 16752 location. But PLT code is generated later than the stubs so we always 16753 read 0 which is not a valid BTI. 16754 16755 Fix the logic to special case the PLT section: this is code the linker 16756 generates so we know when it will have BTI. 16757 16758 This avoids BTI stubs in large executables where the PLTs have them 16759 already. An alternative is to never emit BTI stubs for PLTs, instead 16760 use BTI in the PLT if a library gets too big, however that may be 16761 more tricky given the ordering of PLT sizing and stub insertion. 16762 16763 Related to bug 30957. 16764 167652023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16766 16767 bfd: aarch64: Fix leaks in case of BTI stub reuse 16768 BTI stub parameters were recomputed even if those were already set up. 16769 This is unnecessary work and leaks the symbol name that is allocated 16770 for the stub. 16771 167722023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16773 16774 bfd: aarch64: Fix broken BTI stub PR30930 16775 Input sections are grouped together that can use the same stub area 16776 (within reach) and these groups have a stable id. 16777 16778 Stubs have a name generated from the stub group id and target symbol. 16779 When a relocation requires a stub with a name that already exists, the 16780 stub is reused instead of adding a new one. 16781 16782 For an indirect branch stub another BTI stub may be inserted near the 16783 target to provide a BTI landing pad. 16784 16785 The BTI stub can end up with the same stub group id and thus the same 16786 name as the indirect stub. This happens if the target symbol is within 16787 reach of the indirect branch stub. Then, due to the name collision, 16788 only a single stub was emmitted which branched to itself causing an 16789 infinite loop at runtime. 16790 16791 A possible solution is to just name the BTI stubs differently, but 16792 since in the problematic case the indirect and BTI stub are in the 16793 same stub area, a better solution is to emit a single stub with a 16794 direct branch. The stub is still needed since the caller cannot reach 16795 the target directly and we also want a BTI landing pad in the stub in 16796 case other indirect stubs target the same symbol and thus need a BTI 16797 stub. 16798 16799 In short we convert an indirect branch stub into a BTI stub when the 16800 target is within reach and has no BTI. It is a hassle to change the 16801 symbol of the stub so a BTI stub may end up with *_veneer instead of 16802 *_bti_veneer after the conversion, but this should not matter much. 16803 (Refactoring some of _bfd_aarch64_add_call_stub_entries would be 16804 useful but too much for this bug fix patch.) 16805 16806 The same conversion to direct branch could be done even if the target 16807 did not need a BTI. The stub groups are fixed in the current logic so 16808 linking can fail if too many stubs are inserted and the section layout 16809 is changed too much, but this only happens in extreme cases that can 16810 be reasonably ignored. Because of this the target cannot go out of 16811 reach during stub insertion so the optimization is valid, but not 16812 implemented by this patch for the non-BTI case. 16813 16814 Fixes bug 30930. 16815 168162023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com> 16817 16818 bfd: aarch64: Fix BTI stub optimization PR30957 16819 The instruction was looked up in the wrong input file (file of branch 16820 source instead of branch target) when optimizing away BTI stubs in 16821 16822 commit 5834f36d93cabf1a8bcc7dd7654141aed3d296bc 16823 bfd: aarch64: Optimize BTI stubs PR30076 16824 16825 This can cause adding BTI stubs when they are not necessary or removing 16826 them when they are (the latter is a correctness issue but it is very 16827 unlikely in practice). 16828 16829 Fixes bug 30957. 16830 168312023-11-09 Victor Do Nascimento <victor.donascimento@arm.com> 16832 16833 aarch64: Fix error in THE system register checking 16834 The erroneous omission of a "reg_value == " in the THE system register 16835 encoding check added in [1] led to an error which was not picked up in 16836 GCC but which was flagged in Clang due to its use of 16837 [-Werror,-Wconstant-logical-operand] check. Together with this fix we 16838 add a new test for the THE registers to pick up their illegal use, 16839 adding an extra and important layer of validation. 16840 16841 Furthermore, in separating system register from instruction 16842 implementation (with which only the former was of concern in the cited 16843 patch), additions made to `aarch64-tbl.h' are rolled back so 16844 that these can be added later when adding THE instructions to the 16845 codebase, a more natural place for these changes. 16846 16847 [1] https://sourceware.org/pipermail/binutils/2023-November/130314.html 16848 16849 opcodes/ChangeLog: 16850 16851 * aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo. 16852 * aarch64-tbl.h (THE): Remove. 16853 (aarch64_feature_set aarch64_feature_the): Likewise. 16854 16855 gas/ChangeLog: 16856 16857 * testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE 16858 system registers. 16859 * testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise. 16860 168612023-11-09 Jan Beulich <jbeulich@suse.com> 16862 16863 x86: rework UWRMSR operand swapping 16864 As indicated during review already, doing the swapping early is overall 16865 cheaper than doing it only after operand matching. 16866 168672023-11-09 Jan Beulich <jbeulich@suse.com> 16868 16869 x86: do away with is_evex_encoding() 16870 As we have grown more uses of it, it becomes increasingly more desirable 16871 to replace it by a simpler check. Have i386-gen do at build time what so 16872 far was done at runtime: Deal with templates indicating EVEX-encoding by 16873 other than the EVex attribute, and set that to "dynamic" in such cases. 16874 16875 This then allows simplifying a number of other conditionals as well. 16876 168772023-11-09 Jan Beulich <jbeulich@suse.com> 16878 16879 x86: split insn templates' CPU field 16880 Right now the opcode table has entries with ISA restrictions of the form 16881 FEAT1|FEAT2, the meaning of which depends on context and requires 16882 special treatment in tc-i386.c: Sometimes this means "both features 16883 requires", whereas originally it was intended to solely mean "all of 16884 these features required". Split the field, with the original one 16885 regaining its original meaning. The new field now truly means "any of 16886 these". The combination of both fields is still and &&-type check, i.e. 16887 (all of these) && (any of these). In the opcode table more involved 16888 combinations of features then also need expressing this way: "all" 16889 entities first, follow by "any" entities enclosed in parentheses, e.g. 16890 x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be 16891 added around the "any" part (unless parsing logic was further relaxed). 16892 16893 Note that this way AVX512VL no longer needs as much special treatment, 16894 and hence templates previously using AVX512F|AVX512VL are switched to 16895 just AVX512VL. 16896 16897 Note further that this requires FMA handling as resulting from 16898 da0784f961d8 ("x86: fold FMA VEX and EVEX templates") to be slightly 16899 re-done: FMA now becomes more similar to AVX and AVX2. 16900 169012023-11-09 Jan Beulich <jbeulich@suse.com> 16902 16903 x86: Cpu64 handling improvements 16904 First of all we want to also accumulate its reverse dependencies, such 16905 that we can use them in cpu_flags_match(). This is in particular in 16906 preparation of APX additions, such that e.g. BMI VEX-encoding templates 16907 can become combined VEX/EVEX ones. 16908 16909 Once we have the reverse dependencies, we can further leverage them to 16910 omit explicit "&x64" from any insn templates dealing with 64-bit-mode- 16911 only ISA extensions. Besides helping readability for several insn 16912 templates we already have, this will also help with what is going to be 16913 added for APX (as all of the new templates would otherwise need to have 16914 "&x64"). 16915 16916 Note that rather than leaving a meaningless CPU_64_FLAGS (which is 16917 unused anyway), its emitting is now also suppressed. 16918 169192023-11-09 Jan Beulich <jbeulich@suse.com> 16920 16921 x86: Intel Core processors do not support CMPXCHG16B 16922 This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot 16923 possibly be supported by CPUs not supporting 64-bit mode. 16924 169252023-11-09 GDB Administrator <gdbadmin@sourceware.org> 16926 16927 Automatic date update in version.in 16928 169292023-11-08 Carl Love <cel@linux.ibm.com> 16930 16931 rs6000, Fix test gdb.base/store.exp 16932 The test currently fails for IEEE 128-bit floating point types. PowerPC 16933 supports the IBM double 128-bit floating point format and IEEE 128-bit 16934 format. The IBM double 128-bit floating point format uses two 64-bit 16935 floating point registers to store the 128-bit value. The IEEE 128-bit 16936 floating point format stores the value in a single 128-bit vector-scalar 16937 register (vsr). 16938 16939 The various floating point values, 32-bit float, 64-bit double, IBM double 16940 128-bit float and IEEE 128-bit floating point numbers are all mapped to the 16941 DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are 16942 actually stored in a vsr not the fprs. This patch changes the register 16943 mapping for the vsrs from the fpr to the vsr registers so the value is 16944 properly accessed by GDB. The functions rs6000_linux_register_to_value, 16945 rs6000_linux_value_to_register, rs6000_linux_value_from_register check if 16946 the value is an IEEE 128-bit floating point value and adjust the register 16947 number as needed. The test in function rs6000_convert_register_p is fixed 16948 so it is only true for floating point values. 16949 16950 This patch fixes three regression tests in gdb.base/store.exp. 16951 16952 The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE 16953 with no regressions. 16954 169552023-11-08 Carl Love <cel@us.ibm.com> 16956 16957 rs6000, Fix Linux DWARF register mapping 16958 Overview of issues fixed by the patch. 16959 16960 The primary issue this patch fixes is the DWARF register mapping for 16961 Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping 16962 issues. The register mapping issue is responsible for two of the 16963 five regression bugs seen in gdb.base/store.exp. 16964 16965 Once the register mapping was fixed, an underlying issue with the unwinding 16966 of the signal trampoline in common-code in ifrun.c was found. This 16967 underlying bug is best described by Ulrich in the following description. 16968 16969 The unwinder bug shows up on platforms where the kernel uses a trampoline 16970 to dispatch "calls to" the signal handler (not just *returns from* the 16971 signal handler). Many platforms use a trampoline for signal return, and 16972 that is working fine, but the only platform I'm (Ulrich) aware of that 16973 uses a trampoline for signal handler calls is (recent kernels for) 16974 PowerPC. I believe the rationale for using a trampoline here 16975 is to improve performance by avoiding unbalancing of the 16976 branch predictor's call/return stack. 16977 16978 However, on PowerPC the bug is dormant as well as it is hidden 16979 by *another* bug that prevents correct unwinding out of the 16980 signal trampoline. This is because the custom CFI for the 16981 trampoline uses a register number (VSCR) that is not ever used 16982 by compiler-generated CFI, and that particular register is 16983 mapped to an invalid number by the current PowerPC DWARF mapper. 16984 16985 The underlying unwinder bug is exposed by the "new" regression failures 16986 in gdb.base/sigstep.exp. These failures were previously masked by 16987 the fact that GDB was not seeing a valid frame when it tried to unwind 16988 the frames. The sigstep.exp test is specifically testing stepping into 16989 a signal handler. With the correct DWARF register mapping in place, 16990 specifically the VSCR mapping, the signal trampoline code now unwinds to a 16991 valid frame exposing the pre-existing bug in how the signal handler on 16992 PowerPC works. The one line change infrun.c fixes the exiting bug in 16993 the common-code for platforms that use a trampoline to dispatch calls 16994 to the signal handler by not stopping in the SIGTRAMP_FRAME. 16995 16996 Detailed description of the DWARF register mapping fix. 16997 16998 The PowerPC DWARF register mapping is the same for the .eh_frame and 16999 .debug_frame on Linux. PowerPC uses different mapping for .eh_frame and 17000 .debug_frame on other operating systems. The current GDB support for 17001 mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and 17002 rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux. 17003 The files have some legacy mappings for spe_acc, spefscr, EV which was 17004 removed from GCC in 2017. 17005 17006 This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum, 17007 and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle 17008 the DWARF register mappings on Linux. Function 17009 rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum 17010 and gdbarch_stab_reg_to_regnum since the mappings are the same. 17011 17012 The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to 17013 call set_gdbarch_dwarf2_reg_to_regnum map the new function 17014 rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly, 17015 dwarf2_frame_set_adjust_regnum is called to map 17016 rs6000_linux_adjust_frame_regnum into the architecture. 17017 17018 Additional detail on the signal handling fix. 17019 17020 The specific sequence of events for handling a signal on most 17021 architectures is as follows: 17022 17023 1) Some code is running when a signal arrives. 17024 2) The kernel handles the signal and dispatches to the handler. 17025 ... 17026 17027 However on PowerPC the sequence of events is: 17028 17029 1) Some code is running when a signal arrives. 17030 2) The kernel handles the signal and dispatches to the trampoline. 17031 3) The trampoline performs a normal function call to the handler. 17032 ... 17033 17034 We want the "nexti" to step into, not over, signal handlers invoked by 17035 the kernel. This is the case for most platforms as the kernel puts a 17036 signal trampoline frame onto the stack to handle proper return after the 17037 handler. However, on some platforms such as PowerPC, the kernel actually 17038 uses a trampoline to handle *invocation* of the handler. We do not 17039 want GDB to stop in the SIGTRAMP_FRAME. The issue is fixed in function 17040 process_event_stop_test by adding a check that the frame is not a 17041 SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This 17042 prevents GDB from erroneously detecting the trampoline invocation as a 17043 subroutine call. 17044 17045 This patch fixes two regression test failures in gdb.base/store.exp. 17046 17047 The patch then fixes an exposed, dormant, signal handling issue that 17048 is exposed in the signal handling test gdb.base/sigstep.exp. 17049 17050 The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with 17051 no new regressions. Note, only two of the five failures in store.exp 17052 are fixed. The remaining three failures are fixed in a following 17053 patch. 17054 170552023-11-08 Andrew Burgess <aburgess@redhat.com> 17056 17057 gdb: call update_thread_list after completing an inferior call 17058 I noticed that if GDB is using a remote or extended-remote target, 17059 then, if an inferior call caused a new thread to appear, or for an 17060 existing thread to exit, then these events are not reported to the 17061 user. 17062 17063 The problem is that for these targets GDB relies on a call to 17064 update_thread_list to learn about changes to the inferior's thread 17065 list. 17066 17067 If GDB doesn't pass through the normal stop code then GDB will not 17068 call update_thread_list, and so will not report changes in the thread 17069 list. 17070 17071 This commit adds an additional update_thread_list call, after which 17072 thread events are correctly reported. 17073 170742023-11-08 Andrew Burgess <aburgess@redhat.com> 17075 17076 gdb: call update_thread_list for $_inferior_thread_count function 17077 I noticed that sometimes the value returned by $_inferior_thread_count 17078 can become out of sync with the actual thread count of the inferior, 17079 and will disagree with the number of threads reported by 'info 17080 threads'. This commit fixes this issue. 17081 17082 The cause of the problem is that 'info threads' includes a call to 17083 update_thread_list, this can be seen in print_thread_info_1 in 17084 thread.c, while $_inferior_thread_count doesn't include a similar 17085 call, see the function inferior_thread_count_make_value also in 17086 thread.c. 17087 17088 Of course, this is only a problem when GDB is running on a target that 17089 relies on update_thread_list calls to learn about new threads, 17090 e.g. remote or extended-remote targets. Native targets generally 17091 learn about new threads as soon as they appear and will not have this 17092 problem. 17093 17094 I ran into this issue when writing a test for the next commit which 17095 uses inferior function calls to add an remove threads from an 17096 inferior. But for testing I've made use of non-stop mode and 17097 asynchronous inferior execution; by reading the inferior state I can 17098 know when a new thread has been created, at which point I can print 17099 $_inferior_thread_count while the inferior is still running. This is 17100 important, if I stop the inferior then GDB will pass through an 17101 update_thread_list call in the normal stop code, which will 17102 synchronise the thread list, after which $_inferior_thread_count will 17103 report the correct value. 17104 17105 With this change in place $_inferior_thread_count is now correct. 17106 171072023-11-08 Andrew Burgess <aburgess@redhat.com> 17108 17109 gdb: add a custom command completer for disassemble command 17110 Add a new command completer function for the disassemble command. 17111 There are two things that this completion function changes. First, 17112 after the previous commit, the new function calls skip_over_slash_fmt, 17113 which means that hitting tab after entering a /OPT flag now inserts a 17114 space ready to start typing the address to disassemble at: 17115 17116 (gdb) disassemble /r<TAB> 17117 (gdb) disassemble /r <CURSOR> 17118 17119 But also, we now get symbol completion after a /OPT option set, 17120 previously this would do nothing: 17121 17122 (gdb) disassemble /r mai<TAB> 17123 17124 But now: 17125 17126 (gdb) disassemble /r mai<TAB> 17127 (gdb) disassemble /r main <CURSOR> 17128 17129 Which was my main motivation for working on this commit. 17130 17131 However, I have made a second change in the completion function. 17132 Currently, the disassemble command calls the generic 17133 location_completer function, however, the disassemble docs say: 17134 17135 Note that the 'disassemble' command's address arguments are specified 17136 using expressions in your programming language (*note Expressions: 17137 Expressions.), not location specs (*note Location Specifications::). 17138 So, for example, if you want to disassemble function 'bar' in file 17139 'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble 17140 foo.c:bar'. 17141 17142 And indeed, if I try: 17143 17144 (gdb) disassemble hello.c:main 17145 No symbol "hello" in current context. 17146 (gdb) disassemble hello.c::main 17147 No symbol "hello" in current context. 17148 (gdb) disassemble 'hello.c'::main 17149 Dump of assembler code for function main: 17150 ... snip ... 17151 17152 But, if I do this: 17153 17154 (gdb) disassemble hell<TAB> 17155 (gdb) disassemble hello.c:<CURSOR> 17156 17157 which is a consequence of using the location_completer function. So 17158 in this commit, after calling skip_over_slash_fmt, I forward the bulk 17159 of the disassemble command completion to expression_completer. Now 17160 when I try this: 17161 17162 (gdb) disassemble hell<TAB> 17163 17164 gives nothing, which I think is an improvement. There is one slight 17165 disappointment, if I do: 17166 17167 (gdb) disassemble 'hell<TAB> 17168 17169 I still get nothing. I had hoped that this would expand to: 17170 'hello.c':: but I guess this is a limitation of the current 17171 expression_completer implementation, however, I don't think this is a 17172 regression, the previous expansion was just wrong. Fixing 17173 expression_completer is out of scope for this commit. 17174 17175 I've added some disassembler command completion tests, and also a test 17176 that disassembling using 'FILE'::FUNC syntax works, as I don't think 17177 that is tested anywhere. 17178 171792023-11-08 Andrew Burgess <aburgess@redhat.com> 17180 17181 gdb: make skip_over_slash_fmt available outside printcmd.c 17182 Move the function skip_over_slash_fmt into completer.c, and make it 17183 extern, with a declaration in completer.h. 17184 17185 This is a refactor in order to support the next commit. I've not 17186 changed any of the code in skip_over_slash_fmt. 17187 17188 There should be no user visible changes after this commit. 17189 171902023-11-08 Andrew Burgess <aburgess@redhat.com> 17191 17192 gdb: error if /r and /b are used with disassemble command 17193 The disassembler gained a new /b flag in this commit: 17194 17195 commit d4ce49b7ac077a9882d6a5e689e260300045ca88 17196 Date: Tue Jun 21 20:23:35 2022 +0100 17197 17198 gdb: disassembler opcode display formatting 17199 17200 The /b and /r flags result in the instruction opcodes displayed in 17201 different formats, so it's not possible to have both at the same 17202 time. Currently the /b flag overrides the /r flag. 17203 17204 We have a similar situation with the /m and /s flags, but here, if the 17205 user tries to use both flags then they will get an error. 17206 17207 I think the error is clearer, so in this commit I propose that we add 17208 an error if /r and /b are both used. 17209 17210 Obviously this change breaks backwards compatibility. I don't have a 17211 compelling argument for why we should make the change beyond my 17212 feeling that it was a mistake not to add this error from the start, 17213 and that the new behaviour is better. 17214 17215 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 17216 172172023-11-08 Jan Beulich <jbeulich@suse.com> 17218 17219 gas: S_GET_{NAME,SEGMENT}() don't alter their input symbol 17220 Make their parameters pointer-to-const, thus allowing callers to also be 17221 const-correct where possible. 17222 172232023-11-08 Clément Chigot <chigot@adacore.com> 17224 17225 ld: print branch fixups into the map file for ppc elf targets 17226 In a safety context, it could interesting to track the trampolines being 17227 generated, ensuring there are expected or not. 17228 17229 bfd/ChangeLog: 17230 17231 * elf32-ppc.c (ppc_elf_relax_section): Log branch fixups. 17232 17233 ld/ChangeLog: 17234 17235 * ld.texi (--print-map): Add new item about fixups. 17236 172372023-11-08 Tom Tromey <tom@tromey.com> 17238 17239 Add minimal thread-safety to BFD 17240 This patch provides some minimal thread-safety to BFD. 17241 17242 The BFD client can request thread-safety by providing a lock and 17243 unlock function. The globals used during BFD creation (e.g., 17244 bfd_id_counter) are then locked, and the file descriptor cache is also 17245 locked. A function to clean up any thread-local data is now provided 17246 for BFD clients. 17247 17248 * bfd-in2.h: Regenerate. 17249 * bfd.c (lock_fn, unlock_fn): New globals. 17250 (bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New 17251 functions. 17252 * cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked. 17253 (cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock 17254 and unlock. 17255 (cache_bclose): Add comment. 17256 (cache_bflush, cache_bstat, cache_bmmap): Lock and unlock. 17257 (_bfd_cache_init_unlocked): New function. 17258 (bfd_cache_init): Use it. Lock and unlock. 17259 (_bfd_cache_close_unlocked): New function. 17260 (bfd_cache_close, bfd_cache_close_all): Use it. Lock and unlock. 17261 (_bfd_open_file_unlocked): New function. 17262 (bfd_open_file): Use it. Lock and unlock. 17263 * doc/bfd.texi (BFD front end): Add Threading menu item. 17264 * libbfd.h: Regenerate. 17265 * opncls.c (_bfd_new_bfd): Lock and unlock. 17266 * po/bfd.pot: Regenerate. 17267 172682023-11-08 Tom Tromey <tom@tromey.com> 17269 17270 Make various error-related globals thread-local 17271 This changes bfd_error et al to be thread-local. 17272 17273 * Makefile.in: Regenerate. 17274 * aclocal.m4: Include ax_tls.m4. 17275 * ax_tls.m4: New file. 17276 * bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf): 17277 Now thread-local. 17278 (bfd_asprintf): Update docs. 17279 * config.in, configure: Regenerate. 17280 * configure.ac: Call AX_TLS. 17281 * po/bfd.pot: Regenerate. 17282 172832023-11-08 Tom Tromey <tom@tromey.com> 17284 17285 Make _bfd_error_buf static 17286 This makes _bfd_error_buf static and adds a way to clear it. I felt 17287 that this made the subsequent patches a little cleaner. 17288 17289 * bfd.c (_bfd_error_buf): Now static. 17290 (bfd_set_input_error): Use _bfd_clear_error_data. 17291 (_bfd_clear_error_data): New function. 17292 (bfd_init): Use _bfd_clear_error_data. 17293 * libbfd.h: Regenerate. 17294 * opncls.c (bfd_close_all_done): Use _bfd_clear_error_data. 17295 * po/bfd.pot: Regenerate. 17296 172972023-11-08 GDB Administrator <gdbadmin@sourceware.org> 17298 17299 Automatic date update in version.in 17300 173012023-11-07 Victor Do Nascimento <victor.donascimento@arm.com> 17302 17303 aarch64: Add LSE128 instructions 17304 Implement, together with the necessary tests, the following new LSE128 17305 atomic instructions: 17306 17307 * Atomic bit clear on quadword in memory (ldclrp{a|l|al}); 17308 * Atomic bit set on quadword in memory (ldsetp{a|l|al}); 17309 * Swap quadword in memory (swpp{a|l|al}); 17310 17311 gas/ChangeLog: 17312 17313 * testsuite/gas/aarch64/lse128-atomic.d: New. 17314 * testsuite/gas/aarch64/lse128-atomic.s: Likewise. 17315 17316 opcodes/ChangeLog: 17317 17318 * aarch64-tbl.h (ldclrp): new _LSE128_INSN entry. 17319 (ldclrpa): Likewise. 17320 (ldclrpal): Likewise. 17321 (ldclrpl): Likewise. 17322 (ldsetp): Likewise. 17323 (ldsetpa): Likewise. 17324 (ldsetpal): Likewise. 17325 (ldsetpl): Likewise. 17326 (swpp): Likewise. 17327 (swppa): Likewise. 17328 (swppal): Likewise. 17329 (swppl): Likewise. 17330 * aarch64-asm-2.c: Regenerate. 17331 * aarch64-dis-2.c: Likewise. 17332 * aarch64-opc-2.c: Likewise. 17333 173342023-11-07 Victor Do Nascimento <victor.donascimento@arm.com> 17335 17336 aarch64: Add arch support for LSE128 extension 17337 Enable the `+lse128' feature modifier which, together with new 17338 internal feature flags, enables LSE128 instructions, which are 17339 represented via the new `_LSE128_INSN' macro. 17340 17341 gas/ChangeLog: 17342 17343 * config/tc-aarch64.c (aarch64_features): Add new "lse128" 17344 entry. 17345 17346 include/ChangeLog: 17347 17348 * include/opcode/aarch64.h (enum aarch64_feature_bit): New 17349 AARCH64_FEATURE_LSE128 feature bit. 17350 (enum aarch64_insn_class): New lse128_atomic instruction class. 17351 17352 opcodes/ChangeLog: 17353 17354 * opcodes/aarch64-tbl.h (aarch64_feature_lse128): New. 17355 (LSE128): Likewise. 17356 (_LSE128_INSN): Likewise. 17357 173582023-11-07 Victor Do Nascimento <victor.donascimento@arm.com> 17359 17360 aarch64: Add LSE128 instruction operand support 17361 Given the particular encoding of the LSE128 instructions, create the 17362 necessary shared input+output operand register description and 17363 handling in the code to allow for the encoding of the LSE128 128-bit 17364 atomic operations. 17365 17366 gas/ChangeLog: 17367 17368 * config/tc-aarch64.c (parse_operands): 17369 17370 include/ChangeLog: 17371 17372 * opcode/aarch64.h (enum aarch64_opnd): 17373 17374 opcodes/ChangeLog: 17375 17376 * aarch64-opc.c (fields): 17377 (aarch64_print_operand): 17378 * aarch64-opc.h (enum aarch64_field_kind): 17379 * aarch64-tbl.h (AARCH64_OPERANDS): 17380 173812023-11-07 Victor Do Nascimento <victor.donascimento@arm.com> 17382 17383 aarch64: Add 128-bit system register flags 17384 In preparation for the implementation of 128-bit system register 17385 support across the toolchain, this patch adds the feature flag 17386 F_REG_128 and adds it to relevant system registers in 17387 `aarch64-sys-regs.def'. 17388 17389 Given the shared nature of this file, this change is made necessary 17390 initially to implement argument validation in the `__arm_rsr128' and 17391 `__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in 17392 the binutils implementation of the corresponding `mrrs' and `msrr' 17393 instructions. 17394 17395 Regression tested on aarch64-linux-gnu, no regressions. 17396 17397 opcodes/ChangeLog: 17398 17399 * aarch64-opc.h (F_REG_128): New flag. 17400 * aarch64-sys-regs.def (par_el1): Add F_REG_128 flag. 17401 (rcwmask_el1): Likewise. 17402 (rcwsmask_el1): Likewise. 17403 (ttbr0_el1): Likewise. 17404 (ttbr0_el12): Likewise. 17405 (ttbr0_el2): Likewise. 17406 (ttbr1_el1): Likewise. 17407 (ttbr1_el12): Likewise. 17408 (ttbr1_el2): Likewise. 17409 (vttbr_el2): Likewise. 17410 174112023-11-07 Victor Do Nascimento <victor.donascimento@arm.com> 17412 17413 aarch64: Add THE system register support 17414 Add Binutils support for system registers associated with the 17415 Translation Hardening Extension (THE). 17416 17417 In doing so, we also add core feature support for THE, enabling its 17418 associated feature flag and implementing the necessary 17419 feature-checking machinery. 17420 17421 Regression tested on aarch64-linux-gnu, no regressions. 17422 17423 gas/ChangeLog: 17424 17425 * config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier. 17426 * doc/c-aarch64.texi (AArch64 Extensions): Update 17427 documentation for `the' option. 17428 * testsuite/gas/aarch64/sysreg-8.s: Add tests for `the' 17429 associated system registers. 17430 * testsuite/gas/aarch64/sysreg-8.d: Likewise. 17431 17432 include/ChangeLog: 17433 17434 * opcode/aarch64.h (enum aarch64_feature_bit): Add 17435 AARCH64_FEATURE_THE. 17436 17437 opcode/ChangeLog: 17438 17439 * aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the' 17440 system register check support. 17441 * aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1' 17442 * aarch64-tbl.h: Define `THE' preprocessor macro. 17443 174442023-11-07 Simon Marchi <simon.marchi@efficios.com> 17445 17446 gdb/arm: remove thumb bit in arm_adjust_breakpoint_address 17447 When compiling gdb with -fsanitize=address on ARM, I get a crash in test 17448 gdb.arch/arm-disp-step.exp, reproduced easily with: 17449 17450 $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" 17451 Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... 17452 ================================================================= 17453 ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494 17454 17455 Since it doesn't require running the program, it can be reproduced locally on a 17456 dev machine other than ARM, after acquiring the test binary. 17457 17458 The length of the allocate buffer `buf` is 1, and we try to extract an 17459 integer of size 2 from it. The length of 1 comes from the subtraction 17460 `bpaddr - boundary`. Normally, on ARM, all instructions are aligned on 17461 a multiple of 2, so it's weird for this subtraction to result in 1. In 17462 this case, boundary comes from the result of find_pc_partial_function 17463 returning 0x549: 17464 17465 (gdb) p/x bpaddr 17466 $2 = 0x54a 17467 (gdb) p/x boundary 17468 $3 = 0x549 17469 (gdb) p/x bpaddr - boundary 17470 $4 = 0x1 17471 17472 0x549 is the address of the test_call_subr label, 0x548, with the thumb 17473 bit enabled. Before doing some math with the address, I think we need 17474 to strip the thumb bit, like is done elsewhere (for instance for bpaddr 17475 earlier in the same function). 17476 17477 I wonder if find_pc_partial_function should do that itself, in order to 17478 return an address that is suitable for arithmetic. In any case, that 17479 would be a change with a broad impact, so for now just fix the issue 17480 locally. 17481 17482 After the patch: 17483 17484 $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" 17485 Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... 17486 Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103. 17487 17488 Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288 17489 Approved-By: Luis Machado <luis.machado@arm.com> 17490 174912023-11-07 Jan Beulich <jbeulich@suse.com> 17492 17493 ld/x86: reduce testsuite dependency on system object files 17494 PR ld/30722 17495 Tests looking for certain .note-section recorded properties may not 17496 involve object files from the underlying platform (e.g. via using the C 17497 compiler for linking): Such object files may themselves have similar 17498 note sections, and hence they may influence the overall outcome. 17499 17500 For now convert just the tests known to be affected by crt*.o coming 17501 with "ISA v3 needed" notes. Eventually other tests ought to be 17502 converted, too. 17503 175042023-11-07 Jan Beulich <jbeulich@suse.com> 17505 17506 Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA" 17507 This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1. 17508 It wrongly altered testcase expectations; the issue will need 17509 taking care of differently. 17510 175112023-11-07 Mary Bennett <mary.bennett@embecosm.com> 17512 17513 RISC-V: Add support for XCValu extension in CV32E40P 17514 Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html 17515 17516 Contributors: 17517 Mary Bennett <mary.bennett@embecosm.com> 17518 Nandni Jamnadas <nandni.jamnadas@embecosm.com> 17519 Pietra Ferreira <pietra.ferreira@embecosm.com> 17520 Charlie Keaney 17521 Jessica Mills 17522 Craig Blackmore <craig.blackmore@embecosm.com> 17523 Simon Cook <simon.cook@embecosm.com> 17524 Jeremy Bennett <jeremy.bennett@embecosm.com> 17525 Helene Chelin <helene.chelin@embecosm.com> 17526 17527 bfd/ChangeLog: 17528 17529 * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu` 17530 instruction class. 17531 (riscv_multi_subset_supports_ext): Likewise. 17532 17533 gas/ChangeLog: 17534 17535 * config/tc-riscv.c (validate_riscv_insn): Added the necessary 17536 operands for the extension. 17537 (riscv_ip): Likewise. 17538 * doc/c-riscv.texi: Noted XCValu as an additional ISA extension 17539 for CORE-V. 17540 * testsuite/gas/riscv/cv-alu-boundaries.d: New test. 17541 * testsuite/gas/riscv/cv-alu-boundaries.l: New test. 17542 * testsuite/gas/riscv/cv-alu-boundaries.s: New test. 17543 * testsuite/gas/riscv/cv-alu-fail-march.d: New test. 17544 * testsuite/gas/riscv/cv-alu-fail-march.l: New test. 17545 * testsuite/gas/riscv/cv-alu-fail-march.s: New test. 17546 * testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test. 17547 * testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test. 17548 * testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test. 17549 * testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test. 17550 * testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test. 17551 * testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test. 17552 * testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test. 17553 * testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test. 17554 * testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test. 17555 * testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test. 17556 * testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test. 17557 * testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test. 17558 * testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test. 17559 * testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test. 17560 * testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test. 17561 * testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test. 17562 * testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test. 17563 * testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test. 17564 * testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test. 17565 * testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test. 17566 * testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test. 17567 * testsuite/gas/riscv/cv-alu-insns.d: New test. 17568 * testsuite/gas/riscv/cv-alu-insns.s: New test. 17569 17570 opcodes/ChangeLog: 17571 17572 * riscv-dis.c (print_insn_args): Disassemble xcb operand. 17573 * riscv-opc.c: Defined the MASK and added XCValu instructions. 17574 17575 include/ChangeLog: 17576 17577 * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros 17578 for XCValu. 17579 * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros 17580 for XCValu. 17581 (enum riscv_insn_class): Added the XCValu instruction class. 17582 175832023-11-07 Mary Bennett <mary.bennett@embecosm.com> 17584 17585 RISC-V: Add support for XCVmac extension in CV32E40P 17586 Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html 17587 17588 Contributors: 17589 Mary Bennett <mary.bennett@embecosm.com> 17590 Nandni Jamnadas <nandni.jamnadas@embecosm.com> 17591 Pietra Ferreira <pietra.ferreira@embecosm.com> 17592 Charlie Keaney 17593 Jessica Mills 17594 Craig Blackmore <craig.blackmore@embecosm.com> 17595 Simon Cook <simon.cook@embecosm.com> 17596 Jeremy Bennett <jeremy.bennett@embecosm.com> 17597 Helene Chelin <helene.chelin@embecosm.com> 17598 17599 bfd/ChangeLog: 17600 17601 * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac` 17602 instruction class. 17603 (riscv_multi_subset_supports_ext): Likewise. 17604 17605 gas/ChangeLog: 17606 17607 * config/tc-riscv.c (validate_riscv_insn): Added the necessary 17608 operands for the extension. 17609 (riscv_ip): Likewise. 17610 * doc/c-riscv.texi: Noted XCVmac as an additional ISA extension 17611 for CORE-V. 17612 * testsuite/gas/riscv/cv-mac-fail-march.d: New test. 17613 * testsuite/gas/riscv/cv-mac-fail-march.l: New test. 17614 * testsuite/gas/riscv/cv-mac-fail-march.s: New test. 17615 * testsuite/gas/riscv/cv-mac-fail-operand.d: New test. 17616 * testsuite/gas/riscv/cv-mac-fail-operand.l: New test. 17617 * testsuite/gas/riscv/cv-mac-fail-operand.s: New test. 17618 * testsuite/gas/riscv/cv-mac-insns.d: New test. 17619 * testsuite/gas/riscv/cv-mac-insns.s: New test. 17620 17621 opcodes/ChangeLog: 17622 17623 * riscv-dis.c (print_insn_args): Disassemble information with 17624 the EXTRACT macro implemented. 17625 * riscv-opc.c: Defined the MASK and added 17626 XCVmac instructions. 17627 17628 include/ChangeLog: 17629 17630 * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros 17631 for XCVmac. 17632 * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros 17633 for uimm. 17634 (enum riscv_insn_class): Added the XCVmac instruction class. 17635 176362023-11-07 Tom Tromey <tom@tromey.com> 17637 17638 Remove EXTERN_C and related defines 17639 common-defs.h has a few defines that I suspect were used during the 17640 transition to C++. These aren't needed any more, so remove them. 17641 17642 Tested by rebuilding. 17643 17644 Approved-By: Simon Marchi <simon.marchi@efficios.com> 17645 Approved-By: Andrew Burgess <aburgess@redhat.com> 17646 176472023-11-07 GDB Administrator <gdbadmin@sourceware.org> 17648 17649 Automatic date update in version.in 17650 176512023-11-06 Carl Love <cel@linux.ibm.com> 17652 17653 gdb: Update email address for Carl Love in gdb/MAINTAINERS 17654 176552023-11-06 Hannes Domani <ssbssa@yahoo.de> 17656 17657 Fix resizing of TUI python windows 17658 When resizing from a big to small terminal size, and you have a 17659 TUI python window that would then be outside of the new size, 17660 valgrind shows this error: 17661 17662 ==3389== Invalid read of size 1 17663 ==3389== at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167) 17664 ==3389== by 0xC3E3C9: wrefresh (lib_refresh.c:63) 17665 ==3389== by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134) 17666 ==3389== by 0x98921C: tui_py_window::rerender() (py-tui.c:183) 17667 ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030) 17668 ==3389== by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033) 17669 ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030) 17670 ==3389== by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81) 17671 ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525) 17672 ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562) 17673 ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234) 17674 ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199) 17675 ==3389== Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd 17676 ==3389== at 0x4A0A430: free (vg_replace_malloc.c:446) 17677 ==3389== by 0xC3CF7D: _nc_freewin (lib_newwin.c:121) 17678 ==3389== by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78) 17679 ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525) 17680 ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562) 17681 ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234) 17682 ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199) 17683 ==3389== by 0x8E40E9: captured_command_loop() (main.c:407) 17684 ==3389== by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324) 17685 ==3389== by 0x62AC04: main (gdb.c:39) 17686 17687 It's because tui_py_window::m_inner_window still has the outside 17688 coordinates, and wnoutrefresh then does an out-of-bounds access. 17689 17690 Fix this by resetting m_inner_window on every resize, it will anyways 17691 be recreated in the next rerender call. 17692 17693 Approved-By: Andrew Burgess <aburgess@redhat.com> 17694 176952023-11-06 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 17696 17697 Change gdb.base/examine-backwards.exp for AIX. 17698 In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump 17699 an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating 17700 it cannot access memory. 17701 17702 This patch is a small change to get it working in AIX as well. 17703 177042023-11-06 Nick Clifton <nickc@redhat.com> 17705 17706 ld: =fillexp different behaviors for hexidecimal literal 17707 PR 30865 17708 * ld.texi: Update description of the FILL command. 17709 * testsuite/ld-scripts/fill2.d: New test. 17710 * testsuite/ld-scripts/fill2.t: New test source. 17711 * testsuite/ld-scripts/data.exp: Run the new test. 17712 177132023-11-06 Nelson Chu <nelson@rivosinc.com> 17714 17715 RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase. 17716 Same as commit 4352c0ac04a. 17717 17718 gas/ 17719 * testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2. 17720 177212023-11-06 Nelson Chu <nelson@rivosinc.com> 17722 Tsukasa OI <research_trasio@irq.a4lg.com> 17723 17724 RISC-V: Moved out linker internal relocations after R_RISCV_max. 17725 Just the lightest modifications about this, without any further checks and 17726 considering --emit-relocs. We will need to improve it in the future, but 17727 first do this to avoid conflicts between linker internal relocations and the 17728 new definition of psabi. For example, TLSDESC relocs. 17729 17730 Passed riscv-gnu-toolchain regressions, so should be safe enough to commit. 17731 17732 17733 bfd/ 17734 * reloc.c: Removed linker internal relocations. 17735 * bfd-in2.h: Regenerated. 17736 * libbfd.h: Regenerated. 17737 * elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h. 17738 * elfxx-riscv.c (howto_table, howto_table_internal): Moved linker 17739 internal relocations from howto_table into howto_table_internal. 17740 (riscv_reloc_map): Removed linker internal relocations mapping. 17741 (riscv_elf_rtype_to_howto): Return howto of linker internal 17742 relocations from howto_table_internal. 17743 include/ 17744 * elf/riscv.h: Defined linker internal relocations after R_RISCV_max. 17745 177462023-11-06 Tom de Vries <tdevries@suse.de> 17747 17748 [gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.exp 17749 Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp: 17750 - passes when gdb is configured using $(cd ../src; pwd)/configure, but 17751 - fails when using ../src/configure. 17752 17753 Fix this by making the matching more precise: 17754 ... 17755 - -re -wrap "$objdir.*" { 17756 + -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" { 17757 ... 17758 such that we only fail on the line: 17759 ... 17760 [symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \ 17761 /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M 17762 ... 17763 17764 Reported-By: Carl Love <cel@us.ibm.com> 17765 177662023-11-06 GDB Administrator <gdbadmin@sourceware.org> 17767 17768 Automatic date update in version.in 17769 177702023-11-05 Tom Tromey <tom@tromey.com> 17771 17772 Pre-read DWZ file in DWARF reader 17773 While working on background reading of DWARF, I came across the 17774 DWZ-reading code. This code can query the user (via the debuginfod 17775 support) -- something that cannot be done off the main thread. 17776 17777 Looking into it, I realized that this code can be run much earlier, 17778 avoiding this problem. Digging a bit deeper, I also found a 17779 discrepancy here between how the DWARF reader works in "readnow" mode 17780 as compared to the normal modes. 17781 17782 This patch cleans this up by trying to read the DWZ file earlier, and 17783 also by having the DWARF reader convert any exception here into a 17784 warning. This unifies the various cases, but also makes it so that 17785 errors do not prevent gdb from continuing on to the extent possible. 17786 17787 Regression tested on x86-64 Fedora 38. 17788 177892023-11-05 GDB Administrator <gdbadmin@sourceware.org> 17790 17791 Automatic date update in version.in 17792 177932023-11-04 GDB Administrator <gdbadmin@sourceware.org> 17794 17795 Automatic date update in version.in 17796 177972023-11-03 Tom Tromey <tromey@adacore.com> 17798 17799 Remove unused declaration 17800 I found a declaration in py-stopevent.h for which there is no 17801 definition. This patch removes it. 17802 178032023-11-03 Simon Marchi <simon.marchi@efficios.com> 17804 17805 gdbsupport: mark array_view::slice with [[nodiscard]] 17806 I (almost) had a bug where I did: 17807 17808 buffer.slice (...) 17809 17810 but I meant: 17811 17812 buffer = buffer.slice (...) 17813 17814 The first one does nothing, it creates a new array_view but without 17815 using it, it's useless. Mark the slice methods with [[nodiscard]] 17816 (which is standard C++17) so that error would generate a warning. 17817 17818 I guess that many functions could be marked as nodiscard, essentially 17819 function that is pure (doesn't have side-effects). But this one seems 17820 particularly easy to mis-use. 17821 17822 Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb 17823 Approved-By: Tom Tromey <tom@tromey.com> 17824 178252023-11-03 Simon Marchi <simon.marchi@efficios.com> 17826 17827 gdbsupport: record and print failed selftest names 17828 Since "maint selftest" now runs quite a lot of tests (especially in an 17829 all-targets build), I thought it would be useful to print a summary at 17830 the end of what failed. So, implement that. 17831 17832 Print the summary before the "Ran %d unit tests, %zu failed\n" line, so 17833 that that one remains the last line, and the gdb.gdb/unittest.exp 17834 doesn't need to be changed. 17835 17836 The output looks like (if I force a failure in a test): 17837 17838 (gdb) maint selftest 17839 ... 17840 Running selftest value_copy. 17841 Running selftest xml_escape_text. 17842 Running selftest xml_escape_text_append. 17843 17844 Failures: 17845 aarch64-analyze-prologue 17846 17847 Ran 4134 unit tests, 1 failed 17848 (gdb) 17849 17850 Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e 17851 Approved-By: Tom Tromey <tom@tromey.com> 17852 178532023-11-03 Jan Beulich <jbeulich@suse.com> 17854 17855 gas: correct ignoring of C-style number suffixes 17856 First of all the respective original changes didn't deal with just 0 17857 having such a suffix - this needs additional logic outside of 17858 integer_constant(). Further bogus suffixes having more than two L-s 17859 were accepted, while valid suffixes with U following the L(s) weren't. 17860 Finally respective tests were introduced for Sparc only. 17861 17862 Reviewed-by: Neal Frager <neal.frager@amd.com> 17863 178642023-11-03 Jan Beulich <jbeulich@suse.com> 17865 17866 RISC-V: reduce redundancy in load/store macro insn handling 17867 Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and 17868 FS{H,W,D,Q} the sole difference between the handling is the insn 17869 mnemonic passed to the common handling functions. The intended mnemonic, 17870 however, can easily be retrieved. Furthermore leverags that Sx and FSx 17871 are then handled identically, too, and hence their cases can also be 17872 folded. 17873 17874 RISC-V: Lx/Sx macro insn tests 17875 Make sure these (continue to) work as intended. 17876 17877 RISC-V: add F- and D-extension testcases 17878 Make sure future changes won't regress any of this. Also cover the FLH 17879 and FSH macro insns of the Zfh extension. 17880 17881 RISC-V: make FLQ/FSQ macro-insns work 17882 When support for the Q extension was added, the libopcodes side of these 17883 macro-insns was properly covered, but no backing support in gas was 17884 added. In new testcases cover not just these, but all Q-extension insns. 17885 178862023-11-03 GDB Administrator <gdbadmin@sourceware.org> 17887 17888 Automatic date update in version.in 17889 178902023-11-02 Tom de Vries <tdevries@suse.de> 17891 17892 [gdb/tdep] Fix nr array elements in ppc64_aggregate_candidate 17893 On AlmaLinux 9.2 powerpc64le I run into: 17894 ... 17895 (gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector 17896 finish^M 17897 Run till exit from #0 pck.create_small_float_vector () at pck.adb:30^M 17898 0x00000000100022d4 in p () at p.adb:25^M 17899 25 Vector := Create_Small_Float_Vector;^M 17900 Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M 17901 (gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector 17902 ... 17903 while this is expected: 17904 ... 17905 Value returned is $3 = (4.25, 4.25)^M 17906 ... 17907 17908 The problem is here in ppc64_aggregate_candidate: 17909 ... 17910 if (!get_array_bounds (type, &low_bound, &high_bound)) 17911 return -1; 17912 count *= high_bound - low_bound 17913 ... 17914 17915 The array type (containing 2 elements) is: 17916 ... 17917 type Small_Float_Vector is array (1 .. 2) of Float; 17918 ... 17919 so we have: 17920 ... 17921 (gdb) p low_bound 17922 $1 = 1 17923 (gdb) p high_bound 17924 $2 = 2 17925 ... 17926 but we calculate the number of elements in the array using 17927 "high_bound - low_bound", which is 1. 17928 17929 Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous 17930 aggregate. 17931 17932 Fix this by calculating the number of elements in the array by using 17933 "high_bound - low_bound + 1" instead. 17934 17935 Furthermore, high_bound can (in general, though perhaps not here) also be 17936 smaller than low_bound, so to be safe take that into account as well: 17937 ... 17938 LONGEST nr_array_elements = (low_bound > high_bound 17939 ? 0 17940 : (high_bound - low_bound + 1)); 17941 count *= nr_array_elements; 17942 ... 17943 17944 Tested on powerpc64le-linux. 17945 17946 Approved-By: Ulrich Weigand <uweigand@de.ibm.com> 17947 17948 PR tdep/31015 17949 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015 17950 179512023-11-02 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 17952 17953 aarch64: Add GCS system registers. 17954 This patch adds support for 10 new AArch64 system registers 17955 (gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3, 17956 gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3), 17957 which are enabled on using Guarded Control Stack (+gcs flag) 17958 feature. 17959 17960 aarch64: Add support for GCSB DSYNC instruction. 17961 This patch adds support for Guarded control stack data synchronization 17962 instruction (GCSB DSYNC). This instruction is allocated to existing 17963 HINT space and uses the HINT number 19 and to match this an entry is 17964 added to the aarch64_hint_options array. 17965 179662023-11-02 srinath <srinath.parvathaneni@arm.com> 17967 17968 aarch64: Add support for GCS extension. 17969 This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is 17970 optional from Armv9.4-A architecture and enabled by passing +gcs option to -march 17971 (eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file. 17972 17973 Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx, 17974 gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr. 17975 179762023-11-02 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 17977 17978 aarch64: Add support for Check Feature Status Extension. 17979 This patch adds support for Check Feature Status Extension (CHK) which 17980 is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction 17981 (hint #40). 17982 179832023-11-02 srinath <srinath.parvathaneni@arm.com> 17984 17985 aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures. 17986 This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a) 17987 and Armv9.4-A architecture (-march=armv9.4-a). 17988 179892023-11-02 Nick Clifton <nickc@redhat.com> 17990 17991 ld x86_64 tests: Accept x86-64-v3 as a needed ISA 17992 * testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3. 17993 * testsuite/ld-x86-64/property-4.r: Likewise. 17994 * testsuite/ld-x86-64/property-5.r: Likewise. 17995 179962023-11-02 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 17997 17998 gprofng: remove dependency on help2man 17999 help2man is no longer used to create the gprofng man pages. 18000 18001 gprofng/ChangeLog 18002 2023-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 18003 18004 * configure.ac: Remove HELP2MAN. 18005 * Makefile.in: Rebuild. 18006 * configure: Rebuild. 18007 * doc/Makefile.in: Rebuild. 18008 * gp-display-html/Makefile.in: Rebuild. 18009 * src/Makefile.in: Rebuild. 18010 180112023-11-02 GDB Administrator <gdbadmin@sourceware.org> 18012 18013 Automatic date update in version.in 18014 180152023-11-01 Simon Marchi <simon.marchi@efficios.com> 18016 18017 gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte> 18018 Use the gdb::byte_vector typedef when possible. 18019 18020 Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a 18021 180222023-11-01 Nick Clifton <nickc@redhat.com> 18023 18024 Fix typo in recent update to the ld/NEWS file 18025 18026 ld: Support input section description keyword: REVERSE 18027 PR 27565 18028 * ldlex.l: Add REVERSE. 18029 * ldgram.y: Allow REVERSE to be used wherever a sorting command can be used. 18030 * ld.h (struct wildcard_spec): Add 'reversed' field. 18031 * ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field. 18032 * ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field. 18033 * ld.texi: Document the new feature. 18034 * NEWS: Mention the new feature. 18035 * testsuite/ld-scripts/sort-file-reversed-1.d: New test driver. 18036 * testsuite/ld-scripts/sort-file-reversed-1.t: New test source. 18037 * testsuite/ld-scripts/sort-file-reversed-2.t: New test source. 18038 * testsuite/ld-scripts/sort-file-reversed-2.d: New test driver. 18039 * testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver. 18040 * testsuite/ld-scripts/sort-sections-reversed-1.t: New test source. 18041 * testsuite/ld-scripts/sort-sections-reversed-2.t: New test source. 18042 * testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver. 18043 * testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver. 18044 * testsuite/ld-scripts/sort-sections-reversed-3.t: New test source. 18045 180462023-11-01 GDB Administrator <gdbadmin@sourceware.org> 18047 18048 Automatic date update in version.in 18049 180502023-10-31 Tom de Vries <tdevries@suse.de> 18051 18052 [gdb/symtab] Work around gas PR28629 18053 When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2 18054 ppc64le, I run into: 18055 ... 18056 FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents 18057 ... 18058 18059 The problem is that we get: 18060 ... 18061 7 [ No Assembly Available ] 18062 ... 18063 because tui_get_begin_asm_address doesn't succeed. 18064 18065 In more detail, tui_get_begin_asm_address calls: 18066 ... 18067 find_line_pc (sal.symtab, sal.line, &addr); 18068 ... 18069 with: 18070 ... 18071 (gdb) p *sal.symtab 18072 $5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0, 18073 filename = "tui-layout-asm-short-prog.S", 18074 filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S", 18075 m_language = language_asm, fullname = 0x0} 18076 (gdb) p sal.line 18077 $6 = 1 18078 ... 18079 18080 The problem is the filename_for_id which is the source file prefixed with the 18081 compilation dir rather than the source dir. 18082 18083 This is due to faulty debug info generated by gas, PR28629: 18084 ... 18085 <1a> DW_AT_name : tui-layout-asm-short-prog.S 18086 <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite 18087 <22> DW_AT_producer : GNU AS 2.35.2 18088 ... 18089 18090 The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry, 18091 making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S. 18092 18093 The bug is fixed starting version 2.38, where we get instead: 18094 ... 18095 <1a> DW_AT_name : 18096 $gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S 18097 <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite 18098 <22> DW_AT_producer : GNU AS 2.38 18099 ... 18100 18101 Work around the faulty debug info by constructing the filename_for_id using 18102 the second directory from the directory table in the .debug_line header: 18103 ... 18104 The Directory Table (offset 0x22, lines 2, columns 1): 18105 Entry Name 18106 0 $gdb/build/gdb/testsuite 18107 1 $gdb/src/gdb/testsuite/gdb.tui 18108 ... 18109 18110 Note that the used gas contains a backport of commit 3417bfca676 ("GAS: 18111 DWARF-5: Ensure that the 0'th entry in the directory table contains the 18112 current working directory."), because directory 0 is correct. With the 18113 unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of 18114 entry 1. 18115 18116 Add a dwarf assembly test-case that reflects the debug info as generated by 18117 unpatched gas 2.35.2. 18118 18119 Tested on x86_64-linux. 18120 18121 Approved-By: Tom Tromey <tom@tromey.com> 18122 181232023-10-31 Tom de Vries <tdevries@suse.de> 18124 18125 [gdb/symtab] Add producer_is_gas 18126 Add producer_is_gas, a generic way to get the gas version from the 18127 producer string. 18128 18129 Tested on x86_64-linux. 18130 181312023-10-31 Tom Tromey <tromey@adacore.com> 18132 18133 Implement DAP setVariable request 18134 This patch implements the DAP setVariable request. 18135 18136 setVariable is a bit odd in that it specifies the variable to modify 18137 by passing in the variable's container and the name of the variable. 18138 This approach can't handle variable shadowing (there are a couple of 18139 open DAP bugs on this topic), so this patch renames duplicates to 18140 avoid the problem. 18141 181422023-10-31 Hu, Lin1 <lin1.hu@intel.com> 18143 18144 Support Intel USER_MSR 18145 This patches aims to support Intel USER_MSR. In addition to the usual 18146 support, this patch includes encoding and decoding support for MAP7 and 18147 immediate numbers as the last operand (ATT style). 18148 18149 gas/ChangeLog: 18150 18151 * NEWS: Support Intel USER_MSR. 18152 * config/tc-i386.c (smallest_imm_type): Reject imm32 in 64bit 18153 mode. 18154 (build_vex_prefix): Add VEXMAP7. 18155 (md_assemble): Handling the imm32 of USER_MSR. 18156 (match_template): Handling the unusual immediate. 18157 * doc/c-i386.texi: Document .user_msr. 18158 * testsuite/gas/i386/i386.exp: Run USER_MSR tests. 18159 * testsuite/gas/i386/x86-64.exp: Ditto. 18160 * testsuite/gas/i386/user_msr-inval.l: New test. 18161 * testsuite/gas/i386/user_msr-inval.s: Ditto. 18162 * testsuite/gas/i386/x86-64-user_msr-intel.d: Ditto. 18163 * testsuite/gas/i386/x86-64-user_msr-inval.l: Ditto. 18164 * testsuite/gas/i386/x86-64-user_msr-inval.s: Ditto. 18165 * testsuite/gas/i386/x86-64-user_msr.d: Ditto. 18166 * testsuite/gas/i386/x86-64-user_msr.s: Ditto. 18167 18168 opcodes/ChangeLog: 18169 * i386-dis.c (struct instr_info): Add a new attribute 18170 has_skipped_modrm. 18171 (Gq): New. 18172 (Rq): Ditto. 18173 (q_mm_mode): Ditto. 18174 (Nq): Change mode from q_mode to q_mm_mode. 18175 (VEX_LEN_TABLE): 18176 (get_valid_dis386): Add VEX_MAP7 in VEX prefix. 18177 and handle the map7_f8 for save space. 18178 (OP_Skip_MODRM): Set has_skipped_modrm. 18179 (OP_E): Skip codep++ when has skipped modrm byte. 18180 (OP_R): Support q_mode and q_mm_mode. 18181 (REG_VEX_MAP7_F8_L_0_W_0): New. 18182 (PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64): Ditto. 18183 (X86_64_VEX_MAP7_F8_L_0_W_0_R_0): Ditto. 18184 (VEX_LEN_MAP7_F8): Ditto. 18185 (VEX_W_MAP7_F8_L_0): Ditto. 18186 (MOD_0F38F8): Ditto. 18187 (PREFIX_0F38F8_M_0): Ditto. 18188 (PREFIX_0F38F8_M_1_X86_64): Ditto. 18189 (X86_64_0F38F8_M_1): Ditto. 18190 (PREFIX_0F38F8): Remove. 18191 (prefix_table): Add PREFIX_0F38F8_M_1_X86_64. 18192 Remove PREFIX_0F38F8. 18193 (reg_table): Add REG_VEX_MAP7_F8_L_0_W_0, 18194 PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64. 18195 (x86_64_table): Add X86_64_0F38F8_PREFIX_3_M_1, 18196 X86_64_VEX_MAP7_F8_L_0_W_0_R_0 and X86_64_0F38F8_M_1. 18197 (vex_table): Add VEX_MAP7. 18198 (vex_len_table): Add VEX_LEN_MAP7_F8, 18199 VEX_W_MAP7_F8_L_0. 18200 (mod_table): New entry for USER_MSR and 18201 add MOD_0F38F8. 18202 * i386-gen.c (cpu_flag_init): Add CPU_USER_MSR_FLAGS and 18203 CPU_ANY_USER_MSR_FLAGS. Add add VEXMAP7. 18204 * i386-init.h: Regenerated. 18205 * i386-mnem.h: Ditto. 18206 * i386-opc.h (SPACE_VEXMAP7): New. 18207 (CPU_USER_MSR_FLAGS): Ditoo. 18208 (CPU_ANY_USER_MSR_FLAGS): Ditto. 18209 (i386_cpu_flags): Add cpuuser_msr. 18210 * i386-opc.tbl: Add USER_MSR instructions. 18211 * i386-tbl.h: Regenerated. 18212 182132023-10-31 Tom Tromey <tom@tromey.com> 18214 18215 Remove some frame invalidation code 18216 I stumbled across a few spots that mention that a function 18217 "invalidates frame" and also assignments of NULL to a frame_info_ptr. 18218 This code isn't harmful, but is also unnecessary since the 18219 introduction of frame_info_ptr -- nowadays frame invalidations are 18220 handled automatically. 18221 18222 Regression tested on x86-64 Fedora 38. 18223 18224 Approved-By: Simon Marchi <simon.marchi@efficios.com> 18225 182262023-10-31 GDB Administrator <gdbadmin@sourceware.org> 18227 18228 Automatic date update in version.in 18229 182302023-10-30 Nick Clifton <nickc@redhat.com> 18231 18232 New Georgian translation for the ld sub-directory 18233 182342023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com> 18235 18236 gas: bpf: new test for MOV with C-like numbers ll suffix 18237 The BPF pseudo-c syntax supports both MOV and LDDW instructions: 18238 18239 mov: r1 = EXPR 18240 lddw: r1 = EXPR ll 18241 18242 Note that the white space between EXPR and `ll' is necessary in order 18243 to avoid ambiguity with the assembler's support for C-like numerical 18244 suffixes. This patch adds a new test to the GAS BPF testsuite to make 18245 sure that instructions like: 18246 18247 r1 = 666ll 18248 18249 are interpreted as `mov %r1,666', not as `lddw %r1,666'. 18250 18251 This matches clang's assembler behavior. 18252 18253 2023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com> 18254 18255 * testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like 18256 suffix `ll' is not interpreted as lddw syntax. 18257 * testsuite/gas/bpf/alu-pseudoc.d: Update expected results. 18258 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 18259 182602023-10-30 Tom Tromey <tromey@adacore.com> 18261 18262 Fix fixed-point "return" on ARM 18263 On a big-endian ARM machine, the "return" command resulted in the 18264 wrong value being returned when the function had a fixed-point return 18265 type. This patch fixes the problem by unpacking and repacking the 18266 fixed-point type appropriately. 18267 18268 Approved-By: Luis Machado <luis.machado@arm.com> 18269 182702023-10-30 Tom Tromey <tromey@adacore.com> 18271 18272 Fix range-type "return" command on ARM 18273 On big-endian ARM, "return"ing from a function that returned a range 18274 type did not work. This patch strips the range type to treat the 18275 function as though it were returning the underlying type instead. 18276 18277 Approved-By: Luis Machado <luis.machado@arm.com> 18278 182792023-10-30 Tom Tromey <tromey@adacore.com> 18280 18281 Fix "finish" for vector types on ARM 18282 On a big-endian ARM system, "finish" printed the wrong value when 18283 finishing from a function that returned a vector type. Similarly, 18284 calls to a function also resulted in the wrong value being passed. I 18285 think both the read- and write-functions here should ignore the 18286 endian-ness. 18287 18288 I tested this using the AdaCore internal test suite; the test case 18289 that caught this is identical to gdb.base/gnu_vector.exp. 18290 18291 Approved-By: Luis Machado <luis.machado@arm.com> 18292 182932023-10-30 Tom Tromey <tromey@adacore.com> 18294 18295 Fix "finish" with range types on ARM 18296 On ARM (I tested big-endian but it may not matter), "finish" can 18297 sometimes print the wrong result when the return type is a range type. 18298 Range types should really be treated as their underlying type 18299 (normally integer, but sometimes fixed-point). This patch implements 18300 this. 18301 18302 Approved-By: Luis Machado <luis.machado@arm.com> 18303 183042023-10-30 Tom Tromey <tromey@adacore.com> 18305 18306 Fix calls with small integers on ARM 18307 On big-endian ARM, an inferior call with a small integer will pass the 18308 wrong value. This patch fixes the problem. Because the code here 18309 works using scalar values, and not just bytes, left-shifting is 18310 unnecessary. 18311 18312 Approved-By: Luis Machado <luis.machado@arm.com> 18313 183142023-10-30 Nick Clifton <nickc@redhat.com> 18315 18316 Accept and ignore the R_BPF_64_NODLYD32 relocation. 18317 183182023-10-30 Victor Do Nascimento <victor.donascimento@arm.com> 18319 18320 aarch64: Update aarch64-sys-regs.def header 18321 Given the shared use of the aarch64-sys-regs.def file across Binutils 18322 and GCC, add instructions for keeping the file synchronized across the 18323 two codebases. 18324 18325 Namely, it should be made clear that all changes are first to be made 18326 in Binutils and the updated file copied across to GCC. 18327 18328 opcodes/ChangeLog 18329 18330 * opcodes/aarch64-sys-regs.def: Update file-description header 18331 comment. 18332 183332023-10-30 GDB Administrator <gdbadmin@sourceware.org> 18334 18335 Automatic date update in version.in 18336 183372023-10-29 Tom Tromey <tom@tromey.com> 18338 18339 Move read_addrmap_from_aranges to new file 18340 In the interest of shrinking dwarf2/read.c a little more, this patch 18341 moves the code that deciphers .debug_aranges into a new file. 18342 18343 Reviewed-By: Guinevere Larsen <blarsen@redhat.com> 18344 183452023-10-29 Tom Tromey <tom@tromey.com> 18346 18347 Pre-read .debug_aranges section 18348 While working on background DWARF reading, I found a race case that I 18349 tracked down to the handling of the .debug_aranges section. Currently 18350 the section data is only read in after the CUs have all been created. 18351 However, there's no real reason to do this -- it seems fine to read it 18352 a little earlier, when all the other necessary sections are read in. 18353 18354 This patch makes this change, and updates the 18355 read_addrmap_from_aranges API to assert that the section is read in. 18356 18357 This patch slightly changes the read_addrmap_from_aranges API as well, 18358 to reject an empty section. This seems better to me than what the 18359 current code does, which is try to read an empty section but then do 18360 no work. 18361 18362 Regression tested on x86-64 Fedora 38. 18363 18364 Reviewed-By: Guinevere Larsen <blarsen@redhat.com> 18365 183662023-10-29 GDB Administrator <gdbadmin@sourceware.org> 18367 18368 Automatic date update in version.in 18369 183702023-10-28 Lancelot Six <lancelot.six@amd.com> 18371 18372 gdb/gdbsupport/gdbserver: Require c++17 18373 This patch proposes to require a C++17 compiler to build gdb / 18374 gdbsupport / gdbserver. Before this patch, GDB required a C++11 18375 compiler. 18376 18377 The general policy regarding bumping C++ language requirement in GDB (as 18378 stated in [1]) is: 18379 18380 Our general policy is to wait until the oldest compiler that 18381 supports C++NN is at least 3 years old. 18382 18383 Rationale: We want to ensure reasonably widespread compiler 18384 availability, to lower barrier of entry to GDB contributions, and to 18385 make it easy for users to easily build new GDB on currently 18386 supported stable distributions themselves. 3 years should be 18387 sufficient for latest stable releases of distributions to include a 18388 compiler for the standard, and/or for new compilers to appear as 18389 easily installable optional packages. Requiring everyone to build a 18390 compiler first before building GDB, which would happen if we 18391 required a too-new compiler, would cause too much inconvenience. 18392 18393 See the policy proposal and discussion 18394 [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). 18395 18396 The first GCC release which with full C++17 support is GCC-9[2], 18397 released in 2019[3], which is over 4 years ago. Clang has had C++17 18398 support since Clang-5[4] released in 2018[5]. 18399 18400 A discussions with many distros showed that a C++17-able compiler is 18401 always available, meaning that this no hard requirement preventing us to 18402 require it going forward. 18403 18404 [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F 18405 [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 18406 [3] https://gcc.gnu.org/gcc-9/ 18407 [4] https://clang.llvm.org/cxx_status.html 18408 [5] https://releases.llvm.org/ 18409 18410 Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd 18411 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 18412 Approved-By: Tom Tromey <tom@tromey.com> 18413 Approved-By: Pedro Alves <pedro@palves.net> 18414 184152023-10-28 Lancelot Six <lancelot.six@amd.com> 18416 18417 gdb/ax_cxx_compile_stdcxx.m4: upgrade 18418 This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes 18419 available in [1] and regenerates the configure script. 18420 18421 [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html 18422 18423 Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e 18424 Approved-By: Tom Tromey <tom@tromey.com> 18425 Approved-By: Pedro Alves <pedro@palves.net> 18426 184272023-10-28 Jose E. Marchesi <jose.marchesi@oracle.com> 18428 18429 gas: tc-bpf.c: fix formatting of comment 18430 18431 opcodes: bpf-dis.c: fix typo in comment 18432 184332023-10-28 GDB Administrator <gdbadmin@sourceware.org> 18434 18435 Automatic date update in version.in 18436 184372023-10-27 Simon Marchi <simon.marchi@efficios.com> 18438 18439 gdb: trim trailing spaces in i386-tdep.{c,h} 18440 Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df 18441 184422023-10-27 Nelson Chu <nelson@rivosinc.com> 18443 18444 RISC-V: Clarify the behaviors of SET/ADD/SUB relocations. 18445 We are used to generate these kinds of relocations by data directives. 18446 Considering the following example, 18447 .word (A + 3) - (B + 2) 18448 The GAS will generate a pair of ADD/SUB for this, 18449 R_RISCV_ADD, A + 1 18450 R_RISCV_SUB, 0 18451 18452 The addend of R_RISCV_SUB will always be zero, and the summary of the 18453 constants will be stored in the addend of R_RISCV_ADD/SET. Therefore, 18454 we can always add the addend of these data relocations when doing relocations. 18455 18456 But unfortunately, I had heard that if we are using .reloc to generate 18457 the data relocations will make the relocations failed. Refer to this, 18458 .reloc offset, R_RISCV_ADD32, A + 3 18459 .reloc offset, R_RISCV_SUB32, B + 2 18460 .word 0 18461 Then we can get the relocations as follows, 18462 R_RISCV_ADD, A + 3 18463 R_RISCV_SUB, B + 2 18464 Then... Current LD does the relocation, B - A + 3 + 2, which is wrong 18465 obviously... 18466 18467 So first of all, this patch fixes the wrong relocation behavior of 18468 R_RISCV_SUB* relocations. 18469 18470 Afterwards, considering the uleb128 direcitve, we will get a pair of 18471 SET_ULEB128/SUB_ULEB128 relocations for it for now, 18472 .uleb128 (A + 3) - (B + 2) 18473 R_RISCV_SET_ULEB128, A + 1 18474 R_RISCV_SUB_ULEB128, B + 1 18475 18476 Which looks also wrong obviously, the summary of the constants should only 18477 be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should 18478 be zero like other SUB relocations. But the current LD will still get the right 18479 relocation values since we only add the addend of SUB_ULEB128 by accident... 18480 Anyway, this patch also fixes the behaviors above, to make sure that no matter 18481 using .uleb128 or .reloc directives, we should always get the right values. 18482 18483 bfd/ 18484 * elfnn-riscv.c (perform_relocation): Clarify that SUB relocations 18485 should substract the addend, rather than add. 18486 (riscv_elf_relocate_section): Since SET_ULEB128 won't go into 18487 perform_relocation, we should add it's addend here in advance. 18488 gas/ 18489 * config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of 18490 SUB_ULEB128 to zero since it should already be added into the addend 18491 of SET_ULEB128. 18492 184932023-10-27 GDB Administrator <gdbadmin@sourceware.org> 18494 18495 Automatic date update in version.in 18496 184972023-10-26 Andrew Burgess <aburgess@redhat.com> 18498 18499 gdb/python: Add new gdb.Value.bytes attribute 18500 Add a gdb.Value.bytes attribute. This attribute contains the bytes of 18501 the value (assuming the complete bytes of the value are available). 18502 18503 If the bytes of the gdb.Value are not available then accessing this 18504 attribute raises an exception. 18505 18506 The bytes object returned from gdb.Value.bytes is cached within GDB so 18507 that the same bytes object is returned each time. The bytes object is 18508 created on-demand though to reduce unnecessary work. 18509 18510 For some values we can of course obtain the same information by 18511 reading inferior memory based on gdb.Value.address and 18512 gdb.Value.type.sizeof, however, not every value is in memory, so we 18513 don't always have an address. 18514 18515 The gdb.Value.bytes attribute will convert any value to a bytes 18516 object, so long as the contents are available. The value can be one 18517 created purely in Python code, the value could be in a register, 18518 or (of course) the value could be in memory. 18519 18520 The Value.bytes attribute can also be assigned too. Assigning to this 18521 attribute is similar to calling Value.assign, the value of the 18522 underlying value is updated within the inferior. The value assigned 18523 to Value.bytes must be a buffer which contains exactly the correct 18524 number of bytes (i.e. unlike value creation, we don't allow oversized 18525 buffers). 18526 18527 To support this assignment like behaviour I've factored out the core 18528 of valpy_assign. I've also updated convert_buffer_and_type_to_value 18529 so that it can (for my use case) check the exact buffer length. 18530 18531 The restrictions for when the Value.bytes can or cannot be written too 18532 are exactly the same as for Value.assign. 18533 18534 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13267 18535 18536 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 18537 Approved-By: Tom Tromey <tom@tromey.com> 18538 185392023-10-26 Andrew Burgess <aburgess@redhat.com> 18540 18541 gdb: handle main thread exiting during detach 18542 Overview 18543 ======== 18544 18545 Consider the following situation, GDB is in non-stop mode, the main 18546 thread is running while a second thread is stopped. The user has the 18547 second thread selected as the current thread and asks GDB to detach. 18548 At the exact moment of detach the main thread exits. 18549 18550 This situation currently causes crashes, assertion failures, and 18551 unexpected errors to be reported from GDB for both native and remote 18552 targets. 18553 18554 This commit addresses this situation for native and remote targets. 18555 There are a number of different fixes, but all are required in order 18556 to get this functionality working correct for native and remote 18557 targets. 18558 18559 Native Linux Target 18560 =================== 18561 18562 For the native Linux target, detaching is handled in the function 18563 linux_nat_target::detach. In here we call stop_wait_callback for each 18564 thread, and it is this callback that will spot that the main thread 18565 has exited. 18566 18567 GDB then detaches from everything except the main thread by calling 18568 detach_callback. 18569 18570 After this the first problem is this assert: 18571 18572 /* Only the initial process should be left right now. */ 18573 gdb_assert (num_lwps (pid) == 1); 18574 18575 The num_lwps call will return 0 as the main thread has exited and all 18576 of the other threads have now been detached. I fix this by changing 18577 the assert to allow for 0 or 1 lwps at this point. As the 0 case can 18578 only happen in non-stop mode, the assert becomes: 18579 18580 gdb_assert (num_lwps (pid) == 1 18581 || (target_is_non_stop_p () && num_lwps (pid) == 0)); 18582 18583 The next problem is that we do: 18584 18585 main_lwp = find_lwp_pid (ptid_t (pid)); 18586 18587 and then proceed assuming that main_lwp is not nullptr. In the case 18588 that the main thread has exited though, main_lwp will be nullptr. 18589 18590 However, we only need main_lwp so that GDB can detach from the 18591 thread. If the main thread has exited, and GDB has already detached 18592 from every other thread, then GDB has finished detaching, GDB can skip 18593 the calls that try to detach from the main thread, and then tell the 18594 user that the detach was a success. 18595 18596 For Remote Targets 18597 ================== 18598 18599 On remote targets there are two problems. 18600 18601 First is that when the exit occurs during the early phase of the 18602 detach, we see the stop notification arrive while GDB is removing the 18603 breakpoints ahead of the detach. The 'set debug remote on' trace 18604 looks like this: 18605 18606 [remote] Sending packet: $z0,7f1648fe0241,1#35 18607 [remote] Notification received: Stop:W0;process:2a0ac8 18608 # At this point an unpatched gdbserver segfaults, and the connection 18609 # is broken. A patched gdbserver continues as below... 18610 [remote] Packet received: E01 18611 [remote] Sending packet: $z0,7f1648ff00a8,1#68 18612 [remote] Packet received: E01 18613 [remote] Sending packet: $z0,7f1648ff132f,1#6b 18614 [remote] Packet received: E01 18615 [remote] Sending packet: $D;2a0ac8#3e 18616 [remote] Packet received: E01 18617 18618 I was originally running into Segmentation Faults, from within 18619 gdbserver/mem-break.cc, in the function find_gdb_breakpoint. This 18620 function calls current_process() and then dereferences the result to 18621 find the breakpoint list. 18622 18623 However, in our case, the current process has already exited, and so 18624 the current_process() call returns nullptr. At the point of failure, 18625 the gdbserver backtrace looks like this: 18626 18627 #0 0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982 18628 #1 0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093 18629 #2 0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372 18630 #3 0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498 18631 ... 18632 18633 The problem is that, as a result non-stop being on, the process 18634 exiting is only reported back to GDB after the request to remove a 18635 breakpoint has been sent. Clearly gdbserver can't actually remove 18636 this breakpoint -- the process has already exited -- so I think the 18637 best solution is for gdbserver just to report an error, which is what 18638 I've done. 18639 18640 The second problem I ran into was on the gdb side, as the process has 18641 already exited, but GDB has not yet acknowledged the exit event, the 18642 detach -- the 'D' packet in the above trace -- fails. This was being 18643 reported to the user with a 'Can't detach process' error. As the test 18644 actually calls detach from Python code, this error was then becoming a 18645 Python exception. 18646 18647 Though clearly the detach has returned an error, and so, maybe, having 18648 GDB throw an error would be fine, I think in this case, there's a good 18649 argument that the remote error can be ignored -- if GDB tries to 18650 detach and gets back an error, and if there's a pending exit event for 18651 the pid we tried to detach, then just ignore the error and pretend the 18652 detach worked fine. 18653 18654 We could possibly check for a pending exit event before sending the 18655 detach packet, however, I believe that it might be possible (in 18656 non-stop mode) for the stop notification to arrive after the detach is 18657 sent, but before gdbserver has started processing the detach. In this 18658 case we would still need to check for pending stop events after seeing 18659 the detach fail, so I figure there's no point having two checks -- we 18660 just send the detach request, and if it fails, check to see if the 18661 process has already exited. 18662 18663 Testing 18664 ======= 18665 18666 In order to test this issue I needed to ensure that the exit event 18667 arrives at the same time as the detach call. The window of 18668 opportunity for getting the exit to arrive is so small I've never 18669 managed to trigger this in real use -- I originally spotted this issue 18670 while working on another patch, which did manage to trigger this 18671 issue. 18672 18673 However, if we trigger both the exit and the detach from a single 18674 Python function then we never return to GDB's event loop, as such GDB 18675 never processes the exit event, and so the first time GDB gets a 18676 chance to see the exit is during the detach call. And so that is the 18677 approach I've taken for testing this patch. 18678 18679 Tested-By: Kevin Buettner <kevinb@redhat.com> 18680 Approved-By: Kevin Buettner <kevinb@redhat.com> 18681 186822023-10-26 Tom de Vries <tdevries@suse.de> 18683 18684 [gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.exp 18685 If we make writing an index-cache entry very slow by doing this in 18686 index_cache::store: 18687 ... 18688 try 18689 { 18690 + sleep (15); 18691 index_cache_debug ("writing index cache for objfile %s", 18692 bfd_get_filename (per_bfd->obfd)); 18693 ... 18694 we run into: 18695 ... 18696 FAIL: gdb.dwarf2/per-bfd-sharing.exp: \ 18697 couldn't remove files in temporary cache dir 18698 ... 18699 18700 The FAIL happens because there is no index-cache entry in the cache dir. 18701 18702 The problem is that gdb is killed (by gdb_exit) before the index-cache entry 18703 is written. 18704 18705 Fix this by using "maint wait-for-index-cache". 18706 18707 Tested on x86_64-linux. 18708 18709 PR testsuite/30528 18710 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528 18711 187122023-10-26 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 18713 18714 gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itself 18715 GCC doesn't complain, but it's still wrong. 18716 187172023-10-26 GDB Administrator <gdbadmin@sourceware.org> 18718 18719 Automatic date update in version.in 18720 187212023-10-25 Guinevere Larsen <blarsen@redhat.com> 18722 18723 gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.exp 18724 Clang doesn't use CFA information for variable locations. This makes it 18725 so software breakpoints get a false hit when rbp gets popped, causing 18726 a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with 18727 GDB itself, add an xfail to reduce noise. 18728 18729 Approved-By: Tom Tromey <tom@tromey.com> 18730 187312023-10-25 Guinevere Larsen <blarsen@redhat.com> 18732 18733 gdb/testsuite: fix running gdb.python/py-explore-cc with clang 18734 The test gdb.python/py-explore-cc.exp was showing one unexpected 18735 failure. This was due to how clang mapped instructions to lines, 18736 resulting in the inferior seemingly stopping at a different location. 18737 18738 This patch adds a nop line in the relevant location so we don't need to 18739 add XFAILs for existing clang releases, if this gets solved in future 18740 versions. 18741 18742 Approved-By: Tom Tromey <tom@tromey.com> 18743 187442023-10-25 Andrew Burgess <aburgess@redhat.com> 18745 18746 gdbserver: don't leak program name in handle_v_run 18747 I noticed that in handle_v_run (gdbserver/server.cc) we leak 18748 new_program_name (a string) each time GDB starts an inferior, in the 18749 case where GDB passes a program name to gdbserver. 18750 18751 This bug was introduced with this commit: 18752 18753 commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c 18754 Date: Wed Apr 13 17:31:02 2022 -0400 18755 18756 gdbsupport: make gdb_abspath return an std::string 18757 18758 When gdbserver receives a program name from GDB, this is first placed 18759 into a malloc'd buffer within handle_v_run, and this buffer is then 18760 used in this call: 18761 18762 program_path.set (new_program_name); 18763 18764 Prior to the above commit this call took ownership of the buffer 18765 passed to it, but now this call uses the buffer to initialise a 18766 std::string, which copies the buffer contents, leaving ownership with 18767 the caller. So now, after this call (in handle_v_run) 18768 new_program_name still owns a buffer. 18769 18770 At no point in handle_v_run do we free new_program_name, as a result 18771 we are leaking the program name each time GDB starts a remote 18772 inferior. 18773 18774 I could solve this by adding a 'free' call into handle_v_run, but I'd 18775 rather automate the memory management. 18776 18777 So, to this end, I have added a new function in gdbserver/server.cc, 18778 decode_v_run_arg. This function takes care of allocating the memory 18779 buffer and decoding the vRun packet into the buffer, but returns a 18780 gdb::unique_xmalloc_ptr<char> (or nullptr on error). 18781 18782 Back in handle_v_run I have converted new_program_name to also be a 18783 gdb::unique_xmalloc_ptr<char>. 18784 18785 Now, after we call program_path.set(), the allocated buffer will be 18786 automatically released when it is no longer needed. 18787 18788 It is worth highlighting that within the new decode_v_run_arg 18789 function, I have wrapped the call to hex2bin in a try/catch block. 18790 The hex2bin function can throw an exception if it encounters an 18791 invalid (non-hex) character. Back in handle_v_run, we have a local 18792 argument new_argv, which is of type std::vector<char *>. Each 18793 'char *' in this vector is a malloc'd buffer. If we allow 18794 hex2bin to throw an exception and don't catch it in either 18795 decode_v_run_arg or handle_v_run then we are going to leak memory from 18796 new_argv. 18797 18798 I chose to catch the exception in decode_v_run_arg, this seemed 18799 cleanest, but I'm not sure it really matters, so long as the exception 18800 is caught before we leave handle_v_run. I am working on a patch that 18801 changes new_argv to automatically manage its memory, but that isn't 18802 ready for posting yet. I think what I have here would be fine if my 18803 follow on patch never arrives. 18804 18805 Additionally, within the handle_v_run loop I have changed an 18806 assignment of nullptr to new_program_name into an assert. Previously, 18807 the assignment could only trigger on the first iteration of the loop, 18808 if we had no new program name to assign. However, new_program_name 18809 always starts as nullptr, so, on the first loop iteration, if we have 18810 nothing to assign to new_program_name, its value must already be 18811 nullptr. 18812 18813 There should be no user visible changes after this commit. 18814 18815 Approved-By: Simon Marchi <simon.marchi@efficios.com> 18816 188172023-10-25 Simon Marchi <simon.marchi@efficios.com> 18818 18819 gdb: make get_symbol_address a private method of symbol 18820 get_symbol_address is only used symbol::value_address, make it a private 18821 helper method. 18822 18823 Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c 18824 Approved-By: Tom Tromey <tom@tromey.com> 18825 188262023-10-25 Simon Marchi <simon.marchi@efficios.com> 18827 18828 gdb: make get_msymbol_address a private method of minimal_symbol 18829 get_msymbol_address is only used in minimal_symbol::value_address. Make 18830 it a private helper method. 18831 18832 Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f 18833 Approved-By: Tom Tromey <tom@tromey.com> 18834 188352023-10-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 18836 18837 gprofng: Fix -Wformat= warnings 18838 Added format attribute to several gprofng functions. 18839 Fixed -Wformat= warnings. 18840 18841 gprofng/ChangeLog 18842 2023-10-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 18843 18844 * libcollector/heaptrace.c: Fixed -Wformat= warnings. 18845 * libcollector/hwprofile.c: Likewise. 18846 * libcollector/iolib.c: Likewise. 18847 * libcollector/iotrace.c: Likewise. 18848 * libcollector/jprofile.c: Likewise. 18849 * libcollector/profile.c: Likewise. 18850 * libcollector/synctrace.c: Likewise. 18851 * src/ClassFile.cc: Likewise. 18852 * src/SourceFile.cc: Likewise. 18853 * libcollector/libcol_util.h: Added format attribute. 18854 * src/Emsg.h: Likewise. 18855 * src/collector_module.h: Likewise. 18856 * src/data_pckts.h: Define fld_sizeof. 18857 188582023-10-25 Alan Modra <amodra@gmail.com> 18859 18860 asan: _bfd_elf_slurp_version_tables memory leak 18861 Extends commit 6136093c0d00 to handle verdefs as well as verrefs. 18862 18863 PR 30886 18864 * elf.c (_bfd_elf_slurp_version_tables): See free_contents for 18865 verdefs too. Use free_contents rather than elf_tdata fields. 18866 188672023-10-25 Alan Modra <amodra@gmail.com> 18868 18869 asan: out of memory in som_set_reloc_info 18870 Sections without SEC_HAS_CONTENTS avoid the file size checks, and of 18871 course it doesn't make sense to read such as the contents are all 18872 zero. 18873 18874 * som.c (som_set_reloc_info): Don't read sections without contents. 18875 188762023-10-25 Alan Modra <amodra@gmail.com> 18877 18878 asan: NULL deref in alpha_ecoff_get_relocated_section_contents 18879 This fixes some holes found by fuzzers, and removes aborts that can be 18880 triggered by user input to objdump. Abort should only be used within 18881 bfd to show programming errors in bfd. 18882 18883 * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle 18884 NULL howto. Don't abort on stack errors or on unexpected relocs. 18885 Show more bfd reloc status messages. 18886 188872023-10-25 GDB Administrator <gdbadmin@sourceware.org> 18888 18889 Automatic date update in version.in 18890 188912023-10-24 Tom de Vries <tdevries@suse.de> 18892 18893 [gdb/cli] Add gnu-source-highlight selftest 18894 Add a selftest gnu-source-highlight: 18895 ... 18896 $ gdb -q -batch -ex "maint selftest gnu-source-highlight" 18897 Running selftest gnu-source-highlight. 18898 Ran 1 unit tests, 0 failed 18899 ... 18900 18901 Tested on x86_64-linux. 18902 189032023-10-24 Tom de Vries <tdevries@suse.de> 18904 18905 [readelf] Handle unknown name of main in .gdb_index section 18906 When compiling hello world and adding a v9 .gdb-index section: 18907 ... 18908 $ gcc -g hello.c 18909 $ gdb-add-index a.out 18910 ... 18911 readelf shows it as: 18912 ... 18913 Shortcut table: 18914 Language of main: unknown: 0 18915 Name of main: ^A 18916 ... 18917 18918 The documentation of gdb says about the "Name of main" that: 18919 ... 18920 This value must be ignored if the value for the language of main is zero. 18921 ... 18922 18923 Implement this approach in display_gdb_index, such that we have instead: 18924 ... 18925 Shortcut table: 18926 Language of main: unknown: 0 18927 Name of main: <unknown> 18928 ... 18929 18930 Tested on x86_64-linux. 18931 18932 Approved-By: Jan Beulich <jbeulich@suse.com> 18933 189342023-10-24 Lulu Cai <cailulu@loongson.cn> 18935 18936 as: fixed internal error when immediate value of relocation overflow. 18937 The as and ld use _bfd_error_handler to output error messages when 18938 checking relocation alignment and relocation overflow. However, the 18939 abfd value passed by as to the function is NULL, resulting in an 18940 internal error. The ld passes a non-null value to the function, 18941 so it can output an error message normally. 18942 189432023-10-24 GDB Administrator <gdbadmin@sourceware.org> 18944 18945 Automatic date update in version.in 18946 189472023-10-23 Tom de Vries <tdevries@suse.de> 18948 18949 [gdb/python] Only include gdbsupport/selftest.h if GDB_SELF_TEST 18950 I noticed that gdb/python/python.c unconditionally includes 18951 gdbsupport/selftest.h. 18952 18953 Make this conditional on GDB_SELF_TEST. 18954 18955 Tested on x86_64-linux. 18956 189572023-10-23 Jan Beulich <jbeulich@suse.com> 18958 18959 gas: make .nops output visible in listing 18960 Due to using a different frag type (in turn due to storing data 18961 differently), making the resulting code appear in listings requires 18962 special handling. 18963 18964 x86: fold NOP testcase expectations where possible 18965 Like done earlier for files needing adjustment anyway, also do this for 18966 the remaining set. 18967 18968 x86: fold a few of the "alternative" NOP patterns 18969 Since named objects may not overlap, the compiler is not permitted to do 18970 this for us, to avoid wasting space and cache bandwidth/capacity. 18971 189722023-10-23 Jan Beulich <jbeulich@suse.com> 18973 18974 x86: add a few more NOP patterns 18975 First of all add f32_5[], allowing to eliminate the extra slot-is-NULL 18976 code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[] 18977 following the same concept of adding a %cs segment override prefix. 18978 18979 Also re-use patterns when possible and correct comments as applicable. 18980 Similarly re-use testcase expectations as much as possible, where they 18981 need touching anyway. 18982 189832023-10-23 Jan Beulich <jbeulich@suse.com> 18984 18985 x86: don't record full i386_cpu_flags in struct i386_tc_frag_data 18986 We only use a single bit of this ever growing structure. 18987 189882023-10-23 Jan Beulich <jbeulich@suse.com> 18989 18990 x86: i686 != PentiumPro 18991 The two are distinct in opcodes/, distinguished precisely by CpuNOP 18992 that's relevant in i386_generate_nops(), yet the function has the PPro 18993 case label in the other group. Simply removing it revealed that 18994 cpu_arch[] had a wrong entry for i686. 18995 18996 While there also add PROCESSOR_IAMCU to the respective comment. 18997 189982023-10-23 Jan Beulich <jbeulich@suse.com> 18999 19000 x86: respect ".arch nonop" when selecting which NOPs to emit 19001 Making GENERIC64 a special case was never correct; prior to the 19002 generalization of ".arch .no*" to cover all ISA extensions other 19003 processor families supporting long NOPs should have been covered as 19004 well. When introducing ".arch .nonops" (among others) it wasn't 19005 apparent that a hidden implication of .cpunop not being possible to 19006 separately turn off existed here. Seeing that the two large case label 19007 blocks in the 2nd switch() already had identical behavior, simply 19008 collapse all of the (useful) case labels into a single "default" one. 19009 19010 x86: don't use operand size override with NOP in 16-bit code 19011 Since we don't key the NOP selection to user-controlled properties, we 19012 may not use i386 features; otherwise we would violate a possible .arch 19013 directive restricting ISA to pre-386. 19014 19015 x86: don't use 32-bit LEA as NOP surrogate in 64-bit code 19016 Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi 19017 (by zero-extending %esi to %rsi). Introduce separate 64-bit patterns 19018 which keep %rsi intact. 19019 19020 x86: i386_generate_nops() may not derive decisions from global variables 19021 What matters is what was in effect at the time the original directive 19022 was issued. Later changes to global state (bitness or ISA) must not 19023 affect what code is generated. 19024 19025 x86: record flag_code in tc_frag_data 19026 The recorded value, and not the global variable, will want using in 19027 TC_FRAG_INIT(). The so far file scope variable therefore needs to become 19028 external, to be accessible there. 19029 190302023-10-23 Clément Chigot <chigot@adacore.com> 19031 19032 objcopy: fix typo in --heap and --stack parser 19033 The help says that <reserve> and <commit> should be separated by a "," 19034 but the implementation is checking for ".". Having two numbers being 19035 separated by a "." could be confusing, thus adjust the implementation to 19036 match the help syntax. 19037 19038 binutils/ChangeLog: 19039 19040 * objcopy.c (copy_main): Set separator to "," between <reserve> 19041 and <commit> for --heap and --stack. 19042 * doc/binutils.texi: Add <commit> for --heap and --stack. 19043 190442023-10-23 GDB Administrator <gdbadmin@sourceware.org> 19045 19046 Automatic date update in version.in 19047 190482023-10-23 Alan Modra <amodra@gmail.com> 19049 19050 bfd-in2.h BFD_RELOC_* comments 19051 I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't 19052 match that committed to bfd-in2.h, and was just going to regen 19053 bfd-in2.h but then decided to do something about the silly formatting 19054 of these comments in bfd-in2.h. eg. the BFD_RELOC_MICROBLAZE_32_NONE 19055 comment: 19056 19057 -/* This is a 32 bit reloc that stores the 32 bit pc relative 19058 -value in two words (with an imm instruction).No relocation is 19059 -done here - only used for relaxing */ 19060 + /* This is a 32 bit reloc that stores the 32 bit pc relative value in 19061 + two words (with an imm instruction). No relocation is done here - 19062 + only used for relaxing. */ 19063 BFD_RELOC_MICROBLAZE_32_NONE, 19064 19065 You'll notice how the second and third line of the original comment 19066 aren't indented properly relative to the first line, and the whole 19067 comment needs to be indented to match the code. 19068 19069 I've also edited reloc.c ENUMDOC paragraphs. Some of these had excess 19070 indentation, presumably in an attempt to properly indent bfd-in2.h 19071 comments but that fails due to chew.c removing leading whitespace 19072 early by skip_white_and_stars. COMMENT was used in reloc.c to add 19073 extra blank lines in bfd-in2.h. I've removed them too as I don't 19074 think they add anything to readability of that file. (Perhaps more 19075 usefully, they also add blank lines to libbfd.h separating relocs for 19076 one target from others, but this isn't done consistently.) 19077 19078 * doc/chew.c (drop, idrop): Move earlier. 19079 (strip_trailing_newlines): Check index before accessing array, 19080 not after. 19081 (wrap_comment): New function. 19082 (main): Add "wrap_comment" intrinsic. 19083 * doc/proto.str (ENUMDOC): Use wrap_comment. 19084 (make_enum_header, ENDSENUM): Put start and end braces on 19085 separate lines. 19086 * reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs. 19087 * libbfd.h: Regenerate. 19088 * bfd-in2.h: Regenerate. 19089 190902023-10-22 Tom Tromey <tom@tromey.com> 19091 19092 Style history variable output 19093 When printing a value, I think the history reference -- the "$1" in 19094 the output -- should be styled using the "variable" style. This patch 19095 implements this. 19096 190972023-10-22 GDB Administrator <gdbadmin@sourceware.org> 19098 19099 Automatic date update in version.in 19100 191012023-10-21 Simon Marchi <simon.marchi@efficios.com> 19102 19103 gdb: fix owner passed to remove_target_sections in clear_solib 19104 Commit 8971d2788e7 ("gdb: link so_list using intrusive_list") introduced 19105 a bug in clear_solib. Instead of passing an `so_list *` to 19106 remove_target_sections, it passed an `so_list **`. This was not caught 19107 by the compiler, because remove_target_sections takes a `void *` as the 19108 "owner", so you can pass it any pointer and it won't complain. 19109 19110 This happened because I previously had a patch to change the type of the 19111 disposer parameter to be a reference rather than a pointer, so had to 19112 change `so` to `&so`. When dropping that patch, I forgot to revert this 19113 bit and / or it got re-introduced when handling subsequent merge 19114 conflicts. And I didn't properly retest. 19115 19116 Fix that, but try to make things less error prone. Add a union to 19117 represent the possible owner kinds for a target_section. Trying to pass 19118 a pointer to another type than those will not compile. 19119 19120 Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c 19121 191222023-10-21 GDB Administrator <gdbadmin@sourceware.org> 19123 19124 Automatic date update in version.in 19125 191262023-10-20 Tom de Vries <tdevries@suse.de> 19127 19128 [gdb/cli] Allow source-highlight to autodetect language 19129 Currently when gdb asks the source-highlight library to highlight a file, it 19130 tells it what language file to use. 19131 19132 For instance, if gdb learns from the debug info that the file is language_c, 19133 the language file "c.lang" is used. This mapping is hardcoded in 19134 get_language_name. 19135 19136 However, if gdb doesn't know what language file to use, it falls back to using 19137 python pygments, and in absence of that, unhighlighted source text. 19138 19139 In the case of python pygments, it autodetects which language to use based on 19140 the file name. 19141 19142 Add the same capability when using the source-highlight library. 19143 19144 Tested on x86_64-linux. 19145 19146 Verified that it works by: 19147 - making get_language_name return nullptr for language_c, and 19148 - checking that source-highlight still manages to highlight a hello world. 19149 19150 Reviewed-By: Guinevere Larsen <blarsen@redhat.com> 19151 Approved-By: Tom Tromey <tom@tromey.com> 19152 19153 PR cli/30966 19154 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966 19155 191562023-10-20 Tom Tromey <tom@tromey.com> 19157 19158 Don't include cooked-index.h from dwarf2/read.h 19159 dwarf2/read.h includes cooked-index.h, but it doesn't need to. This 19160 patch removes the inclusion from this header, and adds one to 19161 index-write.c to make up for the absence. 19162 191632023-10-20 Neal Frager <neal.frager@amd.com> 19164 19165 gas: testsuite: microblaze: cosmetic fix 19166 This patch makes a cosmetic change to the reloc_weaksym.s 19167 by making the bneid instruction all lower case like all of 19168 the other instructions in the example. 19169 191702023-10-20 Nick Alcock <nick.alcock@oracle.com> 19171 19172 libctf: fix creation-time parent/child dict confusions 19173 The fixes applied a few years ago to resolve confusions between parent and 19174 child dicts at lookup time also apply in various forms to creation. In 19175 general, if you have a type in a parent dict ctf_imported into a child and 19176 you do something to it, and the parent dict is writable (created via 19177 ctf_create, not opened via ctf_open*) it should work just the same to make 19178 changes to that type via a child dict as it does to make the change 19179 to the parent dict directly -- and nothing you're prohibited from doing 19180 to the parent dict when done directly should be allowed just because 19181 you're doing it via a child. 19182 19183 Specifically, the following don't work when doing things from the child, but 19184 should: 19185 19186 - adding a member of a type in the parent to a struct or union in the 19187 parent via ctf_add_member or ctf_add_member_offset: this yields 19188 ECTF_BADID 19189 19190 - adding a member of a type in the parent to a struct or union in the 19191 parent via ctf_add_member_encoded: this dumps core (!). 19192 19193 - adding an enumerand to an enumerator in the parent: this yields 19194 ECTF_BADID 19195 19196 - setting the properties of an array in the parent via ctf_set_array; 19197 this yields ECTF_BADID 19198 19199 Relatedly, some things work when doing things via a child that should fail, 19200 yielding a CTF dictionary with invalid content (readable, but meaningless): 19201 in particular, you can add a child type to a struct in the parent via 19202 any of the ctf_add_member* family and nothing complains at all, even though 19203 you should never be able to add references to children to parents (since any 19204 given parent can be associated with many different children). 19205 19206 A family of tests is added to check each of these cases independently, since 19207 some can result in coredumps and it would be nice to test the other cases 19208 even if some dump core. They use a common library to do all the actual 19209 work. The set of affected API calls was determined by code inspection 19210 (auditing all calls to ctf_dtd_lookup): it's possible that I missed a few, 19211 but I doubt it, since other cases use ctf_lookup* functions, which already 19212 climb to the parent where appropriate. 19213 19214 libctf/ChangeLog: 19215 19216 PR libctf/30985 19217 * ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary. 19218 (ctf_set_array): Likewise. Report errors on the child; require 19219 both parent and child to be writable. 19220 (ctf_add_enumerator): Likewise. 19221 (ctf_add_member_offset): Likewise. Prohibit addition of child types 19222 to structs in the parent. 19223 (ctf_add_member_encoded): Do not dereference a NULL dtd: report 19224 ECTF_BADID instead. 19225 * ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the 19226 dict if addition of a string ref fails. 19227 * testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library. 19228 * testsuite/libctf-writable/parent-child-dtd-enum.*: New test. 19229 * testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test. 19230 * testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test. 19231 * testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test. 19232 * testsuite/libctf-writable/parent-child-dtd-set-array.*: New test. 19233 * testsuite/libctf-writable/parent-child-dtd-struct.*: New test. 19234 * testsuite/libctf-writable/parent-child-dtd-union.*: New test. 19235 192362023-10-20 Neal Frager <neal.frager@amd.com> 19237 19238 bfd: microblaze: Add 32_NONE reloc type 19239 This patch adds the R_MICROBLAZE_32_NONE relocation type. 19240 This is a 32-bit reloc that stores the 32-bit pc relative 19241 value in two words (with an imm instruction). 19242 19243 Add test case to gas test suite. 19244 192452023-10-20 Tom de Vries <tdevries@suse.de> 19246 19247 [gdb/symtab] Fix more style issues in v9 .gdb_index section support 19248 I noticed a few more style issues in commit 8b9c08eddac ("[gdb/symtab] Add 19249 name_of_main and language_of_main to the DWARF index"), after checking it 19250 with gcc's check_GNU_style.{sh,py}. 19251 19252 Fix these. 19253 19254 Build on x86_64-linux. 19255 192562023-10-20 Neal Frager <neal.frager@amd.com> 19257 19258 opcodes: microblaze: Fix bit masking bug 19259 There is currently a bug in the bit masking for the barrel shift 19260 instructions because the bit mask is not including all of the 19261 register bits which must be zero. With this patch, the disassembler 19262 can be sure that the 32-bit value is indeed a barrel shift instruction 19263 and not a data value in memory. 19264 19265 This fix can be verified by assembling and disassembling the following: 19266 19267 .text 19268 .long 0x65005f5f 19269 19270 With this patch, the bug is fixed, and the objdump will know that 19271 0x65005f5f is not a barrel shift instruction. 19272 192732023-10-20 GDB Administrator <gdbadmin@sourceware.org> 19274 19275 Automatic date update in version.in 19276 192772023-10-19 Tom Tromey <tom@tromey.com> 19278 19279 Fix race in DWARF reader 19280 The recent change to record the DWARF language in the per-CU data 19281 yielded a race warning in my testing: 19282 19283 ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit 19284 19285 This patch fixes the bug by applying the same style of fix that was 19286 done for the ordinary (gdb) language. 19287 19288 I wonder if this code could be improved. Requiring an atomic for the 19289 language in particular seems unfortunate, as it is often consulted 19290 during index finalization. However, I haven't investigated this. 19291 19292 Regression tested on x86-64 Fedora 38. 19293 19294 Reviewed-by: Tom de Vries <tdevries@suse.de> 19295 192962023-10-19 Alan Modra <amodra@gmail.com> 19297 19298 PR30984, assertion fail elf.c:8485 19299 PR 30984 19300 * ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as 19301 a potential output section. 19302 193032023-10-19 Simon Marchi <simon.marchi@efficios.com> 19304 19305 gdb: fix no-expat build of solib-target.c 19306 Fixes: 19307 19308 CXX solib-target.o 19309 /home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type 19310 57 | static lm_info_vector 19311 | ^~~~~~~~~~~~~~ 19312 /home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’: 19313 /home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope 19314 244 | = solib_target_parse_libraries (library_document->data ()); 19315 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19316 19317 Change-Id: Ib477d3343b401017d79729118242143bc95f24b2 19318 193192023-10-19 Jose E. Marchesi <jose.marchesi@oracle.com> 19320 19321 ld: fix typo in ld.texi metdata->metadata 19322 193232023-10-19 Simon Marchi <simon.marchi@efficios.com> 19324 19325 gdb: rename struct so_list to shobj 19326 Now that so_list lists are implemented using intrusive_list, it doesn't 19327 really make sense for the element type to be named "_list". Rename to 19328 just `struct shobj` (`struct so` was deemed to be not greppable enough). 19329 19330 Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e 19331 Approved-By: Pedro Alves <pedro@palves.net> 19332 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19333 193342023-10-19 Simon Marchi <simon.marchi@efficios.com> 19335 19336 gdb: remove free_so function 19337 Remove this function, replace it with deleting the so_list in callers. 19338 19339 Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60 19340 Approved-By: Pedro Alves <pedro@palves.net> 19341 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19342 193432023-10-19 Simon Marchi <simon.marchi@efficios.com> 19344 19345 gdb: don't call so_list::clear in free_so 19346 I think this `so.clear ()` call is not useful. 19347 19348 - so_list::clear deletes some things that now get automatically deleted 19349 when the so_list gets deleted right after in free_so. 19350 - so_list::clear resets some scalar fields of so_list, which we don't 19351 really care about since the so_list gets deleted right after. 19352 - so_list::clear calls target_so_ops::clear_so, of which there is a 19353 single implementation, svr4_clear_so. That implementation just 19354 resets a field in lm_info_svr4, which we don't care about, as it will 19355 get deleted when the so_list gets deleted right after. 19356 19357 Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32 19358 Approved-By: Pedro Alves <pedro@palves.net> 19359 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19360 193612023-10-19 Simon Marchi <simon.marchi@efficios.com> 19362 19363 gdb: link so_list using intrusive_list 19364 Replace the hand-made linked list implementation with intrusive_list, 19365 simplying management of list items. 19366 19367 Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d 19368 Approved-By: Pedro Alves <pedro@palves.net> 19369 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19370 193712023-10-19 Simon Marchi <simon.marchi@efficios.com> 19372 19373 gdb: make so_list::{so_original_name,so_name} std::strings 19374 Change these two fields, simplifying memory management and copying. 19375 19376 Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55 19377 Approved-By: Pedro Alves <pedro@palves.net> 19378 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19379 193802023-10-19 Simon Marchi <simon.marchi@efficios.com> 19381 19382 gdb: make so_list::abfd a gdb_bfd_ref_ptr 19383 Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically 19384 manage the reference. 19385 19386 Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950 19387 Approved-By: Pedro Alves <pedro@palves.net> 19388 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19389 193902023-10-19 Simon Marchi <simon.marchi@efficios.com> 19391 19392 gdb: make so_list::sections not a pointer 19393 Make the field a vector directly, instead of a pointer to a vector. 19394 This was needed when so_list had to be a trivial type, which is not the 19395 case anymore. 19396 19397 Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14 19398 Approved-By: Pedro Alves <pedro@palves.net> 19399 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19400 194012023-10-19 Simon Marchi <simon.marchi@efficios.com> 19402 19403 gdb: remove target_section_table typedef 19404 Remove this typedef. I think that hiding the real type (std::vector) 19405 behind a typedef just hinders readability. 19406 19407 Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f 19408 Approved-By: Pedro Alves <pedro@palves.net> 19409 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19410 194112023-10-19 Simon Marchi <simon.marchi@efficios.com> 19412 19413 gdb: make clear_so a method of struct so_list 19414 ... just because it seems to make sense to do so. 19415 19416 Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b 19417 Approved-By: Pedro Alves <pedro@palves.net> 19418 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19419 194202023-10-19 Simon Marchi <simon.marchi@efficios.com> 19421 19422 gdb: make so_list::lm_info a unique_ptr 19423 Make it a unique_ptr, so it gets automatically deleted when the so_list 19424 is deleted. 19425 19426 Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d 19427 Approved-By: Pedro Alves <pedro@palves.net> 19428 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19429 194302023-10-19 Simon Marchi <simon.marchi@efficios.com> 19431 19432 gdb: remove lm_info_vector typedef 19433 I think this typedef hinders readability. First, it's not well named 19434 (it's not clear it contains lm_info_target objects). And hiding the 19435 fact that it contains unique pointers is not very useful either. I was 19436 looking at the code in solib_target_current_sos where the unique 19437 pointers get moved from the vector, and it wasn't obvious at all what 19438 the source of the move was. 19439 19440 Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7 19441 Approved-By: Pedro Alves <pedro@palves.net> 19442 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19443 194442023-10-19 Simon Marchi <simon.marchi@efficios.com> 19445 19446 gdb: make solib-rocm not use so_list internally 19447 Same rationale as the previous patch, but for solib-rocm. 19448 19449 - Introduce rocm_so, which is a name a unique_name (see comment in 19450 rocm_update_solib_list for that) and a unique_ptr to the 19451 lm_info_svr4. 19452 - Change the internal lists from so_list lists to vectors of rocm_so. 19453 - Remove rocm_free_solib_list, as everything is automatic now. 19454 - Replace rocm_solib_copy_list with so_list_from_rocm_sos. 19455 19456 Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8 19457 Approved-By: Pedro Alves <pedro@palves.net> 19458 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19459 194602023-10-19 Simon Marchi <simon.marchi@efficios.com> 19461 19462 gdb: make solib-svr4 not use so_list internally 19463 A subsequent patch makes use of non-trivial types in struct so_list. 19464 This trips on the fact that svr4_copy_library_list uses memcpy to copy 19465 so_list objects: 19466 19467 so_list *newobj = new so_list; 19468 memcpy (newobj, src, sizeof (struct so_list)); 19469 19470 solib-svr4 maintains lists of so_list objects in its own internal data 19471 structures. When requested to return a list of so_list objects (through 19472 target_so_ops::current_sos), it duplicates the internal so_list lists, 19473 using memcpy. When changing so_list to make it non-trivial, we would 19474 need to replace this use of memcpy somehow. That would mean making 19475 so_list copyable, with all the complexity that entails, just to satisfy 19476 this internal usage of solib-svr4 (and solib-rocm, which does the same). 19477 19478 Change solib-svr4 to use its own data type for its internal lists. The 19479 use of so_list is a bit overkill anyway, as most fields of so_list are 19480 irrelevant for this internal use. 19481 19482 - Introduce svr4_so, which contains just an std::string for the name 19483 and a unique_ptr for the lm_info. 19484 - Change the internal so_list lists to be std::vector<svr4_so>. Vector 19485 seems like a good choice for this, we don't need to insert/remove 19486 elements in the middle of these internal lists. 19487 - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as 19488 everything is managed automatically now. 19489 - Replace svr4_copy_library_list (which duplicated internal lists in 19490 order to return them to the core) with so_list_from_svr4_sos, which 19491 creates an so_list list from a vector of svr4_so. 19492 - Generalize svr4_same a bit, because find_debug_base_for_solib now 19493 needs to compare an so_list and an svr4_so to see if they are the 19494 same. 19495 19496 Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877 19497 Approved-By: Pedro Alves <pedro@palves.net> 19498 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19499 195002023-10-19 Simon Marchi <simon.marchi@efficios.com> 19501 19502 gdb: use gdb::checked_static_cast when casting lm_info 19503 Now that the lm_info class hierarchy has a virtual destructor and 19504 therefore a vtable, use checked_static_cast instead of C-style cases to 19505 ensure (when building in dev mode) that we're casting to the right kind 19506 of lm_info. 19507 19508 Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744 19509 Approved-By: Pedro Alves <pedro@palves.net> 19510 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19511 195122023-10-19 Simon Marchi <simon.marchi@efficios.com> 19513 19514 gdb: remove target_so_ops::free_so 19515 target_so_ops::free_so is responsible for freeing the specific lm_info 19516 object. All implementations basically just call delete. Remove that 19517 method, make the destructor of lm_info virtual, and call delete directly 19518 from the free_so function. Make the sub-classes final, just because 19519 it's good practice. 19520 19521 Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee 19522 Approved-By: Pedro Alves <pedro@palves.net> 19523 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19524 195252023-10-19 Simon Marchi <simon.marchi@efficios.com> 19526 19527 gdb: rename lm_info_base to lm_info 19528 The base class doesn't need to have "_base" in its name, all the 19529 sub-classes have a specific suffix. 19530 19531 Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb 19532 Approved-By: Pedro Alves <pedro@palves.net> 19533 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19534 195352023-10-19 Simon Marchi <simon.marchi@efficios.com> 19536 19537 gdb: allocate so_list with new, deallocate with delete 19538 Initialize all fields in the class declaration, change allocations to 19539 use "new", change deallocations to use "delete". This is needed by a 19540 subsequent patches that use C++ stuff in so_list. 19541 19542 Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222 19543 Approved-By: Pedro Alves <pedro@palves.net> 19544 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19545 195462023-10-19 Simon Marchi <simon.marchi@efficios.com> 19547 19548 gdb: make get_cbfd_soname_build_id static 19549 It is only used in solib.c. 19550 19551 Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b 19552 Approved-By: Pedro Alves <pedro@palves.net> 19553 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19554 195552023-10-19 Simon Marchi <simon.marchi@efficios.com> 19556 19557 gdbsupport: use "reference" and "pointer" type aliases in intrusive_list 19558 It seems to me like the code should used the defined type aliases, for 19559 consistency. 19560 19561 Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9 19562 Approved-By: Pedro Alves <pedro@palves.net> 19563 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19564 195652023-10-19 Simon Marchi <simon.marchi@polymtl.ca> 19566 19567 gdb: replace some so_list parameters to use references 19568 A subsequent patch changes so_list to be linked using 19569 intrusive_list. Iterating an intrusive_list yields some references to 19570 the list elements. Convert some functions accepting so_list objects to 19571 take references, to make things easier and more natural. Add const 19572 where possible and convenient. 19573 19574 Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3 19575 Approved-By: Pedro Alves <pedro@palves.net> 19576 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19577 195782023-10-19 Simon Marchi <simon.marchi@polymtl.ca> 19579 19580 gdb: make interps_notify work with references 19581 A subsequent patch changes the interp::on_solib_loaded and 19582 interp::on_solib_unloaded methods to take references. This highlighted 19583 that interps_notify did not work with reference parameters. 19584 19585 Fix that by changing interps_notify's `args` arg to be a universal 19586 reference (&&). Change the type of the method to be auto-deduced as an 19587 additional template parameter, otherwise the signature of the callback 19588 function would never match: 19589 19590 CXX interps.o 19591 /home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’: 19592 /home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’ 19593 378 | interps_notify (&interp::on_signal_received, sig); 19594 | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19595 /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’ 19596 363 | interps_notify (void (interp::*method) (Args...), Args&&... args) 19597 | ^~~~~~~~~~~~~~ 19598 /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: template argument deduction/substitution failed: 19599 /home/simark/src/binutils-gdb/gdb/interps.c:378:18: note: inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’ 19600 378 | interps_notify (&interp::on_signal_received, sig); 19601 | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19602 19603 Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838 19604 Approved-By: Pedro Alves <pedro@palves.net> 19605 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19606 196072023-10-19 Simon Marchi <simon.marchi@efficios.com> 19608 19609 gdb: add program_space parameter to target_so_ops::clear_solib 19610 The clear_solib is implicitly meant to clear the resources associated to 19611 the current program space (that's what the solib implementations that 19612 actually support multi-program-space / multi-inferior do). Make that 19613 explicit by adding a program_space parameter and pass down 19614 current_program_space in call sites. The implementation of the 19615 clear_solib callbacks is fairly simple, I don't think any of them rely 19616 on global state other than accessing current_program_space. 19617 19618 Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46 19619 Approved-By: Pedro Alves <pedro@palves.net> 19620 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19621 196222023-10-19 Simon Marchi <simon.marchi@efficios.com> 19623 19624 gdb: remove empty clear_solib functions 19625 Make the target_so_ops::clear_solib method optional, remove two empty 19626 implementations. 19627 19628 Change-Id: Ifda297d50c74327d337091c58cdb5b3b60382591 19629 Approved-By: Pedro Alves <pedro@palves.net> 19630 Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19631 196322023-10-19 Nelson Chu <nelson@rivosinc.com> 19633 19634 RISC-V: Don't do undefweak relaxations for the linker_def symbols. 19635 I get the following truncated errors recently when running riscv-gnu-toolchain 19636 regressions, 19637 19638 /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/libc.a(libc-start.o): in function `elf_irela': 19639 /scratch/riscv-gnu-toolchain/glibc/csu/../sysdeps/riscv/dl-irel.h:47:(.text+0x88): relocation truncated to fit: R_RISCV_GPREL_I against symbol `__ehdr_start' defined in .note.ABI-tag section in /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/elf/sln 19640 19641 The linker_def symbols like __ehdr_start that may be undefweak in early stages 19642 of linking, including relax stage, but are guaranteed to be defined later. 19643 Therefore, it seems like we shouldn't do the undefweak relaxations for these 19644 kinds of symbols since they may be defined after relaxations. 19645 19646 bfd/ 19647 * elfnn-riscv.c (_bfd_riscv_relax_section): Don't do undefweak 19648 relaxations for the linker_def symbols. 19649 196502023-10-19 Tsukasa OI <research_trasio@irq.a4lg.com> 19651 19652 RISC-V: Remove semicolons from DECLARE_INSN 19653 This is for consistency and to prevent possible unnecessary errors due 19654 to this inconsistency. 19655 19656 include/ChangeLog: 19657 19658 * opcode/riscv-opc.h (DECLARE_INSN): Remove semicolons from the 19659 end of each entry. 19660 196612023-10-19 GDB Administrator <gdbadmin@sourceware.org> 19662 19663 Automatic date update in version.in 19664 196652023-10-18 Lancelot Six <lancelot.six@amd.com> 19666 19667 gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp 19668 The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread" 19669 command, but this is incorrect. If "continue" is given an argument, it 19670 sets the ignore count of the breakpoint the thread stopped at. 19671 19672 For this testcase it does not really matter since the breakpoint is not 19673 meant to be hit anymore, so whatever the ignore count is won't influence 19674 the outcome of the test. It is worth fixing nevertheless. 19675 19676 Change-Id: I0eb674d5529cdeb9e808b74870a29b6077265737 19677 Approved-By: Simon Marchi <simon.marchi@efficios.com> 19678 196792023-10-18 Jaydeep Patil <Jaydeep.Patil@imgtec.com> 19680 19681 sim/riscv: fix JALR instruction simulation 19682 Fix 32bit 'jalr rd,ra,imm' integer instruction, where RD was written 19683 before using it to calculate destination address. 19684 19685 This commit also improves testutils.inc for riscv; make use of 19686 pushsection and popsection when adding things to .data, and setup the 19687 %gp global pointer register within the 'start' macro. 19688 19689 Approved-By: Andrew Burgess <aburgess@redhat.com> 19690 196912023-10-18 Nick Alcock <nick.alcock@oracle.com> 19692 19693 libctf: check for problems with error returns 19694 We do this as a writable test because the only known-affected platforms 19695 (with ssize_t longer than unsigned long) use PE, and we do not have support 19696 for CTF linkage in the PE linker yet. 19697 19698 PR libctf/30836 19699 * libctf/testsuite/libctf-writable/libctf-errors.*: New test. 19700 197012023-10-18 Lancelot Six <lancelot.six@amd.com> 19702 19703 gdb/testsuite/gdb.rocm: Check value returned by hipDeviceSynchronize 19704 Functions of the hip runtime returning a hipError_t can be marked 19705 nodiscard depending on the configuration[1] (when compiled with C++17). 19706 19707 This patch makes sure that we always check the value returned by 19708 hipDeviceSynchronize and friends, and print an error message when 19709 appropriate. This avoid a wall of warnings when running the testsuite 19710 if the compiler defaults to using C++17. 19711 19712 It is always a good practice to check the return values anyway. 19713 19714 [1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218 19715 19716 Change-Id: I2a819a8ac45f4bcf814efe9a2ff12c6a7ad22f97 19717 Approved-By: Simon Marchi <simon.marchi@efficios.com> 19718 197192023-10-18 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 19720 19721 libctf: Return CTF_ERR in ctf_type_resolve_unsliced PR 30836 19722 In commit 998a4f589d68503f79695f180fdf1742eeb0a39d, all but one return 19723 statement was updated to return the error proper value. This commit 19724 rectifies that missed return statement. 19725 19726 libctf/ 19727 ctf-types.c (ctf_type_resolve_unsliced): Return CTF_ERR on error. 19728 197292023-10-18 Tom de Vries <tdevries@suse.de> 19730 19731 [gdb/testsuite] Fix gdb.base/jit-bfd-name.exp 19732 When running test-case gdb.base/jit-bfd-name.exp, I run into: 19733 ... 19734 ERROR: tcl error sourcing gdb/testsuite/gdb.base/jit-bfd-name.exp. 19735 ERROR: can't read "start": no such variable 19736 ... 19737 19738 The problem is that commit c96ceed9dce ("gdb: include the end address in 19739 in-memory bfd filenames") introduced a use of variable start, but not a 19740 definition. 19741 19742 Fix this by adding the missing definition. 19743 19744 Tested on x86_64-linux. 19745 197462023-10-18 Tom de Vries <tdevries@suse.de> 19747 19748 [gdb/symtab] Fix two style issues in gdb/dwarf2/index-write.c 19749 While reviewing gdb/dwarf2/index-write.c I noticed two style issues. 19750 19751 Fix these. 19752 19753 Tested on x86_64-linux. 19754 19755 Approved-By: Tom Tromey <tom@tromey.com> 19756 197572023-10-18 Tom de Vries <tdevries@suse.de> 19758 19759 [gdb/symtab] Fix style issues in v9 .gdb_index section support 19760 Post-commit review pointed out a few style issues in commit 8b9c08eddac 19761 ("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index"). 19762 19763 Fix these. 19764 19765 Tested on x86_64-linux. 19766 19767 Reported-By: Tom Tromey <tom@tromey.com> 19768 Approved-By: Tom Tromey <tom@tromey.com> 19769 197702023-10-18 Nelson Chu <nelson@rivosinc.com> 19771 19772 RISC-V: Make sure rv32q conflict won't affect the zfa gas testcases. 19773 According to the commit 51498ab9abc6, the q extension was no longer allowed 19774 for rv32 since version 2.2. Therefore, make sure the version of q is larger 19775 than 2.2, in case the new extension conflict breaks the toolchain regressions, 19776 which built with the old -misa-spec. 19777 19778 gas/ 19779 * testsuite/gas/riscv/zfa-zvfh.d: Set q to v2.2. 19780 * testsuite/gas/riscv/zfa.d: Likewise. 19781 197822023-10-18 caiyinyu <caiyinyu@loongson.cn> 19783 19784 LoongArch: Correct comments. 19785 197862023-10-18 GDB Administrator <gdbadmin@sourceware.org> 19787 19788 Automatic date update in version.in 19789 197902023-10-17 Neal Frager <neal.frager@amd.com> 19791 19792 gas: testsuite: microblaze: Add new bit-field tests 19793 This patch adds new gas tests for the 19794 microblaze bsefi and bsifi instructions. 19795 197962023-10-17 Markus Metzger <markus.t.metzger@intel.com> 19797 19798 gdb: include the end address in in-memory bfd filenames 19799 Commit 19800 19801 66984afd29e gdb: include the base address in in-memory bfd filenames 19802 19803 added the base address to in-memory bfd filenames. Also add the end 19804 address to allow dumping the in-memory bfd using the 'dump memory' 19805 command. 19806 198072023-10-17 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 19808 19809 libctf: Sanitize error types for PR 30836 19810 Made sure there is no implicit conversion between signed and unsigned 19811 return value for functions setting the ctf_errno value. 19812 An example of the problem is that in ctf_member_next, the "offset" value 19813 is either 0L or (ctf_id_t)-1L, but it should have been 0L or -1L. 19814 The issue was discovered while building a 64 bit ld binary to be 19815 executed on the Windows platform. 19816 Example object file that demonstrates the issue is attached in the PR. 19817 19818 libctf/ 19819 Affected functions adjusted. 19820 19821 Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com> 19822 198232023-10-17 Nick Clifton <nickc@redhat.com> 19824 19825 Update the documentation of the LINKER_VERSIOn script command to actually mention the name of the command. 19826 198272023-10-17 Tom de Vries <tdevries@suse.de> 19828 19829 [gdb/cli] Keep track of styling failures in source_cache 19830 In source_cache::ensure, keep track of which files failed to be styled, and 19831 don't attempt to style them again in case the file dropped out of the cache. 19832 19833 Tested on x86_64-linux. 19834 19835 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19836 198372023-10-17 Tom de Vries <tdevries@suse.de> 19838 19839 [gdb/cli] Factor out try_source_highlight 19840 Function source_cache::ensure contains some code using the GNU 19841 source-highlight library. 19842 19843 The code is a sizable part of the function, and contains conditional 19844 compilation in a slightly convoluted way: 19845 ... 19846 if (!already_styled) 19847 #endif /* HAVE_SOURCE_HIGHLIGHT */ 19848 { 19849 ... 19850 19851 Fix this by factoring out the code into new function try_source_highlight, 19852 such that: 19853 - source_cache::ensure is easier to read, and 19854 - the conditional compilation is at the level of the function body. 19855 19856 Tested on x86_64-linux. 19857 19858 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19859 198602023-10-17 Tom de Vries <tdevries@suse.de> 19861 19862 [gdb/cli] Skip string copy in source_cache::ensure 19863 In function source_cache::ensure we have: 19864 ... 19865 std::ostringstream output; 19866 ... 19867 contents = output.str (); 19868 ... 19869 The last line causes an unnecessary string copy. 19870 19871 C++20 allows us to skip it, like this: 19872 ... 19873 contents = std::move (output).str (); 19874 ... 19875 19876 Use the more efficient solution. 19877 19878 Tested on x86_64-linux. 19879 19880 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 19881 198822023-10-17 mengqinggang <mengqinggang@loongson.cn> 19883 19884 LoongArch: readelf -d RELASZ excludes .rela.plt size 19885 Before, readelf -d RELASZ is the sum of .rela.dyn size and .rela.plt size. 19886 To consistent with LoongArch lld, RELASZ chang to only the size of .rela.dyn. 19887 198882023-10-17 Alan Modra <amodra@gmail.com> 19889 19890 asan: Invalid free in alpha_ecoff_get_relocated_section_contents 19891 This fixes an ancient bug in commit a3a33af390 (which makes me think 19892 this code has never been used). 19893 19894 * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Iterate 19895 through reloc_vector using a temp. 19896 198972023-10-17 Tsukasa OI <research_trasio@irq.a4lg.com> 19898 19899 RISC-V: Fix typo 19900 include/ChangeLog: 19901 19902 * opcode/riscv-opc.h: Fix typo. 19903 199042023-10-17 John Baldwin <jhb@FreeBSD.org> 19905 19906 nat/x86-cpuid.h: Remove non-x86 fallbacks 19907 This header is only suitable for use on x86 hosts and is only included 19908 there, so these fallbacks should not be needed. 19909 19910 Approved-By: Simon Marchi <simon.marchi@efficios.com> 19911 199122023-10-17 GDB Administrator <gdbadmin@sourceware.org> 19913 19914 Automatic date update in version.in 19915 199162023-10-16 Simon Marchi <simon.marchi@efficios.com> 19917 19918 gdb: remove unnecessary declarations in target.c 19919 I found that these local declarations were not needed, remove them. 19920 Tested by rebuilding. 19921 19922 Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22 19923 199242023-10-16 Tom Tromey <tromey@adacore.com> 19925 19926 Have DAP handle non-Value results from 'children' 19927 A pretty-printer's 'children' method may return values other than a 19928 gdb.Value -- it may return any value that can be converted to a 19929 gdb.Value. 19930 19931 I noticed that this case did not work for DAP. This patch fixes the 19932 problem. 19933 199342023-10-16 Tom Tromey <tromey@adacore.com> 19935 19936 Handle gdb.LazyString in DAP 19937 Andry pointed out that the DAP code did not properly handle 19938 gdb.LazyString results from a pretty-printer, yielding: 19939 19940 TypeError: Object of type LazyString is not JSON serializable 19941 19942 This patch fixes the problem, partly with a small patch in varref.py, 19943 but mainly by implementing tp_str for LazyString. 19944 19945 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 19946 199472023-10-16 Tom Tromey <tromey@adacore.com> 19948 19949 Fix register-setting response from DAP 19950 Andry noticed that given a DAP setExpression request, where the 19951 expression to set is a register, DAP will return the wrong value -- it 19952 will return the old value, not the updated one. 19953 19954 This happens because gdb.Value.assign (which was recently added for 19955 DAP) does not update the value. 19956 19957 In this patch, I chose to have the assign method update the Value 19958 in-place. It's also possible to have it return a new value, but this 19959 didn't seem very useful to me. 19960 199612023-10-16 Nick Clifton <nickc@redhat.com> 19962 19963 Fix: GNU-ld: ARM: Issues when trying to set target output architecture 19964 PR 28910 19965 * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set. 19966 19967 Fix: GNU-ld: ARM: Issues when trying to set target output architecture 19968 PR 28910 19969 * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option. 19970 199712023-10-16 Tom Tromey <tromey@adacore.com> 19972 19973 Add DAP scope cache 19974 Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests 19975 with the same frame would yield different variableReference values in 19976 the response. 19977 19978 This patch adds a regression test for this, and adds a scope cache in 19979 scopes.py, ensuring that multiple identical requests will get the same 19980 response. 19981 19982 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 19983 199842023-10-16 Tom de Vries <tdevries@suse.de> 19985 19986 [gdb/symtab] Work around PR gas/29517 19987 When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517: 19988 ... 19989 $ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")" 19990 Temporary breakpoint 1 at 0x40051b: file hello.c, line 6. 19991 19992 Temporary breakpoint 1, main () at hello.c:6 19993 6 printf ("hello\n"); 19994 Invalid cast. 19995 ... 19996 while without glibc debuginfo installed we get the expected result: 19997 ... 19998 $n = 0x7ffff7daa1b1 "aha" 19999 ... 20000 and likewise with glibc debuginfo generated with gas 2.40. 20001 20002 The strstr ifunc resolves to __strstr_sse2_unaligned. The problem is that gas 20003 generates dwarf that states that the return type is void: 20004 ... 20005 <1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram) 20006 <3e1e59> DW_AT_name : __strstr_sse2_unaligned 20007 <3e1e5d> DW_AT_external : 1 20008 <3e1e5e> DW_AT_low_pc : 0xbbd2e 20009 <3e1e66> DW_AT_high_pc : 0xbc1c3 20010 ... 20011 while the return type should be a DW_TAG_unspecified_type, as is the case 20012 with gas 2.40. 20013 20014 We can still use the workaround of casting to another function type for both 20015 __strstr_sse2_unaligned: 20016 ... 20017 (gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \ 20018 ("haha", "ah") 20019 $n = 0x7ffff7daa211 "aha" 20020 ... 20021 and strstr (which requires using *strstr to dereference the ifunc before we 20022 cast): 20023 ... 20024 gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah") 20025 $n = 0x7ffff7daa251 "aha" 20026 ... 20027 but that's a bit cumbersome to use. 20028 20029 Work around this in the dwarf reader, such that we have instead: 20030 ... 20031 (gdb) p (char *)strstr ("haha", "ah") 20032 $n = 0x7ffff7daa1b1 "aha" 20033 ... 20034 20035 This also requires fixing producer_is_gcc to stop returning true for 20036 producer "GNU AS 2.39.0". 20037 20038 Tested on x86_64-linux. 20039 20040 Approved-By: Andrew Burgess <aburgess@redhat.com> 20041 20042 PR symtab/30911 20043 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911 20044 200452023-10-16 Luis Machado <luis.machado@arm.com> 20046 20047 Only allow closure lookup by address if there are threads displaced-stepping 20048 Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in 20049 displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure 20050 is available whenever we have a match between the provided address argument and 20051 the buffer address. 20052 20053 That is fine, but the report in PR30872 shows this assertion triggering when 20054 it really shouldn't. After some investigation, here's what I found out. 20055 20056 The 32-bit Arm architecture is the only one that calls 20057 gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because 20058 32-bit Arm needs to figure out the thumb state of the original instruction 20059 that we displaced-stepped through the displaced-step buffer. 20060 20061 Before the assertion was put in place by commit 20062 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of 20063 getting nullptr back, which meant we were not doing a displaced-stepping 20064 operation. 20065 20066 Now, with the assertion in place, this is running into issues. 20067 20068 It looks like displaced_step_buffers::copy_insn_closure_by_addr is 20069 being used to return a couple different answers depending on the 20070 state we're in: 20071 20072 1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr 20073 is supposed to return a valid closure for us, so we can determine the 20074 thumb mode. 20075 20076 2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr 20077 should return nullptr to signal that there isn't any displaced-step buffers 20078 in use, because we don't have a valid closure (but we should always have 20079 this). 20080 20081 Since the displaced-step buffers are always allocated, but not always used, 20082 that means the buffers will always contain data. In particular, the buffer 20083 addr field cannot be used to determine if the buffer is active or not. 20084 20085 For instance, we cannot set the buffer addr field to 0x0, as that can be a 20086 valid PC in some cases. 20087 20088 My understanding is that the current_thread field should be a good candidate 20089 to signal that a particular displaced-step buffer is active or not. If it is 20090 nullptr, we have no threads using that buffer to displaced-step. Otherwise, 20091 it is an active buffer in use by a particular thread. 20092 20093 The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr 20094 function so we only attempt to return a closure if the buffer has an assigned 20095 current_thread and if the buffer address matches the address argument. 20096 20097 Alternatively, I think we could use a function to answer the question of 20098 whether we're actively displaced-stepping (so we have an active buffer) or 20099 not. 20100 20101 I've also added a testcase that exercises the problem. It should reproduce 20102 reliably on Arm, as that is the only architecture that faces this problem 20103 at the moment. 20104 20105 Regression-tested on Ubuntu 20.04. OK? 20106 20107 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872 20108 Approved-By: Simon Marchi <simon.marchi@efficios.com> 20109 201102023-10-16 Andrew Burgess <aburgess@redhat.com> 20111 20112 gdb: replace architecture_changed with new_architecture observer 20113 This commit replaces the architecture_changed observer with a 20114 new_architecture observer. 20115 20116 Currently the only user of the architecture_changed observer is the 20117 Python code, which uses this observer to register the Python unwinder 20118 with the architecture. 20119 20120 The problem is that the architecture_changed observer is triggered 20121 from inferior::set_arch(), which only sees the inferior-wide gdbarch 20122 value. For targets that use thread-specific architectures, these 20123 never trigger the architecture_changed observer, and so never have the 20124 Python unwinder registered with them. 20125 20126 When it comes to unwinding GDB makes use of the frame's gdbarch, which 20127 is based on the thread's regcache gdbarch, which is set in 20128 get_thread_regcache to the value returned from 20129 target_thread_architecture, which is not always the inferiors gdbarch 20130 value, it might be a thread-specific gdbarch which has not passed 20131 through inferior::set_arch(). 20132 20133 The new_architecture observer will be triggered from 20134 gdbarch_find_by_info, whenever a new gdbarch is created and 20135 initialised. As GDB caches and reuses gdbarch values, we should 20136 expect to see each new architecture trigger the new_architecture 20137 observer just once. 20138 20139 After this commit, targets that make use of thread-specific 20140 architectures should be able to make use of Python unwinders. 20141 20142 As I don't have access to a machine that makes use of thread-specific 20143 architectures right now, I asked Luis to confirm that an AArch64 20144 target that uses SVE/SME can't use the Python unwinders in threads 20145 that are using a thread-specific architectures, and he confirmed that 20146 this is indeed the case, see this discussion: 20147 20148 https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com 20149 20150 Tested-By: Lancelot Six <lancelot.six@amd.com> 20151 Tested-By: Luis Machado <luis.machado@arm.com> 20152 Reviewed-By: Luis Machado <luis.machado@arm.com> 20153 Approved-By: Simon Marchi <simon.marchi@efficios.com> 20154 201552023-10-16 Clément Chigot <chigot@adacore.com> 20156 20157 objcopy: Fix name of the field modified by pe_stack_reserve. 20158 201592023-10-16 Tsukasa OI <research_trasio@irq.a4lg.com> 20160 20161 RISC-V: Add "lp64e" ABI support 20162 Since RV32E and RV64E are now ratified, this commit prepares the ABI 20163 support for LP64E (LP64 with reduced GPRs). 20164 20165 gas/ChangeLog: 20166 20167 * config/tc-riscv.c (riscv_set_abi_by_arch): Update the error 20168 message. (md_parse_option): Accept "lp64e". 20169 * doc/c-riscv.texi: Update the documentation to allow "lp64e". 20170 * testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l: 20171 Change error message. 20172 * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise. 20173 * testsuite/gas/riscv/mabi-fail-rv32e-lp64q.l: Likewise. 20174 201752023-10-16 Tsukasa OI <research_trasio@irq.a4lg.com> 20176 20177 RISC-V: Remove RV64E conflict 20178 Since RV32E *and* RV64E are ratified, RV64E is no longer invalid. 20179 20180 This commit removes a restriction that prevents making base ISA with 20181 reduced GPRs with XLEN > 32. 20182 20183 bfd/ChangeLog: 20184 20185 * elfxx-riscv.c (riscv_parse_check_conflicts): Remove RV64E 20186 conflict since the ratified 'E' base ISAs include RV64E. 20187 20188 gas/ChangeLog: 20189 20190 * testsuite/gas/riscv/march-fail-base-02.d: Removed. 20191 * testsuite/gas/riscv/march-fail-base-02.l: Removed. 20192 201932023-10-16 GDB Administrator <gdbadmin@sourceware.org> 20194 20195 Automatic date update in version.in 20196 201972023-10-15 Mike Frysinger <vapier@gentoo.org> 20198 20199 sim: add distclean dep for gnulib 20200 202012023-10-15 Neal Frager <neal.frager@amd.com> 20202 20203 opcodes: microblaze: Add new bit-field instructions 20204 This patches adds new bsefi and bsifi instructions. 20205 BSEFI- The instruction shall extract a bit field from a 20206 register and place it right-adjusted in the destination register. 20207 The other bits in the destination register shall be set to zero. 20208 BSIFI- The instruction shall insert a right-adjusted bit field 20209 from a register at another position in the destination register. 20210 The rest of the bits in the destination register shall be unchanged. 20211 20212 Further documentation of these instructions can be found here: 20213 https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref 20214 20215 With version 6 of the patch, no new relocation types are added as 20216 this was unnecessary for adding the bsefi and bsifi instructions. 20217 20218 FIXED: Segfault caused by incorrect termination of microblaze_opcodes. 20219 202202023-10-15 Mike Frysinger <vapier@gentoo.org> 20221 20222 sim: mips: fix printf string 20223 202242023-10-15 GDB Administrator <gdbadmin@sourceware.org> 20225 20226 Automatic date update in version.in 20227 202282023-10-14 GDB Administrator <gdbadmin@sourceware.org> 20229 20230 Automatic date update in version.in 20231 202322023-10-13 Luis Machado <luis.machado@arm.com> 20233 20234 [aarch64] Use SVE_VQ_BYTES instead of __SVE_VQ_BYTES 20235 __SVE_VQ_BYTES is only available if SVE definitions are available in 20236 the system's headers, and this is not true for all systems. 20237 20238 For this purpose, we define SVE_VQ_BYTES. This patch fixes the 20239 name of the constant being used. 20240 202412023-10-13 Clément Chigot <chigot@adacore.com> 20242 20243 ld: replace wrong bfd_malloc in nto.em 20244 xmalloc should be called in ld instead of bfd_malloc. 20245 20246 ld/ChangeLog: 20247 20248 * emultempl/nto.em (nto_lookup_QNX_note_section): Replace 20249 bfd_malloc by xmalloc. 20250 202512023-10-13 Clément Chigot <chigot@adacore.com> 20252 20253 ld: warn when duplicated QNX stack note are detected 20254 This warning is triggered only when a stack parameter is given to 20255 the linker. 20256 20257 ld/ChangeLog: 20258 20259 * emultempl/nto.em: Add warning when several QNX .note are 20260 detected. 20261 202622023-10-13 Clément Chigot <chigot@adacore.com> 20263 20264 ld: correctly handle QNX --lazy-stack without -zstack-size 20265 The warning was skipped if -zstack-size is not provided. 20266 20267 ld/ChangeLog: 20268 20269 * emultempl/nto.em: Move --lazy-stack warning before missing 20270 -zstack-size skip. 20271 202722023-10-13 Clément Chigot <chigot@adacore.com> 20273 20274 ld: allow update of existing QNX stack note 20275 Up to now, the linker would always create a QNX stack note from scratch. 20276 However, object files could already have such note, ending up into 20277 duplicates. QNX loader doesn't handle that. 20278 20279 Update the mechanism to first search through the input files for a .note 20280 section holding a QNX stack note. If none are found, then a new section 20281 is created into the stub file as before. This requires this search to be 20282 done once the file have been opened, moving the whole logic a bit later 20283 in the emulation process. 20284 20285 As part for this update, also allow to request an executable stack 20286 without necessarily having to provide its size as well. In this case, s 20287 etup a default lazy stack of 0x1000. 20288 20289 ld/ChangeLog: 20290 20291 * emultempl/nto.em (nto_create_QNX_note_section): New Function. 20292 (nto_lookup_QNX_note_section): New Function. 20293 (nto_add_note_section): Move the creation of the note section 20294 in the above new functions. 20295 (nto_create_output_section_statements): rename nto_after_open 20296 * testsuite/ld-aarch64/aarch64-nto.exp: add new test. 20297 * testsuite/ld-aarch64/nto-stack-note-3.d: New test. 20298 * testsuite/ld-aarch64/nto-stack-note.s: New test. 20299 203002023-10-13 Joseph Faulls <Joseph.Faulls@imgtec.com> 20301 20302 RISC-V: Add support for numbered ISA mapping strings 20303 The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any> 20304 20305 opcodes/ 20306 * riscv-dis.c (riscv_get_map_state): allow mapping symbol to 20307 be suffixed by a unique identifier .<any> 20308 203092023-10-13 Tom Tromey <tom@tromey.com> 20310 20311 Move -lsocket check to common.m4 20312 A user pointed out that the -lsocket check in gdb should also apply to 20313 gdbserver -- otherwise it can't find the Solaris socketpair. This 20314 patch makes the change. It also removes a couple of redundant 20315 function checks from gdb's configure.ac. 20316 20317 This was tested by the person who reported the bug. 20318 20319 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927 20320 Approved-By: Pedro Alves <pedro@palves.net> 20321 203222023-10-13 GDB Administrator <gdbadmin@sourceware.org> 20323 20324 Automatic date update in version.in 20325 203262023-10-12 Tom Tromey <tromey@adacore.com> 20327 20328 Fix test suite failure in file-then-restart.exp 20329 Simon pointed out that the new file-then-restart.exp test fails with 20330 the extended-remote target board. 20331 20332 The problem is that the test suite doesn't use gdb_file_cmd -- which 20333 handles things like "set remote exec-file". This patch changes 20334 gdb_file_cmd to make the "kill" command optional, and then switches 20335 the test case to use it. 20336 20337 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933 20338 Approved-By: Simon Marchi <simon.marchi@efficios.com> 20339 203402023-10-12 Andrew Burgess <aburgess@redhat.com> 20341 20342 bfd: add new bfd_cache_size() function 20343 In GDB we have a problem with the BFD cache. 20344 20345 As GDB runs for a potentially extended period of time, if the BFD 20346 cache holds a file descriptor for an open on-disk file, this can, on 20347 some targets (e.g. Win32) prevent the OS writing to the file. 20348 20349 This might, for example, prevent a user from recompiling their 20350 executable as GDB is (via the BFD cache) holding an open reference to 20351 that file. 20352 20353 Another problem, relates to bfd_stat, for BFDs that are using the BFD 20354 cache (i.e. they call cache_bstat to implement bfd_stat). The 20355 cache_bstat function finds the BFD in the cache, opening the file if 20356 needed, and then uses fstat on the open file descriptor. 20357 20358 What this means is that, if the on-disk file changes, but the cache 20359 was holding an open reference to the file, the bfd_stat will return 20360 the 'struct stat' for the old file, not the new file. 20361 20362 Now, for this second problem, we might be tempted to make use of an 20363 actual stat call, instead of calling bfd_stat, however, this isn't 20364 ideal as we have some BFDs that use a custom iovec, and implement the 20365 various functions over GDB's remote protocol. By using bfd_stat we 20366 can have a single call that should work for both local files, and for 20367 remote files. 20368 20369 To solve both of these problems GDB has calls to bfd_cache_close_all 20370 sprinkled around its code base. And in theory this should work fine. 20371 20372 However, I recently ran into a case where we had missed a 20373 bfd_cache_close_all call, and as a result some BFDs were held open. 20374 This caused a bfd_stat call to return an unexpected result (old file 20375 vs new file). 20376 20377 What I'd like is some way within GDB that I can do: 20378 20379 gdb_assert ( /* Nothing is held open in the cache. */ ); 20380 20381 As this would allow GDB to quickly identify when we've missed some 20382 bfd_cache_close_all calls. 20383 20384 And so, to support this, I would like to add a new bfd_cache_size 20385 function. This function returns an integer, which is the number of 20386 open files in the cache. I can then start adding: 20387 20388 gdb_assert (bfd_cache_size() == 0); 20389 20390 to GDB in some strategic spots, and start fixing all of the missing 20391 bfd_cache_close_all calls that crop up as a result. 20392 203932023-10-12 Andrew Burgess <aburgess@redhat.com> 20394 20395 bfd/cache: change type used to track cached BFDs from int to unsigned 20396 Within bfd/cache.c change the type for max_open_files and open_files 20397 variables from int to unsigned. As a consequence of this, the return 20398 type for bfd_cache_max_open() is also changed from int to unsigned. 20399 20400 Within bfd_cache_max_open I've left the local 'max' variable as an 20401 int, this should ensure that if the sysconf call fails, and returns 20402 -1, then the computed max value will be less than 10, which means 20403 max_open_files will be set to 10. If 'max' was changed to unsigned 20404 then, should the sysconf call fail, we'd end up with max becoming a 20405 very large positive number ... which is clearly not what we want. 20406 20407 And, while I was auditing how open_files is used, I added an assert 20408 within bfd_cache_delete to ensure that we don't try to reduce 20409 open_files below zero. 20410 20411 There should be no user visible change with this commit. 20412 204132023-10-12 GDB Administrator <gdbadmin@sourceware.org> 20414 20415 Automatic date update in version.in 20416 204172023-10-11 Jeff Law <jlaw@ventanamicro.com> 20418 20419 [RFA] Fix for mcore simulator 20420 I was looking for cases where a GCC patch under evaluation would cause test 20421 results to change. Quite surprisingly the mcore-elf port showed test 20422 differences. After a fair amount of digging my conclusion was the sequences 20423 before/after the patch should have been semantically the same. 20424 20425 Of course if the code is supposed to behave the same, then that points to 20426 problems elsewhere (assembler, linker, simulator). Sure enough the mcore 20427 simulator was mis-handling the sign extension instructions. The simulator 20428 implementation of sextb is via paired shift-by-24 operations. Similarly the 20429 simulator implements sexth via paired shift-by-16 operations. 20430 20431 The temporary holding the value was declared as a "long" thus this approach 20432 worked fine for hosts with a 32 bit wide long and failed miserably for hosts 20433 with a 64 bit wide long. 20434 20435 This patch makes the shift count automatically adjust based on the size of the 20436 temporary. It includes a simple test for sextb and sexth. I have _not_ done a 20437 full audit of the mcore simulator for more 32->64 bit issues. 20438 20439 This also fixes 443 execution tests in the GCC testsuite 20440 204412023-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 20442 20443 gprofng: Use the correct application name in error messages 20444 The old application name (er_archive) is used in many places. 20445 20446 gprofng/ChangeLog 20447 2023-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 20448 20449 * src/Experiment.cc: Replace er_archive with gp-archive. 20450 * src/Experiment.cc: Likewise. 20451 204522023-10-11 GDB Administrator <gdbadmin@sourceware.org> 20453 20454 Automatic date update in version.in 20455 204562023-10-10 Hui Li <lihui@loongson.cn> 20457 20458 gdb: LoongArch: Handle special struct in dummy call 20459 When execute the following command on LoongArch: 20460 20461 make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp" 20462 20463 there exist some failed testcases: 20464 20465 === gdb Summary === 20466 20467 # of expected passes 5533 20468 # of unexpected failures 367 20469 20470 The root cause is related with a struct containing floating-point 20471 members as function argument or return value for a dummy call. 20472 20473 (1) Structure consists of one floating-point member within FRLEN bits 20474 wide, it is passed in an FAR if available. 20475 (2) Structure consists of two floating-point members both within FRLEN 20476 bits wide, it is passed in two FARs if available. 20477 (3) Structure consists of one integer member within GRLEN bits wide and 20478 one floating-point member within FRLEN bits wide, it is passed in a 20479 GAR and an FAR if available. 20480 20481 Note that in the above cases, empty structure or union members are also 20482 ignored even in C++. 20483 20484 Here is a simple test on LoongArch: 20485 20486 loongson@bogon:~$ cat test.c 20487 20488 #include<stdio.h> 20489 20490 struct test { 20491 long a; 20492 double b __attribute__((aligned(16))); 20493 }; 20494 struct test val = { 88, 99.99 }; 20495 int check_arg_struct (struct test arg) 20496 { 20497 printf("arg.a = %ld\n", arg.a); 20498 printf("arg.b = %f\n", arg.b); 20499 printf("sizeof(val) = %d\n", sizeof(val)); 20500 return 1; 20501 } 20502 int main() 20503 { 20504 check_arg_struct (val); 20505 return 0; 20506 } 20507 loongson@bogon:~$ gcc -g test.c -o test 20508 loongson@bogon:~$ ./test 20509 arg.a = 88 20510 arg.b = 99.990000 20511 sizeof(val) = 32 20512 20513 Before: 20514 20515 loongson@bogon:~$ gdb test 20516 ... 20517 (gdb) start 20518 ... 20519 Temporary breakpoint 1, main () at test.c:19 20520 19 check_arg_struct (val); 20521 (gdb) p check_arg_struct (val) 20522 arg.a = 140737488286128 20523 arg.b = -nan 20524 sizeof(val) = 32 20525 $1 = 1 20526 ... 20527 20528 After: 20529 20530 loongson@bogon:~$ gdb test 20531 ... 20532 (gdb) start 20533 ... 20534 Temporary breakpoint 1, main () at test.c:19 20535 19 check_arg_struct (val); 20536 (gdb) p check_arg_struct (val) 20537 arg.a = 88 20538 arg.b = 99.990000 20539 sizeof(val) = 32 20540 $1 = 1 20541 ... 20542 20543 With this patch, there are no failed testcases: 20544 20545 make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp" 20546 20547 === gdb Summary === 20548 20549 # of expected passes 5900 20550 205512023-10-10 Simon Marchi <simon.marchi@efficios.com> 20552 20553 gdb: add assertion when marking the remote async flag 20554 As reported in bug 30630 [1], we hit a case where the remote target's 20555 async flag is marked while the target is not configured (yet) to work 20556 async. This should not happen. It is caught thanks to this assert in 20557 remote_target::wait: 20558 20559 /* Start by clearing the flag that asks for our wait method to be called, 20560 we'll mark it again at the end if needed. If the target is not in 20561 async mode then the async token should not be marked. */ 20562 if (target_is_async_p ()) 20563 rs->clear_async_event_handler (); 20564 else 20565 gdb_assert (!rs->async_event_handler_marked ()); 20566 20567 This is helpful, but I think that we could have caught the problem earlier than 20568 that, at the moment we marked the handler. Catching problems earlier 20569 makes them easier to debug. 20570 20571 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630 20572 20573 Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833 20574 Approved-By: Andrew Burgess <aburgess@redhat.com> 20575 205762023-10-10 Simon Marchi <simon.marchi@efficios.com> 20577 20578 gdb: add remote_state::{is_async_p,can_async_p} 20579 A subsequent patch will want to know if the remote is async within a 20580 remote_state method. Add a helper method for that, and for "can async" 20581 as well, for symmetry. 20582 20583 Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352 20584 Approved-By: Andrew Burgess <aburgess@redhat.com> 20585 205862023-10-10 Simon Marchi <simon.marchi@efficios.com> 20587 20588 gdb: make remote_state's async token private 20589 Make remote_async_inferior_event_token private (rename to 20590 m_async_event_handler_token) and add methods for the various operations 20591 we do on it. This will help by: 20592 20593 - allowing to break on those methods when debugging 20594 - allowing to add assertions in the methods 20595 20596 Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d 20597 Approved-By: Andrew Burgess <aburgess@redhat.com> 20598 205992023-10-10 Simon Marchi <simon.marchi@efficios.com> 20600 20601 gdb: remove trailing whitespaces in remote.c 20602 Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a 20603 206042023-10-10 Simon Marchi <simon.marchi@efficios.com> 20605 20606 gdb: scope down registers_changed call in inferior::set_arch 20607 inferior::set_arch calls registers_changed, which invalidates all 20608 regcaches. It would be enough to invalidate only regcaches of threads 20609 belonging to this inferior. Call registers_changed_ptid instead, with 20610 the proper process target / ptid. If the inferior does not have a 20611 process target, there should be no regcaches for that inferior, so no 20612 need to invalidate anything. 20613 20614 Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882 20615 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 20616 Approved-By: Andrew Burgess <aburgess@redhat.com> 20617 206182023-10-10 Simon Marchi <simon.marchi@efficios.com> 20619 20620 gdb: remove target_gdbarch 20621 This function is just a wrapper around the current inferior's gdbarch. 20622 I find that having that wrapper just obscures where the arch is coming 20623 from, and that it's often used as "I don't know which arch to use so 20624 I'll use this magical target_gdbarch function that gets me an arch" when 20625 the arch should in fact come from something in the context (a thread, 20626 objfile, symbol, etc). I think that removing it and inlining 20627 `current_inferior ()->arch ()` everywhere will make it a bit clearer 20628 where that arch comes from and will trigger people into reflecting 20629 whether this is the right place to get the arch or not. 20630 20631 Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b 20632 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 20633 Approved-By: Andrew Burgess <aburgess@redhat.com> 20634 206352023-10-10 Simon Marchi <simon.marchi@efficios.com> 20636 20637 gdb: move set_target_gdbarch to inferior::set_arch 20638 set_target_gdbarch is basically a setter for the current inferior's 20639 arch, that notifies other parts of GDB of the architecture change. Move 20640 the code of set_target_gdbarch to the inferior::set_arch method. 20641 20642 Add gdbarch_initialized_p, so we can keep the assertion. 20643 20644 Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90 20645 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 20646 Approved-By: Andrew Burgess <aburgess@redhat.com> 20647 206482023-10-10 Simon Marchi <simon.marchi@efficios.com> 20649 20650 gdb: add inferior parameter to architecture_changed observable 20651 This is to make it explicit which inferior's architecture just changed, 20652 and that the callbacks should not assume it is the current inferior. 20653 20654 Update the only caller, pyuw_on_new_gdbarch, to add the parameter, 20655 although it doesn't use it currently. 20656 20657 Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e 20658 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 20659 Approved-By: Andrew Burgess <aburgess@redhat.com> 20660 206612023-10-10 Simon Marchi <simon.marchi@efficios.com> 20662 20663 gdb: add inferior::{arch, set_arch} 20664 Make the inferior's gdbarch field private, and add getters and setters. 20665 This helped me by allowing putting breakpoints on set_arch to know when 20666 the inferior's arch was set. A subsequent patch in this series also 20667 adds more things in set_arch. 20668 20669 Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec 20670 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 20671 Approved-By: Andrew Burgess <aburgess@redhat.com> 20672 206732023-10-10 Alan Modra <amodra@gmail.com> 20674 20675 asan: buffer overflow in elf32_arm_get_synthetic_symtab 20676 Guard against fuzzed files where .plt size isn't commensurate with 20677 plt relocations. 20678 20679 * elf32-arm.c (elf32_arm_plt0_size): Add data_size param. 20680 Return -1 if data_size is too small. 20681 (elf32_arm_plt_size): Likewise. Delete temp var. Formatting. 20682 (elf32_arm_get_synthetic_symtab): Adjust to suit. 20683 206842023-10-10 Alan Modra <amodra@gmail.com> 20685 20686 asan: null dereference in read_and_display_attr_value 20687 This fixes multiple places in read_and_display_attr_value dealing with 20688 range and location lists that can segfault when debug_info_p is NULL. 20689 Fuzzed object files can contain arbitrary DW_FORMs. 20690 20691 * dwarf.c (read_and_display_attr_value): Don't dereference NULL 20692 debug_info_p. 20693 206942023-10-10 Alan Modra <amodra@gmail.com> 20695 20696 asan: invalid free in bfd_init_section_compress_status 20697 With specially crafted compressed sections, it's possible to tickle a 20698 problem when decompressing: If the compression headers says the 20699 uncompressed size is zero, this will be seen as an error return from 20700 bfd_compress_section_contents. On errors the caller should free any 20701 malloc'd input buffers, but this isn't really an error and the section 20702 contents have been updated to a bfd_alloc'd buffer which can't be 20703 freed. 20704 20705 * compress.c (bfd_compress_section_contents): Return -1 as error 20706 rather than 0. 20707 (bfd_init_section_compress_status, bfd_compress_section): Adjust. 20708 207092023-10-10 Jan Vrany <jan.vrany@labware.com> 20710 20711 gdb/python: implement support for sending custom MI async notifications 20712 This commit adds a new Python function, gdb.notify_mi, that can be used 20713 to emit custom async notification to MI channel. This can be used, among 20714 other things, to implement notifications about events MI does not support, 20715 such as remote connection closed or register change. 20716 20717 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 20718 Approved-By: Andrew Burgess <aburgess@redhat.com> 20719 207202023-10-10 Jan Vrany <jan.vrany@labware.com> 20721 20722 gdb/python: generalize serialize_mi_result() 20723 This commit generalizes serialize_mi_result() to make usable in 20724 different contexts than printing result of custom MI command. 20725 20726 To do so, the check whether passed Python object is a dictionary has been 20727 moved to the caller - at the very least, different uses require different 20728 error messages. Also it has been renamed to serialize_mi_results() to better 20729 match GDB/MI output syntax (see corresponding section in documentation, 20730 in particular rules 'result-record' and 'async-output'. 20731 20732 Since it is now more generic function, it has been moved to py-mi.c. 20733 20734 This is a preparation for implementing Python support for sending custom 20735 MI async events. 20736 20737 Approved-By: Andrew Burgess <aburgess@redhat.com> 20738 207392023-10-10 mengqinggang <mengqinggang@loongson.cn> 20740 20741 LoongArch/GAS: Add support for branch relaxation 20742 For the instructions of R_LARCH_B16/B21, if the immediate overflow, 20743 add a B instruction and R_LARCH_B26 relocation. 20744 20745 For example: 20746 20747 .L1 20748 ... 20749 blt $t0, $t1, .L1 20750 R_LARCH_B16 20751 20752 change to: 20753 20754 .L1 20755 ... 20756 bge $t0, $t1, .L2 20757 b .L1 20758 R_LARCH_B26 20759 .L2 20760 207612023-10-10 Tom de Vries <tdevries@suse.de> 20762 20763 [readelf] Handle .gdb_index section version 9 20764 Add the abilitity to print a v9 .gdb_index section. 20765 20766 The v9 section contains an extra table, which is printed as follows: 20767 ... 20768 Shortcut table: 20769 Language of main: Fortran 95 20770 Name of main: contains_keyword 20771 ... 20772 20773 [ For the example, I used the exec of gdb test-case 20774 gdb.fortran/nested-funcs-2-exp when running the test-case with target board 20775 cc-with-gdb-index. ] 20776 20777 Tested on x86_64-linux. 20778 20779 Approved-By: Nick Clifton <nickc@redhat.com> 20780 207812023-10-10 Matheus Branco Borella <dark.ryu.550@gmail.com> 20782 20783 [gdb/symtab] Add name_of_main and language_of_main to the DWARF index 20784 This patch adds a new section to the DWARF index containing the name 20785 and the language of the main function symbol, gathered from 20786 `cooked_index::get_main`, if available. Currently, for lack of a better name, 20787 this section is called the "shortcut table". The way this name is both saved and 20788 applied upon an index being loaded in mirrors how it is done in 20789 `cooked_index_functions`, more specifically, the full name of the main function 20790 symbol is saved and `set_objfile_main_name` is used to apply it after it is 20791 loaded. 20792 20793 The main use case for this patch is in improving startup times when dealing with 20794 large binaries. Currently, when an index is used, GDB has to expand symtabs 20795 until it finds out what the language of the main function symbol is. For some 20796 large executables, this may take a considerable amount of time to complete, 20797 slowing down startup. This patch bypasses that operation by having both the name 20798 and language of the main function symbol be provided ahead of time by the index. 20799 20800 In my testing (a binary with about 1.8GB worth of DWARF data) this change brings 20801 startup time down from about 34 seconds to about 1.5 seconds. 20802 20803 When testing the patch with target board cc-with-gdb-index, test-case 20804 gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a 20805 pre-existing issue, filed as PR symtab/30946. 20806 20807 Tested on x86_64-linux, with target board unix and cc-with-gdb-index. 20808 20809 PR symtab/24549 20810 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 20811 20812 Approved-By: Tom de Vries <tdevries@suse.de> 20813 208142023-10-10 GDB Administrator <gdbadmin@sourceware.org> 20815 20816 Automatic date update in version.in 20817 208182023-10-09 John Baldwin <jhb@FreeBSD.org> 20819 20820 gdb_unique_ptr.h: Fix a typo in a comment 20821 208222023-10-09 Nick Clifton <nickc@redhat.com> 20823 20824 Fix: Null pointer dereference in ldlex.l 20825 PR 30951 20826 * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL. 20827 20828 Fix: A potential null_pointer_deference bug 20829 PR 30954 20830 * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it. 20831 20832 Fix: Null pointer dereference in elf32-i386.c 20833 PR 30950 20834 * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer. 20835 20836 Fix: A potential bug of null pointer dereference 20837 PR 30949 20838 * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer. 20839 208402023-10-09 Andrew Burgess <aburgess@redhat.com> 20841 20842 gdb/testsuite: match complete lines in gdb.base/maint.exp 20843 This thread: 20844 20845 https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/ 20846 20847 pointed out that within gdb.base/maint.exp, some regexps within a 20848 gdb_test_multiple were failing to match a complete line, while later 20849 regexps within the gdb_test_multiple made use of the '^' anchor, and 20850 so assumed that earlier lines had been completely matched and removed 20851 from expect's buffer. 20852 20853 When testing with READ1 set this assumption was failing. 20854 20855 Fix this by extending the offending patterns with a trailing '\r\n'. 20856 20857 Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 20858 208592023-10-09 GDB Administrator <gdbadmin@sourceware.org> 20860 20861 Automatic date update in version.in 20862 208632023-10-08 Joel Brobecker <brobecker@adacore.com> 20864 20865 Update gdb/NEWS after GDB 14 branch creation. 20866 This commit a new section for the next release branch, and renames 20867 the section of the current branch, now that it has been cut. 20868 208692023-10-08 Joel Brobecker <brobecker@adacore.com> 20870 20871 Bump version to 15.0.50.DATE-git. 20872 Now that the GDB 14 branch has been created, 20873 this commit bumps the version number in gdb/version.in to 20874 15.0.50.DATE-git 20875 20876 For the record, the GDB 14 branch was created 20877 from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588. 20878 20879 Also, as a result of the version bump, the following changes 20880 have been made in gdb/testsuite: 20881 20882 * gdb.base/default.exp: Change $_gdb_major to 15. 20883 208842023-10-08 cailulu <cailulu@loongson.cn> 20885 20886 Add testsuits for new assembler option of mthin-add-sub. 20887 208882023-10-08 cailulu <cailulu@loongson.cn> 20889 20890 as: add option for generate R_LARCH_32/64_PCREL. 20891 Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL, 20892 so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default, 20893 and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL 20894 as much as possible. 20895 20896 The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL 20897 relocation in .eh_frame. 20898 208992023-10-08 GDB Administrator <gdbadmin@sourceware.org> 20900 20901 Automatic date update in version.in 20902 209032023-10-07 Michael J. Eager <eager@eagercon.com> 20904 20905 Revert "opcodes: microblaze: Add new bit-field instructions" 20906 This reverts commit 6bbf249557ba17cfebe01c67370df4da9e6a56f9. 20907 20908 Maciej W. Rozycki <macro@orcam.me.uk>: 20909 Yet it has caused numerous regressions: 20910 20911 microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges 20912 microblaze-elf +FAIL: binutils-all/pr26548 20913 microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output) 20914 microblaze-elf +FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output) Yet it has caused numerous regressions: 20915 microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges 20916 microblaze-elf +FAIL: binutils-all/pr26548 20917 microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output) 20918 ... 20919 209202023-10-07 Tom de Vries <tdevries@suse.de> 20921 20922 [gdb/testsuite] Fix gdb.arch/i386-signal.exp on x86_64 20923 On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into: 20924 ... 20925 builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \ 20926 -fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M 20927 /tmp/cc2xydTG.s: Assembler messages:^M 20928 /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M 20929 compiler exited with status 1 20930 output is: 20931 /tmp/cc2xydTG.s: Assembler messages:^M 20932 /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M 20933 20934 gdb compile failed, /tmp/cc2xydTG.s: Assembler messages: 20935 /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push' 20936 UNTESTED: gdb.arch/i386-signal.exp: failed to compile 20937 ... 20938 20939 This is with gas 2.41, it compiles without problems with gas 2.40. Some more 20940 strict checking was added in commit 5cc007751cd ("x86: further adjust 20941 extend-to-32bit-address conditions"). This may or may not be a gas regression 20942 ( https://sourceware.org/pipermail/binutils/2023-October/129818.html ). 20943 20944 The offending bit is: 20945 ... 20946 " push $sigframe\n" 20947 ... 20948 which refers to a function: 20949 ... 20950 " .globl sigframe\n" 20951 "sigframe:\n" 20952 ... 20953 20954 The test-case passes with target board unix/-m32. 20955 20956 Make the test-case work by using pushq instead of push for the 20957 is_amd64_regs_target case. 20958 20959 Tested on x86_64-linux, with target boards: 20960 - unix/-m64 (is_amd64_regs_target == 1), and 20961 - unix/-m32 (is_amd64_regs_target == 0), 20962 20963 PR testsuite/30928 20964 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928 20965 209662023-10-07 Ilya Leoshkevich <iii@linux.ibm.com> 20967 20968 gdb: support rseq auxvs 20969 Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size 20970 and alignment ELF auxiliary vector entries") introduced two new auxvs: 20971 AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN. Support them in GDB. This 20972 fixes auxv.exp on kernels >= v6.3. 20973 20974 Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e 20975 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540 20976 Approved-By: Tom Tromey <tom@tromey.com> 20977 209782023-10-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 20979 20980 gprofng: 30910 cross test fail: can't read "CHECK_TARGET": no such variable 20981 When TCL_TRY is FALSE, the wrong check-DEJAGNU is generated. 20982 Place "if TCL_TRY / endif" in the right place. 20983 20984 gprofng/ChangeLog 20985 2023-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 20986 20987 PR gprofng/30910 20988 * Makefile.am: Correct "if TCL_TRY / endif". 20989 * Makefile.in: Rebuild. 20990 209912023-10-07 GDB Administrator <gdbadmin@sourceware.org> 20992 20993 Automatic date update in version.in 20994 209952023-10-06 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 20996 20997 process-dies-while-detaching.exp: Exit early if GDB misses sync breakpoint 20998 I'm seeing a lot of variability in the failures of 20999 gdb.threads/process-dies-while-detaching.exp on aarch64-linux. On this 21000 platform, a problem yet to be investigated causes GDB to miss the _exit 21001 breakpoint. What happens next is random because after missing that 21002 breakpoint, GDB is out of sync with the inferior. This causes the tests 21003 following that point in the testcase to fail in a random way. 21004 21005 In this scenario it's better to exit the testcase early to avoid random 21006 results in the testsuite. 21007 21008 We are relying on gdb_continue_to_breakpoint to return the result of 21009 gdb_test_multiple. This is already the case because in Tcl the return 21010 value of a function is the return value of the last command it runs. But 21011 change gdb_continue_to_breakpoint to explicitly return this value, to make 21012 it clear this is the intended behaviour. 21013 21014 Tested on aarch64-linux. 21015 21016 Tested-By: Guinevere Larsen <blarsen@redhat.com> 21017 Approved-By: Andrew Burgess <aburgess@redhat.com> 21018 210192023-10-06 Neal Frager <neal.frager@amd.com> 21020 21021 opcodes: microblaze: Add new bit-field instructions 21022 This patches adds new bsefi and bsifi instructions. 21023 BSEFI- The instruction shall extract a bit field from a 21024 register and place it right-adjusted in the destination register. 21025 The other bits in the destination register shall be set to zero. 21026 BSIFI- The instruction shall insert a right-adjusted bit field 21027 from a register at another position in the destination register. 21028 The rest of the bits in the destination register shall be unchanged. 21029 21030 Further documentation of these instructions can be found here: 21031 https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref 21032 21033 This patch has been tested for years of AMD Xilinx Yocto 21034 releases as part of the following patch set: 21035 21036 https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils 21037 210382023-10-06 Andrew Burgess <aburgess@redhat.com> 21039 21040 gdb/NEWS: reorder some entries in the NEWS file 21041 I spotted two entries in the NEWS file that I believe are in the wrong 21042 place, these are: 21043 21044 - An entry about MI v1 being deprecated, this feels like it should 21045 be the first entry under the 'MI changes' heading, and 21046 21047 - An entry for the $_shell convenience function which is currently 21048 under the 'New commands' heading (sort of), when I think this 21049 should be listed in the general news section. 21050 210512023-10-06 Andrew Burgess <aburgess@redhat.com> 21052 21053 gdbserver: fix gdbserver builds after expedite_regs changes 21054 After this commit: 21055 21056 commit 6a65998a8a94abaaae7ca4ff0ab9c3f25dc2e766 21057 Date: Mon Sep 11 12:42:00 2023 +0100 21058 21059 Convert tdesc's expedite_regs to a string vector 21060 21061 The risc-v, loongarch, and csky gdbserver builds were broken. A use 21062 of target_desc::expedite_regs (for each architecture) was not updated 21063 to take account of the type change. 21064 21065 I've tested that this fixes the risc-v build. I haven't tested the 21066 other architectures, but they should be fine. 21067 210682023-10-06 Andrew Burgess <aburgess@redhat.com> 21069 21070 gdb/testsuite: cleanup in gdb.base/args.exp 21071 The last few commits resolved the KFAILs in gdb.base/args.exp. With 21072 those out of the way we can clean up this test script a little. 21073 21074 In this commit I have: 21075 21076 - Stopped passing 'nowarnings' flag when building the source file. 21077 I see no reason why this source should issue a warning, 21078 21079 - Moved setup of GDBFLAGS into args_test proc, callers that passed a 21080 newline needed a small tweak, and also the matching code needs 21081 updating for newline handling, but I think this is nicer, the 21082 argument lists are now given just once, 21083 21084 - Updated comment on args_test, 21085 21086 - Updated other comments. 21087 21088 There should be no change in what is tested after this commit. 21089 21090 Approved-By: Tom Tromey <tom@tromey.com> 21091 210922023-10-06 Andrew Burgess <aburgess@redhat.com> 21093 21094 gdbserver: cleanup in handle_v_run 21095 After the previous commit there is now a redundant string copy in 21096 handle_v_run, this commit cleans that up. 21097 21098 There should be no functional change after this commit. 21099 21100 During review I was pointed to this older series: 21101 21102 https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ 21103 21104 which also includes this fix as part of a larger set of changes. I'm 21105 giving a Co-Authored-By credit to the author of that original series. 21106 I believe this smaller fix brings some benefits on its own, though the 21107 original series does offer additional improvements. Once this is 21108 merged I'll take a look at rebasing and resubmitting the original series. 21109 21110 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> 21111 Approved-By: Tom Tromey <tom@tromey.com> 21112 211132023-10-06 Andrew Burgess <aburgess@redhat.com> 21114 21115 gdbserver: handle newlines in inferior arguments 21116 Similarly to how single quotes were mishandled, which was fixed two 21117 commits ago, this commit fixes handling of newlines in arguments 21118 passed to gdbserver. 21119 21120 We already had a test that covered this, gdb.base/args.exp, which, 21121 when run with the native-extended-gdbserver board contained several 21122 KFAIL covering this situation. 21123 21124 In this commit I remove the unnecessary, attempt to quote incoming 21125 newlines within arguments, and do some minimal cleanup of the related 21126 code. There is additional cleanup that can be done, but I'm leaving 21127 that for the next commit. 21128 21129 Then I've removed the KFAIL from the test case, and performed some 21130 minimal cleanup there too. 21131 21132 After this commit the gdb.base/args.exp is 100% passing with the 21133 native-extended-gdbserver board file. 21134 21135 During review I was pointed to this older series: 21136 21137 https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ 21138 21139 which also includes this fix as part of a larger set of changes. I'm 21140 giving a Co-Authored-By credit to the author of that original series. 21141 I believe this smaller fix brings some benefits on its own, though the 21142 original series does offer additional improvements. Once this is 21143 merged I'll take a look at rebasing and resubmitting the original series. 21144 21145 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 21146 21147 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> 21148 Approved-By: Tom Tromey <tom@tromey.com> 21149 211502023-10-06 Andrew Burgess <aburgess@redhat.com> 21151 21152 gdbserver: fix handling of trailing empty argument 21153 When I posted the previous patch for review Andreas Schwab pointed out 21154 that passing a trailing empty argument also doesn't work. 21155 21156 The fix for this is in the same area of code as the previous patch, 21157 but is sufficiently different that I felt it deserved a patch of its 21158 own. 21159 21160 I noticed that passing arguments containing single quotes to gdbserver 21161 didn't work correctly: 21162 21163 gdb -ex 'set sysroot' --args /tmp/show-args 21164 Reading symbols from /tmp/show-args... 21165 (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args 21166 Remote debugging using | gdbserver --once --multi - /tmp/show-args 21167 stdin/stdout redirected 21168 Process /tmp/show-args created; pid = 176054 21169 Remote debugging using stdio 21170 Reading symbols from /lib64/ld-linux-x86-64.so.2... 21171 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 21172 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 21173 (gdb) set args abc "" 21174 (gdb) run 21175 The program being debugged has been started already. 21176 Start it from the beginning? (y or n) y 21177 Starting program: /tmp/show-args \' 21178 stdin/stdout redirected 21179 Process /tmp/show-args created; pid = 176088 21180 2 args are: 21181 /tmp/show-args 21182 abc 21183 Done. 21184 [Inferior 1 (process 176088) exited normally] 21185 (gdb) target native 21186 Done. Use the "run" command to start a process. 21187 (gdb) run 21188 Starting program: /tmp/show-args \' 21189 2 args are: 21190 /tmp/show-args 21191 abc 21192 21193 Done. 21194 [Inferior 1 (process 176095) exited normally] 21195 (gdb) q 21196 21197 The 'shows-args' program used here just prints the arguments passed to 21198 the inferior. 21199 21200 Notice that when starting the inferior using the extended-remote 21201 target there is only a single argument 'abc', while when using the 21202 native target there is a second argument, the blank line, representing 21203 the empty argument. 21204 21205 The problem here is that the vRun packet coming from GDB looks like 21206 this (I've removing the trailing checksum): 21207 21208 $vRun;PROGRAM_NAME;616263; 21209 21210 If we compare this to a packet with only a single argument and no 21211 trailing empty argument: 21212 21213 $vRun;PROGRAM_NAME;616263 21214 21215 Notice the lack of the trailing ';' character here. 21216 21217 The problem is that gdbserver processes this string in a loop. At 21218 each point we maintain a pointer to the character just after a ';', 21219 and then we process everything up to either the next ';' character, or 21220 to the end of the string. 21221 21222 We break out of this loop when the character we start with (in that 21223 loop iteration) is the null-character. This means in the trailing 21224 empty argument case, we abort the loop before doing anything with the 21225 empty argument. 21226 21227 In this commit I've updated the loop, we now break out using a 'break' 21228 statement at the end of the loop if the (sub-)string we just processed 21229 was empty, with this change we now notice the trailing empty 21230 argument. 21231 21232 I've updated the test case to cover this issue. 21233 21234 Approved-By: Tom Tromey <tom@tromey.com> 21235 212362023-10-06 Andrew Burgess <aburgess@redhat.com> 21237 21238 gdbserver: fix handling of single quote arguments 21239 I noticed that passing arguments containing single quotes to gdbserver 21240 didn't work correctly: 21241 21242 gdb -ex 'set sysroot' --args /tmp/show-args 21243 Reading symbols from /tmp/show-args... 21244 (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args 21245 Remote debugging using | gdbserver --once --multi - /tmp/show-args 21246 stdin/stdout redirected 21247 Process /tmp/show-args created; pid = 176054 21248 Remote debugging using stdio 21249 Reading symbols from /lib64/ld-linux-x86-64.so.2... 21250 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 21251 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 21252 (gdb) set args \' 21253 (gdb) r 21254 The program being debugged has been started already. 21255 Start it from the beginning? (y or n) y 21256 Starting program: /tmp/show-args \' 21257 stdin/stdout redirected 21258 Process /tmp/show-args created; pid = 176088 21259 2 args are: 21260 /tmp/show-args 21261 \' 21262 Done. 21263 [Inferior 1 (process 176088) exited normally] 21264 (gdb) target native 21265 Done. Use the "run" command to start a process. 21266 (gdb) run 21267 Starting program: /tmp/show-args \' 21268 2 args are: 21269 /tmp/show-args 21270 ' 21271 Done. 21272 [Inferior 1 (process 176095) exited normally] 21273 (gdb) q 21274 21275 The 'shows-args' program used here just prints the arguments passed to 21276 the inferior. 21277 21278 Notice that when starting the inferior using the extended-remote 21279 target the second argument is "\'", while when running using native 21280 target the argument is "'". The second of these is correct, the \' 21281 used with the "set args" command is just to show GDB that the single 21282 quote is not opening an argument string. 21283 21284 It turns out that the extra backslash is injected on the gdbserver 21285 side when gdbserver processes the arguments that GDB passes it, the 21286 code that does this was added as part of this much larger commit: 21287 21288 commit 2090129c36c7e582943b7d300968d19b46160d84 21289 Date: Thu Dec 22 21:11:11 2016 -0500 21290 21291 Share fork_inferior et al with gdbserver 21292 21293 In this commit I propose removing the specific code that adds what I 21294 believe is a stray backslash. I've extended an existing test to cover 21295 this case, and I now see identical behaviour when using an 21296 extended-remote target as with the native target. 21297 21298 This partially fixes PR gdb/27989, though there are still some issues 21299 with newline handling which I'll address in a later commit. 21300 21301 During review I was pointed to this older series: 21302 21303 https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ 21304 21305 which also includes this fix as part of a larger set of changes. I'm 21306 giving a Co-Authored-By credit to the author of that original series. 21307 I believe this smaller fix brings some benefits on its own, though the 21308 original series does offer additional improvements. Once this is 21309 merged I'll take a look at rebasing and resubmitting the original series. 21310 21311 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 21312 21313 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> 21314 Approved-By: Tom Tromey <tom@tromey.com> 21315 213162023-10-06 Nick Clifton <nickc@redhat.com> 21317 21318 Fix: alpha: ld segfaults in 21319 PR 30940 21320 * elf64-alpha.c (elf64_alpha_check_relocs): Correct error message. 21321 213222023-10-06 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 21323 21324 gdb/configure.ac: Add option --with-additional-debug-dirs 21325 If you want to install GDB in a custom prefix, have it look for debug info 21326 in that prefix but also in the distro's default location (typically, 21327 /usr/lib/debug) and run the GDB testsuite before doing "make install", you 21328 have a bit of a problem: 21329 21330 Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory' 21331 parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from 21332 looking for distro-installed debug info in /usr/lib/debug. For regular GDB 21333 use you could set debug-file-directory to $PREFIX:/usr/lib/debug in 21334 $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want 21335 to run the testsuite then that doesn't help because in that case GDB runs 21336 with the '-nx' option. 21337 21338 There's the configure option '--with-separate-debug-dir' to set the default 21339 value for 'debug-file-directory', but it accepts only one directory and not 21340 a list. I considered modifying it to accept a list, but it's not obvious 21341 how to do that because its value is also used by BFD, as well as processed 21342 for "relocatability". 21343 21344 I thought it was simpler to add a new option to specify a list of 21345 additional directories that will be appended to the debug-file-directory 21346 setting. 21347 21348 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 21349 Approved-By: Tom Tromey <tom@tromey.com> 21350 213512023-10-06 GDB Administrator <gdbadmin@sourceware.org> 21352 21353 Automatic date update in version.in 21354 213552023-10-05 Tom de Vries <tdevries@suse.de> 21356 21357 [gdb/go] Handle v3 go_0 mangled prefix 21358 With gcc-10 we have: 21359 ... 21360 (gdb) break package2.Foo^M 21361 Breakpoint 2 at 0x402563: file package2.go, line 5.^M 21362 (gdb) PASS: gdb.go/package.exp: setting breakpoint 1 21363 ... 21364 but with gcc-11: 21365 ... 21366 gdb) break package2.Foo^M 21367 Function "package2.Foo" not defined.^M 21368 Make breakpoint pending on future shared library load? (y or [n]) n^M 21369 (gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo 21370 ... 21371 21372 In the gcc-10 case, though the exec contains dwarf, it's not used to set the 21373 breakpoint (which is an independent problem, filed as PR go/30941), instead 21374 the minimal symbol information is used. 21375 21376 The minimal symbol information changed between gcc-10 and gcc-11: 21377 ... 21378 $ nm a.out.10 | grep Foo 21379 000000000040370d T go.package2.Foo 21380 0000000000404e50 R go.package2.Foo..f 21381 $ nm a.out.11 | grep Foo 21382 0000000000403857 T go_0package2.Foo 21383 0000000000405030 R go_0package2.Foo..f 21384 ... 21385 21386 A new v3 mangling scheme was used. The mangling schemes define a separator 21387 character and mangling character: 21388 - for v2, dot is used both as separator character and mangling character, and 21389 - for v3, dot is used as separator character and underscore as mangling 21390 character. 21391 21392 For more details, see [1] and [2]. 21393 21394 In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo: 21395 change mangling scheme"), function Special_char_code::Special_char_code. ] 21396 21397 Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the 21398 test-case. 21399 21400 Note that this doesn't fix this regression: 21401 ... 21402 $ gccgo-10 package2.go -c -g0 21403 $ gccgo-10 package1.go package2.o -g0 21404 $ gdb -q -batch a.out -ex "break go.package2.Foo" 21405 Breakpoint 1 at 0x40370d 21406 $ gccgo-11 package2.go -c -g0 21407 $ gccgo-11 package1.go package2.o -g0 21408 $ gdb -q -batch a.out -ex "break go.package2.Foo" 21409 Function "go.package2.Foo" not defined. 21410 ... 21411 21412 With gcc-10, we set a breakpoint on the mangled minimal symbol. That 21413 one has simply changed for gcc-11, so it's equivalent to using: 21414 ... 21415 $ gdb -q -batch a.out -ex "break go_0package2.Foo" 21416 Breakpoint 1 at 0x403857 21417 ... 21418 which does work. 21419 21420 Tested on x86_64-linux: 21421 - openSUSE Leap 15.4, using gccgo-7, 21422 - openSUSE Tumbleweed, using gccgo-13. 21423 21424 PR go/27238 21425 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238 21426 21427 [1] https://go-review.googlesource.com/c/gofrontend/+/271726 21428 [2] https://github.com/golang/go/issues/41862#issuecomment-707244103 21429 214302023-10-05 Simon Marchi <simon.marchi@efficios.com> 21431 21432 gdb: use objfile->pspace in free_objfile observers 21433 Use objfile->pspace instead of current_program_space. 21434 21435 Change-Id: I127a1788e155b321563114452ed5b530f1d1f618 21436 Approved-By: Tom Tromey <tom@tromey.com> 21437 214382023-10-05 Simon Marchi <simon.marchi@efficios.com> 21439 21440 gdb: remove unnecessary nullptr check in free_objfile observers 21441 The free_objfile observable is never called with a nullptr objfile. 21442 21443 Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe 21444 Approved-By: Tom Tromey <tom@tromey.com> 21445 214462023-10-05 Simon Marchi <simon.marchi@efficios.com> 21447 21448 gdb: add all_objfiles_removed observer 21449 The new_objfile observer is currently used to indicate both when a new 21450 objfile is added to program space (when passed non-nullptr) and when all 21451 objfiles of a program space were just removed (when passed nullptr). 21452 I think this is confusing (and Andrew apparently thinks so too [1]). 21453 Add a new "all_objfiles_removed" observer to remove the second role from 21454 "new_objfile". 21455 21456 Some existing users of new_objfile do nothing if the passed objfile is 21457 nullptr. For them, we can simply drop the nullptr check. For others, 21458 add a new all_objfiles_removed callback, and refactor things a bit to 21459 keep the existing behavior as much as possible. 21460 21461 Some callbacks relied on current_program_space, and following 21462 the refactoring now use either objfile->pspace or the pspace passed to 21463 all_objfiles_removed. I think this should be relatively safe, and in 21464 general a step in the right direction. 21465 21466 On the notify side, I found only one call site to change from 21467 new_objfile to all_objfiles_removed, in clear_symtab_users. It is not 21468 entirely clear to me that this is entirely correct. clear_symtab_users 21469 appears to be called in spots that don't remove all objfiles 21470 (functions finish_new_objfile, remove_symbol_file_command, reread_symbols, 21471 do_module_cleanups). But I think that this patch at least makes the 21472 current code clearer. 21473 21474 [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252 21475 21476 Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13 21477 Approved-By: Tom Tromey <tom@tromey.com> 21478 214792023-10-05 Simon Marchi <simon.marchi@efficios.com> 21480 21481 gdb: add program_space parameters to some auto-load functions 21482 Make the current_program_space references bubble up a bit. 21483 21484 Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652 21485 Approved-By: Tom Tromey <tom@tromey.com> 21486 214872023-10-05 Simon Marchi <simon.marchi@efficios.com> 21488 21489 gdb: use objfile->pspace in auto-load.c 21490 Use objfile->pspace instead of current_program_space in two spots. 21491 21492 Change-Id: Idf94fad486252d1250380f295e71b0fe76dce76c 21493 Approved-By: Tom Tromey <tom@tromey.com> 21494 214952023-10-05 Simon Marchi <simon.marchi@efficios.com> 21496 21497 gdb: add program_space parameter to emit_clear_objfiles_event 21498 Add program_space space parameters to emit_clear_objfiles_event and 21499 create_clear_objfiles_event_object, making the reference to 21500 current_program_space bubble up a bit. 21501 21502 Change-Id: I5fde2071712781e5d45971fa0ab34d85d3a49a71 21503 Approved-By: Tom Tromey <tom@tromey.com> 21504 215052023-10-05 Simon Marchi <simon.marchi@efficios.com> 21506 21507 gdb: add program_space parameters to some functions in symtab.c 21508 Add some program_space parameters to functions related to getting and 21509 setting the main name, making the references to current_program_space 21510 bubble up a bit. find_main_name calls ada_main_name, which implicitly 21511 relies on the current program space, so I didn't add a parameter to that 21512 function. 21513 21514 Change-Id: I9996955e8ae56832bbd461964d978e700e6feaf4 21515 Approved-By: Tom Tromey <tom@tromey.com> 21516 215172023-10-05 Simon Marchi <simon.marchi@efficios.com> 21518 21519 gdb: add program_space parameter to ada_clear_symbol_cache 21520 Make the references to current_program_space bubble up one level. 21521 21522 Change-Id: I82acab5628c30f6535d52aa32ce2c1d0375cbeed 21523 Approved-By: Tom Tromey <tom@tromey.com> 21524 215252023-10-05 Andrew Burgess <aburgess@redhat.com> 21526 21527 gdb: fix auxv cache clearing from new_objfile observer 21528 It was pointed out on the mailing list that a recently added 21529 test (gdb.python/py-progspace-events.exp) was failing when run with 21530 the native-extended-gdbserver board. This test was added with this 21531 commit: 21532 21533 commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f 21534 Date: Tue Sep 19 11:45:36 2023 +0100 21535 21536 gdb: add Python events for program space addition and removal 21537 21538 It turns out though that the test is failing due to a existing bug 21539 in GDB, the new test just exposes the problem. Additionally, the 21540 failure really doesn't even rely on the new functionality added in the 21541 above commit. I reduced the test to a simple set of steps that 21542 reproduced the failure and tested against GDB 13, and the test passes; 21543 so the bug was introduced since then. In fact, the bug was introduced 21544 with this commit: 21545 21546 commit a2827364e2bf19910fa5a54364a594a5ba3033b8 21547 Date: Fri Sep 8 15:48:16 2023 +0100 21548 21549 gdb: remove final user of the executable_changed observer 21550 21551 This commit changed how the per-inferior auxv data cache is managed, 21552 specifically, when the cache is cleared, and it is this that leads to 21553 the failure. 21554 21555 This bug is interesting because it exposes a number of issues with 21556 GDB, I'll explain all of the problems I see, though ultimately, I only 21557 propose fixing one problem in this commit, which is enough to resolve 21558 the crash we are currently seeing. 21559 21560 The crash that we are seeing manifests like this: 21561 21562 ... 21563 [Inferior 2 (process 3970384) exited normally] 21564 +inferior 1 21565 [Switching to inferior 1 [process 3970383] (/tmp/build/gdb/testsuite/outputs/gdb.python/py-progspace-events/py-progspace-events)] 21566 [Switching to thread 1.1 (Thread 3970383.3970383)] 21567 #0 breakpt () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.python/py-progspace-events.c:28 21568 28 { /* Nothing. */ } 21569 (gdb) step 21570 +step 21571 terminate called after throwing an instance of 'gdb_exception_error' 21572 21573 Fatal signal: Aborted 21574 ... etc ... 21575 21576 What's happening is that GDB attempts to refill the auxv cache as a 21577 result of the gdbarch_has_shared_address_space call in 21578 program_space::~program_space, the backtrace looks like this: 21579 21580 #0 0x00007fb4f419a9a5 in raise () from /lib64/libpthread.so.0 21581 #1 0x00000000008b635d in handle_fatal_signal (sig=6) at ../../src/gdb/event-top.c:912 21582 #2 <signal handler called> 21583 #3 0x00007fb4f38e3625 in raise () from /lib64/libc.so.6 21584 #4 0x00007fb4f38cc8d9 in abort () from /lib64/libc.so.6 21585 #5 0x00007fb4f3c70756 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6 21586 #6 0x00007fb4f3c7c6dc in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6 21587 #7 0x00007fb4f3c7b6e9 in __cxa_call_terminate () from /lib64/libstdc++.so.6 21588 #8 0x00007fb4f3c7c094 in __gxx_personality_v0 () from /lib64/libstdc++.so.6 21589 #9 0x00007fb4f3a80c63 in _Unwind_RaiseException_Phase2 () from /lib64/libgcc_s.so.1 21590 #10 0x00007fb4f3a8154e in _Unwind_Resume () from /lib64/libgcc_s.so.1 21591 #11 0x0000000000e8832d in target_read_alloc_1<unsigned char> (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2266 21592 #12 0x0000000000e73dea in target_read_alloc (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2315 21593 #13 0x000000000058248c in target_read_auxv_raw (ops=0x408a3a0) at ../../src/gdb/auxv.c:379 21594 #14 0x000000000058243d in target_read_auxv () at ../../src/gdb/auxv.c:368 21595 #15 0x000000000058255c in target_auxv_search (match=0x0, valp=0x7ffdee17c598) at ../../src/gdb/auxv.c:415 21596 #16 0x0000000000a464bb in linux_is_uclinux () at ../../src/gdb/linux-tdep.c:433 21597 #17 0x0000000000a464f6 in linux_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/linux-tdep.c:440 21598 #18 0x0000000000510eae in gdbarch_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/gdbarch.c:4889 21599 #19 0x0000000000bc7558 in program_space::~program_space (this=0x4544aa0, __in_chrg=<optimized out>) at ../../src/gdb/progspace.c:124 21600 #20 0x00000000009b245d in delete_inferior (inf=0x47b3de0) at ../../src/gdb/inferior.c:290 21601 #21 0x00000000009b2c10 in prune_inferiors () at ../../src/gdb/inferior.c:480 21602 #22 0x00000000009c5e3e in fetch_inferior_event () at ../../src/gdb/infrun.c:4558 21603 #23 0x000000000099b4dc in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42 21604 #24 0x0000000000cbc64f in remote_async_serial_handler (scb=0x4090a30, context=0x408a6b0) at ../../src/gdb/remote.c:14859 21605 #25 0x0000000000d83d3a in run_async_handler_and_reschedule (scb=0x4090a30) at ../../src/gdb/ser-base.c:138 21606 #26 0x0000000000d83e1f in fd_event (error=0, context=0x4090a30) at ../../src/gdb/ser-base.c:189 21607 21608 So this is problem #1, if we throw an exception while deleting a 21609 program_space then this is not caught, and is going to crash GDB. 21610 21611 Problem #2 becomes evident when we ask why GDB is throwing an error in 21612 this case; the error is thrown because the remote target, operating in 21613 non-async mode, can't read the auxv data while an inferior is running 21614 and GDB is waiting for a stop reply. The problem here then, is why 21615 does GDB get into a position where it tries to interact with the 21616 remote target in this way, at this time? The problem is caused by the 21617 prune_inferiors call which can be seen in the above backtrace. 21618 21619 In prune_inferiors we check if the inferior is deletable, and if it 21620 is, we delete it. The problem is, I think, we should also check if 21621 the target is currently in a state that would allow us to delete the 21622 inferior. We don't currently have such a check available, we'd need 21623 to add one, but for the remote target, this would return false if the 21624 remote is in async mode and the remote is currently waiting for a stop 21625 reply. With this change in place GDB would defer deleting the 21626 inferior until the remote target has stopped, at which point GDB would 21627 be able to refill the auxv cache successfully. 21628 21629 And then, problem #3 becomes evident when we ask why GDB is needing to 21630 refill the auxv cache now when it didn't need to for GDB 13. This is 21631 where the second commit mentioned above (a2827364e2bf) comes in. 21632 Prior to this commit, the auxv cache was cleared by the 21633 executable_changed observer, while after that commit the auxv cache 21634 was cleared by the new_objfile observer -- but only when the 21635 new_objfile observer is used in the special mode that actually means 21636 that all objfiles have been unloaded (I know, the overloading of the 21637 new_objfile observer is horrible, and unnecessary, but it's not really 21638 important for this bug). 21639 21640 The difference arises because the new_objfile observer is triggered 21641 from clear_symtab_users, which in turn is called from 21642 program_space::~program_space. The new_objfile observer for auxv does 21643 this: 21644 21645 static void 21646 auxv_new_objfile_observer (struct objfile *objfile) 21647 { 21648 if (objfile == nullptr) 21649 invalidate_auxv_cache_inf (current_inferior ()); 21650 } 21651 21652 That is, when all the objfiles are unloaded, we clear the auxv cache 21653 for the current inferior. 21654 21655 The problem is, then when we look at the prune_inferiors -> 21656 delete_inferior -> ~program_space path, we see that the current 21657 inferior is not going to be an inferior that exists within the 21658 program_space being deleted; delete_inferior removes the deleted 21659 inferior from the global inferior list, and then only deletes the 21660 program_space if program_space::empty() returns true, which is only 21661 the case if the current inferior isn't within the program_space to 21662 delete, and no other inferior exists within that program_space 21663 either. 21664 21665 What this means is that when the new_objfile observer is called we 21666 can't rely on the current inferior having any relationship with the 21667 program space in which the objfiles were removed. This was an error 21668 in the commit a2827364e2bf, the only thing we can rely on is the 21669 current program space. As a result of this mistake, after commit 21670 a2827364e2bf, GDB was sometimes clearing the auxv cache for a random 21671 inferior. In the native target case this was harmless as we can 21672 always refill the cache when needed, but in the remote target case, if 21673 we need to refill the cache when the remote target is executing, then 21674 we get the crash we observed. 21675 21676 And additionally, if we think about this a little more, we see that 21677 commit a2827364e2bf made another mistake. When all the objfiles are 21678 removed, they are removed from a program_space, a program_space might 21679 contain multiple inferiors, so surely, we should clear the auxv cache 21680 for all of the matching inferiors? 21681 21682 Given these two insights, that the current_inferior is not relevant, 21683 only the current_program_space, and that we should be clearing the 21684 cache for all inferiors in the current_program_space, we can update 21685 auxv_new_objfile_observer to: 21686 21687 if (objfile == nullptr) 21688 { 21689 for (inferior *inf : all_inferiors ()) 21690 { 21691 if (inf->pspace == current_program_space) 21692 invalidate_auxv_cache_inf (inf); 21693 } 21694 } 21695 21696 With this change we now correctly clear the auxv cache for the correct 21697 inferiors, and GDB no longer needs to refill the cache at an 21698 inconvenient time, this avoids the crash we were seeing. 21699 21700 And finally, we reach problem #4. Inspired by the observation that 21701 using the current_inferior from within the ~program_space function was 21702 not correct, I added some debug to see if current_inferior() was 21703 called anywhere else (below ~program_space), and the answer is yes, 21704 it's called a often. Mostly the culprit is GDB doing: 21705 21706 current_inferior ()->top_target ()-> .... 21707 21708 But I think all of these calls are most likely doing the wrong thing, 21709 and only work because the top target in all these cases is shared 21710 between all inferiors, e.g. it's the native target, or the remote 21711 target for all inferiors. But if we had a truly multi-connection 21712 setup, then we might start to see odd behaviour. 21713 21714 Problem #1 I'm just ignoring for now, I guess at some point we might 21715 run into this again, and then we'd need to solve this. But in this 21716 case I wasn't sure what a "good" solution would look like. We need 21717 the auxv data in order to implement the linux_is_uclinux() function. 21718 If we can't get the auxv data then what should we do, assume yes, or 21719 assume no? The right answer would probably be to propagate the error 21720 back up the stack, but then we reach ~program_space, and throwing 21721 exceptions from a destructor is problematic, so we'd need to catch and 21722 deal at this point. The linux_is_uclinux() call is made from within 21723 gdbarch_has_shared_address_space(), which is used like: 21724 21725 if (!gdbarch_has_shared_address_space (target_gdbarch ())) 21726 delete this->aspace; 21727 21728 So, we would have to choose; delete the address space or not. If we 21729 delete it on error, then we might delete an address space that is 21730 shared within another program space. If we don't delete the address 21731 space, then we might leak it. Neither choice is great. 21732 21733 A better solution might be to have the address spaces be reference 21734 counted, then we could remove the gdbarch_has_shared_address_space 21735 call completely, and just rely on the reference count to auto-delete 21736 the address space when appropriate. 21737 21738 The solution for problem #2 I already hinted at above, we should have 21739 a new target_can_delete_inferiors() call, which should be called from 21740 prune_inferiors, this would prevent GDB from trying to delete 21741 inferiors when a (remote) target is in a state where we know it can't 21742 delete the inferior. Deleting an inferior often (always?) requires 21743 sending packets to the remote, and if the remote is waiting for a stop 21744 reply then this will never work, so the pruning should be deferred in 21745 this case. 21746 21747 The solution for problem #3 is included in this commit. 21748 21749 And, for problem #4, I'm not sure what the right solution is. Maybe 21750 delete_inferior should ensure the inferior to be deleted is in place 21751 when ~program_space is called? But that seems a little weird, as the 21752 current inferior would, in theory, still be using the current 21753 program_space... 21754 21755 Anyway, after this commit, the gdb.python/py-progspace-events.exp test 21756 now passes when run with the native-extended-remote board. 21757 21758 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30935 21759 Approved-By: Simon Marchi <simon.marchi@efficios.com> 21760 Change-Id: I41f0e6e2d7ecc1e5e55ec170f37acd4052f46eaf 21761 217622023-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 21763 21764 gprofng: 30894 bison should be no hard dependency 21765 When running from a distribution tarball, bison should not be necessary. 21766 The generated files (QLParser.tab.cc, QLParser.tab.hh) should be distributed. 21767 configure.ac should not abort if bison is missing. 21768 configure.ac should remove temporary files (dummy.c, Simple.class). 21769 bison must be run once to create QLParser.tab.cc and QLParser.tab.hh. 21770 21771 gprofng/ChangeLog 21772 2023-10-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 21773 21774 PR gprofng/30894 21775 * configure.ac: Don't abort if bison is missing. Remove temporary files. 21776 * src/Makefile.am: Distribute QLParser.tab.cc and QLParser.tab.hh. 21777 * Run bison once to create QLParser.tab.cc and QLParser.tab.hh. 21778 * configure: Rebuild. 21779 * src/Makefile.in: Rebuild. 21780 217812023-10-05 Nick Clifton <nickc@redhat.com> 21782 21783 Fix: nm: SEGV at bfd/elf.c:2267 in _bfd_elf_get_dynamic_symbols 21784 PR 30904 21785 * elf.c (_bfd_elf_get_dynamic_symbols): Fix typo when checking to see if the gnuchains array has been successfully created. 21786 217872023-10-05 A. Wilcox <awilfox@adelielinux.org> 21788 21789 Fix: ld: Test case pr28158 fails on x86_64-linux-musl when index is > 19 21790 PR 30905 21791 * testsuite/ld-elf/pr28158.rd: Adjust regexp to allow for section indicies larger than 9. 21792 21793 Fix: addr2line testsuite fails when targeting PowerPC 64 big-endian with ELFv2 ABI 21794 PR 30916 21795 * testsuite/binutils-all/addr2line.exp: Do not use PowerPC specific options when working with a MUSL target. 21796 21797 Fix: ld testsuite: glibc-specific DT_RELR tests should not be run on musl systems 21798 PR 30917 21799 * testsuite/ld-elf/dt-relr.exp: Skip for MUSL targets. 21800 21801 Fix: ld testsuite: non-PIC shared tests fail on powerpc-linux-musl 21802 PR 30918 21803 * testsuite/ld-shared/shared.exp: Add XFAILs for tests that fail with the MUSL library. 21804 21805 Fix: ld testsuite: Thumb PLT and GOT tests should be skipped on musl armhf targets 21806 PR 30923 21807 * testsuite/ld-arm/thumb-plt-got.d: Skip test for configurations using the MUSL library. 21808 * testsuite/ld-arm/thumb-plt.d: Likewise. 21809 21810 Fix: ld testsuite: pr22001-1 test segfaults on musl/x86 21811 PR 30925 21812 PR 22001 21813 * testsuite/ld-i386/i386.exp: Skip the pr22001 test with TEXTREL relocations enabled on configurations using the MUSL library. 21814 218152023-10-05 Andrew Burgess <aburgess@redhat.com> 21816 21817 gdb: fix reread_symbols when an objfile has target: prefix 21818 When using a remote target, it is possible to tell GDB that the 21819 executable to be debugged is located on the remote machine, like this: 21820 21821 (gdb) target extended-remote :54321 21822 ... snip ... 21823 (gdb) file target:/tmp/hello.x 21824 Reading /tmp/hello.x from remote target... 21825 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. 21826 Reading /tmp/hello.x from remote target... 21827 Reading symbols from target:/tmp/hello.x... 21828 (gdb) 21829 21830 So far so good. However, when we try to start the inferior we run 21831 into a small problem: 21832 21833 (gdb) set remote exec-file /tmp/hello.x 21834 (gdb) start 21835 `target:/tmp/hello.x' has disappeared; keeping its symbols. 21836 Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18. 21837 Starting program: target:/tmp/hello.x 21838 ... snip ... 21839 21840 Temporary breakpoint 1, main () at /tmp/hello.c:18 21841 18 printf ("Hello World\n"); 21842 (gdb) 21843 21844 Notice this line: 21845 21846 `target:/tmp/hello.x' has disappeared; keeping its symbols. 21847 21848 That's wrong, the executable hasn't been removed, GDB just doesn't 21849 know how to check if the remote file has changed, and so falls back to 21850 assuming that the file has been removed. 21851 21852 In this commit I update reread_symbols to use bfd_stat instead of 21853 a direct stat call, this adds support for target: files, and fixes the 21854 problem. 21855 21856 This change was proposed before in this commit: 21857 21858 https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/ 21859 21860 However, that patch never got merged, and seemed to get stuck 21861 discussing issues around gnulib stat vs system stat as used by BFD. 21862 21863 I didn't 100% understand the issues discussed in that thread, however, 21864 I think the problem with the previous thread related to the changes in 21865 gdb_bfd.c, rather than to the change in symfile.c. As such, I think 21866 this change might be acceptable, my reasoning is: 21867 21868 - the objfile::mtime field is set by a call to bfd_get_mtime (see 21869 objfiles.c), which calls bfd_stat under the hood. This will end 21870 up using the system stat, 21871 21872 - In symfile.c we currently call stat directly, which will call the 21873 gnulib stat, which, if I understand the above thread correctly, 21874 might give a different result to the system stat in some cases, 21875 21876 - By switching to using bfd_stat in symfile.c we should now be 21877 consistently calling the system stat. 21878 21879 There is another issue that came up during testing that this commit 21880 fixes. Consider this GDB session: 21881 21882 $ gdb -q 21883 (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once - 21884 Remote debugging using | ./gdbserver/gdbserver --multi --once - 21885 Remote debugging using stdio 21886 (gdb) file /tmp/hello.x 21887 Reading symbols from /tmp/hello.x... 21888 (gdb) set remote exec-file /tmp/hello.x 21889 (gdb) start 21890 ... snip ... 21891 (gdb) load 21892 `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols. 21893 Loading section .interp, size 0x1c lma 0x4002a8 21894 ... snip ... 21895 Start address 0x0000000000401050, load size 2004 21896 Transfer rate: 326 KB/sec, 87 bytes/write. 21897 21898 Notice this line: 21899 21900 `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols. 21901 21902 We actually see the same output, for the same reasons, when using a 21903 native target, like this: 21904 21905 $ gdb -q 21906 (gdb) file /tmp/hello.x 21907 Reading symbols from /tmp/hello.x... 21908 (gdb) start 21909 ... snip ... 21910 (gdb) load 21911 `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols. 21912 You can't do that when your target is `native' 21913 (gdb) 21914 21915 In both cases this line appears because load_command (symfile.c) calls 21916 reread_symbols, and reread_symbols loops over every currently loaded 21917 objfile and tries to check if the file has changed on disk by calling 21918 stat. 21919 21920 However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory 21921 BFD, the filename for this BFD is literally the string 21922 'system-supplied DSO at 0x7ffff7fcf000'. 21923 21924 Before this commit GDB would try to use the system 'stat' call to stat 21925 the file `system-supplied DSO at 0x7ffff7fcf000', which obviously 21926 fails; there's no file with that name (usually). As a consequence of 21927 the stat failing GDB prints the ' .... has disappeared ...' line. 21928 21929 Initially, all this commit did was switch from using 'stat' to using 21930 'bfd_stat'. Calling bfd_stat on an in-memory BFD works just fine, 21931 however, BFD just fills the 'struct stat' buffer with zeros (except 21932 for the file size), see memory_bstat in bfd/bfdio.c. 21933 21934 However, there is a bit of a weirdness about in-memory BFDs. When 21935 they are initially created the libbfd caches an mtime within the bfd 21936 object, this is done in bfd_from_remote_memory (elfcode.h), the cached 21937 mtime is the time at which the in-memory BFD is created. 21938 21939 What this means is that when GDB creates the in-memory BFD, and we 21940 call bfd_get_mtime(), the value returned, which GDB caches within 21941 objfile::mtime is the creation time of the in-memory BFD. But, when 21942 this patch changes to use bfd_stat() we now get back 0, and so we 21943 believe that the in-memory BFD has changed. This is a change in 21944 behaviour. 21945 21946 To avoid this change in behaviour, in this commit, I propose that we 21947 always skip in-memory BFDs in reread_symbols. This preserves the 21948 behaviour from before this commit -- mostly. 21949 21950 As I'm not specifically checking for, and then skipping, in-memory 21951 BFDs, we no longer see this line: 21952 21953 `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols. 21954 21955 Which I think is an improvement. 21956 21957 Co-Authored-By: Tom Tromey <tromey@adacore.com> 21958 Approved-By: Tom Tromey <tom@tromey.com> 21959 219602023-10-05 Andrew Burgess <aburgess@redhat.com> 21961 21962 gdb: remove print_sys_errmsg 21963 This started with me running into this comment in symfile.c: 21964 21965 /* FIXME, should use print_sys_errmsg but it's not filtered. */ 21966 gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"), 21967 styled_string (file_name_style.style (), filename)); 21968 21969 In this particular case I think I disagree with the comment; I think 21970 the output should be a warning rather than just a message printed to 21971 gdb_stdout, I think when the executable, or some other objfile that is 21972 currently being debugged, disappears from disk, this is likely an 21973 unexpected situation, and worth warning the user about. 21974 21975 So, in theory, I could just call print_sys_errmsg and remove the 21976 comment, but that would mean loosing the filename styling in the 21977 output... so in the end I remove the comment and updated the code to 21978 call warning. 21979 21980 But that got me looking at print_sys_errmsg and how it's used. 21981 21982 Currently the function takes a string and an errno, and prints, to 21983 stderr, the string followed by the result of calling strerror on the 21984 errno. 21985 21986 In some places the string passed to print_sys_errmsg is just a 21987 filename, and this is used when something goes wrong. In these cases, 21988 I think calling warning rather than gdb_printf to gdb_stderr, would be 21989 better, and in fact, in a couple of places we manually print a 21990 "warning" prefix, and then call print_sys_errmsg. And so, for these 21991 users I have added a new function warning_filename_and_errno, which 21992 takes a filename, which is printed with styling, and an errno, which 21993 is passed through strerror and the resulting string printed. This new 21994 function calls warning to print its output. I then updated some of 21995 the print_sys_errmsg users to use this new function. 21996 21997 Some other users of print_sys_errmsg are also emitting what is clearly 21998 a warning, however, the string being passed in is more than just a 21999 filename, so the new warning_filename_and_errno function can't be 22000 used, it would style the whole string. For these users I have 22001 switched to calling warning directly, this allows me to style the 22002 warning message correctly. 22003 22004 Finally, in inflow.c there is one last call to print_sys_errmsg, in 22005 this case I just inlined the definition of print_sys_errmsg. This is 22006 a really weird case, as after printing this message GDB just does a 22007 hard exit. This is pretty old code, dating back to the initial GDB 22008 import, I guess it should be updated to call error() maybe, but I'm 22009 reluctant to make this change as part of this commit, just in case 22010 there's some reason why we can't throw an error at this point. 22011 22012 With that done there are now no users of print_sys_errmsg, and so the 22013 old function can be removed. 22014 22015 While I was doing all of the above I added some additional filename 22016 styling in soure.c, this is in an else block where the if contained 22017 the print_sys_errmsg call, so these felt related. 22018 22019 And finally, while I was updating the uses of print_sys_errmsg in 22020 procfs.c, I noticed that we used a static errmsg buffer to format some 22021 error strings. As the above changes got rid of one of the users of 22022 errmsg I also removed the other two users, and the static buffer. 22023 22024 There were a couple of tests that depended on the existing output 22025 message format that needed updating. In one case we gained an extra 22026 'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ', 22027 I think in both cases the new output is an improvement. 22028 22029 Approved-By: Tom Tromey <tom@tromey.com> 22030 220312023-10-05 Andrew Burgess <aburgess@redhat.com> 22032 22033 gdb: remove use of a static buffer for building error strings 22034 I noticed in procfs.c that we use a static buffer for building error 22035 strings when we could easily use std::string and string_printf to 22036 achieve the same result, this commit does that. 22037 22038 I ran into this while performing a further refactor/cleanup that will 22039 be presented in a later patch in this series, and thought this was 22040 worth splitting out into its own patch. 22041 22042 As far as I can tell, only Solaris uses procfs.c, so I did a test 22043 build on a Solaris machine, and I don't believe that I've broken 22044 anything. 22045 22046 There should be no user visible changes after this commit. 22047 22048 Approved-By: Tom Tromey <tom@tromey.com> 22049 220502023-10-05 Andrew Burgess <aburgess@redhat.com> 22051 22052 gdb: use archive name in warning when appropriate 22053 While working on some other patch I noticed that in reread_symbols 22054 there is a diagnostic message that can be printed, and in some cases 22055 we might use the wrong filename in the message. 22056 22057 The code in question is checking to see if an objfile has changed on 22058 disk, we do this by stat-ing the on disk file and checking the mtime. 22059 If this file has been removed from disk then we print a message that 22060 the file has been removed, however, if the objfile is within an 22061 archive then we stat the archive itself, but then warn that the 22062 component within the archive has disappeared. I think it makes more 22063 sense to say that the archive has disappeared. 22064 22065 The last related commit is this one: 22066 22067 commit 02aeec7bde8ec8a04d14a5637e75f1c6ab899e23 22068 Date: Tue Apr 27 21:01:30 2010 +0000 22069 22070 Check library name rather than member name when rereading symbols. 22071 22072 Though this just makes the code to stat the archive unconditional, the 22073 code in question existed before this commit. 22074 22075 However, the above commit doesn't include any tests, and seems to 22076 indicate that the problem being addressed was seen on Darwin. I'm not 22077 sure how to setup a test where GDB is using an objfile from within an 22078 archive, and so there's no tests for this commit... 22079 22080 ... but if someone can let me know how I can setup a suitable test, 22081 please let me know and I'll try to get something working. 22082 22083 Approved-By: Tom Tromey <tom@tromey.com> 22084 220852023-10-05 Andrew Burgess <aburgess@redhat.com> 22086 22087 gdb: some additional filename styling 22088 Fix up another couple of places where we can apply filename styling. 22089 22090 Approved-By: Tom Tromey <tom@tromey.com> 22091 220922023-10-05 A. Wilcox <awilfox@adelielinux.org> 22093 22094 Fix: ld testsuite: 'Version' pattern grabs 'Version5 EABI', breaking test on arm-linux-musleabihf 22095 PR 30924 22096 * testsuite/ld-elfvers/vers.exp (objdump_emptyverstuff): Handle EABI version information in objdump's output. 22097 220982023-10-05 Saurabh Jha <saurabh.jha@arm.com> 22099 22100 aarch64: Enable Cortex-X4 CPU 22101 221022023-10-05 Neal frager <neal.frager@amd.com> 22103 22104 microblaze: Add address extension instructions 22105 * microblaze-opcm.h (struct op_code_struct): Tidy and remove redundant entries. 22106 * microblaze-opc.h (MAX_OPCODES): Increase to 300. (op_code_struct): Add address extension instructions. 22107 221082023-10-05 GDB Administrator <gdbadmin@sourceware.org> 22109 22110 Automatic date update in version.in 22111 221122023-10-04 Guinevere Larsen <blarsen@redhat.com> 22113 22114 gdb/testsuite: XFAIL some gdb.base/fileio.exp 22115 Some gdb.base/fileio.exp tests expect the inferior to not have write 22116 access to some files. If the test is being run as root, this is never 22117 possible. This commit adds a way to identify if the user is root and 22118 xfails the tests that expect no write access. 22119 22120 Approved-By: Tom de Vries <tdevries@suse.de> 22121 221222023-10-04 Neal Frager <neal.frager@amd.com> 22123 22124 ld: microblaze: ignore rwx segments 22125 The linker will generate warnings if it is creating an executable 22126 stack or a segment with all three read, write and execute permissions. 22127 These settings are not appropriate for all targets including 22128 MicroBlaze. 22129 221302023-10-04 Neal frager <neal.frager@amd.com> 22131 22132 opcodes: microblaze: Add hibernate and suspend instructions 22133 221342023-10-04 Luis Machado <luis.machado@arm.com> 22135 22136 sme2: Document SME2 registers and features 22137 Document changes introduced by gdb's SME2 support. 22138 22139 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 22140 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22141 221422023-10-04 Luis Machado <luis.machado@arm.com> 22143 22144 sme2: Extend SME tests to include SME2 22145 Reusing the SME tests, this patch introduces additional tests to exercise 22146 reading/writing ZT0, availability of the register set, signal context reading 22147 for ZT0 and also core file generation. 22148 22149 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22150 221512023-10-04 Luis Machado <luis.machado@arm.com> 22152 22153 sme2: Core file support for ZT register set 22154 This patch adds support for ZT register dumps/reads for core files. The 22155 ZT register is available when the SME2 feature is advertised as available 22156 by the Linux Kernel. 22157 22158 Unlike the enablement for SME1 and the ZA register, support for SME2 is rather 22159 simple given the fixed size of the ZT0 register. 22160 22161 Validated on the Fast Models. 22162 22163 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22164 221652023-10-04 Luis Machado <luis.machado@arm.com> 22166 22167 sme2: signal frame support 22168 Teach gdb about the ZT state on signal frames and how to restore 22169 the contents of the registers. 22170 22171 There is a new ZT_MAGIC context that the Linux Kernel uses to communicate 22172 the ZT register state to gdb. 22173 22174 As mentioned before, the ZT state should only be available when the ZA state 22175 is available. 22176 22177 Validated under Fast Models. 22178 22179 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22180 221812023-10-04 Luis Machado <luis.machado@arm.com> 22182 22183 sme2: Enable SME2 support in gdbserver 22184 This patch teaches gdbserver about the SME2 and the ZT0 register. 22185 22186 Since most of the code used by gdbserver for SME2 is shared with gdb, this 22187 is a rather small patch that reuses most of the code put in place for native 22188 AArch64 Linux. 22189 22190 Validated under Fast Models. 22191 22192 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22193 221942023-10-04 Luis Machado <luis.machado@arm.com> 22195 22196 sme2: Enable SME2 for AArch64 gdb on Linux 22197 SME2 defines a new 512-bit register named ZT0, and it is only available 22198 if SME is also supported. The ZT0 state is valid only if the SVCR ZA bit 22199 is enabled. Otherwise its contents are empty (0). 22200 22201 The target description is dynamic and gets generated at runtime based on the 22202 availability of the feature. 22203 22204 Validated under Fast Models. 22205 22206 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22207 222082023-10-04 Luis Machado <luis.machado@arm.com> 22209 22210 sme: Document SME registers and features 22211 Provide documentation for the SME feature and other information that 22212 should be useful for users that need to debug a SME-capable target. 22213 22214 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 22215 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22216 222172023-10-04 Luis Machado <luis.machado@arm.com> 22218 22219 sme: Add SVE/SME testcases 22220 Add 5 SVE/SME tests to exercise all the new features like reading/writing 22221 registers, pseudo-registers, signal frames and core files. 22222 22223 - Sanity check for SME: Gives a brief smoke test to make sure the most basic 22224 of features are working correctly. 22225 22226 - ZA unavailability tests: Validates the behavior/content of the ZA register 22227 is correct when no payload is available. It also exercises changing the 22228 vector lengths. 22229 22230 - ZA availability tests: These tests exercise reading/writing to all the 22231 possible ZA pseudo-registers, and validates the state is correct. 22232 22233 - Core file tests: Validates that core file reading and writing works 22234 correctly and that all state dumped/loaded is sane. This is exercised for 22235 both Linux Kernel core files and gcore core files. 22236 22237 - Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD 22238 values across signal frames. 22239 22240 Since some of these tests are very lengthy and take a little while to run 22241 (under QEMU at the moment), I decided to parallelize them into smaller 22242 chunks so we can throw some more CPU power at them so they run faster. 22243 22244 I'd still like to add a few more tests to give the testsuite more coverage 22245 in the areas of SME/SVE. Hopefully in the near future that will happen. 22246 22247 Just a reminder that these SME tests are currently unsupported when gdb is 22248 connected to a remote target. That's because the RSP doesn't support 22249 communicating changes in vector lenghts mid-execution, so gdb will always 22250 get wrong state from the remote target. 22251 22252 Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com> 22253 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22254 222552023-10-04 Luis Machado <luis.machado@arm.com> 22256 22257 sme: Core file support for Linux 22258 This patch enables dumping SME state via gdb's gcore command and also 22259 enables gdb to read SME state from a core file generated by the Linux 22260 Kernel. 22261 22262 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22263 22264 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22265 222662023-10-04 Luis Machado <luis.machado@arm.com> 22267 22268 corefile/bug: Add hook to control the use of target description notes from corefiles 22269 Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread 22270 can potentially have distinct target descriptions/gdbarches. 22271 22272 When loading a gcore-generated core file, at the moment GDB gives priority 22273 to the target description dumped to NT_GDB_TDESC. Though technically correct 22274 for most targets, it doesn't work correctly for AArch64 with SVE or SME 22275 support. 22276 22277 The correct approach for AArch64/Linux is to either have per-thread target 22278 description notes in the corefiles or to rely on the 22279 gdbarch_core_read_description hook, so it can figure out the proper target 22280 description for a given thread based on the various available register notes. 22281 22282 The former, although more correct, doesn't address the case of existing gdb's 22283 that only output a single target description note. 22284 22285 This patch goes for the latter, and adds a new gdbarch hook to conditionalize 22286 the use of the corefile target description note. The hook is called 22287 use_target_description_from_corefile_notes. 22288 22289 The hook defaults to returning true, meaning targets will use the corefile 22290 target description note. AArch64 Linux overrides the hook to return false 22291 when it detects any of the SVE or SME register notes in the corefile. 22292 22293 Otherwise it should be fine for AArch64 Linux to use the corefile target 22294 description note. 22295 22296 When we support per-thread target description notes, then we can augment 22297 the AArch64 Linux hook to rely on those notes. 22298 22299 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22300 22301 Approved-By: Simon Marchi <simon.marchi@efficios.com> 22302 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22303 223042023-10-04 Luis Machado <luis.machado@arm.com> 22305 22306 corefile/bug: Use thread-specific gdbarch when dumping register state to core files 22307 When we have a core file generated by gdb (via the gcore command), gdb dumps 22308 the target description to a note. During loading of that core file, gdb will 22309 first try to load that saved target description. 22310 22311 This works fine for almost all architectures. But AArch64 has a few 22312 dynamically-generated target descriptions/gdbarch depending on the vector 22313 length that was in use at the time the core file was generated. 22314 22315 The target description gdb dumps to the core file note is the one generated 22316 at the time of attachment/startup. If, for example, the SVE vector length 22317 changed during execution, this would not reflect on the core file, as gdb 22318 would still dump the initial target description. 22319 22320 Another issue is that the gdbarch potentially doesn't match the thread's 22321 real gdbarch, and so things like the register cache may have different formats 22322 and sizes. 22323 22324 To address this, fetch the thread's architecture before dumping its register 22325 state. That way we will always use the correct target description/gdbarch. 22326 22327 Approved-By: Simon Marchi <simon.marchi@efficios.com> 22328 Approved-By: Tom Tromey <tom@tromey.com> 22329 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22330 223312023-10-04 Luis Machado <luis.machado@arm.com> 22332 22333 Get rid of linux-core-thread-data 22334 This struct type seems to have been used in the past as a callback 22335 parameter. Now it seems that case is no longer true, so we can simplify 22336 things by passing the individual parameters linux_core_thread_data 22337 encapsulates directly to the functions. 22338 22339 This is just a cleanup before the next change. 22340 22341 Approved-By: Simon Marchi <simon.marchi@efficios.com> 22342 223432023-10-04 Luis Machado <luis.machado@arm.com> 22344 22345 sme: Support TPIDR2 signal frame context 22346 The Linux Kernel defines a separate context for the TPIDR2 register in a 22347 signal frame. Handle this additional context in gdb so this register 22348 gets restored properly when unwinding through signal frames. 22349 22350 The TPIDR2 register is closely related to SME, and is available when SME 22351 support is reported. 22352 22353 This is tested by testcases that are available in a later patch in the series. 22354 22355 Regressions-tested on aarch64-linux Ubuntu 22.04/20.04. 22356 22357 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22358 223592023-10-04 Luis Machado <luis.machado@arm.com> 22360 22361 sme: Fixup sigframe gdbarch when vg/svg changes 22362 With SME, where you have two different vector lengths (vl and svl), it may be 22363 the case that the current frame has a set of vector lengths (A) but the signal 22364 context has a distinct set of vector lengths (B). 22365 22366 In this case, we may run into a situation where GDB attempts to use a gdbarch 22367 created for set A, but it is really dealing with a frame that was using set 22368 B. 22369 22370 This is problematic, specially with SME, because now we have a different 22371 number of pseudo-registers and types that gets cached on creation of each 22372 gdbarch variation. 22373 22374 For AArch64 we really need to be able to use the correct gdbarch for each 22375 frame, and I noticed the signal frame (tramp-frame) doesn't have a settable 22376 prev_arch field. So it ends up using the default frame_unwind_arch function 22377 and eventually calling get_frame_arch (next_frame). That means the previous 22378 frame will always have the same gdbarch as the current frame. 22379 22380 This patch first refactors the AArch64/Linux signal context code, simplifying 22381 it and making it reusable for our purposes of calculating the previous frame's 22382 gdbarch. 22383 22384 I introduced a struct that holds information that we have found in the signal 22385 context, and with which we can make various decisions. 22386 22387 Finally, a small change to tramp-frame.c and tramp-frame.h to expose a 22388 prev_arch hook that the architecture can set. 22389 22390 With this new field, AArch64/Linux can implement a hook that looks at the 22391 signal context and infers the gdbarch for the previous frame. 22392 22393 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22394 22395 Approved-By: Simon Marchi <simon.marchi@efficios.com> 22396 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22397 223982023-10-04 Luis Machado <luis.machado@arm.com> 22399 22400 sme: Signal frame support 22401 Teach gdb about the ZA/SSVE state on signal frames and how to restore 22402 the contents of the registers. 22403 22404 There is a new ZA_MAGIC context that the Linux Kernel uses to communicate 22405 the ZA register state to gdb. 22406 22407 The SVE_MAGIC context has also been adjusted to contain a flag indicating 22408 whether it is a SVE or SSVE state. 22409 22410 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22411 22412 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22413 224142023-10-04 Luis Machado <luis.machado@arm.com> 22415 22416 sve: Fix signal frame z/v register restore 22417 While doing some SME work, I ran into the situation where the Z register 22418 contents restored from a signal frame are incorrect if the signal frame 22419 only contains fpsimd state and no sve state. 22420 22421 This happens because we only restore the v register values in that case, 22422 and don't do anything for the z registers. 22423 22424 Fix this by initializing the z registers to 0 and then copying over the 22425 overlapping part of the v registers to the z registers. 22426 22427 While at it, refactor the code a bit to simplify it and make it smaller. 22428 22429 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22430 22431 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22432 224332023-10-04 Luis Machado <luis.machado@arm.com> 22434 22435 sme: Add support for SME 22436 Enable SME support in gdbserver by adjusting the usual fields. There is 22437 not much to this patch because the code is either in gdb or it is shared 22438 between gdbserver and gdb. One exception is the bump to gdbserver's 22439 PBUFSIZ from 18432 to 131104. 22440 22441 Since the ZA register can be quite big (256 * 256 bytes), the g/G remote 22442 packet will also become quite big 22443 22444 From gdbserver/tdesc.cc:init_target_desc, I estimated the new size should 22445 be at least (2 * 256 * 256 + 32), which yields 131104. 22446 22447 It is also unlikely we will find a process starting up with SVL set to 256. 22448 22449 Ideally we'd adjust the packet size dynamically based on what we need, but 22450 for now this should do. 22451 22452 Please note we have the same limitation for SME that we have for SVE, and 22453 that is the fact gdbserver cannot communicate vector length changes to gdb 22454 via the remote protocol. 22455 22456 Thiago is working on this improvement, which hopefully will be able to be 22457 adapted to SME in an easy way. 22458 22459 Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com> 22460 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22461 224622023-10-04 Luis Machado <luis.machado@arm.com> 22463 22464 refactor: Adjust expedited registers dynamically 22465 Instead of using static arrays, build the list of expedited registers 22466 dynamically using a std::vector. 22467 22468 This refactor shouldn't cause any user-visible changes. 22469 22470 Regression-tested for aarch64-linux Ubuntu 22.04/20.04. 22471 22472 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22473 224742023-10-04 Luis Machado <luis.machado@arm.com> 22475 22476 Convert tdesc's expedite_regs to a string vector 22477 Right now the list of expedited registers is stored as an array of char *, 22478 with a nullptr element at the end to signal its last element. 22479 22480 Convert expedite_regs to a std::vector of std::string so it is easier to 22481 manage the elements and the storage is handled automatically. 22482 22483 Eventually we might want to convert all the target functions so they pass a 22484 std::vector of std::string as well. Or maybe expose an interface that target can 22485 use to add expedited registers on-by-one depending on the target description 22486 discovery needs, as opposed to just a static list of char *. 22487 22488 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22489 Approved-By: Tom Tromey <tom@tromey.com> 22490 224912023-10-04 Luis Machado <luis.machado@arm.com> 22492 22493 sme: Enable SME registers and pseudo-registers 22494 The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with 22495 variable sizes. It also exposes a new mode called streaming mode. 22496 22497 Similarly to SVE, the ZA register size is dictated by a vector length, but the 22498 SME vector length is called streaming vetor length. The total size for 22499 ZA in a given moment is svl x svl. 22500 22501 In streaming mode, the SVE registers have their sizes based on svl rather than 22502 the regular vector length (vl). 22503 22504 The feature detection is controlled by the HWCAP2_SME bit, but actual support 22505 should be validated by attempting a ptrace call for one of the new register 22506 sets: NT_ARM_ZA and NT_ARM_SSVE. 22507 22508 Due to its large size, the ZA register is exposed as a vector of bytes, but we 22509 introduce a number of pseudo-registers that gives various different views 22510 into the ZA contents. These can be arranged in a couple categories: tiles and 22511 tile slices. 22512 22513 Tiles are matrices the same size or smaller than ZA. Tile slices are vectors 22514 which map to ZA's rows/columns in different ways. 22515 22516 A new dynamic target description is provided containing the ZA register, the SVG 22517 register and the SVCR register. The size of ZA, like the SVE vector registers, 22518 is based on the vector length register SVG (VG for SVE). 22519 22520 This patch enables SME register support for gdb. 22521 22522 [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture 22523 22524 Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com> 22525 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22526 225272023-10-04 Luis Machado <luis.machado@arm.com> 22528 22529 sve: Fix return command when using V registers in a SVE-enabled target 22530 In a target without SVE support, the V registers have a size of 16 bytes, 22531 otherwise they may have a size bigger than 16 bytes (depending on the current 22532 vector length for the Z registers, as they overlap the V registers). 22533 22534 In aarch64-tdep.c:aarch64_store_return_value, the code is laid 22535 out in a way that allocates the buffer with the size of the register, but 22536 only updates the amount of bytes for the particular type we're returning. 22537 22538 This may cause a situation where we have a register size of 32 bytes but 22539 are returning a floating point value of 8 bytes. The temporary buffer 22540 will therefore have 32 bytes, but we'll only update 8 bytes of it. 22541 22542 When we write the entire register back, it will have potentially 24 bytes 22543 of garbage in it. 22544 22545 Fix this by first reading the original contents of the register and then 22546 overriding only the bytes that we need for the return value. 22547 22548 Tested on aarch64-linux Ubuntu 22.04/20.04. 22549 22550 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22551 225522023-10-04 Luis Machado <luis.machado@arm.com> 22553 22554 refactor: Simplify SVE interface to read/write registers 22555 This is a patch in preparation to upcoming patches enabling SME support. It 22556 attempts to simplify the gdb/gdbserver shared interface used to read/write 22557 SVE registers. 22558 22559 Where the current code makes use of unique_ptr, allocating a new buffer by 22560 hand and passing a buffer around, this patch makes that code use 22561 gdb::byte_vector and passes a reference to this byte vector to the functions, 22562 allowing the functions to have ready access to the size of the buffer. 22563 22564 It also shares a bit more code between gdb and gdbserver, in particular around 22565 handling of ptrace get/set requests for SVE. 22566 22567 I think gdbserver could be refactored to handle register reads/writes more 22568 like gdb's native layer as opposed to letting the generic linux-low layer do 22569 the ptrace calls. This is not very flexible and assumes one size for the 22570 responses. If you have something like NT_ARM_SVE, where you can have either 22571 FPSIMD or SVE contents, it doesn't work that well. 22572 22573 I didn't want to change that interface right now as it is a bit too much work 22574 and touches all the targets, some of which I can't easily test. 22575 22576 Hence the reason why the buffer the generic linux-now passes down to 22577 linux-aarch64-low is unused or ignored. 22578 22579 No user-visible changes should happen as part of this refactor other than a 22580 slightly reworded warning message. 22581 22582 While doing the refactor, I also noticed what seems to be a mistake in checking 22583 if the register cache contains active (non-zero) SVE data. 22584 22585 For instance, the original code did something like this in 22586 aarch64_sve_regs_copy_from_reg_buf: 22587 22588 has_sve_state |= reg_buf->raw_compare (AARCH64_SVE_Z0_REGNUM + i 22589 reg, sizeof (__int128_t)); 22590 22591 "reg" is a zeroed-out buffer that we compare the Z register contents 22592 past the first 128 bits. The problem here is that raw_compare returns 22593 1 if the contents compare the same, which means has_sve_state will be 22594 true. But if we compared the Z register contents to 0, it means we 22595 *do not* have SVE state, and therefore has_sve_state should be false. 22596 22597 The consequence of this mistake is that we convert the initial 22598 FPSIMD-formatted data we get from ptrace for the NT_ARM_SVE register 22599 set to a SVE-formatted one. 22600 22601 In the end, this doesn't cause user-visible differences because the 22602 values of both the Z and V registers will still be the same. But the 22603 logic is not correct. 22604 22605 I used the opportunity to fix this, and it gets tested later on by 22606 the additional SME tests. 22607 22608 I do plan on submitting some SVE-specific tests to make sure we have 22609 a bit more coverage in GDB's testsuite. 22610 22611 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22612 22613 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22614 226152023-10-04 Luis Machado <luis.machado@arm.com> 22616 22617 refactor: Rename SVE-specific files 22618 In preparation to the SME support patches, rename the SVE-specific files to 22619 something a bit more meaningful that can be shared with the SME code. 22620 22621 In this case, I've renamed the "sve" in the names to "scalable". 22622 22623 No functional changes. 22624 22625 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22626 22627 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22628 226292023-10-04 Luis Machado <luis.machado@arm.com> 22630 22631 Fix register fetch/store order for native AArch64 Linux 22632 I noticed we don't handle register reads/writes in the best way for native 22633 AArch64 Linux. Some other registers are fetched/stored even if upper level 22634 code told us to fetch a particular register number. 22635 22636 Fix this by being more strict about which registers we touch when 22637 reading/writing them in the native AArch64 Linux layer. 22638 22639 There should be no user-visible changes due to this patch. 22640 22641 Regression-tested on aarch64-linux Ubuntu 22.04/20.04. 22642 22643 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> 22644 226452023-10-04 Victor Do Nascimento <victor.donascimento@arm.com> 22646 22647 aarch64: Refactor system register data 22648 This patch moves instances of system register definitions, represented 22649 by the SYSREG macro, out of their original place in `aarch64-opc.c' 22650 and into a dedicated .def file, `aarch64-sys-regs.def'. 22651 22652 System register entries in this new file are ordered alphabetically by 22653 name. This choice is made to enable the use of fast search algorithms 22654 such as binary search when validating register names. 22655 22656 The SYSREG macro, defined as SYSREG (name, encoding, flags, features) 22657 is kept as is and used in the def file, but all other SR_* macros 22658 which previously served as indirections to SYSREG are removed. 22659 22660 opcodes/ChangeLog: 22661 * aarch64-opc.c (SR_CORE): Macro definition and uses deleted. 22662 (SR_FEAT): Likewise. 22663 (SR_FEAT2): Likewise. 22664 (SR_V8_1_A): Likewise. 22665 (SR_V8_4_A): Likewise. 22666 (SR_V8A): Likewise. 22667 (SR_V8R): Likewise. 22668 (SR_V8_1A): Likewise. 22669 (SR_V8_2A): Likewise. 22670 (SR_V8_3A): Likewise. 22671 (SR_V8_4A): Likewise. 22672 (SR_V8_6A): Likewise. 22673 (SR_V8_7A): Likewise. 22674 (SR_V8_8A): Likewise. 22675 (SR_GIC): Likewise. 22676 (SR_AMU): Likewise. 22677 (SR_LOR): Likewise. 22678 (SR_PAN): Likewise. 22679 (SR_RAS): Likewise. 22680 (SR_RNG): Likewise. 22681 (SR_SME): Likewise. 22682 (SR_SSBS): Likewise. 22683 (SR_SVE): Likewise. 22684 (SR_ID_PFR2): Likewise. 22685 (SR_PROFILE): Likewise. 22686 (SR_MEMTAG): Likewise. 22687 (SR_SCXTNUM): Likewise. 22688 (SR_EXPAND_ELx): Likewise. 22689 (SR_EXPAND_EL12): Likewise. 22690 * opcodes/aarch64-sys-regs.def: New. 22691 226922023-10-04 Victor Do Nascimento <victor.donascimento@arm.com> 22693 22694 aarch64: system register aliasing detection 22695 This patch adds a mechanism for system register name alias detection 22696 to register-matching mechanisms. 22697 22698 A new `F_REG_ALIAS' flag is added to the set of register flags and 22699 used to label which entries in aarch64_sys_regs[] correspond to 22700 aliases (and thus which CPENC values are non-unique in this array). 22701 22702 Where this is used is, for example, in `aarch64_print_operand' where, 22703 in the case of system register decoding, the aarch64_sys_regs[] array 22704 is iterated through until a match in CPENC value is made and the first 22705 match accepted. If insufficient care is given in the ordering of 22706 system registers in this array, the alias is encountered before the 22707 "real" register and used incorrectly as the register name in the 22708 disassembled output. 22709 22710 With this flag and the new `aarch64_sys_reg_alias_p' test, search 22711 candidates corresponding to aliases can be conveniently skipped over. 22712 22713 One concrete example of where this is useful is with the 22714 `trcextinselr0' system register. It was initially placed in the 22715 system register list before `trcextinselr', in contrast to a more 22716 natural alphabetical order. 22717 22718 include/ChangeLog: 22719 * opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype. 22720 22721 opcodes/ChangeLog: 22722 * aarch64-opc.c (aarch64_sys_reg_alias_p): New. 22723 (aarch64_print_operand): add aarch64_sys_reg_alias_p check. 22724 (aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr" 22725 entry. 22726 * aarch64-opc.h (F_REG_ALIAS): New. 22727 227282023-10-04 GDB Administrator <gdbadmin@sourceware.org> 22729 22730 Automatic date update in version.in 22731 227322023-10-03 Andrew Burgess <aburgess@redhat.com> 22733 22734 gdb/corefile: write NT_GDB_TDESC based on signalled thread 22735 When creating a core file from within GDB we include a NT_GDB_TDESC 22736 that includes the target description of the architecture in use. 22737 22738 For architectures with dynamic architectures (e.g. AArch64 with 22739 sve/sme) the original architecture, calculated from the original 22740 target description, might not match the per-thread architecture. 22741 22742 In the general case, where each thread has a different architecture, 22743 then we really need a separate NT_GDB_TDESC for each thread, however, 22744 there's currently no way to read in multiple NT_GDB_TDESC. 22745 22746 This commit is a step towards per-thread NT_GDB_TDESC. In this commit 22747 I have updated the function that writes the NT_GDB_TDESC to accept a 22748 gdbarch (rather than calling target_gdbarch() to find a gdbarch), and 22749 I now pass in the gdbarch of the signalled thread. 22750 22751 In many cases (though NOT all) targets with dynamic architectures 22752 really only use a single architecture, even when there are multiple 22753 threads, so in the common case, this should ensure that GDB emits an 22754 architecture that is more likely to be correct. 22755 22756 Additional work will be needed in order to support corefiles with 22757 truly per-thread architectures, but that will need to be done in the 22758 future. 22759 227602023-10-03 YunQiang Su <yunqiang.su@cipunited.com> 22761 22762 MIPS: Fix `readelf -S bintest' test for n64 targets 22763 Add a 64-bit traditional MIPS dump variant for the `readelf -S bintest' 22764 test from binutils-all/readelf.exp, using a filename suffix according to 22765 the rules set there, removing: 22766 22767 FAIL: readelf -S bintest 22768 22769 regressions with `mips64-linux-gnuabi64', `mips64el-linux-gnuabi64', 22770 `mips64-openbsd', and `mips64el-openbsd' targets, which default to the 22771 n64 ABI and consequently produce a section layout that is different from 22772 what the generic dump pattern covers. 22773 22774 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 22775 22776 binutils/ 22777 * testsuite/binutils-all/readelf.s-64-tmips: New test variant. 22778 227792023-10-03 Vsevolod Alekseyev <sevaa@sprynet.com> 22780 22781 Fix: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx 22782 PR 29267 22783 * dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation. (read_and_display_attr_value): Replace uses of fetch_indexed_value with fetch_indexed_offset. 22784 227852023-10-03 GDB Administrator <gdbadmin@sourceware.org> 22786 22787 Automatic date update in version.in 22788 227892023-10-02 Andrew Burgess <aburgess@redhat.com> 22790 22791 gdb/python: reformat file with black 22792 Reformat a Python file with black after this commit: 22793 22794 commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f 22795 Date: Tue Sep 19 11:45:36 2023 +0100 22796 22797 gdb: add Python events for program space addition and removal 22798 22799 There should be no functional change with this commit. 22800 228012023-10-02 Tom Tromey <tromey@adacore.com> 22802 22803 Add regression test for instructionReference change 22804 Yesterday I pushed a patch to fix a small oversight in the DAP code 22805 that caused an instructionReference to be an array instead of a 22806 string. 22807 22808 This patch adds a test case for that regression. This required 22809 exposing the TON form of the response -- something I mentioned might 22810 be necessary when this code was changed to return just the Tcl form. 22811 22812 I tested this by backing out yesterday's bug fix and verifying that a 22813 failure is seen. 22814 228152023-10-02 Tom Tromey <tromey@adacore.com> 22816 22817 Clean up intermediate values in val_print_packed_array_elements 22818 Following on Tom de Vries' work in the other array-printers, this 22819 patch changes val_print_packed_array_elements to also avoid allocating 22820 too many values when printing an Ada packed array. 22821 228222023-10-02 Simon Marchi <simon.marchi@efficios.com> 22823 22824 gdb/testsuite: accept variable number of spaces in gdb.base/jit-reader-simple.exp regex 22825 I see this failure: 22826 22827 FAIL: gdb.base/jit-reader-simple.exp: standalone: change addr: initial run: maint info breakpoints shows jit breakpoint 22828 22829 The jit breakpoint expected by the test is there, it's just that the 22830 number of spaces doesn't match what the test expects, after "jit 22831 events": 22832 22833 -2 jit events keep y 0x0000555555555119 <__jit_debug_register_code> inf 1 22834 22835 Fix that by relaxing the regex a bit. 22836 22837 Change-Id: Ia3b04e6d5978399d940fd1a590f95f15275ca7ac 22838 228392023-10-02 Aaron Merey <amerey@redhat.com> 22840 22841 gdb: Add command 'maint set/show debuginfod download-sections' 22842 This setting controls whether GDB may attempt to download ELF/DWARF 22843 sections from debuginfod servers. 22844 22845 This setting is enabled by default if gdb is built with debuginfod 22846 section download support (requires libdebuginfod 0.188). 22847 22848 Also update debuginfod command help text and gdb.texinfo with 22849 information on section downloading and the new command. 22850 22851 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 22852 Approved-By: Andrew Burgess <aburgess@redhat.com> 22853 228542023-10-02 Aaron Merey <amerey@redhat.com> 22855 22856 gdb/debuginfod: Add debuginfod_section_query 22857 Add new function debuginfod_section_query. This function queries 22858 debuginfod servers for an individual ELF/DWARF section associated with 22859 a given build-id. 22860 22861 Approved-By: Andrew Burgess <aburgess@redhat.com> 22862 228632023-10-02 Tom de Vries <tdevries@suse.de> 22864 22865 [gdb/testsuite] Handle older gcc in gdb.ada/import.exp 22866 When running test-case gdb.ada/import.exp with gcc 7, most test fail: 22867 ... 22868 FAIL: gdb.ada/import.exp: print imported_var_ada 22869 FAIL: gdb.ada/import.exp: print local_imported_var 22870 FAIL: gdb.ada/import.exp: print pkg.imported_var_ada 22871 FAIL: gdb.ada/import.exp: print pkg.exported_var_ada 22872 FAIL: gdb.ada/import.exp: print exported_var_ada 22873 FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada 22874 FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada 22875 FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func 22876 ... 22877 22878 When running with gcc 8 or 9, only 2 tests fail: 22879 ... 22880 FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada 22881 FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada 22882 ... 22883 22884 The test-case passes fully with gcc 10, 11, 12 and 13. 22885 22886 Debug info for pragma import seems to not have been supported before gcc 8, so 22887 require that version. 22888 22889 The two FAILs with gcc 8 and 9 seem to be due to problems in debug info. Add 22890 an xfail for these. 22891 22892 Tested on x86_64-linux. 22893 22894 Approved-By: Tom Tromey <tom@tromey.com> 22895 228962023-10-02 Tom de Vries <tdevries@suse.de> 22897 22898 [gdb/testsuite] Add KFAIL for PR ada/30908 22899 With gcc 13.2.1, I run into a cluster of fails: 22900 ... 22901 FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD" 22902 FAIL: gdb.ada/widewide.exp: print my_wws = " helo" 22903 FAIL: gdb.ada/widewide.exp: print my_ws = "wide" 22904 ... 22905 22906 The problem is that the debug info contains information about function 22907 ada.strings.maps."=", and gdb uses it to implement the comparison. 22908 The function is supposed to compare two char sets, not strings, so gdb 22909 shouldn't use it. This is PR ada/30908. 22910 22911 I don't see the same problem with gcc 7.5.0, because the exec doesn't contain 22912 the debug info for the function, because the corresponding object is not 22913 linked in. Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to 22914 gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0. 22915 22916 Add KFAILs for the PR. 22917 22918 Tested on x86_64-linux: 22919 - openSUSE Leap 15.4 (using gcc 7.5.0), and 22920 - openSUSE Tumbleweed (using gcc 13.2.1). 22921 22922 Approved-By: Tom Tromey <tom@tromey.com> 22923 22924 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908 22925 229262023-10-02 Andrew Burgess <aburgess@redhat.com> 22927 22928 gdb: add Python events for program space addition and removal 22929 Initially I just wanted a Python event for when GDB removes a program 22930 space, I'm writing a Python extension that caches information for each 22931 program space, and need to know when I should discard entries for a 22932 particular program space. 22933 22934 But, it seemed easy enough to also add an event for when GDB adds a 22935 new program space, so I went ahead and added both new events. 22936 22937 Of course, we don't currently have an observable for program space 22938 addition or removal, so I first needed to add these. After that it's 22939 pretty simple to add two new Python events and have these trigger. 22940 22941 The two new event registries are: 22942 22943 events.new_progspace 22944 events.free_progspace 22945 22946 These emit NewProgspaceEvent and FreeProgspaceEvent objects 22947 respectively, each of these new event types has a 'progspace' 22948 attribute that contains the relevant gdb.Progspace object. 22949 22950 There's a couple of things to be mindful of. 22951 22952 First, it is not possible to catch the NewProgspaceEvent for the very 22953 first program space, the one that is created when GDB first starts, as 22954 this program space is created before any Python scripts are sourced. 22955 22956 In order to allow this event to be caught we would need to defer 22957 creating the first program space, and as a consequence the first 22958 inferior, until some later time. But, existing scripts could easily 22959 depend on there being an initial inferior, so I really don't think we 22960 should change that -- and so, we end up with the consequence that we 22961 can't catch the event for the first program space. 22962 22963 The second, I think minor, issue, is that GDB doesn't clean up its 22964 program spaces upon exit -- or at least, they are not cleaned up 22965 before Python is shut down. As a result, any program spaces in use at 22966 the time GDB exits don't generate a FreeProgspaceEvent. I'm not 22967 particularly worried about this for my use case, I'm using the event 22968 to ensure that a cache doesn't hold stale entries within a single GDB 22969 session. It's also easy enough to add a Python at-exit callback which 22970 can do any final cleanup if needed. 22971 22972 Finally, when testing, I did hit a slightly weird issue with some of 22973 the remote boards (e.g. remote-stdio-gdbserver). As a consequence of 22974 this issue I see some output like this in the gdb.log: 22975 22976 (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 22977 step 22978 FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10> 22979 warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. 22980 Use the "interrupt" command to stop the target 22981 and then try again. 22982 warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running. 22983 Use the "interrupt" command to stop the target 22984 and then try again. 22985 warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running. 22986 Use the "interrupt" command to stop the target 22987 and then try again. 22988 do_parent_stuff () at py-progspace-events.c:41 22989 41 ++global_var; 22990 (gdb) PASS: gdb.python/py-progspace-events.exp: step 22991 22992 The 'FreeProgspaceEvent ...' line is expected, that's my test Python 22993 extension logging the event. What isn't expected are all the blocks 22994 like: 22995 22996 warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. 22997 Use the "interrupt" command to stop the target 22998 and then try again. 22999 23000 It turns out that this has nothing to do with my changes, this is just 23001 a consequence of reading files over the remote protocol. The test 23002 forks a child process which GDB stays attached too. When the child 23003 exits, GDB cleans up by calling prune_inferiors, which in turn can 23004 result in GDB trying to close some files that are open because of the 23005 inferior being deleted. 23006 23007 If the prune_inferiors call occurs when the remote target is 23008 running (and in non-async mode) then GDB will try to send a fileio 23009 packet while the remote target is waiting for a stop reply, and the 23010 remote target will throw an error, see remote_target::putpkt_binary in 23011 remote.c for details. 23012 23013 I'm going to look at fixing this, but, as I said, this is nothing to 23014 do with this change, I just mention it because I ended up needing to 23015 account for these warning messages in one of my tests, and it all 23016 looks a bit weird. 23017 23018 Approved-By: Tom Tromey <tom@tromey.com> 23019 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23020 230212023-10-02 Simon Marchi <simon.marchi@efficios.com> 23022 23023 gdb: remove solib::pspace field 23024 This backlink is not necessary, we always know the program space from 23025 the context. Pass it down the solib_unloaded observer. 23026 23027 Change-Id: I45a503472dc791f517558b8141901472634e0556 23028 Approved-By: Tom Tromey <tom@tromey.com> 23029 230302023-10-02 Nick Clifton <nickc@redhat.com> 23031 23032 Fix memory leak in RiscV assembler. 23033 PR 30861 23034 * config/tc-riscv.c (riscv_insert_uleb128_fixes): Release duplicated memory. 23035 23036 Use bfd_get_current_time in places where it is suitable 23037 230382023-10-02 GDB Administrator <gdbadmin@sourceware.org> 23039 23040 Automatic date update in version.in 23041 230422023-10-01 GDB Administrator <gdbadmin@sourceware.org> 23043 23044 Automatic date update in version.in 23045 230462023-09-30 GDB Administrator <gdbadmin@sourceware.org> 23047 23048 Automatic date update in version.in 23049 230502023-09-29 Tom Tromey <tom@tromey.com> 23051 23052 Support the NO_COLOR environment variable 23053 I ran across this site: 23054 23055 https://no-color.org/ 23056 23057 ... which lobbies for tools to recognize the NO_COLOR environment 23058 variable and disable any terminal styling when it is seen. 23059 23060 This patch implements this for gdb. 23061 23062 Regression tested on x86-64 Fedora 38. 23063 23064 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 23065 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 23066 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23067 Approved-By: Andrew Burgess <aburgess@redhat.com> 23068 230692023-09-29 Neal Frager <neal.frager@amd.com> 23070 23071 tc-microblaze.c - int compare for X_add_number. 23072 The range check should be checking for the range 23073 ffffffff80000000..7fffffff, not ffffffff70000000. 23074 23075 This patch has been tested for years of AMD Xilinx Yocto 23076 releases as part of the following patch set: 23077 23078 https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils 23079 230802023-09-29 Neal Frager <neal.frager@amd.com> 23081 23082 bfd: microblaze: Fix bug in TLSTPREL Relocation 23083 Fixed the problem related to the fixup/relocations TLSTPREL. 23084 When the fixup is applied the addend is not added at the correct offset 23085 of the instruction. The offset is hard coded considering its big endian 23086 and it fails for Little endian. This patch allows support for both 23087 big & little-endian compilers. 23088 23089 This patch has been tested for years of AMD Xilinx Yocto 23090 releases as part of the following patch set: 23091 23092 https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils 23093 230942023-09-29 H.J. Lu <hjl.tools@gmail.com> 23095 23096 x86-64: Add -z mark-plt and -z nomark-plt 23097 The PLT entry in executables and shared libraries contains an indirect 23098 branch, like 23099 23100 jmp *foo@GOTPCREL(%rip) 23101 push $index_foo 23102 jmp .PLT0 23103 23104 or 23105 23106 endbr64 23107 jmp *foo@GOTPCREL(%rip) 23108 NOP padding 23109 23110 which is used to branch to the function, foo, defined in another object. 23111 Each R_X86_64_JUMP_SLOT relocation has a corresponding PLT entry. 23112 23113 The dynamic tags have been added to the x86-64 psABI to mark such PLT 23114 entries: 23115 23116 https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6d824a52a42d173eb838b879616c1be5870b593e 23117 23118 Add an x86-64 linker option, -z mark-plt, to mark PLT entries with 23119 23120 #define DT_X86_64_PLT (DT_LOPROC + 0) 23121 #define DT_X86_64_PLTSZ (DT_LOPROC + 1) 23122 #define DT_X86_64_PLTENT (DT_LOPROC + 3) 23123 23124 1. DT_X86_64_PLT: The address of the procedure linkage table. 23125 2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage 23126 table. 23127 3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table 23128 entry. 23129 23130 and set the r_addend field of the R_X86_64_JUMP_SLOT relocation to the 23131 memory offset of the indirect branch instruction. The dynamic linker 23132 can use these tags to update the PLT section to direct branch. 23133 23134 bfd/ 23135 23136 * elf-linker-x86.h (elf_linker_x86_params): Add mark_plt. 23137 * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Set the 23138 r_addend of R_X86_64_JUMP_SLOT to the indirect branch offset 23139 in PLT entry for -z mark-plt. 23140 * elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Add 23141 DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT for 23142 -z mark-plt. 23143 (_bfd_x86_elf_finish_dynamic_sections): Set DT_X86_64_PLT, 23144 DT_X86_64_PLTSZ and DT_X86_64_PLTENT. 23145 (_bfd_x86_elf_get_synthetic_symtab): Ignore addend for 23146 JUMP_SLOT relocation. 23147 (_bfd_x86_elf_link_setup_gnu_properties): Set 23148 plt_indirect_branch_offset. 23149 * elfxx-x86.h (elf_x86_plt_layout): Add plt_indirect_branch_offset. 23150 23151 binutils/ 23152 23153 * readelf.c (get_x86_64_dynamic_type): New function. 23154 (get_dynamic_type): Call get_x86_64_dynamic_type. 23155 23156 include/ 23157 23158 * elf/x86-64.h (DT_X86_64_PLT): New. 23159 (DT_X86_64_PLTSZ): Likewise. 23160 (DT_X86_64_PLTENT): Likewise. 23161 23162 ld/ 23163 23164 * ld.texi: Document -z mark-plt and -z nomark-plt. 23165 * emulparams/elf32_x86_64.sh: Source x86-64-plt.sh. 23166 * emulparams/elf_x86_64.sh: Likewise. 23167 * emulparams/x86-64-plt.sh: New file. 23168 * testsuite/ld-x86-64/mark-plt-1.s: Likewise. 23169 * testsuite/ld-x86-64/mark-plt-1a-x32.d: Likewise. 23170 * testsuite/ld-x86-64/mark-plt-1a.d: Likewise. 23171 * testsuite/ld-x86-64/mark-plt-1b-x32.d: Likewise. 23172 * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. 23173 * testsuite/ld-x86-64/mark-plt-1c-x32.d: Likewise. 23174 * testsuite/ld-x86-64/mark-plt-1c.d: Likewise. 23175 * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. 23176 * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. 23177 * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt tests. 23178 231792023-09-29 Nick Clifton <nickc@redhat.com> 23180 23181 Fix: Segmentation fault caused by npd in objdump 23182 PR 30906 23183 * elf.c (_bfd_elf_slurp_version_tables): Test that the verref section header has been initialised before using it. 23184 23185 Update README file's installation instructions 23186 231872023-09-29 Sam James <sam@gentoo.org> 23188 23189 gdb: add Sam James to MAINTAINERS 23190 Acked-by: Tom de Vries <tdevries@suse.de> 23191 231922023-09-29 Kevin Buettner <kevinb@redhat.com> 23193 23194 gdb/testsuite: Add relative versus absolute LD_LIBRARY_PATH test 23195 At one time, circa 2006, there was a bug, which was presumably fixed 23196 without adding a test case: 23197 23198 If you provided some relative path to the shared library, such as 23199 with 23200 23201 export LD_LIBRARY_PATH=. 23202 23203 then gdb would fail to match the shared library name during the 23204 TLS lookup. 23205 23206 I think there may have been a bit more to it than is provided by that 23207 explanation, since the test also takes care to split the debug info 23208 into a separate file. 23209 23210 In any case, this commit is based on one of Red Hat's really old 23211 local patches. I've attempted to update it and remove a fair amount 23212 of cruft, hopefully without losing any critical elements from the 23213 test. 23214 23215 Testing on Fedora 38 (correctly) shows 1 unsupported test for 23216 native-gdbserver and 5 PASSes for the native target as well as 23217 native-extended-gdbserver. 23218 23219 In his review of v1 of this patch, Lancelot SIX observed that 23220 'thread_local' could be used in place of '__thread' in the C source 23221 files. But it only became available via the standard in C11, so I 23222 used additional_flags=-std=c11 for compiling both the shared object 23223 and the main program. 23224 23225 Also, while testing with CC_FOR_TARGET=clang, I found that 23226 'additional_flags=-Wl,-soname=${binsharedbase}' caused clang 23227 to complain that this linker flag was unused when compiling 23228 the source file, so I moved this linker option to 'ldflags='. 23229 23230 My testing for this v2 patch shows the same results as with v1, 23231 but I've done additional testing with CC_FOR_TARGET=clang as 23232 well. The results are the same as when gcc is used. 23233 23234 Co-Authored-by: Jan Kratochvil <jan@jankratochvil.net> 23235 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23236 232372023-09-29 Simon Marchi <simon.marchi@efficios.com> 23238 23239 gdb: remove nbsd_{ilp32,lp64}_solib_svr4_fetch_link_map_offsets 23240 They are unused. 23241 23242 Change-Id: I9b78837d41126ce1957aa1e8b08c82a422f06cbf 23243 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 23244 232452023-09-29 Simon Marchi <simon.marchi@efficios.com> 23246 23247 gdb: remove unused imports in solib*.[ch] 23248 I'm starting to work on these files, I thought it would be a good time 23249 to remove unused imports. These were identified by 23250 include-what-you-use. Tested by rebuilding. 23251 23252 Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8 23253 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 23254 232552023-09-29 GDB Administrator <gdbadmin@sourceware.org> 23256 23257 Automatic date update in version.in 23258 232592023-09-28 Michael J. Eager <eager@eagercon.com> 23260 23261 Added support in gas for mlittle-endian and mbig-endian flags as options. 23262 Updated show usage for MicroBlaze specific assembler options 23263 to include new entries. 23264 23265 This patch has been tested for years of AMD Xilinx Yocto 23266 releases as part of the following patch set: 23267 23268 https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils 23269 23270 23271 --- 23272 V1->V2: 23273 - removed new options which were unnecessary 23274 - added documentation for MicroBlaze specific options 23275 232762023-09-28 Tom de Vries <tdevries@suse.de> 23277 23278 [gdb/tui] Fix segfault in tui_find_disassembly_address 23279 PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp 23280 and target board unix/-m32. 23281 23282 The FAIL happens due to the test executable running into an assert, which is 23283 caused by a forked child segfaulting, like so: 23284 ... 23285 Program terminated with signal SIGSEGV, Segmentation fault. 23286 #0 0x00000000 in ?? () 23287 ... 23288 23289 I tried to reproduce the segfault with exec next-fork-other-thread-fork, using 23290 TUI layout asm. 23291 23292 I set a breakpoint at fork and ran to the breakpoint, and somewhere during the 23293 following session I ran into a gdb segfault here in 23294 tui_find_disassembly_address: 23295 ... 23296 /* Disassemble forward. */ 23297 next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines); 23298 last_addr = asm_lines.back ().addr; 23299 ... 23300 due to asm_lines being empty after the call to tui_disassemble, while 23301 asm_lines.back () assumes that it's not empty. 23302 23303 I have not been able to reproduce that segfault in that original setting, I'm 23304 not sure of the exact scenario (though looking back it probably involved 23305 "set detach-on-fork off"). 23306 23307 What likely happened is that I managed to reproduce PR29040, and TUI (attempted 23308 to) display the disassembly for address 0, which led to the gdb segfault. 23309 23310 When gdb_print_insn encounters an insn it cannot print because it can't read 23311 the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble. 23312 23313 The specific bit that causes the gdb segfault is that if gdb_print_insn throws 23314 a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty 23315 asm_lines. 23316 23317 FWIW, I did manage to reproduce the gdb segfault as follows: 23318 ... 23319 $ gdb -q \ 23320 -iex "set pagination off" \ 23321 /usr/bin/rustc \ 23322 -ex "set breakpoint pending on" \ 23323 -ex "b dl_main" \ 23324 -ex run \ 23325 -ex "up 4" \ 23326 -ex "layout asm" \ 23327 -ex "print \$pc" 23328 ... 23329 <TUI> 23330 ... 23331 $1 = (void (*)()) 0x1 23332 (gdb) 23333 ... 23334 Now press <up>, and the segfault triggers. 23335 23336 Fix the segfault by handling asm_lines.empty () results of tui_disassemble in 23337 tui_find_disassembly_address. 23338 23339 I've written a unit test that exercises this scenario. 23340 23341 Tested on x86_64-linux. 23342 23343 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 23344 23345 PR tui/30823 23346 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823 23347 233482023-09-28 Tom Tromey <tromey@adacore.com> 23349 23350 Remove old gdb_bfd_openr_iovec 23351 This removes the old gdb_bfd_openr_iovec entirely. I think any new 23352 code should use the type-safe approach. 23353 23354 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23355 233562023-09-28 Tom Tromey <tromey@adacore.com> 23357 23358 Convert solib-rocm to new type-safe gdb_bfd_openr_iovec 23359 This converts the solib-rocm BFD iovec implementations to the new 23360 type-safe gdb_bfd_openr_iovec. They were already essentially using 23361 this approach, just without the type-safe wrapper. 23362 23363 Thanks to Lancelot Six for testing and fixing this patch. 23364 23365 Co-Authored-By: Lancelot Six <lancelot.six@amd.com> 23366 Acked-by: Lancelot Six <lancelot.six@amd.com> 23367 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23368 233692023-09-28 Tom Tromey <tromey@adacore.com> 23370 23371 Convert minidebug to new type-safe gdb_bfd_openr_iovec 23372 This converts the minidebug BFD iovec implementation to the new 23373 type-safe gdb_bfd_openr_iovec. 23374 23375 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23376 233772023-09-28 Tom Tromey <tromey@adacore.com> 23378 23379 Convert target fileio to new type-safe gdb_bfd_openr_iovec 23380 This converts the target fileio BFD iovec implementation to use the 23381 new type-safe gdb_bfd_openr_iovec. 23382 23383 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23384 233852023-09-28 Tom Tromey <tromey@adacore.com> 23386 23387 Convert mem_bfd_iovec to new type-safe gdb_bfd_openr_iovec 23388 This converts the mem_bfd_iovec / target_buffer code to use the new 23389 type-safe gdb_bfd_openr_iovec. 23390 23391 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23392 233932023-09-28 Tom Tromey <tromey@adacore.com> 23394 23395 Small constructor change to target_buffer 23396 This changes the target_buffer constructor to initialize m_filename 23397 rather than assign to it. 23398 23399 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23400 234012023-09-28 Tom Tromey <tromey@adacore.com> 23402 23403 Introduce type-safe variant of gdb_bfd_openr_iovec 23404 This patch adds a new, type-safe variant of gdb_bfd_openr_iovec. In 23405 this approach, the underlying user data is simply an object, the 23406 callbacks are methods, and the "open" function is a function view. 23407 Nothing uses this new code yet. 23408 23409 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 23410 234112023-09-28 Andrew Burgess <aburgess@redhat.com> 23412 23413 gdb: use reopen_exec_file from reread_symbols 23414 This commit fixes an issue that was discovered while writing the tests 23415 for the previous commit. 23416 23417 I noticed that, when GDB restarts an inferior, the executable_changed 23418 event would trigger twice. The first notification would originate 23419 from: 23420 23421 #0 exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 23422 #1 0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122 23423 #2 0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682 23424 #3 0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192 23425 #4 0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125 23426 #5 0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609 23427 #6 0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761 23428 #7 0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593 23429 #8 0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924 23430 #9 0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328 23431 #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381 23432 #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 23433 #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 23434 23435 While the second originates from: 23436 23437 #0 exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 23438 #1 0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517 23439 #2 0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398 23440 #3 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 23441 #4 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 23442 23443 In the first case the call to exec_file_attach first passes through 23444 reopen_exec_file. The reopen_exec_file performs a modification time 23445 check on the executable file, and only calls exec_file_attach if the 23446 executable has changed on disk since it was last loaded. 23447 23448 However, in the second case things work a little differently. In this 23449 case GDB is really trying to reread the debug symbol. As such, we 23450 iterate over the objfiles list, and for each of those we check the 23451 modification time, if the file on disk has changed then we reload the 23452 debug symbols from that file. 23453 23454 However, there is an additional check, if the objfile has the same 23455 name as the executable then we will call exec_file_attach, but we do 23456 so without checking the cached modification time that indicates when 23457 the executable was last reloaded, as a result, we reload the 23458 executable twice. 23459 23460 In this commit I propose that reread_symbols be changed to 23461 unconditionally call reopen_exec_file before performing the objfile 23462 iteration. This will ensure that, if the executable has changed, then 23463 the executable will be reloaded, however, if the executable has 23464 already been recently reloaded, we will not reload it for a second 23465 time. 23466 23467 After handling the executable, GDB can then iterate over the objfiles 23468 list and reload them in the normal way. 23469 23470 With this done I now see the executable reloaded only once when GDB 23471 restarts an inferior, which means I can remove the kfail that I added 23472 to the gdb.python/py-exec-file.exp test in the previous commit. 23473 23474 Approved-By: Tom Tromey <tom@tromey.com> 23475 234762023-09-28 Andrew Burgess <aburgess@redhat.com> 23477 23478 gdb/python: make the executable_changed event available from Python 23479 This commit makes the executable_changed observable available through 23480 the Python API as an event. There's nothing particularly interesting 23481 going on here, it just follows the same pattern as many of the other 23482 Python events we support. 23483 23484 The new event registry is called events.executable_changed, and this 23485 emits an ExecutableChangedEvent object which has two attributes, a 23486 gdb.Progspace called 'progspace', this is the program space in which 23487 the executable changed, and a Boolean called 'reload', which is True 23488 if the same executable changed on disk and has been reloaded, or is 23489 False when a new executable has been loaded. 23490 23491 One interesting thing did come up during testing though, you'll notice 23492 the test contains a setup_kfail call. During testing I observed that 23493 the executable_changed event would trigger twice when GDB restarted an 23494 inferior. However, the ExecutableChangedEvent object is identical for 23495 both calls, so the wrong information is never sent out, we just see 23496 one too many events. 23497 23498 I tracked this down to how the reload_symbols function (symfile.c) 23499 takes care to also reload the executable, however, I've split fixing 23500 this into a separate commit, so see the next commit for details. 23501 23502 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23503 Approved-By: Tom Tromey <tom@tromey.com> 23504 235052023-09-28 Andrew Burgess <aburgess@redhat.com> 23506 23507 gdb: pass more arguments to the executable_changed observer 23508 This commit continues the work of the previous few commits. 23509 23510 My goal is to expose the executable_changed observer through the 23511 Python API as an event. 23512 23513 At this point adding executable_changed as an event to the Python API 23514 is trivial, but before I do that I would like to add some additional 23515 arguments to the observable, which currently has no arguments at all. 23516 23517 The new arguments I wish to add are: 23518 23519 1. The program_space in which the executable was changed, and 23520 23521 2. A boolean flag that will indicate if the executable changed to a 23522 whole new path, or if GDB just spotted that the executable changed on 23523 disk (e.g. the user recompiled the executable). 23524 23525 In this commit I change the signature of the observable and then pass 23526 the arguments through at the one place where this observable is 23527 notified. 23528 23529 As there are (currently) no users of this observable nothing else 23530 needs updating. In the next commit I'll add a listener for this 23531 observable in the Python code, and expose this as an event in the 23532 Python API. 23533 23534 Additionally, with this change, it should be possible to update the 23535 insight debugger to make use of this observable rather than using the 23536 deprecated_exec_file_display_hook (as it currently does), which will 23537 then allow this hook to be removed from GDB. 23538 23539 There should be no user visible changes after this commit. 23540 23541 Approved-By: Tom Tromey <tom@tromey.com> 23542 235432023-09-28 Andrew Burgess <aburgess@redhat.com> 23544 23545 gdb: remove unnecessary notification of executable_changed observer 23546 This commit continues the work of the previous two commits. 23547 23548 My goal, in the next couple of commits, is to expose the 23549 executable_changed observable in the Python API as an event. However, 23550 before I do that I want to remove the use of the executable_changed 23551 observable from the reread_symbols function in symfile.c as this use 23552 isn't directly associated with a change of the executable file, and so 23553 seems wrong. 23554 23555 In the previous two commits I have removed all users of the 23556 executable_changed observer as I believe those users can, and should, 23557 actually be listening for the new_objfile observable instead, so now 23558 there are no users of the executable_changed observable. 23559 23560 As such, I think removing the use of executable_changed from the 23561 function reread_symbols is perfectly safe, and correct. At this point 23562 the executable has not been changed, so we shouldn't be sending an 23563 executable_changed notification, and, as there is nobody listening to 23564 this observable, we can't break anything by removing this call. 23565 23566 There should be no user visible changes after this commit. 23567 23568 Approved-By: Tom Tromey <tom@tromey.com> 23569 235702023-09-28 Andrew Burgess <aburgess@redhat.com> 23571 23572 gdb: remove final user of the executable_changed observer 23573 This commit continues with the task started in the previous commit, 23574 and is similar in many ways. 23575 23576 The goal of the next couple of commits is to expose the 23577 executable_changed observable in the Python API as an event. Before I 23578 do this I would like to remove the additional call to the 23579 executable_changed observable which can be found in the reread_symbols 23580 function in the symfile.c file, as I don't believe that this use 23581 actually corresponds to a change in the current executable. 23582 23583 The previous commit removed one user of the executable_changed 23584 observable and replaced it with a new_obfile observer instead, and 23585 this commit does the same thing. 23586 23587 In auxv.c we use the executable_changed observable to call 23588 invalidate_auxv_cache, which then calls: 23589 23590 invalidate_auxv_cache_inf (current_inferior ()); 23591 23592 The auxv cache is already (additionally) cleared when an inferior 23593 exits and when an inferior appears. 23594 23595 As with the previous commit, I think we can safely replace the use of 23596 the executable_changed observable with a use of the new_obfile 23597 observable. All the tests still pass, and with some locally placed 23598 printf calls, I think that the cache is still being cleared in all the 23599 cases that should matter. 23600 23601 Approved-By: Tom Tromey <tom@tromey.com> 23602 236032023-09-28 Andrew Burgess <aburgess@redhat.com> 23604 23605 gdb: remove one user of the executable changed observer 23606 My goal for the next few commits is to expose the executable_changed 23607 observable from the Python API. 23608 23609 However, there is call to the executable_changed observable in the 23610 reread_symbols function (in symfile.c), and this doesn't actually 23611 correspond to the executable changing. My idea then, is to remove 23612 this use of the executable_changed observable, but, before I can do 23613 that, I need to check that nothing is going to break, and that 23614 requires my to think about the current users of this observable. 23615 23616 One current user of executable_changed is in symtab.c. We add an 23617 executable_changed observer that calls: 23618 23619 set_main_name (nullptr, language_unknown); 23620 23621 to discard all information about the main function when the executable 23622 changes. 23623 23624 However, changing the executable doesn't actually change the debug 23625 information. The debug information changes when the symbol-file 23626 changes, so I think this observer is in slightly the wrong place. 23627 23628 The new_objfile observable is (unfortunately) overloaded, it is called 23629 when a new objfile is loaded, and also (when its argument is nullptr), 23630 when all debug information should be discarded. 23631 23632 It turns out that there is already a new_objfile observer in 23633 symtab.c. I propose that, when the argument is nullptr (indicating 23634 all debug info should be discarded), that we should call set_main_name 23635 to discard the information about the main function. We can then 23636 remove the executable_changed observer from symtab.c. 23637 23638 All tests still pass, and, in my local world, I added some debug 23639 printf calls, and I think we are still discarded the main information 23640 everywhere we need to. 23641 23642 Approved-By: Tom Tromey <tom@tromey.com> 23643 236442023-09-28 Andrew Burgess <aburgess@redhat.com> 23645 23646 gdb/python: new Progspace.executable_filename attribute 23647 Add a new Progspace.executable_filename attribute that contains the 23648 path to the executable for this program space, or None if no 23649 executable is set. 23650 23651 The path within this attribute will be set by the "exec-file" and/or 23652 "file" commands. 23653 23654 Accessing this attribute for an invalid program space will raise an 23655 exception. 23656 23657 This new attribute is similar too, but not the same as the existing 23658 gdb.Progspace.filename attribute. If I could change the past, I'd 23659 change the 'filename' attribute to 'symbol_filename', which is what it 23660 actually represents. The old attribute will be set by the 23661 'symbol-file' command, while the new attribute is set by the 23662 'exec-file' command. Obviously the 'file' command sets both of these 23663 attributes. 23664 23665 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23666 Approved-By: Tom Tromey <tom@tromey.com> 23667 236682023-09-28 Andrew Burgess <aburgess@redhat.com> 23669 23670 gdb/python: new Progspace.symbol_file attribute 23671 Add a new Progspace.symbol_file attribute. This attribute holds the 23672 gdb.Objfile object that corresponds to Progspace.filename, or None if 23673 there is no main symbol file currently set. 23674 23675 Currently, to get this gdb.Objfile, a user would need to use 23676 Progspace.objfiles, and then search for the objfile with a name that 23677 matches Progspace.filename -- which should work just fine, but having 23678 direct access seems a little nicer. 23679 23680 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23681 Approved-By: Tom Tromey <tom@tromey.com> 23682 236832023-09-28 Andrew Burgess <aburgess@redhat.com> 23684 23685 gdb/doc: extend the description for Progspace.filename 23686 Extend the description for Progspace.filename in the documentation to 23687 mention what the returned string is actually the filename 23688 for (e.g. that it is the filename passed to the 'symbol-file' or 23689 'file' command). 23690 23691 Also document that this attribute will be None if no symbol file is 23692 currently loaded. 23693 23694 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 23695 Approved-By: Tom Tromey <tom@tromey.com> 23696 236972023-09-28 Simon Marchi <simon.marchi@polymtl.ca> 23698 23699 gdb/x86: use size of XSAVE area of enabled features 23700 Since commit b42405a1594 ("gdb: Update x86 Linux architectures to 23701 support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD 23702 Ryzen 3700X machine: 23703 23704 FAIL: gdb.base/gcore.exp: corefile restored all registers 23705 23706 The test gets the register state (saves the output of "info 23707 all-registers"), saves a core with the "gcore" command, loads the core, 23708 and checks the register state against the one previously saved. The 23709 problem is that when reading registers from the core file, the last half 23710 of ymm registers is unavailable: 23711 23712 (gdb) print $ymm0.v32_int8 23713 $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, <unavailable> <repeats 16 times>} 23714 23715 One strange thing with this machine is that the bitset of state 23716 components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU", 23717 but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX". So, PKRU appears 23718 to be supported by the processor, but disabled by the kernel. I didn't 23719 find why yet. 23720 23721 From CPUID leaf EAX=0Dh, ECX=00h, GDB can get: 23722 23723 - from EBX: max size of the XSAVE area required by features currently 23724 enabled in XCR0. On my machine, it's 0x340 (832). 23725 - from ECX: max size of the XSAVE area required by all features 23726 supported by XCR0. On my machine, it's 0x380 (896). 23727 23728 At runtime, GDB uses ECX (max size required by all supported features) 23729 to fill the x86_xsave_layout::sizeof_xsave. So, when writing the core 23730 file note for the XSAVE state, it writes a note of size 896, even though 23731 it doesn't write the PKRU state. When loading back the core, GDB tries 23732 to figure out the layout of the XSAVE area based on what features are 23733 enabled in XCR0 and the size of the note (the size of the XSAVE area). 23734 Since my combination of XCR0 and size of XSAVE area doesn't match any 23735 combination known by GDB, GDB falls back to a gdbarch supporting only 23736 x87 and SSE. 23737 23738 This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave 23739 field (and consequently the size of the XSAVE state note in core files) 23740 using EBX, the size of the XSAVE area required by currently enabled 23741 features in XCR0. This makes i387_guess_xsave_layout recognize my case 23742 with this condition: 23743 23744 else if (HAS_AVX (xcr0) && xsave_size == 832) 23745 { 23746 /* Intel and AMD CPUs supporting AVX. */ 23747 layout.avx_offset = 576; 23748 } 23749 23750 In other words, just as if my machine didn't support PKRU at all. 23751 23752 Another reason why I think this change makes sense is that XSAVE state 23753 notes in kernel-generated cores on this machine have size 832. So this 23754 change makes GDB-generated cores more similar to kernel-generated ones, 23755 reducing the diversity of XSAVE state notes that GDB needs to be able to 23756 figure out. 23757 23758 Note that if PKRU was enabled on my machine, then the effective XSAVE 23759 area size would be 896 bytes. We would need to add a case in 23760 i387_guess_xsave_layout for that combination, since there is no 23761 currently. But I don't have a way to test that right now, since I don't 23762 know why PKRU is disabled. 23763 23764 Relevant review note from John Baldwin: 23765 23766 One further note is that the Linux x86 arches use x86_xsave_length() 23767 to infer ("guess") the size of the XSAVE register set that the Linux 23768 kernel writes out in core dumps. On FreeBSD x86 arches, GDB is able 23769 to query this size directly from the kernel via ptrace. My use of ECX 23770 for this guess earlier was just not the best guess. In the case that 23771 the kernel enables all of the available features, then ECX and EBX 23772 have the same values, so this only matters for a system where the 23773 kernel has enabled a subset of available XSAVE extensions. 23774 23775 Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85 23776 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 23777 237782023-09-28 Frederic Cambus <fred@statdns.com> 23779 23780 Add support to readelf for the PT_OPENBSD_NOBTCFI segment type. 23781 237822023-09-28 Nick Clifton <nickc@redhat.com> 23783 23784 Fix: nm: SEGV on unknow address at nm.c:718 in print_symname 23785 PR 30886 * elf-bfd.h (struct elf_obj_tdata): Add dt_strsz field. 23786 * elf.c (_bfd_elf_get_dynamic_symbols): Add a NUL byte at the end of the string table. Initialise the dt_strsz field. (_bfd_elf_slurp_version_tables): Only free the contents if they were malloc'ed. Add checks before setting string pointers in the dt_strtab buffer. 23787 237882023-09-28 Tom de Vries <tdevries@suse.de> 23789 23790 [gdb/testsuite] Add nopie to gdb.base/unwind-on-each-insn-amd64-2.exp 23791 When running test-case gdb.base/unwind-on-each-insn-amd64-2.exp with target 23792 board unix/-fPIE/-pie, I run into: 23793 ... 23794 gdb compile failed, ld: unwind-on-each-insn-amd64-21.o: relocation \ 23795 R_X86_64_32S against `.text' can not be used when making a PIE object; \ 23796 recompile with -fPIE 23797 ld: failed to set dynamic section sizes: bad value 23798 ... 23799 23800 Fix this by hardcoding nopie in the test-case, and for good measure in the 23801 other test-cases that source unwind-on-each-insn.exp.tcl and use a .s file. 23802 23803 Tested on x86_64-linux. 23804 23805 Approved-by: Kevin Buettner <kevinb@redhat.com> 23806 238072023-09-28 GDB Administrator <gdbadmin@sourceware.org> 23808 23809 Automatic date update in version.in 23810 238112023-09-27 Aaron Merey <amerey@redhat.com> 23812 23813 config/debuginfod.m4: Add check for libdebuginfod 0.188 23814 Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found 23815 define macro HAVE_LIBDEBUGINFOD_FIND_SECTION. 23816 23817 This macro indicates support for downloading ELF sections from 23818 debuginfod servers. 23819 238202023-09-27 Nick Clifton <nickc@redhat.com> 23821 23822 nm: heap-buffer-overflow at elfcode.h:1507 in bfd_elf64_slurp_symbol_table 23823 PR 30885 23824 * elfcode.h (elf_slurp_symbol_table): Compute the symcount for non dynamic symbols in the same way as _bfd_elf_get_symtab_upper_bound. 23825 238262023-09-27 Jan Beulich <jbeulich@suse.com> 23827 23828 x86: prefer VEX encodings over EVEX ones when possible 23829 AVX-* features / insns paralleling earlier introduced AVX512* ones can 23830 be encoded more compactly when the respective feature was explicitly 23831 enabled by the user. 23832 23833 x86: drop cpu_arch_tune_flags 23834 Apparently from its introduction the variable was only ever written (the 23835 only read is merely to determine whether to write it with another value). 23836 (Since, due to the need to re-indent, the adjacent lines setting 23837 cpu_arch_tune need touching anyway, switch to using PREOCESSOR_* 23838 constants where applicable, to make more obvious what the resulting 23839 state is going to be.) 23840 238412023-09-27 Jan Beulich <jbeulich@suse.com> 23842 23843 x86: correct cpu_arch_isa_flags maintenance 23844 These may not be set from a value derived from cpu_arch_flags: That 23845 starts with (almost) all functionality enabled, while cpu_arch_isa_flags 23846 is supposed to track features that were explicitly enabled (and perhaps 23847 later disabled) by the user. 23848 23849 To avoid needing to do any such adjustment in two places (each), 23850 introduce helper functions used by both command line handling and 23851 directive processing. 23852 238532023-09-27 Pedro Alves <pedro@palves.net> 23854 23855 Adjust gdb.thread/pthreads.exp for Cygwin 23856 The Cygwin runtime spawns a few extra threads, so using hardcoded 23857 thread numbers in tests rarely works correctly. Thankfully, this 23858 testcase already records the ids of the important threads in globals. 23859 It just so happens that they are not used in a few tests. This commit 23860 fixes that. 23861 23862 With this, the test passes cleanly on Cygwin [1]. Still passes cleanly on 23863 x86-64 GNU/Linux. 23864 23865 [1] - with system GDB. Upstream GDB is missing a couple patches 23866 Cygwin carries downstream. 23867 23868 Approved-By: Tom Tromey <tom@tromey.com> 23869 Change-Id: I01bf71fcb44ceddea8bd16b933b10b964749a6af 23870 238712023-09-27 Pedro Alves <pedro@palves.net> 23872 23873 In gdb.threads/pthreads.c, handle pthread_attr_setscope ENOTSUP 23874 On Cygwin, I see: 23875 23876 (gdb) PASS: gdb.threads/pthreads.exp: break thread1 23877 continue 23878 Continuing. 23879 pthread_attr_setscope 1: Not supported (134) 23880 [Thread 3732.0x265c exited with code 1] 23881 [Thread 3732.0x2834 exited with code 1] 23882 [Thread 3732.0x2690 exited with code 1] 23883 23884 Program terminated with signal SIGHUP, Hangup. 23885 The program no longer exists. 23886 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread 23887 23888 ... and then a set of cascading failures. 23889 23890 Fix this by treating ENOTSUP the same way as if PTHREAD_SCOPE_SYSTEM 23891 were not defined. I.e., ignore ENOTSUP errors, and proceed with 23892 testing. 23893 23894 Approved-By: Tom Tromey <tom@tromey.com> 23895 Change-Id: Iea68ff8b9937570726154f36610c48ef96101871 23896 238972023-09-27 Pedro Alves <pedro@palves.net> 23898 23899 Fix gdb.threads/pthreads.exp error handling/printing 23900 On Cygwin, I noticed: 23901 23902 (gdb) PASS: gdb.threads/pthreads.exp: break thread1 23903 continue 23904 Continuing. 23905 pthread_attr_setscope 1: No error 23906 [Thread 8732.0x28f8 exited with code 1] 23907 [Thread 8732.0xb50 exited with code 1] 23908 [Thread 8732.0x17f8 exited with code 1] 23909 23910 Program terminated with signal SIGHUP, Hangup. 23911 The program no longer exists. 23912 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread 23913 23914 Note "No error" in "pthread_attr_setscope 1: No error". That is a bug 23915 in the test. It is using perror, but that prints errno, while the 23916 pthread functions return the error directly. Fix all cases of the 23917 same problem, by adding a new print_error function and using it. 23918 23919 We now get: 23920 23921 ... 23922 pthread_attr_setscope 1: Not supported (134) 23923 ... 23924 23925 Approved-By: Tom Tromey <tom@tromey.com> 23926 Change-Id: I972ebc931b157bc0f9084e6ecd8916a5e39238f5 23927 239282023-09-27 Pedro Alves <pedro@palves.net> 23929 23930 Fix gdb.threads/pthreads.c formatting 23931 Just some GNU formatting fixes throughout. 23932 23933 Approved-By: Tom Tromey <tom@tromey.com> 23934 Change-Id: Ie851e3815b839e57898263896db0ba8ddfefe09e 23935 239362023-09-27 Pedro Alves <pedro@palves.net> 23937 23938 gdb.threads/pthreads.c, K&R -> ANSI function style 23939 gdb.threads/pthreads.c is declaring functions with old K&R style. 23940 This commit converts them to ANSI style. 23941 23942 Approved-By: Tom Tromey <tom@tromey.com> 23943 Change-Id: I1ce007c67bb4ab1e49248c014c7881e46634f8f8 23944 239452023-09-27 Neal Frager <neal.frager@amd.com> 23946 23947 opcodes: microblaze: Add wdc.ext.clear and wdc.ext.flush insns 23948 239492023-09-27 Hsinyuan Xavier <TheLastLin@hotmail.com> 23950 23951 Fix: Output section type does not been applied to section forced output by `. = .` assignment 23952 PR 30875 23953 * ldlang.c (get_os_init_flag): New function. (exp_init_os, map_input_to_output_sections): Use it. 23954 239552023-09-27 Jan Beulich <jbeulich@suse.com> 23956 23957 x86: fold FMA VEX and EVEX templates 23958 Following the folding of some generic AVX/AVX2 templates with their 23959 AVX512F counterpart ones, do this for FMA ones as well, requiring one 23960 further adjustment to cpu_flags_match(). 23961 23962 x86: fold VAES/VPCLMULQDQ VEX and EVEX templates 23963 Following the folding of some generic AVX/AVX2 templates with their 23964 AVX512F counterpart ones, do this for VAES and VPCLMULQDQ ones as well. 23965 239662023-09-27 Jan Beulich <jbeulich@suse.com> 23967 23968 x86: fold certain VEX and EVEX templates 23969 In anticipation of APX introduce logic to reduce the number of templates 23970 we have now, allowing to limit some the number of ones we then need to 23971 gain. 23972 23973 The fundamental requirements are that 23974 - attributes be compatible, which specifically means VexW needs to be 23975 the same in the templates (which often isn't the case, for VEX 23976 encodings having far more WIG tha, EVEX ones), 23977 - the EVEX form being AVX512F (with or without AVX512VL), not any of its 23978 extensions (the same will then be required for APX - it'll need to be 23979 APX_F). 23980 23981 Note that in check_register() there's now a redundant zmm check. Since 23982 this logic will need revisiting for APX anyway, I'd like to keep it that 23983 way for now. (Similarly a couple of if()-s which could be folded are 23984 kept separate, to reduce code churn when adding APX support.) 23985 239862023-09-27 Jan Beulich <jbeulich@suse.com> 23987 23988 x86: tighten .insn SAE and broadcast checking 23989 SAE / embedded rounding are invalid when there's the memory operand, as 23990 the bit encoding this specifies broadcast in that case. 23991 23992 Broadcast needs to be specified on the memory operand. 23993 239942023-09-27 Jan Beulich <jbeulich@suse.com> 23995 23996 x86-64: REX.W overrides DATA_PREFIX 23997 REX.W needs to be respected when immediate size and relocation type are 23998 determined. 23999 240002023-09-27 Jan Beulich <jbeulich@suse.com> 24001 24002 x86-64: fix suffix-less PUSH of symbol address 24003 PR gas/30856 24004 24005 In 5cc007751cdb ("x86: further adjust extend-to-32bit-address 24006 conditions") I neglected the case of PUSH, which is the only insn 24007 allowing (proper) symbol addresses to be used as immediates (not 24008 displacements, like CALL/JMP) in the absence of any register operands. 24009 Since it defaults to 64-bit operand size, guessing an L suffix is wrong 24010 there. 24011 240122023-09-27 Sam James <sam@gentoo.org> (tiny change) 24013 24014 gdb: Fix an ODR warning with byacc with GDB_YY_REMAP 24015 With byacc, we get an ODR warning with YYSTACKDATA between ada-exp.c.tmp 24016 and c-exp.c.tmp. Just include it in the list of symbols we rename. 24017 24018 PR gdb/30839 24019 24020 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30839 24021 Approved-By: Tom de Vries <tdevries@suse.de> 24022 240232023-09-27 mengqinggang <mengqinggang@loongson.cn> 24024 24025 Add support for "pcaddi rd, symbol" 24026 Add a macro pcaddi instruction to support "pcaddi rd, symbol". 24027 24028 pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative 24029 address, and the address should be 4-byte aligned. 24030 240312023-09-27 GDB Administrator <gdbadmin@sourceware.org> 24032 24033 Automatic date update in version.in 24034 240352023-09-26 Simon Marchi <simon.marchi@efficios.com> 24036 24037 gdb/testsuite: add xfail for gdb/29965 in gdb.threads/process-exit-status-is-leader-exit-status.exp 24038 Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently 24039 with: 24040 24041 FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=0: continue (the program exited) 24042 ... 24043 FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=9: continue (the program exited) 24044 24045 This is due to a change in Linux kernel behavior [1] that affects 24046 exactly what this test tests. That is, if multiple threads (including 24047 the leader) call SYS_exit, the exit status of the process should be the 24048 exit status of the leader. After that change in the kernel, it is no 24049 longer the case. 24050 24051 Add an xfail in the test, based on the Linux kernel version. The goal 24052 is that if a regression is introduced in GDB regarding this feature, it 24053 should be caught if running on an older kernel where the behavior was 24054 consistent. 24055 24056 [1] https://bugzilla.suse.com/show_bug.cgi?id=1206926 24057 24058 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965 24059 Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb 24060 Approved-By: Tom de Vries <tdevries@suse.de> 24061 240622023-09-26 Tom de Vries <tdevries@suse.de> 24063 24064 [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp with newer gcc 24065 When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using 24066 gcc 13.2.1, I run into (layout adapted for readability): 24067 ... 24068 -stack-list-arguments 1^M 24069 ^done,stack-args=[ 24070 frame={level="0",args=[]}, 24071 frame={level="1",args=[{name="<_task>",value="0x464820"}, 24072 {name="<_taskL>",value="129"}]}, 24073 frame={level="2",args=[{name="self_id",value="0x464840"}]}, 24074 frame={level="3",args=[]}, 24075 frame={level="4",args=[]} 24076 ]^M 24077 (gdb) ^M 24078 FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) 24079 ... 24080 24081 On openSUSE Leap 15.4 with gcc 7.5.0 I get instead: 24082 ... 24083 -stack-list-arguments 1^M 24084 ^done,stack-args=[ 24085 frame={level="0",args=[]}, 24086 frame={level="1",args=[{name="<_task>",value="0x444830"}]}, 24087 frame={level="2",args=[{name="self_id",value="0x444850"}]}, 24088 frame={level="3",args=[]}, 24089 frame={level="4",args=[]}]^M 24090 (gdb) ^M 24091 PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 24092 ... 24093 24094 The difference in gdb output is due to difference in the dwarf generated by 24095 the compiler, so I don't see a problem with gdb here. 24096 24097 Fix this by updating the test-case to accept this output. 24098 24099 Tested on x86_64-linux. 24100 24101 Approved-By: Tom Tromey <tom@tromey.com> 24102 241032023-09-26 Tom Tromey <tromey@adacore.com> 24104 24105 Remove some unnecessary qualification from printing.py 24106 printing.py references "gdb.printing" in a few spots, but there's no 24107 need for this. I think this is leftover from when this code was 24108 (briefly) in some other module. This patch removes the unnecessary 24109 qualifications. Tested on x86-64 Fedora 36. 24110 241112023-09-26 Tom Tromey <tromey@adacore.com> 24112 24113 Add two new pretty-printer methods 24114 This adds two new pretty-printer methods, to support random access to 24115 children. The methods are implemented for the no-op array printer, 24116 and DAP is updated to use this. 24117 24118 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 24119 241202023-09-26 Tom Tromey <tromey@adacore.com> 24121 24122 Introduce gdb.ValuePrinter 24123 There was an earlier thread about adding new methods to 24124 pretty-printers: 24125 24126 https://sourceware.org/pipermail/gdb-patches/2023-June/200503.html 24127 24128 We've known about the need for printer extensibility for a while, but 24129 have been hampered by backward-compatibilty concerns: gdb never 24130 documented that printers might acquire new methods, and so existing 24131 printers may have attribute name clashes. 24132 24133 To solve this problem, this patch adds a new pretty-printer tag class 24134 that signals to gdb that the printer follows new extensibility rules. 24135 24136 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30816 24137 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 24138 241392023-09-26 Nick Clifton <nickc@redhat.com> 24140 24141 Fix a snafu in the new tests for reproducible archives that assumed a umask of 22. 24142 241432023-09-26 Tom de Vries <tdevries@suse.de> 24144 24145 [gdb/testsuite] Fix gdb.server/ext-run.exp in container 24146 When running the gdb testsuite inside a container, I run into: 24147 ... 24148 (gdb) gdb_expect_list pattern: /1 +root +[/a-z]*(init|systemd)/ 24149 FAIL: gdb.server/ext-run.exp: get process list (pattern 2) 24150 ... 24151 because there's no process with pid 1 and cmd init or systemd. 24152 24153 In the host system (where the test passes), I have: 24154 ... 24155 $ ps -f 1 24156 UID PID PPID C STIME TTY STAT TIME CMD 24157 root 1 0 0 Sep25 ? Ss 0:03 /usr/lib/systemd/systemd ... 24158 ... 24159 but in the container instead: 24160 ... 24161 UID PID PPID C STIME TTY STAT TIME CMD 24162 root 1 0 0 11:45 pts/0 Ss 0:00 /bin/bash 24163 ... 24164 24165 Fix this by also accepting bash as a valid cmd. 24166 24167 Tested on x86_64-linux. 24168 24169 Approved-By: Tom Tromey <tom@tromey.com> 24170 241712023-09-26 Richard Sandiford <richard.sandiford@arm.com> 24172 24173 aarch64: Allow feature flags to occupy >64 bits 24174 Following on from the previous patch to make the feature macros take 24175 a word number, this one increases the number of flag words from 1 to 2. 24176 24177 The patch uses some dummy features to push the number of features 24178 over 64. The intention is that these should be reused by real 24179 features rather than kept as-is. 24180 241812023-09-26 Richard Sandiford <richard.sandiford@arm.com> 24182 24183 aarch64: Restructure feature flag handling 24184 The AArch64 feature-flag code is currently limited to a maximum 24185 of 64 features. This patch reworks it so that the limit can be 24186 increased more easily. The basic idea is: 24187 24188 (1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum 24189 counting bit positions. 24190 24191 (2) Make the feature-list macros take an array index argument 24192 (currently always 0). The macros then return the 24193 aarch64_feature_set contents for that array index. 24194 24195 An N-element array would then be initialised as: 24196 24197 { MACRO (0), ..., MACRO (N - 1) } 24198 24199 (3) Provide convenience macros for initialising an 24200 aarch64_feature_set for: 24201 24202 - a single feature 24203 - a list of individual features 24204 - an architecture version 24205 - an architecture version + a list of additional features 24206 24207 (2) and (3) use the preprocessor to generate static initialisers. 24208 The main restriction was that uses of the same preprocessor macro 24209 cannot be nested. So if a macro wants to do something for N individual 24210 arguments, it needs to use a chain of N macros to do it. There then 24211 needs to be a way of deriving N, as a preprocessor token suitable for 24212 pasting. 24213 24214 The easiest way of doing that was to precede each list of features 24215 by the number of features in the list. So an aarch64_feature_set 24216 initialiser for three features A, B and C would be written: 24217 24218 AARCH64_FEATURES (3, A, B, C) 24219 24220 This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a 24221 synonym for SHA2+AES, so the patch expands the former to the latter. 24222 242232023-09-26 Tom de Vries <tdevries@suse.de> 24224 24225 [gdb/dap] Fix dap for python < 3.8 24226 With any gdb.dap test and python 3.6 I run into: 24227 ... 24228 Error occurred in Python: 'code' object has no attribute 'co_posonlyargcount' 24229 ERROR: eof reading json header 24230 ... 24231 24232 The attribute is not supported before python 3.8, which introduced the 24233 "Positional−only Parameters" concept. 24234 24235 Fix this by using try/except AttributeError. 24236 24237 Tested on x86_64-linux: 24238 - openSUSE Leap 15.4 with python 3.6, and 24239 - openSUSE Tumbleweed with python 3.11.5. 24240 24241 Approved-By: Tom Tromey <tom@tromey.com> 24242 242432023-09-26 Enze Li <enze.li@hotmail.com> 24244 24245 fbsd-nat: Fix build failure with GCC 12 24246 A user pointed out that the build failed on FreeBSD/amd64 with my last 24247 commit. The problem is that I'm not using the proper way to tell the 24248 compiler that the variable has been "used". This patch fixes this issue 24249 as suggested by John. Pushed as obvious. 24250 24251 Tested both on FreeBSD/amd64 and FreeBSD/aarch64 by rebuilding. 24252 24253 Suggested-By: John Baldwin <jhb@FreeBSD.org> 24254 242552023-09-26 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 24256 24257 Fix to step instruction due to P10 prefix instruction. 24258 In AIX, power 10 instructions like paddi occupy 8 bytes, while the other instructions 24259 4 bytes of space. Due to this when we do a stepi on paddi instruction we get a SIGILL interrupt. Hence, we 24260 need to check during stepi if we are able to step 8 bytes during this instruction execution and is the 24261 breakpoint to this instruction set correctly in both 32- and 64-bit mode. 24262 24263 This patch is a fix to the same. 24264 242652023-09-26 Nick Clifton <nickc@redhat.com> 24266 24267 Allow the use of SOURCE_DATE_EPOCH in the timestamps for members of static archives. 24268 (For some reason this commit was not applied at the time that the patch was approved). 24269 242702023-09-26 Tom Tromey <tromey@adacore.com> 24271 24272 Use string_file::release in some places 24273 I found a few spots like: 24274 24275 string_file f; 24276 std::string x = f.string (); 24277 24278 However, string_file::string returns a 'const std::string &'... so it 24279 seems to me that this must be copying the string (? I find it hard to 24280 reason about this in C++). 24281 24282 This patch changes these spots to use release() instead, which moves 24283 the string. 24284 24285 Reviewed-by: Keith Seitz <keiths@redhat.com> 24286 Reviewed-by: Lancelot Six <lancelot.six@amd.com> 24287 242882023-09-26 GDB Administrator <gdbadmin@sourceware.org> 24289 24290 Automatic date update in version.in 24291 242922023-09-25 Vsevolod Alekseyev <sevaa@sprynet.com> 24293 24294 Fix readelf's display of dwarf v5 range lists 24295 PR 30792 24296 * dwarf.h (struct debug_info): Remove range_versions field. 24297 * dwarf.c (fetch_indexed_offset): New function. (read_and_display_attr_value): Use it for DW_FORM_rnglistx. Remove code to initialise range_versions. (skip_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (process_debug_info): Call read_bases. (display_debug_rnglists): Rename to display_debug_rnglists_unit_header and only display the range list header information. (display_debug_ranges): Adjust. 24298 242992023-09-25 Claudiu Zissulescu <claziss@gmail.com> 24300 24301 Revert "arc: Add new GAS tests for ARCv3." 24302 This reverts commit 462693a455f04fc52c1c91ffc52ea2446a086444. 24303 24304 Revert "arc: Add new LD tests for ARCv3." 24305 This reverts commit 6e467e9a94c1135bd11d985e9263d43204a9258b. 24306 24307 Revert "arc: Add new ARCv3 ISA to BFD." 24308 This reverts commit 06e8d9861d16c5b7e6920ad0e89889ccf45c575a. 24309 24310 Revert "arc: Add new linker emulation and scripts for ARCv3 ISA." 24311 This reverts commit 4deb1ee57fdb711cac6f36fed75b3c8cb5112d99. 24312 24313 Revert "arc: Update opcode related include files for ARCv3." 24314 This reverts commit 04414221df53bb5129e34bec354dae3121db436a. 24315 24316 Revert "arc: Update ARC's Gnu Assembler backend with ARCv3 ISA." 24317 This reverts commit f3d38d7d0b7346515ba603454feeddc58a3fc451. 24318 24319 Revert "arc: Add new opcode functions for ARCv3 ISA." 24320 This reverts commit c99dc76089a2de97ea0ee755aa8e87037a17b6d6. 24321 24322 Revert "arc: New ARCv3 ISA instruction table" 24323 This reverts commit 67036dfacf87e79317984f51892bfc0eda0e597f. 24324 24325 Revert "arc: Update arc's gas tests" 24326 This reverts commit ef90c0991e78c28bebdd3ed31a77c05be0444191. 24327 24328 Revert "arc: Update NEWS files" 24329 This reverts commit a47d304b1229ecf8912fac17ee9c48d1bf3c729a. 24330 24331 Revert "arc: Update bfd arc pattern file to allow enable-targets=all" 24332 This reverts commit 5e5116071b09e187ee3c6b7e86e86114f6a65ef3. 24333 243342023-09-25 Claudiu Zissulescu <claziss@gmail.com> 24335 24336 arc: Update bfd arc pattern file to allow enable-targets=all 24337 The ARC backend uses a BFD pattern file to generate three ARC targets: 24338 - an BFD ARC target for ARCv1 and ARCv2 CPU families. It also works 24339 for big-endian variants. 24340 - an BFD ARC64 target for ARCv3 64bit machines. It also allows working 24341 with ARCv3 32bit machines. 24342 - an BFD ARC32 target for ARCv4 32bit machines. It also allows working 24343 with ARCv3 64bit machines. 24344 24345 When configuring with `--enable-targets=all` some patterns are defined 24346 multiple times. Fix this issue. 24347 243482023-09-25 Andreas Schwab <schwab@suse.de> 24349 24350 RISC-V: Protect .got with relro 24351 Move .got before .data so that it can be protected with -zrelro. Also 24352 separate .got.plt from .got if -znow is not in effect; the first two words 24353 of .got.plt are placed within the relro region. 24354 24355 ld: 24356 PR ld/30877 24357 * emulparams/elf32lriscv-defs.sh (DATA_GOT, SEPARATE_GOTPLT): 24358 Define. 24359 * emulparams/elf64lriscv-defs.sh (SEPARATE_GOTPLT): Define. 24360 * testsuite/ld-elf/binutils.exp (binutils_test): Remove riscv*-*-* 24361 from relro_got expression. 24362 243632023-09-25 Claudiu Zissulescu <claziss@gmail.com> 24364 24365 arc: Update NEWS files 24366 Add ARCv3 support in NEWS files. 24367 243682023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24369 24370 arc: Update arc's gas tests 24371 The disassembler can recognize the alternative register names ILINK1 24372 and ILINK2. Update tests. 24373 24374 gas/testsuite/gas/arc 24375 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24376 24377 * gas/testsuite/gas/arc/adc.d: Update ILINK1/INLINK2 reg names. 24378 * gas/testsuite/gas/arc/add.d: Likewise. 24379 * gas/testsuite/gas/arc/and.d: Likewise. 24380 * gas/testsuite/gas/arc/asl.d: Likewise. 24381 * gas/testsuite/gas/arc/asr.d: Likewise. 24382 * gas/testsuite/gas/arc/bic.d: Likewise. 24383 * gas/testsuite/gas/arc/lsr.d: Likewise. 24384 * gas/testsuite/gas/arc/nps400-1.d: Likewise. 24385 * gas/testsuite/gas/arc/or.d: Likewise. 24386 * gas/testsuite/gas/arc/ror.d: Likewise. 24387 * gas/testsuite/gas/arc/sbc.d: Likewise. 24388 * gas/testsuite/gas/arc/sub.d: Likewise. 24389 * gas/testsuite/gas/arc/textinsn3op.d: Likewise. 24390 * gas/testsuite/gas/arc/warn.exp: Update predicate. 24391 * gas/testsuite/gas/arc/arc.exp: Likewise. 24392 243932023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24394 24395 arc: New ARCv3 ISA instruction table 24396 opcodes/ 24397 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24398 24399 * opcodes/arc64-tbl.h: New file. 24400 244012023-09-25 Claudiu Zissulescu <claziss@gmail.com> 24402 24403 arc: Add new opcode functions for ARCv3 ISA. 24404 opcodes/ 24405 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24406 Cupertino Miranda <cmiranda@synopsys.com> 24407 24408 * opcodes/Makefile.am: Add ARC64 opcode file. 24409 * opcodes/Makefile.in: Regenerate. 24410 * opcodes/arc-opc.c: Move the common functionality to 24411 arcxx-opc.inc. Keep only ARCv2 ARCv1 specifics. 24412 * opcodes/arc-ext-tbl.h: Deleted file. 24413 * opcodes/arcxx-opc.inc: New file. 24414 * opcodes/arc64-opc.c: Likewise. 24415 * opcodes/arc-fxi.h (insert_uimm9_a32_11_s): New function. 24416 (extract_uimm9_a32_11_s): Likewise. 24417 (insert_uimm10_13_s): Likewise. 24418 (extract_uimm10_13_s): Likewise. 24419 * opcodes/configure: Regenerate. 24420 * opcodes/configure.ac: Add ARC64 target. 24421 * opcodes/disassemble.c: Likewise. 24422 * opcodes/arc-dis.c (regmod_t): New type. 24423 (regmods): New structure. 24424 (fpnames): New strings with fp-regs name. 24425 (REG_PCL, REG_LIMM, REG_LIMM_S, REG_U32, REG_S32): New defines. 24426 (getregname): New function. 24427 (find_format_from_table): Discriminate between signed and unsigned 24428 32bit immediates. 24429 (find_format): Handle extract function for flags. 24430 (arc_insn_length): Update insn lengths to various architectures. 24431 (print_insn_arc): Update printing for various ARC architectures. 24432 * opcodes/arc-flag-classes.def: New file. 24433 * opcodes/arc-flag.def: New file. 24434 * opcodes/arc-operands.def: New file. 24435 * opcodes/arc-regs.h: Changed. 24436 244372023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24438 24439 arc: Update ARC's Gnu Assembler backend with ARCv3 ISA. 24440 The new Synopsys ARCv3 ISA has a similar instruction format like 24441 the old ARCv1 and ARCv2 ISA. Thus, the ARCv3 addition is using 24442 whatever we have for old ARC processors plus some ARCv3 spcific mods. 24443 24444 To distinguish between various ARC variants, we introduced two new 24445 configure defines named TARGET_ARCv3_32 and TARGET_ARCv3_64 which are 24446 set when we choose either an ARC32 (ARCv3/32) ISA toolchain or an 24447 ARC64 (ARCv3/64) ISA toolchain. 24448 24449 gas/ 24450 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24451 24452 * gas/config/tc-arc.h: Selectively define default target macros. 24453 * gas/configure.ac: Add ARC64 target. 24454 * gas/configure.tgt: Likewise. 24455 * gas/configure: Regenerate 24456 * gas/config.in: Regenerate. 24457 * gas/config/tc-arc.c (DEFAULT_ARCH): New macro. 24458 (default_arch): New variable. 24459 (md_pseudo_table): Add xword. 24460 (md_shortopts): Only a few options are recognized by the new ARC64 24461 assembler. 24462 (md_longopts): Likewise. 24463 (ARC_CPU_TYPE_A64x): New define. 24464 (ARC_CPU_TYPE_A32x): Likewise. 24465 (cpu_type): New arch field. 24466 (selected_cpu): Update fields. 24467 (arc_opcode_hash_entry_iterator_init): Formating. 24468 (arc_opcode_hash_entry_iterator_next): Likewise. 24469 (arc_select_cpu): Likewise. 24470 (arc_option): Likewise. 24471 (check_cpu_feature): Likewise. 24472 (debug_exp): Recognize new expression operands. 24473 (parse_reloc_symbol): Parse new signed/unsigend cases. 24474 (parse_opcode_flags): Update for the case when the flags needs 24475 insert/extract functions. 24476 (find_opcode_match): Match new signed/unsigned 32-bit immediates. 24477 (autodetect_attributes): PLT34 only available for ARC64. 24478 (md_assemble): Extend match characters. 24479 (declare_fp_set): New function. 24480 (init_default_arch): Likewise. 24481 (md_begin): Detect and initialize the correct CPU and coresponding 24482 registers. 24483 (md_pcrel_from_section): Add new relocs. 24484 (arc_target_format): New function. 24485 (md_apply_fix): Add new relocs. 24486 (md_parse_option): Update options. 24487 (arc_show_cpu_list): Update with ARC64 cpus. 24488 (md_show_usage): Update messages. 24489 (may_relax_expr): Add PLT34 case. 24490 (assemble_insn): Update for ARC64. 24491 (arc_make_nops): New function. 24492 (arc_handle_align): Refurbish this function, use arc_make_nops. 24493 (tc_arc_fix_adjustable): Update messages. 24494 244952023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24496 24497 arc: Update opcode related include files for ARCv3. 24498 Add new ARCv3 CPUs and required bits to decode/encode ARCv3 ISA 24499 opcodes. Fix 32 bit relocations which were set as signed but should be 24500 bitfield: ARC_32_ME, ARC_GLOB_DAT, ARC_JMP_SLOT, ARC_RELATIVE. Remove 24501 non-ABI relocation ARC_32_ME_S. 24502 24503 include/ 24504 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24505 Cupertino Miranda <cupertinomiranda@gmail.com> 24506 Bruno Mauricio <brunoasmauricio@gmail.com> 24507 24508 * include/elf/arc-cpu.def: Add new HS5x and HS6x CPUs. 24509 * include/elf/arc-reloc.def: Add new ARC64 relocations. 24510 * include/elf/arc.h (EF_ARC_CPU_ARC64): New define. 24511 * include/opcode/arc-attrs.h (FEATURE_LIST_NAME): Update predicate. 24512 * include/opcode/arc-func.h: Update formating. 24513 (replace_disp8ls): New function. 24514 (replace_disp9s): Likewise. 24515 (replace_disp6s): Likewise. 24516 (replace_disp7s): Likewise. 24517 (replace_disp12s): Likewise. 24518 * include/opcode/arc.h (ARC_OPCODE_ARC64): New define. 24519 (ARC_OPCODE_ARC32): Likewise. 24520 (ARC_OPERAND_FP): Likewise. 24521 (HARD_FIELDF): Likewise. 24522 (ARC_OPCODE_ARCVx): New macro. 24523 (arc_flag_class): Update structure to hold new extract/insert 24524 functions for flags. 24525 (INSN3OP): Update macro. 24526 (FP_SIZE, TPOF, DPOF, SOPF, COPF, CONVOPS): New enums. 24527 245282023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24529 24530 arc: Add new linker emulation and scripts for ARCv3 ISA. 24531 Add ARCv3's linker bits. Remove obsolete tests. 24532 24533 ld/ 24534 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24535 24536 * ld/Makefile.am: Add ARC64 targets. 24537 * ld/configure.tgt: Likewise. 24538 * ld/Makefile.in: Regenerate. 24539 * ld/emulparams/arc64elf32.sh: New file. 24540 * ld/emulparams/arc64elf64.sh: Likewise. 24541 * ld/emulparams/arc64linux32.sh: Likewise. 24542 * ld/emulparams/arc64linux64.sh: Likewise. 24543 * ld/scripttempl/elfarc.sc: Update stack and heap definitions. 24544 * ld/testsuite/ld-arc/got-weak.d: Deleted file. 24545 * ld/testsuite/ld-arc/got-weak.s: Likewise. 24546 245472023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24548 24549 arc: Add new ARCv3 ISA to BFD. 24550 The new Synopsys's ARCv3 ISA is capable to run either 64-bit or 24551 32-bit ISA. The new 32-bit ISA is not compatible with the old 24552 Synopsys ARCv1/ARCv2 ISA, however, it retains a lot of common 24553 concepts. Thus, this patch is reusing the old ARC BFD backend and 24554 adds the necessary bits for the new architecture in a similar way as 24555 it is done for RISCV backend. 24556 24557 bfd/ 24558 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24559 Cupertino Miranda <cupertinomiranda@gmail.com> 24560 24561 * bfd/Makefile.am: Add ARC64 files. 24562 * bfd/Makefile.in: Regerate. 24563 * bfd/arc-got.h (TCB_SIZE): Depends on the target architecture. 24564 (GOT_ENTRY_SIZE): New define. 24565 (write_in_got): Likewise. 24566 (read_from_got): Likewise. 24567 (align_power): Likewise. 24568 (arc_got_entry_type_for_reloc): Use RELA_SIZE and GOT_ENTRY_SIZE. 24569 (arc_fill_got_info_for_reloc): Update formating. 24570 (relocate_fix_got_relocs_for_got_info): Likewise. 24571 (arc_static_sym_data): Deleted structure. 24572 (get_static_sym_data): Deleted function. 24573 (relocate_fix_got_relocs_for_got_info): Use symbol static data. 24574 (create_got_dynrelocs_for_single_entry): Update formating. 24575 (create_got_dynrelocs_for_got_info): Likewise. 24576 * bfd/arc-plt.c: New file. 24577 * bfd/arc-plt.def: Add ARC64 PLT entry. 24578 * bfd/arc-plt.h: Clean it up, move functionality to arc-plt.c file. 24579 * bfd/archures.c: Add ARC64 target. 24580 * bfd/config.bfd: Likewise. 24581 * bfd/configure.ac: Likewise. 24582 * bfd/bfd-in2.h: Regenerate. 24583 * bfd/configure: Likewise. 24584 * bfd/libbfd.h: Likewise. 24585 * bfd/cpu-arc.c: Clean it up. 24586 * bfd/cpu-arc64.c: New file. 24587 * bfd/elf32-arc.c: Renamed to elfnn-arc.c. 24588 * bfd/elfnn-arc.c: New file. 24589 * bfd/reloc.c: Add new ARC64 relocs. 24590 * bfd/targets.c: Add ARC64 target. 24591 245922023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24593 24594 arc: Add new LD tests for ARCv3. 24595 Add new linker tests for ARCv3 ISA. All the new tests are added in a 24596 distinct new folder named arc64. 24597 24598 ld/ 24599 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24600 24601 * ld/testsuite/ld-arc64/arcv3_64-reloc-near-exe.dd: New file. 24602 * ld/testsuite/ld-arc64/arcv3_64-reloc-near-so.dd: Likewise. 24603 * ld/testsuite/ld-arc64/arcv3_64-reloc-near.s: Likewise. 24604 * ld/testsuite/ld-arc64/arcv3_64.exp: Likewise. 24605 * ld/testsuite/ld-arc64/bl34.dd: Likewise. 24606 * ld/testsuite/ld-arc64/bl34.s: Likewise. 24607 * ld/testsuite/ld-arc64/linkscript.ld: Likewise. 24608 * ld/testsuite/ld-arc64/plt34-got.dd: Likewise. 24609 * ld/testsuite/ld-arc64/plt34-got.s: Likewise. 24610 * ld/testsuite/ld-arc64/plt34-reloc.dd: Likewise. 24611 * ld/testsuite/ld-arc64/plt34-reloc.s: Likewise. 24612 246132023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24614 24615 arc: Add new GAS tests for ARCv3. 24616 Add new assembler tests for ARCv3 ISA. All the new tests are added in 24617 a distinct folder named arc64. 24618 24619 gas/ 24620 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24621 24622 * gas/testsuite/gas/arc64/arc64.exp: New file. 24623 * gas/testsuite/gas/arc64/float01.d: Likewise. 24624 * gas/testsuite/gas/arc64/float01.s: Likewise. 24625 * gas/testsuite/gas/arc64/ldd.d: Likewise. 24626 * gas/testsuite/gas/arc64/ldd.s: Likewise. 24627 * gas/testsuite/gas/arc64/lddl.d: Likewise. 24628 * gas/testsuite/gas/arc64/lddl.s: Likewise. 24629 * gas/testsuite/gas/arc64/load.d: Likewise. 24630 * gas/testsuite/gas/arc64/load.s: Likewise. 24631 * gas/testsuite/gas/arc64/st.d: Likewise. 24632 * gas/testsuite/gas/arc64/st.s: Likewise. 24633 * gas/testsuite/gas/arc64/std.d: Likewise. 24634 * gas/testsuite/gas/arc64/std.s: Likewise. 24635 * gas/testsuite/gas/arc64/stdl.d: Likewise. 24636 * gas/testsuite/gas/arc64/stdl.s: Likewise. 24637 * gas/testsuite/gas/arc64/stl.d: Likewise. 24638 * gas/testsuite/gas/arc64/stl.s: Likewise. 24639 246402023-09-25 Claudiu Zissulescu <claziss@synopsys.com> 24641 24642 arc: Update binutils arc predicate for tests. 24643 binutils/testsuite/binutils-all 24644 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 24645 24646 * binutils/testsuite/binutils-all/arc/objdump.exp: Update predicate. 24647 246482023-09-25 GDB Administrator <gdbadmin@sourceware.org> 24649 24650 Automatic date update in version.in 24651 246522023-09-24 GDB Administrator <gdbadmin@sourceware.org> 24653 24654 Automatic date update in version.in 24655 246562023-09-23 GDB Administrator <gdbadmin@sourceware.org> 24657 24658 Automatic date update in version.in 24659 246602023-09-22 Frederic Cambus <fred@statdns.com> 24661 24662 Update the NetBSD system call table to add memfd_create(2) and epoll(2). 24663 Generated from sys/sys/syscall.h revision 1.324. 24664 246652023-09-22 Enze Li <enze.li@hotmail.com> 24666 24667 fbsd-nat: Pacify gcc with no functional changes 24668 I see these errors on FreeBSD/aarch64 when using gcc 12 without passing 24669 --disable-werror. 24670 24671 ===================================================================== 24672 CXX fbsd-nat.o 24673 fbsd-nat.c: In member function 'void fbsd_nat_target::resume_one_process(ptid_t, int, gdb_signal)': 24674 fbsd-nat.c:1208:11: error: unused variable 'request' [-Werror=unused-variable] 24675 1208 | int request; 24676 | ^~~~~~~ 24677 fbsd-nat.c: In member function 'virtual ptid_t fbsd_nat_target::wait(ptid_t, target_waitstatus*, target_wait_flags)': 24678 fbsd-nat.c:1726:22: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local] 24679 1726 | for (inferior *inf : all_non_exited_inferiors (this)) 24680 | ^~~ 24681 fbsd-nat.c:1697:17: note: shadowed declaration is here 24682 1697 | inferior *inf = find_inferior_ptid (this, wptid); 24683 | ^~~ 24684 fbsd-nat.c: In member function 'virtual void fbsd_nat_target::detach(inferior*, int)': 24685 fbsd-nat.c:2044:18: error: variable 'wptid' set but not used [-Werror=unused-but-set-variable] 24686 2044 | ptid_t wptid = wait_1 (ptid, &ws, 0); 24687 | ^~~~~ 24688 cc1plus: all warnings being treated as errors 24689 ===================================================================== 24690 24691 This patch includes the following non-functional changes, 24692 24693 1. Remove unused variable "request". 24694 2. Rename inf to inf_p to avoid shadowed declaration warnings. 24695 3. Mark wptid as used when USE_SIGTRAP_SIGINFO is defined. 24696 24697 Tested on FreeBSD/aarch64 by rebuilding. 24698 24699 Approved-By: John Baldwin <jhb@FreeBSD.org> 24700 247012023-09-22 Tom Tromey <tromey@adacore.com> 24702 24703 Remove keywords from target debug printer names 24704 I recently checked in a patch that removed the use of the "struct" 24705 keyword in some spots. Doing this pointed out that the target 24706 delegate code preserves this keyword -- but, with C++, it does not 24707 really need to. This patch changes make-target-delegates.py to remove 24708 these keywords, and updates target-debug.h to follow. This pointed 24709 out that there was already one redudancy: both 24710 target_debug_print_struct_inferior_p and target_debug_print_inferior_p 24711 existed. 24712 24713 Tested by rebuilding. 24714 24715 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 24716 247172023-09-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 24718 24719 gprofng: 30834 improve disassembly output for call and branch instructions 24720 This patch makes the gprofng disassembler to emit, e.g. 24721 call fprintf@plt [ 0x401060, .-0x49c] 24722 instead of 24723 call 0xfffffffffffffb64 24724 24725 I use bfd_get_synthetic_symtab() to get function names in the .plt section. 24726 I have not yet modified Elf-reader in gprofng to remove parsing of .symtab or 24727 .dynsym sections. But we plan to do it. 24728 24729 gprofng/ChangeLog 24730 2023-09-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 24731 24732 PR gprofng/30834 24733 * src/Disasm.cc: Show the function name in the call instruction 24734 and the relative address in the branch instruction. Remove unused code. 24735 * src/Disasm.h (map_PC_to_func, get_funcname_in_plt): New functions. 24736 * src/Elf.cc: Get function names for the .plt section. 24737 * src/Elf.h (get_funcname_in_plt, get_bfd_symbols): New functions. 24738 * src/Stabs.cc: Add pltSym to SymLst. Remove the conversion to uint32_t. 24739 247402023-09-22 GDB Administrator <gdbadmin@sourceware.org> 24741 24742 Automatic date update in version.in 24743 247442023-09-21 Thomas Weißschuh <thomas@t-8ch.de> 24745 24746 ld: write resolved path to included file to dependency-file 24747 In ldfile_open_command_file_1() name written to the dependency files is 24748 the name as specified passed to the "INCLUDE" directive. 24749 This is before include-path processing so the tracked dependency 24750 location is most likely wrong. 24751 24752 Instead track the opened file at the point where the resolved path is 24753 actually available, in try_open(). 24754 247552023-09-21 GDB Administrator <gdbadmin@sourceware.org> 24756 24757 Automatic date update in version.in 24758 247592023-09-21 Tom Tromey <tromey@adacore.com> 24760 24761 Remove stray trailing "," from DAP breakpoint.py 24762 The buildbot pointed out that the last DAP series I checked in had an 24763 issue. Looking into it, it seems there is a stray trailing "," in 24764 breakpoint.py. This patch removes it. 24765 24766 This seems to point out a test suite deficiency. I will look into 24767 fixing that. 24768 247692023-09-20 Tom Tromey <tom@tromey.com> 24770 24771 Remove explanatory comments from includes 24772 I noticed a comment by an include and remembered that I think these 24773 don't really provide much value -- sometimes they are just editorial, 24774 and sometimes they are obsolete. I think it's better to just remove 24775 them. Tested by rebuilding. 24776 24777 Approved-By: Andrew Burgess <aburgess@redhat.com> 24778 247792023-09-20 Gregory Anders <greg@gpanders.com> 24780 24781 gdb/dap: only include sourceReference if file path does not exist 24782 According to the DAP specification if the "sourceReference" field is 24783 included in a Source object, then the DAP client _must_ make a "source" 24784 request to the debugger to retrieve file contents, even if the Source 24785 object also includes path information. 24786 24787 If the Source's path field is a valid path that the DAP client is able 24788 to read from the filesystem, having to make another request to the 24789 debugger to get the file contents is wasteful and leads to incorrect 24790 results (DAP clients will try to get the contents from the server and 24791 display those contents as a file with the name in "source.path", but 24792 this will conflict with the _acutal_ existing file at "source.path"). 24793 24794 Instead, only set "sourceReference" if the source file path does not 24795 exist. 24796 24797 Approved-By: Tom Tromey <tom@tromey.com> 24798 247992023-09-20 Gregory Anders <greg@gpanders.com> 24800 24801 gdb/dap: use breakpoint fullname to resolve source 24802 If the breakpoint has a fullname, use that as the source path when 24803 resolving the breakpoint source information. This is consistent with 24804 other callers of make_source which also use "fullname" if it exists (see 24805 e.g. DAPFrameDecorator which returns the symtab's fullname). 24806 24807 Approved-By: Tom Tromey <tom@tromey.com> 24808 248092023-09-20 Gregory Anders <greg@gpanders.com> 24810 24811 gdb/dap: ignore unused keyword args in step_out 24812 Some DAP clients may send additional parameters in the stepOut command 24813 (e.g. "granularity") which are not used by GDB, but should nonetheless 24814 be accepted without error. 24815 24816 Approved-By: Tom Tromey <tom@tromey.com> 24817 248182023-09-20 Gregory Anders <greg@gpanders.com> 24819 24820 gdb/dap: check for breakpoint source before unpacking 24821 Not all breakpoints have a source location. For example, a breakpoint 24822 set on a raw address will have only the "address" field populated, but 24823 "source" will be None, which leads to a RuntimeError when attempting to 24824 unpack the filename and line number. 24825 24826 Before attempting to unpack the filename and line number from the 24827 breakpoint, ensure that the source information is not None. Also 24828 populate the source and line information separately from the 24829 "instructionReference" field, so that breakpoints that include only an 24830 address are still included. 24831 24832 Approved-By: Tom Tromey <tom@tromey.com> 24833 248342023-09-20 Tom Tromey <tromey@adacore.com> 24835 24836 Run 'black' on printing.py 24837 The buildbot pointed out that I neglected to re-run 'black' after 24838 making some changes. This patch fixes the oversight. 24839 248402023-09-20 Matthew "strager" Glazar <strager.nds@gmail.com> 24841 24842 gdb/tui: add 'set tui mouse-events off' to restore mouse selection 24843 Rationale: 24844 I use the mouse with my terminal to select and copy text. In gdb, I use 24845 the mouse to select a function name to set a breakpoint, or a variable 24846 name to print, for example. 24847 24848 When gdb is compiled with ncurses mouse support, gdb's TUI mode 24849 intercepts mouse events. Left-clicking and dragging, which would 24850 normally select text, seems to do nothing. This means I cannot select 24851 text using my mouse anymore. This makes it harder to set breakpoints, 24852 print variables, etc. 24853 24854 Solution: 24855 I tried to fix this issue by editing the 'mousemask' call to only enable 24856 buttons 4 and 5. However, this still caused my terminal (gnome-terminal) 24857 to not allow text to be selected. The only way I could make it work is 24858 by calling 'mousemask (0, NULL);'. But doing so disables the mouse code 24859 entirely, which other people might want. 24860 24861 I therefore decided to make a setting in gdb called 'tui mouse-events'. 24862 If enabled (the default), the behavior is as it is now: terminal mouse 24863 events are given to gdb, disabling the terminal's default behavior. 24864 If disabled (opt-in), the behavior is as it was before the year 2020: 24865 terminal mouse events are not given to gdb, therefore the mouse can be 24866 used to select and copy text. 24867 24868 Notes: 24869 I am not attached to the setting name or its description. Feel free to 24870 suggest better wording. 24871 24872 Testing: 24873 I tested this change in gnome-terminal by performing the following steps 24874 manually: 24875 24876 1. Run: gdb --args ./myprogram 24877 2. Enable TUI: press ctrl-x ctrl-a 24878 3. Click and drag text with the mouse. Observe no selection. 24879 4. Input: set tui mouse-events off 24880 5. Click and drag text with the mouse. Observe that selection works now. 24881 6. Input: set tui mouse-events on. 24882 7. Click and drag text with the mouse. Observe no selection. 24883 248842023-09-20 Tom de Vries <tdevries@suse.de> 24885 24886 [gdb/symtab] Error out for .debug_types section in dwz file 24887 There are two methods to factor out type information in a dwarf4 executable: 24888 - use -fdebug-info-types to generate type units in a .debug_types section, and 24889 - use dwz to create partial units. 24890 24891 The dwz method has an extra benefit: it also allows to factor out information 24892 between executables into a newly created .dwz file, pointed to by a 24893 .gnu_debugaltlink section. 24894 24895 There is nothing prohibiting a .gnu_debugaltlink file to contain a 24896 .debug_types section. 24897 24898 It's just not generated by dwz or any other tool atm, and consequently gdb has 24899 no support for it. Enhancement PR symtab/30838 is open about the lack of 24900 support. 24901 24902 Make the current situation explicit by emitting a dwarf error: 24903 ... 24904 (gdb) file struct-with-sig-2^M 24905 Reading symbols from struct-with-sig-2...^M 24906 Dwarf Error: .debug_types section not supported in dwz file^M 24907 ... 24908 and add an assert in write_gdbindex: 24909 ... 24910 + /* See enhancement PR symtab/30838. */ 24911 + gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types)); 24912 ... 24913 to clarify why we can use: 24914 ... 24915 data_buf &cu_list = (per_cu->is_debug_types 24916 ? types_cu_list 24917 : per_cu->is_dwz ? dwz_cu_list : objfile_cu_list); 24918 ... 24919 24920 The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it 24921 keeps the copyright years range. 24922 24923 Tested on x86_64-linux. 24924 24925 Tested-By: Guinevere Larsen <blarsen@redhat.com> 24926 24927 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838 24928 249292023-09-20 Song Mengzhi <song.mengzhi@zte.com.cn> 24930 24931 PR30870, VMS_DEBUG compilation error 24932 Introduced by 8169954446. 24933 24934 PR 30870 24935 * vms-alpha.c (image_write): Remove extraneous parenthesis. 24936 249372023-09-20 GDB Administrator <gdbadmin@sourceware.org> 24938 24939 Automatic date update in version.in 24940 249412023-09-19 Alan Modra <amodra@gmail.com> 24942 24943 readelf.c 'ext' may be used uninitialized 24944 * readelf.c (display_lto_symtab): Init ext. 24945 249462023-09-19 Alan Modra <amodra@gmail.com> 24947 24948 elf-attrs.c memory allocation fail 24949 Report errors rather than segfaulting. 24950 24951 bfd/ 24952 * elf-attrs.c (elf_new_obj_attr): Return NULL on bfd_alloc fail. 24953 (bfd_elf_add_obj_attr_int): Handle NULL return from the above, 24954 and propagate return to callers. 24955 (elf_add_obj_attr_string, elf_add_obj_attr_int_string): Likewise. 24956 (bfd_elf_add_obj_attr_string): Similarly. 24957 (_bfd_elf_copy_obj_attributes): Report error on alloc fails. 24958 (_bfd_elf_parse_attributes): Likewise. 24959 * elf-bfd.h (bfd_elf_add_obj_attr_int): Update prototype. 24960 (bfd_elf_add_obj_attr_string): Likewise. 24961 (bfd_elf_add_obj_attr_int_string): Likewise. 24962 gas/ 24963 * config/obj-elf.c (obj_elf_vendor_attribute): Report fatal 24964 error on out of memory from bfd attribute functions. 24965 * config/tc-arc.c (arc_set_attribute_int): Likewise. 24966 (arc_set_attribute_string, arc_set_public_attributes): Likewise. 24967 * config/tc-arm.c (aeabi_set_attribute_int): Likewise. 24968 (aeabi_set_attribute_string): Likewise. 24969 * config/tc-mips.c (mips_md_finish): Likewise. 24970 * config/tc-msp430.c (msp430_md_finish): Likewise. 24971 * config/tc-riscv.c (riscv_write_out_attrs): Likewise. 24972 * config/tc-sparc.c (sparc_md_finish): Likewise. 24973 * config/tc-tic6x.c (tic6x_set_attribute_int): Likewise. 24974 * config/tc-csky.c (md_begin): Likewise. 24975 (set_csky_attribute): Return ok status. 24976 249772023-09-19 Tom Tromey <tromey@adacore.com> 24978 24979 Handle pointers and references correctly in DAP 24980 A user pointed out that the current DAP variable code does not let the 24981 client deference a pointer. Oops! 24982 24983 Fixing this oversight is simple enough -- adding a new no-op 24984 pretty-printer for pointers and references is quite simple. 24985 24986 However, doing this naive caused a regession in scopes.exp, which 24987 expected there to be no children of a 'const char *' variable. This 24988 problem was fixed by the preceding patches in the series, which ensure 24989 that a C type of this kind is recognized as a string. 24990 24991 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30821 24992 249932023-09-19 Tom Tromey <tromey@adacore.com> 24994 24995 Give a language to a type 24996 This changes main_type to hold a language, and updates the debug 24997 readers to set this field. This is done by adding the language to the 24998 type-allocator object. 24999 25000 Note that the non-DWARF readers are changed on a "best effort" basis. 25001 25002 This patch also reimplements type::is_array_like to use the type's 25003 language, and it adds a new type::is_string_like as well. This in 25004 turn lets us change the Python implementation of these methods to 25005 simply defer to the type. 25006 250072023-09-19 Tom Tromey <tromey@adacore.com> 25008 25009 Add is_array_like and to_array to language_defn 25010 This adds new is_array_like and to_array methods to language_defn. 25011 This will be used in a subsequent patch that generalizes the new 25012 Python array- and string-handling code. 25013 25014 Regularize some DWARF type initialization 25015 In one spot, it will be convenient for a subsequent patch if the CU is 25016 passed to a type-creation helper function. In another spot, remove 25017 the redundant 'objfile' parameter to another such function. 25018 25019 Pass a type allocator to init_fixed_point_type 25020 init_fixed_point_type currently takes an objfile and creates its own 25021 type allocator. However, for a later patch it is more convenient if 25022 this function accepts a type allocator. This patch makes this change. 25023 250242023-09-19 Tom Tromey <tromey@adacore.com> 25025 25026 Use gdb::checked_static_cast for catchpoints 25027 This replaces some casts to various kinds of catchpoint with 25028 checked_static_cast. 25029 25030 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25031 250322023-09-19 Tom Tromey <tromey@adacore.com> 25033 25034 Use gdb::checked_static_cast for code_breakpoint 25035 This replaces some casts to 'code_breakpoint *' with 25036 checked_static_cast. 25037 25038 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25039 250402023-09-19 Tom Tromey <tromey@adacore.com> 25041 25042 Use gdb::checked_static_cast for tracepoints 25043 This replaces some casts to 'tracepoint *' with checked_static_cast. 25044 Some functions are changed to accept a 'tracepoint *' now, for better 25045 type safety. 25046 25047 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25048 250492023-09-19 Tom Tromey <tromey@adacore.com> 25050 25051 Use gdb::checked_static_cast for watchpoints 25052 This replaces some casts to 'watchpoint *' with checked_static_cast. 25053 In one spot, an unnecessary block is also removed. 25054 25055 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25056 250572023-09-19 Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> 25058 25059 gdb, breakpoint: add a destructor to the watchpoint struct 25060 Make sure to unlink the related breakpoint when the watchpoint instance 25061 is deleted. This prevents having a wp-related breakpoint that is 25062 linked to a NULL watchpoint (e.g. the watchpoint instance is being 25063 deleted when the 'watch' command fails). With the below scenario, 25064 having such a left out breakpoint will lead to a GDB hang, and this 25065 is due to an infinite loop when deleting all inferior breakpoints. 25066 25067 Scenario: 25068 (gdb) set can-use-hw-watchpoints 0 25069 (gdb) awatch <SCOPE VAR> 25070 Can't set read/access watchpoint when hardware watchpoints are disabled. 25071 (gdb) rwatch <SCOPE VAR> 25072 Can't set read/access watchpoint when hardware watchpoints are disabled. 25073 (gdb) <continue the program until the end> 25074 >> HANG << 25075 25076 Reviewed-by: Bruno Larsen <blarsen@redhat.com> 25077 250782023-09-19 Guinevere Larsen <blarsen@redhat.com> 25079 25080 gdb/cli: fixes to newly added "list ." command 25081 After the series that added this command was pushed, Pedro mentioned 25082 that the news description could easily be misinterpreted, as well as 25083 some code and test improvements that should be made. 25084 25085 While fixing the test, I realized that code repetition wasn't 25086 happening as it should, so I took care of that too. 25087 25088 Approved-By: Andrew Burgess <aburgess@redhat.com> 25089 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 25090 250912023-09-19 GDB Administrator <gdbadmin@sourceware.org> 25092 25093 Automatic date update in version.in 25094 250952023-09-18 Tom Tromey <tom@tromey.com> 25096 25097 More type safety for symbol_search 25098 This patch changes class symbol_search to store a block_enum rather 25099 than an int. 25100 25101 Regression tested on x86-64 Fedora 38. 25102 25103 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25104 251052023-09-18 Tom Tromey <tromey@adacore.com> 25106 25107 Move val_prettyformat to valprint.h 25108 I stumbled across an ancient FIXME comment that was easy to fix -- 25109 val_prettyformat does not need to be in defs.h, and is easily moved to 25110 valprint.h, where (despite what the comment says) it belongs. 25111 25112 Tested by rebuilding. 25113 251142023-09-18 Jacob Navia <jacob@jacob.remcomp.fr> 25115 25116 Fix: Use of uninitialized memory 25117 * config/tc-riscv.c (riscv_ip_hardcode): Fully initialise the allocated riscv_opcode structure. 25118 251192023-09-18 Simon Marchi <simon.marchi@polymtl.ca> 25120 25121 gdb: remove unused free_actions declaration 25122 This appears to be a leftover from a past change. 25123 25124 Change-Id: I8e747edbf291400e4f417f5c6875049479a1669a 25125 251262023-09-18 GDB Administrator <gdbadmin@sourceware.org> 25127 25128 Automatic date update in version.in 25129 251302023-09-17 GDB Administrator <gdbadmin@sourceware.org> 25131 25132 Automatic date update in version.in 25133 251342023-09-16 Tom de Vries <tdevries@suse.de> 25135 25136 [gdb/symtab] Fix overly large gdb-index file check for 32-bit 25137 Add a unit test which checks that write_gdb_index_1 will throw 25138 an error when the size of the file would exceed the maximum value 25139 capable of being represented by 'offset_type'. 25140 25141 The unit test fails on 32-bit systems due to wrapping overflow. Fix this by 25142 changing the type of total_len in write_gdbindex_1 from size_t to uint64_t. 25143 25144 Tested on x86_64-linux. 25145 25146 Co-Authored-By: Kevin Buettner <kevinb@redhat.com> 25147 Approved-by: Kevin Buettner <kevinb@redhat.com> 25148 251492023-09-16 GDB Administrator <gdbadmin@sourceware.org> 25150 25151 Automatic date update in version.in 25152 251532023-09-15 Simon Marchi <simon.marchi@efficios.com> 25154 25155 gdb: remove -Werror annotations from MAINTAINERS file 25156 I don't think these are useful nowadays, since we now expect all code to 25157 be -Werror clean (it's the default in development branches). 25158 25159 Change-Id: I8c3b86c70d683bd41344d27add0ac2627a474d20 25160 Approved-By: Tom Tromey <tom@tromey.com> 25161 251622023-09-15 Simon Marchi <simon.marchi@efficios.com> 25163 25164 gdb/amdgpu: add precise-memory support 25165 The amd-dbgapi library exposes a setting called "memory precision" for 25166 AMD GPUs [1]. Here's a copy of the description of the setting: 25167 25168 The AMD GPU can overlap the execution of memory instructions with other 25169 instructions. This can result in a wave stopping due to a memory violation 25170 or hardware data watchpoint hit with a program counter beyond the 25171 instruction that caused the wave to stop. 25172 25173 Some architectures allow the hardware to be configured to always wait for 25174 memory operations to complete before continuing. This will result in the 25175 wave stopping at the instruction immediately after the one that caused the 25176 stop event. Enabling this mode can make execution of waves significantly 25177 slower. 25178 25179 Expose this option through a new "amdgpu precise-memory" setting. 25180 25181 The precise memory setting is per inferior. The setting is transferred 25182 from one inferior to another when using the clone-inferior command, or 25183 when a new inferior is created following an exec or a fork. 25184 25185 It can be set before starting the inferior, in which case GDB will 25186 attempt to apply what the user wants when attaching amd-dbgapi. If the 25187 user has requested to enable precise memory, but it can't be enabled 25188 (not all hardware supports it), GDB prints a warning. 25189 25190 If precise memory is disabled, GDB prints a warning when hitting a 25191 memory exception (translated into GDB_SIGNAL_SEGV or GDB_SIGNAL_BUS), 25192 saying that the stop location may not be precise. 25193 25194 Note that the precise memory setting also affects memory watchpoint 25195 reporting, but the watchpoint support for AMD GPUs hasn't been 25196 upstreamed to GDB yet. When we do upstream watchpoint support, GDB will 25197 produce a similar warning message when stopping due to a watchpoint if 25198 precise memory is disabled. 25199 25200 Add a handful of tests. Add a util proc 25201 "hip_devices_support_precise_memory", which indicates if all devices 25202 used for testing support that feature. 25203 25204 [1] https://github.com/ROCm-Developer-Tools/ROCdbgapi/blob/687374258a27b5aab1309a7e8ded719e2f1ed3b1/include/amd-dbgapi.h.in#L6300-L6317 25205 25206 Change-Id: Ife1a99c0e960513da375ced8f8afaf8e47a61b3f 25207 Approved-By: Lancelot Six <lancelot.six@amd.com> 25208 252092023-09-15 Simon Marchi <simon.marchi@efficios.com> 25210 25211 gdb/testsuite: add linux target check in allow_hipcc_tests 25212 ROCm / HIP tests should only run on Linux for now, existing gdb.rocm 25213 tests miss such a check. Add an "istarget linux" check in 25214 allow_hipcc_tests. 25215 25216 Change-Id: I71f69e510a754f2fdadc32de53b923ebb9835ab5 25217 Approved-By: Lancelot Six <lancelot.six@amd.com> 25218 252192023-09-15 Simon Marchi <simon.marchi@efficios.com> 25220 25221 gdb: add inferior_cloned observable 25222 The following patch makes the amdgpu port transfer a property from the 25223 original inferior to the new inferior when using the clone-inferior 25224 command. Add the inferior_cloned observable to help with this. 25225 25226 Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631 25227 Approved-By: Tom Tromey <tom@tromey.com> 25228 252292023-09-15 Tom Tromey <tromey@adacore.com> 25230 25231 Fix build failure with GCC 4.8 25232 A user pointed out that the build failed with GCC 4.8. The problem 25233 was that the form used by the std::hash specialization of ptid_t was 25234 not accepted. This patch rewrites this code into a form that is 25235 acceptable to the older compiler. 25236 25237 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25238 252392023-09-15 Laurent Morichetti <laurent.morichetti@amd.com> 25240 25241 gdb/amdgpu: Silence wave termination messages 25242 After commit 9d7d58e7262, the amdgpu target started printing 25243 "thread exited" messages when pruning waves that had terminated. 25244 25245 ... 25246 [AMDGPU Wave ?:?:?:2045 (?,?,?)/? exited] 25247 [AMDGPU Wave ?:?:?:2046 (?,?,?)/? exited] 25248 [AMDGPU Wave ?:?:?:2047 (?,?,?)/? exited] 25249 [AMDGPU Wave ?:?:?:2048 (?,?,?)/? exited] 25250 ... 25251 25252 The issue was that before commit 9d7d58e7262, delete_thread was silent 25253 by default due to a bug that the commit fixed. 25254 25255 Replaced the amdgpu target call to delete_thread with a call to 25256 delete_thread_silent. 25257 25258 Change-Id: Ie5d5a4c5be851f092d2315b2afa6a36a30a05245 25259 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25260 252612023-09-15 Simon Marchi <simon.marchi@efficios.com> 25262 25263 gdb: add Lancelot Six as maintainer of the AMD GPU port 25264 Lancelot has accepted to take the role of maintainer for the AMD GPU 25265 port. The AMD GPU port (amdgpu as I've written in the MAINTAINERS file) 25266 is an umbrella term for everything needed to make this work: the amdgcn 25267 arch, the amd-dbgapi target, solib-rocm, etc. 25268 25269 Thanks for accepting the role, and congratulations! 25270 25271 Change-Id: I4c898042fda49b45dcb0d54ca94731bb57287f71 25272 252732023-09-15 Tom Tromey <tromey@adacore.com> 25274 25275 Rename split_style::DOT 25276 This renames split_style::DOT, to avoid name clashes when building gdb 25277 with an old version of Bison (2.3, the version available on macOS). 25278 25279 In particular the error looks like: 25280 25281 ./split-name.h:34:3: error: expected identifier 25282 DOT, 25283 ^ 25284 m2-exp.c:163:13: note: expanded from macro 'DOT' 25285 25286 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286 25287 252882023-09-15 Claudiu Zissulescu <claziss@gmail.com> 25289 25290 arc: Fix alignment of the TLS Translation Control Block 25291 The R_ARC_TLS_LE_32 is defined as S + A + TLS_TBSS - TLS_REL, where 25292 25293 - S is the base address of the symbol in the memory 25294 - A is the symbol addendum 25295 - TLS_TBSS is the TLS Translation Control Block size (aligned) 25296 - TLS_REL is the base of the TLS section 25297 25298 Given the next code snip: 25299 25300 __thread int data_var = 12; 25301 __attribute__((__aligned__(128))) __thread int data_var_128 = 128; 25302 __thread int bss_var; 25303 __attribute__((__aligned__(256))) __thread int bss_var_256; 25304 25305 int __start(void) 25306 { 25307 return data_var + data_var_128 + bss_var + bss_var_256; 25308 } 25309 25310 The current code returns different TLS_TBSS values for .tdata and 25311 .tbss. This patch fixes this by using the linker provided tls_sec. 25312 25313 bfd/ 25314 25315 * elf32-arc.c (TLS_REL): Clean up. 25316 (TLS_TBSS): Use tls_sec alignment. 25317 (arc_do_relocation): Check if we have valid tls_sec. 25318 253192023-09-15 Andrew Burgess <aburgess@redhat.com> 25320 25321 gdb: small cleanup in symbol_file_add_with_addrs 25322 While looking at how gdb::observers::new_objfile was used, I found 25323 some code in symbol_file_add_with_addrs that I thought could be 25324 improved. 25325 25326 Instead of: 25327 25328 if (condition) 25329 { 25330 ... 25331 return; 25332 } 25333 25334 ... 25335 return; 25336 25337 Where some parts of '...' identical between the two branches. I think 25338 it would be nicer if the duplication is removed, and we just use: 25339 25340 if (!condition) 25341 ... 25342 25343 to guard the one statement that should only happen when the condition 25344 is not true. 25345 25346 There is one change in this commit though that is (possibly) 25347 significant, there is a call to bfd_cache_close_all() that was only 25348 present in the second block. After this commit we now call that 25349 function for both paths. 25350 25351 The call to bfd_cache_close_all was added in commit: 25352 25353 commit ce7d45220e4ed342d4a77fcd2f312e85e1100971 25354 Date: Fri Jul 30 12:05:45 2004 +0000 25355 25356 with the purpose of ensuring that GDB doesn't hold the BFDs open 25357 unnecessarily, thus preventing the files from being updated on some 25358 hosts (e.g. Win32). 25359 25360 In the early exit case we previously didn't call bfd_cache_close_all, 25361 with the result that GDB would continue to hold open some BFD objects 25362 longer than needed. 25363 25364 After this commit, but calling bfd_cache_close_all for both paths this 25365 problem is solved. 25366 25367 I'm not sure how this change could be tested, I don't believe there's 25368 any GDB (maintenance) command that displays the BFD cache contents, so 25369 we can't check the cache contents easily. Ideas are welcome though. 25370 25371 Approved-By: Tom Tromey <tom@tromey.com> 25372 253732023-09-15 Andrew Burgess <aburgess@redhat.com> 25374 25375 gdb: add some missing filename styling 25376 Spotted a few places where we can add filename styling. 25377 25378 Approved-By: Tom Tromey <tom@tromey.com> 25379 253802023-09-15 Jinyang He <hejinyang@loongson.cn> 25381 25382 LoongArch: Enable gas sort relocs 25383 The md_pre_output_hook creating fixup is asynchronous, causing relocs 25384 may be out of order in .eh_frame. Define GAS_SORT_RELOCS so that reorder 25385 relocs when write_relocs. 25386 25387 Reported-by: Rui Ueyama <rui314@gmail.com> 25388 253892023-09-15 Jan Beulich <jbeulich@suse.com> 25390 25391 x86: fold CpuLM and Cpu64 25392 Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while 25393 Cpu64 is solely used in insn templates, they no longer need to be 25394 treated different from other "ordinary" flags; the only "unusual" one 25395 left if CpuNo64. Fold both, leaving just Cpu64. 25396 253972023-09-15 Jan Beulich <jbeulich@suse.com> 25398 25399 x86: don't play with cpu_arch_flags.cpu{,no}64 25400 A total four places exists where we set the two bits from flag_code, but 25401 these values are never used. The two bits are evaluated only when coming 25402 from insn templates. 25403 25404 Drop these assignments. Also make obvious that cpu_flags_check_cpu64() 25405 is only ever used against insn templates. 25406 254072023-09-15 Jan Beulich <jbeulich@suse.com> 25408 25409 x86: make code size vs CPU arch checking consistent 25410 While update_code_flag() checks for LM / i386, set_cpu_arch() so far 25411 didn't, allowing e.g. 64-bit code to be emitted after ".arch generic32". 25412 25413 Oddly enough a few of our testcases actually exhibit bad behavior (and 25414 hence need minor adjustments). 25415 254162023-09-15 Jan Beulich <jbeulich@suse.com> 25417 25418 x86: re-order update_code_flag() 25419 Do checks before updating state, and bail upon failure of either of the 25420 checks. While moving the code, eliminate some redundancy. 25421 254222023-09-15 Guinevere Larsen <blarsen@redhat.com> 25423 25424 gdb/testsuite: explicitly test for stderr in gdb.mi/mi-dprintf.exp 25425 As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some 25426 compilers such as clang don't add debug information about stderr by 25427 default, leaving it to external debug packages. 25428 25429 This commit adds a way to check if GDB has access to stderr information 25430 when in MI mode, and uses this new mechanism to skip the related section 25431 of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a 25432 test in that file. 25433 25434 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 25435 Approved-By: Kevin Buettner <kevinb@redhat.com> 25436 254372023-09-15 GDB Administrator <gdbadmin@sourceware.org> 25438 25439 Automatic date update in version.in 25440 254412023-09-15 Kevin Buettner <kevinb@redhat.com> 25442 25443 Throw error when creating an overly large gdb-index file 25444 The header in a .gdb_index section uses 32-bit unsigned offsets to 25445 refer to other areas of the section. Thus, there is a size limit of 25446 2^32-1 which is currently unaccounted for by GDB's code for outputting 25447 these sections. 25448 25449 At the moment, when GDB creates an overly large section, it will exit 25450 abnormally due to an internal error, which is caused by a failed 25451 assert in assert_file_size, which in turn is called from 25452 write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c. 25453 25454 This is what happens when that assert fails: 25455 25456 $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/" 25457 Reading symbols from ./libgraph_tool_inference.so... 25458 No executable file now. 25459 Discard symbol table from `libgraph_tool_inference.so'? (y or n) n 25460 Not confirmed. 25461 ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed. 25462 A problem internal to GDB has been detected, 25463 further debugging may prove unreliable. 25464 ----- Backtrace ----- 25465 0x55fddb4d78b0 gdb_internal_backtrace_1 25466 ../../gdb/bt-utils.c:122 25467 0x55fddb4d78b0 _Z22gdb_internal_backtracev 25468 ../../gdb/bt-utils.c:168 25469 0x55fddb98b5d4 internal_vproblem 25470 ../../gdb/utils.c:396 25471 0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag 25472 ../../gdb/utils.c:476 25473 0x55fddbb71654 _Z18internal_error_locPKciS0_z 25474 ../../gdbsupport/errors.cc:58 25475 0x55fddb5a0f23 assert_file_size 25476 ../../gdb/dwarf2/index-write.c:1069 25477 0x55fddb5a1ee0 assert_file_size 25478 /usr/include/c++/13/bits/stl_iterator.h:1158 25479 0x55fddb5a1ee0 write_gdbindex_1 25480 ../../gdb/dwarf2/index-write.c:1119 25481 0x55fddb5a51be write_gdbindex 25482 ../../gdb/dwarf2/index-write.c:1273 25483 [...] 25484 --------------------- 25485 ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed. 25486 25487 This problem was encountered while building the python-graph-tool 25488 package on Fedora. The Fedora bugzilla bug can be found here: 25489 25490 https://bugzilla.redhat.com/show_bug.cgi?id=1773651 25491 25492 This commit prevents the internal error from occurring by calling error() 25493 when the file size exceeds 2^32-1. 25494 25495 Using a gdb built with this commit, I now see this behavior instead: 25496 25497 $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/" 25498 Reading symbols from ./libgraph_tool_inference.so... 25499 No executable file now. 25500 Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n 25501 Not confirmed. 25502 Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded 25503 (gdb) 25504 25505 I wish I could provide a test case, but due to the sizes of both the 25506 input and output files, I think that testing resources would be 25507 strained or exceeded in many environments. 25508 25509 My testing on Fedora 38 shows no regressions. 25510 25511 Approved-by: Tom Tromey <tom@tromey.com> 25512 255132023-09-14 Andrew Burgess <aburgess@redhat.com> 25514 25515 gdb: fix buffer overflow in DWARF reader 25516 In this commit: 25517 25518 commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e 25519 Date: Fri Nov 19 10:12:44 2021 -0700 25520 25521 Handle multiple addresses in call_site_target 25522 25523 a buffer overflow bug was introduced when the following code was 25524 added: 25525 25526 CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR, 25527 addresses.size ()); 25528 std::copy (addresses.begin (), addresses.end (), saved); 25529 25530 The definition of XOBNEWVAR is (from libiberty.h): 25531 25532 #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S))) 25533 25534 So 'saved' is going to point to addresses.size () bytes of memory, 25535 however, the std::copy will write addresses.size () number of 25536 CORE_ADDR sized entries to the address pointed to by 'saved', this is 25537 going to result in memory corruption. 25538 25539 The mistake is that we should have used XOBNEWVEC, which allocates a 25540 vector of entries, the definition of XOBNEWVEC is: 25541 25542 #define XOBNEWVEC(O, T, N) \ 25543 ((T *) obstack_alloc ((O), sizeof (T) * (N))) 25544 25545 Which means we will have set aside enough space to create a copy of 25546 the contents of the addresses vector. 25547 25548 I'm not sure how to create a test for this problem, this issue cropped 25549 up when debugging a particular i686 built binary, which just happened 25550 to trigger a glibc assertion (likely due to random memory corruption), 25551 debugging the same binary built for x86-64 appeared to work just fine. 25552 25553 Using valgrind on the failing GDB binary pointed straight to the cause 25554 of the problem, and with this patch in place there are no longer 25555 valgrind errors in this area. 25556 25557 If anyone has ideas for a test I'm happy to work on something. 25558 25559 Co-Authored-By: Keith Seitz <keiths@redhat.com> 25560 Approved-By: Tom Tromey <tom@tromey.com> 25561 255622023-09-14 Tom de Vries <tdevries@suse.de> 25563 25564 [gdb/exp] Clean up asap in value_print_array_elements 25565 I've been running the test-suite on an i686-linux laptop with 1GB of memory, 25566 and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb 25567 not being able to spawn for a large number of test-cases afterwards. 25568 25569 So I investigated the memory usage, on my usual x86_64-linux development 25570 platform. 25571 25572 The test-case is compiled with -DCRASH_GDB=2097152, so this: 25573 ... 25574 static int a[CRASH_GDB], b[CRASH_GDB]; 25575 ... 25576 with sizeof (int) == 4 represents two arrays of 8MB each. 25577 25578 Say we add a loop around the "print a" command and print space usage 25579 statistics: 25580 ... 25581 gdb_test "maint set per-command space on" 25582 for {set i 0} {$i < 100} {incr i} { 25583 gdb_test "print a" 25584 } 25585 ... 25586 25587 This gets us: 25588 ... 25589 (gdb) print a^M 25590 $1 = {0 <repeats 2097152 times>}^M 25591 Space used: 478248960 (+469356544 for this command)^M 25592 (gdb) print a^M 25593 $2 = {0 <repeats 2097152 times>}^M 25594 Space used: 486629376 (+8380416 for this command)^M 25595 (gdb) print a^M 25596 $3 = {0 <repeats 2097152 times>}^M 25597 Space used: 495009792 (+8380416 for this command)^M 25598 ... 25599 (gdb) print a^M 25600 $100 = {0 <repeats 2097152 times>}^M 25601 Space used: 1308721152 (+8380416 for this command)^M 25602 ... 25603 25604 In other words, we start out at 8MB, and the first print costs us about 469MB, 25605 and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the 25606 i686-linux laptop, the first print costs us 335MB. ] 25607 25608 The subsequent 8MBs are consistent with the values being saved into the value 25609 history, but the usage for the initial print seems somewhat excessive. 25610 25611 There is a PR open about needing sparse representation of large arrays 25612 (PR8819), but this memory usage points to an independent problem. 25613 25614 The function value_print_array_elements contains a scoped_value_mark to free 25615 allocated values in the outer loop, but it doesn't prevent the inner loop from 25616 allocating a lot of values. 25617 25618 Fix this by adding a scoped_value_mark in the inner loop, after which we have: 25619 ... 25620 (gdb) print a^M 25621 $1 = {0 <repeats 2097152 times>}^M 25622 Space used: 8892416 (+0 for this command)^M 25623 (gdb) print a^M 25624 $2 = {0 <repeats 2097152 times>}^M 25625 Space used: 8892416 (+0 for this command)^M 25626 (gdb) print a^M 25627 $3 = {0 <repeats 2097152 times>}^M 25628 Space used: 8892416 (+0 for this command)^M 25629 ... 25630 (gdb) print a^M 25631 $100 = {0 <repeats 2097152 times>}^M 25632 Space used: 8892416 (+0 for this command)^M 25633 ... 25634 25635 Note that the +0 here just means that the mallocs did not trigger an sbrk. 25636 This is dependent on malloc (which can use either mmap or sbrk or some 25637 pre-allocated memory) and will likely vary between different tunings, versions 25638 and implementations, so this does not give us a reliable way detect the 25639 problem in a minimal way. 25640 25641 A more reliable way of detecting the problem is: 25642 ... 25643 void 25644 value_free_to_mark (const struct value *mark) 25645 { 25646 + size_t before = all_values.size (); 25647 auto iter = std::find (all_values.begin (), all_values.end (), mark); 25648 if (iter == all_values.end ()) 25649 all_values.clear (); 25650 else 25651 all_values.erase (iter + 1, all_values.end ()); 25652 + size_t after = all_values.size (); 25653 + if (before - after >= 1024) 25654 + fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after); 25655 ... 25656 which without the fix tells us: 25657 ... 25658 +print a 25659 value_free_to_mark freed 2097152 items 25660 $1 = {0 <repeats 2097152 times>} 25661 ... 25662 25663 Fix a similar problem for Fortran: 25664 ... 25665 +print array1 25666 value_free_to_mark freed 4194303 items 25667 $1 = (0, <repeats 2097152 times>) 25668 ... 25669 in fortran_array_printer_impl::process_element. 25670 25671 The problem also exists for Ada: 25672 ... 25673 +print Arr 25674 value_free_to_mark freed 2097152 items 25675 $1 = (0 <repeats 2097152 times>) 25676 ... 25677 but is fixed by the fix for C. 25678 25679 Add Fortran and Ada variants of the test-case. The *.exp files are similar 25680 enough to the original to keep the copyright years range. 25681 25682 While writing the Fortran test-case, I ran into needing an additional print 25683 setting to print the entire array in repeat form, filed as PR exp/30817. 25684 25685 I managed to apply the compilation loop for the Ada variant as well, but with 25686 a cumbersome repetition style. I noticed no other test-case uses gnateD, so 25687 perhaps there's a better way of implementing this. 25688 25689 The regression test included in the patch is formulated in its weakest 25690 form, to avoid false positive FAILs, which also means that smaller regressions 25691 may not get detected. 25692 25693 Tested on x86_64-linux. 25694 25695 Approved-By: Tom Tromey <tom@tromey.com> 25696 256972023-09-14 Tom de Vries <tdevries@suse.de> 25698 25699 [gdb/testsuite] Modernize gdb.base/huge.exp 25700 Rewrite test-case gdb.base/huge.exp: 25701 - use build_executable rather than gdb_compile, 25702 - use save_vars, 25703 - factor out hardcoded loop limits min and max, 25704 - handle compilation failure using require, and 25705 - avoid using . in regexp to match $, {} and <>. 25706 25707 Tested on x86_64-linux. 25708 25709 Approved-By: Tom Tromey <tom@tromey.com> 25710 257112023-09-14 Jan Beulich <jbeulich@suse.com> 25712 25713 x86: Vxy naming correction 25714 Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that 25715 operand purpose isn't properly reflected in Vxy's definition. Rename 25716 "dst" to "src", thus bringing things in line with Exy. 25717 257182023-09-14 Jan Beulich <jbeulich@suse.com> 25719 25720 x86: support AVX10.1 vector size restrictions 25721 Recognize "/<number>" suffixes on both -march=+avx10.1 and the 25722 corresponding .arch directive, setting an upper bound on the vector size 25723 that insns may use. Such a restriction can be reset by setting a new base 25724 architecture, by using a suffix-less form, by disabling AVX10, or by 25725 enabling any other VEX/EVEX-based vector extension. 25726 25727 While for most insns we can suppress their use with too wide operands 25728 via registers becoming unavailable (or in Intel syntax memory operand 25729 size specifiers not being recognized), mask register insns have to have 25730 their minimum required vector size specified in a new attribute. (Of 25731 course this new attribute could also be used on other insns.) 25732 25733 Note that .insn continues to be permitted to emit EVEX{512,256} (and 25734 VEX256 ones) encodings regardless of vector size restrictions in place. 25735 Of course these can't be expressed using zmm (or ymm) operands then, 25736 but need using the EVEX.512.* forms (broadcast forms may be usable right 25737 now, but this may go away so shouldn't be relied upon). This is why no 25738 assertions should be added to build_{e,}vex_prefix(). 25739 257402023-09-14 Jan Beulich <jbeulich@suse.com> 25741 25742 x86: support AVX10.1/512 25743 Since this is merely a re-branding of certain AVX512* features, there's 25744 little code to be added. 25745 25746 The main aspect here are new testcases. In order to be able to re-use 25747 some of the existing testcases, several of them need their start symbols 25748 adjusted. Note that 256- and 128-bit tests want adding here, as these 25749 need to work right away. Subsequently they'll gain vector length 25750 constraints. 25751 25752 Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ 25753 test. 25754 257552023-09-14 Jan Beulich <jbeulich@suse.com> 25756 25757 x86: make AES/PCMULQDQ respectively prereqs of VAES/VPCMULQDQ 25758 These probably should have been put in place already anyway, but they're 25759 very much wanted in order to then put AVX10.1 support on top. Note that 25760 to avoid reverse dependencies towards SSE (just like we already do for 25761 AVX and XOP), add_isa_dependencies() needs some further tweaking. 25762 25763 While there also address a related anomaly: Disabling AES but neither 25764 AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit 25765 VEX-encoded forms available. Note that for this the VAES insns are moved 25766 past the AVX+AES ones, to avoid the property-11 test suddenly failing. 25767 The test really is wrong, but let's not also make things inconsistent: 25768 Without the movement, YMM use would be correctly recorded for the 25769 128-bit forms simply because the first template already matches, as long 25770 as VAES wasn't disabled. Yet it still wouldn't be if only AVX+AES were 25771 enabled. Nor would behavior here then be the same as for VPCLMUL* insns. 25772 257732023-09-14 GDB Administrator <gdbadmin@sourceware.org> 25774 25775 Automatic date update in version.in 25776 257772023-09-13 Jacob Navia <jacob@jacob.remcomp.fr> 25778 25779 Fix: "Missing NULL check" 25780 * elf.c (_bfd_elf_init_reloc_shdr): Don't segfault on alloc fail. 25781 257822023-09-13 Alan Modra <amodra@gmail.com> 25783 25784 Fix: "Possible Memory leak in bed hash.c" 25785 * elf-strtab.c (_bfd_elf_strtab_init): In the event of memory allocation failure, make sure that the hash table is freed. 25786 257872023-09-13 GDB Administrator <gdbadmin@sourceware.org> 25788 25789 Automatic date update in version.in 25790 257912023-09-12 Simon Marchi <simon.marchi@efficios.com> 25792 25793 gdb/mi: remove warning about mi1 25794 Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI 25795 version 1"). It is no longer possible to reach this warning, since 25796 trying to use interpreter mi1 bails out before: 25797 25798 $ ./gdb -nx -q --data-directory=data-directory -i mi1 25799 Interpreter `mi1' unrecognized 25800 25801 Change-Id: Ie43b21e01bca1407995150c729531a70ee662003 25802 Approved-By: Tom Tromey <tom@tromey.com> 25803 258042023-09-12 Tom Tromey <tromey@adacore.com> 25805 25806 Avoid spurious breakpoint-setting failure in DAP 25807 A user pointed out that if a DAP setBreakpoints request has a 'source' 25808 field in a SourceBreakpoint object, then the gdb DAP implementation 25809 will throw an exception. 25810 25811 While SourceBreakpoint does not allow 'source' in the spec, it seems 25812 better to me to accept it. I don't think we should fully go down the 25813 "Postel's Law" path -- after all, we have the type-checker -- but at 25814 the same time, if we do send errors, they should be intentional and 25815 not artifacts of the implementation. 25816 25817 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30820 25818 258192023-09-12 Enze Li <enze.li@hotmail.com> 25820 25821 gdb: Fix -Wuninitialized issue 25822 I see the following warning when building GDB on FreeBSD/amd64 with 25823 Clang 14, 25824 25825 ====================================================================== 25826 CXX mdebugread.o 25827 mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized] 25828 f->set_loc_enumval (tsym.value); 25829 ^ 25830 mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning 25831 struct field *f; 25832 ^ 25833 = nullptr 25834 ====================================================================== 25835 25836 after digging a little, I realized that we can not simply do what 25837 Clang 14 says. 25838 25839 The root cause of this issue is that we lost the initialization of 25840 the variable 'f' in this commit, 25841 25842 commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e 25843 Date: Thu Aug 31 09:37:44 2023 +0200 25844 25845 [gdb/symtab] Factor out type::{alloc_fields,copy_fields} 25846 25847 we have made these modifications, 25848 25849 --------------------------------------------------------------------- 25850 --- a/gdb/mdebugread.c 25851 +++ b/gdb/mdebugread.c 25852 @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend, 25853 25854 t->set_code (type_code); 25855 t->set_length (sh->value); 25856 - t->set_num_fields (nfields); 25857 - f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field))); 25858 - t->set_fields (f); 25859 + t->alloc_fields (nfields, false); 25860 --------------------------------------------------------------------- 25861 25862 The problem is that the variable 'f' is used in the second half of 25863 parse_symbol, that's why Clang complained. 25864 25865 To fix this issue we need to ensure that the varibale 'f' is 25866 initialized. Calling the fields method is an obvious way to fix this 25867 issue. 25868 25869 Tested on FreeBSD/amd64 by rebuilding. 25870 25871 Approved-By: Tom de Vries <tdevries@suse.de> 25872 258732023-09-12 Lancelot Six <lancelot.six@amd.com> 25874 25875 gdb/testsuite/rocm: fix rocm-multi-inferior-gpu.cpp 25876 The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a 25877 call to execl which does not have NULL as a last argument. This is 25878 an invalid use of execl. This patch fixes this oversight. 25879 25880 Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2 25881 Approved-By: Tom Tromey <tom@tromey.com> 25882 258832023-09-12 GDB Administrator <gdbadmin@sourceware.org> 25884 25885 Automatic date update in version.in 25886 258872023-09-11 Tom Tromey <tromey@adacore.com> 25888 25889 Specialize std::hash for ptid_t 25890 This changes hash_ptid to instead be a specialization of std::hash. 25891 This makes it a little easier to use with standard containers. 25892 25893 Approved-By: Simon Marchi <simon.marchi@efficios.com> 25894 258952023-09-11 Tom Tromey <tromey@adacore.com> 25896 25897 Update Python signal-handling documentation 25898 I noticed a typo in the "Basic Python" node, and when fixing it 25899 realized that the paragraph could use a link to the block_signals 25900 function. This patch is the result. 25901 25902 Approved-By: Eli Zaretskii <eliz@gnu.org> 25903 259042023-09-11 Simon Marchi <simon.marchi@polymtl.ca> 25905 25906 gdb/testsuite: use foreach_with_prefix in gdb.guile/scm-ports.exp 25907 Simplify things a bit using foreach_with_prefix. The only expected 25908 change is in the naming of tests. 25909 25910 Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017 25911 Approved-By: Andrew Burgess <aburgess@redhat.com> 25912 259132023-09-11 Ijaz, Abdul B <abdul.b.ijaz@intel.com> 25914 25915 testsuite, fortran: Fix regression due to fix for ifort's 'start' behavior 25916 Got a regression email due to merge of commit in CI config 25917 tcwg_gdb_check/master-aarch64 : 25918 https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec 25919 25920 Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above 25921 commit to start the test from running to line with tag "First Breakpoint" 25922 instead of "fortran_runto_main". Reason of the regression is shared 25923 libraries are still loaded after hitting the breakpoint as "nosharedlibrary" 25924 is already called before hitting the breakpoint. 25925 25926 So now after this change test is updated accordingly to disable and unload 25927 shared libraries symbols after hitting the first breakpoint. 25928 25929 Approved-By: Andrew Burgess <aburgess@redhat.com> 25930 259312023-09-11 Markus Metzger <markus.t.metzger@intel.com> 25932 25933 gdb: c++ify btrace_target_info 25934 Following the example of private_thread_info and private_inferior, turn 25935 struct btrace_target_info into a small class hierarchy. 25936 25937 Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into 25938 linux_btrace_target_info. 25939 25940 Fixes PR gdb/30751. 25941 259422023-09-11 Markus Metzger <markus.t.metzger@intel.com> 25943 25944 gdb, btrace: move xml parsing into remote.c 25945 The code is only used in remote.c and all functions can be declared static. 25946 259472023-09-11 Simon Marchi <simon.marchi@efficios.com> 25948 25949 gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs 25950 I see the following failure when running this test on an AMD machine: 25951 25952 p/x $fioff^M 25953 $24 = 0x0^M 25954 (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff 25955 25956 The register that GDB calls fioff normally contains the address of the 25957 last instruction executed by the x87 unit. It is available through the 25958 FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE 25959 area. You can read about it in the Intel manual [1] at section "10.5.1 25960 FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD 25961 manual [2] at section "11.4.4 Saving Media and x87 Execution Unit 25962 State". 25963 25964 The test therefore expects that after executing the FLD1 instruction, 25965 the fioff register contains the address of the FLD1 instruction. 25966 25967 However, the FXSAVE and XSAVE instructions (which the kernel uses to 25968 dump x87 register state which it provides GDB through ptrace) behave 25969 differently on AMD CPUs. In section "11.4.4.3 FXSAVE and FXRSTOR 25970 Instructions" of the AMD manual, we read: 25971 25972 The FXSAVE and FXRSTOR instructions save and restore the entire 25973 128-bit media, 64-bit media, and x87 state. These instructions 25974 usually execute faster than FSAVE/FNSAVE and FRSTOR because they do 25975 not normally save and restore the x87 exception pointers 25976 (last-instruction pointer, last data-operand pointer, and last 25977 opcode). The only case in which they do save the exception pointers 25978 is the relatively rare case in which the exception-summary bit in 25979 the x87 status word (FSW.ES) is set to 1, indicating that an 25980 unmasked exception has occurred. 25981 25982 So, unless a floating point exception happened and that exception is 25983 unmasked in the x87 FPU control register (which isn't by default on 25984 Linux, from what I saw), the "last instruction address" register (or 25985 fioff as GDB calls it) will always be 0 on an AMD CPU. 25986 25987 For this reason, I think it's fine to change the test to accept the 25988 value 0 - that's just how the processor works. 25989 25990 I toyed with the idea of changing the test program to make it so the CPU 25991 would generate a non-zero fioff. That is by unmasking an FPU exception 25992 and executing an instruction to raise that kind exception. It worked, 25993 but then I would have to change the test more extensively, and it didn't 25994 seem to be worth it. 25995 25996 [1] https://cdrdv2.intel.com/v1/dl/getContent/671200 25997 [2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf 25998 25999 Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b 26000 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 26001 260022023-09-11 GDB Administrator <gdbadmin@sourceware.org> 26003 26004 Automatic date update in version.in 26005 260062023-09-10 GDB Administrator <gdbadmin@sourceware.org> 26007 26008 Automatic date update in version.in 26009 260102023-09-09 GDB Administrator <gdbadmin@sourceware.org> 26011 26012 Automatic date update in version.in 26013 260142023-09-09 Jinyang He <hejinyang@loongson.cn> 26015 26016 Make sure DW_CFA_advance_loc4 is in the same frag 26017 Do the same as commit b9d8f5601bcf in another place generating 26018 DW_CFA_advance_loc4. The idea behind commit b9d8f5601bcf was that 26019 when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and 26020 eh_frame_convert_frag we want to remove the opcode entirely, not just 26021 convert to a nop. If the opcode was split over two frags then a size 26022 adjustment would need to be done to the first frag, not just the 26023 second as is correct for other cases with split frags. This would 26024 complicate the eh relaxation. It's easier to ensure the frag is not 26025 split. 26026 26027 * ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4 26028 to be placed in a different frag to the rs_cfa. 26029 260302023-09-08 Tom Tromey <tromey@adacore.com> 26031 26032 Run 'black' on recent test case 26033 The auto-builders pointed out that I neglected to run 'black' after a 26034 rest testcase change. This patch fixes the oversight. 26035 260362023-09-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 26037 26038 Set insn_type for branch instructions on aarch64 26039 gprofng uses insn_type in print_address_func(). 26040 But insn_type is always zero on aarch64. 26041 26042 opcodes/ChangeLog: 26043 2023-09-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 26044 26045 * opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for 26046 branch instructions. 26047 260482023-09-08 Simon Marchi <simon.marchi@efficios.com> 26049 26050 gdb/doc: describe x87 registers 26051 While investigating this [1], I initially had no idea what register 26052 "fioff" stood for, making it difficult to map it to something in the 26053 Intel or AMD manuals. Similarly, I can imaging someone familiar with 26054 x87 to want to print the "x87 last instruction address", and have no 26055 clue that GDB makes it available as register "fioff". The names of the 26056 x87 state fields don't seem to be standardized, they even change between 26057 sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area 26058 descriptions). 26059 26060 Add some details to the doc to help one map GDB register names to x87 26061 state fields. 26062 26063 [1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u 26064 26065 Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762 26066 Approved-By: Eli Zaretskii <eliz@gnu.org> 26067 Approved-By: Pedro Alves <pedro@palves.net> 26068 260692023-09-08 Simon Marchi <simon.marchi@efficios.com> 26070 26071 gdb/doc: rename "x86 Architecture-specific Issues" section to "x86" 26072 I'm looking to add some x86-specific information to the doc, but I find 26073 the naming of this section odd. It doesn't really talk about issues, it 26074 just gives generally useful information. Also, the sections about other 26075 architectures don't mention "issues", just the architecture name. 26076 26077 Also, at least in the HTML version of the doc, the name is inconsistent 26078 between the main table of content, where it appears as "x86 26079 Architecture-specific Issues", and the sub-table of contents of the 26080 "Architectures" section, where it appears as "i386". 26081 26082 Rename the section to just "x86". 26083 26084 Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca 26085 Approved-By: Eli Zaretskii <eliz@gnu.org> 26086 260872023-09-08 Richard Sandiford <richard.sandiford@arm.com> 26088 26089 aarch64: Remove unused function 26090 set_expected_error is no longer used. It has been replaced by 26091 more specific error messages. 26092 260932023-09-08 Tom de Vries <tdevries@suse.de> 26094 26095 [gdb/testsuite] Make gdb.dwarf2/dwzbuildid.exp more robust 26096 I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index, 26097 and noticed that compilation failure for one exec prohibited testing of all 26098 execs. 26099 26100 Fix this by restructuring the test-case, such that we have: 26101 ... 26102 PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory 26103 PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int 26104 UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed 26105 UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed 26106 ... 26107 26108 Tested on x86_64-linux. 26109 261102023-09-08 Tom de Vries <tdevries@suse.de> 26111 26112 [gdb/testsuite] Add kfail in gdb.dwarf2/dwzbuildid.exp 26113 When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I 26114 get: 26115 ... 26116 (gdb) file dwzbuildid-mismatch^M 26117 Reading symbols from dwzbuildid-mismatch...^M 26118 warning: File "dwzbuildid5.o" has a different build-id, file skipped^M 26119 could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M 26120 (gdb) delete breakpoints^M 26121 (gdb) info breakpoints^M 26122 No breakpoints or watchpoints.^M 26123 (gdb) break -qualified main^M 26124 No symbol table is loaded. Use the "file" command.^M 26125 Make breakpoint pending on future shared library load? (y or [n]) n^M 26126 (gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main 26127 ... 26128 26129 This is PR symtab/26797: when using readnow, a failure in reading the dwarf 26130 results in the minimal symbols not being available. 26131 26132 Add a corresponding KFAIL. 26133 26134 Tested on x86_64-linux. 26135 261362023-09-08 Tom de Vries <tdevries@suse.de> 26137 26138 [gdb/testsuite] Add aranges in gdb.dwarf2/dwzbuildid.exp 26139 While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran 26140 into a warning: 26141 ... 26142 $ readelf -w dwzbuildid-ok > READELF 26143 readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not 26144 point to a CU header. 26145 ... 26146 26147 AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that. 26148 26149 While looking at the .debug_aranges section, I noticed that the entries for 26150 the CUs generated by the dwarf assembler are missing. 26151 26152 Fix this by adding the missing .debug_aranges entries. 26153 26154 Tested on x86_64-linux. 26155 261562023-09-08 Tom de Vries <tdevries@suse.de> 26157 26158 [gdb/testsuite] Fix build-ids in gdb.dwarf2/dwzbuildid.exp 26159 When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using 26160 readelf, I run into: 26161 ... 26162 $ readelf -w dwzbuildid-ok > READELF 26163 readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink 26164 readelf: Warning: Build-ID is too short (0x6 bytes) 26165 ... 26166 26167 Fix this by ensuring the Build-IDs are the required 20 bytes. 26168 26169 Tested on x86_64-linux. 26170 261712023-09-08 Andrew Burgess <aburgess@redhat.com> 26172 26173 gdb/testsuite: fix gdb.mi/mi-condbreak-throw.exp failure 26174 In commit: 26175 26176 commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae 26177 Date: Tue Aug 8 10:45:20 2023 +0100 26178 26179 gdb: MI stopped events when unwindonsignal is on 26180 26181 a new test, gdb.mi/mi-condbreak-throw.exp, was added. Unfortunately, 26182 this test would fail when using the native-gdbserver board (and other 26183 similar boards). 26184 26185 The problem was that one of the expected output patterns included some 26186 output from the inferior. When using the native-gdbserver board, this 26187 output is not printed to GDB's tty, but is instead printed to 26188 gdbserver's tty, the result is that the expected output no longer 26189 matches, and the test fails. 26190 26191 Additionally, as the output is actually from the C++ runtime, rather 26192 than the test's source file, changes to the C++ runtime could cause 26193 the output to change. 26194 26195 To solve both of these issues, in this commit, I'm removing the 26196 reference to the inferior's output, and replacing it with '.*', which 26197 will skip the output if it is present, but is equally happy if the 26198 output is not present. 26199 26200 After this commit gdb.mi/mi-condbreak-throw.exp now passes on all 26201 boards, including native-gdbserver. 26202 262032023-09-08 Jan Beulich <jbeulich@suse.com> 26204 26205 x86: restrict prefix use with .insn VEX/XOP/EVEX 26206 Avoid triggering the respective abort() in output_insn(). 26207 262082023-09-08 Simon Marchi <simon.marchi@efficios.com> 26209 26210 gdb: remove interp_supports_command_editing 26211 It is a trivial wrapper around the supports_command_editing method, 26212 remove it. 26213 26214 Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7 26215 Approved-By: Tom Tromey <tom@tromey.com> 26216 262172023-09-08 Simon Marchi <simon.marchi@efficios.com> 26218 26219 gdb: remove interp_pre_command_loop 26220 It is a trivial wrapper around the pre_command_loop method, remove it. 26221 26222 Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4 26223 Approved-By: Tom Tromey <tom@tromey.com> 26224 262252023-09-08 GDB Administrator <gdbadmin@sourceware.org> 26226 26227 Automatic date update in version.in 26228 262292023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com> 26230 26231 testsuite, fortran: make kfail gfortran specific 26232 The modified test in function-calls.exp actually passes with ifort and 26233 ifx. The particular fail seems to be specific to gfortran. When the 26234 test was introduced it was only tested with gfortran (actually the 26235 whole patch was written with gfortran and the GNU Fortran argument 26236 passing convention in mind). 26237 26238 Approved-by: Tom Tromey <tom@tromey.com> 26239 262402023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com> 26241 26242 testsuite, fortran: adapt tests for ifort's 'start' behavior 26243 The modified tests array-slices-bad.exp and vla-type.exp both set a 26244 breakpoint at the first real statement in the respective executables. 26245 26246 Normally, the expected behavior of fortran_runto_main for these would be 26247 the stopping of the debugger at exactly the first statment in the code. 26248 26249 Strangely, neither gfortran nor ifx seem to do this for these tests. 26250 Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB 26251 stop at the 'program ...' line and gfortran stops at a variable 26252 declaration line. E.g. for vla-type it stops at 26253 26254 41 type(five) :: fivearr (2) 26255 26256 So, actually, ifort's behavior can be considered to be a bit more 26257 'correct' here. This patch remove the fortran_runto_main in the 26258 two tests and instead uses runto to directly run to the first breakpoint 26259 set at the first program statement. This works with both compiler 26260 behaviors and makes the tests more robust. 26261 26262 Approved-by: Kevin Buettner <kevinb@redhat.com> 26263 262642023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com> 26265 26266 testsuite, fortran: Remove self assignment non-statements 26267 There were a couple of places in the testsuite where instructions like 26268 26269 var = var 26270 26271 were written in the source code of tests. These were usually dummy 26272 statements meant to generate a line table entry at that line on which 26273 to break later on. 26274 26275 This worked fine for gfortran and ifx, but it seems that, when compiled 26276 with ifort (2021.6.0) these statements do not actually create any 26277 assmbler instructions and especially no line table entries. Consider 26278 the program 26279 26280 program test 26281 Integer var :: var = 1 26282 var = var 26283 end program 26284 26285 compiled with gfortran (13.0.0, -O0 -g). The linetable as emitted by 26286 'objdump --dwarf=decodedline ./a.out' looks like 26287 26288 test.f90: 26289 File name Line number Starting address View Stmt 26290 test.f90 1 0x401172 x 26291 test.f90 3 0x401176 x 26292 test.f90 4 0x401182 x 26293 test.f90 4 0x401185 x 26294 test.f90 4 0x401194 x 26295 test.f90 - 0x4011c0 26296 26297 actually containing line table info for line 3. Running gdb, breaking 26298 at 3 and checking the assembly we see 26299 26300 0x0000000000401172 <+0>: push %rbp 26301 0x0000000000401173 <+1>: mov %rsp,%rbp 26302 => 0x0000000000401176 <+4>: mov 0x2ebc(%rip),%eax # 0x404038 <var.1> 26303 0x000000000040117c <+10>: mov %eax,0x2eb6(%rip) # 0x404038 <var.1> 26304 0x0000000000401182 <+16>: nop 26305 0x0000000000401183 <+17>: pop %rbp 26306 0x0000000000401184 <+18>: ret 26307 26308 so two mov instructions are being issued for this assignment one copying 26309 the value into a register and one writing it back to the same memory. 26310 Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here 26311 and also has no line table entry: 26312 26313 test.f90: 26314 File name Line number Starting address View Stmt 26315 test.f90 1 0x4040f8 x 26316 test.f90 4 0x404109 x 26317 test.f90 4 0x40410e x 26318 test.f90 - 0x404110 26319 26320 As I do not think that this is really a bug (on either side, gfortran/ifx or 26321 ifort), and as I don't think this behavior is covered in the Fortran 26322 standard, I changed these lines to become actual value assignments. 26323 26324 This removes a few FAILs in the testsuite when ran with ifort. 26325 26326 Approved-by: Tom Tromey <tom@tromey.com> 26327 263282023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com> 26329 26330 testsuite, fortran: make mixed-lang-stack less compiler dependent 26331 In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a 26332 bunch of nested function calls we issue and test a 'info args' command 26333 for the mixed_func_1b function (when in that function's frame). 26334 26335 The signature of the function looks like 26336 26337 subroutine mixed_func_1b(a, b, c, d, e, g) 26338 use type_module 26339 implicit none 26340 26341 integer :: a 26342 real(kind=4) :: b 26343 real(kind=8) :: c 26344 complex(kind=4) :: d 26345 character(len=*) :: e 26346 character(len=:), allocatable :: f 26347 TYPE(MyType) :: g 26348 26349 and usually one would expect arguments a, b, c, d, e, and g to be 26350 emitted here. However, due to some compiler dependent treatment of the 26351 e array the actual output in the test (with gfortran/ifx) is 26352 26353 (gdb) info args 26354 a = 1 26355 b = 2 26356 c = 3 26357 d = (4,5) 26358 e = 'abcdef' 26359 g = ( a = 1.5, b = 2.5 ) 26360 _e = 6 26361 26362 where the compiler generated '_e' is emitted as the length of e. While 26363 ifort also generates an additional length argument, the naming (which is 26364 up to the compilers here I think, I could not find anything in the 26365 Fortran standard about this) is different and we see 26366 26367 (gdb) info args 26368 a = 1 26369 b = 2 26370 c = 3 26371 d = (4,5) 26372 e = 'abcdef' 26373 g = ( a = 1.5, b = 2.5 ) 26374 .tmp.E.len_V$4a = 6 26375 26376 To make both outputs pass the test, I kept the additional argument for now and 26377 made the regex for the emitted name of the last variable match any 26378 arbitrary name. 26379 26380 Approved-by: Tom Tromey <tom@tromey.com> 26381 263822023-09-07 Ijaz, Abdul B <abdul.b.ijaz@intel.com> 26383 26384 gdb: add Abdul Basit Ijaz to gdb/MAINTAINERS 26385 263862023-09-07 Paul Iannetta <piannetta@kalrayinc.com> 26387 26388 kvx: Add a testcase for bundles with KVXMAXBUNDLEWORDS syllables 26389 * testsuite/gas/kvx/fat-bundles.s: New test. 26390 * testsuite/gas/kvx/kv3-1-fat-bundles.d: New test. 26391 * testsuite/gas/kvx/kv3-2-fat-bundles.d: New test. 26392 263932023-09-07 Alan Modra <amodra@gmail.com> 26394 26395 PR30793, kvx_reassemble_bundle index 8 out of bounds 26396 While the patch already committed for pr30793 prevents the asan error, 26397 there is a problem: Now the last element of bundle_words never gets 26398 written. That's very likely wrong, or KVXMAXBUNDLEWORDS is too big. 26399 So this patch rearranges things a little to support writing of all of 26400 bundle_words and does the parallel bit checking only when filling 26401 bundle_words. In the normal case, kvx_reassemble_bundle will see 26402 bundle_words[word_count-1] with the parallel bit clear and all other 26403 words having it set. In the error case where all words in 26404 bundle_words have the parallel bit set, kvx_reassemble_bundle will be 26405 passed a wordcount of KVXMAXBUNDLEWORDS + 1. I've also made 26406 kvx_reassemble_bundle return true for success rather than zero, and 26407 removed the unnecessary check for zero wordcount. 26408 26409 PR 30793 26410 * kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success. 26411 Fail if wordcount is too large. Don't check for wordcount zero. 26412 Don't check kvx_has_parallel_bit. 26413 (print_insn_kvx): Rewrite code reading bundle_words as a for loop. 26414 Don't stop reading at KVXMAXBUNDLEWORDS - 1. 26415 (decode_prologue_epilogue_bundle): Similarly. 26416 264172023-09-07 Tom Tromey <tromey@adacore.com> 26418 26419 Fix bug in -var-evaluate-expression 26420 This bug points out that if one uses -var-set-visualizer with "None" 26421 -- to disable a pretty-printer for a varobj -- then 26422 -var-evaluate-expression will still use pretty-printing. 26423 26424 This is a combination of bugs. First, setting the visualizer does not 26425 update the display text; and second, computing the display text should 26426 use "raw" when Python is available but no visualizer is desired. 26427 26428 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738 26429 Reviewed-by: Keith Seitz <keiths@redhat.com> 26430 264312023-09-07 Tom Tromey <tromey@adacore.com> 26432 26433 Remove variable_default_display 26434 variable_default_display has a single caller now, so remove it. 26435 26436 Reviewed-by: Keith Seitz <keiths@redhat.com> 26437 264382023-09-07 Tom Tromey <tromey@adacore.com> 26439 26440 Remove dead code from varobj_set_display_format 26441 varobj_set_display_format takes an enum and exhaustively switches on 26442 the values -- but also has a default. This default case is dead code. 26443 26444 Reviewed-by: Keith Seitz <keiths@redhat.com> 26445 264462023-09-07 Tom Tromey <tromey@adacore.com> 26447 26448 Allow pretty-printer 'children' method to return strings 26449 A user noticed that, while a pretty-printer can return Python strings 26450 from its "children" method, this does not really work for MI. I 26451 tracked this down to my_value_of_variable calling into 26452 c_value_of_variable, which specially handles arrays and structures -- 26453 not using the actual contents of the string. 26454 26455 Now, this part of MI seems bad to me, but rather than change that, 26456 this applies the fix to only dynamic varobjs, which is the only 26457 scenario where a string like this can really be returned. 26458 26459 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282 26460 Reviewed-by: Keith Seitz <keiths@redhat.com> 26461 264622023-09-07 Tom de Vries <tdevries@suse.de> 26463 26464 [gdb/symtab] Fix gdb-index writing for .debug_types 26465 With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run 26466 into: 26467 ... 26468 (gdb) print red^M 26469 No definition of "red" in current context.^M 26470 (gdb) FAIL: gdb.ada/same_enum.exp: print red 26471 ... 26472 26473 [ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"), 26474 so this is broken in gdb 12 and 13. ] 26475 26476 The easiest way to see what's going wrong is with readelf. We have in section 26477 .gdb_index: 26478 ... 26479 [7194] pck__red: 26480 2 [static, variable] 26481 3 [static, variable] 26482 ... 26483 which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but 26484 should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and 26485 "T3"). 26486 26487 Fix this by removing the counter / types_counter distinction in 26488 write_gdbindex, such that we get the expected: 26489 ... 26490 [7194] pck__red: 26491 T2 [static, variable] 26492 T3 [static, variable] 26493 ... 26494 26495 [ While reading write_gdbindex I noticed a few oddities related to dwz 26496 handling, I've filed PR30829 about this. ] 26497 26498 Tested on x86_64-linux. 26499 26500 Approved-By: Tom Tromey <tom@tromey.com> 26501 26502 PR symtab/30827 26503 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827 26504 265052023-09-07 Tom de Vries <tdevries@suse.de> 26506 26507 [gdb/ada] Extend type equivalence test in ada_resolve_enum 26508 When running test-case gdb.ada/local-enum.exp with target board debug-types, I 26509 run into: 26510 ... 26511 (gdb) print v1(three)^M 26512 No name 'three' in enumeration type 'local__e1'^M 26513 (gdb) FAIL: gdb.ada/local-enum.exp: print v1 element 26514 ... 26515 26516 The array V1 is of type A1 which is an array with index type E1, containing 26517 "three" as enumerator: 26518 ... 26519 type E1 is (one, two, three); 26520 type A1 is array (E1) of Integer; 26521 V1 : A1 := (0, 1, 2); 26522 ... 26523 26524 There's also a type E2 that contains three as enumerator: 26525 ... 26526 type E2 is (three, four, five); 26527 ... 26528 26529 When doing "print v1(three)", it's the job of ada_resolve_enum to resolve 26530 "three" to type E1 rather than type E2. 26531 26532 When using target board debug-types, the enums E1 and E2 are replicated in the 26533 .debug_types section, and consequently in ada_resolve_enum the type 26534 equivalence check using a pointer comparison fails: 26535 ... 26536 for (int i = 0; i < syms.size (); ++i) 26537 { 26538 /* We already know the name matches, so we're just looking for 26539 an element of the correct enum type. */ 26540 if (ada_check_typedef (syms[i].symbol->type ()) == context_type) 26541 return i; 26542 } 26543 ... 26544 26545 Fix this by also trying a structural comparison using 26546 ada_identical_enum_types_p. 26547 26548 Tested on x86_64-linux. 26549 26550 Approved-By: Tom Tromey <tom@tromey.com> 26551 26552 PR ada/29335 26553 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335 26554 265552023-09-07 Tom de Vries <tdevries@suse.de> 26556 26557 [gdb/ada] Move identical enums handling later 26558 When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board 26559 cc-with-dwz, I run into: 26560 ... 26561 (gdb) print enum_with_gaps'enum_rep(lit3)^M 26562 'Enum_Rep requires argument to have same type as enum^M 26563 (gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep 26564 ... 26565 26566 With target_board unix, we have instead: 26567 ... 26568 (gdb) print enum_with_gaps'enum_rep(lit3)^M 26569 $16 = 13^M 26570 (gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep 26571 ... 26572 26573 Conversely, when I add this test to the test-case: 26574 ... 26575 gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \ 26576 "enum_rep" 26577 + gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \ 26578 + "other enum_rep" 26579 ... 26580 the extra test passes with target board cc-with-dwz, but fails with target 26581 board unix. 26582 26583 The problem is here in remove_extra_symbols: 26584 ... 26585 if (symbols_are_identical_enums (syms)) 26586 syms.resize (1); 26587 ... 26588 where one of the two identical enums is picked before the enum_rep handling 26589 can resolve lit3 to one of the two. 26590 26591 Fix this by moving the code to ada_resolve_variable. 26592 26593 Tested on x86_64-linux. 26594 26595 Approved-By: Tom Tromey <tom@tromey.com> 26596 26597 PR ada/30726 26598 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726 26599 266002023-09-07 Tom Tromey <tom@tromey.com> 26601 26602 Simplify block_find_symbol 26603 block_find_symbol takes a callback function, but only two callbacks 26604 are ever passed to it -- and they are similar enough that it seems 26605 cleaner to just have block_find_symbol do the work itself. Also, 26606 block_find_symbol can take a lookup_name_info as an argument, 26607 following the general idea of pushing the construction of these 26608 objects as high in the call chain as feasible. 26609 26610 Regression tested on x86-64 Fedora 38. 26611 26612 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 26613 266142023-09-07 Simon Marchi <simon.marchi@efficios.com> 26615 26616 gdb/mi: make current_token a field of mi_interp 26617 Following the commit f818c32ba459 ("gdb/mi: fix ^running record with 26618 multiple MI interpreters"), I thought it would make sense to make 26619 current_token a field of mi_interp. This variable contains the token of 26620 the currently handled MI command, like the 222 in: 26621 26622 222-exec-continue 26623 26624 I didn't find any bug related to that, it's just a "that seems nicer" 26625 cleanup, since the current token is a fundamentally per-interp thing. 26626 26627 mi_execute_command needs a check similar to what we already have in 26628 mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current 26629 interpreter is not an mi_interp. When using the Python gdb.execute_mi 26630 function, there is no such concept of token, so we can just skip that. 26631 26632 There should be no user-visible change. 26633 26634 Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad 26635 Approved-By: Tom Tromey <tom@tromey.com> 26636 266372023-09-07 Simon Marchi <simon.marchi@efficios.com> 26638 26639 gdb: fix indentation in mi/mi-parse.h 26640 Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8 26641 266422023-09-07 cailulu <cailulu@loongson.cn> 26643 26644 Add testcase for generation of 32/64_PCREL. 26645 266462023-09-07 cailulu <cailulu@loongson.cn> 26647 26648 Use 32/64_PCREL to replace a pair of ADD32/64 and SUB32/64. 26649 Subtraction for labels that require static relocation 26650 usually generates ADD32/64 and SUB32/64. 26651 26652 If subsy of BFD_RELOC_32/64 and PC in same segment, 26653 and disable relax or PC at start of subsy or enable 26654 relax but not in SEC_CODE, we generate 32/64_PCREL 26655 to replace a pair of ADD32/64 and SUB32/64. 26656 266572023-09-07 Nelson Chu <nelson@rivosinc.com> 26658 26659 RISC-V: Clarify the naming rules of vendor operands. 26660 The vendor operands should be named starting with `X', and preferably the 26661 second letter (or multiple following letters) is enough to differentiate 26662 them from other vendors. 26663 26664 Therefore, added letter `t' after `X' for t-head operands, to differentiate 26665 from future different vendor's operands. 26666 26667 bfd/ 26668 * elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor 26669 document link since it should already be recorded in the 26670 gas/doc/c-riscv.texi. 26671 gas/ 26672 * config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for 26673 t-head operands. Minor updates for indents and comments. 26674 (riscv_ip): Likewise. 26675 * doc/c-riscv.texi: Minor updates. 26676 opcodes/ 26677 * riscv-dis.c (print_insn_args): Added `t' after `X' for t-head 26678 operands. Minor updates for indents and comments. 26679 * riscv-opc.c (riscv_opcode): Likewise. 26680 266812023-09-07 Roland McGrath <mcgrathr@google.com> 26682 26683 gold: Use char16_t, char32_t instead of uint16_t, uint32_t as character types 26684 The std::basic_string template type is only specified for 26685 instantiations using character types. Newer (LLVM) libc++ 26686 implementations no longer allow non-character integer types 26687 to be used. 26688 26689 gold/ 26690 * output.cc: Include <uchar.h>. 26691 (Output_section::add_merge_input_section): Use char16_t and 26692 char32_t for 2- and 4-byte entry size, respectively. 26693 * stringpool.cc: Include <uchar.h>. 26694 (Stringpool_template): Explicitly instantiate for char16_t, 26695 char32_t instead of uint16_t, uint32_t. 26696 * merge.cc (Output_merge_string): Likewise. 26697 266982023-09-07 GDB Administrator <gdbadmin@sourceware.org> 26699 26700 Automatic date update in version.in 26701 267022023-09-07 Alan Modra <amodra@gmail.com> 26703 26704 PR30828, notes obstack memory corruption 26705 Commit 3bab069c29b3 carelessly allowed "string" to be released from 26706 the notes obstack twice, with the second call to obstack_free 26707 releasing memory for a fixup that just happened to be the same size as 26708 the original string. The fixup then of course was overwritten. 26709 This patch fixes that problem, and another that could occur on an 26710 error path. 26711 26712 PR 30828 26713 * stabs.c (s_stab_generic): Don't free string twice. Don't 26714 blow away entire notes obstack on a missing string. 26715 267162023-09-06 Tom de Vries <tdevries@suse.de> 26717 26718 [gdb/testsuite] Fix gdb.ada/same_enum.exp 26719 Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this 26720 bit of code in remove_extra_symbols: 26721 ... 26722 if (symbols_are_identical_enums (syms)) 26723 syms.resize (1); 26724 ... 26725 26726 The test-case does "print red" and expects one of these two choices to be 26727 picked by remove_extra_symbols: 26728 ... 26729 type Color is (Black, Red, Green, Blue, White); 26730 type RGB_Color is new Color range Red .. Blue; 26731 ... 26732 but because only the type Color is used: 26733 ... 26734 FC : Color := Red; 26735 SC : Color := Green; 26736 ... 26737 the RGB_Color type is eliminated from the debug info, and consequently 26738 remove_extra_symbols has no effect for the test-case. 26739 26740 In other words, we have: 26741 ... 26742 (gdb) ptype Color ^M 26743 type = (black, red, green, blue, white)^M 26744 (gdb) ptype RGB_Color^M 26745 No definition of "rgb_color" in current context.^M 26746 ... 26747 26748 Fix this by changing the type of SC to RGB_Color, and add prints of the two 26749 types to check that they're both available. 26750 26751 With the test-case fixed, if we disable the bit of code in 26752 remove_extra_symbols we get: 26753 ... 26754 (gdb) print red^M 26755 Multiple matches for red^M 26756 [0] cancel^M 26757 [1] pck.color'(pck.red) (enumeral)^M 26758 [2] pck.rgb_colorB'(pck.red) (enumeral)^M 26759 > FAIL: gdb.ada/same_enum.exp: print red (timeout) 26760 ... 26761 in other words, the test-case now properly functions as a regression test. 26762 26763 Tested on x86_64-linux. 26764 267652023-09-06 Tom de Vries <tdevries@suse.de> 26766 26767 [gdb/symtab] Fix too many symbols in gdbpy_lookup_static_symbols 26768 When running test-case gdb.python/py-symbol.exp with target board 26769 cc-with-dwz-m, we run into: 26770 ... 26771 (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 26772 4^M 26773 (gdb) FAIL: gdb.python/py-symbol.exp: \ 26774 print (len (gdb.lookup_static_symbols ('rr'))) 26775 ... 26776 while with target board unix we have instead: 26777 ... 26778 (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 26779 2^M 26780 (gdb) PASS: gdb.python/py-symbol.exp: \ 26781 print (len (gdb.lookup_static_symbols ('rr'))) 26782 ... 26783 26784 The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits 26785 representing both CUs and PUs: 26786 ... 26787 for (compunit_symtab *cust : objfile->compunits ()) 26788 ... 26789 26790 When doing a lookup on a PU, the user link is followed until we end up at a CU, 26791 and the lookup is done in that CU. 26792 26793 In other words, when doing a lookup in the loop for a PU we duplicate the 26794 lookup for a CU that is already handled by the loop. 26795 26796 Fix this by skipping PUs in the loop in gdb.lookup_static_symbols. 26797 26798 Tested on x86_64-linux. 26799 26800 PR symtab/25261 26801 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261 26802 268032023-09-06 Tom de Vries <tdevries@suse.de> 26804 26805 [gdb/symtab] Handle PU in iterate_over_some_symtabs 26806 When running test-case gdb.base/setshow.exp with target board cc-with-dwz I 26807 run into: 26808 ... 26809 (gdb) info line 1^M 26810 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M 26811 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M 26812 (gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1 26813 ... 26814 while the expected output is: 26815 ... 26816 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code. 26817 ��setshow.c:1:0:beg:0x400527 26818 ... 26819 26820 The second line of the expected output is missing due to the first line of the 26821 expected output being repeated, so the problem is that the "Line 1" line is 26822 printed twice. 26823 26824 This happens because the PU imported by the CU reuses the filetab of the CU, 26825 and both the CU and PU are visited by iterate_over_some_symtabs. 26826 26827 Fix this by skipping PUs in iterate_over_some_symtabs. 26828 26829 Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m. 26830 26831 Approved-By: Tom Tromey <tom@tromey.com> 26832 26833 PR symtab/30797 26834 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797 26835 268362023-09-06 Hans-Peter Nilsson <hp@axis.com> 26837 26838 src-release.sh (SIM_SUPPORT_DIRS): Add libsframe, libctf/swap.h and gnulib 26839 Without this, a simulator build breaks when building from a tarball 26840 made by "./src-release.sh -b sim", when building e.g. bfd and 26841 libsframe. See also previous similar commits for GDB_SUPPORT_DIRS. 26842 26843 The libctf library does not needed to be built, but building 26844 libsframe requires libctf/swap.h, with no dependencies on built or 26845 configured contents. Do as for the single gdb files and include 26846 explicitly only that file. 26847 268482023-09-06 GDB Administrator <gdbadmin@sourceware.org> 26849 26850 Automatic date update in version.in 26851 268522023-09-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 26853 26854 Fix 30808 gprofng tests failed 26855 In gprofng testing, we need a tempory gprofng installation to resolve run-time 26856 dependencies on libraries (libgprofng, libopcodes, libbfd, etc). 26857 We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and 26858 configuration file. These variables must be set for all gprofng tests. 26859 26860 Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>. 26861 26862 gprofng/ChangeLog 26863 2023-08-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 26864 26865 PR gprofng/30808 26866 * testsuite/config/default.exp: Make a temporary install dir. 26867 Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR. 26868 * testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and 26869 GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp. 26870 268712023-09-05 Sandra Loosemore <sandra@codesourcery.com> 26872 26873 gdb/testsuite: Make hook-stop.exp ignore termination message from GDB stub 26874 When a GDB stub is run via "target remote |", it sometimes produces 26875 extra output that ends up mixed with GDB's own output. For example, 26876 QEMU's built-in GDB stub responds to the vKill packet by printing 26877 26878 nios2-elf-qemu-system: QEMU: Terminated via GDBstub 26879 26880 before exiting. 26881 26882 This patch fixes the regexp in gdb.base/hook-stop.exp to allow such 26883 messages between GDB's "continuing" and "Inferior killed" messages. 26884 26885 Reviewed-By: Tom Tromey <tom@tromey.com> 26886 Approved-By: Tom Tromey <tom@tromey.com> 26887 268882023-09-05 Sandra Loosemore <sandra@codesourcery.com> 26889 26890 gdb/testsuite: Disable some tests that are broken on remote Windows host 26891 These testcases assume host==build or that the remote host has a Posix 26892 shell to run commands in. Don't try to run them if that's not the case. 26893 26894 Reviewed-By: Tom Tromey <tom@tromey.com> 26895 Approved-By: Tom Tromey <tom@tromey.com> 26896 268972023-09-05 Sandra Loosemore <sandra@codesourcery.com> 26898 26899 gdb/testsuite: Adjust some testcases to allow Windows pathnames 26900 This patch fixes some testcases that formerly had patterns with 26901 hardwired "/" pathname separators in them, which broke when testing on 26902 (remote) Windows host. 26903 26904 Reviewed-By: Tom Tromey <tom@tromey.com> 26905 Approved-By: Tom Tromey <tom@tromey.com> 26906 269072023-09-05 Sandra Loosemore <sandra@codesourcery.com> 26908 26909 gdb/testsuite: Fix style.exp failures on targets without argc/argv support 26910 Some embedded targets don't have full support for argc/argv. argv 26911 may print as "0x0" or as an address with a symbol name following. 26912 This causes problems for the regexps in the style.exp line-wrapping 26913 tests that assume it always prints as an ordinary address in backtrace 26914 output. 26915 26916 This patch generalizes the regexps to handle these additional forms 26917 and reworks some of the line-wrapping tests to account for the argv 26918 address string being shorter or longer than a regular address. 26919 26920 Reviewed-By: Tom Tromey <tom@tromey.com> 26921 Approved-By: Tom Tromey <tom@tromey.com> 26922 269232023-09-05 Tom Tromey <tromey@adacore.com> 26924 26925 Handle array- and string-like values in no-op pretty printers 26926 This changes the no-op pretty printers -- used by DAP -- to handle 26927 array- and string-like objects known by the gdb core. Two new tests 26928 are added, one for Ada and one for Rust. 26929 269302023-09-05 Tom Tromey <tromey@adacore.com> 26931 26932 Add new Python APIs to support DAP value display 26933 gdb's language code may know how to display values specially. For 26934 example, the Rust code understands that &str is a string-like type, or 26935 Ada knows how to handle unconstrained arrays. This knowledge is 26936 exposed via val-print, and via varobj -- but currently not via DAP. 26937 26938 This patch adds some support code to let DAP also handle these cases, 26939 though in a somewhat more generic way. 26940 26941 Type.is_array_like and Value.to_array are added to make Python aware 26942 of the cases where gdb knows that a structure type is really 26943 "array-like". 26944 26945 Type.is_string_like is added to make Python aware of cases where gdb's 26946 language code knows that a type is string-like. 26947 26948 Unlike Value.string, these cases are handled by the type's language, 26949 rather than the current language. 26950 26951 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 26952 269532023-09-05 Tom Tromey <tromey@adacore.com> 26954 26955 Select frame when fetching a frame variable in DAP 26956 Right now, if a program uses multiple languages, DAP value formatting 26957 will always use the language of the innermost frame. However, it is 26958 better to use the variable's defining frame instead. This patch does 26959 this by selecting the frame first. 26960 26961 This also fixes a possibly latent bug in the "stepOut" command -- 26962 "finish" is sensitive to the selected frame, but the DAP code may 26963 already select other frames when convenient. The DAP stepOut request 26964 only works on the newest frame, so be sure to select it before 26965 invoking "finish". 26966 269672023-09-05 Tom Tromey <tromey@adacore.com> 26968 26969 Introduce type::is_array_like and value_to_array 26970 This adds the type::is_array_like method and the value_to_array 26971 function. 26972 26973 The former can be used to see whether a given type is known to be 26974 "array-like". This is the currently the case for certain 26975 compiler-generated structure types; in particular both the Ada and 26976 Rust compilers do this. 26977 269782023-09-05 Tom Tromey <tromey@adacore.com> 26979 26980 Use ada_value_subscript in valpy_getitem 26981 Ada has a few complexities when it comes to array handling. Currently 26982 these are all handled in Ada-specific code -- but unfortunately that 26983 means they aren't really accessible to Python. 26984 26985 This patch changes the Python code to defer to Ada when given an Ada 26986 array. In order to make this work, one spot in ada-lang.c had to be 26987 updated to set the "GNAT-specific" flag on an array type. 26988 26989 The test case for this will come in a later patch. 26990 269912023-09-05 Tom Tromey <tromey@adacore.com> 26992 26993 Introduce TYPE_SPECIFIC_RUST_STUFF 26994 This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes 26995 the DWARF reader to set this on Rust types. This will be used as a 26996 flag in a later patch. 26997 26998 Note that the size of the type_specific_field bitfield had to be 26999 increased. I checked that this did not impact the size of main_type. 27000 270012023-09-05 Tom Tromey <tromey@adacore.com> 27002 27003 Refactor Rust code for slice-to-array operation 27004 This patch exposes rust_slice_type_p and introduces 27005 rust_slice_to_array, in preparation for subsequent patches that will 27006 need these. 27007 27008 Move rust_language::lookup_symbol_nonlocal 27009 This moves rust_language::lookup_symbol_nonlocal to rust-lang.c. 27010 There's no need to have it in rust-lang.h and moving it lets us avoid 27011 adding new includes in a later patch. 27012 270132023-09-05 Ciaran Woodward <ciaranwoodward@xmos.com> 27014 27015 gdb/riscv: Fix oob memory access when printing info registers 27016 If the length of a register name was greater than 15, 27017 print_spaces was called with a negative number, which 27018 prints random data from the heap instead of the requested 27019 number of spaces. 27020 27021 This could happen if a target-description file was used 27022 to specify additional long-named registers. 27023 27024 Fix is simple - don't ask for fewer than 1 space (since 27025 we still want column separation). 27026 27027 Approved-by: Kevin Buettner <kevinb@redhat.com> 27028 270292023-09-05 Tom Tromey <tromey@adacore.com> 27030 27031 Read Ada main name from executable, not inferior 27032 An upstream bug report points out this bug: if the user switches from 27033 one Ada executable to another without "kill"ing the inferior, then the 27034 "start" command will fail. 27035 27036 What happens here is that the Ada "main" name is found in a constant 27037 string in the executable. But, if the inferior is running, then the 27038 process_stratum target reads from the inferior memory. 27039 27040 This patch fixes the problem by changing the main name code to set 27041 trust-readonly-sections, causing the target stack to read from the 27042 executable instead. 27043 27044 I looked briefly at changing GNAT to emit DW_AT_main_subprogram 27045 instead, but this looks to be pretty involved. 27046 27047 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811 27048 270492023-09-05 Tom Tromey <tromey@adacore.com> 27050 27051 Avoid crash with Ada and -fdata-sections 27052 A user noticed that gdb would crash when showing a backtrace. 27053 Investigation showed this to be a crash in the DWARF reader when 27054 handling a "pragma export" symbol. The bug here is that earlier code 27055 decides to eliminate the symbol, but the export code tries to add it 27056 anyway -- but to a NULL list. 27057 270582023-09-05 Nick Clifton <nickc@redhat.com> 27059 27060 readelf: Add option to display the names of sections referenced by symbols. 27061 PR 30684 27062 * readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function. Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function. 27063 * doc/binutils.texi: Document the new option. 27064 * NEWS: Mention the new feature. 27065 270662023-09-05 Jan Beulich <jbeulich@suse.com> 27067 27068 RISC-V: fold duplicate code in vector_macro() 27069 There's no need to have almost identical code twice. Do away with 27070 M_VMSGEU and instead simply use an unused (for these macros) field to 27071 tell apart both variants. 27072 270732023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com> 27074 27075 RISC-V: Add stub support for the 'Svadu' extension 27076 This commit implements support for 'Svadu' extension. Because it does not 27077 add any instructions or CSRs (but adds bits to existing CSRs), this commit 27078 only adds extension name support and implication to the 'Zicsr' extension. 27079 27080 This is based on the "Hardware Updating of PTE A/D Bits (Svadu)" 27081 specification, version 1.0-rc1 (Frozen): 27082 <https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1> 27083 27084 bfd/ChangeLog: 27085 27086 * elfxx-riscv.c (riscv_implicit_subsets): Add implication from 27087 'Svadu' to 'Zicsr'. (riscv_supported_std_s_ext) Add 'Svadu'. 27088 270892023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com> 27090 27091 RISC-V: Fix typo in the testsuite 27092 gas/ChangeLog: 27093 27094 * testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded 27095 by minstretcfg, not mcyclecfg. 27096 270972023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com> 27098 27099 RISC-V: Add 'Smcntrpmf' extension and its CSRs 27100 This commit adds now stable and approved 'Smcntrpmf' extension defined by 27101 the RISC-V Cycle and Instret Privilege Mode Filtering specification. 27102 27103 Note that, because mcyclecfg and minstretcfg CSRs conflict with the 27104 privileged specification version 1.9.1, CSRs for this extension are only 27105 enabled on the privileged specification version 1.10 or later. 27106 27107 By checking the base privileged specification, we no longer need to change 27108 the design of base CSR handling. 27109 27110 This is based on the specification version v1.0_rc1 (Frozen): 27111 <https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163> 27112 27113 bfd/ChangeLog: 27114 27115 * elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from 27116 the new 'Smcntrpmf' extension. (riscv_supported_std_s_ext): Add 27117 'Smcntrpmf' to the supported S extension list. 27118 27119 gas/ChangeLog: 27120 27121 * config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes 27122 CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32. 27123 (riscv_csr_address): Add handling for new CSR classes. 27124 * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. Move 27125 "mscounteren" and "mhcounteren" CSRs and note that they are now 27126 aliases. 27127 * testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change. 27128 * testsuite/gas/riscv/csr.s: Add new CSRs. Move "mscounteren" 27129 and "mhcounteren" CSRs and note that they are now reused for 27130 the 'Smcntrpmf' extension. 27131 * testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of 27132 csr.s. 27133 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 27134 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 27135 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 27136 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 27137 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 27138 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 27139 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 27140 27141 include/ChangeLog: 27142 27143 * opcode/riscv-opc.h: Add new CSRs noting that this extension is 27144 incompatible with the privileged specification version 1.9.1. 27145 Move "mscounteren" and "mhcounteren" CSRs, make them aliases and 27146 reuse the CSR numbers from the 'Smcntrpmf' extension. 27147 (CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and 27148 "mhcounteren" are now aliases and new CSR macros are used instead. 27149 (CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH): 27150 New CSR macros. 27151 271522023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com> 27153 27154 RISC-V: Prohibit combination of 'E' and 'H' 27155 According to the ratified privileged specification (version 20211203), 27156 it says: 27157 27158 > The hypervisor extension depends on an "I" base integer ISA with 32 x 27159 > registers (RV32I or RV64I), not RV32E, which has only 16 x registers. 27160 27161 Also in the latest draft, it also prohibits RV64E with the 'H' extension. 27162 This commit prohibits the combination of 'E' and 'H' extensions. 27163 27164 bfd/ChangeLog: 27165 27166 * elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and 27167 'H' combinations. 27168 27169 gas/ChangeLog: 27170 27171 * testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to 27172 make sure that RV32E + 'H' is prohibited. 27173 * testsuite/gas/riscv/march-fail-rv32eh.l: Likewise. 27174 271752023-09-05 GDB Administrator <gdbadmin@sourceware.org> 27176 27177 Automatic date update in version.in 27178 271792023-09-04 Christophe Lyon <christophe.lyon@linaro.org> 27180 27181 arm: Make 'conflicting CPU architectures' error message more user-friendly 27182 Error messages such as "conflicting CPU architectures 10/16" are not 27183 very to understand, so this patch replaces the numbers with the 27184 description they actually mean: 27185 "conflicting CPU architectures ARM v7E-M vs Pre v4" 27186 27187 2023-09-01 Christophe Lyon <christophe.lyon@linaro.org> 27188 27189 bfd/ 27190 * elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and 27191 use it. 27192 (elf32_arm_merge_eabi_attributes): Update call to 27193 tag_cpu_arch_combine. 27194 27195 ld/ 27196 * testsuite/ld-arm/attr-merge-9.out: Update expected error 27197 message. 27198 * testsuite/ld-arm/attr-merge-arch-2.d: Likewise. 27199 272002023-09-04 Tom de Vries <tdevries@suse.de> 27201 27202 [gdb/testsuite] Fix race in gdb.base/add-symbol-file-attach.exp 27203 When running test-case gdb.base/add-symbol-file-attach.exp with target board 27204 unix/-m32, we run into: 27205 ... 27206 (gdb) attach 3955^M 27207 Attaching to process 3955^M 27208 Load new symbol table from "add-symbol-file-attach"? (y or n) y^M 27209 Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M 27210 Reading symbols from /lib/libm.so.6...^M 27211 Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M 27212 Reading symbols from /lib/libc.so.6...^M 27213 Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M 27214 Reading symbols from /lib/ld-linux.so.2...^M 27215 Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M 27216 0xf7f53549 in __kernel_vsyscall ()^M 27217 (gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach 27218 ... 27219 27220 The test fails because this regexp is used: 27221 ... 27222 -re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" { 27223 ... 27224 27225 The regexp attempts to detect that the exec is somewhere in pause (): 27226 ... 27227 int 27228 main (int argc, char **argv) 27229 { 27230 pause (); 27231 return 0; 27232 } 27233 ... 27234 but when the exec is blocked in pause, the backtrace is: 27235 ... 27236 (gdb) bt 27237 #0 0xf7fd2549 in __kernel_vsyscall () 27238 #1 0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29 27239 #2 0x0804844c in main (argc=1, argv=0xffffce84) 27240 at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26 27241 ... 27242 27243 We could simply extend the regexp to also match __kernel_vsyscall, but the 27244 more fundamental problem is that the test is racy. 27245 27246 The attach can happen before the exec is blocked in pause (), somewhere in the 27247 dynamic linker resolving the call to pause, in main or even earlier. 27248 27249 Note that for the test-case to be effective, the exec is not required to be in 27250 pause (). I added a "while (1);" loop at the start of main, reverted the 27251 patch fixing the corresponding PR and reproduced the problem it's supposed to 27252 detect. 27253 27254 Fix this by simply matching the "Reading symbols from" line, similar to what 27255 an earlier test is doing. 27256 27257 While we're at it, rewrite the earlier test to also use the -wrap idiom. 27258 27259 Tested on x86_64-linux. 27260 272612023-09-04 GDB Administrator <gdbadmin@sourceware.org> 27262 27263 Automatic date update in version.in 27264 272652023-09-03 GDB Administrator <gdbadmin@sourceware.org> 27266 27267 Automatic date update in version.in 27268 272692023-09-02 Simon Marchi <simon.marchi@efficios.com> 27270 27271 gdbserver: i387_cache_to_xsave: fix copy dest of zmm registers 27272 On a machine with AVX512 support (AMD EPYC 9634), I see these failures: 27273 27274 $ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver" 27275 ... 27276 FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs 27277 FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs 27278 FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs 27279 ... 27280 27281 The problem can be reduced to: 27282 27283 (gdb) print $zmm16.v8_int64 27284 $1 = {0, 0, 0, 0, 0, 0, 0, 0} 27285 (gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88} 27286 $2 = {11, 22, 33, 44, 55, 66, 77, 88} 27287 (gdb) print $zmm16.v8_int64 27288 $3 = {11, 22, 33, 44, 55, 66, 77, 88} 27289 (gdb) step 27290 5 ++x; 27291 (gdb) print $zmm16.v8_int64 27292 $4 = {11, 22, 77, 88, 0, 0, 0, 0} 27293 27294 Writing to the local regcache in GDB works fine, but the writeback to 27295 gdbserver (which happens when resuming / stepping) doesn't work (the 27296 code being stepped doesn't touch AVX registers, so we don't expect the 27297 value of zmm16 to change when stepping). 27298 27299 The problem is on the gdbserver side, the zmmh and ymmh portions of the 27300 zmm register are not memcpied at the right place in the xsave buffer. Fix 27301 that. Note now how the two modified memcpy calls match the memcmp calls 27302 just above them. 27303 27304 With this patch, gdb.arch/i386-avx512.exp passes completely for me. 27305 27306 Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433 27307 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 27308 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818 27309 273102023-09-02 GDB Administrator <gdbadmin@sourceware.org> 27311 27312 Automatic date update in version.in 27313 273142023-09-01 Joseph Myers <joseph@codesourcery.com> 27315 27316 config: Fix host -rdynamic detection for build != host != target 27317 [Merge from GCC commit 4d9bc81a5d8d884dee7a7781fa4c1577a6c9681a.] 27318 27319 The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic 27320 is necessary and supported uses an appropriate objdump for $host 27321 binaries (running on $build) in cases where $host is $build or 27322 $target. 27323 27324 However, it is missing such logic in the case where $host is neither 27325 $build nor $target, resulting in the compilers not being linked with 27326 -rdynamic and plugins not being usable with such a compiler. In fact 27327 $ac_cv_prog_OBJDUMP, as used when $build = $host, is always an objdump 27328 for $host binaries that runs on $build; that is, it's appropriate to 27329 use in this case as well. 27330 27331 Tested in such a configuration that it does result in cc1 being linked 27332 with -rdynamic as expected. Also bootstrapped with no regressions for 27333 x86_64-pc-linux-gnu. 27334 27335 config/ 27336 * gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Use 27337 export_sym_check="$ac_cv_prog_OBJDUMP -T" also when host is not 27338 build or target. 27339 273402023-09-01 Tom Tromey <tromey@adacore.com> 27341 27342 Fix "usage" errors for some MI varobj commands 27343 I noticed that the "usage" error for -var-set-frozen mentioned the 27344 wrong command name. Then I looked through the whole file and found a 27345 couple other spots that didn't mention the command name at all. This 27346 patch fixes all of these. 27347 27348 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 27349 273502023-09-01 Jan Beulich <jbeulich@suse.com> 27351 27352 x86: unindent most of set_cpu_arch() 27353 Inverting the initial if()'s condition allows to move out the bulk of 27354 the function by a level, improving readability at least a bit. While 27355 doing that also pull the push/pop handling up first, such that "else if" 27356 after "return" isn't needed anymore; the order in which special cases 27357 are checked doesn't really matter. 27358 27359 x86: rename CpuPCLMUL 27360 The name we use internally isn't in line with the SDM, and also isn't in 27361 line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave 27362 alone user facing names. 27363 27364 x86: correct source used for two non-AVX512 VEXWIG tests 27365 These shouldn't wrongly include the AVX512VL sources. Obviously the 27366 expectations therefore also need to change. 27367 27368 x86: drop Size64 from VMOVQ 27369 Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was 27370 right in adding the attribute to MOVQ, but there was no need to add it 27371 to VMOVQ. (See also the AVX512F form, which doesn't have the attribute 27372 either.) 27373 273742023-09-01 Jan Beulich <jbeulich@suse.com> 27375 27376 RISC-V: move various alias entries 27377 For disassembly to only use spec-mandated aliases, respective non-alias 27378 entries need to come ahead of their alias ones. Since identical 27379 mnemonics need to stay together, whole groups are moved up where 27380 necessary. 27381 27382 This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for 27383 consistent alias handling"), but then also goes beyond a plain revert. 27384 27385 Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com> 27386 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 27387 273882023-09-01 Jerry Zhang Jian <jerry.zhangjian@sifive.com> 27389 27390 Fix ld Makefile variable naming: ELF_CLFAGS -> ELF_CFLAGS 27391 273922023-09-01 Nelson Chu <nelson@rivosinc.com> 27393 27394 RISC-V: Fixed the wrong expansion for pseudo vmsge[u].vx instructions. 27395 The original report was from Kiva Oyama <libkernelpanic@gmail.com>, 27396 https://sourceware.org/pipermail/binutils/2023-August/129255.html 27397 27398 The vmsge[u].vx pseudo should be expanded to masked vmslt[u].vx only when 27399 vd != v0. Otherwise, it should be expanded to unmasked one. 27400 27401 gas/ 27402 * config/tc-riscv.c (vector_macro): Fixed the wrong expansion for 27403 pseudo vmsge[u].vx instructions. 27404 * testsuite/gas/riscv/vector-insns-vmsgtvx.d: Updated. 27405 274062023-09-01 Simon Marchi <simon.marchi@polymtl.ca> 27407 27408 gdb: remove uses of alloca in gdbtypes.c 27409 Replace two uses of alloca with std::string. 27410 27411 Change-Id: I970ae3f450da407494d95668a57bba8796d6292b 27412 Approved-by: Kevin Buettner <kevinb@redhat.com> 27413 274142023-09-01 GDB Administrator <gdbadmin@sourceware.org> 27415 27416 Automatic date update in version.in 27417 274182023-09-01 Nicolas Boulenguez <nicolas@debian.org> 27419 27420 PR30806, CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfo 27421 PR 30806 27422 bfd/ 27423 * doc/local.mk (doc/chew.stamp): Add CPPFLAGS_FOR_BUILD. 27424 * Makefile.in: Regenerate. 27425 binutils/ 27426 * Makefile.am (syslex_wrap.@OBJEXT@): Add CPPFLAGS_FOR_BUILD. 27427 (sysinfo.@OBJEXT@): Likewise. 27428 * Makefile.in: Regenerate. 27429 274302023-09-01 H.J. Lu <hjl.tools@gmail.com> 27431 27432 elf: Adjust PR ld/30791 tests 27433 Adjust PR ld/30791 tests: 27434 27435 1. Generic linker targets don't comply with all orhpan section merging 27436 rules. 27437 2. z80 fails since a, b, c, d are registers for z80. 27438 3. hppa fails since .text sections aren't merged for relocatable link. 27439 27440 PR ld/30791 27441 * testsuite/ld-elf/pr30791a.d: Xfail for generic and z80 27442 targets. 27443 * testsuite/ld-elf/pr30791b.d: Xfail for hppa and z80 targets. 27444 274452023-08-31 Tom Tromey <tom@tromey.com> 27446 27447 Add symbol::matches method 27448 This adds symbol::matches, a wrapper for symbol_matches_domain. Most 27449 places calling symbol_matches_domain can call this method instead, 27450 which is a bit less wordy and also (IMO) clearer. 27451 27452 Approved-By: Simon Marchi <simon.marchi@efficios.com> 27453 274542023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27455 27456 gdb: remove TYPE_FIELD_PACKED 27457 Replace with a new equivalent "is_packed" method on struct field. 27458 27459 Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c 27460 Approved-By: Tom Tromey <tom@tromey.com> 27461 274622023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27463 27464 gdb: remove TYPE_FIELD_BITSIZE 27465 Replace with type::field + field::bitsize. 27466 27467 Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a 27468 Approved-By: Tom Tromey <tom@tromey.com> 27469 274702023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27471 27472 gdb: remove FIELD_BITSIZE 27473 Replace with field::bitsize. 27474 27475 Change-Id: I400be235d6a1f446d0a4aafac01df5e850185d3a 27476 Approved-By: Tom Tromey <tom@tromey.com> 27477 274782023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27479 27480 gdb: introduce field::bitsize / field::set_bitsize 27481 Add these two methods, rename the field to m_bitsize to make it pseudo 27482 private. 27483 27484 Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413 27485 Approved-By: Tom Tromey <tom@tromey.com> 27486 274872023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27488 27489 gdb: remove TYPE_FIELD_ARTIFICIAL 27490 Replace with type::field + field::is_artificial. 27491 27492 Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081 27493 Approved-By: Tom Tromey <tom@tromey.com> 27494 274952023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27496 27497 gdb: remove FIELD_ARTIFICIAL 27498 Replace uses with field::is_artificial. 27499 27500 Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1 27501 Approved-By: Tom Tromey <tom@tromey.com> 27502 275032023-08-31 Simon Marchi <simon.marchi@polymtl.ca> 27504 27505 gdb: introduce field::is_artificial / field::set_is_artificial 27506 Add these two methods, rename the field to m_artificial to make it 27507 pseudo private. 27508 27509 Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a 27510 Approved-By: Tom Tromey <tom@tromey.com> 27511 275122023-08-31 Tom Tromey <tromey@adacore.com> 27513 27514 Remove eval_op_ternop 27515 eval_op_ternop is only used by the implementation of 27516 ternop_slice_operation. While working on another series, it was 27517 convenient for me to merge this function into its only caller. 27518 27519 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 27520 275212023-08-31 Kevin Buettner <kevinb@redhat.com> 27522 27523 [symtab/27831] New test case: gdb.base/add-symbol-file-attach.exp 27524 This commit adds a new test case for bug 27831. See the contents 27525 of the .exp file for a description of what it's about. 27526 27527 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831 27528 Approved-By: Tom Tromey <tom@tromey.com> 27529 275302023-08-31 Kevin Buettner <kevinb@redhat.com> 27531 27532 [symtab/27831] Fix OBJF_MAINLINE assert 27533 This commit fixes a bug mentioned by Florian Weimer during the 27534 libpthread/ld.so load order discussion from 2021. Florian provided 27535 instructions for reproducing the bug here: 27536 27537 https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html 27538 27539 That particular test does some interesting things involving forks, 27540 threads, and thread local storage. Fortunately, none of that is 27541 needed to reproduce the problem. 27542 27543 I've made a new test case (which is now found in a separate commit) 27544 contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The 27545 .c file is fairly simple as is the recipe for reproducing the problem. 27546 27547 After separately starting the test case and noting the process id, 27548 start gdb (w/ no arguments), and do the following to reproduce the 27549 assertion failure - for this run, the process id of the separately 27550 started add-symbol-file-attach process is 4103218: 27551 27552 (gdb) add-symbol-file add-symbol-file-attach 27553 add symbol table from file "add-symbol-file-attach" 27554 (y or n) y 27555 Reading symbols from add-symbol-file-attach... 27556 (gdb) attach 4103218 27557 Attaching to process 4103218 27558 Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y 27559 Reading symbols from /tmp/add-symbol-file-attach... 27560 Reading symbols from /lib64/libc.so.6... 27561 (No debugging symbols found in /lib64/libc.so.6) 27562 Reading symbols from /lib64/ld-linux-x86-64.so.2... 27563 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 27564 0x00007f502130bf27 in pause () from /lib64/libc.so.6 27565 (gdb) p foo 27566 symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*, 27567 const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0' 27568 failed. 27569 A problem internal to GDB has been detected, 27570 further debugging may prove unreliable. 27571 27572 The add-symbol-file command causes the symbols to be loaded without 27573 the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being 27574 set. This, in turn, causes the "maybe_copied" flag to be set for 27575 the global symbol (named "foo" in the provided test case). 27576 27577 The attach command will cause another objfile to be created, but 27578 it will reuse the symtabs from the objfile created by add-symbol-file, 27579 leading to a situation in which the OBJFILE_MAINLINE flag will be set 27580 for the new (attach-created) objfile, however the "maybe_copied" 27581 flag will still be set for the global symbol. Had it been loaded 27582 anew, this flag would not be set due to OBJFILE_MAINLINE being set 27583 for the objfile. 27584 27585 At present, minimal_symbol::value_address looks like this: 27586 27587 CORE_ADDR 27588 minimal_symbol::value_address (objfile *objfile) const 27589 { 27590 if (this->maybe_copied (objfile)) 27591 return get_msymbol_address (objfile, this); 27592 else 27593 return (CORE_ADDR (this->unrelocated_address ()) 27594 + objfile->section_offsets[this->section_index ()]); 27595 } 27596 27597 So, we can now see the problem: When the "maybe_copied" flag is set, 27598 get_msymbol_address() will be called. However, get_msymbol_address() 27599 assumes that it won't be called with the OBF_MAINLINE flag set for 27600 the objfile in question. It, in fact, contains an assert() which 27601 makes sure that this is the case: 27602 27603 gdb_assert ((objf->flags & OBJF_MAINLINE) == 0); 27604 27605 (If this assert is removed, then get_msymbol_address() recurses 27606 infinitely for the case under consideration.) 27607 27608 So, the problem here is that the maybe_copied flag is set for the 27609 symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted 27610 earlier, this happens due to add-symbol-file being used; this causes 27611 the maybe_copied flag to be set. Later, when the attach is performed, 27612 OBJF_MAINLINE will be set for that objfile, leading to this 27613 unfortunate situation. 27614 27615 My first cut at a solution involved adjusting the 27616 MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the 27617 method noted above) to include a test of the OBJFILE_MAINLINE flag. 27618 However, Simon Marchi, in his review of my patch, suggested a better 27619 solution. Simon observed that the 'maybe_copied' flag is (was, after 27620 this commit) being set/initialized in record_minimal_symbol() using 27621 using the objfile in the context in which the symbol was created. 27622 27623 Simon further observed: 27624 27625 Today, a single copy is created, as symtabs are shared between 27626 objfiles. This means that everything that we store into a symbol 27627 must be independent of any objfile. However, the value of the 27628 maybe_copied field is dependent on the objfile in the context of 27629 which the symbol was created. Meaning that when the symbol is 27630 re-used in the context of another objfile, the maybe_copied value is 27631 not right in the context of that objfile. 27632 27633 So I think it means there isn't a single "is this symbol maybe 27634 copied" value, but instead "is this symbol maybe copied, in the 27635 context of this given objfile". And the answer is yes or no, 27636 depending on whether the objfile is mainline. So maybe_copied 27637 should become a method that takes an objfile and returns an answer 27638 based on that. 27639 27640 Simon's full review can be found here: 27641 27642 https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html 27643 27644 Simon also provided a patch which implements this suggestion. The 27645 current patch is mostly his work, though I did make some adjustments 27646 during a rebase in addition to making some changes to account for a 27647 concern from Tom Tromey. 27648 27649 During his review of the v3 series, Tom noted, "The old approach was 27650 specific to ELF, while the new approach will be used by any object 27651 format." Tom further observed, "...it seems like it could result in an 27652 incorrect evaluation in some scenario." This seemed plausible to me, 27653 so I introduced the flag 'object_format_has_copy_relocs' to struct 27654 objfile. It is set at the end of elf_symfile_read() in elfread.c. 27655 The minimal_symbol::maybe_copied method tests this new flag, forcing 27656 this method to return false when the flag is not set. If we find that 27657 other object file formats use the same copy reloc mechanism as ELF, 27658 then 'object_format_has_copy_relocs' should be set for objfiles using 27659 those formats. 27660 27661 Lastly, I'll note that this is a strange use case. It's far more 27662 common to either let gdb figure out which file to load by itself when 27663 attaching, i.e. 27664 27665 (gdb) attach 4104360 27666 Attaching to process 4104360 27667 Reading symbols from /tmp/add-symbol-file-attach... 27668 Reading symbols from /lib64/libc.so.6... 27669 (No debugging symbols found in /lib64/libc.so.6) 27670 Reading symbols from /lib64/ld-linux-x86-64.so.2... 27671 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 27672 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 27673 (gdb) p foo 27674 $1 = 42 27675 27676 ...or to use the "file" command prior to the attach, like this: 27677 27678 (gdb) file add-symbol-file-attach 27679 Reading symbols from add-symbol-file-attach... 27680 (gdb) attach 4104360 27681 Attaching to program: /tmp/add-symbol-file-attach, process 4104360 27682 Reading symbols from /lib64/libc.so.6... 27683 (No debugging symbols found in /lib64/libc.so.6) 27684 Reading symbols from /lib64/ld-linux-x86-64.so.2... 27685 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 27686 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 27687 27688 Both of these more common scenarios work perfectly fine; using 27689 "add-symbol-file" to load the program to which you will attach 27690 isn't recommended as a normal use case. That said, it's bad for 27691 gdb to assert, hence this fix. 27692 27693 Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca> 27694 Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca> 27695 Approved-by: Tom Tromey <tom@tromey.com> 27696 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831 27697 276982023-08-31 Tom Tromey <tom@tromey.com> 27699 27700 Unify DW_TAG_typedef case in new_symbol 27701 This patch merges the DW_TAG_typedef case in new_symbol with some 27702 other type-related cases. These all have identical code. 27703 27704 Reviewed-By: Guinevere Larsen <blarsen@redhat.com> 27705 277062023-08-31 Tom Tromey <tom@tromey.com> 27707 27708 Revert "Simplify @node use in BFD documentation" 27709 This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8. 27710 27711 My earlier patch to simplifify the @node uses in the BFD manual didn't 27712 take into account (1) that BFD doesn't use the ordinary texinfo 27713 sectioning commands, and (2) that some users are stuck on very ancient 27714 versions of makeinfo. 27715 27716 This patch reverts the change. 27717 27718 I went through the entire manual using the spacebar, trying to find 27719 the original problem I reported in the change, but couldn't. I don't 27720 know why. Anyway, all this means is that, with this reversion, 27721 editing the node structure will be slightly less convenient. 27722 27723 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30703 27724 27725 2023-08-30 Tom Tromey <tom@tromey.com> 27726 27727 PR binutils/30703 27728 * doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding 27729 parameters back to @node. 27730 277312023-08-31 Tom de Vries <tdevries@suse.de> 27732 27733 [gdb/contrib] Require minimal dwz version in cc-with-tweaks.sh 27734 I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build 27735 from current trunk, but the pathname to the build dir changed and I forgot to 27736 update my test scripts, so the test scripts reverted to using system dwz, 27737 version 0.12. 27738 27739 Consequently, I ran into: 27740 ... 27741 (gdb) p ZERO^M 27742 No symbol "ZERO" in current context.^M 27743 (gdb) FAIL: gdb.base/enumval.exp: p ZERO 27744 ... 27745 which is due to PR dwz/24468, which was fixed in version 0.13. 27746 27747 Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such 27748 that this situation is detected and we get instead: 27749 ... 27750 gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \ 27751 0.13 or higher required 27752 ... 27753 27754 Tested on x86_64-linux, verified with shellcheck. 27755 27756 Approved-By: Tom Tromey <tom@tromey.com> 27757 277582023-08-31 Alan Modra <amodra@gmail.com> 27759 27760 vms-alpha: Free memory on failure path 27761 * vms-alpha.c (evax_bfd_print_eobj): Free rec on failure. 27762 277632023-08-31 Alan Modra <amodra@gmail.com> 27764 27765 gas init_stab_section and get_stab_string_offset 27766 get_stab_string_offset currently creates the stabstr section if not 27767 already present, in the process keeping a reference to the malloc'd 27768 section name string. Really, the name belongs in bfd_alloc'd memory 27769 or some obstack so that it doesn't show as a memory leak on exit. 27770 s_stab_generic at least does allocate the name for the stab section on 27771 an obstack, but doesn't tidy that as well as it could. Return paths 27772 after issuing a warning don't release the memory, nor the memory for 27773 the "string" copy. 27774 27775 This patch fixes these problems. s_stab_generic is rearranged so that 27776 creation of the sections occurs earlier, before any potential uses of 27777 the note obstack during expression parsing. That makes it possible to 27778 always free the section name strings unless used to create new 27779 sections. I've also avoided get_absolute_expression_and_terminator 27780 as I see that function might skip over end-of-line, and lack of a 27781 --input_line_pointer might have caused the following source line to be 27782 ignored. (Other uses of this function in gas are OK.) 27783 27784 * config/obj-coff.c (obj_coff_init_stab_section): Add stabstr 27785 param. Pass to get_stab_string_offset rather than name of 27786 section. 27787 * config/obj-som.c (obj_som_init_stab_section): Likewise. 27788 * config/obj-elf.c (obj_elf_init_stab_section): Likewise. 27789 (elf_init_stab_section): Adjust. 27790 * config/obj-coff.h (INIT_STAB_SECTION): Update. 27791 (obj_coff_init_stab_section): Update prototype. 27792 * config/obj-som.h: Similarly. 27793 * config/obj-elf.h: Similarly. 27794 * config/obj-multi.h (INIT_STAB_SECTION): Update. 27795 * obj.h (struct format_ops <init_stab_section>): Update. 27796 * read.h (get_stab_string_offset): Update prototype. 27797 * stabs.c (cached_sec): Delete. 27798 (stabs_begin): Adjust to suit. 27799 (get_stab_string_offset): Add stabstr param, delete stabstr_name 27800 and free_stabstr_secname params. Don't make stabstr section 27801 here. 27802 (eat_comma): New function. 27803 (s_stab_generic): Replace stab_secname_obstack_end param with 27804 bool freenames. Move creation of stab and stabstr sections 27805 earlier, so the names can be freed earlier before possible use 27806 of notes obstack during expression parsing. Tidy error paths 27807 ensuring "string" is freed. Use get_absolute_expression in 27808 place of get_absolute_expression_and_terminator. 27809 (s_stab): Adjust. 27810 (s_xstab): Use notes_concat to make stabstr section name. 27811 278122023-08-31 Alan Modra <amodra@gmail.com> 27813 27814 gas OBJ_PROCESS_STAB 27815 This macro and the supporting functions have an unused "seg" first 27816 argument. Tidy that. 27817 27818 * config/obj-aout.c (obj_aout_process_stab): Delete first param. 27819 * config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise. 27820 * config/obj-elf.c (elf_process_stab): Likewise. 27821 * config/obj-elf.h (OBJ_PROCESS_STAB): Likewise. 27822 * config/obj-macho.h (OBJ_PROCESS_STAB): Likewise. 27823 * config/obj-multi.h (OBJ_PROCESS_STAB): Likewise. 27824 * ecoff.c (ecoff_stab): Likewise. 27825 * ecoff.h (ecoff_stab): Likewise. 27826 * obj.h (struct format_ops <process_stab>): Likewise. 27827 * stabs.c (OBJ_PROCESS_STAB): Likewise. 27828 278292023-08-31 Tom de Vries <tdevries@suse.de> 27830 27831 [gdb/symtab] Replace TYPE_ALLOC with TYPE_ZALLOC where required 27832 Handle the remaining uses of TYPE_ALLOC, either by: 27833 - replacing with TYPE_ZALLOC, or 27834 - adding a comment explaining why zero-initialization is not necessary. 27835 27836 Tested on x86_64-linux. 27837 27838 Approved-By: Tom Tromey <tom@tromey.com> 27839 278402023-08-31 Tom de Vries <tdevries@suse.de> 27841 27842 [gdb/symtab] Replace TYPE_ALLOC + B_CLRALL with TYPE_ZALLOC 27843 I noticed some cases of TYPE_ALLOC followed by B_CLRALL. 27844 27845 Replace these with TYPE_ZALLOC. 27846 27847 Tested on x86_64-linux. 27848 27849 Approved-By: Tom Tromey <tom@tromey.com> 27850 278512023-08-31 Tom de Vries <tdevries@suse.de> 27852 27853 [gdb/symtab] Replace TYPE_ALLOC + memset with TYPE_ZALLOC 27854 I noticed a case of TYPE_ALLOC followed by memset. 27855 27856 Replace this with TYPE_ZALLOC. 27857 27858 Tested on x86_64-linux. 27859 27860 Approved-By: Tom Tromey <tom@tromey.com> 27861 278622023-08-31 Tom de Vries <tdevries@suse.de> 27863 27864 [gdb/symtab] Do more zero-initialization of type::fields 27865 Now that we've introduced type::{alloc_fields,copy_fields}, the places where 27866 no zero-initialization of allocated fields is done are easy to spot: 27867 ... 27868 $ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false 27869 gdb/coffread.c: type->alloc_fields (nfields, false); 27870 gdb/coffread.c: type->alloc_fields (nsyms, false); 27871 gdb/stabsread.c: ftype->alloc_fields (nsemi, false); 27872 gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false); 27873 gdb/gdbtypes.c: alloc_fields (nfields, false); 27874 gdb/gdbtypes.c: alloc_fields (nfields, false); 27875 gdb/mdebugread.c: t->alloc_fields (nfields, false); 27876 gdb/mdebugread.c: ftype->alloc_fields (nparams, false); 27877 ... 27878 27879 All hits in gdbtypes.c are ok. There are two hits in the two variants of 27880 copy_fields, and there's already a comment for the third. 27881 27882 AFAICT, the other ones are not ok, so fix those by dropping the "false" 27883 argument. 27884 27885 Tested on x86_64-linux. 27886 27887 Approved-By: Tom Tromey <tom@tromey.com> 27888 278892023-08-31 Tom de Vries <tdevries@suse.de> 27890 27891 [gdb/symtab] Factor out type::{alloc_fields,copy_fields} 27892 After finding this code in buildsym_compunit::finish_block_internal: 27893 ... 27894 ftype->set_fields 27895 ((struct field *) 27896 TYPE_ALLOC (ftype, nparams * sizeof (struct field))); 27897 ... 27898 and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more 27899 locations that needed fixing. 27900 27901 I decided to make things easier to spot by factoring out a new function 27902 alloc_fields: 27903 ... 27904 /* Allocate the fields array of this type, with NFIELDS elements. If INIT, 27905 zero-initialize the allocated memory. */ 27906 void 27907 type::alloc_fields (unsigned int nfields, bool init = true); 27908 ... 27909 where: 27910 - a regular use would be "alloc_fields (nfields)", and 27911 - an exceptional use that needed no initialization would be 27912 "alloc_fields (nfields, false)". 27913 27914 Pretty soon I discovered that most of the latter cases are due to 27915 initialization by memcpy, so I added two variants of copy_fields as well. 27916 27917 After this rewrite there are 8 uses of set_fields left: 27918 ... 27919 gdb/coffread.c: type->set_fields (nullptr); 27920 gdb/coffread.c: type->set_fields (nullptr); 27921 gdb/coffread.c: type->set_fields (nullptr); 27922 gdb/eval.c: type->set_fields 27923 gdb/gdbtypes.c: type->set_fields (args); 27924 gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (), 27925 gdb/dwarf2/read.c: type->set_fields (new_fields); 27926 gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1); 27927 ... 27928 27929 These fall into the following categories: 27930 - set to nullptr (coffread.c), 27931 - type not owned by objfile or gdbarch (eval.c), and 27932 - modifying an existing fields array, like adding an element at the end or 27933 dropping an element at the start (the rest). 27934 27935 Tested on x86_64-linux. 27936 279372023-08-31 Tom de Vries <tdevries@suse.de> 27938 27939 [gdb/symtab] Fix uninitialized memory in buildsym_compunit::finish_block_internal 27940 When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs, 27941 gdb either segfaults or asserts due to reading uninitialized memory, allocated 27942 here in buildsym_compunit::finish_block_internal: 27943 ... 27944 ftype->set_fields 27945 ((struct field *) 27946 TYPE_ALLOC (ftype, nparams * sizeof (struct field))); 27947 ... 27948 27949 Fix this by using TYPE_ZALLOC instead. 27950 27951 Tested on x86_64-linux. 27952 27953 Approved-By: Tom Tromey <tom@tromey.com> 27954 27955 PR symtab/30810 27956 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810 27957 279582023-08-31 Claudiu Zissulescu <claziss@gmail.com> 27959 27960 arc: Update elfarcv2 script template 27961 Update ARC's elfarcv2 script template with: 27962 27963 - The .ivt section (Interrupt Vector Table) is mapped at the begining 27964 of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it 27965 was pointing to 0x00. 27966 27967 - MEMORY_FILE is a new emulation paramter and sets the name for the 27968 linker script file which holds the MEMORY commands required by 27969 arcv2elfx emulation. 27970 27971 - Four new linker variables are introduced available when arcv2elf emulation is used: 27972 * __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero. 27973 * __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M. 27974 * __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000. 27975 * __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M. 27976 27977 ld/ChangeLog: 27978 27979 * scripttempl/elfarcv2.sc: Update script template. 27980 279812023-08-31 H.J. Lu <hjl.tools@gmail.com> 27982 27983 elf: Don't merge sections with different SHF_LINK_ORDER 27984 For relocatable link, don't merge 2 SHF_LINK_ORDER sections if output 27985 sections of their linked to sections are different. 27986 27987 * ldelf.c (elf_orphan_compatible): Don't merge sections with 27988 different SHF_LINK_ORDER. 27989 * testsuite/ld-elf/pr30791a.d: New file. 27990 * testsuite/ld-elf/pr30791a.s: Likewise. 27991 * testsuite/ld-elf/pr30791b.d: Likewise. 27992 * testsuite/ld-elf/pr30791b.s: Likewise. 27993 * testsuite/ld-elf/pr30791c.s: Likewise. 27994 * testsuite/ld-elf/pr30791d.s: Likewise. 27995 279962023-08-31 H.J. Lu <hjl.tools@gmail.com> 27997 27998 elf: Check DT_SYMTAB only on non-IR object 27999 Check DT_SYMTAB only on non-IR object of archive member to avoid crash 28000 on LLVM IR object with NULL elf_tdata. 28001 28002 PR ld/30811 28003 * elflink.c (elf_link_is_defined_archive_symbol): Check 28004 DT_SYMTAB only on non-IR object. 28005 280062023-08-31 GDB Administrator <gdbadmin@sourceware.org> 28007 28008 Automatic date update in version.in 28009 280102023-08-31 Alan Modra <amodra@gmail.com> 28011 28012 libbfd.texi zero size 28013 Pattern rules in doc/local.mk exist that specify how to make 28014 libbfd.texi from libfd.h or libbfd.c. Since both files exist and the 28015 libbfd.h rule is first, libbfd.h is used. libbfd.h doesn't contain 28016 the documentation.. 28017 28018 * doc/local.mk (doc/%stamp): Put rule making this from %.c 28019 before %.h rule. 28020 * Makefile.in: Regenerate. 28021 * libbfd.c (Byte swapping routines): Don't omit description. 28022 280232023-08-30 Alan Modra <amodra@gmail.com> 28024 28025 DEFAULT_BUFFERSIZE 28026 There isn't any reason to think that a particular buffer size is 28027 ideal in bfd, so let's just not define it. 28028 28029 * libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define. 28030 * libbfd.h: Regenerate. 28031 * archive.c (AR_WRITE_BUFFERSIZE): Substitute value. 28032 * vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise. 28033 * coff-rs6000.c (do_copy): Likewise, and use sizeof. 28034 280352023-08-30 Tom de Vries <tdevries@suse.de> 28036 28037 [gdb/testsuite] Fix gdb.dwarf2/nullptr_t.exp with cc-with-dwz-m 28038 When running test-case gdb.dwarf2/nullptr_t.exp with target board 28039 cc-with-dwz-m, I run into: 28040 ... 28041 FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol 28042 ... 28043 28044 The problem is that were looking for "typedef void decltype\\(nullptr\\)" 28045 using "maint print symbols -source $srcfile", but dwz has moved the typedef to 28046 a PU, so it's shown by "maint print symbols -source <unknown>" instead. 28047 28048 Fix this by dropping the "-source $srcfile" bit. 28049 28050 Tested on x86_64-linux, with make-check-all.sh. 28051 280522023-08-30 Simon Marchi <simon.marchi@efficios.com> 28053 28054 gdb: simplify vector construction in eval_op_rust_array 28055 Replace the manual fill of the vector with the appropriate std::vector 28056 constructor that makes N copies of the provided value. 28057 28058 Change-Id: I579570748c48f53d35024105269d83c716294746 28059 Approved-By: Tom Tromey <tom@tromey.com> 28060 280612023-08-30 Maciej W. Rozycki <macro@orcam.me.uk> 28062 28063 Revert "Gold: Add targ_extra_little_endian to configure.ac" 28064 This reverts commit cf8565fb2ea42579c50722cbaeafdf71c3d58c66. It was 28065 applied unapproved. 28066 28067 Revert "Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian" 28068 This reverts commit 39834263784567c306fbccb8230ddd1badca53fe. It was 28069 applied unapproved. 28070 28071 Revert "Gold/MIPS: Drop mips*le/mips*el* triple pattern" 28072 This reverts commit adb3ae2eba78b4b84d7b94342f6774b250190a98. It was 28073 applied unapproved. 28074 28075 Revert "Gold/MIPS: Add targ_extra_size=64 for mips32 triples" 28076 This reverts commit d6cdc0af2b880bb48dd16055f4cb3509c7a2da70. It was 28077 applied unapproved. 28078 28079 Revert "Gold/MIPS: Add mips64*/mips64*el triple support" 28080 This reverts commit 5c4cdba100b66e2924a25dad9b12d8e5b84d527f. It was 28081 applied unapproved. 28082 28083 Revert "MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets" 28084 This reverts commit 025e84f93566c8ced594ef48ddee1dec7e5b4cdd. It was 28085 applied unapproved. 28086 280872023-08-30 Willgerodt, Felix <felix.willgerodt@intel.com> 28088 28089 gdbserver, linux-low: add a couple of nullptr assertions. 28090 This safeguards a couple of places that may theoretically return NULL but 28091 must not in this specific context. These were found by a static analysis tool. 28092 28093 Approved-By: Tom Tromey <tom@tromey.com> 28094 280952023-08-30 Tsukasa OI <research_trasio@irq.a4lg.com> 28096 28097 RISC-V: Make XVentanaCondOps RV64 only 28098 Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual 28099 only defines them only for RV64 (because all Ventana's processors implement 28100 RV64). 28101 28102 This commit limits XVentanaCondOps instructions RV64-only to match the 28103 behavior of the manual and LLVM. 28104 28105 Note that this commit alone will not make XVentanaCondOps extension with 28106 RV32 invalid (it just makes XVentanaCondOps on RV32 empty). 28107 28108 opcodes/ChangeLog: 28109 28110 * riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn" 28111 to XLEN=64. 28112 28113 gas/ChangeLog: 28114 28115 * testsuite/gas/riscv/x-ventana-condops-32.d: New failure test. 28116 * testsuite/gas/riscv/x-ventana-condops-32.l: Likewise. 28117 281182023-08-30 Alan Modra <amodra@gmail.com> 28119 28120 objdump: Free sorted_syms on error path 28121 * objdump.c (disassemble_data): Free sorted_syms before returning. 28122 28123 binutils/dwarf.c abbrev list leak 28124 * dwarf.c (process_debug_info): Call free_abrev_list on 28125 return paths. 28126 28127 Re: readelf/objdump: Handle DWARF info with mixed types of range section 28128 PR 30791 28129 * dwarf.c (free_debug_information): Free range_versions. 28130 281312023-08-30 GDB Administrator <gdbadmin@sourceware.org> 28132 28133 Automatic date update in version.in 28134 281352023-08-29 Tom de Vries <tdevries@suse.de> 28136 28137 [gdb/build] Fix C inclusion of nat/x86-cpuid.h 28138 When running test-case gdb.arch/i386-avx512.exp, I run into: 28139 ... 28140 gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0: 28141 src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count': 28142 src/gdb/nat/x86-cpuid.h:63:16: error: \ 28143 'nullptr' undeclared (first use in this function) 28144 if (__eax == nullptr) 28145 ^~~~~~~ 28146 src/gdb/nat/x86-cpuid.h:63:16: note: each \ 28147 undeclared identifier is reported only once for each function it appears in 28148 28149 === gdb Summary === 28150 28151 # of untested testcases 1 28152 ... 28153 28154 This is due to commit e85aad4ae76 ("nat/x86-cpuid.h: Add x86_cpuid_count 28155 wrapper around __get_cpuid_count"), which introduced the nullptr check. 28156 28157 The header file gdb/nat/x86-cpuid.h is a file that is included in the build 28158 and compiled as a C++ file, but also in the testsuite and compiled as a C 28159 file. 28160 28161 Fix this by replacing nullptr with (void *)0. 28162 28163 Tested on x86_64-linux. 28164 28165 Co-Authored-By: Kevin Buettner <kevinb@redhat.com> 28166 Approved-by: Kevin Buettner <kevinb@redhat.com> 28167 281682023-08-29 Tom Tromey <tromey@adacore.com> 28169 28170 More renames in array_operation::evaluate 28171 array_operation::evaluate has variables named "tem2" and "tem3". This 28172 patch replaces one with a better name, and entirely removes the other. 28173 28174 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28175 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28176 281772023-08-29 Tom Tromey <tromey@adacore.com> 28178 28179 Remove "highbound" parameter from value_array 28180 value_array requires the passed-in bounds to match the length of the 28181 array_view it is given. This patch removes the redundant "highbound" 28182 parameter. 28183 28184 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28185 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28186 281872023-08-29 Tom Tromey <tromey@adacore.com> 28188 28189 Remove another redundant variable from array_operation::evaluate 28190 This removes yet another redundant variable from 28191 array_operation::evaluate -- only one index is needed. 28192 28193 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28194 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28195 281962023-08-29 Tom Tromey <tromey@adacore.com> 28197 28198 Remove redundant variable from array_operation::evaluate 28199 In array_operation::evaluate, 'idx' and 'tem' are redundant in one 28200 branch. This patch merges them, using the clearer name. 28201 28202 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28203 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28204 282052023-08-29 Tom Tromey <tromey@adacore.com> 28206 28207 Hoist array bounds check in array_operation::evaluate 28208 This hoists the array bounds check in array_operation::evaluate to 28209 before the loop. 28210 28211 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28212 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28213 282142023-08-29 Tom Tromey <tromey@adacore.com> 28215 28216 Declare 'tem' in loop header in array_operation::evaluate 28217 This changes array_operation::evaluate to declare the 'tem' variable 28218 in the loop header, rather than at the top of the function. This is 28219 cleaner and easier to reason about. I also changed 'nargs' to be 28220 'const'. 28221 28222 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28223 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28224 282252023-08-29 Tom Tromey <tromey@adacore.com> 28226 28227 Use gdb::array_view for value_array 28228 This changes value_array to accept an array view. I also replaced an 28229 alloca with a std::vector in array_operation::evaluate. This function 28230 can work on any size of array, so it seems bad to use alloca. 28231 28232 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28233 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28234 282352023-08-29 Simon Marchi <simon.marchi@efficios.com> 28236 28237 gdb/testsuite: recognize one more unsupported instruction in gdb.reverse/step-precsave.exp 28238 When running this test on a processor that supports AVX512 (AMD EPYC 28239 9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see: 28240 28241 continue^M 28242 Continuing.^M 28243 Process record does not support instruction bound.^M 28244 Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M 28245 Process record: failed to record execution log.^M 28246 ^M 28247 Program stopped.^M 28248 0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M 28249 (gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main 28250 28251 The instruction at this address is: 28252 28253 0x00007ffff7f49b40: 62 e2 7d 48 7a c6 vpbroadcastb %esi,%zmm16 28254 28255 This seems like an AVX512 instruction (given the use of zmm16). Match 28256 this byte value in order to produce a KFAIL. 28257 28258 Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee 28259 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807 28260 Approved-By: Tom Tromey <tom@tromey.com> 28261 282622023-08-29 Tom de Vries <tdevries@suse.de> 28263 28264 [gdb/testsuite] Require have_compile_flag -mavx512f in gdb.arch/i386-avx512.exp 28265 When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into: 28266 ... 28267 Running gdb.arch/i386-avx512.exp ... 28268 gdb compile failed, gcc: error: unrecognized command line option '-mavx512f' 28269 ... 28270 28271 Fix this by requiring have_compile_flag -mavx512f. 28272 28273 Tested on x86_64-linux. 28274 282752023-08-29 Tom de Vries <tdevries@suse.de> 28276 28277 [gdb/testsuite] Require gcc >= 5 in gdb.linespec/cpls-abi-tag.exp 28278 When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run 28279 into: 28280 ... 28281 cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’ 28282 ABI3 test_abi_tag_struct s; 28283 ^ 28284 ... 28285 28286 The test-case is supported starting gcc 5. 28287 28288 Fix this by requiring gcc >= 5, if a gcc compiler is used. 28289 28290 Tested on x86_64-linux. 28291 282922023-08-29 Tom de Vries <tdevries@suse.de> 28293 28294 [gdb/testsuite] Handle some test-cases with older compiler 28295 When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run 28296 into a compilation failure due to the test-case requiring c++11 and the 28297 compiler defaulting to less than that. 28298 28299 Fix this by compiling with -std=c++11. 28300 28301 Likewise in a few other test-cases. 28302 28303 Tested on x86_64-linux. 28304 283052023-08-29 Tom de Vries <tdevries@suse.de> 28306 28307 [gdb/testsuite] Fix false negative in have_host_locale 28308 In test-case gdb.tui/pr30056.exp we check for: 28309 ... 28310 require {have_host_locale C.UTF-8} 28311 ... 28312 28313 The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to 28314 find it in the list returned by host_locales. 28315 28316 On my development platform, "locale -a" lists C.utf8, which is normalized to 28317 "c.utf8" by host_locales, so there's a match and have_host_locale returns true. 28318 28319 On another platform however, "locale -a" lists C.UTF-8, which is normalized to 28320 "c.utf-8" by host_locales, so there's no match and have_host_locale returns false. 28321 28322 Fix this by also dropping the dash in host_locales. 28323 28324 Tested on x86_64-linux. 28325 283262023-08-29 Nicolas Boulenguez <nicolas.boulenguez@free.fr> 28327 28328 readelf: typos in user messages 28329 283302023-08-29 Tom Tromey <tromey@adacore.com> 28331 28332 Default getpkt 'forever' parameter to 'false' 28333 This patch changes remote.c so that the getpkt 'forever' parameter now 28334 defaults to 'false' and fixes up all the callers. 28335 28336 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28337 283382023-08-29 Tom Tromey <tromey@adacore.com> 28339 28340 Unify getpkt and getpkt_or_notif_sane 28341 getpkt and getpkt_or_notif_sane are just wrappers for 28342 getpkt_or_notif_sane_1. This patch adds the is_notif parameter to 28343 getpkt, with a suitable default, and removes the wrappers. 28344 28345 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28346 283472023-08-29 Tom Tromey <tromey@adacore.com> 28348 28349 Use bool in getpkt 28350 This changes getpkt and related functions to use bool rather than int. 28351 28352 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28353 283542023-08-29 Tom Tromey <tromey@adacore.com> 28355 28356 Remove expecting_notif parameter from getpkt_or_notif_sane_1 28357 For getpkt_or_notif_sane_1, expecting_notif is redundant, because it 28358 always reflects whether the is_notif parameter is non-NULL. This 28359 patch removes the redundant parameter. 28360 28361 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28362 283632023-08-29 Tom Tromey <tromey@adacore.com> 28364 28365 Remove getpkt_sane 28366 I noticed that getpkt is just a wrapper around getpk_sane, so this 28367 patch unifies the two of them. 28368 28369 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 28370 283712023-08-29 Tom de Vries <tdevries@suse.de> 28372 28373 [gdb/testsuite] Check for sys/random.h in gdb.reverse/getrandom.exp 28374 When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19, 28375 we run into: 28376 ... 28377 gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \ 28378 sys/random.h: No such file or directory 28379 #include <sys/random.h> 28380 ^ 28381 compilation terminated. 28382 28383 === gdb Summary === 28384 28385 # of untested testcases 1 28386 ... 28387 and: 28388 ... 28389 UNTESTED: gdb.reverse/getrandom.exp: failed to prepare 28390 ... 28391 28392 Fix this by testing for the presence of the header, such that we have instead: 28393 ... 28394 UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \ 28395 have_system_header sys/random.h 28396 ... 28397 28398 Tested on x86_64-linux and i686-linux. 28399 284002023-08-29 GDB Administrator <gdbadmin@sourceware.org> 28401 28402 Automatic date update in version.in 28403 284042023-08-28 Tom de Vries <tdevries@suse.de> 28405 28406 [gdb/testsuite] Improve xfail in gdb.cp/nsusing.exp 28407 In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS 28408 mentioned: 28409 ... 28410 XFAIL: gdb.cp/nsusing.exp: print x, before using statement 28411 XFAIL: gdb.cp/nsusing.exp: print x, only using M 28412 ... 28413 28414 Add the missing PRMS, such that we have: 28415 ... 28416 XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716) 28417 XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716) 28418 ... 28419 and limit the xfail to unfixed versions. 28420 28421 The PR is fixed starting gcc 13, but it has been backported to release 28422 branches stretching back to gcc 10. For simplicity we just stick to testing 28423 for the major version and ignore the backported fixes. 28424 28425 Tested on x86_64-linux. 28426 28427 Approved-By: Tom Tromey <tom@tromey.com> 28428 284292023-08-28 John Baldwin <jhb@FreeBSD.org> 28430 28431 gdbserver: Fix style of struct declarations in i387-fp.cc 28432 284332023-08-28 John Baldwin <jhb@FreeBSD.org> 28434 28435 gdbserver: Simplify handling of ZMM registers. 28436 - Reuse num_xmm_registers directly for the count of ZMM0-15 registers 28437 as is already done for the YMM registers for AVX rather than using 28438 a new variable that is always the same. 28439 28440 - Replace 3 identical variables for the count of upper ZMM16-31 28441 registers with a single variable. Make use of this to merge 28442 various loops working on the ZMM XSAVE region so that all of the 28443 handling for the various sub-registers in this region are always 28444 handled in a single loop. 28445 28446 - While here, fix some bugs in i387_cache_to_xsave where if 28447 X86_XSTATE_ZMM was set on i386 (e.g. a 32-bit process on a 64-bit 28448 kernel), the -1 register nums would wrap around and store the value 28449 of GPRs in the XSAVE area. This should be harmless, but is 28450 definitely odd. Instead, check num_zmm_high_registers directly when 28451 checking X86_XSTATE_ZMM and skip the ZMM region handling entirely if 28452 the register count is 0. 28453 28454 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28455 284562023-08-28 John Baldwin <jhb@FreeBSD.org> 28457 28458 x86: Remove X86_XSTATE_SIZE and related constants. 28459 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28460 284612023-08-28 Aleksandar Paunovic <aleksandar.paunovic@intel.com> 28462 John Baldwin <jhb@FreeBSD.org> 28463 28464 gdbserver: Use x86_xstate_layout to parse the XSAVE extended state area. 28465 Replace the extended state area fields of i387_xsave with methods which 28466 return an offset into the XSAVE buffer. 28467 28468 The two changed functions are called within all tests which runs 28469 gdbserver. 28470 28471 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28472 284732023-08-28 Aleksandar Paunovic <aleksandar.paunovic@intel.com> 28474 John Baldwin <jhb@FreeBSD.org> 28475 28476 gdbserver: Refactor the legacy region within the xsave struct 28477 Legacy fields of the XSAVE area are already defined within fx_save 28478 struct. Use class inheritance to remove code duplication. 28479 28480 The two changed functions are called within all tests which run 28481 gdbserver. 28482 28483 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28484 284852023-08-28 John Baldwin <jhb@FreeBSD.org> 28486 28487 gdbserver: Add a function to set the XSAVE mask and size. 28488 Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set 28489 the value instead. Add a static global instance of x86_xsave_layout 28490 and initialize it in the new function as well to be used in a future 28491 commit to parse XSAVE extended state regions. 28492 28493 Update the Linux port to use this function rather than setting 28494 x86_xcr0 directly. In the case that XML is not supported, don't 28495 bother setting x86_xcr0 to the default value but just omit the call to 28496 i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for 28497 non-XML. 28498 28499 In addition, use x86_xsave_length to determine the size of the XSAVE 28500 register set via CPUID. 28501 28502 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28503 285042023-08-28 John Baldwin <jhb@FreeBSD.org> 28505 28506 gdb: Use x86_xstate_layout to parse the XSAVE extended state area. 28507 All of the tables describing the offsets of individual registers for 28508 XSAVE state components now hold relative offsets rather than absolute 28509 offsets. Some tables (those for MPX registers and ZMMH registers) had 28510 to be split into separate tables as they held entries that spanned 28511 multiple state components. 28512 28513 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28514 285152023-08-28 John Baldwin <jhb@FreeBSD.org> 28516 28517 gdb: Support XSAVE layouts for the current host in the Linux x86 targets. 28518 Note that this uses the CPUID instruction to determine the total size 28519 of the XSAVE register set. If there is a way to fetch the register set 28520 size using ptrace that would probably be better. 28521 28522 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28523 285242023-08-28 John Baldwin <jhb@FreeBSD.org> 28525 28526 gdb: Update x86 Linux architectures to support XSAVE layouts. 28527 Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding 28528 x86_xsave_layout as well as xcr0 using the size of an existing 28529 NT_X86_XSTATE core dump to determine the offsets via 28530 i387_guess_xsave_layout. Use this to add an implementation of 28531 gdbarch_core_xfer_x86_xsave_layout. 28532 28533 Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register 28534 set. 28535 28536 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28537 285382023-08-28 John Baldwin <jhb@FreeBSD.org> 28539 28540 gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets. 28541 Use the CPUID instruction to fetch the offsets of supported state 28542 components. 28543 28544 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28545 285462023-08-28 John Baldwin <jhb@FreeBSD.org> 28547 28548 gdb: Update x86 FreeBSD architectures to support XSAVE layouts. 28549 Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding 28550 x86_xsave_layout as well as xcr0 using the size of an existing 28551 NT_X86_XSTATE core dump to determine the offsets via 28552 i387_guess_xsave_layout. Use this to add an implementation of 28553 gdbarch_core_xfer_x86_xsave_layout. 28554 28555 Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register 28556 set and only fetch/store the register set if this size is non-zero. 28557 28558 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28559 285602023-08-28 John Baldwin <jhb@FreeBSD.org> 28561 28562 x86 nat: Add helper functions to save the XSAVE layout for the host. 28563 x86_xsave_length returns the total length of the XSAVE state area 28564 standard format as queried from CPUID. 28565 28566 x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE 28567 extended regions from the running host. The total length of the XSAVE 28568 state area can either be supplied by the caller if known (e.g. from 28569 FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host 28570 using x86_xsave_length. 28571 28572 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28573 285742023-08-28 John Baldwin <jhb@FreeBSD.org> 28575 28576 nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count. 28577 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28578 285792023-08-28 John Baldwin <jhb@FreeBSD.org> 28580 28581 core: Support fetching x86 XSAVE layout from architectures. 28582 Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout 28583 structure from a core file. 28584 28585 Current OS's do not export the offsets of XSAVE state components in 28586 core dumps, so provide an i387_guess_xsave_layout helper function to 28587 set offsets based on known combinations of XCR0 masks and total state 28588 sizes. Eventually when core dumps do contain this information this 28589 function should only be used as a fall back for older core dumps. 28590 28591 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28592 285932023-08-28 John Baldwin <jhb@FreeBSD.org> 28594 28595 gdb: Store an x86_xsave_layout in i386_gdbarch_tdep. 28596 This structure is fetched from the current target in i386_gdbarch_init 28597 via a new "fetch_x86_xsave_layout" target method. 28598 28599 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28600 286012023-08-28 John Baldwin <jhb@FreeBSD.org> 28602 Aleksandar Paunovic <aleksandar.paunovic@intel.com> 28603 28604 x86: Add an x86_xsave_layout structure to handle variable XSAVE layouts. 28605 The standard layout of the XSAVE extended state area consists of three 28606 regions. The first 512 bytes (legacy region) match the layout of the 28607 FXSAVE instruction including floating point registers, MMX registers, 28608 and SSE registers. The next 64 bytes (XSAVE header) contains a header 28609 with a fixed layout. The final region (extended region) contains zero 28610 or more optional state components. Examples of these include the 28611 upper 128 bits of YMM registers for AVX. 28612 28613 These optional state components generally have an 28614 architecturally-fixed size, but they are not assigned architectural 28615 offsets in the extended region. Instead, processors provide 28616 additional CPUID leafs describing the size and offset of each 28617 component in the "standard" layout for a given CPU. (There is also a 28618 "compact" format which uses an alternate layout, but existing OS's 28619 currently export the "standard" layout when exporting XSAVE data via 28620 ptrace() and core dumps.) 28621 28622 To date, GDB has assumed the layout used on current Intel processors 28623 for state components in the extended region and hardcoded those 28624 offsets in the tables in i387-tdep.c and i387-fp.cc. However, this 28625 fails on recent AMD processors which use a different layout. 28626 Specifically, AMD Zen3 and later processors do not leave space for the 28627 MPX register set in between the AVX and AVX512 register sets. 28628 28629 To rectify this, add an x86_xsave_layout structure which contains the 28630 total size of the XSAVE extended state area as well as the offset of 28631 each known optional state component. 28632 28633 Subsequent commits will modify XSAVE parsing in both gdb and gdbserver 28634 to use x86_xsave_layout. 28635 28636 Approved-By: Simon Marchi <simon.marchi@efficios.com> 28637 286382023-08-28 Tom Tromey <tromey@adacore.com> 28639 28640 Use sect_offset_str in cooked_index::dump 28641 Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and 28642 Andreas Schwab pointed out that gdb already has sect_offset_str. This 28643 patch applies both these observations. 28644 286452023-08-28 Mark Wielaard <mark@klomp.org> 28646 28647 Use hex_string in gdb/coffread.c instead of PRIxPTR 28648 The getsymname function uses PRIxPTR to print and uintptr_t value in 28649 an error message. Use hex_string instead. 28650 28651 Approved-By: Tom Tromey <tom@tromey.com> 28652 286532023-08-28 Tom de Vries <tdevries@suse.de> 28654 28655 [gdb/symtab] Handle self-reference in inherit_abstract_dies 28656 Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a 28657 self-referencing DIE: 28658 ... 28659 <2><91dace>: Abbrev Number: 405 (DW_TAG_label) 28660 <91dad0> DW_AT_abstract_origin: <0x91dace> 28661 ... 28662 28663 When encountering the self-reference DIE in inherit_abstract_dies we loop 28664 following the abstract origin, effectively hanging gdb. 28665 28666 Fix this by handling self-referencing DIEs in the loop in 28667 inherit_abstract_dies. 28668 28669 Tested on x86_64-linux. 28670 28671 Approved-By: Tom Tromey <tom@tromey.com> 28672 28673 PR symtab/30799 28674 https://sourceware.org/bugzilla/show_bug.cgi?id=30799 28675 286762023-08-28 Alan Modra <amodra@gmail.com> 28677 28678 COFF swap_aux_in 28679 A low level function like coff_swap_aux_in really has no business 28680 concatenating multiple auxents for the old PE multi-aux scheme of 28681 handling long file names. In doing so, it assumes multiple internal 28682 auxent buffers are available, which they are not in most calls to 28683 bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB. Buffer 28684 overflow fun. Concatenating multiple auxents belongs at a higher 28685 level. 28686 28687 This required some changes to coff_get_normalized_symtab, which now 28688 uses the external auxents to access the concatenated file name. 28689 (Internal auxents are larger than the x_fname array, so the pieces of 28690 the file name are not adjacent as they are in the external auxents.) 28691 28692 * coffswap.h (coff_swap_aux_in): Do not write more than one 28693 internal auxent. 28694 * coffcode.h (coff_bigobj_swap_aux_in): Likewise. 28695 * coffgen.c (coff_get_normalized_symtab): Normalize strings 28696 after swapping in each symbol so that external auxents are 28697 available. Use external auxents for multi-aux long file 28698 names. Formatting. Wrap long lines. Remove excess parens 28699 and unnecessary casts. Don't zalloc when only the string 28700 terminator needs zeroing, and memcpy rather than strncpy. 28701 Delete unnecessary sanity check with unsigned _n_offset. 28702 Return with failure if debug section can't be read, to avoid 28703 trying to read it multiple times. Correct sanity check 28704 against debug section size. 28705 287062023-08-28 Alan Modra <amodra@gmail.com> 28707 28708 Re: comdat_hash memory leaks 28709 I missed another field that needs freeing. Also, oss-fuzz found a 28710 case with a C_FILE sym using multiple auxents for a long file name 28711 which overflowed the single auxent buffer. I'm going to fix that 28712 problem in swap_aux_in too, but we may as well avoid it here too, 28713 saving unnecessary work. 28714 28715 * coffcode.h (comdat_delf): Free comdat_name. 28716 (fill_comdat_hash): Only look at symbols with one auxent. 28717 287182023-08-28 Tom de Vries <tdevries@suse.de> 28719 28720 [gdb/testsuite] Add xfail in gdb.cp/subtypes.exp 28721 When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into: 28722 ... 28723 FAIL: gdb.cp/subtypes.exp: ptype main::Foo 28724 FAIL: gdb.cp/subtypes.exp: ptype main::Bar 28725 FAIL: gdb.cp/subtypes.exp: ptype main::Baz 28726 FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo 28727 FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar 28728 FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz 28729 FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo 28730 FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar 28731 FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz 28732 ... 28733 28734 The problem is gcc PR debug/55541, which generates a superfluous 28735 DW_TAG_lexical_block. 28736 28737 Add a corresponding xfail. 28738 28739 Tested on x86_64-linux. 28740 287412023-08-28 Tom de Vries <tdevries@suse.de> 28742 28743 [gdb/testsuite] Refactor gdb.cp/subtypes.exp 28744 Make test-case gdb.cp/subtypes.exp less repetitive by using foreach. 28745 28746 Tested on x86_64-linux. 28747 287482023-08-28 Tom de Vries <tdevries@suse.de> 28749 28750 [gdb/testsuite] Handle gdb.cp/*.exp with older compiler 28751 When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation 28752 failures due to the test-cases requiring c++11 and the compiler defaulting 28753 to less than that. 28754 28755 Fix this by compiling with -std=c++11. 28756 28757 This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to 28758 gcc PR debug/16063, so xfail those. 28759 28760 Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to 28761 prevent compilation failure. 28762 28763 Tested on x86_64-linux. 28764 287652023-08-28 YunQiang Su <yunqiang.su@cipunited.com> 28766 28767 MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets 28768 Following the arrangement in GCC select a 64-bit ABI by default, either 28769 n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as 28770 with the corresponding `mips64*-*-linux*' targets. 28771 28772 Gold/MIPS: Add mips64*/mips64*el triple support 28773 Use targ_size=64 and targ_extra_size=32 28774 28775 Gold/MIPS: Add targ_extra_size=64 for mips32 triples 28776 So we can enable 64bit ELF support for MIPS32 toolchain. 28777 28778 Gold/MIPS: Drop mips*le/mips*el* triple pattern 28779 Only mips*el triples are supported by binutils. The mips*le 28780 or mips*el* may cause some problem with other components of 28781 binutils, since they will consider them as big endian. 28782 287832023-08-28 YunQiang Su <yunqiang.su@cipunited.com> 28784 28785 Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian 28786 EM_MIPS_RS3_LE has been deprecated quite long ago, and in fact 28787 most of current LE ELF files are using EM_MIPS. 28788 28789 This problem didn't make some trouble for us, is due to that 28790 gold is a linker, and all of the inputs to it has right EM values. 28791 287922023-08-28 YunQiang Su <yunqiang.su@cipunited.com> 28793 28794 Gold: Add targ_extra_little_endian to configure.ac 28795 This option will be used by architectures which is big endian 28796 by default, while little-endian support is also needed. 28797 28798 Mips(eb) ports are the examples. 28799 288002023-08-28 GDB Administrator <gdbadmin@sourceware.org> 28801 28802 Automatic date update in version.in 28803 288042023-08-27 Alan Modra <amodra@gmail.com> 28805 28806 PE dos_message 28807 I was looking at dos_message and wondering why we have H_PUT_32 28808 in _bfd_XXi_only_swap_filehdr_out but no H_GET_32 in pe_bfd_object_p. 28809 On a big-endian machine this would result in scrambling the code and 28810 strings constained in dos_message. Rather than fix the lack of 28811 H_GET_32 in pe_bfd_object_p, I decided it doesn't make sense to store 28812 dos_message internally as an array of ints. 28813 28814 include/ 28815 * coff/internal.h (struct internal_extra_pe_filehdr): Make 28816 dos_message a char array. 28817 * coff/msdos.h (struct external_DOS_hdr): Flatten dos_message. 28818 * coff/pe.h (struct external_PEI_filehdr): Likewise. 28819 bfd/ 28820 * libcoff-in.h (struct pe_tdata): Make dos_message a char array. 28821 * libcoff.h: Regenerate. 28822 * peXXigen.c (_bfd_XXi_only_swap_filehdr_out): memcpy dos_message 28823 to output. 28824 * peicode.h (pe_mkobject): Don't memset already zeroed pe_opthdr. 28825 Tidy allocation of tdata.pe_obj_data. Set up dos_message from.. 28826 (default_dos_message): ..this. New static array. 28827 288282023-08-27 Alan Modra <amodra@gmail.com> 28829 28830 comdat_hash memory leaks 28831 Entries added to the hash table with bfd_malloc ought to be freed when 28832 the hash table is deleted. This patch adds the necessary del_f to the 28833 htab_create call, and delays creating the table until an 28834 IMAGE_SCN_LNK_COMDAT symbol is read. 28835 28836 * peicode.h (pe_mkobject): Move comdat_hash creation.. 28837 (htab_hash_flags, htab_eq_flags): ..and these support functions.. 28838 * coffcode.h (handle_COMDAT): ..to here, renaming support to 28839 (comdat_hashf, comdat_eqf): ..this and adding.. 28840 (comdat_delf): ..this new function. 28841 288422023-08-27 Alan Modra <amodra@gmail.com> 28843 28844 Confusion in coff_object_cleanup 28845 A bfd_cleanup function needs to run when only tdata is correct for the 28846 bfd. The xvec may have changed during bfd_check_format and thus the 28847 flavour may be incorrect. The format won't have changed but checking 28848 is superfluous. (In contrast to _bfd_free_cached_info or 28849 _close_and_cleanup where we do need to check things.) 28850 28851 Not getting this correct leaked comdat_hash. 28852 28853 Also, pe_ILF_cleanup ought to call coff_object_cleanup as do all PE 28854 files. 28855 28856 * coffgen.c (coff_object_cleanup): Don't check bfd flavour or 28857 format. 28858 * peicode.h (pe_ILF_cleanup): Call coff_object_cleanup. 28859 288602023-08-27 Alan Modra <amodra@gmail.com> 28861 28862 sanity check n_numaux 28863 Sanity check aux entries used by PE to extend a C_FILE name. See 28864 coffswap.h:coff_swap_aux_in. The existing check only catered for 28865 n_numaux == 1. 28866 28867 * coffcode.h (fill_comdat_hash): Properly sanity check n_numaux. 28868 Formatting. 28869 (handle_COMDAT): Formatting. 28870 288712023-08-27 Alan Modra <amodra@gmail.com> 28872 28873 Re: ld STRINGIFY 28874 Oops there was a reference to the old name. 28875 28876 * emultempl/aix.em: Use stringify.sed. 28877 288782023-08-27 GDB Administrator <gdbadmin@sourceware.org> 28879 28880 Automatic date update in version.in 28881 288822023-08-26 Tom Tromey <tom@tromey.com> 28883 28884 Simplify definition of GUILE 28885 This patch sets GUILE to just plain 'guile'. 28886 28887 In the distant ("devo") past, the top-level build did support building 28888 Guile in-tree. However, I don't think this really works any more. 28889 For one thing, there are no build dependencies on it, so there's no 28890 guarantee it would actually be built before the uses. 28891 28892 This patch also removes the use of "-s" as an option to cgen scheme 28893 scripts. With my latest patch upstream, this is no longer needed. 28894 28895 After the upstream changes, either Guile 2 or Guile 3 will work, with 28896 or without the compiler enabled. 28897 28898 2023-08-24 Tom Tromey <tom@tromey.com> 28899 28900 * cgen.sh: Don't pass "-s" to cgen. 28901 * Makefile.in: Rebuild. 28902 * Makefile.am (GUILE): Simplify. 28903 289042023-08-26 Tom Tromey <tom@tromey.com> 28905 28906 Use get_frame_address_in_block in print_frame 28907 The author of 'mold' pointed out that with a certain shared library, 28908 gdb would fail to find the shared library's name in 'bt'. 28909 28910 The function in question appeared at the end of the .so's .text 28911 segment and ended with a call to 'abort'. 28912 28913 This turned out to be a classic case of calling get_frame_pc when 28914 get_frame_address_in_block is needed -- the former will be off-by-one 28915 for purposes of finding the enclosing function or shared library. 28916 28917 The included test fails without the patch on my system. However, I 28918 imagine it can't be assumed to reliably fail. Nevertheless it seemed 28919 worth doing. 28920 28921 Regression tested on x86-64 Fedora 38. 28922 28923 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074 28924 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 28925 289262023-08-26 Alan Modra <amodra@gmail.com> 28927 28928 opcodes i386 and ia64 gen file warnings 28929 i386: warning: format ‘%u’ expects argument of type ‘unsigned int’, 28930 but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=] 28931 ia64: warning: ignoring return value of ‘fgets’ 28932 28933 * i386-gen.c (process_i386_opcodes): Correct format string. 28934 * ia64-gen.c (load_insn_classes, load_depfile): Don't ignore 28935 fgets return value. 28936 289372023-08-26 Alan Modra <amodra@gmail.com> 28938 28939 ld STRINGIFY 28940 Delete support for old compilers that don't support string 28941 concatentation. 28942 28943 * Makefile.am (stringify.sed): Delete rule. 28944 (GEN_DEPENDS, DISTCLEANFILES): Adjust. 28945 * configure.ac (STRINGIFY): Delete. 28946 * emultempl/beos.em: Use stringify.sed from srcdir. 28947 * emultempl/elf.em: Likewise. 28948 * emultempl/generic.em: Likewise. 28949 * emultempl/msp430.em: Likewise. 28950 * emultempl/pdp11.em: Likewise. 28951 * emultempl/pe.em: Likewise. 28952 * emultempl/pep.em: Likewise. 28953 * emultempl/stringify.sed: Renamed from.. 28954 * emultempl/astring.sed: ..this. 28955 * emultempl/ostring.sed: Delete. 28956 * Makefile.in: Regenerate. 28957 * configure: Regenerate. 28958 289592023-08-26 GDB Administrator <gdbadmin@sourceware.org> 28960 28961 Automatic date update in version.in 28962 289632023-08-26 Alan Modra <amodra@gmail.com> 28964 28965 ld .deps/*.Pc files 28966 This patch gets rid of the individual rules including the .Pc 28967 dependency files made while generating e*.c files, replacing them with 28968 a fancy GNU make pattern include. I've also moved creation of 28969 ldscripts to the makefile since it is possible to run more than one 28970 genscripts at once, resulting in "ldscripts: File exists" messages. 28971 28972 * Makefile.am: Replace individual include of *.Pc dependency 28973 files with one pattern rule. 28974 (.Pc): New dummy rule. 28975 (ldscripts/stamp): New rule. 28976 (GEN_DEPENDS): Add ldscripts/stamp. 28977 (install-data-local): Exclude ldscripts/stamp from install. 28978 * genscripts.sh: Don't make ldscripts dir. 28979 * Makefile.in: Regenerate. 28980 289812023-08-25 Mark Wielaard <mark@klomp.org> 28982 28983 Fix gdb/coffread.c build on 32bit architectures 28984 The getsymname function tries to emit an error using %ld for an 28985 uintptr_t argument. Use PRIxPTR instead. Which works on any architecture 28986 for uintptr_t. 28987 289882023-08-25 Keith Seitz <keiths@redhat.com> 28989 28990 Verify COFF symbol stringtab offset 28991 This patch addresses an issue with malformed/fuzzed debug information that 28992 was recently reported in gdb/30639. That bug specifically deals with 28993 an ASAN issue, but the reproducer provided by the reporter causes a 28994 another failure outside of ASAN: 28995 28996 $ ./gdb --data-directory data-directory -nx -q UAF_2 28997 Reading symbols from /home/keiths/UAF_2... 28998 28999 29000 Fatal signal: Segmentation fault 29001 ----- Backtrace ----- 29002 0x59a53a gdb_internal_backtrace_1 29003 ../../src/gdb/bt-utils.c:122 29004 0x59a5dd _Z22gdb_internal_backtracev 29005 ../../src/gdb/bt-utils.c:168 29006 0x786380 handle_fatal_signal 29007 ../../src/gdb/event-top.c:889 29008 0x7864ec handle_sigsegv 29009 ../../src/gdb/event-top.c:962 29010 0x7ff354c5fb6f ??? 29011 0x611f9a process_coff_symbol 29012 ../../src/gdb/coffread.c:1556 29013 0x611025 coff_symtab_read 29014 ../../src/gdb/coffread.c:1172 29015 0x60f8ff coff_read_minsyms 29016 ../../src/gdb/coffread.c:549 29017 0x60fe4b coff_symfile_read 29018 ../../src/gdb/coffread.c:698 29019 0xbde0f6 read_symbols 29020 ../../src/gdb/symfile.c:772 29021 0xbde7a3 syms_from_objfile_1 29022 ../../src/gdb/symfile.c:966 29023 0xbde867 syms_from_objfile 29024 ../../src/gdb/symfile.c:983 29025 0xbded42 symbol_file_add_with_addrs 29026 ../../src/gdb/symfile.c:1086 29027 0xbdf083 _Z24symbol_file_add_from_bfdRKN3gdb7ref_ptrI3bfd18gdb_bfd_ref_policyEEPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaISC_EES8_I12objfile_flagEP7objfile 29028 ../../src/gdb/symfile.c:1166 29029 0xbdf0d2 _Z15symbol_file_addPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaIS5_EES1_I12objfile_flagE 29030 ../../src/gdb/symfile.c:1179 29031 0xbdf197 symbol_file_add_main_1 29032 ../../src/gdb/symfile.c:1203 29033 0xbdf13e _Z20symbol_file_add_mainPKc10enum_flagsI16symfile_add_flagE 29034 ../../src/gdb/symfile.c:1194 29035 0x90f97f symbol_file_add_main_adapter 29036 ../../src/gdb/main.c:549 29037 0x90f895 catch_command_errors 29038 ../../src/gdb/main.c:518 29039 0x9109b6 captured_main_1 29040 ../../src/gdb/main.c:1203 29041 0x910fc8 captured_main 29042 ../../src/gdb/main.c:1310 29043 0x911067 _Z8gdb_mainP18captured_main_args 29044 ../../src/gdb/main.c:1339 29045 0x418c71 main 29046 ../../src/gdb/gdb.c:39 29047 --------------------- 29048 A fatal error internal to GDB has been detected, further 29049 debugging is not possible. GDB will now terminate. 29050 29051 This is a bug, please report it. For instructions, see: 29052 <https://www.gnu.org/software/gdb/bugs/>. 29053 29054 Segmentation fault (core dumped) 29055 29056 The issue here is that the COFF offset for the fuzzed symbol's 29057 name is outside the string table. That is, the offset is greater 29058 than the actual string table size. 29059 29060 coffread.c:getsymname actually contains a FIXME about this, and that's 29061 what I've chosen to address to fix this issue, following what is done 29062 in the DWARF reader: 29063 29064 $ ./gdb --data-directory data-directory -nx -q UAF_2 29065 Reading symbols from /home/keiths/UAF_2... 29066 COFF Error: string table offset (256) outside string table (length 0) 29067 (gdb) 29068 29069 Unfortunately, I haven't any idea how else to test this patch since 29070 COFF is not very common anymore. GCC removed support for it five 29071 years ago with GCC 8. 29072 290732023-08-25 John Baldwin <jhb@FreeBSD.org> 29074 29075 Update FreeBSD system calls for the upcoming 14.0-RELEASE 29076 This matches the current set of system calls at the start of the 29077 stable/14 branch (commit 29a16ce065dbc28bc9e87c9bfadb08bb58b137e4). 29078 290792023-08-25 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 29080 29081 Fix for call feature having 9th function parameter and beyond corrupt values. 29082 In AIX the first eight function parameters are stored from R3 to R10. 29083 If there are more than eight parameters in a function then we store the 9th parameter onwards in the stack. 29084 While doing so, in 64 bit mode the words were not zero extended and was coming like 32 bit mode. 29085 This patch is a fix to the same. 29086 29087 Fix 64 bit red zone frame size in AIX 29088 290892023-08-25 Jan Beulich <jbeulich@suse.com> 29090 29091 bfd: correct relocation handling for objcopy COFF -> ELF 29092 While documented to not be reliable, it is still odd for objcopy to 29093 silently produce bad output when converting COFF/PE object files to ELF 29094 ones. The issue there is that relocation addends all are screwed up by 29095 subtracting the symbol's section offset. In the COFF/PE world, to my 29096 knowledge, section contents stores the addends alone, not the result of 29097 symbol value plus addend. Hence the compensation talked about in a 29098 comment ahead of the sole use site of CALC_ADDEND() may need to account 29099 for the VMA (which is always zero for object files anyway), but not for 29100 the symbol value. 29101 29102 The coff-sh.c adjustment is based upon guessing that behavior there is 29103 the same. Note also how coff-aarch64.c short-circuits CALC_ADDEND() 29104 altogether, which may suggest that a much simpler macro might do for the 29105 COFF_WITH_PE case in the three arch-specific files touched here. 29106 29107 For (at least) Arm/WinCE this actually results in more appropriate 29108 objdump output as well, as can be seen in the one testcase which has its 29109 expectations adjusted (the generated binary doesn't change). 29110 291112023-08-25 Jan Beulich <jbeulich@suse.com> 29112 29113 gas/ELF: widen use of $dump_opts in testsuite 29114 Rather than special-casing rx-*-* for section30, force use of 29115 conventional section names uniformly. By further passing $dump_opts to 29116 a few more tests, a number of xfail-s (and one notarget) can be 29117 eliminated (some of which had wrong justifications in associated 29118 comments anyway). Note that section7 and section15 need to be left 29119 alone: The harness fiddling with section names there didn't help before 29120 and is getting in the way now. For section12b, section16b, and most of 29121 the Dwarf tests nothing changes. Interestingly by passing $dump_opts 29122 the need to xfail section11 for LoongArch and RISC-V also goes away. 29123 291242023-08-25 Jan Beulich <jbeulich@suse.com> 29125 29126 gas/ELF: allow "inheriting" section attributes and type 29127 While --sectname-subst is nice, it isn't enough to e.g. mimic 29128 -f{function,data}-sections in assembly code, when such use is to be 29129 optional (e.g. dependent upon some configuration setting). 29130 29131 Assign meaning to '+' and '-' as section attribute letters, allowing 29132 to inherit the prior section's attributes (and possibly type) along 29133 with adding or removing some. Note that documenting the interaction 29134 with '?' as undefined is a precautionary measure. 29135 29136 While touching the function invocation, stop using |= on the result of 29137 obj_elf_parse_section_letters(): "attr" is firmly zero ahead of the 29138 call. 29139 291402023-08-25 Alan Modra <amodra@gmail.com> 29141 29142 Use GNU make pattern rule in ld Makefile 29143 Use the pattern rule in a comment from commit 77ac17b8453f. 29144 29145 * Makefile.am (run-genscripts): Delete. Use pattern rule 29146 e%.c instead. 29147 * Makefile.in: Regenerate. 29148 291492023-08-25 Alan Modra <amodra@gmail.com> 29150 29151 som: buffer overflow writing strings 29152 Code in som_write_symbol_strings neglected to allow for padding, which 29153 can result in a buffer overflow. It also used xrealloc, which we're 29154 not supposed to use in libbfd because libbfd isn't supposed to call 29155 exit. Also a realloc is perhaps not a good idea when none of the 29156 buffer contents are needed, so replace with free, bfd_malloc. There 29157 were three copies of the string handling code, so rather than fix them 29158 all I've extracted them to a function. This necessitated making one 29159 of the fields in struct som_symbol unsigned. 29160 29161 * som.c (add_string): New function. 29162 (som_write_space_strings, som_write_symbol_strings): Use it. 29163 * som.h (som_symbol_type <stringtab_offset>): Make unsigned. 29164 291652023-08-25 Alan Modra <amodra@gmail.com> 29166 29167 PR30794, PowerPC gold: internal error in add_output_section_to_load 29168 Caused by commit 5a97377e5513, specifically this code added to 29169 Target_powerpc::do_relax 29170 + if (parameters->options().output_is_position_independent()) 29171 + this->rela_dyn_size_ 29172 + = this->rela_dyn_section(layout)->current_data_size(); 29173 29174 The problem here is that if .rela.dyn isn't already created then the 29175 call to rela_dyn_section creates it, and as this comment in 29176 Target_powerpc::do_finalize_sections says: 29177 // Annoyingly, we need to make these sections now whether or 29178 // not we need them. If we delay until do_relax then we 29179 // need to mess with the relaxation machinery checkpointing. 29180 We can't be creating sections in do_relax. 29181 29182 PR 30794 29183 * powerpc.cc (Target_powerpc::do_relax): Only set rela_dyn_size_ 29184 for size == 64, and assert that rela_dyn_ already exists. 29185 Tidy code setting plt_thread_safe, which also only needs to be 29186 set when size == 64 for ELFv1. 29187 291882023-08-25 GDB Administrator <gdbadmin@sourceware.org> 29189 29190 Automatic date update in version.in 29191 291922023-08-24 Lancelot SIX <lancelot.six@amd.com> 29193 29194 gdb/solib-rocm: Detect SO for unsupported AMDGPU device 29195 It is possible to debug a process which uses unsupported AMDGPU devices. 29196 In such scenario, we can still use librocm-dbgapi.so to attach to the 29197 process and complete the runtime activation sequence. 29198 29199 However, when listing shared objects loaded on the AMDGPU devices, we 29200 might list SOs loaded on the unsupported devices. If such SO is 29201 seen, one of two things can happen. 29202 29203 First, if the arch of this device is unknown to BFD, 29204 'gdbarch_find_by_info (gdbarch_info info)' will return the gdbarch 29205 matching default_bfd_arch. As a result, 29206 rocm_solib_relocate_section_addresses will delegate the relocation 29207 operation to svr4_so_ops.relocate_section_addresses, but this makes no 29208 sense: this code object was not loaded by the system loader. 29209 29210 The second case is if BFD knows the micro-architecture of the device, 29211 but dbgapi does not support it. In such case, gdbarch_info_fill will 29212 successfully identify an amdgcn architecture (bfd_arch_amdgcn). From 29213 there, gdbarch_find_by_info calls amdgpu_gdbarch_init which will fail to 29214 query arch specific details from dbgapi and subsequently fail to 29215 initialize the gdbarch object. As a result, gdbarch_find_by_info 29216 returns nullptr, which will down the line cause some "gdb_assert 29217 (gdbarch != nullptr)" assertion failures. 29218 29219 This patch proposes to add a check in rocm_solib_bfd_open to ensure that 29220 the architecture associated with the code object to open is fully 29221 supported by both BFD and amd-dbgapi, and error-out otherwise. 29222 29223 Change-Id: Ica97ab7cba45e4944b77d3080c54c1038aaeda54 29224 Approved-By: Pedro Alves <pedro@palves.net> 29225 292262023-08-24 Tom de Vries <tdevries@suse.de> 29227 29228 [gdb/build] Return gdb::array_view in thread_info_to_thread_handle 29229 In remote_target::thread_info_to_thread_handle we return a copy: 29230 ... 29231 gdb::byte_vector 29232 remote_target::thread_info_to_thread_handle (struct thread_info *tp) 29233 { 29234 remote_thread_info *priv = get_remote_thread_info (tp); 29235 return priv->thread_handle; 29236 } 29237 ... 29238 29239 Fix this by returning a gdb::array_view instead: 29240 ... 29241 gdb::array_view<const gdb_byte> 29242 remote_target::thread_info_to_thread_handle (struct thread_info *tp) 29243 ... 29244 29245 Tested on x86_64-linux. 29246 29247 This fixes the build when building with -std=c++20. 29248 29249 Approved-By: Pedro Alves <pedro@palves.net> 29250 292512023-08-24 Paul Iannetta <piannetta@kalrayinc.com> 29252 29253 kvx: fix kvx_reassemble_bundle index 8 out of bounds 29254 opcodes/ 29255 * kvx-dis.c (print_insn_kvx): Change the loop condition so that 29256 wordcount is always less than KVXMAXBUNDLEWORDS. 29257 (decode_prologue_epilogue_bundle): Likewise. 29258 292592023-08-24 Guinevere Larsen <blarsen@redhat.com> 29260 29261 gdb/testsuite: Multiple improvements for gdb.reverse/insn-reverse.exp 29262 This commits tackles 2 problems in the test 29263 gdb.reverse/insn-reverse.exp. They are, broadly: flawed logic when an 29264 unexpected error occurs, and badly formed asm expressions. 29265 29266 For the first, what happens is that if the inferior stops progressing 29267 for some reason, the test will emit an UNSUPPORTED and continue testing 29268 by reversing from the current location and checking all registers for 29269 every instruction. However, due to how the outputs are indexed in the 29270 test, this early exit will cause most of the subsequent tests to be 29271 de-synced and will emit many unrelated failures. 29272 29273 This commit changes the UNSUPPORTED for a FAIL, since the test has in 29274 fact failed to record the execution of the whole function, and 29275 decrements the recorded instruction count by one so that the indexes are 29276 in sync once more. 29277 29278 At the time of committing, this reduces the amount of failures when 29279 testing with clang-15 from around 150 to 2, and correctly identifies 29280 where the issue lies. 29281 29282 The second problem is in how the asm statements in the *-x86.c file 29283 are written. As an example, let's examine the following line: 29284 29285 __asm__ volatile ("rdrand %%ebp;" : "=r" (number)); 29286 29287 This statement says that number is being used as the output variable, 29288 but is not indicating which registers were clobbered so that the 29289 compiler is able to properly output. GCC decides to just not save 29290 anything, whereas clang assumes that the output is in %rax, and writes 29291 it to the variable. This hid the problem that any compiler is not good 29292 at dealing with asm statements that change the rbp register. It can be 29293 seen more explicitly by informing gcc that rbp has been clobbered like 29294 so: 29295 29296 __asm__ volatile ("rdrand %%ebp;" : "=r" (number) : : "%ebp"); 29297 29298 This statement gets compiled into the following assembly: 29299 rdrandl %ebp 29300 movl %eax, -4(%rbp) 29301 29302 Which is clearly using the incorrect rbp to find the memory location of 29303 the variable. Since the test only exercises GDB's ability to record the 29304 register changes, this commit removes the output to memory. 29305 29306 Finally, correctly informing the compiler of clobbered registers 29307 makes gcc throw an error that the rsp is no longer usable at the end of 29308 the function. To avoid that, this commit compresses the 3 asm statements 29309 that would save, change and reset registers into a single asm statement. 29310 29311 Approved-By: Tom Tromey <tom@tromey.com> 29312 293132023-08-24 Guinevere Larsen <blarsen@redhat.com> 29314 29315 gdb/testsuite: fix testing gdb.reverse/step-reverse.exp with clang 29316 When testing using reverse-stepi to fully step through a function, the 29317 code checks for an infinite loop by seeing if we land on the line that 29318 contains the return statement multiple times. This assumption only works 29319 if there is only one instruction associated with that line, which is how 29320 GCC handles line information, but other compilers may handle it differently. 29321 Clang-15, for instance, associates 6. Because of this, the inferior used 29322 to get seriously out of sync with the test expectations, and result in 13 29323 spurious failures. The same issue occurs with gdb.reverse/step-precsave.exp. 29324 29325 This commit changes the test so that we check for PC instead of line 29326 number. The test still only happens when the same line is detected, to 29327 simplify the resulting log. With this change, no new failures are 29328 emitted when using clang. 29329 29330 Approved-By: Tom Tromey <tom@tromey.com> 29331 293322023-08-24 Guinevere Larsen <blarsen@redhat.com> 29333 29334 gdb/testsuite: fix gdb.reverse/solib-*.exp tests when using clang 29335 The tests gdb.reverse/solib-precsave.exp and solib-reverse.exp have the 29336 assumption that line tables will have an entry for the closing } in a 29337 function. Not all compiles do this, one example being clang. To fix 29338 this, this commit changes the function in shr2.c to have multiple lines, 29339 and the test to accept either line as a correct step location. 29340 29341 To properly re-sync the inferiors, the function repeat_cmd_until had to 29342 be slightly changed to work with empty "current locations", so that we 29343 are able to step through multiple lines. 29344 29345 This also changes the annotations used to determine the breakpoint 29346 locations in solib-reverse.c, adding a simple variable assignment right 29347 before the return statement. This way GDB will not set a breakpoint in 29348 the closing } line. 29349 29350 Approved-By: Tom Tromey <tom@tromey.com> 29351 293522023-08-24 Guinevere Larsen <blarsen@redhat.com> 29353 29354 gdb/testsuite: Fix many errors in gdb.reverse with clang 29355 Clang does not add line information for lines that only contain a 29356 closing } in functions. Many tests in the gdb.reverse folder set a 29357 breakpoint in that line, but don't seem to use information available 29358 after the return statement is executed, so this commit moves the 29359 breakpoint to the previous line, where the return statement is. 29360 29361 Approved-By: Tom Tromey <tom@tromey.com> 29362 293632023-08-24 Alan Modra <amodra@gmail.com> 29364 29365 kvx: workaround gcc-4.5 bug 29366 kvx-dis.c:1078:10: error: missing initializer 29367 kvx-dis.c:1078:10: error: (near initialization for 'dec.nb_ops') 29368 29369 * kvx-dis.c (print_insn_kvx): Init dec with memset. 29370 (decode_prologue_epilogue_bundle): Likewise. 29371 293722023-08-24 Oleg Tolmatcev <oleg.tolmatcev@gmail.com> 29373 29374 optimize handle_COMDAT 29375 293762023-08-24 Alan Modra <amodra@gmail.com> 29377 29378 nds32, sh, kvx: DT_JMPREL/DT_PLTRELSZ 29379 As commit fa4f2d46f9 did for x86, there a few other targets that 29380 wrongly use the output section rather than the dynamic section for 29381 DT_JMPREL and others. 29382 29383 * elfnn-kvx.c (elfNN_kvx_finish_dynamic_sections): Use input 29384 section for DT_JMPREL. 29385 * elf32-sh.c (sh_elf_finish_dynamic_sections): Use input 29386 section for DT_JMPREL and DT_PLTRELSZ. 29387 * elf32-nds32.c (nds32_elf_finish_dynamic_sections): Likewise, 29388 and for DT_PLTGOT and when adjusting DT_RELA. 29389 293902023-08-24 Stafford Horne <shorne@gmail.com> 29391 29392 sim: or1k: Eliminate dangerous RWX load segments 29393 This fixes test failures caused by the new linker warning which report: 29394 29395 ./ld/ld-new: warning: load.S.x has a LOAD segment with RWX permissions 29396 29397 Fix this by splitting the linker MEMORY into ram and rom to avoid 29398 generating RWX sections. This required tests to be adjusted to fix 29399 issues with the move. Namely: 29400 29401 - fpu tests: were incorrectly using l.ori with ha(anchor) which now 29402 that we pushed the anchor up in memory it exposes the bug. Update 29403 to used the correct l.movhi instruction instead. 29404 - adrp test: the test reports ram offset addresses, now that we have 29405 moved memory layout around a bit I adjusted the test output. Some 29406 padding is added before pi to show that the actual address of pi and 29407 the adrp page offset are not the same. 29408 29409 Bug: https://sourceware.org/PR29957 29410 294112023-08-24 Paul Iannetta <piannetta@kalrayinc.com> 29412 29413 kvx: bfd/config.bfd & ld/configure.tgt 29414 bfd/ 29415 * config.bfd: Remove kvx_elf64_vec from targ_selvecs as it is 29416 already in targ_defvec. 29417 ld/ 29418 * configure.tgt: Split long line. 29419 294202023-08-24 Paul Iannetta <piannetta@kalrayinc.com> 29421 29422 kvx: use {u,}int32_t and {u,}int64_t 29423 gas/ 29424 * config/kvx-parse.c (promote_token): Use {u,}int32_t and 29425 {u,}int64_t. 29426 (get_token_class): Likewise. 29427 * config/tc-kvx.c (insert_operand): Likewise. 29428 * config/tc-kvx.h (struct token_s): Likewise. 29429 (struct token_list): Likewise. 29430 29431 opcodes/ 29432 * kvx-dis.c (struct decoded_insn): Use {u,}int32_t and 29433 {u,}int64_t. 29434 (decode_insn): Likewise. 29435 (print_insn_kvx): Likewise. 29436 (decode_prologue_epilogue_bundle): Likewise. 29437 * kvx-dis.h (struct kvx_prologue_epilogue_insn): Likewise. 29438 294392023-08-24 Paul Iannetta <piannetta@kalrayinc.com> 29440 29441 kvx: fix handling of STB_GNU_UNIQUE symbols 29442 When processing a STB_GNU_UNIQUE symbol we did not update has_gnu_osabi 29443 correctly. 29444 29445 * config/tc-kvx.c (kvx_end): Do not write to e_ident. 29446 (kvx_type): Properly handle STB_GNU_UNIQUE symbols. 29447 294482023-08-24 Paul Iannetta <piannetta@kalrayinc.com> 29449 29450 kvx: remove kvx_elf64_linux_vec 29451 * configure.ac: Remove kvx_elf64_linux_vec. 29452 * configure: Regenerate. 29453 294542023-08-24 GDB Administrator <gdbadmin@sourceware.org> 29455 29456 Automatic date update in version.in 29457 294582023-08-23 Tom de Vries <tdevries@suse.de> 29459 29460 [gdb/build] Run black on make-target-delegates.py 29461 Run black on make-target-delegates.py to fix buildbot build breaker. 29462 29463 Tested on x86_64-linux. 29464 294652023-08-23 Tom de Vries <tdevries@suse.de> 29466 29467 [gdb/build] Support reference return type in make-target-delegates.py 29468 When doing this in target.h: 29469 ... 29470 - virtual gdb::byte_vector thread_info_to_thread_handle (struct thread_info *) 29471 + virtual gdb::byte_vector &thread_info_to_thread_handle (struct thread_info *) 29472 ... 29473 make-target-delegates.py drops the function. 29474 29475 By handling '&' in POINTER_PART we can prevent that the function is dropped, 29476 but when recompiling target.o we get: 29477 ... 29478 gdb/target-delegates.c: In member function ‘virtual gdb::byte_vector& \ 29479 debug_target::thread_info_to_thread_handle(thread_info*)’: 29480 gdb/target-delegates.c:1889:22: error: ‘result’ declared as reference but not \ 29481 initialized 29482 gdb::byte_vector & result; 29483 ^~~~~~ 29484 make: *** [Makefile:1923: target.o] Error 1 29485 ... 29486 29487 Fix this by making sure result is initialized. 29488 29489 Regenerate target-delegates.c using this new style. 29490 29491 Tested on x86_64-linux. 29492 29493 Approved-By: Pedro Alves <pedro@palves.net> 29494 294952023-08-23 Peter Edwards <peadar@arista.com> 29496 29497 x86: Fix DT_JMPREL/DT_PLTRELSZ when relocs share a section 29498 If a linker script does not place the PLT relocations and "normal" 29499 relocations in separate ELF sections, `ld` will currently output incorrect 29500 values for DT_JMPREL and DT_PLTRELSZ - they cover the entire ELF section, 29501 rather than just the PLT relocations 29502 29503 Don't ignore the extent of the BFD section - use the size of the srelplt 29504 BFD section and its offset from the output_secttion 29505 29506 bfd/ 29507 29508 PR ld/30787 29509 * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use input 29510 section for DT_JMPREL and DT_PLTRELSZ. 29511 29512 ld/ 29513 29514 PR ld/30787 29515 * testsuite/ld-i386/i386.exp: Run pr30787. 29516 * testsuite/ld-x86-64/x86-64.exp: Likewise. 29517 * testsuite/ld-i386/pr30787.d: New file. 29518 * testsuite/ld-i386/pr30787.s: Likewise. 29519 * testsuite/ld-i386/pr30787.t: Likewise. 29520 * testsuite/ld-x86-64/pr30787.d: Likewise. 29521 * testsuite/ld-x86-64/pr30787.s: Likewise. 29522 * testsuite/ld-x86-64/pr30787.t: Likewise. 29523 295242023-08-23 Lancelot Six <lancelot.six@amd.com> 29525 29526 gdb: fix build failure in amd-dbgapi-target.c 29527 Since b080fe54fb3 "gdb: add inferior-specific breakpoints", the 29528 breakpoint class has an "inferior" member used to handle 29529 inferior-specific breakpoints. This creates a compilation error 29530 in amd_dbgapi_target_breakpoint::check_status which declares a local 29531 variable "inferior *inf". 29532 29533 Fix this by using "struct inferior *inf" instead. 29534 29535 Change-Id: Icc4dc1ba96c7d3ff9d33f9cb384ffcf64eba26fb 29536 Approved-By: Pedro Alves <pedro@palves.net> 29537 295382023-08-23 Pedro Alves <pedro@palves.net> 29539 29540 Fix Windows sharing_input_terminal hang 29541 After running a number of programs under Windows gdb and detaching 29542 them, I typed run in gdb, and got a hang, here: 29543 29544 (top-gdb) bt 29545 #0 sharing_input_terminal (pid=4672) at /home/pedro/gdb/src/gdb/mingw-hdep.c:388 29546 #1 0x00007ff71a2d8678 in sharing_input_terminal (inf=0x23bf23dafb0) at /home/pedro/gdb/src/gdb/inflow.c:269 29547 #2 0x00007ff71a2d887b in child_terminal_save_inferior (self=0x23bf23de060) at /home/pedro/gdb/src/gdb/inflow.c:423 29548 #3 0x00007ff71a2c80c0 in inf_child_target::terminal_save_inferior (this=0x23bf23de060) at /home/pedro/gdb/src/gdb/inf-child.c:111 29549 #4 0x00007ff71a429c0f in target_terminal_is_ours_kind (desired_state=target_terminal_state::is_ours_for_output) at /home/pedro/gdb/src/gdb/target.c:1037 29550 #5 0x00007ff71a429e02 in target_terminal::ours_for_output () at /home/pedro/gdb/src/gdb/target.c:1094 29551 #6 0x00007ff71a2ccc8e in post_create_inferior (from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:245 29552 #7 0x00007ff71a2cd431 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at /home/pedro/gdb/src/gdb/infcmd.c:502 29553 #8 0x00007ff71a2cd58b in run_command (args=0x0, from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:527 29554 29555 The problem is that the loop around GetConsoleProcessList looped 29556 forever, because there were exactly 10 processes to return. 29557 GetConsoleProcessList's documentation says: 29558 29559 If the buffer is too small to hold all the valid process identifiers, 29560 the return value is the required number of array elements. The 29561 function will have stored no identifiers in the buffer. In this 29562 situation, use the return value to allocate a buffer that is large 29563 enough to store the entire list and call the function again. 29564 29565 In this case, the buffer wasn't too small, it was exactly the right 29566 size, so we should have broken out of the loop. We didn't due to a 29567 "<" check that should have been "<=". That is fixed by this patch. 29568 29569 Approved-By: Tom Tromey <tom@tromey.com> 29570 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 29571 Change-Id: I14e4909f2ac2fa83d0d9b6e64418b5831ac4e4e3 29572 295732023-08-23 Andrew Burgess <aburgess@redhat.com> 29574 29575 gdb: fix up a few places where a char was treated as a bool 29576 Spotted a few places where a char is being treated as a bool. The GDB 29577 style is to use explicit comparisons, so fix things up. 29578 29579 There should be no user visible changes after this commit. 29580 295812023-08-23 Nick Clifton <nickc@redhat.com> 29582 29583 Correct PR number in previous delta 29584 29585 readelf/objdump: Handle DWARF info with mixed types of range section. 29586 PR 30791 29587 * dwarf.h (debug_info): Add range_versions field. 29588 * dwarf.c (read_and_display_attr_value): When recording a range arribute also ecord the dwarf version number. 29589 (is_range_list_for_this_section): New function. 29590 (display_debug_ranges): Only show debug ranges whose version is suitable for the secction being displayed. 29591 295922023-08-23 Andrew Burgess <aburgess@redhat.com> 29593 29594 gdb: MI stopped events when unwindonsignal is on 29595 This recent commit: 29596 29597 commit b1c0ab20809a502b2d2224fecb0dca3ada2e9b22 29598 Date: Wed Jul 12 21:56:50 2023 +0100 29599 29600 gdb: avoid double stop after failed breakpoint condition check 29601 29602 Addressed a problem where two MI stopped events would be reported if a 29603 breakpoint condition failed due to a signal, this commit was a 29604 replacement for this commit: 29605 29606 commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b 29607 Date: Fri Oct 14 14:53:15 2022 +0100 29608 29609 gdb: don't always print breakpoint location after failed condition check 29610 29611 which solved the two stop problem, but only for the CLI. Before both 29612 of these commits, if a b/p condition failed due to a signal then the 29613 user would see two stops reported, the first at the location where the 29614 signal occurred, and the second at the location of the breakpoint. 29615 29616 By default GDB remains at the location where the signal occurred, so 29617 the second reported stop can be confusing, this is the problem that 29618 commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a 29619 extended also address the issue for MI too. 29620 29621 However, while working on another patch I realised that there was a 29622 problem with GDB after the above commits. Neither of the above 29623 commits considered 'set unwindonsignal on'. With this setting on, 29624 when an inferior function call fails with a signal GDB will unwind the 29625 stack back to the location where the inferior function call started. 29626 In the b/p case we're looking at, the stop should be reported at the 29627 location of the breakpoint, not at the location where the signal 29628 occurred, and this isn't what happens. 29629 29630 This commit fixes this by ensuring that when unwindonsignal is 'on', 29631 GDB reports a single stop event at the location of the breakpoint, 29632 this fixes things for both CLI and MI. 29633 29634 The function call_thread_fsm::should_notify_stop is called when the 29635 inferior function call completes and GDB is figuring out if the user 29636 should be notified about this stop event by calling normal_stop from 29637 fetch_inferior_event in infrun.c. If normal_stop is called, then this 29638 notification will be for the location where the inferior call stopped, 29639 which will be the location at which the signal occurred. 29640 29641 Prior to this commit, the only time that normal_stop was not called, 29642 was if the inferior function call completed successfully, this was 29643 controlled by ::should_notify_stop, which only turns false when the 29644 inferior function call has completed successfully. 29645 29646 In this commit I have extended the logic in ::should_notify_stop. Now 29647 there are three cases in which ::should_notify_stop will return false, 29648 and we will not announce the first stop (by calling normal_stop). 29649 These three reasons are: 29650 29651 1. If the inferior function call completes successfully, this is 29652 unchanged behaviour, 29653 29654 2. If the inferior function call stopped due to a signal and 'set 29655 unwindonsignal on' is in effect, and 29656 29657 3. If the inferior function call stopped due to an uncaught C++ 29658 exception, and 'set unwind-on-terminating-exception on' is in 29659 effect. 29660 29661 However, if we don't call normal_stop then we need to call 29662 async_enable_stdin in call_thread_fsm::should_stop. Prior to this 29663 commit this was only done for the case where the inferior function 29664 call completed successfully. 29665 29666 In this commit I now call ::should_notify_stop and use this to 29667 determine if we need to call async_enable_stdin. With this done we 29668 now call async_enable_stdin for each of the three cases listed above, 29669 which means that GDB will exit wait_sync_command_done correctly (see 29670 run_inferior_call in infcall.c). 29671 29672 With these two changes the problem is mostly resolved. However, the 29673 solution isn't ideal, we've still lost some information. 29674 29675 Here is how GDB 13.1 behaves, this is before commits b1c0ab20809a and 29676 2e411b8c68eb: 29677 29678 $ gdb -q /tmp/mi-condbreak-fail \ 29679 -ex 'set unwindonsignal on' \ 29680 -ex 'break 30 if (cond_fail())' \ 29681 -ex 'run' 29682 Reading symbols from /tmp/mi-condbreak-fail... 29683 Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30. 29684 Starting program: /tmp/mi-condbreak-fail 29685 29686 Program received signal SIGSEGV, Segmentation fault. 29687 0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24 29688 24 return *p; /* Crash here. */ 29689 Error in testing breakpoint condition: 29690 The program being debugged was signaled while in a function called from GDB. 29691 GDB has restored the context to what it was before the call. 29692 To change this behavior use "set unwindonsignal off". 29693 Evaluation of the expression containing the function 29694 (cond_fail) will be abandoned. 29695 29696 Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30 29697 30 global_counter += 1; /* Set breakpoint here. */ 29698 (gdb) 29699 29700 In this state we see two stop notifications, the first is where the 29701 signal occurred, while the second is where the breakpoint is located. 29702 As GDB has unwound the stack (thanks to unwindonsignal) the second 29703 stop notification reflects where the inferior is actually located. 29704 29705 Then after commits b1c0ab20809a and 2e411b8c68eb the behaviour changed 29706 to this: 29707 29708 $ gdb -q /tmp/mi-condbreak-fail \ 29709 -ex 'set unwindonsignal on' \ 29710 -ex 'break 30 if (cond_fail())' \ 29711 -ex 'run' 29712 Reading symbols from /tmp/mi-condbreak-fail... 29713 Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30. 29714 Starting program: /tmp/mi-condbreak-fail 29715 29716 Program received signal SIGSEGV, Segmentation fault. 29717 0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24 29718 24 return *p; /* Crash here. */ 29719 Error in testing condition for breakpoint 1: 29720 The program being debugged was signaled while in a function called from GDB. 29721 GDB has restored the context to what it was before the call. 29722 To change this behavior use "set unwindonsignal off". 29723 Evaluation of the expression containing the function 29724 (cond_fail) will be abandoned. 29725 (gdb) bt 1 29726 #0 foo () at /tmp/mi-condbreak-fail.c:30 29727 (More stack frames follow...) 29728 (gdb) 29729 29730 This is the broken state. GDB is reports the SIGSEGV location, but 29731 not the unwound breakpoint location. The final 'bt 1' shows that the 29732 inferior is not located in cond_fail, which is the only location GDB 29733 reported, so this is clearly wrong. 29734 29735 After implementing the fixes described above we now get this 29736 behaviour: 29737 29738 $ gdb -q /tmp/mi-condbreak-fail \ 29739 -ex 'set unwindonsignal on' \ 29740 -ex 'break 30 if (cond_fail())' \ 29741 -ex 'run' 29742 Reading symbols from /tmp/mi-condbreak-fail... 29743 Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30. 29744 Starting program: /tmp/mi-condbreak-fail 29745 Error in testing breakpoint condition for breakpoint 1: 29746 The program being debugged was signaled while in a function called from GDB. 29747 GDB has restored the context to what it was before the call. 29748 To change this behavior use "set unwindonsignal off". 29749 Evaluation of the expression containing the function 29750 (cond_fail) will be abandoned. 29751 29752 Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30 29753 30 global_counter += 1; /* Set breakpoint here. */ 29754 (gdb) 29755 29756 This is better. GDB now reports a single stop at the location of the 29757 breakpoint, which is where the inferior is actually located. However, 29758 by removing the first stop notification we have lost some potentially 29759 useful information about which signal caused the inferior to stop. 29760 29761 To address this I've reworked the message that is printed to include 29762 the signal information. GDB now reports this: 29763 29764 $ gdb -q /tmp/mi-condbreak-fail \ 29765 -ex 'set unwindonsignal on' \ 29766 -ex 'break 30 if (cond_fail())' \ 29767 -ex 'run' 29768 Reading symbols from /tmp/mi-condbreak-fail... 29769 Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30. 29770 Starting program: /tmp/mi-condbreak-fail 29771 Error in testing condition for breakpoint 1: 29772 The program being debugged received signal SIGSEGV, Segmentation fault 29773 while in a function called from GDB. GDB has restored the context 29774 to what it was before the call. To change this behavior use 29775 "set unwindonsignal off". Evaluation of the expression containing 29776 the function (cond_fail) will be abandoned. 29777 29778 Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30 29779 30 global_counter += 1; /* Set breakpoint here. */ 29780 (gdb) 29781 29782 This is better, the user now sees a single stop notification at the 29783 correct location, and the error message describes which signal caused 29784 the inferior function call to stop. 29785 29786 However, we have lost the information about where the signal 29787 occurred. I did consider trying to include this information in the 29788 error message, but, in the end, I opted not too. I wasn't sure it was 29789 worth the effort. If the user has selected to unwind on signal, then 29790 surely this implies they maybe aren't interested in debugging failed 29791 inferior calls, so, hopefully, just knowing the signal name will be 29792 enough. I figure we can always add this information in later if 29793 there's a demand for it. 29794 297952023-08-23 Andrew Burgess <aburgess@redhat.com> 29796 29797 gdb/testsuite: add mi_info_frame helper proc (and use it) 29798 New helper proc mi_info_frame which takes care of running the MI 29799 -stack-info-frame command and matching its output. 29800 29801 Like the breakpoint helper procs, this new proc takes a name/value 29802 argument list and uses this to build the expected result regexp. This 29803 means that we can now write something like: 29804 29805 mi_info_frame "test name here" \ 29806 -level 0 -func name -line 123 29807 29808 Instead of the current equivalent: 29809 29810 mi_gdb_test "235-stack-info-frame" \ 29811 "235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"name\",file=\".*\",fullname=\".*\",line=\"123\",arch=\".*\"\}" \ 29812 "test name here" 29813 29814 There's also a helper proc mi_make_info_frame_regexp which is 29815 responsible for building the 'frame={...}' part of the pattern. 29816 29817 I've update the two existing tests that use -stack-info-frame and 29818 expect the command to succeed. There is another test that runs 29819 -stack-info-frame and expects the command to fail -- the helper proc 29820 doesn't help with this case, so that test is not changed. 29821 298222023-08-23 Pedro Alves <pedro@palves.net> 29823 29824 gdb: centralize "[Thread ...exited]" notifications 29825 Currently, each target backend is responsible for printing "[Thread 29826 ...exited]" before deleting a thread. This leads to unnecessary 29827 differences between targets, like e.g. with the remote target, we 29828 never print such messages, even though we do print "[New Thread ...]". 29829 29830 E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp 29831 with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we 29832 currently see: 29833 29834 (gdb) c 29835 Continuing. 29836 ^C[New Thread 3850398.3887449] 29837 [New Thread 3850398.3887500] 29838 [New Thread 3850398.3887551] 29839 [New Thread 3850398.3887602] 29840 [New Thread 3850398.3887653] 29841 ... 29842 29843 Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 29844 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) 29845 at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 29846 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c 29847 (gdb) 29848 29849 Above, we only see "New Thread" notifications, even though threads 29850 were deleted. 29851 29852 After this patch, we'll see: 29853 29854 (gdb) c 29855 Continuing. 29856 ^C[Thread 3558643.3577053 exited] 29857 [Thread 3558643.3577104 exited] 29858 [Thread 3558643.3577155 exited] 29859 [Thread 3558643.3579603 exited] 29860 ... 29861 [New Thread 3558643.3597415] 29862 [New Thread 3558643.3600015] 29863 [New Thread 3558643.3599965] 29864 ... 29865 29866 Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 29867 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) 29868 at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 29869 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c 29870 (gdb) q 29871 29872 This commit fixes this by moving the thread exit printing to common 29873 code instead, triggered from within delete_thread (or rather, 29874 set_thread_exited). 29875 29876 There's one wrinkle, though. While most targest want to print: 29877 29878 [Thread ... exited] 29879 29880 the Windows target wants to print: 29881 29882 [Thread ... exited with code <exit_code>] 29883 29884 ... and sometimes wants to suppress the notification for the main 29885 thread. To address that, this commits adds a delete_thread_with_code 29886 function, only used by that target (so far). 29887 29888 This fix was originally posted as part of a larger series: 29889 29890 https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ 29891 29892 But didn't really need to be part of that series. In order to get 29893 this fix merged sooner, I (Andrew Burgess) have rebased this commit 29894 outside of the original series. Any bugs introduced while splitting 29895 this patch out and rebasing, are entirely my own. 29896 29897 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 29898 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 29899 299002023-08-23 Andrew Burgess <aburgess@redhat.com> 29901 29902 gdb: remove the silent parameter from exit_inferior_1 and cleanup 29903 After the previous commit, exit_inferior_1 no longer makes use of the 29904 silent parameter. This commit removes this parameter and cleans up 29905 the callers. 29906 29907 After doing this exit_inferior_1, exit_inferior, and 29908 exit_inferior_silent are all equivalent, so rename exit_inferior_1 to 29909 exit_inferior and delete exit_inferior_silent, update all the callers. 29910 29911 Also I spotted the declaration exit_inferior_num_silent in inferior.h, 29912 but this function is not defined anywhere, so I deleted the 29913 declaration. 29914 29915 There should be no user visible changes after this commit. 29916 299172023-08-23 Pedro Alves <pedro@palves.net> 29918 29919 gdb: make inferior::clear_thread_list always silent 29920 After this commit: 29921 29922 commit a78ef8757418105c35685c5d82b9fdf79459321b 29923 Date: Wed Jun 22 18:10:00 2022 +0100 29924 29925 Always emit =thread-exited notifications, even if silent 29926 29927 The function mi_interp::on_thread_exited (or mi_thread_exit as the 29928 function was called back then) no longer makes use of the "silent" 29929 parameter. 29930 29931 As a result there is no difference between inferior::clear_thread_list 29932 with silent true or false, because: 29933 29934 - None of the interpreter ::on_thread_exited functions rely on the 29935 silent parameter, and 29936 29937 - None of GDB's thread_exit observers rely on the silent parameter 29938 either. 29939 29940 This commit removes the silent parameter from 29941 inferior::clear_thread_list, and makes the function always silent. 29942 29943 This commit was originally part of a larger series: 29944 29945 https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ 29946 29947 But didn't really need to be part of that series. I had an interest 29948 in seeing this patch merged: 29949 29950 https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-31-pedro@palves.net/ 29951 29952 Which also didn't really need to be part of the larger series, but 29953 does depend, at least a little, on this commit. In order to get the 29954 fix I'm interested in merged quicker, I (Andrew Burgess) have rebased 29955 this commit outside of the original series. Any bugs introduced while 29956 splitting this patch out and rebasing, are entirely my own. 29957 29958 There should be no user visible changes after this commit. 29959 29960 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 29961 299622023-08-23 Andrew Burgess <aburgess@redhat.com> 29963 29964 gdb: remove mi_parse::make functions 29965 Remove the static mi_parse::make functions, and instead use the 29966 mi_parse constructor. 29967 29968 This is a partial revert of the commit: 29969 29970 commit fde3f93adb50c9937cd2e1c93561aea2fd167156 29971 Date: Mon Mar 20 10:56:55 2023 -0600 29972 29973 Introduce "static constructor" for mi_parse 29974 29975 which introduced the mi_parse::make functions, though after discussion 29976 on the list the reasons for seem to have been lost[1]. Given there 29977 are no test regressions when moving back to using the constructors, I 29978 propose we should do that for now. 29979 29980 There should be no user visible changes after this commit. 29981 29982 [1] https://inbox.sourceware.org/gdb-patches/20230404-dap-loaded-sources-v2-5-93f229095e03@adacore.com/ 29983 29984 Approved-By: Tom Tromey <tom@tromey.com> 29985 299862023-08-23 Andrew Burgess <aburgess@redhat.com> 29987 29988 gdb: have mi_out_new return std::unique_ptr 29989 Have the mi_out_new function return a std::unique_ptr instead of a raw 29990 pointer. Update the two uses of mi_out_new. 29991 29992 There should be no user visible changes after this commit. 29993 29994 Approved-By: Tom Tromey <tom@tromey.com> 29995 299962023-08-23 Andrew Burgess <aburgess@redhat.com> 29997 29998 gdb: add gdb::make_unique function 29999 While GDB is still C++11, lets add a gdb::make_unique template 30000 function that can be used to create std::unique_ptr objects, just like 30001 the C++14 std::make_unique. 30002 30003 If GDB is being compiled with a C++14 compiler then the new 30004 gdb::make_unique function will delegate to the std::make_unique. I 30005 checked with gcc, and at -O1 and above gdb::make_unique will be 30006 optimised away completely in this case. 30007 30008 If C++14 (or later) becomes our minimum, then it will be easy enough 30009 to go through the code and replace gdb::make_unique with 30010 std::make_unique later on. 30011 30012 I've make use of this function in all the places I think this can 30013 easily be used, though I'm sure I've probably missed some. 30014 30015 Should be no user visible changes after this commit. 30016 30017 Approved-By: Tom Tromey <tom@tromey.com> 30018 300192023-08-23 Andrew Burgess <aburgess@redhat.com> 30020 30021 gdb/testsuite: improve MI support for inferior specific breakpoints 30022 In this commit: 30023 30024 commit b080fe54fb3414b488b8ef323c6c50def061f918 30025 Date: Tue Nov 8 12:32:51 2022 +0000 30026 30027 gdb: add inferior-specific breakpoints 30028 30029 limited support was added in lib/mi-support.exp to help with testing 30030 of inferior specific breakpoints. 30031 30032 Though the changes that were added were not wrong, while working on a 30033 later patch, I realised that I had added the support in the wrong 30034 place -- I only added support to mi_make_breakpoint_multi, when really 30035 I should have added the support to mi_make_breakpoint_1, which is used 30036 by all of the MI procs that create breakpoints. 30037 30038 This commit moves the support to mi_make_breakpoint_1, and updates all 30039 the procs that use mi_make_breakpoint_1 to accept, and then pass 30040 through, and (optional) inferior argument. This will make it much 30041 easier to write MI tests for inferior specific breakpoints. 30042 30043 There's no change in what is tested after this commit. 30044 300452023-08-23 Andrew Burgess <aburgess@redhat.com> 30046 30047 gdb: add missing notify_breakpoint_modified call 30048 The commit: 30049 30050 commit b080fe54fb3414b488b8ef323c6c50def061f918 30051 Date: Tue Nov 8 12:32:51 2022 +0000 30052 30053 gdb: add inferior-specific breakpoints 30054 30055 introduced a bug in the function breakpoint_set_inferior. The above 30056 commit includes this line: 30057 30058 gdb::observers::breakpoint_modified.notify (b); 30059 30060 when it should have instead used this line: 30061 30062 notify_breakpoint_modified (b); 30063 30064 The change to use notify_breakpoint_modified was introduced to GDB 30065 after commit b080fe54fb34 was written, but before it was merged, and I 30066 failed to update this part of the code during the rebase. 30067 30068 The consequence of this error is that the MI interpreter will not emit 30069 breakpoint-modified notifications when breakpoint_set_inferior is 30070 called. 30071 30072 In this commit I update the code to call notify_breakpoint_modified, 30073 and add a test that checks the MI events are being emitted correctly 30074 in this case. 30075 300762023-08-23 Paul Iannetta <piannetta@kalrayinc.com> 30077 30078 kvx: fix 32-bit build 30079 bfd/ 30080 * Makefile.am: Move elf32-kvx.lo from BFD32_BACKENDS to 30081 BFD64_BACKENDS. Remove elfxx-kvx.lo from BFD32_BACKENDS. 30082 Remove elfxx-kvx.c from BFD32_BACKENDS_CFILES. 30083 * Makefile.in: Regenerate. 30084 * config.bfd: Adjust targ_defvec and targ_selvecs and gate them 30085 behind BFD64. 30086 * configure.ac: Add target_size=64 to kvx_elf64_*vec. 30087 * configure: Regenerate. 30088 * elfnn-kvx.c (elfNN_kvx_stub_name): Cast rel->r_addend to 30089 uint64_t to match format string. 30090 (elfNN_kvx_relocate_section): Similarly for r_offset, and 30091 use PRIx64 in format string. 30092 * targets.c (_bfd_target_vector <kvx_elf32_vec>): Move inside 30093 #ifdef BFD64. 30094 ld/ 30095 * Makefile.am: Move eelf32kvx.c from ALL_EMULATION_SOURCES to 30096 ALL_64_EMULATION_SOURCES. 30097 * Makefile.in: Regenerate. 30098 300992023-08-23 Alan Modra <amodra@gmail.com> 30100 30101 kvx: O_pseudo_fixup 30102 O_pseudo_fixup was defined as O_max+1, missing the fact that O_md1 30103 through O_md32 enums are for use by target code. Worse, kvx-parse.c 30104 used 64 rather than O_pseudo_fixup. Fix this, and wrap some overlong 30105 lines. 30106 30107 * config/tc-kvx.h (O_pseudo_fixup): Define. 30108 * config/tc-kvx.c (O_pseudo_fixup): Don't define here. 30109 (insert_operand): Delete bogus comment and cast. 30110 * config/kvx-parse.c (promote_token): Use O_pseudo_fixup 30111 rather than hardcoded value. Wrap overlong lines. 30112 (get_token_class): Likewise. 30113 (parse_with_restarts): Wrap overlong line. 30114 301152023-08-23 Alan Modra <amodra@gmail.com> 30116 30117 kvx: ubsan: integer overflow 30118 This fixes a few places where ubsan complains about signed integer 30119 overflow when running the testsuite, and that clz(0) is undefined. 30120 When fixing the clz problem, I also noticed that we'd get complaints 30121 if pval is ever LLONG_MIN. Fix that by using unsigned arithmetic. 30122 30123 * config/kvx-parse.c (get_token_class): Avoid signed overflow. 30124 Don't clz(0). 30125 * config/tc-kvx.c (PARALLEL_BIT): Avoid signed overflow. 30126 301272023-08-23 Alan Modra <amodra@gmail.com> 30128 30129 kvx: asan: out-of-bounds read 30130 kvx-parse.c:parse_with_restarts does 30131 if (!tok.insn[tok.begin]) 30132 tok.class_id = -3; 30133 then a little later 30134 printf_debug (1, "\nEntering rule: %d (Trying to match: (%s)[%d])\n", jump_target, 30135 TOKEN_NAME (CLASS_ID (tok)), CLASS_ID (tok)); 30136 30137 This results in a buffer overrun in TOKEN_NAME. Fix that. 30138 30139 * config/tc-kvx.h (TOKEN_NAME): Check for tok <= 0, not just -1. 30140 301412023-08-23 Alan Modra <amodra@gmail.com> 30142 30143 kvx bfd signed calculations and _bfd_kvx_elf_resolve_relocation 30144 It is generally a good idea to avoid signed arithmetic on values 30145 extracted from object files, to avoid ubsan warnings on overflow. 30146 This patch replaces some uses of bfd_signed_vma in the kvx backend 30147 with bfd_vma, and removes _bfd_kvx_elf_resolve_relocation, a 30148 do-nothing function. In the process of making this patch I noticed 30149 some dead code in the GOT entry handling, setting value to 30150 got_entry_addr but using "off" in the _bfd_final_link_relocate call. 30151 Since kvx_calculate_got_entry_vma also returns the GOT offset, I 30152 presume the code is correct, but I've left the dead code and comment 30153 there. 30154 30155 * elfxx-kvx.h (_bfd_kvx_elf_resolve_relocation): Delete. 30156 * elfxx-kvx.c (kvx_signed_overflow): Rewrite using unsigned 30157 arithmetic. 30158 (_bfd_kvx_elf_resolve_relocation): Delete. 30159 * elfnn-kvx.c (kvx_relocate): Update for 30160 _bfd_kvx_elf_resolve_relocation removal. 30161 (elfNN_kvx_final_link_relocate): Likewise. Don't use a signed 30162 addend. 30163 301642023-08-23 Alan Modra <amodra@gmail.com> 30165 30166 bfd kvx formatting fixes 30167 Indentation, whitespace and comment fixes. 30168 30169 * elfnn-kvx.c: Formatting. 30170 * elfxx-kvx.c: Formatting. 30171 (elfNN_kvx_final_link_relocate): Correct GOT entry comment. 30172 301732023-08-23 Alan Modra <amodra@gmail.com> 30174 30175 gdb: bfd_get_symbol_leading_char vs. "" 30176 Some places matching the first char of a string against 30177 bfd_get_symbol_leading_char, which may be zero, didn't check for "". 30178 This could lead to accesses past the end of the string and potential 30179 buffer overruns. Fix that, and also get rid of a stupid optimisation 30180 in dbxread when looking for "__DYNAMIC" that also might access past 30181 the end of a string. 30182 301832023-08-23 Alan Modra <amodra@gmail.com> 30184 30185 bfd_get_symbol_leading_char vs. "" 30186 Some places matching the first char of a string against 30187 bfd_get_symbol_leading_char, which may be zero, didn't check for the 30188 string being "". This patch adds the check to stop accesses past the 30189 end of the string and potential buffer overruns. 30190 The dlltool one was found by oss-fuzz quite a while ago. 30191 30192 bfd/ 30193 * cofflink.c (_bfd_coff_link_input_bfd): Ensure a zero 30194 bfd_get_symbol_leading_char doesn't lead to accessing past the 30195 zero string terminator. 30196 * linker.c (bfd_wrapped_link_hash_lookup): Likewise. 30197 (unwrap_hash_lookup): Likewise. 30198 binutils/ 30199 * dlltool.c (scan_filtered_symbols): Ensure a zero 30200 bfd_get_symbol_leading_char doesn't lead to accessing past the 30201 zero string terminator. 30202 302032023-08-23 GDB Administrator <gdbadmin@sourceware.org> 30204 30205 Automatic date update in version.in 30206 302072023-08-22 Tom de Vries <tdevries@suse.de> 30208 30209 [gdb/build] Work around cgen odr violations 30210 When building gdb with -flto -O2, I run into: 30211 ... 30212 opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \ 30213 C++ One Definition Rule [-Wodr] 30214 typedef enum cgen_operand_type { 30215 ^ 30216 opcodes/or1k-desc.h:624:14: note: an enum with different value name is \ 30217 defined in another translation unit 30218 typedef enum cgen_operand_type { 30219 ^ 30220 opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \ 30221 Definition Rule [-Wodr] 30222 typedef enum cgen_hw_type { 30223 ^ 30224 opcodes/or1k-desc.h:433:14: note: an enum with different value name is \ 30225 defined in another translation unit 30226 typedef enum cgen_hw_type { 30227 ^ 30228 ... 30229 30230 Fix this by making the conflicting type names unique, adding a target-specific 30231 prefix using a define before the include: 30232 ... 30233 #define cgen_operand_type <target-name>_cgen_operand_type 30234 #define cgen_hw_type <target-name>_cgen_hw_type 30235 #include "opcodes/<target-name>-desc.h" 30236 ... 30237 and move those defines into a new file cgen-remap.h, similar to how that's 30238 done for yacc in yy-remap.h. 30239 30240 Likewise for targets frv and lm32, the two other targets that include 30241 opcodes/<target-name>-desc.h. 30242 30243 Likewise for more cgen symbols that I got the same warning for when using 30244 -flto-partition=one. 30245 30246 A PR has been filed to take care of this in the opcodes dir instead (PR30758). 30247 30248 Tested on x86_64-linux. 30249 30250 Approved-By: Tom Tromey <tom@tromey.com> 30251 30252 PR build/30757 30253 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757 30254 302552023-08-22 Tom Tromey <tromey@adacore.com> 30256 30257 Remove value::copy call from gdbpy_get_varobj_pretty_printer 30258 I noticed a call to value::copy in gdbpy_get_varobj_pretty_printer, 30259 and I couldn't figure out why it was there. I think maybe it came 30260 from the time when value_to_value_object would release values from the 30261 value chain -- but that was removed in commit f3d3bbbc. 30262 30263 This patch removes this call. Regression tested on x86-64 Fedora 36. 30264 302652023-08-22 Victor Do Nascimento <Victor.DoNascimento@arm.com> 30266 30267 aarch64: Improve naming conventions for A and R-profile architecture 30268 Historically, flags and variables relating to architectural revisions 30269 for the A-profile architecture omitted the trailing `A' such that, for 30270 example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4' 30271 flag in the assembler. 30272 30273 This leads to some ambiguity, since Binutils also targets the 30274 R-profile Arm architecture. Therefore, it seems prudent to have 30275 everything associated with the A-profile cores end in `A' and likewise 30276 `R' for the R-profile. Referring back to the example above, the flag 30277 set for `-march=armv8.4-a' is better characterized if labeled 30278 `AARCH64_ARCH_V8_4A'. 30279 30280 The only exception to the rule of appending `A' to variables is found 30281 in the handling of the `AARCH64_FEATURE_V8' macro, as it is the 30282 baseline from which ALL processors derive and should therefore be left 30283 unchanged. 30284 30285 In reflecting the `ARM' architectural nomenclature choices, where we 30286 have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have 30287 an underscore separating the numerical revision number and the 30288 A/R-profile indicator suffix. This has meant that renaming of 30289 R-profile related flags and variables was warranted, thus going from 30290 `.*_[vV]8_[rR]' to `.*_[vV]8[rR]'. 30291 30292 Finally, this is more in line with conventions within GCC and adds consistency 30293 across the toolchain. 30294 30295 gas/ChangeLog: 30296 * gas/config/tc-aarch64.c: 30297 (aarch64_cpus): Reference to arch feature macros updated. 30298 (aarch64_archs): Likewise. 30299 30300 include/ChangeLog: 30301 * include/opcode/aarch64.h: 30302 (AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A. 30303 (AARCH64_FEATURE_V8_1A): A-suffix added. 30304 (AARCH64_FEATURE_V8_2A): Likewise. 30305 (AARCH64_FEATURE_V8_3A): Likewise. 30306 (AARCH64_FEATURE_V8_4A): Likewise. 30307 (AARCH64_FEATURE_V8_5A): Likewise. 30308 (AARCH64_FEATURE_V8_6A): Likewise. 30309 (AARCH64_FEATURE_V8_7A): Likewise. 30310 (AARCH64_FEATURE_V8_8A):Likewise. 30311 (AARCH64_FEATURE_V9A): Likewise. 30312 (AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R. 30313 (AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A. 30314 (AARCH64_ARCH_V8_1A_FEATURES): A-suffix added. 30315 (AARCH64_ARCH_V8_2A_FEATURES): Likewise. 30316 (AARCH64_ARCH_V8_3A_FEATURES): Likewise. 30317 (AARCH64_ARCH_V8_4A_FEATURES): Likewise. 30318 (AARCH64_ARCH_V8_5A_FEATURES): Likewise. 30319 (AARCH64_ARCH_V8_6A_FEATURES): Likewise. 30320 (AARCH64_ARCH_V8_7A_FEATURES): Likewise. 30321 (AARCH64_ARCH_V8_8A_FEATURES): Likewise. 30322 (AARCH64_ARCH_V9A_FEATURES): Likewise. 30323 (AARCH64_ARCH_V9_1A_FEATURES): Likewise. 30324 (AARCH64_ARCH_V9_2A_FEATURES): Likewise. 30325 (AARCH64_ARCH_V9_3A_FEATURES): Likewise. 30326 (AARCH64_ARCH_V8A): Updated name: V8_A -> V8A. 30327 (AARCH64_ARCH_V8_1A): A-suffix added. 30328 (AARCH64_ARCH_V8_2A): Likewise. 30329 (AARCH64_ARCH_V8_3A): Likewise. 30330 (AARCH64_ARCH_V8_4A): Likewise. 30331 (AARCH64_ARCH_V8_5A): Likewise. 30332 (AARCH64_ARCH_V8_6A): Likewise. 30333 (AARCH64_ARCH_V8_7A): Likewise. 30334 (AARCH64_ARCH_V8_8A): Likewise. 30335 (AARCH64_ARCH_V9A): Likewise. 30336 (AARCH64_ARCH_V9_1A): Likewise. 30337 (AARCH64_ARCH_V9_2A): Likewise. 30338 (AARCH64_ARCH_V9_3A): Likewise. 30339 (AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R. 30340 30341 opcodes/ChangeLog: 30342 * opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A. 30343 (SR_V8_1A): A-suffix added. 30344 (SR_V8_2A): Likewise. 30345 (SR_V8_3A): Likewise. 30346 (SR_V8_4A): Likewise. 30347 (SR_V8_6A): Likewise. 30348 (SR_V8_7A): Likewise. 30349 (SR_V8_8A): Likewise. 30350 (aarch64_sys_regs): Reference to arch feature macros updated. 30351 (aarch64_pstatefields): Reference to arch feature macros updated. 30352 (aarch64_sys_ins_reg_supported_p): Reference to arch feature macros 30353 updated. 30354 * opcodes/aarch64-tbl.h: 30355 (aarch64_feature_v8_2a): a-suffix added. 30356 (aarch64_feature_v8_3a): Likewise. 30357 (aarch64_feature_fp_v8_3a): Likewise. 30358 (aarch64_feature_v8_4a): Likewise. 30359 (aarch64_feature_fp_16_v8_2a): Likewise. 30360 (aarch64_feature_v8_5a): Likewise. 30361 (aarch64_feature_v8_6a): Likewise. 30362 (aarch64_feature_v8_7a): Likewise. 30363 (aarch64_feature_v8r): Updated name: v8_r-> v8r. 30364 (ARMV8R): Updated name: V8_R-> V8R. 30365 (ARMV8_2A): A-suffix added. 30366 (ARMV8_3A): Likewise. 30367 (FP_V8_3A): Likewise. 30368 (ARMV8_4A): Likewise. 30369 (FP_F16_V8_2A): Likewise. 30370 (ARMV8_5): Likewise. 30371 (ARMV8_6A): Likewise. 30372 (ARMV8_6A_SVE): Likewise. 30373 (ARMV8_7A): Likewise. 30374 (V8_2A_INSN): `A' added to macro symbol. 30375 (V8_3A_INSN): Likewise. 30376 (V8_4A_INSN): Likewise. 30377 (FP16_V8_2A_INSN): Likewise. 30378 (V8_5A_INSN): Likewise. 30379 (V8_6A_INSN): Likewise. 30380 (V8_7A_INSN): Likewise. 30381 (V8R_INSN): Updated name: V8_R-> V8R. 30382 303832023-08-22 Alan Modra <amodra@gmail.com> 30384 30385 objdump: file name table entry count check 30386 Fuzzers have found that objdump -W takes a really long time if 30387 the entry count uleb is ridiculously large, and format attributes 30388 don't consume data (which doesn't make sense for a table of names). 30389 30390 * dwarf.c (display_formatted_table): Sanity check count of 30391 table entries. 30392 303932023-08-22 Alan Modra <amodra@gmail.com> 30394 30395 kvx_dis_init 30396 kvx_dis_init currently always returns true, but error conditions do so 30397 by "return -1" which converts to true. The return status is ignored 30398 anyway, and it doesn't make much sense to error on unexpected arch or 30399 mach: If print_insn_kvx is called then the atch is known to be kvx, 30400 and it's better to choose some default for a user passing an unknown 30401 mach value rather than segfaulting in decode_insn when env.opc_table 30402 is NULL. 30403 30404 I've chosen the default mach to be bfd_mach_kv3_1, the default in 30405 bfd/cpu-kvx.c, not that it matters very much. In normal objdump/gdb 30406 usage, info->mach won't be an unexpected value. 30407 30408 * kvx-dis.c (kvx_dis_init): Return void. Don't error on 30409 unexpected arch or mach. Default to bfd_mach_kv3_1 for 30410 unknown mach. Don't clear info->disassembler_options. 30411 304122023-08-22 Alan Modra <amodra@gmail.com> 30413 30414 kvx-linux config 30415 A misplaced line, resulting in testsuite errors when attempting to use 30416 as -m32. 30417 30418 * config.bfd (kvx-*-linux*): Add targ_selvecs. 30419 (kvx-*-*): Remove targ_selvecs. 30420 304212023-08-22 Alan Modra <amodra@gmail.com> 30422 30423 Re: kvx: New port. 30424 Add files submitted on the mailing list but somehow not committed. 30425 304262023-08-22 GDB Administrator <gdbadmin@sourceware.org> 30427 30428 Automatic date update in version.in 30429 304302023-08-21 David Faust <david.faust@oracle.com> 30431 30432 sim: bpf: remove negi, neg32i insns 30433 The BPF virtual machine does not support neg instructions operating on 30434 immediates, and these erroneous instructions were recently removed from 30435 gas. Remove them from the simulator as well. 30436 304372023-08-21 David Faust <david.faust@oracle.com> 30438 30439 bpf: correct neg and neg32 instruction encoding 30440 The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header 30441 source bit, despite operating on registers. If BPF_SRC_X (=1) is set, 30442 the instructions are rejected by the kernel. 30443 30444 Because of this there are also no neg/neg32 instructions which operate 30445 on immediates, so remove them. 30446 30447 bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old 30448 CGEN-based port, but was not carried forward in the new port. 30449 30450 include/ 30451 * opcode/bpf.h (enum bpf_insn_id): Remove spurious entries 30452 BPF_INSN_NEGI and BPF_INSN_NEG32I. 30453 30454 opcodes/ 30455 * bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I 30456 instructions. 30457 30458 gas/ 30459 * doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and 30460 neg32 instructions operating on immediates. 30461 * testsuite/gas/bpf/alu.s: Adapt accordingly. 30462 * testsuite/gas/bpf/alu.d: Likewise. 30463 * testsuite/gas/bpf/alu-be.d: Likewise 30464 * testsuite/gas/bpf/alu32.s: Likewise. 30465 * testsuite/gas/bpf/alu32.d: Likewise. 30466 * testsuite/gas/bpf/alu32-be.d: Likewise. 30467 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 30468 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 30469 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 30470 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 30471 * testsuite/gas/bpf/alu32-pseudoc.d: Likewise. 30472 * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise. 30473 304742023-08-21 Luis Machado <luis.machado@arm.com> 30475 30476 aarch64/sme2: Teach binutils/BFD about the NT_ARM_ZT register set 30477 The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that 30478 the Linux Kernel handles through a new NT_ARM_ZT register set. 30479 30480 Teach binutils/BFD about it so that gdb can make use of it for reading 30481 and writing core files. This also enables readelf/objdump to show the 30482 correct identification for the NT_ARM_ZT register set. 30483 30484 Validated under Fast Models. 30485 304862023-08-21 Ezra Sitorus <ezra.sitorus@arm.com> 30487 30488 aarch64/sme: Core file support 30489 Add required code to support core file dumps with NT_ARM_ZA and NT_ARM_SSVE 30490 register sets in them. 30491 30492 These new register sets are dumped when SME is supported. 30493 304942023-08-21 Alan Modra <amodra@gmail.com> 30495 30496 bfd_close_all_done bug and bfd_last_cache 30497 bfd_close ought to always call iovec->bclose so that cache_bclose is 30498 called. If not, bfd_last_cache will be left pointing at freed memory. 30499 This bug was found by oss-fuzz with the trigger being an old bug in 30500 the ia64-vms support. Given a file of the "wrong" size, 30501 elf64_vms_close_and_cleanup attempted to extend it, leading to an 30502 error since the file was opened read-only by nm. nm bad_file bad_file 30503 then hit the use-after-free when opening the second file. 30504 30505 commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and 30506 bfd_close_all_done, but didn't go quite far enough. 30507 30508 * elf64-ia64-vms.c (elf64_vms_close_and_cleanup): Don't 30509 attempt to extend read-only files. 30510 * opncls.c (bfd_close_all_done): Always call _close_and_cleanup. 30511 30512 An old bug in the ia64-vms support can be used to tickle another bug 30513 in bfd_close_all_done. If _close_and_cleanup returns an error, 30514 305152023-08-21 mengqinggang <mengqinggang@loongson.cn> 30516 30517 LoongArch: gas: Fix make check-gas crash 30518 305192023-08-21 GDB Administrator <gdbadmin@sourceware.org> 30520 30521 Automatic date update in version.in 30522 305232023-08-20 GDB Administrator <gdbadmin@sourceware.org> 30524 30525 Automatic date update in version.in 30526 305272023-08-19 Tom Tromey <tom@tromey.com> 30528 30529 Placate -Wmissing-declarations in sim/cris 30530 I get a couple of -Wmissing-declarations errors when building the sim. 30531 This happens because an earlier patch added the declarations to a 30532 cgen-generated header, but the recent re-generation then removed them. 30533 30534 This patch fixes the build by adding declarations just before the 30535 definition. This is normally not best practice, but in this 30536 particular situation it at leat un-breaks the build. 30537 305382023-08-19 Tom Tromey <tom@tromey.com> 30539 30540 Remove extraneous '%' from sim/cris/local.mk 30541 I saw this warning from make: 30542 30543 Makefile:5043: *** mixed implicit and normal rules: deprecated syntax 30544 30545 I believe this snuck in by error with the recent cgen-related changes. 30546 30547 This patch removes the stray '%' and rebuilds the Makefile.in. I'm 30548 checking this in. 30549 305502023-08-19 Alan Modra <amodra@gmail.com> 30551 30552 sim regen 30553 This regenerates sim files. 30554 30555 Tested with the following tools from a recent binutils build in 30556 sim-site-config.exp, plus a few cross compilers. 30557 30558 set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new" 30559 set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new" 30560 set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc" 30561 set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new" 30562 set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new" 30563 set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc" 30564 set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new" 30565 set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new" 30566 set CC_FOR_TARGET_AVR "" 30567 set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new" 30568 set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new" 30569 set CC_FOR_TARGET_BFIN "" 30570 set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new" 30571 set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new" 30572 set CC_FOR_TARGET_BPF "" 30573 set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new" 30574 set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new" 30575 set CC_FOR_TARGET_CR16 "" 30576 set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new" 30577 set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new" 30578 set CC_FOR_TARGET_CRIS "" 30579 set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new" 30580 set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new" 30581 set CC_FOR_TARGET_D10V "" 30582 set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new" 30583 set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new" 30584 set CC_FOR_TARGET_FRV "" 30585 set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new" 30586 set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new" 30587 set CC_FOR_TARGET_FT32 "" 30588 set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new" 30589 set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new" 30590 set CC_FOR_TARGET_H8300 "" 30591 set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new" 30592 set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new" 30593 set CC_FOR_TARGET_IQ2000 "" 30594 set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new" 30595 set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new" 30596 set CC_FOR_TARGET_LM32 "" 30597 set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new" 30598 set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new" 30599 set CC_FOR_TARGET_M32C "" 30600 set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new" 30601 set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new" 30602 set CC_FOR_TARGET_M32R "" 30603 set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new" 30604 set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new" 30605 set CC_FOR_TARGET_M68HC11 "" 30606 set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new" 30607 set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new" 30608 set CC_FOR_TARGET_MCORE "" 30609 set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new" 30610 set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new" 30611 set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc" 30612 set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new" 30613 set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new" 30614 set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc" 30615 set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new" 30616 set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new" 30617 set CC_FOR_TARGET_MN10300 "" 30618 set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new" 30619 set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new" 30620 set CC_FOR_TARGET_MOXIE "" 30621 set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new" 30622 set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new" 30623 set CC_FOR_TARGET_MSP430 "" 30624 set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new" 30625 set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new" 30626 set CC_FOR_TARGET_OR1K "" 30627 set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new" 30628 set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new" 30629 set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc" 30630 set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new" 30631 set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new" 30632 set CC_FOR_TARGET_PRU "" 30633 set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new" 30634 set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new" 30635 set CC_FOR_TARGET_RISCV "" 30636 set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new" 30637 set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new" 30638 set CC_FOR_TARGET_RL78 "" 30639 set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new" 30640 set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new" 30641 set CC_FOR_TARGET_RX "" 30642 set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new" 30643 set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new" 30644 set CC_FOR_TARGET_SH "" 30645 set AS_FOR_TARGET_ERC32 "" 30646 set LD_FOR_TARGET_ERC32 "" 30647 set CC_FOR_TARGET_ERC32 "" 30648 set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new" 30649 set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new" 30650 set CC_FOR_TARGET_V850 "" 30651 30652 Results both before and after were: 30653 FAIL: crisv10 mem1.ms (execution) 30654 FAIL: crisv10 mem2.ms (execution) 30655 FAIL: crisv32 mem1.ms (execution) 30656 FAIL: crisv32 mem2.ms (execution) 30657 FAIL: microblaze fail.s (execution) 30658 FAIL: microblaze pass.s (execution) 30659 expected passes 5288 30660 unexpected failures 6 30661 expected failures 3 30662 untested testcases 373 30663 unsupported tests 14 30664 306652023-08-19 Alan Modra <amodra@gmail.com> 30666 30667 sim regen preparation 30668 Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a 30669 generated file, so this patch move those declarations to 30670 sim/lm32/sim-main.h. 30671 306722023-08-19 Alan Modra <amodra@gmail.com> 30673 30674 sim --enable-cgen-maint 30675 I had reason yesterday to want to regenerate configury files which I 30676 do with --enable-maintainer-mode, and added --enable-cgen-maint 30677 accidentally. The first problem I hit is that sim looks for cgen in a 30678 different directory by default than opcodes, and I had my source 30679 layout set up for opcodes rather than sim. Fix that by making both 30680 use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The 30681 next problem was that various sim local.mk files expected generated 30682 sources in the build dir rather than the source dir. Fix that by 30683 adding $(srcdir) to paths. Finally, the generated iq2000 files had a 30684 compile error, fixed by the cpu/iq2000.cpu patch. 30685 30686 cpu/ 30687 * iq2000.cpu (syscall): Add pc arg. 30688 opcodes/ 30689 * configure.ac (cgendir): Default to ../../cgen, but use ../cgen 30690 if found there. 30691 * configure: Regenerate. 30692 sim/m4/ 30693 * sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too. 30694 sim/ 30695 * cris/local.mk: Add $(srcdir) to paths for regenerated source. 30696 * frv/local.mk: Likewise. 30697 * iq2000/local.mk: Likewise. 30698 * lm32/local.mk: Likewise. 30699 * m32r/local.mk: Likewise. 30700 * or1k/local.mk: Likewise. 30701 * Makefile.in: Regenerate. 30702 * configure: Regenerate. 30703 307042023-08-19 Alan Modra <amodra@gmail.com> 30705 30706 sim prune_warnings 30707 Remove some of the warnings generated by newer versions of ld. 30708 30709 * testsuite/lib/sim-defs.exp (prune_warnings_extra): New. 30710 Arrange to run it from prune_warnings. 30711 307122023-08-19 GDB Administrator <gdbadmin@sourceware.org> 30713 30714 Automatic date update in version.in 30715 307162023-08-18 Tom Tromey <tromey@adacore.com> 30717 30718 Fix off-by-one in call to vector::reserve 30719 While looking at a bug, I noticed what I think is an off-by-one 30720 mistake in a call to vector::reserve. This code: 30721 30722 new_args.reserve (args.size ()); 30723 new_args.push_back 30724 (value_from_pointer (lookup_pointer_type (values_type), struct_addr)); 30725 new_args.insert (new_args.end (), args.begin (), args.end ()); 30726 30727 ... reserves 'size()' entries, but then proceeds to push one extra 30728 one. 30729 30730 This shouldn't have any really bad effects, as insert will grow the 30731 vector. Still, it seems better to use the correct size if we're going 30732 to bother calling reserve. 30733 30734 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780 30735 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 30736 307372023-08-18 Tom Tromey <tromey@adacore.com> 30738 30739 Merge psympriv.h into psymtab.h 30740 psympriv.h was intended for use by code that created partial symbols. 30741 Now that no generic code needs psymtab.h any more, psympriv.h can be 30742 merged into psymtab.h. 30743 30744 Remove most includes of psymtab.h 30745 I found that most spots including psymtab.h do not need it. This 30746 patch removes these includes, and also one unnecessary include of 30747 psympriv.h. 30748 307492023-08-18 Jan Beulich <jbeulich@suse.com> 30750 30751 x86: remove indirection from bx[] and di_si[] 30752 The longest register name is 3 characters (plus a nul one), so using a 30753 4- or 8-byte pointer to get at it is neither space nor time efficient. 30754 Embed the names right into the array. For PIE this also slightly reduces 30755 the number of base relocations in the final image. 30756 30757 gas: make S_IS_LOCAL() and S_IS_EXTERNAL() exclusive of one another 30758 While they aren't opposites of each other, there also shouldn't be any 30759 symbol for which both return true; both may return false. Therefore 30760 use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check 30761 which so far both did alike. 30762 307632023-08-18 Nelson Chu <nelson@rivosinc.com> 30764 30765 RISC-V: Report "c or zca" for INSN_CLASS_C when error reporting. 30766 bfd/ 30767 * elfxx-riscv.c (riscv_multi_subset_supports_ext): Return "c or zca" 30768 rather than "c". 30769 307702023-08-18 GDB Administrator <gdbadmin@sourceware.org> 30771 30772 Automatic date update in version.in 30773 307742023-08-18 Tom Tromey <tom@tromey.com> 30775 30776 C++-ify minidebug.c 30777 I noticed minidebug.c was still using explicit malloc and free, where 30778 a vector would be more automatic. 30779 30780 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 30781 307822023-08-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 30783 30784 gprofng: Use execvp instead of execv 30785 gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui) 30786 can be installed in a different directory. 30787 In this case, $PATH is used to look up gp-display-text. 30788 execv() does not use $PATH to find the executable. 30789 30790 gprofng/ChangeLog 30791 2023-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 30792 30793 * src/gp-display-text.cc (reexec): Use execvp instead of execv. 30794 307952023-08-17 Andrew Burgess <aburgess@redhat.com> 30796 30797 gdb: add inferior-specific breakpoints 30798 This commit extends the breakpoint mechanism to allow for inferior 30799 specific breakpoints (but not watchpoints in this commit). 30800 30801 As GDB gains better support for multiple connections, and so for 30802 running multiple (possibly unrelated) inferiors, then it is not hard 30803 to imagine that a user might wish to create breakpoints that apply to 30804 any thread in a single inferior. To achieve this currently, the user 30805 would need to create a condition possibly making use of the $_inferior 30806 convenience variable, which, though functional, isn't the most user 30807 friendly. 30808 30809 This commit adds a new 'inferior' keyword that allows for the creation 30810 of inferior specific breakpoints. 30811 30812 Inferior specific breakpoints are automatically deleted when the 30813 associated inferior is removed from GDB, this is similar to how 30814 thread-specific breakpoints are deleted when the associated thread is 30815 deleted. 30816 30817 Watchpoints are already per-program-space, which in most cases mean 30818 watchpoints are already inferior specific. There is a small window 30819 where inferior-specific watchpoints might make sense, which is after a 30820 vfork, when two processes are sharing the same address space. 30821 However, I'm leaving that as an exercise for another day. For now, 30822 attempting to use the inferior keyword with a watchpoint will give an 30823 error, like this: 30824 30825 (gdb) watch a8 inferior 1 30826 Cannot use 'inferior' keyword with watchpoints 30827 30828 A final note on the implementation: currently, inferior specific 30829 breakpoints, like thread-specific breakpoints, are inserted into every 30830 inferior, GDB then checks once the inferior stops if we are in the 30831 correct thread or inferior, and resumes automatically if we stopped in 30832 the wrong thread/inferior. 30833 30834 An obvious optimisation here is to only insert breakpoint locations 30835 into the specific program space (which mostly means inferior) that 30836 contains either the inferior or thread we are interested in. This 30837 would reduce the number times GDB has to stop and then resume again in 30838 a multi-inferior setup. 30839 30840 I have a series on the mailing list[1] that implements this 30841 optimisation for thread-specific breakpoints. Once this series has 30842 landed I'll update that series to also handle inferior specific 30843 breakpoints in the same way. For now, inferior specific breakpoints 30844 are just slightly less optimal, but this is no different to 30845 thread-specific breakpoints in a multi-inferior debug session, so I 30846 don't see this as a huge problem. 30847 30848 [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/ 30849 308502023-08-17 Tom de Vries <tdevries@suse.de> 30851 30852 [gdb/build] Fix yysymbol_kind_t odr violation 30853 When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I 30854 run into: 30855 ... 30856 ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \ 30857 Definition Rule [-Wodr] 30858 c-exp.c.tmp:398: note: an enum with different value name is defined in \ 30859 another translation unit 30860 ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \ 30861 'YYSYMBOL_COMPLEX_INT' defined in another translation unit 30862 c-exp.c.tmp:405: note: mismatching definition 30863 ... 30864 30865 Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y 30866 files. 30867 30868 Tested on x86_64-linux. 30869 30870 PR build/22395 30871 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 30872 308732023-08-17 Alan Modra <amodra@gmail.com> 30874 30875 generated bfd files, and kvx regen 30876 The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are 30877 different to the other similar generated files, and that reminded me 30878 that we need to have $srcdir in the generated #line reference back to 30879 the source for debugging, but don't want it for comments in bfd.pot 30880 (because then bfd.pot will likely reference Nick's source tree). 30881 This patch fixes that by making all the #line use $srcdir by virtue of 30882 using $<, and edits bfd.pot. 30883 30884 I also uniq list of files to remove duplicated elfxx-x86.c, sort lists 30885 of files and regen with our standard automake/autoconf. 30886 30887 * configure: Regenerate. 30888 bfd/ 30889 * Makefile.am: Sort various lists of files. Use $< in #line 30890 directive of generated C files. 30891 (po/SRC-POTFILES.in): uniq SRC_POTFILES. 30892 (po/BLD-POTFILES.in): uniq BFD_POTFILES. 30893 * Makefile.in: Regenerate. 30894 * po/Make-in (bfd.pot): Edit out source dir from comments. 30895 * po/SRC-POTFILES.in: Regenerate. 30896 gas/ 30897 * Makefile.in: Regenerate. 30898 * configure: Regenerate. 30899 * po/POTFILES.in: Regenerate. 30900 ld/ 30901 * Makefile.am (ALL_64_EMULATION_SOURCES): Sort. 30902 * Makefile.in: Regenerate. 30903 309042023-08-17 Alan Modra <amodra@gmail.com> 30905 30906 Re: sim frv: Add a missing return value for frvbf_check_acc_range. 30907 Commit f00b50d057 went the wrong way. As the comment says this 30908 function is only applicable to fr550. If not fr550 return 1, 30909 meaning we don't have acc restrictions. 30910 309112023-08-17 Tom de Vries <tdevries@suse.de> 30912 30913 [gdb/build, c++20] Handle deprecated std::allocator::construct 30914 When building gdb with -std=c++20, I run into: 30915 ... 30916 gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \ 30917 declared in ‘class std::allocator<unsigned char>’ 30918 52 | using A::construct; 30919 | ^~~~~~~~~ 30920 ... 30921 30922 Indeed, std::allocator::construct has been deprecated in c++17 and removed in 30923 c++20. 30924 30925 Fix this by using instead std::pmr::polymorphic_allocator for c++20. 30926 30927 Tested on x86_64-linux. 30928 309292023-08-17 Tom de Vries <tdevries@suse.de> 30930 30931 [gdb/build] Return const reference in target_read_auxv 30932 In target_read_auxv we return a copy of an object: 30933 ... 30934 gdb::optional<gdb::byte_vector> 30935 target_read_auxv () 30936 { 30937 ... 30938 return info->data; 30939 } 30940 ... 30941 30942 Return a const reference instead, saving a copy. 30943 30944 This is exposed by using std::pmr::polymorphic_allocator instead of 30945 std::allocator in default_init_allocator. 30946 30947 Tested on x86_64-linux. 30948 309492023-08-17 Tom de Vries <tdevries@suse.de> 30950 30951 [gdb/build, c++20] Fix invalid conversion in test_symbols 30952 When building gdb with -std=c++20, I run into: 30953 ... 30954 gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \ 30955 ‘const char*’ [-fpermissive] 30956 2709 | u8"u8função", 30957 | ^~~~~~~~~~~~ 30958 | | 30959 | const char8_t* 30960 ... 30961 30962 Fix this by making the conversion explicit. 30963 30964 Tested on x86_64-linux. 30965 309662023-08-17 Tom de Vries <tdevries@suse.de> 30967 30968 [gdb/build, c++20] Fix deprecated implicit capture of this 30969 When building gdb with -std=c++20 I run into: 30970 ... 30971 gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \ 30972 deprecated in C++20 [-Werror=deprecated] 30973 10713 | auto do_op = [=] (LONGEST x, LONGEST y) 30974 | ^ 30975 gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture 30976 ... 30977 30978 Fix this by using "[this]". 30979 30980 Likewise in two more spots. 30981 30982 Tested on x86_64-linux. 30983 309842023-08-17 Tom de Vries <tdevries@suse.de> 30985 30986 [gdb/build, c++20] Fix DISABLE_COPY_AND_ASSIGN use in ui_out_emit_type 30987 When building gdb with -std=c++20, I run into: 30988 ... 30989 include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’ 30990 342 | TYPE (const TYPE&) = delete; \ 30991 | ^~~~~ 30992 gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’ 30993 412 | DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>); 30994 | ^~~~~~~~~~~~~~~~~~~~~~~ 30995 ... 30996 30997 Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)". 30998 30999 Tested on x86_64-linux. 31000 310012023-08-17 Tom de Vries <tdevries@suse.de> 31002 31003 [gdb/build, c++20] Stop using deprecated is_pod 31004 When building gdb with clang 15 and -std=c++20, I run into: 31005 ... 31006 gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \ 31007 is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations] 31008 std::is_pod<T>> 31009 ^ 31010 ... 31011 31012 Fix this by following the suggestion. 31013 31014 Likewise in gdb/unittests/ptid-selftests.c. 31015 31016 Tested on x86_64-linux. 31017 310182023-08-17 Tom de Vries <tdevries@suse.de> 31019 31020 [gdb/build, c++20] Fix Wdeprecated-enum-enum-conversion 31021 When building gdb with clang 15 and -std=c++20, I run into: 31022 ... 31023 gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \ 31024 enumeration types ('const enum return_reason' and 'const enum errors') is \ 31025 deprecated [-Werror,-Wdeprecated-enum-enum-conversion] 31026 size_t result = exc.reason + exc.error; 31027 ~~~~~~~~~~ ^ ~~~~~~~~~ 31028 ... 31029 31030 Fix this by using to_underlying. 31031 31032 Likewise in a few other places. 31033 31034 Tested on x86_64-linux. 31035 310362023-08-17 Tom de Vries <tdevries@suse.de> 31037 31038 [gdb/testsuite] Fix copy-to-remote in gdb.base/vfork-follow-parent.exp 31039 When running test-case gdb.base/vfork-follow-parent.exp, I run into: 31040 ... 31041 ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp. 31042 ERROR: error copying "vforked-prog": no such file or directory 31043 while executing 31044 "file copy -force $fromfile $tofile" 31045 (procedure "gdb_remote_download" line 29) 31046 invoked from within 31047 "gdb_remote_download target $binfile3" 31048 ... 31049 31050 Fix this by: 31051 - making the copy-to-remote conditional on is_remote target, and 31052 - allowing gdb_remote_download to find $binfile3 by using 31053 standard_output_file. 31054 31055 Also remove unused variable remote_exec_prog. 31056 31057 Tested on x86_64-linux. 31058 310592023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com> 31060 31061 gas: tc-sparc.c: undo spurious change in 5be1b787276d2adbe85ae7febc709ca517b62f08 31062 310632023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com> 31064 31065 bpf: gas: consolidate handling of immediate overflows 31066 This commit changes the BPF GAS port in order to handle immediate 31067 overflows the same way than the clang BPF assembler: 31068 31069 - For an immediate field of N bits, any written number (positive or 31070 negative) whose two's complement encoding fit in N its is accepted. 31071 This means that -2 is the same than 0xffffffe. It is up to the 31072 instructions to decide how to interpret the encoded value. 31073 31074 - Immediate fields in jump instructions are no longer relaxed. 31075 Relaxing to jump instructions with wider range is only performed 31076 when expressions are involved. 31077 31078 - The manual is updated to document this, and testsuite adapted 31079 accordingly. 31080 31081 Tested in x86_64-linux-gnu host, bpf-unknown-none target. 31082 31083 gas/ChangeLog: 31084 31085 2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com> 31086 31087 * config/tc-bpf.c (check_immediate_overflow): New function. 31088 (encode_insn): Use check_immediate_overflow. 31089 (md_assemble): Do not relax instructions with 31090 constant disp16 fields. 31091 * doc/c-bpf.texi (BPF Instructions): Add note about how numerical 31092 literal values are interpreted for instruction immediate operands. 31093 * testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly. 31094 * testsuite/gas/bpf/jump-relax-jump.s: Likewise. 31095 * testsuite/gas/bpf/jump-relax-jump.d: Likewise. 31096 * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise. 31097 * testsuite/gas/bpf/jump-relax-ja.s: Likewise. 31098 * testsuite/gas/bpf/jump-relax-ja.d: Likewise. 31099 * testsuite/gas/bpf/jump-relax-ja-be.d: Likewise. 31100 * testsuite/gas/bpf/disp16-overflow-relax.l: Likewise. 31101 * testsuite/gas/bpf/imm32-overflow.s: Likewise. 31102 * testsuite/gas/bpf/disp32-overflow.s: Likewise. 31103 * testsuite/gas/bpf/disp16-overflow.l: Likewise. 31104 * testsuite/gas/bpf/disp32-overflow.l: Likewise. 31105 * testsuite/gas/bpf/imm32-overflow.l: Likewise. 31106 * testsuite/gas/bpf/offset16-overflow.l: Likewise. 31107 311082023-08-17 Sam James <sam@gentoo.org> 31109 31110 ld: ld-lib.exp: log failed dump.out contents for debugging 31111 If we're using dump_prog in a test which fails, log the dump.out contents 31112 to ld.log to aid debugging. 31113 31114 This avoids needing to ask reporters to manually run e.g. `objdump` commands 31115 when making bug reports. 31116 31117 PR30722 31118 * ld/testsuite/lib/ld-lib.exp: Log failed dump.out contents to aid 31119 debugging. 31120 31121 Approved-by: Nick Clifton <nickc@redhat.com> 31122 311232023-08-17 GDB Administrator <gdbadmin@sourceware.org> 31124 31125 Automatic date update in version.in 31126 311272023-08-16 Tom de Vries <tdevries@suse.de> 31128 31129 [gdb/symtab] Handle self-reference DIE 31130 While working on a dwarf assembly test-case I accidentally created the 31131 following pathological dwarf: 31132 ... 31133 <1><be>: Abbrev Number: 3 (DW_TAG_class_type) 31134 <bf> DW_AT_name : c1 31135 <c2> DW_AT_specification: <0xbe> 31136 ... 31137 and noticed gdb segfaulting during cooked index creating due to running out of 31138 stack. This is a regression from gdb-12, where gdb just hung. 31139 31140 Fix this by inhibiting the scan_attributes self-recursion for self-references. 31141 31142 The same test-case with -readnow makes gdb hang, so also fix this in 31143 dwarf2_attr and follow_die_ref. 31144 31145 Note that this doesn't fix the same problems for the more complicated case of: 31146 ... 31147 <1><be>: Abbrev Number: 3 (DW_TAG_class_type) 31148 <bf> DW_AT_name : c1 31149 <c2> DW_AT_specification: <0xc6> 31150 <1><c6>: Abbrev Number: 4 (DW_TAG_class_type) 31151 <c7> DW_AT_name : c2 31152 <ca> DW_AT_specification: <0xbe> 31153 ... 31154 but the approach for deciding whether to fix pathological dwarf cases is as 31155 per PR27981 comment 3: 31156 ... 31157 yes if it is cheap/obvious, and no if it is something complicated or expensive. 31158 ... 31159 and at this point I'm not sure whether fixing this will fall in the first 31160 category. 31161 31162 Tested on x86_64-linux. 31163 31164 Approved-By: Tom Tromey <tom@tromey.com> 31165 311662023-08-16 Tom Tromey <tromey@adacore.com> 31167 31168 Avoid buffer overflow in ada_decode 31169 A bug report pointed out a buffer overflow in ada_decode, which Keith 31170 helpfully analyzed. ada_decode had a logic error when the input was 31171 all digits. While this isn't valid -- and would probably only appear 31172 in fuzzer tests -- it still should be handled properly. 31173 31174 This patch adds a missing bounds check. Tested with the self-tests in 31175 an asan build. 31176 31177 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639 31178 Reviewed-by: Keith Seitz <keiths@redhat.com> 31179 311802023-08-16 Tom Tromey <tromey@adacore.com> 31181 31182 Fix obvious bug in aggregate expression 31183 I found an obvious bug in Ada aggregate expression handling: 31184 31185 if (vvo != nullptr) 31186 error (_("Invalid record component association.")); 31187 name = vvo->get_symbol ()->natural_name (); 31188 31189 Here the code errors when vvo is not null -- and then proceeds to use 31190 vvo. 31191 31192 This hasn't caused a crash because, I believe, there's currently no 31193 way to reach this code in the null case. However, I'm not really 31194 willing to assert this... 31195 31196 Fixing this shows another bug, which is that due to the way the parser 31197 works, a field name in an aggregate expression might erroneously be 31198 fully qualified if some global variable with the same base name 31199 exists. 31200 31201 The included test case triggers both bugs. Note that the test 31202 includes a confounding case for array aggregates as well, but as these 31203 are harder to fix, I've left it as kfail. 31204 31205 As this is Ada-specific, and has already been tested internally at 31206 AdaCore, I am checking it in. 31207 312082023-08-16 Tom Tromey <tromey@adacore.com> 31209 31210 Implement DAP module-removed event 31211 DAP specifies an event that should be sent when a module is removed. 31212 This patch implements this. 31213 31214 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 31215 312162023-08-16 Andrew Burgess <aburgess@redhat.com> 31217 31218 gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp 31219 I ran into a test failure on gdb.python/py-thread-exited.c. The test 31220 creates two threads and then catches the thread exits in Python. The 31221 test expects the threads to exit in a specific order. 31222 31223 As the test is currently written, it is _likely_, but not guaranteed, 31224 that the threads will exit in the same order they are created, which 31225 is what the test expects. 31226 31227 When running on a loaded system I ran into a case where the threads 31228 exited in the reverse creation order, which caused the test to fail. 31229 31230 I could fix this by having the .exp file not care about the thread 31231 order, or by changing the C file to force the order. I chose the 31232 later, and added a pthread_barrier_t to ensure the threads exit in the 31233 correct order. 31234 31235 There should be no change in what is tested after this commit. 31236 312372023-08-16 Andrew Burgess <aburgess@redhat.com> 31238 31239 gdb: fix vfork regressions when target-non-stop is off 31240 It was pointed out on the mailing list[1] that after this commit: 31241 31242 commit b1e0126ec56e099d753c20e91a9f8623aabd6b46 31243 Date: Wed Jun 21 14:18:54 2023 +0100 31244 31245 gdb: don't resume vfork parent while child is still running 31246 31247 the test gdb.base/vfork-follow-parent.exp now has some failures when 31248 run with the native-gdbserver or native-extended-gdbserver boards: 31249 31250 FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout) 31251 FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout) 31252 FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout) 31253 FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout) 31254 31255 The reason that these failures don't show up when run on the standard 31256 unix board is that the test is only run in the default operating mode, 31257 so for Linux this will be all-stop on top of non-stop. 31258 31259 If we adjust the test script so that it runs in the default mode and 31260 with target-non-stop turned off, then we see the same failures on the 31261 unix board. This commit includes this change. 31262 31263 The way that the test is written means that it is not (currently) 31264 possible to turn on non-stop mode and have the test still work, so 31265 this commit does not do that. 31266 31267 I have also updated the test script so that the vfork child performs 31268 an exec as well as the current exit. Exec and exit are the two ways 31269 in which a vfork child can release the vfork parent, so testing both 31270 of these cases is useful I think. 31271 31272 In this test the inferior performs a vfork and the vfork-child 31273 immediately exits. The vfork-parent will wait for the vfork-child and 31274 then blocks waiting for gdb. Once gdb has released the vfork-parent, 31275 the vfork-parent also exits. 31276 31277 In the test that fails, GDB sets 'detach-on-fork off' and then runs to 31278 the vfork. At this point the test tries to just "continue", but this 31279 fails as the vfork-parent is still selected, and the parent can't 31280 continue until the vfork-child completes. As the vfork-child is 31281 stopped by GDB the parent will never stop once resumed, so GDB refuses 31282 to resume it. 31283 31284 The test script then sets 'schedule-multiple on' and once again 31285 continues. This time GDB, in theory, resumes both the parent and the 31286 child, the parent will be held blocked by the kernel, but the child 31287 will run until it exits, and which point GDB stops again, this time 31288 with inferior 2, the newly exited vfork-child, selected. 31289 31290 What happens after this in the test script is irrelevant as far as 31291 this failure is concerned. 31292 31293 To understand why the test started failing we should consider the 31294 behaviour of four different cases: 31295 31296 1. All-stop-on-non-stop before commit b1e0126ec56e, 31297 31298 2. All-stop-on-non-stop after commit b1e0126ec56e, 31299 31300 3. All-stop-on-all-stop before commit b1e0126ec56e, and 31301 31302 4. All-stop-on-all-stop after commit b1e0126ec56e. 31303 31304 Only case #4 is failing after commit b1e0126ec56e, but I think the 31305 other cases are interesting because, (a) they inform how we might fix 31306 the regression, and (b) it turns out the behaviour of #2 changed too 31307 with the commit, but the change was harmless. 31308 31309 For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens 31310 is: 31311 31312 1. GDB calls proceed with the vfork-parent selected, as schedule 31313 multiple is on user_visible_resume_ptid returns -1 (everything) 31314 as the resume_ptid (see proceed function), 31315 31316 2. As this is all-stop-on-non-stop, every thread is resumed 31317 individually, so GDB tries to resume both the vfork-parent and the 31318 vfork-child, both of which succeed, 31319 31320 3. The vfork-parent is held stopped by the kernel, 31321 31322 4. The vfork-child completes (exits) at which point the GDB sees the 31323 EXITED event for the vfork-child and the VFORK_DONE event for the 31324 vfork-parent, 31325 31326 5. At this point we might take two paths depending on which event 31327 GDB handles first, if GDB handles the VFORK_DONE first then: 31328 31329 (a) As GDB is controlling both parent and child the VFORK_DONE is 31330 ignored (see handle_vfork_done), the vfork-parent will be 31331 resumed, 31332 31333 (b) GDB processes the EXITED event, selects the (now defunct) 31334 vfork-child, and stops, returning control to the user. 31335 31336 Alternatively, if GDB selects the EXITED event first then: 31337 31338 (c) GDB processes the EXITED event, selects the (now defunct) 31339 vfork-child, and stops, returning control to the user. 31340 31341 (d) At some future time the user resumes the vfork-parent, at 31342 which point the VFORK_DONE is reported to GDB, however, GDB 31343 is ignoring the VFORK_DONE (see handle_vfork_done), so the 31344 parent is resumed. 31345 31346 For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the 31347 important difference is in step (2) above, now, instead of resuming 31348 both the vfork-parent and the vfork-child, only the vfork-child is 31349 resumed. As such, when we get to step (5), only a single event, the 31350 EXITED event is reported. 31351 31352 GDB handles the EXITED just as in (5)(c), then, later, when the user 31353 resumes the vfork-parent, the VFORKED_DONE is immediately delivered 31354 from the kernel, but this is ignored just as in (5)(d), and so, 31355 though the pattern of when the vfork-parent is resumed changes, the 31356 overall pattern of which events are reported and when, doesn't 31357 actually change. In fact, by not resuming the vfork-parent, the order 31358 of events (in this test) is now deterministic, which (maybe?) is a 31359 good thing. 31360 31361 If we now consider case #3, all-stop-on-all-stop before commit 31362 b1e0126ec56e, then what happens is: 31363 31364 1. GDB calls proceed with the vfork-parent selected, as schedule 31365 multiple is on user_visible_resume_ptid returns -1 (everything) 31366 as the resume_ptid (see proceed function), 31367 31368 2. As this is all-stop-on-all-stop, the resume is passed down to the 31369 linux-nat target, the vfork-parent is the event thread, while the 31370 vfork-child is a sibling of the event thread, 31371 31372 3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback 31373 for all threads, this causes the vfork-child to be resumed. Then 31374 in linux_nat_target::resume, the event thread, the vfork-parent, 31375 is also resumed. 31376 31377 4. The vfork-parent is held stopped by the kernel, 31378 31379 5. The vfork-child completes (exits) at which point the GDB sees the 31380 EXITED event for the vfork-child and the VFORK_DONE event for the 31381 vfork-parent, 31382 31383 6. We are now in a situation identical to step (5) as for 31384 all-stop-on-non-stop above, GDB selects one of the events to 31385 handle, and whichever we select the user sees the correct 31386 behaviour. 31387 31388 And so, finally, we can consider #4, all-stop-on-all-stop after commit 31389 b1e0126ec56e, this is the case that started failing. 31390 31391 We start out just like above, in proceed, the resume_ptid is 31392 -1 (resume everything), due to schedule multiple being on. And just 31393 like above, due to the target being all-stop, we call 31394 proceed_resume_thread_checked just once, for the current thread, 31395 which, remember, is the vfork-parent thread. 31396 31397 The change in commit b1e0126ec56e was to avoid resuming a vfork-parent 31398 thread, read the commit message for the justification for this change. 31399 31400 However, this means that GDB now rejects resuming the vfork-parent in 31401 this case, which means that nothing gets resumed! Obviously, if 31402 nothing resumes, then nothing will ever stop, and so GDB appears to 31403 hang. 31404 31405 I considered a couple of solutions which, in the end, I didn't go 31406 with, these were: 31407 31408 1. Move the vfork-parent check out of proceed_resume_thread_checked, 31409 and place it in proceed, but only on the all-stop-on-non-stop 31410 path, this should still address the issue seen in b1e0126ec56e, 31411 but would avoid the issue seen here. I rejected this just 31412 because it didn't feel great to split the checks that exist in 31413 proceed_resume_thread_checked like this, 31414 31415 2. Extend the condition in proceed_resume_thread_checked by adding a 31416 target_is_non_stop_p check. This would have the same effect as 31417 idea 1, but leaves all the checks in the same place, which I 31418 think would be better, but this still just didn't feel right to 31419 me, and so, 31420 31421 What I noticed was that for the all-stop-on-non-stop, after commit 31422 b1e0126ec56e, we only resumed the vfork-child, and this seems fine. 31423 The vfork-parent isn't going to run anyway (the kernel will hold it 31424 back), so if feels like we there's no harm in just waiting for the 31425 child to complete, and then resuming the parent. 31426 31427 So then I started looking at follow_fork, which is called from the top 31428 of proceed. This function already has the task of switching between 31429 the parent and child based on which the user wishes to follow. So, I 31430 wondered, could we use this to switch to the vfork-child in the case 31431 that we are attached to both? 31432 31433 Turns out this is pretty simple to do. 31434 31435 Having done that, now the process is for all-stop-on-all-stop after 31436 commit b1e0126ec56e, and with this new fix is: 31437 31438 1. GDB calls proceed with the vfork-parent selected, but, 31439 31440 2. In follow_fork, and follow_fork_inferior, GDB switches the 31441 selected thread to be that of the vfork-child, 31442 31443 3. Back in proceed user_visible_resume_ptid returns -1 (everything) 31444 as the resume_ptid still, but now, 31445 31446 4. When GDB calls proceed_resume_thread_checked, the vfork-child is 31447 the current selected thread, this is not a vfork-parent, and so 31448 GDB allows the proceed to continue to the linux-nat target, 31449 31450 5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback 31451 for all threads, this does not resume the vfork-parent (because 31452 it is a vfork-parent), and then the vfork-child is resumed as 31453 this is the event thread, 31454 31455 At this point we are back in the same situation as for 31456 all-stop-on-non-stop after commit b1e0126ec56e, that is, the 31457 vfork-child is resumed, while the vfork-parent is held stopped by 31458 GDB. 31459 31460 Eventually the vfork-child will exit or exec, at which point the 31461 vfork-parent will be resumed. 31462 31463 [1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/ 31464 314652023-08-16 Paul Iannetta <piannetta@kalrayinc.com> 31466 31467 kvx: New port. 31468 314692023-08-16 Richard Ball <richard.ball@arm.com> 31470 31471 aarch64: Enable Cortex-A720 CPU 31472 This patch adds support for the Cortex-A720 CPU to binutils. 31473 31474 bfd/ChangeLog: 31475 31476 * cpu-aarch64.c: Add Cortex-A720. 31477 31478 gas/ChangeLog: 31479 31480 * NEWS: Update docs. 31481 * config/tc-aarch64.c: Add Cortex-A720. 31482 * doc/c-aarch64.texi: Update docs. 31483 * testsuite/gas/aarch64/cpu-cortex-a720.d: New test. 31484 314852023-08-16 Puputti, Matti <matti.puputti@intel.com> 31486 31487 gdb, infcmd: support jump command in multi-inferior case 31488 Fixes the issue where jump failed if multiple inferiors run the same 31489 source. 31490 31491 See the below example 31492 31493 $ gdb -q ./simple 31494 Reading symbols from ./simple... 31495 (gdb) break 2 31496 Breakpoint 1 at 0x114e: file simple.c, line 2. 31497 (gdb) run 31498 Starting program: /temp/simple 31499 31500 Breakpoint 1, main () at simple.c:2 31501 2 int a = 42; 31502 (gdb) add-inferior 31503 [New inferior 2] 31504 Added inferior 2 on connection 1 (native) 31505 (gdb) inferior 2 31506 [Switching to inferior 2 [<null>] (<noexec>)] 31507 (gdb) info inferiors 31508 Num Description Connection Executable 31509 1 process 6250 1 (native) /temp/simple 31510 * 2 <null> 1 (native) 31511 (gdb) file ./simple 31512 Reading symbols from ./simple... 31513 (gdb) run 31514 Starting program: /temp/simple 31515 31516 Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2 31517 2 int a = 42; 31518 (gdb) info inferiors 31519 Num Description Connection Executable 31520 1 process 6250 1 (native) /temp/simple 31521 * 2 process 6705 1 (native) /temp/simple 31522 (gdb) jump 3 31523 Unreasonable jump request 31524 (gdb) 31525 31526 In this example, jump fails because the debugger finds two different 31527 locations, one for each inferior. 31528 31529 Solution is to limit the search to the current program space. 31530 31531 This is done by having the jump_command function use 31532 decode_line_with_current_source rather than 31533 decode_line_with_last_displayed, which makes sense, 31534 the *_current_source function always looks up a location based on the 31535 current thread's location -- if a user is asking the current thread to 31536 jump, then surely their destination should be relative to where the 31537 current thread is located. 31538 31539 Then, inside decode_line_with_current_source, the call to 31540 decode_line_1 is updated to pass through the current program_space, 31541 which will limit the returned locations to those in the current 31542 program space. 31543 31544 Approved-By: Andrew Burgess <aburgess@redhat.com> 31545 315462023-08-16 GDB Administrator <gdbadmin@sourceware.org> 31547 31548 Automatic date update in version.in 31549 315502023-08-15 Tom Tromey <tromey@adacore.com> 31551 31552 Mention process_stratum in inferior::priv comment 31553 From what I can tell, inferior::priv is reserved for the 31554 process_stratum target. It seems to me that it has to be, because 31555 currenlty only such targets use it, and if a target at another stratum 31556 started using this field, then conflicts could occur. This patch 31557 documents this. 31558 31559 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 31560 315612023-08-15 Nick Clifton <nickc@redhat.com> 31562 31563 Updated Russian translation for the bfd directory 31564 315652023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com> 31566 31567 RISC-V: Make T-Head testing pattern more generic 31568 On some T-Head vendor extensions, we test against the constant 31569 18446744073709551615 (2**64-1) to detect invalid immediate errors on -1. 31570 However, it heavily depends on the fact that the value used to print 31571 immediate value is a 64-bit unsigned type and this constant is not (and 31572 should not be) important (we just want to know that -1 is not valid). 31573 31574 This commit replaces all such occurrences of 18446744073709551615 with 31575 a more generic regular expression. 31576 31577 gas/ChangeLog: 31578 31579 * testsuite/gas/riscv/x-thead-ba-fail.l: Replace 31580 18446744073709551615 with generic regular expression. 31581 * testsuite/gas/riscv/x-thead-bb-fail.l: Likewise. 31582 * testsuite/gas/riscv/x-thead-bs-fail.l: Likewise. 31583 * testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise. 31584 * testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise. 31585 * testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise. 31586 315872023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com> 31588 31589 RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa' 31590 The documentation of the 'Zfa' extension states that "fli.h" is available 31591 "if the Zfh or Zvfh extension is implemented" (both the latest and the 31592 oldest editions are checked). 31593 31594 This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full 31595 'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions). 31596 This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh' 31597 extensions are implemented. 31598 31599 bfd/ChangeLog: 31600 31601 * elfxx-riscv.c (riscv_multi_subset_supports): Add new 31602 instruction class handling. 31603 (riscv_multi_subset_supports_ext): Likewise. 31604 31605 gas/ChangeLog: 31606 31607 * testsuite/gas/riscv/zfa-zvfh.s: New test. 31608 * testsuite/gas/riscv/zfa-zvfh.d: Ditto. 31609 31610 include/ChangeLog: 31611 31612 * opcode/riscv.h (enum riscv_insn_class): Add new instruction 31613 class. 31614 31615 opcodes/ChangeLog: 31616 31617 * riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h" 31618 from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA. 31619 316202023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com> 31621 Nelson Chu <nelson@rivosinc.com> 31622 31623 RISC-V: Add support for the 'Zihintntl' extension 31624 This commit adds 'Zihintntl' extension and its hint instructions. 31625 31626 This is based on: 31627 <https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>, 31628 the first ISA Manual noting that the 'Zihintntl' extension is ratified. 31629 31630 Note that compressed 'Zihintntl' hints require either 'C' or 31631 'Zca' extension. 31632 31633 31634 bfd/ChangeLog: 31635 31636 * elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl' 31637 standard hint 'Z' extension. 31638 (riscv_multi_subset_supports): Support new instruction classes. 31639 (riscv_multi_subset_supports_ext): Likewise. 31640 31641 gas/ChangeLog: 31642 31643 * testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl' 31644 including auto-compression without C prefix and explicit C prefix. 31645 * testsuite/gas/riscv/zihintntl.d: Likewise. 31646 * testsuite/gas/riscv/zihintntl-na.d: Likewise. 31647 * testsuite/gas/riscv/zihintntl-base.s: New test for correspondence 31648 between 'Zihintntl' and base 'I' or 'C' instructions. 31649 * testsuite/gas/riscv/zihintntl-base.d: Likewise. 31650 31651 include/ChangeLog: 31652 31653 * opcode/riscv.h (enum riscv_insn_class): Add new instruction 31654 classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C. 31655 (MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL, 31656 MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL, 31657 MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL, 31658 MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL, 31659 MATCH_C_NTL_ALL): New. 31660 31661 opcodes/ChangeLog: 31662 31663 * riscv-opc.c (riscv_opcodes): Add instructions from the 31664 'Zihintntl' extension. 31665 316662023-08-15 Jan Beulich <jbeulich@suse.com> 31667 31668 RISC-V: remove indirection from register tables 31669 The longest register name is 4 characters (plus a nul one), so using a 31670 4- or 8-byte pointer to get at it is neither space nor time efficient. 31671 Embed the names right into the array. For PIE this also reduces the 31672 number of base relocations in the final image. 31673 31674 To avoid old gcc, when generating 32-bit code, bogusly warning about 31675 bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD, 31676 an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply 31677 a 64-bit value, and it also doesn't need to - all operand fields to 31678 date are far more narrow than 32 bits. This in turn allows dropping a 31679 number of casts elsewhere. 31680 316812023-08-15 Jan Beulich <jbeulich@suse.com> 31682 31683 PPC: remove indirection from struct pd_reg 31684 The longest register name is 5 characters (plus a nul one), so using a 31685 4- or 8-byte pointer to get at it is neither space nor time efficient. 31686 Embed the names right into the array. For PIE this also reduces the 31687 number of base relocations in the final image. 31688 316892023-08-15 GDB Administrator <gdbadmin@sourceware.org> 31690 31691 Automatic date update in version.in 31692 316932023-08-14 Tom de Vries <tdevries@suse.de> 31694 31695 [gdb/build] Fix YYSTYPE and yyalloc odr violation 31696 When building gdb with -O2 -flto I run into: 31697 ... 31698 ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \ 31699 Definition Rule [-Werror=odr] 31700 ... 31701 31702 Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files. 31703 31704 Likewise for yyalloc. 31705 31706 Tested on x86_64-linux. Also tested with byacc rather than bison on 31707 suggestion of Tom Tromey. 31708 31709 Approved-By: Tom Tromey <tom@tromey.com> 31710 31711 PR build/22395 31712 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 31713 317142023-08-14 John Baldwin <jhb@FreeBSD.org> 31715 31716 fbsd-nat: Stop a process if it is running before killing it. 31717 In addition, detach from any child processes implicitly attached to by 31718 the kernel due to fork following that have not yet been processed by 31719 GDB's core. 31720 317212023-08-14 John Baldwin <jhb@FreeBSD.org> 31722 31723 fbsd-nat: Fix thread_alive against a running thread. 31724 FreeBSD's ptrace fails requests with EBUSY against a running process. 31725 Report that the thread is alive instead of dead if ptrace fails with 31726 EBUSY. 31727 31728 This fixes an internal error in the gdb.threads/detach-step-over.exp 31729 test where one process was detached while a thread in a second process 31730 was being stepped. The core incorrectly assumed the stepping thread 31731 had vanished and discarded the pending stepping state. When the 31732 thread later reported a SIGTRAP from completing the step, this 31733 triggered an assertion. 31734 317352023-08-14 John Baldwin <jhb@FreeBSD.org> 31736 31737 fbsd-nat: Fix several issues with detaching. 31738 - Detach from any child processes implicitly attached to by the kernel 31739 due to fork following that have not yet been processed by GDB's 31740 core. 31741 31742 - Delete breakpoints before detaching. 31743 31744 inf-ptrace::detach does not do this (somewhat surprisingly), so add 31745 an override to remove breakpoints from a process before detaching 31746 from it. 31747 31748 This also requires explicitly draining any pending SIGTRAP events 31749 for software breakpoints before detaching. In particular, threads 31750 may need their PC adjusted due to the software breakpoint before 31751 being resumed after detach. On more modern systems using the si_code 31752 from SIGTRAP to identify software breakpoint traps, the PC is adjusted 31753 in ::wait_1 as a side effect of parsing the event. To support older 31754 kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential 31755 new PC matches an existing software breakpoint. 31756 317572023-08-14 John Baldwin <jhb@FreeBSD.org> 31758 31759 fbsd-nat: Fix resuming and waiting with multiple processes. 31760 I did not fully understand the requirements of multiple process 31761 support when I enabled it previously and several parts were broken. 31762 In particular, the resume method was only resuming a single process, 31763 and wait was not stopping other processes when reporting an event. 31764 31765 To support multiple running inferiors, add a new per-inferior 31766 structure which trackes the number of existing and running LWPs for 31767 each process. The structure also stores a ptid_t describing the 31768 set of LWPs currently resumed for each process. 31769 31770 For the resume method, iterate over all non-exited inferiors resuming 31771 each process matching the passed in ptid rather than only resuming the 31772 current inferior's process for a wildcard ptid. If a resumed process 31773 has a pending event, don't actually resume the process, but other 31774 matching processes without a pending event are still resumed in case 31775 the later call to the wait method requests an event from one of the 31776 processes without a pending event. 31777 31778 For the wait method, stop other running processes before returning an 31779 event to the core. When stopping a process, first check to see if an 31780 event is already pending. If it is, queue the event to be reported 31781 later. If not, send a SIGSTOP to the process and wait for it to stop. 31782 If the event reported by the wait is not for the SIGSTOP, queue the 31783 event and remember to ignore a future SIGSTOP event for the process. 31784 31785 Note that, unlike the Linux native target, entire processes are 31786 stopped rather than individual LWPs. In FreeBSD one can only wait on 31787 processes (via pid), not for an event from a specific thread. 31788 31789 Other changes in this commit handle bookkeeping for the per-inferior 31790 data such as migrating the data to the new inferior in the follow_exec 31791 method. The per-inferior data is created in the attach, 31792 create_inferior, and follow_fork methods. 31793 317942023-08-14 John Baldwin <jhb@FreeBSD.org> 31795 31796 fbsd-nat: Defer any ineligible events reported by wait. 31797 If wait_1 finds an event for a thread or process that does not match 31798 the set of threads and processes previously resumed, defer the event. 31799 If the event is for a specific thread, suspend the thread and continue 31800 the associated process before waiting for another event. 31801 31802 One specific example of such an event is if a thread is created while 31803 another thread in the same process hits a breakpoint. If the second 31804 thread's event is reported first, the target resume method does not 31805 yet "know" about the new thread and will not suspend it via 31806 PT_SUSPEND. When wait is called, it will probably return the event 31807 from the first thread before the result of the step from second 31808 thread. This is the case reported in PR 21497. 31809 31810 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21497 31811 318122023-08-14 John Baldwin <jhb@FreeBSD.org> 31813 31814 fbsd-nat: Add a list of pending events. 31815 The m_pending_events list stores a queue of deferred events that might 31816 be reported by the next call to the target's wait method. The set of 31817 events that are eligible is filtered by the ptid passed to resume. 31818 31819 For now this just replaces the list of vfork_done events. A 31820 subsequent commit will reuse this to store other events. 31821 318222023-08-14 Tom Tromey <tom@tromey.com> 31823 31824 Remove alloca from osabi.c 31825 I noticed that the call to alloca in osabi.c can be replaced with a 31826 statically-sized buffer, because some code just before the declaration 31827 ensures that the length is bounded. 31828 31829 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 31830 318312023-08-14 Tom de Vries <tdevries@suse.de> 31832 31833 [gdb/build] Fix struct token odr violation 31834 When building gdb with -O2 -flto I run into: 31835 ... 31836 /data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \ 31837 violates the C++ One Definition Rule [-Wodr] 31838 struct token 31839 ^ 31840 /data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \ 31841 another translation unit 31842 struct token 31843 ^ 31844 ... 31845 31846 Fix this by renaming to c_token and d_token. 31847 31848 Likewise in: 31849 - fortran-exp.y, renaming to f_token, 31850 - go-exp.y, renaming to go_token, and 31851 - p-exp.y, renaming to p_token. 31852 31853 Tested on x86_64-linux. 31854 31855 Approved-By: Tom Tromey <tom@tromey.com> 31856 31857 PR build/22395 31858 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 31859 318602023-08-14 Tom de Vries <tdevries@suse.de> 31861 31862 [gdb/build] Fix struct token_and_value odr violation 31863 When build gdb with -O2 -flto I run into: 31864 ... 31865 gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \ 31866 One Definition Rule [-Wodr] 31867 struct token_and_value 31868 ^ 31869 gdb/d-exp.y:1310:8: note: a different type is defined in another translation \ 31870 unit 31871 struct token_and_value 31872 ^ 31873 ... 31874 31875 Fix this by renaming to c_token_and_value and d_token_and_value. 31876 31877 Likewise in gdb/go-exp.y, renaming to go_token_and_value. 31878 31879 Tested on x86_64-linux. 31880 31881 Approved-By: Tom Tromey <tom@tromey.com> 31882 31883 PR build/22395 31884 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 31885 318862023-08-14 Tom de Vries <tdevries@suse.de> 31887 31888 [gdb/build] Fix enum param_types odr violation 31889 When building gdb with -O2 -flto, I run into: 31890 ... 31891 gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \ 31892 One Definition Rule [-Wodr] 31893 enum param_types 31894 ^ 31895 gdb/python/py-param.c:33:6: note: an enum with different value name is \ 31896 defined in another translation unit 31897 enum param_types 31898 ^ 31899 ... 31900 31901 Fix this by renaming to enum scm_param_types and py_param_types. 31902 31903 Tested on x86_64-linux. 31904 31905 Approved-By: Tom Tromey <tom@tromey.com> 31906 31907 PR build/22395 31908 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 31909 319102023-08-14 Tom de Vries <tdevries@suse.de> 31911 31912 [gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c 31913 In gdb/python/py-param.c we have: 31914 ... 31915 enum param_types 31916 { 31917 ... 31918 } 31919 param_types; 31920 ... 31921 which declares both an enum param_types, and an unused variable param_types. 31922 31923 Fix this by removing the variable. 31924 31925 Tested on x86_64-linux. 31926 31927 Approved-By: Tom Tromey <tom@tromey.com> 31928 319292023-08-14 Tom de Vries <tdevries@suse.de> 31930 31931 [gdb] Fix maint print symbols/psymbols help text 31932 Consider the help text of "maint print symbols": 31933 ... 31934 (gdb) help maint print symbols 31935 Print dump of current symbol definitions. 31936 Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE] 31937 mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE] 31938 Entries in the full symbol table are dumped to file OUTFILE, 31939 or the terminal if OUTFILE is unspecified. 31940 If ADDRESS is provided, dump only the file for that address. 31941 If SOURCE is provided, dump only that file's symbols. 31942 If OBJFILE is provided, dump only that file's minimal symbols. 31943 ... 31944 and "maint print psymbols": 31945 ... 31946 (gdb) help maint print psymbols 31947 Print dump of current partial symbol definitions. 31948 Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE] 31949 mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE] 31950 Entries in the partial symbol table are dumped to file OUTFILE, 31951 or the terminal if OUTFILE is unspecified. 31952 If ADDRESS is provided, dump only the file for that address. 31953 If SOURCE is provided, dump only that file's symbols. 31954 If OBJFILE is provided, dump only that file's minimal symbols. 31955 ... 31956 31957 The OBJFILE lines mistakingly mention minimal symbols. 31958 31959 Fix this by reformulating as "dump only that object file's symbols". 31960 31961 Also make the ADDRESS lines more clear by using the formulation: "dump only 31962 the symbols for the file with code at that address". 31963 31964 Tested on x86_64-linux. 31965 31966 Co-Authored-By: Eli Zaretskii <eliz@gnu.org> 31967 31968 PR gdb/30742 31969 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742 31970 319712023-08-14 H.J. Lu <hjl.tools@gmail.com> 31972 31973 ld: Build libpr23169a.so with -z lazy 31974 pr23169b test only works with lazy binding. To work with linker which 31975 disables lazy binding by default, build pr23169b binaries with -z lazy. 31976 31977 PR ld/30698 31978 * ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy. 31979 319802023-08-14 Alan Modra <amodra@gmail.com> 31981 31982 Remove fall-back prune_warnings 31983 No one should be using versions of dejagnu without prune_warnings, 31984 which was available in 1996 (dejagnu-1.3). 31985 31986 binutils/ 31987 * testsuite/lib/binutils-common.exp: Remove fallback prune_warnings. 31988 gas/ 31989 * testsuite/lib/gas-defs.exp: Remove fallback prune_warnings. 31990 319912023-08-14 Alan Modra <amodra@gmail.com> 31992 31993 Re: PR30715, VAX: md_create_long_jump 31994 Tidy comment formatting. 31995 319962023-08-14 Sam James <sam@gentoo.org> 31997 31998 ld: fix relocatable, retain7a target pattens for HPPA 31999 Fix issue reported by Dave and Alan. 32000 32001 Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover 32002 Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did 32003 before. 32004 32005 ld/ 32006 PR 30733 32007 PR 30734 32008 * ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64 32009 but include hppa1.1, hppa2.0. 32010 * ld/testsuite/ld-elf/retain7a.d: Ditto. 32011 32012 Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49 32013 Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5 32014 320152023-08-14 GDB Administrator <gdbadmin@sourceware.org> 32016 32017 Automatic date update in version.in 32018 320192023-08-13 Tom de Vries <tdevries@suse.de> 32020 32021 [gdb/symtab] Don't deduplicate variables in gdb-index 32022 When running test-case gdb.python/py-symbol.exp with target board 32023 cc-with-gdb-index, we run into: 32024 ... 32025 (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 32026 1^M 32027 (gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr'))) 32028 ... 32029 32030 [ Note that the test-case contains rr in both py-symtab.c: 32031 ... 32032 static int __attribute__ ((used)) rr = 42; /* line of rr */ 32033 ... 32034 and py-symtab-2.c: 32035 ... 32036 static int __attribute__ ((used)) rr = 99; /* line of other rr */ 32037 ... ] 32038 32039 This passes with gdb-12-branch, and fails with gdb-13-branch. 32040 32041 AFAIU the current code in symtab_index_entry::minimize makes the assumption 32042 that it's fine to store only one copy of rr in the gdb-index, because 32043 "print rr" will only ever print one, and always the same. 32044 32045 But that fails to recognize that gdb supports gdb.lookup_static_symbols, which 32046 returns a list of variables rather than the first one. 32047 32048 In other words, the current approach breaks feature parity between cooked 32049 index and gdb-index. 32050 32051 Note btw that also debug-names has both instances: 32052 ... 32053 [ 5] #00597969 rr: 32054 <4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1 32055 <4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1 32056 ... 32057 32058 Fix this in symtab_index_entry::minimize, by not deduplicating variables. 32059 32060 Tested on x86_64-linux, with target boards unix and cc-with-gdb-index. 32061 32062 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 32063 32064 PR symtab/30720 32065 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720 32066 320672023-08-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 32068 32069 gprofng: pass gprofng location to gp-display-gui 32070 gprofng GUI can be installed to the other directory. 32071 In this case, $PATH is used to find gp-display-gui from gprofng 32072 and option --gprofngdir is passed to gp-display-gui. 32073 32074 gprofng/ChangeLog 32075 2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 32076 32077 * src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir. 32078 320792023-08-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 32080 32081 gprofng: fix typos in get_realpath() and check_executable() 32082 gprofng/ChangeLog 32083 2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 32084 32085 * src/Application.cc (Application::get_realpath): Fix typo. 32086 * src/checks.cc (collect::check_executable): Likewise. 32087 320882023-08-13 GDB Administrator <gdbadmin@sourceware.org> 32089 32090 Automatic date update in version.in 32091 320922023-08-13 Alan Modra <amodra@gmail.com> 32093 32094 Re: gdb: warn unused result for bfd IO functions 32095 Add a missing return statement. 32096 320972023-08-12 Kalvis Duckmanton <kalvisd@gmail.com> 32098 32099 PR30715, VAX: md_create_long_jump 32100 PR 30715 32101 * config/tc-vax.c (md_create_long_jump): Use pc-relative addressing. 32102 * testsuite/gas/vax/broken_word.d, 32103 * testsuite/gas/vax/broken_word.s: New test. 32104 * testsuite/gas/vax/vax.exp: Run it. 32105 321062023-08-12 Kevin Buettner <kevinb@redhat.com> 32107 32108 gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps 32109 At the moment, while performing a software single-step, gdbserver fails 32110 to reinsert software single-step breakpoints for a LWP when 32111 interrupted by a signal in another thread. This commit fixes this 32112 problem by reinstalling software single-step breakpoints in 32113 linux_process_target::resume_stopped_resumed_lwps in 32114 gdbserver/linux-low.cc. 32115 32116 This bug was discovered due to a failing assert in maybe_hw_step() 32117 in gdbserver/linux-low.cc. Looking at the backtrace revealed 32118 that the caller was linux_process_target::resume_stopped_resumed_lwps. 32119 I was uncertain whether the assert should still be valid when called 32120 from that method, so I tried hoisting the assert from maybe_hw_step 32121 to all callers except resume_stopped_resumed_lwps. But running the 32122 new test case, described below, showed that merely eliminating the 32123 assert for this case was NOT a good fix - a study of the log file for 32124 the test showed that the single-step operation failed to occur. 32125 Instead GDB (via gdbserver) stopped at the next breakpoint that was 32126 hit. 32127 32128 Zhiyong Yan had proposed a fix which resinserted software single-step 32129 breakpoints, albeit at a different location in linux-low.cc. Testing 32130 revealed that, while running gdb.threads/pending-fork-event-detach, 32131 the executable associated with that test would die due to a SIGTRAP 32132 after the test program was detached. Examination of the core file(s) 32133 showed that a breakpoint instruction had been left in program memory. 32134 Test results were otherwise very good, so Zhiyong was definitely on 32135 the right track! 32136 32137 This commit causes software single-step breakpoint(s) to be inserted 32138 before the call to maybe_hw_step in resume_stopped_resumed_lwps. This 32139 will cause 'has_single_step_breakpoints (thread)' to be true, so that 32140 the assert in maybe_hw_step... 32141 32142 /* GDBserver must insert single-step breakpoint for software 32143 single step. */ 32144 gdb_assert (has_single_step_breakpoints (thread)); 32145 32146 ...will no longer fail. And better still, the single-step breakpoints 32147 are reinstalled, so that stepping will actually work, even when 32148 interrupted. 32149 32150 The C code for the test case was loosely adapted from the reproducer 32151 provided in Zhiyong's bug report for this problem. The .exp file was 32152 copied from next-fork-other-thread.exp and then tweaked slightly. As 32153 noted in a comment in next-fork-exec-other-thread.exp, I had to remove 32154 "on" from the loop for non-stop as it was failing on all architectures 32155 (including x86-64) that I tested. I have a feeling that it ought to 32156 work, but this can be investigated separately and (re)enabled once it 32157 works. I also increased the number of iterations for the loop running 32158 the "next" commands. I've had some test runs which don't show the bug 32159 until the loop counter exceeded 100 iterations. The C file for the 32160 new test uses shorter delays than next-fork-other-thread.c though, so 32161 it doesn't take overly long (IMO) to run this new test. 32162 32163 Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and 32164 userland using a gdbserver build without the fix in this commit shows 32165 the following results: 32166 32167 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line 32168 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line 32169 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line 32170 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line 32171 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line 32172 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line 32173 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here 32174 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here 32175 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here 32176 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line 32177 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line 32178 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here 32179 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here 32180 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here 32181 32182 === gdb Summary === 32183 32184 # of unexpected core files 12 32185 # of expected passes 3011 32186 # of unexpected failures 14 32187 32188 Each of the 12 core files were caused by the failed assertion in 32189 maybe_hw_step in linux-low.c. These correspond to 12 of the 32190 unexpected failures. 32191 32192 When the tests are run using a gdbserver build which includes the fix 32193 in this commit, the results are significantly better, but not perfect: 32194 32195 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line 32196 FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line 32197 32198 === gdb Summary === 32199 32200 # of expected passes 10178 32201 # of unexpected failures 2 32202 32203 I think that the two remaining failures are due to some different 32204 problem. They are also racy - I've seen runs with no failures or only 32205 one failure, but never more than two. Also, those runs were conducted 32206 with the loop count in next-fork-exec-other-thread.exp set to 200. 32207 During his testing of this fix and the new test case, Luis Machado 32208 found that this test was taking a long time and asked about ways to 32209 speed it up. I then conducted additional tests in which I gradually 32210 reduced the loop count, timing each one, also noting the number of 32211 failures. With the loop count set to 30, I found that I could still 32212 reliably reproduce the failures that Zhiyong reported (in which, with 32213 the proper settings, core files are created). But, with the loop 32214 count set to 30, the other failures noted above were much less likely 32215 to show up. Anyone wishing to investigate those other failures should 32216 set the loop count back up to 200. 32217 32218 Running the new test on x86-64 and aarch64, both native and 32219 native-gdbserver shows no failures. 32220 32221 Also, I see no regressions when running the entire test suite for 32222 armv7l-unknown-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit 32223 kernel+userland) with --target_board=native-gdbserver. Additionally, 32224 using --target_board=native-gdbserver, I also see no regressions for 32225 the entire test suite for x86-64 and aarch64 running Fedora 38. 32226 32227 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387 32228 Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com> 32229 Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com> 32230 Tested-By: Luis Machado <luis.machado@arm.com> 32231 322322023-08-12 Alan Modra <amodra@gmail.com> 32233 32234 regen config 32235 This regenerates config files changed by the previous 44 commits. 32236 Note that subject lines in these commits mostly match the gcc git 32237 originating commit. 32238 322392023-08-12 Arsen Arsenović <arsen@aarsen.me> 32240 32241 toplevel: Substitute GDCFLAGS instead of using CFLAGS 32242 r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already 32243 implemented this change, but only on the generated file rather than in 32244 the template it is generated from. 32245 32246 * Makefile.tpl: Substitute @GDCFLAGS@ instead of using 32247 $(CFLAGS). 32248 322492023-08-12 Andreas Schwab <schwab@suse.de> 32250 32251 Use substituted GDCFLAGS 32252 Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so 32253 that the subdir configure scripts use the configured value. 32254 32255 * configure.ac (GDCFLAGS): Set default from ${CFLAGS}. 32256 322572023-08-12 Philip Herron <philip.herron@embecosm.com> 32258 32259 gccrs: Add gcc-check-target check-rust 32260 This allows us to invoke the rust testsuite. 32261 32262 * Makefile.def: Add Rust language. 32263 322642023-08-12 Roger Sayle <roger@nextmovesoftware.com> 32265 32266 PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def 32267 This patch fixes PR bootstrap/106472 by adding a missing dependency 32268 to Makefile.def to allow make bootstrap when configured using 32269 "--enable-languages=go" (and not using make with multiple threads). 32270 32271 2022-07-31 Roger Sayle <roger@nextmovesoftware.com> 32272 32273 PR bootstrap/106472 32274 * Makefile.def (dependencies): Make configure-target-libgo depend 32275 upon all-target-libbacktrace. 32276 322772023-08-12 Thomas Schwinge <thomas@codesourcery.com> 32278 32279 Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102] 32280 322812023-08-12 Eugene Rozenfeld <erozen@microsoft.com> 32282 32283 Disable warnings as errors for STAGEautofeedback. 32284 Compilation during STAGEautofeedback produces additional warnings 32285 since inlining decisions with -fauto-profile are different from 32286 other builds. 32287 32288 This patches disables warnings as errors for STAGEautofeedback. 32289 32290 Tested on x86_64-pc-linux-gnu. 32291 32292 * Makefile.tpl: Disable warnings as errors for STAGEautofeedback 32293 322942023-08-12 Eugene Rozenfeld <erozen@microsoft.com> 32295 32296 Fix autoprofiledbootstrap build 32297 * Makefile.tpl: Define PROFILE_MERGER 32298 322992023-08-12 Eugene Rozenfeld <erozen@microsoft.com> 32300 32301 Fix collection and processing of autoprofile data for target libs 32302 cc1, cc1plus, and lto built during STAGEautoprofile need to be built with 32303 debug info since they are used to build target libs. -gtoggle was 32304 turning off debug info for this stage. 32305 32306 create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto 32307 instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when 32308 processing profile data collected while building target libraries. 32309 32310 Tested on x86_64-pc-linux-gnu. 32311 32312 * Makefile.tpl: Remove -gtoggle for STAGEautoprofile 32313 323142023-08-12 Eugene Rozenfeld <erozen@microsoft.com> 32315 32316 Collect both user and kernel events for autofdo tests and autoprofiledbootstrap 32317 When we collect just user events for autofdo with lbr we get some events where branch 32318 sources are kernel addresses and branch targets are user addresses. Without kernel MMAP 32319 events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if 32320 it can't map at least 95% of events. We sometimes get below this threshold with just 32321 user events. The change is to collect both user events and kernel events. 32322 32323 Tested on x86_64-pc-linux-gnu. 32324 32325 * Makefile.tpl: Collect both kernel and user events for autofdo 32326 323272023-08-12 Iain Buclaw <ibuclaw@gdcproject.org> 32328 32329 d: Import dmd b8384668f, druntime e6caaab9, phobos 5ab9ad256 (v2.098.0-beta.1) 32330 The D front-end is now itself written in D, in order to build GDC, you 32331 will need a working GDC compiler (GCC version 9.1 or later). 32332 32333 GCC changes: 32334 32335 - Add support for bootstrapping the D front-end. 32336 32337 These add the required components in order to have a D front-end written 32338 in D itself. Because the compiler front-end only depends on the core 32339 runtime modules, only libdruntime is built for the bootstrap stages. 32340 32341 D front-end changes: 32342 32343 - Import dmd v2.098.0-beta.1. 32344 32345 Druntime changes: 32346 32347 - Import druntime v2.098.0-beta.1. 32348 32349 Phobos changes: 32350 32351 - Import phobos v2.098.0-beta.1. 32352 32353 The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of 32354 development on the D programming language and run-time libraries. 32355 32356 * Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and 32357 libatomic. 32358 * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC. 32359 (STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if 32360 target-libphobos-bootstrap. 32361 (STAGE2_CONFIGURE_FLAGS): Likewise. 32362 323632023-08-12 Sergei Trofimovich <siarheit@google.com> 32364 32365 Makefile.def: drop remnants of unused libelf 32366 Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR 32367 lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0. 32368 32369 This change removes unused references to libelf from top-level configure 32370 and Makefile. 32371 32372 * Makefile.def: Drop libelf module and gcc-configure dependency 32373 on it. 32374 * Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and 32375 LIBELFINC. 32376 323772023-08-12 Martin Liska <mliska@suse.cz> 32378 32379 Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin. 32380 PR gcov-profile/94570 32381 * ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM 32382 for CYGWIN. 32383 32384 Co-Authored-By: Jonathan Yong <10walls@gmail.com> 32385 323862023-08-12 Christophe Lyon <christophe.lyon@st.com> 32387 32388 FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts 32389 In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared 32390 libraries support is required, as uclinux does not guarantee that. 32391 32392 * libtool.m4: Handle uclinuxfdpiceabi. 32393 323942023-08-12 Bernhard M. Wiedemann <bwiedemann@suse.de> 32395 32396 libtool.m4: Sort output of 'find' to enable deterministic builds. 32397 * libtool.m4: Sort output of 'find' to enable deterministic builds. 32398 * ltmain.sh: Likewise. 32399 324002023-08-12 John David Anglin <danglin@gcc.gnu.org> 32401 32402 Fix hppa64-hpux11 build to remove source paths from embedded path. 32403 This change adds the +nodefaultrpath ld option to remove all library 32404 paths that were specified with the -L option from the embedded path. 32405 32406 * libtool.m4 (archive_cmds): Add +nodefaultrpath ld option on 32407 hppa64-*-hpux11*. 32408 324092023-08-12 Olivier Hainque <hainque@adacore.com> 32410 32411 Generic configury support for shared libs on VxWorks 32412 This change adds the configury bits to activate the build of 32413 shared libs on VxWorks ports configured with --enable-shared, 32414 for libraries variants where this is generally supported (rtp, 32415 code model !large - currently not compatible with -fPIC). 32416 32417 Set lt_cv_deplibs_check_method in libtool.m4, so the build of 32418 libraries know how to establish dependencies. This is useful in 32419 configurations such as aarch64 where proper support of LSE relies 32420 on accurate dependency information between libstdc++ and libgcc_s 32421 to begin with. 32422 32423 * libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker 32424 and friends for rtp !large. Assume the linker has the required 32425 abilities and set lt_cv_deplibs_check_method. 32426 324272023-08-12 Arsen Arsenović <arsen@aarsen.me> 32428 32429 toplevel: reconcile few divergences with GCC 32430 * configure.ac: Reorder include. 32431 <is_elf calculation>: Re-add haiku to ELF target list. 32432 324332023-08-12 Max Filippov <jcmvbkbc@gmail.com> 32434 32435 gcc: xtensa: add data alignment properties to dynconfig 32436 include/ 32437 * xtensa-dynconfig.h (xtensa_config_v4): New struct. 32438 (XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION) 32439 (XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW) 32440 (XCHAL_UNALIGNED_STORE_HW, XTENSA_CONFIG_V4_ENTRY_LIST): New 32441 definitions. 32442 (XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v4 instance. 32443 (XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V4_ENTRY_LIST. 32444 32445 gcc: xtensa: add XCHAL_HAVE_{CLAMPS, DEPBITS, EXCLUSIVE, XEA3} to dynconfig 32446 include/ 32447 * xtensa-dynconfig.h (xtensa_config_v3): New struct. 32448 (xtensa_get_config_v3): New declaration. 32449 (XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS, XCHAL_HAVE_EXCLUSIVE) 32450 (XCHAL_HAVE_XEA3, XTENSA_CONFIG_V3_ENTRY_LIST): New definitions. 32451 (XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v3 instance. 32452 (XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V3_ENTRY_LIST. 32453 324542023-08-12 Jozef Lawrynowicz <jozefl@gcc.gnu.org> 32455 32456 MSP430: Add -fno-exceptions multilib 32457 * config-ml.in (msp430-*-*): Support --disable-no-exceptions configure 32458 flag. 32459 324602023-08-12 Iain Buclaw <ibuclaw@gcc.gnu.org> 32461 32462 Add D front-end, libphobos library, and D2 testsuite. 32463 * config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag 32464 environment variables. 32465 32466 Cherry picked from GCC commit b4c522fabd0df7be08882d2207df8b2765026110 32467 324682023-08-12 Jonathan Wakely <jwakely@redhat.com> 32469 32470 config-ml.in: Suppress output from multi-do recipes 32471 The FIXME comments saying "Leave out until this is tested a bit more" 32472 are from 1997. I think they've been sufficiently tested. 32473 32474 * config-ml.in (multi-do, multi-clean): Add @ to silence recipes. 32475 Remove FIXME comments. 32476 324772023-08-12 Sergei Trofimovich <siarheit@google.com> 32478 32479 mh-mingw: drop unused BOOT_CXXFLAGS variable 32480 gcc's build system has BOOT_CFLAGS and various STAGE<N>_C{,XX}FLAGS 32481 variables. BOOT_CXXFLAGS is not handled anywhere. 32482 32483 config/ 32484 * mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable. 32485 324862023-08-12 Martin Storsjö <martin@martin.st> 32487 32488 mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables 32489 This is similar to what was done in 32490 eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to 32491 STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and 32492 BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and 32493 BOOT_CFLAGS). 32494 32495 2021-04-09 Martin Storsjö <martin@martin.st> 32496 32497 config/ 32498 * mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags 32499 variables 32500 325012023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32502 32503 configure: Allow host fragments to react to --enable-host-shared. 32504 This makes the host_shared value available to host makefile 32505 fragments. 32506 32507 It uses this to adjust Darwin's mdynamic-no-pic in the case that 32508 shared host resources are required. 32509 32510 32511 config/ 32512 * mh-darwin: Require a non-shared host configuration to 32513 enable mdynamic-no-pic where that is supported. 32514 325152023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32516 32517 Darwin, config: Revise host config fragment. 32518 There were two uses for the Darwin host config fragment: 32519 32520 The first is to arrange for targets that support mdynamic-no-pic 32521 to be built with that enabled (since it makes a significant 32522 difference to the compiler performance). We can be more specific 32523 in the application of this, since it only applies to 32b hosts 32524 plus powerpc64-darwin9. 32525 32526 The second was to work around a tool bug where -fno-PIE was not 32527 propagated to the link stage. This second use is redundant, 32528 since the buggy toolchain cannot bootstrap current GCC sources 32529 anyway. 32530 32531 This makes the host fragment more specific and reduces the number 32532 of toolchains for which it is included which reduces clutter in 32533 configure lines. 32534 32535 32536 config/ 32537 * mh-darwin: Make this specific to handling the 32538 mdynamic-no-pic case. 32539 325402023-08-12 LIU Hao <lh_mouse@126.com> 32541 32542 gcc: Add 'mcf' thread model support from mcfgthread 32543 This patch adds the new thread model `mcf`, which implements mutexes 32544 and condition variables with the mcfgthread library. 32545 32546 Source code for mcfgthread is available at <https://github.com/lhmouse/mcfgthread>. 32547 32548 config/ 32549 * gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread 32550 model 32551 325522023-08-12 Andrew Pinski <apinski@marvell.com> 32553 32554 Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken 32555 So the problem here is that now the lto-plugin requires NM that works 32556 with LTO to work so we need to pass down NM just like we do for ranlib 32557 and ar. 32558 32559 config/ 32560 * bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR. 32561 * bootstrap-lto.mk: Likewise. 32562 325632023-08-12 Martin Liska <mliska@suse.cz> 32564 32565 32-bit PA-RISC with HP-UX: remove deprecated ports 32566 * configure.ac: Drop GCC configury for hpux10 32567 * configure: Likewise. 32568 config/ 32569 * mh-pa-hpux10: Drop. 32570 325712023-08-12 Gaius Mulley <gaiusmod2@gmail.com> 32572 32573 Merge modula-2 front end onto gcc. 32574 This commit merges the devel/modula2 into master. 32575 The libraries reside in libgm2, the compiler in gcc/m2 32576 and the testsuite in gcc/testsuite/gm2. 32577 32578 * configure.ac (target_libraries): Add target-libgm2. 32579 Add NCN_STRICT_CHECK_TARGET_TOOLS entry for gm2. 32580 Add GCC_TARGET_TOOL entry for gm2. (compare_exclusions) 32581 add gcc/m2/gm2-compiler/M2Version, 32582 gcc/m2/gm2-compiler-boot/SYSTEM and gcc/m2/gm2version. 32583 * Makefile.def (target_modules): Add libgm2. (flags_to_pass) 32584 Add GM2_FOR_TARGET, GM2FLAGS_FOR_TARGET. (dependencies) Add 32585 all-target-libgm2 and on=all-target-libatomic. (languages) 32586 Add entry for language=m2 with gcc-check-target=check-m2 32587 and lib-check-target=check-target-libgm2. 32588 * Makefile.tpl (BUILD_EXPORTS): Add definition for GM2 32589 and GM2FLAGS. (HOST_EXPORTS) Add definition for GM2. 32590 (BASE_TARGET_EXPORTS) Add definition for GM2. 32591 (GM2_FOR_BUILD) Defined. (GM2FLAGS) Defined. 32592 (GM2_FOR_TARGET) Defined. (GM2FLAGS_FOR_TARGET) Defined. 32593 (EXTRA_HOST_FLAGS) Defined. (POSTSTAGE1_FLAGS_TO_PASS) 32594 Add GM2 and GM2_FOR_BUILD. (EXTRA_TARGET_FLAGS) Add 32595 GM2 and GM2FLAGS. (EXTRA_GCC_FLAGS) Add GM2_FOR_TARGET. 32596 325972023-08-12 Alexandre Oliva <oliva@adacore.com> 32598 32599 Add TFLAGS to gcc's GCC_FOR_TARGET 32600 When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for 32601 dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios. This 32602 patch arranges for TFLAGS to be passed from the top level down to gcc 32603 in GCC_FOR_TARGET in this case. 32604 32605 * Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET. 32606 (EXTRA_GCC_FLAGS): Likewise. 32607 326082023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32609 32610 configure: Account CXXFLAGS in gcc-plugin.m4. 32611 We now use a C++ compiler so that we need to process 32612 CXXFLAGS as well as CFLAGS in the gcc-plugin config 32613 fragment. 32614 32615 32616 config/ 32617 * gcc-plugin.m4: Save and process CXXFLAGS. 32618 326192023-08-12 David Seifert <soap@gentoo.org> 32620 32621 configure: use OBJDUMP determined by libtool [PR95648] 32622 $ac_cv_prog_OBJDUMP contains the --host OBJDUMP that 32623 libtool has inferred. Current config/gcc-plugin.m4 does 32624 not respect the user's choice for OBJDUMP. 32625 32626 config/ 32627 * gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP. 32628 326292023-08-12 Thomas Schwinge <thomas@codesourcery.com> 32630 32631 Remove support for Intel MIC offloading 32632 ... after its deprecation in GCC 12. 32633 32634 * Makefile.def: Remove module 'liboffloadmic'. 32635 * configure.ac: Remove 'liboffloadmic' handling. 32636 326372023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32638 32639 configure, Darwin: Ensure overrides to host-pie are passed to gcc configure. 32640 The latest versions of Darwin on the Aarch64 platform mandate PIE executables. 32641 On x86_64 it remains optional, but produces tool warnings after Darwin20, so 32642 we default to PIE executables there too. 32643 32644 All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force 32645 host_shared on (we issue a diagnostic if the user tries to configure them 32646 non-shared). 32647 32648 However, this also means we cannot test the host_shared setting independently 32649 of the host_pie setting so that the logic for setting PICFLAG must be amended 32650 for Darwin. 32651 32652 For Darwin versions required to have PIE executables, in the event that the 32653 user tries to configure these as --disable-host-pie, we issue a warning and 32654 override the setting. These versions must also switch host_pie on even if it 32655 is not given in the configure line. To cater for this we pass the current 32656 value of host_pie, as determined by top-level configure, to the GCC configure. 32657 32658 32659 * Makefile.def: Pass the enable-host-pie value to GCC configure. 32660 * configure.ac: Adjust the logic for shared and PIE host flags to 32661 ensure that PIE is passed for hosts that require it. 32662 326632023-08-12 Peter Foley <pefoley2@pefoley.com> 32664 32665 configure: Only create serdep.tmp if needed 32666 There's no reason to create this file if none of the serial configure 32667 options are passed. 32668 32669 * configure.ac: Only create serdep.tmp if needed 32670 326712023-08-12 Marek Polacek <polacek@redhat.com> 32672 32673 configure: Implement --enable-host-pie 32674 This patch implements the --enable-host-pie configure option which 32675 makes the compiler executables PIE. This can be used to enhance 32676 protection against ROP attacks, and can be viewed as part of a wider 32677 trend to harden binaries. 32678 32679 Co-Authored by: Iain Sandoe <iain@sandoe.co.uk> 32680 32681 * configure.ac (--enable-host-pie): New check. Set PICFLAG after this 32682 check. 32683 32684 intl/ 32685 * configure.ac (--enable-host-shared): Don't set PICFLAG here. 32686 (--enable-host-pie): New check. Set PICFLAG after this check. 32687 32688 libdecnumber/ 32689 * configure.ac (--enable-host-shared): Don't set PICFLAG here. 32690 (--enable-host-pie): New check. Set PICFLAG after this check. 32691 32692 zlib/ 32693 * configure.ac (--enable-host-shared): Don't set PICFLAG here. 32694 (--enable-host-pie): New check. Set PICFLAG after this check. 32695 326962023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32697 32698 configure: When host-shared, pass --with-pic to in-tree lib configs. 32699 If we are building PIC/PIE host executables, and we are building dependent 32700 libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code. 32701 32702 32703 * Makefile.def: Pass host_libs_picflag to host dependent library 32704 configures. 32705 * configure.ac (host_libs_picflag): New configure variable set to 32706 '--with-pic' when building 'host_shared'. 32707 327082023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32709 32710 configure: Do not build the ununsed libffi shared library. 32711 We do not use the shared libffi libraray, nor do we install it. 32712 However, on at least Darwin, the shared version will be picked 32713 up for testing, so it is preferrable not to build it. 32714 32715 32716 * Makefile.def: Do not build shared libffi. 32717 327182023-08-12 Iain Sandoe <iain@sandoe.co.uk> 32719 32720 Darwin : Update libtool and dependencies for Darwin20 [PR97865] 32721 The change in major version (and the increment from Darwin19 to 20) 32722 caused libtool tests to fail which resulted in incorrect build settings 32723 for shared libraries. 32724 32725 PR target/97865 32726 * libtool.m4: Update handling of Darwin platform link flags 32727 for Darwin20. 32728 327292023-08-12 Xi Ruoyao <xry111@xry111.site> 32730 32731 LoongArch: implement count_{leading,trailing}_zeros 32732 LoongArch always support clz and ctz instructions, so we can always use 32733 __builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves 32734 the code of libgcc, and also benefits Glibc once we merge longlong.h 32735 there. 32736 32737 Bootstrapped and regtested on loongarch64-linux-gnu. 32738 32739 include/ 32740 * longlong.h [__loongarch__] (count_leading_zeros): Define. 32741 [__loongarch__] (count_trailing_zeros): Likewise. 32742 [__loongarch__] (COUNT_LEADING_ZEROS_0): Likewise. 32743 327442023-08-12 Meghan Denny <hello@nektro.net> 32745 32746 Updated constants from <https://dwarfstd.org/Languages.php> 32747 include/ 32748 * dwarf2.h: Update with additional languages from dwarf 32749 standard. 32750 327512023-08-12 Jason Merrill <jason@redhat.com> 32752 32753 c++: source position of lambda captures [PR84471] 32754 include/ 32755 * ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __. 32756 327572023-08-12 Lulu Cheng <chenglulu@loongson.cn> 32758 32759 Libvtv: Add loongarch support. 32760 The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB, 32761 but only 16KiB pages are supported for now. 32762 32763 Co-Authored-By: qijingwen <qijingwen@loongson.cn> 32764 32765 include/ 32766 * vtv-change-permission.h (defined): Determines whether the macro 32767 __loongarch_lp64 is defined 32768 (VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64. 32769 327702023-08-12 GDB Administrator <gdbadmin@sourceware.org> 32771 32772 Automatic date update in version.in 32773 327742023-08-11 Carl Love <cel@us.ibm.com> 32775 32776 gdb.ada/mi_var_access.exp 32777 The NUMCHILD value for the "A_String_Access" test differs for X86 and 32778 PowerPC. The patch substitutes $decimal instead of "1" to match the value 32779 of NUMCHILD. 32780 32781 The test "-var-update A_String_Access" generates different output depending 32782 on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true, 32783 the strings "new_type" and "new_num_children" are printed along with their 32784 values. 32785 32786 The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which 32787 produces the output: 32788 32789 Expecting: ^(-var-update A_String_Access[ 32790 ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][ 32791 ]+[(]gdb[)] 32792 [ ]*) 32793 -var-update A_String_Access 32794 ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}] 32795 (gdb) 32796 FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output) 32797 32798 The patch adds a second possible result string for the test 32799 $re_varobj_update_result_type to match the case when type_changed is true. 32800 32801 Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED 32802 is true on PowerPC and false on X86-64. 32803 32804 Fixes 2 failures on PowerPC. 32805 32806 Approved-By: Tom Tromey <tom@tromey.com> 32807 328082023-08-11 Tom Tromey <tromey@adacore.com> 32809 32810 Fix Python documentation for range type fields 32811 GDB's Python documentation claims that range types have two fields, 32812 but this is not true, and attempts to access them hit this error: 32813 32814 "Type is not a structure, union, enum, or function type." 32815 32816 This patch fixes the documentation. 32817 328182023-08-11 Tom Tromey <tromey@adacore.com> 32819 32820 Test GNAT encodings in arr_acc_idx_w_gap.exp 32821 While working on a GNAT bug, I wanted to also test 32822 arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is 32823 ready, I plan to add a new case here. 32824 32825 Tested on x86-64 Fedora 36. I am checking this in. 32826 328272023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com> 32828 32829 RISC-V: Reflect actual range of vlen for hashing 32830 Before actual vlen handling, fix the riscv_gdbarch_features hashing 32831 function based on the actual valid range of vlen. In bytes, vlen is 0, 32832 or 4 <= xlen <= 8192. 32833 32834 RISC-V: Add reference to Zve32* 32835 Before actual vlen handling, this commit fixes its description to allow vlen 32836 less than 16 (but 4 or greater), to support vector subset extensions for 32837 embedded environment ('Zve32*'). 32838 328392023-08-11 Alan Modra <amodra@gmail.com> 32840 32841 gdb: warn unused result for bfd IO functions 32842 This fixes the compilation warnings introduced by my bfdio.c patch. 32843 32844 The removed bfd_seeks in coff_symfile_read date back to 1994, commit 32845 7f4c859520, prior to which the file used stdio rather than bfd to read 32846 symbols. Since it now uses bfd to read the file there should be no 32847 need to synchronise to bfd's idea of the file position. I also fixed 32848 a potential uninitialised memory access. 32849 32850 Approved-By: Andrew Burgess <aburgess@redhat.com> 32851 328522023-08-11 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 32853 32854 Fix AIX build break. 32855 In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same. 32856 32857 This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result. 32858 328592023-08-11 Jan Beulich <jbeulich@suse.com> 32860 32861 gas: purge md_elf_section_word() 32862 It's not documented anyway, and having it makes no sense anymore with 32863 obj_elf_section_word() now being TC_SPARC-only. In any event the x86 32864 backing function was dead code. 32865 328662023-08-11 Jan Beulich <jbeulich@suse.com> 32867 32868 x86: pack CPU flags in opcode table 32869 The table constantly growing in two dimensions (number of table entries 32870 times number of ISA extension flags) doesn't scale very well. Use a more 32871 compact representation: Only identifiers which need to combine with 32872 other identifiers retain individual flag bits. All others are combined 32873 into an enum, with a new helper added to transform the table entries 32874 into the original i386_cpu_flags layout. This way the table in the final 32875 binary shrinks by almost a third (the generated source code shrinks by 32876 about half), and isn't likely to grow again in that dimension any time 32877 soon. 32878 32879 While moving the 3DNow! fields, drop the stray inner 'a' from their 32880 names. 32881 328822023-08-11 Alan Modra <amodra@gmail.com> 32883 32884 warn unused result for bfd IO functions 32885 This patch fixes all the warnings I found in bfd, binutils and ld, 32886 plus some bitrotted COFF_GO32 code that tried to allocate -168ul 32887 bytes. When the malloc fail was reported these testsuite fails 32888 resulted: 32889 32890 i386-go32 +FAIL: go32 stub 32891 i386-go32 +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp. 32892 i386-go32 +ERROR: couldn't open "tmpdir/go32stub": no such file or directory 32893 i386-go32 +FAIL: ld-scripts/sane1 32894 i386-go32 +FAIL: ld-scripts/assign-loc 32895 i386-go32 +FAIL: ld-scripts/pr18963 32896 32897 This does result in some warnings in gdb which are fixed in a followup 32898 patch. 32899 32900 bfd/ 32901 * bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT. 32902 (bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise. 32903 * bfd-in2.h: Regenerate. 32904 * coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write 32905 return value. 32906 (xcoff_generate_rtinit): Likewise. Also free data_buffer and 32907 string_table before returning. 32908 * coff64-rs6000.c (xcoff64_generate_rtinit): Likewise. 32909 * coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek 32910 return value. 32911 * coffcode.h (coff_apply_checksum): Don't ignore bfd_write return. 32912 (coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc. 32913 Fix bitrotted code to look for first section with non-zero filepos. 32914 * elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore 32915 bfd_seek or bfd_write return values. 32916 * pef.c (bfd_pef_scan_section): Likewise. 32917 (bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise. 32918 * vms-misc.c (_bfd_vms_output_end): Likewise. Return status. 32919 * vms.h (_bfd_vms_output_end): Update prototype. 32920 * vms-alpha.c: Pass _bfd_vms_output_end status up call chains. 32921 * wasm-module.c (wasm_compute_custom_section_file_position): Don't 32922 ignore bfd_seek or bfd_write return values. 32923 (wasm_compute_section_file_positions): Likewise. 32924 * xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value. 32925 (bfd_sym_read_name_table): Likewise. 32926 binutils/ 32927 * ar.c (print_contents, extract_file): Don't ignore bfd_seek 32928 return value. 32929 ld/ 32930 * pdb.c (create_section_contrib_substream): Don't ignore bfd_seek 32931 return value. 32932 (create_section_header_stream): Likewise. 32933 * pe-dll.c (pe_get16, pe_get32): Add fail param to return results 32934 from bfd_seek and bfd_read. 32935 (pe_implied_import_dll): Handle these fails, and other bfd_seek 32936 and bfd_read return values. 32937 329382023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com> 32939 32940 RISC-V: Fix opcode entries of "vmsge{,u}.vx" 32941 Their check_func should be "match_never", not "match_opcode". The reasons 32942 this error did not cause any disassembler errors are: 32943 32944 1. The problem will not reproduce if "no-aliases" is specified 32945 (because macro instructions are handled as aliases). 32946 2. If not, all affected compressed instructions or their aliases 32947 precede before "vmsge{,u}.vx" macro instructions. 32948 32949 However, it'll easily break if we reorder opcode entries. This commit 32950 fixes this issue before the *accident* occurs. 32951 32952 opcodes/ChangeLog: 32953 32954 * riscv-opc.c (riscv_opcodes): Make sure that we never match to 32955 vmsge{,u}.vx instructions unless specified in the assembler. 32956 329572023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com> 32958 32959 RISC-V: Remove support for non-existing 'Zve32d' 32960 Since this "extension" does not exist (on the other hand, 'Zve64d' exists) 32961 and it's not useful if we keep it (as other code portions just ignore 32962 "zve32d"), this commit just removes it. 32963 32964 bfd/ChangeLog: 32965 32966 * elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d' 32967 extension from the list. 32968 329692023-08-11 GDB Administrator <gdbadmin@sourceware.org> 32970 32971 Automatic date update in version.in 32972 329732023-08-10 Tom de Vries <tdevries@suse.de> 32974 32975 [gdb/symtab] Fix off-by-one error in cooked_indexer::recurse 32976 Test-case gdb.dwarf2/pr13961.exp contains: 32977 ... 32978 <1><25>: Abbrev Number: 8 (DW_TAG_class_type) 32979 <26> DW_AT_specification: <0x2a> 32980 <1><2a>: Abbrev Number: 2 (DW_TAG_class_type) 32981 <2b> DW_AT_name : foo 32982 <2f> DW_AT_byte_size : 4 32983 <30> DW_AT_decl_file : 1 32984 <31> DW_AT_decl_line : 1 32985 <32> DW_AT_sibling : <0x44> 32986 ... 32987 32988 The DIE at 0x25 contains an intra-CU forward reference, and is deferred during 32989 DIE indexing in the cooked_index, by adding it to m_deferred_entries. 32990 32991 The resulting cooked index entries are: 32992 ... 32993 [25] ((cooked_index_entry *) 0x333b5d0) 32994 name: foo 32995 canonical: foo 32996 qualified: foo 32997 DWARF tag: DW_TAG_class_type 32998 flags: 0x0 [] 32999 DIE offset: 0x2a 33000 parent: ((cooked_index_entry *) 0) 33001 33002 [26] ((cooked_index_entry *) 0x333b630) 33003 name: foo 33004 canonical: foo 33005 qualified: foo::foo 33006 DWARF tag: DW_TAG_class_type 33007 flags: 0x0 [] 33008 DIE offset: 0x25 33009 parent: ((cooked_index_entry *) 0x333b5d0) [foo] 33010 ... 33011 33012 Notice that 0x2a is the parent of 0x25, and that this is why the qualified 33013 name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo". 33014 33015 The parent is set here in cooked_indexer::make_index: 33016 ... 33017 for (const auto &entry : m_deferred_entries) 33018 { 33019 void *obj = m_die_range_map.find (entry.spec_offset); 33020 cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj); 33021 m_index_storage->add (entry.die_offset, entry.tag, entry.flags, 33022 entry.name, parent, m_per_cu); 33023 } 33024 ... 33025 and AFAICT, we store in m_die_range_map the parent of the respective 33026 spec_offset DIE (though that's not clear from the comment describing it). 33027 33028 So, the root cause of this is that when we lookup the parent for DIE 0x25, we get 33029 m_die_range_map.find (0x2a) == 0x2a. 33030 33031 This is an off-by-one error, fixed in cooked_indexer::recurse by: 33032 ... 33033 - CORE_ADDR start = form_addr (parent_entry->die_offset, 33034 + CORE_ADDR start = form_addr (parent_entry->die_offset + 1, 33035 ... 33036 which gives us: 33037 ... 33038 [12] ((cooked_index_entry *) 0x41e21f0) 33039 name: foo 33040 canonical: foo 33041 qualified: foo 33042 DWARF tag: DW_TAG_class_type 33043 flags: 0x0 [] 33044 DIE offset: 0x25 33045 parent: ((cooked_index_entry *) 0) 33046 33047 [13] ((cooked_index_entry *) 0x41e2190) 33048 name: foo 33049 canonical: foo 33050 qualified: foo 33051 DWARF tag: DW_TAG_class_type 33052 flags: 0x0 [] 33053 DIE offset: 0x2a 33054 parent: ((cooked_index_entry *) 0) 33055 ... 33056 33057 Tested on x86_64-linux. 33058 33059 Approved-By: Tom Tromey <tom@tromey.com> 33060 33061 PR symtab/30739 33062 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739 33063 330642023-08-10 Tom de Vries <tdevries@suse.de> 33065 33066 [gdb/symtab] Dump qualified name of cooked_index_entry 33067 When doing "maint print objfiles" for the exec of test-case 33068 gdb.dwarf2/pr13961.exp, we get: 33069 ... 33070 [25] ((cooked_index_entry *) 0x37b25d0) 33071 name: foo 33072 canonical: foo 33073 DWARF tag: DW_TAG_class_type 33074 flags: 0x0 [] 33075 DIE offset: 0x2a 33076 parent: ((cooked_index_entry *) 0) 33077 33078 [26] ((cooked_index_entry *) 0x37b2630) 33079 name: foo 33080 canonical: foo 33081 DWARF tag: DW_TAG_class_type 33082 flags: 0x0 [] 33083 DIE offset: 0x25 33084 parent: ((cooked_index_entry *) 0x37b25d0) [foo] 33085 ... 33086 33087 By following the parent links in the text, we can conclude that the qualified 33088 name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739). 33089 33090 But it's not evident, and also hard to verify in a test-case. 33091 33092 Add dumping of the qualified name, such that we have: 33093 ... 33094 [25] ((cooked_index_entry *) 0x333b5d0) 33095 name: foo 33096 canonical: foo 33097 qualified: foo 33098 DWARF tag: DW_TAG_class_type 33099 flags: 0x0 [] 33100 DIE offset: 0x2a 33101 parent: ((cooked_index_entry *) 0) 33102 33103 [26] ((cooked_index_entry *) 0x333b630) 33104 name: foo 33105 canonical: foo 33106 qualified: foo::foo 33107 DWARF tag: DW_TAG_class_type 33108 flags: 0x0 [] 33109 DIE offset: 0x25 33110 parent: ((cooked_index_entry *) 0x333b5d0) [foo] 33111 ... 33112 33113 Tested on x86_64-linux. 33114 33115 Approved-By: Tom Tromey <tom@tromey.com> 33116 331172023-08-10 Carl Love <cel@us.ibm.com> 33118 33119 Fix gdb.ada/O2_float_param.exp for PowerPC 33120 The frame command on Power pc prints the address in hex between the 33121 #0 and in calle.increment. For example 33122 33123 (gdb) frame 33124 #0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...) 33125 at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19 33126 19 procedure Increment (Val : in out Float; Msg: String) is 33127 33128 The printing of the address for the frame is done by function 33129 print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame, 33130 function frame_show_address returns true and print_frame prints the 33131 address. Currently, SAL.IS is false on PowerPC and true on X86-64. 33132 33133 Update the set re string to accept the hex address if it exits. 33134 33135 Fixes two failures on PowerPC. 33136 33137 Patch tested on Power10 with no new regressions. 33138 33139 Approved-By: Tom Tromey <tom@tromey.com> 33140 331412023-08-10 Tom Tromey <tromey@adacore.com> 33142 33143 Change py-thread-exited.exp to work with gdbserver 33144 gdbserver does not notify gdb of new threads when they are created. 33145 I'm not sure if this is documented anywhere, but it is mentioned on 33146 this page: 33147 33148 https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity 33149 33150 Search for "Finding new threads in the inferior". 33151 33152 This behavior is a bit unfortunate -- I would think that it would be 33153 better to arrange for such notification if something on the gdb side 33154 is interested. 33155 33156 Meanwhile, this patch fixes py-thread-exited.exp to work around this 33157 problem. 33158 33159 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677 33160 331612023-08-10 Tom Tromey <tom@tromey.com> 33162 33163 Pass unique_ptr to add_thread_with_info 33164 This changes add_thread_with_info to accept a unique_ptr, making it 33165 clear that it takes ownership of the passed-in pointer. 33166 33167 I can't test the AIX or Darwin changes, but I think they are 33168 relatively obvious. 33169 331702023-08-10 Richard Ball <richard.ball@arm.com> 33171 33172 aarch64: Enable Cortex-A520 CPU 33173 This patch adds support for the Cortex-A520 CPU to gas. 33174 33175 No regressions on aarch64-none-elf. 33176 33177 gas/ChangeLog: 33178 33179 * NEWS: Update docs. 33180 * config/tc-aarch64.c: Add Cortex-A520. 33181 * doc/c-aarch64.texi: Update docs. 33182 331832023-08-10 Tom de Vries <tdevries@suse.de> 33184 33185 [gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with cc-with-gnu-debuglink 33186 When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board 33187 cc-with-gnu-debuglink, I run into: 33188 ... 33189 (gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo 33190 maint print symbols -objfile enqueued-cu-base-addr^M 33191 (gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found 33192 ... 33193 33194 The problem is that the CU we're trying to print is in objfile 33195 enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr. 33196 33197 Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2". 33198 33199 Tested on x86_64-linux. 33200 332012023-08-10 Tom de Vries <tdevries@suse.de> 33202 33203 [gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp 33204 I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board 33205 cc-with-debug-names, and ran into: 33206 ... 33207 FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error) 33208 FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found 33209 ... 33210 33211 The first FAIL is a known issue, PR symtab/29572. 33212 33213 The following FAIL is a consequence of the first FAIL, so require for the 33214 second test that the first test passes. 33215 33216 Tested on x86_64-linux, with target boards unix and cc-with-debug-names. 33217 332182023-08-10 Tom de Vries <tdevries@suse.de> 33219 33220 [gdb/symtab] Fix assertion in write_debug_names 33221 When running test-case gdb.dwarf2/pr13961.exp with target-board 33222 cc-with-debug-names, I run into: 33223 ... 33224 Running gdb.dwarf2/pr13961.exp ... 33225 gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \ 33226 write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed. 33227 ... 33228 33229 This is a regression since commit 542a33e348a ("Only use the per-BFD object to 33230 write a DWARF index"), which did: 33231 ... 33232 - gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ()); 33233 + gdb_assert (counter == per_bfd->all_units.size ()); 33234 ... 33235 33236 Fix this by reverting to using all_comp_units: 33237 ... 33238 gdb_assert (counter == per_bfd->all_comp_units.size ()); 33239 ... 33240 33241 Tested on x86_64-linux, using target boards unix and cc-with-debug-names. 33242 33243 PR symtab/30741 33244 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30741 33245 332462023-08-10 GDB Administrator <gdbadmin@sourceware.org> 33247 33248 Automatic date update in version.in 33249 332502023-08-09 David Faust <david.faust@oracle.com> 33251 33252 bpf: use w regs in 32-bit non-fetch atomic pseudo-c 33253 The 32-bit non-fetching atomic instructions treat the source register as 33254 32-bits, which means in the pseudo-c syntax the "w" registers should be 33255 used rather than the "r" registers. 33256 33257 opcodes/ 33258 33259 * bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32 33260 and AXOR32 pseudo-c dialect asm templates. 33261 33262 gas/ 33263 33264 * testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg 33265 in non-fetching 32-bit atomic instructions. 33266 * testsuite/gas/bpf/atomic-pseudoc.d: Likewise. 33267 * testsuite/gas/bpf/atomic-pseudoc.s: Likewise. 33268 332692023-08-09 Mihails Strasuns <mihails.strasuns@intel.com> 33270 33271 gdb, breakpoint: add breakpoint location debugging logs 33272 Add new commands: 33273 33274 set debug breakpoint on|off 33275 show debug breakpoint 33276 33277 This patch introduces new debugging information that prints 33278 breakpoint location insertion and removal flow. 33279 33280 The debug output looks like: 33281 ~~~ 33282 (gdb) set debug breakpoint on 33283 (gdb) disassemble main 33284 Dump of assembler code for function main: 33285 0x0000555555555129 <+0>: endbr64 33286 0x000055555555512d <+4>: push %rbp 33287 0x000055555555512e <+5>: mov %rsp,%rbp 33288 => 0x0000555555555131 <+8>: mov $0x0,%eax 33289 0x0000555555555136 <+13>: pop %rbp 33290 0x0000555555555137 <+14>: ret 33291 End of assembler dump. 33292 (gdb) break *0x0000555555555137 33293 Breakpoint 2 at 0x555555555137: file main.c, line 4. 33294 [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT 33295 (gdb) c 33296 Continuing. 33297 [breakpoint] update_global_location_list: insert_mode = UGLL_INSERT 33298 [breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 33299 [breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 33300 [breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e 33301 [breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 33302 [breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove 33303 [breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove 33304 [breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove 33305 [breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove 33306 33307 Breakpoint 2, 0x0000555555555137 in main () at main.c:4 33308 4 } 33309 ~~~ 33310 33311 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 33312 333132023-08-09 GDB Administrator <gdbadmin@sourceware.org> 33314 33315 Automatic date update in version.in 33316 333172023-08-09 Alan Modra <amodra@gmail.com> 33318 33319 Rename bfd_bread and bfd_bwrite 33320 These were renamed from bfd_read and bfd_write back in 2001 when they 33321 lost an unnecessary parameter. Rename them back, and get rid of a few 33322 casts that are only needed without prototyped functions (K&R C). 33323 33324 Add ld makefile dependencies 33325 * Makefile.am (EXTRA_ld_new_SOURCES): Add pep-dll-aarch64.c 33326 and pep-dll-x86_64.c. 33327 * Makefile.in: Regenerate. 33328 333292023-08-09 Alan Modra <amodra@gmail.com> 33330 33331 PR30724, cygwin ld performance regression since 014a602b86 33332 According to the reporter of this bug the newlib fseek implementation 33333 is likely slowed down by locking and fflush, only attempting to 33334 optimise seeks when the file is opened read-only. Thus when writing 33335 the output we get a dramatic slowdown due to commit 014a602b86. 33336 33337 PR 30724 33338 * bfd.c (enum bfd_last_io): New. 33339 (struct bfd): Add last_io field. 33340 * bfd-in2.h: Regenerate. 33341 * bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is 33342 opposite direction. 33343 (bfd_seek): Reinstate optimisation for seek to same position. 33344 333452023-08-08 Tom de Vries <tdevries@suse.de> 33346 33347 [gdb/build] Use move capture in gdb_demangle 33348 Use move capture in gdb_demangle when compiling for c++14 or higher, to save a 33349 std::string copy. 33350 33351 Tested on x86_64-linux. 33352 33353 Reported-By: Tom Tromey <tom@tromey.com> 33354 Approved-By: Tom Tromey <tom@tromey.com> 33355 333562023-08-08 Sam James <sam@gentoo.org> 33357 33358 ld: Fix retain7a.d XFAIL/notarget entry for hppa 33359 PR 30733 33360 * ld/testsuite/ld-elf/retain7a.d: Fix XFAIL entry for hppa to match 33361 hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses. 33362 33363 ld: Fix relocatable.d XFAIL/notarget entry for hppa 33364 PR 30734 33365 * ld/testsuite/ld-elf/relocatable.d: Fix notarget entry for hppa to match 33366 hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses. 33367 333682023-08-08 Guinevere Larsen <blarsen@redhat.com> 33369 33370 Update my name in maintainers file 33371 333722023-08-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 33373 33374 Guard against killing unrelated processes in amd64-disp-step.exp 33375 When testing current gdb trunk on Solaris/amd64, the whole session was 33376 reliably terminated by make check. I could trace this to the following 33377 entry in gdb.arch/amd64-disp-step/gdb.log: 33378 33379 FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get 33380 inferior pid 33381 Executing on target: kill -ALRM -1 (timeout = 300) 33382 builtin_spawn -ignore SIGHUP kill -ALRM -1 33383 33384 If $inferior_pid doesn't refer to a single process for some reason, this 33385 kill would terminate either a process group or the whole session. 33386 33387 This patch avoids this by ensuring that the pid arg is positive. 33388 33389 Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu. 33390 33391 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 33392 Approved-By: Tom Tromey <tom@tromey.com> 33393 333942023-08-08 Tom de Vries <tdevries@suse.de> 33395 33396 [gdb/build] Fix build breaker with -std=c++11 33397 When building with -std=c++11 I run into: 33398 ... 33399 gdb/dwarf2/cooked-index.c: In member function \ 33400 ‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’: 33401 gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \ 33402 available with -std=c++14 or -std=gnu++14 [-Werror] 33403 ctx = std::move (ctx)] () 33404 ^~~ 33405 ... 33406 33407 Fix this by capturing a copy instead when using -std=c++11: 33408 ... 33409 = gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] () 33410 ... 33411 33412 Tested by building with and without -stdc=++11 on x86_64-linux. 33413 33414 Reported-By: Tom Tromey <tom@tromey.com> 33415 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 33416 334172023-08-08 Tsukasa OI <research_trasio@irq.a4lg.com> 33418 33419 RISC-V: Update ratified 'Ztso' extension version 33420 Because the 'Ztso' extension is now ratified, it has a version number of 1.0 33421 (not 0.1). This commit updates the number. 33422 33423 bfd/ChangeLog: 33424 33425 * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version 33426 number of the 'Ztso' extension since it's ratified. 33427 334282023-08-08 GDB Administrator <gdbadmin@sourceware.org> 33429 33430 Automatic date update in version.in 33431 334322023-08-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 33433 33434 gprofng: 30700 tmpdir/gp-collect-app_F test fails 33435 gprofng/ChangeLog 33436 2023-08-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 33437 33438 PR gprofng/30700 33439 * testsuite/gprofng.display/gp-collect-app_F.exp: Fix -name argument 33440 for sub-experiment filtering. 33441 334422023-08-07 Jan Beulich <jbeulich@suse.com> 33443 33444 RISC-V: move comment describing rules for riscv_opcodes[] 33445 It makes little sense to have this comment meanwhile over a hundred 33446 lines ahead of the array. In fact until spotting the comment, I was 33447 wondering why those pretty important aspects aren't spelled out 33448 anywhere. 33449 334502023-08-07 Richard Bunt <richard.bunt@linaro.org> 33451 33452 gdb/fortran: Align intrinsic/variable precedence 33453 Fortran allows variables and function to be named after language defined 33454 intrinsics as they are not reserved keywords. For example, the abs maths 33455 intrinsic can be hidden by a user declaring a variable called abs. 33456 33457 The behavior before this patch was to favour the intrinsic, which meant 33458 that any variables named, for example "allocated", could not be 33459 inspected by GDB. 33460 33461 This patch inverts this priority to bring GDB's behaviour closer to the 33462 Fortran language, where the user defined symbol can hide the intrinsic. 33463 33464 Special care was need to prevent any C symbols from overriding either 33465 Fortran intrinsics or user defined variables. This was observed to be 33466 the case when GDB has access to symbols for abs from libm. This was 33467 solved by only allowing symbols not marked with language_fortran to be 33468 overridden. 33469 33470 In total this brings the order of precedence to the following (highest 33471 first): 33472 33473 1. User defined Fortran variable or function. 33474 2. Fortran intrinsic. 33475 3. Symbols from languages other than Fortran. 33476 33477 The sizeof intrinsic is now case insensitive. This is closer to the 33478 Fortran language. I believe this change is safe enough as it increases 33479 the acceptance of the grammar, rather than restricts it. I.e. it should 33480 not break any existing scripts which rely on it. Unless of course they 33481 rely on SIZEOF being rejected. 33482 33483 GDB built with GCC 13. 33484 33485 No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel 33486 LLVM, NVHPC; Platforms: x86_64, aarch64. 33487 33488 Existing tests in gdb.fortran cover the invocation of intrinsics 33489 including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp. 33490 33491 Approved-By: Tom Tromey <tom@tromey.com> 33492 334932023-08-07 GDB Administrator <gdbadmin@sourceware.org> 33494 33495 Automatic date update in version.in 33496 334972023-08-06 GDB Administrator <gdbadmin@sourceware.org> 33498 33499 Automatic date update in version.in 33500 335012023-08-05 Tom de Vries <tdevries@suse.de> 33502 33503 [gdb/symtab] Find main language without symtab expansion 33504 When loading an executable using "file a.out", the language is set according 33505 to a.out, which can involve looking up the language of symbol "main", which 33506 will cause the symtab expansion for the containing CU. 33507 33508 Expansion of lto debug info can be slow, so in commit d3214198119 ("[gdb] Use 33509 partial symbol table to find language for main") a feature was added to avoid 33510 the symtab expansion. 33511 33512 This feature stopped working after commit 7f4307436fd ("Fix "start" for D, 33513 Rust, etc"). 33514 33515 [ The commit addresses problems related to command start, which requires finding 33516 the main function: 33517 - for language D, "main" was found instead of "D main", and 33518 - for Rust, the correct function was found, but attributed the wrong name 33519 (not fully qualified). ] 33520 33521 Reimplement the feature by adding 33522 cooked_index_functions::lookup_global_symbol_language. 33523 33524 Tested on x86_64-linux. 33525 33526 PR symtab/30661 33527 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661 33528 335292023-08-05 David Carew <david@dcarew.com> 33530 33531 as: Fix typo in manual 33532 The -D flag should enable "debugging" 33533 335342023-08-05 GDB Administrator <gdbadmin@sourceware.org> 33535 33536 Automatic date update in version.in 33537 335382023-08-04 Tom Tromey <tromey@adacore.com> 33539 33540 Reindent recursive_dump_type 33541 I noticed that a 'switch' in recursive_dump_type was incorrect 33542 indented. This patch fixes the problem. Tested by rebuilding. 33543 335442023-08-04 Tom Tromey <tom@tromey.com> 33545 33546 Consolidate calls to bfd_set_cacheable 33547 I noticed that some spots in gdb call bfd_set_cacheable after opening 33548 a BFD. 33549 33550 The BFD file cache is a bit odd. BFDs that are opened locally are 33551 unconditionally registered with the cache, and their underlying file 33552 descriptor will always be closed when bfd_cache_close_all is called. 33553 However, only "cacheable" BFDs will be eligible for reopening when 33554 needed -- and by default BFD decides that if a file descriptor is 33555 passed in, then it should not be cacheable. If a non-cacheable BFD's 33556 file descriptor is closed, there is no offical way to reopen it. 33557 33558 gdb needs to call bfd_cache_close_all, because some systems cannot 33559 start an executable when it has an open file descriptor referencing 33560 it. 33561 33562 However, gdb also will sometimes passes an open file descriptor to the 33563 various BFD open functions. And, due to lazy DWARF reading, gdb may 33564 also need to reopen these BFDs. 33565 33566 Rather than having all the callers figure out when exactly to set the 33567 cacheable flag, I think it makes sense to consolidate this logic into 33568 the gdb_bfd.c wrapper functions. It is ok to do this because gdb 33569 always passes a filename to these open functions, so reopening should 33570 work ok. 33571 33572 Regression tested on x86-64 Fedora 38. 33573 33574 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 33575 335762023-08-04 Tom Tromey <tromey@adacore.com> 33577 33578 Remove extra '.' from error message 33579 A local gdb test failed with this error message: 33580 33581 Remote communication error. Target disconnected.: Arg list too long. 33582 33583 The ".:" seemed weird to me. This patch removes the ".". 33584 33585 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 33586 335872023-08-04 Tom Tromey <tromey@adacore.com> 33588 33589 Fix incorrect class name in free_objfile documentation 33590 The documentation for the Python free_objfile event registry uses the 33591 wrong class name. This patch fixes it. I'm checking this in as 33592 obvious. 33593 335942023-08-04 Nick Clifton <nickc@redhat.com> 33595 33596 Fix potential infinite loop in bfd_cache_close_all. 33597 PR 15545 * cache.c (bfd_cache_close_all): Extend description to note that all files will be closed, even those that are not cacheable. Add code to prevent a possible infinite loop. 33598 335992023-08-04 Tom de Vries <tdevries@suse.de> 33600 33601 [gdb/testsuite] Extend gdb.base/index-cache.exp further 33602 Add lookup of a non-existing symbol to test-case gdb.base/index-cache.exp. 33603 33604 This serves as regression test for PR symtab/30718. 33605 33606 PR symtab/30718 33607 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718 33608 336092023-08-04 Tom de Vries <tdevries@suse.de> 33610 33611 [gdb/testsuite] Move "maint wait-for-index-cache" ALAP in gdb.base/index-cache.exp 33612 In test-case gdb.base/index-cache.exp proc run_test_with_flags contains: 33613 ... 33614 clean_restart ${testfile} 33615 33616 # The tests generally want to check the cache, so make sure it 33617 # has completed its work. 33618 gdb_test_no_output "maintenance wait-for-index-cache" 33619 ... 33620 33621 This however hides data races between: 33622 - index-cache writing (due to file $exec), and 33623 - symbol lookups (due to subsequent ptype commands). 33624 33625 Fix this by: 33626 - moving the "maintenance wait-for-index-cache" to proc check_cache_stats, and 33627 - moving all calls to proc check_cache_stats ALAP. 33628 33629 Tested on x86_64-linux. 33630 336312023-08-04 Tom de Vries <tdevries@suse.de> 33632 33633 [gdb/symtab] Fix data race on dwarf2_per_cu_data::{files_read,is_debug_types} 33634 With gdb build with -fsanitize=thread, and the exec from test-case 33635 gdb.base/index-cache.exp, I run into: 33636 ... 33637 $ rm -f ~/.cache/gdb/*; \ 33638 gdb -q -batch -iex "set index-cache enabled on" index-cache \ 33639 -ex "print foobar" 33640 ... 33641 WARNING: ThreadSanitizer: data race (pid=25018) 33642 Write of size 1 at 0x7b200000410d by main thread: 33643 #0 dw2_get_file_names_reader gdb/dwarf2/read.c:2033 (gdb+0x7ab023) 33644 #1 dw2_get_file_names gdb/dwarf2/read.c:2130 (gdb+0x7ab023) 33645 #2 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3105 (gdb+0x7ac6e9) 33646 #3 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d040f) 33647 #4 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5b6e) 33648 #5 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc441d) 33649 #6 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc4522) 33650 #7 classify_name gdb/c-exp.y:3083 (gdb+0x61afec) 33651 #8 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13) 33652 #9 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e) 33653 #10 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864) 33654 #11 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x977245) 33655 #12 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10b1b) 33656 #13 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb1112e) 33657 #14 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf8c) 33658 #15 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4caaa) 33659 #16 print_command gdb/printcmd.c:1468 (gdb+0xb4cdda) 33660 #17 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078) 33661 #18 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53) 33662 #19 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a7ea) 33663 #20 catch_command_errors gdb/main.c:518 (gdb+0xa183fd) 33664 #21 execute_cmdargs gdb/main.c:617 (gdb+0xa185bf) 33665 #22 captured_main_1 gdb/main.c:1289 (gdb+0xa1aad8) 33666 #23 captured_main gdb/main.c:1310 (gdb+0xa1b9da) 33667 #24 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b9da) 33668 #25 main gdb/gdb.c:39 (gdb+0x42506a) 33669 33670 Previous read of size 1 at 0x7b200000410d by thread T2: 33671 #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30) 33672 #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803) 33673 #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36) 33674 #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d) 33675 #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d) 33676 #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d) 33677 #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c) 33678 #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db) 33679 #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db) 33680 #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db) 33681 #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db) 33682 #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db) 33683 #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954) 33684 #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954) 33685 #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a) 33686 #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a) 33687 #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a) 33688 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a) 33689 #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a) 33690 #19 pthread_once <null> (libtsan.so.0+0x4457c) 33691 #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b) 33692 #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b) 33693 #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174570d) 33694 #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174570d) 33695 #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174570d) 33696 #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174570d) 33697 #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x17480c0) 33698 #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x17480c0) 33699 #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x17480c0) 33700 #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x17480c0) 33701 #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x17480c0) 33702 #31 <null> <null> (libstdc++.so.6+0xdcac2) 33703 ... 33704 SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:2033 in dw2_get_file_names_reader 33705 ... 33706 33707 The race happens when issuing the "file $exec" command. 33708 33709 The race is between: 33710 - a worker thread writing the index cache, and in the process reading 33711 dwarf2_per_cu_data::is_debug_type, and 33712 - the main thread writing to dwarf2_per_cu_data::files_read. 33713 33714 The two bitfields dwarf2_per_cu_data::files_read and 33715 dwarf2_per_cu_data::is_debug_type share the same bitfield container. 33716 33717 Fix this by making dwarf2_per_cu_data::files_read a packed<bool, 1>. 33718 33719 Tested on x86_64-linux. 33720 33721 PR symtab/30718 33722 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718 33723 337242023-08-04 Tom de Vries <tdevries@suse.de> 33725 33726 [gdb/symtab] Fix data race on dwarf2_per_cu_data::{mark,is_debug_types} 33727 With gdb build with -fsanitize=thread, and the exec from test-case 33728 gdb.base/index-cache.exp, I run into: 33729 ... 33730 $ rm -f ~/.cache/gdb/*; \ 33731 gdb -q -batch -iex "set index-cache enabled on" index-cache \ 33732 -ex "print foobar" 33733 ... 33734 WARNING: ThreadSanitizer: data race (pid=23970) 33735 Write of size 1 at 0x7b200000410d by main thread: 33736 #0 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3077 (gdb+0x7ac54e) 33737 #1 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d039f) 33738 #2 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5aee) 33739 #3 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc439d) 33740 #4 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc44a2) 33741 #5 classify_name gdb/c-exp.y:3083 (gdb+0x61afec) 33742 #6 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13) 33743 #7 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e) 33744 #8 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864) 33745 #9 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x9771c5) 33746 #10 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10a9b) 33747 #11 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb110ae) 33748 #12 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf0c) 33749 #13 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4ca2a) 33750 #14 print_command gdb/printcmd.c:1468 (gdb+0xb4cd5a) 33751 #15 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078) 33752 #16 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53) 33753 #17 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a76a) 33754 #18 catch_command_errors gdb/main.c:518 (gdb+0xa1837d) 33755 #19 execute_cmdargs gdb/main.c:617 (gdb+0xa1853f) 33756 #20 captured_main_1 gdb/main.c:1289 (gdb+0xa1aa58) 33757 #21 captured_main gdb/main.c:1310 (gdb+0xa1b95a) 33758 #22 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b95a) 33759 #23 main gdb/gdb.c:39 (gdb+0x42506a) 33760 33761 Previous read of size 1 at 0x7b200000410d by thread T1: 33762 #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30) 33763 #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803) 33764 #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36) 33765 #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d) 33766 #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d) 33767 #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d) 33768 #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c) 33769 #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db) 33770 #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db) 33771 #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db) 33772 #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db) 33773 #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db) 33774 #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954) 33775 #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954) 33776 #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a) 33777 #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a) 33778 #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a) 33779 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a) 33780 #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a) 33781 #19 pthread_once <null> (libtsan.so.0+0x4457c) 33782 #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b) 33783 #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b) 33784 #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174568d) 33785 #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174568d) 33786 #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174568d) 33787 #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174568d) 33788 #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1748040) 33789 #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1748040) 33790 #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1748040) 33791 #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1748040) 33792 #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1748040) 33793 #31 <null> <null> (libstdc++.so.6+0xdcac2) 33794 ... 33795 SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:3077 in dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) 33796 ... 33797 33798 The race happens when issuing the "file $exec" command. 33799 33800 The race is between: 33801 - a worker thread writing the index cache, and in the process reading 33802 dwarf2_per_cu_data::is_debug_type, and 33803 - the main thread writing to dwarf2_per_cu_data::mark. 33804 33805 The two bitfields dwarf2_per_cu_data::mark and 33806 dwarf2_per_cu_data::is_debug_type share the same bitfield container. 33807 33808 Fix this by making dwarf2_per_cu_data::mark a packed<unsigned int, 1>. 33809 33810 Tested on x86_64-linux. 33811 33812 PR symtab/30718 33813 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718 33814 338152023-08-04 Tom de Vries <tdevries@suse.de> 33816 33817 [gdb/testsuite] Extend gdb.base/index-cache.exp 33818 The test-case gdb.base/index-cache.exp uses only one source file, which 33819 contains main. 33820 33821 While doing "file $exec", in set_initial_language a symbol lookup of "main" is 33822 done, causing the symtab containing main to be expanded. 33823 33824 Handling of main is special, and a future optimization may skip the lookup and 33825 expansion. 33826 33827 Reliably exercise: 33828 - the lookup of main, expanding the symtab containing main, by doing 33829 "ptype main", and 33830 - the lookup of another symbol, expanding a symtab not containing main, by: 33831 - adding another source file containing function foo, and 33832 - doing "ptype foo". 33833 33834 This triggered a segfault with target board native-extended-gdbserver, filed 33835 as PR symtab/30712, but that seems to be fixed by a previous commit in this 33836 series. 33837 33838 Tested on x86_64-linux. 33839 33840 Approved-By: Tom Tromey <tom@tromey.com> 33841 33842 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30712 33843 338442023-08-04 Tom de Vries <tdevries@suse.de> 33845 33846 [gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in,is_debug_type} 33847 With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp 33848 and target board debug-types, I run into: 33849 ... 33850 (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache 33851 Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache... 33852 ================== 33853 WARNING: ThreadSanitizer: data race (pid=9654) 33854 Write of size 1 at 0x7b200000420d by main thread: 33855 #0 dwarf2_per_cu_data::get_header() const gdb/dwarf2/read.c:21513 (gdb+0x8d1eee) 33856 #1 dwarf2_per_cu_data::addr_size() const gdb/dwarf2/read.c:21524 (gdb+0x8d1f4e) 33857 #2 dwarf2_cu::addr_type() const gdb/dwarf2/cu.c:112 (gdb+0x806327) 33858 #3 set_die_type gdb/dwarf2/read.c:21932 (gdb+0x8d3870) 33859 #4 read_base_type gdb/dwarf2/read.c:15448 (gdb+0x8bcacb) 33860 #5 read_type_die_1 gdb/dwarf2/read.c:19832 (gdb+0x8cc0a5) 33861 #6 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d) 33862 #7 lookup_die_type gdb/dwarf2/read.c:19739 (gdb+0x8cbdc7) 33863 #8 die_type gdb/dwarf2/read.c:19593 (gdb+0x8cb68a) 33864 #9 read_subroutine_type gdb/dwarf2/read.c:14648 (gdb+0x8b998e) 33865 #10 read_type_die_1 gdb/dwarf2/read.c:19792 (gdb+0x8cbf2f) 33866 #11 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d) 33867 #12 read_func_scope gdb/dwarf2/read.c:10154 (gdb+0x8a4f36) 33868 #13 process_die gdb/dwarf2/read.c:6667 (gdb+0x898daa) 33869 #14 read_file_scope gdb/dwarf2/read.c:7682 (gdb+0x89bad8) 33870 #15 process_die gdb/dwarf2/read.c:6654 (gdb+0x898ced) 33871 #16 process_full_comp_unit gdb/dwarf2/read.c:6418 (gdb+0x8981de) 33872 #17 process_queue gdb/dwarf2/read.c:5690 (gdb+0x894433) 33873 #18 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1770 (gdb+0x88623a) 33874 #19 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x886300) 33875 #20 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88b1f1) 33876 #21 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16917 (gdb+0x8c228e) 33877 #22 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf39055) 33878 #23 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66ab7) 33879 #24 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf6711b) 33880 #25 operator() gdb/symtab.c:2562 (gdb+0xf67272) 33881 #26 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf776b1) 33882 #27 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77708) 33883 #28 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3fc97) 33884 #29 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xecae47) 33885 #30 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad) 33886 #31 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf674fb) 33887 #32 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf67780) 33888 #33 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf66d6e) 33889 #34 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf65cb3) 33890 #35 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf64dab) 33891 #36 set_initial_language() gdb/symfile.c:1708 (gdb+0xf43074) 33892 #37 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf41608) 33893 #38 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf42faf) 33894 #39 file_command gdb/exec.c:554 (gdb+0x94ff29) 33895 #40 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528) 33896 #41 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69) 33897 #42 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff379c) 33898 #43 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94b5bc) 33899 #44 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94bc79) 33900 #45 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x1034efc) 33901 #46 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94ab61) 33902 #47 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11be4ef) 33903 #48 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a960) 33904 #49 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94aa21) 33905 #50 stdin_event_handler gdb/ui.c:155 (gdb+0x10751a0) 33906 #51 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d95bac) 33907 #52 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d962e4) 33908 #53 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d946d0) 33909 #54 start_event_loop gdb/main.c:412 (gdb+0xb5ab52) 33910 #55 captured_command_loop gdb/main.c:476 (gdb+0xb5ad41) 33911 #56 captured_main gdb/main.c:1320 (gdb+0xb5cec1) 33912 #57 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5cf70) 33913 #58 main gdb/gdb.c:32 (gdb+0x416776) 33914 33915 Previous read of size 1 at 0x7b200000420d by thread T11: 33916 #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x831630) 33917 #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x832897) 33918 #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x82db8d) 33919 #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:645 (gdb+0x7f1d49) 33920 #4 operator() gdb/dwarf2/cooked-index.c:474 (gdb+0x7f0f31) 33921 #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2a13) 33922 #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952) 33923 #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0) 33924 #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91) 33925 #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59) 33926 #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660) 33927 #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c) 33928 #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623) 33929 #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf) 33930 #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f) 33931 #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5) 33932 #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d) 33933 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2) 33934 #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2) 33935 #19 pthread_once <null> (libtsan.so.0+0x4457c) 33936 #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd) 33937 #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224) 33938 #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852) 33939 #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef) 33940 #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dad25a) 33941 #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dacb7c) 33942 #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dadc2b) 33943 #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dad05c) 33944 #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1db038e) 33945 #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1db0319) 33946 #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1db02ce) 33947 #31 <null> <null> (libstdc++.so.6+0xdcac2) 33948 ... 33949 SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:21513 in dwarf2_per_cu_data::get_header() const 33950 ... 33951 33952 The race happens when issuing the "file $exec" command. 33953 33954 The race is between: 33955 - a worker thread writing the index cache, and in the process reading 33956 dwarf2_per_cu_data::is_debug_type, and 33957 - the main thread writing to dwarf2_per_cu_data::m_header_read_in. 33958 33959 The two bitfields dwarf2_per_cu_data::m_header_read_in and 33960 dwarf2_per_cu_data::is_debug_type share the same bitfield container. 33961 33962 Fix this by making dwarf2_per_cu_data::m_header_read_in a packed<bool, 1>. 33963 33964 Tested on x86_64-linux. 33965 33966 Approved-By: Tom Tromey <tom@tromey.com> 33967 33968 PR symtab/30392 33969 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392 33970 339712023-08-04 Tom de Vries <tdevries@suse.de> 33972 33973 [gdb/symtab] Fix race on dwarf2_per_cu_data::{queued,is_debug_type} 33974 With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I 33975 run into: 33976 ... 33977 (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache 33978 Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache... 33979 ================== 33980 WARNING: ThreadSanitizer: data race (pid=24296) 33981 Write of size 1 at 0x7b200000420d by main thread: 33982 #0 queue_comp_unit gdb/dwarf2/read.c:5564 (gdb+0x8939ce) 33983 #1 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1754 (gdb+0x885b96) 33984 #2 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x885d86) 33985 #3 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88ac77) 33986 #4 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16915 (gdb+0x8c1c8a) 33987 #5 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf389a1) 33988 #6 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66403) 33989 #7 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf66a67) 33990 #8 operator() gdb/symtab.c:2562 (gdb+0xf66bbe) 33991 #9 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf76ffd) 33992 #10 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77054) 33993 #11 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3f5e3) 33994 #12 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xeca793) 33995 #13 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad) 33996 #14 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf66e47) 33997 #15 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf670cc) 33998 #16 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf666ba) 33999 #17 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf655ff) 34000 #18 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf646f7) 34001 #19 set_initial_language() gdb/symfile.c:1708 (gdb+0xf429c0) 34002 #20 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40f54) 34003 #21 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf428fb) 34004 #22 file_command gdb/exec.c:554 (gdb+0x94f875) 34005 #23 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528) 34006 #24 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69) 34007 #25 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff3166) 34008 #26 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94af08) 34009 #27 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b5c5) 34010 #28 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x10348c6) 34011 #29 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a4ad) 34012 #30 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdf87) 34013 #31 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a2ac) 34014 #32 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a36d) 34015 #33 stdin_event_handler gdb/ui.c:155 (gdb+0x1074b6a) 34016 #34 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d9502c) 34017 #35 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d95764) 34018 #36 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93b50) 34019 #37 start_event_loop gdb/main.c:412 (gdb+0xb5a49e) 34020 #38 captured_command_loop gdb/main.c:476 (gdb+0xb5a68d) 34021 #39 captured_main gdb/main.c:1320 (gdb+0xb5c80d) 34022 #40 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c8bc) 34023 #41 main gdb/gdb.c:32 (gdb+0x416776) 34024 34025 Previous read of size 1 at 0x7b200000420d by thread T12: 34026 #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x8310c8) 34027 #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x83232f) 34028 #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:177 (gdb+0x82d62b) 34029 #3 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf7) 34030 #4 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40) 34031 #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2909) 34032 #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952) 34033 #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0) 34034 #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91) 34035 #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59) 34036 #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660) 34037 #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c) 34038 #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623) 34039 #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf) 34040 #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f) 34041 #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5) 34042 #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d) 34043 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2) 34044 #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2) 34045 #19 pthread_once <null> (libtsan.so.0+0x4457c) 34046 #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd) 34047 #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224) 34048 #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852) 34049 #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef) 34050 #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac6da) 34051 #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabffc) 34052 #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dad0ab) 34053 #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac4dc) 34054 #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf80e) 34055 #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf799) 34056 #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf74e) 34057 #31 <null> <null> (libstdc++.so.6+0xdcac2) 34058 ... 34059 SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:5564 in queue_comp_unit 34060 ... 34061 34062 The race happens when issuing the "file $exec" command. 34063 34064 The race is between: 34065 - a worker thread writing the index cache, and in the process reading 34066 dwarf2_per_cu_data::is_debug_type, and 34067 - the main thread expanding the CU containing main, and in the process setting 34068 dwarf2_per_cu_data::queued. 34069 34070 The two bitfields dwarf2_per_cu_data::queue and 34071 dwarf2_per_cu_data::is_debug_type share the same bitfield container. 34072 34073 Fix this by making dwarf2_per_cu_data::queued a packed<bool, 1>. 34074 34075 Tested on x86_64-linux. 34076 34077 Approved-By: Tom Tromey <tom@tromey.com> 34078 34079 PR symtab/30392 34080 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392 34081 340822023-08-04 Tom de Vries <tdevries@suse.de> 34083 34084 [gdb/symtab] Fix data race on bfd::{cacheable,format} 34085 With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I 34086 run into: 34087 ... 34088 (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache 34089 Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache... 34090 ================== 34091 WARNING: ThreadSanitizer: data race (pid=12261) 34092 Write of size 4 at 0x7b4400097d08 by main thread: 34093 #0 bfd_open_file bfd/cache.c:584 (gdb+0x148bb92) 34094 #1 bfd_cache_lookup_worker bfd/cache.c:261 (gdb+0x148b12a) 34095 #2 cache_bseek bfd/cache.c:289 (gdb+0x148b324) 34096 #3 bfd_seek bfd/bfdio.c:459 (gdb+0x1489c31) 34097 #4 _bfd_generic_get_section_contents bfd/libbfd.c:1069 (gdb+0x14977a4) 34098 #5 bfd_get_section_contents bfd/section.c:1606 (gdb+0x149cc7c) 34099 #6 gdb_bfd_scan_elf_dyntag(int, bfd*, unsigned long*, unsigned long*) gdb/solib.c:1601 (gdb+0xed8eca) 34100 #7 elf_locate_base gdb/solib-svr4.c:705 (gdb+0xec28ac) 34101 #8 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3430 (gdb+0xeca55d) 34102 #9 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad) 34103 #10 find_main_name gdb/symtab.c:6270 (gdb+0xf743a5) 34104 #11 main_language() gdb/symtab.c:6313 (gdb+0xf74499) 34105 #12 set_initial_language() gdb/symfile.c:1700 (gdb+0xf4285c) 34106 #13 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40e2a) 34107 #14 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf427d1) 34108 #15 file_command gdb/exec.c:554 (gdb+0x94f74b) 34109 #16 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528) 34110 #17 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69) 34111 #18 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff303c) 34112 #19 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94adde) 34113 #20 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b49b) 34114 #21 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103479c) 34115 #22 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a383) 34116 #23 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bde5d) 34117 #24 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a182) 34118 #25 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a243) 34119 #26 stdin_event_handler gdb/ui.c:155 (gdb+0x1074a40) 34120 #27 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94f02) 34121 #28 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9563a) 34122 #29 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93a26) 34123 #30 start_event_loop gdb/main.c:412 (gdb+0xb5a374) 34124 #31 captured_command_loop gdb/main.c:476 (gdb+0xb5a563) 34125 #32 captured_main gdb/main.c:1320 (gdb+0xb5c6e3) 34126 #33 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c792) 34127 #34 main gdb/gdb.c:32 (gdb+0x416776) 34128 34129 Previous read of size 1 at 0x7b4400097d08 by thread T12: 34130 #0 bfd_check_format_matches bfd/format.c:323 (gdb+0x1492db4) 34131 #1 bfd_check_format bfd/format.c:94 (gdb+0x1492104) 34132 #2 build_id_bfd_get(bfd*) gdb/build-id.c:42 (gdb+0x6648f7) 34133 #3 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:110 (gdb+0x82d205) 34134 #4 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf1) 34135 #5 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40) 34136 #6 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f28f7) 34137 #7 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952) 34138 #8 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0) 34139 #9 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91) 34140 #10 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59) 34141 #11 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660) 34142 #12 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c) 34143 #13 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623) 34144 #14 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf) 34145 #15 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f) 34146 #16 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5) 34147 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d) 34148 #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2) 34149 #19 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2) 34150 #20 pthread_once <null> (libtsan.so.0+0x4457c) 34151 #21 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd) 34152 #22 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224) 34153 #23 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852) 34154 #24 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef) 34155 #25 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac5b0) 34156 #26 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabed2) 34157 #27 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dacf81) 34158 #28 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac3b2) 34159 #29 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf6e4) 34160 #30 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf66f) 34161 #31 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf624) 34162 #32 <null> <null> (libstdc++.so.6+0xdcac2) 34163 ... 34164 SUMMARY: ThreadSanitizer: data race bfd/cache.c:584 in bfd_open_file 34165 ... 34166 34167 The race happens when issuing the "file $exec" command. 34168 34169 The race is between: 34170 - a worker thread getting the build id while writing the index cache, and in 34171 the process reading bfd::format, and 34172 - the main thread calling find_main_name, and in the process setting 34173 bfd::cacheable. 34174 34175 The two bitfields bfd::cacheable and bfd::format share the same bitfield 34176 container. 34177 34178 Fix this by capturing the build id in the main thread, and using the captured 34179 value in the worker thread. 34180 34181 Likewise for the dwz build id, which likely suffers from the same issue. 34182 34183 While we're at it, also move the creation of the cache directory to 34184 the index_cache_store_context constructor, to: 34185 - make sure there's no race between subsequent file commands, and 34186 - issue any related warning or error messages during the file command. 34187 34188 Tested on x86_64-linux. 34189 34190 Approved-By: Tom Tromey <tom@tromey.com> 34191 34192 PR symtab/30392 34193 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392 34194 341952023-08-04 Tom de Vries <tdevries@suse.de> 34196 34197 [gdb/symtab] Fix data race on index_cache::m_enabled 34198 With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I 34199 run into: 34200 ... 34201 (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache 34202 Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache... 34203 (gdb) show index-cache enabled 34204 The index cache is off. 34205 (gdb) PASS: gdb.base/index-cache.exp: test_basic_stuff: index-cache is disabled by default 34206 set index-cache enabled on 34207 ================== 34208 WARNING: ThreadSanitizer: data race (pid=32248) 34209 Write of size 1 at 0x00000321f540 by main thread: 34210 #0 index_cache::enable() gdb/dwarf2/index-cache.c:76 (gdb+0x82cfdd) 34211 #1 set_index_cache_enabled_command gdb/dwarf2/index-cache.c:270 (gdb+0x82d9af) 34212 #2 bool setting::set<bool>(bool const&) gdb/command.h:353 (gdb+0x6fe5f2) 34213 #3 do_set_command(char const*, int, cmd_list_element*) gdb/cli/cli-setshow.c:414 (gdb+0x6fcd21) 34214 #4 execute_command(char const*, int) gdb/top.c:567 (gdb+0xff2e64) 34215 #5 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94acc0) 34216 #6 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b37d) 34217 #7 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103467e) 34218 #8 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a265) 34219 #9 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdd3f) 34220 #10 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a064) 34221 #11 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a125) 34222 #12 stdin_event_handler gdb/ui.c:155 (gdb+0x1074922) 34223 #13 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94de4) 34224 #14 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9551c) 34225 #15 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93908) 34226 #16 start_event_loop gdb/main.c:412 (gdb+0xb5a256) 34227 #17 captured_command_loop gdb/main.c:476 (gdb+0xb5a445) 34228 #18 captured_main gdb/main.c:1320 (gdb+0xb5c5c5) 34229 #19 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c674) 34230 #20 main gdb/gdb.c:32 (gdb+0x416776) 34231 34232 Previous read of size 1 at 0x00000321f540 by thread T12: 34233 #0 index_cache::enabled() const gdb/dwarf2/index-cache.h:48 (gdb+0x82e1a6) 34234 #1 index_cache::store(dwarf2_per_bfd*) gdb/dwarf2/index-cache.c:94 (gdb+0x82d0bc) 34235 #2 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:638 (gdb+0x7f1b97) 34236 #3 operator() gdb/dwarf2/cooked-index.c:468 (gdb+0x7f0f24) 34237 #4 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f285b) 34238 #5 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952) 34239 #6 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0) 34240 #7 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91) 34241 #8 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59) 34242 #9 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660) 34243 #10 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c) 34244 #11 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623) 34245 #12 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf) 34246 #13 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f) 34247 #14 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5) 34248 #15 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d) 34249 #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2) 34250 #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2) 34251 #18 pthread_once <null> (libtsan.so.0+0x4457c) 34252 #19 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd) 34253 #20 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224) 34254 #21 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852) 34255 #22 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef) 34256 #23 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac492) 34257 #24 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabdb4) 34258 #25 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dace63) 34259 #26 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac294) 34260 #27 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf5c6) 34261 #28 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf551) 34262 #29 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf506) 34263 #30 <null> <null> (libstdc++.so.6+0xdcac2) 34264 34265 Location is global 'global_index_cache' of size 48 at 0x00000321f520 (gdb+0x00000321f540) 34266 ... 34267 SUMMARY: ThreadSanitizer: data race gdb/dwarf2/index-cache.c:76 in index_cache::enable() 34268 ... 34269 34270 The race happens when issuing a "file $exec" command followed by a 34271 "set index-cache enabled on" command. 34272 34273 The race is between: 34274 - a worker thread reading index_cache::m_enabled to determine whether an 34275 index-cache entry for $exec needs to be written 34276 (due to command "file $exec"), and 34277 - the main thread setting index_cache::m_enabled 34278 (due to command "set index-cache enabled on"). 34279 34280 Fix this by capturing the value of index_cache::m_enabled in the main thread, 34281 and using the captured value in the worker thread. 34282 34283 Tested on x86_64-linux. 34284 34285 PR symtab/30392 34286 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392 34287 342882023-08-04 Alan Modra <amodra@gmail.com> 34289 34290 ppc: sanity check writing relocs 34291 Check for output buffer overruns. 34292 34293 * elf32-ppc.c (swap_reloc_out, count_and_swap_reloc_out): New 34294 functions. Use throughout file. 34295 * elf64-ppc.c (swap_reloc_out, count_and_swap_reloc_out): Likewise. 34296 342972023-08-04 Alan Modra <amodra@gmail.com> 34298 34299 PR30697, ppc32 mix of local-dynamic and global-dynamic TLS 34300 This fixes miscounting of dynamic relocations on GOT entries when 34301 a) there are both local-dynamic and global-dynamic tls accesss for a 34302 given symbol, and 34303 b) the symbol is global with non-default visibility, and 34304 c) the __tls_get_addr calls aren't optimised away. 34305 34306 PR 30697 34307 bfd/ 34308 * elf32-ppc.c (allocate_dynrelocs): Correct local-dynamic 34309 reloc count. 34310 ld/ 34311 * testsuite/ld-powerpc/tls32ldgd.d, 34312 * testsuite/ld-powerpc/tls32ldgd.s: New test. 34313 * testsuite/ld-powerpc/powerpc.exp: Run it. 34314 343152023-08-04 Bruno Larsen <blarsen@redhat.com> 34316 34317 gdb/testsuite: Disable gdb.compile when testing with clang 34318 Attempting to test the gdb.compile with clang as the compiler results in 34319 over 300 unexpected errors, due to a segmentation fault and several 34320 handshake failures. Since the whole feature is designed around a gcc 34321 plugin, and even the gcc testing is shaky at best, this commit restricts 34322 those tests to only running under gcc. If that gets fixed, this commit 34323 can be reverted. 34324 34325 Approved-By: Tom Tromey <tom@tromey.com> 34326 343272023-08-04 GDB Administrator <gdbadmin@sourceware.org> 34328 34329 Automatic date update in version.in 34330 343312023-08-03 Tom de Vries <tdevries@suse.de> 34332 34333 [gdb/symtab] Remove superfluous handling of Ada main in write_cooked_index 34334 I filed PR29179 about the following FAIL in test-case 34335 gdb.ada/O2_float_param.exp with target board cc-with-gdb-index: 34336 ... 34337 (gdb) break increment^M 34338 Function "increment" not defined.^M 34339 Make breakpoint pending on future shared library load? (y or [n]) n^M 34340 (gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: gdb_breakpoint: \ 34341 set breakpoint at increment 34342 ... 34343 34344 The FAIL was a regression since commit 2cf349be0e3 ("Do not put linkage names 34345 into .gdb_index"). 34346 34347 Before that commit we had: 34348 ... 34349 $ readelf -w foo > READELF 34350 $ grep callee.*increment READELF 34351 [1568] callee__increment: 5 [global, function] 34352 [3115] callee.increment: 5 [global, function] 34353 ... 34354 but after only: 34355 ... 34356 $ grep callee.*increment READELF 34357 [3115] callee.increment: 5 [global, function] 34358 ... 34359 34360 The regression was fixed by commit 67e83a0deef ("Fix regression in 34361 c-linkage-name.exp with gdb index"), which got us again: 34362 ... 34363 $ grep callee.*increment READELF 34364 [1568] callee__increment: 5 [global, function] 34365 [3115] callee.increment: 5 [global, function] 34366 ... 34367 34368 The commit however did not claim that particular PR. A subsequent commit, 34369 commit 5fea9794325 ("Improve Ada support in .gdb_index") did claim to fix it, 34370 together with commit dd05fc7071a ("Change .gdb_index de-duplication 34371 implementation"). 34372 34373 The commit 5fea9794325 contained the following addition in write_cooked_index: 34374 ... 34375 + if (entry->per_cu->lang () == language_ada) 34376 + { 34377 + /* We want to ensure that the Ada main function's name 34378 + appears verbatim in the index. However, this name will 34379 + be of the form "_ada_mumble", and will be rewritten by 34380 + ada_decode. So, recognize it specially here and add it 34381 + to the index by hand. */ 34382 + if (entry->tag == DW_TAG_subprogram 34383 + && strcmp (main_for_ada, name) == 0) 34384 + { 34385 + /* Leave it alone. */ 34386 + } 34387 + else 34388 + { 34389 + /* In order for the index to work when read back into 34390 + gdb, it has to use the encoded name, with any 34391 + suffixes stripped. */ 34392 + std::string encoded = ada_encode (name, false); 34393 + name = obstack_strdup (&symtab->m_string_obstack, 34394 + encoded.c_str ()); 34395 + } 34396 + } 34397 ... 34398 34399 The code contains some special handling related to the Ada main function, so 34400 let's look at that one: foo. Before commit 67e83a0deef we have: 34401 ... 34402 $ grep foo.*function READELF 34403 [3733] foo: 7 [global, function] 34404 ... 34405 and after: 34406 ... 34407 $ grep foo.*function READELF 34408 [2738] _ada_foo: 7 [global, function] 34409 [3733] foo: 7 [global, function] 34410 ... 34411 so that looks identical to the callee.increment case. 34412 34413 At commit 5fea9794325, we have slightly different index numbers: 34414 ... 34415 $ grep foo.*function READELF 34416 [1658] foo: 7 [global, function] 34417 [2738] _ada_foo: 7 [global, function] 34418 ... 34419 but otherwise the same result. 34420 34421 If we disable the special handling of the Ada main function like so: 34422 ... 34423 - if (entry->tag == DW_TAG_subprogram 34424 + if (false && entry->tag == DW_TAG_subprogram 34425 ... 34426 we still have the exact same result because: 34427 ... 34428 (gdb) p main_for_ada 34429 $1 = 0x352e6a0 "_ada_foo" 34430 ... 34431 and ada_encode ("_ada_foo", false) == "_ada_foo". 34432 34433 The comment seems to be copied from debug_names::insert, which does indeed use 34434 ada_decode, while the code in write_cooked_index uses ada_encode instead. 34435 34436 Remove the superfluous special handling of Ada main in write_cooked_index. 34437 34438 Tested on x86_64-linux, with target boards unix and cc-with-gdb-index. 34439 34440 Approved-By: Tom Tromey <tom@tromey.com> 34441 344422023-08-03 Tom Tromey <tromey@adacore.com> 34443 34444 Remove f-string from DAP 34445 One more f-string snuck into the DAP code, in breakpoint.py. Most of 34446 them were removed here: 34447 34448 https://sourceware.org/pipermail/gdb-patches/2023-June/200023.html 34449 34450 but I think this one landed after that patch. 34451 34452 While DAP only supports Python 3.5 and later, f-strings were added in 34453 3.6, so remove this. 34454 34455 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708 34456 344572023-08-03 Tom Tromey <tromey@adacore.com> 34458 34459 Use frame.name() in FrameDecorator 34460 A co-worker pointed out that gdb's DAP implementation might return an 34461 integer for the name of a stack frame, like: 34462 34463 {"id": 1, "name": 93824992310799, ...} 34464 34465 This can be seen currently in the logs of the bt-nodebug.exp test 34466 case. 34467 34468 What is happening is that FrameDecorator falls back on returning the 34469 PC when the frame's function symbol cannot be found, relying on the 34470 gdb core to look up the minsym and print its name. 34471 34472 This can actually yield the wrong answer sometimes, because it falls 34473 into the get_frame_pc / get_frame_address_in_block problem -- if the 34474 frame is at a call to a noreturn function, the PC in this case might 34475 appear to be in the next function in memory. For more on this, see: 34476 34477 https://sourceware.org/bugzilla/show_bug.cgi?id=8416 34478 34479 and related bugs. 34480 34481 However, there's a different approach we can take: the code here can 34482 simply use Frame.name. This handles the PC problem correctly, and 34483 gets us the information we need. 34484 344852023-08-03 Andrew Burgess <aburgess@redhat.com> 34486 34487 gdb: avoid double stop after failed breakpoint condition check 34488 This commit replaces this earlier commit: 34489 34490 commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b 34491 Date: Fri Oct 14 14:53:15 2022 +0100 34492 34493 gdb: don't always print breakpoint location after failed condition check 34494 34495 and is a result of feedback received here[1]. 34496 34497 The original commit addressed a problem where, if a breakpoint 34498 condition included an inferior function call, and if the inferior 34499 function call failed, then GDB would announce the stop twice. Here's 34500 an example of GDB's output before the above commit that shows the 34501 problem being addressed: 34502 34503 (gdb) break foo if (some_func ()) 34504 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 34505 (gdb) r 34506 Starting program: /tmp/bpcond 34507 34508 Program received signal SIGSEGV, Segmentation fault. 34509 0x0000000000401116 in some_func () at bpcond.c:5 34510 5 return *p; 34511 Error in testing condition for breakpoint 1: 34512 The program being debugged stopped while in a function called from GDB. 34513 Evaluation of the expression containing the function 34514 (some_func) will be abandoned. 34515 When the function is done executing, GDB will silently stop. 34516 34517 Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 34518 5 return *p; 34519 (gdb) 34520 34521 The original commit addressed this issue in breakpoint.c, by spotting 34522 that the $pc had changed while evaluating the breakpoint condition, 34523 and inferring from this that GDB must have stopped elsewhere. 34524 34525 However, the way in which the original commit suppressed the second 34526 stop announcement was to set bpstat::print to true -- this tells GDB 34527 not to print the frame during the stop announcement, and for the CLI 34528 this is fine, however, it was pointed out that for the MI this still 34529 isn't really enough. Below is an example from an MI session after the 34530 above commit was applied, this shows the problem with the above 34531 commit: 34532 34533 -break-insert -c "cond_fail()" foo 34534 ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"} 34535 (gdb) 34536 -exec-run 34537 =thread-group-started,id="i1",pid="2636270" 34538 =thread-created,id="1",group-id="i1" 34539 =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}] 34540 ^running 34541 *running,thread-id="all" 34542 (gdb) 34543 =library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}] 34544 =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}] 34545 ~"\nProgram" 34546 ~" received signal SIGSEGV, Segmentation fault.\n" 34547 ~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n" 34548 ~"24\t return *p;\t\t\t/* Crash here. */\n" 34549 *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9" 34550 &"Error in testing condition for breakpoint 1:\n" 34551 &"The program being debugged was signaled while in a function called from GDB.\n" 34552 &"GDB remains in the frame where the signal was received.\n" 34553 &"To change this behavior use \"set unwindonsignal on\".\n" 34554 &"Evaluation of the expression containing the function\n" 34555 &"(cond_fail) will be abandoned.\n" 34556 &"When the function is done executing, GDB will silently stop.\n" 34557 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"} 34558 *stopped 34559 (gdb) 34560 34561 Notice that we still see two '*stopped' lines, the first includes the 34562 full frame information, while the second has no frame information, 34563 this is a result of bpstat::print having been set. Ideally, the 34564 second '*stopped' line should not be present. 34565 34566 By setting bpstat::print I was addressing the problem too late, this 34567 flag really only changes how interp::on_normal_stop prints the stop 34568 event, and interp::on_normal_stop is called (indirectly) from the 34569 normal_stop function in infrun.c. A better solution is to avoid 34570 calling normal_stop at all for the stops which should not be reported 34571 to the user, and this is what I do in this commit. 34572 34573 This commit has 3 parts: 34574 34575 1. In breakpoint.c, revert the above commit, 34576 34577 2. In fetch_inferior_event (infrun.c), capture the stop-id before 34578 calling handle_inferior_event. If, after calling 34579 handle_inferior_event, the stop-id has changed, then this indicates 34580 that somewhere within handle_inferior_event, a stop was announced to 34581 the user. If this is the case then GDB should not call normal_stop, 34582 and we should rely on whoever announced the stop to ensure that we 34583 are in a PROMPT_NEEDED state, which means the prompt will be 34584 displayed once fetch_inferior_event returns. And, 34585 34586 3. In infcall.c, do two things: 34587 34588 (a) In run_inferior_call, after making the inferior call, ensure 34589 that either async_disable_stdin or async_enable_stdin is called 34590 to put the prompt state, and stdin handling into the correct 34591 state based on whether the inferior call completed successfully 34592 or not, and 34593 34594 (b) In call_thread_fsm::should_stop, call async_enable_stdin 34595 rather than changing the prompt state directly. This isn't 34596 strictly necessary, but helped me understand this code more. 34597 This async_enable_stdin call is only reached if normal_stop is 34598 not going to be called, and replaces the async_enable_stdin call 34599 that exists in normal_stop. Though we could just adjust the 34600 prompt state if felt (to me) much easier to understand when I 34601 could see this call and the corresponding call in normal_stop. 34602 34603 With these changes in place now, when the inferior call (from the 34604 breakpoint condition) fails, infcall.c leaves the prompt state as 34605 PROMPT_NEEDED, and leaves stdin registered with the event loop. 34606 34607 Back in fetch_inferior_event GDB notices that the stop-id has changed 34608 and so avoids calling normal_stop. 34609 34610 And on return from fetch_inferior_event GDB will display the prompt 34611 and handle input from stdin. 34612 34613 As normal_stop is not called the MI problem is solved, and the test 34614 added in the earlier mentioned commit still passes just fine, so the 34615 CLI has not regressed. 34616 34617 [1] https://inbox.sourceware.org/gdb-patches/6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net/ 34618 346192023-08-03 Tom Tromey <tom@tromey.com> 34620 34621 Remove PEI_HEADERS define 34622 I noticed a few files double-included libcoff.h, and digging deeper I 34623 found that the PEI_HEADERS define is a sort of external include guard. 34624 34625 This patch adds include guards to the few files in include/coff that 34626 were missing one, and then removes the PEI_HEADERS workaround and the 34627 redundant includes. 34628 34629 I didn't see anything in these files that indicated that 34630 double-inclusion would be useful, so it seems to me that this approach 34631 is ok. 34632 34633 Tested by rebuilding with --enable-targets=all. 34634 34635 2023-08-02 Tom Tromey <tromey@adacore.com> 34636 34637 * pei-x86_64.c (PEI_HEADERS): Do not define. 34638 * pei-loongarch64.c (PEI_HEADERS): Do not define. 34639 * pei-aarch64.c (PEI_HEADERS): Do not define. 34640 * pe-x86_64.c (PEI_HEADERS): Do not define. 34641 * pe-aarch64.c (PEI_HEADERS): Do not define. 34642 * libpei.h (_LIBPEI_H): Add include guard. 34643 * coff-x86_64.c (PEI_HEADERS): Do not check. 34644 * coff-loongarch64.c (PEI_HEADERS): Do not check. 34645 * coff-aarch64.c (PEI_HEADERS): Do not check. 34646 34647 include/ChangeLog 34648 2023-08-02 Tom Tromey <tromey@adacore.com> 34649 34650 * coff/x86_64.h (COFF_X86_64_H): Add include guard. 34651 * coff/loongarch64.h (COFF_LOONGARCH64_H): Add include guard. 34652 * coff/aarch64.h (COFF_AARCH64_H): Add include guard. 34653 346542023-08-03 Alan Modra <amodra@gmail.com> 34655 34656 readelf sprintf optimisation 34657 This replaces sprintf and strcat calls with stpcpy, and makes use of 34658 sprintf return value rather than using strlen, for get_machine_flags. 34659 34660 decode_NDS32_machine_flags made use of snprintf, which is arguably the 34661 "correct" way to do things if there can be a buffer overflow. In this 34662 case I don't think there can be, the buffer is 1k in size which is at 34663 least 5 times more than needed. What's more, snprintf returns the 34664 count of chars that would be output given no buffer limit, which means 34665 code like 34666 r += snprintf (buf + r, size - r, ...); 34667 r += snprintf (buf + r, size - r, ...); 34668 is just wrong. There needs to be a check on the return value in order 34669 to prevent buf + r being out of bounds for the second snprintf call. 34670 34671 BTW, if you look closely you'll see the return value of the decode 34672 functions is unused. I admit to getting a little carried away with 34673 writing "out = stpcpy (out, ...):" in each of the decode functions and 34674 didn't notice that until get_machine_flags was trimmed down to a much 34675 smaller size. When I did notice, I decided it's not such a bad thing. 34676 34677 * readelf.c (decode_ARC_machine_flags, decode_ARM_machine_flags), 34678 (decode_AVR_machine_flags, decode_NDS32_machine_flags), 34679 (decode_AMDGPU_machine_flags): Use stpcpy and sprintf return 34680 value. Return end of string. 34681 (decode_BLACKFIN_machine_flags, decode_FRV_machine_flags), 34682 (decode_IA64_machine_flags, decode_LOONGARCH_machine_flags), 34683 (decode_M68K_machine_flags, decode_MeP_machine_flags), 34684 (decode_MIPS_machine_flags, decode_MSP430_machine_flags), 34685 (decode_PARISC_machine_flags, decode_RISCV_machine_flags), 34686 (decode_RL78_machine_flags, decode_RX_machine_flags), 34687 (decode_SH_machine_flags, decode_SPARC_machine_flags), 34688 (decode_V800_machine_flags, decode_V850_machine_flags), 34689 (decode_Z80_machine_flags): New functions, split out from.. 34690 (get_machine_flags): ..here. Similarly use stpcpy. 34691 346922023-08-03 Alan Modra <amodra@gmail.com> 34693 34694 binutils sprintf optimisation 34695 Avoid the use of sprintf with a "%s" format string, replacing with 34696 strcpy or stpcpy. Use sprintf return value rather than a later 34697 strlen. Don't use strcat where we can keep track of the end of a 34698 string output buffer. 34699 34700 * dlltool.c (look_for_prog): memcpy prefix and strcpy prog_name. 34701 * dllwrap.c (look_for_prog): Likewise. 34702 * resrc.c (look_for_default): Likewise. Add quotes with memmove 34703 rather than allocating another buffer. 34704 * size.c (size_number): Use sprintf return value. 34705 * stabs.c (parse_stab_argtypes): Likewise. 34706 * windmc.c (write_bin): Likewes, and use stpcpy. 34707 * wrstabs.c: Similarly throughout. 34708 347092023-08-03 Alan Modra <amodra@gmail.com> 34710 34711 cris: sprintf optimisation 34712 Since I was poking at cris-dis.c to avoid the sanitizer warning, 34713 I figure I might as well make use of stpcpy and sprintf return value 34714 in other places in this file. 34715 34716 * cris-dis.c (format_hex): Use sprintf return value. 34717 (format_reg): Use stpcpy and sprintf return, avoiding strlen. 34718 (format_sup_reg): Likewise. 34719 347202023-08-03 Alan Modra <amodra@gmail.com> 34721 34722 arm: sanitizer stringop-overflow 34723 In function 'memset', 34724 inlined from 'create_unwind_entry' at /home/alan/src/binutils-gdb/gas/config/tc-arm.c:27881:3: 34725 /usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' specified size between 2147483652 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=] 34726 59 | return __builtin___memset_chk (__dest, __ch, __len, 34727 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34728 60 | __glibc_objsize0 (__dest)); 34729 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 34730 34731 * config/tc-arm.c (create_unwind_entry): Return after bad size, 34732 and bad opcode count. 34733 347342023-08-03 Alan Modra <amodra@gmail.com> 34735 34736 xtensa: sprintf sanitizer null destination pointer 34737 * config/tc-xtensa.c (xtensa_add_config_info): Use auto buffer 34738 rather than malloc. Use sprintf return value. 34739 34740 ld: sprintf sanitizer null destination pointer 34741 * configure.ac (stpcpy): AC_CHECK_DECLS. 34742 * sysdep.h (stpcpy): Add fallback declaraion. 34743 * config.in: Regenerate. 34744 * configure: Regenerate. 34745 * emultempl/pe.em (open_dynamic_archive): Use 34746 stpcpy rather than sprintf plus strlen. 34747 * emultempl/pep.em (open_dynamic_archive): Likewise. 34748 * emultempl/xtensaelf.em (elf_xtensa_before_allocation): Use 34749 auto rather than malloc'd buffer. Use sprintf count. 34750 * ldelf.c (ldelf_search_needed): Use memcpy in place of sprintf. 34751 * pe-dll.c (pe_process_import_defs): Use string already formed 34752 for alias match rather than recreating. 34753 34754 gprof: sprintf sanitizer null destination pointer 34755 * basic_blocks.c (annotate_with_count): Use output of sprintf 34756 rather than strlen. 34757 34758 resrc: sprintf sanitizer null destination pointer 34759 * resrc.c (read_rc_file): Use stpcpy rather than sprintf 34760 followed by strlen. Tidy. 34761 34762 dlltool: sprintf sanitizer null destination pointer 34763 * dlltool.c (gen_lib_file): Avoid bogus sanitizer error. 34764 347652023-08-03 Alan Modra <amodra@gmail.com> 34766 34767 wrstabs: sprintf sanitizer null destination pointer 34768 gcc-2.12 seems to be ignoring __attribute__((__returns_nonnull__)) 34769 on xmalloc. 34770 34771 * wrstabs.c (stab_method_type): Use stpcpy rather than sprintf 34772 or strcat. 34773 347742023-08-03 Alan Modra <amodra@gmail.com> 34775 34776 cris: sprintf sanitizer null destination pointer 34777 Simplify the sprintf calls, and use sprintf return value. Older code 34778 in binutils avoided using the sprintf return count of chars printed, 34779 because with some older C libraries it wasn't reliable. Nowadays it 34780 should be OK to use (and we already use the return value elsewhere). 34781 sprintf can't return an error status of -1 here. 34782 34783 * cris-dis.c (format_dec): Avoid sanitizer warning. Use sprintf 34784 return value rather than calling strlen. 34785 347862023-08-03 Alan Modra <amodra@gmail.com> 34787 34788 objdump, nm: sprintf sanitizer null destination pointer 34789 Seen on Ubuntu 23.04 x86_64-linux using gcc-12.2 and gcc-12.3 with 34790 CFLAGS="-m32 -g -O2 -fsanitize=address,undefined". 34791 34792 CC objdump.o 34793 In file included from /usr/include/stdio.h:906, 34794 from /home/alan/src/binutils-gdb/binutils/sysdep.h:24, 34795 from /home/alan/src/binutils-gdb/binutils/objdump.c:51: 34796 In function 'sprintf', 34797 inlined from 'display_utf8' at /home/alan/src/binutils-gdb/binutils/objdump.c:621:14, 34798 inlined from 'sanitize_string.part.0' at /home/alan/src/binutils-gdb/binutils/objdump.c:742:11: 34799 /usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=] 34800 30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, 34801 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34802 31 | __glibc_objsize (__s), __fmt, 34803 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34804 32 | __va_arg_pack ()); 34805 | ~~~~~~~~~~~~~~~~~ 34806 cc1: all warnings being treated as errors 34807 34808 The warning is bogus of course. xmalloc is guaranteed to return 34809 non-NULL, but apparently this isn't seen in display_utf6. The same 34810 doesn't happen with -m64, maybe due to inlining differences, I haven't 34811 investigated fully. Easily avoided as we hardly need to use sprintf 34812 for a single char, or a two char string. 34813 34814 * objdump.c (display_utf8): Avoid bogus sprintf sanitizer warning. 34815 Use hex ESC to switch back to default colour. 34816 (sanitize_string): Comment. Bump buffer size by one. Fix overlong 34817 line. 34818 * nm.c (display_utf8, sanitize_string): As above. 34819 348202023-08-03 Andrew Burgess <aburgess@redhat.com> 34821 34822 gdb: fix possible nullptr dereference in a remote_debug_printf call 34823 While working on another patch I triggered a segfault from within the 34824 function remote_target::discard_pending_stop_replies. Turns out this 34825 was caused by a cut&paste error introduced in this commit: 34826 34827 commit df5ad102009c41ab4dfadbb8cfb8c8b2a02a4f78 34828 Date: Wed Dec 1 09:40:03 2021 -0500 34829 34830 gdb, gdbserver: detach fork child when detaching from fork parent 34831 34832 This commit adds a remote_debug_printf call that was copied from 34833 earlier in the function, however, the new call wasn't updated to use 34834 the appropriate local variable. The local variable that it is using 34835 might be nullptr, in which case we trigger undefined behaviour, and 34836 could crash, which is what I was seeing. 34837 34838 Fixed by updating to use the correct local variable. 34839 348402023-08-03 Tom de Vries <tdevries@suse.de> 34841 34842 Fix Wlto-type-mismatch in opcodes/ft32-dis.c 34843 348442023-08-03 Tsukasa OI <research_trasio@irq.a4lg.com> 34845 34846 RISC-V: Add support for 'Zvfh' and 'Zvfhmin' 34847 This commit adds support for recently ratified vector FP16 extensions: 34848 'Zvfh' and 'Zvfhmin'. 34849 34850 This is based on: 34851 <https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point> 34852 <https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfh-vector-extension-for-half-precision-floating-point> 34853 34854 Despite not having any new instructions, it will be necessary since those 34855 extensions are already implemented in GCC. 34856 34857 Note that however, in this commit, following dependencies are implemented. 34858 34859 1. 'Zvfhmin' -> 'Zve32f' 34860 2. 'Zvfh' -> 'Zvfhmin' (not 'Zvfh' -> 'Zve32f' as in the documentation) 34861 3. 'Zvfh' -> 'Zfhmin' 34862 34863 This is because the instructions and configurations supported by the 34864 'Zvfh' extension is a strict superset of the 'Zvfhmin' extension and 34865 'Zvfh' -> 'Zve32f' dependency is indirectly derived from that fact. 34866 34867 bfd/ChangeLog: 34868 34869 * elfxx-riscv.c (riscv_implicit_subsets): Add implications 34870 related to 'Zvfh' and 'Zvfhmin' extensions. 34871 (riscv_supported_std_z_ext) Add 'Zvfh' and 'Zvfhmin' to the list. 34872 348732023-08-03 Tsukasa OI <research_trasio@irq.a4lg.com> 34874 34875 RISC-V: Imply 'Zicsr' from 'Zve32x' 34876 Further clarification is made so that 'Zve32x' implies 'Zicsr' (the same 34877 implication is already implemented in LLVM). 34878 34879 See related issue (the author raised) on the vector specification: 34880 <https://github.com/riscv/riscv-v-spec/issues/908> 34881 and its resolution: 34882 <https://github.com/riscv/riscv-v-spec/issues/909> 34883 34884 bfd/ChangeLog: 34885 34886 * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zve32x' -> 'Zicsr'. 34887 348882023-08-03 GDB Administrator <gdbadmin@sourceware.org> 34889 34890 Automatic date update in version.in 34891 348922023-08-02 Tom de Vries <tdevries@suse.de> 34893 34894 [gdb] Initialize main_thread_id earlier 34895 I wrote a patch using is_main_thread (), and found it returning false in the 34896 main thread due to main_thread_id not being initialized yet. 34897 34898 Initialization currently takes place in _initialize_run_on_main_thread, but 34899 that's too late for earlier uses. 34900 34901 Fix this by initializing, either: 34902 - when entering main, or 34903 - on an earlier first use. 34904 34905 Tested on x86_64-linux. 34906 34907 Approved-By: Tom Tromey <tom@tromey.com> 34908 349092023-08-02 Tom de Vries <tdevries@suse.de> 34910 34911 [gdb/dap] Disable DAP for python <= 3.5 34912 DAP requires python module typing, which is supported starting python 3.5. 34913 34914 Make this formal by: 34915 - disabling the dap interpreter for python version < 3.5 34916 - returning 0 in allow_dap_tests for python version < 3.5 34917 34918 Approved-By: Tom Tromey <tom@tromey.com> 34919 34920 PR dap/30708 34921 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708 34922 349232023-08-02 Tom Tromey <tromey@adacore.com> 34924 34925 Avoid failures in fixed_points.exp with older GCC 34926 Tom de Vries pointed out that my recent change to fixed_points.exp 34927 failed with older versions of GCC. This patch fixes the problem by 34928 skipping the new test in this situation. 34929 349302023-08-02 Sam James <sam@gentoo.org> 34931 34932 Revert "2.41 Release sources" 34933 This reverts commit 675b9d612cc59446e84e2c6d89b45500cb603a8d. 34934 34935 See https://sourceware.org/pipermail/binutils/2023-August/128761.html. 34936 349372023-08-02 Nick Clifton <nickc@redhat.com> 34938 34939 2.41 Release sources 34940 349412023-08-02 Khem Raj <raj.khem@gmail.com> 34942 34943 gprofng: Fix build with 64bit file offset on 32bit machines 34944 gprofng/ChangeLog 34945 2023-07-31 Khem Raj <raj.khem@gmail.com> 34946 34947 * libcollector/iotrace.c: Define open64, fgetpos64, and fsetpos64 34948 only when __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not 34949 defined. 34950 349512023-08-02 GDB Administrator <gdbadmin@sourceware.org> 34952 34953 Automatic date update in version.in 34954 349552023-08-01 Alan Modra <amodra@gmail.com> 34956 34957 Don't declare xmalloc and others in ldmisc.h 34958 * ldmisc.h (xmalloc, xrealloc, xexit, yyerror): Don't declare. 34959 * emultempl/pdp11.em: Include libiberty.h. 34960 * emultempl/ticoff.em: Likewise. 34961 * emultempl/vms.em: Likewise. 34962 * ldctor.c: Likewise. 34963 * ldelfgen.c: Likewise. 34964 * ldgram.y: Likewise. 34965 (yyerror): Prototype and make static. 34966 349672023-08-01 Alan Modra <amodra@gmail.com> 34968 34969 Don't declare xmalloc or xrealloc in bucomm.h 34970 It's better to include the proper header, which has declarations with 34971 various attributes. Commit 096aefc040 in 1994 introduced this wart. 34972 34973 * bucomm.h (xmalloc, xrealloc): Delete declaration. 34974 * od-macho.c: Include libiberty.h. 34975 * od-xcoff.c: Include libiberty.h. 34976 349772023-08-01 Alan Modra <amodra@gmail.com> 34978 34979 Regen ld/configure 34980 For commit 3d05c80b5dc4. 34981 349822023-08-01 Tom Tromey <tromey@adacore.com> 34983 34984 Implement DAP "source" request 34985 This implements the DAP "source" request. I renamed the 34986 "loadedSources" function from "sources" to "loaded_sources" to avoid 34987 any confusion. I also moved the loadedSources test to the new 34988 sources.exp. 34989 34990 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30691 34991 349922023-08-01 Tom Tromey <tromey@adacore.com> 34993 34994 Handle Source in DAP breakpointLocations 34995 This changes the DAP breakpointLocations request to accept a Source 34996 and to decode it properly. 34997 34998 Introduce sourceReference handling in DAP 34999 This changes the gdb DAP implementation to emit a real 35000 sourceReference, rather than emitting 0. Sources are tracked in some 35001 maps in sources.py, and a new helper function is introduced to compute 35002 the "Source" object that can be sent to the client. 35003 350042023-08-01 Tom Tromey <tromey@adacore.com> 35005 35006 Don't supply DAP 'path' for non-file shared libraries 35007 The DAP 'module' event may include a 'path' component. I noticed that 35008 this is supplied even when the module in question does not come from a 35009 file. 35010 35011 This patch only emits this field when the objfile corresponds to a 35012 real file. 35013 35014 No test case, because I wasn't sure how to write a portable one. 35015 However, it's clear from gdb.log on Linux: 35016 35017 {"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21} 35018 35019 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676 35020 350212023-08-01 Tom Tromey <tromey@adacore.com> 35022 35023 Implement ValueFormat for DAP 35024 This patch implements ValueFormat for DAP. Currently this only means 35025 supporting "hex". 35026 35027 Note that StackFrameFormat is defined to have many more options, but 35028 none are currently recognized. It isn't entirely clear how these 35029 should be handled. I'll file a new gdb bug for this, and perhaps an 35030 upstream DAP bug as well. 35031 35032 New in v2: 35033 - I realized that the "hover" context was broken, and furthermore 35034 that we only had tests for "hover" failing, not for it succeeding. 35035 This version fixes the oversight and adds a test. 35036 35037 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30469 35038 350392023-08-01 Tom Tromey <tromey@adacore.com> 35040 35041 Respect supportsMemoryReferences in DAP 35042 I noticed that the support for memoryReference in the "variables" 35043 output is gated on the client "supportsMemoryReferences" capability. 35044 35045 This patch implements this and makes some other changes to the DAP 35046 memory reference code: 35047 35048 * Remove the memoryReference special case from _SetResult. 35049 Upstream DAP fixed this oversight in response to 35050 https://github.com/microsoft/debug-adapter-protocol/issues/414 35051 35052 * Don't use the address of a variable as its memoryReference -- only 35053 emit this for pointer types. There's no spec support for the 35054 previous approach. 35055 35056 * Use strip_typedefs to handle typedefs of pointers. 35057 350582023-08-01 Tom Tromey <tromey@adacore.com> 35059 35060 Add DAP support for C++ exceptions 35061 This adds DAP support for the various C++ exception-catching 35062 operations. 35063 35064 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682 35065 350662023-08-01 Tom Tromey <tromey@adacore.com> 35067 35068 Implement DAP 'terminated' event 35069 This implements the DAP 'terminated' event. Vladimir Makaev noticed 35070 that VSCode will not report the debug session as over unless this is 35071 sent. 35072 35073 It's not completely clear when exactly this event ought to be sent. 35074 Here I've done it when the inferior exits. 35075 35076 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30681 35077 350782023-08-01 Tom Tromey <tromey@adacore.com> 35079 35080 Do not send "new breakpoint" event when breakpoint is set 35081 When the DAP client sets a breakpoint, gdb currently sends a "new 35082 breakpoint" event. However, Vladimir Makaev discovered that this 35083 causes VSCode to think there are two breakpoints. 35084 35085 This patch changes gdb to suppress the event in this case. 35086 35087 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678 35088 350892023-08-01 Tom Tromey <tromey@adacore.com> 35090 35091 Move DAP breakpoint event code to breakpoint.py 35092 A subsequent patch will add the ability to suppress breakpoint events 35093 to DAP. My first attempt at this ended up with recurse imports, 35094 causing Python failures. So, this patch moves all the DAP breakpoint 35095 event code to breakpoint.py in preparation for the change. 35096 35097 I've renamed breakpoint_descriptor here as well, because it can now be 35098 private to breakpoint.py. 35099 351002023-08-01 Tom Tromey <tromey@adacore.com> 35101 35102 Full paths in DAP stackTrace responses 35103 Vladimir Makaev noticed that, in some cases, a DAP stackTrace response 35104 would include a relative path name for the "path" component. 35105 35106 This patch changes the frame decorator code to add a new DAP-specific 35107 decorator, and changes the DAP entry point to frame filters to use it. 35108 This decorator prefers the symtab's full name, and does not fall back 35109 to the solib's name. 35110 35111 I'm not entirely happy with this patch, because if a user frame filter 35112 uses FrameDecorator, it may still do the wrong thing. It would be 35113 better to have frame filters return symtab-like objects instead, or to 35114 have a separate method to return the full path to the source file. 35115 35116 I also tend to think that the solib fallback behavior of 35117 FrameDecorator is a mistake. If this is ever needed, it seems to me 35118 that it should be a separate method. 35119 35120 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665 35121 351222023-08-01 Tom Tromey <tromey@adacore.com> 35123 35124 Add "cwd" parameter to DAP launch request 35125 This adds the "cwd" parameter to the DAP launch request. 35126 35127 This came up here: 35128 https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90 35129 ... and seemed like a good idea. 35130 35131 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 35132 351332023-08-01 Tom Tromey <tromey@adacore.com> 35134 35135 Refactor dap_launch 35136 This patch refactors dap_launch to make it more extensible and also 35137 easier to use. 35138 35139 Rename private member of FrameDecorator 35140 In Python, a member name starting with "__" is specially handled to 35141 make it "more private" to the class -- it isn't truly private, but it 35142 is renamed to make it less likely to be reused by mistake. This patch 35143 ensures that this is done for the private method of FrameDecorator. 35144 351452023-08-01 Simon Farre <simon.farre.cx@gmail.com> 35146 35147 Add thread exited event 35148 Reports a thread exit according to the DAP spec: 35149 https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread 35150 35151 This patch requires the ThreadExitedEvent to be checked in, 35152 in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html 35153 35154 Formatted correctly using black 35155 35156 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30474 35157 35158 Approved-By: Tom Tromey <tom@tromey.com> 35159 351602023-08-01 Nick Clifton <nickc@redhat.com> 35161 35162 Fix "--only-keep-debug for ELF relocatables" binutils test for compilers which add .debug_macro sections to object files. 35163 PR 30699 35164 * binutils/testsuite/binutils-all/objcopy.exp (keep_debug_symbols_for_elf_relocatable): Do not add sections containing the string "debug_" to the list of non-debug sections. 35165 351662023-08-01 Jan Beulich <jbeulich@suse.com> 35167 35168 gas: rework timestamp preservation on doc/asconfig.texi 35169 PR 28909 35170 35171 Sadly "cp -p", doing more than just preserving the time stamp, can fail 35172 e.g. upon trying to preserve ownership (which we don't care about), as 35173 can be observed on e.g. Cygwin. Replace the use of -p by a use of touch, 35174 this way also only preserving modification time. 35175 351762023-08-01 Nick Clifton <nickc@redhat.com> 35177 35178 Add note to check that all changes have been pushed before creating the source tarballs 35179 351802023-08-01 Sam James <sam@gentoo.org> 35181 35182 ld: Fix test failures with --enable-textrel-check=error 35183 351842023-08-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 35185 35186 gprofng: create a list of available views 35187 In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use 35188 the output of gp-display-text to display the data. 35189 gp-display-text did not report available views. 35190 35191 gprofng/ChangeLog 35192 2023-07-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 35193 35194 * src/Command.cc: Add commands for gprofng GUI. 35195 * src/gprofng.rc: Set defaults for gprofng GUI. 35196 351972023-08-01 GDB Administrator <gdbadmin@sourceware.org> 35198 35199 Automatic date update in version.in 35200 352012023-07-31 Tom de Vries <tdevries@suse.de> 35202 35203 [gdb/testsuite] Set TSAN_OPTIONS by default to history_size=7 35204 I build gdb with -fsanitize=thread and ran the testsuite, and ran into the 35205 case that a race is detected, but we see the full stack trace only for one of 35206 the two accesses, and the other one is showing "failed to restore the stack". 35207 35208 Try to prevent this by setting ThreadSanitizer flag history_size [1] to the 35209 maximum (7) by default, as suggested here [2]. 35210 35211 Tested on x86_64-linux. 35212 35213 Approved-By: Tom Tromey <tom@tromey.com> 35214 35215 [1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags 35216 [2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE 35217 352182023-07-31 Tom Tromey <tromey@adacore.com> 35219 35220 Fix bug in fixed-point handling 35221 Alexandre Oliva found a bug in gdb's handling of fixed-point -- a 35222 certain Ada fixed-point type would be misintepreted. The bug was that 35223 the DW_AT_small looked like: 35224 35225 <1><13cd>: Abbrev Number: 16 (DW_TAG_constant) 35226 <13ce> DW_AT_GNU_numerator: 1 35227 <13cf> DW_AT_GNU_denominator: 0x8000000000000000 35228 35229 ... but gdb interpreted the denominator as a negative value. 35230 352312023-07-31 Sam James <sam@gentoo.org> 35232 35233 ld: fix typo in --enable-warn-rwx-segments help 35234 352352023-07-31 Lancelot Six <lancelot.six@amd.com> 35236 35237 gdb/amdgpu: Fix debugging multiple inferiors using the ROCm runtime 35238 When debugging a multi-process application where a parent spawns 35239 multiple child processes using the ROCm runtime, I see the following 35240 assertion failure: 35241 35242 ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed. 35243 A problem internal to GDB has been detected, 35244 further debugging may prove unreliable. 35245 ----- Backtrace ----- 35246 0x556e9a318540 gdb_internal_backtrace_1 35247 ../../gdb/bt-utils.c:122 35248 0x556e9a318540 _Z22gdb_internal_backtracev 35249 ../../gdb/bt-utils.c:168 35250 0x556e9a730224 internal_vproblem 35251 ../../gdb/utils.c:396 35252 0x556e9a7304e0 _Z15internal_verrorPKciS0_P13__va_list_tag 35253 ../../gdb/utils.c:476 35254 0x556e9a87aeb4 _Z18internal_error_locPKciS0_z 35255 ../../gdbsupport/errors.cc:58 35256 0x556e9a29f446 process_one_event 35257 ../../gdb/amd-dbgapi-target.c:1071 35258 0x556e9a29f446 process_event_queue 35259 ../../gdb/amd-dbgapi-target.c:1156 35260 0x556e9a29faf2 _ZN17amd_dbgapi_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE 35261 ../../gdb/amd-dbgapi-target.c:1262 35262 0x556e9a6b0965 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE 35263 ../../gdb/target.c:2586 35264 0x556e9a4c221f do_target_wait_1 35265 ../../gdb/infrun.c:3876 35266 0x556e9a4d8489 operator() 35267 ../../gdb/infrun.c:3935 35268 0x556e9a4d8489 do_target_wait 35269 ../../gdb/infrun.c:3964 35270 0x556e9a4d8489 _Z20fetch_inferior_eventv 35271 ../../gdb/infrun.c:4365 35272 0x556e9a87b915 gdb_wait_for_event 35273 ../../gdbsupport/event-loop.cc:694 35274 0x556e9a87c3a9 gdb_wait_for_event 35275 ../../gdbsupport/event-loop.cc:593 35276 0x556e9a87c3a9 _Z16gdb_do_one_eventi 35277 ../../gdbsupport/event-loop.cc:217 35278 0x556e9a521689 start_event_loop 35279 ../../gdb/main.c:412 35280 0x556e9a521689 captured_command_loop 35281 ../../gdb/main.c:476 35282 0x556e9a523c04 captured_main 35283 ../../gdb/main.c:1320 35284 0x556e9a523c04 _Z8gdb_mainP18captured_main_args 35285 ../../gdb/main.c:1339 35286 0x556e9a24b1bf main 35287 ../../gdb/gdb.c:32 35288 --------------------- 35289 ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed. 35290 A problem internal to GDB has been detected, 35291 35292 Before diving into why this error appears, let's explore how things are 35293 expected to work in normal circumstances. When a process being debugged 35294 starts using the ROCm runtime, the following happens: 35295 35296 - The runtime registers itself to the driver. 35297 - The driver creates a "runtime loaded" event and notifies the debugger 35298 that a new event is available by writing to a file descriptor which is 35299 registered in GDB's main event loop. 35300 - GDB core calls the callback associated with this file descriptor 35301 (dbgapi_notifier_handler). Because the amd-dbgapi-target is not 35302 pushed at this point, the handler pulls the "runtime loaded" event 35303 from the driver (this is the only event which can be available at this 35304 point) and eventually pushes the amd-dbgapi-target on the inferior's 35305 target stack. 35306 35307 In a nutshell, this is the expected AMDGPU runtime activation process. 35308 35309 From there, when new events are available regarding the GPU threads, the 35310 same file descriptor is written to. The callback sees that the 35311 amd-dbgapi-target is pushed so marks the amd_dbgapi_async_event_handler. 35312 This will later cause amd_dbgapi_target::wait to be called. The wait 35313 method pulls all the available events from the driver and handles them. 35314 The wait method returns the information conveyed by the first event, the 35315 other events are cached for later calls of the wait method. 35316 35317 Note that because we are under the wait method, we know that the 35318 amd-dbgapi-target is pushed on the inferior target stack. This implies 35319 that the runtime activation event has been seen already. As a 35320 consequence, we cannot receive another event indicating that the runtime 35321 gets activated. This is what the failing assertion checks. 35322 35323 In the case when we have multiple inferiors however, there is a flaw in 35324 what have been described above. If one inferior (let's call it inferior 35325 1) already has the amd-dbgapi-target pushed to its target stack and 35326 another inferior (inferior 2) activates the ROCm runtime, here is what 35327 can happen: 35328 35329 - The driver creates the runtime activation for inferior 2 and writes to 35330 the associated file descriptor. 35331 - GDB has inferior 1 selected and calls target_wait for some reason. 35332 - This prompts amd_dbgapi_target::wait to be called. The method pulls 35333 all events from the driver, including the runtime activation event for 35334 inferior 2, leading to the assertion failure. 35335 35336 The fix for this problem is simple. To avoid such problem, we need to 35337 make sure that amd_dbgapi_target::wait only pulls events for the current 35338 inferior from the driver. This is what this patch implements. 35339 35340 This patch also includes a testcase which could fail before this patch. 35341 35342 This patch has been tested on a system with multiple GPUs which had more 35343 chances to reproduce the original bug. It has also been tested on top 35344 of the downstream ROCgdb port which has more AMDGPU related tests. The 35345 testcase has been tested with `make check check-read1 check-readmore`. 35346 35347 Approved-By: Pedro Alves <pedro@palves.net> 35348 353492023-07-31 Lancelot Six <lancelot.six@amd.com> 35350 35351 gdb/testsuite/rocm: Add the hip_devices_support_debug_multi_process proc 35352 It is not possible to debug multiple processes simultaneously on all 35353 generations of AMDGPU devices. As some tests will need to debug 35354 multiple inferiors using AMDGPU devices, we need to ensure that all 35355 devices available have the required capability. Failing to do so would 35356 result in GDB not being able to debug all inferiors properly. 35357 35358 Add the hip_devices_support_debug_multi_process helper function used to 35359 ensure that all devices available can debug multiple processes. 35360 35361 Approved-By: Pedro Alves <pedro@palves.net> 35362 353632023-07-31 Tom Tromey <tromey@adacore.com> 35364 35365 Set PYTHONMALLOC in the test suite 35366 Setting PYTHONMALLOC helped me locate an earlier bug. It seems to me 35367 that there aren't big downsides to always setting this during testing, 35368 and it might help find other bugs in the future. 35369 353702023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com> 35371 35372 bpf: opcodes: fix regression in BPF disassembler 35373 This patch fixes a regression recently introduced in the BPF 35374 disassembler, that was assuming an abfd was always available in 35375 info->section->owner. Apparently this is not so in GDB, and therefore 35376 https://sourceware.org/bugzilla/show_bug.cgi?id=30705. 35377 35378 Tested in bpf-unkonwn-none. 35379 35380 opcodes/ChangeLog: 35381 35382 2023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com> 35383 35384 PR 30705 35385 * bpf-dis.c (print_insn_bpf): Check that info->section->owner is 35386 actually available before using it. 35387 353882023-07-31 Nick Clifton <nickc@redhat.com> 35389 35390 Updated Spanish translation for the gprof directory 35391 353922023-07-31 Tom Tromey <tromey@adacore.com> 35393 35394 Restore previous sigmask in gdb.block_signals 35395 Tom de Vries found a bug where, sometimes, a SIGCHLD would be 35396 delivered to a non-main thread, wreaking havoc. 35397 35398 The problem is that gdb.block_signals after first blocking a set of 35399 signals, then unblocked the same set rather than restoring the initial 35400 situation. This function being called from the DAP thread lead to 35401 SIGCHLD being unblocked there. 35402 35403 This patch fixes the problem by restoring the previous set of signals 35404 instead. 35405 35406 Tested-by: Tom de Vries <tdevries@suse.de> 35407 Reviewed-By: Tom de Vries <tdevries@suse.de> 35408 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30680 35409 354102023-07-31 Tsukasa OI <research_trasio@irq.a4lg.com> 35411 35412 RISC-V: Fix typo in the test case name 35413 gas/ChangeLog: 35414 35415 * testsuite/gas/riscv/rouding-fail.s: Moved to... 35416 * testsuite/gas/riscv/rounding-fail.s: ...here. 35417 * testsuite/gas/riscv/rouding-fail.d: Moved to... 35418 * testsuite/gas/riscv/rounding-fail.d: ...here. 35419 * testsuite/gas/riscv/rouding-fail.l: Moved to... 35420 * testsuite/gas/riscv/rounding-fail.l: ...here. 35421 354222023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com> 35423 35424 bpf: sim: do not overflow instruction immediates in tests 35425 This patch fixes some instructions in the BPF tests that overflow the 35426 signed immediates. Note that this happened to work before by chance, 35427 as GAS would silently truncate. 35428 35429 Tested in bpf-unknown-none. 35430 354312023-07-31 GDB Administrator <gdbadmin@sourceware.org> 35432 35433 Automatic date update in version.in 35434 354352023-07-31 Joel Brobecker <brobecker@adacore.com> 35436 35437 GDB Global Maintainer update (3 maintainers stepping down) 35438 Doug Evans, Yao Qi and myself are stepping down as GDB Global 35439 Maintainers. This commit therefore moves our entries to the 35440 "Past Maintainers" section. 35441 35442 I've also removed myself as Ada maintainer, as well as MIPS 35443 authorized committer. 35444 354452023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35446 35447 bpf: include, bfd, opcodes: add EF_BPF_CPUVER ELF header flags 35448 This patch adds support for EF_BPF_CPUVER bits in the ELF 35449 machine-dependent header flags. These bits encode the BPF CPU 35450 version for which the object file has been compiled for. 35451 35452 The BPF assembler is updated so it annotates the object files it 35453 generates with these bits. 35454 35455 The BPF disassembler is updated so it honors EF_BPF_CPUVER to use the 35456 appropriate ISA version if the user didn't specify an explicit ISA 35457 version in the command line. Note that a value of zero in 35458 EF_BPF_CPUVER is interpreted by the disassembler as "use the later 35459 supported version" (the BPF CPU versions start with v1.) 35460 35461 The readelf utility is updated to pretty print EF_BPF_CPUVER when it 35462 prints out the ELF header: 35463 35464 $ readelf -h a.out 35465 ELF Header: 35466 ... 35467 Flags: 0x4, CPU Version: 4 35468 35469 Tested in bpf-unknown-none. 35470 35471 include/ChangeLog: 35472 35473 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35474 35475 * elf/bpf.h (EF_BPF_CPUVER): Define. 35476 * opcode/bpf.h (BPF_XBPF): Change from 0xf to 0xff so it fits in 35477 EF_BPF_CPUVER. 35478 35479 binutils/ChangeLog: 35480 35481 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35482 35483 * readelf.c (get_machine_flags): Recognize and pretty print BPF 35484 machine flags. 35485 35486 opcodes/ChangeLog: 35487 35488 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35489 35490 * bpf-dis.c: Initialize asm_bpf_version to -1. 35491 (print_insn_bpf): Set BPF ISA version from the cpu version ELF 35492 header flags if no explicit version set in the command line. 35493 * disassemble.c (disassemble_init_for_target): Remove unused code. 35494 35495 gas/ChangeLog: 35496 35497 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35498 35499 * config/tc-bpf.h (elf_tc_final_processing): Define. 35500 * config/tc-bpf.c (bpf_elf_final_processing): New function. 35501 355022023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35503 35504 bpf: gas: add field overflow checking to the BPF assembler 35505 This patch makes the BPF assembler to throughfully check for overflow 35506 in immediates. This includes relaxed instructions. 35507 35508 Tested in bpf-unknown-none. 35509 35510 gas/ChangeLog: 35511 35512 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com> 35513 35514 * config/tc-bpf.c (signed_overflow): Copy function from 35515 tc-aarch64.c. 35516 (encode_insn): Check for overflow in constant immediates. 35517 (add_relaxed_insn): Pass relax argument to encode_insn. 35518 (add_fixed_insn): Likewise. 35519 * testsuite/gas/bpf/disp16-overflow.d: New file. 35520 * testsuite/gas/bpf/disp16-overflow.s: Likewise. 35521 * testsuite/gas/bpf/disp16-overflow.l: Likewise. 35522 * testsuite/gas/bpf/disp32-overflow.d: Likewise. 35523 * testsuite/gas/bpf/disp32-overflow.s: Likewise. 35524 * testsuite/gas/bpf/disp32-overflow.l: Likewise. 35525 * testsuite/gas/bpf/imm32-overflow.d: Likewise. 35526 * testsuite/gas/bpf/imm32-overflow.s: Likewise. 35527 * testsuite/gas/bpf/imm32-overflow.l: Likewise. 35528 * testsuite/gas/bpf/offset16-overflow.d: Likewise. 35529 * testsuite/gas/bpf/offset16-overflow.s: Likewise. 35530 * testsuite/gas/bpf/offset16-overflow.l: Likewise. 35531 * testsuite/gas/bpf/disp16-overflow-relax.d: Likewise. 35532 * testsuite/gas/bpf/disp16-overflow-relax.l: Likewise. 35533 * testsuite/gas/bpf/disp16-overflow-relax.s: Likewise. 35534 * testsuite/gas/bpf/jump-relax-jump-be.d: New file. 35535 * testsuite/gas/bpf/bpf.exp: Run new tests. 35536 355372023-07-30 Nick Clifton <nickc@redhat.com> 35538 35539 Update how to make a release document after the 2.41 release 35540 355412023-07-30 GDB Administrator <gdbadmin@sourceware.org> 35542 35543 Automatic date update in version.in 35544 355452023-07-29 GDB Administrator <gdbadmin@sourceware.org> 35546 35547 Automatic date update in version.in 35548 355492023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com> 35550 35551 bpf: remove spurious comment from tc-bpf.c 35552 355532023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com> 35554 35555 bpf: gas: support relaxation of V4 jump instructions 35556 The BPF jump-always instruction (JA), like all other jump instructions 35557 in the ISA, get a signed 16-bit displacement target argument denoted 35558 in number of 64-bit words minus one. This can sometimes be overflown. 35559 35560 The BPF V4 ISA thus introduced support for a jump-always 35561 instruction (JAL) that gets a signed 32-bit displacement instead. 35562 35563 This patch makes the BPF assembler to perform the following 35564 relaxations when the disp16 field gets overflown, unless the option 35565 -mno-relax is specified: 35566 35567 JA disp16 -> JAL disp32 35568 Jxx disp16 -> Jxx +1; JA +1; JAL disp32 35569 35570 Documentation and tests added. 35571 Tested in bpf-unknown-none. 35572 35573 gas/ChangeLog: 35574 35575 2023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com> 35576 35577 PR gas/30690 35578 * config/tc-bpf.c (struct bpf_insn): Add fields is_relaxable and 35579 relaxed_exp. 35580 (enum options): Add OPTION_NO_RELAX. 35581 (md_longopts): Likewise for -mno-relax. 35582 (do_relax): New global. 35583 (md_parse_option): Handle OPTION_NO_RELAX. 35584 (RELAX_BRANCH_ENCODE): Define. 35585 (RELAX_BRANCH_P): Likewise. 35586 (RELAX_BRANCH_LENGTH): Likewise. 35587 (RELAX_BRANCH_CONST): Likewise. 35588 (RELAX_BRANCH_UNCOND): Likewise. 35589 (relaxed_branch_length): New function. 35590 (md_estimate_size_before_relax): Likewise. 35591 (read_insn_word): Likewise. 35592 (encode_int16): Likewise. 35593 (encode_int32): Likewise. 35594 (write_insn_bytes): Likewise. 35595 (md_convert_frag): Likewise. 35596 (encode_insn): Likewise. 35597 (install_insn_fixups): Likewise. 35598 (add_fixed_insn): Likewise. 35599 (add_relaxed_insn): Likewise. 35600 (md_assemble): Move instruction encoding logic to the above 35601 new functions. 35602 * testsuite/gas/bpf/jump-relax-ja.d: New test. 35603 * testsuite/gas/bpf/jump-relax-ja-be.d: Likewise. 35604 * testsuite/gas/bpf/jump-relax-ja.s: And corresponding source. 35605 * testsuite/gas/bpf/jump-relax-jump.d: New test. 35606 * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise. 35607 * testsuite/gas/bpf/jump-relax-jump.s: And corresponding source. 35608 * testsuite/gas/bpf/bpf.exp: Run new tests. 35609 * doc/c-bpf.texi (BPF Options): Document -mno-relax. 35610 356112023-07-28 Tom de Vries <tdevries@suse.de> 35612 35613 [gdb] Rename variable main_thread to main_thread_id 35614 I noticed that the variable main_thread: 35615 ... 35616 /* The main thread. */ 35617 35618 static std::thread::id main_thread; 35619 ... 35620 has a confusing name and corresponding comment, because it doesn't contain the 35621 main thread, but rather the main thread's std::thread::id. 35622 35623 Fix this by renaming to main_thread_id. 35624 35625 Tested on x86_64-linux. 35626 35627 Approved-By: Tom Tromey <tom@tromey.com> 35628 356292023-07-28 Tom Tromey <tromey@adacore.com> 35630 35631 Re-acquire GIL earlier in gdbpy_parse_and_eval 35632 Tom de Vries filed a bug about an intermittent gdb DAP failure -- and 35633 coincidentally, at the same time, Alexandra Hájková sent email about a 35634 somewhat similar failure. 35635 35636 After looking into this for a while (with no results) using ASan and 35637 valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug 35638 instantly. 35639 35640 The problem is that gdbpy_parse_and_eval releases the GIL while 35641 calling parse_and_eval, but fails to re-acquire it before calling 35642 value_to_value_object. This is easily fixed by introducing a new 35643 scope. 35644 35645 I wonder whether the test suite should unconditionally set 35646 PYTHONMALLOC=malloc_debug. 35647 35648 Tested-by: Tom de Vries <tdevries@suse.de> 35649 Reviewed-By: Tom de Vries <tdevries@suse.de> 35650 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686 35651 356522023-07-28 Jan Beulich <jbeulich@suse.com> 35653 35654 gas: amend X_unsigned uses 35655 PR gas/30688 35656 35657 X_unsigned being clear does not indicate a negative number; it merely 35658 indicates a signed one (whose sign may still be clear). Amend two uses 35659 by an actual value check. 35660 356612023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35662 35663 MIPS: Support `-gnuabi64' target triplet suffix for 64-bit Linux targets 35664 Make the n64 ABI the default for 64-bit Linux targets specified with 35665 `-gnuabi64' suffix included in the target triplet, for configurations 35666 such as the Debian mips64el and mips64r6el ports. Adjust testsuite 35667 configuration accordingly. 35668 35669 There are the following regressions with the new target triplet: 35670 35671 mips64-linux-gnuabi64 +FAIL: readelf -S bintest 35672 mips64-linux-gnuabi64 +FAIL: MIPS reloc estimation 1 35673 mips64el-linux-gnuabi64 +FAIL: readelf -S bintest 35674 mips64el-linux-gnuabi64 +FAIL: MIPS reloc estimation 1 35675 35676 The `readelf' issue comes from a difference in section headers produced 35677 that the `binutils/testsuite/binutils-all/readelf.s-64' pattern template 35678 does not match. While there has been a precedent it does not appear to 35679 me that there is a clear advantage from adding more and more variations 35680 to the template rather than forking the existing template into multiple 35681 ones for a more exact match. So this is best deferred to a separate 35682 discussion. 35683 35684 The MIPS reloc estimation issue is an actual bug in `objdump', which 35685 discards a number of trailing entries from output here for n64 composed 35686 relocations: 35687 35688 DYNAMIC RELOCATION RECORDS 35689 OFFSET TYPE VALUE 35690 0000000000000000 R_MIPS_NONE *ABS* 35691 0000000000000000 R_MIPS_NONE *ABS* 35692 35693 and consequently `ld/testsuite/ld-mips-elf/reloc-estimate-1.d' does not 35694 match even though ELF output produced is correct according to `readelf': 35695 35696 Relocation section '.rel.dyn' at offset 0x10400 contains 2 entries: 35697 Offset Info Type Sym. Value Sym. Name 35698 000000000000 000000000000 R_MIPS_NONE 35699 Type2: R_MIPS_NONE 35700 Type3: R_MIPS_NONE 35701 000000010000 000300001203 R_MIPS_REL32 0000000000010010 foo@@V2 35702 Type2: R_MIPS_64 35703 Type3: R_MIPS_NONE 35704 35705 As a genuine bug this has to be handled separately. 35706 35707 Co-Authored by: Maciej W. Rozycki <macro@orcam.me.uk> 35708 35709 bfd/ 35710 * config.bfd: Add `mips64*el-*-linux*-gnuabi64' and 35711 `mips64*-*-linux*-gnuabi64' targets. 35712 35713 binutils/ 35714 * testsuite/binutils-all/mips/mips.exp: Handle `*-*-*-gnuabi64' 35715 targets. 35716 * testsuite/binutils-all/objcopy.exp: Handle 35717 `mips64*-*-*-gnuabi64' targets. 35718 * testsuite/binutils-all/remove-relocs-01.d: Likewise. 35719 * testsuite/binutils-all/remove-relocs-04.d: Likewise. 35720 * testsuite/binutils-all/remove-relocs-05.d: Likewise. 35721 * testsuite/binutils-all/remove-relocs-06.d: Likewise. 35722 35723 gas/ 35724 * configure.ac: Handle `mips64*-linux-gnuabi64' targets. 35725 * configure: Regenerate. 35726 * testsuite/gas/mips/compact-eh-eb-7.d: Handle 35727 `mips64*-*-*-gnuabi64' targets. 35728 * testsuite/gas/mips/compact-eh-el-7.d: Likewise. 35729 35730 ld/ 35731 * configure.tgt: Add `mips64*el-*-linux-gnuabi64' and 35732 `mips64*-*-linux-gnuabi64' targets. 35733 * testsuite/ld-undefined/undefined.exp: Handle 35734 `mips64*-*-*-gnuabi64' targets. 35735 * testsuite/ld-mips-elf/attr-gnu-4-10.d: Likewise. 35736 * testsuite/ld-mips-elf/compact-eh6.d: Likewise. 35737 * testsuite/ld-mips-elf/mips-elf.exp: Handle `*-*-*-gnuabi64' 35738 targets. 35739 357402023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35741 35742 MIPS/GAS/testsuite: Fix n64 compact EH failures 35743 Expect a `.MIPS.options' section alternatively to `.reginfo' and ignore 35744 contents of either as irrelevant for all the affected compact EH tests, 35745 removing these regressions: 35746 35747 mips64-openbsd -FAIL: Compact EH EB #1 with personality ID and FDE data 35748 mips64-openbsd -FAIL: Compact EH EB #2 with personality routine and FDE data 35749 mips64-openbsd -FAIL: Compact EH EB #3 with personality id and large FDE data 35750 mips64-openbsd -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA 35751 mips64-openbsd -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA 35752 mips64-openbsd -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data 35753 mips64-openbsd -FAIL: Compact EH EL #1 with personality ID and FDE data 35754 mips64-openbsd -FAIL: Compact EH EL #2 with personality routine and FDE data 35755 mips64-openbsd -FAIL: Compact EH EL #3 with personality id and large FDE data 35756 mips64-openbsd -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA 35757 mips64-openbsd -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA 35758 mips64-openbsd -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data 35759 mips64el-openbsd -FAIL: Compact EH EB #1 with personality ID and FDE data 35760 mips64el-openbsd -FAIL: Compact EH EB #2 with personality routine and FDE data 35761 mips64el-openbsd -FAIL: Compact EH EB #3 with personality id and large FDE data 35762 mips64el-openbsd -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA 35763 mips64el-openbsd -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA 35764 mips64el-openbsd -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data 35765 mips64el-openbsd -FAIL: Compact EH EL #1 with personality ID and FDE data 35766 mips64el-openbsd -FAIL: Compact EH EL #2 with personality routine and FDE data 35767 mips64el-openbsd -FAIL: Compact EH EL #3 with personality id and large FDE data 35768 mips64el-openbsd -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA 35769 mips64el-openbsd -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA 35770 mips64el-openbsd -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data 35771 35772 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 35773 35774 gas/ 35775 * testsuite/gas/mips/compact-eh-eb-1.d: Accept `.MIPS.options' 35776 section as an alternative to `.reginfo' and ignore contents of 35777 either. 35778 * testsuite/gas/mips/compact-eh-eb-2.d: Likewise. 35779 * testsuite/gas/mips/compact-eh-eb-3.d: Likewise. 35780 * testsuite/gas/mips/compact-eh-eb-4.d: Likewise. 35781 * testsuite/gas/mips/compact-eh-eb-5.d: Likewise. 35782 * testsuite/gas/mips/compact-eh-eb-6.d: Likewise. 35783 * testsuite/gas/mips/compact-eh-el-1.d: Likewise. 35784 * testsuite/gas/mips/compact-eh-el-2.d: Likewise. 35785 * testsuite/gas/mips/compact-eh-el-3.d: Likewise. 35786 * testsuite/gas/mips/compact-eh-el-4.d: Likewise. 35787 * testsuite/gas/mips/compact-eh-el-5.d: Likewise. 35788 * testsuite/gas/mips/compact-eh-el-6.d: Likewise. 35789 357902023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35791 35792 testsuite: Handle composed R_MIPS_NONE relocations 35793 MIPS n64 ABI has a peculiarity where all relocations are composed of 35794 three, with subsequent relocation types set to R_MIPS_NONE if further 35795 calculation is not required. Example output produced by `readelf' and 35796 `objdump' for such relocations is: 35797 35798 Offset Info Type Sym. Value Sym. Name + Addend 35799 000000000000 000800000002 R_MIPS_32 0000000000000000 foo + 0 35800 Type2: R_MIPS_NONE 35801 Type3: R_MIPS_NONE 35802 35803 and: 35804 35805 OFFSET TYPE VALUE 35806 0000000000000000 R_MIPS_32 foo 35807 0000000000000000 R_MIPS_NONE *ABS* 35808 0000000000000000 R_MIPS_NONE *ABS* 35809 35810 respectively. The presence of these extra R_MIPS_NONE entries is not 35811 relevant for generic or even some MIPS tests, so optionally match them 35812 with the respective dump patterns, also discarding `xfail' annotation 35813 for MIPS/OpenBSD targets from gas/elf/missing-build-notes.d, removing 35814 these regressions: 35815 35816 mips64-openbsd -FAIL: readelf -r bintest 35817 mips64-openbsd -FAIL: forward expression 35818 mips64-openbsd -FAIL: assignment tests 35819 mips64-openbsd -FAIL: gas/all/none 35820 mips64-openbsd -XFAIL: gas/elf/missing-build-notes 35821 mips64-openbsd -FAIL: macro test 2 35822 mips64-openbsd -FAIL: macro irp 35823 mips64-openbsd -FAIL: macro rept 35824 mips64-openbsd -FAIL: nested irp/irpc/rept 35825 mips64-openbsd -FAIL: macro vararg 35826 mips64-openbsd -FAIL: mips jalx 35827 mips64-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue 35828 mips64el-openbsd -FAIL: readelf -r bintest 35829 mips64el-openbsd -FAIL: forward expression 35830 mips64el-openbsd -FAIL: assignment tests 35831 mips64el-openbsd -FAIL: gas/all/none 35832 mips64el-openbsd -XFAIL: gas/elf/missing-build-notes 35833 mips64el-openbsd -FAIL: macro test 2 35834 mips64el-openbsd -FAIL: macro irp 35835 mips64el-openbsd -FAIL: macro rept 35836 mips64el-openbsd -FAIL: nested irp/irpc/rept 35837 mips64el-openbsd -FAIL: macro vararg 35838 mips64el-openbsd -FAIL: mips jalx 35839 mips64el-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue 35840 35841 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 35842 35843 binutils/ 35844 * testsuite/binutils-all/readelf.r-64: Optionally match extra 35845 R_MIPS_NONE pairs. 35846 35847 gas/ 35848 * testsuite/gas/all/assign.d: Optionally match extra 35849 R_MIPS_NONE pairs. 35850 * testsuite/gas/all/fwdexp.d: Likewise. 35851 * testsuite/gas/all/none.d: Likewise. 35852 * testsuite/gas/macros/irp.d: Likewise. 35853 * testsuite/gas/macros/repeat.d: Likewise. 35854 * testsuite/gas/macros/rept.d: Likewise. 35855 * testsuite/gas/macros/test2.d: Likewise. 35856 * testsuite/gas/macros/vararg.d: Likewise. 35857 * testsuite/gas/mips/compact-eh-eb-1.d: Likewise. 35858 * testsuite/gas/mips/compact-eh-eb-2.d: Likewise. 35859 * testsuite/gas/mips/compact-eh-eb-3.d: Likewise. 35860 * testsuite/gas/mips/compact-eh-eb-4.d: Likewise. 35861 * testsuite/gas/mips/compact-eh-eb-5.d: Likewise. 35862 * testsuite/gas/mips/compact-eh-eb-6.d: Likewise. 35863 * testsuite/gas/mips/compact-eh-el-1.d: Likewise. 35864 * testsuite/gas/mips/compact-eh-el-2.d: Likewise. 35865 * testsuite/gas/mips/compact-eh-el-3.d: Likewise. 35866 * testsuite/gas/mips/compact-eh-el-4.d: Likewise. 35867 * testsuite/gas/mips/compact-eh-el-5.d: Likewise. 35868 * testsuite/gas/mips/compact-eh-el-6.d: Likewise. 35869 * testsuite/gas/mips/loongson-2f-3.d: Likewise. 35870 * testsuite/gas/mips/mips-jalx.d: Likewise. 35871 * testsuite/gas/elf/missing-build-notes.d: Likewise. Remove 35872 the `xfail' tag. 35873 35874 ld/ 35875 * testsuite/ld-mips-elf/reloc-estimate-1.d: Optionally match 35876 extra R_MIPS_NONE pairs. 35877 358782023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35879 35880 MIPS/testsuite: Handle 64-bit addresses 35881 Several MIPS test cases are suitable for the n64 ABI if not for the 35882 extra leading zeros or spaces in addresses not handled by dump patterns. 35883 Match the characters then, removing these regressions: 35884 35885 mips64-openbsd -FAIL: .set arch=FOO 35886 mips64-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue 35887 mips64-openbsd -FAIL: MIPS DSP ASE for MIPS64 35888 mips64-openbsd -FAIL: gas/mips/align2 35889 mips64-openbsd -FAIL: gas/mips/align2-el 35890 mips64-openbsd -FAIL: Locally-resolvable PC-relative code references 35891 mips64-openbsd -FAIL: MIPS jalx-1 35892 mips64-openbsd -FAIL: JAL overflow 2 35893 mips64el-openbsd -FAIL: .set arch=FOO 35894 mips64el-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue 35895 mips64el-openbsd -FAIL: MIPS DSP ASE for MIPS64 35896 mips64el-openbsd -FAIL: gas/mips/align2 35897 mips64el-openbsd -FAIL: gas/mips/align2-el 35898 mips64el-openbsd -FAIL: Locally-resolvable PC-relative code references 35899 mips64el-openbsd -FAIL: MIPS jalx-1 35900 mips64el-openbsd -FAIL: JAL overflow 2 35901 35902 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 35903 35904 gas/ 35905 * testsuite/gas/mips/align2-el.d: Match extra leading zeros 35906 with addresses. 35907 * testsuite/gas/mips/align2.d: Likewise. 35908 * testsuite/gas/mips/compact-eh-eb-1.d: Likewise. 35909 * testsuite/gas/mips/compact-eh-eb-2.d: Likewise. 35910 * testsuite/gas/mips/compact-eh-eb-3.d: Likewise. 35911 * testsuite/gas/mips/compact-eh-eb-4.d: Likewise. 35912 * testsuite/gas/mips/compact-eh-eb-5.d: Likewise. 35913 * testsuite/gas/mips/compact-eh-eb-6.d: Likewise. 35914 * testsuite/gas/mips/compact-eh-el-1.d: Likewise. 35915 * testsuite/gas/mips/compact-eh-el-2.d: Likewise. 35916 * testsuite/gas/mips/compact-eh-el-3.d: Likewise. 35917 * testsuite/gas/mips/compact-eh-el-4.d: Likewise. 35918 * testsuite/gas/mips/compact-eh-el-5.d: Likewise. 35919 * testsuite/gas/mips/compact-eh-el-6.d: Likewise. 35920 * testsuite/gas/mips/loongson-2f-2.d: Likewise. 35921 * testsuite/gas/mips/loongson-2f-3.d: Likewise. 35922 * testsuite/gas/mips/mips-jalx.d: Likewise. 35923 * testsuite/gas/mips/mips64-dsp.d: Likewise. 35924 * testsuite/gas/mips/pcrel-1.d: Likewise. 35925 * testsuite/gas/mips/set-arch.d: Likewise. 35926 35927 ld/ 35928 * testsuite/ld-mips-elf/jaloverflow-2.d: Match extra leading 35929 zeros and spaces with addresses as appropriate. 35930 * testsuite/ld-mips-elf/jalx-1.d: Likewise. 35931 * testsuite/ld-mips-elf/reloc-estimate-1.d: Likewise. 35932 359332023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35934 35935 testsuite: Also discard the `.MIPS.options' section 35936 Also discard the `.MIPS.options' section, used with n64 MIPS binaries, 35937 along with similar other MIPS sections (`.reginfo', `.MIPS.abiflags') 35938 not relevant for the test cases concerned, fixing these regressions: 35939 35940 mips64-openbsd -FAIL: ld-elf/group3a 35941 mips64-openbsd -FAIL: ld-elf/group3b 35942 mips64-openbsd -FAIL: Place orphan sections (map file check) 35943 mips64-openbsd -FAIL: ld-elf/orphan-region 35944 mips64-openbsd -FAIL: ld-elf/orphan 35945 mips64-openbsd -FAIL: overlay size (map file check) 35946 mips64-openbsd -FAIL: overlay size 35947 mips64el-openbsd -FAIL: ld-elf/group3a 35948 mips64el-openbsd -FAIL: ld-elf/group3b 35949 mips64el-openbsd -FAIL: Place orphan sections (map file check) 35950 mips64el-openbsd -FAIL: ld-elf/orphan-region 35951 mips64el-openbsd -FAIL: ld-elf/orphan 35952 mips64el-openbsd -FAIL: overlay size (map file check) 35953 mips64el-openbsd -FAIL: overlay size 35954 35955 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 35956 35957 binutils/ 35958 * testsuite/binutils-all/strip-3.d: Add `-R .MIPS.options' to 35959 the `strip' tag. 35960 35961 ld/ 35962 * testsuite/ld-elf/group.ld: Also discard `.MIPS.options'. 35963 * testsuite/ld-elf/orphan-region.ld: Likewise. 35964 * testsuite/ld-elf/orphan.ld: Likewise. 35965 * testsuite/ld-mips-elf/got-page-1.ld: Likewise. 35966 * testsuite/ld-scripts/overlay-size.t: Likewise. 35967 359682023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 35969 35970 MIPS/LD/testsuite: Fix MIPS16 interlinking test IRIX 6 regressions 35971 IRIX 6 does not have MIPS16 stub section support in its n32 linker 35972 scripts, causing such input sections to be propagated to the respective 35973 output sections rather than `.text', causing dump pattern mismatches. 35974 35975 Expect IRIX 6 to fail with n32 testing then, removing this regression: 35976 35977 mips-sgi-irix6 -FAIL: MIPS16 interlinking for local functions 1 (n32) 35978 35979 We may choose to update IRIX 6 n32 linker scripts sometime, as it seems 35980 a harmless change. 35981 35982 ld/ 35983 * testsuite/ld-mips-elf/mips-elf.exp: Expect IRIX 6 to fail with 35984 n32 `mips16-local-stubs-1' testing. 35985 359862023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 35987 35988 MIPS/LD/testsuite: Fix MIPS16 interlinking test n64 regressions 35989 The MIPS16 interlinking test for local functions expects to be assembled 35990 with 32-bit addressing, otherwise causing assembly warnings: 35991 35992 .../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s: Assembler messages: 35993 .../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s:16: Warning: la used to load 64-bit address; recommend using dla instead 35994 35995 Use the per-ABI framework then to run the test explicitly for o32 and 35996 n32 ABIs only, replacing the `-mips4' option from the `as' tag with 35997 `.module mips4' pseudo-op within the source itself so as to avoid 35998 assembly errors: 35999 36000 Assembler messages: 36001 Error: -mips4 conflicts with the other architecture options, which imply -mips3 36002 36003 with n32 testing for some targets, and ultimately removing these 36004 regressions: 36005 36006 mips64-openbsd -FAIL: MIPS16 interlinking for local functions 1 36007 mips64el-openbsd -FAIL: MIPS16 interlinking for local functions 1 36008 36009 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 36010 36011 ld/ 36012 * testsuite/ld-mips-elf/mips16-local-stubs-1.d: Remove `-mips4' 36013 from the `as' tag. 36014 * testsuite/ld-mips-elf/mips16-local-stubs-1.s: Add `.module 36015 mips4'. 36016 * testsuite/ld-mips-elf/mips-elf.exp: Run `mips16-local-stubs-1' 36017 for o32 and n32 ABIs only. 36018 360192023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 36020 36021 MIPS/GAS/testsuite: Force o32 for tests expecting 32-bit addressing 36022 A few GAS tests expect to be assembled with 32-bit addressing, otherwise 36023 causing an assembly warning: 36024 36025 .../gas/testsuite/gas/mips/fix-rm7000-2.s:11: Warning: la used to load 64-bit address; recommend using dla instead 36026 36027 or pattern dump mismatches against 32-bit address calculations, however 36028 these tests do not enforce their expectation in any. For none of them 36029 the specific ABI used is of any relevance however, so select the o32 ABI 36030 unconditionally, removing these failures with OpenBSD targets: 36031 36032 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (micromips) 36033 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips3) 36034 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips4) 36035 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips5) 36036 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64) 36037 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r2) 36038 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r3) 36039 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r5) 36040 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon) 36041 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon2) 36042 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon3) 36043 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeonp) 36044 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (r4000) 36045 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (sb1) 36046 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (vr5400) 36047 mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (xlr) 36048 mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2) 36049 mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3) 36050 mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp) 36051 mips64-openbsd -FAIL: Full MIPS R5900 36052 mips64-openbsd -FAIL: MIPS R5900 VU0 36053 mips64-openbsd -FAIL: Paired LL/SC for mips64r6 (mips64r6) 36054 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (micromips) 36055 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips3) 36056 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips4) 36057 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips5) 36058 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64) 36059 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r2) 36060 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r3) 36061 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r5) 36062 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon) 36063 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon2) 36064 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon3) 36065 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeonp) 36066 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (r4000) 36067 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (sb1) 36068 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (vr5400) 36069 mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (xlr) 36070 mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2) 36071 mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3) 36072 mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp) 36073 mips64el-openbsd -FAIL: Full MIPS R5900 36074 mips64el-openbsd -FAIL: MIPS R5900 VU0 36075 mips64el-openbsd -FAIL: Paired LL/SC for mips64r6 (mips64r6) 36076 36077 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 36078 36079 gas/ 36080 * testsuite/gas/mips/fix-rm7000-2.d: Add `-32' to the `as' tag. 36081 * testsuite/gas/mips/micromips@fix-rm7000-2.d: Likewise. 36082 * testsuite/gas/mips/r5900-full.d: Likewise. 36083 * testsuite/gas/mips/r5900-vu0.d: Likewise. 36084 * testsuite/gas/mips/llpscp-64.d: Add `as' tag with `-32'. 36085 * testsuite/gas/mips/octeon-saa-saad.d: Likewise. 36086 360872023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36088 36089 MIPS/LD/testsuite: Run `got-dump-1' for o32/n32 ABIs 36090 The `got-dump-1' test case uses 32-bit addressing, so it makes no sense 36091 to run it with the n64 ABI. And there is a corresponding `got-dump-2' 36092 test already for the n64 ABI. 36093 36094 Use the per-ABI framework then to run the `got-dump-1' test explicitly 36095 for o32 and n32 ABIs only. 36096 36097 ld/ 36098 * testsuite/ld-mips-elf/mips-elf.exp: Run `got-dump-1' for o32 36099 and n32 ABIs only. 36100 361012023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36102 36103 MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with OpenBSD targets 36104 OpenBSD targets produce ELF64 files while the pattern dump expects ELF32 36105 output and specific header sizes. Disable it for `mips64*-*-openbsd*' 36106 for these targets then, removing these failures: 36107 36108 mips64-openbsd -FAIL: ld-mips-elf/attr-gnu-4-10 36109 mips64el-openbsd -FAIL: ld-mips-elf/attr-gnu-4-10 36110 36111 ld/ 36112 * testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `notarget' tag with 36113 `mips64*-*-openbsd*'. 36114 361152023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36116 36117 MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with IRIX targets 36118 IRIX targets do not enable the production of a `.pdr' section in GAS by 36119 default, which causes a failure with the `attr-gnu-4-10' test case due 36120 to a difference resulting in the number and indices of sections produced 36121 in linker output. 36122 36123 As the presence or absence of this section is not relevant to this test 36124 case, just enable it unconditionally, fixing these regressions: 36125 36126 mips-sgi-irix5 -FAIL: ld-mips-elf/attr-gnu-4-10 36127 mips-sgi-irix6 -FAIL: ld-mips-elf/attr-gnu-4-10 36128 36129 ld/ 36130 * testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `as' tag with 36131 `-mpdr'. 36132 361332023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36134 36135 MIPS/LD/testsuite: Fix JALR relaxation test failure with IRIX 6 36136 The `mips-sgi-irix6' target only supports IRIX linker emulations, but 36137 most JALR relaxation tests request the relevant traditional emulation 36138 instead, causing a link failure: 36139 36140 ./ld-new: unrecognised emulation mode: elf32btsmipn32 36141 Supported emulations: elf32bmipn32 elf32bsmip elf64bmip 36142 36143 This is clearly an omission from the conversion to use the per-ABI 36144 framework made with commit 78da84f99405 ("MIPS/LD/testsuite: Correct 36145 mips-elf.exp test ABI/emul/endian arrangement"). These tests are also 36146 endianness agnostic, which was missed in the conversion as well. 36147 36148 Remove the unnecessary explicit ABI and endianness options then and rely 36149 on the per-ABI framework to get things right, removing this regression: 36150 36151 mips-sgi-irix6 -FAIL: MIPS relax-jalr-shared n32 36152 36153 ld/ 36154 * testsuite/ld-mips-elf/relax-jalr-n32-shared.d: Remove flags 36155 related to ABI and endianness selection from the `as' and `ld' 36156 tags. 36157 * testsuite/ld-mips-elf/relax-jalr-n64.d: Likewise. 36158 * testsuite/ld-mips-elf/relax-jalr-n64-shared.d: Likewise. 36159 * testsuite/ld-mips-elf/mips-elf.exp: Remove `as' and `ld' tag 36160 additions from the invocation of JALR relaxation tests. 36161 361622023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36163 36164 MIPS/LD/testsuite: Fix unaligned JALX failures with OpenBSD targets 36165 There are only n64 linker emulations included with `mips64*-*-openbsd*' 36166 targets, however the unaligned JALX tests insist on running across all 36167 targets and force the n32 ABI, causing link errors with the targets 36168 concerned, e.g.: 36169 36170 ./ld-new: tmpdir/unaligned-jalx-0.o: ABI is incompatible with that of the selected emulation 36171 ./ld-new: failed to merge target specific data of file tmpdir/unaligned-jalx-0.o 36172 ./ld-new: tmpdir/unaligned-insn.o: ABI is incompatible with that of the selected emulation 36173 ./ld-new: failed to merge target specific data of file tmpdir/unaligned-insn.o 36174 36175 Convert the tests then to use the per-ABI framework and run them for the 36176 o32 and n32 ABIs, removing these regressions: 36177 36178 mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 0 36179 mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 1 36180 mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 2 36181 mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 3 36182 mips64-openbsd -FAIL: MIPS16 JALX to unaligned symbol 0 36183 mips64-openbsd -FAIL: MIPS16 JALX to unaligned symbol 1 36184 mips64-openbsd -FAIL: microMIPS JALX to unaligned symbol 0 36185 mips64-openbsd -FAIL: microMIPS JALX to unaligned symbol 1 36186 mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 0 36187 mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 1 36188 mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 2 36189 mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 3 36190 mips64el-openbsd -FAIL: MIPS16 JALX to unaligned symbol 0 36191 mips64el-openbsd -FAIL: MIPS16 JALX to unaligned symbol 1 36192 mips64el-openbsd -FAIL: microMIPS JALX to unaligned symbol 0 36193 mips64el-openbsd -FAIL: microMIPS JALX to unaligned symbol 1 36194 36195 Similar tests for the n64 ABI can be added separately, using suitable 36196 dump patterns. 36197 36198 ld/ 36199 * testsuite/ld-mips-elf/unaligned-jalx-0.d: Remove `-32' from 36200 the `as' tag. 36201 * testsuite/ld-mips-elf/unaligned-jalx-1.d: Likewise. 36202 * testsuite/ld-mips-elf/unaligned-jalx-2.d: Likewise. 36203 * testsuite/ld-mips-elf/unaligned-jalx-3.d: Likewise. 36204 * testsuite/ld-mips-elf/unaligned-jalx-mips16-0.d: Likewise. 36205 * testsuite/ld-mips-elf/unaligned-jalx-mips16-1.d: Likewise. 36206 * testsuite/ld-mips-elf/unaligned-jalx-micromips-0.d: Likewise. 36207 * testsuite/ld-mips-elf/unaligned-jalx-micromips-1.d: Likewise. 36208 * testsuite/ld-mips-elf/mips-elf.exp: Run unaligned JALX tests 36209 with `run_dump_test_o32' and `run_dump_test_n32' rather than 36210 `run_dump_test'. 36211 362122023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36213 36214 MIPS/GAS/testsuite: Disable compact EH #7 tests with OpenBSD targets 36215 Compact EH #7 tests use output templates that are not suitable for the 36216 n64 ABI, which `mips64*-*-openbsd*' targets use by default, because the 36217 contents of the sections examined are expected to be differnt. Disable 36218 the tests then, removing these regressions: 36219 36220 mips64-openbsd -FAIL: Compact EH EB #7 with personality id and fallback FDE 36221 mips64-openbsd -FAIL: Compact EH EL #7 with personality id and fallback FDE 36222 mips64el-openbsd -FAIL: Compact EH EB #7 with personality id and fallback FDE 36223 mips64el-openbsd -FAIL: Compact EH EL #7 with personality id and fallback FDE 36224 36225 Suitable corresponding tests for the n64 ABI can be added separately. 36226 36227 gas/ 36228 * testsuite/gas/mips/compact-eh-eb-7.d: Exclude for 36229 `mips64*-*-openbsd*'. 36230 * testsuite/gas/mips/compact-eh-el-7.d: Likewise. 36231 362322023-07-28 YunQiang Su <yunqiang.su@cipunited.com> 36233 36234 MIPS/LD: Include n64 `.interp' with INITIAL_READONLY_SECTIONS 36235 In ld/emulparams/elf64bmip-defs.sh there is no explicit handling of the 36236 `.interp' section, which causes it to be positioned in output at an odd 36237 place. 36238 36239 Let's include it with INITIAL_READONLY_SECTIONS, just like o32/n32 do, 36240 fixing a regression from commit 5a8e7be242f3 ("INITIAL_READONLY_SECTIONS 36241 in elf.sc"), where the handling of n64 was missed due to an unfortunate 36242 sequence of events where ld/emulparams/elf64bmip-defs.sh was only added 36243 with commit 94bb04b3c611 ("Use .reginfo rather than .MIPS.options in n32 36244 linker scripts") the day before. 36245 36246 Add test cases covering section ordering across the three ABIs. This 36247 change also fixes ld/pr23658-2: 36248 36249 FAIL: Build pr23658-2 36250 36251 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 36252 36253 ld/ChangeLog: 36254 * emulparams/elf64bmip-defs.sh: Include `.interp' with 36255 INITIAL_READONLY_SECTIONS. 36256 * testsuite/ld-mips-elf/pie-n64.d: Adjust addresses. 36257 * testsuite/ld-mips-elf/sections-1-o32.rd: New test. 36258 * testsuite/ld-mips-elf/sections-1-o32t.rd: New test. 36259 * testsuite/ld-mips-elf/sections-1-n32.rd: New test. 36260 * testsuite/ld-mips-elf/sections-1-n32t.rd: New test. 36261 * testsuite/ld-mips-elf/sections-1-n32p.rd: New test. 36262 * testsuite/ld-mips-elf/sections-1-n64.rd: New test. 36263 * testsuite/ld-mips-elf/sections-1-n64t.rd: New test. 36264 * testsuite/ld-mips-elf/sections-2-o32.rd: New test. 36265 * testsuite/ld-mips-elf/sections-2-o32t.rd: New test. 36266 * testsuite/ld-mips-elf/sections-2-n32.rd: New test. 36267 * testsuite/ld-mips-elf/sections-2-n32t.rd: New test. 36268 * testsuite/ld-mips-elf/sections-2-n32p.rd: New test. 36269 * testsuite/ld-mips-elf/sections-2-n64.rd: New test. 36270 * testsuite/ld-mips-elf/sections-2-n64t.rd: New test. 36271 * testsuite/ld-mips-elf/sections.s: New test source. 36272 * testsuite/ld-mips-elf/mips-elf.exp: Run the new tests. 36273 362742023-07-28 Maciej W. Rozycki <macro@orcam.me.uk> 36275 36276 Revert "MIPS: support mips*64 as CPU and gnuabi64 as ABI" 36277 This reverts commit 32f1c80375ebe8ad25d9805ee5889f0006c51e59. It had 36278 two unrelated changes lumped together, one of which changed the meaning 36279 of the `mipsisa64*-*-linux*' target triplets, which was not properly 36280 evaluated. 36281 362822023-07-28 Alan Modra <amodra@gmail.com> 36283 36284 ldscripts/empty-address vs. xcoff 36285 The empty-address tests check that if a section is removed by ld due 36286 to being empty then properties of that section don't affect following 36287 addresses. The xcoff backend doesn't remove the empty .data section 36288 created by empty-address-2* and empty-address-3* for some reason, and 36289 therefore fails the test. 36290 36291 * testsuite/ld-scripts/empty-address-1.d: Accept more symbols. 36292 * testsuite/ld-scripts/empty-address-2a.d: xfail for xcoff. 36293 * testsuite/ld-scripts/empty-address-2b.d: Likewise. 36294 * testsuite/ld-scripts/empty-address-3a.d: Likewise. 36295 * testsuite/ld-scripts/empty-address-3b.d: Likewise. 36296 362972023-07-28 Alan Modra <amodra@gmail.com> 36298 36299 Fix recent x86 pe/coff testsuite regressions 36300 * testsuite/gas/i386/sha512-intel.d: Accept section nop padding. 36301 * testsuite/gas/i386/sha512.d: Likewise. 36302 * testsuite/gas/i386/sm3-intel.d: Likewise. 36303 * testsuite/gas/i386/sm3.d: Likewise. 36304 * testsuite/gas/i386/x86-64-pbndkb-intel.d: Likewise. 36305 * testsuite/gas/i386/x86-64-pbndkb.d: Likewise. 36306 * testsuite/gas/i386/x86-64-sha512-intel.d: Likewise. 36307 * testsuite/gas/i386/x86-64-sha512.d: Likewise. 36308 * testsuite/gas/i386/x86-64-sm3-intel.d: Likewise. 36309 * testsuite/gas/i386/x86-64-sm3.d: Likewise. 36310 363112023-07-28 Alan Modra <amodra@gmail.com> 36312 36313 coff/pe/xcoff and --extract-symbols 36314 This fixes failure of the "extract symbols" test for rs6000, where 36315 --extract-symbols generates a non-zero sized .text. By the look of 36316 coffcode.h the same problem might occur for coff/pe too, but doesn't 36317 happen to trigger a test failure. 36318 36319 bfd/ 36320 * coffcode.h (coff_compute_section_file_positions): Don't 36321 adjust size of !SEC_LOAD sections. 36322 binutils/ 36323 * objcopy.c (setup_section): Clear SEC_LOAD for --extract-symbol. 36324 363252023-07-28 Tsukasa OI <research_trasio@irq.a4lg.com> 36326 36327 RISC-V: Add actual 'Zvkt' extension support 36328 The 'Zvkt' extension is listed on the added extensions in the GNU Binutils 36329 version 2.41 (see binutils/NEWS). However, the support of this extension 36330 was actually missing. 36331 36332 This commit adds actual support of this extension and adds implications 36333 from 'Zvkn' and 'Zvks' superset extensions. 36334 36335 bfd/ChangeLog: 36336 36337 * elfxx-riscv.c (riscv_implicit_subsets) Add implications from 36338 'Zvkn' and 'Zvks'. (riscv_supported_std_z_ext): Add 'Zvkt' to 36339 the supported extension list. 36340 363412023-07-28 Tsukasa OI <research_trasio@irq.a4lg.com> 36342 36343 Fix typo in riscv-dis.c comment 36344 Don't go "past" the start of the section. 36345 363462023-07-28 GDB Administrator <gdbadmin@sourceware.org> 36347 36348 Automatic date update in version.in 36349 363502023-07-27 Simon Marchi <simon.marchi@polymtl.ca> 36351 36352 gdb: remove trailing empty line in target-delegates.c 36353 In a review [1], I pointed out that applying the patch, git would say: 36354 36355 .git/rebase-apply/patch:147: new blank line at EOF. 36356 36357 However, since the empty line is in target-delegates.c (a generated 36358 file), there's nothing the author can do about it. To avoid this 36359 comment coming up again in the future, change make-target-delegates.py 36360 to avoid the trailing empty line. Do this by making it output empty 36361 lines before each entity, not after. 36362 36363 Since this needs removing a newline output in gdbcopyright, adjust 36364 ada-unicode.py and gdbarch.py to avoid changes in the files they 36365 generate. 36366 36367 [1] https://inbox.sourceware.org/gdb-patches/20230427210113.45380-1-jhb@FreeBSD.org/T/#m083598405bef19157f67c9d97846d3dd90dc7d1c 36368 36369 Change-Id: Ic4c648f06443b432168cb76603402c918aa6e5d2 36370 Approved-By: Tom Tromey <tom@tromey.com> 36371 363722023-07-27 Tom Tromey <tromey@adacore.com> 36373 36374 Report supportsBreakpointLocationsRequest 36375 While looking at the DAP spec, I noticed that the breakpointLocations 36376 request is gated behind a capability. This patch changes gdb to 36377 report this capability. 36378 36379 I've also added a comment to explain the fact that arguments to 36380 breakpointLocations are not optional, even though the spec says they 36381 are. 36382 363832023-07-27 Alan Modra <amodra@gmail.com> 36384 36385 /DISCARD/ in ld testsuite 36386 The canonical form to discard all sections not mentioned earlier in 36387 the script is 36388 /DISCARD/ : { *(*) } 36389 not 36390 /DISCARD/ : { *(.*) } 36391 ".*" happens to work with the usual section names starting with a dot, 36392 but let's not promote something not quite right. 36393 363942023-07-27 Alan Modra <amodra@gmail.com> 36395 36396 sh: uninitialised sh_operand_info.type in get_specific 36397 Seen when running gas/testsuite/gas/sh/err-at.s 36398 36399 * config/tc-sh.c (get_operands): Always init operand type. 36400 * testsuite/gas/sh/err-at.s: Expect unnecessary extra errors. 36401 364022023-07-27 Hu, Lin1 <lin1.hu@intel.com> 36403 36404 Support Intel PBNDKB 36405 gas/ChangeLog: 36406 36407 * NEWS: Support Intel PBNDKB. 36408 * config/tc-i386.c: Add pbndkb. 36409 * doc/c-i386.texi: Document .pbndkb. 36410 * testsuite/gas/i386/i386.exp: Add PBNDKB tests. 36411 * testsuite/gas/i386/x86-64.exp: Ditto. 36412 * testsuite/gas/i386/pbndkb-inval.l: New test. 36413 * testsuite/gas/i386/pbndkb-inval.s: Ditto. 36414 * testsuite/gas/i386/x86-64-pbndkb-intel.d: Ditto. 36415 * testsuite/gas/i386/x86-64-pbndkb.d: Ditto. 36416 * testsuite/gas/i386/x86-64-pbndkb.s: Ditto. 36417 36418 opcodes/ChangeLog: 36419 36420 * i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_7): New. 36421 (X86_64_0F01_REG_0_MOD_3_RM_7_P_0): Ditto. 36422 (prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_7. 36423 (x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_7_P_0. 36424 (rm_table): New entry for pbndkb. 36425 * i386-gen.c (cpu_flag): Add PBNDKB. 36426 * i386-init.h: Regenerated. 36427 * i386-mnem.h: Ditto. 36428 * i386-opc.h (CpuPBNDKB): New. 36429 (i386_cpu_flags): Add cpupbndkb. 36430 * i386-opc.tbl: Add PBNDKB instructions. 36431 * i386-tbl.h: Regenerated. 36432 364332023-07-27 Haochen Jiang <haochen.jiang@intel.com> 36434 36435 Support Intel SM4 36436 gas/ChangeLog: 36437 36438 * NEWS: Support Intel SM4. 36439 * config/tc-i386.c: Add sm4. 36440 * doc/c-i386.texi: Document .sm4. 36441 * testsuite/gas/i386/i386.exp: Run SM4 tests. 36442 * testsuite/gas/i386/x86-64.exp: Ditto. 36443 * testsuite/gas/i386/sm4-intel.d: Add SM4 tests. 36444 * testsuite/gas/i386/sm4.d: Ditto. 36445 * testsuite/gas/i386/sm4.s: Ditto. 36446 * testsuite/gas/i386/x86-64-sm4-intel.d: Ditto. 36447 * testsuite/gas/i386/x86-64-sm4.d: Ditto. 36448 * testsuite/gas/i386/x86-64-sm4.s: Ditto. 36449 36450 opcodes/ChangeLog: 36451 36452 * i386-dis.c (prefix_table): Add SM4 instructions. 36453 * i386-gen.c (isa_dependencies): Add SM4. 36454 (cpu_flags): Ditto. 36455 * i386-init.h: Regenerated. 36456 * i386-mnem.h: Ditto. 36457 * i386-opc.h (CpuSM4): New. 36458 (i386_cpu_flags): Add cpusm4. 36459 * i386-opc.tbl: Add SM4 instructions. 36460 * i386-tbl.h: Regenerated. 36461 364622023-07-27 Haochen Jiang <haochen.jiang@intel.com> 36463 36464 Support Intel SM3 36465 gas/ChangeLog: 36466 36467 * NEWS: Support Intel SM3. 36468 * config/tc-i386.c: Add sm3. 36469 * doc/c-i386.texi: Document .sm3. 36470 * testsuite/gas/i386/i386.exp: Run sm3 tests. 36471 * testsuite/gas/i386/x86-64.exp: Ditto. 36472 * testsuite/gas/i386/sm3-intel.d: New test. 36473 * testsuite/gas/i386/sm3.d: Ditto. 36474 * testsuite/gas/i386/sm3.s: Ditto. 36475 * testsuite/gas/i386/x86-64-sm3-intel.d: Ditto. 36476 * testsuite/gas/i386/x86-64-sm3.d: Ditto. 36477 * testsuite/gas/i386/x86-64-sm3.s: Ditto. 36478 36479 opcodes/ChangeLog: 36480 36481 * i386-dis.c (PREFIX_VEX_0F38DA_W_0): New. 36482 (VEX_LEN_0F38DA_W_0_P_0): Ditto. 36483 (VEX_LEN_0F38DA_W_0_P_2): Ditto. 36484 (VEX_LEN_0F3ADE_W_0): Ditto. 36485 (VEX_W_0F38DA): Ditto. 36486 (VEX_W_0F3ADE): Ditto. 36487 (prefix_table): Add PREFIX_VEX_0F38DA_W_0. 36488 (vex_len_table): Add VEX_LEN_0F38DA_W_0_P_0, 36489 VEX_LEN_0F38DA_W_0_P_2, VEX_LEN_0F3ADE_W_0. 36490 (vex_w_table): Add VEX_W_0F38DA, VEX_W_0F3ADE. 36491 * i386-gen.c (isa_dependencies): Add SM3. 36492 (cpu_flags): Ditto. 36493 * i386-init.h: Regenerated. 36494 * i386-mnem.h: Ditto. 36495 * i386-opc.h (CpuSM3): New. 36496 (i386_cpu_flags): Add cpusm3. 36497 * i386-opc.tbl: Add SM3 instructions. 36498 * i386-tbl.h: Regenerated. 36499 365002023-07-27 Haochen Jiang <haochen.jiang@intel.com> 36501 36502 Support Intel SHA512 36503 gas/ChangeLog: 36504 36505 * NEWS: Support Intel SHA512. 36506 * config/tc-i386.c: Add sha512. 36507 * doc/c-i386.texi: Document .sha512. 36508 * testsuite/gas/i386/disassem.d: Add SHA512 tests. 36509 * testsuite/gas/i386/disassem.s: Ditto. 36510 * testsuite/gas/i386/i386.exp: Run SHA512 tests. 36511 * testsuite/gas/i386/x86-64.exp: Ditto. 36512 * testsuite/gas/i386/sha512-intel.d: New test. 36513 * testsuite/gas/i386/sha512-inval.l: Ditto. 36514 * testsuite/gas/i386/sha512-inval.s: Ditto. 36515 * testsuite/gas/i386/sha512.d: Ditto. 36516 * testsuite/gas/i386/sha512.s: Ditto. 36517 * testsuite/gas/i386/x86-64-sha512-intel.d: Ditto. 36518 * testsuite/gas/i386/x86-64-sha512-inval.l: Ditto. 36519 * testsuite/gas/i386/x86-64-sha512-inval.s: Ditto. 36520 * testsuite/gas/i386/x86-64-sha512.d: Ditto. 36521 * testsuite/gas/i386/x86-64-sha512.s: Ditto. 36522 36523 opcodes/ChangeLog: 36524 36525 * i386-dis.c (Rxmmq): New. 36526 (Rymm): Ditto. 36527 (PREFIX_VEX_0F38CB): Ditto. 36528 (PREFIX_VEX_0F38CC): Ditto. 36529 (PREFIX_VEX_0F38CD): Ditto. 36530 (VEX_LEN_0F38CB_P_3_W_0): Ditto. 36531 (VEX_LEN_0F38CC_P_3_W_0): Ditto. 36532 (VEX_LEN_0F38CD_P_3_W_0): Ditto. 36533 (VEX_W_0F38CB_P_3): Ditto. 36534 (VEX_W_0F38CC_P_3): Ditto. 36535 (VEX_W_0F38CD_P_3): Ditto. 36536 (prefix_table): Add PREFIX_VEX_0F38CB, PREFIX_VEX_0F38CC, 36537 PREFIX_VEX_0F38CD. 36538 (vex_len_table): Add VEX_LEN_0F38CB_P_3_W_0, 36539 VEX_LEN_0F38CC_P_3_W_0, VEX_LEN_0F38CD_P_3_W_0. 36540 (vex_w_table): Add VEX_W_0F38CB_P_3, VEX_W_0F38CC_P_3, VEX_W_0F38CD_P_3. 36541 * i386-gen.c (isa_dependencies): Add SHA512. 36542 (cpu_flags): Ditto. 36543 * i386-init.h: Regenerated. 36544 * i386-mnem.h: Ditto. 36545 * i386-opc.h (CpuSHA512): New. 36546 (i386_cpu_flags): Add cpusha512. 36547 * i386-opc.tbl: Add SHA512 instructions. 36548 * i386-tbl.h: Regenerated. 36549 365502023-07-27 konglin1 <lingling.kong@intel.com> 36551 36552 Support Intel AVX-VNNI-INT16 36553 gas/ChangeLog: 36554 36555 * NEWS: Support Intel AVX-VNNI-INT16. 36556 * config/tc-i386.c: Add avx_vnni_int16. 36557 * doc/c-i386.texi: Document avx_vnni_int16. 36558 * testsuite/gas/i386/i386.exp: Run AVX VNNI INT16 tests. 36559 * testsuite/gas/i386/x86-64.exp: Ditto. 36560 * testsuite/gas/i386/avx-vnni-int16-intel.d: New test. 36561 * testsuite/gas/i386/avx-vnni-int16.d: New test. 36562 * testsuite/gas/i386/avx-vnni-int16.s: New test. 36563 * testsuite/gas/i386/x86-64-avx-vnni-int16-intel.d: New test. 36564 * testsuite/gas/i386/x86-64-avx-vnni-int16.d: New test. 36565 * testsuite/gas/i386/x86-64-avx-vnni-int16.s: New test. 36566 36567 opcodes/ChangeLog: 36568 36569 * i386-dis.c (PREFIX_VEX_0F38D2_W_0): New. 36570 (PREFIX_VEX_0F38D3_W_0): Ditto. 36571 (VEX_W_0F38D2_P_0): Ditto. 36572 (VEX_W_0F38D2_P_1): Ditto. 36573 (VEX_W_0F38D2_P_2): Ditto. 36574 (VEX_W_0F38D3_P_0): Ditto. 36575 (VEX_W_0F38D3_P_1): Ditto. 36576 (VEX_W_0F38D3_P_2): Ditto. 36577 (prefix_table): Add PREFIX_VEX_0F38D2_W_0 and 36578 PREFIX_VEX_0F38D3_W_0. 36579 (vex_table): Add VEX_W_0F38D2 and VEX_W_0F38D3. 36580 (vex_w_table): Ditto. 36581 * i386-gen.c (isa_dependencies): Add AVX_VNNI_INT16. 36582 (cpu_flag): Ditto. 36583 * i386-init.h: Regenerated. 36584 * i386-mnem.h: Ditto. 36585 * i386-opc.h: (CpuAVX_VNNI_INT16): New. 36586 * i386-opc.tbl: Add Intel AVX_VNNI_INT16 instructions. 36587 * i386-tbl.h: Regenerated. 36588 365892023-07-27 GDB Administrator <gdbadmin@sourceware.org> 36590 36591 Automatic date update in version.in 36592 365932023-07-26 Tom de Vries <tdevries@suse.de> 36594 36595 [gdb/testsuite] Fix gdb.python/py-thread-exited.exp 36596 Two fixes in gdb.python/py-thread-exited.exp: 36597 - fix the copyright notice validity range (PR testsuite/30687): 36598 2022-202 -> 2022-2023, and 36599 - add missing "require allow_python_tests". 36600 36601 Tested on x86_64-linux. 36602 36603 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30687 36604 366052023-07-26 David Faust <david.faust@oracle.com> 36606 36607 bpf: accept # as an inline comment char 36608 This little patch makes the BPF assembler accept '#' as an inline 36609 comment character, which clang -S seems to use. 36610 36611 gas/ 36612 * config/tc-bpf.c (comment_chars): Add '#'. 36613 * doc/c-bpf.texi (BPF Special Characters): Add note that '#' may 36614 be used for inline comments. 36615 366162023-07-26 Tom de Vries <tdevries@suse.de> 36617 36618 [gdb/build] Fix Wstringop-truncation in coff_getfilename 36619 When building gdb with -O2 -fsanitize-threads, I ran into 36620 a Werror=stringop-truncation. 36621 36622 The problem is here in coff_getfilename in coffread.c: 36623 ... 36624 strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN); 36625 buffer[FILNMLEN] = '\0'; 36626 ... 36627 36628 The constant FILNMLEN is expected to designate the size of 36629 aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit 36630 60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW 36631 targets."). 36632 36633 Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead. 36634 36635 Likewise in xcoffread.c. 36636 36637 Tested on x86_64-linux. 36638 36639 Approved-By: Tom Tromey <tom@tromey.com> 36640 36641 PR build/30669 36642 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669 36643 366442023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36645 36646 bpf: gas: add negi and neg32i tests 36647 gas/ChangeLog: 36648 36649 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36650 36651 * testsuite/gas/bpf/alu.s: Add test for NEGI and NEG32I. 36652 * testsuite/gas/bpf/alu32.s: Likewise. 36653 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 36654 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 36655 * testsuite/gas/bpf/alu.d: Add expected results. 36656 * testsuite/gas/bpf/alu-be.d: Likewise. 36657 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 36658 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 36659 * testsuite/gas/bpf/alu32.d: Likewise. 36660 * testsuite/gas/bpf/alu32-be.d: Likewise. 36661 * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise. 36662 366632023-07-26 Tom de Vries <tdevries@suse.de> 36664 36665 [gdb/testsuite] Drop -nostdlib in gdb.dwarf2/typeddwarf.exp 36666 As reported in PR testsuite/30633, when running test-case 36667 gdb.dwarf2/typeddwarf.exp with target board native-gdbserver on Ubuntu 36668 22.04.2, we run into: 36669 ... 36670 (gdb) continue^M 36671 Continuing.^M 36672 ^M 36673 Program received signal SIGSEGV, Segmentation fault.^M 36674 0x0000000000000001 in ?? ()^M 36675 (gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main 36676 ... 36677 36678 We run into the FAIL as follows: 36679 - due to using gdbserver, we attach at the point of the first instruction, in 36680 _start 36681 - we then set a breakpoint at main 36682 - the test-case is a .s file, that has main renamed to _start in the assembly, 36683 but not in the debuginfo 36684 - setting a breakpoint at main sets the breakpoint at the same instruction 36685 we're currently stopped at 36686 - continue doesn't hit the breakpoint, and we return out of _start, which 36687 causes a sigsegv 36688 36689 Note that this is for the amd64 case (using gdb.dwarf2/typeddwarf-amd64.S). 36690 For the i386 case (using gdb.dwarf2/typeddwarf.S), setting a breakpoint in 36691 main sets it one insn after function entry, and consequently the problem does 36692 not occur. 36693 36694 The FAIL is a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie 36695 in a few test-cases"). 36696 36697 Without nopie the executable is PIE, with nopie it's static instead. 36698 36699 In the PIE case, we attach at the point of _start in the dynamic linker, and 36700 consequently we do not skip the breakpoint in main, and also don't run into 36701 the FAIL. 36702 36703 Fix this by: 36704 - removing the -nostdlib setting, and 36705 - renaming _start to main in both .S files. 36706 36707 The change to use -nostdlib and rename main to _start was originally added 36708 in commit 6edba76fe8b (submitted here: 36709 https://sourceware.org/pipermail/gdb-patches/2011-May/082657.html ) , I assume 36710 to fix the problem now fixed by using nopie. 36711 36712 Tested on x86_64-linux. 36713 36714 Reported-By: Simon Marchi <simon.marchi@efficios.com> 36715 Tested-By: Simon Marchi <simon.marchi@efficios.com> 36716 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30633 36717 367182023-07-26 Tom de Vries <tdevries@suse.de> 36719 36720 [gdb/tui] Fix secondary prompt 36721 With CLI, a session defining a command looks like: 36722 ... 36723 (gdb) define foo 36724 Type commands for definition of "foo". 36725 End with a line saying just "end". 36726 >bar 36727 >end 36728 (gdb) 36729 ... 36730 36731 With TUI however, we get the same secondary prompts, and type the same, but 36732 are left with: 36733 ... 36734 (gdb) define foo 36735 Type commands for definition of "foo". 36736 End with a line saying just "end". 36737 (gdb) 36738 ... 36739 36740 Fix this by calling tui_inject_newline_into_command_window in 36741 gdb_readline_wrapper_line, as is done in tui_command_line_handler. 36742 36743 Tested on x86_64-linux. 36744 36745 PR tui/30636 36746 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30636 36747 367482023-07-26 Tom de Vries <tdevries@suse.de> 36749 36750 [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0 some more 36751 With a gdb build with -O2 -flto=auto and gcc 7.5.0 and test-case 36752 gdb.gdb/python-helper.exp I run into: 36753 ... 36754 (outer-gdb) continue^M 36755 Continuing.^M 36756 print 1^M 36757 ^M 36758 Thread 1 "xgdb" hit Breakpoint 2, \ 36759 _Z11value_printP5valueP7ui_filePK19value_print_options (val=0x22e2590, \ 36760 stream=0x1f65480, options=0x7fffffffcdc0) at gdb/valprint.c:1193^M 36761 1193 {^M 36762 (outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb 36763 ... 36764 36765 This is the "value_print" variant of the problem with "c_print_type" I fixed 36766 in commit 0d332f11122 ("[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 36767 -flto=auto and gcc 7.5.0"). 36768 36769 Fix this likewise. 36770 36771 Tested on x86_64-linux. 36772 367732023-07-26 Tom de Vries <tdevries@suse.de> 36774 36775 [gdb/tui] Fix assert in ~gdbpy_tui_window_maker 36776 In gdb/tui/tui-layout.c, we have: 36777 ... 36778 static window_types_map known_window_types; 36779 ... 36780 and in gdb/python/py-tui.c: 36781 ... 36782 /* A global list of all gdbpy_tui_window_maker objects. */ 36783 static intrusive_list<gdbpy_tui_window_maker> m_window_maker_list; 36784 }; 36785 36786 /* See comment in class declaration above. */ 36787 36788 intrusive_list<gdbpy_tui_window_maker> 36789 gdbpy_tui_window_maker::m_window_maker_list; 36790 ... 36791 36792 With a gdb build with -O0 or -O2, the static destructor calling order seems to be: 36793 - first gdb/tui/tui-layout.c, 36794 - then gdb/python/py-tui.c. 36795 36796 So when running test-case gdb.python/tui-window-factory.exp, we see the 36797 following order of events: 36798 - the destructor for known_window_types is called, which triggers calling the 36799 destructor for the only element E of m_window_maker_list. The destructor 36800 destroys E, and also removes E from m_window_maker_list, leaving it empty. 36801 - the destructor for m_window_maker_list is called. It's empty, so it's a nop. 36802 36803 However, when building gdb with -O2 -flto=auto, the static destructor calling 36804 order seems to be reversed. 36805 36806 Instead, we have these events: 36807 - the destructor for m_window_maker_list is called. This doesn't destroy it's 36808 only element E, but it does make m_window_maker_list empty. 36809 - the destructor for known_window_types is called, which triggers calling the 36810 destructor for E. An attempt is done to remove E from m_window_maker_list, 36811 but we run into an assertion failure, because the list is empty. 36812 36813 Fix this by checking is_linked () before attempting to remove from 36814 m_window_maker_list, similar to how things were addressed in commit 995a34b1772 36815 ("Guard against frame.c destructors running before frame-info.c's"). 36816 36817 Tested on x86_64-linux. 36818 36819 PR tui/30646 36820 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30646 36821 368222023-07-26 Tom de Vries <tdevries@suse.de> 36823 36824 [gdb/testsuite] Fix regexps in gdb.base/step-over-syscall.exp 36825 When running test-case gdb.base/step-over-syscall.exp without glibc debuginfo 36826 installed, I get: 36827 ... 36828 (gdb) continue^M 36829 Continuing.^M 36830 ^M 36831 Breakpoint 2, 0x00007ffff7d4405e in vfork () from /lib64/libc.so.6^M 36832 (gdb) PASS: gdb.base/step-over-syscall.exp: vfork: displaced=off: \ 36833 continue to vfork (1st time) 36834 ... 36835 but with glibc debuginfo installed I get instead: 36836 ... 36837 (gdb) continue^M 36838 Continuing.^M 36839 ^M 36840 Breakpoint 2, 0x00007ffff7d4405e in __libc_vfork () at \ 36841 ../sysdeps/unix/sysv/linux/x86_64/vfork.S:44^M 36842 44 ENTRY (__vfork)^M 36843 (gdb) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: \ 36844 continue to vfork (1st time) 36845 ... 36846 36847 The FAIL is due to a mismatch with regexp: 36848 ... 36849 "Breakpoint \[0-9\]+, (.* in |__libc_|)$syscall \\(\\).*" 36850 ... 36851 because it cannot match both ".* in " and the __libc_ prefix. 36852 36853 Fix this by using instead the regexp: 36854 ... 36855 "Breakpoint \[0-9\]+, (.* in )?(__libc_)?$syscall \\(\\).*" 36856 ... 36857 36858 Tested on x86_64-linux. 36859 368602023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36861 36862 bpf: fix neg and neg32 BPF instructions in simulator 36863 This patch fixes the semantics of the neg and neg32 BPF instructions 36864 in the simulator, and also updates the corresponding tests 36865 accordingly. 36866 36867 Tested in target bpf-unknown-none. 36868 368692023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36870 36871 bpf: fix register NEG[32] instructions 36872 This patch fixes the BPF_INSN_NEGR and BPF_INSN_NEG32R BPF 36873 instructions to not use their source registers. 36874 36875 Tested in bpf-unknown-none. 36876 36877 opcodes/ChangeLog: 36878 36879 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36880 36881 * bpf-opc.c (bpf_opcodes): Fix BPF_INSN_NEGR to not use a src 36882 register. 36883 36884 gas/ChangeLog: 36885 36886 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com> 36887 36888 * testsuite/gas/bpf/alu.s: The register neg instruction gets only 36889 one argument. 36890 * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise. 36891 * testsuite/gas/bpf/alu32-pseudoc.d: Likewise. 36892 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 36893 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 36894 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 36895 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 36896 * testsuite/gas/bpf/alu-be.d: Likewise. 36897 * testsuite/gas/bpf/alu.d: Likewise. 36898 * testsuite/gas/bpf/alu32-be.d: Likewise. 36899 * testsuite/gas/bpf/alu32.d: Likewise. 36900 * testsuite/gas/bpf/alu32.s: Likewise. 36901 * doc/c-bpf.texi (BPF Instructions): Update accordingly. 36902 369032023-07-26 Alan Modra <amodra@gmail.com> 36904 36905 PR30657, gprof heap buffer overflow 36906 PR 30657 36907 * cg_arcs.c (cg_assemble): Sanity check find_call addresses. 36908 * i386.c (i386_find_call): Don't access past end of core_text_space. 36909 * aarch64.c (aarch64_find_call): Round up lowpc, round down highpc. 36910 * alpha.c (alpha_find_call): Likewise. 36911 * mips.c (mips_find_call): Likewise. 36912 * sparc.c (sparc_find_call): Likewise. 36913 * vax.c (vax_find_call): Sanity check core_text_space accesses. 36914 369152023-07-26 Alan Modra <amodra@gmail.com> 36916 36917 [GOLD] reporting local symbol names 36918 get_symbol_name currently returns "" for the usual STT_SECTION symbols 36919 generated by gas. That's not very helpful, return the section name. 36920 Demangle local symbols too, fixing an inconsistency in 36921 issue_discarded_error where global symbols are demangled. 36922 36923 * object.cc (Sized_relobj_file::get_symbol_name): Return a 36924 std::string. Return section name for STT_SECTION symbols with 36925 zero st_name. Sanity check st_name, and don't run off the end 36926 of an improperly terminated .strtab. Demangle sym names. 36927 * object.h (Sized_relobj_file::get_symbol_name): Update decl. 36928 * target-reloc.h (issue_discarded_error): Adjust. 36929 * powerpc.cc (Target_powerpc::Relocate::relocate): Report reloc 36930 type and symbol for relocation overflows. 36931 369322023-07-26 Alan Modra <amodra@gmail.com> 36933 36934 Don't warn on .attach_to_group to same group 36935 * config/obj-elf.c (obj_elf_attach_to_group): Don't warn if 36936 group name matches current group for section. 36937 36938 bpf: format not a string literal 36939 * config/tc-bpf.c (md_assemble): Correct as_bad call. 36940 36941 Regen bpf opcodes POTFILE 36942 369432023-07-26 GDB Administrator <gdbadmin@sourceware.org> 36944 36945 Automatic date update in version.in 36946 369472023-07-25 David Faust <david.faust@oracle.com> 36948 36949 bpf: Add atomic compare-and-exchange instructions 36950 This patch adds the two remaining BPF v3 atomic instructions: 36951 - BPF_INSN_ACMP{,32}: atomic compare-and-swap 36952 - BPF_INSN_AXCHG{,32}: atomic (non-conditional) exchange 36953 36954 Tests and documentation are also updated. 36955 36956 gas/ 36957 * doc/c-bpf.texi (BPF Instructions): Document atomic exchange and 36958 atomic compare-and-swap instructions. 36959 * testsuite/gas/bpf/atomic.s: Test ACMP, ACMP32, AXCHG, AXCGH32 36960 instructions. 36961 * testsuite/gas/bpf/atomic.d: Likewise. 36962 * testsuite/gas/bpf/atomic-be.d: Likewise. 36963 * testsuite/gas/bpf/atomic-pseudoc.s: Likewise. 36964 * testsuite/gas/bpf/atomic-pseudoc.d: Likewise. 36965 * testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise. 36966 36967 include/ 36968 * opcode/bpf.h (BPF_IMM32_ACMP): Fix typo. 36969 (enum bpf_insn_id): New entries for BPF_INSN_ACMP{,32} and 36970 BPF_INSN_AXCHG{,32}. 36971 36972 opcodes/ 36973 * bpf-opc.c (bpf_opcodes): Add entries for ACMP{,32} and 36974 AXCHG{,32} instructions. 36975 369762023-07-25 David Faust <david.faust@oracle.com> 36977 36978 bpf: Update atomic instruction pseudo-C syntax 36979 This patch updates the pseudo-C dialect templates for the BPF v3 atomic 36980 instructions. The templates match the strings emitted by clang -S for 36981 these instructions. 36982 36983 The tests and documentation are updated accordingly. 36984 36985 gas/ 36986 * doc/c-bpf.texi (BPF Instructions): Update entries for atomic 36987 and 32-bit atomic instructions. 36988 * testsuite/gas/bpf/atomic.s: Test AAND, AAND32, AOR, AOR32, 36989 AXOR, AXOR32, AFADD, AFADD32, AFAND, AFAND32, AFOR, AFOR32, 36990 AFXOR and AFXOR32 instructions. 36991 * testsuite/gas/bpf/atomic.d: Likewise. 36992 * testsuite/gas/bpf/atomic-be.d: Likewise. 36993 * testsuite/gas/bpf/atomic-pseudoc.s: Likewise. 36994 * testsuite/gas/bpf/atomic-pseudoc.d: Likewise. 36995 * testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise. 36996 * testsuite/gas/bpf/atomic-v1.s: New test. 36997 * testsuite/gas/bpf/atomic-v1.d: Likewise. 36998 * testuiste/gas/bpf/atomic-v1-be.d: Likewise. 36999 * testuiste/gas/bpf/bpf.exp: Run new tests. 37000 37001 opcodes/ 37002 * bpf-opc.c (bpf_opcodes): Update pseudo-C dialect templates for: 37003 BPF_INSN_AADD, BPF_INSN_AOR, BPF_INSN_AAND, BPF_INSN_AXOR, 37004 BPF_INSN_AFADD, BPF_INSN_AFOR, BPF_INSN_AFAND, BPF_INSN_AFXOR, 37005 BPF_INSN_AADD32, BPF_INSN_AOR32, BPF_INSN_AAND32, 37006 BPF_INSN_AXOR32, BPF_INSN_AFADD32, BPF_INSN_AFOR32, 37007 BPF_INSN_AFAND32, and BPF_INSN_AFXOR32 instructions. 37008 370092023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com> 37010 37011 RISC-V: Enable RVC on ".option arch, +zca" etc. 37012 Since the 'Zca' extension is the new base of the compressed instructions, 37013 this commit enables RVC *also* when the 'Zca' extension is enabled 37014 via ".option arch" directive. 37015 37016 gas/ChangeLog: 37017 37018 * config/tc-riscv.c (s_riscv_option): Enable RVC also when the 37019 'Zca' extension is enabled after an ".option arch" directive. 37020 370212023-07-25 GDB Administrator <gdbadmin@sourceware.org> 37022 37023 Automatic date update in version.in 37024 370252023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com> 37026 37027 RISC-V: Implications from 'Zc[fd]' extensions 37028 The version 1.0.4-1 of the code size reduction specification clarifies 37029 that 'Zcf' implies 'F' and 'Zcd' implies 'D'. 37030 37031 cf: 37032 <https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1> 37033 37034 This commit adds those implications. 37035 37036 bfd/ChangeLog: 37037 37038 * elfxx-riscv.c (riscv_implicit_subsets): Add two implications, 37039 'Zcf' -> 'F' and 'Zcd' -> 'D'. 37040 37041 gas/ChangeLog: 37042 37043 * testsuite/gas/riscv/march-imply-zcd.d: New test. 37044 * testsuite/gas/riscv/march-imply-zcf.d: New test. 37045 370462023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com> 37047 37048 RISC-V: Prohibit the 'Zcf' extension on RV64 37049 As per: 37050 <https://github.com/riscv/riscv-code-size-reduction/issues/221>, 37051 the 'Zcf' extension does not exist on RV64. This is reflected on the 37052 version 1.0.4-1 of the code size reduction specification: 37053 <https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1>. 37054 37055 This commit prohibits the combination: RV64 (or any ISA with XLEN > 32) 37056 and the 'Zcf' extension. 37057 37058 bfd/ChangeLog: 37059 37060 * elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 37061 combination of RV64 and 'Zcf'. 37062 37063 gas/ChangeLog: 37064 37065 * testsuite/gas/riscv/march-fail-rv64i_zcf.d: New test. 37066 * testsuite/gas/riscv/march-fail-rv64i_zcf.l: Likewise. 37067 370682023-07-24 Johannes Schauer Marin Rodrigues <josch@debian.org> 37069 37070 objcopy embeds the current time and ignores SOURCE_DATE_EPOCH making the output unreproducible. 37071 bfd 37072 * peXXigen.c (_bfd_XXi_only_swap_filehdr_out): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined. 37073 binutils 37074 * doc/binutils.texi (objcopy): Document change in behaviour of objcopy's --preserve-dates command line option. 37075 ld 37076 * pe-dll.c (fill_edata): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined. 37077 * ld.texi (--insert-timestamp): Document change in behaviour. 37078 370792023-07-24 Nick Clifton <nickc@redhat.com> 37080 37081 Updated translations for bfd, gold and opcodes 37082 370832023-07-24 mengqinggang <mengqinggang@loongson.cn> 37084 37085 LoongArch: ld: Simplify inserting IRELATIVE relocations to .rela.dyn 37086 In LoongArch, the R_LARCH_IRELATIVE relocations for local ifunc symbols are 37087 in .rela.dyn. Before, this is done by loongarch_elf_finish_dynamic_sections. 37088 But this function is called after elf_link_sort_relocs, it need to find a 37089 null slot to insert IRELATIVE relocation. 37090 37091 Now, it is processed by elf_loongarch_output_arch_local_syms before 37092 elf_link_sort_relocs, just need to call loongarch_elf_append_rela to 37093 insert IRELATIVE relocation. 37094 37095 bfd/ChangeLog: 37096 37097 * elfnn-loongarch.c (elfNN_allocate_local_ifunc_dynrelocs): Return 37098 type change to int. 37099 (loongarch_elf_size_dynamic_sections): Delete (void *). 37100 (loongarch_elf_finish_dynamic_symbol): Use loongarch_elf_append_rela 37101 insert IRELATIVE relocation to .rela.dyn. 37102 (elfNN_loongarch_finish_local_dynamic_symbol): Return type change to 37103 int. 37104 (loongarch_elf_finish_dynamic_sections): Delete process of local 37105 ifunc symbols. 37106 (elf_backend_output_arch_local_syms): New. 37107 37108 ld/ChangeLog: 37109 37110 * testsuite/ld-loongarch-elf/local-ifunc-reloc.d: Regenerated. 37111 371122023-07-24 mengqinggang <mengqinggang@loongson.cn> 37113 37114 LoongArch: Fix immediate overflow check bug 37115 For B16/B21/B26/PCREL20_S2 relocations, if immediate overflow check after 37116 rightshift, and the mask need to include sign bit. 37117 37118 Now, the immediate overflow check before rightshift for easier understand. 37119 37120 bfd/ChangeLog: 37121 37122 * elfxx-loongarch.c (reloc_bits_pcrel20_s2): Delete. 37123 (reloc_bits_b16): Delete. 37124 (reloc_bits_b21): Delete. 37125 (reloc_bits_b26): Delete. 37126 (reloc_sign_bits): New. 37127 371282023-07-24 mengqinggang <mengqinggang@loongson.cn> 37129 37130 LoongArch: Fix instruction immediate bug caused by sign-extend 37131 For extreme code mode, the instruction sequences is 37132 pcalau12i $t0, hi20 37133 addi.d $t1, $zero, lo12 37134 lu32i.d $t1, lo20 37135 lu52i.d $t1, hi12 37136 add.d $t1, $t0, $t1 37137 37138 If lo12 > 0x7ff, hi20 need to add 0x1, lo20 need to sub 0x1. 37139 If hi20 > 0x7ffff, lo20 need to add 0x1. 37140 37141 bfd/ChangeLog: 37142 37143 * elfnn-loongarch.c (RELOCATE_CALC_PC32_HI20): Redefined. 37144 (RELOCATE_CALC_PC64_HI32): Redefined. 37145 371462023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37147 37148 bpf: gas,include,opcode: add suppor for instructions BSWAP{16,32,64} 37149 This patch adds support for the BPF V4 ISA byte swap instructions to 37150 opcodes, assembler and disassembler. 37151 37152 Tested in bpf-unknown-none. 37153 37154 include/ChangeLog: 37155 37156 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37157 37158 * opcode/bpf.h (BPF_IMM32_BSWAP16): Define. 37159 (BPF_IMM32_BSWAP32): Likewise. 37160 (BPF_IMM32_BSWAP64): Likewise. 37161 (enum bpf_insn_id): New entries BPF_INSN_BSWAP{16,32,64}. 37162 37163 opcodes/ChangeLog: 37164 37165 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37166 37167 * bpf-opc.c (bpf_opcodes): Add entries for the BSWAP* 37168 instructions. 37169 37170 gas/ChangeLog: 37171 37172 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37173 37174 * doc/c-bpf.texi (BPF Instructions): Document BSWAP* instructions. 37175 * testsuite/gas/bpf/alu.s: Test BSWAP{16,32,64} instructions. 37176 * testsuite/gas/bpf/alu.d: Likewise. 37177 * testsuite/gas/bpf/alu-be.d: Likewise. 37178 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 37179 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 37180 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 37181 371822023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37183 37184 bpf: gas: fix in manual that MOVS* pseudoc syntax uses = instead of s= 37185 gas/ChangeLog: 37186 37187 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37188 37189 * doc/c-bpf.texi (BPF Instructions): The pseudoc syntax for MOVS* 37190 doesn't use `s=' but `='. 37191 371922023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37193 37194 bpf: gas,opcodes: fix pseudoc syntax for MOVS* and LDXS* insns 37195 This patch fixes the pseudoc syntax of the V4 instructions MOVS* and 37196 LDXS* in order to reflect https://reviews.llvm.org/D144829. 37197 37198 opcodes/ChangeLog: 37199 37200 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37201 37202 * bpf-opc.c (bpf_opcodes): Fix pseudo-c syntax for MOVS* and LDXS* 37203 instructions. 37204 37205 gas/ChangeLog: 37206 37207 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37208 37209 * doc/c-bpf.texi (BPF Instructions): Fix pseudoc syntax for MOVS* 37210 and LDXS* instructions. 37211 * testsuite/gas/bpf/mem-pseudoc.d: Likewise. 37212 * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. 37213 * testsuite/gas/bpf/mem-pseudoc.s: Likewise. 37214 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 37215 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 37216 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 37217 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 37218 * testsuite/gas/bpf/alu32-pseudoc.d: Likewise. 37219 * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise. 37220 372212023-07-24 GDB Administrator <gdbadmin@sourceware.org> 37222 37223 Automatic date update in version.in 37224 372252023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37226 37227 bpf: add support for jal/gotol jump instruction with 32-bit target 37228 This patch adds support for the V4 BPF instruction jal/gotol, which is 37229 like ja/goto but it supports a signed 32-bit PC-relative (in number of 37230 64-bit words minus one) target operand instead of the 16-bit signed 37231 operand of the other instruction. This greatly increases the jump 37232 range in BPF programs. 37233 37234 Tested in bpf-unkown-none. 37235 37236 bfd/ChangeLog: 37237 37238 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37239 37240 * reloc.c: New reloc BFD_RELOC_BPF_DISPCALL32. 37241 * elf64-bpf.c (bpf_reloc_type_lookup): Handle the new reloc. 37242 * libbfd.h (bfd_reloc_code_real_names): Regenerate. 37243 37244 gas/ChangeLog: 37245 37246 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37247 37248 * config/tc-bpf.c (struct bpf_insn): New field `id'. 37249 (md_assemble): Save the ids of successfully parsed instructions 37250 and use the new BFD_RELOC_BPF_DISPCALL32 whenever appropriate. 37251 (md_apply_fix): Adapt to the new BFD reloc. 37252 * testsuite/gas/bpf/jump.s: Test JAL. 37253 * testsuite/gas/bpf/jump.d: Likewise. 37254 * testsuite/gas/bpf/jump-pseudoc.d: Likewise. 37255 * testsuite/gas/bpf/jump-be.d: Likewise. 37256 * testsuite/gas/bpf/jump-be-pseudoc.d: Likewise. 37257 * doc/c-bpf.texi (BPF Instructions): Document new instruction 37258 jal/gotol. 37259 Document new operand type disp32. 37260 37261 include/ChangeLog: 37262 37263 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com> 37264 37265 * opcode/bpf.h (enum bpf_insn_id): Add entry BPF_INSN_JAL. 37266 (enum bpf_insn_id): Remove spurious entry BPF_INSN_CALLI. 37267 37268 opcodes/ChangeLog: 37269 37270 2023-07-23 Jose E. Marchesi <jose.marchesi@oracle.com> 37271 37272 * bpf-opc.c (bpf_opcodes): Add entry for jal. 37273 372742023-07-23 Tom Tromey <tom@tromey.com> 37275 37276 Use 'name' in DAP start_thread function 37277 The DAP start_thread helper function has a 'name' parameter that is 37278 unused. Apparently I forgot to hook it up to the thread constructor. 37279 This patch fixes the oversight. 37280 372812023-07-23 Tom Tromey <tom@tromey.com> 37282 37283 Export gdb.block_signals and create gdb.Thread 37284 While working on an experiment, I realized that I needed the DAP 37285 block_signals function. I figured other developers may need it as 37286 well, so this patch moves it from DAP to the gdb module and exports 37287 it. 37288 37289 I also added a new subclass of threading.Thread that ensures that 37290 signals are blocked in the new thread. 37291 37292 Finally, this patch slightly rearranges the documentation so that 37293 gdb-side threading issues and functions are all discussed in a single 37294 node. 37295 372962023-07-23 Andrew Burgess <aburgess@redhat.com> 37297 37298 gdb: two changes to linux_nat_debug_printf calls in linux-nat.c 37299 This commit adjusts some of the debug output in linux-nat.c, but makes 37300 no other functional changes to GDB. 37301 37302 In resume_lwp I've added the word "sibling" to one of the debug 37303 messages. All the other debug messages in this function talk about 37304 operating on the sibling thread, so I think it makes sense, for 37305 consistency, if the message I've updated also talks about the sibling 37306 thread. 37307 37308 In resume_stopped_resumed_lwps I've reordered the condition checks so 37309 that the vfork-parent check now happens after the checks for whether 37310 the thread is already resumed or not. This makes no functional 37311 difference to GDB, but does, I think, mean we see more helpful debug 37312 messages first. 37313 37314 Consider the situation where a vfork-parent thread is already resumed, 37315 and resume_stopped_resumed_lwps is called. Previously the message 37316 saying that the thread was not being resumed due to being a 37317 vfork-parent, was printed. This might give the impression that the 37318 thread is left in a not resumed state, which is misleading. 37319 37320 After this change we now get a message saying that the thread is not 37321 being resumed due to it not being stopped (i.e. is already resumed). 37322 With this message the already resumed nature of the thread is much 37323 clearer. 37324 37325 I found this change helpful when debugging some vfork related issues. 37326 373272023-07-23 Andrew Burgess <aburgess@redhat.com> 37328 37329 gdb/testsuite: replace $testfile with $binfile in one case 37330 For *reasons* I was hacking on gdb.base/foll-vfork.exp and wanted to 37331 change the name of the binary that was created. Should be easy, I 37332 adjusted the global $binfile variable .... but that didn't work. 37333 37334 In one place the script uses $testfile instead of $binfile. 37335 37336 Fixed this to use $binfile, now I can easily change the name of the 37337 generated binary, and the test still works. 37338 37339 There's no change in what is tested after this commit. 37340 373412023-07-23 GDB Administrator <gdbadmin@sourceware.org> 37342 37343 Automatic date update in version.in 37344 373452023-07-22 Tom de Vries <tdevries@suse.de> 37346 37347 [gdb/testsuite] Improve gdb.arch/arm-pthread_cond_timedwait-bt.exp 37348 I noticed in test-case gdb.arch/arm-pthread_cond_timedwait-bt.exp that 37349 prepare_for_testing is used, followed by a clean_restart. 37350 37351 This calls clean_restart twice in a row. 37352 37353 Fix this by using build_executable instead. 37354 37355 Also, I noticed that the test-case requires an SVC instruction, so add a 37356 require to limit the test-case to supported architectures. 37357 37358 While we're at it, run M-x indent-region in emacs to fix indentation. 37359 37360 Tested on x86_64-linux. 37361 373622023-07-22 Tom de Vries <tdevries@suse.de> 37363 37364 [gdb/testsuite] Use proc readnow in two test-cases 37365 Use "require !readnow" in two test-cases, instead of the written-out variant. 37366 37367 Tested on x86_64-linux, with target boards unix and readnow. 37368 373692023-07-22 GDB Administrator <gdbadmin@sourceware.org> 37370 37371 Automatic date update in version.in 37372 373732023-07-21 Tom Tromey <tom@tromey.com> 37374 37375 Fix crash with DW_FORM_implicit_const 37376 Jakub pointed out that using DW_FORM_implicit_const with 37377 DW_AT_bit_size would cause gdb to crash. This happened because 37378 DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned 37379 to assert. This patch fixes the problem. 37380 37381 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651 37382 Approved-By: Andrew Burgess <aburgess@redhat.com> 37383 373842023-07-21 David Faust <david.faust@oracle.com> 37385 37386 bpf: disasemble offsets of value 0 as "+0" 37387 This tiny patch makes the BPF disassembler to emit, e.g. 37388 37389 ldxdw %r1, [%r0+0] 37390 37391 instead of 37392 37393 ldxdw %r1, [%r00] 37394 37395 when the offset is 0, to avoid confusion. 37396 37397 opcodes/ 37398 37399 * bpf-dis.c (print_insn_bpf): Print offsets with value 0 as "+0". 37400 37401 gas/ 37402 37403 * testsuite/gas/bpf/mem.s: Add tests with offset 0. 37404 * testsuite/gas/bpf/mem-pseudoc.s: Likewise. 37405 * testsuite/gas/bpf/mem.d: Update accordingly. 37406 * testsuite/gas/bpf/mem-be.d: Likewise. 37407 * testsuite/gas/bpf/mem-pseudoc.d: Likewise. 37408 * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. 37409 374102023-07-21 Tom Tromey <tromey@adacore.com> 37411 37412 Implement DAP modules request 37413 This implements the DAP "modules" request, and also arranges to add 37414 the module ID to stack frames. 37415 374162023-07-21 Tom Tromey <tromey@adacore.com> 37417 37418 Add Progspace.objfile_for_address 37419 This adds a new objfile_for_address method to gdb.Progspace. This 37420 makes it easy to find the objfile for a given address. 37421 37422 There's a related PR; and while this change would have been sufficient 37423 for my original need, it's not clear to me whether I should close the 37424 bug. Nevertheless I think it makes sense to at least mention it here. 37425 37426 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288 37427 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 37428 374292023-07-21 Tom Tromey <tromey@adacore.com> 37430 37431 Remove unused imports 37432 I noticed an unused import in dap/evaluate.py; and also I found out 37433 that my recent changes to use frame filters from DAP left some unused 37434 imports in dap/bt.py. 37435 374362023-07-21 Tom Tromey <tromey@adacore.com> 37437 37438 Document array indexing for Python gdb.Value 37439 I noticed that the documentation for gdb.Value doesn't mention array 37440 indexing. 37441 37442 Approved-By: Eli Zaretskii <eliz@gnu.org> 37443 374442023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37445 37446 bpf: opcodes, gas: support for signed load V4 instructions 37447 This commit adds the signed load to register (ldxs*) instructions 37448 introduced in the BPF ISA version 4, including opcodes and assembler 37449 tests. 37450 37451 Tested in bpf-unknown-none. 37452 37453 include/ChangeLog: 37454 37455 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37456 37457 * opcode/bpf.h (enum bpf_insn_id): Add entries for signed load 37458 instructions. 37459 (BPF_MODE_SMEM): Define. 37460 37461 opcodes/ChangeLog: 37462 37463 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37464 37465 * bpf-opc.c (bpf_opcodes): Add entries for LDXS{B,W,H,DW} 37466 instructions. 37467 37468 gas/ChangeLog: 37469 37470 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37471 37472 * testsuite/gas/bpf/mem.s: Add signed load instructions. 37473 * testsuite/gas/bpf/mem-pseudoc.s: Likewise. 37474 * testsuite/gas/bpf/mem.d: Likewise. 37475 * testsuite/gas/bpf/mem-pseudoc.d: Likewise. 37476 * testsuite/gas/bpf/mem-be.d: Likewise. 37477 * doc/c-bpf.texi (BPF Instructions): Document the signed load 37478 instructions. 37479 374802023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37481 37482 bpf: opcodes, gas: support for signed register move V4 instructions 37483 This commit adds the signed register move (movs) instructions 37484 introduced in the BPF ISA version 4, including opcodes and assembler 37485 tests. 37486 37487 Tested in bpf-unknown-none. 37488 37489 include/ChangeLog: 37490 37491 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37492 37493 * opcode/bpf.h (BPF_OFFSET16_MOVS8): Define. 37494 (BPF_OFFSET16_MOVS16): Likewise. 37495 (BPF_OFFSET16_MOVS32): Likewise. 37496 (enum bpf_insn_id): Add entries for MOVS{8,16,32}R and 37497 MOVS32{8,16,32}R. 37498 37499 opcodes/ChangeLog: 37500 37501 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37502 37503 * bpf-opc.c (bpf_opcodes): Add entries for MOVS{8,16,32}R and 37504 MOVS32{8,16,32}R instructions. and MOVS32I instructions. 37505 37506 gas/ChangeLog: 37507 37508 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37509 37510 * testsuite/gas/bpf/alu.s: Test movs instructions. 37511 * testsuite/gas/bpf/alu-pseudoc.s: Likewise. 37512 * testsuite/gas/bpf/alu32.s: Likewise for movs32 instruction. 37513 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 37514 * testsuite/gas/bpf/alu.d: Add expected results. 37515 * testsuite/gas/bpf/alu32.d: Likewise. 37516 * testsuite/gas/bpf/alu-be.d: Likewise. 37517 * testsuite/gas/bpf/alu32-be.d: Likewise. 37518 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 37519 * testsuite/gas/bpf/alu32-pseudoc.d: Likewise. 37520 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 37521 * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise. 37522 375232023-07-21 Tom Tromey <tromey@adacore.com> 37524 37525 Remove redundant @findex from python.texi 37526 In a review, Eli pointed out that @findex is redundant when used with 37527 @defun. This patch removes all such uses from python.texi, plus a 37528 couple uses before @defvar that are also unnecessary. 37529 37530 Approved-By: Eli Zaretskii <eliz@gnu.org> 37531 375322023-07-21 Tom Tromey <tromey@adacore.com> 37533 37534 Fix typo in py-type.c docstring 37535 I noticed that a doc string py-type.c says "an signed". 37536 This patch corrects it to "a signed". 37537 375382023-07-21 Tom Tromey <tromey@adacore.com> 37539 37540 Implement Ada target name symbol 37541 Ada 2022 adds the "target name symbol", which can be used on the right 37542 hand side of an assignment to refer to the left hand side. This 37543 allows for convenient updates. This patch implements this for gdb's 37544 Ada expression parser. 37545 37546 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 37547 375482023-07-21 Tom Tromey <tromey@adacore.com> 37549 37550 Add instruction bytes to DAP disassembly response 37551 The DAP disassemble command lets the client return the underlying 37552 bytes of the instruction in an implementation-defined format. This 37553 patch updates gdb to return this, and simply uses a hex string of the 37554 bytes as the format. 37555 37556 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 37557 375582023-07-21 Tom Tromey <tromey@adacore.com> 37559 37560 Remove ancient Ada workaround 37561 I ran across this very old code in gdb's Ada support. After a bit of 37562 archaeology, we couldn't determine what bug this might have been 37563 working around. It is no longer needed, so this patch removes it. 37564 37565 As this is entirely Ada-specific and was reviewed and tested at 37566 AdaCore, I'm checking it in. 37567 375682023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37569 37570 bpf: add missing bpf-dis.c to opcodes/Makefile.am 37571 This was breaking --enable-targets=all builds. 37572 37573 opcodes/ChangeLog: 37574 37575 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37576 37577 * Makefile.am (TARGET64_LIBOPCODES_CFILES): Add missing bpf-dis.c 37578 * Makefile.in: Regenerate. 37579 375802023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37581 37582 sim/bpf: desCGENization of the BPF simulator 37583 The BPF port in binutils has been rewritten (commit 37584 d218e7fedc74d67837d2134120917f4ac877454c) in order to not be longer 37585 based on CGEN. Please see that commit log for more information. 37586 37587 This patch updates the BPF simulator accordingly. The new 37588 implementation is much simpler and it is based on the new BPF opcodes. 37589 37590 Tested with target bpf-unknown-none with both 64-bit little-endian 37591 host and 32-bit little-endian host. 37592 37593 Note that I have not tested in a big-endian host yet. I will do so 37594 once this lands upstream so I can use the GCC compiler farm. 37595 375962023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com> 37597 37598 DesCGENization of the BPF binutils port 37599 CGEN is cool, but the BPF architecture is simply too bizarre for it. 37600 37601 The weird way of BPF to handle endianness in instruction encoding, the 37602 weird C-like alternative assembly syntax, the weird abuse of 37603 multi-byte (or infra-byte) instruction fields as opcodes, the unusual 37604 presence of opcodes beyond the first 32-bits of some instructions, are 37605 all examples of what makes it a PITA to continue using CGEN for this 37606 port. The bpf.cpu file is becoming so complex and so nested with 37607 p-macros that it is very difficult to read, and quite challenging to 37608 update. Also, every time we are forced to change something in CGEN to 37609 accommodate BPF requirements (which is often) we have to do extensive 37610 testing to make sure we do not break any other target using CGEN. 37611 37612 This is getting un-maintenable. 37613 37614 So I have decided to bite the bullet and revamp/rewrite the port so it 37615 no longer uses CGEN. Overall, this involved: 37616 37617 * To remove the cpu/bpf.{cpu,opc} descriptions. 37618 37619 * To remove the CGEN generated files. 37620 37621 * To replace the CGEN generated opcodes table with a new hand-written 37622 opcodes table for BPF. 37623 37624 * To replace the CGEN generated disassembler wih a new disassembler 37625 that uses the new opcodes. 37626 37627 * To replace the CGEN generated assembler with a new assembler that uses the 37628 new opcodes. 37629 37630 * To replace the CGEN generated simulator with a new simulator that uses the 37631 new opcodes. [This is pushed in GDB in another patch.] 37632 37633 * To adapt the build systems to the new situation. 37634 37635 Additionally, this patch introduces some extensions and improvements: 37636 37637 * A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF 37638 relocation R_BPF_GNU_64_16 are added to the BPF BFD port. These 37639 relocations are used for section-relative 16-bit offsets used in 37640 load/store instructions. 37641 37642 * The disassembler now has support for the "pseudo-c" assembly syntax of 37643 BPF. What dialect to use when disassembling is controlled by a command 37644 line option. 37645 37646 * The disassembler now has support for dumping instruction immediates in 37647 either octal, hexadecimal or decimal. The used output base is controlled 37648 by a new command-line option. 37649 37650 * The GAS BPF test suite has been re-structured and expanded in order to 37651 test the disassembler pseudoc syntax support. Minor bugs have been also 37652 fixed there. The assembler generic tests that were disabled for bpf-*-* 37653 targets due to the previous implementation of pseudoc syntax are now 37654 re-enabled. Additional tests have been added to test the new features of 37655 the assembler. .dump files are no longer used. 37656 37657 * The linker BPF test suite has been adapted to the command line options 37658 used by the new disassembler. 37659 37660 The result is very satisfactory. This patchs adds 3448 lines of code 37661 and removes 10542 lines of code. 37662 37663 Tested in: 37664 37665 * Target bpf-unknown-none with 64-bit little-endian host and 32-bit 37666 little-endian host. 37667 37668 * Target x86-64-linux-gnu with --enable-targets=all 37669 37670 Note that I have not tested in a big-endian host yet. I will do so 37671 once this lands upstream so I can use the GCC compiler farm. 37672 37673 I have not included ChangeLog entries in this patch: these would be 37674 massive and not very useful, considering this is pretty much a rewrite 37675 of the port. I beg the indulgence of the global maintainers. 37676 376772023-07-21 Lancelot Six <lancelot.six@amd.com> 37678 37679 gdb/solib-rocm: limit the number of opened file descriptors 37680 ROCm programs can load a high number of compute kernels on GPU devices, 37681 especially if lazy code-object loading have been disabled. Each code 37682 object containing such program is loaded once for each device available, 37683 and each instance is reported by GDB as an individual shared library. 37684 37685 We came across situations where the number of shared libraries opened by 37686 GDB gets higher than the allowed number of opened files for the process. 37687 Increasing the opened files limit works around the problem, but there is a 37688 better way this patch proposes to follow. 37689 37690 Under the hood, the GPU code objects are embedded inside the host 37691 application binary and shared library binaries. GDB currently opens the 37692 underlying file once for each shared library it sees. That means that 37693 the same file is re-opened every time a code object is loaded on a GPU. 37694 37695 This patch proposes to only open each underlying file once. This is 37696 done by implementing a reference counting mechanism so the underlying 37697 file is opened when the underlying file first needs to be opened, and 37698 closed when the last BFD using the underlying file is closed. 37699 37700 On a program where GDB used to open about 1500 files to load all shared 37701 libraries, this patch makes it so only 54 opened file descriptors are 37702 needed. 37703 37704 I have tested this patch on downstream ROCgdb's full testsuite and 37705 upstream GDB testsuite with no regression. 37706 37707 Approved-By: Pedro Alves <pedro@palves.net> 37708 377092023-07-21 Jan Beulich <jbeulich@suse.com> 37710 37711 x86: adjust disassembly of insns operating on selector values 37712 Bring disassembly back in line with what the assembler accepts, thus 37713 also making it self-consistent (with, in particular selector load/store 37714 insns). While there further add D to all affected insns except ARPL 37715 (where S is used, matching LAR/LSL), to also behave correctly in suffix- 37716 always mode. 37717 37718 While there also hook up the Intel variant of the LKGS test. 37719 377202023-07-21 Jan Beulich <jbeulich@suse.com> 37721 37722 x86: simplify disassembly of LAR/LSL 37723 For whatever reason in c9f5b96bdab0 ("x86: correct handling of LAR and 37724 LSL") I didn't realize that we can easily use Sv instead of going 37725 through mod_table[]. Redo this aspect of that change. 37726 377272023-07-21 Tom de Vries <tdevries@suse.de> 37728 37729 [gdb/symtab] Add optimized out static var to cooked index 37730 Consider the test-case: 37731 ... 37732 $ cat main.c 37733 int main (void) { return 0; } 37734 $ cat static-optimized-out.c 37735 static int aaa; 37736 ... 37737 compiled like this: 37738 ... 37739 $ gcc-12 static-optimized-out.c main.c -g -O2 -flto 37740 ... 37741 37742 There's a difference in behaviour depending on symtab expansion state: 37743 ... 37744 $ gdb -q -batch a.out -ex "print aaa" 37745 No symbol "aaa" in current context. 37746 $ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa" 37747 $1 = <optimized out> 37748 ... 37749 37750 The reason for the difference is that the optimized out variable aaa: 37751 ... 37752 <1><104>: Abbrev Number: 2 (DW_TAG_variable) 37753 <105> DW_AT_name : aaa 37754 <109> DW_AT_decl_file : 1 37755 <10a> DW_AT_decl_line : 18 37756 <10b> DW_AT_decl_column : 12 37757 <10c> DW_AT_type : <0x110> 37758 ... 37759 is not added to the cooked index because of this clause in abbrev_table::read: 37760 ... 37761 else if (!has_location && !has_specification_or_origin && !has_external 37762 && cur_abbrev->tag == DW_TAG_variable) 37763 cur_abbrev->interesting = false; 37764 ... 37765 37766 Fix this inconsistency by making sure that the optimized out variable is added 37767 to the cooked index. 37768 37769 Regression tested on x86_64-linux. 37770 37771 Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf 37772 assembly test-case gdb.dwarf2/static-optimized-out.exp. 37773 37774 Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now 37775 consistently get: 37776 ... 37777 (gdb) print aaa^M 37778 $1 = <optimized out>^M 37779 ... 37780 and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get: 37781 ... 37782 (gdb) print aaa^M 37783 No symbol "aaa" in current context.^M 37784 ... 37785 due to missing debug info for the variable. 37786 37787 PR symtab/30656 37788 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656 37789 37790 Approved-By: Tom Tromey <tom@tromey.com> 37791 377922023-07-21 Tom de Vries <tdevries@suse.de> 37793 37794 [gdb/tui] Fix superfluous newline for long prompt 37795 In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size 37796 as the terminal width, we get a superfluous newline at line 19: 37797 ... 37798 16 (gdb) set prompt 123456789A123456789B123 37799 17 456789C123456789> 37800 18 123456789A123456789B123456789C123456789> 37801 19 37802 20 123456789A123456789B123456789C123456789> 37803 21 set prompt (gdb) 37804 22 (gdb) 37805 ... 37806 as well as a superfluous repetition of the prompt at line 20 once we type the 37807 's' starting "set prompt". 37808 37809 I traced the superfluous newline back to readline's readline_internal_setup, 37810 that does: 37811 ... 37812 /* If we're not echoing, we still want to at least print a prompt, because 37813 rl_redisplay will not do it for us. If the calling application has a 37814 custom redisplay function, though, let that function handle it. */ 37815 if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay) 37816 ... 37817 else 37818 { 37819 if (rl_prompt && rl_already_prompted) 37820 rl_on_new_line_with_prompt (); 37821 else 37822 rl_on_new_line (); 37823 (*rl_redisplay_function) (); 37824 ... 37825 and then we hit the case that calls rl_on_new_line_with_prompt, which does: 37826 ... 37827 /* If the prompt length is a multiple of real_screenwidth, we don't know 37828 whether the cursor is at the end of the last line, or already at the 37829 beginning of the next line. Output a newline just to be safe. */ 37830 if (l > 0 && (l % real_screenwidth) == 0) 37831 _rl_output_some_chars ("\n", 1); 37832 ... 37833 37834 This doesn't look like a readline bug, because the behaviour matches the 37835 comment. 37836 37837 [ And the fact that the output of the newline doesn't happen in the scope of 37838 tui_redisplay_readline means it doesn't get the prompt wrap detection 37839 treatment, causing start_line to be incorrect, which causes the superfluous 37840 repetition of the prompt. ] 37841 37842 I looked at ways to work around this, and managed by switching off 37843 rl_already_prompted, which we set to 1 in tui_rl_startup_hook: 37844 ... 37845 /* Readline hook to redisplay ourself the gdb prompt. 37846 In the SingleKey mode, the prompt is not printed so that 37847 the command window is cleaner. It will be displayed if 37848 we temporarily leave the SingleKey mode. */ 37849 static int 37850 tui_rl_startup_hook (void) 37851 { 37852 rl_already_prompted = 1; 37853 if (tui_current_key_mode != TUI_COMMAND_MODE 37854 && !gdb_in_secondary_prompt_p (current_ui)) 37855 tui_set_key_mode (TUI_SINGLE_KEY_MODE); 37856 tui_redisplay_readline (); 37857 return 0; 37858 } 37859 ... 37860 37861 Then I started looking at why rl_already_prompted is set to 1. 37862 37863 The use case for rl_already_prompted seems to be: 37864 - app (application, the readline user) outputs prompt, 37865 - app sets rl_already_prompted to 1, and 37866 - app calls readline, which calls rl_on_new_line_with_prompt, which figures 37867 out how long the prompt is, and sets a few readline variables accordingly, 37868 which can be used in the following call to rl_redisplay_function. 37869 37870 AFAICT, TUI does not fit this pattern. It does not output an initial prompt, 37871 rather it writes the prompt in every rl_redisplay_function. It doesn't use 37872 the variables set by rl_on_new_line_with_prompt, instead it figures stuff out 37873 by itself. 37874 37875 Fix this by removing the rl_already_prompted setting. 37876 37877 Also remove the call to tui_redisplay_readline, it's not necessary, the 37878 function is called anyway. 37879 37880 Tested on x86_64-linux, no regressions. 37881 378822023-07-21 GDB Administrator <gdbadmin@sourceware.org> 37883 37884 Automatic date update in version.in 37885 378862023-07-20 Alan Modra <amodra@gmail.com> 37887 37888 MIPS: Don't move __gnu_lto_slim to .scommon 37889 * elfxx-mips.c (_bfd_mips_elf_symbol_processing): Don't treat 37890 __gnu_lto_slim as SHN_MIPS_SCOMMON. 37891 (_bfd_mips_elf_add_symbol_hook): Likewise. 37892 378932023-07-20 GDB Administrator <gdbadmin@sourceware.org> 37894 37895 Automatic date update in version.in 37896 378972023-07-19 Hui Li <lihui@loongson.cn> 37898 37899 gdb: LoongArch: Update status of the entire regset in regcache 37900 In the current code, when a register is fetched, the entire regset 37901 are fetched via ptrace, but only this register status is updated in 37902 regcache, it needs to fetch the same regset through ptrace again if 37903 another register in this regset is fetched later, this is obviously 37904 unnecessary. It is proper to update the status of the entire regset 37905 in regcache when fetching a register via ptrace. 37906 37907 Reviewed-By: Tom Tromey <tom@tromey.com> 37908 379092023-07-19 Pedro Alves <pedro@palves.net> 37910 37911 Fix gdb.Inferior.read_memory without execution (PR dap/30644) 37912 Andrew reported that the previous change to gdb.Inferior.read_memory & 37913 friends introducing scoped_restore_current_inferior_for_memory broke 37914 gdb.dap/stop-at-main.exp. This is also reported as PR dap/30644. 37915 37916 The root of the problem is that all the methods that now use 37917 scoped_restore_current_inferior_for_memory cause GDB to crash with a 37918 failed assert if they are run on an inferior that is not yet started. 37919 37920 E.g.: 37921 37922 (gdb) python i = gdb.selected_inferior () 37923 (gdb) python i.read_memory (4,4) 37924 gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed. 37925 37926 This patch fixes the problem by removing 37927 scoped_restore_current_inferior_for_memory's ctor ptid parameter and 37928 the any_thread_of_inferior calls completely, and making 37929 scoped_restore_current_inferior_for_memory switch inferior_ptid to a 37930 pid ptid. 37931 37932 I was a little worried that some port might be assuming inferior_ptid 37933 points at a thread in the xfer_partial memory access routines. We 37934 know that anything that supports forks must not assume that, due to 37935 how detach_breakpoints works. I looked at a number of xfer_partial 37936 implementations, and didn't see anything that is looking at 37937 inferior_ptid in a way that would misbehave. I'm thinking that we 37938 could go forward with this and just fix ports if they break. 37939 37940 While on some ports like on AMD GPU we have thread-specific address 37941 spaces, and so when accessing memory for those address spaces, we must 37942 have the right thread context (via inferior_ptid) selected, in 37943 Inferior.read_memory, we only have the inferior to work with, so this 37944 API as is can't be used to access thread-specific address spaces. 37945 IOW, it can only be used to access the global address space that is 37946 visible to both the CPU and the GPUs. 37947 37948 In proc-service.c:ps_xfer_memory, the other spot using 37949 scoped_restore_current_inferior_for_memory, we're always accessing 37950 per-inferior memory. 37951 37952 If we end up using scoped_restore_current_inferior_for_memory later to 37953 set up the context to read memory from a specific thread, then we can 37954 add an alternative ctor that takes a thread_info pointer, and make 37955 inferior_ptid point to the thread, for example. 37956 37957 New test added to gdb.python/py-inferior.exp, exercising 37958 Inferior.read_memory without execution. 37959 37960 No regressions on native and extended-gdbserver x86_64 GNU/Linux. 37961 37962 Reviewed-By: Tom Tromey <tom@tromey.com> 37963 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644 37964 Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19 37965 379662023-07-19 Nick Clifton <nickc@redhat.com> 37967 37968 Updated Romainian translation for the opcodes directory 37969 379702023-07-19 Lancelot SIX <lancelot.six@amd.com> 37971 37972 gdb/amd-dbgapi-target: Use inf param in detach 37973 Current implementation of amd_dbgapi_target::detach (inferior *, int) 37974 does the following: 37975 37976 remove_breakpoints_inf (current_inferior ()); 37977 detach_amd_dbgapi (inf); 37978 beneath ()->detach (inf, from_tty); 37979 37980 I find that using a mix of `current_inferior ()` and `inf` disturbing. 37981 At this point, we know that both are the same (target_detach does assert 37982 that `inf == current_inferior ()` before calling target_ops::detach). 37983 37984 To improve consistency, this patch replaces `current_inferior ()` with 37985 `inf` in amd_dbgapi_target::detach. 37986 37987 Change-Id: I01b7ba2e661c25839438354b509d7abbddb7c5ed 37988 Approved-By: Pedro Alves <pedro@palves.net> 37989 379902023-07-19 Tom de Vries <tdevries@suse.de> 37991 37992 [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0 37993 With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into: 37994 ... 37995 (gdb) ptype global_c^M 37996 ^M 37997 Thread 1 "xgdb" hit Breakpoint 3, \ 37998 _Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \ 37999 gdb/c-typeprint.c:175^M 38000 175 {^M 38001 (outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again 38002 ... 38003 38004 This is a problem with the debug info, which marks the CU containing the 38005 function declaration as C rather than C++. This is fixed in gcc 8 and later. 38006 38007 Work around this compiler problem by allowing the mangled name. 38008 38009 Tested on x86_64-linux. 38010 38011 PR testsuite/30648 38012 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648 38013 380142023-07-19 Alan Modra <amodra@gmail.com> 38015 38016 [GOLD, PowerPC64] Debug info relocation overflow 38017 It is possible to build huge binaries on powerpc64, where 32-bit 38018 addresses in debug info are insufficient to descibe locations in the 38019 binary. Help out the user, and only warn about debug overflows. 38020 38021 * powerpc.cc (Target_powerpc::Relocate::relocate): Warn on 38022 relocation overflows in debug info. 38023 380242023-07-19 Alan Modra <amodra@gmail.com> 38025 38026 Tidy binutils configure 38027 Separate out some of the defines from the block handling windows 38028 support, so they don't get lost. Delete an unused variable. 38029 380302023-07-19 Alan Modra <amodra@gmail.com> 38031 38032 Build all the objdump extensions with --enable-targets=all 38033 Only the xcoff and pe extensions were enabled. Build the lot, and fix 38034 some more printf format problems when the host is 32-bit. 38035 38036 * configure.ac (od_vectors): Set up for --enable-targets=all. 38037 * configure: Regenerate. 38038 * od-elf32_avr.c (elf32_avr_dump_mem_usage): Correct format 38039 specifier vs. arg mismatch. 38040 (elf32_avr_dump_avr_prop): Likewise. 38041 380422023-07-19 Alan Modra <amodra@gmail.com> 38043 38044 gas 32-bit host compile warnings 38045 * config/tc-d10v.c (find_opcode): Correct format specifier vs. 38046 arg mismatch. 38047 * config/tc-m68hc11.c (fixup8, fixup16, fixup24, fixup8_xg): Likewise. 38048 * config/tc-vax.c (md_assemble): Likewise. 38049 * config/tc-xtensa.c (dump_litpools): Likewise. 38050 * config/tc-z80.c (emit_data_val, emit_byte): Likewise. 38051 380522023-07-19 GDB Administrator <gdbadmin@sourceware.org> 38053 38054 Automatic date update in version.in 38055 380562023-07-18 Nick Clifton <nickc@redhat.com> 38057 38058 Updated Swedish translation for the binutils subdirectory 38059 380602023-07-18 Pter Chubb <peter.chubb@unsw.edu.au> 38061 38062 PR 30632 - ld segfaults if linker script includes a STARTUP line. 38063 380642023-07-18 Jiawei <jiawei@iscas.ac.cn> 38065 38066 RISC-V: Supports Zcb extension. 38067 This patch support Zcb extension, contains new compressed instructions, 38068 some instructions depend on other existed extension, like 'zba', 'zbb' 38069 and 'zmmul'. Zcb also imply Zca extension to enable the compressing 38070 features. 38071 38072 Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com> 38073 Co-Authored by: Mary Bennett <mary.bennett@embecosm.com> 38074 Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com> 38075 Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com> 38076 Co-Authored by: Simon Cook <simon.cook@embecosm.com> 38077 Co-Authored by: Shihua Liao <shihua@iscas.ac.cn> 38078 Co-Authored by: Yulong Shi <yulong@iscas.ac.cn> 38079 38080 bfd/ChangeLog: 38081 38082 * elfxx-riscv.c (riscv_multi_subset_supports): New extension. 38083 (riscv_multi_subset_supports_ext): Ditto. 38084 38085 gas/ChangeLog: 38086 38087 * config/tc-riscv.c (validate_riscv_insn): New operators. 38088 (riscv_ip): Ditto. 38089 * testsuite/gas/riscv/zcb.d: New test. 38090 * testsuite/gas/riscv/zcb.s: New test. 38091 38092 include/ChangeLog: 38093 38094 * opcode/riscv-opc.h (MATCH_C_LBU): New opcode. 38095 (MASK_C_LBU): New mask. 38096 (MATCH_C_LHU): New opcode. 38097 (MASK_C_LHU): New mask. 38098 (MATCH_C_LH): New opcode. 38099 (MASK_C_LH): New mask. 38100 (MATCH_C_SB): New opcode. 38101 (MASK_C_SB): New mask. 38102 (MATCH_C_SH): New opcode. 38103 (MASK_C_SH): New mask. 38104 (MATCH_C_ZEXT_B): New opcode. 38105 (MASK_C_ZEXT_B): New mask. 38106 (MATCH_C_SEXT_B): New opcode. 38107 (MASK_C_SEXT_B): New mask. 38108 (MATCH_C_ZEXT_H): New opcode. 38109 (MASK_C_ZEXT_H): New mask. 38110 (MATCH_C_SEXT_H): New opcode. 38111 (MASK_C_SEXT_H): New mask. 38112 (MATCH_C_ZEXT_W): New opcode. 38113 (MASK_C_ZEXT_W): New mask. 38114 (MATCH_C_NOT): New opcode. 38115 (MASK_C_NOT): New mask. 38116 (MATCH_C_MUL): New opcode. 38117 (MASK_C_MUL): New mask. 38118 (DECLARE_INSN): New opcode. 38119 * opcode/riscv.h (EXTRACT_ZCB_BYTE_UIMM): New inline func. 38120 (EXTRACT_ZCB_HALFWORD_UIMM): Ditto. 38121 (ENCODE_ZCB_BYTE_UIMM): Ditto. 38122 (ENCODE_ZCB_HALFWORD_UIMM): Ditto. 38123 (VALID_ZCB_BYTE_UIMM): Ditto. 38124 (VALID_ZCB_HALFWORD_UIMM): Ditto. 38125 (enum riscv_insn_class): New extension class. 38126 38127 opcodes/ChangeLog: 38128 38129 * riscv-dis.c (print_insn_args): New operators. 38130 * riscv-opc.c: New instructions. 38131 381322023-07-18 Jiawei <jiawei@iscas.ac.cn> 38133 38134 RISC-V: Support Zca/f/d extensions. 38135 This patch add Zca/f/d extensions support, since all ZC* 38136 extensions will imply Zca extension, just enabled compress 38137 feature when Zca extension is available. 38138 38139 Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com> 38140 Co-Authored by: Mary Bennett <mary.bennett@embecosm.com> 38141 Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com> 38142 Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com> 38143 Co-Authored by: Simon Cook <simon.cook@embecosm.com> 38144 Co-Authored by: Shihua Liao <shihua@iscas.ac.cn> 38145 Co-Authored by: Yulong Shi <yulong@iscas.ac.cn> 38146 38147 bfd/ChangeLog: 38148 38149 * elfxx-riscv.c (riscv_multi_subset_supports): New extensions. 38150 (riscv_multi_subset_supports_ext): Ditto. 38151 38152 gas/ChangeLog: 38153 38154 * config/tc-riscv.c (riscv_set_arch): Extend compress check. 38155 * testsuite/gas/riscv/zca.d: New test. 38156 * testsuite/gas/riscv/zca.s: New test. 38157 * testsuite/gas/riscv/zcd.d: New test. 38158 * testsuite/gas/riscv/zcd.s: New test. 38159 * testsuite/gas/riscv/zcf.d: New test. 38160 * testsuite/gas/riscv/zcf.s: New test. 38161 381622023-07-18 GDB Administrator <gdbadmin@sourceware.org> 38163 38164 Automatic date update in version.in 38165 381662023-07-17 Tom Tromey <tromey@adacore.com> 38167 38168 Remove unused declaration of child_terminal_init_with_pgrp 38169 child_terminal_init_with_pgrp is declared but not defined. This patch 38170 removes the declaration. Tested by grep and rebuilding. 38171 381722023-07-17 Michael Matz <matz@suse.de> 38173 38174 Also support '^=' in linker script expressions 38175 this requires also changes in ldgram.y and ldexp.c, unlike 38176 accepting '^' only. But let's do this anyway, if only for 38177 symmetry. 38178 381792023-07-17 Andrew Burgess <aburgess@redhat.com> 38180 38181 gdb: additional debug output in infrun.c and linux-nat.c 38182 While working on some of the recent patches relating to vfork handling 38183 I found this debug output very helpful, I'd like to propose adding 38184 this into GDB. 38185 38186 With debug turned off there should be no user visible changes after 38187 this commit. 38188 381892023-07-17 Andrew Burgess <aburgess@redhat.com> 38190 38191 gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp 38192 While working on gdb.base/foll-vfork.exp I noticed that there are 38193 several random 'sleep' calls throughout the test. 38194 38195 The comment suggests these are to allow for output from a vforked 38196 child to arrive, but in each case the test is about to close and 38197 restart GDB, so I don't see how random output from a child process 38198 could impact testing. 38199 38200 I removed the sleep calls and couldn't reproduce any failures from 38201 this test, I left the test running for a couple of hours, and tried 38202 loading my machine, and the test seems fine with these removed. 38203 38204 I've left this as a separate commit so that if, in the future, someone 38205 can show that these are required, it will be easy to revert this one 38206 patch and bring them back. 38207 38208 There should be no change in what is tested after this commit. 38209 382102023-07-17 Andrew Burgess <aburgess@redhat.com> 38211 38212 gdb/testsuite: expand gdb.base/foll-vfork.exp 38213 This commit provides tests for all of the bugs fixed in the previous 38214 four commits, this is achieved by expanding gdb.base/foll-vfork.exp to 38215 run with different configurations: 38216 38217 * target-non-stop on/off 38218 * non-stop on/off 38219 * schedule-multiple on/off 38220 38221 We don't test with schedule-multiple on if we are using a remote 38222 target, this is due to bug gdb/30574. I've added a link to that bug 38223 in this commit, but all this commit does is expose that bug, there's 38224 no fixes here. 38225 38226 Some of the bugs fixed in the previous commits are very timing 38227 dependent, as such, they don't always show up. I've had more success 38228 when running this test on a very loaded machine -- I usually run ~8 38229 copies of the test in parallel, then the bugs would normally show up 38230 pretty quickly. 38231 38232 Other than running the test in more configurations, I've not made any 38233 changes to what is actually being tested, other than in one place 38234 where, when testing with non-stop mode, GDB stops in a different 38235 inferior, as such I had to add a new 'inferior 2' call, this can be 38236 found in vfork_relations_in_info_inferiors. 38237 38238 I have cleaned things up a little, for example, making use of 38239 proc_with_prefix to remove some with_test_prefix calls. 38240 38241 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30574 38242 382432023-07-17 Andrew Burgess <aburgess@redhat.com> 38244 38245 gdb: don't resume vfork parent while child is still running 38246 Like the last few commit, this fixes yet another vfork related issue. 38247 Like the commit titled: 38248 38249 gdb: don't restart vfork parent while waiting for child to finish 38250 38251 which addressed a case in linux-nat where we would try to resume a 38252 vfork parent, this commit addresses a very similar case, but this time 38253 occurring in infrun.c. Just like with that previous commit, this bug 38254 results in the assert: 38255 38256 x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. 38257 38258 In this case the issue occurs when target-non-stop is on, but non-stop 38259 is off, and again, schedule-multiple is on. As with the previous 38260 commit, GDB is in follow-fork-mode child. If you have not done so, it 38261 is worth reading the earlier commit as many of the problems leading to 38262 the failure are the same, they just appear in a different part of GDB. 38263 38264 Here are the steps leading to the assertion failure: 38265 38266 1. The user performs a 'next' over a vfork, GDB stop in the vfork 38267 child, 38268 38269 2. As we are planning to follow the child GDB sets the vfork_parent 38270 and vfork_child member variables in the two inferiors, the 38271 thread_waiting_for_vfork_done member is left as nullptr, that member 38272 is only used when GDB is planning to follow the parent inferior, 38273 38274 3. The user does 'continue', our expectation is that the vfork child 38275 should resume, and once that process has exited or execd, GDB should 38276 detach from the vfork parent. As a result of the 'continue' GDB 38277 eventually enters the proceed function, 38278 38279 4. In proceed we selected a ptid_t to resume, because 38280 schedule-multiple is on we select minus_one_ptid (see 38281 user_visible_resume_ptid), 38282 38283 5. As GDB is running in all-stop on top of non-stop mode, in the 38284 proceed function we iterate over all threads that match the resume 38285 ptid, which turns out to be all threads, and call 38286 proceed_resume_thread_checked. One of the threads we iterate over 38287 is the vfork parent thread, 38288 38289 6. As the thread passed to proceed_resume_thread_checked doesn't 38290 match any of the early return conditions, GDB will set the thread 38291 resumed, 38292 38293 7. As we are resuming one thread at a time, this thread is seen by 38294 the lower layers (e.g. linux-nat) as the "event thread", which means 38295 we don't apply any of the checks, e.g. is this thread a 38296 vfork parent, instead we assume that GDB core knows what it's doing, 38297 and linux-nat will resume the thread, we have now incorrectly set 38298 running the vfork parent thread when this thread should be waiting 38299 for the vfork child to complete, 38300 38301 8. Back in the proceed function GDB continues to iterate over all 38302 threads, and now (correctly) resumes the vfork child thread, 38303 38304 8. As the vfork child is still alive the kernel holds the vfork 38305 parent stopped, 38306 38307 9. Eventually the child performs its exec and GDB is sent and EXECD 38308 event. However, because the parent is resumed, as soon as the child 38309 performs its exec the vfork parent also sends a VFORK_DONE event to 38310 GDB, 38311 38312 10. Depending on timing both of these events might seem to arrive in 38313 GDB at the same time. Normally GDB expects to see the EXECD or 38314 EXITED/SIGNALED event from the vfork child before getting the 38315 VFORK_DONE in the parent. We know this because it is as a result of 38316 the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see 38317 handle_vfork_child_exec_or_exit for details). Further the comment 38318 in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that 38319 when we remain attached to the child (not the parent) we should not 38320 expect to see a VFORK_DONE, 38321 38322 11. If both events arrive at the same time then GDB will randomly 38323 choose one event to handle first, in some cases this will be the 38324 VFORK_DONE. As described above, upon seeing a VFORK_DONE GDB 38325 expects that (a) the vfork child has finished, however, in this case 38326 this is not completely true, the child has finished, but GDB has not 38327 processed the event associated with the completion yet, and (b) upon 38328 seeing a VFORK_DONE GDB assumes we are remaining attached to the 38329 parent, and so resumes the parent process, 38330 38331 12. GDB now handles the EXECD event. In our case we are detaching 38332 from the parent, so GDB calls target_detach (see 38333 handle_vfork_child_exec_or_exit), 38334 38335 13. While this has been going on the vfork parent is executing, and 38336 might even exit, 38337 38338 14. In linux_nat_target::detach the first thing we do is stop all 38339 threads in the process we're detaching from, the result of the stop 38340 request will be cached on the lwp_info object, 38341 38342 15. In our case the vfork parent has exited though, so when GDB 38343 waits for the thread, instead of a stop due to signal, we instead 38344 get a thread exited status, 38345 38346 16. Later in the detach process we try to resume the threads just 38347 prior to making the ptrace call to actually detach (see 38348 detach_one_lwp), as part of the process to resume a thread we try to 38349 touch some registers within the thread, and before doing this GDB 38350 asserts that the thread is stopped, 38351 38352 17. An exited thread is not classified as stopped, and so the assert 38353 triggers! 38354 38355 Just like with the earlier commit, the fix is to spot the vfork parent 38356 status of the thread, and not resume such threads. Where the earlier 38357 commit fixed this in linux-nat, in this case I think the fix should 38358 live in infrun.c, in proceed_resume_thread_checked. This function 38359 already has a similar check to not resume the vfork parent in the case 38360 where we are planning to follow the vfork parent, I propose adding a 38361 similar case that checks for the vfork parent when we plan to follow 38362 the vfork child. 38363 38364 This new check will mean that at step #6 above GDB doesn't try to 38365 resume the vfork parent thread, which prevents the VFORK_DONE from 38366 ever arriving. Once GDB sees the EXECD/EXITED/SIGNALLED event from 38367 the vfork child GDB will detach from the parent. 38368 38369 There's no test included in this commit. In a subsequent commit I 38370 will expand gdb.base/foll-vfork.exp which is when this bug would be 38371 exposed. 38372 38373 If you do want to reproduce this failure then you will for certainly 38374 need to run the gdb.base/foll-vfork.exp test in a loop as the failures 38375 are all very timing sensitive. I've found that running multiple 38376 copies in parallel makes the failure more likely to appear, I usually 38377 run ~6 copies in parallel and expect to see a failure after within 38378 10mins. 38379 383802023-07-17 Mihails Strasuns <mihails.strasuns@intel.com> 38381 38382 gdb, infrun: refactor part of `proceed` into separate function 38383 Split the thread resuming code from proceed into new function 38384 proceed_resume_thread_checked. 38385 38386 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 38387 383882023-07-17 Andrew Burgess <aburgess@redhat.com> 38389 38390 gdb: fix an issue with vfork in non-stop mode 38391 This commit fixes a bug introduced by this commit: 38392 38393 commit d8bbae6ea080249c05ca90b1f8640fde48a18301 38394 Date: Fri Jan 14 15:40:59 2022 -0500 38395 38396 gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on) 38397 38398 The problem can be seen in this GDB session: 38399 38400 $ gdb -q 38401 (gdb) set non-stop on 38402 (gdb) file ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork 38403 Reading symbols from ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork... 38404 (gdb) tcatch vfork 38405 Catchpoint 1 (vfork) 38406 (gdb) run 38407 Starting program: /tmp/gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork 38408 38409 Temporary catchpoint 1 (vforked process 1375914), 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6 38410 (gdb) bt 38411 #0 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6 38412 #1 0x00000000004011af in main (argc=1, argv=0x7fffffffad88) at .../gdb/testsuite/gdb.base/foll-vfork.c:32 38413 (gdb) finish 38414 Run till exit from #0 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6 38415 [Detaching after vfork from child process 1375914] 38416 No unwaited-for children left. 38417 (gdb) 38418 38419 Notice the "No unwaited-for children left." error. This is incorrect, 38420 given where we are stopped there's no reason why we shouldn't be able 38421 to use "finish" to return to the main frame. 38422 38423 When the inferior is stopped as a result of the 'tcatch vfork', the 38424 inferior is in the process of performing the vfork, that is, GDB has 38425 seen the VFORKED event, but has not yet attached to the new child 38426 process, nor has the child process been resumed. 38427 38428 However, GDB has seen the VFORKED, and, as we are going to follow the 38429 parent process, the inferior for the vfork parent will have its 38430 thread_waiting_for_vfork_done member variable set, this will point to 38431 the one and only thread that makes up the vfork parent process. 38432 38433 When the "finish" command is used GDB eventually ends up in the 38434 proceed function (in infrun.c), in here we pass through all the 38435 function until we eventually encounter this 'else if' condition: 38436 38437 else if (!cur_thr->resumed () 38438 && !thread_is_in_step_over_chain (cur_thr) 38439 /* In non-stop, forbid resuming a thread if some other thread of 38440 that inferior is waiting for a vfork-done event (this means 38441 breakpoints are out for this inferior). */ 38442 && !(non_stop 38443 && cur_thr->inf->thread_waiting_for_vfork_done != nullptr)) 38444 { 38445 38446 The first two of these conditions will both be true, the thread is not 38447 already resumed, and is not in the step-over chain, however, the third 38448 condition, this one: 38449 38450 && !(non_stop 38451 && cur_thr->inf->thread_waiting_for_vfork_done != nullptr)) 38452 38453 is false, and this prevents the thread we are trying to finish from 38454 being resumed. This condition is false because (a) non_stop is true, 38455 and (b) cur_thr->inf->thread_waiting_for_vfork_done is not 38456 nullptr (see above for why). 38457 38458 Now, if we check the comment embedded within the condition it says: 38459 38460 /* In non-stop, forbid resuming a thread if some other thread of 38461 that inferior is waiting for a vfork-done event (this means 38462 breakpoints are out for this inferior). */ 38463 38464 And this makes sense, if we have a vfork parent with two thread, and 38465 one thread has performed a vfork, then we shouldn't try to resume the 38466 second thread. 38467 38468 However, if we are trying to resume the thread that actually performed 38469 a vfork, then this is fine. If we never resume the vfork parent then 38470 we'll never get a VFORK_DONE event, and so the vfork will never 38471 complete. 38472 38473 Thus, the condition should actually be: 38474 38475 && !(non_stop 38476 && cur_thr->inf->thread_waiting_for_vfork_done != nullptr 38477 && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr)) 38478 38479 This extra check will allow the vfork parent thread to resume, but 38480 prevent any other thread in the vfork parent process from resuming. 38481 This is the same condition that already exists in the all-stop on a 38482 non-stop-target block earlier in the proceed function. 38483 38484 My actual fix is slightly different to the above, first, I've chosen 38485 to use a nested 'if' check instead of extending the original 'else if' 38486 check, this makes it easier to write a longer comment explaining 38487 what's going on, and second, instead of checking 'non_stop' I've 38488 switched to checking 'target_is_non_stop_p'. In this context this is 38489 effectively the same thing, a previous 'else if' block in proceed 38490 already handles '!non_stop && target_is_non_stop_p ()', so by the time 38491 we get here, if 'target_is_non_stop_p ()' then we must be running in 38492 non_stop mode. 38493 38494 Both of these tweaks will make the next patch easier, which is a 38495 refactor to merge two parts of the proceed function, so this nested 38496 'if' block is not going to exist for long. 38497 38498 For testing, there is no test included with this commit. The test was 38499 exposed when using a modified version of the gdb.base/foll-vfork.exp 38500 test script, however, there are other bugs that are exposed when using 38501 the modified test script. These bugs will be addressed in subsequent 38502 commits, and then I'll add the updated gdb.base/foll-vfork.exp. 38503 38504 If you wish to reproduce this failure then grab the updates to 38505 gdb.base/foll-vfork.exp from the later commit and run this test, the 38506 failure is always reproducible. 38507 385082023-07-17 Andrew Burgess <aburgess@redhat.com> 38509 38510 gdb: don't restart vfork parent while waiting for child to finish 38511 While working on a later patch, which changes gdb.base/foll-vfork.exp, 38512 I noticed that sometimes I would hit this assert: 38513 38514 x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. 38515 38516 I eventually tracked it down to a combination of schedule-multiple 38517 mode being on, target-non-stop being off, follow-fork-mode being set 38518 to child, and some bad timing. The failing case is pretty simple, a 38519 single threaded application performs a vfork, the child process then 38520 execs some other application while the parent process (once the vfork 38521 child has completed its exec) just exits. As best I understand 38522 things, here's what happens when things go wrong: 38523 38524 1. The parent process performs a vfork, GDB sees the VFORKED event 38525 and creates an inferior and thread for the vfork child, 38526 38527 2. GDB resumes the vfork child process. As schedule-multiple is on 38528 and target-non-stop is off, this is translated into a request to 38529 start all processes (see user_visible_resume_ptid), 38530 38531 3. In the linux-nat layer we spot that one of the threads we are 38532 about to start is a vfork parent, and so don't start that 38533 thread (see resume_lwp), the vfork child thread is resumed, 38534 38535 4. GDB waits for the next event, eventually entering 38536 linux_nat_target::wait, which in turn calls linux_nat_wait_1, 38537 38538 5. In linux_nat_wait_1 we eventually call 38539 resume_stopped_resumed_lwps, this should restart threads that have 38540 stopped but don't actually have anything interesting to report. 38541 38542 6. Unfortunately, resume_stopped_resumed_lwps doesn't check for 38543 vfork parents like resume_lwp does, so at this point the vfork 38544 parent is resumed. This feels like the start of the bug, and this 38545 is where I'm proposing to fix things, but, resuming the vfork parent 38546 isn't the worst thing in the world because.... 38547 38548 7. As the vfork child is still alive the kernel holds the vfork 38549 parent stopped, 38550 38551 8. Eventually the child performs its exec and GDB is sent and EXECD 38552 event. However, because the parent is resumed, as soon as the child 38553 performs its exec the vfork parent also sends a VFORK_DONE event to 38554 GDB, 38555 38556 9. Depending on timing both of these events might seem to arrive in 38557 GDB at the same time. Normally GDB expects to see the EXECD or 38558 EXITED/SIGNALED event from the vfork child before getting the 38559 VFORK_DONE in the parent. We know this because it is as a result of 38560 the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see 38561 handle_vfork_child_exec_or_exit for details). Further the comment 38562 in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that 38563 when we remain attached to the child (not the parent) we should not 38564 expect to see a VFORK_DONE, 38565 38566 10. If both events arrive at the same time then GDB will randomly 38567 choose one event to handle first, in some cases this will be the 38568 VFORK_DONE. As described above, upon seeing a VFORK_DONE GDB 38569 expects that (a) the vfork child has finished, however, in this case 38570 this is not completely true, the child has finished, but GDB has not 38571 processed the event associated with the completion yet, and (b) upon 38572 seeing a VFORK_DONE GDB assumes we are remaining attached to the 38573 parent, and so resumes the parent process, 38574 38575 11. GDB now handles the EXECD event. In our case we are detaching 38576 from the parent, so GDB calls target_detach (see 38577 handle_vfork_child_exec_or_exit), 38578 38579 12. While this has been going on the vfork parent is executing, and 38580 might even exit, 38581 38582 13. In linux_nat_target::detach the first thing we do is stop all 38583 threads in the process we're detaching from, the result of the stop 38584 request will be cached on the lwp_info object, 38585 38586 14. In our case the vfork parent has exited though, so when GDB 38587 waits for the thread, instead of a stop due to signal, we instead 38588 get a thread exited status, 38589 38590 15. Later in the detach process we try to resume the threads just 38591 prior to making the ptrace call to actually detach (see 38592 detach_one_lwp), as part of the process to resume a thread we try to 38593 touch some registers within the thread, and before doing this GDB 38594 asserts that the thread is stopped, 38595 38596 16. An exited thread is not classified as stopped, and so the assert 38597 triggers! 38598 38599 So there's two bugs I see here. The first, and most critical one here 38600 is in step #6. I think that resume_stopped_resumed_lwps should not 38601 resume a vfork parent, just like resume_lwp doesn't resume a vfork 38602 parent. 38603 38604 With this change in place the vfork parent will remain stopped in step 38605 instead GDB will only see the EXECD/EXITED/SIGNALLED event. The 38606 problems in #9 and #10 are therefore skipped and we arrive at #11, 38607 handling the EXECD event. As the parent is still stopped #12 doesn't 38608 apply, and in #13 when we try to stop the process we will see that it 38609 is already stopped, there's no risk of the vfork parent exiting before 38610 we get to this point. And finally, in #15 we are safe to poke the 38611 process registers because it will not have exited by this point. 38612 38613 However, I did mention two bugs. 38614 38615 The second bug I've not yet managed to actually trigger, but I'm 38616 convinced it must exist: if we forget vforks for a moment, in step #13 38617 above, when linux_nat_target::detach is called, we first try to stop 38618 all threads in the process GDB is detaching from. If we imagine a 38619 multi-threaded inferior with many threads, and GDB running in non-stop 38620 mode, then, if the user tries to detach there is a chance that thread 38621 could exit just as linux_nat_target::detach is entered, in which case 38622 we should be able to trigger the same assert. 38623 38624 But, like I said, I've not (yet) managed to trigger this second bug, 38625 and even if I could, the fix would not belong in this commit, so I'm 38626 pointing this out just for completeness. 38627 38628 There's no test included in this commit. In a couple of commits time 38629 I will expand gdb.base/foll-vfork.exp which is when this bug would be 38630 exposed. Unfortunately there are at least two other bugs (separate 38631 from the ones discussed above) that need fixing first, these will be 38632 fixed in the next commits before the gdb.base/foll-vfork.exp test is 38633 expanded. 38634 38635 If you do want to reproduce this failure then you will for certainly 38636 need to run the gdb.base/foll-vfork.exp test in a loop as the failures 38637 are all very timing sensitive. I've found that running multiple 38638 copies in parallel makes the failure more likely to appear, I usually 38639 run ~6 copies in parallel and expect to see a failure after within 38640 10mins. 38641 386422023-07-17 Andrew Burgess <aburgess@redhat.com> 38643 38644 gdb: catch more errors in gdb.base/foll-vfork.exp 38645 For *reasons* I was looking at gdb.base/foll-vfork.exp. This test 38646 script has a proc 'setup_gdb' that could (potentially) fail. The 38647 setup_gdb proc is called from many places and I, initially, didn't 38648 think that we were checking if setup_gdb had failed or not. 38649 38650 My confusion was because I didn't understand what this tcl construct 38651 did: 38652 38653 return -code return 38654 38655 this will actually act as a return in the context of a proc's caller, 38656 effectively returning two levels of the call stack. Neat (I guess). 38657 38658 So it turns out my worries were misplaced, everywhere setup_gdb is 38659 called, if setup_gdb fails then we will (magically) return. 38660 38661 However, I did spot one place where we managed to confuse ourselves 38662 with our cleverness. 38663 38664 In check_vfork_catchpoints, this proc is called to check that GDB is 38665 able to catch vforks or not. This proc is called early in the test 38666 script, and the intention is that, should this proc fail, we'll mark 38667 the whole test script as unsupported and then move onto the next test 38668 script. 38669 38670 However, check_vfork_catchpoints also uses setup_gdb, and so, if that 38671 call to setup_gdb fails we'll end up returning immediately from 38672 check_vfork_catchpoints, and then continue with the test of _this_ 38673 test script, which is not correct. 38674 38675 To fix this I see two choices, one is remove the use of 'return -code 38676 return' from setup_gdb, however, this would require every use of 38677 setup_gdb to then be placed inside: 38678 38679 if { ![setup_gdb] } { 38680 return 38681 } 38682 38683 Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints 38684 and check its return code. 38685 38686 I chose the second option as this is the smaller code change. 38687 38688 There should be no change in what is tested after this commit. 38689 386902023-07-17 GDB Administrator <gdbadmin@sourceware.org> 38691 38692 Automatic date update in version.in 38693 386942023-07-16 Alan Modra <amodra@gmail.com> 38695 38696 PR10957, Missing option to really print section+offset 38697 Many of the reloc error messages have already been converted from 38698 using %C to using %H in ld.bfd, to print section+offset as well as 38699 file/line/function. This catches a few remaining, and changes gold to 38700 do the same. 38701 38702 PR 10957 38703 bfd/ 38704 * elf32-sh.c (sh_elf_relocate_section): Use %H in error messages. 38705 gold/ 38706 * object.cc (Relocate_info::location): Always report section+offset. 38707 * testsuite/debug_msg.sh: Adjust to suit. 38708 * testsuite/x32_overflow_pc32.sh: Likewise. 38709 * testsuite/x86_64_overflow_pc32.sh: Likewise. 38710 ld/ 38711 * emultempl/pe.em (read_addend): Use %H in error message. 38712 * emultempl/pep.em (read_addend): Likewise. 38713 * ldcref.c (check_reloc_refs): Likewise. 38714 * ldmain.c (warning_find_reloc, undefined_symbol): Likewise. 38715 * pe-dll.c (pe_create_import_fixup): Likewise. 38716 * testsuite/ld-cris/undef2.d: Adjust expected output to suit. 38717 * testsuite/ld-cris/undef3.d: Likewise. 38718 * testsuite/ld-elf/shared.exp: Likewise. 38719 * testsuite/ld-i386/compressed1.d: Likewise. 38720 * testsuite/ld-ia64/line.exp: Likewise. 38721 * testsuite/ld-plugin/lto.exp: Likewise. 38722 * testsuite/ld-undefined/undefined.exp: Likewise. 38723 * testsuite/ld-x86-64/compressed1.d: Likewise. 38724 * testsuite/ld-x86-64/line.exp: Likewise. 38725 * testsuite/ld-x86-64/pr27587.err: Likewise. 38726 387272023-07-16 Alan Modra <amodra@gmail.com> 38728 38729 Support NEXT_SECTION in ALIGNOF and SIZEOF 38730 This patch is aimed at making __bss_start properly aligned with the 38731 first of any bss-style sections following. Most of the work here 38732 involves keeping track of the last output section seen when processing 38733 the linker script. 38734 38735 You can almost align __bss_start properly by using 38736 ${RELOCATING+. = ALIGN(${DATA_SDATA-${NO_SMALL_DATA-ALIGNOF(.${SBSS_NAME}) != 0 ? ALIGNOF(.${SBSS_NAME}) : }}${BSS_PLT+ALIGNOF(.plt) != 0 ? ALIGNOF(.plt) : }ALIGNOF(.${BSS_NAME}));} 38737 and changing every place that defines NO_SMALL_DATA to use " ", but 38738 having two .plt sections (marked SPECIAL) on some backends foils that 38739 idea. The problem is that you only want to pick up the following 38740 .plt, not the one preceeding __bss_start in the data segment if the 38741 backend decides that is the proper .plt section. 38742 38743 Perhaps that could be fixed too, but I decided instead to extend the 38744 linker script a little. THIS_SECTION and PREV_SECTION could easily be 38745 added too. 38746 38747 * ld.texi (ALIGNOF, SIZEOF): Update and mention NEXT_SECTION. 38748 * ldexp.c (output_section_find): New function. 38749 (fold_name <ALIGNOF, SIZEOF>): Use output_section_find. 38750 (exp_fold_tree): Add os parameter. Adjust all calls. 38751 (exp_fold_tree_no_dot, exp_get_vma, exp_get_power): Likewise. 38752 * ldexp.h (struct ldexp_control): Add last_os. 38753 (exp_fold_tree, exp_fold_tree_no_dot): Update prototypes. 38754 (exp_get_vma, exp_get_power): Likewise. 38755 * ldlang.c: Pass last output section to expression folder 38756 calls throughout file. 38757 (open_input_bfds): Add os parameter to track last os seen. 38758 (lang_size_sections_1): Rename output_section_statement param 38759 to current_os. Track last os. 38760 (lang_do_assignments_1): Track last os. 38761 * scripttempl/arclinux.sc: Align to ALIGNOF NEXT_SECTION 38762 before defining __bss_start. 38763 * scripttempl/elf.sc: Likewise. 38764 * scripttempl/elf64bpf.sc: Likewise. 38765 * scripttempl/elf64hppa.sc: Likewise. 38766 * scripttempl/elf_chaos.sc: Likewise. 38767 * scripttempl/elfarc.sc: Likewise. 38768 * scripttempl/elfd10v.sc: Likewise. 38769 * scripttempl/elfxtensa.sc: Likewise. 38770 * scripttempl/epiphany_4x4.sc: Likewise. 38771 * scripttempl/iq2000.sc: Likewise. 38772 * scripttempl/mep.sc: Likewise. 38773 * scripttempl/nds32elf.sc: Likewise. 38774 * scripttempl/xstormy16.sc: Likewise. 38775 * testsuite/ld-x86-64/pe-x86-64-5.od: Update expected __bss_start. 38776 * testsuite/ld-x86-64/pe-x86-64-5.rd: Likewise. 38777 387782023-07-16 Tom de Vries <tdevries@suse.de> 38779 38780 [gdb/testsuite] Handle has_native_target in gdb.testsuite/gdb-caching-proc-consistency.exp 38781 With test-case gdb.testsuite/gdb-caching-proc-consistency.exp we run into: 38782 ... 38783 ERROR: no fileid for xerxes 38784 Couldn't send help target native to GDB. 38785 UNRESOLVED: <exp>: have_native_target: initial: help target native 38786 ... 38787 38788 Fix this by handling have_native_target in 38789 gdb.testsuite/gdb-caching-proc-consistency.exp. 38790 38791 Tested on x86_64-linux. 38792 387932023-07-16 GDB Administrator <gdbadmin@sourceware.org> 38794 38795 Automatic date update in version.in 38796 387972023-07-15 Andrew Burgess <aburgess@redhat.com> 38798 38799 gdb/tui: make tui_win_info::title private 38800 This commit builds on this earlier work: 38801 38802 commit 9fe01a376b2fb096e4836e985ba316ce9dc02399 38803 Date: Thu Jun 29 11:26:55 2023 -0600 38804 38805 Update TUI window title when changed 38806 38807 and makes tui_win_info::title private, renaming to m_title at the same 38808 time. There's a new tui_win_info::title() member function to provide 38809 read-only access to the title. 38810 38811 There should be no user visible changes after this commit. 38812 38813 Approved-By: Tom Tromey <tom@tromey.com> 38814 388152023-07-15 Andrew Burgess <aburgess@redhat.com> 38816 38817 gdb: style filenames in separate debug file warnings 38818 After the commit: 38819 38820 commit 6647f05df023b63bbe056e9167e9e234172fa2ca 38821 Date: Tue Jan 24 18:13:38 2023 +0100 38822 38823 gdb: defer warnings when loading separate debug files 38824 38825 It was pointed out[1] that the warnings being deferred and then later 38826 emitted lacked styling. The warnings lacked styling before the above 38827 commit, but it was suggested that the filenames in these warnings 38828 should be styled, and this commit does this. 38829 38830 There were a couple of previous attempts[2][3][4] to solve this 38831 problem, but these all tried to extend the mechanism introduced in the 38832 above commit, the deferred warnings were placed directly into a 38833 std::vector, but now we tried to, when appropriate, style these 38834 warnings. The review feedback that this approach looked too complex. 38835 38836 So instead, this revision adds a new helper class 'deferred_warnings' 38837 which can be used to collect a set of deferred warnings, and then emit 38838 these deferred warnings later, if needed. This helper class hides the 38839 complexity, so at the point the deferred warning is created no extra 38840 logic is required. 38841 38842 The deferred_warnings class will style the deferred warnings only if 38843 gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr, 38844 so this should ensure we only style when expected. 38845 38846 There was also review feedback[5] that all of the warnings should be 38847 bundled into a single string_file, this has not been done. I feel 38848 pretty strongly that separate warnings should be emitted using 38849 separate "warning" calls. If we do end up with multiple warnings in 38850 this case they aren't really related, one will be about looking up 38851 debug via .gnu_debuglink, while the other will be about build-id based 38852 lookup. So I'd really rather keep the warnings separate. 38853 38854 [1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/ 38855 [2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/ 38856 [3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/ 38857 [4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/ 38858 [5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/ 38859 38860 Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com> 38861 Approved-By: Simon Marchi <simon.marchi@efficios.com> 38862 388632023-07-15 Tom de Vries <tdevries@suse.de> 38864 38865 [gdb/testsuite] Fix gdb.dwarf2/forward-spec.exp with read1 38866 When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run 38867 into: 38868 ... 38869 parent: ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent 38870 7fdc1c002ed0) [ns]^M 38871 ... 38872 38873 The problem is using regexps containing '.' to avoid escaping, which makes 38874 them too generic. 38875 38876 Fix this by eliminating the '.' from the regexps. 38877 38878 Tested on x86_64-linux. 38879 388802023-07-15 GDB Administrator <gdbadmin@sourceware.org> 38881 38882 Automatic date update in version.in 38883 388842023-07-14 Tom Tromey <tromey@adacore.com> 38885 38886 Use correct inferior in Inferior.read_memory et al 38887 A user noticed that Inferior.read_memory and a few other Python APIs 38888 will always use the currently selected inferior, not the one passed to 38889 the call. 38890 38891 This patch fixes the bug by arranging to switch to the inferior. I 38892 found this same issue in several APIs, so this fixes them all. 38893 38894 I also added a few missing calls to INFPY_REQUIRE_VALID to these 38895 methods. 38896 38897 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30615 38898 Approved-By: Pedro Alves <pedro@palves.net> 38899 389002023-07-14 Tom Tromey <tromey@adacore.com> 38901 38902 Introduce scoped_restore_current_inferior_for_memory 38903 This introduces a new class, 38904 scoped_restore_current_inferior_for_memory, and arranges to use it in 38905 a few places. This class is intended to handle setting up and 38906 restoring the various globals that are needed to read or write memory 38907 -- but without invalidating the frame cache. 38908 38909 I wasn't able to test the change to aix-thread.c. 38910 38911 Approved-By: Pedro Alves <pedro@palves.net> 38912 389132023-07-14 Tom Tromey <tromey@adacore.com> 38914 38915 Remove obsolete comment from gdbthread.h 38916 A comment in gdbthread.h refers to a global that no longer exists. 38917 38918 Approved-By: Pedro Alves <pedro@palves.net> 38919 389202023-07-14 Tom Tromey <tromey@adacore.com> 38921 38922 Rename Python variable in py-inferior.exp 38923 py-inferior.exp creates a Python variable named 'str'. This clashes 38924 with the built-in type of the same name and can be confusing when 38925 trying to evaluate Python code when debugging the test case. This 38926 patch renames it. 38927 38928 Approved-By: Pedro Alves <pedro@palves.net> 38929 389302023-07-14 Tom Tromey <tromey@adacore.com> 38931 38932 Refactor py-inferior.exp 38933 This changes py-inferior.exp to make it a bit more robust when adding 38934 new inferiors during the course of the test. 38935 38936 Approved-By: Pedro Alves <pedro@palves.net> 38937 389382023-07-14 Tom Tromey <tromey@adacore.com> 38939 38940 Minor cleanups in py-inferior.exp 38941 While working on this series, I noticed a some oddities in 38942 py-inferior.exp. One is an obviously incorrect comment, and the 38943 others are confusing test names. This patch fixes these. 38944 38945 Approved-By: Pedro Alves <pedro@palves.net> 38946 389472023-07-14 Tom Tromey <tromey@adacore.com> 38948 38949 Revert "Simplify auto_load_expand_dir_vars and remove substitute_path_component" 38950 This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489. 38951 38952 This commit was a refactoring to remove an xrealloc and simplify 38953 utils.[ch]. However, it has a flaw -- it mishandles a substitution 38954 like "$datadir/subdir". 38955 38956 I am backing out the patch in the interests of fixing the regression 38957 before GDB 14. It can be reinstated (with modifications) later if we 38958 like. 38959 38960 Regression tested on x86-64 Fedora 36. 38961 389622023-07-14 John Baldwin <jhb@FreeBSD.org> 38963 38964 Test that native targets can read a tdesc without a process attached. 38965 This ensures that 'unset tdesc filename' does not generate any output 38966 on a "bare" native target inferior without an attached process. 38967 38968 Add a have_native_target helper function for use with require. 38969 Move logic from auto-connect-native-target.exp into this helper. 38970 389712023-07-14 John Baldwin <jhb@FreeBSD.org> 38972 38973 *-linux-nat: Handle null inferior in read_description. 38974 Don't invoke ptrace in the target read_description method if there is 38975 not an active inferior to query via ptrace. Instead, use the default 38976 register set for the architecture. 38977 38978 Previously the native target could report an error from a failed 38979 ptrace operation when fetching a tdesc without an attached process. 38980 For example on Linux x86-64: 38981 38982 (gdb) target native 38983 Done. Use the "run" command to start a process. 38984 (gdb) unset tdesc filename 38985 Couldn't get CS register: No such process. 38986 389872023-07-14 John Baldwin <jhb@FreeBSD.org> 38988 38989 *-fbsd-nat: Handle null inferior in read_description. 38990 Don't invoke ptrace in the target read_description method if there is 38991 not an active inferior to query via ptrace. Instead, use the default 38992 register set for the architecture. 38993 38994 Previously the native target could report an error from a failed 38995 ptrace operation when fetching a tdesc without an attached process. 38996 For example on FreeBSD/amd64: 38997 38998 (gdb) target native 38999 Done. Use the "run" command to start a process. 39000 (gdb) unset tdesc filename 39001 Couldn't get registers: Operation not permitted. 39002 390032023-07-14 Tobias Burnus <tobias@codesourcery.com> 39004 39005 Re: Let '^' through the lexer 39006 Fix "make pdf". 39007 390082023-07-14 Bruno Larsen <blarsen@redhat.com> 39009 39010 gdb/doc: document '+' argument for 'list' command 39011 The command 'list' has accepted the argument '+' for many years already, 39012 but this option wasn't documented either in the texinfo docs or in the 39013 help text for the command. This commit documents it. 39014 39015 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 39016 Approved-By: Tom Tromey <tom@tromey.com> 39017 390182023-07-14 Bruno Larsen <blarsen@redhat.com> 39019 39020 gdb/cli: Improve UX when using list with no args 39021 When using "list" with no arguments, GDB will first print the lines 39022 around where the inferior is stopped, then print the next N lines until 39023 reaching the end of file, at which point it warns the user "Line X out 39024 of range, file Y only has X-1 lines.". This is usually desirable, but 39025 if the user can no longer see the original line, they may have forgotten 39026 the current line or that a list command was used at all, making GDB's 39027 error message look cryptic. It was reported in bugzilla as PR cli/30497. 39028 39029 This commit improves the user experience by changing the behavior of 39030 "list" slightly when a user passes no arguments. It now prints that the 39031 end of the file has been reached and recommends that the user use the 39032 command "list ." instead. 39033 39034 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497 39035 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 39036 Approved-By: Tom Tromey <tom@tromey.com> 39037 390382023-07-14 Bruno Larsen <blarsen@redhat.com> 39039 39040 gdb/cli: add '.' as an argument for 'list' command 39041 Currently, after the user has used the list command once, there is no 39042 self-contained way to ask GDB to print the location where the inferior is 39043 stopped. The current best options require either using a separate 39044 command to scope out where the inferior is stopped, or using "list *$pc" 39045 requiring knowledge of GDB standard registers. This commit adds a way 39046 to do that using '.' as a new argument for the 'list' command. If the 39047 inferior isn't running, the command prints around the main function. 39048 39049 Because this necessitated having the inferior running and the test was 39050 (seemingly unnecessarily) using printf in a non-essential way and it 39051 would make the resulting log harder to read for no benefit, it was 39052 replaced by a different statement. 39053 39054 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 39055 Approved-By: Tom Tromey <tom@tromey.com> 39056 390572023-07-14 Bruno Larsen <blarsen@redhat.com> 39058 39059 gdb/cli: Factor out code to list lines around a given line 39060 A future patch will add more situations that calculates "lines around a 39061 certain point" to be printed using print_source_lines, and the logic 39062 could be re-used. As a preparation for those commits, this one factors 39063 out that part of the logic of the list command into its own function. 39064 No functional changes are expected 39065 39066 Approved-By: Tom Tromey <tom@tromey.com> 39067 390682023-07-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 39069 39070 gprofng: 30602 [2.41] gprofng test hangs on i686-linux-gnu 39071 There were several problems in the gprofng testing: 39072 - we did not catch a timeout for each test. 39073 - we used exit() to stop a failed test. But this stops all other tests. 39074 - we used a time_t (long) type in smalltest.c instead of a long long type. 39075 39076 PR gprofng/30602 39077 * configure.ac: Launch only native testing. 39078 * configure: Rebuild. 39079 * testsuite/config/default.exp: Set TEST_TIMEOUT. 39080 * testsuite/gprofng.display/setpath_map.exp: Use return instead of exit. 39081 * testsuite/gprofng.display/gp-archive.exp: Likewise. 39082 * testsuite/gprofng.display/gp-collect-app_F.exp: Likewise. 39083 * testsuite/gprofng.display/display.exp: Delete an unnecessary test 39084 for native testing. 39085 * testsuite/lib/display-lib.exp (run_native_host_cmd): Add timeout. 39086 * testsuite/lib/smalltest.c: Use a long long type instead of time_t. 39087 390882023-07-14 Alan Modra <amodra@gmail.com> 39089 39090 Make the default gas symbol hash table larger 39091 We may as well start with the symbol table a little larger, saving 39092 time resizing. Even a simple C hello world compiled with -O2 -g will 39093 exceed 16 symbols (by well over 3 times with gcc-11). 39094 39095 * symbols.c (symbol_begin): Create sy_hash with more entries. 39096 390972023-07-14 Alan Modra <amodra@gmail.com> 39098 39099 Fix loongarch build with gcc-4.5 39100 * loongarch-opc.c (loongarch_alias_opcodes): Don't trigger 39101 gcc-4.5 bug in handling of struct initialisation. 39102 391032023-07-14 Alan Modra <amodra@gmail.com> 39104 39105 More tidies to objcopy archive handling 39106 This makes sure copy_archive exits with ibfd and obfd closed. Error 39107 paths didn't do that, leading to memory leaks. None of this matters 39108 very much. 39109 39110 * objcopy.c (copy_archive): bfd_close ibfd and obfd on error 39111 return paths. Remove braces around "list" free. 39112 (copy_file): Don't close invalid file descriptor. 39113 391142023-07-14 Alan Modra <amodra@gmail.com> 39115 39116 AIX_WEAK_SUPPORT 39117 Making target code depend on a host define like _AIX52 is never 39118 correct, so out it goes. Also, sort some config.bfd entries a little 39119 to make it more obvious there is a config difference between aix5.1 39120 and aix5.2. These two changes should make no difference to anything 39121 in binutils. The gas define of AIX_WEAK_SUPPORT on the other hand was 39122 wrong, so fix that. Finally, fix some testsuite fails on aix < 5.2 by 39123 simply not running the tests. 39124 39125 include/ 39126 * coff/internal.h (C_WEAKEXT): Don't depend on _AIX52. 39127 bfd/ 39128 * coffcode.h (coff_slurp_symbol_table): Don't depend on _AIX52. 39129 (coff_classify_symbol): Likewise. 39130 * config.bfd: Sort some entries. 39131 gas/ 39132 * configure.ac (AIX_WEAK_SUPPORT): Don't set for aix5.[01]. 39133 * configure: Regenerate. 39134 * testsuite/gas/ppc/aix.exp (xcoff-visibility-1*) Don't run 39135 for aix < 5.2. 39136 391372023-07-14 GDB Administrator <gdbadmin@sourceware.org> 39138 39139 Automatic date update in version.in 39140 391412023-07-13 Tom Tromey <tromey@adacore.com> 39142 39143 Implement 'Enum_Val and 'Enum_Rep 39144 This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep. 39145 39146 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 39147 391482023-07-13 Tom Tromey <tromey@adacore.com> 39149 39150 Remove ada_attribute_name 39151 ada_attribute_name uses an array that must be kept in sync with an 39152 enum -- but the comment here refers to an enum that no longer exists. 39153 Looking at the sole caller, I see this can only be called for two 39154 opcodes. So, remove this entirely and inline it. 39155 391562023-07-13 Michael Matz <matz@suse.de> 39157 39158 Let '^' through the lexer 39159 so that the (existing) code in parser and expression evaluator 39160 actually get to see it and handle it as XOR. Also adjust docu 39161 to match what's there. 39162 391632023-07-13 Alan Modra <amodra@gmail.com> 39164 39165 elf_object_p load of dynamic symbols 39166 This fixes an uninitialised memory access on a fuzzed file: 39167 0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2 39168 1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13 39169 2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9 39170 39171 Hopefully it will also stop any attempt to load dynamic symbols from 39172 eu-strip debug files. 39173 39174 * elfcode.h (elf_object_p): Do not attempt to load dynamic 39175 symbols for a file with no section headers until all the 39176 program headers are swapped in. Do not fail on eu-strip debug 39177 files. 39178 391792023-07-13 GDB Administrator <gdbadmin@sourceware.org> 39180 39181 Automatic date update in version.in 39182 391832023-07-12 Tom de Vries <tdevries@suse.de> 39184 39185 [gdb/tui] Assume HAVE_WBORDER 39186 The tui border-kind setting allows values acs, ascii and space. 39187 39188 The values ascii and space however don't work well with !HAVE_WBORDER. 39189 39190 Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix 39191 support, which is now obsolete. 39192 39193 Tested on x86_64-linux. 39194 39195 PR tui/30580 39196 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580 39197 39198 Approved-By: Tom Tromey <tom@tromey.com> 39199 392002023-07-12 Tom de Vries <tdevries@suse.de> 39201 39202 [gdb/tui] Make translate return entry->value instead of entry 39203 The only use of "entry = translate (...)" is entry->value. 39204 39205 Simplify using the function by returning entry->value instead. 39206 39207 Tested on x86_64-linux. 39208 39209 Approved-By: Tom Tromey <tom@tromey.com> 39210 392112023-07-12 Tom de Vries <tdevries@suse.de> 39212 39213 [gdb/tui] Merge tui border-kind corner translation tables 39214 The tables: 39215 - tui_border_kind_translate_ulcorner 39216 - tui_border_kind_translate_urcorner 39217 - tui_border_kind_translate_llcorner 39218 - tui_border_kind_translate_lrcorner 39219 are identical. 39220 39221 Merge and rename to tui_border_kind_translate_corner. 39222 39223 Tested on x86_64-linux. 39224 39225 Approved-By: Tom Tromey <tom@tromey.com> 39226 392272023-07-12 Tom de Vries <tdevries@suse.de> 39228 39229 [gdb/tui] Introduce translate_acs 39230 In function tui_update_variables we have the somewhat inconvenient: 39231 ... 39232 entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner); 39233 int val = (entry->value < 0) ? ACS_LRCORNER : entry->value; 39234 ... 39235 39236 Add a new function translate_acs, that allows us to do the more straighforward: 39237 ... 39238 int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner, 39239 ACS_LRCORNER); 39240 ... 39241 39242 By special-casing "acs" in translate_acs, we can now remove the acs entries 39243 from the translation tables. 39244 39245 Tested on x86_64-linux. 39246 39247 Approved-By: Tom Tromey <tom@tromey.com> 39248 392492023-07-12 Tom de Vries <tdevries@suse.de> 39250 39251 [gdb/tui] Remove default entries in TUI translation tables 39252 The TUI translation tables contain default entries at the end: 39253 ... 39254 static struct tui_translate tui_border_kind_translate_hline[] = { 39255 { "space", ' ' }, 39256 { "ascii", '-' }, 39257 { "acs", -1 }, 39258 { 0, 0 }, 39259 { "ascii", '-' } 39260 }; 39261 ... 39262 39263 A simpler way of implementing this would be to to declare the first (or last) 39264 entry the default, but in fact these default entries are not used. 39265 39266 Make this explicit by removing the default entries, and asserting in translate 39267 that an entry will always be found. 39268 39269 Tested on x86_64-linux. 39270 39271 Approved-By: Tom Tromey <tom@tromey.com> 39272 392732023-07-12 Alan Modra <amodra@gmail.com> 39274 39275 .noinit and .persistent for msp430 39276 Similar to the previous patch, but also tidy a few more sections. 39277 39278 * scripttempl/elf32msp430.sc (.text, .rodata, .data, .bss, .noinit), 39279 (.persistent): Align the section rather than aligning inside. 39280 392812023-07-12 Alan Modra <amodra@gmail.com> 39282 39283 .noinit and .persistent alignment 39284 It's more elegant to make the section match up with its "_start" 39285 symbol. We could align by setting the address of the section (by 39286 using ALIGN before the colon), but this way we also set sh_addralign 39287 to at least $ALIGNMENT. 39288 39289 * scripttempl/elf.sc (.noinit, .persistent): Align the output 39290 section rather than using ". = ALIGN();" at the beginning. 39291 Set address to zero when not a final link. 39292 392932023-07-12 Alan Modra <amodra@gmail.com> 39294 39295 Re: Align linkerscript symbols according to ABI 39296 Align dot before symbols defined outside of output sections. Before _end 39297 is already aligned. 39298 39299 * scripttempl/elf.sc (def_symbol): Tidy excess space. 39300 (_edata): Align before emitting symbol when SYMBOL_ABI_ALIGNMENT. 39301 393022023-07-12 Alan Modra <amodra@gmail.com> 39303 39304 Re: Keeping track of rs6000-coff archive element pointers 39305 bfd/ 39306 * coff-rs6000.c (add_range): Revise comment, noting possible fail. 39307 (_bfd_xcoff_openr_next_archived_file): Start with clean ranges. 39308 binutils/ 39309 * bfdtest1.c: Enhance to catch errors on second scan. 39310 393112023-07-12 GDB Administrator <gdbadmin@sourceware.org> 39312 39313 Automatic date update in version.in 39314 393152023-07-11 Tom Tromey <tromey@adacore.com> 39316 39317 Remove some TODOs from gdb.cp tests 39318 This patch removes many TODOs from the gdb.cp tests. 39319 Going through the patch: 39320 39321 * bs15503.exp - these have been commented out forever and rely on 39322 libstdc++ debuginfo. It's better to just remove these. 39323 39324 * classes.exp - the test is wrong, I think, according to the C++ ABI 39325 that gdb understands; and the test can be fixed and comments removed 39326 with a simple change to the code. 39327 39328 * ctti.exp - there's no need to bail out any more, as the test works. 39329 39330 * exception.exp - the code relying on the line numbers can't work, 39331 because gdb never prints that message anyway. 39332 39333 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 39334 393352023-07-11 Jan Beulich <jbeulich@suse.com> 39336 39337 x86: simplify table-referencing macros 39338 First of all it is entirely unclear why THREE_BYTE_TABLE_PREFIX() was 39339 introduced by bf890a93a7c4. Nothing uses the .prefix_requirement values 39340 from the two relevant entries. 39341 39342 And then having VEX_Cn_TABLE() and friends take arguments is misleading. 39343 These aren't used (or pointlessly used in the case of VEX_C5_TABLE); the 39344 respective table index is decoded from the insn (or implied in the case 39345 of VEX_C5_TABLE). 39346 393472023-07-11 Jan Beulich <jbeulich@suse.com> 39348 39349 x86: convert 0FXOP to just XOP in enumerator names 39350 There's nothing 0f-ish in XOP encodings. 39351 393522023-07-11 Jan Beulich <jbeulich@suse.com> 39353 39354 x86: misc further register-only insns don't need to go through mod_table[] 39355 Several already use OP_R(), which rejects the memory forms of insns, and 39356 a few others can easily be converted to do so as well. Note that for it 39357 to be able to use BadOp() without forward declaration, OP_Skip_MODRM() is 39358 moved down. 39359 39360 While there add the previously missing PREFIX_OPCODE to legacy opcode 39361 0FD7. 39362 393632023-07-11 Jan Beulich <jbeulich@suse.com> 39364 39365 x86: various operations on mask registers can avoid going through mod_table[] 39366 Now that we have OP_R(), use it here as well, while wiring memory-only 39367 operands to OP_M() at the same time. To keep the number of consumed 39368 opcode bytes similar to before, make BadOp() also account for VEX/XOP/ 39369 EVEX prefix bytes. To keep that change simple, convert need_vex to an 39370 actual count of prefix bytes (keeping intact all prior boolean uses of 39371 the field). 39372 39373 Note how this improves disassembly of such bad encodings, by at least 39374 leaving a hint towards what a "nearby" instruction is. (For KSHIFT* 39375 change the immediates test testcases use, such that disassembly remains 39376 sufficiently in sync.) 39377 39378 While there also use Ux for VPMOV{B,W,D,Q}2M, where decoding through 39379 mod_table[] was missing in the earlier scheme. 39380 393812023-07-11 Jan Beulich <jbeulich@suse.com> 39382 39383 x86: slightly rework handling of some register-only insns 39384 Fold OP_MS() and OP_XS() into OP_R(), paralleling OP_M(). Use operand 39385 names (largely) matching those in the SDM. For 128-bit-only forms use 39386 Uxmm though, marking 256-bit forms as bad. This then allows no longer 39387 going through vex_len_table[] for two of the insns. 39388 39389 Specifically _do not_ continue to mis-use v_mode. 39390 393912023-07-11 Jan Beulich <jbeulich@suse.com> 39392 39393 x86: SIMD shift-by-immediate don't need to go through mod_table[] 39394 OP_MS() and OP_XS() reject memory forms of insns quite fine. This then 39395 also eliminates mis-named enumerators (we use M_1 for register forms). 39396 393972023-07-11 Jan Beulich <jbeulich@suse.com> 39398 39399 x86: misc further memory-only insns don't need to go through mod_table[] 39400 Several already use OP_M(), which rejects the register forms of insns, 39401 and a few others can easily be converted to do so as well. (Note that 39402 FXSAVE_Fixup() wires through to OP_M(). Note further that OP_IndirE(), 39403 which wasn't placed very well anyway, is moved down to avoid the need to 39404 forward-declare BadOp().) 39405 39406 Also adjust formatting of and drop PREFIX_OPCODE from a few adjacent 39407 entries. 39408 394092023-07-11 Jan Beulich <jbeulich@suse.com> 39410 39411 x86: {,V}MOVNT* don't need to go through mod_table[] 39412 Most of them use Mx already for the memory operand, which rejects the 39413 register form of the insn. Use that operand type also for the two EVEX 39414 forms which so far have used EXEvexXNoBcst (and thus failed to reject 39415 the register forms), compensating by flagging broadcast as bad for all 39416 Mx. This way several other insns which don't permit embedded broadcast 39417 either are also covered at the same time. 39418 39419 x86: fold legacy/VEX {,V}MOV{H,L}* entries 39420 By changing decode order to do ModR/M.mod last (rather than VEX.L), the 39421 VEX entries (which are already reused by EVEX decoding) can be folded 39422 with their legacy counterparts as well. Note how this change of decode 39423 order also allows removing two auxiliary #define-s, which were 39424 introduced during earlier folding (because of that unhelpful order of 39425 steps). 39426 39427 x86: fold certain legacy/VEX table entries 39428 Introduce macro V to expand to 'v' in the VEX/EVEX case, and replace a 39429 couple of abort()s where legacy code can now legitimately make it. While 39430 there for {,V}LDDQU drop hoing through mod_table[] - OP_M() rejects 39431 register operands quite fine. 39432 39433 ld/PDB: fix off-by-1 in add_globals_ref() 39434 Copying one too many bytes can corrupt memory, detected/reported by 39435 glibc on a 32-bit distro. 39436 394372023-07-11 GDB Administrator <gdbadmin@sourceware.org> 39438 39439 Automatic date update in version.in 39440 394412023-07-10 Tom Tromey <tom@tromey.com> 39442 39443 Remove target_close 39444 I noticed that target_close is only called in two places: 39445 solib-svr4.c, and target_ops_ref_policy::decref. 39446 39447 This patch fixes the former by changing target_bfd_reopen to return a 39448 target_ops_up and then fixing the sole caller. Then it removes 39449 target_close by inlining its body into the decref method. 39450 39451 The advantage of this approach is that targets are now automatically 39452 managed. 39453 39454 Regression tested on x86-64 Fedora 38. 39455 39456 Approved-By: Andrew Burgess <aburgess@redhat.com> 39457 394582023-07-10 Tom Tromey <tom@tromey.com> 39459 39460 Update TUI window title when changed 39461 I wrote a TUI window in Python, and I noticed that setting its title 39462 did not result in a refresh, so the new title did not appear. This 39463 patch corrects this problem. 39464 394652023-07-10 Tom Tromey <tromey@adacore.com> 39466 39467 Add Ada scope test for DAP 39468 This adds a DAP test for fetching scopes and variables with an Ada 39469 program. This test is the reason that the FrameVars code does not 39470 check is_constant on the symbols it returns. 39471 39472 Note that this test also shows that string-printing is incorrect in 39473 Ada. This is a known bug but I'm still considering how to fix it. 39474 394752023-07-10 Tom Tromey <tromey@adacore.com> 39476 39477 Handle typedefs in no-op pretty printers 39478 The no-ops pretty-printers that were introduced for DAP have a classic 39479 gdb bug: they neglect to call check_typedef. This will cause some 39480 strange behavior; for example not showing the children of a variable 39481 whose type is a typedef of a structure type. This patch fixes the 39482 oversight. 39483 394842023-07-10 Tom Tromey <tromey@adacore.com> 39485 39486 Reimplement DAP stack traces using frame filters 39487 This reimplements DAP stack traces using frame filters. This slightly 39488 simplifies the code, because frame filters and DAP were already doing 39489 some similar work. This also renames RegisterReference and 39490 ScopeReference to make it clear that these are private (and so changes 39491 don't have to worry about other files). 39492 39493 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30468 39494 394952023-07-10 Tom Tromey <tromey@adacore.com> 39496 39497 Simplify FrameVars 39498 FrameVars implements its own variant of Symbol.is_variable. This 39499 patch replaces this code. 39500 395012023-07-10 Tom Tromey <tromey@adacore.com> 39502 39503 Fix oversights in frame decorator code 39504 The frame decorator "FrameVars" code misses a couple of cases, 39505 discovered when working on related DAP changes. 39506 39507 First, fetch_frame_locals does not stop when reaching a function 39508 boundary. This means it would return locals from any enclosing 39509 functions. 39510 39511 Second, fetch_frame_args assumes that all arguments are at the 39512 outermost scope, but this doesn't seem to be required by gdb. 39513 395142023-07-10 Tom Tromey <tromey@adacore.com> 39515 39516 Add new interface to frame filter iteration 39517 This patch adds a new function, frame_iterator, that wraps the 39518 existing code to find and execute the frame filters. However, unlike 39519 execute_frame_filters, it will always return an iterator -- whereas 39520 execute_frame_filters will return None if no frame filters apply. 39521 39522 Nothing uses this new function yet, but it will used by a subsequent 39523 DAP patch. 39524 395252023-07-10 Tom Tromey <tromey@adacore.com> 39526 39527 Fix execute_frame_filters doc string 39528 When reading the doc string for execute_frame_filters, I wasn't sure 39529 if the ranges were inclusive or exclusive. This patch updates the doc 39530 string to reflect my findings, and also fixes an existing typo. 39531 395322023-07-10 Tom Tromey <tom@tromey.com> 39533 39534 Change 'handle_id' to be a local variable 39535 The global variable 'handle_id' in tracectf.c is only used in a single 39536 function, so change it to be a local variable. 39537 39538 Reviewed-by: Keith Seitz <keiths@redhat.com> 39539 395402023-07-10 Tom Tromey <tom@tromey.com> 39541 39542 Move definition of ctf_target type 39543 This moves the definition of the ctf_target type into the 39544 HAVE_LIBBABELTRACE block. This type is only used in this block, so it 39545 makes sense to only define it there. 39546 39547 Reviewed-by: Keith Seitz <keiths@redhat.com> 39548 395492023-07-10 Tom Tromey <tom@tromey.com> 39550 39551 Constify tfile_interp_line 39552 This adds 'const' to tfile_interp_line. 39553 39554 Reviewed-by: Keith Seitz <keiths@redhat.com> 39555 395562023-07-10 Tom Tromey <tom@tromey.com> 39557 39558 Use function_view in traceframe_walk_blocks 39559 This change traceframe_walk_blocks to take a function_view. This 39560 simplifies the code somewhat and lets us entirely remove one helper 39561 function. 39562 39563 Reviewed-by: Keith Seitz <keiths@redhat.com> 39564 395652023-07-10 Tom Tromey <tom@tromey.com> 39566 39567 Use unique_ptr for trace_dirname 39568 This changes trace_dirname to use unique_ptr, removing some manual 39569 memory management. 39570 39571 Reviewed-by: Keith Seitz <keiths@redhat.com> 39572 395732023-07-10 Tom Tromey <tom@tromey.com> 39574 39575 Use unique_ptr for trace_filename 39576 This changes trace_filename to use unique_ptr, removing some manual 39577 memory management. 39578 39579 Reviewed-by: Keith Seitz <keiths@redhat.com> 39580 395812023-07-10 Tom Tromey <tom@tromey.com> 39582 39583 Replace use of xfree with byte_vector 39584 This replaces a use of xfree with a byte_vector. 39585 39586 Reviewed-by: Keith Seitz <keiths@redhat.com> 39587 395882023-07-10 Tom Tromey <tom@tromey.com> 39589 39590 Remove a use of xfree 39591 This removes a use of xfree from tracefile-tfile.c, replacing it with 39592 a unique_xmalloc_ptr. 39593 39594 Reviewed-by: Keith Seitz <keiths@redhat.com> 39595 395962023-07-10 Tom Tromey <tom@tromey.com> 39597 39598 Avoid crash with absolute symbol 39599 A user supplied an executable and a remote logfile that could be used 39600 to crash gdb. The problem is that the BFD section for a particular 39601 symbol was null, because the section was not marked "allocated". 39602 Digging deeper, the problem was that elfread.c dropped the section for 39603 absolute symbols. This patch fixes the crash. 39604 39605 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431 39606 396072023-07-10 Andrew Burgess <aburgess@redhat.com> 39608 39609 gdbserver: handle all eval_result_type values in tracepoint.cc 39610 It was pointed out[1] that after this commit: 39611 39612 commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab 39613 Date: Thu Oct 20 11:14:33 2022 +0100 39614 39615 gdbserver: allow agent expressions to fail with invalid memory access 39616 39617 Now that agent expressions might fail with the error 39618 expr_eval_invalid_memory_access, we might overflow the 39619 eval_result_names array in tracepoint.cc. This is because the 39620 eval_result_names array does not include a string for either 39621 expr_eval_invalid_goto or expr_eval_invalid_memory_access. 39622 39623 I don't know if having expr_eval_invalid_goto missing is also a 39624 problem, but it feels like eval_result_names should just include a 39625 string for every possible error. 39626 39627 I could just add two more strings into the array, but I figure that a 39628 more robust solution will be to move all of the error types, and their 39629 associated strings, into a new ax-result-types.def file, and to then 39630 include this file in both ax.h and tracepoint.cc in order to build 39631 the enum eval_result_type and the eval_result_names string array. 39632 Doing this means it is impossible to have a missing error string in 39633 the future. 39634 39635 [1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/ 39636 39637 Approved-By: Pedro Alves <pedro@palves.net> 39638 396392023-07-10 Andrew Burgess <aburgess@redhat.com> 39640 39641 gdb/testsuite: avoid stack addresses in test names 39642 When comparing the test results for two different runs of GDB I 39643 noticed a difference in the results for gdb.base/frame-view.exp. 39644 39645 The difference was caused by one of the tests including a stack 39646 address in the test name: 39647 39648 PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b 39649 39650 and 39651 39652 PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b 39653 39654 If for whatever reason the stack address changes between test runs 39655 then it becomes harder to compare results. 39656 39657 Fix this by giving the test a descriptive name that doesn't include a 39658 stack address: 39659 39660 PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1 39661 39662 and 39663 39664 PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1 39665 39666 There's no change to what is actually tested after this commit. 39667 396682023-07-10 Andrew Burgess <aburgess@redhat.com> 39669 39670 gdb/testsuite: return after reporting a test unsupported 39671 In this commit: 39672 39673 commit 8bcead69665af3a9f9867cd34c3a1daf22120027 39674 Date: Tue May 23 11:25:01 2023 +0100 39675 39676 gdb/testsuite: add test for core file with a 0 pid 39677 39678 a new test gdb.arch/core-file-pid0.exp was added. This test includes 39679 a pre-generated core file for x86-64 and for other architectures the 39680 test reports 'unsupported'. 39681 39682 However, after reporting 'unsupported' the test failed to perform an 39683 early return, so the test would then carry on and try to actually 39684 perform the test, which resulted in some TCL errors. 39685 39686 Fix this by returning after reporting the test unsupported. 39687 396882023-07-10 Andrew Burgess <aburgess@redhat.com> 39689 39690 gdb: include location number in breakpoint error message 39691 This commit improves the output of this previous commit: 39692 39693 commit 2dc3457a454a35d0617dc1f9cc1db77468471f95 39694 Date: Fri Oct 14 13:22:55 2022 +0100 39695 39696 gdb: include breakpoint number in testing condition error message 39697 39698 The earlier commit extended the error message: 39699 39700 Error in testing breakpoint condition: 39701 39702 to include the breakpoint number, e.g.: 39703 39704 Error in testing breakpoint condition 3: 39705 39706 This commit extends takes this further, and includes the location 39707 number if the breakpoint has multiple locations, so we might now see: 39708 39709 Error in testing breakpoint condition 3.2: 39710 39711 Just as with how GDB reports a normal breakpoint stop, if a breakpoint 39712 only has a single location then the location number is not included, 39713 this keeps things nice and consistent. 39714 39715 I've extended one of the tests to cover the new functionality. 39716 39717 Approved-By: Pedro Alves <pedro@palves.net> 39718 397192023-07-10 Richard Bunt <richard.bunt@linaro.org> 39720 39721 gdb/testsuite: Testing with the nvfortran compiler 39722 Currently, the Fortran test suite does not run with NVIDIA's Fortran 39723 compiler (nvfortran). 39724 39725 The goal here is to get the tests running and preventing further 39726 regressions during future work. This change does not do anything to fix 39727 existing failures. 39728 39729 Teach the compiler detection about nvfortran. There is no underlying 39730 information about whether this compiler is related to flang classic or 39731 flang, so we cannot reuse the main and type definitions. Therefore, we 39732 explicitly record the main method and type information observed when 39733 using nvfortran. 39734 39735 The main name was extracted by trying to set breakpoints on both MAIN_ 39736 and MAIN__. 39737 39738 The following mapping of test to type names was used to extract how 39739 nvfortran reports types. 39740 39741 info-types.exp: fortran_int4, fortran_int8, fortran_real4, 39742 fortran_logical4 39743 39744 common-block.exp: fortran_real8 39745 39746 complex.exp: fortran_complex4 fortran_complex8 39747 39748 logical.exp: fortran_character1. Ran ptype on "c". 39749 39750 Types defined as fortran_complex16 do not compile with nvfortran, so it 39751 was left unset. 39752 39753 gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL. 39754 No regressions detected. 39755 39756 The gdb.fortran test results with nvfortran 23.3 are as follows. 39757 39758 Before: 39759 39760 # of expected passes 523 39761 # of unexpected failures 107 39762 # of known failures 2 39763 # of unresolved testcases 1 39764 # of untested testcases 7 39765 # of duplicate test names 2 39766 39767 After: 39768 39769 # of expected passes 5696 39770 # of unexpected failures 271 39771 # of known failures 12 39772 # of untested testcases 9 39773 # of unsupported tests 5 39774 39775 As can be seen from the above, there are now considerably more passing 39776 assertions. 39777 39778 Approved-By: Tom Tromey <tom@tromey.com> 39779 397802023-07-10 GDB Administrator <gdbadmin@sourceware.org> 39781 39782 Automatic date update in version.in 39783 397842023-07-09 Fangrui Song <maskray@google.com> 39785 39786 PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE 39787 For example, objcopy --set-section-flags .data=alloc,large will add 39788 SHF_X86_64_LARGE to the .data section. Omitting "large" will drop the 39789 SHF_X86_64_LARGE flag. 39790 39791 The bfd_section flag is named generically, SEC_ELF_LARGE, in case other 39792 processors want to follow SHF_X86_64_LARGE. SEC_ELF_LARGE has the same 39793 value as SEC_TIC54X_BLOCK used by coff. 39794 39795 bfd/ 39796 * section.c: Define SEC_ELF_LARGE. 39797 * bfd-in2.h: Regenerate. 39798 * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections, 39799 elf_x86_64_copy_private_section_data): New. 39800 39801 binutils/ 39802 * NEWS: Mention the new feature for objcopy. 39803 * doc/binutils.texi: Mention "large". 39804 * objcopy.c (parse_flags): Parse "large". 39805 (check_new_section_flags): Error if "large" is used with a 39806 non-x86-64 ELF target. 39807 * testsuite/binutils-all/x86-64/large-sections.d: New. 39808 * testsuite/binutils-all/x86-64/large-sections.s: New. 39809 * testsuite/binutils-all/x86-64/large-sections-i386.d: New. 39810 * testsuite/binutils-all/x86-64/large-sections-2.d: New. 39811 * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New. 39812 398132023-07-09 GDB Administrator <gdbadmin@sourceware.org> 39814 39815 Automatic date update in version.in 39816 398172023-07-08 Aaron Merey <amerey@redhat.com> 39818 39819 gdb/cp-namespace.c: Fix assert failure caused by malformed user input 39820 When debugging C++ programs, it is possible to trigger a spurious assert 39821 failure when attempting to set a breakpoint on a malformed symbol name. 39822 Names of the form 'A>::B' and 'A)::B' trigger this assert failure in 39823 cp_lookup_bare_symbol: 39824 39825 $ gdb gdb 39826 [...] 39827 (gdb) br test>::assert 39828 Function "test>::assert" not defined. 39829 Make breakpoint pending on future shared library load? (y or [n]) y 39830 Breakpoint 1 (test>::assert) pending. 39831 (gdb) start 39832 [...] 39833 cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed. 39834 A problem internal to GDB has been detected, 39835 further debugging may prove unreliable. 39836 ----- Backtrace ----- 39837 0x5217e2 gdb_internal_backtrace_1 39838 /home/amerey/binutils-gdb/gdb/bt-utils.c:122 39839 0x521885 _Z22gdb_internal_backtracev 39840 /home/amerey/binutils-gdb/gdb/bt-utils.c:168 39841 0xaf8303 internal_vproblem 39842 /home/amerey/binutils-gdb/gdb/utils.c:396 39843 0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag 39844 /home/amerey/binutils-gdb/gdb/utils.c:476 39845 0xccdb3f _Z18internal_error_locPKciS0_z 39846 /home/amerey/binutils-gdb/gdbsupport/errors.cc:58 39847 0x5dded9 cp_lookup_bare_symbol 39848 /home/amerey/binutils-gdb/gdb/cp-namespace.c:181 39849 0x5de39d cp_lookup_symbol_in_namespace 39850 /home/amerey/binutils-gdb/gdb/cp-namespace.c:328 39851 [...] 39852 39853 Currently this assert is skipped if the symbol name contains '<' or '('. 39854 Fix this spurious failure by also skipping the assert when the symbol 39855 name contains '>' or ')'. 39856 39857 Regression tested on F38 x86_64. 39858 39859 Approved-By: Tom Tromey <tom@tromey.com> 39860 398612023-07-08 GDB Administrator <gdbadmin@sourceware.org> 39862 39863 Automatic date update in version.in 39864 398652023-07-07 Tom Tromey <tromey@adacore.com> 39866 39867 Fix result of DAP setExpression 39868 A co-worker, Andry, noticed that the DAP setExpression implementation 39869 returned the wrong fields -- it used "result" rather than "value", and 39870 included "memoryReference", which isn't in the spec (an odd oversight, 39871 IMO). 39872 39873 This patch fixes the problems. 39874 398752023-07-07 Tom Tromey <tromey@adacore.com> 39876 39877 Remove unchecked casts to mi_interp 39878 Simon noticed a crash that could be caused via new Python 39879 gdb.execute_mi function. Looking into this, I found a few unchecked 39880 casts to mi_interp, like: 39881 39882 - struct mi_interp *mi = (struct mi_interp *) command_interp (); 39883 39884 This patch replaces all such casts with safer variants. 39885 39886 For -gdb-exit and mi_load_progress, I chose to have the functions 39887 simply not generate any output. It didn't seem useful to do so. 39888 39889 Some casts I eliminated by adding a parameter to a function. Then, in 39890 mi_execute_command, I changed the code to use 39891 gdb::checked_static_cast. This is appropriate because this particular 39892 overload can only be called by the MI interpreter. 39893 39894 There does not seem to be a very good way to test -gdb-exit. 39895 39896 Regression tested on x86-64 Fedora 36. 39897 398982023-07-07 Andrew Burgess <aburgess@redhat.com> 39899 39900 gdb: check max-value-size when reading strings for printf 39901 I noticed that the printf code for strings, printf_c_string and 39902 printf_wide_c_string, don't take max-value-size into account, but do 39903 load a complete string from the inferior into a GDB buffer. 39904 39905 As such it would be possible for an badly behaved inferior to cause 39906 GDB to try and allocate an excessively large buffer, potentially 39907 crashing GDB, or at least causing GDB to swap lots, which isn't 39908 great. 39909 39910 We already have a setting to protect against this sort of thing, the 39911 'max-value-size'. So this commit updates the two function mentioned 39912 above to check the max-value-size and give an error if the 39913 max-value-size is exceeded. 39914 39915 If the max-value-size is exceeded, I chose to continue reading 39916 inferior memory to figure out how long the string actually is, we just 39917 don't store the results. The benefit of this is that when we give the 39918 user an error we can tell the user how big the string actually is, 39919 which would allow them to correctly adjust max-value-size, if that's 39920 what they choose to do. 39921 39922 The default for max-value-size is 64k so there should be no user 39923 visible changes after this commit, unless the user was previously 39924 printing very large strings. If that is the case then the user will 39925 now need to increase max-value-size. 39926 399272023-07-07 Andrew Burgess <aburgess@redhat.com> 39928 39929 gdb: remove last alloca call from printcmd.c 39930 This commit removes the last alloca call from printcmd.c. This is 39931 similar to the patches I originally posted here: 39932 39933 https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/ 39934 39935 However, this change was not included in that original series. 39936 39937 The original series received push back because it was thought that 39938 replacing alloca with a C++ container type would introduce unnecessary 39939 malloc/free overhead. 39940 39941 However, in this case we are building a string, and (at least for 39942 GCC), the std::string type has a small string optimisation, where 39943 small strings are stored on the stack. 39944 39945 And in this case we are building what will usually be a very small 39946 string, we're just constructing a printf format specifier for a hex 39947 value, so it'll be something like '%#x' -- though it could also have a 39948 width in there too -- but still, it should normally fit within GCCs 39949 small string buffer. 39950 39951 So, in this commit, I propose replacing the use of alloca with a 39952 std::string. This shouldn't result (normally) in any additional 39953 malloc or free calls, so should be similar in performance to the 39954 original approach. 39955 39956 There should be no user visible differences after this commit. 39957 399582023-07-07 Andrew Burgess <aburgess@redhat.com> 39959 39960 gdb: remove two uses of alloca from printcmd.c 39961 Remove a couple of uses of alloca from printcmd.c, and replace them 39962 with gdb::byte_vector. 39963 39964 An earlier variant of this patch was proposed in this thread: 39965 39966 https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/ 39967 39968 however, there was push back on that thread due to it adding extra 39969 dynamic allocation, i.e. moving the memory buffers off the stack on to 39970 the heap. 39971 39972 However, of all the patches originally proposed, I think in these two 39973 cases moving off the stack is the correct thing to do. Unlike all the 39974 other patches in the original series, where the data being read 39975 was (mostly) small in size, a register, or a couple of registers, in 39976 this case we are reading an arbitrary string from the inferior. This 39977 could be any size, and so should not be placed on the stack. 39978 39979 So in this commit I replace the use of alloca with std::byte_vector 39980 and simplify the logic a little (I think) to take advantage of the 39981 ability of std::byte_vector to dynamically grow in size. 39982 39983 Of course, really, we should probably be checking the max-value-size 39984 setting as we load the string to stop GDB crashing if a corrupted 39985 inferior causes GDB to try read a stupidly large amount of 39986 memory... but I'm leaving that for a follow on patch. 39987 39988 There should be no user visible changes after this commit. 39989 399902023-07-07 Andrew Burgess <aburgess@redhat.com> 39991 39992 gdb: fix printf of wchar_t early in a gdb session 39993 Given this test program: 39994 39995 #include <wchar.h> 39996 39997 const wchar_t wide_str[] = L"wide string"; 39998 39999 int 40000 main (void) 40001 { 40002 return 0; 40003 } 40004 40005 I observed this GDB behaviour: 40006 40007 $ gdb -q /tmp/printf-wchar_t 40008 Reading symbols from /tmp/printf-wchar_t... 40009 (gdb) start 40010 Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8. 40011 Starting program: /tmp/printf-wchar_t 40012 40013 Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8 40014 25 return 0; 40015 (gdb) printf "%ls\n", wide_str 40016 40017 (gdb) 40018 40019 Notice that the printf results in a blank line rather than the 40020 expected 'wide string' output. 40021 40022 I tracked the problem down to printf_wide_c_string (in printcmd.c), in 40023 this function we do this: 40024 40025 struct type *wctype = lookup_typename (current_language, 40026 "wchar_t", NULL, 0); 40027 int wcwidth = wctype->length (); 40028 40029 the problem here is that 'wchar_t' is a typedef. If we look at the 40030 comment on type::length() we see this: 40031 40032 /* Note that if thistype is a TYPEDEF type, you have to call check_typedef. 40033 But check_typedef does set the TYPE_LENGTH of the TYPEDEF type, 40034 so you only have to call check_typedef once. Since value::allocate 40035 calls check_typedef, X->type ()->length () is safe. */ 40036 40037 What this means is that after calling lookup_typename we should call 40038 check_typedef in order to ensure that the length of the typedef has 40039 been setup correctly. We are not doing this in printf_wide_c_string, 40040 and so wcwidth is incorrectly calculated as 0. This is what leads GDB 40041 to print an empty string. 40042 40043 We can see in c_string_operation::evaluate (in c-lang.c) an example of 40044 calling check_typedef specifically to fix this exact issue. 40045 40046 Initially I did fix this problem by adding a check_typedef call into 40047 printf_wide_c_string, but then I figured why not move the 40048 check_typedef call up into lookup_typename itself, that feels like it 40049 should be harmless when looking up a non-typedef type, but will avoid 40050 bugs like this when looking up a typedef. So that's what I did. 40051 40052 I can then remove the extra check_typedef call from c-lang.c, I don't 40053 see any other places where we had extra check_typedef calls. This 40054 doesn't mean we definitely had bugs -- so long as we never checked the 40055 length, or, if we knew that check_typedef had already been called, 40056 then we would be fine. 40057 40058 I don't see any test regressions after this change, and my new test 40059 case is now passing. 40060 40061 Reviewed-By: Tom Tromey <tom@tromey.com> 40062 400632023-07-07 Jan Beulich <jbeulich@suse.com> 40064 40065 ld: fix build with old glibc / gcc 40066 "rename" conflicts with a function of that name, which gcc from that 40067 same timeframe then complains about. Use a name matching that of 40068 struct input_remap's respective field. 40069 400702023-07-07 Claudiu Zissulescu <claziss@synopsys.com> 40071 40072 arc: Update/Add ARCv3 support. 40073 The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA 40074 that implements a full range of 32-bit and 64-bit instructions. These 40075 processors feature a high-speed 10-stage, dual-issue pipeline that 40076 offers increased utilization of functional units with a limited 40077 increase in power and area. The HS5x processors feature a 32-bit 40078 pipeline that can execute all ARCv3 32-bit instructions, while the 40079 HS6x processors feature a full 64-bit pipeline and register file that 40080 can execute both 32-bit and 64-bit instructions. In addition, the ARC 40081 HS6x supports 64-bit virtual and 52-bit physical address spaces to 40082 enable direct addressing of current and future large memories, as well 40083 as 128-bit loads and stores for efficient data movement. 40084 40085 This readelf patch updates/adds Synopsys ARCv3 machine name fileds and 40086 supported relocations. 40087 400882023-07-07 Andrew Burgess <aburgess@redhat.com> 40089 40090 gdb/testsuite: fix license on recently added file 40091 The license header on a file I recently contributed was incorrect. 40092 The file was added in commit: 40093 40094 commit 087969169836f802a09b1cd0502d2f22d7a8f7dc 40095 Date: Tue May 23 11:25:21 2023 +0100 40096 40097 gdb: handle core files with .reg/0 section names 40098 40099 The problems were: 40100 40101 - GPLv2 instead of GPLv3, 40102 - Use the FSF postal address rather than their URL. 40103 40104 Nobody else has touched the file since I merged it, so I don't believe 40105 there are any problems with me changing the license, this commit does 40106 just that. 40107 401082023-07-07 Nick Clifton <nickc@redhat.com> 40109 40110 Udated Freach and Romainian translations for various sub-directories 40111 40112 Minor updates to release readme 40113 401142023-07-07 GDB Administrator <gdbadmin@sourceware.org> 40115 40116 Automatic date update in version.in 40117 401182023-07-06 Pedro Alves <pedro@palves.net> 40119 40120 Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525) 40121 Since commit 05c06f318fd9 ("Linux: Access memory even if threads are 40122 running"), GDB prefers pread64/pwrite64 to access inferior memory 40123 instead of ptrace. That change broke reading shared libraries on 40124 SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared 40125 libraries on SPARC64"). 40126 40127 On SPARC64 Linux, surprisingly (to me), userspace shared libraries are 40128 mapped at high 64-bit addresses: 40129 40130 (gdb) info sharedlibrary 40131 Cannot access memory at address 0xfff80001002011e0 40132 Cannot access memory at address 0xfff80001002011d8 40133 Cannot access memory at address 0xfff80001002011d8 40134 From To Syms Read Shared Object Library 40135 0xfff80001000010a0 0xfff8000100021f80 Yes (*) /lib64/ld-linux.so.2 40136 (*): Shared library is missing debugging information. 40137 40138 Those addresses are 64-bit addresses with the high bits set. When 40139 interpreted as signed, they're negative. 40140 40141 The Linux kernel rejects pread64/pwrite64 if the offset argument of 40142 type off_t (a signed type) is negative, which happens if the memory 40143 address we're accessing has its high bit set. See 40144 linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux. 40145 40146 Thankfully, lseek does not fail in that situation. So the fix is to 40147 use the 'lseek + read|write' path if the offset would be negative. 40148 40149 Fix this in both native GDB and GDBserver. 40150 40151 Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux. 40152 40153 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525 40154 Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5 40155 401562023-07-06 Branislav Brzak <branislav.brzak@syrmia.com> 40157 40158 riscv: Ensure LE instruction fetching 40159 Currently riscv gdb code looks at arch byte order 40160 when fetching instructions. This works when the 40161 target is LE, but on BE arch it will byte swap the 40162 instruction, while the riscv spec defines all 40163 instructions are LE encoded regardless of 40164 system memory endianess. 40165 401662023-07-06 Pedro Alves <pedro@palves.net> 40167 40168 Fix Solaris regression (PR tdep/30252) 40169 PR tdep/30252 reports that using GDB on Solaris fails an assertion in 40170 target_resume: 40171 40172 target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed. 40173 A problem internal to GDB has been detected, 40174 further debugging may prove unreliable. 40175 Quit this debugging session? (y or n) 40176 40177 The backtrace, after running it through c++filt, looks like: 40178 40179 ----- Backtrace ----- 40180 0xa18914 gdb_internal_backtrace_1 40181 /root/binutils-gdb/gdb/bt-utils.c:122 40182 0xa18914 gdb_internal_backtrace() 40183 /root/binutils-gdb/gdb/bt-utils.c:168 40184 0xdec834 internal_vproblem 40185 /root/binutils-gdb/gdb/utils.c:401 40186 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*) 40187 /root/binutils-gdb/gdb/utils.c:481 40188 0xf3638c internal_error_loc(char const*, int, char const*, ...) 40189 /root/binutils-gdb/gdbsupport/errors.cc:58 40190 0xd70580 target_resume(ptid_t, int, gdb_signal) 40191 /root/binutils-gdb/gdb/target.c:2648 40192 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) 40193 /root/binutils-gdb/gdb/procfs.c:2187 40194 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) 40195 /root/binutils-gdb/gdb/sol-thread.c:442 40196 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) 40197 /root/binutils-gdb/gdb/target.c:2586 40198 ... 40199 40200 The problem is that the procfs backend, while inside target_wait, 40201 called target_resume without switching to the leader thread of that 40202 resumption. 40203 40204 The target_resume interface is: 40205 40206 /* Resume execution (or prepare for execution) of the current thread 40207 (INFERIOR_PTID), while optionally letting other threads of the 40208 current process or all processes run free. 40209 ... 40210 40211 Thus calling target_resume with inferior_ptid == null_ptid is bogus. 40212 40213 target_wait (which leads to procfs_target::wait on Solaris) is called 40214 with inferior_ptid == null_ptid on entry exactly to help catch such 40215 bogus uses. 40216 40217 From the backtrace, it seems that the relevant line in question is 40218 procfs.c:2187: 40219 40220 2186 /* How to keep going without returning to wfi: */ 40221 2187 target_continue_no_signal (ptid); 40222 2188 goto wait_again; 40223 40224 target_continue_no_signal is a small wrapper around target_resume, 40225 which would make sense. 40226 40227 The fix is to not call target_resume or go via the target stack at 40228 all. Instead, factor out a new proc_resume function out of 40229 procfs_target::resume, and call that. The new function does not rely 40230 on inferior_ptid. 40231 40232 I've not been able to test it myself, but Petr confirmed it fixes the 40233 assertion failure with his test case, and Marcel Telka also confirmed 40234 it solves the problem. 40235 40236 Tested-By: Petr Šumbera <petr.sumbera@oracle.com> 40237 Tested-By: Marcel Telka <marcel@telka.sk> 40238 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252 40239 Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3 40240 402412023-07-06 YunQiang Su <yunqiang.su@cipunited.com> 40242 40243 ld: fix plugin tests for MIPS PIC 40244 On MIPS, for PIC objects, symbols may reference 2 times: 40245 once from the caller, and once from GOT. 40246 Thus ld may complains 2 times about "undefined reference". 40247 40248 So we add a new "#?" line to every effected testsuite. 40249 402502023-07-06 Alan Modra <amodra@gmail.com> 40251 40252 Use run_host_cmd to run $CC and other no-section-header test fixes 40253 We should be using run_host_cmd everywhere we invoke a compiler in the 40254 ld testsuite, if we want to use ld/ld-new just built. run_host_cmd 40255 properly inserts $gcc_B_opt in cases where a user wants to test 40256 binutils with a newly built compiler, ie. when $CC specifies -B itself. 40257 40258 Also, it is not good practice to exclude tests when non-native except 40259 of course those tests that run a target binary. Compiling and linking 40260 often shows up problems. 40261 40262 * testsuite/ld-elf/no-section-header.exp (binutils_run_test): 40263 Use run_host_cmd to invoke $CC_FOR_TARGET. Run all tests 40264 non-native too, except for attempting to run the binaries. 40265 Run tests for ELF in general, not just linux. 40266 * testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry 40267 symbol decoration, and support either sorting of symbols. 40268 * testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise. 40269 * testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise. 40270 * testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms. 40271 * testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept 40272 mips-sgi-irix symbol output. 40273 * testsuite/ld-elf/start-shared-noheader.nd: Likewise. 40274 402752023-07-06 Alan Modra <amodra@gmail.com> 40276 40277 Re: Stop the linker's --dependency-file option from including temporary lto files. 40278 PR 30568 40279 * ldfile.c (ldfile_try_open_bfd): Fix build failure when 40280 !BFD_SUPPORTS_PLUGINS. 40281 402822023-07-06 YunQiang Su <yunqiang.su@cipunited.com> 40283 40284 ld: Use run_host_cmd_yesno in indirect.exp instead of catch exec 40285 Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build, 40286 and in fact run_host_cmd_yesno is a better choice for it. 40287 40288 ld/ChangeLog: 40289 40290 * testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno 40291 instead of handwrite catch exec $CC_FOR_TARGET. 40292 402932023-07-06 YunQiang Su <yunqiang.su@cipunited.com> 40294 40295 ld: Use [list ] syntax to define run_tests in indirect.exp 40296 Currently, the var run_tests is defined by syntax {{}}, 40297 while in this case, variables cannot be used. 40298 Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names 40299 instead of values: 40300 gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o 40301 40302 Let's use [list [list ]] syntax instead. 40303 40304 ld/ChangeLog: 40305 40306 * testsuite/ld-elf/indirect.exp(run_tests): use [list [list]] 40307 syntax instead of {{}}. 40308 403092023-07-06 GDB Administrator <gdbadmin@sourceware.org> 40310 40311 Automatic date update in version.in 40312 403132023-07-05 Andreas Krebbel <krebbel@linux.ibm.com> 40314 40315 Align linkerscript symbols according to ABI 40316 Apply ABI specific alignment to symbols generated in the default 40317 linker script. 40318 403192023-07-05 GDB Administrator <gdbadmin@sourceware.org> 40320 40321 Automatic date update in version.in 40322 403232023-07-04 Jan Beulich <jbeulich@suse.com> 40324 40325 x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ 40326 The alternative is 1 byte shorter when the source is %xmm0-7, as a 40327 2-byte VEX prefix can then be used. 40328 40329 x86: optimize pre-AVX512 {,V}PCMPGT* with identical sources 40330 These are better expressed by the zeroing idiom {,V}PXOR. In some cases 40331 this also results in a shorter encoding. 40332 40333 x86: optimize pre-AVX512 {,V}PCMPEQQ with identical sources 40334 The {,V}PCMPEQD alternative is 1 byte shorter in many cases. 40335 403362023-07-04 Jan Beulich <jbeulich@suse.com> 40337 40338 x86: flag bad EVEX masking for miscellaneous insns 40339 Masking is not permitted for certain further insns, not falling in any 40340 of the earlier categories. Introduce the Y macro (not expanding to any 40341 output) to flag such cases. 40342 40343 Note that in a few cases entries already covered otherwise are converted 40344 as well, to continue to allow sharing of the string literals. 40345 403462023-07-04 Jan Beulich <jbeulich@suse.com> 40347 40348 x86: flag EVEX masking when destination is GPR(-like) 40349 Masking is not permitted in this case. See the code comment for how this 40350 is being dealt with. 40351 40352 To avoid excess special casing of modes, have OP_M() call OP_E_memory() 40353 directly. 40354 403552023-07-04 Jan Beulich <jbeulich@suse.com> 40356 40357 x86: flag EVEX.z set when destination is memory 40358 Zeroing-masking is not permitted in this case. See the code comment for 40359 how this is being dealt with. 40360 40361 x86: flag EVEX.z set when destination is a mask register 40362 While only zeroing-masking is possible in this case, this still requires 40363 EVEX.z to be clear. Introduce a "global" flag right here, to be re-used 40364 by checks which need to live in specific operand handlers. 40365 40366 x86: re-work EVEX-z-without-masking check 40367 Rather than corrupting disassmbly altogether, flag EVEX.z set as bad 40368 when masking isn't in effect in the first place at the time the 40369 destination operand is actually processed. 40370 403712023-07-04 Matheus Branco Borella <dark.ryu.550@gmail.com> 40372 40373 gdb: add __repr__() implementation to a few Python types 40374 Only a few types in the Python API currently have __repr__() 40375 implementations. This patch adds a few more of them. specifically: it 40376 adds __repr__() implementations to gdb.Symbol, gdb.Architecture, 40377 gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type. 40378 40379 This makes it easier to play around the GDB Python API in the Python 40380 interpreter session invoked with the 'pi' command in GDB, giving more 40381 easily accessible tipe information to users. 40382 40383 An example of how this would look like: 40384 40385 (gdb) pi 40386 >> gdb.lookup_type("char") 40387 <gdb.Type code=TYPE_CODE_INT name=char> 40388 >> gdb.lookup_global_symbol("main") 40389 <gdb.Symbol print_name=main> 40390 40391 The gdb.Block.__repr__() method shows the first 5 symbols from the 40392 block, and then a message to show how many more were elided (if any). 40393 403942023-07-04 Andrew Burgess <aburgess@redhat.com> 40395 40396 gdb: have mdict_size always return a symbol count 40397 In the next commit we would like to have mdict_size return the number 40398 of symbols in the dictionary, currently mdict_size is just a 40399 heuristic, sometimes it returns the number of symbols, and sometimes 40400 the number of buckets in a hashing dictionary (see size_hashed in 40401 dictionary.c). 40402 40403 Currently this vague notion of size is good enough, the only place 40404 mdict_size is used is in a maintenance command in order to print a 40405 message containing the size of the dictionary ... so we don't really 40406 care that the value isn't correct. 40407 40408 However, in the next commit we do want the size returned to be the 40409 number of symbols in the dictionary, so this commit makes mdict_size 40410 return the symbol count in all cases. 40411 40412 The new use is still not on a hot path -- it's going to be a Python 40413 __repr__ method, so all I do in this commit is have size_hashed walk 40414 the dictionary and count the entries, obviously this could be slow if 40415 we have a large number of symbols, but for now I'm not worrying about 40416 that case. We could always store the symbol count if we wanted, but 40417 that would increase the size of every dictionary for a use case that 40418 isn't going to be hit that often. 40419 40420 I've updated the text in 'maint print symbols' so that we don't talk 40421 about the size being 'syms/buckets', but just 'symbols' now. 40422 404232023-07-04 Nick Clifton <nickc@redhat.com> 40424 40425 Updated Ukranian, Romanian and German translations for various sub-directories 40426 404272023-07-04 Claudiu Zissulescu <claziss@gmail.com> 40428 40429 arc: Update default target CPU to match GCC defaults 40430 40431 arc: Update neg<.f> 0,b encoding 40432 Wrong encoding for null destination NEG instruction. Fix it. 40433 404342023-07-04 GDB Administrator <gdbadmin@sourceware.org> 40435 40436 Automatic date update in version.in 40437 404382023-07-03 Andreas Krebbel <krebbel@linux.ibm.com> 40439 40440 IBM Z: Fix pcrel relocs for symA-symB expressions 40441 The code in md_apply_fix which tries to deduce from the operand type 40442 which reloc to apply currently does the wrong thing for absolute 40443 relocs which have been re-written by fixup_segment as pc-relative to 40444 implement a subtraction of a local and an external symbol. 40445 40446 In all these cases we wrongly emit an absolute reloc because we ignore 40447 the fx_pcrel flag in md_apply_fix. However, only for the last one we 40448 actually support a pc relative relocation of the proper size and can 40449 implement it accordingly. For the other 3 we have to issue an error. 40450 40451 foo: 40452 cli 0(%r2),undef-foo 40453 la %r2,undef-foo(%r2) 40454 lay %r2,undef-foo(%r2) 40455 lhi %r2,undef-foo 40456 404572023-07-03 Tom Tromey <tromey@adacore.com> 40458 40459 Fix two Python calls that don't check for errors 40460 PyModule_AddObject steals a reference on success, but not on error, 40461 which is why we have gdb_pymodule_addobject. I found one spot still 40462 calling the former, which could in theory leak memory on failure. 40463 This patch fixes this. 40464 40465 In the same function I found an unchecked call to 40466 PyDict_SetItemString. This patch fixes this as well. 40467 40468 Approved-By: Andrew Burgess <aburgess@redhat.com> 40469 404702023-07-03 Andrew Burgess <aburgess@redhat.com> 40471 40472 gdb: handle core files with .reg/0 section names 40473 The previous commit added the test gdb.arch/core-file-pid0.exp which 40474 tests GDB's ability to load a core file containing threads with an 40475 lwpid of 0, which is something we GDB can encounter when loading a 40476 vmcore file -- a core file generated by the Linux kernel. The threads 40477 with an lwpid of 0 represents idle cores. 40478 40479 While the previous commit added the test, which confirms GDB doesn't 40480 crash when confronted with such a core file, there are still some 40481 problems with GDB's handling of these core files. These problems all 40482 originate from the fact that the core file (once opened by bfd) 40483 contains multiple sections called .reg/0, these sections all 40484 represents different threads (cpu cores in the original vmcore dump), 40485 but GDB gets confused and thinks all of these .reg/0 sections are all 40486 referencing the same thread. 40487 40488 Here is a GDB session on an x86-64 machine which loads the core file 40489 from the gdb.arch/core-file-pid0.exp, this core file contains two 40490 threads, both of which have a pid of 0: 40491 40492 $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q 40493 (gdb) core-file /tmp/x86_64-pid0-core.core 40494 [New process 1] 40495 [New process 1] 40496 Failed to read a valid object file image from memory. 40497 Core was generated by `./segv-mt'. 40498 Program terminated with signal SIGSEGV, Segmentation fault. 40499 The current thread has terminated 40500 (gdb) info threads 40501 Id Target Id Frame 40502 2 process 1 0x00000000004017c2 in ?? () 40503 40504 The current thread <Thread ID 1> has terminated. See `help thread'. 40505 (gdb) maintenance info sections 40506 Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64. 40507 [0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS 40508 [1] 0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS 40509 [2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS 40510 [3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS 40511 [4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS 40512 [5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS 40513 [6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS 40514 [7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS 40515 [8] 0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS 40516 [9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS 40517 [10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS 40518 [11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS 40519 [12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS 40520 [13] 0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS 40521 [14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS 40522 [15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS 40523 [16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE 40524 [17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY 40525 [18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS 40526 [19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS 40527 [20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS 40528 [21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY 40529 [22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS 40530 [23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS 40531 [24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS 40532 [25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS 40533 [26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS 40534 (gdb) 40535 40536 Notice when the core file is first loaded we see two lines like: 40537 40538 [New process 1] 40539 40540 And GDB reports: 40541 40542 The current thread has terminated 40543 40544 Which isn't what we'd expect from a core file -- the core file should 40545 only contain threads that are live at the point of the crash, one of 40546 which should be the current thread. The above message is reported 40547 because GDB has deleted what we think is the current thread! 40548 40549 And in the 'info threads' output we are only seeing a single thread, 40550 again, this is because GDB has deleted one of the threads. 40551 40552 Finally, the 'maintenance info sections' output shows the cause of all 40553 our problems, two sections named .reg/0. When GDB sees the first of 40554 these it creates a new thread. But, when we see the second .reg/0 GDB 40555 tries to create another new thread, but this thread has the same 40556 ptid_t as the first thread, so GDB deletes the first thread and 40557 creates the second thread in its place. 40558 40559 Because both these threads are created with an lwpid of 0 GDB reports 40560 these are 'New process NN' rather than 'New LWP NN' which is what we 40561 would normally expect. 40562 40563 The previous commit includes a little more of the history of GDB 40564 support in this area, but these problems were discussed on the mailing 40565 list a while ago in this thread: 40566 40567 https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/ 40568 40569 In this commit I propose a solution to these problems. 40570 40571 What I propose is that GDB should spot when we have .reg/0 sections 40572 and, when these are found, should rename these sections using some 40573 unique non-zero lwpid. 40574 40575 Note in the above output we also have sections like .reg2/0 and 40576 .reg-xstate/0, these are additional register sets, this commit also 40577 renumbers these sections inline with their .reg section. 40578 40579 The user is warned that some section renumbering has been performed. 40580 40581 GDB takes care to ensure that the new numbers assigned are unique and 40582 don't clash with any of the pid's that might already be in use -- 40583 remember, in a real vmcore file, 0 is used to indicate an idle core, 40584 non-idle cores will have the pid of whichever process was running on 40585 that core, so we don't want GDB to assign an lwpid that clashes with 40586 an actual pid that is in use in the core file. 40587 40588 After this commit here's the updated GDB session output: 40589 40590 $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q 40591 (gdb) core-file /tmp/x86_64-pid0-core.core 40592 warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2 40593 [New LWP 1] 40594 [New LWP 2] 40595 Failed to read a valid object file image from memory. 40596 Core was generated by `./segv-mt'. 40597 Program terminated with signal SIGSEGV, Segmentation fault. 40598 #0 0x00000000004017c2 in ?? () 40599 [Current thread is 1 (LWP 1)] 40600 (gdb) info threads 40601 Id Target Id Frame 40602 * 1 LWP 1 0x00000000004017c2 in ?? () 40603 2 LWP 2 0x000000000040dda5 in ?? () 40604 (gdb) maintenance info sections 40605 Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64. 40606 [0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS 40607 [1] 0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS 40608 [2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS 40609 [3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS 40610 [4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS 40611 [5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS 40612 [6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS 40613 [7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS 40614 [8] 0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS 40615 [9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS 40616 [10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS 40617 [11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS 40618 [12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS 40619 [13] 0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS 40620 [14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS 40621 [15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS 40622 [16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE 40623 [17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY 40624 [18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS 40625 [19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS 40626 [20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS 40627 [21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY 40628 [22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS 40629 [23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS 40630 [24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS 40631 [25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS 40632 [26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS 40633 (gdb) 40634 40635 Notice the new warning which is issued when the core file is being 40636 loaded. The threads are announced as '[New LWP NN]', and we see two 40637 threads in the 'info threads' output. The 'maintenance info sections' 40638 output shows the result of the section renaming. 40639 40640 The gdb.arch/core-file-pid0.exp test has been update to check for the 40641 improved GDB output. 40642 40643 Reviewed-By: Kevin Buettner <kevinb@redhat.com> 40644 406452023-07-03 Andrew Burgess <aburgess@redhat.com> 40646 40647 gdb/testsuite: add test for core file with a 0 pid 40648 This patch contains a test for this commit: 40649 40650 commit c820c52a914cc9d7c63cb41ad396f4ddffff2196 40651 Date: Fri Aug 6 19:45:58 2010 +0000 40652 40653 * thread.c (add_thread_silent): Use null_ptid instead of 40654 minus_one_ptid while getting rid of stale inferior_ptid. 40655 40656 This is another test that has been carried in the Fedora GDB tree for 40657 some time, and I thought that it would be worth merging to master. I 40658 don't believe there is any test like this currently in the testsuite. 40659 40660 The original issue was reported in this thread: 40661 40662 https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/ 40663 40664 The problem was that when GDB was used to open a vmcore (core file) 40665 image generated by the Linux kernel GDB would (sometimes) crash with 40666 an assertion failure: 40667 40668 thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed. 40669 40670 To understand what's going on we need some background; a vmcore file 40671 represents each processor core in the same way that a standard 40672 application core file represents threads. Thus, we might say, a 40673 vmcore file represents cores as threads. 40674 40675 When writing a vmcore file, the kernel will store the pid of the 40676 process currently running on that core as the thread's lwpid. 40677 40678 However, if a core is idle, with no process currently running on it, 40679 then the lwpid for that thread is stored as 0 in the vmcore file. If 40680 multiple cores are idle then multiple threads will have a lwpid of 0. 40681 40682 Back in 2010, the original issue reported tried to change the kernel's 40683 behaviour in this thread: 40684 40685 https://lkml.org/lkml/2010/8/3/75 40686 40687 This change was rejected by the kernel team, the current 40688 behaviour (lwpid of 0) was considered correct. I've checked the 40689 source of a recent kernel. The code mentioned in the lkml.org posting 40690 has moved, it's now in the function crash_save_cpu in the file 40691 kernel/kexec_core.c, but the general behaviour is unchanged, an idle 40692 core will have an lwpid of 0, so I think GDB still needs to be able to 40693 handle this case. 40694 40695 When GDB loads a vmcore file (which is handled just like any other 40696 core file) the sections are processed in core_open to generate the 40697 threads for the core file. The processing is done by calling 40698 add_to_thread_list, a function which looks for sections named .reg/NN 40699 where NN is the lwpid of the thread, GDB then builds a ptid_t for the 40700 new thread and calls add_thread. 40701 40702 Remember, in our case the lwpid is 0. Now for the first thread this 40703 is fine, if a little weird, 0 isn't usually a valid lwpid, but that's 40704 OK, GDB creates a thread with lwpid of 0 and carries on. 40705 40706 When we find the next thread (core) with lwpid of 0, we attempt to 40707 create another thread with an lwpid of 0. This of course clashes with 40708 the previously created thread, they have the same ptid_t, so GDB tries 40709 to delete the first thread. 40710 40711 And it was within this thread delete code that we triggered a bug 40712 which would then cause GDB to assert -- when deleting we tried to 40713 switch to a thread with minus_one_ptid, this resulted in a call to 40714 find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the 40715 find_inferior_pid call fails and returns NULL, which then triggered an 40716 assert in switch_to_thread. 40717 40718 The actual details of the why the assert triggered are really not 40719 important. What's important (I think) is that a vmcore file might 40720 have this interesting lwpid of 0 characteristic, which isn't something 40721 we see in "normal" application core files, and it is this that I think 40722 we should be testing. 40723 40724 Now, you might be thinking: isn't deleting the first thread the wrong 40725 thing to do? If the vmcore file has two threads that represent two 40726 cores, and both have an lwpid of 0 (indicating both cores are idle), 40727 then surely GDB should still represent this as two threads? You're 40728 not wrong. This was mentioned by Pedro in the original GDB mailing 40729 list thread here: 40730 40731 https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/ 40732 40733 This is indeed a problem, and this problem is still present in GDB 40734 today. I plan to try and address this in a later commit, however, 40735 this first commit is about getting a test in place to confirm that GDB 40736 at a minimum doesn't crash when loading such a vmcore file. 40737 40738 And so, finally, what's in this commit? 40739 40740 This commit contains a new test. The test doesn't actually contain a 40741 vmcore file. Instead I've created a standard application core file 40742 that contains two threads, and then manually edited the core file to 40743 set the lwpid of each thread to 0. 40744 40745 To further reduce the size of the core file (as it will be stored in 40746 git), I've zeroed all of the LOAD-able segments in the core file. 40747 This test really doesn't care about that part of the core file, we 40748 only really care about loading the register's, this is enough to 40749 confirm that the GDB doesn't crash. 40750 40751 Obviously as the core file is pre-generated, this test is architecture 40752 specific. There are already a few tests in gdb.arch/ that include 40753 pre-generate core files. Just as those existing tests do, I've 40754 compressed the core file with bzip2, which reduces it to just 750 40755 bytes. I have structured the test so that if/when this patch is 40756 merged I can add some additional core files for other architectures, 40757 however, these are not included in this commit. 40758 40759 The test simply expands the core file, and then loads it into GDB. 40760 One interesting thing to note is that GDB reports the core file 40761 loading like this: 40762 40763 (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core 40764 [New process 1] 40765 [New process 1] 40766 Failed to read a valid object file image from memory. 40767 Core was generated by `./segv-mt'. 40768 Program terminated with signal SIGSEGV, Segmentation fault. 40769 The current thread has terminated 40770 (gdb) 40771 40772 There's two interesting things here: first, the repeated "New process 40773 1" message. This is caused because linux_core_pid_to_str reports 40774 anything with an lwpid of 0 as a process, rather than an LWP. And 40775 second, the "The current thread has terminated" message. This is 40776 because the first thread in the core file is the current thread, but 40777 when GDB loads the second thread (which also has lwpid 0) this causes 40778 the first thread to be deleted, as a result GDB thinks that the 40779 current (first) thread has terminated. 40780 40781 As I said previously, both of these problems are a result of the lwpid 40782 0 aliasing, which is not being fixed in this commit -- this commit is 40783 just confirming that GDB doesn't crash when loading this core file. 40784 40785 Reviewed-By: Kevin Buettner <kevinb@redhat.com> 40786 407872023-07-03 Andrew Burgess <aburgess@redhat.com> 40788 40789 gdb: split inferior and thread setup when opening a core file 40790 I noticed that in corelow.c, when a core file is opened, both the 40791 thread and inferior setup is done in add_to_thread_list. In this 40792 patch I propose hoisting the inferior setup out of add_to_thread_list 40793 into core_target_open. 40794 40795 The only thing about this change that gave me cause for concern is 40796 that in add_to_thread_list, we only setup the inferior after finding 40797 the first section with a name like ".reg/NN". If we find no such 40798 section then the inferior will never be setup. 40799 40800 Is this important? 40801 40802 Well, I don't think so. Back in core_target_open, if there is no 40803 current thread (which there will not be if no ".reg/NN" section was 40804 found), then we look for a thread in the current inferior. If there 40805 are no threads (which there will not be if no ".reg/NN" is found), 40806 then we once again setup the current inferior. 40807 40808 What I think this means, is that, in all cases, the current inferior 40809 will end up being setup. By moving the inferior setup code earlier in 40810 core_target_open and making it non-conditional, we can remove the 40811 later code that sets up the inferior, we now know this will always 40812 have been done. 40813 40814 There should be no user visible changes after this commit. 40815 40816 Reviewed-By: Kevin Buettner <kevinb@redhat.com> 40817 408182023-07-03 Nick Clifton <nickc@redhat.com> 40819 40820 Update after creating 2.41 branch 40821 40822 Change version number to 2.41.50 and regenerate files 40823 408242023-07-03 Christoph Müllner <christoph.muellner@vrull.eu> 40825 40826 RISC-V: Zvkh[a,b]: Remove individual instruction class 40827 Currently we have three instruction classes defined for Zvkh[a,b]: 40828 - INSN_CLASS_ZVKNHA 40829 - INSN_CLASS_ZVKNHB 40830 - INSN_CLASS_ZVKNHA_OR_ZVKNHB 40831 40832 The encodings of all instructions in Zvknh[a,b] are identical. 40833 Therefore, we don't need the individual instruction classes 40834 and can remove them. 40835 40836 This patch also adds the missing support of the combined instruction 40837 class in riscv_multi_subset_supports_ext(). 40838 40839 Fixes: 62edb233ef5 ("RISC-V: Add support for the Zvknh[a,b] ISA extensions") 40840 Reported-By: Nelson Chu <nelson@rivosinc.com> 40841 408422023-07-03 Nick Clifton <nickc@redhat.com> 40843 40844 Add markers for the 2.41 branch 40845 408462023-07-03 WANG Xuerui <git@xen0n.name> 40847 40848 gas: NEWS: Announce LoongArch changes in the 2.41 cycle 40849 gas/ChangeLog: 40850 40851 * NEWS: Mention LoongArch changes for 2.41. 40852 408532023-07-03 WANG Xuerui <git@xen0n.name> 40854 40855 binutils: NEWS: Announce LoongArch changes in the 2.41 cycle 40856 binutils/ChangeLog: 40857 40858 * NEWS: Mention LoongArch changes for 2.41. 40859 408602023-07-03 WANG Xuerui <git@xen0n.name> 40861 40862 LoongArch: gas: Fix shared builds 40863 Formerly an include of libbfd.h was added in commit 56576f4a722 40864 ("LoongArch: gas: Add support for linker relaxation."), in order to 40865 allow calling _bfd_read_unsigned_leb128 from gas, but doing so broke 40866 shared builds. Commit d2fddb6d783 fixed this reference but did not 40867 remove the now unnecessary inclusion of libbfd.h. The gas_assert macro 40868 expands into a conditional call to abort(), but "abort" is re-defined to 40869 _bfd_abort in libbfd.h, so the extra include breaks any gas_assert 40870 usage, and should be removed. 40871 40872 gas/ChangeLog: 40873 40874 * config/tc-loongarch.c: Don't include libbfd.h. 40875 40876 Fixes: d2fddb6d783 ("LoongArch: Fix ld "undefined reference" error with --enable-shared") 40877 408782023-07-03 WANG Xuerui <git@xen0n.name> 40879 40880 opcodes/loongarch: Mark address offset operands of LVZ/LBT insns as such 40881 opcodes/ChangeLog: 40882 40883 * loongarch-opc.c: Mark the offset operands as "so" for 40884 {,x}v{ld,st}, {,x}v{ldrepl,stelm}.[bhwd], and {ld,st}[lr].[wd]. 40885 408862023-07-03 GDB Administrator <gdbadmin@sourceware.org> 40887 40888 Automatic date update in version.in 40889 408902023-07-02 GDB Administrator <gdbadmin@sourceware.org> 40891 40892 Automatic date update in version.in 40893 408942023-07-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 40895 40896 gprofng: fix data race 40897 In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use 40898 the output of gprofng to display the data. Sometimes this data is corrupted. 40899 40900 gprofng/ChangeLog 40901 2023-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 40902 40903 * src/ipc.cc (ipc_doWork): Fix data race. 40904 * src/ipcio.cc (IPCresponse::print): Fix data race. 40905 Remove unused variables and functions. 40906 * src/ipcio.h: Declare two variables. 40907 * src/StringBuilder.cc (StringBuilder::write): New function. 40908 * src/StringBuilder.h: Likewise. 40909 409102023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 40911 40912 binutils: NEWS: Announce new RISC-V vector crypto extensions 40913 This commit adds the recently added support of the RISC-V vector crypto 40914 extensions to the NEWS file. 40915 40916 binutils/ChangeLog: 40917 40918 * NEWS: Announce new RISC-V vector crypto extensions. 40919 409202023-07-01 Nathan Huckleberry <nhuck@google.com> 40921 40922 RISC-V: Add support for the Zvksc ISA extension 40923 Zvksc is part of the vector crypto extensions. 40924 40925 Zvksc is shorthand for the following set of extensions: 40926 - Zvks 40927 - Zvbc 40928 40929 bfd/ChangeLog: 40930 40931 * elfxx-riscv.c: Define Zvksc extension. 40932 40933 gas/ChangeLog: 40934 40935 * testsuite/gas/riscv/zvksc.d: New test. 40936 * testsuite/gas/riscv/zvksc.s: New test. 40937 409382023-07-01 Nathan Huckleberry <nhuck@google.com> 40939 40940 RISC-V: Add support for the Zvknc ISA extension 40941 Zvknc is part of the vector crypto extensions. 40942 40943 Zvknc is shorthand for the following set of extensxions: 40944 - Zvkn 40945 - Zvbc 40946 40947 bfd/ChangeLog: 40948 40949 * elfxx-riscv.c: Define Zvknc extension. 40950 40951 gas/ChangeLog: 40952 40953 * testsuite/gas/riscv/zvknc.d: New test. 40954 * testsuite/gas/riscv/zvknc.s: New test. 40955 409562023-07-01 Nathan Huckleberry <nhuck@google.com> 40957 40958 RISC-V: Add support for the Zvksg ISA extension 40959 Zvksg is part of the vector crypto extensions. 40960 40961 Zvksg is shorthand for the following set of extensions: 40962 - Zvks 40963 - Zvkg 40964 40965 bfd/ChangeLog: 40966 40967 * elfxx-riscv.c: Define Zvksg extension. 40968 40969 gas/ChangeLog: 40970 40971 * testsuite/gas/riscv/zvksg.d: New test. 40972 * testsuite/gas/riscv/zvksg.s: New test. 40973 409742023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 40975 40976 RISC-V: Add support for the Zvks ISA extension 40977 Zvks is part of the vector crypto extensions. 40978 40979 Zvks is shorthand for the following set of extensions: 40980 - Zvksed 40981 - Zvksh 40982 - Zvbb 40983 - Zvkt 40984 40985 bfd/ChangeLog: 40986 40987 * elfxx-riscv.c: Define Zvks extension. 40988 40989 gas/ChangeLog: 40990 40991 * testsuite/gas/riscv/zvks.d: New test. 40992 * testsuite/gas/riscv/zvks.s: New test. 40993 409942023-07-01 Nathan Huckleberry <nhuck@google.com> 40995 40996 RISC-V: Add support for the Zvkng ISA extension 40997 Zvkng is part of the vector crypto extensions. 40998 40999 Zvkng is shorthand for the following set of extensions: 41000 - Zvkn 41001 - Zvkg 41002 41003 bfd/ChangeLog: 41004 41005 * elfxx-riscv.c: Define Zvkng extension. 41006 41007 gas/ChangeLog: 41008 41009 * testsuite/gas/riscv/zvkng.d: New test. 41010 * testsuite/gas/riscv/zvkng.s: New test. 41011 410122023-07-01 Nathan Huckleberry <nhuck@google.com> 41013 41014 RISC-V: Allow nested implications for extensions 41015 Certain extensions require two levels of implications. For example, 41016 zvkng implies zvkn and zvkn implies zvkned. Enabling zvkng should also 41017 enable zvkned. 41018 41019 This patch fixes this behavior. 41020 41021 bfd/ChangeLog: 41022 41023 * elfxx-riscv.c (riscv_parse_add_implicit_subsets): Allow nested 41024 implications for extensions. 41025 410262023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41027 41028 RISC-V: Add support for the Zvkn ISA extension 41029 Zvkn is part of the vector crypto extensions. 41030 41031 Zvkn is shorthand for the following set of extensions: 41032 - Zvkned 41033 - Zvknhb 41034 - Zvbb 41035 - Zvkt 41036 41037 bfd/ChangeLog: 41038 41039 * elfxx-riscv.c: Define Zvkn extension. 41040 41041 gas/ChangeLog: 41042 41043 * testsuite/gas/riscv/zvkn.d: New test. 41044 * testsuite/gas/riscv/zvkn.s: New test. 41045 410462023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41047 41048 RISC-V: Add support for the Zvksh ISA extension 41049 Zvksh is part of the vector crypto extensions. 41050 41051 This extension adds the following instructions: 41052 - vsm3me.vv 41053 - vsm3c.vi 41054 41055 bfd/ChangeLog: 41056 41057 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41058 class support for Zvksh. 41059 (riscv_multi_subset_supports_ext): Likewise. 41060 41061 gas/ChangeLog: 41062 41063 * testsuite/gas/riscv/zvksh.d: New test. 41064 * testsuite/gas/riscv/zvksh.s: New test. 41065 41066 include/ChangeLog: 41067 41068 * opcode/riscv-opc.h (MATCH_VSM3C_VI): New. 41069 (MASK_VSM3C_VI): New. 41070 (MATCH_VSM3ME_VV): New. 41071 (MASK_VSM3ME_VV): New. 41072 (DECLARE_INSN): New. 41073 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41074 support for Zvksh. 41075 41076 opcodes/ChangeLog: 41077 41078 * riscv-opc.c: Add Zvksh instructions. 41079 410802023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41081 41082 RISC-V: Add support for the Zvksed ISA extension 41083 Zvksed is part of the vector crypto extensions. 41084 41085 This extension adds the following instructions: 41086 - vsm4k.vi 41087 - vsm4r.[vv,vs] 41088 41089 bfd/ChangeLog: 41090 41091 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41092 class support for Zvksed. 41093 (riscv_multi_subset_supports_ext): Likewise. 41094 41095 gas/ChangeLog: 41096 41097 * testsuite/gas/riscv/zvksed.d: New test. 41098 * testsuite/gas/riscv/zvksed.s: New test. 41099 41100 include/ChangeLog: 41101 41102 * opcode/riscv-opc.h (MATCH_VSM4K_VI): New. 41103 (MASK_VSM4K_VI): New. 41104 (MATCH_VSM4R_VS): New. 41105 (MASK_VSM4R_VS): New. 41106 (MATCH_VSM4R_VV): New. 41107 (MASK_VSM4R_VV): New. 41108 (DECLARE_INSN): New. 41109 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41110 support for Zvksed. 41111 41112 opcodes/ChangeLog: 41113 41114 * riscv-opc.c: Add Zvksed instructions. 41115 411162023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41117 41118 RISC-V: Add support for the Zvknh[a,b] ISA extensions 41119 Zvknh[a,b] are parts of the vector crypto extensions. 41120 41121 This extension adds the following instructions: 41122 - vsha2ms.vv 41123 - vsha2c[hl].vv 41124 41125 bfd/ChangeLog: 41126 41127 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41128 class support for Zvknh[a,b]. 41129 (riscv_multi_subset_supports_ext): Likewise. 41130 41131 gas/ChangeLog: 41132 41133 * testsuite/gas/riscv/zvknha.d: New test. 41134 * testsuite/gas/riscv/zvknha_zvknhb.s: New test. 41135 * testsuite/gas/riscv/zvknhb.d: New test. 41136 41137 include/ChangeLog: 41138 41139 * opcode/riscv-opc.h (MATCH_VSHA2CH_VV): New. 41140 (MASK_VSHA2CH_VV): New. 41141 (MATCH_VSHA2CL_VV): New. 41142 (MASK_VSHA2CL_VV): New. 41143 (MATCH_VSHA2MS_VV): New. 41144 (MASK_VSHA2MS_VV): New. 41145 (DECLARE_INSN): New. 41146 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41147 support for Zvknh[a,b]. 41148 41149 opcodes/ChangeLog: 41150 41151 * riscv-opc.c: Add Zvknh[a,b] instructions. 41152 411532023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41154 41155 RISC-V: Add support for the Zvkned ISA extension 41156 Zvkned is part of the vector crypto extensions. 41157 41158 This extension adds the following instructions: 41159 - vaesef.[vv,vs] 41160 - vaesem.[vv,vs] 41161 - vaesdf.[vv,vs] 41162 - vaesdm.[vv,vs] 41163 - vaeskf1.vi 41164 - vaeskf2.vi 41165 - vaesz.vs 41166 41167 bfd/ChangeLog: 41168 41169 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41170 class support for Zvkned. 41171 (riscv_multi_subset_supports_ext): Likewise. 41172 41173 gas/ChangeLog: 41174 41175 * testsuite/gas/riscv/zvkned.d: New test. 41176 * testsuite/gas/riscv/zvkned.s: New test. 41177 41178 include/ChangeLog: 41179 41180 * opcode/riscv-opc.h (MATCH_VAESDF_VS): New. 41181 (MASK_VAESDF_VS): New. 41182 (MATCH_VAESDF_VV): New. 41183 (MASK_VAESDF_VV): New. 41184 (MATCH_VAESDM_VS): New. 41185 (MASK_VAESDM_VS): New. 41186 (MATCH_VAESDM_VV): New. 41187 (MASK_VAESDM_VV): New. 41188 (MATCH_VAESEF_VS): New. 41189 (MASK_VAESEF_VS): New. 41190 (MATCH_VAESEF_VV): New. 41191 (MASK_VAESEF_VV): New. 41192 (MATCH_VAESEM_VS): New. 41193 (MASK_VAESEM_VS): New. 41194 (MATCH_VAESEM_VV): New. 41195 (MASK_VAESEM_VV): New. 41196 (MATCH_VAESKF1_VI): New. 41197 (MASK_VAESKF1_VI): New. 41198 (MATCH_VAESKF2_VI): New. 41199 (MASK_VAESKF2_VI): New. 41200 (MATCH_VAESZ_VS): New. 41201 (MASK_VAESZ_VS): New. 41202 (DECLARE_INSN): New. 41203 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41204 support for Zvkned. 41205 41206 opcodes/ChangeLog: 41207 41208 * riscv-opc.c: Add Zvkned instructions. 41209 412102023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41211 41212 RISC-V: Add support for the Zvkg ISA extension 41213 Zvkg is part of the vector crypto extensions. 41214 41215 This extension adds the following instructions: 41216 - vghsh.vv 41217 - vgmul.vv 41218 41219 bfd/ChangeLog: 41220 41221 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41222 class support for Zvkg. 41223 (riscv_multi_subset_supports_ext): Likewise. 41224 41225 gas/ChangeLog: 41226 41227 * testsuite/gas/riscv/zvkg.d: New test. 41228 * testsuite/gas/riscv/zvkg.s: New test. 41229 41230 include/ChangeLog: 41231 41232 * opcode/riscv-opc.h (MATCH_VGHSH_VV): New. 41233 (MASK_VGHSH_VV): New. 41234 (MATCH_VGMUL_VV): New. 41235 (MASK_VGMUL_VV): New. 41236 (DECLARE_INSN): New. 41237 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41238 support for Zvkg. 41239 41240 opcodes/ChangeLog: 41241 41242 * riscv-opc.c: Add Zvkg instructions. 41243 412442023-07-01 Nathan Huckleberry <nhuck@google.com> 41245 41246 RISC-V: Add support for the Zvbc extension 41247 Zvbc is part of the crypto vector extensions. 41248 41249 This extension adds the following instructions: 41250 - vclmul.[vv,vx] 41251 - vclmulh.[vv,vx] 41252 41253 bfd/ChangeLog: 41254 41255 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41256 class support for Zvbc. 41257 (riscv_multi_subset_supports_ext): Likewise. 41258 41259 gas/ChangeLog: 41260 41261 * testsuite/gas/riscv/zvbc.d: New test. 41262 * testsuite/gas/riscv/zvbc.s: New test. 41263 41264 include/ChangeLog: 41265 41266 * opcode/riscv-opc.h (MATCH_VCLMUL_VV): New. 41267 (MASK_VCLMUL_VV): New. 41268 (MATCH_VCLMUL_VX): New. 41269 (MASK_VCLMUL_VX): New. 41270 (MATCH_VCLMULH_VV): New. 41271 (MASK_VCLMULH_VV): New. 41272 (MATCH_VCLMULH_VX): New. 41273 (MASK_VCLMULH_VX): New. 41274 (DECLARE_INSN): New. 41275 * opcode/riscv.h (enum riscv_insn_class): Add instruction class 41276 support for Zvbc. 41277 41278 opcodes/ChangeLog: 41279 41280 * riscv-opc.c: Add Zvbc instruction. 41281 412822023-07-01 Christoph Müllner <christoph.muellner@vrull.eu> 41283 41284 RISC-V: Add support for the Zvbb ISA extension 41285 Zvbb is part of the vector crypto extensions. 41286 41287 This extension adds the following instructions: 41288 - vandn.[vv,vx] 41289 - vbrev.v 41290 - vbrev8.v 41291 - vrev8.v 41292 - vclz.v 41293 - vctz.v 41294 - vcpop.v 41295 - vrol.[vv,vx] 41296 - vror.[vv,vx,vi] 41297 - vwsll.[vv,vx,vi] 41298 41299 bfd/ChangeLog: 41300 41301 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41302 class support for Zvbb. 41303 (riscv_multi_subset_supports_ext): Likewise. 41304 41305 gas/ChangeLog: 41306 41307 * config/tc-riscv.c (validate_riscv_insn): Add 'l' as new format 41308 string directive. 41309 (riscv_ip): Likewise. 41310 * testsuite/gas/riscv/zvbb.d: New test. 41311 * testsuite/gas/riscv/zvbb.s: New test. 41312 41313 include/ChangeLog: 41314 41315 * opcode/riscv-opc.h (MATCH_VANDN_VV): New. 41316 (MASK_VANDN_VV): New. 41317 (MATCH_VANDN_VX): New. 41318 (MASK_VANDN_VX): New. 41319 (MATCH_VBREV8_V): New. 41320 (MASK_VBREV8_V): New. 41321 (MATCH_VBREV_V): New. 41322 (MASK_VBREV_V): New. 41323 (MATCH_VCLZ_V): New. 41324 (MASK_VCLZ_V): New. 41325 (MATCH_VCPOP_V): New. 41326 (MASK_VCPOP_V): New. 41327 (MATCH_VCTZ_V): New. 41328 (MASK_VCTZ_V): New. 41329 (MATCH_VREV8_V): New. 41330 (MASK_VREV8_V): New. 41331 (MATCH_VROL_VV): New. 41332 (MASK_VROL_VV): New. 41333 (MATCH_VROL_VX): New. 41334 (MASK_VROL_VX): New. 41335 (MATCH_VROR_VI): New. 41336 (MASK_VROR_VI): New. 41337 (MATCH_VROR_VV): New. 41338 (MASK_VROR_VV): New. 41339 (MATCH_VROR_VX): New. 41340 (MASK_VROR_VX): New. 41341 (MATCH_VWSLL_VI): New. 41342 (MASK_VWSLL_VI): New. 41343 (MATCH_VWSLL_VV): New. 41344 (MASK_VWSLL_VV): New. 41345 (MATCH_VWSLL_VX): New. 41346 (MASK_VWSLL_VX): New. 41347 (DECLARE_INSN): New. 41348 * opcode/riscv.h (EXTRACT_RVV_VI_UIMM6): New. 41349 (ENCODE_RVV_VI_UIMM6): New. 41350 (enum riscv_insn_class): Add instruction class for Zvbb. 41351 41352 opcodes/ChangeLog: 41353 41354 * riscv-dis.c (print_insn_args): Add 'l' as new format string 41355 directive. 41356 * riscv-opc.c: Add Zvbb instructions. 41357 413582023-07-01 GDB Administrator <gdbadmin@sourceware.org> 41359 41360 Automatic date update in version.in 41361 413622023-06-30 Tom Tromey <tom@tromey.com> 41363 41364 Fix regressions caused by agent expression C++-ification 41365 Simon pointed out that my agent expression C++-ification patches 41366 caused a regression with the native-gdbserver target board. The bug 41367 is that append_const is supposed to write in big-endian order, but I 41368 switched this by mistake. 41369 413702023-06-30 Philipp Tomsich <philipp.tomsich@vrull.eu> 41371 41372 binutils: NEWS: announce new RISC-V extensions 41373 We picked up support for a few new extensions over the last weeks 41374 (this may need further updating prior to the next release), list them 41375 in the NEWS file. 41376 41377 binutils/ChangeLog: 41378 41379 * binutils/NEWS: announce suuport for the new RISC-V 41380 extensions (Zicond, Zfa, XVentanaCondOps). 41381 413822023-06-30 Christoph Müllner <christoph.muellner@vrull.eu> 41383 41384 RISC-V: Add support for the Zfa extension 41385 This patch adds support for the RISC-V Zfa extension, 41386 which introduces additional floating-point instructions: 41387 * fli (load-immediate) with pre-defined immediates 41388 * fminm/fmaxm (like fmin/fmax but with different NaN behaviour) 41389 * fround/froundmx (round to integer) 41390 * fcvtmod.w.d (Modular Convert-to-Integer) 41391 * fmv* to access high bits of FP registers in case XLEN < FLEN 41392 * fleq/fltq (quiet comparison instructions) 41393 41394 Zfa defines its instructions in combination with the following 41395 extensions: 41396 * single-precision floating-point (F) 41397 * double-precision floating-point (D) 41398 * quad-precision floating-point (Q) 41399 * half-precision floating-point (Zfh) 41400 41401 This patch is based on an earlier version from Tsukasa OI: 41402 https://sourceware.org/pipermail/binutils/2022-September/122939.html 41403 Most significant change to that commit is the switch from the rs1-field 41404 value to the actual floating-point value in the last operand of the fli* 41405 instructions. Everything that strtof() can parse is accepted and 41406 the '%a' printf specifier is used to output hex floating-point literals 41407 in the disassembly. 41408 41409 The Zfa specification is frozen (and has passed public review). It is 41410 available as a chapter in "The RISC-V Instruction Set Manual: Volume 1": 41411 https://github.com/riscv/riscv-isa-manual/releases 41412 41413 bfd/ChangeLog: 41414 41415 * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction 41416 class support for 'Zfa' extension. 41417 (riscv_multi_subset_supports_ext): Likewise. 41418 (riscv_implicit_subsets): Add 'Zfa' -> 'F' dependency. 41419 41420 gas/ChangeLog: 41421 41422 * config/tc-riscv.c (flt_lookup): New helper to lookup a float value 41423 in an array. 41424 (validate_riscv_insn): Add 'Wfv' as new format string directive. 41425 (riscv_ip): Likewise. 41426 * doc/c-riscv.texi: Add floating-point chapter and describe 41427 limiations of the Zfa FP literal parsing. 41428 * testsuite/gas/riscv/zfa-32.d: New test. 41429 * testsuite/gas/riscv/zfa-32.s: New test. 41430 * testsuite/gas/riscv/zfa-64.d: New test. 41431 * testsuite/gas/riscv/zfa-64.s: New test. 41432 * testsuite/gas/riscv/zfa-fail.d: New test. 41433 * testsuite/gas/riscv/zfa-fail.l: New test. 41434 * testsuite/gas/riscv/zfa-fail.s: New test. 41435 * testsuite/gas/riscv/zfa.d: New test. 41436 * testsuite/gas/riscv/zfa.s: New test. 41437 * testsuite/gas/riscv/zfa.s: New test. 41438 41439 * opcode/riscv-opc.h (MATCH_FLI_H): New. 41440 (MASK_FLI_H): New. 41441 (MATCH_FMINM_H): New. 41442 (MASK_FMINM_H): New. 41443 (MATCH_FMAXM_H): New. 41444 (MASK_FMAXM_H): New. 41445 (MATCH_FROUND_H): New. 41446 (MASK_FROUND_H): New. 41447 (MATCH_FROUNDNX_H): New. 41448 (MASK_FROUNDNX_H): New. 41449 (MATCH_FLTQ_H): New. 41450 (MASK_FLTQ_H): New. 41451 (MATCH_FLEQ_H): New. 41452 (MASK_FLEQ_H): New. 41453 (MATCH_FLI_S): New. 41454 (MASK_FLI_S): New. 41455 (MATCH_FMINM_S): New. 41456 (MASK_FMINM_S): New. 41457 (MATCH_FMAXM_S): New. 41458 (MASK_FMAXM_S): New. 41459 (MATCH_FROUND_S): New. 41460 (MASK_FROUND_S): New. 41461 (MATCH_FROUNDNX_S): New. 41462 (MASK_FROUNDNX_S): New. 41463 (MATCH_FLTQ_S): New. 41464 (MASK_FLTQ_S): New. 41465 (MATCH_FLEQ_S): New. 41466 (MASK_FLEQ_S): New. 41467 (MATCH_FLI_D): New. 41468 (MASK_FLI_D): New. 41469 (MATCH_FMINM_D): New. 41470 (MASK_FMINM_D): New. 41471 (MATCH_FMAXM_D): New. 41472 (MASK_FMAXM_D): New. 41473 (MATCH_FROUND_D): New. 41474 (MASK_FROUND_D): New. 41475 (MATCH_FROUNDNX_D): New. 41476 (MASK_FROUNDNX_D): New. 41477 (MATCH_FLTQ_D): New. 41478 (MASK_FLTQ_D): New. 41479 (MATCH_FLEQ_D): New. 41480 (MASK_FLEQ_D): New. 41481 (MATCH_FLI_Q): New. 41482 (MASK_FLI_Q): New. 41483 (MATCH_FMINM_Q): New. 41484 (MASK_FMINM_Q): New. 41485 (MATCH_FMAXM_Q): New. 41486 (MASK_FMAXM_Q): New. 41487 (MATCH_FROUND_Q): New. 41488 (MASK_FROUND_Q): New. 41489 (MATCH_FROUNDNX_Q): New. 41490 (MASK_FROUNDNX_Q): New. 41491 (MATCH_FLTQ_Q): New. 41492 (MASK_FLTQ_Q): New. 41493 (MATCH_FLEQ_Q): New. 41494 (MASK_FLEQ_Q): New. 41495 (MATCH_FCVTMOD_W_D): New. 41496 (MASK_FCVTMOD_W_D): New. 41497 (MATCH_FMVH_X_D): New. 41498 (MASK_FMVH_X_D): New. 41499 (MATCH_FMVH_X_Q): New. 41500 (MASK_FMVH_X_Q): New. 41501 (MATCH_FMVP_D_X): New. 41502 (MASK_FMVP_D_X): New. 41503 (MATCH_FMVP_Q_X): New. 41504 (MASK_FMVP_Q_X): New. 41505 (DECLARE_INSN): New. 41506 * opcode/riscv.h (enum riscv_insn_class): Add instruction 41507 classes for the Zfa extension. 41508 41509 opcodes/ChangeLog: 41510 41511 * riscv-dis.c (print_insn_args): Add support for 41512 new format string directive 'Wfv'. 41513 * riscv-opc.c: Add Zfa instructions. 41514 41515 Co-Developed-by: Tsukasa OI <research_trasio@irq.a4lg.com> 41516 Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu> 41517 Acked-by: Palmer Dabbelt <palmer@rivosinc.com> 41518 415192023-06-30 Nick Clifton <nickc@redhat.com> 41520 41521 strings: Improve code to detect excessively large minimum string lengths. 41522 PR 30598 41523 * strings.c (set_string_min): New function. (main): Use it. (print_unicode_stream): Calculate buffer size using a size_t. 41524 41525 Prevent an illegal memory access when running the strings program with an excessively lerge minimum string length. 41526 PR 30595 41527 * strings.c (main): Check for an excessively large minimum string length. 41528 41529 Fix used-before-initialized warnings when compiling elf.c with Clang-16. 41530 415312023-06-30 mengqinggang <mengqinggang@loongson.cn> 41532 41533 LoongArch: gas: Fix code style issues 41534 Blocks of 8 spaces be replaced with tabs. 41535 Fix alignment issues. 41536 415372023-06-30 mengqinggang <mengqinggang@loongson.cn> 41538 41539 LoongArch: gas: Add LVZ and LBT instructions support 41540 gas/ChangeLog: 41541 * config/tc-loongarch.c (md_parse_option): Add LARCH_opts.ase_lvz and 41542 LARCH_opts.ase_lbt. 41543 * testsuite/gas/loongarch/uleb128.d: Regenerated. 41544 * testsuite/gas/loongarch/lvz-lbt.d: New test. 41545 * testsuite/gas/loongarch/lvz-lbt.s: New test. 41546 41547 include/ChangeLog: 41548 * opcode/loongarch.h (ase_lvz): New. 41549 (ase_lbt): New. 41550 41551 opcodes/ChangeLog: 41552 * loongarch-dis.c (set_default_loongarch_dis_options): Add 41553 LARCH_opts.ase_lvz and LARCH_opts.ase_lbt. 41554 * loongarch-opc.c (struct loongarch_ase): Add LVZ and LBT instructions. 41555 415562023-06-30 WANG Xuerui <git@xen0n.name> 41557 41558 LoongArch: Deprecate $v[01], $fv[01] and $x names per spec 41559 As outlined in the LoongArch ELF psABI spec [1], it is actually already 41560 2 versions after the initial LoongArch support, and the $v[01] and 41561 $fv[01] names should really get sunset by now. 41562 41563 In addition, the "$x" name for $r21 was never included in any released 41564 version of the ABI spec, and such usages are all fixed to say just $r21 41565 for every project I could think of that accepted a LoongArch port. 41566 41567 Plus, the upcoming LSX/LASX support makes use of registers named 41568 "$vrNN" and "$xrNN", so having "$vN" and "$x" alongside would almost 41569 certainly create confusion for developers. 41570 41571 Issue warnings for such usages per the deprecation procedure detailed 41572 in the spec, so we can finally remove support in the next release cycle 41573 after this. 41574 41575 [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html 41576 41577 gas/ChangeLog: 41578 41579 * config/tc-loongarch.c: Init canonical register ABI name 41580 mappings and deprecated register names. 41581 (loongarch_args_parser_can_match_arg_helper): Warn in case of 41582 deprecated register name usage. 41583 * testsuite/gas/loongarch/deprecated_reg_aliases.d: New test. 41584 * testsuite/gas/loongarch/deprecated_reg_aliases.l: Likewise. 41585 * testsuite/gas/loongarch/deprecated_reg_aliases.s: Likewise. 41586 41587 include/ChangeLog: 41588 41589 * opcode/loongarch.h: Rename global variables. 41590 41591 opcodes/ChangeLog: 41592 41593 * loongarch-opc.c: Rename the alternate/deprecated register name 41594 mappings, and move $x to the deprecated name map. 41595 415962023-06-30 WANG Xuerui <git@xen0n.name> 41597 41598 opcodes/loongarch: print unrecognized insn words with the .word directive 41599 For better round-trip fidelity and readability in general. 41600 41601 gas/ChangeLog: 41602 41603 * testsuite/gas/loongarch/uleb128.d: Update test case. 41604 * testsuite/gas/loongarch/raw-insn.d: New test. 41605 * testsuite/gas/loongarch/raw-insn.s: Likewise. 41606 41607 opcodes/ChangeLog: 41608 41609 * loongarch-dis.c (disassemble_one): Print ".word" if !opc. 41610 416112023-06-30 WANG Xuerui <git@xen0n.name> 41612 41613 opcodes/loongarch: do not print hex notation for signed immediates 41614 The additional hex notation was minimally useful when one had to 41615 inspect code with heavy bit manipulation, or of unclear signedness, but 41616 it clutters the output, and the style is not regular assembly language 41617 syntax either. 41618 41619 Precisely how one approaches the original use case is not taken care of 41620 in this patch (maybe we want a disassembler option forcing a certain 41621 style for immediates, like for example printing every immediate in 41622 decimal or hexadecimal notation), but at least let's stop the current 41623 practice. 41624 41625 ChangeLog: 41626 41627 * testsuite/gas/loongarch/imm_ins.d: Update test case. 41628 * testsuite/gas/loongarch/imm_ins_32.d: Likewise. 41629 * testsuite/gas/loongarch/imm_op.d: Likewise. 41630 * testsuite/gas/loongarch/jmp_op.d: Likewise. 41631 * testsuite/gas/loongarch/load_store_op.d: Likewise. 41632 * testsuite/gas/loongarch/macro_op.d: Likewise. 41633 * testsuite/gas/loongarch/macro_op_32.d: Likewise. 41634 * testsuite/gas/loongarch/privilege_op.d: Likewise. 41635 * testsuite/gas/loongarch/uleb128.d: Likewise. 41636 * testsuite/gas/loongarch/vector.d: Likewise. 41637 41638 ld/ChangeLog: 41639 41640 * testsuite/ld-loongarch-elf/jmp_op.d: Update test case. 41641 * testsuite/ld-loongarch-elf/macro_op.d: Likewise. 41642 * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise. 41643 41644 opcodes/ChangeLog: 41645 41646 * loongarch-dis.c (dis_one_arg): Remove the "(0x%x)" part from 41647 disassembly output of signed immediate operands. 41648 416492023-06-30 WANG Xuerui <git@xen0n.name> 41650 41651 opcodes/loongarch: style disassembled address offsets as such 41652 Add a modifier char 'o' telling the disassembler to print the immediate 41653 using the address offset style, and mark the memory access instructions' 41654 offset operands as such. 41655 41656 opcodes/ChangeLog: 41657 41658 * loongarch-dis.c (dis_one_arg): Style disassembled address 41659 offsets as such when the operand has a modifier char 'o'. 41660 * loongarch-opc.c: Add 'o' to operands that represent address 41661 offsets. 41662 416632023-06-30 WANG Xuerui <git@xen0n.name> 41664 41665 opcodes/loongarch: implement style support in the disassembler 41666 Update the LoongArch disassembler to supply style information to the 41667 disassembler output. The output formatting remains unchanged. 41668 41669 opcodes/ChangeLog: 41670 41671 * disassemble.c: Mark LoongArch as created_styled_output=true. 41672 * loongarch-dis.c (dis_one_arg): Use fprintf_styled_func 41673 throughout with proper styles. 41674 416752023-06-30 WANG Xuerui <git@xen0n.name> 41676 41677 opcodes/loongarch: remove unused code 41678 Remove some unused declarations and code. 41679 41680 include/ChangeLog: 41681 41682 * opcode/loongarch.h: Remove unused declarations. 41683 41684 opcodes/ChangeLog: 41685 41686 * loongarch-dis.c (loongarch_parse_dis_options): Remove. 41687 (my_print_address_func): Likewise. 41688 (loongarch_disassemble_one): Likewise. 41689 416902023-06-30 WANG Xuerui <git@xen0n.name> 41691 41692 LoongArch: support disassembling certain pseudo-instructions 41693 Add a flag in the pinfo field for being able to mark certain specialized 41694 matchers as disassembler-only, so some degree of isolation between 41695 assembler-side and disassembler-side can be achieved. 41696 41697 This isolation is necessary, firstly because some pseudo-instructions 41698 cannot be fully described in the opcode table, like `li.[wd]`, so the 41699 corresponding opcode entry cannot have meaningful match/mask values. 41700 Secondly, some of these pseudo-instructions can be realized in more than 41701 one plausible ways; e.g. `li.w rd, <something between 0 and 0x7ff>` can 41702 be realized on LA64 with any of `addi.w`, `addi.d` or `ori`. If we tie 41703 disassembly of such aliases with the corresponding GAS support, only one 41704 canonical form among the above would be recognized as `li.w`, and it 41705 would mildly impact the readability of disassembly output. 41706 People wanting the exact disassembly can always set `-M no-aliases` to 41707 get the original behavior back. 41708 41709 In addition, in certain cases, information is irreversibly lost after 41710 assembling, so perfect round-trip would not be possible in such cases. 41711 For example, `li.w` and `li.d` of immediates within int32_t range 41712 produce the same code; in this patch, `addi.d rd, $zero, imm` is treated 41713 as `li.d`, while `addi.w` and `ori` immediate loads are shown as `li.w`, 41714 due to the expressible value range well within 32 bits. 41715 41716 gas/ChangeLog: 41717 41718 * config/tc-loongarch.c (get_loongarch_opcode): Ignore 41719 disassembler-only aliases. 41720 * testsuite/gas/loongarch/64_pcrel.d: Update test case. 41721 * testsuite/gas/loongarch/imm_ins.d: Likewise. 41722 * testsuite/gas/loongarch/imm_ins_32.d: Likewise. 41723 * testsuite/gas/loongarch/jmp_op.d: Likewise. 41724 * testsuite/gas/loongarch/li.d: Likewise. 41725 * testsuite/gas/loongarch/macro_op.d: Likewise. 41726 * testsuite/gas/loongarch/macro_op_32.d: Likewise. 41727 * testsuite/gas/loongarch/macro_op_large_abs.d: Likewise. 41728 * testsuite/gas/loongarch/macro_op_large_pc.d: Likewise. 41729 * testsuite/gas/loongarch/nop.d: Likewise. 41730 * testsuite/gas/loongarch/relax_align.d: Likewise. 41731 * testsuite/gas/loongarch/reloc.d: Likewise. 41732 41733 include/ChangeLog: 41734 41735 * opcode/loongarch.h (INSN_DIS_ALIAS): Add. 41736 41737 ld/ChangeLog: 41738 41739 * testsuite/ld-loongarch-elf/jmp_op.d: Update test case. 41740 * testsuite/ld-loongarch-elf/macro_op.d: Likewise. 41741 * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise. 41742 * testsuite/ld-loongarch-elf/relax-align.dd: Likewise. 41743 41744 opcodes/ChangeLog: 41745 41746 * loongarch-dis.c: Move register name map declarations to top. 41747 (get_loongarch_opcode_by_binfmt): Consider aliases when 41748 disassembling without the no-aliases option. 41749 (parse_loongarch_dis_option): Support the no-aliases option. 41750 * loongarch-opc.c: Collect pseudo instructions into a new 41751 dedicated table. 41752 417532023-06-30 GDB Administrator <gdbadmin@sourceware.org> 41754 41755 Automatic date update in version.in 41756 417572023-06-30 Indu Bhagat <indu.bhagat@oracle.com> 41758 41759 binutils/NEWS: announce SFrame version 2 as the new default 41760 417612023-06-30 Indu Bhagat <indu.bhagat@oracle.com> 41762 41763 doc: sframe: update specification for SFRAME_VERSION_2 41764 Add details for the changes made from Version 1 to Version 2 of the format. 41765 41766 Also add details about alignment in the SFrame format. A portion of the 41767 SFrame stack trace format has an unaligned on-disk representation. Add 41768 description at relevant points in the specificatin to clarify the 41769 alignment related details. 41770 417712023-06-30 Indu Bhagat <indu.bhagat@oracle.com> 41772 41773 sframe: bfd: gas: ld: format bump to SFrame version 2 41774 SFrame version 2 encodes the size of repetitive insn block explicitly 41775 in the format. Add information in the SFrame FDE to convey the size 41776 of the block of repeating instructions. This information is used only 41777 for SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK. 41778 41779 Introduce two extra bytes for padding: this ensures that the memory 41780 accesses to the members of the SFrame Frame Descriptor Entry (FDE) are 41781 naturally aligned. 41782 41783 gas generates SFrame section with version SFRAME_VERSION_2 by default. 41784 41785 libsframe provides two new APIs to: 41786 - get an SFrame FDE data from the decoder context, and 41787 - add an SFrame FDE to the encoder context. 41788 The additional argument (for rep_block_size) is useful for SFrame FDEs 41789 where FDE type is SFRAME_FDE_TYPE_PCMASK. 41790 41791 The linker will generate the output SFrame sections in the 41792 SFRAME_VERSION_2 format. If the input sections offered to the linker 41793 are not all in the SFRAME_VERSION_2 format, the linker issues an error 41794 to the user. 41795 41796 objdump/readelf will show the following message to the user if .sframe 41797 section in SFRAME_VERSION_1 format is seen: 41798 41799 "No further information can be displayed. SFrame version not 41800 supported." 41801 41802 In other words, like the rest of the binutils, only the current SFrame 41803 format version, i.e., SFRAME_VERSION_2 is supported by the textual dump 41804 facilities. 41805 41806 bfd/ 41807 * elf-sframe.c (_bfd_elf_merge_section_sframe): Generate an 41808 output SFrame section with version SFRAME_VERSION_2. Also, 41809 error out if the SFrame sections do not all have 41810 SFRAME_VERSION_2. 41811 * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Generate SFrame 41812 section for plt entries with version SFRAME_VERSION_2. 41813 gas/ 41814 * gen-sframe.c (sframe_set_version): Update to SFRAME_VERSION_2. 41815 (output_sframe): Likewise. 41816 gas/testsuite/ 41817 * gas/cfi-sframe/cfi-sframe-aarch64-1.d: Use SFRAME_VERSION_2. 41818 * gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise. 41819 * gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Likewise. 41820 * gas/cfi-sframe/cfi-sframe-common-1.d: Likewise. 41821 * gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. 41822 * gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. 41823 * gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. 41824 * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. 41825 * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. 41826 * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. 41827 * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. 41828 * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise. 41829 * gas/cfi-sframe/common-empty-1.d: Likewise. 41830 * gas/cfi-sframe/common-empty-2.d: Likewise. 41831 * gas/cfi-sframe/common-empty-3.d: Likewise. 41832 ld/testsuite/ 41833 * ld-aarch64/sframe-simple-1.d: Adjust for SFRAME_VERSION_2. 41834 * ld-x86-64/sframe-plt-1.d: Likewise. 41835 * ld-x86-64/sframe-simple-1.d: Likewise. 41836 libsframe/ 41837 * libsframe.ver: Add the new APIs. 41838 * sframe.c (sframe_decoder_get_funcdesc_v2): New definition. 41839 (sframe_encoder_add_funcdesc_v2): Likewise. 41840 (sframe_header_sanity_check_p): Include SFRAME_VERSION_2. 41841 (sframe_fre_check_range_p): Get rep_block_size info from SFrame 41842 FDE. 41843 * sframe-dump.c (dump_sframe_header): Add support for 41844 SFRAME_VERSION_2. 41845 (dump_sframe): Inform user if SFrame section in SFRAME_VERSION_1 41846 format is seen. 41847 libsframe/testsuite/ 41848 * libsframe.decode/DATA-BE: Regenerated data file. 41849 * libsframe.decode/DATA1: Likewise. 41850 * libsframe.decode/DATA2: Likewise. 41851 * libsframe.find/plt-findfre-1.c: Use new API in the testcase. 41852 include/ 41853 * sframe.h: Add member to encode size of the code block of 41854 repeating instructions. Add 2 bytes of padding. 41855 * sframe-api.h (sframe_decoder_get_funcdesc_v2): New 41856 declaration. 41857 (sframe_encoder_add_funcdesc_v2): Likewise. 41858 418592023-06-30 Indu Bhagat <indu.bhagat@oracle.com> 41860 41861 libsframe: add new APIs to get SFrame version 41862 While the SFrame preamble is guaranteed to not change between versions, 41863 providing these access APIs from the SFrame decoder and encoder APIs is 41864 for convenience only. The linker may want to use these APIs as the 41865 format evolves. 41866 41867 include/ 41868 * sframe-api.h (sframe_decoder_get_version): New declaration. 41869 (sframe_encoder_get_version): Likewise. 41870 41871 libsframe/ 41872 * libsframe/libsframe.ver: Add new APIs. 41873 * libsframe/sframe.c (sframe_decoder_get_version): New 41874 definition. 41875 (sframe_encoder_get_version): Likewise. 41876 418772023-06-29 Indu Bhagat <indu.bhagat@oracle.com> 41878 41879 libsframe: fix sframe_find_fre for pltN entries 41880 For a toy application on x86_64, for example, following is the SFrame 41881 stack trace information for the 3 pltN entries of 16 bytes each: 41882 41883 func idx [1]: pc = 0x401030, size = 48 bytes 41884 STARTPC[m] CFA FP RA 41885 0000000000000000 sp+8 u u 41886 000000000000000b sp+16 u u 41887 41888 The data in first column is the start_ip_offset. Also note that the FDE 41889 is of type SFRAME_FDE_TYPE_PCMASK (denoted by the [m] on LHS). 41890 41891 Where each pltN (note: excluding plt0 entry) entry looks like: 41892 41893 401030: jmp *0x2fca(%rip) 41894 401036: push $0x0 41895 40103b: jmp 401020<_init+0x20> 41896 41897 401040: jmp *0x2fc2(%rip) 41898 401046: push $0x1 41899 40104b: jmp 401020<_init+0x20> 41900 41901 401050: jmp *0x2fba(%rip) 41902 401056: push $0x2 41903 40105b: jmp 401020<_init+0x20> 41904 41905 Now, to find SFrame stack trace information from an FDE of type 41906 SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation 41907 like, 41908 (start_ip_offset & 0xf) >= (pc & 0xf) 41909 41910 This works for pltN entry of size, say, less than 16 bytes. But if the 41911 pltN entries or similar code stubs (for which SFrame FDE of type 41912 SFRAME_FDE_TYPE_PCMASK may be used), evolve to be of size > 16 bytes, 41913 this will cease to work. 41914 41915 To match the range covered by the SFrame FRE, one should instead perform 41916 a modulo operation. The constant for the modulo operation must be the 41917 size of the pltN entry. Further, this constant should ideally be 41918 encoded in the format, as it may be different for each ABI. 41919 41920 In SFrame Version 2 of the format, we will move towards encoding it 41921 explicitly in the SFrame FDE. For now, fix up the logic to at least 41922 move towards modulo operation. 41923 41924 libsframe/ 41925 * sframe.c (sframe_fre_check_range_p): New definition. 41926 (sframe_find_fre): Refactor a bit and use the new definition 41927 above. 41928 include/ 41929 * sframe.h (SFRAME_FDE_TYPE_PCMASK): Update comment. 41930 libsframe/doc/ 41931 * sframe-spec.texi: Fix the text for SFRAME_FDE_TYPE_PCMASK FDE 41932 type. 41933 419342023-06-29 H.J. Lu <hjl.tools@gmail.com> 41935 41936 ld: Add -z nosectionheader test to bootstrap.exp 41937 PR ld/25617 41938 * testsuite/ld-bootstrap/bootstrap.exp: Add -z nosectionheader 41939 test. 41940 419412023-06-29 H.J. Lu <hjl.tools@gmail.com> 41942 41943 ld: Add tests for -z nosectionheader and --strip-section-headers 41944 Add tests to verify that the linker option, -z nosectionheader and 41945 objcopy and strip option, --strip-section-headers, work correctly as well 41946 as linker issues an error when dynamic symbol table from PT_DYNAMIC 41947 segment is used. 41948 41949 PR ld/25617 41950 * testsuite/ld-elf/hash-2.d: New file. 41951 * testsuite/ld-elf/no-section-header.exp: Likewise. 41952 * testsuite/ld-elf/pr25617-1-no-sec-hdr.nd: Likewise. 41953 * testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Likewise. 41954 * testsuite/ld-elf/pr25617-1-static-no-sec-hdr.rd: Likewise. 41955 * testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Likewise. 41956 * testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise. 41957 * testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise. 41958 * testsuite/ld-elf/pr25617-1a.c: Likewise. 41959 * testsuite/ld-elf/pr25617-1b.c: Likewise. 41960 * testsuite/ld-elf/start-noheader.rd: Likewise. 41961 * testsuite/ld-elf/start-shared-noheader-gnu.rd: Likewise. 41962 * testsuite/ld-elf/start-shared-noheader-sysv.rd: Likewise. 41963 * testsuite/ld-elf/start-shared-noheader.nd: Likewise. 41964 419652023-06-29 H.J. Lu <hjl.tools@gmail.com> 41966 41967 binutils: Add a --strip-section-headers test 41968 PR ld/25617 41969 * testsuite/binutils-all/objcopy.exp: Run strip-section-headers-1. 41970 * testsuite/binutils-all/strip-section-headers-1.d: New file. 41971 419722023-06-29 Kaylee Blake <klkblake@gmail.com> 41973 41974 ld: Add simple tests for -z nosectionheader 41975 2020-06-06 Kaylee Blake <klkblake@gmail.com> 41976 H.J. Lu <hongjiu.lu@intel.com> 41977 41978 PR ld/25617 41979 * testsuite/ld-elf/nosectionheader-1.d: New file. 41980 * testsuite/ld-elf/nosectionheader-2.d: Likewise. 41981 419822023-06-29 H.J. Lu <hjl.tools@gmail.com> 41983 41984 bfd: Improve nm and objdump without section header 41985 When there is no section header in an executable or shared library, we 41986 reconstruct dynamic symbol table from the PT_DYNAMIC segment, which 41987 contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, DT_STRTAB, DT_SYMTAB, 41988 DT_STRSZ, and DT_SYMENT entries, to improve nm and objdump. For DT_HASH, 41989 the number of dynamic symbol table entries equals the number of chains. 41990 For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols with non-STB_LOCAL 41991 indings are in hash table. Since DT_GNU_HASH/DT_MIPS_XHASH place all 41992 symbols with STB_LOCAL binding before symbols with other bindings and 41993 all undefined symbols defined ones in dynamic symbol table, the highest 41994 symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest dynamic symbol 41995 table index. We can also get symbol version from DT_VERSYM, DT_VERDEF 41996 and DT_VERNEED entries. 41997 41998 dt_symtab, dt_versym, dt_verdef, dt_verneed, dt_symtab_count, 41999 dt_verdef_count, dt_verneed_count and dt_strtab are added to 42000 elf_obj_tdata to store dynamic symbol table information. 42001 42002 PR ld/25617 42003 * elf-bfd.h (elf_obj_tdata): Add dt_symtab, dt_verdef, dt_verneed, 42004 dt_symtab_count, dt_verdef_count, dt_verneed_count and dt_strtab. 42005 (elf_use_dt_symtab_p): New. 42006 (_bfd_elf_get_dynamic_symbols): Likewise. 42007 (_bfd_elf_get_section_from_dynamic_symbol): Likewise. 42008 * elf.c (bfd_elf_get_elf_syms): Use dynamic symbol table if 42009 neeeded. 42010 (_bfd_elf_get_dynamic_symtab_upper_bound): Likewise. 42011 (_bfd_elf_slurp_version_tables): Likewise. 42012 (offset_from_vma): New function. 42013 (get_hash_table_data): Likewise. 42014 (_bfd_elf_get_dynamic_symbols): Likewise. 42015 (_bfd_elf_get_section_from_dynamic_symbol): Likewise. 42016 (_bfd_elf_get_symbol_version_name): Likewise. 42017 * elfcode.h (elf_object_p): Call _bfd_elf_get_dynamic_symbols 42018 to reconstruct dynamic symbol table from PT_DYNAMIC segment if 42019 there is no section header. 42020 (elf_slurp_symbol_table): Use dynamic symbol table if neeeded. 42021 Don't free isymbuf when dynamic symbol table is used. 42022 * elflink.c (elf_link_is_defined_archive_symbol): Return wrong 42023 format error when dynamic symbol table is used. 42024 (elf_link_add_object_symbols): Likewise. 42025 420262023-06-29 H.J. Lu <hjl.tools@gmail.com> 42027 42028 ELF: Discard non-alloc sections without section header 42029 Discard non-alloc sections when section headers are stripped. 42030 42031 bfd/ 42032 42033 PR ld/25617 42034 * elf.c (_bfd_elf_assign_file_positions_for_non_load): Skip 42035 non-load sections without section header. 42036 (_bfd_elf_write_object_contents): Don't set the sh_name field 42037 without section header. Write out the .shstrtab section only 42038 if its sh_offset field isn't -1. 42039 42040 binutils/ 42041 42042 PR ld/25617 42043 * objcopy.c (is_strip_section_1): Remove non-alloc sections for 42044 --strip-section-headers. 42045 42046 ld/ 42047 42048 PR ld/25617 42049 * ldlang.c (lang_discard_section_p): Discard non-alloc sections 42050 if we are stripping section headers. 42051 420522023-06-29 Kaylee Blake <klkblake@gmail.com> 42053 42054 ELF: Strip section header in ELF objects 42055 Section header isn't mandatory on ELF executable nor shared library. 42056 This patch adds a new linker option, -z nosectionheader, to omit ELF 42057 section header, a new objcopy and strip option, --strip-section-headers, 42058 to remove ELF section headers. 42059 42060 bfd/ 42061 42062 2023-06-06 H.J. Lu <hongjiu.lu@intel.com> 42063 Kaylee Blake <klkblake@gmail.com> 42064 42065 PR ld/25617 42066 * bfd.c (BFD_NO_SECTION_HEADER): New. 42067 (BFD_FLAGS_SAVED): Add BFD_NO_SECTION_HEADER. 42068 (BFD_FLAGS_FOR_BFD_USE_MASK): Likewise. 42069 * elfcode.h (elf_swap_ehdr_out): Omit section header with 42070 BFD_NO_SECTION_HEADER. 42071 (elf_write_shdrs_and_ehdr): Likewise. 42072 * elfxx-target.h (TARGET_BIG_SYM): Add BFD_NO_SECTION_HEADER 42073 to object_flags. 42074 (TARGET_LITTLE_SYM): Likewise. 42075 * bfd-in2.h: Regenerated. 42076 42077 binutils/ 42078 42079 2023-06-06 H.J. Lu <hongjiu.lu@intel.com> 42080 42081 PR ld/25617 42082 * NEWS: Mention --strip-section-headers for objcopy and strip. 42083 * objcopy.c (strip_section_headers): New. 42084 (command_line_switch): Add OPTION_STRIP_SECTION_HEADERS. 42085 (strip_options): Add --strip-section-headers. 42086 (copy_options): Likewise. 42087 (copy_usage): Add --strip-section-headers. 42088 (strip_usage): Likewise. 42089 (copy_object): Handle --strip-section-headers for ELF files. 42090 (strip_main): Handle OPTION_STRIP_SECTION_HEADERS. 42091 (copy_main): Likewise. 42092 * doc/binutils.texi: Document --strip-section-headers for objcopy 42093 and strip. 42094 42095 ld/ 42096 42097 2023-06-06 H.J. Lu <hongjiu.lu@intel.com> 42098 Kaylee Blake <klkblake@gmail.com> 42099 42100 PR ld/25617 42101 * NEWS: Mention -z nosectionheader. 42102 * emultempl/elf.em: Support -z sectionheader and 42103 -z nosectionheader. 42104 * ld.h (ld_config_type): Add no_section_header. 42105 * ld.texi: Document -z sectionheader and -z nosectionheader. 42106 * ldlang.c (ldlang_open_output): Handle 42107 config.no_section_header. 42108 * lexsup.c (parse_args): Enable --strip-all with 42109 -z nosectionheader. Disallow -r with -z nosectionheader. 42110 (elf_static_list_options): Add -z sectionheader and 42111 -z nosectionheader. 42112 421132023-06-29 Matthias Klose <doko@debian.org> 42114 42115 Ignore --prefix-file-map compiler option whist running testsuite. 42116 42117 ignore lto-wrapper warnings for lto builds. 42118 I see these warnings from time to time, when configuring a build with --enable-pgo-build=lto, I haven't yet found out why I see these sometime, and why not. E.g. https://gcc.gnu.org/PR109241. Just ignore these when they appear in test cases. lto-wrapper: warning: using serial compilation of N LTRANS jobs 42119 421202023-06-29 GDB Administrator <gdbadmin@sourceware.org> 42121 42122 Automatic date update in version.in 42123 421242023-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 42125 42126 gprofng: Add new tests 42127 gprofng/ChangeLog 42128 2023-06-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 42129 42130 * Makefile.am: Pass CLOCK_GETTIME_LINK to the testsuite 42131 * Makefile.in: Rebuild. 42132 * testsuite/gprofng.display/gp-archive.exp: New file. 42133 * testsuite/gprofng.display/gp-collect-app_F.exp: New file. 42134 * testsuite/gprofng.display/setpath_map.exp: New file. 42135 * testsuite/lib/smalltest.c: New file. 42136 421372023-06-28 Andrew Carlotti <andrew.carlotti@arm.com> 42138 42139 aarch64: Remove version dependencies from features 42140 Many instructions were enabled only when both a feature flag and a minimum 42141 architecture version are specified. This behaviour differs from GCC, which (in 42142 most cases) allows features to be enabled at any architecture version. 42143 42144 There is no need for the toolchain to restrict combinations of unrelated 42145 features in this way, so this patch removes the unnecessary dependencies. 42146 421472023-06-28 Tom Tromey <tromey@adacore.com> 42148 42149 Remove Python 2 from gdb documentation 42150 GDB can't be built using Python 2 any more, so remove the remaining 42151 vestiges of this from the documentation. 42152 42153 Approved-By: Eli Zaretskii <eliz@gnu.org> 42154 421552023-06-28 Michael Matz <matz@suse.de> 42156 42157 section-match: Check parent archive name as well 42158 rewriting the section matching routines lost a special case 42159 of matching: section statements of the form 42160 42161 NAME(section-glob) 42162 42163 normally match against NAME being an object file, but like in 42164 the exclude list we happened to accept archive names as NAME 42165 (undocumented). The documented way to specify (all) archive members 42166 is by using e.g. 42167 42168 lib.a:(section-glob) 42169 42170 (that does work also with the prefix tree matcher). 42171 42172 But I intended to not actually change behaviour with the prefix 42173 tree implementation. So, let's also implement checking against 42174 archive names with a similar FIXME comment we already have in 42175 walk_wild_file_in_exclude_list. 42176 42177 PR 30590 42178 42179 ld/ 42180 * ldlang.c (walk_wild_section_match): Also look at archive 42181 parents for a name match. 42182 421832023-06-28 Tom Tromey <tromey@adacore.com> 42184 42185 Fix handling of DW_TAG_unspecified_type for Ada 42186 Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type 42187 DIE") changed the handling of DW_TAG_unspecified_type. Before this 42188 change, such types were not entered into the symbol table. 42189 42190 It turns out that, when such a type is in the symtab, it can cause 42191 failures in Ada. In particular, a private type in another package may 42192 be seen locally as "void". 42193 42194 Now, it would probably be better to fix this via check_typedef. 42195 However, that is somewhat difficult given the state of the DWARF 42196 reader -- in particular with gdb_index, this would require expanding 42197 potentially many CUs to find the correct type. 42198 42199 Instead, this patch changes gdb to not enter a symbol for an 42200 unspecified type -- but only for Ada. 42201 422022023-06-28 Tom Tromey <tromey@adacore.com> 42203 42204 Remove some Python 2 code 42205 I found some Python 2 compatibility code in gdb's Python library. 42206 There's no need for this any more, so this removes it. There is still 42207 a bit more of this remaining in __init__.py, but I haven't tried 42208 removing that yet. 42209 42210 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 42211 422122023-06-28 Nick Clifton <nickc@redhat.com> 42213 42214 Stop the linker's --dependency-file option from including temporary lto files. 42215 PR 30568 42216 * ldfile.c (ldfile_try_open_bfd): Do not track lto generated temporary files. 42217 42218 Updated French translation for the gold sub-directory 42219 422202023-06-28 mengqinggang <mengqinggang@loongson.cn> 42221 42222 LoongArch: gas: Add LSX and LASX instructions test 42223 gas/ChangeLog: 42224 42225 * testsuite/gas/loongarch/vector.d: New test. 42226 * testsuite/gas/loongarch/vector.s: New test. 42227 422282023-06-28 mengqinggang <mengqinggang@loongson.cn> 42229 42230 LoongArch: gas: Add lsx and lasx instructions support 42231 gas/ChangeLog: 42232 42233 * config/tc-loongarch.c (md_parse_option): Add lsx and lasx option. 42234 (loongarch_after_parse_args): Add lsx and lasx option. 42235 42236 opcodes/ChangeLog: 42237 42238 * loongarch-opc.c (struct loongarch_ase): Add lsx and lasx 42239 instructions. 42240 422412023-06-28 mengqinggang <mengqinggang@loongson.cn> 42242 42243 LoongArch: Add R_LARCH_64_PCREL relocation support 42244 Gas defaults to emit R_LARCH_ADD64/R_LARCH_SUB64 unless explcitly declared 42245 to emit R_LARCH_64_PCREL. 42246 42247 The LoongArch ABI at here: 42248 https://github.com/loongson/la-abi-specs/blob/release/la-abi.adoc 42249 42250 bfd/ChangeLog: 42251 42252 * bfd-in2.h (not): Add R_LARCH_64_PCREL 42253 * elfnn-loongarch.c (perform_relocation): Likewise. 42254 * elfxx-loongarch.c: Likewise. 42255 * libbfd.h: Likewise. 42256 * reloc.c: Likewise. 42257 42258 gas/ChangeLog: 42259 42260 * config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper): 42261 (md_apply_fix): Add R_LARCH_64_PCREL. 42262 * testsuite/gas/loongarch/64_pcrel.d: New test. 42263 * testsuite/gas/loongarch/64_pcrel.s: New test. 42264 42265 include/ChangeLog: 42266 42267 * elf/loongarch.h (RELOC_NUMBER): Add R_LARCH_64_PCREL. 42268 42269 ld/ChangeLog: 42270 42271 * testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test. 42272 * testsuite/ld-loongarch-elf/64_pcrel.d: New test. 42273 * testsuite/ld-loongarch-elf/64_pcrel.s: New test. 42274 422752023-06-28 GDB Administrator <gdbadmin@sourceware.org> 42276 42277 Automatic date update in version.in 42278 422792023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42280 42281 binutils/NEWS: add note about upcoming libsframe changes 42282 Some of these changes update the ABI in an incompatible way. 42283 422842023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42285 42286 libsframe: bfd: use uint32_t for return type of get_num_fidx APIs 42287 Keep the data types usage in libsframe look consistent. 42288 42289 bfd/ 42290 * elf-sframe.c (_bfd_elf_merge_section_sframe): Use uint32_t 42291 type alias. 42292 * libsframe/sframe.c (sframe_decoder_get_funcdesc_at_index): 42293 Likewise. 42294 (sframe_decoder_get_num_fidx): Likewise. 42295 (sframe_encoder_get_num_fidx): Likewise. 42296 include/ 42297 * sframe-api.h (sframe_decoder_get_num_fidx): Likewise. 42298 (sframe_encoder_get_num_fidx): Likewise. 42299 423002023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42301 42302 libsframe: use appropriate data types for args of sframe_encode 42303 include/ 42304 * sframe-api.h (sframe_encode): Use of uint8_t is more 42305 appropriate. 42306 libsframe/ 42307 * sframe.c (sframe_encode): Likewise. 42308 423092023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42310 42311 libsframe: use uint8_t for return type of sframe_fre_get_base_reg_id 42312 Use a more appropriate data type. 42313 42314 include/ 42315 * sframe-api.h (sframe_fre_get_base_reg_id): Use uint8_t as 42316 return type. 42317 libsframe/ 42318 * sframe-dump.c (dump_sframe_func_with_fres): Use uint8_t type 42319 for base reg id. 42320 * sframe.c (sframe_fre_get_base_reg_id): Use uin8_t as return 42321 type. 42322 423232023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42324 42325 libsframe: use uint8_t instead of unsigned char for abi_arch 42326 Use uint8_t consistently for identifying ABI/arch in SFrame format. 42327 42328 bfd/ 42329 * elf-sframe.c (_bfd_elf_merge_section_sframe): 42330 libsframe/ 42331 * sframe-dump.c (is_sframe_abi_arch_aarch64): Use uint8_t for 42332 local variable. 42333 * sframe.c (sframe_decoder_get_abi_arch): Update return type to 42334 uint8_t. 42335 (sframe_encoder_get_abi_arch): Likewise. 42336 include/ 42337 * sframe-api.h (sframe_decoder_get_abi_arch): Likewise. 42338 (sframe_encoder_get_abi_arch): Likewise. 42339 423402023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42341 42342 libsframe: bfd: use uint32_t for return type of sframe_calc_fre_type 42343 Use uint32_t type alias consistently for all APIs in libsframe. 42344 42345 bfd/ 42346 * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for the 42347 changed return type. 42348 libsframe/ 42349 * sframe.c (sframe_calc_fre_type): Use uint32_t for return type. 42350 include/ 42351 * sframe-api.h (sframe_calc_fre_type): Likewise. 42352 423532023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42354 42355 libsframe: use uint32_t for fre_type and fde_type function args 42356 The API sframe_fde_create_func_info is provided by libsframe. Current 42357 users are the bfd linker. Adjust the argument type for the variables 42358 carrying the SFrame FRE type and SFrame FDE type to consistenly use 42359 uint32_t type alias. 42360 42361 include/ 42362 * sframe-api.h (sframe_fde_create_func_info): Use uint32_t 42363 instead of unsigned int. 42364 libsframe/ 42365 * sframe.c (sframe_get_fre_type): Likewise. 42366 (sframe_get_fde_type): Likewise. 42367 (flip_fre_start_address): Likewise. 42368 (sframe_fre_start_addr_size): Likewise. 42369 (sframe_fre_entry_size): Likewise. 42370 (flip_fre): Likewise. 42371 (flip_sframe): Likewise. 42372 (sframe_fde_create_func_info): Likewise. 42373 (sframe_calc_fre_type): Likewise. 42374 (sframe_decode_fre_start_address): Likewise. 42375 (sframe_decode_fre): Likewise. 42376 (sframe_find_fre): Likewise. 42377 (sframe_decoder_get_fre): Likewise. 42378 (sframe_encoder_add_fre): Likewise. 42379 (sframe_encoder_write_fre_start_addr): Likewise. 42380 (sframe_encoder_write_fre): Likewise. 42381 (sframe_encoder_write_sframe): Likewise. 42382 423832023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42384 42385 libsframe: update the semantics of sframe_fre_get_fp_offset 42386 Until now, sframe_fre_get_fp_offset () would return 42387 SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed FP offset. A stack 42388 tracer, then, would call an explicit sframe_decoder_get_fixed_fp_offset () 42389 to get the FP offset. 42390 42391 On second look, it appears to make sense to hide these details of 42392 whether the FP offset is fixed or not in an ABI from the consumer. Now, 42393 with the changed semantics, the call to sframe_fre_get_fp_offset () will 42394 fetch the fixed FP offset if applicable, or get the FP offset from FRE 42395 when there is no fixed FP offset. 42396 42397 This patch changes the behavior of sframe_fre_get_fp_offset (): it turns 42398 an error into non-error. This change will be included with the next 42399 release of libsframe, where all the exposed symbols will be versioned 42400 with version node LIBSFRAME_1.0 for the first time. 42401 42402 libsframe/ 42403 * sframe.c (sframe_fre_get_fp_offset): Return the fixed offset, if 42404 applicable. Else return the FP offset from the FRE. 42405 424062023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42407 42408 libsframe: update the semantics of sframe_fre_get_ra_offset 42409 Until now, sframe_fre_get_ra_offset () would return 42410 SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed RA offset (e.g., 42411 AMD64). A stack tracer, then, will call an explicit 42412 sframe_decoder_get_fixed_ra_offset () to get the RA offset. 42413 42414 On second look, it appears to make sense to hide these details of 42415 whether the RA offset is fixed or not from the consumer. Now, with the 42416 changed semantics, the call to sframe_fre_get_ra_offset () will fetch 42417 the fixed RA offset if applicable, or get the RA offset from FRE when 42418 there is no fixed RA offset. 42419 42420 Adjustments need to be made to ensure the textual dump remains the same 42421 as preivous. Currently, e.g., if RA is not being tracked per FRE, 42422 following is seen with objdump --sframe: 42423 42424 STARTPC CFA FP RA 42425 000000000000NNNN sp+X u u 42426 42427 This patch changes the behavior of sframe_fre_get_ra_offset: it turns an 42428 error into non-error. This change will be included with the next 42429 release of libsframe, where all exposed symbols will be versioned for 42430 the first time. 42431 42432 libsframe/ 42433 * sframe.c (sframe_fre_get_ra_offset): Return the fixed offset, 42434 if applicable. Else return the RA offset from the FRE. 42435 * sframe-dump.c (dump_sframe_func_with_fres): Make adjustments 42436 to keep the textual dump same as previous. 42437 424382023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42439 42440 libsframe: add symbol versioning 42441 Define an empty base version LIBSFRAME_0.0 and add all symbols to 42442 version LIBSFRAME_1.0. 42443 42444 The previous release of libsframe (libsframe.so.0) did not have 42445 versioned symbols. Adding a libsframe.ver file so that future releases 42446 of the library (and its consumers) can manage the changes better. 42447 42448 For Solaris ld, use -M mapfile command line option. libsframe does not 42449 restrict the set of exported symbols, so at this time there is no need 42450 to fall back on the libtool's -export-symbols option for platforms where 42451 some other linker (with a different command line option for symbol 42452 versioning) may be used. 42453 42454 libsframe/ 42455 * Makefile.am: Use symbol versioning for libsframe. 42456 * Makefile.in: Regenerated. 42457 * configure: Check for Solaris ld. 42458 * configure.ac: Regenerated. 42459 * libsframe.ver: New file. 42460 424612023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42462 42463 libsframe: remove sframe_get_funcdesc_with_addr API 42464 This is an incompatible ABI change in libsframe. 42465 42466 The interface provided by this function is not a healthy abstraction to 42467 expose: the return type sframe_func_desc_entry, which is defined in 42468 include/sframe.h (the SFrame binary format definition). This ties up 42469 the library in a undesirable way. Most importantly, this function 42470 should technically not be directly necessary for a stack tracer. A 42471 stack tracer will likely only need to do a sframe_find_fre (). 42472 42473 Rename the API to continue to use the functionality internally in the 42474 library. bfd/linker does not use this function. 42475 42476 Change the return type of the previous definition and make a note about 42477 its planned deprecation. 42478 42479 include/ 42480 * sframe-api.h: Change return type of sframe_get_funcdesc_with_addr. 42481 Add comment for intention to deprecate. 42482 libsframe/ 42483 *sframe.c (sframe_get_funcdesc_with_addr): Change return type 42484 and set error code. This API is deprecated. 42485 (sframe_get_funcdesc_with_addr_internal): New definition for 42486 internal use. 42487 (sframe_find_fre): Use sframe_get_funcdesc_with_addr_internal 42488 instead. 42489 424902023-06-27 Indu Bhagat <indu.bhagat@oracle.com> 42491 42492 libsframe: add library versioning 42493 lisbframe was first released with Bintuils 2.40. As the library 42494 evolves, some changes will break the ABI. Add library versioning for 42495 users to manage these changes. 42496 42497 For the next release of the library (libsframe.so.1), incompatible ABI 42498 changes are planned. These will include: 42499 - Deprecation of some APIs, like sframe_get_funcdesc_with_addr (), and 42500 - Change in the contract of some APIs (e.g., return type, behavior). 42501 42502 In libtool-version, set the current to 1 to prepare for the upcoming 42503 release. Reset revision and age to 0. 42504 42505 Add libtool-version file to EXTRA_DIST. 42506 42507 libsframe/ 42508 * Makefile.am: Use libtool versioning. 42509 * Makefile.in: Regenerated. 42510 * libtool-version: New file. 42511 425122023-06-27 Philipp Tomsich <philipp.tomsich@vrull.eu> 42513 42514 RISC-V: Support Zicond extension 42515 This implements the Zicond (conditional integer operations) extension, 42516 as of version 1.0-rc2. 42517 42518 The Zicond extension acts as a building block for branchless sequences 42519 including conditional-arithmetic, conditional-logic and 42520 conditional-select/move. 42521 The following instructions constitute Zicond: 42522 - czero.eqz rd, rs1, rs2 => rd = (rs2 == 0) ? 0 : rs1 42523 - czero.nez rd, rs1, rs2 => rd = (rs2 != 0) ? 0 : rs1 42524 42525 See 42526 https://github.com/riscv/riscv-zicond/releases/download/v1.0-rc2/riscv-zicond-v1.0-rc2.pdf 42527 for the proposed specification and usage details. 42528 42529 bfd/ChangeLog: 42530 42531 * elfxx-riscv.c (riscv_multi_subset_supports): Recognize 42532 INSN_CLASS_ZICOND. 42533 (riscv_multi_subset_supports_ext): Recognize INSN_CLASS_ZICOND. 42534 42535 gas/ChangeLog: 42536 42537 * testsuite/gas/riscv/zicond.d: New test. 42538 * testsuite/gas/riscv/zicond.s: New test. 42539 42540 include/ChangeLog: 42541 42542 * opcode/riscv-opc.h (MATCH_CZERO_EQZ): Define. 42543 (MASK_CZERO_EQZ): Define. 42544 (MATCH_CZERO_NEZ): Define, 42545 (MASK_CZERO_NEZ): Define. 42546 (DECLARE_INSN): Add czero.eqz and czero.nez. 42547 * opcode/riscv.h (enum riscv_insn_class): Add 42548 INSN_CLASS_ZICOND. 42549 42550 opcodes/ChangeLog: 42551 42552 * riscv-opc.c: Add czero.eqz and czero.nez. 42553 42554 Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> 42555 425562023-06-27 Nick Clifton <nickc@redhat.com> 42557 42558 Add note about adding ChangeLog.git to src-release.sh 42559 425602023-06-27 Cui, Lili <lili.cui@intel.com> 42561 42562 gprofng: Update intel url 42563 Since the old software.intel.com has been removed, update a new one. 42564 42565 gprofng/ChangeLog 42566 2023-06-27 Lili Cui <lili.cui@intel.com> 42567 42568 * gp-display-html/gp-display-html.in: Update intel url. 42569 425702023-06-27 GDB Administrator <gdbadmin@sourceware.org> 42571 42572 Automatic date update in version.in 42573 425742023-06-26 Nick Clifton <nickc@redhat.com> 42575 42576 Fix gas tests for aarch64-pe 42577 42578 Synchromize libiberty sources with master version in gcc repository 42579 42580 Sync config.guess and config.sub with upstream master versions. 42581 42582 Updated French translation for the gprof sub-directory 42583 425842023-06-26 GDB Administrator <gdbadmin@sourceware.org> 42585 42586 Automatic date update in version.in 42587 425882023-06-25 Feiyang Chen <chenfeiyang@loongson.cn> 42589 42590 LoongArch: Support referring to FCSRs as $fcsrX 42591 Previously, FCSRs were referred to as $rX, which seemed strange. 42592 We refer to FCSRs as $fcsrX, which ensures compatibility with LLVM 42593 IAS as well. 42594 42595 gas/ChangeLog: 42596 42597 * config/tc-loongarch.c: 42598 (loongarch_fc_normal_name): New definition. 42599 (loongarch_fc_numeric_name): New definition. 42600 (loongarch_single_float_opcodes): Modify `movgr2fcsr` and 42601 `movfcsr2gr`. 42602 testsuite/gas/loongarch/float_op.d: Likewise. 42603 testsuite/gas/loongarch/float_op.s: Likewise. 42604 42605 include/ChangeLog: 42606 42607 * opcode/loongarch.h: 42608 (loongarch_fc_normal_name): New extern. 42609 (loongarch_fc_numeric_name): New extern. 42610 42611 opcodes/ChangeLog: 42612 42613 * opcodes/loongarch-dis.c (loongarch_after_parse_args): Support 42614 referring to FCSRs as $fcsrX. 42615 * opcodes/loongarch-opc.c (loongarch_args_parser_can_match_arg_helper): 42616 Likewise. 42617 426182023-06-25 GDB Administrator <gdbadmin@sourceware.org> 42619 42620 Automatic date update in version.in 42621 426222023-06-24 GDB Administrator <gdbadmin@sourceware.org> 42623 42624 Automatic date update in version.in 42625 426262023-06-23 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 42627 42628 gdb/testsuite: Avoid infinite loop in gdb.reverse/step-reverse.exp 42629 This testcase sometimes gets stuck in a loop for hours when running in our 42630 CI. The problem is that due to an issue unrelated to reverse debugging the 42631 inferior exits early, and because of the overly generic ".*" pattern the 42632 testcase keeps sending the "next" command without noticing that the 42633 inferior is gone. 42634 42635 gdb_test_multiple has a pattern to detect that "The program is not being 42636 run.", but since it is placed after the patterns from the caller it won't 42637 be triggered. It also has a timeout pattern but because it is triggered 42638 between successful matches, each time the test matches the '-re -wrap ".*"' 42639 this counts as a successful match and the timeout is reset. 42640 42641 Since the test binary is compiled with debug information, fix by changing 42642 one of the generic patterns to match entering the main function and the 42643 other one to match the source code line number that is shown by GDB right 42644 after the "step" command. 42645 42646 Also, as a precaution add a maximum number of times the "next" command will 42647 be sent. 42648 42649 Co-Authored-By: Tom de Vries <tdevries@suse.de> 42650 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 42651 Approved-By: Tom de Vries <tdevries@suse.de> 42652 426532023-06-23 Alan Modra <amodra@gmail.com> 42654 42655 [GOLD] PowerPC64 huge branch dynamic relocs 42656 PowerPC64 gold and ld.bfd implement an indirect branch trampoline, 42657 used when the destination of a branch exceeds a bounce through another 42658 "b" instruction. When generating PIEs or shared libraries, the 42659 addresses need dynamic relocations. This was implemented in gold 42660 using a dedicated relocation section, but this means the relative 42661 relocations for these addresses are not sorted properly with other 42662 dynamic relative relocations: gold doesn't support merging relocation 42663 sections, then sorting. Instead we need to use a single .rela.dyn 42664 section. 42665 42666 This is done by increasing the size of rela_dyn_ during do_relax to 42667 account for needed dynamic relocations, delaying adding the actual 42668 relocations until the end of relaxation once the layout has 42669 stabilised. 42670 42671 * powerpc.cc (Target_powerpc): Add rela_dyn_size_; 42672 (update_current_size): New function. 42673 (Target_powerpc::do_relax): Capture the size of rela_dyn_ at 42674 the start of relaxation. Artifically increase its size during 42675 relaxation to account for needed indirect branches, and add 42676 those relocations at the end. 42677 (Output_data_brlt_powerpc::rel_, reset_brlt_sizes), 42678 (finalize_brlt_sizes, add_reloc, set_current_size): Delete. 42679 (Target_powerpc::make_brlt_section): Don't make reloc section. 42680 426812023-06-23 Alan Modra <amodra@gmail.com> 42682 42683 [GOLD] Support setting DT_RELACOUNT late 42684 PowerPC gold adds relative dynamic relocs in do_relax. These aren't 42685 accounted for in the value set in add_target_dynamic_tags, which is 42686 called before do_relax. Provide a way of setting DT_RELCOUNT and 42687 DT_RELACOUNT at the point where .dynamic is written. 42688 42689 * layout.cc (Layout::add_target_dynamic_tags): Add custom_relcount 42690 parameter. Emit DT_RELCOUNT/RELACOUNT as a custom target handled 42691 dynamic tag if set. 42692 * layout.h(Layout::add_target_dynamic_tags): Update prototype. 42693 * aarch64.cc (Target_aarch64::do_finalize_sections): Adjust 42694 add_target_dynamic_tags call. 42695 * arm.cc (Target_arm::do_finalize_sections): Likewise. 42696 * i386.cc (Target_i386::do_finalize_sections): Likewise. 42697 * mips.cc (Target_mips::do_finalize_sections): Likewise. 42698 * s390.cc (Target_s390::do_finalize_sections): Likewise. 42699 * sparc.cc (Target_sparc::do_finalize_sections): Likewise. 42700 * tilegx.cc (Target_tilegx::do_finalize_sections): Likewise. 42701 * x86_64.cc (Target_x86_64::do_finalize_sections): Likewise. 42702 * powerpc.cc (Target_powerpc::do_finalize_sections): Likewise. 42703 (Target_powerpc::do_dynamic_tag_custom_value): New function. 42704 427052023-06-23 Alan Modra <amodra@gmail.com> 42706 42707 [GOLD] powerpc DT_RELACOUNT 42708 DT_RELACOUNT was calculated incorrectly, and relative relocs not 42709 sorted as they should be to the start of .rela.dyn, due to adding one 42710 particular class of dynamic reloc using the wrong "add" method. 42711 42712 * powerpc.cc (Target_powerpc::Scan::global): Add relative 42713 dyn relocs for ADDR64 and similar using add_global_relative. 42714 427152023-06-23 Alan Modra <amodra@gmail.com> 42716 42717 lto test fails with -fno-inline in CFLAGS 42718 Putting -fno-inline in CFLAGS results in these failures. 42719 FAIL: Build liblto-17b.so 1 42720 FAIL: PR ld/12365 42721 FAIL: PR ld/13183 42722 42723 * ld-plugin/lto.exp: Add -finline to compiler flags in some tests. 42724 427252023-06-23 Tom Tromey <tom@tromey.com> 42726 42727 Fix off-by-one error 42728 Simon pointed out that commit a2bbca9fa5e ("Use std::vector<bool> for 42729 agent_expr::reg_mask") caused a regression in libstdc++ debug mode. 42730 This was due to an off-by-one error in a vector resize. This patch 42731 fixes the problem. 42732 427332023-06-23 GDB Administrator <gdbadmin@sourceware.org> 42734 42735 Automatic date update in version.in 42736 427372023-06-22 Ilya Leoshkevich <iii@linux.ibm.com> 42738 42739 gdb/testsuite: fix gdb.python/py-unwind.exp with python >= 3.11 42740 Python 3.11 changed the AttributeError message - see commit 42741 0cb765b2cec9 ("bpo-46730: Add more info to @property AttributeError 42742 messages (GH-31311)"). Add the new message to the expectations. 42743 42744 Approved-By: Tom Tromey <tom@tromey.com> 42745 Link: https://sourceware.org/pipermail/gdb-patches/2023-June/200433.html 42746 427472023-06-22 H.J. Lu <hjl.tools@gmail.com> 42748 42749 Revert "x86: Don't check if AVX512 template requires AVX512VL" 42750 This reverts commit c7face14225296a2f5d3ebeb8ace88c166d80c3e. 42751 427522023-06-22 Tom de Vries <tdevries@suse.de> 42753 42754 [gdb/testsuite] Clean or check standard_output_file dir in gdb_init 42755 In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in 42756 gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some 42757 files at the start of the test-case: 42758 ... 42759 remote_file host delete [standard_output_file prog.o] 42760 remote_file host delete [standard_output_file prog.ali] 42761 ... 42762 42763 Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in 42764 gdb_init") I tried to do this more structurally, by cleaning up the entire 42765 standard_output_file directory, for all test-cases. 42766 42767 This caused a regression when using "make check -j 2", due to the cleanup 42768 removing the active gdb.log, so I reverted the commit. 42769 42770 Try again, this time handling the two cases separately. 42771 42772 If the standard_output_file directory contains an active gdb.log, check that 42773 the directory contains no files other than gdb.log and gdb.sum. This puts 42774 the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in 42775 which use --outdir. 42776 42777 If the standard_output_file directory doesn't contain an active gdb.log, clean 42778 it by removing the entire directory. 42779 42780 An exception is made for performance tests, where cleaning up the 42781 standard_output_file dir is the wrong thing to do, because an invocation with 42782 GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an 42783 earlier invocation with GDB_PERFTEST_MODE == compile. 42784 42785 Tested on x86_64-linux. 42786 42787 Suggested-By: Tom Tromey <tom@tromey.com> 42788 Reviewed-By: Tom Tromey <tom@tromey.com> 42789 Tested-By: Luis Machado <luis.machado@arm.com> 42790 427912023-06-22 Tom Tromey <tromey@adacore.com> 42792 42793 Implement DAP "hover" context 42794 A DAP client can request that an expression be evaluated in "hover" 42795 context, meaning that it should not cause side effects. In gdb, this 42796 can be implemented by temporarily setting a few "may-" parameters to 42797 "off". 42798 42799 In order to make this work, I had to also change "may-write-registers" 42800 so that it can be changed while the program is running. I don't think 42801 there was any reason for this prohibition in the first place. 42802 42803 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30476 42804 428052023-06-22 Tom Tromey <tromey@adacore.com> 42806 42807 Implement DAP logging breakpoints 42808 DAP allows a source breakpoint to specify a log message. When this is 42809 done, the breakpoint acts more like gdb's dprintf: it logs a message 42810 but does not cause a stop. 42811 42812 I looked into implement this using dprintf with the new %V printf 42813 format. However, my initial attempt at this did not work, because 42814 when the inferior is continued, the dprintf output is captured by the 42815 gdb.execute call. Maybe this could be fixed by having all 42816 inferior-continuation commands use the "&" form; the main benefit of 42817 this would be that expressions are only parsed a single time. 42818 428192023-06-22 Tom Tromey <tromey@adacore.com> 42820 42821 Handle supportsVariablePaging in DAP 42822 A bug report about the supportsVariablePaging capability in DAP 42823 resulted in a clarification: when this capability is not present, DAP 42824 implementations should ignore the paging parameters to the "variables" 42825 request. This patch implements this clarification. 42826 42827 Implement type checking for DAP breakpoint requests 42828 I realized that with a small refactoring, it is possible to type-check 42829 the parameters to the various DAP breakpoint requests. This would 42830 have caught the earlier bug involving hitCondition. 42831 42832 Handle exceptions when creating DAP breakpoints 42833 When creating a DAP breakpoint, a failure should be returned by 42834 setting "verified" to False. gdb didn't properly implement this, and 42835 there was a FIXME comment to this effect. This patch fixes the 42836 problem. 42837 42838 Reuse breakpoints more frequently in DAP 42839 The DAP breakpoint code tries to reuse a breakpoint when possible. 42840 Currently it uses the condition and the hit condition (aka ignore 42841 count) when making this determination. However, these attributes are 42842 just going to be reset anyway, so this patch changes the code to 42843 exclude these from the reuse decision. 42844 42845 Fix type of DAP hitCondition 42846 DAP specifies a breakpoint's hitCondition as a string, meaning it is 42847 an expression to be evaluated. However, gdb implemented this as if it 42848 were an integer instead. This patch fixes this oversight. 42849 428502023-06-22 Simon Farre <simon.farre.cx@gmail.com> 42851 42852 gdb/DAP Few bug fixes & Evaluate Array Watch vars 42853 v2. 42854 42855 EvaluateResult does not need a name, just as what Tom pointed out in 42856 previous review. It's only the *children* that need to be made sure that 42857 their names are valid. An identifier for a variable, can't ever have an 42858 integer as a name, anyhow (not as far as I am aware, no programming 42859 languages allow for that). 42860 42861 Removed the f-strings and use str() instead as pointed out that 42862 f-strings might not be supported fully. 42863 42864 v1. 42865 42866 This patch fixes a few bugs. 42867 42868 First of all, name of VariableReferences must always be of string type. 42869 This patch makes sure that this is the case by formatting the name. If 42870 (when) the name is an integer, this will cause clients to fail or throw 42871 errors. 42872 42873 Fixes a bug in NoOpArrayPrinter that calculated children to be N, but 42874 only ever retrieves N-1 children, which makes Python at some time later 42875 (during fetch_children -> fetch_one_child(N) ) raise an exception (out 42876 of list index) which makes the entire request go bad. 42877 42878 The result[self.result_name] also f-strings the printer.to_string() 42879 value, because this can potentially be a LazyString (which is a Python 42880 object, not a string) and is not serializable by json.dumps. 42881 42882 Approved-By: Tom Tromey <tom@tromey.com> 42883 428842023-06-22 GDB Administrator <gdbadmin@sourceware.org> 42885 42886 Automatic date update in version.in 42887 428882023-06-21 H.J. Lu <hjl.tools@gmail.com> 42889 42890 x86: Free the symbol buffer and the relocation buffer after use 42891 When --no-keep-memory is used, the symbol buffer and the relocation 42892 buffer aren't cached. When packing relative relocations, we may 42893 allocate a new symbol buffer and a new relocation buffer for each 42894 eligible section in an object file. If there are many sections, 42895 memory may be exhausted. In this case, we should free the symbol 42896 buffer and the relocation buffer after use. If symbol buffer entries 42897 are used to track relative relocations against local symbols for later 42898 use, the symbol buffer should be cached. 42899 42900 PR ld/30566 42901 * elfxx-x86.c (elf_x86_relative_reloc_record_add): Add an 42902 argument to inform caller if the symbol buffer should be kept. 42903 (_bfd_x86_elf_link_relax_section): Call 42904 _bfd_elf_link_info_read_relocs instead of 42905 _bfd_elf_link_read_relocs. Free the symbol buffer and the 42906 relocation buffer after use. Cache the symbol buffer if it 42907 is used. 42908 429092023-06-21 Tom Tromey <tromey@adacore.com> 42910 42911 Add missing backslash to update-gnulib.sh 42912 A user on irc noticed a missing backslash on one line in 42913 update-gnulib.sh. This patch adds it. 42914 42915 Re-running update-gnulib.sh causes a few copyright notices to change. 42916 Presumably these are from upstream gnulib and shouldn't be touched by 42917 our yearly update. I've updated the script to account for this, but I 42918 did not want to try testing it... 42919 429202023-06-21 Tom de Vries <tdevries@suse.de> 42921 42922 [gdb/testsuite] Add have_host_locale 42923 With test-case gdb.tui/pr30056.exp, I run into: 42924 ... 42925 sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M 42926 ... 42927 and then subsequently into: 42928 ... 42929 WARNING: timeout in accept_gdb_output 42930 FAIL: gdb.tui/pr30056.exp: Control-C 42931 ... 42932 42933 This is on a CentOS 7 distro for powerpc64le. 42934 42935 Either it has no C.UTF-8 support, or it's not installed: 42936 ... 42937 $ locale -a | grep ^C 42938 C 42939 $ 42940 ... 42941 42942 Fix this by: 42943 - adding a new proc have_host_locale, and 42944 - using it in all test-cases using setenv LC_ALL. 42945 42946 Tested on powerpc64le-linux and x86_64-linux. 42947 429482023-06-21 Tom de Vries <tdevries@suse.de> 42949 42950 [gdb/testsuite] Fix gdb.tui/wrap-line.exp 42951 PR testsuite/30458 reports the following FAIL: 42952 ... 42953 PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap 42954 ^CQuit 42955 (gdb) WARNING: timeout in accept_gdb_output 42956 Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3): 42957 0 Quit 42958 1 (gdb) 7890123456789012345678901234567890123456789 42959 2 W^CQuit 42960 3 (gdb) 42961 ... 42962 FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap 42963 ... 42964 42965 The problem is that the regexp doesn't account for the ^C: 42966 ... 42967 gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap" 42968 ... 42969 42970 The ^C occurs occasionally. This is something we'd like to fix. It's 42971 reported as a readline problem here ( 42972 https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html ). 42973 42974 For now, fix this by updating the regexp, and likewise in another place in the 42975 test-case where we use ^C. 42976 42977 Tested on x86_64-linux. 42978 42979 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458 42980 429812023-06-21 Alan Modra <amodra@gmail.com> 42982 42983 PR30536, ppc64el gold linker produces unusable clang-16 binary 42984 In commit 0961e631575b, the fix for PR30217, make_lplt_section and 42985 make_brlt_section were changed to use rela_dyn_ rather than their own 42986 separate dynamic reloc sections. This fails miserably whenever brlt_ 42987 is needed for long branches, due to needing to iterate sizing and thus 42988 reset brlt_ sizes. 42989 42990 PR 30536 42991 PR 30217 42992 * powerpc.cc (Target_powerpc::make_brlt_section): Don't use 42993 rela_dyn_. 42994 429952023-06-21 Tom de Vries <tdevries@suse.de> 42996 42997 [gdb/testsuite] Reimplement Term::command_no_prompt_prefix 42998 Say we run test-case gdb.tui/basic.exp. It calls Term::enter_tui, which does: 42999 ... 43000 command_no_prompt_prefix "tui enable" 43001 ... 43002 43003 The proc command_no_prompt_prefix is documented as: 43004 ... 43005 # As proc command, but don't wait for an initial prompt. This is used for 43006 # initial terminal commands, where there's no prompt yet. 43007 ... 43008 43009 Indeed, before the "tui enable" command, the tuiterm is empty, so there is no 43010 prompt and just before switching to TUI we have in the tuiterm: 43011 ... 43012 tui enable 43013 ... 43014 43015 The reason that there is no prompt, is that: 43016 - in order for tuiterm to show something, its input processing procs need to 43017 be called, and 43018 - the initial gdb prompt, and subsequent prompts generated by gdb_test-style 43019 procs, are all consumed by those procs instead. 43020 43021 This is in principle not a problem, but the absence of a prompt makes a 43022 tuiterm session look less like a session on an actual xterm. 43023 43024 Add a new proc gen_prompt, that: 43025 - generates a prompt using echo 43026 - consumes the response before the prompt using gdb_expect 43027 - consumes the prompt using Term::wait_for "". 43028 43029 This allows us to reimplement Term::command_no_prompt_prefix using 43030 Term::command, and just before switching to TUI we have in the tuiterm: 43031 ... 43032 (gdb) tui enable 43033 ... 43034 43035 Tested on x86_64-linux. 43036 430372023-06-21 Tom de Vries <tdevries@suse.de> 43038 43039 [gdb/testsuite] Make Term::wait_for "" match only a prompt 43040 The semantics of Term::wait_for is: 43041 ... 43042 # Accept some output from gdb and update the screen. WAIT_FOR is 43043 # a regexp matching the line to wait for. Return 0 on timeout, 1 43044 # on success. 43045 proc wait_for {wait_for} { 43046 ... 43047 43048 Note that besides the regexp, also a subsequent gdb prompt is matched. 43049 43050 I recently used wait_for "" in a few test-cases, thinking that this would 43051 match just a prompt, but in fact that's not the case. 43052 43053 Fix this in wait_for, and add a corresponding test in gdb.tui/tuiterm-2.exp. 43054 43055 Tested on x86_64-linux. 43056 430572023-06-21 Nick Clifton <nickc@redhat.com> 43058 43059 Prune linker warnings about an executable stack being created with the -z execstack option. 43060 * testsuite/lib/binutils-common.exp (prune_warnings_extra): Prune warnings about -z execstack creating an executable stack. 43061 43062 For test for PR 29072 when the linker is configured with --enable-default-execstack=no. 43063 PR 29072 43064 * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Always return false for linkers configured with the --enable-default-execstack=no option. 43065 430662023-06-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 43067 43068 gdbserver: use target_waitstatus::to_string in 'prepare_resume_reply' 43069 Use the to_string method of target_waitstatus in 43070 'prepare_resume_reply' for a more readable log message. 43071 43072 Approved-By: Tom Tromey <tom@tromey.com> 43073 430742023-06-21 Jan Beulich <jbeulich@suse.com> 43075 43076 x86: fix expansion of %XV 43077 Only %LV should continue on to S handling; avoid emitting a stray 'l' 43078 (typically) in suffix-always mode. 43079 430802023-06-21 Alan Modra <amodra@gmail.com> 43081 43082 elf32_arm_get_synthetic_symtab memory leak 43083 ARM get_synthetic_symtab reads .plt and caches that data. Caching the 43084 data doesn't make a lot of sense since get_synthetic_symtab is only 43085 called once per bfd, and the memory might be put to better use. It 43086 also leaks on closing the bfd. 43087 43088 * elf32-arm.c (elf32_arm_get_synthetic_symtab): Don't cache 43089 plt contents. Free plt data before returning. 43090 430912023-06-21 Alan Modra <amodra@gmail.com> 43092 43093 macho-o.c don't leak strtab 43094 * mach-o.c (bfd_mach_o_write_symtab_content): Free strtab on 43095 success path. 43096 430972023-06-21 GDB Administrator <gdbadmin@sourceware.org> 43098 43099 Automatic date update in version.in 43100 431012023-06-20 Tom Tromey <tom@tromey.com> 43102 43103 Use ARRAY_SIZE in ax-general.c 43104 This changes a couple of spots in ax-general.c to use ARRAY_SIZE. 43105 While making this change, I noticed that one of the bounds checks was 43106 incorrect. 43107 43108 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43109 431102023-06-20 Tom Tromey <tom@tromey.com> 43111 43112 Remove aop_last 43113 aop_last is only used for an assertion. However, due to the '.def' 43114 construct in the sources, this assert could never plausibly trigger 43115 (the assert predates the use of a .def file here). This patch removes 43116 the constant and the assert. 43117 43118 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43119 431202023-06-20 Tom Tromey <tom@tromey.com> 43121 43122 Make aop_map 'static' 43123 This changes aop_map to be 'static'. 43124 43125 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43126 431272023-06-20 Tom Tromey <tom@tromey.com> 43128 43129 Use bool for agent_expr::tracing 43130 This changese agent_expr::tracing to have type bool, allowing inline 43131 initialization and cleaning up the code a little. 43132 43133 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43134 431352023-06-20 Tom Tromey <tom@tromey.com> 43136 43137 Simplify agent_expr constructor 43138 This simplifies the agent_expr constructor a bit, and removes the 43139 destructor entirely. 43140 43141 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43142 431432023-06-20 Tom Tromey <tom@tromey.com> 43144 43145 Use std::vector<bool> for agent_expr::reg_mask 43146 agent_expr::reg_mask implements its own packed boolean vector. This 43147 patch replaces it with a std::vector<bool>, simplifying the code. 43148 43149 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43150 431512023-06-20 Tom Tromey <tom@tromey.com> 43152 43153 Use gdb::byte_vector in agent_expr 43154 This changes agent_expr to use gdb::byte_vector rather than manually 43155 reimplementing a vector. 43156 43157 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43158 431592023-06-20 Tom Tromey <tom@tromey.com> 43160 43161 Remove mem2hex 43162 tracepoint.c has a 'mem2hex' function that is functionally equivalent 43163 to bin2hex. This patch removes the redundancy. 43164 43165 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43166 431672023-06-20 H.J. Lu <hjl.tools@gmail.com> 43168 43169 x86: Don't check if AVX512 template requires AVX512VL 43170 If the ZMM operand in an AVX12 template also allows XMM or ZMM, this 43171 template must require AVX512VL. Drop the AVX512VL requirement check 43172 on such AVX512 templates. 43173 43174 * config/tc-i386.c (check_VecOperands): Don't check if AVX512 43175 template requires AVX512VL. 43176 431772023-06-20 Tom Tromey <tom@tromey.com> 43178 43179 Use std::string in do_set_command 43180 do_set_command manually updates a string, only to copy it to a 43181 std::string and free the working copy. This patch changes this code 43182 to use std::string for everything, simplifying the code and removing a 43183 copy. 43184 43185 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43186 431872023-06-20 Tom Tromey <tom@tromey.com> 43188 43189 Use byte_vector in remote.c:readahead_cache 43190 This patch changes the remote.c readahead_cache to use 43191 gdb::byte_vector. This simplifies the code by removing manual memory 43192 management. 43193 43194 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43195 431962023-06-20 Tom Tromey <tom@tromey.com> 43197 43198 Use std::string in linux-osdata.c 43199 I found some code in linux-osdata that manually managed a string. 43200 Replacing this with std::string simplifies it. 43201 43202 Reviewed-by: John Baldwin <jhb@FreeBSD.org> 43203 432042023-06-20 Tom Tromey <tromey@adacore.com> 43205 43206 Use unique_xmalloc_ptr for mi_parse::command 43207 This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up 43208 all the uses. This avoids some manual memory management. std::string 43209 is not used here due to how the Python API works -- this approach 43210 avoids an extra copy there. 43211 43212 Reviewed-by: Keith Seitz <keiths@redhat.com> 43213 432142023-06-20 Tom Tromey <tromey@adacore.com> 43215 43216 Use std::string for MI token 43217 This changes the MI "token" to be a std::string, removing some manual 43218 memory management. It also makes current_token 'const' in order to 43219 support this change. 43220 43221 Reviewed-by: Keith Seitz <keiths@redhat.com> 43222 432232023-06-20 Alan Modra <amodra@gmail.com> 43224 43225 Don't segfault in mips reloc special_functions 43226 A symbol defined in a section from a shared library will have a NULL 43227 section->output_section during linking. 43228 43229 * elf32-mips.c (gprel32_with_gp): Don't segfault on NULL 43230 symbol->section->output_section. 43231 * elf64-mips.c (mips_elf64_gprel32_reloc): Likewise. 43232 * elfn32-mips.c (mips_elf_gprel16_reloc): Likewise. 43233 (mips_elf_literal_reloc, mips_elf_gprel32_reloc): Likewise. 43234 (gprel32_with_gp, mips16_gprel_reloc): Likewise. 43235 * elfxx-mips.c (_bfd_mips_elf_gprel16_with_gp): Likewise. 43236 (_bfd_mips_elf_generic_reloc): Likewise. 43237 432382023-06-20 GDB Administrator <gdbadmin@sourceware.org> 43239 43240 Automatic date update in version.in 43241 432422023-06-19 Tom de Vries <tdevries@suse.de> 43243 43244 Revert "[gdb/testsuite] Clean standard_output_file dir in gdb_init" 43245 This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557. 43246 432472023-06-19 Simon Farre <simon.farre.cx@gmail.com> 43248 43249 Fixes 28ab59607ef40b9571c0702ffba8f6aa6fb1b033 43250 Python formatting errors fixed, introduced by this commit. 43251 43252 Fixes f1a614dc8f015743e9fe7fe5f3f019303f8db718 43253 Fixes failure reported by buildbot regarding ill-formatted Python code. 43254 432552023-06-19 Simon Farre <simon.farre.cx@gmail.com> 43256 43257 gdb/Python: Added ThreadExitedEvent 43258 v6: 43259 Fix comments. 43260 Fix copyright 43261 Remove unnecessary test suite stuff. save_var had to stay, as it mutates 43262 some test suite state that otherwise fails. 43263 43264 v5: 43265 Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/ 43266 43267 v4: 43268 Doc formatting fixed. 43269 43270 v3: 43271 Eli: 43272 Updated docs & NEWS to reflect new changes. Added 43273 a reference from the .ptid attribute of the ThreadExitedEvent 43274 to the ptid attribute of InferiorThread. To do this, 43275 I've added an anchor to that attribute. 43276 43277 Tom: 43278 Tom requested that I should probably just emit the thread object; 43279 I ran into two issues for this, which I could not resolve in this patch; 43280 43281 1 - The Thread Object (the python type) checks it's own validity 43282 by doing a comparison of it's `thread_info* thread` to nullptr. This 43283 means that any access of it's attributes may (probably, since we are 43284 in "async" land) throw Python exceptions because the thread has been 43285 removed from the thread object. Therefore I've decided in v3 of this 43286 patch to just emit most of the same fields that gdb.InferiorThread has, namely 43287 global_num, name, num and ptid (the 3-attribute tuple provided by 43288 gdb.InferiorThread.ptid). 43289 43290 2 - A python user can hold a global reference to an exiting thread. Thus 43291 in order to have a ThreadExit event that can provide attribute access 43292 reliably (both as a global reference, but also inside the thread exit 43293 handler, as we can never guarantee that it's executed _before_ the 43294 thread_info pointer is removed from the gdbpy thread object), 43295 the `thread_info *` thread pointer must not be null. However, this 43296 comes at the cost of gdb.InferiorThread believing it is "valid" - which means, 43297 that if a user holds takes a global reference to that 43298 exiting event thread object, they can some time later do `t.switch()` at which 43299 point GDB will 'explode' so to speak. 43300 43301 v2: 43302 Fixed white space issues and NULL/nullptr stuff, 43303 as requested by Tom Tromey. 43304 43305 v1: 43306 Currently no event is emitted for a thread exit. 43307 43308 This adds this functionality by emitting a new gdb.ThreadExitedEvent. 43309 43310 It currently provides four attributes: 43311 - global_num: The GDB assigned global thread number 43312 - num: the per-inferior thread number 43313 - name: name of the thread or none if not set 43314 - ptid: the PTID of the thread, a 3-attribute tuple, identical to 43315 InferiorThread.ptid attribute 43316 43317 Added info to docs & the NEWS file as well. 43318 43319 Added test to test suite. 43320 43321 Fixed formatting. 43322 43323 Feedback wanted and appreciated. 43324 433252023-06-19 Simon Farre <simon.farre.cx@gmail.com> 43326 43327 gdb/dap - Getting thread names 43328 Renamed thread_name according to convention (_ first) 43329 43330 When testing firefox tests, it is apparent that 43331 _get_threads returns threads with name field = None. 43332 43333 I had initially thought that this was due to Firefox setting the names 43334 using /proc/pid/task/tid/comm, by writing directly to the proc fs the 43335 names, but apparently GDB seems to catch this, because I re-wrote 43336 the basic-dap.exp/c to do this specifically and it saw the changes. 43337 43338 So I couldn't determine right now, what operation of name change that 43339 GDB does not pick up, but with this patch, GDB will pick up the thread 43340 names for an applications that set the name of a thread in ways that 43341 aren't obvious. 43342 433432023-06-19 Nick Clifton <nickc@redhat.com> 43344 43345 Fix illegal memory access implementing relocs in a fuzzed x86_64 object file. 43346 PR 30560 43347 * elf64-x86-64.c (elf_x86_64_relocate_section): Add more checks for a valid relocation offset. 43348 433492023-06-19 Tom de Vries <tdevries@suse.de> 43350 43351 [gdb/testsuite] Add shared_gnat_runtime_has_debug_info 43352 Test-case gdb.ada/catch_ex_std.exp passes for me with package 43353 libada7-debuginfo installed, but after removing it I get: 43354 ... 43355 (gdb) catch exception some_kind_of_error^M 43356 Your Ada runtime appears to be missing some debugging information.^M 43357 Cannot insert Ada exception catchpoint in this configuration.^M 43358 (gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error 43359 ... 43360 43361 The test-case contains a require gnat_runtime_has_debug_info to deal with 43362 this, but the problem is that this checks the static gnat runtime, while this 43363 test-case uses the shared one. 43364 43365 Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that 43366 one instead. 43367 43368 Tested on x86_64-linux. 43369 43370 PR testsuite/30094 43371 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094 43372 433732023-06-19 Tom de Vries <tdevries@suse.de> 43374 43375 [gdb/tui] Simplify tui_update_variables 43376 Simplify tui_update_variables by using template function 43377 assign_return_if_changed. 43378 43379 Tested on x86_64-linux. 43380 433812023-06-19 Tom de Vries <tdevries@suse.de> 43382 43383 [gdb] Add template functions assign_return/set_if_changed 43384 Add template functions assign_return_if_changed and assign_set_if_changed in 43385 gdb/utils.h: 43386 ... 43387 template<typename T> void assign_set_if_changed (T &lval, const T &val, bool &changed) 43388 { ... } 43389 template<typename T> bool assign_return_if_changed (T &lval, const T &val) 43390 { ... } 43391 ... 43392 43393 This allows us to rewrite code like this: 43394 ... 43395 if (tui_border_attrs != entry->value) 43396 { 43397 tui_border_attrs = entry->value; 43398 need_redraw = true; 43399 } 43400 ... 43401 into this: 43402 ... 43403 need_redraw |= assign_return_if_changed<int> (tui_border_attrs, entry->value); 43404 ... 43405 or: 43406 ... 43407 assign_set_if_changed<int> (tui_border_attrs, entry->value, need_redraw); 43408 ... 43409 43410 The names are a composition of the functionality. The functions: 43411 - assign VAL to LVAL, and either 43412 - return true if the assignment changed LVAL, or 43413 - set CHANGED to true if the assignment changed LVAL. 43414 43415 Tested on x86_64-linux. 43416 434172023-06-19 Andreas Schwab <schwab@suse.de> 43418 43419 riscv: Use run-time endianess for floating point literals 43420 gas/ 43421 PR binutils/30551 43422 * config/tc-riscv.c (md_atof): Use target_big_endian instead of 43423 TARGET_BYTES_BIG_ENDIAN. 43424 * testsuite/gas/riscv/float-be.d: New file. 43425 * testsuite/gas/riscv/float-le.d: New file. 43426 * testsuite/gas/riscv/float.s: New file. 43427 434282023-06-19 GDB Administrator <gdbadmin@sourceware.org> 43429 43430 Automatic date update in version.in 43431 434322023-06-18 Tom de Vries <tdevries@suse.de> 43433 43434 [gdb/testsuite] Clean standard_output_file dir in gdb_init 43435 In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in 43436 gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some 43437 files at the start of the test-case: 43438 ... 43439 remote_file host delete [standard_output_file prog.o] 43440 remote_file host delete [standard_output_file prog.ali] 43441 ... 43442 43443 Replace this with cleaning up the entire directory instead, for all 43444 test-cases. 43445 43446 Tested on x86_64-linux. 43447 43448 Suggested-By: Tom Tromey <tom@tromey.com> 43449 Reviewed-By: Tom Tromey <tom@tromey.com> 43450 434512023-06-18 GDB Administrator <gdbadmin@sourceware.org> 43452 43453 Automatic date update in version.in 43454 434552023-06-17 Tom de Vries <tdevries@suse.de> 43456 43457 [gdb/testsuite] Remove f-string in gdb.python/py-unwind.py 43458 on openSUSE Leap 42.3, with python 3.4, I run into a 43459 "SyntaxError: invalid syntax" due to usage of an f-string in test-case 43460 gdb.python/py-unwind.py. 43461 43462 Fix this by using string concatenation using '+' instead. 43463 43464 Tested on x86_64-linux. 43465 434662023-06-17 Tom de Vries <tdevries@suse.de> 43467 43468 [gdb/testsuite] Add nopie in a few test-cases 43469 When running test-case gdb.arch/i386-disp-step.exp with target board 43470 unix/-m32/-fPIE/-pie we run into: 43471 ... 43472 gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text' 43473 ld: warning: creating DT_TEXTREL in a PIE 43474 ... 43475 43476 Fix this by adding nopie in the compilation flags. 43477 43478 Likewise in a few other test-cases. 43479 43480 Tested on x86_64-linux. 43481 434822023-06-17 Tom de Vries <tdevries@suse.de> 43483 43484 [gdb/testsuite] Use require in gdb.dwarf2/implptr.exp 43485 In test-case gdb.dwarf2/implptr.exp I noticed: 43486 ... 43487 } elseif {![is_x86_like_target]} { 43488 # This test can only be run on x86 targets. 43489 unsupported "needs x86-like target" 43490 return 0 43491 } 43492 ... 43493 43494 Use instead "require is_x86_like_target". 43495 43496 Tested on x86_64-linux. 43497 434982023-06-17 GDB Administrator <gdbadmin@sourceware.org> 43499 43500 Automatic date update in version.in 43501 435022023-06-16 Tom de Vries <tdevries@suse.de> 43503 43504 [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 43505 Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works 43506 fine, but if we run it again with target board unix-m32, we run into: 43507 ... 43508 gnatlink prog.ali -m32 -g -o prog^M 43509 ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \ 43510 i386 output^M 43511 ... 43512 43513 This is due to compiling with no-force. 43514 43515 The test-case: 43516 - first compiles pck.adb into pck.o (without debug info), and 43517 - then compiles prog.adb and pck.o into prog (with debug info). 43518 43519 Using no-force in the second compilation make sure that pck.adb is not 43520 compiled again, with debug info. 43521 43522 But it also means it will pick up intermediate files related to prog.adb from 43523 a previous compilation. 43524 43525 Fix this by removing prog.o and prog.ali before compilation. 43526 43527 Tested on x86_64-linux. 43528 435292023-06-16 Tom de Vries <tdevries@suse.de> 43530 43531 [gdb/testsuite] Use %progbits in gdb.arch/thumb*.S 43532 In commit 0f2cd53cf4f ("[gdb/testsuite] Handle missing .note.GNU-stack") I 43533 updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits, 43534 but failed to do so for gdb.arch/thumb*.S. Fix this oversight. 43535 43536 Tested on arm-linux-gnueabihf. 43537 435382023-06-16 mengqinggang <mengqinggang@loongson.cn> 43539 43540 LoongArch: Fix ld "undefined reference" error with --enable-shared 43541 Because _bfd_read_unsigned_leb128 is hidden visibility, so it can't 43542 be referenced out of shared object. 43543 43544 The new function loongarch_get_uleb128_length just used to call 43545 _bfd_read_unsigned_leb128. 43546 43547 bfd/ChangeLog: 43548 43549 * elfxx-loongarch.c (loongarch_get_uleb128_length): New function. 43550 * elfxx-loongarch.h (loongarch_get_uleb128_length): New function. 43551 43552 gas/ChangeLog: 43553 43554 * config/tc-loongarch.c (md_apply_fix): Use 43555 loongarch_get_uleb128_length. 43556 435572023-06-16 Andrew Burgess <aburgess@redhat.com> 43558 43559 gdb: update IRC reference from Freenode to Libera.Chat 43560 It's been some time since the switch from Freenode to Libera.Chat, 43561 however, there's still a reference to Freenode in the 'gdb --help' 43562 output. Lets update that. 43563 435642023-06-16 Jan Beulich <jbeulich@suse.com> 43565 43566 x86: shrink Masking insn attribute to a single bit (boolean) 43567 The logic can actually be expressed with less code that way, utilizing 43568 that there are common patterns of when which form of masking is 43569 permitted. This then also eliminates the large set of open-codings of 43570 BOTH_MASKING in the opcode table. 43571 435722023-06-16 Alan Modra <amodra@gmail.com> 43573 43574 Correct ld-elf/eh5 test for hppa64 43575 Commit 3c0afdb78988 regressed this test for hppa64, because the test 43576 had been enabled for hppa64 in the time between the mips changes and 43577 their reversion. This patch isn't just a simple reapply, I recreated 43578 the testsuite change by hand for hppa64: Two lines in eh5.d might need 43579 further changes for mips. 43580 435812023-06-16 GDB Administrator <gdbadmin@sourceware.org> 43582 43583 Automatic date update in version.in 43584 435852023-06-15 Maciej W. Rozycki <macro@orcam.me.uk> 43586 43587 binutils/NEWS: Mention Sony Allegrex MIPS CPU support 43588 Mention the addition of Sony Allegrex processor support to the MIPS port. 43589 43590 binutils/ 43591 * NEWS: Mention Sony Allegrex MIPS CPU support. 43592 435932023-06-15 Maciej W. Rozycki <macro@orcam.me.uk> 43594 43595 MIPS/GAS/testsuite: Fix `-modd-spreg'/`-mno-odd-spreg' test invocations 43596 Reformat `-modd-spreg'/`-mno-odd-spreg' test invocations in mips.exp to 43597 fit in 79 columns 43598 43599 gas/ 43600 * testsuite/gas/mips/mips.exp: Reformat 43601 `-modd-spreg'/`-mno-odd-spreg' test invocations. 43602 436032023-06-15 David Guillen Fandos <david@davidgf.net> 43604 43605 Add additional missing Allegrex CPU instructions 43606 Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with 43607 some encoding differences) such as bit manipulation (ins/ext) and MLA 43608 (madd/msub). It also features some new instructions like wsbw and 43609 min/max or device-specific ones such as mfic. 43610 43611 Add rotation instructions to MIPS Allegrex CPU 43612 The Allegrex CPU supports bit rotation instructions as described in the 43613 MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU). 43614 43615 Add MIPS Allegrex CPU as a MIPS2-based CPU 43616 The Allegrex CPU was created by Sony Interactive Entertainment to power 43617 their portable console, the PlayStation Portable. 43618 The pspdev organization maintains all sorts of tools to create software 43619 for said device including documentation. 43620 436212023-06-15 Maciej W. Rozycki <macro@orcam.me.uk> 43622 43623 GAS/doc: Correct Tag_GNU_MIPS_ABI_MSA attribute description 43624 Rewrite the paragraph to match the style of Tag_GNU_MIPS_ABI_FP text 43625 immediately above, correcting grammar and formatting at the same time. 43626 43627 gas/ 43628 * doc/as.texi (MIPS Attributes): Correct Tag_GNU_MIPS_ABI_MSA 43629 attribute description. 43630 436312023-06-15 Maciej W. Rozycki <macro@orcam.me.uk> 43632 43633 Revert "MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit" 43634 This reverts commit 094025a30bb2da19df3990e0c0ff8167af823aa1. It was 43635 applied unapproved. 43636 43637 Revert "MIPS: default r6 if vendor is img" 43638 This reverts commit be0d391f22fe6009c3be907753975a984cbbcc23. It was 43639 applied unapproved. 43640 43641 Revert "MIPS: fix r6 testsuites" 43642 This reverts commit ffc528aed56b9e2c171137da28690a9bb6861b0b. It was 43643 applied unapproved. 43644 43645 Revert "MIPS: fix -gnuabi64 testsuite" 43646 This reverts commit cb81e84c72933a7fad10b75b7e270d92d8d65251. It was 43647 applied unapproved. 43648 43649 Revert "MIPS: fix some ld testcases with compiler" 43650 This reverts commit a0631c1501c113c04891c9a24a9ff5276257f28d. It was 43651 applied unapproved. 43652 43653 Revert "MIPS: add MT ASE support for micromips32" 43654 This reverts commit acce83dacff0ce43677410c67aaae32817afe991. It was 43655 applied unapproved. 43656 43657 Revert "MIPS: sync oprand char usage between mips and micromips" 43658 This reverts commit 5b207b919483f67311a73dfc1de8897ecfd8e776. It was 43659 applied unapproved. 43660 436612023-06-15 Alan Modra <amodra@gmail.com> 43662 43663 Re: Add some expected failures for bfin linker tests 43664 After commit 7ade0f1582c4 I was seeing bfin-elf +XPASS: weak symbols, 43665 and on looking into the bfin targets a little, discovered we have two 43666 bfin-linux targets. One, bfin-uclinux, is like bfin-elf in that 43667 ld -m elf32bfin is the default, and the other, bfin-linux-uclibc where 43668 ld -m elf32bfinfd is the default. So putting bfin-*-*linux* in test 43669 xfails or elsewhere is wrong. We want bfin-*-linux* instead to just 43670 select the fdpic bfin target. 43671 43672 This patch corrects wrong bfin target triples in the ld testsuite, 43673 not just the recent change but others I'd added to xfails too. 43674 It also fixes the bfin-linux-uclibc ld-elf/64ksec fail 43675 436762023-06-15 Alan Modra <amodra@gmail.com> 43677 43678 vms write_archive memory leaks 43679 This fixes two memory leaks in the vms archive handling. 43680 43681 * vms-lib.c (_bfd_vms_lib_build_map): Free input symbols. 43682 (_bfd_vms_lib_write_archive_contents): Free archive map symbols. 43683 436842023-06-15 GDB Administrator <gdbadmin@sourceware.org> 43685 43686 Automatic date update in version.in 43687 436882023-06-14 Tom de Vries <tdevries@suse.de> 43689 43690 [gdb/testsuite] Fix gdb.base/step-over-exit.exp with glibc debuginfo 43691 In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and 43692 continue, expecting to hit the breakpoint. 43693 43694 Without glibc debug info installed, we have with target board unix/-m64: 43695 ... 43696 Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \ 43697 _exit () from /lib64/libc.so.6^M 43698 (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit 43699 ... 43700 and with target board unix/-m32: 43701 ... 43702 Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \ 43703 /lib/libc.so.6^M 43704 (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit 43705 ... 43706 43707 However after installing debug info (packages glibc-debuginfo and 43708 glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit): 43709 ... 43710 Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \ 43711 __GI__exit (status=<optimized out>) at \ 43712 ../sysdeps/unix/sysv/linux/_exit.c:27^M 43713 27 {^M 43714 (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit 43715 ... 43716 and -m32 (note: _Exit instead of _exit): 43717 ... 43718 Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \ 43719 ../sysdeps/unix/sysv/linux/i386/_exit.S:24^M 43720 24 ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M 43721 (gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit 43722 ... 43723 43724 The gdb_test allows for both _exit and __GI__exit, but not _Exit: 43725 ... 43726 gdb_test "continue" \ 43727 "Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \ 43728 "continue to exit" 43729 ... 43730 43731 Fix this by allowing _Exit as well. 43732 43733 Tested on x86_64-linux. 43734 437352023-06-14 Nick Clifton <nickc@redhat.com> 43736 43737 Add some expected failures for bfin linker tests 43738 43739 Add --remap-inputs option to the BFD linker. 43740 PR 30374 43741 * ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions. 43742 * ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps. 43743 * ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define. 43744 * lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options. 43745 * NEWS: Mention the new feature. 43746 * ld.texi: Document the new options. 43747 * testsuite/ld-misc/input-remap.exp: New test driver. 43748 * testsuite/ld-misc/remaps.r: New file: Expected linker output. 43749 * testsuite/ld-misc/remaps.txt: New file. Input remaps file. 43750 437512023-06-14 Alan Modra <amodra@gmail.com> 43752 43753 asprintf memory leaks 43754 A number of backends want to return bfd_reloc_dangerous messaqes from 43755 relocation special_function, and construct the message using asprintf. 43756 Such messages are not freed anywhere, leading to small memory leaks 43757 inside libbfd. To limit the leaks, I'd implemented a static buffer in 43758 the ppc backends that was freed before use in asprintf output. This 43759 patch extends that scheme to other backends using a shared static 43760 buffer and goes further in freeing the buffer on any bfd_close. 43761 43762 The patch also fixes a few other cases where asprintf output was not 43763 freed after use. 43764 43765 bfd/ 43766 * bfd.c (_input_error_msg): Make global and rename to.. 43767 (_bfd_error_buf): ..this. 43768 (bfd_asprintf): New function. 43769 (bfd_errmsg): Use bfd_asprintf. 43770 * opncls.c (bfd_close_all_done): Free _buf_error_buf. 43771 * elf32-arm.c (find_thumb_glue, find_arm_glue): Use bfd_asprintf. 43772 * elf32-nios2.c (nios2_elf32_relocate_section): Likewise. 43773 * elf32-ppc.c (ppc_elf_unhandled_reloc): Likewise. 43774 * elf64-ppc.c (ppc64_elf_unhandled_reloc): Likewise. 43775 * elfnn-riscv.c (riscv_resolve_pcrel_lo_relocs): Likewise. 43776 (riscv_elf_relocate_section): Likewise. 43777 * libbfd.h: Regenerate. 43778 gas/ 43779 * read.c (read_end): Free current_name and current_label. 43780 (do_s_func): Likewise on error path. strdup label. 43781 ld/ 43782 * pe-dll.c (make_head, make_tail, make_one), 43783 (make_singleton_name_thunk, make_import_fixup_entry), 43784 (make_runtime_pseudo_reloc), 43785 (pe_create_runtime_relocator_reference: Free oname after use. 43786 437872023-06-14 Alan Modra <amodra@gmail.com> 43788 43789 Re: bfd/elf.c strtab memory leak 43790 There are other places that leak the strtab. 43791 43792 * elf.c (_bfd_elf_compute_section_file_positions): Free strtab 43793 on error paths. 43794 437952023-06-14 GDB Administrator <gdbadmin@sourceware.org> 43796 43797 Automatic date update in version.in 43798 437992023-06-13 Tom de Vries <tdevries@suse.de> 43800 43801 [gdb/testsuite] Fix gdb.tui/long-prompt.exp with read1 43802 When running test-case gdb.tui/long-prompt.exp with check-read1, we get: 43803 ... 43804 (gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \ 43805 end of screen: at last line 43806 ... 43807 43808 The problem is in these commands: 43809 ... 43810 Term::command "echo \\n" 43811 Term::command "echo \\n" 43812 Term::command "echo \\n" 43813 Term::command "echo \\n" 43814 ... 43815 43816 The last one makes the terminal scroll, and the scrolling makes the expected 43817 output match on a different line. 43818 43819 Fix this by replacing the sequence with a single command: 43820 ... 43821 Term::command "echo \\n\\n\\n\\n\\n\\n" 43822 ... 43823 which avoids scrolling. 43824 43825 Tested on x86_64-linux. 43826 438272023-06-13 Tom de Vries <tdevries@suse.de> 43828 43829 [gdb/testsuite] Fix and add prompt anchoring in tuiterm 43830 There is a test-case that contains a unit test for tuiterm: 43831 gdb.tui/tuiterm.exp. 43832 43833 However, this only excercises the tuiterm itself, and not the functions that 43834 interact with it, like Term::command. 43835 43836 Add a new test-case gdb.tui/tuiterm-2.exp that: 43837 - overrides proc accept_gdb_output (to be able simulate incorrect responses 43838 while avoiding the timeout), 43839 - overrides proc send_gdb (to be able to call Term::command without a gdb 43840 instance, such that all tuiterm input is generated by the test-case). 43841 - issues Term::command calls, and 43842 - checks whether they behave correctly. 43843 43844 This exposes a problem in Term::command. The "prompt before command" regexp 43845 starts with a bit that is supposed to anchor the prompt to the border: 43846 ... 43847 set str "(^|\|)$gdb_prompt $str" 43848 ... 43849 but that doesn't work due to insufficient escaping. Fix this by adding the 43850 missing escape: 43851 ... 43852 set str "(^|\\|)$gdb_prompt $str" 43853 ... 43854 43855 Futhermore, the "prompt after command" regexp in Term::wait_for has no 43856 anchoring at all: 43857 ... 43858 set prompt_wait_for "$gdb_prompt \$" 43859 ... 43860 so add that as well. 43861 43862 Tested on x86_64-linux. 43863 438642023-06-13 Tom de Vries <tdevries@suse.de> 43865 43866 [gdb/testsuite] Allow procs with default value args in with_override 43867 Currently proc with_override does not work with procs with default value args. 43868 43869 Fix this, and add a test-case excercising this scenario. 43870 43871 Tested on x86_64-linux. 43872 438732023-06-13 Tom de Vries <tdevries@suse.de> 43874 43875 [gdb/testsuite] Fix gdb.dap/type_check.exp with older python 43876 On openSUSE Leap 15.4 with system python 3.6, I run into: 43877 ... 43878 (gdb) python check_everything()^M 43879 (gdb) FAIL: gdb.dap/type_check.exp: type checker 43880 ... 43881 43882 In check_everything, the hasattr test fails silently: 43883 ... 43884 def check_everything(): 43885 # Older versions of Python can't really implement this. 43886 if hasattr(typing, "get_origin"): 43887 ... 43888 and that makes the gdb_test in the test-case fail. 43889 43890 Fix this by emitting UNSUPPORTED instead in check_everything, and detecting 43891 this in the test-case. 43892 43893 Tested on x86_64-linux. 43894 438952023-06-13 Lancelot SIX <lancelot.six@amd.com> 43896 43897 gdb/testsuite: use proper int size for gdb.dwarf2/symbol_needs_eval*.exp 43898 We recently realized that symbol_needs_eval_fail.exp and 43899 symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on 43900 x86_64) by reading 8 bytes (the size of a pointer). 43901 43902 Here how it goes: 43903 43904 In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is 43905 defined: 43906 43907 int exec_mask = 1; 43908 43909 and later both tests build some DWARF using the assembler doing: 43910 43911 set exec_mask_var [gdb_target_symbol exec_mask] 43912 ... 43913 DW_TAG_variable { 43914 {DW_AT_name a} 43915 {DW_AT_type :$int_type_label} 43916 {DW_AT_location { 43917 DW_OP_addr $exec_mask_var 43918 DW_OP_deref 43919 ... 43920 } 43921 } 43922 43923 The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations) 43924 says that "The size of the data retrieved from the dereferenced address 43925 is the size of an address on the target machine." 43926 43927 On x86_64, the size of an int is 4 while the size of an address is 8. 43928 The result is that when evaluating this expression, the debugger reads 43929 outside of the `a` variable. 43930 43931 Fix this by using `DW_OP_deref_size $int_size` instead. To achieve 43932 this, this patch adds the necessary steps so we can figure out what 43933 `sizeof(int)` evaluates to for the current target. 43934 43935 While at it, also change the definition of the int type in the assembled 43936 DWARF information so we use the actual target's size for an int instead 43937 of the literal 4. 43938 43939 Tested on x86_64 Linux. 43940 43941 Approved-By: Tom Tromey <tom@tromey.com> 43942 439432023-06-13 GDB Administrator <gdbadmin@sourceware.org> 43944 43945 Automatic date update in version.in 43946 439472023-06-13 Kevin Buettner <kevinb@redhat.com> 43948 43949 Simplify case DW_OP_GNU_uninit in dwarf_expr_context::execute_stack_op 43950 Tom Tromey pointed out that the test and call to error() for the 43951 DW_OP_GNU_uninit case in dwarf_expr_context::execute_stack_op (in 43952 gdb/dwarf2/expr.c)... 43953 43954 if (op_ptr != op_end && *op_ptr != DW_OP_piece 43955 && *op_ptr != DW_OP_bit_piece) 43956 error (_("DWARF-2 expression error: DW_OP_GNU_uninit must always " 43957 "be the very last op in a DWARF expression or " 43958 "DW_OP_piece/DW_OP_bit_piece piece.")); 43959 43960 ...could be replaced by a call to dwarf_expr_require_composition which 43961 performs a similar check and outputs a suitable error message. 43962 439632023-06-12 Simon Farre <simon.farre.cx@gmail.com> 43964 43965 Added self to W.A.A. maintainers 43966 439672023-06-12 Richard Bunt <richard.bunt@linaro.org> 43968 43969 gdb/testsuite: Testing with the armflang compiler 43970 Currently the Fortran test suite does not run with armflang because the 43971 compiler detection fails. This in turn means fortran_runto_main does not 43972 know which main method to use to start a test case. 43973 43974 Fortran compiler detection was added in 44d469c5f85; however, the commit 43975 message notes that it was not tested with armflang. 43976 43977 This commit tests and fixes up a minor issue to get the detection 43978 working. 43979 43980 The goal here is to get the tests running and preventing further 43981 regressions during future work. This change does not do anything to fix 43982 existing failures. 43983 43984 >From what I can understand, the auto detection leverages the 43985 preprocessor to extract the Fortran compiler identity from the defines. 43986 This preprocessor output is then evaluated by the test suite to import 43987 these defines. 43988 43989 In the case of armflang, this evaluation step is disrupted by the 43990 presence of the following warning: 43991 43992 $ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp 43993 $ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] 43994 43995 The evaluation logic is already set up to filter this warning, but the 43996 prefix differs. 43997 43998 This commit fixes the issue by updating the filter to exclude the 43999 armflang flavour of warning. 44000 44001 gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No 44002 regressions detected. 44003 44004 The gdb.fortran test results with ACfL 23.04.1 are as follows. 44005 44006 Before: 44007 44008 # of expected passes 560 44009 # of unexpected failures 113 44010 # of unresolved testcases 2 44011 # of untested testcases 5 44012 # of duplicate test names 2 44013 44014 After: 44015 44016 # of expected passes 5388 44017 # of unexpected failures 628 44018 # of known failures 10 44019 # of untested testcases 8 44020 # of unsupported tests 5 44021 # of duplicate test names 5 44022 44023 As can be seen from the above, there are now considerably more passing 44024 assertions. 44025 44026 Reviewed-By: Luis Machado <luis.machado@arm.com> 44027 Approved-By: Tom Tromey <tom@tromey.com> 44028 440292023-06-12 Tom Tromey <tromey@adacore.com> 44030 44031 Remove f-strings from DAP 44032 Kévin pointed out that gdb claims a minimum Python version of 3.2, but 44033 the DAP code uses f-strings, which were added in 3.6. 44034 44035 This patch removes the uses of f-strings from the DAP code. I can't 44036 test an older version of Python, but I did confirm that this still 44037 works with the version I have. 44038 440392023-06-12 Tom Tromey <tromey@adacore.com> 44040 44041 Implement DAP conditional breakpoints 44042 I realized that I had only implemented DAP breakpoint conditions for 44043 exception breakpoints, and not other kinds of breakpoints. This patch 44044 corrects the oversight. 44045 440462023-06-12 Tom Tromey <tromey@adacore.com> 44047 44048 Do not report totalFrames from DAP stackTrace request 44049 Currently, gdb will unwind the entire stack in response to the 44050 stackTrace request. I had erroneously thought that the totalFrames 44051 attribute was required in the response. However, the spec says: 44052 44053 If omitted or if `totalFrames` is larger than the available 44054 frames, a client is expected to request frames until a request 44055 returns less frames than requested (which indicates the end of the 44056 stack). 44057 44058 This patch removes this from the response in order to improve 44059 performance when the stack trace is very long. 44060 440612023-06-12 Tom Tromey <tromey@adacore.com> 44062 44063 Implement DAP breakpointLocations request 44064 This implements the DAP breakpointLocations request. 44065 440662023-06-12 Tom Tromey <tromey@adacore.com> 44067 44068 Add "stop at main" extension to DAP launch request 44069 Co-workers who work on a program that uses DAP asked for the ability 44070 to have gdb stop at the main subprogram when launching. This patch 44071 implements this extension. 44072 44073 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 44074 440752023-06-12 Tom Tromey <tromey@adacore.com> 44076 44077 Add "target" parameter to DAP attach request 44078 This adds a new "target" to the DAP attach request. This is passed to 44079 "target remote". I thought "attach" made the most sense for this, 44080 because in some sense gdb is attaching to a running process. It's 44081 worth noting that all DAP "attach" parameters are defined by the 44082 implementation. 44083 44084 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 44085 440862023-06-12 Tom Tromey <tromey@adacore.com> 44087 44088 Handle DAP supportsVariableType capability 44089 A DAP client can report the supportsVariableType capability in the 44090 initialize request. In this case, gdb can include the type of a 44091 variable or expression in various results. 44092 44093 Implement DAP setExpression request 44094 This implements the DAP setExpression request. 44095 440962023-06-12 Tom Tromey <tromey@adacore.com> 44097 44098 Add gdb.Value.assign method 44099 This adds an 'assign' method to gdb.Value. This allows for assignment 44100 without requiring the use of parse_and_eval. 44101 44102 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 44103 441042023-06-12 Tom Tromey <tromey@adacore.com> 44105 44106 Add type-checking to DAP requests 44107 It occurred to me recently that gdb's DAP implementation should 44108 probably check the types of objects coming from the client. This 44109 patch implements this idea by reusing Python's existing type 44110 annotations, and supplying a decorator that verifies these at runtime. 44111 44112 Python doesn't make it very easy to do runtime type-checking, so the 44113 core of the checker is written by hand. I haven't tried to make a 44114 fully generic runtime type checker. Instead, this only checks the 44115 subset that is needed by DAP. For example, only keyword-only 44116 functions are handled. 44117 44118 Furthermore, in a few spots, it wasn't convenient to spell out the 44119 type that is accepted. I've added a couple of comments to this effect 44120 in breakpoint.py. 44121 44122 I've tried to make this code compatible with older versions of Python, 44123 but I've only been able to try it with 3.9 and 3.10. 44124 441252023-06-12 Tom Tromey <tromey@adacore.com> 44126 44127 Use tuples for default arguments in DAP 44128 My co-worker Kévin taught me that using a mutable object as a default 44129 argument in Python is somewhat dangerous, because the object is 44130 created a single time (when the function is defined), and so if it is 44131 mutated in the body of the function, the changes will stick around. 44132 44133 This patch changes the cases like this in DAP to use () rather than [] 44134 as the default. This patch is merely preventative, as no bugs like 44135 this are in the code. 44136 441372023-06-12 Tom Tromey <tromey@adacore.com> 44138 44139 Fix a latent bug in DAP request decorator 44140 The 'request' decorator is intended to also ensure that the request 44141 function runs in the DAP thread. However, the unwrapped function is 44142 installed in the global request map, so the wrapped version is never 44143 called. This patch fixes the bug. 44144 44145 Add test for DAP pause request 44146 I neglected to write a test for the DAP "pause" request. This patch 44147 adds one. 44148 44149 Rename one DAP function 44150 When I first started implementing DAP, I had some vague plan of having 44151 the implementation functions use the same name as the request. I 44152 abandoned this idea, but one vestige remained. This patch renames the 44153 one remaining function to be gdb-ish. 44154 44155 Add singleThread support to some DAP requests 44156 A few DAP requests support a "singleThread" parameter, which is 44157 somewhat similar to scheduler-locking. This patch implements support 44158 for this. 44159 44160 Implement DAP stepOut request 44161 This implements the DAP "stepOut" request. 44162 441632023-06-12 Tom Tromey <tromey@adacore.com> 44164 44165 Implement DAP attach request 44166 This implements the DAP "attach" request. 44167 44168 Note that the copyright dates on the new test source file are not 44169 incorrect -- this was copied verbatim from another directory. 44170 44171 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 44172 441732023-06-12 Tom Tromey <tromey@adacore.com> 44174 44175 Implement DAP setExceptionBreakpoints request 44176 This implements the DAP setExceptionBreakpoints request for Ada. This 44177 is a somewhat minimal implementation, in that "exceptionOptions" are 44178 not implemented (or advertised) -- I wasn't completely sure how this 44179 feature is supposed to work. 44180 44181 I haven't added C++ exception handling here, but it's easy to do if 44182 needed. 44183 44184 This patch relies on the new MI command execution support to do its 44185 work. 44186 441872023-06-12 Tom Tromey <tromey@adacore.com> 44188 44189 Don't require inferior execution for Ada catchpoints 44190 Currently, Ada catchpoints require that the inferior be running. 44191 However, there's no deep reason for this -- for example, C++ exception 44192 catchpoints do not have this requirement. Instead, those work like 44193 ordinary breakpoints: they are pending until the needed runtime 44194 locations are seen. 44195 44196 This patch changes Ada catchpoints to work the same way. 44197 441982023-06-12 Tom Tromey <tromey@adacore.com> 44199 44200 Mark members of ada_catchpoint "private" 44201 This changes the members of ada_catchpoint to be private. 44202 44203 Turn should_stop_exception into a method of ada_catchpoint 44204 This turns the should_stop_exception function in ada-lang.c into a 44205 method of ada_catchpoint. 44206 44207 Combine create_excep_cond_exprs and ada_catchpoint::re_set 44208 This patch merges create_excep_cond_exprs into ada_catchpoint::re_set. 44209 This is less verbose and is also a step toward making ada_catchpoint 44210 work more like the other code_breakpoint-based exception catchpoints. 44211 44212 Transfer ownership of exception string to ada_catchpoint 44213 This changes the ada_catchpoint to require an rvalue ref, so that 44214 ownership of the exception string can be transferred to the catchpoint 44215 object. 44216 44217 Pass tempflag to ada_catchpoint constructor 44218 This is a minor cleanup to pass tempflag to the ada_catchpoint 44219 constructor. 44220 44221 Use gnat_runtime_has_debug_info in Ada catchpoint tests 44222 This changes the Ada catchpoint tests to use 44223 gnat_runtime_has_debug_info. This simplifies the code. 44224 44225 Stop gdb in gnat_runtime_has_debug_info 44226 gnat_runtime_has_debug_info starts a new gdb to do its work. However, 44227 it also leaves this gdb running, which can potentially confuse the 44228 calling test -- I encountered this when writing a new DAP test. This 44229 patch changes the proc to shut down gdb. 44230 442312023-06-12 Tom de Vries <tdevries@suse.de> 44232 44233 [gdb/testsuite] Relax breakpoint count check in gdb.python/py-rbreak.exp 44234 With a gdb 13.2 based package on SLE-15 aarch64, I run into: 44235 ... 44236 (gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary 44237 py sl = gdb.rbreak("^[^_]",minsyms=False)^M 44238 Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M 44239 ... 44240 (gdb) py print(len(sl))^M 44241 12^M 44242 (gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11 44243 ... 44244 44245 The FAIL is due to: 44246 - the glibc object crti.o containing debug information for function 44247 call_weak_fn, and 44248 - the test-case not expecting this. 44249 44250 The debug information is there due to compiling glibc using a binutils which 44251 contains commit 591cc9fbbfd ("gas/Dwarf: record functions"). 44252 44253 I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite] 44254 Fix regexp in py-rbreak.exp"). 44255 44256 The fix I applied there was to use a regexp "^[^_]" to filter out 44257 __libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn. 44258 44259 Fix this by: 44260 - reverting the regexp to "", and 44261 - rewriting the check to require at least 11 functions, rather than a precise 44262 match. 44263 44264 Tested on x86_64-linux. 44265 44266 PR testsuite/30538 44267 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30538 44268 442692023-06-12 Tom de Vries <tdevries@suse.de> 44270 44271 [gdb/testsuite] Fix breakpoint regexp in gdb.ada/out_of_line_in_inlined.exp 44272 With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into: 44273 ... 44274 (gdb) run ^M 44275 Starting program: out_of_line_in_inlined/foo_o224_021-all ^M 44276 [Thread debugging using libthread_db enabled]^M 44277 Using host libthread_db library "/lib/libthread_db.so.1".^M 44278 ^M 44279 Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M 44280 26 for C of S loop^M 44281 (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \ 44282 run to foo_o224_021.child1.child2 44283 ... 44284 44285 I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3 44286 instead of optimize=-O2. 44287 44288 Fix this by using $bkptno_num_re. 44289 44290 Tested on x86_64-linux. 44291 44292 PR testsuite/30539 44293 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539 44294 442952023-06-12 Tom de Vries <tdevries@suse.de> 44296 44297 [gdb/tui] Replace macro HELP_ATTRIBUTE_MODE with std::string 44298 Replace macro HELP_ATTRIBUTE_MODE with a std::string. 44299 44300 Tested on x86_64-linux. 44301 44302 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 44303 Reviewed-By: Tom Tromey <tom@tromey.com> 44304 443052023-06-12 mengqinggang <mengqinggang@loongson.cn> 44306 44307 LoongArch: gas: Relocations simplification when -mno-relax 44308 Gas does not emit ADD/SUB relocation pairs for label differences 44309 when -mno-relax. 44310 443112023-06-12 GDB Administrator <gdbadmin@sourceware.org> 44312 44313 Automatic date update in version.in 44314 443152023-06-11 Kevin Buettner <kevinb@redhat.com> 44316 44317 Permit DW_OP_GNU_uninit to be used with DW_OP_piece 44318 This commit implements a fix for a bug reported against GDB on 44319 Fedora bugzilla... 44320 44321 https://bugzilla.redhat.com/show_bug.cgi?id=2166796 44322 44323 The test case in that bug report involved running gdb against the 'jq' 44324 program (which is a command-line JSON processor) on Fedora 37. Since 44325 the debug info is compiler (and compile-time option) dependent, it 44326 won't necessarily show up in other distributions or even past or 44327 future versions of Fedora. (E.g. when trying the example shown below 44328 on Fedora 38, GDB says that the value of 'value' has been optimized 44329 out. I.e. it does not demonstrate the same DWARF error that can be 44330 see when using Fedora 37.) 44331 44332 That said, on Fedora 37, the bug could be reproduced as follows: 44333 44334 [kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null' 44335 Reading symbols from jq... 44336 44337 This GDB supports auto-downloading debuginfo from the following URLs: 44338 <https://debuginfod.fedoraproject.org/> 44339 Enable debuginfod for this session? (y or [n]) y 44340 Debuginfod has been enabled. 44341 To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. 44342 Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo... 44343 No source file named src/util.c. 44344 Make breakpoint pending on future shared library load? (y or [n]) y 44345 Breakpoint 1 (src/util.c:415) pending. 44346 Starting program: /usr/bin/jq </dev/null 44347 [Thread debugging using libthread_db enabled] 44348 Using host libthread_db library "/lib64/libthread_db.so.1". 44349 44350 Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416 44351 416 if (state->parser == NULL) { 44352 (gdb) p value 44353 DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op. 44354 44355 This is undesirable - rather than output an error about the DWARF 44356 info, we'd prefer to see a value, even if it is uninitialized. 44357 44358 Examination of the debuginfo showed the following: 44359 44360 <1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram) 44361 <468f2> DW_AT_external : 1 44362 <468f2> DW_AT_name : (indirect string, offset: 0x4781): jq_util_input_next_input 44363 <468f6> DW_AT_decl_file : 10 44364 <468f6> DW_AT_decl_line : 411 44365 <468f8> DW_AT_decl_column : 4 44366 <468f9> DW_AT_prototyped : 1 44367 <468f9> DW_AT_type : <0x3f2> 44368 <468fd> DW_AT_sibling : <0x4692e> 44369 ... 44370 <2><46921>: Abbrev Number: 102 (DW_TAG_variable) 44371 <46922> DW_AT_name : (indirect string, offset: 0x8cb): value 44372 <46926> DW_AT_decl_file : 10 44373 <46926> DW_AT_decl_line : 414 44374 <46928> DW_AT_decl_column : 6 44375 <46929> DW_AT_type : <0x3f2> 44376 44377 Note that there's no DW_AT_location, so I looked for an abstract origin entry: 44378 44379 <2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable) 44380 <2dfa1> DW_AT_abstract_origin: <0x46921> 44381 <2dfa5> DW_AT_location : 0x27cf1 (location list) 44382 <2dfa9> DW_AT_GNU_locviews: 0x27ce1 44383 44384 (Note that the DW_AT_abstract_origin attribute's value is 0x46921 which 44385 is the DIE for the local variable "value".) 44386 44387 Looking at the location list, I see: 44388 44389 00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for: 44390 000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8) 44391 44392 While DW_OP_GNU_uninit is not the very last op, it is the last op 44393 prior to DW_OP_piece. The fix involved changing the DW_OP_GNU_uninit 44394 case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so 44395 that DW_OP_GNU_uninit may appear just before DW_OP_piece. 44396 44397 With the fix in place, attempting to print 'value' now looks like 44398 this: 44399 44400 (gdb) p value 44401 $1 = [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0, 44402 size = 0, u = {ptr = 0x0, number = 0}} 44403 44404 Note that "[uninitialized]" is part of the output. (But also note 44405 that there's an extra space character.) 44406 44407 I've made a new test case, 44408 gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an 44409 existing one, gdb.dwarf2/opt-out-not-implptr.exp. Since it uses the 44410 DWARF assembler, the test case does not depend on a specific compiler 44411 version or compiler options. 44412 44413 Tested on Fedora 37 and Fedora 38. 44414 444152023-06-11 GDB Administrator <gdbadmin@sourceware.org> 44416 44417 Automatic date update in version.in 44418 444192023-06-10 GDB Administrator <gdbadmin@sourceware.org> 44420 44421 Automatic date update in version.in 44422 444232023-06-09 Indu Bhagat <indu.bhagat@oracle.com> 44424 44425 libsframe: testsuite: add sframe_find_fre tests for pltN entries 44426 Add a new test plt-findfre-1 to ensure lookup of SFrame stack trace 44427 information for pltN entries is correct. 44428 44429 In this test, a dummy SFrame FDE of type SFRAME_FDE_TYPE_PCMASK is 44430 created. The size of the 'function code block' covered by the SFrame 44431 FDE is equivalent to 5 pltN entries of 16 bytes each. 44432 44433 The test first looks up SFrame FREs for some addresses in the first pltN 44434 entry, followed by lookups for some addresses in the fourth pltN entry. 44435 44436 libsframe/ 44437 * Makefile.in: Regenerated. 44438 * testsuite/libsframe.find/find.exp: Add new test. 44439 * testsuite/libsframe.find/local.mk: Likewise. 44440 * testsuite/libsframe.find/plt-findfre-1.c: New test. 44441 444422023-06-09 Indu Bhagat <indu.bhagat@oracle.com> 44443 44444 libsframe: fix sframe_find_fre for pltN entries 44445 To find SFrame stack trace information from an FDE of type 44446 SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation 44447 like, 44448 (start_ip_offset & 0xff) >= (pc & 0xff), etc. 44449 44450 This is buggy and needs correction. The mask 0xff should be 0xf (to 44451 work for a pltN entry of size say, 16 bytes). 44452 44453 At this time, the size of the pltN entry is implicitly assumed to be 16 44454 bytes by libsframe. In next version of the SFrame format, we can encode 44455 this information explicitly in the SFrame FDE. 44456 44457 For now, we should fix the code to at least behave correctly for the 44458 generated code and the generated SFrame stack trace information for the 44459 pltN entries on x86_64. 44460 44461 libsframe/ 44462 * sframe.c (sframe_find_fre): Correct the bitmask used for 44463 SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK. 44464 444652023-06-09 Luis Machado <luis.machado@arm.com> 44466 44467 [AArch64,arm] Fix some formatting issues in the aarch64/arm codebase 44468 As noted by Tom Tromey, there are some formatting issues with the ternary 44469 operator in the aarch64/arm codebase. This patch fixes those. 44470 44471 Reviewed-By: Tom Tromey <tom@tromey.com> 44472 444732023-06-09 Tom de Vries <tdevries@suse.de> 44474 44475 [gdb/tui] Simplify tui_puts_internal 44476 Simplify tui_puts_internal by using continue, as per this [1] coding standard 44477 rule, making the function more readable and easier to understand. 44478 44479 No functional changes. 44480 44481 Tested on x86_64-linux. 44482 44483 [1] https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code 44484 44485 Reviewed-By: Tom Tromey <tom@tromey.com> 44486 444872023-06-09 Tom de Vries <tdevries@suse.de> 44488 44489 [gdb/tui] Delete line buffer when switching to singlekey 44490 Say we're in TUI mode, and type "sun": 44491 ... 44492 (gdb) sun 44493 ... 44494 44495 After switching to SingleKey mode using C-x s, we have just: 44496 ... 44497 sun 44498 ... 44499 44500 After typing "d", we get: 44501 ... 44502 sun 44503 Undefined command: "sundown". Try "help". 44504 ... 44505 44506 The SingleKey "d" is supposed run the "down" command. 44507 44508 Fix this by clearing the readline line buffer when switching to SingleKey 44509 mode. 44510 44511 Tested on x86_64-linux. 44512 44513 PR tui/30522 44514 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522 44515 44516 Reviewed-By: Tom Tromey <tom@tromey.com> 44517 445182023-06-09 Tom de Vries <tdevries@suse.de> 44519 44520 [gdb/testsuite] Add test-case gdb.tui/single-key.exp 44521 I noticed that there's no test-case excercising SingleKey mode, so add a test-case. 44522 44523 Tested on x86_64-linux. 44524 44525 Reviewed-By: Tom Tromey <tom@tromey.com> 44526 445272023-06-09 Andrew Burgess <aburgess@redhat.com> 44528 44529 gdb/debuginfod: cleanup debuginfod earlier 44530 A GDB crash was discovered on Fedora GDB that was tracked back to an 44531 issue with the way that debuginfod is cleaned up. 44532 44533 The bug was reported on Fedora 37, 38, and 39. Here are the steps to 44534 reproduce: 44535 44536 1. The file /etc/ssl/openssl.cnf contains the following lines: 44537 44538 [provider_sect] 44539 default = default_sect 44540 ##legacy = legacy_sect 44541 ## 44542 [default_sect] 44543 activate = 1 44544 44545 ##[legacy_sect] 44546 ##activate = 1 44547 44548 The bug will occur when the '##' characters are removed so that the 44549 lines in question look like this: 44550 44551 [provider_sect] 44552 default = default_sect 44553 legacy = legacy_sect 44554 44555 [default_sect] 44556 activate = 1 44557 44558 [legacy_sect] 44559 activate = 1 44560 44561 2. Clean up any existing debuginfod cache data: 44562 44563 > rm -rf $HOME/.cache/debuginfod_client 44564 44565 3. Run GDB: 44566 44567 > gdb -nx -q -iex 'set trace-commands on' \ 44568 -iex 'set debuginfod enabled on' \ 44569 -iex 'set confirm off' \ 44570 -ex 'start' -ex 'quit' /bin/ls 44571 +set debuginfod enabled on 44572 +set confirm off 44573 Reading symbols from /bin/ls... 44574 Downloading separate debug info for /usr/bin/ls 44575 ... snip ... 44576 Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde38) at ../src/ls.c:1646 44577 1646 { 44578 +quit 44579 44580 Fatal signal: Segmentation fault 44581 ----- Backtrace ----- 44582 ... snip ... 44583 44584 So GDB ends up crashing during exit. 44585 44586 What's happening is that when debuginfod is initialised 44587 debuginfod_begin is called (this is in the debuginfod library), this 44588 in turn sets up libcurl, which makes use of openssl. Somewhere during 44589 this setup process an at_exit function is registered to cleanup some 44590 state. 44591 44592 Back in GDB the debuginfod_client object is managed using this code: 44593 44594 /* Deleter for a debuginfod_client. */ 44595 44596 struct debuginfod_client_deleter 44597 { 44598 void operator() (debuginfod_client *c) 44599 { 44600 debuginfod_end (c); 44601 } 44602 }; 44603 44604 using debuginfod_client_up 44605 = std::unique_ptr<debuginfod_client, debuginfod_client_deleter>; 44606 44607 And then a global debuginfod_client_up is created to hold a pointer to 44608 the debuginfod_client object. As a global this will be cleaned up 44609 using the standard C++ global object destructor mechanism, which is 44610 run after the at_exit handlers. 44611 44612 However, it is expected that when debuginfod_end is called the 44613 debuginfod_client object will still be in a usable state, that is, we 44614 don't expect the at_exit handlers to have run and started cleaning up 44615 the library state. 44616 44617 To fix this issue we need to ensure that debuginfod_end is called 44618 before the at_exit handlers have a chance to run. 44619 44620 This commit removes the debuginfod_client_up type, and instead has GDB 44621 hold a raw pointer to the debuginfod_client object. We then make use 44622 of GDB's make_final_cleanup to register a function that will call 44623 debuginfod_end. 44624 44625 As GDB's final cleanups are called before exit is called, this means 44626 that debuginfod_end will be called before the at_exit handlers are 44627 called, and the crash identified above is resolved. 44628 44629 It's not obvious how this issue can easily be tested for. The bug does 44630 not appear to manifest when using a local debuginfod server, so we'd 44631 need to setup something more involved. For now I'm proposing this 44632 patch without any associated tests. 44633 44634 Co-Authored-By: Mark Wielaard <mark@klomp.org> 44635 Co-Authored-By: Simon Marchi <simark@simark.ca> 44636 Reviewed-By: Tom Tromey <tom@tromey.com> 44637 Reviewed-By: Aaron Merey <amerey@redhat.com> 44638 446392023-06-09 Andrew Burgess <aburgess@redhat.com> 44640 44641 gdb: fix ASan failure after recent string changes 44642 After this commit: 44643 44644 commit baab375361c365afee2577c94cbbd3fdd443d6da 44645 Date: Tue Jul 13 14:44:27 2021 -0400 44646 44647 gdb: building inferior strings from within GDB 44648 44649 It was pointed out that a new ASan failure had been introduced which 44650 was triggered by gdb.base/internal-string-values.exp: 44651 44652 (gdb) PASS: gdb.base/internal-string-values.exp: test_setting: all langs: lang=ada: ptype "foo" 44653 print $_gdb_maint_setting("test-settings string") 44654 ================================================================= 44655 ==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba682 bp 0x7ffd20644620 sp 0x7ffd20644610 44656 READ of size 1 at 0x603000068034 thread T0 44657 #0 0x564785cba681 in find_command_name_length(char const*) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2129 44658 #1 0x564785cbacb2 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2186 44659 #2 0x564785cbb539 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2248 44660 #3 0x564785cbbcf3 in lookup_cmd(char const**, cmd_list_element*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2339 44661 #4 0x564785c82df2 in setting_cmd /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2219 44662 #5 0x564785c84274 in gdb_maint_setting_internal_fn /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2348 44663 #6 0x564788167b3b in call_internal_function(gdbarch*, language_defn const*, value*, int, value**) /tmp/src/binutils-gdb/gdb/value.c:2321 44664 #7 0x5647854b6ebd in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11254 44665 #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111 44666 #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322 44667 #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335 44668 #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468 44669 #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95 44670 #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735 44671 #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574 44672 #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543 44673 #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779 44674 #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104 44675 #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250 44676 #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) 44677 #20 0x564786683dea in gdb_rl_callback_read_char_wrapper_noexcept /tmp/src/binutils-gdb/gdb/event-top.c:192 44678 #21 0x564786684042 in gdb_rl_callback_read_char_wrapper /tmp/src/binutils-gdb/gdb/event-top.c:225 44679 #22 0x564787f1b119 in stdin_event_handler /tmp/src/binutils-gdb/gdb/ui.c:155 44680 #23 0x56478862438d in handle_file_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:573 44681 #24 0x564788624d23 in gdb_wait_for_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:694 44682 #25 0x56478862297c in gdb_do_one_event(int) /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:264 44683 #26 0x564786df99f0 in start_event_loop /tmp/src/binutils-gdb/gdb/main.c:412 44684 #27 0x564786dfa069 in captured_command_loop /tmp/src/binutils-gdb/gdb/main.c:476 44685 #28 0x564786dff61f in captured_main /tmp/src/binutils-gdb/gdb/main.c:1320 44686 #29 0x564786dff75c in gdb_main(captured_main_args*) /tmp/src/binutils-gdb/gdb/main.c:1339 44687 #30 0x564785381b6d in main /tmp/src/binutils-gdb/gdb/gdb.c:32 44688 #31 0x7f4efbc3984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) 44689 #32 0x7f4efbc39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) 44690 #33 0x564785381934 in _start (/tmp/build/binutils-gdb/gdb/gdb+0xabc5934) (BuildId: 90de353ac158646e7dab501b76a18a76628fca33) 44691 44692 0x603000068034 is located 0 bytes after 20-byte region [0x603000068020,0x603000068034) allocated by thread T0 here: 44693 #0 0x7f4efcee0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 44694 #1 0x5647856265d8 in xcalloc /tmp/src/binutils-gdb/gdb/alloc.c:97 44695 #2 0x564788610c6b in xzalloc(unsigned long) /tmp/src/binutils-gdb/gdbsupport/common-utils.cc:29 44696 #3 0x56478815721a in value::allocate_contents(bool) /tmp/src/binutils-gdb/gdb/value.c:929 44697 #4 0x564788157285 in value::allocate(type*, bool) /tmp/src/binutils-gdb/gdb/value.c:941 44698 #5 0x56478815733a in value::allocate(type*) /tmp/src/binutils-gdb/gdb/value.c:951 44699 #6 0x5647854ae81c in expr::ada_string_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:10675 44700 #7 0x5647854b63b8 in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11184 44701 #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111 44702 #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322 44703 #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335 44704 #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468 44705 #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95 44706 #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735 44707 #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574 44708 #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543 44709 #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779 44710 #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104 44711 #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250 44712 #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) 44713 44714 The problem is in cli/cli-cmds.c, in the function setting_cmd, where 44715 we do this: 44716 44717 const char *a0 = (const char *) argv[0]->contents ().data (); 44718 44719 Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or 44720 a TYPE_CODE_STRING. The problem is that the above line is casting the 44721 value contents directly to a C-string, i.e. one that is assumed to 44722 have a null-terminator at the end. 44723 44724 After the above commit this can no longer be assumed to be true. A 44725 string value will be represented just as it would be in the current 44726 language, so for Ada and Fortran the string will be an array of 44727 characters with no null-terminator at the end. 44728 44729 My proposed solution is to copy the string contents into a std::string 44730 object, and then use the std::string::c_str() value, this will ensure 44731 that a null-terminator has been added. 44732 44733 I had a check through GDB at places TYPE_CODE_STRING was used and 44734 couldn't see any other obvious places where this type of assumption 44735 was being made, so hopefully this is the only offender. 44736 44737 Running the above test with ASan compiled in no longer gives an error. 44738 44739 Reviewed-By: Tom Tromey <tom@tromey.com> 44740 447412023-06-09 Tom Tromey <tromey@adacore.com> 44742 44743 Use scoped_value_mark in two more places 44744 I found a couple of spots that could use scoped_value_mark. One of 44745 them is a spot that didn't consider the possibility that value_mark 44746 can return NULL. I tend to doubt this can be seen in this context, 44747 but nevertheless this is safer. 44748 44749 Regression tested on x86-64 Fedora 36. 44750 447512023-06-09 Tom de Vries <tdevries@suse.de> 44752 44753 [gdb] Fix typos 44754 Fix typos: 44755 - reponse -> response 44756 - inital -> initial 44757 - a -> an 44758 447592023-06-09 Alan Modra <amodra@gmail.com> 44760 44761 readelf/objdump remember_state memory leaks 44762 * dwarf.c (display_debug_frames <DW_CFA_restore_state>): Do free 44763 invalid remember_state. 44764 447652023-06-09 Alan Modra <amodra@gmail.com> 44766 44767 ecoff find_nearest_line and final link leaks 44768 Freeing ecoff_debug_info "pointers to the unswapped symbolic info" 44769 isn't a simple matter, due to differing allocation strategies. In 44770 _bfd_ecoff_slurp_symbolic_info the pointers are to objalloc memory. 44771 In the ecoff linker they are to separately malloc'd memory. In gas we 44772 have most (obj-elf) or all (obj-ecoff) into a single malloc'd buffer. 44773 44774 This patch fixes the leaks for binutils and ld, leaving the gas leaks 44775 for another day. The mips elf backend already had this covered, and 44776 the ecoff backend had a pointer, raw_syments used as a flag, so most 44777 of the patch is moving these around a little so they are accessible 44778 for both ecoff and elf. 44779 44780 include/ 44781 * coff/ecoff.h (struct ecoff_debug_info): Add alloc_syments. 44782 bfd/ 44783 * libecoff.h (struct ecoff_tdata): Delete raw_syments. 44784 * elfxx-mips.c (free_ecoff_debug): Delete. Replace uses with 44785 _bfd_ecoff_free_ecoff_debug_info. 44786 (_bfd_mips_elf_final_link): Init debug.alloc_syments. 44787 * ecofflink.c (_bfd_ecoff_free_ecoff_debug_info): New function. 44788 * ecoff.c (_bfd_ecoff_bfd_free_cached_info): Call 44789 _bfd_ecoff_free_ecoff_debug_info. 44790 (_bfd_ecoff_slurp_symbolic_info): Replace uses of raw_syments 44791 with alloc_syments. 44792 (ecoff_final_link_debug_accumulate): Likewise. Use 44793 _bfd_ecoff_free_ecoff_debug_info. 44794 (_bfd_ecoff_bfd_copy_private_bfd_data): Set alloc_syments for 44795 copied output. 44796 * elf64-alpha.c (elf64_alpha_read_ecoff_info): Use 44797 _bfd_ecoff_free_ecoff_debug_info. 44798 * libbfd-in.h (_bfd_ecoff_free_ecoff_debug_info): Declare. 44799 * libbfd.h: Regenerate. 44800 gas/ 44801 * config/obj-ecoff.c (ecoff_frob_file): Set alloc_syments. 44802 * config/obj-elf.c (elf_frob_file_after_relocs): Likewise. 44803 448042023-06-09 GDB Administrator <gdbadmin@sourceware.org> 44805 44806 Automatic date update in version.in 44807 448082023-06-08 Tom de Vries <tdevries@suse.de> 44809 44810 [gdb/testsuite] Add test-case gdb.tui/long-prompt.exp 44811 I noticed that the test-suite doesn't excercise the case in 44812 tui_redisplay_readline that height (initially 1) is changed by this call: 44813 ... 44814 tui_puts_internal (w, prompt, &height); 44815 ... 44816 44817 Add a test-case that excercises this. 44818 44819 Tested on x86_64-linux. 44820 448212023-06-08 Lancelot SIX <lancelot.six@amd.com> 44822 44823 gdb/corelow.c: do not try to reopen a file if open failed once 44824 In the current implementation, core_target::build_file_mappings will try 44825 to locate and open files which were mapped in the process for which the 44826 core dump was produced. If the file cannot be found or cannot be 44827 opened, GDB will re-try to open it once for each time it was mapped in 44828 the process's address space. 44829 44830 This patch makes it so GDB recognizes that it has already failed to open 44831 a given file once and does not re-try the process for each mapping. 44832 44833 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 44834 Approved-By: Andrew Burgess <aburgess@redhat.com> 44835 448362023-06-08 Lancelot SIX <lancelot.six@amd.com> 44837 44838 gdb/corelow.c: avoid repeated warnings in build_file_mappings 44839 When GDB opens a coredump it tries to locate and then open all files 44840 which were mapped in the process. 44841 44842 If a file is found but cannot be opened with BFD (bfd_open / 44843 bfd_check_format fails), then a warning is printed to the user. If the 44844 same file was mapped multiple times in the process's address space, the 44845 warning is printed once for each time the file was mapped. I find this 44846 un-necessarily noisy. 44847 44848 This patch makes it so the warning message is printed only once per 44849 file. 44850 44851 There was a comment in the code assuming that if the file was found on 44852 the system, opening it (bfd_open + bfd_check_format) should always 44853 succeed. A recent change in BFD (014a602b86f "Don't optimise bfd_seek 44854 to same position") showed that this assumption is not valid. For 44855 example, it is possible to have a core dump of a process which had 44856 mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In 44857 such case the core dump does contain the information that portions of 44858 this special file were mapped in the host process, but trying to seek to 44859 position 0 will fail, making bfd_check_format fail. This patch removes 44860 this comment. 44861 44862 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 44863 Approved-By: Andrew Burgess <aburgess@redhat.com> 44864 448652023-06-08 Lancelot SIX <lancelot.six@amd.com> 44866 44867 gdb/corelow.c: fix use-after-free in build_file_mappings 44868 In core_target::build_file_mappings, GDB tries to open files referenced 44869 in the core dump. 44870 44871 The process goes like this: 44872 44873 struct bfd *bfd = bfd_map[filename]; 44874 if (bfd == nullptr) 44875 { 44876 bfd = bfd_map[filename] 44877 = bfd_openr (expanded_fname.get (), "binary"); 44878 if (bfd == nullptr || !bfd_check_format (bfd, bfd_object)) 44879 { 44880 if (bfd != nullptr) 44881 bfd_close (bfd); 44882 return; 44883 } 44884 } 44885 asection *sec = bfd_make_section_anyway (bfd, "load"); 44886 ... 44887 44888 The problem is that if bfd_check_format fails, we close the bfd but keep 44889 a reference to it in the bfd_map. 44890 44891 If the same filename appears another time in the NT_FILE note, we enter 44892 this code again. The second time, bfd_map[filename] is not nullptr and 44893 we try to call bfd_make_section_anyway on an already closed BFD, which 44894 is a use-after-free error. 44895 44896 This patch makes sure that the bfd is only saved in the bfd_map if it 44897 got opened successfully. 44898 44899 This error got exposed by a recent change in BFD (014a602b86f "Don't 44900 optimise bfd_seek to same position"). Since this change, opening a 44901 coredump which contains mapping to some special files such as a DRI 44902 render node (/dev/dri/renderD$NUM) exposes the issue. This happens for 44903 example for processes using AMDGPU devices to offload compute tasks. 44904 44905 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 44906 Approved-By: Andrew Burgess <aburgess@redhat.com> 44907 449082023-06-08 Alan Modra <amodra@gmail.com> 44909 44910 Re: _bfd_free_cached_info 44911 Oops, another leak caused by not defining the correct macro. 44912 44913 * elf32-mips.c: Define bfd_elf32_bfd_free_cached_info. 44914 * elfn32-mips.c: Likewise. 44915 * elf64-mips.c: Define bfd_elf64_bfd_free_cached_info. 44916 449172023-06-08 Alan Modra <amodra@gmail.com> 44918 44919 Re: _bfd_free_cached_info 44920 ELF targets with target-specific free_cache_info functions need to 44921 call _bfd_elf_free_cached_info, not _bfd_generic_bfd_free_cached_info. 44922 44923 * elf64-ppc.c (ppc64_elf_free_cached_info): Call 44924 _bfd_elf_free_cached_info. 44925 * elfnn-aarch64.c (elfNN_aarch64_bfd_free_cached_info): Likewise. 44926 449272023-06-08 GDB Administrator <gdbadmin@sourceware.org> 44928 44929 Automatic date update in version.in 44930 449312023-06-07 Indu Bhagat <indu.bhagat@oracle.com> 44932 44933 libsframe: reuse static function sframe_decoder_get_funcdesc_at_index 44934 sframe_decoder_get_funcdesc_at_index () is the function to access SFrame 44935 FDEs in the SFrame decoder context. Use it consistently. 44936 44937 Avoid unnecessary type cast and include minor enhancements as the code 44938 is moved around. 44939 44940 libsframe/ 44941 * sframe.c (sframe_decoder_get_funcdesc_at_index): Move some 44942 checks here. Move the static function definition before the new 44943 use. 44944 (sframe_decoder_get_funcdesc): Use 44945 sframe_decoder_get_funcdesc_at_index instead. 44946 449472023-06-07 Tom Tromey <tromey@adacore.com> 44948 44949 Simplify ada_lookup_struct_elt_type 44950 This patch simplifies ada_lookup_struct_elt_type by changing it to 44951 call find_struct_field. The two functions were substantially similar, 44952 even to the point of having identical comments. 44953 44954 I tested this using both the gdb test suite and the internal AdaCore 44955 test suite. Given this and the fact that it is Ada-specific, I am 44956 checking it in. 44957 449582023-06-07 Nick Clifton <nickc@redhat.com> 44959 44960 Add extra linker warning message about discrepancies between normal and common symbols. 44961 PR 30499 44962 bfd * elflink.c (elf_link_add_object_symbols): Add a message indicating that alignment and size discrepancies between the definition of common symbols and normal symbols are serious and should be investigated. 44963 ld * testsuite/ld-elfcomm/elfcomm.exp: Update regexps to match new output from the linker. 44964 449652023-06-07 Tom de Vries <tdevries@suse.de> 44966 44967 [gdb/tui] Factor out border-mode help text 44968 I noticed that the help texts for tui border-mode and tui active-border-mode 44969 are similar. 44970 44971 Factor out the common part into macro HELP_ATTRIBUTE_MODE. 44972 44973 Tested on x86_64-linux. 44974 449752023-06-07 Tom de Vries <tdevries@suse.de> 44976 44977 [gdb/cli] Handle pending ^C after rl_callback_read_char for readline 7 44978 In commit faf01aee1d0 ("[gdb] Handle pending ^C after rl_callback_read_char") 44979 we handled a problem (described in detail in that commit) for readline >= 8 44980 using public readline functions rl_pending_signal and rl_check_signals. 44981 44982 For readline 7 (note that we require at least readline 7 so there's no need to 44983 worry about readline 6), there was no fix though, because rl_check_signals was 44984 not available. 44985 44986 Fix this by instead using the private readline function _rl_signal_handler. 44987 44988 There is precedent for using private readline variables and functions, but 44989 it's something we want to get rid of (PR build/10723). Nevertheless, I think 44990 we can allow this specific instance because it's not used when building 44991 against readline >= 8. 44992 44993 [ In the meanwhile, a fix was committed in the devel branch of the readline 44994 repo, contained in commit 8d0c439 ("rollup of changes since readline-8.2"), 44995 first proposed here ( 44996 https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00008.html ). ] 44997 44998 Tested on x86_64-linux, against system readline 7.0 on openSUSE Leap 15.4. 44999 45000 PR cli/27813 45001 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813 45002 450032023-06-07 Tom de Vries <tdevries@suse.de> 45004 45005 Fix PR30369 regression on aarch64/arm (PR30506) 45006 The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and 45007 Arm. 45008 45009 As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/), 45010 there are issues with both the prologue skipper for AArch64 and Arm and an 45011 incorrect assumption by the testcase. 45012 45013 This patch fixes both of AArch64's and Arm's prologue skippers to not skip past 45014 the end of a function. It also incorporates a fix to the testcase so it 45015 doesn't assume the prologue skipper will stop at the first instruction of the 45016 functions/labels. 45017 45018 Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and 45019 x86_64-linux Ubuntu 20.04. 45020 45021 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30506 45022 45023 Co-Authored-By: Tom de Vries <tdevries@suse.de> 45024 Co-Authored-By: Luis Machado <luis.machado@arm.com> 45025 450262023-06-07 Tom de Vries <tdevries@suse.de> 45027 45028 [gdb/testsuite] Add missing wait in gdb.python/tui-window-disabled.exp 45029 While working on PR tui/30526, I noticed a bug in test-case 45030 gdb.python/tui-window-disabled.exp. 45031 45032 Here we send "tui enable" to gdb, but don't wait for it to arrive before 45033 checking for a window box: 45034 ... 45035 send_gdb "tui enable\n" 45036 Term::check_box "check for python window" 0 0 80 16 45037 ... 45038 45039 Fix this by waiting for the prompt to be issued in TUI before doing the check. 45040 45041 Tested on x86_64-linux. 45042 450432023-06-07 Tom de Vries <tdevries@suse.de> 45044 45045 [gdb/testsuite] Fix two typos in gdb.python/tui-window-disabled.exp 45046 Fix two typos in test-case gdb.python/tui-window-disabled.exp. 45047 450482023-06-07 Tom de Vries <tdevries@suse.de> 45049 45050 [gdb/testsuite] Handle output after prompt in gdb.threads/step-N-all-progress.exp 45051 Using "taskset -c 0" I run into this timeout: 45052 ... 45053 (gdb) PASS: gdb.threads/step-N-all-progress.exp: non-stop=on: \ 45054 target-non-stop=on: continue to breakpoint: break here 45055 next 3^M 45056 [New Thread 0x7ffff7dbd6c0 (LWP 10202)]^M 45057 50 return 0;^M 45058 (gdb) [Thread 0x7ffff7dbd6c0 (LWP 10202) exited]^M 45059 FAIL: gdb.threads/step-N-all-progress.exp: non-stop=on: target-non-stop=on: \ 45060 next 3 (timeout) 45061 ... 45062 45063 The problem is that this test: 45064 ... 45065 gdb_test "next 3" "return 0;" 45066 ... 45067 expects no output after the prompt. 45068 45069 Fix this by using -no-prompt-anchor. 45070 45071 Tested on x86_64-linux. 45072 450732023-06-07 Alan Modra <amodra@gmail.com> 45074 45075 ld-elf/eh5 remove xfail hppa64 45076 Commit cb81e84c72 resulted in an xpass for hppa64-hp-hpux11, but the 45077 test still fails on hpp64-linux. Let's make it pass for hppa64-linux 45078 too, by accepting pcrel sdata8 encoding in the augmentation data. 45079 450802023-06-07 Luis Machado <luis.machado@arm.com> 45081 45082 Fix gdb.base/memtag.exp failure 45083 While running this test on an emulator, I noticed we're failing to match the 45084 output message when "memory-tag check" is issued with no arguments. That's 45085 because I coded the message using "error" and missed a period at the end. Other 45086 similar messages are issued with error_no_arg. 45087 45088 This patch changes that call to use error_no_arg. 45089 45090 Tested on aarch64-linux Ubuntu 20.04/22.04. 45091 450922023-06-07 Alan Modra <amodra@gmail.com> 45093 45094 _bfd_free_cached_info 45095 doc/bfdint.texi and comments in the aout and som code about this 45096 function are just wrong, and its name is not very apt. Better would 45097 be _bfd_mostly_destroy, and we certainly should not be saying anything 45098 about the possibility of later recreating anything lost by this 45099 function. What's more, if _bfd_free_cached_info is called when 45100 creating an archive map to reduce memory usage by throwing away 45101 symbols, the target _close_and_cleanup function won't have access to 45102 tdata or section bfd_user_data to tidy memory. This means most of the 45103 target _close_and_cleanup function won't do anything, and therefore 45104 sometimes will result in memory leaks. 45105 45106 This patch fixes the documentation problems and moves most of the 45107 target _close_and_cleanup code to target _bfd_free_cached_info. 45108 Another notable change is that bfd_generic_bfd_free_cached_info is now 45109 defined as _bfd_free_cached_info rather than _bfd_bool_bfd_true, 45110 ie. the default now frees objalloc memory. 45111 451122023-06-07 Alan Modra <amodra@gmail.com> 45113 45114 Memory leaks in bfd/vms-lib.c 45115 * vms-lib.c (vms_lib_read_index): Free malloc'd memory on error 45116 return paths. 45117 (vms_write_index, _bfd_vms_lib_write_archive_contents): Likewise. 45118 45119 bfd/elf.c strtab memory leak 45120 * elf.c (_bfd_elf_compute_section_file_positions): Free strtab 45121 on set_group_contents failure return path. 45122 451232023-06-07 Alan Modra <amodra@gmail.com> 45124 45125 objcopy memory leaks after errors 45126 These aren't important at all, but tidy them in case they obscure 45127 other more important leaks. 45128 45129 * objcopy (copy_file): Close input bfd after errors. 45130 451312023-06-07 GDB Administrator <gdbadmin@sourceware.org> 45132 45133 Automatic date update in version.in 45134 451352023-06-06 Indu Bhagat <indu.bhagat@oracle.com> 45136 45137 libsframe: fix cosmetic issues and typos 45138 include/ 45139 * sframe-api.h (sframe_decoder_get_num_fidx): Use extern. 45140 libsframe/ 45141 * sframe-dump.c (dump_sframe_func_with_fres): Fix line length. 45142 * sframe.c (sframe_frame_row_entry_copy): Likewise. 45143 (sframe_decode_fre_start_address): Use the intended type uint32_t. 45144 451452023-06-06 Alan Modra <amodra@gmail.com> 45146 45147 Re: loongarch readelf support 45148 Commit 89c70cd358b8 apparently results in a bogus "value may be used 45149 uninitialized" warning with some combination of compiler and 45150 optimisation options. 45151 45152 * readelf.c (target_specific_reloc_handling): Init value. 45153 451542023-06-06 GDB Administrator <gdbadmin@sourceware.org> 45155 45156 Automatic date update in version.in 45157 451582023-06-05 Indu Bhagat <indu.bhagat@oracle.com> 45159 45160 libsframe: avoid unnecessary type casts 45161 Change the data type of some of the members of the sframe_decoder_ctx 45162 and sframe_encoder_ctx data structures to use the applicable data types 45163 explicitly. Current implementation in libsframe does type casts, which 45164 seem unnecessary. 45165 45166 libsframe/ 45167 * libsframe/sframe-impl.h (struct sframe_decoder_ctx): Use 45168 applicable data type explicitly. 45169 (struct sframe_encoder_ctx): Likewise. Use same style of 45170 comments consistently. 45171 * libsframe/sframe.c (struct sf_fde_tbl): Define without 45172 typedef. 45173 (struct sf_fre_tbl): Likewise. 45174 (sframe_decode): Remove unnecessary type casts. 45175 (sframe_encoder_get_funcdesc_at_index): Likewise. 45176 (sframe_encoder_add_fre): Likewise. 45177 (sframe_encoder_add_funcdesc): Likewise. 45178 (sframe_sort_funcdesc): Likewise. 45179 (sframe_encoder_write_sframe): Likewise. 45180 451812023-06-05 H.J. Lu <hjl.tools@gmail.com> 45182 45183 ELF: Add "#pass" to ld-elf/pr30508.d 45184 Add "#pass" to ld-elf/pr30508.d to allow extra segments. 45185 45186 PR binutils/30508 45187 * testsuite/ld-elf/pr30508.d: Add "#pass". 45188 451892023-06-05 Tom Tromey <tromey@adacore.com> 45190 45191 Use unrelocated_addr in dwarf2_fde 45192 This changes dwarf2_fde to use the unrelocated_addr type. This 45193 pointed out a latent bug in dwarf2_frame_cache, where a relocated 45194 address is compared to an unrelocated address. 45195 451962023-06-05 Tom Tromey <tromey@adacore.com> 45197 45198 Use local "text offset" variable in dwarf2_frame_cache 45199 A few spots in dwarf2_frame_cache use: 45200 45201 cache->per_objfile->objfile->text_section_offset () 45202 45203 ... and a subsequent patch will add more, so move this into a local 45204 variable. 45205 452062023-06-05 Tom Tromey <tromey@adacore.com> 45207 45208 Constify dwarf2_cie::augmentation 45209 I noticed that dwarf2_cie::augmentation could be 'const'. 45210 45211 Use "unrelocated" terminology in linetable_entry 45212 I forgot to convert struct linetable_entry to use the "unrelocated" 45213 (as opposed to "raw") terminology. This patch corrects the oversight. 45214 45215 Fix comment in address_class 45216 enum address_class has a stale comment referring to 45217 MSYMBOL_VALUE_RAW_ADDRESS, which no longer exists. This patch updates 45218 the comment. 45219 45220 Use unrelocated_addr in dwarf_decode_lines 45221 This changes dwarf_decode_lines to accept an unrelocated_addr and 45222 fixes up the fallout. 45223 45224 Use unrelocated_addr in the DWARF reader 45225 This changes various spots in the DWARF reader to use 45226 unrelocated_addr. 45227 45228 Move unrelocated_addr to common-types.h 45229 unrelocated_addr is currently defined in symtab.h, but in order to 45230 avoid having to include that in more places, I wanted to move the type 45231 elsewhere. I considered defs.h, but it seemed reasonable to have it 45232 next to CORE_ADDR, which is what this patch does. 45233 45234 Minor cleanup in loclist_describe_location 45235 loclist_describe_location already has a per_objfile local variable, so 45236 use it consistently. 45237 45238 Remove baseaddr parameter from dwarf2_record_block_ranges 45239 dwarf2_record_block_ranges is only ever called with the text section 45240 offset, so this patch removes the parameter entirely. This makes a 45241 subsequent patch a little simpler. 45242 452432023-06-05 H.J. Lu <hjl.tools@gmail.com> 45244 45245 ELF: Don't warn an empty PT_LOAD with the program headers 45246 When rewriting the program headers, don't warn an empty PT_LOAD with the 45247 program headers. 45248 45249 bfd/ 45250 45251 PR binutils/30508 45252 * elf.c (rewrite_elf_program_header): Don't warn if an empty 45253 PT_LOAD contains the program headers. 45254 45255 ld/ 45256 45257 PR binutils/30508 45258 * testsuite/ld-elf/pr30508.d: New file. 45259 * testsuite/ld-elf/pr30508.s: Likewise. 45260 452612023-06-05 Andrew Burgess <aburgess@redhat.com> 45262 45263 gdb: building inferior strings from within GDB 45264 History Of This Patch 45265 ===================== 45266 45267 This commit aims to address PR gdb/21699. There have now been a 45268 couple of attempts to fix this issue. Simon originally posted two 45269 patches back in 2021: 45270 45271 https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html 45272 https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html 45273 45274 Before Pedro then posted a version of his own: 45275 45276 https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html 45277 45278 After this the conversation halted. Then in 2023 I (Andrew) also took 45279 a look at this bug and posted two versions: 45280 45281 https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html 45282 https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html 45283 45284 The approach taken in my first patch was pretty similar to what Simon 45285 originally posted back in 2021. My second attempt was only a slight 45286 variation on the first. 45287 45288 Pedro then pointed out his older patch, and so we arrive at this 45289 patch. The GDB changes here are mostly Pedro's work, but updated by 45290 me (Andrew), any mistakes are mine. 45291 45292 The tests here are a combinations of everyone's work, and the commit 45293 message is new, but copies bits from everyone's earlier work. 45294 45295 Problem Description 45296 =================== 45297 45298 Bug PR gdb/21699 makes the observation that using $_as_string with 45299 GDB's printf can cause GDB to print unexpected data from the 45300 inferior. The reproducer is pretty simple: 45301 45302 #include <stddef.h> 45303 static char arena[100]; 45304 45305 /* Override malloc() so value_coerce_to_target() gets a known 45306 pointer, and we know we"ll see an error if $_as_string() gives 45307 a string that isn't null terminated. */ 45308 void 45309 *malloc (size_t size) 45310 { 45311 memset (arena, 'x', sizeof (arena)); 45312 if (size > sizeof (arena)) 45313 return NULL; 45314 return arena; 45315 } 45316 45317 int 45318 main () 45319 { 45320 return 0; 45321 } 45322 45323 And then in a GDB session: 45324 45325 $ gdb -q test 45326 Reading symbols from /tmp/test... 45327 (gdb) start 45328 Temporary breakpoint 1 at 0x4004c8: file test.c, line 17. 45329 Starting program: /tmp/test 45330 45331 Temporary breakpoint 1, main () at test.c:17 45332 17 return 0; 45333 (gdb) printf "%s\n", $_as_string("hello") 45334 "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 45335 (gdb) quit 45336 45337 The problem above is caused by how value_cstring is used within 45338 py-value.c, but once we understand the issue then it turns out that 45339 value_cstring is used in an unexpected way in many places within GDB. 45340 45341 Within py-value.c we have a null-terminated C-style string. We then 45342 pass a pointer to this string, along with the length of this 45343 string (so not including the null-character) to value_cstring. 45344 45345 In value_cstring GDB allocates an array value of the given character 45346 type, and copies in requested number of characters. However 45347 value_cstring does not add a null-character of its own. This means 45348 that the value created by calling value_cstring is only 45349 null-terminated if the null-character is included in the passed in 45350 length. In py-value.c this is not the case, and indeed, in most uses 45351 of value_cstring, this is not the case. 45352 45353 When GDB tries to print one of these strings the value contents are 45354 pushed to the inferior, and then read back as a C-style string, that 45355 is, GDB reads inferior memory until it finds a null-terminator. For 45356 the py-value.c case, no null-terminator is pushed into the inferior, 45357 so GDB will continue reading inferior memory until a null-terminator 45358 is found, with unpredictable results. 45359 45360 Patch Description 45361 ================= 45362 45363 The first thing this patch does is better define what the arguments 45364 for the two function value_cstring and value_string should represent. 45365 The comments in the header file are updated to describe whether the 45366 length argument should, or should not, include a null-character. 45367 Also, the data argument is changed to type gdb_byte. The functions as 45368 they currently exist will handle wide-characters, in which case more 45369 than one 'char' would be needed for each character. As such using 45370 gdb_byte seems to make more sense. 45371 45372 To avoid adding casts throughout GDB, I've also added an overload that 45373 still takes a 'char *', but asserts that the character type being used 45374 is of size '1'. 45375 45376 The value_cstring function is now responsible for adding a null 45377 character at the end of the string value it creates. 45378 45379 However, once we start looking at how value_cstring is used, we 45380 realise there's another, related, problem. Not every language's 45381 strings are null terminated. Fortran and Ada strings, for example, 45382 are just an array of characters, GDB already has the function 45383 value_string which can be used to create such values. 45384 45385 Consider this example using current GDB: 45386 45387 (gdb) set language ada 45388 (gdb) p $_gdb_setting("arch") 45389 $1 = (97, 117, 116, 111) 45390 (gdb) ptype $ 45391 type = array (1 .. 4) of char 45392 (gdb) p $_gdb_maint_setting("test-settings string") 45393 $2 = (0) 45394 (gdb) ptype $ 45395 type = array (1 .. 1) of char 45396 45397 This shows two problems, first, the $_gdb_setting and 45398 $_gdb_maint_setting functions are calling value_cstring using the 45399 builtin_char character, rather than a language appropriate type. In 45400 the first call, the 'arch' case, the value_cstring call doesn't 45401 include the null character, so the returned array only contains the 45402 expected characters. But, in the $_gdb_maint_setting example we do 45403 end up including the null-character, even though this is not expected 45404 for Ada strings. 45405 45406 This commit adds a new language method language_defn::value_string, 45407 this function takes a pointer and length and creates a language 45408 appropriate value that represents the string. For C, C++, etc this 45409 will be a null-terminated string (by calling value_cstring), and for 45410 Fortran and Ada this can be a bounded array of characters with no null 45411 terminator. Additionally, this new language_defn::value_string 45412 function is responsible for selecting a language appropriate character 45413 type. 45414 45415 After this commit the only calls to value_cstring are from the C 45416 expression evaluator and from the default language_defn::value_string. 45417 45418 And the only calls to value_string are from Fortan, Ada, and ObjectC 45419 related code. 45420 45421 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699 45422 45423 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 45424 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 45425 Co-Authored-By: Pedro Alves <pedro@palves.net> 45426 Approved-By: Simon Marchi <simon.marchi@efficios.com> 45427 454282023-06-05 Tom de Vries <tdevries@suse.de> 45429 45430 [gdb] Fix grammar in comments and docs 45431 Fix grammar in some comments and docs: 45432 - machines that doesn't -> machines that don't 45433 - its a -> it's a 45434 - its the -> it's the 45435 - if does its not -> if it does it's not 45436 - one more instructions if doesn't match -> 45437 one more instruction if it doesn't match 45438 - it's own -> its own 45439 - it's first -> its first 45440 - it's pointer -> its pointer 45441 45442 I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public 45443 domain notice, I've left that alone. 45444 45445 Tested on x86_64-linux. 45446 454472023-06-05 Tom de Vries <tdevries@suse.de> 45448 45449 [gdb] Fix more typos 45450 Fix some more typos: 45451 - distinquish -> distinguish 45452 - actualy -> actually 45453 - singe -> single 45454 - frash -> frame 45455 - chid -> child 45456 - dissassembler -> disassembler 45457 - uninitalized -> uninitialized 45458 - precontidion -> precondition 45459 - regsiters -> registers 45460 - marge -> merge 45461 - sate -> state 45462 - garanteed -> guaranteed 45463 - explictly -> explicitly 45464 - prefices (nonstandard plural) -> prefixes 45465 - bondary -> boundary 45466 - formated -> formatted 45467 - ithe -> the 45468 - arrav -> array 45469 - coresponding -> corresponding 45470 - owend -> owned 45471 - fials -> fails 45472 - diasm -> disasm 45473 - ture -> true 45474 - tpye -> type 45475 45476 There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to 45477 SIG_CODE_BOUNDARY_FAULT. 45478 45479 Tested on x86_64-linux. 45480 454812023-06-05 Alan Modra <amodra@gmail.com> 45482 45483 bfd_error_on_input messages 45484 bfd_errmsg uses asprintf for bfd_error_on_input, which means we 45485 currently leak memory. Keep a static pointer to the message and free 45486 it in various places to minimise the leaks. 45487 bfd_set_input_error (NULL, bfd_error_no_error) is a way to free up the 45488 last string if that matters. 45489 45490 * bfd.c (input_error_msg): New static var. 45491 (bfd_set_input_error): Free it here.. 45492 (bfd_init): ..and here.. 45493 (bfd_errmsg): ..and here. Use it for asprintf output. 45494 454952023-06-05 Alan Modra <amodra@gmail.com> 45496 45497 Yet another ecoff fuzzed object fix 45498 * ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check fdr_ptr 45499 csym against remaining space for symbols. Error on out of bounds 45500 fdr_ptr fields. 45501 455022023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45503 45504 MIPS: sync oprand char usage between mips and micromips 45505 We should try our best to make mips32 using the same 45506 oprand char with micromips. So for mips32, we use: 45507 45508 ^ is added for 5bit sa oprand for some new DSPr2 instructions: 45509 APPEND, PREPEND, PRECR_SRA[_R].PH.W 45510 the LSB bit is 11, like RD. 45511 +t is removed for coprocessor 0 destination register. 45512 'E' does the samething. 45513 +t is now used for RX oprand for MFTR/MTTR (MT ASE) 45514 ? is added for sel oprand for MFTR/MTTR (MT ASE) 45515 For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc, 45516 while for micromips, they are different. 45517 45518 We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2: 45519 concatenating rs with rx as the index of control or data. 45520 455212023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45522 45523 MIPS: add MT ASE support for micromips32 45524 These instructions are descripted in MD00768. 45525 45526 MIPS® Architecture for Programmers 45527 Volume IV-f: The MIPS® MT Module for 45528 the microMIPS32™ Architecture 45529 45530 Document Number: MD00768 45531 Revision 1.12 45532 July 16, 2013 45533 45534 https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf 45535 455362023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45537 45538 Revert "MIPS: add MT ASE support for micromips32" 45539 This reverts commit 783a5f46b0583e9ed3a63acd3361009f46de5c17. 45540 455412023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45542 45543 MIPS: add MT ASE support for micromips32 45544 These instructions are descripted in MD00768. 45545 45546 MIPS® Architecture for Programmers 45547 Volume IV-f: The MIPS® MT Module for 45548 the microMIPS32™ Architecture 45549 45550 Document Number: MD00768 45551 Revision 1.12 45552 July 16, 2013 45553 45554 https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf 45555 455562023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45557 45558 MIPS: fix some ld testcases with compiler 45559 1. config/default.exp: 45560 use -mabi=32 not for -gnuabi64 45561 xfail_from_runlist: remove an element and mark it xfail. 45562 2. ld-elf/indirect.exp: xfail 45563 indirect5a indirect5b indirect6a indirect6b 45564 indirect5c indirect5d indirect6c indirect6d 45565 3. ld-elf/pr23658-2: mips output is not common 45566 4. ld-elf/shared.exp: non-run on mips: Build libpr16496b.so 45567 5. ld-elfvers/vers.exp: 45568 xfail vers4, vers4b 45569 no-run on mips: vers24a, vers24b, vers24c 45570 6. ld-gc/gc.exp: add -KPIC into asflags for pr13683, pr14265, pr19161 45571 7. ld-mips-elf/mips-elf.exp: 45572 use noarch for mips16-local-stubs-1, since it use -mips4 45573 8. ld-plugin/lto.exp: 45574 no-run on mips/linux: PR ld/12982 45575 add -KPIC into asflags for lto-3r, lto-5r, PR ld/19317 (2) 45576 xfail PR ld/15323 (4), PR ld/19317 (3) 45577 9. ld-plugin/plugin.exp: xfail 45578 plugin claimfile lost symbol 45579 plugin claimfile replace symbol 45580 plugin claimfile replace symbol 45581 plugin claimfile lost symbol with source 45582 plugin claimfile replace symbol with source 45583 plugin claimfile resolve symbol with source 45584 plugin 2 with source lib 45585 load plugin 2 with source 45586 plugin 3 with source lib 45587 load plugin 3 with source 45588 11. ld-selective/selective.exp: add -fno-PIC, which is needed for -mno-abicalls 45589 12. ld-shared/shared.exp: xfail shared (non PIC), shared (PIC main, non PIC so) 45590 45591 MIPS: fix -gnuabi64 testsuite 45592 Test on: 45593 mips64-linux-gnuabi64 45594 mips64el-linux-gnuabi64 45595 mipsisa64-linux-gnuabi64 45596 mipsisa64el-linux-gnuabi64 45597 mipsisa64r2-linux-gnuabi64 45598 mipsisa64r2el-linux-gnuabi64 45599 mipsisa64r6-linux-gnuabi64 45600 mipsisa64r6el-linux-gnuabi64 45601 456022023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45603 45604 MIPS: fix r6 testsuites 45605 Introduce 45606 run_dump_test_o32l 45607 run_dump_test_n32l 45608 run_dump_test_n64l 45609 Which use `-march=from-abi` for pre-R6 testcases, 45610 like micromips/mips16e etc. 45611 45612 For cases doesn't use run_dump_test_*, we use 45613 -mips32r2 for micromips32 45614 -mips1 for mips16-32 45615 -march=from-abi for testcases to o32/n32/n64 both/all. 45616 45617 Replace `addi` with `addiu` for some cases for both r6 and pre-R6. 45618 45619 Introduce some new testcases for r6 with FPXX/FP64. 45620 Introduce new testcase: comdat-reloc-r6. 45621 45622 Skip `default` in mips_arch_list_matching if triple is mipsisa*, due to: 45623 1)it will cannot match mipsr6@*.d: since mips32rN/mips64rN 45624 will always be used, it won't be a problem. 45625 2)some test think -march=mips64rN will alway true for mipsisa64rN, 45626 which is not true now. 45627 45628 This patch fix testsuite for all r6-default gnu triples: 45629 mipsisa32r6-linux-gnu 45630 mipsisa32r6el-linux-gnu 45631 mips-img-linux-gnu 45632 mipsel-img-linux-gnu 45633 mipsisa64r6-linux-gnu 45634 mipsisa64r6el-linux-gnu 45635 456362023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45637 45638 MIPS: default r6 if vendor is img 45639 This behavior is used by downstream toolchain since 2014. 45640 We also set the default ABI for mips*-img-elf to O32. 45641 The previous value is NO_ABI, which is not good default ABI. 45642 45643 We don't support mips64*-img* due to GCC doesn't support it, 45644 and We believe that the multilib should be used for this case. 45645 456462023-06-05 YunQiang Su <yunqiang.su@cipunited.com> 45647 45648 MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit 45649 When configure with triples mipsisa[32,64]rN[el,], the march value 45650 is pinned to a fix value if not given explicitly. for example 45651 1) mipsisa32r6-linux-gnu -n32 xx.s will complains that: 45652 -march=mips32r6 is not compatible with the selected ABI 45653 2) mipsisa64r2el-linux-gnu -o32 generates objects with 64bit CPU: 45654 ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV) 45655 They are not good default behaviors: Let's alter the CPU info 45656 45657 Since we are using these triples as a regular linux distributions, 45658 let's alter march according to ABI. 45659 456602023-06-05 GDB Administrator <gdbadmin@sourceware.org> 45661 45662 Automatic date update in version.in 45663 456642023-06-04 GDB Administrator <gdbadmin@sourceware.org> 45665 45666 Automatic date update in version.in 45667 456682023-06-03 Tom de Vries <tdevries@suse.de> 45669 45670 [gdb] Fix typos 45671 Fix a few typos: 45672 - implemention -> implementation 45673 - convertion(s) -> conversion(s) 45674 - backlashes -> backslashes 45675 - signoring -> ignoring 45676 - (un)ambigious -> (un)ambiguous 45677 - occured -> occurred 45678 - hidding -> hiding 45679 - temporarilly -> temporarily 45680 - immediatelly -> immediately 45681 - sillyness -> silliness 45682 - similiar -> similar 45683 - porkuser -> pokeuser 45684 - thats -> that 45685 - alway -> always 45686 - supercede -> supersede 45687 - accomodate -> accommodate 45688 - aquire -> acquire 45689 - priveleged -> privileged 45690 - priviliged -> privileged 45691 - priviledges -> privileges 45692 - privilige -> privilege 45693 - recieve -> receive 45694 - (p)refered -> (p)referred 45695 - succesfully -> successfully 45696 - successfuly -> successfully 45697 - responsability -> responsibility 45698 - wether -> whether 45699 - wich -> which 45700 - disasbleable -> disableable 45701 - descriminant -> discriminant 45702 - construcstor -> constructor 45703 - underlaying -> underlying 45704 - underyling -> underlying 45705 - structureal -> structural 45706 - appearences -> appearances 45707 - terciarily -> tertiarily 45708 - resgisters -> registers 45709 - reacheable -> reachable 45710 - likelyhood -> likelihood 45711 - intepreter -> interpreter 45712 - disassemly -> disassembly 45713 - covnersion -> conversion 45714 - conviently -> conveniently 45715 - atttribute -> attribute 45716 - struction -> struct 45717 - resonable -> reasonable 45718 - popupated -> populated 45719 - namespaxe -> namespace 45720 - intialize -> initialize 45721 - identifer(s) -> identifier(s) 45722 - expection -> exception 45723 - exectuted -> executed 45724 - dungerous -> dangerous 45725 - dissapear -> disappear 45726 - completly -> completely 45727 - (inter)changable -> (inter)changeable 45728 - beakpoint -> breakpoint 45729 - automativ -> automatic 45730 - alocating -> allocating 45731 - agressive -> aggressive 45732 - writting -> writing 45733 - reguires -> requires 45734 - registed -> registered 45735 - recuding -> reducing 45736 - opeartor -> operator 45737 - ommitted -> omitted 45738 - modifing -> modifying 45739 - intances -> instances 45740 - imbedded -> embedded 45741 - gdbaarch -> gdbarch 45742 - exection -> execution 45743 - direcive -> directive 45744 - demanged -> demangled 45745 - decidely -> decidedly 45746 - argments -> arguments 45747 - agrument -> argument 45748 - amespace -> namespace 45749 - targtet -> target 45750 - supress(ed) -> suppress(ed) 45751 - startum -> stratum 45752 - squence -> sequence 45753 - prompty -> prompt 45754 - overlow -> overflow 45755 - memember -> member 45756 - languge -> language 45757 - geneate -> generate 45758 - funcion -> function 45759 - exising -> existing 45760 - dinking -> syncing 45761 - destroh -> destroy 45762 - clenaed -> cleaned 45763 - changep -> changedp (name of variable) 45764 - arround -> around 45765 - aproach -> approach 45766 - whould -> would 45767 - symobl -> symbol 45768 - recuse -> recurse 45769 - outter -> outer 45770 - freeds -> frees 45771 - contex -> context 45772 45773 Tested on x86_64-linux. 45774 45775 Reviewed-By: Tom Tromey <tom@tromey.com> 45776 457772023-06-03 Tom de Vries <tdevries@suse.de> 45778 45779 [gdb/tdep] Fix typo in debug message 45780 In microblaze_analyze_prologue in gdb/microblaze-tdep.c I came across: 45781 ... 45782 microblaze_debug ("got addi r1,r1,%d; contnuing\n", imm); 45783 ... 45784 45785 Fix this by using "continuing". 45786 45787 Reviewed-By: Tom Tromey <tom@tromey.com> 45788 457892023-06-03 Tom de Vries <tdevries@suse.de> 45790 45791 [gdb/python] Fix doc string of valpy_const_value 45792 In gdb/python/py-value.c, in the value_object_methods array I noticed: 45793 ... 45794 { "const_value", valpy_const_value, METH_NOARGS, 45795 "Return a 'const' qualied version of the same value." }, 45796 ... 45797 45798 Fix the qualied -> qualified typo. 45799 45800 Reviewed-By: Tom Tromey <tom@tromey.com> 45801 458022023-06-03 Tom de Vries <tdevries@suse.de> 45803 45804 [gdb/guile] Fix doc string for value-optimized-out? 45805 In gdb/guile/scm-value.c, I noticed in the value_functions array initializer: 45806 ... 45807 { "value-optimized-out?", 1, 0, 0, 45808 as_a_scm_t_subr (gdbscm_value_optimized_out_p), 45809 "\ 45810 Return #t if the value has been optimizd out." }, 45811 ... 45812 There's a typo in the doc string. 45813 45814 Fix this by using "optimized". 45815 45816 Reviewed-By: Tom Tromey <tom@tromey.com> 45817 458182023-06-03 Tom de Vries <tdevries@suse.de> 45819 45820 [gdb/tui] Fix help text of show tui tab-width 45821 I noticed: 45822 ... 45823 (gdb) help show tui tab-width 45824 Show the tab witdh, in characters, for the TUI. 45825 This variable controls how many spaces are used to display a tab character. 45826 ... 45827 a typo: "witdh". 45828 45829 Fix this by using "width" instead. 45830 45831 Reviewed-By: Tom Tromey <tom@tromey.com> 45832 458332023-06-03 Tom de Vries <tdevries@suse.de> 45834 45835 [gdb/cli] Fix help text of maint info target-sections 45836 I noticed a typo: 45837 ... 45838 (gdb) help maint info target-sections 45839 List GDB's internal section table. 45840 45841 Print the current targets section list. This is a sub-set of all 45842 sections, from all objects currently loaded. Usually the ALLOC 45843 sectoins. 45844 ... 45845 45846 Fix this by using "sections". 45847 45848 Reviewed-By: Tom Tromey <tom@tromey.com> 45849 458502023-06-03 Tom de Vries <tdevries@suse.de> 45851 45852 [gdb/cli] Fix help text of maint set ignore-prologue-end-flag 45853 I noticed here: 45854 ... 45855 (gdb) help maint set ignore-prologue-end-flag 45856 Set if the PROLOGUE-END flag is ignored. 45857 The PROLOGUE-END flag from the line-table entries is used to place \ 45858 breakpoints past the prologue of functions. Disabeling its use use forces \ 45859 the use of prologue scanners. 45860 ... 45861 a typo in "Disabeling" and accidental word repetition "use use". 45862 45863 Fix by replacing with "Disabling" and "use". 45864 45865 Reviewed-By: Tom Tromey <tom@tromey.com> 45866 458672023-06-03 Tom de Vries <tdevries@suse.de> 45868 45869 [gdb/compile] Fix typo in debug message 45870 In compile_object_load in gdb/compile/compile-object-load.c I came across: 45871 ... 45872 "Connectiong ELF symbol \"%s\" to the .toc section (%s)\n", 45873 ... 45874 45875 Fix this typo by using "Connecting" instead. 45876 45877 Reviewed-By: Tom Tromey <tom@tromey.com> 45878 458792023-06-03 Tom de Vries <tdevries@suse.de> 45880 45881 [gdbserver] Fix typo in debug message 45882 I noticed in emit_ops_insns in gdbserver/linux-aarch64-low.cc: 45883 ... 45884 threads_debug_printf ("Adding %d instrucions at %s", 45885 ... 45886 45887 Fix the typo by using "instructions" instead. 45888 45889 Reviewed-By: Tom Tromey <tom@tromey.com> 45890 458912023-06-03 Tom de Vries <tdevries@suse.de> 45892 45893 [gdb/ada] Fix argument name misspelling 45894 Two functions use the argument name bounds_prefered_p. 45895 45896 This misspells "preferred". 45897 45898 Fix this by using bounds_preferred_p instead. 45899 45900 Tested on x86_64-linux. 45901 45902 Reviewed-By: Tom Tromey <tom@tromey.com> 45903 459042023-06-03 Alan Modra <amodra@gmail.com> 45905 45906 Re: loongarch readelf support 45907 Another segfault. 45908 45909 * readelf.c (target_specific_reloc_handling): Sanity check 45910 loongarch reloc r_offset. 45911 459122023-06-03 Alan Modra <amodra@gmail.com> 45913 45914 Re: More ecoff sanity checks 45915 Yet another fuzzer fix. 45916 45917 * ecoff.c (ecoff_slurp_symbolic_header <FIX>): Zero counts when 45918 associated pointer is zero. 45919 (_bfd_ecoff_slurp_symbolic_info): Remove now unnecessary check. 45920 459212023-06-03 GDB Administrator <gdbadmin@sourceware.org> 45922 45923 Automatic date update in version.in 45924 459252023-06-02 Luis Machado <luis.machado@arm.com> 45926 45927 [AArch64] Fix architecture debug version constant thinkos 45928 Caught this during emulator testing. 45929 45930 Fix the constants. They should be 0xa and 0xb as opposed to 0x10 and 45931 0x11. There was a thinko while defining them. 45932 45933 Obvious enough. 45934 45935 Tested on aarch64-linux Ubuntu 20.04/22.04. 45936 459372023-06-02 Alan Modra <amodra@gmail.com> 45938 45939 Re: bfd_close and target free_cached_memory 45940 _bfd_delete_bfd can be called early, before the target xvec is set up. 45941 45942 * opncls.c (_bfd_delete_bfd): Don't segfault on NULL xvec. 45943 459442023-06-02 Alan Modra <amodra@gmail.com> 45945 45946 Re: More ecoff sanity checks 45947 Another fix for fuzzed object files, exhibiting as a segfault in 45948 nm.c filter_symbols when accessing a symbol name. 45949 45950 * ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check 45951 fdr_ptr->issBase, and tighten sym.iss check. 45952 459532023-06-02 Alan Modra <amodra@gmail.com> 45954 45955 loongarch readelf support 45956 This fixes two buffer overflows found by fuzzers. 45957 45958 * readelf.c (target_specific_reloc_handling): Sanity check 45959 loongarch reloc symbol index. Don't apply reloc after errors. 45960 Reduce translation work of "invalid symbol index" error message. 45961 459622023-06-02 Alan Modra <amodra@gmail.com> 45963 45964 Minor objcopy optimisation for copy_relocations_in_section 45965 * objcopy (copy_relocations_in_section): Don't read the relocs 45966 for STRIP_ALL if keep_specific_htab is empty. 45967 459682023-06-02 GDB Administrator <gdbadmin@sourceware.org> 45969 45970 Automatic date update in version.in 45971 459722023-06-01 Indu Bhagat <indu.bhagat@oracle.com> 45973 45974 libsframe: avoid using magic number 45975 Define a new constant for the maximum number of stack offsets handled in 45976 libsframe, and use it. Note that the SFrame format does not define such 45977 a constant (limit). This is an implmentation-defined constant in 45978 libsframe. 45979 45980 include/ 45981 * sframe-api.h (MAX_NUM_STACK_OFFSETS): New definition. 45982 libsframe/ 45983 * sframe.c (sframe_fre_sanity_check_p): Use it. 45984 459852023-06-01 Indu Bhagat <indu.bhagat@oracle.com> 45986 45987 libsframe: minor fixups in flip_fre related functions 45988 libsframe/ 45989 * sframe.c (flip_fre_start_address): Remove unnecessary type 45990 cast. Use uint16_t instead of unsigned short. 45991 (flip_fre_stack_offsets): Likewise. 45992 459932023-06-01 Jim Wilson <jimw@sifive.com> 45994 45995 RISC-V: PR30449, Add lga assembler macro support. 45996 Originally discussion, https://github.com/riscv/riscv-isa-manual/pull/539 45997 45998 Added new load address pseudo instruction which is always expanded to GOT 45999 access, no matter the .option rvc is set or not. 46000 46001 gas/ 46002 PR 30449 46003 * config/tc-riscv.c (macro): Add M_LGA support. 46004 * testsuite/gas/riscv/la-variants.d: New. 46005 * testsuite/gas/riscv/la-variants.s: New. 46006 include/ 46007 PR 30449 46008 * opcode/riscv.h (M_LGA): New. 46009 opcodes/ 46010 PR 30449 46011 * riscv-opc.c (riscv_opcodes): Add lga support. 46012 460132023-06-01 Nelson Chu <nelson@rivosinc.com> 46014 46015 [PR ld/22263][PR ld/24676] RISC-V: Avoid spurious R_RISCV_NONE for TLS GD/IE. 46016 For TLS GD/IE, add the same condition with the relocate_section in the 46017 allocate_dynrelocs, to make sure we won't reserve redundant spaces 46018 for dynamic relocations since the conservative estimatation. 46019 46020 After applying this patch, ld seems no longer generate the spurious 46021 R_RISCV_NONE for pr22263-1 test, and the test in pr24676. 46022 46023 bfd/ 46024 PR ld/22263 46025 PR ld/24676 46026 * elfnn-riscv.c (RISCV_TLS_GD_IE_NEED_DYN_RELOC): New defined. 46027 Set NEED_RELOC to true if TLS GD/IE needs dynamic relocations, 46028 and INDX will be the dynamic index. 46029 (allocate_dynrelocs): Don't reserve extra spaces in the rela.got 46030 if RISCV_TLS_GD_IE_NEED_DYN_RELOC set need_reloc to false. This 46031 condition needs to be same as relocate_section. 46032 (relocate_section): Likewise, use the same condition as 46033 allocate_dynrelocs. 46034 460352023-06-01 Alan Modra <amodra@gmail.com> 46036 46037 Harden PowerPC64 OPD handling against fuzzers 46038 PowerPC64 ELFv1 object files should have at most one .opd section, and 46039 OPD handling in elf64-ppc.c makes use of this fact by caching some 46040 .opd section info in the per-object bfd.tdata. This was done to avoid 46041 another word in the target specific section data. Of course, fuzzers 46042 don't respect the ABI, and even non-malicious users can accidentally 46043 create multiple .opd sections. So it is better to avoid possible 46044 buffer overflows and other confusion when OPD handling for a second 46045 .opd section references data for the first .opd section, by keeping 46046 the data per-section. 46047 46048 The patch also fixes a memory leak, and a corner case where I think we 46049 could hit an assertion in opd_entry_value or read out of bounds in 46050 ppc64_elf_branch_reloc doing a final link producing non-ppc64 output. 46051 (It's a really rare corner case because not only would you need to be 46052 linking ppc64 objects to non-ppc64 output, you'd also need a branch 46053 reloc symbol to be defined in a .opd section of a non-ppc64 input.) 46054 46055 * elf64-ppc.c (is_ppc64_elf): Move earlier in file. 46056 (ppc64_elf_branch_reloc): Check symbol bfd before accessing 46057 ppc64 elf specific data structures. 46058 (struct ppc64_elf_obj_tdata): Move opd union.. 46059 (struct _ppc64_elf_section_data): ..to here. 46060 (ppc64_elf_before_check_relocs): Allow for opd sec_type 46061 already set to sec_opd. 46062 (ppc64_elf_check_relocs): Only set sec_type to sec_toc when 46063 unset. Error for unexpected toc relocs. 46064 (opd_entry_value): Return -1 when non-ppc64 rather than 46065 asserting. Check and set sec_type too. Adjust for changed 46066 location of contents and relocs. 46067 (ppc64_elf_relocate_section): Adjust for changed location of 46068 cached .opd relocs. 46069 (ppc64_elf_free_cached_info): New function. 46070 (bfd_elf64_bfd_free_cached_info): Define. 46071 460722023-06-01 Alan Modra <amodra@gmail.com> 46073 46074 bfd_close and target free_cached_memory 46075 bfd_free_cached_info is used in just one place in archive.c, which 46076 means most times we reach bfd_close the function isn't called. On the 46077 other hand, if bfd_free_cached_info is called we can't do much on the 46078 bfd since it loses all its obj_alloc memory. This restricts what can 46079 be done in a target _close_and_cleanup. In particular you can't look 46080 at sections, which leads to duplication of code in target 46081 close_and_cleanup and free_cached_info, eg. elfnn-aarch64.c. 46082 46083 * opncls.c (_bfd_delete_bfd): Call bfd_free_cached_info. 46084 * elfnn-aarch64.c (elfNN_aarch64_close_and_cleanup): Delete. 46085 (bfd_elfNN_close_and_cleanup): Don't define. 46086 * som.c (som_bfd_free_cached_info): Don't call 46087 _bfd_generic_close_and_cleanup here. 46088 (som_close_and_cleanup): Define as _bfd_generic_close_and_cleanup. 46089 460902023-06-01 Alan Modra <amodra@gmail.com> 46091 46092 section_by_target_index memory leak 46093 The rs6000 backend can call coff_section_from_bfd_index from its 46094 object_p function via coff_set_alignment_hook. If the object doesn't 46095 match, or another target matches too, then the hash table needs to be 46096 freed via a cleanup. 46097 46098 * coffgen.c (coff_object_cleanup): New function. 46099 (coff_real_object_p): Return coff_object_cleanup, and call on 46100 failure path. Move declaration to.. 46101 * libcoff-in.h: ..here. 46102 (coff_object_cleanup): Declare. 46103 * coff-stgo32.c (go32exe_cleanup): Call coff_object_cleanup. 46104 (go32exe_check_format): Adjust assertion. 46105 * libcoff.h: Regenerate. 46106 461072023-06-01 Alan Modra <amodra@gmail.com> 46108 46109 Remove BFD_FAIL in cpu-sh.c 46110 The assertions in cpu-sh.c can be triggered by passing bogus values 46111 in disassemble_info.mach. This doesn't cause any bfd misbehaviour. 46112 46113 * cpu-sh.c (sh_get_arch_from_bfd_mach): Remove BFD_FAIL. 46114 (sh_get_arch_up_from_bfd_mach): Likewise. 46115 461162023-06-01 GDB Administrator <gdbadmin@sourceware.org> 46117 46118 Automatic date update in version.in 46119 461202023-05-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 46121 46122 gprofng: Fix -Wsign-compare warning 46123 gprofng/ChangeLog 46124 2023-05-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 46125 46126 PR gprofng/30490 46127 * src/LoadObject.cc: Fix -Wsign-compare warning. 46128 461292023-05-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 46130 46131 gprofng: 29470 The test suite should be made more flexible 46132 I add two new targets (check-extra, check-install) for gprofng testing: 46133 `make check` runs sanity testing for gprofng and takes ~30 secunds. 46134 `make check-extra` runs all gprofng tests and takes ~20 minutus. 46135 `make check-install` runs all gprofng tests and uses gprofng installation. 46136 46137 On aarch64, there are unwind problems in libgp-collector.so. 46138 I set ACCT_FILTER to temporarily ignore problematic functions. 46139 46140 gprofng/ChangeLog 46141 2023-05-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 46142 46143 PR gprofng/29470 46144 * Makefile.am: Add check-extra, check-install. 46145 * Makefile.in: Rebuild 46146 * testsuite/config/default.exp: Set the GPROFNG variable. 46147 * testsuite/gprofng.display/display.exp: Updated the test list. 46148 * testsuite/gprofng.display/jsynprog/Intface.java: Correct copyright. 46149 * testsuite/gprofng.display/jsynprog/Launcher.java: Likewise. 46150 * testsuite/gprofng.display/jsynprog/Makefile: Likewise. 46151 * testsuite/gprofng.display/jsynprog/Routine.java: Likewise. 46152 * testsuite/gprofng.display/jsynprog/Sub_Routine.java: Likewise. 46153 * testsuite/gprofng.display/jsynprog/cloop.cc: Likewise. 46154 * testsuite/gprofng.display/jsynprog/jsynprog.h: Likewise. 46155 * testsuite/gprofng.display/jsynprog/jsynprog.java: Correct copyright. 46156 Add the -j option to run the selected functions. 46157 * testsuite/gprofng.display/synprog/check_results.pl: 46158 Remove unused environment variable. 46159 * testsuite/gprofng.display/synprog/synprog.c: Updated DEFAULT_COMMAND. 46160 * testsuite/lib/Makefile.skel: Apply $(ACCT_FILTER). 46161 * testsuite/lib/acct.pm: Ignore errors when $(ACCT_FILTER) is set. 46162 * testsuite/lib/display-lib.exp: Add TARGET_FLAGS in make_args. 46163 461642023-05-31 Tom Tromey <tromey@adacore.com> 46165 46166 Improve MI -dprintf-insert documentation 46167 I found the documentation for -dprintf-insert a bit unclear. It 46168 didn't mention the possibility of multiple arguments, and I also 46169 noticed that it implied that the format parameter is optional, which 46170 it is not. 46171 46172 While looking into this I also noticed a few comments in the 46173 implementation that could also be improved. 46174 46175 Then, I noticed a repeated call to strlen in a loop condition, so I 46176 fixed this up as well. 46177 46178 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 46179 461802023-05-31 Tom Tromey <tromey@adacore.com> 46181 46182 Pass correct name to @value in gdb.texinfo 46183 I noticed a couple instance of this warning when rebuilding the gdb 46184 info files: 46185 46186 warning: undefined flag: GDB 46187 46188 The problem is that the wrong argument was passed to @value. This 46189 patch fixes the problem. 46190 461912023-05-31 Tom de Vries <tdevries@suse.de> 46192 46193 [gdb/testsuite] Fix gdb.tui/wrap-line.exp with --disable-tui 46194 When running the test-case gdb.tui/wrap-line.exp with a build configured with 46195 --disable-tui, we run into: 46196 ... 46197 (gdb) PASS: gdb.tui/wrap-line.exp: width-hard-coded: set width 50 46198 tui new-layout command-layout cmd 1^M 46199 Undefined command: "tui". Try "help".^M 46200 (gdb) ERROR: Undefined command "tui new-layout command-layout cmd 1". 46201 ... 46202 46203 Fix this by guarding the command with allow_tui_tests. 46204 46205 Tested on x86_64-linux. 46206 462072023-05-31 Tom de Vries <tdevries@suse.de> 46208 46209 [gdb/testsuite] Fix gdb.tui/pr30056.exp for native-extended-gdbserver 46210 When running test-case gdb.tui/pr30056.exp with target board 46211 native-extended-gdbserver, I run into: 46212 ... 46213 Quit^[[K^M^[[B(gdb) PASS: gdb.tui/pr30056.exp: Control-C 46214 Remote debugging from host ::1, port 38810^M 46215 ^M(failed reverse-i-search)`xyz': ^M(gdb) target extended-remote \ 46216 localhost:2346^[[7GWARNING: Timed out waiting for EOF in server after \ 46217 monitor exit 46218 ... 46219 46220 This is due to the fact that ^C doesn't abort the reverse-i-search. This 46221 appears to be due to a readline problem. A PR is open about this: PR 46222 cli/30498. 46223 46224 Add a KFAIL for the PR, and ensure that the isearch is aborted by using ^G, 46225 such that we have a responsive prompt to handle the "monitor exit" command 46226 that native-extended-gdbserver issues. 46227 46228 Tested on x86_64-linux. 46229 462302023-05-31 Tristan Gingold <tgingold@free.fr> 46231 46232 pe/coff - add support for base64 encoded long section names 46233 PR 30444 46234 * coffcode.h (coff_write_object_contents): Handle base64 encoding on PE. Also check for too large string table. 46235 * coffgen.c (extract_long_section_name): New function extracted from ... (make_a_section_from_file): ... here. Add support for base64 long section names. (decode_base64): New function. 46236 462372023-05-31 Nick Clifton <nickc@redhat.com> 46238 46239 Fix printf formating issues in elfxx-loongarch64.c 46240 462412023-05-31 Felix Willgerodt <felix.willgerodt@intel.com> 46242 46243 python, btrace: Fix some small formatting issues. 46244 Reviewed-By: Tom Tromey <tom@tromey.com> 46245 462462023-05-31 Tom de Vries <tdevries@suse.de> 46247 46248 [gdb/tui] Fix fingerprint for cmd-only layout 46249 I added a cmd-only layout: 46250 ... 46251 (gdb) tui new-layout cmd cmd 1 46252 ... 46253 and set it: 46254 ... 46255 (gdb) layout cmd 46256 ... 46257 which gave me the expect result: only the cmd window in the screen. 46258 46259 However, after going back to layout src: 46260 ... 46261 (gdb) layout src 46262 ... 46263 I got a source window with only one line in it, and the cmd window taking most 46264 of the screen. 46265 46266 I traced this back to tui_set_layout, where for both the old and the new 46267 layout the fingerprint of the cmd window in the layout is taken. If the 46268 fingerprint is the same, an effort will be done to preserve the command 46269 window size. 46270 46271 The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which 46272 explains the behaviour. 46273 46274 I think this is essentially a bug in the finger print calculation, and it 46275 should be "C" for the cmd layout. 46276 46277 Fix this by not adding a V or H in the fingerprint if the list size is one. 46278 46279 Tested on x86_64-linux. 46280 46281 Reviewed-By: Tom Tromey <tom@tromey.com> 46282 462832023-05-31 GDB Administrator <gdbadmin@sourceware.org> 46284 46285 Automatic date update in version.in 46286 462872023-05-30 Andrew Burgess <aburgess@redhat.com> 46288 46289 gdb: add support for %V to printf command 46290 This commit adds a new format for the printf and dprintf commands: 46291 '%V'. This new format takes any GDB expression and formats it as a 46292 string, just as GDB would for a 'print' command, e.g.: 46293 46294 (gdb) print a1 46295 $a = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20} 46296 (gdb) printf "%V\n", a1 46297 {2, 4, 6, 8, 10, 12, 14, 16, 18, 20} 46298 (gdb) 46299 46300 It is also possible to pass the same options to %V as you might pass 46301 to the print command, e.g.: 46302 46303 (gdb) print -elements 3 -- a1 46304 $4 = {2, 4, 6...} 46305 (gdb) printf "%V[-elements 3]\n", a1 46306 {2, 4, 6...} 46307 (gdb) 46308 46309 This new feature would effectively replace an existing feature of GDB, 46310 the $_as_string builtin convenience function. However, the 46311 $_as_string function has a few problems which this new feature solves: 46312 46313 1. $_as_string doesn't currently work when the inferior is not 46314 running, e.g: 46315 46316 (gdb) printf "%s", $_as_string(a1) 46317 You can't do that without a process to debug. 46318 (gdb) 46319 46320 The reason for this is that $_as_string returns a value object with 46321 string type. When we try to print this we call value_as_address, 46322 which ends up trying to push the string into the inferior's address 46323 space. 46324 46325 Clearly we could solve this problem, the string data exists in GDB, so 46326 there's no reason why we have to push it into the inferior, but this 46327 is an existing problem that would need solving. 46328 46329 2. $_as_string suffers from the fact that C degrades arrays to 46330 pointers, e.g.: 46331 46332 (gdb) printf "%s\n", $_as_string(a1) 46333 0x404260 <a1> 46334 (gdb) 46335 46336 The implementation of $_as_string is passed a gdb.Value object that is 46337 a pointer, it doesn't understand that it's actually an array. Solving 46338 this would be harder than issue #1 I think. The whole array to 46339 pointer transformation is part of our expression evaluation. And in 46340 most cases this is exactly what we want. It's not clear to me how 46341 we'd (easily) tell GDB that we didn't want this reduction in _some_ 46342 cases. But I'm sure this is solvable if we really wanted to. 46343 46344 3. $_as_string is a gdb.Function sub-class, and as such is passed 46345 gdb.Value objects. There's no super convenient way to pass formatting 46346 options to $_as_string. By this I mean that the new %V feature 46347 supports print formatting options. Ideally, we might want to add this 46348 feature to $_as_string, we might imagine it working something like: 46349 46350 (gdb) printf "%s\n", $_as_string(a1, 46351 elements = 3, 46352 array_indexes = True) 46353 46354 where the first item is the value to print, while the remaining 46355 options are the print formatting options. However, this relies on 46356 Python calling syntax, which isn't something that convenience 46357 functions handle. We could possibly rely on strictly positional 46358 arguments, like: 46359 46360 (gdb) printf "%s\n", $_as_string(a1, 3, 1) 46361 46362 But that's clearly terrible as there's far more print formatting 46363 options, and if you needed to set the 9th option you'd need to fill in 46364 all the previous options. 46365 46366 And right now, the only way to pass these options to a gdb.Function is 46367 to have GDB first convert them all into gdb.Value objects, which is 46368 really overkill for what we want. 46369 46370 The new %V format solves all these problems: the string is computed 46371 and printed entirely on the GDB side, we are able to print arrays as 46372 actual arrays rather than pointers, and we can pass named format 46373 arguments. 46374 46375 Finally, the $_as_string is sold in the manual as allowing users to 46376 print the string representation of flag enums, so given: 46377 46378 enum flags 46379 { 46380 FLAG_A = (1 << 0), 46381 FLAG_B = (1 << 1), 46382 FLAG_C = (1 << 1) 46383 }; 46384 46385 enum flags ff = FLAG_B; 46386 46387 We can: 46388 46389 (gdb) printf "%s\n", $_as_string(ff) 46390 FLAG_B 46391 46392 This works just fine with %V too: 46393 46394 (gdb) printf "%V\n", ff 46395 FLAG_B 46396 46397 So all functionality of $_as_string is replaced by %V. I'm not 46398 proposing to remove $_as_string, there might be users currently 46399 depending on it, but I am proposing that we don't push $_as_string in 46400 the documentation. 46401 46402 As %V is a feature of printf, GDB's dprintf breakpoints naturally gain 46403 access to this feature too. dprintf breakpoints can be operated in 46404 three different styles 'gdb' (use GDB's printf), 'call' (call a 46405 function in the inferior), or 'agent' (perform the dprintf on the 46406 remote). 46407 46408 The use of '%V' will work just fine when dprintf-style is 'gdb'. 46409 46410 When dprintf-style is 'call' the format string and arguments are 46411 passed to an inferior function (printf by default). In this case GDB 46412 doesn't prevent use of '%V', but the documentation makes it clear that 46413 support for '%V' will depend on the inferior function being called. 46414 46415 I chose this approach because the current implementation doesn't place 46416 any restrictions on the format string when operating in 'call' style. 46417 That is, the user might already be calling a function that supports 46418 custom print format specifiers (maybe including '%V') so, I claim, it 46419 would be wrong to block use of '%V' in this case. The documentation 46420 does make it clear that users shouldn't expect this to "just work" 46421 though. 46422 46423 When dprintf-style is 'agent' then GDB does no support the use of 46424 '%V' (right now). This is handled at the point when GDB tries to 46425 process the format string and send the dprintf command to the remote, 46426 here's an example: 46427 46428 Reading symbols from /tmp/hello.x... 46429 (gdb) dprintf call_me, "%V", a1 46430 Dprintf 1 at 0x401152: file /tmp/hello.c, line 8. 46431 (gdb) set sysroot / 46432 (gdb) target remote | gdbserver --once - /tmp/hello.x 46433 Remote debugging using | gdbserver --once - /tmp/hello.x 46434 stdin/stdout redirected 46435 Process /tmp/hello.x created; pid = 3088822 46436 Remote debugging using stdio 46437 Reading symbols from /lib64/ld-linux-x86-64.so.2... 46438 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 46439 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 46440 (gdb) set dprintf-style agent 46441 (gdb) c 46442 Continuing. 46443 Unrecognized format specifier 'V' in printf 46444 Command aborted. 46445 (gdb) 46446 46447 This is exactly how GDB would handle any other invalid format 46448 specifier, for example: 46449 46450 Reading symbols from /tmp/hello.x... 46451 (gdb) dprintf call_me, "%Q", a1 46452 Dprintf 1 at 0x401152: file /tmp/hello.c, line 8. 46453 (gdb) set sysroot / 46454 (gdb) target remote | gdbserver --once - /tmp/hello.x 46455 Remote debugging using | gdbserver --once - /tmp/hello.x 46456 stdin/stdout redirected 46457 Process /tmp/hello.x created; pid = 3089193 46458 Remote debugging using stdio 46459 Reading symbols from /lib64/ld-linux-x86-64.so.2... 46460 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 46461 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 46462 (gdb) set dprintf-style agent 46463 (gdb) c 46464 Continuing. 46465 Unrecognized format specifier 'Q' in printf 46466 Command aborted. 46467 (gdb) 46468 46469 The error message isn't the greatest, but improving that can be put 46470 off for another day I hope. 46471 46472 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 46473 Acked-By: Simon Marchi <simon.marchi@efficios.com> 46474 464752023-05-30 Simon Marchi <simon.marchi@efficios.com> 46476 46477 gdb: add interp::on_memory_changed method 46478 Same idea as previous patches, but for memory_changed. 46479 46480 Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82 46481 464822023-05-30 Simon Marchi <simon.marchi@efficios.com> 46483 46484 gdb: add interp::on_param_changed method 46485 Same idea as previous patches, but for command_param_changed. 46486 46487 Change-Id: I7c2196343423360da05f016f8ffa871c064092bb 46488 464892023-05-30 Simon Marchi <simon.marchi@efficios.com> 46490 46491 gdb: add interp::on_breakpoint_modified method 46492 Same idea as previous patches, but for breakpoint_modified. 46493 46494 Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328 46495 464962023-05-30 Simon Marchi <simon.marchi@efficios.com> 46497 46498 gdb: add interp::on_breakpoint_deleted method 46499 Same idea as previous patches, but for breakpoint_deleted. 46500 46501 Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c 46502 465032023-05-30 Simon Marchi <simon.marchi@efficios.com> 46504 46505 gdb: add interp::on_breakpoint_created method 46506 Same idea as previous patches, but for breakpoint_created. 46507 46508 Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef 46509 465102023-05-30 Simon Marchi <simon.marchi@efficios.com> 46511 46512 gdb: add interp::on_tsv_modified method 46513 Same idea as previous patches, but for tsv_modified. 46514 46515 Change-Id: I55454a2386d5450040b3a353909b26f389a43682 46516 465172023-05-30 Simon Marchi <simon.marchi@efficios.com> 46518 46519 gdb: add interp::on_tsv_deleted method 46520 Same idea as previous patches, but for tsv_deleted. 46521 46522 Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75 46523 465242023-05-30 Simon Marchi <simon.marchi@efficios.com> 46525 46526 gdb: add interp::on_tsv_created method 46527 Same idea as previous patches, but for tsv_created. 46528 46529 Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5 46530 465312023-05-30 Simon Marchi <simon.marchi@efficios.com> 46532 46533 gdb: add interp::on_traceframe_changed method 46534 Same idea as previous patches, but for traceframe_changed. 46535 46536 Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637 46537 465382023-05-30 Simon Marchi <simon.marchi@efficios.com> 46539 46540 gdb: add interp::on_about_to_proceed method 46541 Same idea as previous patches, but for about_to_proceed. We only need 46542 (and want, as far as the mi_interp implementation is concerned) to 46543 notify the interpreter that caused the proceed. 46544 46545 Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89 46546 465472023-05-30 Simon Marchi <simon.marchi@efficios.com> 46548 46549 gdb: add interp::on_solib_unloaded method 46550 Same idea as previous patches, but for solib_unloaded. 46551 46552 Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5 46553 465542023-05-30 Simon Marchi <simon.marchi@efficios.com> 46555 46556 gdb: add interp::on_solib_loaded method 46557 Same idea as previous patches, but for solib_loaded 46558 46559 Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55 46560 465612023-05-30 Simon Marchi <simon.marchi@efficios.com> 46562 46563 gdb: add interp::on_target_resumed method 46564 Same idea as previous patches, but for target_resumed. 46565 46566 Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c 46567 465682023-05-30 Simon Marchi <simon.marchi@efficios.com> 46569 46570 gdb: add interp::on_record_changed method 46571 Same idea as previous patches, but for record_changed 46572 46573 Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40 46574 465752023-05-30 Simon Marchi <simon.marchi@efficios.com> 46576 46577 gdb: add interp::on_inferior_removed method 46578 Same idea as previous patches, but for inferior_removed. 46579 46580 Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0 46581 465822023-05-30 Simon Marchi <simon.marchi@efficios.com> 46583 46584 gdb: add interp::on_inferior_disappeared method 46585 Same idea as previous patches, but for inferior_disappeared. 46586 46587 For symmetry with on_inferior_appeared, I named this one 46588 on_inferior_disappeared, despite the observer being called 46589 inferior_exit. This is called when detaching an inferior, so I think 46590 that calling it "disappeared" is a bit less misleading (the observer 46591 should probably be renamed later). 46592 46593 Change-Id: I372101586bc9454997953c1e540a2a6685f53ef6 46594 465952023-05-30 Simon Marchi <simon.marchi@efficios.com> 46596 46597 gdb: add interp::on_inferior_appeared method 46598 Same idea as previous patches, but for inferior_appeared. 46599 46600 Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5 46601 466022023-05-30 Simon Marchi <simon.marchi@efficios.com> 46603 46604 gdb: add interp::on_inferior_added method 46605 Same idea as previous patches, but for inferior_added. 46606 46607 mi_interp::init avoided using mi_inferior_added, since, as the comment 46608 used to say, it would notify all MI interpreters. Now, it's easy to 46609 only notify the new interpreter, so it's possible to just call the 46610 on_inferior_added method in mi_interp::init. 46611 46612 Change-Id: I0eddbd5367217d1c982516982089913019ef309f 46613 466142023-05-30 Simon Marchi <simon.marchi@efficios.com> 46615 46616 gdb: add interp::on_thread_exited method 46617 Same idea as previous patches, but for thread_exited. 46618 46619 Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9 46620 466212023-05-30 Simon Marchi <simon.marchi@efficios.com> 46622 46623 gdb: add interp::on_new_thread method 46624 Same idea as previous patches, but for new_thread. 46625 46626 Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c 46627 466282023-05-30 Simon Marchi <simon.marchi@efficios.com> 46629 46630 gdb: add interp::on_user_selected_context_changed method 46631 Same as previous patches, but for user_selected_context_changed. 46632 46633 Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be 46634 466352023-05-30 Simon Marchi <simon.marchi@efficios.com> 46636 46637 gdb: add interp::on_command_error method 46638 Same idea as the previous patches, but for command_error. 46639 46640 Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d 46641 466422023-05-30 Simon Marchi <simon.marchi@efficios.com> 46643 46644 gdb: add interp::on_sync_execution_done method 46645 Same as previous patches, but for sync_execution_done. Except that 46646 here, we only want to notify the interpreter that is executing the 46647 command, not all interpreters. 46648 46649 Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b 46650 466512023-05-30 Simon Marchi <simon.marchi@efficios.com> 46652 46653 gdb: add interp::on_no_history method 46654 Same as previous patches, but for no_history. 46655 46656 Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da 46657 466582023-05-30 Simon Marchi <simon.marchi@efficios.com> 46659 46660 gdb: add interp::on_exited method 46661 Same as previous patch, but for exited. Remove the exited observable, 46662 since nothing uses it anymore, and we don't have anything coming that 46663 will use it. 46664 46665 Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb 46666 466672023-05-30 Simon Marchi <simon.marchi@efficios.com> 46668 46669 gdb: add interp::on_signal_exited method 46670 Same as previous patch, but for signal_exited. Remove the signal_exited 46671 observable, since nothing uses it anymore, and we don't have anything 46672 coming that will use it. 46673 46674 Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10 46675 466762023-05-30 Simon Marchi <simon.marchi@efficios.com> 46677 46678 gdb: add interp::on_normal_stop method 46679 Same idea as the previous patch, but for the normal_stop event. 46680 46681 Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863 46682 466832023-05-30 Simon Marchi <simon.marchi@efficios.com> 46684 46685 gdb: add interp::on_signal_received method 46686 Instead of having the interpreter code registering observers for the 46687 signal_received observable, add a "signal_received" virtual method to 46688 struct interp. Add a interps_notify_signal_received function that loops 46689 over all UIs and calls the signal_received method on the interpreter. 46690 Finally, add a notify_signal_received function that calls 46691 interps_notify_signal_received and then notifies the observers. Replace 46692 all existing notifications to the signal_received observers with calls 46693 to notify_signal_received. 46694 46695 Before this patch, the CLI and MI code both register a signal_received 46696 observer. These observer go over all UIs, and, for those that have a 46697 interpreter of the right kind, print the stop notifiation. 46698 46699 After this patch, we have just one "loop over all UIs", inside 46700 interps_notify_signal_received. Since the interp::on_signal_received 46701 method gets called once for each interpreter, the implementations only 46702 need to deal with the current interpreter (the "this" pointer). 46703 46704 The motivation for this patch comes from a future patch, that makes the 46705 amdgpu code register an observer to print a warning after the CLI's 46706 signal stop message. Since the amdgpu and the CLI code both use 46707 observers, the order of the two messages is not stable, unless we define 46708 the priority using the observer dependency system. However, the 46709 approach of using virtual methods on the interpreters seems like a good 46710 change anyway, I think it's more straightforward and simple to 46711 understand than the current solution that uses observers. We are sure 46712 that the amdgpu message gets printed after the CLI message, since 46713 observers are notified after interpreters. 46714 46715 Keep the signal_received, even if nothing uses if, because we will be 46716 using it in the upcoming amdgpu patch implementing the warning described 46717 above. 46718 46719 Change-Id: I4d8614bb8f6e0717f4bfc2a59abded3702f23ac4 46720 467212023-05-30 Tom de Vries <tdevries@suse.de> 46722 46723 [gdb] Mention --with/without-system-readline for --configuration 46724 Simon reported that the new test-case gdb.tui/pr30056.exp fails with system 46725 readline. 46726 46727 This is because the test-case requires a fix in readline that's present in our 46728 in-repo copy of readline, but most likely not in any system readline yet. 46729 46730 Fix this by: 46731 - mentioning --with-system-readline or --without-system-readline in the 46732 configuration string. 46733 - adding a new proc with_system_readline that makes this information available 46734 in the testsuite. 46735 - using this in test-case gdb.tui/pr30056.exp to declare it unsupported for 46736 --with-system-readline. 46737 46738 Tested on x86_64-linux. 46739 46740 Reported-By: Simon Marchi <simon.marchi@efficios.com> 46741 Approved-By: Simon Marchi <simon.marchi@efficios.com> 46742 467432023-05-30 Nick Clifton <nickc@redhat.com> 46744 46745 Slight wording improvement for the -Ur documentation 46746 46747 Improve header information displayed with objdump -P for PE binaries. 46748 * od-pe.c (targ_info): New array. 46749 (get_target_specific_info): New function. 46750 (decode_machine_number): Retire. Use get_target_specific_info instead. 46751 (is_pe_object_magic): Likewise. 46752 (dump_pe_file_header): Display more information. 46753 Rework layout to be similar to that from 'objdump -p'. 46754 Add code to handle larger than normnal AOUT headers. 46755 467562023-05-30 mengqinggang <mengqinggang@loongson.cn> 46757 46758 LoongArch: ld: Add support for linker relaxation. 46759 Add ld relax support and testsuits. 46760 46761 ld/ChangeLog: 46762 46763 * emultempl/loongarchelf.em: Regenerated. 46764 * testsuite/ld-elf/compressed1d.d: Xfail loongarch*-*. 46765 * testsuite/ld-elf/pr26936.d: Likewise. 46766 * testsuite/ld-loongarch-elf/disas-jirl.d: Regenerated. 46767 * testsuite/ld-loongarch-elf/disas-jirl-32.d: Regenerated. 46768 * testsuite/ld-loongarch-elf/jmp_op.d: Likewise. 46769 * testsuite/ld-loongarch-elf/macro_op.d: Likewise. 46770 * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise. 46771 * testsuite/ld-loongarch-elf/relax-align.dd: New test. 46772 * testsuite/ld-loongarch-elf/relax-align.s: New test. 46773 * testsuite/ld-loongarch-elf/relax.exp: New test. 46774 * testsuite/ld-loongarch-elf/relax.s: New test. 46775 * testsuite/ld-loongarch-elf/uleb128.dd: New test. 46776 * testsuite/ld-loongarch-elf/uleb128.s: New test. 46777 467782023-05-30 mengqinggang <mengqinggang@loongson.cn> 46779 46780 LoongArch: gas: Add support for linker relaxation. 46781 Add gas -mrelax and -mno-relax option. 46782 Add R_LARCH_RELAX reloc for instrction if it can be relaxed. 46783 ADD R_LARCH_ALIGN reloc for align pseudo instruction because relax. 46784 Add ADD/SUB reloc pair for debug and exception data to calculate symbol 46785 substraction because relax. 46786 46787 gas/ChangeLog: 46788 46789 * config/tc-loongarch.c: 46790 (struct loongarch_cl_insn): New macro_id member. 46791 (enum options): New OPTION_RELAX and OPTION_NO_RELAX. 46792 (struct option): New mrelax and mno-relax. 46793 (md_parse_option): Likewise. 46794 (get_internal_label): 46795 (loongarch_args_parser_can_match_arg_helper): Generate relax reloc. 46796 (move_insn): Set fx_frag and fx_where if exist. 46797 (append_fixp_and_insn): Call frag_wane and frag_new for linker relax 46798 relocs. 46799 (loongarch_assemble_INSNs): New loongarch_cl_insn pointer parameter. 46800 (md_assemble): Fix function call. 46801 (fix_reloc_insn): Likewise. 46802 (md_apply_fix): Generate ADD/SUB reloc pair for debug and exception 46803 data. 46804 (loongarch_fix_adjustable): Delete. 46805 (md_convert_frag): Generate new fix. 46806 (loongarch_pre_output_hook): New function. 46807 (loongarch_make_nops): Likewise. 46808 (loongarch_frag_align_code): Likewise. 46809 (loongarch_insert_uleb128_fixes): Likewise. 46810 (loongarch_md_finish): Likewise. 46811 * config/tc-loongarch.h 46812 (md_allow_local_subtract): New macro define. 46813 (loongarch_frag_align_code): New declare. 46814 (md_do_align): Likewise. 46815 (loongarch_fix_adjustable): Delete. 46816 (tc_fix_adjustable): New macro define. 46817 (TC_FORCE_RELOCATION_SUB_SAME): Likewise. 46818 (TC_LINKRELAX_FIXUP): Likewise. 46819 (TC_FORCE_RELOCATION_LOCAL): Likewise. 46820 (DWARF2_USE_FIXED_ADVANCE_PC): Likewise. 46821 (MD_APPLY_SYM_VALUE): Likewise. 46822 (tc_symbol_new_hook): New extern. 46823 (NOP_OPCODE): Delete. 46824 (loongarch_pre_output_hook): New macro define. 46825 (md_pre_output_hook): Likewise. 46826 (md_finish): Likewise. 46827 (loongarch_md_finish): New extern. 46828 * testsuite/gas/all/align.d: Mark as unsupported on LoongArch. 46829 * testsuite/gas/all/gas.exp: Xfail loongarch*-*. 46830 * testsuite/gas/all/relax.d: Likewise. 46831 * testsuite/gas/elf/dwarf-5-irp.d: Likewise. 46832 * testsuite/gas/elf/dwarf-5-loc0.d: Likewise. 46833 * testsuite/gas/elf/dwarf-5-macro-include.d: Likewise. 46834 * testsuite/gas/elf/dwarf-5-macro.d: Likewise. 46835 * testsuite/gas/elf/dwarf2-11.d: Likewise. 46836 * testsuite/gas/elf/dwarf2-15.d: Likewise. 46837 * testsuite/gas/elf/dwarf2-16.d: Likewise. 46838 * testsuite/gas/elf/dwarf2-17.d: Likewise. 46839 * testsuite/gas/elf/dwarf2-18.d: Likewise. 46840 * testsuite/gas/elf/dwarf2-19.d: Likewise. 46841 * testsuite/gas/elf/dwarf2-5.d: Likewise. 46842 * testsuite/gas/elf/ehopt0.d: Likewise. 46843 * testsuite/gas/elf/elf.exp: Likewise. 46844 * testsuite/gas/elf/section11.d: Likewise. 46845 * testsuite/gas/lns/lns.exp: Likewise. 46846 * testsuite/gas/loongarch/jmp_op.d: Regenerated. 46847 * testsuite/gas/loongarch/li.d: Likewise. 46848 * testsuite/gas/loongarch/macro_op.d: Likewise. 46849 * testsuite/gas/loongarch/macro_op_32.d: Likewise. 46850 * testsuite/gas/loongarch/macro_op_large_abs.d: Likewise. 46851 * testsuite/gas/loongarch/macro_op_large_pc.d: Likewise. 46852 * testsuite/gas/loongarch/relax_align.d: New test. 46853 * testsuite/gas/loongarch/relax_align.s: New test. 46854 * testsuite/gas/loongarch/uleb128.d: New test. 46855 * testsuite/gas/loongarch/uleb128.s: New test. 46856 468572023-05-30 mengqinggang <mengqinggang@loongson.cn> 46858 46859 LoongArch: binutils: Add support for linker relaxation. 46860 Add support for relocs related to relax to readelf. 46861 46862 binutils/ChangeLog: 46863 46864 * readelf.c (target_specific_reloc_handling): Handle ULEB128 reloc. 46865 (is_32bit_inplace_add_reloc): Handle new reloc. 46866 (is_32bit_inplace_sub_reloc): Likewise. 46867 (is_64bit_inplace_add_reloc): Likewise. 46868 (is_64bit_inplace_sub_reloc): Likewise. 46869 (is_16bit_inplace_add_reloc): Likewise. 46870 (is_16bit_inplace_sub_reloc): Likewise. 46871 (is_8bit_inplace_add_reloc): Likewise. 46872 (is_8bit_inplace_sub_reloc): Likewise. 46873 (is_6bit_inplace_sub_reloc): Likewise. 46874 (is_6bit_inplace_add_reloc): New function. 46875 (apply_relocations): Handle new reloc. 46876 * testsuite/binutils-all/readelf.exp: Add -mno-relax option 46877 for LoongArch. 46878 468792023-05-30 mengqinggang <mengqinggang@loongson.cn> 46880 46881 LoongArch: opcodes: Add support for linker relaxation. 46882 Set gas default to enable relax. 46883 46884 opcodes/ChangeLog: 46885 46886 * loongarch-opc.c (struct loongarch_ASEs_option): New member relax 46887 with the default value 1. 46888 468892023-05-30 mengqinggang <mengqinggang@loongson.cn> 46890 46891 LoongArch: bfd: Add support for linker relaxation. 46892 Add relax support and related relocs in bfd. 46893 46894 bfd/ChangeLog: 46895 46896 * bfd-in2.h: Add relocs related to relax. 46897 * elfnn-loongarch.c (struct loongarch_elf_link_hash_table): New integer 46898 pointer (data_segment_phase) to monitor the data segment phase. 46899 (loongarch_elf_check_relocs): Swap B21/B26 reloc sequence. 46900 (loongarch_elf_adjust_dynamic_symbol): Fix code format. 46901 (loongarch_reloc_rewrite_imm_insn): Fix function call. 46902 (perform_relocation): Handle new relocs related to relax. 46903 (RELOCATE_CALC_PC32_HI20): Fix code format. 46904 (RELOCATE_CALC_PC64_HI32): Likewise. 46905 (loongarch_elf_relocate_section): Handle new relocs related to relax. 46906 (loongarch_relax_delete_bytes): New function. 46907 (loongarch_relax_pcala_addi): Likewise. 46908 (loongarch_relax_pcala_ld): Likewise. 46909 (bfd_elfNN_loongarch_set_data_segment_info): Likewise. 46910 (loongarch_relax_align): Likewise. 46911 (loongarch_elf_relax_section): Likewise. 46912 (bfd_elfNN_bfd_relax_section): New macro define. 46913 * elfxx-loongarch.c (reloc_bits): New bfd point parameter. 46914 (reloc_bits_b16): Likewise. 46915 (reloc_bits_b21): Likewise. 46916 (reloc_bits_b26): Likewise. 46917 (loongarch_adjust_reloc_bitsfield): Likewise. 46918 (reloc_bits_pcrel20_s2): New function. 46919 (loongarch_elf_add_sub_reloc): Likewise. 46920 (loongarch_elf_add_sub_reloc_uleb128): Likewise. 46921 (loongarch_write_unsigned_leb128): New function. 46922 * elfxx-loongarch.h (loongarch_adjust_reloc_bitsfield): New bfd point 46923 parameter. 46924 (bfd_elf32_loongarch_set_data_segment_info): New declare. 46925 (bfd_elf64_loongarch_set_data_segment_info): Likewise. 46926 (loongarch_write_unsigned_leb128): Likewise. 46927 * libbfd.h: Add relocs related to relax. 46928 * reloc.c: Add relocs related to relax. 46929 469302023-05-30 mengqinggang <mengqinggang@loongson.cn> 46931 46932 LoongArch: include: Add support for linker relaxation. 46933 Add relocs and gas LARCH_opts.relax option. 46934 46935 include/ChangeLog: 46936 46937 * elf/loongarch.h: Add relocs. 46938 * opcode/loongarch.h: Add LARCH_opts.relax and macro LARCH_NOP. 46939 469402023-05-30 Nick Clifton <nickc@redhat.com> 46941 46942 Add support for an ARMMAGIC value of 0xa00 to the PE dumper. 46943 469442023-05-30 Alan Modra <amodra@gmail.com> 46945 46946 arm-pe objdump -P 46947 arm-pe looks to be a very old PE implementation, incompatible with 46948 current arm-wince-pe. arm-pe has different relocations and uses 46949 ARMMAGIC which has this comment: "I just made this up". Well, OK, I 46950 don't know the history but it was probably before Microsoft "just made 46951 up" their constants for ARM windows CE. 46952 46953 This patch supports objdump -P for arm-pe, and another magic constant 46954 that may appear in object files. (I don't think binutils generates 46955 files using ARMV7PEMAGIC aka IMAGE_FILE_MACHINE_ARMNT.) 46956 46957 * od-pe.c (is_pe_object_magic): Handle IMAGE_FILE_MACHINE_ARMNT 46958 and ARMMAGIC. 46959 469602023-05-30 Alan Modra <amodra@gmail.com> 46961 46962 Define IMAGE_FILE_MACHINE_ARMNT 46963 Same value as ARMV7PEMAGIC. 46964 https://learn.microsoft.com/en-us/windows/win32/sysinfo/image-file-machine-constants 46965 46966 * coff/pe.h (IMAGE_FILE_MACHINE_ARMNT): Define. 46967 469682023-05-30 Alan Modra <amodra@gmail.com> 46969 46970 Don't define COFF_MAGIC 46971 This macro was unused apart from aout/encap.h, which has been deleted. 46972 46973 * config/tc-arm.h (COFF_MAGIC): Don't define. 46974 * config/tc-sh.h (COFF_MAGIC): Don't define. 46975 * config/tc-z80.h (COFF_MAGIC): Don't define. 46976 * config/tc-z8k.h (COFF_MAGIC): Don't define. 46977 469782023-05-30 Alan Modra <amodra@gmail.com> 46979 46980 Delete include/aout/encap.h 46981 This file is unused and as the header comment says, obsolete. 46982 46983 Regen binutils POTFILES.in 46984 for od-pe.c 46985 469862023-05-30 GDB Administrator <gdbadmin@sourceware.org> 46987 46988 Automatic date update in version.in 46989 469902023-05-29 Tom de Vries <tdevries@suse.de> 46991 46992 [gdb/testsuite] Fix linefeed scrolling in tuiterm 46993 I came across a bug in the implementation of line feed in tuiterm, and added a 46994 unit test that exposes it. 46995 46996 Before sending the line feed we have: 46997 ... 46998 Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 3): 46999 0 abcdefgh 47000 1 ijklmnop 47001 2 qrstuvwx 47002 3 yz01234 47003 ... 47004 and after it we have: 47005 ... 47006 Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 1): 47007 0 ijklmnop 47008 1 qrstuvwx 47009 2 yz01234 47010 3 yz01234 47011 ... 47012 47013 Note how the cursor started at row 3 and after the line feed ended up at 47014 row 1, while it should have stayed in row 3. 47015 47016 Fix this by moving "incr _cur_row -1" one level up in the loop nest in 47017 proc _ctl_0x0a. 47018 47019 Tested on x86_64-linux. 47020 470212023-05-29 Simon Marchi <simon.marchi@efficios.com> 47022 47023 gdb/mi: fix ^running record with multiple MI interpreters 47024 I stumbled on the mi_proceeded and running_result_record_printed 47025 globals, which are shared by all MI interpreter instances (it's unlikely 47026 that people use multiple MI interpreter instances, but it's possible). 47027 After poking at it, I found this bug: 47028 47029 1. Start GDB in MI mode 47030 2. Add a second MI interpreter with the new-ui command 47031 3. Use -exec-run on the second interpreter 47032 47033 This is the output I get on the first interpreter: 47034 47035 =thread-group-added,id="i1" 47036 ~"Reading symbols from a.out...\n" 47037 ~"New UI allocated\n" 47038 (gdb) 47039 =thread-group-started,id="i1",pid="94718" 47040 =thread-created,id="1",group-id="i1" 47041 ^running 47042 *running,thread-id="all" 47043 47044 And this is the output I get on the second intepreter: 47045 47046 =thread-group-added,id="i1" 47047 (gdb) 47048 -exec-run 47049 =thread-group-started,id="i1",pid="94718" 47050 =thread-created,id="1",group-id="i1" 47051 *running,thread-id="all" 47052 47053 The problem here is that the `^running` reply to the -exec-run command 47054 is printed on the wrong UI. It is printed on the first one, it should 47055 be printed on the second (the one on which we sent the -exec-run). 47056 47057 What happens under the hood is that captured_mi_execute_command, while 47058 executing a command for the second intepreter, clears the 47059 running_result_record_printed and mi_proceeded globals. 47060 mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets 47061 called for the first intepreter first. Since the 47062 47063 !running_result_record_printed && mi_proceeded 47064 47065 condition is true, it prints a ^running, and sets 47066 running_result_record_printed. When mi_on_resume_1 gets called for the 47067 second interpreter, running_result_record_printed is already set, so 47068 ^running is not printed there. 47069 47070 It took me a while to understand the relationship between these two 47071 variables. I think that in the end, this is what we want to track: 47072 47073 1. When executing an MI command, take note if that command causes a 47074 "proceed". This is done in mi_about_to_proceed. 47075 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want 47076 to output a ^running record. And we want to remember that we did, 47077 because... 47078 3. Back in captured_mi_execute_command, if we did not output a 47079 ^running, we want to output a ^done. 47080 47081 Moving those two variables to the mi_interp struture appears to fix it. 47082 Only for the interpreter doing the -exec-run command does the 47083 running_result_record_printed flag get cleared, and therefore only or 47084 that one does the ^running record get printed. 47085 47086 Add a new test for this, that does pretty much what the reproducer above 47087 shows. Without the fix, the test fails because 47088 mi_send_resuming_command_raw never sees the ^running record. 47089 47090 Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b 47091 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 47092 470932023-05-29 GDB Administrator <gdbadmin@sourceware.org> 47094 47095 Automatic date update in version.in 47096 470972023-05-28 Tom de Vries <tdevries@suse.de> 47098 47099 [readline] Fix double free in _rl_scxt_dispose 47100 Consider the following scenario. We start gdb in TUI mode: 47101 ... 47102 $ gdb -q -tui 47103 ... 47104 and type ^R which gives us the reverse-isearch prompt in the cmd window: 47105 ... 47106 (reverse-i-search)`': 47107 ... 47108 and then type "foo", right-arrow-key, and ^C. 47109 47110 In TUI mode, gdb uses a custom rl_getc_function tui_getc. 47111 47112 When pressing the right-arrow-key, tui_getc: 47113 - attempts to scroll the TUI src window, without any effect, and 47114 - returns 0. 47115 47116 The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char: 47117 ... 47118 /* We intercepted the control character, so return 0 (which readline 47119 will interpret as a no-op). */ 47120 return 0; 47121 ... 47122 47123 However, after this 0 is returned by the rl_read_key () call in 47124 _rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets 47125 0 as the first part of an utf-8 multibyte char, and tries to read the next 47126 char. 47127 47128 In this state, the ^C takes effect and we run into a double free because 47129 _rl_isearch_cleanup is called twice. 47130 47131 Both these issues need fixing independently, though after fixing the first we 47132 no longer trigger the second. 47133 47134 The first issue is caused by the subtle difference between: 47135 - a char array containing 0 chars, which is zero-terminated, and 47136 - a char array containing 1 char, which is zero. 47137 47138 In mbrtowc terms, this is the difference between: 47139 ... 47140 mbrtowc (&wc, "", 0, &ps); 47141 ... 47142 which returns -2, and: 47143 ... 47144 mbrtowc (&wc, "", 1, &ps); 47145 ... 47146 which returns 0. 47147 47148 Note that _rl_read_mbstring calls _rl_get_char_len without passing it an 47149 explicit length parameter, and consequently it cannot distinguish between the 47150 two, and defaults to the "0 chars" choice. 47151 47152 Note that the same problem doesn't exist in _rl_read_mbchar. 47153 47154 Fix this by defaulting to the "1 char" choice in _rl_get_char_len: 47155 ... 47156 - if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src)) 47157 + if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src)) 47158 ... 47159 47160 The second problem happens when the call to _rl_search_getchar in 47161 _rl_isearch_callback returns. At that point _rl_isearch_cleanup has already 47162 been called from the signal handler, but we proceed regardless, using a cxt 47163 pointer that has been freed. 47164 47165 Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to 47166 _rl_search_getchar: 47167 ... 47168 c = _rl_search_getchar (cxt); 47169 + if (!RL_ISSTATE (RL_STATE_ISEARCH)) 47170 + return 1; 47171 ... 47172 47173 Tested on x86_64-linux. 47174 47175 Approved-By: Chet Ramey <chet.ramey@case.edu> 47176 47177 PR tui/30056 47178 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056 47179 471802023-05-28 GDB Administrator <gdbadmin@sourceware.org> 47181 47182 Automatic date update in version.in 47183 471842023-05-27 Nelson Chu <nelson@nelson.ba.rivosinc.com> 47185 47186 [PR ld/22263][PR ld/25694] RISC-V: Avoid dynamic TLS relocs in PIE. 47187 Lots of targets already fixed the TEXTREL problem for TLS in PIE. 47188 47189 * For PR ld/25694, 47190 In the check_reloc, refer to spare and loongarch, they don't need to reserve 47191 any local dynamic reloc for TLS LE in pie/pde, and similar to other targets. 47192 So it seems like riscv was too conservative to estimate the TLS LE before. 47193 Just break and don't goto static_reloc for TLS LE in pie/pde can fix the 47194 TEXTREL problem. 47195 47196 * For PR ld/22263, 47197 The risc-v code for TLS GD/IE in the relocate_section seems same as MIPS port. 47198 So similar to MIPS, pr22570, commits 9143e72c6d4d and 1cb83cac9a89, it seems 47199 also the right way to do the same thing for risc-v. 47200 47201 On risc-v, fixes 47202 FAIL: Build pr22263-1 47203 47204 RISC-V haven't supported the TLS transitions, so will need the same fix (use 47205 bfd_link_dll) in the future. 47206 47207 bfd/ 47208 PR ld/22263 47209 PR ld/25694 47210 * elfnn-riscv.c (riscv_elf_check_relocs): Replace bfd_link_pic with 47211 bfd_link_dll for TLS IE. Don't need to reserve the local dynamic 47212 relocation for TLS LE in pie/pde, and report error in pic just like 47213 before. 47214 (riscv_elf_relocate_section): For TLS GD/IE, use bfd_link_dll rather 47215 than !bfd_link_pic in determining the dynamic symbol index. Avoid 47216 the index of -1. 47217 472182023-05-27 GDB Administrator <gdbadmin@sourceware.org> 47219 47220 Automatic date update in version.in 47221 472222023-05-26 Nick Clifton <nickc@redhat.com> 47223 47224 Enhance objdump's --private option so that it can display the contents of PE format files. 47225 * od-pe.c: New file: Dumps fields in PE format headers. 47226 * configure.ac (od_vectors): Add objdump_private_desc_pe for PE format targets. (od_files): Add od-pe for PE format targets. 47227 * configure: Regenerate. 47228 * Makefile.am (CFILES): Add od-pe.c (EXTRA_objdump_SOURCE): Likewise. 47229 * Makefile.in: Generate. 47230 * NEWS: Mention the new feature. 47231 * doc/binutils.texi: Document the new support. 47232 * objdump.c (wide_output): Change from local to global. 47233 * objdump.h (wide_output): Prototype. (objdump_private_desc_pe): Prototype. 47234 * testsuite/binutils-all/objdump.exp: Add a test of the new feature. 47235 472362023-05-26 Andreas Schwab <schwab@linux-m68k.org> 47237 47238 Remove duplicate definition 47239 * coff/pe.h (IMAGE_FILE_MACHINE_AMD64): Remove duplicate 47240 definition. Alphabetize. 47241 472422023-05-26 Jan Beulich <jbeulich@suse.com> 47243 47244 x86: fix disassembler build after 1a3b4f90bc5f 47245 In commit 1a3b4f90bc5f ("x86: convert two pointers to (indexing) 47246 integers") I neglected the fact that compilers may warn about comparing 47247 ptrdiff_t (signed long) with size_t (unsigned long) values. Since just 47248 before we've checked that the value is positive, simply add a cast 47249 (despite my dislike for casts). 47250 472512023-05-26 Tom de Vries <tdevries@suse.de> 47252 47253 [gdb/testsuite] Add test-case gdb.tui/color-prompt.exp 47254 Add a test-case that sets a prompt with color in TUI. 47255 47256 The line containing the prompt is shown by get_line_with_attrs as follows: 47257 ... 47258 <fg:31>(gdb) <fg:default> 47259 ... 47260 47261 The 31 means red, but only for foreground colors, for background colors 41 47262 means red. 47263 47264 Make this more readable by using color names for both foreground and 47265 background, such that we have instead: 47266 .... 47267 <fg:red>(gdb) <fg:default> 47268 ... 47269 47270 Tested on x86_64-linux. 47271 472722023-05-26 Tom de Vries <tdevries@suse.de> 47273 47274 [gdb/testsuite] Add invisible and blinking attributes in tuiterm 47275 I noticed curses using the invisible and blinking attributes. 47276 47277 Add these in tuiterm. 47278 47279 Tested on x86_64-linux. 47280 472812023-05-26 Tom de Vries <tdevries@suse.de> 47282 47283 [gdb/testsuite] Fix reverse attribute in tuiterm 47284 I noticed in proc Term::_csi_m arguments that while parameters 7 and 27 are 47285 supposed to set the reverse attribute to 1 and 0, in fact it's set to 1 in 47286 both cases: 47287 ... 47288 7 { 47289 set _attrs(reverse) 1 47290 } 47291 ... 47292 27 { 47293 set _attrs(reverse) 1 47294 } 47295 ... 47296 47297 Fix this and add a regression test in gdb.tui/tuiterm.exp. 47298 47299 Tested on x86_64-linux. 47300 473012023-05-26 Jan Beulich <jbeulich@suse.com> 47302 47303 iamcu: suppress tests which can't possibly work 47304 With neither --32 nor --64 passed to gas, advanced features like AVX 47305 aren't available without explicitly enabling them. 47306 47307 x86-64: improve gas diagnostic when no 32-bit target is configured 47308 Make this similar to --64 and --x32: Check whether a suitable target 47309 exists. 47310 47311 x86-64: conditionalize tests using --32 47312 Using this option doesn't really work when no support for any 32-bit 47313 target was configured in (as is the case for at least cloudabi and 47314 rdos). 47315 47316 x86: split gas testsuite .exp file 47317 The set of 32-bit-only and 64-bit-only tests has grown quite large. In 47318 particular when one's after only the results for the 64-bit set, having 47319 them live in a separate .exp file is easier / faster. 47320 47321 x86: convert two pointers to (indexing) integers 47322 This in particular reduces the number of pointers to non-const that we 47323 have (and that could potentially be used for undue modification of 47324 state). As a result, fetch_code()'s 2nd parameter can then also become 47325 pointer-to-const. 47326 473272023-05-26 Jan Beulich <jbeulich@suse.com> 47328 47329 x86: disassembling over-long insns 47330 The present way of dealing with them - misusing MAX_MNEM_SIZE, which has 47331 nothing to do with insn length - leads to inconsistent results. Since we 47332 allow for up to MAX_CODE_LENGTH - 1 prefix bytes (which then could be 47333 followed by another MAX_CODE_LENGTH "normal" insn bytes until we're done 47334 decoding), size the_buffer[] accordingly. 47335 47336 Move struct dis_private down to be able to use MAX_CODE_LENGTH without 47337 moving its #define. While doing this also alter the order to have the 47338 potentially large array last. 47339 473402023-05-26 Jan Beulich <jbeulich@suse.com> 47341 47342 x86: use fixed-width type for codep and friends 47343 This first of all removes a dependency on bfd_byte and unsigned char 47344 being the same types. It further eliminates the need to mask by 0xff 47345 when fetching values (which wasn't done fully consistently anyway), 47346 improving code legibility. 47347 47348 While there, where possible add const. 47349 473502023-05-26 Jan Beulich <jbeulich@suse.com> 47351 47352 x86: figure braces aren't really part of mnemonics 47353 Instead they're separators for pseudo-prefixes. Don't insert them in 47354 mnemonic_chars[], handling them explicitly in parse_insn() instead. Note 47355 that this eliminates the need for another separator after a pseudo- 47356 prefix. While maybe not overly interesting for a following real 47357 mnemonic, I view this as quite desirable between multiple successive 47358 pseudo-prefixes (bringing things in line with the other use of figure 47359 braces in AVX512's zeroing-masking). 47360 47361 Drop the unused is_mnemonic_char() at this occasion. 47362 473632023-05-26 Jan Beulich <jbeulich@suse.com> 47364 47365 x86: de-duplicate operand_special_chars[] wrt extra_symbol_chars[] 47366 Having to add characters to both arrays can easily lead to oversights. 47367 Consuming extra_symbol_chars[] when populating operand_chars[] also 47368 allows to drop two special cases in md_begin(). 47369 47370 Constify operand_special_chars[] at this occasion. 47371 473722023-05-26 Indu Bhagat <indu.bhagat@oracle.com> 47373 47374 sframe/doc: minor improvements for readability 47375 libsframe/ 47376 * sframe-spec.texi: Cosmetic fixes. 47377 473782023-05-26 Indu Bhagat <indu.bhagat@oracle.com> 47379 47380 libsframe: revisit sframe_find_fre API 47381 Inspite of implementing a rather simple functionality, this function was 47382 relatively difficult to follow, and maintain. Some changes are done now 47383 to address that - refactor the function and use better names to make it 47384 more readable. 47385 47386 The changes to the implementation do not cause any change in the 47387 contract of the API. 47388 47389 libsframe/ 47390 * sframe.c (sframe_fre_get_end_ip_offset): to here... 47391 (sframe_find_fre): Refactor some bits from... 47392 473932023-05-26 Indu Bhagat <indu.bhagat@oracle.com> 47394 47395 libsframe: use const char * consistently for immutable FRE buffers 47396 libsframe/ 47397 * sframe.c (sframe_decode_fre): Use const char * datatype when 47398 handling buffer containing the FREs. 47399 (sframe_fre_get_end_ip_offset): Likewise. 47400 (sframe_find_fre): Likewise. 47401 (sframe_decoder_get_fre): Likewise. 47402 47403 libsframe: use uint8_t data type for FRE info related stubs 47404 libsframe/ 47405 * sframe.c: Use uint8_t for FRE offset count and FRE offset 47406 size. Use uint8_t for FRE info word as well. 47407 474082023-05-26 Alan Modra <amodra@gmail.com> 47409 47410 PR22263 ld test 47411 A number of targets that I test regularly fail the "Build pr22263-1" 47412 test for various reasons. 47413 47414 arm-linux-gnueabi: "undefined reference to `__aeabi_read_tp'" 47415 ia64-linux-gnu: "Explicit stops are ignored in auto mode" 47416 m68k-linux-gnu: "undefined reference to `__m68k_read_tp'" 47417 microblaze-linux-gnu: "undefined reference to `__tls_get_addr'" 47418 nios2-linux-gnu, s390-linux-gnu and sh4-linux-gnu have a tprel reloc in .got 47419 riscv64-linux-gnu has a dynamic relocation in text 47420 47421 So only riscv really fails the pr. The rest fail due to test issues 47422 or lack of a linker optimisation. Lack of an optimisation isn't 47423 really a fail, but it's worth keeping the test to ensure those 47424 optimisations don't regress. The xfail targets may not be an 47425 exhaustive list. This just tidies test results for those for which I 47426 have cross compilers installed. 47427 47428 PR 22263 47429 * testsuite/ld-elf/tls.exp: Split pr22263 test into two parts, 47430 one to check for -z text errors, the other to check tprel 47431 linker optimisation. Supply needed symbols and assembler flags. 47432 xfail the linker optimisation on targets known to fail. 47433 474342023-05-26 Tom Tromey <tom@tromey.com> 47435 47436 Make MI commands const-correct 47437 I've had this patch for a while now and figured I'd update it and send 47438 it. It changes MI commands to use a "const char * const" for their 47439 argv parameter. 47440 47441 Regression tested on x86-64 Fedora 36. 47442 47443 Acked-By: Simon Marchi <simon.marchi@efficios.com> 47444 474452023-05-26 GDB Administrator <gdbadmin@sourceware.org> 47446 47447 Automatic date update in version.in 47448 474492023-05-25 Ciaran Woodward <ciaranwoodward@xmos.com> 47450 47451 Fix scoped_value_mark not working with empty value chain 47452 The scoped_value_mark helper class was setting its internal 47453 mark value to NULL to indicate that the value chain had already 47454 been freed to mark. 47455 47456 However, value_mark() also returns NULL if the value chain is 47457 empty at the time of call. 47458 47459 This lead to the situation that if the value chain was empty 47460 at the time the scoped_value_mark was created, the class 47461 would not correctly clean up the state when it was destroyed, 47462 because it believed it had already been freed. 47463 47464 I noticed this because I was setting a watchpoint very early 47465 in my debug session, and it was becoming a software watchpoint 47466 rather than hardware. Running any command that called evaluate() 47467 beforehand (such as 'x 0') would mean that a hardware watchpoint 47468 was correctly used. After some careful examination of the 47469 differences in execution, I noticed that values were being freed 47470 later in the 'bad case', which lead me to notice the issue with 47471 scoped_value_mark. 47472 474732023-05-25 Simon Marchi <simon.marchi@efficios.com> 47474 47475 gdb: remove breakpoint_pointer_iterator 47476 Remove the breakpoint_pointer_iterator layer. Adjust all users of 47477 all_breakpoints and all_tracepoints to use references instead of 47478 pointers. 47479 47480 Change-Id: I376826f812117cee1e6b199c384a10376973af5d 47481 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47482 474832023-05-25 Simon Marchi <simon.marchi@efficios.com> 47484 47485 gdbsupport: make filtered_iterator::operator* return the same thing as underlying iterator 47486 This is the same idea as the previous patch, but for filtered_iterator. 47487 Without this patch, I would see this when applying the patch that 47488 removes reference_to_pointer_iterator from breakpoint_range: 47489 47490 CXX breakpoint.o 47491 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void download_tracepoint_locations()’: 47492 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:11007:41: error: cannot allocate an object of abstract type ‘breakpoint’ 47493 11007 | for (breakpoint &b : all_tracepoints ()) 47494 | ^ 47495 In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26, 47496 from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21, 47497 from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28, 47498 from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23, 47499 from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21: 47500 /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note: because the following virtual functions are pure within ‘breakpoint’: 47501 619 | struct breakpoint : public intrusive_list_node<breakpoint> 47502 | ^~~~~~~~~~ 47503 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note: ‘virtual breakpoint::~breakpoint()’ 47504 250 | breakpoint::~breakpoint () 47505 | ^~~~~~~~~~ 47506 47507 Change-Id: I05285ff27d21cb0ab80cba392ec4e959167e3cd7 47508 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47509 475102023-05-25 Simon Marchi <simon.marchi@efficios.com> 47511 47512 gdbsupport: make basic_safe_iterator::operator* return the same thing as underlying iterator 47513 Using the following patch that removes the reference_to_pointer_iterator 47514 from breakpoint_range, I would get: 47515 47516 CXX breakpoint.o 47517 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’: 47518 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’ 47519 3030 | for (breakpoint &b : all_breakpoints_safe ()) 47520 | ^ 47521 In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26, 47522 from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21, 47523 from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28, 47524 from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23, 47525 from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21: 47526 /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note: because the following virtual functions are pure within ‘breakpoint’: 47527 619 | struct breakpoint : public intrusive_list_node<breakpoint> 47528 | ^~~~~~~~~~ 47529 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note: ‘virtual breakpoint::~breakpoint()’ 47530 250 | breakpoint::~breakpoint () 47531 | ^~~~~~~~~~ 47532 47533 This is because the operator* method of the basic_safe_iterator iterator 47534 wrapper returns a value_type. So, even if the method of the underlying 47535 iterator (breakpoint_iterator, an intrusive_list iterator) returns a 47536 `breakpoint &`, the method of the wrapper returns a `breakpoint`. 47537 47538 I think it would make sense for iterator wrappers such as 47539 basic_safe_iterator to return the exact same thing as the iterator they 47540 wrap. At least, it fixes my problem. 47541 47542 Change-Id: Ibbcd390ac03d2fb6ae4854923750c8d7c3c04e8a 47543 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47544 475452023-05-25 Simon Marchi <simon.marchi@efficios.com> 47546 47547 gdb: link breakpoints with intrusive_list 47548 Change-Id: I043d8d6f3dd864d80d5088f6ffc2c098337249ea 47549 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47550 475512023-05-25 Simon Marchi <simon.marchi@efficios.com> 47552 47553 gdb: remove bp_location_pointer_iterator 47554 Remove the bp_location_pointer_iterator layer. Adjust all users of 47555 breakpoint::locations to use references instead of pointers. 47556 47557 Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa 47558 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47559 475602023-05-25 Simon Marchi <simon.marchi@efficios.com> 47561 47562 gdb: use intrusive_list for breakpoint locations 47563 Replace the hand-maintained linked lists of breakpoint locations with 47564 and intrusive list. 47565 47566 - Remove breakpoint::loc, add breakpoint::m_locations. 47567 47568 - Add methods for the various manipulations that need to be done on the 47569 location list, while maintaining reasonably good encapsulation. 47570 47571 - bp_location currently has a default constructor because of one use 47572 in hoist_existing_locations. hoist_existing_locations now returns a 47573 bp_location_list, and doesn't need the default-constructor 47574 bp_location anymore, so remove the bp_location default constructor. 47575 47576 - I needed to add a call to clear_locations in delete_breakpoint to 47577 avoid a use-after-free. 47578 47579 - Add a breakpoint::last_loc method, for use in 47580 set_breakpoint_condition. 47581 47582 bp_location_range uses reference_to_pointer_iterator, so that all 47583 existing callers of breakpoint::locations don't need to change right 47584 now. It will be removed in the next patch. 47585 47586 The rest of the changes are to adapt the call sites to use the new 47587 methods, of breakpoint::locations, rather than breakpoint::loc directly. 47588 47589 Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70 47590 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47591 475922023-05-25 Simon Marchi <simon.marchi@efficios.com> 47593 47594 gdbsupport: add missing increment/decrement operators to reference_to_pointer_iterator 47595 Using the following patch, I would get this build failure: 47596 47597 CXX breakpoint.o 47598 In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66, 47599 from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36, 47600 from /usr/include/c++/13.1.1/bits/hashtable.h:35, 47601 from /usr/include/c++/13.1.1/bits/unordered_map.h:33, 47602 from /usr/include/c++/13.1.1/unordered_map:41, 47603 from /usr/include/c++/13.1.1/functional:63, 47604 from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35, 47605 from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206, 47606 from /home/smarchi/src/binutils-gdb/gdb/defs.h:26, 47607 from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20: 47608 /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’: 47609 /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21: required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’ 47610 /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19: required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’ 47611 /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19: required from here 47612 /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’) 47613 179 | --__i; 47614 | ^~~~~ 47615 47616 This points out that while intrusive_list_iterator has an operator--, 47617 the reference_to_pointer_iterator wrapper does not. I'm not to sure why 47618 the compiler chooses the overload of __advance that accepts a 47619 _BidirectionalIterator, given that reference_to_pointer_iterator can't 47620 be decremented, but adding those operators seems like the right thing to 47621 do in any case, for completeness. 47622 47623 Change-Id: I8e2044b6734fadf0f21093047cf35bb7080dbdc3 47624 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47625 476262023-05-25 Simon Marchi <simon.marchi@efficios.com> 47627 47628 gdb: add breakpoint::first_loc methods 47629 Add convenience first_loc methods to struct breakpoint (const and 47630 non-const overloads). A subsequent patch changes the list of locations 47631 to be an intrusive_list and makes the actual list private, so these 47632 spots would need to change from: 47633 47634 b->loc 47635 47636 to something ugly like: 47637 47638 *b->locations ().begin () 47639 47640 That would make the code much heavier and not readable. There is a 47641 surprisingly big number of places that access the first location of 47642 breakpoints. Whether this is correct, or these spots fail to consider 47643 the possibility of multi-location breakpoints, I don't know. But 47644 anyhow, I think that using this instead: 47645 47646 b->first_loc () 47647 47648 conveys the intention better than the other two forms. 47649 47650 Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95 47651 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47652 476532023-05-25 Simon Marchi <simon.marchi@efficios.com> 47654 47655 gdb: add breakpoint "has locations" methods 47656 Add three convenience methods to struct breakpoint: 47657 47658 - has_locations: returns true if the breakpoint has at least one 47659 location 47660 - has_single_location: returns true if the breakpoint has exactly one 47661 location 47662 - has_multiple_locations: returns true if the breakpoint has more than 47663 one location 47664 47665 A subsequent patch changes the list of breakpoints to be an 47666 intrusive_list, so all these spots would need to change. But in any 47667 case, I think that this: 47668 47669 if (b->has_multiple_locations ()) 47670 47671 conveys the intention better than: 47672 47673 if (b->loc != nullptr && b->loc->next != nullptr) 47674 47675 Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747 47676 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47677 476782023-05-25 Simon Marchi <simon.marchi@efficios.com> 47679 47680 gdb: constify breakpoint::print_it parameter 47681 The print_it method itself is const. In a subsequent patch, the 47682 locations that come out of a const breakpoint will be const as well. It 47683 will therefore be needed to make the last_loc output parameter const as 47684 well. Make that change now to reduce the size of the following patches. 47685 47686 Change-Id: I7ed962950bc9582646e31e2e42beca2a1c9c5105 47687 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47688 476892023-05-25 Simon Marchi <simon.marchi@efficios.com> 47690 47691 gdb: make some breakpoint methods use `this` 47692 Some implementations of breakpoint::check_status and 47693 breakpoint::print_it do this: 47694 47695 struct breakpoint *b = bs->breakpoint_at; 47696 47697 bs->breakpoint_at is always the same as `this` (we can get convinced by 47698 looking at the call sites of check_status and print_it), so it would 47699 just be clearer to access fields through `this` instead. 47700 47701 Change-Id: Ic542a64fcd88e31ae2aad6feff1da278c7086891 47702 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 47703 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47704 477052023-05-25 Simon Marchi <simon.marchi@efficios.com> 47706 47707 gdb: get gdbarch from syscall_catchpoint instead of location 47708 I noticed some methods of syscall_catchpoint doing this: 47709 47710 struct gdbarch *gdbarch = loc->owner->gdbarch; 47711 47712 `loc` is the list of locations of this catchpoint. Logically, the owner 47713 the locations are this catchpoint. So this just ends up getting 47714 this->gdbarch. Remove the unnecessary indirection through the loc. 47715 47716 syscall_catchpoint::print_recreate does something slightly different, 47717 getting its arch from the loc: 47718 47719 struct gdbarch *gdbarch = loc->gdbarch; 47720 47721 I suppose it's always going to be the same arch, so get it from the 47722 catchpoint there too. 47723 47724 Change-Id: I6f6a6f8e0cd7cfb754cecfb6249e71ec12ba4855 47725 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 47726 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47727 477282023-05-25 Alan Modra <amodra@gmail.com> 47729 47730 PR29189, dlltool delaylibs corrupt float/double arguments 47731 PR 29189 47732 * dlltool.c (i386_x64_trampoline): Save and restore xmm0-5. Make 47733 use of parameter save area for integer arg regs. Comment. 47734 477352023-05-25 GDB Administrator <gdbadmin@sourceware.org> 47736 47737 Automatic date update in version.in 47738 477392023-05-24 Simon Marchi <simon.marchi@efficios.com> 47740 47741 gdbsupport: add support for references to checked_static_cast 47742 Add a checked_static_cast overload that works with references. A bad 47743 dynamic cast with references throws std::bad_cast, it would be possible 47744 to implement the new overload based on that, but it seemed simpler to 47745 just piggy back off the existing function. 47746 47747 I found some potential uses of this new overload in amd-dbgapi-target.c, 47748 update them to illustrate the use of the new overload. To build 47749 amd-dbgapi-target.c, on needs the amd-dbgapi library, which I don't 47750 expect many people to have. But I have it, and it builds fine here. I 47751 did test the new overload by making a purposely bad cast and it did 47752 catch it. 47753 47754 Change-Id: Id6b6a7db09fe3b4aa43cddb60575ff5f46761e96 47755 Reviewed-By: Lancelot SIX <lsix@lancelotsix.com> 47756 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47757 477582023-05-24 Andrew Burgess <aburgess@redhat.com> 47759 47760 gdb/testsuite: fix race in gdb.server/multi-ui-errors.exp 47761 After this commit: 47762 47763 commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd 47764 Date: Thu Mar 9 10:45:03 2023 +0100 47765 47766 [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target 47767 47768 I noticed the occasional failure in gdb.server/multi-ui-errors.exp, 47769 which looked like this: 47770 47771 (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI 47772 interrupt 47773 (gdb) 47774 Program received signal SIGINT, Interrupt. 47775 0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6 47776 FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout) 47777 PASS: gdb.server/multi-ui-errors.exp: interrupt arrived 47778 p server_pid 47779 $1 = 718174 47780 (gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid 47781 47782 This is triggered by this code in gdb.server/multi-ui-errors.exp: 47783 47784 gdb_test "interrupt" 47785 47786 gdb_test_multiple "" "interrupt arrived" { 47787 -re "Program received signal SIGINT, Interrupt\\.\r\n" { 47788 pass $gdb_test_name 47789 } 47790 } 47791 47792 The problem here is that the first interrupt will trigger the prompt 47793 to be printed, and then, after some time the inferior will be 47794 interrupted. 47795 47796 However the default pattern for gdb_test includes a '$' end anchor. 47797 If expect sees the prompt with nothing following it then everything is 47798 fine, and the test passes. 47799 47800 However, if the interrupt is quick and so what expect sees is this: 47801 47802 (gdb) 47803 Program received signal SIGINT, Interrupt. 47804 0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6 47805 47806 In this case the end anchor means that the gdb_test fails to match, 47807 and eventually times out. 47808 47809 Fix this by passing -no-prompt-anchor to gdb_test. 47810 47811 Reviewed-By: Tom de Vries <tdevries@suse.de> 47812 478132023-05-24 Matti Puputti <matti.puputti@intel.com> 47814 47815 gdb, infcmd: Support jump command with same line in multiple symtabs 47816 If a header file defining a static function is included in multiple source 47817 files, each calling the function, and GDB is asked to jump to a line inside 47818 that function, there would be multiple locations matching the target. The 47819 solution in this commit is to select the location in the current symtab. 47820 47821 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 47822 Approved-By: Andrew Burgess <aburgess@redhat.com> 47823 478242023-05-24 Tom Tromey <tromey@adacore.com> 47825 47826 Add "args" and "env" parameters to DAP launch request 47827 This patch augments the DAP launch request with some optional new 47828 parameters that let the client control the command-line arguments and 47829 the environment of the inferior. 47830 47831 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 47832 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 47833 478342023-05-24 Tom Tromey <tromey@adacore.com> 47835 47836 Add attributes and methods to gdb.Inferior 47837 This adds two new attributes and three new methods to gdb.Inferior. 47838 47839 The attributes let Python code see the command-line arguments and the 47840 name of "main". Argument setting is also supported. 47841 47842 The methods let Python code manipulate the inferior's environment 47843 variables. 47844 47845 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 47846 478472023-05-24 Andreas Schwab <schwab@suse.de> 47848 47849 Remove accidentally added file 47850 478512023-05-24 Alan Modra <amodra@gmail.com> 47852 47853 Don't optimise bfd_seek to same position 47854 It's not worth avoiding an fseek to the same position, and can cause 47855 problems if the linker's output file (which is opened "w+") is read, 47856 because that can result in writing, reading, then writing again. 47857 47858 POSIX.1-2017 (IEEE Std 1003.1) says of fopen: 47859 "When a file is opened with update mode ('+' as the second or third 47860 character in the mode argument), both input and output may be 47861 performed on the associated stream. However, the application shall 47862 ensure that output is not directly followed by input without an 47863 intervening call to fflush() or to a file positioning function 47864 (fseek(), fsetpos(), or rewind()), and input is not directly followed 47865 by output without an intervening call to a file positioning function, 47866 unless the input operation encounters end-of-file." 47867 47868 * bfdio.c (bfd_seek): Always call iovec->bseek. 47869 478702023-05-24 GDB Administrator <gdbadmin@sourceware.org> 47871 47872 Automatic date update in version.in 47873 478742023-05-23 Tom Tromey <tromey@adacore.com> 47875 47876 Handle DAP evaluate request without a frame ID 47877 DAP specifies that if an evaluate request does not have a frameID 47878 parameter, then the expression is evaluated in the global scope. 47879 478802023-05-23 Tom Tromey <tromey@adacore.com> 47881 47882 Add global_context parameter to gdb.parse_and_eval 47883 This adds a 'global_context' parse_and_eval to gdb.parse_and_eval. 47884 This lets users request a parse that is done at "global scope". 47885 47886 I considered letting callers pass in a block instead, with None 47887 meaning "global" -- but then there didn't seem to be a clean way to 47888 express the default for this parameter. 47889 47890 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 47891 478922023-05-23 Tom Tromey <tromey@adacore.com> 47893 47894 Add flags to parse_and_eval 47895 This adds a flags parameter to parse_and_eval. 47896 47897 Add PARSER_LEAVE_BLOCK_ALONE flag 47898 This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API 47899 to respect it. This flag lets callers avoid any change to the 47900 passed-in block and expression PC, letting them specify the context 47901 exactly. In particular, now nullptr can be used to indicate that the 47902 parse should not examine any local variables. 47903 47904 Add PARSER_DEBUG flag 47905 This adds a new PARSER_DEBUG constant and changes the parser code to 47906 use it. This lets us make the 'parser_debug' global 'static'. 47907 47908 Rearrange parser_state 47909 This patch mildly rearranges parser_state, moving all the bool fields 47910 together. 47911 47912 Boolify parser_state::comma_terminates 47913 parser_state::comma_terminates ought to be boolean, and changing it 47914 does not require any other changes. 47915 47916 Simplify parser_state constructor 47917 This simplifies the parser_state constructor by having it accept a 47918 parser_flags parameter. 47919 47920 Introduce and use parser flags 47921 This patch adds a new parser_flags type and changes the parser APIs to 47922 use it rather than a collection of 'int' and 'bool'. More flags will 47923 be added in subsquent patches. 47924 47925 Move innermost_block_tracker to expression.h 47926 I think parser-defs.h should hold declarations that can be used by 47927 parser implementations, whereas expression.h should hold declarations 47928 that are used by code that wants to call a parser. Following this 47929 logic, this patch moves innermost_block_tracker to expression.h. 47930 47931 Avoid forward declaration in parse.c 47932 This minorly rearranges parse.c to avoid the need for a forward 47933 declaration. 47934 47935 Implement DAP loadedSources request 47936 This implements the DAP loadedSources request, using gdb.execute_mi to 47937 avoid having to write another custom Python API. 47938 479392023-05-23 Tom Tromey <tromey@adacore.com> 47940 47941 Implement gdb.execute_mi 47942 This adds a new Python function, gdb.execute_mi, that can be used to 47943 invoke an MI command but get the output as a Python object, rather 47944 than a string. This is done by implementing a new ui_out subclass 47945 that builds a Python object. 47946 47947 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688 47948 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 47949 479502023-05-23 Tom Tromey <tromey@adacore.com> 47951 47952 Add second mi_parse constructor 47953 This adds a second mi_parse constructor. This constructor takes a 47954 command name and vector of arguments, and does not do any escape 47955 processing. This also changes mi_parse::args to handle parse objects 47956 created this new way. 47957 47958 Introduce mi_parse helper methods 47959 This introduces some helper methods for mi_parse that handle some of 47960 the details of parsing. This approach lets us reuse them later. 47961 47962 Introduce "static constructor" for mi_parse 47963 Change the mi_parse function to be a static method of mi_parse. This 47964 lets us remove the 'set_args' setter function. 47965 47966 Change mi_parse_argv to a method 47967 This changes mi_parse_argv to be a method of mi_parse. This is just a 47968 minor cleanup. 47969 47970 Use accessor for mi_parse::args 47971 This changes mi_parse::args to be a private member, retrieved via 47972 accessor. It also changes this member to be a std::string. This 47973 makes it simpler for a subsequent patch to implement different 47974 behavior for argument parsing. 47975 47976 Use member initializers in mi_parse 47977 This changes mi_parse to use member initializers rather than a 47978 constructor. This is easier to follow. 47979 47980 Use field_signed from Python MI commands 47981 If an MI command written in Python includes a number in its output, 47982 currently that is simply emitted as a string. However, it's 47983 convenient for a later patch if these are emitted using field_signed. 47984 This does not make a difference to ordinary MI clients. 47985 479862023-05-23 Aaron Merey <amerey@redhat.com> 47987 47988 gdb/cli-out.c: clear_current_line shouldn't trigger pagination prompt 47989 clear_current_line overwrites the current line with chars_per_line 47990 blank spaces. Printing the final space triggers a condition in 47991 pager_file::puts that causes lines_printed to be incremented. If 47992 lines_printed becomes greater than or equal to lines_allowed, the 47993 pagination prompt will appear if enabled. 47994 47995 In this case the prompt is unnecessary since after printing the final 47996 space clear_current_line immediately moves the cursor to the beginning 47997 of the line with '\r'. A new line isn't actually started, so the prompt 47998 ends up being spurious. 47999 48000 Additionally it's possible for gdb to crash during this pagination prompt. 48001 Answering the prompt with 'q' throws an exception intended to bring gdb 48002 back to the main event loop. But since commit 0fea10f32746, 48003 clear_current_line may be called under the progress_update destructor. 48004 The exception will try to propagate through the destructor, causing an abort. 48005 48006 To fix this, pagination is disabled for the duration for clear_current_line. 48007 clear_current_line is also renamed to clear_progress_notify to help 48008 indicate that it is a special purpose function intended for use with 48009 do_progress_notify. 48010 48011 Acked-by: Eli Zaretskii <eliz@gnu.org> 48012 480132023-05-23 Michael Matz <matz@suse.de> 48014 48015 PR30437 aarch64: make RELA relocs idempotent 48016 normally RELA relocs in BFD should not consider the contents of the 48017 relocated place. The aarch64 psABI is even stricter, it specifies 48018 (section 5.7.16) that all RELA relocs _must_ be idempotent. 48019 48020 Since the inception of the aarch64 BFD backend all the relocs have a 48021 non-zero src_mask, and hence break this invariant. It's normally not 48022 a very visible problem as one can see it only when the relocated place 48023 already contains a non-zero value, which usually only happens sometimes 48024 when using 'ld -r' (or as in the testcase when jumping through hoops to 48025 generate the relocations). Or with alternative toolchains that do encode 48026 stuff in the relocated places with the assumption that a relocation 48027 to that place ignores whatever is there (as they can according to 48028 the psABI). 48029 48030 Golang is such a toolchain and https://github.com/golang/go/issues/39927 48031 is ultimately caused by this problem: the testcase testGCData failing 48032 is caused by the garbage collection data-structure to describe a type 48033 containing pointers to be wrong. It's wrong because a field that's 48034 supposed to contain a file-relative offset (to some gcbits) has a 48035 relocation applied and that relocation has an addend which also is 48036 already part of the go-produced object file (so the addend is 48037 implicitely applied twice). 48038 48039 bfd/ 48040 PR ld/30437 48041 * elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask 48042 if all relocation descriptors. 48043 48044 ld/ 48045 * testsuite/ld-aarch64/rela-idempotent.s: New testcase. 48046 * testsuite/ld-aarch64/rela-idempotent.d: New. 48047 * testsuite/ld-aarch64/aarch64-elf.exp: Run it. 48048 480492023-05-23 Nick Clifton <nickc@redhat.com> 48050 48051 Updated Swedish translation for the opcodes directory 48052 480532023-05-23 Bruno Larsen <blarsen@redhat.com> 48054 48055 gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.exp 48056 When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64 48057 machine, the compiled test case would segfault when returning from 48058 the function can_relocate_call, with a suggestion of a broken stack. 48059 The example assembly in the commment was the following: 48060 48061 f: 48062 MOV $1, %[ok] 48063 JMP end 48064 set_point0: 48065 CALL f ; tracepoint here. 48066 end: 48067 48068 And the segmentation fault happening at the final "ret" instruction of 48069 can_relocate_call. Looking at the disassembled version of the later 48070 half of the important function, we see: 48071 48072 Clang version (f starting at 11a4): 48073 00000000000011ae <set_point0>: 48074 11ae: e8 f1 ff ff ff callq 11a4 <can_relocate_call+0x14> 48075 11b3: 89 45 fc mov %eax,-0x4(%rbp) 48076 11b6: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 48077 11ba: 0f 85 0a 00 00 00 jne 11ca <set_point0+0x1c> 48078 11c0: e8 5b 00 00 00 callq 1220 <pass> 48079 11c5: e9 05 00 00 00 jmpq 11cf <set_point0+0x21> 48080 11ca: e8 61 00 00 00 callq 1230 <fail> 48081 11cf: 48 83 c4 10 add $0x10,%rsp 48082 11d3: 5d pop %rbp 48083 11d4: c3 retq 48084 11d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) 48085 11dc: 00 00 00 00 48086 48087 gcc version (f starting at 401125): 48088 000000000040112c <set_point0>: 48089 40112c: e8 f4 ff ff ff callq 401125 <can_relocate_call+0x11> 48090 401131: 89 45 fc mov %eax,-0x4(%rbp) 48091 401134: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 48092 401138: 75 07 jne 401141 <set_point0+0x15> 48093 40113a: e8 c7 ff ff ff callq 401106 <pass> 48094 40113f: eb 05 jmp 401146 <set_point0+0x1a> 48095 401141: e8 c7 ff ff ff callq 40110d <fail> 48096 401146: 90 nop 48097 401147: c9 leaveq 48098 401148: c3 retq 48099 48100 The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main 48101 difference: GCC's version uses the leaveq instruction, which resets rsp 48102 based on rbp, while clang adds the same constant to rsp that it 48103 subtracted in the prologue. Clang fails because the return address that 48104 is added by the "call f" instruction isn't accounted for. 48105 48106 This commit fixes that by adding a return instruction to f, which leaves 48107 the rsp as the compilers would expect. 48108 48109 Approved-By: Andrew Burgess <aburgess@redhat.com> 48110 481112023-05-23 Jan Beulich <jbeulich@suse.com> 48112 48113 x86/Intel: address quoted-symbol related FIXMEs 48114 If in a "word ptr <address>" or alike construct the "ptr" part is 48115 double-quoted, it shouldn't be recognized as the specific keyword we're 48116 looking for (just like we don't recognize double-quoted operator or 48117 register names anymore). Be careful though to tell closing from opening 48118 double-quotes, as a quoted symbol may follow right afterwards. 48119 481202023-05-23 Jan Beulich <jbeulich@suse.com> 48121 48122 x86: don't recognize quoted symbol names as registers or operators 48123 The concept of quoted symbols names was introduced pretty late. Utilize 48124 it to allow access to symbols with names matching that of a register (or, 48125 in Intel syntax, also an identifier-like operator). 48126 48127 This is primarily to aid gcc when generating Intel syntax output; see 48128 their bug target/53929. 48129 481302023-05-23 Zhang, Jun <jun.zhang@intel.com> 48131 48132 Support Intel FRED LKGS 48133 gas/ChangeLog: 48134 48135 * NEWS: Support Intel FRED LKGS. 48136 * config/tc-i386.c: Add fred lkgs 48137 * doc/c-i386.texi: Document .fred, .lkgs. 48138 * testsuite/gas/i386/i386.exp: Add FRED LKGS tests 48139 * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. 48140 * testsuite/gas/i386/x86-64-fred.d: Ditto. 48141 * testsuite/gas/i386/x86-64-fred.s: Ditto. 48142 * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. 48143 * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. 48144 * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. 48145 * testsuite/gas/i386/x86-64-lkgs.d: Ditto. 48146 * testsuite/gas/i386/x86-64-lkgs.s: Ditto. 48147 48148 opcodes/ChangeLog: 48149 48150 * i386-dis.c: New entry for fred, lkgs. 48151 * i386-gen.c: Add CPU_FRED CPU_LKGS. 48152 * i386-init.h : Regenerated. 48153 * i386-mnem.h : Regenerated. 48154 * i386-opc.h: Add fred, lkgs. 48155 * i386-opc.tbl: Add FRED, LKGS instructions. 48156 * i386-tbl.h: Regenerated. 48157 481582023-05-23 liuhongt <hongtao.liu@intel.com> 48159 48160 Revert "Support Intel FRED LKGS" 48161 This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478. 48162 481632023-05-23 Zhang, Jun <jun.zhang@intel.com> 48164 48165 Support Intel FRED LKGS 48166 gas/ChangeLog: 48167 48168 * NEWS: Support Intel FRED LKGS. 48169 * config/tc-i386.c: Add fred lkgs 48170 * doc/c-i386.texi: Document .fred, .lkgs. 48171 * testsuite/gas/i386/i386.exp: Add FRED LKGS tests 48172 * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. 48173 * testsuite/gas/i386/x86-64-fred.d: Ditto. 48174 * testsuite/gas/i386/x86-64-fred.s: Ditto. 48175 * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. 48176 * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. 48177 * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. 48178 * testsuite/gas/i386/x86-64-lkgs.d: Ditto. 48179 * testsuite/gas/i386/x86-64-lkgs.s: Ditto. 48180 48181 opcodes/ChangeLog: 48182 48183 * i386-dis.c: New entry for fred, lkgs. 48184 * i386-gen.c: Add CPU_FRED CPU_LKGS. 48185 * i386-init.h : Regenerated. 48186 * i386-mnem.h : Regenerated. 48187 * i386-opc.h: Add fred, lkgs. 48188 * i386-opc.tbl: Add FRED, LKGS instructions. 48189 * i386-tbl.h: Regenerated. 48190 481912023-05-23 GDB Administrator <gdbadmin@sourceware.org> 48192 48193 Automatic date update in version.in 48194 481952023-05-22 Tom de Vries <tdevries@suse.de> 48196 48197 [gdb/tui] Fix buglet in tui_update_variables 48198 I noticed a buglet in tui_update_variables: 48199 ... 48200 entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner); 48201 if (tui_border_lrcorner != (chtype) entry->value) 48202 { 48203 tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value; 48204 ... 48205 48206 When assigning the new value to tui_border_lrcorner, an entry->value of -1 is 48207 taken into account, but not when comparing to the current value of 48208 tui_border_lrcorner. 48209 48210 Fix this by introducing: 48211 ... 48212 int val = (entry->value < 0) ? ACS_LRCORNER : entry->value; 48213 ... 48214 and using this in both comparison and assignment. 48215 48216 Tested on x86_64-linux. 48217 482182023-05-22 Tom Tromey <tromey@adacore.com> 48219 48220 Remove some FIXME comments from DAP 48221 I recently added a 'dap' component to bugzilla, and I filed a few bugs 48222 there. This patch removes the corresponding FIXME comments. 48223 48224 A few such comments still exist. In at least one case, I have a fix 48225 I'll be submitting eventually; in others I think I need to do a bit of 48226 investigation to properly file a bug report. 48227 482282023-05-22 Richard Bunt <richard.bunt@linaro.org> 48229 48230 gdb: add Richard Bunt to gdb/MAINTAINERS 48231 482322023-05-22 Tom de Vries <tdevries@suse.de> 48233 48234 [gdb/testsuite] Add Term::get_line_with_attrs 48235 Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that 48236 annotates a tuiterm line with the active attributes. 48237 48238 For instance, the line representing the TUI status window with attribute mode 48239 standout looks like this with Term::get_line: 48240 ... 48241 exec No process In: ... L?? PC: ?? 48242 ... 48243 but like this with Term::get_line_with_attrs: 48244 ... 48245 <reverse:1>exec No process In: ... L?? PC: ?? <reverse:0> 48246 ... 48247 48248 Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses 48249 Term::get_line_with_attrs instead of Term::get_line. 48250 48251 Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) 48252 on x86_64-linux. 48253 482542023-05-22 Tom de Vries <tdevries@suse.de> 48255 48256 [gdb/testsuite] Factor out Term::_reset_attrs 48257 Factor out new proc Term::_reset_attrs. 48258 48259 Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) 48260 on x86_64-linux. 48261 482622023-05-22 Alan Modra <amodra@gmail.com> 48263 48264 Re: readelf: Support SHT_RELR/DT_RELR for -r 48265 Revert value of DT_ENCODING to as it was before commit a7fd118627, and 48266 adjust readelf. 48267 48268 include/ 48269 * elf/common.h (DT_ENCODING): Set back to 32. 48270 binutils/ 48271 * readelf.c (struct filedata): Don't size dynamic_info array 48272 using DT_ENCODING. 48273 482742023-05-22 Alan Modra <amodra@gmail.com> 48275 48276 PowerPC64 report number of stub iterations 48277 As a developer it is sometimes useful to know how many times stubs 48278 have been resized. Report the count for users too, in ld --stats. 48279 482802023-05-22 GDB Administrator <gdbadmin@sourceware.org> 48281 48282 Automatic date update in version.in 48283 482842023-05-21 GDB Administrator <gdbadmin@sourceware.org> 48285 48286 Automatic date update in version.in 48287 482882023-05-20 Alan Modra <amodra@gmail.com> 48289 48290 Re: Bug 23686, two segment faults in nm 48291 The fix for pr23686 had a hole in the reloc address sanity check, 48292 the calculation could overflow. Note that stabsize is known to be a 48293 non-zero multiple of 12 so stabsize - 4 can't underflow. 48294 48295 PR 23686 48296 * syms.c (_bfd_stab_section_find_nearest_line): Correct 48297 r->address sanity check. 48298 482992023-05-20 Alan Modra <amodra@gmail.com> 48300 48301 coffcode.h handle_COMDAT tidy 48302 I started down the path of attempting to fix 48303 https://sourceware.org/pipermail/binutils/2023-April/127263.html but 48304 decided after a while that I didn't want to mess with this code.. 48305 48306 This patch is a just a few things that I thought worth doing, the main 48307 one being reporting of errors up the call chain. The while loop to 48308 for loop change is shamelessly stolen from Oleg. 48309 48310 * coffcode.h (handle_COMDAT): Return bool. Make sec_flags a 48311 flagword*, and adjust to suit. Replace while loop with for 48312 loop. Check isym.n_numaux before reading aux entries. Alloc 48313 coff_comdat_info and name in one call to bfd_alloc. Remove 48314 goto breakloop. 48315 (styp_to_sec_flags): Adjust handle_COMDAT call. 48316 483172023-05-20 Alan Modra <amodra@gmail.com> 48318 48319 tic54x set_arch_mach 48320 The tic54x backend provides its own coff_set_arch_mach, but wants to 48321 use the standard coff_set_section_contents. BFD_JUMP_TABLE_WRITE 48322 defines both of these functions, so the code also provides a wrapper 48323 for coff_set_section_contents. This is all quite OK, but I was on a 48324 mission to remove unnecessary declarations in coffcode.h, and on 48325 deleting the one for coff_set_arch_mach ran into a warning about the 48326 function being unused. I could have kept that declaration with its 48327 ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the 48328 definition but the latter is not usual and looks odd to me. So I 48329 had a closer look at tic54x_set_arch_mach and decided the function is 48330 very likely wrong to allow bfd_arch_unknown. Thus the backend should 48331 be using the standard coff_set_arch_mach. 48332 48333 * coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs. 48334 (tic54x_coff_set_arch_mach): Delete. 48335 (tic54x_set_section_contents): Delete. 48336 * coffcode.h: Delete unnecessary forward declarations. 48337 483382023-05-20 GDB Administrator <gdbadmin@sourceware.org> 48339 48340 Automatic date update in version.in 48341 483422023-05-19 Tom Tromey <tromey@adacore.com> 48343 48344 Update documentation for Python Frame.older and Frame.newer 48345 I noticed that Frame.older and Frame.newer don't document that they 48346 return None at the ends of the stack. This patch updates the 48347 documentation, and also fixes a somewhat related typo in a comment 48348 that I noticed while digging into this. 48349 48350 Approved-By: Eli Zaretskii <eliz@gnu.org> 48351 483522023-05-19 Jan Beulich <jbeulich@suse.com> 48353 48354 ld: drop stray blank from ld.texi 48355 At least older makeinfo complains about it. Also fix an apparent typo 48356 while touching that line. 48357 483582023-05-19 Jan Vrany <jan.vrany@labware.com> 48359 48360 gdb: fix post-hook execution for remote targets 48361 Commit b5661ff2 ("gdb: fix possible use-after-free when 48362 executing commands") attempted to fix possible use-after-free 48363 in case command redefines itself. 48364 48365 Commit 37e5833d ("gdb: fix command lookup in execute_command ()") 48366 updated the previous fix to handle subcommands as well by using the 48367 original command string to lookup the command again after its execution. 48368 48369 This fixed the test in gdb.base/define.exp but it turned out that it 48370 does not work (at least) for "target remote" and "target extended-remote". 48371 48372 The problem is that the command buffer P passed to execute_command () 48373 gets overwritten in dont_repeat () while executing "target remote" 48374 command itself: 48375 48376 #0 dont_repeat () at top.c:822 48377 #1 0x000055555730982a in target_preopen (from_tty=1) at target.c:2483 48378 #2 0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0) 48379 at remote.c:5946 48380 #3 0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272 48381 #4 0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490) 48382 at target.c:853 48383 #5 0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1) 48384 at cli/cli-decode.c:2737 48385 #6 0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688 48386 48387 Therefore the second call to lookup_cmd () at line 697 fails to find 48388 command because the original command string is gone. 48389 48390 This commit addresses this particular problem by creating a *copy* of 48391 original command string for the sole purpose of using it after command 48392 execution to lookup the command again. It may not be the most efficient 48393 way but it's safer given that command buffer is shared and overwritten 48394 in hard-to-foresee situations. 48395 48396 Tested on x86_64-linux. 48397 48398 PR 30249 48399 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249 48400 48401 Approved-By: Tom Tromey <tom@tromey.com> 48402 484032023-05-19 Richard Bunt <richard.bunt@linaro.org> 48404 48405 gdb: Remove redundant frame switching 48406 547ce8f00b fixed an issue where dynamic types were not being resolved 48407 correctly prior to printing a value. The same issue was discovered when 48408 printing the value using mi-mode, which was not covered by the fix. 48409 Porting the fix to the mi-mode code path resolved the issue. 48410 48411 However, it was discovered that a later patch series, ending 48412 2fc3b8a4cb8, independently fixed the issue in both the cli- and mi-mode 48413 code paths, making the original fix unneeded. 48414 48415 This commit removes this extra frame switch and adds test coverage for 48416 the mi-mode scenario to protect against any future divergence in this 48417 area. 48418 48419 GDB built with GCC 11. 48420 48421 No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1, 48422 Intel 22.1; Platforms: x86_64, aarch64. 48423 48424 Approved-By: Tom Tromey <tom@tromey.com> 48425 484262023-05-19 Andrew Burgess <aburgess@redhat.com> 48427 48428 gdb: safety checks in skip_prologue_using_sal 48429 While working on the previous patch I reverted this commit: 48430 48431 commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff 48432 Date: Tue Nov 28 16:23:32 2006 +0000 48433 48434 * symtab.c (find_pc_sect_line): Do not return a line before 48435 the start of a symtab. 48436 48437 When I re-ran the testsuite I saw some GDB crashes in the tests: 48438 48439 gdb.dwarf2/dw2-line-number-zero.exp 48440 gdb.dwarf2/dw2-lines.exp 48441 gdb.dwarf2/dw2-vendor-extended-opcode.exp 48442 48443 GDB was reading beyond the end of an array in the function 48444 skip_prologue_using_sal. 48445 48446 Now, without the above commit reverted I don't believe that this 48447 should ever happen. Reverting the above commit effectively breaks 48448 GDB's symtab_and_line lookup, we try to find a result for an address, 48449 and return the wrong symtab and line-table. In 48450 skip_prologue_using_sal we then walk the line table looking for an 48451 appropriate entry, except we never find one, and GDB just keeps going, 48452 wandering off the end of the array. 48453 48454 However, I think adding extra protection to prevent walking off the 48455 end of the array is pretty cheap, and if something does go wrong in 48456 the future then this should prevent a random crash. 48457 48458 Obviously, I have no reproducer for this, as I said, I don't think 48459 this should impact GDB at all, this is just adding a little extra 48460 caution. 48461 48462 Reviewed-By: Tom Tromey <tom@tromey.com> 48463 484642023-05-19 Andrew Burgess <aburgess@redhat.com> 48465 48466 gdb/testsuite: test for a function with no line table 48467 This commit adds a test for the following commit: 48468 48469 commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff 48470 Date: Tue Nov 28 16:23:32 2006 +0000 48471 48472 * symtab.c (find_pc_sect_line): Do not return a line before 48473 the start of a symtab. 48474 48475 We have been carrying a test for that commit in the Fedora GDB tree 48476 since that commit was added to GDB. I don't know why the test wasn't 48477 added along with the original commit, but as was written, the test is 48478 pretty gross, it uses objcopy to pull the .text section from an object 48479 file, which was then injected into another source file within a .asm 48480 statement... 48481 48482 ... these days we can just make use of the DWARF assembler to achieve 48483 the same results, so I've rewritten the test and think it is worth 48484 adding this to upstream GDB. 48485 48486 The original patch was about about how we find the best symtab and 48487 line table entry, and what to do when GDB can't find a good match. 48488 48489 The new test creates a CU with two functions, only one of which is 48490 covered by the line table. With the above patch reverted GDB returns 48491 an invalid address. 48492 48493 With the above patch reverted I did run the testsuite to see what 48494 other tests might already be exercising this functionality, and I 48495 found two tests: 48496 48497 gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp 48498 gdb.dwarf2/dw2-vendor-extended-opcode.exp 48499 48500 These are pretty similar, they either create minimal, or no line table 48501 for one of the functions in the source file, and as a consequence GDB 48502 returns an unexpected address at some point during the test. 48503 48504 However, both of those tests are really focused on other issues, so I 48505 think this new test does add some value. Plus the new test is not 48506 large, so it's not a huge cost to also run this new test. 48507 48508 Reviewed-By: Tom Tromey <tom@tromey.com> 48509 485102023-05-19 Andrew Burgess <aburgess@redhat.com> 48511 48512 gdb/breakpoint: use warning function instead of gdb_printf 48513 Noticed that in breakpoint.c, in one place, we do this: 48514 48515 gdb_printf (_("warning: Error removing " 48516 "breakpoint %d\n"), 48517 old_loc->owner->number); 48518 48519 Instead of using the `warning` function. There are a number of 48520 differences between using gdb_printf like this and calling `warning`, 48521 the main one is probably that real warnings are sent to gdb_stderr, 48522 while the above gdb_printf call will go to gdb_stdout. 48523 48524 In this commit I: 48525 48526 1. Change to call `warning`, we can drop the "warning: " prefix from 48527 the string in breakpoint.c, 48528 48529 2. Update the warning text, I now start with a lower case 'e', which 48530 I believe is the GDB style for warnings, 48531 48532 3. And I have included the address of the bp_location in the warning 48533 messsage, 48534 48535 4. Finally, I update all the tests (2) that include this error 48536 message. 48537 48538 Reviewed-By: Tom Tromey <tom@tromey.com> 48539 485402023-05-19 Andrew Burgess <aburgess@redhat.com> 48541 48542 gdb/testsuite: handle older Python versions in gdb.python/py-disasm.exp 48543 It was pointed out on the mailing list that the new tests added in 48544 this commit: 48545 48546 commit 4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1 48547 Date: Tue Jan 24 15:35:45 2023 +0000 48548 48549 gdb/python: extend the Python Disassembler API to allow for styling 48550 48551 will fail when GDB is built with Python 3.6 or earlier. This is 48552 because the error that is emitted when a function argument is missing 48553 changed in Python 3.7, instead of an error like this: 48554 48555 Python Exception <class 'TypeError'>: function missing required argument 'style' (pos 1) 48556 48557 earlier versions of Python emit: 48558 48559 Python Exception <class 'TypeError'>: Required argument 'style' (pos 1) not found 48560 48561 and the new tests didn't allow for this. 48562 48563 This commit fixes this by allowing either pattern. I've tested this 48564 building GDB against Python 3.7.9 and 3.6.15, with this commit all 48565 tests in gdb.python/py-disasm.exp now pass. 48566 485672023-05-19 Kuan-Lin Chen <rufus@andestech.com> 48568 48569 RISC-V: Support subtraction of .uleb128. 48570 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/96d6e190e9fc04a8517f9ff7fb9aed3e9876cbd6 48571 48572 There are some known limitations for now, 48573 48574 * Do not shrink the length of the uleb128 value, even if the value is reduced 48575 after relaxations. Also reports error if the length grows up. 48576 48577 * The R_RISCV_SET_ULEB128 needs to be paired with and be placed before the 48578 R_RISCV_SUB_ULEB128. 48579 48580 bfd/ 48581 * bfd-in2.h: Regenerated. 48582 * elfnn-riscv.c (perform_relocation): Perform R_RISCV_SUB_ULEB128 and 48583 R_RISCV_SET_ULEB128 relocations. Do not shrink the length of the 48584 uleb128 value, and report error if the length grows up. Called the 48585 generic functions, _bfd_read_unsigned_leb128 and _bfd_write_unsigned_leb128, 48586 to encode the uleb128 into the section contents. 48587 (riscv_elf_relocate_section): Make sure that the R_RISCV_SET_ULEB128 48588 must be paired with and be placed before the R_RISCV_SUB_ULEB128. 48589 * elfxx-riscv.c (howto_table): Added R_RISCV_SUB_ULEB128 and 48590 R_RISCV_SET_ULEB128. 48591 (riscv_reloc_map): Likewise. 48592 (riscv_elf_ignore_reloc): New function. 48593 * libbfd.h: Regenerated. 48594 * reloc.c (BFD_RELOC_RISCV_SET_ULEB128, BFD_RELOC_RISCV_SUB_ULEB128): 48595 New relocations to support .uleb128 subtraction. 48596 gas/ 48597 * config/tc-riscv.c (md_apply_fix): Added BFD_RELOC_RISCV_SET_ULEB128 48598 and BFD_RELOC_RISCV_SUB_ULEB128. 48599 (s_riscv_leb128): Updated to allow uleb128 subtraction. 48600 (riscv_insert_uleb128_fixes): New function, scan uleb128 subtraction 48601 expressions and insert fixups for them. 48602 (riscv_md_finish): Called riscv_insert_uleb128_fixes for all sections. 48603 include/ 48604 * elf/riscv.h ((R_RISCV_SET_ULEB128, (R_RISCV_SUB_ULEB128): Defined. 48605 ld/ 48606 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 48607 * testsuite/ld-riscv-elf/uleb128*: New testcase for uleb128 subtraction. 48608 binutils/ 48609 * testsuite/binutils-all/nm.exp: Updated since RISCV supports .uleb128. 48610 486112023-05-19 Nelson Chu <nelson@rivosinc.com> 48612 48613 RISC-V: Minor improvements for dis-assembler. 48614 * Extract all private_data initializations into riscv_init_disasm_info, which 48615 called from print_insn_riscv rather than riscv_disassemble_insn. 48616 48617 * The disassemble_free_target seems like the right place to release all target 48618 private_data, also including the internal data structures, like riscv_subsets. 48619 Therefore, add a new function, disassemble_free_riscv, to release them for safe. 48620 48621 opcodes/ 48622 * disassemble.c (disassemble_free_target): Called disassemble_free_riscv 48623 for riscv to release private_data and internal data structures. 48624 * disassemble.h: Added extern disassemble_free_riscv. 48625 * riscv-dis.c (riscv_init_disasm_info): New function, used to init 48626 riscv_private_data. 48627 (riscv_disassemble_insn): Moved riscv_private_data initializations 48628 into riscv_init_disasm_info. 48629 (print_insn_riscv): Called riscv_init_disasm_info to init 48630 riscv_private_data once time. 48631 (disassemble_free_riscv): New function, used to free the internal data 48632 structures, like riscv_subsets. 48633 486342023-05-19 Jan Beulich <jbeulich@suse.com> 48635 48636 x86: permit all relational operators in insn operands 48637 Oddly enough == and != were not permitted, because of '=' not having 48638 been listed in operand_special_chars[]. 48639 486402023-05-19 Jan Beulich <jbeulich@suse.com> 48641 48642 x86: further adjust extend-to-32bit-address conditions 48643 While a442cac5084e ("ix86: wrap constants") helped address a number of 48644 inconsistencies between BFD64 and !BFD64 builds, it has also resulted in 48645 certain bogus uses of constants to no longer be warned about. Leverage 48646 the md_optimize_expr() hook to adjust when to actually truncate 48647 expressions to 32 bits - any involvement of binary expressions (which 48648 would be evaluated in 32 bits only when !BFD64) signals the need for 48649 doing so. Plain constants (or ones merely subject to unary operators) 48650 should remain un-truncated - they would be handled as bignums when 48651 !BFD64, and hence are okay to permit. 48652 48653 To compensate 48654 - slightly extend optimize_imm() (to be honest I never understood why 48655 the code being added - or something similar - wasn't there in the 48656 first place), 48657 - adjust expectations of the disp-imm-32 testcase (there are now 48658 warnings, as there should be for any code which won't build [warning- 48659 free] when !BFD64, and Disp8/Imm8 are no longer used in the warned 48660 about cases). 48661 486622023-05-19 Jan Beulich <jbeulich@suse.com> 48663 48664 gas: invoke md_optimize_expr() also for unary expressions 48665 Give backends a chance to see these, just as they can see binary ones. 48666 Most of those which use this hook already cope with NULL being passed 48667 for the left operand (typically because of checking the operator first). 48668 Adjust the two which don't. 48669 48670 Take the opportunity and also document the hook. 48671 486722023-05-19 Jan Beulich <jbeulich@suse.com> 48673 48674 gas: maintain O_constant signedness in more cases 48675 Unary '~' doesn't really produce an unsigned result. Neither does 48676 subtraction (unless taking operand values into consideration). And an 48677 abstract operator applied to two operands which aren't both unsigned 48678 can't be assumed to yield an unsigned result; exceptions are 48679 - shifts, where only signedness of the left hand operand matters, 48680 - comparisons, which - unlike unary '!' - produce signed results (they 48681 deliver 0 or ~0, as opposed to '!', which yields 0 or 1), 48682 - logical operators (yielding 0 or 1 and hence treated like unary '!'). 48683 48684 While doing this (specifically while extending the all/quad testcase), 48685 update .quad and .8byte documentation: With 64-bit architectures now 48686 being common, it is highly inappropriate to state that these directives 48687 unconditionally require bignums. 48688 486892023-05-19 Jan Beulich <jbeulich@suse.com> 48690 48691 x86: tighten extend-to-32bit-address conditions 48692 In a442cac5084e ("ix86: wrap constants") I made the truncation condition 48693 too relaxed: Any indication of a mode that's possible with BFD64 only 48694 should avoid the truncation. Therefore, like in the other two cases of 48695 calls to extend_to_32bit_address(), also check whether we're generating 48696 a 64-bit object. 48697 486982023-05-19 GDB Administrator <gdbadmin@sourceware.org> 48699 48700 Automatic date update in version.in 48701 487022023-05-18 Tom Tromey <tromey@adacore.com> 48703 48704 Use lower-case in @sc in the documentation 48705 Eli pointed out that @sc only produces small caps for lower case 48706 letters in its argument, so it's weird to write it using upper-case 48707 letters. This patch fixes the instances I found. 48708 48709 Approved-By: Eli Zaretskii <eliz@gnu.org> 48710 487112023-05-18 Simon Marchi <simon.marchi@efficios.com> 48712 48713 gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function parameters (PR 30414) 48714 gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound 48715 values by reading some output from the inferior. This is racy when 48716 running on boards where the inferior I/O is on a separate TTY than 48717 GDB's, such as native-gdbserver. 48718 48719 I sometimes see this behavior: 48720 48721 (gdb) continue 48722 Continuing. 48723 48724 Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati 48725 ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45 48726 45 print *, "" ! Test Breakpoint 48727 (gdb) Remote debugging from host ::1, port 37496 48728 48729 Expected GDB Output: 48730 48731 LBOUND = (-8, -10) 48732 UBOUND = (-1, -2) 48733 APB: Run a test here 48734 APB: Expected lbound '(-8, -10)' 48735 APB: Expected ubound '' 48736 48737 What happened is that expect read the output from GDB before the output 48738 from the inferior, triggering this gdb_test_multiple clause: 48739 48740 -re "$gdb_prompt $" { 48741 set found_prompt true 48742 48743 if {$found_dealloc_breakpoint 48744 || ($expected_lbound != "" && $expected_ubound != "")} { 48745 # We're done. 48746 } else { 48747 exp_continue 48748 } 48749 } 48750 48751 So it set found_prompt, but the gdb_test_multiple kept going because 48752 found_dealloc_breakpoint is false (this is the flag indicating that the 48753 test is finished) and we still don't have expected_lbound and 48754 expected_ubound. Then, expect reads in the inferior I/O, triggering 48755 this clause: 48756 48757 -re ".*LBOUND = (\[^\r\n\]+)\r\n" { 48758 set expected_lbound $expect_out(1,string) 48759 if {!$found_prompt} { 48760 exp_continue 48761 } 48762 } 48763 48764 This sets expected_lbound, but since found_prompt is true, we don't do 48765 exp_continue, and exit the gdb_test_multiple, without having an 48766 expected_ubound. 48767 48768 Change the test to read the values from the lb and ub function 48769 parameters instead. As far as I understand, this still exercises what 48770 we want to test. These variables contain the return values of the 48771 lbound and ubound functions as computed by the program. We'll use them 48772 to check the return values of the lbound and ubound functions as 48773 computed by GDB. 48774 48775 Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5 48776 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414 48777 487782023-05-18 Hui Li <lihui@loongson.cn> 48779 48780 gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_ 48781 In the current code, when execute the following test on LoongArch: 48782 48783 $ make check-gdb TESTS="gdb.base/gnu-ifunc.exp" 48784 === gdb Summary === 48785 48786 # of expected passes 111 48787 # of unexpected failures 62 48788 48789 According to IFUNC's working process [1]. first time the IFUNC function 48790 is called, the dynamic linker will not simply fill the .got.plt entry 48791 with the actual address of IFUNC symbol, it will call the IFUNC resolver 48792 function and take the return address, uses it as the sym-bound address 48793 and puts it in the .got.plt entry. Initial address in .got.plt entry is 48794 not a real function addresss. Depending on the compiler implementation, 48795 some different addresses will be filled in. Most architectures will use 48796 a .plt entry address to fill in the corresponding .got.plt entry. 48797 48798 In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real 48799 IFUNC function addresss. First check to see if the real address for 48800 the IFUNC symbol has been resolved by the following function: 48801 48802 elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p) 48803 { 48804 if (elf_gnu_ifunc_resolve_by_cache (name, addr_p)) 48805 return true; 48806 48807 if (elf_gnu_ifunc_resolve_by_got (name, addr_p)) 48808 return true; 48809 48810 return false; 48811 } 48812 48813 in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the 48814 .got.plt entry and determines if the contents is the correct address 48815 by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working 48816 principle analysis above, the address filled in the .got.plt entry is 48817 not the actual target function address initially, it would be a .plt 48818 entry address corresponding symbol like *@plt. In this case, gdb just 48819 go back to execute the resolver function and puts the return address 48820 in the .got.plt entry. After that, gdb can get a real ifun address via 48821 .got.plt entry. 48822 48823 On LoongArch, initially, each address filled in the .got.plt entries 48824 is the first .plt entry address. Some architectures such as LoongArch 48825 define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt 48826 section. This symbol is the first plt entry, so gdb needs to check 48827 this symbol in elf_gnu_ifunc_record_cache(). 48828 48829 On LoongArch .got.plt and .plt section as follow: 48830 48831 $objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0 48832 ... 48833 0000000120010008 <.got.plt>: 48834 120010008: ffffffff 0xffffffff 48835 12001000c: ffffffff 0xffffffff 48836 ... 48837 120010018: 20004000 ll.w $zero, $zero, 64(0x40) 48838 12001001c: 00000001 0x00000001 48839 120010020: 20004000 ll.w $zero, $zero, 64(0x40) 48840 120010024: 00000001 0x00000001 48841 120010028: 20004000 ll.w $zero, $zero, 64(0x40) 48842 12001002c: 00000001 0x00000001 48843 120010030: 20004000 ll.w $zero, $zero, 64(0x40) 48844 120010034: 00000001 0x00000001 48845 48846 ... 48847 Disassembly of section .plt: 48848 48849 0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>: 48850 120004000: 1c00018e pcaddu12i $t2, 12(0xc) 48851 120004004: 0011bdad sub.d $t1, $t1, $t3 48852 120004008: 28c021cf ld.d $t3, $t2, 8(0x8) 48853 12000400c: 02ff51ad addi.d $t1, $t1, -44(0xfd4) 48854 120004010: 02c021cc addi.d $t0, $t2, 8(0x8) 48855 120004014: 004505ad srli.d $t1, $t1, 0x1 48856 120004018: 28c0218c ld.d $t0, $t0, 8(0x8) 48857 12000401c: 4c0001e0 jirl $zero, $t3, 0 48858 48859 0000000120004020 <__libc_start_main@plt>: 48860 120004020: 1c00018f pcaddu12i $t3, 12(0xc) 48861 120004024: 28ffe1ef ld.d $t3, $t3, -8(0xff8) 48862 120004028: 4c0001ed jirl $t1, $t3, 0 48863 12000402c: 03400000 andi $zero, $zero, 0x0 48864 48865 0000000120004030 <abort@plt>: 48866 120004030: 1c00018f pcaddu12i $t3, 12(0xc) 48867 120004034: 28ffc1ef ld.d $t3, $t3, -16(0xff0) 48868 120004038: 4c0001ed jirl $t1, $t3, 0 48869 12000403c: 03400000 andi $zero, $zero, 0x0 48870 48871 0000000120004040 <gnu_ifunc@plt>: 48872 120004040: 1c00018f pcaddu12i $t3, 12(0xc) 48873 120004044: 28ffa1ef ld.d $t3, $t3, -24(0xfe8) 48874 120004048: 4c0001ed jirl $t1, $t3, 0 48875 12000404c: 03400000 andi $zero, $zero, 0x0 48876 ... 48877 48878 With this patch: 48879 48880 $make check-gdb TESTS="gdb.base/gnu-ifunc.exp" 48881 === gdb Summary === 48882 48883 #of expected passes 173 48884 48885 [1] https://sourceware.org/glibc/wiki/GNU_IFUNC 48886 488872023-05-18 Alan Modra <amodra@gmail.com> 48888 48889 Re: Add section caches to coff_data_type 48890 Another thing, section target_index is renumbered in 48891 coff_compute_section_file_positions and _bfd_xcoff_bfd_final_link. I 48892 don't know that there is currently any way that the output bfd 48893 section_by_target_index could be populated before this point but 48894 clear them out so no one need worry about it. 48895 48896 * coffcode.h (coff_compute_section_file_positions): Clear 48897 section_by_target_index hash table when changing target_index. 48898 (_bfd_xcoff_bfd_final_link): Likewise. 48899 489002023-05-18 Tom de Vries <tdevries@suse.de> 48901 48902 [gdb/testsuite] Fix whitespace and indentation in lib/tuiterm.exp 48903 I noticed a trailing whitespace and some indentation errors in lib/tuiterm.exp. 48904 48905 Fix these. 48906 48907 Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) 48908 on x86_64-linux. 48909 489102023-05-18 Indu Bhagat <indu.bhagat@oracle.com> 48911 48912 libsframe: testsuite: add tests for sframe_get_funcdesc_with_addr API 48913 sframe_get_funcdesc_with_addr API is currently used internally by the 48914 sframe_find_fre (). 48915 48916 In this test, we create three dummy SFrame FDEs with 4 FREs each. Then, 48917 we use few negative tests to lookup FREs with PCs not in the range of 48918 PCs covered by the FDEs, ensuring graceful return from 48919 sframe_get_funcdesc_with_addr in all cases. Some positive tests are 48920 also added that exercise further scenarios as well. 48921 48922 libsframe/ 48923 * Makefile.in: Regenerated. 48924 * testsuite/libsframe.find/find.exp: Include new test. 48925 * testsuite/libsframe.find/findfunc-1.c: New Test. 48926 * testsuite/libsframe.find/local.mk: Include new test. 48927 489282023-05-18 Indu Bhagat <indu.bhagat@oracle.com> 48929 48930 libsframe: testsuite: add new tests for sframe_find_fre API 48931 libsframe provides an API to find the FRE associated with a given PC in 48932 the program. This patch adds a direct test of this API. 48933 48934 In this test, we create two dummy SFrame FDEs with 4 FREs each. Then we 48935 test that sframe_find_fre () works for the first, second, third and the 48936 last FRE from one of the FDEs. Such a test ensures better regression 48937 testing for the sframe_find_fre () function which is going to be the 48938 bread and butter of an SFrame based stack tracer. 48939 48940 libsframe/ 48941 * Makefile.in: Regenerated. 48942 * testsuite/libsframe.find/find.exp: New test. 48943 * testsuite/libsframe.find/findfre-1.c: New test. 48944 * testsuite/libsframe.find/local.mk: Build new test. 48945 * testsuite/local.mk: Include libsframe.find. 48946 489472023-05-18 Alan Modra <amodra@gmail.com> 48948 48949 Re: Add section caches to coff_data_type 48950 Commit 0e759f232b6d regressed these tests: 48951 rs6000-aix7.2 +FAIL: Garbage collection test 1 (32-bit) 48952 rs6000-aix7.2 +FAIL: Garbage collection test 1 (64-bit) 48953 rs6000-aix7.2 +FAIL: Glink test 1 (32-bit) 48954 rs6000-aix7.2 +FAIL: Glink test 1 (64-bit) 48955 48956 Investigation showed segfaults in coff_section_from_bfd_index called 48957 by xcoff_write_global_symbol due to the hash table pointer being 48958 NULL. Well, yes, the hash table isn't initialised for the output bfd. 48959 mkobject_hook is the wrong place to do that. 48960 48961 * coffcode.h: Revert 0e759f232b6d changes. 48962 * peicode.h: Likewise. 48963 * coff-x86_64.c (htab_hash_section_index, htab_eq_section_index): 48964 Moved here from coffcode.h. 48965 (coff_amd64_rtype_to_howto): Create section_by_index htab. 48966 * coffgen.c (htab_hash_section_target_index), 48967 (htab_eq_section_target_index): Moved here from coffcode.h. 48968 (coff_section_from_bfd_index): Create section_by_target_index 48969 htab. Stash newly created sections in htab. 48970 489712023-05-18 Alan Modra <amodra@gmail.com> 48972 48973 PR11601, Solaris assembler compatibility doesn't work 48974 Well, it doesn't work on x86 or ppc, which both have # starting 48975 comments anywhere on a line. I think it is therefore only useful on 48976 sparc. 48977 48978 PR 11601 48979 * config/obj-elf.c (obj_elf_section_word): Only compile for sparc. 48980 (obj_elf_section): Only support solaris .section directive on 48981 sparc. 48982 * doc/as.texi (Section): Mention that solaris .section 48983 directive is only supported for sparc. 48984 489852023-05-18 GDB Administrator <gdbadmin@sourceware.org> 48986 48987 Automatic date update in version.in 48988 489892023-05-17 Tom Tromey <tom@tromey.com> 48990 48991 Special case "&str" in Rust parser 48992 "&str" is an important type in Rust -- it's the type of string 48993 literals. However, the compiler puts it in the DWARF in a funny way. 48994 The slice itself is present and named "&str". However, the Rust 48995 parser doesn't look for types with names like this, but instead tries 48996 to construct them from components. In this case it tries to make a 48997 pointer-to-"str" -- but "str" isn't always available, and in any case 48998 that wouldn't yield the best result. 48999 49000 This patch adds a special case for &str. 49001 49002 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251 49003 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 49004 490052023-05-17 Luca Bacci <luca.bacci@outlook.com> 49006 49007 Decorated symbols in import libs (BUG 30421) 49008 PR 30421 49009 * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it. 49010 * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype. 49011 * libcoff.h: Regenerate. 49012 49013 * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function. 49014 * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function. 49015 * pe-dll.c (make_one): Check for decoated symbols. 49016 490172023-05-17 Alan Modra <amodra@gmail.com> 49018 49019 PR29961, plugin-api.h: "Could not detect architecture endianess" 49020 Found when attempting to build binutils on sparc sunos-5.8 where 49021 sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER 49022 variants. This patch adds the extra tests to cope with the old 49023 machine, and tidies the header a little. 49024 49025 PR 29961 49026 plugin-api.h: When handling non-gcc or gcc < 4.6.0 include 49027 necessary header files before testing macros. Make more use 49028 of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests. 49029 490302023-05-17 Alan Modra <amodra@gmail.com> 49031 49032 gcc-4.5 build fixes 49033 Trying to build binutils with an older gcc currently fails. Working 49034 around these gcc bugs is not onerous so let's fix them. 49035 49036 bfd/ 49037 * elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun 49038 pointer. 49039 * elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat" 49040 variable to "status". 49041 gas/ 49042 * compress-debug.c (compress_finish): Supply all fields in 49043 ZSTD_inBuffer initialisation. 49044 include/ 49045 * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary 49046 forward declaration. 49047 opcodes/ 49048 * loongarch-opc.c: Supply all fields of zero struct initialisation 49049 in various opcode tables. 49050 490512023-05-17 GDB Administrator <gdbadmin@sourceware.org> 49052 49053 Automatic date update in version.in 49054 490552023-05-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 49056 49057 gprofng: include a new function in the right place 49058 Static function name is not available in stripped libraries. 49059 In this case, gprofng maps PC to a fake function like <static>@0xPC (<libname>). 49060 Sometimes gprofng creates two functions instead of one. 49061 Also FUNC_FLAG_SIMULATED is needed for these fake functions. 49062 49063 gprofng/ChangeLog 49064 2023-05-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 49065 49066 * src/LoadObject.cc (LoadObject::find_function): Set FUNC_FLAG_SIMULATED. 49067 Include a new function in the right place. 49068 490692023-05-16 Tom de Vries <tdevries@suse.de> 49070 49071 [gdb/tui] Don't show line number for lines not in source file 49072 Currently, for a source file containing only 5 lines, we also show line 49073 numbers 6 and 7 if they're in scope of the source window: 49074 ... 49075 0 +-compact-source.c----------------+ 49076 1 |___3_{ | 49077 2 |___4_ return 0; | 49078 3 |___5_} | 49079 4 |___6_ | 49080 5 |___7_ | 49081 6 +---------------------------------+ 49082 ... 49083 49084 Fix this by not showing line numbers not in a source file, such that we have instead: 49085 ... 49086 0 +-compact-source.c----------------+ 49087 1 |___3_{ | 49088 2 |___4_ return 0; | 49089 3 |___5_} | 49090 4 | | 49091 5 | | 49092 6 +---------------------------------+ 49093 ... 49094 49095 Tested on x86_64-linux. 49096 49097 Suggested-By: Simon Marchi <simon.marchi@efficios.com> 49098 Approved-By: Tom Tromey <tom@tromey.com> 49099 491002023-05-16 Nick Clifton <nickc@redhat.com> 49101 49102 Document how to use the linker to create a resource only DLL. 49103 PR 30359 49104 * ld.texi (WIN32): Document how to create a resource only DLL. 49105 491062023-05-16 Oleg Tolmatcev <oleg.tolmatcev@gmail.com> 49107 49108 Add section caches to coff_data_type 49109 * libcoff-in.h (struct coff_tdata): Add section_by_index and section_by_target_index hash tables. 49110 * libcoff.h: Regenerate. 49111 * coffcode.h (htab_hash_section_index): New function. (htab_eq_section_index): New function. (htab_hash_section_target_index): New function. (htab_eq_section_target_index): New function. (coff_mkobject_hool): Create the hash tables. 49112 * peicode.h: Add the same new functions. (pe_mkobject_hook): Create the hash tables. 49113 * coff-x86_64.c (coff_amd64_rtype_to_howto): Use the new tables to speed up lookups. 49114 * coffgen.c (coff_section_from_bfd_index): Likewise. (_bfd_coff_close_and_cleanup): Delete the hash tables. 49115 491162023-05-16 Paul Pluzhnikov <ppluzhnikov@google.com> 49117 49118 Update comments for the gdb/24331 fix. 49119 Approved-by: Andrew Burgess <aburgess@redhat.com> 49120 491212023-05-16 Andrew Burgess <aburgess@redhat.com> 49122 49123 gdb/testsuite: fix formatting of gdb.python/py-disasm.py 49124 Run black on gdb.python/py-disasm.py file and commit the changes. 49125 491262023-05-16 Andrew Burgess <aburgess@redhat.com> 49127 49128 gdb/testsuite: make gdb_supported_languages a caching proc 49129 Rewrite gdb_supported_languages as a caching proc that actually 49130 queries GDB for the list of supported languages, rather than just 49131 containing a hard-coded list of languages. 49132 49133 There's only one test that uses this proc right now, 49134 gdb.python/py-function.exp, and that still passes after this change, 49135 with no changes in the test names. 49136 491372023-05-16 Nick Clifton <nickc@redhat.com> 49138 49139 -Ur option documentation 49140 * ld.texi (-Ur): Clarify the actions of this option. 49141 491422023-05-16 Andrew Burgess <aburgess@redhat.com> 49143 49144 gdb/testsuite: fix regressions in break-main-file-remove-fail.exp 49145 After this commit: 49146 49147 commit a68f7e9844208ad8cd498f89b5100084ece7d0f6 49148 Date: Tue May 9 10:28:42 2023 +0100 49149 49150 gdb/testsuite: extend special '^' handling to gdb_test_multiple 49151 49152 buildbot notified me of a regression on s390 in the test: 49153 49154 gdb.base/break-main-file-remove-fail.exp 49155 49156 the failure looks like this: 49157 49158 print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096) 49159 warning: Error removing breakpoint 0 49160 $2 = 0 49161 (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)" 49162 49163 On the mailing list it has been reported that this failure also 49164 impacts arm, aarch64, and possibly ppc/ppc64 too. 49165 49166 The above commit changed get_integer_valueof so that no output is 49167 expected between the command and the '$2 = 0' line. In this case the 49168 'warning: Error removing breakpoint 0' output is causing the 49169 get_integer_valueof call to fail. 49170 49171 The reason for this warning is that this test deliberately calls 49172 munmap on a page of the inferior's code. The test is checking that 49173 GDB can handle the situation where a s/w breakpoint can't be 49174 removed (due to the page no longer being readable/writable). 49175 49176 The test that is supposed to trigger the warning is later in the test 49177 script when we delete a breakpoint. 49178 49179 So why do some targets trigger the warning earlier during the inferior 49180 call? 49181 49182 The impacted targets use AT_ENTRY_POINT as their strategy for handling 49183 inferior calls, that is, the trampoline that calls the inferior 49184 function is placed at the program's entry point, e.g. often the _start 49185 label. 49186 49187 If this location happens to be on the same page as the page that the 49188 test script unmaps then, when the inferior function call returns, GDB 49189 will not be able to remove the temporary breakpoint that is inserted 49190 to catch the inferior function call returning! As a result we end up 49191 seeing the warning earlier than expected. 49192 49193 I did wonder if this means I should relax the pattern in 49194 get_integer_valueof - just accept that there might be additional 49195 output from GDB which we should ignore. 49196 49197 However, I don't think this the right way to go. With the change in 49198 a68f7e984420 we are now stricter for GDB emitting additional, 49199 unexpected, output, and I think that is a good thing. 49200 49201 So, I think, in this case, in order to handle the possible extra 49202 output, we should implement something like get_integer_valueof 49203 directly in the gdb.base/break-main-file-remove-fail.exp test script. 49204 This local version will handle the possible warning output. 49205 49206 After this the test should pass again on the impacted targets. 49207 492082023-05-16 Andrew Burgess <aburgess@redhat.com> 49209 49210 gdb/python: extend the Python Disassembler API to allow for styling 49211 This commit extends the Python Disassembler API to allow for styling 49212 of the instructions. 49213 49214 Before this commit the Python Disassembler API allowed the user to do 49215 two things: 49216 49217 - They could intercept instruction disassembly requests and return a 49218 string of their choosing, this string then became the disassembled 49219 instruction, or 49220 49221 - They could call builtin_disassemble, which would call back into 49222 libopcode to perform the disassembly. As libopcode printed the 49223 instruction GDB would collect these print requests and build a 49224 string. This string was then returned from the builtin_disassemble 49225 call, and the user could modify or extend this string as needed. 49226 49227 Neither of these approaches allowed for, or preserved, disassembler 49228 styling, which is now available within libopcodes for many of the more 49229 popular architectures GDB supports. 49230 49231 This commit aims to fill this gap. After this commit a user will be 49232 able to do the following things: 49233 49234 - Implement a custom instruction disassembler entirely in Python 49235 without calling back into libopcodes, the custom disassembler will 49236 be able to return styling information such that GDB will display 49237 the instruction fully styled. All of GDB's existing style 49238 settings will affect how instructions coming from the Python 49239 disassembler are displayed in the expected manner. 49240 49241 - Call builtin_disassemble and receive a result that represents how 49242 libopcode would like the instruction styled. The user can then 49243 adjust or extend the disassembled instruction before returning the 49244 result to GDB. Again, the instruction will be styled as expected. 49245 49246 To achieve this I will add two new classes to GDB, 49247 DisassemblerTextPart and DisassemblerAddressPart. 49248 49249 Within builtin_disassemble, instead of capturing the print calls from 49250 libopcodes and building a single string, we will now create either a 49251 text part or address part and store these parts in a vector. 49252 49253 The DisassemblerTextPart will capture a small piece of text along with 49254 the associated style that should be used to display the text. This 49255 corresponds to the disassembler calling 49256 disassemble_info::fprintf_styled_func, or for disassemblers that don't 49257 support styling disassemble_info::fprintf_func. 49258 49259 The DisassemblerAddressPart is used when libopcodes requests that an 49260 address be printed, and takes care of printing the address and 49261 associated symbol, this corresponds to the disassembler calling 49262 disassemble_info::print_address_func. 49263 49264 These parts are then placed within the DisassemblerResult when 49265 builtin_disassemble returns. 49266 49267 Alternatively, the user can directly create parts by calling two new 49268 methods on the DisassembleInfo class: DisassembleInfo.text_part and 49269 DisassembleInfo.address_part. 49270 49271 Having created these parts the user can then pass these parts when 49272 initializing a new DisassemblerResult object. 49273 49274 Finally, when we return from Python to gdbpy_print_insn, one way or 49275 another, the result being returned will have a list of parts. Back in 49276 GDB's C++ code we walk the list of parts and call back into GDB's core 49277 to display the disassembled instruction with the correct styling. 49278 49279 The new API lives in parallel with the old API. Any existing code 49280 that creates a DisassemblerResult using a single string immediately 49281 creates a single DisassemblerTextPart containing the entire 49282 instruction and gives this part the default text style. This is also 49283 what happens if the user calls builtin_disassemble for an architecture 49284 that doesn't (yet) support libopcode styling. 49285 49286 This matches up with what happens when the Python API is not involved, 49287 an architecture without disassembler styling support uses the old 49288 libopcodes printing API (the API that doesn't pass style info), and 49289 GDB just prints everything using the default text style. 49290 49291 The reason that parts are created by calling methods on 49292 DisassembleInfo, rather than calling the class constructor directly, 49293 is DisassemblerAddressPart. Ideally this part would only hold the 49294 address which the part represents, but in order to support backwards 49295 compatibility we need to be able to convert the 49296 DisassemblerAddressPart into a string. To do that we need to call 49297 GDB's internal print_address function, and to do that we need an 49298 gdbarch. 49299 49300 What this means is that the DisassemblerAddressPart needs to take a 49301 gdb.Architecture object at creation time. The only valid place a user 49302 can pull this from is from the DisassembleInfo object, so having the 49303 DisassembleInfo act as a factory ensures that the correct gdbarch is 49304 passed over each time. I implemented both solutions (the one 49305 presented here, and an alternative where parts could be constructed 49306 directly), and this felt like the cleanest solution. 49307 49308 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 49309 Reviewed-By: Tom Tromey <tom@tromey.com> 49310 493112023-05-16 Andrew Burgess <aburgess@redhat.com> 49312 49313 gdb/python: rework how the disassembler API reads the result object 49314 This commit is a refactor ahead of the next change which will make 49315 disassembler styling available through the Python API. 49316 49317 Unfortunately, in order to make the styling support available, I think 49318 the easiest solution is to make a very small change to the existing 49319 API. 49320 49321 The current API relies on returning a DisassemblerResult object to 49322 represent each disassembled instruction. Currently GDB allows the 49323 DisassemblerResult class to be sub-classed, which could mean that a 49324 user tries to override the various attributes that exist on the 49325 DisassemblerResult object. 49326 49327 This commit removes this ability, effectively making the 49328 DisassemblerResult class final. 49329 49330 Though this is a change to the existing API, I'm hoping this isn't 49331 going to cause too many issues: 49332 49333 - The Python disassembler API was only added in the previous release 49334 of GDB, so I don't expect it to be widely used yet, and 49335 49336 - It's not clear to me why a user would need to sub-class the 49337 DisassemblerResult type, I allowed it in the original patch 49338 because at the time I couldn't see any reason to NOT allow it. 49339 49340 Having prevented sub-classing I can now rework the tail end of the 49341 gdbpy_print_insn function; instead of pulling the results out of the 49342 DisassemblerResult object by calling back into Python, I now cast the 49343 Python object back to its C++ type (disasm_result_object), and access 49344 the fields directly from there. In later commits I will be reworking 49345 the disasm_result_object type in order to hold information about the 49346 styled disassembler output. 49347 49348 The tests that dealt with sub-classing DisassemblerResult have been 49349 removed, and a new test that confirms that DisassemblerResult can't be 49350 sub-classed has been added. 49351 49352 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 49353 Reviewed-By: Tom Tromey <tom@tromey.com> 49354 493552023-05-16 GDB Administrator <gdbadmin@sourceware.org> 49356 49357 Automatic date update in version.in 49358 493592023-05-15 Tom Tromey <tom@tromey.com> 49360 49361 Correctly handle forward DIE references in scanner 49362 The cooked index scanner has special code to handle forward DIE 49363 references. However, a bug report lead to the discovery that this 49364 code does not work -- the "deferred_entry::spec_offset" field is 49365 written to but never used, i.e., the lookup is done using the wrong 49366 key. 49367 49368 This patch fixes the bug and adds a regression test. 49369 49370 The test in the bug itself used a thread_local variable, which 49371 provoked a failure at runtime. This test instead uses "maint print 49372 objfiles" and then inspects to ensure that the entry in question has a 49373 parent. This lets us avoid a clang dependency in the test. 49374 49375 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271 49376 493772023-05-15 mengqinggang <mengqinggang@loongson.cn> 49378 49379 LoongArch: Fix PLT entry generate bug 49380 If a function symbol only get its address by la.global, without 49381 directly called by bl instruction, the PLT entry is not required. 49382 49383 bfd/ChangeLog: 49384 49385 * elfnn-loongarch.c (loongarch_elf_adjust_dynamic_symbol): Fix PLT 49386 entry generate bug. 49387 49388 ld/ChangeLog: 49389 49390 * testsuite/ld-elf/shared.exp: Clear xfail for LoongArch. 49391 493922023-05-15 GDB Administrator <gdbadmin@sourceware.org> 49393 49394 Automatic date update in version.in 49395 493962023-05-14 GDB Administrator <gdbadmin@sourceware.org> 49397 49398 Automatic date update in version.in 49399 494002023-05-13 Paul Pluzhnikov <ppluzhnikov@google.com> 49401 49402 Fix bad interaction between element limit and repeated values (BZ#24331). 49403 Currently 49404 49405 print -elements=3 -- "AAAAAA" 49406 49407 prints complete string, which is not what the user asked for. 49408 49409 Fix two buggy tests exposed by the fix, and add a new test. 49410 49411 Reviewed-by: Keith Seitz <keiths@redhat.com> 49412 494132023-05-13 Alan Modra <amodra@gmail.com> 49414 49415 PR28955 mips gas segfault 49416 Testing for NULL in pic_need_relax fixes the other call to this 49417 function in md_estimate_size_before_relax. 49418 49419 PR 28955 49420 * config/tc-mips.c (mips_frob_file): Move NULL sym test to.. 49421 (pic_need_relax): ..here. 49422 494232023-05-13 Alan Modra <amodra@gmail.com> 49424 49425 PR28902, -T script with INSERT ordering 49426 The answer to PR28902 may be deduced from the existing INSERT 49427 documentation that says the default script is parsed after the -T 49428 INSERT script, if you assume (correctly) that nothing special is done 49429 when inserting into -T scripts overriding the default script. In both 49430 cases INSERT handling looks for the specified output section later on 49431 the internal list of parsed script commands. This isn't obvious 49432 though, so make the ordering explicit, and mention that section 49433 assignments are the same too. 49434 49435 PR 28902 49436 * ld.texi (INSERT): Specify ordering when -T is used both to 49437 override the default script and to augment. 49438 494392023-05-13 GDB Administrator <gdbadmin@sourceware.org> 49440 49441 Automatic date update in version.in 49442 494432023-05-12 Tom Tromey <tromey@adacore.com> 49444 49445 Fix regression due to Pragma Import series 49446 A co-worker here at AdaCore discovered that the Pragma Import series 49447 caused a rgression. When debugging gnat1, gdb started asking for 49448 overload resolution like: 49449 49450 (gdb) call pp(n) 49451 Multiple matches for pp 49452 [0] cancel 49453 [1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511 49454 [2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511 49455 49456 This worked before the series, and is strange anyway, because the 49457 matches refer to the same function. 49458 49459 This patch adds a test case for this situation and fixes the bug by 49460 pruning identical functions in remove_extra_symbols. 49461 494622023-05-12 Tom Tromey <tromey@adacore.com> 49463 49464 Use bool and early loop exit in remove_extra_symbols 49465 This changes remove_extra_symbols to use bool rather than int, and 49466 changes the nested loops to exit early when "remove_p" is set. 49467 49468 Use reference parameter in remove_extra_symbols 49469 Changing ada-lang.c:remove_extra_symbols to take a reference parameter 49470 makes the code a bit easier to read, by replacing "(*syms)" with plain 49471 "syms". 49472 49473 Handle Ada Pragma Import and Pragma Export 49474 Ada can import C APIs and also export Ada constructs to C via Pragma 49475 Import and Pragma Export. This patch adds support for these to gdb, 49476 by arranging to either defer some aspects of a symbol to the 49477 underlying C symbol (for Import) or by introducing a second symbol 49478 (for Export). A somewhat tricky approach is needed, both because gdb 49479 doesn't generally handle symbol aliasing, and because Ada treats 49480 symbol names in an unusual way (as compared to the rest of gdb). 49481 49482 Introduce symbol_block_ops::get_block_value 49483 This adds a new callback to symbol_block_ops. This callback lets a 49484 LOC_BLOCK symbol implement its own function to find the underlying 49485 block. 49486 49487 Define symbol::value_block separately 49488 This moves the definition of symbol::value_block outside of the class. 49489 A subsequent patch will change this method to use SYMBOL_BLOCK_OPS, 49490 and it seemed simplest to move this method out-of-line, and cleaner to 49491 do this as a separate change. 49492 49493 Bump MAX_SYMBOL_IMPLS 49494 A subsequent patch will introduce more aclass registrations, causing 49495 the number to go over the current maximum. This bumps the number. 49496 Note that there's a separate static assert that ensures that this 49497 number doesn't get too large for the field size in the symbol. 49498 49499 Introduce lookup_minimal_symbol_linkage 49500 This introduces a new function, lookup_minimal_symbol_linkage, and 49501 refactors a couple other existing functions to call it. This function 49502 will be used in a subsequent patch. 49503 495042023-05-12 Simon Marchi <simon.marchi@efficios.com> 49505 49506 gdb: remove unnecessary call to std::string constructor 49507 I spotted this explicit call to std::string, which creates an 49508 unnecessary temporary extra std::string, while calling emplace_back. 49509 I'm not sure if it has any impact in an optimized build, maybe the 49510 compiler elides it. But still, it's unnecessary. 49511 49512 Change-Id: I873337ea91db29ac06267aff8fc12dcf52824cac 49513 Approved-By: Tom Tromey <tom@tromey.com> 49514 495152023-05-12 Tom Tromey <tromey@adacore.com> 49516 49517 Add dynamic_prop::is_constant 49518 I noticed many spots checking whether a dynamic property's kind is 49519 PROP_CONST. Some spots, I think, are doing a slightly incorrect check 49520 -- checking for != PROP_UNDEFINED where == PROP_CONST is actually 49521 required, the key thing being that const_val may only be called for 49522 PROP_CONST properties. 49523 49524 This patch adds dynamic::is_constant and then updates these checks to 49525 use it. 49526 49527 Regression tested on x86-64 Fedora 36. 49528 495292023-05-12 Tom Tromey <tromey@adacore.com> 49530 49531 Implement DAP register scope 49532 I noticed that gdb's DAP code did not provide a way to see register 49533 values. DAP defines a "register" scope, which this patch implements. 49534 This patch also adds the missing (and optional) "presentationHint" to 49535 scopes. 49536 495372023-05-12 Tom Tromey <tromey@adacore.com> 49538 49539 Fix calling debuginfo-less functions in Ada 49540 A co-worker at AdaCore noticed that calling a function without 49541 debuginfo yields: 49542 49543 (gdb) print plus_one(23) 49544 'pck.plus_one' has unknown return type; cast the call to its declared return type 49545 49546 However, this also happens if you follow the directions and add the 49547 cast. 49548 49549 This patch fixes the problem and adds a regression test. 49550 495512023-05-12 Andrew Burgess <aburgess@redhat.com> 49552 49553 gdb/python: implement DisassemblerResult.__str__ method 49554 Add the DisassemblerResult.__str__ method. This gives the same result 49555 as the DisassemblerResult.string attribute, but can be useful 49556 sometimes depending on how the user is trying to print the object. 49557 49558 There's a test for the new functionality. 49559 495602023-05-12 Andrew Burgess <aburgess@redhat.com> 49561 49562 gdb/python: implement __repr__ methods for py-disasm.c types 49563 Add a __repr__ method for the DisassembleInfo and DisassemblerResult 49564 types, and add some tests for these new methods. 49565 495662023-05-12 Andrew Burgess <aburgess@redhat.com> 49567 49568 gdb/doc: improve Python Disassembler API documentation 49569 Some small improvements to the Python Disassembler API documentation: 49570 49571 * Be consistent about using the package scope in the @deftp lines, 49572 49573 * Rework the description of the DisassemblerResult class to include 49574 mention of builtin_disassemble. 49575 495762023-05-12 Andrew Burgess <aburgess@redhat.com> 49577 49578 gdb/testsuite: extend special '^' handling to gdb_test_multiple 49579 The commit: 49580 49581 commit 08ec06d6440745ef9204d39197aa1e732df41056 49582 Date: Wed Mar 29 10:41:07 2023 +0100 49583 49584 gdb/testsuite: special case '^' in gdb_test pattern 49585 49586 Added some special handling of '^' to gdb_test -- a leading '^' will 49587 cause the command regexp to automatically be included in the expected 49588 output pattern. 49589 49590 It was pointed out that the '-wrap' flag of gdb_test_multiple is 49591 supposed to work in the same way as gdb_test, and that the recent 49592 changes for '^' had not been replicated for gdb_test_multiple. This 49593 patch addresses this issue. 49594 49595 So, after this commit, the following two constructs should have the 49596 same meaning: 49597 49598 gdb_test "command" "^output" "test name" 49599 49600 gdb_test_multiple "command" "test name" { 49601 -re -wrap "^output" { 49602 pass $gdb_test_name 49603 } 49604 } 49605 49606 In both cases the '^' will case gdb.exp to inject a regexp that 49607 matches 'command' after the '^' and before the 'output', this is in 49608 addition to adding the $gdb_prompt pattern after 'output' in the 49609 normal way. 49610 49611 The special '^' handling is only applied when '-wrap' is used, as this 49612 is the only mode that aims to mimic gdb_test. 49613 49614 While working on this patch I realised that I could actually improve 49615 the logic for the special '^' handling in the case where the expected 49616 output pattern is empty. I replicated these updates for both gdb_test 49617 and gdb_test_multiple in order to keep these two paths in sync. 49618 49619 There were a small number of tests that needed adjustment after this 49620 change, mostly just removing command regexps that are now added 49621 automatically, but the gdb.base/settings.exp case was a little weird 49622 as it turns out trying to match a single blank line is probably harder 49623 now than it used to be -- still, I suspect this is a pretty rare case, 49624 so I think the benefits (improved anchoring) outweigh this small 49625 downside (IMHO). 49626 496272023-05-12 Andrew Burgess <aburgess@redhat.com> 49628 49629 gdb: fix error message for $_gdb_maint_setting 49630 I spotted this behaviour: 49631 49632 (gdb) p $_gdb_maint_setting("xxx") 49633 First argument of $_gdb_maint_setting must be a valid setting of the 'show' command. 49634 49635 Notice that GDB claims I need to use a setting from the 'show' 49636 command, which isn't correct for $_gdb_maint_setting, in this case I 49637 need to use a setting from 'maintenance show'. 49638 49639 This same issue is present for $_gdb_maint_setting_str. 49640 49641 This commit fixes this minor issue. 49642 49643 Approved-By: Simon Marchi <simon.marchi@efficios.com> 49644 496452023-05-12 Tom de Vries <tdevries@suse.de> 49646 49647 [gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32 49648 When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board 49649 unix/-m32 we have: 49650 ... 49651 (gdb) print noptr^M 49652 $1 = {0, <optimized out>, <optimized out>, <optimized out>}^M 49653 (gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr 49654 ... 49655 49656 The problem happens when evaluating this dwarf expression: 49657 ... 49658 <45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \ 49659 (DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8) 49660 ... 49661 49662 The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and 49663 the "generic type" has the size of an address on the target machine, which for 49664 target board unix/-m32 is 4 bytes. Consequently, the constant is abbreviated. 49665 49666 Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes 49667 large, and we hit this clause in rw_pieced_value: 49668 ... 49669 /* Use zeroes if piece reaches beyond stack value. */ 49670 if (p->offset + p->size > stack_value_size_bits) 49671 break; 49672 ... 49673 and consequently get a zero. 49674 49675 We could just add require is_target_64 to the test-case, but instead, add a 49676 32-bit case and require is_target_64 just for the 64-bit case. 49677 49678 Tested on x86_64-linux. 49679 496802023-05-12 Tom de Vries <tdevries@suse.de> 49681 49682 [gdb/testsuite] Make is_64_target more robust 49683 I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and 49684 with target board dwarf64 ran into: 49685 ... 49686 FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr 49687 ... 49688 due to is_target_64 failing because of: 49689 ... 49690 builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ 49691 -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \ 49692 is_64_target.c^M 49693 gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \ 49694 '-gdwarf -g64' for debug level^M 49695 compiler exited with status 1 49696 ... 49697 49698 The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64 49699 fails for both cases. 49700 49701 The reason that is_target_64 is failing for target board dwarf64, is because 49702 of using system compiler 7.5.0 which doesn't support -gdwarf64. 49703 49704 Fix this by making is_target_64 use nodebug instead of debug for compilation. 49705 49706 Tested on x86_64-linux. 49707 497082023-05-12 Tom de Vries <tdevries@suse.de> 49709 49710 [gdb/cli] Fix wrapping for TERM=ansi 49711 I. Auto-detected width (xterm vs. ansi) 49712 49713 Say we have a terminal with a width of 40 chars: 49714 ... 49715 $ echo $COLUMNS 49716 40 49717 ... 49718 49719 With TERM=xterm, we report a width of 40 chars: 49720 ... 49721 $ TERM=xterm gdb 49722 (gdb) show width 49723 Number of characters gdb thinks are in a line is 40. 49724 ... 49725 49726 And with TERM=ansi, a width of 39 chars: 49727 ... 49728 $ TERM=ansi gdb 49729 (gdb) show width 49730 Number of characters gdb thinks are in a line is 39. 49731 ... 49732 49733 Gdb uses readline to auto-detect screen size, and readline decides in the 49734 TERM=ansi case that the terminal does not have reliable auto-wrap, and 49735 consequently decides to hide the last terminal column from the readline user 49736 (in other words GDB), hence we get 39 instead of 40. 49737 49738 II. Types of wrapping 49739 49740 Looking a bit more in detail inside gdb, it seems there are two types of 49741 wrapping: 49742 - readline wrapping (in other words, prompt edit wrapping), and 49743 - gdb output wrapping (can be observed by issuing "info sources"). 49744 This type of wrapping attempts to wrap some of the gdb output earlier 49745 than the indicated width, to not break lines in inconvenient places. 49746 49747 III. Readline wrapping, auto-detected screen size 49748 49749 Let's investigate readline wrapping with the auto-detected screen widths. 49750 49751 First, let's try with xterm: 49752 ... 49753 $ TERM=xterm gdb 49754 (gdb) 7890123456789012345678901234567890 49755 123 49756 ... 49757 That looks as expected, wrapping occurs after 40 chars. 49758 49759 Now, let's try with ansi: 49760 ... 49761 $ TERM=ansi gdb 49762 (gdb) 78901234567890123456789012345678 49763 90123 49764 ... 49765 It looks like wrapping occurred after 38, while readline should be capable of 49766 wrapping after 39 chars. 49767 49768 This is caused by readline hiding the last column, twice. 49769 49770 In more detail: 49771 - readline detects the screen width: 40, 49772 - readline hides the last column, setting the readline screen width to 39, 49773 - readline reports 39 to gdb as screen width, 49774 - gdb sets its width setting to 39, 49775 - gdb sets readline screen width to 39, 49776 - readline hides the last column, again, setting the readline screen width to 49777 38. 49778 49779 This is reported as PR cli/30346. 49780 49781 IV. gdb output wrapping, auto-detected screen size 49782 49783 Say we set the terminal width to 56. With TERM=xterm, we have: 49784 ... 49785 /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, 49786 /data/vries/hello.c, 49787 ... 49788 but with TERM=ansi: 49789 ... 49790 /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, / 49791 data/vries/hello.c, 49792 ... 49793 49794 So what happened here? With TERM=ansi, the width setting is auto-detected to 49795 55, and gdb assumes the terminal inserts a line break there, which it doesn't 49796 because the terminal width is 56. 49797 49798 This is reported as PR cli/30411. 49799 49800 V. Fix PRs 49801 49802 Fix both mentioned PRs by taking into account the hidden column when readline 49803 reports the screen width in init_page_info, and updating chars_per_line 49804 accordingly. 49805 49806 Note that now we report the same width for both TERM=xterm and TERM=ansi, 49807 which is much clearer. 49808 49809 The point where readline respectively expects or ensures wrapping is still 49810 indicated by "maint info screen", for xterm: 49811 ... 49812 Number of characters readline reports are in a line is 40. 49813 ... 49814 and ansi: 49815 ... 49816 Number of characters readline reports are in a line is 39. 49817 ... 49818 49819 VI. Testing 49820 49821 PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp 49822 and gdb.tui/wrap-line.exp, so remove the KFAILs there. 49823 49824 I didn't manage to come up with a regression test for PR cli/30411. Perhaps 49825 that would be easier if we had a maintenance command that echoes its arguments 49826 while applying gdb output wrapping. 49827 49828 Tested on x86_64-linux. 49829 49830 PR cli/30346 49831 PR cli/30411 49832 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346 49833 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411 49834 498352023-05-12 Jan Beulich <jbeulich@suse.com> 49836 49837 x86: move a few more disassembler helper functions 49838 ... such that they wouldn't need forward declarations anymore. Note that 49839 append_seg() already was suitably placed. 49840 49841 x86: move get<N>() disassembler helper functions 49842 ... such that none of them would need forward declarations anymore. 49843 49844 x86: slightly simplify i386_parse_name() 49845 With the switch to parse_real_register() (commit 4faaa10f3fab) "bad_reg" 49846 cannot come back anymore. Drop the respective check. 49847 498482023-05-12 Jan Beulich <jbeulich@suse.com> 49849 49850 gas: equates of registers 49851 There are two problems: symbol_equated_p() doesn't recognize equates of 49852 registers, and S_CAN_BE_REDEFINED() goes by section rather than by 49853 expression type. Both together undermine .eqv and .equiv clearly meaning 49854 to guard the involved symbols against re-definition (both ways). 49855 49856 To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED() 49857 now checking for O_register, 49858 - for targets creating register symbols through symbol_{new,create}() -> 49859 symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips, 49860 mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have 49861 symbol_init() set their expressions to O_register, 49862 - x86'es parse_register() also can't go by section anymore when 49863 trying to "look through" equates; probably symbol_equated_p() should 49864 have been used there from the beginning, if only that had worked for 49865 equates of registers, 49866 - various targets need to "look through" equates when parsing insn 49867 operands (which also helps transitive forward equates); perhaps even 49868 more ought to, but many don't look to consider the possibility of 49869 register equates in the first place. 49870 49871 This was uncovered by code reported in PR gas/30274 (duplicating 49872 PR gas/30272), except that there .eqv was used when really .equ was 49873 meant. Therefore that bug report is addressed here only in so far as 49874 gas wouldn't crash anymore; the code there still won't assemble 49875 successfully, just that now the issues there are properly diagnosed. 49876 498772023-05-12 GDB Administrator <gdbadmin@sourceware.org> 49878 49879 Automatic date update in version.in 49880 498812023-05-11 Tom Tromey <tom@tromey.com> 49882 49883 Do not print <synthetic pointer> when piece is optimized out 49884 A user reported a bug where printing a certain array of integer types 49885 would result in the nonsensical: 49886 49887 (gdb) p l_126 49888 $1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>} 49889 49890 I tracked this down to some issues in the DWARF expression code. 49891 First, check_pieced_synthetic_pointer did not account for the 49892 situation where a location expression does not describe all the bits 49893 of a value -- in this case it returned true, meaning there is a 49894 synthetic pointer, but in fact these bits are optimized out. (It 49895 turns out this incorrect output had already been erroneously tested 49896 for as well.) 49897 49898 Next, rw_pieced_value did not mark these bits as optimized-out, 49899 either. 49900 49901 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296 49902 499032023-05-11 Aaron Merey <amerey@redhat.com> 49904 49905 gdb/testsuite: Match file size in gdb.debuginfod/crc_mismatch.exp 49906 gdb's debuginfod progress messages include the size of the file being 49907 downloaded if the size information is available at the time the message 49908 is printed. For example: 49909 49910 Downloading 10 MB separate debug info for /lib64/libxyz.so 49911 49912 This size information is omitted if it's not available at the time of 49913 printing: 49914 49915 Downloading separate debug info for /lib64/libxyz.so 49916 49917 A pattern in crc_mismatch.exp fails to be matched if a progress message 49918 includes a file size. Add a wildcard to the pattern so that it matches 49919 the progress message whether or not it includes the file size. 49920 499212023-05-11 Johnson Sun <j3.soon777@gmail.com> 49922 49923 Disable out-of-scope watchpoints 49924 Currently, when a local software watchpoint goes out of scope, GDB sets 49925 the watchpoint's disposition to `delete at next stop' and then normal 49926 stops (i.e., stop and wait for the next GDB command). When GDB normal 49927 stops, it automatically deletes the breakpoints with their disposition 49928 set to `delete at next stop'. 49929 49930 Suppose a Python script decides not to normal stop when a local 49931 software watchpoint goes out of scope, the watchpoint will not be 49932 automatically deleted even when its disposition is set to 49933 `delete at next stop'. 49934 49935 Since GDB single-steps the program and tests the watched expression 49936 after each instruction, not deleting the watchpoint causes the 49937 watchpoint to be hit many more times than it should, as reported in 49938 PR python/29603. 49939 49940 This was happening because the watchpoint is not deleted or disabled 49941 when going out of scope. 49942 49943 This commit fixes this issue by disabling the watchpoint when going out 49944 of scope. It also adds a test to ensure this feature isn't regressed in 49945 the future. 49946 49947 Calling `breakpoint_auto_delete' on all kinds of stops (in 49948 `fetch_inferior_event') seem to solve this issue, but is in fact 49949 inappropriate, since `breakpoint_auto_delete' goes over all breakpoints 49950 instead of just going through the bpstat chain (which only contains the 49951 breakpoints that were hit right now). 49952 49953 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29603 49954 Change-Id: Ia85e670b2bcba2799219abe4b6be3b582387e383 49955 499562023-05-11 Tom Tromey <tromey@adacore.com> 49957 49958 Add "scheduler-locking" to documentation index 49959 I noticed that "scheduler-locking" does not appear in the index of the 49960 gdb manual. This patch corrects this oversight. 49961 499622023-05-11 Joseph Myers <joseph@codesourcery.com> 49963 49964 Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128] 49965 This is one part of the fix for GCC PR109128, along with a 49966 corresponding GCC change. Without this patch, what happens in the 49967 linker, when an unused object in a .a file has offload data, is that 49968 elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p, 49969 which ends up calling the plugin's claim_file_handler, which then 49970 records the object as one with offload data. That is, the linker never 49971 decides to use the object in the first place, but use of this _p 49972 interface (called as part of trying to decide whether to use the 49973 object) results in the plugin deciding to use its offload data (and a 49974 consequent mismatch in the offload data present at runtime). 49975 49976 The new hook allows the linker plugin to distinguish calls to 49977 claim_file_handler that know the object is being used by the linker 49978 (from ldmain.c:add_archive_element), from calls that don't know it's 49979 being used by the linker (from elf_link_is_defined_archive_symbol); in 49980 the latter case, the plugin should avoid recording the object as one 49981 with offload data. 49982 49983 bfd/ 49984 * plugin.c (struct plugin_list_entry): Add claim_file_v2. 49985 (register_claim_file_v2): New. 49986 (try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2. 49987 (ld_plugin_object_p): Take second argument. 49988 (bfd_link_plugin_object_p): Update call to ld_plugin_object_p. 49989 (register_ld_plugin_object_p): Update argument prototype. 49990 (bfd_plugin_object_p): Update call to ld_plugin_object_p. 49991 * plugin.h (register_ld_plugin_object_p): Update argument 49992 prototype. 49993 49994 include/ 49995 * plugin.api.h (ld_plugin_claim_file_handler_v2) 49996 (ld_plugin_register_claim_file_v2) 49997 (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. 49998 (struct ld_plugin_tv): Add tv_register_claim_file_v2. 49999 50000 ld/ 50001 * plugin.c (struct plugin): Add claim_file_handler_v2. 50002 (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. 50003 (plugin_object_p): Add second argument. Update call to 50004 plugin_call_claim_file. 50005 (register_claim_file_v2): New. 50006 (set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2. 50007 (plugin_call_claim_file): Add argument known_used. 50008 (plugin_maybe_claim): Update call to plugin_object_p. 50009 * testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle 50010 LDPT_REGISTER_CLAIM_FILE_HOOK_V2. 50011 * testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d, 50012 testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d, 50013 testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d, 50014 testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d, 50015 testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d, 50016 testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d, 50017 testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d, 50018 testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d, 50019 testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d, 50020 testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d: 50021 Update test expectations. 50022 500232023-05-11 GDB Administrator <gdbadmin@sourceware.org> 50024 50025 Automatic date update in version.in 50026 500272023-05-10 Tom de Vries <tdevries@suse.de> 50028 50029 [gdb/tui] Fix tui compact-source a bit more 50030 Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp 50031 is incorrect: 50032 ... 50033 0 +-compact-source.c--------------------------------------------------------+ 50034 1 |___3_{ | 50035 2 |___4_ return 0; | 50036 3 |___5_} | 50037 4 |___6_ | 50038 5 |___7_ | 50039 6 |___8_ | 50040 7 |___9_ | 50041 8 +-------------------------------------------------------------------------+ 50042 ... 50043 50044 The last line number in the source file is 5, and there are 7 lines to display 50045 source lines, so if we'd scroll all the way down, the first line number in the 50046 source window would be 5, and the last one would be 11. 50047 50048 To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of 50049 ___4_, even though all line numbers currently in the src window (3-9) can be 50050 represented with only 1 digit. 50051 50052 Fix this in tui_source_window::set_contents, by updating the computation of 50053 max_line_nr: 50054 ... 50055 - int max_line_nr = std::max (lines_in_file, last_line_nr_in_window); 50056 + int max_line_nr = lines_in_file + nlines - 1; 50057 ... 50058 50059 Tested on x86_64-linux. 50060 50061 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 50062 Approved-By: Tom Tromey <tom@tromey.com> 50063 500642023-05-10 Andrew Burgess <aburgess@redhat.com> 50065 50066 gdb/rust: fix crash for expression debug with strings 50067 While working on another patch I did this: 50068 50069 (gdb) set debug expression 1 50070 (gdb) set language rust 50071 (gdb) p "foo" 50072 Operation: OP_AGGREGATE 50073 Type: &str 50074 50075 Fatal signal: Segmentation fault 50076 ... etc ... 50077 50078 The problem is that the second field of the rust_aggregate_operation 50079 is created as a nullptr, this can be seen in rust-parse.c. in the 50080 function rust_parser::parse_string(). 50081 50082 However, in expop.h, in the function dump_for_expression, we make the 50083 assumption that the expressions will never be nullptr. 50084 50085 I did consider moving the nullptr handling into a new function 50086 rust_aggregate_operation::dump, however, as the expression debug 50087 dumping code is not exercised as much as it might be, I would rather 50088 that this code be hardened and able to handle a nullptr without 50089 crashing, so I propose that we add nullptr handling into the general 50090 dump_for_expression function. The behaviour is now: 50091 50092 (gdb) set debug expression 1 50093 (gdb) set language rust 50094 (gdb) p "foo" 50095 Operation: OP_AGGREGATE 50096 Type: &str 50097 nullptr 50098 Vector: 50099 String: data_ptr 50100 Operation: UNOP_ADDR 50101 Operation: OP_STRING 50102 String: foo 50103 String: length 50104 Operation: OP_LONG 50105 Type: usize 50106 Constant: 3 50107 evaluation of this expression requires the target program to be active 50108 (gdb) 50109 50110 There's a new test to check for this case. 50111 50112 Reviewed-By: Tom Tromey <tom@tromey.com> 50113 501142023-05-10 Alan Modra <amodra@gmail.com> 50115 50116 Re: stack overflow in debug_write_type 50117 Apparently u.kindirect->slot can point at a NULL. 50118 50119 * debug.c (debug_write_type): Don't segfault on NULL indirect. 50120 501212023-05-10 Luca Bonissi <gcc@scarsita.it> 50122 50123 or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large 50124 PR 30422 50125 * elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs. 50126 501272023-05-10 Nick Clifton <nickc@redhat.com> 50128 50129 Add linker option to include local symbols in the linker map. 50130 PR 16566 50131 * ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section. 50132 * ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS. 50133 * lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals. 50134 * NEWS: Mention the new feature. 50135 * ld.h (struct ld_config_type): Add print_map_locals field. 50136 * ld.texi: Document the new command line option. 50137 * testsuite/ld-scripts/sizeof.s: Add a local symbol. 50138 * testsuite/ld-scripts/map-locals.d: New test control file. 50139 * testsuite/ld-scripts/map-address.exp: Run the new test. 50140 501412023-05-10 Tom de Vries <tdevries@suse.de> 50142 50143 [gdb/tui] Fix tui compact-source 50144 Consider a hello.c, with less than 10 lines: 50145 ... 50146 $ wc -l hello.c 50147 8 hello.c 50148 ... 50149 and compiled with -g into an a.out. 50150 50151 With compact-source off: 50152 ... 50153 $ gdb -q a.out \ 50154 -ex "set tui border-kind ascii" \ 50155 -ex "maint set tui-left-margin-verbose on" \ 50156 -ex "set tui compact-source off" \ 50157 -ex "tui enable" 50158 ... 50159 we get: 50160 ... 50161 +-./data/hello.c-----------------------+ 50162 |___000005_{ | 50163 |___000006_ printf ("hello\n"); | 50164 |___000007_ return 0; | 50165 |___000008_} | 50166 |___000009_ | 50167 |___000010_ | 50168 |___000011_ | 50169 ... 50170 but with compact-source on: 50171 ... 50172 +-./data/hello.c-----------------------+ 50173 |___5{ | 50174 |___6 printf ("hello\n"); | 50175 |___7 return 0; | 50176 |___8} | 50177 |___9 | 50178 |___1 | 50179 |___1 | 50180 ... 50181 50182 There are a couple of problems with compact-source. 50183 50184 First of all the documentation mentions: 50185 ... 50186 The default display uses more space for line numbers and starts the 50187 source text at the next tab stop; the compact display uses only as 50188 much space as is needed for the line numbers in the current file, and 50189 only a single space to separate the line numbers from the source. 50190 ... 50191 50192 The bit about the default display and the next tab stop looks incorrect. The 50193 source doesn't start at a tab stop, instead it uses a single space to separate 50194 the line numbers from the source. 50195 50196 Then the documentation mentions that there's single space in the compact 50197 display, but evidently that's missing. 50198 50199 Then there's the fact that the line numbers "10" and "11" are both abbreviated 50200 to "1" in the compact case. 50201 50202 The abbreviation is due to allocating space for <lines in source>, which is 50203 8 for this example, and takes a single digit. The line numbers though 50204 continue past the end of the file, so fix this by allocating space for 50205 max (<lines in source>, <last line in window>), which in this example takes 2 50206 digits. 50207 50208 The missing space is due to some confusion about what the "1" here in 50209 tui_source_window::set_contents represent: 50210 ... 50211 double l = log10 ((double) offsets->size ()); 50212 m_digits = 1 + (int) l; 50213 ... 50214 50215 It could be the trailing space that's mentioned in tui-source.h: 50216 ... 50217 /* How many digits to use when formatting the line number. This 50218 includes the trailing space. */ 50219 int m_digits; 50220 ... 50221 50222 Then again, it could be part of the calculation for the number of digits 50223 needed for printing. With this minimal example: 50224 ... 50225 int main () { 50226 for (int i = 8; i <= 11; ++i) { 50227 double l = log10 ((double) i); 50228 printf ("%d %d\n", i, (int)l); 50229 } 50230 return 0; 50231 } 50232 ... 50233 we get: 50234 ... 50235 $ ./a.out 50236 8 0 50237 9 0 50238 10 1 50239 11 1 50240 ... 50241 which shows that the number of digits needed for printing i is 50242 "1 + (int)log10 ((double) i)". 50243 50244 Fix this by introducing named variables needed_digits and trailing_space, each 50245 adding 1. 50246 50247 With the fixes, we get for compact-source on: 50248 ... 50249 +-./data/hello.c-----------------------+ 50250 |___05_{ | 50251 |___06_ printf ("hello\n"); | 50252 |___07_ return 0; | 50253 |___08_} | 50254 |___09_ | 50255 |___10_ | 50256 |___11_ | 50257 |... 50258 50259 Also fix the documentation and help text to actually match effect of 50260 compact-source. 50261 50262 Tested on x86_64-linux. 50263 502642023-05-10 GDB Administrator <gdbadmin@sourceware.org> 50265 50266 Automatic date update in version.in 50267 502682023-05-09 Dan Callaghan <dan.callaghan@morsemicro.com> 50269 50270 Support higher baud rates when they are defined 50271 On Linux at least, baud rate codes are defined up to B4000000. Allow the 50272 user to select them if they are present in the system headers. 50273 50274 Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e 50275 502762023-05-09 Simon Marchi <simon.marchi@efficios.com> 50277 50278 gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy 50279 Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a 50280 use-after-free in the breakpoints iterations (see below for full ASan 50281 report). This makes gdb.base/stale-infcall.exp fail when GDB is build 50282 with ASan. 50283 50284 check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints, 50285 possibly deleting the current breakpoint as well as related breakpoints. 50286 The problem arises when a breakpoint in the B->related_breakpoint chain 50287 is also B->next. In that case, deleting that related breakpoint frees 50288 the breakpoint that all_breakpoints_safe has saved. 50289 50290 The old code worked around that by manually changing B_TMP, which was 50291 the next breakpoint saved by the "safe iterator": 50292 50293 while (b->related_breakpoint != b) 50294 { 50295 if (b_tmp == b->related_breakpoint) 50296 b_tmp = b->related_breakpoint->next; 50297 delete_breakpoint (b->related_breakpoint); 50298 } 50299 50300 (Note that this seemed to assume that b->related_breakpoint->next was 50301 the same as b->next->next, not sure this is guaranteed.) 50302 50303 The new code kept the B_TMP variable, but it's not useful in that 50304 context. We can't go change the next breakpoint as saved by the safe 50305 iterator, like we did before. I suggest fixing that by saving the 50306 breakpoints to delete in a map and deleting them all at the end. 50307 50308 Here's the full ASan report: 50309 50310 (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1 50311 print infcall () 50312 ================================================================= 50313 ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60 50314 READ of size 8 at 0x611000034980 thread T0 50315 #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66 50316 #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84 50317 #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611 50318 #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881 50319 #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769 50320 #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023 50321 #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387 50322 #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42 50323 #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219 50324 #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 50325 #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 50326 #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217 50327 #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426 50328 #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650 50329 #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332 50330 #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 50331 #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 50332 #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 50333 #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 50334 #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 50335 #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 50336 #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 50337 #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 50338 #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 50339 #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 50340 #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 50341 #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 50342 #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 50343 #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 50344 #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779 50345 #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104 50346 #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250 50347 #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) 50348 #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192 50349 #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225 50350 #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155 50351 #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 50352 #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 50353 #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264 50354 #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412 50355 #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476 50356 #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320 50357 #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339 50358 #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32 50359 #44 0x7f5a7e43984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) 50360 #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) 50361 #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995) 50362 50363 0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50) 50364 freed by thread T0 here: 50365 #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164 50366 #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304 50367 #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404 50368 #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673 50369 #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881 50370 #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769 50371 #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023 50372 #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387 50373 #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42 50374 #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219 50375 #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 50376 #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 50377 #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217 50378 #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426 50379 #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650 50380 #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332 50381 #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 50382 #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 50383 #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 50384 #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 50385 #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 50386 #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 50387 #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 50388 #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 50389 #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 50390 #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 50391 #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 50392 #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 50393 #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 50394 #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 50395 50396 previously allocated by thread T0 here: 50397 #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95 50398 #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129 50399 #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169 50400 #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582 50401 #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260 50402 #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 50403 #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 50404 #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 50405 #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 50406 #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 50407 #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 50408 #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 50409 #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 50410 #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 50411 #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 50412 #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 50413 #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 50414 #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 50415 #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 50416 #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779 50417 #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104 50418 #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250 50419 #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) 50420 50421 Change-Id: Id00c17ab677f847fbf4efdf0f4038373668d3d88 50422 Approved-By: Tom Tromey <tom@tromey.com> 50423 504242023-05-09 Enze Li <enze.li@gmx.com> 50425 50426 Correct a spelling mistake in the binutils README file. 50427 504282023-05-09 Alan Modra <amodra@gmail.com> 50429 50430 stack overflow in debug_write_type 50431 Another fuzzer attack. This one was a "set" with elements using an 50432 indirect type pointing back at the set. The existing recursion check 50433 only prevented simple recursion. 50434 50435 * debug.c (struct debug_type_s): Add mark. 50436 (debug_write_type): Set mark and check before recursing into 50437 indirect types. 50438 504392023-05-09 Alan Modra <amodra@gmail.com> 50440 50441 alpha-vms reloc sanity check 50442 Stops fuzzed files triggering reads past the end of the reloc buffer. 50443 50444 * vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records. 50445 504462023-05-09 Alan Modra <amodra@gmail.com> 50447 50448 regen ld/Makefile.in 50449 504502023-05-09 GDB Administrator <gdbadmin@sourceware.org> 50451 50452 Automatic date update in version.in 50453 504542023-05-08 John Baldwin <jhb@FreeBSD.org> 50455 50456 gdbserver: Clear upper ZMM registers in the right location. 50457 This was previously clearing the upper 32 bytes of ZMM0-15 rather than 50458 ZMM16-31. 50459 50460 Approved-By: Simon Marchi <simon.marchi@efficios.com> 50461 504622023-05-08 John Baldwin <jhb@FreeBSD.org> 50463 50464 x86-fbsd-nat: Add missing public label. 50465 These two methods are both overrides of public methods in base 50466 classes. 50467 504682023-05-08 Felix Willgerodt <felix.willgerodt@intel.com> 50469 50470 gdb: Avoid warning for the jump command inside an inline function. 50471 When stopped inside an inline function, trying to jump to a different line 50472 of the same function currently results in a warning about jumping to another 50473 function. Fix this by taking inline functions into account. 50474 50475 Before: 50476 Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22 50477 22 a = a + x; /* inline-funct */ 50478 (gdb) j 21 50479 Line 21 is not in `function_inline(int)'. Jump anyway? (y or n) 50480 50481 After: 50482 Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22 50483 22 a = a + x; /* inline-funct */ 50484 (gdb) j 21 50485 Continuing at 0x400679. 50486 50487 Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21 50488 21 a += 1020 + a; /* increment-funct */ 50489 50490 This was regression-tested on X86-64 Linux. 50491 50492 Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com> 50493 Approved-By: Andrew Burgess <aburgess@redhat.com> 50494 504952023-05-08 Alan Modra <amodra@gmail.com> 50496 50497 pe.em and pep.em make_import_fixup 50498 This is a little cleanup that I made when looking at pr30343 that 50499 makes it more obvious that make_import_fixup in both files are 50500 identical (and in fact the new pep.em read_addend could be used in 50501 both files). 50502 50503 * emultempl/pep.em (read_addend): Extract from.. 50504 (make_import_fixup): ..here. 50505 * emultempl/pe.em (read_addend): Similarly. 50506 (make_import_fixup): Similarly. Add debug code from pep.em. 50507 505082023-05-08 Alan Modra <amodra@gmail.com> 50509 50510 PR30343, LTO ignores linker reference to _pei386_runtime_relocator 50511 Make a reference to _pei386_runtime_relocator before LTO recompilation. 50512 This is done regardless of whether such a reference will be used, 50513 because it can't be known whether it is needed before LTO. 50514 50515 I also found it necessary to enable long section names for the bfd 50516 created in make_runtime_pseudo_reloc, because otherwise when writing 50517 it out to the bfd-in-memory we get the section written as .rdata_r 50518 which when read back in leads to a linker warning ".rdata_r: section 50519 below image base" and likely runtime misbehaviour. 50520 50521 PR 30343 50522 * emultempl/pe.em (make_runtime_ref): New function. 50523 (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function. 50524 (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define. 50525 * emultempl/pep.em: Similarly to pe.em. 50526 * pe-dll.c (make_runtime_pseudo_reloc): Set long section names. 50527 505282023-05-08 GDB Administrator <gdbadmin@sourceware.org> 50529 50530 Automatic date update in version.in 50531 505322023-05-07 Tom Tromey <tom@tromey.com> 50533 50534 Remove parameter from select_source_symtab 50535 I noticed that select_source_symtab is only ever called with nullptr 50536 as an argument, so this patch removes the parameter and associated 50537 logic. 50538 50539 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 50540 505412023-05-07 Tom Tromey <tom@tromey.com> 50542 50543 Remove ALL_BREAKPOINTS_SAFE 50544 There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro; 50545 this patch replaces it with a for-each and an explicit temporary 50546 variable. 50547 50548 Remove ALL_DICT_SYMBOLS 50549 This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can 50550 be used. 50551 50552 Remove ALL_OBJFILE_OSECTIONS 50553 This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each 50554 can be used. 50555 50556 Rename objfile::sections 50557 I think objfile::sections makes sense as the name of the method to 50558 iterate over an objfile's sections, so this patch renames the existing 50559 field to objfile::sections_start in preparation for that. 50560 505612023-05-07 GDB Administrator <gdbadmin@sourceware.org> 50562 50563 Automatic date update in version.in 50564 505652023-05-06 Tom Tromey <tom@tromey.com> 50566 50567 Allow pretty-print of static members 50568 Python pretty-printers haven't applied to static members for quite 50569 some time. I tracked this down to the call to cp_print_value_fields 50570 in cp_print_static_field -- it doesn't let pretty-printers have a 50571 chance to print the value. This patch fixes the problem. 50572 50573 The way that static members are handled is very weird to me. I tend 50574 to think this should be done more globally, like in value_print. 50575 However, I haven't made any big change. 50576 50577 Reviewed-by: Keith Seitz <keiths@redhat.com> 50578 Tested-by: Keith Seitz <keiths@redhat.com> 50579 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057 50580 505812023-05-06 YunQiang Su <yunqiang.su@cipunited.com> 50582 50583 gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA 50584 It is added since 2016 by 50585 Add support for .MIPS.abiflags and .gnu.attributes sections 50586 b52717c0e104eb603e8189c3c0d3658ef5d903f5 50587 But never documented. 50588 505892023-05-06 GDB Administrator <gdbadmin@sourceware.org> 50590 50591 Automatic date update in version.in 50592 505932023-05-05 Tom Tromey <tromey@adacore.com> 50594 50595 Filter out types from DAP scopes request 50596 The DAP scopes request examines the symbols in a block tree, but 50597 neglects to omit types. This patch fixes the problem. 50598 505992023-05-05 Tom Tromey <tromey@adacore.com> 50600 50601 Use discrete_position in ada-valprint.c 50602 I found a couple of spots in ada-valprint.c that use an explicit loop, 50603 but where discrete_position could be used instead. 50604 50605 Reviewed-by: Keith Seitz <keiths@redhat.com> 50606 506072023-05-05 Andrew Burgess <aburgess@redhat.com> 50608 50609 gdb/python: add mechanism to manage Python initialization functions 50610 Currently, when we add a new python sub-system to GDB, 50611 e.g. py-inferior.c, we end up having to create a new function like 50612 gdbpy_initialize_inferior, which then has to be called from the 50613 function do_start_initialization in python.c. 50614 50615 In some cases (py-micmd.c and py-tui.c), we have two functions 50616 gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called 50617 from finalize_python which is also in python.c. 50618 50619 This commit proposes a mechanism to manage these initialization and 50620 finalization calls, this means that adding a new Python subsystem will 50621 no longer require changes to python.c or python-internal.h, instead, 50622 the initialization and finalization functions will be registered 50623 directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. 50624 50625 The initialization and finalization functions are managed through a 50626 new class gdbpy_initialize_file in python-internal.h. This class 50627 contains a single global vector of all the initialization and 50628 finalization functions. 50629 50630 In each Python sub-system we create a new gdbpy_initialize_file 50631 object, the object constructor takes care of registering the two 50632 callback functions. 50633 50634 Now from python.c we can call static functions on the 50635 gdbpy_initialize_file class which take care of walking the callback 50636 list and invoking each callback in turn. 50637 50638 To slightly simplify the Python sub-system files I added a new macro 50639 GDBPY_INITIALIZE_FILE, which hides the need to create an object. We 50640 can now just do this: 50641 50642 GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); 50643 50644 One possible problem with this change is that there is now no 50645 guaranteed ordering of how the various sub-systems are initialized (or 50646 finalized). To try and avoid dependencies creeping in I have added a 50647 use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is 50648 the same environment variable used in the generated init.c file. 50649 50650 Just like with init.c, when this environment variable is set we 50651 reverse the list of Python initialization (and finalization) 50652 functions. As there is already a test that starts GDB with the 50653 environment variable set then this should offer some level of 50654 protection against dependencies creeping in - though for full 50655 protection I guess we'd need to run all gdb.python/*.exp tests with 50656 the variable set. 50657 50658 I have tested this patch with the environment variable set, and saw no 50659 regressions, so I think we are fine right now. 50660 50661 One other change of note was for gdbpy_initialize_gdb_readline, this 50662 function previously returned void. In order to make this function 50663 have the correct signature I've updated its return type to int, and we 50664 now return 0 to indicate success. 50665 50666 All of the other initialize (and finalize) functions have been made 50667 static within their respective sub-system files. 50668 50669 There should be no user visible changes after this commit. 50670 506712023-05-05 Andrew Burgess <aburgess@redhat.com> 50672 50673 gdb/testsuite: more newline pattern cleanup 50674 After this commit: 50675 50676 commit e2f620135d92f7cd670af4e524fffec7ac307666 50677 Date: Thu Mar 30 13:26:25 2023 +0100 50678 50679 gdb/testsuite: change newline patterns used in gdb_test 50680 50681 It was pointed out in PR gdb/30403 that the same patterns can be found 50682 in other lib/gdb.exp procs and that it would probably be a good idea 50683 if these procs remained in sync with gdb_test. Actually, the bug 50684 specifically calls out gdb_test_multiple when using with '-wrap', but 50685 I found a couple of other locations in gdb_continue_to_breakpoint, 50686 gdb_test_multiline, get_valueof, and get_local_valueof. 50687 50688 In all these locations one or both of the following issues are 50689 addressed: 50690 50691 1. A leading pattern of '[\r\n]*' is pointless. If there is a 50692 newline it will be matched, but if there is not then the testsuite 50693 doesn't care. Also, as expect is happy to skip non-matched output 50694 at the start of a pattern, if there is a newline expect is happy to 50695 skip over it before matching the rest. As such, this leading 50696 pattern is removed. 50697 50698 2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow 50699 unexpected blank lines at the end of a command's output, but also, 50700 if the pattern from the test script ends with a '\r', '\n', or '.' 50701 then these will partially match the trailing newline, with the 50702 remainder of the newline matched by the pattern from gdb.exp. This 50703 split matching doesn't add any value, it's just something that has 50704 appeared as a consequence of how gdb.exp was originally written. In 50705 this case the '\[\r\n\]*' is replaced with '\r\n'. 50706 50707 I've rerun the testsuite and fixed the regressions that I saw, these 50708 were places where GDB emits a blank line at the end of the command 50709 output, which we now need to explicitly match in the test script, this 50710 was for: 50711 50712 gdb.dwarf2/dw2-out-of-range-end-of-seq.exp 50713 gdb.guile/guile.exp 50714 gdb.python/python.exp 50715 50716 Or a location where the test script was matching part of the newline 50717 sequence, while gdb.exp was previously matching the remainder of the 50718 newline sequence. Now we rely on gdb.exp to match the complete 50719 newline sequence, this was for: 50720 50721 gdb.base/commands.exp 50722 50723 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403 50724 507252023-05-05 Tom de Vries <tdevries@suse.de> 50726 50727 [gdb/testsuite] Generate long string in gdb.base/page.exp 50728 I noticed in gdb.base/page.exp: 50729 ... 50730 set fours [string repeat 4 40] 50731 ... 50732 but then shortly afterwards: 50733 ... 50734 [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444] 50735 ... 50736 50737 Summarize the long string in the same way using string repeat: 50738 ... 50739 [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]] 50740 ... 50741 50742 Tested on x86_64-linux. 50743 507442023-05-05 Andrew Burgess <aburgess@redhat.com> 50745 50746 gdb/testsuite: tighten patterns in build-id-no-debug-warning.exp 50747 Tighten the expected output pattern in the test script: 50748 50749 gdb.debuginfod/build-id-no-debug-warning.exp 50750 50751 While working on some other patch I broke GDB such that this warning: 50752 50753 warning: "FILENAME": separate debug info file has no debug info 50754 50755 (which is generated in build-id.c) didn't actually include the 50756 FILENAME any more -- yet this test script continued to pass. It turns 50757 out that this script doesn't actually check for FILENAME. 50758 50759 This commit extends the test pattern to check for the full warning 50760 string, including FILENAME, and also removes some uses of '.*' to make 50761 the test stricter. 50762 507632023-05-05 Tom Tromey <tom@tromey.com> 50764 50765 Simplify decode_locdesc 50766 While looking into another bug, I noticed that the DWARF cooked 50767 indexer picks up an address for this symbol: 50768 50769 <1><82>: Abbrev Number: 2 (DW_TAG_variable) 50770 <83> DW_AT_specification: <0x9f> 50771 <87> DW_AT_location : 10 byte block: e 0 0 0 0 0 0 0 0 e0 (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown) 50772 <92> DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E 50773 50774 This happens because decode_locdesc allows the use of 50775 DW_OP_GNU_push_tls_address. 50776 50777 This didn't make sense to me. I looked into it a bit more, and I 50778 think decode_locdesc is used in three ways: 50779 50780 1. Find a constant address of a symbol that happens to be encoded as a 50781 location expression. 50782 50783 2. Find the offset of a function in a virtual table. (This one should 50784 probably be replaced by code to just evaluate the expression in 50785 gnu-v3-abi.c -- but there's no point yet because no compiler 50786 actually seems to emit correct DWARF here, see the bug linked in 50787 the patch.) 50788 50789 3. Find the offset of a field, if the offset is a constant. 50790 50791 None of these require TLS. 50792 50793 This patch simplifies decode_locdesc by removing any opcodes that 50794 don't fit into the above. It also changes the API a little, to make 50795 it less difficult to use. 50796 50797 Regression tested on x86-64 Fedora 36. 50798 507992023-05-05 Tom Tromey <tom@tromey.com> 50800 50801 Simplify auto_load_expand_dir_vars and remove substitute_path_component 50802 This simplifies auto_load_expand_dir_vars to first split the string, 50803 then do any needed substitutions. This was suggested by Simon, and is 50804 much simpler than the current approach. 50805 50806 Then this patch also removes substitute_path_component, as it is no 50807 longer called. This is nice because it helps with the long term goal 50808 of removing utils.h. 50809 50810 Regression tested on x86-64 Fedora 36. 50811 508122023-05-05 Tom de Vries <tdevries@suse.de> 50813 50814 [gdb/testsuite] Add gdb.base/wrap-line.exp 50815 Add a test-case that tests prompt edit wrapping in CLI, both 50816 for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width. 50817 50818 In the TERM=ansi case with auto-detected width we run into PR cli/30346, so 50819 add a KFAIL for that failure mode. 50820 50821 Tested on x86_64-linux. 50822 508232023-05-05 Tom de Vries <tdevries@suse.de> 50824 50825 [gdb/testsuite] Add gdb.tui/wrap-line.exp 50826 Add a test-case that tests prompt edit wrapping behaviour in the tuiterm, both 50827 for CLI and TUI, both with auto-detected and hard-coded width. 50828 50829 In the CLI case with auto-detected width we run into PR cli/30411, so add a 50830 KFAIL for that failure mode. 50831 50832 Tested on x86_64-linux. 50833 508342023-05-05 Nick Clifton <nickc@redhat.com> 50835 50836 Debug info is lost for functions only called from functions marked with cmse_nonsecure_entr 50837 PR 30354 50838 * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies. 50839 508402023-05-05 GDB Administrator <gdbadmin@sourceware.org> 50841 50842 Automatic date update in version.in 50843 508442023-05-04 Bruno Larsen <blarsen@redhat.com> 50845 50846 Revert "gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp" 50847 This reverts commit 476410b3bca1389ee69e9c8fa18aaee16793a56d. 50848 50849 One of Simon's recent commits (2a740b3ba4c9f39c86dd75e0914ee00942cab471) 50850 changed the way recording a remote target works and fixed the underlying 50851 issue of the bug, so the KFails can be removed from the test. 50852 50853 Approved-By: Tom Tromey <tom@tromey.com> 50854 508552023-05-04 Gareth Rees <grees@undo.io> 50856 50857 Don't treat references to compound values as "simple". 50858 SUMMARY 50859 50860 The '--simple-values' argument to '-stack-list-arguments' and similar 50861 GDB/MI commands does not take reference types into account, so that 50862 references to arbitrarily large structures are considered "simple" and 50863 printed. This means that the '--simple-values' argument cannot be used 50864 by IDEs when tracing the stack due to the time taken to print large 50865 structures passed by reference. 50866 50867 DETAILS 50868 50869 Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals', 50870 '-stack-list-variables' and so on) take a PRINT-VALUES argument which 50871 may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2). 50872 In the '--simple-values' case, the command is supposed to print the 50873 name, type, and value of variables with simple types, and print only the 50874 name and type of variables with compound types. 50875 50876 The '--simple-values' argument ought to be suitable for IDEs that need 50877 to update their user interface with the program's call stack every time 50878 the program stops. However, it does not take C++ reference types into 50879 account, and this makes the argument unsuitable for this purpose. 50880 50881 For example, consider the following C++ program: 50882 50883 struct s { 50884 int v[10]; 50885 }; 50886 50887 int 50888 sum(const struct s &s) 50889 { 50890 int total = 0; 50891 for (int i = 0; i < 10; ++i) total += s.v[i]; 50892 return total; 50893 } 50894 50895 int 50896 main(void) 50897 { 50898 struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } }; 50899 return sum(s); 50900 } 50901 50902 If we start GDB in MI mode and continue to 'sum', the behaviour of 50903 '-stack-list-arguments' is as follows: 50904 50905 (gdb) 50906 -stack-list-arguments --simple-values 50907 ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}] 50908 50909 Note that the value of the argument 's' was printed, even though 's' is 50910 a reference to a structure, which is not a simple value. 50911 50912 See https://github.com/microsoft/MIEngine/pull/673 for a case where this 50913 behaviour caused Microsoft to avoid the use of '--simple-values' in 50914 their MIEngine debug adapter, because it caused Visual Studio Code to 50915 take too long to refresh the call stack in the user interface. 50916 50917 SOLUTIONS 50918 50919 There are two ways we could fix this problem, depending on whether we 50920 consider the current behaviour to be a bug. 50921 50922 1. If the current behaviour is a bug, then we can update the behaviour 50923 of '--simple-values' so that it takes reference types into account: 50924 that is, a value is simple if it is neither an array, struct, or 50925 union, nor a reference to an array, struct or union. 50926 50927 In this case we must add a feature to the '-list-features' command so 50928 that IDEs can detect that it is safe to use the '--simple-values' 50929 argument when refreshing the call stack. 50930 50931 2. If the current behaviour is not a bug, then we can add a new option 50932 for the PRINT-VALUES argument, for example, '--scalar-values' (3), 50933 that would be suitable for use by IDEs. 50934 50935 In this case we must add a feature to the '-list-features' command 50936 so that IDEs can detect that the '--scalar-values' argument is 50937 available for use when refreshing the call stack. 50938 50939 PATCH 50940 50941 This patch implements solution (1) as I think the current behaviour of 50942 not printing structures, but printing references to structures, is 50943 contrary to reasonable expectation. 50944 50945 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554 50946 509472023-05-04 Nick Clifton <nickc@redhat.com> 50948 50949 Stop the linker from loosing the entry point for COFF/PE code when compiling with LTO enabled. 50950 PR 30300 50951 * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically. 50952 * emultempl/pe.em (set_entry_point): Likewise. 50953 509542023-05-04 Dimitar Dimitrov <dimitar@dinux.eu> 50955 50956 ld: pru: Place exception-handling sections correctly 50957 * scripttempl/pru.sc (OUTPUT_SECTION_ALIGN): New helper variable to place at end of DMEM output sections. 50958 (.data): Use the helper variable. 50959 (.eh_frame): New output section. 50960 (.gnu_extab): Ditto. 50961 (.gcc_except_table): Ditto. 50962 (.resource_table): Use the helper variable. 50963 509642023-05-04 Jan Beulich <jbeulich@suse.com> 50965 50966 RISC-V: tighten post-relocation-operator separator expectation 50967 As per the spec merely a blank isn't okay as a separator, the operand 50968 to the relocation function ought to be parenthesized. Enforcing this 50969 then also eliminates an inconsistency in that 50970 50971 lui t0, %hi sym 50972 lui t0, %hi 0x1000 50973 50974 were accepted, but 50975 50976 lui t0, %hi +sym 50977 lui t0, %hi -0x1000 50978 50979 were not. 50980 509812023-05-04 Ilya Leoshkevich <iii@linux.ibm.com> 50982 50983 gas: fix building tc-bpf.c on s390x 50984 char is unsigned on s390x, so there are a lot of warnings like: 50985 50986 gas/config/tc-bpf.c: In function 'get_token': 50987 gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits] 50988 900 | if (ch == EOF || len > MAX_TOKEN_SZ) 50989 | ^~ 50990 50991 Change its type to int, like in the other similar code. 50992 50993 There is also: 50994 50995 gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized] 50996 735 | dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]); 50997 | ~~~~~~~~~~~^~~~~~~~~~ 50998 50999 -Wmaybe-uninitialized doesn't seem to understand the FSM; just 51000 initialize bpf_endianness to silence it. Add an assertion to 51001 build_bpf_endianness() in order to catch potential bugs. 51002 510032023-05-04 YunQiang Su <yunqiang.su@cipunited.com> 51004 51005 MIPS: revert "default r6 if vendor is img" 51006 In commit: 9171de358f230b64646bbb525a74e5f8e3dbe0dc, 51007 The default output is set to r6 if the vendor is img, 51008 It is ugly and should not be in upstream. 51009 51010 Let's revert it. 51011 510122023-05-04 GDB Administrator <gdbadmin@sourceware.org> 51013 51014 Automatic date update in version.in 51015 510162023-05-03 Tom de Vries <tdevries@suse.de> 51017 51018 [gdb/build] Fix frame_list position in frame.c 51019 In commit 995a34b1772 ("Guard against frame.c destructors running before 51020 frame-info.c's") the following problem was addressed. 51021 51022 The frame_info_ptr destructor: 51023 ... 51024 ~frame_info_ptr () 51025 { 51026 frame_list.erase (frame_list.iterator_to (*this)); 51027 } 51028 ... 51029 uses frame_list, which is a static member of class frame_info_ptr, 51030 instantiated in frame-info.c: 51031 ... 51032 intrusive_list<frame_info_ptr> frame_info_ptr::frame_list; 51033 ... 51034 51035 Then there's a static frame_info_pointer variable named selected_frame in 51036 frame.c: 51037 ... 51038 static frame_info_ptr selected_frame; 51039 ... 51040 51041 Because the destructor of selected_frame uses frame_list, its destructor needs 51042 to be called before the destructor of frame_list. 51043 51044 But because they're in different compilation units, the initialization order and 51045 consequently destruction order is not guarantueed. 51046 51047 The commit fixed this by handling the case that the destructor of frame_list 51048 is called first, adding a check on is_linked (): 51049 ... 51050 ~frame_info_ptr () 51051 { 51052 - frame_list.erase (frame_list.iterator_to (*this)); 51053 + /* If this node has static storage, it may be deleted after 51054 + frame_list. Attempting to erase ourselves would then trigger 51055 + internal errors, so make sure we are still linked first. */ 51056 + if (is_linked ()) 51057 + frame_list.erase (frame_list.iterator_to (*this)); 51058 } 51059 ... 51060 51061 However, since then frame_list has been moved into frame.c, and 51062 initialization/destruction order is guarantueed inside a compilation unit. 51063 51064 Revert aforementioned commit, and fix the destruction order problem by moving 51065 frame_list before selected_frame. 51066 51067 Reverting the commit is another way of fixing the already fixed 51068 Wdangling-pointer warning reported in PR build/30413, in a different way than 51069 commit 9b0ccb1ebae ("Pass const frame_info_ptr reference for 51070 skip_[language_]trampoline"). 51071 51072 Approved-By: Simon Marchi <simon.marchi@efficios.com> 51073 Tested on x86_64-linux. 51074 PR build/30413 51075 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413 51076 510772023-05-03 Lancelot SIX <lancelot.six@amd.com> 51078 51079 gdb/show_args_command: print to the ui_file argument 51080 The show_args_command uses gdb_printf without specifying the ui_file. 51081 This means that it prints to gdb_stdout instead of the stream given as 51082 an argument to the function. 51083 51084 This commit fixes this. 51085 51086 Reviewed-By: Tom Tromey <tom@tromey.com> 51087 510882023-05-03 Oleg Tolmatcev <oleg.tolmatcev@gmail.com> 51089 51090 Make ar faster 51091 * archive.c (_bfd_write_archive_contents): Use a larger buffer in order to improve efficiency. 51092 510932023-05-03 Mark Wielaard <mark@klomp.org> 51094 51095 Pass const frame_info_ptr reference for skip_[language_]trampoline 51096 g++ 13.1.1 produces a -Werror=dangling-pointer= 51097 51098 In file included from ../../binutils-gdb/gdb/frame.h:75, 51099 from ../../binutils-gdb/gdb/symtab.h:40, 51100 from ../../binutils-gdb/gdb/language.c:33: 51101 In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’, 51102 inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24, 51103 inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26, 51104 inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49: 51105 gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=] 51106 415 | m_back = &elem; 51107 | ~~~~~~~^~~~~~~ 51108 gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’: 51109 gdb/language.c:530:49: note: ‘<anonymous>’ declared here 51110 530 | CORE_ADDR real_pc = lang->skip_trampoline (frame, pc); 51111 | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ 51112 gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here 51113 359 | static intrusive_list<frame_info_ptr> frame_list; 51114 | ^~~~~~~~~~ 51115 51116 Each new frame_info_ptr is being pushed on a static frame list and g++ 51117 cannot see why that is safe in case the frame_info_ptr is created and 51118 destroyed immediately when passed as value. 51119 51120 It isn't clear why only in this one place g++ sees the issue (probably 51121 because it can inline enough code in this specific case). 51122 51123 Since passing the frame_info_ptr as const reference is cheaper, use 51124 that as workaround for this warning. 51125 51126 PR build/30413 51127 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413 51128 51129 Tested-by: Kevin Buettner <kevinb@redhat.com> 51130 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 51131 Reviewed-by: Tom Tromey <tom@tromey.com> 51132 511332023-05-03 Oleg Tolmatcev <oleg.tolmatcev@gmail.com> 51134 51135 Improve the speed of computing checksums for COFF binaries. 51136 * coffcode.h (coff_read_word_from_buffer): New function. 51137 * coffcode.h (COFF_CHECKSUM_BUFFER_SIZE): New constant. 51138 * coffcode.h (coff_compute_checksum): Improve speed by reducing the number of seeks and reads used. 51139 511402023-05-03 Alan Modra <amodra@gmail.com> 51141 51142 Remove unused args from bfd_make_debug_symbol 51143 The ptr and size args are unused. Make the function look the same as 51144 bfd_make_empty_symbol. 51145 51146 Generated docs and include files 51147 bfd/doc/chew.c extracts documentation from source code comments 51148 annotated with keywords, and generates much of bfd.h and libbfd.h from 51149 those same comments. The docs have suffered from people (me too) 51150 adding things like CODE_FRAGMENT to the source to put code into bfd.h 51151 without realising that CODE_FRAGMENT also puts @example around said 51152 code into the docs. So we have random senseless things in the docs. 51153 This patch fixes that problem (well, the senseless things from 51154 CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a 51155 few chew.c features. libbfd.h now automatically gets ATTRIBUTE_HIDDEN 51156 prototypes, and indentation in bfd.h and libbfd.h is better. 51157 511582023-05-03 Alan Modra <amodra@gmail.com> 51159 51160 Move bfd_alloc, bfd_zalloc and bfd_release to libbfd.c 51161 These functions don't belong in opncls.c. 51162 51163 * libbfd-in.h (bfd_release): Delete prototype. 51164 * opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to.. 51165 * libbfd.c: ..here. Include objalloc.c and provide bfd_release 51166 with a FUNCTION comment. 51167 * bfd-in2.h: Regenerate. 51168 * libbfd.h: Regenerate. 51169 511702023-05-03 Alan Modra <amodra@gmail.com> 51171 51172 Move bfd_elf_bfd_from_remote_memory to opncls.c 51173 bfd_elf_bfd_from_remote_memory is just a wrapper, and the function 51174 could be implemented for other formats. Move it to opncls.c because 51175 it acts a little like some of the other bfd_open* routines. Also give 51176 it the usual FUNCTION etc. comment so prototypes and docs are handled 51177 automatically. 51178 51179 * elf.c (bfd_elf_bfd_from_remote_memory): Move to.. 51180 * opncls.c: ..here, add FUNCTION comment. 51181 * bfd-in.h (bfd_elf_bfd_from_remote_memory): Delete prototype. 51182 * bfd-in2.h: Regenerate. 51183 511842023-05-03 Alan Modra <amodra@gmail.com> 51185 51186 hash.c: replace some unsigned long with unsigned int 51187 * hash.c (higher_prime_number): Use uint32_t param, return value, 51188 tables and variables. 51189 (bfd_default_hash_table_size): Make it an unsigned int. 51190 (bfd_hash_set_default_size): Use unsigned int param and return. 51191 * bfd-in.h (bfd_hash_set_default_size): Update prototype. 51192 * bfd-in2.h: Regenerate. 51193 51194 libbfc.c: Use stdint types for unsigned char and unsigned long 51195 * libbfd.c (bfd_put_8): Use bfd_byte rather than unsigned char. 51196 (bfd_get_8, bfd_get_signed_8): Likewise. 51197 (_bfd_read_unsigned_leb128, _bfd_safe_read_leb128): Likewise. 51198 (_bfd_read_signed_leb128): Likewise. 51199 (bfd_getb24, bfd_getl24): Replace unsigned long with uint32_t. 51200 (bfd_getb32, bfd_getl32): Likewise. 51201 (bfd_getb_signed_32, bfd_getl_signed_32): Likewise. 51202 512032023-05-03 Alan Modra <amodra@gmail.com> 51204 51205 Change signature of bfd crc functions 51206 The crc calculated is 32 bits. Replace uses of unsigned long with 51207 uint32_t. Also use bfd_byte* for buffers. 51208 51209 bfd/ 51210 * opncls.c (bfd_calc_gnu_debuglink_crc32): Use stdint types. 51211 (bfd_get_debug_link_info_1, bfd_get_debug_link_info): Likewise. 51212 (separate_debug_file_exists, bfd_follow_gnu_debuglink): Likewise. 51213 (bfd_fill_in_gnu_debuglink_section): Likewise. 51214 * bfd-in2.h: Regenerate. 51215 gdb/ 51216 * auto-load.c (auto_load_objfile_script): Update type of 51217 bfd_get_debug_link_info argument. 51218 * symfile.c (find_separate_debug_file_by_debuglink): Likewise. 51219 * gdb_bfd.c (get_file_crc): Update type of 51220 bfd_calc_gnu_debuglink_crc32 argument. 51221 512222023-05-03 Alan Modra <amodra@gmail.com> 51223 51224 _bfd_mips_elf_lo16_reloc vallo comment 51225 This explains exactly why the high reloc adjustment is as it is, 51226 replacing the rather nebulous existing comment. I've also changed the 51227 expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better 51228 matches part of the standard 16-bit sign extension (resulting in 51229 exactly the same value), and hoisted the calculation out of the loop. 51230 51231 * elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo 51232 comment. Hoist calculation out of loop. 51233 512342023-05-02 Alexandra Hájková <ahajkova@redhat.com> 51235 51236 gdb.base/watchpoint-unaligned.exp: Always initialize wpoffset_to_wpnum 51237 Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types. 51238 51239 ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp 51240 ERROR: can't read "wpoffset_to_wpnum(1)": no such element in array 51241 ERROR: tcl error code TCL READ VARNAME 51242 ERROR: tcl error info: 51243 can't read "wpoffset_to_wpnum(1)": no such element in array 51244 while executing 51245 51246 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340 51247 51248 Reviewed-by: Luis Machado <luis.machado@arm.com> 51249 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 51250 512512023-05-02 Mark Wielaard <mark@klomp.org> 51252 51253 xcoffread.c: Fix -Werror=dangling-pointer= issue with main_subfile. 51254 GCC 13 points out that main_subfile has local function scope, but a 51255 pointer to it is assigned to the global inclTable array subfile 51256 element field: 51257 51258 In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’, 51259 inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19, 51260 inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1: 51261 xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=] 51262 629 | inclTable[ii].subfile = &main_subfile; 51263 | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ 51264 xcoffread.c: In function ‘void aix_process_linenos(objfile*)’: 51265 xcoffread.c:579:18: note: ‘main_subfile’ declared here 51266 579 | struct subfile main_subfile; 51267 | ^~~~~~~~~~~~ 51268 xcoffread.c:496:19: note: ‘inclTable’ declared here 51269 496 | static InclTable *inclTable; /* global include table */ 51270 | ^~~~~~~~~ 51271 51272 Fix this by making main_subfile file static. And allocate and 51273 deallocated together with inclTable in allocate_include_entry and 51274 xcoff_symfile_finish. Adjust the use of main_subfile in 51275 process_linenos to take a pointer to the subfile. 51276 512772023-05-02 Tom de Vries <tdevries@suse.de> 51278 51279 [gdb/testsuite] Use set in lmap in gdb.dwarf2/dw2-abs-hi-pc.exp 51280 In gdb.dwarf2/dw2-abs-hi-pc.exp we do: 51281 ... 51282 set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }] 51283 ... 51284 51285 The use of expr is not idiomatic. Fix this by using set instead: 51286 ... 51287 set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }] 51288 ... 51289 51290 Reported-By: Tom Tromey <tom@tromey.com> 51291 Reviewed-By: Andreas Schwab <schwab@suse.de> 51292 512932023-05-02 Aditya Kamath <Aditya.Kamath1@ibm.com> 51294 51295 Fix Assertion pid != 0 failure in AIX. 51296 In AIX if there is a main and a thread created from it , then once the 51297 program completed execution and goes to pd_disable () inferior_ptid 51298 had pid 0 leading to an assertion failure while finding the thread's data 51299 in aix-thread.c file. 51300 51301 This patch is a fix for the same. 51302 513032023-05-02 Tom Tromey <tom@tromey.com> 51304 51305 Remove error_stream 51306 error_stream is trivial and only used in a couple of spots in 51307 breakpoint.c. This patch removes it in favor of just writing it out 51308 at the spots where it was used. 51309 513102023-05-02 Nick Clifton <nickc@redhat.com> 51311 51312 Remove Dimity Diky as MSP430 maintainer. 51313 513142023-05-02 Andrew Burgess <aburgess@redhat.com> 51315 51316 gdb/testsuite: compile gdb.linespec/cp-completion-aliases.exp as C++ 51317 Noticed in passing that the prepare_for_testing call in 51318 gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag, 51319 despite this being a C++ test. 51320 51321 I guess, as the source file has the '.cc' extension, all the compilers 51322 are doing the right thing anyway -- the source file uses templates, so 51323 is definitely being compiled as C++. 51324 51325 I noticed this when I tried to set CXX_FOR_TARGET (but not 51326 CC_FOR_TARGET) and spotted that this script was still using the C 51327 compiler. 51328 51329 Fixed in this commit by adding the 'c++' flag for prepare_for_testing. 51330 513312023-05-02 GDB Administrator <gdbadmin@sourceware.org> 51332 51333 Automatic date update in version.in 51334 513352023-05-01 Tom Tromey <tromey@adacore.com> 51336 51337 Document DAP 'launch' parameter 51338 The Debugger Adapter Protocol defines a "launch" request but leaves 51339 the parameters up to the implementation: 51340 51341 Since launching is debugger/runtime specific, the arguments for 51342 this request are not part of this specification. 51343 51344 This patch adds some documentation for the parameter GDB currently 51345 defines. Note that I plan to add more parameters here, and perhaps 51346 there will be other extensions in time as well. 51347 51348 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 51349 513502023-05-01 Simon Marchi <simon.marchi@efficios.com> 51351 51352 gdb: remove ui_interp_info 51353 I don't think that having struct ui_interp_info separated from struct ui 51354 is very useful. As of today, it looks like an unnecessary indirection 51355 layer. Move the contents of ui_interp_info directly into struct ui, and 51356 update all users. 51357 51358 Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521 51359 513602023-05-01 Simon Marchi <simon.marchi@efficios.com> 51361 51362 gdb: store interps in an intrusive_list 51363 Use intrusive_list, instead of hand-made linked list. 51364 51365 Change-Id: Idc857b40dfa3e3c35671045898331cca2c928097 51366 513672023-05-01 Simon Marchi <simon.marchi@efficios.com> 51368 51369 gdb: move struct ui and related things to ui.{c,h} 51370 I'd like to move some things so they become methods on struct ui. But 51371 first, I think that struct ui and the related things are big enough to 51372 deserve their own file, instead of being scattered through top.{c,h} and 51373 event-top.c. 51374 51375 Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc 51376 513772023-05-01 Tom Tromey <tromey@adacore.com> 51378 51379 Turn set_inferior_args_vector into method of inferior 51380 This patch turns set_inferior_args_vector into an overload of 51381 inferior::set_args. 51382 51383 Regression tested on x86-64 Fedora 36. 51384 513852023-05-01 Tom Tromey <tromey@adacore.com> 51386 51387 Remove evaluate_type 51388 Like evaluate_expression, evaluate_type is also just a simple wrapper. 51389 Removing it makes the code a little nicer. 51390 51391 Remove evaluate_expression 51392 evaluate_expression is just a little wrapper for a method on 51393 expression. Removing it also removes a lot of ugly (IMO) calls to 51394 get(). 51395 51396 Remove op_name 51397 op_name is only needed in a single place, so remove it and inline it 51398 there. 51399 514002023-05-01 Tom Tromey <tromey@adacore.com> 51401 51402 Fix crash in Rust expression parser 51403 A user found that an array expression with just a single value (like 51404 "[23]") caused the Rust expression parser to crash. 51405 51406 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30410 51407 514082023-05-01 Tom Tromey <tom@tromey.com> 51409 51410 Replace field_is_static with a method 51411 This changes field_is_static to be a method on struct field, and 51412 updates all the callers. Most of this patch was written by script. 51413 51414 Regression tested on x86-64 Fedora 36. 51415 514162023-05-01 GDB Administrator <gdbadmin@sourceware.org> 51417 51418 Automatic date update in version.in 51419 514202023-04-30 Tom de Vries <tdevries@suse.de> 51421 51422 [gdb/tui] Fix TUI resizing for TERM=ansi 51423 With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118 51424 (maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't 51425 fix) and a message: 51426 ... 51427 @@ resize done 0, size = 77x20 51428 ... 51429 with the resulting width being 77 instead of the expected 78. 51430 51431 [ The discrepancy also manifests in CLI, filed as PR30346. ] 51432 51433 The discrepancy comes from tui_resize_all, where we ask readline for the 51434 screen size: 51435 ... 51436 rl_get_screen_size (&screenheight, &screenwidth); 51437 ... 51438 51439 As it happens, when TERM is set to ansi, readline decides that the terminal 51440 cannot auto-wrap lines, and reserves one column to deal with that, and as a 51441 result reports back one less than the actual screen width: 51442 ... 51443 $ echo $COLUMNS 51444 78 51445 $ TERM=xterm gdb -ex "show width" -ex q 51446 Number of characters gdb thinks are in a line is 78. 51447 $ TERM=ansi gdb -ex "show width" -ex q 51448 Number of characters gdb thinks are in a line is 77. 51449 ... 51450 51451 In tui_resize_all, we need the actual screen width, and using a screenwidth of 51452 one less than the actual value garbles the screen. 51453 51454 This is currently not causing trouble in testing because we have a workaround 51455 in place in proc Term::resize. If we disable the workaround: 51456 ... 51457 - stty columns [expr {$_cols + 1}] < $::gdb_tty_name 51458 + stty columns $_cols < $::gdb_tty_name 51459 ... 51460 and dump the screen we get the same type of screen garbling: 51461 ... 51462 0 +---------------------------------------+| 51463 1 || 51464 2 || 51465 3 || 51466 ... 51467 51468 Another way to reproduce the problem is using command "maint info screen". 51469 After starting gdb with TERM=ansi, entering TUI, and issuing the command, we 51470 get: 51471 ... 51472 Number of characters curses thinks are in a line is 78. 51473 ... 51474 and after maximizing and demaximizing the window we get: 51475 ... 51476 Number of characters curses thinks are in a line is 77. 51477 ... 51478 If we use TERM=xterm, we do get the expected 78. 51479 51480 Fix this by: 51481 - detecting when readline will report back less than the actual screen width, 51482 - accordingly setting a new variable readline_hidden_cols, 51483 - using readline_hidden_cols in tui_resize_all to fix the resize problem, and 51484 - removing the workaround in Term::resize. 51485 51486 The test-case gdb.tui/empty.exp serves as regression test. 51487 51488 I've applied the same fix in tui_async_resize_screen, the new test-case 51489 gdb.tui/resize-2.exp serves as a regression test for that change. Without 51490 that fix, we have: 51491 ... 51492 FAIL: gdb.tui/resize-2.exp: again: gdb width 80 51493 ... 51494 51495 Tested on x86_64-linux. 51496 51497 PR tui/30337 51498 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337 51499 515002023-04-30 GDB Administrator <gdbadmin@sourceware.org> 51501 51502 Automatic date update in version.in 51503 515042023-04-29 Tom de Vries <tdevries@suse.de> 51505 51506 [gdb/testsuite] Fix gdb.base/readline.exp with stub-termcap 51507 When doing a build which uses stub-termcap, we run into: 51508 ... 51509 (gdb) set width 7 51510 <b) FAIL: gdb.base/readline.exp: set width 7 (timeout) 51511 ... 51512 51513 Since readline can't detect very basic terminal support, it falls back on 51514 horizontal scrolling. 51515 51516 Fix this by detecting the horizontal scrolling case, and skipping the 51517 subsequent test. 51518 51519 Tested on x86_64-linux. 51520 51521 PR testsuite/30400 51522 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400 51523 515242023-04-29 Manoj Gupta <manojgupta@google.com> 51525 51526 gdb: Fix building with latest libc++ 51527 Latest libc++[1] causes transitive include to <locale> when 51528 <mutex> or <thread> header is included. This causes 51529 gdb to not build[2] since <locale> defines isupper/islower etc. 51530 functions that are explicitly macroed-out in safe-ctype.h to 51531 prevent their use. 51532 Use the suggestion from libc++ to include <locale> internally when 51533 building in C++ mode to avoid build errors. 51534 Use safe-gdb-ctype.h as the include instead of "safe-ctype.h" 51535 to keep this isolated to gdb since rest of binutils 51536 does not seem to use much C++. 51537 51538 [1]: https://reviews.llvm.org/D144331 51539 [2]: https://issuetracker.google.com/issues/277967395 51540 515412023-04-29 Tom de Vries <tdevries@suse.de> 51542 51543 [gdb/testsuite] Fix gdb.ada/excep_handle.exp for updated gdb_test 51544 Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9 51545 ("gdb/testsuite: change newline patterns used in gdb_test"): 51546 ... 51547 (gdb) continue^M 51548 Continuing.^M 51549 ^M 51550 Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M 51551 26 when Constraint_Error =>^M 51552 (gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \ 51553 exception handlers 51554 ... 51555 51556 The output is supposed to be matched by: 51557 ... 51558 gdb_test "continue" \ 51559 "Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \ 51560 "continuing to first Constraint_Error exception handlers" 51561 ... 51562 but the $eol bit no longer matches due to the stricter matching introduced 51563 in aforementioned commit. 51564 51565 Fix this by dropping the "$eol.*" bit. 51566 51567 Tested on x86_64-linux. 51568 51569 PR testsuite/30399 51570 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399 51571 515722023-04-29 Tom de Vries <tdevries@suse.de> 51573 51574 [gdb/build] Fix build without ncurses in maintenance_info_screen 51575 With a build without ncurses we run into: 51576 ... 51577 src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’: 51578 src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope 51579 COLS); 51580 ^~~~ 51581 src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope 51582 LINES); 51583 ^~~~~ 51584 ... 51585 51586 Fix this by using HAVE_LIBCURSES. 51587 51588 Tested on x86_64-linux. 51589 51590 PR build/30391 51591 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30391 51592 515932023-04-29 Tom de Vries <tdevries@suse.de> 51594 51595 [gdb/testsuite] Fix gdb.tui/main.exp without TUI 51596 With a build with --disable-tui, we get: 51597 ... 51598 (gdb) PASS: gdb.tui/main.exp: set interactive-mode off 51599 maint set tui-left-margin-verbose on^M 51600 Undefined maintenance set command: "tui-left-margin-verbose on". \ 51601 Try "help maintenance set".^M 51602 (gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on 51603 ... 51604 51605 Fix this by adding the missing "require allow_tui_tests". 51606 51607 Tested on x86_64-linux. 51608 516092023-04-29 GDB Administrator <gdbadmin@sourceware.org> 51610 51611 Automatic date update in version.in 51612 516132023-04-29 Andrew Burgess <aburgess@redhat.com> 51614 51615 gdb/mi: check thread exists when creating thread-specific b/p 51616 I noticed the following behaviour: 51617 51618 $ gdb -q -i=mi /tmp/hello.x 51619 =thread-group-added,id="i1" 51620 =cmd-param-changed,param="print pretty",value="on" 51621 ~"Reading symbols from /tmp/hello.x...\n" 51622 (gdb) 51623 -break-insert -p 99 main 51624 ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"} 51625 (gdb) 51626 info breakpoints 51627 &"info breakpoints\n" 51628 ~"Num Type Disp Enb Address What\n" 51629 ~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n" 51630 &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable." 51631 &"\n" 51632 &"----- Backtrace -----\n" 51633 &"Backtrace unavailable\n" 51634 &"---------------------\n" 51635 &"\nThis is a bug, please report it." 51636 &" For instructions, see:\n" 51637 &"<https://www.gnu.org/software/gdb/bugs/>.\n\n" 51638 Aborted (core dumped) 51639 51640 What we see here is that when using the MI a user can create 51641 thread-specific breakpoints for non-existent threads. Then if we try 51642 to use the CLI 'info breakpoints' command GDB throws an assertion. 51643 The assert is a result of the print_thread_id call when trying to 51644 build the 'stop only in thread xx.yy' line; print_thread_id requires a 51645 valid thread_info pointer, which we can't have for a non-existent 51646 thread. 51647 51648 In contrast, when using the CLI we see this behaviour: 51649 51650 $ gdb -q /tmp/hello.x 51651 Reading symbols from /tmp/hello.x... 51652 (gdb) break main thread 99 51653 Unknown thread 99. 51654 (gdb) 51655 51656 The CLI doesn't allow a breakpoint to be created for a non-existent 51657 thread. So the 'info breakpoints' command is always fine. 51658 51659 Interestingly, the MI -break-info command doesn't crash, this is 51660 because the MI uses global thread-ids, and so never calls 51661 print_thread_id. However, GDB does support using CLI and MI in 51662 parallel, so we need to solve this problem. 51663 51664 One option would be to change the CLI behaviour to allow printing 51665 breakpoints for non-existent threads. This would preserve the current 51666 MI behaviour. 51667 51668 The other option is to pull the MI into line with the CLI and prevent 51669 breakpoints being created for non-existent threads. This is good for 51670 consistency, but is a breaking change for the MI. 51671 51672 In the end I figured that it was probably better to retain the 51673 consistent CLI behaviour, and just made the MI reject requests to 51674 place a breakpoint on a non-existent thread. The only test we had 51675 that depended on the old behaviour was 51676 gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit: 51677 51678 commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c 51679 Date: Fri Feb 17 10:48:06 2023 +0000 51680 51681 gdb: don't duplicate 'thread' field in MI breakpoint output 51682 51683 I certainly didn't intend for this test to rely on this feature of the 51684 MI, so I propose to update this test to only create breakpoints for 51685 threads that exist. 51686 51687 Actually, I've added a new test that checks the MI rejects creating a 51688 breakpoint for a non-existent thread, and I've also extended the test 51689 to run with the separate MI/CLI UIs, and then tested 'info 51690 breakpoints' to ensure this command doesn't crash. 51691 51692 I've extended the documentation of the `-p` flag to explain the 51693 constraints better. 51694 51695 I have also added a NEWS entry just in case someone runs into this 51696 issue, at least then they'll know this change in behaviour was 51697 intentional. 51698 51699 One thing that I did wonder about while writing this patch, is whether 51700 we should treat requests like this, on both the MI and CLI, as another 51701 form of pending breakpoint, something like: 51702 51703 (gdb) break foo thread 9 51704 Thread 9 does not exist. 51705 Make breakpoint pending on future thread creation? (y or [n]) y 51706 Breakpoint 1 (foo thread 9) pending. 51707 (gdb) info breakpoints 51708 Num Type Disp Enb Address What 51709 1 breakpoint keep y <PENDING> foo thread 9 51710 51711 Don't know if folk think that would be a useful idea or not? Either 51712 way, I think that would be a separate patch from this one. 51713 51714 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 51715 517162023-04-28 Andrew Burgess <aburgess@redhat.com> 51717 51718 gdb: make deprecated_show_value_hack static 51719 The deprecated_show_value_hack function is now only used inside 51720 cli-setshow.c, so lets make the function static to discourage its use 51721 anywhere else. 51722 51723 There should be no user visible changes after this commit 51724 51725 Reviewed-By: Tom Tromey <tom@tromey.com> 51726 517272023-04-28 Andrew Burgess <aburgess@redhat.com> 51728 51729 gdb: make set/show inferior-tty work with $_gdb_setting_str 51730 Like the previous two commits, this commit fixes set/show inferior-tty 51731 to work with $_gdb_setting_str. 51732 51733 Instead of using a scratch variable which is then pushed into the 51734 current inferior from a set callback, move to the API that allows for 51735 getters and setters, and store the value directly within the current 51736 inferior. 51737 51738 Update an existing test to check the inferior-tty setting. 51739 51740 Reviewed-By: Tom Tromey <tom@tromey.com> 51741 517422023-04-28 Andrew Burgess <aburgess@redhat.com> 51743 51744 gdb: make set/show cwd work with $_gdb_setting_str 51745 The previous commit fixed set/show args when used with 51746 $_gdb_setting_str, this commit fixes set/show cwd. 51747 51748 Instead of using a scratch variable which is then pushed into the 51749 current inferior from a set callback, move to the API that allows for 51750 getters and setters, and store the value directly within the current 51751 inferior. 51752 51753 Update the existing test to check the cwd setting. 51754 517552023-04-28 Andrew Burgess <aburgess@redhat.com> 51756 51757 gdb: make set/show args work with $_gdb_setting_str 51758 I noticed that $_gdb_setting_str was not working with 'args', e.g.: 51759 51760 $ gdb -q --args /tmp/hello.x arg1 arg2 arg3 51761 Reading symbols from /tmp/hello.x... 51762 (gdb) show args 51763 Argument list to give program being debugged when it is started is "arg1 arg2 arg3". 51764 (gdb) print $_gdb_setting_str("args") 51765 $1 = "" 51766 51767 This is because the 'args' setting is implemented using a scratch 51768 variable ('inferior_args_scratch') which is updated when the user does 51769 'set args ...'. There is then a function 'set_args_command' which is 51770 responsible for copying the scratch area into the current inferior. 51771 51772 However, when the user sets the arguments via the command line the 51773 scratch variable is not updated, instead the arguments are pushed 51774 straight into the current inferior. 51775 51776 There is a second problem, when the current inferior changes the 51777 scratch area is not updated, which means that the value returned will 51778 only ever reflect the last call to 'set args ...' regardless of which 51779 inferior is currently selected. 51780 51781 Luckily, the fix is pretty easy, set/show variables have an 51782 alternative API which requires we provide some getter and setter 51783 functions. With this done the scratch variable can be removed and the 51784 value returned will now always reflect the current inferior. 51785 51786 While working on set/show args I also rewrote show_args_command to 51787 remove the use of deprecated_show_value_hack. 51788 51789 Reviewed-By: Tom Tromey <tom@tromey.com> 51790 517912023-04-28 Andrew Burgess <aburgess@redhat.com> 51792 51793 gdb: cleanup command creation in infcmd.c 51794 In infcmd.c, in order to add command completion to some of the 'set' 51795 commands, we are currently creating the command, then looking up the 51796 command by calling lookup_cmd. 51797 51798 This is no longer necessary, we already return the relevant 51799 cmd_list_element object when the set/show command is created, and we 51800 can use that to set the command completion callback. 51801 51802 I don't know if there's actually any tests for completion of these 51803 commands, but I manually checked, and each command still appears to 51804 offer the expected filename completion. 51805 51806 There should be no user visible changes after this commit. 51807 51808 Reviewed-By: Tom Tromey <tom@tromey.com> 51809 518102023-04-28 Simon Marchi <simon.marchi@efficios.com> 51811 51812 gdb/record-full: disable range stepping when resuming threads 51813 I see these failures, when running with the native-gdbserver of 51814 native-extended-gdbserver boards: 51815 51816 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ... 51817 FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body 51818 FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body 51819 FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body 51820 FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body 51821 51822 Let's use this simpler program to illustrate the problem: 51823 51824 int main() 51825 { 51826 int a = 362; 51827 a = a * 17; 51828 return a; 51829 } 51830 51831 It compiles down to: 51832 51833 int a = 362; 51834 401689: c7 45 fc 6a 01 00 00 movl $0x16a,-0x4(%rbp) 51835 a = a * 17; 51836 401690: 8b 55 fc mov -0x4(%rbp),%edx 51837 401693: 89 d0 mov %edx,%eax 51838 401695: c1 e0 04 shl $0x4,%eax 51839 401698: 01 d0 add %edx,%eax 51840 40169a: 89 45 fc mov %eax,-0x4(%rbp) 51841 return a; 51842 40169d: 8b 45 fc mov -0x4(%rbp),%eax 51843 51844 When single stepping these lines, debugging locally, while recording, 51845 these are the recorded instructions (basically one for each instruction 51846 shown above): 51847 51848 (gdb) maintenance print record-instruction 0 51849 4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00 51850 Register rip changed: (void (*)()) 0x40169a <main+21> 51851 (gdb) maintenance print record-instruction -1 51852 Register rax changed: 5792 51853 Register eflags changed: [ PF AF IF ] 51854 Register rip changed: (void (*)()) 0x401698 <main+19> 51855 (gdb) maintenance print record-instruction -2 51856 Register rax changed: 362 51857 Register eflags changed: [ PF ZF IF ] 51858 Register rip changed: (void (*)()) 0x401695 <main+16> 51859 (gdb) maintenance print record-instruction -3 51860 Register rax changed: 4200069 51861 Register rip changed: (void (*)()) 0x401693 <main+14> 51862 (gdb) maintenance print record-instruction -4 51863 Register rdx changed: 140737488346696 51864 Register rip changed: (void (*)()) 0x401690 <main+11> 51865 (gdb) maintenance print record-instruction -5 51866 4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00 51867 Register rip changed: (void (*)()) 0x401689 <main+4> 51868 (gdb) maintenance print record-instruction -6 51869 Not enough recorded history 51870 51871 But when debugging remotely: 51872 51873 (gdb) maintenance print record-instruction 0 51874 Register rdx changed: 140737488346728 51875 Register rip changed: (void (*)()) 0x401690 <main+11> 51876 (gdb) maintenance print record-instruction -1 51877 4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00 51878 Register rip changed: (void (*)()) 0x401689 <main+4> 51879 (gdb) maintenance print record-instruction -2 51880 Not enough recorded history 51881 51882 In this list, we only have entries for the beginning of each line. This 51883 is because of the remote target's support for range stepping. The 51884 record-full layer can only record instructions when the underlying 51885 process target reports a stop. With range stepping, the remote target 51886 single-steps multiple instructions at a time, so the record-full target 51887 doesn't get to see and record them all. 51888 51889 Fix this by making the record-full layer disable range-stepping 51890 before handing the resume request to the beneath layer, forcing the 51891 remote target to report stops for each instruction. 51892 51893 Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d 51894 518952023-04-28 Keith Seitz <keiths@redhat.com> 51896 51897 Allow strings with printf/eval 51898 PR 13098 explains that if a user attempts to use a string with either 51899 `printf' (or `eval'), gdb returns an error (inferior not running): 51900 51901 (gdb) printf "%s\n", "hello" 51902 evaluation of this expression requires the target program to be active 51903 51904 However, the parser can certainly handle this case: 51905 51906 (gdb) p "hello" 51907 $1 = "hello" 51908 51909 This discrepancy occurs because printf_c_string does not handle 51910 this specific case. The passed-in value that we are attempting to print 51911 as a string is TYPE_CODE_ARRAY but it's lval type is not_lval. 51912 51913 printf_c_string will only attempt to print a string from the value's 51914 contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's 51915 type is considered a string type: 51916 51917 if (value->type ()->code () != TYPE_CODE_PTR 51918 && value->lval () == lval_internalvar 51919 && c_is_string_type_p (value->type ())) 51920 { 51921 ... 51922 } 51923 51924 Otherwise, it attempts to read the value of the string from the target's 51925 memory (which is what actually generates the "evaluation of this ..." 51926 error message). 51927 519282023-04-28 Tom Tromey <tromey@adacore.com> 51929 51930 Move find_minimal_symbol_address to minsyms.c 51931 I found find_minimal_symbol_address in parse.c, but it seems to me 51932 that it belongs in minsyms.c. 51933 51934 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 51935 519362023-04-28 Tom Tromey <tromey@adacore.com> 51937 51938 Do not change type in get_discrete_low_bound 51939 get_discrete_low_bound has this code: 51940 51941 /* Set unsigned indicator if warranted. */ 51942 if (low >= 0) 51943 type->set_is_unsigned (true); 51944 51945 It's bad to modify a type in a getter like this, so this patch removes 51946 this code. FWIW I looked and this code has been there since at least 51947 1999 (it was in the initial sourceware import). 51948 51949 Types in general would benefit from const-ification, which would 51950 probably reveal more code like this, but I haven't attempted that. 51951 51952 Regression tested on x86-64 Fedora 36. 51953 51954 Reviewed-by: Kevin Buettner <kevinb@redhat.com> 51955 519562023-04-28 Tom Tromey <tromey@adacore.com> 51957 51958 Remove @var from @defun in Python documentation 51959 Eli pointed out that @var isn't needed in @defun in Texinfo. This 51960 patch removes the cases I found in python.texi. I also renamed some 51961 variables in one spot, because "-" isn't valid in a Python variable 51962 name. 51963 519642023-04-28 Andrew Burgess <aburgess@redhat.com> 51965 51966 gdb/testsuite: additional test fixes after gdb_test changes 51967 After this commit: 51968 51969 commit e2f620135d92f7cd670af4e524fffec7ac307666 51970 Date: Thu Mar 30 13:26:25 2023 +0100 51971 51972 gdb/testsuite: change newline patterns used in gdb_test 51973 51974 There were some regressions in gdb.trace/*.exp tests when run with the 51975 native-gdbserver board. This commit fixes these regressions. 51976 51977 All the problems are caused by unnecessary trailing newline characters 51978 included in the patterns passed to gdb_test. After the above commit 51979 the testsuite is stricter when matching trailing newlines, and so the 51980 additional trailing newline characters are now causing the test to 51981 fail. Fix by removing all the excess trailing newline characters. 51982 51983 In some cases this cleanup means we should use gdb_test_no_output, 51984 I've done that where appropriate. In a couple of other places I've 51985 made use of multi_line to better build the expected output pattern. 51986 519872023-04-28 H.J. Lu <hjl.tools@gmail.com> 51988 51989 ld: Use run_cc_link_tests for PR ld/26391 tests 51990 Use run_cc_link_tests for PR ld/26391 tests to compile PR ld/26391 tests 51991 in C. 51992 51993 PR ld/30002 51994 * testsuite/ld-elf/elf.exp: Use run_cc_link_tests for PR ld/26391 51995 tests. 51996 519972023-04-28 Eli Zaretskii <eliz@gnu.org> 51998 51999 Fix a typo in gdb.texinfo. 52000 520012023-04-28 Nelson Chu <nelson@rivosinc.com> 52002 52003 RISC-V: Enable x0 base relaxation for relax_pc even if --no-relax-gp. 52004 Let --no-relax-gp only disable the gp relaxation for lui and pcrel 52005 relaxations, since x0 base and gp relaxations are different optimizations 52006 in fact, but just use the same function to handle. 52007 52008 bfd/ 52009 * elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui, 52010 set gp to zero when --no-relax-gp, then we should still keep the 52011 x0 base relaxation. 52012 (_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when 52013 --no-relax-gp, we will disable the gp relaxation in the 52014 _bfd_riscv_relax_pc. 52015 520162023-04-28 Nelson Chu <nelson@rivosinc.com> 52017 52018 RISC-V: Relax R_RISCV_[PCREL_]LO12_I/S to R_RISCV_GPREL_I/S for undefined weak. 52019 bfd/ 52020 *elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol, 52021 just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't 52022 update the rs1 to zero until relocate_section. 52023 (_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S. 52024 520252023-04-28 Jan Beulich <jbeulich@suse.com> 52026 52027 x86: limit data passed to i386_dis_printf() 52028 The function doesn't use "ins" for other than retrieving "info". Remove 52029 a thus pointless level of indirection. 52030 52031 x86: limit data passed to prefix_name() 52032 Make apparent that neither what "ins" points to nor, in particular, that 52033 "ins->info->private_data" is actually used in the function. 52034 52035 x86/Intel: reduce ELF/PE conditional scope in x86_cons() 52036 All the Intel syntax related state adjustments apply independent of 52037 target or object format. 52038 52039 gas: move shift count check 52040 ... out of mainline code, grouping together the two case labels. This 52041 then also make more obvious that the comment there applies to both forms 52042 of shifts. 52043 52044 x86: rework AMX control insn disassembly 52045 Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth, 52046 and only then prefix, resulting in fewer table entries. Note that in the 52047 course of the re-work 52048 - TILEZERO has a previously missing decode step through rm_table[] 52049 added, 52050 - a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an 52051 infix). 52052 520532023-04-28 Jan Beulich <jbeulich@suse.com> 52054 52055 x86: rework AMX multiplication insn disassembly 52056 Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth, 52057 and prefix last, resulting in fewer table entries. Note that in the 52058 course of the re-work wrong M_0 suffixes are also corrected to be M_1 52059 (partly infixes now). 52060 52061 Since it ended up confusing while testing the change, also adjust the 52062 test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's). 52063 520642023-04-28 Alan Modra <amodra@gmail.com> 52065 52066 Re: Keeping track of rs6000-coff archive element pointers 52067 Commit de7b90610e9e left a hole in the element checking, explained by 52068 the comment added to _bfd_xcoff_openr_next_archived_file. While 52069 fixing this, tidy some types used to hold unsigned values so that 52070 casts are not needed to avoid signed/unsigned comparison warnings. 52071 Also tidy a few things in xcoff.h. 52072 52073 bfd/ 52074 * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check 52075 that we aren't pointing back at the last element. Make 52076 filestart a ufile_ptr. Update for xcoff_artdata change. 52077 (_bfd_strntol, _bfd_strntoll): Return unsigned values. 52078 (_bfd_xcoff_slurp_armap): Make off a ufile_ptr. 52079 (add_ranges): Update for xcoff_artdata change. 52080 * libbfd-in.h (struct artdata): Make first_file_filepos a 52081 ufile_ptr. 52082 * libbfd.h: Regenerate. 52083 include/ 52084 * coff/xcoff.h (struct xcoff_artdata): Replace min_elt with 52085 ar_hdr_size. 52086 (xcoff_big_format_p): In the !SMALL_ARCHIVE case return true 52087 for anything but a small archive. 52088 520892023-04-28 Alan Modra <amodra@gmail.com> 52090 52091 Remove deprecated bfd_read 52092 20+ years is long enough to warn. 52093 52094 * bfd-in.h (bfd_read, bfd_write): Don't define 52095 (_bfd_warn_deprecated): Don't declare. 52096 * bfd-in2.h: Regenerate. 52097 * libbfd.c (_bfd_warn_deprecated): Delete. 52098 520992023-04-28 Alan Modra <amodra@gmail.com> 52100 52101 Make bfd_byte an int8_t, flagword a uint32_t 52102 * bfd-in.h (bfd_byte): Typedef as int8_t. 52103 (flagword): Typedef as uint32_t. 52104 (bfd_vma, bfd_signed_vma, bfd_size_type, symvalue): Use stdint 52105 types in !BFD64 case. 52106 * bfd-in2.h: Regenerate. 52107 521082023-04-28 GDB Administrator <gdbadmin@sourceware.org> 52109 52110 Automatic date update in version.in 52111 521122023-04-27 Jose E. Marchesi <jose.marchesi@oracle.com> 52113 52114 gas: bpf: fix tests for pseudo-c syntax 52115 This patch fixes the GAS BPF testsuite so the tests for pseudo-c 52116 syntax are actually executed. 52117 52118 2023-04-27 Jose E. Marchesi <jose.marchesi@oracle.com> 52119 52120 * testsuite/gas/bpf/mem.dump: New file. 52121 * testsuite/gas/bpf/mem-pseudoc.d: Likewise. 52122 * testsuite/gas/bpf/mem.d: #dump mem.dump. 52123 * testsuite/gas/bpf/lddw.dump: New file. 52124 * testsuite/gas/bpf/lddw-pseudoc.d: Likewise. 52125 * testsuite/gas/bpf/lddw.d: #dump lddw.dump. 52126 * testsuite/gas/bpf/jump.dump: New file. 52127 * testsuite/gas/bpf/jump-pseudoc.d: Likewise 52128 * testsuite/gas/bpf/jump.d: #dump jump.dump. 52129 * testsuite/gas/bpf/jump32.dump: New file. 52130 * testsuite/gas/bpf/jump32-pseudoc.d: Likewise. 52131 * testsuite/gas/bpf/jump32.d: #dump jump32.dump. 52132 * testsuite/gas/bpf/lddw-be.dump: New file. 52133 * testsuite/gas/bpf/lddw-be-pseudoc.d: Likewise. 52134 * testsuite/gas/bpf/lddw-be.d: #dump lddw-be.dump. 52135 * testsuite/gas/bpf/indcall-1.dump: New file. 52136 * testsuite/gas/bpf/indcall-1-pseudoc.d: Likewise. 52137 * testsuite/gas/bpf/indcall-1.d: #dump indcall-1.dump. 52138 * testsuite/gas/bpf/indcall-1-pseudoc.s (main): Fix lddw 52139 instruction. 52140 * testsuite/gas/bpf/atomic.dump: New file. 52141 * testsuite/gas/bpf/atomic-pseudoc.d: Likewise. 52142 * testsuite/gas/bpf/atomic.d: #dump atomic.dump. 52143 * testsuite/gas/bpf/alu32.dump: New file. 52144 * testsuite/gas/bpf/alu32-pseudoc.d: Likewise. 52145 * testsuite/gas/bpf/alu32.d: #dump alu32.dump. 52146 * testsuite/gas/bpf/alu.dump: New file. 52147 * testsuite/gas/bpf/alu-pseudoc.d: Likewise. 52148 * testsuite/gas/bpf/alu.d: #dump alu.dump. 52149 52150 * testsuite/gas/bpf/alu-be.dump: New file. 52151 * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise. 52152 * testsuite/gas/bpf/alu-be.d: #dump alu-be.dump. 52153 * testsuite/gas/bpf/alu32-be-pseudoc.d: New file. 52154 * testsuite/gas/bpf/alu32-be-dump: Likewise. 52155 * testsuite/gas/bpf/alu32-be.d: #dump alu32-be-dump. 52156 * testsuite/gas/bpf/bpf.exp: Run *-pseudoc tests. 52157 521582023-04-27 Tom Tromey <tromey@adacore.com> 52159 52160 Avoid some compiler warnings in gdb.ada 52161 Running gdb.ada/verylong.exp shows a warning from the Ada compiler: 52162 52163 prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default] 52164 52165 This patch fixes the problem, and another similar one in 52166 unchecked_union.exp. 52167 521682023-04-27 Michael Matz <matz@suse.de> 52169 52170 Fix PR30358, performance with --sort-section 52171 since af31506c we only use the binary tree when section sorting is 52172 required. While its unbalanced and hence can degrade to a linear list 52173 it should otherwise have been equivalent to the old code relying on 52174 insertion sort. Unfortunately it was not. The old code directly used 52175 lang_add_section to populate the sorted list, the new code first 52176 populates the tree and only then does lang_add_section on the sorted 52177 result. 52178 52179 In the testcase we have very many linkonce section groups, and hence 52180 lang_add_section won't actually insert anything for most of them. That 52181 limited the to-be-sorted list length previously. The tree-sorting code 52182 OTOH first created a tree of all candidates sections, including those 52183 that wouldn't be inserted by lang_add_section, hence increasing the size 52184 of the sorting problem. In the testcase the chain length went from 52185 about 1500 to 106000, and in the degenerated case (as in the testcase) 52186 that goes in quadratically. 52187 52188 This splits out most of the early-out code from lang_add_section to its 52189 own function and uses the latter to avoid inserting into the tree. This 52190 refactoring slightly changes the order of early-out tests (the ones 52191 based on section flags is now done last, and only in lang_add_section). 52192 The new function is not a pure predicate: it can give warnings and it 52193 might change output_section, like the old early-out code did. I have 52194 also added a skip-warning case in the first discard case, whose 52195 non-existence seemed to have been an oversight. 52196 52197 PR 30358 52198 * ldlang.c (wont_add_section_p): Split out from ... 52199 (lang_add_section): ... here. 52200 (output_section_callback_sort): Use wont_add_section_p to not 52201 always add sections to the sort tree. 52202 522032023-04-27 Andrew Burgess <aburgess@redhat.com> 52204 52205 gdb/doc: extend the documentation of the jump command 52206 This commit addresses PR gdb/7946. While checking for bugs relating 52207 to the jump command I noticed a long standing bug that points out a 52208 deficiency with GDB's documentation of the jump command. 52209 52210 The bug points out that 'jump 0x...' is not always the same as 'set 52211 $pc = 0x...' and then 'continue'. Writing directly to the $pc 52212 register does not update any auxiliary state, e.g. $npc on SPARC, 52213 while using 'jump' does. 52214 52215 It felt like this would be an easy issue to address by adding a 52216 paragraph to the docs, so I took a stab at writing something suitable. 52217 52218 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7946 52219 52220 Approved-By: Eli Zaretskii <eliz@gnu.org> 52221 522222023-04-27 Andrew Burgess <aburgess@redhat.com> 52223 52224 gdb/testsuite: special case '^' in gdb_test pattern 52225 In this commit I propose that we add special handling for the '^' when 52226 used at the start of a gdb_test pattern. Consider this usage: 52227 52228 gdb_test "some_command" "^command output pattern" 52229 52230 I think the intention here is pretty clear - run 'some_command', and 52231 the output from the command should be exactly 'command output 52232 pattern'. 52233 52234 After the previous commit which tightened up how gdb_test matches the 52235 final newline and prompt we know that the only thing after the output 52236 pattern will be a single newline and prompt, and the leading '^' 52237 ensures that there's no output before 'command output pattern', so 52238 this will do what I want, right? 52239 52240 ... except it doesn't. The command itself will also needs to be 52241 matched, so I should really write: 52242 52243 gdb_test "some_command" "^some_command\r\ncommand output pattern" 52244 52245 which will do what I want, right? Well, that's fine until I change 52246 the command and include some regexp character, then I have to write: 52247 52248 gdb_test "some_command" \ 52249 "^[string_to_regexp some_command]\r\ncommand output pattern" 52250 52251 but this all gets a bit verbose, so in most cases I simply don't 52252 bother anchoring the output with a '^', and a quick scan of the 52253 testsuite would indicate that most other folk don't both either. 52254 52255 What I propose is this: the *only* thing that can appear immediately 52256 after the '^' is the command converted into a regexp, so lets do that 52257 automatically, moving the work into gdb_test. Thus, when I write: 52258 52259 gdb_test "some_command" "^command output pattern" 52260 52261 Inside gdb_test we will spot the leading '^' in the pattern, and 52262 inject the regexp version of the command after the '^', followed by a 52263 '\r\n'. 52264 52265 My hope is that given this new ability, folk will be more inclined to 52266 anchor their output patterns when this makes sense to do so. This 52267 should increase our ability to catch any unexpected output from GDB 52268 that appears as a result of running a particular command. 52269 52270 There is one problem case we need to consider, sometime people do 52271 this: 52272 52273 gdb_test "" "^expected output pattern" 52274 52275 In this case no command is sent to GDB, but we are still expecting 52276 some output from GDB. This might be a result of some asynchronous 52277 event for example. As there is no command sent to GDB (from the 52278 gdb_test) there will be no command text to parse. 52279 52280 In this case my proposed new feature injects the command regexp, which 52281 is the empty string (as the command itself is empty), but still 52282 injects the '\r\n' after the command regexp, thus we end up with this 52283 pattern: 52284 52285 ^\r\nexpected output pattern 52286 52287 This extra '\r\n' is not what we should expected here, and so there is 52288 a special case inside gdb_test -- if the command is empty then don't 52289 add anything after the '^' character. 52290 52291 There are a bunch of tests that do already use '^' followed by the 52292 command, and these can all be simplified in this commit. 52293 52294 I've tried to run all the tests that I can to check this commit, but I 52295 am certain that there will be some tests that I manage to miss. 52296 Apologies for any regressions this commit causes, hopefully fixing the 52297 regressions will not be too hard. 52298 52299 Reviewed-By: Tom Tromey <tom@tromey.com> 52300 523012023-04-27 Andrew Burgess <aburgess@redhat.com> 52302 52303 gdb/testsuite: change newline patterns used in gdb_test 52304 This commit makes two changes to how we match newline characters in 52305 the gdb_test proc. 52306 52307 First, for the newline pattern between the command output and the 52308 prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'. 52309 52310 The old pattern would spot multiple newlines, and so there are a few 52311 places where, as part of this commit, I've needed to add an extra 52312 trailing '\r\n' to the pattern in the main test file, where GDB's 52313 output actually includes a blank line. 52314 52315 But I think this is a good thing. If a command produces a blank line 52316 then we should be checking for it, the current gdb_test doesn't do 52317 that. But also, with the current gdb_test, if a blank line suddenly 52318 appears in the output, this is going to be silently ignored, and I 52319 think this is wrong, the test should fail in that case. 52320 52321 Additionally, the existing pattern will happily match a partial 52322 newline. There are a strangely large number of tests that end with a 52323 random '.' character. Not matching a literal period, but matching any 52324 single character, this is then matching half of the trailing newline 52325 sequence, while the \[\r\n\]+ in gdb_test is matching the other half 52326 of the sequence. I can think of no reason why this would be 52327 intentional, I suspect that the expected output at one time included a 52328 period, which has since been remove, but I haven't bothered to check 52329 on this. In this commit I've removed all these unneeded trailing '.' 52330 characters. 52331 52332 The basic rule of gdb_test after this is that the expected pattern 52333 needs to match everything up to, but not including the newline 52334 sequence immediately before the GDB prompt. This is generally how the 52335 proc is used anyway, so in almost all cases, this commit represents no 52336 significant change. 52337 52338 Second, while I was cleaning up newline matching in gdb_test, I've 52339 also removed the '[\r\n]*' that was added to the start of the pattern 52340 passed to gdb_test_multiple. 52341 52342 The addition of this pattern adds no value. If the user pattern 52343 matches at the start of a line then this would match against the 52344 newline sequence. But, due to the '*', if the user pattern doesn't 52345 match at the start of a line then this group doesn't care, it'll 52346 happily match nothing. 52347 52348 As such, there's no value to it, it just adds more complexity for no 52349 gain, so I'm removing it. No tests will need updating as a 52350 consequence of this part of the patch. 52351 52352 Reviewed-By: Tom Tromey <tom@tromey.com> 52353 523542023-04-27 Andrew Burgess <aburgess@redhat.com> 52355 52356 gdb/testsuite: use 'return' in gdb_test_no_output 52357 A TCL proc will return the return value of the last command executed 52358 within the proc's body if there is no explicit return call, so 52359 gdb_test_no_output is already returning the return value of 52360 gdb_test_multiple. 52361 52362 However, I'm not a fan of (relying on) this implicit return value 52363 behaviour -- I prefer to be explicit about what we are doing. So in 52364 this commit I have extended the comment on gdb_test_no_output to 52365 document the possible return values (just as gdb_test does), and 52366 explicitly call return. 52367 52368 This should make no different to our testing, but I think it's clearer 52369 now what the gdb_test_no_output proc is expected to do. 52370 52371 The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the 52372 return value of gdb_test_no_output, and continue to pass after this 52373 change. 52374 52375 I also spotted that gdb.base/watchpoint.exp could be updated to make 52376 use of gdb_test_no_output, so I did that. 52377 52378 Reviewed-By: Tom Tromey <tom@tromey.com> 52379 523802023-04-27 Andrew Burgess <aburgess@redhat.com> 52381 52382 gdb: remove some trailing newlines from warning messages 52383 While working on a later patch in this series, which tightens up some 52384 of our pattern matching when using gdb_test, I ran into some failures 52385 caused by some warnings having a trailing newline character. 52386 52387 The warning function already adds a trailing newline, and it is my 52388 understanding that we should not be adding a second by including a 52389 newline at the end of any warning message. 52390 52391 The problem cases I found were in language.c and remote.c, in this 52392 patch I fix the cases I hit, but I also checked all the other warning 52393 calls in these two files and removed any additional trailing newlines 52394 I found. 52395 52396 In remote.c the warning actually had a newline character in the middle 52397 of the warning message (in addition to the trailing newline), which 52398 I've removed. I don't think it's helpful to forcibly split a warning 52399 as was done here -- in the middle of a sentence. Additionally, the 52400 message isn't even that long (71 characters), so I think removing this 52401 newline is an improvement. 52402 52403 None of the expected test result need updating with this commit, 52404 currently the patterns in gdb_test will match one or more newline 52405 sequences, so the tests are as happy with one newline (after this 52406 commit) as they are with two newlines (before this commit). A later 52407 commit will change gdb_test so that it is not so forgiving, and these 52408 warnings would have caused some failures. 52409 52410 Reviewed-By: Tom Tromey <tom@tromey.com> 52411 524122023-04-27 Andrew Burgess <aburgess@redhat.com> 52413 52414 gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp 52415 I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes 52416 fail when run from a particular directory. 52417 52418 The test tries to find the number of the first internal breakpoint 52419 using this proc: 52420 52421 proc get_first_maint_bp_num { } { 52422 gdb_test_multiple "maint info break" "find first internal bp num" { 52423 -re -wrap "(-\[0-9\]).*" { 52424 return $expect_out(1,string) 52425 } 52426 } 52427 return "" 52428 } 52429 52430 The problem is, at the time we issue 'maint info break' there are both 52431 internal breakpoint and non-internal (user created) breakpoints in 52432 place. The user created breakpoints include the path to the source 52433 file. 52434 52435 Sometimes, I'll be working from a directory that includes a number, 52436 like '/tmp/blah-1/gdb/etc', in which case the pattern above actually 52437 matches the '-1' from 'blah-1'. In this case there's no significant 52438 problem as it turns out that -1 is the number of the first internal 52439 breakpoint. 52440 52441 Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which 52442 case the above pattern patches '-4' from 'blah-4'. It turns out this 52443 is also not a problem -- the test doesn't actually need the first 52444 internal breakpoint number, it just needs the number of any internal 52445 breakpoint. 52446 52447 But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in 52448 which case the pattern above matches '-0' from 'blah-0', and in this 52449 case the test fails - there is no internal breakpoint '-0'. 52450 52451 Fix this by spotting that the internal breakpoint numbers always 52452 occurs after a '\r\n', and that they never start with a 0. Our 52453 pattern becomes: 52454 52455 -re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" { 52456 return $expect_out(1,string) 52457 } 52458 52459 After this I'm no longer seeing any failures. 52460 52461 Reviewed-By: Tom Tromey <tom@tromey.com> 52462 524632023-04-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 52464 52465 gdb, doc: add index entry for the $_inferior_thread_count convenience var 52466 Add a marker in the documentation for indexing the $_inferior_thread_count 52467 variable. 52468 52469 Approved-By: Eli Zaretskii <eliz@gnu.org> 52470 524712023-04-27 Nick Clifton <nickc@redhat.com> 52472 52473 Add support for %x and %lx formats to the linker's vinfo() function. 52474 524752023-04-27 GDB Administrator <gdbadmin@sourceware.org> 52476 52477 Automatic date update in version.in 52478 524792023-04-26 Philipp Tomsich <philipp.tomsich@vrull.eu> 52480 52481 RISC-V: Support XVentanaCondOps extension 52482 Ventana Micro has published the specification for their 52483 XVentanaCondOps ("conditional ops") extension at 52484 https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf 52485 which contains two new instructions 52486 - vt.maskc 52487 - vt.maskcn 52488 that can be used in constructing branchless sequences for 52489 various conditional-arithmetic, conditional-logical, and 52490 conditional-select operations. 52491 52492 To support such vendor-defined instructions in the mainline binutils, 52493 this change also adds a riscv_supported_vendor_x_ext secondary 52494 dispatch table (but also keeps the behaviour of allowing any unknow 52495 X-extension to be specified in addition to the known ones from this 52496 table). 52497 52498 As discussed, this change already includes the planned/agreed future 52499 requirements for X-extensions (which are likely to be captured in the 52500 riscv-toolchain-conventions repository): 52501 - a public specification document is available (see above) and is 52502 referenced from the gas-documentation 52503 - the naming follows chapter 27 of the RISC-V ISA specification 52504 - instructions are prefixed by a vendor-prefix (vt for Ventana) 52505 to ensure that they neither conflict with future standard 52506 extensions nor clash with other vendors 52507 52508 bfd/ChangeLog: 52509 52510 * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext. 52511 (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS. 52512 52513 gas/ChangeLog: 52514 52515 * doc/c-riscv.texi: Add section to list custom extensions and 52516 their documentation URLs. 52517 * testsuite/gas/riscv/x-ventana-condops.d: New test. 52518 * testsuite/gas/riscv/x-ventana-condops.s: New test. 52519 52520 include/ChangeLog: 52521 52522 * opcode/riscv-opc.h Add vt.maskc and vt.maskcn. 52523 * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS. 52524 52525 opcodes/ChangeLog: 52526 52527 * riscv-opc.c: Add vt.maskc and vt.maskcn. 52528 52529 Series-version: 1 52530 Series-to: binutils@sourceware.org 52531 Series-cc: Kito Cheng <kito.cheng@sifive.com> 52532 Series-cc: Nelson Chu <nelson.chu@sifive.com> 52533 Series-cc: Greg Favor <gfavor@ventanamicro.com> 52534 Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org> 52535 525362023-04-26 Jose E. Marchesi <jose.marchesi@oracle.com> 52537 52538 gas: documentation for the BPF pseudo-c asm syntax 52539 This patch expands the GAS manual in order to specify the alternate 52540 pseudo-C assembly syntax used in BPF, and now supported by the 52541 assembler. 52542 52543 gas/ChangeLog: 52544 52545 2023-04-19 Jose E. Marchesi <jose.marchesi@oracle.com> 52546 52547 PR gas/29757 52548 * doc/c-bpf.texi (BPF Pseudo-C Syntax): New section. 52549 525502023-04-26 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 52551 52552 gas: BPF pseudo-c syntax tests 52553 This patch expands the GAS BPF testsuite in order to also test the 52554 alternative pseudo-C syntax used in BPF assembly. 52555 52556 This includes three main changes: 52557 52558 - Some general GAS tests involving assignment and equality operands in 52559 expressions (such as = and ==) are disabled in bpf-* targets, 52560 because the syntax collides with the pseudo-C BPF assembly syntax. 52561 52562 - New tests are added to the BPF GAS testsuite that test the pseudo-c 52563 syntax. Tests for all BPF instructions are included. 52564 52565 - New tests are added to the BPF GAS testsuite that test the support 52566 for both syntaxes in the same source. 52567 52568 gas/ChangeLog: 52569 52570 2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 52571 52572 PR gas/29728 52573 * testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-* 52574 targets. 52575 * testsuite/gas/all/eqv-dot.d: Likewise. 52576 * testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*. 52577 * testsuite/gas/bpf/alu-pseudoc.s: New file. 52578 * testsuite/gas/bpf/pseudoc-normal.s: Likewise. 52579 * testsuite/gas/bpf/pseudoc-normal.d: Likewise. 52580 * testsuite/gas/bpf/pseudoc-normal-be.d: Likewise. 52581 * testsuite/gas/bpf/mem-pseudoc.s: Likewise. 52582 * testsuite/gas/bpf/lddw-pseudoc.s: Likewise. 52583 * testsuite/gas/bpf/jump32-pseudoc.s: Likewise. 52584 * testsuite/gas/bpf/jump-pseudoc.s: Likewise. 52585 * testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise. 52586 * testsuite/gas/bpf/atomic-pseudoc.s: Likewise. 52587 * testsuite/gas/bpf/alu32-pseudoc.s: Likewise. 52588 * testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests. 52589 525902023-04-26 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 52591 52592 gas: support for the BPF pseudo-c assembly syntax 52593 This patch adds support to the GNU assembler for an alternative 52594 assembly syntax used in BPF. This syntax is C-like and very 52595 unconventional for an assembly language, but it is generated by 52596 clang/llvm and is also used in inline asm templates in kernel code, so 52597 we ought to support it. 52598 52599 After this patch, the assembler is able to parse instructions in both 52600 supported syntax: the normal assembly-like syntax and the pseudo-C 52601 syntax. Instruction formats can be mixed in the source program: the 52602 assembler recognizes the right syntax to use. 52603 52604 gas/ChangeLog: 52605 52606 2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 52607 52608 PR gas/29728 52609 * config/tc-bpf.h (TC_EQUAL_IN_INSN): Define. 52610 * config/tc-bpf.c (LEX_IS_SYMBOL_COMPONENT): Define. 52611 (LEX_IS_WHITESPACE): Likewise. 52612 (LEX_IS_NEWLINE): Likewise. 52613 (LEX_IS_ARITHM_OP): Likewise. 52614 (LEX_IS_STAR): Likewise. 52615 (LEX_IS_CLSE_BR): Likewise. 52616 (LEX_IS_OPEN_BR): Likewise. 52617 (LEX_IS_EQUAL): Likewise. 52618 (LEX_IS_EXCLA): Likewise. 52619 (ST_EOI): Likewise. 52620 (MAX_TOKEN_SZ): Likewise. 52621 (init_pseudoc_lex): New function. 52622 (md_begin): Call init_pseudoc_lex. 52623 (valid_expr): New function. 52624 (build_bpf_non_generic_load): Likewise. 52625 (build_bpf_atomic_insn): Likewise. 52626 (build_bpf_jmp_insn): Likewise. 52627 (build_bpf_arithm_insn): Likewise. 52628 (build_bpf_endianness): Likewise. 52629 (build_bpf_load_store_insn): Likewise. 52630 (look_for_reserved_word): Likewise. 52631 (is_register): Likewise. 52632 (is_cast): Likewise. 52633 (get_token): Likewise. 52634 (bpf_pseudoc_to_normal_syntax): Likewise. 52635 (md_assemble): Try pseudo-C syntax if an instruction cannot be 52636 parsed. 52637 526382023-04-26 Jose E. Marchesi <jose.marchesi@oracle.com> 52639 52640 sim: bpf: update to new BPF relocations 52641 This patch updates the BPF GNU sim testsuite in order to match the new 52642 BPF relocations introduced in binutils in a recent patch [1]. 52643 52644 [1] https://sourceware.org/pipermail/binutils/2023-March/126429.html 52645 526462023-04-26 Tom de Vries <tdevries@suse.de> 52647 52648 [gdb/tui] Fix length of status line string 52649 In commit 5d10a2041eb ("gdb: add string_file::release method") this was added: 52650 ... 52651 + std::string string_val = string.release (); 52652 ... 52653 without updating subsequent uses of string.size (), which returns 0 after the 52654 string.release () call. 52655 52656 Fix this by: 52657 - using string_val.size () instead of string.size (), and 52658 - adding an assert that would have caught this regression. 52659 52660 Tested on x86_64-linux. 52661 52662 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 52663 PR tui/30389 52664 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389 52665 526662023-04-26 Tom Tromey <tromey@adacore.com> 52667 52668 Rewrite gdb_mpz::operator== 52669 Simon pointed out that the recent changes to gdb_mpz caused a build 52670 failure on amd64 macOS. It turns out to be somewhat difficult to 52671 overload a method in a way that will work "naturally" for all integer 52672 types; especially in a case like gdb_mpz::operator==, where it's 52673 desirable to special case all integer types that are no wider than 52674 'long'. 52675 52676 After a false start, I came up with this patch, which seems to work. 52677 It applies the desirable GMP special cases directly in the body, 52678 rather than via overloads. 52679 52680 Approved-By: Simon Marchi <simon.marchi@efficios.com> 52681 526822023-04-26 Luis Machado <luis.machado@arm.com> 52683 52684 Updated debug architecture version checks for fbsd 52685 There are two new debug architecture version entries. I updated the 52686 code for Linux, but fbsd also needs updating. 52687 52688 This patch does this, and should be pretty straightforward. 52689 52690 I can't test this on native fbsd, but I'm fairly confident it should 52691 work. 52692 526932023-04-26 Luis Machado <luis.machado@arm.com> 52694 52695 Add new debug architecture version 52696 Teach gdb about a new debug architecture version for AArch64 (0x11). 52697 52698 No user-visible changes. 52699 52700 Regression-tested on aarch64-linux Ubuntu 20.04/22.04. 52701 527022023-04-26 Alan Modra <amodra@gmail.com> 52703 52704 i386-dis.c UB shift and other tidies 52705 1) i386-dis.c:12055:11: runtime error: left shift of negative value -1 52706 Bit twiddling is best done unsigned, due to UB on overflow of signed 52707 expressions. Fix this by using bfd_vma rather than bfd_signed_vma 52708 everywhere in i386-dis.c except print_displacement. 52709 52710 2) Return get32s and get16 value in a bfd_vma, reducing the need for 52711 temp variables. 52712 52713 3) Introduce get16s and get8s functions to simplify the code. 52714 52715 4) With some optimisation options gcc-13 legitimately complains about 52716 a fall-through in OP_I. Fix that. OP_I also doesn't need to use 52717 "mask" which was wrong for w_mode anyway. 52718 52719 5) Masking with & 0xffffffff is better than casting to unsigned. We 52720 don't know for sure that unsigned int is 32-bit. 52721 52722 6) We also don't know that unsigned char is 8 bits. Mask codep 52723 accesses everywhere. I don't expect binutils will work on anything 52724 other than an 8-bit char host, but if we are masking codep accesses in 52725 some places we might as well be consistent. (Better would be to use 52726 stdint.h types more in binutils.) 52727 527282023-04-26 Alan Modra <amodra@gmail.com> 52729 52730 binutils runtest $CC 52731 I noticed in the binutile Makefile that runtest is being invoked with 52732 CC, CC_FOR_BUILD and other compiler related flags in the environment. 52733 That doesn't work. Those variables ought to be passed on the runtest 52734 command line. 52735 52736 After fixing that I had some fails due to binutils testprog.c now 52737 being compiled with the default "-g -O2" picked up in 52738 CFLAGS_FOR_TARGET. Hack around that by passing -O0. 52739 52740 Also, with the binutils testsuite now taking notice of CC_FOR_TARGET, 52741 I found a couple of debuginfod.exp fails with one of my compilers that 52742 happened to be built without --debug-id being enabled by default. 52743 52744 * Makefile.am (check-DEJAGNU): Pass $CC and other variable on 52745 the runtest command line rather than futilely in the 52746 environment. Add -O0 to CFLAGS_FOR_TARGET. 52747 * Makefile.in: Regenerate. 52748 * testsuite/binutils-all/debuginfod.exp: Compile testprog.c 52749 with -Wl,--build-id. 52750 527512023-04-26 Alan Modra <amodra@gmail.com> 52752 52753 Avoid another -Werror=dangling-pointer 52754 write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used 52755 52756 * write.c (chain_frchains_together_1): Rewrite loop as a do 52757 while to avoid false positive -Wdangling-pointer. 52758 527592023-04-26 GDB Administrator <gdbadmin@sourceware.org> 52760 52761 Automatic date update in version.in 52762 527632023-04-25 Tom Tromey <tromey@adacore.com> 52764 52765 Use scoped_restore in varobj.c 52766 One spot in varobj.c should use scoped_restore to save and restore 52767 input_radix. Note that the current code may fail to restore it on 52768 error, so this patch fixes a latent bug. 52769 52770 Approved-By: Simon Marchi <simon.marchi@efficios.com> 52771 527722023-04-25 Tom Tromey <tromey@adacore.com> 52773 52774 Remove some "goto"s from parse.c 52775 parser_state::push_dollar has some unnecessary "goto"s. Replacing 52776 them cleans up the code. Regression tested on x86-64 Fedora 36. 52777 52778 Approved-By: Simon Marchi <simon.marchi@efficios.com> 52779 527802023-04-25 Michael Matz <matz@suse.de> 52781 52782 section-select: Fix performance problem (PR30367) 52783 when using many wild-statements with non-wildcard filenames we 52784 were running into quadraticness via repeatedly using lookup_name 52785 on a long list of loaded files. I've originally retained using 52786 lookup_name because that preserved existing behaviour most obviously. 52787 In particular in matching wild-statements when using a non-wildcard 52788 filename it matches against local_sym_name, not the filename member. 52789 If the wildspec would have an archive-spec or a wildcard it would use 52790 the filename member, though. Also it would load the named file 52791 (and ignore it, as being not equal to the currently considered 52792 input-statement). 52793 52794 Rewrite this to not use lookup_name but retain the comparison 52795 against local_sym_name with a comment to that effect. 52796 52797 PR 30367 52798 * ldlang.c (walk_wild_section_match): Don't use lookup_name 52799 but directly compare spec and local_sym_name. 52800 528012023-04-25 Jan Beulich <jbeulich@suse.com> 52802 52803 RISC-V: adjust logic to avoid register name symbols 52804 Special casing GPR names in my_getSmallExpression() leads to a number of 52805 inconsistencies. Generalize this by utilizing the md_parse_name() hook, 52806 limited to when instruction operands are being parsed (really: probed). 52807 Then both the GPR lookup there and the yet more ad hoc workaround for 52808 PR/gas 29940 can be removed (including its extension needed for making 52809 the compressed form JAL work again). 52810 52811 RISC-V: test for expected / no unexpected symbols 52812 Both the temporary workaround for PR/gas 29940 and the existing special 52813 casing of GPRs in my_getSmallExpression() aren't really tested anywhere 52814 (i.e. with the workarounds remove testing would still succeed). Nor is 52815 there any test for uses of symbols with names matching GPRs, where such 52816 is permitted. Before altering how this is to be dealt with, install two 52817 testcases covering the expected behavior. (For now this includes only 52818 known affected insns; re-ordering of entries in riscv_opcodes[] could, 52819 however, yield more of them.) 52820 52821 RISC-V: don't recognize bogus relocations 52822 With my_getSmallExpression() consistently and silently failing on 52823 relocation operators not fitting an insn, it is no longer necessary to 52824 hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a 52825 subsequent parsing attempt for another operand combination might 52826 succeed). This also eliminates the latent problem of percent_op_itype[] 52827 and percent_op_stype[] growing a non-identical set of recognized 52828 relocation operators. 52829 52830 RISC-V: avoid redundant and misleading/wrong error messages 52831 The use of a wrong (for the insn) relocation operator (or a future one 52832 which simply isn't recognized by older gas yet) doesn't render the (rest 52833 of the) expression "bad". Furthermore alongside the error from 52834 expression() in most cases the parser would emit another error then 52835 anyway. Suppress the call to my_getExpression() in such a case, 52836 arranging for a guaranteed subsequent error message by marking the 52837 expression "illegal". 52838 52839 RISC-V: drop "percent_op" parameter from my_getOpcodeExpression() 52840 Both callers check for no relocations, so there's no point parsing for 52841 some. Have the function pass percent_op_null into 52842 my_getSmallExpression(). Note that there's no point passing 52843 percent_op_itype: Elsewhere, especially when processing compressed alias 52844 insns ahead of non-alias ones, this has the effect of avoiding "bad 52845 expression" errors when another parsing pass may follow (and succeed). 52846 Here, however, all alternative forms of an insn type will again start 52847 with the same O4 or O2, so avoiding errors earlier on doesn't really 52848 help. Plus constructs with a relocation specifier (as percent_op_itype 52849 would permit) can't be specified anyway, as the scrubber eats the 52850 whitespace between .insn's type and the O4 or O2 expression when that 52851 starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and 52852 riscv_ip() looks only for whitespace when finding the end of a mnemonic. 52853 52854 RISC-V: minor effort reduction in relocation specifier parsing 52855 The sole caller of parse_relocation() has already checked for the % 52856 prefix, so there's no need to check for it again in the strncasecmp() 52857 and there's also no reason to make the involved string literals longer 52858 than necessary. 52859 528602023-04-25 Tom de Vries <tdevries@suse.de> 52861 52862 [gdb/testsuite] Fix timeout in gdb.tui/empty.exp 52863 In test-case gdb.tui/empty.exp we run into: 52864 ... 52865 WARNING: timeout in accept_gdb_output 52866 PASS: gdb.tui/empty.exp: src: 90x40: box 1 52867 ... 52868 52869 We timeout here in Term::resize: 52870 ... 52871 # Due to the strange column resizing behavior, and because we 52872 # don't care about this intermediate resize, we don't check 52873 # the size here. 52874 wait_for "@@ resize done $_resize_count" 52875 ... 52876 because the string we're trying to match is split over two lines: 52877 ... 52878 25 -----------------------------------------------------------------------------+No 52879 26 ne No process In: L?? PC: ?? @@ 52880 27 resize done 0, size = 79x40 52881 28 (gdb) 52882 ... 52883 52884 Fix this by dropping the "@@ " prefix. 52885 52886 Tested on x86_64-linux. 52887 528882023-04-25 Tom de Vries <tdevries@suse.de> 52889 52890 [gdb/testsuite] Fix timeout in gdb.tui/completion.exp 52891 With test-case gdb.tui/completion.exp, we run into: 52892 ... 52893 WARNING: timeout in accept_gdb_output 52894 PASS: gdb.tui/completion.exp: check focus completions 52895 ... 52896 52897 The timeout happens in this command: 52898 ... 52899 Term::command "layout src" 52900 ... 52901 which waits for: 52902 - "(gdb) layout src", and then 52903 - "(gdb) ". 52904 52905 Because the "layout src" command enables the TUI there's just a prompt. 52906 52907 Fix this by using Term::command_no_prompt_prefix. 52908 52909 Tested on x86_64-linux. 52910 529112023-04-25 Tom de Vries <tdevries@suse.de> 52912 52913 [gdb/testsuite] Fix timeout in gdb.tui/new-layout.exp 52914 In test-case gdb.tui/new-layout.exp we run into: 52915 ... 52916 WARNING: timeout in accept_gdb_output 52917 PASS: gdb.tui/new-layout.exp: layout=cmd_only {cmd 1} {} {}: \ 52918 bottom of cmd window is blank 52919 ... 52920 52921 The timeout happens here: 52922 ... 52923 Term::command "layout src" 52924 ... 52925 52926 Before the "layout src" command we have: 52927 ... 52928 Screen Dump (size 80 columns x 24 rows, cursor at column 46, row 7): 52929 0 +-tui-layout.c-------------------------+(gdb) layout example3 52930 1 | 20 { |(gdb) layout src 52931 2 | 21 return 0; |(gdb) winheight cmd 8 52932 3 | 22 } |(gdb) layout example4 52933 4 | 23 |(gdb) layout src 52934 5 | 24 |(gdb) winheight cmd 8 52935 6 | 25 |(gdb) layout example5 52936 7 | 26 |(gdb) 52937 8 | 27 | 52938 9 | 28 | 52939 10 | 29 | 52940 11 | 30 | 52941 12 | 31 | 52942 13 | 32 | 52943 14 | 33 | 52944 15 | 34 | 52945 16 | 35 | 52946 17 | 36 | 52947 18 | 37 | 52948 19 | 38 | 52949 20 | 39 | 52950 21 | 40 | 52951 22 +--------------------------------------+ 52952 23 exec No process In: L?? PC: ?? 52953 ... 52954 and after: 52955 ... 52956 Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 16): 52957 0 +-tui-layout.c-----------------------------------------------------------------+ 52958 1 | 20 { | 52959 2 | 21 return 0; | 52960 3 | 22 } | 52961 4 | 23 | 52962 5 | 24 | 52963 6 | 25 | 52964 7 | 26 | 52965 8 | 27 | 52966 9 | 28 | 52967 10 | 29 | 52968 11 | 30 | 52969 12 | 31 | 52970 13 | 32 | 52971 14 +------------------------------------------------------------------------------+ 52972 15 exec No process In: L?? PC: ?? 52973 16 (gdb) 52974 17 52975 18 52976 19 52977 20 52978 21 52979 22 52980 23 52981 ... 52982 52983 The Term::command "layout src" is waiting to match: 52984 - "(gdb) layout src", and then 52985 - "(gdb) ". 52986 52987 The first part fails to match on a line: 52988 ... 52989 | 26 |(gdb) layout src 52990 ... 52991 because it expects the prompt at the start of the line. 52992 52993 Fix this by allowing the prompt at the start of a window as well. 52994 52995 Tested by x86_64-linux. 52996 529972023-04-25 Tom de Vries <tdevries@suse.de> 52998 52999 [gdb/testsuite] Fix timeout in gdb.tui/main.exp 53000 With test-case gdb.tui/main.exp we run into: 53001 ... 53002 WARNING: timeout in accept_gdb_output 53003 PASS: gdb.tui/main.exp: show main after file 53004 ... 53005 53006 The problem is that this command: 53007 ... 53008 Term::command "file [standard_output_file $testfile]" 53009 ... 53010 tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up 53011 over two lines: 53012 ... 53013 16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma 53014 17 in 53015 18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t 53016 19 ui/main/main... 53017 20 (gdb) 53018 ... 53019 53020 Fix this by matching "Reading symbols from" instead. 53021 53022 Tested on x86_64-linux. 53023 530242023-04-25 Tom de Vries <tdevries@suse.de> 53025 53026 [gdb/testsuite] Fix timeout in gdb.tui/corefile-run.exp 53027 With test-case gdb.tui/corefile-run.exp we run into: 53028 ... 53029 WARNING: timeout in accept_gdb_output 53030 PASS: gdb.tui/corefile-run.exp: load corefile 53031 ... 53032 53033 The timeout happens in this command: 53034 ... 53035 Term::command "core-file $core" 53036 ... 53037 because it tries to match "(gdb) $cmd" but $cmd is split over two lines: 53038 ... 53039 16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co 53040 17 refile-run/corefile-run.core 53041 18 [New LWP 5370] 53042 19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb 53043 20 .tui/corefile-run/coref'. 53044 21 Program terminated with signal SIGTRAP, Trace/breakpoint trap. 53045 22 #0 main () at tui-layout.c:21 53046 23 (gdb) 53047 ... 53048 53049 Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead. 53050 53051 Tested on x86_64-linux. 53052 530532023-04-25 Tom de Vries <tdevries@suse.de> 53054 53055 [gdb/testsuite] Add debug prints in Term::wait_for 53056 The semantics of wait_for are non-trivial, and a bit hard to understand 53057 sometimes. 53058 53059 Add some debug prints in wait_for that make it clear: 53060 - what regexps we're trying to match, 53061 - what strings we compare to the regexps, and 53062 - whether there's a match or mismatch. 53063 53064 I've added this ad-hoc a couple of times, and it seems that it's worth having 53065 readily available. 53066 53067 The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the 53068 RUNTESTFLAGS: 53069 ... 53070 $ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1" 53071 ... 53072 53073 Tested on x86_64-linux. 53074 530752023-04-25 Tom de Vries <tdevries@suse.de> 53076 53077 [gdb/testsuite] Add warning for timeout in accept_gdb_output 53078 In accept_gdb_output we have: 53079 ... 53080 timeout { 53081 # Assume a timeout means we somehow missed the 53082 # expected result, and carry on. 53083 return 0 53084 } 53085 ... 53086 53087 The timeout is silent, and though in some places the return value is checked, 53088 this is not done consistently, and consequently there are silent timeouts 53089 when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp). 53090 53091 Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking 53092 50 seconds overall: 53093 ... 53094 real 1m0.275s 53095 user 0m10.440s 53096 sys 0m1.343s 53097 ... 53098 53099 With an entire testsuite run taking about 30 minutes, that is about 2.5% of 53100 the time spent waiting in TUI tests. 53101 53102 Let's make the timeouts visible using a warning, such that they can be fixed. 53103 53104 Tested on x86_64-linux. 53105 531062023-04-25 GDB Administrator <gdbadmin@sourceware.org> 53107 53108 Automatic date update in version.in 53109 531102023-04-24 Tom de Vries <tdevries@suse.de> 53111 53112 [gdb/testsuite] Fix auto-indent in gdb.gdb/python-helper.exp 53113 When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor 53114 (emacs). 53115 53116 The problem is that this: 53117 ... 53118 if { 1 } { 53119 foo "{" "}"<ENTER>bar 53120 } 53121 ... 53122 produces this: 53123 ... 53124 if { 1 } { 53125 foo "{" "}" 53126 bar 53127 } 53128 ... 53129 53130 Note that this doesn't happen for "{}". 53131 53132 Fix this by using "\{" and "\}". 53133 53134 Tested on x86_64-linux. 53135 531362023-04-24 Tom de Vries <tdevries@suse.de> 53137 53138 [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto 53139 On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with 53140 -O2 -g -flto=auto, I run into: 53141 ... 53142 FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb 53143 FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info 53144 FAIL: gdb.gdb/python-helper.exp: print *type->main_type 53145 ... 53146 53147 Fix the first two FAILs by using $bkptno_numopt_re. 53148 53149 The last FAIL is due to: 53150 ... 53151 (outer-gdb) print *type->main_type^M 53152 A syntax error in expression, near `->main_type'.^M 53153 (outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type 53154 ... 53155 because: 53156 ... 53157 (outer-gdb) print type^M 53158 Attempt to use a type name as an expression^M 53159 ... 53160 53161 Fix this by making the test unresolved if "print type" or 53162 "print type->main_type" doesn't succeed. 53163 53164 On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with 53165 -O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type 53166 not hitting. Fix this by detecting the situation and bailing out. 53167 53168 Tested on x86_64-linux. 53169 531702023-04-24 Tom de Vries <tdevries@suse.de> 53171 53172 [gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multiple 53173 While writing a gdb_test_multiple call in a test-case I tried to use -wrap in 53174 combination with -prompt and found out that it doesn't work, because -wrap uses 53175 "$gdb_prompt $" instead of $prompt_regexp. 53176 53177 Fix this by making -wrap use $prompt_regexp. 53178 53179 Tested on x86_64-linux. 53180 531812023-04-24 Simon Marchi <simon.marchi@efficios.com> 53182 53183 gdb: remove end_stepping_range observable 53184 I noticed that this observable was never notified, which means we can 53185 probably safely remove it. The notification was removed in: 53186 53187 commit 243a925328f8e3184b2356bee497181049c0174f 53188 Author: Pedro Alves <palves@redhat.com> 53189 Date: Wed Sep 9 18:23:24 2015 +0100 53190 53191 Replace "struct continuation" mechanism by something more extensible 53192 53193 print_end_stepping_range_reason in turn becomes unused, so remote it as 53194 well. 53195 53196 Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a 53197 531982023-04-24 Tom de Vries <tdevries@suse.de> 53199 53200 [gdb/testsuite] Use -std=gnu99 for gdb.server/attach-flag.exp 53201 When using a compiler defaulting to -std=gnu90, we run into: 53202 ... 53203 Running gdb.server/attach-flag.exp ... 53204 gdb compile failed, attach-flag.c: In function 'main': 53205 attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \ 53206 in C99 or C11 mode 53207 for (int i = 0; i < NTHREADS; i++) 53208 ^~~ 53209 attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \ 53210 -std=gnu11 to compile your code 53211 ... 53212 53213 Fix this by using -std=gnu99. 53214 53215 Tested on x86_64-linux. 53216 532172023-04-24 Tom de Vries <tdevries@suse.de> 53218 53219 [gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.exp 53220 Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so 53221 require this. 53222 53223 Tested on x86_64-linux. 53224 532252023-04-24 Tom de Vries <tdevries@suse.de> 53226 53227 [gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64le 53228 When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into: 53229 ... 53230 Running gdb/testsuite/gdb.multi/multi-arch.exp ... 53231 gdb compile failed, In file included from /usr/include/features.h:399:0, 53232 from /usr/include/stdio.h:27, 53233 from gdb/testsuite/gdb.multi/hangout.c:18: 53234 /usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \ 53235 No such file or directory 53236 # include <gnu/stubs-32.h> 53237 ^ 53238 compilation terminated. 53239 ... 53240 53241 The problem is that the test-case attempts to use gcc -m32 to produce an 53242 executable while that's not available. 53243 53244 Fix this by: 53245 - introduce a new caching proc have_compile_and_link_flag, and 53246 - using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp. 53247 53248 Tested on: 53249 - x86_64-linux (openSUSE Leap 15.4), and 53250 - powerpc64le-linux (CentOS-7). 53251 532522023-04-24 Tom de Vries <tdevries@suse.de> 53253 53254 [gdb/testsuite] Add basic lmap for tcl < 8.6 53255 With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into: 53256 ... 53257 ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp. 53258 ERROR: invalid command name "lmap" 53259 while executing 53260 "::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \ 53261 dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }" 53262 ... 53263 53264 Fix this by adding basic lmap support for tcl version < 8.6. 53265 53266 Tested on x86_64-linux. 53267 532682023-04-24 Tom de Vries <tdevries@suse.de> 53269 53270 [gdb/testsuite] Don't use string cat in gdb.dwarf2/dw2-abs-hi-pc.exp 53271 Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat: 53272 ... 53273 set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }] 53274 ... 53275 but that's only supported starting tcl 8.6. 53276 53277 Fix this by using "expr" instead: 53278 ... 53279 set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }] 53280 ... 53281 53282 Tested on x86_64-linux. 53283 532842023-04-24 Nick Clifton <nickc@redhat.com> 53285 53286 New georgian translation for the bfd sub-directory 53287 532882023-04-24 Alan Modra <amodra@gmail.com> 53289 53290 Revert "x86: work around compiler diagnosing dangling pointer" 53291 This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269. 53292 532932023-04-24 Alan Modra <amodra@gmail.com> 53294 53295 gcc-13 i386-dis.c warning 53296 opcodes/i386-dis.c: In function ‘print_insn’: 53297 opcodes/i386-dis.c:9865:22: error: storing the address of local 53298 variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=] 53299 53300 * i386-dis.c (print_insn): Clear info->private_data before 53301 returning. 53302 533032023-04-24 Alan Modra <amodra@gmail.com> 53304 53305 asan: segfault in coff_mangle_symbols 53306 The testcase managed to trigger creation of a wild pointer in 53307 coff_slurp_symbol_table. Stop that happening, and fix an unrelated 53308 problem I happened to see in bfd_coff_get_syment. 53309 53310 * coff-bfd.c (bfd_coff_get_syment): Clear fix_value after 53311 converting n_value from a pointer to an index. 53312 * coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check 53313 symbol value before converting to a pointer. 53314 533152023-04-24 Alan Modra <amodra@gmail.com> 53316 53317 objcopy of archives tidy 53318 This makes sure the input element bfd is closed before exiting the 53319 loop copying elements. 53320 53321 * objcopy.c (copy_archive): Rename output_bfd to output_element. 53322 Localise last_element. Close this_element in more error cases. 53323 533242023-04-24 Tom de Vries <tdevries@suse.de> 53325 53326 [gdb/testsuite] Skip dap tests for tcl 8.5 53327 When running the dap tests on a system with tcl 8.5, we run into: 53328 ... 53329 ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp. 53330 ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \ 53331 digit, double, false, graph, integer, list, lower, print, punct, space, \ 53332 true, upper, wideinteger, wordchar, or xdigit 53333 while executing 53334 "string is entier $num" 53335 (procedure "num" line 16) 53336 invoked from within 53337 ... 53338 53339 Fix this by: 53340 - requiring tcl 8.6 in allow_dap_tests, and 53341 - adding the missing require allow_dap_tests in gdb.dap/memory.exp. 53342 53343 Tested on x86_64-linux. 53344 533452023-04-24 Jan Beulich <jbeulich@suse.com> 53346 53347 x86: work around compiler diagnosing dangling pointer 53348 For quite come time print_insn() has been storing the address of a local 53349 variable into info->private_data. Since the compiler can't know that the 53350 field won't be accessed again after print_insn() returns, it may kind of 53351 legitimately diagnose this. And recent enough gcc does as of the 53352 introduction of the fetch_error() return paths (replacing setjmp()-based 53353 error handling). 53354 53355 Utilizing that neither prefix_name() nor i386_dis_printf() actually use 53356 info->private_data, zap the pointer in fetch_error(), after having 53357 retrieved it for local use. 53358 533592023-04-24 GDB Administrator <gdbadmin@sourceware.org> 53360 53361 Automatic date update in version.in 53362 533632023-04-23 YunQiang Su <yunqiang.su@cipunited.com> 53364 53365 MIPS: fix loongson3 llsc workaround 53366 -mfix-looongson3-llsc may add sync instructions not needed on some 53367 asm code with lots of debug info. 53368 53369 PR: 30153 53370 * gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic. 53371 533722023-04-23 YunQiang Su <yunqiang.su@cipunited.com> 53373 53374 MIPS: default output r6 obj if the triple is r6 53375 If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output 53376 r6 objects by default. 53377 The triples with vendor `img` should do same. 53378 53379 The examples include: 53380 as xx.s -o xx.o 53381 ld -r -b binary xx.dat -o xx.o 53382 533832023-04-23 YunQiang Su <yunqiang.su@cipunited.com> 53384 53385 MIPS: support mips*64 as CPU and gnuabi64 as ABI 53386 For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is 53387 used as the cpu name in triple. 53388 Let's recognize them by `mips*64*(el)`. 53389 53390 For 64bit Ports, like Debian's mips64el and mips64r6el ports, 53391 `gnuabi64` is used as the abi section. 53392 Let's use N64 abi by default for the triple with gnuabi64. 53393 533942023-04-23 mengqinggang <mengqinggang@loongson.cn> 53395 53396 LoongArch: Fix loongarch32 test fails 53397 Regenerated macro_op_32.d and add skip loongarch64-*-*. 53398 53399 gas/ChangeLog: 53400 53401 * testsuite/gas/loongarch/macro_op_32.d: Regenerated. 53402 53403 ld/ChangeLog: 53404 53405 * testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated. 53406 534072023-04-23 GDB Administrator <gdbadmin@sourceware.org> 53408 53409 Automatic date update in version.in 53410 534112023-04-22 Tom de Vries <tdevries@suse.de> 53412 53413 [gdb/testsuite] Remove debug prints in gdb_find_gdc 53414 When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used 53415 rather than dejagnu's copy (mimicing what happens with an older dejagnu 53416 without find_gdc), I run into these debug prints: 53417 ... 53418 Tool Root: /data/vries/gdb/leap-15-4/build 53419 CC: gdc 53420 ... 53421 53422 Remove these. 53423 53424 Tested on x86_64-linux. 53425 534262023-04-22 WANG Rui <r@hev.cc> 53427 53428 gdb: Fix false match issue in skip_prologue_using_linetable 53429 [ Changes in v2: 53430 - rebase on trunk 53431 Changes in v3: 53432 - add test-case ] 53433 53434 We should exclude matches to the ending PC to prevent false matches with the 53435 next function, as prologue_end is located at the end PC. 53436 53437 <fun1>: 53438 0x00: ... <-- start_pc 53439 0x04: ... 53440 0x08: ... <-- breakpoint 53441 0x0c: ret 53442 <fun2>: 53443 0x10: ret <-- end_pc | prologue_end of fun2 53444 53445 Tested on x86_64-linux. 53446 53447 Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1]) 53448 Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case) 53449 Approved-by: Kevin Buettner <kevinb@redhat.com> 53450 53451 [1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html 53452 53453 PR symtab/30369 53454 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369 53455 534562023-04-22 GDB Administrator <gdbadmin@sourceware.org> 53457 53458 Automatic date update in version.in 53459 534602023-04-21 Simon Marchi <simon.marchi@efficios.com> 53461 53462 gdb: remove language_auto 53463 I think that the language_auto enumerator and the auto_language class 53464 can be removed. There isn't really an "auto" language, it's only a 53465 construct of the "set language" command to say "pick the appropriate 53466 language automatically". But "auto" is never the current language. The 53467 `current_language` points to the current effective language, and the 53468 fact that we're in "auto language" mode is noted by the language_mode 53469 global. 53470 53471 - Change set_language to handle the "auto" (and "local", which is a 53472 synonym) early, instead of in the for loop. I think it makes the two 53473 cases (auto vs explicit language) more clearly separated anyway. 53474 53475 - Adjust add_set_language_command to hard-code the "auto" string, 53476 instead of using the "auto" language definition. 53477 53478 - Remove auto_language, rename auto_or_unknown_language to 53479 unknown_language and move the bits of the existing unknown_language 53480 in there. 53481 53482 - Remove the set_language at the end of _initialize_language. I think 53483 it's not needed, because we call set_language in gdb_init, after all 53484 _initialize functions are called. There is some chance that an 53485 _initialize function that runs after _initialize_language implicitly 53486 depends on current_language being set, but my testsuite runs haven't 53487 found anything like that. 53488 53489 - Use language_unknown instead of language_auto when creating a minimal 53490 symbol (minimal_symbol_reader::record_full). I think that this value 53491 is used to indicate that we don't know the symbol of the minimal 53492 symbol (yet), so language_unknown makes sense to me. Update a 53493 condition accordingly in ada-lang.c. symbol_find_demangled_name also 53494 appears to "normalize" this value from "unknown" to "auto", remove 53495 that part and update the condition to just check for 53496 language_unknown. 53497 53498 Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034 53499 Reviewed-By: Tom Tromey <tom@tromey.com> 53500 535012023-04-21 Simon Marchi <simon.marchi@efficios.com> 53502 53503 gdb: switch "set language" to getter/setter 53504 The `language` global variable is mostly a scratch variable used for the 53505 setting. The source of truth is really current_language and 53506 language_mode (auto vs manual), which are set by the 53507 set_language_command callback. 53508 53509 Switch the setting to use the add_setshow_enum_cmd overload that takes a 53510 value getter and setter. 53511 53512 Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b 53513 Reviewed-By: Tom Tromey <tom@tromey.com> 53514 535152023-04-21 Simon Marchi <simon.marchi@efficios.com> 53516 53517 gdb: remove return value of set_language 53518 set_language returns the previous language, but nothing uses it. Remove 53519 the return value. This lets us remove the assignment to 53520 current_language, in _initialize_language. 53521 53522 Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17 53523 Reviewed-By: Tom Tromey <tom@tromey.com> 53524 535252023-04-21 Tom de Vries <tdevries@suse.de> 53526 53527 [gdb/testsuite] Add make-check-all.sh 53528 Directory gdb/testsuite/boards contains a number of host/target boards, which 53529 run a test-case (or test-cases) in a different way. 53530 53531 The benefits of using these boards are: 53532 - improving test coverage of gdb, 53533 - making the testsuite more robust, and 53534 - making sure the test-cases work for non-native and remote setups, if 53535 possible. 53536 53537 Each board is slightly different, and developers need to learn how to use each 53538 one, what parameters to pass and how, and which ones can be used in 53539 combination with each other. This is a threshold to start using them. 53540 53541 And then there quite a few, so I suppose typically only a few will be used by 53542 each developer. 53543 53544 Add script gdb/testsuite/make-check-all.sh, that's intended to function as a 53545 drop-in replacement of make check, while excercising all host/target boards in 53546 gdb/testsuite/boards. 53547 53548 An example of make-check-all.sh for one test-case is: 53549 ... 53550 $ ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp 53551 LOCAL: 53552 # of expected passes 8 53553 TARGET BOARD: cc-with-gdb-index 53554 # of expected passes 8 53555 ... 53556 HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver 53557 # of expected passes 8 53558 HOST/TARGET BOARD: local-remote-host-native 53559 # of expected passes 8 53560 ... 53561 53562 Shell-checked and tested on x86_64-linux. 53563 53564 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 53565 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 53566 535672023-04-21 Tom de Vries <tdevries@suse.de> 53568 53569 [gdb/cli] Add maint info screen 53570 While working on PRs tui/30337 and cli/30346 I came across various notions of 53571 width in gdb, as reported by gdb, readline, curses and the environment 53572 variables. 53573 53574 As for gdb, readline and the environment variables, the way things work 53575 is: 53576 - Gdb asks readline to detect screen size, 53577 - readline sets the actual screen size in the environment variables 53578 COLUMNS and LINES, 53579 - readline reports back a screen size to gdb, which may have one column 53580 less than the actual screen size, to deal with lack of auto-wrap. 53581 This becomes gdb's notion of screen size (in other words the point where 53582 we can expect the gdb command line to wrap), 53583 - Gdb then explicitly sets readline's screen size, which readline itself may 53584 adjust to deal with lack of auto-wrap. This becomes readlines notion 53585 of screen size (well, internally the unadjusted one, but it'll report back 53586 the adjusted one). 53587 53588 Add a command "maint info screen" that prints these notions, both for width 53589 and height. 53590 53591 For TERM=xterm we have: 53592 ... 53593 $ TERM=xterm gdb -ex "maint info screen" 53594 Number of characters gdb thinks are in a line is 118. 53595 Number of characters readline reports are in a line is 118. 53596 Number of characters curses thinks are in a line is 118. 53597 Number of characters environment thinks are in a line is 118 (COLUMNS). 53598 Number of lines gdb thinks are in a page is 27. 53599 Number of lines readline reports are in a page is 27. 53600 Number of lines curses thinks are in a page is 27. 53601 Number of lines environment thinks are in a page is 27 (LINES). 53602 ... 53603 53604 And for TERM=ansi: 53605 ... 53606 $ TERM=ansi gdb -ex "maint info screen" 53607 Number of characters gdb thinks are in a line is 117. 53608 Number of characters readline reports are in a line is 116. 53609 Number of characters curses thinks are in a line is 118. 53610 Number of characters environment thinks are in a line is 118 (COLUMNS). 53611 Number of lines gdb thinks are in a page is 27. 53612 Number of lines readline reports are in a page is 27. 53613 Number of lines curses thinks are in a page is 27. 53614 Number of lines environment thinks are in a page is 27 (LINES). 53615 ... 53616 53617 [ The fact that we have "characters readline reports are in a line is 116" is 53618 is due to gdb making readline adjust twice for the lack of auto-wrap, this is 53619 PR cli/30346. 53620 53621 Likewise we can detect tui/30337 by doing a resize in TUI mode and doing 53622 "maint info screen": 53623 ... 53624 Number of characters characters curses thinks are in a line is 110. 53625 Number of characters environment thinks are in a line is 111 (COLUMNS). ] 53626 53627 And for TERM=ansi, with width and heigth set to 0: 53628 ... 53629 Number of characters gdb thinks are in a line is 4294967295 (unlimited). 53630 Number of characters readline reports are in a line is 32766 (unlimited - 1). 53631 Number of characters curses thinks are in a line is 118. 53632 Number of characters environment thinks are in a line is 118 (COLUMNS). 53633 Number of lines gdb thinks are in a page is 4294967295 (unlimited). 53634 Number of lines readline reports are in a page is 32767 (unlimited). 53635 Number of lines curses thinks are in a page is 27. 53636 Number of lines environment thinks are in a page is 27 (LINES). 53637 ... 53638 53639 [ Note that when doing a resize by say maximizing or de-maximizing a terminal, 53640 all reported values are updated, except for curses when not in TUI mode. 53641 53642 Maybe that means there's a bug. If not, then maybe we should not print 53643 the curses lines unless in TUI mode, or annotate those lines such that it's 53644 clear that the values may be not up-to-date. ] 53645 53646 I'd like to use this command in the regression test for PR cli/30346. 53647 53648 Tested on x86_64-linux. 53649 53650 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 53651 Reviewed-By: Tom Tromey <tom@tromey.com> 53652 536532023-04-21 Tom Tromey <tromey@adacore.com> 53654 53655 Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.c 53656 A recent change in opcodes/i386-dis.c caused a build failure on my 53657 x86-64 Fedora 36 system, which uses: 53658 53659 $ gcc --version 53660 gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4) 53661 [...] 53662 53663 The error is: 53664 53665 ../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’: 53666 ../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized] 53667 12705 | disp = val & 0x8000 ? val - 0x10000 : val; 53668 | ~~~~^~~~~~~~ 53669 53670 This patch fixes the warning. 53671 53672 opcodes/ChangeLog 53673 2023-04-21 Tom Tromey <tromey@adacore.com> 53674 53675 * i386-dis.c (OP_J): Check result of get16. 53676 536772023-04-21 Tom Tromey <tromey@adacore.com> 53678 53679 Use entry values for 32-bit PPC struct return 53680 AdaCore has a local patch for PPC "finish", but last year, Ulrich 53681 Weigand pointed out that this patch was incorrect. It may work for 53682 simple functions like the one in the internal test, but nothing 53683 guarantees that r3 will be preserved by the callee, so checking r3 on 53684 exit is not always correct. 53685 53686 This patch fixes the problem using the same approach as PPC64: use the 53687 entry value of r3, if available. Ulrich confirmed this matches the 53688 PPC32 ABI. 53689 536902023-04-21 Tom Tromey <tromey@adacore.com> 53691 53692 Handle erroneous DW_AT_call_return_pc 53693 On PPC64, with the test case included in an earlier patch, we found 53694 that "finish" would still not correctly find the return value via 53695 entry values. 53696 53697 The issue is simple. The compiler emits: 53698 53699 0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large> 53700 0x00000000100032bc <+32>: nop 53701 0x00000000100032c0 <+36>: li r9,42 53702 53703 ... but the DWARF says: 53704 53705 <162a> DW_AT_call_return_pc: 0x100032c0 53706 53707 That is, the declared return PC is one instruction past the actual 53708 return PC. 53709 53710 This patch adds a new arch hook to handle this scenario, and 53711 implements it for PPC64. Some care is taken so that GDB will continue 53712 to work if this compiler bug is fixed. A GCC patch is here: 53713 53714 https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html 53715 53716 No check for 'nop' is done, as subsequent discussion revealed that the 53717 linker might replace this with another instruction. 53718 537192023-04-21 Tom Tromey <tromey@adacore.com> 53720 53721 Handle function descriptors in call_site_target 53722 call_site_target::iterate_over_addresses may look up a minimal symbol. 53723 On platforms like PPC64 that use function descriptors, this may find 53724 an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr 53725 to convert from a function descriptor to the address recorded at the 53726 call site. 53727 53728 I've added a new test case that is based on the internal AdaCore test 53729 that provoked this bug. However, I'm unable to test it as-is on 53730 PPC64. 53731 537322023-04-21 Jan Beulich <jbeulich@suse.com> 53733 53734 x86: drop (explicit) BFD64 dependency from disassembler 53735 get64() is unreachable when !BFD64 (due to a check relatively early in 53736 print_insn()). Let's avoid the associated #ifdef-ary (or else we should 53737 extend it to remove more dead code). 53738 53739 x86: drop use of setjmp() from disassembler 53740 With the longjmp() uses all gone, the setjmp() isn't necessary anymore 53741 either. 53742 537432023-04-21 Jan Beulich <jbeulich@suse.com> 53744 53745 x86: change fetch error handling for get<N>() 53746 Make them return boolean and convert FETCH_DATA() uses to fetch_code(). 53747 With this no further users of FETCH_DATA() remain, so the macro and its 53748 backing function are dropped as well. 53749 53750 Leave value types as they were for the helper functions, even if I don't 53751 think that beyond get64() use of bfd_{,signed_}vma is really necessary. 53752 With type change of "disp" in OP_E_memory(), change the 2nd parameter of 53753 print_displacement() to a signed type as well, though (eliminating the 53754 need for a local variable of signed type). This also eliminates the need 53755 for custom printing of '-' in Intel syntax displacement expressions. 53756 53757 While there drop forward declarations which aren't really needed. 53758 537592023-04-21 Jan Beulich <jbeulich@suse.com> 53760 53761 x86: change fetch error handling when processing operands 53762 Make the handler functions all return boolean and convert FETCH_DATA() 53763 uses to fetch_code(). 53764 53765 x86: change fetch error handling in get_valid_dis386() 53766 Introduce a special error indicator node, for the sole (real) caller 53767 to recognize and act upon. 53768 53769 x86: change fetch error handling in ckprefix() 53770 Use a tristate (enum) return value type to be able to express all three 53771 cases which are of interest to the (sole) caller. This also allows doing 53772 away with the abuse of "rex_used". 53773 537742023-04-21 Jan Beulich <jbeulich@suse.com> 53775 53776 x86: change fetch error handling in top-level function 53777 ... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch 53778 error handling is problematic, as per 53779 https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start 53780 using more conventional error handling instead. 53781 53782 Also introduce a fetch_modrm() helper, for subsequent re-use. 53783 537842023-04-21 Jan Beulich <jbeulich@suse.com> 53785 53786 x86: move fetch error handling into a helper function 53787 ... such that it can be used from other than the setjmp() error handling 53788 path. 53789 53790 Since I'd like the function's parameter to be pointer-to-const, two 53791 other functions need respective constification then, too (along with 53792 needing to be forward-declared). 53793 537942023-04-21 Jan Beulich <jbeulich@suse.com> 53795 53796 bfd: fix STRICT_PE_FORMAT build 53797 A semicolon was missing and "name" needs to be pointer-to-const. While 53798 adding "const" there, also add it for "sec". 53799 538002023-04-21 Lifang Xia <lifang_xia@linux.alibaba.com> 53801 53802 RISC-V: Optimize relaxation of gp with max_alignment. 53803 This should be the first related issue, which posted in riscv-gnu-toolchain, 53804 https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497 53805 53806 If the output sections are not between gp and the symbol, then their alignments 53807 shouldn't affect the gp relaxation. However, this patch improves this idea 53808 even more, it limits the range to the gp+-2k, which means only the output 53809 section which are in the [gp-2K, gp+2K) range need to be considered. 53810 53811 Even if the output section candidates may be different for each relax passes, 53812 the symbol that can be relaxed ar this round will not be truncated at next 53813 round. That is because this round you can do relaxation which means that the 53814 section where the symbol is located is within the [gp-2K, gp+2K) range, so all 53815 the output section alignments between them should be considered. In other 53816 words, if the alignments between them may cause truncated, then we should 53817 already preserve the size and won't do the gp relaxation this time. 53818 53819 This patch can resolve the github issue which mentioned above, and also passed 53820 all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and 53821 safe enough to commit. 53822 53823 Originally, this patch also do the same optimization for the call relaxations, 53824 https://sourceware.org/pipermail/binutils/2022-October/123918.html 53825 But just in case there is something that has not been considered, we only 53826 deal with the gp relaxation at this time. 53827 53828 bfd/ 53829 * elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma, 53830 max_alignment_for_gp. It is used to record the maximum alignment of 53831 the output sections, which are in the [gp-2K, gp+2k) range. 53832 (riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1. 53833 (_bfd_riscv_get_max_alignment): Added new parameter, gp. If gp is 53834 zero, then all the output section alignments are possible candidates; 53835 Otherwise, only the output sections which are in the [gp-2K, gp+2K) 53836 range need to be considered. 53837 (_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the 53838 non-zero gp if the max_alignment_for_gp is -1. 53839 (_bfd_riscv_relax_pc): Likewise. 53840 (_bfd_riscv_relax_section): Record the first input section, so that 53841 we can reset the max_alignment_for_gp for each repeated relax passes. 53842 ld/ 53843 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 53844 * testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase. It fails 53845 without this patch. 53846 538472023-04-21 Jan Beulich <jbeulich@suse.com> 53848 53849 ld: add missing period after @xref 53850 At least older versions of one of the doc generation tools complain 53851 (warn) about it missing. 53852 538532023-04-21 Alan Modra <amodra@gmail.com> 53854 53855 Keeping track of rs6000-coff archive element pointers 53856 rs6000-coff archives use a linked list of file offsets, where each 53857 element points to the next element. The idea is to allow updating of 53858 large archives quickly without rewriting the whole archive. (binutils 53859 ar does not do this.) Unfortunately this is an easy target for 53860 fuzzers to create an archive that will cause ar or any other tool 53861 processing archives to hang. I'd implemented guards against pointing 53862 back to the previous element, but of course that didn't last long. 53863 53864 So this patch implements a scheme to keep track of file offset ranges 53865 used by elements as _bfd_read_ar_hdr is called for each element. See 53866 the add_range function comment. I needed a place to stash the list, 53867 so chose the obvious artdata.tdata backend extension to archive's 53868 tdata, already used by xcoff. That involved a little cleanup, because 53869 while it would be possible to continue using different artdata.tdata 53870 for the big and small archives, it's nicer to use a union. 53871 53872 If anyone is concerned this list of element ranges might grow large 53873 and thus significantly slow down the tools, adjacent ranges are 53874 merged. In fact something like "ar t" will only ever have one range 53875 on xcoff archives generated by binutils/ar. I agree there might still 53876 be a problem with ld random element access via the armap. 53877 53878 include/ 53879 * coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof. 53880 (SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise. 53881 (struct ar_ranges, struct xcoff_artdata): New. 53882 (x_artdata): Define. 53883 (xcoff_big_format_p): Rewrite. 53884 (xcoff_ardata, xcoff_ardata_big): Delete. 53885 bfd/ 53886 * coff-rs6000.c: Replace uses of xcoff_ardata and 53887 xcoff_ardata_big throughout file. 53888 (_bfd_xcoff_archive_p): Adjust artdata.tdata allocation. 53889 (add_range): New function. 53890 (_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak. 53891 (_bfd_xcoff_openr_next_archived_file): Remove old sanity 53892 checks. Set up range for header. 53893 (xcoff_write_archive_contents_old): Make the temporary 53894 artdata.tdata used here to pass info down to 53895 _bfd_compute_and_write_armap a struct xcoff_artdata. 53896 (xcoff_write_archive_contents_big): Likewise. 53897 * coff64-rs6000.c: Replace uses of xcoff_ardata and 53898 xcoff_ardata_big throughout file. 53899 (xcoff64_archive_p): Adjust artdata.tdata allocation. 53900 539012023-04-21 Alan Modra <amodra@gmail.com> 53902 53903 Delete struct artdata archive_head 53904 This element is unused. Ideally we'd be moving archive_head and 53905 other archive specific fields from struct bfd to here, but that's a 53906 much larger change than this little bit of cleanup. 53907 53908 * libbfd-in.h (struct artdata): Delete archive_head. 53909 * libbfd.h: Regenerate. 53910 * archive.c, 53911 * coff-rs6000.c, 53912 * coff64-rs6000.c: Delete comments mentioning artdata archive_head. 53913 539142023-04-21 GDB Administrator <gdbadmin@sourceware.org> 53915 53916 Automatic date update in version.in 53917 539182023-04-20 Nick Clifton <nickc@redhat.com> 53919 53920 Add a SECURITY.txt file describing the GNU Binutils' project's stance on security related bugs. 53921 539222023-04-20 Jan Beulich <jbeulich@suse.com> 53923 53924 x86: adjust an ILP32 testcase using .insn 53925 In commit 6967633c8b49 ("x86: convert testcases to use .insn") an ILP32 53926 clone of a testcase was missed in the set of tests needing --divide 53927 added. 53928 53929 Reported-by: Clément Chigot <chigot@adacore.com> 53930 539312023-04-20 GDB Administrator <gdbadmin@sourceware.org> 53932 53933 Automatic date update in version.in 53934 539352023-04-20 Alan Modra <amodra@gmail.com> 53936 53937 sh4-linux segfaults running ld testsuite 53938 Segmentation fault 53939 FAIL: pr22269-1 (static pie undefined weak) 53940 and others running "visibility (hidden undef)" tests 53941 53942 No code has any right to access bfd_link_hash_entry u.def without 53943 first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient. 53944 53945 * elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative 53946 relocs in GOT unless symbol is defined. 53947 539482023-04-20 Alan Modra <amodra@gmail.com> 53949 53950 PR30343 infrastructure 53951 Make ldemul_before_plugin_all_symbols_read more useful. 53952 53953 * ldlang.c (lang_process): Move call to 53954 ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS. 53955 Allow backends to add to gc_sym_list before handling entry sym. 53956 * ldelf.c (ldelf_before_plugin_all_symbols_read): Test 53957 lto_plugin_active. 53958 539592023-04-20 Alan Modra <amodra@gmail.com> 53960 53961 ubsan: signed integer overflow in display_debug_lines_raw 53962 This one was caused by me unnecessarily promoting an "int adv" to 53963 "int64_t adv". The expression overflowing was 4259 + 9223372036854775807 53964 with the left number being unsigned int. 53965 53966 * dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short 53967 with uint16_t and unsigned char with uint8_t. Make li_line_base 53968 an int8_t. 53969 * dwarf.c (display_debug_lines_raw): Revert "adv" back to an int. 53970 539712023-04-20 Alan Modra <amodra@gmail.com> 53972 53973 Yet another out-of-memory fuzzed object 53974 Do I care about out of memory conditions triggered by fuzzers? Not 53975 much. Your operating system ought to be able to handle it by killing 53976 the memory hog. Oh well, this one was an element of a coff-alpha 53977 archive that said it was a little less that 2**64 in size. The 53978 coff-alpha compression scheme expands at most 8 times, so we can do 53979 better in bfd_get_file_size. 53980 53981 * bfdio.c (bfd_get_file_size): Assume elements in compressed 53982 archive can only expand a maximum of eight times. 53983 * coffgen.c (_bfd_coff_get_external_symbols): Sanity check 53984 size of symbol table agains file size. 53985 539862023-04-20 Alan Modra <amodra@gmail.com> 53987 53988 buffer overflow in print_symname 53989 * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate 53990 string sections. 53991 539922023-04-19 Indu Bhagat <indu.bhagat@oracle.com> 53993 53994 libsframe: minor formatting fixes in sframe_encoder_write_fre 53995 libsframe/ 53996 * sframe.c (sframe_encoder_write_fre): Formatting fixes for 53997 readability. 53998 53999 libsframe: use consistent function argument names 54000 libsframe/ 54001 * sframe.c (sframe_decoder_get_header): Use consistent function 54002 arg names. 54003 (sframe_decoder_free): Likewise. 54004 (sframe_encode): Use more appropriate var name. 54005 540062023-04-19 Indu Bhagat <indu.bhagat@oracle.com> 54007 54008 sframe: correct some typos 54009 include/ 54010 * sframe.h: Correct a typo. 54011 54012 libsframe/ 54013 * sframe.c: Likewise. 54014 540152023-04-19 Indu Bhagat <indu.bhagat@oracle.com> 54016 54017 libsframe: use return type of bool for predicate functions 54018 libsframe/ 54019 * sframe.c (sframe_header_sanity_check_p): Change return type to 54020 bool. 54021 (sframe_fre_sanity_check_p): Likewise. 54022 54023 gas: sframe: fix comment 54024 54025 gas: sframe: use ATTRIBUTE_UNUSED consistently 54026 gas/ 54027 * gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED 54028 consistently. 54029 (output_sframe): Likewise. 54030 (sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED. 54031 540322023-04-19 Tom Tromey <tromey@adacore.com> 54033 54034 Remove adjust_type_signedness 54035 I happened across adjust_type_signedness, which may be used to modify 54036 a type when printing an Ada value. Modifying a type like this is a 54037 bad idea -- they should normally be considered immutable. Removing 54038 this function still passes both the dejagnu and internal AdaCore 54039 tests, though, so this patch drops it. 54040 54041 As this was reviewed internally, and only affect Ada, I am checking it 54042 in. 54043 540442023-04-19 Nick Clifton <nickc@redhat.com> 54045 54046 Fix: readelf: loc_offset XX too big 54047 PR 30355 54048 * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section. 54049 540502023-04-19 Jan Beulich <jbeulich@suse.com> 54051 54052 gas: document that get_symbol_name() can clobber the input buffer 54053 Callers which want to make further parsing attempts at the buffer passed 54054 to the function need to be aware that due to the potential of string 54055 concatenation the input buffer may be altered in ways beyond what can be 54056 undone by putting back at *input_line_pointer the character that the 54057 function returns. 54058 540592023-04-19 Jan Beulich <jbeulich@suse.com> 54060 54061 x86: parse_register() must not alter the parsed string 54062 This reverts the code change done by 100f993c53a5 ("x86: Check 54063 unbalanced braces in memory reference"), which wrongly identified 54064 e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T 54065 syntax") as the root cause of PR gas/30248. (The testcase is left in 54066 place, no matter that it's at best marginally useful in that shape.) 54067 54068 The problem instead is that parse_register() alters the string handed to 54069 it, thus breaking valid assumptions in subsequent parsing code. Since 54070 the function's behavior is a result of get_symbol_name()'s, make a copy 54071 of the incoming string before invoking that function. 54072 54073 Like for parse_real_register() follow the model of strtol() et al: input 54074 string is const-qualified to signal that the string isn't altered, but 54075 the returned "end" pointer is not const-qualified, requiring const to be 54076 cast away (which generally is a bad idea, but the alternative would 54077 again be more convoluted code). 54078 540792023-04-19 Jan Beulich <jbeulich@suse.com> 54080 54081 x86: parse_real_register() does not alter the parsed string 54082 Follow the model of strtol() et al - input string is const-qualified to 54083 signal that the string isn't altered, but the returned "end" pointer is 54084 not const-qualified, requiring const to be cast away (which generally is 54085 a bad idea, but the alternative would be more convoluted code). 54086 540872023-04-19 Nick Clifton <nickc@redhat.com> 54088 54089 Updated Hungarian translation for the gprof directory 54090 540912023-04-19 GDB Administrator <gdbadmin@sourceware.org> 54092 54093 Automatic date update in version.in 54094 540952023-04-18 Simon Marchi <simon.marchi@efficios.com> 54096 54097 gdb: re-format Python code with black 23 54098 Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b 54099 541002023-04-18 Carl Love <cel@us.ibm.com> 54101 54102 PowerPC: fix _Float128 type output string 54103 PowerPC supports two 128-bit floating point formats, the IBM long double 54104 and IEEE 128-bit float. The issue is the DWARF information does not 54105 distinguish between the two. There have been proposals of how to extend 54106 the DWARF information as discussed in 54107 54108 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194 54109 54110 but has not been fully implemented. 54111 54112 GCC introduced the _Float128 internal type as a work around for the issue. 54113 The workaround is not transparent to GDB. The internal _Float128 type 54114 name is printed rather then the user specified long double type. This 54115 patch adds a new gdbarch method to allow PowerPC to detect the GCC 54116 workaround. The workaround checks for "_Float128" name when reading the 54117 base typedef from the die_info. If the workaround is detected, the type 54118 and format fields from the _Float128 typedef are copied to the long 54119 double typedef. The same is done for the complex long double typedef. 54120 54121 This patch fixes 74 regression test failures in 54122 gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the 54123 default on GCC. It fixes one regression test failure in 54124 gdb.base/complex-parts.exp. 54125 54126 The patch has been tested on Power 10 where GCC defaults to IEEE Float 54127 128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The 54128 patch as also been tested on X86-64 with no new regression failures. 54129 541302023-04-18 mengqinggang <mengqinggang@loongson.cn> 54131 54132 Symbols with GOT relocatios do not fix adjustbale 54133 gas 54134 * config/tc-loongarch.c (loongarch_fix_adjustable): Symbols with GOT relocatios do not fix adjustbale. 54135 * testsuite/gas/loongarch/macro_op_large_abs.d: Regenerated. 54136 * testsuite/gas/loongarch/macro_op_large_pc.d: Regenerated. 54137 ld 54138 * testsuite/ld-loongarch-elf/macro_op.d: Regenerated. - 54139 541402023-04-18 Thomas Koenig <tkoenig@netcologne.de> 54141 54142 Assembler Internal Docs: Describe handling of opcodes for relaxation a bit better. 54143 541442023-04-18 Kito Cheng <kito.cheng@sifive.com> 54145 54146 RISC-V: Cache the latest mapping symbol and its boundary. 54147 This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188 54148 54149 Current flow: 54150 1) Scan any mapping symbol less than this instruciton. 54151 2) If not found, did a backward search. 54152 54153 The flow seems not big issue, let run an example here: 54154 54155 $x: 54156 0x0 a <--- Found at step 1 54157 0x4 b <--- Not found in step 1, but found at step 2 54158 0x8 c <--- Not found in step 1, but found at step 2 54159 $d 54160 0x12 .word 1234 <-- Found at step 1 54161 54162 The instruciton didn't have the same address with mapping symbol will 54163 still did backward search again and again. 54164 54165 So the new flow is: 54166 1) Use the last mapping symbol status if the address is still within the range 54167 of the current mapping symbol. 54168 2) Scan any mapping symbol less than this instruciton. 54169 3) If not found, did a backward search. 54170 4) If a proper mapping symbol is found in either step 2 or 3, find its boundary, 54171 and cache that. 54172 54173 Use the same example to run the new flow again: 54174 54175 $x: 54176 0x0 a <--- Found at step 2, the boundary is 0x12 54177 0x4 b <--- Cache hit at step 1, within the boundary. 54178 0x8 c <--- Cache hit at step 1, within the boundary. 54179 $d 54180 0x12 .word 1234 <-- Found at step 2, the boundary is the end of section. 54181 54182 The disassemble time of the test cases has been reduced from ~20 minutes to ~4 54183 seconds. 54184 54185 opcode/ChangeLog 54186 PR 30282 54187 * riscv-dis.c (last_map_symbol_boundary): New. 54188 (last_map_state): New. 54189 (last_map_section): New. 54190 (riscv_search_mapping_symbol): Cache the result of latest 54191 mapping symbol. 54192 541932023-04-18 Alan Modra <amodra@gmail.com> 54194 54195 objdump use of uninitialised value in pr_string_field 54196 PR 30365 54197 * rdcoff.c (parse_coff_struct_type): Leave bitsize zero when no 54198 auxents. 54199 54200 objdump buffer overflow in fetch_indexed_string 54201 PR 30361 54202 * dwarf.c (fetch_indexed_string): Sanity check string index. 54203 542042023-04-18 GDB Administrator <gdbadmin@sourceware.org> 54205 54206 Automatic date update in version.in 54207 542082023-04-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 54209 54210 gprofng: 30360 Seg. Fault when application uses std::thread 54211 We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.). 54212 Some of these functions have versions. For example, 54213 54214 % nm -D /lib64/gprofng/libgp-collector.so | grep thread_create@ | sort 54215 000000000004b420 T pthread_create@GLIBC_2.34 54216 000000000004b490 T pthread_create@GLIBC_2.17 54217 000000000004b500 T pthread_create@GLIBC_2.2.5 54218 000000000004b570 T pthread_create@GLIBC_2.1 54219 000000000004b5e0 T pthread_create@GLIBC_2.0 54220 54221 Our library does not set the default version for symbols. 54222 This is correct because we don't know which libC will be used. 54223 54224 gcc and g++ links differently the version symbols when the default version is 54225 not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using 54226 our pthread_create@GLIBC_2.0 by default. 54227 54228 The current implementation of the interposed functions is: 54229 If we are in our pthread_create@GLIBC_<NN>, 54230 we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call 54231 the same function from libC. 54232 In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC. 54233 We need to call the default version symbol from libC. 54234 54235 gprofng/ChangeLog 54236 2023-04-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 54237 54238 PR gprofng/30360 54239 * libcollector/iotrace.c: Find and call a default libC version symbol. 54240 * libcollector/dispatcher.c: Likewise. 54241 * libcollector/iotrace.c: Likewise. 54242 * libcollector/linetrace.c: Likewise. 54243 * libcollector/mmaptrace.c: Likewise. 54244 * libcollector/synctrace.c: Likewise. 54245 * libcollector/collector.h (REAL_DCL): Remove an unused argument. 54246 542472023-04-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 54248 54249 gprofng: Update documentation 54250 This patch addresses bugzilla 29521: 54251 Bug 29521 - [docs] man pages are not in the release tarball 54252 54253 The dependence on help2man to create the man pages has been eliminated. 54254 All man pages are now written in Texinfo. Texi2pod and pod2man are used 54255 to generate the man pages from the source. 54256 54257 The user guide has been significantly expanded. It also includes all 54258 the man pages. These are formatted appropriately in the INFO, PDF, and 54259 HTML formats. 54260 54261 The index in the user guide has been enhanced to include an overview 54262 of all options and commands that have been documented so far. 54263 54264 The work on the documentation has not been completed, but this is 54265 a significant step forward. 54266 54267 gprofng/ChangeLog 54268 2023-04-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 54269 54270 PR gprofng/29521 54271 * doc/Makefile.am: Build documentation. 54272 * doc/gprofng.texi: Update documentation. 54273 * doc/version.texi: Likewise. 54274 * src/Makefile.am: Move the man pages generation to doc/Makefile.am. 54275 * gp-display-html/Makefile.am: Likewise. 54276 * doc/gp-archive.texi: New file. 54277 * doc/gp-collect-app.texi: New file. 54278 * doc/gp-display-html.texi: New file. 54279 * doc/gp-display-src.texi: New file. 54280 * doc/gp-display-text.texi: New file. 54281 * doc/gp-macros.texi: New file. 54282 * doc/gprofng_ug.texi: New file. 54283 * doc/Makefile.in: Rebuild. 54284 * gp-display-html/Makefile.in: Rebuild. 54285 * src/Makefile.in" Rebuild. 54286 542872023-04-17 Tom Tromey <tromey@adacore.com> 54288 54289 Remove some unnecessary casts from ada-lang.c 54290 I noticed some unnecessary casts to LONGEST in ada-lang.c. This patch 54291 removes the ones I think are very clearly not needed. I'm checking 54292 this in as obvious. 54293 542942023-04-17 Simon Marchi <simon.marchi@efficios.com> 54295 54296 gdb/amdgpu: add follow fork and exec support 54297 Prior to this patch, it's not possible for GDB to debug GPU code in fork 54298 children or after an exec. The amd-dbgapi target attaches to processes 54299 when an inferior appears due to a "run" or "attach" command, but not 54300 after a fork or exec. This patch adds support for that, such that it's 54301 possible to for an inferior to fork and for GDB to debug the GPU code in 54302 the child. 54303 54304 To achieve that, use the inferior_forked and inferior_execd observers. 54305 54306 In the case of fork, we have nothing to do if `child_inf` is nullptr, 54307 meaning that GDB won't debug the child. We also don't attach if the 54308 inferior has vforked. We are already attached to the parent's address 54309 space, which is shared with the child, so trying to attach would cause 54310 problems. And anyway, the inferior can't do anything other than exec or 54311 exit, it certainly won't start GPU kernels before exec'ing. 54312 54313 In the case of exec, we detach from the exec'ing inferior and attach to 54314 the following inferior. This works regardless of whether they are the 54315 same or not. If they are the same, meaning the execution continues in 54316 the existing inferior, we need to do a detach/attach anyway, as 54317 amd-dbgapi needs to be aware of the new address space created by the 54318 exec. 54319 54320 Note that we use observers and not target_ops::follow_{fork,exec} here. 54321 When the amd-dbgapi target is compiled in, it will attach (in the 54322 amd_dbgapi_process_attach sense, not the ptrace sense) to native 54323 inferiors when they appear, but won't push itself on the inferior's 54324 target stack just yet. It only pushes itself if the inferior 54325 initializes the ROCm runtime. So, if a non-GPU-using inferior calls 54326 fork, an amd_dbgapi_target::follow_fork method would not get called. 54327 Same for exec. A previous version of the code had the amd-dbgapi target 54328 pushed all the time, in which case we could use the target methods. But 54329 we prefer having the target pushed only when necessary, it's less 54330 intrusive when doing native debugging that doesn't involve the GPU. 54331 54332 Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9 54333 Reviewed-By: Pedro Alves <pedro@palves.net> 54334 543352023-04-17 Simon Marchi <simon.marchi@efficios.com> 54336 54337 gdb: switch to right inferior in fetch_inferior_event 54338 The problem explained and fixed in the previous patch could have also 54339 been fixed by this patch. But I think it's good change anyhow, that 54340 could prevent future bugs, so here it is. 54341 54342 fetch_inferior_event switches to an arbitrary (in practice, the first) inferior 54343 of the process target of the inferior used to fetch the event. The idea is 54344 that the event handling code will need to do some target calls, so we want to 54345 switch to an inferior that has target target. 54346 54347 However, you can have two inferiors that share a process target, but with one 54348 inferior having an additional target on top: 54349 54350 inf 1 inf 2 54351 ----- ----- 54352 another target 54353 process target process target 54354 exec exec 54355 54356 Let's say inferior 2 is selected by do_target_wait and returns an event that is 54357 really synthetized by "another target". This "another target" could be a 54358 thread or record stratum target (in the case explained by the previous patch, 54359 it was the arch stratum target, but it's because the amd-dbgapi abuses the arch 54360 layer). fetch_inferior_event will then switch to the first inferior with 54361 "process target", so inferior 1. handle_signal_stop then tries to fetch the 54362 thread's registers: 54363 54364 ecs->event_thread->set_stop_pc 54365 (regcache_read_pc (get_thread_regcache (ecs->event_thread))); 54366 54367 This will try to get the thread's register by calling into the current target 54368 stack, the stack of inferior 1. This is problematic because "another target" 54369 might have a special fetch_registers implementation. 54370 54371 I think it would be a good idea to switch to the inferior for which the 54372 even was reported, not just some inferior of the same process target. 54373 This will ensure that any target call done before we eventually call 54374 context_switch will be done on the full target stack that reported the 54375 event. 54376 54377 Not all events are associated to an inferior though. For instance, 54378 TARGET_WAITKIND_NO_RESUMED. In those cases, some targets return 54379 null_ptid, some return minus_one_ptid (ideally the expected return value 54380 should be clearly defined / documented). So, if the ptid returned is 54381 either of these, switch to an arbitrary inferior with that process 54382 target, as before. 54383 54384 Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af 54385 Reviewed-By: Pedro Alves <pedro@palves.net> 54386 543872023-04-17 Simon Marchi <simon.marchi@efficios.com> 54388 54389 gdb: make regcache::raw_update switch to right inferior 54390 With the following patch, which teaches the amd-dbgapi target to handle 54391 inferiors that fork, we end up with target stacks in the following 54392 state, when an inferior that does not use the GPU forks an inferior that 54393 eventually uses the GPU. 54394 54395 inf 1 inf 2 54396 ----- ----- 54397 amd-dbgapi 54398 linux-nat linux-nat 54399 exec exec 54400 54401 When a GPU thread from inferior 2 hits a breakpoint, the following 54402 sequence of events would happen, if it was not for the current patch. 54403 54404 - we start with inferior 1 as current 54405 - do_target_wait_1 makes inferior 2 current, does a target_wait, which 54406 returns a stop event for an amd-dbgapi wave (thread). 54407 - do_target_wait's scoped_restore_current_thread restores inferior 1 as 54408 current 54409 - fetch_inferior_event calls switch_to_target_no_thread with linux-nat 54410 as the process target, since linux-nat is officially the process 54411 target of inferior 2. This makes inferior 1 the current inferior, as 54412 it's the first inferior with that target. 54413 - In handle_signal_stop, we have: 54414 54415 ecs->event_thread->suspend.stop_pc 54416 = regcache_read_pc (get_thread_regcache (ecs->event_thread)); 54417 54418 context_switch (ecs); 54419 54420 regcache_read_pc executes while inferior 1 is still the current one 54421 (because it's before the `context_switch`). This is a problem, 54422 because the regcache is for a ptid managed by the amd-dbgapi target 54423 (e.g. (12345, 1, 1)), a ptid that does not make sense for the 54424 linux-nat target. The fetch_registers target call goes directly 54425 to the linux-nat target, which gets confused. 54426 - We would then get an error like: 54427 54428 Couldn't get extended state status: No such process. 54429 54430 ... since linux-nat tries to do a ptrace call on tid 1. 54431 54432 GDB should switch to the inferior the ptid belongs to before doing the 54433 target call to fetch registers, to make sure the call hits the right 54434 target stack (it should be handled by the amd-dbgapi target in this 54435 case). In fact the following patch does this change, and it would be 54436 enough to fix this specific problem. 54437 54438 However, I propose to change regcache to make it switch to the right 54439 inferior, if needed, before doing target calls. That makes the 54440 interface as a whole more independent of the global context. 54441 54442 My first attempt at doing this was to find an inferior using the process 54443 stratum target and the ptid that regcache already knows about: 54444 54445 gdb::optional<scoped_restore_current_thread> restore_thread; 54446 inferior *inf = find_inferior_ptid (this->target (), this->ptid ()); 54447 if (inf != current_inferior ()) 54448 { 54449 restore_thread.emplace (); 54450 switch_to_inferior_no_thread (inf); 54451 } 54452 54453 However, this caused some failures in fork-related tests and gdbserver 54454 boards. When we detach a fork child, we may create a regcache for the 54455 child, but there is no corresponding inferior. For instance, to restore 54456 the PC after a displaced step over the fork syscall. So 54457 find_inferior_ptid would return nullptr, and 54458 switch_to_inferior_no_thread would hit a failed assertion. 54459 54460 So, this patch adds to regcache the information "the inferior to switch 54461 to to makes target calls". In typical cases, it will be the inferior 54462 that matches the regcache's ptid. But in some cases, like the detached 54463 fork child one, it will be another inferior (in this example, it will be 54464 the fork parent inferior). 54465 54466 The problem that we witnessed was in regcache::raw_update specifically, 54467 but I looked for other regcache methods doing target calls, and added 54468 the same inferior switching code to raw_write too. 54469 54470 In the regcache constructor and in get_thread_arch_aspace_regcache, 54471 "inf_for_target_calls" replaces the process_stratum_target parameter. 54472 We suppose that the process stratum target that would be passed 54473 otherwise is the same that is in inf_for_target_calls's target stack, so 54474 we don't need to pass both in parallel. The process stratum target is 54475 still used as a key in the `target_pid_ptid_regcache_map` map, but 54476 that's it. 54477 54478 There is one spot that needs to be updated outside of the regcache code, 54479 which is the path that handles the "restore PC after a displaced step in 54480 a fork child we're about to detach" case mentioned above. 54481 54482 regcache_test_data needs to be changed to include full-fledged mock 54483 contexts (because there now needs to be inferiors, not just targets). 54484 54485 Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123 54486 Reviewed-By: Pedro Alves <pedro@palves.net> 54487 544882023-04-17 Simon Marchi <simon.marchi@efficios.com> 54489 54490 gdb: add maybe_switch_inferior function 54491 Add the maybe_switch_inferior function, which ensures that the given 54492 inferior is the current one. Return an instantiated 54493 scoped_restore_current_thread object only we actually needed to switch 54494 inferior. 54495 54496 Returning a scoped_restore_current_thread requires it to be 54497 move-constructible, so give it a move constructor. 54498 54499 Change-Id: I1231037102ed6166f2530399e8257ad937fb0569 54500 Reviewed-By: Pedro Alves <pedro@palves.net> 54501 545022023-04-17 Simon Marchi <simon.marchi@efficios.com> 54503 54504 gdb: remove regcache::target 54505 The regcache class takes a process_stratum_target and then exposes it 54506 through regcache::target. But it doesn't use it itself, suggesting it 54507 doesn't really make sense to put it there. The only user of 54508 regcache::target is record_btrace_target::fetch_registers, but it might 54509 as well just get it from the current target stack. This simplifies a 54510 little bit a patch later in this series. 54511 54512 Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d 54513 Reviewed-By: Pedro Alves <pedro@palves.net> 54514 545152023-04-17 Simon Marchi <simon.marchi@efficios.com> 54516 54517 gdb: add inferior_forked observable 54518 In the upcoming patch to support fork in the amd-dbgapi target, the 54519 amd-dbgapi target will need to be notified of fork events through an 54520 observer, to attach itself (attach in the amd-dbgapi sense, not ptrace 54521 sense) to the new inferior / process. 54522 54523 The reason that this can't be done through target_ops::follow_fork is 54524 that the amd-dbgapi target isn't pushed on the inferior's target stack 54525 right away. It attaches itself to the process and only pushes itself on 54526 its target stack if and when the inferior initializes the ROCm runtime. 54527 54528 If an inferior that is not using the ROCm runtime forks, we want to be 54529 notified of it, so we can attach to the child, and catch if the child 54530 starts using the ROCm runtime. 54531 54532 So, add a new observable and notify it in follow_fork_inferior. It will 54533 be used later in this series. 54534 54535 Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54 54536 Reviewed-By: Pedro Alves <pedro@palves.net> 54537 545382023-04-17 Simon Marchi <simon.marchi@efficios.com> 54539 54540 gdb: pass execing and following inferior to inferior_execd observers 54541 The upcoming patch to support exec in the amd-dbgapi target needs to 54542 detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi 54543 to the inferior continuing the execution. They may or may not be the 54544 same, depending on the `set follow-exec-mode` setting. But even if they 54545 are the same, we need to do the detach / attach dance. 54546 54547 With the current observable signature, the observers only receive the 54548 inferior in which execution continues (the "following" inferior). 54549 54550 Change the signature to pass both inferiors, and update all existing 54551 observers. 54552 54553 Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659 54554 Reviewed-By: Pedro Alves <pedro@palves.net> 54555 545562023-04-17 Tom Tromey <tromey@adacore.com> 54557 54558 Add 128-bit integer support to the Ada parser 54559 This adds support for 128-bit integers to the Ada parser. 54560 54561 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30188 54562 545632023-04-17 Tom Tromey <tromey@adacore.com> 54564 54565 Remove some Ada parser helper functions 54566 These helper functions in the Ada parser don't seem all that 54567 worthwhile to me, so this patch removes them. 54568 54569 Add overload of fits_in_type 54570 This adds an overload of fits_in_type that accepts a gdb_mpz. A 54571 subsequent patch will use this. 54572 545732023-04-17 Tom Tromey <tromey@adacore.com> 54574 54575 Add 128-bit integer support to the Rust parser 54576 This adds support for 128-bit integers to the Rust parser. 54577 54578 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185 54579 545802023-04-17 Tom Tromey <tromey@adacore.com> 54581 54582 Convert long_const_operation to use gdb_mpz 54583 This changes long_const_operation to use gdb_mpz for its storage. 54584 545852023-04-17 Tom Tromey <tromey@adacore.com> 54586 54587 Additions to gdb_mpz 54588 In preparation for adding more 128-bit support to gdb, a few additions 54589 to gdb_mpz are needed. 54590 54591 First, this adds a new 'as_integer_truncate' method. This method 54592 works like 'as_integer' but does not require the value to fit in the 54593 target type -- it just truncates. 54594 54595 Second, gdb_mpz::export_bits is changed to handle the somewhat unusual 54596 situation of zero-length types. This can happen for a Rust '()' type; 54597 but I think other languages have zero-bit integer types as well. 54598 54599 Finally, this adds some operator== overloads. 54600 546012023-04-17 Nick Clifton <nickc@redhat.com> 54602 54603 Make the .rsrc section read only. 54604 PR 30142 54605 * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable. 54606 * rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section. 54607 546082023-04-17 Tom de Vries <tdevries@suse.de> 54609 54610 [gdb/symtab] Handle empty file name in .debug_line section 54611 With DWARF 5, it's possible to produce an empty file name in the File Name 54612 Table of the .debug_line section: 54613 ... 54614 The File Name Table (offset 0x112, lines 1, columns 2): 54615 Entry Dir Name 54616 0 1 (indirect line string, offset: 0x2d): 54617 ... 54618 54619 Currently, when gdb reads an exec containing such debug info, it segfaults: 54620 ... 54621 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 54622 0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \ 54623 gdb/dwarf2/read.c:18716 54624 18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL) 54625 ... 54626 because read_direct_string transforms "" into a nullptr, and we end up 54627 dereferencing the nullptr. 54628 54629 Note that the behaviour of read_direct_string has been present since repo 54630 creation. 54631 54632 Fix this in read_formatted_entries, by transforming nullptr filenames in to "" 54633 filenames. 54634 54635 Tested on x86_64-linux. 54636 54637 Reviewed-By: Tom Tromey <tom@tromey.com> 54638 54639 PR symtab/30357 54640 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357 54641 546422023-04-17 Nick Clifton <nickc@redhat.com> 54643 54644 Add support for the .gnu.sgstubs section to the linker for ARM/ELF based targets. 54645 PR 30354 54646 * emulparams/armelf.sh (OTHER_PLT_SECTIONS): Define in order to handle the .gnu.sgstubs section. 54647 546482023-04-17 GDB Administrator <gdbadmin@sourceware.org> 54649 54650 Automatic date update in version.in 54651 546522023-04-16 GDB Administrator <gdbadmin@sourceware.org> 54653 54654 Automatic date update in version.in 54655 546562023-04-15 GDB Administrator <gdbadmin@sourceware.org> 54657 54658 Automatic date update in version.in 54659 546602023-04-14 Andrew Burgess <aburgess@redhat.com> 54661 54662 gdb/testsuite: accept script argument for mi_make_breakpoint_pending 54663 This commit changes mi_make_breakpoint_pending to accept the 'script' 54664 and 'times' arguments. 54665 54666 I've then added a new test that makes use of 'scripts' in 54667 gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp. 54668 54669 There is already a test in gdb.mi/mi-pending.exp that uses the 'times' 54670 argument -- previously this argument was being ignored, but is now 54671 used. 54672 54673 Reviewed-By: Tom Tromey <tom@tromey.com> 54674 546752023-04-14 Andrew Burgess <aburgess@redhat.com> 54676 54677 gdb/testsuite: avoid {"} pattern in lib/mi-support.exp 54678 Commit: 54679 54680 commit c569a946f6925d3f210c3eaf74dcda56843350ef 54681 Date: Fri Mar 24 10:45:37 2023 +0100 54682 54683 [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument 54684 54685 Introduced the use of {"} in mi-support.exp. There is absolutely 54686 nothing wrong with this in any way. However, this is causing my 54687 editor to get the syntax highlighting of this file wrong after this 54688 point. 54689 54690 Maybe the real answer is to use a better editor, or fix my current 54691 editor.... but I'm hoping I can instead take the lazy approach of just 54692 changing {"} to "\"", which is handled fine, and means exactly the 54693 same as far as I understand it. 54694 54695 There should be no change in what is tested after this commit. 54696 54697 Reviewed-By: Tom Tromey <tom@tromey.com> 54698 546992023-04-14 Luis Machado <luis.machado@arm.com> 54700 54701 pauth: Create new feature string for pauth to prevent crashing older gdb's 54702 Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever 54703 a target reports the pauth feature string in the target description and also 54704 provide additional register outside of gdb's known and expected feature 54705 strings. 54706 54707 This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out 54708 there that will crash on connection to the above targets. 54709 54710 QEMU has postponed inclusion of the pauth feature string in version 8, and 54711 instead we agreed to use a new feature name to prevent crashing those older 54712 gdb's. 54713 54714 Initially there was a plan to backport a trivial fix all the way to gdb 9, but 54715 given QEMU's choice, this is no longer needed. 54716 54717 This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used 54718 by all targets going forward, except native linux gdb and gdbserver, for 54719 backwards compatibility with older gdb's/gdbserver's. 54720 54721 gdb/gdbserver will still emit the old feature string for Linux since it doesn't 54722 report additional system registers and thus doesn't cause a crash of older 54723 gdb's. We can revisit this in the future once the problematic gdb's are likely 54724 no longer in use. 54725 54726 I've added some documentation to explain the situation. 54727 547282023-04-14 Luis Machado <luis.machado@arm.com> 54729 54730 debug registers: Add missing debug version entry for FEAT_Debugv8p8 54731 The Arm Architecture Reference Manual defines debug version 0b1010 for 54732 FEAT_Debugv8p8. This is used to identify valid hardware debug registers. 54733 54734 gdb currently only knows about versions up to FEAT_Debugv8p4. This patch 54735 teaches gdb about this new version. 54736 54737 No visible changes should happen as consequence of this patch, but in the 54738 future gdb will be able to identify debug registers in newer hardware. 54739 54740 Regression-tested on aarch64-linux Ubuntu 20.04/22.04. 54741 547422023-04-14 Hui Li <lihui@loongson.cn> 54743 54744 gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp 54745 (1) Description of problem 54746 54747 In the current code, when execute the following test on LoongArch: 54748 54749 $make check-gdb TESTS="gdb.base/dump.exp" 54750 ``` 54751 FAIL: gdb.base/dump.exp: dump array as value, intel hex 54752 FAIL: gdb.base/dump.exp: dump struct as value, intel hex 54753 FAIL: gdb.base/dump.exp: dump array as memory, ihex 54754 FAIL: gdb.base/dump.exp: dump struct as memory, ihex 54755 54756 ``` 54757 These tests passed on the X86_64, 54758 54759 (2) Root cause 54760 54761 On LoongArch, variable intarray address 0x120008068 out of range for IHEX, 54762 so dump ihex test failed. 54763 54764 gdb.base/dump.exp has the following code to check 64-bit address 54765 54766 ``` 54767 # Check the address of a variable. If it is bigger than 32-bit, 54768 # assume our target has 64-bit addresses that are not supported by SREC, 54769 # IHEX and TEKHEX. We skip those tests then. 54770 set max_32bit_address "0xffffffff" 54771 set data_address [get_hexadecimal_valueof "&intarray" 0x100000000] 54772 if {${data_address} > ${max_32bit_address}} { 54773 set is64bitonly "yes" 54774 } 54775 ``` 54776 54777 We check the "&intarray" on different target as follow: 54778 54779 ``` 54780 $gdb gdb/testsuite/outputs/gdb.base/dump/dump 54781 ... 54782 (gdb) start 54783 ... 54784 54785 On X86_64: 54786 (gdb) print /x &intarray 54787 $1 = 0x404060 54788 54789 On LoongArch: 54790 (gdb) print /x &intarray 54791 $1 = 0x120008068 54792 ``` 54793 The variable address difference here is due to the link script 54794 of linker. 54795 54796 ``` 54797 On X86_64: 54798 $ld --verbose 54799 ... 54800 PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); 54801 . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS; 54802 54803 On LoongArch: 54804 $ld --verbose 54805 ... 54806 PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000)); 54807 . = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS; 54808 54809 ``` 54810 54811 (3) How to fix 54812 54813 Because 64-bit variable address out of range for IHEX, it's not an 54814 functional problem for LoongArch. Refer to the handling of 64-bit 54815 targets in this testsuite, use the "is64bitonly" flag to skip those 54816 tests for the target has 64-bit addresses. 54817 54818 Approved-By: Tom Tromey <tom@tromey.com> 54819 548202023-04-14 Tom de Vries <tdevries@suse.de> 54821 54822 [gdb/testsuite] Add regression test for PR30325 54823 Add regression tests for PR30325, one for the asm window and one for the 54824 source window. 54825 54826 Use maint set tui-left-margin verbose to make the extend of the left margin 54827 clear. 54828 54829 Tested on x86_64-linux. 54830 54831 Approved-By: Andrew Burgess <aburgess@redhat.com> 54832 548332023-04-14 GDB Administrator <gdbadmin@sourceware.org> 54834 54835 Automatic date update in version.in 54836 548372023-04-13 Tom Tromey <tromey@adacore.com> 54838 54839 Avoid double-free with debuginfod 54840 PR gdb/29257 points out a possible double free when debuginfod is in 54841 use. Aside from some ugly warts in the symbol code (an ongoing 54842 issue), the underlying issue in this particular case is that elfread.c 54843 seems to assume that symfile_bfd_open will return NULL on error, 54844 whereas in reality it throws an exception. As this code isn't 54845 prepared for an exception, bad things result. 54846 54847 This patch fixes the problem by introducing a non-throwing variant of 54848 symfile_bfd_open and using it in the affected places. 54849 54850 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257 54851 548522023-04-13 Claudiu Zissulescu <claziss@synopsys.com> 54853 54854 arc: Update ARC specific linker tests. 54855 All the tests are designed for a little-endian ARC system. Thus, 54856 update the arc predicate in arc.exp, improve the matching pattern for 54857 linker relaxation test, and add linker scripts to nps-1x tests. 54858 54859 arc: Update ARC's CFI tests. 54860 The double store/loads instructions (e.g. STD/LDD) are not baseline 54861 ARC ISA. The same holds for some short instructions. Update the 54862 tests to use base ARC ISA. 54863 548642023-04-13 Claudiu Zissulescu <claziss@gmail.com> 54865 54866 arc: Update GAS test 54867 548682023-04-13 Alan Modra <amodra@gmail.com> 54869 54870 Preserve a few more bfd fields in check_format_matches 54871 AOUT and COFF targets set symcount and start_address in their object_p 54872 functions. If these are used anywhere then it would pay to save and 54873 restore them so that a successful match gets the values expected 54874 rather than that for a later unsuccessful target match. 54875 54876 * format.c (struct bfd_preserve): Move some fields. Add 54877 symcount, read_only and start_address. 54878 (bfd_preserve_save): Save.. 54879 (bfd_preserve_restore): ..and restore.. 54880 (bfd_reinit): ..and zero new fields. 54881 548822023-04-13 Alan Modra <amodra@gmail.com> 54883 54884 Re: pe_ILF_object_p and bfd_check_format_matches 54885 The last patch wasn't quite correct. bfd_preserve_restore also needs 54886 to handle an in-memory to file backed transition, seen in a testcase 54887 ILF object matching both pei-arm-little and pei-arm-wince-little. 54888 There the first match is saved in preserve_match, and restored at the 54889 end of the bfd_check_format_matches loop making the bfd in-memory. On 54890 finding more than one match the function wants to restore the bfd back 54891 to its original state with another bfd_preserve_restore call before 54892 exiting with a bfd_error_file_ambiguously_recognized error. 54893 54894 It is also not correct to restore abfd->iostream unless the iovec 54895 changes. abfd->iostream is a FILE* when using cache_iovec, and if 54896 the file has been closed and reopened the iostream may have changed. 54897 54898 * format.c (io_reinit): New function. 54899 (bfd_reinit, bfd_preserve_restore): Use it. 54900 549012023-04-13 GDB Administrator <gdbadmin@sourceware.org> 54902 54903 Automatic date update in version.in 54904 549052023-04-12 Tom de Vries <tdevries@suse.de> 54906 54907 [gdb/tui] Revert workaround in tui_source_window::show_line_number 54908 The m_digits member of tui_source_window is documented as having semantics: 54909 ... 54910 /* How many digits to use when formatting the line number. This 54911 includes the trailing space. */ 54912 ... 54913 54914 The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source 54915 code") started printing two trailing spaces instead: 54916 ... 54917 - xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno); 54918 + xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno); 54919 ... 54920 54921 Now that PR30325 is fixed, this no longer has any effect. 54922 54923 Fix this by reverting to the original behaviour: print one trailing space 54924 char. 54925 54926 Tested on x86_64-linux. 54927 54928 Approved-By: Tom Tromey <tom@tromey.com> 54929 549302023-04-12 Tom de Vries <tdevries@suse.de> 54931 54932 [gdb/tui] Fix left margin in disassembly window 54933 With a hello world a.out, and maint set tui-left-margin-verbose on, we have 54934 this disassembly window: 54935 ... 54936 ┌───────────────────────────────────────────────────────────┐ 54937 │___ 0x555555555149 <main> endbr64 │ 54938 │___ 0x55555555514d <main+4> push %rbp │ 54939 │___ 0x55555555514e <main+5> mov %rsp,%rbp │ 54940 │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│ 54941 │___ 0x555555555158 <main+15> mov %rax,%rdi │ 54942 ... 54943 Note the space between "B+>" and 0x555555555151. The space shows that a bit 54944 of the left margin is not written, which is a problem because that location is 54945 showing a character previously written, which happens to be a space, but also 54946 may be something else, for instance a '[' as reported in PR tui/30325. 54947 54948 The problem is caused by confusion about the meaning of: 54949 ... 54950 #define TUI_EXECINFO_SIZE 4 54951 ... 54952 54953 There's the meaning of defining the size of this zero-terminated char array: 54954 ... 54955 char element[TUI_EXECINFO_SIZE]; 54956 ... 54957 which is used to print the "B+>" bit, which is 3 chars wide. 54958 54959 And there's the meaning of defining part of the size of the left margin: 54960 ... 54961 int left_margin () const 54962 { return 1 + TUI_EXECINFO_SIZE + extra_margin (); } 54963 ... 54964 where it represents 4 chars. 54965 54966 The discrepancy between the two causes the space between "B+>" and 54967 "0x555555555151". 54968 54969 Fix this by redefining TUI_EXECINFO_SIZE to 3, and using: 54970 ... 54971 char element[TUI_EXECINFO_SIZE + 1]; 54972 ... 54973 such that we have: 54974 ... 54975 |B+>0x555555555151 <main+8> lea 0xeac(%rip),%rax │ 54976 ... 54977 54978 This changes the layout of the disassembly window back to what it was before 54979 commit 9e820dec13e ("Use a curses pad for source and disassembly windows"), 54980 the commit that introduced the PR30325 regression. 54981 54982 This also changes the source window from: 54983 ... 54984 │___000005__{ | 54985 ... 54986 to: 54987 ... 54988 │___000005_{ | 54989 ... 54990 54991 Tested on x86_64-linux. 54992 54993 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30325 54994 54995 Approved-By: Tom Tromey <tom@tromey.com> 54996 549972023-04-12 Tom de Vries <tdevries@suse.de> 54998 54999 [gdb/tui] Add maint set/show tui-left-margin-verbose 55000 The TUI has two types of windows derived from tui_source_window_base: 55001 - tui_source_window (the source window), and 55002 - tui_disasm_window (the disassembly window). 55003 55004 The two windows share a common concept: the left margin. 55005 55006 With a hello world a.out, we can see the source window: 55007 ... 55008 ┌─/home/vries/hello.c───────────────────────────────────────┐ 55009 │ 5 { │ 55010 │B+> 6 printf ("hello\n"); │ 55011 │ 7 return 0; │ 55012 │ 8 } │ 55013 │ 9 │ 55014 │ 55015 ... 55016 where the left margin is the part holding "B+>" and the line number, and the 55017 disassembly window: 55018 ... 55019 ┌───────────────────────────────────────────────────────────┐ 55020 │ 0x555555555149 <main> endbr64 │ 55021 │ 0x55555555514d <main+4> push %rbp │ 55022 │ 0x55555555514e <main+5> mov %rsp,%rbp │ 55023 │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│ 55024 │ 0x555555555158 <main+15> mov %rax,%rdi │ 55025 ... 55026 where the left margin is just the bit holding "B+>". 55027 55028 Because the left margin contains some spaces, it's not clear where it starts 55029 and ends, making it harder to observe problems related to it. 55030 55031 Add a new maintenance command "maint set tui-left-margin-verbose", that when 55032 set to on replaces the spaces in the left margin with either '_' or '0', 55033 giving us this for the source window: 55034 ... 55035 ┌─/home/vries/hello.c───────────────────────────────────────┐ 55036 │___000005__{ │ 55037 │B+>000006__ printf ("hello\n"); │ 55038 │___000007__ return 0; │ 55039 │___000008__} │ 55040 ... 55041 and this for the disassembly window: 55042 ... 55043 ┌───────────────────────────────────────────────────────────┐ 55044 │___ 0x555555555149 <main> endbr64 │ 55045 │___ 0x55555555514d <main+4> push %rbp │ 55046 │___ 0x55555555514e <main+5> mov %rsp,%rbp │ 55047 │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│ 55048 │___ 0x555555555158 <main+15> mov %rax,%rdi │ 55049 ... 55050 55051 Note the space between "B+>" and 0x555555555151. The space shows that a bit 55052 of the left margin is not written, a problem reported as PR tui/30325. 55053 55054 Specifically, PR tui/30325 is about the fact that the '[' character from the 55055 string "[ No Assembly Available ]" ends up in that same spot: 55056 ... 55057 │B+>[0x555555555151 <main+8> lea 0xeac(%rip),%rax│ 55058 ... 55059 which only happens for certain window widths. 55060 55061 The new command allows us to spot the problem with any window width. 55062 55063 Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces 55064 between line numbers and source code"), we have: 55065 ... 55066 ┌─/home/vries/hello.c───────────────────────────────────────┐ 55067 │___000005_ { │ 55068 │B+>000006_ printf ("hello\n"); │ 55069 │___000007_ return 0; │ 55070 │___000008_ } │ 55071 ... 55072 showing a similar problem at the space between '_' and '{'. 55073 55074 Tested on x86_64-linux. 55075 55076 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 55077 Approved-By: Tom Tromey <tom@tromey.com> 55078 550792023-04-12 Tom Tromey <tom@tromey.com> 55080 55081 Use SELF_CHECK in all unit tests 55082 I noticed a few unit tests are using gdb_assert. I think this was an 55083 older style, before SELF_CHECK was added. This patch switches them 55084 over. 55085 55086 Approved-By: Simon Marchi <simon.marchi@efficios.com> 55087 550882023-04-12 Claudiu Zissulescu <claziss@gmail.com> 55089 55090 arc: remove faulty instructions 55091 Clean not implemented ARC instruction from ARC instruction table. 55092 550932023-04-12 Tom Tromey <tromey@adacore.com> 55094 55095 Use 'require' with gnatmake_version_at_least 55096 I found a couple of tests that check gnatmake_version_at_least using 55097 "if" where "require" would be a little cleaner. This patch converts 55098 these. 55099 551002023-04-12 YunQiang Su <yunqiang.su@cipunited.com> 55101 55102 MIPS: make mipsisa32 and mipsisa64 link more systematic 55103 Introduce `static const struct mips_mach_extension mips_mach_32_64[]` 55104 and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`, 55105 to make mipsisa32 and mipsisa64 interlink more systemtic. 55106 55107 Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and 55108 mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1), 55109 so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64. 55110 55111 Note: R6 is not compatible with pre-R6. 55112 55113 bfd/ChangeLog: 55114 55115 * elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and 55116 mipsisa64 interlink more systematic. 55117 (mips_mach_32_64): new struct added. 55118 (mips_mach_extends_32_64): new function added. 55119 551202023-04-12 Nick Clifton <nickc@redhat.com> 55121 55122 Fix typos in the linker's documentation of the --enable-non-contiguous-regions option. 55123 551242023-04-12 Alan Modra <amodra@gmail.com> 55125 55126 PR30326, uninitialised value in objdump compare_relocs 55127 This is a fuzzing PR, with a testcase involving a SHF_ALLOC and 55128 SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc 55129 section. BFD doesn't handle compressed relocation sections, with most 55130 of the code reading relocs using sh_size (often no bfd section is 55131 created) but in the case of SHF_ALLOC dynamic relocs we had some code 55132 using the bfd section size. This led to a mismatch, sh_size is 55133 compressed, size is uncompressed, and from that some uninitialised 55134 memory. Consistently using sh_size is enough to fix this PR, but I've 55135 also added tests to exclude SHF_COMPRESSED reloc sections from 55136 consideration. 55137 55138 PR 30362 55139 * elf.c (bfd_section_from_shdr): Exclude reloc sections with 55140 SHF_COMPRESSED flag from normal reloc processing. 55141 (_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude 55142 SHF_COMPRESSED sections from consideration. Use sh_size when 55143 sizing to match slurp_relocs. 55144 (_bfd_elf_canonicalize_dynamic_reloc): Likewise. 55145 (_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size 55146 plt relocs. 55147 * elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise. 55148 * elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise. 55149 * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise. 55150 * elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise. 55151 551522023-04-12 Alan Modra <amodra@gmail.com> 55153 55154 ubsan: dwarf2.c:2232:7: runtime error: index 16 out of bounds 55155 Except it isn't out of bounds because space for a larger array has 55156 been allocated. 55157 55158 * dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array. 55159 (alloc_trie_leaf, insert_arange_in_trie): Adjust sizing. 55160 551612023-04-12 Alan Modra <amodra@gmail.com> 55162 55163 Fail of x86_64 AMX-COMPLEX insns (Intel disassembly) 55164 x86_64-w64-mingw32 pads sections. 55165 55166 * testsuite/gas/i386/x86-64-amx-complex-intel.d: Don't fail 55167 due to nop padding. 55168 551692023-04-12 Alan Modra <amodra@gmail.com> 55170 55171 pe_ILF_object_p and bfd_check_format_matches 55172 If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the 55173 bfd from being file backed to in-memory. This can have unfortunate 55174 results for targets checked by bfd_check_format_matches after that 55175 point as they will be matching against the created in-memory image 55176 rather than the file. bfd_preserve_restore also has a problem if it 55177 flips the BFD_IN_MEMORY flag, because the flag affects iostream 55178 meaning and should be set if using _bfd_memory_iovec. To fix these 55179 problems, save and restore iostream and iovec along with flags, and 55180 modify bfd_reinit to make the bfd file backed again. Restoring the 55181 iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY 55182 (part of BFD_FLAGS_SAVED) to be removed. 55183 One more detail: If restoring from file backed to in-memory then the 55184 bfd needs to be forcibly removed from the cache lru list, since after 55185 the bfd becomes in-memory a bfd_close will delete the bfd's memory 55186 leaving the lru list pointing into freed memory. 55187 55188 * cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here.. 55189 (bfd_cache_lookup_worker): ..rather than here. 55190 (bfd_cache_close): Comment. 55191 * format.c (struct bfd_preserve): Add iovec and iostream fields. 55192 (bfd_preserve_save): Save them.. 55193 (bfd_preserve_restore): ..and restore them, calling 55194 bfd_cache_close if the iovec differs. 55195 (bfd_reinit): Add preserve param. If the bfd has been flipped 55196 to in-memory, reopen the file. Restore flags. 55197 * peicode.h (pe_ILF_cleanup): New function. 55198 (pe_ILF_object_p): Return it. 55199 * bfd.c (BFD_FLAGS_SAVED): Delete. 55200 * bfd-in2.h: Regenerate. 55201 552022023-04-12 Alan Modra <amodra@gmail.com> 55203 55204 Comment typo fix 55205 552062023-04-12 GDB Administrator <gdbadmin@sourceware.org> 55207 55208 Automatic date update in version.in 55209 552102023-04-11 Nathan Sidwell <nathan@acm.org> 55211 55212 bfd: optimize bfd_elf_hash 55213 The bfd_elf_hash loop is taken straight from the sysV document, but it 55214 is poorly optimized. This refactoring removes about 5 x86 insns from 55215 the 15 insn loop. 55216 55217 1) The if (..) is meaningless -- we're xoring with that value, and of 55218 course xor 0 is a nop. On x86 (at least) we actually compute the xor'd 55219 value and then cmov. Removing the if test removes the cmov. 55220 55221 2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits 55222 will be shifted out in the next iteration. All we need to do is sink 55223 a mask of those 4 bits out of the loop. 55224 55225 3) anding with 0xf0 after shifting by 24 bits can allow betterin 55226 encoding on RISC ISAs than masking with '0xf0 << 24' before shifting. 55227 RISC ISAs often require materializing larger constants. 55228 55229 bfd/ 55230 * elf.c (bfd_elf_hash): Refactor to optimize loop. 55231 (bfd_elf_gnu_hash): Refactor to use 32-bit type. 55232 552332023-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 55234 55235 gdb, doc: correct argument description for info connections/inferiors 55236 It said for 'info inferiors' and 'info connections' that the argument 55237 could be 'a space separated list of inferior numbers' which is correct 55238 but incomplete. In fact the arguments can be any space separated 55239 combination of numbers and (ascending) ranges. 55240 55241 The beginning of the section now describes the ID list as a new keyword. 55242 55243 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 55244 552452023-04-11 Nick Clifton <nickc@redhat.com> 55246 55247 Replace an assertion in the dwarf code with a warning message. 55248 PR 30327 55249 * dwarf.c (read_and_display_attr_value): Warn if the number of views is greater than the number of locations. 55250 55251 Fix an illegal memorty access when running gprof over corrupt data. 55252 PR 30324 55253 * symtab.c (symtab_finalize): Only change the end address if dst has been updated. 55254 55255 Fix an attempt to allocate an excessive amount of memory when parsing a corrupt DWARF file. 55256 PR 30313 55257 * dwarf.c (display_debug_lines_decoded): Check for an overlarge number of files or directories. 55258 55259 Fix a potential illegal memory access when displaying corrupt DWARF information. 55260 PR 30312 55261 * dwarf.c (prealloc_cu_tu_list): Always allocate at least one entry. 55262 55263 Fix an attempt to allocate an overlarge amount of memory when decoding a corrupt ELF format file. 55264 PR 30311 55265 * readelf.c (uncompress_section_contents): Check for a suspiciously large uncompressed size. 55266 55267 Fix illegal memory access when disassembling corrupt NFP binaries. 55268 PR 30310 55269 * nfp-dis.c (init_nfp6000_priv): Check that the output section exists. 55270 552712023-04-11 Andrew Burgess <aburgess@redhat.com> 55272 55273 gdb: fix indentation within print_one_breakpoint_location 55274 Spotted some code in print_one_breakpoint_location that was not 55275 indented correctly, this commit just changes the indentation. 55276 55277 There should be no user visible changes after this commit. 55278 552792023-04-11 Andrew Burgess <aburgess@redhat.com> 55280 55281 gdb/testsuite: fix typo gdb_name_name -> gdb_test_name 55282 Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name 55283 instead of $gdb_test_name in one place. Fixed in this commit. 55284 552852023-04-11 Andrew Burgess <aburgess@redhat.com> 55286 55287 gdb: warn when converting h/w watchpoints to s/w 55288 On amd64 (at least) if a user sets a watchpoint before the inferior 55289 has started then GDB will assume that a hardware watchpoint can be 55290 created. 55291 55292 When the inferior starts there is a chance that the watchpoint can't 55293 actually be create as a hardware watchpoint, in which case (currently) 55294 GDB will silently convert the watchpoint to a software watchpoint. 55295 Here's an example session: 55296 55297 (gdb) p sizeof var 55298 $1 = 4000 55299 (gdb) watch var 55300 Hardware watchpoint 1: var 55301 (gdb) info watchpoints 55302 Num Type Disp Enb Address What 55303 1 hw watchpoint keep y var 55304 (gdb) starti 55305 Starting program: /home/andrew/tmp/watch 55306 55307 Program stopped. 55308 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 55309 (gdb) info watchpoints 55310 Num Type Disp Enb Address What 55311 1 watchpoint keep y var 55312 (gdb) 55313 55314 Notice that before the `starti` command the watchpoint is showing as a 55315 hardware watchpoint, but afterwards it is showing as a software 55316 watchpoint. Additionally, note that we clearly told the user we 55317 created a hardware watchpoint: 55318 55319 (gdb) watch var 55320 Hardware watchpoint 1: var 55321 55322 I think this is bad. I used `starti`, but if the user did `start` or 55323 even `run` then the inferior is going to be _very_ slow, which will be 55324 unexpected -- after all, we clearly told the user that we created a 55325 hardware watchpoint, and the manual clearly says that hardware 55326 watchpoints are fast (at least compared to s/w watchpoints). 55327 55328 In this patch I propose adding a new warning which will be emitted 55329 when GDB downgrades a h/w watchpoint to s/w. The session now looks 55330 like this: 55331 55332 (gdb) p sizeof var 55333 $1 = 4000 55334 (gdb) watch var 55335 Hardware watchpoint 1: var 55336 (gdb) info watchpoints 55337 Num Type Disp Enb Address What 55338 1 hw watchpoint keep y var 55339 (gdb) starti 55340 Starting program: /home/andrew/tmp/watch 55341 warning: watchpoint 1 downgraded to software watchpoint 55342 55343 Program stopped. 55344 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 55345 (gdb) info watchpoints 55346 Num Type Disp Enb Address What 55347 1 watchpoint keep y var 55348 (gdb) 55349 55350 The important line is: 55351 55352 warning: watchpoint 1 downgraded to software watchpoint 55353 55354 It's not much, but hopefully it will be enough to indicate to the user 55355 that something unexpected has occurred, and hopefully, they will not 55356 be surprised when the inferior runs much slower than they expected. 55357 55358 I've added an amd64 only test in gdb.arch/, I didn't want to try 55359 adding this as a global test as other architectures might be able to 55360 support the watchpoint request in h/w. 55361 55362 Also the test is skipped for extended-remote boards as there's a 55363 different set of options for limiting hardware watchpoints on remote 55364 targets, and this test isn't about them. 55365 55366 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 55367 553682023-04-11 Andrew Burgess <aburgess@redhat.com> 55369 55370 gdb/riscv: Support c.li in prologue unwinder 55371 I was seeing some failures in gdb.threads/omp-par-scope.exp when run 55372 on a riscv64 target. It turns out the cause of the problem is that I 55373 didn't have debug information installed for libgomp.so, which this 55374 test makes use of. The test requires GDB to backtrace through a 55375 libgomp function, and the riscv prologue unwinder was failing to 55376 unwind this particular stack frame. 55377 55378 The reason for the failure to unwind was that the function prologue 55379 includes a c.li (compressed load immediate) instruction, and the riscv 55380 prologue scanning unwinder doesn't know what to do with this 55381 instruction, though the unwinder does understand c.lui (compressed 55382 load unsigned immediate). 55383 55384 This commit adds support for c.li. After this GDB is able to unwind 55385 through libgomp, and I no longer see any unexpected failures in 55386 gdb.threads/omp-par-scope.exp. 55387 55388 I've also included a new test in gdb.arch/ which specifically checks 55389 for our c.li support. 55390 553912023-04-11 GDB Administrator <gdbadmin@sourceware.org> 55392 55393 Automatic date update in version.in 55394 553952023-04-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 55396 55397 gdb/dwarf: Fix MinGW build 55398 Unfortunately MinGW doesn't support std::future yet, so this causes the 55399 build to fail. Use GDB's version which provides a fallback for this case. 55400 55401 Tested for regressions on native aarch64-linux. 55402 55403 Approved-By: Tom Tromey <tromey@adacore.com> 55404 554052023-04-10 Tom Tromey <tromey@adacore.com> 55406 55407 Handle unwinding from SEGV on Windows 55408 PR win32/30255 points out that a call to a NULL function pointer will 55409 leave gdb unable to "bt" on Windows. 55410 55411 I tracked this down to the amd64 windows unwinder. If we treat this 55412 scenario as if it were a leaf function, unwinding works fine. 55413 55414 I'm not completely sure this patch is the best way. I considered 55415 having it check for 'pc==0' -- but then I figured this could affect 55416 any inaccessible PC, not just the special 0 value. 55417 55418 No test case because I can't run dejagnu tests on Windows. I tested 55419 this by hand using the test case in the bug. 55420 55421 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30255 55422 554232023-04-10 Haochen Jiang <haochen.jiang@intel.com> 55424 55425 x86: Add inval tests for AMX instructions 55426 gas/ChangeLog: 55427 55428 * testsuite/gas/i386/i386.exp: Run AMX-FP16 and AMX-COMPLEX 55429 inval testcases. 55430 * testsuite/gas/i386/x86-64-amx-inval.l: Add AMX-BF16 tests. 55431 * testsuite/gas/i386/x86-64-amx-inval.s: Ditto. 55432 * testsuite/gas/i386/x86-64-amx-complex-inval.l: New test. 55433 * testsuite/gas/i386/x86-64-amx-complex-inval.s: Ditto. 55434 * testsuite/gas/i386/x86-64-amx-fp16-inval.l: Ditto. 55435 * testsuite/gas/i386/x86-64-amx-fp16-inval.s: Ditto. 55436 554372023-04-10 GDB Administrator <gdbadmin@sourceware.org> 55438 55439 Automatic date update in version.in 55440 554412023-04-09 GDB Administrator <gdbadmin@sourceware.org> 55442 55443 Automatic date update in version.in 55444 554452023-04-08 Philippe Blain <levraiphilippeblain@gmail.com> 55446 55447 Fix typos in previous commit of gdb.texinfo. 55448 * gdb/doc/gdb.texinfo (Requirements): Fix typos. 55449 554502023-04-08 Nick Alcock <nick.alcock@oracle.com> 55451 55452 libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGS 55453 This is a bug in the intersection of two obscure options that cannot 55454 even be invoked from ld with a feature added to stop ld of the 55455 same input file repeatedly from crashing the linker. 55456 55457 The latter fix involved tracking input files (internally to libctf) not 55458 just with their input CU name but with a version of their input CU name 55459 that was augmented with a numeric prefix if their linker input file name 55460 was changed, to prevent distinct CTF dicts with the same cuname from 55461 overwriting each other. (We can't use just the linker input file name 55462 because one linker input can contain many CU dicts, particularly under 55463 ld -r). If these inputs then produced conflicting types, those types 55464 were emitted into similarly-named output dicts, so we needed similar 55465 machinery to detect clashing output dicts and add a numeric prefix to 55466 them as well. 55467 55468 This works fine, except that if you used the cu-mapping feature to force 55469 double-linking of CTF (so that your CTF can be grouped into output dicts 55470 larger than a single translation unit) and then also used 55471 CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the 55472 mapping to be created (even if empty), we did the creation of empty dicts 55473 first, and then all the actual content got considered to be a clash. So 55474 you ended up with a pile of useless empty dicts and then all the content 55475 was in full dicts with the same names suffixed with a #0. This seems 55476 likely to confuse consumers that use this facility. 55477 55478 Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking 55479 is complete, not before it runs. 55480 55481 No impact on ld, which does not do cu-mapped links or pass 55482 CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link(). 55483 55484 libctf/ 55485 * ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one 55486 already exists and we are making one for no input in particular. 55487 (ctf_link): Emit empty CTF dicts corresponding to no input in 55488 particular only after linkiing is complete. 55489 554902023-04-08 Nick Alcock <nick.alcock@oracle.com> 55491 55492 libctf: propagate errors from parents correctly 55493 CTF dicts have per-dict errno values: as with other errno values these 55494 are set on error and left unchanged on success. This means that all 55495 errors *must* set the CTF errno: if a call leaves it unchanged, the 55496 caller is apt to find a previous, lingering error and misinterpret 55497 it as the real error. 55498 55499 There are many places in libctf where we carry out operations on parent 55500 dicts as a result of carrying out other user-requested operations on 55501 child dicts (e.g. looking up information on a pointer to a type will 55502 look up the type as well: the pointer might well be in a child and the 55503 type it's a pointer to in the parent). Those operations on the parent 55504 might fail; if they do, the error must be correctly reflected on the 55505 child that the user-visible operation was carried out on. In many 55506 places this was not happening. 55507 55508 So, audit and fix all those places. Add tests for as many of those 55509 cases as possible so they don't regress. 55510 55511 libctf/ 55512 * ctf-create.c (ctf_add_slice): Use the original dict. 55513 * ctf-lookup.c (ctf_lookup_variable): Propagate errors. 55514 (ctf_lookup_symbol_idx): Likewise. 55515 * ctf-types.c (ctf_member_next): Likewise. 55516 (ctf_type_resolve_unsliced): Likewise. 55517 (ctf_type_aname): Likewise. 55518 (ctf_member_info): Likewise. 55519 (ctf_type_rvisit): Likewise. 55520 (ctf_func_type_info): Set the error on the right dict. 55521 (ctf_type_encoding): Use the original dict. 55522 * testsuite/libctf-writable/error-propagation.*: New test. 55523 555242023-04-08 Nick Alcock <nick.alcock@oracle.com> 55525 55526 libctf, tests: do not assume host and target have identical field offsets 55527 The newly-introduced libctf-lookup unnamed-field-info test checks 55528 C compiler-observed field offsets against libctf-computed ones 55529 by #including the testcase in the lookup runner as well as 55530 generating CTF for it. This only works if the host, on which 55531 the lookup runner is compiled and executed, is the same architecture as 55532 the target, for which the CTF is generated: when crossing, the trick 55533 may fail. 55534 55535 So pass down an indication of whether this is a cross into the 55536 testsuite, and add a new no_cross flag to .lk files that is used to 55537 suppress test execution when a cross-compiler is being tested. 55538 55539 libctf/ 55540 * Makefile.am (check_DEJAGNU): Pass down TEST_CROSS. 55541 * Makefile.in: Regenerated. 55542 * testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to 55543 implement the new no_cross option. 55544 * testsuite/libctf-lookup/unnamed-field-info.lk: Mark as 55545 no_cross. 55546 555472023-04-08 GDB Administrator <gdbadmin@sourceware.org> 55548 55549 Automatic date update in version.in 55550 555512023-04-07 Tom Tromey <tromey@adacore.com> 55552 55553 Rewrite Ada symbol cache 55554 In an experiment I'm trying, I needed Ada symbol cache entries to be 55555 allocated with 'new'. This patch reimplements the symbol cache to use 55556 the libiberty hash table and to use new and delete. A couple of other 55557 minor cleanups are done. 55558 55559 Add Ada test case for break using a label 55560 I noticed there aren't any Ada test cases for setting a breakpoint 55561 using a label. This patch adds one, adapted from the AdaCore test 55562 suite. 55563 55564 Use ui_out for "maint info frame-unwinders" 55565 This changes "maint info frame-unwinders" to use ui-out. This makes 55566 the table slightly nicer. In general I think it's better to use 55567 ui-out for tables. 55568 555692023-04-07 Tom de Vries <tdevries@suse.de> 55570 55571 [gdb/testsuite] Add -q to INTERNAL_GDBFLAGS 55572 Whenever we start gdb in the testsuite, we have the rather verbose: 55573 ... 55574 $ gdb 55575 GNU gdb (GDB) 14.0.50.20230405-git 55576 Copyright (C) 2023 Free Software Foundation, Inc. 55577 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 55578 This is free software: you are free to change and redistribute it. 55579 There is NO WARRANTY, to the extent permitted by law. 55580 Type "show copying" and "show warranty" for details. 55581 This GDB was configured as "x86_64-pc-linux-gnu". 55582 Type "show configuration" for configuration details. 55583 For bug reporting instructions, please see: 55584 <https://www.gnu.org/software/gdb/bugs/>. 55585 Find the GDB manual and other documentation resources online at: 55586 <http://www.gnu.org/software/gdb/documentation/>. 55587 55588 For help, type "help". 55589 Type "apropos word" to search for commands related to "word". 55590 (gdb) 55591 ... 55592 55593 This makes gdb.log longer than necessary and harder to read. 55594 55595 We do need to test that the output is produced, but that should be limited to 55596 one or a few test-cases. 55597 55598 Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have: 55599 ... 55600 $ gdb -q 55601 (gdb) 55602 ... 55603 55604 Tested on x86_64-linux. 55605 556062023-04-07 Tom de Vries <tdevries@suse.de> 55607 55608 [gdb/testsuite] Add missing .note.GNU-stack in gdb.arch/amd64-disp-step-self-call.exp 55609 For test-case gdb.arch/amd64-disp-step-self-call.exp I get: 55610 ... 55611 gdb compile failed, ld: warning: amd64-disp-step-self-call0.o: \ 55612 missing .note.GNU-stack section implies executable stack 55613 ld: NOTE: This behaviour is deprecated and will be removed in a future \ 55614 version of the linker 55615 ... 55616 55617 Fix this by adding the missing .note.GNU-stack. 55618 55619 Likewise for gdb.arch/i386-disp-step-self-call.exp. 55620 55621 Tested on x86_64-linux. 55622 556232023-04-07 Haochen Jiang <haochen.jiang@intel.com> 55624 55625 Support Intel AMX-COMPLEX 55626 gas/ChangeLog: 55627 55628 * NEWS: Support Intel AMX-COMPLEX. 55629 * config/tc-i386.c: Add amx_complex. 55630 * doc/c-i386.texi: Document .amx_complex. 55631 * testsuite/gas/i386/i386.exp: Run AMX-COMPLEX tests. 55632 * testsuite/gas/i386/amx-complex-inval.l: New test. 55633 * testsuite/gas/i386/amx-complex-inval.s: Ditto. 55634 * testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto. 55635 * testsuite/gas/i386/x86-64-amx-complex-bad.s: Ditto. 55636 * testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto. 55637 * testsuite/gas/i386/x86-64-amx-complex.d: Ditto. 55638 * testsuite/gas/i386/x86-64-amx-complex.s: Ditto. 55639 55640 opcodes/ChangeLog: 55641 55642 * i386-dis.c (MOD_VEX_0F386C_X86_64_W_0): New. 55643 (PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0): Ditto. 55644 (X86_64_VEX_0F386C): Ditto. 55645 (VEX_LEN_0F386C_X86_64_W_0_M_1): Ditto. 55646 (VEX_W_0F386C_X86_64): Ditto. 55647 (mod_table): Add MOD_VEX_0F386C_X86_64_W_0. 55648 (prefix_table): Add PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0. 55649 (x86_64_table): Add X86_64_VEX_0F386C. 55650 (vex_len_table): Add VEX_LEN_0F386C_X86_64_W_0_M_1. 55651 (vex_w_table): Add VEX_W_0F386C_X86_64. 55652 * i386-gen.c (cpu_flag_init): Add CPU_AMX_COMPLEX_FLAGS and 55653 CPU_ANY_AMX_COMPLEX_FLAGS. 55654 * i386-init.h: Regenerated. 55655 * i386-mnem.h: Ditto. 55656 * i386-opc.h (CpuAMX_COMPLEX): New. 55657 (i386_cpu_flags): Add cpuamx_complex. 55658 * i386-opc.tbl: Add AMX-COMPLEX instructions. 55659 * i386-tbl.h: Regenerated. 55660 556612023-04-07 Andrew Burgess <aburgess@redhat.com> 55662 55663 gdb/testsuite: updates for gdb.arch/{amd64,i386}-disp-step-self-call.exp 55664 This commit: 55665 55666 commit cf141dd8ccd36efe833aae3ccdb060b517cc1112 55667 Date: Wed Feb 22 12:15:34 2023 +0000 55668 55669 gdb: fix reg corruption from displaced stepping on amd64 55670 55671 Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and 55672 gdb.arch/i386-disp-step-self-call.exp. These scripts contained a test 55673 that included a stack address in the test name, this makes it harder 55674 to compare results between runs. 55675 55676 This commit gives the tests proper names that doesn't include an 55677 address. 55678 55679 Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were 55680 writing 8-bytes rather than 4 in order to clear the return address 55681 entry on the stack. This is also fixed in this commit. 55682 556832023-04-07 GDB Administrator <gdbadmin@sourceware.org> 55684 55685 Automatic date update in version.in 55686 556872023-04-06 Tom Tromey <tromey@adacore.com> 55688 55689 Use unique_xmalloc_ptr in apply_ext_lang_type_printers 55690 This changes apply_ext_lang_type_printers to use unique_xmalloc_ptr, 55691 removing some manual memory management. Regression tested on x86-64 55692 Fedora 36. 55693 55694 Approved-By: Simon Marchi <simon.marchi@efficios.com> 55695 556962023-04-06 Pedro Alves <pedro@palves.net> 55697 55698 Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC 55699 Clang with LTO (clang -flto) garbage collects unused global variables, 55700 Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with 55701 hundreds of FAILs like so: 55702 55703 $ make check \ 55704 TESTS="gdb.*/align-*.exp" \ 55705 RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'" 55706 ... 55707 FAIL: gdb.base/align-c.exp: get integer valueof "a_char" 55708 FAIL: gdb.base/align-c.exp: print _Alignof(char) 55709 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char" 55710 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char) 55711 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char" 55712 ... 55713 55714 AIX GCC has the same issue, and there the easier way of adding 55715 __attribute__((used)) to globals does not help. 55716 55717 So add explicit uses of all globals to the generated code. 55718 55719 For the C++ test, that reveals that the static variable members of the 55720 generated structs are not defined anywhere, leading to undefined 55721 references. Fixed by emitting initialization for all static members. 55722 55723 Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's 55724 because the align-c++.exp testcase is compiling with the C compiler 55725 driver. Fixed by passing "c++" as option to prepare_for_testing. 55726 55727 Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716 55728 557292023-04-06 Andrew Burgess <aburgess@redhat.com> 55730 55731 gdb: run black code formatter on gdbarch_components.py 55732 The following commit changed gdbarch_components.py but failed to 55733 format it with black: 55734 55735 commit cf141dd8ccd36efe833aae3ccdb060b517cc1112 55736 Date: Wed Feb 22 12:15:34 2023 +0000 55737 55738 gdb: fix reg corruption from displaced stepping on amd64 55739 55740 This commit just runs black on the file and commits the result. 55741 55742 The change is just the addition of an extra "," -- there will be no 55743 change to the generated source files after this commit. 55744 55745 There will be no user visible changes after this commit. 55746 557472023-04-06 Andrew Burgess <aburgess@redhat.com> 55748 55749 gdb/python: allow Frame.read_var to accept named arguments 55750 This commit allows Frame.read_var to accept named arguments, and also 55751 improves (I think) some of the error messages emitted when values of 55752 the wrong type are passed to this function. 55753 55754 The read_var method takes two arguments, one a variable, which is 55755 either a gdb.Symbol or a string, while the second, optional, argument 55756 is always a gdb.Block. 55757 55758 I'm now using 'O!' as the format specifier for the second argument, 55759 which allows the argument type to be checked early on. Currently, if 55760 the second argument is of the wrong type then we get this error: 55761 55762 (gdb) python print(gdb.selected_frame().read_var("a1", "xxx")) 55763 Traceback (most recent call last): 55764 File "<string>", line 1, in <module> 55765 RuntimeError: Second argument must be block. 55766 Error while executing Python code. 55767 (gdb) 55768 55769 After this commit, we now get an error like this: 55770 55771 (gdb) python print(gdb.selected_frame().read_var("a1", "xxx")) 55772 Traceback (most recent call last): 55773 File "<string>", line 1, in <module> 55774 TypeError: argument 2 must be gdb.Block, not str 55775 Error while executing Python code. 55776 (gdb) 55777 55778 Changes are: 55779 55780 1. Exception type is TypeError not RuntimeError, this is unfortunate 55781 as user code _could_ be relying on this, but I think the improvement 55782 is worth the risk, user code relying on the exact exception type is 55783 likely to be pretty rare, 55784 55785 2. New error message gives argument position and expected argument 55786 type, as well as the type that was passed. 55787 55788 If the first argument, the variable, has the wrong type then the 55789 previous exception was already a TypeError, however, I've updated the 55790 text of the exception to more closely match the "standard" error 55791 message we see above. If the first argument has the wrong type then 55792 before this commit we saw this: 55793 55794 (gdb) python print(gdb.selected_frame().read_var(123)) 55795 Traceback (most recent call last): 55796 File "<string>", line 1, in <module> 55797 TypeError: Argument must be a symbol or string. 55798 Error while executing Python code. 55799 (gdb) 55800 55801 And after we see this: 55802 55803 (gdb) python print(gdb.selected_frame().read_var(123)) 55804 Traceback (most recent call last): 55805 File "<string>", line 1, in <module> 55806 TypeError: argument 1 must be gdb.Symbol or str, not int 55807 Error while executing Python code. 55808 (gdb) 55809 55810 For existing code that doesn't use named arguments and doesn't rely on 55811 exceptions, there will be no changes after this commit. 55812 55813 Reviewed-By: Tom Tromey <tom@tromey.com> 55814 558152023-04-06 Andrew Burgess <aburgess@redhat.com> 55816 55817 gdb/python: convert Frame.read_register to take named arguments 55818 Following on from the previous commit, this updates 55819 Frame.read_register to accept named arguments. As with the previous 55820 commit there's no huge benefit for the users in accepting named 55821 arguments here -- this function only takes a single argument after 55822 all. 55823 55824 But I do think it is worth keeping Frame.read_register method in sync 55825 with the PendingFrame.read_register method, this allows for the 55826 possibility that the user has some code that can operate on either a 55827 Frame or a Pending frame. 55828 55829 Minor update to allow for named arguments, and an extra test to check 55830 the new functionality. 55831 55832 Reviewed-By: Tom Tromey <tom@tromey.com> 55833 558342023-04-06 Andrew Burgess <aburgess@redhat.com> 55835 55836 gdb/python: have PendingFrame methods accept keyword arguments 55837 Update the two gdb.PendingFrame methods gdb.PendingFrame.read_register 55838 and gdb.PendingFrame.create_unwind_info to accept keyword arguments. 55839 55840 There's no huge benefit for making this change, both of these methods 55841 only take a single argument, so it is (maybe) less likely that a user 55842 will take advantage of the keyword arguments in these cases, but I 55843 think it's nice to be consistent, and I don't see any particular draw 55844 backs to making this change. 55845 55846 For PendingFrame.read_register I've changed the argument name from 55847 'reg' to 'register' in the documentation and used 'register' as the 55848 argument name in GDB. My preference for APIs is to use full words 55849 where possible, and given we didn't support named arguments before 55850 this change should not break any existing code. 55851 55852 There should be no user visible changes (for existing code) after this 55853 commit. 55854 55855 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 55856 Reviewed-By: Tom Tromey <tom@tromey.com> 55857 558582023-04-06 Andrew Burgess <aburgess@redhat.com> 55859 55860 gdb/python: have UnwindInfo.add_saved_register accept named args 55861 Update gdb.UnwindInfo.add_saved_register to accept named keyword 55862 arguments. 55863 55864 As part of this update we now use gdb_PyArg_ParseTupleAndKeywords 55865 instead of PyArg_UnpackTuple to parse the function arguments. 55866 55867 By switching to gdb_PyArg_ParseTupleAndKeywords, we can now use 'O!' 55868 as the argument format for the function's value argument. This means 55869 that we can check the argument type (is gdb.Value) as part of the 55870 argument processing rather than manually performing the check later in 55871 the function. One result of this is that we now get a better error 55872 message (at least, I think so). Previously we would get something 55873 like: 55874 55875 ValueError: Bad register value 55876 55877 Now we get: 55878 55879 TypeError: argument 2 must be gdb.Value, not XXXX 55880 55881 It's unfortunate that the exception type changed, but I think the new 55882 exception type actually makes more sense. 55883 55884 My preference for argument names is to use full words where that's not 55885 too excessive. As such, I've updated the name of the argument from 55886 'reg' to 'register' in the documentation, which is the argument name 55887 I've made GDB look for here. 55888 55889 For existing unwinder code that doesn't throw any exceptions nothing 55890 should change with this commit. It is possible that a user has some 55891 code that throws and catches the ValueError, and this code will break 55892 after this commit, but I think this is going to be sufficiently rare 55893 that we can take the risk here. 55894 55895 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 55896 Reviewed-By: Tom Tromey <tom@tromey.com> 55897 558982023-04-06 Andrew Burgess <aburgess@redhat.com> 55899 55900 gdb: fix reg corruption from displaced stepping on amd64 55901 This commit aims to address a problem that exists with the current 55902 approach to displaced stepping, and was identified in PR gdb/22921. 55903 55904 Displaced stepping is currently supported on AArch64, ARM, amd64, 55905 i386, rs6000 (ppc), and s390. Of these, I believe there is a problem 55906 with the current approach which will impact amd64 and ARM, and can 55907 lead to random register corruption when the inferior makes use of 55908 asynchronous signals and GDB is using displaced stepping. 55909 55910 The problem can be found in displaced_step_buffers::finish in 55911 displaced-stepping.c, and is this; after GDB tries to perform a 55912 displaced step, and the inferior stops, GDB classifies the stop into 55913 one of two states, either the displaced step succeeded, or the 55914 displaced step failed. 55915 55916 If the displaced step succeeded then gdbarch_displaced_step_fixup is 55917 called, which has the job of fixing up the state of the current 55918 inferior as if the step had not been performed in a displaced manner. 55919 This all seems just fine. 55920 55921 However, if the displaced step is considered to have not completed 55922 then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB 55923 remains in displaced_step_buffers::finish and just performs a minimal 55924 fixup which involves adjusting the program counter back to its 55925 original value. 55926 55927 The problem here is that for amd64 and ARM setting up for a displaced 55928 step can involve changing the values in some temporary registers. If 55929 the displaced step succeeds then this is fine; after the step the 55930 temporary registers are restored to their original values in the 55931 architecture specific code. 55932 55933 But if the displaced step does not succeed then the temporary 55934 registers are never restored, and they retain their modified values. 55935 55936 In this context a temporary register is simply any register that is 55937 not otherwise used by the instruction being stepped that the 55938 architecture specific code considers safe to borrow for the lifetime 55939 of the instruction being stepped. 55940 55941 In the bug PR gdb/22921, the amd64 instruction being stepped is 55942 an rip-relative instruction like this: 55943 55944 jmp *0x2fe2(%rip) 55945 55946 When we displaced step this instruction we borrow a register, and 55947 modify the instruction to something like: 55948 55949 jmp *0x2fe2(%rcx) 55950 55951 with %rcx having its value adjusted to contain the original %rip 55952 value. 55953 55954 Now if the displaced step does not succeed, then %rcx will be left 55955 with a corrupted value. Obviously corrupting any register is bad; in 55956 the bug report this problem was spotted because %rcx is used as a 55957 function argument register. 55958 55959 And finally, why might a displaced step not succeed? Asynchronous 55960 signals provides one reason. GDB sets up for the displaced step and, 55961 at that precise moment, the OS delivers a signal (SIGALRM in the bug 55962 report), the signal stops the inferior at the address of the displaced 55963 instruction. GDB cancels the displaced instruction, handles the 55964 signal, and then tries again with the displaced step. But it is that 55965 first cancellation of the displaced step that causes the problem; in 55966 that case GDB (correctly) sees the displaced step as having not 55967 completed, and so does not perform the architecture specific fixup, 55968 leaving the register corrupted. 55969 55970 The reason why I think AArch64, rs600, i386, and s390 are not effected 55971 by this problem is that I don't believe these architectures make use 55972 of any temporary registers, so when a displaced step is not completed 55973 successfully, the minimal fix up is sufficient. 55974 55975 On amd64 we use at most one temporary register. 55976 55977 On ARM, looking at arm_displaced_step_copy_insn_closure, we could 55978 modify up to 16 temporary registers, and the instruction being 55979 displaced stepped could be expanded to multiple replacement 55980 instructions, which increases the chances of this bug triggering. 55981 55982 This commit only aims to address the issue on amd64 for now, though I 55983 believe that the approach I'm proposing here might be applicable for 55984 ARM too. 55985 55986 What I propose is that we always call gdbarch_displaced_step_fixup. 55987 55988 We will now pass an extra argument to gdbarch_displaced_step_fixup, 55989 this a boolean that indicates whether GDB thinks the displaced step 55990 completed successfully or not. 55991 55992 When this flag is false this indicates that the displaced step halted 55993 for some "other" reason. On ARM GDB can potentially read the 55994 inferior's program counter in order figure out how far through the 55995 sequence of replacement instructions we got, and from that GDB can 55996 figure out what fixup needs to be performed. 55997 55998 On targets like amd64 the problem is slightly easier as displaced 55999 stepping only uses a single replacement instruction. If the displaced 56000 step didn't complete the GDB knows that the single instruction didn't 56001 execute. 56002 56003 The point is that by always calling gdbarch_displaced_step_fixup, each 56004 architecture can now ensure that the inferior state is fixed up 56005 correctly in all cases, not just the success case. 56006 56007 On amd64 this ensures that we always restore the temporary register 56008 value, and so bug PR gdb/22921 is resolved. 56009 56010 In order to move all architectures to this new API, I have moved the 56011 minimal roll-back version of the code inside the architecture specific 56012 fixup functions for AArch64, rs600, s390, and ARM. For all of these 56013 except ARM I think this is good enough, as no temporaries are used all 56014 that's needed is the program counter restore anyway. 56015 56016 For ARM the minimal code is no worse than what we had before, though I 56017 do consider this architecture's displaced-stepping broken. 56018 56019 I've updated the gdb.arch/amd64-disp-step.exp test to cover the 56020 'jmpq*' instruction that was causing problems in the original bug, and 56021 also added support for testing the displaced step in the presence of 56022 asynchronous signal delivery. 56023 56024 I've also added two new tests (for amd64 and i386) that check that GDB 56025 can correctly handle displaced stepping over a single instruction that 56026 branches to itself. I added these tests after a first version of this 56027 patch relied too much on checking the program-counter value in order 56028 to see if the displaced instruction had executed. This works fine in 56029 almost all cases, but when an instruction branches to itself a pure 56030 program counter check is not sufficient. The new tests expose this 56031 problem. 56032 56033 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22921 56034 56035 Approved-By: Pedro Alves <pedro@palves.net> 56036 560372023-04-06 Alan Modra <amodra@gmail.com> 56038 56039 Re: objcopy write_debugging_info memory leaks 56040 Oops, tried to free too much 56041 56042 * wrstabs.c (write_stabs_in_sections_debugging_info): Don't 56043 free strings. 56044 560452023-04-06 Alan Modra <amodra@gmail.com> 56046 56047 objdump print_debugging_info memory leaks 56048 Fix memory leaks and do a general tidy of the code for printing coff 56049 and stabs debug. 56050 56051 * prdbg.c: Delete unnneeded forward function declarations. 56052 Delete unnecessary casts throughout. Free all strings 56053 returned from pop_type throughout file. 56054 (struct pr_stack): Delete "num_parents". Replace tests for 56055 "num_parents" non-zero with tests of "parents" non-NULL 56056 throughout. Free "parents" before assigning, and set to NULL 56057 after freeing. Remove const from "method". Always strdup 56058 strings assigned to method, and free before assigning. 56059 (print_debugging_info): Free info.stack and info.filename. 56060 560612023-04-06 Alan Modra <amodra@gmail.com> 56062 56063 objdump -g on gcc COFF/PE files 56064 objdump -g can't be used much. Trying to dump PE files invariably 56065 seems to run into "debug_name_type: no current file" or similar 56066 errors, because parse_coff expects a C_FILE symbol to be the first 56067 symbol. Dumping -gstabs output works since the N_SO stab is present. 56068 Pre-setting the file name won't hurt stabs dumping. 56069 56070 * rddbg.c (read_debugging_info): Call debug_set_filename. 56071 560722023-04-06 Alan Modra <amodra@gmail.com> 56073 56074 gas/write.c use better types 56075 A tiny tidy. 56076 56077 * write.c (frags_chained): Make it a bool. 56078 (n_fixups): Make it unsigned. 56079 560802023-04-06 Alan Modra <amodra@gmail.com> 56081 56082 objcopy write_debugging_info memory leaks 56083 The old stabs code didn't bother too much about freeing memory. 56084 This patch corrects that and avoids some dubious copying of strings. 56085 56086 * objcopy.c (write_debugging_info): Free both strings and 56087 syms on failure to create sections. 56088 * wrstabs.c: Delete unnecessary forward declarations and casts 56089 throughout file. 56090 (stab_write_symbol_and_free): New function. Use it 56091 throughout, simplifying return paths. 56092 (stab_push_string): Don't strdup string. Use it thoughout 56093 for malloced strings. 56094 (stab_push_string_dup): New function. Use it throughout for 56095 strings in auto buffers. 56096 (write_stabs_in_sections_debugging_info): Free malloced memory. 56097 (stab_enum_type): Increase buffer sizing for worst case. 56098 (stab_range_type, stab_array_type): Reduce buffer size. 56099 (stab_set_type): Likewise. 56100 (stab_method_type): Free args on error return. Correct 56101 buffer size. 56102 (stab_struct_field): Fix memory leaks. 56103 (stab_class_static_member, stab_class_baseclass): Likewise. 56104 (stab_start_class_type): Likewise. Correct buffer size. 56105 (stab_class_start_method): Correct buffer size. 56106 (stab_class_method_var): Free memory on error return. 56107 (stab_start_function): Fix "rettype" memory leak. 56108 561092023-04-06 GDB Administrator <gdbadmin@sourceware.org> 56110 56111 Automatic date update in version.in 56112 561132023-04-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 56114 56115 gdb/testsuite: Default to assembler's preferred debug format in asm-source.exp 56116 The stabs debug format is obsolete and there's no reason to think that 56117 toolchains still have good support for it. Therefore, if a specific debug 56118 format wasn't set in asm-source.exp then leave it to the assembler to 56119 decide which one to use. 56120 56121 Reviewed-By: Tom Tromey <tom@tromey.com> 56122 561232023-04-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 56124 56125 gdb: Fix reading of partial symtabs in dbxread.c 56126 After commit 9675da25357c ("Use unrelocated_addr in minimal symbols"), 56127 aarch64-linux started failing gdb.asm/asm-source.exp: 56128 56129 Running /home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.asm/asm-source.exp ... 56130 PASS: gdb.asm/asm-source.exp: f at main 56131 PASS: gdb.asm/asm-source.exp: n at main 56132 PASS: gdb.asm/asm-source.exp: next over macro 56133 FAIL: gdb.asm/asm-source.exp: step into foo2 56134 PASS: gdb.asm/asm-source.exp: info target 56135 PASS: gdb.asm/asm-source.exp: info symbol 56136 PASS: gdb.asm/asm-source.exp: list 56137 PASS: gdb.asm/asm-source.exp: search 56138 FAIL: gdb.asm/asm-source.exp: f in foo2 56139 FAIL: gdb.asm/asm-source.exp: n in foo2 (the program exited) 56140 FAIL: gdb.asm/asm-source.exp: bt ALL in foo2 56141 FAIL: gdb.asm/asm-source.exp: bt 2 in foo2 56142 PASS: gdb.asm/asm-source.exp: s 2 56143 PASS: gdb.asm/asm-source.exp: n 2 56144 FAIL: gdb.asm/asm-source.exp: bt 3 in foo3 56145 PASS: gdb.asm/asm-source.exp: info source asmsrc1.s 56146 FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running) 56147 FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s 56148 PASS: gdb.asm/asm-source.exp: info sources 56149 FAIL: gdb.asm/asm-source.exp: info line 56150 FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running) 56151 FAIL: gdb.asm/asm-source.exp: return from foo2 56152 PASS: gdb.asm/asm-source.exp: look at global variable 56153 PASS: gdb.asm/asm-source.exp: x/i &globalvar 56154 PASS: gdb.asm/asm-source.exp: disassem &globalvar, (int *) &globalvar+1 56155 PASS: gdb.asm/asm-source.exp: look at static variable 56156 PASS: gdb.asm/asm-source.exp: x/i &staticvar 56157 PASS: gdb.asm/asm-source.exp: disassem &staticvar, (int *) &staticvar+1 56158 PASS: gdb.asm/asm-source.exp: look at static function 56159 56160 The problem is simple: a pair of parentheses was removed from the 56161 expression calculating text_end and thus text_size was only added if 56162 lowest_text_address wasn't equal to -1. 56163 56164 This patch restores the previous behaviour and fixes the testcase. 56165 Tested on native aarch64-linux. 56166 56167 Reviewed-By: Tom Tromey <tom@tromey.com> 56168 561692023-04-05 Eli Zaretskii <eliz@gnu.org> 56170 56171 Improve documentation of GDB build requirements and options 56172 MPFR is now mandatory, so its previous description in Requirements 56173 was inappropriate and out of place. In addition, the description 56174 of how to go about specifying 'configure' time options for 56175 building with libraries was highly repetitive. Some of the text 56176 was also outdated and used wrong markup. 56177 56178 Original patch and suggestions from Philippe Blain 56179 <levraiphilippeblain@gmail.com>. 56180 56181 ChangeLog: 56182 2023-04-05 Eli Zaretskii <eliz@gnu.org> 56183 56184 * gdb/doc/gdb.texinfo (Requirements, Configure Options): Update and 56185 rearrange; improve and fix markup. 56186 561872023-04-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 56188 56189 gdb, doc: add the missing '-gid' option to 'info threads' 56190 The 'info threads' command does not show the '-gid' option 56191 in the syntax. Add the option. The flag is already explained 56192 in the command description and used in the examples. 56193 56194 Approved-By: Eli Zaretskii <eliz@gnu.org> 56195 561962023-04-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 56197 56198 gdb: boolify 'should_print_thread' 56199 Convert the return type of 'should_print_thread' from int to bool. 56200 56201 Reviewed-By: Tom Tromey <tom@tromey.com> 56202 562032023-04-05 Simon Marchi <simon.marchi@polymtl.ca> 56204 56205 gdb: make find_thread_ptid a process_stratum_target method 56206 Make find_thread_ptid (the overload that takes a process_stratum_target) 56207 a method of process_stratum_target. 56208 56209 Change-Id: Ib190a925a83c6b93e9c585dc7c6ab65efbdd8629 56210 Reviewed-By: Tom Tromey <tom@tromey.com> 56211 562122023-04-05 Simon Marchi <simon.marchi@polymtl.ca> 56213 56214 gdb: make find_thread_ptid an inferior method 56215 Make find_thread_ptid (the overload that takes an inferior) a method of 56216 struct inferior. 56217 56218 Change-Id: Ie5b9fa623ff35aa7ddb45e2805254fc8e83c9cd4 56219 Reviewed-By: Tom Tromey <tom@tromey.com> 56220 562212023-04-05 GDB Administrator <gdbadmin@sourceware.org> 56222 56223 Automatic date update in version.in 56224 562252023-04-04 Jan Beulich <jbeulich@suse.com> 56226 56227 bfd+ld: when / whether to generate .c files 56228 Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re- 56229 generated in x86-only builds, I came across 769a27ade588 ("Re: bfd 56230 BLD-POTFILES.in dependencies"). I think this went slightly too far, as 56231 outside of maintainer mode dependencies will cause the subset of files 56232 to be (re-)generated which are actually needed for the build. 56233 Generating them all is only needed when wanting to update certain files 56234 under bfd/po/, i.e. in maintainer mode. 56235 56236 In the course of looking around in an attempt to try to understand how 56237 things are meant to work, I further noticed that ld has got things 56238 slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't 56239 quite right (the output doesn't change when any of the enumerated files 56240 changes; it's the mere presence which matters); like in bfd it looks 56241 like we would better extend BUILT_SOURCES accordingly. 56242 56243 Furthermore it became apparent that ld fails to enumerate the .c files 56244 generated from the .l and .y ones. While in their absence it was benign 56245 whether translatable strings in the source files were actually marked as 56246 such, this now becomes relevant. Mark respective strings at the same 56247 time, but skipping ones which look to be of interest for debugging 56248 purposes only (e.g. such used by printf() enclosed in #ifdef TRACE). 56249 562502023-04-04 Alan Modra <amodra@gmail.com> 56251 56252 Use bfd_alloc memory for read_debugging_info storage 56253 Trying to free malloc'd memory used by the stabs and coff debug info 56254 parsers is complicated, and traversing the trees generated requires a 56255 lot of code. It's better to bfd_alloc the memory which allows it all 56256 to be freed without fuss when the bfd is closed. In the process of 56257 doing this I reverted most of commit a6336913332. 56258 56259 Some of the stabs handling code grows arrays of pointers with realloc, 56260 to deal with arbitrary numbers of fields, function args, etc. The 56261 code still does that but copies over to bfd_alloc memory when 56262 finished. The alternative is to parse twice, once to size, then again 56263 to populate the arrays. I think that complication is unwarranted. 56264 56265 Note that there is a greater than zero chance this patch breaks 56266 something, eg. that I missed an attempt to free obj_alloc memory. 56267 Also it seems there are no tests in the binutils testsuite aimed at 56268 exercising objdump --debugging. 56269 56270 * budbg.h (finish_stab, parse_stab): Update prototypes 56271 * debug.c: Include bucomm.h. 56272 (struct debug_handle): Add "abfd" field. 56273 (debug_init): Add "abfd" param. bfd_alloc handle. 56274 (debug_xalloc, debug_xzalloc): New functions. Use throughout 56275 in place of xmalloc and memset. 56276 (debug_start_source): Remove "name_used" param. 56277 * debug.h (debug_init, debug_start_source): Update prototypes. 56278 (debug_xalloc, debug_xzalloc): Declare. 56279 * objcopy.c (copy_object): Don't free dhandle. 56280 * objdump.c (dump_bfd): Likewise. 56281 * rdcoff.c (coff_get_slot): Add dhandle arg. debug_xzalloc 56282 memory in place of xcalloc. Update callers. 56283 (parse_coff_struct_type): Don't leak on error return. Copy 56284 fields over to debug_xalloc memory. 56285 (parse_coff_enum_type): Copy names and vals over the 56286 debug_xalloc memory. 56287 * rddbg.c (read_debugging_info): Adjust debug_init call. 56288 Don't free dhandle. 56289 (read_section_stabs_debugging_info): Don't free shandle. 56290 Adjust parse_stab call. Call finish_stab on error return. 56291 (read_symbol_stabs_debugging_info): Similarly. 56292 * stabs.c (savestring): Delete unnecessary forward declaration. 56293 Add dhandle param. debug_xalloc memory. Update callers. 56294 (start_stab): Delete unnecessary casts. 56295 (finish_stab): Add "emit" param. Free file_types, so_string, 56296 and stabs handle. 56297 (parse_stab): Delete string_used param. Revert code dealing 56298 with string_used. Copy so_string passed to debug_set_filename 56299 and stored as main_filename to debug_xalloc memory. Similarly 56300 for string passed to debug_start_source and push_bincl. Copy 56301 args to debug_xalloc memory. Don't leak args. 56302 (parse_stab_enum_type): Copy names and values to debug_xalloc 56303 memory. Don't free name. 56304 (parse_stab_struct_type): Don't free fields. 56305 (parse_stab_baseclasses): Delete unnecessary cast. 56306 (parse_stab_struct_fields): Return debug_xalloc fields. 56307 (parse_stab_cpp_abbrev): Use debug_xalloc for _vb$ type name. 56308 (parse_stab_one_struct_field): Don't free name. 56309 (parse_stab_members): Copy variants and methods to 56310 debug_xalloc memory. Don't free name or argtypes. 56311 (parse_stab_argtypes): Use debug_xalloc memory for physname 56312 and args. 56313 (push_bincl): Add dhandle param. Use debug_xalloc memory. 56314 (stab_record_variable): Use debug_xalloc memory. 56315 (stab_emit_pending_vars): Don't free var list. 56316 (stab_find_slot): Add dhandle param. Use debug_xzalloc 56317 memory. Update all callers. 56318 (stab_find_tagged_type): Don't free name. Use debug_xzalloc. 56319 (stab_demangle_qualified): Don't free name. 56320 (stab_demangle_template): Don't free s1. 56321 (stab_demangle_args): Tidy pvarargs refs. Copy *pargs on 56322 success to debug_xalloc memory, free on failure. 56323 (stab_demangle_fund_type): Don't free name. 56324 (stab_demangle_v3_arglist): Copy args to debug_xalloc memory. 56325 Don't free dt. 56326 563272023-04-04 GDB Administrator <gdbadmin@sourceware.org> 56328 56329 Automatic date update in version.in 56330 563312023-04-03 Tom Tromey <tromey@adacore.com> 56332 56333 Add readMemory and writeMemory requests to DAP 56334 This adds the DAP readMemory and writeMemory requests. A small change 56335 to the evaluation code is needed in order to test this -- this is one 56336 of the few ways for a client to actually acquire a memory reference. 56337 563382023-04-03 Andrew Burgess <aburgess@redhat.com> 56339 56340 gdb: cleanup around some set_momentary_breakpoint_at_pc calls 56341 I noticed a couple of places in infrun.c where we call 56342 set_momentary_breakpoint_at_pc, and then set the newly created 56343 breakpoint's thread field, these are in: 56344 56345 insert_exception_resume_breakpoint 56346 insert_exception_resume_from_probe 56347 56348 Function set_momentary_breakpoint_at_pc calls 56349 set_momentary_breakpoint, which always creates the breakpoint as 56350 thread-specific for the current inferior_thread(). 56351 56352 The two insert_* functions mentioned above take an arbitrary 56353 thread_info* as an argument and set the breakpoint::thread to hold the 56354 thread number of that arbitrary thread. 56355 56356 However, the insert_* functions store the breakpoint pointer within 56357 the current inferior_thread(), so we know that the thread being passed 56358 in must be the currently selected thread. 56359 56360 What this means is that we can: 56361 56362 1. Assert that the thread being passed in is the currently selected 56363 thread, and 56364 56365 2. No longer adjust the breakpoint::thread field, this will already 56366 have been set correctly be calling set_momentary_breakpoint_at_pc. 56367 56368 There should be no user visible changes after this commit. 56369 563702023-04-03 Andrew Burgess <aburgess@redhat.com> 56371 56372 gdb: don't always print breakpoint location after failed condition check 56373 Consider the following session: 56374 56375 (gdb) list some_func 56376 1 int 56377 2 some_func () 56378 3 { 56379 4 int *p = 0; 56380 5 return *p; 56381 6 } 56382 7 56383 8 void 56384 9 foo () 56385 10 { 56386 (gdb) break foo if (some_func ()) 56387 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56388 (gdb) r 56389 Starting program: /tmp/bpcond 56390 56391 Program received signal SIGSEGV, Segmentation fault. 56392 0x0000000000401116 in some_func () at bpcond.c:5 56393 5 return *p; 56394 Error in testing condition for breakpoint 1: 56395 The program being debugged stopped while in a function called from GDB. 56396 Evaluation of the expression containing the function 56397 (some_func) will be abandoned. 56398 When the function is done executing, GDB will silently stop. 56399 56400 Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 56401 5 return *p; 56402 (gdb) 56403 56404 What happens here is the breakpoint condition includes a call to an 56405 inferior function, and the inferior function segfaults. We can see 56406 that GDB reports the segfault, and then gives an error message that 56407 indicates that an inferior function call was interrupted. 56408 56409 After this GDB appears to report that it is stopped at Breakpoint 1, 56410 inside some_func. 56411 56412 I find this second stop report a little confusing. While it is true 56413 that GDB stopped as a result of hitting breakpoint 1, I think the 56414 message GDB currently prints might give the impression that GDB is 56415 actually stopped at a location of breakpoint 1, which is not the case. 56416 56417 Also, I find the second stop message draws attention away from 56418 the "Program received signal SIGSEGV, Segmentation fault" stop 56419 message, and this second stop might be thought of as replacing in 56420 someway the earlier message. 56421 56422 In short, I think things would be clearer if the second stop message 56423 were not reported at all, so the output should, I think, look like 56424 this: 56425 56426 (gdb) list some_func 56427 1 int 56428 2 some_func () 56429 3 { 56430 4 int *p = 0; 56431 5 return *p; 56432 6 } 56433 7 56434 8 void 56435 9 foo () 56436 10 { 56437 (gdb) break foo if (some_func ()) 56438 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56439 (gdb) r 56440 Starting program: /tmp/bpcond 56441 56442 Program received signal SIGSEGV, Segmentation fault. 56443 0x0000000000401116 in some_func () at bpcond.c:5 56444 5 return *p; 56445 Error in testing condition for breakpoint 1: 56446 The program being debugged stopped while in a function called from GDB. 56447 Evaluation of the expression containing the function 56448 (some_func) will be abandoned. 56449 When the function is done executing, GDB will silently stop. 56450 (gdb) 56451 56452 The user can still find the number of the breakpoint that triggered 56453 the initial stop in this line: 56454 56455 Error in testing condition for breakpoint 1: 56456 56457 But there's now only one stop reason reported, the SIGSEGV, which I 56458 think is much clearer. 56459 56460 To achieve this change I set the bpstat::print field when: 56461 56462 (a) a breakpoint condition evaluation failed, and 56463 56464 (b) the $pc of the thread changed during condition evaluation. 56465 56466 I've updated the existing tests that checked the error message printed 56467 when a breakpoint condition evaluation failed. 56468 564692023-04-03 Andrew Burgess <aburgess@redhat.com> 56470 56471 gdb: avoid repeated signal reporting during failed conditional breakpoint 56472 Consider the following case: 56473 56474 (gdb) list some_func 56475 1 int 56476 2 some_func () 56477 3 { 56478 4 int *p = 0; 56479 5 return *p; 56480 6 } 56481 7 56482 8 void 56483 9 foo () 56484 10 { 56485 (gdb) break foo if (some_func ()) 56486 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56487 (gdb) r 56488 Starting program: /tmp/bpcond 56489 56490 Program received signal SIGSEGV, Segmentation fault. 56491 0x0000000000401116 in some_func () at bpcond.c:5 56492 5 return *p; 56493 Error in testing breakpoint condition: 56494 The program being debugged was signaled while in a function called from GDB. 56495 GDB remains in the frame where the signal was received. 56496 To change this behavior use "set unwindonsignal on". 56497 Evaluation of the expression containing the function 56498 (some_func) will be abandoned. 56499 When the function is done executing, GDB will silently stop. 56500 56501 Program received signal SIGSEGV, Segmentation fault. 56502 56503 Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 56504 5 return *p; 56505 (gdb) 56506 56507 Notice that this line: 56508 56509 Program received signal SIGSEGV, Segmentation fault. 56510 56511 Appears twice in the output. The first time is followed by the 56512 current location. The second time is a little odd, why do we print 56513 that? 56514 56515 Printing that line is controlled, in part, by a global variable, 56516 stopped_by_random_signal. This variable is reset to zero in 56517 handle_signal_stop, and is set if/when GDB figures out that the 56518 inferior stopped due to some random signal. 56519 56520 The problem is, in our case, GDB first stops at the breakpoint for 56521 foo, and enters handle_signal_stop and the stopped_by_random_signal 56522 global is reset to 0. 56523 56524 Later within handle_signal_stop GDB calls bpstat_stop_status, it is 56525 within this function (via bpstat_check_breakpoint_conditions) that the 56526 breakpoint condition is checked, and, we end up calling the inferior 56527 function (some_func in our example above). 56528 56529 In our case above the thread performing the inferior function call 56530 segfaults in some_func. GDB catches the SIGSEGV and handles the stop, 56531 this causes us to reenter handle_signal_stop. The global variable 56532 stopped_by_random_signal is updated, this time it is set to true 56533 because the thread stopped due to SIGSEGV. As a result of this we 56534 print the first instance of the line (as seen above in the example). 56535 56536 Finally we unwind GDB's call stack, the inferior function call is 56537 complete, and we return to the original handle_signal_stop. However, 56538 the stopped_by_random_signal global is still carrying the value as 56539 computed for the inferior function call's stop, which is why we now 56540 print a second instance of the line, as seen in the example. 56541 56542 To prevent this, I propose adding a scoped_restore before we start an 56543 inferior function call. This will save and restore the global 56544 stopped_by_random_signal value. 56545 56546 With this done, the output from our example is now this: 56547 56548 (gdb) list some_func 56549 1 int 56550 2 some_func () 56551 3 { 56552 4 int *p = 0; 56553 5 return *p; 56554 6 } 56555 7 56556 8 void 56557 9 foo () 56558 10 { 56559 (gdb) break foo if (some_func ()) 56560 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56561 (gdb) r 56562 Starting program: /tmp/bpcond 56563 56564 Program received signal SIGSEGV, Segmentation fault. 56565 0x0000000000401116 in some_func () at bpcond.c:5 56566 5 return *p; 56567 Error in testing condition for breakpoint 1: 56568 The program being debugged stopped while in a function called from GDB. 56569 Evaluation of the expression containing the function 56570 (some_func) will be abandoned. 56571 When the function is done executing, GDB will silently stop. 56572 56573 Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 56574 5 return *p; 56575 (gdb) 56576 56577 We now only see the 'Program received signal SIGSEGV, ...' line once, 56578 which I think makes more sense. 56579 56580 Finally, I'm aware that the last few lines, that report the stop as 56581 being at 'Breakpoint 1', when this is not where the thread is actually 56582 located anymore, is not great. I'll address that in the next commit. 56583 565842023-04-03 Andrew Burgess <aburgess@redhat.com> 56585 56586 gdbserver: allow agent expressions to fail with invalid memory access 56587 This commit extends gdbserver to take account of a failed memory 56588 access from agent_mem_read, and to return a new eval_result_type 56589 expr_eval_invalid_memory_access. 56590 56591 I have only updated the agent_mem_read calls related directly to 56592 reading memory, I have not updated any of the calls related to 56593 tracepoint data collection. This is just because I'm not familiar 56594 with that area of gdb/gdbserver, and I don't want to break anything, 56595 so leaving the existing behaviour untouched seems like the safest 56596 approach. 56597 56598 I've then updated gdb.base/bp-cond-failure.exp to test evaluating the 56599 breakpoints on the target, and have also extended the test so that it 56600 checks for different sizes of memory access. 56601 566022023-04-03 Andrew Burgess <aburgess@redhat.com> 56603 56604 gdbserver: allows agent_mem_read to return an error code 56605 Currently the gdbserver function agent_mem_read ignores any errors 56606 from calling read_inferior_memory. This means that if there is an 56607 attempt to access invalid memory then this will appear to succeed. 56608 56609 In this patch I update agent_mem_read so that if read_inferior_memory 56610 fails, agent_mem_read will return an error code. 56611 56612 However, none of the callers of agent_mem_read actually check the 56613 return value, so this commit will have no effect on anything. In the 56614 next commit I will update the users of agent_mem_read to check for the 56615 error code. 56616 56617 I've also updated the header comments on agent_mem_read to better 56618 reflect what the function does, and its possible return values. 56619 566202023-04-03 Andrew Burgess <aburgess@redhat.com> 56621 56622 gdb: include breakpoint number in testing condition error message 56623 When GDB fails to test the condition of a conditional breakpoint, for 56624 whatever reason, the error message looks like this: 56625 56626 (gdb) break foo if (*(int *) 0) == 1 56627 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56628 (gdb) r 56629 Starting program: /tmp/bpcond 56630 Error in testing breakpoint condition: 56631 Cannot access memory at address 0x0 56632 56633 Breakpoint 1, foo () at bpcond.c:11 56634 11 int a = 32; 56635 (gdb) 56636 56637 The line I'm interested in for this commit is this one: 56638 56639 Error in testing breakpoint condition: 56640 56641 In the case above we can figure out that the problematic breakpoint 56642 was #1 because in the final line of the message GDB reports the stop 56643 at breakpoint #1. 56644 56645 However, in the next few patches I plan to change this. In some cases 56646 I don't think it makes sense for GDB to report the stop as being at 56647 breakpoint #1, consider this case: 56648 56649 (gdb) list some_func 56650 1 int 56651 2 some_func () 56652 3 { 56653 4 int *p = 0; 56654 5 return *p; 56655 6 } 56656 7 56657 8 void 56658 9 foo () 56659 10 { 56660 (gdb) break foo if (some_func ()) 56661 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56662 (gdb) r 56663 Starting program: /tmp/bpcond 56664 56665 Program received signal SIGSEGV, Segmentation fault. 56666 0x0000000000401116 in some_func () at bpcond.c:5 56667 5 return *p; 56668 Error in testing breakpoint condition: 56669 The program being debugged was signaled while in a function called from GDB. 56670 GDB remains in the frame where the signal was received. 56671 To change this behavior use "set unwindonsignal on". 56672 Evaluation of the expression containing the function 56673 (some_func) will be abandoned. 56674 When the function is done executing, GDB will silently stop. 56675 56676 Program received signal SIGSEGV, Segmentation fault. 56677 56678 Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 56679 5 return *p; 56680 (gdb) 56681 56682 Notice that, the final lines of output reports the stop as being at 56683 breakpoint #1, even though the inferior in not located within 56684 some_func, and it's certainly not located at the breakpoint location. 56685 56686 I find this behaviour confusing, and propose that this should be 56687 changed. However, if I make that change then every reference to 56688 breakpoint #1 will be lost from the error message. 56689 56690 So, in this commit, in preparation for the later commits, I propose to 56691 change the 'Error in testing breakpoint condition:' line to this: 56692 56693 Error in testing condition for breakpoint NUMBER: 56694 56695 where NUMBER will be filled in as appropriate. Here's the first 56696 example with the updated error: 56697 56698 (gdb) break foo if (*(int *) 0) == 0 56699 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. 56700 (gdb) r 56701 Starting program: /tmp/bpcond 56702 Error in testing condition for breakpoint 1: 56703 Cannot access memory at address 0x0 56704 56705 Breakpoint 1, foo () at bpcond.c:11 56706 11 int a = 32; 56707 (gdb) 56708 56709 The breakpoint number does now appear twice in the output, but I don't 56710 see that as a negative. 56711 56712 This commit just changes the one line of the error, and updates the 56713 few tests that either included the old error in comments, or actually 56714 checked for the error in the expected output. 56715 56716 As the only test that checked the line I modified is a Python test, 56717 I've added a new test that doesn't rely on Python that checks the 56718 error message in detail. 56719 56720 While working on the new test, I spotted that it would fail when run 56721 with native-gdbserver and native-extended-gdbserver target boards. 56722 This turns out to be due to a gdbserver bug. To avoid cluttering this 56723 commit I've added a work around to the new test script so that the 56724 test passes for the remote boards, in the next few commits I will fix 56725 gdbserver, and update the test script to remove the work around. 56726 567272023-04-03 Alan Modra <amodra@gmail.com> 56728 56729 asan: csky floatformat_to_double uninitialised value 56730 * csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't 56731 access ibytes after read_memory_func error. Change type of 56732 ibytes to avoid casts. 56733 567342023-04-03 Andrew Burgess <aburgess@redhat.com> 56735 56736 gdb/riscv: fix regressions in gdb.base/unwind-on-each-insn.exp 56737 This commit builds on the previous one to fix all the remaining 56738 failures in gdb.base/unwind-on-each-insn.exp for RISC-V. 56739 56740 The problem we have in gdb.base/unwind-on-each-insn.exp is that, when 56741 we are in the function epilogue, the previous frame and stack pointer 56742 values are being restored, and so, the values that we calculated 56743 during the function prologue are no longer suitable. 56744 56745 Here's an example from the function 'bar' in the mentioned test. This 56746 was compiled for 64-bit RISC-V with compressed instruction support: 56747 56748 Dump of assembler code for function bar: 56749 0x000000000001018a <+0>: add sp,sp,-32 56750 0x000000000001018c <+2>: sd ra,24(sp) 56751 0x000000000001018e <+4>: sd fp,16(sp) 56752 0x0000000000010190 <+6>: add fp,sp,32 56753 0x0000000000010192 <+8>: sd a0,-24(fp) 56754 0x0000000000010196 <+12>: ld a0,-24(fp) 56755 0x000000000001019a <+16>: jal 0x10178 <foo> 56756 0x000000000001019e <+20>: nop 56757 0x00000000000101a0 <+22>: ld ra,24(sp) 56758 0x00000000000101a2 <+24>: ld fp,16(sp) 56759 0x00000000000101a4 <+26>: add sp,sp,32 56760 0x00000000000101a6 <+28>: ret 56761 End of assembler dump. 56762 56763 When we are at address 0x101a4 the previous instruction has restored 56764 the frame-pointer, as such GDB's (current) preference for using the 56765 frame-pointer as the frame base address is clearly not going to work. 56766 We need to switch to using the stack-pointer instead. 56767 56768 At address 0x101a6 the previous instruction has restored the 56769 stack-pointer value. Currently GDB will not understand this and so 56770 will still assume the stack has been decreased by 32 bytes in this 56771 function. 56772 56773 My proposed solution is to extend GDB such that GDB will scan the 56774 instructions at the current $pc looking for this pattern: 56775 56776 ld fp,16(sp) 56777 add sp,sp,32 56778 ret 56779 56780 Obviously the immediates can change, but the basic pattern indicates 56781 that the function is in the process of restoring state before 56782 returning. If GDB sees this pattern then GDB can use the inferior's 56783 position within this instruction sequence to help calculate the 56784 correct frame-id. 56785 56786 With this implemented then gdb.base/unwind-on-each-insn.exp now fully 56787 passes. 56788 56789 Obviously what I've implemented is just a heuristic. It's not going 56790 to work for every function. If the compiler reorders the 56791 instructions, or merges the epilogue back into the function body then 56792 GDB is once again going to get the frame-id wrong. 56793 56794 I'm OK with that, we're no worse off that we are right now in that 56795 situation (plus we can always improve the heuristic later). 56796 56797 Remember, this is for debugging code without debug information, 56798 and (in our imagined situation) with more aggressive levels of 56799 optimisation being used. Obviously GDB is going to struggle in these 56800 situations. 56801 56802 My thinking is, lets get something in place now. Then, later, if 56803 possible, we might be able to improve the logic to cover more 56804 situations -- if there's an interest in doing so. But I figure we 56805 need something in place as a starting point. 56806 56807 After this commit gdb.base/unwind-on-each-insn.exp passes with no 56808 failures on RV64. 56809 568102023-04-03 Andrew Burgess <aburgess@redhat.com> 56811 56812 gdb/riscv: support c.ldsp and c.lwsp in prologue scanner 56813 Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp 56814 instructions. 56815 56816 This fixes some of the failures in gdb.base/unwind-on-each-insn.exp, 56817 though there are further failures that are not fixed by this commit. 56818 56819 This change started as a wider fix that would address all the failures 56820 in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed 56821 support for the two additional compressed instructions. 56822 56823 When I added support for those two compressed instructions I noticed 56824 that some of the failures in gdb.base/unwind-on-each-insn.exp resolved 56825 themselves! 56826 56827 Here's what's going on: 56828 56829 The reason for the failures is that GDB is trying to build the 56830 frame-id during the last few instructions of the function. These are 56831 the instructions that restore the frame and stack pointers just prior 56832 to the return instruction itself. 56833 56834 By the time we reach the function epilogue the stack offset that we 56835 calculated during the prologue scan is no longer valid, and so we 56836 calculate the wrong frame-id. 56837 56838 However, in the particular case of interest here, the test function 56839 'foo', the function is so simple and short (the empty function) that 56840 GDB's prologue scan could, in theory, scan every instruction of the 56841 function. 56842 56843 I say "could, in theory," because currently GDB stops the prologue 56844 scan early when it hits an unknown instruction. The unknown 56845 instruction happens to be one of the compressed instructions that I'm 56846 adding support for in this commit. 56847 56848 Now that GDB understands the compressed instructions the prologue scan 56849 really does go from the start of the function right up to the current 56850 program counter. As such, GDB sees that the stack frame has been 56851 allocated, and then deallocated, and so builds the correct frame-id. 56852 56853 Of course, most real functions are not as simple as the test function 56854 'foo'. As such, we can't usually rely on scanning right up to the end 56855 of the function -- there are some instructions we always need to stop 56856 at because GDB can't reason about how they change the inferior 56857 state (e.g. a function call). The test function 'bar' is just such an 56858 example. 56859 56860 After this commit, we can now build the frame-id correctly for every 56861 instruction in 'foo', but there are some tests still failing in 'bar'. 56862 568632023-04-03 Andrew Burgess <aburgess@redhat.com> 56864 56865 gdb/riscv: convert riscv debug settings to new debug print scheme 56866 Convert the RISC-V specific debug settings to use the new debug 56867 printing scheme. This updates the following settings: 56868 56869 set/show debug riscv breakpoints 56870 set/show debug riscv gdbarch 56871 set/show debug riscv infcall 56872 set/show debug riscv unwinder 56873 56874 All of these settings now take a boolean rather than an integer, and 56875 all print their output using the new debug scheme. 56876 56877 There should be no visible change for anyone not turning on debug. 56878 568792023-04-03 Andrew Burgess <aburgess@redhat.com> 56880 56881 opcodes/arm: adjust whitespace in cpsie instruction 56882 While I was working on the disassembler styling for ARM I noticed that 56883 the whitespace in the cpsie instruction was inconsistent with most of 56884 the other ARM disassembly output, the disassembly for cpsie looks like 56885 this: 56886 56887 cpsie if,#10 56888 56889 notice there's no space before the '#10' immediate, most other ARM 56890 instructions have a space before each operand. 56891 56892 This commit updates the disassembler to add the missing space, and 56893 updates the tests I found that tested this instruction. 56894 568952023-04-03 Andrew Burgess <aburgess@redhat.com> 56896 56897 gdb/testsuite: gdb.server/server-kill.exp 'info frame' before kill_server 56898 This commit follows on from the following two commits: 56899 56900 commit 80dc83fd0e70f4d522a534bc601df5e05b81d564 56901 Date: Fri Jun 11 11:30:47 2021 +0100 56902 56903 gdb/remote: handle target dying just before a stepi 56904 56905 And: 56906 56907 commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53 56908 Date: Thu Mar 9 10:45:03 2023 +0100 56909 56910 [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target 56911 56912 The first of these commits fixed an issue in GDB and tried to extend 56913 the gdb.server/server-kill.exp test to cover the GDB fix. 56914 56915 Unfortunately, the changes to gdb.server/server-kill.exp were not 56916 correct, and were causing problems when trying to run with the 56917 remote-gdbserver-on-localhost board file. 56918 56919 The second commit reverts some of the gdb.server/server-kill.exp 56920 changes introduced in the first commit so that the test will now work 56921 correctly with the remote-gdbserver-on-localhost board file. 56922 56923 The second commit is just about GDB's testing infrastructure -- it's 56924 not about the original fix to GDB from the first commit, the actual 56925 GDB change was fine. 56926 56927 While reviewing the second commit I wanted to check that the problem 56928 fixed in the first commit is still being tested by the 56929 gdb.server/server-kill.exp script, so I reverted the change to 56930 breakpoint.c that is the core of the first commit and ran the test 56931 script ..... and saw no failures. 56932 56933 The first commit is about GDB discovering that gdbserver has died 56934 while trying to insert a breakpoint. As soon as GDB spots that 56935 gdbserver is gone we mourn the remote inferior, which ends up deleting 56936 all the breakpoints associated with the remote inferiors. We then 56937 throw an exception which is caught in the insert breakpoints code, and 56938 we try to display an error that includes the breakpoint number 56939 .... but the breakpoint has already been deleted ... and so GDB 56940 crashes. 56941 56942 After digging a little, what I found is that today, when the test does 56943 'stepi' the first thing we end up doing is calculating the frame-id as 56944 part of the stepi logic, it is during this frame-id calculation that 56945 we mourn the remote inferior, delete the breakpoints, and throw an 56946 exception. The exception is caught by the top level interpreter loop, 56947 and so we never try to print the breakpoint number which is what 56948 caused the original crash. 56949 56950 If I add an 'info frame' command to the test script, prior to killing 56951 gdbserver, then now when we 'stepi' GDB already has the frame-id 56952 calculated, and the first thing we do is try to insert the 56953 breakpoints, this will trigger the original bug. 56954 56955 In order to reproduce this experiment you'll need to change a function 56956 in breakpoint.c, like this: 56957 56958 static void 56959 rethrow_on_target_close_error (const gdb_exception &e) 56960 { 56961 return; 56962 } 56963 56964 Then run gdb.server/server-kill.exp with and without this patch. You 56965 should find that without this patch there are zero test failures, 56966 while with this patch there will be one failure like this: 56967 56968 (gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame 56969 Executing on target: kill -9 4513 (timeout = 300) 56970 builtin_spawn -ignore SIGHUP kill -9 4513 56971 stepi 56972 ../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed. 56973 A problem internal to GDB has been detected, 56974 further debugging may prove unreliable. 56975 ----- Backtrace ----- 56976 ... 56977 569782023-04-03 Andrew Burgess <aburgess@redhat.com> 56979 56980 gdb/testsuite: fix failure in gdb.python/py-unwind.exp 56981 A potential test failure was introduced with commit: 56982 56983 commit 6bf5f25bb150c0fbcb125e3ee466ba8f9680310b 56984 Date: Wed Mar 8 16:11:30 2023 +0000 56985 56986 gdb/python: make the gdb.unwinder.Unwinder class more robust 56987 56988 In this commit a new test was added, however the expected output 56989 pattern varies depending on which Python version GDB is linked 56990 against. 56991 56992 Older versions of Python result in output like this: 56993 56994 (gdb) python global_test_unwinder.name = "foo" 56995 Traceback (most recent call last): 56996 File "<string>", line 1, in <module> 56997 AttributeError: can't set attribute 56998 Error while executing Python code. 56999 (gdb) 57000 57001 While more recent versions of Python give a similar, but slightly more 57002 verbose error message, like this: 57003 57004 (gdb) python global_test_unwinder.name = "foo" 57005 Traceback (most recent call last): 57006 File "<string>", line 1, in <module> 57007 AttributeError: can't set attribute 'name' 57008 Error while executing Python code. 57009 (gdb) 57010 57011 The test was only accepting the first version of the output. This 57012 commit extends the test pattern so that either version will be 57013 accepted. 57014 570152023-04-03 Luis Machado <luis.machado@arm.com> 57016 57017 [aarch64] tpidr2: Fix erroneous detection logic for TPIDR2 57018 The detection logic for TPIDR2 was implemented incorrectly. Originally 57019 the detection was supposed to be through a ptrace error code, but in reality, 57020 for backwards compatibility, the detection should be based on the size of 57021 the returned iovec. 57022 57023 For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a 57024 iovec size of 16. If a target only supports TPIDR and not TPIDR2, it will 57025 return a iovec size of 8, even if we asked for 16 bytes. 57026 57027 This patch fixes this issue in code that is shared between gdb and gdbserver, 57028 therefore both gdb and gdbserver are fixed. 57029 57030 Tested on AArch64/Linux Ubuntu 20.04. 57031 570322023-04-03 GDB Administrator <gdbadmin@sourceware.org> 57033 57034 Automatic date update in version.in 57035 570362023-04-02 Alan Modra <amodra@gmail.com> 57037 57038 asan: heap buffer overflow printing ecoff debug info file name 57039 A case of a string section ending with an unterminated string. Fix it 57040 by allocating one more byte and making it zero. Also make functions 57041 reading the data return void* so that casts are not needed. 57042 57043 * ecoff.c (READ): Delete type param. Allocate one extra byte 57044 to terminate string sections with a NUL. Adjust invocation. 57045 * elfxx-mips.c (READ): Likewise. 57046 * libbfd-in.h (_bfd_alloc_and_read): Return a void*. 57047 (_bfd_malloc_and_read): Likewise. 57048 * libbfd.h: Regenerate. 57049 570502023-04-02 Alan Modra <amodra@gmail.com> 57051 57052 ubsan: aarch64 parse_vector_reg_list 57053 tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places 57054 cannot be represented in type 'int'. 57055 57056 * config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left 57057 shift. 57058 570592023-04-02 Alan Modra <amodra@gmail.com> 57060 57061 rddbg.c stabs FIXMEs 57062 This should sort out some very old FIXMEs in code handling stabs 57063 debug info. Necessary if we are to fuss over freeing up memory before 57064 objdump and objcopy exit. It is of course better from a user 57065 viewpoint to *not* free memory, which takes some time, and leave that 57066 to process exit. The only reason to do so is that having many memory 57067 leaks in binutils/ code tends to hide leaks in bfd/ or opcodes/, which 57068 we should care about. 57069 57070 * budbg.h (parse_stab): Update prototype. 57071 * debug.h (debug_start_source): Update prototype. 57072 * debug.c (debug_start_source): Add name_used. Set if stashed. 57073 * rddbg.c (read_symbol_stabs_debugging_info): Always malloc 57074 stab string passed to parse_stab. Free stab string when 57075 unreferenced. 57076 (read_section_stabs_debugging_info): Likewise, and strings 57077 section contents. 57078 * stabs.c (parse_stab): Add string_used param. Set if string 57079 stashed. Pass to debug_start_source. Realloc file_types 57080 array rather that using malloc. Clarify comment about 57081 debug_make_indirect_type. 57082 570832023-04-02 Alan Modra <amodra@gmail.com> 57084 57085 Memory leak in process_abbrev_set 57086 We may have added some abbrevs to the list before hitting an error. 57087 Free the list elements too. free_abbrev_list returns list->next so we 57088 need to init it earlier to avoid an uninitialised memory access. 57089 57090 * dwarf.c (process_abbrev_set): Call free_abbrev_list on errors. 57091 Set list->next earlier. 57092 570932023-04-02 Simon Marchi <simon.marchi@polymtl.ca> 57094 57095 gdb: remove unused parameters in print_doc_of_command, apropos_cmd 57096 I noticed the prefix parameter was unused in print_doc_of_command. And 57097 when removing it, it becomes unused in apropos_cmd. 57098 57099 Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e 57100 571012023-04-02 GDB Administrator <gdbadmin@sourceware.org> 57102 57103 Automatic date update in version.in 57104 571052023-04-01 Jan Kratochvil <jan.kratochvil@redhat.com> 57106 57107 gdb/arm: Fix backtrace for pthread_cond_timedwait 57108 GDB expected PC should point right after the SVC instruction when the 57109 syscall is active. But some active syscalls keep PC pointing to the SVC 57110 instruction itself. 57111 57112 This leads to a broken backtrace like: 57113 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 57114 #0 0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 57115 #1 0xb6e21f80 in ?? () 57116 57117 The reason is that .ARM.exidx unwinder gives up if PC does not point 57118 right after the SVC (syscall) instruction. I did not investigate why but 57119 some syscalls will point PC to the SVC instruction itself. This happens 57120 for the "futex" syscall used by pthread_cond_timedwait. 57121 57122 That normally does not matter as ARM prologue unwinder gets called 57123 instead of the .ARM.exidx one. Unfortunately some glibc calls have more 57124 complicated prologue where the GDB unwinder fails to properly determine 57125 the return address (that is in fact an orthogonal GDB bug). I expect it 57126 is due to the "vpush" there in this case but I did not investigate it more: 57127 57128 Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4: 57129 0xb6f8757c <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 57130 0xb6f87580 <+4>: mov r10, r2 57131 0xb6f87584 <+8>: vpush {d8} 57132 57133 Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11). 57134 57135 Approved-By: Luis Machado <luis.machado@arm.com> 57136 571372023-04-01 GDB Administrator <gdbadmin@sourceware.org> 57138 57139 Automatic date update in version.in 57140 571412023-03-31 H.J. Lu <hjl.tools@gmail.com> 57142 57143 lto: Don't add indirect symbols for versioned aliases in IR 57144 Linker adds indirect symbols for versioned symbol aliases, which are 57145 created by ".symver foo, foo@FOO", by checking symbol type, value and 57146 section so that references to foo will be replaced by references to 57147 foo@FOO if foo and foo@FOO have the same symbol type, value and section. 57148 But in IR, since all symbols of the same type have the same value and 57149 section, we can't tell if a symbol is an alias of another symbol by 57150 their types, values and sections. We shouldn't add indirect symbols 57151 for versioned symbol aliases in IR. 57152 57153 bfd/ 57154 57155 PR ld/30281 57156 * elflink.c (elf_link_add_object_symbols): Don't add indirect 57157 symbols for ".symver foo, foo@FOO" aliases in IR. 57158 57159 ld/ 57160 57161 PR ld/30281 57162 * testsuite/ld-plugin/lto.exp: Add PR ld/30281 test. 57163 * testsuite/ld-plugin/pr30281.t: New file. 57164 * testsuite/ld-plugin/pr30281.c: Likewise. 57165 571662023-03-31 Tom Tromey <tom@tromey.com> 57167 57168 Fix maybe-uninitialized warning in frame.c 57169 A recent patch caused my system gcc (Fedora 36, so gcc 12.2.1) to warn 57170 about sym_addr being possibly uninitialized in frame.c. It isn't, but 57171 the compiler can't tell. So, this patch initializes the variable. I 57172 also fixed a formatting buglet that I missed in review. 57173 571742023-03-31 Tom de Vries <tdevries@suse.de> 57175 57176 [gdb/testsuite] Fix gdb.base/trace-commands.exp with editing off 57177 With test-case gdb.base/trace-commands.exp and editing off, I run into fails 57178 because multi-line commands are issued using gdb_test_sequence, which 57179 doesn't handle them correctly. 57180 57181 Fix this by using gdb_test instead. 57182 57183 Tested on x86_64-linux. 57184 57185 PR testsuite/30288 57186 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288 57187 571882023-03-31 Tom de Vries <tdevries@suse.de> 57189 57190 [gdb/testsuite] Fix gdb.threads/threadapply.exp with editing off 57191 With test-case gdb.threads/threadapply.exp and editing set to on, we have: 57192 ... 57193 (gdb) define remove^M 57194 Type commands for definition of "remove".^M 57195 End with a line saying just "end".^M 57196 >remove-inferiors 3^M 57197 >end^M 57198 (gdb) 57199 ... 57200 but with editing set to off, we run into: 57201 ... 57202 (gdb) define remove^M 57203 Type commands for definition of "remove".^M 57204 End with a line saying just "end".^M 57205 >remove-inferiors 3^M 57206 end^M 57207 >(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \ 57208 define remove (timeout) 57209 ... 57210 57211 The commands are issued by this test: 57212 ... 57213 gdb_define_cmd "remove" { 57214 "remove-inferiors 3" 57215 } 57216 ... 57217 which does: 57218 - gdb_test_multiple "define remove", followed by 57219 - gdb_test_multiple "remove-inferiors 3\nend". 57220 57221 Proc gdb_test_multiple has special handling for multi-line commands, which 57222 splits it up into subcommands, and for each subcommand issues it and then 57223 waits for the resulting prompt (the secondary prompt ">" for all but the last 57224 subcommand). 57225 57226 However, that doesn't work as expected in this case because the initial 57227 gdb_test_multiple "define remove" fails to match all resulting output, and 57228 consequently the secondary prompt resulting from "define remove" is counted as 57229 if it was the one resulting from "remove-inferiors 3". 57230 57231 Fix this by matching the entire output of "define remove", including the 57232 secondary prompt. 57233 57234 Tested on x86_64-linux. 57235 57236 PR testsuite/30288 57237 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288 57238 572392023-03-31 Tom Tromey <tom@tromey.com> 57240 57241 Remove language_demangle 57242 I noticed that language_demangle shadows the global 57243 "current_language". When I went to fix this, though, I then saw that 57244 language_demangle is only called in two places, and has a comment 57245 saying it should be removed. This patch removes it. Note that the 57246 NULL check in language_demangle is not needed by either of the 57247 existing callers. 57248 57249 Regression tested on x86-64 Fedora 36. 57250 57251 Approved-By: Simon Marchi <simon.marchi@efficios.com> 57252 572532023-03-31 Tom Tromey <tom@tromey.com> 57254 57255 Fix race in background index-cache writing 57256 Tom de Vries pointed out a bug in the index-cache background writer -- 57257 sometimes it will fail. He also noted that it fails when the number 57258 of worker threads is set to zero. These turn out to be the same 57259 problem -- the cache can't be written to until the per-BFD's 57260 "index_table" member is set. 57261 57262 This patch avoids the race by rearranging the code slightly, to ensure 57263 the cache cannot possibly be written before the member is set. 57264 57265 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261 57266 572672023-03-31 Richard Bunt <richard.bunt@linaro.org> 57268 57269 GDB: Add `info main' command 57270 Allow consumers of GDB to extract the name of the main method. This is 57271 most useful for Fortran programs which have a variable main method. 57272 57273 Used by both MAP and DDT e.g. it is used to detect the presence of debug 57274 information. 57275 57276 Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> 57277 572782023-03-31 Maciej W. Rozycki <macro@embecosm.com> 57279 57280 GDB: Bring back the handling of DW_CC_program 57281 Fix a functional regression and restore the handling of DW_CC_program 57282 code of DW_AT_calling_convention attribute for determining the name of 57283 the starting function of the program where the DW_AT_main_subprogram 57284 attribute has not been provided, such as with Fortran code compiled with 57285 GCC versions 4.5.4 and below, or where DWARF version 3 or below has been 57286 requested. Without it "main" is considered the starting function. Cf. 57287 GCC PR fortran/43414. 57288 57289 Original code was removed with commit 6209cde4ddb8 ("Delete DWARF 57290 psymtab code"), and then an update to complement commit 81873cc81eff 57291 ("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also 57292 been included here. 57293 572942023-03-31 Richard Bunt <richard.bunt@linaro.org> 57295 57296 GDB: Favor full symbol main name for backtrace stop 57297 In the case where a Fortran program has a program name of "main" and 57298 there is also a minimal symbol called main, such as with programs built 57299 with GCC version 4.4.7 or below, the backtrace will erroneously stop at 57300 the minimal symbol rather than the user specified main, e.g.: 57301 57302 (gdb) bt 57303 #0 bar () at .../gdb/testsuite/gdb.fortran/backtrace.f90:17 57304 #1 0x0000000000402556 in foo () at .../gdb/testsuite/gdb.fortran/backtrace.f90:21 57305 #2 0x0000000000402575 in main () at .../gdb/testsuite/gdb.fortran/backtrace.f90:31 57306 #3 0x00000000004025aa in main () 57307 (gdb) 57308 57309 This patch fixes this issue by increasing the precedence of the full 57310 symbol when the language of the current frame is Fortran. 57311 57312 Newer versions of GCC transform the program name to "MAIN__" in this 57313 case, avoiding the problem. 57314 57315 Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> 57316 573172023-03-31 Ari Hannula <ari.hannula@intel.com> 57318 57319 gdb: Remove extra if statement 57320 The removed if statement is already checked in the parent if else 57321 statement. 57322 57323 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 57324 573252023-03-31 Tsukasa OI <research_trasio@irq.a4lg.com> 57326 57327 RISC-V: Allocate "various" operand type 57328 This commit intends to move operands that require very special handling or 57329 operand types that are so minor (e.g. only useful on a few instructions) 57330 under "W". I also intend this "W" to be "temporary" operand storage until 57331 we can find good two character (or less) operand type. 57332 57333 In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved 57334 to "Wif" because of its special handling (and allocating single character 57335 "f" for this operand type seemed too much). 57336 57337 Current expected allocation guideline is as follows: 57338 57339 1. 'W' 57340 2. The most closely related single-letter extension in lowercase 57341 (strongly recommended but not mandatory) 57342 3. Identify operand type 57343 57344 The author currently plans to allocate following three-character operand 57345 types (for operands including instructions from unratified extensions). 57346 57347 1. "Wif" ('Zicbop': fetch offset) 57348 2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions) 57349 3. "Wfm" / "WfM" 57350 'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling 57351 solely for widening conversion instructions. 57352 57353 gas/ChangeLog: 57354 57355 * config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from 57356 "f" to "Wif". 57357 57358 opcodes/ChangeLog: 57359 57360 * riscv-dis.c (print_insn_args): Move from "f" to "Wif". 57361 * riscv-opc.c (riscv_opcodes): Reflect new operand type. 57362 573632023-03-31 Jan Beulich <jbeulich@suse.com> 57364 57365 x86: convert testcases to use .insn 57366 This can't be done for all insns currently encoded with .byte. For one 57367 outside of 64-bit mode unused (typically ignored) register encoding bits 57368 in VEX/XOP/EVEX prefixes can't be set to their non-default values, since 57369 the necessary registers cannot be specified (and some of these bits 57370 can't even be used outside of 64-bit mode). And then there are odd tests 57371 like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b 57372 together with EVEX.W (which could be expressed; note though EVEX.W set 57373 is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus 57374 it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous, 57375 because that's another #UD reason). 57376 57377 In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M 57378 byte but insufficient displacement bytes, some using SIB encoding with 57379 the SIB byte actually being the supposed immediate. Some of these could 57380 be expressed by .insn, but I don't want to introduce bogus examples. 57381 These will all need adjustment anyway once the disassembler is improved 57382 in the way it deals with unrecognized encodings. 57383 57384 Generally generated code is meant to remain the same. {,x86-64-}nops.d 57385 are exceptions because insn prefixes are emitted in a different order. 57386 opcode{,-intel,-suffix}.d are also adjusted (along with an according 57387 correction to opcode.s) to cover an apparent typo in the original tests 57388 (xor when or was meant). 57389 57390 Where necessary --divide is added as gas option, to allow for the use 57391 of the extension opcode functionality. 57392 57393 Comments are being adjusted where obviously wrong/misleading. 57394 573952023-03-31 Jan Beulich <jbeulich@suse.com> 57396 57397 x86: document .insn 57398 ... and mention its introduction in NEWS. 57399 574002023-03-31 Jan Beulich <jbeulich@suse.com> 57401 57402 x86: handle immediate operands for .insn 57403 Since we have no insn suffix and it's also not realistic to infer 57404 immediate size from the size of other (typically register) operands 57405 (like optimize_imm() does), and since we also don't have a template 57406 telling us permitted size(s), a new syntax construct is introduced to 57407 allow size (and signedness) specification. In the absence of such, the 57408 size is inferred from significant bits (which obviously may yield 57409 inconsistent results at least for effectively negative values, depending 57410 on whether BFD64 is enabled), and only if supplied expressions can be 57411 evaluated at parsing time. Being explicit is generally recommended to 57412 users. 57413 57414 Size specification is permitted at bit granularity, but of course the 57415 eventually emitted immediate values will be padded up to 8-, 16-, 32-, 57416 or 64-bit fields. 57417 574182023-03-31 Jan Beulich <jbeulich@suse.com> 57419 57420 x86: allow for multiple immediates in output_disp() 57421 .insn isn't going to have a constraint of only a single immediate when, 57422 in particular, RIP-relative addressing is used. 57423 57424 x86: handle EVEX Disp8 for .insn 57425 In particular the scaling factor cannot always be determined from pre- 57426 existing operand attributes. Introduce a new {:d<N>} vector operand 57427 syntax extension, restricted to .insn only, to allow specifying this in 57428 (at least) otherwise ambiguous cases. 57429 574302023-03-31 Jan Beulich <jbeulich@suse.com> 57431 57432 x86: process instruction operands for .insn 57433 Deal with register and memory operands; immediate operands will follow 57434 later, as will the handling of EVEX embedded broadcast and EVEX Disp8 57435 scaling. 57436 57437 Note that because we can't really know how to encode their use, %cr8 and 57438 up cannot be used with .insn outside of 64-bit mode. Users would need to 57439 specify an explicit LOCK prefix in combination with %cr0 etc. 57440 574412023-03-31 Jan Beulich <jbeulich@suse.com> 57442 57443 x86: parse special opcode modifiers for .insn 57444 So called "short form" encoding is specified by a trailing "+r", whereas 57445 a possible extension opcode is specified by the usual "/<digit>". Take 57446 these off the expression before handing it to get_absolute_expression(). 57447 57448 Note that on targets where / starts a comment, --divide needs passing to 57449 gas in order to make use of the extension opcode functionality. 57450 574512023-03-31 Jan Beulich <jbeulich@suse.com> 57452 57453 x86: parse VEX and alike specifiers for .insn 57454 All encoding spaces can be used this way; there's a certain risk that 57455 the bits presently reserved could be used for other purposes down the 57456 road, but people using .insn are expected to know what they're doing 57457 anyway. Plus this way there's at least _some_ way to have those bits 57458 set. 57459 57460 For now this will only allow operand-less insns to be encoded this way. 57461 574622023-03-31 Jan Beulich <jbeulich@suse.com> 57463 57464 x86: introduce .insn directive 57465 For starters this deals with only very basic constructs. 57466 57467 Arm64/ELF: accept relocations against STN_UNDEF 57468 While only a secondary issue there, the testcase of PR gas/27212 exposes 57469 an oversight in relocation handling: Just like e.g. Arm32, which has a 57470 similar comment and a similar check, relocations against STN_UNDEF have 57471 to be permitted to satisfy the ELF spec. 57472 574732023-03-31 GDB Administrator <gdbadmin@sourceware.org> 57474 57475 Automatic date update in version.in 57476 574772023-03-30 Kevin Buettner <kevinb@redhat.com> 57478 57479 PR gdb/30219: Clear sync_quit_force_run in quit_force 57480 PR 30219 shows an internal error due to a "Bad switch" in 57481 print_exception() in gdb/exceptions.c. The switch in question 57482 contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case 57483 for the recently added RETURN_FORCED_QUIT. This commit adds that case. 57484 57485 Making the above change allows the errant test case to pass, but does 57486 not fix the underlying problem, which I'll describe shortly. Even 57487 though the addition of a case for RETURN_FORCED_QUIT isn't the actual 57488 fix, I still think it's important to add this case so that other 57489 situations which lead to print_exeption() being called won't generate 57490 that "Bad switch" internal error. 57491 57492 In order to understand the underlying problem, please examine 57493 this portion of the backtrace from the bug report: 57494 57495 0x5576e4ff5780 print_exception 57496 /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100 57497 0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&) 57498 /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110 57499 0x5576e6a896dd quit_force(int*, int) 57500 /home/smarchi/src/binutils-gdb/gdb/top.c:1849 57501 57502 The real problem is in quit_force; here's the try/catch which 57503 eventually leads to the internal error: 57504 57505 /* Get out of tfind mode, and kill or detach all inferiors. */ 57506 try 57507 { 57508 disconnect_tracing (); 57509 for (inferior *inf : all_inferiors ()) 57510 kill_or_detach (inf, from_tty); 57511 } 57512 catch (const gdb_exception &ex) 57513 { 57514 exception_print (gdb_stderr, ex); 57515 } 57516 57517 While running the calls in the try-block, a QUIT check is being 57518 performed. This check finds that sync_quit_force_run is (still) set, 57519 causing a gdb_exception_forced_quit to be thrown. The exception 57520 gdb_exception_forced_quit is derived from gdb_exception, causing 57521 exception_print to be called. As shown by the backtrace, 57522 print_exception is then called, leading to the internal error. 57523 57524 The actual fix, also implemented by this commit, is to clear 57525 sync_quit_force_run along with the quit flag. This will allow the 57526 various cleanup code, called by quit_force, to run without triggering 57527 a gdb_exception_forced_quit. (Though, if another SIGTERM is sent to 57528 the gdb process, these flags will be set again and a QUIT check in the 57529 cleanup code will detect it and throw the exception.) 57530 57531 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219 57532 Approved-By: Simon Marchi <simon.marchi@efficios.com> 57533 575342023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57535 57536 aarch64: Remove stray reglist variable 57537 Sorry for not catching this during testing. I was using a 57538 host compiler that predated the switch to -fno-common. 57539 575402023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57541 57542 aarch64: Add the RPRFM instruction 57543 This patch adds the RPRFM (range prefetch) instruction. 57544 It was introduced as part of SME2, but it belongs to the 57545 prefetch hint space and so doesn't require any specific 57546 ISA flags. 57547 57548 The aarch64_rprfmop_array initialiser (deliberately) only 57549 fills in the leading non-null elements. 57550 575512023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57552 57553 aarch64: Add the SVE FCLAMP instruction 57554 57555 aarch64: Add new SVE shift instructions 57556 This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN 57557 instructions. 57558 57559 aarch64: Add new SVE saturating conversion instructions 57560 This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions, 57561 which are available when FEAT_SME2 is implemented. 57562 57563 aarch64: Add new SVE dot-product instructions 57564 This patch adds the SVE FDOT, SDOT and UDOT instructions, 57565 which are available when FEAT_SME2 is implemented. The patch 57566 also reorders the existing SVE_Zm3_22_INDEX to keep the 57567 operands numerically sorted. 57568 57569 aarch64: Add the SVE BFMLSL instructions 57570 This patch adds the SVE BFMLSLB and BFMLSLT instructions, 57571 which are available when FEAT_SME2 is implemented. 57572 57573 aarch64: Add the SME2 UZP and ZIP instructions 57574 This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2} 57575 into single instructions. 57576 57577 aarch64: Add the SME2 UNPK instructions 57578 This patch adds SUNPK and UUNPK, which unpack one register's 57579 worth of elements to two registers' worth, or two registers' 57580 worth to four registers' worth. 57581 575822023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57583 57584 aarch64: Add the SME2 shift instructions 57585 There are two instruction formats here: 57586 57587 - SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two 57588 or four registers. 57589 57590 - SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of 57591 four registers. 57592 57593 These are the first SME2 instructions to have immediate operands. 57594 The patch makes sure that, when parsing SME2 instructions with 57595 immediate operands, the new predicate-as-counter registers are 57596 parsed as registers rather than as #-less immediates. 57597 575982023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57599 57600 aarch64: Add the SME2 saturating conversion instructions 57601 There are two instruction formats here: 57602 57603 - SQCVT, SQCVTU and UQCVT, which operate on lists of two or 57604 four registers. 57605 57606 - SQCVTN, SQCVTUN and UQCVTN, which operate on lists of 57607 four registers. 57608 576092023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57610 57611 aarch64: Add the SME2 FP<->FP conversion instructions 57612 This patch adds the BFCVT{,N} and FCVT{,N} instructions, 57613 which narrow a pair of .S registers to a single .H register. 57614 57615 aarch64: Add the SME2 FP<->int conversion instructions 57616 This patch adds the SME2 versions of the FP<->integer conversion 57617 instructions FCVT* and *CVTF. It also adds FP rounding instructions 57618 FRINT*, which share the same format. 57619 57620 aarch64: Add the SME2 CLAMP instructions 57621 FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP 57622 doesn't have a .B form. 57623 57624 aarch64: Add the SME2 MOPA and MOPS instructions 57625 [BSU]MOP[AS] share the same format. 57626 576272023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57628 57629 aarch64: Add the SME2 vertical dot-product instructions 57630 There are three instruction formats here: 57631 - BFVDOT + FVDOT 57632 - SVDOT + UVDOT 57633 - SUVDOT + USVDOT 57634 57635 There are also 64-bit forms of SVDOT and UVDOT. 57636 576372023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57638 57639 aarch64: Add the SME2 dot-product instructions 57640 BFDOT, FDOT and USDOT share the same instruction format. 57641 SDOT and UDOT share a different format. SUDOT does not 57642 have the multi vector x multi vector forms, since they 57643 would be redundant with USDOT. 57644 57645 aarch64: Add the SME2 MLALL and MLSLL instructions 57646 SMLALL, SMLSLL, UMLALL and UMLSLL have the same format. 57647 USMLALL and SUMLALL allow the same operand types as those 57648 instructions, except that SUMLALL does not have the multi-vector 57649 x multi-vector forms (which would be redundant with USMLALL). 57650 57651 aarch64: Add the SME2 MLAL and MLSL instructions 57652 The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same 57653 encoding. They are the first instance of a ZA (as opposed to ZA tile) 57654 operand having a range of offsets. As with ZA tiles, the expected 57655 range size is encoded in the operand-specific data field. 57656 57657 aarch64: Add the SME2 FMLA and FMLS instructions 57658 57659 aarch64: Add the SME2 maximum/minimum instructions 57660 This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM} 57661 and {S,U}{MAX,MIN}. SQDMULH, SRSHL and URSHL have the same form 57662 as SMAX etc., so the patch adds them too. 57663 576642023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57665 57666 aarch64: Add the SME2 ADD and SUB instructions 57667 Add support for the SME2 ADD. SUB, FADD and FSUB instructions. 57668 SUB and FSUB have the same form as ADD and FADD, except that 57669 ADD also has a 2-operand accumulating form. 57670 57671 The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the 57672 64-bit FADD/FSUB instructions require FEAT_SME_F64F64. 57673 57674 These are the first instructions to have tied register list 57675 operands, as opposed to tied single registers. 57676 57677 The parse_operands change prevents unsuffixed Z registers (width==-1) 57678 from being treated as though they had an Advanced SIMD-style suffix 57679 (.4s etc.). It means that: 57680 57681 Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}' 57682 57683 becomes: 57684 57685 Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}' 57686 576872023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57688 57689 aarch64: Add the SME2 ZT0 instructions 57690 SME2 adds lookup table instructions for quantisation. They use 57691 a new lookup table register called ZT0. 57692 57693 LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>], 57694 which is the first time that this syntax has been used. 57695 576962023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57697 57698 aarch64: Add the SME2 predicate-related instructions 57699 Implementation-wise, the main things to note here are: 57700 57701 - the WHILE* instructions have forms that return a pair of predicate 57702 registers. This is the first time that we've had lists of predicate 57703 registers, and they wrap around after register 15 rather than after 57704 register 31. 57705 57706 - the predicate-as-counter WHILE* instructions have a fourth operand 57707 that specifies the vector length. We can treat this as an enumeration, 57708 except that immediate values aren't allowed. 57709 57710 - PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>]. 57711 This is the first instance of a vector/predicate index having 57712 no suffix. 57713 577142023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57715 57716 aarch64: Add the SME2 multivector LD1 and ST1 instructions 57717 SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers. 57718 The registers can be consecutive or strided. In the strided case, 57719 2-register lists have a stride of 8, starting at register x0xxx. 57720 4-register lists have a stride of 4, starting at register x00xx. 57721 57722 The instructions are predicated on a predicate-as-counter register in 57723 the range pn8-pn15. Although we already had register fields with upper 57724 bounds of 7 and 15, this is the first plain register operand to have a 57725 nonzero lower bound. The patch uses the operand-specific data field 57726 to record the minimum value, rather than having separate inserters 57727 and extractors for each lower bound. This in turn required adding 57728 an extra bit to the field. 57729 577302023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57731 57732 aarch64: Add the SME2 MOVA instructions 57733 SME2 defines new MOVA instructions for moving multiple registers 57734 to and from ZA. As with SME, the instructions are also available 57735 through MOV aliases. 57736 57737 One notable feature of these instructions (and many other SME2 57738 instructions) is that some register lists must start at a multiple 57739 of the list's size. The patch uses the general error "start register 57740 out of range" when this constraint isn't met, rather than an error 57741 specifically about multiples. This ensures that the error is 57742 consistent between these simple consecutive lists and later 57743 strided lists, for which the requirements aren't a simple multiple. 57744 577452023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57746 57747 aarch64: Add support for predicate-as-counter registers 57748 SME2 adds a new format for the existing SVE predicate registers: 57749 predicates as counters rather than predicates as masks. In assembly 57750 code, operands that interpret predicates as counters are written 57751 pn<N> rather than p<N>. 57752 57753 This patch adds support for these registers and extends some 57754 existing instructions to support them. Since the new forms 57755 are just a programmer convenience, there's no need to make them 57756 more restrictive than the earlier predicate-as-mask forms. 57757 577582023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57759 57760 aarch64; Add support for vector offset ranges 57761 Some SME2 instructions operate on a range of consecutive ZA vectors. 57762 This is indicated by syntax such as: 57763 57764 za[<Wv>, <imml>:<immh>] 57765 57766 Like with the earlier vgx2 and vgx4 support, we get better error 57767 messages if the parser allows all ZA indices to have a range. 57768 We can then reject invalid cases during constraint checking. 57769 577702023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57771 57772 aarch64: Add support for vgx2 and vgx4 57773 Many SME2 instructions operate on groups of 2 or 4 ZA vectors. 57774 This is indicated by adding a "vgx2" or "vgx4" group size to the 57775 ZA index. The group size is optional in assembly but preferred 57776 for disassembly. 57777 57778 There is not a binary distinction between mnemonics that have 57779 group sizes and mnemonics that don't, nor between mnemonics that 57780 take vgx2 and mnemonics that take vgx4. We therefore get better 57781 error messages if we allow any ZA index to have a group size 57782 during parsing, and wait until constraint checking to reject 57783 invalid sizes. 57784 57785 A quirk of the way errors are reported means that if an instruction 57786 is wrong both in its qualifiers and its use of a group size, we'll 57787 print suggested alternative instructions that also have an incorrect 57788 group size. But that's a general property that also applies to 57789 things like out-of-range immediates. It's also not obviously the 57790 wrong thing to do. We need to be relatively confident that we're 57791 looking at the right opcode before reporting detailed operand-specific 57792 errors, so doing qualifier checking first seems resonable. 57793 577942023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57795 57796 aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array 57797 SME2 adds various new fields that are similar to 57798 AARCH64_OPND_SME_ZA_array, but are distinguished by the size of 57799 their offset fields. This patch adds _off4 to the name of the 57800 field that we already have. 57801 57802 aarch64: Add a _10 suffix to FLD_imm3 57803 SME2 adds various new 3-bit immediate fields, so this patch adds 57804 an lsb position suffix to the name of the field that we already have. 57805 57806 aarch64: Add +sme2 57807 This patch adds bare-bones support for +sme2. Later patches 57808 fill in the rest. 57809 578102023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57811 57812 aarch64: Prefer register ranges & support wrapping 57813 Until now, binutils has supported register ranges such 57814 as { v0.4s - v3.4s } as an unofficial shorthand for 57815 { v0.4s, v1.4s, v2.4s, v3.4s }. The SME2 ISA embraces this form 57816 and makes it the preferred disassembly. It also embraces wrapped 57817 lists such as { z31.s - z2.s }, which is something that binutils 57818 didn't previously allow. 57819 57820 The range form was already binutils's preferred disassembly for 3- and 57821 4-register lists. This patch prefers it for 2-register lists too. 57822 The patch also adds support for wrap-around. 57823 578242023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57825 57826 aarch64: Add support for strided register lists 57827 SME2 has instructions that accept strided register lists, 57828 such as { z0.s, z4.s, z8.s, z12.s }. The purpose of this 57829 patch is to extend binutils to support such lists. 57830 57831 The parsing code already had (unused) support for strides of 2. 57832 The idea here is instead to accept all strides during parsing 57833 and reject invalid strides during constraint checking. 57834 57835 The SME2 instructions that accept strided operands also have 57836 non-strided forms. The errors about invalid strides therefore 57837 take a bitmask of acceptable strides, which allows multiple 57838 possibilities to be summed up in a single message. 57839 57840 I've tried to update all code that handles register lists. 57841 578422023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57843 57844 aarch64: Sort fields alphanumerically 57845 This patch just sorts the field enum alphanumerically, which makes 57846 it easier to see if a particular field has already been defined. 57847 57848 aarch64: Resync field names 57849 This patch just makes the comments in aarch64-opc.c:fields match 57850 the names of the associated FLD_* enum. 57851 578522023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57853 57854 aarch64: Regularise FLD_* suffixes 57855 Some FLD_imm* suffixes used a counting scheme such as FLD_immN, 57856 FLD_immN_2, FLD_immN_3, etc., while others used the lsb as the 57857 suffix. The latter seems more mnemonic, and was a big help 57858 in doing the SME2 work. 57859 57860 Similarly, the _10 suffix on FLD_SME_size_10 was nonobvious. 57861 Presumably it indicated a 2-bit field, but it actually starts 57862 in bit 22. 57863 578642023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57865 57866 aarch64: Rename some of GAS's REG_TYPE_* macros 57867 In GAS, the vector and predicate registers are identified by 57868 REG_TYPE_VN, REG_TYPE_ZN and REG_TYPE_PN. This "N" is obviously 57869 a placeholder for the register number. However, we don't use that 57870 convention for integer and FP registers, and (more importantly) 57871 SME2 adds "predicate-as-counter" registers that are denoted PN. 57872 57873 This patch therefore drops the "N" suffix from the existing 57874 registers. The main hitch is that Z was also used for the 57875 zero register in things like R_Z, but using ZR seems more 57876 consistent with the SP-based names. 57877 578782023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57879 57880 aarch64: Add a aarch64_cpu_supports_inst_p helper 57881 Quite a lot of SME2 instructions have an opcode bit that selects 57882 between 32-bit and 64-bit forms of an instruction, with the 32-bit 57883 forms being part of base SME2 and with the 64-bit forms being part 57884 of an optional extension. It's nevertheless useful to have a single 57885 opcode entry for both forms since (a) that matches the ISA definition 57886 and (b) it tends to improve error reporting. 57887 57888 This patch therefore adds a libopcodes function called 57889 aarch64_cpu_supports_inst_p that tests whether the target 57890 supports a particular instruction. In future it will depend 57891 on internal libopcodes routines. 57892 578932023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57894 57895 aarch64: Reorder some OP_SVE_* macros 57896 This patch just moves some out-of-order-looking OP_SVE_* macros. 57897 57898 aarch64: Rename aarch64-tbl.h OP_SME_* macros 57899 This patch renames the OP_SME_* macros in aarch64-tbl.h so that 57900 they follow the same scheme as the OP_SVE_* ones. It also uses 57901 OP_SVE_ as the prefix, since there is no real distinction between 57902 the SVE and SME uses of qualifiers: a macro defined for one can 57903 be useful for the other too. 57904 579052023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57906 57907 aarch64: Tweak priorities of parsing-related errors 57908 There are three main kinds of error reported during parsing, 57909 in increasing order of priority: 57910 57911 - AARCH64_OPDE_RECOVERABLE (register seen instead of immediate) 57912 - AARCH64_OPDE_SYNTAX_ERROR 57913 - AARCH64_OPDE_FATAL_SYNTAX_ERROR 57914 57915 This priority makes sense when comparing errors reported against the 57916 same operand. But if we get to operand 3 (say) and see a register 57917 instead of an immediate, that's likely to be a better match than 57918 something that fails with a syntax error at operand 1. 57919 57920 The idea of this patch is to prioritise parsing-related errors 57921 based on operand index first, then by error code. Post-parsing 57922 errors still win over parsing errors, and their relative priorities 57923 don't change. 57924 579252023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57926 57927 aarch64: Try to report invalid variants against the closest match 57928 If an instruction has invalid qualifiers, GAS would report the 57929 error against the final opcode entry that got to the qualifier- 57930 checking stage. It seems better to report the error against 57931 the opcode entry that had the closest match, just like we 57932 pick the closest match within an opcode entry for the 57933 "did you mean this?" message. 57934 57935 This patch adds the number of invalid operands as an 57936 argument to AARCH64_OPDE_INVALID_VARIANT and then picks the 57937 AARCH64_OPDE_INVALID_VARIANT with the lowest argument. 57938 579392023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57940 57941 aarch64: Tweak register list errors 57942 The error for invalid register lists had the form: 57943 57944 invalid number of registers in the list; N registers are expected at operand M -- `insn' 57945 57946 This seems a bit verbose. Also, the "bracketing" is really: 57947 57948 (invalid number of registers in the list; N registers are expected) at operand M 57949 57950 but the semicolon works against that. 57951 57952 This patch goes for slightly shorter messages, setting a template 57953 that later patches can use for more complex cases. 57954 579552023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57956 57957 aarch64: Make AARCH64_OPDE_REG_LIST take a bitfield 57958 AARCH64_OPDE_REG_LIST took a single operand that specified the 57959 expected number of registers. However, there are quite a few 57960 SME2 instructions that have both 2-register forms and (separate) 57961 4-register forms. If the user tries to use a 3-register list, 57962 it isn't obvious which opcode entry they meant. Saying that we 57963 expect 2 registers and saying that we expect 4 registers would 57964 both be wrong. 57965 57966 This patch therefore switches the operand to a bitfield. If a 57967 AARCH64_OPDE_REG_LIST is reported against multiple opcode entries, 57968 the patch ORs up the expected lengths. 57969 57970 This has no user-visible effect yet. A later patch adds more error 57971 strings, alongside tests that use them. 57972 579732023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57974 57975 aarch64: Add an operand class for SVE register lists 57976 SVE register lists were classified as SVE_REG, since there had been 57977 no particular reason to separate them out. However, some SME2 57978 instructions have tied register list operands, and so we need to 57979 distinguish registers and register lists when checking whether two 57980 operands match. 57981 57982 Also, the register list operands used a general error message, 57983 even though we already have a dedicated error code for register 57984 lists that are the wrong length. 57985 579862023-03-30 Richard Sandiford <richard.sandiford@arm.com> 57987 57988 aarch64: Commonise checks for index operands 57989 This patch splits out the constraint checking for index operands, 57990 so that it can be reused by new SME2 operands. 57991 57992 aarch64: Add an error code for out-of-range registers 57993 libopcodes currently reports out-of-range registers as a general 57994 AARCH64_OPDE_OTHER_ERROR. However, this means that each register 57995 range needs its own hard-coded string, which is a bit cumbersome 57996 if the range is determined programmatically. This patch therefore 57997 adds a dedicated error type for out-of-range errors. 57998 579992023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58000 58001 aarch64: Deprioritise AARCH64_OPDE_REG_LIST 58002 SME2 has many instructions that take a list of SVE registers. 58003 There are often multiple forms, with different forms taking 58004 different numbers of registers. 58005 58006 This means that if, after a successful parse and qualifier match, 58007 we find that the number of registers does not match the opcode entry, 58008 the associated error should have a lower priority/severity than other 58009 errors reported at the same stage. For example, if there are 2-register 58010 and 4-register forms of an instruction, and if the assembly code uses 58011 the 2-register form with an out-of-range value, the out-of-range value 58012 error against the 2-register instruction should have a higher priority 58013 than the "wrong number of registers" error against the 4-register 58014 instruction. 58015 58016 This is tested by the main SME2 patches, but seemed worth splitting out. 58017 580182023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58019 58020 aarch64: Update operand_mismatch_kind_names 58021 The contents of operand_mismatch_kind_names were out of sync 58022 with the enum. 58023 580242023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58025 58026 aarch64: Rework reporting of failed register checks 58027 There are many opcode table entries that share the same mnemonic. 58028 Trying to parse an invalid assembly line will trigger an error for 58029 each of these entries, but the specific error might vary from one 58030 entry to another, depending on the exact nature of the problem. 58031 58032 GAS has quite an elaborate system for picking the most appropriate 58033 error out of all the failed matches. And in many cases it works well. 58034 However, one of the limitations is that the error is always reported 58035 against a single opcode table entry. If that table entry isn't the 58036 one that the user intended to use, then the error can end up being 58037 overly specific. 58038 58039 This is particularly true if an instruction has a typoed register 58040 name, or uses a type of register that is not accepted by any 58041 opcode table entry. For example, one of the expected error 58042 matches for an attempted SVE2 instruction is: 58043 58044 Error: operand 1 must be a SIMD scalar register -- `addp z32\.s,p0/m,z32\.s,z0\.s' 58045 58046 even though the hypothetical user was presumably attempting to use 58047 the SVE form of ADDP rather than the Advanced SIMD one. There are 58048 many other instances of this in the testsuite. 58049 58050 The problem becomes especially acute with SME2, since many SME2 58051 instructions reuse existing mnemonics. This could lead to us 58052 reporting an SME-related error against a non-SME instruction, 58053 or a non-SME-related error against an SME instruction. 58054 58055 This patch tries to improve things by collecting together all 58056 the register types that an opcode table entry expected for a 58057 given operand. It also records what kind of register was 58058 actually seen, if any. It then tries to summarise all this 58059 in a more directed way, falling back to a generic error if 58060 the combination defies a neat summary. 58061 58062 The patch includes tests for all new messages except REG_TYPE_ZA, 58063 which only triggers with SME2. 58064 58065 To test this, I created an assembly file that contained the cross 58066 product of all known mnemonics and one example from each register 58067 class. I then looked for cases where the new routines fell back on the 58068 generic errors ("expected a register" or "unexpected register type"). 58069 I locally added dummy messages for each one until there were no 58070 more hits. The patch adds a specimen instruction to diagnostics.s 58071 for each of these combinations. In each case, the combination didn't 58072 seem like something that could be summarised in a natural way, so the 58073 generic messages seemed better. There's always going to be an element 58074 of personal taste around this kind of thing though. 58075 58076 Adding more register types made 1<<REG_TYPE_MAX exceed the range 58077 of the type, but we don't actually need/want 1<<REG_TYPE_MAX. 58078 580792023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58080 58081 aarch64: Try to avoid inappropriate default errors 58082 After parsing a '{' and the first register, parse_typed_reg would 58083 report errors in subsequent registers in the same way as for the 58084 first register. It used set_default_error, which reports errors 58085 of the form "operand N must be X". 58086 58087 The problem is that if there are multiple opcode entries for the 58088 same mnemonic, there could be several matches that lead to a 58089 default error. There's no guarantee that the default error for 58090 the register list is the one that will be chosen. 58091 58092 To take an example from the testsuite: 58093 58094 ext z0.b,{z31.b,z32.b},#0 58095 58096 gave: 58097 58098 operand 2 must be an SVE vector register 58099 58100 with the error being reported against the single-vector version 58101 of ext, even though the operand is clearly a list. 58102 58103 This patch uses set_fatal_syntax_error to bump the priority of the 58104 error once we're sure that the operand is a list of the right type. 58105 581062023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58107 58108 aarch64: Improve errors for malformed register lists 58109 parse_typed_reg is used for parsing both bare registers and 58110 registers that occur in lists. If it doesn't see a register, 58111 or sees an unexpected kind of register, it queues a default 58112 error to report the problem. These default errors have the form 58113 "operand N must be an X", where X comes from the operand table. 58114 58115 If there are multiple opcode entries that report default errors, 58116 GAS tries to pick the most appropriate one, using the opcode 58117 table order as a tiebreaker. But this can lead to cases where 58118 a syntax error in a register list is reported against an opcode 58119 that doesn't accept register lists. For example, the unlikely 58120 error: 58121 58122 ext z0.b,{,},#0 58123 58124 is reported as: 58125 58126 operand 2 must be an SVE vector register -- `ext z0.b,{,},#0' 58127 58128 even though operand 2 can be a register list. 58129 58130 If we've parsed the opening '{' of a register list, and then see 58131 something that isn't remotely register-like, it seems better to 58132 report that directly as a syntax error, rather than rely on the 58133 default error. The operand won't be a valid list of anything, 58134 so there's no need to pick a specific Y in "operand N must be 58135 a list of Y". 58136 581372023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58138 58139 aarch64: Tweak parsing of integer & FP registers 58140 Integer registers were parsed indirectly through 58141 aarch64_reg_parse_32_64 (and thus aarch64_addr_reg_parse) rather 58142 than directly through parse_reg. This was because we need the 58143 qualifier associated with the register, and the logic to calculate 58144 that was buried in aarch64_addr_reg_parse. 58145 58146 The code that parses FP registers had the same need, but it 58147 open-coded the calculation of the qualifier. 58148 58149 This patch tries to handle both cases in the same way. It is 58150 needed by a later patch that tries to improve the register-related 58151 diagnostics. 58152 581532023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58154 58155 aarch64: Tweak errors for base & offset registers 58156 parse_address_main currently uses get_reg_expected_msg to 58157 report invalid base and offset registers, but the disadvantage 58158 of doing that is that it isn't immediately clear which register 58159 is wrong (the base or the offset). 58160 58161 A later patch moves away from using get_reg_expected_msg for failed 58162 type checks, but doing that here didn't seem like the best approach. 58163 The patch tries to use more tailored messages instead. 58164 581652023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58166 58167 aarch64: Tweak error for missing immediate offset 58168 This patch tweaks the error message that is printed when 58169 a ZA-style index is missing the immediate offset. 58170 581712023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58172 58173 aarch64: Move w12-w15 range check to libopcodes 58174 In SME, the vector select register had to be in the range 58175 w12-w15, so it made sense to enforce that during parsing. 58176 However, SME2 adds instructions for which the range is 58177 w8-w11 instead. 58178 58179 This patch therefore moves the range check from the parsing 58180 stage to the constraint-checking stage. 58181 58182 Also, the previous error used a capitalised range W12-W15, 58183 whereas other register range errors used lowercase ranges 58184 like p0-p7. A quick internal poll showed a preference for 58185 the lowercase form, so the patch uses that. 58186 58187 The patch uses "selection register" rather than "vector 58188 select register" so that the terminology extends more 58189 naturally to PSEL. 58190 581912023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58192 58193 aarch64: Commonise index parsing 58194 Just a minor clean-up to factor out the index parsing, partly to 58195 ensure that the error handling remains consistent. No behavioural 58196 change intended. 58197 581982023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58199 58200 aarch64: Consolidate ZA slice parsing 58201 Now that parse_typed_reg checks the range of tile register numbers 58202 and libopcodes checks the range of vector select offsets, there's 58203 very little difference between the parsing of ZA tile indices, 58204 ZA array indices, and PSEL indices. The main one is that ZA 58205 array indices don't currently allow "za" to be qualified, 58206 but we need to remove that restriction for SME2. 58207 58208 This patch therefore consolidates all three parsers into a single 58209 routine, parameterised by the type of register that they expect. 58210 582112023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58212 58213 aarch64: Move ZA range checks to aarch64-opc.c 58214 This patch moves the range checks on ZA vector select offsets from 58215 gas to libopcodes. Doing the checks there means that the error 58216 messages contain the expected range. It also fits in better 58217 with the error severity scheme, which becomes important later. 58218 (This is because out-of-range indices are treated as more severe than 58219 syntax errors, on the basis that parsing must have succeeded if we get 58220 to the point of checking the completed opcode.) 58221 58222 The patch also adds a new check_za_access function for checking 58223 ZA accesses. That's a bit over the top for one offset check, but the 58224 function becomes more complex with later patches. 58225 58226 sme-9-illegal.s checked for an invalid .q suffix using: 58227 58228 psel p1, p15, p3.q[w15] 58229 58230 but this is doubly invalid because it misses the immediate part 58231 of the index. The patch keeps that test but adds another with 58232 a zero index, so that .q is the only thing wrong. 58233 58234 The aarch64-tbl.h change includes neatening up the backslash 58235 positions. 58236 582372023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58238 58239 aarch64: Pass aarch64_indexed_za to parsers 58240 ZA indices have more parts than most operands, so passing these 58241 parts around individually is more awkward than for other operand 58242 types. Things aren't too bad at the moment, but SME2 adds two 58243 further pieces: an offset range and a vector group size. 58244 58245 This patch therefore replaces arguments for the individual pieces 58246 with a single argument for the index as a whole. 58247 582482023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58249 58250 aarch64: Make indexed_za use 64-bit immediates 58251 A later patch moves the range checking for ZA vector select 58252 offsets from gas to libopcodes. That in turn requires the 58253 immediate field to be big enough to support all parsed values. 58254 58255 This shouldn't be a particularly size-sensitive structure, 58256 so there should be no memory problems with doing this. 58257 582582023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58259 58260 aarch64: Rename za_tile_vector to za_index 58261 za_tile_vector is also used for indexing ZA as a whole, rather than 58262 just for indexing tiles. The former is more common than the latter 58263 in SME2, so this patch generalises the name to "indexed_za". 58264 58265 The patch also names the associated structure, so that later patches 58266 can reuse it during parsing. 58267 582682023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58269 58270 aarch64: Treat ZA as a register 58271 We already treat the ZA tiles ZA0-ZA15 as registers. This patch 58272 does the same for ZA itself. parse_sme_zero_mask can then parse 58273 ZA tiles and ZA in the same way, through parsed_type_reg. 58274 58275 One important effect of going through parsed_type_reg (in general) 58276 is that it allows ZA to take qualifiers. This is necessary for many 58277 SME2 instructions. 58278 58279 However, to support existing unqualified uses of ZA, parse_reg_with_qual 58280 needs to treat the qualiier as optional. Hopefully the net effect is 58281 to give better error messages, since now that SME2 makes "za.<T>" 58282 valid in some contexts, it might be natural to use it (incorrectly) 58283 in ZERO too. 58284 58285 While there, the patch also tweaks the error messages for invalid 58286 ZA tiles, to try to make some cases more specific. 58287 58288 For now, parse_sme_za_array just uses parse_reg, rather than 58289 parse_typed_reg/parse_reg_with_qual. A later patch consolidates 58290 the parsing further. 58291 582922023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58293 58294 aarch64: Consolidate ZA tile range checks 58295 Now that all parsing of ZA tile names goes through parse_typed_reg, 58296 we can check there for out-of-range tile numbers. The other check 58297 performed by parse_sme_zada_operand was to reject .q, but that can 58298 now be done via F_STRICT instead. (.q tiles are valid in other 58299 contexts, so they shouldn't be rejected in parse_typed_reg.) 58300 58301 aarch64: Reuse parse_typed_reg for ZA tiles 58302 This patch reuses the general parse_typed_reg for ZA tiles. 58303 This involves adding a way of suppressing the usual treatment 58304 of register indices, since ZA indices look very different from 58305 Advanced SIMD and SVE vector indices. 58306 583072023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58308 58309 aarch64: Rework parse_typed_reg interface 58310 parse_typed_reg returned a register number and passed the 58311 register type back using a pointer parameter. It seems simpler 58312 to return the register entry instead, since that has both pieces 58313 of information in one place. 58314 58315 The patch also replaces the boolean in_reg_list parameter with 58316 a mask of flags. This hopefully makes calls easier to read 58317 (more self-documenting than "true" or "false"), but more 58318 importantly, it allows a later patch to add a second flag. 58319 583202023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58321 58322 aarch64: Move vectype_to_qualifier further up 58323 This patch just moves vectype_to_qualifier further up, so that 58324 a later patch can call it at an earlier point in the file. 58325 No behavioural change intended. 58326 58327 aarch64: Add REG_TYPE_ZATHV 58328 This patch adds a multi-register type that includes both REG_TYPE_ZATH 58329 and REG_TYPE_ZATV. This slightly simplifies the existing code, but the 58330 main purpose is to enable later patches. 58331 583322023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58333 58334 aarch64: Rename REG_TYPE_ZA* to REG_TYPE_ZAT* 58335 The ZA tile registers were called REG_TYPE_ZA, REG_TYPE_ZAH and 58336 REG_TYPE_ZAV. However, a later patch wants to make plain "za" 58337 a register type too, and REG_TYPE_ZA is the obvious name for that. 58338 58339 This patch therefore adds "T" (tile) to the existing names. 58340 583412023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58342 58343 aarch64: Use aarch64_operand_error more widely 58344 GAS's aarch64_instruction had its own cut-down error record, 58345 but it's better for later patches if it reuses the binutils-wide 58346 aarch64_operand_error instead. The main difference is that 58347 aarch64_operand_error can store arguments to the error while 58348 aarch64_instruction couldn't. 58349 583502023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58351 58352 aarch64: Make SME instructions use F_STRICT 58353 This patch makes all SME instructions use F_STRICT, so that qualifiers 58354 have to be provided explicitly rather than being inferred from other 58355 operands. The main change is to move the qualifier setting from the 58356 operand-level decoders to the opcode level. 58357 58358 This is one step towards consolidating the ZA parsing code and 58359 extending it to handle SME2. 58360 583612023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58362 58363 aarch64: Fix SVE2 register/immediate distinction 58364 GAS refuses to interpret register names like x0 as unadorned 58365 immediates, due to the obvious potential for confusion with 58366 register operands. (An explicit #x0 is OK.) 58367 58368 For compatibility reasons, we can't extend the set of registers 58369 that GAS rejects for existing instructions. For example: 58370 58371 mov x0, z0 58372 58373 was valid code before SVE was added, so it needs to stay valid 58374 code even when SVE is enabled. But we can make GAS reject newer 58375 registers in newer instructions. The SVE instruction: 58376 58377 and z0.s, z0.s, z0.h 58378 58379 is therefore invalid, rather than z0.h being an immediate. 58380 58381 This patch extends the SVE behaviour to SVE2. The old call 58382 to AARCH64_CPU_HAS_FEATURE was technically the wrong way around, 58383 although it didn't matter in practice for base SVE instructions 58384 since their avariants only set SVE. 58385 583862023-03-30 Richard Sandiford <richard.sandiford@arm.com> 58387 58388 aarch64: Restrict range of PRFM opcodes 58389 In the register-index forms of PRFM, the unallocated prefetch opcodes 58390 24-31 have been reused for the encoding of the new RPRFM instruction. 58391 The PRFM opcode space is now capped at 23 for these forms. The other 58392 forms of PRFM are unaffected. 58393 58394 aarch64: Fix PSEL opcode mask 58395 The opcode mask for PSEL was missing some bits, which meant 58396 that some upcoming SME2 opcodes would be misinterpreted as PSELs. 58397 58398 aarch64: Add sme-i16i64 and sme-f64f64 aliases 58399 Most extension flags are named after the associated architectural 58400 FEAT_* flags, but sme-i64 and sme-f64 were exceptions. This patch 58401 adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too 58402 for compatibility. 58403 584042023-03-30 Nick Clifton <nickc@redhat.com> 58405 58406 Fix an illegal memory access triggered by parsing corrupt DWARF info. 58407 PR 30284 58408 * dwarf.c (read_and_display_attr_value): Detect and ignore negative base values. 58409 584102023-03-30 Andrew Burgess <aburgess@redhat.com> 58411 58412 gdb/python: Add new gdb.unwinder.FrameId class 58413 When writing an unwinder it is necessary to create a new class to act 58414 as a frame-id. This new class is almost certainly just going to set a 58415 'sp' and 'pc' attribute within the instance. 58416 58417 This commit adds a little helper class gdb.unwinder.FrameId that does 58418 this job. Users can make use of this to avoid having to write out 58419 standard boilerplate code any time they write an unwinder. 58420 58421 Of course, if the user wants their FrameId class to be more 58422 complicated in some way, then they can still write their own class, 58423 just like they could before. 58424 58425 I've simplified the example code in the documentation to now use the 58426 new helper class, and I've also made use of this helper within the 58427 testsuite. 58428 58429 Any existing user code will continue to work just as it did before 58430 after this change. 58431 58432 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 58433 Reviewed-By: Tom Tromey <tom@tromey.com> 58434 584352023-03-30 Andrew Burgess <aburgess@redhat.com> 58436 58437 gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args 58438 Currently when creating a gdb.UnwindInfo object a user must call 58439 gdb.PendingFrame.create_unwind_info and pass a frame-id object. 58440 58441 The frame-id object should have at least a 'sp' attribute, and 58442 probably a 'pc' attribute too (it can also, in some cases have a 58443 'special' attribute). 58444 58445 Currently all of these frame-id attributes need to be gdb.Value 58446 objects, but the only reason for that requirement is that we have some 58447 code in py-unwind.c that only handles gdb.Value objects. 58448 58449 If instead we switch to using get_addr_from_python in py-utils.c then 58450 we will support both gdb.Value objects and also raw numbers, which 58451 might make things simpler in some cases. 58452 58453 So, I started rewriting pyuw_object_attribute_to_pointer (in 58454 py-unwind.c) to use get_addr_from_python. However, while looking at 58455 the code I noticed a problem. 58456 58457 The pyuw_object_attribute_to_pointer function returns a boolean flag, 58458 if everything goes OK we return true, but we return false in two 58459 cases, (1) when the attribute is not present, which might be 58460 acceptable, or might be an error, and (2) when we get an error trying 58461 to extract the attribute value, in which case a Python error will have 58462 been set. 58463 58464 Now in pending_framepy_create_unwind_info we have this code: 58465 58466 if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp)) 58467 { 58468 PyErr_SetString (PyExc_ValueError, 58469 _("frame_id should have 'sp' attribute.")); 58470 return NULL; 58471 } 58472 58473 Notice how we always set an error. This will override any error that 58474 is already set. 58475 58476 So, if you create a frame-id object that has an 'sp' attribute, but 58477 the attribute is not a gdb.Value, then currently we fail to extract 58478 the attribute value (it's not a gdb.Value) and set this error in 58479 pyuw_object_attribute_to_pointer: 58480 58481 rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr); 58482 if (!rc) 58483 PyErr_Format ( 58484 PyExc_ValueError, 58485 _("The value of the '%s' attribute is not a pointer."), 58486 attr_name); 58487 58488 Then we return to pending_framepy_create_unwind_info and immediately 58489 override this error with the error about 'sp' being missing. 58490 58491 This all feels very confused. 58492 58493 Here's my proposed solution: pyuw_object_attribute_to_pointer will now 58494 return a tri-state enum, with states OK, MISSING, or ERROR. The 58495 meanings of these states are: 58496 58497 OK - Attribute exists and was extracted fine, 58498 58499 MISSING - Attribute doesn't exist, no Python error was set. 58500 58501 ERROR - Attribute does exist, but there was an error while 58502 extracting it, a Python error was set. 58503 58504 We need to update pending_framepy_create_unwind_info, the only user of 58505 pyuw_object_attribute_to_pointer, but now I think things are much 58506 clearer. Errors from lower levels are not blindly overridden with the 58507 generic meaningless error message, but we still get the "missing 'sp' 58508 attribute" error when appropriate. 58509 58510 This change also includes the switch to get_addr_from_python which was 58511 what started this whole journey. 58512 58513 For well behaving user code there should be no visible changes after 58514 this commit. 58515 58516 For user code that hits an error, hopefully the new errors should be 58517 more helpful in figuring out what's gone wrong. 58518 58519 Additionally, users can now use integers for the 'sp' and 'pc' 58520 attributes in their frame-id objects if that is useful. 58521 58522 Reviewed-By: Tom Tromey <tom@tromey.com> 58523 585242023-03-30 Andrew Burgess <aburgess@redhat.com> 58525 58526 gdb: have value_as_address call unpack_pointer 58527 While refactoring some other code in gdb/python/* I wanted to merge 58528 two code paths. One path calls value_as_address, while the other 58529 calls unpack_pointer. 58530 58531 I suspect calling value_as_address is the correct choice, but, while 58532 examining the code I noticed that value_as_address calls unpack_long 58533 rather than unpack_pointer. 58534 58535 Under the hood, unpack_pointer does just call unpack_long so there's 58536 no real difference here, but it feels like value_as_address should 58537 call unpack_pointer. 58538 58539 I've updated the code to use unpack_pointer, and changed a related 58540 comment to say that we call unpack_pointer. I've also adjusted the 58541 header comment on value_as_address. The existing header refers to 58542 some code that is now commented out. 58543 58544 Rather than trying to describe the whole algorithm of 58545 value_as_address, which is already well commented within the function, 58546 I've just trimmed the comment on value_as_address to be a brief 58547 summary of what the function does. 58548 58549 There should be no user visible changes after this commit. 58550 58551 Reviewed-By: Tom Tromey <tom@tromey.com> 58552 585532023-03-30 Andrew Burgess <aburgess@redhat.com> 58554 58555 gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.UnwindInfo 58556 It is not currently possible to directly create gdb.UnwindInfo 58557 instances, they need to be created by calling 58558 gdb.PendingFrame.create_unwind_info so that the newly created 58559 UnwindInfo can be linked to the pending frame. 58560 58561 As such there's no tp_init method defined for UnwindInfo. 58562 58563 A consequence of all this is that it doesn't really make sense to 58564 allow sub-classing of gdb.UnwindInfo. Any sub-class can't call the 58565 parents __init__ method to correctly link up the PendingFrame 58566 object (there is no parent __init__ method). And any instances that 58567 sub-classes UnwindInfo but doesn't call the parent __init__ is going 58568 to be invalid for use in GDB. 58569 58570 This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo 58571 class, which prevents the class being sub-classed. Then I've added a 58572 test to check that this is indeed prevented. 58573 58574 Any functional user code will not have any issues with this change. 58575 58576 Reviewed-By: Tom Tromey <tom@tromey.com> 58577 585782023-03-30 Andrew Burgess <aburgess@redhat.com> 58579 58580 gdb/python: add __repr__ for PendingFrame and UnwindInfo 58581 Having a useful __repr__ method can make debugging Python code that 58582 little bit easier. This commit adds __repr__ for gdb.PendingFrame and 58583 gdb.UnwindInfo classes, along with some tests. 58584 58585 Reviewed-By: Tom Tromey <tom@tromey.com> 58586 585872023-03-30 Andrew Burgess <aburgess@redhat.com> 58588 58589 gdb/python: add some additional methods to gdb.PendingFrame 58590 The gdb.Frame class has far more methods than gdb.PendingFrame. Given 58591 that a PendingFrame hasn't yet been claimed by an unwinder, there is a 58592 limit to which methods we can add to it, but many of the methods that 58593 the Frame class has, the PendingFrame class could also support. 58594 58595 In this commit I've added those methods to PendingFrame that I believe 58596 are safe. 58597 58598 In terms of implementation: if I was starting from scratch then I 58599 would implement many of these (or most of these) as attributes rather 58600 than methods. However, given both Frame and PendingFrame are just 58601 different representation of a frame, I think there is value in keeping 58602 the interface for the two classes the same. For this reason 58603 everything here is a method -- that's what the Frame class does. 58604 58605 The new methods I've added are: 58606 58607 - gdb.PendingFrame.is_valid: Return True if the pending frame 58608 object is valid. 58609 58610 - gdb.PendingFrame.name: Return the name for the frame's function, 58611 or None. 58612 58613 - gdb.PendingFrame.pc: Return the $pc register value for this 58614 frame. 58615 58616 - gdb.PendingFrame.language: Return a string containing the 58617 language for this frame, or None. 58618 58619 - gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object 58620 for the current location within the pending frame, or None. 58621 58622 - gdb.PendingFrame.block: Return a gdb.Block for the current 58623 pending frame, or None. 58624 58625 - gdb.PendingFrame.function: Return a gdb.Symbol for the current 58626 pending frame, or None. 58627 58628 In every case I've just copied the implementation over from gdb.Frame 58629 and cleaned the code slightly e.g. NULL to nullptr. Additionally each 58630 function required a small update to reflect the PendingFrame type, but 58631 that's pretty minor. 58632 58633 There are tests for all the new methods. 58634 58635 For more extensive testing, I added the following code to the file 58636 gdb/python/lib/command/unwinders.py: 58637 58638 from gdb.unwinder import Unwinder 58639 58640 class TestUnwinder(Unwinder): 58641 def __init__(self): 58642 super().__init__("XXX_TestUnwinder_XXX") 58643 58644 def __call__(self,pending_frame): 58645 lang = pending_frame.language() 58646 try: 58647 block = pending_frame.block() 58648 assert isinstance(block, gdb.Block) 58649 except RuntimeError as rte: 58650 assert str(rte) == "Cannot locate block for frame." 58651 function = pending_frame.function() 58652 arch = pending_frame.architecture() 58653 assert arch is None or isinstance(arch, gdb.Architecture) 58654 name = pending_frame.name() 58655 assert name is None or isinstance(name, str) 58656 valid = pending_frame.is_valid() 58657 pc = pending_frame.pc() 58658 sal = pending_frame.find_sal() 58659 assert sal is None or isinstance(sal, gdb.Symtab_and_line) 58660 return None 58661 58662 gdb.unwinder.register_unwinder(None, TestUnwinder()) 58663 58664 This registers a global unwinder that calls each of the new 58665 PendingFrame methods and checks the result is of an acceptable type. 58666 The unwinder never claims any frames though, so shouldn't change how 58667 GDB actually behaves. 58668 58669 I then ran the testsuite. There was only a single regression, a test 58670 that uses 'disable unwinder' and expects a single unwinder to be 58671 disabled -- the extra unwinder is now disabled too, which changes the 58672 test output. So I'm reasonably confident that the new methods are not 58673 going to crash GDB. 58674 58675 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 58676 Reviewed-By: Tom Tromey <tom@tromey.com> 58677 586782023-03-30 Andrew Burgess <aburgess@redhat.com> 58679 58680 gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c 58681 This commit copies the pattern that is present in many other py-*.c 58682 files: having a single macro to check that the Python object is still 58683 valid. 58684 58685 This cleans up the code a little throughout the py-unwind.c file. 58686 58687 Some of the exception messages will change slightly with this commit, 58688 though the type of the exceptions is still ValueError in all cases. 58689 58690 I started writing some tests for this change and immediately ran into 58691 a problem: GDB would crash. It turns out that the PendingFrame 58692 objects are not being marked as invalid! 58693 58694 In pyuw_sniffer where the pending frames are created, we make use of a 58695 scoped_restore to invalidate the pending frame objects. However, this 58696 only restores the pending_frame_object::frame_info field to its 58697 previous value -- and it turns out we never actually give this field 58698 an initial value, it's left undefined. 58699 58700 So, when the scoped_restore (called invalidate_frame) performs its 58701 cleanup, it actually restores the frame_info field to an undefined 58702 value. If this undefined value is not nullptr then any future 58703 accesses to the PendingFrame object result in undefined behaviour and 58704 most likely, a crash. 58705 58706 As part of this commit I now initialize the frame_info field, which 58707 ensures all the new tests now pass. 58708 58709 Reviewed-By: Tom Tromey <tom@tromey.com> 58710 587112023-03-30 Andrew Burgess <aburgess@redhat.com> 58712 58713 gdb/python: remove unneeded nullptr check in frapy_block 58714 Spotted a redundant nullptr check in python/py-frame.c in the function 58715 frapy_block. This was introduced in commit 57126e4a45e3000e when we 58716 expanded an earlier check in return early if the pointer in question 58717 is nullptr. 58718 58719 There should be no user visible changes after this commit. 58720 58721 Reviewed-By: Tom Tromey <tom@tromey.com> 58722 587232023-03-30 Andrew Burgess <aburgess@redhat.com> 58724 58725 gdb/python: make the gdb.unwinder.Unwinder class more robust 58726 This commit makes a few related changes to the gdb.unwinder.Unwinder 58727 class attributes: 58728 58729 1. The 'name' attribute is now a read-only attribute. This prevents 58730 user code from changing the name after registering the unwinder. It 58731 seems very unlikely that any user is actually trying to do this in 58732 the wild, so I'm not very worried that this will upset anyone, 58733 58734 2. We now validate that the name is a string in the 58735 Unwinder.__init__ method, and throw an error if this is not the 58736 case. Hopefully nobody was doing this in the wild. This should 58737 make it easier to ensure the 'info unwinder' command shows sane 58738 output (how to display a non-string name for an unwinder?), 58739 58740 3. The 'enabled' attribute is now implemented with a getter and 58741 setter. In the setter we ensure that the new value is a boolean, 58742 but the real important change is that we call 58743 'gdb.invalidate_cached_frames()'. This means that the backtrace 58744 will be updated if a user manually disables an unwinder (rather than 58745 calling the 'disable unwinder' command). It is not unreasonable to 58746 think that a user might register multiple unwinders (relating to 58747 some project) and have one command that disables/enables all the 58748 related unwinders. This command might operate by poking the enabled 58749 attribute of each unwinder object directly, after this commit, this 58750 would now work correctly. 58751 58752 There's tests for all the changes, and lots of documentation updates 58753 that both cover the new changes, but also further improve (I think) 58754 the general documentation for GDB's Unwinder API. 58755 58756 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 58757 Reviewed-By: Tom Tromey <tom@tromey.com> 58758 587592023-03-30 Nick Clifton <nickc@redhat.com> 58760 58761 Fix an illegal memory access when an accessing a zer0-lengthverdef table. 58762 PR 30285 58763 * elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated. 58764 587652023-03-30 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 58766 58767 gprofng: Add version symbols to libgprofng.ver 58768 gprofng/ChangeLog 58769 2023-03-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 58770 58771 PR gprofng/30089 58772 * libcollector/libgprofng.ver: Add version symbols. 58773 * libcollector/synctrace.c: Fix typo for pthread_mutex_lock. 58774 587752023-03-30 Alan Modra <amodra@gmail.com> 58776 58777 Setting sh_link for SHT_REL/SHT_RELA 58778 It's wrong to have an alloc reloc section trying to use a non-alloc 58779 symbol table. 58780 58781 * elf.c (assign_section_numbers <SHT_REL, SHT_RELA>): Correct 58782 comment. Always set sh_link to .dynsym for alloc reloc 58783 sections and to .symtab for non-alloc. 58784 587852023-03-30 Alan Modra <amodra@gmail.com> 58786 58787 Fix memory leak in bfd_get_debug_link_info_1 58788 * opncls.c (bfd_get_alt_debug_link_info): Don't bother freeing 58789 after bfd_malloc_and_get_section failure. 58790 (get_build_id): Likewise. 58791 (bfd_get_debug_link_info_1): Likewise. Free section contents 58792 when crc not present. 58793 * section.c (bfd_malloc_and_get_section): Document that the 58794 buffer is NULL on error return. 58795 58796 Tidy leaked objcopy memory 58797 * objcopy.c (delete_symbol_htabs): Also free symbols. 58798 (write_debugging_info): Free strings and syms once written. 58799 * wrstabs.c (write_stabs_in_sections_debugging_info): memset 58800 entire info struct. Free hash tables before returning. Free 58801 syms on error return. 58802 58803 Tidy memory on addr2line failures 58804 * addr2line.c (process_file): Close bfd on error paths. 58805 588062023-03-30 Roland McGrath <mcgrathr@google.com> 58807 58808 Fix typo in ld manual --enable-non-contiguous-regions example 58809 588102023-03-30 GDB Administrator <gdbadmin@sourceware.org> 58811 58812 Automatic date update in version.in 58813 588142023-03-30 Palmer Dabbelt <palmer@rivosinc.com> 58815 58816 RISC-V: PR28789, Reject R_RISCV_PCREL relocations with ABS symbol in PIC/PIE. 58817 The non-preemptible SHN_ABS symbol with a pc-relative relocation should be 58818 disallowed when generating shared object (pic and pie). Generally, the 58819 following cases, which refer to pr25749, will cause a symbol be 58820 non-preemptible, 58821 58822 * -pie, or -shared with -symbolic 58823 * STV_HIDDEN, STV_INTERNAL, STV_PROTECTED 58824 * Have dynamic symbol table, but without the symbol 58825 * VER_NDX_LOCAL 58826 58827 However, PCREL_HI20/LO12 relocs are always bind locally when generating 58828 shared object, so not only the non-preemptible absolute symbol need to 58829 be disallowed, all absolute symbol references need but except that they 58830 are defined in linker script. If we also disallow the absolute symbol 58831 in linker script, then the glibc-linux toolchain build failed, so regard 58832 them as pc-relative symbols, just like what x86 did. 58833 58834 Maybe we should add this check for all pc-relative relocations, rather 58835 than just handle in R_RISCV_PCREL relocs. Ideally, since the value of 58836 SHN_ABS symbol is a constant, only S - A relocations should be allowed 58837 in the shared object, so only BFD_RELOC_8/16/32/64 are allowed, which 58838 means R_RISCV_32/R_RISCV_64. 58839 58840 bfd/ 58841 PR 28789 58842 * elfnn-riscv.c (riscv_elf_check_relocs): The absolute symbol cannot be 58843 referneced with pc-relative relocation when generating shared object. 58844 ld/ 58845 PR 28789 58846 * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 58847 * ld/testsuite/ld-riscv-elf/pcrel-reloc*: New testcases. 58848 588492023-03-30 Nelson Chu <nelson@rivosinc.com> 58850 58851 RISC-V: Clarify link behaviors of R_RISCV_32/64 relocations with ABS symbol. 58852 There are two improvements, which are all referenced to aarch64, 58853 58854 * R_RISCV_32 with non ABS symbol cannot be used under RV64 when making 58855 shard objects. 58856 58857 * Don't need dynamic relocation for R_RISCV_32/64 under RV32/RV64 when 58858 making shared objects, if the referenced symbol is local ABS symbol. 58859 58860 However, considering this link, 58861 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/341 58862 58863 Seems like we should makes all R_RISCV_32/64 relocs with ABS symbol 58864 that don't need any dynamic relocations when making the shared objects. 58865 But anyway, I just sync the current behavior as aarch64 ld, in case 58866 there are any unexpected behaviors happen. 58867 58868 Passed the gcc/binutils regressions in riscv-gnu-toolchain. 58869 58870 bfd/ 58871 * elfnn-riscv.c (riscv_elf_check_relocs): Only allow R_RISCV_32 with ABS 58872 symbol under RV64. 58873 (riscv_elf_relocate_section): R_RISCV_32/64 with local ABS symbol under 58874 RV32/RV64 doesn't need any dynamic relocation when making shared objects. 58875 I just make the implementations similar to other targets, so that will be 58876 more easy to mainatain. 58877 ld/ 58878 * testsuite/ld-riscv-elf/data-reloc*: New testcases. 58879 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Added new data-reloc* testcases, 58880 and need to make ifunc-seperate* testcases work for rv32. 58881 * testsuite/ld-riscv-elf/ifunc-seperate-caller-nonplt.s: Likewise. 58882 * testsuite/ld-riscv-elf/ifunc-seperate-caller-plt.s: Likewise. 58883 588842023-03-30 Nelson Chu <nelson@rivosinc.com> 58885 58886 RISC-V: Extract the ld code which are too complicated, and may be reused. 58887 These types of codes are different for each target, I am not sure what are the 58888 best for RISC-V, so extract them out may be more easy to compare what's the 58889 difference. 58890 58891 bfd/ 58892 * elfnn-riscv.c (RISCV_NEED_DYNAMIC_RELOC): New defined. Extracted 58893 from riscv_elf_check_relocs, to see if dynamic reloc is needed for the 58894 specific relocation. 58895 (RISCV_GENERATE_DYNAMIC_RELOC): New defined. Extracted from 58896 riscv_elf_relocate_section, to see if R_RISCV_32/64 need to generate 58897 dynamic relocation. 58898 (RISCV_COPY_INPUT_RELOC): New defined. Extracted from 58899 riscv_elf_relocate_section, to see if R_RISCV_32/64 need to copy itslef 58900 tp output file. 58901 (RISCV_RESOLVED_LOCALLY): New defined. Extracted from 58902 riscv_elf_relocate_section, to see if R_RISCV_GOT_HI20 can be resolved 58903 locally. 58904 589052023-03-29 Tom Tromey <tromey@adacore.com> 58906 58907 Use the correct frame when evaluating a dynamic property 58908 The test case in this patch shows an unusual situation: an Ada array 58909 has a dynamic bound, but the bound comes from a frame that's referred 58910 to by the static link. This frame is correctly found when evaluating 58911 the array variable itself, but is lost when evaluating the array's 58912 bounds. 58913 58914 This patch fixes the problem by passing this frame through to 58915 value_at_lazy in the DWARF expression evaluator. 58916 589172023-03-29 Tom Tromey <tromey@adacore.com> 58918 58919 Pass a frame to value_at_lazy and value_from_contents_and_address 58920 This patch adds a 'frame' parameter to value_at_lazy and ensures that 58921 it is passed down to the call to resolve_dynamic_type. This required 58922 also adding a frame parameter to value_from_contents_and_address. 58923 58924 Nothing passes this parameter to value_at_lazy yet, so this patch 58925 should have no visible effect. 58926 589272023-03-29 Tom Tromey <tromey@adacore.com> 58928 58929 Add frame parameter to resolve_dynamic_type 58930 This adds a frame parameter to resolve_dynamic_type and arranges for 58931 it to be passed through the call tree and, in particular, to all calls 58932 to dwarf2_evaluate_property. 58933 58934 Nothing passes this parameter yet, so this patch should have no 58935 visible effect. 58936 58937 A 'const frame_info_ptr *' is used here to avoid including frame.h 58938 from gdbtypes.h. 58939 589402023-03-29 Tom Tromey <tromey@adacore.com> 58941 58942 Remove version_at_least 58943 version_at_least is a less capable variant of version_compare, so this 58944 patch removes it. 58945 58946 Rewrite version_compare and rust_at_least 58947 This rewrites version_compare to allow the input lists to have 58948 different lengths, then rewrites rust_at_least to use version_compare. 58949 58950 Introduce rust_at_least helper proc 58951 This adds a 'rust_at_least' helper proc, for checking the version of 58952 the Rust compiler in use. It then changes various tests to use this 58953 with 'require'. 58954 589552023-03-29 Tom de Vries <tdevries@suse.de> 58956 58957 [gdb/testsuite] Require gnatmake 11 for gdb.ada/verylong.exp 58958 With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into: 58959 ... 58960 compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb 58961 prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" 58962 prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow) 58963 gnatmake: "prog.adb" compilation error 58964 58965 FAIL: gdb.ada/verylong.exp: compilation prog.adb 58966 ... 58967 58968 AFAICT, support for Long_Long_Long_Integer was added in gcc 11. 58969 58970 Fix this by requiring gnatmake version 11 or higher in the test-case. 58971 58972 Tested on x86_64-linux. 58973 589742023-03-29 Nils-Christian Kempke <nils-christian.kempke@intel.com> 58975 58976 doc: fix informations typo in gdb.texinfo 58977 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 58978 589792023-03-29 Nils-Christian Kempke <nils-christian.kempke@intel.com> 58980 58981 gdb, infcmd: remove redundant ERROR_NO_INFERIOR in continue_command 58982 The ERROR_NO_INFERIOR macro is already called at the beginning of the 58983 function continue_command. Since target/inferior are not switched in-between, 58984 the second call to it is redundant. 58985 58986 Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com> 58987 589882023-03-29 Andrew Burgess <aburgess@redhat.com> 58989 58990 gdb: move displaced_step_dump_bytes into gdbsupport (and rename) 58991 It was pointed out during review of another patch that the function 58992 displaced_step_dump_bytes really isn't specific to displaced stepping, 58993 and should really get a more generic name and move into gdbsupport/. 58994 58995 This commit does just that. The function is renamed to 58996 bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The 58997 function implementation doesn't really change. Much... 58998 58999 ... I have updated the function to take an array view, which makes it 59000 slightly easier to call in a couple of places where we already have a 59001 gdb::bytes_vector. I've then added an inline wrapper to convert a raw 59002 pointer and length into an array view, which is used in places where 59003 we don't easily have a gdb::bytes_vector (or similar). 59004 59005 Updated all users of displaced_step_dump_bytes. 59006 59007 There should be no user visible changes after this commit. 59008 59009 Finally, I ended up having to add an include of gdb_assert.h into 59010 array-view.h. When I include array-view.h into common-utils.h I ran 59011 into build problems because array-view.h calls gdb_assert. 59012 59013 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59014 590152023-03-29 Andrew Burgess <aburgess@redhat.com> 59016 59017 gdb: more debug output for displaced stepping 59018 While investigating a displaced stepping issue I wanted an easy way to 59019 see what GDB thought the original instruction was, and what 59020 instruction GDB replaced that with when performing the displaced step. 59021 59022 We do print out the address that is being stepped, so I can track down 59023 the original instruction, I just need to go find the information 59024 myself. 59025 59026 And we do print out the bytes of the new instruction, so I can figure 59027 out what the replacement instruction was, but it's not really easy. 59028 59029 Also, the code that prints the bytes of the replacement instruction 59030 only prints 4 bytes, which clearly isn't always going to be correct. 59031 59032 In this commit I remove the existing code that prints the bytes of the 59033 replacement instruction, and add two new blocks of code to 59034 displaced_step_prepare_throw. This new code prints the original 59035 instruction, and the replacement instruction. In each case we print 59036 both the bytes that make up the instruction and the completely 59037 disassembled instruction. 59038 59039 Here's an example of what the output looks like on x86-64 (this is 59040 with 'set debug displaced on'). The two interesting lines contain the 59041 strings 'original insn' and 'replacement insn': 59042 59043 (gdb) step 59044 [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now 59045 [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 <puts@got.plt> 59046 [displaced] prepare: selected buffer at 0x401052 59047 [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 59048 [displaced] fixup_riprel: %rip-relative addressing used. 59049 [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036 59050 [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff 59051 [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052 59052 [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx) 59053 [displaced] finish: restored 2892655.2892655.0 0x401052 59054 [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ... 59055 [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578 59056 0x00007ffff7e402c0 in puts () from /lib64/libc.so.6 59057 (gdb) 59058 59059 One final note. For many targets that support displaced stepping (in 59060 fact all targets except ARM) the replacement instruction is always a 59061 single instruction. But on ARM the replacement could actually be a 59062 series of instructions. 59063 59064 The debug code tries to handle this by disassembling the entire 59065 displaced stepping buffer. Obviously this might actually print more 59066 than is necessary, but there's (currently) no easy way to know how 59067 many instructions to disassemble; that knowledge is all locked in the 59068 architecture specific code. Still I don't think it really hurts, if 59069 someone is looking at this debug then hopefully they known what to 59070 expect. 59071 59072 Obviously we can imagine schemes where the architecture specific 59073 displaced stepping code could communicate back how many bytes its 59074 replacement sequence was, and then our debug print code could use this 59075 to limit the disassembly. But this seems like a lot of effort just to 59076 save printing a few additional instructions in some debug output. 59077 59078 I'm not proposing to do anything about this issue for now. 59079 59080 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59081 590822023-03-29 Tom de Vries <tdevries@suse.de> 59083 59084 [gdb/testsuite] Fix gdb.guile/scm-symbol.exp for remote host 59085 Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less 59086 strict. 59087 59088 Likewise in gdb.guile/scm-symtab.exp. 59089 59090 Tested on x86_64-linux. 59091 590922023-03-29 Tom de Vries <tdevries@suse.de> 59093 59094 [gdb/testsuite] Fix /gdb.guile/scm-parameter.exp for remote host 59095 Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into 59096 account that gdb_reinitialize_dir has no effect for remote host. 59097 59098 Tested on x86_64-linux. 59099 591002023-03-29 Tom de Vries <tdevries@suse.de> 59101 59102 [gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host 59103 Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download. 59104 59105 Tested on x86_64-linux. 59106 591072023-03-29 Tom de Vries <tdevries@suse.de> 59108 59109 [gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host 59110 Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file. 59111 59112 Tested on x86_64-linux. 59113 591142023-03-29 Tom de Vries <tdevries@suse.de> 59115 59116 [gdb/testsuite] Fix gdb.guile/scm-cmd.exp without readline 59117 Fix test-case gdb.guile/scm-cmd.exp using readline_is_used. 59118 59119 Tested on x86_64-linux. 59120 591212023-03-29 Tom de Vries <tdevries@suse.de> 59122 59123 [gdb/testsuite] Fix gdb.guile/guile.exp for remote host 59124 Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download. 59125 59126 Tested on x86_64-linux. 59127 591282023-03-29 Alan Modra <amodra@gmail.com> 59129 59130 Sanity check section size in bfd_init_section_compress_status 59131 This function doesn't just initialise for compression, it actually 59132 compresses. This patch sanity checks section size before allocating 59133 buffers for the uncompressed contents. 59134 59135 * compress.c (bfd_init_section_compress_status): Sanity check 59136 section size. 59137 591382023-03-29 Alan Modra <amodra@gmail.com> 59139 59140 Re: Fix an aout memory leak 59141 We have way too much duplicated code in bfd. Apply dd3a3d0af9f6 and 59142 920581c57e08 to pdp11.c. 59143 59144 * pdp11.c (bfd_free_cached_info): Free line_buf. Return true 59145 if tdata.aout_data is NULL. 59146 591472023-03-29 Alan Modra <amodra@gmail.com> 59148 59149 ld testsuite CFLAGS_FOR_TARGET 59150 run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it 59151 detects the program being run is a compiler. Since the program being 59152 run in lto.exp linking pr28138 is "sh", we need to add these by hand. 59153 This isn't exactly as run_host_cmd does, as it lacks reordering of 59154 any user -B option in $CC_FOR_TARGET, but it's better than ignoring 59155 gcc_B_opt. This fixes a mips64 testsuite fail. 59156 59157 ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there 59158 is no need for the ld_compile command line to include 59159 CFLAGS_FOR_TARGET. Fixing this is just a tidy. 59160 59161 * testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET 59162 and $ld_L_opt to pr28138 link line. 59163 * testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass 59164 unnecessary flags to ld_compile. 59165 (run_ld_link_exec_tests, run_cc_link_tests): Likewise. 59166 591672023-03-29 GDB Administrator <gdbadmin@sourceware.org> 59168 59169 Automatic date update in version.in 59170 591712023-03-28 Tom Tromey <tom@tromey.com> 59172 59173 Rename "raw" to "unrelocated" 59174 Per an earlier discussion, this patch renames the existing "raw" APIs 59175 to use the word "unrelocated" instead. 59176 59177 Use unrelocated_addr in minimal symbols 59178 This changes minimal symbols to use unrelocated_addr. I believe this 59179 detected a latent bug in add_pe_forwarded_sym. 59180 59181 Use unrelocated_addr in psymbols 59182 This changes psymbols themselves to use unrelocated_addr. This 59183 transform is largely mechanical. I don't think it finds any bugs. 59184 59185 Use unrelocated_addr in partial symbol tables 59186 This changes partial symbol tables to use unrelocated_addr for the 59187 text_high and text_low members. This revealed some latent bugs in 59188 ctfread.c, which are fixed here. 59189 59190 Move definition of unrelocated_addr earlier 59191 This moves the definition of unrelocated_addr a bit earlier in 59192 symtab.h, so that it can be used elsewhere in the file. 59193 59194 Use function_view in gdb_bfd_lookup_symbol 59195 This changes gdb_bfd_lookup_symbol to use a function_view. This 59196 simplifies the code a little bit. 59197 591982023-03-28 Tom de Vries <tdevries@suse.de> 59199 59200 [gdb/testsuite] Fix gdb.btrace/multi-inferior.exp for remote host 59201 Fix test-case gdb.btrace/multi-inferior.exp for remote host using 59202 gdb_remote_download. 59203 59204 Tested on x86_64-linux. 59205 592062023-03-28 Tom de Vries <tdevries@suse.de> 59207 59208 [gdb/testsuite] Fix gdb.btrace/gcore.exp for remote host 59209 Fix test-case gdb.btrace/gcore.exp for remote host using 59210 host_standard_output. 59211 59212 Tested on x86_64-linux. 59213 592142023-03-28 Tom de Vries <tdevries@suse.de> 59215 59216 [gdb/testsuite] Fix gdb.btrace/reconnect.exp for remote target 59217 Fix test-case gdb.btrace/reconnect.exp for target board 59218 remote-gdbserver-on-localhost using gdb_remote_download. 59219 59220 Tested on x86_64-linux. 59221 592222023-03-28 Tom Tromey <tromey@adacore.com> 59223 59224 Put pretty-printers to_string output in varobj result 59225 PR mi/11335 points out that an MI varobj will not display the result 59226 of a pretty-printer's "to_string" method. Instead, it always shows 59227 "{...}". 59228 59229 This does not seem very useful, and there have been multiple 59230 complaints about it over the years. This patch changes varobj to emit 59231 this string when possible, and updates the test suite. 59232 59233 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335 59234 592352023-03-28 Simon Marchi <simon.marchi@efficios.com> 59236 59237 gdb/testsuite: allow "require" callbacks to provide a reason 59238 When an allow_* proc returns false, it can be a bit difficult what check 59239 failed exactly, if the procedure does multiple checks. To make 59240 investigation easier, I propose to allow the "require" callbacks to be 59241 able to return a list of two elements: the zero/non-zero value, and a 59242 reason string. 59243 59244 Use the new feature in allow_hipcc_tests to demonstrate it (it's also 59245 where I hit actually hit this inconvenience). On my computer (where GDB 59246 is built with amd-dbgapi support but where I don't have a suitable GPU 59247 target), I get: 59248 59249 UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found) 59250 59251 vs before: 59252 59253 UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests 59254 59255 Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578 59256 Approved-By: Tom de Vries <tdevries@suse.de> 59257 592582023-03-28 Tom de Vries <tdevries@suse.de> 59259 59260 [gdb/testsuite] Fix gdb.server/server-kill-python.exp for remote host 59261 Fix test-case gdb.server/server-kill-python.exp for remote host using 59262 gdb_remote_download. 59263 59264 Tested on x86_64-linux. 59265 592662023-03-28 Tom de Vries <tdevries@suse.de> 59267 59268 [gdb/testsuite] Fix gdb.server/sysroot.exp for remote host 59269 Fix test-case gdb.server/sysroot.exp for remote host, by: 59270 - using gdb_remote_download, and 59271 - disabling the "local" scenario for remote host/target, unless 59272 remote host == remote target. 59273 59274 Tested on x86_64-linux. 59275 592762023-03-28 Tom de Vries <tdevries@suse.de> 59277 59278 [gdb/testsuite] Require non-remote host for gdb.server/multi-ui-errors.exp 59279 Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because 59280 it uses "spawn -pty", which creates a pty on build, which gdb cannot use on 59281 remote host. 59282 59283 Tested on x86_64-linux. 59284 592852023-03-28 Tom de Vries <tdevries@suse.de> 59286 59287 [gdb/testsuite] Fix gdb.server/solib-list.exp for remote host 59288 Fix test-case gdb.server/solib-list.exp for remote host using 59289 gdb_remote_download. 59290 59291 Likewise in another test-case. 59292 59293 Tested on x86_64-linux. 59294 592952023-03-28 Tom de Vries <tdevries@suse.de> 59296 59297 [gdb/testsuite] Fix gdb.server/file-transfer.exp for remote host 59298 Fix test-case gdb.server/file-transfer.exp for remote host using 59299 gdb_remote_download and host_standard_output_file. 59300 59301 Tested on x86_64-linux. 59302 593032023-03-28 Tom de Vries <tdevries@suse.de> 59304 59305 [gdb/testsuite] Fix local-remote-host-native.exp for gdb.server tests 59306 When running test-case gdb.server/stop-reply-no-thread-multi.exp with 59307 host+target board local-remote-host-native, I run into a time-out: 59308 ... 59309 (gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \ 59310 to_disable=: disconnect 59311 builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \ 59312 localhost:2346 stop-reply-no-thread-multi^M 59313 Process stop-reply-no-thread-multi created; pid = 32600^M 59314 Listening on port 2346^M 59315 set remote threads-packet off^M 59316 FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \ 59317 to_disable=: set remote threads-packet off (timeout) 59318 ... 59319 59320 This is due to this line in ${board}_spawn: 59321 ... 59322 set board_info($board,fileid) $spawn_id 59323 ... 59324 59325 We have the following series of events: 59326 - gdb is spawned, setting fileid 59327 - a few gdb commands (set height etc) are send using fileid, arrive at gdb and 59328 are successful 59329 - gdbserver is spawned, overwriting fileid 59330 - the next gdb command is sent using fileid, so it's send 59331 to gdbserver instead of gdb, and we run into the timeout. 59332 59333 There is some notion of current gdb, tracked in both gdb_spawn_id and fileid 59334 of the host board (see switch_gdb_spawn_id). And because the host and target 59335 board are the same, spawning something on the target overwrites the fileid on 59336 host, and consequently the current gdb. 59337 59338 Fix this by only setting fileid when spawning gdb. 59339 59340 Tested on x86_64-linux. 59341 59342 Now gdb.server/*.exp passes for host+target board local-remote-host-native, 59343 except for file-transfer.exp. 59344 59345 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734 59346 593472023-03-28 Enze Li <enze.li@hotmail.com> 59348 59349 gdb: use dynamic year in update-freebsd.sh 59350 When running update-freebsd.sh on FreeBSD, I see the following 59351 modification in freebsd.xml, 59352 59353 -<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc. 59354 +<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc. 59355 59356 It means that each time, when we running the update-freebsd.sh on 59357 FreeBSD, we have to correct the year of copyright manually. So fix this 59358 issue by using dynamic year. 59359 59360 Tested by regenerating freebsd.xml on FreeBSD/amd64. 59361 59362 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 59363 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59364 593652023-03-28 Tom de Vries <tdevries@suse.de> 59366 59367 [gdb/testsuite] Fix gdb.server/non-existing-program.exp with remote-gdbserver-on-localhost 59368 With test-case gdb.server/non-existing-program.exp and native, I have reliably: 59369 ... 59370 (gdb) builtin_spawn gdbserver stdio non-existing-program^M 59371 stdin/stdout redirected^M 59372 /bin/bash: line 0: exec: non-existing-program: not found^M 59373 During startup program exited with code 127.^M 59374 Exiting^M 59375 PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly 59376 ... 59377 59378 But with target board remote-gdbserver-on-localhost I sometimes have: 59379 ... 59380 (gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \ 59381 stdio non-existing-program^M 59382 stdin/stdout redirected^M 59383 /bin/bash: line 0: exec: non-existing-program: not found^M 59384 During startup program exited with code 127.^M 59385 Exiting^M 59386 Connection to localhost closed.^M^M 59387 PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly 59388 ... 59389 and sometimes the exact same output, but a FAIL instead. 59390 59391 Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps. 59392 59393 Tested on x86_64-linux. 59394 593952023-03-28 Alan Modra <amodra@gmail.com> 59396 59397 Avoid undefined behaviour in m68hc11 md_begin 59398 Given p = A where p is a pointer to some type and A is an array of 59399 that type, then the expression p - 1 + 1 evokes undefined behaviour 59400 according to the C standard. 59401 59402 gcc-13 -fsanitize=address,undefined complains about this, but not 59403 where the undefined behaviour actually occurs at tc-m68hc11.c:646. 59404 Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store 59405 to address 0x62600000016c with insufficient space for an object of 59406 type 'int'". Which is a lie. There most definitely is space there. 59407 Oh well, diagnostics are sometimes hard to get right. The UB is easy 59408 to avoid. 59409 59410 PR 30279 59411 * config/tc-m68hc11.c (md_begin): Avoid undefined pointer 59412 decrement. Remove unnecessary cast. 59413 594142023-03-28 Tom de Vries <tdevries@suse.de> 59415 59416 [gdb/testsuite] Allow gdb.rust/expr.exp without rust compiler 59417 Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives 59418 the wrong answer for gdb.rust/expr.exp, which doesn't require it. 59419 59420 Fix this by using can_compile rust in the test-cases that need it, and just 59421 returning 1 in allow_rust_tests. 59422 59423 Tested on x86_64-linux. 59424 594252023-03-28 Tom de Vries <tdevries@suse.de> 59426 59427 [gdb/testsuite] Add can_compile rust 59428 If I deinstall the rust compiler, I get: 59429 ... 59430 gdb compile failed, default_target_compile: Can't find rustc --color never. 59431 UNTESTED: gdb.rust/watch.exp: failed to prepare 59432 ... 59433 59434 Fix this by adding can_compile rust, and using it in allow_rust_tests, such 59435 that we have instead: 59436 ... 59437 UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests 59438 ... 59439 59440 Since the rest of the code in allow_rust_tests is also about availability of 59441 the rust compiler, move it to can_compile. 59442 59443 Tested on x86_64-linux. 59444 594452023-03-28 Tom de Vries <tdevries@suse.de> 59446 59447 [gdb/testsuite] Unsupport gdb.rust for remote host 59448 With test-case gdb.rust/watch.exp and remote host I run into: 59449 ... 59450 Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300) 59451 ... 59452 ld:watch.rs: file format not recognized; treating as linker script 59453 ld:watch.rs:1: syntax error 59454 ... 59455 UNTESTED: gdb.rust/watch.exp: failed to prepare 59456 ... 59457 59458 The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails. 59459 59460 Fix this by returning 0 in allow_rust_tests for remote host. 59461 59462 Tested on x86_64-linux. 59463 594642023-03-28 Alan Modra <amodra@gmail.com> 59465 59466 ubsan: elfnn-aarch64.c:4595:19: runtime error: load of value 190 59467 which is not a valid value for type '_Bool' 59468 59469 * elfnn-aarch64.c (stub_hash_newfunc): Clear all fields past root. 59470 594712023-03-28 GDB Administrator <gdbadmin@sourceware.org> 59472 59473 Automatic date update in version.in 59474 594752023-03-27 Tom de Vries <tdevries@suse.de> 59476 59477 [gdb/testsuite] Fix gnat_runtime_has_debug_info for remote host 59478 Fix gnat_runtime_has_debug_info for remote host by checking for 59479 allow_ada_tests. 59480 59481 This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and 59482 remote host. 59483 59484 Tested on x86_64-linux. 59485 594862023-03-27 John Baldwin <jhb@FreeBSD.org> 59487 59488 fbsd-nat: Use correct constant for target_waitstatus::sig. 59489 Use GDB_SIGNAL_TRAP instead of SIGTRAP. This is a no-op since the 59490 value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but 59491 it is more correct. 59492 59493 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59494 594952023-03-27 John Baldwin <jhb@FreeBSD.org> 59496 59497 fbsd-nat: Avoid a direct write to target_waitstatus::kind. 59498 This is in #ifdef'd code for a workaround for FreeBSD versions older 59499 than 11.1 which is why it wasn't caught earlier. 59500 59501 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59502 595032023-03-27 John Baldwin <jhb@FreeBSD.org> 59504 59505 fbsd-nat: Add missing spaces. 59506 No functional change, just style fixes. 59507 59508 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59509 595102023-03-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 59511 59512 gprofng: 30089 [display text] Invalid number of threads 59513 The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34 59514 We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.). 59515 Some of these functions have versions. For example, dlopen@GLIBC_2.34, 59516 dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc. 59517 We have to interpose each of the functions because we don't know 59518 which version of libC will be used during profiling. 59519 Historically, we have used three versions of scripts (mapfile.aarch64-Linux, 59520 mapfile.amd64-Linux, mapfile.intel-Linux). 59521 Three are not needed. One is enough 59522 59523 The fixes below include: 59524 - merged all version symbols into one version script. 59525 - added new version symbols which are defined in latest versions of libC. 59526 - removed unused defines and duplicated code. 59527 - added the DCL_FUNC_VER macro to define the version symbols. 59528 59529 Tested on x86_64 and aarch64 (OL8/OL9). No regression. 59530 59531 gprofng/ChangeLog 59532 2023-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 59533 59534 PR gprofng/30089 59535 * libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.* 59536 * libcollector/configure.ac: Delete GPROFNG_VARIANT. 59537 * src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h 59538 * libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER). 59539 Remove unused defines. 59540 * libcollector/dispatcher.c: Interpose functions from libC. 59541 Clean up the old code. 59542 * libcollector/iotrace.c: Likewise. 59543 * libcollector/libcol_util.c: Likewise. 59544 * libcollector/linetrace.c: Likewise. 59545 * libcollector/mmaptrace.c: Likewise. 59546 * libcollector/synctrace.c: Likewise. 59547 * libcollector/libgprofng.ver: New file. 59548 * libcollector/Makefile.in: Rebuild. 59549 * libcollector/configure: Rebuild. 59550 * libcollector/mapfile.aarch64-Linux: Removed. 59551 * libcollector/mapfile.amd64-Linux: Removed. 59552 * libcollector/mapfile.intel-Linux: Removed. 59553 * libcollector/mapfile.sparc-Linux: Removed. 59554 * libcollector/mapfile.sparcv9-Linux: Removed. 59555 595562023-03-27 Pedro Alves <pedro@palves.net> 59557 59558 linux-nat: introduce pending_status_str 59559 I noticed that some debug log output printing an lwp's pending status 59560 wasn't considering lp->waitstatus. This fixes it, by introducing a 59561 new pending_status_str function. 59562 59563 Also fix the comment in gdb/linux-nat.h describing 59564 lwp_info::waitstatus and details the description of lwp_info::status 59565 while at it. 59566 59567 Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980 59568 Approved-By: Andrew Burgess <aburgess@redhat.com> 59569 595702023-03-27 Pedro Alves <pedro@palves.net> 59571 59572 displaced step: pass down target_waitstatus instead of gdb_signal 59573 This commit tweaks displaced_step_finish & friends to pass down a 59574 target_waitstatus instead of a gdb_signal. This is needed because a 59575 patch later in the step-over-{thread-exit,clone] series will want to 59576 make displaced_step_buffers::finish handle 59577 TARGET_WAITKIND_THREAD_EXITED. It also helps with the 59578 TARGET_WAITKIND_THREAD_CLONED patch later in that same series. 59579 59580 It's also a bit more logical this way, as we don't have to pass down 59581 signals when the thread didn't actually stop for a signal. So we can 59582 also think of it as a clean up. 59583 59584 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 59585 Change-Id: I4c5d338647b028071bc498c4e47063795a2db4c0 59586 Approved-By: Andrew Burgess <aburgess@redhat.com> 59587 595882023-03-27 Tom de Vries <tdevries@suse.de> 59589 59590 [gdb/testsuite] Fix gdb.stabs/exclfwd.exp for remote host 59591 Fix test-case gdb.stabs/exclfwd.exp for remote host using include_file. 59592 59593 Tested on x86_64-linux. 59594 595952023-03-27 Tom de Vries <tdevries@suse.de> 59596 59597 [gdb/testsuite] Fix gdb.stabs/weird.exp for remote host 59598 Fix test-case gdb.stabs/weird.exp for remote host by not using an absolute 59599 destfile argument to gdb_remote_download, which doesn't work well with remotedir. 59600 596012023-03-27 Tom de Vries <tdevries@suse.de> 59602 59603 [gdb/testsuite] Fix gdb.gdb/unittest.exp for remote host 59604 Fix test-case gdb.gdb/unittest.exp for remote host, by: 59605 - disabling the completion tests if readline is not used, and 59606 - not using with_gdb_cwd $dir for remote host (because it does 59607 not support changing to "."). 59608 59609 Tested on x86_64-linux. 59610 596112023-03-27 Tom de Vries <tdevries@suse.de> 59612 59613 [gdb/testsuite] Skip do_self_tests on remote host 59614 In do_self_tests we try to find out the location of the gdb to debug, which 59615 will then be copied and renamed to xgdb. 59616 59617 In principle, the host board specifies the location of GDB, on host. 59618 59619 With remote host, we could upload that gdb from host to build/target, but we 59620 would miss the data directory (which is listed as the reason to skip 59621 do_self_tests for remote target). 59622 59623 We could fix that by instead taking the gdb from build instead, but that 59624 wouldn't work with installed testing. 59625 59626 It seems easier to just skip this on remote host. 59627 59628 It could be made to work for the "[is_remote host] && [is_remote target] 59629 && host == target" scenario (see board local-remote-host-native.exp), but 59630 that doesn't seem worth the effort. 59631 59632 Tested on x86_64-linux. 59633 596342023-03-27 Tom Tromey <tromey@adacore.com> 59635 59636 Change symbol::line to unsigned int 59637 A user here at AdaCore noticed that, when debugging a certain program, 59638 a stack frame reported line 34358, where it should have been line 59639 99894. 59640 59641 After debugging a bit, I discovered: 59642 59643 (top) p (99894 & ~65536) 59644 $60 = 34358 59645 59646 That line, symbol::line is too narrow. 59647 59648 This patch widens the member and changes all the uses that currently 59649 use the narrower type. 59650 59651 Approved-By: Simon Marchi <simon.marchi@efficios.com> 59652 596532023-03-27 Tom Tromey <tromey@adacore.com> 59654 59655 Fix 128-bit integer bug in Ada 59656 While working on 128-bit integer support, I found one spot in Ada that 59657 needed a fix as well. 59658 596592023-03-27 Tom Tromey <tromey@adacore.com> 59660 59661 Use gdb_gmp for scalar arithmetic 59662 This changes gdb to use scalar arithmetic for expression evaluation. 59663 59664 I suspect this patch is not truly complete, as there may be code paths 59665 that still don't correctly handle 128-bit integers. However, many 59666 things do work now. 59667 59668 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30190 59669 596702023-03-27 Tom Tromey <tromey@adacore.com> 59671 59672 Use value_true in value_equal and value_less 59673 Both value_equal and value_less use value_as_long to check a 59674 presumably boolean result of calling value_binop. However, 59675 value_binop in this case actually returns an int as wide as its 59676 arguments, and this approach can then fail for integers wider than 59677 LONGEST. Instead, rewrite this in a form that works for any size 59678 integer. 59679 596802023-03-27 Tom Tromey <tromey@adacore.com> 59681 59682 Simplify binop_promote 59683 binop_promote currently only handles integer sizes up to 59684 builtin_long_long. However, this may not handle 128-bit types. 59685 Simplify this code, unify the C and non-C (but not OpenCL, as I don't 59686 know how to test this) cases, and handle 128-bit integers as well. 59687 59688 This still doesn't exactly follow C or C++ rules. This could be 59689 implemented, but if so, I think it makes more sense as a C-specific 59690 expression node. 59691 596922023-03-27 Tom Tromey <tromey@adacore.com> 59693 59694 Add value_as_mpz and value_from_mpz 59695 This adds the two new functions, value_as_mpz and value_from_mpz, 59696 useful for manipulation values via gdb_mpz. 59697 59698 Add truncation mode to gdb_mpz 59699 This renames gdb_mpz::safe_export to export_bits, and adds a new flag 59700 to export a truncated value. This is needed by value arithmetic. 59701 59702 Avoid a copy in gdb_mpz::safe_export 59703 Currently, gdb_mpz::safe_export will always make a copy of *this. 59704 However, this copy isn't always needed. This patch makes this code 59705 slightly more efficient, by avoiding the copy when possible. 59706 59707 Add many operators to gdb_mpz 59708 This adds many operator overloads and other useful methods to gdb_mpz. 59709 This is preparation for using this class for scalar arithmetic in gdb 59710 expression evaluation. 59711 597122023-03-27 Tom Tromey <tromey@adacore.com> 59713 59714 Populate seen_names hash in cooked_index_shard::do_finalize 59715 Hannes pointed out that cooked_index_shard::do_finalize never 59716 populates the seen_names hash table. This patch adds the necessary 59717 store. This reduces memory use a little for "gdb gdb": 59718 59719 (before) Space used: 28909568 (+0 for this command) 59720 (after) Space used: 28884992 (+0 for this command) 59721 59722 What this means, btw, is that in gdb there are not many symbols that 59723 are both mentioned in many CUs and that also require name 59724 canonicalization. It's possible this would differ in other programs. 59725 597262023-03-27 Tom de Vries <tdevries@suse.de> 59727 59728 [gdb/testsuite] Fix gdb.asm/asm-source.exp for remote host 59729 Fix test-case gdb.asm/asm-source.exp for remote host using 59730 host_standard_output_file and gdb_remote_download. 59731 59732 Tested on x86_64-linux. 59733 597342023-03-27 Tom de Vries <tdevries@suse.de> 59735 59736 [gdb/testsuite] Fix gdb.dwarf2/imported-unit-bp-c.exp for remote host 59737 Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a 59738 downloaded source file. 59739 59740 Tested on x86_64-linux. 59741 597422023-03-27 Tom de Vries <tdevries@suse.de> 59743 59744 [gdb/testsuite] Unsupport gdb.dwarf2/gdb-add-index-symlink.exp for remote host 59745 Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote 59746 host, because the current implementation of gdb_ensure_index doesn't support it. 59747 59748 Tested on x86_64-linux. 59749 597502023-03-27 Tom de Vries <tdevries@suse.de> 59751 59752 [gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote host 59753 Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using 59754 host_standard_output_file. 59755 59756 Tested on x86_64-linux. 59757 597582023-03-27 Tom de Vries <tdevries@suse.de> 59759 59760 [gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp for remote host 59761 Fix test-case gdb.dwarf2/enqueued-cu-base-addr.exp for remote host by using 59762 $testfile instead $binfile. 59763 59764 Tested on x86_64-linux. 59765 597662023-03-27 Tom de Vries <tdevries@suse.de> 59767 59768 [gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote host 59769 Fix test-case gdb.dwarf2/gdb-index.exp on remote host using 59770 gdb_remote_download and host_standard_output_file. 59771 59772 Also declare the test-case unsupported with readnow. 59773 59774 Tested on x86_64-linux. 59775 597762023-03-27 Tom de Vries <tdevries@suse.de> 59777 59778 [gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp for remote host 59779 Fix test-case gdb.dwarf2/per-bfd-sharing.exp for remote host using 59780 gdb_remote_download. 59781 59782 Likewise in a few other test-cases. 59783 59784 Tested on x86_64-linux. 59785 597862023-03-27 Tom de Vries <tdevries@suse.de> 59787 59788 [gdb/testsuite] Fix quoting issue in gdb.base/index-cache.exp 59789 For test-case gdb.base/index-cache.exp and remote host, this: 59790 ... 59791 lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret 59792 ... 59793 gives us: 59794 ... 59795 Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index (timeout = 300) 59796 builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M 59797 rm: missing operand^M 59798 Try 'rm --help' for more information.^M 59799 FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir 59800 ... 59801 59802 Fix this using quote_for_host. Likewise in gdb.dwarf2/per-bfd-sharing.exp. 59803 59804 Tested on x86_64-linux. 59805 598062023-03-27 Tom de Vries <tdevries@suse.de> 59807 59808 [gdb/testsuite] Fix quoting issues in gdb.dwarf2 for remote host 59809 A few test-cases in gdb.dwarf2 use something like: 59810 ... 59811 additional_flags=\"-DFOO=BAR + 10\" 59812 ... 59813 which doesn't work on remote host. 59814 59815 Fix this by introducing a new proc quote_for_host that also works for remote 59816 host, such that we have: 59817 ... 59818 additional_flags=[quote_for_host -DFOO=BAR + 10] 59819 ... 59820 59821 Tested on x86_64-linux. 59822 598232023-03-27 Tom de Vries <tdevries@suse.de> 59824 59825 [gdb/testsuite] Fix have_index for remote host 59826 Proc have_index is mostly used with $binfile, which gives problems 59827 for remote host. 59828 59829 Fix this by using "file tail" on the proc argument. 59830 59831 Tested on x86_64-linux. 59832 598332023-03-27 Tom de Vries <tdevries@suse.de> 59834 59835 [gdb/testsuite] Add missing include_file in gdb.dwarf/*.exp 59836 598372023-03-27 Tom de Vries <tdevries@suse.de> 59838 59839 [gdb/testsuite] Add test-case gdb.dlang/dlang-start-2.exp 59840 For test-case gdb.dlang/dlang-start.exp, I run into: 59841 ... 59842 UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d 59843 ... 59844 59845 My distro has no support for gdc, but I'd like to have the test-case 59846 running and passing, so let's rewrite the test-case using dwarf assembly 59847 and add it alongside (rather than replacing it, because it's good to use 59848 actual compiler output if we have it available). 59849 59850 My distro does have a package providing dmd, so let's mimic that debug info in 59851 the dwarf assembly. This gives us: 59852 ... 59853 (gdb) start ^M 59854 Temporary breakpoint 1 at 0x4004ab^M 59855 Starting program: dlang-start-2 ^M 59856 ^M 59857 Temporary breakpoint 1, 0x00000000004004ab in _Dmain ()^M 59858 ... 59859 59860 The "_Dmain ()" should probably be "D main", I've filed PR30276 about that. 59861 59862 Also add a "show language" to check that we automatically set the language 59863 correctly to D. 59864 59865 Note that the dwarf assembly also describes main, otherwise the test-case 59866 doesn't function as regression test for commit 47fe57c9281 ("Fix "start" for 59867 D, Rust, etc"). 59868 59869 Tested on x86_64-linux. 59870 598712023-03-27 Alan Modra <amodra@gmail.com> 59872 59873 Tidy tc-ppc.c XCOFF auxent access 59874 It's better not to drill down into u.auxent but instead use a pointer 59875 to the combined_entry_type. That way the fix_scnlen field is 59876 available, and no one looking at the codes needs to wonder whether 59877 coffsymbol (symbol_get_bfdsym (sym))->native[i + 1] is the same 59878 auxent. 59879 59880 * config/tc-ppc.c (ppc_frob_symbol): Tidy XCOFF auxent access. 59881 (ppc_adjust_symtab): Likewise. 59882 598832023-03-27 Alan Modra <amodra@gmail.com> 59884 59885 Remove coff_pointerize_aux table_end param 59886 I'm fairly certain the table_end checks are redundant now. This 59887 patch reverts commit 334d4ced42d3. 59888 59889 * coffgen.c (coff_pointerize_aux): Remove table_end parameter. 59890 (coff_get_normalized_symtab): Adjust to suit. 59891 598922023-03-27 Alan Modra <amodra@gmail.com> 59893 59894 Use stdint types in coff internal_auxent 59895 long is a poor choice of type to store 32-bit values read from 59896 objects files by H_GET_32. H_GET_32 doesn't sign extend so tests like 59897 that in gdb/coffread.c for "negative" values won't work if long is 59898 larger than 32 bits. If long is 32-bit then code needs to be careful 59899 to not accidentally index negative array elements. (I'd rather see a 59900 segfault on an unmapped 4G array index than silently reading bogus 59901 data.) long is also a poor choice for x_sect.s_scnlen, which might 59902 have 64-bit values. It's better to use unsigned exact width types to 59903 avoid surprises. 59904 59905 I decided to change the field names too, which makes most of this 59906 patch simply renaming. Besides that there are a few places where 59907 casts are no longer needed, and where printf format strings or tests 59908 need adjusting. 59909 59910 include/ 59911 * coff/internal.h (union internal_auxent): Use unsigned stdint 59912 types. Rename l fields to u32 and u64 as appropriate. 59913 bfd/ 59914 * coff-bfd.c, 59915 * coff-rs6000.c, 59916 * coff64-rs6000.c, 59917 * coffcode.h, 59918 * coffgen.c, 59919 * cofflink.c, 59920 * coffswap.h, 59921 * peXXigen.c, 59922 * xcofflink.c: Adjust to suit internal_auxent changes. 59923 binutils/ 59924 * rdcoff.c: Adjust to suit internal_auxent changes. 59925 gas/ 59926 * config/obj-coff.h, 59927 * config/tc-ppc.c: Adjust to suit internal_auxent changes. 59928 gdb/ 59929 * coffread.c, 59930 * xcoffread.c: Adjust to suit internal_auxent changes. 59931 ld/ 59932 * pe-dll.c: Adjust to suit internal_auxent changes. 59933 599342023-03-27 Alan Modra <amodra@gmail.com> 59935 59936 Set proper union selector tag 59937 * coff-bfd.c (bfd_coff_get_auxent): After converting sym pointer 59938 to an index, reset the union tag. 59939 599402023-03-27 Alan Modra <amodra@gmail.com> 59941 59942 coffgrok access of u.auxent.x_sym.x_tagndx.p 59943 u.auxent.x_sym.x_tagndx is a union. The p field is only valid when 59944 fix_tag is set. This patch fixes code in coffgrok.c that accessed the 59945 field without first checking fix_tag, and removes a whole lot of code 59946 validating bogus pointers to prevent segfaults (which no longer 59947 happen, I checked the referenced PR 17512 testcases). The patch also 59948 documents this in the fix_tag comment, makes is_sym a bitfield, and 59949 sorts the selecter fields a little. 59950 59951 bfd/ 59952 * coffcode.h (combined_entry_type): Make is_sym a bitfield. 59953 Sort and comment on union selectors. 59954 * libcoff.h: Regenerate. 59955 binutils/ 59956 * coffgrok.c (do_type): Make aux a combined_entry_type. Test 59957 fix_tag before accessing u.auxent.x_sym.x_tagndx.p. Remove 59958 now unnecessary pointer bounds checking. 59959 599602023-03-27 Alan Modra <amodra@gmail.com> 59961 59962 Duplicate DW_AT_call_file leak 59963 When given two or more DW_AT_call_file for a given function we 59964 currently leak the concat memory. 59965 59966 * dwarf2.c (scan_unit_for_symbols): Don't leak on duplicate 59967 DW_AT_call_file. 59968 599692023-03-27 Alan Modra <amodra@gmail.com> 59970 59971 XCOFF sanity check 59972 * coffcode.h (coff_pointerize_aux_hook): Sanity check 59973 x_csect.x_scnlen against raw_syment_count. 59974 599752023-03-27 Nick Clifton <nickc@redhat.com> 59976 59977 Add an option to the gold linker to put its version string into the .comment section. 59978 PR 30187 59979 * options.h (class General_options): Add enable-linker-version. 59980 * layout.cc (Layout::create_gold_note): If linker-version is enabled put the version string into the .comment section. 59981 599822023-03-27 Tom de Vries <tdevries@suse.de> 59983 59984 [gdb/testsuite] Handle missing gdc in gdb.dlang/dlang-start.exp 59985 On openSUSE Leap 15.4, I get: 59986 ... 59987 Running gdb.dlang/dlang-start.exp ... 59988 gdb compile failed, default_target_compile: Can't find gdc. 59989 UNTESTED: gdb.dlang/dlang-start.exp: failed to prepare 59990 ... 59991 59992 Fix this by: 59993 - introducing a new proc can_compile, and 59994 - requiring "can_compile d" in the test-case, 59995 such that I have instead: 59996 ... 59997 Running gdb.dlang/dlang-start.exp ... 59998 UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d 59999 ... 60000 60001 Tested on x86_64-linux, on openSUSE Leap 15.4 and Fedora 37. 60002 600032023-03-27 Tom de Vries <tdevries@suse.de> 60004 60005 [gdb/testsuite] Remove superfluous pid in temp files 60006 While trying to use gdb_can_simple_compile with a d program, I ran into: 60007 ... 60008 /data/vries/gdb/f37/build/gdb/testsuite/temp/105856/can_compile_d-105856.d: \ 60009 error: module 'can_compile_d-105856' has non-identifier characters in \ 60010 filename, use module declaration instead 60011 ... 60012 60013 The d compiler has a problem with the filename can_compile_d-105856.d, which 60014 contains the pid. The pid is added by gdb_simple_compile: 60015 ... 60016 set obj [standard_temp_file $name-[pid].$postfix] 60017 ... 60018 but it's unnecessary because standard_temp_file already uses the pid. 60019 60020 Fix this by removing "[pid]" in all calls to standard_temp_file. 60021 60022 Tested on x86_64-linux. 60023 600242023-03-27 GDB Administrator <gdbadmin@sourceware.org> 60025 60026 Automatic date update in version.in 60027 600282023-03-26 Tom de Vries <tdevries@suse.de> 60029 60030 [gdb/testsuite] Introduce allow_dap_tests 60031 Simon pointed out that with gdb.dap/*.exp and target board 60032 native-gdbserver, we run into problems. 60033 60034 I see for each test-case: 60035 ... 60036 +++ run 60037 Traceback (most recent call last): 60038 File "startup.py", line 146, in exec_and_log 60039 output = gdb.execute(cmd, from_tty=True, to_string=True) 60040 gdb.error: Don't know how to run. Try "help target". 60041 ... 60042 60043 Likewise with target board native-extended-gdbserver. 60044 60045 Fix this by: 60046 - adding a new proc allow_dap_tests, 60047 - using it in all the gdb.dap tests, and 60048 - bailing out if GDBFLAGS/INTERNAL_GDBFLAGS contains 60049 "set auto-connect-native-target off". 60050 60051 Tested on x86_64-linux. 60052 60053 Reported-By: Simon Marchi <simon.marchi@efficios.com> 60054 Approved-By: Tom Tromey <tom@tromey.com> 60055 600562023-03-26 GDB Administrator <gdbadmin@sourceware.org> 60057 60058 Automatic date update in version.in 60059 600602023-03-25 GDB Administrator <gdbadmin@sourceware.org> 60061 60062 Automatic date update in version.in 60063 600642023-03-24 Tom Tromey <tromey@adacore.com> 60065 60066 Preserve name of range types 60067 The type-allocation patches introduced a small regression that was 60068 picked up by the AdaCore internal test suite. Previously, the name of 60069 a range type was preserved by resolve_dynamic_range, but now it is 60070 not. This patch changes this code to preserve the name. 60071 60072 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 60073 600742023-03-24 Tom Tromey <tromey@adacore.com> 60075 60076 Implement repl evaluation for DAP 60077 The evaluate command supports a "context" parameter which tells the 60078 adapter the context in which an evaluation occurs. One of the 60079 supported values is "repl", which we took to mean evaluation of a gdb 60080 command. That is what this patch implements. 60081 60082 Note that some gdb commands probably will not work correctly with the 60083 rest of the protocol. For example if the user types "continue", 60084 confusion may result. 60085 60086 This patch requires the earlier patch to fix up scopes in DAP. 60087 600882023-03-24 Tom de Vries <tdevries@suse.de> 60089 60090 [gdb/symtab] Fix line number of static const class member 60091 Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there 60092 was a silent regression on openSUSE Leap 15.4 for test-case 60093 gdb.cp/m-static.exp, from: 60094 ... 60095 (gdb) info variable everywhere^M 60096 All variables matching regular expression "everywhere":^M 60097 ^M 60098 File /home/vries/tmp.local-remote-host-native/m-static.h:^M 60099 8: const int gnu_obj_4::everywhere;^M 60100 (gdb) 60101 ... 60102 to: 60103 ... 60104 (gdb) info variable everywhere^M 60105 All variables matching regular expression "everywhere":^M 60106 ^M 60107 File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 60108 8: const int gnu_obj_4::everywhere;^M 60109 ^M 60110 File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M 60111 8: const int gnu_obj_4::everywhere;^M 60112 (gdb) 60113 ... 60114 60115 Another regression was found due to that commit, and it was fixed in commit 60116 99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by 60117 limiting the scope of the fix in the original commit. 60118 60119 Fix this regression by yet further limiting the scope of that fix, making sure 60120 that this bit in dwarf_decode_lines is executed again for m-static1.cc: 60121 ... 60122 /* Make sure a symtab is created for every file, even files 60123 which contain only variables (i.e. no code with associated 60124 line numbers). */ 60125 ... 60126 60127 Tested on x86_64-linux. 60128 60129 PR symtab/30265 60130 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265 60131 601322023-03-24 Nick Alcock <nick.alcock@oracle.com> 60133 60134 libctf: get the offsets of fields of unnamed structs/unions right 60135 We were failing to add the offsets of the containing struct/union 60136 in this case, leading to all offsets being relative to the unnamed 60137 struct/union itself. 60138 60139 libctf/ 60140 PR libctf/30264 60141 * ctf-types.c (ctf_member_info): Add the offset of the unnamed 60142 member of the current struct as necessary. 60143 * testsuite/libctf-lookup/unnamed-field-info*: New test. 60144 601452023-03-24 Nick Alcock <nick.alcock@oracle.com> 60146 60147 libctf: fix a comment typo 60148 ctf_dedup's intern() function does not return a dynamically allocated 60149 string, so I just spent ten minutes auditing for obvious memory leaks 60150 that couldn't actually happen. Update the comment to note what it 60151 actually returns (a pointer into an atoms table: i.e. possibly not 60152 a new string, and not so easily leakable). 60153 60154 libctf/ 60155 * ctf-dedup.c (intern): Update comment. 60156 601572023-03-24 Nick Alcock <nick.alcock@oracle.com> 60158 60159 libctf: work around an uninitialized variable warning 60160 GCC 11+ complains that sym is uninitialized in ctf_symbol_next. It 60161 isn't, but it's not quite smart enough to figure that out (it requires 60162 domain-specific knowledge of the state of the ctf_next_t iterator 60163 over multiple calls). 60164 60165 libctf/ 60166 * ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable 60167 value for returning if never reset during the function. 60168 601692023-03-24 Nick Alcock <nick.alcock@oracle.com> 60170 60171 libctf: fix assertion failure with no system qsort_r 60172 If no suitable qsort_r is found in libc, we fall back to an 60173 implementation in ctf-qsort.c. But this implementation routinely calls 60174 the comparison function with two identical arguments. The comparison 60175 function that ensures that the order of output types is stable is not 60176 ready for this, misinterprets it as a type appearing more that once (a 60177 can-never-happen condition) and fails with an assertion failure. 60178 60179 Fixed, audited for further instances of the same failure (none found) 60180 and added a no-qsort test to my regular testsuite run. 60181 60182 libctf/: 60183 PR libctf/30013 60184 * ctf-dedup.c (sort_output_mapping): Inputs are always equal to 60185 themselves. 60186 601872023-03-24 Tom Tromey <tromey@adacore.com> 60188 60189 Fix race in DAP startup 60190 Internal AdaCore DAP testing on Windows has had occasional failures 60191 that show: 60192 60193 assert threading.current_thread() is _dap_thread 60194 60195 I think this is a race in DAP startup: the _dap_thread global is only 60196 set on return from start_thread, but it seems possible that the thread 60197 itself could already run and encounter a @in_dap_thread decorator. 60198 60199 This patch fixes the problem by setting the global before running any 60200 of the code in the new thread. This also lets us remove a FIXME. 60201 602022023-03-24 Luis Machado <luis.machado@arm.com> 60203 60204 aarch64: Check for valid inferior thread/regcache before reading pauth registers 60205 There were reports of gdb throwing internal errors when calling 60206 inferior_thread ()/get_current_regcache () on a system with 60207 Pointer Authentication enabled. 60208 60209 In such cases, gdb produces the following backtrace: 60210 60211 ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. 60212 A problem internal to GDB has been detected, 60213 further debugging may prove unreliable. 60214 ----- Backtrace ----- 60215 0xaaaae04a571f gdb_internal_backtrace_1 60216 ../../../repos/binutils-gdb/gdb/bt-utils.c:122 60217 0xaaaae04a57f3 _Z22gdb_internal_backtracev 60218 ../../../repos/binutils-gdb/gdb/bt-utils.c:168 60219 0xaaaae0b52ccf internal_vproblem 60220 ../../../repos/binutils-gdb/gdb/utils.c:401 60221 0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list 60222 ../../../repos/binutils-gdb/gdb/utils.c:481 60223 0xaaaae0e24b8f _Z18internal_error_locPKciS0_z 60224 ../../../repos/binutils-gdb/gdbsupport/errors.cc:58 60225 0xaaaae0a88983 _Z15inferior_threadv 60226 ../../../repos/binutils-gdb/gdb/thread.c:86 60227 0xaaaae0956c87 _Z20get_current_regcachev 60228 ../../../repos/binutils-gdb/gdb/regcache.c:428 60229 0xaaaae035223f aarch64_remove_non_address_bits 60230 ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572 60231 0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm 60232 ../../../repos/binutils-gdb/gdb/gdbarch.c:3109 60233 0xaaaae0a692d7 memory_xfer_partial 60234 ../../../repos/binutils-gdb/gdb/target.c:1620 60235 0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm 60236 ../../../repos/binutils-gdb/gdb/target.c:1684 60237 0xaaaae0a69e9f target_read_partial 60238 ../../../repos/binutils-gdb/gdb/target.c:1937 60239 0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml 60240 ../../../repos/binutils-gdb/gdb/target.c:1977 60241 0xaaaae0a69937 _Z18target_read_memorymPhl 60242 ../../../repos/binutils-gdb/gdb/target.c:1773 60243 0xaaaae08be523 ps_xfer_memory 60244 ../../../repos/binutils-gdb/gdb/proc-service.c:90 60245 0xaaaae08be6db ps_pdread 60246 ../../../repos/binutils-gdb/gdb/proc-service.c:124 60247 0x40001ed7c3b3 _td_fetch_value 60248 /build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115 60249 0x40001ed791ef td_ta_map_lwp2thr 60250 /build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194 60251 0xaaaae07f4473 thread_from_lwp 60252 ../../../repos/binutils-gdb/gdb/linux-thread-db.c:413 60253 0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE 60254 ../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420 60255 0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE 60256 ../../../repos/binutils-gdb/gdb/target.c:2586 60257 0xaaaae0789cf7 do_target_wait_1 60258 ../../../repos/binutils-gdb/gdb/infrun.c:3825 60259 0xaaaae0789e6f operator() 60260 ../../../repos/binutils-gdb/gdb/infrun.c:3884 60261 0xaaaae078a167 do_target_wait 60262 ../../../repos/binutils-gdb/gdb/infrun.c:3903 60263 0xaaaae078b0af _Z20fetch_inferior_eventv 60264 ../../../repos/binutils-gdb/gdb/infrun.c:4314 60265 0xaaaae076652f _Z22inferior_event_handler19inferior_event_type 60266 ../../../repos/binutils-gdb/gdb/inf-loop.c:41 60267 0xaaaae07dc68b handle_target_event 60268 ../../../repos/binutils-gdb/gdb/linux-nat.c:4206 60269 0xaaaae0e25fbb handle_file_event 60270 ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573 60271 0xaaaae0e264f3 gdb_wait_for_event 60272 ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694 60273 0xaaaae0e24f9b _Z16gdb_do_one_eventi 60274 ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217 60275 0xaaaae080f033 start_event_loop 60276 ../../../repos/binutils-gdb/gdb/main.c:411 60277 0xaaaae080f1b7 captured_command_loop 60278 ../../../repos/binutils-gdb/gdb/main.c:475 60279 0xaaaae0810b97 captured_main 60280 ../../../repos/binutils-gdb/gdb/main.c:1318 60281 0xaaaae0810c1b _Z8gdb_mainP18captured_main_args 60282 ../../../repos/binutils-gdb/gdb/main.c:1337 60283 0xaaaae0338453 main 60284 ../../../repos/binutils-gdb/gdb/gdb.c:32 60285 --------------------- 60286 ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. 60287 A problem internal to GDB has been detected, 60288 further debugging may prove unreliable. 60289 Quit this debugging session? (y or n) 60290 60291 We also see failures across the testsuite if the tests get executed on a target 60292 that has native support for the pointer authentication feature. But 60293 gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of 60294 tests that run into errors and internal errors. 60295 60296 This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which 60297 enabled more broad use of pointer authentication masks to remove non-address 60298 bits of pointers, but wasn't immediately detected because systems with native 60299 support for pointer authentication are not that common yet. 60300 60301 The above crash happens because gdb is in the middle of handling an event, 60302 and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the 60303 current thread. This means a call to inferior_thread () will assert, and 60304 attempting to call get_current_regcache () will also call inferior_thread (), 60305 resulting in an assertion as well. 60306 60307 target_has_registers was one function that seemed useful for detecting these 60308 types of situation where we don't have a register cache. The problem with that 60309 is the inconsistent state of inferior_ptid, which is used by 60310 target_has_registers. 60311 60312 Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from 60313 do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to 60314 ps_xfer_memory sets inferior_ptid momentarily before reading memory: 60315 60316 static ps_err_e 60317 ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr, 60318 gdb_byte *buf, size_t len, int write) 60319 { 60320 scoped_restore_current_inferior restore_inferior; 60321 set_current_inferior (ph->thread->inf); 60322 60323 scoped_restore_current_program_space restore_current_progspace; 60324 set_current_program_space (ph->thread->inf->pspace); 60325 60326 scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid); 60327 inferior_ptid = ph->thread->ptid; 60328 60329 CORE_ADDR core_addr = ps_addr_to_core_addr (addr); 60330 60331 int ret; 60332 if (write) 60333 ret = target_write_memory (core_addr, buf, len); 60334 else 60335 ret = target_read_memory (core_addr, buf, len); 60336 return (ret == 0 ? PS_OK : PS_ERR); 60337 } 60338 60339 Maybe this shouldn't happen, or maybe it is just an unfortunate state to be 60340 in. But this prevents the use of target_has_registers to guard against the 60341 lack of registers, since, although current_thread_ is still nullptr, 60342 inferior_ptid is valid and is not null_ptid. 60343 60344 There is another crash scenario after we kill a previously active inferior, in 60345 which case the gdbarch will still say we support pointer authentication but we 60346 will also have no current thread (inferior_thread () will assert etc). 60347 60348 If the target has support for pointer authentication, gdb needs to use 60349 a couple (or 4, for bare-metal) mask registers to mask off some bits of 60350 pointers, and for that it needs to access the registers. 60351 60352 At some points, like the one from the backtrace above, there is no active 60353 thread/current regcache because gdb is in the middle of doing event handling 60354 and switching between threads. 60355 60356 Simon suggested the use of inferior_ptid to fetch the register cache, as 60357 opposed to relying on the current register cache. Though we need to make sure 60358 inferior_ptid is valid (not null_ptid), I think this works nicely. 60359 60360 With inferior_ptid, we can do safety checks along the way, making sure we have 60361 a thread to fetch a register cache from and checking if the thread is actually 60362 stopped or running. 60363 60364 The following patch implements this idea with safety checks to make sure we 60365 don't run into assertions or errors. If any of the checks fail, we fallback to 60366 using a default mask to remove non-address bits of a pointer. 60367 60368 I discussed with Pedro the possibility of caching the mask register values 60369 (which are per-process and can change mid-execution), but there isn't a good 60370 spot to cache those values. Besides, the mask registers can change constantly 60371 for bare-metal debugging when switching between exception levels. 60372 60373 In some cases, it is just not possible to get access to these mask registers, 60374 like the case where threads are running. In those cases, using a default mask 60375 to remove the non-address bits should be enough. 60376 60377 This can happen when we let threads run in the background and then we attempt 60378 to access a memory address (now that gdb is capable of reading memory even 60379 with threads running). Thus gdb will attempt to remove non-address bits 60380 of that memory access, will attempt to access registers, running into errors. 60381 60382 Regression-tested on aarch64-linux Ubuntu 20.04. 60383 603842023-03-24 Alan Modra <amodra@gmail.com> 60385 60386 Tidy string_ptr increment 60387 * peicode.h (pe_ILF_make_a_symbol): Use sprintf output to 60388 increment string_ptr to end of new string. 60389 60390 Tidy dwarf1 cached section contents 60391 * dwarf1.c (_bfd_dwarf1_cleanup_debug_info): New function. 60392 * libbfd-in.h (_bfd_dwarf1_cleanup_debug_info): Declare. 60393 * elf.c (_bfd_elf_close_and_cleanup): Call it. 60394 * elf-bfd.h (struct elf_obj_tdata): Make dwarf1_find_line_info 60395 a void*. 60396 * libbfd.h: Regenerate. 60397 603982023-03-24 Tom de Vries <tdevries@suse.de> 60399 60400 [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument 60401 In proc mi_expect_stop there's a proc argument reason that's handled like so: 60402 ... 60403 set r "reason=\"$reason\"," 60404 ... 60405 60406 That's fine for say: 60407 ... 60408 set reason "foo" 60409 ... 60410 for which this evaluates to: 60411 ... 60412 set r "reason=\"foo\"," 60413 ... 60414 60415 But there are more complex uses, for instance: 60416 ... 60417 set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal" 60418 ... 60419 which evaluates to: 60420 ... 60421 set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\"" 60422 ... 60423 60424 Note how in this reason argument, the first two '\"' seems to form a pair 60425 surrounding ',disp=', which is not the case, which is confusing. 60426 60427 Fix this by only adding the quotes in mi_expect_stop if the string doesn't 60428 already contain quotes, such that we have the more readable: 60429 ... 60430 set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\"" 60431 ... 60432 60433 Tested on x86_64-linux. 60434 604352023-03-24 Tom de Vries <tdevries@suse.de> 60436 60437 [gdb/testsuite] Fix gdb.cp/m-static.exp regression on Ubuntu 20.04 60438 In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I 60439 needed to change ".*/" into "(.*/)?" in: 60440 ... 60441 gdb_test "info variable everywhere" \ 60442 "File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;" 60443 ... 60444 60445 However, due to the fact that I got this output: 60446 ... 60447 (gdb) info variable everywhere^M 60448 All variables matching regular expression "everywhere":^M 60449 ^M 60450 File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 60451 8: const int gnu_obj_4::everywhere;^M 60452 ^M 60453 File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M 60454 8: const int gnu_obj_4::everywhere;^M 60455 ... 60456 I decided to make the matching somewhat stricter, to make sure that the two 60457 matched lines were subsequent. 60458 60459 The commit turned out to be more strict than intended, and caused a regression 60460 on Ubuntu 20.04, where the output was instead: 60461 ... 60462 (gdb) info variable everywhere^M 60463 All variables matching regular expression "everywhere":^M 60464 ^M 60465 File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 60466 8: const int gnu_obj_4::everywhere;^M 60467 ... 60468 60469 At that point I realized I'm looking at a bug (filed as PR symtab/30265), 60470 which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu 60471 20.04 for readnow, but not for native. 60472 60473 Before my commit, the test-case passed whether the bug manifested or not. 60474 60475 After my commit, the test-case only passed when the bug manifested. 60476 60477 Fix the test-case regression by reverting to the situation before the commit: 60478 pass whether the bug manifests or not. We could add an xfail for the PR, but 60479 I'm expecting a fix soon, so that doesn't look worth the effort. 60480 60481 Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with 60482 native and readnow. 60483 60484 Reported-By: Simon Marchi <simon.marchi@efficios.com> 60485 604862023-03-24 Tom de Vries <tdevries@suse.de> 60487 60488 [gdb/dap] Add logging of ignored lines 60489 This input sequence is accepted by DAP: 60490 ... 60491 {"seq": 4, "type": "request", "command": "configurationDone"}Content-Length: 84 60492 ... 60493 60494 This input sequence has the same effect: 60495 ... 60496 {"seq": 4, "type": "request", "command": "configurationDone"}ignorethis 60497 Content-Length: 84 60498 ... 60499 but the 'ignorethis' part is silently ignored. 60500 60501 Log the ignored bit, such that we have: 60502 ... 60503 READ: <<<{"seq": 4, "type": "request", "command": "configurationDone"}>>> 60504 WROTE: <<<{"request_seq": 4, "type": "response", "command": "configurationDone" 60505 , "success": true}>>> 60506 +++ run 60507 IGNORED: <<<b'ignorethis'>>> 60508 ... 60509 605102023-03-24 GDB Administrator <gdbadmin@sourceware.org> 60511 60512 Automatic date update in version.in 60513 605142023-03-23 Tom Tromey <tromey@adacore.com> 60515 60516 Fix minor grammar issue in python.texi 60517 I noticed a minor grammar problem in the 'GDB/MI Commands In Python' 60518 node of the manual. I'm checking in this patch to correct it. 60519 605202023-03-23 Frederic Cambus <fred@statdns.com> 60521 60522 Add support to readelf for the PT_OPENBSD_MUTABLE segment type. 60523 binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type. 60524 include * elf/common.h (PT_OPENBSD_MUTABLE): Define. 60525 605262023-03-23 Tom de Vries <tdevries@suse.de> 60527 60528 [gdb/testsuite] Use gdb_remote_download in allow_opencl_tests 60529 Simon reported that doing: 60530 ... 60531 $ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done 60532 ... 60533 could run into: 60534 ... 60535 ERROR: remote_download to target of \ 60536 /data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \ 60537 cp: cannot create regular file 'opencl_kernel.cl': File exists 60538 ... 60539 60540 Fix this by using gdb_remote_download (instead of plain remote_download) in 60541 allow_opencl_test, which takes care of: 60542 - downloading to a location which is safe for parallel testing, by 60543 using standard_output_file, and 60544 - cleaning up the downloaded file, meaning we can remove the corresponding 60545 "remote_file target delete ${clprogram}" lines in allow_opencl_test. 60546 60547 Tested on x86_64-linux. 60548 60549 Reported-by: Simon Marchi <simon.marchi@efficios.com> 60550 605512023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com> 60552 60553 bfd: aarch64: Optimize BTI stubs PR30076 60554 Don't insert a second stub if the target is already compatible with 60555 an indirect branch. 60556 605572023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com> 60558 60559 bfd: aarch64: Fix stubs that may break BTI PR30076 60560 Insert two stubs in a BTI enabled binary when fixing long calls: The 60561 first is near the call site and uses an indirect jump like before, 60562 but it targets the second stub that is near the call target site and 60563 uses a direct jump. 60564 60565 This is needed when a single stub breaks BTI compatibility. 60566 60567 The stub layout is kept fixed between sizing and building the stubs, 60568 so the location of the second stub is known at build time, this may 60569 introduce padding between stubs when those are relaxed. Stub layout 60570 with BTI disabled is unchanged. 60571 605722023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com> 60573 60574 bfd: aarch64: Refactor stub sizing code 60575 elfNN_aarch64_size_stubs has grown big, so factor out the call stub 60576 related code before adding new logic there. 60577 605782023-03-23 Andrew Burgess <aburgess@redhat.com> 60579 60580 gdb/riscv: add systemtap support 60581 This commit is initial support for SystemTap for RISC-V Linux. The 60582 following two tests exercise SystemTap functionality, and are showing 60583 many failures, which are all fixed by this commit: 60584 60585 gdb.cp/exceptprint.exp 60586 gdb.base/stap-probe.exp 60587 60588 One thing I wasn't sure about is if the SystemTap support should be 60589 Linux specific, or architecture specific. For aarch64, arm, ia64, and 60590 ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c 60591 file, while for amd64, i386, and s390 the implementation lives in 60592 ARCH-tdep.c. I have no idea which of these is the better choice -- or 60593 maybe both choices are correct in the right circumstances, and I'm 60594 just not aware of how to choose between them. 60595 60596 Anyway, for this patch I selected riscv-tdep.c (though clearly, moving 60597 the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a 60598 more appropriate location). 60599 60600 The stap-probe.exp file tests immediate, register, and register 60601 indirect operands, all of which appear to be working fine with this 60602 commit. The generic expression support doesn't appear to be 60603 architecture specific, so I'd expect that to work fine too. 60604 606052023-03-23 GDB Administrator <gdbadmin@sourceware.org> 60606 60607 Automatic date update in version.in 60608 606092023-03-22 Andrew Burgess <aburgess@redhat.com> 60610 60611 gdb: remove gdbarch_displaced_step_fixup_p 60612 The comment on the gdbarch_displaced_step_fixup gdbarch method 60613 indicates that this method is optional and that GDB will perform some 60614 default if this method is not supplied. As such we define a predicate 60615 gdbarch_displaced_step_fixup_p. 60616 60617 It may have been true at one point that the fixup method was optional, 60618 but it is no longer true. If this method is not defined and GDB tries 60619 to complete a displaced step, then GDB is going to crash. 60620 60621 Additionally the gdbarch_displaced_step_fixup_p predicate is not used 60622 anywhere in GDB. 60623 60624 In this commit I have removed the gdbarch_displaced_step_fixup_p 60625 predicate, and I have updated the validation check for the 60626 gdbarch_displaced_step_fixup method; if the 60627 gdbarch_displaced_step_copy_insn method is defined then the fixup 60628 method must also be defined. 60629 60630 I believe I've manually checked all the current places where 60631 gdbarch_displaced_step_copy_insn is defined and they all also define 60632 the fixup method, so this change should cause no problems for anyone. 60633 60634 There should be no user visible changes after this commit. 60635 60636 Approved-By: Pedro Alves <pedro@palves.net> 60637 606382023-03-22 Tom Tromey <tromey@adacore.com> 60639 60640 Remove unnecessary cast 60641 I found an upcast from template_symbol to symbol. This was necessary 60642 long ago, but since symbols use inheritance now, it is not. This 60643 patch removes it. Tested by rebuilding. 60644 606452023-03-22 Simon Marchi <simon.marchi@polymtl.ca> 60646 60647 gdb/testsuite: adjust test cases to previous "maintenance info line-table" change 60648 Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show 60649 relocated addresses again") changed the format of that command, but 60650 failed to adjust some test cases that relied on it. This patch fixes 60651 it. 60652 60653 The failures fixed are: 60654 60655 FAIL: gdb.base/maint.exp: maint info line-table w/o a file name 60656 FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated 60657 FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table 60658 60659 Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c 60660 606612023-03-22 Tom de Vries <tdevries@suse.de> 60662 60663 [gdb/testsuite] Fix gdb.cp/cp-relocate.exp for remote host 60664 Fix test-case gdb.cp/cp-relocate.exp for remote host using 60665 gdb_remote_download. 60666 60667 Tested on x86_64-linux. 60668 606692023-03-22 Tom de Vries <tdevries@suse.de> 60670 60671 [gdb/testsuite] Fix gdb.cp/annota{2,3}.exp for native-extended-gdbserver 60672 When running test-cases gdb.cp/annota{2,3}.exp with target board 60673 native-extended-gdbserver, we run into a few FAILs, due to the test-cases 60674 trying to match inferior output together with gdb output. 60675 60676 Fix this by ignoring the inferior output in this case. 60677 60678 Tested on x86_64-linux. 60679 606802023-03-22 Tom de Vries <tdevries@suse.de> 60681 60682 [gdb/testsuite] Fix gdb.cp/*.exp for remote host 60683 Fix a few test-cases in gdb.cp/*.exp for remote host using new proc 60684 include_file. 60685 60686 Tested on x86_64-linux. 60687 606882023-03-22 Simon Marchi <simon.marchi@efficios.com> 60689 60690 gdb: make "maintenance info line-table" show relocated addresses again 60691 Commit 1acc9dca423f ("Change linetables to be objfile-independent") 60692 changed "maintenance info line-table" to print unrelocated addresses 60693 instead of relocated. This breaks a few tests on systems where that 60694 matters. The ones I see are: 60695 60696 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... 60697 FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) 60698 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... 60699 FAIL: gdb.base/async.exp: stepi& 60700 FAIL: gdb.base/async.exp: nexti& 60701 FAIL: gdb.base/async.exp: finish& 60702 60703 These tests run "maintenance info line-table" to record the address of 60704 some lines, and then use these addresses in expected patterns. It 60705 therefore expects these addresses to match the runtime addresses, 60706 therefore the relocated addresses. 60707 60708 Add back the relocated addresses, next to the unrelocated addresses, 60709 like so: 60710 60711 INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END 60712 0 6 0x0000555555555119 0x0000000000001119 Y 60713 1 7 0x000055555555511d 0x000000000000111d Y 60714 2 8 0x0000555555555123 0x0000000000001123 Y 60715 3 END 0x0000555555555125 0x0000000000001125 Y 60716 60717 The unrelocated addresses can always be useful trying to map this 60718 information with a DWARF info dump. 60719 60720 Adjust the is_stmt_addresses proc in the testsuite to match the new 60721 output. 60722 60723 Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf 60724 607252023-03-22 Alan Modra <amodra@gmail.com> 60726 60727 coff_get_normalized_symtab bfd_release 60728 We can't free "internal" on errors, since bfd_coff_swap_sym_in may 60729 call bfd_alloc. For example, _bfd_XXi_swap_sym_in may even create new 60730 sections, which use bfd_alloc'd memory. If "internal" is freed, all 60731 more recently bfd_alloc'd memory is also freed. 60732 60733 * coffgen.c (coff_get_normalized_symtab): Don't bfd_release on 60734 error. 60735 607362023-03-22 GDB Administrator <gdbadmin@sourceware.org> 60737 60738 Automatic date update in version.in 60739 607402023-03-21 Alan Modra <amodra@gmail.com> 60741 60742 Remove unnecessary memsets in sframe-dump.c 60743 * sframe-dump.c (dump_sframe_func_with_fres): Don't memset temp. 60744 60745 Sanity check coff-sh and coff-mcore sym string offset 60746 * coff-mcore.c (coff_mcore_relocate_section): Sanity check sym 60747 string offset when setting up name for use by error messages. 60748 * coff-sh.c (sh_relocate_section): Likewise. 60749 607502023-03-21 Alan Modra <amodra@gmail.com> 60751 60752 PR17910 sym string offset check 60753 As far as I can see the only place that sets obj_coff_strings without 60754 setting obj_coff_strings_len is pe_ILF_build_a_bfd. Fix that and we 60755 can simplify the sym string offset check. This is just a tidy. 60756 pe_ILF_build_a_bfd doesn't create bad symbols and 60757 _bfd_coff_read_string_table will always result in non-zero 60758 obj_coff_strings_len when obj_coff_strings is non-NULL. 60759 60760 PR 17910 60761 * coffgen.c (_bfd_coff_internal_syment_name): Always sanity 60762 check sym string offset. 60763 * peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len. 60764 607652023-03-21 Alan Modra <amodra@gmail.com> 60766 60767 PE fake section for C_SECTION syms 60768 It's an odd thing to have objdump -x show a different section table 60769 to objdump -h, but that can happen if swapping in symbols leads to 60770 creating sections. Setting SEC_LINKER_CREATED stops the display of 60771 these sections, so that you get shown what is in the object file. 60772 60773 * peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on 60774 fake section created for C_SECTION syms. Don't zero asection 60775 fields that are already zero. 60776 607772023-03-21 Alan Modra <amodra@gmail.com> 60778 60779 XCOFF: use bfd_coff_close_and_cleanup 60780 Free memory on closing bfds. The COFF close_and_cleanup does more 60781 work than _bfd_generic_close_and_cleanup (defined as 60782 _bfd_archive_close_and_cleanup). 60783 60784 * coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as 60785 _bfd_coff_close_and_cleanup. 60786 * coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use 60787 _bfd_coff_close_and_cleanup. 60788 607892023-03-21 Alan Modra <amodra@gmail.com> 60790 60791 gas: expand_irp memory leaks 60792 * macro.c (expand_irp): Free memory on error return paths. 60793 607942023-03-21 H.J. Lu <hjl.tools@gmail.com> 60795 60796 x86: Check unbalanced braces in memory reference 60797 Check unbalanced braces in memory reference to avoid assembler crash 60798 caused by 60799 60800 commit e87fb6a6d0cdfc0e9c471b7825c20c238c2cf506 60801 Author: Jan Beulich <jbeulich@suse.com> 60802 Date: Wed Oct 5 09:16:24 2022 +0200 60803 60804 x86/gas: support quoted address scale factor in AT&T syntax 60805 60806 PR gas/30248 60807 * config/tc-i386.c (i386_att_operand): Check unbalanced braces 60808 in memory reference. 60809 * testsuite/gas/i386/i386.exp: Run pr30248. 60810 * testsuite/gas/i386/pr30248.d: New file. 60811 * testsuite/gas/i386/pr30248.err: Likewise. 60812 * testsuite/gas/i386/pr30248.s: Likewise. 60813 608142023-03-21 Carl Love <cel@us.ibm.com> 60815 60816 PowerPC: regression fix for reverse-finish command. 60817 The recent commit: 60818 60819 commit 2a8339b71f37f2d02f5b2194929c9d702ef27223 60820 Author: Carl Love <cel@us.ibm.com> 60821 Date: Thu Mar 9 16:10:18 2023 -0500 60822 60823 PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp 60824 60825 PPC64 multiple entry points, a normal entry point and an alternate entry 60826 point. The alternate entry point is to setup the Table of Contents (TOC) 60827 register before continuing at the normal entry point. When the TOC is 60828 already valid, the normal entry point is used, this is typically the case. 60829 The alternate entry point is typically referred to as the global entry 60830 point (GEP) in IBM. The normal entry point is typically referred to as 60831 the local entry point (LEP). 60832 ..... 60833 60834 Is causing regression failures on on PowerPC platforms. The regression 60835 failures are in tests: 60836 60837 gdb.reverse/finish-precsave.exp 60838 gdb.btrace/tailcall.exp 60839 gdb.mi/mi-reverse.exp 60840 gdb.btrace/step.exp 60841 gdb.reverse/until-precsave.exp 60842 gdb.reverse/finish-reverse.exp 60843 gdb.btrace/tailcall-only.exp 60844 60845 The issue is in gdb/infcmd.c, function finish_command. The value of the 60846 two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed 60847 to SAL.PC. However, SAL has just been declared. The value of SAL.PC is 60848 zero at this point. The intialization of ALT_ENTRY_POINT and ENTRY_POINT 60849 needs to be after the initialization of SAL. 60850 60851 This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT 60852 variables to fix the regression failures. 60853 60854 The patch has been tested on Power10 and on X86. 60855 608562023-03-21 Tom de Vries <tdevries@suse.de> 60857 60858 [gdb/testsuite] Check remote_exec results in board files 60859 Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is 60860 checked. 60861 60862 Tested on x86_64-linux. 60863 608642023-03-21 Tom de Vries <tdevries@suse.de> 60865 60866 [gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.exp 60867 In a recent commit I forgot to add a double quote before chmod here: 60868 ... 60869 remote_exec build $rsh_cmd chmod go-rx ." 60870 ... 60871 60872 Fix it by adding the missing double quote. 60873 608742023-03-21 Tom de Vries <tdevries@suse.de> 60875 60876 [gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.exp 60877 Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp, 60878 I don't see a relevant difference with the implementation of standard_file 60879 in dejagnu. 60880 60881 Simplify the board by removing ${board}_file. 60882 60883 Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp. 60884 608852023-03-21 Tom de Vries <tdevries@suse.de> 60886 60887 [gdb/testsuite] Use localhost instead of 127.0.0.1 for boards 60888 Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1". 60889 60890 Use instead "localhost". 60891 60892 Tested on x86_64-linux. 60893 608942023-03-21 Tom de Vries <tdevries@suse.de> 60895 60896 [gdb/testsuite] Fix gdb.xml/tdesc-regs.exp for remote host 60897 Fix test-case gdb.xml/tdesc-regs.exp for remote host by using appropriate 60898 filenames. 60899 60900 Tested on x86_64-linux. 60901 609022023-03-21 Tom de Vries <tdevries@suse.de> 60903 60904 [gdb/testsuite] Fix gdb.xml/tdesc-reload.exp for remote host 60905 Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate 60906 filenames. 60907 60908 Tested on x86_64-linux. 60909 609102023-03-21 Tom de Vries <tdevries@suse.de> 60911 60912 [gdb/testsuite] Set remotedir in local-remote-host-native.exp 60913 In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I 60914 removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs 60915 in test-case gdb.testsuite/board-sanity.exp. 60916 60917 Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for 60918 a host board no longer make compilation fail due to commit 80d6c79866f 60919 ("[gdb/testsuite] Handle remotedir in remote_upload"). 60920 60921 This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit 60922 3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards"). 60923 60924 Tested on x86_64-linux. 60925 609262023-03-21 Jiawei <jiawei@iscas.ac.cn> 60927 60928 RISC-V: Fix disassemble fetch fail return value. 60929 This bug reported in 60930 https://sourceware.org/bugzilla/show_bug.cgi?id=30184 60931 And discussed in 60932 https://sourceware.org/pipermail/binutils/2023-February/126213.html 60933 60934 We also checked the implementation of return value in arm and mips. 60935 So this patch changes the return value to -1, that can fix bugs and maintain 60936 consistency with other architectures. 60937 60938 opcodes/ChangeLog: 60939 60940 * riscv-dis.c (print_insn_riscv):Change the return value. 60941 609422023-03-21 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 60943 60944 Remove .c header files from rs6000-aix-nat.c file 60945 Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64 60946 definitions are moved to ppc-tdep.h we no longer need to import these .c files. 60947 609482023-03-21 GDB Administrator <gdbadmin@sourceware.org> 60949 60950 Automatic date update in version.in 60951 609522023-03-20 Tom Tromey <tom@tromey.com> 60953 60954 Remove some unnecessary includes from *-exp.y 60955 I noticed a weird comment in one of the .y files, and then ended up 60956 removing some unnecessary #includes from these files. 60957 60958 Tested by rebuilding. 60959 60960 Approved-By: Simon Marchi <simon.marchi@efficios.com> 60961 609622023-03-20 Tom Tromey <tromey@adacore.com> 60963 60964 Remove mi_version function 60965 The mi_version function is unused, and I think it's better overall if 60966 it is never used. This patch removes it. Tested by rebuilding. 60967 60968 Approved-By: Simon Marchi <simon.marchi@efficios.com> 60969 609702023-03-20 Tom Tromey <tromey@adacore.com> 60971 60972 Update python-helper.exp for type allocation changes 60973 The type allocation changes introduced a failure in python-helper.exp 60974 that I did not notice. The bug is that, with these patches, 60975 arch-allocated integer types have a TYPE_SPECIFIC_INT object attached. 60976 This patch updates the test to allow this. 60977 60978 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30253 60979 609802023-03-20 Tom de Vries <tdevries@suse.de> 60981 60982 [gdb/testsuite] Handle remotedir in remote_upload 60983 Dejagnu's remotedir implementation has support in remote_exec and 60984 remote_download, but not remote_upload. 60985 60986 Consider the following scenario: 60987 - downloading an executable to target, 60988 - running it, 60989 - uploading a file produced by the executable 60990 while assuming remote target user remote-target with homedir 60991 /home/remote-target and remotedir set to /home/remote-target/tmp. 60992 60993 Concretely, it looks like this: 60994 ... 60995 # binfile == "$outputs/gdb.abc/a.out" 60996 set target_binfile [remote_download target $binfile] 60997 # target_binfile == "/home/remote-target/tmp/a.out" 60998 remote_exec target $target_binfile 60999 # Running $target_binfile produced /home/remote-target/tmp/result.txt. 61000 set result [remote_upload target /home/remote-target/tmp/result.txt \ 61001 $outputs/gdb.abc/result.txt] 61002 # result == $outputs/gdb.abc/result.txt. 61003 ... 61004 61005 Add a remote_upload implementation that also handles remotedir in lib/gdb.exp, 61006 overriding dejagnu's remote_upload, such that we can simplify the 61007 remote_upload call to: 61008 ... 61009 set result [remote_upload target result.txt $outputs/gdb.abc/result.txt] 61010 ... 61011 61012 Tested on x86_64-linux. 61013 61014 PR testsuite/30250 61015 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250 61016 610172023-03-20 Andrew Burgess <aburgess@redhat.com> 61018 61019 gdb: fix crash during command completion 61020 In some cases GDB will fail when attempting to complete a command that 61021 involves a rust symbol, the failure can manifest as a crash. 61022 61023 The problem is caused by the completion_match_for_lcd object being 61024 left containing invalid data during calls to cp_symbol_name_matches_1. 61025 61026 The first question to address is why we are calling a C++ support 61027 function when handling a rust symbol. That's due to GDB's auto 61028 language detection for msymbols, in some cases GDB can't tell if a 61029 symbol is a rust symbol, or a C++ symbol. 61030 61031 The test application contains symbols for functions which are 61032 statically linked in from various rust support libraries. There's no 61033 DWARF for these symbols, so all GDB has is the msymbols built from the 61034 ELF symbol table. 61035 61036 Here's the problematic symbol that leads to our crash: 61037 61038 mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE 61039 demangled: core::str::<impl str>::parse 61040 61041 As an msymbol this is initially created with language auto, then GDB 61042 eventually calls symbol_find_demangled_name, which loops over all 61043 languages calling language_defn::sniff_from_mangled_name, the first 61044 language that can demangle the symbol gets assigned as the language 61045 for that symbol. 61046 61047 Unfortunately, there's overlap in the mangled symbol names, 61048 some (legacy) rust symbols can be demangled as both rust and C++, see 61049 cplus_demangle in libiberty/cplus-dem.c where this is mentioned. 61050 61051 And so, because we check the C++ language before we check for rust, 61052 then the msymbol is (incorrectly) given the C++ language. 61053 61054 Now it's true that is some cases we might be able to figure out that a 61055 demangled symbol is not actually a valid C++ symbol, for example, in 61056 our case, the construct '::<impl str>::' is not, I believe, valid in a 61057 C++ symbol, we could look for ':<' and '>:' and refuse to accept this 61058 as a C++ symbol. 61059 61060 However, I'm not sure it is always possible to tell that a demangled 61061 symbol is rust or C++, so, I think, we have to accept that some times 61062 we will get this language detection wrong. 61063 61064 If we accept that we can't fix the symbol language detection 100% of 61065 the time, then we should make sure that GDB doesn't crash when it gets 61066 the language wrong, that is what this commit addresses. 61067 61068 In our test case the user tries to complete a symbol name like this: 61069 61070 (gdb) complete break pars 61071 61072 This results in GDB trying to find all symbols that match 'pars', 61073 eventually we consider our problematic symbol, and we end up with a 61074 call stack that looks like this: 61075 61076 #0 0x0000000000f3c6bd in strncmp_iw_with_mode 61077 #1 0x0000000000706d8d in cp_symbol_name_matches_1 61078 #2 0x0000000000706fa4 in cp_symbol_name_matches 61079 #3 0x0000000000df3c45 in compare_symbol_name 61080 #4 0x0000000000df3c91 in completion_list_add_name 61081 #5 0x0000000000df3f1d in completion_list_add_msymbol 61082 #6 0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on 61083 #7 0x0000000000658c08 in language_defn::collect_symbol_completion_matches 61084 #8 0x0000000000df54c9 in collect_symbol_completion_matches 61085 #9 0x00000000009d98fb in linespec_complete_function 61086 #10 0x00000000009d99f0 in complete_linespec_component 61087 #11 0x00000000009da200 in linespec_complete 61088 #12 0x00000000006e4132 in complete_address_and_linespec_locations 61089 #13 0x00000000006e4ac3 in location_completer 61090 61091 In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly 61092 tries to match the demangled problematic symbol name against the user 61093 supplied text ('pars'). Each time around the loop another component 61094 of the symbol name is stripped off, thus, we check 'pars' against 61095 these options: 61096 61097 core::str::<impl str>::parse 61098 str::<impl str>::parse 61099 <impl str>::parse 61100 parse 61101 61102 As soon as we get a match the cp_symbol_name_matches_1 exits its loop 61103 and returns. In our case, when we're looking for 'pars', the match 61104 occurs on the last iteration of the loop, when we are comparing to 61105 'parse'. 61106 61107 Now the problem here is that cp_symbol_name_matches_1 uses the 61108 strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for 61109 skipping over template parameters. This allows GDB to match the 61110 symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'. 61111 Inside strncmp_iw_with_mode GDB will record any template arguments 61112 that it has skipped over inside the completion_match_for_lcd object 61113 that is passed in as an argument. 61114 61115 And so, when GDB tries to match against '<impl str>::parse', the first 61116 thing it sees is '<impl str>', GDB assumes this is a template argument 61117 and records this as a skipped region within the 61118 completion_match_for_lcd object. After '<impl str>' GDB sees a ':' 61119 character, which doesn't match with the 'pars' the user supplied, so 61120 strncmp_iw_with_mode returns a value indicating a non-match. GDB then 61121 removes the '<impl str>' component from the symbol name and tries 61122 again, this time comparing to 'parse', which does match. 61123 61124 Having found a match, then in cp_symbol_name_matches_1 we record the 61125 match string, and the full symbol name within the 61126 completion_match_result object, and return. 61127 61128 The problem here is that the skipped region, the '<impl str>' that we 61129 recorded in the penultimate loop iteration was never discarded, its 61130 still there in our returned result. 61131 61132 If we look at what the pointers held in the completion_match_result 61133 that cp_symbol_name_matches_1 returns, this is what we see: 61134 61135 core::str::<impl str>::parse 61136 | \________/ | 61137 | | '--- completion match string 61138 | '---skip range 61139 '--- full symbol name 61140 61141 When GDB calls completion_match_for_lcd::finish, GDB tries to create a 61142 string using the completion match string (parse), but excluding the 61143 skip range, as the stored skip range is before the start of the 61144 completion match string, then GDB tries to do some weird string 61145 creation, which will cause GDB to crash. 61146 61147 The reason we don't often see this problem in C++ is that for C++ 61148 symbols there is always some non-template text before the template 61149 argument. This non-template text means GDB is likely to either match 61150 the symbol, or reject the symbol without storing a skip range. 61151 61152 However, notice, I did say, we don't often see this problem. Once I 61153 understood the issue, I was able to reproduce the crash using a pure 61154 C++ example: 61155 61156 template<typename S> 61157 struct foo 61158 { 61159 template<typename T> 61160 foo (int p1, T a) 61161 { 61162 s = 0; 61163 } 61164 61165 S s; 61166 }; 61167 61168 int 61169 main () 61170 { 61171 foo<int> obj (2.3, 0); 61172 return 0; 61173 } 61174 61175 Then in GDB: 61176 61177 (gdb) complete break foo(int 61178 61179 The problem here is that the C++ symbol for the constructor looks like 61180 this: 61181 61182 foo<int>::foo<double>(int, double) 61183 61184 When GDB enters cp_symbol_name_matches_1 the symbols it examines are: 61185 61186 foo<int>::foo<double>(int, double) 61187 foo<double>(int, double) 61188 61189 The first iteration of the loop will match the 'foo', then add the 61190 '<int>' template argument will be added as a skip range. When GDB 61191 find the ':' after the '<int>' the first iteration of the loop fails 61192 to match, GDB removes the 'foo<int>::' component, and starts the 61193 second iteration of the loop. 61194 61195 Again, GDB matches the 'foo', and now adds '<double>' as a skip 61196 region. After that the '(int' successfully matches, and so the second 61197 iteration of the loop succeeds, but, once again we left the '<int>' in 61198 place as a skip region, even though this occurs before the start of 61199 our match string, and this will cause GDB to crash. 61200 61201 This problem was reported to the mailing list, and a solution 61202 discussed in this thread: 61203 61204 https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html 61205 61206 The solution proposed here is similar to one proposed by the original 61207 bug reported, but implemented in a different location within GDB. 61208 Instead of placing the fix in strncmp_iw_with_mode, I place the fix in 61209 cp_symbol_name_matches_1. I believe this is a better location as it 61210 is this function that implements the loop, and it is this loop, which 61211 repeatedly calls strncmp_iw_with_mode, that should be resetting the 61212 result object state (I believe). 61213 61214 What I have done is add an assert to strncmp_iw_with_mode that the 61215 incoming result object is empty. 61216 61217 I've also added some other asserts in related code, in 61218 completion_match_for_lcd::mark_ignored_range, I make some basic 61219 assertions about the incoming range pointers, and in 61220 completion_match_for_lcd::finish I also make some assertions about how 61221 the skip ranges relate to the match pointer. 61222 61223 There's two new tests. The original rust example that was used in the 61224 initial bug report, and a C++ test. The rust example depends on which 61225 symbols are pulled in from the rust libraries, so it is possible that, 61226 at some future date, the problematic symbol will disappear from this 61227 test program. The C++ test should be more reliable, as this only 61228 depends on symbols from within the C++ source code. 61229 61230 Since I originally posted this patch to the mailing list, the 61231 following patch has been merged: 61232 61233 commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb 61234 Date: Sun Mar 19 09:13:10 2023 -0600 61235 61236 Use rust_demangle to fix a crash 61237 61238 This solves the problem of a rust symbol ending up in the C++ specific 61239 code by changing the order languages are sorted. However, this new 61240 commit doesn't address the issue in the C++ code which was fixed with 61241 this commit. 61242 61243 Given that the C++ issue is real, and has a reproducer, I'm still 61244 going to merge this fix. I've left the discussion of rust in this 61245 commit message as I originally wrote it, but it should be read within 61246 the context of GDB prior to commit 6e7eef72164c00d6a5a7. 61247 61248 Co-Authored-By: Zheng Zhan <zzlossdev@163.com> 61249 612502023-03-20 Jan Beulich <jbeulich@suse.com> 61251 61252 x86: drop identifier_chars[] 61253 It tries to resemble what's underlying is_part_of_name(), but doesn't 61254 quite achieve that: '$' for example is unconditionally marked as part of 61255 symbol names, but was included as identifier char for Intel syntax only. 61256 Note that i386_att_operand() checks for the immediate prefix first, so 61257 the wider coverage by starts_memory_operand() is has no real effect 61258 there, but it does matter for something like 61259 61260 mov %fs:$dollar, %eax 61261 61262 which previously wasn't accepted (but which clearly is a memory 61263 reference - there's no point in forcing people to parenthesize the 61264 symbol name). Similarly including '%' as an identfier for Intel syntax 61265 had no real significance to the rest of the assembler. If '%' was to be 61266 valid in (unquoted) symbol names, LEX_PCT would need to be defined. 61267 61268 Note further that this also addresses the latent issue of a sub-target 61269 defining LEX_AT or LEX_QM to zero: That would make '@' and/or '?' no 61270 valid part of symbol names, but would have included them in what 61271 is_identifier_char() considers a valid part of a name. (There's a minor 61272 related issue which is actually being eliminated: te-interix.h allows 61273 '@' only in the middle of symbol names, yet starts_memory_operand() 61274 specifically looks at the first character of [possibly] a symbol name.) 61275 61276 In parse_real_register() there's no point also checking is_name_ender() 61277 as at this point no character is marked solely LEX_END_NAME by any sub- 61278 target. Checking is_name_beginner() is also pointless as the hash lookup 61279 will fail anyway for a zero-length name. 61280 61281 While touching the check in parse_real_register() also drop the 61282 "allow_naked_reg" part of the condition: This has only led to 61283 inconsistent error messages. 61284 612852023-03-20 Jan Beulich <jbeulich@suse.com> 61286 61287 x86/AT&T: restrict recognition of the "absolute branch" prefix character 61288 While in principle merely rejecting this for .insn would be sufficient 61289 for the purposes there, be more generic and reject it for anything that 61290 isn't going to be a branch: All elements of same-mnemonic template 61291 groups either are branches, or are not, and the few cases possibly 61292 requiring a 2nd parsing pass aren't affected either. This then also 61293 improves diagnostics for misuses like 61294 61295 inc *%eax 61296 incl %fs:*(%eax) 61297 add *$1, %eax 61298 612992023-03-20 Jan Beulich <jbeulich@suse.com> 61300 61301 x86: drop "shimm" special case template expansions 61302 With VexVVVV only being boolean, the SSE shift-by-immediate instructions 61303 don't need special casing anymore for SSE2AVX handling. Simplify the two 61304 respective templates. (No change to generated tables.) 61305 613062023-03-20 Jan Beulich <jbeulich@suse.com> 61307 61308 x86: VexVVVV is now merely a boolean 61309 With the SDM long having dropped the NDS/NDD/DDS concept of identifying 61310 encoding variants, we can finally do away with this concept as well. Of 61311 the few consumers of the attribute, only an assertion was still checking 61312 for a particular value, which we don't really need to retain. 61313 61314 When touching lines anyway, modernize other aspects as well. This often 61315 improves similarity to adjacent lines. 61316 613172023-03-20 Jan Beulich <jbeulich@suse.com> 61318 61319 x86: re-work build_modrm_byte()'s register assignment 61320 The function has accumulated a number of special cases for no real 61321 reason. Some were necessary because insn attributes (SwapSources in 61322 particular) weren't suitably utilized instead. Note that the addition of 61323 SwapSources actually increases consistency among the templates: Like 61324 others which already have the attribute, these are all insns where the 61325 VEX.VVVV-encoded register comes first (or last when looking at the SDM). 61326 61327 Note that the vexvvvv attribute now has merely boolean meaning anymore, 61328 in line with the SDM long having dropped the NDS/NDD/DDS concept of 61329 identifying encoding variants. The fallout will be taken care of 61330 subsequently, though, to not further clutter the change here. 61331 61332 As to the TILEZERO special case: If more instructions like this 61333 appeared, a new attribute would likely be the way to go. But as long as 61334 it's only a single insn, going from the mnemonic is cheaper. 61335 613362023-03-20 Cupertino Miranda <cupertino.miranda@oracle.com> 61337 61338 Changed ld and gas BPF tests 61339 Recent BPF patch removed and renamed the list of relocations based on 61340 the limitations of BPF instruction set. 61341 This patch is a correction to the tests. 61342 61343 Reloc howto access broken for BPF 61344 Forgot to change the logic to access the reloc howto from 61345 bpf_elf_relocate_section. 61346 Problem was introduced in previous BPF commit. 61347 613482023-03-20 Tom Tromey <tom@tromey.com> 61349 61350 Use rust_demangle to fix a crash 61351 PR rust/30211 points out a crash caused by a particular completion. 61352 This turns out to happen because a Rust minsym winds up in a 61353 C++-specific path in strncmp_iw_with_mode, which ultimately causes the 61354 completer to pass invalid arguments to string::append. 61355 61356 This patch fixes the bug by reordering the language constants so that 61357 Rust comes before C++, and then using rust_demangle. This ensures 61358 that minsyms are correctly marked as "Rust", avoiding this code and 61359 thus the crash. 61360 61361 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20367 61362 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30211 61363 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 61364 613652023-03-20 Tom Tromey <tromey@adacore.com> 61366 61367 Make ui_out::do_progress_end 'private' 61368 I noticed that ui_out::do_progress_end is public, just to support one 61369 use in debuginfod-support.c. This patch makes it private, updates 61370 progress_info to call it from its destructor, and finally changes 61371 debuginfod-support.c to follow. 61372 613732023-03-20 Andrew Burgess <aburgess@redhat.com> 61374 61375 gdb: don't use the global thread-id in the saved breakpoints file 61376 I noticed that breakpoint::print_recreate_thread was printing the 61377 global thread-id. This function is used to implement the 'save 61378 breakpoints' command, and should be writing out suitable CLI commands 61379 for recreating the current breakpoints. The CLI does not use global 61380 thread-ids, but instead uses the inferior specific thread-ids, 61381 e.g. "2.1". 61382 61383 After some discussion on the mailing list it was suggested that the 61384 most consistent solution would be for the saved breakpoints file to 61385 always contain the inferior-qualified thread-id, so the file would 61386 include "thread 1.1" instead of just "thread 1", even when there is 61387 only a single inferior. 61388 61389 So, this commit adds print_full_thread_id, which is just like the 61390 existing print_thread_id, only it always prints the inferior-qualified 61391 thread-id. 61392 61393 I then update the existing print_thread_id to make use of this new 61394 function, and finally, I update breakpoint::print_recreate_thread to 61395 also use this new function. 61396 61397 There's a multi-inferior test that confirms the saved breakpoints file 61398 correctly includes the fully-qualified thread-id, and I've also 61399 updated the single inferior test gdb.base/save-bp.exp to have it 61400 validate that the saved breakpoints file includes the 61401 inferior-qualified thread-id, even for this single inferior case. 61402 614032023-03-20 Alan Modra <amodra@gmail.com> 61404 61405 Revert "segfault at i386-dis.c:9815" 61406 This reverts commit 92d450c79ad321e42f9a77692b5db10d0f7b9344. 61407 61408 Accessing these local var structs using a volatile qualified pointer 61409 may indeed read the object, but I don't think changed values are 61410 guaranteed to be written back to the object unless the actual object 61411 is declared volatile. That would probably slow down i386 disassembly 61412 unacceptably. 61413 614142023-03-20 Alan Modra <amodra@gmail.com> 61415 61416 libctf: unused variable 61417 * ctf-archive.c (arc_mmap_writeout): Delete unused variable. 61418 614192023-03-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 61420 61421 gprofng: Use prototype to call libc functions 61422 libcollector may not link against libC. 61423 We use dlsym() to get a function from libc. 61424 In some files, pointers to these functions do not have prototypes. 61425 I also moved the shared definitions to libcollector/collect.h. 61426 61427 gprofng/ChangeLog 61428 2023-03-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 61429 61430 libcollector/collector.c: Add prototypes. 61431 libcollector/dispatcher.c: Likewise. 61432 libcollector/heaptrace.c: Likewise. 61433 libcollector/iotrace.c: Likewise. 61434 libcollector/linetrace.c: Likewise. 61435 libcollector/mmaptrace.c: Likewise. 61436 libcollector/synctrace.c: Likewise. 61437 libcollector/collector.h: Add CALL_REAL(), NULL_PTR(), and DBG_LT. 61438 614392023-03-20 GDB Administrator <gdbadmin@sourceware.org> 61440 61441 Automatic date update in version.in 61442 614432023-03-19 Tom Tromey <tom@tromey.com> 61444 61445 Don't declare psymbol_functions::fill_psymbol_map 61446 psymbol_functions::fill_psymbol_map was removed, but I forgot to 61447 remove the declaration. This patch removes it. Tested by rebuilding. 61448 614492023-03-19 Alan Modra <amodra@gmail.com> 61450 61451 segfault at i386-dis.c:9815 61452 * i386-dis.c (print_insn): Access "ins" and "priv" via volatile 61453 pointers after second sigsetjmp return. 61454 614552023-03-19 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 61456 61457 Enable vector register visibility in core file for AIX binutils 61458 This patch will enable vector register visibility when AIX FOLKS do 61459 core file analysis. 61460 614612023-03-19 Alan Modra <amodra@gmail.com> 61462 61463 Regen ld/po/BLD-POTFILES.in 61464 614652023-03-19 Alan Modra <amodra@gmail.com> 61466 61467 XCOFF archive sanity check 61468 XCOFF archive elements are in a linked list. Add a little more sanity 61469 checking. This of course doesn't stop the fuzzers finding a way to 61470 make a loop, but this check is cheap. 61471 61472 * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Sanity 61473 check that next element isn't pointing back to the header. 61474 614752023-03-19 Alan Modra <amodra@gmail.com> 61476 61477 rewrite_elf_program_header and want_p_paddr_set_to_zero 61478 Layout in rewrite_elf_program_header is really done by lma, even if 61479 program headers are going to have their p_paddr forced to zero. Thus 61480 when not matching against an existing segment, don't try to use a 61481 "vma" from elf_segment_map. 61482 61483 * elf.c (is_contained_by): Replace "bed" param with "use_vaddr". 61484 (IS_SECTION_IN_INPUT_SEGMENT): Adjust is_contained_by call. 61485 (rewrite_elf_program_header): Always match against lma in 61486 calls to is_contained_by using new maps. 61487 614882023-03-19 Alan Modra <amodra@gmail.com> 61489 61490 Another sanity check for read_section_stabs_debugging_info 61491 * rddbg.c (read_section_stabs_debugging_info): Ignore invalid 61492 stab sections with size less than 12 bytes. 61493 61494 ctf segfaults 61495 PR 30228 61496 PR 30229 61497 * ctf-open.c (ctf_bufopen_internal): Check for NULL cts_data. 61498 * ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Likewise. 61499 615002023-03-19 GDB Administrator <gdbadmin@sourceware.org> 61501 61502 Automatic date update in version.in 61503 615042023-03-18 Tom Tromey <tom@tromey.com> 61505 61506 Remove objfile_type 61507 This removes objfile_type, in favor of always using the per-arch 61508 builtins. 61509 61510 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61511 615122023-03-18 Tom Tromey <tom@tromey.com> 61513 61514 Add some types to struct builtin_type 61515 This adds some types to struct builtin_type, ensuring it contains all 61516 the types currently used by objfile_type. 61517 61518 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61519 615202023-03-18 Tom Tromey <tom@tromey.com> 61521 61522 Rename objfile_type to builtin_type 61523 This renames objfile_type to be an overload of builtin_type, in 61524 preparation for their unification. 61525 61526 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61527 615282023-03-18 Tom Tromey <tom@tromey.com> 61529 61530 Use builtin type when appropriate 61531 There are a few spots that check whether a type is objfile-owned, and 61532 then choose either the objfile- or arch-specific builtin type. I 61533 don't think there is a need to do this any more (if there ever was), 61534 because it is ok for an objfile-allocated type to refer to an 61535 arch-allocated type. 61536 61537 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61538 615392023-03-18 Tom Tromey <tom@tromey.com> 61540 61541 Use type allocator for set types 61542 This changes the set type creation function to accept a type 61543 allocator, and updates all the callers. Note that symbol readers 61544 should generally allocate on the relevant objfile, regardless of the 61545 underlying type of the set, which is what this patch implements. 61546 61547 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61548 615492023-03-18 Tom Tromey <tom@tromey.com> 61550 61551 Use type allocator for array types 61552 This changes the array type creation functions to accept a type 61553 allocator, and updates all the callers. Note that symbol readers 61554 should generally allocate on the relevant objfile, regardless of the 61555 placement of the index type of the array, which is what this patch 61556 implements. 61557 61558 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61559 615602023-03-18 Tom Tromey <tom@tromey.com> 61561 61562 Use type allocator for range types 61563 This changes the range type creation functions to accept a type 61564 allocator, and updates all the callers. Note that symbol readers 61565 should generally allocate on the relevant objfile, regardless of the 61566 underlying type of the range, which is what this patch implements. 61567 61568 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61569 615702023-03-18 Tom Tromey <tom@tromey.com> 61571 61572 Unify arch_pointer_type and init_pointer_type 61573 This unifies arch_pointer_type and init_pointer_type by using a type 61574 allocator. 61575 61576 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61577 615782023-03-18 Tom Tromey <tom@tromey.com> 61579 61580 Unify arch_decfloat_type and init_decfloat_type 61581 This unifies arch_decfloat_type and init_decfloat_type by using a type 61582 allocator. 61583 61584 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61585 615862023-03-18 Tom Tromey <tom@tromey.com> 61587 61588 Unify arch_float_type and init_float_type 61589 This unifies arch_float_type and init_float_type by using a type 61590 allocator. 61591 61592 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61593 615942023-03-18 Tom Tromey <tom@tromey.com> 61595 61596 Unify arch_boolean_type and init_boolean_type 61597 This unifies arch_boolean_type and init_boolean_type by using a type 61598 allocator. 61599 61600 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61601 616022023-03-18 Tom Tromey <tom@tromey.com> 61603 61604 Unify arch_character_type and init_character_type 61605 This unifies arch_character_type and init_character_type by using a 61606 type allocator. 61607 61608 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61609 616102023-03-18 Tom Tromey <tom@tromey.com> 61611 61612 Unify arch_integer_type and init_integer_type 61613 This unifies arch_integer_type and init_integer_type by using a type 61614 allocator. 61615 61616 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61617 616182023-03-18 Tom Tromey <tom@tromey.com> 61619 61620 Remove init_type 61621 This removes init_type, replacing all uses with the new type 61622 allocator. 61623 61624 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61625 616262023-03-18 Tom Tromey <tom@tromey.com> 61627 61628 Remove arch_type 61629 This removes arch_type, replacing all uses with the new type 61630 allocator. 61631 61632 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61633 616342023-03-18 Tom Tromey <tom@tromey.com> 61635 61636 Reuse existing builtin types 61637 This changes a few spots to reuse the existing builting "void" type, 61638 rather than construct a new one. 61639 61640 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61641 616422023-03-18 Tom Tromey <tom@tromey.com> 61643 61644 Remove alloc_type 61645 This removes alloc_type, replacing all uses with the new type 61646 allocator. 61647 61648 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61649 616502023-03-18 Tom Tromey <tom@tromey.com> 61651 61652 Remove alloc_type_copy 61653 This removes alloc_type_copy, replacing all uses with the new type 61654 allocator. 61655 61656 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61657 616582023-03-18 Tom Tromey <tom@tromey.com> 61659 61660 Remove alloc_type_arch 61661 This removes alloc_type_arch, replacing all uses with the new type 61662 allocator. 61663 61664 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61665 616662023-03-18 Tom Tromey <tom@tromey.com> 61667 61668 Introduce type_allocator 61669 This introduces a new type_allocator class. This class will be used 61670 to abstract out the placement of new types, so that type-creation code 61671 can be simplified and shared. 61672 61673 Reviewed-By: Simon Marchi <simon.marchi@efficios.com> 61674 616752023-03-18 Tom de Vries <tdevries@suse.de> 61676 61677 [gdb/testsuite] Handle unbuffer_output.c for remote host 61678 Handle $srcdir/lib/unbuffer_output.c using lappend_include_file. 61679 61680 Tested on x86_64-linux. 61681 616822023-03-18 Tom de Vries <tdevries@suse.de> 61683 61684 [gdb/testsuite] Handle my-syscalls.h for remote host 61685 Handle $srcdir/lib/my-syscalls.h using lappend_include_dir. 61686 61687 Tested on x86_64-linux. 61688 616892023-03-18 Tom de Vries <tdevries@suse.de> 61690 61691 [gdb/testsuite] Handle attributes.h for remote host 61692 Handle $srcdir/lib/attributes.h using lappend_include_dir. 61693 61694 Tested on x86_64-linux. 61695 616962023-03-18 GDB Administrator <gdbadmin@sourceware.org> 61697 61698 Automatic date update in version.in 61699 617002023-03-17 Tom Tromey <tom@tromey.com> 61701 61702 Fix line table regression 61703 Simon pointed out a line table regression, and after a couple of false 61704 starts, I was able to reproduce it by hand using his instructions. 61705 61706 The bug is that most of the code in do_mixed_source_and_assembly uses 61707 unrelocated addresses, but one spot does: 61708 61709 pc = low; 61710 61711 ... after the text offset has been removed. 61712 61713 This patch fixes the problem by introducing a new type to represent 61714 unrelocated addresses in the line table. This prevents this sort of 61715 bug to some degree (it's still possible to manipulate a CORE_ADDR in a 61716 bad way, this is unavoidable). 61717 61718 However, this did let the compiler flag a few spots in that function, 61719 and now it's not possible to compare an unrelocated address from a 61720 line table with an ordinary CORE_ADDR. 61721 61722 Regression tested on x86-64 Fedora 36, though note this setup never 61723 reproduced the bug in the first place. I also tested it by hand on 61724 the disasm-optim test program. 61725 617262023-03-17 Frederic Cambus <fred@statdns.com> 61727 61728 Update the NetBSD system call table to add eventfd(2) and timerfd(2). 61729 Generated from sys/sys/syscall.h revision 1.321. 61730 617312023-03-17 Simon Marchi <simon.marchi@polymtl.ca> 61732 61733 gdb: introduce bp_loc_tracepoint 61734 Since commit cb1e4e32c2d9 ("catch catch/throw/rethrow", breakpoint -> 61735 catchpoint), this simple tracing scenario does not work: 61736 61737 $ gdb/gdb -nx -q --data-directory=gdb/data-directory ./test 61738 Reading symbols from ./test... 61739 (gdb) tar rem :1234 61740 Remote debugging using :1234 61741 Reading symbols from /lib64/ld-linux-x86-64.so.2... 61742 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 61743 0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2 61744 (gdb) trace do_something 61745 Tracepoint 1 at 0x555555555144: file test.c, line 5. 61746 (gdb) tstart 61747 (gdb) continue 61748 Continuing. 61749 Target returns error code '01'. 61750 61751 The root cause is that the bp_location::nserted flag does not transfer 61752 anymore from an old bp_location to the new matching one. When a shared 61753 library gets loaded, GDB computes new breakpoint locations for each 61754 breakpoint in update_breakpoint_locations. The new locations are in the 61755 breakpoint::loc chain, while the old locations are still in the 61756 bp_locations global vector. Later, update_global_location_list is 61757 called. It tries to map old locations to new locations, and if 61758 necessary transfer some properties, like the inserted flag. 61759 61760 Since commit cb1e4e32c2d9, the inserted flag isn't transferred for 61761 locations of tracepoints. This is because bl_address_is_meaningful used 61762 to be implemented like this: 61763 61764 static int 61765 breakpoint_address_is_meaningful (struct breakpoint *bpt) 61766 { 61767 enum bptype type = bpt->type; 61768 61769 return (type != bp_watchpoint && type != bp_catchpoint); 61770 } 61771 61772 and was changed to this: 61773 61774 static bool 61775 bl_address_is_meaningful (bp_location *loc) 61776 { 61777 return loc->loc_type != bp_loc_other; 61778 } 61779 61780 Because locations for tracepoints have the bp_loc_other type, 61781 bl_address_is_meaningful started to return false for them, where it 61782 returned true before. This made update_global_location_list skip the 61783 part where it calls swap_insertion. 61784 61785 I think this can be solved by introduced a new bp_loc_tracepoint 61786 bp_loc_type. 61787 61788 I don't know if it's accurate, but my understanding is that bp_loc_type 61789 describes roughly "how do we ask the target to insert that location". 61790 bp_loc_software_breakpoint are inserted using 61791 target_ops::insert_breakpoint_location. bp_loc_hardware_breakpoint are 61792 inserted using target_ops::insert_hw_breakpoint. 61793 bp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted 61794 using target_ops::insert_watchpoint. For all these, the address is 61795 meaningful, as we ask the target to insert the point at a specific 61796 address. bp_loc_other is a catch-all for "the rest", in practice for 61797 catchpoints that don't have a specific address (hence why 61798 bl_address_is_meaningful returns false for them). For instance, 61799 inserting a signal catchpoint is done by asking the target to report 61800 that specific signal. GDB doesn't associate an address to that. 61801 61802 But tracepoints do have a meaningful address to thems, so they can't be 61803 bp_loc_other, with that logic. They also can't be 61804 bp_loc_software_breakpoint, because we don't want GDB to insert 61805 breakpoints for them (even though they might be implemented using 61806 software breakpoints by the remote side). So, the new bp_loc_tracepoint 61807 type describes that the way to insert these locations is with 61808 target_ops::download_tracepoint. It makes bl_address_is_meaningful 61809 return true for them. And they'll be ignored by insert_bp_location and 61810 GDB won't try to insert a memory breakpoint for them. 61811 61812 With this, I see a few instances of 'Target returns error code: 01' 61813 disappearing from gdb.log, and the results of gdb.trace/*.exp improve a 61814 little bit: 61815 61816 -# of expected passes 3765 61817 +# of expected passes 3781 61818 -# of unexpected failures 518 61819 +# of unexpected failures 498 61820 61821 Things remain quite broken in that area though. 61822 61823 Change-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3 61824 618252023-03-17 Carl Love <cel@us.ibm.com> 61826 61827 PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp 61828 PPC64 multiple entry points, a normal entry point and an alternate entry 61829 point. The alternate entry point is to setup the Table of Contents (TOC) 61830 register before continuing at the normal entry point. When the TOC is 61831 already valid, the normal entry point is used, this is typically the case. 61832 The alternate entry point is typically referred to as the global entry 61833 point (GEP) in IBM. The normal entry point is typically referred to as 61834 the local entry point (LEP). 61835 61836 When GDB is executing the finish command in reverse, the function 61837 finish_backward currently sets the break point at the alternate entry point. 61838 This issue is if the function, when executing in the forward direction, 61839 entered the function via the normal entry point, execution in the reverse 61840 direction will never sees the break point at the alternate entry point. In 61841 this case, the reverse execution continues until the next break point is 61842 encountered thus stopping at the wrong place. 61843 61844 This patch adds a new address to struct execution_control_state to hold the 61845 address of the alternate entry point (GEP). The finish_backwards function 61846 is updated, if the stopping point is between the normal entry point (LEP) 61847 and the end of the function, a breakpoint is set at the normal entry point. 61848 If the stopping point is between the entry points, a breakpoint is set at 61849 the alternate entry point. This ensures that GDB will always stop at the 61850 normal entry point. If the function did enter via the alternate entry 61851 point, GDB will detect that and continue to execute backwards in the 61852 function until the alternate entry point is reached. 61853 61854 The patch fixes the behavior of the reverse-finish command on PowerPC to 61855 match the behavior of the command on other platforms, specifically X86. 61856 The patch does not change the behavior of the command on X86. 61857 61858 A new test is added to verify the reverse-finish command on PowerPC 61859 correctly stops at the instruction where the function call is made. 61860 61861 The patch fixes 11 regression errors in test gdb.reverse/finish-precsave.exp 61862 and 11 regression errors in test gdb.reverse/finish-reverse.exp. 61863 61864 The patch has been tested on Power 10 and X86 processor with no new 61865 regression failures. 61866 618672023-03-17 Carl Love <cel@us.ibm.com> 61868 61869 Move step_until procedure 61870 Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp 61871 is moved to lib/gdb.exp and renamed repeat_cmd_until. The existing procedure 61872 gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until 61873 procedure. The existing procedure gdb_step_until is changed to just call 61874 the new repeat_cmd_until procedure with the command set to "step" and an 61875 optional CURRENT string. The default CURRENT string is set to "\}" to work 61876 with the existing uses of procedure gdb_step_until. 61877 618782023-03-17 Tom de Vries <tdevries@suse.de> 61879 61880 [gdb/testsuite] Fix regexp in gdb.arch/ftrace-insn-reloc.exp 61881 With test-case gdb.arch/ftrace-insn-reloc.exp and host board 61882 local-remote-host-notty and target board native-gdbserver I run into: 61883 ... 61884 (gdb) info sharedlibrary^M 61885 From To Syms Read Shared Object Library^M 61886 $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M 61887 $hex $hex Yes /home/remote-host/libinproctrace.so^M 61888 $hex $hex Yes /lib64/libm.so.6^M 61889 $hex $hex Yes /lib64/libc.so.6^M 61890 $hex $hex Yes /lib64/libdl.so.2^M 61891 $hex $hex Yes (*) /usr/lib64/libstdc++.so.6^M 61892 $hex $hex Yes (*) /lib64/libgcc_s.so.1^M 61893 $hex $hex Yes /lib64/libpthread.so.0^M 61894 (*): Shared library is missing debugging information.^M 61895 (gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded 61896 ... 61897 due to trying to match libinproctrace.so using the target path, while the 61898 command lists it using the host path. 61899 61900 Fix this by making the regexp less strict. 61901 61902 Tested on x86_64-linux. 61903 619042023-03-17 Tom de Vries <tdevries@suse.de> 61905 61906 [gdb/testsuite] Handle remote host in gdb_load_shlib 61907 With test-case gdb.arch/ftrace-insn-reloc.exp and host board 61908 local-remote-host-notty and target board native-gdbserver I run into: 61909 ... 61910 (gdb) tstart^M 61911 Target returns error code '.In-process agent library not loaded in process. \ 61912 Fast and static trace points unavailable.'.^M 61913 (gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment 61914 ... 61915 61916 Fix this by: 61917 - handling remote host in gdb_load_shlib, and 61918 - moving the gdb_load_shlib to after the clean_restart, such that the 61919 set solib-search-path can take effect. 61920 61921 Tested on x86_64-linux. 61922 619232023-03-17 Tom de Vries <tdevries@suse.de> 61924 61925 [gdb/testsuite] Fix gdb.arch/i386-biarch-core.exp for remote host 61926 Fix test-case gdb.arch/i386-biarch-core.exp using gdb_download_remote host. 61927 61928 Tested on x86_64-linux. 61929 619302023-03-17 Tom de Vries <tdevries@suse.de> 61931 61932 [gdb/testsuite] Handle REMOTE_HOST_USERNAME in local-remote-host 61933 Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for 61934 REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost. 61935 61936 This helps to keep the home dir clean. 61937 61938 Since the setup makes $build/gdb/testsuite on build unreadable for the remote 61939 host, we run into permission problems for GDB and the data-directory, so fix 61940 this (as was done for gdbserver in gdbserver-base.exp) using file normalize. 61941 61942 Tested on x86_64-linux. 61943 619442023-03-17 Tom de Vries <tdevries@suse.de> 61945 61946 [gdb/testsuite] Set remotedir by default in some boards 61947 When doing a gdb_simple_compile, and downloading the resulting exec $obj 61948 to target the result $target_obj may be a relative file path, which may give 61949 problems when trying to do: 61950 ... 61951 remote_exec target $target_obj 61952 ... 61953 61954 Fix/workaround this on some target boards by setting remotedir by default, and 61955 add a corresponding test in gdb.testsuite/board-sanity.exp. 61956 61957 This doesn't work for host/target board local-remote-host-native, so xfail this. 61958 61959 Tested on x86_64-linux. 61960 619612023-03-17 Tom de Vries <tdevries@suse.de> 61962 61963 [gdb/testsuite] Fix have_avx for remote target 61964 In proc have_avx we compile some source into an exec, resulting in a file $obj 61965 on build, and then attempt to execute it on target: 61966 ... 61967 set result [remote_exec target $obj] 61968 ... 61969 61970 Fix this by using gdb_remote_download target. 61971 61972 Likewise in a few other procs that use "remote_exec target". 61973 61974 Tested on x86_64-linux. 61975 619762023-03-17 Tom de Vries <tdevries@suse.de> 61977 61978 [gdb/testsuite] Handle precise-aligned-alloc.c for remote host 61979 With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and 61980 host board local-remote-host-notty and target board native-gdbserver I run 61981 into: 61982 ... 61983 gdb compile failed, i386-sse.c:68:10: fatal error: \ 61984 ../lib/precise-aligned-alloc.c: No such file or directory 61985 #include "../lib/precise-aligned-alloc.c" 61986 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 61987 ... 61988 61989 Fix this using '#include "precise-aligned-alloc.c"' and making that work with 61990 non-remote and remote host. 61991 61992 Tested on x86_64-linux. 61993 619942023-03-17 Tom de Vries <tdevries@suse.de> 61995 61996 [gdb/testsuite] Handle remote host in escape_for_host 61997 With test-case gdb.arch/ftrace-insn-reloc.exp and host board 61998 local-remote-host-notty and target board native-gdbserver, I run into: 61999 ... 62000 FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded 62001 ... 62002 due to having: 62003 ... 62004 $ readelf -d ftrace-insn-reloc | grep RUNPATH 62005 0x000000000000001d (RUNPATH) Library runpath: [] 62006 ... 62007 instead of: 62008 ... 62009 $ readelf -d ftrace-insn-reloc | grep RUNPATH 62010 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN] 62011 ... 62012 62013 Handle this in escape_for_host. 62014 62015 Tested on x86_64-linux. 62016 620172023-03-17 Tom de Vries <tdevries@suse.de> 62018 62019 [gdb/testsuite] Add escape_for_host 62020 In gdb_compile we have: 62021 ... 62022 lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN" 62023 ... 62024 and we could improve readability by using {} rather than "": 62025 ... 62026 lappend new_options {ldflags=-Wl,-rpath,\$ORIGIN} 62027 ... 62028 62029 But rather than manually adding escapes in a string, add a new proc 62030 escape_for_host that care of this for us, allowing us to write: 62031 ... 62032 lappend new_options [escape_for_host {ldflags=-Wl,-rpath,$ORIGIN}] 62033 ... 62034 62035 Tested on x86_64-linux. 62036 620372023-03-17 Alan Modra <amodra@gmail.com> 62038 62039 mach-o: out of memory in get_dynamic_reloc_upper_bound 62040 * mach-o.c (bfd_mach_o_canonicalize_dynamic_reloc): Move sanity 62041 checks.. 62042 (bfd_mach_o_get_dynamic_reloc_upper_bound): ..to here. 62043 62044 Another source_sh 62045 * scripttempl/z80.sc: Use source_sh to source elf.sc. 62046 620472023-03-17 Tom de Vries <tdevries@suse.de> 62048 62049 [gdb/testsuite] Declare ada unsupported for remote host 62050 Currently gdb_ada_compile doesn't support remote host. 62051 62052 Make this explicit in allow_ada_tests. 62053 62054 Tested on x86_64-linux. 62055 620562023-03-17 Jan Beulich <jbeulich@suse.com> 62057 62058 gas: apply md_register_arithmetic also to unary '+' 62059 Even a unary '+' has to be considered arithmetic; at least on x86 in 62060 Intel Syntax mode otherwise bogus insn operands may be accepted. 62061 Convert this specific case to binary + (i.e. 0 + <register>). (An 62062 implication is that md_operator(,1,) would need to deal with arch- 62063 specific equivalents of unary '+' is a similar way, if such an arch- 62064 specific variant would be specified in the first place.) 62065 62066 To avoid duplicating what make_expr_symbol() does to construct a 62067 constant-zero expression, simply make its previously local variable a 62068 file-scope static one. This way there's also no need to invoke 62069 clean_up_expression(). 62070 620712023-03-17 Jan Beulich <jbeulich@suse.com> 62072 62073 gas: expose flag_macro_alternate globally 62074 Yet again with the removal of gasp about 20 years ago this extra level 62075 of indirection isn't necessary anymore either. Drop macro.c's local 62076 variable and make as.c's global. 62077 62078 While doing the conversion, switch the variable to "bool". 62079 620802023-03-17 Jan Beulich <jbeulich@suse.com> 62081 62082 gas: use flag_mri directly in macro processing 62083 Again with the removal of gasp about 20 years ago the extra level of 62084 indirection isn't necessary anymore. Drop macro.c's local variable and 62085 use the global flag directly. 62086 62087 gas: isolate macro_strip_at to macro.c 62088 This removes a leftover from i960 support; with that nothing is left 62089 which would set macro_strip_at to non-zero, so the variable is converted 62090 to a #define (retaining the logic in case a new user would appear) and 62091 macro_init()'s respective parameter is dropped. 62092 62093 gas: drop function pointer parameter from macro_init() 62094 With the removal of gasp (about 20 years ago) the need for this kind- 62095 of-hook has disappeared. Go a step beyond merely moving the to be called 62096 function: Inline its contents right at the sole call site. 62097 620982023-03-17 Tom de Vries <tdevries@suse.de> 62099 62100 [gdb/testsuite] Fix filename in gdb.debuginfod/crc_mismatch.exp 62101 After running test-case gdb.debuginfod/crc_mismatch.exp, I find a dir called '$': 62102 ... 62103 $ ls $build/gdb/testsuite/ 62104 $ config.log gdb.log lib outputs site.exp 62105 cache config.status gdb.sum Makefile site.bak temp 62106 ... 62107 62108 Fix this by removing the stray '$' here: 62109 ... 62110 set debugfile "$[standard_output_file ${testfile}.debug]" 62111 ... 62112 62113 Tested on x86_64-linux. 62114 621152023-03-17 GDB Administrator <gdbadmin@sourceware.org> 62116 62117 Automatic date update in version.in 62118 621192023-03-16 Andrew Burgess <aburgess@redhat.com> 62120 62121 gdb/doc: extended documentation for inferior function calls 62122 I noticed that the documentation for inferior function calls doesn't 62123 say much about what happens if/when an inferior function call is 62124 interrupted, i.e. it doesn't describe what the dummy frame looks like 62125 on the stack, or how GDB behaves when the inferior is continued and 62126 reaches the dummy frame. 62127 62128 This commit aims to add some of this missing information. 62129 621302023-03-16 Tom Tromey <tromey@adacore.com> 62131 62132 Fix build breakage in rs6000-aix-tdep.c 62133 A recent change to rs6000-aix-tdep.c broke the build. This patch 62134 fixes it by declaring a few target descriptions in ppc-tdep.h and then 62135 not including the various features .c files in rs6000-aix-tdep.c. 62136 621372023-03-16 Hui Li <lihui@loongson.cn> 62138 62139 gdb/testsuite: Add support for LoongArch in gdb.base/float.exp 62140 The test results on LoongArch as follows: 62141 62142 Without this patch: 62143 62144 ``` 62145 $ make check-gdb TESTS="gdb.base/float.exp" 62146 === gdb Summary === 62147 62148 # of expected passes 2 62149 # of unexpected failures 1 62150 62151 ``` 62152 With this patch: 62153 62154 ``` 62155 $ make check-gdb TESTS="gdb.base/float.exp" 62156 === gdb Summary === 62157 62158 # of expected passes 3 62159 62160 ``` 62161 62162 Reviewed-By: Tom Tromey <tom@tromey.com> 62163 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62164 621652023-03-16 Christophe Lyon <christophe.lyon@linaro.org> 62166 62167 Re: Add --enable-linker-version option 62168 The recently-added ld-version*.d tests expect 62169 .*GNU ld \(GNU Binutils\) 2.* 62170 in the .comment section. 62171 62172 However, when buidling --with-pkgversion=XXX, we get 62173 GNU ld (XXX) 2.[...] 62174 instead, leading to a spurious FAIL. 62175 62176 This small patch replaces "GNU Binutils" with ".*" instead. 62177 62178 I inspected other testcases to see if we already had similar 62179 occurrences but I couldn't see any, so I hope this fix is OK for the 62180 purpose? 62181 62182 Thanks, 62183 62184 Christophe 62185 621862023-03-16 Andrew Burgess <aburgess@redhat.com> 62187 62188 gdb/doc: spring clean the Python unwinders documentation 62189 The documentation for the Python Unwinders API could do with some 62190 improvement. The 'Unwinder Skeleton Code' has an error: it says 62191 'unwinders' when it should say 'unwinder' in one case. 62192 62193 Additionally, by placing the 'Unwinder Skeleton Code' before the 62194 section 'Registering an Unwinder' we have skipping including the 62195 registration line in the skeleton code. But this is confusion for 62196 users (I think) as the skeleton code is almost complete, except for 62197 one missing line which the user has to figure out for themselves. By 62198 reordering the sections, it is now obvious that the registration 62199 should be included in the skeleton code, and the example is therefore 62200 almost complete. 62201 62202 Additionally, in the example skeleton code the way in which the 62203 frame-id was being built (using the current stack point and program 62204 counter is (a) not correct, and (b) counter to what is laid out in the 62205 'Unwinder Input' section when describing building a frame-id. 62206 62207 I've removed the incorrect code and replaced it with more generic 62208 comments indicating what needs to be done. As the actual actions that 62209 need to be performed are both architecture specific, and dependent on 62210 the function being unwound, it's almost impossible to include more 62211 exact code here, but I think what I'm proposing is less misleading 62212 than what we had before. 62213 62214 I've also added more cross references. 62215 62216 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 62217 622182023-03-16 Clément Chigot <chigot@adacore.com> 62219 62220 ld/testsuite: disable ilp32 tests for aarch64-qnx 62221 aarch64nto32 emulation isn't supported. The tests will then fall back 62222 on aarch64elf32. It does work but some extra warnings are being 62223 generated because the "-z relro" being added aarch64nto but ignored by 62224 aarch64elf32 emulation. 62225 Skip the tests to avoid any problems. 62226 62227 ld/ChangeLog: 62228 62229 * testsuite/ld-aarch64/emit-relocs-112-overflow.d: Skip for 62230 aarch64nto. 62231 * testsuite/ld-aarch64/emit-relocs-112.d: Likewise. 62232 * testsuite/ld-aarch64/emit-relocs-113.d: Likewise. 62233 * testsuite/ld-aarch64/emit-relocs-114-overflow.d: Likewise. 62234 * testsuite/ld-aarch64/emit-relocs-114.d: Likewise. 62235 * testsuite/ld-aarch64/emit-relocs-115.d: Likewise. 62236 * testsuite/ld-aarch64/emit-relocs-116-overflow.d: Likewise. 62237 * testsuite/ld-aarch64/emit-relocs-116.d: Likewise. 62238 * testsuite/ld-aarch64/emit-relocs-117.d: Likewise. 62239 * testsuite/ld-aarch64/emit-relocs-118-overflow.d: Likewise. 62240 * testsuite/ld-aarch64/emit-relocs-118.d: Likewise. 62241 * testsuite/ld-aarch64/emit-relocs-119.d: Likewise. 62242 * testsuite/ld-aarch64/emit-relocs-22.d: Likewise. 62243 * testsuite/ld-aarch64/emit-relocs-23.d: Likewise. 62244 * testsuite/ld-aarch64/emit-relocs-28.d: Likewise. 62245 * testsuite/ld-aarch64/emit-relocs-86-overflow.d: Likewise. 62246 * testsuite/ld-aarch64/emit-relocs-86.d: Likewise. 62247 * testsuite/ld-aarch64/emit-relocs-87.d: Likewise. 62248 * testsuite/ld-aarch64/emit-relocs-88-overflow.d: Likewise. 62249 * testsuite/ld-aarch64/emit-relocs-88.d: Likewise. 62250 * testsuite/ld-aarch64/emit-relocs-89.d: Likewise. 62251 * testsuite/ld-aarch64/emit-relocs-90-overflow.d: Likewise. 62252 * testsuite/ld-aarch64/emit-relocs-90.d: Likewise. 62253 * testsuite/ld-aarch64/emit-relocs-92.d: Likewise. 62254 * testsuite/ld-aarch64/tls-desc-ie-ilp32.d: Likewise. 62255 * testsuite/ld-aarch64/tls-relax-all-ilp32.d: Likewise. 62256 * testsuite/ld-aarch64/tls-relax-gd-ie-ilp32.d: Likewise. 62257 * testsuite/ld-aarch64/tls-relax-gd-le-ilp32.d: Likewise. 62258 * testsuite/ld-aarch64/tls-relax-gdesc-le-2-ilp32.d: Likewise. 62259 * testsuite/ld-aarch64/tls-relax-gdesc-le-ilp32.d: Likewise. 62260 * testsuite/ld-aarch64/tls-relax-ie-le-2-ilp32.d: Likewise. 62261 * testsuite/ld-aarch64/tls-relax-ie-le-3-ilp32.d: Likewise. 62262 * testsuite/ld-aarch64/tls-relax-ie-le-ilp32.d: Likewise. 62263 * testsuite/ld-aarch64/tls-relax-ld-le-small-ilp32.d: Likewise. 62264 * testsuite/ld-aarch64/tls-relax-ld-le-tiny-ilp32.d: Likewise. 62265 * testsuite/ld-aarch64/tls-tiny-desc-ie-ilp32.d: Likewise. 62266 * testsuite/ld-aarch64/tls-tiny-desc-le-ilp32.d: Likewise. 62267 * testsuite/ld-aarch64/tls-tiny-gd-ie-ilp32.d: Likewise. 62268 * testsuite/ld-aarch64/tls-tiny-gd-le-ilp32.d: Likewise. 62269 622702023-03-16 Clément Chigot <chigot@adacore.com> 62271 62272 ld/testsuite: add aarch64nto to ld-aarch64 62273 ld/ChangeLog: 62274 62275 * testsuite/ld-aarch64/aarch64-elf.exp: Add support for 62276 aarch64nto. 62277 622782023-03-16 Clément Chigot <chigot@adacore.com> 62279 62280 ld: add support of QNX stack arguments for aarch64nto 62281 QNX is handling the stack argument using a .note section. Generate it 62282 according to ELF argument -zexecstack, -zstack-size and a new NTO 62283 argument --lazy-stack. Another NTO argument --stack mimicking 62284 -zstack-size is added in order to ensure compatibility with previously 62285 made NTO linkers. 62286 This requires a new emultempl nto.em which is applied above the default 62287 ${ARCH}elf.em. 62288 62289 ld/ChangeLog: 62290 62291 * emulparams/aarch64nto.sh: Move to nto.em. 62292 * emultempl/nto.em: New file. 62293 * testsuite/ld-aarch64/aarch64-nto.exp: New test. 62294 * testsuite/ld-aarch64/nto-stack-note-1.d: New test. 62295 * testsuite/ld-aarch64/nto-stack-note-2.d: New test. 62296 * testsuite/ld-aarch64/start.s: New test. 62297 622982023-03-16 Clément Chigot <chigot@adacore.com> 62299 62300 readelf: add support for QNT_STACK note subsections 62301 QNX provides some .note subsections. QNT_STACK is the one controling 62302 the stack allocation. 62303 62304 bfd/ChangeLog: 62305 62306 * elf.c (BFD_QNT_CORE_INFO): Delete. 62307 (BFD_QNT_CORE_STATUS): Likewise. 62308 (BFD_QNT_CORE_GREG): Likewise. 62309 (BFD_QNT_CORE_FPREG): Likewise. 62310 (elfcore_grok_nto_note): Replace BFD_QNT_* by QNT_*. 62311 62312 binutils/ChangeLog: 62313 62314 * readelf.c (get_qnx_elfcore_note_type): New function. 62315 (print_qnx_note): New function. 62316 (process_note): Add support for QNX support. 62317 62318 include/ChangeLog: 62319 62320 * elf/common.h (QNT_DEBUG_FULLPATH): New define. 62321 (QNT_DEBUG_RELOC): New define. 62322 (QNT_STACK): New define. 62323 (QNT_GENERATOR): New define. 62324 (QNT_DEFAULT_LIB): New define. 62325 (QNT_CORE_SYSINFO): New define. 62326 (QNT_CORE_INFO): New define. 62327 (QNT_CORE_STATUS): New define. 62328 (QNT_CORE_GREG): New define. 62329 (QNT_CORE_FPREG): New define. 62330 (QNT_LINK_MAP): New define. 62331 623322023-03-16 Clément Chigot <chigot@adacore.com> 62333 62334 configure: add new target aarch64-*-nto* 62335 This target has its own ld emulation based on aarch64elf.em. 62336 623372023-03-16 Cupertino Miranda <cupertino.miranda@oracle.com> 62338 62339 BPF relocations review / refactoring 62340 - Removed not needed relocations. 62341 - Renamed relocations to match llvm and linux kernel. 62342 62343 Relocation changes: 62344 R_BPF_INSN_64 => R_BPF_64_64 62345 R_BPF_INSN_DISP32 => R_BPF_64_32 62346 R_BPF_DATA_32 => R_BPF_64_ABS32 62347 R_BPF_DATA_64 => R_BPF_64_ABS64 62348 62349 ChangeLog: 62350 62351 * bfd/bpf-reloc.def: Created file with BPF_HOWTO macro entries. 62352 * bfd/reloc.c: Removed non needed relocations. 62353 * bfd/bfd-in2.h: regenerated. 62354 * bfd/libbfd.h: regenerated. 62355 * bfd/elf64-bpf.c: Changed relocations. 62356 * include/elf/bpf.h: Adapted relocation values/names. 62357 * gas/config/tc-bpf.c: Changed relocation mapping. 62358 623592023-03-16 Alan Modra <amodra@gmail.com> 62360 62361 Re: Add --enable-linker-verssion 62362 Output sections without any input sections to initialise their flags 62363 have their flags initialised by data statements to LOAD, ALLOC, 62364 HAS_CONTENTS by default. This is wrong for .comment. Fix that by 62365 making the script initialise the section type to INFO, one of the 62366 noalloc section types. That also allows the address of .comment to be 62367 set to zero, as is usual for non-alloc sections. 62368 62369 Also, use source_sh for all of the sourced scripts to set up make 62370 dependencies. 62371 62372 PR 30187 62373 * scripttempl/misc-sections.sc: Set .comment address to zero 62374 and type to INFO. 62375 * scripttempl/ft32.sc: Fix breakages from last edit. 62376 * scripttempl/arclinux.sc: Use source_sh to source DWARF.sc 62377 and misc-sections.sc. 62378 * scripttempl/avr.sc: Likewise. 62379 * scripttempl/dlx.sc: Likewise. 62380 * scripttempl/elf.sc: Likewise. 62381 * scripttempl/elf32cr16.sc: Likewise. 62382 * scripttempl/elf32crx.sc: Likewise. 62383 * scripttempl/elf32msp430.sc: Likewise. 62384 * scripttempl/elf64bpf.sc: Likewise. 62385 * scripttempl/elf64hppa.sc: Likewise. 62386 * scripttempl/elf_chaos.sc: Likewise. 62387 * scripttempl/elfarc.sc: Likewise. 62388 * scripttempl/elfarcv2.sc: Likewise. 62389 * scripttempl/elfd10v.sc: Likewise. 62390 * scripttempl/elfd30v.sc: Likewise. 62391 * scripttempl/elfm68hc11.sc: Likewise. 62392 * scripttempl/elfm68hc12.sc: Likewise. 62393 * scripttempl/elfm9s12z.sc: Likewise. 62394 * scripttempl/elfmicroblaze.sc: Likewise. 62395 * scripttempl/elfxgate.sc: Likewise. 62396 * scripttempl/elfxtensa.sc: Likewise. 62397 * scripttempl/epiphany_4x4.sc: Likewise. 62398 * scripttempl/i386beos.sc: Likewise. 62399 * scripttempl/i386go32.sc: Likewise. 62400 * scripttempl/ia64vms.sc: Likewise. 62401 * scripttempl/ip2k.sc: Likewise. 62402 * scripttempl/iq2000.sc: Likewise. 62403 * scripttempl/mep.sc: Likewise. 62404 * scripttempl/mmo.sc: Likewise. 62405 * scripttempl/nds32elf.sc: Likewise. 62406 * scripttempl/pru.sc: Likewise. 62407 * scripttempl/v850.sc: Likewise. 62408 * scripttempl/v850_rh850.sc: Likewise. 62409 * scripttempl/visium.sc: Likewise. 62410 * scripttempl/xstormy16.sc: Likewise. 62411 * scripttempl/z80.sc: Likewise. 62412 * testsuite/ld-scripts/ld-version-2.d: Don't skip ft32 or pru. 62413 624142023-03-16 Alan Modra <amodra@gmail.com> 62415 62416 cpu/mem.opc whitespace tidy 62417 cpu/ 62418 * mep.opc: Whitespace and formatting. 62419 opcodes/ 62420 * mep-asm.c: Regenerate. 62421 * mep-dis.c: Regenerate. 62422 624232023-03-16 Alan Modra <amodra@gmail.com> 62424 62425 PR30217, dynamic relocations using local dynamic symbols 62426 glibc's ld.so ignores local dynamic symbols. It's been that way 62427 forever. We therefore can't use them on dynamic relocations. Fixing 62428 that problem uncovered another problem in sorting of dynamic relocs, 62429 caused no doubt by copying make_iplt_section (where we don't want 62430 reloc sorting by the generic gold function, we want iplt relocs last) 62431 to make_lplt_section (where we do want sorting). 62432 62433 PR 30217 62434 * powerpc.cc (branch_needs_plt_entry): New function. 62435 (Target_powerpc::plt_off): Use it here.. 62436 (Target_powerpc::Scan::global): ..and here to correct PLT16 reloc 62437 handling for forced-local global symbols. 62438 (Output_data_plt_powerpc::add_entry): Rename "stash" 62439 parameter "is_local". Emit relative relocs for globals that 62440 are forced local, and don't set_needs_dynsym_entry. 62441 (Target_powerpc::make_lplt_section): Don't create a separate 62442 reloc section, use rela_dyn. 62443 (Target_powerpc::make_brlt_section): Likewise. 62444 624452023-03-16 Alan Modra <amodra@gmail.com> 62446 62447 Re: Sanity check read_section_stabs_debugging_info 62448 * rddbg.c (read_section_stabs_debugging_info): Don't segfault on 62449 zero size string section. 62450 624512023-03-16 GDB Administrator <gdbadmin@sourceware.org> 62452 62453 Automatic date update in version.in 62454 624552023-03-15 Tom Tromey <tromey@adacore.com> 62456 62457 Fix formatting in gdb/printing.py 62458 According to black 23, gdb/printing.py was mis-formatted. This patch 62459 fixes it. 62460 624612023-03-15 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 62462 62463 Enable vector register visibility in core for AIX. 62464 This patch enables AIX folks to see vector register contents while they 62465 analyse the core file. 62466 624672023-03-15 Tom de Vries <tdevries@suse.de> 62468 62469 [gdb/testsuite] Fix re-used exec in gdb.arch/ftrace-insn-reloc.exp 62470 In test-case gdb.arch/ftrace-insn-reloc.exp we generate two executables with 62471 the same name, which is confusing and known to cause trouble. 62472 62473 Fix this by making the executable names unique. 62474 62475 Tested on x86_64-linux. 62476 624772023-03-15 Tom de Vries <tdevries@suse.de> 62478 62479 [gdb/testsuite] Fix gdb.arch/amd64-stap-special-operands.exp for remote host 62480 With test-case gdb.arch/amd64-stap-special-operands.exp and host board 62481 local-remote-host-notty and target board native-gdbserver I run into: 62482 ... 62483 (gdb) break -pstap three_arg^M 62484 No probe matching objfile=`<any>', provider=`<any>', name=`three_arg'^M 62485 Make breakpoint pending on future shared library load? (y or [n]) n^M 62486 (gdb) FAIL: gdb.arch/amd64-stap-special-operands.exp: probe: three_arg: \ 62487 gdb_breakpoint: set breakpoint at -pstap three_arg 62488 ... 62489 due to compiling two executables with the same name, and when uploading the 62490 second one from host to build, we run into: 62491 ... 62492 Upload from 127.0.0.1 failed, \ 62493 $outputs/gdb.arch/amd64-stap-special-operands/amd64-stap-special-operands: \ 62494 Text file busy. 62495 ... 62496 62497 Fix this by making the executable names unique. 62498 62499 Tested on x86_64-linux. 62500 625012023-03-15 Tom de Vries <tdevries@suse.de> 62502 62503 [gdb/testsuite] Fix gdb.arch/i386-pkru.exp for native-gdbserver 62504 With test-case gdb.arch/i386-pkru.exp and target board native-gdbserver we run 62505 into: 62506 ... 62507 FAIL: gdb.arch/i386-pkru.exp: variable after reading pkru 62508 ... 62509 62510 This looks similar to the the problem for which there's already an xfail, so 62511 fix this by extending the xfail matching. 62512 62513 Tested on x86_64-linux. 62514 62515 Also tested on openSUSE Tumbleweed, where all tests in the test-case pass. 62516 625172023-03-15 Tom de Vries <tdevries@suse.de> 62518 62519 [gdb/testsuite] Unset DEBUGINFOD_URLS on remote host 62520 When running test-case gdb.arch/i386-pkru.exp with host board 62521 local-remote-host-notty and target board native-gdbserver on openSUSE 62522 Tumbleweed (with DEBUGINFOD_URLS set), I run into: 62523 ... 62524 This GDB supports auto-downloading debuginfo from the following URLs:^M 62525 <https://debuginfod.opensuse.org/>^M 62526 Enable debuginfod for this session? (y or [n]) ^CQuit^M 62527 (gdb) FAIL: gdb.arch/i386-pkru.exp: runto: run to main 62528 ... 62529 62530 The problem is that the unsetenv for DEBUGINFOD_URLS in default_gdb_init: 62531 ... 62532 # If DEBUGINFOD_URLS is set, gdb will try to download sources and 62533 # debug info for f.i. system libraries. Prevent this. 62534 unset -nocomplain ::env(DEBUGINFOD_URLS) 62535 ... 62536 doesn't work on remote host. 62537 62538 Fix this by using "set debuginfod enabled off" for remote host. 62539 62540 Tested on x86_64-linux. 62541 625422023-03-15 Tom de Vries <tdevries@suse.de> 62543 62544 [gdb/testsuite] Fix gdb.arch/amd64*.exp with local-remote-host-native.exp 62545 There's a number of gdb.arch/amd64*.exp test-cases that fail with host+target 62546 board local-remote-host-native.exp because of using a .S file, generated from 62547 a .c file. 62548 62549 If a test-case compiles the .S file when executing on remote host, 62550 the .S file is already copied from build to host, such that it's available for 62551 the compiler. 62552 62553 But that's not the case for the .c file, which is needed by gdb to show a 62554 source line: 62555 ... 62556 (gdb) continue^M 62557 Continuing.^M 62558 ^M 62559 Breakpoint 2, fn2 (y=y@entry=25, x=x@entry=6) at amd64-entry-value-inline.c:32^M 62560 32 in gdb.arch/amd64-entry-value-inline.c^M 62561 (gdb) FAIL: gdb.arch/amd64-entry-value-inline.exp: continue to breakpoint: \ 62562 break-here 62563 ... 62564 62565 Fix this by using "gdb_remote_download host <.c file>". 62566 62567 Tested on x86_64-linux, with host+target board local-remote-host-native. 62568 625692023-03-15 Nick Clifton <nickc@redhat.com> 62570 62571 Add --enable-linker-version option to bfd linker to add an entry in the .comment section. 62572 PR 30187 62573 * NEWS: Mention the new feature. * ld.texi: Document the new feature. * ldgram.y: Handle LINKER_VERSION token. * ldlang.c (lang_add_version): New function. (enable_linker_version): New global variable. * ldlang.h (land_add_version): Prototype. (enable_linker_version): Export. * ldlex.h (OPTION_ENABLE_LINKER_VERSION): Define. (OPTION_DISABLE_LINKER_VERSION): Define. * ldlex.l (LINKER_VERSION): Add token. * lexsup.c (ld_options): Add --enable-linker-version and --disable-linker-version. (parse_args): Handle the new options. * scripttempl/arclinux.sc: Remove stabs and comment sections and replace with inclusion of misc-sections.sc * scripttempl/avr.sc: Likewise. * scripttempl/dlx.sc: Likewise. * scripttempl/elf.sc: Likewise. * scripttempl/elf32cr16.sc: Likewise. * scripttempl/elf32crx.sc: Likewise. * scripttempl/elf32msp430.sc: Likewise. * scripttempl/elf64bpf.sc: Likewise. * scripttempl/elf64hppa.sc: Likewise. * scripttempl/elf_chaos.sc: Likewise. * scripttempl/elfarc.sc: Likewise. * scripttempl/elfarcv2.sc: Likewise. * scripttempl/elfd10v.sc: Likewise. * scripttempl/elfd30v.sc: Likewise. * scripttempl/elfm68hc11.sc: Likewise. * scripttempl/elfm68hc12.sc: Likewise. * scripttempl/elfm9s12z.sc: Likewise. * scripttempl/elfmicroblaze.sc: Likewise. * scripttempl/elfxgate.sc: Likewise. * scripttempl/elfxtensa.sc: Likewise. * scripttempl/epiphany_4x4.sc: Likewise. * scripttempl/ft32.sc: Likewise. * scripttempl/ip2k.sc: Likewise. * scripttempl/iq2000.sc: Likewise. * scripttempl/mep.sc: Likewise. * scripttempl/nds32elf.sc: Likewise. * scripttempl/pru.sc: Likewise. * scripttempl/v850.sc: Likewise. * scripttempl/v850_rh850.sc: Likewise. * scripttempl/visium.sc: Likewise. * scripttempl/xstormy16.sc: Likewise. * scripttempl/z80.sc: Likewise. * testsuite/ld-scripts/script.exp: Run new tests. * scripttempl/misc-sections.sc: New file. * testsuite/ld-scripts/ld-version-2.d: New file. * testsuite/ld-scripts/ld-version.d: New file. * testsuite/ld-scripts/ld-version.t: New file. 62574 62575 Fix an illegal memory access when disassembling a corrupt MeP file. 62576 PR 30231 62577 * mep.opc (mep_print_insn): Check for an out of range index. 62578 62579 Fix an illegal memory access when disassebling a corrupt ARM file. 62580 PR 30230 62581 * arm-dis.c (get_sym_code_type): Check for non-ELF symbols. 62582 625832023-03-15 GDB Administrator <gdbadmin@sourceware.org> 62584 62585 Automatic date update in version.in 62586 625872023-03-14 Tom Tromey <tromey@adacore.com> 62588 62589 Implement DAP variables, scopes, and evaluate requests 62590 The DAP code already claimed to implement "scopes" and "evaluate", but 62591 this wasn't done completely correctly. This patch implements these 62592 and also implements the "variables" request. 62593 62594 After this patch, variables and scopes correctly report their 62595 sub-structure. This also interfaces with the gdb pretty-printer API, 62596 so the output of pretty-printers is available. 62597 625982023-03-14 Tom Tromey <tromey@adacore.com> 62599 62600 Hide the implementation of gdb_mpf 62601 This renames the data member of gdb_mpf and makes it private. It also 62602 adds a single new method to aid in this change. Unlike the earlier 62603 changes here, I did this one all together because gdb_mpf has very few 62604 uses. 62605 62606 Rename gdb_mpq::val and make contents private 62607 This changes gdb_mpq to hide its data, and renames the data member 62608 from 'val' to 'm_val', following gdb convention. 62609 626102023-03-14 Tom Tromey <tromey@adacore.com> 62611 62612 Add operators and methods to gdb_mpq 62613 This adds some operators and methods to gdb_mpq, in preparation for 62614 making its implementation private. 62615 62616 This only adds the operators currently needed by gdb. More could be 62617 added as necessary. 62618 626192023-03-14 Tom Tromey <tromey@adacore.com> 62620 62621 Rename gdb_mpz::val and make contents private 62622 This changes gdb_mpz to hide its data, and renames the data member 62623 from 'val' to 'm_val', following gdb convention. 62624 626252023-03-14 Tom Tromey <tromey@adacore.com> 62626 62627 Add methods and operators to gdb_mpz 62628 This adds various methods and operators to gdb_mpz, as a step toward 62629 hiding the implementation. 62630 62631 This only adds the operators that were needed. Many more could be 62632 added as required. 62633 626342023-03-14 Tom Tromey <tromey@adacore.com> 62635 62636 Clean up gmp-utils.h includes 62637 gmp-utils.h includes "defs.h", but normally the rule in gdb is that 62638 the .c files include this first. This patch changes this code to 62639 match the rest of gdb. 62640 626412023-03-14 Tom Tromey <tromey@adacore.com> 62642 62643 Fix DAP frame bug with older versions of Python 62644 Tom de Vries pointed out that one DAP test failed on Python 3.6 62645 because gdb.Frame is not hashable. 62646 62647 This patch fixes the problem by using a list to hold the frames. This 62648 is less efficient but there normally won't be that many frames. 62649 62650 Tested-by: Tom de Vries <tdevries@suse.de> 62651 626522023-03-14 Nick Clifton <nickc@redhat.com> 62653 62654 Prevent an over large memory allocation in readelf when parsing a corrupt DWARF file. 62655 PR 30227 62656 * dwarf.c (process_cu_tu_index): Prevent excessive memory allocation when nused is large and ncols is zero. 62657 626582023-03-14 Tom de Vries <tdevries@suse.de> 62659 62660 [gdb/testsuite] Add gdb.testsuite/board-sanity.exp 62661 Add a test-case that tests the sanity of target/host boards. 62662 62663 It contains a number of tests related to remote file manipulation, exercising: 62664 - remote_upload 62665 - remote_download 62666 - remote_file exists 62667 - remote_file delete 62668 which check that these work together as expected. 62669 62670 Tested on x86_64-linux, with all relevant gdb/testsuite/boards/*.exp boards. 62671 62672 For target board remote-stdio-gdbserver.exp, this revealed a trivial problem 62673 with the return value of proc ${board}_file for delete, so fix this. 62674 62675 The test-case shows that the proc ${board}_download in 62676 local-remote-host-native.exp is broken, so remove it. 62677 62678 Likewise for board local-remote-host.exp, so remove proc ${board}_download and 62679 associated ${board}_file. 62680 62681 Tested on x86_64-linux. 62682 626832023-03-14 Nick Clifton <nickc@redhat.com> 62684 62685 Adjust the decoded line output to fit into 80 columns. 62686 PR 30216 62687 * dwarf.c (display_debug_lines_decoded): Reduce space for filenames. 62688 * testsuite/binutils-all/dw5.W: Adjust expected output. 62689 * testsuite/binutils-all/objdump.WL: Adjust expected output. 62690 62691 Fix assembler documentation regarding data directives. 62692 PR 30206 62693 * doc/as.texi (Pseudo Ops): Document that data directives such as .byte and .int are not intended for encoding instructions. 62694 626952023-03-14 Alan Modra <amodra@gmail.com> 62696 62697 objdump segfault after symbol table error 62698 This memcpy segfaults if symcount is -1 (=> syms is NULL). 62699 memcpy (sorted_syms, symcount ? syms : dynsyms, 62700 sorted_symcount * sizeof (asymbol *)); 62701 62702 * objdump.c (slurp_symtab): Don't leave symcount as -1 after 62703 an error. 62704 (slurp_dynamic_symtab): Likewise for dynsymcount. 62705 627062023-03-14 Alan Modra <amodra@gmail.com> 62707 62708 Sanity check read_section_stabs_debugging_info 62709 * rddbg.c (read_section_stabs_debugging_info): Exclude sections 62710 without contents. Use bfd_malloc_and_get_section. Don't alloc 62711 one extra for strings. 62712 62713 gas/read.c: init more statics 62714 * read.c (current_name, current_label, dwarf_file, dwarf_line): Move 62715 to file scope. 62716 (pobegin): Tidy pop_override_ok. 62717 (read_a_source_file): Make last_eol an auto var. 62718 (s_reloc): Constify bfd_relocs. 62719 (read_begin): Init more variables. 62720 627212023-03-14 Alan Modra <amodra@gmail.com> 62722 62723 gas .include and .incbin 62724 This fixes a bug in .include and .incbin where given an absolute path 62725 the -I dirs would be searched for the path. 62726 62727 * read.c (include_dir_count, include_dir_maxlen): Make them size_t. 62728 (search_and_open): New function. 62729 (s_incbin, s_include): Use search_and_open. 62730 (init_include_dir): New function. 62731 (add_include_dir): Don't set initial "." dir here. 62732 * read.h (include_dir_count, include_dir_maxlen): Update. 62733 (init_include_dir, search_and_open): Declare. 62734 * as.c (gas_early_init): Call init_include_dir. 62735 * config/tc-rx.c (rx_include): Avoid warning by using size_t. 62736 * config/tc-tic54x.c (tic54x_set_default_include): Simplify and 62737 use notes for include path. 62738 (tic54x_mlib): Use search_and_open. 62739 627402023-03-14 Alan Modra <amodra@gmail.com> 62741 62742 gas/dwarf2dbg.c init more statics 62743 * dwarf2dbg.c (dw2_line, dw2_filename): Move to file scope and.. 62744 (dwarf2_gen_line_info): ..renamed from here. 62745 (label_num, last_used, last_used_dir_len): Move to file scope. 62746 (dwarf2_init): Init moved statics, except last_used_dir_len. 62747 627482023-03-14 Alan Modra <amodra@gmail.com> 62749 62750 gas/ecoff.c: don't use zero struct copies to init 62751 It might have made sense once upon a time, but doesn't nowadays when 62752 compilers expand memset inline. 62753 62754 * ecoff.c (add_aux_sym_tir, allocate_scope, allocate_vlinks), 62755 (allocate_shash, allocate_thash, allocate_tag, allocate_forward), 62756 (allocate_thead, allocate_lineno_list): Use memset rather than 62757 copying zero struct. 62758 627592023-03-14 Alan Modra <amodra@gmail.com> 62760 62761 gas/compress-debug.c init all of strm 62762 * compress-debug.c (compress_init): Clear all of strm. 62763 627642023-03-14 GDB Administrator <gdbadmin@sourceware.org> 62765 62766 Automatic date update in version.in 62767 627682023-03-13 Andrew Burgess <aburgess@redhat.com> 62769 62770 gdb: add gdbarch::displaced_step_buffer_length 62771 The gdbarch::max_insn_length field is used mostly to support displaced 62772 stepping; it controls the size of the buffers allocated for the 62773 displaced-step instruction, and is also used when first copying the 62774 instruction, and later, when fixing up the instruction, in order to 62775 read in and parse the instruction being stepped. 62776 62777 However, it has started to be used in other places in GDB, for 62778 example, it's used in the Python disassembler API, and it is used on 62779 amd64 as part of branch-tracing instruction classification. 62780 62781 The problem is that the value assigned to max_insn_length is not 62782 always the maximum instruction length, but sometimes is a multiple of 62783 that length, as required to support displaced stepping, see rs600, 62784 ARM, and AArch64 for examples of this. 62785 62786 It seems to me that we are overloading the meaning of the 62787 max_insn_length field, and I think that could potentially lead to 62788 confusion. 62789 62790 I propose that we add a new gdbarch field, 62791 gdbarch::displaced_step_buffer_length, this new field will do 62792 exactly what it says on the tin; represent the required displaced step 62793 buffer size. The max_insn_length field can then do exactly what it 62794 claims to do; represent the maximum length of a single instruction. 62795 62796 As some architectures (e.g. i386, and amd64) only require their 62797 displaced step buffers to be a single instruction in size, I propose 62798 that the default for displaced_step_buffer_length will be the 62799 value of max_insn_length. Architectures than need more buffer space 62800 can then override this default as needed. 62801 62802 I've updated all architectures to setup the new field if appropriate, 62803 and I've audited all calls to gdbarch_max_insn_length and switched to 62804 gdbarch_displaced_step_buffer_length where appropriate. 62805 62806 There should be no user visible changes after this commit. 62807 62808 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62809 628102023-03-13 Andrew Burgess <aburgess@redhat.com> 62811 62812 gdbarch: make invalid=True the default for all Components 62813 This commit switches the default value for the 'invalid' field from 62814 False to True. All components that previous set the invalid field to 62815 True explicitly have had the field removed. 62816 62817 I think that True is a good choice for the default, this means that we 62818 now get the validity checks by default, and if anyone adds a new 62819 Component they need to make a choice to add an 'invalid=False' line 62820 and disable the validation. 62821 62822 The flip side of this is that 'invalid=False' seems to be far more 62823 common than 'invalid=True'. But I don't see a huge problem with this, 62824 we shouldn't be aiming to reduce our typing, rather we should choose 62825 based on which is least likely to introduce bugs. I think assuming 62826 that we should do a validity check will achieve that. 62827 62828 Some additional components need to have an 'invalid=False' line added 62829 to their definition, these are components that have a predefault 62830 value, which is sufficient; the tdep code doesn't need to replace this 62831 value if it doesn't want to. 62832 62833 Without adding the 'invalid=False' these components would be 62834 considered to be invalid if they have not changed from their 62835 predefault value -- but the predefault is fine. 62836 62837 There's no change in the generated code after this commit, so there 62838 will be no user visible changes after this commit. 62839 62840 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62841 628422023-03-13 Andrew Burgess <aburgess@redhat.com> 62843 62844 gdbarch: remove some unneeded predefault="0" from gdbarch_components.py 62845 I noticed that there are a bunch of 'predefault="0"' lines in 62846 gdbarch_components.py, and that some (just some, not all) of these are 62847 not needed. 62848 62849 The gdbarch is already zero initialized, but these lines seem to 62850 exists so that we can know when to compare against "0" and when to 62851 compare against "NULL". At least, this seems to be useful in some 62852 places in the generated code. 62853 62854 Specifically, if we remove the predefault="0" line from the 62855 max_insn_length component then we end up generating a line like: 62856 62857 gdb_assert (gdbarch->max_insn_length != NULL); 62858 62859 which doesn't compile as we compare a ULONGEST to NULL. 62860 62861 In this commit I remove all the predefault="0" lines that I claim are 62862 obviously not needed. These are lines for components that are not 62863 Values (i.e. the component holds a function pointer anyway), or for 62864 Value components that hold a pointer type, in which case using NULL is 62865 fine. 62866 62867 The only changes after this commit are some fields that have nullptr 62868 as their initial value, and gcore_bfd_target now compares to NULL not 62869 0 in gdbarch_gcore_bfd_target_p, which, given the field is of type 62870 'const char *', seems like an improvement. 62871 62872 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62873 628742023-03-13 Andrew Burgess <aburgess@redhat.com> 62875 62876 gdbarch: improve generation of validation in gdbarch getters 62877 We currently generate some validation code within the gdbarch getter 62878 methods. 62879 62880 This commit adjusts the algorithm used to generate this validation 62881 slightly to make the gdbarch.py code (I think) clearer; there's no 62882 significant changes to what is generated. 62883 62884 The validation algorithm for gdbarch values is now: 62885 62886 - If the Value has an 'invalid' field that is a string, use that for 62887 validation, 62888 62889 - If the Value has its 'predicate' field set to true, then check the 62890 predicate returns true, this ensures the predicate has been 62891 called, 62892 62893 - If the Value has its 'invalid' field set to True, or the Value has 62894 'postdefault' field, then check the fields has changed from its 62895 initial value, 62896 62897 - Otherwise no validation is performed. 62898 62899 The only changes after this commit are: 62900 62901 - Some comments change slightly, and 62902 62903 - For 'gcore_bfd_target' and 'max_insn_length' we now validate by 62904 calling the predicate rather than checking the field value 62905 directly, the underlying check being performed is unchanged 62906 though. 62907 62908 There should be no user visible changes after this commit. 62909 62910 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62911 629122023-03-13 Andrew Burgess <aburgess@redhat.com> 62913 62914 gdbarch: use predefault for more value components within gdbarch 62915 For some reason the following value components of gdbarch: 62916 62917 bfloat16_format 62918 half_format 62919 float_format 62920 double_format 62921 long_double_format 62922 so_ops 62923 62924 All use a postdefault but no predefault to set the default value for 62925 the component. 62926 62927 As the postdefault values for these components are all constant 62928 pointers that don't depend on other fields within the gdbarch, then I 62929 don't see any reason why we couldn't use a predefault instead. 62930 62931 So lets do that. 62932 62933 Approved-By: Simon Marchi <simon.marchi@efficios.com> 62934 629352023-03-13 Andrew Burgess <aburgess@redhat.com> 62936 62937 gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py 62938 This commit ensures that the 'invalid' property of all components is 62939 either True, False, or a string. 62940 62941 Additionally, this commit allows a component to have both a predicate 62942 and for the 'invalid' property to be a string. 62943 62944 Removing the option for 'invalid' to be None allows us to simplify the 62945 algorithms in gdbarch.py a little. 62946 62947 Allowing a component to have both a predicate and an 'invalid' string 62948 means that we can validate the value that a tdep sets into a field, 62949 but also allow a predicate to ensure that the field has changed from 62950 the default. 62951 62952 This functionality isn't going to be used in this series, but I have 62953 tested it locally and believe that it would work, and this might make 62954 it easier for others to add new components in the future. 62955 62956 In gdbarch_types.py, I've updated the type annotations to show that 62957 the 'invalid' field should not be None, and I've changed the default 62958 for this field from None to False. 62959 62960 The change to using False as the default is temporary. Later in this 62961 series I'm going to change the default to True, but we need more fixes 62962 before that can be done. 62963 62964 Additionally, in gdbarch_types.py I've removed an assert from 62965 Component.get_predicate. This assert ensured that we didn't have the 62966 predicate field set to True and the invalid field set to a string. 62967 However, no component currently uses this configuration, and after 62968 this commit, that combination is now supported, so the assert can be 62969 removed. 62970 62971 As a consequence of the gdbarch_types.py changes we see some 62972 additional comments generated in gdbarch.c about verification being 62973 skipped due to the invalid field being False. This comment is inline 62974 with plenty of other getters that also have a similar comment. Plenty 62975 of the getters do have validation, so I think it is reasonable to have 62976 a comment noting that the validation has been skipped for a specific 62977 reason, rather than due to some bug. 62978 62979 In gdbarch_components.py I've had to add 'invalid=True' for two 62980 components: gcore_bfd_target and max_insn_length, without this the 62981 validation in the gdbarch getter would disappear. 62982 62983 And in gdbarch.py I've reworked the logic for generating the 62984 verify_gdbarch function, and for generating the getter functions. 62985 62986 The logic for generating the getter functions is still not ideal, I 62987 ended up having to add this additional logic block: 62988 62989 elif c.postdefault is not None and c.predefault is not None: 62990 print(" /* Check variable changed from pre-default. */", file=f) 62991 print(f" gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f) 62992 62993 which was needed to ensure we continued to generate the same code as 62994 before, without this the fact that invalid is now False when it would 62995 previously have been None, meant that we dropped the gdb_assert in 62996 favour of a comment like: 62997 62998 print(f" /* Skip verify of {c.name}, invalid_p == 0 */", file=f) 62999 63000 which is clearly not a good change. We could potentially look at 63001 improving this in a later commit, but I don't plan to do that in this 63002 series. 63003 63004 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63005 630062023-03-13 Andrew Burgess <aburgess@redhat.com> 63007 63008 gdb/gdbarch: split postdefault setup from invalid check in gdbarch.py 63009 Restructure how gdbarch.py generates the verify_gdbarch function. 63010 Previously the postdefault handling was bundled together with the 63011 validation. This means that a field can't have both a postdefault, 63012 and set its invalid attribute to a string. 63013 63014 This doesn't seem reasonable to me, I see no reason why a field can't 63015 have both a postdefault (used when the tdep doesn't set the field), 63016 and an invalid expression, which can be used to validate the value 63017 that a tdep might set. 63018 63019 In this commit I restructure the verify_gdbarch generation code to 63020 allow the above, there is no change in the actual generated code in 63021 this commit, that will come in later commit. 63022 63023 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63024 630252023-03-13 Andrew Burgess <aburgess@redhat.com> 63026 63027 gdb/gdbarch: remove yet more 'invalid=True' from gdbarch_components.py 63028 Following on from the previous commit, this commit removes yet more 63029 'invalid=True' lines from gdbarch_components.py where the invalid 63030 setting has no effect. 63031 63032 Due to the algorithm used in gdbarch.py for generated verify_gdbarch, 63033 if a component has a postdefault value then no invalid check will ever 63034 be generated for the component, as such setting 'invalid=True' on the 63035 component is pointless. This commit removes the setting of invalid. 63036 63037 There is no change in the generated code after this commit. 63038 63039 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63040 630412023-03-13 Andrew Burgess <aburgess@redhat.com> 63042 63043 gdb/gdbarch: remove unused 'invalid=True' from gdbarch_components.py 63044 Due to the algorithm used to generate verify_gdbarch in gdbarch.py, if 63045 a component has a predicate, then a validation check will never be 63046 generated. 63047 63048 There are a bunch of components that are declared with both a 63049 predicate AND have 'invalid=True' set. The 'invalid=True' has no 63050 effect. 63051 63052 In this commit I clean things up by removing all these additional 63053 'invalid=True' lines. There's no change in any of the generated files 63054 after this commit. 63055 63056 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63057 630582023-03-13 Tom Tromey <tromey@adacore.com> 63059 63060 Fix crash in inside_main_func 63061 gdb 13.1 crashes while running the rust compiler's debugger tests. 63062 The crash has a number of causes. 63063 63064 First, the rust compiler still uses the C++-like _Z mangling, but with 63065 its own twist -- some hex digits added to the end of a symbol. So, 63066 while gdb finds the correct name of "main": 63067 63068 (top-gdb) p name 63069 $13 = 0x292e0c0 "rustc_gdb_1031745::main" 63070 63071 It isn't found in the minsyms, because C++ demangling yields: 63072 63073 [99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v 63074 63075 This could perhaps be fixed. I also filed a new PR to suggest 63076 preferring the linkage name of the main program. 63077 63078 Next, the rust compiler emits both a DW_TAG_subprogram and a 63079 DW_TAG_namespace for "main". This happens because the file is named 63080 "main.rs" -- i.e., the bug is specific to the source file name. The 63081 crash also seems to require the nested function inside of 'main', at 63082 least for me. The namespace always is generated, but perhaps this 63083 changes the ordering in the DWARF. 63084 63085 When inside_main_func looks up the main symbol, it finds the namespace 63086 symbol rather than the function. (I filed a bug about fixing gdb's 63087 symbol tables -- long overdue.) 63088 63089 Meanwhile, as I think it's important to fix this crash sooner rather 63090 than later, this patch changes inside_main_func to check that the 63091 symbol that is found is LOC_BLOCK. This perhaps should have been done 63092 in the first place, anyway. 63093 63094 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30158 63095 630962023-03-13 Tom de Vries <tdevries@suse.de> 63097 63098 [gdb/testsuite] Fix gdb.python/tui-window-factory.exp for remote host 63099 When running gdb.python/tui-window.exp with host board 63100 local-remote-host-notty and target board native-gdbserver, I get: 63101 ... 63102 FAIL: gdb.python/tui-window-factory.exp: msg_2: \ 63103 check test_window box (box check: ul corner is l, not +) 63104 ... 63105 63106 The problem is that the result of Term::prepare_for_tui is not checked. 63107 63108 Fix this by adding the missing check. 63109 63110 Tested on x86_64-linux. 63111 631122023-03-13 Tom de Vries <tdevries@suse.de> 63113 63114 [gdb/testsuite] Fix gdb.python/tui-window.exp for remote host 63115 When running gdb.python/tui-window.exp with host board 63116 local-remote-host-notty and target board native-gdbserver, I get: 63117 ... 63118 UNSUPPORTED: gdb.python/tui-window.exp: TUI not supported 63119 FAIL: gdb.python/tui-window.exp: test title 63120 ... 63121 63122 Fix this by adding the missing return after the unsupported. 63123 63124 Tested on x86_64-linux. 63125 631262023-03-13 Tom de Vries <tdevries@suse.de> 63127 63128 [gdb/testsuite] Fix gdb.tui/completion.exp for local-remote-host-notty 63129 When running test-case gdb.tui/completion.exp with host board 63130 local-remote-host-notty and target board native-gdbserver, I get: 63131 ... 63132 FAIL: gdb.tui/completion.exp: completion of layout names: \ 63133 tab completion (timeout) 63134 ... 63135 63136 The test-case contains a few tests that do tab completion, which requires 63137 readline, which is unavailable with host board local-remote-host-notty. 63138 63139 Fix this by adding the missing check for readline_is_used. 63140 63141 Tested on x86_64-linux. 63142 631432023-03-13 Tom de Vries <tdevries@suse.de> 63144 63145 [gdb/testsuite] Fix gdb.tui/tui-layout.exp for remote host 63146 When running test-case gdb.tui/tui-layout.exp with host board 63147 local-remote-host-notty and target board native-gdbserver, I get: 63148 ... 63149 FAIL: gdb.tui/tui-layout.exp: terminal=dumb: execution=false: layout=asm: \ 63150 layout asm (timeout) 63151 ... 63152 63153 The problem is that the test-case expects that the default "setenv TERM dumb" 63154 has effect, which is not the case for remote host. 63155 63156 Fix this by skipping the test for remote host. 63157 63158 Tested on x86_64-linux. 63159 631602023-03-13 Tom de Vries <tdevries@suse.de> 63161 63162 [gdb/testsuite] Fix gdb.tui/tui-nl-filtered-output.exp for remote host 63163 When running test-case gdb.tui/tui-nl-filtered-output.exp with host board 63164 local-remote-host-notty and target board native-gdbserver, I get: 63165 ... 63166 FAIL: gdb.tui/tui-nl-filtered-output.exp: check printf output 63167 ... 63168 63169 The problem is that Term::enter_tui is returning 0, but the test-case doesn't 63170 check for this, and consequently runs unsupported tests. 63171 63172 Fix this by adding the missing check. 63173 63174 Tested on x86_64-linux. 63175 631762023-03-13 Tom de Vries <tdevries@suse.de> 63177 63178 [gdb/testsuite] Require ![is_remote host] for TUI 63179 When running test-case gdb.tui/corefile-run.exp with both host and target board 63180 local-remote-host-native.exp, we run into: 63181 ... 63182 FAIL: gdb.tui/corefile-run.exp: load corefile 63183 ... 63184 while this passes with USE_TUI=0. 63185 63186 The problem is that the TUI setup code uses "setenv TERM ansi", which has no 63187 effect on remote host. 63188 63189 I can confirm this analysis by working around this problem in 63190 local-remote-host-native.exp like this: 63191 ... 63192 - spawn $RSH -t -l $username $remote $cmd 63193 + spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd" 63194 ... 63195 63196 For now, simply make TUI unsupported for remote host, by returning 0 in 63197 prepare_for_tui. 63198 63199 Tested on x86_64-linux. 63200 632012023-03-13 Tom de Vries <tdevries@suse.de> 63202 63203 [gdb/testsuite] Handle USE_TUI in gdb.tui/corefile-run.exp 63204 Once in a while I find myself rewriting a TUI test-case into a non-TUI 63205 test-case, to better understand whether the problem I'm looking at is 63206 related to the TUI or not. 63207 63208 I've got the impression that I've done this sufficiently often that it's worth 63209 committing the non-TUI version, so having just written a non-TUI version of 63210 gdb.tui/corefile-run.exp, let's commit it. 63211 63212 The non-TUI version can be enabled by doing: 63213 ... 63214 $ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0" 63215 ... 63216 63217 Also remove hard-coding of a source line number. 63218 63219 Tested on x86_64-linux. 63220 632212023-03-13 Tom de Vries <tdevries@suse.de> 63222 63223 [gdb/testsuite] Fix untested message in gdb.tui/corefile-run.exp 63224 In test-case gdb.tui/corefile-run.exp, we have this bit: 63225 ... 63226 require !use_gdb_stub 63227 if { [target_info gdb_protocol] == "extended-remote" } { 63228 untested "not supported" 63229 return 63230 } 63231 ... 63232 63233 So with target board native-gdbserver we get: 63234 ... 63235 UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub 63236 ... 63237 and with target board native-extended-gdbserver instead: 63238 ... 63239 UNTESTED: gdb.tui/corefile-run.exp: not supported 63240 ... 63241 63242 Fix this by: 63243 - adding an optional argument target_description to proc 63244 target_can_use_run_cmd 63245 - handling the target_description == core && 63246 [target_info gdb_protocol] == "extended-remote" case in the proc 63247 - using require {target_can_use_run_cmd core} 63248 such that now in both cases we have: 63249 ... 63250 UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \ 63251 target_can_use_run_cmd core 63252 ... 63253 63254 Tested on x86_64-linux. 63255 632562023-03-13 Tom de Vries <tdevries@suse.de> 63257 63258 [gdb/testsuite] Fix gdb.threads/step-bg-decr-pc-switch-thread.exp for native-gdbserver 63259 With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board 63260 native-gdbserver, I run into: 63261 ... 63262 (gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \ 63263 switch to main thread 63264 Remote debugging from host ::1, port 43914^M 63265 monitor exit^M 63266 Cannot execute this command while the target is running.^M 63267 Use the "interrupt" command to stop the target^M 63268 and then try again.^M 63269 (gdb) WARNING: Timed out waiting for EOF in server after monitor exit 63270 ... 63271 63272 Fix this by following the advice and issuing an interrupt command, allowing 63273 the following monitor exit command to succeed. 63274 63275 Tested on x86_64-linux. 63276 632772023-03-13 Bruno Larsen <blarsen@redhat.com> 63278 63279 [gdb/obvious]: fix python formatting for test gdb.python/py-typeprint.py 63280 python black formatter was complaining about the formatting of 63281 gdb.python/py-typeprint.py, so this commit corrects it. 63282 632832023-03-13 Bruno Larsen <blarsen@redhat.com> 63284 63285 gdb/testsuite: add regression test for per-objfile typeprinters 63286 PR python/17136 reported an unhandled exception when using typeprinters 63287 only valid on some objfiles, rather than being a global typeprinter. The 63288 fix was accepted without a regression test, and we've been carrying one 63289 out-of-tree for a while but I think it's worth upstreaming. The code 63290 itself was developed by Jan Kratochvil. 63291 63292 Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com> 63293 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136 63294 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 63295 Approved-By: Tom Tromey <tom@tromey.com> 63296 632972023-03-13 Tom Tromey <tromey@adacore.com> 63298 63299 Remove dead code from scalar_binop 63300 scalar_binop has code for "&&" and "||", but I think this code can't 63301 currently be run -- and, furthermore, it doesn't make sense to have 63302 this code here, as the point of these operators is to short-circuit 63303 evaluation. 63304 63305 This patch removes the dead code. 63306 63307 Regression tested on x86-64 Fedora 36. 63308 63309 Approved-by: Kevin Buettner <kevinb@redhat.com> 63310 633112023-03-13 Luis Machado <luis.machado@arm.com> 63312 63313 aarch64: Expand documentation of XML features 63314 Similar to the arm target documentation situation, the documentation of the 63315 XML features for AArch64 targets is rather brief. I have received the same 63316 feedback that what gdb carries in the documentation is quite unclear from the 63317 perspective of what debugging servers should define in the XML features, how and 63318 what the outcome is in gdb. 63319 63320 This patch attempts to clarify a bit more what all the possible features are. 63321 633222023-03-13 Luis Machado <luis.machado@arm.com> 63323 63324 arm: Expand documentation of XML features 63325 The documentation of the XML features for Arm targets is very brief. I have 63326 received feedback saying it is quite unclear from the perspective of the 63327 debugging servers what should be defined in the XML features, how and 63328 what the outcome is in gdb. 63329 63330 This patch attempts to clarify a bit more what all the possible features are. 63331 633322023-03-13 GDB Administrator <gdbadmin@sourceware.org> 63333 63334 Automatic date update in version.in 63335 633362023-03-12 GDB Administrator <gdbadmin@sourceware.org> 63337 63338 Automatic date update in version.in 63339 633402023-03-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 63341 63342 gprofng: fix the Dwarf reader 63343 gprofng/ChangeLog 63344 2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 63345 63346 gprofng/src/DwarfLib.cc (DwrLineRegs::getPath): Add a DW_AT_comp_dir 63347 string if the directoty table has relative names. 63348 633492023-03-11 Tom Tromey <tom@tromey.com> 63350 63351 Change linetable_entry::is_stmt to bool 63352 This changes linetable_entry::is_stmt to type bool, rather than 63353 unsigned. 63354 63355 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63356 633572023-03-11 Tom Tromey <tom@tromey.com> 63358 63359 Remove extra scopes from objfile_relocate1 63360 objfile_relocate1 introduces new scopes that aren't necessary. I 63361 noticed this while working on an earlier patch in this series. This 63362 patch removes these. 63363 63364 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63365 633662023-03-11 Tom Tromey <tom@tromey.com> 63367 63368 Constify linetables 63369 Linetables no longer change after they are created. This patch 63370 applies const to them. 63371 63372 Note there is one hack to cast away const in mdebugread.c. This code 63373 allocates a linetable using 'malloc', then later copies it to the 63374 obstack. While this could be cleaned up, I chose not to do so because 63375 I have no way of testing it. 63376 63377 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63378 633792023-03-11 Tom Tromey <tom@tromey.com> 63380 63381 Change linetables to be objfile-independent 63382 This changes linetables to not add the text offset to the addresses 63383 they contain. I did this in a few steps, necessarily combined 63384 together in one patch: I renamed the 'pc' member to 'm_pc', added the 63385 appropriate accessors, and then recompiled. Then I fixed all the 63386 errors. Where possible I generally chose to use the raw_pc accessor, 63387 as it is less expensive. 63388 63389 Note that this patch discounts the possibility that the text section 63390 offset might cause wraparound in the addresses in the line table. 63391 However, this was already discounted -- in particular, 63392 objfile_relocate1 did not re-sort the table in this scenario. (There 63393 was a bug open about this, but as far as I can tell this has never 63394 happened, it's not even clear what inspired that bug.) 63395 63396 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63397 633982023-03-11 Tom Tromey <tom@tromey.com> 63399 63400 Add operator< and operator== to linetable_entry 63401 This adds a couple of comparison operators to linetable_entry, and 63402 simplifies both the calls to sort and one other spot that checks for 63403 equality. 63404 63405 Approved-By: Simon Marchi <simon.marchi@efficios.com> 63406 634072023-03-11 GDB Administrator <gdbadmin@sourceware.org> 63408 63409 Automatic date update in version.in 63410 634112023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 63412 63413 gprofng: PR30195 [display text] Source code location can not be found 63414 gprofng/ChangeLog 63415 2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 63416 63417 PR gprofng/30195 63418 gprofng/src/DwarfLib.cc (DwrLineRegs::reset): Set 'file = 1;'. 63419 634202023-03-10 John Baldwin <jhb@FreeBSD.org> 63421 63422 PR gdb/30214: Prefer local include paths to system include paths 63423 Some systems may install binutils headers into a system location 63424 (e.g. /usr/local/include on FreeBSD) which may also include headers 63425 for other external packages used by GDB such as zlib or zstd. If a 63426 system include path such as /usr/local/include is added before local 63427 include paths to directories within a clone or release tarball, then 63428 headers from the external binutils package are used which can result 63429 in build failures if the external binutils package is out of sync with 63430 the version of GDB being built. 63431 63432 To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS 63433 for "local" componenets before external components. 63434 63435 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214 63436 Reviewed-By: Tom Tromey <tom@tromey.com> 63437 634382023-03-10 Fangrui Song <maskray@google.com> 63439 63440 ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg) 63441 Similar to d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274 for x86_64. 63442 63443 _Thread_local int a; 63444 int main() { return a; } 63445 63446 % gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no 63447 /usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed 63448 /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value 63449 collect2: error: ld returned 1 exit status 63450 63451 This commit fixes the issue. 63452 63453 There is an argument that the -fno-plt TLS sequence was added after 63454 R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was 63455 intended to be unsupported. 63456 63457 Unfortunately this standpoint has caused interop difficulty: some 63458 projects specify -mrelax-relocations=no to build relocatable object 63459 files compatible with older linkers (e.g. 63460 https://github.com/IHaskell/IHaskell/issues/636) or do so by accident 63461 (e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of 63462 today). Many uses have not been cleaned up in practice, and compiling 63463 with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...` 63464 error which is hard to reason about. 63465 63466 It seems easier to apply this simple change to prevent the footgun. 63467 63468 PR ld/24784 63469 * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32. 63470 634712023-03-10 Fangrui Song <maskray@google.com> 63472 63473 ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip) 63474 _Thread_local int a; 63475 int main() { return a; } 63476 63477 % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no 63478 /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed 63479 /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value 63480 collect2: error: ld returned 1 exit status 63481 63482 This commit fixes the issue. 63483 63484 There is an argument that the -fno-plt TLS sequence was added after 63485 R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was 63486 intended to be unsupported. 63487 63488 Unfortunately this standpoint has caused interop difficulty: some 63489 projects specify -mrelax-relocations=no to build relocatable object 63490 files compatible with older linkers (e.g. 63491 https://github.com/IHaskell/IHaskell/issues/636) or do so by accident 63492 (e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of 63493 today). Many uses have not been cleaned up in practice, and compiling 63494 with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...` 63495 error which is hard to reason about. 63496 63497 There is another argument which may be weaker but relevant to the 63498 necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will 63499 likely need some assembler support to disable relaxation. Without the 63500 support and if the compiler needs to support many gas version, the 63501 simplest solution would be to use -Wa,-mrelax-relocations=no. 63502 63503 PR ld/24784 63504 * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow 63505 R_X86_64_GOTPCREL. 63506 635072023-03-10 Tom de Vries <tdevries@suse.de> 63508 63509 [gdb/testsuite] Fix gdb.python/py-completion.exp 63510 With test-case gdb.python/py-completion.exp and target board 63511 native-extended-gdbserver I get this warning: 63512 ... 63513 (gdb) PASS: gdb.python/py-completion.exp: discard #2 63514 completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\ 63515 PASS: gdb.python/py-completion.exp: completefilecommandcond completion 63516 Remote debugging from host ::1, port 53346^M 63517 monitor exit^M 63518 not implemented^M 63519 (gdb) WARNING: Timed out waiting for EOF in server after monitor exit 63520 ... 63521 63522 Fix this by adding the missing "discard #3", such that we have instead: 63523 ... 63524 (gdb) PASS: gdb.python/py-completion.exp: discard #2 63525 completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\ 63526 PASS: gdb.python/py-completion.exp: completefilecommandcond completion 63527 ^M 63528 not implemented^M 63529 (gdb) PASS: gdb.python/py-completion.exp: discard #3 63530 Remote debugging from host ::1, port 36278^M 63531 monitor exit^M 63532 (gdb) 63533 ... 63534 63535 Tested on x86_64-linux. 63536 635372023-03-10 Tom de Vries <tdevries@suse.de> 63538 63539 [gdb/testsuite] Fix gdb.python/py-cmd.exp 63540 [ Using $pp as shorthand for the pagination prompt 63541 "--Type <RET> for more, q to quit, c to continue without paging--". ] 63542 63543 The test-case gdb.python/py-cmd.exp passes, but the handling of the 63544 test_multiline command output looks a bit odd: 63545 ... 63546 (gdb) test_multiline 63547 test_multiline output 63548 ... 63549 test_multiline output 63550 $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline 63551 q 63552 test_multiline 63553 Quit 63554 (gdb) test_multiline 63555 test_multiline output 63556 ... 63557 test_multiline output 63558 $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q 63559 ... 63560 63561 What happens is: 63562 - a test_multiline command is issued 63563 - some output is printed, followed by a pagination prompt 63564 - the test-case concludes that pagination occurred, and produces a PASS 63565 - "q\n" is replied to the pagination prompt 63566 - without waiting for response to the "q\n", another test_multiline command is 63567 issued 63568 - in response to the "q\n" we get "Quit\n(gdb) " 63569 - some output is printed, followed by a pagination prompt 63570 - the test-case concludes that there's a valid response to the "q\n", and 63571 produces a PASS, consuming the second pagination prompt, but without a reply. 63572 63573 My conclusion is that the second test_multiline command is unintentional, so fix 63574 this by removing it. 63575 63576 Without it, we have the more straightforward: 63577 ... 63578 (gdb) test_multiline 63579 test_multiline output 63580 ... 63581 test_multiline output 63582 $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline 63583 q 63584 Quit 63585 (gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q 63586 ... 63587 63588 This also fixes the following warning with target board native-gdbserver: 63589 ... 63590 WARNING: Timed out waiting for EOF in server after monitor exit 63591 ... 63592 63593 Tested on x86_64-linux. 63594 635952023-03-10 Tom de Vries <tdevries@suse.de> 63596 63597 [gdb/testsuite] Fix py-autoloaded-pretty-printers-in-newobjfile-event.exp for remote target 63598 With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp 63599 and target board remote-gdbserver-on-localhost, I run into: 63600 ... 63601 FAIL: $exp: runto: run to main 63602 ... 63603 63604 I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into: 63605 ... 63606 (gdb) print all_good^M 63607 $1 = false^M 63608 (gdb) FAIL: $exp: print all_good 63609 info pretty-printer^M 63610 ... 63611 63612 Sysroot is set to "target:", so gdb downloads the shared library from the target 63613 (Using $so as shorthand for 63614 libpy-autoloaded-pretty-printers-in-newobjfile-event.so): 63615 ... 63616 Reading /home/remote-target/$so from remote target...^M 63617 ... 63618 and internally refers to it as "target:/home/remote-target/$so". 63619 63620 In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts 63621 for $so once it checks for is_target_filename. 63622 63623 Fix this by declaring auto-load unsupported if sysroot starts with "target:". 63624 63625 Tested on x86_64-linux. 63626 636272023-03-10 Tom de Vries <tdevries@suse.de> 63628 63629 [gdb/testsuite] Fix gdb.python/py-event-load.exp for remote target 63630 Fix test-case gdb.python/py-event-load.exp for target board 63631 remote-gdbserver-on-localhost using gdb_download_shlib. 63632 63633 Tested on x86_64-linux. 63634 636352023-03-10 Tom Tromey <tom@tromey.com> 63636 63637 Use require with test_compiler_info 63638 One spot that checks test_compiler_info can be switched to use 63639 'require'. 63640 63641 More uses of require with istarget 63642 I found a few more spots that check istarget that can be switched to 63643 use 'require'. 63644 63645 Use require with gdb_skip_stdio_test 63646 One use of gdb_skip_stdio_test can use 'require'. 63647 63648 Use require with target_info 63649 This changes many tests to use 'require' when checking target_info. 63650 In a few spots, the require is hoisted to the top of the file, to 63651 avoid doing any extra work when the test is going to be skipped 63652 anyway. 63653 636542023-03-10 Tom Tromey <tromey@adacore.com> 63655 63656 Move allocate_stub_method to stabsread.c 63657 allocate_stub_method is only called from stabsread.c, and I don't 63658 think it will be needed anywhere else. So, move it and make it 63659 static. Tested by rebuilding. 63660 636612023-03-10 Alan Modra <amodra@gmail.com> 63662 63663 Revert ld ASCII support 63664 Revert "Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant." 63665 This reverts commit adbe951fc95943016325af08d677f18e8c177ac1. 63666 63667 Revert "ld test asciz and ascii fails" 63668 This reverts the ascii.d part of commit 5f497256bee624f0fa470949aa41534093bc5b25. 63669 63670 Revert "Add support for the ASCII directive inside linker scripts." 63671 This mostly reverts commit 9fe129a4105bb59398f73ce96938a94f19265b79 63672 leaving the asciz.d and asciz.t changes in place. 63673 636742023-03-10 Alan Modra <amodra@gmail.com> 63675 63676 Revert ld DIGEST support 63677 This is a hopefully temporary reversion of new ld features for 63678 embedded processors by Ulf Samuelsson, plus some followup patches. 63679 63680 Squashed together from the following: 63681 63682 Revert "lddigest 32-bit support and gcc-4 compile errors" 63683 This reverts commit d7ee19be87110a8f5342cec6e323d83d01c641d1. 63684 63685 Revert "ld: Use correct types for crc64 calculations" 63686 This reverts commit 9a534b9f8e3d0f3cdb5a20f19ff165693fbb84d2. 63687 63688 Revert "Re: DIGEST: testsuite" 63689 This reverts commit c8e85484d8a0fe9f7b88e00a6b9ae63bcb53ba32. 63690 63691 Revert "Regen potfiles" 63692 This reverts commit 4d98c966f8bf305ab25badd34cb295631873cf7c. 63693 63694 Revert "DIGEST: Makefile.*" 63695 This reverts commit 78ef6ab03f56ce83a606d974bb8a9f34b5d6e0b7. 63696 63697 Revert "DIGEST: calculation" 63698 This reverts commit 5243990191e683d5066d3dd622c76deaba0bf15c. 63699 63700 Revert "DIGEST: ldlang.*: add timestamp" 63701 This reverts commit bd9466d4aa277a469a9d8b12f0a6e6fa51678e36. 63702 63703 Revert "DIGEST: ldmain.c" 63704 This reverts commit c8f8653fa7eeb3dc0769ac23039eadb5c5f09dff. 63705 63706 Revert "DIGEST: ldgram.y" 63707 This reverts commit d73c01be2669e9c5267fab669a269f95a32048c9. 63708 63709 Revert "DIGEST: ldlex.l" 63710 This reverts commit 48b5163a9dd5759cc87171331bbd6e902c547b5a. 63711 63712 Revert "DIGEST: testsuite" 63713 This reverts commit a4135d1a4886400ea29af2da782dd8dd40ccad23. 63714 63715 Revert "DIGEST: Documentation" 63716 This reverts commit 3ec28966c3e4c63704212778f96c517cbf2e0090. 63717 63718 Revert "DIGEST: NEWS" 63719 This reverts commit 099bf2927d446424e8585a60cf4ce63209999aa2. 63720 63721 Revert "DIGEST: LICENSING" 63722 This reverts commit 5c8a0c6654fb55926985edf3b360b62d4f20691d. 63723 637242023-03-10 Jan Beulich <jbeulich@suse.com> 63725 63726 Arm64/gas: drop redundant feature prereqs 63727 Logic exists to deal with prereqs or prereqs, and in many cases 63728 transitive prereqs are already not spelled out explicitly. Drop further 63729 ones: 63730 - FP is already a prereq to F16, 63731 - SIMD and F16 are already prereqs to COMPNUM, and 63732 - SVE2 and BFLOAT16 are already prereqs to SME. 63733 63734 Arm64/gas: add missing prereq features 63735 A number of newer features are really SIMD or FP extensions, but don't 63736 have this properly specified. 63737 63738 x86: decouple broadcast type and bytes fields 63739 Keep both representing exclusively what was parsed from input, to avoid 63740 the need for (potentially bogus) calculations when processing .insn. 63741 63742 x86-64: adjust REX-prefix part of SSE2AVX test 63743 Before altering how build_modrm_byte() works, arrange for this part of 63744 the testcase to actually use distinguishable source and destination 63745 register numbers, such that incorrect propagation of, in particular, the 63746 high bit encodings (from REX to VEX) can be noticed (in turn 63747 specifically assertions [not] triggering in the respective code). 63748 637492023-03-10 Jan Beulich <jbeulich@suse.com> 63750 63751 x86: move more disp processing out of md_assemble() 63752 Put it in optimize_disp() such that it can then be re-used by .insn 63753 handling. The movement makes it necessary (or at least very desirable, 63754 to avoid introducing a fragile cast) to convert to local variable to 63755 "unsigned", which in turn requires an adjustment to the pre-existing 63756 loop header. 63757 63758 Having the caller pass in the specific template under consideration has 63759 another benefit then: We can replace the two uses of current_templates 63760 in the function as well, thus no longer looking at some merely "related" 63761 template. (This may allow further tightening, but if so that's to be the 63762 subject of another change.) 63763 637642023-03-10 Jan Beulich <jbeulich@suse.com> 63765 63766 x86: use set_rex_vrex() also for short-form handling 63767 This is benign for all existing insns, but is going to be needed for 63768 handling of .insn operands. The earlier use requires moving up the 63769 function, to avoid the need for a forward declaration. 63770 637712023-03-10 Alan Modra <amodra@gmail.com> 63772 63773 eh static data 63774 Fix another case of oss-fuzz tripping over gas static state, 63775 ie. starting over testing another input file with rubbish left 63776 uncleared in bss. size_end_sym pointed at garbage. 63777 63778 * ehopt.c (get_cie_info): Delete forward declaration. 63779 (struct frame_data): Move to file scope. 63780 (frame): New static, packaged.. 63781 (check_eh_frame): ..eh_frame_data and debug_frame_data. 63782 (eh_begin): New function. 63783 * as.c (gas_init): Call eh_begin. 63784 * as.h (eh_begin): Declare. 63785 637862023-03-10 GDB Administrator <gdbadmin@sourceware.org> 63787 63788 Automatic date update in version.in 63789 637902023-03-09 Simon Marchi <simon.marchi@efficios.com> 63791 63792 gdb, gdbserver, gdbsupport: fix whitespace issues 63793 Replace spaces with tabs in a bunch of places. 63794 63795 Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0 63796 637972023-03-09 Tom de Vries <tdevries@suse.de> 63798 63799 [gdb/testsuite] Fix gdb.threads/pending-fork-event-detach.exp for remote target 63800 Fix test-case gdb.threads/pending-fork-event-detach.exp for target board 63801 remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin. 63802 63803 Then, fix the test-case for target board remote-stdio-gdbserver with 63804 REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path 63805 on target using remote_download, and using the resulting path. 63806 63807 Tested on x86_64-linux. 63808 638092023-03-09 Alan Modra <amodra@gmail.com> 63810 63811 objdump: report no section contents 63812 objdump's read_section is never used for bss-style sections, so to 63813 plug a hole that fuzzers have found, exclude sections without 63814 SEC_HAS_CONTENTS. 63815 63816 * objdump.c (read_section): Report and return an error on 63817 a no contents section. 63818 638192023-03-09 Alan Modra <amodra@gmail.com> 63820 63821 gas: allow frag address wrapping in absolute section 63822 This: 63823 .struct -1 63824 x: 63825 .fill 1 63826 y: 63827 results in an internal error in frag_new due to abs_section_offset 63828 wrapping from -1 to 0. Frags in the absolute section don't do much so 63829 I think we can allow the address wrap. 63830 63831 * frags.c (frag_new): Allow address wrap in absolute section. 63832 638332023-03-09 Tom de Vries <tdevries@suse.de> 63834 63835 [gdb/testsuite] Fix gdb.threads/multiple-successive-infcall.exp on native-gdbserver 63836 With test-case gdb.threads/multiple-successive-infcall.exp and target board 63837 native-gdbserver I run into: 63838 ... 63839 (gdb) continue^M 63840 Continuing.^M 63841 [New Thread 758.759]^M 63842 ^M 63843 Thread 1 "multiple-succes" hit Breakpoint 2, main () at \ 63844 multiple-successive-infcall.c:97^M 63845 97 thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M 63846 (gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \ 63847 created new thread 63848 ... 63849 63850 The problem is that the new thread message doesn't match the regexp, which 63851 expects something like this instead: 63852 ... 63853 [New Thread 0x7ffff746e700 (LWP 570)]^M 63854 ... 63855 63856 Fix this by accepting this form of new thread message. 63857 63858 Tested on x86_64-linux. 63859 638602023-03-09 Tom de Vries <tdevries@suse.de> 63861 63862 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver 63863 With test-case gdb.threads/thread-specific-bp.exp and target board 63864 native-gdbserver I run into: 63865 ... 63866 (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected 63867 continue^M 63868 Continuing.^M 63869 Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M 63870 ^M 63871 Thread 1 "thread-specific" hit Breakpoint 4, end () at \ 63872 thread-specific-bp.c:29^M 63873 29 }^M 63874 (gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \ 63875 continue to end (timeout) 63876 ... 63877 63878 The problem is that the test-case tries to match the "[Thread ... exited]" 63879 message which we do see with native testing: 63880 ... 63881 Continuing.^M 63882 [Thread 0x7ffff746e700 (LWP 7047) exited]^M 63883 Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M 63884 ... 63885 63886 The fact that the message is missing was reported as PR remote/30129. 63887 63888 We could add a KFAIL for this, but the functionality the test-case is trying 63889 to test has nothing to do with the message, so it should pass. I only added 63890 matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix 63891 gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so 63892 broke testing on native-gdbserver. 63893 63894 Fix this by matching the "Thread-specific breakpoint $decimal deleted" message 63895 instead. 63896 63897 Tested on x86_64-linux. 63898 638992023-03-09 Tom de Vries <tdevries@suse.de> 63900 63901 [gdb/testsuite] Fix gdb.server/*.exp for remote target 63902 Fix test-cases for target board remote-gdbserver-on-localhost by using 63903 gdb_remote_download. 63904 63905 Tested on x86_64-linux. 63906 639072023-03-09 Tom de Vries <tdevries@suse.de> 63908 63909 [gdb/testsuite] Fix gdb.server/unittest.exp for remote target 63910 With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I 63911 get: 63912 ... 63913 (gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \ 63914 --selftest^M 63915 Selftests have been disabled for this build.^M 63916 UNSUPPORTED: gdb.server/unittest.exp: unit tests 63917 ... 63918 but with target board remote-stdio-gdbserver I get instead: 63919 ... 63920 (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \ 63921 /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M 63922 Selftests have been disabled for this build.^M 63923 Connection to localhost closed.^M^M 63924 FAIL: gdb.server/unittest.exp: unit tests 63925 ... 63926 63927 Fix this by making the regexp less strict. 63928 63929 Tested on x86_64-linux. 63930 639312023-03-09 Tom de Vries <tdevries@suse.de> 63932 63933 [gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.exp 63934 With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver 63935 I run into: 63936 ... 63937 (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \ 63938 --selftest^M 63939 Selftests have been disabled for this build.^M 63940 UNSUPPORTED: gdb.server/unittest.exp: unit tests 63941 ... 63942 due to using the system gdbserver /usr/bin/gdbserver rather than the one from 63943 the build. 63944 63945 Fix this by removing the hard-coding of /usr/bin/gdbserver in 63946 remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we 63947 have instead: 63948 ... 63949 (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \ 63950 /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M 63951 Running selftest remote_memory_tagging.^M 63952 Ran 1 unit tests, 0 failed^M 63953 Connection to localhost closed.^M^M 63954 PASS: gdb.server/unittest.exp: unit tests 63955 ... 63956 63957 Tested on x86_64-linux. 63958 639592023-03-09 Tom de Vries <tdevries@suse.de> 63960 63961 [gdb/testsuite] Fix gdb.server/sysroot.exp for remote target 63962 Fix test-case gdb.server/sysroot.exp with target board 63963 remote-gdbserver-on-localhost, by: 63964 - using gdb_remote_download, and 63965 - disabling the "local" scenario for remote host. 63966 63967 Tested on x86_64-linux. 63968 639692023-03-09 Tom de Vries <tdevries@suse.de> 63970 63971 [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target 63972 Test-case gdb.server/multi-ui-errors.exp fails for target board 63973 remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target: 63974 ... 63975 (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI 63976 Executing on target: kill -9 6447 (timeout = 300) 63977 builtin_spawn [open ...]^M 63978 XYZ1ZYX 63979 sh: line 0: kill: (6447) - Operation not permitted 63980 ... 63981 63982 The problem is that the kill command: 63983 ... 63984 remote_exec target "kill -9 $gdbserver_pid" 63985 ... 63986 intended to kill gdbserver instead tries to kill the ssh client session in 63987 which the gdbserver runs, and fails because it's trying as the remote target 63988 user (remote-target on localhost) to kill a pid owned by the the build user 63989 ($USER on localhost). 63990 63991 Fix this by getting the gdbserver pid using the ppid trick from 63992 server-kill.exp. 63993 63994 Likewise in gdb.server/server-kill-python.exp. 63995 63996 Tested on x86_64-linux. 63997 639982023-03-09 Tom de Vries <tdevries@suse.de> 63999 64000 [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target 64001 In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi") 64002 an observation is made that test-case gdb.server/server-kill.exp claims to 64003 kill gdbserver, but actually kills the inferior. Consequently, the commit 64004 adds testing of killing gdbserver alongside. 64005 64006 The problem is that: 64007 - the original observation is incorrect (possibly caused by misreading getppid 64008 as getpid) 64009 - consequently, the test-case doesn't test killing the inferior, instead it 64010 tests killing gdbserver twice 64011 - the method to get the gdbserver PID added in the commit doesn't work 64012 for target board remote-gdbserver-on-localhost, it returns the 64013 PID of the ssh client session instead. 64014 64015 Fixing the method for getting the inferior PID gives us fails, and there's no 64016 evidence that killing the inferior ever worked. 64017 64018 So, fix this by reverting the commit and just killing gdbserver, using the 64019 original method of getting the gdbserver PID which does work for target board 64020 remote-gdbserver-on-localhost. 64021 64022 Tested on x86_64-linux. 64023 640242023-03-09 Tom de Vries <tdevries@suse.de> 64025 64026 [gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target 64027 Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board 64028 remote-gdbserver-on-localhost. 64029 64030 The problem is here: 64031 ... 64032 set target_exec [gdb_remote_download target $binfile.bak $binfile] 64033 ... 64034 A "gdb_remote_download target" copies from build to target. So $binfile is 64035 assumed to be a target path, but it's actually a build path. 64036 64037 Fix this by: 64038 - fist copying $binfile.bak to $binfile, and 64039 - simply doing [gdb_remote_download target $binfile]. 64040 64041 Then, $binfile.bak is created here: 64042 ... 64043 # Make sure we have the original symbol file in a safe place to copy from. 64044 gdb_remote_download host $binfile $binfile.bak 64045 ... 64046 and since "gdb_remote_download host" copies from build to host, $binfile.bak 64047 is assumed to be a host path, but it's actually a build path. This happens to 64048 cause no problems in this configuration (because build == host), but it would 64049 for a remote host configuration. 64050 64051 So let's fix this by making build rather than host the "safe place to copy 64052 from". 64053 64054 Tested on x86_64-linux. 64055 640562023-03-09 Alan Modra <amodra@gmail.com> 64057 64058 lddigest 32-bit support and gcc-4 compile errors 64059 * ld.texi: Revert 2023-03-08 commit 9a534b9f8e3d. 64060 * testsuite/ld-scripts/crc64-poly.d: Likewise. 64061 * testsuite/ld-scripts/crc64-poly.t: Likewise. 64062 * lddigest.c: Formatting. 64063 (get_uint64_t): New function. 64064 (lang_add_digest): Take etree_type* args. Replace "illegal" with 64065 "invalid" in error message. 64066 * lddigest.h (lang_add_digest): Update prototype. 64067 * lddigest_tab.c (algorithms): Work around gcc-4 errors. 64068 * ldgram.y (polynome): Adjust lang_add_digest call. 64069 * testsuite/ld-scripts/crc64-poly-size.d: Update expected error. 64070 640712023-03-09 GDB Administrator <gdbadmin@sourceware.org> 64072 64073 Automatic date update in version.in 64074 640752023-03-08 Tom Tromey <tom@tromey.com> 64076 64077 Remove OBJF_REORDERED 64078 OBJF_REORDERED is set for nearly every object format. And, despite 64079 the ominous warnings here and there, it does not seem very expensive. 64080 This patch removes the flag entirely. 64081 64082 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 64083 640842023-03-08 Carl Love <cel@us.ibm.com> 64085 64086 PowerPC, fix test gdb.arch/altivec-regs.exp 64087 The test fails on Power 10 with the RHEL9 distro. It also fails on 64088 Power 9. 64089 64090 The test set a the breakpoint in main that stops at line: 64091 a = 9; /* start here */. The test then sets a break point at the same 64092 line where it wants to start the test and does a continue. GDB does not 64093 stop again on the same line where it is stopped, but rather continues to 64094 the end of the program. 64095 64096 Initialize variable A to zero so the break on main will stop before setting 64097 a break point on line a = 9; /* start here */. 64098 64099 Make the match on the breakpoint number generic. 64100 64101 Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04, 64102 and Power 9 with Fedora 36 with no regression failures. 64103 641042023-03-08 Nick Clifton <nickc@redhat.com> 64105 64106 ld: Use correct types for crc64 calculations 64107 641082023-03-08 Alan Modra <amodra@gmail.com> 64109 64110 Tidy pe_ILF_build_a_bfd a little 64111 * peicode.h (ILF section, pe_ILF_object_p): Correct comments 64112 and update the reference to Microsoft's docs. 64113 (pe_ILF_build_a_bfd): Move all symbol creation before flipping 64114 the bfd over to in-memory. 64115 64116 Re: DIGEST: testsuite 64117 Correct test target/skip lines to fix fails on alpha-dec-vms, 64118 alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd, 64119 ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and 64120 tic54x-coff. 64121 64122 Regen potfiles 64123 641242023-03-08 Alan Modra <amodra@gmail.com> 64125 64126 Re: Move nm.c cached line number info to bfd usrdata 64127 Commit e3f450f3933d resulted in a nm -l segfault on object files 64128 without undefined symbols. Fix that, and be paranoid about bfd 64129 section count changing. 64130 64131 * nm.c (struct lineno_cache): Add seccount. 64132 (free_lineno_cache): Don't segfault on NULL lc->relocs. 64133 (print_symbol): Stash section count when creating arrays. 64134 641352023-03-08 Alan Modra <amodra@gmail.com> 64136 64137 z8 and z80 coff_reloc16_extra_cases sanity checks 64138 * reloc16.c (bfd_coff_reloc16_get_relocated_section_contents): 64139 Use size_t variables. Sanity check reloc address. Handle 64140 errors from bfd_coff_reloc16_extra_cases. 64141 * coffcode.h (_bfd_coff_reloc16_extra_cases): Return bool, take 64142 size_t* args. 64143 (dummy_reloc16_extra_cases): Adjust to suit. Don't abort. 64144 * coff-z80.c (extra_case): Sanity check reloc address. Return 64145 errors. Tidy formatting. Use bfd_signed_vma temp var to 64146 check for reloc overflow. Don't abort on unexpected reloc type, 64147 instead print an error and return false. 64148 * coff-z8k.c (extra_case): Likewise. 64149 * libcoff.h: Regenerate. 64150 641512023-03-08 GDB Administrator <gdbadmin@sourceware.org> 64152 64153 Automatic date update in version.in 64154 641552023-03-07 Simon Marchi <simon.marchi@polymtl.ca> 64156 64157 gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value 64158 The AMD GPU support has been merged shortly after commit 4e1d2f5814b2 64159 ("Add new overload of gdbarch_return_value"), which made it mandatory 64160 for architectures to provide either a return_value or 64161 return_value_as_value implementation. Because of my failure to test 64162 properly after rebasing and before pushing, we get this with the current 64163 master: 64164 64165 $ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch 64166 /home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ... 64167 return_value_as_value 64168 64169 I started trying to change GDB to not force architectures to provide a 64170 return_value or return_value_as_value implementation, but Andrew pointed 64171 out that any serious port will have an implementation one day or 64172 another, and it's easy to add a dummy implementation in the mean time. 64173 So it's better to not complicate the core of GDB to know how to deal 64174 with this. 64175 64176 There is an implementation of return_value in the downstream ROCgdb port 64177 (which we'll need to convert to the new return_value_as_value), which 64178 we'll contribute soon-ish. In the mean time, add a dummy implementation 64179 of return_value_as_value to avoid the failed assertion. 64180 64181 Change-Id: I26edf441b511170aa64068fd248ab6201158bb63 64182 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 64183 641842023-03-07 Tom Tromey <tom@tromey.com> 64185 64186 Merge forget_cached_source_info_for_objfile into objfile method 64187 forget_cached_source_info_for_objfile does some objfile-specific work 64188 and then calls objfile::forget_cached_source_info. It seems better to 64189 me to just have the method do all the work. 64190 641912023-03-07 Tom Tromey <tom@tromey.com> 64192 64193 Clean up attribute reprocessing 64194 I ran across the attribute reprocessing code recently and noticed that 64195 it unconditionally sets members of the CU when reading a DIE. Also, 64196 each spot reading attributes needs to be careful to "reprocess" them 64197 as a separate step. 64198 64199 This seemed excessive to me, because while reprocessing applies to any 64200 DIE, setting the CU members is only necessary for the toplevel DIE in 64201 any given CU. 64202 64203 This patch introduces a new read_toplevel_die function and changes a 64204 few spots to call it. This is easily done because reading the 64205 toplevel DIE is already special. 64206 64207 I left the reprocessing flag and associated checks in attribute. It 64208 could be stripped out, but I am not sure it would provide much value 64209 (maybe some iota of performance). 64210 64211 Regression tested on x86-64 Fedora 36. 64212 642132023-03-07 Simon Marchi <simon.marchi@polymtl.ca> 64214 64215 gdb: initialize interp::next 64216 This field is never initialized, it seems to me like it would be a good 64217 idea to initialize it to nullptr to avoid bad surprises. 64218 64219 Change-Id: I8c04319d564f5d385d8bf0acee758f6ce28b4447 64220 Reviewed-By: Tom Tromey <tom@tromey.com> 64221 642222023-03-07 Simon Marchi <simon.marchi@polymtl.ca> 64223 64224 gdb: make interp::m_name an `const char *` 64225 I realized that the memory for interp names does not need to be 64226 allocated. The name used to register interp factory functions is always 64227 a literal string, so has static storage duration. If we change 64228 interp_lookup to pass that name instead of the string that it receives 64229 as a parameter (which does not always have static storage duration), 64230 then interps can simply store pointers to the name. 64231 64232 So, change interp_lookup to pass `factory.name` rather than `name`. 64233 Change interp::m_name to be a `const char *` rather than an std::string. 64234 64235 Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188 64236 Reviewed-By: Tom Tromey <tom@tromey.com> 64237 642382023-03-07 Simon Marchi <simon.marchi@efficios.com> 64239 64240 gdb: make get_interp_info return a reference 64241 get_interp_info and get_current_interp_info always return non-nullptr, 64242 so they can return a reference instead of a pointer. 64243 64244 Since we don't need to copy it, make ui_interp_info non-copyiable, to 64245 avoid a copying it in a local variable, instead of getting a reference. 64246 64247 Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0 64248 Reviewed-By: Tom Tromey <tom@tromey.com> 64249 642502023-03-07 Tom Tromey <tromey@adacore.com> 64251 64252 Fix selfcheck regression due to new maint command 64253 Simon points out that the new maint command, intended to fix a 64254 regression, also introduces a new regression in "maint selftest". 64255 64256 This patch fixes the error. I did a full regression test on x86-64 64257 Fedora 36. 64258 642592023-03-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 64260 64261 gprofng: read Dwarf 5 64262 gprofng reads Dwarf to find function names, sources, and line numbers. 64263 gprofng skips other debug information. 64264 I fixed three places in gprofng Dwarf reader: 64265 - parsing the compilation unit header. 64266 - parsing the line number table header. 64267 - parsing new DW_FORMs. 64268 64269 Tested on aarch64-linux/x86_64-linux. 64270 64271 gprofng/ChangeLog 64272 2023-03-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 64273 64274 PR gprofng/30195 64275 gprofng/src/Dwarf.cc: Support Dwarf-5. 64276 gprofng/src/DwarfLib.cc: Likewise. 64277 gprofng/src/Dwarf.h: Likewise. 64278 gprofng/src/DwarfLib.h: Likewise. 64279 gprofng/src/collctrl.cc: Don't read freed memory. 64280 642812023-03-07 Richard Purdie <richard.purdie@linuxfoundation.org> 64282 64283 gdb: Fix GDB_AC_CHECK_BFD macro regression 64284 Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in 64285 GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment, 64286 this caused the configure check "checking for ELF support in BFD" to stop 64287 working causing build failures as we need our LDFLAGS to be used for 64288 correct linking. 64289 64290 That change also meant the code failed to match the comments. Add back the 64291 missing LDFLAGS preservation, fix our builds and match the comment. 64292 64293 Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112 64294 Approved-By: Simon Marchi <simon.marchi@efficios.com> 64295 Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com> 64296 642972023-03-07 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 64298 64299 Enable vector instruction debugging for AIX 64300 AIX now supports vector register contents debugging for both VMX 64301 VSX registers. 64302 643032023-03-07 Tom de Vries <tdevries@suse.de> 64304 64305 [gdb/testsuite] Fix gdb.threads/execl.exp for remote target 64306 Fix test-case gdb.threads/execl.exp on target board 64307 remote-gdbserver-on-localhost using gdb_remote_download. 64308 64309 Tested on x86_64-linux. 64310 643112023-03-07 Tom Tromey <tromey@adacore.com> 64312 64313 Ensure index cache entry written in test 64314 Now that index cache files are written in the background, one test in 64315 index-cache.exp is racy -- it assumes that the cache file will have 64316 been written during startup. 64317 64318 This patch fixes the problem by introducing a new maintenance command 64319 to wait for all pending writes to the index cache. 64320 64321 Approved-By: Simon Marchi <simon.marchi@efficios.com> 64322 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 64323 643242023-03-07 Tom de Vries <tdevries@suse.de> 64325 64326 [gdb/testsuite] Fix gdb.base/skip-solib.exp for remote target 64327 Fix test-case gdb.base/skip-solib.exp for target board 64328 remote-gdbserver-on-localhost using gdb_load_shlib. 64329 64330 Tested on x86_64-linux. 64331 643322023-03-07 Tom de Vries <tdevries@suse.de> 64333 64334 [gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.exp 64335 In test-case gdb.base/skip-solib.exp the linking against a shared library is 64336 done manually: 64337 ... 64338 if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \ 64339 [list debug "additional_flags=-L$testobjdir" \ 64340 "additional_flags=-l${test}" \ 64341 "ldflags=-Wl,-rpath=$testobjdir"]] != ""} { 64342 ... 64343 64344 Instead, use the shlib gdb_compile option such that we simply have: 64345 ... 64346 [list debug shlib=$binfile_lib]] != ""} { 64347 ... 64348 64349 Tested on x86_64-linux. 64350 643512023-03-07 Tom de Vries <tdevries@suse.de> 64352 64353 [gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for remote target 64354 Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board 64355 remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib. 64356 64357 Tested on x86_64-linux. 64358 643592023-03-07 Tom de Vries <tdevries@suse.de> 64360 64361 [gdb/testsuite] Fix gdb.base/break-probes.exp for remote target 64362 With test-case gdb.base/break-probes.exp and target board 64363 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 64364 failures. 64365 64366 Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib. 64367 64368 Tested on x86_64-linux. 64369 643702023-03-07 Tom de Vries <tdevries@suse.de> 64371 64372 [gdb/testsuite] Fix gdb.dwarf2/dw2-zero-range.exp for remote-gdbserver-on-localhost 64373 Fix test-case gdb.dwarf2/dw2-zero-range.exp for target board 64374 remote-gdbserver-on-localhost using gdb_load_shlib. 64375 64376 Tested on x86_64-linux. 64377 643782023-03-07 Ulf Samuelsson <ulf@emagii.com> 64379 64380 Build ldint 64381 643822023-03-07 Ulf Samuelsson <ulf@emagii.com> 64383 64384 DIGEST: Makefile.* 64385 The Makefile.in was generated using automake 64386 after adding a few files. 64387 64388 When adding the ldreflect.* files, the autotools 64389 versions were wrong. 64390 After upgrading the host OS, autotools were upgraded to 2.71 64391 reinstalling the desired 2.69 still generates a lot of changes. 64392 64393 Makefile.ini has therefore been manually edited. 64394 643952023-03-07 Ulf Samuelsson <ulf@emagii.com> 64396 64397 DIGEST: calculation 64398 64399 DIGEST: ldlang.*: add timestamp 64400 64401 DIGEST: ldmain.c 64402 64403 DIGEST: ldgram.y 64404 64405 DIGEST: ldlex.l 64406 64407 DIGEST: testsuite 64408 64409 DIGEST: Documentation 64410 64411 DIGEST: NEWS 64412 64413 DIGEST: LICENSING 64414 644152023-03-07 Tom de Vries <tdevries@suse.de> 64416 64417 [gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost 64418 With test-case gdb.base/signals-state-child.exp on target board 64419 remote-gdbserver-on-localhost I run into: 64420 ... 64421 builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ 64422 $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M 64423 bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \ 64424 Permission denied^M 64425 Connection to localhost closed.^M^M 64426 FAIL: gdb.base/signals-state-child.exp: collect standalone signals state 64427 ... 64428 64429 The problem is that we're trying to run an executable on the target board using 64430 a host path. 64431 64432 After fixing this by downloading the exec to the target board, we run into: 64433 ... 64434 builtin_spawn /usr/bin/ssh -t -l remote-target localhost \ 64435 signals-state-child-standalone^M 64436 bash: signals-state-child-standalone: command not found^M 64437 Connection to localhost closed.^M^M 64438 FAIL: gdb.base/signals-state-child.exp: collect standalone signals state 64439 ... 64440 64441 Fix this by using an absolute path name for the exec on the target board. 64442 64443 The dejagnu proc standard_file does not support op == "absolute" for target 64444 boards, so add an implementation in remote-gdbserver-on-localhost.exp. 64445 64446 Also: 64447 - fix a PATH-in-test-name issue 64448 - cleanup gdb.txt and standalone.txt on target board 64449 64450 Tested on x86_64-linux. 64451 644522023-03-07 Tom de Vries <tdevries@suse.de> 64453 64454 [gdb/testsuite] Fix gdb.cp/breakpoint-shlib-func.exp with remote-gdbserver-on-localhost 64455 Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board 64456 remote-gdbserver-on-localhost. 64457 64458 Fix this by adding the missing gdb_load_shlib. 64459 64460 Tested on x86_64-linux. 64461 644622023-03-07 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 64463 64464 Modify altivec-regs.exp testcase for AIX 64465 On AIX, the debugger cannot access vector registers before they 64466 are first used by the inferior. Hence we change the test case 64467 such that some vector registers are accessed by the variable 'x' in AIX 64468 and other targets are not affected as a consequence of the same. 64469 644702023-03-07 Tom de Vries <tdevries@suse.de> 64471 64472 [gdb/testsuite] Fix gdb.mi/*.exp with remote-gdbserver-on-localhost 64473 When running test-cases gdb.mi/*.exp with target board 64474 remote-gdbserver-on-localhost, we run into a few fails. 64475 64476 Fix these (and make things more similar to the gdb.exp procs) by: 64477 - factoring out mi_load_shlib out of mi_load_shlibs 64478 - making mi_load_shlib use gdb_download_shlib, like 64479 gdb_load_shlib 64480 - factoring out mi_locate_shlib out of mi_load_shlib 64481 - making mi_locate_shlib check for mi_spawn_id, like 64482 gdb_locate_shlib 64483 - using gdb_download_shlib and mi_locate_shlib in the test-cases. 64484 64485 Tested on x86_64-linux, with and without target board 64486 remote-gdbserver-on-localhost. 64487 644882023-03-07 Simon Marchi <simon.marchi@efficios.com> 64489 64490 gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.c 64491 When building with clang 16, I see: 64492 64493 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64494 info->prologue_type.load_args = 1; 64495 ^ ~ 64496 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64497 info->prologue_type.critical = 1; 64498 ^ ~ 64499 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64500 info->prologue_type.interrupt = 1; 64501 ^ ~ 64502 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64503 info->prologue_type.fp_sdcc = 1; 64504 ^ ~ 64505 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64506 info->prologue_type.fp_sdcc = 1; 64507 ^ ~ 64508 /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 64509 info->prologue_type.fp_sdcc = 1; 64510 ^ ~ 64511 64512 Fix that by using "unsigned int" as the bitfield's underlying type. 64513 64514 Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d 64515 645162023-03-07 Simon Marchi <simon.marchi@efficios.com> 64517 64518 gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h 64519 When building with clang 16, we get: 64520 64521 CXX gdb.o 64522 In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19: 64523 In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65: 64524 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion] 64525 integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type 64526 ^ 64527 64528 The error message does not make it clear in the context of which enum 64529 flag this fails (i.e. what is T in this context), but it doesn't really 64530 matter, we have similar warning/errors for many of them, if we let the 64531 build go through. 64532 64533 clang is right that the value -1 is invalid for the enum type we cast -1 64534 to. However, we do need this expression in order to select an integer 64535 type with the appropriate signedness. That is, with the same signedness 64536 as the underlying type of the enum. 64537 64538 I first wondered if that was really needed, if we couldn't use 64539 std::underlying_type for that. It turns out that the comment just above 64540 says: 64541 64542 /* Note that std::underlying_type<enum_type> is not what we want here, 64543 since that returns unsigned int even when the enum decays to signed 64544 int. */ 64545 64546 I was surprised, because std::is_signed<std::underlying_type<enum_type>> 64547 returns the right thing. So I tried replacing all this with 64548 std::underlying_type, see if that would work. Doing so causes some 64549 build failures in unittests/enum-flags-selftests.c: 64550 64551 CXX unittests/enum-flags-selftests.o 64552 /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s 64553 elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla 64554 gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte 64555 sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true': 64556 CHECK_VALID (true, int, true ? EF () : EF2 ()) 64557 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64558 /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID' 64559 CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR) 64560 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64561 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6' 64562 CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \ 64563 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64564 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT' 64565 static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, \ 64566 ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 64567 64568 This is a bit hard to decode, but basically enumerations have the 64569 following funny property that they decay into a signed int, even if 64570 their implicit underlying type is unsigned. This code: 64571 64572 enum A {}; 64573 enum B {}; 64574 64575 int main() { 64576 std::cout << std::is_signed<std::underlying_type<A>::type>::value 64577 << std::endl; 64578 std::cout << std::is_signed<std::underlying_type<B>::type>::value 64579 << std::endl; 64580 auto result = true ? A() : B(); 64581 std::cout << std::is_signed<decltype(result)>::value << std::endl; 64582 } 64583 64584 produces: 64585 64586 0 64587 0 64588 1 64589 64590 So, the "CHECK_VALID" above checks that this property works for enum flags the 64591 same way as it would if you were using their underlying enum types. And 64592 somehow, changing integer_for_size to use std::underlying_type breaks that. 64593 64594 Since the current code does what we want, and I don't see any way of doing it 64595 differently, ignore -Wenum-constexpr-conversion around it. 64596 64597 Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2 64598 645992023-03-07 John Baldwin <jhb@FreeBSD.org> 64600 64601 gdb.threads/next-bp-other-thread.c: Ensure child thread is started. 64602 Use a pthread_barrier to ensure the child thread is started before 64603 the main thread gets to the first breakpoint. 64604 64605 gdb.threads/execl.c: Ensure all threads are started before execl. 64606 Use a pthread_barrier to ensure all threads are started before 64607 proceeding to the breakpoint where info threads output is checked. 64608 646092023-03-07 John Baldwin <jhb@FreeBSD.org> 64610 64611 gdb.base/catch-syscall.exp: Remove some Linux-only assumptions. 64612 - Some OS's use a different syscall for exit(). For example, the 64613 BSD's use SYS_exit rather than SYS_exit_group. Update the C source 64614 file and the expect script to support SYS_exit as an alternative to 64615 SYS_exit_group. 64616 64617 - The cross-arch syscall number tests are all Linux-specific with 64618 hardcoded syscall numbers specific to Linux kernels. Skip these 64619 tests on non-Linux systems. FreeBSD kernels for example use the 64620 same system call numbers on all platforms, so the test is also not 64621 relevant on FreeBSD. 64622 646232023-03-07 John Baldwin <jhb@FreeBSD.org> 64624 64625 gdb.threads/multi-create: Double the existing stack size. 64626 Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the 64627 stack on FreeBSD rather than raising it causing non-main threads in 64628 the test program to overflow their stack and crash. Double the 64629 existing stack size rather than assuming that the initial stack size 64630 is PTHREAD_STACK_MIN. 64631 646322023-03-07 John Baldwin <jhb@FreeBSD.org> 64633 64634 amd64-linux-tdep: Don't treat fs_base and gs_base as system registers. 64635 These registers can be changed directly in userspace, and similar 64636 registers to support TLS on other architectures (tpidr* on ARM and 64637 AArch64, tp on RISC-V) are treated as general purpose registers. 64638 64639 Reviewed-By: Tom Tromey <tom@tromey.com> 64640 646412023-03-07 John Baldwin <jhb@FreeBSD.org> 64642 64643 gdb.arch/amd64-gs_base.exp: Support non-Linux. 64644 The orig_rax pseudo-register is Linux-specific and isn't relevant to 64645 this test. The fs_base and gs_base registers are also not treated as 64646 system registers in other OS ABIs. This allows the test to pass on 64647 FreeBSD. 64648 64649 Reviewed-By: Tom Tromey <tom@tromey.com> 64650 646512023-03-07 GDB Administrator <gdbadmin@sourceware.org> 64652 64653 Automatic date update in version.in 64654 646552023-03-06 Kévin Le Gouguec <legouguec@adacore.com> 64656 64657 gdb/python: Fix --disable-tui build 64658 As of 2023-02-13 "gdb/python: deallocate tui window factories at Python 64659 shut down" (9ae4519da90), a TUI-less build fails with: 64660 64661 $src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’: 64662 $src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared 64663 621 | gdbpy_tui_window_maker::invalidate_all (); 64664 | ^~~~~~~~~~~~~~~~~~~~~~ 64665 64666 Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an 64667 #ifdef guard in gdbpy_finalize_tui as well. 64668 646692023-03-06 Tom de Vries <tdevries@suse.de> 64670 64671 [gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuite 64672 Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests 64673 the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather 64674 than gdb.base. 64675 64676 Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to 64677 gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with 64678 recently added gdb.testsuite/gdb-caching-proc.exp. 64679 64680 Tested on x86_64-linux. 64681 64682 Reviewed-By: Tom Tromey <tom@tromey.com> 64683 646842023-03-06 Tom de Vries <tdevries@suse.de> 64685 64686 [gdb/testsuite] Allow args in gdb_caching_proc 64687 Test-case gdb.base/morestack.exp contains: 64688 ... 64689 require {have_compile_flag -fsplit-stack} 64690 ... 64691 and I want to cache the result of have_compile_flag. 64692 64693 Currently gdb_caching_proc doesn't allow args, so I could add: 64694 ... 64695 gdb_caching_proc have_compile_flag_fsplit_stack { 64696 return [have_compile_flag -fsplit-stack] 64697 } 64698 ... 64699 and then use that proc instead, but I find this cumbersome and 64700 maintenance-unfriendly. 64701 64702 Instead, allow args in a gdb_caching_proc, such that I can simply do: 64703 ... 64704 -proc have_compile_flag { flag } { 64705 +gdb_caching_proc have_compile_flag { flag } { 64706 ... 64707 64708 Note that gdb_caching_procs with args do not work with the 64709 gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped. 64710 64711 Tested on x86_64-linux. 64712 64713 Reviewed-By: Tom Tromey <tom@tromey.com> 64714 647152023-03-06 Tom de Vries <tdevries@suse.de> 64716 64717 [gdb/testsuite] Use regular proc syntax for gdb_caching_proc 64718 A regular tcl proc with no args looks like: 64719 ... 64720 proc foo {} { 64721 return 1 64722 } 64723 ... 64724 but a gdb_caching_proc deviates from that syntax by dropping the explicit no 64725 args bit: 64726 ... 64727 gdb_caching_proc foo { 64728 return 1 64729 } 64730 ... 64731 64732 Make the gdb_caching_proc use the same syntax as regular procs, such that we 64733 have instead: 64734 ... 64735 gdb_caching_proc foo {} { 64736 return 1 64737 } 64738 ... 64739 64740 Tested on x86_64-linux. 64741 64742 Reviewed-By: Tom Tromey <tom@tromey.com> 64743 647442023-03-06 Tom de Vries <tdevries@suse.de> 64745 64746 [gdb/testsuite] Add gdb.testsuite/gdb-caching-proc.exp 64747 Add test-case gdb.testsuite/gdb-caching-proc.exp that excercises 64748 gdb_caching_proc. 64749 64750 Tested on x86_64-linux. 64751 64752 Reviewed-By: Tom Tromey <tom@tromey.com> 64753 647542023-03-06 Tom Tromey <tromey@adacore.com> 64755 64756 Fix DAP stackTrace through frames without debuginfo 64757 The DAP stackTrace implementation did not fully account for frames 64758 without debuginfo. Attemping this would yield a result like: 64759 64760 {"request_seq": 5, "type": "response", "command": "stackTrace", "success": false, "message": "'NoneType' object has no attribute 'filename'", "seq": 11} 64761 64762 This patch fixes the problem by adding another check for None. 64763 647642023-03-06 Tom Tromey <tromey@adacore.com> 64765 64766 Remove exception_catchpoint::resources_needed 64767 exception_catchpoint::resources_needed has a FIXME comment that I 64768 think makes this method obsolete. Also, I note that similar 64769 catchpoints, for example Ada catchpoints, don't have this method. 64770 This patch removes the method. Regression tested on x86-64 Fedora 36. 64771 647722023-03-06 Tom Tromey <tromey@adacore.com> 64773 64774 Remove two more files in gdb "distclean" 64775 The recent work to have gdb link via libtool means that there are a 64776 couple more generated files in the build directory that should be 64777 removed by "distclean". 64778 64779 Note that gdb can't really fully implement distclean due to the desire 64780 to put certain generated files into the distribution. Still, it can 64781 get pretty close. 64782 647832023-03-06 Alan Modra <amodra@gmail.com> 64784 64785 macho null dereference read 64786 The main problem here was not returning -1 from canonicalize_symtab on 64787 an error, leaving the vector of relocs only partly initialised and one 64788 with a null sym_ptr_ptr. 64789 64790 * mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error, 64791 not 0. 64792 (bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to 64793 undefined section sym. 64794 647952023-03-06 Alan Modra <amodra@gmail.com> 64796 64797 PR30198, Assertion and segfault when linking x86_64 elf and coff 64798 PR 30198 64799 * coff-x86_64.c (coff_amd64_reloc): Set *error_message when 64800 returning bfd_reloc_dangerous. Also check that __ImageBase is 64801 defined before accessing h->u.def. 64802 64803 More _bfd_ecoff_locate_line sanity checks 64804 * ecofflink.c (mk_fdrtab): Discard fdr with negative cpd. 64805 (lookup_line): Sanity check fdr cbLineOffset and cbLine. 64806 Sanity check pdr cbLineOffset. 64807 648082023-03-06 Alan Modra <amodra@gmail.com> 64809 64810 Correct odd loop in ecoff lookup_line 64811 I can't see why this really odd looking loop was written the way it 64812 was in commit a877f5917f90, but it can result in a buffer overrun. 64813 64814 * ecofflink.c (lookup_line): Don't swap in pdr at pdr_end. 64815 648162023-03-06 Alan Modra <amodra@gmail.com> 64817 64818 Downgrade objdump fatal errors to non-fatal 64819 * objdump.c (slurp_symtab): Replace bfd_fatal calls with calls 64820 to my_bfd_nonfatal. 64821 (slurp_dynamic_symtab, disassemble_section): Likewise. 64822 (disassemble_data): Replace fatal call with non_fatal call, and 64823 set exit_status. Don't error on non-existent dynamic relocs. 64824 Don't call bfd_fatal on bfd_canonicalize_dynamic_reloc error. 64825 (dump_ctf, dump_section_sframe): Replace bfd_fatal calls with 64826 calls to my_bfd_nonfatal and clean up memory. 64827 (dump_relocs_in_section): Don't call bfd_fatal on errors. 64828 (dump_dynamic_relocs): Likewise. 64829 (display_any_bfd): Make archive nesting too depp non_fatal. 64830 64831 Downgrade addr2line fatal errors to non-fatal 64832 * addr2line.c (slurp_symtab): Don't exit on errors. 64833 (process_file): Likewise. 64834 648352023-03-06 Alan Modra <amodra@gmail.com> 64836 64837 Downgrade nm fatal errors to non-fatal 64838 Many of the fatal errors in nm ought to be recoverable. This patch 64839 downgrades most of them. The ones that are left are most likely due 64840 to memory allocation failures. 64841 64842 * nm.c (print_symdef_entry): Don't bomb with a fatal error 64843 on a corrupted archive symbol table. 64844 (filter_symbols): Silently omit symbols that return NULL 64845 from bfd_minisymbol_to_symbol rather than giving a fatal 64846 error. 64847 (display_rel_file): Don't give a fatal error on 64848 bfd_read_minisymbols returning an error, or on not being able 64849 to read dynamic symbols for synth syms. 64850 (display_archive): Downgrade bfd_openr_next_archived_file 64851 error. 64852 (display_file): Don't bomb on a bfd_close failure. 64853 648542023-03-06 Alan Modra <amodra@gmail.com> 64855 64856 Move nm.c cached line number info to bfd usrdata 64857 Replace the static variables used by nm to cache line number info 64858 with a struct attached to the bfd. Cleaner, and it avoids any concern 64859 that lineno_cache_bfd is somehow left pointing at memory for a closed 64860 bfd and that memory is later reused for another bfd, not that I think 64861 this is possible. Also don't bomb via bfd_fatal on errors getting 64862 the line number info, just omit the line numbers. 64863 64864 * nm.c (struct lineno_cache): Rename from get_relocs_info. 64865 Add symcount. 64866 (lineno_cache_bfd, lineno_cache_rel_bfd): Delete. 64867 (get_relocs): Adjust for struct rename. Don't call bfd_fatal 64868 on errors. 64869 (free_lineno_cache): New function. 64870 (print_symbol): Use lineno_cache in place of statics. Don't 64871 call bfd_fatal on errors reading symbols, just omit the line 64872 info. 64873 (display_archive, display_file): Call free_lineno_cache. 64874 648752023-03-06 Alan Modra <amodra@gmail.com> 64876 64877 Correct objdump command line error handling 64878 bfd_nonfatal is used when a bfd error is to be printed. That's not 64879 the case for command line errors. 64880 64881 * objdump.c (nonfatal): Rename to my_bfd_nonfatal. 64882 (main): Use non_fatal and call usage on unrecognized arg errors. 64883 Don't set exit_status when calling usage. 64884 648852023-03-06 GDB Administrator <gdbadmin@sourceware.org> 64886 64887 Automatic date update in version.in 64888 648892023-03-05 GDB Administrator <gdbadmin@sourceware.org> 64890 64891 Automatic date update in version.in 64892 648932023-03-04 GDB Administrator <gdbadmin@sourceware.org> 64894 64895 Automatic date update in version.in 64896 648972023-03-03 Simon Marchi <simon.marchi@efficios.com> 64898 64899 gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO` 64900 When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash, 64901 rather than bash, I get: 64902 64903 c&^M 64904 Continuing.^M 64905 (gdb) sh: 1: kill: Illegal option -S^M 64906 ^M 64907 Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M 64908 23 return 0;^M 64909 FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout) 64910 64911 This is because it uses the kill command built-in the dash shell, and 64912 using the SIG prefix with kill does not work with dash's kill. The 64913 difference is listed in the documentation for bash's POSIX-correct mode 64914 [1]: 64915 64916 The kill builtin does not accept signal names with a ‘SIG’ prefix. 64917 64918 Replace SIGINT with INT in that test. 64919 64920 By grepping, I found two other instances (gdb.base/sigwinch-notty.exp 64921 and gdb.threads/detach-step-over.exp). Those were not problematic on my 64922 system though. Since they are done through remote_exec, they don't go 64923 through the shell and therefore invoke /bin/kill. On my Arch Linux, 64924 it's: 64925 64926 $ /bin/kill --version 64927 kill from util-linux 2.38.1 (with: sigqueue, pidfd) 64928 64929 and on my Ubuntu: 64930 64931 $ /bin/kill --version 64932 kill from procps-ng 3.3.17 64933 64934 These two implementations accept "-SIGINT". But according to the POSIX 64935 spec [2], the kill utility should recognize the signal name without the 64936 SIG prefix (if it recognizes them with the SIG prefix, it's an 64937 extension): 64938 64939 -s signal_name 64940 Specify the signal to send, using one of the symbolic names defined 64941 in the <signal.h> header. Values of signal_name shall be recognized 64942 in a case-independent fashion, without the SIG prefix. In addition, 64943 the symbolic name 0 shall be recognized, representing the signal 64944 value zero. The corresponding signal shall be sent instead of SIGTERM. 64945 -signal_name 64946 [XSI] [Option Start] 64947 Equivalent to -s signal_name. [Option End] 64948 64949 So, just in case some /bin/kill implementation happens to not recognize 64950 the SIG prefixes, change these two other calls to remove the SIG 64951 prefix. 64952 64953 [1] https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html 64954 [2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html 64955 64956 Change-Id: I81ccedd6c9428ab63b9261813f1905a18941f8da 64957 Reviewed-By: Tom Tromey <tom@tromey.com> 64958 649592023-03-03 Tom de Vries <tdevries@suse.de> 64960 64961 [gdb/testsuite] Use set always-read-ctf on instead of --strip-debug 64962 Use "set always-read-ctf on" instead of --strip-debug in the ctf test-cases. 64963 64964 Tested on x86_64-linux. 64965 649662023-03-03 Tom Tromey <tromey@adacore.com> 64967 64968 Update expected results in long_long.exp 64969 Simon pointed out that the recent patch to add half-float support to 64970 'x/f' caused a couple of regressions in long_long.exp. This patch 64971 fixes these by updating the expected results. 64972 649732023-03-03 Nick Clifton <nickc@redhat.com> 64974 64975 Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant. 64976 PR 30193 * ldgram.y (ASCII): Fail if the size is not a constant. 64977 649782023-03-03 Andrew Burgess <aburgess@redhat.com> 64979 64980 gdb/python: replace strlen call with std::string::size call 64981 Small cleanup to use std::string::size instead of calling strlen on 64982 the result of std::string::c_str. 64983 64984 Should be no user visible changes after this call. 64985 649862023-03-03 Jan Beulich <jbeulich@suse.com> 64987 64988 x86: use swap_2_operands() in build_vex_prefix() 64989 Open-coding part of what may eventually be needed is somewhat risky. 64990 Let's use the function we have, taking care of all pieces of data which 64991 may need swapping, no matter that 64992 - right now i.flags[] and i.reloc[] aren't relevant here (yet), 64993 - EVEX masking and embedded broadcast aren't applicable. 64994 64995 x86: drop redundant calculation of EVEX broadcast size 64996 In commit a5748e0d8c50 ("x86/Intel: allow MASM representation of 64997 embedded broadcast") I replaced the calculation of i.broadcast.bytes in 64998 check_VecOperands() not paying attention to the immediately following 64999 call to get_broadcast_bytes() doing exactly that (again) first thing. 65000 650012023-03-03 Jan Beulich <jbeulich@suse.com> 65002 65003 gas: default .debug section compression method adjustments 65004 While commit b0c295e1b8d0 ("add --enable-default-compressed-debug- 65005 sections-algorithm configure option") adjusted flag_compress_debug's 65006 initializer, it didn't alter the default used when the command line 65007 option was specified with an (optional!) argument. This rendered help 65008 text inconsistent with actual behavior in certain configurations. 65009 65010 As to help text - the default reported there clearly shouldn't be 65011 affected by a possible earlier --compress-debug-sections= option, so 65012 flag_compress_debug can't be used when emitting usage information. 65013 650142023-03-03 Jan Beulich <jbeulich@suse.com> 65015 65016 x86: avoid .byte in testcases where possible 65017 In the course of using the upcoming .insn directive to eliminate various 65018 .byte uses in testcases I've come across these, which needlessly use 65019 more .byte than necessary even without the availability of .insn. 65020 650212023-03-03 Alan Modra <amodra@gmail.com> 65022 65023 Tidy type handling in binutils/rdcoff.c 65024 There isn't really any good reason for code in rdcoff.c to distinguish 65025 between "basic" types and any other type. This patch dispenses with 65026 the array reserved for basic types and instead handles all types using 65027 coff_get_slot, simplifying the code. 65028 65029 * rdcoff.c (struct coff_types, coff_slots): Merge. Delete 65030 coff_slots. 65031 (T_MAX): Delete. 65032 (parse_coff_base_type): Use coff_get_slot to store baseic types. 65033 (coff_get_slot, parse_coff_type, parse_coff_base_type), 65034 (parse_coff_struct_type, parse_coff_enum_type), 65035 (parse_coff_symbol, parse_coff): Pass types as coff_types**. 65036 650372023-03-03 Alan Modra <amodra@gmail.com> 65038 65039 binutils coff type list 65040 As for commit 72d225ef9cc7, handle type numbers starting anywhere. 65041 65042 PR 17512 65043 * rdcoff.c (struct coff_slots): Add base_index. 65044 (coff_get_slot): Delete pr17512 excessively large slot check. 65045 Don't allocate entire array from 0 to type number, allocate a 65046 sparse array. 65047 650482023-03-03 GDB Administrator <gdbadmin@sourceware.org> 65049 65050 Automatic date update in version.in 65051 650522023-03-02 Simon Marchi <simon.marchi@efficios.com> 65053 65054 gdb: fix -Wmaybe-uninitialized warning in value.c 65055 Since commit 11470e70ea0d ("gdb: store internalvars in an std::map"), bulding 65056 with -O2, with g++ 11.3.0 on Ubuntu 22.04, I see: 65057 65058 CXX value.o 65059 In constructor ‘internalvar::internalvar(internalvar&&)’, 65060 inlined from ‘constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const char*&; _U2 = internalvar; typename std::enable_if<(std::_PCC<true, _T1, _T2>::_MoveConstructiblePair<_U1, _U2>() && std::_PCC<true, _T1, _T2>::_ImplicitlyMoveConvertiblePair<_U1, _U2>()), bool>::type <anonymous> = true; _T1 = const char*; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:353:35, 65061 inlined from ‘constexpr std::pair<typename std::__strip_reference_wrapper<typename std::decay<_Tp>::type>::__type, typename std::__strip_reference_wrapper<typename std::decay<_Tp2>::type>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = const char*&; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:572:72, 65062 inlined from ‘internalvar* create_internalvar(const char*)’ at /home/smarchi/src/binutils-gdb/gdb/value.c:1933:52: 65063 /home/smarchi/src/binutils-gdb/gdb/value.c:1831:8: warning: ‘<unnamed>.internalvar::u’ may be used uninitialized [-Wmaybe-uninitialized] 65064 1831 | struct internalvar 65065 | ^~~~~~~~~~~ 65066 /home/smarchi/src/binutils-gdb/gdb/value.c: In function ‘internalvar* create_internalvar(const char*)’: 65067 /home/smarchi/src/binutils-gdb/gdb/value.c:1933:76: note: ‘<anonymous>’ declared here 65068 1933 | auto pair = internalvars.emplace (std::make_pair (name, internalvar (name))); 65069 | ^ 65070 65071 This is because the union field internalvar::u is not initialized when 65072 constructing the temporary internalvar object above. That object is then used 65073 for move-construction, and the (implicit) move constructor copies the 65074 uninitialized bytes of field u over from the temporary object to the new 65075 internalvar object. The compiler therefore complains that we use uninitialized 65076 bytes. I don't think it's really a problem, because the internalvar object is 65077 in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is 65078 irrelevant. Still, mute the warning by default-initializing the union. 65079 65080 Change-Id: I70c392842f35255f50d8e63f4099cb6685366fb7 65081 Reviewed-By: Tom Tromey <tom@tromey.com> 65082 650832023-03-02 Tom Tromey <tromey@adacore.com> 65084 65085 Handle half-float in 'x' command 65086 Using 'x/hf' should print bytes as float16, but instead it currently 65087 prints as an integer. I tracked this down to a missing case in 65088 float_type_from_length. 65089 65090 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30161 65091 Approved-By: Simon Marchi <simon.marchi@efficios.com> 65092 650932023-03-02 Tom Tromey <tromey@adacore.com> 65094 65095 Fix some value comments 65096 I noticed a very stale comment in valarith.c. This patch fixes a few 65097 comments in this area. 65098 65099 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 65100 651012023-03-02 Hui Li <lihui@loongson.cn> 65102 65103 gdb: LoongArch: Add support for static data member in struct 65104 As described in C++ reference [1], static data members are not part 65105 of objects of a given class type. Modified compute_struct_member () 65106 to ignore static data member so that we can get the expected result. 65107 65108 loongson@linux:~$ cat test.c 65109 #include<stdio.h> 65110 struct struct_01 { static unsigned a; float b;}; 65111 unsigned struct_01::a = 66; 65112 struct struct_01 struct_01_val = { 99.00 }; 65113 int check_arg_struct(struct struct_01 arg) 65114 { 65115 printf("arg.a = %d\n", arg.a); 65116 printf("arg.b = %f\n", arg.b); 65117 return 0; 65118 } 65119 int main() 65120 { 65121 check_arg_struct(struct_01_val); 65122 return 0; 65123 } 65124 loongson@linux:~$ g++ -g test.c -o test++ 65125 loongson@linux:~$ gdb test++ 65126 65127 Without this patch: 65128 ... 65129 (gdb) start 65130 ... 65131 (gdb) p check_arg_struct(struct_01_val) 65132 arg.a = 66 65133 arg.b = 0.000000 65134 $1 = 0 65135 65136 With this patch: 65137 ... 65138 (gdb) start 65139 ... 65140 (gdb) p check_arg_struct(struct_01_val) 65141 arg.a = 66 65142 arg.b = 99.000000 65143 $1 = 0 65144 65145 [1] https://learn.microsoft.com/en-us/cpp/cpp/static-members-cpp?view=msvc-170 65146 65147 Reviewed-By: Tom Tromey <tom@tromey.com> 65148 651492023-03-02 Alan Modra <amodra@gmail.com> 65150 65151 Don't write zeros to a gap in the output file 65152 Writing out zeros is counterproductive if a file system supports 65153 sparse files. A very large gap need not take much actual disk space, 65154 but it usually will if zeros are written. 65155 65156 memory_bseek also supports not writing out zeros in a gap. 65157 65158 * elf.c (write_zeros): Delete. 65159 (assign_file_positions_for_load_sections): Don't call write_zeros. 65160 Comment. 65161 651622023-03-02 Tom de Vries <tdevries@suse.de> 65163 65164 [gdb/symtab] Add set/show always-read-ctf on/off 65165 [ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add 65166 maint set symbol-read-order", submitted here ( 65167 https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html 65168 ). ] 65169 65170 With the test-case included in this patch, we run into: 65171 ... 65172 (gdb) file dwarf2-and-ctf 65173 (gdb) print var_ctf^M 65174 'var_ctf' has unknown type; cast it to its declared type^M 65175 ... 65176 65177 The problem is that the executable contains both ctf and dwarf2, so the ctf 65178 info (which contains the type information about var_ctf) is ignored. 65179 65180 GDB has support for handling multiple debug formats, but the common use case 65181 for ctf is to be used when dwarf2 is not present, and gdb reflects that, 65182 assuming that by reading ctf in addition there won't be any extra information, 65183 so it's not worth the additional cycles and memory. 65184 65185 Add a new command "set/show always-read-ctf on/off", that when on forces 65186 unconditional reading of ctf, allowing us to do: 65187 ... 65188 (gdb) set always-read-ctf on 65189 (gdb) file dwarf2-and-ctf 65190 (gdb) print var_ctf^M 65191 $2 = 2^M 65192 ... 65193 65194 The setting is off by default, preserving current behaviour. 65195 65196 A bit of background on the relevance of reading order: the formats have a 65197 priority relationship between them, where reading earlier means lower 65198 priority. By reading the format with the most detail last, we ensure it has 65199 the highest priority, which makes sure that in case there is overlapping info, 65200 the most detailed info is found. This explains the current reading order of 65201 mdebug, stabs and dwarf2. 65202 65203 Add the unconditional reading of ctf before dwarf2, because it's less detailed 65204 than dwarf2. The conditional reading of ctf is still done after the attempt to 65205 read dwarf2, necessarily so because we only know whether there's dwarf2 after 65206 we've tried to read it. 65207 65208 The new command allow us to replace uses of -Wl,--strip-debug added in commit 65209 908a926ec4e ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by 65210 uses of "set always-read-ctf on", but I've left that for another commit. 65211 65212 Tested on x86_64-linux. 65213 65214 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 65215 Reviewed-By: Tom Tromey <tom@tromey.com> 65216 652172023-03-02 Simon Marchi <simon.marchi@efficios.com> 65218 65219 gdb: update some copyright years (2022 -> 2023) 65220 The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong, 65221 they end in 2022 instead of 2023. I suppose because I posted (or at 65222 least prepared) the patches in 2022 but merged them in 2023, and forgot 65223 to update the year. I found a bunch of other files that are in the same 65224 situation. Fix them all up. 65225 65226 Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10 65227 Reviewed-By: Tom Tromey <tom@tromey.com> 65228 652292023-03-02 GDB Administrator <gdbadmin@sourceware.org> 65230 65231 Automatic date update in version.in 65232 652332023-03-01 Tom Tromey <tromey@adacore.com> 65234 65235 Use const for dwarf2_property_baton 65236 Once a baton is stored in a struct type, it doesn't make sense to 65237 modify it. This patch constifies the API. 65238 65239 Approved-By: Simon Marchi <simon.marchi@efficios.com> 65240 652412023-03-01 Tom Tromey <tromey@adacore.com> 65242 65243 Make gdb property batons type-safe 65244 gdbtypes treats dynamic property batons as 'void *', but in actuality 65245 the only users all use dwarf2_property_baton. This patch changes this 65246 code to be type-safe. If a new type is needed here, it seems like 65247 that too could be done in a type-safe way. 65248 65249 Approved-By: Simon Marchi <simon.marchi@efficios.com> 65250 652512023-03-01 Alan Modra <amodra@gmail.com> 65252 65253 More bounds checking in macro_expand 65254 * macro.c (macro_expand): Ensure input string buffer is not 65255 read past end. 65256 652572023-03-01 Alan Modra <amodra@gmail.com> 65258 65259 Using .mri in assembly 65260 Changing mri mode between macro definition and use isn't good. This 65261 .macro x 65262 .endm 65263 .mri 1 65264 x 65265 leads to a segfault. Fixed with the following patch, but I suppose 65266 what should really happen is that macros be marked as being mri mode 65267 when defined, and that determine whether the magic NARG parameter be 65268 supplied at expansion. Nobody has complained about this in 30 years 65269 so I'm not inclined to change gas behaviour to that extent. 65270 65271 * macro.c (macro_expand): Don't segfault in mri mode if NARG 65272 formal isn't found. 65273 652742023-03-01 Tom Tromey <tromey@adacore.com> 65275 65276 Fix type of check_valid_shift_count parameter 65277 check_valid_shift_count has an 'int' parameter that really should be 65278 an enum exp_opcode. This patch makes the change. Tested by 65279 rebuilding. 65280 652812023-03-01 Simon Marchi <simon.marchi@efficios.com> 65282 65283 gdb: fix a whitespace issue in solib-rocm.c 65284 Change-Id: I9cd236eaf161fe3a1abf0d212efca47a7149e021 65285 652862023-03-01 Nick Clifton <nickc@redhat.com> 65287 65288 Fix typo with my email address 65289 652902023-03-01 Tom Tromey <tom@tromey.com> 65291 65292 Fix btrace regression 65293 Tom de Vries pointed out that my earlier patch: 65294 65295 commit 873a185be258ad2552b9579005852815b4da5baf 65296 Date: Fri Dec 16 07:56:57 2022 -0700 65297 65298 Don't use struct buffer in handle_qxfer_btrace 65299 65300 regressed gdb.btrace/reconnect.exp. I didn't notice this because I 65301 did not have libipt installed. 65302 65303 This patch fixes the bug. 65304 65305 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30169 65306 Tested-By: Bruno Larsen <blarsen@redhat.com> 65307 653082023-03-01 Tom de Vries <tdevries@suse.de> 65309 65310 [gdb/testsuite] Add another xfail case in gdb.python/py-record-btrace.exp 65311 I ran into: 65312 ... 65313 (gdb) PASS: gdb.python/py-record-btrace.exp: function call: \ 65314 python print(c.prev) 65315 python print(c == c.next.prev)^M 65316 Traceback (most recent call last):^M 65317 File "<string>", line 1, in <module>^M 65318 AttributeError: 'NoneType' object has no attribute 'prev'^M 65319 Error while executing Python code.^M 65320 (gdb) FAIL: gdb.python/py-record-btrace.exp: function call: \ 65321 python print(c == c.next.prev) 65322 ... 65323 due to having only 4 insn instead of 100: 65324 ... 65325 python print(len(insn))^M 65326 4^M 65327 ... 65328 65329 This could be caused by the same hw bug as we already have an xfail for, so 65330 expand the xfail matching. 65331 65332 Tested on x86_64-linux. 65333 65334 PR testsuite/30185 65335 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30185 65336 65337 Approved-By: Markus T. Metzger <markus.t.metzger@intel.com> 65338 653392023-03-01 Alan Modra <amodra@gmail.com> 65340 65341 Catch overflow in gas s_space 65342 Also fix an error introduced in 1998 in reporting a zero count for 65343 negative counts. 65344 65345 * read.c (s_space): Use unsigned multiply, and catch overflow. 65346 Correct order of tests for invalid repeat counts. Ensure 65347 ignored directives don't affect mri_pending_align. 65348 653492023-03-01 Alan Modra <amodra@gmail.com> 65350 65351 gas s_fill caused internal error in frag_new 65352 Fix an internal error after "non-constant fill count for absolute 65353 section". 65354 65355 * read.c (s_fill): Don't create frags after errors. 65356 653572023-03-01 Alan Modra <amodra@gmail.com> 65358 65359 Memory leak in gas do_repeat 65360 * read.c (do_repeat): Free sb on error path. 65361 653622023-03-01 GDB Administrator <gdbadmin@sourceware.org> 65363 65364 Automatic date update in version.in 65365 653662023-02-28 Simon Marchi <simon.marchi@efficios.com> 65367 65368 gdb: add HtabPrinter to gdb-gdb.py.in 65369 When debugging GDB, I find it a bit tedious to inspect htab_t objects. 65370 It is possible to find the entries by poking at the fields, but it's 65371 annoying to do each time. I think a pretty printer would help. Add a 65372 basic one to gdb-gdb.py. 65373 65374 The pretty printer advertises itself as "array-like", and the result 65375 looks like: 65376 65377 (top-gdb) p bfcache 65378 $3 = htab_t with 3 elements = {0x6210003252a0, 0x62100032caa0, 0x62100033baa0} 65379 65380 The htab_t itself doesn't know about the type of pointed objects. But 65381 it's easy enough to cast the addresses to the right type to use them: 65382 65383 (top-gdb) print *((btrace_frame_cache *) 0x6210003252a0) 65384 $6 = {tp = 0x61700002ed80, frame = 0x6210003251e0, bfun = 0x62000000b390} 65385 65386 Change-Id: Ia692e3555fe7a117b7ec087840246b1260a704c6 65387 Reviewed-By: Tom Tromey <tom@tromey.com> 65388 653892023-02-28 Tom de Vries <tdevries@suse.de> 65390 65391 [gdb/testsuite] Fix gdb.python/py-breakpoint.exp timeouts 65392 On powerpc64le-linux, I run into two timeouts: 65393 ... 65394 FAIL: gdb.python/py-breakpoint.exp: test_watchpoints: \ 65395 Test watchpoint write (timeout) 65396 FAIL: gdb.python/py-breakpoint.exp: test_bkpt_internal: \ 65397 Test watchpoint write (timeout) 65398 ... 65399 65400 In this case, hw watchpoints are not supported, and using sw watchpoints 65401 is slow. 65402 65403 Most of the time is spent in handling a try-catch, which triggers a malloc. I 65404 think this bit is more relevant for the "catch throw" part of the test-case, 65405 so fix the timeouts by setting the watchpoints after the try-catch. 65406 65407 Tested on x86_64-linux and powerpc64le-linux. 65408 654092023-02-28 Tom Tromey <tromey@adacore.com> 65410 65411 Remove value_in 65412 value_in is unused. From git log, it seems to have been part of the 65413 Chill language, which was removed from gdb eons ago. This patch 65414 removes the function. Tested by rebuilding. 65415 654162023-02-28 Tom de Vries <tdevries@suse.de> 65417 65418 [gdb/testsuite] Fix gdb.rust/watch.exp on ppc64le 65419 On x86_64-linux, I have: 65420 ... 65421 (gdb) watch -location y^M 65422 Hardware watchpoint 2: -location y^M 65423 (gdb) PASS: gdb.rust/watch.exp: watch -location y 65424 ... 65425 but on powerpc64le-linux, I run into: 65426 ... 65427 (gdb) watch -location y^M 65428 Watchpoint 2: -location y^M 65429 (gdb) FAIL: gdb.rust/watch.exp: watch -location y 65430 ... 65431 due to the regexp matching "Hardware watchpoint" but not "Watchpoint": 65432 ... 65433 gdb_test "watch -location y" ".*watchpoint .* -location .*" 65434 ... 65435 65436 Fix this by making the regexp less restrictive. 65437 65438 Tested on x86_64-linux and powerpc64le-linux. 65439 654402023-02-28 Andrew Burgess <aburgess@redhat.com> 65441 65442 gdb: fix mi breakpoint-deleted notifications for thread-specific b/p 65443 Background 65444 ---------- 65445 65446 When a thread-specific breakpoint is deleted as a result of the 65447 specific thread exiting the function remove_threaded_breakpoints is 65448 called which sets the disposition of the breakpoint to 65449 disp_del_at_next_stop and sets the breakpoint number to 0. Setting 65450 the breakpoint number to zero has the effect of hiding the breakpoint 65451 from the user. We also print a message indicating that the breakpoint 65452 has been deleted. 65453 65454 It was brought to my attention during a review of another patch[1] 65455 that setting a breakpoints number to zero will suppress the MI 65456 breakpoint-deleted notification for that breakpoint, and indeed, this 65457 can be seen to be true, in delete_breakpoint, if the breakpoint number 65458 is zero, then GDB will not notify the breakpoint_deleted observer. 65459 65460 It seems wrong that a user created, thread-specific breakpoint, will 65461 have a =breakpoint-created notification, but will not have a 65462 =breakpoint-deleted notification. I suspect that this is a bug. 65463 65464 [1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html 65465 65466 The First Problem 65467 ----------------- 65468 65469 During my initial testing I wanted to see how GDB handled the 65470 breakpoint after it's number was set to zero. To do this I created 65471 the testcase gdb.threads/thread-bp-deleted.exp. This test creates a 65472 worker thread, which immediately exits. After the worker thread has 65473 exited the main thread spins in a loop. 65474 65475 In GDB I break once the worker thread has been created and place a 65476 thread-specific breakpoint, then use 'continue&' to resume the 65477 inferior in non-stop mode. The worker thread then exits, but the main 65478 thread never stops - instead it sits in the spin. I then tried to use 65479 'maint info breakpoints' to see what GDB thought of the 65480 thread-specific breakpoint. 65481 65482 Unfortunately, GDB crashed like this: 65483 65484 (gdb) continue& 65485 Continuing. 65486 (gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited] 65487 Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. 65488 maint info breakpoints 65489 ... snip some output ... 65490 65491 Fatal signal: Segmentation fault 65492 ----- Backtrace ----- 65493 0x5ffb62 gdb_internal_backtrace_1 65494 ../../src/gdb/bt-utils.c:122 65495 0x5ffc05 _Z22gdb_internal_backtracev 65496 ../../src/gdb/bt-utils.c:168 65497 0x89965e handle_fatal_signal 65498 ../../src/gdb/event-top.c:964 65499 0x8997ca handle_sigsegv 65500 ../../src/gdb/event-top.c:1037 65501 0x7f96f5971b1f ??? 65502 /usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 65503 0xe602b0 _Z15print_thread_idP11thread_info 65504 ../../src/gdb/thread.c:1439 65505 0x5b3d05 print_one_breakpoint_location 65506 ../../src/gdb/breakpoint.c:6542 65507 0x5b462e print_one_breakpoint 65508 ../../src/gdb/breakpoint.c:6702 65509 0x5b5354 breakpoint_1 65510 ../../src/gdb/breakpoint.c:6924 65511 0x5b58b8 maintenance_info_breakpoints 65512 ../../src/gdb/breakpoint.c:7009 65513 ... etc ... 65514 65515 As the thread-specific breakpoint is set to disp_del_at_next_stop, and 65516 GDB hasn't stopped yet, then the breakpoint still exists in the global 65517 breakpoint list. 65518 65519 The breakpoint will not show in 'info breakpoints' as its number is 65520 zero, but it will show in 'maint info breakpoints'. 65521 65522 As GDB prints the breakpoint, the thread-id for the breakpoint is 65523 printed as part of the 'stop only in thread ...' line. Printing the 65524 thread-id involves calling find_thread_global_id to convert the global 65525 thread-id into a thread_info*. Then calling print_thread_id to 65526 convert the thread_info* into a string. 65527 65528 The problem is that find_thread_global_id returns nullptr as the 65529 thread for the thread-specific breakpoint has exited. The 65530 print_thread_id assumes it will be passed a non-nullptr. As a result 65531 GDB crashes. 65532 65533 In this commit I've added an assert to print_thread_id (gdb/thread.c) 65534 to check that the pointed passed in is not nullptr. This assert would 65535 have triggered in the above case before GDB crashed. 65536 65537 MI Notifications: The Dangers Of Changing A Breakpoint's Number 65538 --------------------------------------------------------------- 65539 65540 Currently the delete_breakpoint function doesn't trigger the 65541 breakpoint_deleted observer for any breakpoint with the number zero. 65542 65543 There is a comment explaining why this is the case in the code; it's 65544 something about watchpoints. But I did consider just removing the 'is 65545 the number zero' guard and always triggering the breakpoint_deleted 65546 observer, figuring that I'd then fix the watchpoint issue some other 65547 way. 65548 65549 But I realised this wasn't going to be good enough. When the MI 65550 notification was delivered the number would be zero, so any frontend 65551 parsing the notifications would not be able to match 65552 =breakpoint-deleted notification to the earlier =breakpoint-created 65553 notification. 65554 65555 What this means is that, at the point the breakpoint_deleted observer 65556 is called, the breakpoint's number must be correct. 65557 65558 MI Notifications: The Dangers Of Delaying Deletion 65559 -------------------------------------------------- 65560 65561 The test I used to expose the above crash also brought another problem 65562 to my attention. In the above test we used 'continue&' to resume, 65563 after which a thread exited, but the inferior didn't stop. Recreating 65564 the same test in the MI looks like this: 65565 65566 -break-insert -p 2 main 65567 ^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...} 65568 (gdb) 65569 -exec-continue 65570 ^running 65571 *running,thread-id="all" 65572 (gdb) 65573 ~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n" 65574 =thread-exited,id="2",group-id="i1" 65575 ~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n" 65576 65577 At this point the we have a single thread left, which is still 65578 running: 65579 65580 -thread-info 65581 ^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1" 65582 (gdb) 65583 65584 Notice that we got the =thread-exited notification from GDB as soon as 65585 the thread exited. We also saw the CLI line from GDB, the line 65586 explaining that breakpoint 2 was deleted. But, as expected, we didn't 65587 see the =breakpoint-deleted notification. 65588 65589 I say "as expected" because the number was set to zero. But, even if 65590 the number was not set to zero we still wouldn't see the 65591 notification. The MI notification is driven by the breakpoint_deleted 65592 observer, which is only called when we actually delete the breakpoint, 65593 which is only done the next time GDB stops. 65594 65595 Now, maybe this is fine. The notification is delivered a little 65596 late. But remember, by setting the number to zero the breakpoint will 65597 be hidden from the user, for example, the breakpoint is removed from 65598 the MI's -break-info command output. 65599 65600 This means that GDB is in a position where the breakpoint doesn't show 65601 up in the breakpoint table, but a =breakpoint-deleted notification has 65602 not yet been sent out. This doesn't seem right to me. 65603 65604 What this means is that, when the thread exits, we should immediately 65605 be sending out the =breakpoint-deleted notification. We should not 65606 wait for GDB to next stop before sending the notification. 65607 65608 The Solution 65609 ------------ 65610 65611 My proposed solution is this; in remove_threaded_breakpoints, instead 65612 of setting the disposition to disp_del_at_next_stop and setting the 65613 number to zero, we now just call delete_breakpoint directly. 65614 65615 The notification will now be sent out immediately; as soon as the 65616 thread exits. 65617 65618 As the number has not changed when delete_breakpoint is called, the 65619 notification will have the correct number. 65620 65621 And as the breakpoint is immediately removed from the breakpoint list, 65622 we no longer need to worry about 'maint info breakpoints' trying to 65623 print the thread-id for an exited thread. 65624 65625 My only concern is that calling delete_breakpoint directly seems so 65626 obvious that I wonder why the original patch (that added 65627 remove_threaded_breakpoints) didn't take this approach. This code was 65628 added in commit 49fa26b0411d, but the commit message offers no clues 65629 to why this approach was taken, and the original email thread offers 65630 no insights either[2]. There are no test regressions after making 65631 this change, so I'm hopeful that this is going to be fine. 65632 65633 [2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html 65634 65635 The Complication 65636 ---------------- 65637 65638 Of course, it couldn't be that simple. 65639 65640 The script gdb.python/py-finish-breakpoint.exp had some regressions 65641 during testing. 65642 65643 The problem was with the FinishBreakpoint.out_of_scope callback 65644 implementation. This callback is supposed to trigger whenever the 65645 FinishBreakpoint goes out of scope; and this includes when the thread 65646 for the breakpoint exits. 65647 65648 The problem I ran into is the Python FinishBreakpoint implementation. 65649 Specifically, after this change I was loosing some of the out_of_scope 65650 calls. 65651 65652 The problem is that the out_of_scope call (of which I'm interested) is 65653 triggered from the inferior_exit observer. Before my change the 65654 observers were called in this order: 65655 65656 thread_exit 65657 inferior_exit 65658 breakpoint_deleted 65659 65660 The inferior_exit would trigger the out_of_scope call. 65661 65662 After my change the breakpoint_deleted notification (for 65663 thread-specific breakpoints) occurs earlier, as soon as the 65664 thread-exits, so now the order is: 65665 65666 thread_exit 65667 breakpoint_deleted 65668 inferior_exit 65669 65670 Currently, after the breakpoint_deleted call the Python object 65671 associated with the breakpoint is released, so, when we get to the 65672 inferior_exit observer, there's no longer a Python object to call the 65673 out_of_scope method on. 65674 65675 My solution is to follow the model for how bpfinishpy_pre_stop_hook 65676 and bpfinishpy_post_stop_hook are called, this is done from 65677 gdbpy_breakpoint_cond_says_stop in py-breakpoint.c. 65678 65679 I've now added a new bpfinishpy_pre_delete_hook 65680 gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook 65681 function I check and where needed call the out_of_scope method. 65682 65683 With this fix in place I now see the 65684 gdb.python/py-finish-breakpoint.exp test fully passing again. 65685 65686 Testing 65687 ------- 65688 65689 Tested on x86-64/Linux with unix, native-gdbserver, and 65690 native-extended-gdbserver boards. 65691 65692 New tests added to covers all the cases I've discussed above. 65693 65694 Approved-By: Pedro Alves <pedro@palves.net> 65695 656962023-02-28 Andrew Burgess <aburgess@redhat.com> 65697 65698 gdb/testsuite: fix failure in gdb.mi/mi-pending.exp with extended-remote 65699 I currently see this failure when running the gdb.mi/mi-pending.exp 65700 test using the native-extended-remote board: 65701 65702 -break-insert -f -c x==4 mi-pendshr.c:pendfunc2 65703 &"No source file named mi-pendshr.c.\n" 65704 ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="mi-pendshr.c:pendfunc2",cond="x==4",evaluated-by="host",times="0",original-location="mi-pendshr.c:pendfunc2"} 65705 (gdb) 65706 FAIL: gdb.mi/mi-pending.exp: MI pending breakpoint on mi-pendshr.c:pendfunc2 if x==4 (unexpected output) 65707 65708 The failure is caused by the 'evaluated-by="host"' string, which only 65709 appears in the output when the test is run using the 65710 native-extended-remote board. 65711 65712 I could fix this by just updating the pattern in 65713 gdb.mi/mi-pending.exp, but I have instead updated mi-pending.exp to 65714 make more use of the support procs in mi-support.exp. This did 65715 require making a couple of adjustments to mi-support.exp, but I think 65716 the result is that mi-pending.exp is now easier to read, and I see no 65717 failures with native-extended-remote anymore. 65718 65719 One of the test names has changed after this work, I think the old 65720 test name was wrong - it described a breakpoint as pending when the 65721 breakpoint was not pending, I suspect a copy & paste error. 65722 65723 But there's no changes to what is actually being tested after this 65724 patch. 65725 65726 Approved-By: Pedro Alves <pedro@palves.net> 65727 657282023-02-28 Andrew Burgess <aburgess@redhat.com> 65729 65730 gdb/testsuite: introduce is_target_non_stop helper proc 65731 I noticed that several tests included copy & pasted code to run the 65732 'maint show target-non-stop' command, and then switch based on the 65733 result. 65734 65735 In this commit I factor this code out into a helper proc in 65736 lib/gdb.exp, and update all the places I could find that used this 65737 pattern to make use of the helper proc. 65738 65739 There should be no change in what is tested after this commit. 65740 65741 Reviewed-By: Pedro Alves <pedro@palves.net> 65742 657432023-02-28 Andrew Burgess <aburgess@redhat.com> 65744 65745 gdb/testsuite introduce foreach_mi_ui_mode helper proc 65746 Introduce foreach_mi_ui_mode, a helper proc which can be used when 65747 tests are going to be repeated once with the MI in the main UI, and 65748 once with the MI on a separate UI. 65749 65750 The proc is used like this: 65751 65752 foreach_mi_ui_mode VAR { 65753 # BODY 65754 } 65755 65756 The BODY will be run twice, once with VAR set to 'main' and once with 65757 VAR set to 'separate', inside BODY we can then change the behaviour 65758 based on the current UI mode. 65759 65760 The point of this proc is that we sometimes shouldn't run the separate 65761 UI tests (when gdb_debug_enabled is true), and this proc hides all 65762 this logic. If the separate UI mode should not be used then BODY will 65763 be run just once with VAR set to 'main'. 65764 65765 I've updated two tests that can make use of this helper proc. I'm 65766 going to add another similar test in a later commit. 65767 65768 There should be no change to what is tested with this commit. 65769 65770 Approved-By: Pedro Alves <pedro@palves.net> 65771 657722023-02-28 Andrew Burgess <aburgess@redhat.com> 65773 65774 gdb/testsuite: extend the use of mi_clean_restart 65775 The mi_clean_restart proc calls the mi_gdb_start proc passing no 65776 arguments. 65777 65778 In this commit I add an extra (optional) argument to the 65779 mi_clean_restart proc, and pass this through to mi_gdb_start. 65780 65781 The benefit of this is that we can now use mi_clean_restart when we 65782 also want to pass the 'separate-mi-tty' or 'separate-inferior-tty' 65783 flags to mi_gdb_start, and avoids having to otherwise duplicate the 65784 contents of mi_clean_restart in different tests. 65785 65786 I've updated the obvious places where this new functionality can be 65787 used, and I'm seeing no test regressions. 65788 65789 Reviewed-By: Pedro Alves <pedro@palves.net> 65790 657912023-02-28 Andrew Burgess <aburgess@redhat.com> 65792 65793 gdb/testsuite: make more use of mi-support.exp 65794 Building on the previous commit, now that the breakpoint related 65795 support functions in lib/mi-support.exp can now help creating the 65796 patterns for thread specific breakpoints, make use of this 65797 functionality for gdb.mi/mi-nsmoribund.exp and gdb.mi/mi-pending.exp. 65798 65799 There should be no changes in what is tested after this commit. 65800 65801 Reviewed-By: Pedro Alves <pedro@palves.net> 65802 658032023-02-28 Andrew Burgess <aburgess@redhat.com> 65804 65805 gdb: don't duplicate 'thread' field in MI breakpoint output 65806 When creating a thread-specific breakpoint with a single location, the 65807 'thread' field would be repeated in the MI output. This can be seen 65808 in two existing tests gdb.mi/mi-nsmoribund.exp and 65809 gdb.mi/mi-pending.exp, e.g.: 65810 65811 (gdb) 65812 -break-insert -p 1 bar 65813 ^done,bkpt={number="1",type="breakpoint",disp="keep", 65814 enabled="y", 65815 addr="0x000000000040110a",func="bar", 65816 file="/tmp/mi-thread-specific-bp.c", 65817 fullname="/tmp/mi-thread-specific-bp.c", 65818 line="32",thread-groups=["i1"], 65819 thread="1",thread="1", <================ DUPLICATION! 65820 times="0",original-location="bar"} 65821 65822 I know we need to be careful when adjusting MI output, but I'm hopeful 65823 in this case, as the field is duplicated, and the field contents are 65824 always identical, that we might get away with removing one of the 65825 duplicates. 65826 65827 The change in GDB is a fairly trivial condition change. 65828 65829 We did have a couple of tests that contained the duplicate fields in 65830 their expected output, but given there was no comment pointing out 65831 this oddity either in the GDB code, or in the test, I suspect this was 65832 more a case of copying whatever output GDB produced and using that as 65833 the expected results. I've updated these tests to remove the 65834 duplication. 65835 65836 I've update lib/mi-support.exp to provide support for building 65837 breakpoint patterns that contain the thread field, and I've made use 65838 of this in a new test I've added that is just about creating 65839 thread-specific breakpoints and checking the results. The two tests I 65840 mentioned above as being updated could also use the new 65841 lib/mi-support.exp functionality, but I'm going to do that in a later 65842 patch, this way it is clear what changes I'm actually proposing to 65843 make to the expected output. 65844 65845 As I said, I hope that frontends will be able to handle this change, 65846 but I still think its worth adding a NEWS entry, that way, if someone 65847 runs into problems, there's a chance they can figure out what's going 65848 on. 65849 65850 This should not impact CLI output at all. 65851 65852 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 65853 Approved-By: Pedro Alves <pedro@palves.net> 65854 658552023-02-28 Andrew Burgess <aburgess@redhat.com> 65856 65857 gdb: remove an out of date comment about disp_del_at_next_stop 65858 Delete an out of date comment about disp_del_at_next_stop, the comment 65859 says: 65860 65861 /* NOTE drow/2003-09-08: This state only exists for removing 65862 watchpoints. It's not clear that it's necessary... */ 65863 65864 I'm sure this was true when the comment was added, but today the 65865 disp_del_at_next_stop state is not just used for deleting watchpoints, 65866 which leaves us with "It's not clear that it's necessary...", which 65867 doesn't really help at all. 65868 65869 And then this comment is located on one random place where 65870 disp_del_at_next_stop is used, rather than at its definition site. 65871 65872 Lets just delete the comment. 65873 65874 No user visible changes after this commit. 65875 65876 Reviewed-By: Pedro Alves <pedro@palves.net> 65877 658782023-02-28 Richard Ball <richard.ball@arm.com> 65879 65880 [Aarch64] Add Binutils support for MEC 65881 This change supports MEC which is part of RME (Realm Management Extension). 65882 658832023-02-28 Alan Modra <amodra@gmail.com> 65884 65885 chew.c printf of intptr_t 65886 Seen when building binutils with gcc -m32 on x86_64-linux. 65887 chew.c: In function ‘print’: 65888 chew.c:1434:59: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘intptr_t’ {aka ‘int’} [-Wformat=] 65889 1434 | fprintf (stderr, "print: illegal print destination `%ld'\n", *isp); 65890 | ~~^ ~~~~ 65891 | | | 65892 | | intptr_t {aka int} 65893 | long int 65894 | %d 65895 65896 * chew.c: Include inttypes.h. 65897 (print): Use PRIdPTR for *isp. 65898 658992023-02-28 Mark Harmstone <mark@harmstone.com> 65900 65901 ld: Sort section contributions in PDB files 65902 Microsoft's DIA library, and thus also MSVC and WinDbg, expects section 65903 contributions to be ordered by section number and offset, otherwise it's 65904 unable to resolve line numbers. 65905 659062023-02-28 Alan Modra <amodra@gmail.com> 65907 65908 Free ecoff debug info 65909 This frees memory associated with the mips ecoff find_nearest_line. 65910 65911 * elfxx-mips.x (free_ecoff_debug): New function, extracted from.. 65912 (_bfd_mips_elf_read_ecoff_info): ..here. Free ext_hdr earlier. 65913 Don't clear already NULL fdr. 65914 (struct mips_elf_find_line): Move earlier. 65915 (_bfd_mips_elf_close_and_cleanup): Call free_ecoff_debug. 65916 (_bfd_mips_elf_find_nearest_line): Likewise on error paths, 65917 and to clean up input_debug when done. 65918 659192023-02-28 Alan Modra <amodra@gmail.com> 65920 65921 Add some sanity checking in ECOFF lookup_line 65922 More anti-fuzzer bounds checking for the ECOFF support. A lot of this 65923 is in ancient code using "long" for counts and sizes, which is why the 65924 patch uses "(long) ((unsigned long) x + 1) > 0" in a few places. The 65925 unsigned long cast is so that "x + 1" doesn't trigger ubsan warnings 65926 about signed integer overflow. It would be a good idea to replace 65927 most of the longs used in binutils with size_t, but that's more than I 65928 care to do for COFF/ECOFF. 65929 65930 * ecofflink.c (mk_fdrtab): Sanity check string offsets. 65931 (lookup_line): Likewise, and symbol indices. 65932 659332023-02-28 Alan Modra <amodra@gmail.com> 65934 65935 Another PE SEC_HAS_CONTENTS test 65936 I'd skipped this one before, thinking "obfd, that's the linker output 65937 bfd so no need to test". Wrong, this is objcopy output. 65938 65939 * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Test 65940 SEC_HAS_CONTENTS before reading section. 65941 659422023-02-28 GDB Administrator <gdbadmin@sourceware.org> 65943 65944 Automatic date update in version.in 65945 659462023-02-27 Kevin Buettner <kevinb@redhat.com> 65947 65948 Forced quit cases handled by resetting sync_quit_force_run 65949 During my audit of the use of gdb_exception with regard to QUIT 65950 processing, I found a try/catch in the scoped_switch_fork_info 65951 destructor. 65952 65953 Static analysis found this call path from the destructor to 65954 maybe_quit(): 65955 65956 scoped_switch_fork_info::~scoped_switch_fork_info() 65957 -> remove_breakpoints() 65958 -> remove_breakpoint(bp_location*) 65959 -> remove_breakpoint_1(bp_location*, remove_bp_reason) 65960 -> memory_validate_breakpoint(gdbarch*, bp_target_info*) 65961 -> target_read_memory(unsigned long, unsigned char*, long) 65962 -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long) 65963 -> maybe_quit() 65964 65965 Since it's not safe to do a 'throw' from a destructor, we simply 65966 call set_quit_flag and, for gdb_exception_forced_quit, also 65967 set sync_quit_force_run. This will cause the appropriate 65968 exception to be rethrown at the next QUIT check. 65969 65970 Another case is the try / catch in tui_getc() in tui-io.c. The 65971 existing catch swallows the exception. I've added a catch for 65972 'gdb_exception_forced_quit', which also swallows the exception, 65973 but also sets sync_quit_force_run and calls set_quit_flag in 65974 order to restart forced quit processing at the next QUIT check. 65975 This is required because it isn't safe to throw into/through 65976 readline. 65977 65978 Thanks to Pedro Alves for suggesting this idea. 65979 65980 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 65981 Tested-by: Tom de Vries <tdevries@suse.de> 65982 Approved-By: Pedro Alves <pedro@palves.net> 65983 659842023-02-27 Kevin Buettner <kevinb@redhat.com> 65985 65986 Introduce set_force_quit_flag and change type of sync_quit_force_run 65987 At the moment, handle_sigterm() in event-top.c does the following: 65988 65989 sync_quit_force_run = 1; 65990 set_quit_flag (); 65991 65992 This was used several more times in a later patch in this series, so 65993 I'm introducing (at Pedro's suggestion) a new function named 65994 'set_force_quit_flag'. It simply sets sync_quit_force_run and also 65995 calls set_quit_flag(). I've revised the later patch to call 65996 set_force_quit_flag instead. 65997 65998 I noticed that sync_quit_force_run is declared as an int but is being 65999 used as a bool, so I also changed its type to bool in this commit. 66000 66001 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66002 Approved-By: Pedro Alves <pedro@palves.net> 66003 660042023-02-27 Kevin Buettner <kevinb@redhat.com> 66005 66006 QUIT processing w/ explicit throw for gdb_exception_forced_quit 66007 This commit contains changes which have an explicit throw for 66008 gdb_exception_forced_quit, or, in a couple of cases for gdb_exception, 66009 but with a throw following a check to see if 'reason' is 66010 RETURN_FORCED_QUIT. 66011 66012 Most of these are straightforward - it made sense to continue to allow 66013 an existing catch of gdb_exception to also catch gdb_exception_quit; 66014 in these cases, a catch/throw for gdb_exception_forced_quit was added. 66015 66016 There are two cases, however, which deserve a more detailed 66017 explanation. 66018 66019 1) remote_fileio_request in gdb/remote-fileio.c: 66020 66021 The try block calls do_remote_fileio_request which can (in turn) 66022 call one of the functions in remote_fio_func_map[]. Taking the 66023 first one, remote_fileio_func_open(), we have the following call 66024 path to maybe_quit(): 66025 66026 remote_fileio_func_open(remote_target*, char*) 66027 -> target_read_memory(unsigned long, unsigned char*, long) 66028 -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long) 66029 -> maybe_quit() 66030 66031 Since there is a path to maybe_quit(), we must ensure that the 66032 catch block is not permitted to swallow a QUIT representing a 66033 SIGTERM. 66034 66035 However, for this case, we must take care not to change the way that 66036 Ctrl-C / SIGINT is handled; we want to send a suitable EINTR reply to 66037 the remote target should that happen. That being the case, I added a 66038 catch/throw for gdb_exception_forced_quit. I also did a bit of 66039 rewriting here, adding a catch for gdb_exception_quit in favor of 66040 checking the 'reason' code in the catch block for gdb_exception. 66041 66042 2) mi_execute_command in gdb/mi/mi-main.c: 66043 66044 The try block calls captured_mi_execute_command(); there exists 66045 a call path to maybe_quit(): 66046 66047 captured_mi_execute_command(ui_out*, mi_parse*) 66048 -> mi_cmd_execute(mi_parse*) 66049 -> get_current_frame() 66050 -> get_prev_frame_always_1(frame_info*) 66051 -> frame_register_unwind_location(frame_info*, int, int*, lval_type*, unsigned long*, int*) 66052 -> frame_register_unwind(frame_info*, int, int*, int*, lval_type*, unsigned long*, int*, unsigned char*) 66053 -> value_entirely_available(value*) 66054 -> value_fetch_lazy(value*) 66055 -> value_fetch_lazy_memory(value*) 66056 -> read_value_memory(value*, long, int, unsigned long, unsigned char*, unsigned long) 66057 -> maybe_quit() 66058 66059 That being the case, we can't allow the exception handler (catch block) 66060 to swallow a gdb_exception_quit for SIGTERM. However, it does seem 66061 reasonable to output the exception via the mi interface so that some 66062 suitable message regarding SIGTERM might be printed; therefore, I 66063 check the exception's 'reason' field for RETURN_FORCED_QUIT and 66064 do a throw for this case. 66065 66066 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66067 Tested-by: Tom de Vries <tdevries@suse.de> 66068 Approved-By: Pedro Alves <pedro@palves.net> 66069 660702023-02-27 Kevin Buettner <kevinb@redhat.com> 66071 66072 Guile QUIT processing updates 66073 This commit contains QUIT processing updates for GDB's Guile support. 66074 As with the Python updates, we don't want to permit this code to 66075 swallow the exception, gdb_exception_forced_quit, which is associated 66076 with GDB receiving a SIGTERM. 66077 66078 I've adopted the same solution that I used for Python; whereever 66079 a gdb_exception is caught in try/catch code in the Guile extension 66080 language support, a catch for gdb_exception_forced_quit has been 66081 added; this catch block will simply call quit_force(), which will 66082 cause the necessary cleanups to occur followed by GDB exiting. 66083 66084 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66085 Tested-by: Tom de Vries <tdevries@suse.de> 66086 Approved-By: Pedro Alves <pedro@palves.net> 66087 660882023-02-27 Kevin Buettner <kevinb@redhat.com> 66089 66090 Python QUIT processing updates 66091 See the previous patches in this series for the motivation behind 66092 these changes. 66093 66094 This commit contains updates to Python's QUIT handling. Ideally, we'd 66095 like to throw gdb_exception_forced_quit through the extension 66096 language; I made an attempt to do this for gdb_exception_quit in an 66097 earlier version of this patch, but Pedro pointed out that it is 66098 (almost certainly) not safe to do so. 66099 66100 Still, we definitely don't want to swallow the exception representing 66101 a SIGTERM for GDB, nor do we want to force modules written in the 66102 extension language to have to explicitly handle this case. Since the 66103 idea is for GDB to cleanup and quit for this exception, we'll simply 66104 call quit_force() just as if the gdb_exception_forced_quit propagation 66105 had managed to make it back to the top level. 66106 66107 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66108 Tested-by: Tom de Vries <tdevries@suse.de> 66109 Approved-By: Pedro Alves <pedro@palves.net> 66110 661112023-02-27 Kevin Buettner <kevinb@redhat.com> 66112 66113 Catch gdb_exception_error instead of gdb_exception (in many places) 66114 As described in the previous commit for this series, I became 66115 concerned that there might be instances in which a QUIT (due to either 66116 a SIGINT or SIGTERM) might not cause execution to return to the top 66117 level. In some (though very few) instances, it is okay to not 66118 propagate the exception for a Ctrl-C / SIGINT, but I don't think that 66119 it is ever okay to swallow the exception caused by a SIGTERM. 66120 Allowing that to happen would definitely be a deviation from the 66121 current behavior in which GDB exits upon receipt of a SIGTERM. 66122 66123 I looked at all cases where an exception handler catches a 66124 gdb_exception. Handlers which did NOT need modification were those 66125 which satisifed one or more of the following conditions: 66126 66127 1) There is no call path to maybe_quit() in the try block. I used a 66128 static analysis tool to help make this determination. In 66129 instances where the tool didn't provide an answer of "yes, this 66130 call path can result in maybe_quit() being called", I reviewed it 66131 by hand. 66132 66133 2) The catch block contains a throw for conditions that it 66134 doesn't want to handle; these "not handled" conditions 66135 must include the quit exception and the new "forced quit" exception. 66136 66137 3) There was (also) a catch for gdb_exception_quit. 66138 66139 Any try/catch blocks not meeting the above conditions could 66140 potentially swallow a QUIT exception. 66141 66142 My first thought was to add catch blocks for gdb_exception_quit and 66143 then rethrow the exception. But Pedro pointed out that this can be 66144 handled without adding additional code by simply catching 66145 gdb_exception_error instead. That's what this patch series does. 66146 66147 There are some oddball cases which needed to be handled differently, 66148 plus the extension languages, but those are handled in later patches. 66149 66150 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66151 Tested-by: Tom de Vries <tdevries@suse.de> 66152 Approved-by: Pedro Alves <pedro@palves.net> 66153 661542023-02-27 Kevin Buettner <kevinb@redhat.com> 66155 66156 Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit 66157 When a GDB process receives the SIGTERM signal, handle_sigterm() in 66158 event-top.c is called. The global variable 'sync_quit_force_run' is 66159 set by this signal handler. It does some other things too, but the 66160 setting of this global is the important bit for the SIGTERM part of 66161 this discussion. 66162 66163 GDB will periodically check to see whether a Ctrl-C or SIGTERM has 66164 been received. This is performed via use of the QUIT macro in 66165 GDB's code. QUIT is defined to invoke maybe_quit(), which will be 66166 periodically called during any lengthy operation. This is supposed to 66167 ensure that the user won't have to wait too long for a Ctrl-C or 66168 SIGTERM to be acted upon. 66169 66170 When a Ctrl-C / SIGINT is received, quit_handler() will decide whether 66171 to pass the SIGINT onto the inferior or to call quit() which causes 66172 gdb_exception_quit to be thrown. This exception (usually) propagates 66173 to the top level. Control is then returned to the top level event 66174 loop. 66175 66176 At the moment, SIGTERM is handled very differently. Instead of 66177 throwing an exception, quit_force() is called. This does eventually 66178 cause GDB to exit(), but prior to that happening, the inferiors 66179 are killed or detached and other target related cleanup occurs. 66180 As shown in this discussion between Pedro Alves and myself... 66181 66182 https://sourceware.org/pipermail/gdb-patches/2021-July/180802.html 66183 https://sourceware.org/pipermail/gdb-patches/2021-July/180902.html 66184 https://sourceware.org/pipermail/gdb-patches/2021-July/180903.html 66185 66186 ...we found that it is possible for inferior_ptid and current_thread_ 66187 to get out of sync. When that happens, the "current_thread_ != nullptr" 66188 assertion in inferior_thread() can fail resulting in a GDB internal 66189 error. 66190 66191 Pedro recommended that we "let the normal quit exception propagate all 66192 the way to the top level, and then have the top level call quit_force 66193 if sync_quit_force_run is set." However, after the v2 series for this 66194 patch set, we tweaked that idea by introducing a new exception for 66195 handling SIGTERM. 66196 66197 This commit implements the obvious part of Pedro's suggestion: 66198 Instead of calling quit_force from quit(), throw_forced_quit() is now 66199 called instead. This causes the new exception 'gdb_exception_forced_quit' 66200 to be thrown. 66201 66202 At the top level, I changed catch_command_errors() and captured_main() 66203 to catch gdb_exception_forced_quit and then call quit_force() from the 66204 catch block. I also changed start_event_loop() to also catch 66205 gdb_exception_forced_quit; while we could also call quit_force() from 66206 that catch block, it's sufficient to simply rethrow the exception 66207 since it'll be caught by the newly added code in captured_main(). 66208 66209 Making these changes fixed the failure / regression that I was seeing 66210 for gdb.base/gdb-sigterm.exp when run on a machine with glibc-2.34. 66211 However, there are many other paths back to the top level which this 66212 test case does not test. I did an audit of all of the try / catch 66213 code in GDB in which calls in the try-block might (eventually) call 66214 QUIT. I found many cases where gdb_exception_quit and the new 66215 gdb_exception_forced_quit will be swallowed. (When using GDB, have 66216 you ever hit Ctrl-C and not have it do anything; if so, it could be 66217 due to a swallowed gdb_exception_quit in one of the cases I've 66218 identified.) The rest of the patches in this series deal with this 66219 concern. 66220 66221 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66222 Tested-by: Tom de Vries <tdevries@suse.de> 66223 Approved-by: Pedro Alves <pedro@palves.net> 66224 662252023-02-27 Kevin Buettner <kevinb@redhat.com> 66226 66227 Introduce gdb_exception_forced_quit 66228 This commit adds a new exception 'gdb_exception_forced_quit', reason 66229 code 'REASON_FORCED_QUIT', return mask 'RETURN_MASK_FORCED_QUIT', and 66230 a wrapper for throwing the exception, throw_forced_quit(). 66231 66232 The addition of this exception plus supporting code will allow us to 66233 recognize that a SIGTERM has been received by GDB and then propagate 66234 recognition of that fact to the upper levels of GDB where it can be 66235 correctly handled. At the moment, when GDB receives a SIGTERM, it 66236 will attempt to exit via a series of calls from the QUIT checking 66237 code. However, before it can exit, it must do various cleanups, such 66238 as killing or detaching all inferiors. Should these cleanups be 66239 attempted while GDB is executing very low level code, such as reading 66240 target memory from within ps_xfer_memory(), it can happen that some of 66241 GDB's state is out of sync with regard to the cleanup code's 66242 expectations. In the case just mentioned, it's been observed that 66243 inferior_ptid and the current_thread_ are not in sync; this triggers 66244 an assert / internal error. 66245 66246 This commit only introduces the exception plus supporting machinery; 66247 changes which use this new exception are in later commits in this 66248 series. 66249 66250 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 66251 Tested-by: Tom de Vries <tdevries@suse.de> 66252 Approved-by: Pedro Alves <pedro@palves.net> 66253 662542023-02-27 Tom Tromey <tom@tromey.com> 66255 66256 Fix value chain use-after-free 66257 Hannes filed a bug showing a crash, where a pretty-printer written in 66258 Python could cause a use-after-free. He sent a patch, but I thought a 66259 different approach was needed. 66260 66261 In a much earlier patch (see bug #12533), we changed the Python code 66262 to release new values from the value chain when constructing a 66263 gdb.Value. The rationale for this is that if you write a command that 66264 does a lot of computations in a loop, all the values will be kept live 66265 by the value chain, resulting in gdb using a large amount of memory. 66266 66267 However, suppose a value is passed to Python from some code in gdb 66268 that needs to use the value after the call into Python. In this 66269 scenario, value_to_value_object will still release the value -- and 66270 because gdb code doesn't generally keep strong references to values (a 66271 consequence of the ancient decision to use the value chain to avoid 66272 memory management), this will result in a use-after-free. 66273 66274 This scenario can happen, as it turns out, when a value is passed to 66275 Python for pretty-printing. Now, normally this route boxes the value 66276 via value_to_value_object_no_release, avoiding the problematic release 66277 from the value chain. However, if you then call Value.cast, the 66278 underlying value API might return the same value, when is then 66279 released from the chain. 66280 66281 This patch fixes the problem by changing how value boxing is done. 66282 value_to_value_object no longer removes a value from the chain. 66283 Instead, every spot in gdb that might construct new values uses a 66284 scoped_value_mark to ensure that the requirements of bug #12533 are 66285 met. And, because incoming values aren't ever released from the chain 66286 (the Value.cast one comes earlier on the chain than the 66287 scoped_value_mark), the bug can no longer occur. (Note that many 66288 spots in the Python layer already take this approach, so not many 66289 places needed to be touched.) 66290 66291 In the future I think we should replace the use of raw "value *" with 66292 value_ref_ptr pretty much everywhere. This will ensure lifetime 66293 safety throughout gdb. 66294 66295 The test case in this patch comes from Hannes' original patch. I only 66296 made a trivial ("require") change to it. However, while this fails 66297 for him, I can't make it fail on this machine; nevertheless, he tried 66298 my patch and reported the bug as being fixed. 66299 66300 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044 66301 663022023-02-27 Pedro Alves <pedro@palves.net> 66303 66304 Remove infrun_thread_thread_exit observer 66305 After the previous patches, I believe this observer isn't necessary 66306 anymore for anything. Remove it. 66307 66308 Change-Id: Idb33fb6b6f55589c8c523a92169b3ca95a23d0b9 66309 663102023-02-27 Pedro Alves <pedro@palves.net> 66311 66312 all-stop "follow-fork parent" and selecting another thread 66313 With: 66314 66315 - catch a fork in thread 1 66316 - select thread 2 66317 - set follow-fork child 66318 - next 66319 66320 ... follow_fork notices that thread 1 had last stopped for a fork 66321 which hasn't been followed yet, and because thread 1 is not the 66322 current thread, GDB aborts the execution command, presenting the stop 66323 in thread 1. 66324 66325 That makes sense, as only the forking thread (thread 1) survives in 66326 the child, so better stop and let the user decide how to proceed. 66327 66328 However, with: 66329 66330 - catch a fork in thread 1 66331 - select thread 2 66332 - set follow-fork parent << note difference here 66333 - next 66334 66335 ... GDB does the same: follow_fork notices that thread 1 had last 66336 stopped for a fork which hasn't been followed yet, and because thread 66337 1 is not the current thread, GDB aborts the execution command, 66338 presenting the stop in thread 1. 66339 66340 Aborting/stopping in this case doesn't make sense to me. As we're 66341 following the parent, thread 2 will still continue to exist in the 66342 parent. What the child does after we've followed the parent shouldn't 66343 matter -- it can go on running free, be detached, etc., depending on 66344 "set schedule-multiple", "set detach-on-fork", etc. That does not 66345 influence the execution command that the user issued for the parent 66346 thread. 66347 66348 So this patch changes GDB in that direction -- in follow_fork, if 66349 following the parent, and we've switched threads meanwhile, switch 66350 back to the unfollowed thread, follow it (stay with the parent), and 66351 don't abort/stop. If we're following a fork (as opposed to vfork), 66352 then switch back again to the thread that the user was trying to 66353 resume. If following a vfork, however, stay with the vforking-thread 66354 selected, as we will need to see a vfork_done event first, before we 66355 can resume any other thread. 66356 66357 As I was working on this, I managed to end up calling target_resume 66358 for a solo-thread resume (to collect the vfork_done event), with 66359 scope_ptid pointing at the vfork parent thread, and inferior_ptid 66360 pointing to the vfork child. For a solo-thread resume, the scope_ptid 66361 argument to target_resume must the same as inferior_ptid. The mistake 66362 was caught by the assertion in target_resume, like so: 66363 66364 ... 66365 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [1722839.1722839.0] at 0x5555555553c3 66366 [infrun] do_target_resume: resume_ptid=1722839.1722939.0, step=0, sig=GDB_SIGNAL_0 66367 ../../src/gdb/target.c:2661: internal-error: target_resume: Assertion `inferior_ptid.matches (scope_ptid)' failed. 66368 ... 66369 66370 but I think it doesn't hurt to catch such a mistake earlier, hence the 66371 change in internal_resume_ptid. 66372 66373 Change-Id: I896705506a16d2488b1bfb4736315dd966f4e412 66374 663752023-02-27 Pedro Alves <pedro@palves.net> 66376 66377 Make follow_fork not rely on get_last_target_status 66378 Currently, if 66379 66380 - you're in all-stop mode, 66381 - the inferior last stopped because of a fork catchpoint, 66382 66383 when you next resume the program, gdb checks whether it had last 66384 stopped for a fork/vfork, and if so, 66385 66386 a) if the current thread is the one that forked, gdb follows the 66387 parent/child, depending on "set follow-fork" mode. 66388 66389 b) if the current thread is some other thread (because you switched 66390 threads meanwhile), gdb switches back to that thread, gdb follows 66391 the parent/child, and stops the resumption command. 66392 66393 There's a problem in b), however -- if you have "set schedule-multiple 66394 off", which is the default, or "set scheduler-locking on", gdb will 66395 still switch back to the forking thread, even if you didn't want to 66396 resume it. For example, with: 66397 66398 (gdb) catch fork 66399 (gdb) c 66400 * thread 1 stops for fork 66401 (gdb) thread 2 66402 (gdb) set scheduler-locking on 66403 (gdb) c 66404 66405 gdb switches back to thread 1, and follows the fork. 66406 66407 Or with: 66408 66409 (gdb) add-inferior -exec prog 66410 (gdb) inferior 2 66411 (gdb) start 66412 (gdb) inferior 1 66413 (gdb) catch fork 66414 (gdb) c 66415 * thread 1.1 stops for fork 66416 (gdb) inferior 2 66417 (gdb) set schedule-multiple off # this is the default 66418 (gdb) c 66419 66420 gdb switches back to thread 1.1, and follows the fork. 66421 66422 Another issue is that, because follow_fork relies on 66423 get_last_target_status to find the thread that has a pending fork, it 66424 is possible to confuse it. For example, "run" or "start" call 66425 init_wait_for_inferior, which clears the last target status, so this: 66426 66427 (gdb) catch fork 66428 (gdb) c 66429 * thread 1 stops for fork 66430 (gdb) add-inferior -exec prog 66431 (gdb) inferior 2 66432 (gdb) start 66433 (gdb) set follow-fork child 66434 (gdb) inferior 1 66435 (gdb) n 66436 66437 ... does not follow to the fork child of inferior 1, because the 66438 get_last_target_status call in follow_fork doesn't return a 66439 TARGET_WAITKIND_FORKED. Thanks to Simon for this example. 66440 66441 All of the above are fixed by this patch. It changes follow_fork to 66442 not look at get_last_target_status, but to instead iterate over the 66443 set of threads that the user is resuming, and find the one that has a 66444 pending_follow kind of fork/vfork. 66445 66446 gdb.base/foll-fork.exp is augmented to exercise the last "start" 66447 scenario described above. The other cases will be exercised in the 66448 testcase added by the following patch. 66449 66450 Change-Id: Ifcca77e7b2456277387f40660ef06cec2b93b97e 66451 664522023-02-27 Pedro Alves <pedro@palves.net> 66453 66454 Improve "info program" 66455 With gdb.base/catch-follow-exec.exp, we currently see: 66456 66457 ~~~~~~~~~~~~~~~ 66458 (gdb) 66459 continue 66460 Continuing. 66461 process 693251 is executing new program: /usr/bin/ls 66462 [New inferior 2] 66463 [New process 693251] 66464 [Switching to process 693251] 66465 66466 Thread 2.1 "ls" hit Catchpoint 2 (exec'd /usr/bin/ls), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2 66467 (gdb) 66468 info prog 66469 No selected thread. 66470 ~~~~~~~~~~~~~~~ 66471 66472 Note the "No selected thread" output. That is totally bogus, because 66473 there _is_ a selected thread. What GDB really means, is that it can't 66474 find the thread that had the latest (user-visible) stop. And that 66475 happens because "info program" gets that info from 66476 get_last_target_status, and the last target status has been cleared. 66477 66478 However, GDB also checks if there is a selected thread, here: 66479 66480 if (ptid == null_ptid || ptid == minus_one_ptid) 66481 error (_("No selected thread.")); 66482 66483 .. the null_ptid part. That is also bogus, because what matters is 66484 the thread that last reported a stop, not the current thread: 66485 66486 - in all-stop mode, "info program" displays info about the last stop. 66487 That may have happened on a thread different from the selected 66488 thread. 66489 66490 - in non-stop mode, because all threads are controlled individually, 66491 "info program" shows info about the last stop of the selected 66492 thread. 66493 66494 The current code already behaves this way, though in a poor way. This 66495 patch reimplements it, such that the all-stop version now finds the 66496 thread that last reported an event via the 'previous_thread' strong 66497 reference. Being a strong reference means that if that thread has 66498 exited since the event was reported, 'previous_thread' will still 66499 point to it, so we can say that the thread exited meanwhile. 66500 66501 The patch also extends "info program" output a little, to let the user 66502 know which thread we are printing info for. For example, for the 66503 gdb.base/catch-follow-exec.exp case we shown above, we now get: 66504 66505 (gdb) info prog 66506 Last stopped for thread 2.1 (process 710867). 66507 Using the running image of child process 710867. 66508 Program stopped at 0x7ffff7fd0100. 66509 It stopped at breakpoint 2. 66510 Type "info stack" or "info registers" for more information. 66511 (gdb) 66512 66513 while in non-stop mode, we get: 66514 66515 (gdb) info prog 66516 Selected thread 2.1 (process 710867). 66517 Using the running image of child process 710867. 66518 Program stopped at 0x7ffff7fd0100. 66519 It stopped at breakpoint 2. 66520 Type "info stack" or "info registers" for more information. 66521 (gdb) 66522 66523 In both cases, the first line of output is new. 66524 66525 The existing code considered these running/exited cases as an error, 66526 but I think that that's incorrect, since this is IMO just plain 66527 execution info as well. So the patch makes those cases regular 66528 prints, not errors. 66529 66530 If the thread is running, we get, in non-stop mode: 66531 66532 (gdb) info prog 66533 Selected thread 2.1 (process 710867). 66534 Selected thread is running. 66535 66536 ... and in all-stop: 66537 66538 (gdb) info prog 66539 Last stopped for thread 2.1 (process 710867). 66540 Thread is now running. 66541 66542 If the thread has exited, we get, in non-stop mode: 66543 66544 (gdb) info prog 66545 Selected thread 2.1 (process 710867). 66546 Selected thread has exited. 66547 66548 ... and in all-stop: 66549 66550 (gdb) info prog 66551 Last stopped for thread 2.1 (process 710867). 66552 Thread has since exited. 66553 66554 The gdb.base/info-program.exp testcase was much extended to test 66555 all-stop/non-stop and single-threaded/multi-threaded. 66556 66557 Change-Id: I51d9d445f772d872af3eead3449ad4aa445781b1 66558 665592023-02-27 Pedro Alves <pedro@palves.net> 66560 66561 Convert previous_inferior_ptid to strong reference to thread_info 66562 I originally wrote this patch, because while working on some other 66563 patch, I spotted a regression in the 66564 gdb.multi/multi-target-no-resumed.exp.exp testcase. Debugging the 66565 issue, I realized that the problem was related to how I was using 66566 previous_inferior_ptid to look up the thread the user had last 66567 selected. The problem is that previous_inferior_ptid alone doesn't 66568 tell you which target that ptid is from, and I was just always using 66569 the current target, which was incorrect. Two different targets may 66570 have threads with the same ptid. 66571 66572 I decided to fix this by replacing previous_inferior_ptid with a 66573 strong reference to the thread, called previous_thread. 66574 66575 I have since found a new motivation for this change -- I would like to 66576 tweak "info program" to not rely on get_last_target_status returning a 66577 ptid that still exists in the thread list. With both the follow_fork 66578 changes later in this series, and the step-over-thread-exit changes, 66579 that can happen, as we'll delete threads and not clear the last 66580 waitstatus. 66581 66582 A new update_previous_thread function is added that can be used to 66583 update previous_thread from inferior_ptid. This must be called in 66584 several places that really want to get rid of previous_thread thread, 66585 and reset the thread id counter, otherwise we get regressions like 66586 these: 66587 66588 (gdb) info threads -gid 66589 Id GId Target Id Frame 66590 - * 1 1 Thread 2974541.2974541 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21 66591 - (gdb) PASS: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid 66592 + * 1 2 Thread 2958361.2958361 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21 66593 + (gdb) FAIL: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid 66594 66595 and: 66596 66597 Core was generated by `build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/si'. 66598 Program terminated with signal SIGTRAP, Trace/breakpoint trap. 66599 #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398 66600 398 kill (getpid (), SIGABRT); 66601 +[Current thread is 1 (LWP 2662066)] 66602 Restored records from core file build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/sigall.precsave. 66603 #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398 66604 398 kill (getpid (), SIGABRT); 66605 66606 continue 66607 Continuing. 66608 66609 -Program received signal SIGABRT, Aborted. 66610 +Thread 1 received signal SIGABRT, Aborted. 66611 0x00007ffff7dfd55b in kill () at ../sysdeps/unix/syscall-template.S:78 66612 78 ../sysdeps/unix/syscall-template.S: No such file or directory. 66613 -(gdb) PASS: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT 66614 +(gdb) FAIL: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT 66615 66616 I.e., GDB was failing to restart the thread counter back to 1, because 66617 the previous_thread thread was being help due to the strong reference. 66618 66619 Tested on GNU/Linux native, gdbserver and gdbserver + "maint set 66620 target-non-stop on". 66621 66622 gdb/ChangeLog: 66623 yyyy-mm-dd Pedro Alves <pedro@palves.net> 66624 66625 * infcmd.c (kill_command, detach_command, disconnect_command): 66626 Call update_previous_thread. 66627 * infrun.c (previous_inferior_ptid): Delete. 66628 (previous_thread): New. 66629 (update_previous_thread): New. 66630 (proceed, init_wait_for_inferior): Call update_previous_thread. 66631 (normal_stop): Adjust to compare previous_thread and 66632 inferior_thread. Call update_previous_thread. 66633 * infrun.h (update_previous_thread): Declare. 66634 * target.c (target_pre_inferior, target_preopen): Call 66635 update_previous_thread. 66636 66637 Change-Id: I42779a1ee51a996fa1e8f6e1525c6605dbfd42c7 66638 666392023-02-27 Pedro Alves <pedro@palves.net> 66640 66641 Tweak "Using the running image of ..." output 66642 Currently, "info files" and "info program" on a few native targets 66643 show: 66644 66645 (gdb) info files 66646 Symbols from "/home/pedro/gdb/tests/threads". 66647 Native process: 66648 Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968). 66649 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 66650 ... 66651 66652 (gdb) info program 66653 Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968). 66654 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 66655 Program stopped at 0x555555555278. 66656 ... 66657 66658 66659 This patch changes them to: 66660 66661 (gdb) info files 66662 Symbols from "/home/pedro/gdb/tests/threads". 66663 Native process: 66664 Using the running image of child process 1097968. 66665 ^^^^^^^^^^^^^^^ 66666 ... 66667 66668 (gdb) info program 66669 Using the running image of child process 1097968. 66670 ^^^^^^^^^^^^^^^ 66671 Program stopped at 0x555555555278. 66672 ... 66673 66674 66675 ... which I think makes a lot more sense in this context. The "info 66676 program" manual entry even says: 66677 66678 "Display information about the status of your program: whether it is 66679 running or not, what process it is, and why it stopped." 66680 ^^^^^^^^^^^^^ 66681 66682 This change affects ptrace targets, procfs targets, and Windows. 66683 66684 Approved-By: Simon Marchi <simon.marchi@efficios.com> 66685 Change-Id: I6aab061ff494a84ba3398cf98fd49efd7a6ec1ca 66686 666872023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66688 66689 gdb: make-target-delegates.py: add type annotations 66690 Fixes all warnings given by pyright. 66691 66692 Change-Id: I480521bfc62960c4eccd9d32c886392b05a1ddaa 66693 Reviewed-By: Tom Tromey <tom@tromey.com> 66694 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66695 666962023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66697 66698 gdb: make-target-delegates.py: add Entry type 66699 Add the Entry type and use it in the `entries` map, rather than using an 66700 ad-hoc str -> str map that comes from the re.match. This will make it 66701 easier to make typing work in a subsequent patch, but it also helps 66702 readers know what attributes exist for entries, which is not clear 66703 currently. 66704 66705 Change-Id: I5b58dee1ed7ae85987b99bd417e641ede718624c 66706 Reviewed-By: Tom Tromey <tom@tromey.com> 66707 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66708 667092023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66710 66711 gdb: make-target-delegates.py: make one string raw 66712 Fixes the following flake8 warning: 66713 66714 make-target-delegates.py:36:39: W605 invalid escape sequence '\s' 66715 66716 Change-Id: I25eeb296f55765e17e5217a2d1e49018f63a3acd 66717 Reviewed-By: Tom Tromey <tom@tromey.com> 66718 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66719 667202023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66721 66722 gdb: gdbarch*.py, copyright.py: add type annotations 66723 Add type annotations to gdbarch*.py to fix all errors shown by pyright. 66724 There is one change in copyright.py too, to fix this one: 66725 66726 /home/simark/src/binutils-gdb/gdb/gdbarch.py 66727 /home/simark/src/binutils-gdb/gdb/gdbarch.py:206:13 - error: Type of "copyright" is partially unknown 66728 Type of "copyright" is "(tool: Unknown, description: Unknown) -> str" (reportUnknownMemberType) 66729 66730 Change-Id: Ia109b53e267f6e2f5bd79a1288d0d5c9508c9ac4 66731 Reviewed-By: Tom Tromey <tom@tromey.com> 66732 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66733 667342023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66735 66736 gdb: split gdbarch component types to gdbarch_types.py 66737 Editing gdbarch-components.py is not an experience in an editor that is 66738 minimally smart about Python. Because gdbarch-components.py is read and 66739 exec'd by gdbarch.py, it doesn't import the Info / Method / Function / 66740 Value types. And because these types are defined in gdbarch.py, it 66741 can't import them, as that would make a cyclic dependency. 66742 66743 Solve this by introducing a third file, gdbarch_types.py, to define 66744 these types. Make gdbarch.py and gdbarch-components.py import it. 66745 Also, replace the read & exec of gdbarch-components.py by a regular 66746 import. For this to work though, gdbarch-components.py needs to be 66747 renamed to gdbarch_components.py. 66748 66749 Change-Id: Ibe994d56ef9efcc0698b3ca9670d4d9bf8bbb853 66750 Reviewed-By: Tom Tromey <tom@tromey.com> 66751 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66752 667532023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66754 66755 gdb: pyproject.toml: set pyright typeCheckingMode = "strict" 66756 While working on other projects, I found the pyright type checker very 66757 helpful when editing Python code. I don't think I have to explain the 66758 advantages of type checking to a crowd used to C/C++. 66759 66760 Setting typeCheckingMode to "strict" makes pyright flag a bit more type 66761 issues than the default of "basic". 66762 66763 Change-Id: I38818ec59f7f73c2ab020cc9226286cdd485abc7 66764 Reviewed-By: Tom Tromey <tom@tromey.com> 66765 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66766 667672023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66768 66769 gdb: gdbarch.py: remove Info.__init__ 66770 Info.__init__ currently assigns `self.predicate = None`. This was 66771 helpful to ensure that all component types had a `predicate` attribute. 66772 The generator code could then avoid having code like "if the component 66773 is anything but Info, use predicate". Since the previous commit, all 66774 component types have a predicate attribute which defaults to False. We 66775 can therefore remove the assignment in Info.__init__, and in turn remove 66776 Info.__init__. We however need to make the printer parameter of 66777 _Component.__init__ optional, as Info don't need a printer. 66778 66779 Change-Id: I611edeca9cc9837eb49dddfe038595e1ff3b7239 66780 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66781 667822023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66783 66784 gdb: gdbarch.py: spell out parameters of _Component.__init__ 66785 The way _Component uses kwargs is handy to save a few characters, but it 66786 doesn't play well with static analysis. When editing gdbarch.py, my 66787 editor (which uses pylance under the hood) knows nothing about the 66788 properties of components. So it's full of squiggly lines, and typing 66789 analysis (which I find really helpful) doesn't work. I therefore think 66790 it would be better to spell out the parameters. 66791 66792 Change-Id: Iaf561beb0d0fbe170ce1c79252a291e0945e1830 66793 Reviewed-By: Tom Tromey <tom@tromey.com> 66794 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66795 667962023-02-27 Simon Marchi <simon.marchi@polymtl.ca> 66797 66798 gdb: reformat Python files with black 23.1.0 66799 Change-Id: Ie8ec8870a16d71c5858f5d08958309d23c318302 66800 Reviewed-By: Tom Tromey <tom@tromey.com> 66801 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66802 668032023-02-27 Simon Marchi <simon.marchi@efficios.com> 66804 66805 gdb: remove invalid / dead code from gdbarch.py 66806 My editor flagged that the variable `c` (in the lines removed by this 66807 patch) was unknown. I guess it ends up working because there is a `c` 66808 variable in the global scope. I tried putting `assert False` inside 66809 that if, and it is not hit, showing that we never enter this if. So, 66810 remove it. There is no change in the generated files. 66811 66812 Change-Id: Id3b9f67719e88cada7c6fde673c8d7842ab13617 66813 Reviewed-By: Tom Tromey <tom@tromey.com> 66814 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 66815 668162023-02-27 Tom Tromey <tom@tromey.com> 66817 66818 Fix crash with "finish" in Rust 66819 PR rust/30090 points out that a certain "finish" in a Rust program 66820 will cause gdb to crash. This happens due to some confusion about 66821 field indices in rust_language::print_enum. The fix is to use 66822 value_primitive_field so that the correct type can be passed; other 66823 spots in rust-lang.c already do this. 66824 66825 Note that the enclosed test case comes with an xfail. This is needed 66826 because for this function, rustc doesn't follow the platform ABI. 66827 66828 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30090 66829 668302023-02-27 Tom Tromey <tom@tromey.com> 66831 66832 Remove old GNU indent directives 66833 Now that gdb_indent.sh has been removed, I think it makes sense to 66834 also remove the directives intended for GNU indent. 66835 668362023-02-27 Tom Tromey <tromey@adacore.com> 66837 66838 Handle range types in ax-gdb.c 66839 A range type can usually be treated the same as its underlying integer 66840 type, at least for the purposes of agent expressions. This patch 66841 arranges for range types to be handled this way in ax-gdb.c, letting a 66842 somewhat larger subset of Ada expressions be compiled. 66843 668442023-02-27 Tom Tromey <tromey@adacore.com> 66845 66846 Implement some agent expressions for Ada 66847 Ada historically has not implemented agent expressions, and some Ada 66848 constructs probably cannot reasonably be converted to agent 66849 expressions. However, a subset of simple operations can be, and this 66850 patch represents a first step in that direction. 66851 66852 On one internal AdaCore test case, this improves the performance of a 66853 conditional breakpoint from 5 minutes to 5 seconds. 66854 66855 The main tricky part in this patch is ensuring the converted 66856 expressions detect the cases that will not work. This is done by 66857 examining the code in the corresponding evaluation methods. 66858 668592023-02-27 Pedro Alves <pedro@palves.net> 66860 66861 Regenerate Linux syscall group info 66862 This commit makes use of the new script to regenerate the Linux 66863 syscall group info against strace git hash 66864 e88e5e9ae6da68f22d15f9be3193b1412ac9aa02. 66865 66866 Like so: 66867 66868 $ cd gdb/syscalls/ 66869 $ ./update-linux-defaults.sh ~/strace.git/ 66870 Generating linux-defaults.xml.in 66871 $ make 66872 for f in aarch64-linux.xml amd64-linux.xml arm-linux.xml bfin-linux.xml \ 66873 i386-linux.xml mips-n32-linux.xml mips-n64-linux.xml \ 66874 mips-o32-linux.xml ppc64-linux.xml ppc-linux.xml s390-linux.xml \ 66875 s390x-linux.xml sparc64-linux.xml sparc-linux.xml; do \ 66876 xsltproc --output $f apply-defaults.xsl $f.in; \ 66877 done 66878 66879 The result is that a lot more syscalls end up assigned to groups. 66880 Some lose their group info, but that just mirrors what strace does. 66881 66882 The gdb/syscalls/linux-defaults.xml.in file shows a large diff because 66883 the new version is ASCII sorted, while the current version was 66884 somewhat (but not consistently) sorted by "family" of syscalls. 66885 66886 If I sort the old file and diff against the new, the difference is 66887 like this: 66888 66889 <syscall name="accept4" groups="network"/> 66890 <syscall name="accept" groups="network"/> 66891 <syscall name="access" groups="file"/> 66892 <syscall name="acct" groups="file"/> 66893 - <syscall name="arch_prctl" groups="process"/> 66894 <syscall name="bind" groups="network"/> 66895 + <syscall name="bpf" groups="descriptor"/> 66896 <syscall name="break" groups="memory"/> 66897 <syscall name="brk" groups="memory"/> 66898 + <syscall name="bsd43_fstatfs" groups="descriptor"/> 66899 + <syscall name="bsd43_fstat" groups="descriptor"/> 66900 + <syscall name="bsd43_killpg" groups="process"/> 66901 + <syscall name="bsd43_kill" groups="process"/> 66902 + <syscall name="bsd43_lstat" groups="file"/> 66903 + <syscall name="bsd43_madvise" groups="memory"/> 66904 + <syscall name="bsd43_mincore" groups="memory"/> 66905 + <syscall name="bsd43_mmap" groups="descriptor,memory"/> 66906 + <syscall name="bsd43_mprotect" groups="memory"/> 66907 + <syscall name="bsd43_mremap" groups="memory"/> 66908 + <syscall name="bsd43_munmap" groups="memory"/> 66909 + <syscall name="bsd43_oldfstat" groups="descriptor"/> 66910 + <syscall name="bsd43_oldstat" groups="file"/> 66911 + <syscall name="bsd43_quotactl" groups="file"/> 66912 + <syscall name="bsd43_sbreak" groups="memory"/> 66913 + <syscall name="bsd43_sbrk" groups="memory"/> 66914 + <syscall name="bsd43_statfs" groups="file"/> 66915 + <syscall name="bsd43_stat" groups="file"/> 66916 + <syscall name="cacheflush" groups="memory"/> 66917 <syscall name="chdir" groups="file"/> 66918 <syscall name="chmod" groups="file"/> 66919 <syscall name="chown32" groups="file"/> 66920 <syscall name="chown" groups="file"/> 66921 <syscall name="chroot" groups="file"/> 66922 + <syscall name="clone2" groups="process"/> 66923 + <syscall name="clone3" groups="process"/> 66924 <syscall name="clone" groups="process"/> 66925 <syscall name="close" groups="descriptor"/> 66926 <syscall name="connect" groups="network"/> 66927 + <syscall name="copy_file_range" groups="descriptor"/> 66928 <syscall name="creat" groups="descriptor,file"/> 66929 <syscall name="dup2" groups="descriptor"/> 66930 <syscall name="dup3" groups="descriptor"/> 66931 @@ -28,14 +52,17 @@ 66932 <syscall name="epoll_create1" groups="descriptor"/> 66933 <syscall name="epoll_create" groups="descriptor"/> 66934 <syscall name="epoll_ctl" groups="descriptor"/> 66935 + <syscall name="epoll_pwait2" groups="descriptor"/> 66936 <syscall name="epoll_pwait" groups="descriptor"/> 66937 <syscall name="epoll_wait" groups="descriptor"/> 66938 <syscall name="eventfd2" groups="descriptor"/> 66939 <syscall name="eventfd" groups="descriptor"/> 66940 + <syscall name="execveat" groups="descriptor,file,process"/> 66941 <syscall name="execve" groups="file,process"/> 66942 <syscall name="execv" groups="file,process"/> 66943 <syscall name="exit_group" groups="process"/> 66944 <syscall name="exit" groups="process"/> 66945 + <syscall name="faccessat2" groups="descriptor,file"/> 66946 <syscall name="faccessat" groups="descriptor,file"/> 66947 <syscall name="fadvise64_64" groups="descriptor"/> 66948 <syscall name="fadvise64" groups="descriptor"/> 66949 @@ -57,7 +84,11 @@ 66950 <syscall name="flock" groups="descriptor"/> 66951 <syscall name="fork" groups="process"/> 66952 <syscall name="fremovexattr" groups="descriptor"/> 66953 + <syscall name="fsconfig" groups="descriptor,file"/> 66954 <syscall name="fsetxattr" groups="descriptor"/> 66955 + <syscall name="fsmount" groups="descriptor"/> 66956 + <syscall name="fsopen" groups="descriptor"/> 66957 + <syscall name="fspick" groups="descriptor,file"/> 66958 <syscall name="fstat64" groups="descriptor"/> 66959 <syscall name="fstatat64" groups="descriptor,file"/> 66960 <syscall name="fstatfs64" groups="descriptor"/> 66961 @@ -72,16 +103,26 @@ 66962 <syscall name="getdents" groups="descriptor"/> 66963 <syscall name="get_mempolicy" groups="memory"/> 66964 <syscall name="getpeername" groups="network"/> 66965 + <syscall name="getpmsg" groups="network"/> 66966 <syscall name="getsockname" groups="network"/> 66967 <syscall name="getsockopt" groups="network"/> 66968 <syscall name="getxattr" groups="file"/> 66969 - <syscall name="inotify_add_watch" groups="descriptor"/> 66970 + <syscall name="inotify_add_watch" groups="descriptor,file"/> 66971 <syscall name="inotify_init1" groups="descriptor"/> 66972 <syscall name="inotify_init" groups="descriptor"/> 66973 <syscall name="inotify_rm_watch" groups="descriptor"/> 66974 <syscall name="ioctl" groups="descriptor"/> 66975 + <syscall name="io_destroy" groups="memory"/> 66976 + <syscall name="io_setup" groups="memory"/> 66977 + <syscall name="io_uring_enter" groups="descriptor,signal"/> 66978 + <syscall name="io_uring_register" groups="descriptor,memory"/> 66979 + <syscall name="io_uring_setup" groups="descriptor"/> 66980 <syscall name="ipc" groups="ipc"/> 66981 - <syscall name="kill" groups="signal"/> 66982 + <syscall name="kexec_file_load" groups="descriptor"/> 66983 + <syscall name="kill" groups="signal,process"/> 66984 + <syscall name="landlock_add_rule" groups="descriptor"/> 66985 + <syscall name="landlock_create_ruleset" groups="descriptor"/> 66986 + <syscall name="landlock_restrict_self" groups="descriptor"/> 66987 <syscall name="lchown32" groups="file"/> 66988 <syscall name="lchown" groups="file"/> 66989 <syscall name="lgetxattr" groups="file"/> 66990 @@ -98,19 +139,31 @@ 66991 <syscall name="lstat" groups="file"/> 66992 <syscall name="madvise" groups="memory"/> 66993 <syscall name="mbind" groups="memory"/> 66994 + <syscall name="memfd_create" groups="descriptor"/> 66995 + <syscall name="memfd_secret" groups="descriptor"/> 66996 <syscall name="migrate_pages" groups="memory"/> 66997 <syscall name="mincore" groups="memory"/> 66998 <syscall name="mkdirat" groups="descriptor,file"/> 66999 <syscall name="mkdir" groups="file"/> 67000 <syscall name="mknodat" groups="descriptor,file"/> 67001 <syscall name="mknod" groups="file"/> 67002 + <syscall name="mlock2" groups="memory"/> 67003 <syscall name="mlockall" groups="memory"/> 67004 <syscall name="mlock" groups="memory"/> 67005 <syscall name="mmap2" groups="descriptor,memory"/> 67006 <syscall name="mmap" groups="descriptor,memory"/> 67007 + <syscall name="mount_setattr" groups="descriptor,file"/> 67008 <syscall name="mount" groups="file"/> 67009 + <syscall name="move_mount" groups="descriptor,file"/> 67010 <syscall name="move_pages" groups="memory"/> 67011 <syscall name="mprotect" groups="memory"/> 67012 + <syscall name="mq_getsetattr" groups="descriptor"/> 67013 + <syscall name="mq_notify" groups="descriptor"/> 67014 + <syscall name="mq_open" groups="descriptor"/> 67015 + <syscall name="mq_timedreceive" groups="descriptor"/> 67016 + <syscall name="mq_timedreceive_time64" groups="descriptor"/> 67017 + <syscall name="mq_timedsend" groups="descriptor"/> 67018 + <syscall name="mq_timedsend_time64" groups="descriptor"/> 67019 <syscall name="mremap" groups="memory"/> 67020 <syscall name="msgctl" groups="ipc"/> 67021 <syscall name="msgget" groups="ipc"/> 67022 @@ -126,45 +179,98 @@ 67023 <syscall name="oldfstat" groups="descriptor"/> 67024 <syscall name="oldlstat" groups="file"/> 67025 <syscall name="oldstat" groups="file"/> 67026 + <syscall name="oldumount" groups="file"/> 67027 + <syscall name="openat2" groups="descriptor,file"/> 67028 <syscall name="openat" groups="descriptor,file"/> 67029 <syscall name="open_by_handle_at" groups="descriptor"/> 67030 <syscall name="open" groups="descriptor,file"/> 67031 + <syscall name="open_tree" groups="descriptor,file"/> 67032 + <syscall name="osf_fstatfs64" groups="descriptor"/> 67033 + <syscall name="osf_fstatfs" groups="descriptor"/> 67034 + <syscall name="osf_fstat" groups="descriptor"/> 67035 + <syscall name="osf_lstat" groups="file"/> 67036 + <syscall name="osf_mincore" groups="memory"/> 67037 + <syscall name="osf_mremap" groups="memory"/> 67038 + <syscall name="osf_old_fstat" groups="descriptor"/> 67039 + <syscall name="osf_old_killpg" groups="process"/> 67040 + <syscall name="osf_old_lstat" groups="file"/> 67041 + <syscall name="osf_old_stat" groups="file"/> 67042 + <syscall name="osf_sbrk" groups="memory"/> 67043 + <syscall name="osf_select" groups="descriptor"/> 67044 + <syscall name="osf_shmat" groups="ipc,memory"/> 67045 + <syscall name="osf_sigprocmask" groups="signal"/> 67046 + <syscall name="osf_statfs64" groups="file"/> 67047 + <syscall name="osf_statfs" groups="file"/> 67048 + <syscall name="osf_stat" groups="file"/> 67049 + <syscall name="osf_utimes" groups="file"/> 67050 + <syscall name="osf_wait4" groups="process"/> 67051 <syscall name="pause" groups="signal"/> 67052 <syscall name="perf_event_open" groups="descriptor"/> 67053 + <syscall name="pidfd_getfd" groups="descriptor"/> 67054 + <syscall name="pidfd_open" groups="descriptor"/> 67055 + <syscall name="pidfd_send_signal" groups="descriptor,signal,process"/> 67056 <syscall name="pipe2" groups="descriptor"/> 67057 <syscall name="pipe" groups="descriptor"/> 67058 <syscall name="pivot_root" groups="file"/> 67059 + <syscall name="pkey_mprotect" groups="memory"/> 67060 <syscall name="poll" groups="descriptor"/> 67061 + <syscall name="posix_fstatfs" groups="descriptor"/> 67062 + <syscall name="posix_fstat" groups="descriptor"/> 67063 + <syscall name="posix_kill" groups="process"/> 67064 + <syscall name="posix_lstat" groups="file"/> 67065 + <syscall name="posix_madvise" groups="memory"/> 67066 + <syscall name="posix_mmap" groups="descriptor,memory"/> 67067 + <syscall name="posix_munmap" groups="memory"/> 67068 + <syscall name="posix_sbreak" groups="memory"/> 67069 + <syscall name="posix_SGI_madvise" groups="memory"/> 67070 + <syscall name="posix_SGI_mmap" groups="descriptor,memory"/> 67071 + <syscall name="posix_SGI_mprotect" groups="memory"/> 67072 + <syscall name="posix_SGI_msync" groups="memory"/> 67073 + <syscall name="posix_SGI_munmap" groups="memory"/> 67074 + <syscall name="posix_statfs" groups="file"/> 67075 + <syscall name="posix_stat" groups="file"/> 67076 <syscall name="ppoll" groups="descriptor"/> 67077 + <syscall name="ppoll_time64" groups="descriptor"/> 67078 <syscall name="pread64" groups="descriptor"/> 67079 <syscall name="pread" groups="descriptor"/> 67080 + <syscall name="preadv2" groups="descriptor"/> 67081 <syscall name="preadv" groups="descriptor"/> 67082 + <syscall name="process_madvise" groups="descriptor"/> 67083 + <syscall name="process_mrelease" groups="descriptor"/> 67084 <syscall name="pselect6" groups="descriptor"/> 67085 + <syscall name="pselect6_time64" groups="descriptor"/> 67086 + <syscall name="putpmsg" groups="network"/> 67087 <syscall name="pwrite64" groups="descriptor"/> 67088 <syscall name="pwrite" groups="descriptor"/> 67089 + <syscall name="pwritev2" groups="descriptor"/> 67090 <syscall name="pwritev" groups="descriptor"/> 67091 + <syscall name="quotactl_fd" groups="descriptor"/> 67092 <syscall name="quotactl" groups="file"/> 67093 <syscall name="readahead" groups="descriptor"/> 67094 <syscall name="readdir" groups="descriptor"/> 67095 - <syscall name="read" groups="descriptor"/> 67096 <syscall name="readlinkat" groups="descriptor,file"/> 67097 <syscall name="readlink" groups="file"/> 67098 + <syscall name="read" groups="descriptor"/> 67099 <syscall name="readv" groups="descriptor"/> 67100 <syscall name="recvfrom" groups="network"/> 67101 - <syscall name="recv" groups="network"/> 67102 + <syscall name="recvmmsg_time64" groups="network"/> 67103 <syscall name="recvmmsg" groups="network"/> 67104 <syscall name="recvmsg" groups="network"/> 67105 + <syscall name="recv" groups="network"/> 67106 <syscall name="remap_file_pages" groups="memory"/> 67107 <syscall name="removexattr" groups="file"/> 67108 + <syscall name="renameat2" groups="descriptor,file"/> 67109 <syscall name="renameat" groups="descriptor,file"/> 67110 <syscall name="rename" groups="file"/> 67111 + <syscall name="riscv_flush_icache" groups="memory"/> 67112 <syscall name="rmdir" groups="file"/> 67113 <syscall name="rt_sigaction" groups="signal"/> 67114 <syscall name="rt_sigpending" groups="signal"/> 67115 <syscall name="rt_sigprocmask" groups="signal"/> 67116 - <syscall name="rt_sigqueueinfo" groups="signal"/> 67117 + <syscall name="rt_sigqueueinfo" groups="signal,process"/> 67118 <syscall name="rt_sigreturn" groups="signal"/> 67119 <syscall name="rt_sigsuspend" groups="signal"/> 67120 + <syscall name="rt_sigtimedwait_time64" groups="signal"/> 67121 <syscall name="rt_sigtimedwait" groups="signal"/> 67122 <syscall name="rt_tgsigqueueinfo" groups="process,signal"/> 67123 <syscall name="select" groups="descriptor"/> 67124 @@ -172,12 +278,14 @@ 67125 <syscall name="semget" groups="ipc"/> 67126 <syscall name="semop" groups="ipc"/> 67127 <syscall name="semtimedop" groups="ipc"/> 67128 + <syscall name="semtimedop_time64" groups="ipc"/> 67129 <syscall name="sendfile64" groups="descriptor,network"/> 67130 <syscall name="sendfile" groups="descriptor,network"/> 67131 - <syscall name="send" groups="network"/> 67132 <syscall name="sendmmsg" groups="network"/> 67133 <syscall name="sendmsg" groups="network"/> 67134 + <syscall name="send" groups="network"/> 67135 <syscall name="sendto" groups="network"/> 67136 + <syscall name="set_mempolicy_home_node" groups="memory"/> 67137 <syscall name="set_mempolicy" groups="memory"/> 67138 <syscall name="setns" groups="descriptor"/> 67139 <syscall name="setsockopt" groups="network"/> 67140 @@ -198,38 +306,78 @@ 67141 <syscall name="sigreturn" groups="signal"/> 67142 <syscall name="sigsuspend" groups="signal"/> 67143 <syscall name="socketcall" groups="descriptor"/> 67144 - <syscall name="socket" groups="network"/> 67145 <syscall name="socketpair" groups="network"/> 67146 + <syscall name="socket" groups="network"/> 67147 <syscall name="splice" groups="descriptor"/> 67148 <syscall name="ssetmask" groups="signal"/> 67149 <syscall name="stat64" groups="file"/> 67150 <syscall name="statfs64" groups="file"/> 67151 <syscall name="statfs" groups="file"/> 67152 <syscall name="stat" groups="file"/> 67153 + <syscall name="statx" groups="descriptor,file"/> 67154 + <syscall name="svr4_fstatfs" groups="descriptor"/> 67155 + <syscall name="svr4_fstat" groups="descriptor"/> 67156 + <syscall name="svr4_fstatvfs" groups="descriptor"/> 67157 + <syscall name="svr4_fxstat" groups="descriptor"/> 67158 + <syscall name="svr4_kill" groups="process"/> 67159 + <syscall name="svr4_lstat" groups="file"/> 67160 + <syscall name="svr4_lxstat" groups="file"/> 67161 + <syscall name="svr4_mincore" groups="memory"/> 67162 + <syscall name="svr4_mmap" groups="descriptor,memory"/> 67163 + <syscall name="svr4_mprotect" groups="memory"/> 67164 + <syscall name="svr4_munmap" groups="memory"/> 67165 + <syscall name="svr4_sbreak" groups="memory"/> 67166 + <syscall name="svr4_statfs" groups="file"/> 67167 + <syscall name="svr4_stat" groups="file"/> 67168 + <syscall name="svr4_statvfs" groups="file"/> 67169 + <syscall name="svr4_xstat" groups="file"/> 67170 <syscall name="swapoff" groups="file"/> 67171 <syscall name="swapon" groups="file"/> 67172 <syscall name="symlinkat" groups="descriptor,file"/> 67173 <syscall name="symlink" groups="file"/> 67174 + <syscall name="sync_file_range2" groups="descriptor"/> 67175 <syscall name="sync_file_range" groups="descriptor"/> 67176 <syscall name="syncfs" groups="descriptor"/> 67177 + <syscall name="sysv_brk" groups="memory"/> 67178 + <syscall name="sysv_fstatfs" groups="descriptor"/> 67179 + <syscall name="sysv_fstat" groups="descriptor"/> 67180 + <syscall name="sysv_fstatvfs" groups="descriptor"/> 67181 + <syscall name="sysv_fxstat" groups="descriptor"/> 67182 + <syscall name="sysv_kill" groups="process"/> 67183 + <syscall name="sysv_lstat" groups="file"/> 67184 + <syscall name="sysv_lxstat" groups="file"/> 67185 + <syscall name="sysv_madvise" groups="memory"/> 67186 + <syscall name="sysv_mmap64" groups="descriptor,memory"/> 67187 + <syscall name="sysv_mmap" groups="descriptor,memory"/> 67188 + <syscall name="sysv_mprotect" groups="memory"/> 67189 + <syscall name="sysv_msync" groups="memory"/> 67190 + <syscall name="sysv_munmap" groups="memory"/> 67191 + <syscall name="sysv_quotactl" groups="file"/> 67192 + <syscall name="sysv_statfs" groups="file"/> 67193 + <syscall name="sysv_stat" groups="file"/> 67194 + <syscall name="sysv_statvfs" groups="file"/> 67195 + <syscall name="sysv_xstat" groups="file"/> 67196 <syscall name="tee" groups="descriptor"/> 67197 - <syscall name="tgkill" groups="signal"/> 67198 + <syscall name="tgkill" groups="signal,process"/> 67199 <syscall name="timerfd_create" groups="descriptor"/> 67200 + <syscall name="timerfd_gettime64" groups="descriptor"/> 67201 <syscall name="timerfd_gettime" groups="descriptor"/> 67202 - <syscall name="timerfd" groups="descriptor"/> 67203 + <syscall name="timerfd_settime64" groups="descriptor"/> 67204 <syscall name="timerfd_settime" groups="descriptor"/> 67205 - <syscall name="tkill" groups="signal"/> 67206 + <syscall name="timerfd" groups="descriptor"/> 67207 + <syscall name="tkill" groups="signal,process"/> 67208 <syscall name="truncate64" groups="file"/> 67209 <syscall name="truncate" groups="file"/> 67210 <syscall name="umount2" groups="file"/> 67211 <syscall name="umount" groups="file"/> 67212 <syscall name="unlinkat" groups="descriptor,file"/> 67213 <syscall name="unlink" groups="file"/> 67214 - <syscall name="unshare" groups="process"/> 67215 <syscall name="uselib" groups="file"/> 67216 - <syscall name="utime" groups="file"/> 67217 + <syscall name="userfaultfd" groups="descriptor"/> 67218 <syscall name="utimensat" groups="descriptor,file"/> 67219 + <syscall name="utimensat_time64" groups="descriptor,file"/> 67220 <syscall name="utimes" groups="file"/> 67221 + <syscall name="utime" groups="file"/> 67222 <syscall name="vfork" groups="process"/> 67223 <syscall name="vmsplice" groups="descriptor"/> 67224 <syscall name="wait4" groups="process"/> 67225 67226 Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1 67227 672282023-02-27 Pedro Alves <pedro@palves.net> 67229 67230 Autogenerate gdb/syscalls/linux-defaults.xml.in (groups) from strace sources 67231 I noticed that "catch syscall group:process" doesn't catch clone3, 67232 while it does catch clone. 67233 67234 The catch syscall group information is recorded in the 67235 gdb/syscalls/linux-defaults.xml.in file, which says: 67236 67237 <!-- The group field information was based on strace. --> 67238 67239 So I looked at the strace sources, to confirm that clone3 is in fact 67240 recorded in the "process" group there too, and to check what other 67241 syscalls might be missing groups. 67242 67243 After some digging, I found that strace records the group info in C 67244 arrays, with entries like: 67245 ... 67246 [ 61] = { 4, TP, SEN(wait4), "wait4" }, 67247 [ 62] = { 2, TS|TP, SEN(kill), "kill" }, 67248 [ 63] = { 1, 0, SEN(uname), "uname" }, 67249 ... 67250 67251 You can see the current master's table for Linux x86-64 here: 67252 67253 https://github.com/strace/strace/blob/e88e5e9ae6da68f22d15f9be3193b1412ac9aa02/src/linux/x86_64/syscallent.h 67254 67255 The column with TS|TP above is what defines each syscall's groups. So 67256 I wrote a script that extracts this information and generates 67257 linux-defaults.xml.in. 67258 67259 Approved-By: Simon Marchi <simon.marchi@efficios.com> 67260 Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1 67261 672622023-02-27 Clément Chigot <chigot@adacore.com> 67263 67264 gas/testsuite: adjust another test for case insensitive file systems 67265 As 1fafeaac8503eea2f61c3a35f0eef183b7e7cc65, "line.s" and "Line.s" are 67266 identical in case insensitive file systems. Thus, gas doesn't trigger 67267 an input file switch. 67268 67269 gas/ChangeLog: 67270 67271 * testsuite/gas/elf/dwarf-5-macro.s: Change Line.s to Line2.s. 67272 672732023-02-27 Andrew Burgess <aburgess@redhat.com> 67274 67275 gdb: don't treat empty enums as flag enums 67276 In C++ it is possible to use an empty enum as a strong typedef. For 67277 example, a user could write: 67278 67279 enum class my_type : unsigned char {}; 67280 67281 Now my_type can be used like 'unsigned char' except the compiler will 67282 not allow implicit conversion too and from the native 'unsigned char' 67283 type. 67284 67285 This is used in the standard library for things like std::byte. 67286 67287 Currently, when GDB prints a value of type my_type, it looks like 67288 this: 67289 67290 (gdb) print my_var 67291 $1 = (unknown: 0x4) 67292 67293 Which isn't great. This gets worse when we consider something like: 67294 67295 std::vector<my_type> vec; 67296 67297 When using a pretty-printer, this could look like this: 67298 67299 std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)} 67300 67301 Clearly not great. This is described in PR gdb/30148. 67302 67303 The problem here is in dwarf2/read.c, we assume all enums are flag 67304 enums unless we find an enumerator with a non-flag like value. 67305 Clearly an empty enum contains no non-flag values, so we assume the 67306 enum is a flag enum. 67307 67308 I propose adding an extra check here; that is, an empty enum should 67309 never be a flag enum. 67310 67311 With this the above cases look more like: 67312 67313 (gdb) print my_var 67314 $1 = 4 67315 67316 and: 67317 67318 std::vector of length 2, capacity 2 = {2, 4} 67319 67320 Which look much better. 67321 67322 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148 67323 67324 Reviewed-By: Tom Tromey <tom@tromey.com> 67325 673262023-02-27 Benson Muite <benson_muite@emailplus.org> 67327 67328 Do not change the timestamp when updating the gas asconfig file. 67329 PR 28909 * doc/local.mk (asconfig.texi): Use "cp -p" to preserve timestamps. * Makefile.in: Regenerate. 67330 673312023-02-27 Felix Willgerodt <felix.willgerodt@intel.com> 67332 67333 Fix missing "Core was generated by" when loading a x32 corefile. 67334 673352023-02-27 Nick Clifton <nickc@redhat.com> 67336 67337 Updated Serbian translations for gold, gprof and opcodes sub-directories 67338 673392023-02-27 Bruno Larsen <blarsen@redhat.com> 67340 67341 gdb/testsuite: Improve testing of GDB's completion functions 67342 When looking at some failures of gdb.linespec/cp-completion-aliases.exp, 67343 I noticed that when a completion test will fail, it always fails with a 67344 timeout. This is because most completion tests use gdb_test_multiple 67345 and only add a check for the correct output. This commit adds new 67346 options for both, tab and command completion. 67347 67348 For command completion, the new option will check if the prompt was 67349 printed, and fail in this case. This is enough to know that the test has 67350 failed because the check comes after the PASS path. For tab completion, 67351 we have to check if GDB outputted more than just the input line, because 67352 sometimes GDB would have printed a partial line before finishing with 67353 the correct completion. 67354 67355 Approved-By: Tom Tromey <tom@tromey.com> 67356 673572023-02-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 67358 67359 gdb, python: do minor modernization in execute_gdb_command 67360 Use nullptr instead of NULL and boolify two local variables in 67361 execute_gdb_command. 67362 67363 Approved-By: Tom Tromey <tom@tromey.com> 67364 673652023-02-27 GDB Administrator <gdbadmin@sourceware.org> 67366 67367 Automatic date update in version.in 67368 673692023-02-26 Tom Tromey <tom@tromey.com> 67370 67371 Remove expand_symtab_containing_pc 67372 The function expand_symtab_containing_pc is unused; remove it. 67373 Tested by rebuilding. 67374 673752023-02-26 GDB Administrator <gdbadmin@sourceware.org> 67376 67377 Automatic date update in version.in 67378 673792023-02-25 Andrew Burgess <aburgess@redhat.com> 67380 67381 gdb/amd64: replace xmalloc/alloca with gdb::byte_vector 67382 Replace a couple of uses of xmalloc and alloc with a gdb::byte_vector 67383 local variable instead. 67384 67385 There should be no user visible changes after this commit. 67386 67387 Reviewed-By: Tom Tromey <tom@tromey.com> 67388 673892023-02-25 Andrew Burgess <aburgess@redhat.com> 67390 67391 opcodes/m68k: enable libopcodes styling for GDB 67392 The following commit added libopcodes styling for m68k: 67393 67394 commit c22ff449275c91e4842bb10c650e83c572580f65 67395 Date: Tue Feb 14 18:07:19 2023 +0100 67396 67397 opcodes: style m68k disassembler output 67398 67399 but didn't set disassemble_info::created_styled_output in 67400 disassemble.c, which is needed in order for GDB to start using the 67401 libopcodes based styling. 67402 67403 This commit fixes this small oversight. GDB now styles correctly. 67404 674052023-02-25 GDB Administrator <gdbadmin@sourceware.org> 67406 67407 Automatic date update in version.in 67408 674092023-02-24 Khem Raj <raj.khem@gmail.com> 67410 67411 gdbserver/linux-low.cc: Fix a typo in ternary operator 67412 674132023-02-24 Tom Tromey <tom@tromey.com> 67414 67415 Remove struct buffer 67416 I've long wanted to remove 'struct buffer', and thanks to Simon's 67417 earlier patch, I was finally able to do so. My feeling has been that 67418 gdb already has several decent structures available for growing 67419 strings: std::string of course, but also obstack and even objalloc 67420 from BFD and dyn-string from libiberty. The previous patches in this 67421 series removed all the uses of struct buffer, so this one can remove 67422 the code and the remaining #includes. 67423 67424 Don't use struct buffer in top.c 67425 This changes top.c to use std::string rather than struct buffer. Like 67426 the event-top.c change, this is not completely ideal in that it 67427 requires a copy of the string. 67428 67429 Don't use struct buffer in event-top.c 67430 This changes event-top.c to use std::string rather than struct buffer. 67431 This isn't completely ideal, in that it requires a copy of the string 67432 to be made. 67433 67434 Don't use struct buffer in handle_qxfer_threads 67435 This changes handle_qxfer_threads, in gdbserver, to use std::string 67436 rather than struct buffer. 67437 67438 Don't use struct buffer in handle_qxfer_btrace 67439 This changes handle_qxfer_btrace and handle_qxfer_btrace_conf, in 67440 gdbserver, to use std::string rather than struct buffer. 67441 67442 Don't use struct buffer in handle_qxfer_traceframe_info 67443 This changes handle_qxfer_traceframe_info, in gdbserver, to use 67444 std::string rather than struct buffer. 67445 67446 Remove struct buffer from tracefile-tfile.c 67447 This changes tracefile-tfile.c to use std::string rather than struct 67448 buffer. 67449 674502023-02-24 Tom Tromey <tromey@adacore.com> 67451 67452 Write the DWARF index in the background 67453 The new DWARF cooked indexer interacts poorly with the DWARF index 67454 cache. In particular, the cache will require gdb to wait for the 67455 cooked index to be finalized. As this happens in the foreground, it 67456 means that users with this setting enabled will see a slowdown. 67457 67458 This patch changes gdb to write the cache entry a worker thread. (As 67459 usual, in the absence of threads, this work is simply done immediately 67460 in the main thread.) 67461 67462 Some care is taken to ensure that this can't crash, and that gdb will 67463 not exit before the task is complete. 67464 67465 To avoid use-after-free problems, the DWARF per-BFD object explicitly 67466 waits for the index cache task to complete. 67467 67468 To avoid gdb exiting early, an exit observer is used to wait for all 67469 such pending tasks. 67470 67471 In normal use, neither of these waits will be very visible. For users 67472 using "-batch" to pre-generate the index, though, it would be. 67473 However I don't think there is much to be done about this, as it was 67474 the status quo ante. 67475 674762023-02-24 Tom Tromey <tromey@adacore.com> 67477 67478 Only use the per-BFD object to write a DWARF index 67479 The DWARF index does not need access to the objfile or per-objfile 67480 objects when writing -- it's entirely based on the objfile-independent 67481 per-BFD data. 67482 67483 This patch implements this idea by changing the entire API to only be 67484 passed the per-BFD object. This simplifies some lifetime reasoning 67485 for the next patch. 67486 67487 This patch removes some code that ensures that the BFD came from a 67488 file. It seems to me that checking for the existence of a build-id is 67489 good enough for the index cache. 67490 674912023-02-24 Simon Marchi <simon.marchi@polymtl.ca> 67492 67493 gdb: fix parenthesis position in comment 67494 Change-Id: I535b597ab4482378910570d8dd69c090419941eb 67495 674962023-02-24 Clément Chigot <chigot@adacore.com> 67497 67498 testsuite: prune DOS drive letter in test outputs 67499 On DOS systems, absolute paths start with the drive letter. This can 67500 trigger failures in the regexp from dump tests, especially for those 67501 checking for warnings or errors. They are usually skipping everything 67502 before the first ":" as it has to be the file path. 67503 | [^:]*: warning: ... 67504 67505 In order to avoid modifying many regexps to allow such drive letters, 67506 prune them from all the outputs if they are found at the beginning of 67507 a line. 67508 67509 binutils/ChangeLog: 67510 67511 * testsuite/lib/binutils-common.exp (prune_dump_output): New 67512 (run_dump_test): Use it. 67513 67514 ld/ChangeLog: 67515 67516 * testsuite/ld-elf/noinit-sections-2.l: Remove DOS drive letter 67517 handler. 67518 675192023-02-24 Jan Beulich <jbeulich@suse.com> 67520 67521 x86: allow to request ModR/M encoding 67522 Several insns have a (typically shorter) non-ModR/M and a (typically 67523 longer) ModR/M encoding. In most cases the former is used by default. 67524 This isn't too dissimilar from register-only insns sometimes having two 67525 encoding forms. In those cases {load} or {store} can be used to control 67526 the encoding used. Extend this to ModR/M-less encodings which have a 67527 ModR/M counterpart (note that BSWAP hasn't). For insn reading and 67528 writing their (explicit) memory operand, both prefixes are honored; 67529 otherwise only the applicable one is. 67530 67531 Note that for some forms of XCHG, {store} has already been performing 67532 this function, apparently as an unnoticed side effect of adding D to 67533 the template. 67534 675352023-02-24 Jan Beulich <jbeulich@suse.com> 67536 67537 x86: MONITOR/MWAIT are not SSE3 insns 67538 These have their own CPUID bit and hence they should also have their own 67539 separate control. 67540 675412023-02-24 Jan Beulich <jbeulich@suse.com> 67542 67543 x86-64: don't permit LAHF/SAHF with "generic64" 67544 The feature isn't universally available on 64-bit CPUs. 67545 67546 Note that in i386-gen.c:isa_dependencies[] I'm only adding it to models 67547 where I'm certain the functionality exists. For Nocona and Core I'm 67548 uncertain in particular. 67549 675502023-02-24 Jan Beulich <jbeulich@suse.com> 67551 67552 x86: have insns acting on segment selector values allow for consistent operands 67553 While MOV to/from segment register as well as selector storing insns 67554 already permit 32- and 64-bit GPR operands, selector loading insns and 67555 ARPL do not. Split templates accordingly. 67556 675572023-02-24 Jan Beulich <jbeulich@suse.com> 67558 67559 x86: restrict insn templates accepting negative 8-bit immediates 67560 For shifts (but not ordinary rotates) and other cases where an immediate 67561 describes e.g. a bit count or position, allowing negative operands is at 67562 best confusing. An extreme example would be the two rotate-through-carry 67563 insns, where a negative value would _not_ mean rotating the 67564 corresponding number of bits in the other direction. To refuse such, 67565 give meaning to the combination of Imm8 and Imm8S in templates (so far 67566 these weren't used together anywhere). The issue was with 67567 smallest_imm_type() blindly setting .imm8 for signed numbers determined 67568 to fit in a byte. 67569 67570 VPROT{B,W,D,Q} is a little special: The rotate count there is a signed 67571 quantity, so Imm8 is replaced by Imm8S. Adjust affected testcases 67572 accordingly as well. 67573 67574 Another small adjustment to the testsuite is necessary: AAM and AAD were 67575 never sensible to use with 0xffffff90 operands. This should have been an 67576 error. 67577 675782023-02-24 Tom de Vries <tdevries@suse.de> 67579 67580 [gdb/testsuite] Cleanup unnecessary expr from require line 67581 In a recent commit I've added: 67582 ... 67583 require {expr [have_compile_flag -fsplit-stack]} 67584 ... 67585 but actually the expr bit is unnecessary, and we can just use: 67586 ... 67587 require {have_compile_flag -fsplit-stack} 67588 ... 67589 67590 Reported-By: Tom Tromey <tom@tromey.com> 67591 675922023-02-24 Maciej W. Rozycki <macro@embecosm.com> 67593 67594 GDB: Fix out of bounds accesses with limited-length values 67595 Fix accesses to limited-length values in `contents_copy_raw' and 67596 `contents_copy_raw_bitwise' so that they observe the limit of the 67597 original allocation. 67598 67599 Reported by Simon Marchi as a heap-buffer-overflow AddressSanitizer 67600 issue triggered with gdb.ada/limited-length.exp. 67601 67602 Approved-By: Simon Marchi <simon.marchi@efficios.com> 67603 676042023-02-24 Nick Clifton <nickc@redhat.com> 67605 67606 Enhance better_fit() function to prefer function symbols over non-function symbols. 67607 676082023-02-24 Alan Modra <amodra@gmail.com> 67609 67610 PR30155, ld segfault in _bfd_nearby_section 67611 The segfault was a symptom of messing with the absolute section next 67612 field, confusing bfd_section_removed_from_list in linker.c:fix_syms. 67613 That's not all that was going wrong. The INSERT list of output 67614 sections was being inserted into itself, ie. lost from the main 67615 list of linker statements. 67616 67617 PR 30155 67618 * ldlang.c (process_insert_statements): Handle pathological 67619 case of the insert script being inserted before the first 67620 output section statement in the default script. 67621 (output_prev_sec_find): Don't test section owner here. 67622 (insert_os_after): Change parameter to a list union pointer. 67623 (lang_insert_orphan): Test section owner here and adjust 67624 insert_os_after call. 67625 676262023-02-24 Fangrui Song <i@maskray.me> 67627 67628 RISC-V: Add --[no-]relax-gp to ld 67629 --relax enables all relaxations. --no-relax-gp disables GP relaxation to 67630 allow measuring its effect. 67631 67632 The option can test effectiveness of GP relaxation and support some ABI 67633 variants that use GP for other purposes. 67634 67635 Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/298 67636 67637 bfd/ 67638 * elfnn-riscv.c (struct riscv_elf_link_hash_table): Add params. 67639 (riscv_elfNN_set_options): New. 67640 (riscv_info_to_howto_rela): Check relax_gp. 67641 (_bfd_riscv_relax_section): Likewise. 67642 * elfxx-riscv.h (struct riscv_elf_params): New. 67643 (riscv_elf32_set_options): New. 67644 (riscv_elf64_set_options): New. 67645 ld/ 67646 * emultempl/riscvelf.em: Add option parsing. 67647 * testsuite/ld-riscv-elf/code-model-relax-medlow-01-norelaxgp.d: New. 67648 * testsuite/ld-riscv-elf/pcgp-relax-01-norelaxgp.d: New. 67649 * testsuite/ld-riscv-elf/pcgp-relax-02.d: Test --relax --relax-gp can be 67650 used together. 67651 676522023-02-24 GDB Administrator <gdbadmin@sourceware.org> 67653 67654 Automatic date update in version.in 67655 676562023-02-23 Palmer Dabbelt <palmer@rivosinc.com> 67657 67658 gdb/doc: The RISC-V vector registers didn't change 67659 When we merged the GDB vector register support we did it a bit early, 67660 just eating the risk in the very unlikely case that the vector register 67661 names changed. They didn't, so we can now remove the caveat in the docs 67662 that they might. 67663 676642023-02-23 Simon Marchi <simon.marchi@efficios.com> 67665 67666 gdb: remove --disable-gdbmi configure option 67667 I noticed that the --disable-gdbmi option was broken for almost a year 67668 (since 740b42ceb7c "gdb/python/mi: create MI commands using python"). 67669 67670 The problem today is the python/py-cmd.c file. It is included in the 67671 build if Python support is enabled, and it calls into some MI functions 67672 (e.g. insert_mi_cmd_entry). If MI support is disabled, we get some 67673 undefined symbols like: 67674 67675 mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >) 67676 >>> referenced by py-micmd.c 67677 >>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*)) 67678 67679 The python/py-cmd.c file should be included in the build if both Python 67680 and MI support are enabled. It is not a case we support today, but it 67681 could be done with a bit more configure code. However, I think we 67682 should just remove the --disable-gdbmi option, and just include MI 67683 support unconditionally. 67684 67685 Tom Tromey proposed a while ago to remove this option, but it ended 67686 staying: 67687 67688 https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/ 67689 67690 However, there was no strong opposition to remove it. The argument was 67691 just "bah, it doesn't hurt anybody". 67692 67693 But given today's case, I would rather remove complexity rather than add 67694 some. I couldn't find anybody caring deeply for that option, and it's 67695 not like MI adds any external dependency. It's just a bit more code. 67696 67697 Removing the option will not break anybody using --disable-gdbmi (it can 67698 be found in many build scripts [1]), since we don't flag invalid 67699 configure flags. 67700 67701 So, remove the option from configure.ac, and adjust Makefile.in 67702 accordingly to always include the MI objects in the build. 67703 67704 [1] https://github.com/search?q=%22--disable-gdbmi%22&type=code 67705 67706 Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240 67707 Approved-By: Tom Tromey <tom@tromey.com> 67708 677092023-02-23 Tom Tromey <tromey@adacore.com> 67710 67711 Fix Tcl quoting in gdb_assert 67712 The gdb_assert proc under-quotes the expression that is passed in. 67713 This leads to weird code in a couple of spots that tries to 67714 compensate: 67715 67716 gdb_assert {{$all_regs eq $completed_regs}} ... 67717 67718 The fix is to add a bit of quoting when evaluating the expression. 67719 677202023-02-23 Nick Clifton <nickc@redhat.com> 67721 67722 Fix _bfd_elf_find_function so that it can cope with overlapping symbols 67723 677242023-02-23 Simon Marchi <simon.marchi@efficios.com> 67725 67726 gdb: add AMDGPU header files to HFILES_NO_SRCDIR 67727 Commit 18b4d0736bc5 ("gdb: initial support for ROCm platform (AMDGPU) 67728 debugging") missed adding these header files to the HFILES_NO_SRCDIR 67729 list in the Makefile. Fix that now. 67730 67731 Change-Id: Ifd387096aef3d147b51aefa2037da5bf6373ea64 67732 677332023-02-23 Tom Tromey <tromey@adacore.com> 67734 67735 Remove 'eval' from gdb_breakpoint 67736 Now that Tcl has the {*} operator, we can remove the use of eval from 67737 gdb_breakpoint. Tested on x86-64 Fedora 36. 67738 677392023-02-23 Hui Li <lihui@loongson.cn> 67740 67741 gdb: LoongArch: Support reg aliases in info reg command 67742 According to LoongArch ELF ABI specification [1], support the register 67743 aliases in "info register" command. 67744 67745 Without this patch: 67746 ``` 67747 (gdb) info reg a0 67748 Invalid register `a0' 67749 67750 ``` 67751 With this patch: 67752 67753 ``` 67754 (gdb) info reg a0 67755 67756 a0 0x1 1 67757 67758 ``` 67759 [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_register_convention 67760 677612023-02-23 Hui Li <lihui@loongson.cn> 67762 67763 gdb: LoongArch: Modify the result of the info reg command 67764 The "info register" command should only display general registers, 67765 but it shows the information of all registers in the current code, 67766 add loongarch_register_reggroup_p() so that we can get the expected 67767 result. 67768 677692023-02-23 Alexey Lapshin <alexey.lapshin@espressif.com> 67770 67771 bfd: xtensa: fix __stop_SECTION literal drop 67772 677732023-02-23 Nick Clifton <nickc@redhat.com> 67774 67775 Fix the BFD library's find_nearest_line feature to produce consistent results. 67776 PR 30150 67777 * dwarf2.c (comp_unit_contains_address): Renamed to ... (comp_unit_may_contain_address): this, 67778 and added code to return true if the CU's ranges have not yet been computed. 67779 (_bfd_dwarf2_find_nearest_line_with_alt): Use the renamed function, simplifying code in the process. 67780 677812023-02-23 Alan Modra <amodra@gmail.com> 67782 67783 dwarf1 .line SEC_HAS_CONTENTS 67784 * dwarf1.c (parse_line_table): Ignore .line without SEC_HAS_CONTENTS. 67785 Formatting. 67786 677872023-02-23 Alan Modra <amodra@gmail.com> 67788 67789 ip2k: don't look at stab sections without relocs 67790 No need to read contents if we won't do anything. 67791 67792 * elf32-ip2k.c (adjust_all_relocations): Skip stab sections 67793 without relocs. 67794 677952023-02-23 Alan Modra <amodra@gmail.com> 67796 67797 Test SEC_HAS_CONTENTS in relax routines 67798 More places that generally expect instructions, so not zeros. 67799 67800 * coff-sh.c (sh_relax_section, sh_relax_delete_bytes): Exclude 67801 sections without SEC_HAS_CONTENTS set. 67802 * elf-m10200.c (mn10200_elf_relax_section): Likewise. 67803 * elf32-arc.c (arc_elf_relax_section): Likewise. 67804 * elf32-avr.c (elf32_avr_relax_section): Likewise. 67805 * elf32-cr16.c (elf32_cr16_relax_section): Likewise. 67806 * elf32-crx.c (elf32_crx_relax_section): Likewise. 67807 * elf32-epiphany.c (epiphany_elf_relax_section): Likewise. 67808 * elf32-ft32.c (ft32_elf_relax_section): Likewise. 67809 * elf32-h8300.c (elf32_h8_relax_section): Likewise. 67810 * elf32-ip2k.c (ip2k_elf_relax_section): Likewise. 67811 * elf32-m32c.c (m32c_elf_relax_section): Likewise. 67812 * elf32-m68hc11.c (m68hc11_elf_relax_section): Likewise. 67813 * elf32-msp430.c (msp430_elf_relax_section): Likewise. 67814 * elf32-pru.c (pru_elf32_relax_section): Likewise. 67815 * elf32-rl78.c (rl78_elf_relax_section): Likewise. 67816 * elf32-rx.c (elf32_rx_relax_section): Likewise. 67817 * elf32-sh.c (sh_elf_relax_section): Likewise. 67818 (sh_elf_relax_delete_bytes): Likewise. 67819 * elf32-v850.c (v850_elf_relax_section): Likewise. 67820 * elf64-alpha.c (elf64_alpha_relax_section): Likewise. 67821 * elf64-ia64-vms.c (elf64_ia64_relax_section): Likewise. 67822 * elfnn-ia64.c (elfNN_ia64_relax_section): Likewise. 67823 * elfnn-riscv.c (_bfd_riscv_relax_section): Likewise. 67824 * elfxx-mips.c (_bfd_mips_elf_relax_section): Likewise. 67825 678262023-02-23 Alan Modra <amodra@gmail.com> 67827 67828 Test SEC_HAS_CONTENTS before reading section contents 67829 bfd_malloc_and_get_section does size sanity checking before allocating 67830 memory and reading contents. These size checks are not done for bss 67831 style sections, because they typically don't occupy file space and 67832 thus can't be compared against file size. However, if you are 67833 expecting to look at something other than a whole lot of zeros, don't 67834 allow fuzzers to avoid the size checking. 67835 67836 * cofflink.c (process_embedded_commands): Don't look at 67837 sections without SEC_HAS_CONTENTS set. 67838 * cpu-arm.c (bfd_arm_update_notes): Likewise. 67839 (bfd_arm_get_mach_from_notes): Likewise. 67840 * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Likewise. 67841 * elf-hppa.h (elf_hppa_sort_unwind): Likewise. 67842 * elf-m10300.c (mn10300_elf_relax_section): Likewise. 67843 * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. 67844 * elf.c (_bfd_elf_print_private_bfd_data): Likewise. 67845 * elf32-arm.c (bfd_elf32_arm_process_before_allocation): Likewise. 67846 * elf32-avr.c (avr_elf32_load_property_records): Likewise. 67847 * elf32-ppc.c (_bfd_elf_ppc_set_arch): Likewise. 67848 (ppc_elf_get_synthetic_symtab, ppc_elf_relax_section): Likewise. 67849 * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise. 67850 (opd_entry_value, ppc64_elf_edit_opd, ppc64_elf_edit_toc): Likewise. 67851 * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise. 67852 * elflink.c (elf_link_add_object_symbols): Likewise. 67853 (bfd_elf_get_bfd_needed_list): Likewise. 67854 * elfnn-aarch64.c (get_plt_type): Likewise. 67855 * elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise. 67856 * linker.c (_bfd_handle_already_linked): Likewise. 67857 * opncls.c (bfd_get_debug_link_info_1): Likewise. 67858 (bfd_get_alt_debug_link_info, get_build_id): Likewise. 67859 * peXXigen.c (pe_print_idata, pe_print_pdata): Likewise. 67860 (_bfd_XX_print_ce_compressed_pdata, pe_print_reloc): Likewise. 67861 * pei-x86_64.c (pex64_bfd_print_pdata_section): Likewise. 67862 * stabs.c (_bfd_link_section_stabs): Likewise. 67863 (_bfd_discard_section_stabs): Likewise. 67864 * xcofflink.c (_bfd_xcoff_get_dynamic_symtab_upper_bound): Likewise. 67865 (_bfd_xcoff_canonicalize_dynamic_symtab): Likewise. 67866 (_bfd_xcoff_get_dynamic_reloc_upper_bound): Likewise. 67867 (_bfd_xcoff_canonicalize_dynamic_reloc): Likewise. 67868 (xcoff_link_add_dynamic_symbols): Likewise. 67869 (xcoff_link_check_dynamic_ar_symbols): Likewise. 67870 (bfd_xcoff_build_dynamic_sections): Likewise. 67871 678722023-02-23 GDB Administrator <gdbadmin@sourceware.org> 67873 67874 Automatic date update in version.in 67875 678762023-02-22 Pedro Alves <pedro@palves.net> 67877 67878 gdb.reverse/time-reverse.exp: test both time syscall and C time function 67879 Instead of only testing this on systems that have a SYS_time syscall, 67880 test it everywhere using the time(2) C function, and in addition, run 67881 the tests again using the SYS_time syscall. 67882 67883 The C variant ensures that if some platform uses some syscall we are 67884 not aware of yet, we'll still exercise it, and likely fail, at which 67885 point we should teach GDB about the syscall. 67886 67887 The explicit syscall variant is useful on platforms where the C 67888 function does not call a syscall at all by default, e.g., on some 67889 systems the C time function wraps an implementation provided by the 67890 vDSO. 67891 67892 Approved-By: Tom de Vries <tdevries@suse.de> 67893 Change-Id: Id4b755d76577d02c46b8acbfa249d9c31b587633 67894 678952023-02-22 Jan Beulich <jbeulich@suse.com> 67896 67897 x86-64: LAR and LSL don't need REX.W 67898 Just like we suppress emitting REX.W for e.g. MOV from/to segment 67899 register, there's also no need for it for LAR and LSL - these can only 67900 ever return 32-bit values and hence always zero-extend their results 67901 anyway. 67902 67903 While there also drop the redundant Word from the first operand of 67904 the second template each - this is already implied by Reg16. 67905 679062023-02-22 Jan Beulich <jbeulich@suse.com> 67907 67908 x86: optimize BT{,C,R,S} $imm,%reg 67909 In 64-bit mode BT can have REX.W or a data size prefix dropped in 67910 certain cases. Outside of 64-bit mode all 4 insns can have the data 67911 size prefix dropped in certain cases. 67912 679132023-02-22 Alan Modra <amodra@gmail.com> 67914 67915 set bfd_error on make_tempname or make_tempdir failure 67916 * bucomm.c (make_tempname, make_tempdir): Set bfd_error on error. 67917 679182023-02-22 GDB Administrator <gdbadmin@sourceware.org> 67919 67920 Automatic date update in version.in 67921 679222023-02-21 Alan Modra <amodra@gmail.com> 67923 67924 Re: objdump read_section_stabs 67925 Also fix ubsan "applying zero offset to null pointer". 67926 67927 * objdump.c (print_section_stabs): Avoid ubsan warning. 67928 679292023-02-21 Alan Modra <amodra@gmail.com> 67930 67931 Re: objdump read_section_stabs 67932 Commit f9c36cc99518 changed (and renamed) read_section_stabs with one 67933 difference in overall behaviour. Previously read_section_stabs would 67934 return a NULL for an empty section, which was then treated the same as 67935 a missing section. Now an empty section is recognized and dumped. 67936 This leads to NULL stabp and stabs_end in print_section_stabs. Since 67937 stabs_end - STABSIZE is then a pointer to a very large address, the 67938 test "stabp < stabs_end - STABSIZE" succeeds. 67939 67940 * objdump.c (print_section_stabs): Correct STABSIZE comparison. 67941 679422023-02-21 Alan Modra <amodra@gmail.com> 67943 67944 debug_link duplicate file size checks 67945 bfd_malloc_and_get_section does these checks. 67946 67947 * opncls.c (bfd_get_debug_link_info_1): Don't check section 67948 size against file size. 67949 (bfd_get_alt_debug_link_info): Likewise. 67950 679512023-02-21 Tom Tromey <tom@tromey.com> 67952 67953 Issue error on erroneous expression 67954 A while back I discovered that this does not issue an error: 67955 67956 (gdb) p $x = (void * ) 57 67957 $3 = (void *) 0x39 67958 (gdb) p $x + 7 = 3 67959 $6 = (void *) 0x3 67960 67961 This patch fixes the bug. 67962 Regression tested on x86-64 Fedora 36. 67963 67964 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 67965 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19312 67966 679672023-02-21 Philippe Blain <levraiphilippeblain@gmail.com> 67968 67969 gdb: add --with-curses to --configuration output 67970 'gdb --configuration' does not mention if GDB was built with curses. 67971 Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show 67972 --enable-tui (or --disable-tui), but one might want to know if GDB was 67973 built with curses independently of the availability of the TUI. 67974 67975 Since configure.ac uses AC_SEARCH_LIBS to check for the curses library, 67976 we do not get an automatically defined HAVE_LIBCURSES symbol in 67977 config.in. We do have symbols defined by AC_CHECK_HEADERS 67978 (HAVE_CURSES_H, etc.) but it would be cumbersome to use those in 67979 print_gdb_configuration because we would have to check for all 6 symbols 67980 corresponding the 6 headers listed. This would also increase the 67981 maintenance burden if support for other variations of curses are added. 67982 67983 Instead, define 'HAVE_LIBCURSES' ourselves by adding an 67984 'action-if-found' argument to AC_SEARCH_LIBS, and use it in 67985 print_gdb_configuration. 67986 67987 While at it, remove the condition on 'ac_cv_search_waddstr' and set 67988 'curses_found' directly in 'action-if-found'. 67989 67990 Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8 67991 Approved-By: Simon Marchi <simon.marchi@efficios.com> 67992 679932023-02-21 Tom de Vries <tdevries@suse.de> 67994 67995 [gdb/testsuite] Require compilation flags in two gdb.arch/aarch64 test-cases 67996 With test-cases gdb.arch/aarch64-mte-core.exp and gdb.arch/aarch64-pauth.exp I 67997 run into compilation errors due to unsupported compilation flags. 67998 67999 Fix this by requiring the compilation flags, such that I have instead: 68000 ... 68001 UNSUPPORTED: gdb.arch/aarch64-mte-core.exp: require failed: \ 68002 have_compile_flag -march=armv8.5-a+memtag 68003 UNSUPPORTED: gdb.arch/aarch64-pauth.exp: require failed: \ 68004 have_compile_flag -mbranch-protection=pac-ret+leaf 68005 ... 68006 68007 Tested on aarch64-linux. 68008 680092023-02-21 Tom de Vries <tdevries@suse.de> 68010 68011 [gdb/testsuite] Require istarget x86* in gdb.reverse/step-indirect-call-thunk.exp 68012 On aarch64-linux, I run into: 68013 ... 68014 Running gdb.reverse/step-indirect-call-thunk.exp ... 68015 gdb compile failed, gcc: error: unrecognized command line option \ 68016 '-mindirect-branch=thunk'; did you mean '-findirect-inlining'? 68017 gcc: error: unrecognized command line option '-mfunction-return=thunk'; \ 68018 did you mean '-Wfunction-elimination'? 68019 UNTESTED: gdb.reverse/step-indirect-call-thunk.exp: failed to prepare 68020 ... 68021 68022 Fix this by requiring istarget "x86*", similar to what was added in 68023 gdb.base/step-indirect-call-thunk.exp by commit 43127ae5714 ("Fix 68024 gdb.base/step-indirect-call-thunk.exp"), such that we have instead: 68025 ... 68026 UNSUPPORTED: gdb.reverse/step-indirect-call-thunk.exp: require failed: \ 68027 istarget "x86* 68028 ... 68029 68030 Tested on x86_64-linux and aarch64-linux. 68031 680322023-02-21 Tom de Vries <tdevries@suse.de> 68033 68034 [gdb/testsuite] Require -fsplit-stack in gdb.base/morestack.exp 68035 On aarch64-linux, I run into: 68036 ... 68037 gdb compile failed, cc1: error: '-fsplit-stack' is not supported by this \ 68038 compiler configuration 68039 UNTESTED: gdb.base/morestack.exp: failed to prepare 68040 ... 68041 68042 Fix this by requiring -fsplit-stack, such that we have instead: 68043 ... 68044 UNSUPPORTED: gdb.base/morestack.exp: require failed: \ 68045 expr [have_compile_flag -fsplit-stack] 68046 ... 68047 68048 Tested on x86_64-linux and aarch64-linux. 68049 680502023-02-21 Tom de Vries <tdevries@suse.de> 68051 68052 [gdb/testsuite] Require syscall time in gdb.reverse/time-reverse.exp 68053 On aarch64-linux, I run into: 68054 ... 68055 Running gdb.reverse/time-reverse.exp ... 68056 gdb compile failed, gdb.reverse/time-reverse.c: In function 'main': 68057 gdb.reverse/time-reverse.c:39:12: error: 'SYS_time' undeclared \ 68058 (first use in this function); did you mean 'SYS_times'? 68059 syscall (SYS_time, &time_global); 68060 ^~~~~~~~ 68061 SYS_times 68062 gdb.reverse/time-reverse.c:39:12: note: each undeclared identifier is \ 68063 reported only once for each function it appears in 68064 UNTESTED: gdb.reverse/time-reverse.exp: failed to prepare 68065 ... 68066 68067 Fix this by adding a new proc have_syscall, and requiring syscall time, such 68068 that we have instead: 68069 ... 68070 UNSUPPORTED: gdb.reverse/time-reverse.exp: require failed: \ 68071 expr [have_syscall time] 68072 ... 68073 68074 Tested on x86_64-linux and aarch64-linux. 68075 680762023-02-21 Tom de Vries <tdevries@suse.de> 68077 68078 [gdb/testsuite] Require python in gdb.dap/basic-dap.exp 68079 When running test-case gdb.dap/basic-dap.exp with a gdb without python 68080 support, I run into: 68081 ... 68082 builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 \ 68083 -data-directory data-directory -iex set debug dap-log-file dap.log.1 -q \ 68084 -i=dap 68085 >>> {"seq": 1, "type": "request", "command": "initialize"} 68086 Interpreter `dap' unrecognized 68087 ERROR: eof reading json header 68088 ... 68089 68090 Fix this by requiring python in the test-case. 68091 68092 Tested on x86_64-linux, both with a gdb without and with python. 68093 680942023-02-21 Nick Clifton <nickc@redhat.com> 68095 68096 Update the description of the bfd_fill_in_gnu_debuglink_section function 68097 68098 Updated translatios for the bfd and gprof directories. 68099 681002023-02-21 Clément Chigot <chigot@adacore.com> 68101 68102 gas/testsuite: adjust a test for case insensitive file systems 68103 When dealing with case insensitive file systems, ".file line.s" and 68104 ".file Line.s" are identical and thus gas won't change the current 68105 input file. 68106 However, in line.l test, it's expecting to trigger an input file switch. 68107 As the second filename doesn't matter in it, change it to fit for those 68108 file systems. 68109 68110 gas/ChangeLog: 68111 68112 * testsuite/gas/elf/line.l: Change Line.s to Line2.s. 68113 * testsuite/gas/elf/line.s: Adjust output. 68114 681152023-02-21 Luis Machado <luis.machado@arm.com> 68116 68117 [aarch64] Enable pointer authentication support for aarch64 bare metal/kernel mode addresses 68118 At the moment GDB only handles pointer authentication (pauth) for userspace 68119 addresses and if we're debugging a Linux-hosted program. 68120 68121 The Linux Kernel can be configured to use pauth instructions for some 68122 additional security hardening, but GDB doesn't handle this well. 68123 68124 To overcome this limitation, GDB needs a couple things: 68125 68126 1 - The target needs to advertise pauth support. 68127 2 - The hook to remove non-address bits from a pointer needs to be registered 68128 in aarch64-tdep.c as opposed to aarch64-linux-tdep.c. 68129 68130 There is a patch for QEMU that addresses the first point, and it makes 68131 QEMU's gdbstub expose a couple more pauth mask registers, so overall we will 68132 have up to 4 pauth masks (2 masks or 4 masks): 68133 68134 pauth_dmask 68135 pauth_cmask 68136 pauth_dmask_high 68137 pauth_cmask_high 68138 68139 pauth_dmask and pauth_cmask are the masks used to remove pauth signatures 68140 from userspace addresses. pauth_dmask_high and pauth_cmask_high masks are used 68141 to remove pauth signatures from kernel addresses. 68142 68143 The second point is easily addressed by moving code around. 68144 68145 When debugging a Linux Kernel built with pauth with an unpatched GDB, we get 68146 the following backtrace: 68147 68148 #0 __fput (file=0xffff0000c17a6400) at /repos/linux/fs/file_table.c:296 68149 #1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348 68150 #2 0x30008000080ade30 [PAC] in ?? () 68151 #3 0x30d48000080ade30 in ?? () 68152 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 68153 68154 With a patched GDB, we get something a lot more meaningful: 68155 68156 #0 __fput (file=0xffff0000c1bcfa00) at /repos/linux/fs/file_table.c:296 68157 #1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348 68158 #2 0xffff8000080ade30 [PAC] in task_work_run () at /repos/linux/kernel/task_work.c:179 68159 #3 0xffff80000801db90 [PAC] in resume_user_mode_work (regs=0xffff80000a96beb0) at /repos/linux/include/linux/resume_user_mode.h:49 68160 #4 do_notify_resume (regs=regs@entry=0xffff80000a96beb0, thread_flags=4) at /repos/linux/arch/arm64/kernel/signal.c:1127 68161 #5 0xffff800008fb9974 [PAC] in prepare_exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:137 68162 #6 exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:142 68163 #7 el0_svc (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:638 68164 #8 0xffff800008fb9d34 [PAC] in el0t_64_sync_handler (regs=<optimized out>) at /repos/linux/arch/arm64/kernel/entry-common.c:655 68165 #9 0xffff800008011548 [PAC] in el0t_64_sync () at /repos/linux/arch/arm64/kernel/entry.S:586 68166 Backtrace stopped: Cannot access memory at address 0xffff80000a96c0c8 68167 681682023-02-21 Clément Chigot <chigot@adacore.com> 68169 68170 ld/testsuite: don't output to /dev/null 68171 Mingw doesn't have /dev/null and thus "-o /dev/null" will fail. 68172 Currently, all the options are checked using this "-o /dev/null", 68173 resulting in them being disabled on mingw hosts. 68174 Fix that by outputting to a real file for all targets. 68175 68176 ld/ChangeLog: 68177 68178 * testsuite/config/default.exp: Replace "-o /dev/null" by a 68179 file. 68180 681812023-02-21 Alan Modra <amodra@gmail.com> 68182 68183 Both FAIL and PASS "check sections 2"? 68184 * testsuite/ld-checks/checks.exp (check sections 2): Don't 68185 continue on with rest of test past first fail. 68186 68187 ld-libs test on alpha-vms 68188 * testsuite/ld-libs/libs.exp: Don't run for alpha-vms. 68189 681902023-02-21 Alan Modra <amodra@gmail.com> 68191 68192 alpha-*-vms missing libraries 68193 For this: 68194 ./ld-new: cannot find -limagelib: No such file or directory 68195 ./ld-new: cannot find -lstarlet: No such file or directory 68196 ./ld-new: cannot find -lsys$public_vectors: No such file or directory 68197 the logs showed 68198 creating dummy tmpdir/libimagelib: 68199 creating dummy No 68200 creating dummy such 68201 etc. 68202 So rubbish instead of tmpdir/libimagelib.a and the other required libs. 68203 68204 * testsuite/config/default.exp: Correct regex detecting missing 68205 libraries automatically searched by alpha-dec-vms-ld. 68206 682072023-02-21 GDB Administrator <gdbadmin@sourceware.org> 68208 68209 Automatic date update in version.in 68210 682112023-02-20 Tom Tromey <tom@tromey.com> 68212 68213 Redefine FUNCTION in doc.str 68214 FUNCTION is identical to func, so simplify doc.str. 68215 68216 2023-02-17 Tom Tromey <tom@tromey.com> 68217 68218 * doc/doc.str (FUNCTION): Call func. 68219 682202023-02-20 Tom Tromey <tom@tromey.com> 68221 68222 Hoist the SECTION comment in opncls.c 68223 The opening and closing node in BFD starts: 68224 68225 File: bfd.info, [...] 68226 68227 /* Set to N to open the next N BFDs using an alternate id space. */ 68228 extern unsigned int bfd_use_reserved_id; 68229 68230 2.13 Opening and closing BFDs 68231 ============================= 68232 68233 That is, there's a stray C comment and declaration before any other 68234 text or subsections. 68235 68236 This occurs because the code fragment for bfd_use_reserved_id comes 68237 before the SECTION comment. Hoisting it makes this a little nicer. 68238 68239 2023-02-17 Tom Tromey <tom@tromey.com> 68240 68241 * opncls.c: Hoist the SECTION comment. 68242 682432023-02-20 Tom Tromey <tom@tromey.com> 68244 68245 Don't use chew comments for static functions 68246 I found a few static functions in the BFD manual. These can't be 68247 called by any user of the library, so I don't think it's useful to put 68248 them in the manual. This patch removes the chew markup from their 68249 comments. 68250 68251 2023-02-17 Tom Tromey <tom@tromey.com> 68252 68253 * opncls.c (bfd_get_debug_link_info_1, separate_debug_file_exists) 68254 (separate_alt_debug_file_exists, find_separate_debug_file) 68255 (get_build_id, get_build_id_name, check_build_id_file): Don't use 68256 chew comments. 68257 682582023-02-20 Tom Tromey <tom@tromey.com> 68259 68260 Fix formatting of long function description in chew output 68261 Currently, if a function description spans a line, the resulting info 68262 can look like this: 68263 68264 -- Function: long bfd_canonicalize_reloc 68265 (bfd *abfd, asection *sec, arelent **loc, asymbol **syms); Call the 68266 back end associated with the open BFD ABFD and translate the 68267 external form of the relocation information attached to SEC into 68268 the internal canonical form. Place the table into memory at LOC, 68269 68270 That is, the function prototype runs together with the text in an ugly 68271 way. This patch fixes this by introducing a new primitive, so that 68272 the generated Texinfo can be a bit nicer. Now this output looks like: 68273 68274 -- Function: long bfd_canonicalize_reloc (bfd *abfd, asection *sec, 68275 arelent **loc, asymbol **syms); 68276 Call the back end associated with the open BFD ABFD and translate 68277 the external form of the relocation information attached to SEC 68278 68279 2023-02-17 Tom Tromey <tom@tromey.com> 68280 68281 * doc/doc.str (SYNOPSIS): Use collapse_whitespace. 68282 * doc/chew.c (collapse_whitespace): New function. 68283 (main): Register collapse_whitespace. 68284 682852023-02-20 Andreas Schwab <schwab@suse.de> 68286 68287 opcodes: style m68k disassembler output 68288 682892023-02-20 Simon Marchi <simon.marchi@efficios.com> 68290 68291 gdb: revert one erroneous bool-ification change 68292 Commit 42c13555ff88 ("Change value::m_stack to bool") erroneously 68293 changed a `0` to `false` in this call to read_value_memory. This 68294 parameter is `LONGEST bit_offset`, it should stay `0`. 68295 68296 Change-Id: I128df6834cf8055ec6a7051e237e379978d3d651 68297 682982023-02-20 Clément Chigot <chigot@adacore.com> 68299 68300 ld/testsuite: handle Windows drive letter in a noinit test 68301 The regexp in "noinit sections (ld -r)" is skipping the file path before 68302 the first ":". However, on Windows, a path can start with "C:". Adjust 68303 the regexp to allow such cases. 68304 68305 ld/ChangeLog: 68306 68307 * testsuite/ld-elf/noinit-sections-2.l: Allow Windows paths 68308 (starting with C:). 68309 683102023-02-20 Clément Chigot <chigot@adacore.com> 68311 68312 ld/testsuite: adjust to Windows path separator. 68313 In some tests, the path reported on Windows will have a \ instead of a 68314 /. This occurs when a file is concatened with the search path in 68315 ldfile.c.: "ld -Ltmpdir -ltext" will result into "tmpdir\libtext.a". 68316 68317 ld/ChangeLog: 68318 68319 * testsuite/ld-elf/retain5.map: Allow \ path separator. 68320 * testsuite/ld-plugin/plugin-10.d: Likewise. 68321 * testsuite/ld-plugin/plugin-11.d: Likewise. 68322 * testsuite/ld-plugin/plugin-18.d: Likewise. 68323 * testsuite/ld-plugin/plugin-19.d: Likewise. 68324 * testsuite/ld-plugin/plugin-20.d: Likewise. 68325 * testsuite/ld-plugin/plugin-22.d: Likewise. 68326 683272023-02-20 Andrew Burgess <aburgess@redhat.com> 68328 68329 gdb/doc: Consistency fixes for GDB/MI documentation 68330 I noticed two inconsistencies in the GDB/MI documentation, which this 68331 commit addresses: 68332 68333 1. Each MI command is introduced like this: 68334 68335 @subheading The @code{-command-name} Command 68336 68337 Except for a few of the tracing command, which just use: 68338 68339 @subheading -command-name 68340 68341 In this commit I've updated all these trace commands to use the 68342 more common format. 68343 68344 2. Each MI command starts with a @subheading, and then the details 68345 of that command are split up using multiple @subsubheading 68346 entries. 68347 68348 Except for a few commands which use @subheading for the top-level 68349 command, and then continue to use @subheading for each part of 68350 the command description. 68351 68352 In this commit I've updated these to use @subsubheading where 68353 appropriate. 68354 683552023-02-20 Nick Clifton <nickc@redhat.com> 68356 68357 So the linker from producing an export data table when run with --exclude-all-symbols. 68358 PR 30004 * pe-dll.c (pe_dll_build_sections): Do not build an edata section if all symbols are being excluded. 68359 683602023-02-20 Tom de Vries <tdevries@suse.de> 68361 68362 [gdb/symtab] Trust epilogue unwind info for unknown or non-gcc producer 68363 Currently we only trust epilogue unwind info only for gcc >= 4.5.0. 68364 68365 This has the effect that we don't trust epilogue unwind info for: 68366 - unknown producers (CU without DW_AT_producer attribute) 68367 - non-gcc producers (say, clang). 68368 68369 Instead, only distrust epilogue unwind info only for gcc < 4.5.0. 68370 683712023-02-20 Tom de Vries <tdevries@suse.de> 68372 68373 [gdb/symtab] Trust epilogue unwind info for unknown producer (-g0 case) 68374 For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with 68375 .eh_frame section), start using the dwarf2 unwinder instead of the 68376 "amd64 epilogue override" unwinder, by returning true in 68377 compunit_epilogue_unwind_valid for cust == nullptr. 68378 68379 This has effect both on the amd64 and i386 targets, but only add amd64 68380 test-case gdb.base/unwind-on-each-insn-amd64-2.exp. 68381 683822023-02-20 Tom de Vries <tdevries@suse.de> 68383 68384 [gdb/tdep] Add amd64/i386 epilogue override unwinders 68385 For amd64 the current frame-unwinders are: 68386 ... 68387 $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" 68388 The target architecture is set to "i386:x86-64". 68389 dummy DUMMY_FRAME 68390 dwarf2 tailcall TAILCALL_FRAME 68391 inline INLINE_FRAME 68392 python NORMAL_FRAME 68393 amd64 epilogue NORMAL_FRAME 68394 dwarf2 NORMAL_FRAME 68395 dwarf2 signal SIGTRAMP_FRAME 68396 amd64 sigtramp SIGTRAMP_FRAME 68397 amd64 prologue NORMAL_FRAME 68398 ... 68399 68400 For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with 68401 .eh_frame section), we'd like to start using the dwarf2 unwinder instead of 68402 the "amd64 epilogue" unwinder, by returning true in 68403 compunit_epilogue_unwind_valid for cust == nullptr. 68404 68405 But we'd run into the following problem for a -g0 68406 -fno-asynchronous-unwind-tables (without .debug_info and .eh_frame section) 68407 exec: 68408 - the "amd64 epilogue" unwinder would not run 68409 (because compunit_epilogue_unwind_valid () == true) 68410 - the dwarf2 unwinder would also not run 68411 (because there's no .eh_frame info). 68412 68413 Fix this by: 68414 - renaming the "amd64 epilogue" unwinder to "amd64 epilogue override", and 68415 - adding a fallback "amd64 epilogue" after the dwarf unwinders, 68416 while making sure that only one of the two is active. Likewise for i386. NFC. 68417 68418 For amd64, this results in this change: 68419 ... 68420 $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" 68421 The target architecture is set to "i386:x86-64". 68422 dummy DUMMY_FRAME 68423 dwarf2 tailcall TAILCALL_FRAME 68424 inline INLINE_FRAME 68425 python NORMAL_FRAME 68426 -amd64 epilogue NORMAL_FRAME 68427 +amd64 epilogue override NORMAL_FRAME 68428 dwarf2 NORMAL_FRAME 68429 dwarf2 signal SIGTRAMP_FRAME 68430 +amd64 epilogue NORMAL_FRAME 68431 amd64 sigtramp SIGTRAMP_FRAME 68432 amd64 prologue NORMAL_FRAME 68433 ... 68434 68435 And for i386: 68436 ... 68437 $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" 68438 The target architecture is set to "i386". 68439 dummy DUMMY_FRAME 68440 dwarf2 tailcall TAILCALL_FRAME 68441 iline INLINE_FRAME 68442 -i386 epilogue NORMAL_FRAME 68443 +i386 epilogue override NORMAL_FRAME 68444 dwarf2 NORMAL_FRAME 68445 dwarf2 signal SIGTRAMP_FRAME 68446 +i386 epilogue NORMAL_FRAME 68447 i386 stack tramp NORMAL_FRAME 68448 i386 sigtramp SIGTRAMP_FRAME 68449 i386 prologue NORMAL_FRAME 68450 ... 68451 684522023-02-20 Tom de Vries <tdevries@suse.de> 68453 68454 [gdb/tdep] Fix amd64/i386_stack_frame_destroyed_p 68455 The use of compunit_epilogue_unwind_valid in both amd64_stack_frame_destroyed_p 68456 and i386_stack_frame_destroyed_p is problematic, in the sense that the 68457 functions no longer match their documented behaviour. 68458 68459 Fix this by moving the use of compunit_epilogue_unwind_valid to 68460 amd64_epilogue_frame_sniffer and i386_epilogue_frame_sniffer. No functional 68461 changes. 68462 684632023-02-20 Tom de Vries <tdevries@suse.de> 68464 68465 [gdb/symtab] Factor out compunit_epilogue_unwind_valid 68466 Factor out compunit_epilogue_unwind_valid from both 68467 amd64_stack_frame_destroyed_p and i386_stack_frame_destroyed_p. No functional 68468 changes. 68469 68470 Also add a comment in the new function about the assumption that in absence of 68471 producer information, epilogue unwind info is invalid. 68472 68473 Approved-By: Tom Tromey <tom@tromey.com> 68474 684752023-02-20 Tom de Vries <tdevries@suse.de> 68476 68477 [gdb/testsuite] Add xfail case in gdb.python/py-record-btrace.exp 68478 I came across: 68479 ... 68480 gdb) PASS: gdb.python/py-record-btrace.exp: prepare record: stepi 100 68481 python insn = r.instruction_history^M 68482 warning: Non-contiguous trace at instruction 1 (offset = 0x3e10).^M 68483 (gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: python insn = r.i\ 68484 nstruction_history 68485 ... 68486 68487 I'm assuming it's the same root cause as for the already present XFAIL. 68488 68489 Fix this by recognizing above warning in the xfail regexp. 68490 68491 Tested on x86_64-linux, although sofar I was not able to trigger the warning 68492 again. 68493 68494 Approved-By: Markus T. Metzger <markus.t.metzger@intel.com> 68495 684962023-02-20 Tom de Vries <tdevries@suse.de> 68497 68498 [gdb/testsuite] Fix gdb.threads/schedlock.exp for gcc 4.8.5 68499 Since commit 9af467b8240 ("[gdb/testsuite] Fix gdb.threads/schedlock.exp on 68500 fast cpu"), the test-case fails for gcc 4.8.5. 68501 68502 The problem is that for gcc 4.8.5, the commit turned a two-line loop: 68503 ... 68504 (gdb) next 68505 78 while (*myp > 0) 68506 (gdb) next 68507 81 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; 68508 (gdb) next 68509 78 while (*myp > 0) 68510 ... 68511 into a three-line loop: 68512 ... 68513 (gdb) next 68514 83 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; 68515 (gdb) next 68516 84 cnt++; 68517 (gdb) next 68518 85 } 68519 (gdb) next 68520 83 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; 68521 (gdb) 68522 ... 68523 and the test-case doesn't expect this. 68524 68525 Fix this by reverting back to the original loop shape as much as possible by: 68526 - removing the cnt++ line 68527 - replacing "while (1)" with "while (one)", where one is a volatile variable 68528 set to 1. 68529 68530 Tested on x86_64-linux, using compilers: 68531 - gcc 4.8.5, 7.5.0, 12.2.1 68532 - clang 4.0.1, 13.0.1 68533 685342023-02-20 Alan Modra <amodra@gmail.com> 68535 68536 In-memory nested archives 68537 alpha-linuxecoff has compressed archives that are decompressed to a 68538 bfd-in-memory. We'd need to handle quite a lot of corner cases to 68539 support nesting of such archives, so just stop it before we run into 68540 segfaults later. 68541 68542 * opncls.c (_bfd_new_bfd_contained_in): Prohibit nested 68543 archives in memory. 68544 685452023-02-20 GDB Administrator <gdbadmin@sourceware.org> 68546 68547 Automatic date update in version.in 68548 685492023-02-19 Tom Tromey <tom@tromey.com> 68550 68551 Convert contained_in to method 68552 This converts contained_in to be a method of block. 68553 68554 Make block members 'private' 68555 This changes block to make the data members 'private'. 68556 68557 Remove allocate_block and allocate_global_block 68558 This removes allocate_block and allocate_global_block in favor of 68559 simply calling 'new'. 68560 68561 Have global_block inherit from block 68562 This changes global_block to inherit from block, which is what was 68563 always intended. 68564 68565 Use 'new' for block and global_block 68566 This changes block and global_block to add initializers, and then to 68567 use 'new' for allocation. 68568 685692023-02-19 Tom Tromey <tom@tromey.com> 68570 68571 Fix memory leak in mdebugread.c 68572 mdebugread.c allocates blocks on the heap. However, this is a memory 68573 leak if the corresponding objfile is ever destroyed. 68574 68575 This patch changes this code to use allocate_block instead, fixing a 68576 FIXME from 2003. 68577 68578 I don't know how to test this patch. 68579 685802023-02-19 Tom Tromey <tom@tromey.com> 68581 68582 Remove ALL_BLOCK_SYMBOLS 68583 This removes ALL_BLOCK_SYMBOLS in favor of foreach. 68584 68585 Remove ALL_BLOCK_SYMBOLS_WITH_NAME 68586 This removes ALL_BLOCK_SYMBOLS_WITH_NAME in favor of foreach. 68587 68588 Convert explicit iterator uses to foreach 68589 This converts most existing explicit uses of block_iterator to use 68590 foreach with the range iterator instead. 68591 68592 Introduce a block iterator wrapper 68593 This introduces a C++-style iterator that wraps the existing 68594 block_iterator. It also adds a range adapter. These will be used in 68595 a later patch. 68596 68597 Combine both styles of block iterator 68598 This merges the two styles of block iterator, having the 68599 initialization API decide which to use based on an optional parameter. 68600 68601 Store 'name' in block_iterator 68602 This changes the block_iterator to store the 'name' that is used by 68603 block_iter_match_next. This avoids any problem where the name could 68604 be passed inconsistently, and also makes the subsequent patches easier 68605 to understand. 68606 68607 Convert block_static_link to method 68608 This converts block_static_link to be a method. This was mostly 68609 written by script. 68610 68611 Convert set_block_compunit_symtab to method 68612 This converts set_block_compunit_symtab to be a method. This was 68613 mostly written by script. 68614 68615 Convert block_static_block and block_global_block to methods 68616 This converts block_static_block and block_global_block to be methods. 68617 This was mostly written by script. It was simpler to convert them at 68618 the same time because they're often used near each other. 68619 68620 Convert block_containing_function to method 68621 This converts block_containing_function to be a method. This was 68622 mostly written by script. 68623 68624 Convert block_linkage_function to method 68625 This converts block_linkage_function to be a method. This was mostly 68626 written by script. 68627 68628 Convert more block functions to methods 68629 This converts block_scope, block_set_scope, block_using, and 68630 block_set_using to be methods. These are all done at once to make it 68631 easier to also convert block_initialize_namespace at the same time. 68632 This was mostly written by script. 68633 68634 Convert block_inlined_p to method 68635 This converts block_inlined_p to be a method. This was mostly written 68636 by script. 68637 68638 Convert block_gdbarch to method 68639 This converts block_gdbarch to be a method. This was mostly written 68640 by script. 68641 68642 Convert block_objfile to method 68643 This converts block_objfile to be a method. This was mostly written 68644 by script. 68645 68646 Don't allow NULL as an argument to block_global_block 68647 block_global_block has special behavior when the block is NULL. 68648 Remove this and patch up the callers instead. 68649 68650 Don't allow NULL as an argument to block_static_block 68651 block_static_block has special behavior when the block is NULL. 68652 Remove this and patch up the callers instead. 68653 68654 Don't allow NULL as an argument to block_using 68655 block_using has special behavior when the block is NULL. 68656 Remove this. No caller seems to be affected. 68657 68658 Don't allow NULL as an argument to block_scope 68659 block_scope has special behavior when the block is NULL. 68660 Remove this and patch up the callers instead. 68661 68662 Avoid extra allocations in block 68663 block_set_scope and block_set_using unconditionally allocate the block 68664 namespace object. However, this isn't truly needed, so arrange to 68665 only allocate when it is. 68666 68667 Rearrange block.c to avoid a forward declaration 68668 Moving block_initialize_namespace before its callers lets us avoid a 68669 forward declaration. 68670 686712023-02-19 Alan Modra <amodra@gmail.com> 68672 68673 Buffer overflow in evax_bfd_print_eobj 68674 * vms-alpha.c (evax_bfd_print_eobj): Rewrite header handling, 68675 sanity checking rec_len. Check bfd_malloc return. 68676 686772023-02-19 Tom Tromey <tom@tromey.com> 68678 68679 Avoid memory leak in chew 68680 An earlier patch of mine introduced a memory leak in chew. The bug 68681 was that the new "variable" word didn't free the following word. This 68682 patch fixes it by arranging to transfer ownership of the name to the 68683 variable itself. 68684 68685 * doc/chew.c (add_variable): New function, from 68686 add_intrinsic_variable. 68687 (add_intrinsic_variable): Call add_variable. 68688 (compile): Call add_variable. 68689 686902023-02-19 GDB Administrator <gdbadmin@sourceware.org> 68691 68692 Automatic date update in version.in 68693 686942023-02-18 Tom Tromey <tom@tromey.com> 68695 68696 Fix "start" for D, Rust, etc 68697 The new DWARF indexer broke "start" for some languages. 68698 68699 For D, it is broken because, while the code in cooked_index_shard::add 68700 specifically excludes Ada, it fails to exclude D. This means that the 68701 C "main" will be detected as "main" here -- whereas what is intended 68702 is for the code in find_main_name to use d_main_name to find the name. 68703 68704 The Rust compiler, on the other hand, uses DW_AT_main_subprogram. 68705 However, the code in dwarf2_build_psymtabs_hard fails to create a 68706 fully-qualified name, so the name always ends up as plain "main". 68707 68708 For D and Ada, a very simple approach suffices: remove the check 68709 against "main" from cooked_index_shard::add. This also has the 68710 benefit of slightly speeding up DWARF indexing. I assume this 68711 approach will work for Pascal and Modula-2 as well, but I don't have a 68712 way to test those at present. 68713 68714 For Rust, though, this is not sufficient. And, computing the 68715 fully-qualified name in dwarf2_build_psymtabs_hard will crash, because 68716 cooked_index_entry::full_name uses the canonical name -- and that is 68717 not computed until after canonicalization. 68718 68719 However, we don't want to wait for canonicalization to be done before 68720 computing the main name. That would remove any benefit from doing 68721 canonicalization is the background. 68722 68723 This patch solves this dilemma by noticing that languages using 68724 DW_AT_main_subprogram are, currently, disjoint from languages 68725 requiring canonicalization. Because of this, we can add a parameter 68726 to full_name to let us avoid crashes, slowdowns, and races here. 68727 68728 This is kind of tricky and ugly, so I've tried to comment it 68729 sufficiently. 68730 68731 While doing this, I had to change gdb.dwarf2/main-subprogram.exp. A 68732 different possibility here would be to ignore the canonicalization 68733 needs of C in this situation, because those only affect certain types. 68734 However, I chose this approach because the test case is artificial 68735 anyhow. 68736 68737 A long time ago, in an earlier threading attempt, I changed the global 68738 current_language to be a function (hidden behind a macro) to let us 68739 attempt lazily computing the current language. Perhaps this approach 68740 could still be made to work. However, that also seemed rather tricky, 68741 more so than this patch. 68742 68743 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 68744 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116 68745 687462023-02-18 Tom Tromey <tom@tromey.com> 68747 68748 Fix crash in go_symbol_package_name 68749 go_symbol_package_name package name asserts that it is only passed a 68750 Go symbol, but this is not enforced by one caller. It seems simplest 68751 to just check and return early in this case. 68752 68753 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17876 68754 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 68755 687562023-02-18 Tom Tromey <tom@tromey.com> 68757 68758 Avoid manual memory management in go-lang.c 68759 I noticed a couple of spots in go-lang.c that could be improved by 68760 using unique_ptr. 68761 68762 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 68763 687642023-02-18 GDB Administrator <gdbadmin@sourceware.org> 68765 68766 Automatic date update in version.in 68767 687682023-02-17 Andrew Burgess <aburgess@redhat.com> 68769 68770 gdb: fix regression in gdb.xml/maint_print_struct.exp 68771 A regression in gdb.xml/maint_print_struct.exp was introduced with 68772 commit: 68773 68774 commit 81b86eced24f905545b58aa6c27478104c364976 68775 Date: Fri Jan 6 09:30:40 2023 -0700 68776 68777 Do not record a rejected target description 68778 68779 The test relied on an invalid target description being stored within 68780 the tdesc_info of the current inferior, the above commit stopped this 68781 behaviour. 68782 68783 Update the test to check that the invalid architecture is NOT stored, 68784 and then check printing the target description directly from the 68785 file. 68786 68787 Approved-By: Tom Tromey <tromey@adacore.com> 68788 687892023-02-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 68790 68791 gprofng: fix Dwarf reader for DW_TAG_subprogram 68792 gprofng/ChangeLog 68793 2023-02-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 68794 68795 * src/Dwarf.cc: Skip DW_TAG_subprogram when DW_AT_declaration is 1. 68796 687972023-02-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 68798 68799 gprofng: PR30036 Build failure on aarch64 w/ glibc: symbol `pwrite64' is already defined 68800 gprofng/ChangeLog 68801 2023-02-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 68802 68803 PR gprofng/30036 68804 * libcollector/iotrace.c: Define creat64 and pwrite64 only when 68805 __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not defined. 68806 * libcollector/mmaptrace.c: Likewise for mmap64. 68807 688082023-02-17 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 68809 68810 Fix multi-threaded debugging under AIX 68811 Multi-threaded debugging using the libpthdebug debug interface 68812 is currently broken due to multiple issues. 68813 68814 When debugging a single inferior, we were getting assertion 68815 failures in get_aix_thread_info as no tp->priv structure was 68816 allocated for the main thread. 68817 68818 We fixed this by switching the main 68819 thread from a (pid, 0, 0) ptid_t to a (pid, 0, tid) ptid_t and 68820 allocaing the tp->priv structure in sync_threadlists. 68821 68822 As a result, the switch_to_thread call in pdc_read_data could 68823 now fail since the main thread no longer uses (pid, 0, 0). 68824 68825 So we replaced the call by only switching inferior_ptid, the current 68826 inferior, and the current address space (like proc-service.c). 68827 Add similar switching to pdc_write_data where it was missing 68828 completely. 68829 68830 When debugging multiple inferiors, an additional set of 68831 problems prevented correct multi-threaded debugging: 68832 68833 First of all, aix-thread.c used to have a number of global 68834 variables holding per-inferior information. 68835 68836 We switched hese 68837 to a per-inferior data structure instead. 68838 68839 Also, sync_threadlists was getting confused as we were 68840 comparing the list of threads returned by libpthdebug 68841 for *one* process with GDB's list of threads for *all* 68842 processes. Now we only use he GDB threads of the current 68843 inferior instead. 68844 68845 We also skip calling pd_activate 68846 from pd_enable if that in_initial_library_scan flag is 68847 true for the current inferior. 68848 68849 Finally, the presence of the thread library in any but 68850 the first inferior was not correctly detected due to a 68851 bug in solib-aix.c, where the BFD file name for shared 68852 library members was changed when the library was loaded 68853 for the first time, which caused the library to no longer 68854 be recognized by name when loaded a second time. 68855 688562023-02-17 Tom Tromey <tromey@adacore.com> 68857 68858 Remove two unnecessary returns in ada-lang.c 68859 I found a couple of spots in ada-lang.c where a return follows a call 68860 to error. These are unnecessary because error never returns. 68861 688622023-02-17 Tom de Vries <tdevries@suse.de> 68863 68864 [gdb/testsuite] Simplify gdb.arch/amd64-disp-step-avx.exp 68865 On SLE-11, with glibc 2.11.3, I run into: 68866 ... 68867 (gdb) PASS: gdb.arch/amd64-disp-step-avx.exp: vex3: \ 68868 var128 has expected value after 68869 continue^M 68870 Continuing.^M 68871 ^M 68872 Program received signal SIGSEGV, Segmentation fault.^M 68873 0x0000000000400283 in _exit (status=0) at \ 68874 ../sysdeps/unix/sysv/linux/_exit.c:33^M 68875 33 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.^M 68876 (gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: \ 68877 continue until exit at amd64-disp-step-avx 68878 ... 68879 68880 This is not related to gdb, we get the same result by just running the exec. 68881 68882 The problem is that the test-case: 68883 - calls glibc's _exit, and 68884 - uses -nostartfiles -static, putting the burden for any necessary 68885 initialization for calling glibc's _exit on the test-case itself. 68886 68887 So, when we get to the second insn in _exit: 68888 ... 68889 000000000040acb0 <_exit>: 68890 40acb0: 48 63 d7 movslq %edi,%rdx 68891 40acb3: 64 4c 8b 14 25 00 00 mov %fs:0x0,%r10 68892 ... 68893 no glibc-related initialization is done, and we run into the segfault. 68894 68895 Adding this (borrowed from __libc_start_main) in _start in the .S file is 68896 sufficient to fix it: 68897 ... 68898 .rept 200 68899 nop 68900 + call __pthread_initialize_minimal 68901 .endr 68902 ... 68903 But that already doesn't compile with say glibc 2.31, and regardless I think 68904 this sort of fix is too fragile. 68905 68906 We could of course fix this by simply not running to exit. But ideally we'd 68907 have an exec that doesn't segfault when you just run it. 68908 68909 Alternatively, we could hand-code an _exit syscall and bypass glibc 68910 all together. But I'd rather fix this in a way that simplifies the test-case. 68911 68912 Taking a step back, the -nostartfiles -static was added to address that the 68913 xmm registers were not zero at main (which AFAICT is a valid thing to happen). 68914 68915 [ The change itself silently broke the test-case, needing further fixing by 68916 commit 40310f30a51 ("gdb: make gdb.arch/amd64-disp-step-avx.exp actually test 68917 displaced stepping"). ] 68918 68919 Instead, simplify things by reverting to the original situation: 68920 - no -nostartfiles -static compilation flags, 68921 - no _start in the .S file, 68922 - use exit instead of _exit in the .S file, 68923 and fix the original problem by setting the xmm registers to zero rather than 68924 checking that they're zero. 68925 68926 Now that we're no longer forcing -static, add nopie to the flags to prevent 68927 compilation failure with target board unix/-fPIE/-pie. 68928 68929 Tested on x86_64-linux. 68930 68931 PR testsuite/30132 68932 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30132 68933 689342023-02-17 Alan Modra <amodra@gmail.com> 68935 68936 ld test asciz and ascii fails 68937 Fix these fails: 68938 alpha-dec-vms +FAIL: ld-scripts/asciz 68939 alpha-dec-vms +FAIL: ld-scripts/ascii 68940 i386-go32 +FAIL: ld-scripts/asciz 68941 sh-coff +FAIL: ld-scripts/asciz 68942 68943 It's better to positively select targets for .section support than to 68944 try to exclude all targets that don't. Make a new is_coff_format so 68945 we can easily select such. 68946 68947 binutils/ 68948 * testsuite/lib/binutils-common.exp (is_coff_format): New. 68949 ld/ 68950 * testsuite/ld-scripts/ascii.d: Use is_elf_format and 68951 is_coff_format to select targets, exclude ti coff. 68952 * testsuite/ld-scripts/asciz.d: Likewise. Accept trailing zeros. 68953 689542023-02-17 Alan Modra <amodra@gmail.com> 68955 68956 Wild pointer reads in _bfd_ecoff_locate_line 68957 * ecofflink.c (mk_fdrtab): Sanity check fdr procedure descriptor 68958 pointer and isymBase. Set fdrtab_len after possible discards. 68959 Use size_t vars and catch possible size overflows. 68960 689612023-02-17 GDB Administrator <gdbadmin@sourceware.org> 68962 68963 Automatic date update in version.in 68964 689652023-02-16 Alan Modra <amodra@gmail.com> 68966 68967 PR30046, power cmpi leads to unknown architecture 68968 PowerPC ELF always uses bfd_arch_powerpc, so we shouldn't allow the 68969 gas -mpwr, -mpwr2 or -mpwrx options to choose bfd_arch_rs6000. 68970 Given the possible values of ppc_cpu, I think the as_fatal at the end 68971 of ppc_arch will never be reached, so it can be deleted and the code 68972 simplified a little. 68973 68974 PR 30046 68975 * config/tc-ppc.c (ppc_arch): Return bfd_arch_powerpc for ELF. 68976 Delete dead code. 68977 689782023-02-16 Tom Tromey <tromey@adacore.com> 68979 68980 Rename parameter of create_ada_exception_catchpoint 68981 create_ada_exception_catchpoint has a parameter named "disabled", but 68982 both its callers and callees use it to mean "enabled". This is 68983 confusing, so this patch renames the parameter. 68984 689852023-02-16 Tom Tromey <tom@tromey.com> 68986 68987 Update the 'g' packet documentation 68988 The 'g' packet documentation references a macro that no longer exists, 68989 and it also claims that the 'x' response for an unavailable register 68990 is limited to trace frames. This patch updates the documentation to 68991 reflect what I think is currently correct. 68992 68993 Co-Authored-By: Pedro Alves <pedro@palves.net> 68994 Approved-By: Eli Zaretskii <eliz@gnu.org> 68995 Change-Id: I863baa3b9293059cfd4aa3d534602cbcb693ba87 68996 689972023-02-16 Nick Clifton <nickc@redhat.com> 68998 68999 Add support for the ASCII directive inside linker scripts. 69000 * ldlex.l: Add ASCII token. 69001 * ldgram.y: Add parsing of the ASCII command. 69002 * ldlang.c (lang_add_string): Add maximum size parameter. Move escape character handling code into separate function. 69003 * ldlang.h (lang_add_string): Update prototype. 69004 * NEWS: Mention the new feature. 69005 * ld.texi (Output Section Data): Document the new directives. 69006 * testsuite/ld-scripts/asciz.t: Adjust to work on more architectures and to test more aspects of the ASCIZ directive. 69007 * testsuite/ld-scripts/asciz.d: Adjust to match the changes to the test linker script. 69008 * testsuite/ld-scripts/ascii.d: New test driver. 69009 * testsuite/ld-scripts/ascii.s: New test assembler source. 69010 * testsuite/ld-scripts/ascii.t: New test script. 69011 * testsuite/ld-scripts/script.exp: Run the new test. 69012 690132023-02-16 Tom Tromey <tromey@adacore.com> 69014 69015 Constify ada_main_name 69016 Unlike the other *_main_name functions, ada_main_name returns a 69017 non-const "char *". This is strange, though, because the caller 69018 should not in fact modify or free this pointer. This patch changes 69019 this function to constify its return type. 69020 69021 Remove unused declaration from ada-lang.h 69022 I stumbled across this declaration in ada-lang.h. I don't know what 69023 function did, but it no longer exists, so remove the declaration. 69024 Tested by rebuilding. 69025 690262023-02-16 Alan Modra <amodra@gmail.com> 69027 69028 Delete PROGRESS macros 69029 I don't see much point in cluttering the source with the PROGRESS 69030 macros, which of course do nothing at all with the definitions in 69031 progress.h. progress.h is unchanged apart from the copyright comment 69032 since commit d4d4c53c68f0 in 1994. 69033 69034 binutils/ 69035 * ar.c: Don't include progress.h, or invoke PROGRESS macros. 69036 * nm.c: Likewise. 69037 * objcopy.c: Likewise. 69038 * objdump.c: Likewise. 69039 gas/ 69040 * as.h: Don't include progress.h. 69041 * as.c: Don't invoke PROGRESS macros. 69042 * write.c: Likewise. 69043 include/ 69044 * progress.h: Delete. 69045 ld/ 69046 * ldmain.c: Don't include progress.h, or invoke PROGRESS macros. 69047 690482023-02-16 Alan Modra <amodra@gmail.com> 69049 69050 gas_init 69051 Rename gas_late_init to plain gas_init, to reinforce the idea that 69052 this is where the bulk of gas initialisation belongs. Also reorder 69053 some initialisation. 69054 69055 * as.c (gas_init): Rename from gas_late_init. Open output 69056 file and arrange for dump_statistics to be called here rather 69057 than in main. Create .gasversion. local symbol earlier, 69058 because we can. 69059 690602023-02-16 Jan Beulich <jbeulich@suse.com> 69061 69062 RISC-V: as_warn() already emits a newline 69063 Therefore there shouldn't be any at the end of the format string. 69064 690652023-02-16 Andrew Burgess <aburgess@redhat.com> 69066 69067 gdb/doc: document MI -remove-inferior command 69068 Back in 2010 the -remove-inferior command was added in commit 69069 a79b8f6ea8c2, unfortunately this command was never added to the 69070 documentation. 69071 69072 This commit addresses that oversight. 69073 69074 Approved-By: Eli Zaretskii <eliz@gnu.org> 69075 690762023-02-16 Jan Beulich <jbeulich@suse.com> 69077 69078 x86/gas: replace inappropriate assertion when parsing registers 69079 PR gas/30117 69080 Once a symbol had its expression evaluated, the "segment" of the symbol 69081 may be reg_section if a register is merely involved in the expression, 69082 not just when the expression references a "plain" register. Therefore 69083 the first of the assertions put in place by 4d1bb7955a8b was too strict. 69084 Convert it to an if() to deal with situations like this one found by 69085 fuzzing: 69086 69087 x=s 69088 s=%eax+0 69089 y=s 69090 or $6,x 69091 69092 In non-debug builds this also avoids potentially silently generating bad 69093 code. 69094 690952023-02-16 GDB Administrator <gdbadmin@sourceware.org> 69096 69097 Automatic date update in version.in 69098 690992023-02-15 Tom Tromey <tom@tromey.com> 69100 69101 Return bool from more value methods 69102 There are several more value methods that currently return 'int' but 69103 that should return 'bool'. This patch updates these. 69104 69105 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69106 691072023-02-15 Tom Tromey <tom@tromey.com> 69108 69109 Have value::bits_synthetic_pointer return bool 69110 This changes value::bits_synthetic_pointer to return bool and fixes up 69111 some fallout from this. 69112 69113 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69114 691152023-02-15 Tom Tromey <tom@tromey.com> 69116 69117 Change value::m_stack to bool 69118 This changes value::m_stack to be a bool and updates the various uses. 69119 69120 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69121 691222023-02-15 Tom Tromey <tom@tromey.com> 69123 69124 Change value::m_initialized to bool 69125 This changes value::m_initialized to be a bool and updates the various 69126 uses. 69127 69128 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69129 691302023-02-15 Tom Tromey <tom@tromey.com> 69131 69132 Change value::m_lazy to bool 69133 This changes value::m_lazy to be a bool and updates the various uses. 69134 69135 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69136 691372023-02-15 Tom Tromey <tom@tromey.com> 69138 69139 Change value::m_modifiable to bool 69140 This changes value::m_modifiable to be a bool and updates the various 69141 uses. 69142 69143 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 69144 691452023-02-15 Pedro Alves <pedro@palves.net> 69146 69147 Don't throw quit while handling inferior events, part II 69148 I noticed that if Ctrl-C was typed just while GDB is evaluating a 69149 breakpoint condition in the background, and GDB ends up reaching out 69150 to the Python interpreter, then the breakpoint condition would still 69151 fail, like: 69152 69153 c& 69154 Continuing. 69155 (gdb) Error in testing breakpoint condition: 69156 Quit 69157 69158 That happens because while evaluating the breakpoint condition, we 69159 enter Python, and end up calling PyErr_SetInterrupt (it's called by 69160 gdbpy_set_quit_flag, in frame #0): 69161 69162 (top-gdb) bt 69163 #0 gdbpy_set_quit_flag (extlang=0x558c68f81900 <extension_language_python>) at ../../src/gdb/python/python.c:288 69164 #1 0x0000558c6845f049 in set_quit_flag () at ../../src/gdb/extension.c:785 69165 #2 0x0000558c6845ef98 in set_active_ext_lang (now_active=0x558c68f81900 <extension_language_python>) at ../../src/gdb/extension.c:743 69166 #3 0x0000558c686d3e56 in gdbpy_enter::gdbpy_enter (this=0x7fff2b70bb90, gdbarch=0x558c6ab9eac0, language=0x0) at ../../src/gdb/python/python.c:212 69167 #4 0x0000558c68695d49 in python_on_memory_change (inferior=0x558c6a830b00, addr=0x555555558014, len=4, data=0x558c6af8a610 "") at ../../src/gdb/python/py-inferior.c:146 69168 #5 0x0000558c6823a071 in std::__invoke_impl<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__f=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:61 69169 #6 0x0000558c68237591 in std::__invoke_r<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__fn=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:111 69170 #7 0x0000558c68233e64 in std::_Function_handler<void (inferior*, unsigned long, long, unsigned char const*), void (*)(inferior*, unsigned long, long, unsigned char const*)>::_M_invoke(std::_Any_data const&, inferior*&&, unsigned long&&, long&&, unsigned char const*&&) (__functor=..., __args#0=@0x7fff2b70bd40: 0x558c6a830b00, __args#1=@0x7fff2b70bd38: 93824992247828, __args#2=@0x7fff2b70bd30: 4, __args#3=@0x7fff2b70bd28: 0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:290 69171 #8 0x0000558c6830a96e in std::function<void (inferior*, unsigned long, long, unsigned char const*)>::operator()(inferior*, unsigned long, long, unsigned char const*) const (this=0x558c6a8ecd98, __args#0=0x558c6a830b00, __args#1=93824992247828, __args#2=4, __args#3=0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:590 69172 #9 0x0000558c6830a620 in gdb::observers::observable<inferior*, unsigned long, long, unsigned char const*>::notify (this=0x558c690828c0 <gdb::observers::memory_changed>, args#0=0x558c6a830b00, args#1=93824992247828, args#2=4, args#3=0x558c6af8a610 "") at ../../src/gdb/../gdbsupport/observable.h:166 69173 #10 0x0000558c68309d95 in write_memory_with_notification (memaddr=0x555555558014, myaddr=0x558c6af8a610 "", len=4) at ../../src/gdb/corefile.c:363 69174 #11 0x0000558c68904224 in value_assign (toval=0x558c6afce910, fromval=0x558c6afba6c0) at ../../src/gdb/valops.c:1190 69175 #12 0x0000558c681e3869 in expr::assign_operation::evaluate (this=0x558c6af8e150, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/expop.h:1902 69176 #13 0x0000558c68450c89 in expr::logical_or_operation::evaluate (this=0x558c6afab060, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:2330 69177 #14 0x0000558c6844a896 in expression::evaluate (this=0x558c6afcfe60, expect_type=0x0, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:110 69178 #15 0x0000558c6844a95e in evaluate_expression (exp=0x558c6afcfe60, expect_type=0x0) at ../../src/gdb/eval.c:124 69179 #16 0x0000558c682061ef in breakpoint_cond_eval (exp=0x558c6afcfe60) at ../../src/gdb/breakpoint.c:4971 69180 ... 69181 69182 69183 The fix is to disable cooperative SIGINT handling while handling 69184 inferior events, so that SIGINT is saved in the global quit flag, and 69185 not in the extension language, while handling an event. 69186 69187 This commit augments the testcase added by the previous commit to test 69188 this scenario as well. 69189 69190 Approved-By: Tom Tromey <tom@tromey.com> 69191 Change-Id: Idf8ab815774ee6f4b45ca2d0caaf30c9b9f127bb 69192 691932023-02-15 Pedro Alves <pedro@palves.net> 69194 69195 GC get_active_ext_lang 69196 get_active_ext_lang is not used anywhere. Delete it. 69197 69198 Approved-By: Tom Tromey <tom@tromey.com> 69199 Change-Id: I4c2b6d0d11291103c098e4db1d6ea449875c96b7 69200 692012023-02-15 Pedro Alves <pedro@palves.net> 69202 69203 Don't throw quit while handling inferior events 69204 This implements what I suggested here: 69205 69206 https://inbox.sourceware.org/gdb-patches/ab97c553-f406-b094-cdf3-ba031fdea925@palves.net/ 69207 69208 Here is the current default quit_handler, a function that ends up 69209 called by the QUIT macro: 69210 69211 void 69212 default_quit_handler (void) 69213 { 69214 if (check_quit_flag ()) 69215 { 69216 if (target_terminal::is_ours ()) 69217 quit (); 69218 else 69219 target_pass_ctrlc (); 69220 } 69221 } 69222 69223 As we can see above, when the inferior is running in the foreground, 69224 then a Ctrl-C is translated into a call to target_pass_ctrlc(). 69225 69226 The target_terminal::is_ours() case above is there to handle the 69227 scenario where GDB has the terminal, meaning it is handling some 69228 command the user typed, like "list", or "p a + b" or some such. 69229 69230 However, when the inferior is running on the background, say with 69231 "c&", GDB also has the terminal. Run control handling is now done in 69232 the "background". The CLI is responsive to user commands. If users 69233 type Ctrl-C, they're expecting it to interrupt whatever command they 69234 next type in the CLI, which again, could be "list", "p a + b", etc. 69235 It's as if background run control was handled by a separate thread, 69236 and the Ctrl-C is meant to go to the main thread, handling the CLI. 69237 69238 However, when handling an event, inside fetch_inferior_event & 69239 friends, a Ctrl-C _also_ results in a Quit exception, from the same 69240 default_quit_handler function shown above. This quit aborts run 69241 control handling, breakpoint condition evaluation, etc., and may even 69242 leave run control in an inconsistent state. 69243 69244 The testcase added by this patch illustrates this. The test program 69245 just loops a number of times calling the "foo" function. 69246 69247 The idea is to set a breakpoint in the "foo" function with a condition 69248 that sends SIGINT to GDB, and then evaluates to false, which results 69249 in the program being re-resumed in the background. The SIGINT-sending 69250 emulates pressing Ctrl-C just while GDB was evaluating the breakpoint 69251 condition, except, it's more deterministic. 69252 69253 It looks like this: 69254 69255 (gdb) p $counter = 0 69256 $1 = 0 69257 (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0 69258 Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21. 69259 (gdb) c& 69260 Continuing. 69261 (gdb) 69262 69263 After that background continue, the breakpoint should be hit 10 times, 69264 and we should see 10 "Quit" being printed on the screen. As if the 69265 user typed Ctrl-C on the prompt a number of times with no inferior 69266 running: 69267 69268 (gdb) <<< Ctrl-C 69269 (gdb) Quit <<< Ctrl-C 69270 (gdb) Quit <<< Ctrl-C 69271 (gdb) 69272 69273 However, here's what you see instead: 69274 69275 (gdb) c& 69276 Continuing. 69277 (gdb) Quit 69278 (gdb) 69279 69280 Just one Quit, and nothing else. If we look at the thread's state, we see: 69281 69282 (gdb) info threads 69283 Id Target Id Frame 69284 * 1 Thread 0x7ffff7d6f740 (LWP 112192) "bg-exec-sigint-" foo () at gdb.base/bg-exec-sigint-bp-cond.c:21 69285 69286 So the thread stopped, but we didn't report a stop... 69287 69288 Issuing another continue shows the same immediate-and-silent-stop: 69289 69290 (gdb) c& 69291 Continuing. 69292 (gdb) Quit 69293 (gdb) p $counter 69294 $2 = 2 69295 69296 As mentioned, since the run control handling, and breakpoint and 69297 watchpoint evaluation, etc. are running in the background from the 69298 perspective of the CLI, when users type Ctrl-C in this situation, 69299 they're thinking of aborting whatever other command they were typing 69300 or running at the prompt, not the run control side, not the previous 69301 "c&" command. 69302 69303 So I think that we should install a custom quit_handler while inside 69304 fetch_inferior_event, where we already disable pagination and other 69305 things for a similar reason. This custom quit handler does nothing if 69306 GDB has the terminal, and forwards Ctrl-C to the inferior otherwise. 69307 69308 With the patch implementing that, and the same testcase, here's what 69309 you see instead: 69310 69311 (gdb) p $counter = 0 69312 $1 = 0 69313 (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0 69314 Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21. 69315 (gdb) c& 69316 Continuing. 69317 (gdb) Quit 69318 (gdb) Quit 69319 (gdb) Quit 69320 (gdb) Quit 69321 (gdb) Quit 69322 (gdb) Quit 69323 (gdb) Quit 69324 (gdb) Quit 69325 (gdb) Quit 69326 (gdb) Quit 69327 (gdb) 69328 Breakpoint 2, foo () at gdb.base/bg-exec-sigint-bp-cond.c:21 69329 21 return 0; 69330 69331 Approved-By: Tom Tromey <tom@tromey.com> 69332 Change-Id: I1f10d99496a7d67c94b258e45963e83e439e1778 69333 693342023-02-15 Pedro Alves <pedro@palves.net> 69335 69336 Add new "$_shell(CMD)" internal function 69337 For testing a following patch, I wanted a way to send a SIGINT to GDB 69338 from a breakpoint condition. And I didn't want to do it from a Python 69339 breakpoint or Python function, as I wanted to exercise non-Python code 69340 paths. So I thought I'd add a new $_shell internal function, that 69341 runs a command under the shell, and returns the exit code. With this, 69342 I could write: 69343 69344 (gdb) b foo if $_shell("kill -SIGINT $gdb_pid") != 0 || <other condition> 69345 69346 I think this is generally useful, hence I'm proposing it here. 69347 69348 Here's the new function in action: 69349 69350 (gdb) p $_shell("true") 69351 $1 = 0 69352 (gdb) p $_shell("false") 69353 $2 = 1 69354 (gdb) p $_shell("echo hello") 69355 hello 69356 $3 = 0 69357 (gdb) p $_shell("foobar") 69358 bash: line 1: foobar: command not found 69359 $4 = 127 69360 (gdb) help function _shell 69361 $_shell - execute a shell command and returns the result. 69362 Usage: $_shell (command) 69363 Returns the command's exit code: zero on success, non-zero otherwise. 69364 (gdb) 69365 69366 NEWS and manual changes included. 69367 69368 Approved-By: Andrew Burgess <aburgess@redhat.com> 69369 Approved-By: Tom Tromey <tom@tromey.com> 69370 Approved-By: Eli Zaretskii <eliz@gnu.org> 69371 Change-Id: I7e36d451ee6b428cbf41fded415ae2d6b4efaa4e 69372 693732023-02-15 Pedro Alves <pedro@palves.net> 69374 69375 Make "ptype INTERNAL_FUNCTION" in Ada print like other languages 69376 Currently, printing the type of an internal function in Ada shows 69377 double <>s, like: 69378 69379 (gdb) with language ada -- ptype $_isvoid 69380 type = <<internal function>> 69381 69382 while all other languages print it with a single <>, like: 69383 69384 (gdb) with language c -- ptype $_isvoid 69385 type = <internal function> 69386 69387 I don't think there's a reason that Ada needs to be different. We 69388 currently print the double <>s because we take this path in 69389 ada_print_type: 69390 69391 switch (type->code ()) 69392 { 69393 default: 69394 gdb_printf (stream, "<"); 69395 c_print_type (type, "", stream, show, level, language_ada, flags); 69396 gdb_printf (stream, ">"); 69397 break; 69398 69399 ... and the type's name already has the <>s. 69400 69401 Fix this by simply adding an early check for 69402 TYPE_CODE_INTERNAL_FUNCTION. 69403 69404 Approved-By: Andrew Burgess <aburgess@redhat.com> 69405 Approved-By: Tom Tromey <tom@tromey.com> 69406 Change-Id: Ic2b6527b9240a367471431023f6e27e6daed5501 69407 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105 69408 694092023-02-15 Pedro Alves <pedro@palves.net> 69410 69411 Fix "ptype INTERNAL_FUNC" (PR gdb/30105) 69412 Currently, looking at the type of an internal function, like below, 69413 hits an odd error: 69414 69415 (gdb) ptype $_isvoid 69416 type = <internal function>type not handled in c_type_print_varspec_prefix() 69417 69418 That is an error thrown from 69419 c-typeprint.c:c_type_print_varspec_prefix, where it reads: 69420 69421 ... 69422 case TYPE_CODE_DECFLOAT: 69423 case TYPE_CODE_FIXED_POINT: 69424 /* These types need no prefix. They are listed here so that 69425 gcc -Wall will reveal any types that haven't been handled. */ 69426 break; 69427 default: 69428 error (_("type not handled in c_type_print_varspec_prefix()")); 69429 break; 69430 69431 Internal function types have type code TYPE_CODE_INTERNAL_FUNCTION, 69432 which is not explicitly handled by that switch. 69433 69434 That comment quoted above says that gcc -Wall will reveal any types 69435 that haven't been handled, but that's not actually true, at least with 69436 modern GCCs. You would need to enable -Wswitch-enum for that, which 69437 we don't. If I do enable that warning, then I see that we're missing 69438 handling for the following type codes: 69439 69440 TYPE_CODE_INTERNAL_FUNCTION, 69441 TYPE_CODE_MODULE, 69442 TYPE_CODE_NAMELIST, 69443 TYPE_CODE_XMETHOD 69444 69445 TYPE_CODE_MODULE and TYPE_CODE_NAMELIST and Fortran-specific, so it'd 69446 be a little weird to handle them here. 69447 69448 I tried to reach this code with TYPE_CODE_XMETHOD, but couldn't figure 69449 out how to. ptype on an xmethod isn't treated specially, it just 69450 complains that the method doesn't exist. I've extended the 69451 gdb.python/py-xmethods.exp testcase to make sure of that. 69452 69453 My thinking is that whatever type code we add next, the most likely 69454 scenario is that it won't need any special handling, so we'd just be 69455 adding another case to that "do nothing" list. If we do need special 69456 casing for whatever type code, I think that tests added at the same 69457 time as the feature would uncover it anyhow. If we do miss adding the 69458 special casing, then it still looks better to me to print the type 69459 somewhat incompletely than to error out and make it harder for users 69460 to debug whatever they need. So I think that the best thing to do 69461 here is to just remove all those explicit "do nothing" cases, along 69462 with the error default case. 69463 69464 After doing that, I decided to write a testcase that iterates over all 69465 supported languages doing "ptype INTERNAL_FUNC". That revealed that 69466 Pascal has a similar problem, except the default case hits a 69467 gdb_assert instead of an error: 69468 69469 (gdb) with language pascal -- ptype $_isvoid 69470 type = 69471 ../../src/gdb/p-typeprint.c:268: internal-error: type_print_varspec_prefix: unexpected type 69472 A problem internal to GDB has been detected, 69473 further debugging may prove unreliable. 69474 69475 That is fixed by this patch in the same way. 69476 69477 You'll notice that the new testcase special-cases the Ada expected 69478 output: 69479 69480 } elseif {$lang == "ada"} { 69481 gdb_test "ptype \$_isvoid" "<<internal function>>" 69482 } else { 69483 gdb_test "ptype \$_isvoid" "<internal function>" 69484 } 69485 69486 That will be subject of the following patch. 69487 69488 Approved-By: Andrew Burgess <aburgess@redhat.com> 69489 Change-Id: I81aec03523cceb338b5180a0b4c2e4ad26b4c4db 69490 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105 69491 694922023-02-15 Simon Marchi <simon.marchi@efficios.com> 69493 69494 gdb/dwarf2: split .debug_names reading code to own file 69495 Move everything related to reading .debug_names from read.c to 69496 read-debug-names.c. The only entry point exposed by 69497 read-debug-names.{c,h} is dwarf2_read_debug_names. 69498 69499 Change-Id: I18b23f3c7a61b14abc3a46e4bf559bc2d078e8bc 69500 Approved-By: Tom Tromey <tom@tromey.com> 69501 695022023-02-15 Simon Marchi <simon.marchi@efficios.com> 69503 69504 gdb/dwarf2: split .gdb_index reading code to own file 69505 Move everything related to reading .gdb_index from read.c to 69506 read-gdb-index.c. The only entry point exposed by read-gdb-index.{c,h} 69507 is dwarf2_read_gdb_index. 69508 69509 Change-Id: I1e32c8f0720086538de8d2f612f27545377099bc 69510 Approved-By: Tom Tromey <tom@tromey.com> 69511 695122023-02-15 Simon Marchi <simon.marchi@polymtl.ca> 69513 69514 gdb/dwarf2: move some things to read.h 69515 The following 2 patches move .gdb_index and .debug_names reading code to 69516 their own file. Prepare this by exposing some things used by that code 69517 to read.h. 69518 69519 Change-Id: If8ef135758a2ff0ab3b765cc92596da8189f3bbd 69520 Approved-By: Tom Tromey <tom@tromey.com> 69521 695222023-02-15 Simon Marchi <simon.marchi@efficios.com> 69523 69524 gdb: fix dealloc function not being called for frame 0 69525 Tom de Vries reported [1] a regression in gdb.btrace/record_goto.exp 69526 caused by 6d3717d4c4 ("gdb: call frame unwinders' dealloc_cache methods 69527 through destroying the frame cache"). This issue is caught by ASan. On 69528 a non-ASan build, it may or may not cause a crash or some other issue, I 69529 haven't tried. 69530 69531 I managed to narrow it down to: 69532 69533 $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.btrace/record_goto/record_goto -ex "start" -ex "record btrace" -ex "next" 69534 69535 ... and then doing repeatedly "record goto 19" and "record goto 27". 69536 Eventually, I get: 69537 69538 (gdb) record goto 27 69539 ================================================================= 69540 ==1527735==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003392a8 at pc 0x55e4c26eef86 bp 0x7ffd229f24e0 sp 0x7ffd229f24d8 69541 READ of size 8 at 0x6210003392a8 thread T0 69542 #0 0x55e4c26eef85 in bfcache_eq /home/simark/src/binutils-gdb/gdb/record-btrace.c:1639 69543 #1 0x55e4c37cdeff in htab_find_slot_with_hash /home/simark/src/binutils-gdb/libiberty/hashtab.c:659 69544 #2 0x55e4c37ce24a in htab_find_slot /home/simark/src/binutils-gdb/libiberty/hashtab.c:703 69545 #3 0x55e4c26ef0c6 in bfcache_new /home/simark/src/binutils-gdb/gdb/record-btrace.c:1653 69546 #4 0x55e4c26f1242 in record_btrace_frame_sniffer /home/simark/src/binutils-gdb/gdb/record-btrace.c:1820 69547 #5 0x55e4c1b926a1 in frame_unwind_try_unwinder /home/simark/src/binutils-gdb/gdb/frame-unwind.c:136 69548 #6 0x55e4c1b930d7 in frame_unwind_find_by_frame(frame_info_ptr, void**) /home/simark/src/binutils-gdb/gdb/frame-unwind.c:196 69549 #7 0x55e4c1bb867f in get_frame_type(frame_info_ptr) /home/simark/src/binutils-gdb/gdb/frame.c:2925 69550 #8 0x55e4c2ae6798 in print_frame_info(frame_print_options const&, frame_info_ptr, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:1049 69551 #9 0x55e4c2ade3e1 in print_stack_frame(frame_info_ptr, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:367 69552 #10 0x55e4c26fda03 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2779 69553 #11 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843 69554 #12 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169 69555 #13 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372 69556 #14 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383 69557 69558 0x6210003392a8 is located 424 bytes inside of 4064-byte region [0x621000339100,0x62100033a0e0) 69559 freed by thread T0 here: 69560 #0 0x7f6ca34a5b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 69561 #1 0x55e4c38a4c17 in rpl_free /home/simark/src/binutils-gdb/gnulib/import/free.c:44 69562 #2 0x55e4c1bbd378 in xfree<void> /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb-xfree.h:37 69563 #3 0x55e4c37d1b63 in call_freefun /home/simark/src/binutils-gdb/libiberty/obstack.c:103 69564 #4 0x55e4c37d25a2 in _obstack_free /home/simark/src/binutils-gdb/libiberty/obstack.c:280 69565 #5 0x55e4c1bad701 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2112 69566 #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564 69567 #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573 69568 #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772 69569 #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843 69570 #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169 69571 #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372 69572 #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383 69573 69574 previously allocated by thread T0 here: 69575 #0 0x7f6ca34a5e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 69576 #1 0x55e4c0b55c60 in xmalloc /home/simark/src/binutils-gdb/gdb/alloc.c:57 69577 #2 0x55e4c37d1a6d in call_chunkfun /home/simark/src/binutils-gdb/libiberty/obstack.c:94 69578 #3 0x55e4c37d1c20 in _obstack_begin_worker /home/simark/src/binutils-gdb/libiberty/obstack.c:141 69579 #4 0x55e4c37d1ed7 in _obstack_begin /home/simark/src/binutils-gdb/libiberty/obstack.c:164 69580 #5 0x55e4c1bad728 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2113 69581 #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564 69582 #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573 69583 #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772 69584 #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843 69585 #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169 69586 #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372 69587 #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383 69588 69589 The problem is a stale entry in the bfcache hash table (in 69590 record-btrace.c), left across a reinit_frame_cache. This entry points 69591 to something that used to be allocated on the frame obstack, that has 69592 since been wiped by reinit_frame_cache. 69593 69594 Before the aforementioned, unwinder deallocation functions were called 69595 by iterating on the frame chain, starting with the sentinel frame, like 69596 so: 69597 69598 /* Tear down all frame caches. */ 69599 for (frame_info *fi = sentinel_frame; fi != NULL; fi = fi->prev) 69600 { 69601 if (fi->prologue_cache && fi->unwind->dealloc_cache) 69602 fi->unwind->dealloc_cache (fi, fi->prologue_cache); 69603 if (fi->base_cache && fi->base->unwind->dealloc_cache) 69604 fi->base->unwind->dealloc_cache (fi, fi->base_cache); 69605 } 69606 69607 After that patch, we relied on the fact that all frames are (supposedly) 69608 in the frame_stash. A deletion function was added to the frame_stash 69609 hash table, so that dealloc functions would be called when emptying the 69610 frame stash. There is one case, however, where a frame_info is not in 69611 the frame stash. That is when we create the frame_info for the current 69612 frame (level 0, unwound from the sentinel frame), but don't compute its 69613 frame id. The computation of the frame id for that frame (and only that 69614 frame, AFAIK) is done lazily. And putting a frame_info in the frame stash 69615 requires knowing its id. So a frame 0 whose frame id is not computed 69616 yet is necessarily not in the frame stash. 69617 69618 When replaying with btrace, record_btrace_frame_sniffer insert entries 69619 corresponding to frames in the "bfcache" hash table. It then relies on 69620 record_btrace_frame_dealloc_cache being called for each frame to remove 69621 all those entries when the frames get invalidated. If a frame reinit 69622 happens while frame 0's id is not computed (and therefore that frame is 69623 not in frame_stash), record_btrace_frame_dealloc_cache does not get 69624 called for it, and it leaves a stale entry in bfcache. That then leads 69625 to a use-after-free when that entry is accessed later, which ASan 69626 catches. 69627 69628 The proposed solution is to explicitly call frame_info_del on frame 0, 69629 if it exists, and if its frame id is not computed. If its frame id is 69630 computed, it is expected that it will be in the frame stash, so it will 69631 be "deleted" through that. 69632 69633 [1] https://inbox.sourceware.org/gdb-patches/20230130200249.131155-1-simon.marchi@efficios.com/T/#mcf1340ce2906a72ec7ed535ec0c97dba11c3d977 69634 69635 Reported-By: Tom de Vries <tdevries@suse.de> 69636 Tested-By: Tom de Vries <tdevries@suse.de> 69637 Change-Id: I2351882dd511f3bbc01e4152e9db13b69b3ba384 69638 696392023-02-15 Tom Tromey <tom@tromey.com> 69640 69641 Remove RETURNS from BFD chew comments 69642 When reading the BFD manual, I noticed text like this: 69643 69644 -- Function: bool bfd_close (bfd *abfd); 69645 Close a BFD. If the BFD was open for writing, then pending 69646 operations are completed and the file written out and closed. If 69647 ... 69648 *Returns* 69649 'TRUE' is returned if all is ok, otherwise 'FALSE'. 69650 69651 The *Returns*, like the *Synopsis* in the earlier patch, is 69652 un-info-like. It's also used inconsistently. 69653 69654 This patch removes all the uses of the RETURNS word and removes it 69655 entirely from the chew scripts. Now this example reads: 69656 69657 -- Function: bool bfd_close (bfd *abfd); 69658 Close a BFD. If the BFD was open for writing, then pending 69659 operations are completed and the file written out and closed. If 69660 ... 69661 'TRUE' is returned if all is ok, otherwise 'FALSE'. 69662 69663 In a few cases I had to slightly reword the comment. There were also 69664 a couple of cases where there was redundant text. In these cases I 69665 just dropped the RETURNS copy. 69666 69667 2023-02-07 Tom Tromey <tom@tromey.com> 69668 69669 * bfd.c, cache.c, compress.c, opncls.c: Remove RETURNS from 69670 documentation comments. 69671 * doc/doc.str, doc/proto.str (RETURNS): Remove. 69672 696732023-02-15 Tom Tromey <tom@tromey.com> 69674 69675 Use @deftypefn in chew output 69676 When reading the BFD info manual, function definitions looked very 69677 strange to me: 69678 69679 *Synopsis* 69680 long bfd_get_mtime (bfd *abfd); 69681 *Description* 69682 Return the file modification time (as read from the file system, or from 69683 the archive header for archive members). 69684 69685 The *Synopsis* and *Description* text in particular is very un-info-like. 69686 69687 To fix this, I tried removing the *Synopsis* text and having FUNCTION 69688 use @deftypefn instead. However, this ended up requiring some new 69689 state, because SYNOPSIS can appear without FUNCTION. This in turn 69690 required "catstrif" (I considered adding FORTH-style if-else-then, but 69691 in the end decided on an ad hoc approach). 69692 69693 After this the result looks like: 69694 69695 -- Function: long bfd_get_mtime (bfd *abfd); 69696 Return the file modification time (as read from the file system, or 69697 from the archive header for archive members). 69698 69699 This patch also reorders a few documentation comments to ensure that 69700 SYNOPSIS comes before DESCRIPTION. This is the more common style and 69701 is also now required by doc.str. 69702 69703 2023-02-07 Tom Tromey <tom@tromey.com> 69704 69705 * syms.c (bfd_decode_symclass, bfd_is_undefined_symclass) 69706 (bfd_symbol_info): Reorder documentation comment. 69707 * doc/doc.str (synopsis_seen): New variable. 69708 (SYNOPSIS): Set synopsis_seen. Emit @deftypefn. 69709 (DESCRIPTION): Use synopsis_seen. 69710 * doc/chew.c (catstrif): New function. 69711 (main): Add catstrif intrinsic. 69712 (compile): Recognize "variable" command. 69713 697142023-02-15 Tom Tromey <tom@tromey.com> 69715 69716 Change internalmode to be an intrinsic variable 69717 Currently, internalmode is a special word to set an internal state 69718 variable. Because this series adds variables anyway, change this to 69719 be a variable instead. 69720 69721 I saw some commits in the history that made sure that chew did not 69722 leak memory, so I put some extra effort into trying to handle this for 69723 variables as well. 69724 69725 2023-02-07 Tom Tromey <tom@tromey.com> 69726 69727 * doc/proto.str (external, internal, ifinternal, ENUMEQ, ENUMDOC): 69728 Update. 69729 * doc/chew.c (internalmode): Remove. 69730 (add_intrinsic_variable): New function. 69731 (main): Add internalmode as intrinsic. 69732 (internal_mode): Remove global. 69733 (maybecatstr): Update. 69734 (free_words): Free variables. 69735 697362023-02-15 Tom Tromey <tom@tromey.com> 69737 69738 Use intptr_t rather than long in chew 69739 To implement variables in chew, it's convenient to have a 69740 pointer-sized integer on the stack. To this end, use intptr_t rather 69741 than long. 69742 69743 2023-02-07 Tom Tromey <tom@tromey.com> 69744 69745 * doc/chew.c (pcu) <l>: Now intptr_t. 69746 (internal_mode, istack, isp): Likewise. 69747 (bang, atsign): Use intptr_t. 69748 697492023-02-15 Tom Tromey <tom@tromey.com> 69750 69751 Remove the paramstuff word 69752 The chew "paramstuff" word has been a no-op since: 69753 69754 commit c58b95236ce4c9345c4fa76e7ef16762e5229380 69755 Author: Alan Modra <amodra@gmail.com> 69756 Date: Sun Jun 29 10:06:40 2003 +0000 69757 69758 Convert to C90 and a few tweaks. 69759 69760 Remove it and its one use. 69761 69762 2023-02-07 Tom Tromey <tom@tromey.com> 69763 69764 * doc/proto.str (SYNOPSIS): Don't use paramstuff. 69765 * doc/chew.c (paramstuff): Remove. 69766 (main): Don't add paramstuff intrinsic. 69767 697682023-02-15 Tom Tromey <tom@tromey.com> 69769 69770 Add copyright headers to the .str files 69771 The .str script files don't have copyright headers, but I think they 69772 should. I used the same dates that chew.c uses, which I think makes 69773 sense because these are inputs to chew. 69774 69775 2023-02-07 Tom Tromey <tom@tromey.com> 69776 69777 * doc/doc.str, doc/proto.str: Add copyright header. 69778 697792023-02-15 Tom Tromey <tom@tromey.com> 69780 69781 Simplify @node use in BFD documentation 69782 The BFD docs currently specify all the parameters to @node. However, 69783 this results in bad navigation in certain nodes -- the "space" command 69784 in info doesn't know how to find the next node. 69785 69786 I think this style of @node is a leftover from ancient times. 69787 Makeinfo can figure out the node structure on its own now, so simplify 69788 everything to a single-argument @node. 69789 69790 2023-02-07 Tom Tromey <tom@tromey.com> 69791 69792 * doc/webassembly.texi (File layout): Remove second argument from 69793 @node. 69794 * doc/bfd.texi: Use single-argument @node everywhere. 69795 697962023-02-15 Tom Tromey <tom@tromey.com> 69797 69798 Remove H_CFLAGS from doc/local.mk 69799 I couldn't see that H_CFLAGS is defined anywhere, so remove it. 69800 69801 2023-02-07 Tom Tromey <tom@tromey.com> 69802 69803 * Makefile.in: Rebuild. 69804 * doc/local.mk (%D%/chew.stamp): Don't use H_CFLAGS. 69805 698062023-02-15 Simon Marchi <simon.marchi@efficios.com> 69807 69808 gdb: store internalvars in an std::map 69809 In a test downstream in ROCgdb, we had a test case failing when 69810 GDB_REVERSE_INIT_FUNCTIONS was set. The test was assuming a particular 69811 order in the output of "show convenience". And the order changes when 69812 running with GDB_REVERSE_INIT_FUNCTIONS. 69813 69814 I think that a nice way to fix it is to make the output of "show 69815 convenience" sorted, and therefore stable. Ideally, I think that the 69816 the user-visible behavior of GDB should not change when using 69817 GDB_REVERSE_INIT_FUNCTIONS. Plus, it makes the output of "show 69818 convenience" look nice, not that it's really important. 69819 69820 Implement this by storing the internal vars in an std::map, which is a 69821 sorted container. 69822 69823 Change-Id: I1fca7e7877cc984a3a3432c7639d45e68d437241 69824 Approved-By: Tom Tromey <tom@tromey.com> 69825 698262023-02-15 Simon Marchi <simon.marchi@efficios.com> 69827 69828 gdb: add constructor to internalvar 69829 Add a constructor that takes the name as a parameter. Initialize the 69830 next and kind fields inline. 69831 69832 Change-Id: Ic4db0aba85f1da9f12f3eee0ac62c0e5ef0cfe88 69833 Approved-By: Tom Tromey <tom@tromey.com> 69834 698352023-02-15 Simon Marchi <simon.marchi@efficios.com> 69836 69837 gdb: use std::string for internalvar::name 69838 Change internalvar::name to std::string, automating memory management. 69839 It becomes necessary to allocate internalvar with new instead of XNEW. 69840 69841 I didn't find how to trigger the code in complete_internalvar. It is 69842 called from condition_completer, so it should be by using the 69843 "condition" command, but I never managed to get in the right code path. 69844 69845 Change-Id: I814d61361663e7becb8f3fb5f58c0180cdc414bc 69846 Approved-By: Tom Tromey <tom@tromey.com> 69847 698482023-02-15 Tom Tromey <tromey@adacore.com> 69849 69850 Do not record a rejected target description 69851 When connecting to a certain target, gdb issues a warning about the 69852 target description: 69853 69854 (gdb) target remote localhost:7947 69855 Remote debugging using localhost:7947 69856 warning: Architecture rejected target-supplied description 69857 69858 If you then kill the inferior and change the exec-file, this will 69859 happen: 69860 69861 (gdb) file bar 69862 Architecture of file not recognized. 69863 69864 After this, debugging doesn't work very well. 69865 69866 What happens here is that, despite the warning, 69867 target_find_description records the downloaded description in the 69868 target_desc_info. Then the "file" command ends up calling 69869 set_gdbarch_from_file, which uses that description. 69870 69871 It seems to me that, because the architecture rejected the 69872 description, it should not be used. That is what this patch 69873 implements. 69874 698752023-02-15 Pedro Alves <pedro@palves.net> 69876 69877 gdb/manual: Move @findex entries 69878 The manual currently has many cases like these: 69879 69880 @item $_gdb_setting_str (@var{setting}) 69881 @findex $_gdb_setting_str@r{, convenience function} 69882 69883 As suggested by Eli, move the @findex entries before @item so that the 69884 index records the position of @item, and the Info reader places you 69885 there when you use index-search. 69886 69887 I went over all @findex calls in the manual, and most are like the 69888 above. Most either appear before @item, or before @subheading, like: 69889 69890 @subheading The @code{-break-after} Command 69891 @findex -break-after 69892 69893 I fixed all of them. 69894 69895 There are findex entries in annotate.texinfo,python.texi, and 69896 stabs.texinfo as well, though those all look right to me already. 69897 69898 Tested by typing "i _isvoid" (@item case) and "i -complete" 69899 (@subheading case) in an Info reader, and checking where those took 69900 me. 69901 69902 Change-Id: Idb6903b0bb39ff03f93524628dcef86b5585c97e 69903 Suggested-By: Eli Zaretskii <eliz@gnu.org> 69904 699052023-02-15 Alan Modra <amodra@gmail.com> 69906 69907 objdump read_section_stabs 69908 This function is used to read sections other than stabs, and there is 69909 now another version of it that extracts different info from the bfd 69910 section. Rename it and return the bfd section instead of assorted 69911 fields of the bfd section. 69912 69913 * objcopy.c (read_section): Renamed from read_section_stabs. 69914 Delete size_ptr and entsize_ptr params, add contents param. 69915 Return asection pointer. Don't unnecessarily free contents on 69916 failure from bfd_malloc_and_get_section. 69917 (find_stabs_section): Use read_section. 69918 (dump_ctf, dump_section_sframe): Likewise. 69919 (read_section_sframe): Delete. 69920 699212023-02-15 Alan Modra <amodra@gmail.com> 69922 69923 objdump -G memory leak 69924 * objdump.c (find_stabs_section): Free stabs. 69925 699262023-02-15 Nick Clifton <nickc@redhat.com> 69927 69928 Fix the linker's merge4 test for the HPPA architecture. 69929 PR 30078 * testsuite/ld-elf/merge4b.s: Use .asciz instead of .string in order to avoid the special behaviour of the .string directive on HPPA architectures. 69930 699312023-02-15 Felix Willgerodt <felix.willgerodt@intel.com> 69932 69933 gdb, fortran: Fix quad floating-point type for ifort compiler. 69934 I fixed this a while ago for ifx, one of the two Intel compilers, in 69935 8d624a9d8050ca96e154215c7858ac5c2d8b0b19. 69936 69937 Apparently I missed that the older ifort Intel compiler actually emits 69938 slightly different debug info again: 69939 69940 0x0000007a: DW_TAG_base_type 69941 DW_AT_byte_size (0x20) 69942 DW_AT_encoding (DW_ATE_complex_float) 69943 DW_AT_name ("COMPLEX(16)") 69944 69945 0x00000081: DW_TAG_base_type 69946 DW_AT_byte_size (0x10) 69947 DW_AT_encoding (DW_ATE_float) 69948 DW_AT_name ("REAL(16)") 69949 69950 This fixes two failures in gdb.fortran/complex.exp with ifort. 69951 69952 Approved-By: Tom Tromey <tom@tromey.com> 69953 699542023-02-15 Jan Beulich <jbeulich@suse.com> 69955 69956 gas: buffer_and_nest() needs to pass nul-terminated string to temp_ilp() 69957 In 7545aa2dd2eb ("gas: improve interaction between read_a_source_file() 69958 and s_linefile()") I didn't pay attention to the dual purpose of the 69959 nul character previously used. This was to a fair degree because of the 69960 open-coding of certain operations. Insert the earlier found line 69961 terminator instead of a hard-coded newline, and do so early in this 69962 special case (bypassing the later general insertion point). Plus 69963 properly use sb_terminate() to mark the end of the string. (Note that 69964 saved_eol_char was misnamed: Without calling sb_terminate() there's 69965 simply random data at that position in the buffer.) 69966 699672023-02-15 Alan Modra <amodra@gmail.com> 69968 69969 More ecoff sanity checks 69970 Change FIX so that unused pointers that escape the UPDATE_RAW_END 69971 sanity checks won't result in overflows. Also sanity check the local 69972 sym fdr isymBase and csym values. 69973 69974 * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Define FIX to set 69975 pointers into swapped internal data to NULL if count is zero. 69976 Sanity check local sym fdr_ptr->isymBase and fdr_ptr->csym. 69977 699782023-02-15 Alan Modra <amodra@gmail.com> 69979 69980 binutils stabs type list 69981 Fuzzers have found that specifying a large stab type number results in 69982 lots of memory being requested, as the list is extended with a 16 69983 element array at a time until we reach the given stab type. It also 69984 takes a long time. Of course normal sane stab types use small 69985 positive integers, but it's not hard to modify the code to handle type 69986 numbers starting anyhere. 69987 69988 * stabs.c (struct stab_types): Add base_index. 69989 (stab_find_slot): Simplify filenum check. Delete type number 69990 check. Don't allocate entire array from 0 to type number, 69991 allocate a sparse array. 69992 699932023-02-15 GDB Administrator <gdbadmin@sourceware.org> 69994 69995 Automatic date update in version.in 69996 699972023-02-14 Tom Tromey <tom@tromey.com> 69998 69999 Remove a use of pagination_enabled 70000 I noticed that the TUI temporarily sets pagination_enabled and 70001 gdb_stdout in one spot. However, I don't believe these settings are 70002 necessary here, as a ui_file is passed to 70003 gdbarch_print_registers_info. This patch removes these settings. 70004 700052023-02-14 Simon Marchi <simon.marchi@polymtl.ca> 70006 70007 gdb/dwarf2: rename some things, index -> gdb_index 70008 This renaming helps make it clearer that these entites (classes, 70009 functions) are specific to .gdb_index only, they are not shared with the 70010 .debug_names handling. 70011 70012 Change-Id: I1a3cf3dbf450b62d1a0879d9aedd26397abdfd13 70013 Approved-By: Tom Tromey <tom@tromey.com> 70014 700152023-02-14 Simon Marchi <simon.marchi@efficios.com> 70016 70017 gdb: cast return value of std::unique_ptr::release to void 70018 My editor shows warnings like: 70019 70020 value.c:2784: warning: The value returned by this function should be used 70021 value.c:2784: note: cast the expression to void to silence this warning [bugprone-unused-return-value] 70022 70023 These warnings come from clangd, so ultimately from one of the clang 70024 static analyzers (probably clang-tidy). 70025 70026 Silence these warnings by casting to void. Add a comment to explain 70027 why this unusual thing is done. 70028 70029 Change-Id: I58323959c0baf9f1b20a8d596e4c58dc77c6809a 70030 Approved-By: Tom Tromey <tom@tromey.com> 70031 700322023-02-14 Simon Marchi <simon.marchi@efficios.com> 70033 70034 gdb: remove unnecessary tui directory check in configure 70035 I suppose this was possible in the CVS days for the tui directory to be 70036 missing, but it's not really possible nowaday. Well, a user could 70037 delete the directory from their source tree but... it doesn't make 70038 sense. Remove the check for that directory in configure. 70039 70040 Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3 70041 Approved-By: Tom Tromey <tom@tromey.com> 70042 700432023-02-14 Tom Tromey <tromey@adacore.com> 70044 70045 Do not cast away const in agent_run_command 70046 While investigating something else, I noticed some weird code in 70047 agent_run_command (use of memcpy rather than strcpy). Then I noticed 70048 that 'cmd' is used as both an in and out parameter, despite being 70049 const. 70050 70051 Casting away const like this is bad. This patch removes the const and 70052 fixes the memcpy. I also added a static assert to assure myself that 70053 the code in gdbserver is correct -- gdbserver is passing its own 70054 buffer directly to agent_run_command. 70055 70056 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 70057 700582023-02-14 Tom de Vries <tdevries@suse.de> 70059 70060 [gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp 70061 There's a HW bug affecting Processor Trace on some Intel processors 70062 (Ice Lake to Raptor Lake microarchitectures). 70063 70064 The bug was exposed by linux kernel commit 670638477aed 70065 ("perf/x86/intel/pt: Opportunistically use single range output mode"), 70066 added in version v5.5.0, and was worked around by commit ce0d998be927 70067 ("perf/x86/intel/pt: Fix sampling using single range output") in version 70068 6.1.0. 70069 70070 The bug manifests (on a Performance-core of an i7-1250U, an Alder Lake cpu) in 70071 a single test-case: 70072 ... 70073 (gdb) python insn = r.instruction_history^M 70074 warning: Decode error (-20) at instruction 33 (offset = 0x3d6a, \ 70075 pc = 0x400501): compressed return without call.^M 70076 (gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: \ 70077 python insn = r.instruction_history 70078 ... 70079 70080 Add a corresponding XFAIL. 70081 70082 Note that the i7-1250U has both Performance-cores and Efficient-cores, and on 70083 an Efficient-Core the test-case runs without any problems, so if the testsuite 70084 run is not pinned to a specific cpu, the test may either PASS or XFAIL. 70085 70086 Tested on x86_64-linux: 70087 - openSUSE Leap 15.4 with linux kernel version 5.14.21 70088 - openSUSE Tumbleweed with linux kernel version 6.1.8 70089 70090 PR testsuite/30075 70091 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30075 70092 700932023-02-14 Nick Clifton <nickc@redhat.com> 70094 70095 Mention that the -plugin command line option is used to load plugins. 70096 700972023-02-14 Tom de Vries <tdevries@suse.de> 70098 70099 [gdb/testsuite] Factor out proc linux_kernel_version 70100 Factor out new proc linux_kernel_version from test-case 70101 gdb.arch/i386-pkru.exp. 70102 70103 Tested on x86_64-linux. 70104 701052023-02-14 Ulf Samuelsson <ulf@emagii.com> 70106 70107 ASCIZ Command for output section 70108 Adds a new directive to the linker script syntax: ASCIZ. 70109 This inserts a zero-terminated string into the output at the place where it is used. 70110 701112023-02-14 Jan Beulich <jbeulich@suse.com> 70112 70113 gas: correct symbol name comparison in .startof./.sizeof. handling 70114 In 162c6aef1f3a ("gas: fold symbol table entries generated for 70115 .startof.() / .sizeof.()") I screwed up quite badly, inverting the case 70116 sensitive and case insensitive comparison functions. 70117 70118 x86: {LD,ST}TILECFG use an extension opcode 70119 It being zero and happening to work right now doesn't mean the insns 70120 shouldn't be spelled out properly. 70121 701222023-02-14 Jan Beulich <jbeulich@suse.com> 70123 70124 gas: improve interaction between read_a_source_file() and s_linefile() 70125 read_a_source_file() would bump line numbers only when seeing a newline, 70126 whereas is_end_of_line[] indicates further end-of-line characters, in 70127 particular the nul character. s_linefile() attempts to compensate for 70128 the bump, but was too aggressive with this so far: It should only adjust 70129 when a newline ends the line. To facilitate such a check, the check for 70130 nothing else on the line needs to move ahead, which luckily is easily 70131 possible: The relevant two conditions match, and the function can 70132 simply return from the body of that earlier instance of the conditional. 70133 70134 The more strict treatment in s_linefile() then requires an adjustment 70135 to buffer_and_nest()'s invocation of the function: The line terminator 70136 now needs to be a newline, not nul. 70137 701382023-02-14 Tom Tromey <tom@tromey.com> 70139 70140 Fix build bug in ppc-linux-nat.c 70141 The buildbot pointed out that my value refactoring series introduced a 70142 bug in ppc-linux-nat.c: 70143 70144 ../../binutils-gdb/gdb/ppc-linux-nat.c: In member function ‘int ppc_linux_nat_target::num_memory_accesses(const std::vector<gdb::ref_ptr<value, value_ref_policy> >&)’: 70145 ../../binutils-gdb/gdb/ppc-linux-nat.c:2458:44: error: expected unqualified-id before ‘->’ token 70146 2458 | if (VALUE_LVAL (v) == not_lval || v->->deprecated_modifiable () == 0) 70147 70148 I don't know how that happened, but I am checking in this patch which 70149 I think should fix it. It just removes the second "->". 70150 70151 I can't readily test this, so perhaps there's another bug lurking 70152 after this one. 70153 701542023-02-14 GDB Administrator <gdbadmin@sourceware.org> 70155 70156 Automatic date update in version.in 70157 701582023-02-13 Tom Tromey <tom@tromey.com> 70159 70160 Rely on value_ref_ptr::operator-> 70161 Simon pointed out some spots were doing val.get()->mumble, where val 70162 is a value_ref_ptr. These were introduced by the function-to-method 70163 script, replacing older code that passed the result of .get() to a 70164 function. 70165 70166 Now that value.h is using methods, we can instead rely on operator->. 70167 This patch replaces all the newly-introduced instances of this. 70168 70169 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70170 701712023-02-13 Tom Tromey <tom@tromey.com> 70172 70173 Remove deprecated_lval_hack 70174 This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing 70175 all uses with a call to value::lval. 70176 70177 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70178 701792023-02-13 Tom Tromey <tom@tromey.com> 70180 70181 Introduce set_lval method on value 70182 This introduces the set_lval method on value, one step toward removing 70183 deprecated_lval_hack. Ultimately I think the goal should be for some 70184 of these set_* methods to be replaced with constructors; but I haven't 70185 done this, as the series is already too long. Other 'deprecated' 70186 methods can probably be handled the same way. 70187 70188 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70189 701902023-02-13 Tom Tromey <tom@tromey.com> 70191 70192 Make ~value private 70193 At the end of this series, I belatedly realized that values should 70194 only be destroyed by value_decref. This patch marks the the 70195 destructor private to enforce this. 70196 70197 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70198 701992023-02-13 Tom Tromey <tom@tromey.com> 70200 70201 Make struct value data members private 70202 This hoists the 'private' in struct value to also encompass the data 70203 members. 70204 70205 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70206 702072023-02-13 Tom Tromey <tom@tromey.com> 70208 70209 Turn record_latest_value into a method 70210 record_latest_value now access some internals of struct value, so turn 70211 it into a method. 70212 70213 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70214 702152023-02-13 Tom Tromey <tom@tromey.com> 70216 70217 Add value::set_modifiable 70218 This introduces a value::set_modifiable and changes a couple of spots 70219 to use it. 70220 70221 I'm not completely sure the comments by deprecated_modifiable are 70222 correct any more. Perhaps they should be removed and the method 70223 renamed. Like so many before me, though, I've deferred investigation 70224 of the issue. 70225 70226 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70227 702282023-02-13 Tom Tromey <tom@tromey.com> 70229 70230 Turn various value copying-related functions into methods 70231 This patch turns a grab bag of value functions to methods of value. 70232 These are done together because their implementations are 70233 interrelated. 70234 70235 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70236 702372023-02-13 Tom Tromey <tom@tromey.com> 70238 70239 Turn preserve_one_value into method 70240 This changes preserve_one_value to be a method of value. Much of this 70241 patch was written by script. 70242 70243 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70244 702452023-02-13 Tom Tromey <tom@tromey.com> 70246 70247 Turn some xmethod functions into methods 70248 This turns value_from_xmethod, result_type_of_xmethod, and 70249 call_xmethod to be methods of value. value_from_xmethod is a static 70250 "constructor" now. 70251 70252 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70253 702542023-02-13 Tom Tromey <tom@tromey.com> 70255 70256 Change some code to use value methods 70257 A few functions in value.c were accessing the internal fields of 70258 struct value. However, in these cases it seemed simpler to change 70259 them to use the public API rather than convert them to be methods. 70260 70261 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70262 702632023-02-13 Tom Tromey <tom@tromey.com> 70264 70265 Turn set_value_component_location into method 70266 This turns set_value_component_location into a method of value. 70267 70268 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70269 702702023-02-13 Tom Tromey <tom@tromey.com> 70271 70272 Turn value_non_lval and value_force_lval into methods 70273 This changes value_non_lval and value_force_lval to be methods of 70274 value. 70275 70276 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70277 702782023-02-13 Tom Tromey <tom@tromey.com> 70279 70280 Turn many optimized-out value functions into methods 70281 This turns many functions that are related to optimized-out or 70282 availability-checking to be methods of value. The static function 70283 value_entirely_covered_by_range_vector is also converted to be a 70284 private method. 70285 70286 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70287 702882023-02-13 Tom Tromey <tom@tromey.com> 70289 70290 Turn value_copy into a method 70291 This turns value_copy into a method of value. Much of this was 70292 written by script. 70293 70294 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70295 702962023-02-13 Tom Tromey <tom@tromey.com> 70297 70298 Fully qualify calls to copy in value.c 70299 A coming patch will add value::copy, so this namespace-qualifies 70300 existing calls to 'copy' in value.c, to ensure it will still compile 70301 after that change is done. 70302 70303 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70304 703052023-02-13 Tom Tromey <tom@tromey.com> 70306 70307 Turn remaining value_contents functions into methods 70308 This turns the remaining value_contents functions -- value_contents, 70309 value_contents_all, value_contents_for_printing, and 70310 value_contents_for_printing_const -- into methods of value. It also 70311 converts the static functions require_not_optimized_out and 70312 require_available to be private methods. 70313 70314 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70315 703162023-02-13 Tom Tromey <tom@tromey.com> 70317 70318 Turn value_incref and value_decref into methods 70319 This changes value_incref and value_decref to be methods of value. 70320 Much of this patch was written by script. 70321 70322 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70323 703242023-02-13 Tom Tromey <tom@tromey.com> 70325 70326 Move value_ref_policy methods out-of-line 70327 This moves the value_ref_policy methods to be defined out-of-line. 70328 This is a necessary step to change value_incref and value_decref to be 70329 methods of value. 70330 70331 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70332 703332023-02-13 Tom Tromey <tom@tromey.com> 70334 70335 Turn value_bits_synthetic_pointer into a method 70336 This changes value_bits_synthetic_pointer to be a method of value. 70337 70338 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70339 703402023-02-13 Tom Tromey <tom@tromey.com> 70341 70342 Turn value_contents_eq into a method 70343 This changes value_contents_eq to be a method of value. It also 70344 converts the static function value_contents_bits_eq into a private 70345 method. 70346 70347 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70348 703492023-02-13 Tom Tromey <tom@tromey.com> 70350 70351 Turn allocate_value_contents into a method 70352 This turns the static function allocate_value_contents into a method 70353 on value. It is temporarily public, until some users are converted. 70354 set_limited_array_length is converted as well. 70355 70356 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70357 703582023-02-13 Tom Tromey <tom@tromey.com> 70359 70360 Turn value_fetch_lazy into a method 70361 This changes value_fetch_lazy to be a method of value. A few helper 70362 functions are converted as well, to avoid problems in later patches 70363 when the data members are all made private. 70364 70365 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70366 703672023-02-13 Tom Tromey <tom@tromey.com> 70368 70369 Turn some value_contents functions into methods 70370 This turns value_contents_raw, value_contents_writeable, and 70371 value_contents_all_raw into methods on value. The remaining functions 70372 will be changed later in the series; they were a bit trickier and so I 70373 didn't include them in this patch. 70374 70375 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70376 703772023-02-13 Tom Tromey <tom@tromey.com> 70378 70379 Turn value_zero into static "constructor" 70380 This turns value_zero into a static "constructor" of value. 70381 70382 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70383 703842023-02-13 Tom Tromey <tom@tromey.com> 70385 70386 Turn allocate_optimized_out_value into static "constructor" 70387 This turns allocate_optimized_out_value into a static "constructor" of 70388 value. 70389 70390 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70391 703922023-02-13 Tom Tromey <tom@tromey.com> 70393 70394 Turn allocate_computed_value into static "constructor" 70395 This turns allocate_computed_value into a static "constructor" of 70396 value. 70397 70398 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70399 704002023-02-13 Tom Tromey <tom@tromey.com> 70401 70402 Turn allocate_value into a static "constructor" 70403 This changes allocate_value to be a static "constructor" of value. 70404 70405 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70406 704072023-02-13 Tom Tromey <tom@tromey.com> 70408 70409 Turn allocate_value_lazy into a static "constructor" 70410 This changes allocate_value_lazy to be a static "constructor" of 70411 struct value. 70412 70413 I considered trying to change value to use ordinary new/delete, but it 70414 seems to me that due to reference counting, we may someday want to 70415 change these static constructors to return value_ref_ptr instead. 70416 70417 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70418 704192023-02-13 Tom Tromey <tom@tromey.com> 70420 70421 Turn more deprecated_* functions into methods 70422 This changes deprecated_value_internalvar_hack, 70423 deprecated_value_internalvar_hack, and deprecated_value_regnum_hack 70424 into methods on value. 70425 70426 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70427 704282023-02-13 Tom Tromey <tom@tromey.com> 70429 70430 Turn value_address and set_value_address functions into methods 70431 This changes the value_address and set_value_address functions to be 70432 methods of value. 70433 70434 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70435 704362023-02-13 Tom Tromey <tom@tromey.com> 70437 70438 Turn value_initialized and set_value_initialized functions into methods 70439 This changes the value_initialized and set_value_initialized functions 70440 to be methods of value. 70441 70442 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70443 704442023-02-13 Tom Tromey <tom@tromey.com> 70445 70446 Convert value_lval_const and deprecated_lval_hack to methods 70447 This converts the value_lval_const and deprecated_lval_hack functions 70448 to be methods on value. 70449 70450 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70451 704522023-02-13 Tom Tromey <tom@tromey.com> 70453 70454 Turn value_computed_closure and value_computed_funcs functions into methods 70455 This changes the value_computed_funcs and value_computed_closure 70456 functions to be methods of value. 70457 70458 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70459 704602023-02-13 Tom Tromey <tom@tromey.com> 70461 70462 Turn value_stack and set_value_stack functions into methods 70463 This changes the value_stack and set_value_stack functions to be 70464 methods of value. 70465 70466 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70467 704682023-02-13 Tom Tromey <tom@tromey.com> 70469 70470 Turn value_lazy and set_value_lazy functions into methods 70471 This changes the value_lazy and set_value_lazy functions to be methods 70472 of value. Much of this patch was written by script. 70473 70474 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70475 704762023-02-13 Tom Tromey <tom@tromey.com> 70477 70478 Turn some value offset functions into method 70479 This changes various offset-related functions to be methods of value. 70480 Much of this patch was written by script. 70481 70482 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70483 704842023-02-13 Tom Tromey <tom@tromey.com> 70485 70486 Turn value_enclosing_type into method 70487 This changes value_enclosing_type to be a method of value. Much of 70488 this patch was written by script. 70489 70490 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70491 704922023-02-13 Tom Tromey <tom@tromey.com> 70493 70494 Turn deprecated_value_modifiable into method 70495 This changes deprecated_value_modifiable to be a method of value. 70496 70497 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70498 704992023-02-13 Tom Tromey <tom@tromey.com> 70500 70501 Turn value_offset into method 70502 This changes value_offset to be a method of value. Much of this patch 70503 was written by script. 70504 70505 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70506 705072023-02-13 Tom Tromey <tom@tromey.com> 70508 70509 Turn value_parent into method 70510 This changes value_parent to be a method of value. Much of this patch 70511 was written by script. 70512 70513 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70514 705152023-02-13 Tom Tromey <tom@tromey.com> 70516 70517 Turn value_bitpos into method 70518 This changes value_bitpos to be a method of value. Much of this patch 70519 was written by script. 70520 70521 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70522 705232023-02-13 Tom Tromey <tom@tromey.com> 70524 70525 Turn value_bitsize into method 70526 This changes value_bitsize to be a method of value. Much of this patch 70527 was written by script. 70528 70529 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70530 705312023-02-13 Tom Tromey <tom@tromey.com> 70532 70533 Turn value_arch into method 70534 This changes value_arch to be a method of value. Much of this patch 70535 was written by script. 70536 70537 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70538 705392023-02-13 Tom Tromey <tom@tromey.com> 70540 70541 Turn deprecated_set_value_type into a method 70542 This changes deprecated_set_value_type to be a method of value. Much 70543 of this patch was written by script. 70544 70545 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70546 705472023-02-13 Tom Tromey <tom@tromey.com> 70548 70549 Turn value_type into method 70550 This changes value_type to be a method of value. Much of this patch 70551 was written by script. 70552 70553 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70554 705552023-02-13 Tom Tromey <tom@tromey.com> 70556 70557 Move struct value to value.h 70558 This moves struct value to value.h. For now, all members remain 70559 public, but this is a temporary state -- by the end of the series 70560 we'll add 'private'. 70561 70562 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70563 705642023-02-13 Tom Tromey <tom@tromey.com> 70565 70566 Move ~value body out-of-line 70567 struct value is going to move to value.h, but to avoid having 70568 excessive code there, first move the destructor body out-of-line. 70569 70570 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70571 705722023-02-13 Tom Tromey <tom@tromey.com> 70573 70574 Rename all fields of struct value 70575 This renames all the fields of struct value, in preparation for the 70576 coming changes. 70577 70578 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70579 705802023-02-13 Michael Matz <matz@suse.de> 70581 70582 PR30120: fix x87 fucomp misassembled 70583 this fixes the entry for 'fucomp' to use the correct Reg value 70584 (otherwise it's assembled as 'fucom'). 70585 705862023-02-13 Tom Tromey <tromey@adacore.com> 70587 70588 Remove unused imports from gdb's Python code 70589 The "sys" import is unused in several Python files. This removes this 70590 line from all the places where it is unnecessary. 70591 705922023-02-13 Andrew Burgess <aburgess@redhat.com> 70593 70594 gdb/tui: don't leak the known_window_types map 70595 This commit finishes the task that was started in the previous 70596 commit. 70597 70598 Now that all Python TUI window factories are correctly deleted when 70599 the Python interpreter is shut down, we no longer need to dynamically 70600 allocate the known_window_types map in tui-layout.c 70601 70602 This commit changes known_window_types to a statically allocated data 70603 structure, removes the dynamic allocation from 70604 initialize_known_windows, and then replaces lots of '->' with '.' 70605 throughout this file. 70606 70607 There should be no user visible changes after this commit. 70608 70609 Reviewed-By: Tom Tromey <tom@tromey.com> 70610 706112023-02-13 Andrew Burgess <aburgess@redhat.com> 70612 70613 gdb/python: deallocate tui window factories at Python shut down 70614 The previous commit relied on spotting when a Python defined TUI 70615 window factory was deleted. I spotted that the window factories are 70616 not deleted when GDB shuts down its Python environment, they are only 70617 deleted when one window factory replaces another. Consider this 70618 example Python script: 70619 70620 class TestWindowFactory: 70621 def __init__(self, msg): 70622 self.msg = msg 70623 print("Entering TestWindowFactory.__init__: %s" % self.msg) 70624 70625 def __call__(self, tui_win): 70626 print("Entering TestWindowFactory.__call__: %s" % self.msg) 70627 return TestWindow(tui_win, self.msg) 70628 70629 def __del__(self): 70630 print("Entering TestWindowFactory.__del__: %s" % self.msg) 70631 70632 gdb.register_window_type("test_window", TestWindowFactory("A")) 70633 gdb.register_window_type("test_window", TestWindowFactory("B")) 70634 70635 And this GDB session: 70636 70637 (gdb) source tui.py 70638 Entering TestWindowFactory.__init__: A 70639 Entering TestWindowFactory.__init__: B 70640 Entering TestWindowFactory.__del__: B 70641 (gdb) quit 70642 70643 Notice that when the 'B' window replaces the 'A' window we see the 'A' 70644 object being deleted. But, when Python is shut down (after the 70645 'quit') the 'B' object is never deleted. 70646 70647 Instead, GDB retains a reference to the window factory object, which 70648 forces the Python object to remain live even after the Python 70649 interpreter itself has been shut down. 70650 70651 The references themselves are held in a dynamically allocated 70652 std::unordered_map (in tui/tui-layout.c) which is never deallocated, 70653 thus the underlying Python references are never decremented to zero, 70654 and so GDB never tries to delete these Python objects. 70655 70656 This commit is the first half of the work to clean up this edge case. 70657 70658 All gdbpy_tui_window_maker objects (the objects that implement the 70659 TUI window factory callback for Python defined TUI windows), are now 70660 linked together into a global list using the intrusive list mechanism. 70661 70662 When GDB shuts down the Python interpreter we can now walk this global 70663 list and release the reference that is held to the underlying Python 70664 object. By releasing this reference the Python object will now be 70665 deleted. 70666 70667 I've added a new assert in gdbpy_tui_window_maker::operator(), this 70668 will catch the case where we somehow end up in here after having 70669 reset the reference to the underlying Python object. I don't think 70670 this should ever happen though as we only clear the references when 70671 shutting down the Python interpreter, and the ::operator() function is 70672 only called when trying to apply a new TUI layout - something that 70673 shouldn't happen while GDB itself is shutting down. 70674 70675 This commit does not update the std::unordered_map in tui-layout.c, 70676 that will be done in the next commit. 70677 70678 Reviewed-By: Tom Tromey <tom@tromey.com> 70679 706802023-02-13 Andrew Burgess <aburgess@redhat.com> 70681 70682 gdb/python: allow Python TUI windows to be replaced 70683 The documentation for gdb.register_window_type says: 70684 70685 "... It's an error to try to replace one of the built-in windows, 70686 but other window types can be replaced. ..." 70687 70688 I take this to mean that if I imported a Python script like this: 70689 70690 gdb.register_window_type('my_window', FactoryFunction) 70691 70692 Then GDB would have a new TUI window 'my_window', which could be 70693 created by calling FactoryFunction(). If I then, in the same GDB 70694 session imported a script which included: 70695 70696 gdb.register_window_type('my_window', UpdatedFactoryFunction) 70697 70698 Then GDB would replace the old 'my_window' factory with my new one, 70699 GDB would now call UpdatedFactoryFunction(). 70700 70701 This is pretty useful in practice, as it allows users to iterate on 70702 their window implementation within a single GDB session. 70703 70704 However, right now, this is not how GDB operates. The second call to 70705 register_window_type is basically ignored and the old window factory 70706 is retained. 70707 70708 This is because in tui_register_window (tui/tui-layout.c) we use 70709 std::unordered_map::emplace to insert the new factory function, and 70710 emplace doesn't replace an existing element in an unordered_map. 70711 70712 In this commit, before the emplace call, I now search for an already 70713 existing element, and delete any matching element from the map, the 70714 emplace call will then add the new factory function. 70715 70716 Reviewed-By: Tom Tromey <tom@tromey.com> 70717 707182023-02-13 Keith Seitz <keiths@redhat.com> 70719 70720 Fix doc build dependencies for --with-system-readline 70721 PR build/30108 concerns building gdb documentation with 70722 --with-sytem-readline. If the in-tree readline directory is 70723 missing, though, the docs will fail to build: 70724 70725 make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc' 70726 make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop. 70727 70728 The listed file (and hsuser.texi) are conditionally included by gdb.texinfo. 70729 When system readline is used, gdb/configure.ac will leave 70730 READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to 70731 $BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the 70732 inclusion of the missing files. They are not needed or used in this 70733 scenario. 70734 70735 However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies, 70736 thus provoking the build error whenever readline/ is missing. 70737 70738 This patch fixes this by creating (essentially) a conditional setting of the 70739 dependencies to be included from readline. 70740 707412023-02-13 Michael Matz <matz@suse.de> 70742 70743 Fix PR30079: abort on mingw 70744 the early-out in wild_sort is not enough, it might still be 70745 that filenames are equal _and_ the wildcard list doesn't specify 70746 a sort order either. Don't call compare_section then. 70747 70748 Tested on all targets. 70749 707502023-02-13 Alan Modra <amodra@gmail.com> 70751 70752 _bfd_ecoff_slurp_symbol_table buffer overflow 70753 Add missing bounds check, and tidy the existing bounds checking. 70754 70755 * ecoff.c (_bfd_ecoff_slurp_symbol_table): Break overlong lines. 70756 Set bfd_error. Bounds check internal_sym.iss. 70757 707582023-02-13 Andrew Burgess <aburgess@redhat.com> 70759 70760 opcodes/mips: disassemble unknown micromips instructions as two shorts 70761 Before commit: 70762 70763 commit 2438b771ee07be19d5b01ea55e077dd8b7cef445 70764 Date: Wed Nov 2 15:53:43 2022 +0000 70765 70766 opcodes/mips: use .word/.short for undefined instructions 70767 70768 unknown 32-bit microMIPS instructions were disassembled as a raw 70769 32-bit number with no '.word' directive. The above commit changed 70770 this and added a '.word' directive before the 32-bit number. 70771 70772 It was pointed out on the mailing list, that for microMIPS it would be 70773 better to display such 32-bit instructions using a '.short' directive 70774 followed by two 16-bit values. 70775 70776 This commit updates the mips disassembler to do this, and adds a new 70777 test that validates this output. 70778 707792023-02-13 Andrew Burgess <aburgess@redhat.com> 70780 70781 gdb/testsuite: handle differences in guile error string output 70782 A new guile test added in commit: 70783 70784 commit 0a9ccb9dd79384f3ba3f8cd75940e8868f3b526f 70785 Date: Mon Feb 6 13:04:16 2023 +0000 70786 70787 gdb: only allow one of thread or task on breakpoints or watchpoints 70788 70789 fails for some versions of guile. It turns out that some versions of 70790 guile emit an error like this: 70791 70792 (gdb) guile (set-breakpoint-thread! bp 1) 70793 ERROR: In procedure set-breakpoint-thread!: 70794 In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes 70795 Error while executing Scheme code. 70796 70797 while other versions of guile emit the error like this: 70798 70799 (gdb) guile (set-breakpoint-thread! bp 1) 70800 ERROR: In procedure set-breakpoint-thread!: 70801 ERROR: In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes 70802 Error while executing Scheme code. 70803 70804 notice the extra 'ERROR: ' on the second line of output. This commit 70805 updates the test regexp to handle this optional 'ERROR: ' string. 70806 708072023-02-13 Alan Modra <amodra@gmail.com> 70808 70809 stabs.c static state 70810 Move all the function local static state variables to file scope, 70811 in order to tidy memory on exit and to reinit everything for that 70812 annoying oss-fuzz. Also fix a couple memory leaks. 70813 70814 * read.h (read_begin, read_end): Declare. 70815 * read.c (read_begin): Call stabs_begin. 70816 (read_end): Call stabs_end. 70817 * stabs.c (stabs_begin, stabs_end): New functions. 70818 (in_dot_func_p): Delete, use current_function_label instead. 70819 (cached_sec): Move from s_stab_generic. 70820 (last_asm_file, file_label_count): Move from generate_asm_file. 70821 (line_label_count, prev_lineno, prev_line_file): Move from 70822 stabs_generate_asm_lineno. 70823 (void_emitted_p): Move from stabs_generate_asm_func. 70824 (endfunc_label_count): Move from stabs_generate_asm_endfunc. 70825 (stabs_generate_asm_lineno): Simplify setting of 70826 prev_line_file. 70827 (stabs_generate_asm_func): Don't leak current_function_label. 70828 (stabs_generate_asm_endfunc): Likewise. 70829 708302023-02-13 Alan Modra <amodra@gmail.com> 70831 70832 Split off gas init to functions 70833 With some slight reordering. 70834 70835 * as.c (gas_early_init, gas_late_init): New functions, split.. 70836 (main): ..from here. 70837 708382023-02-13 Lancelot SIX <lancelot.six@amd.com> 70839 70840 gdb/testsuite: look for hipcc in env(ROCM_PATH) 70841 If the hipcc compiler cannot be found in dejagnu's tool_root_dir, look 70842 for it in $::env(ROCM_PATH) (if set). If hipcc is still not found, 70843 fallback to "hipcc" so the compiler will be searched in the PATH. This 70844 removes the fallback to the hard-coded "/opt/rocm/bin" prefix. 70845 70846 This change is done so ROCM tools are searched in a uniform manner. 70847 70848 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70849 708502023-02-13 Lancelot SIX <lancelot.six@amd.com> 70851 70852 gdb/testsuite: allow_hipcc_tests tests the hipcc compiler 70853 Update allow_hipcc_tests so all gdb.rocm tests are skipped if we do not 70854 have a working hipcc compiler available. 70855 70856 To achieve this, adjust gdb_simple_compile to ensure that the hip 70857 program is saved in a ".cpp" file before calling hipcc otherwise 70858 compilation will fail. 70859 70860 One thing to note is that it is possible to have a hipcc installed with 70861 a CUDA backend. Compiling with this back-end will successfully result 70862 in an application, but GDB cannot debug it (at least for the offload 70863 part). In the context of the gdb.rocm tests, we want to detect such 70864 situation where gdb_simple_compile would give a false positive. 70865 70866 To achieve this, this patch checks that there is at least one AMDGPU 70867 device available and that hipcc can compile for this or those targets. 70868 Detecting the device is done using the rocm_agent_enumerator tool which 70869 is installed with the all ROCm installations (it is used by hipcc to 70870 detect identify targets if this is not specified on the comand line). 70871 70872 This patch also makes the allow_hipcc_tests proc a cached proc. 70873 70874 Co-Authored-By: Pedro Alves <pedro@palves.net> 70875 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70876 708772023-02-13 Lancelot SIX <lancelot.six@amd.com> 70878 70879 gdb/testsuite: require amd-dbgapi support to run rocm tests 70880 Update allow_hipcc_tests to check that GDB has the amd-dbgapi support 70881 built-in. Without this support, all tests using hipcc and the rocm 70882 stack will fail. 70883 70884 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70885 708862023-02-13 Lancelot SIX <lancelot.six@amd.com> 70887 70888 gdb/testsuite: Rename skip_hipcc_tests to allow_hipcc_tests 70889 Rename skip_hipcc_tests to allow_hipcc_tests so it can be used as a 70890 "require" predicate in tests. 70891 70892 Use require in gdb.rocm/simple.exp. 70893 70894 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70895 708962023-02-13 Lancelot SIX <lancelot.six@amd.com> 70897 70898 gdb: 'show config' shows --with[out]-amd-dbgapi 70899 Ensure that the "show configuration" command and the "--configuration" 70900 command line switch shows if GDB was built with the AMDGPU support or 70901 not. 70902 70903 This will be used in a later patch in this series. 70904 70905 Approved-By: Simon Marchi <simon.marchi@efficios.com> 70906 709072023-02-13 Alan Modra <amodra@gmail.com> 70908 70909 objcopy memory leaks 70910 This fixes some objcopy memory leaks. commit 450da4bd38ae used 70911 xatexit to tidy most of the hash table memory, but of course that's 70912 ineffective without a call to xexit. The other major memory leak 70913 happens if there is an error of some sort writing the output file, due 70914 to not closing the input file and thus not freeing memory attached to 70915 the bfd. 70916 70917 * objcopy.c (copy_file): Don't return when bfd_close of output 70918 gives an error, always bfd_close input too. 70919 (main): Call xexit. 70920 709212023-02-13 GDB Administrator <gdbadmin@sourceware.org> 70922 70923 Automatic date update in version.in 70924 709252023-02-12 Tom Tromey <tom@tromey.com> 70926 70927 Move some code from dwarf2/read.c to die.c 70928 This patch introduces a new file, dwarf2/die.c, and moves some 70929 DIE-related code out of dwarf2/read.c and into this new file. This is 70930 just a small part of the long-term project to split up read.c. 70931 (According to 'wc', dwarf2/read.c is the largest file in gdb by around 70932 8000 LOC.) 70933 70934 Regression tested on x86-64 Fedora 36. 70935 709362023-02-12 Andrew Burgess <aburgess@redhat.com> 70937 70938 gdb: fix describe_other_breakpoints for default task being -1 70939 Commit: 70940 70941 commit 2ecee236752932672fb3d6cd63c6976927f747d8 70942 CommitDate: Sun Feb 12 05:46:44 2023 +0000 70943 70944 gdb: use -1 for breakpoint::task default value 70945 70946 Failed to take account of an earlier commit: 70947 70948 commit f1f517e81039f6aa673b7d87a66bfbd25a66e3d3 70949 CommitDate: Sat Feb 11 17:36:24 2023 +0000 70950 70951 gdb: show task number in describe_other_breakpoints 70952 70953 That both of these are my own commits is only more embarrassing. 70954 70955 This small fix updates describe_other_breakpoints to take account of 70956 the default task number now being -1. This fixes regressions in 70957 gdb.base/break.exp, gdb.base/break-always.exp, and many other tests. 70958 709592023-02-12 Andrew Burgess <aburgess@redhat.com> 70960 70961 gdb/c++: fix handling of breakpoints on @plt symbols 70962 This commit should fix PR gdb/20091, PR gdb/17201, and PR gdb/17071. 70963 Additionally, PR gdb/17199 relates to this area of code, but is more 70964 of a request to refactor some parts of GDB, this commit does not 70965 address that request, but it is probably worth reading that PR when 70966 looking at this commit. 70967 70968 When the current language is C++, and the user places a breakpoint on 70969 a function in a shared library, GDB will currently find two locations 70970 for the breakpoint, one location will be within the function itself as 70971 we would expect, but the other location will be within the PLT table 70972 for the call to the named function. Consider this session: 70973 70974 $ gdb -q /tmp/breakpoint-shlib-func 70975 Reading symbols from /tmp/breakpoint-shlib-func... 70976 (gdb) start 70977 Temporary breakpoint 1 at 0x40112e: file /tmp/breakpoint-shlib-func.cc, line 20. 70978 Starting program: /tmp/breakpoint-shlib-func 70979 70980 Temporary breakpoint 1, main () at /tmp/breakpoint-shlib-func.cc:20 70981 20 int answer = foo (); 70982 (gdb) break foo 70983 Breakpoint 2 at 0x401030 (2 locations) 70984 (gdb) info breakpoints 70985 Num Type Disp Enb Address What 70986 2 breakpoint keep y <MULTIPLE> 70987 2.1 y 0x0000000000401030 <foo()@plt> 70988 2.2 y 0x00007ffff7fc50fd in foo() at /tmp/breakpoint-shlib-func-lib.cc:20 70989 70990 This is not the expected behaviour. If we compile the same test using 70991 a C compiler then we see this: 70992 70993 (gdb) break foo 70994 Breakpoint 2 at 0x7ffff7fc50fd: file /tmp/breakpoint-shlib-func-c-lib.c, line 20. 70995 (gdb) info breakpoints 70996 Num Type Disp Enb Address What 70997 2 breakpoint keep y 0x00007ffff7fc50fd in foo at /tmp/breakpoint-shlib-func-c-lib.c:20 70998 70999 Here's what's happening. When GDB parses the symbols in the main 71000 executable and the shared library we see a number of different symbols 71001 for foo, and use these to create entries in GDB's msymbol table: 71002 71003 - In the main executable we see a symbol 'foo@plt' that points at 71004 the plt entry for foo, from this we add two entries into GDB's 71005 msymbol table, one called 'foo@plt' which points at the plt entry 71006 and has type mst_text, then we create a second symbol, this time 71007 called 'foo' with type mst_solib_trampoline which also points at 71008 the plt entry, 71009 71010 - Then, when the shared library is loaded we see another symbol 71011 called 'foo', this one points at the actual implementation in the 71012 shared library. This time GDB creates a msymbol called 'foo' with 71013 type mst_text that points at the implementation. 71014 71015 This means that GDB creates 3 msymbols to represent the 2 symbols 71016 found in the executable and shared library. 71017 71018 When the user creates a breakpoint on 'foo' GDB eventually ends up in 71019 search_minsyms_for_name (linespec.c), this function then calls 71020 iterate_over_minimal_symbols passing in the name we are looking for 71021 wrapped in a lookup_name_info object. 71022 71023 In iterate_over_minimal_symbols we iterate over two hash tables (using 71024 the name we're looking for as the hash key), first we walk the hash 71025 table of symbol linkage names, then we walk the hash table of 71026 demangled symbol names. 71027 71028 When the language is C++ the symbols for 'foo' will all have been 71029 mangled, as a result, in this case, the iteration of the linkage name 71030 hash table will find no matching results. 71031 71032 However, when we walk the demangled hash table we do find some 71033 results. In order to match symbol names, GDB obtains a symbol name 71034 matching function by calling the get_symbol_name_matcher method on the 71035 language_defn class. For C++, in this case, the matching function we 71036 use is cp_fq_symbol_name_matches, which delegates the work to 71037 strncmp_iw_with_mode with mode strncmp_iw_mode::MATCH_PARAMS and 71038 language set to language_cplus. 71039 71040 The strncmp_iw_mode::MATCH_PARAMS mode means that strncmp_iw_mode will 71041 skip any parameters in the demangled symbol name when checking for a 71042 match, e.g. 'foo' will match the demangled name 'foo()'. The way this 71043 is done is that the strings are matched character by character, but, 71044 once the string we are looking for ('foo' here) is exhausted, if we 71045 are looking at '(' then we consider the match a success. 71046 71047 Lets consider the 3 symbols GDB created. If the function declaration 71048 is 'void foo ()' then from the main executable we added symbols 71049 '_Z3foov@plt' and '_Z3foov', while from the shared library we added 71050 another symbol call '_Z3foov'. When these are demangled they become 71051 'foo()@plt', 'foo()', and 'foo()' respectively. 71052 71053 Now, the '_Z3foov' symbol from the main executable has the type 71054 mst_solib_trampoline, and in search_minsyms_for_name, we search for 71055 any symbols of type mst_solib_trampoline and filter these out of the 71056 results. 71057 71058 However, the '_Z3foov@plt' symbol (from the main executable), and the 71059 '_Z3foov' symbol (from the shared library) both have type mst_text. 71060 71061 During the demangled name matching, due to the use of MATCH_PARAMS 71062 mode, we stop the comparison as soon as we hit a '(' in the demangled 71063 name. And so, '_Z3foov@plt', which demangles to 'foo()@plt' matches 71064 'foo', and '_Z3foov', which demangles to 'foo()' also matches 'foo'. 71065 71066 By contrast, for C, there are no demangled hash table entries to be 71067 iterated over (in iterate_over_minimal_symbols), we only consider the 71068 linkage name symbols which are 'foo@plt' and 'foo'. The plain 'foo' 71069 symbol obviously matches when we are looking for 'foo', but in this 71070 case the 'foo@plt' will not match due to the '@plt' suffix. 71071 71072 And so, when the user asks for a breakpoint in 'foo', and the language 71073 is C, search_minsyms_for_name, returns a single msymbol, the mst_text 71074 symbol for foo in the shared library, while, when the language is C++, 71075 we get two results, '_Z3foov' for the shared library function, and 71076 '_Z3foov@plt' for the plt entry in the main executable. 71077 71078 I propose to fix this in strncmp_iw_with_mode. When the mode is 71079 MATCH_PARAMS, instead of stopping at a '(' and assuming the match is a 71080 success, GDB will instead search forward for the matching, closing, 71081 ')', effectively skipping the parameter list, and then resume 71082 matching. Thus, when comparing 'foo' to 'foo()@plt' GDB will 71083 effectively compare against 'foo@plt' (skipping the parameter list), 71084 and the match will fail, just as it does when the language is C. 71085 71086 There is one slight complication, which is revealed by the test 71087 gdb.linespec/cpcompletion.exp, when searching for the symbol of a 71088 const member function, the demangled symbol will have 'const' at the 71089 end of its name, e.g.: 71090 71091 struct_with_const_overload::const_overload_fn() const 71092 71093 Previously, the matching would stop at the '(' character, but after my 71094 change the whole '()' is skipped, and the match resumes. As a result, 71095 the 'const' modifier results in a failure to match, when previously 71096 GDB would have found a match. 71097 71098 To work around this issue, in strncmp_iw_with_mode, when mode is 71099 MATCH_PARAMS, after skipping the parameter list, if the next character 71100 is '@' then we assume we are looking at something like '@plt' and 71101 return a value indicating the match failed, otherwise, we return a 71102 value indicating the match succeeded, this allows things like 'const' 71103 to be skipped. 71104 71105 With these changes in place I now see GDB correctly setting a 71106 breakpoint only at the implementation of 'foo' in the shared library. 71107 71108 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20091 71109 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17201 71110 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17071 71111 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17199 71112 71113 Tested-By: Bruno Larsen <blarsen@redhat.com> 71114 Approved-By: Simon Marchi <simon.marchi@efficios.com> 71115 711162023-02-12 Andrew Burgess <aburgess@redhat.com> 71117 71118 gdb: use -1 for breakpoint::task default value 71119 Within the breakpoint struct we have two fields ::thread and ::task 71120 which are used for thread or task specific breakpoints. When a 71121 breakpoint doesn't have a specific thread or task then these fields 71122 have the values -1 and 0 respectively. 71123 71124 There's no particular reason (as far as I can tell) why these two 71125 "default" values are different, and I find the difference a little 71126 confusing. Long term I'd like to potentially fold these two fields 71127 into a single field, but that isn't what this commit does. 71128 71129 What this commit does is switch to using -1 as the "default" value for 71130 both fields, this means that the default for breakpoint::task has 71131 changed from 0 to -1. I've updated all the code I can find that 71132 relied on the value of 0, and I see no test regressions, especially in 71133 gdb.ada/tasks.exp, which still fully passes. 71134 71135 There should be no user visible changes after this commit. 71136 71137 Approved-By: Pedro Alves <pedro@palves.net> 71138 711392023-02-12 Andrew Burgess <aburgess@redhat.com> 71140 71141 gdb: only allow one of thread or task on breakpoints or watchpoints 71142 After this mailing list posting: 71143 71144 https://sourceware.org/pipermail/gdb-patches/2023-February/196607.html 71145 71146 it seems to me that in practice an Ada task maps 1:1 with a GDB 71147 thread, and so it doesn't really make sense to allow uses to give both 71148 a thread and a task within a single breakpoint or watchpoint 71149 condition. 71150 71151 This commit updates GDB so that the user will get an error if both 71152 are specified. 71153 71154 I've added new tests to cover the CLI as well as the Python and Guile 71155 APIs. For the Python and Guile testing, as far as I can tell, this 71156 was the first testing for this corner of the APIs, so I ended up 71157 adding more than just a single test. 71158 71159 For documentation I've added a NEWS entry, but I've not added anything 71160 to the docs themselves. Currently we document the commands with a 71161 thread-id or task-id as distinct command, e.g.: 71162 71163 'break LOCSPEC task TASKNO' 71164 'break LOCSPEC task TASKNO if ...' 71165 'break LOCSPEC thread THREAD-ID' 71166 'break LOCSPEC thread THREAD-ID if ...' 71167 71168 As such, I don't believe there is any indication that combining 'task' 71169 and 'thread' would be expected to work; it seems clear to me in the 71170 above that those four options are all distinct commands. 71171 71172 I think the NEWS entry is enough that if someone is combining these 71173 keywords (it's not clear what the expected behaviour would be in this 71174 case) then they can figure out that this was a deliberate change in 71175 GDB, but for a new user, the manual doesn't suggest combining them is 71176 OK, and any future attempt to combine them will give an error. 71177 71178 Approved-By: Pedro Alves <pedro@palves.net> 71179 711802023-02-12 GDB Administrator <gdbadmin@sourceware.org> 71181 71182 Automatic date update in version.in 71183 711842023-02-11 Andrew Burgess <aburgess@redhat.com> 71185 71186 gdb: show task number in describe_other_breakpoints 71187 I noticed that describe_other_breakpoints doesn't show the task 71188 number, but does show the thread-id. I can't see any reason why we'd 71189 want to not show the task number in this situation, so this commit 71190 adds this missing information, and extends gdb.ada/tasks.exp to check 71191 this case. 71192 71193 Approved-By: Pedro Alves <pedro@palves.net> 71194 711952023-02-11 Andrew Burgess <aburgess@redhat.com> 71196 71197 gdb: don't print global thread-id to CLI in describe_other_breakpoints 71198 I noticed that describe_other_breakpoints was printing the global 71199 thread-id to the CLI. For CLI output we should be printing the 71200 inferior local thread-id (e.g. "2.1"). This can be seen in the 71201 following GDB session: 71202 71203 (gdb) info threads 71204 Id Target Id Frame 71205 1.1 Thread 4065742.4065742 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27 71206 * 2.1 Thread 4065743.4065743 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27 71207 (gdb) break foo thread 2.1 71208 Breakpoint 3 at 0x40110a: foo. (2 locations) 71209 (gdb) break foo thread 1.1 71210 Note: breakpoint 3 (thread 2) also set at pc 0x40110a. 71211 Note: breakpoint 3 (thread 2) also set at pc 0x40110a. 71212 Breakpoint 4 at 0x40110a: foo. (2 locations) 71213 71214 Notice that GDB says: 71215 71216 Note: breakpoint 3 (thread 2) also set at pc 0x40110a. 71217 71218 The 'thread 2' in here is using the global thread-id, we should 71219 instead say 'thread 2.1' which corresponds to how the user specified 71220 the breakpoint. 71221 71222 This commit fixes this issue and adds a test. 71223 71224 Approved-By: Pedro Alves <pedro@palves.net> 71225 712262023-02-11 Andrew Burgess <aburgess@redhat.com> 71227 71228 gdb: add test for readline handling very long commands 71229 The test added in this commit tests for a long fixed readline issue 71230 relating to long command lines. A similar patch has existed in the 71231 Fedora GDB tree for several years, but I don't see any reason why this 71232 test would not be suitable for inclusion in upstream GDB. I've 71233 updated the patch to current testsuite standards. 71234 71235 The test is checking for an issue that was fixed by this readline 71236 patch: 71237 71238 https://lists.gnu.org/archive/html/bug-readline/2006-11/msg00002.html 71239 71240 Which was merged into readline 6.0 (released ~2010). The issue was 71241 triggered when the user enters a long command line, which wrapped over 71242 multiple terminal lines. The crash looks like this: 71243 71244 free(): invalid pointer 71245 71246 Fatal signal: Aborted 71247 ----- Backtrace ----- 71248 0x4fb583 gdb_internal_backtrace_1 71249 ../../src/gdb/bt-utils.c:122 71250 0x4fb583 _Z22gdb_internal_backtracev 71251 ../../src/gdb/bt-utils.c:168 71252 0x6047b9 handle_fatal_signal 71253 ../../src/gdb/event-top.c:964 71254 0x7f26e0cc56af ??? 71255 0x7f26e0cc5625 ??? 71256 0x7f26e0cae8d8 ??? 71257 0x7f26e0d094be ??? 71258 0x7f26e0d10aab ??? 71259 0x7f26e0d124ab ??? 71260 0x7f26e1d32e12 rl_free_undo_list 71261 ../../readline-5.2/undo.c:119 71262 0x7f26e1d229eb readline_internal_teardown 71263 ../../readline-5.2/readline.c:405 71264 0x7f26e1d3425f rl_callback_read_char 71265 ../../readline-5.2/callback.c:197 71266 0x604c0d gdb_rl_callback_read_char_wrapper_noexcept 71267 ../../src/gdb/event-top.c:192 71268 0x60581d gdb_rl_callback_read_char_wrapper 71269 ../../src/gdb/event-top.c:225 71270 0x60492f stdin_event_handler 71271 ../../src/gdb/event-top.c:545 71272 0xa60015 gdb_wait_for_event 71273 ../../src/gdbsupport/event-loop.cc:694 71274 0xa6078d gdb_wait_for_event 71275 ../../src/gdbsupport/event-loop.cc:593 71276 0xa6078d _Z16gdb_do_one_eventi 71277 ../../src/gdbsupport/event-loop.cc:264 71278 0x6fc459 start_event_loop 71279 ../../src/gdb/main.c:411 71280 0x6fc459 captured_command_loop 71281 ../../src/gdb/main.c:471 71282 0x6fdce4 captured_main 71283 ../../src/gdb/main.c:1310 71284 0x6fdce4 _Z8gdb_mainP18captured_main_args 71285 ../../src/gdb/main.c:1325 71286 0x44f694 main 71287 ../../src/gdb/gdb.c:32 71288 --------------------- 71289 71290 I recreated the above crash by a little light hacking on GDB, and then 71291 linking GDB against readline 5.2. The above stack trace was generated 71292 from the test included in this patch, and matches the trace that was 71293 included in the original bug report. 71294 71295 It is worth acknowledging that without hacking things GDB has a 71296 minimum requirement of readline 7.0. This test is not about checking 71297 whether GDB has been built against an older version of readline, it is 71298 about checking that readline doesn't regress in this area. 71299 71300 Reviewed-By: Tom Tromey <tom@tromey.com> 71301 713022023-02-11 Andrew Burgess <aburgess@redhat.com> 71303 71304 gdb: remove unnecessary 'dir' commands from gdb-gdb.gdb script 71305 While debugging GDB I used 'show directories' and spotted lots of 71306 entries that didn't make much sense. Here are all the entries that are 71307 in my directories list: 71308 71309 /tmp/binutils-gdb/build 71310 /tmp/binutils-gdb/build/../../src/gdb 71311 /tmp/binutils-gdb/build/../../src/gdb/../bfd 71312 /tmp/binutils-gdb/build/../../src/gdb/../libiberty 71313 $cdir 71314 $cwd 71315 71316 Notice the second, third, and fourth entries in this list, these 71317 should really be: 71318 71319 /tmp/binutils-gdb/build/../src/gdb 71320 /tmp/binutils-gdb/build/../src/gdb/../bfd 71321 /tmp/binutils-gdb/build/../src/gdb/../libiberty 71322 71323 The problem is because I generally run everything from the top level 71324 build directory, not the gdb/ sub-directory, thus, I start GDB like: 71325 71326 ./gdb/gdb --data-directory ./gdb/data-directory 71327 71328 If run GDB under GDB, then I end up loading the gdb/gdb-gdb.gdb 71329 script, which contains these lines: 71330 71331 dir ../../src/gdb/../libiberty 71332 dir ../../src/gdb/../bfd 71333 dir ../../src/gdb 71334 dir . 71335 71336 These commands only make sense when running within the gdb/ 71337 sub-directory. 71338 71339 However, my debugging experience doesn't seem to be degraded at all, I 71340 can still see the GDB source code just fine; which is because the 71341 directory list still contains $cdir. 71342 71343 The build/gdb/gdb-gdb.gdb script is created from the 71344 src/gdb/gdb-gdb.gdb.in template, which includes the automake @srcdir@ 71345 markers. 71346 71347 The 'dir' commands have mostly been around since the sourceware 71348 repository was first created, though this commit 67f0714670383a did 71349 reorder some of the 'dir' commands, which would seem to indicate these 71350 commands were important to some people, at some time. 71351 71352 One possible fix would be to replace @srcdir@ with @abs_srcdir@, this 71353 would ensure that the entries added were all valid, no matter the 71354 user's current directory when debugging GDB. 71355 71356 However... I'd like to propose that we instead remove all the extra 71357 directories completely. My hope is that, with more recent tools, the 71358 debug information should allow us to correctly find all of the source 71359 files without having to add any extra 'dir' entries. Obviously, 71360 commit 67f0714670383a does make me a little nervous, but the 71361 gdb-gdb.gdb script isn't something a non-maintainer will be using, so 71362 I think we can afford to be a little more aggressive here. If it 71363 turns out the 'dir' entries are needed then we can add them back, but 71364 actually document why they are needed. Plus, when we add them back we 71365 will use @abs_srcdir@ instead of @srcdir@. 71366 71367 Reviewed-By: Tom Tromey <tom@tromey.com> 71368 713692023-02-11 Tom de Vries <tdevries@suse.de> 71370 71371 [gdb/tdep] Don't use i386 unwinder for amd64 71372 For i386 we have these unwinders: 71373 ... 71374 $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" 71375 The target architecture is set to "i386". 71376 dummy DUMMY_FRAME 71377 dwarf2 tailcall TAILCALL_FRAME 71378 inline INLINE_FRAME 71379 i386 epilogue NORMAL_FRAME 71380 dwarf2 NORMAL_FRAME 71381 dwarf2 signal SIGTRAMP_FRAME 71382 i386 stack tramp NORMAL_FRAME 71383 i386 sigtramp SIGTRAMP_FRAME 71384 i386 prologue NORMAL_FRAME 71385 ... 71386 and for amd64: 71387 ... 71388 $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" 71389 The target architecture is set to "i386:x86-64". 71390 dummy DUMMY_FRAME 71391 dwarf2 tailcall TAILCALL_FRAME 71392 inline INLINE_FRAME 71393 python NORMAL_FRAME 71394 amd64 epilogue NORMAL_FRAME 71395 i386 epilogue NORMAL_FRAME 71396 dwarf2 NORMAL_FRAME 71397 dwarf2 signal SIGTRAMP_FRAME 71398 amd64 sigtramp SIGTRAMP_FRAME 71399 amd64 prologue NORMAL_FRAME 71400 i386 stack tramp NORMAL_FRAME 71401 i386 sigtramp SIGTRAMP_FRAME 71402 i386 prologue NORMAL_FRAME 71403 ... 71404 71405 ISTM me there's no reason for the i386 unwinders to be there for amd64. 71406 71407 Furthermore, there's a generic need to play around with enabling and disabling 71408 unwinders, see PR8434. Currently, that's only available for both the dwarf2 71409 unwinders at once using "maint set dwarf unwinders on/off". 71410 71411 If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue" 71412 unwinder becomes active and gives the wrong answer, while I'm actually 71413 interested in the result of the dwarf2 unwinder. Of course I can also 71414 manually disable the "i386 epilogue", but I take the fact that I have to do 71415 that as evidence that on amd64, the "i386 epilogue" is not only unnecessary, 71416 but in the way. 71417 71418 Fix this by only adding the i386 unwinders if 71419 "info.bfd_arch_info->bits_per_word == 32". 71420 71421 Note that the x32 abi (x86_64/-mx32): 71422 - has the same unwinder list as amd64 (x86_64/-m64) before this commit, 71423 - has info.bfd_arch_info->bits_per_word == 64, the same as amd64, and 71424 consequently, 71425 - has the same unwinder list as amd64 after this commit. 71426 71427 Tested on x86_64-linux, -m64 and -m32. Not tested with -mx32. 71428 71429 Reviewed-By: John Baldwin <jhb@freebsd.org> 71430 71431 PR tdep/30102 71432 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30102 71433 714342023-02-11 Alan Modra <amodra@gmail.com> 71435 71436 objdump -D of bss sections and -s with -j 71437 There is some inconsistency between the behaviour of objdump -D and 71438 objdump -s, both supposedly operating on all sections by default. 71439 objdump -s ignores bss sections, while objdump -D dissassembles the 71440 zeros. Fix this by making objdump -D ignore bss sections too. 71441 71442 Furthermore, "objdump -s -j .bss" doesn't dump .bss as it should, 71443 since the user is specifically asking to look at all those zeros. 71444 71445 This change does find some tests that used objdump -D with expected 71446 output in bss-style sections. I've updated all the msp430 tests that 71447 just wanted to find a non-empty section to look at section headers 71448 instead, making the tests slightly more stringent. The ppc xcoff and 71449 spu tests are fixed by adding -j options to objdump, which makes the 71450 tests somewhat more lenient. 71451 71452 binutils/ 71453 * objdump.c (disassemble_section): Ignore sections without 71454 contents, unless overridden by -j. 71455 (dump_section): Allow -j to override the default of not 71456 displaying sections without contents. 71457 * doc/binutils.texi (objdump options): Update -D, -s and -j 71458 description. 71459 gas/ 71460 * testsuite/gas/ppc/xcoff-tls-32.d: Select wanted objdump 71461 sections with -j. 71462 * testsuite/gas/ppc/xcoff-tls-64.d: Likewise. 71463 ld/ 71464 * testsuite/ld-msp430-elf/main-bss-lower.d, 71465 * testsuite/ld-msp430-elf/main-bss-upper.d, 71466 * testsuite/ld-msp430-elf/main-const-lower.d, 71467 * testsuite/ld-msp430-elf/main-const-upper.d, 71468 * testsuite/ld-msp430-elf/main-text-lower.d, 71469 * testsuite/ld-msp430-elf/main-text-upper.d, 71470 * testsuite/ld-msp430-elf/main-var-lower.d, 71471 * testsuite/ld-msp430-elf/main-var-upper.d: Expect -wh output. 71472 * testsuite/ld-msp430-elf/msp430-elf.exp: Use objdump -wh 71473 rather than objdump -D or objdump -d with tests checking for 71474 non-empty given sections. 71475 * testsuite/ld-spu/ear.d, 71476 * testsuite/ld-spu/icache1.d, 71477 * testsuite/ld-spu/ovl.d, 71478 * testsuite/ld-spu/ovl2.d: Select wanted objdump sections. 71479 714802023-02-11 Alan Modra <amodra@gmail.com> 71481 71482 .debug sections without contents 71483 * dwarf1.c (_bfd_dwarf1_find_nearest_line): Exclude .debug 71484 sections without contents. 71485 714862023-02-11 Aaron Merey <amerey@redhat.com> 71487 71488 gdb/source: Fix open_source_file error handling 71489 open_source_file relies on errno to communicate the reason for a missing 71490 source file. 71491 71492 open_source_file may also call debuginfod_find_source. It is possible 71493 for debuginfod_find_source to set errno to a value unrelated to the 71494 reason for a failed download. 71495 71496 This can result in bogus error messages being reported as the reason for 71497 a missing source file. The following error message should instead be 71498 "No such file or directory": 71499 71500 Temporary breakpoint 1, 0x00005555556f4de0 in main () 71501 (gdb) list 71502 Downloading source file /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in> 71503 1 /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in>: Directory not empty. 71504 71505 Fix this by having open_source_file return a negative errno if it fails 71506 to open a source file. Use this value to generate the error message 71507 instead of errno. 71508 71509 Approved-By: Tom Tromey <tom@tromey.com> 71510 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29999 71511 715122023-02-11 Aaron Merey <amerey@redhat.com> 71513 71514 Move implementation of perror_with_name to gdbsupport 71515 gdbsupport/errors.h declares perror_with_name and leaves the 71516 implementation to the clients. 71517 71518 However gdb and gdbserver's implementations are essentially the 71519 same, resulting in unnecessary code duplication. 71520 71521 Fix this by implementing perror_with_name in gdbsupport. Add an 71522 optional parameter for specifying the errno used to generate the 71523 error message. 71524 71525 Also move the implementation of perror_string to gdbsupport since 71526 perror_with_name requires it. 71527 71528 Approved-By: Tom Tromey <tom@tromey.com> 71529 715302023-02-11 GDB Administrator <gdbadmin@sourceware.org> 71531 71532 Automatic date update in version.in 71533 715342023-02-10 Andrew Burgess <andrew.burgess@embecosm.com> 71535 71536 GDB: Introduce limited array lengths while printing values 71537 This commit introduces the idea of loading only part of an array in 71538 order to print it, what I call "limited length" arrays. 71539 71540 The motivation behind this work is to make it possible to print slices 71541 of very large arrays, where very large means bigger than 71542 `max-value-size'. 71543 71544 Consider this GDB session with the current GDB: 71545 71546 (gdb) set max-value-size 100 71547 (gdb) p large_1d_array 71548 value requires 400 bytes, which is more than max-value-size 71549 (gdb) p -elements 10 -- large_1d_array 71550 value requires 400 bytes, which is more than max-value-size 71551 71552 notice that the request to print 10 elements still fails, even though 10 71553 elements should be less than the max-value-size. With a patched version 71554 of GDB: 71555 71556 (gdb) p -elements 10 -- large_1d_array 71557 $1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...} 71558 71559 So now the print has succeeded. It also has loaded `max-value-size' 71560 worth of data into value history, so the recorded value can be accessed 71561 consistently: 71562 71563 (gdb) p -elements 10 -- $1 71564 $2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...} 71565 (gdb) p $1 71566 $3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 71567 20, 21, 22, 23, 24, <unavailable> <repeats 75 times>} 71568 (gdb) 71569 71570 Accesses with other languages work similarly, although for Ada only 71571 C-style [] array element/dimension accesses use history. For both Ada 71572 and Fortran () array element/dimension accesses go straight to the 71573 inferior, bypassing the value history just as with C pointers. 71574 71575 Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> 71576 715772023-02-10 Maciej W. Rozycki <macro@embecosm.com> 71578 71579 GDB/testsuite: Add `-nonl' option to `gdb_test' 71580 Add a `-nonl' option to `gdb_test' making it possible to match output 71581 from commands such as `output' that do not produce a new line sequence 71582 at the end, e.g.: 71583 71584 (gdb) output 0 71585 0(gdb) 71586 715872023-02-10 Maciej W. Rozycki <macro@embecosm.com> 71588 71589 GDB: Only make data actually retrieved into value history available 71590 While it makes sense to allow accessing out-of-bounds elements in the 71591 debuggee and see whatever there might happen to be there in memory (we 71592 are a debugger and not a programming rules enforcement facility and we 71593 want to make people's life easier in chasing bugs), e.g.: 71594 71595 (gdb) print one_hundred[-1] 71596 $1 = 0 71597 (gdb) print one_hundred[100] 71598 $2 = 0 71599 (gdb) 71600 71601 we shouldn't really pretend that we have any meaningful data around 71602 values recorded in history (what these commands really retrieve are 71603 current debuggee memory contents outside the original data accessed, 71604 really confusing in my opinion). Mark values recorded in history as 71605 such then and verify accesses to be in-range for them: 71606 71607 (gdb) print one_hundred[-1] 71608 $1 = <unavailable> 71609 (gdb) print one_hundred[100] 71610 $2 = <unavailable> 71611 71612 Add a suitable test case, which also covers integer overflows in data 71613 location calculation. 71614 71615 Approved-By: Tom Tromey <tom@tromey.com> 71616 716172023-02-10 Maciej W. Rozycki <macro@embecosm.com> 71618 71619 GDB: Fix the mess with value byte/bit range types 71620 Consistently use the LONGEST and ULONGEST types for value byte/bit 71621 offsets and lengths respectively, avoiding silent truncation for ranges 71622 exceeding the 32-bit span, which may cause incorrect matching. Also 71623 report a conversion overflow on byte ranges that cannot be expressed in 71624 terms of bits with these data types, e.g.: 71625 71626 (gdb) print one_hundred[1LL << 58] 71627 Integer overflow in data location calculation 71628 (gdb) print one_hundred[(-1LL << 58) - 1] 71629 Integer overflow in data location calculation 71630 (gdb) 71631 71632 Previously such accesses would be let through with unpredictable results 71633 produced. 71634 716352023-02-10 Maciej W. Rozycki <macro@embecosm.com> 71636 71637 GDB: Ignore `max-value-size' setting with value history accesses 71638 We have an inconsistency in value history accesses where array element 71639 accesses cause an error for entries exceeding the currently selected 71640 `max-value-size' setting even where such accesses successfully complete 71641 for elements located in the inferior, e.g.: 71642 71643 (gdb) p/d one 71644 $1 = 0 71645 (gdb) p/d one_hundred 71646 $2 = {0 <repeats 100 times>} 71647 (gdb) p/d one_hundred[99] 71648 $3 = 0 71649 (gdb) set max-value-size 25 71650 (gdb) p/d one_hundred 71651 value requires 100 bytes, which is more than max-value-size 71652 (gdb) p/d one_hundred[99] 71653 $7 = 0 71654 (gdb) p/d $2 71655 value requires 100 bytes, which is more than max-value-size 71656 (gdb) p/d $2[99] 71657 value requires 100 bytes, which is more than max-value-size 71658 (gdb) 71659 71660 According to our documentation the `max-value-size' setting is a safety 71661 guard against allocating an overly large amount of memory. Moreover a 71662 statement in documentation says, concerning this setting, that: "Setting 71663 this variable does not affect values that have already been allocated 71664 within GDB, only future allocations." While in the implementer-speak 71665 the sentence may be unambiguous I think the outside user may well infer 71666 that the setting does not apply to values previously printed. 71667 71668 Therefore rather than just fixing this inconsistency it seems reasonable 71669 to lift the setting for value history accesses, under an implication 71670 that by having been retrieved from the debuggee they have already passed 71671 the safety check. Do it then, by suppressing the value size check in 71672 `value_copy' -- under an observation that if the original value has been 71673 already loaded (i.e. it's not lazy), then it must have previously passed 71674 said check -- making the last two commands succeed: 71675 71676 (gdb) p/d $2 71677 $8 = {0 <repeats 100 times>} 71678 (gdb) p/d $2 [99] 71679 $9 = 0 71680 (gdb) 71681 71682 Expand the testsuite accordingly, covering both value history handling 71683 and the use of `value_copy' by `make_cv_value', used by Python code. 71684 716852023-02-10 Maciej W. Rozycki <macro@embecosm.com> 71686 71687 GDB: Switch to using C++ standard integer type limits 71688 Use <climits> instead of <limits.h> and ditch local fallback definitions 71689 for minimum and maximum value macros provided by C++11. Add LONGEST_MAX 71690 and LONGEST_MIN definitions. 71691 71692 Approved-By: Tom Tromey <tom@tromey.com> 71693 716942023-02-10 Tom Tromey <tromey@adacore.com> 71695 71696 Ensure all DAP requests are keyword-only 71697 Python functions implementing DAP requests should not use positional 71698 parameters -- it only makes sense to call them with keyword arguments. 71699 This patch changes the few remaining cases to start with the special 71700 "*" parameter, following this rule. 71701 717022023-02-10 Simon Marchi <simon.marchi@polymtl.ca> 71703 71704 gdb/testsuite: fix gdb.gdb/selftest.exp for native-extended-gdbserver 71705 Following commit 4e2a80ba606 ("gdb/testsuite: expect SIGSEGV from top 71706 GDB spawn id"), the next failure I get in gdb.gdb/selftest.exp, using 71707 the native-extended-gdbserver, is: 71708 71709 (gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process 71710 signal SIGINT 71711 Continuing with signal SIGINT. 71712 FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout) 71713 71714 The problem is that in this gdb_test_multiple: 71715 71716 set description "send SIGINT signal to child process" 71717 gdb_test_multiple "signal SIGINT" "$description" { 71718 -re "^signal SIGINT\r\nContinuing with signal SIGINT.\r\nQuit\r\n.* $" { 71719 pass "$description" 71720 } 71721 } 71722 71723 The "Continuing with signal SIGINT" portion is printed by the top GDB, 71724 while the Quit portion is printed by the bottom GDB. As the 71725 gdb_test_multiple is written, it expects both the the top GDB's spawn 71726 id. 71727 71728 Fix this by splitting the gdb_test_multiple in two. The first one 71729 expects the "Continuing with signal SIGINT" from the top GDB. The 71730 second one expect "Quit" and the "(xgdb)" prompt from 71731 $inferior_spawn_id. When debugging natively, this spawn id will be the 71732 same as the top GDB's spawn id, but it's different when debugging with 71733 GDBserver. 71734 71735 Change-Id: I689bd369a041b48f4dc9858d38bf977d09600da2 71736 717372023-02-10 Tom Tromey <tom@tromey.com> 71738 71739 Use std::string in main_info 71740 This changes main_info to use std::string. It removes some manual 71741 memory management. 71742 717432023-02-10 Tom de Vries <tdevries@suse.de> 71744 71745 [gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp 71746 PR testsuite/30103 reports the following failure on aarch64-linux 71747 (ubuntu 22.04): 71748 ... 71749 (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp 71750 next 71751 warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 71752 0xffdc305fef755015. 71753 Warning: 71754 Cannot insert breakpoint 0. 71755 Cannot access memory at address 0xffdc305fef755015 71756 71757 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 71758 30 } 71759 (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ 71760 (PRMS: next over longjmp) 71761 delete breakpoints 71762 Delete all breakpoints? (y or n) y 71763 (gdb) info breakpoints 71764 No breakpoints or watchpoints. 71765 (gdb) break 63 71766 No line 63 in the current file. 71767 Make breakpoint pending on future shared library load? (y or [n]) n 71768 (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ 71769 at pattern start (got interactive prompt) 71770 ... 71771 71772 The test-case intends to set the breakpoint on line number 63 in 71773 gdb.base/longjmp.c. 71774 71775 It tries to do so by specifying "break 63", which specifies a line in the 71776 "current source file". 71777 71778 Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence 71779 of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. 71780 71781 Consequently, setting the breakpoint fails. 71782 71783 Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. 71784 71785 I've managed to reproduce the FAIL on x86_64/-m32, by installing the 71786 glibc-32bit-debuginfo package. This allowed me to confirm the "current source 71787 file" that is used: 71788 ... 71789 (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ 71790 (PRMS: next over longjmp) 71791 info source^M 71792 Current source file is ../setjmp/longjmp.c^M 71793 ... 71794 71795 Tested on x86_64-linux, target boards unix/{-m64,-m32}. 71796 71797 Reported-By: Luis Machado <luis.machado@arm.com> 71798 Reviewed-By: Tom Tromey <tom@tromey.com> 71799 71800 PR testsuite/30103 71801 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103 71802 718032023-02-10 Tom de Vries <tdevries@suse.de> 71804 71805 [gdb/cli] Add maint info frame-unwinders 71806 Add a new command "maint info frame-unwinders": 71807 ... 71808 (gdb) help maint info frame-unwinders 71809 List the frame unwinders currently in effect, starting with the highest \ 71810 priority. 71811 ... 71812 71813 Output for i386: 71814 ... 71815 $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" 71816 The target architecture is set to "i386". 71817 dummy DUMMY_FRAME 71818 dwarf2 tailcall TAILCALL_FRAME 71819 inline INLINE_FRAME 71820 i386 epilogue NORMAL_FRAME 71821 dwarf2 NORMAL_FRAME 71822 dwarf2 signal SIGTRAMP_FRAME 71823 i386 stack tramp NORMAL_FRAME 71824 i386 sigtramp SIGTRAMP_FRAME 71825 i386 prologue NORMAL_FRAME 71826 ... 71827 71828 Output for x86_64: 71829 ... 71830 $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" 71831 The target architecture is set to "i386:x86-64". 71832 dummy DUMMY_FRAME 71833 dwarf2 tailcall TAILCALL_FRAME 71834 inline INLINE_FRAME 71835 python NORMAL_FRAME 71836 amd64 epilogue NORMAL_FRAME 71837 i386 epilogue NORMAL_FRAME 71838 dwarf2 NORMAL_FRAME 71839 dwarf2 signal SIGTRAMP_FRAME 71840 amd64 sigtramp SIGTRAMP_FRAME 71841 amd64 prologue NORMAL_FRAME 71842 i386 stack tramp NORMAL_FRAME 71843 i386 sigtramp SIGTRAMP_FRAME 71844 i386 prologue NORMAL_FRAME 71845 ... 71846 71847 Tested on x86_64-linux. 71848 71849 Reviewed-By: Tom Tromey <tom@tromey.com> 71850 Reviewed-By: Eli Zaretskii <eliz@gnu.org> 71851 718522023-02-10 Tsukasa OI <research_trasio@irq.a4lg.com> 71853 71854 RISC-V: Reduce effective linker relaxation passses 71855 Commit 43025f01a0c9 ("RISC-V: Improve link time complexity.") reduced the 71856 time complexity of the linker relaxation but some code portions did not 71857 reflect this change. 71858 71859 This commit fixes a comment describing each relaxation pass and reduces 71860 actual number of passes for the RISC-V linker relaxation from 3 to 2. 71861 Though it does not change the functionality, it marginally improves the 71862 performance while linking large programs (with many relocations). 71863 71864 bfd/ChangeLog: 71865 71866 * elfnn-riscv.c (_bfd_riscv_relax_section): Fix a comment to 71867 reflect current roles of each relaxation pass. 71868 71869 ld/ChangeLog: 71870 71871 * emultempl/riscvelf.em: Reduce the number of linker relaxation 71872 passes from 3 to 2. 71873 718742023-02-10 Alan Modra <amodra@gmail.com> 71875 71876 Fix mmo memory leaks 71877 The main one here is the section buffer, which can be quite large. 71878 By using alloc rather than malloc we can leave tidying memory to the 71879 generic bfd code when the bfd is closed. bfd_check_format also 71880 releases memory when object_p fails, so while it wouldn't be wrong 71881 to bfd_release at bad_format_free in mmo_object_p, it's a little extra 71882 code and work for no gain. 71883 71884 * mmo.c (mmo_object_p): bfd_alloc rather than bfd_malloc 71885 lop_stab_symbol. Don't free/release on error. 71886 (mmo_get_spec_section): bfd_zalloc rather than bfd_zmalloc 71887 section buffer. 71888 (mmo_scan): Free fname on another error path. 71889 718902023-02-10 Alan Modra <amodra@gmail.com> 71891 71892 Local label checks in integer_constant 71893 "Local labels are never absolute" says the comment. Except when they 71894 are. Testcase 71895 .offset 71896 0: 71897 a=0b 71898 I don't see any particular reason to disallow local labels inside 71899 struct definitions, so delete the comment and assertions. 71900 71901 * expr.c (integer_constant): Delete local label assertions. 71902 719032023-02-10 Jan Beulich <jbeulich@suse.com> 71904 71905 x86: drop use of VEX3SOURCES 71906 The attribute really specifies that the sum of register and memory 71907 operands is 4. Express it like that in most places, while using the 2nd 71908 (apart from XOP) CPU feature flags (FMA4) in reversed operand matching 71909 logic. 71910 71911 With the use in build_modrm_byte() gone, part of an assertion there 71912 also becomes meaningless - simplify that at the same time. 71913 71914 With all uses of the opcode modifier field gone, also drop that. 71915 719162023-02-10 Jan Beulich <jbeulich@suse.com> 71917 71918 x86: drop use of XOP2SOURCES 71919 The few XOP insns which used it wrongly didn't have VexVVVV specified. 71920 With that added, the only further missing piece to use more generic code 71921 elsewhere is SwapSources - see e.g. the BMI2 insns for similar operand 71922 patterns. 71923 71924 With the only users gone, drop the #define as well as the special case 71925 code. 71926 719272023-02-10 Jan Beulich <jbeulich@suse.com> 71928 71929 x86: limit use of XOP2SOURCES 71930 The VPROT* forms with an immediate operand are entirely standard in the 71931 way their ModR/M bytes are built. There's no reason to invoke special 71932 case code. With that the handling of an immediate there can also be 71933 dropped; it was partially bogus anyway, as in its "no memory operands" 71934 portion it ignores the possibility of an immediate operand (which was 71935 okay only because that case was already handled by more generic code). 71936 719372023-02-10 Jan Beulich <jbeulich@suse.com> 71938 71939 x86: move (and rename) opcodespace attribute 71940 This really isn't a "modifier" and rather ought to live next to the base 71941 opcode anyway. Use the bits we presently have available to fit in the 71942 field, renaming it to opcode_space. As an intended side effect this 71943 helps readability at the use sites, by shortening the references quite a 71944 bit. 71945 71946 In generated code arrange for human readable output, by using the 71947 SPACE_* constants there rather than raw numbers. This may aid debugging 71948 down the road. 71949 719502023-02-10 Jan Beulich <jbeulich@suse.com> 71951 71952 x86: simplify a few expressions 71953 Fold adjacent comparisons when, by ORing in a certain mask, the same 71954 effect can be achieved by a single one. In load_insn_p() this extends 71955 to further uses of an already available local variable. 71956 719572023-02-10 Jan Beulich <jbeulich@suse.com> 71958 71959 x86: improve special casing of certain insns 71960 Now that we have identifiers for the mnemonic strings we can avoid 71961 opcode based comparisons, for (in many cases) being more expensive and 71962 (in a few cases) being a little fragile and not self-documenting. 71963 71964 Note that the MOV optimization can be engaged by the earlier LEA one, 71965 and hence LEA also needs checking for there. 71966 719672023-02-10 Alan Modra <amodra@gmail.com> 71968 71969 objcopy of mach-o indirect symbols 71970 Anti-fuzzer measure. I'm not sure what the correct fix is for 71971 objcopy. Probably the BFD_MACH_O_S_NON_LAZY_SYMBOL_POINTERS, 71972 BFD_MACH_O_S_LAZY_SYMBOL_POINTERS and BFD_MACH_O_S_SYMBOL_STUBS 71973 contents should be read. 71974 71975 * mach-o.c (bfd_mach_o_section_get_nbr_indirect): Omit sections 71976 with NULL sec->indirect_syms. 71977 719782023-02-10 GDB Administrator <gdbadmin@sourceware.org> 71979 71980 Automatic date update in version.in 71981 719822023-02-09 Tom Tromey <tromey@adacore.com> 71983 71984 Add full display feature to dwarf-mode.el 71985 I've found that I often use dwarf-mode with relatively small test 71986 files. In this situation, it's handy to be able to expand all the 71987 DWARF, rather than moving to each "..." separately and using C-u C-m. 71988 71989 This patch implements this feature. It also makes a couple of other 71990 minor changes: 71991 71992 * I removed a stale FIXME from dwarf-mode. In practice I find I often 71993 use "g" to restore the buffer to a pristine state; checking the file 71994 mtime would work against this. 71995 71996 * I tightened the regexp in dwarf-insert-substructure. This prevents 71997 the C-m binding from trying to re-read a DIE which has already been 71998 expanded. 71999 72000 * Finally, I've bumped the dwarf-mode version number so that this 72001 version can easily be installed using package.el. 72002 72003 2023-02-09 Tom Tromey <tromey@adacore.com> 72004 72005 * dwarf-mode.el: Bump version to 1.8. 72006 (dwarf-insert-substructure): Tighten regexp. 72007 (dwarf-refresh-all): New defun. 72008 (dwarf-mode-map): Bind "A" to dwarf-refresh-all. 72009 (dwarf-mode): Remove old FIXME. 72010 720112023-02-09 Tom Tromey <tom@tromey.com> 72012 72013 Fix comment in gdb.rust/fnfield.exp 72014 gdb.rust/fnfield.exp has a comment that, I assume, I copied from some 72015 other test. This patch fixes it. 72016 720172023-02-09 Tom Tromey <tom@tromey.com> 72018 72019 Trivially simplify rust_language::print_enum 72020 rust_language::print_enum computes: 72021 72022 int nfields = variant_type->num_fields (); 72023 72024 ... but then does not reuse this in one spot. This patch corrects the 72025 oversight. 72026 720272023-02-09 Roland McGrath <mcgrathr@google.com> 72028 72029 [aarch64] Avoid initializers for VLAs 72030 Clang doesn't accept initializer syntax for variable-length 72031 arrays in C. Just use memset instead. 72032 720332023-02-09 Christina Schimpe <christina.schimpe@intel.com> 72034 72035 gdb, testsuite: Remove unnecessary call of "set print pretty on" 72036 The command has no effect for the loading of GDB pretty printers and is 72037 removed by this patch to avoid confusion. 72038 72039 Documentation for "set print pretty" 72040 "Cause GDB to print structures in an indented format with one member per line" 72041 720422023-02-09 Tom Tromey <tromey@adacore.com> 72043 72044 Increase size of main_type::nfields 72045 main_type::nfields is a 'short', and has been for many years. PR 72046 c++/29985 points out that 'short' is too narrow for an enum that 72047 contains more than 2^15 constants. 72048 72049 This patch bumps the size of 'nfields'. To verify that the field 72050 isn't directly used, it is also renamed. Note that this does not 72051 affect the size of main_type on x86-64 Fedora 36. And, if it does 72052 have a negative effect somewhere, it's worth considering that types 72053 could be shrunk more drastically by using subclasses for the different 72054 codes. 72055 72056 This is v2 of this patch, which has these changes: 72057 72058 * I changed nfields to 'unsigned', per Simon's request. I looked at 72059 changing all the uses, but this quickly fans out into a very large 72060 patch. (One additional tweak was needed, though.) 72061 72062 * I wrote a test case. I discovered that GCC cannot compile a large 72063 enough C test case, so I resorted to using the DWARF assembler. 72064 This test doesn't reproduce the crash, but it does fail without the 72065 patch. 72066 72067 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29985 72068 720692023-02-09 Tom Tromey <tromey@adacore.com> 72070 72071 Remove mention of cooked_index_vector 72072 I noticed a leftover mention of cooked_index_vector. This updates the 72073 text. 72074 720752023-02-09 Tom Tromey <tromey@adacore.com> 72076 72077 Let user C-c when waiting for DWARF index finalization 72078 In PR gdb/29854, Simon pointed out that it would be good to be able to 72079 use C-c when the DWARF cooked index is waiting for finalization. The 72080 idea here is to be able to interrupt a command like "break" -- not to 72081 stop the finalization process itself, which runs in a worker thread. 72082 72083 This patch implements this idea, by changing the index wait functions 72084 to, by default, allow a quit. Polling is done, because there doesn't 72085 seem to be a better way to interrupt a wait on a std::future. 72086 72087 For v2, I realized that the thread compatibility code in thread-pool.h 72088 also needed an update. 72089 72090 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29854 72091 720922023-02-09 Alan Modra <amodra@gmail.com> 72093 72094 coff keep_relocs and keep_contents 72095 keep_relocs is set by pe_ILF_save_relocs but not used anywhere in the 72096 coff/pe code. It is tested by the xcoff backend but not set. 72097 72098 keep_contents is only used by the xcoff backend when dealing with 72099 the .loader section, and it's easy enough to dispense with it there. 72100 keep_contents is set in various places but that's fairly useless when 72101 the contents aren't freed anyway until later linker support functions, 72102 add_dynamic_symbols and check_dynamic_ar_symbols. There the contents 72103 were freed if keep_contents wasn't set. I reckon we can free them 72104 unconditionally. 72105 72106 * coff-bfd.h (struct coff_section_tdata): Delete keep_relocs 72107 and keep_contents. 72108 * peicode.h (pe_ILF_save_relocs): Don't set keep_relocs. 72109 * xcofflink.c (xcoff_get_section_contents): Cache contents. 72110 Return the contents. Update callers. 72111 (_bfd_xcoff_canonicalize_dynamic_symtab): Don't set 72112 keep_contents for .loader. 72113 (xcoff_link_add_dynamic_symbols): Free .loader contents 72114 unconditionally. 72115 (xcoff_link_check_dynamic_ar_symbols): Likewise. 72116 721172023-02-09 GDB Administrator <gdbadmin@sourceware.org> 72118 72119 Automatic date update in version.in 72120 721212023-02-08 Alan Modra <amodra@gmail.com> 72122 72123 coff-sh.c keep_relocs, keep_contents and keep_syms 72124 keep_relocs and keep_contents are unused nowadays except by 72125 xcofflink.c, and I can't see a reason why keep_syms needs to be set. 72126 The external syms are read and used by sh_relax_section and used by 72127 sh_relax_delete_bytes. There doesn't appear to be any way that 72128 freeing them will cause trouble. 72129 72130 * coff-sh.c (sh_relax_section): Don't set keep_relocs, 72131 keep_contents or keep_syms. 72132 (sh_relax_delete_bytes): Don't set keep_contents. 72133 721342023-02-08 Alan Modra <amodra@gmail.com> 72135 72136 Memory leak in bfd_init_section_compress_status 72137 * compress.c (bfd_init_section_compress_status): Free 72138 uncompressed_buffer on error return. 72139 721402023-02-08 Alan Modra <amodra@gmail.com> 72141 72142 Clear cached file size when bfd changed to BFD_IN_MEMORY 72143 If file size is calculated by bfd_get_file_size, as it is by 72144 _bfd_alloc_and_read calls in coff_object_p, then it is cached and when 72145 pe_ILF_build_a_bfd converts an archive entry over to BFD_IN_MEMORY, 72146 the file size is no longer valid. Found when attempting objdump -t on 72147 a very small (27 bytes) ILF file and hitting the pr24707 fix (commit 72148 781152ec18f5). So, clear file size when setting BFD_IN_MEMORY on bfds 72149 that may have been read. (It's not necessary in writable bfds, 72150 because caching is ignored by bfd_get_size when bfd_write_p.) 72151 72152 I also think the PR 24707 fix is no longer neeeded. All of the 72153 testcases in that PR and in PR24712 are caught earlier by file size 72154 checks when reading the symbols from file. So I'm reverting that fix, 72155 which just compared the size of an array of symbol pointers against 72156 file size. That's only valid if on-disk symbols are larger than a 72157 host pointer, so the test is better done in format-specific code. 72158 72159 bfd/ 72160 * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Clear cached 72161 file size when making a BFD_IN_MEMORY bfd. 72162 * opncls.c (bfd_make_readable): Likewise. 72163 * peicode.h (pe_ILF_build_a_bfd): Likewise. 72164 binutils/ 72165 PR 24707 72166 * objdump.c (slurp_symtab): Revert PR24707 fix. Tidy. 72167 (slurp_dynamic_symtab): Tidy. 72168 721692023-02-08 Alan Modra <amodra@gmail.com> 72170 72171 Internal error at gas/expr.c:1814 72172 This is the assertion 72173 know (*input_line_pointer != ' '); 72174 after calling operand. 72175 72176 The usual exit from operand calls SKIP_ALL_WHITESPACE. 72177 72178 * expr.c (operand): Call SKIP_ALL_WHITESPACE after call to expr. 72179 721802023-02-08 Simon Marchi <simon.marchi@efficios.com> 72181 72182 gdb: give sentinel for user frames distinct IDs, register sentinel frames to the frame cache 72183 The test gdb.base/frame-view.exp fails like this on AArch64: 72184 72185 frame^M 72186 #0 baz (z1=hahaha, /home/simark/src/binutils-gdb/gdb/value.c:4056: internal-error: value_fetch_lazy_register: Assertion `next_frame != NULL' failed.^M 72187 A problem internal to GDB has been detected,^M 72188 further debugging may prove unreliable.^M 72189 FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame (GDB internal error) 72190 72191 The sequence of events leading to this is the following: 72192 72193 - When we create the user frame (the "select-frame view" command), we 72194 create a sentinel frame just for our user-created frame, in 72195 create_new_frame. This sentinel frame has the same id as the regular 72196 sentinel frame. 72197 72198 - When printing the frame, after doing the "select-frame view" command, 72199 the argument's pretty printer is invoked, which does an inferior 72200 function call (this is the point of the test). This clears the frame 72201 cache, including the "real" sentinel frame, which sets the 72202 sentinel_frame global to nullptr. 72203 72204 - Later in the frame-printing process (when printing the second 72205 argument), the auto-reinflation mechanism re-creates the user frame 72206 by calling create_new_frame again, creating its own special sentinel 72207 frame again. However, note that the "real" sentinel frame, the 72208 sentinel_frame global, is still nullptr. If the selected frame had 72209 been a regular frame, we would have called get_current_frame at some 72210 point during the reinflation, which would have re-created the "real" 72211 sentinel frame. But it's not the case when reinflating a user frame. 72212 72213 - Deep down the stack, something wants to fill in the unwind stop 72214 reason for frame 0, which requires trying to unwind frame 1. This 72215 leads us to trying to unwind the PC of frame 1: 72216 72217 #0 gdbarch_unwind_pc (gdbarch=0xffff8d010080, next_frame=...) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:2955 72218 #1 0x000000000134569c in dwarf2_tailcall_sniffer_first (this_frame=..., tailcall_cachep=0xffff773fcae0, entry_cfa_sp_offsetp=0xfffff7f7d450) 72219 at /home/simark/src/binutils-gdb/gdb/dwarf2/frame-tailcall.c:390 72220 #2 0x0000000001355d84 in dwarf2_frame_cache (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1089 72221 #3 0x00000000013562b0 in dwarf2_frame_unwind_stop_reason (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1101 72222 #4 0x0000000001990f64 in get_prev_frame_always_1 (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2281 72223 #5 0x0000000001993034 in get_prev_frame_always (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2376 72224 #6 0x000000000199b814 in get_frame_unwind_stop_reason (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:3051 72225 #7 0x0000000001359cd8 in dwarf2_frame_cfa (this_frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1356 72226 #8 0x000000000132122c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d8883ee "\217\002", op_end=0xffff8d8883ee "\217\002") 72227 at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:2110 72228 #9 0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d8883ed "\234\217\002", len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239 72229 #10 0x000000000131d68c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d88840e "", op_end=0xffff8d88840e "") at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1811 72230 #11 0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239 72231 #12 0x0000000001314c3c in dwarf_expr_context::evaluate (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2, as_lval=true, per_cu=0xffff90b03700, frame=..., addr_info=0x0, 72232 type=0xffff8f6c8400, subobj_type=0xffff8f6c8400, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1078 72233 #13 0x000000000149f9e0 in dwarf2_evaluate_loc_desc_full (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980, 72234 subobj_type=0xffff8f6c8400, subobj_byte_offset=0, as_lval=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1513 72235 #14 0x00000000014a0100 in dwarf2_evaluate_loc_desc (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980, as_lval=true) 72236 at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1557 72237 #15 0x00000000014aa584 in locexpr_read_variable (symbol=0xffff8f6cd770, frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3052 72238 72239 - AArch64 defines a special "prev register" function, 72240 aarch64_dwarf2_prev_register, to handle unwinding the PC. This 72241 function does 72242 72243 frame_unwind_register_unsigned (this_frame, AARCH64_LR_REGNUM); 72244 72245 - frame_unwind_register_unsigned ultimately creates a lazy register 72246 value, saving the frame id of this_frame->next. this_frame is the 72247 user-created frame, to this_frame->next is the special sentinel frame 72248 we created for it. So the saved ID is the sentinel frame ID. 72249 72250 - When time comes to un-lazify the value, value_fetch_lazy_register 72251 calls frame_find_by_id, to find the frame with the ID we saved. 72252 72253 - frame_find_by_id sees it's the sentinel frame ID, so returns the 72254 sentinel_frame global, which is, if you remember, nullptr. 72255 72256 - We hit the `gdb_assert (next_frame != NULL)` assertion in 72257 value_fetch_lazy_register. 72258 72259 The issues I see here are: 72260 72261 - The ID of the sentinel frame created for the user-created frame is 72262 not distinguishable from the ID of the regular sentinel frame. So 72263 there's no way frame_find_by_id could find the right frame, in 72264 value_fetch_lazy_register. 72265 - Even if they had distinguishable IDs, sentinel frames created for 72266 user frames are not registered anywhere, so there's no easy way 72267 frame_find_by_id could find it. 72268 72269 This patch addresses these two issues: 72270 72271 - Give sentinel frames created for user frames their own distinct IDs 72272 - Register sentinel frames in the frame cache, so they can be found 72273 with frame_find_by_id. 72274 72275 I initially had this split in two patches, but I then found that it was 72276 easier to explain as a single patch. 72277 72278 Rergarding the first part of the change: with this patch, the sentinel 72279 frames created for user frames (in create_new_frame) still have 72280 stack_status == FID_STACK_SENTINEL, but their code_addr and stack_addr 72281 fields are now filled with the addresses used to create the user frame. 72282 This ensures this sentinel frame ID is different from the "target" 72283 sentinel frame ID, as well as any other "user" sentinel frame ID. If 72284 the user tries to create the same frame, with the same addresses, 72285 multiple times, create_sentinel_frame just reuses the existing frame. 72286 So we won't end up with multiple user sentinels with the same ID. 72287 72288 Regular "target" sentinel frames remain with code_addr and stack_addr 72289 unset. 72290 72291 The concrete changes for that part are: 72292 72293 - Remove the sentinel_frame_id constant, since there isn't one 72294 "sentinel frame ID" now. Add the frame_id_build_sentinel function 72295 for building sentinel frame IDs and a is_sentinel_frame_id function 72296 to check if a frame id represents a sentinel frame. 72297 - Replace the sentinel_frame_id check in frame_find_by_id with a 72298 comparison to `frame_id_build_sentinel (0, 0)`. The sentinel_frame 72299 global is meant to contain a reference to the "target" sentinel, so 72300 the one with addresses (0, 0). 72301 - Add stack and code address parameters to create_sentinel_frame, to be 72302 able to create the various types of sentinel frames. 72303 - Adjust get_current_frame to create the regular "target" sentinel. 72304 - Adjust create_new_frame to create a sentinel with the ID specific to 72305 the created user frame. 72306 - Adjust sentinel_frame_prev_register to get the sentinel frame ID from 72307 the frame_info object, since there isn't a single "sentinel frame ID" 72308 now. 72309 - Change get_next_frame_sentinel_okay to check for a 72310 sentinel-frame-id-like frame ID, rather than for sentinel_frame 72311 specifically, since this function could be called with another 72312 sentinel frame (and we would want the assert to catch it). 72313 72314 The rest of the change is about registering the sentinel frame in the 72315 frame cache: 72316 72317 - Change frame_stash_add's assertion to allow sentinel frame levels 72318 (-1). 72319 - Make create_sentinel_frame add the frame to the frame cache. 72320 - Change the "sentinel_frame != NULL" check in reinit_frame_cache for a 72321 check that the frame stash is not empty. The idea is that if we only 72322 have some user-created frames in the cache when reinit_frame_cache is 72323 called, we probably want to emit the frames invalid annotation. The 72324 goal of that check is to avoid unnecessary repeated annotations, I 72325 suppose, so the "frame cache not empty" check should achieve that. 72326 72327 After this change, I think we could theoritically get rid of the 72328 sentienl_frame global. That sentinel frame could always be found by 72329 looking up `frame_id_build_sentinel (0, 0)` in the frame cache. 72330 However, I left the global there to avoid slowing the typical case down 72331 for nothing. I however, noted in its comment that it is an 72332 optimization. 72333 72334 With this fix applied, the gdb.base/frame-view.exp now passes for me on 72335 AArch64. value_of_register_lazy now saves the special sentinel frame ID 72336 in the value, and value_fetch_lazy_register is able to find that 72337 sentinel frame after the frame cache reinit and after the user-created 72338 frame was reinflated. 72339 72340 Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> 72341 Tested-By: Luis Machado <luis.machado@arm.com> 72342 Change-Id: I8b77b3448822c8aab3e1c3dda76ec434eb62704f 72343 723442023-02-08 Simon Marchi <simon.marchi@efficios.com> 72345 72346 gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache 72347 Currently, some frame resources are deallocated by iterating on the 72348 frame chain (starting from the sentinel), calling dealloc_cache. The 72349 problem is that user-created frames are not part of that chain, so we 72350 never call dealloc_cache for them. 72351 72352 I propose to make it so the dealloc_cache callbacks are called when the 72353 frames are removed from the frame_stash hash table, by registering a 72354 deletion function to the hash table. This happens when 72355 frame_stash_invalidate is called by reinit_frame_cache. This way, all 72356 frames registered in the cache will get their unwinder's dealloc_cache 72357 callbacks called. 72358 72359 Note that at the moment, the sentinel frames are not registered in the 72360 cache, so we won't call dealloc_cache for them. However, it's just a 72361 theoritical problem, because the sentinel frame unwinder does not 72362 provide this callback. Also, a subsequent patch will change things so 72363 that sentinel frames are registered to the cache. 72364 72365 I moved the obstack_free / obstack_init pair below the 72366 frame_stash_invalidate call in reinit_frame_cache, because I assumed 72367 that some dealloc_cache would need to access some data on that obstack, 72368 so it would be better to free it after clearing the hash table. 72369 72370 Change-Id: If4f9b38266b458c4e2f7eb43e933090177c22190 72371 723722023-02-08 Tom Tromey <tom@tromey.com> 72373 72374 Remove block.h includes from some tdep files 72375 A few tdep files include block.h but do not need to. This patch 72376 removes the inclusions. I checked that this worked correctly by 72377 examining the resulting .Po file to make sure that block.h was not 72378 being included by some other route. 72379 72380 Don't include block.h from expop.h 72381 expop.h needs block.h for a single inline function. However, I don't 72382 think most of the check_objfile functions need to be defined in the 72383 header (just the templates). This patch moves the one offending 72384 function and removes the include. 72385 723862023-02-08 Pedro Alves <pedro@palves.net> 72387 72388 Simplify interp::exec / interp_exec - let exceptions propagate 72389 This patch implements a simplication that I suggested here: 72390 72391 https://sourceware.org/pipermail/gdb-patches/2022-March/186320.html 72392 72393 Currently, the interp::exec virtual method interface is such that 72394 subclass implementations must catch exceptions and then return them 72395 via normal function return. 72396 72397 However, higher up the in chain, for the CLI we get to 72398 interpreter_exec_cmd, which does: 72399 72400 for (i = 1; i < nrules; i++) 72401 { 72402 struct gdb_exception e = interp_exec (interp_to_use, prules[i]); 72403 72404 if (e.reason < 0) 72405 { 72406 interp_set (old_interp, 0); 72407 error (_("error in command: \"%s\"."), prules[i]); 72408 } 72409 } 72410 72411 and for MI we get to mi_cmd_interpreter_exec, which has: 72412 72413 void 72414 mi_cmd_interpreter_exec (const char *command, char **argv, int argc) 72415 { 72416 ... 72417 for (i = 1; i < argc; i++) 72418 { 72419 struct gdb_exception e = interp_exec (interp_to_use, argv[i]); 72420 72421 if (e.reason < 0) 72422 error ("%s", e.what ()); 72423 } 72424 } 72425 72426 Note that if those errors are reached, we lose the original 72427 exception's error code. I can't see why we'd want that. 72428 72429 And, I can't see why we need to have interp_exec catch the exception 72430 and return it via the normal return path. That's normally needed when 72431 we need to handle propagating exceptions across C code, like across 72432 readline or ncurses, but that's not the case here. 72433 72434 It seems to me that we can simplify things by removing some 72435 try/catch-ing and just letting exceptions propagate normally. 72436 72437 Note, the "error in command" error shown above, which only exists in 72438 the CLI interpreter-exec command, is only ever printed AFAICS if you 72439 run "interpreter-exec console" when the top level interpreter is 72440 already the console/tui. Like: 72441 72442 (gdb) interpreter-exec console "foobar" 72443 Undefined command: "foobar". Try "help". 72444 error in command: "foobar". 72445 72446 You won't see it with MI's "-interpreter-exec console" from a top 72447 level MI interpreter: 72448 72449 (gdb) 72450 -interpreter-exec console "foobar" 72451 &"Undefined command: \"foobar\". Try \"help\".\n" 72452 ^error,msg="Undefined command: \"foobar\". Try \"help\"." 72453 (gdb) 72454 72455 nor with MI's "-interpreter-exec mi" from a top level MI interpreter: 72456 72457 (gdb) 72458 -interpreter-exec mi "-foobar" 72459 ^error,msg="Undefined MI command: foobar",code="undefined-command" 72460 ^done 72461 (gdb) 72462 72463 in both these cases because MI's -interpreter-exec just does: 72464 72465 error ("%s", e.what ()); 72466 72467 You won't see it either when running an MI command with the CLI's 72468 "interpreter-exec mi": 72469 72470 (gdb) interpreter-exec mi "-foobar" 72471 ^error,msg="Undefined MI command: foobar",code="undefined-command" 72472 (gdb) 72473 72474 This last case is because MI's interp::exec implementation never 72475 returns an error: 72476 72477 gdb_exception 72478 mi_interp::exec (const char *command) 72479 { 72480 mi_execute_command_wrapper (command); 72481 return gdb_exception (); 72482 } 72483 72484 Thus I think that "error in command" error is pretty pointless, and 72485 since it simplifies things to not have it, the patch just removes it. 72486 72487 The patch also ends up addressing an old FIXME. 72488 72489 Change-Id: I5a6432a80496934ac7127594c53bf5221622e393 72490 Approved-By: Tom Tromey <tromey@adacore.com> 72491 Approved-By: Kevin Buettner <kevinb@redhat.com> 72492 724932023-02-08 Tom Tromey <tromey@adacore.com> 72494 72495 Avoid FAILs in gdb.compile 72496 Many gdb.compile C++ tests fail for me on Fedora 36. I think these 72497 are largely bugs in the plugin, though I didn't investigate too 72498 deeply. Once one failure is seen, this often cascades and sometimes 72499 there are many timeouts. 72500 72501 For example, this can happen: 72502 72503 (gdb) compile code var = a->get_var () 72504 warning: Could not find symbol "_ZZ9_gdb_exprP10__gdb_regsE1a" for compiled module "/tmp/gdbobj-0xdI6U/out2.o". 72505 1 symbols were missing, cannot continue. 72506 72507 I think this is probably a plugin bug because, IIRC, in theory these 72508 symbols should be exempt from a lookup via gdb. 72509 72510 This patch arranges to catch any catastrophic failure and then simply 72511 exit the entire .exp file. 72512 725132023-02-08 Tom Tromey <tromey@adacore.com> 72514 72515 Don't let .gdb_history file cause failures 72516 I had a .gdb_history file in my testsuite directory in the build tree, 72517 and this provoked a failure in gdbhistsize-history.exp. It seems 72518 simple to prevent this file from causing a failure. 72519 725202023-02-08 Tom Tromey <tromey@adacore.com> 72521 72522 Merge fixup_section and fixup_symbol_section 72523 fixup_symbol_section delegates all its work to fixup_section, so merge 72524 the two. 72525 72526 Because there is only a single caller to fixup_symbol_section, we can 72527 also remove some of the introductory logic. For example, this will 72528 never be called with a NULL objfile any more. 72529 72530 The LOC_BLOCK case can be removed, because such symbols are handled by 72531 the buildsym code now. 72532 72533 Finally, a symbol can only appear in a SEC_ALLOC section, so the loop 72534 is modified to skip sections that do not have this flag set. 72535 725362023-02-08 Tom Tromey <tromey@adacore.com> 72537 72538 Remove most calls to fixup_symbol_section 72539 Nearly every call to fixup_symbol_section in gdb is incorrect, and if 72540 any such call has an effect, it's purely by happenstance. 72541 72542 fixup_section has a long comment explaining that the call should only 72543 be made before runtime section offsets are applied. And, the loop in 72544 this code (the fallback loop -- the minsym lookup code is "ok") is 72545 careful to remove these offsets before comparing addresses. 72546 72547 However, aside from a single call in dwarf2/read.c, every call in gdb 72548 is actually done after section offsets have been applied. So, these 72549 calls are incorrect. 72550 72551 Now, these calls could be made when the symbol is created. I 72552 considered this approach, but I reasoned that the code has been this 72553 way for many years, seemingly without ill effect. So, instead I chose 72554 to simply remove the offending calls. 72555 725562023-02-08 Tom Tromey <tromey@adacore.com> 72557 72558 Set section index when setting a symbol's block 72559 When a symbol's block is set, the block has the runtime section offset 72560 applied. So, it seems to me that the symbol implicitly is in the same 72561 section as the block. Therefore, this patch sets the symbol's section 72562 index at this same spot. 72563 72564 Remove compunit_symtab::m_block_line_section 72565 The previous patch hard-coded SECT_OFF_TEXT into the buildsym code. 72566 After this, it's clear that there is only one caller of 72567 compunit_symtab::set_block_line_section, and it always passes 72568 SECT_OFF_TEXT. So, remove compunit_symtab::m_block_line_section and 72569 use SECT_OFF_TEXT instead. 72570 72571 Do not pass section index to end_compunit_symtab 72572 Right now, the section index passed to end_compunit_symtab is always 72573 SECT_OFF_TEXT. Remove this parameter and simply always use 72574 SECT_OFF_TEXT. 72575 725762023-02-08 Tom Tromey <tromey@adacore.com> 72577 72578 Set section indices when symbols are made 72579 Most places in gdb that create a new symbol will apply a section 72580 offset to the address. It seems to me that the choice of offset here 72581 is also an implicit choice of the section. This is particularly true 72582 if you examine fixup_section, which notes that it must be called 72583 before such offsets are applied -- meaning that if any such call has 72584 an effect, it's purely by accident. 72585 72586 This patch cleans up this area by tracking the section index and 72587 applying it to a symbol when the address is set. This is done for 72588 nearly every case -- the remaining cases will be handled in later 72589 patches. 72590 725912023-02-08 Tom Tromey <tromey@adacore.com> 72592 72593 Use default section indexes in fixup_symbol_section 72594 If fixup_section does not find a matching section, it arbitrarily 72595 chooses the first one. However, it seems better to make this default 72596 depend on the type of the symbol -- i.e., default data symbols to 72597 .data and text symbols to .text. 72598 72599 I've also made fixup_section static, as it only has one caller. 72600 726012023-02-08 Tom Tromey <tom@tromey.com> 72602 72603 Simplify checks of cooked_index 72604 This changes the cooked_index_functions to avoid an extra null check 72605 now that checked_static_cast allows a null argument. 72606 72607 Approved-By: Simon Marchi <simon.marchi@efficios.com> 72608 726092023-02-08 Tom de Vries <tdevries@suse.de> 72610 72611 [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp 72612 Test-case gdb.base/longjmp.exp handles both the case that there is a libc 72613 longjmp probe, and the case that there isn't. 72614 72615 However, it only tests one of the two cases. 72616 72617 Use maint ignore-probes to test both cases, if possible. 72618 72619 Tested on x86_64-linux. 72620 726212023-02-08 Tom de Vries <tdevries@suse.de> 72622 72623 [gdb/testsuite] Use maint ignore-probes in gdb.base/solib-corrupted.exp 72624 Test-case gdb.base/solib-corrupted.exp only works for a glibc without probes 72625 interface, otherwise we run into: 72626 ... 72627 XFAIL: gdb.base/solib-corrupted.exp: info probes 72628 UNTESTED: gdb.base/solib-corrupted.exp: GDB is using probes 72629 ... 72630 72631 Fix this by using maint ignore-probes to simulate the absence of the relevant 72632 probes. 72633 72634 Also, it requires glibc debuginfo, and if not present, it produces an XFAIL: 72635 ... 72636 XFAIL: gdb.base/solib-corrupted.exp: make solibs looping 72637 UNTESTED: gdb.base/solib-corrupted.exp: no _r_debug symbol has been found 72638 ... 72639 This is incorrect, because an XFAIL indicates a known problem in the 72640 environment. In this case, there is no problem: the environment is 72641 functioning as expected when glibc debuginfo is not installed. 72642 72643 Fix this by using UNSUPPORTED instead, and make the message less cryptic: 72644 ... 72645 UNSUPPORTED: gdb.base/solib-corrupted.exp: make solibs looping \ 72646 (glibc debuginfo required) 72647 ... 72648 72649 Finally, with glibc debuginfo present, we run into: 72650 ... 72651 (gdb) PASS: gdb.base/solib-corrupted.exp: make solibs looping 72652 info sharedlibrary^M 72653 warning: Corrupted shared library list: 0x7ffff7ffe750 != 0x0^M 72654 From To Syms Read Shared Object Library^M 72655 0x00007ffff7dd4170 0x00007ffff7df4090 Yes /lib64/ld-linux-x86-64.so.2^M 72656 (gdb) FAIL: gdb.base/solib-corrupted.exp: corrupted list \ 72657 (shared library list corrupted) 72658 ... 72659 due to commit 44288716537 ("gdb, testsuite: extend gdb_test_multiple checks"). 72660 72661 Fix this by rewriting into gdb_test_multiple and using -early. 72662 72663 Tested on x86_64-linux, with and without glibc debuginfo installed. 72664 726652023-02-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 72666 72667 gprofng: fix SIGSEGV when processing unusual dwarf 72668 gprofng/ChangeLog 72669 2023-02-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 72670 72671 PR gprofng/30093 72672 * src/Dwarf.cc: add nullptr check. 72673 * src/DwarfLib.cc: Likewise. 72674 726752023-02-08 Alan Modra <amodra@gmail.com> 72676 72677 Re: Resetting section vma after _bfd_dwarf2_find_nearest_line 72678 f.bfd_ptr is set too early to be a reliable indicator of good debug 72679 info. 72680 72681 * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Correct test for 72682 debug info being previously found. 72683 726842023-02-08 GDB Administrator <gdbadmin@sourceware.org> 72685 72686 Automatic date update in version.in 72687 726882023-02-07 Andrew Burgess <aburgess@redhat.com> 72689 72690 gdb: fix display of thread condition for multi-location breakpoints 72691 This commit addresses the issue in PR gdb/30087. 72692 72693 If a breakpoint with multiple locations has a thread condition, then 72694 the 'info breakpoints' output is a little messed up, here's an example 72695 of the current output: 72696 72697 (gdb) break foo thread 1 72698 Breakpoint 2 at 0x401114: foo. (3 locations) 72699 (gdb) break bar thread 1 72700 Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32. 72701 (gdb) info breakpoints 72702 Num Type Disp Enb Address What 72703 2 breakpoint keep y <MULTIPLE> thread 1 72704 stop only in thread 1 72705 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72706 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72707 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72708 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1 72709 stop only in thread 1 72710 72711 Notice that, at the end of the location for breakpoint 3, the 'thread 72712 1' condition is printed, but this is then repeated on the next line 72713 with 'stop only in thread 1'. 72714 72715 In contrast, for breakpoint 2, the 'thread 1' appears randomly, in the 72716 "What" column, though slightly offset, non of the separate locations 72717 have the 'thread 1' information. Additionally for breakpoint 2 we 72718 also get a 'stop only in thread 1' line. 72719 72720 There's two things going on here. First the randomly placed 'thread 72721 1' for breakpoint 2 is due to a bug in print_one_breakpoint_location, 72722 where we check the variable part_of_multiple instead of 72723 header_of_multiple. 72724 72725 If I fix this oversight, then the output is now: 72726 72727 (gdb) break foo thread 1 72728 Breakpoint 2 at 0x401114: foo. (3 locations) 72729 (gdb) break bar thread 1 72730 Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32. 72731 (gdb) info breakpoints 72732 Num Type Disp Enb Address What 72733 2 breakpoint keep y <MULTIPLE> 72734 stop only in thread 1 72735 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1 72736 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1 72737 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1 72738 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1 72739 stop only in thread 1 72740 72741 The 'thread 1' condition is now displayed at the end of each location, 72742 which makes the output the same for single location breakpoints and 72743 multi-location breakpoints. 72744 72745 However, there's still some duplication here. Both breakpoints 2 and 72746 3 include a 'stop only in thread 1' line, and it feels like the 72747 additional 'thread 1' is redundant. In fact, there's a comment to 72748 this very effect in the code: 72749 72750 /* FIXME: This seems to be redundant and lost here; see the 72751 "stop only in" line a little further down. */ 72752 72753 So, lets fix this FIXME. The new plan is to remove all the trailing 72754 'thread 1' markers from the CLI output, we now get this: 72755 72756 (gdb) break foo thread 1 72757 Breakpoint 2 at 0x401114: foo. (3 locations) 72758 (gdb) break bar thread 1 72759 Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32. 72760 (gdb) info breakpoints 72761 Num Type Disp Enb Address What 72762 2 breakpoint keep y <MULTIPLE> 72763 stop only in thread 1 72764 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72765 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72766 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 72767 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 72768 stop only in thread 1 72769 72770 All of the above points are also true for the Ada 'task' breakpoint 72771 condition, and the changes I've made also update how the task 72772 information is printed, though in the case of the Ada task there was 72773 no 'stop only in task XXX' line printed, so I've added one of those. 72774 72775 Obviously it can't be quite that easy. For MI backwards compatibility 72776 I've retained the existing code (but now only for MI like outputs), 72777 which ensures we should generate backwards compatible output. 72778 72779 I've extended an Ada test to cover the new task related output, and 72780 updated all the tests I could find that checked for the old output. 72781 72782 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30087 72783 72784 Approved-By: Pedro Alves <pedro@palves.net> 72785 727862023-02-07 Nick Clifton <nickc@redhat.com> 72787 72788 Fix documentation of the 'n' symbol type displayed by nm. 72789 PR 30080 * doc/binutils.texi (nm): Update description of the 'n' symbol type. 72790 727912023-02-07 Tom de Vries <tdevries@suse.de> 72792 72793 [gdb/testsuite] Improve untested message in gdb.ada/finish-var-size.exp 72794 I came across: 72795 ... 72796 UNTESTED: gdb.ada/finish-var-size.exp: GCC too told for this test 72797 ... 72798 The message only tells us that the compiler version too old, not what compiler 72799 version is required. 72800 72801 Fix this by rewriting using required: 72802 ... 72803 UNSUPPORTED: gdb.ada/finish-var-size.exp: require failed: \ 72804 expr [gcc_major_version] >= 12 72805 ... 72806 72807 Tested on x86_64-linux. 72808 728092023-02-07 GDB Administrator <gdbadmin@sourceware.org> 72810 72811 Automatic date update in version.in 72812 728132023-02-06 Simon Marchi <simon.marchi@polymtl.ca> 72814 72815 gdb: adjust comment on target_desc_info::from_user_p 72816 Remove the stale reference to INFO, which is now "this target 72817 description info" now. 72818 72819 Change-Id: I35dbdb089048ed7cfffe730d3134ee391b176abf 72820 728212023-02-06 Andrew Burgess <aburgess@redhat.com> 72822 72823 gdb/doc: extend the documentation for the 'handle' command 72824 The documentation for the 'handle' command does not cover all of the 72825 features of the command, and in one case, is just wrong. 72826 72827 The user can specify 'all' as signal name, the documentation implies 72828 that this will change the behaviour of all signals, in reality, this 72829 changes all signals except SIGINT and SIGTRAP (the signals used by 72830 GDB). I've updated the docs to list this limitation. 72831 72832 The 'handle' command also allows the user to specify multiple signals 72833 for a single command, e.g. 'handle SIGFPE SIGILL nostop pass print', 72834 however the documentation doesn't describe this, so I've updated the 72835 docs to describe this feature. 72836 728372023-02-06 Alan Modra <amodra@gmail.com> 72838 72839 ppc32 and "LOAD segment with RWX permissions" 72840 When using a bss-plt we'll always trigger the RWX warning, which 72841 disturbs gcc test results. On the other hand, there may be reason to 72842 want the warning when gcc is configured with --enable-secureplt. 72843 So turning off the warning entirely for powerpc might not be the best 72844 solution. Instead, we'll turn off the warning whenever a bss-plt is 72845 generated, unless the user explicitly asked for the warning. 72846 72847 bfd/ 72848 * elf32-ppc.c (ppc_elf_select_plt_layout): Set 72849 no_warn_rwx_segments on generating a bss plt, unless explicity 72850 enabled by the user. Also show the bss-plt warning when 72851 --warn-rwx-segments is given without --bss-plt. 72852 include/ 72853 * bfdlink.h (struct bfd_link_info): Add user_warn_rwx_segments. 72854 ld/ 72855 * lexsup.c (parse_args): Set user_warn_rwx_segments. 72856 * testsuite/ld-elf/elf.exp: Pass --secure-plt for powerpc to 72857 the rwx tests. 72858 728592023-02-06 Tom de Vries <tdevries@suse.de> 72860 72861 [gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu 72862 Occasionally, I run into: 72863 ... 72864 (gdb) PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \ 72865 set scheduler-locking on 72866 continue^M 72867 Continuing.^M 72868 PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \ 72869 continue (with lock) 72870 [Thread 0x7ffff746e700 (LWP 1339) exited]^M 72871 No unwaited-for children left.^M 72872 (gdb) Quit^M 72873 (gdb) FAIL: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \ 72874 stop all threads (with lock) (timeout) 72875 ... 72876 72877 What happens is that this loop which is supposed to run "just short of forever": 72878 ... 72879 /* Don't run forever. Run just short of it :) */ 72880 while (*myp > 0) 72881 { 72882 /* schedlock.exp: main loop. */ 72883 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++; 72884 } 72885 ... 72886 finishes after 0x7fffffff iterations (when a signed wrap occurs), which on my 72887 system takes only about 1.5 seconds. 72888 72889 Fix this by: 72890 - changing the pointed-at type of myp from signed to unsigned, which makes the 72891 wrap defined behaviour (and which also make the loop run twice as long, 72892 which is already enough to make it impossible for me to reproduce the FAIL. 72893 But let's try to solve this more structurally). 72894 - changing the pointed-at type of myp from int to long long, making the wrap 72895 unlikely. 72896 - making sure the loop runs forever, by setting the loop condition to 1. 72897 - making sure the loop still contains different lines (as far as debug info is 72898 concerned) by incrementing a volatile counter in the loop. 72899 - making sure the program doesn't run forever in case of trouble, by adding an 72900 "alarm (30)". 72901 72902 Tested on x86_64-linux. 72903 72904 PR testsuite/30074 72905 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30074 72906 729072023-02-06 Andrew Burgess <aburgess@redhat.com> 72908 72909 gdb: error if 'thread' or 'task' keywords are overused 72910 When creating a breakpoint or watchpoint, the 'thread' and 'task' 72911 keywords can be used to create a thread or task specific breakpoint or 72912 watchpoint. 72913 72914 Currently, a thread or task specific breakpoint can only apply for a 72915 single thread or task, if multiple threads or tasks are specified when 72916 creating the breakpoint (or watchpoint), then the last specified id 72917 will be used. 72918 72919 The exception to the above is that when the 'thread' keyword is used 72920 during the creation of a watchpoint, GDB will give an error if 72921 'thread' is given more than once. 72922 72923 In this commit I propose making this behaviour consistent, if the 72924 'thread' or 'task' keywords are used more than once when creating 72925 either a breakpoint or watchpoint, then GDB will give an error. 72926 72927 I haven't updated the manual, we don't explicitly say that these 72928 keywords can be repeated, and (to me), given the keyword takes a 72929 single id, I don't think it makes much sense to repeat the keyword. 72930 As such, I see this more as adding a missing error to GDB, rather than 72931 making some big change. However, I have added an entry to the NEWS 72932 file as I guess it is possible that some people might hit this new 72933 error with an existing (I claim, badly written) GDB script. 72934 72935 I've added some new tests to check for the new error. 72936 72937 Just one test needed updating, gdb.linespec/keywords.exp, this test 72938 did use the 'thread' keyword twice, and expected the breakpoint to be 72939 created. Looking at what this test was for though, it was checking 72940 the use of '-force-condition', and I don't think that being able to 72941 repeat 'thread' was actually a critical part of this test. 72942 72943 As such, I've updated this test to expect the error when 'thread' is 72944 repeated. 72945 729462023-02-06 Alan Modra <amodra@gmail.com> 72947 72948 Resetting section vma after _bfd_dwarf2_find_nearest_line 72949 There are failure paths in _bfd_dwarf2_slurp_debug_info that can 72950 result in altered section vmas. Also, when setting ET_REL section 72951 vmas it's not too difficult to handle cases where the original vma was 72952 non-zero, so do that too. 72953 72954 This patch was really in response to an addr2line buffer overflow 72955 processing a fuzzed mips relocatable object file. The file had a 72956 number of .debug_info sections with relocations that included lo16 and 72957 hi16 relocs, and in that order. At least one section VMA was 72958 non-zero. This resulted in processing of DWARF info twice, once via 72959 the call to _bfd_dwarf2_find_nearest_line in 72960 _bfd_mips_elf_find_nearest_line, and because that failed leaving VMAs 72961 altered, the second via the call in _bfd_elf_find_nearest_line. The 72962 first call left entries on mips_hi16_list pointing at buffers 72963 allocated during the first call, the second call processed the 72964 mips_hi16_list after the buffers had been freed. (At least when 72965 running with asan and under valgrind. Under gdb with a non-asan 72966 addr2line the second call allocated exactly the same buffer and the 72967 bug didn't show.) Now I don't really care too much what happens with 72968 fuzzed files, but the logic in _bfd_dwarf2_find_nearest_line is meant 72969 to result in only one read of .debug_info, not multiple reads of the 72970 same info when there are errors. This patch fixes that problem. 72971 72972 * dwarf2.c (struct adjusted_section): Add orig_vma. 72973 (unset_sections): Reset vma to it. 72974 (place_sections): Handle non-zero vma too. Save orig_vma. 72975 (_bfd_dwarf2_slurp_debug_info): Tidy. Correct outdated comment. 72976 On error returns after calling place_sections, call 72977 unset_sections. 72978 (_bfd_dwarf2_find_nearest_line_with_alt): Simplify call to 72979 unset_sections. 72980 729812023-02-06 Romain Geissler <romain.geissler@amadeus.com> 72982 72983 [PR 30082] Pass $JANSSON_LIBS and $ZSTD_LIBS to ld-bootstrap/bootrap.exp 72984 729852023-02-06 GDB Administrator <gdbadmin@sourceware.org> 72986 72987 Automatic date update in version.in 72988 729892023-02-05 GDB Administrator <gdbadmin@sourceware.org> 72990 72991 Automatic date update in version.in 72992 729932023-02-04 Andrew Burgess <aburgess@redhat.com> 72994 72995 gdb/testsuite: don't try to set non-stop mode on a running target 72996 The test gdb.threads/thread-specific-bp.exp tries to set non-stop mode 72997 on a running target, something which the manual makes clear is not 72998 allowed. 72999 73000 This commit restructures the test a little, we now set the non-stop 73001 mode as part of the GDBFLAGS, so the mode will be set before GDB 73002 connects to the target. As a consequence I'm able to move the 73003 with_test_prefix out of the check_thread_specific_breakpoint proc. 73004 The check_thread_specific_breakpoint proc is now called within a loop. 73005 73006 After this commit the gdb.threads/thread-specific-bp.exp test still 73007 has some failures, this is because of an issue GDB currently has 73008 printing "Thread ... exited" messages. This problem should be 73009 addressed by this patch: 73010 73011 https://sourceware.org/pipermail/gdb-patches/2022-December/194694.html 73012 73013 when it is merged. 73014 730152023-02-04 Dimitar Dimitrov <dimitar@dinux.eu> 73016 73017 ld: pru: Add optional section alignments 73018 The Texas Instruments SoCs with AARCH64 host processors have stricter 73019 alignment requirements than ones with ARM32 host processors. It's not 73020 only the requirement for resource_table to be aligned to 8. But also 73021 any loadable segment size must be a multiple of 4 [1]. 73022 73023 The current PRU default linker script may output a segment size not 73024 aligned to 4, which would cause firmware load failure on AARCH64 hosts. 73025 73026 Fix this by using COMMONPAGESIZE and MAXPAGESIZE to signify respectively 73027 the section memory size requirement and the resource table section's 73028 start address alignment. This would avoid penalizing the ARM32 hosts, 73029 for which the default values (1 and 1) are sufficient. 73030 73031 For AARCH64 hosts, the alignments would be overwritten from GCC spec 73032 files using the linker command line, e.g.: 73033 -z common-page-size=4 -z max-page-size=8 73034 73035 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n555 73036 73037 ld/ChangeLog: 73038 73039 * scripttempl/pru.sc (_data_end): Remove the alignment. 73040 (.data): Align output section size to COMMONPAGESIZE. 73041 (.resource_table): Ditto. 73042 730432023-02-04 Dimitar Dimitrov <dimitar@dinux.eu> 73044 73045 ld: pru: Merge the bss input sections into data 73046 The popular method to load PRU firmware is through the remoteproc Linux 73047 kernel driver. In order to save a few bytes from the firmware, the PRU 73048 CRT0 is spared from calling memset for the bss segment [1]. Instead the 73049 host loader is supposed to zero out the bss segment. This is important 73050 for PRU, which typically has only 8KB for instruction memory. 73051 73052 The legacy non-mainline PRU host driver relied on the default 73053 behaviour of the kernel core remoteproc [2]. That default is to zero 73054 out the loadable memory regions not backed by file storage (i.e. the 73055 bss sections). This worked for the libgloss' CRT0. 73056 73057 But the PRU loader merged in mainline Linux explicitly changes the 73058 default behaviour [3]. It no longer is zeroing out memory regions. 73059 Hence the bss sections are not initialized - neither by CRT0, nor by the 73060 host loader. 73061 73062 This patch fixes the issue by aligning the GNU LD default linker script 73063 with the mainline Linux kernel expectation. Since the mainline kernel 73064 driver is submitted by the PRU manufacturer itself (Text Instruments), 73065 we can consider that as defining the ABI. 73066 73067 This change has been tested on Beaglebone AI-64 [4]. Static counter 73068 variables in the firmware are now always starting from zero, as 73069 expected. There was only one new toolchain test failure in orphan3.d, 73070 due to reordering of the output sections. I believe this is a harmless 73071 issue. I could not rewrite the PASS criteria to ignore the output 73072 section ordering, so I have disabled that test case for PRU. 73073 73074 [1] https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=libgloss/pru/crt0.S;h=b3f0d53a93acc372f461007553e7688ca77753c9;hb=HEAD#l40 73075 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/remoteproc_elf_loader.c?h=v6.1#n228 73076 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n641 73077 [4] https://beagleboard.org/ai-64 73078 73079 ld/ChangeLog: 73080 73081 * scripttempl/pru.sc (.data): Merge .bss input sections into the 73082 .data output section. 73083 * testsuite/ld-elf/orphan3.d: Disable for PRU. 73084 730852023-02-04 GDB Administrator <gdbadmin@sourceware.org> 73086 73087 Automatic date update in version.in 73088 730892023-02-03 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 73090 73091 bpf: fix error conversion from long unsigned int to unsigned int [-Werror=overflow] 73092 Regenerating BPF target using the maintainer mode emits: 73093 .../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow] 73094 57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } } 73095 73096 The use of a narrow size to handle the mask CGEN in instruction format 73097 is causing this error. Additionally eBPF `call' instructions 73098 constructed by expressions using symbols (BPF_PSEUDO_CALL) emits 73099 annotations in `src' field of the instruction, used to identify BPF 73100 target endianness. 73101 73102 cpu/ 73103 * bpf.cpu (define-call-insn): Remove `src' field from 73104 instruction mask. 73105 73106 include/ 73107 *opcode/cge.h (CGEN_IFMT): Adjust mask bit width. 73108 73109 opcodes/ 73110 * bpf-opc.c: Regenerate. 73111 731122023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73113 73114 gdb: make target_desc_info_from_user_p a method of target_desc_info 73115 Move the implementation over to target_desc_info. Remove the 73116 target_desc_info forward declaration in target-descriptions.h, it's no 73117 longer needed. 73118 73119 Change-Id: Ic95060341685afe0b73af591ca6efe32f5e7e892 73120 731212023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73122 73123 gdb: remove copy_inferior_target_desc_info 73124 This function is now trivial, we can just copy inferior::tdesc_info 73125 where needed. 73126 73127 Change-Id: I25185e2cd4ba1ef24a822d9e0eebec6e611d54d6 73128 731292023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73130 73131 gdb: remove get_tdesc_info 73132 Remove this function, since it's now a trivial access to 73133 inferior::tdesc_info. 73134 73135 Change-Id: I3e88a8214034f1a4163420b434be11f51eef462c 73136 731372023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73138 73139 gdb: change inferior::tdesc_info to non-pointer 73140 I initially made this field a unique pointer, to have automatic memory 73141 management. But I then thought that the field didn't really need to be 73142 allocated separately from struct inferior. So make it a regular 73143 non-pointer field of inferior. 73144 73145 Remove target_desc_info_free, as it's no longer needed. 73146 73147 Change-Id: Ica2b97071226f31c40e86222a2f6922454df1229 73148 731492023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73150 73151 gdb: move target_desc_info to inferior.h 73152 In preparation for the following patch, where struct inferior needs to 73153 "see" struct target_desc_info, move target_desc_info to the header file. 73154 73155 I initially moved the structure to target-descriptions.h, and later made 73156 inferior.h include target-descriptions.h. This worked, but it then 73157 occured to me that target_desc_info is really an inferior property that 73158 involves a target description, so I think it makes sense to have it in 73159 inferior.h. 73160 73161 Change-Id: I3e81d04faafcad431e294357389f3d4c601ee83d 73162 731632023-02-03 Simon Marchi <simon.marchi@polymtl.ca> 73164 73165 gdb: use assignment to initialize variable in tdesc_parse_xml 73166 Since allocate_target_description returns a target_desc_up, use 73167 assignment to initialize the description variable. 73168 73169 Change-Id: Iab3311642c09b95648984f305936f4a4cde09440 73170 731712023-02-03 Jan Beulich <jbeulich@suse.com> 73172 73173 x86: drop LOCK from XCHG when optimizing 73174 Like with segment overrides on LEA, optimize away such a redundant 73175 instruction prefix. 73176 73177 x86-64: respect {nooptimize} when building VEX prefix 73178 Swapping operands for commutative insns occurs outside of 73179 optimize_encoding() and hence needs explicit checking for a request to 73180 avoid any optimizations. 73181 73182 x86: respect {nooptimize} for LEA 73183 Dropping a meaningless segment prefix occurs outside of 73184 optimize_encoding() and hence needs explicit checking for a request to 73185 avoid any optimizations. 73186 73187 x86-64: respect MOVABS when choosing alternative encodings 73188 The alternative encoding is valid for MOV, but there's no such thing for 73189 MOVABS. 73190 73191 RISC-V: don't disassemble unrecognized insns as .byte 73192 Insn width granularity being 16 bits, producing byte granular output 73193 isn't very useful. With there being a way to specific otherwise 73194 unknown insns to the assembler, use that same representation (to be 73195 precise: its <length>,<encoding> flavor) for disassembly. 73196 731972023-02-03 Alan Modra <amodra@gmail.com> 73198 73199 Add ECOFF Symbolic Header sanity checks 73200 Anti-fuzzer measures. The checks don't ensure the various elements in 73201 the header are distinct, but that isn't important as far as making 73202 sure we don't overrun the buffer containing all the elements. Also, 73203 we now don't care about offsets where the corresponding count is zero. 73204 73205 * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Sanity check offsets 73206 in debug->symbolic_header. 73207 732082023-02-03 GDB Administrator <gdbadmin@sourceware.org> 73209 73210 Automatic date update in version.in 73211 732122023-02-02 Simon Marchi <simon.marchi@polymtl.ca> 73213 73214 gdb: initial support for ROCm platform (AMDGPU) debugging 73215 This patch adds the foundation for GDB to be able to debug programs 73216 offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest 73217 public release of the ROCm release at the time of writing is 5.4, so 73218 this is what this patch targets. 73219 73220 The ROCm platform allows host programs to schedule bits of code for 73221 execution on GPUs or similar accelerators. The programs running on GPUs 73222 are typically referred to as `kernels` (not related to operating system 73223 kernels). 73224 73225 Programs offloaded with the AMD ROCm platform can be written in the HIP 73226 language [2], OpenCL and OpenMP, but we're going to focus on HIP here. 73227 The HIP language consists of a C++ Runtime API and kernel language. 73228 Here's an example of a very simple HIP program: 73229 73230 #include "hip/hip_runtime.h" 73231 #include <cassert> 73232 73233 __global__ void 73234 do_an_addition (int a, int b, int *out) 73235 { 73236 *out = a + b; 73237 } 73238 73239 int 73240 main () 73241 { 73242 int *result_ptr, result; 73243 73244 /* Allocate memory for the device to write the result to. */ 73245 hipError_t error = hipMalloc (&result_ptr, sizeof (int)); 73246 assert (error == hipSuccess); 73247 73248 /* Run `do_an_addition` on one workgroup containing one work item. */ 73249 do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr); 73250 73251 /* Copy result from device to host. Note that this acts as a synchronization 73252 point, waiting for the kernel dispatch to complete. */ 73253 error = hipMemcpyDtoH (&result, result_ptr, sizeof (int)); 73254 assert (error == hipSuccess); 73255 73256 printf ("result is %d\n", result); 73257 assert (result == 3); 73258 73259 return 0; 73260 } 73261 73262 This program can be compiled with: 73263 73264 $ hipcc simple.cpp -g -O0 -o simple 73265 73266 ... where `hipcc` is the HIP compiler, shipped with ROCm releases. This 73267 generates an ELF binary for the host architecture, containing another 73268 ELF binary with the device code. The ELF for the device can be 73269 inspected with: 73270 73271 $ roc-obj-ls simple 73272 1 host-x86_64-unknown-linux file://simple#offset=8192&size=0 73273 1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216 73274 $ roc-obj-extract 'file://simple#offset=8192&size=34216' 73275 $ file simple-offset8192-size34216.co 73276 simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped 73277 ^ 73278 amcgcn architecture that my `file` doesn't know about ----´ 73279 73280 Running the program gives the very unimpressive result: 73281 73282 $ ./simple 73283 result is 3 73284 73285 While running, this host program has copied the device program into the 73286 GPU's memory and spawned an execution thread on it. The goal of this 73287 GDB port is to let the user debug host threads and these GPU threads 73288 simultaneously. Here's a sample session using a GDB with this patch 73289 applied: 73290 73291 $ ./gdb -q -nx --data-directory=data-directory ./simple 73292 Reading symbols from ./simple... 73293 (gdb) break do_an_addition 73294 Function "do_an_addition" not defined. 73295 Make breakpoint pending on future shared library load? (y or [n]) y 73296 Breakpoint 1 (do_an_addition) pending. 73297 (gdb) r 73298 Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple 73299 [Thread debugging using libthread_db enabled] 73300 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 73301 [New Thread 0x7ffff5db7640 (LWP 1082911)] 73302 [New Thread 0x7ffef53ff640 (LWP 1082913)] 73303 [Thread 0x7ffef53ff640 (LWP 1082913) exited] 73304 [New Thread 0x7ffdecb53640 (LWP 1083185)] 73305 [New Thread 0x7ffff54bf640 (LWP 1083186)] 73306 [Thread 0x7ffdecb53640 (LWP 1083185) exited] 73307 [Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0] 73308 73309 Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73310 b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73311 out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 73312 24 *out = a + b; 73313 (gdb) info inferiors 73314 Num Description Connection Executable 73315 * 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple 73316 (gdb) info threads 73317 Id Target Id Frame 73318 1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1 73319 2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 73320 5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 73321 * 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition ( 73322 a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73323 b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73324 out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 73325 (gdb) bt 73326 Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1 73327 #0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73328 b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, 73329 out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 73330 (gdb) continue 73331 Continuing. 73332 result is 3 73333 warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208" 73334 [Thread 0x7ffff54bf640 (LWP 1083186) exited] 73335 [Thread 0x7ffff5db7640 (LWP 1082911) exited] 73336 [Inferior 1 (process 1082907) exited normally] 73337 73338 One thing to notice is the host and GPU threads appearing under 73339 the same inferior. This is a design goal for us, as programmers tend to 73340 think of the threads running on the GPU as part of the same program as 73341 the host threads, so showing them in the same inferior in GDB seems 73342 natural. Also, the host and GPU threads share a global memory space, 73343 which fits the inferior model. 73344 73345 Another thing to notice is the error messages when trying to read 73346 variables or printing a backtrace. This is expected for the moment, 73347 since the AMD GPU compiler produces some DWARF that uses some 73348 non-standard extensions: 73349 73350 https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html 73351 73352 There were already some patches posted by Zoran Zaric earlier to make 73353 GDB support these extensions: 73354 73355 https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/ 73356 73357 We think it's better to get the basic support for AMD GPU in first, 73358 which will then give a better justification for GDB to support these 73359 extensions. 73360 73361 GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware 73362 thread using the SIMT (single-instruction, multiple-threads) [3] 73363 execution model. 73364 73365 GDB uses the amd-dbgapi library [4], included in the ROCm platform, for 73366 a few things related to AMD GPU threads debugging. Different components 73367 talk to the library, as show on the following diagram: 73368 73369 +---------------------------+ +-------------+ +------------------+ 73370 | GDB | amd-dbgapi target | <-> | AMD | | Linux kernel | 73371 | +-------------------+ | Debugger | +--------+ | 73372 | | amdgcn gdbarch | <-> | API | <=> | AMDGPU | | 73373 | +-------------------+ | | | driver | | 73374 | | solib-rocm | <-> | (dbgapi.so) | +--------+---------+ 73375 +---------------------------+ +-------------+ 73376 73377 - The amd-dbgapi target is a target_ops implementation used to control 73378 execution of GPU threads. While the debugging of host threads works 73379 by using the ptrace / wait Linux kernel interface (as usual), control 73380 of GPU threads is done through a special interface (dubbed `kfd`) 73381 exposed by the `amdgpu` Linux kernel module. GDB doesn't interact 73382 directly with `kfd`, but instead goes through the amd-dbgapi library 73383 (AMD Debugger API on the diagram). 73384 73385 Since it provides execution control, the amd-dbgapi target should 73386 normally be a process_stratum_target, not just a target_ops. More 73387 on that later. 73388 73389 - The amdgcn gdbarch (describing the hardware architecture of the GPU 73390 execution units) offloads some requests to the amd-dbgapi library, 73391 so that knowledge about the various architectures doesn't need to be 73392 duplicated and baked in GDB. This is for example for things like 73393 the list of registers. 73394 73395 - The solib-rocm component is an solib provider that fetches the list of 73396 code objects loaded on the device from the amd-dbgapi library, and 73397 makes GDB read their symbols. This is very similar to other solib 73398 providers that handle shared libraries, except that here the shared 73399 libraries are the pieces of code loaded on the device. 73400 73401 Given that Linux host threads are managed by the linux-nat target, and 73402 the GPU threads are managed by the amd-dbgapi target, having all threads 73403 appear in the same inferior requires the two targets to be in that 73404 inferior's target stack. However, there can only be one 73405 process_stratum_target in a given target stack, since there can be only 73406 one target per slot. To achieve it, we therefore resort the hack^W 73407 solution of placing the amd-dbgapi target in the arch_stratum slot of 73408 the target stack, on top of the linux-nat target. Doing so allows the 73409 amd-dbgapi target to intercept target calls and handle them if they 73410 concern GPU threads, and offload to beneath otherwise. See 73411 amd_dbgapi_target::fetch_registers for a simple example: 73412 73413 void 73414 amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno) 73415 { 73416 if (!ptid_is_gpu (regcache->ptid ())) 73417 { 73418 beneath ()->fetch_registers (regcache, regno); 73419 return; 73420 } 73421 73422 // handle it 73423 } 73424 73425 ptids of GPU threads are crafted with the following pattern: 73426 73427 (pid, 1, wave id) 73428 73429 Where pid is the inferior's pid and "wave id" is the wave handle handed 73430 to us by the amd-dbgapi library (in practice, a monotonically 73431 incrementing integer). The idea is that on Linux systems, the 73432 combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always 73433 belong to the init process, which would also have pid == 1 (and it's 73434 improbable for the init process to offload work to the GPU and much less 73435 for the user to debug it). We can therefore differentiate GPU and 73436 non-GPU ptids this way. See ptid_is_gpu for more details. 73437 73438 Note that we believe that this scheme could break down in the context of 73439 containers, where the initial process executed in a container has pid 1 73440 (in its own pid namespace). For instance, if you were to execute a ROCm 73441 program in a container, then spawn a GDB in that container and attach to 73442 the process, it will likely not work. This is a known limitation. A 73443 workaround for this is to have a dummy process (like a shell) fork and 73444 execute the program of interest. 73445 73446 The amd-dbgapi target watches native inferiors, and "attaches" to them 73447 using amd_dbgapi_process_attach, which gives it a notifier fd that is 73448 registered in the event loop (see enable_amd_dbgapi). Note that this 73449 isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached 73450 is a precondition for amd_dbgapi_process_attach to work. When the 73451 debugged process enables the ROCm runtime, the amd-dbgapi target gets 73452 notified through that fd, and pushes itself on the target stack of the 73453 inferior. The amd-dbgapi target is then able to intercept target_ops 73454 calls. If the debugged process disables the ROCm runtime, the 73455 amd-dbgapi target unpushes itself from the target stack. 73456 73457 This way, the amd-dbgapi target's footprint stays minimal when debugging 73458 a process that doesn't use the AMD ROCm platform, it does not intercept 73459 target calls. 73460 73461 The amd-dbgapi library is found using pkg-config. Since enabling 73462 support for the amdgpu architecture (amdgpu-tdep.c) depends on the 73463 amd-dbgapi library being present, we have the following logic for 73464 the interaction with --target and --enable-targets: 73465 73466 - if the user explicitly asks for amdgcn support with 73467 --target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for 73468 the amd-dbgapi and fail if not found 73469 73470 - if the user uses --enable-targets=all, we probe for amd-dbgapi, 73471 enable amdgcn support if found, disable amdgcn support if not found 73472 73473 - if the user uses --enable-targets=all and --with-amd-dbgapi=yes, 73474 we probe for amd-dbgapi, enable amdgcn if found and fail if not found 73475 73476 - if the user uses --enable-targets=all and --with-amd-dbgapi=no, 73477 we do not probe for amd-dbgapi, disable amdgcn support 73478 73479 - otherwise, amd-dbgapi is not probed for and support for amdgcn is not 73480 enabled 73481 73482 Finally, a simple test is included. It only tests hitting a breakpoint 73483 in device code and resuming execution, pretty much like the example 73484 shown above. 73485 73486 [1] https://docs.amd.com/category/ROCm_v5.4 73487 [2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4 73488 [3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads 73489 [4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4 73490 73491 Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee 73492 Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com> 73493 Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com> 73494 Co-Authored-By: Tony Tye <Tony.Tye@amd.com> 73495 Co-Authored-By: Lancelot SIX <lancelot.six@amd.com> 73496 Co-Authored-By: Pedro Alves <pedro@palves.net> 73497 734982023-02-02 Simon Marchi <simon.marchi@efficios.com> 73499 73500 gdb: make gdb_printing_disassembler::stream public 73501 In the ROCm port, we need to access the underlying stream of a 73502 gdb_printing_disassembler, so make it public. The reason we need to 73503 access it is to know whether it supports style escape code. We then 73504 pass that information to a temporary string_file we use while 73505 symbolizing addresses. 73506 73507 Change-Id: Ib95755a4a45b8f6478787993e9f904df60dd8dc1 73508 Approved-By: Andrew Burgess <aburgess@redhat.com> 73509 735102023-02-02 Simon Marchi <simon.marchi@efficios.com> 73511 73512 gdb/solib-svr4: don't disable probes interface if probe not found 73513 In ROCm-GDB, we install an solib provider for the GPU code objects on 73514 top of the svr4 provider for the host, in order to add solibs 73515 representing the GPU code objects to the solib list containing the host 73516 process' shared libraries. We override the target_so_ops::handle_event 73517 function pointer with our own, in which we call svr4_so_ops.handle_event 73518 (which contains svr4_handle_solib_event) manually. When the host 73519 (un)loads a library, the ROCm part of handle_event is a no-op. When the 73520 GPU (un)loads a code object, we want the host side (svr4) to be a no-op. 73521 73522 The problem is that when handle_event is called because of a GPU event, 73523 svr4_handle_solib_event gets called while not stopped at an svr4 73524 probe. It then assumes this means there's a problem with the probes 73525 interface and disables it through the following sequence of events: 73526 73527 - solib_event_probe_at return nullptr 73528 - svr4_handle_solib_event returns early 73529 - the make_scope_exit callback calls disable_probes_interface 73530 73531 We could fix that by making the ROCm handle_event callback check if an 73532 svr4 probe is that the stop address, and only call 73533 svr4_so_ops.handle_event if so. However, it doesn't feel right to 73534 include some svr4 implementation detail in the ROCm event handler. 73535 73536 Instead, this patch changes svr4_handle_solib_event to not assume it is 73537 an error if called while not at an svr4 probe location, and therefore 73538 not disable the probes interface. That just means moving the 73539 make_scope_exit call below where we lookup the probe by pc. 73540 73541 Change-Id: Ie8ddf5beffa2e92b8ebfdd016454546252519244 73542 Co-Authored-By: Lancelot SIX <lancelot.six@amd.com> 73543 735442023-02-02 Simon Marchi <simon.marchi@efficios.com> 73545 73546 gdb: add gdbarch_up 73547 Add a gdbarch_up unique pointer type, that calls gdbarch_free on 73548 deletion. This is used in the ROCm support patch at the end of this 73549 series. 73550 73551 Change-Id: I4b808892d35d69a590ce83180f41afd91705b2c8 73552 Approved-By: Andrew Burgess <aburgess@redhat.com> 73553 735542023-02-02 Simon Marchi <simon.marchi@efficios.com> 73555 73556 gdb: add inferior_pre_detach observable 73557 Add an observable notified in target_detach just before calling the 73558 detach method on the inferior's target stack. This allows observer to 73559 do some work on the inferior while it's still ptrace-attached, in the 73560 case of a native Linux inferior. Specifically, the amd-dbgapi target 73561 will need it in order to call amd_dbgapi_process_detach before the 73562 process gets ptrace-detached. 73563 73564 Change-Id: I28b6065e251012a4c2db8a600fe13ba31671e3c9 73565 Approved-By: Andrew Burgess <aburgess@redhat.com> 73566 735672023-02-02 Simon Marchi <simon.marchi@efficios.com> 73568 73569 gdbsupport: add type definitions for pid, lwp and tid 73570 A following patch will want to declare variables of the same type as 73571 some ptid_t components. To make that easy (and avoid harcoding those 73572 types everywhere), define some type definitions in the ptid_t struct for 73573 each of them. Use them throughout ptid.h. 73574 73575 I initially used pid_t, lwp_t and tid_t, but there is the risk of some 73576 system defining the pid_t type using a macro instead of a typedef, which 73577 would break things. So, use the _type suffix instead. 73578 73579 Change-Id: I820b0bea9dafcb4914f1c9ba4bb96b5c666c8dec 73580 Approved-By: Andrew Burgess <aburgess@redhat.com> 73581 735822023-02-02 Pedro Alves <pedro@palves.net> 73583 73584 gdb: make install_breakpoint return a non-owning reference 73585 A following patch will want to install a breakpoint and then keep a 73586 non-owning reference to it. Make install_breakpoint return a non-owning 73587 reference, to make that easy. 73588 73589 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 73590 Change-Id: I2e8106a784021ff276ce251e24708cbdccc2d479 73591 Approved-By: Andrew Burgess <aburgess@redhat.com> 73592 735932023-02-02 Lancelot SIX <lancelot.six@amd.com> 73594 73595 gdb: add supports_arch_info callback to gdbarch_register 73596 In the ROCm GDB port, there are some amdgcn architectures known by BFD 73597 that we don't actually support in GDB. We don't want 73598 gdbarch_printable_names to return these architectures. 73599 73600 gdbarch_printable_names is used for a few things: 73601 73602 - completion of the "set architecture" command 73603 - the gdb.architecture_names function in Python 73604 - foreach-arch selftests 73605 73606 Add an optional callback to gdbarch_register that is a predicate 73607 indicating whether the gdbarch supports the given bfd_arch_info. by 73608 default, it is nullptr, meaning that the gdbarch accepts all "mach"s for 73609 that architecture known by BFD. 73610 73611 Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860 73612 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 73613 Approved-By: Andrew Burgess <aburgess@redhat.com> 73614 736152023-02-02 Tom de Vries <tdevries@suse.de> 73616 73617 [gas] Update .loc syntax comment in dwarf2dbg.c 73618 I noticed that a comment in gas/dwarf2dbg.c describing .loc syntax was missing 73619 the "view VALUE" option. 73620 73621 Fix this by adding the missing option. 73622 736232023-02-02 Enze Li <enze.li@hotmail.com> 73624 73625 gdb: remove gdb_indent.sh 73626 GDB has been converted to a C++ program for many years[1], and the 73627 gdb_indent.sh will not be used any more. Therefore, remove the script as 73628 obvious. 73629 73630 [1] https://sourceware.org/gdb/wiki/cxx-conversion 73631 73632 Approved-By: Simon Marchi <simark@simark.ca> 73633 736342023-02-02 Indu Bhagat <indu.bhagat@oracle.com> 73635 73636 ld/doc: use "stack trace" instead of "unwind" for SFrame 73637 SFrame format is meant for generating stack traces only. 73638 73639 ld/ 73640 * ld.texi: Replace the use of "unwind" with "stack trace". 73641 736422023-02-02 Indu Bhagat <indu.bhagat@oracle.com> 73643 73644 bfd: use "stack trace" instead of "unwind" for SFrame 73645 SFrame format is meant for generating stack traces only. 73646 73647 bfd/ 73648 * elf-bfd.h: Replace the use of "unwind" with "stack trace". 73649 * elf-sframe.c: Likewise. 73650 * elf64-x86-64.c: Likewise. 73651 * elfxx-x86.c: Likewise. 73652 73653 include/ 73654 * elf/common.h: Likewise. 73655 736562023-02-02 Indu Bhagat <indu.bhagat@oracle.com> 73657 73658 gas: use "stack trace" instead of "unwind" for SFrame 73659 SFrame format is meant for generating stack traces only. 73660 73661 gas/ 73662 * as.c: Replace the use of "unwind" with "stack trace". 73663 * config/tc-aarch64.c: Likewise. 73664 * config/tc-aarch64.h: Likewise. 73665 * config/tc-i386.c: Likewise. 73666 * config/tc-i386.h: Likewise. 73667 * gen-sframe.c: Likewise. 73668 * gen-sframe.h: Likewise. 73669 * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise. 73670 * testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise. 73671 * testsuite/gas/cfi-sframe/common-empty-2.s: Likewise. 73672 * testsuite/gas/cfi-sframe/common-empty-3.s: Likewise. 73673 736742023-02-02 Indu Bhagat <indu.bhagat@oracle.com> 73675 73676 sframe: use "stack trace" instead of "unwind" for SFrame 73677 SFrame format is meant for generating stack traces only. 73678 73679 include/ 73680 * sframe.h: Fix comments in the header file. 73681 736822023-02-02 Indu Bhagat <indu.bhagat@oracle.com> 73683 73684 libsframe/doc: use "stack trace" instead of "unwind" for SFrame 73685 SFrame format is meant for generating stack traces only. 73686 73687 libsframe/ 73688 * doc/sframe-spec.texi: Use "stack trace" instead of "unwind". 73689 736902023-02-02 Alan Modra <amodra@gmail.com> 73691 73692 ld-elf/merge test update 73693 The merge test fais on numerous targets because they don't support the 73694 necessary pc-relative relocs. This patch removes that part of the 73695 merge test, and makes references to the merged strings from .data 73696 rather than .text to better support targets that relax text by 73697 default. 73698 736992023-02-02 GDB Administrator <gdbadmin@sourceware.org> 73700 73701 Automatic date update in version.in 73702 737032023-02-01 Alan Modra <amodra@gmail.com> 73704 73705 obj-elf.h BYTES_IN_WORD 73706 Don't define this. It is defined just before elf-bfd.h is included, 73707 but doesn't have any relevance there. Instead is for aout64.h where 73708 the default is 4 anyway. 73709 737102023-02-01 Alan Modra <amodra@gmail.com> 73711 73712 gas obj_end 73713 Provide a way for config/obj-* to clean up at end of assembly, and do 73714 so for ELF. 73715 73716 * obj.h (struct format_ops): Add "end". 73717 * config/obj-aout.c (aout_format_ops): Init new field. 73718 * config/obj-coff.c (coff_format_ops): Likewise. 73719 * config/obj-ecoff.c (ecoff_format_ops): Likewise. 73720 * config/obj-elf.c (elf_format_ops): Likewise. 73721 (elf_begin): Move later in file. Clear some more variables. 73722 (comment_section): Make file scope. 73723 (free_section_idx): Rewrite. 73724 (elf_adjust_symtab): Expand str_htab_create call and use 73725 free_section_idx as delete function. 73726 (elf_frob_file_after_relocs): Don't clean up groups.indexes here. 73727 (elf_end): New function. 73728 * config/obj-elf.h (obj_end): Define. 73729 * config/obj-multi.h (obj_end): Define. 73730 * output-file.c (output_file_close): Call obj_end. 73731 737322023-02-01 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 73733 73734 gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap 73735 This patch doesn't change gdbserver behaviour, but after later changes are 73736 made it avoids a null pointer dereference when HWCAP needs to be obtained 73737 for a specific process while current_thread is nullptr. 73738 73739 Fixing linux_read_auxv, linux_get_hwcap and linux_get_hwcap2 to take a PID 73740 parameter seems more correct than setting current_thread in one particular 73741 code path. 73742 73743 Changes are propagated to allow passing the new parameter through the call 73744 chain. 73745 73746 Approved-By: Simon Marchi <simon.marchi@efficios.com> 73747 737482023-02-01 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 73749 73750 gdbserver: Add assert in find_register_by_number 73751 It helped me during development, catching bugs closer to when they actually 73752 happened. 73753 73754 Also remove the equivalent gdb_assert in regcache_raw_read_unsigned, since 73755 it's checking the same condition a few frames above. 73756 73757 Suggested-By: Simon Marchi <simon.marchi@efficios.com> 73758 Approved-By: Simon Marchi <simon.marchi@efficios.com> 73759 737602023-02-01 Andrew Burgess <aburgess@redhat.com> 73761 73762 gdb/testsuite: fix fetch_src_and_symbols.exp with native-gdbserver board 73763 I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp script 73764 doesn't work with the native-gdbserver board, I see this error: 73765 73766 ERROR: tcl error sourcing /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp. 73767 ERROR: gdbserver does not support run without extended-remote 73768 while executing 73769 "error "gdbserver does not support $command without extended-remote"" 73770 (procedure "gdb_test_multiple" line 51) 73771 invoked from within 73772 73773 This was introduced with this commit: 73774 73775 commit 7dd38e31d67c2548b52bea313ab18e40824c05da 73776 Date: Fri Jan 6 18:45:27 2023 -0500 73777 73778 gdb/linespec.c: Fix missing source file during breakpoint re-set 73779 73780 The problem is that the above commit introduces a direct use of the 73781 "run" command, which doesn't work with 'target remote' targets, as 73782 exercised by the native-gdbserver board. 73783 73784 To avoid this, in this commit I switch to using runto_main. However, 73785 calling runto_main will, by default, delete all the currently set 73786 breakpoints. As the point of the above commit was to check that a 73787 breakpoint set before stating an inferior would be correctly re-set, 73788 we need to avoid this breakpoint deleting behaviour. 73789 73790 To do this I make use of with_override, and override the 73791 delete_breakpoints proc with a dummy proc which does nothing. 73792 73793 By reverting the GDB changes in commit 7dd38e31d67c I have confirmed 73794 that even after my changes in this commit, the test still fails. But 73795 with the fixes in commit 7dd38e31d67c, this test now passed using the 73796 unix, native-gdbserver, and native-extended-gdbserver boards. 73797 737982023-02-01 Alexandra Hájková <ahajkova@redhat.com> 73799 73800 gdb: defer warnings when loading separate debug files 73801 Currently, when GDB loads debug information from a separate debug 73802 file, there are a couple of warnings that could be produced if things 73803 go wrong. 73804 73805 In find_separate_debug_file_by_buildid (build-id.c) GDB can give a 73806 warning if the separate debug file doesn't include any actual debug 73807 information, and in separate_debug_file_exists (symfile.c) we can warn 73808 if the CRC checksum in the separate debug file doesn't match the 73809 checksum in the original executable. 73810 73811 The problem here is that, when looking up debug information, GDB will 73812 try several different approaches, lookup by build-id, lookup by 73813 debug-link, and then a lookup from debuginfod. GDB can potentially 73814 give a warning from an earlier attempt, and then succeed with a later 73815 attempt. In the cases I have run into this is primarily a warning 73816 about some out of date debug information on my machine, but then GDB 73817 finds the correct information using debuginfod. This can be confusing 73818 to a user, they will see warnings from GDB when really everything is 73819 working just fine. 73820 73821 For example: 73822 73823 warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \ 73824 does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). 73825 73826 This diagnostic was printed on Fedora 33 even when the correct 73827 debuginfo was downloaded. 73828 73829 In this patch I propose that we defer any warnings related to looking 73830 up debug information from a separate debug file. If any of the 73831 approaches are successful then GDB will not print any of the warnings. 73832 As far as the user is concerned, everything "just worked". Only if 73833 GDB completely fails to find any suitable debug information will the 73834 warnings be printed. 73835 73836 The crc_mismatch test compiles two executables: crc_mismatch and 73837 crc_mismatch-2 and then strips them of debuginfo creating separate 73838 debug files. The test then replaces crc_mismatch-2.debug with 73839 crc_mismatch.debug to trigger "CRC mismatch" warning. A local 73840 debuginfod server is setup to supply the correct debug file, now when 73841 GDB looks up the debug info no warning is given. 73842 73843 The build-id-no-debug-warning.exp is similar to the previous test. It 73844 triggers the "separate debug info file has no debug info" warning by 73845 replacing the build-id based .debug file with the stripped binary and 73846 then loading it to GDB. It then also sets up local debuginfod server 73847 with the correct debug file to download to make sure no warnings are 73848 emitted. 73849 738502023-02-01 Nick Clifton <nickc@redhat.com> 73851 73852 Fix compilation of the assembler with sanitization enabled. 73853 * dwarf2dbg.c (emit_inc_line_addr): Use unsigned constants when checking addr_delta. 73854 738552023-02-01 Alan Modra <amodra@gmail.com> 73856 73857 Recursion in as_info_where 73858 This function has a gas_assert, ie. possible call to as_abort, which 73859 calls as_report_context, which calls as_info_where. 73860 73861 * messages.c (as_info_where): Don't gas_assert. 73862 738632023-02-01 Simon Marchi <simon.marchi@efficios.com> 73864 73865 gdb/dwarf: rename cooked_index_vector to cooked_index 73866 See previous patch's commit message for rationale. 73867 73868 Change-Id: I6b8cdc045dffccc1c01ed690ff258af09f6ff076 73869 Approved-By: Tom Tromey <tom@tromey.com> 73870 738712023-02-01 Simon Marchi <simon.marchi@efficios.com> 73872 73873 gdb/dwarf: rename cooked_index to cooked_index_shard 73874 I propose to rename cooked_index_vector and cooked_index such that the 73875 "main" object, that is the entry point to the index, is called 73876 cooked_index. The fact that the cooked index is implemented as a vector 73877 of smaller indexes is an implementation detail. 73878 73879 This patch renames cooked_index to cooked_index_shard. The following 73880 patch renames cooked_index_vector to cooked_index. 73881 73882 Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177 73883 Approved-By: Tom Tromey <tom@tromey.com> 73884 738852023-02-01 Tom de Vries <tdevries@suse.de> 73886 73887 [gas] Emit v2 .debug_line for -gdwarf-2 73888 Currently, when using -gdwarf-2, gas emits a v3 .debug_line contribution. 73889 73890 Fix this by emitting a v2 .debug_line contribution instead. 73891 73892 gas/ChangeLog: 73893 73894 2023-01-31 Tom de Vries <tdevries@suse.de> 73895 73896 PR 23941 73897 * dwarf2dbg.c (DWARF2_LINE_VERSION): Set to 2 for -gdwarf-2. 73898 (DWARF2_LINE_OPCODE_BASE): Handle DWARF2_LINE_VERSION == 2. 73899 (dwarf2_directive_loc): Bump dwarf_level when encountering 73900 v3 .loc options. 73901 (out_debug_line): Don't output v3 standard opcodes for v2. 73902 * testsuite/gas/i386/debug1.d: Update. 73903 * testsuite/gas/i386/dwarf2-line-1.d: Update. 73904 * testsuite/gas/i386/dwarf2-line-4.d: Update. 73905 739062023-02-01 GDB Administrator <gdbadmin@sourceware.org> 73907 73908 Automatic date update in version.in 73909 739102023-01-31 Simon Marchi <simon.marchi@efficios.com> 73911 73912 gdb: add nullptr check to cooked_index_functions::dump 73913 Since commit 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in 73914 cooked_index_functions::dump"), we see: 73915 73916 maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error^M 73917 ^M 73918 Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 15 minsyms^M 73919 ^M 73920 Cooked index in use:^M 73921 ^M 73922 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb-checked-static-cast.h:58: internal-error: checked_static_cast: Assertion `result != nullptr' failed.^M 73923 A problem internal to GDB has been detected,^M 73924 further debugging may prove unreliable.^M 73925 ----- Backtrace -----^M 73926 FAIL: gdb.dwarf2/dw2-error.exp: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error (GDB internal error) 73927 73928 The problem is that when cooked_index_functions fails to build an index, 73929 per_objfile->index_table is nullptr. Therefore, add a nullptr check, 73930 like other methods of cooked_index_functions already do. 73931 73932 Print the "Cooked index in use" message after the nullptr check, such 73933 that if the cooked index failed to build, that message is not printed. 73934 73935 Change-Id: Id67aef592e76c41b1e3bde9838a4e36cef873253 73936 739372023-01-31 Simon Marchi <simon.marchi@efficios.com> 73938 73939 gdbsupport: allow passing nullptr to checked_static_cast 73940 Both static_cast and dynamic_cast handle nullptr (they return nullptr), 73941 so I think checked_static_cast should too. This will allow doing a null 73942 check after a checked_static_cast: 73943 73944 cooked_index_vector *table 73945 = (gdb::checked_static_cast<cooked_index_vector *> 73946 (per_bfd->index_table.get ())); 73947 if (table != nullptr) 73948 return; 73949 73950 Change-Id: If5c3134e63696f8e417c87b5f3901240c9f7ea97 73951 739522023-01-31 Simon Marchi <simon.marchi@efficios.com> 73953 73954 gdb/testsuite: adjust ensure_gdb_index to cooked_index_functions::dump changes 73955 Following 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in 73956 cooked_index_functions::dump"), I see some failures like: 73957 73958 (gdb) mt print objfiles with-mf^M 73959 ^M 73960 Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/with-mf/with-mf: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 18 minsyms ^M 73961 ^M 73962 Cooked index in use:^M 73963 ^M 73964 ... 73965 (gdb) FAIL: gdb.base/with-mf.exp: check if index present 73966 73967 This is because the format of the "Cooked index in use" line changed 73968 slightly. Adjust ensure_gdb_index to expect the trailing colon. 73969 73970 Change-Id: If0a87575c02d8a0bc0d4b8ead540c234c62760f8 73971 739722023-01-31 Simon Marchi <simon.marchi@efficios.com> 73973 73974 gdb/testsuite: fix xfail in gdb.ada/ptype_tagged_param.exp 73975 I see: 73976 73977 ERROR: wrong # args: should be "xfail message" 73978 while executing 73979 "xfail "no debug info" $gdb_test_name" 73980 ("uplevel" body line 3) 73981 invoked from within 73982 "uplevel { 73983 if {!$has_runtime_debug_info} { 73984 xfail "no debug info" $gdb_test_name 73985 } else { 73986 fail $gdb_test_name 73987 } 73988 }" 73989 73990 This is because the xfail takes only one argument, fix that. 73991 73992 Change-Id: I2e304d4fd3aa61067c04b5dac2be2ed34dab3190 73993 739942023-01-31 Nick Clifton <nickc@redhat.com> 73995 73996 Updated Swedish translation for the binutils sub-directory 73997 739982023-01-31 Alan Modra <amodra@gmail.com> 73999 74000 Re: Another fix for EFI generation with LTO enabled 74001 Revert 1c66b8a03989 and instead fix the broken list pointer. 74002 74003 PR 29998 74004 * pe-dll.c (build_filler_bfd): Revert last change. 74005 * ldlang.c (lang_process): When rescanning archives for lto, 74006 fix file_chain.tail pointer if the insert point happens to be 74007 at the end of the list. 74008 740092023-01-31 Andrew Burgess <aburgess@redhat.com> 74010 74011 gas/ppc: Additional tests for DFP instructions 74012 I noticed that some of the Power6 DFP instructions were not covered by 74013 the assembler tests. I've added a new test file which I believe 74014 covers all the DFP Power6 instructions. 74015 74016 The existing gas/testsuite/gas/ppc/power6.d test is called: 74017 74018 POWER6 tests (includes DFP and Altivec) 74019 74020 And does cover some of the DFP instructions. But, given the number of 74021 additional instructions I'm adding I opted to add a whole new test 74022 file. I've left the original power6.d unchanged, so there is now some 74023 overlap, but I don't think that should hurt much. 74024 740252023-01-31 Jan Beulich <jbeulich@suse.com> 74026 74027 RISC-V: make C-extension JAL available again for (32-bit) assembly 74028 Along with the normal JAL alias, the C-extension one should have been 74029 moved as well by 839189bc932e ("RISC-V: re-arrange opcode table for 74030 consistent alias handling"), for the assembler to actually be able to 74031 use it where/when possible. 74032 74033 Since neither this nor any other compressed branch insn was being tested 74034 so far, take the opportunity and introduce a new testcase covering those. 74035 740362023-01-31 Alan Modra <amodra@gmail.com> 74037 74038 Silence ubsan warning about 1<<31 74039 * merge.c (hash_blob): Write 1u << 31. 74040 740412023-01-31 Alan Modra <amodra@gmail.com> 74042 74043 PR 30060, ASAN error in bfd_cache_close 74044 After bfd_close nothing should access bfd memory. Now that bfd_close 74045 always tidies up even after an error, attempting to tidy the cached 74046 bfd list by calling bfd_cache_close is wrong and not needed. 74047 74048 PR 30060 74049 * ar.c (remove_output): Don't call bfd_cache_close. 74050 (output_bfd): Delete. 74051 * arsup.c (ar_end): Call bfd_close_all_done, not bfd_cache_close. 74052 740532023-01-31 Alan Modra <amodra@gmail.com> 74054 74055 testsuite XPASSes 74056 This adjusts the testsuite to get rid of a number of XPASSes that have 74057 appeared. Someone might like to look into a better patch for the s390 74058 change. 74059 74060 aarch64-pe XPASS: weak symbols 74061 arm-nacl XPASS: rgn-over8 74062 mcore-pe XPASS: ld-scripts/provide-8 74063 mips64-linux-gnuabi64 XPASS: vers4 74064 mips64-linux-gnuabi64 XPASS: vers4b 74065 mips-linux-gnu XPASS: vers4 74066 mips-linux-gnu XPASS: vers4b 74067 s390-linux-gnu XPASS: undefined line 74068 sh4-linux-gnu XPASS: --gc-sections with __start_SECTIONNAME 74069 sh-coff XPASS: objcopy object (simple copy) 74070 sh-coff XPASS: objcopy executable (pr25662) 74071 74072 binutils/ 74073 * testsuite/binutils-all/objcopy.exp: Don't xfail "simple 74074 copy" and "pr25662" on sh-*-coff. Remove all non-ELF xfails 74075 on "ELF unknown section type" test. 74076 ld/ 74077 * testsuite/ld-elfvers/vers.exp (vers4, vers4b): Don't xfail 74078 all mips, just xfail mips irix. 74079 * testsuite/ld-gc/pr19161.d: Don't xfail sh. 74080 * testsuite/ld-scripts/rgn-over8-ok.d: Don't xfail nacl. 74081 * testsuite/ld-scripts/weak.exp: Don't xfail aarch64-pe. 74082 * testsuite/ld-undefined/undefined.exp: Conditionally xfail 74083 "undefined line" depending on gcc version for s390. 74084 740852023-01-31 GDB Administrator <gdbadmin@sourceware.org> 74086 74087 Automatic date update in version.in 74088 740892023-01-30 Tom Tromey <tom@tromey.com> 74090 74091 Remove value_next declaration 74092 value_next is declared but not defined. It's long obsolete. This 74093 patch removes the stray declaration. 74094 740952023-01-30 Simon Marchi <simon.marchi@efficios.com> 74096 74097 gdb: fix dwarf2/cooked-index.c compilation on 32-bit systems 74098 The i386 builder shows: 74099 74100 ../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’: 74101 ../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=] 74102 492 | gdb_printf (" DIE offset: 0x%lx\n", 74103 | ~~^ 74104 | | 74105 | long unsigned int 74106 | %llx 74107 493 | to_underlying (entry->die_offset)); 74108 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 74109 | | 74110 | std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int} 74111 74112 The die_offset's underlying type is uint64, so use PRIx64 in the format 74113 string. 74114 74115 Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323 74116 741172023-01-30 Mark Wielaard <mark@klomp.org> 74118 74119 gdb: Replace memcpy with std::copy to avoid some g++ warnings on sparc 74120 For some reason g++ 12.2.1 on sparc produces spurious warnings for 74121 stringop-overread and restrict in fbsd-tdep.c for a memcpy call. 74122 Use std::copy to avoid the warnings: 74123 74124 In function ‘void* memcpy(void*, const void*, size_t)’, 74125 inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:666:10: 74126 /usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified bound 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 74127 74128 In function ‘void* memcpy(void*, const void*, size_t)’, 74129 inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:673:10: 74130 /usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744073709551612 bytes at offsets 0 and 0 overlaps 9223372036854775801 bytes at offset -9223372036854775805 [-Werror=restrict] 74131 74132 gdb/ChangeLog: 74133 74134 * fbsd-tdep.c (fbsd_make_note_desc): Use std::copy instead 74135 of memcpy. 74136 741372023-01-30 Simon Marchi <simon.marchi@polymtl.ca> 74138 74139 gdb/dwarf: dump cooked index contents in cooked_index_functions::dump 74140 As I am investigating a crash I see with the cooked index, I thought it 74141 would be useful to have a way to dump the index contents. For those not 74142 too familiar with it (that includes me), it can help get a feel of what 74143 it contains and how it is structured. 74144 74145 The cooked_index_functions::dump function is called as part of the 74146 "maintenance print objfiles" command. I tried to make the output 74147 well structured and indented to help readability, as this prints a lot 74148 of text. 74149 74150 The dump function first dumps all cooked index entries, like this: 74151 74152 [25] ((cooked_index_entry *) 0x621000121220) 74153 name: __ioinit 74154 canonical: __ioinit 74155 DWARF tag: DW_TAG_variable 74156 flags: 0x2 [IS_STATIC] 74157 DIE offset: 0x21a4 74158 parent: ((cooked_index_entry *) 0x6210000f9610) [std] 74159 74160 Then the information about the main symbol: 74161 74162 main: ((cooked_index_entry *) 0x621000123b40) [main] 74163 74164 And finally the address map contents: 74165 74166 [1] ((addrmap *) 0x6210000f7910) 74167 74168 [0x0] ((dwarf2_per_cu_data *) 0) 74169 [0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00) 74170 [0x1cc7] ((dwarf2_per_cu_data *) 0) 74171 [0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00) 74172 [0x1cdf] ((dwarf2_per_cu_data *) 0) 74173 [0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00) 74174 74175 The display of address maps above could probably be improved, to show it 74176 more as ranges, but I think this is a reasonable start. 74177 74178 Note that this patch depends on Pedro Alves' patch "enum_flags 74179 to_string" [1]. If my patch is to be merged before Pedro's series, I 74180 will cherry-pick this patch from his series and merge it before mine. 74181 74182 [1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/ 74183 74184 Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a 74185 741862023-01-30 Pedro Alves <pedro@palves.net> 74187 74188 enum_flags to_string 74189 This commit introduces shared infrastructure that can be used to 74190 implement enum_flags -> to_string functions. With this, if we want to 74191 support converting a given enum_flags specialization to string, we 74192 just need to implement a function that provides the enumerator->string 74193 mapping, like so: 74194 74195 enum some_flag 74196 { 74197 SOME_FLAG1 = 1 << 0, 74198 SOME_FLAG2 = 1 << 1, 74199 SOME_FLAG3 = 1 << 2, 74200 }; 74201 74202 DEF_ENUM_FLAGS_TYPE (some_flag, some_flags); 74203 74204 static std::string 74205 to_string (some_flags flags) 74206 { 74207 static constexpr some_flags::string_mapping mapping[] = { 74208 MAP_ENUM_FLAG (SOME_FLAG1), 74209 MAP_ENUM_FLAG (SOME_FLAG2), 74210 MAP_ENUM_FLAG (SOME_FLAG3), 74211 }; 74212 return flags.to_string (mapping); 74213 } 74214 74215 .. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like 74216 "0x6 [SOME_FLAG2 SOME_FLAG3]". 74217 74218 If we happen to forget to update the mapping array when we introduce a 74219 new enumerator, then the string representation will pretty-print the 74220 flags it knows about, and then the leftover flags in hex (one single 74221 number). For example, if we had missed mapping SOME_FLAG2 above, we'd 74222 end up with: 74223 74224 to_string(SOME_FLAG2 | SOME_FLAG3) => "0x6 [SOME_FLAG2 0x4]"); 74225 74226 Other than in the unit tests included, no actual usage of the 74227 functionality is added in this commit. 74228 74229 Approved-By: Simon Marchi <simon.marchi@efficios.com> 74230 Change-Id: I835de43c33d13bc0c95132f42c3f97318b875779 74231 742322023-01-30 Tom Tromey <tromey@adacore.com> 74233 74234 Fix comparator bug in cooked index 74235 Simon pointed out that the cooked index template-matching patch 74236 introduced a failure in libstdc++ debug mode. In particular, the new 74237 code violates the assumption of std::lower_bound and std::upper_bound 74238 that the range is sorted with respect to the comparison. 74239 74240 When I first debugged this, I thought the problem was unfixable as-is 74241 and that a second layer of filtering would have to be done. However, 74242 on irc, Simon pointed out that it could perhaps be solved if the 74243 comparison function were assured that one operand always came from the 74244 index, with the other always being the search string. 74245 74246 This patch implements this idea. 74247 74248 First, a new mode is introduced: a sorting mode for 74249 cooked_index_entry::compare. In this mode, strings are compared 74250 case-insensitively, but we're careful to always sort '<' before any 74251 other printable character. This way, two names like "func" and 74252 "func<param>" will be sorted next to each other -- i.e., "func1" will 74253 not be seen between them. This is important when searching. 74254 74255 Second, the compare function is changed to work in a strcmp-like way. 74256 This makes it easier to test and (IMO) understand. 74257 74258 Third, the compare function is modified so that in non-sorting modes, 74259 the index entry is always the first argument. This allows consistency 74260 in compares. 74261 74262 I regression tested this in libstdc++ debug mode on x86-64 Fedora 36. 74263 It fixes the crash that Simon saw. 74264 74265 This is v2. I believe it addresses the review comments, except for 74266 the 'enum class' change, as I mentioned in email on the list. 74267 74268 Approved-By: Simon Marchi <simon.marchi@efficios.com> 74269 742702023-01-30 Tom Tromey <tom@tromey.com> 74271 74272 Clean up lnp_state_machine constructor 74273 This changes the lnp_state_machine constructor to initialize members 74274 directly; and changes lnp_state_machine itself to initialize members 74275 inline when possible. 74276 74277 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 74278 742792023-01-30 Tom Tromey <tromey@adacore.com> 74280 74281 Make addrmap const-correct in cooked index 74282 After the cooked index is created, the addrmaps should be const. 74283 74284 Change-Id: I8234520ab346ced40a8dd6e478ba21fc438c2ba2 74285 742862023-01-30 Simon Marchi <simon.marchi@polymtl.ca> 74287 74288 gdb: provide const-correct versions of addrmap::find and addrmap::foreach 74289 Users of addrmap::find and addrmap::foreach that have a const addrmap 74290 should ideally receive const pointers to objects, to indicate they 74291 should not be modified. However, users that have a non-const addrmap 74292 should still receive a non-const pointer. 74293 74294 To achieve this, without adding more virtual methods, make the existing 74295 find and foreach virtual methods private and prefix them with "do_". 74296 Add small non-const and const wrappers for find and foreach. 74297 74298 Obviously, the const can be cast away, but if using static_cast 74299 instead of C-style casts, then the compiler won't let you cast 74300 the const away. I changed all the callers of addrmap::find and 74301 addrmap::foreach I could find to make them use static_cast. 74302 74303 Change-Id: Ia8e69d022564f80d961413658fe6068edc71a094 74304 743052023-01-30 Tom Tromey <tromey@adacore.com> 74306 74307 Use xfail in ptype_tagged_param.exp 74308 Pedro pointed out that ptype_tagged_param.exp used a kfail, but an 74309 xfail would be more appropriate as the problem appears to be in gcc, 74310 not gdb. 74311 743122023-01-30 Christina Schimpe <christina.schimpe@intel.com> 74313 74314 gdb: Remove workaround for the vCont packet 74315 The workaround for the vCont packet is no longer required due to the 74316 former commit "gdb: Make global feature array a per-remote target array". 74317 The vCont packet is now checked once when the connection is started and 74318 the supported vCont actions are set to the target's remote state 74319 attribute. 74320 743212023-01-30 Christina Schimpe <christina.schimpe@intel.com> 74322 74323 gdb: Add per-remote target variables for memory read and write config 74324 This patch adds per-remote target variables for the configuration of 74325 memory read- and write packet size. It is a further change to commit 74326 "gdb: Make global feature array a per-remote target array" to apply the 74327 fixme notes described in commit 5b6d1e4 "Multi-target support". 74328 74329 The former global variables for that configuration are still available 74330 to allow the command line configuration for all future remote 74331 connections. Similar to the command line configuration of the per- 74332 remote target feature array, the commands 74333 74334 - set remotewritesize (deprecated) 74335 - set remote memory-read-packet-size 74336 - set remote memory-write-packet-size 74337 74338 will configure the current target (if available). If no target is 74339 available, the default configuration for future remote connections is 74340 adapted. The show command will display the current remote target's 74341 packet size configuration. If no remote target is selected, the default 74342 configuration for future connections will be shown. 74343 74344 It is required to adapt the test gdb.base/remote.exp which is failing 74345 for --target_board=native-extended-gdbserver. With that board GDB 74346 connects to gdbserver at gdb start time. Due to this patch two loggings 74347 "The target may not be able to.." are shown if the command 'set remote 74348 memory-write-packet-size fixed' is executed while a target is connected 74349 for the current inferior. To fix this, the clean_restart command is 74350 moved to a later time point of the test. It is sufficient to be 74351 connected to the server when "runto_main" is executed. Now the 74352 connection time is similar to a testrun with 74353 --target_board=native-gdbserver. 74354 74355 To allow the user to distinguish between the packet-size configuration 74356 for future remote connections and for the currently selected target, the 74357 commands' loggings are adapted. 74358 743592023-01-30 Christina Schimpe <christina.schimpe@intel.com> 74360 74361 gdb: Make global feature array a per-remote target array 74362 This patch applies the appropriate FIXME notes described in commit 5b6d1e4 74363 "Multi-target support". 74364 74365 "You'll notice that remote.c includes some FIXME notes. These refer to 74366 the fact that the global arrays that hold data for the remote packets 74367 supported are still globals. For example, if we connect to two 74368 different servers/stubs, then each might support different remote 74369 protocol features. They might even be different architectures, like 74370 e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a 74371 host/controller scenario as a single program. That isn't going to 74372 work correctly today, because of said globals. I'm leaving fixing 74373 that for another pass, since it does not appear to be trivial, and I'd 74374 rather land the base work first. It's already useful to be able to 74375 debug multiple instances of the same server (e.g., a distributed 74376 cluster, where you have full control over the servers installed), so I 74377 think as is it's already reasonable incremental progress." 74378 74379 Using this patch it is possible to configure per-remote targets' 74380 feature packets. 74381 74382 Given the following setup for two gdbservers: 74383 74384 ~~~~ 74385 gdbserver --multi :1234 74386 gdbserver --disable-packet=vCont --multi :2345 74387 ~~~~ 74388 74389 Before this patch configuring of range-stepping was not possible for one 74390 of two connected remote targets with different support for the vCont 74391 packet. As one of the targets supports vCont, it should be possible to 74392 configure "set range-stepping". However, the output of GDB looks like: 74393 74394 (gdb) target extended-remote :1234 74395 Remote debugging using :1234 74396 (gdb) add-inferior -no-connection 74397 [New inferior 2] 74398 Added inferior 2 74399 (gdb) inferior 2 74400 [Switching to inferior 2 [<null>] (<noexec>)] 74401 (gdb) target extended-remote :2345 74402 Remote debugging using :2345 74403 (gdb) set range-stepping on 74404 warning: Range stepping is not supported by the current target 74405 (gdb) inferior 1 74406 [Switching to inferior 1 [<null>] (<noexec>)] 74407 (gdb) set range-stepping on 74408 warning: Range stepping is not supported by the current target 74409 ~~~~ 74410 74411 Two warnings are shown. The warning for inferior 1 should not appear 74412 as it is connected to a target supporting the vCont package. 74413 74414 ~~~~ 74415 (gdb) target extended-remote :1234 74416 Remote debugging using :1234 74417 (gdb) add-inferior -no-connection 74418 [New inferior 2] 74419 Added inferior 2 74420 (gdb) inferior 2 74421 [Switching to inferior 2 [<null>] (<noexec>)] 74422 (gdb) target extended-remote :2345 74423 Remote debugging using :2345 74424 (gdb) set range-stepping on 74425 warning: Range stepping is not supported by the current target 74426 (gdb) inferior 1 74427 [Switching to inferior 1 [<null>] (<noexec>)] 74428 (gdb) set range-stepping on 74429 (gdb) 74430 ~~~~ 74431 74432 Now only one warning is shown for inferior 2, which is connected to 74433 a target not supporting vCont. 74434 74435 The per-remote target feature array is realized by a new class 74436 remote_features, which stores the per-remote target array and 74437 provides functions to determine supported features of the target. 74438 A remote_target object now has a new member of that class. 74439 74440 Each time a new remote_target object is initialized, a new per-remote 74441 target array is constructed based on the global remote_protocol_packets 74442 array. The global array is initialized in the function _initialize_remote 74443 and can be configured using the command line. Before this patch the 74444 command line configuration affected current targets and future remote 74445 targets (due to the global feature array used by all remote 74446 targets). This behavior is different and the configuration applies as 74447 follows: 74448 74449 - If a target is connected, the command line configuration affects the 74450 current connection. All other existing remote targets are not 74451 affected. 74452 74453 - If not connected, the command line configuration affects future 74454 connections. 74455 74456 The show command displays the current remote target's configuration. If no 74457 remote target is selected the default configuration for future 74458 connections is shown. 74459 74460 If we have for instance the following setup with inferior 2 being 74461 selected: 74462 ~~~~ 74463 (gdb) info inferiors 74464 Num Description Connection Executable 74465 1 <null> 1 (extended-remote :1234) 74466 * 2 <null> 2 (extended-remote :2345) 74467 ~~~~ 74468 74469 Before this patch, if we run 'set remote multiprocess-feature-packet', the 74470 following configuration was set: 74471 The feature array of all remote targets (in this setup the two connected 74472 targets) and all future remote connections are affected. 74473 74474 After this patch, it will be configured as follows: 74475 The feature array of target with port :2345 which is currently selected 74476 will be configured. All other existing remote targets are not affected. 74477 The show command 'show remote multiprocess-feature-packet' will display 74478 the configuration of target with port :2345. 74479 74480 Due to this configuration change, it is required to adapt the test 74481 "gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the 74482 multiprocess-feature-packet before the connections are created. 74483 74484 To inform the gdb user about the new behaviour of the 'show remote 74485 PACKET-NAME' commands and the new configuration impact for remote 74486 targets using the 'set remote PACKET-NAME' commands the commands' 74487 outputs are adapted. Due to this change it is required to adapt each 74488 test using the set/show remote 'PACKET-NAME' commands. 74489 744902023-01-30 GDB Administrator <gdbadmin@sourceware.org> 74491 74492 Automatic date update in version.in 74493 744942023-01-29 GDB Administrator <gdbadmin@sourceware.org> 74495 74496 Automatic date update in version.in 74497 744982023-01-28 GDB Administrator <gdbadmin@sourceware.org> 74499 74500 Automatic date update in version.in 74501 745022023-01-27 Tom Tromey <tromey@adacore.com> 74503 74504 More const-correctness in cooked indexer 74505 I noticed that iterating over the index yields non-const 74506 cooked_index_entry objects. However, after finalization, they should 74507 not be modified. This patch enforces this by adding const where 74508 needed. 74509 74510 v2 makes the find, all_entries, and wait methods const as well. 74511 745122023-01-27 Tom de Vries <tdevries@suse.de> 74513 74514 [gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp.tcl 74515 Recent commit 1d98e564c97 ("[gdb/testsuite] Add 74516 gdb.base/unwind-on-each-insn-{amd64,i386}.exp") broke commit eb015bf86b6 74517 ("[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp"), 74518 in the sense that gdb.base/unwind-on-each-insn.exp no longer uses 74519 -fno-asynchronous-unwind-tables, due to trying to concatenate two lists using: 74520 ... 74521 lappend srcfile2_flags $nodebug_flags 74522 ... 74523 which should instead be: 74524 ... 74525 lappend srcfile2_flags {*}$nodebug_flags 74526 ... 74527 74528 Fix this by simplifying gdb.base/unwind-on-each-insn.exp.tcl, completely 74529 leaving the responsibility to set srcfile_flags and srcfile2_flags to each 74530 includer. 74531 74532 Tested on x86_64-linux. 74533 745342023-01-27 Tom Tromey <tromey@adacore.com> 74535 74536 Invert test in gdb.ada/ptype_tagged_param.exp 74537 Simon pointed out that the kfail check in 74538 gdb.ada/ptype_tagged_param.exp is inverted. See: 74539 74540 https://sourceware.org/pipermail/gdb-patches/2023-January/196296.html 74541 74542 This patch fixes the problem. 74543 745442023-01-27 Andrew Burgess <aburgess@redhat.com> 74545 74546 gdb/tui: more debug output 74547 Add some additional debug output that I've found really useful while 74548 working on the previous set of patches. 74549 74550 Unless tui debug is turned on, then there should be no user visible 74551 changes with this commit. 74552 745532023-01-27 Andrew Burgess <aburgess@redhat.com> 74554 74555 gdb/tui: avoid extra refresh_window on vertical scroll 74556 While working on the previous couple of patches I noticed that when I 74557 scroll the src and asm windows vertically, I get two refresh_window 74558 calls. 74559 74560 The two calls can be traced back to 74561 tui_source_window_base::update_source_window_as_is, in here we call 74562 show_source_content, which calls refresh_window, and then 74563 update_exec_info, which also calls refresh_window. 74564 74565 In this commit I propose making the refresh_window call in 74566 update_exec_info optional. In update_source_window_as_is I'll then 74567 call update_exec_info before calling show_source_content, and pass a 74568 flag to update_exec_info to defer the refresh. 74569 74570 There are places where update_exec_info is used without any subsequent 74571 refresh_window call (e.g. when a breakpoint is updated), so 74572 update_exec_info does not to call refresh_window in some cases, which 74573 is why I'm using a flag to control the refresh. 74574 74575 With this changes I'm now only seeing a single refresh_window call for 74576 each vertical scroll. 74577 74578 There should be no user visible changes after this commit. 74579 745802023-01-27 Andrew Burgess <aburgess@redhat.com> 74581 74582 gdb/tui: avoid extra refresh_window on horizontal scroll 74583 While working on the previous patches I noticed that in some cases I 74584 was seeing two calls to tui_source_window_base::refresh_window when 74585 scrolling the window horizontally. 74586 74587 The two calls would trigger in for the tui-disasm-long-lines.exp test 74588 when the pad needed to be refilled. The two called both come from 74589 tui_source_window_base::show_source_content. The first call is nested 74590 within check_and_display_highlight_if_needed, while the second call is 74591 done directly at the end of show_source_content. 74592 74593 The check_and_display_highlight_if_needed is being used to draw the 74594 window box to the window, this is needed here because 74595 show_source_content is what gets called when the window needs 74596 updating, e.g. after a resize. We could potentially do the boxing in 74597 refresh_window, but then we'd be doing it each time we scroll, even 74598 though the box doesn't need changing in this case. 74599 74600 However, we can move the check_and_display_highlight_if_needed to be 74601 the last thing done in show_source_content, this means that we can 74602 rely on the refresh_window call within it to be our single refresh 74603 call. 74604 74605 There should be no user visible changes after this commit. 74606 746072023-01-27 Andrew Burgess <aburgess@redhat.com> 74608 74609 gdb/tui: rewrite of tui_source_window_base to handle very long lines 74610 This commit addresses an issue that is exposed by the test script 74611 gdb.tui/tui-disasm-long-lines.exp, that is, tui_source_window_base 74612 does not handle very long lines. 74613 74614 The problem can be traced back to the newpad call in 74615 tui_source_window_base::show_source_content, this is where we allocate 74616 a backing pad to hold the window content. 74617 74618 Unfortunately, there appears to be a limit to the size of pad that can 74619 be allocated, and the gdb.tui/tui-disasm-long-lines.exp test goes 74620 beyond this limit. As a consequence the newpad call fails and returns 74621 nullptr. 74622 74623 It just so happens that the reset of the tui_source_window_base code 74624 can handle the pad being nullptr (this happens anyway when the window 74625 is first created, so we already depend on nullptr handling), so all 74626 that happens is the source window displays no content. 74627 74628 ... well, sort of ... something weird does happen in the command 74629 window, we seem to see a whole bunch of blank lines. I've not 74630 bothered to track down exactly what's happening there, but it's some 74631 consequence of GDB attempting to write content to a WINDOW* that is 74632 nullptr. 74633 74634 Before explaining my solution, I'll outline how things currently work: 74635 74636 Consider we have the following window content to display: 74637 74638 aaaaaaaaaa 74639 bbbbbbbbbbbbbbbbbbbb 74640 ccccccccccccccc 74641 74642 the longest line here is 20 characters. If our display window is 10 74643 characters wide, then we will create a pad that is 20 characters wide, 74644 and then copy the lines of content into the pad: 74645 74646 .--------------------. 74647 |aaaaaaaaaa | 74648 |bbbbbbbbbbbbbbbbbbbb| 74649 |ccccccccccccccc | 74650 .--------------------. 74651 74652 Now we will copy a 10 character wide view into this pad to the 74653 display, our display will then see: 74654 74655 .----------. 74656 |aaaaaaaaaa| 74657 |bbbbbbbbbb| 74658 |cccccccccc| 74659 .----------. 74660 74661 As the user scrolls left and right we adjust m_horizontal_offset and 74662 use this to select which part of the pad is copied onto the display. 74663 74664 The benefit of this is that we only need to copy the content to the 74665 pad once, which includes processing the ansi escape sequences, and 74666 then the user can scroll left and right as much as they want 74667 relatively cheaply. 74668 74669 The problem then, is that if the longest content line is very long, 74670 then we try to allocate a very large pad, which can fail. 74671 74672 What I propose is that we allow both the pad and the display view to 74673 scroll. Once we allow this, then it becomes possible to allocate a 74674 pad that is smaller than the longest display line. We then copy part 74675 of the content into the pad. As the user scrolls the view left and 74676 right GDB will continue to copy content from the pad just as it does 74677 right now. But, when the user scrolls to the edge of the pad, GDB 74678 will copy a new block of content into the pad, and then update the 74679 view as normal. This all works fine so long as the maximum pad size 74680 is larger than the current window size - which seems a reasonable 74681 restriction, if ncurses can't support a pad of a given size it seems 74682 likely it will not support a display window of that size either. 74683 74684 If we return to our example above, but this time we assume that the 74685 maximum pad size is 15 characters, then initially the pad would be 74686 loaded like this: 74687 74688 .---------------. 74689 |aaaaaaaaaa | 74690 |bbbbbbbbbbbbbbb| 74691 |ccccccccccccccc| 74692 .---------------. 74693 74694 Notice that the last 5 characters from the 'b' line are no longer 74695 included in the pad. There is still enough content though to fill the 74696 10 character wide display, just as we did before. 74697 74698 The pad contents remain unchanged until the user scrolls the display 74699 right to this point: 74700 74701 .----------. 74702 |aaaaa | 74703 |bbbbbbbbbb| 74704 |cccccccccc| 74705 .----------. 74706 74707 Now, when the user scrolls right once more GDB spots that the user has 74708 reached the end of the pad, and the pad contents are reloaded, like 74709 this: 74710 74711 .---------------. 74712 |aaaaa | 74713 |bbbbbbbbbbbbbbb| 74714 |cccccccccc | 74715 .---------------. 74716 74717 The display can now be updated from the pad again just like normal. 74718 74719 With this change in place the gdb.tui/tui-disasm-long-lines.exp test 74720 now correctly loads the assembler code, and we can scroll around as 74721 expected. 74722 74723 Most of the changes are pretty mundane, just updating to match the 74724 above. One interesting change though is the new member function 74725 tui_source_window_base::puts_to_pad_with_skip. This replaces direct 74726 calls to tui_puts when copying content to the pad. 74727 74728 The content strings contain ansi escape sequences. When these strings 74729 are written to the pad these escape sequences are translated into 74730 ncurses attribute setting calls. 74731 74732 Now however, we sometimes only write a partial string to the pad, 74733 skipping some of the leading content. Imagine then that we have a 74734 content line like this: 74735 74736 "\033[31mABCDEFGHIJKLM\033[0m" 74737 74738 Now the escape sequences in this content mean that the actual 74739 content (the 'ABCDEFGHIJKLM') will have a red foreground color. 74740 74741 If we want to copy this to the pad, but skip the first 3 characters, 74742 then what we expect is to have the pad contain 'DEFGHIJKLM', but this 74743 text should still have a red foreground color. 74744 74745 It is this problem that puts_to_pad_with_skip solves. This function 74746 skips some number of printable characters, but processes all the 74747 escape sequences. This means that when we do start printing the 74748 actual content the content will have the expected attributes. 74749 / 74750 747512023-01-27 Andrew Burgess <aburgess@redhat.com> 74752 74753 gdb/tui: make m_horizontal_offset private 74754 I noticed that tui_source_window_base::m_horizontal_offset was 74755 protected, but could be made private, so lets do that. 74756 74757 This makes more sense in the context of a later commit where I plan to 74758 add another member variable that is similar to m_horizontal_offset. 74759 The new member variable could also be private. 74760 74761 So I had to choose, place the new member variable next to 74762 m_horizontal_offset making it protected, but grouping similar 74763 variables together, or make m_horizontal_offset private, and then add 74764 the new variable as private too. 74765 74766 I chose to make m_horizontal_offset private, which is this commit. 74767 74768 There should be no user visible changes after this commit. 74769 747702023-01-27 Andrew Burgess <aburgess@redhat.com> 74771 74772 gdb/tui: disable tui mode when an assert triggers 74773 When an assert triggers in tui mode the output is not great, the 74774 internal backtrace that is generated is printed directly to the file 74775 descriptor for gdb_stderr, and, as a result, does not currently format 74776 itself correctly - the output uses only '\n' at the end of each line, 74777 and so, when the terminal is in raw mode, the cursor does not return 74778 to the start of each line after the '\n'. 74779 74780 This is mostly fixable, we could update bt-utils.c to use '\r\n' 74781 instead of just '\n', and this would fix most of the problems. The 74782 one we can't easily fix is if/when GDB is built to use execinfo 74783 instead of libbacktrace, in this case we use backtrace_symbols_fd to 74784 print the symbols, and this function only uses '\n' as the line 74785 terminator. Fixing this would require switching to backtrace_symbols, 74786 but that API uses malloc, which is something we're trying to 74787 avoid (this code is called when GDB hits an error, so ideally we don't 74788 want to rely on malloc). 74789 74790 However, the execinfo code is only used when libbacktrace is not 74791 available (or the user specifically disables libbacktrace) so maybe we 74792 can ignore that problem... 74793 74794 ... but there is another problem. When the backtrace is printed in 74795 raw mode, it is possible that the backtrace fills the screen. With 74796 the terminal in raw mode we don't have the ability to scroll back, 74797 which means we loose some of the backtrace, which isn't ideal. 74798 74799 In this commit I propose that we should disable tui mode whenever we 74800 handle a fatal signal, or when we hit the internal error code 74801 path (e.g. when an assert triggers). With this done then we don't 74802 need to update the bt-utils.c code, and the execinfo version of the 74803 code (using backtrace_symbols_fd) works just fine. We also get the 74804 ability to scroll back to view the error message and all of the 74805 backtrace, assuming the users terminal supports scrolling back. 74806 74807 The only downside I see with this change is if the tui_disable call 74808 itself causes an error for some reason, or, if we handle a single at a 74809 time when it is not safe to call tui_disable, in these cases the extra 74810 tui_disable call might cause GDB to loose the original error. 74811 74812 However, I think (just from personal experience) that the above two 74813 issues are pretty rare and the benefits from this change far out 74814 weighs the possible drawbacks. 74815 748162023-01-27 Andrew Burgess <aburgess@redhat.com> 74817 74818 gdb/tui: improve errors from tui focus command 74819 This commit improves (I think) the errors from the tui focus command. 74820 There are a number of errors that can be triggered by the focus 74821 command, they include: 74822 74823 (1) Window name "NAME" is ambiguous 74824 74825 (2) Unrecognized window name "NAME" 74826 74827 (3) Window "NAME" cannot be focused 74828 74829 Error (1) is triggered when the user gives a partial window name, and 74830 the name matches multiple windows in the current layout. 74831 74832 It is worth noting that the ambiguity must be within the current 74833 layout; if the partial name matches one window in the current layout, 74834 and one or more windows not in the current layout, then this is not 74835 ambiguous, and focus will shift to the matching window in the current 74836 layout. 74837 74838 This error was not previous being tested, but in this commit I make 74839 use of the Python API to trigger and test this error. 74840 74841 Error (3) is simple enough, and was already being tested. This is 74842 triggered by something like 'focus status'. The named window needs to 74843 be present in the current layout, and non-focusable in order to 74844 trigger the error. 74845 74846 Error (2) is what I'd like to improve in this commit. This error 74847 triggers if the name the user gives doesn't match any window in the 74848 current layout. Even if GDB does know about the window, but the 74849 window isn't in the current layout, then GDB will say it doesn't 74850 recognize the window name. 74851 74852 In this commit I propose to to split this error into three different 74853 errors. These will be: 74854 74855 (a) Unrecognized window name "NAME" 74856 74857 (b) No windows matching "NAME" in the current layout 74858 74859 (c) Window "NAME" is not in the current layout 74860 74861 Error (a) is the same as before, but will now only trigger if GDB 74862 doesn't know about window NAME at all. If the window is known, but 74863 not in the current layout then one of the other errors will trigger. 74864 74865 Error (b) will trigger if NAME is ambiguous for multiple windows that 74866 are not in the current layout. If NAME identifies a single window in 74867 the current layout then that window will continue to be selected, just 74868 as it currently is. Only in the case where NAME doesn't identify a 74869 window in the current layout do we then check all the other known 74870 windows, if NAME matches multiple of these, then (b) is triggered. 74871 74872 Finally, error (c) is used when NAME uniquely identifies a single 74873 window that is not in the current layout. 74874 74875 The hope with these new errors is that the user will have a better 74876 understanding of what went wrong. Instead of GDB claiming to not know 74877 about a window, the mention of the current layout will hint to the 74878 user that they should first switch layouts. 74879 74880 There are tests included for all the new errors. 74881 748822023-01-27 Andrew Burgess <aburgess@redhat.com> 74883 74884 gdb/testsuite: fix line feed scrolling in tuiterm.exp 74885 In a following commit I managed to trigger the line feed scrolling 74886 case in tuiterm.exp. This case is currently unhandled, and this 74887 commit fills in this missing functionality. 74888 74889 The implementation is pretty simple, just scroll all the content up 74890 one line at a time until the cursor is back on the screen (a single 74891 line of scroll is all that should be needed). 74892 74893 This change is untested in this commit, but is required by the next 74894 commit. 74895 748962023-01-27 Nick Clifton <nickc@redhat.com> 74897 74898 Another fix for EFI generation with LTO enabled. 74899 PR 29998 * pe-dll.c (build_filler_bfd): Initialise the next field of the filler input statement, so that it does not break the file chain. 74900 749012023-01-27 Jan Beulich <jbeulich@suse.com> 74902 74903 x86: move reg_operands adjustment 74904 Ideally we'd do away with this somewhat questionable adjustment (leaving 74905 i.types[] untouched). That's non-trivial though as it looks, so only 74906 - move the logic into process_operands(), putting it closer to related 74907 logic and eliminating a conditional for operand-less insns, 74908 - make it consistent (i.e. also affect %xmm0), eliminating an ugly 74909 special case later in the function. 74910 74911 x86: drop dead SSE2AVX-related code 74912 All (there are just two) SSE2AVX templates with %xmm0 as first operand 74913 also specify VEX3SOURCES. Hence there's no need for an "else" to the 74914 respective if(), and the if() itself can become an assertion. 74915 74916 x86: use ModR/M for FPU insns with operands 74917 This is the correct way of expressing things; encoding the ModR/M byte 74918 directly in base_opcode has always been bogus. 74919 74920 x86/Intel: improve special casing of certain insns 74921 Now that we have identifiers for the mnemonic strings we can avoid 74922 opcode based comparisons, for (in many cases) being more expensive and 74923 (in a few cases) being a little fragile and not self-documenting. 74924 749252023-01-27 Jan Beulich <jbeulich@suse.com> 74926 74927 opcodes: suppress internationalization on build helper tools 74928 While one of the two actually having been instrumented (i386-gen.c) now 74929 has that instrumentation dropped, there's still no point in honoring 74930 such instrumentation in general (i.e. now for ia64-gen.c only), as that 74931 only leads to a waste of resources. 74932 74933 With CFILES then being merely an alias of LIBOPCODES_CFILES, drop the 74934 former variable altogether. 74935 749362023-01-27 Jan Beulich <jbeulich@suse.com> 74937 74938 x86: remove internationalization from i386-gen.c 74939 This is a build time helper utility, which doesn't require translation. 74940 749412023-01-27 Alan Modra <amodra@gmail.com> 74942 74943 Call bfd_close_all_done in ld_cleanup 74944 This is similar to "Call bfd_close_all_done in output_file_close", 74945 but with some code tidying in the pe/pep write_build_id functions. 74946 write_build_id is passed the output bfd as its parameter, so there is 74947 no need to go looking for the output bfd via link_info (and doing so 74948 will no longer work since I clear link_info.output_bfd before calling 74949 bfd_close). 74950 74951 * emultempl/pe.em (write_build_id): Rename t to td. Formatting. 74952 Don't access pe_data(link_info.output_bfd), use td instead. 74953 (setup_build_id): Rename t to td. Formatting. 74954 * emultempl/pep.em: As for pe.em. 74955 * ldmain.c (ld_cleanup): Call bfd_close_all_done on linker bfds. 74956 (main): Clear link_info.output_bfd when closing. 74957 749582023-01-27 Alan Modra <amodra@gmail.com> 74959 74960 Perform cleanup in bfd_close after errors 74961 It seems reasonable to continue after errors in bfd_close_all_done, 74962 particularly since bfd_close_all_done is typically called on an output 74963 file after we've hit some sort of error elsewhere. The iovec test is 74964 necessary if bfd_close_all_done is to work on odd bfd's opened by 74965 bfd_create. 74966 74967 * opncls.c (bfd_close): Call bfd_close_all_done after errors 74968 from _bfd_write_contents. 74969 (bfd_close_all_done): Call _bfd_delete_bfd after errors. 74970 Don't call iovec->bclose when iovec is NULL. 74971 749722023-01-27 Alan Modra <amodra@gmail.com> 74973 74974 Call bfd_close_all_done in output_file_close 74975 bfd_cache_close_all is good for closing file descriptors, but doesn't 74976 do the cleanup of bfd memory as in bfd_close_all_done. 74977 74978 PR 13056 74979 * output-file.c (output_file_close): Call bfd_close_all_done, 74980 not bfd_cache_close_all. 74981 749822023-01-27 Alan Modra <amodra@gmail.com> 74983 74984 gas macro memory leaks 74985 This tidies memory allocated for entries in macro_hash. Freeing the 74986 macro name requires a little restructuring of the define_macro 74987 interface due to the name being used in the error message, and exposed 74988 the fact that the name and other fields were not initialised by the 74989 iq2000 backend. 74990 74991 There is also a fix for 74992 .macro .macro 74993 .endm 74994 .macro .macro 74995 .endm 74996 which prior to this patch reported 74997 mac.s:1: Warning: attempt to redefine pseudo-op `.macro' ignored 74998 mac.s:3: Error: Macro `.macro' was already defined 74999 rather than reporting the attempt to redefine twice. 75000 75001 * macro.c (macro_del_f): New function. 75002 (macro_init): Use it when creating macro_hash. 75003 (free_macro): Free macro name too. 75004 (define_macro): Return the macro_entry, remove idx, file, line and 75005 namep params. Call as_where. Report errors here. Delete macro 75006 from macro_hash on attempt to redefined pseudo-op. 75007 (delete_macro): Don't call free_macro. 75008 * macro.h (define_macro): Update prototype. 75009 * read.c (s_macro): Adjust to suit. 75010 * config/tc-iq2000.c (iq2000_add_macro): Init all fields of 75011 macro_entry. 75012 750132023-01-27 Mark Harmstone <mark@harmstone.com> 75014 75015 gas/testsuite: Add -gcodeview test for aarch64-w64-mingw32 75016 This is a copy of the x86 gas -gcodeview test, with changes made for the 75017 differing instruction lengths between x86 and aarch64. 75018 75019 gas: Add CodeView constant for aarch64 75020 Adds the correct constant to the S_COMPILE3 CodeView record when 75021 assembling aarch64-w64-mingw32 with the -gcodeview flag. 75022 750232023-01-27 Tom Tromey <tom@tromey.com> 75024 75025 Use clean_restart in gdb.base 75026 Change gdb.base to use clean_restart more consistently. 75027 75028 Use clean_restart in gdb.python 75029 Change gdb.python to use clean_restart more consistently. 75030 75031 Use clean_restart in gdb.cp 75032 Change gdb.cp to use clean_restart more consistently. 75033 75034 Use clean_restart in gdb.disasm 75035 Change gdb.disasm to use clean_restart more consistently. 75036 75037 Use clean_restart in gdb.perf 75038 Change gdb.perf to use clean_restart more consistently. 75039 75040 Use clean_restart in gdb.go 75041 Change gdb.go to use clean_restart more consistently. 75042 75043 Use clean_restart in gdb.stabs 75044 Change gdb.stabs to use clean_restart more consistently. 75045 75046 Use clean_restart in gdb.fortran 75047 Change gdb.fortran to use clean_restart more consistently. 75048 75049 Use clean_restart in gdb.ada 75050 Change gdb.ada to use clean_restart more consistently. 75051 75052 Use clean_restart in gdb.dwarf2 75053 Change gdb.dwarf2 to use clean_restart more consistently. 75054 75055 Use clean_restart in gdb.reverse 75056 Change gdb.reverse to use clean_restart more consistently. 75057 75058 Use clean_restart in gdb.arch 75059 Change gdb.arch to use clean_restart more consistently. 75060 75061 Use clean_restart in gdb.guile 75062 Change gdb.guile to use clean_restart more consistently. 75063 75064 Use clean_restart in gdb.threads 75065 Change gdb.threads to use clean_restart more consistently. 75066 75067 Use clean_restart in gdb.objc 75068 Change gdb.objc to use clean_restart more consistently. 75069 75070 Use clean_restart in gdb.trace 75071 Change gdb.trace to use clean_restart more consistently. 75072 75073 Use clean_restart in gdb.opencl 75074 Change gdb.opencl to use clean_restart more consistently. 75075 75076 Use clean_restart in gdb.linespec 75077 Change gdb.linespec to use clean_restart more consistently. 75078 75079 Use clean_restart in gdb.pascal 75080 Change gdb.pascal to use clean_restart more consistently. 75081 75082 Use mi_clean_restart more 75083 This changes a number of MI tests to use mi_clean_restart rather than 75084 separate calls. This reduces the number of lines, which is nice, and 75085 also provides a nicer model to copy for future tests. 75086 75087 Start gdb after building executable in mi-basics.exp 75088 A lot of the MI tests start gdb and only then build the executable. 75089 This just seemed weird to me, so I've fixed this up. In this patch, 75090 no other cleanups are done, the startup is just moved to a more 75091 logical (to me) spot. 75092 75093 Remove unnecessary call to standard_testfile 75094 This test does not build a program and does not need to call 75095 standard_testfile. 75096 75097 Minor "require" fixups 75098 I found a couple of spots that could use "require", and one spot where 75099 hoisting the "require" closer to the top of the file made it more 75100 clear. 75101 751022023-01-27 Tom Tromey <tom@tromey.com> 75103 75104 Remove some dead code in gdb.fortran/info-types.exp 75105 An early "return" in this test case prevents a test from running. 75106 This seems to have been intentional and has been in place since: 75107 75108 commit d57cbee932f86df06251498daa93154046dc77c0 75109 Author: Andrew Burgess <andrew.burgess@embecosm.com> 75110 Date: Tue Dec 3 13:18:43 2019 +0000 75111 75112 gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+ 75113 75114 This patch removes the dead code. 75115 751162023-01-27 Tom Tromey <tom@tromey.com> 75117 75118 Eliminate spurious returns from the test suite 75119 A number of tests end with "return". However, this is unnecessary. 75120 This patch removes all of these. 75121 75122 Use clean_restart in gdb.dlang 75123 Change gdb.dlang to use clean_restart more consistently. 75124 75125 Use ordinary calling convention for clean_restart 75126 clean_restart accepts a single optional argument. Rather than using 75127 {args} and handling the argument by hand, change it to use Tcl's own 75128 argument-checking. 75129 751302023-01-27 GDB Administrator <gdbadmin@sourceware.org> 75131 75132 Automatic date update in version.in 75133 751342023-01-26 Alan Modra <amodra@gmail.com> 75135 75136 Free gas/dwarf2dbg.c dirs 75137 Entries are allocated with xmemdup0. 75138 75139 * dwarf2dbg.c (dwarf2_cleanup): Free dirs entries. 75140 751412023-01-26 Alan Modra <amodra@gmail.com> 75142 75143 Sanity check dwarf5 form of .file 75144 There's a comment a few lines earlier saying that demand_copy_C_string 75145 has already reported an error if it returns NULL. Given the proximity 75146 I decided not to duplicate the comment. 75147 75148 * dwarf2dbg.c (dwarf2_directive_filename): Check return of 75149 demand_copy_C_string for file. 75150 751512023-01-26 Alan Modra <amodra@gmail.com> 75152 75153 resolve gas shift expressions with large exponents to zero 75154 * expr.c (resolve_expression <O_left_shift, O_right_shift>): Resolve 75155 shifts exceeding bits in a valueT to zero. 75156 75157 segv in coff_aarch64_addr32nb_reloc 75158 * coff-aarch64.c (coff_aarch64_addr32nb_reloc): When output_bfd 75159 is NULL (which it is for objdump -W) get the output bfd via the 75160 input section. 75161 751622023-01-26 Simon Marchi <simon.marchi@efficios.com> 75163 75164 gdb/testsuite: initialize "correct" variable in gdb.cp/cpexprs.exp.tcl 75165 Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB 75166 crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to 75167 read the string, at gdb.cp/cpexprs.exp.tcl:725. The "correct" variable 75168 doesn't get set, and I then see this TCL error: 75169 75170 ERROR: can't read "correct": no such variable 75171 75172 Avoid the TCL error by initializing the "correct" variable to a dummy 75173 value. 75174 75175 Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059 75176 751772023-01-26 Simon Marchi <simon.marchi@efficios.com> 75178 75179 gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE 75180 Prior to this patch, I get: 75181 75182 >>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}} 75183 Content-Length: 147 75184 75185 {"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success 75186 FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output 75187 75188 The problem is that the PC to disassemble is taken from the breakpoint 75189 insertion response, which happens before running. With a PIE 75190 executable, that PC is unrelocated, but the disassembly request happens 75191 after relocation. 75192 75193 I chose to fix this by watching for a breakpoint changed event giving 75194 the new breakpoint address, and recording the address from there. I 75195 think this is an interesting way to fix it, because it adds a bit of 75196 test coverage, I don't think these events are checked right now. 75197 75198 Other ways to fix it would be: 75199 75200 - Get the address by doing a breakpoint insertion after the program is 75201 started, or some other way. 75202 - Do the disassembly by symbol instead of by address. 75203 - Do the disassembly before running the program. 75204 75205 Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e 75206 752072023-01-26 Simon Marchi <simon.marchi@efficios.com> 75208 75209 gdb/testsuite/dap: make dap_wait_for_event_and_check return preceding messages 75210 In the following patch, I change gdb.dap/basic-dap.exp such that after 75211 waiting for some event, it checks if it received another event 75212 meanwhile. To help with this, make dap_wait_for_event_and_check and 75213 _dap_dap_wait_for_event return a list with everything received before 75214 the event of interest. This is similar to what 75215 dap_check_request_and_response returns. 75216 75217 Change-Id: I85c8980203a2dec833937e7552c2196bc137935d 75218 752192023-01-26 Simon Marchi <simon.marchi@efficios.com> 75220 75221 gdb/testsuite/dap: rename dap_read_event to dap_wait_for_event_and_check 75222 I think that name describes a bit better what the proc does, it is 75223 similar to "wait_for" in tuiterm.exp. 75224 75225 Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419 75226 752272023-01-26 Simon Marchi <simon.marchi@efficios.com> 75228 75229 gdb/testsuite/dap: pass around dicts instead of TON objects 75230 The DAP helper functions generally return TON objects. However, callers 75231 almost all immediately use ton::2dict to convert them to dicts, to 75232 access their contents. This commits makes things a bit simpler for them 75233 by having function return dicts directly instead. 75234 75235 The downside is that the TON objects contain type information. For 75236 instance, a "2" in a TCL dict could have been the integer 2 or the 75237 string "2" in JSON. By converting to TCL dicts, we lose that 75238 information. If some tests specifically want to check the types of some 75239 fields, I think we can add intermediary functions that return TON 75240 objects, without having to complicate other callers who don't care. 75241 75242 Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f 75243 752442023-01-26 Simon Marchi <simon.marchi@efficios.com> 75245 75246 gdb/testsuite/dap: remove catch from dap_read_event 75247 This catch didn't cause me any trouble, but for the same reason as the 75248 preceding patch, I think it's a bit better to just let any exception 75249 propagate, to make for easier debugging. 75250 75251 Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c 75252 752532023-01-26 Simon Marchi <simon.marchi@efficios.com> 75254 75255 gdb/testsuite/dap: make dap_request_and_response not catch / issue test result 75256 Following some of my changes, dap_request_and_response was failing and I 75257 didn't know why. I think it's better to make it not catch any 75258 exception, and just make it do a simple "send request, read response". 75259 If an exception is thrown while sending a request or reading a response, 75260 things are going really badly, it's not like we'll want to recover from 75261 that and continue the test. 75262 75263 Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356 75264 752652023-01-26 Simon Marchi <simon.marchi@efficios.com> 75266 75267 gdb/testsuite/dap: write requests to gdb.log 75268 This helps following what happens when reading gdb.log. The downside is 75269 that it becomes harder to tell what text is from GDB and what text is 75270 going to GDB, but I think that seeing responses without seeing requests 75271 is even more confusing. At least, the lines are prefix with >>>, so 75272 when you see this, you know that until the end of the line, it's 75273 something that was sent to GDB, and not GDB output. 75274 75275 Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874 75276 752772023-01-26 Simon Marchi <simon.marchi@efficios.com> 75278 75279 gdb/testsuite/dap: prefix some procs with _ 75280 Prefix some procs that are only used internally with an underscore, to 75281 make it clear they are internal. If they need to be used by some test 75282 later, we can always un-prefix them. 75283 75284 Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d 75285 752862023-01-26 Simon Marchi <simon.marchi@efficios.com> 75287 75288 gdb/testsuite/dap: use gdb_assert in gdb.dap/basic-dap.exp 75289 Use gdb_assert instead of manual pass/fail. 75290 75291 Change-Id: I71fbc4e37a0a1ef4783056c7424e932651fa397f 75292 752932023-01-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 75294 75295 gprofng: PR30043 libgprofng.so.* are installed to a wrong location 75296 gprofng/ChangeLog 75297 2023-01-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 75298 75299 PR gprofng/30043 75300 PR gprofng/28972 75301 * src/Makefile.am: Use lib_LTLIBRARIES instead of pkglib_LTLIBRARIES. 75302 * src/Makefile.in: Rebuild. 75303 753042023-01-26 Tom de Vries <tdevries@suse.de> 75305 75306 [gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.exp 75307 The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in 75308 the epilogue was inaccurate. 75309 75310 In order to work around this in gdb, epilogue unwinders were added with a 75311 higher priority than the dwarf unwinders in the amd64 and i386 targets: 75312 - amd64_epilogue_frame_unwind, and 75313 - i386_epilogue_frame_unwind. 75314 75315 Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0. 75316 75317 However, the epilogue unwinders prevented gdb from taking advantage of the 75318 fixed epilogue unwind info, so the scope of the epilogue unwinders was 75319 limited, bailing out for gcc >= 4.5.0. 75320 75321 There was no regression test added for this preference scheme, so if we now 75322 declare epilogue unwind info from all gcc versions as trusted, no test will 75323 start failing. 75324 75325 Fix this by adding an amd64 and i386 regression test for this. 75326 75327 I have no gcc 4.4.x lying around, so I fabricated the assembly files by: 75328 - commenting out some .cfi directives to break the epilogue unwind info, and 75329 - hand-editing the producer info to 4.4.7 to activate the fix. 75330 75331 Tested on x86_64-linux, target boards unix/{-m64,-m32}. 75332 753332023-01-26 Tom de Vries <tdevries@suse.de> 75334 75335 [gdb/testsuite] Add and use is_x86_64_m64_target 75336 Add new proc is_x86_64_m64_target and use it where appropriate. 75337 75338 Tested on x86_64-linux. 75339 753402023-01-26 GDB Administrator <gdbadmin@sourceware.org> 75341 75342 Automatic date update in version.in 75343 753442023-01-25 Mark Harmstone <mark@harmstone.com> 75345 75346 ld/testsuite: Add missing targets to PDB tests 75347 753482023-01-25 Mark Harmstone <mark@harmstone.com> 75349 75350 ld: Add pdb support to aarch64-w64-mingw32 75351 This extends PDB support to the aarch64 PE targets. 75352 75353 The changes to the test files are just to make it so they can be assembled as 75354 either x86, x86_64, or aarch64, mainly by changing the comment style. 75355 The only actual code change here is in adding the architecture constants 75356 to pdb.c. 75357 753582023-01-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 75359 75360 gdb/arm: Use new dwarf2 function cache 75361 This patch resolves the performance issue reported in pr/29738 by 75362 caching the values for the stack pointers for the inner frame. By 75363 doing so, the impact can be reduced to checking the state and 75364 returning the appropriate value. 75365 753662023-01-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 75367 75368 gdb: dwarf2 generic implementation for caching function data 75369 When there is no dwarf2 data for a register, a function can be called 75370 to provide the value of this register. In some situations, it might 75371 not be trivial to determine the value to return and it would cause a 75372 performance bottleneck to do the computation each time. 75373 75374 This patch allows the called function to have a "cache" object that it 75375 can use to store some metadata between calls to reduce the performance 75376 impact of the complex logic. 75377 75378 The cache object is unique for each function and frame, so if there are 75379 more than one function pointer stored in the dwarf2_frame_cache->reg 75380 array, then the appropriate pointer will be supplied (the type is not 75381 known by the dwarf2 implementation). 75382 75383 dwarf2_frame_get_fn_data can be used to retrieve the function unique 75384 cache object. 75385 dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the 75386 function unique cache object. 75387 753882023-01-25 Tom Tromey <tromey@adacore.com> 75389 75390 Clean up unusual code in mi-cmd-stack.c 75391 I noticed some unusual code in mi-cmd-stack.c. This code is a switch, 75392 where one of the cases appears in the middle of another block. It 75393 seemed cleaner to me to have the earlier case just conditionally fall 75394 through. 75395 753962023-01-25 H.J. Lu <hjl.tools@gmail.com> 75397 75398 i386: Pass -Wl,--no-as-needed to compiler as needed 75399 Pass -Wl,--no-as-needed to linker tests to fix 75400 75401 FAIL: Run pr19031 75402 FAIL: Run got1 75403 FAIL: Undefined weak symbol (-fPIE -no-pie) 75404 FAIL: Undefined weak symbol (-fPIE -pie) 75405 75406 when --as-needed is passed to linker by compiler. 75407 75408 PR ld/30050 75409 * testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler 75410 as needed. 75411 754122023-01-25 Tom Tromey <tom@tromey.com> 75413 75414 Move target check into allow_altivec_tests 75415 Pedro pointed out that only PPC can possibly have altivec, so we can 75416 move the target check into allow_altivec_tests. 75417 75418 Use require with is_remote 75419 This changes some tests to use require with 'is_remote', rather than 75420 an explicit test. This adds uniformity helps clean up more spots 75421 where a test might exit early without any notification. 75422 754232023-01-25 Tom Tromey <tom@tromey.com> 75424 75425 Add unsupported calls where needed 75426 A number of tests will exit early without saying why. This patch adds 75427 "unsupported" at spots like this that I could readily find. 75428 75429 There are definitely more of these; for example dw2-ranges.exp fails 75430 silently because a compilation fails. I didn't attempt to address 75431 these as that is a much larger task. 75432 754332023-01-25 Tom Tromey <tom@tromey.com> 75434 75435 Introduce and use is_any_target 75436 A few tests work on two different targets that can't be detected with 75437 a single call to istarget -- that proc only accepts globs, not regular 75438 expressions. 75439 75440 This patch introduces a new is_any_target proc and then converts these 75441 tests to use it in a 'require'. 75442 754432023-01-25 Tom Tromey <tom@tromey.com> 75444 75445 Use require with istarget 75446 This changes many tests to use require when checking 'istarget'. A 75447 few of these conversions were already done in earlier patches. 75448 75449 No change was needed to 'require' to make this work, due to the way it 75450 is written. I think the result looks pretty clear, and it has the 75451 bonus of helping to ensure that the reason that a test is skipped is 75452 always logged. 75453 754542023-01-25 Tom Tromey <tom@tromey.com> 75455 75456 Rename skip_vsx_tests to allow form 75457 This renames skip_vsx_tests to allow_vsx_tests and updates it users to 75458 use require. 75459 75460 Rename skip_power_isa_3_1_tests to allow form 75461 This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and 75462 updates its users to use require. 75463 75464 Rename skip_float_test to allow form 75465 This renames skip_float_test to allow_float_test and updates its users 75466 to use require. 75467 75468 Convert skip_altivec_tests to allow form 75469 This renames skip_altivec_tests to allow_altivec_tests and updates its 75470 users to use require. 75471 754722023-01-25 Tom de Vries <tdevries@suse.de> 75473 75474 [gdb/testsuite] Fix gdb.base/unwind-on-each-insn.exp for -m32 75475 With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I 75476 now get: 75477 ... 75478 # of expected passes 25 75479 ... 75480 instead of: 75481 ... 75482 # of expected passes 133 75483 ... 75484 as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug 75485 srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match 75486 "rip = " and info frame printing "eip = " instead. 75487 75488 Fix this by dropping "rip" from the regexp. 75489 75490 Tested on x86_64-linux, target boards unix/{-m64,-m32}. 75491 754922023-01-25 Tom de Vries <tdevries@suse.de> 75493 75494 [gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.exp 75495 Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and 75496 $srcfile2 without. 75497 75498 Occasionally, I try both files with debug info: 75499 ... 75500 - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { 75501 + $srcfile $debug_flags $srcfile2 $debug_flags]]} { 75502 ... 75503 75504 This shortcuts the test due to no longer recognizing that stepi still lands 75505 in foo. 75506 75507 Fix this by determining whether still in foo by checking the info frame output. 75508 75509 Tested on x86_64-linux. 75510 755112023-01-25 Tom de Vries <tdevries@suse.de> 75512 75513 [gdb/testsuite] Allow nodebug srcfile in gdb.base/unwind-on-each-insn.exp 75514 Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and 75515 $srcfile2 without. 75516 75517 Occasionally, I try both files with debug info: 75518 ... 75519 - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { 75520 + $srcfile $debug_flags $srcfile2 $debug_flags]]} { 75521 ... 75522 and both files without: 75523 ... 75524 - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { 75525 + $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} { 75526 ... 75527 75528 In the latter case, I run into: 75529 ... 75530 FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2 75531 FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up 75532 ... 75533 due to a mismatch between the regexp and the different output due to using 75534 nodebug. 75535 75536 Fix this by making the regexp less strict. 75537 75538 Tested on x86_64-linux. 75539 755402023-01-25 Felix Willgerodt <felix.willgerodt@intel.com> 75541 75542 gdb, i386: Update stale comment in i386-tdep.h. 75543 The comment seems no longer valid, the functions technically check for 75544 non-pseudo registers, like zmmh. Which is a valid use case. 75545 755462023-01-25 Tom de Vries <tdevries@suse.de> 75547 75548 [gdb/testsuite] Analyze non-leaf fn in gdb.base/unwind-on-each-insn.exp 75549 In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo 75550 to check various invariants at each insn, in particular hoping to excercise 75551 insns that modify stack and frame pointers. 75552 75553 Function foo is a leaf function, so add a non-leaf function bar, and step 75554 through it as well (using nexti instead of stepi). 75555 75556 With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049: 75557 ... 75558 FAIL: bar: instruction 5: bt 2 75559 FAIL: bar: instruction 5: up 75560 FAIL: bar: instruction 5: [string equal $fid $::main_fid] 75561 FAIL: bar: instruction 6: bt 2 75562 FAIL: bar: instruction 6: up 75563 FAIL: bar: instruction 6: [string equal $fid $::main_fid] 75564 ... 75565 75566 Tested on: 75567 - x86_64-linux (-m64 and -m32) 75568 - s390x-linux (-m64 and -m31) 75569 - aarch64-linux 75570 - powerpc64le-linux 75571 755722023-01-25 Tom de Vries <tdevries@suse.de> 75573 75574 [gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp 75575 In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo 75576 to check various invariants at each insn, in particular hoping to excercise 75577 insns that modify stack and frame pointers. 75578 75579 For x86_64-linux, we have a reasonably complex foo (and similar for -m32): 75580 ... 75581 4004bc: 55 push %rbp 75582 4004bd: 48 89 e5 mov %rsp,%rbp 75583 4004c0: 90 nop 75584 4004c1: 5d pop %rbp 75585 4004c2: c3 ret 75586 ... 75587 Both stack pointer (%rsp) and frame pointer (%rbp) are modified. 75588 75589 Also for s390x-linux (and similar for -m31): 75590 ... 75591 0000000001000668 <foo>: 75592 1000668: e3 b0 f0 58 00 24 stg %r11,88(%r15) 75593 100066e: b9 04 00 bf lgr %r11,%r15 75594 1000672: e3 b0 b0 58 00 04 lg %r11,88(%r11) 75595 1000678: 07 fe br %r14 75596 ... 75597 Frame pointer (%r11) is modified. 75598 75599 Likewise for powerpc64le-linux: 75600 ... 75601 00000000100006c8 <foo>: 75602 100006c8: f8 ff e1 fb std r31,-8(r1) 75603 100006cc: d1 ff 21 f8 stdu r1,-48(r1) 75604 100006d0: 78 0b 3f 7c mr r31,r1 75605 100006d4: 00 00 00 60 nop 75606 100006d8: 30 00 3f 38 addi r1,r31,48 75607 100006dc: f8 ff e1 eb ld r31,-8(r1) 75608 100006e0: 20 00 80 4e blr 75609 ... 75610 Both stack pointer (r1) and frame pointer (r31) are modified. 75611 75612 But for aarch64-linux, we have: 75613 ... 75614 00000000004005fc <foo>: 75615 4005fc: d503201f nop 75616 400600: d65f03c0 ret 75617 ... 75618 There's no insn that modifies stack or frame pointer. 75619 75620 Fix this by making foo more complex, adding an (unused) argument: 75621 ... 75622 0000000000400604 <foo>: 75623 400604: d10043ff sub sp, sp, #0x10 75624 400608: f90007e0 str x0, [sp, #8] 75625 40060c: d503201f nop 75626 400610: 910043ff add sp, sp, #0x10 75627 400614: d65f03c0 ret 75628 ... 75629 such that the stack pointer (sp) is modified. 75630 75631 [ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with 75632 -mno-omit-leaf-frame-pointer we have instead: 75633 ... 75634 0000000000400604 <foo>: 75635 400604: a9be7bfd stp x29, x30, [sp, #-32]! 75636 400608: 910003fd mov x29, sp 75637 40060c: f9000fa0 str x0, [x29, #24] 75638 400610: d503201f nop 75639 400614: a8c27bfd ldp x29, x30, [sp], #32 75640 400618: d65f03c0 ret 75641 ... 75642 such that also the frame pointer (x29) is modified. ] 75643 75644 Having made foo more complex, we now run into the following fail on 75645 x86_64/-m32: 75646 ... 75647 FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp 75648 .... 75649 75650 The problem is that the stack pointer has changed inbetween the sampling of 75651 main_sp and *foo, in particular by the push insn: 75652 ... 75653 804841a: 68 c0 84 04 08 push $0x80484c0 75654 804841f: e8 10 00 00 00 call 8048434 <foo> 75655 ... 75656 75657 Fix this by updating main_sp. 75658 75659 On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021: 75660 ... 75661 FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba 75662 FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid] 75663 ... 75664 but I saw the same failure before this commit with gcc 4.8.5. 75665 75666 Tested on: 75667 - x86_64-linux (-m64 and -m32) 75668 - s390x-linux (-m64 and -m31) 75669 - powerpc64le-linux 75670 - aarch64-linux 75671 75672 Also I've checked that the test-case still functions as regression test for PR 75673 record/16678 on x86_64. 75674 756752023-01-25 Andrew Burgess <aburgess@redhat.com> 75676 75677 gdb/tui: make use of a scoped_restore 75678 Make use of a scoped_restore object in tui_mld_read_key instead of 75679 doing a manual save/restore. 75680 75681 I don't think the existing code can throw an exception, so this is 75682 just a cleanup rather than a bug fix. 75683 75684 There should be no user visible changes after this commit. 75685 756862023-01-25 Andrew Burgess <aburgess@redhat.com> 75687 75688 gdb/tui: better filtering of tab completion results for focus command 75689 While working on the previous couple of commits, I noticed that the 75690 'focus' command would happily suggest 'status' as a possible focus 75691 completion, even though the 'status' window is non-focusable, and, 75692 after the previous couple of commits, trying to focus the status 75693 window will result in an error. 75694 75695 This commit improves the tab-completion results for the focus command 75696 so that the status window is not included. 75697 756982023-01-25 Andrew Burgess <aburgess@redhat.com> 75699 75700 gdb/tui: convert if/error to an assert 75701 While working on the previous commit, I realised that there was an 75702 error in tui_set_focus_command that could never be triggered. 75703 75704 Since the big tui rewrite (adding dynamic layouts) it is no longer 75705 true that there is a tui_win_info object for every window at all 75706 times. We now only create a tui_win_info object for a particular 75707 window, when the window is part of the current layout. As a result, 75708 if we have a tui_win_info pointer, then the window must be visible 75709 inside tui_set_focus_command (this function calls tui_enable as its 75710 first action, which makes the current layout visible). 75711 75712 The gdb.tui/tui-focus.exp test script exercises this area of code, and 75713 doesn't trigger the assert, nor do any of our other existing tui 75714 tests. 75715 757162023-01-25 Andrew Burgess <aburgess@redhat.com> 75717 75718 gdb/testsuite/tui: more testing of the 'focus' command 75719 I noticed that we didn't have many tests of the tui 'focus' command, 75720 so I started adding some. This exposed a bug in GDB; we are able to 75721 focus windows that should not be focusable, e.g. the 'status' window. 75722 75723 This is harmless until we then do 'focus next' or 'focus prev', along 75724 this code path we assert that the currently focused window is 75725 focusable, which obviously, is not always true, so GDB fails with an 75726 assertion error. 75727 75728 The fix is simple; add a check to the tui_set_focus_command function 75729 to ensure that the selected window is focusable. If it is not then an 75730 error is thrown. The new tests I've added cover this case. 75731 757322023-01-25 Andrew Burgess <aburgess@redhat.com> 75733 75734 gdb/testsuite: update gdb.tui/tui-nl-filtered-output.exp 75735 Following on from the previous commit, in this commit I am updating 75736 the test script gdb.tui/tui-nl-filtered-output.exp to take account of 75737 the changes in commit: 75738 75739 commit 9162a27c5f5828240b53379d735679e2a69a9f41 75740 Date: Tue Nov 13 11:59:03 2018 -0700 75741 75742 Change gdb test suite's TERM setting 75743 75744 In the above commit the TERM environment variable was changed to be 75745 'dumb' by default, which means that tests, that previously activated 75746 tui mode, no longer do unless TERM is set to 'ansi'. 75747 75748 As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the 75749 test stopped working. As the expect patterns in this script were 75750 pretty generic no tests actually started failing, and we never 75751 noticed. 75752 75753 In this commit I update the test script to correctly activate our 75754 terminal emulator, the test continues to pass after this update, but 75755 now we are testing in tui mode. 75756 757572023-01-25 Andrew Burgess <aburgess@redhat.com> 75758 75759 gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp 75760 Following on from the previous commit, in this commit I am updating 75761 the test script gdb.tui/tui-disasm-long-lines.exp to take account of 75762 the changes in commit: 75763 75764 commit 9162a27c5f5828240b53379d735679e2a69a9f41 75765 Date: Tue Nov 13 11:59:03 2018 -0700 75766 75767 Change gdb test suite's TERM setting 75768 75769 In the above commit the TERM environment variable was changed to be 75770 'dumb' by default, which means that tests, that previously activated 75771 tui mode, no longer do unless TERM is set to 'ansi'. 75772 75773 As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the 75774 test stopped working. As the expect patterns in this script were 75775 pretty generic no tests actually started failing, and we never 75776 noticed. 75777 75778 In this commit I update the script to use Term::clean_restart, which 75779 correctly sets TERM to 'ansi'. I've also added a check that the asm 75780 box does appear on the screen, which should indicate that tui mode has 75781 correctly activated. 75782 75783 However, I also notice that GDB doesn't appear to fully work 75784 correctly. The test should display the disassembly for the test 75785 program, but it doesn't. 75786 75787 The test is trying to disassemble some code that (deliberately) uses a 75788 very long symbol name, this eventually results in GDB entering 75789 tui_source_window_base::show_source_content and trying to allocate an 75790 ncurses pad in order to hold the current page of disassembler output. 75791 75792 Unfortunately, due to the very long line, the call to newpad fails, 75793 meaning that tui_source_window_base::m_pad is nullptr. Luckily non of 75794 the following calls appear to crash when passed a nullptr, however, 75795 all the output that is written to the pad is lost, which is why we 75796 don't see any assembly code written to the screen. 75797 75798 As the test history indicates that the script was originally checking 75799 for a crash in GDB when the long identifier was encountered, I think 75800 there is value in just leaving the test as it is for now, I have a fix 75801 for the issue of the newpad call failing, which I'll post in a follow 75802 up commit later. 75803 758042023-01-25 Andrew Burgess <aburgess@redhat.com> 75805 75806 gdb/testsuite: extend gdb.tui/tui-layout.exp test script 75807 In passing I noticed that the gdb.tui/tui-layout.exp test script was a 75808 little strange, it tests the layout command multiple times, but never 75809 sets up our ANSI terminal emulator, so every layout command fails with 75810 a message about the terminal lacking the required abilities. 75811 75812 It turns out that this was caused by this commit: 75813 75814 commit 9162a27c5f5828240b53379d735679e2a69a9f41 75815 Date: Tue Nov 13 11:59:03 2018 -0700 75816 75817 Change gdb test suite's TERM setting 75818 75819 This was when we changed the testsuite to set the TERM environment 75820 variable to "dumb" by default. 75821 75822 After this, any tui test that didn't set the terminal mode back to 75823 'ansi' would fail to activate tui mode. 75824 75825 For the tui-layout.exp test it just so happens that the test patterns 75826 are generic enough that the test continued to pass, even after this 75827 change. 75828 75829 In this commit I have updated the test so we now check the layout 75830 command both with a 'dumb' terminal and with the 'ansi' terminal. 75831 When testing with the 'ansi' terminal, I have some limited validation 75832 that GDB correctly entered tui mode. 75833 75834 I figured that it is probably worth having at least one test in the 75835 test suite that deliberately tries to enter tui mode in a dumb 75836 terminal, it would be sad if we one day managed to break GDB such that 75837 this caused a crash, and never noticed. 75838 758392023-01-25 Andrew Burgess <aburgess@redhat.com> 75840 75841 gdb/testsuite: rename test source file to match test script 75842 The previous commit touched the source file for the test script 75843 gdb.cp/cpcompletion.exp. This source file is called pr9594.cc. The 75844 source file is only used by the one test script. 75845 75846 This commit renames the source file to cpcompletion.cc to match the 75847 test script, this is more inline with how we name source files these 75848 days. 75849 758502023-01-25 Andrew Burgess <aburgess@redhat.com> 75851 75852 gdb/testsuite: use test_gdb_complete_unique more in C++ tests 75853 Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of 75854 gdb_test with test_gdb_complete_unique, this will extend the 75855 completion testing to check tab-completion as well as completion using 75856 the 'complete' command in some additional cases. 75857 758582023-01-25 GDB Administrator <gdbadmin@sourceware.org> 75859 75860 Automatic date update in version.in 75861 758622023-01-24 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 75863 75864 gprofng: PR29521 [docs] man pages are not in the release tarball 75865 gprofng/ChangeLog 75866 2023-01-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 75867 75868 PR gprofng/29521 75869 * configure.ac: Check if $MAKEINFO and $HELP2MAN are missing. 75870 * Makefile.am: Build doc if $MAKEINFO exists. 75871 * doc/gprofng.texi: Update documentation for gprofng. 75872 * doc/Makefile.am: Build gprofng.1. 75873 * src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am. 75874 * configure: Rebuild. 75875 * Makefile.in: Rebuild. 75876 * doc/Makefile.in: Rebuild. 75877 * src/Makefile.in: Rebuild. 75878 758792023-01-24 Indu Bhagat <indu.bhagat@oracle.com> 75880 75881 libsframe/doc: fix some warnings 75882 'make pdf' in libsframe shows some warnings, some of which (especially 75883 the Overfull warnings) are causing undesirable effects on the rendered 75884 output. Few examples of the warnings: 75885 75886 Underfull \hbox (badness 10000) in paragraph at lines 406--407 75887 @texttt pauth_ 75888 75889 Underfull \hbox (badness 10000) in paragraph at lines 407--410 75890 @textrm Specify which key is used for signing the return 75891 75892 ... 75893 75894 Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413 75895 @texttt fdetype[]| 75896 75897 ... 75898 75899 Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447 75900 @textrm SFRAME[]FDE[]TYPE[]PCMASK| 75901 75902 ... 75903 75904 This patch adjusts column widths of the affected cells to fix a subset 75905 of these warnings. For the rest of the warnings, use explicit newline 75906 command to fix them. 75907 75908 libsframe/ 75909 * doc/sframe-spec.texi: Fix various underfull and overfull 75910 warnings. 75911 759122023-01-24 Nick Clifton <nickc@redhat.com> 75913 75914 Fix seg-fault when generating an empty DLL with LTO enabled. 75915 ld PR 29998 75916 * pe-dll.c (generate_reloc): Handle sections 75917 with no assigned output section. 75918 Terminate early of there are no relocs to put 75919 in the .reloc section. 75920 (pe_exe_fill_sections): Do not emit an empty 75921 .reloc section. 75922 75923 bfd * cofflink.c (_bfd_coff_generic_relocate_section): 75924 Add an assertion that the output section is set 75925 for defined, global symbols. 75926 759272023-01-24 Enze Li <enze.li@hotmail.com> 75928 75929 gdb: some int to bool conversion 75930 When building GDB with clang 16, I got this, 75931 75932 CXX maint.o 75933 maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 75934 m_space_enabled = 1; 75935 ^ ~ 75936 maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 75937 m_time_enabled = 1; 75938 ^ ~ 75939 maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] 75940 m_symtab_enabled = 1; 75941 ^ ~ 75942 3 errors generated. 75943 75944 Work around this by using bool bitfields instead. 75945 75946 Tested by rebuilding on x86_64-linux with clang 16 and gcc 12. 75947 75948 Approved-By: Tom Tromey <tom@tromey.com> 75949 759502023-01-24 Mark Harmstone <mark@harmstone.com> 75951 75952 ld: Avoid magic numbers for subsystems in pe.em and pep.em 75953 759542023-01-24 GDB Administrator <gdbadmin@sourceware.org> 75955 75956 Automatic date update in version.in 75957 759582023-01-23 Mark Harmstone <mark@harmstone.com> 75959 75960 ld: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI 75961 This fixes the test failures introduced by 87a5cf5c, by changing the 75962 default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to 75963 2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other 75964 PE targets. 75965 75966 As far as I can tell there's no working modern Windows CE toolchain 75967 knocking about anyway, so this change shouldn't inconvenience anyone. 75968 759692023-01-23 Mark Harmstone <mark@harmstone.com> 75970 75971 Add support for secidx relocations to aarch64-w64-mingw32 75972 This patch adds support for the .secidx directive and its corresponding 75973 relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE 75974 integer which gets filled in with the 1-based index of the output 75975 section that a symbol ends up in. 75976 75977 This is needed for PDBs, which represent addresses as a .secrel32, 75978 .secidx pair. 75979 75980 The test is substantially the same as for amd64, but with changes made 75981 for padding and alignment. 75982 759832023-01-23 Tom de Vries <tdevries@suse.de> 75984 75985 [gdb/tdep, aarch64] Fix frame address of last insn 75986 Consider the test-case test.c, compiled without debug info: 75987 ... 75988 void 75989 foo (const char *s) 75990 { 75991 } 75992 75993 int 75994 main (void) 75995 { 75996 foo ("foo"); 75997 return 0; 75998 } 75999 ... 76000 76001 Disassembly of foo: 76002 ... 76003 0000000000400564 <foo>: 76004 400564: d10043ff sub sp, sp, #0x10 76005 400568: f90007e0 str x0, [sp, #8] 76006 40056c: d503201f nop 76007 400570: 910043ff add sp, sp, #0x10 76008 400574: d65f03c0 ret 76009 ... 76010 76011 Now, let's do "info frame" at each insn in foo, as well as printing $sp 76012 and $x29 (and strip the output of info frame to the first line, for brevity): 76013 ... 76014 $ gdb -q a.out 76015 Reading symbols from a.out... 76016 (gdb) b *foo 76017 Breakpoint 1 at 0x400564 76018 (gdb) r 76019 Starting program: a.out 76020 76021 Breakpoint 1, 0x0000000000400564 in foo () 76022 (gdb) display /x $sp 76023 1: /x $sp = 0xfffffffff3a0 76024 (gdb) display /x $x29 76025 2: /x $x29 = 0xfffffffff3a0 76026 (gdb) info frame 76027 Stack level 0, frame at 0xfffffffff3a0: 76028 (gdb) si 76029 0x0000000000400568 in foo () 76030 1: /x $sp = 0xfffffffff390 76031 2: /x $x29 = 0xfffffffff3a0 76032 (gdb) info frame 76033 Stack level 0, frame at 0xfffffffff3a0: 76034 (gdb) si 76035 0x000000000040056c in foo () 76036 1: /x $sp = 0xfffffffff390 76037 2: /x $x29 = 0xfffffffff3a0 76038 (gdb) info frame 76039 Stack level 0, frame at 0xfffffffff3a0: 76040 (gdb) si 76041 0x0000000000400570 in foo () 76042 1: /x $sp = 0xfffffffff390 76043 2: /x $x29 = 0xfffffffff3a0 76044 (gdb) info frame 76045 Stack level 0, frame at 0xfffffffff3a0: 76046 (gdb) si 76047 0x0000000000400574 in foo () 76048 1: /x $sp = 0xfffffffff3a0 76049 2: /x $x29 = 0xfffffffff3a0 76050 (gdb) info frame 76051 Stack level 0, frame at 0xfffffffff3b0: 76052 pc = 0x400574 in foo; saved pc = 0x40058c 76053 (gdb) si 76054 0x000000000040058c in main () 76055 1: /x $sp = 0xfffffffff3a0 76056 2: /x $x29 = 0xfffffffff3a0 76057 ... 76058 76059 The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it 76060 lists 0xfffffffff3b0. 76061 76062 The frame address is calculated here in aarch64_make_prologue_cache_1: 76063 ... 76064 unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg); 76065 if (unwound_fp == 0) 76066 return; 76067 76068 cache->prev_sp = unwound_fp + cache->framesize; 76069 ... 76070 76071 For insns after the prologue, we have cache->framereg == sp and 76072 cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong 76073 answer once sp has been restored to entry value by the before-last insn. 76074 76075 Fix this by detecting the situation that the sp has been restored. 76076 76077 This fixes PRs tdep/30010 and tdep/30011. 76078 76079 This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and 76080 gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721. 76081 76082 Tested on aarch64-linux. 76083 PR tdep/30010 76084 PR tdep/30011 76085 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010 76086 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011 76087 760882023-01-23 Tom de Vries <tdevries@suse.de> 76089 76090 [gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp 76091 One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the 76092 architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is 76093 compiled with nodebug, to prevent the dwarf unwinders from taking effect. 76094 76095 For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by 76096 default, generating an .eh_frame section contribution which might enable the 76097 dwarf unwinders and bypass the architecture-specific unwinders. 76098 76099 Currently, that happens to be not the case due to the current implementation 76100 of epilogue_unwind_valid, which assumes that in absence of debug info proving 76101 that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid. 76102 76103 That may change though, see PR30028, in which case 76104 gdb.base/unwind-on-each-insn.exp stops being a regression test for commit 76105 49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder"). 76106 76107 Fix this by making sure that we don't use .eh_frame info regardless of 76108 epilogue_unwind_valid, simply by not generating it using 76109 -fno-asynchronous-unwind-tables. 76110 76111 Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers 76112 gcc 7.5.0 and clang 13.0.1. 76113 761142023-01-23 Nick Clifton <nickc@redhat.com> 76115 76116 Updated Swedish translation for the binutils sub-directory 76117 761182023-01-23 Tom de Vries <tdevries@suse.de> 76119 76120 [gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp 76121 In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last 76122 disassembled insn in function foo. 76123 76124 This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc 76125 fix for gdb.base/unwind-on-each-insn.exp"). 76126 76127 The use of the last disassembled insn in the test-case is to stop stepping in 76128 foo once reaching it. 76129 76130 However, the intent is to stop stepping just before returning to main. 76131 76132 There is no guarantee that the last disassembled insn: 76133 - is actually executed 76134 - is executed just before returning to main 76135 - is executed only once. 76136 76137 Fix this by simplying the test-case to continue stepping till stepping out of 76138 foo. 76139 76140 Tested on x86_64-linux. 76141 761422023-01-23 Tom de Vries <tdevries@suse.de> 76143 76144 [gdb/testsuite] Fix untested in gdb.base/frame-view.exp 76145 When running test-case gdb.base/frame-view.exp, I see: 76146 ... 76147 gdb compile failed, ld: frame-view0.o: in function `main': 76148 frame-view.c:73: undefined reference to `pthread_create' 76149 ld: frame-view.c:76: undefined reference to `pthread_join' 76150 collect2: error: ld returned 1 exit status 76151 UNTESTED: gdb.base/frame-view.exp: failed to prepare 76152 ... 76153 76154 Fix this by adding pthreads to the compilation flags. 76155 76156 Tested on x86_64-linux. 76157 761582023-01-23 Vladislav Khmelevsky <och95@yandex.ru> 76159 76160 Fix objdump --reloc for specific symbol 76161 If objdump is used with both --disassemble=symbol and --reloc options 76162 skip relocations that have addresses before the symbol, so that they 76163 are not displayed. 76164 761652023-01-23 GDB Administrator <gdbadmin@sourceware.org> 76166 76167 Automatic date update in version.in 76168 761692023-01-22 Tom Tromey <tom@tromey.com> 76170 76171 Remove path name from test 76172 The test suite reports several path names in tests. I couldn't find 76173 most of these, and I suspect they are false reports, but I did manage 76174 to locate one. This one is probably harmless, as I think the path 76175 does not vary; but it's also easy to fix and suppress one warning. 76176 76177 Minor cleanup in gdb.btrace/enable.exp 76178 I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is 76179 left over from an earlier change. This patch moves the "!" inside the 76180 braces, where it belongs. 76181 76182 Minor fixup in allow_aarch64_sve_tests 76183 An earlier patch failed to update a string in allow_aarch64_sve_tests. 76184 761852023-01-22 GDB Administrator <gdbadmin@sourceware.org> 76186 76187 Automatic date update in version.in 76188 761892023-01-21 GDB Administrator <gdbadmin@sourceware.org> 76190 76191 Automatic date update in version.in 76192 761932023-01-20 Simon Marchi <simon.marchi@efficios.com> 76194 76195 gdb: make frame_info_ptr auto-reinflatable 76196 This is the second step of making frame_info_ptr automatic, reinflate on 76197 demand whenever trying to obtain the wrapper frame_info pointer, either 76198 through the get method or operator->. Make the reinflate method 76199 private, it is used as a convenience method in those two. 76200 76201 Add an "is_null" method, because it is often needed to know whether the 76202 frame_info_ptr wraps an frame_info or is empty. 76203 76204 Make m_ptr mutable, so that it's possible to reinflate const 76205 frame_info_ptr objects. Whether m_ptr is nullptr or not does not change 76206 the logical state of the object, because we re-create it on demand. I 76207 believe this is the right use case for mutable. 76208 76209 Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794 76210 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76211 762122023-01-20 Simon Marchi <simon.marchi@efficios.com> 76213 76214 gdb: make frame_info_ptr grab frame level and id on construction 76215 This is the first step of making frame_info_ptr automatic. Remove the 76216 frame_info_ptr::prepare_reinflate method, move that code to the 76217 constructor. 76218 76219 Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8 76220 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76221 762222023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76223 76224 gdb: make user-created frames reinflatable 76225 This patch teaches frame_info_ptr to reinflate user-created frames 76226 (frames created through create_new_frame, with the "select-frame view" 76227 command). 76228 76229 Before this patch, frame_info_ptr doesn't support reinflating 76230 user-created frames, because it currently reinflates by getting the 76231 current target frame (for frame 0) or frame_find_by_id (for other 76232 frames). To reinflate a user-created frame, we need to call 76233 create_new_frame, to make it lookup an existing user-created frame, or 76234 otherwise create one. 76235 76236 So, in prepare_reinflate, get the frame id even if the frame has level 76237 0, if it is user-created. In reinflate, if the saved frame id is user 76238 create it, call create_new_frame. 76239 76240 In order to test this, I initially enhanced the gdb.base/frame-view.exp 76241 test added by the previous patch by setting a pretty-printer for the 76242 type of the function parameters, in which we do an inferior call. This 76243 causes print_frame_args to not reinflate its frame (which is a 76244 user-created one) properly. On one machine (my Arch Linux one), it 76245 properly catches the bug, as the frame is not correctly restored after 76246 printing the first parameter, so it messes up the second parameter: 76247 76248 frame 76249 #0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40 76250 40 return z1.m + z2.n; 76251 (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame 76252 frame 76253 #0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40 76254 40 return z1.m + z2.n; 76255 (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again 76256 76257 However, on another machine (my Ubuntu 22.04 one), it just passes fine, 76258 without the appropriate fix. I then thought about writing a selftest 76259 for that, it's more reliable. I left the gdb.base/frame-view.exp pretty 76260 printer test there, it's already written, and we never know, it might 76261 catch some unrelated issue some day. 76262 76263 Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386 76264 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76265 762662023-01-20 Simon Marchi <simon.marchi@efficios.com> 76267 76268 gdb: make it possible to restore selected user-created frames 76269 I would like to improve frame_info_ptr to automatically grab the 76270 information needed to reinflate a frame, and automatically reinflate it 76271 as needed. One thing that is in the way is the fact that some frames 76272 can be created out of thin air by the create_new_frame function. These 76273 frames are not the fruit of unwinding from the target's current frame. 76274 These frames are created by the "select-frame view" command. 76275 76276 These frames are not correctly handled by the frame save/restore 76277 functions, save_selected_frame, restore_selected_frame and 76278 lookup_selected_frame. This can be observed here, using the test 76279 included in this patch: 76280 76281 $ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view 76282 Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view... 76283 (gdb) break thread_func 76284 Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42. 76285 (gdb) run 76286 Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view 76287 76288 [Thread debugging using libthread_db enabled] 76289 Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 76290 [New Thread 0x7ffff7cc46c0 (LWP 4171134)] 76291 [Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)] 76292 76293 Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42 76294 42 foo (11); 76295 (gdb) info frame 76296 Stack level 0, frame at 0x7ffff7cc3ee0: 76297 rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd 76298 called by frame at 0x7ffff7cc3f80 76299 source language c. 76300 Arglist at 0x7ffff7cc3ed0, args: p=0x0 76301 Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0 76302 Saved registers: 76303 rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8 76304 (gdb) thread 1 76305 [Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))] 76306 #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6 76307 76308 Here, we create a custom frame for thread 1 (using the stack from thread 76309 2, for convenience): 76310 76311 (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2 76312 76313 The first calls to "frame" looks good: 76314 76315 (gdb) frame 76316 #0 thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42 76317 42 foo (11); 76318 76319 But not the second one: 76320 76321 (gdb) frame 76322 #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6 76323 76324 This second "frame" command shows the current target frame instead of 76325 the user-created frame. 76326 76327 It's not totally clear how the "select-frame view" feature is expected 76328 to behave, especially since it's not tested. I heard accounts that it 76329 used to be possible to select a frame like this and do "up" and "down" 76330 to navigate the backtrace starting from that frame. The fact that 76331 create_new_frame calls frame_unwind_find_by_frame to install the right 76332 unwinder suggest that it used to be possible. But that doesn't work 76333 today: 76334 76335 (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2 76336 (gdb) up 76337 Initial frame selected; you cannot go up. 76338 (gdb) down 76339 Bottom (innermost) frame selected; you cannot go down. 76340 76341 and "backtrace" always shows the actual thread's backtrace, it ignores 76342 the user-created frame: 76343 76344 (gdb) bt 76345 #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6 76346 #1 0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6 76347 #2 0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56 76348 76349 I don't want to address all the `select-frame view` issues , but I think 76350 we can agree that the "frame" command changing the selected frame, as 76351 shown above, is a bug. I would expect that command to show the 76352 currently selected frame and not change it. 76353 76354 This happens because of the scoped_restore_selected_frame object in 76355 print_frame_args. The frame information is saved in the constructor 76356 (the backtrace below), and restored in the destructor. 76357 76358 #0 save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682 76359 #1 0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324 76360 #2 0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755 76361 #3 0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401 76362 #4 0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126 76363 #5 0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368 76364 #6 0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346 76365 #7 0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993 76366 #8 0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871 76367 #9 0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976 76368 76369 Since the user-created frame has level 0 (identified by the saved level 76370 -1), lookup_selected_frame just reselects the target's current frame, 76371 and the user-created frame is lost. 76372 76373 My goal here is to fix this particular problem. 76374 76375 Currently, select_frame does not set selected_frame_id and 76376 selected_frame_level for frames with level 0. It leaves them at 76377 null_frame_id / -1, indicating to restore_selected_frame to use the 76378 target's current frame. User-created frames also have level 0, so add a 76379 special case them such that select_frame saves their selected id and 76380 level. 76381 76382 save_selected_frame does not need any change. 76383 76384 Change the assertion in restore_selected_frame that checks `frame_level 76385 != 0` to account for the fact that we can restore user-created frames, 76386 which have level 0. 76387 76388 Finally, change lookup_selected_frame to make it able to re-create 76389 user-created frame_info objects from selected_frame_level and 76390 selected_frame_id. 76391 76392 Add a minimal test case for the case described above, that is the 76393 "select-frame view" command followed by the "frame" command twice. In 76394 order to have a known stack frame to switch to, the test spawns a second 76395 thread, and tells the first thread to use the other thread's top frame. 76396 76397 Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7 76398 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76399 764002023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76401 76402 gdb: add create_new_frame(frame_id) overload 76403 The subsequent patches will need to call create_new_frame with an 76404 existing frame_id representing a user created frame. They could call 76405 the existing create_new_frame, passing both addresses, but it seems 76406 nicer to have a version of the function that takes a frame_id directly. 76407 76408 Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32 76409 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76410 764112023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76412 76413 gdb: add user-created frames to stash 76414 A subsequent patch makes it possible for frame_info_ptr to reinflate 76415 user-created frames. If two frame_info_ptr objects wrapping the same 76416 user-created frame_info need to do reinflation, we want them to end up 76417 pointing to the same frame_info instance, and not create two separate 76418 frame_infos. Otherwise, GDB gets confused down the line, as the state 76419 kept in one frame_info object starts differing from the other 76420 frame_info. 76421 76422 Achieve this by making create_new_frame place the user-created frames in 76423 the frame stash. This way, when the second frame_info_ptr does 76424 reinflation, it will find the existing frame_info object, created by the 76425 other frame_info_ptr, in the frame stash. 76426 76427 To make the frame stash differentiate between regular and user-created 76428 frame infos which would otherwise be equal, change frame_addr_hash and 76429 frame_id::operator== to account for frame_id::user_created_p. 76430 76431 I made create_new_frame look up existing frames in the stash, and only 76432 create one if it doesn't find one. The goal is to avoid the 76433 "select-frame view"/"info frame view"/"frame view" commands from 76434 overriding existing entries into the stash, should the user specify the 76435 same frame more than once. This will also help in the subsequent patch 76436 that makes frame_info_ptr capable of reinflating user-created frames. 76437 It will be able to just call create_new_frame and it will do the right 76438 thing. 76439 76440 Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404 76441 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76442 764432023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76444 76445 gdb: add frame_id::user_created_p 76446 Later in this series, we'll need to differentiate frame ids for regular 76447 frames (obtained from the target state and unwinding from it) vs frame 76448 ids for user-created frames (created with create_new_frame). Add the 76449 frame_id::user_created_p field to indicate a frame is user-created, and 76450 set it in create_new_frame. 76451 76452 The field is otherwise not used yet, so not changes in behavior are 76453 expected. 76454 76455 Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3 76456 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76457 764582023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76459 76460 gdb: move frame_info_ptr to frame.{c,h} 76461 A patch later in this series will make frame_info_ptr access some 76462 fields internal to frame_info, which we don't want to expose outside of 76463 frame.c. Move the frame_info_ptr class to frame.h, and the definitions 76464 to frame.c. Remove frame-info.c and frame-info.h. 76465 76466 Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea 76467 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76468 764692023-01-20 Simon Marchi <simon.marchi@efficios.com> 76470 76471 gdb: move call site types to call-site.h 76472 I hesitated between putting the file in the dwarf2 directory (as 76473 gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h). 76474 The concept of call site is not DWARF-specific, another debug info 76475 reader could provide this information. But as it is, the implementation 76476 is a bit DWARF-specific, as one form it can take is a DWARF expression 76477 and parameters can be defined using a DWARF register number. So I ended up 76478 choosing to put it under dwarf2/. If another debug info reader ever 76479 wants to provide call site information, we can introduce a layer of 76480 abstraction between the "common" call site and the "dwarf2" call site. 76481 76482 The copyright start year comes from the date `struct call_site` was 76483 introduced. 76484 76485 Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d 76486 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76487 764882023-01-20 Simon Marchi <simon.marchi@efficios.com> 76489 76490 gdb: move sect_offset and cu_offset to dwarf2/types.h 76491 I want to move the call_site stuff out of gdbtypes.h, to a new header 76492 file, to break some cyclic include problem. The call_site stuff uses 76493 cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move 76494 somewhere else (otherwise, call-site.h will need to include gdbtypes.h, 76495 and we are back to square 1). I could move cu_offset to the future new 76496 file dwarf2/call-site.h, but it doesn't sound like a good place for it, 76497 at cu_offset is not specific to call sites, it's used throughout 76498 dwarf2/. So, move it to its own file, dwarf2/types.h. For now, 76499 gdbtypes.h includes dwarf2/types.h, but that will be removed once the 76500 call site stuff is moved to its own file. 76501 76502 Move sect_offset with it too. sect_offset is not a DWARF-specific 76503 concept, but for the moment it is only used in dwarf2/. 76504 76505 Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e 76506 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76507 765082023-01-20 Simon Marchi <simon.marchi@efficios.com> 76509 76510 gdb: remove language.h include from frame.h 76511 This helps resolve some cyclic include problem later in the series. 76512 The only language-related thing frame.h needs is enum language, and that 76513 is in defs.h. 76514 76515 Doing so reveals that a bunch of files were relying on frame.h to 76516 include language.h, so fix the fallouts here and there. 76517 76518 Change-Id: I178a7efec1953c2d088adb58483bade1f349b705 76519 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76520 765212023-01-20 Simon Marchi <simon.marchi@efficios.com> 76522 76523 gdb: move compile_instance to compile/compile.h 76524 struct compile_instance needs to be visible to users, since we use 76525 std::unique<compile_instance>. language.c and c-lang.c currently 76526 includes compile-internal.h for this reason, which kind of defeats the 76527 purpose of having an "internal" header file. 76528 76529 Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f 76530 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76531 765322023-01-20 Simon Marchi <simon.marchi@efficios.com> 76533 76534 gdb: move type_map_instance to compile/compile.c 76535 It's only used in compile/compile.c, it doesn't need to be in a header. 76536 76537 Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3 76538 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 76539 765402023-01-20 Indu Bhagat <indu.bhagat@oracle.com> 76541 76542 Upload SFrame spec files as well 76543 binutils/ 76544 * README-how-to-make-a-release: Include sframe-spec html and pdf 76545 files. 76546 765472023-01-20 Tom Tromey <tom@tromey.com> 76548 76549 Use bool in pc_in_* functions 76550 I noticed that pc_in_unmapped_range had a weird return type -- it was 76551 returning a CORE_ADDR but intending to return a bool. This patch 76552 changes all the pc_in_* functions to return bool instead. 76553 765542023-01-20 Tom Tromey <tromey@adacore.com> 76555 76556 Constify notif_client 76557 It seems to me that a notif_client is read-only, so this patch changes 76558 the code to use "const" everywhere. 76559 765602023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76561 76562 gdb: remove struct trad_frame forward declaration 76563 I found this forward declaration for a struct that doesn't exist, remove 76564 it. 76565 76566 Change-Id: Ib9473435a949452160598035e5e0fe19fcdc4d20 76567 765682023-01-20 Tom Tromey <tromey@adacore.com> 76569 76570 Make gdb.ada/ptype_tagged_param.exp pass 76571 gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36. 76572 However, it's actually generating the correct output -- it is just 76573 that the test thinks that the "ptype" will not work because I do not 76574 have the GNAT debuginfo installed. 76575 76576 This patch changes the code to accept either result, and then to issue 76577 a kfail as appropriate. 76578 765792023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76580 76581 gdb/dwarf: fix UBsan crash in read_subrange_type 76582 When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the 76583 `gnat-11` package installed (not `gnat`), with UBSan activated, I get: 76584 76585 (gdb) break foo.adb:40 76586 /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int' 76587 76588 The problematic DIEs are: 76589 76590 0x00001460: DW_TAG_subrange_type 76591 DW_AT_lower_bound [DW_FORM_data1] (0x00) 76592 DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000) 76593 DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423") 76594 DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned") 76595 DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e) 76596 DW_AT_artificial [DW_FORM_flag_present] (true) 76597 76598 0x0000153f: DW_TAG_base_type 76599 DW_AT_byte_size [DW_FORM_data1] (0x10) 76600 DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned) 76601 DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned") 76602 DW_AT_artificial [DW_FORM_flag_present] (true) 76603 76604 When processed by this code: 76605 76606 negative_mask = 76607 -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1)); 76608 if (low.kind () == PROP_CONST 76609 && !base_type->is_unsigned () && (low.const_val () & negative_mask)) 76610 low.set_const_val (low.const_val () | negative_mask); 76611 76612 When the base type's length (16 bytes in this case) is larger than a 76613 ULONGEST (typically 8 bytes), the bit shift is too large. 76614 76615 My obvious fix is just to skip the fixup for base types larger than a 76616 ULONGEST (8 bytes). I don't think we really handle constant attribute 76617 values larger than 8 bytes anyway, so this is part of a much larger 76618 problem. 76619 76620 Add a test that replicates this situation, but uses bounds that fit in a 76621 signed 64 bit, so we get a sensible result. 76622 76623 Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb 76624 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386 76625 766262023-01-20 Simon Marchi <simon.marchi@polymtl.ca> 76627 76628 gdb/testsuite: add test for negative subrange bounds with unsigned form 76629 I am looking at this code [1]: 76630 76631 /* Normally, the DWARF producers are expected to use a signed 76632 constant form (Eg. DW_FORM_sdata) to express negative bounds. 76633 But this is unfortunately not always the case, as witnessed 76634 with GCC, for instance, where the ambiguous DW_FORM_dataN form 76635 is used instead. To work around that ambiguity, we treat 76636 the bounds as signed, and thus sign-extend their values, when 76637 the base type is signed. */ 76638 negative_mask = 76639 -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1)); 76640 if (low.kind () == PROP_CONST 76641 && !base_type->is_unsigned () && (low.const_val () & negative_mask)) 76642 low.set_const_val (low.const_val () | negative_mask); 76643 if (high.kind () == PROP_CONST 76644 && !base_type->is_unsigned () && (high.const_val () & negative_mask)) 76645 high.set_const_val (high.const_val () | negative_mask); 76646 76647 Nothing in the testsuite seems to exercise it, as when I remove it, all 76648 of gdb.dwarf2 still passes. And tests in other directories would be 76649 compiler-dependent, so would rely on having a buggy compiler. 76650 76651 Update gdb.dwarf2/subrange.exp to have a test for it. When removing the 76652 code above, the new test fails with: 76653 76654 ptype array_with_buggy_negative_bounds_type^M 76655 type = array [240..244] of signed_byte^M 76656 (gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type 76657 76658 instead of the expected: 76659 76660 ptype array_with_buggy_negative_bounds_type^M 76661 type = array [-16..-12] of signed_byte^M 76662 (gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type 76663 76664 [1] https://gitlab.com/gnutools/binutils-gdb/-/blob/5ea14aa4e53fa37f4ba4517497ed2c1e4c60dee2/gdb/dwarf2/read.c#L17681-17695 76665 76666 Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2 76667 766682023-01-20 Michael Matz <matz@suse.de> 76669 76670 Add testcase ld-elf/merge4 76671 to check a situation that once failed with the new section merging 76672 when it mishandled offsets pointing into alignment padding in mergable 76673 string sections (i.e. pointing to zeros). It made bootstrap.exp fail 76674 but that depends on many factors to actually go wrong so this is a more 76675 explicit variant of it. 76676 766772023-01-20 Michael Matz <matz@suse.de> 76678 76679 arm32: Fix rodata-merge-map 76680 the test expects a second, but useless, $d mapping symbol for 76681 the partially merged section, and specifically disallows one 76682 for the completely merged section. The new merging algorithm 76683 makes it so that also the partially merged sections are conceptually 76684 SEC_EXCLUDED, except the first merge section (e.g. as if the very 76685 first object file already contains all strings). So that second mapping 76686 symbol is now missing. It never was needed anyway. 76687 76688 So, adjust the test. 76689 766902023-01-20 Michael Matz <matz@suse.de> 76691 76692 Faster string merging 76693 * use power-of-two hash table 76694 * use better hash function (hashing 32bits at once and with better 76695 mixing characteristics) 76696 * use input-offset-to-entry maps instead of retaining full input 76697 contents for lookup time 76698 * don't reread SEC_MERGE section multiple times 76699 * care for cache behaviour for the hot lookup routine 76700 76701 The overall effect is less usage in libz and much faster string merging 76702 itself. On a debug-info-enabled cc1 the effect at the time of this 76703 writing on the machine I used was going from 14400 perf samples to 9300 76704 perf samples or from 3.7 seconds to 2.4 seconds, i.e. about 33% . 76705 767062023-01-20 Frederic Cambus <fred@statdns.com> 76707 76708 Add OpenBSD ARM GAS support. 76709 767102023-01-20 Jan Beulich <jbeulich@suse.com> 76711 76712 x86: split i386-gen's opcode hash entry struct 76713 All glibc malloc() implementations I've checked have a smallest 76714 allocation size worth of 3 pointers, with an increment worth of 2 76715 pointers. Hence mnemonics with multiple templates can be stored more 76716 efficiently when maintaining the shared "name" field only in the actual 76717 hash entry. (To express the shared nature, also convert "name" to by 76718 pointer-to-const.) 76719 76720 While doing the conversation also pull out common code from the involved 76721 if/else construct in expand_templates(). 76722 767232023-01-20 Jan Beulich <jbeulich@suse.com> 76724 76725 x86: embed register and alike names in disassembler 76726 Register names are (including their nul terminators) on average almost 4 76727 bytes long. Otoh no register name is longer than 8 bytes. Hence even for 76728 32-bit builds using a pointer is only slightly more space efficient than 76729 embedding the strings. A level of indirection can be also avoided by 76730 embedding the names as an array of 8 characters directly in the arrays, 76731 and the number of base relocations in libopcodes.so (or PIE builds of 76732 statically linked executables) goes down as well. 76733 76734 To amortize for the otherwise reduced folding of string literals by the 76735 linker, use att_names_seg[] in place of string literals in append_seg() 76736 and OP_ESreg(). 76737 767382023-01-20 Jan Beulich <jbeulich@suse.com> 76739 76740 x86: embed register names in reg_entry 76741 Register names are (including their nul terminators) on average almost 4 76742 bytes long. Otoh no register name is longer than 7 bytes. Hence even for 76743 32-bit builds using a pointer is only slightly more space efficient than 76744 embedding the strings. A level of indirection can be also avoided by 76745 embedding the names as an array of 8 characters directly in the struct, 76746 and the number of base relocations in PIE builds of gas goes down as 76747 well. 76748 76749 x86: avoid strcmp() in a few places 76750 Now that we have identifiers for the mnemonic strings we can avoid 76751 strcmp() in a number of places, comparing the offsets into the mnemonic 76752 string table instead. While doing this also 76753 - convert a leftover strncmp() to startswith() (apparently an oversight 76754 when rebasing the original patch introducing the startswith() uses), 76755 - use the new shorthand for current_templates->start also elsewhere in 76756 md_assemble() (valid up to the point where match_template() is 76757 called). 76758 76759 x86: absorb allocation in i386-gen 76760 When generating the mnemonic string table we already set up an 76761 identifier for the following entry in a number of cases. Re-use that on 76762 the next loop iteration rather than re-doing allocation and conversion. 76763 76764 x86: re-use insn mnemonic strings as much as possible 76765 Compact the mnemonic string table such that the tails of longer 76766 mnemonics are re-used for shorter ones, going beyond what compilers 76767 would typically do, but matching what ELF linkers may do when processing 76768 SHF_MERGE|SHF_STRINGS sections. This reduces table size by about 12.5%. 76769 767702023-01-20 Jan Beulich <jbeulich@suse.com> 76771 76772 x86: move insn mnemonics to a separate table 76773 Using full pointers to reference the insn mnemonic strings is not very 76774 efficient. With overall string size presently just slightly over 20k, 76775 even a 16-bit value would suffice. Use "unsigned int" for now, as 76776 there's no good use we could presently make of the otherwise saved 16 76777 bits. 76778 76779 For 64-bit builds this reduces table size by 6.25% (prior to the recent 76780 ISA extension additions it would have been 12.5%), with a similar effect 76781 on cache occupation of table entries accessed. For PIE builds of gas 76782 this also reduces the number of base relocations quite a bit (obviously 76783 independent of bitness). 76784 767852023-01-20 Jan Beulich <jbeulich@suse.com> 76786 76787 x86: abstract out obtaining of a template's mnemonic 76788 In preparation for changing the representation of the "name" field 76789 introduce a wrapper function. This keeps the mechanical change separate 76790 from the functional one. 76791 767922023-01-20 GDB Administrator <gdbadmin@sourceware.org> 76793 76794 Automatic date update in version.in 76795 767962023-01-19 Tom Tromey <tromey@adacore.com> 76797 76798 Use "maint ignore-probes" in no-libstdcxx-probe.exp 76799 While looking at some test output, I saw that no-libstdcxx-probe.exp 76800 was not being run. However, it occurred to me that Tom de Vries' new 76801 "maint ignore-probes" command could be used to enable this test 76802 unconditionally. 76803 76804 Reviewed-by: Tom de Vries <tdevries@suse.de> 76805 768062023-01-19 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 76807 76808 i386: Don't emit unsupported TLS relocs on Solaris 76809 Emit R_386_TLS_LE and R_386_TLS_IE, instead of R_386_TLS_LE_32 and 76810 R_386_TLS_IE_32, on Solaris. 76811 76812 PR ld/13671 76813 * elf32-i386.c (elf_i386_tls_transition): Only emit R_386_TLS_LE, 76814 R_386_TLS_IE on Solaris. 76815 (elf_i386_relocate_section): Only use R_386_TLS_GD->R_386_TLS_LE 76816 transition on Solaris. 76817 76818 Co-Authored-By: H.J. Lu <hjl.tools@gmail.com> 76819 768202023-01-19 Andrew Burgess <andrew.burgess@embecosm.com> 76821 76822 GDB/testsuite: Expand for character string limiting options 76823 Modify test cases that verify the operation of the array element limit 76824 with character strings such that they are executed twice, once with the 76825 `set print characters' option set to `elements' and the limit controlled 76826 with the `set print elements' option, and then again with the limit 76827 controlled with the `set print characters' option instead. Similarly 76828 with the `-elements' and `-characters' options for the `print' command. 76829 Additionally verify that said `print' command options combined yield the 76830 expected result. 76831 76832 Verify correct $_gdb_setting and $_gdb_setting_str values for the `print 76833 characters' setting, in particular the `void' value for the `elements' 76834 default, which has no corresponding integer value exposed. 76835 76836 Add Guile and Python coverage for the `print characters' GDB setting. 76837 76838 There are new tests for Ada and Pascal, as the string printing code for 76839 these languages is different than the generic string printing code used 76840 by other languages. Modula2 also has different string printing code, 76841 but (a) this is similar to Pascal, and (b) there are no existing modula2 76842 tests written in Modula2, so I'm not sure how I'd even test the Modula2 76843 string printing. 76844 76845 Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> 76846 Approved-By: Simon Marchi <simon.marchi@efficios.com> 76847 768482023-01-19 Andrew Burgess <andrew.burgess@embecosm.com> 76849 76850 GDB: Add a character string limiting option 76851 This commit splits the `set/show print elements' option into two. We 76852 retain `set/show print elements' for controlling how many elements of an 76853 array we print, but a new `set/show print characters' setting is added 76854 which is used for controlling how many characters of a string are 76855 printed. 76856 76857 The motivation behind this change is to allow users a finer level of 76858 control over how data is printed, reflecting that, although strings can 76859 be thought of as arrays of characters, users often want to treat these 76860 two things differently. 76861 76862 For compatibility reasons by default the `set/show print characters' 76863 option is set to `elements', which makes the limit for character strings 76864 follow the setting of the `set/show print elements' option, as it used 76865 to. Using `set print characters' with any other value makes the limit 76866 independent from the `set/show print elements' setting, however it can 76867 be restored to the default with the `set print characters elements' 76868 command at any time. 76869 76870 A corresponding `-characters' option for the `print' command is added, 76871 with the same semantics, i.e. one can use `elements' to make a given 76872 `print' invocation follow the limit of elements, be it set with the 76873 `-elements' option also given with the same invocation or taken from the 76874 `set/show print elements' setting, for characters as well regardless of 76875 the current setting of the `set/show print characters' option. 76876 76877 The GDB changes are all pretty straightforward, just changing references 76878 to the old 'print_max' to use a new `get_print_max_chars' helper which 76879 figures out which of the two of `print_max' and `print_max_chars' values 76880 to use. 76881 76882 Likewise, the documentation is just updated to reference the new setting 76883 where appropriate. 76884 76885 To make people's life easier the message shown by `show print elements' 76886 now indicates if the setting also applies to character strings: 76887 76888 (gdb) set print characters elements 76889 (gdb) show print elements 76890 Limit on string chars or array elements to print is 200. 76891 (gdb) set print characters unlimited 76892 (gdb) show print elements 76893 Limit on array elements to print is 200. 76894 (gdb) 76895 76896 and the help text shows the dependency as well: 76897 76898 (gdb) help set print elements 76899 Set limit on array elements to print. 76900 "unlimited" causes there to be no limit. 76901 This setting also applies to string chars when "print characters" 76902 is set to "elements". 76903 (gdb) 76904 76905 In the testsuite there are two minor updates, one to add `-characters' 76906 to the list of completions now shown for the `print' command, and a bare 76907 minimum pair of checks for the right handling of `set print characters' 76908 and `show print characters', copied from the corresponding checks for 76909 `set print elements' and `show print elements' respectively. 76910 76911 Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> 76912 Approved-By: Simon Marchi <simon.marchi@efficios.com> 76913 769142023-01-19 Maciej W. Rozycki <macro@embecosm.com> 76915 76916 GDB: Allow arbitrary keywords in integer set commands 76917 Rather than just `unlimited' allow the integer set commands (or command 76918 options) to define arbitrary keywords for the user to use, removing 76919 hardcoded arrangements for the `unlimited' keyword. 76920 76921 Remove the confusingly named `var_zinteger', `var_zuinteger' and 76922 `var_zuinteger_unlimited' `set'/`show' command variable types redefining 76923 them in terms of `var_uinteger', `var_integer' and `var_pinteger', which 76924 have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. 76925 76926 Following existing practice `var_pinteger' allows extra negative values 76927 to be used, however unlike `var_zuinteger_unlimited' any number of such 76928 values can be defined rather than just `-1'. 76929 76930 The "p" in `var_pinteger' stands for "positive", for the lack of a more 76931 appropriate unambiguous letter, even though 0 obviously is not positive; 76932 "n" would be confusing as to whether it stands for "non-negative" or 76933 "negative". 76934 76935 Add a new structure, `literal_def', the entries of which define extra 76936 keywords allowed for a command and numerical values they correspond to. 76937 Those values are not verified against the basic range supported by the 76938 underlying variable type, allowing extra values to be allowed outside 76939 that range, which may or may not be individually made visible to the 76940 user. An optional value translation is possible with the structure to 76941 follow the existing practice for some commands where user-entered 0 is 76942 internally translated to UINT_MAX or INT_MAX. Such translation can now 76943 be arbitrary. Literals defined by this structure are automatically used 76944 for completion as necessary. 76945 76946 So for example: 76947 76948 const literal_def integer_unlimited_literals[] = 76949 { 76950 { "unlimited", INT_MAX, 0 }, 76951 { nullptr } 76952 }; 76953 76954 defines an extra `unlimited' keyword and a user-visible 0 value, both of 76955 which get translated to INT_MAX for the setting to be used with. 76956 76957 Similarly: 76958 76959 const literal_def zuinteger_unlimited_literals[] = 76960 { 76961 { "unlimited", -1, -1 }, 76962 { nullptr } 76963 }; 76964 76965 defines the same keyword and a corresponding user-visible -1 value that 76966 is used for the requested setting. If the last member were omitted (or 76967 set to `{}') here, then only the keyword would be allowed for the user 76968 to enter and while -1 would still be used internally trying to enter it 76969 as a part of a command would result in an "integer -1 out of range" 76970 error. 76971 76972 Use said error message in all cases (citing the invalid value requested) 76973 replacing "only -1 is allowed to set as unlimited" previously used for 76974 `var_zuinteger_unlimited' settings only rather than propagating it to 76975 `var_pinteger' type. It could only be used for the specific case where 76976 a single extra `unlimited' keyword was defined standing for -1 and the 76977 use of numeric equivalents is discouraged anyway as it is for historical 76978 reasons only that they expose GDB internals, confusingly different 76979 across variable types. Similarly update the "must be >= -1" Guile error 76980 message. 76981 76982 Redefine Guile and Python parameter types in terms of the new variable 76983 types and interpret extra keywords as Scheme keywords and Python strings 76984 used to communicate corresponding parameter values. Do not add a new 76985 PARAM_INTEGER Guile parameter type, however do handle the `var_integer' 76986 variable type now, permitting existing parameters defined by GDB proper, 76987 such as `listsize', to be accessed from Scheme code. 76988 76989 With these changes in place it should be trivial for a Scheme or Python 76990 programmer to expand the syntax of the `make-parameter' command and the 76991 `gdb.Parameter' class initializer to have arbitrary extra literals along 76992 with their internal representation supplied. 76993 76994 Update the testsuite accordingly. 76995 76996 Approved-By: Simon Marchi <simon.marchi@efficios.com> 76997 769982023-01-19 Indu Bhagat <indu.bhagat@oracle.com> 76999 77000 libsframe: Use AM_SILENT_RULES macro in configure.ac 77001 Silence 'make' by default. 77002 77003 libsframe/ 77004 * configure.ac: Use AM_SILENT_RULES. 77005 * configure: Regenerate. 77006 770072023-01-19 Tom Tromey <tom@tromey.com> 77008 77009 Remove some unused includes 77010 I noticed a few spots that include gnu-stabs.h but that do not need 77011 to. This patch removes these unnecessary includes. Tested by 77012 rebuilding. 77013 770142023-01-19 Tom de Vries <tdevries@space.suse.cz> 77015 77016 [gdb/tdep, aarch64] Remove fp and sp reg aliases, add x31 reg alias 77017 In aarch64-tdep.c we find these register aliases: 77018 ... 77019 { 77020 /* 64-bit register names. */ 77021 {"fp", AARCH64_FP_REGNUM}, 77022 {"lr", AARCH64_LR_REGNUM}, 77023 {"sp", AARCH64_SP_REGNUM}, 77024 ... 77025 77026 The sp alias is superfluous, because the canonical name of x31 is already sp. 77027 77028 The fp alias is superfluous, because it's already taken by the default meaning 77029 of fp, assigned here in _initialize_frame_reg: 77030 ... 77031 user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL); 77032 ... 77033 77034 Fix this by removing the fp and sp aliases. 77035 77036 While we're at it, add an x31 alias for sp. 77037 77038 Approved-By: Luis Machado <luis.machado@arm.com> 77039 77040 Tested on aarch64-linux. 77041 PR tdep/30012 77042 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012 77043 770442023-01-19 Tom de Vries <tdevries@suse.de> 77045 77046 [gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian 77047 On s390x-linux, I run into: 77048 ... 77049 (gdb) python print(u[u_fields[0]])^M 77050 99^M 77051 (gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field 77052 python print(u[u_fields[1]])^M 77053 0 '\000'^M 77054 (gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field 77055 ... 77056 77057 There's a var u of this type: 77058 ... 77059 union U { 77060 int a; 77061 char c; 77062 }; 77063 ... 77064 and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which 77065 it does on x86_64), but instead it contains 0. 77066 77067 Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both 77068 little and big endian. 77069 77070 Tested on x86_64-linux and s390x-linux. 77071 770722023-01-19 Alan Modra <amodra@gmail.com> 77073 77074 Reinitialise macro_nest 77075 * input-scrub.c (input_scrub_begin): Init macro_nest. 77076 770772023-01-19 Alan Modra <amodra@gmail.com> 77078 77079 PR 30022, concurrent builds can fail 77080 So let's not copy .libs/libbfd.a to libbfd.a now that nothing in the 77081 binutils-gdb source tries to link against it. 77082 77083 PR 30022 77084 * Makefile.am (noinst_LIBRARIES, libbfd_a_SOURCES, stamp-lib), 77085 (libbfd.a): Delete rules. 77086 (CLEANFILES): Adjust to suit. 77087 770882023-01-19 Indu Bhagat <indu.bhagat@oracle.com> 77089 77090 toplevel: Makefile.def: add install-strip dependency on libsframe 77091 As noted in PR libsframe/30014 - FTBFS: install-strip fails because 77092 bfdlib relinks and fails to find libsframe, the install time 77093 dependencies of libbfd need to be updated. 77094 77095 PR libsframe/30014 77096 * Makefile.def: Reflect that libsframe needs to installed before 77097 libbfd. Reorder a bit to better track libsframe dependencies. 77098 * Makefile.in: Regenerate. 77099 771002023-01-19 Alan Modra <amodra@gmail.com> 77101 77102 The fuzzers have found the reloc special functions in coff-aarch64.c 77103 All of them need a bfd_reloc_offset_in_range check before accessing 77104 data + reloc_entry->address. This patch adds the missing checks and 77105 sanity checks reloc offsets in coff_pe_aarch64_relocate_section too. 77106 77107 All of them also need changing to support objdump -W calls to 77108 bfd_simple_get_relocated_section_contents. At least, secrel_reloc 77109 needs the support, the others might not be present in dwarf debug 77110 sections. 77111 77112 * coff-aarch64.c (coff_aarch64_rel21_reloc): Range check 77113 reloc offset. Support final-linking. 77114 (coff_aarch64_po12l_reloc): Likewise. 77115 (coff_aarch64_addr32nb_reloc): Likewise. 77116 (coff_aarch64_secrel_reloc): Likewise. 77117 (coff_pe_aarch64_relocate_section): Range check reloc offset. 77118 771192023-01-19 Alan Modra <amodra@gmail.com> 77120 77121 Correct coff-aarch64 howtos and delete unnecessary special functions 77122 The remaining special functions are still broken except when called 77123 by gas bfd_install_relocation. 77124 77125 * coff-aarch64.c (coff_aarch64_addr64_reloc), 77126 (coff_aarch64_addr32_reloc, coff_aarch64_branch26_reloc), 77127 (coff_aarch64_branch19_reloc, coff_aarch64_branch14_reloc), 77128 (coff_aarch64_po12a_reloc): Delete. 77129 (HOWTO_INSTALL_ADDEND): Define as 1. 77130 (HOW): Remove pcrel_off. Correct all the howtos. 77131 (CALC_ADDEND): Define. 77132 (coff_aarch64_rtype_to_howto): New function. 77133 (coff_rtype_to_howto): Define. 77134 771352023-01-19 Alan Modra <amodra@gmail.com> 77136 77137 coff-aarch64.c howtos 77138 This is just a patch to fix overlong lines. Wrapping the HOWTO macro 77139 in a new HOW macro helps in this. No functional changes here. 77140 77141 * coff-aarch64.c (HOW): Define and use for reloc howtos. 77142 771432023-01-19 Alan Modra <amodra@gmail.com> 77144 77145 howto install_addend 77146 This adds a new flag to the reloc howtos that can be used to 77147 incrementally change targets over to simple bfd_install_relocation 77148 that just installs the addend without any weird adjustments. 77149 I've made a few other changes to bfd_install_relocation, removing dead 77150 code and comments that are really only applicable to 77151 bfd_perform_relocation. 77152 77153 There is also a reloc offset bounds check change. I've moved the 77154 check to where data is accessed, as it seems reasonable to me to not 77155 perform the check unless it is needed. There is precedence for this; 77156 Relocations against absolute symbols already avoided the check. 77157 77158 I also tried always performing the reloc offset check, and ran into 77159 testsuite failures due to _NONE and _ALIGN relocs at the end of 77160 sections. These likely would be fixed if all such reloc howtos had 77161 size set to zero, but I would rather not edit lots of files when it 77162 involves checking that target code does not use the size. 77163 77164 * reloc.c (struct reloc_howto_struct): Add install_addend. 77165 (HOWTO_INSTALL_ADDEND): Define. 77166 (HOWTO): Init new field with HOWTO_INSTALL_ADDEND. 77167 (bfd_install_relocation): Remove comments copied from 77168 bfd_perform_relocation that aren't applicable here. Remove 77169 code dealing with output_offset and output_section. Just set 77170 relocation to addend if install_addend. Move reloc offset 77171 bounds check to just before section data is accessed, avoiding 77172 the check when data is not accessed. 77173 * bfd-in2.h: Regenerate. 77174 771752023-01-19 Mike Frysinger <vapier@gentoo.org> 77176 77177 sim: info: convert verbose field to a bool 77178 The verbose argument has always been an int treated as a bool, so 77179 convert it to an explicit bool. Further, update the API docs to 77180 match the reality that the verbose value is actually used by some 77181 of the internal modules. 77182 77183 sim: unify sim-signal.o building 77184 Now that sim-main.h has been reduced significantly, we can remove it 77185 from sim-signal.c and unify it across all boards since it compiles to 77186 the same code. 77187 77188 sim: v850: reduce extra header inclusion to igen files 77189 Limit these extra header includes to only when specific igen files 77190 include us until we can move the includes to the igen fils directly. 77191 77192 sim: v850: drop redundant define 77193 This is already in v850/local.mk, so we can drop it from sim-main.h. 77194 771952023-01-19 Mark Wielaard <mark@klomp.org> 77196 77197 sim: mn10300: minimize mn10300-sim.h include in sim-main.h 77198 sim-main.h is special since it is one of the files automatically 77199 included in igen generated files. But this means anything including 77200 sim-main.h might get everything included just for the igen files. 77201 77202 To prevent clashing symbols/defines only include sim-fpu.h, 77203 sim-signal.h, mn10300-sim.h from sim-main.h if it is included 77204 from one of the generated igen C files. Add explicit includes 77205 of mn10300-sim.h, sim-fpu.h and/or sim-signal.h to dv-mn103cpu.c, 77206 interp.c and op_utils.c. 77207 772082023-01-19 GDB Administrator <gdbadmin@sourceware.org> 77209 77210 Automatic date update in version.in 77211 772122023-01-18 Maciej W. Rozycki <macro@embecosm.com> 77213 77214 GDB: Add references to erased args in cli-decode.c 77215 Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within 77216 cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter 77217 callbacks for settings") and update inline documentation accordingly for 77218 `add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the 77219 `args' parameter and removing references to `var', `set_setting_func' 77220 and `get_setting_func'. 77221 77222 Approved-By: Simon Marchi <simon.marchi@efficios.com> 77223 772242023-01-18 Maciej W. Rozycki <macro@embecosm.com> 77225 77226 GDB: Add missing inline documentation for `add_setshow_cmd_full' 77227 Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct 77228 within cmd_list_element") and add missing description for 77229 `add_setshow_cmd_full'. 77230 77231 GDB: Correct inline documentation for `add_setshow_cmd_full_erased' 77232 Use proper English in the description of SET_LIST and SHOW_LIST. 77233 772342023-01-18 Maciej W. Rozycki <macro@embecosm.com> 77235 77236 GDB: Fix documentation for `theclass' parameters in cli-decode.c 77237 Rename CLASS to THECLASS in the documentation for `theclass' parameters 77238 throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword 77239 cleanliness, mostly auto-generated"). 77240 77241 Approved-By: Simon Marchi <simon.marchi@efficios.com> 77242 772432023-01-18 Tom Tromey <tom@tromey.com> 77244 77245 Fix 'make TAGS' in gdbserver 77246 PR build/29003 points out that "make TAGS" is broken in gdbserver. 77247 This patch fixes the problem that is pointed out there, plus another 77248 one I noticed while working on that -- namely that the "sed" computes 77249 the wrong names for some source files. Finally, a couple of obsolete 77250 variable references are removed. 77251 77252 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29003 77253 772542023-01-18 Carl Love <cel@us.ibm.com> 77255 77256 Revert "X86: reverse-finish fix" 77257 This reverts commit b22548ddb30bfb167708e82d3bb932461c1b703a. 77258 77259 This patch is being reverted since the patch series is causing regressions. 77260 772612023-01-18 Carl Love <cel@us.ibm.com> 77262 77263 Revert "PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp" 77264 This reverts commit 92e07580db6a5572573d5177ca23933064158f89. 77265 77266 Reverting patch as the patch series is causing regressions. 77267 772682023-01-18 Jan Vrany <jan.vrany@labware.com> 77269 77270 gdb: care for dynamic objfiles in build_id_bfd_get () 77271 Accessing gdb.Objfile.build_id caused GDB to crash when objfile is 77272 dynamic, that is created by JIT reader API. 77273 77274 The issue was NULL-pointer dereferencing in build_id_bfd_get () because 77275 dynamic objfiles have no underlaying BFD structure. This commit fixes 77276 the problem by a NULL-check in build_id_bfd_get (). 77277 772782023-01-18 Nick Clifton <nickc@redhat.com> 77279 77280 Speed up objcopy's note merging. 77281 PR 29993 77282 * objcopy.c (merge_gnu_build_notes): Remember the last non-deleted note in order to speed up the scan for matching notes. 77283 772842023-01-18 Mike Frysinger <vapier@gentoo.org> 77285 77286 sim: ppc: drop local psim link 77287 This has never been installed, and it's not clear anyone cares about 77288 it in the local build dir (when the main program is sim/ppc/run), so 77289 drop all the logic to simplify. 77290 772912023-01-18 Mark Harmstone <mark@harmstone.com> 77292 77293 Use subsystem to distinguish between pei-arm-little and pei-arm-wince-little 77294 Running objdump against a 32-bit ARM PE file currently needs 77295 disambiguation, as it gets picked up by both pei-arm-little and 77296 pei-arm-wince-little. 77297 77298 This adds a check in pe_bfd_object_p so that the subsystem in the PE 77299 header is used to do the disambiguation for us, so that WinCE images get 77300 assigned to pei-arm-wince-little, and everything else to pei-arm-little. 77301 773022023-01-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 77303 77304 Revert "gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'" 77305 This reverts commit c2a5d74050ea9d7897b4122ef57c627d395683b3. 77306 773072023-01-18 GDB Administrator <gdbadmin@sourceware.org> 77308 77309 Automatic date update in version.in 77310 773112023-01-17 Tom Tromey <tromey@adacore.com> 77312 77313 Remove two unused fields from gdbarch 77314 When I converted gdbarch to use the registry, I forgot to remove the 77315 two fields that were used to implement the previous approach. This 77316 patch removes them. Tested by rebuilding. 77317 77318 Use require in paramless.exp 77319 The new paramless.exp test was not converted to the new "require" 77320 approach. This patch fixes the problem. 77321 773222023-01-17 Carl Love <cel@us.ibm.com> 77323 77324 PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp 77325 PR record/29927 - reverse-finish requires two reverse next instructions to 77326 reach previous source line 77327 77328 PowerPC uses two entry points called the local entry point (LEP) and the 77329 global entry point (GEP). Normally the LEP is used when calling a 77330 function. However, if the table of contents (TOC) value in register 2 is 77331 not valid the GEP is called to setup the TOC before execution continues at 77332 the LEP. When executing in reverse, the function finish_backward sets the 77333 break point at the alternate entry point (GEP). However if the forward 77334 execution enters via the normal entry point (LEP), the reverse execution 77335 never sees the break point at the GEP of the function. Reverse execution 77336 continues until the next break point is encountered or the end of the 77337 recorded log is reached causing gdb to stop at the wrong place. 77338 77339 This patch adds a new address to struct execution_control_state to hold the 77340 address of the alternate function start address, known as the GEP on 77341 PowerPC. The finish_backwards function is updated. If the stopping point 77342 is between the two entry points (the LEP and GEP on PowerPC), the stepping 77343 range is set to execute back to the alternate entry point (GEP on PowerPC). 77344 Otherwise, a breakpoint is inserted at the normal entry point (LEP on 77345 PowerPC). 77346 77347 Function process_event_stop_test checks uses a stepping range to stop 77348 execution in the caller at the first instruction of the source code line. 77349 Note, on systems that only support one entry point, the address of the two 77350 entry points are the same. 77351 77352 Test finish-reverse-next.exp is updated to include tests for the 77353 reverse-finish command when the function is entered via the normal entry 77354 point (i.e. the LEP) and the alternate entry point (i.e. the GEP). 77355 77356 The patch has been tested on X86 and PowerPC with no regressions. 77357 773582023-01-17 Carl Love <cel@us.ibm.com> 77359 77360 X86: reverse-finish fix 77361 PR record/29927 - reverse-finish requires two reverse next instructions to 77362 reach previous source line 77363 77364 Currently on X86, when executing the finish command in reverse, gdb does a 77365 single step from the first instruction in the callee to get back to the 77366 caller. GDB stops on the last instruction in the source code line where 77367 the call was made. When stopped at the last instruction of the source code 77368 line, a reverse next or step command will stop at the first instruction 77369 of the same source code line thus requiring two step/next commands to 77370 reach the previous source code line. It should only require one step/next 77371 command to reach the previous source code line. 77372 77373 By contrast, a reverse next or step command from the first line in a 77374 function stops at the first instruction in the source code line where the 77375 call was made. 77376 77377 This patch fixes the reverse finish command so it will stop at the first 77378 instruction of the source line where the function call was made. The 77379 behavior on X86 for the reverse-finish command now matches doing a 77380 reverse-next from the beginning of the function. 77381 77382 The proceed_to_finish flag in struct thread_control_state is no longer 77383 used. This patch removes the declaration, initialization and setting of 77384 the flag. 77385 77386 This patch requires a number of regression tests to be updated. Test 77387 gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the 77388 previous line. The gdb output for tests gdb.reverse/until-precsave.exp 77389 and gdb.reverse/until-reverse.exp changed slightly. The expected result in 77390 tests gdb.reverse/amd64-failcall-reverse.exp and 77391 gdb.reverse/singlejmp-reverse.exp are updated to the correct expected 77392 result. 77393 77394 This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the 77395 reverse-finish command when returning from the entry point and from the 77396 body of the function. 77397 77398 The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp 77399 was moved to lib/gdb.exp and renamed cmd_until. 77400 77401 The patch has been tested on X86 and PowerPC to verify no additional 77402 regression failures occured. 77403 77404 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927 77405 774062023-01-17 Simon Marchi <simon.marchi@efficios.com> 77407 77408 gdb/testsuite: expect SIGSEGV from top GDB spawn id 77409 When testing with the native-extended-gdbserver, I get: 77410 77411 Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault. 77412 0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1 77413 (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt 77414 77415 This is because the -re that is supposed to match this SIGSEGV is after 77416 `-i $inferior_spawn_id`. On native, the top and bottom GDB are on the 77417 same spawn id, so it ends up working. But with a gdbserver board, 77418 that's not the case. Move the SIGSEGV -re before the `-i 77419 $inferior_spawn_id` line, such that it matches what the top GDB outputs. 77420 77421 Do the same fix in gdb.gdb/python-helper.exp. 77422 77423 Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927 77424 Approved-By: Tom Tromey <tom@tromey.com> 77425 774262023-01-17 Tom Tromey <tromey@adacore.com> 77427 77428 Fix parameter-less template regression in new DWARF reader 77429 PR c++/29896 points out a regression in the new DWARF reader. It does 77430 not properly handle a case like "break fn", where "fn" is a template 77431 function. 77432 77433 This happens because the new index uses strncasecmp to compare. 77434 However, to make this work correctly, we need a custom function that 77435 ignores template parameters. 77436 77437 This patch adds a custom comparison function and fixes the bug. A new 77438 test case is included. 77439 77440 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896 77441 774422023-01-17 Tom Tromey <tromey@adacore.com> 77443 77444 Move hash_entry and eq_entry into cooked_index::do_finalize 77445 I was briefly confused by the hash_entry and eq_entry functions in the 77446 cooked index. They are only needed in a single method, and that 77447 method already has a couple of local lambdas for a different hash 77448 table. So, it seemed cleaner to move these there as well. 77449 77450 Don't erase empty indices in DWARF reader 77451 The DWARF reader has some code to remove empty indices. However, I 77452 think this code has been obsolete since some earlier changes to 77453 parallel_for_each. This patch removes this code. 77454 77455 Avoid submitting empty tasks in parallel_for_each 77456 I found that parallel_for_each would submit empty tasks to the thread 77457 pool. For example, this can happen if the number of tasks is smaller 77458 than the number of available threads. In the DWARF reader, this 77459 resulted in the cooked index containing empty sub-indices. This patch 77460 arranges to instead shrink the result vector and process the trailing 77461 entries in the calling thread. 77462 774632023-01-17 Stam Markianos-Wright <stam.markianos-wright@arm.com> 77464 77465 gas: arm: Change warning message to not reference specific A-class architecture revision 77466 We noticed that a warning message about the use of scalar fp16 77467 instructions being UNPREDICTABLE when conditionalized in an IT 77468 block referenced the specific A-class architecture revision 77469 ARMv8.2-A. 77470 Many of these instructions are now also part of ARMv8.1-M, so 77471 the warning message had become misleading. Here we just change 77472 the message to not specify an architecture revision at all and 77473 update all testing accordingly. This was done with a simple 77474 find-n-replace within the binutils sources. No tests have 77475 regressed for the arm target. 77476 77477 gas/ChangeLog: 77478 77479 * config/tc-arm.c (do_scalar_fp16_v82_encode): Remove 77480 ARMv8.2-A from the warning message. 77481 (do_neon_movhf): Likewise 77482 * testsuite/gas/arm/armv8-2-fp16-scalar-bad.l: Likewise 77483 * testsuite/gas/arm/mve-vaddsub-it-bad.l: Likewise 77484 * testsuite/gas/arm/mve-vcvtne-it-bad.l: Likewise 77485 * testsuite/gas/arm/mve-vcvtne-it.d: Likewise 77486 774872023-01-17 Stam Markianos-Wright <stam.markianos-wright@arm.com> 77488 77489 gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn 77490 Previously we had experienced issues with assembling a "VCVTNE" instruction 77491 in the presence of the MVE architecture extension, because it could be 77492 interpreted both as: 77493 77494 * The base instruction VCVT + NE for IT predication when inside an IT block. 77495 * The MVE instruction VCVTN + E in the Else of a VPT block. 77496 77497 Given a C reproducer of: 77498 ``` 77499 int test_function(float value) 77500 { 77501 int ret_val = 10; 77502 if (value != 0.0) 77503 { 77504 ret_val = (int) value; 77505 } 77506 return ret_val; 77507 } 77508 ``` 77509 GCC generates a VCVTNE instruction based on the `truncsisf2_vfp` 77510 pattern, which will look like: 77511 `vcvtne.s32.f32 s-reg, s-reg` 77512 This still triggers an error due to being misidentified as "vcvtn+e" 77513 Similar errors were found with other type combinations and instruction 77514 patterns (these have all been added to the testing of this patch). 77515 77516 This class of errors was previously worked around by: 77517 https://sourceware.org/pipermail/binutils/2020-August/112728.html 77518 which addressed this by looking at the operand types, however, 77519 that isn't adequate to cover all the extra cases that have been 77520 found. Instead, we add some special-casing logic earlier when 77521 the instructions are parsed that is conditional on whether we are 77522 in a VPT block or not, when the instruction is parsed. 77523 77524 gas/ChangeLog: 77525 77526 * config/tc-arm.c (opcode_lookup): Add special vcvtn handling. 77527 * testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing. 77528 * testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise. 77529 * testsuite/gas/arm/mve-vcvtne-it.d: Likewise. 77530 * testsuite/gas/arm/mve-vcvtne-it.s: Likewise. 77531 775322023-01-17 Nick Clifton <nickc@redhat.com> 77533 77534 Fix snafu in previous delta for elf32-csky.c 77535 775362023-01-17 Xianmiao Qu <cooper.qu@linux.alibaba.com> 77537 77538 C-SKY: Fix machine flag. 77539 * elf32-csky.c (elf32_csky_merge_attributes): Don't save and restore the ARCH attribute, it will actually clear the ARCH attribute. (csky_elf_merge_private_bfd_data): Store the machine flag correctly. 77540 775412023-01-17 GDB Administrator <gdbadmin@sourceware.org> 77542 77543 Automatic date update in version.in 77544 775452023-01-16 Enze Li <enze.li@hotmail.com> 77546 77547 libctf: update regexp to allow makeinfo to build document 77548 While trying to build gdb on latest openSUSE Tumbleweed, I noticed the 77549 following warning, 77550 77551 checking for makeinfo... makeinfo --split-size=5000000 77552 configure: WARNING: 77553 *** Makeinfo is too old. Info documentation will not be built. 77554 77555 then I checked the version of makeinfo, it said, 77556 ====== 77557 $ makeinfo --version 77558 texi2any (GNU texinfo) 7.0.1 77559 77560 Copyright (C) 2022 Free Software Foundation, Inc. 77561 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 77562 This is free software: you are free to change and redistribute it. 77563 There is NO WARRANTY, to the extent permitted by law. 77564 ====== 77565 77566 After digging a little bit, it became quite obvious that a dot is 77567 missing in regexp that makes it impossible to match versions higher than 77568 7.0, and here's the solution: 77569 77570 - | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9][0-9])' >/dev/null 2>&1; then 77571 + | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9]\.[0-9])' >/dev/null 2>&1; then 77572 77573 However, Eli pointed out that the solution above has another problem: it 77574 will stop working when Texinfo 10.1 will be released. Meanwhile, he 77575 suggested to solve this problem permanently. That is, we don't care 77576 about the minor version for Texinfo > 6.9, we only care about the major 77577 version. 77578 77579 In this way, the problem will be resolved permanently, thanks to Eli. 77580 77581 libctf/ChangeLog: 77582 77583 * configure: Regenerated. 77584 * configure.ac: Update regexp to match versions higher than 7.0. 77585 775862023-01-16 Alan Modra <amodra@gmail.com> 77587 77588 Correct ld-pe/aarch64.d test output 77589 "foo" is at 0x2010. This corrects the expected output for .long and 77590 .word referencing foo, showing a problem with relocation handling. 77591 77592 * testsuite/ld-pe/aarch64.d: Correct expected output. 77593 775942023-01-16 Alan Modra <amodra@gmail.com> 77595 77596 Tidy gas/expr.c static state 77597 * expr.c (seen, nr_seen): Make file scope. 77598 (expr_begin): Clear seen, nr_seen, and expr_symbol_lines. 77599 (expr_end): New function. 77600 * expr.h (expr_end): Declare. 77601 * output-file.c (output_file_close): Call expr_end. 77602 * config/tc-hppa.c (expr_end): Rename to expr_parse_end. 77603 * config/tc-mips.c: Likewise. 77604 * config/tc-riscv.c: Likewise. 77605 * config/tc-sparc.c: Likewise. 77606 77607 Leftover hack from i960-coff 77608 * reloc.c (bfd_perform_relocation, bfd_install_relocation): Remove 77609 i960-coff target hack. 77610 776112023-01-16 Alan Modra <amodra@gmail.com> 77612 77613 COFF CALC_ADDEND comment 77614 Old COFF (and AOUT) targets have unusual relocation addends. 77615 77616 * coffcode.h (<Reading relocations>): Describe COFF addends. 77617 776182023-01-16 Alan Modra <amodra@gmail.com> 77619 77620 PR29991, MicroMIPS flag erased after align directives 77621 PR 29991 77622 * config/tc-mips.c (s_align): Call file_mips_check_options and 77623 mips_mark_labels. 77624 * testsuite/gas/mips/align-after-label.s, 77625 * testsuite/gas/mips/mips-align-after-label.d, 77626 * testsuite/gas/mips/micromips-align-after-label.d: New test. 77627 * testsuite/gas/mips/mips.exp: Run it. 77628 776292023-01-16 Nick Clifton <nickc@redhat.com> 77630 77631 Update release making howto 77632 77633 Updated translations for the gas and binutils sub-directories 77634 776352023-01-16 Mike Frysinger <vapier@gentoo.org> 77636 77637 sim: assume sys/stat.h always exists (via gnulib) 77638 We have many uses of sys/stat.h that are unprotected by HAVE_SYS_STAT_H, 77639 so this is more formalizing the reality that we require this header. 77640 Since we switched to gnulib, it guarantees that a sys/stat.h exists 77641 for us to include, so we're doubly OK. 77642 77643 sim: formally assume unistd.h always exists (via gnulib) 77644 We have many uses of unistd.h that are unprotected by HAVE_UNISTD_H, 77645 so this is more formalizing the reality that we require this header. 77646 Since we switched to gnulib, it guarantees that a unistd.h exists 77647 for us to include, so we're doubly OK. 77648 77649 sim: build: stop probing system extensions (ourselves) 77650 This logic was added in order to expose the strsignal prototype for 77651 nrun.c. Since then, we've migrated to gnulib as our portability layer, 77652 and it takes care of probing system extensions for us, so there's no 77653 need to duplicate the work. 77654 776552023-01-16 Mike Frysinger <vapier@gentoo.org> 77656 77657 sim: modules.c: fix generation after recent refactors 77658 Add explicit arch-specific modules.c rules to keep the build from 77659 generating an incorrect common/modules.c. Otherwise the pattern 77660 rules would cascade such that it'd look for $arch/modules.o which 77661 turned into common/modules.c which triggered the gen rule. 77662 77663 My local testing of this code didn't catch this bug because of how 77664 Automake manages .Po (dependency files) in incremental builds -- it 77665 was adding extra rules that override the pattern rules which caused 77666 the build to generate correct modules.c files. But when building 77667 from a cold cache, the pattern rules would force common/modules.c to 77668 be used leading to crashes at runtime. 77669 776702023-01-16 GDB Administrator <gdbadmin@sourceware.org> 77671 77672 Automatic date update in version.in 77673 776742023-01-15 Mark Wielaard <mark@klomp.org> 77675 77676 sim: microblaze, mn10300: remove signal.h include in interp.c 77677 signal.h isn't needed in microblaze and mn10300 interp.c 77678 so don't include it. 77679 776802023-01-15 Mike Frysinger <vapier@gentoo.org> 77681 77682 sim: m32r: fix typos in stamp depends 77683 Copying & pasting the first rule missed updating the dep to the right 77684 stamp file. 77685 77686 sim: igen: simplify build logic a little 77687 Now that all ports (that use igen) build in the top-level and depend 77688 on igen, we can move the conditional logic out of configure. We also 77689 switch from noinst_LIBRARIES to EXTRA_LIBRARIES so that the library 77690 is only built when needed (i.e. the igen tool is used). 77691 77692 sim: build: drop depdir subdir hack 77693 Now that all the ports compile some C files in their arch dirs, Automake 77694 guarantees creating the depdir for us, so we can drop our configure hack. 77695 77696 sim: common: simplify modules.c deps 77697 Now that all ports (other than ppc) build in the top-level, we don't 77698 need to expand all the modules.c targets as a recursive dep. Each 77699 port depends on their respective file now, and the ppc port doesn't 77700 use it at all. 77701 77702 sim: common: move modules.c to source tracking 77703 This makes sure the arch-specific modules.c wildcard is matched and 77704 not the common/%.c so that we compile it correctly. It also makes 77705 sure each subdir has depdir logic enabled. 77706 77707 sim: common: move libcommon.a dep to ppc code 77708 Rather than force this to be built ahead of time for all targets, 77709 move the dep to the ppc code since it's the only user of it now. 77710 77711 sim: build: drop most recursive build deps 77712 Now that we build these objects in the top dir & generate modules.c 77713 there, we don't need to generate them all first -- we can let the 77714 normal dependency graph take care of building things in parallel. 77715 77716 sim: common: move libcommon.a objects to sources 77717 This simplifies the build logic and avoids an Automake bug where the 77718 common_libcommon_a_OBJECTS variable isn't set in the arch libsim.a 77719 DEPENDENCIES for targets that, alphabetically, come before "common". 77720 We aren't affected by that bug with the current code, but as we move 77721 things out of SIM_ALL_RECURSIVE_DEPS and rely on finer dependencies, 77722 we will trip over it. 77723 77724 sim: igen: simplify build dep 77725 Now that all ports (other than ppc) build in the top-level, we don't 77726 need to mark the igen tool as a recursive dep. Each port depends on 77727 the tool if it actually uses it, and ppc doesn't use it at all. 77728 77729 sim: common: simplify hw-config.h deps 77730 Now that all ports (other than ppc) build in the top-level, we don't 77731 need to expand all the hw-config.h targets as a recursive dep. Each 77732 port depends on their respective header now, and the ppc port doesn't 77733 use it at all. 77734 77735 sim: build: drop AM_MAKEFLAGS settings 77736 We don't have any recursive builds anymore, so we can drop this logic. 77737 777382023-01-15 GDB Administrator <gdbadmin@sourceware.org> 77739 77740 Automatic date update in version.in 77741 777422023-01-14 Tom Tromey <tom@tromey.com> 77743 77744 Pass internal gdb flags to --configuration invocations 77745 The test suite uses the --configuration flag to feature-test gdb. 77746 However, when I added this, I neglected to pass the internal gdbflags 77747 to this, causing an error, which then caused failures in the test 77748 suite (which would not be seen if you'd ever run "make install"). 77749 77750 This patch fixes the bug. Tested by removing my install tree first, 77751 to verify that I could reproduce the failure. 77752 777532023-01-14 Nick Clifton <nickc@redhat.com> 77754 77755 Update how-to-make-a-release file now that the 2.40 release is out 77756 777572023-01-14 GDB Administrator <gdbadmin@sourceware.org> 77758 77759 Automatic date update in version.in 77760 777612023-01-13 Mike Frysinger <vapier@gentoo.org> 77762 77763 sim: build: delete Make-common.in logic 77764 Now that all (other than ppc) build in the top-level, this logic is 77765 unused, so punt it all. 77766 777672023-01-13 Tom Tromey <tom@tromey.com> 77768 77769 Rename to allow_tui_tests 77770 This changes skip_tui_tests to invert the sense, and renames it to 77771 allow_tui_tests. It also rewrites this function to use the output of 77772 "gdb --configuration", and it adds a note about the state of the TUI 77773 to that output. 77774 77775 Rename to allow_guile_tests 77776 This changes skip_guile_tests to invert the sense, and renames it to 77777 allow_guile_tests. It also rewrites this proc to check the output of 77778 "gdb --configuration", as was done for Python. Then it changes the 77779 code to use "require" where possible. 77780 77781 Rename to allow_hw_breakpoint_tests 77782 This changes skip_hw_breakpoint_tests to invert the sense, and renames 77783 it to allow_hw_breakpoint_tests. This also converts some tests to use 77784 "require" -- I missed this particular check in the first series. 77785 77786 Rename to allow_tsx_tests 77787 This changes skip_tsx_tests to invert the sense, and renames it to 77788 allow_tsx_tests. 77789 77790 Rename to allow_shlib_tests 77791 This changes skip_shlib_tests to invert the sense, and renames it to 77792 allow_shlib_tests. 77793 77794 Rename to allow_rust_tests 77795 This changes skip_rust_tests to invert the sense, and renames it to 77796 allow_rust_tests. 77797 77798 Rename to allow_python_tests 77799 This changes skip_python_tests to invert the sense, and renames it to 77800 allow_python_tests. 77801 77802 Rename to allow_perf_tests 77803 This changes skip_perf_tests to invert the sense, and renames it to 77804 allow_perf_tests. 77805 77806 Rename to allow_opencl_tests 77807 This changes skip_opencl_tests to invert the sense, and renames it to 77808 allow_opencl_tests. 77809 77810 Rename to allow_ifunc_tests 77811 This changes skip_ifunc_tests to invert the sense, and renames it to 77812 allow_ifunc_tests. 77813 77814 Rename to allow_hw_watchpoint_tests 77815 This changes skip_hw_watchpoint_tests to invert the sense, and renames 77816 it to allow_hw_watchpoint_tests. 77817 77818 Rename to allow_hw_watchpoint_multi_tests 77819 This changes skip_hw_watchpoint_multi_tests to invert the sense, and 77820 renames it to allow_hw_watchpoint_multi_tests. 77821 77822 Rename to allow_hw_watchpoint_access_tests 77823 This changes skip_hw_watchpoint_access_tests to invert the sense, and 77824 renames it to allow_hw_watchpoint_access_tests. 77825 77826 Rename to allow_go_tests 77827 This changes skip_go_tests to invert the sense, and renames it to 77828 allow_go_tests. 77829 77830 Rename to allow_gdbserver_tests 77831 This changes skip_gdbserver_tests to invert the sense, and renames it 77832 to allow_gdbserver_tests. 77833 77834 Rename to allow_fortran_tests 77835 This changes skip_fortran_tests to invert the sense, and renames it to 77836 allow_fortran_tests. 77837 77838 Rename to allow_d_tests 77839 This changes skip_d_tests to invert the sense, and renames it to 77840 allow_d_tests. 77841 77842 Rename to allow_dlmopen_tests 77843 This changes skip_dlmopen_tests to invert the sense, and renames it to 77844 allow_dlmopen_tests. 77845 77846 Rename to allow_debuginfod_tests 77847 This changes skip_debuginfod_tests to invert the sense, and renames it 77848 to allow_debuginfod_tests. 77849 77850 Rename to allow_ctf_tests 77851 This changes skip_ctf_tests to invert the sense, and renames it to 77852 allow_ctf_tests. 77853 77854 Rename to allow_cplus_tests and allow_stl_tests 77855 This changes skip_cplus_tests to invert the sense, and renames it to 77856 allow_cplus_tests. This one also converts skip_stl_tests to 77857 allow_stl_tests, as that was convenient to do at the same time. 77858 77859 Rename to allow_btrace_tests 77860 This changes skip_btrace_tests to invert the sense, and renames it to 77861 allow_btrace_tests. 77862 77863 Rename to allow_btrace_pt_tests 77864 This changes skip_btrace_pt_tests to invert the sense, and renames it 77865 to allow_btrace_pt_tests. 77866 77867 Rename to allow_avx512fp16_tests 77868 This changes skip_avx512fp16_tests to invert the sense, and renames it 77869 to allow_avx512fp16_tests. 77870 77871 Rename to allow_avx512bf16_tests 77872 This changes skip_avx512bf16_tests to invert the sense, and renames it 77873 to allow_avx512bf16_tests. 77874 77875 Rename to allow_ada_tests 77876 This changes skip_ada_tests to invert the sense, and renames it to 77877 allow_ada_tests. 77878 77879 Rename to allow_aarch64_sve_tests 77880 This changes skip_aarch64_sve_tests to invert the sense, and renames 77881 it to allow_aarch64_sve_tests. 77882 77883 Rename to allow_xml_test 77884 This changes gdb_skip_xml_test to invert the sense, and renames it to 77885 allow_xml_test. 77886 77887 Use "require" for Python tests 77888 This changes various tests to use "require" for the Python feature. 77889 778902023-01-13 Tom Tromey <tom@tromey.com> 77891 77892 Fix latent bug in default_prompt_gdb_start 77893 default_prompt_gdb_start mimics default_gdb_start, but does not set 77894 the use_gdb_stub global. This caused one Python test to work only 77895 because it used the ordinary gdb_start before later using 77896 default_prompt_gdb_start. 77897 77898 This patch updates default_prompt_gdb_start to set this global as 77899 well. 77900 779012023-01-13 Tom Tromey <tom@tromey.com> 77902 77903 Remove mi_skip_python_tests 77904 mi_skip_python_tests was necessary because skip_python_tests used the 77905 running gdb, and so needed to know what prompt to expect. Now that 77906 skip_python_tests has been rewritten, mi_skip_python_tests is no 77907 longer needed. 77908 77909 Rewrite skip_python_tests 77910 This rewrites skip_python_tests to examine the output of 77911 "gdb --configuration". This is a bit nicer because it 77912 does not require an already-running gdb. 77913 77914 Use require gnat_runtime_has_debug_info 77915 This changes some tests to use "require gnat_runtime_has_debug_info". 77916 77917 Use require !skip_debuginfod_tests 77918 This changes some tests to use "require !skip_debuginfod_tests". 77919 77920 Use require using_fission 77921 This changes some tests to use "require using_fission". 77922 77923 Use require target_can_use_run_cmd 77924 This changes some tests to use "require target_can_use_run_cmd". 77925 77926 Use require !skip_opencl_tests 77927 This changes some tests to use "require !skip_opencl_tests". 77928 77929 Use require !skip_perf_tests 77930 This changes some tests to use "require !skip_perf_tests". 77931 77932 Use require gdb_trace_common_supports_arch 77933 This changes some tests to use "require gdb_trace_common_supports_arch". 77934 77935 Use require gdb_skip_xml_test 77936 This changes some tests to use "require gdb_skip_xml_test". 77937 77938 Use require !gdb_debug_enabled 77939 This changes some tests to use "require !gdb_debug_enabled". 77940 77941 Use require is_c_compiler_gcc 77942 This changes some tests to use "require is_c_compiler_gcc". 77943 77944 Use require !skip_shlib_tests 77945 This changes some tests to use "require !skip_shlib_tests". This patch 77946 cleans up a few spots that were missed in the earlier patch. 77947 77948 Use require !skip_gdbserver_tests 77949 This changes some tests to use "require !skip_gdbserver_tests". 77950 77951 Use require isnative 77952 This changes some tests to use "require isnative". 77953 77954 Use require can_spawn_for_attach 77955 This changes some tests to use "require can_spawn_for_attach". 77956 77957 Use require !use_gdb_stub 77958 This changes some tests to use "require !use_gdb_stub". 77959 77960 Use require support_go_compile 77961 This changes some tests to use "require support_go_compile". 77962 77963 Use require supports_get_siginfo_type 77964 This changes some tests to use "require supports_get_siginfo_type". 77965 77966 Use require can_single_step_to_signal_handler 77967 This changes some tests to use "require can_single_step_to_signal_handler". 77968 77969 Use require is_elf_target 77970 This changes some tests to use "require is_elf_target". 77971 77972 Use require is_amd64_regs_target 77973 This changes some tests to use "require is_amd64_regs_target". 77974 77975 Use require is_aarch32_target 77976 This changes some tests to use "require is_aarch32_target". 77977 77978 Use require is_aarch64_target 77979 This changes some tests to use "require is_aarch64_target". 77980 77981 Use require support_displaced_stepping 77982 This changes some tests to use "require support_displaced_stepping". 77983 77984 Use require !skip_avx_* 77985 This changes some tests to use "require" with !skip_avx_*. 77986 77987 Use require !skip_btrace_tests 77988 This changes some tests to use "require !skip_btrace_tests". 77989 77990 Use require !skip_btrace_pt_tests 77991 This changes some tests to use "require !skip_btrace_pt_tests" and 77992 "require !skip_tsx_tests". 77993 77994 Use require !skip_aarch64_sve_tests 77995 This changes some tests to use "require !skip_aarch64_sve_tests". 77996 77997 Use require !skip_ifunc_tests 77998 This changes some tests to use "require !skip_ifunc_tests". 77999 78000 Use require !skip_hw_watchpoint_tests 78001 This changes some tests to use "require !skip_hw_watchpoint_tests". 78002 78003 Use require !skip_ctf_tests 78004 This changes some tests to use "require !skip_ctf_tests". 78005 78006 Use require !skip_d_tests 78007 This changes some tests to use "require !skip_d_tests". 78008 78009 Use require !skip_go_tests 78010 This changes some tests to use "require !skip_go_tests". 78011 78012 Use require !skip_ada_tests 78013 This changes some tests to use "require !skip_ada_tests". 78014 78015 Use require !skip_fortran_tests 78016 This changes some tests to use "require !skip_fortran_tests". 78017 78018 Use require !skip_rust_tests 78019 This changes some tests to use "require !skip_rust_tests". 78020 78021 Use require !skip_stl_tests 78022 This changes some tests to use "require !skip_stl_tests". 78023 78024 Use require !skip_dlmopen_tests 78025 This changes some tests to use "require !skip_dlmopen_tests". 78026 78027 Use require !skip_shlib_tests 78028 This changes some tests to use "require !skip_shlib_tests". 78029 78030 Use require !skip_cplus_tests 78031 This changes some tests to use "require !skip_cplus_tests". 78032 78033 Use require is_x86_like_target 78034 This changes some tests to use "require is_x86_like_target". 78035 78036 Use require dwarf2_support 78037 This changes some tests to use "require dwarf2_support". 78038 78039 Use require supports_process_record 78040 This changes some tests to use "require supports_process_record". 78041 78042 Use require supports_reverse 78043 This changes some tests to use "require supports_reverse". 78044 780452023-01-13 Tom Tromey <tom@tromey.com> 78046 78047 Use unsupported in 'require' 78048 This changes 'require' to use 'unsupported' rather than 'untested'. 78049 The latter doesn't really seem to be correct according to the DejaGNU 78050 documentation: 78051 78052 Declares a test was not run. `untested' writes in the log file a 78053 message beginning with _UNTESTED_, appending the `message' argument. 78054 For example, you might use this in a dummy test whose only role is to 78055 record that a test does not yet exist for some feature. 78056 78057 The example there, and some text elsewhere, is what makes me think 78058 this isn't a great fit. On the other hand, 'unsupported' says: 78059 78060 Declares that a test case depends on some facility that does not exist 78061 in the testing environment. 78062 780632023-01-13 Tom Tromey <tom@tromey.com> 78064 78065 Change 'require' to accept a list of predicates 78066 This changes 'require' to accept a list of simple predicates. For 78067 now, each predicate is just the name of a proc, optionally prefixed 78068 with "!" to indicate that the result should be inverted. 78069 78070 It's possible to make this fancier, but so far I haven't done so. One 78071 idea I had is to allow a predicate to have associated text to display 78072 on failure. Another is to convert the predicates that need a running 78073 gdb (e.g., skip_python_tests) to start their own gdb, and then 78074 'require' could enforce the rule that gdb not be running when it is 78075 called. 78076 780772023-01-13 Tom Tromey <tom@tromey.com> 78078 78079 Don't use ensure_gdb_index with require 78080 This series changes 'require' to take a list of simple predicates. 78081 This patch backs out the one use of 'require' that doesn't conform to 78082 this -- calling ensure_gdb_index. 78083 780842023-01-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 78085 78086 gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp' 78087 gprofng/ChangeLog 78088 2023-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 78089 78090 PR gprofng/29987 78091 * configure.ac: Remove dependencies on libbfd and libiberty. 78092 * gprofng/src/Makefile.am: Likewise. 78093 * configure: Rebuild. 78094 * Makefile.in: Rebuild. 78095 * src/Makefile.in: Rebuild. 78096 * doc/Makefile.in: Rebuild. 78097 * gp-display-html/Makefile.in: Rebuild. 78098 780992023-01-13 Indu Bhagat <indu.bhagat@oracle.com> 78100 78101 libsframe: replace an strncat with strcat 78102 Calling strncat with the size of the src string is not so meaningful. 78103 The length argument to strncat should specify the remaining bytes 78104 bytes in the destination; although in this case, it appears to be 78105 unncessary altogether to use strncat in the first place. 78106 78107 libsframe/ 78108 * sframe-dump.c (dump_sframe_func_with_fres): Use of strcat is 78109 just as fine. 78110 781112023-01-13 Andrew Burgess <aburgess@redhat.com> 78112 78113 gdbserver: add comments to read_inferior_memory function 78114 Just adding some comments to the gdbserver read_inferior_memory 78115 function. No actual code changes. 78116 78117 gdb/infrun: add debug print in print_signal_received_reason 78118 It would have helped me to see an infrun debug line being printed from 78119 print_signal_received_reason, so I'm adding one. 78120 781212023-01-13 Andrew Burgess <aburgess@redhat.com> 78122 78123 gdb: int to bool conversion for normal_stop 78124 Change the return type of normal_stop (infrun.c) from int to bool. 78125 Update callers. 78126 78127 I've also converted the (void) to () in the function declaration and 78128 definition, given I was changing those lines anyway. 78129 78130 There should be no user visible changes after this commit. 78131 781322023-01-13 Nick Clifton <nickc@redhat.com> 78133 78134 Updated Romainian translation for the bfd sub-directory 78135 781362023-01-13 GDB Administrator <gdbadmin@sourceware.org> 78137 78138 Automatic date update in version.in 78139 781402023-01-12 Tom Tromey <tromey@adacore.com> 78141 78142 Disable ptype/o for dynamic types 78143 A user pointed out that "ptype/o" of a certain Ada type -- while in C 78144 mode -- caused gdb to crash. 78145 78146 The bug here is that dynamic types can't really be printed this way. 78147 This patch avoids the bug by disabling the "/o" feature in this case. 78148 78149 Note that using "ptype/o" in this way makes sense for the time being, 78150 because the Ada code doesn't support the "/o" feature (yet); and in 78151 any case gdb should not crash. 78152 781532023-01-12 Hans-Peter Nilsson <hp@axis.com> 78154 78155 ARM: Fix ld bloat introduced between binutils-2.38 and 2.39 78156 Since commit 9833b7757d24, "PR28824, relro security issues", 78157 ELF_MAXPAGESIZE matters much more, with regards to layout of 78158 the linked file. That commit fixed an actual bug, but also 78159 exposes a problem for targets were that value is too high. 78160 78161 For example, for ARM(32, a.k.a. "Aarch32") specifically 78162 bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU) 78163 targets pay an extra amount of up to 60 KiB of bloat in 78164 DSO:s and executables. This matters when there are many 78165 such files, and where storage is expensive. 78166 78167 It's *mostly* bloat when using a Linux kernel, as ARM(32) is 78168 a good example of an target where ELF_MAXPAGESIZE is set to 78169 an extreme value for an obscure corner-case. The ARM 78170 (32-bit) kernel has 4 KiB pages, has had that value forever, 78171 and can't be configured to any other value. The use-case is 78172 IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but 78173 not just that, but a setup where the Linux page-size is 78174 configured to something other than the *default* 4 KiB. Not 78175 sure there actually any such systems in use, again with 78176 both Aarch32 compatibility support and a non-4KiB pagesize, 78177 with all the warnings in the kernel config and requiring the 78178 "EXPERT" level set on. 78179 78180 So, let's do like x86-64 in a2267dbfc9e1 "x86-64: Use only 78181 one default max-page-size" and set ELF_MAXPAGESIZE to 4096. 78182 78183 bfd: 78184 * elf32-arm.c (ELF_MAXPAGESIZE): Always set to 0x1000. 78185 781862023-01-12 Hans-Peter Nilsson <hp@axis.com> 78187 78188 ld/testsuite: Adjust for ELF_MAXPAGESIZE 0x1000 78189 Many tests reflect a setting of ELF_MAXPAGESIZE to 64 KiB. 78190 With ELF_MAXPAGESIZE changed to 4 KiB, layout is sometimes 78191 different and symbols end up in other places. Avoid churn 78192 and regexpification of old test patterns by passing the 78193 max-page-size setting active at the time. 78194 78195 ld/testsuite: 78196 78197 * testsuite/ld-arm/arm-elf.exp, 78198 testsuite/ld-arm/non-contiguous-arm2.d, 78199 testsuite/ld-arm/non-contiguous-arm3.d, 78200 testsuite/ld-arm/non-contiguous-arm5.d, 78201 testsuite/ld-arm/non-contiguous-arm6.d, 78202 testsuite/ld-arm/thumb-plt-got.d, testsuite/ld-arm/thumb-plt.d: 78203 Pass -z max-page-size=0x10000 explicitly to test that rely on 78204 that value in output-matching patterns. 78205 782062023-01-12 Nick Alcock <nick.alcock@oracle.com> 78207 78208 libctf: ctf-link outdated input check faulty 78209 This check has a pair of faults which, combined, can lead to memory 78210 corruption. Firstly, it assumes that the values of the ctf_link_inputs 78211 hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much 78212 shorter structure. So the flags check which is the core of this is 78213 faulty (but happens, by chance, to give the right output on most 78214 architectures, since usually we happen to get a 0 here, so the test that 78215 checks this usually passes). Worse, the warning that is emitted when 78216 the test fails is added to the wrong dict -- it's added to the input 78217 dict, whose warning list is never consumed, rendering the whole check 78218 useless. But the dict it adds to is still the wrong type, so we end up 78219 overwriting something deep in memory (or, much more likely, 78220 dereferencing a garbage pointer and crashing). 78221 78222 Fixing both reveals another problem: the link input is an *archive* 78223 consisting of multiple members, so we have to consider whether to check 78224 all of them for the outdated-func-info thing we are checking here. 78225 However, no compiler exists that emits a mixture of members with this 78226 flag on and members with it off, and the linker always reserializes (and 78227 upgrades) such things when it sees them: so all members in a given 78228 archive must have the same value of the flag, so we only need to check 78229 one member per input archive. 78230 78231 libctf/ 78232 PR libctf/29983 78233 * ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of 78234 members of ctf_link_inputs right, fixing a possible spurious 78235 tesst failure / wild pointer deref / overwrite. Emit the 78236 warning message into the right dict. 78237 782382023-01-12 Nick Alcock <nick.alcock@oracle.com> 78239 78240 libctf: skip the testsuite from inside dejagnu 78241 The libctf testsuite uses Tcl try/catch to trap run_output errors. This 78242 is only supported in reasonably recent Tcls, so we detect the lack of 78243 try/catch and suppress the testsuite via an Automake conditional in its 78244 absence. 78245 78246 But this turns out not to work: Automake produces a check-DEJAGNU target 78247 regardless of the value of this conditional and sticks it in an 78248 unconditionally-executed part of the makefile, so the testsuite gets 78249 executed anyway, and fails with a nasty-looking syntax error. We can't 78250 disable it by taking "dejagnu" out of AUTOMAKE_OPTIONS, because if you 78251 do that Automake stops you using RUNTEST, RUNTESTFLAGS and other 78252 variables users would expect to work. 78253 78254 So move to disabling the testsuite from inside the testsuite itself, 78255 importing the value of the former Automake conditional as a Tcl variable 78256 and exiting very early in default.exp if it's false. 78257 78258 * configure.ac (TCL_TRY): No longer an Automake conditional. 78259 Rename to... 78260 (HAVE_TCL_TRY): ... this. 78261 * Makefile.am: Drop TCL_TRY. 78262 (development.exp): Set have_tcl_try. 78263 * testsuite/config/default.exp: Exit if have_tcl_try is false. 78264 78265 * configure: Regenerated. 78266 * Makefile.in: Likewise. 78267 782682023-01-12 Nick Alcock <nick.alcock@oracle.com> 78269 78270 ctf: fix various dreadful typos in the ctf_archive format comments 78271 When defining a format it helps to a) get the endianness right when you 78272 explicitly state what it is and b) define things in terms of fields that 78273 exist rather than fields that don't. 78274 78275 (A bunch of changes of names during implementation were not reflected in 78276 these comments...) 78277 78278 Thanks to Jose "Eye of the Eagle" Marchesi for spotting these. 78279 78280 include/ 78281 * ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of 78282 this is in little-endian byte order, not network byte order. 78283 (struct ctf_archive_modent): This is positioned right after the 78284 end fo the struct ctf_archive, not at the offset of a 78285 nonexistent field. The number of elements in the array depends 78286 on ctfa_ndicts, not another nonexistent field. 78287 782882023-01-12 Nick Clifton <nickc@redhat.com> 78289 78290 Ensure that libbacktrace/allocfail.sh is not deleted when creating release tarballs. 78291 * Makefile.am (CLEANFILES): Import patch from upstream to prevent 78292 allocafail.sh from being removed when running 'make clean'. 78293 782942023-01-12 Alan Modra <amodra@gmail.com> 78295 78296 Use __func__ rather than __FUNCTION__ 78297 We already use C99's __func__ in places, use it more generally. This 78298 patch doesn't change uses in the testsuite. I've also left one in 78299 gold.h that is protected by GCC_VERSION < 4003. If any of the 78300 remaining uses bothers anyone I invite patches. 78301 78302 bfd/ 78303 * bfd-in.h: Replace __FUNCTION__ with __func__. 78304 * elf32-bfin.c: Likewise. 78305 * elfnn-aarch64.c: Likewise. 78306 * elfxx-sparc.c: Likewise. 78307 * bfd-in2.h: Regenerate. 78308 gas/ 78309 * config/tc-cris.c: Replace __FUNCTION__ with __func__. 78310 * config/tc-m68hc11.c: Likewise. 78311 * config/tc-msp430.c: Likewise. 78312 gold/ 78313 * dwp.h: Replace __FUNCTION__ with __func__. 78314 * gold.h: Likewise, except for use inside GCC_VERSION < 4003. 78315 ld/ 78316 * emultempl/pe.em: Replace __FUNCTION__ with __func__. 78317 * emultempl/pep.em: Likewise. 78318 * pe-dll.c: Likewise. 78319 783202023-01-12 Alan Modra <amodra@gmail.com> 78321 78322 Remove myself as hppa32 maintainer 78323 Reflects the reality that I haven't done much on hppa32 for years. 78324 783252023-01-12 Mike Frysinger <vapier@gentoo.org> 78326 78327 sim: build: drop subdir Makefile.in files 78328 These aren't used anymore, so punt them all. 78329 783302023-01-12 GDB Administrator <gdbadmin@sourceware.org> 78331 78332 Automatic date update in version.in 78333 783342023-01-11 Simon Marchi <simon.marchi@polymtl.ca> 78335 78336 gdb/doc: fix install-html with Texinfo 7 78337 Starting with Texinfo 7 (this commit [1]), the output directory for the 78338 HTML doc format is gdb/doc/gdb_html, rather than gdb/doc/gdb previously. 78339 This breaks the install-html target, which expects the HTML doc to be in 78340 gdb/doc/gdb: 78341 78342 $ make install-html MAKEINFO=makeinfo DESTDIR=/tmp/install 78343 make[1]: Entering directory '/home/simark/build/binutils-gdb/gdb' 78344 make[2]: Entering directory '/home/simark/build/binutils-gdb/gdb/doc' 78345 makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc/../../readline/readline/doc -I /home/simark/src/binutils-gdb/gdb/doc/../mi -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/gdb.texinfo 78346 makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/stabs.texinfo 78347 makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/annotate.texinfo 78348 test -z "/usr/local/share/doc/gdb" || /bin/sh /home/simark/src/binutils-gdb/gdb/doc/../../mkinstalldirs "/tmp/install/usr/local/share/doc/gdb" 78349 /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/gdb' '/tmp/install/usr/local/share/doc/gdb/gdb' 78350 /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/gdb': No such file or directory 78351 /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/stabs' '/tmp/install/usr/local/share/doc/gdb/stabs' 78352 /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/stabs': No such file or directory 78353 /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/annotate' '/tmp/install/usr/local/share/doc/gdb/annotate' 78354 /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/annotate': No such file or directory 78355 make[2]: *** [Makefile:278: install-html] Error 1 78356 make[2]: Leaving directory '/home/simark/build/binutils-gdb/gdb/doc' 78357 make[1]: *** [Makefile:2240: subdir_do] Error 1 78358 make[1]: Leaving directory '/home/simark/build/binutils-gdb/gdb' 78359 make: *** [Makefile:2006: install-html] Error 2 78360 78361 Fix this by adding -o switches to the HTML targets, to force the output 78362 directories. 78363 78364 [1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a868421baf9c44227c43490687f8d6b8d6c95414 78365 78366 Change-Id: Ie147dc7b4a52eb2348005b8dc006a41b0784621f 78367 783682023-01-11 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 78369 78370 gdb: Update gdbarch.py with latest changes in gdbarch.c 78371 Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep") 78372 changed gdbarch.c without updating gdbarch.py. As a result, running 78373 gdbarch.py reverts those changes and causes the build to fail. 78374 78375 So change gdbarch.py to generate the current version of gdbarch.c. 78376 78377 Approved-By: Simon Marchi <simon.marchi@efficios.com> 78378 783792023-01-11 Tom Tromey <tromey@adacore.com> 78380 78381 Set _WIN32_WINNT in common.m4 configure check 78382 GCC recently added support for the Windows thread model, enabling 78383 libstdc++ to support Windows natively. However, this supporrt 78384 requires a version of Windows later than the minimum version that is 78385 supported by GDB. 78386 78387 PR build/29966 points out that the GDB configure test for std::thread 78388 does not work in this situation, because _WIN32_WINNT is not defined 78389 in test program, and so <thread> seems to be fine. 78390 78391 This patch is an attempt to fix the problem, by using the same setting 78392 for _WIN32_WINNT at configure time as is used at build time. 78393 78394 I don't have access to one of the older systems so I don't think I can 78395 truly test this. I did do a mingw cross build, though. I'm going to 78396 ask the bug reporter to test it. 78397 78398 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966 78399 784002023-01-11 Simon Marchi <simon.marchi@polymtl.ca> 78401 78402 [gdb/testsuite] Fix regexp in gdb.threads/dlopen-libpthread.exp 78403 Fix regexp in gdb.threads/dlopen-libpthread.exp: 78404 'libpthread\\.so' -> '/libpthread\\.so'. 78405 78406 Tested on x86_64-linux. 78407 784082023-01-11 Alan Modra <amodra@gmail.com> 78409 78410 Fix XPASS weak symbols on x86_64-mingw32 78411 Fixes commit 16fea92ccd99. 78412 78413 * testsuite/ld-scripts/weak.exp: Don't xfail x86_64 PE targets. 78414 Do xfail other PE OS triplets by moving code setting xfails. 78415 784162023-01-11 Nick Clifton <nickc@redhat.com> 78417 78418 Fix a potential illegal memory access in the BFD library when parsing a corrupt DWARF file. 78419 PR 29988 78420 * dwarf2.c (read_indexed_address): Fix check for an out of range 78421 offset. 78422 784232023-01-11 Tom de Vries <tdevries@suse.de> 78424 78425 [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, again 78426 On an x86_64 laptop running ubuntu 22.04.1 with unity desktop: 78427 ... 78428 $ echo $XDG_CURRENT_DESKTOP 78429 Unity:Unity7:ubuntu 78430 ... 78431 I have: 78432 ... 78433 $ echo $LD_PRELOAD 78434 libgtk3-nocsd.so.0 78435 ... 78436 due to package gtk3-nocsd, a package recommended by unity-session. 78437 78438 Consequently, for each exec these dependencies are pulled in, including 78439 libpthread.so.0: 78440 ... 78441 $ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 78442 libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none) 78443 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 78444 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 78445 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 78446 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 78447 ... 78448 78449 So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok: 78450 ... 78451 # of expected passes 12 78452 # of unsupported tests 1 78453 ... 78454 with LD_PRELOAD="" we have instead: 78455 ... 78456 (gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify 78457 info sharedlibrary^M 78458 From To Syms Read Shared Object Library^M 78459 $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M 78460 $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M 78461 $hex $hex Yes dlopen-libpthread.so^M 78462 (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found 78463 ... 78464 78465 The problem is that libpthread is expected as dependency of 78466 dlopen-libpthread.so, but it's missing: 78467 ... 78468 $ lddtree dlopen-libpthread.so 78469 dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none) 78470 libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6 78471 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 78472 ... 78473 due to having glibc 2.35, which has libpthread integrated into libc. 78474 78475 Fix this by: 78476 - adding a proc has_dependency 78477 - using [has_dependency $exec libpthread.so] as hint that libpthread 78478 may be preloaded 78479 - using ![has_dependency $shlib libpthread.so] to detect that 78480 the libpthread.so dependency is missing. 78481 78482 Also add a missing return after untested "no matching probes". 78483 78484 Tested on x86_64-linux, with and without LD_PRELOAD="". 78485 784862023-01-11 Jan Beulich <jbeulich@suse.com> 78487 78488 gas/RISC-V: adjust assembler for opcode table re-ordering 78489 PR gas/29940 78490 78491 With the single-operand JAL entry now sitting ahead of the two-operand 78492 one, the parsing of a two-operand insn would first try to parse an 'a'- 78493 style operand, resulting in the insertion of bogus (and otherwise 78494 unused) undefined symbols in the symbol table, having register names. 78495 Since 'a' is used as 1st operand only with J and JAL, and since JAL is 78496 the only insn _also_ allowing for a register as 1st operand (and then 78497 there being a 2nd one), special case this parsing aspect right there. 78498 78499 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 78500 785012023-01-11 Alan Modra <amodra@gmail.com> 78502 78503 Tidy some global bfd state used by gas 78504 * subsegs.c (subsegs_end): Clear abs and und userdata. 78505 785062023-01-11 Alan Modra <amodra@gmail.com> 78507 78508 now_seg after closing output file 78509 now_seg, a pointer into the output file sections, isn't valid after 78510 the output file is closed. gas doesn't and shouldn't use now_seg 78511 after this point of course, but let's be safe. 78512 78513 * output-file.c (output_file_close): Clear now_seg and now_subseg. 78514 785152023-01-11 GDB Administrator <gdbadmin@sourceware.org> 78516 78517 Automatic date update in version.in 78518 785192023-01-10 Tom Tromey <tom@tromey.com> 78520 78521 Fix bug in 'say_where' transform 78522 The patch to change say_where into a method introduced a bug. This 78523 patch fixes it. 78524 785252023-01-10 Mark Harmstone <mark@harmstone.com> 78526 78527 gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64 78528 Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to 78529 make sure that DWARF offsets are encoded correctly (they're secrels in 78530 COFF). There were remnants of this there before, but they were removed 78531 by Jedidiah's original patch - presumably because we didn't yet have 78532 .secrel32. 78533 785342023-01-10 Mark Harmstone <mark@harmstone.com> 78535 78536 Add aarch64-w64-mingw32 target 78537 This adds a mingw target for aarch64, including windres and dlltool. 78538 78539 Note that the old value of jmp_aarch64_bytes was wrong, and this does 78540 the same thing as MSVC does. 78541 785422023-01-10 Mark Harmstone <mark@harmstone.com> 78543 78544 Add .secrel32 for pe-aarch64 78545 Adds the .secrel32 pseudo-directive and its corresponding relocation. 78546 78547 Add pe-aarch64 relocations 78548 This adds the remaining pe-aarch64 relocations, and gets them working. 78549 It also brings in the constant directives from ELF, as otherwise .word 78550 would be 2 rather than 4 bytes, and .xword and .dword wouldn't be 78551 defined. 78552 785532023-01-10 Mark Harmstone <mark@harmstone.com> 78554 78555 Fix size of external_reloc for pe-aarch64 78556 This patch series finishes off the work by Jedidiah Thompson, and adds 78557 support for creating aarch64 PE images. 78558 78559 This should be essentially complete: I've used this to create a "hello 78560 world" Windows program in asm, and (with GCC patches) a UEFI program in 78561 C. I think the only things missing are the .secidx relocation, which is 78562 needed for PDBs, and the SEH pseudos used for C++ exceptions. 78563 78564 This first patch fixes the size of RELSZ; I'm not sure why it was 14 in 78565 the first place. This is the size of the "Base Relocation Block" in 78566 https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and 78567 AFAIK should be 10 for everything. 78568 785692023-01-10 Rohr, Stephan <stephan.rohr@intel.com> 78570 78571 gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type. 78572 The 'rw_pieced_value' function is executed when fetching a (lazy) 78573 variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The 78574 function checks the 'type' and 'enclosing_type' fields of the value 78575 for identity. 78576 78577 * The 'type' field describes the type of a value. 78578 * In most cases, the 'enclosing_type' field is identical to the 78579 'type' field. 78580 * Scenarios where the 'type' and 'enclosing_type' of an object 78581 differ are described in 'gdb/value.c'. Possible cases are: 78582 * If a value represents a C++ object, then the 'type' field 78583 gives the object's compile-time type. If the object actually 78584 belongs to some class derived from `type', perhaps with other 78585 base classes and additional members, then `type' is just a 78586 subobject of the real thing, and the full object is probably 78587 larger than `type' would suggest. 78588 * If 'type' is a dynamic class (i.e. one with a vtable), then GDB 78589 can actually determine the object's run-time type by looking at 78590 the run-time type information in the vtable. GDB may then elect 78591 to read the entire object. 78592 * If the user casts a variable to a different type 78593 (e.g. 'print (<type> []) <variable>'), the value's type is 78594 updated before reading the value. 78595 78596 If a lazy value is fetched, GDB allocates space based on the enclosing 78597 type's length and typically reads the 'full' object. This is not 78598 implemented for pieced values and causes an internal error if 'type' 78599 and 'enclosing_type' of a value are not identical. 78600 78601 However, GDB can read the value based on its type. Thus, this patch 78602 fixes the previously mentioned cases by removing the check for identity. 78603 78604 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605 78605 78606 gdb/ChangeLog: 78607 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> 78608 78609 * dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and 78610 'enlcosing_type' when reading pieced value 'v'. 78611 78612 gdb/testsuite/ChangeLog: 78613 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> 78614 78615 * gdb.dwarf2/shortpiece.exp: Added test cases. 78616 786172023-01-10 Tom Tromey <tromey@adacore.com> 78618 78619 Convert say_where to method on code_breakpoint 78620 'say_where' is only useful (and only called for) code breakpoints, so 78621 convert it to be a protected method on code_breakpoint. 78622 786232023-01-10 Simon Marchi <simon.marchi@polymtl.ca> 78624 78625 gdb/doc: use @value{GDBP} in some spots 78626 Examples are supposed to use @value{GDBP} instead of the literal "(gdb)" 78627 (many of them already do). Update a bunch of spots where it wasn't the 78628 case. 78629 78630 Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d 78631 786322023-01-10 Simon Marchi <simon.marchi@polymtl.ca> 78633 78634 gdb/doc: use @value{GDBN} in some spots 78635 Change some spots to use "@value{GDBN}" instead of just "GDB". 78636 78637 Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e 78638 786392023-01-10 Simon Marchi <simon.marchi@polymtl.ca> 78640 78641 gdb/doc: some whitespace fixes 78642 For consistency, replace tabs with spaces in all gdb.texinfo menus. 78643 78644 Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce 78645 786462023-01-10 Stefan Schulze Frielinghaus <stefansf@linux.ibm.com> 78647 78648 IBM zSystems: Fix offset relative to static TLS 78649 For local exec TLS relocations of the form foo@NTPOFF+x the addend was 78650 ignored. 78651 78652 bfd/ChangeLog: 78653 78654 * elf32-s390.c (elf_s390_relocate_section): Honor addend for 78655 R_390_TLS_LE32. 78656 * elf64-s390.c (elf_s390_relocate_section): Honor addend for 78657 R_390_TLS_LE64. 78658 78659 ld/ChangeLog: 78660 78661 * testsuite/ld-s390/reloctlsle-1.d: New test. 78662 * testsuite/ld-s390/reloctlsle-1.s: New test. 78663 786642023-01-10 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi> 78665 78666 PR 29981 references to init.texi 78667 786682023-01-10 Alan Modra <amodra@gmail.com> 78669 78670 Re: Move bfd_init to bfd.c 78671 Commit b1c95bc4dd73 resulted in 78672 ...bfd.texi:246: @include: could not find init.texi 78673 which went unnoticed due to not building in a clean directory. 78674 78675 This fixes the problem by moving bfd_init earlier, giving it a 78676 doc node, and stitching the nodes back together. 78677 78678 * bfd.c (bfd_init): Move earlier. Give it a doc inode. 78679 Adjust other inodes to suit. 78680 * doc/bfd.texi: Don't include init.texi. Adjust nodes to suit. 78681 786822023-01-10 Mike Frysinger <vapier@gentoo.org> 78683 78684 sim: disable recursive make in (most) subdirs 78685 Now that all (other than ppc) build in the top-level, we can disable 78686 the recursive make calls to them. This speeds things up nicely. 78687 78688 sim: common: move test-hw-events to top-level build 78689 This is an internal developer target that isn't normally compiled, 78690 but it can still be occasionally useful. Move it to the top-level 78691 build so we can kill off common/Make-common.in. 78692 78693 sim: move arch-specific file compilation of common/ files to top-level 78694 78695 sim: v850: move arch-specific file compilation to top-level 78696 The arch-specific compiler flags are duplicated, but they'll be cleaned 78697 up once we move all subdir compiles to the top-level. 78698 78699 sim: sh: move arch-specific file compilation to top-level 78700 78701 sim: rx: move arch-specific file compilation to top-level 78702 The arch-specific flags are only used by the arch-specific modules, 78703 not the common/ files, so we can delete them too. 78704 78705 sim: rl78: move arch-specific file compilation to top-level 78706 78707 sim: riscv: move arch-specific file compilation to top-level 78708 The arch-specific compiler flags are duplicated, but they'll be cleaned 78709 up once we move all subdir compiles to the top-level. 78710 78711 sim: pru: move arch-specific file compilation to top-level 78712 78713 sim: or1k: move arch-specific file compilation to top-level 78714 The arch-specific compiler flags are duplicated, but they'll be cleaned 78715 up once we move all subdir compiles to the top-level. 78716 78717 sim: msp430: move arch-specific file compilation to top-level 78718 78719 sim: moxie: move arch-specific file compilation to top-level 78720 The arch-specific flags are only used by the arch-specific modules, 78721 not the common/ files, so we can delete them too. 78722 78723 sim: mn10300: move arch-specific file compilation to top-level 78724 The arch-specific compiler flags are duplicated, but they'll be cleaned 78725 up once we move all subdir compiles to the top-level. 78726 78727 sim: mips: move arch-specific file compilation to top-level 78728 The arch-specific compiler flags are duplicated, but they'll be cleaned 78729 up once we move all subdir compiles to the top-level. 78730 78731 sim: microblaze: move arch-specific file compilation to top-level 78732 78733 sim: mcore: move arch-specific file compilation to top-level 78734 78735 sim: m68hc11: move arch-specific file compilation to top-level 78736 The arch-specific compiler flags are duplicated, but they'll be cleaned 78737 up once we move all subdir compiles to the top-level. 78738 78739 sim: m32r: move arch-specific file compilation to top-level 78740 78741 sim: m32c: move arch-specific file compilation to top-level 78742 The arch-specific flags are only used by the arch-specific modules, 78743 not the common/ files, so we can delete them too. 78744 78745 sim: lm32: move arch-specific file compilation to top-level 78746 78747 sim: iq2000: move arch-specific file compilation to top-level 78748 78749 sim: h8300: move arch-specific file compilation to top-level 78750 78751 sim: ft32: move arch-specific file compilation to top-level 78752 78753 sim: frv: move arch-specific file compilation to top-level 78754 The arch-specific flags are only used by the arch-specific modules, 78755 not the common/ files, so we can delete them too. 78756 78757 sim: example-synacor: move arch-specific file compilation to top-level 78758 78759 sim: erc32: move arch-specific file compilation to top-level 78760 The arch-specific flags are only used by the arch-specific modules, 78761 not the common/ files, so we can delete them too. 78762 78763 sim: d10v: move arch-specific file compilation to top-level 78764 78765 sim: cris: move arch-specific file compilation to top-level 78766 78767 sim: cr16: move arch-specific file compilation to top-level 78768 78769 sim: bfin: move arch-specific file compilation to top-level 78770 The arch-specific flags are only used by the arch-specific modules, 78771 not the common/ files, so we can delete them too. 78772 78773 sim: bpf: move arch-specific file compilation to top-level 78774 We can drop the arch-specific rules from the subdir as they're no 78775 longer used. 78776 78777 sim: avr: move arch-specific file compilation to top-level 78778 78779 sim: arm: move arch-specific file compilation to top-level 78780 The arch-specific flags are only used by the arch-specific modules, 78781 not the common/ files, so we can delete them too. 78782 78783 sim: aarch64: move arch-specific file compilation to top-level 78784 78785 sim: build: add basic framework for compiling arch objects in top-level 78786 The code so far has been assuming that we only compile common/ objects. 78787 Now that we're ready to compile arch-specific objects, refactor some of 78788 the flags & checks a bit to support both. 78789 78790 sim: modules.c: move generation to top-level 78791 Now that all arches create libsim.a from the top-level, we have full 78792 access to their inputs, and can move the actual generation from the 78793 subdir up to the top-level. This avoids recursive makes and will 78794 help simplify state passing between the two. 78795 78796 sim: build: drop common/nrun.o subdir hack 78797 Now that all the subdirs handle their own builds, we can drop this 78798 common rule as it's unused, and we don't want to use it anymore. 78799 78800 sim: build: drop support for creating libsim.a in subdirs 78801 Now that all ports have moved to creating libsim.a in the top-level, 78802 drop all the support code to create it in a subdir. 78803 788042023-01-10 Mike Frysinger <vapier@gentoo.org> 78805 78806 sim: v850: move libsim.a creation to top-level 78807 The objects are still compiled in the subdir, but the creation of the 78808 archive itself is in the top-level. This is a required step before we 78809 can move compilation itself up, and makes it easier to review. 78810 78811 The downside is that each object compile is a recursive make instead of 78812 a single one. On my 4 core system, it adds ~100msec to the build per 78813 port, so it's not great, but it shouldn't be a big deal. This will go 78814 away of course once the top-level compiles objects. 78815 788162023-01-10 Mike Frysinger <vapier@gentoo.org> 78817 78818 sim: sh: move libsim.a creation to top-level 78819 The objects are still compiled in the subdir, but the creation of the 78820 archive itself is in the top-level. This is a required step before we 78821 can move compilation itself up, and makes it easier to review. 78822 78823 The downside is that each object compile is a recursive make instead of 78824 a single one. On my 4 core system, it adds ~100msec to the build per 78825 port, so it's not great, but it shouldn't be a big deal. This will go 78826 away of course once the top-level compiles objects. 78827 788282023-01-10 Mike Frysinger <vapier@gentoo.org> 78829 78830 sim: rx: move libsim.a creation to top-level 78831 The objects are still compiled in the subdir, but the creation of the 78832 archive itself is in the top-level. This is a required step before we 78833 can move compilation itself up, and makes it easier to review. 78834 78835 The downside is that each object compile is a recursive make instead of 78836 a single one. On my 4 core system, it adds ~100msec to the build per 78837 port, so it's not great, but it shouldn't be a big deal. This will go 78838 away of course once the top-level compiles objects. 78839 788402023-01-10 Mike Frysinger <vapier@gentoo.org> 78841 78842 sim: rl78: move libsim.a creation to top-level 78843 The objects are still compiled in the subdir, but the creation of the 78844 archive itself is in the top-level. This is a required step before we 78845 can move compilation itself up, and makes it easier to review. 78846 78847 The downside is that each object compile is a recursive make instead of 78848 a single one. On my 4 core system, it adds ~100msec to the build per 78849 port, so it's not great, but it shouldn't be a big deal. This will go 78850 away of course once the top-level compiles objects. 78851 788522023-01-10 Mike Frysinger <vapier@gentoo.org> 78853 78854 sim: riscv: move libsim.a creation to top-level 78855 The objects are still compiled in the subdir, but the creation of the 78856 archive itself is in the top-level. This is a required step before we 78857 can move compilation itself up, and makes it easier to review. 78858 78859 The downside is that each object compile is a recursive make instead of 78860 a single one. On my 4 core system, it adds ~100msec to the build per 78861 port, so it's not great, but it shouldn't be a big deal. This will go 78862 away of course once the top-level compiles objects. 78863 788642023-01-10 Mike Frysinger <vapier@gentoo.org> 78865 78866 sim: pru: move libsim.a creation to top-level 78867 The objects are still compiled in the subdir, but the creation of the 78868 archive itself is in the top-level. This is a required step before we 78869 can move compilation itself up, and makes it easier to review. 78870 78871 The downside is that each object compile is a recursive make instead of 78872 a single one. On my 4 core system, it adds ~100msec to the build per 78873 port, so it's not great, but it shouldn't be a big deal. This will go 78874 away of course once the top-level compiles objects. 78875 788762023-01-10 Mike Frysinger <vapier@gentoo.org> 78877 78878 sim: or1k: move libsim.a creation to top-level 78879 The objects are still compiled in the subdir, but the creation of the 78880 archive itself is in the top-level. This is a required step before we 78881 can move compilation itself up, and makes it easier to review. 78882 78883 The downside is that each object compile is a recursive make instead of 78884 a single one. On my 4 core system, it adds ~100msec to the build per 78885 port, so it's not great, but it shouldn't be a big deal. This will go 78886 away of course once the top-level compiles objects. 78887 788882023-01-10 Mike Frysinger <vapier@gentoo.org> 78889 78890 sim: msp430: move libsim.a creation to top-level 78891 The objects are still compiled in the subdir, but the creation of the 78892 archive itself is in the top-level. This is a required step before we 78893 can move compilation itself up, and makes it easier to review. 78894 78895 The downside is that each object compile is a recursive make instead of 78896 a single one. On my 4 core system, it adds ~100msec to the build per 78897 port, so it's not great, but it shouldn't be a big deal. This will go 78898 away of course once the top-level compiles objects. 78899 789002023-01-10 Mike Frysinger <vapier@gentoo.org> 78901 78902 sim: moxie: move libsim.a creation to top-level 78903 The objects are still compiled in the subdir, but the creation of the 78904 archive itself is in the top-level. This is a required step before we 78905 can move compilation itself up, and makes it easier to review. 78906 78907 The downside is that each object compile is a recursive make instead of 78908 a single one. On my 4 core system, it adds ~100msec to the build per 78909 port, so it's not great, but it shouldn't be a big deal. This will go 78910 away of course once the top-level compiles objects. 78911 789122023-01-10 Mike Frysinger <vapier@gentoo.org> 78913 78914 sim: mn10300: move libsim.a creation to top-level 78915 The objects are still compiled in the subdir, but the creation of the 78916 archive itself is in the top-level. This is a required step before we 78917 can move compilation itself up, and makes it easier to review. 78918 78919 The downside is that each object compile is a recursive make instead of 78920 a single one. On my 4 core system, it adds ~100msec to the build per 78921 port, so it's not great, but it shouldn't be a big deal. This will go 78922 away of course once the top-level compiles objects. 78923 789242023-01-10 Mike Frysinger <vapier@gentoo.org> 78925 78926 sim: mips: move libsim.a creation to top-level 78927 The objects are still compiled in the subdir, but the creation of the 78928 archive itself is in the top-level. This is a required step before we 78929 can move compilation itself up, and makes it easier to review. 78930 78931 The downside is that each object compile is a recursive make instead of 78932 a single one. On my 4 core system, it adds ~100msec to the build per 78933 port, so it's not great, but it shouldn't be a big deal. This will go 78934 away of course once the top-level compiles objects. 78935 78936 The mips code is a little more tricky than others because, for multi-run 78937 targets, it generates the list of sources & objects on the fly in the 78938 configure script. 78939 789402023-01-10 Mike Frysinger <vapier@gentoo.org> 78941 78942 sim: microblaze: move libsim.a creation to top-level 78943 The objects are still compiled in the subdir, but the creation of the 78944 archive itself is in the top-level. This is a required step before we 78945 can move compilation itself up, and makes it easier to review. 78946 78947 The downside is that each object compile is a recursive make instead of 78948 a single one. On my 4 core system, it adds ~100msec to the build per 78949 port, so it's not great, but it shouldn't be a big deal. This will go 78950 away of course once the top-level compiles objects. 78951 789522023-01-10 Mike Frysinger <vapier@gentoo.org> 78953 78954 sim: mcore: move libsim.a creation to top-level 78955 The objects are still compiled in the subdir, but the creation of the 78956 archive itself is in the top-level. This is a required step before we 78957 can move compilation itself up, and makes it easier to review. 78958 78959 The downside is that each object compile is a recursive make instead of 78960 a single one. On my 4 core system, it adds ~100msec to the build per 78961 port, so it's not great, but it shouldn't be a big deal. This will go 78962 away of course once the top-level compiles objects. 78963 789642023-01-10 Mike Frysinger <vapier@gentoo.org> 78965 78966 sim: m68hc11: move libsim.a creation to top-level 78967 The objects are still compiled in the subdir, but the creation of the 78968 archive itself is in the top-level. This is a required step before we 78969 can move compilation itself up, and makes it easier to review. 78970 78971 The downside is that each object compile is a recursive make instead of 78972 a single one. On my 4 core system, it adds ~100msec to the build per 78973 port, so it's not great, but it shouldn't be a big deal. This will go 78974 away of course once the top-level compiles objects. 78975 789762023-01-10 Mike Frysinger <vapier@gentoo.org> 78977 78978 sim: m32r: move libsim.a creation to top-level 78979 The objects are still compiled in the subdir, but the creation of the 78980 archive itself is in the top-level. This is a required step before we 78981 can move compilation itself up, and makes it easier to review. 78982 78983 The downside is that each object compile is a recursive make instead of 78984 a single one. On my 4 core system, it adds ~100msec to the build per 78985 port, so it's not great, but it shouldn't be a big deal. This will go 78986 away of course once the top-level compiles objects. 78987 789882023-01-10 Mike Frysinger <vapier@gentoo.org> 78989 78990 sim: m32c: move libsim.a creation to top-level 78991 The objects are still compiled in the subdir, but the creation of the 78992 archive itself is in the top-level. This is a required step before we 78993 can move compilation itself up, and makes it easier to review. 78994 78995 The downside is that each object compile is a recursive make instead of 78996 a single one. On my 4 core system, it adds ~100msec to the build per 78997 port, so it's not great, but it shouldn't be a big deal. This will go 78998 away of course once the top-level compiles objects. 78999 790002023-01-10 Mike Frysinger <vapier@gentoo.org> 79001 79002 sim: lm32: move libsim.a creation to top-level 79003 The objects are still compiled in the subdir, but the creation of the 79004 archive itself is in the top-level. This is a required step before we 79005 can move compilation itself up, and makes it easier to review. 79006 79007 The downside is that each object compile is a recursive make instead of 79008 a single one. On my 4 core system, it adds ~100msec to the build per 79009 port, so it's not great, but it shouldn't be a big deal. This will go 79010 away of course once the top-level compiles objects. 79011 790122023-01-10 Mike Frysinger <vapier@gentoo.org> 79013 79014 sim: iq2000: move libsim.a creation to top-level 79015 The objects are still compiled in the subdir, but the creation of the 79016 archive itself is in the top-level. This is a required step before we 79017 can move compilation itself up, and makes it easier to review. 79018 79019 The downside is that each object compile is a recursive make instead of 79020 a single one. On my 4 core system, it adds ~100msec to the build per 79021 port, so it's not great, but it shouldn't be a big deal. This will go 79022 away of course once the top-level compiles objects. 79023 790242023-01-10 Mike Frysinger <vapier@gentoo.org> 79025 79026 sim: h8300: move libsim.a creation to top-level 79027 The objects are still compiled in the subdir, but the creation of the 79028 archive itself is in the top-level. This is a required step before we 79029 can move compilation itself up, and makes it easier to review. 79030 79031 The downside is that each object compile is a recursive make instead of 79032 a single one. On my 4 core system, it adds ~100msec to the build per 79033 port, so it's not great, but it shouldn't be a big deal. This will go 79034 away of course once the top-level compiles objects. 79035 790362023-01-10 Mike Frysinger <vapier@gentoo.org> 79037 79038 sim: ft32: move libsim.a creation to top-level 79039 The objects are still compiled in the subdir, but the creation of the 79040 archive itself is in the top-level. This is a required step before we 79041 can move compilation itself up, and makes it easier to review. 79042 79043 The downside is that each object compile is a recursive make instead of 79044 a single one. On my 4 core system, it adds ~100msec to the build per 79045 port, so it's not great, but it shouldn't be a big deal. This will go 79046 away of course once the top-level compiles objects. 79047 790482023-01-10 Mike Frysinger <vapier@gentoo.org> 79049 79050 sim: frv: move libsim.a creation to top-level 79051 The objects are still compiled in the subdir, but the creation of the 79052 archive itself is in the top-level. This is a required step before we 79053 can move compilation itself up, and makes it easier to review. 79054 79055 The downside is that each object compile is a recursive make instead of 79056 a single one. On my 4 core system, it adds ~100msec to the build per 79057 port, so it's not great, but it shouldn't be a big deal. This will go 79058 away of course once the top-level compiles objects. 79059 790602023-01-10 Mike Frysinger <vapier@gentoo.org> 79061 79062 sim: example-synacor: move libsim.a creation to top-level 79063 The objects are still compiled in the subdir, but the creation of the 79064 archive itself is in the top-level. This is a required step before we 79065 can move compilation itself up, and makes it easier to review. 79066 79067 The downside is that each object compile is a recursive make instead of 79068 a single one. On my 4 core system, it adds ~100msec to the build per 79069 port, so it's not great, but it shouldn't be a big deal. This will go 79070 away of course once the top-level compiles objects. 79071 790722023-01-10 Mike Frysinger <vapier@gentoo.org> 79073 79074 sim: erc32: move libsim.a creation to top-level 79075 The objects are still compiled in the subdir, but the creation of the 79076 archive itself is in the top-level. This is a required step before we 79077 can move compilation itself up, and makes it easier to review. 79078 79079 The downside is that each object compile is a recursive make instead of 79080 a single one. On my 4 core system, it adds ~100msec to the build per 79081 port, so it's not great, but it shouldn't be a big deal. This will go 79082 away of course once the top-level compiles objects. 79083 790842023-01-10 Mike Frysinger <vapier@gentoo.org> 79085 79086 sim: d10v: move libsim.a creation to top-level 79087 The objects are still compiled in the subdir, but the creation of the 79088 archive itself is in the top-level. This is a required step before we 79089 can move compilation itself up, and makes it easier to review. 79090 79091 The downside is that each object compile is a recursive make instead of 79092 a single one. On my 4 core system, it adds ~100msec to the build per 79093 port, so it's not great, but it shouldn't be a big deal. This will go 79094 away of course once the top-level compiles objects. 79095 790962023-01-10 Mike Frysinger <vapier@gentoo.org> 79097 79098 sim: cris: move libsim.a creation to top-level 79099 The objects are still compiled in the subdir, but the creation of the 79100 archive itself is in the top-level. This is a required step before we 79101 can move compilation itself up, and makes it easier to review. 79102 79103 The downside is that each object compile is a recursive make instead of 79104 a single one. On my 4 core system, it adds ~100msec to the build per 79105 port, so it's not great, but it shouldn't be a big deal. This will go 79106 away of course once the top-level compiles objects. 79107 791082023-01-10 Mike Frysinger <vapier@gentoo.org> 79109 79110 sim: cr16: move libsim.a creation to top-level 79111 The objects are still compiled in the subdir, but the creation of the 79112 archive itself is in the top-level. This is a required step before we 79113 can move compilation itself up, and makes it easier to review. 79114 79115 The downside is that each object compile is a recursive make instead of 79116 a single one. On my 4 core system, it adds ~100msec to the build per 79117 port, so it's not great, but it shouldn't be a big deal. This will go 79118 away of course once the top-level compiles objects. 79119 791202023-01-10 Mike Frysinger <vapier@gentoo.org> 79121 79122 sim: bpf: move libsim.a creation to top-level 79123 The objects are still compiled in the subdir, but the creation of the 79124 archive itself is in the top-level. This is a required step before we 79125 can move compilation itself up, and makes it easier to review. 79126 79127 The downside is that each object compile is a recursive make instead of 79128 a single one. On my 4 core system, it adds ~100msec to the build per 79129 port, so it's not great, but it shouldn't be a big deal. This will go 79130 away of course once the top-level compiles objects. 79131 791322023-01-10 Mike Frysinger <vapier@gentoo.org> 79133 79134 sim: bfin: move libsim.a creation to top-level 79135 The objects are still compiled in the subdir, but the creation of the 79136 archive itself is in the top-level. This is a required step before we 79137 can move compilation itself up, and makes it easier to review. 79138 79139 The downside is that each object compile is a recursive make instead of 79140 a single one. On my 4 core system, it adds ~100msec to the build per 79141 port, so it's not great, but it shouldn't be a big deal. This will go 79142 away of course once the top-level compiles objects. 79143 791442023-01-10 Mike Frysinger <vapier@gentoo.org> 79145 79146 sim: avr: move libsim.a creation to top-level 79147 The objects are still compiled in the subdir, but the creation of the 79148 archive itself is in the top-level. This is a required step before we 79149 can move compilation itself up, and makes it easier to review. 79150 79151 The downside is that each object compile is a recursive make instead of 79152 a single one. On my 4 core system, it adds ~100msec to the build per 79153 port, so it's not great, but it shouldn't be a big deal. This will go 79154 away of course once the top-level compiles objects. 79155 791562023-01-10 Mike Frysinger <vapier@gentoo.org> 79157 79158 sim: arm: move libsim.a creation to top-level 79159 The objects are still compiled in the subdir, but the creation of the 79160 archive itself is in the top-level. This is a required step before we 79161 can move compilation itself up, and makes it easier to review. 79162 79163 The downside is that each object compile is a recursive make instead of 79164 a single one. On my 4 core system, it adds ~100msec to the build per 79165 port, so it's not great, but it shouldn't be a big deal. This will go 79166 away of course once the top-level compiles objects. 79167 791682023-01-10 Mike Frysinger <vapier@gentoo.org> 79169 79170 sim: aarch64: move libsim.a creation to top-level 79171 The objects are still compiled in the subdir, but the creation of the 79172 archive itself is in the top-level. This is a required step before we 79173 can move compilation itself up, and makes it easier to review. 79174 79175 The downside is that each object compile is a recursive make instead of 79176 a single one. On my 4 core system, it adds ~100msec to the build per 79177 port, so it's not great, but it shouldn't be a big deal. This will go 79178 away of course once the top-level compiles objects. 79179 791802023-01-10 Mike Frysinger <vapier@gentoo.org> 79181 79182 sim: build: drop support for subdir extra deps 79183 Nothing uses this hook anymore, so punt it. It was largely used to 79184 track generated files (which we do in the top-level now) and extra 79185 header files (which we use automake depgen for now). 79186 791872023-01-10 Mike Frysinger <vapier@gentoo.org> 79188 79189 sim: modules: trigger generation from top-level 79190 Add rules for tracking generated subdir modules.c files. This doesn't 79191 actually generate the file from the top-level, but allows us to add 79192 rules that need to be ordered wrt it. Once those changes land, we can 79193 rework this to actually generate from the top-level. 79194 79195 This currently builds off of the objects that go into the libsim.a as 79196 we don't build those from the top-level either. Once we migrate that 79197 up, we can switch this to the source files directly. It's a bit hacky 79198 overall, but makes it easier to migrate things in smaller chunks, and 79199 we aren't going to keep this logic long term. 79200 792012023-01-10 Aaron Merey <amerey@redhat.com> 79202 79203 gdb/linespec.c: Fix missing source file during breakpoint re-set 79204 During breakpoint re-setting, the source_filename of an 79205 explicit_location_spec is used to lookup the symtabs associated with 79206 the breakpoint being re-set. This source_filename is compared with each 79207 known symtab filename in order to retrieve the breakpoint's symtabs. 79208 79209 However the source_filename may have been originally copied from a 79210 symtab's fullname (the path where GDB found the source file) when the 79211 breakpoint was first created. If a breakpoint symtab's filename and 79212 fullname differ and there is no substitute-path rule that converts the 79213 fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown 79214 during re-setting. 79215 79216 Fix this by using a symtab's filename to set the explicit_location_spec 79217 source_filename instead of the symtab's fullname. 79218 792192023-01-10 Aaron Merey <amerey@redhat.com> 79220 79221 gdb/linespec.c: Fix -Wmaybe-uninitialized warning 79222 Although the bool want_start_sal isn't actually used without being assigned 79223 a value, initialize it to be false in order to prevent the following 79224 -Wmaybe-uninitialized warning: 79225 79226 linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’: 79227 linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized] 79228 4150 | if (is_function && want_start_sal) 79229 792302023-01-10 GDB Administrator <gdbadmin@sourceware.org> 79231 79232 Automatic date update in version.in 79233 792342023-01-09 Alan Modra <amodra@gmail.com> 79235 79236 Set dwarf2 stash pointer earlier 79237 This fixes a memory leak in the vanishingly rare cases (found by 79238 fuzzers of course) when something goes wrong in the save_section_vma, 79239 htab_create_alloc or alloc_trie_leaf calls before *pinfo is written. 79240 If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able 79241 to free that memory. 79242 79243 * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer 79244 on setting up stash. 79245 792462023-01-09 Alan Modra <amodra@gmail.com> 79247 79248 peXXigen.c sanity checks 79249 Also fix a memory leak, and make some style changes. I tend to read 79250 (sizeof * x) as a multiplication of two variables, which I would not 79251 do if binutils followed the gcc coding conventions consistently (see 79252 https://gcc.gnu.org/codingconventions.html#Expressions). (sizeof *x) 79253 looks a lot better to me, or even (sizeof (*x)) which I've used here. 79254 79255 * peXXigen.c (get_contents_sanity_check): New function. 79256 (pe_print_idata): Use it here.. 79257 (pe_print_edata): ..and here. Free data on error return. 79258 (rsrc_parse_entry): Check entry size read from file. 79259 (rsrc_parse_entries): Style fixes. 79260 (rsrc_process_section): Use bfd_malloc_and_get_section. 79261 (_bfd_XXi_final_link_postscript): Likewise. 79262 792632023-01-09 Alan Modra <amodra@gmail.com> 79264 79265 Move mips_refhi_list to bfd tdata 79266 Similar to commit c799eddb3512, but for mips-ecoff. mips-ecoff is 79267 marked obsolete, but we still allow reading of these object files in 79268 a number of mips targets. 79269 79270 * coff-mips.c (struct mips_hi, mips_refhi_list): Delete. 79271 (mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list 79272 in ecoff_data. 79273 * ecoff.c (_bfd_ecoff_close_and_cleanup): New function. 79274 * libecoff.h (struct mips_hi): Moved from coff-mips.c. 79275 (struct ecoff_tdata): Add mips_refhi_list. 79276 (_bfd_ecoff_close_and_cleanup): Declare. 79277 792782023-01-09 Alan Modra <amodra@gmail.com> 79279 79280 Move bfd_init to bfd.c 79281 init.c contains just one function that doesn't do much. Move it to 79282 bfd.c and give it something to do, initialising static state. So far 79283 the only initialisation is for bfd.c static variables. 79284 79285 The idea behind reinitialising state is to see whether some set of 79286 flaky oss-fuzz crashes go away. oss-fuzz stresses binutils in ways 79287 that can't occur in reality, feeding multiple testcases into the 79288 internals of binutils. So one testcase may affect the result of the 79289 next testcase. 79290 79291 * init.c: Delete file. Move bfd_init to.. 79292 * bfd.c (bfd_init): ..here. Init static variables. 79293 * Makefile.am (BFD32_LIBS): Remove init.lo. 79294 (BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c. 79295 * doc/local.mk: Remove mention of init.texi and init.c. 79296 * Makefile.in: Regenerate. 79297 * bfd-in2.h: Regenerate. 79298 * po/SRC-POTFILES.in: Regenerate. 79299 793002023-01-09 Tom Tromey <tom@tromey.com> 79301 79302 Fix crash with C++ qualified names 79303 PR c++/29503 points out that something like "b->Base::member" will 79304 crash when 'b' does not have pointer type. This seems to be a simple 79305 oversight in eval_op_member. 79306 79307 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503 79308 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 79309 793102023-01-09 Simon Marchi <simon.marchi@polymtl.ca> 79311 79312 gdb/doc: fix @code{GDBN} -> @value{GDBN} 79313 Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e 79314 793152023-01-09 Christophe Lyon <christophe.lyon@arm.com> 79316 79317 Skip ld/pr23169 test on arm. 79318 The test is already skipped on several targets (including AArch64) 79319 because it's invalid. 79320 79321 * testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm. 79322 793232023-01-09 Christophe Lyon <christophe.lyon@arm.com> 79324 79325 Fix PR18841 ifunc relocation ordering 79326 In order to get the ifunc relocs properly sorted the correct class 79327 needs to be returned. The code mimics what has been done for AArch64. 79328 79329 Fixes: 79330 FAIL: Run pr18841 with libpr18841b.so 79331 FAIL: Run pr18841 with libpr18841c.so 79332 FAIL: Run pr18841 with libpr18841bn.so (-z now) 79333 FAIL: Run pr18841 with libpr18841cn.so (-z now) 79334 79335 bfd/ 79336 PR ld/18841 79337 * elf32-arm.c (elf32_arm_reloc_type_class): Return 79338 reloc_class_ifunc for ifunc symbols. 79339 79340 ld/testsuite/ 79341 * ld-arm/ifunc-12.rd: Update relocations order. 79342 * ld-arm/ifunc-3.rd: Likewise. 79343 * ld-arm/ifunc-4.rd: Likewise. 79344 793452023-01-09 Nick Clifton <nickc@redhat.com> 79346 79347 Updated transaltions for the gprof and binutils sub-directories 79348 793492023-01-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 79350 79351 testsuite: add -O0 to Intel compilers if no 'optimize' option is given 79352 icpx/icx give the following warning if '-g' is used without '-O'. 79353 79354 icpx: remark: Note that use of '-g' without any optimization-level 79355 option will turn off most compiler optimizations similar to use of 79356 '-O0'; use '-Rno-debug-disables-optimization' to disable this 79357 remark [-Rdebug-disables-optimization] 79358 79359 The warning makes dejagnu think that compilation has failed. E.g.: 79360 79361 $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" 79362 ... 79363 gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization] 79364 79365 === gdb Summary === 79366 79367 # of untested testcases 1 79368 79369 Furthermore, if no -O flag is passed, icx/icc optimize 79370 the code by default. This breaks assumptions in many GDB tests 79371 that the code is unoptimized by default. E.g.: 79372 79373 $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" 79374 ... 79375 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const' 79376 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile' 79377 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile' 79378 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator == 79379 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&) 79380 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char) 79381 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int) 79382 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)" 79383 FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple() 79384 79385 === gdb Summary === 79386 79387 # of expected passes 1 79388 # of unexpected failures 9 79389 79390 To fix both problems, pass the -O0 flag explicitly, if no optimization 79391 option is given. 79392 79393 With this patch we get, e.g.: 79394 79395 $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" 79396 ... 79397 === gdb Summary === 79398 79399 # of expected passes 19 79400 # of known failures 1 79401 79402 Approved-By: Tom Tromey <tom@tromey.com> 79403 794042023-01-09 Nils-Christian Kempke <nils-christian.kempke@intel.com> 79405 79406 testsuite: handle icc and icpc deprecated remarks 79407 Starting with icc/icpc version 2021.7.0 and higher both compilers emit a 79408 deprecation remark when used. E.g. 79409 79410 >> icc --version 79411 icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is 79412 deprecated and will be removed from product release in the second half 79413 of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended 79414 compiler moving forward. Please transition to use this compiler. Use 79415 '-diag-disable=10441' to disable this message. 79416 icc (ICC) 2021.7.0 20220713 79417 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. 79418 79419 >> icpc --version 79420 icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is 79421 deprecated ... 79422 icpc (ICC) 2021.7.0 20220720 79423 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. 79424 79425 As the testsuite compile fails when unexpected output by the compiler is 79426 seen this change in the compiler breaks all existing icc and icpc tests. 79427 This patch makes the gdb testsuite more forgiving by a) allowing the 79428 output of the remark when trying to figure out the compiler version 79429 and by b) adding '-diag-disable=10441' to the compile command whenever 79430 gdb_compile is called without the intention to detect the compiler. 79431 79432 Approved-By: Tom Tromey <tom@tromey.com> 79433 794342023-01-09 GDB Administrator <gdbadmin@sourceware.org> 79435 79436 Automatic date update in version.in 79437 794382023-01-08 Alan Modra <amodra@gmail.com> 79439 79440 PR29972, inconsistent format specification in singular form 79441 PR 29972 79442 * readelf.c (process_dynamic_section): Correct format string. 79443 794442023-01-08 GDB Administrator <gdbadmin@sourceware.org> 79445 79446 Automatic date update in version.in 79447 794482023-01-07 GDB Administrator <gdbadmin@sourceware.org> 79449 79450 Automatic date update in version.in 79451 794522023-01-06 Indu Bhagat <indu.bhagat@oracle.com> 79453 79454 sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants 79455 An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT 79456 constants. These constants are used (by gas and libsframe) to pick an 79457 SFrame FRE type based on the function size. Those constants, however, 79458 were buggy, causing the generated SFrame sections to be bloated as 79459 SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than 79460 necessary. 79461 79462 gas/ 79463 * sframe-opt.c (sframe_estimate_size_before_relax): Use 79464 typecast. 79465 (sframe_convert_frag): Likewise. 79466 79467 libsframe/ 79468 * sframe.c (sframe_calc_fre_type): Use a more appropriate type 79469 for argument. Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT 79470 to keep it warning-free but meaningful. 79471 79472 include/ 79473 * sframe-api.h (sframe_calc_fre_type): Use a more appropriate 79474 type for the argument. 79475 * sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant. 79476 (SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise. 79477 (SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise. 79478 794792023-01-06 Indu Bhagat <indu.bhagat@oracle.com> 79480 79481 libsframe: adjust an incorrect check in flip_sframe 79482 When sframe_encoder_write needs to flip the buffer containing the SFrame 79483 section before writing, it is not necessary that the SFrame FDES are in 79484 the order of their sfde_func_start_fre_off. On the contrary, SFrame 79485 FDEs will be sorted in the order of their start address. So, remove 79486 this incorrect assumption which is basically assuming that the last 79487 sfde_func_start_fre_off seen will help determine the end of the flipped 79488 buffer. 79489 79490 The function now keeps track of the bytes_flipped and then compares it with 79491 the expected value. Also, added two more checks at appropriate places: 79492 - check that the SFrame FDE read is within bounds 79493 - check that the SFrame FRE read is within bounds 79494 79495 libsframe/ 79496 79497 * sframe.c (flip_sframe): Adjust an incorrect check. 79498 Add other checks to ensure reads are within the buffer size. 79499 795002023-01-06 Jan Beulich <jbeulich@suse.com> 79501 79502 ld: yet another PDB build fix (or workaround) 79503 Older bash looks to improperly deal with backslashes in here-documents, 79504 leaving them in place on the escaped double quotes inside the parameter 79505 expansion. Convert to a model without using such a construct, by simply 79506 splitting the here-documents into three ones. 79507 795082023-01-06 Nick Clifton <nickc@redhat.com> 79509 79510 Updated Bulgarian and Russian translations for LD and BFD respectively 79511 795122023-01-06 Alan Modra <amodra@gmail.com> 79513 79514 Fix an aout memory leak 79515 * aoutx.h (aout_bfd_free_cached_info): Free line_buf. 79516 79517 Tidy pe flag in coff_data 79518 Make it a bool, use obj_pe accessor everywhere. 79519 795202023-01-06 Alan Modra <amodra@gmail.com> 79521 79522 Make coff backend data read-only 79523 The bfd_coff_backend_data struct should be read-only, the only thing 79524 preventing this is that objcopy writes to one of the fields, 79525 _bfd_coff_long_section_names. This patch creates a copy of the field 79526 in bfd coff_obj_tdata, which makes more sense anyway. When enabling 79527 long section names the intent is to do so for a particular bfd, not 79528 for all bfds that might happen to be using the target xvec. 79529 79530 bfd/ 79531 * coffcode.h: Update coff long section name comment. 79532 (bfd_coff_set_long_section_names_allowed): Use macro accessor 79533 to set flag. 79534 (bfd_coff_set_long_section_names_disallowed): Tidy. 79535 (coff_backend_info): Return a const pointer. 79536 (bfd_coff_std_swap_table, ticoff0_swap_table, ticoff1_swap_table), 79537 (bigobj_swap_table): Make const. 79538 (bfd_coff_long_section_names): Use tdata copy. 79539 (coff_mkobject): Set long_section_names from coff_backend_info. 79540 * coff-go32.c (_bfd_go32_mkobject): Likewise. 79541 * peicode.h (pe_mkobject): Likewise. 79542 * coff-sh.c (bfd_coff_small_swap_table): Make const. 79543 * libcoff-in.h (struct coff_tdata): Add long_section_names, 79544 reorder fields. 79545 * libcoff.h: Regenerate. 79546 binutils/ 79547 * objcopy.c (set_long_section_mode): Move earlier in file. 79548 (copy_object): Call set_long_section_mode here, after setting 79549 output format. 79550 (copy_file): Don't call set_long_section_mode. 79551 795522023-01-06 Bruno Larsen <blarsen@redhat.com> 79553 79554 gdb/c++: Detect ambiguous variables in imported namespaces 79555 When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB 79556 to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB 79557 will print M::x, and using clang 16.0.0 prints N::x. Not only is this 79558 behavior confusing to users, it is also not consistent with compiler 79559 behaviors, which would warn that using x is ambiguous at this point. 79560 79561 This commit makes GDB behavior consistent with compilers. it achieves 79562 this by making it so instead of exiting early when finding any symbol 79563 with the correct name, GDB continues searching through all include 79564 directives, storing all matching symbols in a relational map betwen the 79565 mangled name and the found symbols. 79566 79567 If the resulting map has more than one entry, GDB says that the 79568 reference is ambiguous and lists all possibilities. Otherwise it returns 79569 the block_symbol structure for the desired symbol, or an empty struct if 79570 nothing was found. 79571 79572 The commit also changes gdb.cp/nsusing.exp to test the ambiguous 79573 detection. 79574 795752023-01-06 Bruno Larsen <blarsen@redhat.com> 79576 79577 gdb/mi: add no-history stop reason 79578 When executing in reverse and runs out of recorded history, GDB prints 79579 a warning to the user, but does not add a reason in the stopped record, 79580 for example: 79581 79582 *stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1" 79583 79584 This problem was reported as record/29260. 79585 79586 This commit adds the reason no-history to the record, making it easier 79587 for interfaces using the mi interpreter to report the result. It also 79588 changes the test gdb.mi/mi-reverse.exp to test that the reason shows up 79589 correctly. 79590 79591 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260 79592 795932023-01-06 Bruno Larsen <blarsen@redhat.com> 79594 79595 gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clang 79596 When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99 79597 unexpected failures. They all fail to produce a complete list of 79598 completion options for a function, either overload2_function, 79599 overload3_function or anon_ns_function. This happens because clang is 79600 optimizing them away, since they are never used. 79601 79602 Fix this by adding __attribute__((used)) to all declarations to the 79603 aforementioned functions. 79604 796052023-01-06 Clément Chigot <chigot@adacore.com> 79606 79607 configure: remove dependencies on gmp and mpfr when gdb is disabled 79608 Since 991180627851801f1999d1ebbc0e569a17e47c74, the configure checks 79609 about GMP and MPFR for gdb builds have been moved to the toplevel 79610 configure. 79611 However, it doesn't take into account the --disable-gdb option. Meaning 79612 that a build without gdb will require these libraries even if not 79613 needed. 79614 79615 ChangeLog: 79616 79617 * configure.ac: Skip GMP and MPFR when --disable-gdb is 79618 provided. 79619 * configure: Regenerate. 79620 796212023-01-06 GDB Administrator <gdbadmin@sourceware.org> 79622 79623 Automatic date update in version.in 79624 796252023-01-05 Simon Marchi <simon.marchi@polymtl.ca> 79626 79627 gdbsupport: fix scoped_debug_start_end's move constructor 79628 I spotted a problem with scoped_debug_start_end's move constructor. 79629 When constructing a scoped_debug_start_end through it, it doesn't 79630 disable the moved-from object, meaning there are now two objects that 79631 will do the side-effects of decrementing the debug_print_depth global 79632 and printing the "end" message. Decrementing the debug_print_depth 79633 global twice is actually problematic, because the increments and 79634 decrements get out of sync, meaning we should hit this assertion, in 79635 theory: 79636 79637 gdb_assert (debug_print_depth > 0); 79638 79639 However, in practice, we don't see that. This is because despite the 79640 move constructor being required for this to compile: 79641 79642 template<typename PT> 79643 static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7) 79644 make_scoped_debug_start_end (PT &&pred, const char *module, const char *func, 79645 const char *start_prefix, 79646 const char *end_prefix, const char *fmt, ...) 79647 { 79648 va_list args; 79649 va_start (args, fmt); 79650 auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix, 79651 end_prefix, fmt, args); 79652 va_end (args); 79653 79654 return res; 79655 } 79656 79657 ... it is never actually called, because compilers elide the move 79658 constructors all the way (the scoped_debug_start_end gets constructed 79659 directly in the instance of the top-level caller). To confirm this, I 79660 built GDB with -fno-elide-constructors, and now I see it: 79661 79662 /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed. 79663 79664 #9 0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58 79665 #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147 79666 #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235 79667 79668 Fix this by adding an m_disabled field to scoped_debug_start_end, and 79669 setting it in the move constructor. 79670 79671 Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f 79672 796732023-01-05 Simon Marchi <simon.marchi@efficios.com> 79674 79675 gdbsupport: add gdb::string_view_hash 79676 Add the string_view_hash type, which will be useful to be able to use 79677 gdb::string_view as std::unordered_map keys. 79678 79679 Use it in gdb/symtab.c, to exercise it. 79680 79681 Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00 79682 Approved-By: Andrew Burgess <aburgess@redhat.com> 79683 796842023-01-05 Simon Marchi <simon.marchi@efficios.com> 79685 79686 gdbsupport: move fast_hash to gdbsupport/common-utils.h 79687 The following patch adds a hash type for gdb::string_view in gdbsupport, 79688 which will use the fast_hash function. Move the latter to gdbsupport. 79689 79690 Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad 79691 Approved-By: Andrew Burgess <aburgess@redhat.com> 79692 796932023-01-05 Simon Marchi <simon.marchi@efficios.com> 79694 79695 gdbsupport: move libxxhash configure check to gdbsupport 79696 The following patch moves the fast_hash function, which uses libxxhash, 79697 to gdbsupport. Move the libxxhash configure check to gdbsupport (and 79698 transitively to gdbserver). 79699 79700 Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e 79701 Approved-By: Andrew Burgess <aburgess@redhat.com> 79702 797032023-01-05 Simon Marchi <simon.marchi@polymtl.ca> 79704 79705 gdb: make gdbarch_alloc take ownership of the tdep 79706 It's currently not clear how the ownership of gdbarch_tdep objects 79707 works. In fact, nothing ever takes ownership of it. This is mostly 79708 fine because we never free gdbarch objects, and thus we never free 79709 gdbarch_tdep objects. There is an exception to that however: when 79710 initialization fails, we do free the gdbarch object that is not going to 79711 be used, and we free the tdep too. Currently, i386 and s390 do it. 79712 79713 To make things clearer, change gdbarch_alloc so that it takes ownership 79714 of the tdep. The tdep is thus automatically freed if the gdbarch is 79715 freed. 79716 79717 Change all gdbarch initialization functions to pass a new gdbarch_tdep 79718 object to gdbarch_alloc and then retrieve a non-owning reference from 79719 the gdbarch object. 79720 79721 Before this patch, the xtensa architecture had a single global instance 79722 of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated 79723 gdbarch_tdep_base instance to gdbarch_alloc, remove this global 79724 instance, and dynamically allocate one as needed, like we do for all 79725 other architectures. Make the `rmap` array externally visible and 79726 rename it to the less collision-prone `xtensa_rmap` name. 79727 79728 Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2 79729 Approved-By: Andrew Burgess <aburgess@redhat.com> 79730 797312023-01-05 Simon Marchi <simon.marchi@polymtl.ca> 79732 79733 gdb/testsuite: add back needed -re clause in gdb_breakpoint 79734 Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused, 79735 amongst others: 79736 79737 (gdb) break 1^M 79738 No line 1 in the current file.^M 79739 Make breakpoint pending on future shared library load? (y or [n]) n^M 79740 (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1 79741 FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set 79742 79743 This is because it removed one empty -re clause (matching just the 79744 prompt) that is necessary after replying "n" to the pending breakpoint 79745 question. Add this clause back. 79746 79747 Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6 79748 Approved-By: Tom de Vries <tdevries@suse.de> 79749 797502023-01-05 Tom de Vries <tdevries@suse.de> 79751 79752 [gdb/python] Avoid queue.SimpleQueue for python 3.6 79753 On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case 79754 fails as follows: 79755 ... 79756 ERROR: eof reading json header 79757 while executing 79758 "error "eof reading json header"" 79759 invoked from within 79760 "expect { 79761 -i exp19 -timeout 10 79762 -re "^Content-Length: (\[0-9\]+)\r\n" { 79763 set length $expect_out(1,string) 79764 exp_continue 79765 } 79766 -re "^(\[^\r\n\]+)..." 79767 ("uplevel" body line 1) 79768 invoked from within 79769 "uplevel $body" NONE eof reading json header 79770 UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize 79771 ... 79772 79773 Investigation using a "catch throw" shows that: 79774 ... 79775 (gdb) 79776 at gdb/python/py-utils.c:396 79777 396 error (_("Error occurred in Python: %s"), msg.get ()); 79778 (gdb) p msg.get () 79779 $1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'" 79780 ... 79781 79782 The python class queue.SimpleQueue was introduced in python 3.7. 79783 79784 Fix this by falling back to queue.Queue for python <= 3.6. 79785 79786 Tested on x86_64-linux, by successfully running the test-case: 79787 ... 79788 # of expected passes 47 79789 ... 79790 797912023-01-05 Tom Tromey <tromey@adacore.com> 79792 79793 Add type to expression dump of symbol 79794 I recently had cause to dump some expressions from gdb. I got output 79795 like this: 79796 79797 Operation: BINOP_GTR 79798 Operation: OP_VAR_VALUE 79799 Block symbol: 79800 Symbol: small_value 79801 Block: 0x39b4c20 79802 Operation: OP_LONG 79803 Operation: OP_LONG 79804 Type: int 79805 Constant: 0x0000000000000014 79806 79807 This is ok, but it would have been handy to see the type of the 79808 symbol. This patch adds this information. 79809 79810 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 79811 798122023-01-05 Nick Clifton <nickc@redhat.com> 79813 79814 Remove Stephen Casner as the PDP11 maintainer. 79815 79816 Add an extra emulation called arm64pe to the aarch64pe emulation. 79817 798182023-01-05 Andreas K. Huettel <dilfridge@gentoo.org> 79819 79820 Un xfail the PR19719 test for the AArch64 architecture 79821 798222023-01-05 Nick Clifton <nickc@redhat.com> 79823 79824 Updated Bulgarian and Russian translations for the gprof subdirectory 79825 798262023-01-05 Paul Koning <paulkoning@comcast.net> 79827 79828 PR29963, PDP11 link produces spurious relocation truncated messages 79829 PDP11 is a 16-bit processor with 16-bit logical addresses. Therefore 79830 wrapping should be allowed on the 16-bit relocs, and may as well be 79831 allowed for the 32-bit reloc too. 79832 79833 PR 29963 79834 * pdp11.c (howto_table_pdp11): Use complain_overflow_dont. 79835 798362023-01-05 Mike Frysinger <vapier@gentoo.org> 79837 79838 sim: mips: add multi source to built sources 79839 The multirun generation mode is a bit of a mess as generated run files 79840 depend on generate igen files, all with unknown names ahead of time. 79841 In the multirun mode, be lazy and declare all of these generated source 79842 files as built sources so they'll be created early on. 79843 798442023-01-05 Tsukasa OI <research_trasio@irq.a4lg.com> 79845 79846 sim: Move getopt checking inside SIM_AC_PLATFORM 79847 This commit moves getopt declaration checker originally in sim/ 79848 configure.ac; added in commit 340aa4f6872c ("sim: Check known getopt 79849 definition existence") to sim/m4/sim_ac_platform.m4 (inside the 79850 SIM_AC_PLATFORM macro). 79851 79852 It also regenerates configuration files using the maintainer mode. 79853 798542023-01-05 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 79855 79856 sim: bpf: fix testsuite due to linker warnings [PR sim/29954] 79857 On a bpf-*-* testsuite fails: 79858 ./ld/ld-new: warning: test has a LOAD segment with RWX permissions 79859 79860 Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes. 79861 79862 Tested on bpf-*-*: 79863 79864 Bug: https://sourceware.org/PR29954 79865 79866 sim/testsuite: 79867 * bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags. 79868 798692023-01-05 GDB Administrator <gdbadmin@sourceware.org> 79870 79871 Automatic date update in version.in 79872 798732023-01-04 Indu Bhagat <indu.bhagat@oracle.com> 79874 79875 MAINTAINERS: add myself as maintainer of libsframe 79876 binutils/ 79877 * MAINTAINERS: Add myself as maintainer of libsframe. 79878 798792023-01-04 H.J. Lu <hjl.tools@gmail.com> 79880 79881 x86: Remove duplicated I386_PCREL_TYPE_P/X86_64_PCREL_TYPE_P 79882 I386_PCREL_TYPE_P and X86_64_PCREL_TYPE_P are defined twice. Remove 79883 the duplications. 79884 79885 * elfxx-x86.h (I386_PCREL_TYPE_P): Remove duplication. 79886 (X86_64_PCREL_TYPE_P): Likewise. 79887 798882023-01-04 Lancelot SIX <lancelot.six@amd.com> 79889 79890 gdb: ensure test_name is initialized in gdb_breakpoint 79891 A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in 79892 gdb_breakpoint) left the $test_name variable undefined. 79893 79894 This patch fixes this. 79895 79896 Approved-By: Simon Marchi <simon.marchi@efficios.com> 79897 798982023-01-04 Tom Tromey <tromey@adacore.com> 79899 79900 Use first_opcode in another spot 79901 I found one place that could use expression::first_opcode. 79902 79903 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 79904 799052023-01-04 Tom Tromey <tromey@adacore.com> 79906 79907 Convert exp_uses_objfile to a method of expression 79908 This changes the exp_uses_objfile function to be a method of 79909 'expression'. 79910 79911 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 79912 799132023-01-04 Simon Marchi <simon.marchi@polymtl.ca> 79914 79915 gdb: use gdb_test_multiple in gdb_breakpoint 79916 When running the testsuite in a non-optimized build on a slow machine, I 79917 sometimes get: 79918 79919 UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase. 79920 79921 do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor 79922 10`, to account for the fact that reading the debug info of the gdb 79923 binary (especially in a non-optimized GDB) can take time. But then it 79924 ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded 79925 timeout of 30 seconds. 79926 79927 Fix this by making gdb_breakpoint use gdb_test_multiple, which is a 79928 desired change anyway for this kind of simple command / expected 79929 output case. 79930 79931 Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75 79932 Reviewed-By: Lancelot Six <lancelot.six@amd.com> 79933 799342023-01-04 Alan Modra <amodra@gmail.com> 79935 79936 Re: Avoid unaligned pointer reads in PEP .idata section 79937 Fix testsuite fallout. 79938 79939 * testsuite/ld-pe/cfi.d: Adjust for changed .idata padding. 79940 * testsuite/ld-pe/secidx_64.d: Likewise. 79941 * testsuite/ld-pe/secrel_64.d: Likewise. 79942 799432023-01-04 Alan Modra <amodra@gmail.com> 79944 79945 objcopy fuzzed pe out of memory 79946 This occurs when attempting to read back a section from the output 79947 file in _bfd_XX_bfd_copy_private_bfd_data_common. The copy of the 79948 section failed size sanity checking, thus it won't be written. 79949 79950 * objcopy.c (copy_object): Return false if copy_section or 79951 copy_relocations_in_section fails. 79952 799532023-01-04 Alan Modra <amodra@gmail.com> 79954 79955 fuzzed file timeout 79956 objcopy of archive, element containing an object with a fuzzed section 79957 size far exceeding the element size. copy_section detects this, but 79958 the temp file is laid out for the large section. It can take a long 79959 time to write terabytes of sparse file, a waste of time when it will 79960 be deleted. 79961 79962 * objcopy.c (copy_archive): Don't write element contents after 79963 bad status result from copy_object. 79964 799652023-01-04 Alan Modra <amodra@gmail.com> 79966 79967 asan: segv in parse_module 79968 * vms-alpha.c (parse_module): Ignore DST__K_SRC_SETFILE data 79969 if out of range. 79970 799712023-01-04 Alan Modra <amodra@gmail.com> 79972 79973 addr2line out of memory on fuzzed file 79974 Another case of fuzzers finding the section size sanity checks are 79975 avoided with SHT_NOBITS sections. 79976 79977 * dwarf2.c (read_section): Check that the DWARF section being 79978 read has contents. 79979 799802023-01-04 Andrew Burgess <aburgess@redhat.com> 79981 79982 gdb: fix some #ifdef logic in bt-utils.h 79983 In passing I spotted some incorrect #ifdef logic in bt-utils.h. The 79984 logic in question has existed since the file was originally added in 79985 commit: 79986 79987 commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0 79988 Date: Wed Aug 11 13:24:33 2021 +0100 79989 79990 gdb: use libbacktrace to create a better backtrace for fatal signals 79991 79992 The code is trying to select between using libbacktrace or using the 79993 execinfo supplied backtrace API. 79994 79995 First we check to see if we can use libbacktrace. If we can then we 79996 include some header files, and then set some defines to indicate that 79997 libbacktrace is being used. 79998 79999 Then we check if execinfo is available, if it is then we include 80000 <execinfo.h> and set some alternative defines. 80001 80002 In theory the second block of logic should not trigger if the first 80003 block (that uses libbacktrace) has also triggered, but we incorrectly 80004 check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking 80005 for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second 80006 block triggers more than it should. The 80007 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this 80008 was a mistake in the original commit. 80009 80010 In reality this is harmless, we include <execinfo.h> when we don't 80011 need too, but in by-utils.c the libbacktrace define is always checked 80012 for before the execinfo define, so we never actually end up using the 80013 execinfo path (when libbacktrace is available). But I figure its 80014 still worth cleaning this up. 80015 80016 I've tested GDB in a "default" build where libbacktrace is used, and 80017 when configuring with --disable-libbacktrace which causes the execinfo 80018 backtrace API to be used instead, both still appear to work fine. 80019 80020 There should be no user visible changes after this commit. 80021 800222023-01-04 Bruno Larsen <blarsen@redhat.com> 80023 80024 gdb: add 'maintenance print record-instruction' command 80025 While chasing some reverse debugging bugs, I found myself wondering what 80026 was recorded by GDB to undo and redo a certain instruction. This commit 80027 implements a simple way of printing that information. 80028 80029 If there isn't enough history to print the desired instruction (such as 80030 when the user hasn't started recording yet or when they request 2 80031 instructions back but only 1 was recorded), GDB warns the user like so: 80032 80033 (gdb) maint print record-instruction 80034 Not enough recorded history 80035 80036 If there is enough, GDB prints the instruction like so: 80037 80038 (gdb) maint print record-instruction 80039 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00 80040 Register eflags changed: [ IF ] 80041 Register rip changed: (void (*)()) 0x401115 <main+15> 80042 80043 Approved-by: Eli Zaretskii <eliz@gnu.org> 80044 Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com> 80045 Reviewed-by: Lancelot Six <lsix@lancelotsix.com> 80046 Approved-by: Tom Tromey <tom@tromey.com> 80047 800482023-01-04 Andreas K. Huettel <dilfridge@gentoo.org> 80049 80050 Fix AArch64 linker testsuite failures trigeered by differences in build environments. 80051 PR 29843 80052 * testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow 80053 for differences in build environments. 80054 * testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise. 80055 800562023-01-04 Mark Harmstone <mark@harmstone.com> 80057 80058 Avoid unaligned pointer reads in PEP .idata section 80059 This is something I discovered when working on aarch64, though it's 80060 relevant to x86_64 too. 80061 80062 The PE32+ imports are located in the .idata section, which starts off 80063 with a 20-byte structure for each DLL, containing offsets into the rest 80064 of the section. This is the Import Directory Table in 80065 https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, which 80066 is a concatenation of the .idata$2 sections. This is then followed by an 80067 20 zero bytes generated by the linker script, which calls this .idata$3. 80068 80069 After this comes the .idata$4 entries for each function, which the 80070 loader overwrites with the function pointers. Because there's no padding 80071 between .idata$3 and .idata$4, this means that if there's an even number 80072 of DLLs, the function pointers won't be aligned on an 8-byte boundary. 80073 80074 Misaligned reads are slower on x86_64, but this is more important on 80075 aarch64, as the e.g. `ldr x0, [x0, :lo12:__imp__func]` the compiler 80076 might generate requires __imp__func (the .idata$4 entry) to be aligned 80077 to 8 bytes. Without this you get IMAGE_REL_ARM64_PAGEOFFSET_12L overflow 80078 errors. 80079 800802023-01-04 Alan Modra <amodra@gmail.com> 80081 80082 Merge config/picflag.m4 from gcc 80083 and regen libiberty/configure 80084 800852023-01-04 Tsukasa OI <research_trasio@irq.a4lg.com> 80086 80087 sim: Regenerate using the maintainer mode 80088 Those files have changed by regenerating using the maintainer mode. 80089 The first line of sim/ppc/pk.h have changed by an effect of the commit 80090 319e41e83a40 ("sim: ppc: inline the sim-packages option"). 80091 800922023-01-04 GDB Administrator <gdbadmin@sourceware.org> 80093 80094 Automatic date update in version.in 80095 800962023-01-03 Max Filippov <jcmvbkbc@gmail.com> 80097 80098 opcodes: xtensa: fix jump visualization for FLIX 80099 opcodes/ 80100 * xtensa-dis.c (print_insn_xtensa): Add local variables 80101 insn_type, target and imm_pcrel to track control flow across 80102 multiple slots. 80103 80104 opcodes: xtensa: implement styled disassembly 80105 opcodes/ 80106 * xtensa-dis.c (print_xtensa_operand) 80107 (print_insn_xtensa): Replace fprintf_func with 80108 fprintf_styled_func. 80109 801102023-01-03 Tom Tromey <tromey@adacore.com> 80111 80112 Add test case for "finish" with variably-sized types 80113 This adds a test case for "finish" with variably-sized types, and for 80114 inferior calls as well. This also extends the "runto" proc to handle 80115 temporary breakpoints. 80116 80117 Use value_at_non_lval in get_call_return_value 80118 get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION, 80119 because the call is completely managed by gdb. However, it does not 80120 handle variably-sized types correctly. The simplest way to fix this 80121 is to use value_at_non_lval, which does type resolution. 80122 80123 Fix inferior calls with variably-sized return type 80124 This patch updates the gdbarch_return_value_as_value implementations 80125 to work correctly with variably-sized return types. 80126 80127 Convert selected architectures to gdbarch_return_value_as_value 80128 This converts a few selected architectures to use 80129 gdbarch_return_value_as_value rather than gdbarch_return_value. The 80130 architectures are just the ones that I am able to test. This patch 80131 should not introduce any behavior changes. 80132 801332023-01-03 Tom Tromey <tromey@adacore.com> 80134 80135 Don't let property evaluation affect the current language 80136 On PPC, we saw that calling an inferior function could sometimes 80137 change the current language, because gdb would select the call dummy 80138 frame -- associated with _start. 80139 80140 This patch changes gdb so that the current language is never affected 80141 by DWARF property evaluation. 80142 801432023-01-03 Tom Tromey <tromey@adacore.com> 80144 80145 Introduce value_at_non_lval 80146 In some cases, while a value might be read from memory, gdb should not 80147 record the value as being equivalent to that memory. 80148 80149 In Ada, the inferior call code will call ada_convert_actual -- and 80150 here, if the argument is already in memory, that address will simply 80151 be reused. However, for a call like "f(g())", the result of "g" might 80152 be on the stack and thus overwritten by the call to "f". 80153 80154 This patch introduces a new function that is like value_at but that 80155 ensures that the result is non-lvalue. 80156 801572023-01-03 Tom Tromey <tromey@adacore.com> 80158 80159 Don't emit gdbarch_return_value 80160 The previous patch introduced a new overload of gdbarch_return_value. 80161 The intent here is that this new overload always be called by the core 80162 of gdb -- the previous implementation is effectively deprecated, 80163 because a call to the old-style method will not work with any 80164 converted architectures (whereas calling the new-style method is will 80165 delegate when needed). 80166 80167 This patch changes gdbarch.py so that the old gdbarch_return_value 80168 wrapper function can be omitted. This will prevent any errors from 80169 creeping in. 80170 801712023-01-03 Tom Tromey <tromey@adacore.com> 80172 80173 Add new overload of gdbarch_return_value 80174 The gdbarch "return_value" can't correctly handle variably-sized 80175 types. The problem here is that the TYPE_LENGTH of such a type is 0, 80176 until the type is resolved, which requires reading memory. However, 80177 gdbarch_return_value only accepts a buffer as an out parameter. 80178 80179 Fixing this requires letting the implementation of the gdbarch method 80180 resolve the type and return a value -- that is, both the contents and 80181 the new type. 80182 80183 After an attempt at this, I realized I wouldn't be able to correctly 80184 update all implementations (there are ~80) of this method. So, 80185 instead, this patch adds a new method that falls back to the current 80186 method, and it updates gdb to only call the new method. This way it's 80187 possible to incrementally convert the architectures that I am able to 80188 test. 80189 801902023-01-03 Tom Tromey <tromey@adacore.com> 80191 80192 Fix crash in amd64-tdep.c 80193 amd64-tdep.c could crash when 'finish'ing from a function whose return 80194 type had variable length. In this situation, the value will be passed 80195 by reference, and this patch avoids the crash. 80196 80197 (Note that this does not fully fix the bug reported, but it does fix 80198 the crash, so it seems worthwhile to land independently.) 80199 802002023-01-03 Tom de Vries <tdevries@suse.de> 80201 80202 [gdb/testsuite] Add xfail in gdb.arch/i386-pkru.exp 80203 On a x86_64-linux machine with pkru register, I run into: 80204 ... 80205 (gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value 80206 info register pkru^M 80207 pkru 0x12345678 305419896^M 80208 (gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value 80209 ... 80210 80211 This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU 80212 onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356 80213 ("x86/fpu: Allow PKRU to be (once again) written by ptrace."). 80214 80215 The regression occurs for kernel versions v5.14-rc1 (the first tag containing 80216 the regression) up to but excluding v6.2-rc1 (the first tag containing the fix). 80217 80218 Fix this by adding an xfail for the appropriate kernel versions. 80219 80220 Tested on x86_64-linux. 80221 80222 PR testsuite/29790 80223 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790 80224 802252023-01-03 Tom Tromey <tromey@adacore.com> 80226 80227 Do not use PyObject_CallNoArgs 80228 PyObject_CallNoArgs was introduced in Python 3.9, so avoid it in favor 80229 of PyObject_CallObject. 80230 802312023-01-03 Himal <himalr@proton.me> 80232 80233 Fix a potential problem in the BFD library when accessing the Windows' nul device driver. 80234 PR 29947 80235 * bfdio.c (_bfd_real_fopen): Do not add a prefix to the Windows' 80236 nul device filename. 80237 802382023-01-03 Nick Clifton <nickc@redhat.com> 80239 80240 Fix a translation problem in the x86 assembler. 80241 PR 29952 80242 * config/tc-i386.c (md_assemble): Avoid constructing translatable 80243 strings. 80244 80245 Updated translations for various languages and sub-directories 80246 802472023-01-03 Luis Machado <luis.machado@arm.com> 80248 80249 Add new NT_ARM_ZA and NT_ARM_SSVE register set constants. 80250 802512023-01-03 Andrew Burgess <aburgess@redhat.com> 80252 80253 [gdb] Fix segfault during inferior call to ifunc 80254 With a simple test-case: 80255 ... 80256 $ cat test.c 80257 char *p = "a"; 80258 int main (void) { 80259 return strlen (p); 80260 } 80261 $ gcc -g test.c 80262 ... 80263 we run into this segfault: 80264 ... 80265 $ gdb -q -batch a.out -ex start -ex "p strlen (p)" 80266 Temporary breakpoint 1 at 0x1151: file test.c, line 4. 80267 [Thread debugging using libthread_db enabled] 80268 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 80269 80270 Temporary breakpoint 1, main () at test.c:4 80271 4 return strlen (p); 80272 80273 Fatal signal: Segmentation fault 80274 ... 80275 80276 The strlen is an ifunc, and consequently during the call to 80277 call_function_by_hand_dummy for "p strlen (p)" another call 80278 to call_function_by_hand_dummy is used to resolve the ifunc. 80279 80280 This invalidates the get_current_frame () result in the outer call. 80281 80282 Fix this by using prepare_reinflate and reinflate. 80283 80284 Note that this series ( 80285 https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ ) 80286 should address this problem, but this patch is a simpler fix which is easy to 80287 backport. 80288 80289 Tested on x86_64-linux. 80290 80291 Co-Authored-By: Tom de Vries <tdevries@suse.de> 80292 PR gdb/29941 80293 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941 80294 802952023-01-03 Mike Frysinger <vapier@gentoo.org> 80296 80297 sim: sh: move some generated source files to built sources 80298 This should have been part of the previous commit 80636a54bcfa2bca3dc8f 80299 ("sim: build: move generated headers to built sources"), but they were 80300 missed because they're .c files effectively treated as .h files. 80301 80302 sim: build: add var for tracking sim enable directly 80303 Rather than rely on SIM_SUBDIRS being set, add a dedicated variable 80304 to track whether to enable the sim. While the current code works 80305 fine, it won't work as we remove the recursive make logic (i.e. the 80306 SIM_SUBDIRS variable). 80307 80308 sim: common: drop libcommon.a linkage 80309 All of these objects should be in libsim.a already, so don't link to 80310 it too. In practice it never gets used, but no point in listing it. 80311 803122023-01-03 Mike Frysinger <vapier@gentoo.org> 80313 80314 sim: build: move generated headers to built sources 80315 Automake's automatic header deptracking has a bootstrap problem where 80316 it can't detect generated headers when compiling. We've been handling 80317 that by adding a custom SIM_ALL_RECURSIVE_DEPS variable, but that only 80318 works when building objects recursively in subdirs. As we move those 80319 out to the top-level, we don't have any recursive steps anymore. The 80320 Automake approach is to declare those headers in BUILT_SOURCES. 80321 80322 This isn't completely foolproof as the Automake manual documents: it 80323 only activates for `make all`, not `make foo.o`, but that shouldn't be 80324 a huge limitation as it only affects the initial compile. After that, 80325 rebuilds should work fine. 80326 803272023-01-03 Mike Frysinger <vapier@gentoo.org> 80328 80329 sim: cgen: drop common subdir build rules 80330 Now that everything has been hoisted to the top-level, we can delete 80331 this unused logic. 80332 80333 sim: or1k: hoist cgen rules to top-level 80334 80335 sim: m32r: hoist cgen rules to top-level 80336 80337 sim: lm32: hoist cgen rules to top-level 80338 80339 sim: iq2000: hoist cgen rules to top-level 80340 80341 sim: frv: hoist cgen rules to top-level 80342 80343 sim: cris: hoist cgen rules to top-level 80344 80345 sim: bpf: hoist cgen rules to top-level 80346 80347 sim: cgen: hoist rules to the top-level build 80348 The rules seem to generate the same output as existing subdir cgen 80349 rules with cgen ports, so hopefully this should be correct. These 80350 are the last set of codegen rules that we run in subdirs, so this 80351 will help unblock killing off subdir builds entirely. 80352 80353 sim: build: use Automake include vars 80354 Rather than define our own hack for emitting an include statement, 80355 use the existing Automake include variables. These have the nice 80356 side-effect of being more portable. 80357 803582023-01-03 GDB Administrator <gdbadmin@sourceware.org> 80359 80360 Automatic date update in version.in 80361 803622023-01-02 Tom Tromey <tromey@adacore.com> 80363 80364 Simplify debug_exp 80365 debug_exp should call expression::dump rather than using the 'op' 80366 member. 80367 803682023-01-02 Tom Tromey <tromey@adacore.com> 80369 80370 Initial implementation of Debugger Adapter Protocol 80371 The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use 80372 to communicate with debuggers. You can find more information here: 80373 80374 https://microsoft.github.io/debug-adapter-protocol/ 80375 80376 Frequently this is implemented as a shim, but it seemed to me that GDB 80377 could implement it directly, via the Python API. This patch is the 80378 initial implementation. 80379 80380 DAP is implemented as a new "interp". This is slightly weird, because 80381 it doesn't act like an ordinary interpreter -- for example it doesn't 80382 implement a command syntax, and doesn't use GDB's ordinary event loop. 80383 However, this seemed like the best approach overall. 80384 80385 To run GDB in this mode, use: 80386 80387 gdb -i=dap 80388 80389 The DAP code will accept JSON-RPC messages on stdin and print 80390 responses to stdout. GDB redirects the inferior's stdout to a new 80391 pipe so that output can be encapsulated by the protocol. 80392 80393 The Python code uses multiple threads to do its work. Separate 80394 threads are used for reading JSON from the client and for writing JSON 80395 to the client. All GDB work is done in the main thread. (The first 80396 implementation used asyncio, but this had some limitations, and so I 80397 rewrote it to use threads instead.) 80398 80399 This is not a complete implementation of the protocol, but it does 80400 implement enough to demonstrate that the overall approach works. 80401 80402 There is a rudimentary test suite. It uses a JSON parser written in 80403 pure Tcl. This parser is under the same license as Tcl itself, so I 80404 felt it was acceptable to simply import it into the tree. 80405 80406 There is also a bit of documentation -- just documenting the new 80407 interpreter name. 80408 804092023-01-02 Jonas Hoerberg <JHorberg@danfoss.com> 80410 80411 Fix target remote pipe command for MinGW 80412 The cced7cacecad104fff0 ("gdb: preserve `|` in connection details string") 80413 commit added '|' detection and removal to ser-pipe.c, but missed to add it 80414 to ser-mingw.c. 80415 80416 This results in the error message below for MinGW hosts: 80417 error starting child process '| <executable> <args>': CreateProcess: No such file or directory 80418 80419 This commit add the missing '|' detection and removal to ser-mingw.c. 80420 804212023-01-02 Tom Tromey <tromey@adacore.com> 80422 80423 Remove target: prefix from gdb_sysroot in find_separate_debug_file 80424 I noticed that, when using gdbserver, gdb might print: 80425 80426 Reading /usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target... 80427 Reading target:/usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target... 80428 80429 The second line has the "target:" prefix, but from the code it's clear 80430 that this string is being passed verbatim to gdbserver -- which seems 80431 wrong. 80432 80433 I filed PR remote/29929 for this. 80434 80435 The problem here is that find_separate_debug_file uses gdb_sysroot 80436 without checking to see if it starts with the "target:" prefix. This 80437 patch changes this code to be a little more careful. 80438 80439 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29929 80440 804412023-01-02 Tom de Vries <tdevries@suse.de> 80442 80443 [gdb/testsuite] Fix gdb.python/py-breakpoint.exp with libstdc++ debug info 80444 On x86_64-linux, I run into: 80445 ... 80446 (gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M 80447 Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M 80448 (gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \ 80449 Set hardware breakpoint 80450 ... 80451 due to libstdc++ debug info: 80452 ... 80453 $ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \ 80454 -ex start \ 80455 -ex "b add" \ 80456 -ex "info break" 80457 Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50. 80458 80459 Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50 80460 50 int foo = 5; 80461 Breakpoint 2 at 0x40072e: add. (7 locations) 80462 Num Type Disp Enb Address What 80463 2 breakpoint keep y <MULTIPLE> 80464 2.1 y 0x000000000040072e in add(int) at \ 80465 py-breakpoint.c:39 80466 2.2 y 0x00007ffff7b131de in \ 80467 (anonymous namespace)::fast_float::bigint::add at \ 80468 ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815 80469 ... 80470 2.7 y 0x00007ffff7b137e4 in \ 80471 (anonymous namespace)::fast_float::bigint::add at \ 80472 ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815 80473 ... 80474 80475 Fix this by using qualified=True. 80476 80477 Tested on x86_64-linux. 80478 PR testsuite/29910 80479 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910 80480 804812023-01-02 Mike Frysinger <vapier@gentoo.org> 80482 80483 sim: replace -I$srcroot/bfd include with -I$srcroot 80484 Clean up includes a bit by making ports include bfd/ headers 80485 explicitly. This matches other projects, and makes it more clear 80486 where these headers are coming from. 80487 80488 sim: replace -I$srcroot/opcodes include with -I$srcroot 80489 Clean up includes a bit by making ports include opcodes/ headers 80490 explicitly. This matches other projects, and makes it more clear 80491 where these headers are coming from. 80492 804932023-01-02 Alan Modra <amodra@gmail.com> 80494 80495 obsolete target tidy 80496 Delete a few files only used for obsolete targets, and tidy config, 80497 xfails and other pieces of support specific to those targets. And 80498 since I was editing target triplets in test files, fix the nm 80499 alpha-linuxecoff fails. 80500 805012023-01-02 GDB Administrator <gdbadmin@sourceware.org> 80502 80503 Automatic date update in version.in 80504 805052023-01-01 Mike Frysinger <vapier@gentoo.org> 80506 80507 sim: build: drop unused SIM_EXTRA_LIBS 80508 Now that all run binaries are linked in the topdir, this subdir libs 80509 variable isn't used anywhere, so punt it. 80510 80511 sim: erc32: drop -I$(srcroot) 80512 Since the port doesn't actually use this include, drop it. 80513 No other port is doing this either. 80514 80515 sim: drop mention of & support for subdir configure 80516 Now that no ports use these common configure APIs, delete the logic 80517 and remove it from the documentation. 80518 80519 sim: refresh copyright dates a bit 80520 Update a few files that were missed, and revert the generated Automake 80521 output that uses dates from Automake itself. 80522 80523 sim: or1k: drop unused rules 80524 These rules are the same as the common ones, so drop them to simplify. 80525 80526 sim: iq2000: drop unused cpu define logic 80527 These defines seem to have been added in anticipation of adding another 80528 cpu port (IQ10BF?), but that was over 20 years ago, and that port has 80529 yet to materialize. So drop these compile flags since they don't do 80530 anything to the generated code. If another port ever shows up, it's 80531 easy enough to readd things as needed. 80532 805332023-01-01 Joel Brobecker <brobecker@adacore.com> 80534 80535 manual copyright year range of various GDB files to add 2023 80536 This commit updates the following file... 80537 80538 gdb/doc/gdb.texinfo 80539 gdb/doc/refcard.tex 80540 gdb/syscalls/update-netbsd.sh 80541 80542 ... by hand as instructed by the gdb/copyright.py script. 80543 The update by hand is needed because the copyright headers 80544 to update are actually nested inside those files, rather 80545 than located at the start of the file. 80546 805472023-01-01 Joel Brobecker <brobecker@adacore.com> 80548 80549 Update copyright year range in header of all files managed by GDB 80550 This commit is the result of running the gdb/copyright.py script, 80551 which automated the update of the copyright year range for all 80552 source files managed by the GDB project to be updated to include 80553 year 2023. 80554 805552023-01-01 Joel Brobecker <brobecker@adacore.com> 80556 80557 gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions... 80558 ... to sim/ppc/powerpc.igen 80559 80560 This file is in the NOT_FSF_LIST because this file has a copyright 80561 which is not assigned to the FSF. Since the file got renamed, 80562 the corresponding entry in NOT_FSF_LIST needs to be renamed as well. 80563 805642023-01-01 Joel Brobecker <brobecker@adacore.com> 80565 80566 Update copyright year in help message of gdb, gdbserver, gdbreplay 80567 This commit updates the copyright year displayed by gdb, gdbserver 80568 and gdbreplay's help message from 2022 to 2023, as per our Start 80569 of New Year procedure. The corresponding source files' copyright 80570 header are also updated accordingly. 80571 805722023-01-01 Alan Modra <amodra@gmail.com> 80573 80574 Update year range in gprofng copyright notices 80575 This adds 'Innovative Computing Labs' as an external author to 80576 update-copyright.py, to cover the copyright notice in 80577 gprofng/common/opteron_pcbe.c, and uses that plus another external 80578 author 'Oracle and' to update gprofng copyright dates. I'm not going 80579 to commit 'Oracle and' as an accepted author, but that covers the 80580 string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All 80581 rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog 80582 files. 80583 80584 Update year range in copyright notice of binutils files 80585 The newer update-copyright.py fixes file encoding too, removing cr/lf 80586 on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and 80587 embedded cr in binutils/testsuite/binutils-all/ar.exp string match. 80588 805892023-01-01 Alan Modra <amodra@gmail.com> 80590 80591 Update etc/update-copyright.py 80592 This picks up some improvements from gcc/contrib. exceptions must 80593 derive from BaseException, port to python3, retain original file mode, 80594 fix name of script in examples. 80595 80596 Adds libsframe to list of default dirs. I would have added gprofng 80597 too but there are some files claiming copyright by authors other than 80598 the Free Software Foundation. 80599 806002023-01-01 GDB Administrator <gdbadmin@sourceware.org> 80601 80602 Automatic date update in version.in 80603 806042022-12-31 Nick Clifton <nickc@redhat.com> 80605 80606 Update version numbers in howto-make-a-release document 80607 80608 Update version number and regenerate files 80609 80610 Add markers for 2.40 branch 80611 80612 sync libiberty sources with gcc mainline 80613 806142022-12-31 Tom de Vries <tdevries@suse.de> 80615 80616 [gdb/cli] Add maintenance ignore-probes 80617 There's a command "disable probes", but SystemTap probes, for instance 80618 libc:longjmp cannot be disabled: 80619 ... 80620 $ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$" 80621 ... 80622 Probe libc:longjmp cannot be disabled. 80623 Probe libc:longjmp cannot be disabled. 80624 Probe libc:longjmp cannot be disabled. 80625 ... 80626 80627 Add a command "maintenance ignore-probes" that ignores probes during 80628 get_probes, such that we can easily pretend to use a libc without the 80629 libc:longjmp probe: 80630 ... 80631 (gdb) maint ignore-probes -verbose libc ^longjmp$ 80632 ignore-probes filter has been set to: 80633 PROVIDER: 'libc' 80634 PROBE_NAME: '^longjmp$' 80635 OBJNAME: '' 80636 (gdb) start ^M 80637 ... 80638 Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M 80639 Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M 80640 Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M 80641 ... 80642 80643 The "Ignoring ..." messages can be suppressed by not using -verbose. 80644 80645 Note that as with "disable probes", running simply "maint ignore-probes" 80646 ignores all probes. 80647 80648 The ignore-probes filter can be reset by using: 80649 ... 80650 (gdb) maint ignore-probes -reset 80651 ignore-probes filter has been reset 80652 ... 80653 80654 For now, the command is only supported for SystemTap probes. 80655 80656 PR cli/27159 80657 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159 80658 806592022-12-31 Mark Harmstone <mark@harmstone.com> 80660 80661 ld/testsuite: Don't add index to sizes in pdb.exp 80662 80663 ld: Handle LF_VFTABLE types in PDBs 80664 806652022-12-31 Mark Harmstone <mark@harmstone.com> 80666 80667 ld: Handle extended-length data structures in PDB types 80668 A few fixes to minor issues I've discovered in my PDB patches. 80669 80670 * If sizes or offsets are greater than 0x8000, they get encoded as 80671 extended values in the same way as for enum values - e.g. a LF_ULONG 80672 .short followed by a .long. 80673 80674 * I've managed to coax MSVC to produce another type, LF_VFTABLE, which 80675 is seen when dealing with COM. I don't think LLVM emits this. Note that 80676 we can't just implement everything in Microsoft's header files, as most 80677 of it is obsolete. 80678 80679 * Fixes a stupid bug in the test program, where I was adding an index to 80680 a size. The index was hard-coded to 0, so this didn't cause any actual 80681 issues. 80682 806832022-12-31 Nick Clifton <nickc@redhat.com> 80684 80685 Updated Romanian translation for the binutils sub-directory 80686 806872022-12-31 Tom de Vries <tdevries@suse.de> 80688 80689 [gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32 80690 [ Partial resubmission of an earlier submission by Andrew ( 80691 https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so 80692 listing him as co-author. ] 80693 80694 With x86_64-linux and target board unix/-m32, we have: 80695 ... 80696 (gdb) continue^M 80697 Continuing.^M 80698 Exception #10^M 80699 ^M 80700 Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M 80701 23 throw new int (e);^M 80702 (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ 80703 check FinishBreakpoint in catch() 80704 ... 80705 80706 The following scenario happens: 80707 - set breakpoint in throw_exception_1, a function that throws an exception 80708 - continue 80709 - hit breakpoint, with call stack main.c:38 -> throw_exception_1 80710 - set a finish breakpoint 80711 - continue 80712 - hit the breakpoint again, with call stack main.c:48 -> throw_exception 80713 -> throw_exception_1 80714 80715 Due to the exception, the function call did not properly terminate, and the 80716 finish breakpoint didn't trigger. This is expected behaviour. 80717 80718 However, the intention is that gdb detects this situation at the next stop 80719 and calls the out_of_scope callback, which would result here in this test-case 80720 in a rather confusing "exception did not finish" message. So the problem is 80721 that this message doesn't show up, in other words, the out_of_scope callback 80722 is not called. 80723 80724 [ Note that the fact that the situation is detected only at the next stop 80725 (wherever that happens to be) could be improved upon, and the earlier 80726 submission did that by setting a longjmp breakpoint. But I'm considering this 80727 problem out-of-scope for this patch. ] 80728 80729 Note that the message does show up later, at thread exit: 80730 ... 80731 [Inferior 1 (process 20046) exited with code 0236]^M 80732 exception did not finish ...^M 80733 ... 80734 80735 The decision on whether to call the out_of_scope call back is taken in 80736 bpfinishpy_detect_out_scope_cb, and the interesting bit is here: 80737 ... 80738 if (b->pspace == current_inferior ()->pspace 80739 && (!target_has_registers () 80740 || frame_find_by_id (b->frame_id) == NULL)) 80741 bpfinishpy_out_of_scope (finish_bp); 80742 ... 80743 80744 In the case of the thread exit, the callback triggers because 80745 target_has_registers () == 0. 80746 80747 So why doesn't the callback trigger in the case of the breakpoint? 80748 80749 Well, the b->frame_id is the frame_id of the frame of main (the frame 80750 in which the finish breakpoint is supposed to trigger), so AFAIU 80751 frame_find_by_id (b->frame_id) == NULL will only be true once we've 80752 left main, at which point I guess we don't stop till thread exit. 80753 80754 Fix this by saving the frame in which the finish breakpoint was created, and 80755 using frame_find_by_id () == NULL on that frame instead, such that we have: 80756 ... 80757 (gdb) continue^M 80758 Continuing.^M 80759 Exception #10^M 80760 ^M 80761 Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M 80762 23 throw new int (e);^M 80763 exception did not finish ...^M 80764 (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ 80765 check FinishBreakpoint in catch() 80766 ... 80767 80768 Still, the test-case is failing because it's setup to match the behaviour that 80769 we get on x86_64-linux with target board unix/-m64: 80770 ... 80771 (gdb) continue^M 80772 Continuing.^M 80773 Exception #10^M 80774 stopped at ExceptionFinishBreakpoint^M 80775 (gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \ 80776 check FinishBreakpoint in catch() 80777 ... 80778 80779 So what happens here? Again, due to the exception, the function call did not 80780 properly terminate, but the finish breakpoint still triggers. This is somewhat 80781 unexpected. This happens because it just so happens to be that the frame 80782 return address at which the breakpoint is set, is also the first instruction 80783 after the exception has been handled. This is a know problem, filed as 80784 PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope 80785 callback. 80786 80787 Also add a breakpoint after setting the finish breakpoint but before throwing 80788 the exception, to check that we don't call the out_of_scope callback too early. 80789 80790 Tested on x86_64-linux, with target boards unix/-m32. 80791 80792 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 80793 PR python/27247 80794 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247 80795 807962022-12-31 Tom de Vries <tdevries@suse.de> 80797 80798 [gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1 80799 On ubuntu 22.04.1 x86_64, I run into: 80800 ... 80801 (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \ 80802 set print symbol-loading off 80803 sharedlibrary .*^M 80804 Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M 80805 Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M 80806 (gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib 80807 ... 80808 80809 The test-case expects the libc.so line, but not the libpthread.so line. 80810 80811 However, we have: 80812 ... 80813 $ ldd /lib/x86_64-linux-gnu/libc.so.6 80814 linux-vdso.so.1 (0x00007ffd7f7e7000) 80815 libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000) 80816 /lib64/ld-linux-x86-64.so.2 (0x00007f4469193000) 80817 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000) 80818 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000) 80819 ... 80820 so it's not unexpected that libpthread.so is loaded if libc.so is loaded. 80821 80822 Fix this by accepting the libpthread.so line. 80823 80824 Tested on x86_64-linux. 80825 80826 PR testsuite/29919 80827 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919 80828 808292022-12-31 Tom de Vries <tdevries@suse.de> 80830 80831 [gdb/testsuite] Replace deprecated pthread_yield in gdb.threads/watchpoint-fork.exp 80832 On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into: 80833 ... 80834 watchpoint-fork-mt.c: In function 'start':^M 80835 watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \ 80836 pthread_yield is deprecated, use sched_yield instead \ 80837 [-Wdeprecated-declarations]^M 80838 67 | i = pthread_yield ();^M 80839 | ^^M 80840 ... 80841 80842 Fix this as suggested, by using sched_yield instead. 80843 80844 Tested on x86_64-linux. 80845 808462022-12-31 Tom de Vries <tdevries@suse.de> 80847 80848 [gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35 80849 On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into: 80850 ... 80851 (gdb) PASS: gdb.base/corefile.exp: $_exitcode is void 80852 bt^M 80853 #0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M 80854 #1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M 80855 #2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M 80856 #3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M 80857 #4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M 80858 #5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M 80859 #6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M 80860 #7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M 80861 (gdb) PASS: gdb.base/corefile.exp: backtrace 80862 up^M 80863 #1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M 80864 78 in ./nptl/pthread_kill.c^M 80865 (gdb) FAIL: gdb.base/corefile.exp: up 80866 ... 80867 80868 The problem is that the regexp used here: 80869 ... 80870 gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up" 80871 ... 80872 does not fit the __pthread_kill_internal line which lacks the instruction 80873 address due to inlining. 80874 80875 Fix this by making the regexp less strict. 80876 80877 Tested on x86_64-linux. 80878 808792022-12-31 GDB Administrator <gdbadmin@sourceware.org> 80880 80881 Automatic date update in version.in 80882 808832022-12-30 Tom de Vries <tdevries@suse.de> 80884 80885 [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc 80886 On ubuntu 22.04.1 x86_64, I run into: 80887 ... 80888 (gdb) info probes all rtld rtld_map_complete^M 80889 No probes matched.^M 80890 (gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete 80891 UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes 80892 ... 80893 This has been filed as PR testsuite/17016. 80894 80895 The problem is that the name rtld_map_complete is used, which was only 80896 available in Fedora 17, and upstream the name map_complete was used. 80897 80898 In the email thread discussing a proposed patch ( 80899 https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was 80900 suggested to make the test-case handle both names. 80901 80902 So, handle both names: map_complete and rtld_map_complete. 80903 80904 This exposes the following FAIL: 80905 ... 80906 (gdb) info sharedlibrary^M 80907 From To Syms Read Shared Object Library^M 80908 $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M 80909 $hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M 80910 $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M 80911 $hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M 80912 $hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M 80913 (*): Shared library is missing debugging information.^M 80914 (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found 80915 ... 80916 due to using a glibc (v2.35) that has libpthread integrated into libc. 80917 80918 Fix this by changing the FAIL into UNSUPPORTED. 80919 80920 Tested on x86_64-linux. 80921 80922 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016 80923 809242022-12-30 Tom de Vries <tdevries@suse.de> 80925 80926 [gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with -fcf-protection 80927 On Ubuntu 22.04.1 x86_64, I run into: 80928 ... 80929 gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M 80930 gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \ 80931 '-fcf-protection' are not compatible^M 80932 22 | { /* inc.1 */^M 80933 | ^^M 80934 ... 80935 80936 Fix this by forcing -fcf-protection=none, if supported. 80937 80938 Tested on x86_64-linux. 80939 809402022-12-30 Tom de Vries <tdevries@suse.de> 80941 80942 [gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protection 80943 On Ubuntu 22.04.1 x86_64, I run into: 80944 ... 80945 (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1 80946 next^M 80947 51 if (t != NULL^M 80948 (gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1 80949 ... 80950 80951 This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set: 80952 ... 80953 0000000000001180 <_Z13get_alias_setP4tree>: 80954 1180: f3 0f 1e fa endbr64 80955 1184: 48 85 ff test %rdi,%rdi 80956 ... 80957 so the extra insn gets an is-stmt line number entry: 80958 ... 80959 INDEX LINE ADDRESS IS-STMT PROLOGUE-END 80960 ... 80961 11 50 0x0000000000001180 Y 80962 12 50 0x0000000000001180 80963 13 51 0x0000000000001184 Y 80964 14 54 0x0000000000001184 80965 ... 80966 and when stepping into get_alias_set we step to line 50: 80967 ... 80968 (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main 80969 step^M 80970 get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M 80971 50 {^M 80972 ... 80973 80974 In contrast, with -fcf-protection=none, we get: 80975 ... 80976 0000000000001170 <_Z13get_alias_setP4tree>: 80977 1170: 48 85 ff test %rdi,%rdi 80978 ... 80979 and: 80980 ... 80981 INDEX LINE ADDRESS IS-STMT PROLOGUE-END 80982 ... 80983 11 50 0x0000000000001170 Y 80984 12 51 0x0000000000001170 Y 80985 13 54 0x0000000000001170 80986 ... 80987 so when stepping into get_alias_set we step to line 51: 80988 ... 80989 (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main 80990 step^M 80991 get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M 80992 51 if (t != NULL^M 80993 ... 80994 80995 Fix this by rewriting the gdb_test issuing the step command to check which 80996 line the step lands on, and issuing an extra next if needed. 80997 80998 Tested on x86_64-linux, both with and without -fcf-protection=none. 80999 81000 PR testsuite/29920 81001 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920 81002 810032022-12-30 Tom de Vries <tdevries@suse.de> 81004 81005 [gdb/symtab] Make comp_unit_head.length private 81006 Make comp_unit_head.length private, to enforce using accessor functions. 81007 81008 Replace accessor function get_length with get_length_with_initial and 81009 get_length_without_initial, to make it explicit which variant we're using. 81010 81011 Tested on x86_64-linux. 81012 81013 PR symtab/29343 81014 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343 81015 810162022-12-30 Alan Modra <amodra@gmail.com> 81017 81018 PR29948, heap-buffer-overflow in display_debug_lines_decoded 81019 This fixes a couple of places in display_debug_lines_decoded that were 81020 off by one in checking DWARF5 .debug_line directory indices. It also 81021 displays the DWARF5 entry 0 for the program current directory rather 81022 than "." as is done for pre-DWARF5. I decided against displaying 81023 DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf 81024 to minimally interpret debug info. 81025 81026 binutils/ 81027 PR 29948 81028 * dwarf.c (display_debug_lines_decoded): Display the given 81029 directory entry 0 for DWARF5. Properly check directory index 81030 against number of entries in the table. Revert to using 81031 unsigned int for n_directories and associated variables. 81032 Correct warning messages. 81033 gas/ 81034 * testsuite/gas/elf/dwarf-5-loc0.d: Update. 81035 810362022-12-30 GDB Administrator <gdbadmin@sourceware.org> 81037 81038 Automatic date update in version.in 81039 810402022-12-29 Tsukasa OI <research_trasio@irq.a4lg.com> 81041 81042 RISC-V: Simplify riscv_csr_address logic on state enable extensions 81043 This commit makes CSR class handling for 'Smstateen' and 'Ssstateen' 81044 extensions simpler using fall-throughs (as used in CSR_CLASS_I{,_32}). 81045 81046 gas/ChangeLog: 81047 81048 * config/tc-riscv.c (riscv_csr_address): Simplify the logic for 81049 'Smstateen' and 'Ssstateen' extensions. 81050 810512022-12-29 GDB Administrator <gdbadmin@sourceware.org> 81052 81053 Automatic date update in version.in 81054 810552022-12-28 Tom Tromey <tom@tromey.com> 81056 81057 Use $decimal in timestamp.exp 81058 This patch fixes a review comment by Tom de Vries. He pointed out 81059 that the new timestamp.exp should use the $decimal convenience regexp. 81060 810612022-12-28 Tom Tromey <tom@tromey.com> 81062 81063 Fix "set debug timestamp" 81064 PR cli/29945 points out that "set debug timestamp 1" stopped working 81065 -- this is a regression due to commit b8043d27 ("Remove a ui-related 81066 memory leak"). 81067 81068 This patch fixes the bug and adds a regression test. 81069 81070 I think this should probably be backported to the gdb 13 branch. 81071 81072 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945 81073 810742022-12-28 GDB Administrator <gdbadmin@sourceware.org> 81075 81076 Automatic date update in version.in 81077 810782022-12-27 H.J. Lu <hjl.tools@gmail.com> 81079 81080 x86-64: Allocate input section memory if needed 81081 When --no-keep-memory is used, the input section memory may not be cached. 81082 Allocate input section memory for -z pack-relative-relocs if needed. 81083 81084 bfd/ 81085 81086 PR ld/29939 81087 * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Allocate 81088 input section memory if needed. 81089 81090 ld/ 81091 81092 PR ld/29939 81093 * testsuite/ld-elf/dt-relr-2i.d: New test. 81094 810952022-12-27 Christoph Müllner <christoph.muellner@vrull.eu> 81096 81097 RISC-V: Fix T-Head Fmv vendor extension encoding 81098 A recent change in the XTheadFmv spec fixed an encoding bug in the 81099 document. This patch changes the code to follow this bugfix. 81100 81101 Spec patch can be found here: 81102 https://github.com/T-head-Semi/thead-extension-spec/pull/11 81103 811042022-12-27 Tom Tromey <tromey@adacore.com> 81105 81106 Handle SIGSEGV in gdb selftests 81107 The gdb.gdb self-tests were timing out for me, which turned out to be 81108 PR testsuite/29325. Looking into it, the problem is that the version 81109 of the Boehm GC that is used by Guile on my machine causes a SEGV 81110 during stack probing. This unexpected stop confuses the tests and 81111 causes repeated timeouts. 81112 81113 This patch adapts the two failing tests. This makes them work for me, 81114 and reduces the running time of gdb.gdb from 20 minutes to about 11 81115 seconds. 81116 81117 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325 81118 811192022-12-27 Mike Frysinger <vapier@gentoo.org> 81120 81121 sim: build: clean up unused codegen logic 81122 Now that all igen ports are in the top-level makefile, we don't need 81123 this logic in any subdirs anymore, so clean it up. 81124 81125 sim: mips: hoist "multi" igen rules up to common builds 81126 Since these are the last mips igen rules, we can clean up a number of 81127 bits in the local Makefile.in. 81128 81129 sim: mips: hoist "m16" igen rules up to common builds 81130 81131 sim: mips: hoist "single" igen rules up to common builds 81132 81133 sim: mips: rename "igen" generation mode to "single" 81134 The naming in here has grown organically and is confusing to follow. 81135 Originally there was only one set of rules for generating code from 81136 the igen sources, so calling it "tmp-igen" and such made sense. But 81137 when other multigen modes were added ("m16" & "multi") which also 81138 used igen, it's not clear what's common igen and what's specific to 81139 this generation mode. So rename the set of rules from "igen" to 81140 "single" so it's easier to follow. 81141 81142 sim: mips: hoist itable igen rules up to common builds 81143 Since this rule is pretty simple, hoist it up to the common build. 81144 811452022-12-27 Mike Frysinger <vapier@gentoo.org> 81146 81147 sim: mips: unify itable generation (a bit) 81148 The m16 & multi targets generate itable once even when all the other 81149 modules are generated multiple times. The default igen target will 81150 generate itable with everything else out of convenience. This means 81151 flags are passed which don't affect the generated itable there. 81152 81153 We can unify the itable generation by making sure the right -F/-M 81154 filter variables are passed down. Since there's already a dedicated 81155 rule & variable in the multi build mode, generalize that and switch 81156 the m16 & igen builds over too. 81157 81158 I spent a lot of time staring at this code, building for diff mips 81159 targets, and exploring all the shell code paths. I think this is 81160 safe, but only time (and users) will really tell. 81161 811622022-12-27 Mike Frysinger <vapier@gentoo.org> 81163 81164 sim: mips: rename multi_flags to igen_itable_flags 81165 This variable is only used to generate the itable files. In preparation 81166 for merging the itable logic among all ports, rename "multi_flags" to a 81167 more appropriate "igen_itable_flags" variable. There should be no real 81168 chagnes here otherwise. 81169 81170 sim: mips: drop unused micromips igen logic 81171 This code appears to be unused since it was first merged. When 81172 micromips was enabled, it was via the "MULTI" config, not the 81173 "MICROMIPS" config, and the multi configs have sep vars. Since 81174 nothing sets SIM_MIPS_GEN=MICROMIPS in the config, all of this 81175 should be unreachable, so punt it to simplify. Further, the 81176 SIM_MIPS_MICROMIPS16_FLAGS & SIM_MIPS_MICROMIPS_FLAGS settings 81177 rely on sim_mips_micromips{,16}_{filter,machine} variables that 81178 are never set in the configure script. 81179 811802022-12-27 GDB Administrator <gdbadmin@sourceware.org> 81181 81182 Automatic date update in version.in 81183 811842022-12-26 Tom Tromey <tom@tromey.com> 81185 81186 Add initializers to comp_unit_head 81187 PR symtab/29343 points out that it would be beneficial if 81188 comp_unit_head had a constructor and used initializers. This patch 81189 implements this. I'm unsure if this is sufficient to close the bug, 81190 but at least it's a step. 81191 81192 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343 81193 811942022-12-26 Alan Modra <amodra@gmail.com> 81195 81196 bfd/dwarf2.c: allow use of DWARF5 directory entry 0 81197 I think the test for table->files[file].dir being non-zero is wrong 81198 for DWARF5 where index zero is allowed and is the current directory of 81199 the compilation. Most times this will be covered by the use of 81200 table->comp_dir (from DW_AT_comp_dir) in concat_filename but the point 81201 of putting the current dir in .debug_line was so the section could 81202 stand alone without .debug_info. 81203 81204 Also, there is no need to check for table->dirs non-NULL, the 81205 table->num_dirs test is sufficient. 81206 81207 * dwarf2.c (concat_filename): Correct and simplify tests of 81208 directory index. 81209 812102022-12-26 Flavio Cruz <flaviocruz@gmail.com> 81211 81212 Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd 81213 812142022-12-26 GDB Administrator <gdbadmin@sourceware.org> 81215 81216 Automatic date update in version.in 81217 812182022-12-25 Mike Frysinger <vapier@gentoo.org> 81219 81220 sim: build: drop support for subdir distclean 81221 All ports that need to clean things up at distclean time have moved 81222 to the top-level build, so we can drop support for this hook. 81223 81224 sim: mips: move distclean settings to common build 81225 This was missed when mips/configure was merged into the top-level. 81226 812272022-12-25 Indu Bhagat <indu.bhagat@oracle.com> 81228 81229 libsframe: write out SFrame FRE start address correctly 81230 The following test was failing on ppc64 and s390x: 81231 "FAIL: encode-1: Encode buffer match" 81232 81233 The offending stub was how we memcpy the FRE start address to the buffer 81234 (on-disk format). When the host is big-endian, the address of the 81235 source buffer for the memcpy needs to point to the uint8_t/uint16_t sized 81236 value of the FRE start addr, not uint32_t sized value; we intend to copy 81237 out only the fre_start_addr_sz number of bytes. 81238 81239 ChangeLog: 81240 81241 * libsframe/sframe.c (sframe_encoder_write_fre_start_addr): New 81242 function. 81243 (sframe_encoder_write_fre): Use it instead of memcpy. 81244 812452022-12-25 Mike Frysinger <vapier@gentoo.org> 81246 81247 sim: smp: plumb igen flag down to all users 81248 While mips has respected sim_igen_smp at configure time (which was 81249 always empty since it defaulted smp to off), no other igen port did. 81250 Move this to a makefile variable and plumb it through the common 81251 IGEN_RUN variable instead so everyone gets it by default. We also 81252 clean up some redundant -N0 setting with multirun mips. 81253 81254 sim: smp: make option available again 81255 At some point we want this to work, but it's not easy to test if 81256 the configure option isn't available. Restore it, but keep the 81257 default off. 81258 81259 sim: cpu: change default init to handle all cpus 81260 All the runtimes were only initializing a single CPU. When SMP is 81261 enabled, things quickly crash as none of the other CPU structs are 81262 setup. Change the default from 0 to the compile time value. 81263 81264 sim: msp430: add basic SMP cpu init 81265 There's no need to assert there's only 1 CPU when setting them all 81266 up here is trivial. 81267 81268 sim: m32r: fix iterator typo when setting up cpus 81269 This code loops over available cpus with "c", but then looks up the 81270 cpu with "i". Fix the typo so the code works correctly with smp. 81271 81272 sim: v850: fix SMP compile 81273 The igen tool sets up the SD & CPU defines for code fragments to use, 81274 but v850 was expecting "sd". Change all the igen related code to use 81275 SD so it actually compiles, and fix a few places to use "CPU" instead 81276 of hardcoding cpu0. 81277 81278 sim: or1k: fix iterator typo when setting up cpus 81279 This code loops over available cpus with "c", but then looks up the 81280 cpu with "i". Fix the typo so the code works correctly with smp. 81281 81282 sim: mn10300: fix SMP compile 81283 The igen tool sets up the SD define for code fragments to use, but 81284 mn10300 was expecting "sd". Change all the igen related code to use 81285 SD so it actually compiles. 81286 81287 sim: cpu: fix SMP msg prefix helper 81288 This code fails to compile when SMP is enabled due to some obvious 81289 errors. Fix those and change the logic to avoid CPP to prevent any 81290 future rot from creeping back in. 81291 81292 sim: mips: clean up a bit after mips/configure removal 81293 Now that there is no subdir configure script, we can clean up some 81294 logic that was spread between the files. 81295 81296 sim: mips: move igen settings to top-level configure 81297 This is the last bit of logic that exists in the mips configure 81298 script, so move it to the top-level configure to kill it off. 81299 We still have to move the Makefile.in igen logic to local.mk, 81300 but this is a required first step for that. 81301 81302 sim: mips: namespace igen configure vars 81303 To prepare moving this logic to the top-level configure, the vars 81304 need to be namespaced. Do that here to make it easier to review. 81305 Basically sim_xxx -> SIM_MIPS_XXX when a var is exported from the 81306 configure script to the Makefile, and sim_xxx -> sim_mips_xxx when 81307 the var is internal in the configure script. 81308 81309 sim: mips: add igen recursive dep 81310 Make sure the igen tool exists before trying to compile the mips 81311 subdir. This happens to work when mips has a subconfigure, but 81312 hits a race condition when that is removed. 81313 81314 sim: mips: drop unused ENGINE_ISSUE_POSTFIX_HOOK 81315 Nothing defines this, and it isn't called in all the engine runtimes, 81316 so drop it entirely to avoid confusion. 81317 81318 sim: igen: drop move-if-changed usage 81319 Now that igen itself has this logic, drop these custom build rules 81320 to greatly simplify. 81321 81322 sim: igen: support in-place updates ourself 81323 Every file that igen outputs is then processed with the move-if-changed 81324 shell script. This creates a lot of boilerplate in the build and not an 81325 insignificant amount of build-time overhead. Move the simple "is the file 81326 changed" logic into igen itself. 81327 81328 sim: igen: constify itable data structures 81329 These are const data arrays of strings and numbers. We don't want 81330 or need them to be writable, so mark them all const. 81331 813322022-12-25 GDB Administrator <gdbadmin@sourceware.org> 81333 81334 Automatic date update in version.in 81335 813362022-12-24 Andrew Burgess <aburgess@redhat.com> 81337 81338 gdb/testsuite: fix buffer overflow in gdb.base/signed-builtin-types.exp 81339 In commit: 81340 81341 commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12 81342 Date: Wed Dec 7 15:55:25 2022 +0000 81343 81344 gdb/testsuite: new test for recent dwarf reader issue 81345 81346 A new test (gdb.base/signed-builtin-types.exp) was added that made use 81347 of 'info sources' to figure out if the debug information for a 81348 particular object file had been fully expanded or not. Unfortunately 81349 some lines of the 'info sources' output can be very long, this was 81350 observed on some systems where the debug information for the 81351 dynamic-linker was installed, in this case, the list of source files 81352 associated with the dynamic linker was so long it would cause expect's 81353 internal buffer to overflow. 81354 81355 This commit switches from using 'info sources' to 'maint print 81356 objfile', the output from the latter command is more compact, but 81357 also, can be restricted to a single named object file. 81358 81359 With this change in place I am no longer seeing buffer overflow errors 81360 from expect when running gdb.base/signed-builtin-types.exp. 81361 813622022-12-24 Mike Frysinger <vapier@gentoo.org> 81363 81364 sim: or1k: move arch-specific settings to internal header 81365 There's no need for these settings to be in sim-main.h which is shared 81366 with common/ sim code, so move it all out to the existing or1k-sim.h. 81367 Unfortunately, we can't yet drop the or1k-sim.h include from sim-main.h 81368 as many of the generated CGEN files refer only to sim-main.h. We'll 81369 have to improve the CGEN interface before we can make more progress, 81370 but this is at least a minor improvement. 81371 813722022-12-24 GDB Administrator <gdbadmin@sourceware.org> 81373 81374 Automatic date update in version.in 81375 813762022-12-23 Tom Tromey <tom@tromey.com> 81377 81378 Use bool for dwarf2_has_info 81379 This changes dwarf2_has_info to return bool. 81380 813812022-12-23 Indu Bhagat <indu.bhagat@oracle.com> 81382 81383 libsframe: testsuite: fix memory leaks in testcases 81384 ChangeLog: 81385 81386 * libsframe/testsuite/libsframe.decode/be-flipping.c: Free 81387 SFrame buffer. 81388 * libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise. 81389 * libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise. 81390 813912022-12-23 Indu Bhagat <indu.bhagat@oracle.com> 81392 81393 libsframe: fix a memory leak in sframe_decode 81394 sframe_decode () needs to malloc a temporary buffer of the same size as 81395 the input buffer (containing the SFrame section bytes) when endian 81396 flipping is needed. The decoder keeps the endian flipped contents in 81397 this buffer for its usage. This code is necessary when the target 81398 endianneess is not the same as host endianness. 81399 81400 The malloc'd buffer needs to be kept track of, so that it can freed up in 81401 sframe_decoder_free () later. 81402 81403 ChangeLog: 81404 81405 * libsframe/sframe-impl.h (struct sframe_decoder_ctx): Add new 81406 member to keep track of the internally malloc'd buffer. 81407 * libsframe/sframe.c (sframe_decoder_free): Free it up. 81408 (sframe_decode): Update the reference to the buffer. 81409 814102022-12-23 Simon Marchi <simon.marchi@polymtl.ca> 81411 81412 gdb/testsuite: remove MPFR detection in gdb.base/float128.exp 81413 I see this fail since commit 991180627851 ("Use toplevel configure for 81414 GMP and MPFR for gdb"): 81415 81416 FAIL: gdb.base/float128.exp: show configuration 81417 81418 The test fails to find --with-mpfr or --without-mpfr in the "show 81419 configuration" output. Since MPFR has become mandatory, we can just 81420 remove that check and simplify the test to assume MPFR support is there. 81421 81422 Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a 81423 Approved-By: Tom de Vries <tdevries@suse.de> 81424 814252022-12-23 Mike Frysinger <vapier@gentoo.org> 81426 81427 sim: m32r: move arch-specific settings to internal header 81428 There's no need for these settings to be in sim-main.h which is shared 81429 with common/ sim code, so move it all out to the existing m32r-sim.h. 81430 Unfortunately, we can't yet drop the m32r-sim.h include from sim-main.h 81431 as many of the generated CGEN files refer only to sim-main.h. We'll 81432 have to improve the CGEN interface before we can make more progress, 81433 but this is at least a minor improvement. 81434 81435 sim: bfin: move arch-specific settings to internal header 81436 There's no need for these settings to be in sim-main.h which is shared 81437 with common/ sim code, so drop the bfin.h include and move the remaining 81438 bfin-specific settings into it. 81439 81440 sim: m68hc11: move arch-specific settings to internal header 81441 There's no need for these settings to be in sim-main.h which is shared 81442 with common/ sim code, so move it all out to a new header which only 81443 this port will include. 81444 81445 sim: sh: move arch-specific settings to internal header 81446 There's no need for these settings to be in sim-main.h which is shared 81447 with common/ sim code, so move it all out to a new header which only 81448 this port will include. 81449 81450 sim: mcore: move arch-specific settings to internal header 81451 There's no need for these settings to be in sim-main.h which is shared 81452 with common/ sim code, so move it all out to a new header which only 81453 this port will include. 81454 81455 sim: h8300: move arch-specific settings to internal header 81456 There's no need for these settings to be in sim-main.h which is shared 81457 with common/ sim code, so move it all out to a new header which only 81458 this port will include. 81459 81460 sim: pru: move arch-specific settings to internal header 81461 There's no need for these settings to be in sim-main.h which is shared 81462 with common/ sim code, so drop the pru.h include and move the remaining 81463 pru-specific settings into it. 81464 814652022-12-23 Mike Frysinger <vapier@gentoo.org> 81466 81467 sim: mn10300: standardize the arch-specific settings a little 81468 Rename mn10300_sim.h to mn10300-sim.h to match other ports, and move most 81469 of the arch-specific content out of sim-main.h to it. This isn't a big 81470 win though as we still have to include the header in sim-main.h due to the 81471 igen interface: it hardcodes including sim-main.h in its files. So until 81472 we can fix that, we have to keep bleeding these settings into the common 81473 codes. 81474 81475 Also take the opportunity to purge a lot of unused headers from these. 81476 The local modules should already include the right headers, so there's 81477 no need to force everyone to pull them in. A lot of this is a hold over 81478 from the pre-igen days of this port. 81479 814802022-12-23 Mike Frysinger <vapier@gentoo.org> 81481 81482 sim: microblaze: move arch-specific settings to internal header 81483 There's no need for these settings to be in sim-main.h which is shared 81484 with common/ sim code, so move it all out to a new header which only 81485 this port will include. 81486 81487 sim: example-synacor: move arch-specific settings to internal header 81488 There's no need for these settings to be in sim-main.h which is shared 81489 with common/ sim code, so move it all out to a new header which only 81490 this port will include. 81491 81492 sim: moxie: move arch-specific settings to internal header 81493 There's no need for these settings to be in sim-main.h which is shared 81494 with common/ sim code, so move it all out to a new header which only 81495 this port will include. 81496 814972022-12-23 Mike Frysinger <vapier@gentoo.org> 81498 81499 sim: riscv: move arch-specific settings to internal header 81500 There's no need for these settings to be in sim-main.h which is shared 81501 with common/ sim code, so move it all out to a new header which only 81502 this port will include. 81503 81504 We can also move the machs.h include out since the model logic was all 81505 generalized from compile-time to runtime last year. 81506 815072022-12-23 Mike Frysinger <vapier@gentoo.org> 81508 81509 sim: v850: standardize the arch-specific settings a little 81510 Rename v850_sim.h to v850-sim.h to match other ports, and move most 81511 of the arch-specific content out of sim-main.h to it. This isn't a 81512 big win though as we still have to include the header in sim-main.h 81513 due to the igen interface: it hardcodes including sim-main.h in its 81514 files. So until we can fix that, we have to keep bleeding these 81515 settings into the common codes. 81516 815172022-12-23 Mike Frysinger <vapier@gentoo.org> 81518 81519 sim: msp430: move arch-specific settings to internal header 81520 There's no need for these settings to be in sim-main.h which is shared 81521 with common/ sim code, so drop the msp430-sim.h include and move it to 81522 the few files that actually need it. 81523 81524 While we're here, drop redundant includes from sim-main.h: 81525 * sim-config.h & sim-types.h included by sim-basics.h already 81526 * sim-engine.h included by sim-base.h already 81527 And move sim-options.h to the one file that needs it. 81528 815292022-12-23 Mike Frysinger <vapier@gentoo.org> 81530 81531 sim: ft32: move arch-specific settings to internal header 81532 There's no need for these settings to be in sim-main.h which is shared 81533 with common/ sim code, so drop the ft32-sim.h include and move it to 81534 the few files that actually need it. 81535 815362022-12-23 Mike Frysinger <vapier@gentoo.org> 81537 81538 sim: d10v: move arch-specific settings to internal header 81539 There's no need for these settings to be in sim-main.h which is shared 81540 with common/ sim code, so drop the d10v_sim.h include and move it to 81541 the few files that actually need it. 81542 81543 Also rename the file to standardize it a bit better with other ports. 81544 815452022-12-23 Mike Frysinger <vapier@gentoo.org> 81546 81547 sim: cr16: move arch-specific settings to internal header 81548 There's no need for these settings to be in sim-main.h which is shared 81549 with common/ sim code, so drop the cr16_sim.h include and move it to 81550 the few files that actually need it. 81551 81552 Also rename the file to standardize it a bit better with other ports. 81553 815542022-12-23 Mike Frysinger <vapier@gentoo.org> 81555 81556 sim: arm: move arch-specific settings to internal header 81557 There's no need for these settings to be in sim-main.h which is shared 81558 with common/ sim code, so move it all out to a new header which only 81559 this port will include. 81560 81561 The BIT override would be better in the place where it's redefined, so 81562 move it to armdefs.h instead. 81563 815642022-12-23 Mike Frysinger <vapier@gentoo.org> 81565 81566 sim: aarch64: move arch-specific settings to internal header 81567 There's no need for these settings to be in sim-main.h which is shared 81568 with common/ sim code, so move it all out to a new header which only 81569 this port will include. 81570 81571 While we're here, drop redundant includes from sim-main.h: 81572 * sim-types.h is included by sim-base.h already 81573 * sim-base.h is included twice 81574 * sim-io.h is included by sim-base.h already 81575 815762022-12-23 Mike Frysinger <vapier@gentoo.org> 81577 81578 sim: avr: move arch-specific settings to internal header 81579 There's no need for these settings to be in sim-main.h which is shared 81580 with common/ sim code, so move it all out to a new header which only 81581 this port will include. 81582 815832022-12-23 Nick Clifton <nickc@redhat.com> 81584 81585 Fix illegal memory access parsing corrupt DWARF information. 81586 PR 29936 81587 * dwarf2.c (concat_filename): Fix check for a directory index off 81588 the end of the directory table. 81589 815902022-12-23 Eli Zaretskii <eliz@gnu.org> 81591 81592 Fix MinGW build using mingw.org's MinGW 81593 This allows to build GDB even though the default value of 81594 _WIN32_WINNT is lower than the one needed to expose some 81595 new APIs used here, and leave the test for their actual 81596 support to run time. 81597 * gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if 81598 not defined. 81599 (create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list' 81600 instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined 81601 at compile time). This fixes compilation error using mingw.org's 81602 MinGW. 81603 816042022-12-23 Mark Harmstone <mark@harmstone.com> 81605 81606 ld: Write linker symbols in PDB 81607 81608 ld: Copy other symbols into PDB file 81609 81610 ld: Write globals stream in PDB 81611 81612 ld: Parse LF_UDT_SRC_LINE records when creating PDB file 81613 81614 ld: Write types into IPI stream of PDB 81615 81616 ld: Write types into TPI stream of PDB 81617 81618 ld: Write DEBUG_S_LINES entries in PDB file 81619 81620 ld: Fix segfault in populate_publics_stream 81621 81622 ld: Write DEBUG_S_FILECHKSMS entries in PDBs 81623 81624 ld: Generate PDB string table 81625 816262022-12-23 Alan Modra <amodra@gmail.com> 81627 81628 pdb build fixes 81629 Enable compilation of ld/pdb.c just for x86, as is done for bfd/pdb.c. 81630 This reduces the size of ld and is necessary with the following 81631 patches that call a COFF-only bfd function from ld/pdb.c. Without it 81632 we'd break every non-COFF target build. 81633 816342022-12-23 Mike Frysinger <vapier@gentoo.org> 81635 81636 sim: lm32/m32r: drop redundant opcode/cgen.h include 81637 The xxx-desc.h header file already includes this, and it's how the 81638 other cgen ports are getting it, so drop it from these two. 81639 81640 sim: ppc: drop unused types from sim-main.h 81641 The common sim headers should define these for us already, so there's 81642 no need for the ppc header to set them up. 81643 81644 sim: cgen: move symcat.h include to where it's used 81645 Move this out of the global sim-main.h and to the few files that 81646 actually use functions from it. Only the cgen ports were pulling 81647 this, so this makes cgen & non-cgen behave more the same. 81648 81649 sim: cgen: move cgen-types.h include to cgen-defs.h 81650 The cgen-types.h header sets up types that are needed by cgen-defs.h, 81651 so move the include out of sim-main.h and to that header. It might 81652 be needed in other specific modules, but for now let's kick it out of 81653 sim-main.h to make some progress. Things still build with just this. 81654 816552022-12-23 Mike Frysinger <vapier@gentoo.org> 81656 81657 Revert "sim: mn10300: drop unused sim-main.c" 81658 This reverts commit 681a422b855e4b20086554b170dae051361f00c7. 81659 81660 I missed that this was included via common/sim-inline.c. I thought 81661 I had grepped the top of the tree, but I must have only done mn10300. 81662 81663 Add a comment to make it clear where/how this file is used. 81664 816652022-12-23 Mike Frysinger <vapier@gentoo.org> 81666 81667 sim: mn10300: drop unused sim-main.c 81668 Nothing compiles or references this, so punt it. 81669 81670 sim: endian: move bfd.h from header to source 81671 The bfd APIs are used only by sim-n-endian.h which is only included by 81672 sim-endian.c, so move the bfd.h include there and out of sim-endian.h 81673 which is included by many other modules. 81674 816752022-12-23 Mike Frysinger <vapier@gentoo.org> 81676 81677 sim: move bfd.h include out of sim-main.h 81678 Not all arches include this in sim-main.h, and the ones that do don't 81679 actually use bfd defines in the sim-main.h header. Prune it to make 81680 sim-main.h simpler so we can kill it off entirely in the future. 81681 81682 We add the include to the files that utilize e.g. bfd_vma though. 81683 816842022-12-23 Mike Frysinger <vapier@gentoo.org> 81685 81686 sim: mcore: replace custom "word" type with int32_t 81687 This is a 32-bit architecture with 32-bit registers, so replace the 81688 custom "word" long int typedef with an explicit int32_t. This is 81689 a correctness fix since long will be 64-bits on most 64-bit hosts. 81690 81691 sim: moxie: replace custom "word" type with int32_t 81692 This is a 32-bit architecture with 32-bit registers, so replace the 81693 custom "word" int typedef with an explicit int32_t. Practically 81694 speaking, this produces the same code, but it should hopefully make 81695 it easier to merge common code in the future. 81696 81697 sim: cr16/d10v/mcore/moxie: clean up unused word & uword types 81698 Nothing actually uses these, so punt them. Some of the ports are 81699 using local "word" types, but we'll clean those up in a follow up. 81700 81701 sim: mips: trim redundant igen settings 81702 These variables are setting the same value as the defaults. Trim 81703 this redundant logic to make it easier to see the real differences 81704 so we can try to keep unifying cases. 81705 81706 sim: mips: merge mips64* with existing multi-run build 81707 Change the default (unhandled) mips64* targets to use the existing 81708 mips64 multi-run build. It already handles the formats, we just 81709 have to list the mips8000 bfd for it. 81710 81711 sim: mips: merge mips64vr5000 with existing multi-run build 81712 The existing mips64vr-* multi-run build already handles mips5000 81713 targets, so reuse that for mips64vr5* targets too. This moves 81714 more logic from build-time to runtime so we can have a single 81715 binary that supports many targets. 81716 817172022-12-23 Nelson Chu <nelson@rivosinc.com> 81718 81719 RISC-V: Relax the order checking for the architecture string 81720 * riscv-toolchain-conventions, 81721 PR, https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14 81722 Issue, https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/11 81723 81724 * Refer to the commit afc41ffb, 81725 RISC-V: Reorder the prefixed extensions which are out of order. 81726 81727 In the past we only allow to reorder the prefixed extensions. But according 81728 to the PR 14 in the riscv-toolchain-convention, we can also relax the order 81729 checking to allow the whole extensions be written out of orders, including 81730 the single standard extensions and the prefixed multi-letter extensions. 81731 Just that we still need to follow the following rules as usual, 81732 81733 1. prefixed extensions need to be seperated with `_'. 81734 2. prefixed extensions need complete <major>.<minor> version if set. 81735 81736 Please see the details in the march-ok-reorder gas testcase. 81737 81738 Passed the riscv-gnu-toolchain regressions. 81739 81740 bfd/ 81741 * elfxx-riscv.c (enum riscv_prefix_ext_class): Changed RV_ISA_CLASS_UNKNOWN 81742 to RV_ISA_CLASS_SINGLE, since everything that does not belong to the 81743 multi-keyword will possible be a single extension for the current parser. 81744 (parse_config): Likewise. 81745 (riscv_get_prefix_class): Likewise. 81746 (riscv_compare_subsets): Likewise. 81747 (riscv_parse_std_ext): Removed, and merged with riscv_parse_prefixed_ext 81748 into riscv_parse_extensions. 81749 (riscv_parse_prefixed_ext): Likewise. 81750 (riscv_parse_subset): Only need to call riscv_parse_extensions to parse 81751 both single standard and prefixed extensions. 81752 gas/ 81753 * testsuite/gas/riscv/march-fail-order-std.d: Removed since the relaxed 81754 order checking. 81755 * testsuite/gas/riscv/march-fail-order-std.l: Likewise. 81756 * testsuite/gas/riscv/march-fail-order-x-std.d: Likewise. 81757 * testsuite/gas/riscv/march-fail-order-z-std.d: Likewise. 81758 * testsuite/gas/riscv/march-fail-order-zx-std.l: Likewise. 81759 * testsuite/gas/riscv/march-fail-unknown-std.l: Updated. 81760 * testsuite/gas/riscv/march-ok-reorder.d: New testcase. 81761 817622022-12-23 Mike Frysinger <vapier@gentoo.org> 81763 81764 sim: drop unused SIM_ADDR type [PR sim/7504] 81765 Now that sim APIs either use 64-bit addresses all the time, or more 81766 appropriate target-specific types, drop this now-unused 32-bit-only 81767 address type. 81768 81769 Bug: https://sourceware.org/PR7504 81770 817712022-12-23 Mike Frysinger <vapier@gentoo.org> 81772 81773 sim: mips: switch from SIM_ADDR to address_word 81774 The latter type matches the address size configured for this sim. 81775 81776 Also take the opportunity to simplify printf logic by leveraging 81777 PRI* macros. 81778 817792022-12-23 Mike Frysinger <vapier@gentoo.org> 81780 81781 sim: v850: switch from SIM_ADDR to address_word 81782 The latter type matches the address size configured for this sim. 81783 817842022-12-23 Mike Frysinger <vapier@gentoo.org> 81785 81786 sim: switch sim_{read,write} APIs to 64-bit all the time [PR sim/7504] 81787 We've been using SIM_ADDR which has always been 32-bit. This means 81788 the upper 32-bit address range in 64-bit sims is inaccessible. Use 81789 64-bit addresses all the time since we want the APIs to be stable 81790 regardless of the active arch backend (which can be 32 or 64-bit). 81791 81792 The length is also 64-bit because it's completely feasible to have 81793 a program that is larger than 4 GiB in size/image/runtime. Forcing 81794 the caller to manually chunk those accesses up into 4 GiB at a time 81795 doesn't seem useful to anyone. 81796 81797 Bug: https://sourceware.org/PR7504 81798 817992022-12-23 Mike Frysinger <vapier@gentoo.org> 81800 81801 sim: use bfd_vma when reading start addr from bfd info 81802 Since SIM_ADDR is always 32-bit, it might truncate the address with 81803 64-bit ELFs. Since we load that addr from the bfd, use the bfd_vma 81804 type which matches the bfd_get_start_address API. 81805 81806 sim: m32r: include sim-hw.h for sim_hw_parse 81807 818082022-12-23 Alan Modra <amodra@gmail.com> 81809 81810 COFF build-id writes uninitialised data to file 81811 1) The first write in write_build_id wrote rubbish past the struct 81812 external_IMAGE_DEBUG_DIRECTORY, which was later overwritten with 81813 correct data. No user visible problem there, except that tools like 81814 valgrind complain. 81815 2) The size for the pdb name was incorrectly calculated. 81816 81817 * emultempl/pe.em (write_build_id): Write the debug directory, 81818 not the entire section contents. 81819 (setup_build_id): Add size for the base name of pdb_name, not 81820 the full path. 81821 * emultempl/pep.em: Likewise. 81822 * testsuite/ld-pe/pdb2-section-contrib.d: Update. 81823 818242022-12-23 Mike Frysinger <vapier@gentoo.org> 81825 81826 sim: mips: merge mips64vr4300 with existing multi-run build 81827 The existing mips64vr-* multi-run build already handles mips4300 81828 targets, so reuse that for mips64vr43* targets too. This moves 81829 more logic from build-time to runtime so we can have a single 81830 binary that supports many targets. 81831 818322022-12-23 GDB Administrator <gdbadmin@sourceware.org> 81833 81834 Automatic date update in version.in 81835 818362022-12-22 Indu Bhagat <indu.bhagat@oracle.com> 81837 81838 sframe: doc: update documentation for pauth key in SFrame FDE 81839 ChangeLog: 81840 81841 * libsframe/doc/sframe-spec.texi 81842 818432022-12-22 Indu Bhagat <indu.bhagat@oracle.com> 81844 81845 gas: sframe: testsuite: add testcase for .cfi_b_key_frame 81846 This is actually a composite test that checks SFrame unwind information 81847 generation for both the .cfi_negate_ra_state and .cfi_b_key_frame 81848 directives on aarch64. 81849 81850 ChangeLog: 81851 81852 * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: 81853 New test. 81854 * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.s: 81855 Likewise. 81856 * testsuite/gas/cfi-sframe/cfi-sframe.exp: Run new test. 81857 818582022-12-22 Indu Bhagat <indu.bhagat@oracle.com> 81859 81860 objdump/readelf: sframe: emit marker for SFrame FDE with B key 81861 ChangeLog: 81862 81863 * libsframe/sframe-dump.c (is_sframe_abi_arch_aarch64): New 81864 definition. 81865 (dump_sframe_func_with_fres): Emit a string if B key is used. 81866 818672022-12-22 Indu Bhagat <indu.bhagat@oracle.com> 81868 81869 gas: sframe: add support for .cfi_b_key_frame 81870 Gather the information from the DWARF FDE on whether frame's return 81871 addresses are signed using the B key or A key. Reflect the information in 81872 the SFrame counterpart data structure, the SFrame FDE. 81873 81874 ChangeLog: 81875 81876 * gas/gen-sframe.c (get_dw_fde_pauth_b_key_p): New definition. 81877 (sframe_v1_set_func_info): Add new argument for pauth_key. 81878 (sframe_set_func_info): Likewise. 81879 (output_sframe_funcdesc): Likewise. 81880 * gas/gen-sframe.h (struct sframe_version_ops): Add new argument 81881 to the function pointer declaration. 81882 * gas/sframe-opt.c (sframe_convert_frag): Handle pauth_key. 81883 818842022-12-22 Indu Bhagat <indu.bhagat@oracle.com> 81885 81886 sframe.h: add support for .cfi_b_key_frame 81887 ARM 8.3 provides five separate keys that can be used to authenticate 81888 pointers. There are two key for executable (instruction) pointers. The 81889 enum pointer_auth_key in gas/config/tc-aarch64.h currently holds two keys: 81890 enum pointer_auth_key { 81891 AARCH64_PAUTH_KEY_A, 81892 AARCH64_PAUTH_KEY_B 81893 }; 81894 81895 Analogous to the above, in SFrame format V1, a bit is reserved in the SFrame 81896 FDE to indicate which key is used for signing the frame's return addresses: 81897 - SFRAME_AARCH64_PAUTH_KEY_A has a value of 0 81898 - SFRAME_AARCH64_PAUTH_KEY_B has a value of 1 81899 81900 Note that the information in this bit will always be used along with the 81901 mangled_ra_p bit, the latter indicates whether the return addresses are 81902 mangled/contain PAC auth bits. 81903 81904 include/ChangeLog: 81905 81906 * sframe.h (SFRAME_AARCH64_PAUTH_KEY_A): New definition. 81907 (SFRAME_AARCH64_PAUTH_KEY_B): Likewise. 81908 (SFRAME_V1_FUNC_INFO): Adjust to accommodate pauth_key. 81909 (SFRAME_V1_FUNC_PAUTH_KEY): New macro. 81910 (SFRAME_V1_FUNC_INFO_UPDATE_PAUTH_KEY): Likewise. 81911 819122022-12-22 Jan Beulich <jbeulich@suse.com> 81913 81914 gas: re-arrange listing output for .irp and alike 81915 It is kind of odd to have the expansions of such constructs ahead of 81916 their definition in listings with macro expansion enabled. Adjust this 81917 by pulling ahead the output of the definition lines, taking care to 81918 avoid producing a listing line for (non-existing) line 0 when the source 81919 is stdin. 81920 81921 Note that with the code movement the conditional operator isn't 81922 necessary anymore - list->line now match up. 81923 819242022-12-22 Jan Beulich <jbeulich@suse.com> 81925 81926 x86: correct/improve TSX controls 81927 TSXLDTRK takes RTM as a prereq. Additionally introduce an umbrella "tsx" 81928 extension option covering both RTM and HLE, paralleling the "abm" one we 81929 already have. 81930 819312022-12-22 Jan Beulich <jbeulich@suse.com> 81932 81933 x86: add dependencies on SVME 81934 SEV-ES is an extension to SVME. SNP in turn is an extension to SEV-ES, 81935 and yet in turn RMPQUERY is a SNP extension. 81936 81937 Note that cpu_arch[] has no SNP entry, so CPU_ANY_SNP_FLAGS remains 81938 unused (just like CPU_SNP_FLAGS already is). 81939 819402022-12-22 Jan Beulich <jbeulich@suse.com> 81941 81942 x86: add dependencies on VMX 81943 Both EPT and VMFUNC are extensions to VMX. 81944 819452022-12-22 Jan Beulich <jbeulich@suse.com> 81946 81947 x86: correct XSAVE* dependencies 81948 Like various other features AMX-TILE takes XSAVE as a prereq. 81949 81950 XSAVES, unconditionally using compacted format, in turn effectively 81951 takes XSAVEC as a prereq (an SDM clarification to this effect is in the 81952 works). 81953 819542022-12-22 Jan Beulich <jbeulich@suse.com> 81955 81956 x86: correct dependencies of a few AVX512 sub-features 81957 Like AVX512-FP16, several other extensions require wider than 16-bit 81958 mask registers. As a result they take AVX512BW as a prereq, not (just) 81959 AVX512F. Which in turn points out wrong expectations in the noavx512-1 81960 testcase. 81961 81962 x86: rework noavx512-1 testcase 81963 So far the set of ".noavx512*" has been accumulating, which isn't ideal. 81964 In particular this hides issues with dependencies between features. 81965 Switch back to the default ISA before disabling a particular subset. 81966 Furthermore limit redundancy by wrapping the repeated block of insns in 81967 an .irp. 81968 81969 x86: add dependencies on AVX2 81970 Like AVX-VNNI both VAES and VPCLMUL take AVX2 as a prereq, for operating 81971 on up to 256-bit packed integer vectors. 81972 81973 x86: correct SSE dependencies 81974 SSE itself takes FXSR as a prereq. Like AES, PCLMUL, and SHA both GFNI 81975 and KL take SSE2 as a prereq, for operating on packed integers. And 81976 while correcting KL also record it as a prereq to WIDEKL. 81977 819782022-12-22 Jan Beulich <jbeulich@suse.com> 81979 81980 x86: correct what gets disabled by certain ".arch .no*" 81981 Features with prereqs as well as features with dependents cannot re-use 81982 CPU_*_MASK for the 3rd argument of SUBARCH() - they need to use 81983 CPU_ANY_*_MASK in order to avoid disabling too many (when there are 81984 prereqs) and/or too few (when there are dependents) features. 81985 81986 Generally any CPU_ANY_*_MASK which exist should not remain unused. 81987 Exceptions are 81988 - FISTTP which has no corresponding entry in cpu_arch[], 81989 - IAMCU which is a base architecture and hence uses ARCH(), not 81990 SUBARCH() (only extensions can be disabled, but unlike for Cpu*86 it 81991 would be a little more clumsy to suppress generating of the #define). 81992 819932022-12-22 Jan Beulich <jbeulich@suse.com> 81994 81995 x86: re-work ISA extension dependency handling 81996 Getting both forward and reverse ISA dependencies right / consistent has 81997 been a permanent source of mistakes. Reduce what needs specifying 81998 manually to just the direct forward dependencies. Transitive forward 81999 dependencies as well as reverse ones are now derived and hence cannot go 82000 out of sync anymore (at least in the vast majority of cases; there are a 82001 few special cases to still take care of manually). In the course of this 82002 several CPU_ANY_*_FLAGS disappear, requiring adjustment to the 82003 assembler's cpu_arch[]. 82004 82005 Note that to retain the correct reverse dependency of AVX512F wrt 82006 AVX512-VP2INTERSECT, the latter has the previously missing AVX512F 82007 prereq added. 82008 82009 Note further that to avoid adding the following undue prereqs: 82010 * ATHLON, K8, and AMDFAM10 gain CMOV and FXSR, 82011 * IAMCU gains 387, 82012 auxiliary table entries (including a colon-separated modifier) are 82013 introduced in addition to the ones representing from converting the old 82014 table. 82015 82016 To maintain forward-only dependencies between AVX (XOP) and SSE* (SSE4a) 82017 (i.e. "nosse" not disabling AVX), reverse dependency tracking is 82018 artifically suppressed. 82019 82020 As a side effect disabling of SSE or SSE2 will now also disable AES, 82021 PCLMUL, and SHA (respective elements were missing from 82022 CPU_ANY_SSE2_FLAGS). 82023 820242022-12-22 Mike Frysinger <vapier@gentoo.org> 82025 82026 sim: mips: match target on cpu settings 82027 We don't need to enforce larger target settings when the only thing 82028 the sim should care about is the CPU target. So reduce most of the 82029 target matches to only check the CPU. 82030 82031 sim: mips: move fpu bitsize defines to top-level configure 82032 This drops support for the --enable-sim-float configure option, 82033 but it's not clear anyone ever actually used that. Eventually 82034 we'll want this to be a runtime option anyways. 82035 82036 sim: mips: move bitsize defines to top-level configure 82037 Since the msb value is always defined as the wordsize-1, stop 82038 hardcoding that value directly, and use a CPP value instead. 82039 82040 sim: mips: move subtarget defines to top-level configure 82041 We want to kill off mips/configure entirely. Move this small part 82042 out now to get started. 82043 82044 sim: mips: always resolve active bfd mach dynamically 82045 Don't assume that the default bfd that we configured for is the one 82046 that is always active when running a program. We already have access 82047 to the real runtime value, so use it directly. This simplifies the 82048 code quite a bit, and will make it easier to support multiple mach's 82049 in a single binary. 82050 82051 sim: hw-config.h: move generation to top-level 82052 In order to compile arch objects from the top-level, we need to 82053 generate the hw-config.h header, so move that logic up to the top 82054 level first. 82055 82056 sim: build: hoist lists of hw devices up 82057 We need these in the top-level to generate libsim.a, but also in the 82058 subdirs to generate hw-config.h. Move it to the local.mk, and pass 82059 it down when running recursive make. This avoids duplication, and 82060 makes it available to both. We can simplify this once we move the 82061 various steps up to the top-level too. 82062 82063 sim: build: hoist lists of common objects up 82064 In order to create libsim.a in the common dir, we need the list of 82065 objects for each target. To avoid duplicating the list with the 82066 recursive make in each port, pass it down as a variable. This is 82067 a temporary hack until the top-level creates libsim.a for ports. 82068 820692022-12-22 GDB Administrator <gdbadmin@sourceware.org> 82070 82071 Automatic date update in version.in 82072 820732022-12-21 Alan Modra <amodra@gmail.com> 82074 82075 PR29925, Memory leak in find_abstract_instance 82076 The testcase in the PR had a variable with both DW_AT_decl_file and 82077 DW_AT_specification, where the DW_AT_specification also specified 82078 DW_AT_decl_file. This leads to a memory leak as the file name is 82079 malloced and duplicates are not expected. 82080 82081 I've also changed find_abstract_instance to not use a temp for "name", 82082 because that can result in a change in behaviour from the usual last 82083 of duplicate attributes wins. 82084 82085 PR 29925 82086 * dwarf2.c (find_abstract_instance): Delete "name" variable. 82087 Free *filename_ptr before assigning new file name. 82088 (scan_unit_for_symbols): Similarly free func->file and 82089 var->file before assigning. 82090 820912022-12-21 Andrew Pinski <apinski@marvell.com> 82092 82093 Fix compiling of top.c 82094 When I moved my last patch forward, somehow I missed removing 82095 the #endif for the HAVE_LIBMPFR case. 82096 82097 Committed as obvious after a quick build. 82098 82099 gdb/ChangeLog: 82100 * top.c: Remove the extra #endif which was missed. 82101 821022022-12-21 Andrew Pinski <apinski@marvell.com> 82103 82104 Use toplevel configure for GMP and MPFR for gdb 82105 This patch uses the toplevel configure parts for GMP/MPFR for 82106 gdb. The only thing is that gdb now requires MPFR for building. 82107 Before it was a recommended but not required library. 82108 Also this allows building of GMP and MPFR with the toplevel 82109 directory just like how it is done for GCC. 82110 We now error out in the toplevel configure of the version 82111 of GMP and MPFR that is wrong. 82112 82113 OK after GDB 13 branches? Build gdb 3 ways: 82114 with GMP and MPFR in the toplevel (static library used at that point for both) 82115 With only MPFR in the toplevel (GMP distro library used and MPFR built from source) 82116 With neither GMP and MPFR in the toplevel (distro libraries used) 82117 82118 Changes from v1: 82119 * Updated gdb/README and gdb/doc/gdb.texinfo. 82120 * Regenerated using unmodified autoconf-2.69 82121 82122 Thanks, 82123 Andrew Pinski 82124 82125 ChangeLog: 82126 * Makefile.def: Add configure-gdb dependencies 82127 on all-gmp and all-mpfr. 82128 * configure.ac: Split out MPC checking from MPFR. 82129 Require GMP and MPFR if the gdb directory exist. 82130 * Makefile.in: Regenerate. 82131 * configure: Regenerate. 82132 82133 gdb/ChangeLog: 82134 82135 PR bug/28500 82136 * configure.ac: Remove AC_LIB_HAVE_LINKFLAGS 82137 for gmp and mpfr. 82138 Use GMPLIBS and GMPINC which is provided by the 82139 toplevel configure. 82140 * Makefile.in (LIBGMP, LIBMPFR): Remove. 82141 (GMPLIBS, GMPINC): Add definition. 82142 (INTERNAL_CFLAGS_BASE): Add GMPINC. 82143 (CLIBS): Exchange LIBMPFR and LIBGMP 82144 for GMPLIBS. 82145 * target-float.c: Make the code conditional on 82146 HAVE_LIBMPFR unconditional. 82147 * top.c: Remove code checking HAVE_LIBMPFR. 82148 * configure: Regenerate. 82149 * config.in: Regenerate. 82150 * README: Update GMP/MPFR section of the config 82151 options. 82152 * doc/gdb.texinfo: Likewise. 82153 82154 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500 82155 821562022-12-21 Bruno Larsen <blarsen@redhat.com> 82157 82158 gdb/c++: validate 'using' directives based on the current line 82159 When asking GDB to print a variable from an imported namespace, we only 82160 want to see variables imported in lines that the inferior has already 82161 gone through, as is being tested last in gdb.cp/nsusing.exp. However 82162 with the proposed change to gdb.cp/nsusing.exp, we get the following 82163 failures: 82164 82165 (gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop 82166 print x 82167 $9 = 911 82168 (gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement 82169 next 82170 15 y += x; 82171 (gdb) PASS: gdb.cp/nsusing.exp: using namespace M 82172 print x 82173 $10 = 911 82174 (gdb) PASS: gdb.cp/nsusing.exp: print x, only using M 82175 82176 Showing that the feature wasn't functioning properly, it just so 82177 happened that gcc ordered the namespaces in a convenient way. 82178 This happens because GDB doesn't take into account the line where the 82179 "using namespace" directive is written. So long as it shows up in the 82180 current scope, we assume it is valid. 82181 82182 To fix this, add a new member to struct using_direct, that stores the 82183 line where the directive was written, and a new function that informs if 82184 the using directive is valid already. 82185 82186 Unfortunately, due to a GCC bug, the failure still shows up. Compilers 82187 that set the declaration line of the using directive correctly (such as 82188 Clang) do not show such a bug, so the test includes an XFAIL for gcc 82189 code. 82190 82191 Finally, because the final test of gdb.cp/nsusing.exp has turned into 82192 multiple that all would need XFAILs for older GCCs (<= 4.3), and that 82193 GCC is very old, if it is detected, the test just exits early. 82194 82195 Approved-by: Tom Tromey <tom@tromey.com> 82196 821972022-12-21 Nick Clifton <nickc@redhat.com> 82198 82199 Updated Romanian translation for the BFD sub-directory. 82200 82201 Fix an attempt to allocate an unreasonably large amount of memory when parsing a corrupt ELF file. 82202 PR 29924 82203 * objdump.c (load_specific_debug_section): Check for excessively 82204 large sections. 82205 82206 Keep the .drectve section when performing a relocateable link. 82207 PR 29900 82208 * scripttempl/pe.sc: Keep the .drectve section when performing a 82209 relocateable link. 82210 * scripttempl/pep.sc: Likewise. 82211 822122022-12-21 Jan Beulich <jbeulich@suse.com> 82213 82214 x86: rename CheckRegSize to CheckOperandSize 82215 While originally indeed used for register size checking only, the 82216 attribute has been used for memory operand size checking as well already 82217 for quite a while, with more such uses recently having been added. 82218 82219 gprofng/testsuite: restrict testing to native configurations 82220 The binaries involved in testing gprofng are native ones, and hence a 82221 cross build of binutils won't really test intended functionality. Since 82222 this testing takes quite a bit of time (typically more than running all 82223 of binutils, gas, and ld testsuites together), restrict the testing to 82224 native configurations only. 82225 822262022-12-21 Alan Modra <amodra@gmail.com> 82227 82228 enable-non-contiguous-regions warnings 82229 The warning about discarded sections in elf_link_input_bfd doesn't 82230 belong there since the code is dealing with symbols. Multiple symbols 82231 in a discarded section will result in multiple identical warnings 82232 about the section. Move the warning to a new function in ldlang.c. 82233 82234 The patch also tidies the warning quoting of section and file names, 82235 consistently using `%pA' and `%pB'. I'm no stickler for one style of 82236 section and file name quoting, but they ought to be consistent within 82237 a warning, eg. see the first one fixed in ldlang.c, and when a warning 82238 is emitted for multiple targets they all ought to use exactly the same 82239 format string to reduce translation work. elf64-ppc.c loses the 82240 build_one_stub errors since we won't get there before hitting the 82241 fatal errors in size_one_stub. 82242 82243 bfd/ 82244 * elflink.c (elf_link_input_bfd): Don't warn here about 82245 discarded sections. 82246 * elf32-arm.c (arm_build_one_stub): Use consistent style in 82247 --enable-non-contiguous-regions error. 82248 * elf32-csky.c (csky_build_one_stub): Likewise. 82249 * elf32-hppa.c (hppa_build_one_stub): Likewise. 82250 * elf32-m68hc11.c (m68hc11_elf_build_one_stub): Likewise. 82251 * elf32-m68hc12.c (m68hc12_elf_build_one_stub): Likewise. 82252 * elf32-metag.c (metag_build_one_stub): Likewise. 82253 * elf32-nios2.c (nios2_build_one_stub): Likewise. 82254 * elfnn-aarch64.c (aarch64_build_one_stub): Likewise. 82255 * xcofflink.c (xcoff_build_one_stub): Likewise. 82256 * elf64-ppc.c (ppc_size_one_stub): Likewise. 82257 (ppc_build_one_stub): Delete dead code. 82258 ld/ 82259 * ldlang.c (lang_add_section): Use consistent style in 82260 --enable-non-contiguous-regions warnings. 82261 (size_input_section): Likewise. 82262 (warn_non_contiguous_discards): New function. 82263 (lang_process): Call it. 82264 * testsuite/ld-arm/non-contiguous-arm.d: Update. 82265 * testsuite/ld-arm/non-contiguous-arm4.d: Update. 82266 * testsuite/ld-arm/non-contiguous-arm7.d: Add 82267 --enable-non-contiguous-regions-warnings. 82268 * testsuite/ld-arm/non-contiguous-arm7.err: New. 82269 * testsuite/ld-powerpc/non-contiguous-powerpc.d: Update. 82270 * testsuite/ld-powerpc/non-contiguous-powerpc64.d: Update. 82271 822722022-12-21 Alan Modra <amodra@gmail.com> 82273 82274 PR29922, SHT_NOBITS section avoids section size sanity check 82275 PR 29922 82276 * dwarf2.c (find_debug_info): Ignore sections without 82277 SEC_HAS_CONTENTS. 82278 822792022-12-21 Mike Frysinger <vapier@gentoo.org> 82280 82281 sim: fully merge sim_cpu_base into sim_cpu 82282 Now that all ports have migrated to the new framework, drop support 82283 for the old sim_cpu_base layout. There's a lot of noise here, so 82284 it's been split into a dedicated commit. 82285 82286 sim: enable common sim_cpu usage everywhere 82287 All ports should be migrated now. Drop the SIM_HAVE_COMMON_SIM_CPU 82288 knob and require it be used everywhere now. 82289 82290 sim: or1k: invert sim_cpu storage 82291 The cpu.h change is in generated cgen code, but that has been sent 82292 upstream too, so the next regen should include it automatically. 82293 82294 sim: m32r: invert sim_cpu storage 82295 The cpu*.h changes are in generated cgen code, but that has been sent 82296 upstream too, so the next regen should include it automatically. 82297 82298 sim: lm32: invert sim_cpu storage 82299 The cpu.h change is in generated cgen code, but that has been sent 82300 upstream too, so the next regen should include it automatically. 82301 82302 sim: iq2000: invert sim_cpu storage 82303 The cpu.h change is in generated cgen code, but that has been sent 82304 upstream too, so the next regen should include it automatically. 82305 82306 sim: frv: invert sim_cpu storage 82307 The cpu.h change is in generated cgen code, but that has been sent 82308 upstream too, so the next regen should include it automatically. 82309 82310 sim: cris: invert sim_cpu storage 82311 The cpu*.h changes are in generated cgen code, but that has been sent 82312 upstream too, so the next regen should include it automatically. 82313 82314 sim: bpf: invert sim_cpu storage 82315 The cpu.h change is in generated cgen code, but that has been sent 82316 upstream too, so the next regen should include it automatically. 82317 82318 sim: cgen: prep for inverting sim_cpu storage 82319 Some common cgen code changes to allow cgen ports to invert their 82320 sim_cpu storage one-by-one. 82321 82322 sim: riscv: invert sim_cpu storage 82323 82324 sim: pru: invert sim_cpu storage 82325 82326 sim: example-synacor: invert sim_cpu storage 82327 82328 sim: h8300: invert sim_cpu storage 82329 82330 sim: m68hc11: invert sim_cpu storage 82331 82332 sim: mips: invert sim_cpu storage 82333 82334 sim: v850: invert sim_cpu storage 82335 82336 sim: mcore: invert sim_cpu storage 82337 82338 sim: aarch64: invert sim_cpu storage 82339 82340 sim: microblaze: invert sim_cpu storage 82341 82342 sim: avr: invert sim_cpu storage 82343 82344 sim: moxie: invert sim_cpu storage 82345 82346 sim: msp430: invert sim_cpu storage 82347 82348 sim: ft32: invert sim_cpu storage 82349 82350 sim: bfin: invert sim_cpu storage 82351 823522022-12-21 Mike Frysinger <vapier@gentoo.org> 82353 82354 sim: sim_cpu: invert sim_cpu storage 82355 Currently all ports have to declare sim_cpu themselves in their 82356 sim-main.h and then embed the common sim_cpu_base in it. This 82357 dynamic makes it impossible to share common object code among 82358 multiple ports because the core data structure is always different. 82359 82360 Let's invert this relationship: common code declares sim_cpu, and 82361 the port uses the new arch_data field for its per-cpu state. 82362 82363 This is the first in a series of changes: it adds a define to select 82364 between the old & new layouts, then converts all the ports that don't 82365 need custom state over to the new layout. This includes mn10300 that, 82366 while it defines custom fields in its cpu struct, never uses them. 82367 823682022-12-21 Mike Frysinger <vapier@gentoo.org> 82369 82370 sim: move register headers into sim/ namespace [PR sim/29869] 82371 These headers define the register numbers for each port to implement 82372 the sim_fetch_register & sim_store_register interfaces. While gdb 82373 uses these, the APIs are part of the sim, not gdb. Move the headers 82374 out of the gdb/ include namespace and into sim/ instead. 82375 82376 sim: ppc: drop old dgen.c generator 82377 The spreg.[ch] files live in the source tree now and are created 82378 with the dgen.py script, so we don't need this old tool anymore. 82379 823802022-12-21 Mike Frysinger <vapier@gentoo.org> 82381 82382 sim: ppc: move spreg.[ch] files to the source tree 82383 Simplify the build by moving the generation of these files from 82384 build-time (via dgen.c that we have to compile & execute on the 82385 build system) to maintainer/release mode (via spreg-gen.py that 82386 we only ever execute when the spreg table actually changes). It 82387 speeds up the build process and makes it easier for us to reason 82388 about & review changes to the code generator. 82389 82390 The tool is renamed from "dgen" because it's hardcoded to only 82391 generated spreg files. It isn't a generalized tool for creating 82392 lookup tables. 82393 823942022-12-21 GDB Administrator <gdbadmin@sourceware.org> 82395 82396 Automatic date update in version.in 82397 823982022-12-20 Hannes Domani <ssbssa@yahoo.de> 82399 82400 Fix install-strip target 82401 The libtool patch broke install-strip of gdb: 82402 82403 /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb 82404 transformed_name=`t='s,y,y,'; \ 82405 echo gdb | sed -e "$t"` ; \ 82406 if test "x$transformed_name" = x; then \ 82407 transformed_name=gdb ; \ 82408 else \ 82409 true ; \ 82410 fi ; \ 82411 /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \ 82412 /bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \ 82413 gdb \ 82414 /src/gdb/inst/bin/$transformed_name ; \ 82415 /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \ 82416 /usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h 82417 libtool: install: `/src/gdb/inst/bin/gdb' is not a directory 82418 libtool: install: Try `libtool --help --mode=install' for more information. 82419 82420 Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the 82421 gdb executable is not installed with install-strip. 82422 824232022-12-20 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 82424 82425 bfd: Discard symbol regardless of warning flag 82426 The discard of symbols should be performed whether the warning for 82427 the discard is enabled or not. 82428 Without this patch, ld would segfault in bfd_section_removed_from_list, 82429 called in the if-statement right after this block, as the argument 82430 isec->output_section can be NULL. 82431 82432 Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com> 82433 824342022-12-20 Alan Modra <amodra@gmail.com> 82435 82436 PR29915, bfdio.c does not compile with mingw.org's MinGW 82437 PR 29915 82438 * configure.ac: Add AC_CHECK_DECLS test ___lc_codepage_func. 82439 * configure: Regenerate. 82440 * config.in: Regenerate. 82441 * bfdio.c (___lc_codepage_func): Move declaration to.. 82442 (_bfd_real_fopen): ..here, and use !HAVE_DECL____LC_CODEPAGE_FUNC. 82443 82444 Re: x86: remove i386-opc.c 82445 Regen opcodes/po/POTFILES.in 82446 824472022-12-20 Mike Frysinger <vapier@gentoo.org> 82448 82449 sim: ppc: change spreg switch table generation to compile-time 82450 Simplify the generator by always outputting the switch tables, and 82451 leave the choice of whether to use them to the compiler via a -D 82452 flag. 82453 824542022-12-20 Mike Frysinger <vapier@gentoo.org> 82455 82456 sim: dv-core: add hw_detach_address method [PR sim/25211] 82457 The core device has an attach address method as the root of the tree 82458 which calls out to the sim API. But it doesn't have a corresponding 82459 detach method which means we just crash if anything tries to detach 82460 itself from the core. In practice, the m68hc11 is the only model 82461 that actually tries to detach itself on the fly, so no one noticed 82462 earlier. 82463 82464 With this in place, we can delete the existing detach code from the 82465 m68hc11 model since it defaults to "passthru" callback which will in 82466 turn call the dv-core detach, and they have the same behavior -- call 82467 the sim core API to detach from the address space. 82468 82469 Bug: https://sourceware.org/PR25211 82470 824712022-12-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 82472 82473 gprofng: PR29646 Various warnings 82474 gprofng/ChangeLog 82475 2022-12-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 82476 82477 PR gprofng/29646 82478 * common/core_pcbe.c: Fix missingReturn warning. 82479 * libcollector/iolib.c: Fix -Waddress warnings. 82480 * src/Settings.cc: Likewise. 82481 * src/checks.cc: Likewise. 82482 * libcollector/linetrace.c: Likewise. 82483 * libcollector/iotrace.c: Fix va_end_missing error. 82484 * libcollector/libcol_util.c: Fix uninitvar warning. 82485 * src/Command.cc: Fix arrayIndexOutOfBounds error. 82486 * src/Function.cc: Fix uninitStructMember warning. 82487 * src/ipc.cc: Fix -Wwrite-strings warnings. 82488 824892022-12-20 GDB Administrator <gdbadmin@sourceware.org> 82490 82491 Automatic date update in version.in 82492 824932022-12-19 Tom Tromey <tromey@adacore.com> 82494 82495 Avoid compiler warning in dwarf-do-refresh 82496 The Emacs 28 compiler warns about dwarf-mode.el: 82497 82498 Warning (comp): dwarf-mode.el:180:32: Warning: Unused lexical argument `ignore' 82499 82500 This is easily fixed by prepending "_" to the parameter's name. 82501 82502 binutils/ChangeLog 82503 2022-12-19 Tom Tromey <tromey@adacore.com> 82504 82505 * dwarf-mode.el (dwarf-do-refresh): Avoid compiler warning. 82506 825072022-12-19 Tom Tromey <tom@tromey.com> 82508 82509 Use bool in bpstat 82510 This changes bpstat to use 'bool' rather than 'char', and updates the 82511 uses. 82512 82513 Use bool constants for value_print_options 82514 This changes the uses of value_print_options to use 'true' and 'false' 82515 rather than integers. 82516 82517 Remove quick_symbol_functions::relocated 82518 quick_symbol_functions::relocated is only needed for psymtabs, and 82519 there it is only needed for Rust. However, because we've switched the 82520 DWARF reader away from psymtabs, this means there's no longer a need 82521 for this method at all. 82522 825232022-12-19 Tom Tromey <tom@tromey.com> 82524 82525 Remove MI version 1 82526 MI version 1 is long since obsolete. Several years ago, I filed 82527 PR mi/23170 for this. I think it's finally time to remove this. 82528 Any users of MI 1 can and should upgrade to a newer version. 82529 82530 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170 82531 825322022-12-19 Tom Tromey <tom@tromey.com> 82533 82534 Remove vestiges of MI version 0 82535 I found a few vestiges of MI version 0 in the test suite. This patch 82536 removes them. 82537 825382022-12-19 Alan Modra <amodra@gmail.com> 82539 82540 Tidy PR29893 and PR29908 fix 82541 PR 29893 82542 PR 29908 82543 * dwarf.c (display_debug_addr): Combine dwarf5 unit_length checks. 82544 Delete dead code. 82545 825462022-12-19 Jan Vrany <jan.vrany@labware.com> 82547 82548 gdb: fix command lookup in execute_command () 82549 Commit b5661ff2 ("gdb: fix possible use-after-free when 82550 executing commands") used lookup_cmd_exact () to lookup 82551 command again after its execution to avoid possible 82552 use-after-free error. 82553 82554 However this change broke test gdb.base/define.exp which 82555 defines a post-hook for subcommand ("target testsuite"). 82556 In this case, lookup_cmd_exact () returned NULL because 82557 there's no command 'testsuite' in top-level commands. 82558 82559 This commit fixes this case by looking up the command again 82560 using the original command line via lookup_cmd (). 82561 82562 Approved-By: Simon Marchi <simon.marchi@efficios.com> 82563 825642022-12-19 Nick Clifton <nickc@redhat.com> 82565 82566 Fix potential illegal memory accesses when parsing corrupt DWARF data. 82567 PR 29914 82568 * dwarf.c (fetch_indexed_value): Fail if the section is not big 82569 enough to contain a header size field. 82570 (display_debug_addr): Fail if the computed address size is too big 82571 or too small. 82572 82573 New Romainian translation for the GOLD subdirectory. 82574 825752022-12-19 Jan Beulich <jbeulich@suse.com> 82576 82577 gprofng/testsuite: skip Java test without JDK 82578 There's no point in even trying the Java test when gprofng was built 82579 without Java support, and when the building of the constituents of the 82580 testcase also would fail. On such systems this converts the respective 82581 tests from "unresolved" to "unsupported", making the overall testsuite 82582 run no longer report failure just because of this. 82583 82584 gprofng/testsuite: eliminate bogus casts 82585 Casting pointers to unsigned int is generally problematic and hence 82586 compilers tend to warn about such. While here they're used only in 82587 fprintf(), it still seems better to omit such casts, even if only to 82588 avoid setting bad precedents. 82589 82590 gprofng/testsuite: correct line continuation in endcases.c 82591 A backslash used to indicate line continuation (in a macro definition 82592 here) is not supposed to be followed by blanks or other white space; the 82593 end-of-line indicator is to follow immediately. 82594 82595 gprofng/testsuite: correct names for signal handling tests 82596 The signal handling tests spend most of their time in the signal 82597 handlers, and hence for profile output to match anything in program 82598 output, the respective name fields need to hold the handler function 82599 names. This converts both respective tests from "unresolved" to actually 82600 succeeding. 82601 82602 gprofng/testsuite: adjust linking of synprog 82603 In order for so_syn.so and so_syx.so to be able to access the main 82604 program's "testtime" variable, that variable needs exposing in the 82605 dynamic symbol table. Since this is a test program only, do it the brute 82606 force way and simply expose all global symbols. 82607 82608 Arm: break gas dependency on libopcodes 82609 gas doesn't use anything from libopcodes (anymore?) - suppress linking 82610 in that library. 82611 82612 x86: omit Cpu prefixes from opcode table 82613 These enumerators can be used in only one specific field, and hence the 82614 Cpu prefix isn't needed ther for disambiguation / name space separation. 82615 826162022-12-19 GDB Administrator <gdbadmin@sourceware.org> 82617 82618 Automatic date update in version.in 82619 826202022-12-18 Alan Modra <amodra@gmail.com> 82621 82622 Comment bfd_get_section_limit_octets and bfd_get_section_alloc_size 82623 * bfd.c (bfd_get_section_limit_octets): Add comment. 82624 (bfd_get_section_alloc_size): Likewise. 82625 * libbfd.c (_bfd_generic_get_section_contents): Use 82626 bfd_get_section_limit_octets. 82627 * section.c (bfd_get_section_contents): Likewise. 82628 * bfd-in2.h: Regenerate. 82629 826302022-12-18 Alan Modra <amodra@gmail.com> 82631 82632 ld bootstrap test in build dir with path containing symlinks 82633 This allows the bootstrap test to run if you have a symlink somewhere 82634 in the build path directory. $ld depends on $base_dir which is set 82635 via tcl [pwd], collapsing the symlink like /usr/bin/pwd, while $objdir 82636 contains the symlink. 82637 82638 * testsuite/ld-bootstrap/bootstrap.exp: Normalize paths when 82639 checking for ld build directory. 82640 826412022-12-18 Joel Brobecker <brobecker@adacore.com> 82642 82643 Update gdb/NEWS after GDB 13 branch creation. 82644 This commit a new section for the next release branch, and renames 82645 the section of the current branch, now that it has been cut. 82646 826472022-12-18 Joel Brobecker <brobecker@adacore.com> 82648 82649 Bump version to 14.0.50.DATE-git. 82650 Now that the GDB 13 branch has been created, 82651 this commit bumps the version number in gdb/version.in to 82652 14.0.50.DATE-git 82653 82654 For the record, the GDB 13 branch was created 82655 from commit 71c90666e601c511a5f495827ca9ba545e4cb463. 82656 82657 Also, as a result of the version bump, the following changes 82658 have been made in gdb/testsuite: 82659 82660 * gdb.base/default.exp: Change $_gdb_major to 14. 82661 826622022-12-18 GDB Administrator <gdbadmin@sourceware.org> 82663 82664 Automatic date update in version.in 82665 826662022-12-17 Alan Modra <amodra@gmail.com> 82667 82668 bfd_get_relocated_section_contents allow NULL data buffer 82669 This patch removes the bfd_malloc in default_indirect_link_order and 82670 bfd_simple_get_relocated_section_contents, pushing the allocation down 82671 to bfd_get_relocated_section_contents. The idea is to make use of the 82672 allocation done with sanity checking in bfd_get_full_section_contents, 82673 which is called by bfd_generic_get_relocated_section_contents. 82674 82675 Doing this exposed a bug in bfd_get_full_section_contents. With 82676 relaxation it is possible that an input section rawsize is different 82677 to the section size. In that case we want to use the larger of 82678 rawsize (the on-disk size for input sections) and size. 82679 82680 * reloc.c (bfd_generic_get_relocated_section_contents), 82681 * reloc16.c (bfd_coff_reloc16_get_relocated_section_contents), 82682 * coff-alpha.c (alpha_ecoff_get_relocated_section_contents), 82683 * coff-sh.c (sh_coff_get_relocated_section_contents), 82684 * elf-m10200.c (mn10200_elf_get_relocated_section_contents), 82685 * elf-m10300.c (mn10300_elf_get_relocated_section_contents), 82686 * elf32-avr.c (elf32_avr_get_relocated_section_contents), 82687 * elf32-cr16.c (elf32_cr16_get_relocated_section_contents), 82688 * elf32-crx.c (elf32_crx_get_relocated_section_contents), 82689 * elf32-h8300.c (elf32_h8_get_relocated_section_contents), 82690 * elf32-nds32.c (nds32_elf_get_relocated_section_contents), 82691 * elf32-sh.c (sh_elf_get_relocated_section_contents), 82692 * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents): 82693 Handle NULL data buffer. 82694 * bfd.c (bfd_get_section_alloc_size): New function. 82695 * bfd-in2.h: Regenerate. 82696 * compress.c (bfd_get_full_section_contents): Correct section 82697 malloc size. 82698 * linker.c (default_indirect_link_order): Don't malloc memory 82699 here before calling bfd_get_relocated_section_contents. 82700 * simple.c (bfd_simple_get_relocated_section_contents): Likewise. 82701 827022022-12-17 Alan Modra <amodra@gmail.com> 82703 82704 asan: elf.c:12621:18: applying zero offset to null pointer 82705 That's this line in elf_parse_notes: 82706 while (p < buf + size) 82707 82708 * elf.c (_bfd_elf_make_section_from_shdr): Don't call 82709 elf_parse_notes when sh_size is zero. 82710 827112022-12-17 Alan Modra <amodra@gmail.com> 82712 82713 Re: The problem with warning in elf_object_p 82714 Commit 5aa0f10c424e added a per_xvec_warn array to provide support for 82715 warnings from elf_object_p (and a later patch for warnings from 82716 pe_bfd_object_p) to be cached and then only printed if the target 82717 matches. It was quite limited in the style of message supported, only 82718 one message could be printed, and didn't really meet the stated aim of 82719 only warning when a target matches: There are many other errors and 82720 warnings that can be emitted by functions called from elf_object_p. 82721 82722 So this patch extends the error handler functions to support printing 82723 to a string buffer, extends per_xvec_warn to support multiple errors/ 82724 warnings, and hooks this all into bfd_check_format_matches. If 82725 bfd_check_format_matches succeeds then any errors/warnings are printed 82726 for the matching target. If bfd_check_format_matches fails either due 82727 to no match or to multiple matches and only one target vector produced 82728 errors, then those errors are printed. 82729 82730 * bfd.c (MAX_ARGS): Define, use throughout. 82731 (print_func): New typedef. 82732 (_bfd_doprnt): Add new print param. Replace calls to fprintf 82733 with print. 82734 (PRINT_TYPE): Similarly. 82735 (error_handler_fprintf): Renamed from error_handler_internal. 82736 Use _bfd_get_error_program_name. Add fprintf arg. Move code 82737 setting up args.. 82738 (_bfd_doprnt_scan): ..to here. Add ap param. 82739 (struct buf_stream): New. 82740 (err_sprintf): New function. 82741 (error_handler_bfd): New static variable. 82742 (error_handler_sprintf): New function. 82743 (_bfd_set_error_handler_caching): New function. 82744 (_bfd_get_error_program_name): New function. 82745 * elfcode.h (elf_swap_shdr_in): Use _bfd_error_handler in 82746 warning messages. 82747 (elf_object_p): Likewise. 82748 * format.c (print_warnmsg): New function. 82749 (clear_warnmsg): Rewrite. 82750 (null_error_handler): New function. 82751 (bfd_check_format_matches): Ignore warnings from recursive calls 82752 checking first element of an archive. Use caching error handler 82753 otherwise. Print warnings on successful match, or when only one 82754 target has emitted warnings/errors. 82755 * peicode.h (pe_bfd_object_p): Use _bfd_error_handler in 82756 warning messages. 82757 * targets.c (per_xvec_warn): Change type of array elements. 82758 (struct per_xvec_message): New. 82759 (_bfd_per_xvec_warn): Rewrite. 82760 * Makefile.am (LIBBFD_H_FILES): Add bfd.c. 82761 * Makefile.in: Regenerate. 82762 * bfd-in2.h: Regenerate. 82763 * libbfd.h: Regenerate. 82764 827652022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82766 82767 sframe: doc: update spec for the mangled-RA bit in FRE 82768 ChangeLog: 82769 82770 * libsframe/doc/sframe-spec.texi 82771 827722022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82773 82774 gas: sframe: testsuite: add testcase for .cfi_negate_ra_state 82775 Add a new test to check that .cfi_negate_ra_state on aarch64 is handled 82776 well (a non-empty SFrame section with valid SFrame FREs is generated). 82777 82778 ChangeLog: 82779 82780 * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.d: New test. 82781 * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise. 82782 * testsuite/gas/cfi-sframe/cfi-sframe.exp: Adjust the list 82783 accordingly. 82784 827852022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82786 82787 objdump/readelf: sframe: emit marker for FREs with mangled RA 82788 In the textual dump of the SFrame section, when an SFrame FRE recovers a 82789 mangled RA, use string "[s]" in the output to indicate that the return 82790 address is a signed (mangled) one. 82791 82792 ChangeLog: 82793 82794 * libsframe/sframe-dump.c (dump_sframe_func_with_fres): Postfix 82795 with "[s]" if RA is signed with authorization code. 82796 827972022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82798 82799 libsframe: provide new access API for mangled RA bit 82800 include/ChangeLog: 82801 82802 * sframe-api.h (sframe_fre_get_ra_mangled_p): New declaration. 82803 82804 ChangeLog: 82805 82806 * libsframe/sframe.c (sframe_get_fre_ra_mangled_p): New 82807 definition. 82808 (sframe_fre_get_ra_mangled_p): New static function. 82809 828102022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82811 82812 gas: sframe: add support for .cfi_negate_ra_state 82813 DW_CFA_AARCH64_negate_ra_state in aarch64 is multiplexed with 82814 DW_CFA_GNU_window_save in the DWARF format. 82815 82816 Remove the common-empty-4 testcase because the generated SFrame section 82817 will not be be empty anymore. A relevant test will be added in a later 82818 commit. 82819 82820 ChangeLog: 82821 82822 * gas/gen-sframe.c (sframe_v1_set_fre_info): Add new argument 82823 for mangled_ra_p. 82824 (sframe_set_fre_info): Likewise. 82825 (output_sframe_row_entry): Handle mangled_ra_p. 82826 (sframe_row_entry_new): Reset mangled_ra_p. 82827 (sframe_row_entry_initialize): Initialize mangled_ra_p. 82828 (sframe_xlate_do_gnu_window_save): New definition. 82829 (sframe_do_cfi_insn): Handle DW_CFA_GNU_window_save. 82830 * gas/gen-sframe.h (struct sframe_row_entry): New member. 82831 (struct sframe_version_ops): Add a new argument for 82832 mangled_ra_p. 82833 * gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Remove test. 82834 * gas/testsuite/gas/cfi-sframe/common-empty-4.d: Removed. 82835 * gas/testsuite/gas/cfi-sframe/common-empty-4.s: Removed. 82836 828372022-12-17 Indu Bhagat <indu.bhagat@oracle.com> 82838 82839 sframe.h: add support for .cfi_negate_ra_state 82840 Use the last remaining bit in the 'SFrame FRE info' word to store whether 82841 the RA is signed/unsigned with PAC authorization code: this bit is named 82842 as the "mangled RA" bit. This bit is still unused for x86-64. 82843 82844 The behaviour of the mangled-RA info bit in SFrame format closely 82845 follows the behaviour of DW_CFA_AARCH64_negate_ra_state in DWARF. During 82846 unwinding, whenever an SFrame FRE with non-zero "mangled RA" bit is 82847 encountered, it means the upper bits of the return address contain Pointer 82848 Authentication code. The unwinder, hence, must use appropriate means to 82849 restore LR correctly in such cases. 82850 82851 include/ChangeLog: 82852 82853 * sframe.h (SFRAME_V1_FRE_INFO_UPDATE_MANGLED_RA_P): New macro. 82854 (SFRAME_V1_FRE_MANGLED_RA_P): Likewise. 82855 828562022-12-17 GDB Administrator <gdbadmin@sourceware.org> 82857 82858 Automatic date update in version.in 82859 828602022-12-16 Pedro Alves <pedro@palves.net> 82861 82862 Delay checking whether /proc/pid/mem is writable (PR gdb/29907) 82863 As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is 82864 writable"), GDB checks if /proc/pid/mem is writable. This is done 82865 early at GDB startup, in order to get a consistent warning, instead of 82866 a warning that depends on whenever GDB writes to inferior memory. 82867 82868 PR gdb/29907 points out that some build systems (like QEMU's, 82869 apparently) may call 'gdb --version' to check GDB's presence & its 82870 version on the system, and that Gentoo's build process has sandboxing 82871 which blocks the /proc/pid/mem access and thus GDB warns, which 82872 results in build fails. 82873 82874 To help with that, this patch delays the /proc/pid/mem check until we 82875 start or attach to an inferior. Ends up potentially emiting a warning 82876 close where we already emit other ptrace- and /proc- related warnings, 82877 which just Feels Right. 82878 82879 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907 82880 Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763 82881 828822022-12-16 Nick Clifton <nickc@redhat.com> 82883 82884 Fix previous delta to allow for compilation on 32-bit systems 82885 828862022-12-16 Tom de Vries <tdevries@suse.de> 82887 82888 [gdb/testsuite] Fix race in gdb.threads/detach-step-over.exp 82889 Once in a while I run into: 82890 ... 82891 FAIL: gdb.threads/detach-step-over.exp: \ 82892 breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \ 82893 displaced=off: iter 1: all threads running 82894 ... 82895 82896 In can easily reproduce this by doing: 82897 ... 82898 # Wait a bit, to give time for the threads to hit the 82899 # breakpoint. 82900 - sleep 1 82901 82902 return true 82903 ... 82904 82905 Fix this by counting the running threads in a loop, effectively allowing 10 82906 seconds (instead of 1) for the threads to start running, but only sleeping if 82907 needed. 82908 82909 Reduces total execution time from 1m27s to 56s. 82910 82911 Tested on x86_64-linux. 82912 829132022-12-16 Andrew Burgess <aburgess@redhat.com> 82914 82915 gdb: fix crash when getting the value of a label symbol 82916 When the source program contains a goto label, it turns out it's 82917 actually pretty hard for a user to find out more about that label. 82918 For example: 82919 82920 (gdb) p some_label 82921 No symbol "some_label" in current context. 82922 (gdb) disassemble some_label 82923 No symbol "some_label" in current context. 82924 (gdb) x/10i some_label 82925 No symbol "some_label" in current context. 82926 (gdb) break some_label 82927 Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35. 82928 82929 In all cases, some_label is a goto label within the current frame. 82930 Only placing a breakpoint on the label worked. 82931 82932 This all seems a little strange to me, it feels like asking about a 82933 goto label would not be an unreasonable thing for a user to do. 82934 82935 This commit doesn't fix any of the above issues, I mention them just 82936 to provide a little context for why the following issue has probably 82937 not been seen before. 82938 82939 It turns out there is one way a user can access the symbol for a goto 82940 label, through the Python API: 82941 82942 python frame = gdb.selected_frame() 82943 python frame_pc = frame.pc() 82944 python block = gdb.current_progspace().block_for_pc(frame_pc) 82945 python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN) 82946 python print(str(symbol.value())) 82947 ../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed. 82948 82949 The problem is that label symbols are created using the 82950 builtin_core_addr type, which is a pure integer type. 82951 82952 When GDB tries to fetch the value of a label symbol then we end up in 82953 findvar.c, in the function language_defn::read_var_value, in the 82954 LOC_LABEL case. From here store_typed_address is called to store the 82955 address of the label into a value object with builtin_core_addr type. 82956 82957 The problem is that store_typed_address requires that the destination 82958 type be a pointer or reference, which the builtin_core_addr type is 82959 not. 82960 82961 Now it's not clear what type a goto label address should have, but 82962 GCC has an extension that allows users to take the address of a goto 82963 label (using &&), in that case the result is of type 'void *'. 82964 82965 I propose that when we convert the CORE_ADDR value to a GDB value 82966 object, we use builtin_func_ptr type instead of builtin_core_addr, 82967 this means the result will be of type 'void (*) ()'. The benefit of 82968 this approach is that when gdbarch_address_to_pointer is called the 82969 target type will be correctly identified as a pointer to code, which 82970 should mean any architecture specific adjustments are done correctly. 82971 82972 We can then cast the new value to 'void *' type with a call to 82973 value_cast_pointer, this should not change the values bit 82974 representation, but will just update the type. 82975 82976 After this asking for the value of a label symbol works just fine: 82977 82978 (gdb) python print(str(symbol.value())) 82979 0x401135 <main+35> 82980 82981 And the type is maybe what we'd expect: 82982 82983 (gdb) python print(str(symbol.value().type)) 82984 void * 82985 829862022-12-16 Simon Marchi <simon.marchi@polymtl.ca> 82987 82988 gdb: convert linux-osdata.c from buffer to std::string 82989 Replace the use of struct buffer in linux-osdata.c with std::string. 82990 There is no change in the logic, so there should be no user-visible 82991 change. 82992 82993 Change-Id: I27f53165d401650bbd0bebe8ed88221e25545b3f 82994 Approved-By: Pedro Alves <pedro@palves.net> 82995 829962022-12-16 Simon Marchi <simon.marchi@polymtl.ca> 82997 82998 gdbsupport: add string_xml_appendf 82999 Add a version of buffer_xml_printf (defined in gdbsupport/buffer.{c,h}) 83000 that appends to an std::string, rather than a struct buffer. Call it 83001 "string" rather than "buffer" since it operates on an std::string rather 83002 than a buffer. And call it "appendf" rather than "printf", since it 83003 appends to and does not replace the string's content. This mirrors 83004 string_appendf. 83005 83006 Place the new version in gdbsupport/xml-utils.h. 83007 83008 The code is a direct copy of buffer_xml_printf. The old version is 83009 going to disappear at some point, which is why I didn't do any effort to 83010 share code. 83011 83012 Change-Id: I30e030627ab4970fd0b9eba3b7e8cec78fa561ba 83013 Approved-By: Pedro Alves <pedro@palves.net> 83014 830152022-12-16 Andrew Burgess <aburgess@redhat.com> 83016 83017 gdb: clean up some inefficient std::string usage 83018 This commit: 83019 83020 commit 53cf95c3389a3ecd97276d322e4a60fe3396a201 83021 Date: Wed Dec 14 14:17:44 2022 +0000 83022 83023 gdb: make more use of make_target_connection_string 83024 83025 Introduced a couple of inefficient uses of std::string, both of which 83026 are fixed in this commit. 83027 83028 There should be no user visible changes after this commit. 83029 83030 Approved-By: Simon Marchi <simon.marchi@efficios.com> 83031 830322022-12-16 Nick Clifton <nickc@redhat.com> 83033 83034 Fix a potential illegal memory access when parsing corrupt DWARF information. 83035 PR 29908 83036 * dwarf.c (display_debug_addr): Check for corrupt header lengths. 83037 830382022-12-16 Jan Vrany <jan.vrany@labware.com> 83039 83040 gdb/testsuite: add test for Python commands redefining itself 83041 This commit adds a test that creates a Python command that redefines 83042 itself during its execution. This is to test use-after-free in 83043 execute_command (). 83044 83045 This test needs run with ASan enabled in order to fail when it 83046 should. 83047 83048 Approved-By: Simon Marchi <simon.marchi@efficios.com> 83049 830502022-12-16 Luis Machado <luis.machado@arm.com> 83051 83052 [aarch64] Fix removal of non-address bits for PAuth 83053 PR gdb/28947 83054 83055 The address_significant gdbarch setting was introduced as a way to remove 83056 non-address bits from pointers, and it is specified by a constant. This 83057 constant represents the number of address bits in a pointer. 83058 83059 Right now AArch64 is the only architecture that uses it, and 56 was a 83060 correct option so far. 83061 83062 But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes 83063 from the address space to store the required information. We could also have 83064 cases where we're using both PAuth and MTE. 83065 83066 We could adjust the constant to 48 to cover those cases, but this doesn't 83067 cover the case where GDB needs to sign-extend kernel addresses after removal 83068 of the non-address bits. 83069 83070 This has worked so far because bit 55 is used to select between kernel-space 83071 and user-space addresses. But trying to clear a range of bits crossing the 83072 bit 55 boundary requires the hook to be smarter. 83073 83074 The following patch renames the gdbarch hook from significant_addr_bit to 83075 remove_non_address_bits and passes a pointer as opposed to the number of 83076 bits. The hook is now responsible for removing the required non-address bits 83077 and sign-extending the address if needed. 83078 83079 While at it, make GDB and GDBServer share some more code for aarch64 and add a 83080 new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp. 83081 83082 Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947 83083 83084 Approved-By: Simon Marchi <simon.marchi@efficios.com> 83085 830862022-12-16 Jan Beulich <jbeulich@suse.com> 83087 83088 gas: restore Dwarf info generation after macro diagnostic adjustments 83089 While 6fdb723799e2 ("gas: re-work line number tracking for macros and 83090 their expansions") was meant to leave generated Dwarf as is, it really 83091 didn't (and the testcase intended to catch that wasn't covering the case 83092 which broke). Its adjustment to buffer_and_nest() didn't go far enough, 83093 leading to the "linefile" directive inserted at the top to also be 83094 processed later in the PR gas/16908 workaround (which clearly isn't 83095 intended - it's being put there for processing during macro expansion 83096 only). That unnoticed flaw in turn led me to work around it by a 83097 (suspicious to me already at the time) conditional in as_where(). 83098 83099 x86: change representation of extension opcode 83100 Having a "None" field in the vast majority of entries is needlessly 83101 cluttering the overall table. Instead of this being a separate field, 83102 use a representation matching that of Intel SDM and AMD PM for the main 83103 use of the field: Append the value after a / as the separator. 83104 831052022-12-16 Simon Marchi <simon.marchi@polymtl.ca> 83106 83107 gdbsupport: change xml_escape_text_append's parameter from pointer to reference 83108 The passed in string can't be nullptr, it makes more sense to pass in a 83109 reference. 83110 83111 Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3 83112 831132022-12-16 Simon Marchi <simon.marchi@polymtl.ca> 83114 83115 gdb: remove static buffer in command_line_input 83116 [I sent this earlier today, but I don't see it in the archives. 83117 Resending it through a different computer / SMTP.] 83118 83119 The use of the static buffer in command_line_input is becoming 83120 problematic, as explained here [1]. In short, with this patch [2] that 83121 attempt to fix a post-hook bug, when running gdb.base/commands.exp, we 83122 hit a case where we read a "define" command line from a script file 83123 using command_command_line_input. The command line is stored in 83124 command_line_input's static buffer. Inside the define command's 83125 execution, we read the lines inside the define using command_line_input, 83126 which overwrites the define command, in command_line_input's static 83127 buffer. After the execution of the define command, execute_command does 83128 a command look up to see if a post-hook is registered. For that, it 83129 uses a now stale pointer that used to point to the define command, in 83130 the static buffer, causing a use-after-free. Note that the pointer in 83131 execute_command points to the dynamically-allocated buffer help by the 83132 static buffer in command_line_input, not to the static object itself, 83133 hence why we see a use-after-free. 83134 83135 Fix that by removing the static buffer. I initially changed 83136 command_line_input and other related functions to return an std::string, 83137 which is the obvious but naive solution. The thing is that some callees 83138 don't need to return an allocated string, so this this an unnecessary 83139 pessimization. I changed it to passing in a reference to an std::string 83140 buffer, which the callee can use if it needs to return 83141 dynamically-allocated content. It fills the buffer and returns a 83142 pointers to the C string inside. The callees that don't need to return 83143 dynamically-allocated content simply don't use it. 83144 83145 So, it started with modifying command_line_input as described above, all 83146 the other changes derive directly from that. 83147 83148 One slightly shady thing is in handle_line_of_input, where we now pass a 83149 pointer to an std::string's internal buffer to readline's history_value 83150 function, which takes a `char *`. I'm pretty sure that this function 83151 does not modify the input string, because I was able to change it (with 83152 enough massaging) to take a `const char *`. 83153 83154 A subtle change is that we now clear a UI's line buffer using a 83155 SCOPE_EXIT in command_line_handler, after executing the command. 83156 This was previously done by this line in handle_line_of_input: 83157 83158 /* We have a complete command line now. Prepare for the next 83159 command, but leave ownership of memory to the buffer . */ 83160 cmd_line_buffer->used_size = 0; 83161 83162 I think the new way is clearer. 83163 83164 [1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/ 83165 [2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/ 83166 83167 Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300 83168 Reviewed-By: Tom Tromey <tom@tromey.com> 83169 831702022-12-16 GDB Administrator <gdbadmin@sourceware.org> 83171 83172 Automatic date update in version.in 83173 831742022-12-15 Indu Bhagat <indu.bhagat@oracle.com> 83175 83176 libsframe asan: avoid generating misaligned loads 83177 There are two places where unaligned loads were seen on aarch64: 83178 - #1. access to the SFrame FRE stack offsets in the in-memory 83179 representation/abstraction provided by libsframe. 83180 - #2. access to the SFrame FRE start address in the on-disk representation 83181 of the frame row entry. 83182 83183 For #1, we can fix this by reordering the struct members of 83184 sframe_frame_row_entry in libsframe/sframe-api.h. 83185 83186 For #2, we need to default to using memcpy instead, and copy out the bytes 83187 to a location for output. 83188 83189 SFrame format is an unaligned on-disk format. As such, there are other blobs 83190 of memory in the on-disk SFrame FRE that are on not on their natural 83191 boundaries. But that does not pose further problems yet, because the users 83192 are provided access to the on-disk SFrame FRE data via libsframe's 83193 sframe_frame_row_entry, the latter has its' struct members aligned on their 83194 respective natural boundaries (and initialized using memcpy). 83195 83196 PR 29856 libsframe asan: load misaligned at sframe.c:516 83197 83198 ChangeLog: 83199 83200 PR libsframe/29856 83201 * bfd/elf64-x86-64.c: Adjust as the struct members have been 83202 reordered. 83203 * libsframe/sframe.c (sframe_decode_fre_start_address): Use 83204 memcpy to perform 16-bit/32-bit reads. 83205 * libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the 83206 struct members have been reordered. 83207 83208 include/ChangeLog: 83209 83210 PR libsframe/29856 83211 * sframe-api.h: Reorder fre_offsets for natural alignment. 83212 832132022-12-15 Simon Marchi <simon.marchi@polymtl.ca> 83214 83215 gdb/testsuite: don't delete command files in gdb.base/commands.exp 83216 Don't delete the runtime-generated command files. This makes it easier 83217 to reproduce tests by hand. 83218 83219 Change-Id: I4e53484eea216512f1c5d7dfcb5c464b36950946 83220 Approved-By: Tom Tromey <tom@tromey.com> 83221 832222022-12-15 Tom Tromey <tromey@adacore.com> 83223 83224 Move streq and compare_cstrings to gdbsupport 83225 It seems to me that streq and compare_cstrings belong near the other 83226 string utility functions in common-utils.h; and furthermore that streq 83227 ought to be inlined. This patch makes this change. 83228 83229 Approved-By: Simon Marchi <simon.marchi@efficios.com> 83230 832312022-12-15 Tom Tromey <tromey@adacore.com> 83232 83233 Remove subset_compare 83234 I stumbled across subset_compare today, and after looking at the 83235 callers I realized it could be removed and replaced with calls to 83236 startswith. 83237 83238 Approved-By: Simon Marchi <simon.marchi@efficios.com> 83239 832402022-12-15 Andrew Burgess <aburgess@redhat.com> 83241 83242 gdb: use gdb_assert not internal_error 83243 Spotted a couple of places in findvar.c where we use: 83244 83245 if ( ! CONDITION ) 83246 internal_error ("..."); 83247 83248 this commit changes these to be: 83249 83250 gdb_assert ( CONDITION ); 83251 83252 which I think is better. 83253 83254 Unless we happen to hit the internal_error calls (which was bad) there 83255 should be no user visible changes after this commit. 83256 832572022-12-15 Andrew Burgess <aburgess@redhat.com> 83258 83259 gdb: some int to bool conversion in remote-sim.c 83260 Some obvious int to bool conversion in remote-sim.c, there should be 83261 no user visible changes after this commit. 83262 832632022-12-15 Andrew Burgess <aburgess@redhat.com> 83264 83265 gdb: make more use of make_target_connection_string 83266 I noticed that we have a function make_target_connection_string which 83267 wraps all the logic for creating a string that describes a target 83268 connection - but in some places we are not calling this function, 83269 instead we duplicate the function's logic. 83270 83271 This commit cleans this up, and calls make_target_connection_string 83272 where possible. 83273 83274 There should be no user visible changes after this commit. 83275 832762022-12-15 Andrew Burgess <aburgess@redhat.com> 83277 83278 gdb: int to bool conversion in tracefile.c 83279 Some obvious int to bool conversion in tracefile.c. 83280 83281 Should be no user visible changes after this commit. 83282 832832022-12-15 Tom de Vries <tdevries@suse.de> 83284 83285 [gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp with gcc 4.8.5 83286 With gcc 4.8.5, I run into: 83287 ... 83288 Running gdb.base/condbreak-multi-context.exp ... 83289 gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \ 83290 data member initializers only available with -std=c++11 or -std=gnu++11 \ 83291 [enabled by default] 83292 int b = 20; 83293 ^ 83294 ... 83295 83296 Fix this by making it a static const. 83297 83298 Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1. 83299 833002022-12-15 GDB Administrator <gdbadmin@sourceware.org> 83301 83302 Automatic date update in version.in 83303 833042022-12-14 Andrew Burgess <aburgess@redhat.com> 83305 83306 gdb/maint: add core file name to 'maint info program-spaces' output 83307 Each program space can have an associated core file. Include this 83308 information in the output of 'maint info program-spaces'. 83309 833102022-12-14 Andrew Burgess <aburgess@redhat.com> 83311 83312 gdb: ensure all targets are popped before an inferior is destructed 83313 Now that the inferiors target_stack automatically manages target 83314 reference counts, we might think that we don't need to unpush targets 83315 when an inferior is deleted... 83316 83317 ...unfortunately that is not the case. The inferior::unpush function 83318 can do some work depending on the type of target, so it is important 83319 that we still pass through this function. 83320 83321 To ensure that this is the case, in this commit I've added an assert 83322 to inferior::~inferior that ensures the inferior's target_stack is 83323 empty (except for the ever present dummy_target). 83324 83325 I've then added a pop_all_targets call to delete_inferior, otherwise 83326 the new assert will fire in, e.g. the gdb.python/py-inferior.exp test. 83327 833282022-12-14 Andrew Burgess <aburgess@redhat.com> 83329 83330 gdb: remove the pop_all_targets (and friends) global functions 83331 This commit removes the global functions pop_all_targets, 83332 pop_all_targets_above, and pop_all_targets_at_and_above, and makes 83333 them methods on the inferior class. 83334 83335 As the pop_all_targets functions will unpush each target, which 83336 decrements the targets reference count, it is possible that the target 83337 might be closed. 83338 83339 Right now, closing a target, in some cases, depends on the current 83340 inferior being set correctly, that is, to the inferior from which the 83341 target was popped. 83342 83343 To facilitate this I have used switch_to_inferior_no_thread within the 83344 new methods. Previously it was the responsibility of the caller to 83345 ensure that the correct inferior was selected. 83346 83347 In a couple of places (event-top.c and top.c) I have been able to 83348 remove a previous switch_to_inferior_no_thread call. 83349 83350 In remote_unpush_target (remote.c) I have left the 83351 switch_to_inferior_no_thread call as it is required for the 83352 generic_mourn_inferior call. 83353 833542022-12-14 Andrew Burgess <aburgess@redhat.com> 83355 83356 gdb: remove decref_target 83357 The decref_target function is not really needed. Calling 83358 target_ops::decref will just redirect to decref_target anyway, so why 83359 not just rename decref_target to target_ops::decref? 83360 83361 That's what this commit does. 83362 83363 It's not exactly renaming to target_ops::decref, because the decref 83364 functionality is handled by a policy class, so the new name is now 83365 target_ops_ref_policy::decref. 83366 83367 There should be no user visible change after this commit. 83368 833692022-12-14 Andrew Burgess <aburgess@redhat.com> 83370 83371 gdb: have target_stack automate reference count handling 83372 This commit changes the target_stack class from using a C style array 83373 of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The 83374 benefit of this change is that some of the reference counting of 83375 target_ops objects is now done automatically. 83376 83377 This commit fixes a crash in gdb.python/py-inferior.exp where GDB 83378 crashes at exit, leaving a core file behind. 83379 83380 The crash occurs in connpy_connection_dealloc, and is actually 83381 triggered by this assert: 83382 83383 gdb_assert (conn_obj->target == nullptr); 83384 83385 Now a little aside... 83386 83387 ... the assert is never actually printed, instead GDB crashes due 83388 to calling a pure virtual function. The backtrace at the point of 83389 crash looks like this: 83390 83391 #7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6 83392 #8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6 83393 #9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s> 83394 #10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.> 83395 #11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047 83396 #12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd> 83397 #13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112 83398 #14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li> 83399 83400 Notice in frame #12 we called target_ops::supports_terminal_ours, 83401 however, this is the_dummy_target, which is of type dummy_target, 83402 and so we should have called dummy_target::supports_terminal_ours. 83403 I believe the reason we ended up in the wrong implementation of 83404 supports_terminal_ours (which is a virtual function) is because we 83405 made the call during GDB's shut-down, and, I suspect, the vtables 83406 were in a weird state. 83407 83408 Anyway, the point of this patch is not to fix GDB's ability to 83409 print an assert during exit, but to address the root cause of the 83410 assert. With that aside out of the way, we can return to the main 83411 story... 83412 83413 Connections are represented in Python with gdb.TargetConnection 83414 objects (or its sub-classes). The assert in question confirms that 83415 when a gdb.TargetConnection is deallocated, the underlying GDB 83416 connection has itself been removed from GDB. If this is not true then 83417 we risk creating multiple different gdb.TargetConnection objects for 83418 the same connection, which would be bad. 83419 83420 To ensure that we have one gdb.TargetConnection object for each 83421 connection, the all_connection_objects map exists, this maps the 83422 process_stratum_target object (the connection) to the 83423 gdb.TargetConnection object that represents the connection. 83424 83425 When a connection is removed in GDB the connection_removed observer 83426 fires, which we catch with connpy_connection_removed, this function 83427 then sets conn_obj->target to nullptr, and removes the corresponding 83428 entry from the all_connection_objects map. 83429 83430 The first issue here is that connpy_connection_dealloc is being called 83431 as part of GDB's exit code, which is run after the Python interpreter 83432 has been shut down. The connpy_connection_dealloc function is used to 83433 deallocate the gdb.TargetConnection Python object. Surely it is 83434 wrong for us to be deallocating Python objects after the interpreter 83435 has been shut down. 83436 83437 The reason why connpy_connection_dealloc is called during GDB's exit 83438 is that the global all_connection_objects map is still holding a 83439 reference to the gdb.TargetConnection object. When the map is 83440 destroyed during GDB's exit, the gdb.TargetConnection objects within 83441 the map can finally be deallocated. 83442 83443 The reason why all_connection_objects has contents when GDB exits, and 83444 the reason the assert fires, is that, when GDB exits, there are still 83445 some connections that have not yet been removed from GDB, that is, 83446 they have a non-zero reference count. 83447 83448 If we take a look at quit_force (top.c) you can see that, for each 83449 inferior, we call pop_all_targets before we (later in the function) 83450 call do_final_cleanups. It is the do_final_cleanups call that is 83451 responsible for shutting down the Python interpreter. The 83452 pop_all_targets calls should, in theory, cause all the connections to 83453 be removed from GDB. 83454 83455 That this isn't working indicates that some targets have a non-zero 83456 reference count even after this final pop_all_targets call, and 83457 indeed, when I debug GDB, that is what I see. 83458 83459 I tracked the problem down to delete_inferior where we do some house 83460 keeping, and then delete the inferior object, which calls 83461 inferior::~inferior. 83462 83463 In neither delete_inferior or inferior::~inferior do we call 83464 pop_all_targets, and it is this missing call that means we leak some 83465 references to the target_ops objects on the inferior's target_stack. 83466 83467 In this commit I will provide a partial fix for the problem. I say 83468 partial fix, but this will actually be enough to resolve the crash. 83469 In a later commit I will provide the final part of the fix. 83470 83471 As mentioned at the start of the commit message, this commit changes 83472 the m_stack in target_stack to hold target_ops_ref objects. This 83473 means that when inferior::~inferior is called, and m_stack is 83474 released, we automatically decrement the target_ops reference count. 83475 With this change in place we no longer leak any references, and now, 83476 in quit_force the final pop_all_targets calls will release the final 83477 references. This means that the targets will be correctly closed at 83478 this point, which means the connections will be removed from GDB and 83479 the Python objects deallocated before the Python interpreter shuts 83480 down. 83481 83482 There's a slight oddity in target_stack::unpush, where we std::move 83483 the reference out of m_stack like this: 83484 83485 auto ref = std::move (m_stack[stratum]); 83486 83487 the `ref' isn't used explicitly, but it serves to hold the 83488 target_ops_ref until the end of the scope while allowing the m_stack 83489 entry to be reset back to nullptr. The alternative would be to 83490 directly set the m_stack entry to nullptr, like this: 83491 83492 m_stack[stratum] = nullptr; 83493 83494 The problem here is that when we set the m_stack entry to nullptr we 83495 first decrement the target_ops reference count, and then set the array 83496 entry to nullptr. 83497 83498 If the decrement means that the target_ops object reaches a zero 83499 reference count then the target_ops object will be closed by calling 83500 target_close. In target_close we ensure that the target being closed 83501 is not in any inferiors target_stack. 83502 83503 As we decrement before clearing, then this check in target_close will 83504 fail, and an assert will trigger. 83505 83506 By using std::move to move the reference out of m_stack, this clears 83507 the m_stack entry, meaning the inferior no longer contains the 83508 target_ops in its target_stack. Now when the REF object goes out of 83509 scope and the reference count is decremented, target_close can run 83510 successfully. 83511 83512 I've made use of the Python connection_removed listener API to add a 83513 test for this issue. The test installs a listener and then causes 83514 delete_inferior to be called, we can then see that the connection is 83515 then correctly removed (because the listener triggers). 83516 835172022-12-14 Andrew Burgess <aburgess@redhat.com> 83518 83519 gdb/remote: remove some manual reference count handling 83520 While working on some other target_ops reference count related code, I 83521 spotted that in remote.c we do some manual reference count handling, 83522 i.e. we call target_ops::incref and decref_target (which wraps 83523 target_ops::decref). 83524 83525 I think it would be better to make use of gdb::ref_ptr to automate the 83526 reference count management. 83527 83528 So, this commit updates scoped_mark_target_starting in two ways, 83529 first, I use gdb::ref_ptr to handle the reference counts. Then, 83530 instead of using the scoped_mark_target_starting constructor and 83531 destructor to set and reset the starting_up flag, I now use a 83532 scoped_restore_tmpl object to set and restore the flag. 83533 83534 The above changes mean that the scoped_mark_target_starting destructor 83535 can be completely removed, and the constructor body is now empty. 83536 83537 I've also fixed a typo in the class comment. 83538 83539 The only change in behaviour after this commit is that previously we 83540 didn't care what the value of starting_up was, we just set it to true 83541 in the constructor and false in the destructor. 83542 83543 Now, I assert that the flag is initially false, then set the flag true 83544 when the scoped_mark_target_starting is created. 83545 83546 As the starting_up flag is initialized to false then, for the assert 83547 to fire, we would need to recursively enter 83548 remote_target::start_remote_1, which I don't think is something we 83549 should be doing, so I think the new assert is an improvement. 83550 835512022-12-14 Alan Modra <amodra@gmail.com> 83552 83553 Re: ld, gold: remove support for -z bndplt (MPX prefix) 83554 Don't attempt to run gold tests with -z bndplt 83555 83556 * testsuite/Makefile.am (exception_x86_64_bnd_test, bnd_plt_1.sh), 83557 (bnd_ifunc_1.sh, bnd_ifunc_2.sh): Delete rules. 83558 * testsuite/Makefile.in: Regenerate. 83559 * testsuite/bnd_ifunc_1.s: Delete. 83560 * testsuite/bnd_ifunc_1.sh: Delete. 83561 * testsuite/bnd_ifunc_2.s: Delete. 83562 * testsuite/bnd_ifunc_2.sh: Delete. 83563 * testsuite/bnd_plt_1.s: Delete. 83564 * testsuite/bnd_plt_1.sh: Delete. 83565 835662022-12-14 Alan Modra <amodra@gmail.com> 83567 83568 asan: buffer overflow in sh_reloc 83569 * coff-sh.c (sh_reloc): Use bfd_reloc_offset_in_range. 83570 835712022-12-14 Alan Modra <amodra@gmail.com> 83572 83573 Fix haiku ld dependencies 83574 I noticed after commit 8ad93045ed, "ld, gold: remove support for -z 83575 bndplt (MPX prefix)", that some of my builds were failing with 83576 83577 eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params' 83578 params.bndplt = true; 83579 ~~~~~~ ^ 83580 83581 * emulparams/aarch64haiku.sh: Use "source_sh" rather than ".". 83582 * emulparams/armelf_haiku.sh: Likewise. 83583 * emulparams/elf32ppchaiku.sh: Likewise. 83584 * emulparams/elf_mipsel_haiku.sh: Likewise. 83585 * emulparams/elf_x86_64_haiku.sh: Likewise. 83586 835872022-12-14 Andrew Burgess <aburgess@redhat.com> 83588 83589 gdb: add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT 83590 After the previous commit converted symbol-lookup debug to use the new 83591 debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT. 83592 83593 The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT 83594 because symbol-lookup debug is controlled by an 'unsigned int' rather 83595 than a 'bool' control variable, we use the numeric value to offer 83596 different levels of verbosity for symbol-lookup debug. 83597 83598 The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing 83599 a reference to the bool control variable, and evaluating the variable 83600 both on entry, and at exit, this is done in the scoped_debug_start_end 83601 class (see gdbsupport/common-debug.h). 83602 83603 This commit templates scoped_debug_start_end so that the class can 83604 accept either a 'bool &' or an invokable object, e.g. a lambda 83605 function, or a function pointer. 83606 83607 The existing scoped_debug_start_end and scoped_debug_enter_exit macros 83608 in common-debug.h are updated to support scoped_debug_enter_exit being 83609 templated, however, nothing outside of common-debug.h needs to change. 83610 83611 I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and 83612 added a couple of token uses in symtab.c. I didn't want to add too 83613 much in this first commit, this is really about updating 83614 common-debug.h to support this new functionality. 83615 83616 Within symtab.h I created a couple of global functions that can be 83617 used to query the status of the symbol_lookup_debug control variable, 83618 these functions are then used within the two existing macros: 83619 83620 symbol_lookup_debug_printf 83621 symbol_lookup_debug_printf_v 83622 83623 and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro. 83624 836252022-12-14 Andrew Burgess <aburgess@redhat.com> 83626 83627 gdb: convert 'set debug symbol-lookup' to new debug printing scheme 83628 Convert the implementation of 'set debug symbol-lookup' to the new 83629 debug printing scheme. 83630 83631 In a few places I've updated the debug output to remove places where 83632 the printed debug message included the function name, the new debug 83633 scheme already adds that, but I haven't done all the possible updates. 83634 836352022-12-14 Andrew Burgess <aburgess@redhat.com> 83636 83637 gdb/testsuite: new test for recent dwarf reader issue 83638 This commit provides a test for this commit: 83639 83640 commit 55fc1623f942fba10362cb199f9356d75ca5835b 83641 Date: Thu Nov 3 13:49:17 2022 -0600 83642 83643 Add name canonicalization for C 83644 83645 Which resolves PR gdb/29105. My reason for writing this test was a 83646 desire to better understand the above commit, my process was to study 83647 the commit until I thought I understood it, then write a test to 83648 expose the issue. As the original commit didn't have a test, I 83649 thought it wouldn't hurt to commit this upstream. 83650 83651 The problem tested for here is already described in the above commit, 83652 but I'll give a brief description here. This description describes 83653 GDB prior to the above commit: 83654 83655 - Builtin types are added to GDB using their canonical name, 83656 e.g. "short", not "signed short", 83657 83658 - When the user does something like 'p sizeof(short)', then this is 83659 handled in c-exp.y, and results in a call to lookup_signed_type 83660 for the name "int". The "int" here is actually being looked up as 83661 the type for the result of the 'sizeof' expression, 83662 83663 - In lookup_signed_type GDB first adds a 'signed' and looks for that 83664 type, so in this case 'signed int', and, if that lookup fails, GDB 83665 then looks up 'int', 83666 83667 - The problem is that 'signed int' is not the canonical name for a 83668 signed int, so no builtin type with that name will be found, GDB 83669 will then go to each object file in turn looking for a matching 83670 type, 83671 83672 - When checking each object file, GDB will first check the partial 83673 symtab to see if the full symtab should be expanded or not. 83674 Remember, at this point GDB is looking for 'signed int', there 83675 will be no partial symbols with that name, so GDB will not expand 83676 anything, 83677 83678 - However, GDB checks each partial symbol using multiple languages, 83679 not just the current language (C in this case), so, when GDB 83680 checks using the C++ language, the symbol name is first 83681 canonicalized (the code that does this can be found 83682 lookup_name_info::language_lookup_name). As the canonical form of 83683 'signed int' is just 'int', GDB then looks for any symbols with 83684 the name 'int', most partial symtabs will contain such a symbol, 83685 so GDB ends up expanding pretty much every symtab. 83686 83687 The above commit fixes this by avoiding the use of non-canonical names 83688 with C, now the initial builtin type lookup will succeed, and GDB 83689 never even considers whether to expand any additional symtabs. 83690 83691 The test case creates a library that includes char, short, int, and 83692 long types, and a test program that links against the library. 83693 83694 In the test script we start the inferior, but don't allow it to 83695 progress far enough that the debug information for the library has 83696 been fully expanded yet. 83697 83698 Then we evaluate some 'sizeof(TYPE)' expressions. 83699 83700 In the buggy version of GDB this would cause the debug information 83701 for the library to be fully expanded, while in the fixed version of 83702 GDB this will not be the case. 83703 83704 We use 'info sources' to determine if the debug information has been 83705 fully expanded or not. 83706 83707 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 83708 837092022-12-14 Andrew Burgess <aburgess@redhat.com> 83710 83711 gdb/testsuite: fix readnow detection 83712 The following commit broke the readnow detection in the testsuite: 83713 83714 commit dfaa040b440084dd73ebd359326752d5f44fc02c 83715 Date: Mon Mar 29 18:31:31 2021 -0600 83716 83717 Remove some "OBJF_READNOW" code from dwarf2_debug_names_index 83718 83719 The testsuite checks if GDB was started with the -readnow flag by 83720 using the 'maintenance print objfiles' command, and looking for the 83721 string 'faked for "readnow"' in the output. This is implemented in 83722 two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp). 83723 83724 The following tests all currently depend on this detection: 83725 83726 gdb.base/maint.exp 83727 gdb.cp/nsalias.exp 83728 gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp 83729 gdb.dwarf2/dw2-stack-boundary.exp 83730 gdb.dwarf2/dw2-zero-range.exp 83731 gdb.dwarf2/gdb-index-nodebug.exp 83732 gdb.mi/mi-info-sources.exp 83733 gdb.python/py-symbol.exp 83734 gdb.rust/traits.exp 83735 83736 The following test also includes detection of 'readnow', but does the 83737 detection itself by checking $::GDBFLAGS for the readnow flag: 83738 83739 gdb.opt/break-on-_exit.exp 83740 83741 The above commit removed from GDB the code that produced the 'faked 83742 for "readnow"' string, as a consequence the testsuite can no longer 83743 correctly spot when readnow is in use, and many of the above tests 83744 will fail (at least partially). 83745 83746 When looking at the above tests, I noticed that gdb.rust/traits.exp 83747 does call `readnow`, but doesn't actually use the result, so I've 83748 removed the readnow call, this simplifies the next part of this patch 83749 as gdb.rust/traits.exp was the only place an extra regexp was passed 83750 to the readnow call. 83751 83752 Next I have rewritten `readnow` to check the $GDBFLAGS for the 83753 -readnow flag, and removed the `maintenance print objfiles` check. At 83754 least for all the tests above, when using the readnow board, this is 83755 good enough to get everything passing again. 83756 83757 For the `mi_readnow` proc, I changed this to just call `readnow` from 83758 gdb.exp, I left the mi_readnow name in place - in the future it might 83759 be the case that we want to do some different checks here. 83760 83761 Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow` 83762 proc. 83763 83764 With these changes, all of the tests listed above now pass correctly 83765 when using the readnow board. 83766 837672022-12-14 Li Xu <xuli1@eswincomputing.com> 83768 83769 RISC-V: Add string length check for operands in AS 83770 The current AS accepts invalid operands due to miss of operands length check. 83771 For example, "e6" is an invalid operand in (vsetvli a0, a1, e6, mf8, tu, ma), 83772 but it's still accepted by assembler. In detail, the condition check "strncmp 83773 (array[i], *s, len) == 0" in arg_lookup function passes with "strncmp ("e64", 83774 "e6", 2)" in the case above. So the generated encoding is same as that of 83775 (vsetvli a0, a1, e64, mf8, tu, ma). 83776 83777 This patch fixes issue above by prompting an error in such case and also adds 83778 a new testcase. 83779 83780 gas/ChangeLog: 83781 83782 * config/tc-riscv.c (arg_lookup): Add string length check for operands. 83783 * testsuite/gas/riscv/vector-insns-fail-vsew.d: New testcase for an illegal vsew. 83784 * testsuite/gas/riscv/vector-insns-fail-vsew.l: Likewise. 83785 * testsuite/gas/riscv/vector-insns-fail-vsew.s: Likewise. 83786 837872022-12-14 Jan Beulich <jbeulich@suse.com> 83788 83789 x86: adjust type checking constructs 83790 As Alan points out, ASAN takes issue with these constructs, for 83791 current_templates being NULL. Wrap them in sizeof(), so the expressions 83792 aren't actually evaluated. 83793 837942022-12-14 Martin Liska <mliska@suse.cz> 83795 83796 ld, gold: remove support for -z bndplt (MPX prefix) 83797 bfd/ChangeLog: 83798 83799 * elf-linker-x86.h (struct elf_linker_x86_params): Remove 83800 bndplt. 83801 * elf64-x86-64.c (elf_x86_64_scan_relocs): Ignore 83802 R_X86_64_PLT32_BND. 83803 (elf_x86_64_relocate_section): Similarly here. 83804 (elf_x86_64_link_setup_gnu_properties): Ignore bndplt. 83805 * elfxx-x86.c: Likewise. 83806 * elfxx-x86.h: Likewise. 83807 83808 gold/ChangeLog: 83809 83810 * NEWS: Document -z bndplt. 83811 * options.h (class General_options): Remove bndplt option. 83812 * x86_64.cc (class Output_data_plt_x86_64_bnd): Remove. 83813 (Target_x86_64::do_make_data_plt): Do not use 83814 Output_data_plt_x86_64_bnd. 83815 (Target_x86_64::Scan::get_reference_flags): Likewise. 83816 (Target_x86_64::Scan::check_non_pic): Likewise. 83817 (Target_x86_64::Scan::local): Likewise. 83818 (Target_x86_64::Scan::global): Likewise. 83819 83820 ld/ChangeLog: 83821 83822 * NEWS: Document -z bndplt. 83823 * emulparams/elf_x86_64.sh: Remove bndplt option. 83824 * ld.texi: Likewise. 83825 * testsuite/ld-x86-64/x86-64.exp: 83826 * testsuite/ld-x86-64/bnd-branch-1-now.d: Removed. 83827 * testsuite/ld-x86-64/bnd-branch-1.d: Removed. 83828 * testsuite/ld-x86-64/bnd-branch-1.s: Removed. 83829 * testsuite/ld-x86-64/bnd-ifunc-1-now.d: Removed. 83830 * testsuite/ld-x86-64/bnd-ifunc-1.d: Removed. 83831 * testsuite/ld-x86-64/bnd-ifunc-1.s: Removed. 83832 * testsuite/ld-x86-64/bnd-ifunc-2-now.d: Removed. 83833 * testsuite/ld-x86-64/bnd-ifunc-2.d: Removed. 83834 * testsuite/ld-x86-64/bnd-ifunc-2.s: Removed. 83835 * testsuite/ld-x86-64/bnd-plt-1-now.d: Removed. 83836 * testsuite/ld-x86-64/bnd-plt-1.d: Removed. 83837 * testsuite/ld-x86-64/mpx.exp: Removed. 83838 * testsuite/ld-x86-64/mpx1.out: Removed. 83839 * testsuite/ld-x86-64/mpx1a.c: Removed. 83840 * testsuite/ld-x86-64/mpx1a.rd: Removed. 83841 * testsuite/ld-x86-64/mpx1b.c: Removed. 83842 * testsuite/ld-x86-64/mpx1c.c: Removed. 83843 * testsuite/ld-x86-64/mpx1c.rd: Removed. 83844 * testsuite/ld-x86-64/mpx2.out: Removed. 83845 * testsuite/ld-x86-64/mpx2a.c: Removed. 83846 * testsuite/ld-x86-64/mpx2a.rd: Removed. 83847 * testsuite/ld-x86-64/mpx2b.c: Removed. 83848 * testsuite/ld-x86-64/mpx2c.c: Removed. 83849 * testsuite/ld-x86-64/mpx2c.rd: Removed. 83850 * testsuite/ld-x86-64/mpx3.dd: Removed. 83851 * testsuite/ld-x86-64/mpx3a.s: Removed. 83852 * testsuite/ld-x86-64/mpx3b.s: Removed. 83853 * testsuite/ld-x86-64/mpx3n.dd: Removed. 83854 * testsuite/ld-x86-64/mpx4.dd: Removed. 83855 * testsuite/ld-x86-64/mpx4a.s: Removed. 83856 * testsuite/ld-x86-64/mpx4b.s: Removed. 83857 * testsuite/ld-x86-64/mpx4n.dd: Removed. 83858 * testsuite/ld-x86-64/pr20800a.S: Removed. 83859 * testsuite/ld-x86-64/pr20800b.S: Removed. 83860 * testsuite/ld-x86-64/pr21038a-now.d: Removed. 83861 * testsuite/ld-x86-64/pr21038a.d: Removed. 83862 * testsuite/ld-x86-64/pr21038a.s: Removed. 83863 * testsuite/ld-x86-64/pr21038b-now.d: Removed. 83864 * testsuite/ld-x86-64/pr21038b.d: Removed. 83865 * testsuite/ld-x86-64/pr21038b.s: Removed. 83866 * testsuite/ld-x86-64/pr21038c-now.d: Removed. 83867 * testsuite/ld-x86-64/pr21038c.d: Removed. 83868 * testsuite/ld-x86-64/pr21038c.s: Removed. 83869 838702022-12-14 Alan Modra <amodra@gmail.com> 83871 83872 asan: signed integer overflow in display_debug_frames 83873 * dwarf.c (struct Frame_Chunk): Make col_offset an int64_t. 83874 Adjust all places allocating col_offset and col_type to use 83875 the size of the array element rather than the size of a type. 83876 (frame_display_row): Adjust printing of col_offset. 83877 (display_debug_frames): Factor out multiplication by 83878 code_factor and data_factor. Avoid signed overflow. Use 83879 64-bit variables. 83880 838812022-12-14 Alan Modra <amodra@gmail.com> 83882 83883 Don't access freed memory printing objcopy warning 83884 abfd->filename will be freed if bfd_close gets far enough to delete 83885 the bfd. It's possible to have an error from fclose at this point. 83886 83887 * objcopy.c (copy_archive): Dup filename before closing bfd for 83888 potential use in bfd_nonfatal_message. 83889 838902022-12-14 GDB Administrator <gdbadmin@sourceware.org> 83891 83892 Automatic date update in version.in 83893 838942022-12-13 Tom Tromey <tromey@adacore.com> 83895 83896 Fix control-c handling on Windows 83897 As Hannes pointed out, the Windows target-async patches broke C-c 83898 handling there. Looking into this, I found a few oddities, fixed 83899 here. 83900 83901 First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent. 83902 I think this event can be ignored by the inferior, so it's not a great 83903 way to interrupt. Instead, using DebugBreakProcess (or a more 83904 complicated thing for Wow64) seems better. 83905 83906 Second, windows_nat_target did not implement the pass_ctrlc method. 83907 Implementing this lets us remove the special code to call 83908 SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c 83909 handling. I believe that this should also fix the race that's 83910 described in the comment that's being removed. 83911 83912 Initially, I thought a simpler version of this patch would work. 83913 However, I think what happens is that some other library (I'm not sure 83914 what) calls SetConsoleCtrlHandler while gdb is running, and this 83915 intercepts and handles C-c -- so that the gdb SIGINT handler is not 83916 called. C-break continues to work, presumably because whatever 83917 handler is installed ignores it. 83918 83919 This patch works around this issue by ensuring that the gdb handler 83920 always comes first. 83921 839222022-12-13 Tom Tromey <tromey@adacore.com> 83923 83924 Refactor code to check for terminal sharing 83925 This refactors the code to check for terminal sharing. 83926 is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed, 83927 slightly refactored, and moved to posix-hdep.c. A new 83928 Windows-specific implementation of this function is added to 83929 mingw-hdep.c. 83930 83931 MSDN has a warning about GetConsoleProcessList 83932 83933 This API is not recommended and does not have a virtual terminal 83934 equivalent. [...] Applications remoting via cross-platform 83935 utilities and transports like SSH may not work as expected if 83936 using this API. 83937 83938 However, we believe this isn't likely to be an issue for gdb. 83939 839402022-12-13 Tom Tromey <tromey@adacore.com> 83941 83942 Use gdb::optional for sigint_ours 83943 sigint_ours (and sigquit_ours) can be used without being set. Avoid 83944 this problem by changing them to gdb::optional and checking that they 83945 are in fact set before using the value. 83946 83947 Rename install_sigint_handler 83948 A subsequent patch will introduce a global 'install_sigint_handler' 83949 function, so first rename the static one in extension.c. 83950 839512022-12-13 Tom de Vries <tdevries@suse.de> 83952 83953 [gdb/tdep] Fix s390_linux_nat_target::stopped_by_watchpoint 83954 On s390x-linux, I run into: 83955 ... 83956 (gdb) continue^M 83957 Continuing.^M 83958 breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \ 83959 Assertion `!target_stopped_by_watchpoint ()' failed.^M 83960 A problem internal to GDB has been detected,^M 83961 further debugging may prove unreliable.^M 83962 FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \ 83963 breakpoint after the first fork (GDB internal error) 83964 ... 83965 83966 What happens is the follow: 83967 - a watchpoint event triggers 83968 - the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and 83969 it returns true, as expected 83970 - the watchpoint event is reported by gdb, and gdb stops 83971 - we issue a continue command 83972 - a fork event triggers 83973 - the event is processed, and during processing that event 83974 s390_linux_nat_target::stopped_by_watchpoint is called again, and returns 83975 true 83976 - the assertion fails, because the function is expected to return false 83977 83978 The function s390_linux_nat_target::stopped_by_watchpoint returns true the 83979 second time, because it looks at the exact same data that was looked at when 83980 it was called the first time, and that data hasn't changed. 83981 83982 There's code in the same function that intends to prevent that from happening: 83983 ... 83984 /* Do not report this watchpoint again. */ 83985 memset (&per_lowcore, 0, sizeof (per_lowcore)); 83986 if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0) 83987 perror_with_name (_("Couldn't clear watchpoint status")); 83988 ... 83989 and that probably used to work for older kernels, but no longer does since 83990 linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup"). 83991 83992 Fix this by copying this: 83993 ... 83994 siginfo_t siginfo; 83995 if (!linux_nat_get_siginfo (inferior_ptid, &siginfo)) 83996 return false; 83997 if (siginfo.si_signo != SIGTRAP 83998 || (siginfo.si_code & 0xffff) != TRAP_HWBKPT) 83999 return false; 84000 ... 84001 from aarch64_linux_nat_target::stopped_data_address and remove the 84002 obsolete watchpoint status clearing code. 84003 84004 Tested on s390x-linux. 84005 84006 Approved-By: Ulrich Weigand <uweigand@de.ibm.com> 84007 840082022-12-13 H.J. Lu <hjl.tools@gmail.com> 84009 84010 gold: Remove BND from 64-bit x86-64 IBT PLT 84011 Since MPX support has been removed from x86-64 psABI, remove BND from 84012 64-bit IBT PLT by using 32-bit IBT PLT. 84013 84014 PR gold/29851 84015 * x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry): 84016 Renamed to ... 84017 (Output_data_plt_x86_64_ibt<size>::first_plt_entry): This. 84018 (Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed. 84019 (Output_data_plt_x86_64_ibt<size>::do_fill_first_plt_entry): 84020 Drop the size == 32 check. 84021 (Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ... 84022 (Output_data_plt_x86_64_ibt<size>::plt_entry): This. 84023 (Output_data_plt_x86_64_ibt<64>::plt_entry): Removed. 84024 (Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ... 84025 (Output_data_plt_x86_64_ibt<size>::aplt_entry): This. 84026 (Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed. 84027 (Output_data_plt_x86_64_ibt<size>::do_fill_plt_entry): Drop the 84028 size == 32 check. 84029 (Output_data_plt_x86_64_ibt<size>::fill_aplt_entry): Likewise. 84030 840312022-12-13 Tom Tromey <tromey@adacore.com> 84032 84033 Remove two unnecessary casts 84034 A couple of calls to parse_probe_linespec had an unnecessary cast. I 84035 suspect this cast was never needed, but once commands were changed to 84036 take a 'const' argument, they became completely obsolete. Tested by 84037 rebuilding. 84038 840392022-12-13 Andrew Burgess <aburgess@redhat.com> 84040 84041 gdb/testsuite: avoid creating temp file in gdb/testsuite/ directory 84042 After this commit: 84043 84044 commit 33c1395cf5e9deec7733691ba32c450e5c27f757 84045 Date: Fri Nov 11 15:26:46 2022 +0000 84046 84047 gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang 84048 84049 The gdb.trace/unavailable-dwarf-piece.exp test script was creating a 84050 temporary file in the build/gdb/testsuite/ directory, instead of in 84051 the expected place in the outputs directory. 84052 84053 Fix this by adding a call to standard_output_file. 84054 840552022-12-13 Tom de Vries <tdevries@suse.de> 84056 84057 [gdb/testsuite] Fix gdb.python/py-disasm.exp on s390x 84058 On s390x-linux, I run into: 84059 ... 84060 (gdb) disassemble test^M 84061 Dump of assembler code for function test:^M 84062 0x0000000001000638 <+0>: stg %r11,88(%r15)^M 84063 0x000000000100063e <+6>: lgr %r11,%r15^M 84064 0x0000000001000642 <+10>: nop 0^M 84065 => 0x0000000001000646 <+14>: nop 0^M 84066 0x000000000100064a <+18>: nop 0^M 84067 0x000000000100064e <+22>: lhi %r1,0^M 84068 0x0000000001000652 <+26>: lgfr %r1,%r1^M 84069 0x0000000001000656 <+30>: lgr %r2,%r1^M 84070 0x000000000100065a <+34>: lg %r11,88(%r11)^M 84071 0x0000000001000660 <+40>: br %r14^M 84072 End of assembler dump.^M 84073 (gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test 84074 ... 84075 84076 The problem is that the test-case expects "nop" but on s390x we have instead 84077 "nop\t0". 84078 84079 Fix this by allowing the insn. 84080 84081 Tested on s390x-linux and x86_64-linux. 84082 840832022-12-13 Jan Beulich <jbeulich@suse.com> 84084 84085 gas: re-work line number tracking for macros and their expansions 84086 The PR gas/16908 workaround aimed at uniformly reporting line numbers 84087 to reference macro invocation sites. As mentioned in a comment this may 84088 be desirable for small macros, but often isn't for larger ones. As a 84089 first step improve diagnostics to report both locations, while aiming at 84090 leaving generated debug info unaltered. 84091 84092 Note that macro invocation context is lost for any diagnostics issued 84093 only after all input was processed (or more generally for any use of 84094 as_*_where(), as the functions can't know whether the passed in location 84095 is related to [part of] the present stack of locations). To maintain the 84096 intended workaround behavior for PR gas/16908, a new as_where() is 84097 introduced to "look through" macro invocations, while the existing 84098 as_where() is renamed (and used in only very few places for now). Down 84099 the road as_where() will likely want to return a list of (file,line) 84100 pairs. 84101 841022022-12-13 Jan Beulich <jbeulich@suse.com> 84103 84104 Arm: avoid unhelpful uses of .macro in testsuite 84105 Macros with just a single use site are a little pointless to have, and 84106 even in further cases .irp is more suitable for the purpose. Expand such 84107 inline, avoiding the need to touch the testcases when diagnostics are 84108 changed for code resulting from macro expansion. 84109 84110 While there also make what was "iter_mla" in sp-usage-thumb2-relax cover 84111 smlatt as well, rather than testing smlabt twice. 84112 841132022-12-13 Tom Tromey <tom@tromey.com> 84114 84115 Fix crash in is_nocall_function 84116 is_nocall_function anticipates only being called for a function or a 84117 method. However, PR gdb/29871 points out a situation where an unusual 84118 expression -- but one that parses to a valid, if extremely weird, 84119 function call -- breaks this assumption. 84120 84121 This patch changes is_nocall_function to remove this assert and 84122 instead simply return 'false' in this case. 84123 84124 Approved-By: Simon Marchi <simon.marchi@efficios.com> 84125 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871 84126 841272022-12-13 Johnson Sun <j3.soon777@gmail.com> 84128 84129 Replace gdbpy_should_stop with gdbpy_breakpoint_cond_says_stop 84130 In 2014, the function `gdbpy_should_stop' has been replaced with 84131 `gdbpy_breakpoint_cond_says_stop' 84132 84133 This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the 84134 comments. 84135 84136 Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014': 84137 84138 * python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed 84139 from gdbpy_should_stop. Change result type to enum scr_bp_stop. 84140 84141 Change-Id: I0ef3491ce5e057c5e75ef8b569803b30a5838575 84142 Approved-By: Simon Marchi <simon.marchi@efficios.com> 84143 841442022-12-13 Alan Modra <amodra@gmail.com> 84145 84146 asan: mips_hi16_list segfault in bfd_get_section_limit_octets 84147 static variables like mips_hi16_list are nasty for applications using 84148 bfd. It is possible when opening and closing bfds with mis-matched 84149 hi/lo relocs to leave a stale section pointer on the list. That can 84150 cause a segfault if multiple bfds are being processed. 84151 84152 Tidying the list when closing is sufficient to stop this happening 84153 (and fixes small memory leaks). This patch goes further and moves 84154 mips_hi16_list to where it belongs in the bfd tdata. 84155 84156 * elf32-mips.c (bfd_elf32_close_and_cleanup(: Define. 84157 * elf64-mips.c (bfd_elf64_close_and_cleanup): Define. 84158 * elfn32-mips.c (bfd_elf32_close_and_cleanup(: Define. 84159 * elfxx-mips.c (struct mips_hi16): Move earlier. 84160 (mips_hi16_list): Move to.. 84161 (struct mips_elf_obj_tdata): ..here. 84162 (_bfd_mips_elf_close_and_cleanup): New function. 84163 (_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc), 84164 (_bfd_elf_mips_get_relocated_section_contents): Adjust uses of 84165 mips_hi16_list. 84166 * elfxx-mips.h (_bfd_mips_elf_close_and_cleanup): Declare. 84167 841682022-12-13 GDB Administrator <gdbadmin@sourceware.org> 84169 84170 Automatic date update in version.in 84171 841722022-12-12 Indu Bhagat <indu.bhagat@oracle.com> 84173 84174 libctf: remove unnecessary zstd constructs 84175 This patch is essentially a revert of 84176 commit-id: 8818c80cbd4116ef5af171ec47c61167179e225c 84177 (libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true) 84178 84179 As the specific configure check now uses libtool, this explicit mention of the 84180 dependency $ZSTD_LIBS is not needed anymore. 84181 84182 ChangeLog: 84183 84184 * libctf/Makefile.in: Regenerated. 84185 * libctf/aclocal.m4: Likewise. 84186 * libctf/config.h.in: Likewise. 84187 * libctf/configure: Likewise. 84188 * libctf/configure.ac: Remove ZSTD_LIBS from LIBS. Cleanup 84189 unused AC_ZSTD. 84190 841912022-12-12 Indu Bhagat <indu.bhagat@oracle.com> 84192 84193 libctf: remove AC_CONFIG_MACRO_DIR 84194 ACLOCAL_AMFLAGS is being set already. So using AC_CONFIG_MACRO_DIR is 84195 unnecessary. 84196 84197 ChangeLog: 84198 84199 * libctf/configure: Regenerated. 84200 * libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage. 84201 842022022-12-12 Indu Bhagat <indu.bhagat@oracle.com> 84203 84204 libctf: remove unnecessary zlib constructs 84205 This dependency is managed via libtool. So explicit addition to LDFLAGS 84206 and LIBS is not necessary anymore. 84207 84208 ChangeLog: 84209 84210 * libctf/configure: Regenerated. 84211 * libctf/configure.ac: remove zlib from LDFLAGS and LIBS. 84212 842132022-12-12 Tom de Vries <tdevries@suse.de> 84214 84215 [gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp 84216 On s390x-linux, I run into: 84217 ... 84218 (gdb) print {unsigned char}{65}^M 84219 $749 = 0 '\000'^M 84220 (gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65} 84221 ... 84222 84223 In contrast, on x86_64-linux, we have: 84224 ... 84225 (gdb) print {unsigned char}{65}^M 84226 $749 = 65 'A'^M 84227 (gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65} 84228 ... 84229 84230 The first problem here is that the test is supposed to be a regression test 84231 for PR20630, which can be reproduced (for an unfixed gdb) like this: 84232 ... 84233 (gdb) p {unsigned char[]}{0x17} 84234 gdbtypes.c:4641: internal-error: copy_type: \ 84235 Assertion `TYPE_OBJFILE_OWNED (type)' failed. 84236 ... 84237 but it's not due to insufficient quoting (note the dropped '[]'). 84238 84239 That's easy to fix, but after that we have on s390 (big endian): 84240 ... 84241 (gdb) print {unsigned char[]}{65}^M 84242 $749 = ""^M 84243 ... 84244 and on x86_64 (little endian): 84245 ... 84246 (gdb) print {unsigned char[]}{65}^M 84247 $749 = "A"^M 84248 ... 84249 84250 Fix this by using 0xffffffff, such that in both cases we have: 84251 ... 84252 (gdb) print {unsigned char[]}{0xffffffff}^M 84253 $749 = "\377\377\377\377"^M 84254 ... 84255 84256 Tested on x86_64-linux and s390x-linux. 84257 842582022-12-12 Alan Modra <amodra@gmail.com> 84259 84260 PR29893, buffer overflow in display_debug_addr 84261 PR 29893 84262 * dwarf.c (display_debug_addr): Sanity check dwarf5 unit_length 84263 field. Don't read past end. 84264 842652022-12-12 Tom Tromey <tom@tromey.com> 84266 84267 Another Rust operator precedence bug 84268 My earlier patch to fix PR rust/29859 introduced a new operator 84269 precedence bug in the Rust parser. Assignment operators are 84270 right-associative in Rust. And, while this doesn't often matter, as 84271 Rust assignments always have the value (), still as a matter of 84272 principle we should get this correct. 84273 84274 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859 84275 842762022-12-12 Tom de Vries <tdevries@suse.de> 84277 84278 [gdb/testsuite] Fix gdb.base/write_mem.exp for big endian 84279 On s390x-linux (big endian), I run into: 84280 ... 84281 (gdb) x /xh main^M 84282 0x1000638 <main>: 0x0000^M 84283 (gdb) FAIL: gdb.base/write_mem.exp: x /xh main 84284 ... 84285 84286 In contrast, on x86_64-linux (little endian), we have the expected: 84287 ... 84288 (gdb) x /xh main^M 84289 0x4004a7 <main>: 0x4242^M 84290 (gdb) PASS: gdb.base/write_mem.exp: x /xh main 84291 ... 84292 84293 The problem is that the test-case hard-codes expectations about endiannes by 84294 writing an int-sized value (4 bytes in this case) and then printing only a 84295 halfword by using "/h" (so, two bytes). 84296 84297 If we print 4 bytes, we have for s390x: 84298 ... 84299 0x1000638 <main>: 0x00004242^M 84300 ... 84301 and for x86_64: 84302 ... 84303 0x4004a7 <main>: 0x00004242^M 84304 ... 84305 84306 Fix this by removing the "/h". 84307 84308 Tested on x86_64-linux and s390x-linux. 84309 843102022-12-12 Jan Vrany <jan.vrany@labware.com> 84311 84312 gdb: fix possible use-after-free when executing commands 84313 In principle, `execute_command()` does following: 84314 84315 struct cmd_list_element *c; 84316 c = lookup_cmd ( ... ); 84317 ... 84318 /* If this command has been pre-hooked, run the hook first. */ 84319 execute_cmd_pre_hook (c); 84320 ... 84321 /* ...execute the command `c` ...*/ 84322 ... 84323 execute_cmd_post_hook (c); 84324 84325 This may lead into use-after-free error. Imagine the command 84326 being executed is a user-defined Python command that redefines 84327 itself. In that case, struct `cmd_list_element` pointed to by 84328 `c` is deallocated during its execution so it is no longer valid 84329 when post hook is executed. 84330 84331 To fix this case, this commit looks up the command once again 84332 after it is executed to get pointer to (possibly newly allocated) 84333 `cmd_list_element`. 84334 843352022-12-12 Jan Beulich <jbeulich@suse.com> 84336 84337 x86: further re-work insn/suffix recognition to also cover MOVSX 84338 PR gas/29524 84339 84340 Having templates with a suffix explicitly present has always been 84341 quirky. After prior adjustment all that's left to also eliminate the 84342 anomaly from move-with-sign-extend is to consolidate the insn templates 84343 and to make may_need_pass2() cope (plus extend testsuite coverage). 84344 843452022-12-12 Jan Beulich <jbeulich@suse.com> 84346 84347 x86: drop (now) stray IsString 84348 The need for them on the operand-less string insns has gone away with 84349 the removal of maybe_adjust_templates() and associated logic. Since 84350 i386_index_check() needs adjustment then anyway, take the opportunity 84351 and also simplify it, possible again as a result of said removal (plus 84352 the opcode template adjustments done here). 84353 843542022-12-12 Jan Beulich <jbeulich@suse.com> 84355 84356 x86: move bad-use-of-TLS-reloc check 84357 Having it in match_template() is unhelpful. Neither does looking for the 84358 next template to possibly match make any sense in that case, nor is the 84359 resulting diagnostic making clear what the problem is. 84360 84361 While moving the check, also generalize it to include all SIMD and VEX- 84362 encoded insns. This way an existing conditional can be re-used in 84363 md_assemble(). Note though that this still leaves a lof of insns which 84364 are also wrong to use with these relocations. 84365 84366 Further fold the remaining check (BFD_RELOC_386_GOT32) with the XRELEASE 84367 related one a few lines down. This again allows re-using an existing 84368 conditional. 84369 843702022-12-12 Jan Beulich <jbeulich@suse.com> 84371 84372 x86-64: allow HLE store of accumulator to absolute 32-bit address 84373 In commit 1212781b35c9 ("ix86: allow HLE store of accumulator to 84374 absolute address") I was wrong to exclude 64-bit code. Dropping the 84375 check also leads to better diagnostics in 64-bit code ("MOV", after 84376 all, isn't invalid with "XRELEASE"). 84377 84378 While there also limit the amount of further checks done: The operand 84379 type checks that were there were effectively redundant with other ones 84380 anyway, plus it's quite fine to also have "xrelease mov <disp>, %eax" 84381 look for the next MOV template (in fact again also improving 84382 diagnostics). 84383 843842022-12-12 Jan Beulich <jbeulich@suse.com> 84385 84386 ix86: don't recognize/derive Q suffix in the common case 84387 Have its use, except where actually legitimate, result in the same "only 84388 supported in 64-bit mode" diagnostic as emitted for other 64-bit only 84389 insns. Also suppress deriving of the suffix in Intel mode except in the 84390 legitimate cases. This in exchange allows dropping the respective code 84391 from match_template(). 84392 84393 To maintain reasonable diagnostics (in particular to avoid "`mov' is 84394 only supported in 64-bit mode" on the SIMD forms of MOVQ) we need to 84395 defer parse_insn()'s emitting of errors unrelated to prefix parsing. 84396 Utilize i.error just like match_template() does. 84397 84398 Oddly enough despite gcc's preference towards FILDQ and FIST{,T}Q we 84399 had no testcase whatsoever for these. Therefore such tests are being 84400 added. Note that the removed line in the x86-64-lfence-load testcase 84401 was redundant with the exact same one a few lines up. 84402 844032022-12-12 Jan Beulich <jbeulich@suse.com> 84404 84405 x86: re-work insn/suffix recognition 84406 Having templates with a suffix explicitly present has always been 84407 quirky. Introduce a 2nd matching pass in case the 1st one couldn't find 84408 a suitable template _and_ didn't itself already need to trim off a 84409 suffix to find a match at all. This requires error reporting adjustments 84410 (albeit luckily fewer than I was afraid might be necessary), as errors 84411 previously reported during matching now need deferring until after the 84412 2nd pass (because, obviously, we must not emit any error if the 2nd pass 84413 succeeds). While also related to PR gas/29524, it was requested that 84414 move-with-sign-extend be left as broken as it always was. 84415 84416 PR gas/29525 84417 Note that with the dropped CMPSD and MOVSD Intel Syntax string insn 84418 templates taking operands, mixed IsString/non-IsString template groups 84419 (with memory operands) cannot occur anymore. With that 84420 maybe_adjust_templates() becomes unnecessary (and is hence being 84421 removed). 84422 84423 PR gas/29526 84424 Note further that while the additions to the intel16 testcase aren't 84425 really proper Intel syntax, we've been permitting all of those except 84426 for the MOVD variant. The test therefore is to avoid re-introducing such 84427 an inconsistency. 84428 844292022-12-12 Jan Beulich <jbeulich@suse.com> 84430 84431 x86: constify parse_insn()'s input 84432 The function doesn't alter its input buffer: Reflect this in its 84433 prototype. To avoid using any kind of cast, simply calculate the update 84434 of "line" from the function's input and output. 84435 84436 x86: revert disassembler parts of "x86: Allow 16-bit register source for LAR and LSL" 84437 This reverts the disassembler parts of 859aa2c86dc9 ("x86: Allow 16-bit 84438 register source for LAR and LSL"), adjusting testcases as necessary. 84439 That change was itself a partial revert of c9f5b96bdab0 ("x86: correct 84440 handling of LAR and LSL"), without actually saying so. While the earlier 84441 commit was properly agreed upon, the partial revert was not, and hence 84442 should not have been committed. This is even more so that the revert 84443 part of that change wasn't even necessary to address PR gas/29844. 84444 844452022-12-12 Alan Modra <amodra@gmail.com> 84446 84447 PR29892, Field file_table of struct module is uninitialized 84448 PR 29892 84449 * vms-alphs.c (new_module): Use bfd_zmalloc to alloc file_table. 84450 (parse_module): Rewrite file_table reallocation code and clear. 84451 84452 Lack of bounds checking in vms-alpha.c parse_module 84453 PR 29873 84454 PR 29874 84455 PR 29875 84456 PR 29876 84457 PR 29877 84458 PR 29878 84459 PR 29879 84460 PR 29880 84461 PR 29881 84462 PR 29882 84463 PR 29883 84464 PR 29884 84465 PR 29885 84466 PR 29886 84467 PR 29887 84468 PR 29888 84469 PR 29889 84470 PR 29890 84471 PR 29891 84472 * vms-alpha.c (parse_module): Make length param bfd_size_type. 84473 Delete length == -1 checks. Sanity check record_length. 84474 Sanity check DST__K_MODBEG, DST__K_RTNBEG, DST__K_RTNEND lengths. 84475 Sanity check DST__K_SOURCE and DST__K_LINE_NUM elements 84476 before accessing. 84477 (build_module_list): Pass dst_section size to parse_module. 84478 844792022-12-12 Alan Modra <amodra@gmail.com> 84480 84481 PR29872, uninitialised value in display_debug_lines_decoded dwarf.c:5413 84482 Plus segvs if the C-library doesn't handle printf %s of NULL. 84483 84484 PR 29872 84485 * dwarf.c (null_name): New function. 84486 (process_debug_info): Use it here.. 84487 (display_debug_lines_raw): ..and here.. 84488 (display_debug_lines_decoded): ..and here. xcalloc directory_table. 84489 Simplify xcalloc of file_table. 84490 844912022-12-12 Jan Beulich <jbeulich@suse.com> 84492 84493 gas/codeview: avoid "shadowing" of glibc function name 84494 While not "index" this time, old enough glibc also has an (unguarded) 84495 declaration of fileno() in stdio.h, which triggers a "shadows a global 84496 declaration" warning with our choice of warning level and with at least 84497 some gcc versions. 84498 84499 x86: generate template sets data at build time 84500 Speed up gas startup by avoiding runtime allocation of the instances of 84501 type "templates". At the same time cut the memory requirement to just 84502 very little over half (not even accounting for any overhead 84503 notes_alloc() may incur) by reusing the "end" slot of a preceding entry 84504 for the "start" slot of the subsequent one. 84505 84506 x86: drop sentinel from i386_optab[] 84507 Now that the table is local to gas, ARRAY_SIZE() can be used to 84508 determine the end of the table. Re-arrange the processing loop in 84509 md_begin() accordingly, at the same time folding the two calls to 84510 notes_alloc() into just one. 84511 84512 x86: add generated tables dependency check to gas 84513 As requested by H.J., just for the sake of people potentially building 84514 in gas/ alone, add a check that the generated files in opcodes/ are 84515 actually up-to-date. Personally I think this should at best be a 84516 warning, but I can see how this may not be easily noticable among other 84517 make output (depending in particular on the verbosity level). 84518 84519 x86: break gas dependency on libopcodes 84520 gas doesn't use anything from libopcodes anymore - suppress linking in 84521 that library. 84522 84523 x86: remove i386-opc.c 84524 Remove the now empty i386-opc.c. To compensate, tie table generation in 84525 opcodes/ to the building of i386-dis.o, despite the file not really 84526 depending on the generated data. 84527 845282022-12-12 Jan Beulich <jbeulich@suse.com> 84529 84530 x86: instantiate i386_{op,reg}tab[] in gas instead of in libopcodes 84531 Unlike many other architectures, x86 does not share an opcode table 84532 between assembly and disassembly. Any consumer of libopcodes would only 84533 ever access one of the two. Since gas is the only consumer of the 84534 assembly data, move it there. While doing so mark respective entities 84535 "static" in i386-gen (we may want to do away with i386_regtab_size 84536 altogether). 84537 84538 This also shrinks the number of relocations to be processed for 84539 libopcodes.so by about 30%. 84540 845412022-12-12 GDB Administrator <gdbadmin@sourceware.org> 84542 84543 Automatic date update in version.in 84544 845452022-12-11 Alan Modra <amodra@gmail.com> 84546 84547 PR29870, objdump SEGV in display_debug_lines_decoded dwarf.c:5524 84548 DWARF5 directory and file table allow more opportunity for fuzzers 84549 to break things. There are likely other places in dwarf.c that should 84550 be fixed too. 84551 84552 PR 29870 84553 * dwarf.c (display_debug_lines_decoded): Handle NULL file_table 84554 name entry. 84555 845562022-12-11 GDB Administrator <gdbadmin@sourceware.org> 84557 84558 Automatic date update in version.in 84559 845602022-12-10 Tom de Vries <tdevries@suse.de> 84561 84562 [gdb/tdep] Fix larl handling in s390_displaced_step_fixup 84563 On s390x-linux with target board unix/-m31, I run into: 84564 ... 84565 (gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length 84566 print ptr^M 84567 $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M 84568 (gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr 84569 ... 84570 84571 A minimal example is: 84572 ... 84573 $ gdb -q -batch -ex "set trace-commands on" -x gdb.in 84574 +file scm-lazy-string 84575 +break main 84576 Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23. 84577 +run 84578 84579 Breakpoint 1, main () at scm-lazy-string.c:23 84580 23 const char *ptr = "pointer"; 84581 +step 84582 24 const char array[] = "array"; 84583 +print ptr 84584 $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0> 84585 ... 84586 84587 If we delete the breakpoint after running to it, we have instead the expected: 84588 ... 84589 +delete 84590 +step 84591 24 const char array[] = "array"; 84592 +print ptr 84593 $1 = 0x4006b0 "pointer" 84594 ... 84595 84596 The problem is in displaced stepping, forced by the presence of the breakpoint, 84597 when stepping over this insn: 84598 ... 84599 0x4005d2 <main+10> larl %r1,0x4006b0 84600 ... 84601 84602 With normal stepping we have: 84603 ... 84604 (gdb) p /x $r1 84605 $2 = 0x3ff004006b0 84606 ... 84607 but with displaced stepping we have instead (note the 0x80000000 difference): 84608 ... 84609 (gdb) p /x $r1 84610 $1 = 0x3ff804006b0 84611 (gdb) 84612 ... 84613 84614 The difference comes from this code in s390_displaced_step_fixup: 84615 ... 84616 /* Handle LOAD ADDRESS RELATIVE LONG. */ 84617 else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2)) 84618 { 84619 /* Update PC. */ 84620 regcache_write_pc (regs, from + insnlen); 84621 /* Recompute output address in R1. */ 84622 regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1, 84623 amode | (from + i2 * 2)); 84624 } 84625 ... 84626 where the "amode |" adds the 0x80000000. 84627 84628 Fix this by removing the "amode |". 84629 84630 Tested on s390-linux, with native and target board unix/-m31. 84631 84632 Approved-By: Ulrich Weigand <uweigand@de.ibm.com> 84633 846342022-12-10 GDB Administrator <gdbadmin@sourceware.org> 84635 84636 Automatic date update in version.in 84637 846382022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84639 84640 objdump: sframe: fix memory leaks 84641 ChangeLog: 84642 84643 * binutils/objdump.c (dump_section_sframe): free up contents and 84644 SFrame decoder context on exit. 84645 846462022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84647 84648 libsframe: rename API sframe_fde_func_info to sframe_fde_create_func_info 84649 The new name better reflects the purpose of the function. 84650 84651 ChangeLog: 84652 84653 * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use new 84654 name. 84655 * libsframe/sframe.c (sframe_fde_create_func_info): Rename 84656 sframe_fde_func_info to this. 84657 * libsframe/testsuite/libsframe.encode/encode-1.c: Use new name. 84658 84659 include/ChangeLog: 84660 84661 * sframe-api.h (sframe_fde_create_func_info): Rename 84662 sframe_fde_func_info to this. 84663 846642022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84665 84666 gas: sframe: fine tune the fragment fixup for SFrame func info 84667 SFrame function info is an unsigned 8-bit field comprising of the following 84668 (from LSB to MSB): 84669 - 4-bits: FRE type 84670 - 1-bit: FRE start address encoding 84671 - 3-bits: Unused 84672 84673 At the moment, the most-significat 4-bits are zero (The FRE start 84674 address encoding of SFRAME_FDE_TYPE_PCINC has a value of zero, and the upper 84675 3-bits are unused). So the current implementation works without this patch. 84676 84677 To be precise, however, the fragment fixup logic is meant to fixup only the 84678 least-significant 4-bits (i.e., only the FRE type needs to be updated 84679 according to the function size). 84680 84681 This patch makes the gas implementation a bit more resilient: In the 84682 future, when the format does evolve to make use of the currently unused 84683 3-bits in various ways, the values in those 3-bits can be propagated 84684 unchanged while the fragment fixup continues to update the lowermost 84685 4-bits to indicate the selected FRE type. 84686 84687 ChangeLog: 84688 84689 * gas/gen-sframe.c (create_func_info_exp): New definition. 84690 (output_sframe_funcdesc): Call create_func_info_exp. 84691 * gas/sframe-opt.c (sframe_estimate_size_before_relax): The 84692 associated fragment uses O_modulus now. 84693 (sframe_convert_frag): Adjust the fragment fixup code according 84694 to the new composite exp. 84695 846962022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84697 84698 sframe: gas: libsframe: define constants and remove magic numbers 84699 Define constants in sframe.h for the various limits associated with the 84700 range of offsets that can be encoded in the start address of an SFrame 84701 FRE. E.g., sframe_frame_row_entry_addr1 is used when start address 84702 offset can be encoded as 1-byte unsigned value. 84703 84704 Update the code in gas to use these defined constants as it checks for 84705 these limits, and remove the usage of magic numbers. 84706 84707 ChangeLog: 84708 84709 * gas/sframe-opt.c (sframe_estimate_size_before_relax): 84710 (sframe_convert_frag): Do not use magic numbers. 84711 * libsframe/sframe.c (sframe_calc_fre_type): Likewise. 84712 84713 include/ChangeLog: 84714 84715 * sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): New constant. 84716 (SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise. 84717 (SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise. 84718 847192022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84720 84721 sframe.h: make some macros more precise 84722 include/ChangeLog: 84723 84724 * sframe.h (SFRAME_V1_FUNC_INFO): Use specific bits only. 84725 (SFRAME_V1_FRE_INFO): Likewise. 84726 847272022-12-09 Indu Bhagat <indu.bhagat@oracle.com> 84728 84729 libsframe: minor formatting nits 84730 ChangeLog: 84731 84732 * libsframe/sframe.c: Fix formatting nits. 84733 847342022-12-09 Luis Machado <luis.machado@arm.com> 84735 84736 [aarch64] Add TPIDR2 register support for Linux 84737 With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and 84738 it will be added to the existing NT_ARM_TLS register set. Kernel patches are 84739 being reviewed here: 84740 84741 https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/ 84742 84743 From GDB's perspective, we handle it in a similar way to the existing TPIDR 84744 register. But we need to consider cases of systems that only have TPIDR and 84745 systems that have both TPIDR and TPIDR2. 84746 84747 With that in mind, the following patch adds the required code to support 84748 TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a 84749 dynamically-generated target description as opposed to a static target 84750 description containing only TPIDR. 84751 84752 That means we can remove the gdb/features/aarch64-tls.xml file and replace the 84753 existing gdb/features/aarch64-tls.c auto-generated file with a new file that 84754 dynamically generates the target description containing either TPIDR alone or 84755 TPIDR and TPIDR2. 84756 84757 In the future, when *BSD's start to support this register, they can just 84758 enable it as is being done for the AArch64 Linux target. 84759 84760 The core file read/write code has been updated to support TPIDR2 as well. 84761 84762 On GDBserver's side, there is a small change to the find_regno function to 84763 expose a non-throwing version of it. 84764 84765 It always seemed strange to me how find_regno causes the whole operation to 84766 abort if it doesn't find a particular register name. The patch moves code 84767 from find_regno into find_regno_no_throw and makes find_regno call 84768 find_regno_no_throw instead. 84769 84770 This allows us to do register name lookups to find a particular register 84771 number without risking erroring out if nothing is found. 84772 84773 The patch also adjusts the feature detection code for aarch64-fbsd, since 84774 the infrastructure is shared amongst all aarch64 targets. I haven't added 84775 code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if 84776 that will happen. 84777 847782022-12-09 Alan Modra <amodra@gmail.com> 84779 84780 PR28306, segfault in _bfd_mips_elf_reloc_unshuffle 84781 Access to section data during relocation processing should be bounds 84782 checked, as it is in bfd_perform_relocation. bfd_perform_relocation 84783 does these checks after any special_function is called. So a reloc 84784 special_function needs to do its own bounds checking before accessing 84785 section data. This patch adds many such checks to the mips backend. 84786 84787 Checking mips relocs is not without some difficulty. See the comment 84788 in _bfd_mips_reloc_offset_in_range. In a multitple reloc sequence 84789 applied to the same location, relocs that may appear somewhere other 84790 than the last one of the sequence need to be treated specially since 84791 they apply to the addend for the next relocation rather than the 84792 section contents. If the addend is in the section then it needs to be 84793 checked but not when the addend is in the reloc. check_inplace 84794 handles this situation. _bfd_mips_reloc_offset_in_range with 84795 check_shuffle handles the case where contents are shuffled before 84796 applying the relocation. 84797 84798 PR 28306 84799 * elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Check reloc 84800 address using _bfd_mips_reloc_offset_in_range. 84801 (gprel32_with_gp, mips16_gprel_reloc): Likewise. 84802 * elf64-mips.c (mips_elf64_gprel32_reloc): Likewise. 84803 (mips16_gprel_reloc): Likewise. 84804 * elfn32-mips.c (mips16_gprel_reloc): Likewise. 84805 (gprel32_with_gp): Check reloc address using 84806 bfd_reloc_offset_in_range. 84807 * elfxx-mips.h (enum reloc_check): Define. 84808 (_bfd_mips_reloc_offset_in_range): Declare. 84809 * elfxx-mips.c (needs_shuffle): New function. 84810 (_bfd_mips_elf_reloc_unshuffle, _bfd_mips_elf_reloc_shuffle): Use it. 84811 (_bfd_mips_reloc_offset_in_range): New function. 84812 (_bfd_mips_elf_gprel16_with_gp): Move reloc address checks to 84813 partial_inplace handling. Use bfd_reloc_offset_in_range. 84814 (_bfd_mips_elf_lo16_reloc): Check reloc address using 84815 bfd_reloc_offset_in_range. 84816 (_bfd_mips_elf_generic_reloc): Check reloc address using 84817 _bfd_mips_reloc_offset_in_range. 84818 (mips_elf_calculate_relocation): Check reloc address before calling 84819 mips_elf_nullify_got_load. 84820 (_bfd_mips_elf_check_relocs): Likewise. 84821 (mips_elf_read_rel_addend): Add sec param, check reloc address 84822 before reading. Adjust callers. 84823 (mips_elf_add_lo16_rel_addend): Add sec param, adjust callers. 84824 848252022-12-09 Tom de Vries <tdevries@suse.de> 84826 84827 [gdb/testsuite] Fix gdb.guile/scm-symtab.exp for ppc64le 84828 On powerpc64le-linux, I run into: 84829 ... 84830 (gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2 84831 guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M 84832 = #f^M 84833 (gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address 84834 ... 84835 84836 The problem is as follows: the instructions for the call to func2 are: 84837 ... 84838 1000070c: 39 00 00 48 bl 10000744 <func1> 84839 10000710: 00 00 00 60 nop 84840 10000714: 59 00 00 48 bl 1000076c <func2> 84841 10000718: 00 00 00 60 nop 84842 1000071c: 00 00 20 39 li r9,0 84843 ... 84844 and the corresponding line number info is: 84845 ... 84846 scm-symtab.c: 84847 File name Line number Starting address View Stmt 84848 scm-symtab.c 42 0x1000070c x 84849 scm-symtab.c 43 0x10000714 x 84850 scm-symtab.c 44 0x1000071c x 84851 ... 84852 84853 The test-case looks at the line numbers for two insns: 84854 - the insn of the call to func2 (0x10000714), and 84855 - the insn after that (0x10000718), 84856 and expects the line number of the latter to be greater than the line number 84857 of the former. 84858 84859 However, both insns have the same line number: 43. 84860 84861 Fix this by replacing ">" with ">=". 84862 84863 Tested on x86_64-linux and powerpc64le-linux. 84864 848652022-12-09 GDB Administrator <gdbadmin@sourceware.org> 84866 84867 Automatic date update in version.in 84868 848692022-12-08 H.J. Lu <hjl.tools@gmail.com> 84870 84871 x86-64: Remove BND from 64-bit IBT PLT 84872 Since MPX support has been removed from x86-64 psABI, remove BND from 84873 64-bit IBT PLT by using x32 IBT PLT. 84874 84875 bfd/ 84876 84877 PR ld/29851 84878 * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Also check 84879 x32 IBT PLT for 64-bit. 84880 (elf_x86_64_link_setup_gnu_properties): Always use x32 IBT PLT. 84881 84882 ld/ 84883 84884 PR ld/29851 84885 * testsuite/ld-x86-64/ibt-plt-1.d: Updated. 84886 * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise. 84887 * testsuite/ld-x86-64/ibt-plt-2b.d: Likewise. 84888 * testsuite/ld-x86-64/ibt-plt-2c.d: Likewise. 84889 * testsuite/ld-x86-64/ibt-plt-2d.d: Likewise. 84890 * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise. 84891 * testsuite/ld-x86-64/ibt-plt-3b.d: Likewise. 84892 * testsuite/ld-x86-64/ibt-plt-3c.d: Likewise. 84893 * testsuite/ld-x86-64/ibt-plt-3d.d: Likewise. 84894 * testsuite/ld-x86-64/plt-main-ibt-x32.dd: Moved to ... 84895 * testsuite/ld-x86-64/plt-main-ibt.dd: This. 84896 * testsuite/ld-x86-64/x86-64.exp: Don't use plt-main-ibt-x32.dd. 84897 848982022-12-08 Tom de Vries <tdevries@suse.de> 84899 84900 [gdb/testsuite] Require debug info for gdb.tui/tui-layout-asm-short-prog.exp 84901 When running test-case gdb.tui/tui-layout-asm-short-prog.exp on SLE-12-SP3 84902 aarch64, I run into: 84903 ... 84904 FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents 84905 FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents again 84906 ... 84907 due to: 84908 ... 84909 (gdb) file tui-layout-asm-short-prog^M 84910 Reading symbols from tui-layout-asm-short-prog...^M 84911 (No debugging symbols found in tui-layout-asm-short-prog)^M 84912 ... 84913 84914 I managed to reproduce the same behaviour on openSUSE Leap 15.4 x86_64, by 84915 removing the debug option. 84916 84917 Fix this by making the test-case unsupported if no debug info is found. 84918 84919 Tested on x86_64-linux. 84920 849212022-12-08 Enze Li <enze.li@hotmail.com> 84922 84923 gdb/testsuite: update a pattern in gdb_file_cmd 84924 When building GDB with the following CFLAGS and CXXFLAGS as part of 84925 configure line: 84926 84927 CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11 84928 84929 Then run the selftest.exp, I see: 84930 84931 ====== 84932 Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp 84933 ... 84934 FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main 84935 WARNING: Couldn't test self 84936 84937 === gdb Summary === 84938 84939 # of unexpected failures 1 84940 /home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx 84941 -iex "set height 0" -iex "set width 0" -data-directory 84942 /home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory 84943 ====== 84944 84945 It is the fact that when I use the previously mentioned CFLAGS and 84946 CXXFLAGS as part of the configuration line, the default value (-O2 -g) 84947 is overridden, then GDB has no debug information. When there's no debug 84948 information, GDB should not run the testcase in selftest.exp. 84949 84950 The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't 84951 get the right value ("nodebug") during the gdb_file_cmd procedure. 84952 84953 That's because in this commit, 84954 84955 commit 3453e7e409f44a79ac6695589836edb8a49bfb08 84956 Date: Sat May 19 11:25:20 2018 -0600 84957 84958 Clean up "Reading symbols" output 84959 84960 It changed "no debugging..." to "No debugging..." which causes the above 84961 problem. This patch only updates the corresponding pattern to fix this 84962 issue. 84963 84964 With this patch applied, I see: 84965 84966 ====== 84967 Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp 84968 ... 84969 84970 === gdb Summary === 84971 84972 # of untested testcases 1 84973 /home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx 84974 -iex "set height 0" -iex "set width 0" -data-directory 84975 /home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory 84976 ====== 84977 84978 Tested on x86_64-linux. 84979 84980 Approved-By: Simon Marchi <simon.marchi@efficios.com> 84981 849822022-12-08 Nick Clifton <nickc@redhat.com> 84983 84984 Update the description of the linker script's TYPE directive. 84985 PR 29861 84986 * ld.texi (Output Section Type): Note that setting the output 84987 section type only works if the section contains untyped data. 84988 849892022-12-08 Jan Vrany <jan.vrany@labware.com> 84990 84991 gdb: skip objfiles with no BFD in DWARF unwinder 84992 While playing with JIT reader I experienced GDB to crash on null-pointer 84993 dereference when stepping through non-jitted code. 84994 84995 The problem was that dwarf2_frame_find_fde () assumed that all objfiles 84996 have BFD but that's not always true. To address this problem, this 84997 commit skips such objfiles. 84998 84999 To test the fix we put breakpoint in jit_function_add (). The JIT reader 85000 does not know how unwind this function so unwinding eventually falls 85001 back to DWARF unwinder which in turn iterates over objfiles. Since the 85002 the code is jitted, it is guaranteed it would eventually process JIT 85003 objfile. 85004 85005 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85006 850072022-12-08 Alan Modra <amodra@gmail.com> 85008 85009 libctf: avoid potential double free 85010 * ctf-link.c (ctf_link_add_cu_mapping): Set t NULL after free. 85011 850122022-12-08 GDB Administrator <gdbadmin@sourceware.org> 85013 85014 Automatic date update in version.in 85015 850162022-12-07 Peter Bergner <bergner@linux.ibm.com> 85017 85018 PowerPC: Add support for RFC02655 - Saturating Subtract Instruction 85019 opcodes/ 85020 * ppc-opc.c (XOL): New define. 85021 (XOL_MASK): Likewise. 85022 (powerpc_opcodes): Add subfus, subfus., subwus, subwus., subdus, subdus. 85023 85024 gas/ 85025 * testsuite/gas/ppc/rfc02655.s: New test. 85026 * testsuite/gas/ppc/rfc02655.d: Likewise 85027 * testsuite/gas/ppc/future-raw.s: Likewise. 85028 * testsuite/gas/ppc/future-raw.d: Likewise. 85029 * testsuite/gas/ppc/ppc.exp: Run them. 85030 850312022-12-07 Peter Bergner <bergner@linux.ibm.com> 85032 85033 PowerPC: Add support for RFC02656 - Enhanced Load Store with Length Instructions 85034 opcodes/ 85035 * ppc-opc.c (PPCVSXF): New define. 85036 (powerpc_opcodes): Add lxvrl, lxvrll, lxvprl, lxvprll, stxvrl, 85037 stxvrll, stxvprl, stxvprl. 85038 85039 gas/ 85040 * testsuite/gas/ppc/rfc02656.s: New test. 85041 * testsuite/gas/ppc/rfc02656.d: Likewise. 85042 * testsuite/gas/ppc/ppc.exp: Run it. 85043 850442022-12-07 Simon Marchi <simon.marchi@polymtl.ca> 85045 85046 gdb: add invalidate_selected_frame function 85047 Instead of using `select_frame (nullptr)` to invalidate the selected 85048 frame, introduce a function to do that. There is no change in behavior, 85049 but it makes the intent a bit clearer. It also allows adding an assert 85050 in select_frame that fi is not nullptr, so it avoids passing nullptr by 85051 mistake. 85052 85053 Change-Id: I61643f46bc8eca428334513ebdaadab63997bdd0 85054 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 85055 850562022-12-07 Tom de Vries <tdevries@suse.de> 85057 85058 [gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp 85059 Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering 85060 various ways that gdb is unable to recover the longjmp target if the libc 85061 probe is not supported. 85062 85063 Tested on x86_64-linux. 85064 85065 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85066 850672022-12-07 Tom Tromey <tromey@adacore.com> 85068 85069 Remove unnecessary xstrdup from bppy_init 85070 I saw that bppy_init used a non-const "char *". Fixing this revealed 85071 that the xstrdup here was also unnecessary, so this patch removes it. 85072 850732022-12-07 Alan Modra <amodra@gmail.com> 85074 85075 coff make_a_section_from_file tidy 85076 Also support compressing a few more sections. 85077 85078 * coffgen.c (make_a_section_from_file): Rename return_section 85079 to newsect. Don't try to be clever matching section name. 85080 Compress .gnu.debuglto_.debug_ and .gnu.linkonce.wi. too. 85081 Only rename debug sections when decompressing for linker. 85082 850832022-12-07 Alan Modra <amodra@gmail.com> 85084 85085 gas compress_debug tidy 85086 * write.c (compress_debug): Don't set up "ob" until after 85087 seginfo NULL check. Simplify SEC_CONTENTS test. Localise 85088 variables. Use bfd_debug_name_to_zdebug. 85089 85090 _bfd_elf_slurp_secondary_reloc_section sanity check 85091 * elf.c (_bfd_elf_slurp_secondary_reloc_section): Sanity check 85092 section header against file size. Avoid overflow in 85093 reloc_count. 85094 85095 bfd_compress_section_contents access to elf_section_data 85096 * compress.c (bfd_compress_section_contents): Don't access 85097 elf_section_data for non-ELF. 85098 850992022-12-07 Alan Modra <amodra@gmail.com> 85100 85101 Compression tidy and fixes 85102 Tidies: 85103 - Move stuff from bfd-in.h and libbfd.c to compress.c 85104 - Delete COMPRESS_DEBUG from enum compressed_debug_section_type 85105 - Move compress_debug field out of link_info to ld_config. 85106 Fixes: 85107 - Correct test in bfd_convert_section_setup to use obfd flags, 85108 not ibfd. 85109 - Apply bfd_applicable_file_flags to compression bfd flags added 85110 by gas and ld to the output bfd. 85111 85112 bfd/ 85113 * bfd-in.h (enum compressed_debug_section_type), 85114 (struct compressed_type_tuple), 85115 (bfd_get_compression_algorithm), 85116 (bfd_get_compression_algorithm_name), 85117 * libbfd.c (compressed_debug_section_names), 85118 (bfd_get_compression_algorithm), 85119 (bfd_get_compression_algorithm_name): Move.. 85120 * compress.c: ..to here, deleting COMPRESS_DEBUG from 85121 enum compressed_debug_section_type. 85122 (bfd_convert_section_setup): Test obfd flags not ibfd for 85123 compression flags. 85124 * elf.c (elf_fake_sections): Replace link_info->compress_debug 85125 test with abfd->flags test. 85126 * bfd-in2.h: Regenerate. 85127 binutils/ 85128 * objcopy.c (copy_file): Tidy setting of bfd compress flags. 85129 Expand comment. 85130 gas/ 85131 * write.c (compress_debug): Test bfd compress flags rather than 85132 flag_compress_debug. 85133 (write_object_file): Apply bfd_applicable_file_flags to compress 85134 debug flags added to output bfd. 85135 include/ 85136 * bfdlink.h (struct bfd_link_info): Delete compress_debug. 85137 ld/ 85138 * ld.h (ld_config_type): Add compress_debug. 85139 * emultempl/elf.em: Replace references to link_info.compress_debug 85140 with config.compress_debug. 85141 * lexsup.c (elf_static_list_options): Likewise. 85142 * ldmain.c (main): Likewise. Apply bfd_applicable_file_flags 85143 to compress debug flags added to output bfd. 85144 851452022-12-07 GDB Administrator <gdbadmin@sourceware.org> 85146 85147 Automatic date update in version.in 85148 851492022-12-06 H.J. Lu <hjl.tools@gmail.com> 85150 85151 bfd: Avoid signed overflow for new_size adjustment 85152 When bfd_size_type is unsigned 64-bit integer and sizeof is unsigned 85153 32-bit integer, subtraction in 85154 85155 *new_size += sizeof (Elf32_External_Chdr) - sizeof (Elf64_External_Chdr); 85156 85157 will overflow. Use 85158 85159 *new_size -= sizeof (Elf64_External_Chdr) - sizeof (Elf32_External_Chdr); 85160 85161 to avoid overflow. 85162 85163 PR binutils/29860 85164 * compress.c (bfd_convert_section_setup): Avoid signed overflow 85165 for new_size adjustment. 85166 851672022-12-06 Tom Tromey <tromey@adacore.com> 85168 85169 Cosmetic fix in ppc-sysv-tdep.c 85170 This is just a couple of cosmetic fixes in ppc-sysv-tdep.c: fixing 85171 some formatting and correcting a typo. 85172 85173 Fix operator precedence bug in Rust parser 85174 PR rust/29859 points out an operator precedence bug in the Rust 85175 parser. This patch fixes it and adds a regression test. 85176 851772022-12-06 Nick Clifton <nickc@redhat.com> 85178 85179 Fix a dereference of NULL when scanning the symbol hashes array in the ARM linker. 85180 PR 29852 85181 * elf32-arm.c (cmse_scan): Check for NULL entries in the 85182 sym_hashes array. 85183 (elf32_arm_gc_mark_extra_sections): Likewise. 85184 851852022-12-06 Tom de Vries <tdevries@suse.de> 85186 85187 [gdb/testsuite] Fix test names in gdb.base/longjmp.exp 85188 When running test-case gdb.base/longjmp.exp, we have: 85189 ... 85190 PASS: gdb.base/longjmp.exp: next over setjmp (1) 85191 ... 85192 PASS: gdb.base/longjmp.exp: next over setjmp (2) 85193 ... 85194 85195 The trailing " (1)" and " (2)" are interpreted as comments rather than parts 85196 of the test name, and therefore this is a duplicate, which is currently not 85197 detected by our duplicate detection mechanism (PR testsuite/29772). 85198 85199 Fix the duplicate by using with_test_prefix. 85200 85201 Tested on x86_64-linux. 85202 852032022-12-06 Tom de Vries <tdevries@suse.de> 85204 85205 [gdb/testsuite] Make gdb.base/longjmp.exp FAIL more stable across archs 85206 When running test-case gdb.base/longjmp.exp on x86_64-linux, the master 85207 longjmp breakpoint is set using probes and the test-case passes: 85208 ... 85209 (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) 85210 next^M 85211 0x00000000004005cc 49 if (setjmp (env) == 0) /* patt1 */^M 85212 (gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1) 85213 next^M 85214 56 resumes++;^M 85215 (gdb) PASS: gdb.base/longjmp.exp: next into else block (1) 85216 ... 85217 85218 However, if I disable 85219 create_longjmp_master_breakpoint_probe, we have instead: 85220 ... 85221 (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) 85222 next^M 85223 56 resumes++;^M 85224 (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) 85225 ... 85226 85227 At first glance, the failure mode doesn't look too bad: we stop 85228 a few insns later than the passing scenario. 85229 85230 For contrast, if we do the same on powerpc64le, the failure mode is: 85231 ... 85232 (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1) 85233 next^M 85234 ^M 85235 Breakpoint 3, main () at longjmp.c:59^M 85236 59 i = 1; /* miss_step_1 */^M 85237 (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) 85238 ... 85239 Here we only stop because of running into the safety net breakpoint at 85240 miss_step_1. 85241 85242 So, how does this happen on x86_64? Let's look at the code: 85243 ... 85244 4005c7: e8 94 fe ff ff call 400460 <_setjmp@plt> 85245 4005cc: 85 c0 test %eax,%eax 85246 4005ce: 75 1e jne 4005ee <main+0x3b> 85247 4005d0: 8b 05 8e 0a 20 00 mov 0x200a8e(%rip),%eax # 601064 <longjmps> 85248 4005d6: 83 c0 01 add $0x1,%eax 85249 4005d9: 89 05 85 0a 20 00 mov %eax,0x200a85(%rip) # 601064 <longjmps> 85250 4005df: be 01 00 00 00 mov $0x1,%esi 85251 4005e4: bf 80 10 60 00 mov $0x601080,%edi 85252 4005e9: e8 82 fe ff ff call 400470 <longjmp@plt> 85253 4005ee: 8b 05 74 0a 20 00 mov 0x200a74(%rip),%eax # 601068 <resumes> 85254 ... 85255 The next over the longjmp call at 4005e9 is supposed to stop at the longjmp 85256 target at 4005cc, but instead we stop at 4005ee, where we have the step-resume 85257 breakpoint inserted by the next. In other words, we accidentally "return" 85258 from the longjmp call to the insn immediately after it (even though 85259 a longjmp is a noreturn function). 85260 85261 Try to avoid this accident and make the failure mode on x86_64 the same as on 85262 powerpc64le, by switching the then and else branch. 85263 85264 Tested on x86_64-linux. 85265 852662022-12-06 Xiao Zeng <zengxiao@eswincomputing.com> 85267 85268 gdb/riscv: correct dwarf to gdb register number mapping 85269 According to the riscv psabi, the mapping relationship between the 85270 DWARF registers and the machine registers is as follows: 85271 85272 DWARF Number | Register Name | Description 85273 0 - 31 | x0 - x31 | Integer Registers 85274 32 - 63 | f0 - f31 | Floating-point Registers 85275 85276 This is not modelled quite right in riscv_dwarf_reg_to_regnum, the 85277 DWARF register numbers 31 and 63 are not handled correctly due to a 85278 use of '<' instead of '<='. This commit fixes this issue. 85279 852802022-12-06 Haochen Jiang <haochen.jiang@intel.com> 85281 85282 x86: Remove unnecessary vex.w check for xh_mode in disassembler 85283 For all the xh_mode usage in table, they are all using %XH, which will 85284 print "{bad}" while EVEX.W=1. This makes this vex.w check unnecessary. 85285 85286 opcodes/ChangeLog: 85287 85288 * i386-dis.c (OP_E_memory): Remove vex.w check for xh_mode. 85289 852902022-12-06 Alan Modra <amodra@gmail.com> 85291 85292 Get rid of SEC_ELF_COMPRESS 85293 This flag also isn't needed, except for some sanity checks which we 85294 can omit. 85295 85296 * elf.c (elf_fake_sections): Don't set SEC_ELF_COMPRESS for 85297 compressed debug sections, just leave sh_name as -1. 85298 (assign_file_positions_for_non_load_sections), 85299 (assign_file_positions_except_relocs): Decide whether a section 85300 needs compressing and thus should not have its file offset set 85301 by looking at sh_name. 85302 (_bfd_elf_assign_file_positions_for_non_load): Similarly decide 85303 which sections need compressing. 85304 * elflink.c (bfd_elf_final_link): Don't test SEC_ELF_COMPRESS. 85305 * merge.c (_bfd_write_merged_section): Likewise. 85306 * section.c (SEC_ELF_COMPRESS): Don't define. 85307 (SEC_ELF_PURECODE): Renumber. 85308 * bfd-in2.h: Regenerate. 85309 853102022-12-06 Alan Modra <amodra@gmail.com> 85311 85312 Get rid of SEC_ELF_RENAME 85313 SEC_ELF_RENAME is a flag used to effect section name changes when 85314 compressing/decompressing zlib-gnu debug sections. This can be 85315 accomplished more directly in one of the objcopy specific bfd 85316 functions. Renaming for ld input is simplified too. Ld input object 85317 files always have BFD_DECOMPRESS set. 85318 85319 bfd/ 85320 * compress.c (bfd_convert_section_size): Rename to.. 85321 (bfd_convert_section_setup): ..this. Handle objcopy renaming 85322 of compressed/decompressed debug sections. 85323 * elf.c (_bfd_elf_make_section_from_shdr): Only rename zdebug 85324 input for linker. 85325 (elf_fake_sections): Don't handle renaming of debug sections for 85326 objcopy here. 85327 * section.c (SEC_ELF_RENAME): Delete. 85328 * bfd-in2.h: Regenerate. 85329 binutils/ 85330 * objcopy.c (setup_section): Call bfd_convert_section_setup. 85331 Don't call bfd_convert_section_size. 85332 853332022-12-06 Alan Modra <amodra@gmail.com> 85334 85335 Compression header enum 85336 Define an enum instead of using ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD 85337 in bfd and binutils, and move some functions from bfd.c to compress.c. 85338 When looking at the COFF/PE debug compression support, I wondered 85339 about extending it to support zstd. I likely won't do that, but 85340 the compression header ch_type field isn't just ELF specific if these 85341 headers are to be used in COFF/PE too. 85342 85343 bfd/ 85344 * bfd.c (bfd_update_compression_header), 85345 (bfd_check_compression_header, bfd_get_compression_header_size), 85346 (bfd_convert_section_size, bfd_convert_section_contents): Move to.. 85347 * compress.c: ..here. 85348 (enum compression_type): New. Use it throughout file. 85349 * elf.c (_bfd_elf_make_section_from_shdr): Replace uses of 85350 ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD with ch_compress_zlib and 85351 ch_compress_zstd. 85352 * bfd-in2.h: Regenerate. 85353 binutils/ 85354 * readelf.c (process_section_headers, dump_section_as_strings), 85355 (dump_section_as_bytes, load_specific_debug_section): Replace 85356 uses of ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD with 85357 ch_compress_zlib and ch_compress_zstd. 85358 853592022-12-06 mengqinggang <mengqinggang@loongson.cn> 85360 85361 LoongArch: Fix dynamic reloc not generated bug in some cases. 85362 bfd/ChangeLog: 85363 85364 * elfnn-loongarch.c (loongarch_elf_relocate_section): Likewise. 85365 853662022-12-06 Alan Modra <amodra@gmail.com> 85367 85368 PR29855, ch_type in bfd_init_section_decompress_status can be uninitialized 85369 PR 29855 85370 * compress.c (bfd_init_section_decompress_status): Set ch_type 85371 to zero for zlib-gnu case. 85372 853732022-12-06 GDB Administrator <gdbadmin@sourceware.org> 85374 85375 Automatic date update in version.in 85376 853772022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85378 85379 gdb/linux-nat: add ptid parameter to linux_xfer_siginfo 85380 Make the inferior_ptid bubble up to linux_nat_target::xfer_partial. 85381 85382 Change-Id: I62dbc5734c26648bb465f449c2003c73751cd812 85383 853842022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85385 85386 gdb/linux-nat: use l linux_nat_get_siginfo in linux_xfer_siginfo 85387 I noticed we could reduce duplication a bit here. 85388 85389 Change-Id: If24e54d1dac71b46f7c1f68a18a073d4c084b644 85390 853912022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85392 85393 gdb/linux-nat: check ptrace return value in linux_nat_get_siginfo 85394 Not a big deal, but it seems strange to check errno instead of the 85395 ptrace return value to know whether it succeeded. 85396 85397 Change-Id: If0a6d0280ab0e5ecb077e546af0d6fe489c5b9fd 85398 853992022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85400 85401 gdb/linux-nat: don't memset siginfo on failure in linux_nat_get_siginfo 85402 No caller cares about the value of *SIGINFO on failure. It's also 85403 documented in the function doc that *SIGINFO is uninitialized (I 85404 understand "untouched") on failure. 85405 85406 Change-Id: I5ef38a5f58e3635e109b919ddf6f827f38f1225a 85407 854082022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85409 85410 gdb/linux-nat: bool-ify linux_nat_get_siginfo 85411 Change return type to bool. 85412 85413 Change-Id: I1bf0360bfdd1b5994cd0f96c268d806f96fe51a4 85414 854152022-12-05 Simon Marchi <simon.marchi@polymtl.ca> 85416 85417 gdb/linux-nat: use get_ptrace_pid in two spots 85418 No behavior change expected. 85419 85420 Change-Id: Ifaa64ecd619483646b024fd7c62e571e92a8eedb 85421 854222022-12-05 Simon Marchi <simon.marchi@efficios.com> 85423 85424 gdb/testsuite: remove perror calls when failing to run 85425 I noticed that when running these two tests in sequence: 85426 85427 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... 85428 ERROR: GDB process no longer exists 85429 ERROR: Couldn't run foo-all 85430 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... 85431 85432 The results in gdb.sum are: 85433 85434 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... 85435 PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb 85436 ERROR: GDB process no longer exists 85437 UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof) 85438 ERROR: Couldn't run foo-all 85439 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... 85440 UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada 85441 PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 85442 85443 The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test, 85444 while trying to run to main. However, the UNRESOLVED in assign_1.exp 85445 doesn't make sense, GDB behaves as expected in that test: 85446 85447 (gdb) set lang ada^M 85448 (gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada 85449 print $xxx := 1^M 85450 $1 = 1^M 85451 (gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 85452 85453 The problem is that arrayptr.exp calls perror when failing to run to 85454 main, then returns. perror makes it so that the next test (as in 85455 pass/fail) will be recorded as UNRESOLVED. However, here, the next test 85456 (as in pass/fail) is in the next test (as in .exp). Hence the spurious 85457 UNRESOLVED in assign_1.exp. 85458 85459 These perror when failing to run to X are not really useful, especially 85460 since runto records a FAIL on error, by default. Remove all the 85461 perrors on runto failure I could find. 85462 85463 When there wasn't one already, add a return statement when failing to 85464 run, to avoid running the test of the test unnecessarily. 85465 85466 I thought of adding a check ran between test (in gdb_finish 85467 probably) where we would emit a warning if errcnt > 0, meaning a test 85468 quit and left a perror "active". However, reading that variable would 85469 poke into the DejaGNU internals, not sure it's a good idea. 85470 85471 Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b 85472 854732022-12-05 Luis Machado <luis.machado@arm.com> 85474 85475 Add missing newline to gdbarch_tdep debugging output 85476 The missing newline causes testsuite issues because the gdb prompt gets output 85477 to an unexpected location. 85478 854792022-12-05 Nick Clifton <nickc@redhat.com> 85480 85481 Prevent an illegal memory access when comparing the prefix of a section name regexp. 85482 PR 29849 85483 * ldlang.c (spec_match): Check that there is sufficient length in 85484 the target name to match the spec's prefix. 85485 854862022-12-05 Martin Liska <mliska@suse.cz> 85487 85488 testsuite: support mold linker 85489 Mold linker demotes symbols like main to be local and the patch 85490 adjusts expected output from nm. 85491 85492 Moreover, simplify the regex patterns. 85493 854942022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 85495 85496 gdbarch.py: Fix indentation in the generated set_gdbarch_* definitions 85497 Use as many tabs as possible for indentation and pad with spaces to keep 85498 the argument aligned to the opening parenthesis in the line above. 85499 85500 Co-developed-by: Simon Marchi <simon.marchi@efficios.com> 85501 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85502 855032022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 85504 85505 gdbarch.py: Fix indentation in the generated gdbarch_dump function 85506 Use tab for the first eight spaces of indentation, and align the gdb_printf 85507 arguments to the open parenthesis of the function call. 85508 85509 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85510 855112022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 85512 85513 gdb: Update my email address in MAINTAINERS 85514 855152022-12-05 Jan Beulich <jbeulich@suse.com> 85516 85517 gas: add Dwarf line number test for .macro expansions 85518 Before fiddling with the code let's put in place a test covering what 85519 PR/gas 16908 aimed at. 85520 85521 gas: squash (some) .linefile from listings 85522 Not so long ago we started to insert these artificially when expanding 85523 certain macro-like constructs; zap them as cluttering what actually 85524 results from user input. 85525 855262022-12-05 Jan Beulich <jbeulich@suse.com> 85527 85528 gas: avoid inserting extra newline in buffer_and_nest() 85529 In "-alm" listings I've noticed an odd blank line following the inserted 85530 .linefile one. This results from the explicit NL inserted being 85531 redundant with the one left in place from the original input line by all 85532 respective callers. Note that we need to compensate for the removed line 85533 by bumping the directive argument (which in turn is decremented again in 85534 s_linefile() before calling new_logical_line_flags(), and I have to 85535 confess that when putting together the original change I was a little 85536 puzzled by the imbalance of increments/decrements, but then I forgot to 85537 actually go look for the cause). 85538 85539 While there also switch to sb_add_string() instead of effectively open- 85540 coding it to some degree. 85541 855422022-12-05 Jan Beulich <jbeulich@suse.com> 85543 85544 Arm: .noinit and .persistent are not supported for Linux targets 85545 Respective tests being run means guaranteed failures. 85546 855472022-12-05 Nick Clifton <nickc@redhat.com> 85548 85549 Fix an illegal memory access when parsing a corrupt VMS Alpha file. 85550 PR 29848 85551 * vms-alpha.c (parse_module): Fix potential out of bounds memory 85552 access. 85553 855542022-12-05 Andrew Burgess <aburgess@redhat.com> 85555 85556 libopcodes/mips: add support for disassembler styling 85557 This commit adds disassembler styling support for MIPS. After this 85558 commit objdump and GDB will style disassembler output. 85559 85560 This is a pretty straight forward change, we switch to use the 85561 disassemble_info::fprintf_styled_func callback, and pass an 85562 appropriate style through as needed. No additional tricks were 85563 needed (compared to say i386, or ARM). 85564 85565 Tested by running all of the objdump commands used by the gas 85566 testsuite and manually inspecting the styled output, everything looks 85567 reasonable, though I'm not a MIPS expert, so it is possible that I've 85568 missed some corner cases. Worst case though is that something will be 85569 styled incorrectly, the actual content should be unchanged. 85570 85571 All the gas, ld, and binutils tests still pass for me. 85572 855732022-12-05 Andrew Burgess <aburgess@redhat.com> 85574 85575 opcodes/mips: use .word/.short for undefined instructions 85576 While working on disassembler styling for MIPS, I noticed that 85577 undefined instructions are printed by the disassembler as raw number 85578 with no assembler directive prefix (e.g. without .word or .short). 85579 85580 I think adding something like .word, or .short, helps to make it 85581 clearer the size of the value that is being displayed, and is inline 85582 with what many of the other libopcode disassemblers do. 85583 85584 In this commit I've added the .word and .short directives, and updated 85585 all the tests that I spotted that failed as a result. 85586 855872022-12-05 Alan Modra <amodra@gmail.com> 85588 85589 Re: Renaming .debug to .zdebug and vice versa 85590 * compress.c (bfd_debug_name_to_zdebug): Fix C++ compile error. 85591 (bfd_zdebug_name_to_debug): Likewise. 85592 * bfd-in2.h: Regenerate. 85593 855942022-12-05 GDB Administrator <gdbadmin@sourceware.org> 85595 85596 Automatic date update in version.in 85597 855982022-12-04 Alan Modra <amodra@gmail.com> 85599 85600 PR29846, segmentation fault in objdump.c compare_symbols 85601 Fixes a fuzzed object file problem where plt relocs were manipulated 85602 in such a way that two synthetic symbols were generated at the same 85603 plt location. Won't occur in real object files. 85604 85605 PR 29846 85606 PR 20337 85607 * objdump.c (compare_symbols): Test symbol flags to exclude 85608 section and synthetic symbols before attempting to check flavour. 85609 856102022-12-04 Alan Modra <amodra@gmail.com> 85611 85612 COFF compressed debug support 85613 Since commit 4bea06d73c04 COFF support for compressed debug sections 85614 has been broken due to the "flags" variable not getting SEC_HAS_CONTENTS. 85615 85616 * coffgen.c (make_a_section_from_file): Correct section flags 85617 handling. Delete extraneous condition. Update error messages 85618 to be the same as in elf.c. 85619 856202022-12-04 Alan Modra <amodra@gmail.com> 85621 85622 Renaming .debug to .zdebug and vice versa 85623 Move a couple of elf.c functions to compress.c. 85624 85625 * compress.c (bfd_debug_name_to_zdebug): New inline function. 85626 (bfd_zdebug_name_to_debug): Likewise. 85627 * elf.c (convert_debug_to_zdebug, convert_zdebug_to_debug): Delete. 85628 (_bfd_elf_make_section_from_shdr, elf_fake_sections), 85629 (_bfd_elf_assign_file_positions_for_non_load): Adjust to suit. 85630 * coffgen.c (make_a_section_from_file): Use new inlines here. 85631 856322022-12-04 GDB Administrator <gdbadmin@sourceware.org> 85633 85634 Automatic date update in version.in 85635 856362022-12-03 H.J. Lu <hjl.tools@gmail.com> 85637 85638 Revert "ld: Add .note.GNU-stack to ld-plugin/dummy.s" 85639 This reverts commit 44e59b5a7d8a874f6546a1471b8a003911853aa0. 85640 85641 It works only for ELF targets. 85642 856432022-12-03 H.J. Lu <hjl.tools@gmail.com> 85644 85645 ld: Add .note.GNU-stack to ld-plugin/dummy.s 85646 * testsuite/ld-plugin/dummy.s: Add .note.GNU-stack. 85647 856482022-12-03 H.J. Lu <hjl.tools@gmail.com> 85649 85650 x86: Allow 16-bit register source for LAR and LSL 85651 Since LAR and LSL only access 16 bits of the source operand, regardless 85652 of operand size, allow 16-bit register source for LAR and LSL, and always 85653 disassemble LAR and LSL with 16-bit source operand. 85654 85655 gas/ 85656 85657 PR gas/29844 85658 * testsuite/gas/i386/i386.s: Add tests for LAR and LSL. 85659 * testsuite/gas/i386/x86_64.s: Likewise. 85660 * testsuite/gas/i386/intelbad.s: Remove "lar/lsl eax, ax". 85661 * testsuite/gas/i386/i386-intel.d: Updated. 85662 * testsuite/gas/i386/i386.d: Likewise. 85663 * testsuite/gas/i386/intel-intel.d: Likewise. 85664 * testsuite/gas/i386/intel.d: Likewise. 85665 * testsuite/gas/i386/intelbad.l: Likewise. 85666 * testsuite/gas/i386/x86_64-intel.d: Likewise. 85667 * testsuite/gas/i386/x86_64.d: Likewise. 85668 85669 opcodes/ 85670 85671 PR gas/29844 85672 * i386-dis.c (MOD_0F02): Removed. 85673 (MOD_0F03): Likewise. 85674 (dis386_twobyte): Restore larS and lslS. 85675 (mod_table): Remove MOD_0F02 and MOD_0F03. 85676 * i386-opc.tbl: Allow 16-bit register source for LAR and LSL. 85677 * i386-tbl.h: Regenerated. 85678 856792022-12-03 GDB Administrator <gdbadmin@sourceware.org> 85680 85681 Automatic date update in version.in 85682 856832022-12-02 Simon Marchi <simon.marchi@polymtl.ca> 85684 85685 gdb/linux-nat: add pid parameter to linux_proc_xfer_memory_partial 85686 Add a pid parameter to linux_proc_xfer_memory_partial, making the 85687 inferior_ptid reference bubble up close to the target_ops::xfer_partial 85688 boundary. No behavior change expected. 85689 85690 Change-Id: I58171b00ee1bba1ea22efdbb5dcab8b1ab3aac4c 85691 856922022-12-02 Simon Marchi <simon.marchi@efficios.com> 85693 85694 gdb: add some debug statements to solib-svr4.c 85695 Add a few debug statements that were useful to me when debugging why the 85696 glibc probes interface wasn't getting used. 85697 85698 Change-Id: Ic20744f9fc80a90f196896b0829949411620c540 85699 857002022-12-02 Simon Marchi <simon.marchi@polymtl.ca> 85701 85702 gdb: merge solib-frv aix-solib debug options into "set/show debug solib" 85703 solib implementations are typically used one at a time. So it will be 85704 rare that you will want to enable debug for one solib kind, and 85705 absolutely want to keep the others disabled. To make things simpler, 85706 instead of adding separate variables / macros / commands for each solib 85707 implementation, merge the existing ones (frv and aix) into a unified 85708 "set/show debug solib", with the solib_debug_printf macro. 85709 85710 Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa 85711 857122022-12-02 Nick Clifton <nickc@redhat.com> 85713 85714 Add Jan Beulich as an x86_64 maintainer. 85715 857162022-12-02 Jan Beulich <jbeulich@suse.com> 85717 85718 x86: drop most OPERAND_TYPE_* (and rework the rest) 85719 With the general use of C99 there's no need anymore to have i386-gen 85720 produce these. For more frequently used ones introduce local #define-s, 85721 while others are simply spelled out directly. While doing this move 85722 some static constants into more narrow scopes. 85723 85724 Note that as a "side effect" this corrects type_names[]'es imm8s entry. 85725 857262022-12-02 Jan Beulich <jbeulich@suse.com> 85727 85728 x86: simplify and slightly correct XCHG vs NOP checking 85729 For one, because of CheckRegSize, there's no need to check the size of 85730 both (register) operands. And then in process_suffix() check opcode 85731 space rather than the (potentially ambiguous) extension opcode. 85732 85733 x86: also use D for XCHG and TEST 85734 Leverage the C (commutative) attribute to also reduce the number of XCHG 85735 and TEST templates we have. This way the reg <-> r/m (and reg <-> reg for 85736 XCHG) forms can also be folded into a single template each, utilizing D. 85737 857382022-12-02 Tom de Vries <tdevries@suse.de> 85739 85740 [gdb/testsuite] Prevent timeout in gdb.ada/float-bits.exp 85741 Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp 85742 for powerpc64le") started using command "maint print architecture", which 85743 produces ~275 lines. 85744 85745 Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent 85746 timeouts on slower test setups. 85747 85748 Note that this doesn't fix a timeout in the test-case on aarch64 due to: 85749 ... 85750 gdbarch_dump: read_core_file_mappings = <0x817438> 85751 (gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000 85752 ... 85753 85754 Tested on x86_64-linux. 85755 857562022-12-02 GDB Administrator <gdbadmin@sourceware.org> 85757 85758 Automatic date update in version.in 85759 857602022-12-01 Carl Love <cel@us.ibm.com> 85761 85762 PowerPC, fix gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 85763 The tests set a break point with the command break *func. This sets a 85764 breakpoint on the first instruction of the function. PowerPC uses 85765 Global Entry Points (GEP) and Local Entry Points (LEP). The first 85766 instruction in the function is the GEP. The GEP sets up register 85767 r2 before reaching the LEP. When the function is called with func() the 85768 function is entered via the LEP and the test fails because GDB does not 85769 see the breakpoint on the GEP. However, if the function is called via a 85770 function pointer, execution begins at the GEP as the test expects. 85771 85772 Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and 85773 next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new 85774 source file was created for tests finish-reverse-bkpt.exp and 85775 next-reverse-bkpt-over-sr.exp. The new files use the new function 85776 pointer method to call the functions so the tests will work correctly on 85777 both PowerPC with a GEP and LEP as well as on other systems. The GEP is 85778 the same as the LEP on non PowerPC systems. 85779 85780 The expect files were changed to use the new source files and to set the 85781 initial break point for the rest of the test on the function pointer call 85782 for the function. 85783 85784 This patch fixes two PowerPC test failures in each of the tests 85785 gdb.reverse/finish-reverse-bkpt.exp and 85786 gdb.reverse/next-reverse-bkpt-over-sr.exp. 85787 85788 Patch tested on PowerPC and Intel X86-64 with no regressions. 85789 85790 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 85791 857922022-12-01 Tom Tromey <tromey@adacore.com> 85793 85794 Remove call to registers_changed from windows-nat.c 85795 I noticed that windows_nat_target::interrupt calls registers_changed. 85796 However, I don't think there's any reason to do this, because this 85797 will happen automatically when the inferior stop is processed. 85798 85799 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85800 858012022-12-01 Tom Tromey <tromey@adacore.com> 85802 85803 Remove the_windows_nat_target global 85804 I belatedly realized that the "the_windows_nat_target" global isn't 85805 really necessary. It's only used in one place, where 'this' would be 85806 simpler and clearer. This patch removes the global entirely. 85807 85808 Approved-By: Simon Marchi <simon.marchi@efficios.com> 85809 858102022-12-01 Simon Marchi <simon.marchi@polymtl.ca> 85811 85812 gdb: make frame_register static 85813 It is only used inside frame.c. 85814 85815 Change-Id: I44eb46a5992412f8f8b4954b2284b0ef3b549504 85816 858172022-12-01 Tom Tromey <tromey@adacore.com> 85818 85819 Add name canonicalization for C 85820 PR symtab/29105 shows a number of situations where symbol lookup can 85821 result in the expansion of too many CUs. 85822 85823 What happens is that lookup_signed_typename will try to look up a type 85824 like "signed int". In cooked_index_functions::expand_symtabs_matching, 85825 when looping over languages, the C++ case will canonicalize this type 85826 name to be "int" instead. Then this method will proceed to expand 85827 every CU that has an entry for "int" -- i.e., nearly all of them. A 85828 crucial component of this is that the caller, objfile::lookup_symbol, 85829 does not do this canonicalization, so when it tries to find the symbol 85830 for "signed int", it fails -- causing the loop to continue. 85831 85832 This patch fixes the problem by introducing name canonicalization for 85833 C. The idea here is that, by making C and C++ agree on the canonical 85834 name when a symbol name can have multiple spellings, we avoid the bad 85835 behavior in objfile::lookup_symbol (and any other such code -- I don't 85836 know if there is any). 85837 85838 Unlike C++, C only has a few situations where canonicalization is 85839 needed. And, in particular, due to the lack of overloading (thus 85840 avoiding any issues in linespec) and due to the way c-exp.y works, I 85841 think that no canonicalization is needed during symbol lookup -- only 85842 during symtab construction. This explains why lookup_name_info is not 85843 touched. 85844 85845 The stabs reader is modified on a "best effort" basis. 85846 85847 The DWARF reader needed one small tweak in dwarf2_name to avoid a 85848 regression in dw2-unusual-field-names.exp. I think this is adequately 85849 explained by the comment, but basically this is a scenario that should 85850 not occur in real code, only the gdb test suite. 85851 85852 lookup_signed_typename is simplified. It used to search for two 85853 different type names, but now gdb can search just for the canonical 85854 form. 85855 85856 gdb.dwarf2/enum-type.exp needed a small tweak, because the 85857 canonicalizer turns "unsigned integer" into "unsigned int integer". 85858 It seems better here to use the correct C type name. 85859 85860 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 85861 Tested-by: Simon Marchi <simark@simark.ca> 85862 Reviewed-by: Andrew Burgess <aburgess@redhat.com> 85863 858642022-12-01 Tom Tromey <tromey@adacore.com> 85865 85866 Refactor cooked_index::do_finalize 85867 This refactors cooked_index::do_finalize, reordering an 'if' to make 85868 it a little less redundant. This change makes a subsequent patch 85869 easier to read. 85870 85871 Reviewed-by: Andrew Burgess <aburgess@redhat.com> 85872 858732022-12-01 Tom Tromey <tromey@adacore.com> 85874 85875 Remove language check from dwarf2_compute_name 85876 dwarf2_compute_name has a redundant check of the CU's language -- this 85877 is also checked in dwarf2_canonicalize_name. Removing this slightly 85878 simplifies a future patch. 85879 85880 Reviewed-by: Andrew Burgess <aburgess@redhat.com> 85881 858822022-12-01 Simon Marchi <simon.marchi@efficios.com> 85883 85884 gdb/dwarf: add some QUIT macros 85885 While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way 85886 out of GDB expanding many symtabs. GDB was busy in a loop in 85887 cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I 85888 also happened to see a spot in 85889 cooked_index_functions::expand_matching_symbols where a QUIT would be 85890 useful too, since we iterate over a potentially big number of index 85891 entries and expand CUs in the loop. Add one there too. 85892 85893 Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3 85894 Approved-By: Kevin Buettner <kevinb@redhat.com> 85895 858962022-12-01 Simon Marchi <simon.marchi@efficios.com> 85897 85898 gdb: remove prune_threads in thread_db_target::update_thread_list 85899 Pedro mentioned that this prune_threads call in 85900 thread_db_target::update_thread_list was not needed, and it was probably 85901 an oversight to leave it there in the work following commit e8032dde10b 85902 ("Push pruning old threads down to the target"). That commit changed 85903 the "find new threads" target operation to "update thread list", making 85904 the target responsible of adding new threads and removing exited 85905 threads, rather than just adding new threads. Commit e8032dde10b moved 85906 the prune_threads calls previously done in common code into each 85907 target's update_thread_list method, in order to keep the existing 85908 behavior, which is why this prune_threads call ended up there. 85909 85910 In the mean time, the linux-nat target was taught to update_thread_list, 85911 and thread_db_target::update_thread_list defers to that for any live 85912 inferior, so the prune_threads call is not needed there. Otherwise, the 85913 thread_db_target::update_thread_list implementation based on 85914 td_ta_thr_iter_p only knows how to add new threads, not how to delete 85915 exited threads, but that is only used for non-live inferiors, where 85916 threads can't exit anyway. So the prune_threads call is not needed for 85917 that case either. 85918 85919 Change-Id: I127fd4f84c25086f97853dadf34c5cec6816840d 85920 Approved-By: Pedro Alves <pedro@palves.net> 85921 859222022-12-01 H.J. Lu <hjl.tools@gmail.com> 85923 85924 opcodes: Remove i386-init.h and i386-tbl.h from HFILES 85925 i386-init.h and i386-tbl.h are generated files. There is nothing to 85926 translate. Remove them from HFILES (POTFILES). 85927 85928 * Makefile.am (HFILES): Remove i386-init.h and i386-tbl.h. 85929 * Makefile.in: Regenerated. 85930 * po/POTFILES.in: Likewise. 85931 859322022-12-01 Tom Tromey <tromey@adacore.com> 85933 85934 Avoid timeouts in gdb.compile 85935 PR compile/29541 points out that some of the C++ tests in gdb.compile 85936 will time out when the glibc debuginfo is installed. This was 85937 interfering with my hacking on gdb by making test runs extremely long, 85938 so I looked into it. 85939 85940 Internally the bug seems to be that gdb tries to convert multiple 85941 symbols named "var" via the compiler interface; one such symbol (I 85942 didn't track it down too far) causes the C++ compiler plugin to crash. 85943 85944 Unfortunately, the crash is reported as a timeout, as the gdb side of 85945 the plugin simply hangs. This seems like a bug in the plugin RPC 85946 mechanism and, worse, apparently when I wrote this stuff I didn't 85947 really consider error reporting very much at all, so gdb can't really 85948 detect failures in the first place. 85949 85950 Anyway... this patch works around the timeout by compiling a simple 85951 test that should provoke this bug, and then using "untested" if it 85952 notices a GCC crash. 85953 85954 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541 85955 859562022-12-01 Tom Tromey <tromey@adacore.com> 85957 85958 Remove obsolete check from skip_compile_feature_tests 85959 skip_compile_feature_tests checks for "Command not supported on this 85960 host", but this error was removed by commit e8d8cce6 ("Import mkdtemp 85961 gnulib module, fix mingw build"). This patch removes the obsolete 85962 test. 85963 85964 Remove one copy of skip_compile_feature_tests 85965 I noticed that there are two identical copies of 85966 skip_compile_feature_tests in the test suite. This removes one from 85967 gdb.exp, in favor of the one in compile-support.exp. 85968 859692022-12-01 Clément Chigot <chigot@adacore.com> 85970 85971 binutils: improve holes detection in .debug_loclists. 85972 The previous warnings about holes in .debug_loclists sections don't 85973 take into account the headers of each CU and could include the locviews 85974 if they precede the loclist. 85975 85976 The following warning can be triggered between two CU. 85977 ... <previous CU views> ... 85978 0000001d <End of list> 85979 85980 0000002a v000000000000000 v000000000000000 location view pair 85981 0000002c v000000000000000 v000000000000000 location view pair 85982 85983 readelf: Warning: There is a hole [0x1e - 0x2e] in .debug_loclists section. 85984 0000002e v000000000000000 v000000000000000 views at 0000002a for: 85985 ... 85986 85987 But [0x1e - 0x2a] corresponds to the CU header and [0x2a - 0x2e] are 85988 the locviews. Thus there is no hole here. 85989 85990 binutils/ChangeLog: 85991 85992 * dwarf.c (display_debug_loc): Adjust holes detections for 85993 headers and locviews. 85994 859952022-12-01 Nick Clifton <nickc@redhat.com> 85996 85997 Fix verilog output when the width is > 1. 85998 PR 25202 85999 bfd * bfd.c (VerilogDataEndianness): New variable. 86000 (verilog_write_record): Use VerilogDataEndianness, if set, to 86001 choose the endianness of the output. 86002 (verilog_write_section): Adjust the address by the data width. 86003 86004 binutils* objcopy.c (copy_object): Set VerilogDataEndianness to the 86005 endianness of the input file. 86006 (copy_main): Verifiy the value set by the --verilog-data-width 86007 option. 86008 * testsuite/binutils-all/objcopy.exp: Add tests of the new behaviour. 86009 * testsuite/binutils-all/verilog-I4.hex: New file. 86010 860112022-12-01 Jan Beulich <jbeulich@suse.com> 86012 86013 x86: rework of match_template()'s suffix checking 86014 (Ab)using i386_opcode_modifier for this has been overkill, as the logic 86015 doesn't really require the full structure. With the removal of 86016 LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf there's no good reason at all 86017 anymore to pull out such a loop invariant: We're dealing a check of a 86018 bit in the loop for a simple comparison. Do the original compares inside 86019 the loop, thus also making it easier to understand what is actually 86020 being checked. 86021 86022 x86: drop No_ldSuf 86023 With LONG_DOUBLE_MNEM_SUFFIX gone there'salso no use for No_ldSuf 86024 anymore. 86025 86026 x86/Intel: drop LONG_DOUBLE_MNEM_SUFFIX 86027 With the removal of its use for FPU insns the suffix is now finally 86028 properly misnamed. Drop its use altogether, replacing it by a separate 86029 boolean instead. 86030 86031 x86/Intel: restrict use of LONG_DOUBLE_MNEM_SUFFIX 86032 As a comment near the top of match_template() already says: We really 86033 only need this pseudo-suffix for far branch handling. Stop "deriving" it 86034 for floating point insns. (Don't bother renaming the now properly 86035 misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going 86036 to disappear anyway.) 86037 860382022-12-01 Tom de Vries <tdevries@suse.de> 86039 86040 [gdb/testsuite] Wait longer for core generation 86041 When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs 86042 file system, I run into timeouts due to core generation, like for instance: 86043 ... 86044 (gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M 86045 FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout) 86046 ... 86047 86048 Fix this by using with_timeout_factor 3 in gdb_gcore_cmd. 86049 86050 Tested on powerpc64le-linux. 86051 Approved-By: Tom Tromey <tom@tromey.com> 86052 860532022-12-01 Tom de Vries <tdevries@suse.de> 86054 86055 [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le 86056 On powerpc64le-linux, I run into: 86057 ... 86058 (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M 86059 $9 = <invalid float value>^M 86060 (gdb) FAIL: gdb.ada/float-bits.exp: print \ 86061 16llf#4000921fb54442d18469898cc51701b8# 86062 ... 86063 86064 The problem is that we're using a hex string for the 128-bit IEEE quad long 86065 double format, but the actual long double float format is: 86066 ... 86067 gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M 86068 ... 86069 86070 Fix this by using the hex string obtained by compiling test.c: 86071 ... 86072 long double a = 5.0e+25L; 86073 ... 86074 like so: 86075 ... 86076 $ gcc -mlittle test.c -c -g 86077 ... 86078 and running gdb: 86079 ... 86080 $ gdb -q -batch test.o -ex "p /x a" 86081 $1 = 0xc1e1c000000000004544adf4b7320335 86082 ... 86083 and likewise for -mbig: 86084 ... 86085 $ gdb -q -batch test.o -ex "p /x a" 86086 $1 = 0x4544adf4b7320335c1e1c00000000000 86087 ... 86088 86089 Tested on powerpc64le-linux. 86090 86091 I excercised the case of floatformat_ibm_long_double_big by 86092 using "set endian big" in the test-case. 86093 86094 Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb] 86095 Improve printing of float formats") is required. 86096 86097 PR testsuite/29816 86098 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816 86099 Approved-By: Tom Tromey <tom@tromey.com> 86100 861012022-12-01 GDB Administrator <gdbadmin@sourceware.org> 86102 86103 Automatic date update in version.in 86104 861052022-11-30 Tom de Vries <tdevries@suse.de> 86106 86107 [gdb/testsuite] Fix DUPLICATEs in s390-multiarch.exp 86108 On s390x-linux, I run into: 86109 ... 86110 DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2 86111 DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2 86112 DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2 86113 ... 86114 86115 Fix this by using with_test_prefix. 86116 86117 Tested on s390x-linux. 86118 861192022-11-30 Tom de Vries <tdevries@suse.de> 86120 86121 [gdb/testsuite] Enable gdb.arch/s390-disassembler-options.exp for --enable-targets=all 86122 On s390x-linux, I run into: 86123 ... 86124 DUPLICATE: gdb.arch/s390-disassembler-options.exp: \ 86125 show disassembler-options esa 86126 ... 86127 86128 First, reproduce this on x86_64-linux with --enable-targets=all, by replacing 86129 the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices 86130 "set architecture" "s390"'. 86131 86132 Fix the DUPLICATE by using with_test_prefix. 86133 86134 Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start. 86135 86136 Tested on x86_64-linux. 86137 861382022-11-30 Michael Matz <matz@suse.de> 86139 86140 section-select: Fix exclude-file-3 86141 this testcase wasn't correctly testing everything, it passed, even 86142 though sections from an excluded file were included. Fixing this 86143 reveals a problem in the new section selector. This fixes that as 86144 well. 86145 86146 section-select: Remove unused code 86147 walk_wild_file, hence walk_wild_section and walk_wild_section_handler 86148 aren't called with the prefix tree. Hence initialization of the latter 86149 and all potential special cases for it aren't used anymore. That also 86150 removes the need to handler_data[] and some associated helper functions. 86151 So, remove all of that. 86152 861532022-11-30 Michael Matz <matz@suse.de> 86154 86155 section-select: Implement a prefix-tree 86156 Now that we have a list of potentially matching sections per wild 86157 statement we can actually pre-fill that one by going once over all input 86158 sections and match their names against a prefix-tree that points to the 86159 potentially matching wild statements. 86160 86161 So instead of looking at all sections names for each glob for each wild 86162 statement we now look at the sections only once and then only check 86163 against those globs that have a possibility of a match at all (usually 86164 only one or two). 86165 86166 This pushes the whole section selection off the profiles. 86167 861682022-11-30 Michael Matz <matz@suse.de> 86169 86170 section-select: Completely rebuild matches 86171 The check_relocs callback (and others) might have created new 86172 section behind our back and some of them (e.g. on powerpc the 86173 "linker stubs" .got) need to come in front of all others, despite 86174 being created late (a symptom would be "TOC opt*" failing on powerpc). 86175 86176 This resets all section matches before updating for newly created 86177 sections (i.e. completely rebuilds the matches). 86178 861792022-11-30 Michael Matz <matz@suse.de> 86180 86181 section-select: Lazily resolve section matches 86182 and remember the results. Before this the order of section matching 86183 is basically: 86184 86185 foreach script-wild-stmt S 86186 foreach pattern P of S 86187 foreach inputfile I 86188 foreach section S of I 86189 match S against P 86190 if match: do action for S 86191 86192 And this process is done three or four times: for each top-level call to 86193 walk_wild() or wild(), that is: check_input_sections, lang_gc_sections, 86194 lang_find_relro_sections and of course map_input_to_output_sections. 86195 86196 So we iterate over all sections of all files many many times (for each 86197 glob). Reality is a bit more complicated (some special glob types don't 86198 need the full iteration over all sections, only over all files), but 86199 that's the gist of it. 86200 86201 For future work this shuffles the whole ordering a bit by lazily doing 86202 the matching process and memoizing results, trading a little memory for 86203 a 75% speedup of the overall section selection process. 86204 86205 This lazy resolution introduces a problem with sections added late 86206 that's corrected in the next patch. 86207 862082022-11-30 Tom Tromey <tromey@adacore.com> 86209 86210 Bounds check access to Ada task state names 86211 While looking into Ada tasking a little, I noticed that no bounds 86212 checking is done on accesses to the Ada task state names arrays. This 86213 isn't a problem currently, but if the runtime ever added numbers -- or 86214 if there was some kind of runtime corruption -- it could cause a gdb 86215 crash. 86216 86217 This patch adds range checking. It also adds a missing _() call when 86218 printing from the 'task_states' array. 86219 862202022-11-30 Tom Tromey <tromey@adacore.com> 86221 86222 Use ui_file_up in mi_interp 86223 This changes mi_interp to use ui_file_up rather than explicit 86224 management. 86225 86226 Approved-By: Simon Marchi <simon.marchi@efficios.com> 86227 862282022-11-30 Tom Tromey <tromey@adacore.com> 86229 86230 Rename fields of cli_interp_base::saved_output_files 86231 This renames the fields of cli_interp_base::saved_output_files, as 86232 requested by Simon. I tried to choose names that more obviously 86233 reflect what the field is used for. I also added a couple of 86234 comments. 86235 86236 Approved-By: Simon Marchi <simon.marchi@efficios.com> 86237 862382022-11-30 Tom de Vries <tdevries@suse.de> 86239 86240 [gdb] Improve printing of float formats 86241 Currently, on x86_64, a little endian target, I get: 86242 ... 86243 $ gdb -q -batch -ex "maint print architecture" | grep " = floatformat" 86244 gdbarch_dump: bfloat16_format = floatformat_bfloat16_big 86245 gdbarch_dump: double_format = floatformat_ieee_double_big 86246 gdbarch_dump: float_format = floatformat_ieee_single_big 86247 gdbarch_dump: half_format = floatformat_ieee_half_big 86248 gdbarch_dump: long_double_format = floatformat_i387_ext 86249 ... 86250 which suggests big endian. 86251 86252 This is due to this bit of code in pformat: 86253 ... 86254 /* Just print out one of them - this is only for diagnostics. */ 86255 return format[0]->name; 86256 ... 86257 86258 Fix this by using gdbarch_byte_order to pick the appropriate index, such that 86259 we have the more accurate: 86260 ... 86261 gdbarch_dump: bfloat16_format = floatformat_bfloat16_little 86262 gdbarch_dump: half_format = floatformat_ieee_half_little 86263 gdbarch_dump: float_format = floatformat_ieee_single_little 86264 gdbarch_dump: double_format = floatformat_ieee_double_little 86265 gdbarch_dump: long_double_format = floatformat_i387_ext 86266 ... 86267 86268 Tested on x86_64-linux. 86269 862702022-11-30 Alan Modra <amodra@gmail.com> 86271 86272 Correct ordering problem in comm-data.exp 86273 * testsuite/ld-elf/comm-data.exp: Build libcomm-data.so before 86274 attempting to read it to set ELF64. 86275 86276 regen SRC-POTFILES.in 86277 862782022-11-30 Jan Beulich <jbeulich@suse.com> 86279 86280 x86/Intel: adjustment to restricted suffix derivation 86281 In "x86/Intel: restrict suffix derivation" I think I screwed up 86282 slightly, bringing a piece of code out of sync with its comment, and 86283 resulting in a suffix potentially being derived when one isn't needed. 86284 862852022-11-30 Jan Beulich <jbeulich@suse.com> 86286 86287 x86: clean up after removal of support for gcc <= 2.8.1 86288 At the very least a comment in process_operands() is stale. Beyond that 86289 there are effectively two options: 86290 1) It is possible that FADDP and FMULP were mistakenly not marked as 86291 being in need of dealing with the compiler anomaly, and hence the 86292 respective templates weren't removed at the time when they should 86293 have been. 86294 2) It is also possible that there are indeed uses known beyond compiler 86295 generated output for these two commutative opcodes, and hence the 86296 templates need to stay. 86297 To be on the safe side assume 2: Update the comment and fold the 86298 templates into their "normal" ones (utilizing D), adjusting consuming 86299 code accordingly. 86300 86301 For FMULP also add a comment paralleling a similar one FADDP has. 86302 863032022-11-30 Jan Beulich <jbeulich@suse.com> 86304 86305 x86: drop FloatR 86306 There are just 4 templates using it, which can be easily identified by 86307 other means, as D is set only on a very limited number of FPU templates. 86308 Also move the respective conditional out of the code path taken by all 86309 "reverse match" insns (it probably should have been this way already 86310 before, to avoid the one conditional in the common case). 86311 86312 With this the templates which had FloatR dropped no longer differ from 86313 their AT&T syntax + mnemonic counterparts - the only difference is now 86314 which of the two would be recognized. For this, however, we don't need 86315 two templates - we can simply arrange the condition for setting 86316 Opcode_FloatR accordingly. 86317 863182022-11-30 Jan Beulich <jbeulich@suse.com> 86319 86320 x86: extend FPU test coverage for AT&T / Intel mnemonic differences 86321 Before touching the templates, let's ensure we actually cover things: 86322 For one FSUB{,R} and FDIV{,R} would better be tested with operands in 86323 both possible orders. And then -mmnemonic=intel wasn't tested at all. 86324 863252022-11-30 Joel Brobecker <brobecker@adacore.com> 86326 86327 src-release.sh: Fix gdb source tarball build failure due to libsframe 86328 This script was recently changed as follow: 86329 86330 | commit e619dddb3a45780ae66d762756882a3b896b617d 86331 | Date: Tue Nov 15 15:07:13 2022 -0800 86332 | Subject: src-release.sh: Add libsframe 86333 | 86334 | Add libsframe to the list of top level directories that will be included 86335 | in a release. 86336 86337 Since then, the gdb source tarball has been failing with the error 86338 below during the "make configure-host configure-target" phase: 86339 86340 | make[3]: *** No rule to make target '../libsframe/libsframe.la', 86341 | needed by 'libbfd.la'. Stop. 86342 | make[3]: Leaving directory '/tmp/gdb-public/bfd' 86343 86344 This patch fixes the issue by adding libsframe to the list of 86345 GDB_SUPPORT_DIRS, similar to what was done for BINUTILS. 86346 86347 ChangeLog: 86348 86349 * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe. 86350 863512022-11-30 GDB Administrator <gdbadmin@sourceware.org> 86352 86353 Automatic date update in version.in 86354 863552022-11-29 Tom de Vries <tdevries@suse.de> 86356 86357 [gdb/testsuite] Fix gdb.base/vla-optimized-out.exp for ppc64le 86358 On powerpc64le-linux, I run into: 86359 ... 86360 (gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla 86361 p sizeof (a)^M 86362 $2 = <optimized out>^M 86363 (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \ 86364 printed size of optimized out vla 86365 ... 86366 86367 The problem happens as follows. 86368 86369 In order to find the size of the optimized out vla, gdb needs to evaluate: 86370 ... 86371 <155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \ 86372 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1; 86373 DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; 86374 DW_OP_minus) 86375 ... 86376 86377 When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site 86378 matching the pc, but doesn't find it: 86379 ... 86380 $ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \ 86381 -ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)" 86382 Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34. 86383 86384 Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34 86385 34 } 86386 DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main 86387 $1 = <optimized out> 86388 .... 86389 86390 The call site lookup fails because the call site label .LVL4: 86391 ... 86392 bl f1 # 11 *call_value_nonlocal_aixdi [length = 8] 86393 nop 86394 .LVL4: 86395 ... 86396 is not placed directly after the bl insn. This is gcc PR target/107909. 86397 86398 However, after manually fixing the .s file we have instead: 86399 ... 86400 Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main 86401 $1 = <optimized out> 86402 ... 86403 due to the fact that the call site has no call site parameters. 86404 86405 The call site does have a reference to the corresponding function f1, with 86406 parameter i, for which we find location list entries: 86407 ... 86408 0037 1000067c 10000680 (DW_OP_reg3 (r3)) 86409 004a 10000680 10000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); 86410 DW_OP_stack_value) 86411 ... 86412 and we could use the fact that the current pc is in the 1000067c-10000680 86413 range, and that that the range starts at the start of the function, to deduce 86414 that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3). 86415 But that's a non-trivial enhancement, filed as enhancement PR symtab/29836. 86416 86417 Fix this by allowing <optimized out> for target powerpc and the gcc compiler. 86418 86419 Reviewed-By: Carl Love <cel@us.ibm.com> 86420 Tested-By: Carl Love <cel@us.ibm.com> 86421 PR testsuite/29813 86422 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813 86423 864242022-11-29 Simon Marchi <simon.marchi@polymtl.ca> 86425 86426 gdb/testsuite: make gdb_unload use gdb_test_multiple 86427 In the failure seen by Philippe here: 86428 86429 https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/ 86430 86431 gdb_unload crashed GDB, leaving no trace in the test results. Change it 86432 to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I 86433 think it is good practice anyway. 86434 86435 Make it return the result of gdb_test_multiple directly, change 86436 gdb.python/py-objfile.exp accordingly. 86437 86438 Change gdb.base/endian.exp as well to avoid duplicate test names. 86439 86440 Change gdb.base/gnu-debugdata.exp to avoid recording a test result, 86441 since gdb_unload does it already now. 86442 86443 Change-Id: I59a1e4947691330797e6ce23277942547c437a48 86444 Approved-By: Tom de Vries <tdevries@suse.de> 86445 864462022-11-29 Simon Marchi <simon.marchi@polymtl.ca> 86447 86448 gdb/testsuite: make gdb_test_multiple return immediately if send_gdb fails 86449 In the failure seen by Philippe here: 86450 86451 https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/ 86452 86453 ... the testsuite only outputs PASSes, and an ERROR, resulting from an 86454 uncaught exception. This is a bit sneaky, because ERRORs are not 86455 reported in the test summary. In certain circumstances, it can be easy 86456 to miss. 86457 86458 Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But 86459 this is only if it manages to send the command, and it's that command 86460 that crashes GDB. Here, the ERROR is due to the fact that GDB had 86461 already crashed by the time we entered gdb_test_multiple and tried to 86462 send a command. GDB was crashed by the previous "file" command, sent by 86463 gdb_unload. Because gdb_unload uses bare expect, it didn't record a 86464 test failure when crashing GDB (this will be addressed separately). 86465 86466 In this patch, I propose to make gdb_test_multiple call unresolved 86467 directly and return -1 send_gdb fails. This way, if GDB is already 86468 crashed by the time we enter gdb_test_multiple, it will leave a trace in 86469 the test results in the form of an UNRESOLVED. It will also spare us 86470 the not-so-useful-in-my-opinion TCL backtrace. 86471 86472 Before, it looks like: 86473 86474 ERROR: Couldn't send python print(objfile.filename) to GDB. 86475 ERROR: : spawn id exp9 not open 86476 while executing 86477 "expect { 86478 -i exp9 -timeout 10 86479 -re ".*A problem internal to GDB has been detected" { 86480 fail "$message (GDB internal error)" 86481 gdb_internal_error..." 86482 ("uplevel" body line 1) 86483 invoked from within 86484 "uplevel $body" NONE : spawn id exp9 not open 86485 86486 And after: 86487 86488 Couldn't send python print(objfile.filename) to GDB. 86489 UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded 86490 86491 Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba 86492 Approved-By: Tom de Vries <tdevries@suse.de> 86493 864942022-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 86495 86496 gprofng: remove unused gprofng/src/DbeSession.cc.1 86497 864982022-11-29 Max Filippov <jcmvbkbc@gmail.com> 86499 86500 xtensa: allow dynamic configuration 86501 Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields 86502 of a structure returned from the xtensa_get_config_v<x> function call. 86503 Define that structure and fill it with default parameter values 86504 specified in the include/xtensa-config.h. 86505 Define reusable function xtensa_load_config that tries to load 86506 configuration and return an address of an exported object from it. 86507 Define functions xtensa_get_config_v{1,2} that use xtensa_load_config 86508 to get structures xtensa_config_v{1,2}, either dynamically configured 86509 or the default. 86510 86511 bfd/ 86512 * Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Append 86513 xtensa-dynconfig.c. 86514 * Makefile.in: Regenerate. 86515 * configure: Regenerate. 86516 * configure.ac (xtensa_elf32_be_vec, xtensa_elf32_le_vec): Add 86517 xtensa-dynconfig.lo to the tb. 86518 * elf32-xtensa.c (xtensa-config.h): Replace #include with 86519 xtensa-dynconfig.h. 86520 (XSHAL_ABI, XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove 86521 definitions. 86522 * xtensa-dynconfig.c: New file. 86523 * xtensa-isa.c (xtensa-dynconfig.h): New #include. 86524 (xtensa_get_modules): New function. 86525 (xtensa_isa_init): Call xtensa_get_modules instead of taking 86526 address of global xtensa_modules. 86527 86528 gas/ 86529 * config/tc-xtensa.c (xtensa-config.h): Replace #include with 86530 xtensa-dynconfig.h. 86531 (XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0, XTENSA_MARCH_EARLIEST): 86532 Remove definitions. 86533 * config/tc-xtensa.h (xtensa-config.h): Replace #include with 86534 xtensa-dynconfig.h. 86535 * config/xtensa-relax.c (xtensa-config.h): Replace #include with 86536 xtensa-dynconfig.h. 86537 (XCHAL_HAVE_WIDE_BRANCHES): Remove definition. 86538 86539 include/ 86540 * xtensa-dynconfig.h: New file. 86541 86542 ld/ 86543 * emultempl/xtensaelf.em (xtensa-config.h): Replace #include 86544 with xtensa-dynconfig.h. 86545 (XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove definitions. 86546 865472022-11-29 GDB Administrator <gdbadmin@sourceware.org> 86548 86549 Automatic date update in version.in 86550 865512022-11-28 Andrew Burgess <aburgess@redhat.com> 86552 86553 gdb/testsuite: remove use of then keyword from library files 86554 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86555 still a bunch of places in the testsuite where we make use of the 86556 'then' keyword, and sometimes these get copies into new tests, which 86557 just spreads poor practice. 86558 86559 This commit removes all use of the 'then' keyword from the testsuite 86560 library files (in boards/, config/, and lib/). Previous commits have 86561 removed all uses of the 'then' keyword from the test script files, 86562 this commit just cleans up the library files. 86563 86564 There should be no changes in what is tested after this commit. 86565 865662022-11-28 Andrew Burgess <aburgess@redhat.com> 86567 86568 gdb/testsuite: remove use of then keyword from gdb.*/*.exp scripts 86569 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86570 still a bunch of places in the testsuite where we make use of the 86571 'then' keyword, and sometimes these get copies into new tests, which 86572 just spreads poor practice. 86573 86574 This commit removes all use of the 'then' keyword from the remaining 86575 gdb.*/*.exp scripts. Previous commits have done the bulk of this 86576 removal, this commit just handles the remaining directories that each 86577 contain a low number of instances. 86578 86579 There should be no changes in what is tested after this commit. 86580 865812022-11-28 Andrew Burgess <aburgess@redhat.com> 86582 86583 gdb/testsuite: remove use of then keyword from gdb.multi/*.exp 86584 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86585 still a bunch of places in the testsuite where we make use of the 86586 'then' keyword, and sometimes these get copies into new tests, which 86587 just spreads poor practice. 86588 86589 This commit removes all use of the 'then' keyword from the gdb.multi/ 86590 test script directory. 86591 86592 There should be no changes in what is tested after this commit. 86593 865942022-11-28 Andrew Burgess <aburgess@redhat.com> 86595 86596 gdb/testsuite: remove use of then keyword from gdb.fortran/*.exp 86597 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86598 still a bunch of places in the testsuite where we make use of the 86599 'then' keyword, and sometimes these get copies into new tests, which 86600 just spreads poor practice. 86601 86602 This commit removes all use of the 'then' keyword from the gdb.fortran/ 86603 test script directory. 86604 86605 There should be no changes in what is tested after this commit. 86606 866072022-11-28 Andrew Burgess <aburgess@redhat.com> 86608 86609 gdb/testsuite: remove use of then keyword from gdb.disasm/*.exp 86610 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86611 still a bunch of places in the testsuite where we make use of the 86612 'then' keyword, and sometimes these get copies into new tests, which 86613 just spreads poor practice. 86614 86615 This commit removes all use of the 'then' keyword from the gdb.disasm/ 86616 test script directory. 86617 86618 There should be no changes in what is tested after this commit. 86619 866202022-11-28 Andrew Burgess <aburgess@redhat.com> 86621 86622 gdb/testsuite: remove use of then keyword from gdb.reverse/*.exp 86623 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86624 still a bunch of places in the testsuite where we make use of the 86625 'then' keyword, and sometimes these get copies into new tests, which 86626 just spreads poor practice. 86627 86628 This commit removes all use of the 'then' keyword from the gdb.reverse/ 86629 test script directory. 86630 86631 There should be no changes in what is tested after this commit. 86632 866332022-11-28 Andrew Burgess <aburgess@redhat.com> 86634 86635 gdb/testsuite: remove use of then keyword from gdb.trace/*.exp 86636 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86637 still a bunch of places in the testsuite where we make use of the 86638 'then' keyword, and sometimes these get copies into new tests, which 86639 just spreads poor practice. 86640 86641 This commit removes all use of the 'then' keyword from the gdb.trace/ 86642 test script directory. 86643 86644 There should be no changes in what is tested after this commit. 86645 866462022-11-28 Andrew Burgess <aburgess@redhat.com> 86647 86648 gdb/testsuite: remove use of then keyword from gdb.threads/*.exp 86649 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86650 still a bunch of places in the testsuite where we make use of the 86651 'then' keyword, and sometimes these get copies into new tests, which 86652 just spreads poor practice. 86653 86654 This commit removes all use of the 'then' keyword from the gdb.threads/ 86655 test script directory. 86656 86657 There should be no changes in what is tested after this commit. 86658 866592022-11-28 Andrew Burgess <aburgess@redhat.com> 86660 86661 gdb/testsuite: remove use of then keyword from gdb.python/*.exp 86662 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86663 still a bunch of places in the testsuite where we make use of the 86664 'then' keyword, and sometimes these get copies into new tests, which 86665 just spreads poor practice. 86666 86667 This commit removes all use of the 'then' keyword from the gdb.python/ 86668 test script directory. 86669 86670 There should be no changes in what is tested after this commit. 86671 866722022-11-28 Andrew Burgess <aburgess@redhat.com> 86673 86674 gdb/testsuite: remove use of then keyword from gdb.cp/*.exp 86675 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86676 still a bunch of places in the testsuite where we make use of the 86677 'then' keyword, and sometimes these get copies into new tests, which 86678 just spreads poor practice. 86679 86680 This commit removes all use of the 'then' keyword from the gdb.cp/ 86681 test script directory. 86682 86683 There should be no changes in what is tested after this commit. 86684 866852022-11-28 Andrew Burgess <aburgess@redhat.com> 86686 86687 gdb/testsuite: remove use of then keyword from gdb.arch/*.exp 86688 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86689 still a bunch of places in the testsuite where we make use of the 86690 'then' keyword, and sometimes these get copies into new tests, which 86691 just spreads poor practice. 86692 86693 This commit removes all use of the 'then' keyword from the gdb.arch/ 86694 test script directory. 86695 86696 There should be no changes in what is tested after this commit. 86697 866982022-11-28 Andrew Burgess <aburgess@redhat.com> 86699 86700 gdb/testsuite: remove use of then keyword from gdb.base/*.exp 86701 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86702 still a bunch of places in the testsuite where we make use of the 86703 'then' keyword, and sometimes these get copies into new tests, which 86704 just spreads poor practice. 86705 86706 This commit removes all use of the 'then' keyword from the gdb.base/ 86707 test script directory. 86708 86709 There should be no changes in what is tested after this commit. 86710 867112022-11-28 Andrew Burgess <aburgess@redhat.com> 86712 86713 gdb/testsuite: remove use of then keyword from gdb.ada/*.exp 86714 The canonical form of 'if' in modern TCL is 'if {} {}'. But there's 86715 still a bunch of places in the testsuite where we make use of the 86716 'then' keyword, and sometimes these get copies into new tests, which 86717 just spreads poor practice. 86718 86719 This commit removes all use of the 'then' keyword from the gdb.ada/ 86720 test script directory. 86721 86722 There should be no changes in what is tested after this commit. 86723 867242022-11-28 Andrew Burgess <aburgess@redhat.com> 86725 86726 gdb/testsuite: remove DOS line endings from a test script 86727 The gdb.fortran/nested-funcs.exp test script has DOS line endings. I 86728 can see no reason why this script needs DOS line endings. 86729 86730 Convert to UNIX line endings. 86731 86732 There should be no change in what is tested after this commit. 86733 867342022-11-28 Tom Tromey <tromey@adacore.com> 86735 86736 Don't let gdb_stdlog use pager 86737 When using the "set logging" commands, cli_interp_base::set_logging 86738 will send gdb_stdlog output (among others) to the tee it makes for 86739 gdb_stdout. However, this has the side effect of also causing logging 86740 to use the pager. This is PR gdb/29787. 86741 86742 This patch fixes the problem by keeping stderr and stdlog separate 86743 from stdout, preserving the rule that only gdb_stdout should page. 86744 86745 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29787 86746 867472022-11-28 Tom Tromey <tromey@adacore.com> 86748 86749 Don't let tee_file own a stream 86750 Right now, tee_file owns the second stream it writes to. This is done 86751 for the convenience of the users. In a subsequent patch, this will no 86752 longer be convenient, so this patch moves the responsibility for 86753 ownership to the users of tee_file. 86754 86755 Remove 'saved_output' global 86756 CLI redirect uses a global variable, 'saved_output'. However, globals 86757 are generally bad, and there is no need for this one -- it can be a 86758 member of cli_interp_base. This patch makes this change. 86759 867602022-11-28 Hannes Domani <ssbssa@yahoo.de> 86761 86762 Remove no longer used jump label 86763 The out label is unused since wait_for_debug_event is in a different thread. 86764 86765 Actually set m_is_async to current async mode 86766 Looks like this was missed in the async mode implementation. 86767 867682022-11-28 Hannes Domani <ssbssa@yahoo.de> 86769 86770 Don't use auto for lambda parameter 86771 Older gcc versions (here 4.9.2) can't handle auto for a lambda parameter: 86772 86773 ../../gdb/windows-nat.c: In member function 'void windows_nat_target::delete_thread(ptid_t, DWORD, bool)': 86774 ../../gdb/windows-nat.c:629:12: error: use of 'auto' in lambda parameter declaration only available with -std=c++1y or -std=gnu++1y [-Werror] 86775 [=] (auto &th) 86776 ^ 86777 867782022-11-28 Hannes Domani <ssbssa@yahoo.de> 86779 86780 Fix calling convention of thread entry point 86781 For i686 the CreateThread entry point function needs the WINAPI (stdcall) 86782 calling convention: 86783 86784 ../../gdb/windows-nat.c: In constructor 'windows_nat_target::windows_nat_target()': 86785 ../../gdb/windows-nat.c:450:56: error: invalid user-defined conversion from 'windows_nat_target::windows_nat_target()::<lambda(LPVOID)>' to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} [-fpermissive] 86786 450 | HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr); 86787 | ^~ 86788 ../../gdb/windows-nat.c:444:13: note: candidate is: 'constexpr windows_nat_target::windows_nat_target()::<lambda(LPVOID)>::operator DWORD (*)(LPVOID)() const' (near match) 86789 444 | auto fn = [] (LPVOID self) -> DWORD 86790 | ^ 86791 ../../gdb/windows-nat.c:444:13: note: no known conversion from 'DWORD (*)(LPVOID)' {aka 'long unsigned int (*)(void*)'} to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} 86792 86793 Since it's not possible to change the calling convention of a lambda, I've 86794 moved it to a separate function. 86795 867962022-11-28 Andrew Burgess <aburgess@redhat.com> 86797 86798 gdb: mark disassembler function callback types as noexcept 86799 In disasm.h we define a set of types that are used by the various 86800 disassembler classes to hold callback functions before passing the 86801 callbacks into libopcodes. 86802 86803 Because libopcodes is C code, and on some (many?) targets, C code is 86804 compiled without exception support, it is important that GDB not try 86805 to throw an exception over libopcode code. 86806 86807 In the previous commit all the existing callbacks were marked as 86808 noexcept, however, this doesn't protect us from a future change to GDB 86809 either adding a new callback that is not noexcept, or removing the 86810 noexcept keyword from an existing callback. 86811 86812 In this commit I mark all the callback types as noexcept. This means 86813 that GDB's disassembler classes will no longer compile if we try to 86814 pass a callback that is not marked as noexcept. 86815 86816 At least, that's the idea. Unfortunately, it's not that easy. 86817 86818 Before C++17, the noexcept keyword on a function typedef would be 86819 ignored, thus: 86820 86821 using func_type = void (*) (void) noexcept; 86822 86823 void 86824 a_func () 86825 { 86826 throw 123; 86827 } 86828 86829 void 86830 some_func (func_type f) 86831 { 86832 f (); 86833 } 86834 86835 int 86836 main () 86837 { 86838 some_func (a_func); 86839 return 0; 86840 } 86841 86842 Will compile just fine for C++11 and C++14 with GCC. Clang on the 86843 other hand complains that 'noexcept' should not appear on function 86844 types, but then does appear to correctly complain that passing a_func 86845 is a mismatch in the set of exceptions that could be thrown. 86846 86847 Switching to C++17 and both GCC and Clang correctly point out that 86848 passing a_func is an invalid conversion relating to the noexcept 86849 keyword. Changing a_func to: 86850 86851 void 86852 a_func () noexcept 86853 { /* Nothing. */ } 86854 86855 And for C++17 both GCC and Clang compile this just fine. 86856 86857 My conclusion then is that adding the noexcept keyword to the function 86858 types is pointless while GDB is not compiled as C++17, and silencing 86859 the warnings would require us to jump through a bunch of hoops. 86860 86861 And so, in this commit, I define a macro LIBOPCODE_CALLBACK_NOEXCEPT, 86862 this macro expands to noexcept when compiling for C++17, but otherwise 86863 expands to nothing. I then add this macro to the function types. 86864 86865 I've compiled GDB as the default C++11 and also forced the compile to 86866 C++17. When compiling as C++17 I spotted a few additional places 86867 where callbacks needed to be marked noexcept (these fixes were merged 86868 into the previous commit, but this confirmed to be that the macro is 86869 working as expected). 86870 868712022-11-28 Andrew Burgess <aburgess@redhat.com> 86872 86873 gdb/disasm: mark functions passed to the disassembler noexcept 86874 While working on another patch, Simon pointed out that GDB could be 86875 improved by marking the functions passed to the disassembler as 86876 noexcept. 86877 86878 https://sourceware.org/pipermail/gdb-patches/2022-October/193084.html 86879 86880 The reason this is important is the on some hosts, libopcodes, being C 86881 code, will not be compiled with support for handling exceptions. As 86882 such, an attempt to throw an exception over libopcodes code will cause 86883 GDB to terminate. 86884 86885 See bug gdb/29712 for an example of when this happened. 86886 86887 In this commit all the functions that are passed to the disassembler, 86888 and which might be used as callbacks by libopcodes are marked 86889 noexcept. 86890 86891 Ideally, I would have liked to change these typedefs: 86892 86893 using read_memory_ftype = decltype (disassemble_info::read_memory_func); 86894 using memory_error_ftype = decltype (disassemble_info::memory_error_func); 86895 using print_address_ftype = decltype (disassemble_info::print_address_func); 86896 using fprintf_ftype = decltype (disassemble_info::fprintf_func); 86897 using fprintf_styled_ftype = decltype (disassemble_info::fprintf_styled_func); 86898 86899 which are declared in disasm.h, as including the noexcept keyword. 86900 However, when I tried this, I ran into this warning/error: 86901 86902 In file included from ../../src/gdb/disasm.c:25: 86903 ../../src/gdb/disasm.h: In constructor ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’: 86904 ../../src/gdb/disasm.h:116:3: error: mangled name for ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type] 86905 116 | gdb_printing_disassembler (struct gdbarch *gdbarch, 86906 | ^~~~~~~~~~~~~~~~~~~~~~~~~ 86907 86908 So I've left that change out. This does mean that if somebody adds a 86909 new use of the disassembler classes in the future, and forgets to mark 86910 the callbacks as noexcept, this will compile fine. We'll just have to 86911 manually check for that during review. 86912 869132022-11-28 Andrew Burgess <aburgess@redhat.com> 86914 86915 gdb/python: avoid throwing an exception over libopcodes code 86916 Bug gdb/29712 identifies a problem with the Python disassembler API. 86917 In some cases GDB will try to throw an exception through the 86918 libopcodes disassembler code, however, not all targets include 86919 exception unwind information when compiling C code, for targets that 86920 don't include this information GDB will terminate when trying to pass 86921 the exception through libopcodes. 86922 86923 To explain what GDB is trying to do, consider the following trivial 86924 use of the Python disassembler API: 86925 86926 class ExampleDisassembler(gdb.disassembler.Disassembler): 86927 86928 class MyInfo(gdb.disassembler.DisassembleInfo): 86929 def __init__(self, info): 86930 super().__init__(info) 86931 86932 def read_memory(self, length, offset): 86933 return super().read_memory(length, offset) 86934 86935 def __init__(self): 86936 super().__init__("ExampleDisassembler") 86937 86938 def __call__(self, info): 86939 info = self.MyInfo(info) 86940 return gdb.disassembler.builtin_disassemble(info) 86941 86942 This disassembler doesn't add any value, it defers back to GDB to do 86943 all the actual work, but it serves to allow us to discuss the problem. 86944 86945 The problem occurs when a Python exception is raised by the 86946 MyInfo.read_memory method. The MyInfo.read_memory method is called 86947 from the C++ function gdbpy_disassembler::read_memory_func. The C++ 86948 stack at the point this function is called looks like this: 86949 86950 #0 gdbpy_disassembler::read_memory_func (memaddr=4198805, buff=0x7fff9ab9d2a8 "\220ӹ\232\377\177", len=1, info=0x7fff9ab9d558) at ../../src/gdb/python/py-disasm.c:510 86951 #1 0x000000000104ba06 in fetch_data (info=0x7fff9ab9d558, addr=0x7fff9ab9d2a9 "ӹ\232\377\177") at ../../src/opcodes/i386-dis.c:305 86952 #2 0x000000000104badb in ckprefix (ins=0x7fff9ab9d100) at ../../src/opcodes/i386-dis.c:8571 86953 #3 0x000000000104e28e in print_insn (pc=4198805, info=0x7fff9ab9d558, intel_syntax=-1) at ../../src/opcodes/i386-dis.c:9548 86954 #4 0x000000000104f4d4 in print_insn_i386 (pc=4198805, info=0x7fff9ab9d558) at ../../src/opcodes/i386-dis.c:9949 86955 #5 0x00000000004fa7ea in default_print_insn (memaddr=4198805, info=0x7fff9ab9d558) at ../../src/gdb/arch-utils.c:1033 86956 #6 0x000000000094fe5e in i386_print_insn (pc=4198805, info=0x7fff9ab9d558) at ../../src/gdb/i386-tdep.c:4072 86957 #7 0x0000000000503d49 in gdbarch_print_insn (gdbarch=0x5335560, vma=4198805, info=0x7fff9ab9d558) at ../../src/gdb/gdbarch.c:3351 86958 #8 0x0000000000bcc8c6 in disasmpy_builtin_disassemble (self=0x7f2ab07f54d0, args=0x7f2ab0789790, kw=0x0) at ../../src/gdb/python/py-disasm.c:324 86959 86960 ### ... snip lots of frames as we pass through Python itself ... 86961 86962 #22 0x0000000000bcd860 in gdbpy_print_insn (gdbarch=0x5335560, memaddr=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/python/py-disasm.c:783 86963 #23 0x00000000008995a5 in ext_lang_print_insn (gdbarch=0x5335560, address=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/extension.c:939 86964 #24 0x0000000000741aaa in gdb_print_insn_1 (gdbarch=0x5335560, vma=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/disasm.c:1078 86965 #25 0x0000000000741bab in gdb_disassembler::print_insn (this=0x7fff9ab9e3c0, memaddr=0x401195, branch_delay_insns=0x0) at ../../src/gdb/disasm.c:1101 86966 86967 So gdbpy_disassembler::read_memory_func is called from the libopcodes 86968 disassembler to read memory, this C++ function then calls into user 86969 supplied Python code to do the work. 86970 86971 If the user supplied Python code raises an gdb.MemoryError exception 86972 indicating the memory read failed, this is fine. The C++ code 86973 converts this exception back into a return value that libopcodes can 86974 understand, and returns to libopcodes. 86975 86976 However, if the user supplied Python code raises some other exception, 86977 what we want is for this exception to propagate through GDB and appear 86978 as if raised by the call to gdb.disassembler.builtin_disassemble. To 86979 achieve this, when gdbpy_disassembler::read_memory_func spots an 86980 unknown Python exception, we must pass the information about this 86981 exception from frame #0 to frame #8 in the above backtrace. Frame #8 86982 is the C++ implementation of gdb.disassembler.builtin_disassemble, and 86983 so it is this function that we want to re-raise the unknown Python 86984 exception, so the user can, if they want, catch the exception in their 86985 code. 86986 86987 The previous mechanism by which the exception was passed was to pack 86988 the details of the Python exception into a C++ exception, then throw 86989 the exception from frame #0, and catch the exception in frame #8, 86990 unpack the details of the Python exception, and re-raise it. 86991 86992 However, this relies on the exception passing through frames #1 to #7, 86993 some of which are in libopcodes, which is C code, and so, might not be 86994 compiled with exception support. 86995 86996 This commit proposes an alternative solution that does not rely on 86997 throwing a C++ exception. 86998 86999 When we spot an unhandled Python exception in frame #0, we will store 87000 the details of this exception within the gdbpy_disassembler object 87001 currently in use. Then we return to libopcodes a value indicating 87002 that the memory_read failed. 87003 87004 libopcodes will now continue to disassemble as though that memory read 87005 failed (with one special case described below), then, when we 87006 eventually return to disasmpy_builtin_disassemble we check to see if 87007 there is an exception stored in the gdbpy_disassembler object. If 87008 there is then this exception can immediately be installed, and then we 87009 return back to Python, when the user will be able to catch the 87010 exception. 87011 87012 There is one extra change in gdbpy_disassembler::read_memory_func. 87013 After the first call that results in an exception being stored on the 87014 gdbpy_disassembler object, any future calls to the ::read_memory_func 87015 function will immediately return as if the read failed. This avoids 87016 any additional calls into user supplied Python code. 87017 87018 My thinking here is that should the first call fail with some unknown 87019 error, GDB should not keep trying with any additional calls. This 87020 maintains the illusion that the exception raised from 87021 MyInfo.read_memory is immediately raised by 87022 gdb.disassembler.builtin_disassemble. I have no tests for this change 87023 though - to trigger this issue would rely on a libopcodes disassembler 87024 that will try to read further memory even after the first failed 87025 read. I'm not aware of any such disassembler that currently does 87026 this, but that doesn't mean such a disassembler couldn't exist in the 87027 future. 87028 87029 With this change in place the gdb.python/py-disasm.exp test should now 87030 pass on AArch64. 87031 87032 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29712 87033 87034 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87035 870362022-11-28 Tom Tromey <tom@tromey.com> 87037 87038 Remove reset_ecs and execution_control_state::reset 87039 I noticed that execution_control_state has a 'reset' method, and 87040 there's also a 'reset_ecs' function that calls it. This patch cleans 87041 this area up a little by adding a parameter to the constructor and (a 87042 change Simon suggested) removing the reset method. Some extraneous 87043 variables are also removed, like: 87044 87045 - struct execution_control_state ecss; 87046 - struct execution_control_state *ecs = &ecss; 87047 87048 Here 'ecs' is never changed, so this patch removes it entirely in 87049 favor of just using the object everywhere. 87050 87051 Regression tested on x86-64 Fedora 34. 87052 87053 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87054 870552022-11-28 Andrew Burgess <aburgess@redhat.com> 87056 87057 gdb: relax requirement for the map_failed stap probe to be present 87058 From glibc 2.35 and later, the "map_failed" stap probe is no longer 87059 included in glibc. The removal of the probe looks like an accident, 87060 but it was caused by a glibc commit which meant that the "map_failed" 87061 probe could no longer be reached; the compiler then helpfully 87062 optimised out the probe. 87063 87064 In GDB, in solib-svr4.c, we have a list of probes that we look for 87065 related to the shared library loading detection. If any of these 87066 probes are missing then GDB will fall back to the non-probe based 87067 mechanism for detecting shared library loading. The "map_failed" 87068 probe is include in the list of required probes. 87069 87070 This means that on glibc 2.35 (or later) systems, GDB is going to 87071 always fall back to the non-probes based mechanism for detecting 87072 shared library loading. 87073 87074 I raised a glibc bug to discuss this issue: 87075 87076 https://sourceware.org/bugzilla/show_bug.cgi?id=29818 87077 87078 But, whatever the ultimate decision from the glibc team, given there 87079 are version of glibc in the wild without the "map_failed" probe, we 87080 probably should update GDB to handle this situation. 87081 87082 The "map_failed" probe is already a little strange, very early 87083 versions of glibc didn't include this probe, so, in some cases, if 87084 this probe is missing GDB is happy to ignore it. This is fine, the 87085 action associated with this probe inside GDB is DO_NOTHING, this means 87086 the probe isn't actually required in order for GDB to correctly detect 87087 the loading of shared libraries. 87088 87089 In this commit I propose changing the rules so that any probe whose 87090 action is DO_NOTHING, is optional. 87091 87092 There is one possible downside to this change, and that concerns 'set 87093 stop-on-solib-events on'. If a probe is removed from glibc, but the 87094 old style breakpoint based mechanism is still in place within glibc 87095 for that same event, then GDB will stop when using the old style 87096 non-probe based mechanism, but not when using the probes based 87097 mechanism. 87098 87099 For the map_failed case this is not a problem, both the map_failed 87100 probe, and the call to the old style breakpoint location were 87101 optimised out, and so neither event (probes based, or breakpoint 87102 based) will trigger. This would only become an issue if glibc removed 87103 a probe, but left the breakpoint in place (this would almost certainly 87104 be a bug in glibc). 87105 87106 For now, I'm proposing that we just don't worry about this. Because 87107 some probes have actions that are not DO_NOTHING, then we know the 87108 user will always seem _some_ stops when a shared library is 87109 loaded/unloaded, and (I'm guessing), in most cases, that's all they 87110 care about. I figure when someone complains then we can figure out 87111 what the right solution is then. 87112 87113 With this commit in place, then, when using a glibc 2.35 or later 87114 system, GDB will once again use the stap probes for shared library 87115 detection. 87116 87117 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 87118 871192022-11-28 Tom de Vries <tdevries@suse.de> 87120 87121 [gdb/testsuite] Require hw watchpoint in gdb.ada/task_watch.exp 87122 On powerpc64le-linux I run into: 87123 ... 87124 (gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint 87125 watch -location value task 3^M 87126 Watchpoint 2: -location value^M 87127 (gdb) PASS: gdb.ada/task_watch.exp: watch -location value task 3 87128 continue^M 87129 Continuing.^M 87130 [Thread 0x7ffff7ccf170 (LWP 65550) exited]^M 87131 [Thread 0x7ffff7abf170 (LWP 65551) exited]^M 87132 FAIL: gdb.ada/task_watch.exp: continue to watchpoint (timeout) 87133 ... 87134 87135 On x86_64-linux (where the test-case passes), a hardware watchpoint is used: 87136 ... 87137 (gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint 87138 watch -location value task 3^M 87139 Hardware watchpoint 2: -location value^M 87140 ... 87141 and after forcing "set can-use-hw-watchpoints 0" we can intermittently 87142 reproduce the same failure. 87143 87144 In the gdb documentation related to watchpoints in multi-threaded programs, we 87145 read: 87146 ... 87147 Warning: In multi-threaded programs, software watchpoints have only limited 87148 usefulness. If GDB creates a software watchpoint, it can only watch the value 87149 of an expression in a single thread. If you are confident that the expression 87150 can only change due to the current thread’s activity (and if you are also 87151 confident that no other thread can become current), then you can use software 87152 watchpoints as usual. However, GDB may not notice when a non-current thread’s 87153 activity changes the expression. (Hardware watchpoints, in contrast, watch an 87154 expression in all threads.) 87155 ... 87156 87157 Since the ada task construct is mapped onto threads, it seems that the 87158 same limitation holds for tasks. 87159 87160 Fix this by using skip_hw_watchpoint_tests. 87161 87162 Tested on powerpc64-linux. 87163 Tested-By: Carl Love <cel@us.ibm.com> 87164 871652022-11-28 Tom de Vries <tdevries@suse.de> 87166 87167 [gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp for ppc64le 87168 On powerpc64le-linux, with test-case gdb.ada/out_of_line_in_inlined.exp I run 87169 into: 87170 ... 87171 (gdb) run ^M 87172 Starting program: foo_o224_021-all ^M 87173 ^M 87174 Breakpoint 1, 0x0000000010002f48 in foo_o224_021.child1.child2 (s=...) at \ 87175 foo_o224_021.adb:24^M 87176 24 function Child2 (S : String) return Boolean is -- STOP^M 87177 (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \ 87178 run to foo_o224_021.child1.child2 87179 ... 87180 87181 The breakpoint is correctly set at the local entry point, and given that the 87182 local entry point doesn't correspond to a line number entry, the instruction 87183 address of the breakpoint is shown. 87184 87185 The problem is that test-case doesn't expect the breakpoint address. 87186 87187 Fix this by allowing the breakpoint address to occur. 87188 87189 Tested on powerpc64le-linux. 87190 871912022-11-28 Michael Matz <matz@suse.de> 87192 87193 Only use wild_sort_fast 87194 there's no reason why the tree-based variant can't always be used 87195 when sorting is required, it merely needs to also support filename 87196 sorting and have a fast path for insertion at end (aka rightmost tree 87197 leaf). 87198 87199 The filename sorting isn't tested anywhere and the only scripttempl 87200 that uses it is avr (for 'SORT(*)(.ctors)'), and I believe even there it 87201 was a mistake. Either way, this adds a testcase for filename sorting as 87202 well. 87203 87204 Then the non-BST based sorting can be simplified to only support 87205 the fast case of no sorting required at all (at the same time renaming 87206 the two variants to _sort and _nosort). 87207 872082022-11-28 Michael Matz <matz@suse.de> 87209 87210 Special case more simple patterns 87211 fnmatch is slow, so avoiding it in more cases is good. This implements 87212 a more generic version of match_simple_wild which needs some 87213 pre-processing of patterns. In particular it supports patterns of the 87214 form PREFIX*SUFFIX (where all parts are optional), i.e. a super set of 87215 what's handled now. Most section matchers of this form and hence don't 87216 need any calls to fnmatch anymore. 87217 87218 We retain the implementation of match_simple_wild for the filename 87219 matchers (they aren't called often enough to matter). 87220 872212022-11-28 Simon Marchi <simon.marchi@polymtl.ca> 87222 87223 gdb/testsuite: fail if gdb_start_cmd fails 87224 I broke gdb.ada/start.exp, and did not notice it, because it outputs an 87225 UNTESTED if gdb_start_cmd fails. I don't really see when start would 87226 fail and it's not a problem that should be looked at. Change all spots 87227 that call untested after a gdb_start_cmd failure, use fail instead. 87228 87229 Doing so caused some failures with the native-gdbserver board. Some 87230 tests that use "start" were relying on the fact that start would fail 87231 with that board to just return with "untested". Change them to add an 87232 early return if use_gdb_stub returns true. 87233 87234 Some gdb.pascal tests also failed with native-gdbserver, because they 87235 did use gdb_start_cmd to start the inferior, for no good reason. 87236 Convert them to use runto_main instead, which does the right thing if 87237 the target is a stub. 87238 87239 A further refactoring could be to make gdb_start_cmd match the expected 87240 breakpoint hit and the prompt, which it doesn't do currently (it leaves 87241 that to the callers, but not all of them do). 87242 87243 Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007 87244 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 87245 Approved-By: Andrew Burgess <aburgess@redhat.com> 87246 872472022-11-28 Tom Tromey <tromey@adacore.com> 87248 87249 Fix range type signed-ness heuristic 87250 The code to create a range type has a heuristic to decide whether the 87251 range is unsigned. However, this heuristic can fail if the upper 87252 bound of the range has its high bit set, because the test is done 87253 using LONGEST. 87254 87255 With this patch, if the underlying type of a range is unsigned, then 87256 the range will always be unsigned. A new test is included. 87257 87258 Regression tested on x86-64 Fedora 34. We've also been using this 87259 internally at AdaCore for a while. 87260 872612022-11-28 Simon Marchi <simon.marchi@efficios.com> 87262 87263 gdb: disable commit resumed in target_kill 87264 New in this version: 87265 87266 - Better comment in target_kill 87267 - Uncomment line in test to avoid hanging when exiting, when testing on 87268 native-extended-gdbserver 87269 87270 PR 28275 shows that doing a sequence of: 87271 87272 - Run inferior in background (run &) 87273 - kill that inferior 87274 - Run again 87275 87276 We get into this assertion: 87277 87278 /home/smarchi/src/binutils-gdb/gdb/target.c:2590: internal-error: target_wait: Assertion `!proc_target->commit_resumed_state' failed. 87279 87280 #0 internal_error_loc (file=0x5606b344e740 "/home/smarchi/src/binutils-gdb/gdb/target.c", line=2590, fmt=0x5606b344d6a0 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:54 87281 #1 0x00005606b6296475 in target_wait (ptid=..., status=0x7fffb9390630, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2590 87282 #2 0x00005606b5767a98 in startup_inferior (proc_target=0x5606bfccb2a0 <the_amd64_linux_nat_target>, pid=3884857, ntraps=1, last_waitstatus=0x0, last_ptid=0x0) at /home/smarchi/src/binutils-gdb/gdb/nat/fork-inferior.c:482 87283 #3 0x00005606b4e6c9c5 in gdb_startup_inferior (pid=3884857, num_traps=1) at /home/smarchi/src/binutils-gdb/gdb/fork-child.c:132 87284 #4 0x00005606b50f14a5 in inf_ptrace_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1) 87285 at /home/smarchi/src/binutils-gdb/gdb/inf-ptrace.c:105 87286 #5 0x00005606b53b6d23 in linux_nat_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1) 87287 at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:978 87288 #6 0x00005606b512b79b in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:468 87289 #7 0x00005606b512c236 in run_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:526 87290 87291 When running the kill command, commit_resumed_state for the 87292 process_stratum_target (linux-nat, here) is true. After the kill, when 87293 there are no more threads, commit_resumed_state is still true, as 87294 nothing touches this flag during the kill operation. During the 87295 subsequent run command, run_command_1 does: 87296 87297 scoped_disable_commit_resumed disable_commit_resumed ("running"); 87298 87299 We would think that this would clear the commit_resumed_state flag of 87300 our native target, but that's not the case, because 87301 scoped_disable_commit_resumed iterates on non-exited inferiors in order 87302 to find active process targets. And after the kill, the inferior is 87303 exited, and the native target was unpushed from it anyway. So 87304 scoped_disable_commit_resumed doesn't touch the commit_resumed_state 87305 flag of the native target, it stays true. When reaching target_wait, in 87306 startup_inferior (to consume the initial expect stop events while the 87307 inferior is starting up and working its way through the shell), 87308 commit_resumed_state is true, breaking the contract saying that 87309 commit_resumed_state is always false when calling the targets' wait 87310 method. 87311 87312 (note: to be correct, I think that startup_inferior should toggle 87313 commit_resumed between the target_wait and target_resume calls, but I'll 87314 ignore that for now) 87315 87316 I can see multiple ways to fix this. In the end, we need 87317 commit_resumed_state to be cleared by the time we get to that 87318 target_wait. It could be done at the end of the kill command, or at the 87319 beginning of the run command. 87320 87321 To keep things in a coherent state, I'd like to make it so that after 87322 the kill command, when the target is left with no threads, its 87323 commit_resumed_state flag is left to false. This way, we can keep 87324 working with the assumption that a target with no threads (and therefore 87325 no running threads) has commit_resumed_state == false. 87326 87327 Do this by adding a scoped_disable_commit_resumed in target_kill. It 87328 clears the target's commit_resumed_state on entry, and leaves it false 87329 if the target does not have any resumed thread on exit. That means, 87330 even if the target has another inferior with stopped threads, 87331 commit_resumed_state will be left to false, which makes sense. 87332 87333 Add a test that tries to cover various combinations of actions done 87334 while an inferior is running (and therefore while commit_resumed_state 87335 is true on the process target). 87336 87337 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275 87338 Change-Id: I8e6fe6dc1f475055921520e58cab68024039a1e9 87339 Approved-By: Andrew Burgess <aburgess@redhat.com> 87340 873412022-11-28 Simon Marchi <simon.marchi@efficios.com> 87342 87343 gdbserver: switch to right process in find_one_thread 87344 New in this version: add a dedicated test. 87345 87346 When I do this: 87347 87348 $ ./gdb -nx --data-directory=data-directory -q \ 87349 /bin/sleep \ 87350 -ex "maint set target-non-stop on" \ 87351 -ex "tar ext :1234" \ 87352 -ex "set remote exec-file /bin/sleep" \ 87353 -ex "run 1231 &" \ 87354 -ex add-inferior \ 87355 -ex "inferior 2" 87356 Reading symbols from /bin/sleep... 87357 (No debugging symbols found in /bin/sleep) 87358 Remote debugging using :1234 87359 Starting program: /bin/sleep 1231 87360 Reading /lib64/ld-linux-x86-64.so.2 from remote target... 87361 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. 87362 Reading /lib64/ld-linux-x86-64.so.2 from remote target... 87363 Reading /usr/lib/debug/.build-id/a6/7a1408f18db3576757eea210d07ba3fc560dff.debug from remote target... 87364 [New inferior 2] 87365 Added inferior 2 on connection 1 (extended-remote :1234) 87366 [Switching to inferior 2 [<null>] (<noexec>)] 87367 (gdb) Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target... 87368 attach 3659848 87369 Attaching to process 3659848 87370 /home/smarchi/src/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. 87371 87372 Note the "attach" command just above. When doing it on the command-line 87373 with a -ex switch, the bug doesn't trigger. 87374 87375 The internal error of GDB is actually caused by GDBserver crashing, and 87376 the error recovery of GDB is not on point. This patch aims to fix just 87377 the GDBserver crash, not the GDB problem. 87378 87379 GDBserver crashes with a segfault here: 87380 87381 (gdb) bt 87382 #0 0x00005555557fb3f4 in find_one_thread (ptid=...) at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:177 87383 #1 0x00005555557fd5cf in thread_db_thread_handle (ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400, handle_len=0x7fffffffc3f0) 87384 at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:461 87385 #2 0x000055555578a0b6 in linux_process_target::thread_handle (this=0x5555558a64c0 <the_x86_target>, ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400, 87386 handle_len=0x7fffffffc3f0) at /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:6905 87387 #3 0x00005555556dfcc6 in handle_qxfer_threads_worker (thread=0x60b000000510, buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1645 87388 #4 0x00005555556e00e6 in operator() (__closure=0x7fffffffc5e0, thread=0x60b000000510) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1696 87389 #5 0x00005555556f54be in for_each_thread<handle_qxfer_threads_proper(buffer*)::<lambda(thread_info*)> >(struct {...}) (func=...) at /home/smarchi/src/binutils-gdb/gdbserver/gdbthread.h:159 87390 #6 0x00005555556e0242 in handle_qxfer_threads_proper (buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1694 87391 #7 0x00005555556e04ba in handle_qxfer_threads (annex=0x629000000213 "", readbuf=0x621000019100 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4097) 87392 at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1732 87393 #8 0x00005555556e1989 in handle_qxfer (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2045 87394 #9 0x00005555556e720a in handle_query (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2685 87395 #10 0x00005555556f1a01 in process_serial_event () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4176 87396 #11 0x00005555556f4457 in handle_serial_event (err=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4514 87397 #12 0x0000555555820f56 in handle_file_event (file_ptr=0x607000000250, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 87398 #13 0x0000555555821895 in gdb_wait_for_event (block=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 87399 #14 0x000055555581f533 in gdb_do_one_event (mstimeout=-1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264 87400 #15 0x00005555556ec9fb in start_event_loop () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3512 87401 #16 0x00005555556f0769 in captured_main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3992 87402 #17 0x00005555556f0e3f in main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4078 87403 87404 The reason is a wrong current process when find_one_thread is called. 87405 The current process is the 2nd one, which was just attached. It does 87406 not yet have thread_db data (proc->priv->thread_db is nullptr). As we 87407 iterate on all threads of all process to fulfull the qxfer:threads:read 87408 request, we get to a thread of process 1 for which we haven't read 87409 thread_db information yet (lwp_info::thread_known is false), so we get 87410 into find_one_thread. find_one_thread uses 87411 `current_process ()->priv->thread_db`, assuming the current process 87412 matches the ptid passed as a parameter, which is wrong. A segfault 87413 happens when trying to dereference that thread_db pointer. 87414 87415 Fix this by making find_one_thread not assume what the current process / 87416 current thread is. If it needs to call into libthread_db, which we know 87417 will try to read memory from the current process, then temporarily set 87418 the current process. 87419 87420 In the case where the thread is already know and we return early, we 87421 don't need to switch process. 87422 87423 Add a test to reproduce this specific situation. 87424 87425 Change-Id: I09b00883e8b73b7e5f89d0f47cb4e9c0f3d6caaa 87426 Approved-By: Andrew Burgess <aburgess@redhat.com> 87427 874282022-11-28 Tom Tromey <tromey@adacore.com> 87429 87430 Fix crash in "document" command 87431 PR cli/29800 points out that "document" will now crash when the 87432 argument is an undefined command. This is a regression due to the 87433 "document user-defined aliases" patch. 87434 87435 Approved-By: Joel Brobecker <brobecker@adacore.com> 87436 Reviewed-By: Philippe Waroquiers <philippe.waroquiers@skynet.be> 87437 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29800 87438 874392022-11-28 Tom de Vries <tdevries@suse.de> 87440 87441 [gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le 87442 On powerpc64le-linux, I run into: 87443 ... 87444 (gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit 87445 step^M 87446 28 { /* first-retry */^M 87447 (gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit 87448 ... 87449 87450 It's a bit easier to understand what happens if we do a full stepping session: 87451 ... 87452 Temporary breakpoint 1, main () 87453 at solib-intra-step-main.c:23 87454 23 shlib_first (); 87455 (gdb) step 87456 shlib_first () at solib-intra-step-lib.c:29 87457 29 shlib_second (0); /* first-hit */ 87458 (gdb) step 87459 28 { /* first-retry */ 87460 (gdb) step 87461 29 shlib_second (0); /* first-hit */ 87462 (gdb) step 87463 shlib_second (dummy=0) 87464 at solib-intra-step-lib.c:23 87465 23 abort (); /* second-hit */ 87466 ... 87467 and compare that to the line info: 87468 ... 87469 CU: solib-intra-step-lib.c: 87470 File name Line number Starting address View Stmt 87471 solib-intra-step-lib.c 22 0x710 x 87472 solib-intra-step-lib.c 23 0x724 x 87473 solib-intra-step-lib.c 28 0x740 x 87474 solib-intra-step-lib.c 29 0x74c x 87475 solib-intra-step-lib.c 28 0x750 x 87476 solib-intra-step-lib.c 29 0x758 x 87477 solib-intra-step-lib.c 30 0x760 x 87478 solib-intra-step-lib.c - 0x77c 87479 ... 87480 87481 So we step from line 29 to line 28, and back to line 29, which is behaviour 87482 that matches the line table. The peculiar order is due to using optimization. 87483 The problem is that the test-case doesn't expect this order. 87484 87485 Fix this by allowing this order in the test-case. 87486 87487 Tested on powerpc64le-linux. 87488 87489 PR testsuite/29792 87490 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29792 87491 874922022-11-28 Andrew Burgess <aburgess@redhat.com> 87493 87494 gdb: fix assert when quitting GDB while a thread is stepping 87495 This commit addresses one of the issues identified in PR gdb/28275. 87496 87497 Bug gdb/28275 identifies a number of situations in which this assert: 87498 87499 Assertion `!proc_target->commit_resumed_state' failed. 87500 87501 could be triggered. There's actually a number of similar places where 87502 this assert is found in GDB, the two of interest in gdb/28275 are in 87503 target_wait and target_stop. 87504 87505 In one of the comments: 87506 87507 https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1 87508 87509 steps to trigger the assertion within target_stop were identified when 87510 using a modified version of the gdb.threads/detach-step-over.exp test 87511 script. 87512 87513 In the gdb.threads/detach-step-over.exp test, we attach to a 87514 multi-threaded inferior, and continue the inferior in asynchronous 87515 (background) mode. Each thread is continuously hitting a conditional 87516 breakpoint where the condition is always false. While the inferior is 87517 running we detach. The goal is that we detach while GDB is performing a 87518 step-over for the conditional breakpoint in at least one thread. 87519 87520 While detaching, if a step-over is in progress, then GDB has to 87521 complete the step over before we can detach. This involves calling 87522 target_stop and target_wait (see prepare_for_detach). 87523 87524 As far as gdb/28275 is concerned, the interesting part here, is the 87525 the process_stratum_target::commit_resumed_state variable must be 87526 false when target_stop and target_wait are called. 87527 87528 This is currently ensured because, in detach_command (infrun.c), we 87529 create an instance of scoped_disable_commit_resumed, this ensures that 87530 when target_detach is called, ::commit_resumed_state will be false. 87531 87532 The modification to the test that I propose here, and which exposed 87533 the bug, is that, instead of using "detach" to detach from the 87534 inferior, we instead use "quit". Quitting GDB after attaching to an 87535 inferior will cause GDB to first detach, and then exit. 87536 87537 When we quit GDB we end up calling target_detach via a different code 87538 path, the stack looks like: 87539 87540 #0 target_detach 87541 #1 kill_or_detach 87542 #2 quit_force 87543 #3 quit_command 87544 87545 Along this path there is no scoped_disable_commit_resumed created. 87546 ::commit_resumed_state can be true when we reach prepare_for_detach, 87547 which calls target_wait and target_stop, so the assertion will trigger. 87548 87549 In this commit, I propose fixing this by adding the creation of a 87550 scoped_disable_commit_resumed into target_detach. This will ensure 87551 that ::commit_resumed_state is false when calling prepare_for_detach 87552 from within target_detach. 87553 87554 I did consider placing the scoped_disable_commit_resumed in 87555 prepare_for_detach, however, placing it in target_detach ensures that 87556 the target's commit_resumed_state flag is left to false if the detached 87557 inferior was the last one for that target. It's the same rationale as 87558 for patch "gdb: disable commit resumed in target_kill" that comes later 87559 in this series, but for detach instead of kill. 87560 87561 detach_command still includes a scoped_disable_commit_resumed too, but I 87562 think it is still relevant to cover the resumption at the end of the 87563 function. 87564 87565 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 87566 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275 87567 Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f 87568 875692022-11-28 Andrew Burgess <aburgess@redhat.com> 87570 87571 gdb/testsuite: refactor gdb.threads/detach-step-over.exp 87572 Factor out some bits of gdb.threads/detach-step-over.exp to procs in 87573 preparation to adding some new variations of the test. Rename the 87574 existing "test" proc and make it use proc_with_prefix. 87575 87576 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 87577 Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189 87578 875792022-11-28 Simon Marchi <simon.marchi@efficios.com> 87580 87581 gdb/testsuite: remove global declarations in gdb.threads/detach-step-over.exp 87582 Before doing further changes to this file, change to use the :: notation 87583 instead of declaring global variables with the `global` keyword. 87584 87585 Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb 87586 Approved-By: Andrew Burgess <aburgess@redhat.com> 87587 875882022-11-28 Tom de Vries <tdevries@suse.de> 87589 87590 [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5 87591 On powerpc64le-linux, using gcc 4.8.5, I run into: 87592 ... 87593 (gdb) PASS: gdb.arch/altivec-regs.exp: next (1) 87594 next^M 87595 11 c = vec_add (a, b);^M 87596 (gdb) PASS: gdb.arch/altivec-regs.exp: next (2) 87597 print/x a^M 87598 $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M 87599 (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a 87600 ... 87601 87602 Looking at the disassembly and the debug info, it's clear why there's 87603 a FAIL. 87604 87605 The debug info says that the variable can be found at some stack location, but 87606 the instructions don't seem to be writing there. 87607 87608 We can work around this by marking variable a volatile. Likewise for b. 87609 87610 Note that marking the variables as volatile doesn't change the location 87611 information. 87612 87613 Tested on power64le-linux. 87614 876152022-11-28 Tom de Vries <tdevries@suse.de> 87616 87617 [gdb/tdep] Fix gdb.base/msym-bp-shl.exp for ppc64le 87618 With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into: 87619 ... 87620 (gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo 87621 info breakpoint^M 87622 Num Type Disp Enb Address What^M 87623 1 breakpoint keep y <MULTIPLE> ^M 87624 1.1 y 0x00000000000008d4 <foo+12>^M 87625 1.2 y 0x0000000000000a34 crti.S:88^M 87626 (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint 87627 ... 87628 87629 The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34: 87630 ... 87631 0000000000000a28 <foo@plt>: 87632 a28: c0 ff ff 4b b 9e8 <__glink_PLTresolve> 87633 87634 Disassembly of section .fini: 87635 87636 0000000000000a2c <_fini>: 87637 a2c: 02 00 4c 3c addis r2,r12,2 87638 a30: d4 74 42 38 addi r2,r2,29908 87639 a34: a6 02 08 7c mflr r0 87640 ... 87641 87642 This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as 87643 having a local entry point, due to incorrectly accessing an asymbol struct 87644 using a (larger) elf_symbol_type. 87645 87646 Fix this by simply ignoring artificial symbols in 87647 ppc_elfv2_elf_make_msymbol_special. 87648 87649 Tested on powerpc64le. 87650 87651 Approved-By: Ulrich Weigand <uweigand@de.ibm.com> 87652 Reviewed-By: Carl Love <cel@us.ibm.com> 87653 Tested-By: Carl Love <cel@us.ibm.com> 87654 PR tdep/29814 87655 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814 87656 876572022-11-28 Alan Modra <amodra@gmail.com> 87658 87659 PR10368, ISO 8859 mentioned as 7bit encoding in strings documentation 87660 PR 10368 87661 * doc/binutils.texi (strings): Delete example of 7-bit encoding. 87662 87663 Use bfd_rename_section in msp430.em 87664 * emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use 87665 bfd_rename_section. 87666 * testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data 87667 and bss input sections. 87668 87669 asan: pef: buffer overflow 87670 * pef.c (bfd_pef_parse_traceback_table): Correct size moved when 87671 stripping leading dot. 87672 87673 regen gas/Makefile.in 87674 876752022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com> 87676 87677 RISC-V: Allow merging 'H' extension 87678 Because riscv_merge_std_ext function did not merge the 'H' extension, linked 87679 executables lacked 'H' extension when multiple objects are merged. 87680 87681 This issue is found while building OpenSBI with 'H' extension (resulting 87682 ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked 87683 object files contained it). 87684 87685 This commit adds 'h' to standard_exts variable to merge 'H' extension. 87686 87687 bfd/ChangeLog: 87688 87689 * elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging. 87690 876912022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com> 87692 87693 RISC-V: Better support for long instructions (tests) 87694 This commit tests both (assembler and disassembler) fixes of "Better support 87695 for long instructions". 87696 87697 gas/ChangeLog: 87698 87699 * testsuite/gas/riscv/insn.s: Add testcases such that big number 87700 handling is required and should be disassembled as long ".byte" 87701 sequence with correct instruction bits. 87702 * testsuite/gas/riscv/insn.d: Likewise. 87703 * testsuite/gas/riscv/insn-na.d: Likewise. 87704 * testsuite/gas/riscv/insn-dwarf.d: Likewise. 87705 877062022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com> 87707 87708 RISC-V: Better support for long instructions (assembler) 87709 Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit 87710 instructions with .insn") tried to start supporting long instructions but 87711 it was insufficient. 87712 87713 1. It heavily depended on the bignum internals (radix of 2^16), 87714 2. It generates "value conflicts with instruction length" even if a big 87715 number instruction encoding does not exceed its expected length and 87716 3. Because long opcode was handled separately (from struct riscv_cl_insn), 87717 some information like DWARF line number correspondence was missing. 87718 87719 To resolve these problems, this commit: 87720 87721 1. Handles bignum (and its encodings) precisely and 87722 2. Incorporates long opcode handling into regular instruction handling. 87723 87724 This commit will be tested on the separate commit. 87725 87726 gas/ChangeLog: 87727 87728 * config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field. 87729 (create_insn) Clear long opcode marker. 87730 (install_insn) Install longer opcode as well. 87731 (s_riscv_insn) Likewise. 87732 (riscv_ip_hardcode): Make big number handling stricter. Length and 87733 the value conflicts only if the bignum size exceeds the expected 87734 maximum length. 87735 877362022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com> 87737 87738 RISC-V: Better support for long instructions (disassembler) 87739 Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit 87740 instructions with .insn") tried to start supporting long instructions but 87741 it was insufficient. 87742 87743 On the disassembler, correct ".byte" output was limited to the first 64-bits 87744 of an instruction. After that, zeroes are incorrectly printed. 87745 87746 Note that, it only happens on ".byte" output (instruction part) and not on 87747 hexdump (data) part. For example, before this commit, hexdump and ".byte" 87748 produces different values: 87749 87750 Assembly: 87751 .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f 87752 objdump output example (before the fix): 87753 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 87754 18: 89ab 4567 0123 3210 87755 20: 7654 ba98 fedc 87756 87757 Note that, after 0xcd (after first 64-bits of the target instruction), all 87758 ".byte" values are incorrectly printed as zero while hexdump prints correct 87759 instruction bits. 87760 87761 To resolve this, this commit adds "packet" argument to support dumping 87762 instructions longer than 64-bits (to print correct instruction bits on 87763 ".byte"). This commit will be tested on the separate commit. 87764 87765 Assembly: 87766 .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f 87767 objdump output example (after the fix): 87768 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe 87769 18: 89ab 4567 0123 3210 87770 20: 7654 ba98 fedc 87771 87772 opcodes/ChangeLog: 87773 87774 * riscv-dis.c (riscv_disassemble_insn): Print unknown instruction 87775 using the new argument packet. 87776 (riscv_disassemble_data): Add unused argument packet. 87777 (print_insn_riscv): Pass packet to the disassemble function. 87778 877792022-11-28 GDB Administrator <gdbadmin@sourceware.org> 87780 87781 Automatic date update in version.in 87782 877832022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be> 87784 87785 Fix leak in the dwarf reader 87786 Valgrind reports a leak in the dwarf reader (see details below). 87787 The function dw2_get_file_names_reader is interning in the per_objfile 87788 all the file names it finds, except the name of 'fnd file name and directory'. 87789 Instead, it was xstrdup-ing the name. 87790 Fix the leaks by also interning the name. 87791 87792 This was validated running the tests natively, and under valgrind. 87793 Leaks have decreased as mentionned below. 87794 Valgrind detected no error such as double free or use after free. 87795 87796 Stack trace of the leak: 87797 ==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074 87798 ==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393) 87799 ==4113266== by 0x25A454: xmalloc (alloc.c:57) 87800 ==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34) 87801 ==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825) 87802 ==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851) 87803 ==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149) 87804 ==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688) 87805 ==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207) 87806 ==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633) 87807 ==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712) 87808 ==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726) 87809 ==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329) 87810 ==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388) 87811 ==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104) 87812 ==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149) 87813 ... 87814 87815 Without the fix, the top 10 leaks are: 87816 ./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks 87817 ./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks 87818 ./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks 87819 ./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks 87820 ./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks 87821 ./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks 87822 ./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks 87823 ./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks 87824 ./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks 87825 ./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks 87826 87827 With the fix: 87828 ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks 87829 ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks 87830 ./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks 87831 ./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks 87832 ./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks 87833 ./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks 87834 ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks 87835 ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks 87836 ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks 87837 ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks 87838 87839 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87840 878412022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be> 87842 87843 fix leak in gdb_environ 87844 valgrind reports a leak when assigning a gdb_environ to another gdb_environ. 87845 The memory allocated for the target gdb_environ env variables is not released. 87846 The gdb_environ selftest reproduces the leak (see below). 87847 Fix the leak by clearing the target gdb_environ before std::move-ing the 87848 members. 87849 87850 Tested natively and re-running all tests under valgrind. 87851 87852 ==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839 87853 ==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393) 87854 ==3261873== by 0x25A454: xmalloc (alloc.c:57) 87855 ==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34) 87856 ==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56) 87857 ==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78) 87858 ==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285) 87859 ==3261873== by 0x7EFC43: operator() (std_function.h:622) 87860 = 87861 87862 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87863 878642022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be> 87865 87866 Use false/true for some inferior class members instead of 0/1 87867 Some class members were changed to bool, but there was 87868 still some assignments or comparisons using 0/1. 87869 87870 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87871 878722022-11-27 Tom de Vries <tdevries@suse.de> 87873 87874 [gdb/server] Emit warning for SIGINT failure 87875 Consider the executable from test-case gdb.base/interrupt-daemon.exp. 87876 87877 When starting it using gdbserver: 87878 ... 87879 $ ./build/gdbserver/gdbserver localhost:2345 \ 87880 ./outputs/gdb.base/interrupt-daemon/interrupt-daemon 87881 ... 87882 and connecting to it using gdb: 87883 ... 87884 $ gdb -q -ex "target remote localhost:2345" \ 87885 -ex "set follow-fork-mode child" \ 87886 -ex "break daemon_main" -ex cont 87887 ... 87888 we are setup to do the same as in the test-case: interrupt a running inferior 87889 using ^C. 87890 87891 So let's try: 87892 ... 87893 (gdb) continue 87894 Continuing. 87895 ^C 87896 ... 87897 After pressing ^C, nothing happens. This a known problem, filed as 87898 PR remote/18772. 87899 87900 The problem is that in linux_process_target::request_interrupt, a kill is used 87901 to send a SIGINT, but it fails. And it fails silently. 87902 87903 Make the failure verbose by adding a warning, such that the gdbserver output 87904 becomes more helpful: 87905 ... 87906 Process interrupt-daemon created; pid = 15068 87907 Listening on port 2345 87908 Remote debugging from host ::1, port 35148 87909 Detaching from process 15068 87910 Detaching from process 15085 87911 gdbserver: Sending SIGINT to process group of pid 15068 failed: \ 87912 No such process 87913 ... 87914 87915 Note that the failure can easily be reproduced using the test-case and target 87916 board native-gdbserver: 87917 ... 87918 (gdb) continue^M 87919 Continuing.^M 87920 PASS: gdb.base/interrupt-daemon.exp: fg: continue 87921 ^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout) 87922 ... 87923 as reported in PR server/23382. 87924 87925 Tested on x86_64-linux. 87926 Approved-By: Simon Marchi <simon.marchi@efficios.com> 87927 879282022-11-27 GDB Administrator <gdbadmin@sourceware.org> 87929 87930 Automatic date update in version.in 87931 879322022-11-26 Tom de Vries <tdevries@suse.de> 87933 87934 [gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp 87935 When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I 87936 noticed: 87937 ... 87938 FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout) 87939 ... 87940 87941 The timeout is 10 seconds, but generating the core file takes more than a 87942 minute, probably due to slow NFS. 87943 87944 I managed to reproduce this behaviour independently of gdb, by compiling 87945 "int main (void) { __builtin_abort (); }" and running it, which took 1.5 87946 seconds for a core file 50 times smaller than the one for gdb. 87947 87948 Fix this by preventing the core file from being generated, using a wrapper 87949 around gdb that does "ulimit -c 0". 87950 87951 Tested on x86_64-linux. 87952 879532022-11-26 Tom de Vries <tdevries@suse.de> 87954 87955 [gdb/symtab] Handle failure to open .gnu_debugaltlink file 87956 If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after 87957 dwz has created it, with test-case 87958 gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m 87959 we run into: 87960 ... 87961 (gdb) file access-mem-running-thread-exit^M 87962 Reading symbols from access-mem-running-thread-exit...^M 87963 could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M 87964 ... 87965 followed a bit later by: 87966 ... 87967 (gdb) file access-mem-running-thread-exit^M 87968 Reading symbols from access-mem-running-thread-exit...^M 87969 gdb/dwarf2/read.c:7284: internal-error: create_all_units: \ 87970 Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M 87971 ... 87972 87973 The problem is that create_units does not catch the error thrown by 87974 dwarf2_get_dwz_file. 87975 87976 Fix this by catching the error and performing the necessary cleanup, getting 87977 the same result for the first and second file command. 87978 87979 PR symtab/29805 87980 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805 87981 879822022-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> 87983 87984 Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct. 87985 Valgrind reports a "jump on unitialised bit error" when running 87986 e.g. gdb.base/macro-source-path.exp (see details below). 87987 87988 Fix this by initializing producer_is_clang member variable of dwarf2_cu. 87989 87990 Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp 87991 under valgrind. 87992 87993 ==2140965== Conditional jump or move depends on uninitialised value(s) 87994 ==2140965== at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676) 87995 ==2140965== by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967) 87996 ==2140965== by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379) 87997 ==2140965== by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687) 87998 ==2140965== by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660) 87999 ==2140965== by 0x5569C7: process_full_comp_unit (read.c:8429) 88000 ==2140965== by 0x5569C7: process_queue (read.c:7675) 88001 ==2140965== by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063) 88002 ==2140965== by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) 88003 ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) 88004 ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) 88005 ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) 88006 .... 88007 ==2140965== Uninitialised value was created by a heap allocation 88008 ==2140965== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434) 88009 ==2140965== by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264) 88010 ==2140965== by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729) 88011 ==2140965== by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021) 88012 ==2140965== by 0x55634C: dw2_do_instantiate_symtab (read.c:2048) 88013 ==2140965== by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) 88014 ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) 88015 ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) 88016 ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) 88017 .... 88018 880192022-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88020 88021 remove the declared but undefined/unused method find_partial_die 88022 The method 88023 struct partial_die_info *find_partial_die (sect_offset sect_off); 88024 in cu.h is defined, but is used nowhere and not implemented. 88025 880262022-11-26 GDB Administrator <gdbadmin@sourceware.org> 88027 88028 Automatic date update in version.in 88029 880302022-11-25 Martin Liska <mliska@suse.cz> 88031 88032 Revert "readelf: Do not require EI_OSABI for IFUNC." 88033 This reverts commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801. 88034 880352022-11-25 Christoph Müllner <christoph.muellner@vrull.eu> 88036 88037 riscv: Add AIA extension support (Smaia, Ssaia) 88038 This commit adds the AIA extensions (Smaia and Ssaia) CSRs. 88039 88040 bfd/ChangeLog: 88041 88042 * elfxx-riscv.c: Add 'smaia' and 'ssaia' to the list 88043 of known standard extensions. 88044 88045 gas/ChangeLog: 88046 88047 * config/tc-riscv.c (enum riscv_csr_class): 88048 (riscv_csr_address): Add CSR classes for Smaia/Ssaia. 88049 * testsuite/gas/riscv/csr-dw-regnums.d: Add new CSRs. 88050 * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. 88051 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 88052 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 88053 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 88054 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 88055 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 88056 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 88057 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 88058 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 88059 * testsuite/gas/riscv/csr.s: Likewise. 88060 88061 include/ChangeLog: 88062 88063 * opcode/riscv-opc.h (CSR_MISELECT): New CSR macro. 88064 (CSR_MIREG): Likewise. 88065 (CSR_MTOPEI): Likewise. 88066 (CSR_MTOPI): Likewise. 88067 (CSR_MVIEN): Likewise. 88068 (CSR_MVIP): Likewise. 88069 (CSR_MIDELEGH): Likewise. 88070 (CSR_MIEH): Likewise. 88071 (CSR_MVIENH): Likewise. 88072 (CSR_MVIPH): Likewise. 88073 (CSR_MIPH): Likewise. 88074 (CSR_SISELECT): Likewise. 88075 (CSR_SIREG): Likewise. 88076 (CSR_STOPEI): Likewise. 88077 (CSR_STOPI): Likewise. 88078 (CSR_SIEH): Likewise. 88079 (CSR_SIPH): Likewise. 88080 (CSR_HVIEN): Likewise. 88081 (CSR_HVICTL): Likewise. 88082 (CSR_HVIPRIO1): Likewise. 88083 (CSR_HVIPRIO2): Likewise. 88084 (CSR_VSISELECT): Likewise. 88085 (CSR_VSIREG): Likewise. 88086 (CSR_VSTOPEI): Likewise. 88087 (CSR_VSTOPI): Likewise. 88088 (CSR_HIDELEGH): Likewise. 88089 (CSR_HVIENH): Likewise. 88090 (CSR_HVIPH): Likewise. 88091 (CSR_HVIPRIO1H): Likewise. 88092 (CSR_HVIPRIO2H): Likewise. 88093 (CSR_VSIEH): Likewise. 88094 (CSR_VSIPH): Likewise. 88095 (DECLARE_CSR): Add CSRs for Smaia and Ssaia. 88096 88097 Changes for v3: 88098 - Imply ssaia for smaia 88099 - Imply zicsr for ssaia (and transitively smaia) 88100 - Move hypervisor CSRs to Ssaia+H 88101 - Rebase on upstream/master 88102 88103 Changes for v2: 88104 - Add hypervisor and VS CSRs 88105 - Fix whitespace issue 88106 881072022-11-25 GDB Administrator <gdbadmin@sourceware.org> 88108 88109 Automatic date update in version.in 88110 881112022-11-24 Indu Bhagat <indu.bhagat@oracle.com> 88112 88113 sframe/doc: remove usage of xrefautomaticsectiontitle 88114 xrefautomaticsectiontitle appears to be available from texinfo 5.0 or 88115 greater. As such, it is not worthwhile to add requirement for a minimum 88116 necessary makeinfo version. So remove the usage of it. 88117 88118 Also align node name with section title where possible. 88119 88120 ChangeLog: 88121 88122 * libsframe/doc/sframe-spec.texi: Remove usage of 88123 xrefautomaticsectiontitle. 88124 881252022-11-24 Andrew Burgess <aburgess@redhat.com> 88126 88127 gdb: fix typo in debug output message 88128 Spotted a minor type, a missing ')', in a debug message. 88129 881302022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88131 88132 gdb/testsuite/gdb.base/break.exp: split test_break 88133 Move all the remaining tests to a single test_break proc. It's a bit 88134 big, but all of these are kind of tied together. The procs starts by 88135 setting breakpoints, checks that we can see them in "info breakpoints", 88136 and tries stopping on them. 88137 88138 Move all the "set bp_locationX" calls together at the top. 88139 88140 Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900 88141 Approved-By: Kevin Buettner <kevinb@redhat.com> 88142 881432022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88144 88145 gdb/testsuite/gdb.base/break.exp: split test_tbreak 88146 Leave setting bp_location11 in the global scope, so that it's accessible 88147 to other procs. 88148 88149 Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9 88150 Approved-By: Kevin Buettner <kevinb@redhat.com> 88151 881522022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88153 88154 gdb/testsuite/gdb.base/break.exp: split test_no_break_on_catchpoint 88155 Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76 88156 Approved-By: Kevin Buettner <kevinb@redhat.com> 88157 88158 gdb/testsuite/gdb.base/break.exp: split test_break_nonexistent_line 88159 Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12 88160 Approved-By: Kevin Buettner <kevinb@redhat.com> 88161 881622022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88163 88164 gdb/testsuite/gdb.base/break.exp: split test_break_default 88165 One special thing here is that the part just above this one, that sets 88166 catchpoints and verifies they are not hit, requires that we resume 88167 execution to verify that the catchpoints are indeed not hit. I guess 88168 it was previously achieved by the until command, but it doesn't happen 88169 now that the until is moved into test_break_default. Add a 88170 gdb_continue_to_end after setting the catchpoints. If any catchpoint 88171 were to be hit, it would catch the problem. 88172 88173 Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05 88174 Approved-By: Kevin Buettner <kevinb@redhat.com> 88175 881762022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88177 88178 gdb/testsuite/gdb.base/break.exp: split test_break_silent_and_more 88179 This one is a bit tricky. The clear tests seem to depend on the various 88180 breakpoints that have been set before, starting with the "silent" 88181 breakpoints. So, move all this in a single chunk, it can always be 88182 split later if needed. 88183 88184 Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f 88185 Approved-By: Kevin Buettner <kevinb@redhat.com> 88186 881872022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88188 88189 gdb/testsuite/gdb.base/break.exp: split test_break_line_convenience_var 88190 Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab 88191 Approved-By: Kevin Buettner <kevinb@redhat.com> 88192 88193 gdb/testsuite/gdb.base/break.exp: split test_break_user_call 88194 Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320 88195 Approved-By: Kevin Buettner <kevinb@redhat.com> 88196 88197 gdb/testsuite/gdb.base/break.exp: split test_finish_arguments 88198 Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51 88199 Approved-By: Kevin Buettner <kevinb@redhat.com> 88200 882012022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88202 88203 gdb/testsuite/gdb.base/break.exp: use proc_with_prefix for test_next_with_recursion 88204 This one is already in a proc, just make the proc use proc_with_prefix, 88205 for consistency. 88206 88207 Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a 88208 Approved-By: Kevin Buettner <kevinb@redhat.com> 88209 882102022-11-24 Simon Marchi <simon.marchi@polymtl.ca> 88211 88212 gdb/testsuite/gdb.base/break.exp: split test_break_optimized_prologue 88213 Change-Id: Ibf17033c8ce72aa5cfe1b739be2902e84a5e945d 88214 Approved-By: Kevin Buettner <kevinb@redhat.com> 88215 88216 gdb/testsuite/gdb.base/break.exp: split test_rbreak_shlib 88217 Change-Id: I130e8914c2713095aab03e84aba1481b4c7af978 88218 Approved-By: Kevin Buettner <kevinb@redhat.com> 88219 88220 gdb/testsuite/gdb.base/break.exp: split test_break_file_line_convenience_var 88221 Change-Id: I0c31b037669b2917e062bf431372fb6531f8f53c 88222 Approved-By: Kevin Buettner <kevinb@redhat.com> 88223 88224 gdb/testsuite/gdb.base/break.exp: split test_break_commands_clear 88225 Change-Id: Ia58f90117d52fc419fc494836d9b4ed5d902fe9b 88226 Approved-By: Kevin Buettner <kevinb@redhat.com> 88227 882282022-11-24 Nick Clifton <nickc@redhat.com> 88229 88230 Impport libiberty commit: 885b6660c17f from gcc mainline. Fix gas's acinclude.m4 to stop a potwntial configure time warning message. 88231 882322022-11-24 Martin Liska <mliska@suse.cz> 88233 88234 readelf: Do not require EI_OSABI for IFUNC. 88235 PR 29718 88236 88237 binutils/ChangeLog: 88238 88239 * readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as 88240 reserved name. 88241 882422022-11-24 Jan Beulich <jbeulich@suse.com> 88243 88244 x86: widen applicability and use of CheckRegSize 88245 First of all make operand_type_register_match() apply to all sized 88246 operands, i.e. in Intel Syntax also to respective memory ones. This 88247 addresses gas wrongly accepting certain SIMD insns where register and 88248 memory operand sizes should match but don't. This apparently has 88249 affected all templates with one memory-only operand and one or more 88250 register ones, both permitting at least two sizes, due to CheckRegSize 88251 not taking effect. 88252 88253 Then also add CheckRegSize to a couple of non-SIMD templates matching 88254 that same pattern of memory-only vs register operands. This replaces 88255 bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when 88256 none was used at all) by "type mismatch" ones, just like already emitted 88257 for insns where the template allows a register operand alongside a 88258 memory one at any particular position. 88259 88260 This also is a prereq to limiting (ideally eliminating in the long run) 88261 suffix "derivation" in Intel Syntax mode. 88262 88263 While making the code adjustment also flip order of checks to do the 88264 cheaper one first in both cases. 88265 882662022-11-24 Jan Beulich <jbeulich@suse.com> 88267 88268 x86: add missing CheckRegSize 88269 To properly and predictably determine operand size encoding (operand 88270 size or REX.W prefixes), consistent operand sizes need to be specified. 88271 Add CheckRegSize where this was previously missing. 88272 88273 x86: correct handling of LAR and LSL 88274 Both uniformly only ever take 16-bit memory operands while at the same 88275 time requiring matching (in size) register operands, which then also 88276 should disassemble that way. This in particular requires splitting each 88277 of the templates for the assembler and separating decode of the 88278 register and memory forms in the disassembler. 88279 882802022-11-24 Alan Modra <amodra@gmail.com> 88281 88282 Tidy objdump printing of section size 88283 * objdump.c (load_specific_debug_section): Use PRIx64 format. 88284 88285 Constify nm format array 88286 * nm.c (formats, format): Make const. 88287 882882022-11-24 Alan Modra <amodra@gmail.com> 88289 88290 PR16995, m68k coldfire emac immediate to macsr incorrect disassembly 88291 Mode/reg bits for these insns are 000 Dy, 001 Ay, and 111 100 for the 88292 move immediate. 88293 88294 * m68k-opc.c (m68k_opcodes): Only accept 000 and 001 as mode 88295 for move reg to macsr/mask insns. 88296 882972022-11-24 Mark Harmstone <mark@harmstone.com> 88298 88299 gas: Disable --gcodeview on PE targets with no O_secrel 88300 883012022-11-24 GDB Administrator <gdbadmin@sourceware.org> 88302 88303 Automatic date update in version.in 88304 883052022-11-23 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 88306 88307 gdb/arm: Include FType bit in EXC_RETURN pattern on v8m 88308 For v8m, the EXC_RETURN pattern, without security extension, consists of 88309 FType, Mode and SPSEL. These are the same bits that are used in v7m. 88310 This patch extends the list of patterns to include also the FType bit 88311 and not just Mode and SPSEL bits for v8m targets without security 88312 extension. 88313 883142022-11-23 Alan Modra <amodra@gmail.com> 88315 88316 regen POTFILES.in 88317 883182022-11-23 Alan Modra <amodra@gmail.com> 88319 88320 PR22509 - Null pointer dereference on coff_slurp_reloc_table 88321 This extends the commit 4581a1c7d304 fix to more targets, which 88322 hardens BFD a little. I think the real underlying problem was the 88323 bfd_canonicalize_reloc call in load_specific_debug_section which 88324 passed a NULL for "symbols". Fix that too. 88325 88326 PR 22509 88327 bfd/ 88328 * aoutx.h (swap_ext_reloc_out): Gracefully handle NULL symbols. 88329 * i386lynx.c (swap_ext_reloc_out): Likewise. 88330 * pdp11.c (pdp11_aout_swap_reloc_out): Likewise. 88331 * coff-tic30.c (reloc_processing): Likewise. 88332 * coff-tic4x.c (tic4x_reloc_processing): Likewise. 88333 * coff-tic54x.c (tic54x_reloc_processing): Likewise. 88334 * coff-z80.c (reloc_processing): Likewise. 88335 * coff-z8k.c (reloc_processing): Likewise. 88336 * ecoff.c (ecoff_slurp_reloc_table): Likewise. 88337 * som.c (som_set_reloc_info): Likewise. 88338 binutils/ 88339 * objdump.c (load_specific_debug_section): Pass syms to 88340 bfd_canonicalize_reloc. 88341 883422022-11-23 Alan Modra <amodra@gmail.com> 88343 88344 asan: NULL deref in filter_symbols 88345 If tdata->symbols is NULL, make tdata->symcount zero too. This makes 88346 wasm_get_symtab_upper_bound return the proper result and stops 88347 cascading errors. 88348 88349 * wasm-module.c (wasm_scan_name_function_section): Clear 88350 tdata->symcount on error. 88351 883522022-11-23 Luis Machado <luis.machado@arm.com> 88353 88354 Document the memory_tagged argument for memory region callbacks 88355 There were no comments in some instances (gdb/defs.h, gdb/core.c and 88356 gdb/linux-tdep.c), so address that by adding comments where those are missing. 88357 883582022-11-23 Tom de Vries <tdevries@loganberry-1.arch.suse.de> 88359 88360 Fix gdb.cp/gdb2495.exp on powerpc64le 88361 On powerpc64le-linux I ran into this FAIL: 88362 ... 88363 (gdb) p exceptions.throw_function()^M 88364 terminate called after throwing an instance of 'int'^M 88365 ^M 88366 Program received signal SIGABRT, Aborted.^M 88367 0x00007ffff7979838 in raise () from /lib64/libc.so.6^M 88368 The program being debugged was signaled while in a function called from GDB.^M 88369 GDB remains in the frame where the signal was received.^M 88370 To change this behavior use "set unwindonsignal on".^M 88371 Evaluation of the expression containing the function^M 88372 (SimpleException::throw_function()) will be abandoned.^M 88373 When the function is done executing, GDB will silently stop.^M 88374 (gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception \ 88375 without a handler. 88376 ... 88377 88378 The following happens: 88379 - we start an inferior call 88380 - an internal breakpoint is set on the global entry point of std::terminate 88381 - the inferior call uses the local entry point 88382 - the breakpoint is not triggered 88383 - we run into std::terminate 88384 88385 We can fix this by simply adding the missing gdbarch_skip_entrypoint call in 88386 create_std_terminate_master_breakpoint, but we try to do this a bit more 88387 generic, by: 88388 - adding a variant of function create_internal_breakpoint which takes a 88389 minimal symbol instead of an address as argument 88390 - in the new function: 88391 - using both gdbarch_convert_from_func_ptr_addr and gdbarch_skip_entrypoint 88392 - documenting why we don't need to use gdbarch_addr_bits_remove 88393 - adding a note about possibly 88394 needing gdbarch_deprecated_function_start_offset. 88395 - using the new function in: 88396 - create_std_terminate_master_breakpoint 88397 - create_exception_master_breakpoint_hook, which currently uses only 88398 gdbarch_convert_from_func_ptr_addr. 88399 88400 Note: we could use the new function in more locations in breakpoint.c, but 88401 as we're not aware of any related failures, we declare this out of scope for 88402 this patch. 88403 88404 Tested on x86_64-linux, powerpc64le-linux. 88405 88406 Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com> 88407 Tested-by: Carl Love <cel@us.ibm.com> 88408 PR tdep/29793 88409 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29793 88410 884112022-11-23 Xiao Zeng <zengxiao@eswincomputing.com> 88412 88413 RISC-V: Make R_RISCV_SUB6 conforms to riscv ABI standard 88414 According to the riscv psabi, R_RISCV_SUB6 only allows 6 least significant 88415 bits are valid, but since binutils implementation, we usually get 8 bits 88416 field for it. That means, the high 2 bits could be other field and have 88417 different purpose. Therefore, we should filter the 8 bits to 6 bits before 88418 calculate, and then only encode the valid 6 bits back. By the way, we also 88419 need the out-of-range check for R_RISCV_SUB6, and the overflow checks for 88420 all R_RISCV_ADD/SUB/SET relocations, but we can add them in the future patches. 88421 88422 Passing riscv-gnu-toolchain regressions. 88423 88424 bfd/ChangeLog: 88425 88426 * elfnn-riscv.c (riscv_elf_relocate_section): Take the R_RISCV_SUB6 88427 lower 6 bits as the significant bit. 88428 * elfxx-riscv.c (riscv_elf_add_sub_reloc): Likewise. 88429 884302022-11-23 Mark Harmstone <mark@harmstone.com> 88431 88432 gas: Add --gcodeview option 88433 88434 ld: Add section contributions substream to PDB files 88435 884362022-11-23 GDB Administrator <gdbadmin@sourceware.org> 88437 88438 Automatic date update in version.in 88439 884402022-11-22 John Baldwin <jhb@FreeBSD.org> 88441 88442 aarch64-fbsd: Use a static regset for the TLS register set. 88443 This uses custom collect/supply regset handlers which pass the TLS 88444 register number from the gdbarch_tdep as the base register number. 88445 88446 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88447 884482022-11-22 John Baldwin <jhb@FreeBSD.org> 88449 88450 arm-fbsd: Use a static regset for the TLS register set. 88451 This uses custom collect/supply regset handlers which pass the TLS 88452 register number from the gdbarch_tdep as the base register number. 88453 88454 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88455 884562022-11-22 John Baldwin <jhb@FreeBSD.org> 88457 88458 fbsd-nat: Pass an optional register base to the register set helpers. 88459 This is needed to permit using the helpers for register sets with a 88460 variable base. In particular regnum needs to be converted into a 88461 relative register number before passed to regcache_map_supplies. 88462 88463 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88464 884652022-11-22 John Baldwin <jhb@FreeBSD.org> 88466 88467 fbsd-nat: Use regset supply/collect methods. 88468 fbsd-nat includes various helper routines for fetching and storing 88469 register sets via ptrace where the register set is described by a 88470 regset. These helper routines directly invoke the 88471 supply/collect_regset regcache methods which doesn't permit a regset 88472 to provide custom logic when fetching or storing a register set. 88473 Instead, just use the function pointers from the struct regset 88474 directly. 88475 88476 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88477 884782022-11-22 John Baldwin <jhb@FreeBSD.org> 88479 88480 regcache: Add collect/supply_regset variants that accept a register base. 88481 Some register sets described by an array of regcache_map_entry 88482 structures do not have fixed register numbers in their associated 88483 architecture but do describe a block of registers whose numbers are at 88484 fixed offsets relative to some base register value. An example of 88485 this are the TLS register sets for the ARM and AArch64 architectures. 88486 88487 Currently OS-specific architectures create register maps and register 88488 sets dynamically using the register base number. However, this 88489 requires duplicating the code to create the register map and register 88490 set. To reduce duplication, add variants of the collect_regset and 88491 supply_regset regcache methods which accept a base register number. 88492 For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this 88493 base register number to the value from the map entry to determine the 88494 final register number. 88495 88496 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88497 884982022-11-22 H.J. Lu <hjl.tools@gmail.com> 88499 88500 x86: Don't define _TLS_MODULE_BASE_ for ld -r 88501 bfd/ 88502 88503 PR ld/29820 88504 * elfxx-x86.c (_bfd_x86_elf_always_size_sections): Don't define 88505 _TLS_MODULE_BASE_ for ld -r. 88506 88507 ld/ 88508 88509 PR ld/29820 88510 * testsuite/ld-x86-64/pr29820.d: New file. 88511 * testsuite/ld-x86-64/pr29820.s: Likewise. 88512 * testsuite/ld-x86-64/x86-64.ex: Run pr29820. 88513 885142022-11-22 Alan Modra <amodra@gmail.com> 88515 88516 Don't use "long" in readelf for file offsets 88517 The aim here is to improve readelf handling of large 64-bit object 88518 files on LLP64 hosts (Windows) where long is only 32 bits. The patch 88519 changes more than just file offsets. Addresses and sizes are also 88520 changed to avoid "long". Most places get to use uint64_t even where 88521 size_t may be more appropriate, because that allows some overflow 88522 checks to be implemented easily (*alloc changes). 88523 88524 * dwarf.c (cmalloc, xcmalloc, xcrealloc, xcalloc2): Make nmemb 88525 parameter uint64_t. 88526 * dwarf.h: Update prototypes. 88527 (struct dwarf_section): Make num_relocs uint64_t. 88528 * elfcomm.c (setup_archive): Update error format. 88529 * elfcomm.h (struct archive_info): Make sym_size, longnames_size, 88530 nested_member_origin, next_arhdr_offset uint64_t. 88531 * readelf.c (struct filedata): Make archive_file_offset, 88532 archive_file_size, string_table_length, dynamic_addr, 88533 dynamic_nent, dynamic_strings_length, num_dynamic_syms, 88534 dynamic_syminfo_offset uint64_t. 88535 (many functions): Replace uses of "unsigned long" with 88536 "uint64_t" or "size_t". 88537 885382022-11-22 Alan Modra <amodra@gmail.com> 88539 88540 Re: readelf: use fseeko64 or fseeko if possible 88541 Replace the macros with a small wrapper function that verifies the fseek 88542 offset arg isn't overlarge. 88543 88544 * readelf.c (FSEEK_FUNC): Delete, replace uses with.. 88545 (fseek64): ..this new function. 88546 (process_program_headers): Don't cast p_offset to long. 88547 885482022-11-22 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 88549 88550 gdb/arm: Fix obvious typo in b0b23e06c3a 88551 As part of the rebase of the patch, I managed to loose the local 88552 changes I had for the comments from Tomas in 88553 https://sourceware.org/pipermail/gdb-patches/2022-November/193413.html 88554 This patch corrects the obvious two typos. 88555 885562022-11-22 Michael Matz <matz@suse.de> 88557 88558 binutils/configure.ac: integrate last change 88559 Integrate back checks for fseeko{,64} into configure.ac, so 88560 that regeneration works. 88561 88562 binutils/ 88563 * configure.ac: Add fseeko, fseeko64 checks. 88564 * configure: Regenerate. 88565 885662022-11-22 Shahab Vahedi <shahab@synopsys.com> 88567 88568 opcodes: Correct address for ARC's "isa_config" aux reg 88569 This patch changes the address for "isa_config" auxiliary register 88570 from 0xC2 to the correct value 0xC1. Moreover, it only exists in 88571 arc700+ and not all ARCs. 88572 88573 opcodes/ChangeLog: 88574 88575 * arc-regs.h: Change isa_config address to 0xc1. 88576 isa_config exists for ARC700 and ARCV2 and not ARCALL. 88577 885782022-11-22 Bruno Larsen <blarsen@redhat.com> 88579 88580 gdb/testsuite: remove gcc restriction from gdb.dwarf2/clang-cli-macro.exp 88581 With the recent changes to the dwarf assembler, there is no longer a 88582 need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as 88583 untested. This commit removes that logic. 88584 885852022-11-22 Jan Beulich <jbeulich@suse.com> 88586 88587 gas/sframe: avoid "shadowing" of glibc function name 88588 Once again: Old enough glibc has an (unguarded) declaration of index() 88589 in string.h, which triggers a "shadows a global declaration" warning 88590 with our choice of wanring level and with at least some gcc versions. 88591 885922022-11-22 GDB Administrator <gdbadmin@sourceware.org> 88593 88594 Automatic date update in version.in 88595 885962022-11-21 Brett Werling <bwerl.dev@gmail.com> 88597 88598 readelf: use fseeko64 or fseeko if possible 88599 Changes readelf to make use first of fseeko64 and then fseeko, 88600 depending on which of those is available. If neither is available, 88601 reverts to the previous behavior of using fseek. 88602 88603 This is necessary when building readelf for LLP64 systems, where a 88604 long will only be 32 bits wide. If the elf file in question is >= 2 GiB, 88605 that is greater than the max long value and therefore fseek will fail 88606 indicating that the offset is negative. On such systems, making use of 88607 fseeko64 or fseeko will result in the ability so seek past the 2 GiB 88608 max long boundary. 88609 88610 Note that large archive handling in readelf remains to be fixed. 88611 886122022-11-21 Alan Modra <amodra@gmail.com> 88613 88614 PR29807, SIGSEGV when linking fuzzed PE object 88615 PR 29807 88616 * cofflink.c (_bfd_coff_generic_relocate_section): Skip relocs 88617 against symbols with a NULL section. 88618 886192022-11-21 Alan Modra <amodra@gmail.com> 88620 88621 Re: ld: Always output local symbol for relocatable link 88622 Remove this code dating back to commit 98790d3a95fc entirely, what it 88623 was trying to do is done elsewhere. 88624 88625 PR ld/29761 88626 * elflink.c (elf_link_output_symstrtab): Don't handle symbols 88627 in SEC_EXCLUDE sections here. 88628 886292022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88630 88631 When getting the locno of a bpstat, handle the case of bp with null locations. 88632 The test py-objfile.exp unloads the current file while debugging the process. 88633 This results in bpstat bs->b->loc to become nullptr. 88634 Handle this case in breakpoint.c:bpstat_locno. 88635 88636 Note: GDB crashes on this problem with an internal error, 88637 but the end of gdb summary shows: 88638 ... 88639 === gdb Summary === 88640 88641 # of expected passes 36 88642 88643 The output also does not contain a 'FAIL:'. 88644 After the fix, the nr of expected passes increased. 88645 88646 In the gdb.log output, one can see: 88647 ... 88648 Fatal signal: Segmentation fault 88649 ----- Backtrace ----- 88650 0x55698905c5b9 gdb_internal_backtrace_1 88651 ../../binutils-gdb/gdb/bt-utils.c:122 88652 0x55698905c5b9 _Z22gdb_internal_backtracev 88653 ... 88654 88655 ERROR: Couldn't send python print(objfile.filename) to GDB. 88656 ERROR: : spawn id exp9 not open 88657 while executing 88658 "expect { 88659 -i exp9 -timeout 10 88660 -re ".*A problem internal to GDB has been detected" { 88661 fail "$message (GDB internal error)" 88662 gdb_internal_error..." 88663 ("uplevel" body line 1) 88664 invoked from within 88665 .... 88666 88667 Wondering if it might be possible to improve gdb_test to have 88668 gdb_test "python print(objfile.filename)" "None" \ 88669 "objfile.filename after objfile is unloaded" 88670 reporting a failed result instead of just producing the internal error. 88671 886722022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88673 88674 Fix use after free introduced by $_hit_bpnum/$_hit_locno variables. 88675 If the commands of the bpstat bs contain commands such as step or next or 88676 continue, the BS and its commands are freed by execute_control_command. 88677 88678 So, we cannot remember the BS that was printed. Instead, remember 88679 the bpnum and locno. 88680 88681 Regtested on debian/amd64 and re-run a few tests under valgrind. 88682 886832022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88684 88685 Fix step-over-syscall.exp matching regexp for $bpnum.$locno matching 88686 step-over-syscall.exp has some specific tests for gdbserver. 88687 The regexp matching breakpoint hit must take the added locno into account. 88688 88689 Test re-run in 3 modes (normal, native-gdbserver and native-extended-gdbserver). 88690 886912022-11-21 Nick Clifton <nickc@redhat.com> 88692 88693 Fix ARM and AArch64 assembler tests to work in a multi-arch environment. 88694 PR 29764 88695 gas * testsuite/gas/arm/cpu-cortex-a76ae.d: Add arm prefix to the -m 88696 option passed to objdump. 88697 * testsuite/gas/arm/cpu-cortex-a77.d: Likewise. 88698 * testsuite/gas/aarch64/cpu-cortex-a76ae.d: Add aarch64 prefix to 88699 the -m option passed to objdump. 88700 * testsuite/gas/aarch64/cpu-cortex-a77.d: Likewise. 88701 88702 bfd * cpu-arm.c (scan): Accept machine names prefixed with "arm:". 88703 * cpu-aarch64.c (scan): Accept machine names prefixed with "aarch64:". 88704 88705 bin * doc/binutils.texi (objdump): Note that the -m option supports 88706 the <architecture>:<machine> syntax. 88707 887082022-11-21 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 88709 88710 gdb/arm: Ensure that stack pointers are in sync 88711 For targets with secext, msp and psp can be seen as an alias for one 88712 of msp_s, msp_ns, psp_s or psp_ns. 88713 Without this patch, sp might be secure, but msp or psp is non-secure 88714 (this state can not happen in the hardware). 88715 88716 gdb/arm: Update active msp/psp when switching stack 88717 For targets with secext, msp and psp can be seen as an alias for one 88718 of msp_s, msp_ns, psp_s or psp_ns. When switching active sp, the 88719 corresponding msp/psp needs to be switched too. 88720 887212022-11-21 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 88722 88723 gdb/csky just return type from csky_vector_type() for vector resgisters 88724 Some gdb stubs may not describe the type for vector registers in the 88725 tdesc-xml and only send bitsize="128", gdb can't deal with a reg 88726 with default type int with bitsize==128. So Just return csky_vector_type() 88727 for vector resgisters. 88728 88729 gdb/csky return type int32 for float and vector pseudo regs 88730 When reg_nr is one of the float and vector pseudo registers, 88731 return builtin_type (gdbarch)->builtin_int32 for it. 88732 887332022-11-21 GDB Administrator <gdbadmin@sourceware.org> 88734 88735 Automatic date update in version.in 88736 887372022-11-20 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 88738 88739 [PR build/29791] gnulib: Disable _GL_ATTRIBUTE_DEALLOC on Solaris 88740 gdbsupport compilation badly fails with GCC 12 on Solaris, with errors 88741 like 88742 88743 ../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous 88744 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i))) 88745 | ^ 88746 ../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate 88747 88748 We've not yet been able to determine where the ambiguity actually lies, 88749 so this patch works around the issue by disabling _GL_ATTRIBUTE_DEALLOC 88750 on Solaris, at least as a workaround for GDB 13. 88751 88752 As Tom suggested in the PR, this is done using our infrastructure for 88753 local gnulib patches. 88754 88755 Tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and 88756 x86_64-pc-linux-gnu. 88757 88758 Approved-By: Simon Marchi <simon.marchi@efficios.com> 88759 887602022-11-20 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 88761 88762 Fix sol-thread.c compilation on 32-bit Solaris 88763 sol-thread.c fails to compile on 32-bit Solaris: there are several 88764 instances of 88765 88766 In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203, 88767 from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28, 88768 from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51: 88769 /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’: 88770 /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=] 88771 416 | warning (_("Specified thread %ld seems to have terminated"), 88772 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 88773 /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29: 88774 note: in definition of macro ‘_’ 88775 28 | # define _(String) gettext (String) 88776 | ^~~~~~ 88777 /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format 88778 string is defined here 88779 416 | warning (_("Specified thread %ld seems to have terminated"), 88780 | ~~^ 88781 | | 88782 | long int 88783 | %lld 88784 88785 Fixed by using pulongest () instead. 88786 88787 Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11, 88788 sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with 88789 Simon's patch for PR build/29798). 88790 887912022-11-20 GDB Administrator <gdbadmin@sourceware.org> 88792 88793 Automatic date update in version.in 88794 887952022-11-19 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88796 88797 Add missing gdb_prompt in ctxobj.exp to avoid random failure, fix typo. 88798 ctxobj.exp fails randomly when computer is loaded. 88799 With the addition of $gdb_prompt in the regexp testing for breakpoint hit, 88800 I could not make it fail anymore. 88801 88802 Also fixed a typo in a comment. 88803 888042022-11-19 Philippe Waroquiers <philippe.waroquiers@skynet.be> 88805 88806 Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum $_hit_locno PR breakpoints/12464 88807 This implements the request given in PR breakpoints/12464. 88808 88809 Before this patch, when a breakpoint that has multiple locations is reached, 88810 GDB printed: 88811 Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5 88812 88813 This patch changes the message so that bkpt_print_id prints the precise 88814 encountered breakpoint: 88815 Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5 88816 88817 In mi mode, bkpt_print_id also (optionally) prints a new table field "locno": 88818 locno is printed when the breakpoint hit has more than one location. 88819 Note that according to the GDB user manual node 'GDB/MI Development and Front 88820 Ends', it is ok to add new fields without changing the MI version. 88821 88822 Also, when a breakpoint is reached, the convenience variables 88823 $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number 88824 and location number. 88825 88826 $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a 88827 breakpoint, to disable the specific encountered breakpoint, e.g. 88828 disable $_hit_bpnum.$_hit_locno 88829 88830 In case the breakpoint has only one location, $_hit_locno is set to 88831 the value 1, so as to allow a command such as: 88832 disable $_hit_bpnum.$_hit_locno 88833 to disable the breakpoint even when the breakpoint has only one location. 88834 88835 This also fixes a strange behaviour: when a breakpoint X has only 88836 one location, 88837 enable|disable X.1 88838 is accepted but transforms the breakpoint in a multiple locations 88839 breakpoint having only one location. 88840 88841 The changes in RFA v4 handle the comments of Tom Tromey: 88842 - Changed convenience var names from $bkptno/$locno to 88843 $_hit_bpnum/$_hit_locno. 88844 - updated the tests and user manual accordingly. 88845 User manual also explictly describes that $_hit_locno is set to 1 88846 for a breakpoint with a single location. 88847 - The variable values are now set in bpstat_do_actions_1 so that 88848 they are set for silent breakpoints, and when several breakpoints 88849 are hit at the same time, that the variables are set to the printed 88850 breakpoint. 88851 88852 The changes in RFA v3 handle the additional comments of Eli: 88853 GDB/NEW: 88854 - Use max 80-column 88855 - Use 'code location' instead of 'location'. 88856 - Fix typo $bkpno 88857 - Ensure that disable $bkptno and disable $bkptno.$locno have 88858 each their explanation inthe example 88859 - Reworded the 'breakpoint-hit' paragraph. 88860 gdb.texinfo: 88861 - Use 'code location' instead of 'location'. 88862 - Add a note to clarify the distinction between $bkptno and $bpnum. 88863 - Use @kbd instead of examples with only one command. 88864 88865 Compared to RFA v1, the changes in v2 handle the comments given by 88866 Keith Seitz and Eli Zaretskii: 88867 - Use %s for the result of paddress 88868 - Use bkptno_numopt_re instead of 2 different -re cases 88869 - use C@t{++} 88870 - Add index entries for $bkptno and $locno 88871 - Added an example for "locno" in the mi interface 88872 - Added examples in the Break command manual. 88873 888742022-11-19 Tsukasa OI <research_trasio@irq.a4lg.com> 88875 88876 RISC-V: Add 'Ssstateen' extension and its CSRs 88877 This commit adds 'Ssstateen' extension, which is a supervisor-visible view 88878 of the 'Smstateen' extension. It means, this extension implements sstateen* 88879 and hstateen* CSRs of the 'Smstateen' extension. 88880 88881 Note that 'Smstateen' extension itself is unchanged but due to 88882 implementation simplicity, it is implemented so that 'Smstateen' implies 88883 'Ssstateen' (just like 'M' implies 'Zmmul'). 88884 88885 This is based on the latest version of RISC-V Profiles 88886 (version 0.9-draft, Frozen): 88887 <https://github.com/riscv/riscv-profiles/commit/226b7f643067b29abc6723fac60d5f6d3f9eb901> 88888 88889 bfd/ChangeLog: 88890 88891 * elfxx-riscv.c (riscv_implicit_subsets): Update implication rules. 88892 (riscv_supported_std_s_ext) Add 'Ssstateen' extension. 88893 88894 gas/ChangeLog: 88895 88896 * config/tc-riscv.c (enum riscv_csr_class): Rename 88897 CSR_CLASS_SMSTATEEN_AND_H{,_32} to CSR_CLASS_SSSTATEEN_... 88898 Add CSR_CLASS_SSSTATEEN. 88899 (riscv_csr_address): Support new/renamed CSR classes. 88900 * testsuite/gas/riscv/csr.s: Add 'Ssstateen' extension to comment. 88901 * testsuite/gas/riscv/csr-version-1p9p1.l: Reflect changes to 88902 error messages. 88903 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 88904 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 88905 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 88906 * testsuite/gas/riscv/ssstateen-csr.s: Test for 'Ssstateen' CSRs. 88907 * testsuite/gas/riscv/ssstateen-csr.d: Likewise. 88908 * testsuite/gas/riscv/smstateen-csr-s.d: Test to make sure that 88909 supervisor/hypervisor part of 'Smstateen' CSRs are accessible from 88910 'RV32IH_Smstateen', not just from 'RV32IH_Ssstateen' that is tested 88911 in ssstateen-csr.d. 88912 88913 include/ChangeLog: 88914 88915 * opcode/riscv-opc.h: Update DECLARE_CSR declarations with 88916 new CSR classes. 88917 889182022-11-19 GDB Administrator <gdbadmin@sourceware.org> 88919 88920 Automatic date update in version.in 88921 889222022-11-18 Simon Marchi <simon.marchi@efficios.com> 88923 88924 gdbserver/linux-x86: move lwp declaration out of __x86_64__ region 88925 Commit 4855cbdc3d8f ("gdbserver/linux-x86: make is_64bit_tdesc accept 88926 thread as a parameter") caused this when building in 32 bits / i386 88927 mode: 88928 88929 CXX linux-x86-low.o 88930 In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24: 88931 /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’: 88932 /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope 88933 357 | struct thread_info *thr = get_lwp_thread (lwp); 88934 | ^~~ 88935 /home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’ 88936 709 | #define get_lwp_thread(lwp) ((lwp)->thread) 88937 | ^~~ 88938 88939 This is because it moved the lwp variable declaration inside the 88940 __x86_64__ guard, making it unavailable when building in 32 bits mode. 88941 Move the lwp variable outside of the __x86_64__ region. 88942 88943 Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05 88944 889452022-11-18 Simon Marchi <simon.marchi@efficios.com> 88946 88947 gdbserver: use current_process in ps_getpid 88948 The following patch ("gdbserver: switch to right process in 88949 find_one_thread") makes it so find_one_thread calls into libthread_db 88950 with a current process but no current thread. This tripped on ps_getpid 88951 using current_thread in order to get the process' pid. Get the pid from 88952 `current_process ()` instead, which removes the need to have a current 88953 thread. Eventually, it would be good to get it from the 88954 gdb_ps_prochandle_t structure, to avoid the need for a current process 88955 as well. 88956 88957 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 88958 Change-Id: I9d2fae266419199a2fbc2fde0a5104c6e0dbd2d5 88959 889602022-11-18 Simon Marchi <simon.marchi@efficios.com> 88961 88962 gdbserver/linux-x86: make is_64bit_tdesc accept thread as a parameter 88963 ps_get_thread_area receives as a parameter the lwpid it must work on. 88964 It then calls is_64bit_tdesc, which uses the current_thread as the 88965 thread to work on. However, it is not said that both are the same. 88966 88967 This became a problem when working in a following patch that makes 88968 find_one_thread switch to a process but to no thread (current_thread == 88969 nullptr). When libthread_db needed to get the thread area, 88970 is_64bit_tdesc would try to get the regcache of a nullptr thread. 88971 88972 Fix that by making is_64bit_tdesc accept the thread to work on as a 88973 parameter. Find the right thread from the context, when possible (when 88974 we know the lwpid to work on). Otherwise, pass "current_thread", to 88975 retain the existing behavior. 88976 88977 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 88978 Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007 88979 889802022-11-18 Simon Marchi <simon.marchi@polymtl.ca> 88981 88982 gdbserver/linux: take condition out of callback in find_lwp_pid 88983 Just a small optimization, it's not necessary to recompute lwp at each 88984 iteration. 88985 88986 While at it, change the variable type to long, as ptid_t::lwp returns a 88987 long. 88988 88989 Reviewed-By: Andrew Burgess <aburgess@redhat.com> 88990 Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105 88991 889922022-11-18 Johnson Sun <j3.soon777@gmail.com> 88993 88994 Fix deletion of FinishBreakpoints 88995 Currently, FinishBreakpoints are set at the return address of a frame based on 88996 the `finish' command, and are meant to be temporary breakpoints. However, they 88997 are not being cleaned up after use, as reported in PR python/18655. This was 88998 happening because the disposition of the breakpoint was not being set 88999 correctly. 89000 89001 This commit fixes this issue by correctly setting the disposition in the 89002 post-stop hook of the breakpoint. It also adds a test to ensure this feature 89003 isn't regressed in the future. 89004 89005 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655 89006 890072022-11-18 Simon Marchi <simon.marchi@polymtl.ca> 89008 89009 gdb: fix symtab.c build on 32 bit targets 89010 When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get: 89011 89012 CXX symtab.o 89013 /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function ‘std::vector<symbol_search> global_symbol_searcher::search() const’: 89014 /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=] 89015 4961 | sprintf (tmp, "operator%.*s%s", fix, " ", opname); 89016 | ^ 89017 In file included from /usr/include/stdio.h:894, 89018 from ../gnulib/import/stdio.h:43, 89019 from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86, 89020 from /home/smarchi/src/binutils-gdb/gdb/defs.h:28, 89021 from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20: 89022 In function ‘int sprintf(char*, const char*, ...)’, 89023 inlined from ‘std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16: 89024 /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647 89025 38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, 89026 | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89027 39 | __glibc_objsize (__s), __fmt, 89028 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89029 40 | __va_arg_pack ()); 89030 | ~~~~~~~~~~~~~~~~~ 89031 89032 PR build/29798 shows a similar error message but on Solaris. 89033 89034 Work around that by using string_printf. It is a good thing to get rid 89035 of the alloca anyway. 89036 89037 Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9 89038 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798 89039 890402022-11-18 Andrew Burgess <aburgess@redhat.com> 89041 89042 gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assembler 89043 Convert the gdb.cp/call-method-register.exp test to make use of the 89044 DWARF assembler. 89045 89046 The existing gdb.cp/call-method-register.exp test relies on a GCC 89047 extension - forcing a local variable into a particular named register. 89048 89049 This means that the test will only work with Clang, and, as we have to 89050 name the register into which the variable will be placed, will only 89051 work for those targets where we've selected a suitable register, 89052 currently this is x86-64, i386, and ppc64. 89053 89054 By switching to the DWARF assembler, the test will work with gcc and 89055 clang, and should work on most, if not all, architectures. 89056 89057 The test creates a small structure, something that can fit within a 89058 register, and then tries to call a method on the structure from within 89059 GDB. This should fail because GDB can't take the address of the in 89060 register structure (for the `this` pointer). 89061 89062 As the test is for a failure case, then we don't really care _which_ 89063 register the structure is in, and I take advantage of this for the 89064 DWARF assembler test, I just declare that the variable is in 89065 DW_OP_reg0, whatever that might be. I've tested the new test on 89066 x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all 89067 these architectures, which is already more than we used to cover. 89068 89069 Additionally, on x86-64, I've tested with Clang and gcc, and the test 89070 runs and passed with both compilers. 89071 89072 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 89073 890742022-11-18 Andrew Burgess <aburgess@redhat.com> 89075 89076 gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with Clang 89077 The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single 89078 failure when run with some older versions of Clang, e.g. 9.0.1. 89079 89080 The problem appears to be with Clang's generated line table. The test 89081 source looks like this: 89082 89083 int 89084 main() 89085 { 89086 asm ("main_label: .globl main_label"); 89087 return 0; 89088 } 89089 89090 In GDB, when we 'start', we expect to stop at the 'return 0;' line. 89091 This is the behaviour when the compiler is gcc, or later versions of 89092 Clang. 89093 89094 However, with Clang 9.0.2, I see GDB stop on the 'asm' line. 89095 89096 In this commit I'll fix this issue by placing a breakpoint on the 89097 return line, and then using gdb_continue_to_breakpoint to ensure we 89098 have stopped in the correct place. 89099 89100 Of course, using gdb_continue_to_breakpoint will only work if we are 89101 not already stopped at the breakpoint location, so I've added some 89102 filler work before the 'return 0;' line. With this done we can use 89103 gdb_continue_to_breakpoint in all cases. 89104 89105 As a result of adding the new filler work, one of the later tests, 89106 that used the 'list' command, no longer see the correct expected 89107 output (the top line of the source file is no longer included in the 89108 output). I've fixed this by listing a known specific line, the test 89109 is checking that GDB managed to find the source file, it doesn't 89110 matter which source line we list, as long as we can list something. 89111 891122022-11-18 Andrew Burgess <aburgess@redhat.com> 89113 89114 gdb/testsuite: rename source file gdb.debuginfod/main.c 89115 The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file 89116 named main.c. I can't see any particular reason why the file is named 89117 as such. 89118 89119 Usually test source files are named after the test script. 89120 89121 This commit just renames the source file inline with the test script, 89122 and updates the call to standard_testfile (removing the reference to 89123 main.c). 89124 89125 There's no particular reason for this change other than seeing the 89126 file named main.c made me thing that the source file must be shared 89127 with some other test (it isn't). 89128 89129 There should be no change in what is tested after this commit. 89130 891312022-11-18 Andrew Burgess <aburgess@redhat.com> 89132 89133 gdb/testsuite: add (and use) a new build-id compile option 89134 I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was 89135 failing when run with Clang as the compiler. 89136 89137 This test relies on the compiled binaries having a build-id within 89138 them. For GCC, really GNU ld, the default is to always include a 89139 build-id. 89140 89141 When compiling with Clang though, the default is for no build-id. 89142 89143 I did consider *always* turning on the build-id feature when the 89144 compiler is Clang, but that felt a little weird. 89145 89146 Instead, I propose that we add a new 'build-id' compiler option to 89147 gdb_compile, this flag indicates that the test _requires_ a build-id. 89148 In gcc_compile we can then add the required flags if the compiler is 89149 Clang so that we do get a build-id. 89150 89151 With this change the gdb.debuginfod/fetch_src_and_symbols.exp test 89152 now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with 89153 gcc. The 'mostly' part is an unrelated issue, and will be addressed 89154 in a later commit in this series. 89155 89156 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 89157 891582022-11-18 Andrew Burgess <aburgess@redhat.com> 89159 89160 gdb/testsuite: fix gdb.compile/compile-ops.exp with clang 89161 I noticed that the gdb.compile/compile-ops.exp test was failing when 89162 run with Clang as the compiler. 89163 89164 This test makes use of the DWARF assembler, and, it turns out, uses 89165 a technique which is not portable to Clang. This problem is 89166 described in the comment on the function_range proc in lib/dwarf.exp, 89167 the explanation is: 89168 89169 # If the compiler is gcc, we can do the following to get function start 89170 # and end address too: 89171 # 89172 # asm ("func_start: .globl func_start"); 89173 # static void func (void) {} 89174 # asm ("func_end: .globl func_end"); 89175 # 89176 # however, this isn't portable, because other compilers, such as clang, 89177 # may not guarantee the order of global asms and function. The code 89178 # becomes: 89179 # 89180 # asm ("func_start: .globl func_start"); 89181 # asm ("func_end: .globl func_end"); 89182 # static void func (void) {} 89183 89184 These start/end labels are used for computing the function start, end, 89185 and length. The portable solution is to place a label within the 89186 function, like this: 89187 89188 # int main (void) 89189 # { 89190 # asm ("main_label: .globl main_label"); 89191 # return 0; 89192 # } 89193 89194 And make use of 'proc function_range' (from lib/dwarf.exp). 89195 89196 So, that's what I do in this commit. 89197 89198 One consequence of this change is that we need to compile the source 89199 file, and have it loaded into a GDB session, before calling 89200 function_range, so I've added an early call to prepare_for_testing. 89201 89202 Additionally, this test script was generating the DWARF assembler into 89203 a file called gdbjit-ops.S, I suspect a copy and paste issue there, so 89204 I've switched this to use compile-ops-dbg.S instead, which is more 89205 inline with what other DWARF assembler tests do. 89206 89207 The only other change, which might be a problem, is that I also 89208 deleted these two lines from the source file: 89209 89210 asm (".section \".text\""); 89211 asm (".balign 8"); 89212 89213 These lines were setting the alignment of the .text section. What I 89214 don't know is whether this was significant or not. If it is 89215 significant, then I can't see why. 89216 89217 On x86-64, the test still passes fine without these lines, but that 89218 doesn't mean the test wont start failing on some other architecture. 89219 89220 Still, I figure, lets remove them, then, if/when we find a test that 89221 starts failing, we can add the lines back, along with an explanation 89222 for why the extra alignment is required. 89223 89224 But, if people would prefer to be more conservative, then I'm happy to 89225 just add the lines back. 89226 89227 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 89228 892292022-11-18 Andrew Burgess <aburgess@redhat.com> 89230 89231 gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang 89232 I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was 89233 failing when run with Clang. Or rather, the test was not running as 89234 the test executable failed to compile. 89235 89236 The problem is that Clang was emitting this warning: 89237 89238 warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] 89239 89240 This warning is emitted when compiling the assembler file generated 89241 by the DWARF assembler. 89242 89243 Most DWARF assembler tests generate the assembler file into a file 89244 with the '.S' extension. However, this particular test uses a '.s' 89245 extension. 89246 89247 Now a .S file will be passed through the preprocessor, while a .s will 89248 be sent straight to the assembler. My guess is that Clang doesn't 89249 support the -fdiagnostics-color=never option for the assembler, but 89250 does for the preprocessor. 89251 89252 That's a little annoying, but easily worked around. We don't care if 89253 our assembler file is passed through the preprocessor, so, in this 89254 commit, I just change the file extension from .s to .S, and the 89255 problem is fixed. 89256 89257 Currently, the unavailable-dwarf-piece.exp script names the assembler 89258 file using standard_output_file, in this commit I've switched to make 89259 use of standard_testfile, as that seems to be the more common way of 89260 doing this sort of thing. 89261 89262 With these changes the test now passes with Clang 9.0.1 and 15.0.2, 89263 and also still passes with gcc. 89264 89265 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 89266 892672022-11-18 Andrew Burgess <aburgess@redhat.com> 89268 89269 gdb/testsuite: don't avoid DWARF assembler tests with Clang 89270 Two tests make the claim that the DWARF assembler requires gcc, 89271 however, this isn't true. I think at one point, when the DWARF 89272 assembler was first added, we did use some techniques that were not 89273 portable (see the comments in lib/dwarf.exp on function_range for 89274 details), however, I think most DWARF assembler tests will now work 89275 fine with Clang. 89276 89277 The two tests that I modify in this commit both work fine with Clang, 89278 at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any 89279 problems, so I'm removing the early return logic that stops these 89280 tests from running with Clang. 89281 89282 Reviewed-By: Lancelot SIX <lancelot.six@amd.com> 89283 892842022-11-18 Zac Walker <zac.walker@linaro.org> 89285 89286 GAS fix alignment for aarch64-pe 89287 Fixes issue where various values of '.align' causes writing of COFF files to fail. 89288 Specific to the aarch64-pe target. 89289 892902022-11-18 Alan Modra <amodra@gmail.com> 89291 89292 PR29799 heap buffer overflow in display_gdb_index dwarf.c:10548 89293 PR 29799 89294 * dwarf.c (display_gdb_index): Typo fix. 89295 89296 go32 sanity check 89297 * coff-stgo32 (go32exe_check_format): Sanity check stubsize against 89298 filesize before malloc. 89299 89300 Regen potfiles for sframe 89301 893022022-11-18 GDB Administrator <gdbadmin@sourceware.org> 89303 89304 Automatic date update in version.in 89305 893062022-11-17 Indu Bhagat <indu.bhagat@oracle.com> 89307 89308 [gas, aarch64]: fix build breakage for aarch64-pe 89309 SFrame is supported for ELF only. Keep the definitions and declarations 89310 guarded with OBJ_ELF consistently. 89311 89312 ChangeLog: 89313 89314 * gas/config/tc-aarch64.h: Guard SFrame related definitions 89315 with OBJ_ELF. 89316 893172022-11-17 Tom Tromey <tromey@adacore.com> 89318 89319 Fix static initialization order problem in windows-nat.c 89320 This patch fixes a static initialization order problem in 89321 windows-nat.c that was pointed out by Jon Turney. The underlying 89322 problem is that the windows_nat_target constructor relies on 89323 serial_logfile already being constructed, but this is not enforced by 89324 C++ rules. This patch fixes the problem by initializing the global 89325 windows_nat_target later. 89326 893272022-11-17 H.J. Lu <hjl.tools@gmail.com> 89328 89329 opcodes: Define NoSuf in i386-opc.tbl 89330 Use NoSuf to replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf 89331 and add the explicit NoSuf to AddrPrefixOpReg in templates. 89332 89333 * i386-opc.tbl (NoSuf): New macro. 89334 (AddrPrefixOpReg): Remove No_?Suf. 89335 Replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf with 89336 NoSuf in templates. 89337 Add NoSuf to AddrPrefixOpReg in templates. 89338 893392022-11-17 H.J. Lu <hjl.tools@gmail.com> 89340 89341 i386: Move i386_seg_prefixes to gas 89342 gas/ 89343 89344 * config/tc-i386.c (i386_seg_prefixes): New. Moved from opcodes. 89345 89346 opcodes/ 89347 89348 * i386-opc.c (i386_seg_prefixes): Removed. 89349 * i386-opc.h (i386_seg_prefixes): Likewise. 89350 893512022-11-17 Carl Love <cel@us.ibm.com> 89352 89353 PowerPC, fix gdb.base/retval-large-struct.exp 89354 Support for printining non-trivial return values was recently added in 89355 commit: 89356 89357 commit a0eda3df5b750ae32576a9be092b361281a41787 89358 Author: Carl Love <cel@us.ibm.com> 89359 Date: Mon Nov 14 16:22:37 2022 -0500 89360 89361 PowerPC, fix support for printing the function return value for non-trivial values. 89362 89363 The functionality can now be used to fix gdb.base/retval-large-struct.exp. 89364 The test just needs to be compiled with -fvar-tracking to enable GDB to 89365 determine the address off the return buffer when the function is called. 89366 89367 The current output from the test: 89368 89369 34 return big_struct; 89370 (gdb) PASS: gdb.base/retval-large-struct.exp: continue to breakpoint: Break in print_large_struct 89371 finish 89372 warning: Cannot determine the function return value. 89373 Try compiling with -fvar-tracking. 89374 Run till exit from #0 return_large_struct () at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:34 89375 main (argc=1, argv=0x7fffffffcd58) at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:44 89376 44 return 0; 89377 Value returned has type: struct big_struct_t. Cannot determine contents 89378 (gdb) FAIL: gdb.base/retval-large-struct.exp: finish from return_large_struct 89379 testcase binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.exp completed in 1 seconds 89380 89381 This patch adds the command line argument -fvar-tracking to enable gdb to 89382 determine the return vaule and thus fixing the test. 89383 89384 Patch tested on Power 10 with no regressions. 89385 893862022-11-17 Tom Tromey <tromey@adacore.com> 89387 89388 Use boolean literals for pagination_enabled 89389 I noticed a couple of spots that used '0' rather than 'false' when 89390 modifying pagination_enabled. This patch cleans these up. 89391 893922022-11-17 Carl Love <cel@us.ibm.com> 89393 89394 Change NULL to nullptr in gdb/infcmd.c and gdb/infrun.c 89395 The GDB coding standard specifies that nullptr should be used instead of 89396 NULL. There are numerous uses of NULL and nullptr in files infcmd.c and 89397 infrun.c. This patch replaces the various uses of NULL with nullptr in 89398 the source files. The use of NULL in the comments was not changed. 89399 89400 The patch does not introduce any functional changes. 89401 89402 The patch has been tested on PowerPC and Intel X86_64 with no new unexpected 89403 test failures, unresolved tests, new core files etc. 89404 894052022-11-17 H.J. Lu <hjl.tools@gmail.com> 89406 89407 ld: Always call elf_backend_output_arch_local_syms 89408 Always call elf_backend_output_arch_local_syms since only the backend 89409 knows if elf_backend_output_arch_local_syms is needed when all symbols 89410 are striped. elf_backend_output_arch_local_syms is defined only for 89411 x86, ARM and AARCH64. On x86, elf_backend_output_arch_local_syms must 89412 be called to handle local IFUNC symbols even if all symbols are striped. 89413 Update ARM and AARCH64 to skip elf_backend_output_arch_local_syms when 89414 symbols aren't needed. 89415 89416 bfd/ 89417 89418 PR ld/29797 89419 * elf32-arm.c (elf32_arm_output_arch_local_syms): Skip if symbols 89420 aren't needed. 89421 * elfnn-aarch64.c (elfNN_aarch64_output_arch_local_syms): 89422 Likewise. 89423 * elflink.c (bfd_elf_final_link): Always call 89424 elf_backend_output_arch_local_syms if available. 89425 89426 ld/ 89427 89428 PR ld/29797 89429 * testsuite/ld-elf/linux-x86.exp: Run PR ld/29797 test. 89430 * testsuite/ld-elf/pr29797.c: New file. 89431 894322022-11-17 Andrew Burgess <aburgess@redhat.com> 89433 89434 gdb: new $_inferior_thread_count convenience variable 89435 Add a new convenience variable $_inferior_thread_count that contains 89436 the number of live (non-exited) threads in the current inferior. This 89437 can be used in command scripts, or breakpoint conditions, etc to 89438 adjust the behaviour for multi-threaded inferiors. 89439 89440 This value is only stable in all-stop mode. In non-stop mode, where 89441 new threads can be started, and existing threads exit, at any time, 89442 this convenience variable can give a different value each time it is 89443 evaluated. 89444 894452022-11-17 Tom Tromey <tromey@adacore.com> 89446 89447 Remove two obsolete declarations 89448 I happened to find a couple of obsolete declarations in cli-interp.h. 89449 This patch removes them. Tested by rebuilding. 89450 894512022-11-17 Andrew Burgess <aburgess@redhat.com> 89452 89453 gdb/testsuite: fix failure in gdb.python/py-send-packet.exp 89454 While working on another patch I noticed that, when run on an AArch64 89455 target, the test gdb.python/py-send-packet.exp was failing: 89456 89457 Traceback (most recent call last): 89458 File "<string>", line 1, in <module> 89459 File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py", 89460 line 106, in run_auxv_send_packet_test 89461 assert string == expected_result 89462 AssertionError 89463 Error while executing Python code. 89464 (gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function 89465 89466 The test uses 'maint packet ...' to send a packet to gdbserver, and 89467 then captures the output in TCL. This output is then passed through 89468 to a Python function, which performs some actions using the Python 89469 API, and compares the results from the Python API to the results 89470 captured in TCL from 'maint packet ...'. 89471 89472 The problem is that the output captured in TCL contains lots of things 89473 like '\x000', when this is passed through to Python the '\x' causes 89474 this to be treated as an escape code, which isn't what we want - we 89475 want the actual string "\x000". 89476 89477 So, in the TCL part of the test we were expanding '\x' to '\\x', this 89478 seemed to work fine for my testing on x86-64. 89479 89480 However, on AArch64 what I see is that the results from 'maint packet 89481 ...' contain a literal '\' character followed by a literal 'x' 89482 character. When GDB prints this in the 'maint packet' output, GDB 89483 escapes the '\' for us, thus we get '\\x' printed by 'maint packet'. 89484 89485 However, now our TCL test script kicks in and tries to "fix" the '\x', 89486 this means we now have '\\\x', which isn't correct. 89487 89488 The problem is that in the TCL script we are too restrictive, we 89489 expand '\x' to '\\x', but really, we should be expanding all '\' 89490 characters, regardless of what follows them. This is what this patch 89491 does. 89492 89493 After this the gdb.python/py-send-packet.exp test passes on AArch64 89494 for me. 89495 894962022-11-17 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 89497 89498 Fix call functions command bug in 64 bits programs for AIX 89499 In AIX for 64 bit programs we need to zero extend variables 89500 of integer or enum or char data type. 89501 89502 Otherwise a zero will get dumped in the register as we memset 89503 our word to 0 and we copy non zero extended contents to the cache. 89504 895052022-11-17 Andrew Burgess <aburgess@redhat.com> 89506 89507 gdb/fortran/testsuite: print values and types of string variables 89508 While looking through the Fortran tests, I couldn't find a test of GDB 89509 printing the value and type of a Fortran string defined using the 89510 'character*SIZE' notation. 89511 89512 This works fine in GDB right now, but I thought it wouldn't hurt to 89513 have a test for this, so this commit adds such a test. 89514 89515 The test also includes printing a string that includes some embedded 89516 special characters: \n \r \t \000 - that's right, as Fortran strings 89517 are stored as an address and length, it is fine to include an embedded 89518 null, so this test includes an example of that. 89519 89520 Standard Fortran doesn't support backslash escape sequences within 89521 strings, the special characters must be generated using the `achar` 89522 function. However, when GDB prints the strings we currently print 89523 using the standard C like backslash sequences. 89524 89525 I'm not currently proposing to change that behaviour, the backslash 89526 sequences are more compact than the standard Fortran way of doing 89527 things, and are so widely used that I suspect most Fortran programmers 89528 will understand them. 89529 895302022-11-17 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 89531 89532 Fix various procfs.c compilation errors 89533 procfs.c has accumulated several compilation errors lately (some of them 89534 new with GCC 12), which are fixed by this patch: 89535 89536 * auxv_parse gets: 89537 89538 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error: ‘int 89539 procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)’ 89540 marked ‘override’, but does not override 89541 144 | int auxv_parse (gdb_byte **readptr, 89542 | ^~~~~~~~~~ 89543 89544 Obviouly, procfs.c was missed in the auxv_parse constification. 89545 89546 * dead_procinfo has: 89547 89548 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function ‘void 89549 dead_procinfo(procinfo*, const char*, int)’: 89550 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address 89551 of ‘procinfo::pathname’ will never be NULL [-Waddress] 89552 563 | if (pi->pathname) 89553 | ~~~~^~~~~~~~ 89554 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note: 89555 ‘procinfo::pathname’ declared here 89556 238 | char pathname[MAX_PROC_NAME_SIZE]; /* Pathname to /proc entry */ 89557 | ^~~~~~~~ 89558 89559 The warning is correct, so the code can lose support for the NULL 89560 pathname case. 89561 89562 * create_inferior has this ugly warning: 89563 89564 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)’: 89565 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: ‘char* std::strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] 89566 2815 | strncpy (tryname, p, len); 89567 | ~~~~~~~~^~~~~~~~~~~~~~~~~ 89568 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed here 89569 2814 | len = strlen (p); 89570 | ~~~~~~~^~~ 89571 89572 It seems that this is another case of GCC PR middle-end/88059, which 89573 Martin Sebor refuses to fix. So I'm using the hack suggested in the 89574 PR to use memcpy instead of strncpy. 89575 89576 * find_memory_regions_callback fails with 89577 89578 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function ‘int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)’: 89579 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few arguments to function 89580 3167 | return (*func) ((CORE_ADDR) map->pr_vaddr, 89581 | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ 89582 3168 | map->pr_size, 89583 | ~~~~~~~~~~~~~ 89584 3169 | (map->pr_mflags & MA_READ) != 0, 89585 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89586 3170 | (map->pr_mflags & MA_WRITE) != 0, 89587 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89588 3171 | (map->pr_mflags & MA_EXEC) != 0, 89589 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89590 3172 | 1, /* MODIFIED is unknown, pass it as true. */ 89591 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89592 3173 | data); 89593 | ~~~~~ 89594 89595 Again, procfs.c was overlooked when adding the new memory_tagged arg. 89596 Unfortunately, it wasn't even documented in gdb/defs.h when it was 89597 added in 89598 89599 commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1 89600 Author: Luis Machado <luis.machado@arm.com> 89601 Date: Thu Mar 31 11:42:35 2022 +0100 89602 89603 [AArch64] MTE corefile support 89604 89605 With those changes, procfs.c compiles again. Together with the hack 89606 from the Solaris gdbsupport breakage reported in PR build/29791, I was 89607 able to build and test gdb on both amd64-pc-solaris2.11 and 89608 sparcv9-sun-solaris2.11. 89609 89610 Approved-By: Simon Marchi <simon.marchi@efficios.com> 89611 896122022-11-17 Christoph Müllner <christoph.muellner@vrull.eu> 89613 89614 RISC-V: Add T-Head Int vendor extension 89615 This patch adds the XTheadInt extension, which provides interrupt 89616 stack management instructions. 89617 89618 The XTheadFmv extension is documented in the RISC-V toolchain 89619 contentions: 89620 https://github.com/riscv-non-isa/riscv-toolchain-conventions 89621 89622 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 89623 896242022-11-17 Christoph Müllner <christoph.muellner@vrull.eu> 89625 89626 RISC-V: Add T-Head Fmv vendor extension 89627 This patch adds the XTheadFmv extension, which allows to access the 89628 upper 32 bits of a double-precision floating-point register in RV32. 89629 89630 The XTheadFmv extension is documented in the RISC-V toolchain 89631 contentions: 89632 https://github.com/riscv-non-isa/riscv-toolchain-conventions 89633 89634 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 89635 896362022-11-17 Tom de Vries <tdevries@jostaberry-8.arch.suse.de> 89637 89638 [gdb/testsuite] Fix DUPLICATE in gdb.arch/ppc-fp.exp 89639 I noticed: 89640 ... 89641 DUPLICATE: gdb.arch/ppc-fp.exp: next 89642 ... 89643 89644 Fix this by adding unique test names. 89645 89646 Tested on powerpc64le-linux. 89647 896482022-11-17 GDB Administrator <gdbadmin@sourceware.org> 89649 89650 Automatic date update in version.in 89651 896522022-11-16 Kévin Le Gouguec <legouguec@adacore.com> 89653 89654 Add myself to the gdb/MAINTAINERS write-after-approval list 89655 896562022-11-16 Kévin Le Gouguec <legouguec@adacore.com> 89657 89658 Guard against frame.c destructors running before frame-info.c's 89659 On x86_64-windows, since 04e2ac7b2a7, we observe this internal error: 89660 89661 [...]/gdbsupport/intrusive_list.h:458: internal-error: erase_element: 89662 Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed. 89663 89664 Breaking in the destructors for intrusive_list and frame_info_ptr shows that 89665 in this configuration, the destructors for frame.c's statically-stored 89666 objects are run before frame-info.c's: 89667 89668 Thread 1 hit Breakpoint 7, intrusive_list<frame_info_ptr, 89669 intrusive_base_node<frame_info_ptr> >::~intrusive_list (this=0x7ff69c418c90 89670 <frame_info_ptr::frame_list>, __in_chrg=<optimized out>) 89671 [...]/../gdbsupport/intrusive_list.h:250 89672 250 clear (); 89673 (gdb) bt 89674 #0 intrusive_list<frame_info_ptr, intrusive_base_node<frame_info_ptr> > 89675 ::~intrusive_list (this=0x7ff69c418c90 <frame_info_ptr::frame_list>, 89676 __in_chrg=<optimized out>) [...]/../gdbsupport/intrusive_list.h:250 89677 #1 0x00007ff69b78edba in __tcf_1 () [...]/frame-info.c:27 89678 #2 0x00007ff9c457aa9f in msvcrt!_initterm_e () 89679 from C:\Windows\System32\msvcrt.dll 89680 #3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00) 89681 [...]/main.c:1111 89682 #4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320 89683 #5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345 89684 #6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32 89685 (gdb) c 89686 Continuing. 89687 89688 Thread 1 hit Breakpoint 8, frame_info_ptr::~frame_info_ptr 89689 (this=0x7ff69c418e20 <selected_frame>, __in_chrg=<optimized out>) 89690 [...]/frame-info.h:74 89691 74 if (is_linked ()) 89692 (gdb) bt 89693 #0 frame_info_ptr::~frame_info_ptr (this=0x7ff69c418e20 <selected_frame>, 89694 __in_chrg=<optimized out>) [...]/frame-info.h:74 89695 #1 0x00007ff69b79a643 in __tcf_1 () [...]/frame.c:1675 89696 #2 0x00007ff9c457aa9f in msvcrt!_initterm_e () from 89697 C:\Windows\System32\msvcrt.dll 89698 #3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00) 89699 [...]/main.c:1111 89700 #4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320 89701 #5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345 89702 #6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32 89703 89704 Approved-By: Simon Marchi <simon.marchi@efficios.com> 89705 897062022-11-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 89707 89708 PR29788, gprofng cannot display Java's generated assembly code 89709 gprofng/ChangeLog 89710 2022-11-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 89711 89712 PR gprofng/29788 89713 * src/Experiment.h: Declare dyntext_name. 89714 * src/Experiment.cc: Use dyntext_name to initialize img_fname. 89715 897162022-11-16 Tom de Vries <tdevries@suse.de> 89717 89718 [gdb/testsuite] Use gdb_gcore_cmd in gdb.threads/gcore-thread.exp 89719 I noticed a plain gcore command in test-case gdb.threads/gcore-thread.exp: 89720 ... 89721 gdb_test "gcore $core0file" "Saved corefile .*" \ 89722 "save a zeroed-threads corefile" 89723 ... 89724 89725 Use gdb_gcore_cmd instead. 89726 89727 Tested on x86_64-linux. 89728 897292022-11-16 Carl Love <cel@us.ibm.com> 89730 89731 Bug fix in commit for printing the function return value for non-trivial values 89732 The recent commit: 89733 89734 commit a0eda3df5b750ae32576a9be092b361281a41787 89735 Author: Carl Love <cel@us.ibm.com> 89736 Date: Mon Nov 14 16:22:37 2022 -0500 89737 89738 PowerPC, fix support for printing the function return value for non-trivial values. 89739 89740 Is generating a segmentation fault on x86_64-linux. 89741 89742 segfault: 89743 ... 89744 PASS: gdb.asm/asm-source.exp: info source asmsrc1.s 89745 ERROR: GDB process no longer exists 89746 UNRESOLVED: gdb.asm/asm-source.exp: finish from foo3 89747 ... 89748 89749 Reproduced on command line: 89750 ... 89751 $ gdb -q -batch -x outputs/gdb.asm/asm-source/gdb.in.1 89752 ... 89753 89754 The problem seems to be that: 89755 ... 89756 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 89757 0x000000000043de7a in symbol::type (this=0x0) at 89758 .../gdb_versions/devel/src/gdb/symtab.h:1287 89759 1287 return m_type; 89760 ... 89761 because: 89762 ... 89763 (gdb) up 89764 #1 0x0000000000852d94 in finish_command (arg=0x0, from_tty=0) 89765 at .../gdb_versions/devel/src/gdb/infcmd.c:1887 89766 1887 = check_typedef (sm->function->type ()->target_type ()); 89767 (gdb) p sm->function 89768 $1 = (symbol *) 0x0 89769 89770 The code is not checking if sm->function is NULL. If sm->function is NULL 89771 the check for the return buffer should be skipped. 89772 897732022-11-16 Tom Tromey <tromey@adacore.com> 89774 89775 Update Ada tasks documentation 89776 My co-worker Kévin noticed that the Ada tasks documentation is 89777 slightly out of date -- it does not document all the states that can 89778 be reported by ada-tasks.c. 89779 89780 This patch adds the missing states to the appropriate node, and 89781 updates one state to reflect a change made some time ago. 89782 897832022-11-16 Pedro Alves <palves@redhat.com> 89784 89785 gdb: add "set style tui-current-position on|off", default to off 89786 As discussed at: 89787 89788 https://sourceware.org/pipermail/gdb-patches/2020-June/169519.html 89789 89790 this patch disables source and assembly code highlighting for the 89791 text highlighted by the TUI's current position indicator, and adds a 89792 command to enable it back. 89793 897942022-11-16 Tom de Vries <tdevries@suse.de> 89795 89796 [gdb/testsuite] Modernize gdb.arch/i386-biarch-core.exp 89797 I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the 89798 completion limit for "complete set gnutarget": 89799 ... 89800 set gnutarget vms-libtxt^M 89801 set gnutarget *** List may be truncated, max-completions reached. ***^M 89802 (gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget 89803 ... 89804 89805 Fix this by using get_set_option_choices. 89806 89807 Also use get_set_option_choices for "complete set architecture i386", which 89808 required extending get_set_option_choices to accept a second argument, such 89809 that we can do: 89810 ... 89811 set archs [get_set_option_choices "set architecture" "i386"] 89812 ... 89813 because this returns an empty list: 89814 ... 89815 set archs [get_set_option_choices "set architecture i386"] 89816 ... 89817 because it does "complete set architecture i386 ". 89818 89819 Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead. 89820 89821 Tested on x86_64-linux. 89822 898232022-11-16 Tom de Vries <tdevries@suse.de> 89824 89825 [gdb/testsuite] Fix gdb.arch/ppc64-symtab-cordic.exp without bzip2 89826 After de-installing bzip2, I run into: 89827 ... 89828 Running ppc64-symtab-cordic.exp ... 89829 sh: bzip2: command not found 89830 PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \ 89831 src/gdb/testsuite/gdb.arch/cordic.ko.bz2 89832 ... 89833 89834 Fix these by: 89835 - using remote_exec instead of catch system, and 89836 - using file tail in the untested message. 89837 89838 I've tried making output redirection work with remote_exec, but that seems to 89839 be broken, so we now: 89840 - copy the file $f.bz2 into the desired location $dir/$f.bz2, and 89841 - decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file 89842 $dir/$f. 89843 89844 Factor out new function decompress_bz2 to make the test-case less verbose, and 89845 also use it in gdb.arch/i386-biarch-core.exp. 89846 89847 Tested on x86_64-linux, without and with bzip2 installed. 89848 898492022-11-16 GDB Administrator <gdbadmin@sourceware.org> 89850 89851 Automatic date update in version.in 89852 898532022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89854 89855 doc: add SFrame spec file 89856 ChangeLog: 89857 89858 * libsframe/Makefile.am: Add info-in-builddir to 89859 AUTOMAKE_OPTIONS. Include doc/local.mk. 89860 * libsframe/Makefile.in: Regenerated. 89861 * libsframe/configure: Likewise. 89862 * libsframe/configure.ac: Check for makeinfo and set BUILD_INFO. 89863 * libsframe/doc/local.mk: New file. 89864 * libsframe/doc/sframe-spec.texi: Likewise. 89865 898662022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89867 89868 gas/NEWS: add text about new command line option and SFrame support 89869 ChangeLog: 89870 89871 * gas/NEWS: Add SFrame related news. 89872 898732022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89874 89875 binutils/NEWS: add text for SFrame support 89876 ChangeLog: 89877 89878 * binutils/NEWS: Add item for SFrame support. 89879 898802022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89881 89882 src-release.sh: Add libsframe 89883 Add libsframe to the list of top level directories that will be included 89884 in a release. 89885 89886 ChangeLog: 89887 89888 * src-release.sh: Add libsframe 89889 898902022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89891 89892 readelf/objdump: support for SFrame section 89893 This patch adds support for SFrame in readelf and objdump. The arguments 89894 of --sframe are optional for both readelf and objdump. 89895 89896 include/ChangeLog: 89897 89898 * sframe-api.h (dump_sframe): New function declaration. 89899 89900 ChangeLog: 89901 89902 * binutils/Makefile.am: Add dependency on libsframe for 89903 readelf and objdump. 89904 * binutils/Makefile.in: Regenerate. 89905 * binutils/doc/binutils.texi: Document --sframe=[section]. 89906 * binutils/doc/sframe.options.texi: New file. 89907 * binutils/objdump.c: Add support for SFrame format. 89908 * binutils/readelf.c: Likewise. 89909 * include/sframe-api.h: Add new API for dumping .sframe 89910 section. 89911 * libsframe/Makefile.am: Add sframe-dump.c. 89912 * libsframe/Makefile.in: Regenerate. 89913 * libsframe/sframe-dump.c: New file. 89914 899152022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 89916 89917 bfd: linker: merge .sframe sections 89918 The linker merges all the input .sframe sections. When merging, the 89919 linker verifies that all the input .sframe sections have the same 89920 abi/arch. 89921 89922 The linker uses libsframe library to perform key actions on the 89923 .sframe sections - decode, read, and create output data. This 89924 implies buildsystem changes to make and install libsframe before 89925 libbfd. 89926 89927 The linker places the output .sframe section in a new segment of its 89928 own: PT_GNU_SFRAME. A new segment is not added, however, if the 89929 generated .sframe section is empty. 89930 89931 When a section is discarded from the final link, the corresponding 89932 entries in the .sframe section for those functions are also deleted. 89933 89934 The linker sorts the SFrame FDEs on start address by default and sets 89935 the SFRAME_F_FDE_SORTED flag in the .sframe section. 89936 89937 This patch also adds support for generation of SFrame unwind 89938 information for the .plt* sections on x86_64. SFrame unwind info is 89939 generated for IBT enabled PLT, lazy/non-lazy PLT. 89940 89941 The existing linker option --no-ld-generated-unwind-info has been 89942 adapted to include the control of whether .sframe unwind information 89943 will be generated for the linker generated sections like PLT. 89944 89945 Changes to the linker script have been made as necessary. 89946 89947 ChangeLog: 89948 89949 * Makefile.def: Add install dependency on libsframe for libbfd. 89950 * Makefile.in: Regenerated. 89951 * bfd/Makefile.am: Add elf-sframe.c 89952 * bfd/Makefile.in: Regenerated. 89953 * bfd/bfd-in2.h (SEC_INFO_TYPE_SFRAME): Regenerated. 89954 * bfd/configure: Regenerate. 89955 * bfd/configure.ac: Add elf-sframe.lo. 89956 * bfd/elf-bfd.h (struct sframe_func_bfdinfo): New struct. 89957 (struct sframe_dec_info): Likewise. 89958 (struct sframe_enc_info): Likewise. 89959 (struct elf_link_hash_table): New member for encoded .sframe 89960 object. 89961 (struct output_elf_obj_tdata): New member. 89962 (elf_sframe): New access macro. 89963 (_bfd_elf_set_section_sframe): New declaration. 89964 * bfd/elf.c (get_segment_type): Handle new segment 89965 PT_GNU_SFRAME. 89966 (bfd_section_from_phdr): Likewise. 89967 (get_program_header_size): Likewise. 89968 (_bfd_elf_map_sections_to_segments): Likewise. 89969 * bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): Add 89970 contents to the .sframe sections or .plt* entries. 89971 * bfd/elflink.c (elf_section_ignore_discarded_relocs): Handle 89972 SEC_INFO_TYPE_SFRAME. 89973 (_bfd_elf_default_action_discarded): Handle .sframe section. 89974 (elf_link_input_bfd): Merge .sframe section. 89975 (bfd_elf_final_link): Write the output .sframe section. 89976 (bfd_elf_discard_info): Handle discarding .sframe section. 89977 * bfd/elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Create 89978 .sframe section for .plt and .plt.sec. 89979 (_bfd_x86_elf_finish_dynamic_sections): Handle .sframe from 89980 .plt* sections. 89981 * bfd/elfxx-x86.h (PLT_SFRAME_FDE_START_OFFSET): New 89982 definition. 89983 (SFRAME_PLT0_MAX_NUM_FRES): Likewise. 89984 (SFRAME_PLTN_MAX_NUM_FRES): Likewise. 89985 (struct elf_x86_sframe_plt): New structure. 89986 (struct elf_x86_link_hash_table): New member. 89987 (struct elf_x86_init_table): New members for .sframe 89988 creation. 89989 * bfd/section.c: Add new definition SEC_INFO_TYPE_SFRAME. 89990 * binutils/readelf.c (get_segment_type): Handle new segment 89991 PT_GNU_SFRAME. 89992 * ld/ld.texi: Update documentation for 89993 --no-ld-generated-unwind-info. 89994 * ld/scripttempl/elf.sc: Support .sframe sections. 89995 * ld/Makefile.am (TESTSFRAMELIB): Use it. 89996 (check-DEJAGNU): Likewise. 89997 * ld/Makefile.in: Regenerated. 89998 * ld/configure.ac (TESTSFRAMELIB): Set to the .so or .a like TESTBFDLIB. 89999 * ld/configure: Regenerated. 90000 * bfd/elf-sframe.c: New file. 90001 90002 include/ChangeLog: 90003 90004 * elf/common.h (PT_GNU_SFRAME): New definition. 90005 * elf/internal.h (struct elf_segment_map): Handle new segment 90006 type PT_GNU_SFRAME. 90007 90008 ld/testsuite/ChangeLog: 90009 90010 * ld/testsuite/ld-bootstrap/bootstrap.exp: Add SFRAMELIB. 90011 * ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test 90012 sframe-simple-1. 90013 * ld/testsuite/ld-aarch64/sframe-bar.s: New file. 90014 * ld/testsuite/ld-aarch64/sframe-foo.s: Likewise. 90015 * ld/testsuite/ld-aarch64/sframe-simple-1.d: Likewise. 90016 * ld/testsuite/ld-sframe/sframe-empty.d: New test. 90017 * ld/testsuite/ld-sframe/sframe-empty.s: New file. 90018 * ld/testsuite/ld-sframe/sframe.exp: New testsuite. 90019 * ld/testsuite/ld-x86-64/sframe-bar.s: New file. 90020 * ld/testsuite/ld-x86-64/sframe-foo.s: Likewise. 90021 * ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise. 90022 * ld/testsuite/ld-x86-64/sframe-plt-1.d: Likewise. 90023 * ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise. 90024 * ld/testsuite/ld-x86-64/x86-64.exp: Add new tests - 90025 sframe-simple-1, sframe-plt-1. 90026 * ld/testsuite/lib/ld-lib.exp: Add new proc to check if 90027 assembler supports SFrame section. 90028 * ld/testsuite/ld-sframe/discard.d: New file. 90029 * ld/testsuite/ld-sframe/discard.ld: Likewise. 90030 * ld/testsuite/ld-sframe/discard.s: Likewise. 90031 900322022-11-15 Weimin Pan <weimin.pan@oracle.com> 90033 90034 libsframe: add the SFrame library 90035 libsframe is a library that allows you to: 90036 - decode a .sframe section 90037 - probe and inspect a .sframe section 90038 - encode (and eventually write) a .sframe section. 90039 90040 This library is currently being used by the linker, readelf, objdump. 90041 This library will also be used by the SFrame unwinder which is still 90042 to be upstream'd. 90043 90044 The file include/sframe-api.h defines the user-facing APIs for decoding, 90045 encoding and probing .sframe sections. A set of error codes together 90046 with their error message strings are also defined. 90047 90048 Endian flipping is performed automatically at read and write time, if 90049 cross-endianness is detected. 90050 90051 ChangeLog: 90052 90053 * Makefile.def: Add libsframe as new module with its 90054 dependencies. 90055 * Makefile.in: Regenerated. 90056 * binutils/Makefile.am: Add libsframe. 90057 * binutils/Makefile.in: Regenerated. 90058 * configure: Regenerated 90059 * configure.ac: Add libsframe to host_libs. 90060 * libsframe/Makefile.am: New file. 90061 * libsframe/Makefile.in: New file. 90062 * libsframe/aclocal.m4: New file. 90063 * libsframe/config.h.in: New file. 90064 * libsframe/configure: New file. 90065 * libsframe/configure.ac: New file. 90066 * libsframe/sframe-error.c: New file. 90067 * libsframe/sframe-impl.h: New file. 90068 * libsframe/sframe.c: New file. 90069 90070 include/ChangeLog: 90071 90072 * sframe-api.h: New file. 90073 90074 testsuite/ChangeLog: 90075 90076 * libsframe/testsuite/Makefile.am: New file. 90077 * libsframe/testsuite/Makefile.in: Regenerated. 90078 * libsframe/testsuite/libsframe.decode/Makefile.am: New 90079 file. 90080 * libsframe/testsuite/libsframe.decode/Makefile.in: 90081 Regenerated. 90082 * libsframe/testsuite/libsframe.decode/decode.exp: New file. 90083 * libsframe/testsuite/libsframe.encode/Makefile.am: 90084 Likewise. 90085 * libsframe/testsuite/libsframe.encode/Makefile.in: 90086 Regenerated. 90087 * libsframe/testsuite/libsframe.encode/encode.exp: New file. 90088 * libsframe/testsuite/libsframe.encode/encode-1.c: Likewise. 90089 * libsframe/testsuite/libsframe.decode/be-flipping.c: Likewise. 90090 * libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise. 90091 * libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise. 90092 * libsframe/testsuite/libsframe.decode/DATA-BE: New file. 90093 * libsframe/testsuite/libsframe.decode/DATA1: Likewise. 90094 * libsframe/testsuite/libsframe.decode/DATA2: Likewise. 90095 900962022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 90097 90098 gas: testsuite: add new tests for SFrame unwind info 90099 Earlier these tests were in the same commit as previous which adds the 90100 support in GNU assembler to generate .sframe section from CFI 90101 directives. Splitting this out here for ease of applying and testing. 90102 90103 ChangeLog: 90104 90105 * gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.d: New file. 90106 * gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.s: Likewise. 90107 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.d: Likewise. 90108 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.s: Likewise. 90109 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. 90110 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.s: Likewise. 90111 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. 90112 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.s: Likewise. 90113 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. 90114 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.s: Likewise. 90115 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. 90116 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.s: Likewise. 90117 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. 90118 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.s: Likewise. 90119 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. 90120 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.s: Likewise. 90121 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. 90122 * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise. 90123 * gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise. 90124 * gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.s: Likewise. 90125 * gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Likewise. 90126 * gas/testsuite/gas/cfi-sframe/common-empty-1.d: Likewise. 90127 * gas/testsuite/gas/cfi-sframe/common-empty-1.s: Likewise. 90128 * gas/testsuite/gas/cfi-sframe/common-empty-2.d: Likewise. 90129 * gas/testsuite/gas/cfi-sframe/common-empty-2.s: Likewise. 90130 * gas/testsuite/gas/cfi-sframe/common-empty-3.d: Likewise. 90131 * gas/testsuite/gas/cfi-sframe/common-empty-3.s: Likewise. 90132 * gas/testsuite/gas/cfi-sframe/common-empty-4.d: Likewise. 90133 * gas/testsuite/gas/cfi-sframe/common-empty-4.s: Likewise. 90134 901352022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 90136 90137 gas: generate .sframe from CFI directives 90138 Currently supported for x86_64 and aarch64 only. 90139 90140 [PS: Currently, the compiler has not been adapted to generate 90141 ".cfi_sections" with ".sframe" in it. The newly added command line 90142 option of --gsframe provides an easy way to try out .sframe support 90143 in the toolchain.] 90144 90145 gas interprets the CFI directives to generate DWARF-based .eh_frame 90146 info. These internal DWARF structures are now consumed by 90147 gen-sframe.[ch] sub-system to, in turn, create the SFrame unwind 90148 information. These internal DWARF structures are read-only for the 90149 purpose of SFrame unwind info generation. 90150 90151 SFrame unwind info generation does not impact .eh_frame unwind info 90152 generation. Both .eh_frame and .sframe can co-exist in an ELF file, 90153 if so desired by the user. 90154 90155 Recall that SFrame unwind information only contains the minimal 90156 necessary information to generate backtraces and does not provide 90157 information to recover all callee-saved registers. The reason being 90158 that callee-saved registers other than FP are not needed for stack 90159 unwinding, and hence are not included in the .sframe section. 90160 90161 Consequently, gen-sframe.[ch] only needs to interpret a subset of 90162 DWARF opcodes in gas. More details follow. 90163 90164 [Set 1, Interpreted] The following opcodes are interpreted: 90165 - DW_CFA_advance_loc 90166 - DW_CFA_def_cfa 90167 - DW_CFA_def_cfa_register 90168 - DW_CFA_def_cfa_offset 90169 - DW_CFA_offset 90170 - DW_CFA_remember_state 90171 - DW_CFA_restore_state 90172 - DW_CFA_restore 90173 90174 [Set 2, Bypassed] The following opcodes are acknowledged but are not 90175 necessary for generating SFrame unwind info: 90176 - DW_CFA_undefined 90177 - DW_CFA_same_value 90178 90179 Anything else apart from the two above-mentioned sets is skipped 90180 altogether. This means that any function containing a CFI directive not 90181 in Set 1 or Set 2 above, will not have any SFrame unwind information 90182 generated for them. Holes in instructions covered by FREs of a single 90183 FDE are not representable in the SFrame unwind format. 90184 90185 As few examples, following opcodes are not processed for .sframe 90186 generation, and are skipped: 90187 - .cfi_personality* 90188 - .cfi_*lsda 90189 - .cfi_escape 90190 - .cfi_negate_ra_state 90191 - ... 90192 90193 Not processing .cfi_escape, .cfi_negate_ra_state will cause SFrame 90194 unwind information to be absent for SFrame FDEs that contain these CFI 90195 directives, hence affecting the asynchronicity. 90196 90197 x86-64 and aarch64 backends need to have a few new definitions and 90198 functions for .sframe generation. These provide gas with architecture 90199 specific information like the SP/FP/RA register numbers and an 90200 SFrame-specific ABI marker. 90201 90202 Lastly, the patch also implements an optimization for size, where 90203 specific fragments containing SFrame FRE start address and SFrame FDE 90204 function are fixed up. This is similar to other similar optimizations 90205 in gas, where fragments are sized and fixed up when the associated 90206 symbols can be resolved. This optimization is controlled by a #define 90207 SFRAME_FRE_TYPE_SELECTION_OPT and should be easy to turn off if needed. 90208 The optimization is on by default for both x86_64 and aarch64. 90209 90210 ChangeLog: 90211 90212 * gas/Makefile.am: Include gen-sframe.c and sframe-opt.c. 90213 * gas/Makefile.in: Regenerated. 90214 * gas/as.h (enum _relax_state): Add new state rs_sframe. 90215 (sframe_estimate_size_before_relax): New function. 90216 (sframe_relax_frag): Likewise. 90217 (sframe_convert_frag): Likewise. 90218 * gas/config/tc-aarch64.c (aarch64_support_sframe_p): New 90219 definition. 90220 (aarch64_sframe_ra_tracking_p): Likewise. 90221 (aarch64_sframe_cfa_ra_offset): Likewise. 90222 (aarch64_sframe_get_abi_arch): Likewise. 90223 (md_begin): Set values of sp/fp/ra registers. 90224 * gas/config/tc-aarch64.h (aarch64_support_sframe_p): New 90225 declaration. 90226 (support_sframe_p): Likewise. 90227 (SFRAME_CFA_SP_REG): Likewise. 90228 (SFRAME_CFA_FP_REG): Likewise. 90229 (SFRAME_CFA_RA_REG): Likewise. 90230 (aarch64_sframe_ra_tracking_p): Likewise. 90231 (sframe_ra_tracking_p): Likewise. 90232 (aarch64_sframe_cfa_ra_offset): Likewise. 90233 (sframe_cfa_ra_offset): Likewise. 90234 (aarch64_sframe_get_abi_arch): Likewise. 90235 (sframe_get_abi_arch): Likewise. 90236 * gas/config/tc-i386.c (x86_support_sframe_p): New definition. 90237 (x86_sframe_ra_tracking_p): Likewise. 90238 (x86_sframe_cfa_ra_offset): Likewise. 90239 (x86_sframe_get_abi_arch): Likewise. 90240 * gas/config/tc-i386.h (x86_support_sframe_p): New declaration. 90241 (support_sframe_p): Likewise. 90242 (SFRAME_CFA_SP_REG): Likewise. 90243 (SFRAME_CFA_FP_REG): Likewise. 90244 (x86_sframe_ra_tracking_p): Likewise. 90245 (sframe_ra_tracking_p): Likewise. 90246 (x86_sframe_cfa_ra_offset): Likewise. 90247 (sframe_cfa_ra_offset): Likewise. 90248 (x86_sframe_get_abi_arch): Likewise. 90249 (sframe_get_abi_arch): Likewise. 90250 * gas/config/tc-xtensa.c (unrelaxed_frag_max_size): Add case for 90251 rs_sframe. 90252 * gas/doc/as.texi: Add .sframe to the documentation for 90253 .cfi_sections. 90254 * gas/dw2gencfi.c (cfi_finish): Create a .sframe section. 90255 * gas/dw2gencfi.h (CFI_EMIT_sframe): New definition. 90256 * gas/write.c (cvt_frag_to_fill): Handle rs_sframe. 90257 (relax_segment): Likewise. 90258 * gas/gen-sframe.c: New file. 90259 * gas/gen-sframe.h: New file. 90260 * gas/sframe-opt.c: New file. 90261 902622022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 90263 90264 gas: add new command line option --gsframe 90265 When --gsframe is specified, the assembler will generate a .sframe 90266 section from the CFI directives in the assembly. 90267 90268 ChangeLog: 90269 90270 * gas/as.c (parse_args): Parse args and set flag_gen_sframe. 90271 * gas/as.h: Introduce skeleton for --gsframe. 90272 * gas/doc/as.texi: document --gsframe. 90273 902742022-11-15 Indu Bhagat <indu.bhagat@oracle.com> 90275 90276 sframe.h: Add SFrame format definition 90277 The header sframe.h defines the SFrame format. 90278 90279 The SFrame format is the Simple Frame format. It can be used to 90280 represent the minimal necessary unwind information required for 90281 backtracing. The current version supports AMD64 and AARCH64. 90282 90283 More details of the SFrame format are included in the documentation 90284 of the header file in this patch. 90285 90286 include/ChangeLog: 90287 * sframe.h: New file. 90288 902892022-11-15 Alan Modra <amodra@gmail.com> 90290 90291 Re: [gas] arm: Add support for new unwinder directive ".pacspval". 90292 * testsuite/gas/arm/ehabi-pacbti-m.d: Limit test to ELF. 90293 902942022-11-15 Alan Modra <amodra@gmail.com> 90295 90296 aarch64-pe can't fill 16 bytes in section .text 90297 Without commit b66e671854, this: 90298 .p2align 4 90299 nop 90300 .p2align 3 90301 nop 90302 results in an error when coff_frob_section attempts to pad out the 90303 section to a 16-byte boundary. Due to miscalculating the pad pattern 90304 repeat count, write.c:write_contents attempts to shove 16 bytes of 90305 padding into the remaining 4 bytes of the .text section. 90306 90307 * config/obj-coff.c (coff_frob_section): Correct fill count. 90308 Don't pad after errors. 90309 903102022-11-15 Jose E. Marchesi <jose.marchesi@oracle.com> 90311 90312 gdb/configure: regenerate 90313 The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an 90314 incorrect thunk for the `configure' script. This patch regenerates 90315 configure by calling autoreconf. 90316 903172022-11-15 Jose E. Marchesi <jose.marchesi@oracle.com> 90318 90319 gdb: use libtool in GDB_AC_CHECK_BFD 90320 The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the 90321 AC_LINK_IFELSE autoconf macro in order to link a simple program to 90322 check features of libbfd. 90323 90324 If libbfd's link dependencies change, it was necessary to reflect them 90325 either in the definition of the macro, or as a consequence of checking 90326 for them with an autoconf macro resulting in an addition to LIBS. 90327 90328 This patch modifies the definition of the GDB_CHECK_BFD macro in order 90329 to use libtool to perform the test link. This makes it possible to 90330 not have to list dependencies of libbfd (which are indirect to GDB) at 90331 all. 90332 90333 After this patch: 90334 90335 configure:28553: checking for ELF support in BFD 90336 configure:28573: ./libtool --quiet --mode=link gcc -o conftest \ 90337 -I../../gdb/../include -I../bfd \ 90338 -I../../gdb/../bfd -g -O2 \ 90339 -L../bfd -L../libiberty conftest.c -lbfd -liberty \ 90340 -lncursesw -lm -ldl >&5 90341 configure:28573: $? = 0 90342 configure:28583: result: yes 90343 90344 Tests performed: 90345 90346 - Configure --with-system-zlib and --without-system-zlib. 90347 - Check link dependencies of installed GDB with both --enable-shared 90348 and --disable-shared. 90349 - Run installed GDB in both cases. 90350 90351 Approved-By: Simon Marchi <simon.marchi@efficios.com> 90352 903532022-11-15 Tom Tromey <tromey@adacore.com> 90354 90355 Fix crash in ada_print_type 90356 The "varstring" paramter to ada_print_type can be null, but one spot 90357 failed to check this. This could cause a crash in some situations. 90358 90359 As this is Ada-specific, and we've been using it internally at AdaCore 90360 for a while, I am going to push it. 90361 903622022-11-15 Tejas Joshi <TejasSanjay.Joshi@amd.com> 90363 90364 Add AMD znver4 processor support 90365 2022-09-28 Tejas Joshi <TejasSanjay.Joshi@amd.com> 90366 90367 gas/ 90368 90369 * config/tc-i386.c (cpu_arch): Add znver4 ARCH and rmpquery SUBARCH. 90370 (md_assemble): Expand comment before swap_operands() with rmpquery. 90371 * doc/c-i386.texi: Add znver4. 90372 * testsuite/gas/i386/arch-14-1.d: New. 90373 * testsuite/gas/i386/arch-14-1.s: New. 90374 * testsuite/gas/i386/arch-14-znver4.d: New. 90375 * testsuite/gas/i386/i386.exp: Add new znver4 test cases. 90376 * testsuite/gas/i386/rmpquery.d: New. 90377 * testsuite/gas/i386/rmpquery.s: New. 90378 * testsuite/gas/i386/x86-64-arch-4-1.d: New. 90379 * testsuite/gas/i386/x86-64-arch-4-1.s: New. 90380 * testsuite/gas/i386/x86-64-arch-4-znver4.d: New. 90381 90382 opcodes/ 90383 90384 * i386-dis.c (x86_64_table): Add rmpquery. 90385 * i386-gen.c (cpu_flag_init): Add CPU_ZNVER4_FLAGS and 90386 CPU_RMPQUERY_FLAGS. 90387 (cpu_flags): Add CpuRMPQUERY. 90388 * i386-opc.h (enum): Add CpuRMPQUERY. 90389 (i386_cpu_flags): Add cpurmpquery. 90390 * i386-opc.tbl: Add rmpquery insn. 90391 * i386-init.h: Re-generated. 90392 * i386-tbl.h: Re-generated. 90393 903942022-11-15 Simon Marchi <simon.marchi@polymtl.ca> 90395 90396 gdb/testsuite: get_set_option_choices: expect \r\n after each item 90397 I get some random failures since commit 8d45c3a82a0e ("[gdb/testsuite] 90398 Set completions to unlimited in get_set_option_choices"), which can be 90399 reproduced with: 90400 90401 $ make check-read1 TESTS="gdb.base/parse_number.exp" 90402 90403 For instance: 90404 90405 set architecture A^M 90406 Ambiguous item "A".^M 90407 (gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A 90408 90409 The problem is the regexp in get_set_option_choices, it is possible that 90410 is only matches part of a completion result. With check-read1, that is 90411 always one letter. 90412 90413 Fix this by expecting the \r\n at the end of the line, so we only match 90414 entire results. Use ^ in match patterns to ensure we don't miss any 90415 output. 90416 90417 Approved-By: Tom de Vries <tdevries@suse.de> 90418 Change-Id: Ib1733737feab7dde0f7095866e089081a891054e 90419 904202022-11-15 Andre Vieira <andre.simoesdiasvieira@arm.com> 90421 90422 aarch64, testsuite: Fixed recently added cssc.d 90423 Fixed wrong paste in cssc.d. 90424 90425 gas/ChangeLog: 90426 90427 * testsuite/gas/aarch64/cssc.d: Removed duplicate head. 90428 904292022-11-15 Tom de Vries <tdevries@suse.de> 90430 90431 [gdb/testsuite] Normalize gdbserver path name 90432 Currently for the target board remote-gdbserver-on-localhost we use the 90433 gdbserver file on build, using a file name which includes "/../". 90434 90435 Fix this by using a normalized file name instead. 90436 90437 This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME 90438 can access: 90439 ... 90440 - remote_exec build "chmod go-rx $objdir/outputs" 90441 + remote_exec build "chmod go-rx $objdir" 90442 ... 90443 90444 Tested on x86_64-linux. 90445 904462022-11-15 Tom de Vries <tdevries@suse.de> 90447 90448 [gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target 90449 With test-case gdb.base/jit-elf-so.exp and target board 90450 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90451 failures. 90452 90453 Fix these by: 90454 - setting jit_libname with the name as returned by gdb_load_shlib 90455 - allowing the libraries to be prefixed with the remote target directory. 90456 90457 Tested on x86_64-linux. 90458 90459 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90460 904612022-11-15 Tom de Vries <tdevries@suse.de> 90462 90463 [gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target 90464 With test-case gdb.base/jit-reader-exec.exp and target board 90465 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90466 failures. 90467 90468 Fix this by adding the missing gdb_remote_download. 90469 90470 Tested on x86_64-linux. 90471 90472 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90473 904742022-11-15 Tom de Vries <tdevries@suse.de> 90475 90476 [gdb/testsuite] Fix gdb.base/info-shared.exp for remote target 90477 With test-case gdb.base/info-shared.exp and target board 90478 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90479 failures. 90480 90481 Fix these by adding the missing gdb_load_shlib. 90482 90483 Tested on x86_64-linux. 90484 90485 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90486 904872022-11-15 Tom de Vries <tdevries@suse.de> 90488 90489 [gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target 90490 When running test-case gdb.base/solib-vanish.exp with target board 90491 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90492 failures. 90493 90494 Fix these by adding the missing gdb_load_shlib. 90495 90496 Tested on x86_64-linux. 90497 90498 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90499 905002022-11-15 Tom de Vries <tdevries@suse.de> 90501 90502 [gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target 90503 When running test-case gdb.base/infcall-exec.exp with target board 90504 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into: 90505 ... 90506 (gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \ 90507 "$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M 90508 $1 = -1^M 90509 (gdb) FAIL: gdb.base/infcall-exec.exp: call execlp 90510 ... 90511 90512 Fix this by using just: 90513 ... 90514 (gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M 90515 ... 90516 and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2 90517 if it's available alongside. 90518 90519 Also fix the exec name in the test-case, such that we can successfully 90520 run the test-case: 90521 ... 90522 $ ./outputs/gdb.base/infcall-exec/infcall-exec 90523 PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec' 90524 $ 90525 ... 90526 90527 Tested on x86_64-linux. 90528 90529 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90530 905312022-11-15 Tom de Vries <tdevries@suse.de> 90532 90533 [gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target 90534 When running test-case gdb.base/print-file-var.exp with target board 90535 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90536 failures. 90537 90538 Fix these by using the name of a shared lib as returned by gdb_load_shlib. 90539 90540 This required splitting up the gdb_load_shlib functionality, which is now 90541 defined as: 90542 ... 90543 proc gdb_load_shlib { file } { 90544 set dest [gdb_download_shlib $file] 90545 gdb_locate_shlib $file 90546 return $dest 90547 } 90548 ... 90549 such that we can do gdb_download_shlib before gdb is started. 90550 90551 Tested on x86_64-linux. 90552 90553 Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90554 905552022-11-15 Tom de Vries <tdevries@suse.de> 90556 90557 [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp 90558 As reported here 90559 ( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a 90560 number of test-cases fails with a remote target setup, for instance test-case 90561 gdb.base/print-file-var.exp. 90562 90563 So, why don't we see these fails with our remote target boards in 90564 gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp? 90565 90566 The problem is that the target board uses the same machine and user for 90567 both (by-definition-local) build and remote target, and when using absolute 90568 pathnames to refer to files on build, we can access those files on target, 90569 which in a real remote target setup wouldn't be the case: we'd have to 90570 download them to target first, and then the filename would also be different. 90571 90572 For aforementioned test-case, this happens when the name of a shared library is 90573 passed as absolute file name to gcc: 90574 ... 90575 gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\ 90576 print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so" 90577 ... 90578 90579 Make these problems visible with remote-gdbserver-on-localhost.exp by 90580 adding an option to specify a test account (still on the same machine) 90581 using REMOTE_TARGET_USERNAME. 90582 90583 We make sure by restricting file permissions, that the test account cannot see 90584 the build files on the $USER account, and that the $USER account cannot see 90585 the target files on the test account. 90586 90587 And so we can reproduce the reported fails: 90588 ... 90589 $ cd build/gdb 90590 $ tc="gdb.base/print-file-var.exp" 90591 $ tb="--target_board remote-gdbserver-on-localhost" 90592 $ tbu="REMOTE_TARGET_USERNAME=remote-target" 90593 $ make check RUNTESTFLAGS="$tb $tbu $tc" 90594 ... 90595 FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \ 90596 version_id_main=0: continue to STOP marker 90597 ... 90598 90599 Tested on x86_64-linux. 90600 90601 Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> 90602 906032022-11-15 Tom de Vries <tdevries@suse.de> 90604 90605 [gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target 90606 With test-case gdb.base/info_sources_2.exp and target board 90607 remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some 90608 failures. 90609 90610 Fix these by adding the missing gdb_load_shlib. 90611 90612 Tested on x86_64-linux. 90613 906142022-11-15 Tom de Vries <tdevries@suse.de> 90615 90616 [gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target 90617 When running test-case gdb.base/foll-exec.exp with target board 90618 remote-gdbserver-on-localhost.exp, I run into: 90619 ... 90620 (gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint 90621 continue^M 90622 Continuing.^M 90623 [Inferior 1 (process 4476) exited normally]^M 90624 (gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\ 90625 xited) 90626 ... 90627 90628 The problem is that the foll-exec executable expects the exec-ed executable 90629 execd-prog alongside it, but it's missing. 90630 90631 Fix this by adding the missing gdb_remote_download. 90632 90633 Likewise in a few other test-cases. 90634 90635 Tested on x86_64-linux. 90636 906372022-11-15 Tom de Vries <tdevries@suse.de> 90638 90639 [gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml support 90640 On aarch64-linux, with a gdb build without libexpat, so without xml support, I 90641 run into: 90642 ... 90643 (gdb) builtin_spawn attach-no-multi-process^M 90644 attach 26808^M 90645 Attaching to Remote target^M 90646 warning: Can not parse XML target description; XML support was disabled at \ 90647 compile time^M 90648 Reading symbols from attach-no-multi-process...^M 90649 Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M 90650 ... 90651 90652 The test-case checks for skip_gdbserver_tests and that one contains a check 90653 for xml support: 90654 ... 90655 # If GDB is lack of XML support, and targets, like arm, have 90656 # multiple target descriptions, GDB doesn't know which target 90657 # description GDBserver uses, and may fail to parse 'g' packet 90658 # after connection. 90659 if { [gdb_skip_xml_test] 90660 && ([istarget "arm*-*-linux*"] 90661 || [istarget "mips*-*-linux*"] 90662 || [istarget "powerpc*-*-linux*"] 90663 || [istarget "s390*-*-linux*"] 90664 || [istarget "x86_64-*-linux*"] 90665 || [istarget "i\[34567\]86-*-linux*"]) } { 90666 return 1 90667 } 90668 ... 90669 but it doesn't trigger because aarch64 is missing. 90670 90671 Fix this by adding istarget "aarch64*-*-linux*". 90672 90673 Tested on aarch64-linux. 90674 90675 Approved-By: Luis Machado <luis.machado@arm.com> 90676 906772022-11-15 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 90678 90679 Enable multi-process debugging for AIX 90680 This patch adds multi-process debugging feature in AIX. 90681 90682 Till now AIX supported debugging only one inferior at a time, 90683 now we can be able to debug multi process. Users can use set 90684 follow fork mode in child or parent and set detach on fork on 90685 or off to enable/disable simultaneous debugging of parent/child. 90686 906872022-11-15 GDB Administrator <gdbadmin@sourceware.org> 90688 90689 Automatic date update in version.in 90690 906912022-11-14 Carl Love <cel@us.ibm.com> 90692 90693 PowerPC, fix support for printing the function return value for non-trivial values. 90694 Currently, a non-trivial return value from a function cannot currently be 90695 reliably determined on PowerPC. This is due to the fact that the PowerPC 90696 ABI uses register r3 to store the address of the buffer containing the 90697 non-trivial return value when the function is called. The PowerPC ABI 90698 does not guarantee the value in register r3 is not modified in the 90699 function. Thus the value in r3 cannot be reliably used to obtain the 90700 return addreses on exit from the function. 90701 90702 This patch adds a new gdbarch method to allow PowerPC to access the value 90703 of r3 on entry to a function. On PowerPC, the new gdbarch method attempts 90704 to use the DW_OP_entry_value for the DWARF entries, when exiting the 90705 function, to determine the value of r3 on entry to the function. This 90706 requires the use of the -fvar-tracking compiler option to compile the 90707 user application thus generating the DW_OP_entry_value in the binary. The 90708 DW_OP_entry_value entries in the binary file allows GDB to resolve the 90709 DW_TAG_call_site entries. This new gdbarch method is used to get the 90710 return buffer address, in the case of a function returning a nontrivial 90711 data type, on exit from the function. The GDB function should_stop checks 90712 to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to 90713 zero by the new gdbarch method call for all architectures except PowerPC. 90714 The get_return_value function will be used to obtain the return value on 90715 all other architectures as is currently being done if RETURN_BUF is zero. 90716 On PowerPC, the new gdbarch method will return a nonzero address in 90717 RETURN_BUF if the value can be determined. The value_at function uses the 90718 return buffer address to get the return value. 90719 90720 This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp. 90721 The correct function return values are now reported. 90722 90723 Note this patch is dependent on patch: "PowerPC, function 90724 ppc64_sysv_abi_return_value add missing return value convention". 90725 90726 This patch has been tested on Power 10 and x86-64 with no regressions. 90727 907282022-11-14 Carl Love <cel@us.ibm.com> 90729 90730 PowerPC, function ppc64_sysv_abi_return_value add missing return value convention 90731 This patch address five testcase failures in gdb.cp/non-trivial-retval.exp. 90732 The following commit resulted in the five testcases failures on PowerPC. 90733 The value returned by the function is being reported incorrectly. 90734 90735 commit b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608 90736 Author: Andrew Burgess <aburgess@redhat.com> 90737 Date: Mon Dec 13 16:56:16 2021 +0000 90738 90739 gdb: on x86-64 non-trivial C++ objects are returned in memory 90740 90741 Fixes PR gdb/28681. It was observed that after using the `finish` 90742 command an incorrect value was displayed in some cases. Specifically, 90743 this behaviour was observed on an x86-64 target. 90744 90745 The function: 90746 90747 enum return_value_convention 90748 ppc64_sysv_abi_return_value (struct gdbarch *gdbarch, struct value *function, 90749 struct type *valtype, struct regcache *regcache, 90750 gdb_byte *readbuf, const gdb_byte *writebuf) 90751 90752 should return RETURN_VALUE_STRUCT_CONVENTION if the valtype->code() is 90753 TYPE_CODE_STRUCT and if the language_pass_by_reference is not 90754 trivially_copyable. 90755 90756 This patch adds the needed code to return the value 90757 RETURN_VALUE_STRUCT_CONVENTION in this case. 90758 90759 With this patch, the five test cases still fail but with the message "Value 90760 returned has type: A. Cannot determine contents". The PowerPC ABI stores 90761 the address of the buffer containing the function return value in register 90762 r3 on entry to the function. However, the PowerPC ABI does not guarentee 90763 that r3 will not be modified in the function. So when the function returns, 90764 the return buffer address cannot be reliably obtained from register r3. 90765 Thus the message "Cannot determine contents" is appropriate in this case. 90766 907672022-11-14 Tom Tromey <tromey@adacore.com> 90768 90769 Remove dump_prefix_expression 90770 Since the expression rewrite, dump_prefix_expression has been 90771 misnamed. This patch cleans this up by removing the function, turning 90772 it into a method on struct expression. 90773 907742022-11-14 Andre Vieira <andre.simoesdiasvieira@arm.com> 90775 90776 aarch64: Add support for Common Short Sequence Compression extension 90777 This patch adds support for the CSSC extension and its corresponding 90778 instructions: ABS, CNT, CTZ, SMAX, UMAX, SMIN, UMIN. 90779 90780 gas/ChangeLog: 90781 90782 * config/tc-aarch64.c (parse_operands): Handle new operand types. 90783 * doc/c-aarch64.texi: Document new extension. 90784 * testsuite/gas/aarch64/cssc.d: New test. 90785 * testsuite/gas/aarch64/cssc.s: New test. 90786 90787 include/ChangeLog: 90788 90789 * opcode/aarch64.h (AARCH64_FEATURE_CSSC): New feature Macro. 90790 (enum aarch64_opnd): New operand types. 90791 (enum aarch64_insn_class): New instruction class. 90792 90793 opcodes/ChangeLog: 90794 90795 * aarch64-asm-2.c: Regenerate. 90796 * aarch64-dis-2.c: Regenerate. 90797 * aarch64-opc-2.c: Regenerate. 90798 * aarch64-opc.c (operand_general_constraint_met_p): Update for new 90799 operand types. 90800 (aarch64_print_operand): Likewise. 90801 * aarch64-opc.h (enum aarch64_field_kind): Declare FLD_CSSC_imm8 field. 90802 * aarch64-tbl.h (aarch64_feature_cssc): Define new feature set. 90803 (CSSC): Define new feature set Macro. 90804 (CSSC_INSN): Define new instruction type. 90805 (aarch64_opcode_table): Add new instructions. 90806 908072022-11-14 Jan Beulich <jbeulich@suse.com> 90808 90809 x86: fold special-operand insn attributes into a single enum 90810 Attributes which aren't used together in any single insn template can be 90811 converted from individual booleans to a single enum, as was done for a few 90812 other attributes before. This is more space efficient. Collect together 90813 all attributes which express special operand constraints (and which fit 90814 the criteria for folding). 90815 908162022-11-14 Dimitar Dimitrov <dimitar@dinux.eu> 90817 90818 pru: bfd: Correct default to no execstack 90819 Data and instruction memories are strictly separated, so it is not 90820 possible to execute instructions from the stack memory on PRU. 90821 90822 I don't see any difference in testsuite results with or without this 90823 change. 90824 90825 bfd/ChangeLog: 90826 90827 * elf32-pru.c (elf_backend_default_execstack): Define as 0. 90828 90829 ld/ChangeLog: 90830 90831 * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): 90832 Return 0 for pru. 90833 908342022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90835 90836 [gas] arm: Add support for new unwinder directive ".pacspval". 90837 This patch adds the assembler support for the new unwinder 90838 directive ".pacspval" and encodes this directives with opcode 90839 "0xb5". This opcode indicates the unwinder to use effective 90840 vsp as modifier for PAC validation. 90841 90842 gas/ChangeLog: 90843 90844 2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90845 90846 * doc/c-arm.texi: Document directive. 90847 * config/tc-arm.c (s_arm_unwind_pacspval): Define function. 90848 (md_pseudo_table): Add entry for pacspval directive. 90849 * testsuite/gas/arm/ehabi-pacbti-m.d: New test. 90850 * testsuite/gas/arm/ehabi-pacbti-m.s: Likewise. 90851 908522022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90853 90854 [readelf] arm: Support for new pacbti unwind opcode 0xb5. 90855 This patch adds readelf support for decoding the exception 90856 table opcode "0xb5", which indicates to use effective vsp 90857 as modifier for PAC validation as defined by EHABI 90858 (https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf 90859 Section 10.3). 90860 90861 binutils/ChangeLog: 90862 90863 2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90864 90865 * readelf.c (decode_arm_unwind_bytecode): Add entry to decode opcode 0xb5. 90866 908672022-11-14 Tsukasa OI <research_trasio@irq.a4lg.com> 90868 90869 gdb/unittests: PR28413, suppress warnings generated by Gnulib 90870 Gnulib generates a warning if the system version of certain functions 90871 are used (to redirect the developer to use Gnulib version). It caused a 90872 compiler error when... 90873 90874 - Compiled with Clang 90875 - -Werror is specified (by default) 90876 - C++ standard used by Clang is before C++17 (by default as of 15.0.0) 90877 when this unit test is activated. 90878 90879 This issue is raised as PR28413. 90880 90881 However, previous proposal to fix this issue (a "fix" to Gnulib): 90882 <https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00003.html> 90883 was rejected because it ruins the intent of Gnulib warnings. 90884 90885 So, we need a Binutils/GDB-side solution. 90886 90887 This commit tries to address this issue on the GDB side. We have 90888 "include/diagnostics.h" to disable certain warnings only when necessary. 90889 90890 This commit suppresses the Gnulib warnings by surrounding entire #include 90891 block with DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS to disable Gnulib- 90892 generated warnings on all standard C++ header files. 90893 90894 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28413 90895 Approved-By: Simon Marchi <simon.marchi@efficios.com> 90896 Change-Id: Ieeb5a31a6902808d4c7263a2868ae19a35e0ccaa 90897 908982022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90899 90900 arm: Add support for Cortex-X1C CPU. 90901 This patch adds support for Cortex-X1C CPU in Arm. 90902 90903 bfd/ChangeLog: 90904 90905 2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90906 90907 * cpu-arm.c (processors): Add Cortex-X1C CPU entry. 90908 90909 gas/ChangeLog: 90910 90911 2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 90912 90913 * NEWS: Update docs. 90914 * config/tc-arm.c (arm_cpus): Add cortex-x1c to -mcpu. 90915 * doc/c-arm.texi: Update docs. 90916 * testsuite/gas/arm/cpu-cortex-x1c.d: New test. 90917 909182022-11-14 Tom de Vries <tdevries@suse.de> 90919 90920 [gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=all 90921 While looking at test-case gdb.arch/ppc64-symtab-cordic.exp I realized that 90922 the test-case is too restrictive here: 90923 ... 90924 if {![istarget "powerpc*"] || ![is_lp64_target]} { 90925 verbose "Skipping powerpc64 separate debug file symtab test." 90926 return 90927 } 90928 ... 90929 and can also be run on x86_64-linux, if "set arch powerpc:common64" is 90930 supported, which is the case if we've build gdb with --enable-targets=all. 90931 90932 Fix this by instead checking if powerpc:common64 is in the completion list for 90933 "set arch". 90934 90935 This allows us to remove the 'untested "powerpc:common64 is not supported"'. 90936 90937 While we're at it, clean up the test-case by using clean_restart. 90938 90939 Tested on x86_64-linux. 90940 909412022-11-14 Tom de Vries <tdevries@suse.de> 90942 90943 [gdb/testsuite] Handle with_set arch 90944 I realized that the more irregular output of show arch: 90945 ... 90946 (gdb) show arch^M 90947 The target architecture is set to "auto" (currently "i386").^M 90948 ... 90949 would be a problem for something like: 90950 ... 90951 with_set arch powerpc:common64 {} 90952 ... 90953 and indeed: 90954 ... 90955 (gdb) set arch powerpc:common64^M 90956 The target architecture is set to "powerpc:common64".^M 90957 (gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64 90958 ... 90959 and: 90960 ... 90961 (gdb) set arch set to "auto" (currently "i386")^M 90962 Undefined item: "set".^M 90963 ... 90964 90965 Fix this in with_set by handling this type of output. 90966 90967 Tested on x86_64-linux. 90968 909692022-11-14 Tom de Vries <tdevries@suse.de> 90970 90971 [gdb/testsuite] Set completions to unlimited in get_set_option_choices 90972 In some test-case I tried to use get_set_option_choices "set architecture" and 90973 ran into max-completions: 90974 ... 90975 set architecture simple^M 90976 set architecture tomcat^M 90977 set architecture xscale^M 90978 set architecture *** List may be truncated, max-completions reached. ***^M 90979 (gdb) PASS: gdb.base/foo.exp: complete set architecture 90980 ... 90981 90982 There's only one test-case using this currently: gdb.base/parse_number.exp, 90983 and it locally sets max-completions to unlimited. 90984 90985 Fix this by: 90986 - factoring out a new proc with_set out of proc with_complaints, and 90987 - using it to temporarily set max-completions to unlimited in 90988 get_set_option_choice. 90989 90990 Tested on x86_64-linux, by running test-cases that excercise 90991 get_set_option_choice and with_complaints. 90992 909932022-11-14 Alan Modra <amodra@gmail.com> 90994 90995 Re: objcopy renaming section with explicit flags 90996 For now, xfail the new test. Some header/aux-header rewriting is 90997 required at the very least. 90998 90999 * testsuite/binutils-all/rename-section-01.d: xfail xcoff. 91000 910012022-11-14 Alan Modra <amodra@gmail.com> 91002 91003 objcopy renaming section with explicit flags 91004 This tidies SEC_RELOC handling in bfd, in the process fixing a bug 91005 with objcopy when renaming sections. 91006 91007 bfd/ 91008 * reloc.c (_bfd_generic_set_reloc): Set/clear SEC_RELOC depending 91009 on reloc count. 91010 * elf64-sparc.c (elf64_sparc_set_reloc): Likewise. 91011 binutils/ 91012 * objcopy.c (copy_relocations_in_section): Remove now unnecessary 91013 clearing of SEC_RELOC. 91014 * testsuite/binutils-all/rename-section-01.d: New test. 91015 * testsuite/binutils-all/objcopy.exp: Run it. 91016 gas/ 91017 * write.c (size_seg): Remove unneccesary twiddle of SEC_RELOC. 91018 (write_relocs): Likewise. Always call bfd_set_reloc. 91019 910202022-11-14 GDB Administrator <gdbadmin@sourceware.org> 91021 91022 Automatic date update in version.in 91023 910242022-11-13 Jon Turney <jon.turney@dronecode.org.uk> 91025 91026 Fix Cygwin build after 02d04eac 91027 Commit 02d04eac "Use strwinerror in gdb/windows-nat.c" also moves 91028 strwinerror() under the USE_WIN32API conditional, which is not defined 91029 for Cygwin (and looks like it shouldn't be, as appears to imply 91030 non-POSIX and MiNGW and WinSock...) 91031 91032 Also enable the declaration and definition of strwinerror() when 91033 __CYGWIN__ is defined. 91034 910352022-11-13 Jon Turney <jon.turney@dronecode.org.uk> 91036 91037 Drop apparently unneeded include of winsock2.h 91038 Commit d08bae3d ("Implement target async for Windows") unconditionally 91039 includes winsock2.h. We don't want to do that on Cygwin, since 91040 including both winsock2.h and sys/select.h causes incompatible 91041 redefinition problems. 91042 91043 Since that include is apparently unneeded, just drop it. 91044 91045 Fixes: d08bae3d 91046 910472022-11-13 GDB Administrator <gdbadmin@sourceware.org> 91048 91049 Automatic date update in version.in 91050 910512022-11-12 Dimitar Dimitrov <dimitar@dinux.eu> 91052 91053 sim: pru: Fix behaviour when loop count is zero 91054 If the counter for LOOP instruction is provided by a register with 91055 value zero, then the instruction must cause a PC jump directly to the 91056 loop end. But in that particular case simulator must not initialize 91057 its internal loop variables, because loop body will not be executed. 91058 Instead, simulator must obtain the loop's end address directly from 91059 the LOOP instruction. 91060 910612022-11-12 Alan Modra <amodra@gmail.com> 91062 91063 PowerPC64 paddi -Mraw 91064 On a testcase like 91065 pla 8,foo@pcrel 91066 disassembled with -Mpower10 results in 91067 0: 00 00 10 06 pla r8,0 # 0 91068 4: 00 00 00 39 91069 0: R_PPC64_PCREL34 foo 91070 but with -Mpower10 -Mraw 91071 0: 00 00 10 06 .long 0x6100000 91072 0: R_PPC64_PCREL34 foo 91073 4: 00 00 00 39 addi r8,0,0 91074 91075 The instruction is unrecognised due to the hack we have in 91076 extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as 91077 pla. I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the 91078 condition in extract_pcrel0 under which *invalid is set, but went for 91079 this larger patch that reorders the extended insn pla to the more 91080 usual place before its underlying machine insn. (la is after addi 91081 because we never disassemble to la.) 91082 91083 gas/ 91084 * testsuite/gas/ppc/raw.d, 91085 * testsuite/gas/ppc/raw.s: Add pla. 91086 opcodes/ 91087 * ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and 91088 invert *invalid logic. 91089 (PCREL1): Rename from PCREL0. 91090 (prefix_opcodes): Sort pla before paddi, adjusting R operand 91091 for pla, paddi and psubi. 91092 910932022-11-12 Indu Bhagat <indu.bhagat@oracle.com> 91094 91095 libctf: use libtool for link test in configure 91096 The configure check for ELF support in BFD uses the AC_TRY_LINK. If 91097 libbfd's dependencies change, this macro will need to be updated 91098 manually with explicit additions to LDFLAGS and LIBS. 91099 91100 This patch updates the check to use libtool instead. 91101 91102 ChangeLog: 91103 91104 * libctf/configure.ac: Use libtool instead. 91105 * libctf/configure: Regenerated. 91106 911072022-11-12 GDB Administrator <gdbadmin@sourceware.org> 91108 91109 Automatic date update in version.in 91110 911112022-11-11 Simon Marchi <simon.marchi@polymtl.ca> 91112 91113 gdb: fix start breakpoint expression not working in some languages 91114 Commit 0be837be9fb4 ("gdb: make "start" breakpoint inferior-specific") 91115 regresses gdb.ada/start.exp: 91116 91117 (gdb) start 91118 Error in expression, near `1'. 91119 (gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right procedure 91120 91121 This is because in Ada, the equality operator is =, not ==. 91122 91123 I checked the other languages supported by GDB, these other languages 91124 use = for equality: 91125 91126 - Pascal: tests like gdb.pascal/hello.exp are affected too 91127 - Modula-2: I tried building a Modula-2 hello world using gm2, but it 91128 seems like the generated DWARF doesn't specify the Modula-2 language 91129 in the CUs, it's C++ and C, so the selected language isn't 91130 "modula-2". But if I manually do "set language modula-2" on a dummy 91131 program and then "start", I get the same error. 91132 91133 Other languages all use ==. 91134 91135 So, a short term fix would be to use = or == in the expression, based on 91136 the current language. If this was meant to be permanent, I would 91137 suggest adding something like an "equality_operator" method to 91138 language_defn, that returns the right equality operator for the 91139 language. But the goal is to replace all this with proper 91140 inferior-specific breakpoints, so I hope all this is temporary. 91141 91142 Approved-By: Tom de Vries <tdevries@suse.de> 91143 Change-Id: Id4d38e14a80e6bbbb1ad2b2277f974dd55192969 91144 911452022-11-11 Mike Frysinger <vapier@gentoo.org> 91146 91147 sim: igen: cleanup archaic pointer-to-long printf casts 91148 Use proper %p to printf a pointer instead of casting it to long and 91149 using 0x%lx. It's cleaner, more correct, and doesn't break on LLP64. 91150 911512022-11-11 Tom de Vries <tdevries@suse.de> 91152 91153 [gdb/testsuite] Don't timeout on prompt in gdb_start_cmd 91154 We're currently running into a timeout at: 91155 ... 91156 (gdb) start ^M 91157 Error in expression, near `1'.^M 91158 (gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \ 91159 procedure 91160 ... 91161 due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to 91162 the start command. 91163 91164 Fix this by handling the prompt. Reduces execution time of the test-case from 91165 1m1s to 1s. 91166 91167 Tested on x86_64-linux. 91168 911692022-11-11 Tom de Vries <tdevries@suse.de> 91170 91171 [gdb/testsuite] Better error checking in has_hw_wp_support 91172 With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support 91173 usage, which was already fixed on trunk by commits: 91174 - 13f72372413 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and 91175 - 01a32ee0b8c ("PowerPC, fix gdb.base/watchpoint.exp on Power 9") 91176 91177 While looking into these ERRORs and the commits that fix them, it occurred to 91178 me that while the commits fix the root cause, the failure mode is not great. 91179 91180 The test-cases expect a running instance of gdb upon return, which is not 91181 there, so there's an long stream of ERRORs generated as a result. 91182 91183 Fix this at the start of has_hw_wp_support, by (instead of accomodating a 91184 running gdb instance by calling gdb_exit), checking whether it's called 91185 without a running gdb instance, and erroring out otherwise. This way, there's 91186 just one error. 91187 91188 I also noticed that in case we do an early exit due to !runto_main, we don't 91189 clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from 91190 the regular exit. 91191 91192 Tested on x86_64-linux, using has_hw_wp_support for x86_64 in 91193 skip_hw_watchpoint_tests. 91194 911952022-11-11 Lancelot SIX <lancelot.six@amd.com> 91196 91197 gdb/py-inferior: Keep inferior threads in a map 91198 The python code maintains a list of threads for each inferior. This 91199 list is implemented as a linked list. When the number of threads grows 91200 high, this implementation can begin to be a performance bottleneck as 91201 finding a particular thread_object in the list has a complexity of O(N). 91202 91203 We see this in ROCgdb[1], a downstream port of GDB for AMDGUP. On 91204 AMDGPU devices, the number of threads can get significantly higher than 91205 on usual GDB workloads. 91206 91207 In some situations, we can reach the end of the inferior process with 91208 GDB still having a substantial list of known threads. While running 91209 target_mourn_inferior, we end up in inferior::clear_thread_list which 91210 iterates over all remaining threads and marks each thread exited. This 91211 fires the gdb::observers::thread_exit observer and eventually 91212 py-inferior.c:set_thread_exited gets called. This function searches in 91213 the linked list with poor performances. 91214 91215 This patch proposes to change the linked list that keeps the per 91216 inferior_object list of thread_objects into a std::unordered_map. This 91217 allows to have the search operation complexity be O(1) on average 91218 instead of O(N). 91219 91220 With this patch, we can complete clear_thread_list in about 2.5 seconds 91221 compared to 10 minutes without it. 91222 91223 Except for the performance change, no user visible change is expected. 91224 91225 Regression tested on Ubuntu-22.04 x86_64. 91226 91227 [1] https://github.com/ROCm-Developer-Tools/ROCgdb 91228 912292022-11-11 Luis Machado <luis.machado@arm.com> 91230 91231 Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr 91232 PR gdb/29272 91233 91234 Investigating PR29272, it was mentioned a particular test used to work on 91235 GDB 10, but it started failing with GDB 11 onwards. I tracked it down to 91236 some displaced stepping improvements on commit 91237 187b041e2514827b9d86190ed2471c4c7a352874. 91238 91239 In particular, one of the corner cases using copy_insn_closure_by_addr got 91240 silently broken. It is hard to spot because it doesn't have any good tests 91241 for it, and the situation is quite specific to the Arm target. 91242 91243 Essentially, the change from the displaced stepping improvements made it so 91244 we could still invoke copy_insn_closure_by_addr correctly to return the 91245 pointer to a copy_insn_closure, but it always returned nullptr due to 91246 the order of the statements in displaced_step_buffer::prepare. 91247 91248 The way it is now, we first write the address of the displaced step buffer 91249 to PC and then save the copy_insn_closure pointer. 91250 91251 The problem is that writing to PC for the Arm target requires figuring 91252 out if the new PC is thumb mode or not. 91253 91254 With no copy_insn_closure data, the logic to determine the thumb mode 91255 during displaced stepping doesn't work, and gives random results that 91256 are difficult to track (SIGILL, SIGSEGV etc). 91257 91258 Fix this by reordering the PC write in displaced_step_buffer::prepare 91259 and, for safety, add an assertion to 91260 displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right 91261 when it sees this invalid situation. If this gets broken again in the 91262 future, it will be easier to spot. 91263 91264 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 91265 91266 Approved-By: Simon Marchi <simon.marchi@efficios.com> 91267 912682022-11-11 Felix Willgerodt <felix.willgerodt@intel.com> 91269 91270 gdb, btrace: Fix rn-dl-bind.exp for new icx remark. 91271 When running the test with the latest Intel compiler: 91272 91273 Running gdb/gdb/testsuite/gdb.btrace/rn-dl-bind.exp ... 91274 gdb compile failed, icpx: warning: treating 'c' input as 'c++' when 91275 in C++ mode, this behavior is deprecated [-Wdeprecated] 91276 91277 The test doesn't seem to test something specifically for C++, 91278 so I removed the C++ compilation option. Alternatively we could rename 91279 rn-dl-bind.exp.c to rn-dl-bind.exp.cc. 91280 912812022-11-11 Bruno Larsen <blarsen@redhat.com> 91282 91283 gdb/testsuite: disable gdb.cp/call-method-register.exp when not using gcc 91284 The test gdb.cp/call-method-register.exp assumes that the class will be 91285 placed on a register. However, this keyword has been deprecated since 91286 C++11, and Clang, for instance, does not feel the need to follow it. 91287 Since this test is not usable without this working, this commit marks 91288 this test as untested. 91289 91290 Approved-by: Tom Tromey <tom@tromey.com> 91291 912922022-11-11 Bruno Larsen <blarsen@redhat.com> 91293 91294 gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp 91295 gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking 91296 for old gcc versions. However, Clang does not fail in this test, 91297 turning into XPASSes and slighty annoying when comparing between 91298 compilers. To change this, make the xfails only happen if we using gcc. 91299 91300 Approved-by: Tom Tromey <tom@tromey.com> 91301 913022022-11-11 Bruno Larsen <blarsen@redhat.com> 91303 91304 gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using Clang 91305 Since Clang chooses to not add any debug information for base types, 91306 expecting it to be included with libraries' informations, gdb.cp/typeid.exp 91307 will always fail if the program hasn't started. This commit fixes that by 91308 making it so when using Clang, the base type variables aren't tested. 91309 91310 Approved-by: Tom Tromey <tom@tromey.com> 91311 913122022-11-11 Bruno Larsen <blarsen@redhat.com> 91313 91314 gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang 91315 When Clang compiles anonymous structures, it does not add linkage names in 91316 their dwarf representations. This is compounded by Clang not adding linkage 91317 names to subprograms of those anonymous structs (for instance, the 91318 constructor). With these 2 things together, GDB is unable to refer to 91319 any of them, so there is no way to pass any of the tests of 91320 gdb.cp/anon-struct.exp 91321 91322 Since this isn't a bug on Clang or GDB according to the DWARF 91323 specifications as DW_AT_name is optional for all DIEs, the test was marked 91324 as untested. 91325 91326 Since I was already touching the file, I also added a comment at the top 91327 of the file explaining what it is testing for. 91328 91329 Approved-by: Tom Tromey <tom@tromey.com> 91330 913312022-11-11 Bruno Larsen <blarsen@redhat.com> 91332 91333 gdb/testsuite: allow for Clang style destructors on gdb.cp/m-static.exp 91334 when running gdb.cp/m-static.exp using Clang, we get the following 91335 failures: 91336 91337 print test1.~gnu_obj_1^M 91338 $6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M 91339 (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor 91340 ptype test1.~gnu_obj_1^M 91341 type = void (gnu_obj_1 * const)^M 91342 (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor 91343 print test1.'~gnu_obj_1'^M 91344 $7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M 91345 (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor 91346 91347 This is because the test is expecting an extra integer parameter on the 91348 destructor. Looking at the debuginfo, it seems that there is nothing 91349 actually wrong with this output, so these tests were changed to test 91350 multiple possible regexps. 91351 91352 Approved-by: Tom Tromey <tom@tromey.com> 91353 913542022-11-11 Bruno Larsen <blarsen@redhat.com> 91355 91356 gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang 91357 When running gdb.cp/derivation.exp using Clang, we get an unexpected 91358 failure when printing the type of a class with an internal typedef. This 91359 happens because Clang doesn't add accessibility information for typedefs 91360 inside classes (see https://github.com/llvm/llvm-project/issues/57608 91361 for more info). To help with Clang testing, an XFAIL was added to this 91362 test. 91363 91364 Approved-by: Tom Tromey <tom@tromey.com> 91365 913662022-11-11 Bruno Larsen <blarsen@redhat.com> 91367 91368 gdb/testsuite: account for clang's nested destructor calls on gdb.cp/mb-ctor.exp 91369 When compiling virtual classes's destructors, two versions are compiled, 91370 one with a single parameter (this) and the other with 2 parameters (this 91371 and vtt). 91372 91373 GCC's compilation makes it so either the version with 1 91374 parameter or the one with 2 parameters is called, depending on whether 91375 the destructor is being called by the class itself or by an inherited 91376 class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint 91377 set at the destructor will be hit 4 times. 91378 91379 Clang, on the other hand, makes the single-parameter version call the 2 91380 parameter version, probably in an attempt to reduce the size of the 91381 resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6 91382 breakpoints before finishing, and is the reason why this test was 91383 failing. To make this test stop failing, a compiler check is added and 91384 another "continue" instruction is issued to account for this difference. 91385 91386 Approved-by: Tom Tromey <tom@tromey.com> 91387 913882022-11-11 Bruno Larsen <blarsen@redhat.com> 91389 91390 gdb/testsuite: enable running gdb.cp/classes.exp with clang 91391 When attempting to run the gdb.cp/classes.exp test using Clang++, the 91392 test fails to prepare with -Wnon-c-typedef-for-linkage like the 91393 previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5 91394 unexpected failures. One such failures is: 91395 91396 ptype/r class class_with_public_typedef 91397 type = class class_with_public_typedef { 91398 private: 91399 int a; 91400 public: 91401 class_with_public_typedef::INT b; 91402 91403 private: 91404 typedef int INT; 91405 } 91406 (gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private 91407 91408 While g++ provided the following output: 91409 91410 ptype/r class class_with_public_typedef 91411 type = class class_with_public_typedef { 91412 private: 91413 int a; 91414 public: 91415 class_with_public_typedef::INT b; 91416 91417 typedef int INT; 91418 } 91419 (gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef 91420 91421 This error happens because Clang does not add DW_AT_accessibility to 91422 typedefs inside classes, and without this information GDB defaults to 91423 assuming the typedef is private. Since there is nothing that GDB can do 91424 about this, these tests have been set as xfails, and Clang bug 57608 has 91425 been filed. 91426 91427 Bug: https://github.com/llvm/llvm-project/issues/57608 91428 Approved-by: Tom Tromey <tom@tromey.com> 91429 914302022-11-11 Bruno Larsen <blarsen@redhat.com> 91431 91432 gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp 91433 When attempting to test gdb.cp/class2.exp using Clang, it fails to 91434 prepare with the following error: 91435 91436 Executing on host: clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc (timeout = 300) 91437 builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc 91438 /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage] 91439 typedef class { 91440 ^ 91441 Dbase 91442 /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration 91443 public: 91444 ^~~~~~~ 91445 /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration 91446 } Dbase; 91447 ^ 91448 1 warning generated. 91449 gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage] 91450 typedef class { 91451 ^ 91452 Dbase 91453 /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration 91454 public: 91455 ^~~~~~~ 91456 /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration 91457 } Dbase; 91458 ^ 91459 1 warning generated. 91460 UNTESTED: gdb.cp/class2.exp: failed to prepare 91461 91462 This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang 91463 11 or later. The test shows no failures with this change. 91464 91465 Approved-by: Tom Tromey <tom@tromey.com> 91466 914672022-11-11 Jan Beulich <jbeulich@suse.com> 91468 91469 gas: accept custom ".linefile <n> ." 91470 While .linefile is generally intended for gas internal use only, its use 91471 in a source file would better not result in an internal error. Give use 91472 of it outside of any macro(-like) construct the meaning of restoring the 91473 original (physical) input file name. 91474 91475 x86: drop stray IsString from PadLock insns 91476 The need for IsString on the PadLock insns went away with the 91477 introduction of RepPrefixOk. Drop these leftovers. 91478 91479 x86: drop duplicate sse4a entry from cpu_arch[] 91480 Of the two instances the first is correct in using ANY_SSE4A as 3rd 91481 argument to SUBARCH(), so drop the wrong/redundant/dead 2nd one. 91482 914832022-11-11 Alan Modra <amodra@gmail.com> 91484 91485 PR28834, PR26946 sanity checking section size 91486 This patch provides a new function to sanity check section sizes. 91487 It's mostly extracted from what we had in bfd_get_full_section_contents 91488 but also handles compressed debug sections. 91489 Improvements are: 91490 - section file offset is taken into account, 91491 - added checks that a compressed section can be read from file. 91492 91493 The function is then used when handling multiple .debug_* sections 91494 that need to be read into a single buffer, to sanity check sizes 91495 before allocating the buffer. 91496 91497 PR 26946, PR 28834 91498 * Makefile.am (LIBBFD_H_FILES): Add section.c. 91499 * compress.c (bfd_get_full_section_contents): Move section size 91500 sanity checks.. 91501 * section.c (_bfd_section_size_insane): ..to here. New function. 91502 * dwarf2.c (read_section): Use _bfd_section_size_insane. 91503 (_bfd_dwarf2_slurp_debug_info): Likewise. 91504 * Makefile.in: Regenerate. 91505 * libbfd.h: Regenerate. 91506 915072022-11-11 Alan Modra <amodra@gmail.com> 91508 91509 Sanity check SHT_MIPS_OPTIONS size 91510 * elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Use 91511 bfd_malloc_and_get_section to read contents of .MIPS.options. 91512 91513 Re: gold: add --compress-debug-sections=zstd [PR 29641] 91514 Fix the following: 91515 compressed_output.cc:86:8: error: assignment of read-only variable ‘size’ 91516 86 | size = ZSTD_compress(*compressed_data + header_size, size, uncompressed_data, 91517 915182022-11-11 Fangrui Song <maskray@google.com> 91519 91520 gold: add --compress-debug-sections=zstd [PR 29641] 91521 This option compresses output debug sections with zstd and sets ch_type 91522 to ELFCOMPRESS_ZSTD. Latest gdb and lldb support ELFCOMPRESS_ZSTD. 91523 91524 There will be an error if zstd is not enabled at configure time. 91525 91526 error: --compress-debug-sections=zstd: gold is not built with zstd support 91527 915282022-11-11 Fangrui Song <maskray@google.com> 91529 91530 gold, dwp: support zstd compressed input debug sections [PR 29641] 91531 This feature is enabled if config/zstd.m4 uses zstd. 91532 915332022-11-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 91534 91535 gprofng: fix typo in configure.ac 91536 gprofng/ChangeLog 91537 2022-11-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 91538 91539 * configure.ac: Fix typo in redirect operator. 91540 * configure: Rebuild. 91541 915422022-11-11 Vladislav Khmelevsky <och95@yandex.ru> 91543 91544 Fix adrp distance check 91545 gold/ 91546 * aarch64.cc (aarch64_valid_for_adrp_p): Shift offset 91547 as a signed number. 91548 915492022-11-11 GDB Administrator <gdbadmin@sourceware.org> 91550 91551 Automatic date update in version.in 91552 915532022-11-10 Mike Frysinger <vapier@gentoo.org> 91554 91555 sim: v850: rename v850.dc to align with other ports 91556 Other arches use the .dc extension for the instruction decode table. 91557 91558 sim: igen: fix hang when decoding boolean rule constants 91559 The parser for boolean rules fails to skip over the , separator in 91560 the options which makes it hang forever. No dc files in the tree 91561 use boolean rules atm which is why no one noticed. 91562 91563 sim: igen: mark error func as noreturn since it exits 91564 91565 sim: igen: mark output funcs with printf attribute 91566 ... and fix the legitimate bug that it catches. 91567 91568 sim: igen: constify various func arguments 91569 91570 sim: ppc: rename ppc-instructions to powerpc.igen 91571 To make it clear this is an input to the igen tool, rename it with an 91572 igen extension. This matches the other files in the ppc dir (altivec 91573 & e500 igen files), and the other igen ports (mips, mn10300, v850). 91574 915752022-11-10 H.J. Lu <hjl.tools@gmail.com> 91576 91577 i386: Check invalid (%dx) usage 91578 (%dx) isn't a valid memory address in any modes. It is used as a special 91579 memory operand for input/output port address in AT&T syntax and should 91580 only be used with input/output instructions. Update i386_att_operand to 91581 set i.input_output_operand to true for (%dx) and issue an error if (%dx) 91582 is used with non-input/output instructions. 91583 91584 PR gas/29751 91585 * config/tc-i386.c (_i386_insn): Add input_output_operand. 91586 (md_assemble): Issue an error if input/output memory operand is 91587 used with non-input/output instructions. 91588 (i386_att_operand): Set i.input_output_operand to true for 91589 (%dx). 91590 * testsuite/gas/i386/inval.l: Updated. 91591 * testsuite/gas/i386/x86-64-inval.l: Likewise. 91592 * testsuite/gas/i386/inval.s: Add tests for invalid (%dx) usage. 91593 * testsuite/gas/i386/x86-64-inval.s: Likewise. 91594 915952022-11-10 Simon Marchi <simon.marchi@efficios.com> 91596 91597 gdb: make "start" breakpoint inferior-specific 91598 I saw this failure on a CI: 91599 91600 (gdb) add-inferior 91601 [New inferior 2] 91602 Added inferior 2 91603 (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior 91604 inferior 2 91605 [Switching to inferior 2 [<null>] (<noexec>)] 91606 (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2 91607 kill 91608 The program is not being run. 91609 (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep 91610 Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep... 91611 (gdb) run & 91612 Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep 91613 (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2 91614 inferior 1 91615 [Switching to inferior 1 [<null>] (<noexec>)] 91616 (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1 91617 kill 91618 The program is not being run. 91619 (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior 91620 Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior... 91621 (gdb) break should_break_here 91622 Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25. 91623 (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here 91624 [Thread debugging using libthread_db enabled] 91625 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 91626 start 91627 Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations) 91628 Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior 91629 [Thread debugging using libthread_db enabled] 91630 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 91631 91632 Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23 91633 23 sleep (30); 91634 (gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1 91635 91636 What happens is: 91637 91638 1. We start inferior 2 with "run&", it runs very slowly, takes time to 91639 get to main 91640 2. We switch to inferior 1, and run "start" 91641 3. The temporary breakpoint inserted by "start" applies to all inferiors 91642 4. Inferior 2 hits that breakpoint and GDB reports that hit 91643 91644 To avoid this, breakpoints inserted by "start" should be 91645 inferior-specific. However, we don't have a nice way to make 91646 inferior-specific breakpoints yet. It's possible to make 91647 pspace-specific breakpoints (for example how the internal_breakpoint 91648 constructor does) by creating a symtab_and_line manually. However, 91649 inferiors can share program spaces (usually on particular embedded 91650 targets), so we could have a situation where two inferiors run the same 91651 code in the same program space. In that case, it would just not be 91652 possible to insert a breakpoint in one inferior but not the other. 91653 91654 A simple solution that should work all the time is to add a condition to 91655 the breakpoint inserted by "start", to check the inferior reporting the 91656 hit is the expected one. This is what this patch implements. 91657 91658 Add a test that does: 91659 91660 - start in background inferior 1 that sleeps before reaching its main 91661 function (using a sleep in a global C++ object's constructor) 91662 - start inferior 2 with the "start" command, which also sleeps before 91663 reaching its main function 91664 - validate that we hit the breakpoint in inferior 2 91665 91666 Without the fix, we hit the breakpoint in inferior 1 pretty much all the 91667 time. There could be some unfortunate scheduling causing the test not 91668 to catch the bug, for instance if the scheduler decides not to schedule 91669 inferior 1 for a long time, but it would be really rare. If the bug is 91670 re-introduced, the test will catch it much more often than not, so it 91671 will be noticed. 91672 91673 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91674 Approved-By: Pedro Alves <pedro@palves.net> 91675 Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a 91676 916772022-11-10 Bruno Larsen <blarsen@redhat.com> 91678 91679 gdb: Fix regressions caused by 041de3d73aa121f2ff0c077213598963bfb34b79 91680 Commit 041de3d73aa changed the output format of all error messages when 91681 GDB couldn't determine a compatible overload for a given function, but 91682 it was only supposed to change if the failure happened due to incomplete 91683 types. This commit removes the stray . that was added 91684 916852022-11-10 Aaron Merey <amerey@redhat.com> 91686 91687 gdb/debuginfod: Improve progress updates 91688 If the download size is known, a progress bar is displayed along with 91689 the percentage of completion and the total download size. 91690 91691 Downloading separate debug info for /lib/libxyz.so 91692 [############ ] 25% (10.01 M) 91693 91694 If the download size is not known, a progress indicator is displayed 91695 with a ticker ("###") that moves across the screen at a rate of 1 tick 91696 every 0.5 seconds. 91697 91698 Downloading separate debug info for /lib/libxyz.so 91699 [ ### ] 91700 91701 If the output stream is not a tty, batch mode is enabled, the screen is 91702 too narrow or width has been set to 'unlimited', then only a static 91703 description of the download is printed. No bar or ticker is displayed. 91704 91705 Downloading separate debug info for /lib/libxyz.so... 91706 91707 In any case, if the size of the download is known at the time the 91708 description is printed then it will be included in the description. 91709 91710 Downloading 10.01 MB separate debug info for /lib/libxyz.so... 91711 917122022-11-10 Simon Marchi <simon.marchi@efficios.com> 91713 91714 gdb: add special handling for frame level 0 in frame_info_ptr 91715 I noticed this problem while preparing the initial submission for the 91716 ROCm GDB port. One particularity of this patch set is that it does not 91717 support unwinding frames, that requires support of some DWARF extensions 91718 that will come later. It was still possible to run to a breakpoint and 91719 print frame #0, though. 91720 91721 When rebasing on top of the frame_info_ptr work, GDB started tripping on 91722 a prepare_reinflate call, making it not possible anymore to event print 91723 the frame when stopping on a breakpoint. One thing to know about frame 91724 0 is that its id is lazily computed when something requests it through 91725 get_frame_id. See: 91726 91727 https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L2070-2080 91728 91729 So, up to that prepare_reinflate call, frame 0's id was not computed, 91730 and prepare_reinflate, calling get_frame_id, forces it to be computed. 91731 Computing the frame id generally requires unwinding the previous frame, 91732 which with my ROCm GDB patch fails. An exception is thrown and the 91733 printing of the frame is simply abandonned. 91734 91735 Regardless of this ROCm GDB problem (which is admittedly temporary, it 91736 will be possible to unwind with subsequent patches), we want to avoid 91737 prepare_reinflate to force the computing of the frame id, for the same 91738 reasons we lazily compute it in the first place. 91739 91740 In addition, frame 0's id is subject to change across a frame cache 91741 reset. This is why save_selected_frame and restore_selected_frame have 91742 special handling for frame 0: 91743 91744 https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L1841-1863 91745 91746 For this last reason, we also need to handle frame 0 specially in 91747 prepare_reinflate / reinflate. Because the frame id of frame 0 can 91748 change across a frame cache reset, we must not rely on the frame id from 91749 that frame to reinflate it. We should instead just re-fetch the current 91750 frame at that point. 91751 91752 This patch adds a frame_info_ptr::m_cached_level field, set in 91753 frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0. 91754 There are cases where a frame_info_ptr object wraps a sentinel frame, 91755 for which frame_relative_level returns -1, so I have chosen the value -2 91756 to represent "invalid frame level", for when the frame_info_ptr object 91757 is empty. 91758 91759 In frame_info_ptr::prepare_reinflate, only cache the frame id if the 91760 frame level is not 0. It's fine to cache the frame id for the sentinel 91761 frame, it will be properly handled by frame_find_by_id later. 91762 91763 In frame_info_ptr::reinflate, if the frame level is 0, call 91764 get_current_frame to get the target's current frame. Otherwise, use 91765 frame_find_by_id just as before. 91766 91767 This patch should not have user-visible changes with upstream GDB. But 91768 it will avoid forcing the computation of frame 0's when calling 91769 prepare_reinflate. And, well, it fixes the upcoming ROCm GDB patch 91770 series. 91771 91772 Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266 91773 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91774 917752022-11-10 Simon Marchi <simon.marchi@polymtl.ca> 91776 91777 gdb: add missing prepare_reinflate call in print_frame_info 91778 print_frame_info calls frame_info_ptr::reinflate, but not 91779 frame_info_ptr::prepare_reinflate, add the call to prepare_reinflate. 91780 It works right now, because all callers of print_frame_info that could 91781 possibly lead to the pretty printers being called, and the frame_info 91782 objects being invalidated, do call prepare_reinflate themselves. And 91783 since the cached frame id is copied when passing a frame_info_ptr by 91784 value, print_frame_info does have a cached frame id on entry. So 91785 technically, this change isn't needed. But I don't think it's good for 91786 a function to rely on its callers to have called prepare_reinflate, if 91787 it intends to call reinflate. 91788 91789 Change-Id: Ie332b2d5479aef46f83fdc1120c7c83f4e84d1b0 91790 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91791 917922022-11-10 Simon Marchi <simon.marchi@efficios.com> 91793 91794 gdb: use frame_id_p instead of comparing to null_frame_id in frame_info_ptr::reinflate 91795 The assertion 91796 91797 gdb_assert (m_cached_id != null_frame_id); 91798 91799 is always true, as comparing equal to null_frame_id is always false 91800 (it's the first case in frame_id::operator==, not sure why it's not this 91801 way, but that's what it is). 91802 91803 Replace the comparison with a call to frame_id_p. 91804 91805 Approved-By: Tom Tromey <tom@tromey.com> 91806 Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb 91807 918082022-11-10 Simon Marchi <simon.marchi@efficios.com> 91809 91810 gdb: remove manual frame_info reinflation code in backtrace_command_1 91811 With the following patch applied (gdb: use frame_id_p instead of 91812 comparing to null_frame_id in frame_info_ptr::reinflate), I would get: 91813 91814 $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full" 91815 Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame... 91816 Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22. 91817 Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame 91818 [Thread debugging using libthread_db enabled] 91819 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 91820 91821 Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22 91822 22 } 91823 #0 breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22 91824 No locals. 91825 /home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed. 91826 91827 This is because the code in backtrace_command_1 to manually reinflate 91828 `fi` steps overs frame_info_ptr's toes. 91829 91830 When calling 91831 91832 fi.prepare_reinflate (); 91833 91834 `fi` gets properly filled with the cached frame id. But when this 91835 happens: 91836 91837 fi = frame_find_by_id (frame_id); 91838 91839 `fi` gets replaced by a brand new frame_info_ptr that doesn't have a 91840 cached frame id. Then this is called without a cached frame id: 91841 91842 fi.reinflate (); 91843 91844 That doesn't cause any problem currently, since 91845 91846 - the gdb_assert in the reinflate method doesn't actually do anything 91847 (the following patch fixes that) 91848 - `fi.m_ptr` will always be non-nullptr, since we just got it from 91849 frame_find_by_id, so reinflate will not do anything, it won't try to 91850 use m_cached_id 91851 91852 Fix that by removing the code to manually re-fetch the frame. That 91853 should be taken care of by frame_info_ptr::reinflate. 91854 91855 Note that the old code checked if we successfully re-inflated the frame 91856 or not, and if not it did emit a warning. The equivalent in 91857 frame_info_ptr::reinflate asserts that the frame has been successfully 91858 re-inflated. It's not clear if / when this can happen, but if it can 91859 happen, we'll need to find a solution to this problem globally 91860 (everywhere a frame_info_ptr can be re-inflated), not just here. So I 91861 propose to leave it like this, until it does become a problem. 91862 91863 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91864 Change-Id: I07b783d94e2853e0a2d058fe7deaf04eddf24835 91865 918662022-11-10 Simon Marchi <simon.marchi@polymtl.ca> 91867 91868 gdb: move frame_info_ptr method implementations to frame-info.c 91869 I don't see any particular reason why the implementations of the 91870 frame_info_ptr object are in the header file. It only seems to add some 91871 complexity. Since we can't include frame.h in frame-info.h, we have to 91872 add declarations of functions defined in frame.c, in frame-info.h. By 91873 moving the implementations to a new frame-info.c, we can avoid that. 91874 91875 Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c 91876 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91877 Reviewed-By: Tom Tromey <tom@tromey.com> 91878 918792022-11-10 Simon Marchi <simon.marchi@polymtl.ca> 91880 91881 gdb: add prepare_reinflate/reinflate around print_frame_args in info_frame_command_core 91882 I noticed this crash: 91883 91884 $ ./gdb --data-directory=data-directory -nx -q \ 91885 testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \ 91886 -x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \ 91887 -ex "b g" -ex r 91888 (gdb) info frame 91889 Stack level 0, frame at 0x7fffffffdd80: 91890 rip = 0x555555555160 in g 91891 (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3 91892 called by frame at 0x7fffffffdda0 91893 source language c. 91894 Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world", 91895 depth=10 91896 91897 Fatal signal: Segmentation fault 91898 91899 This is another case of frame_info being invalidated under a function's 91900 feet. The stack trace when the frame_info get invalidated looks like: 91901 91902 ... many frames to pretty print the arg, that eventually invalidate the frame_infos ... 91903 #35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489 91904 #36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300) 91905 at /home/simark/src/binutils-gdb/gdb/stack.c:898 91906 #37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682 91907 91908 print_frame_args knows that print_frame_arg can invalidate frame_info 91909 objects, and therefore calls prepare_reinflate/reinflate. However, 91910 info_frame_command_core has a separate frame_info_ptr instance (it is 91911 passed by value / copy). So info_frame_command_core needs to know that 91912 print_frame_args can invalidate frame_info objects, and therefore needs 91913 to prepare_reinflate/reinflate as well. Add those calls, and enhance 91914 the gdb.python/pretty-print-call-by-hand.exp test to test that command. 91915 91916 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91917 Change-Id: I9edaae06d62e97ffdb30938d364437737238a960 91918 919192022-11-10 Simon Marchi <simon.marchi@polymtl.ca> 91920 91921 gdb: clear other.m_cached_id in frame_info_ptr's move ctor 91922 We do it in the move assignment operator, so I think it makes sense to 91923 do it here too for consistency. I don't think it's absolutely necessary 91924 to clear the other object's fields (in other words, copy constructor and 91925 move constructor could be the same), as there is no exclusive resource 91926 being transfered. The important thing is to leave the moved-from object 91927 in an unknown, but valid state. But still, I think that clearing the 91928 fields of the moved-from object is not a bad idea, it helps ensure we 91929 don't rely on the moved-from object after. 91930 91931 Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340 91932 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 91933 919342022-11-10 Bruno Larsen <blarsen@redhat.com> 91935 91936 gdb/c++: Improve error messages in overload resolution 91937 When resolving overloaded functions, GDB relies on knowing relationships 91938 between types, i.e. if a type inherits from another. However, some 91939 compilers may not add complete information for given types as a way to 91940 reduce unnecessary debug information. In these cases, GDB would just say 91941 that it couldn't resolve the method or function, with no extra 91942 information. 91943 91944 The problem is that sometimes the user may not know that the type 91945 information is incomplete, and may just assume that there is a bug in 91946 GDB. To improve the user experience, we attempt to detect if the 91947 overload match failed because of an incomplete type, and warn the user 91948 of this. 91949 91950 This commit also adds a testcase confirming that the message is only 91951 triggered in the correct scenario. This test was not developed as an 91952 expansion of gdb.cp/overload.cc because it needed the dwarf assembler, 91953 and porting all of overload.cc seemed unnecessary. 91954 91955 Approved-By: Tom Tromey <tom@tromey.com> 91956 919572022-11-10 Bruno Larsen <blarsen@redhat.com> 91958 91959 gdb/testsuite: allowed for function_range to deal with mangled functions 91960 When calling get_func_info inside a test case, it would cause failures 91961 if the function was printed using a C++ style mangled name. The current 91962 patch fixes this by allowing for mangled names along with the current 91963 rules. 91964 91965 Approved-By: Tom Tromey <tom@tromey.com> 91966 919672022-11-10 Clément Chigot <chigot@adacore.com> 91968 91969 ld/testsuite: skip ld-size when -shared is not supported 91970 ld/ChangeLog: 91971 91972 * testsuite/ld-size/size.exp: Skip when -shared is not 91973 supported. 91974 919752022-11-10 Alan Modra <amodra@gmail.com> 91976 91977 mach-o reloc size overflow 91978 * mach-o.c (bfd_mach_o_canonicalize_reloc): Set bfd_error on 91979 multiply overflow. 91980 919812022-11-10 Alan Modra <amodra@gmail.com> 91982 91983 Sanity check reloc count in get_reloc_upper_bound 91984 The idea here is the stop tools from allocating up to 32G per section 91985 for the arelent pointer array, only to find a little later that the 91986 section reloc count was fuzzed. This usually doesn't hurt much (on 91987 systems that allow malloc overcommit) except when compiled with asan. 91988 91989 We already do this for ELF targets, and while fixing the logic 91990 recently I decided other targets ought to do the same. 91991 91992 * elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Sanity check 91993 section reloc count against file size. 91994 * mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise. 91995 * aoutx.h (get_reloc_upper_bound): Likewise, and don't duplicate 91996 check done in bfd_get_reloc_upper_bound. 91997 * pdp11.c (get_reloc_upper_bound): Likewise. 91998 * coffgen.c (coff_get_reloc_upper_bound): Likewise. 91999 920002022-11-10 Lancelot SIX <lancelot.six@amd.com> 92001 92002 gdb/testsuite: Fix rtld-step-nodebugsym.exp 92003 The test case introduced in bafcc335266 (Fix stepping in rtld without 92004 debug symbol) fails on some systems as reported by PR/29768. This can 92005 be seen if the system does not have debug info for the libc: 92006 92007 (gdb) step^M 92008 Single stepping until exit from function main,^M 92009 which has no line number information.^M 92010 hello world[Inferior 1 (process 48203) exited normally]^M 92011 (gdb) PASS: gdb.base/rtld-step-nodebugsym.exp: step 92012 continue^M 92013 The program is not being run.^M 92014 (gdb) FAIL: gdb.base/rtld-step-nodebugsym.exp: continue until exit (the program is no longer running) 92015 92016 Without glibc debug info, GDB steps until the program finishes, and 92017 then "gdb_continue_to_end" fails. 92018 92019 As this test was designed to check that GDB does not crash in the "step" 92020 command, the continue does not carry real meaning to the test. 92021 92022 Replace it by "print 0" so we still check that after the step command 92023 GDB is still alive, which is what we care about. 92024 92025 Tested on Ubuntu-22.04 x86_64, with and without libc6-dbg. 92026 92027 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29768 92028 Approved-By: Simon Marchi <simon.marchi@efficios.com> 92029 920302022-11-10 Mike Frysinger <vapier@gentoo.org> 92031 92032 sim: ppc: drop old makefile fragment 92033 Support for these files was dropped almost 30 years ago, but the ppc 92034 arch was missed. Clean that up now too. 92035 92036 sim: ppc: drop support for dgen -L option 92037 Nothing passes this to dgen, and even if it did, nothing would happen 92038 because the generated spreg.[ch] files don't include any references 92039 back to the original data table. So drop it to simplify. 92040 92041 sim: ppc: collapse is_readonly & length switch tables heavily 92042 Since we know we'll return 0 by default, we don't have to output case 92043 statements for readonly or length fields whose values are also zero. 92044 This is the most common case by far and thus generates a much smaller 92045 switch table in the end. 92046 920472022-11-10 Mike Frysinger <vapier@gentoo.org> 92048 92049 sim: ppc: collapse is_valid switch table more 92050 Instead of writing: 92051 case 1: 92052 return 1; 92053 case 2: 92054 return 1; 92055 ...etc... 92056 92057 Output a single return so we get: 92058 case 1: 92059 case 2: 92060 case ... 92061 return 1; 92062 92063 This saves ~100 lines of code. Hopefully the compiler was already 92064 smart enough to optimize to the same code, but if not, this probably 92065 helps there too :). 92066 920672022-11-10 Mike Frysinger <vapier@gentoo.org> 92068 92069 sim: ppc: pull default switch return out 92070 This saves a single line for the same result. By itself, it's not 92071 interesting, but we can further optimize the generated output and 92072 completely omit the switch table in some cases. Which we'll do in 92073 follow up commits. 92074 92075 sim: ppc: constify spreg table 92076 This internal table is only ever read, so constify it. 92077 920782022-11-10 Mark Harmstone <mark@harmstone.com> 92079 92080 ld: Add module information substream to PDB files 92081 920822022-11-10 Luis Machado <luis.machado@arm.com> 92083 92084 [opcodes/arm] Fix potential null pointer dereferences 92085 PR tdep/29598 92086 92087 As pointed out in the bug ticket, we have a couple potential null pointer 92088 dereferencing situations. Harden those. 92089 92090 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29598 92091 920922022-11-10 Luis Machado <luis.machado@arm.com> 92093 92094 [gdb/aarch64] Use safer memory read routines 92095 PR tdep/28796 92096 92097 As reported, we are using some memory read routines that don't handle read 92098 errors gracefully. Convert those to use the safe_* versions if available. 92099 92100 This allows the code to handle those read errors in a more sensible way. 92101 92102 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28796 92103 921042022-11-10 GDB Administrator <gdbadmin@sourceware.org> 92105 92106 Automatic date update in version.in 92107 921082022-11-09 Lancelot SIX <lancelot.six@amd.com> 92109 92110 Fix stepping in rtld without debug symbol 92111 Commit be6276e0aed "Allow debugging of runtime loader / dynamic linker" 92112 introduced a small regression when stepping into the runtime loader / 92113 dynamic linker from function we do not have debug information for. This 92114 is reported in PR/29747. 92115 92116 This can be shown by the following example (given by Simon Marchi in 92117 buzilla bug report): 92118 92119 $ cat test.c 92120 #include <stdio.h> 92121 92122 int main() 92123 { 92124 printf("Hi\n"); 92125 return 0; 92126 } 92127 $ gcc test.c -O0 -o test 92128 $ ./gdb -q -nx --data-directory=data-directory test -ex start -ex s 92129 Reading symbols from test... 92130 (No debugging symbols found in test) 92131 Temporary breakpoint 1 at 0x1151 92132 Starting program: .../binutils-gdb/gdb/test 92133 [Thread debugging using libthread_db enabled] 92134 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 92135 92136 Temporary breakpoint 1, 0x0000555555555151 in main () 92137 Single stepping until exit from function main, 92138 which has no line number information. 92139 /home/smarchi/src/binutils-gdb/gdb/infrun.c:6960:64: runtime error: member call on null pointer of type 'struct symbol' 92140 92141 The crash happens here: 92142 92143 #0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50 92144 #1 0x00007ffff5dd7128 in __ubsan::__ubsan_handle_type_mismatch_v1_abort (Data=<optimized out>, Pointer=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:148 92145 #2 0x000055556183e1a7 in process_event_stop_test (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6960 92146 #3 0x0000555561838ea4 in handle_signal_stop (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6615 92147 #4 0x000055556182f77b in handle_inferior_event (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:5866 92148 92149 When evaluating: 92150 92151 6956 if (execution_direction != EXEC_REVERSE 92152 6957 && ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE 92153 6958 && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ()) 92154 6959 && !in_solib_dynsym_resolve_code ( 92155 6961 ecs->event_thread->control.step_start_function->value_block () 92156 6962 ->entry_pc ())) 92157 92158 we dereference, ecs->event_thread->control.step_start_function which is 92159 nullptr. 92160 92161 This patch changes this condition so it evaluates to true if 92162 ecs->event_thread->control.step_start_function is nullptr since this 92163 matches the behaviour before be6276e0aed. 92164 92165 Tested on ubuntu-22.04 x86_64. 92166 92167 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29747 92168 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 92169 Approved-By: Kevin Buettner <kevinb@redhat.com> 92170 921712022-11-09 Mike Frysinger <vapier@gentoo.org> 92172 92173 sim: igen: add missing newline to various error messages 92174 The error() function expects a trailing newline in its message. 92175 Most callers do this already, so adding it to the few that don't. 92176 92177 sim: restore lstat & mkdir func checks 92178 When merging ppc configure checks into the top-level, these 2 funcs 92179 were accidentally dropped (probably due to incorrect resolution of 92180 conflicts). Restore them since the ppc code utilizes them both. 92181 92182 sim: ppc: drop obsolete USE_WIN32API check 92183 This controls only one thing: how to call mkdir(). The gnulib code 92184 already has a mkdir module that provides this exact logic for us, so 92185 punt the code entirely. 92186 921872022-11-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 92188 92189 gdbserver: do not report btrace support if target does not announce it 92190 Gdbserver unconditionally reports support for btrace packets. Do not 92191 report the support, if the underlying target does not say it supports 92192 it. Otherwise GDB would query the server with btrace-related packets 92193 unnecessarily. 92194 921952022-11-09 Tom Tromey <tromey@adacore.com> 92196 92197 Allow 'ptype/o' for assembly 92198 PR exp/28359 points out that 'ptype/o' does not work when the current 92199 language is "asm". 92200 92201 I tracked this down to a hard-coded list of languages in typeprint.c. 92202 This patch replaces this list with a method on 'language_defn' 92203 instead. If all languages are ever updated to have this feature, the 92204 method could be removed; but in the meantime this lets each language 92205 control what happens. 92206 92207 I looked at having each print_type method simply modify the flags 92208 itself, but this doesn't work very well with the feature that disables 92209 method-printing by default (but allows it via a flag). 92210 92211 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359 92212 Approved-By: Andrew Burgess <aburgess@redhat.com> 92213 Approved-By: Keith Seitz <keiths@redhat.com> 92214 922152022-11-09 Mike Frysinger <vapier@gentoo.org> 92216 92217 sim: ppc: add missing parens with e500 macro 92218 This macro expansion was missing a set of outer-most parenthesis which 92219 some compilers would complain about depending on how the macro is used. 92220 This is just standard good macro hygiene too. 92221 92222 sim: ppc: drop useless linking of helper tools 92223 We've never run these helper programs directly. The igen program 92224 includes the relevant source files directly and runs the code that 92225 way. So stop wasting developer CPU time linking programs that are 92226 never run. We leave the rules in place for people who need to test 92227 and debug the specific bits of code every now & then. 92228 922292022-11-09 Jan Beulich <jbeulich@suse.com> 92230 92231 x86/Intel: don't accept malformed EXTRQ / INSERTQ 92232 Operand swapping was mistakenly suppressed when the first two operands 92233 were immediate ones, not taking into account overall operand count. This 92234 way EXTRQ / INSERTQ would have been accepted also with kind-of-AT&T 92235 operand order. 92236 92237 For the testcase being extended, in order to not move around "GAS 92238 LISTING" expectations, suppress pagination. 92239 922402022-11-09 Alan Modra <amodra@gmail.com> 92241 92242 Re: Fuzzed files in archives 92243 Like commit ffbe89531c2e this avoids more silliness writing output 92244 that is going to be deleted. bfd_close and bfd_close_all_done differ 92245 in that only the former calls _bfd_write_contents. 92246 92247 * objcopy.c (copy_archive): Don't call bfd_close for elements 92248 that are going to be deleted, call bfd_close_all_done instead. 92249 Do the same for the archive itself. 92250 922512022-11-09 Christoph Müllner <christoph.muellner@vrull.eu> 92252 92253 RISC-V: xtheadfmemidx: Use fp register in mnemonics 92254 Although the encoding for scalar and fp registers is identical, 92255 we should follow common pratice and use fp register names 92256 when referencing fp registers. 92257 92258 The xtheadmemidx extension consists of indirect load/store instructions 92259 which all load to or store from fp registers. 92260 Let's use fp register names in this case and adjust the test cases 92261 accordingly. 92262 92263 gas/ 92264 * testsuite/gas/riscv/x-thead-fmemidx-fail.l: Updated since rd need to 92265 be float register. 92266 * testsuite/gas/riscv/x-thead-fmemidx-fail.s: Likewise. 92267 * testsuite/gas/riscv/x-thead-fmemidx.d: Likewise. 92268 * testsuite/gas/riscv/x-thead-fmemidx.s: Likewise. 92269 opcodes/ 92270 * riscv-opc.c (riscv_opcodes): Updated since rd need to be float register. 92271 922722022-11-09 H.J. Lu <hjl.tools@gmail.com> 92273 92274 ld: Always output local symbol for relocatable link 92275 PR ld/29761 92276 * elflink.c (elf_link_output_symstrtab): Don't skip local symbol 92277 in SEC_EXCLUDE section for relocatable link. 92278 922792022-11-09 GDB Administrator <gdbadmin@sourceware.org> 92280 92281 Automatic date update in version.in 92282 922832022-11-08 Simon Marchi <simon.marchi@efficios.com> 92284 92285 gdb/linux-nat: get core count using /sys/devices/system/cpu/possible 92286 I get this test failure on my CI; 92287 92288 FAIL: gdb.base/info-os.exp: get process list 92289 92290 The particularity of this setup is that builds are done in containers 92291 who are allocated 4 CPUs on a machine that has 40. The code in 92292 nat/linux-osdata.c fails to properly fetch the core number for each 92293 task. 92294 92295 linux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which 92296 returns 4, so it allocates an array of 4 integers. However, the core 92297 numbers read from /proc/pid/task/tid/stat, by function 92298 linux_common_core_of_thread, returns a value anywhere between 0 and 39. 92299 The core numbers above 3 are therefore ignored, many processes end up 92300 with no core value, and the regexp in the test doesn't match (it 92301 requires an integer as the core field). 92302 92303 The way this the CPUs are exposed to the container is that the container 92304 sees 40 CPUs "present" and "possible", but only 4 arbitrary CPUs 92305 actually online: 92306 92307 root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present 92308 0-39 92309 root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online 92310 5,11,24,31 92311 root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible 92312 0-39 92313 92314 The solution proposed in this patch is to find out the number of 92315 possible CPUs using /sys/devices/system/cpu/possible. In practice, this 92316 will probably always contain `0-N`, where N is the number of CPUs, minus 92317 one. But the documentation [1] doesn't such guarantee, so I'll assume 92318 that it can contain a more complex range list such as `2,4-31,32-63`, 92319 like the other files in that directory can have. The solution is to 92320 iterate over these numbers to find the highest possible CPU id, and 92321 use that that value plus one as the size of the array to allocate. 92322 92323 [1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst 92324 92325 Change-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3 92326 923272022-11-08 Simon Marchi <simon.marchi@efficios.com> 92328 92329 gdbsupport, gdb: add read_text_file_to_string, use it in linux_common_core_of_thread 92330 I would like to add more code to nat/linux-osdata.c that reads an entire 92331 file from /proc or /sys and processes it as a string afterwards. I 92332 would like to avoid duplicating the somewhat error-prone code that reads 92333 an entire file to a buffer. I think we should have a utility function 92334 that does that. 92335 92336 Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make 92337 linux_common_core_of_thread use it. I want to make the new function 92338 return an std::string, and because strtok doesn't play well with 92339 std::string (it requires a `char *`, std::string::c_str returns a `const 92340 char *`), change linux_common_core_of_thread to use std::string methods 92341 instead. 92342 92343 Approved-By: Tom Tromey <tom@tromey.com> 92344 Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a 92345 923462022-11-08 Peter Bergner <bergner@linux.ibm.com> 92347 92348 PowerPC: Add XSP operand define 92349 opcodes/ 92350 * ppc-opc.c (XSP): New define. 92351 (powerpc_opcodes) <stxvp, stxvpx, pstxvp>: Use it. 92352 923532022-11-08 Tom de Vries <tdevries@suse.de> 92354 92355 [gdb/cli] Make quit really quit after remote connection closed 92356 Consider a hello world a.out, started using gdbserver: 92357 ... 92358 $ gdbserver --once 127.0.0.1:2345 ./a.out 92359 Process ./a.out created; pid = 15743 92360 Listening on port 2345 92361 ... 92362 that we can connect to using gdb: 92363 ... 92364 $ gdb -ex "target remote 127.0.0.1:2345" 92365 Remote debugging using 127.0.0.1:2345 92366 Reading /home/vries/a.out from remote target... 92367 ... 92368 0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2 92369 (gdb) 92370 ... 92371 92372 After that, we can for instance quit with confirmation: 92373 ... 92374 (gdb) quit 92375 A debugging session is active. 92376 92377 Inferior 1 [process 16691] will be killed. 92378 92379 Quit anyway? (y or n) y 92380 $ 92381 ... 92382 92383 Or, kill with confirmation and quit: 92384 ... 92385 (gdb) kill 92386 Kill the program being debugged? (y or n) y 92387 [Inferior 1 (process 16829) killed] 92388 (gdb) quit 92389 $ 92390 ... 92391 92392 Or, monitor exit, kill with confirmation, and quit: 92393 ... 92394 (gdb) monitor exit 92395 (gdb) kill 92396 Kill the program being debugged? (y or n) y 92397 Remote connection closed 92398 (gdb) quit 92399 $ 92400 ... 92401 92402 But when doing monitor exit followed by quit with confirmation, we get the gdb 92403 prompt back, requiring us to do quit once more: 92404 ... 92405 (gdb) monitor exit 92406 (gdb) quit 92407 A debugging session is active. 92408 92409 Inferior 1 [process 16944] will be killed. 92410 92411 Quit anyway? (y or n) y 92412 Remote connection closed 92413 (gdb) quit 92414 $ 92415 ... 92416 92417 So, the first quit didn't quit. This happens as follows: 92418 - quit_command calls query_if_trace_running 92419 - a TARGET_CLOSE_ERROR is thrown 92420 - it's caught in remote_target::get_trace_status, but then 92421 rethrown because it's TARGET_CLOSE_ERROR 92422 - catch_command_errors catches the error, at which point the quit command 92423 has been aborted. 92424 92425 The TARGET_CLOSE_ERROR is defined as: 92426 ... 92427 /* Target throwing an error has been closed. Current command should be 92428 aborted as the inferior state is no longer valid. */ 92429 TARGET_CLOSE_ERROR, 92430 ... 92431 so in a way this is expected behaviour. But aborting quit because the inferior 92432 state (which we've already confirmed we're not interested in) is no longer 92433 valid, and having to type quit again seems pointless. 92434 92435 Furthermore, the purpose of not catching errors thrown by 92436 query_if_trace_running as per commit 2f9d54cfcef ("make -gdb-exit call 92437 disconnect_tracing too, and don't lose history if the target errors on 92438 "quit""), was to make sure that error (_("Not confirmed.") had effect. 92439 92440 Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception 92441 during query_if_trace_running and reporting it: 92442 ... 92443 (gdb) monitor exit 92444 (gdb) quit 92445 A debugging session is active. 92446 92447 Inferior 1 [process 19219] will be killed. 92448 92449 Quit anyway? (y or n) y 92450 Remote connection closed 92451 $ 92452 ... 92453 92454 Tested on x86_64-linux. 92455 92456 PR server/15746 92457 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746 92458 Approved-By: Tom Tromey <tom@tromey.com> 92459 924602022-11-08 Tom de Vries <tdevries@suse.de> 92461 92462 [gdb/testsuite] Remove test-case from test name 92463 Remove test-cases from test-names, such that we don't have the redundant: 92464 ... 92465 PASS: gdb.base/corefile.exp: backtrace in corefile.exp 92466 ... 92467 but simply: 92468 ... 92469 PASS: gdb.base/corefile.exp: backtrace 92470 ... 92471 92472 Fixed all instances found using: 92473 ... 92474 $ grep ":.*:.*\.exp" gdb.sum 92475 ... 92476 92477 Tested on x86_64-linux. 92478 924792022-11-08 Tom de Vries <tdevries@suse.de> 92480 92481 [gdb/testsuite] Fix find_core_file for core named core 92482 With test-case gdb.base/bigcore.exp I run into: 92483 ... 92484 (gdb) PASS: gdb.base/bigcore.exp: get inferior pid 92485 signal SIGABRT^M 92486 Continuing with signal SIGABRT.^M 92487 ^M 92488 Program terminated with signal SIGABRT, Aborted.^M 92489 The program no longer exists.^M 92490 (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT 92491 UNTESTED: gdb.base/bigcore.exp: can't generate a core file 92492 ... 92493 due to find_core_file returning "". 92494 92495 There is a core file name core: 92496 ... 92497 $ ls ./outputs/gdb.base/bigcore 92498 bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1 92499 ... 92500 but it's not found. 92501 92502 The problem is this statement: 92503 ... 92504 lappend files [list ${::testfile}.core core] 92505 ... 92506 which adds a single list item "${::testfile}.core core". 92507 92508 Fix this in the most readable way: 92509 ... 92510 lappend files ${::testfile}.core 92511 lappend files core 92512 ... 92513 92514 Tested on x86_64-linux. 92515 925162022-11-08 Mike Frysinger <vapier@gentoo.org> 92517 92518 sim: mips: call Unpredictable instead of setting bogus values [PR sim/29276] 92519 The intention of this code seems to be to indicate that this insn 92520 should not be used and produces undefined behavior, so instead of 92521 setting registers to bogus values, call Unpredictable. This fixes 92522 build warnings due to 32-bit/64-bit type conversions, and outputs 92523 a log message for users at runtime instead of silent corruption. 92524 92525 Bug: https://sourceware.org/PR29276 92526 925272022-11-08 Mike Frysinger <vapier@gentoo.org> 92528 92529 sim: drop unused CORE_ADDR_TYPE 92530 This hasn't been used by gdb in decades, and doesn't make sense with 92531 a standalone sim program/library where the ABI is fixed. So punt it 92532 to simplify the code. 92533 925342022-11-08 Haochen Jiang <haochen.jiang@intel.com> 92535 92536 x86: Correct wrong comments in vex_w_table 92537 Hi all, 92538 92539 This wrong comment was introduced by previous AVX-VNNI-INT8 commit. 92540 92541 Committed as obvious fix. 92542 92543 BRs, 92544 Haochen 92545 92546 opcodes/ChangeLog: 92547 92548 * i386-dis.c (VEX_W_0F3851): Corrected from 92549 VEX_W_0F3851_P_0. 92550 925512022-11-08 Kong Lingling <lingling.kong@intel.com> 92552 92553 Support Intel RAO-INT 92554 gas/ChangeLog: 92555 92556 * NEWS: Support Intel RAO-INT. 92557 * config/tc-i386.c: Add raoint. 92558 * doc/c-i386.texi: Document .raoint. 92559 * testsuite/gas/i386/i386.exp: Run RAO_INT tests. 92560 * testsuite/gas/i386/raoint-intel.d: New test. 92561 * testsuite/gas/i386/raoint.d: Ditto. 92562 * testsuite/gas/i386/raoint.s: Ditto. 92563 * testsuite/gas/i386/x86-64-raoint-intel.d: Ditto. 92564 * testsuite/gas/i386/x86-64-raoint.d: Ditto. 92565 * testsuite/gas/i386/x86-64-raoint.s: Ditto. 92566 92567 opcodes/ChangeLog: 92568 92569 * i386-dis.c (PREFIX_0F38FC): New. 92570 (prefix_table): Add PREFIX_0F38FC. 92571 * i386-gen.c: (cpu_flag_init): Add CPU_RAO_INT_FLAGS and 92572 CPU_ANY_RAO_INT_FLAGS. 92573 * i386-init.h: Regenerated. 92574 * i386-opc.h: (CpuRAO_INT): New. 92575 (i386_cpu_flags): Add cpuraoint. 92576 * i386-opc.tbl: Add RAO_INT instructions. 92577 * i386-tbl.h: Regenerated. 92578 925792022-11-08 GDB Administrator <gdbadmin@sourceware.org> 92580 92581 Automatic date update in version.in 92582 925832022-11-07 Tom Tromey <tromey@adacore.com> 92584 92585 Silence libtool during link 92586 The switch to linking with libtool now shows a very long link line 92587 even when V=0. This patch arranges to silence libtool in this 92588 situation. 92589 92590 Approved-By: Simon Marchi <simon.marchi@efficios.com> 92591 925922022-11-07 Simon Marchi <simon.marchi@efficios.com> 92593 92594 gdb: make lookup_selected_frame static 92595 Change-Id: Ide2749a34333110c7f0112b25852c78cace0d2b4 92596 925972022-11-07 Mike Frysinger <vapier@gentoo.org> 92598 92599 sim: riscv: add missing AC_MSG_RESULT call 92600 Previous commit in here forgot to include this. 92601 92602 sim: v850: drop subdir configure logic 92603 We've been using this only to set the default word size to 32. We 92604 can easily move this into the makefile via a -D compiler flag and 92605 clean up the build logic quite a bit. 92606 92607 sim: mn10300: drop subdir configure logic 92608 We've been using this only to set the default word size to 32. We 92609 can easily move this into the makefile via a -D compiler flag and 92610 clean up the build logic quite a bit. 92611 92612 sim: or1k: drop subdir configure logic 92613 We've been using this only to set the default word size to 32. We 92614 can easily move this into the makefile via a -D compiler flag and 92615 clean up the build logic quite a bit. 92616 92617 sim: bpf: drop subdir configure logic 92618 We've been using this only to set the default word size to 64. We 92619 can easily move this into the makefile via a -D compiler flag and 92620 clean up the build logic quite a bit. 92621 92622 sim: riscv: drop subdir configure logic 92623 We've been using this only to set the default word size to 32-vs-64 92624 based on the $target. We can easily merge this with the top-level 92625 configure script to clean things up a bit. 92626 926272022-11-07 Jose E. Marchesi <jose.marchesi@oracle.com> 92628 92629 gdb: link executables with libtool 92630 This patch changes the GDB build system in order to use libtool to 92631 link the several built executables. This makes it possible to refer 92632 to libtool libraries (.la files) in CLIBS. 92633 92634 As an application of the above, 92635 92636 BFD now refers to ../libbfd/libbfd.la 92637 OPCODES now refers to ../opcodes/libopcodes.la 92638 LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la 92639 LIBCTF now refers to ../libctf/libctf.la 92640 92641 NOTE1: The addition of libtool adds a few new configure-time options 92642 to GDB. Among these, --enable-shared and --disable-shared, which were 92643 previously ignored. Now GDB shall honor these options when linking, 92644 picking up the right version of the referred libtool libraries 92645 automagically. 92646 92647 NOTE2: I have not tested the insight build. 92648 92649 NOTE3: For regenerating configure I used an environment with Autoconf 92650 2.69 and Automake 1.15.1. This should match the previously 92651 used version as announced in the configure script. 92652 92653 NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and 92654 libctf.so are used by gdb if binutils is installed with 92655 --enable-shared. 92656 92657 Testing performed: 92658 92659 - --enable-shared and --disable-shared (the default in binutils) work 92660 as expected: the linked executables link with the archive or shared 92661 libraries transparently. 92662 92663 - Makefile.in modified for EXEEXT = .exe. It installs the binaries 92664 just fine. The installed gdb.exe runs fine. 92665 92666 - Native build regtested in x86_64. No regressions found. 92667 92668 - Cross build for aarch64-linux-gnu built to exercise 92669 program_transform_name and friends. The installed 92670 aarch64-linux-gnu-gdb runs fine. 92671 92672 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372 92673 Approved-By: Simon Marchi <simon.marchi@efficios.com> 92674 926752022-11-07 Simon Marchi <simon.marchi@polymtl.ca> 92676 92677 gdb/testsuite: use a more unique name in gdb.mi/mi-breakpoint-multiple-locations.exp 92678 I see failures in this test, due to the function name "add" being too 92679 generic, and unexpected breakpoint locations being found in my 92680 libstdc++, such as (wrapped for readability): 92681 92682 { 92683 number="2.4",enabled="y",addr="0x00007ffff7d67e68", 92684 func="(anonymous namespace)::fast_float::bigint::add", 92685 file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h", 92686 fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h", 92687 line="1815", thread-groups=["i1"] 92688 } 92689 92690 Change the test to use a more unique name. 92691 92692 Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d 92693 926942022-11-07 Pedro Alves <pedro@palves.net> 92695 92696 Don't explicitly set clone child ptrace options 92697 linux_handle_extended_wait calls target_post_attach if we're handling 92698 a PTRACE_EVENT_CLONE, and libthread_db.so isn't active. 92699 target_post_attach just calls linux_init_ptrace_procfs to set the 92700 lwp's ptrace options. However, this is completely unnecessary, 92701 because, as man ptrace [1] says, options are inherited: 92702 92703 "Flags are inherited by new tracees created and "auto-attached" via 92704 active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE 92705 options." 92706 92707 This removes the unnecessary call. 92708 92709 [1] - https://man7.org/linux/man-pages/man2/ptrace.2.html 92710 92711 Approved-By: Simon Marchi <simon.marchi@efficios.com> 92712 Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78 92713 927142022-11-07 Mike Frysinger <vapier@gentoo.org> 92715 92716 sim: .gdbinit: generate for all arch subdirs 92717 This was being skipped for ports that had a recursive configure, 92718 but we want it for them too. 92719 92720 sim: build: add a proper var for enabled arches 92721 The install code was using $SUBDIRS to track all enabled arches. This 92722 works, but isn't great if we want to add a subdir that isn't an arch 92723 port, or as we merge the subdirs into the top-level. Create a new var 92724 explicitly to track the list of enabled arches instead. 92725 927262022-11-07 Christophe Lyon <christophe.lyon@arm.com> 92727 92728 configure: require libzstd >= 1.4.0 92729 gas uses ZSTD_compressStream2 which is only available with libzstd >= 92730 1.4.0, leading to build errors when an older version is installed. 92731 92732 This patch updates the check libzstd presence to check its version is 92733 >= 1.4.0. However, since gas seems to be the only component requiring 92734 such a recent version this may imply that we disable ZSTD support for 92735 all components although some would still benefit from an older 92736 version. 92737 92738 I ran 'autoreconf -f' in all directories containing a configure.ac 92739 file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed 92740 several errors from autoheader in readline, as well as warnings in 92741 intl, but they are unrelated to this patch. 92742 92743 This should fix some of the buildbots. 92744 92745 OK for trunk? 92746 92747 Thanks, 92748 92749 Christophe 92750 927512022-11-07 Clément Chigot <chigot@adacore.com> 92752 92753 ld/testsuite: skip tests related to -shared when disabled 92754 Call the helper function "check_shared_lib_support" to ensure -shared 92755 is enabled before launching ld-shared, ld-elfweak and ld-elfvers. 92756 This allows to catch custom targets explicitly disabling it. 92757 92758 ld/ChangeLog: 92759 92760 * testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support. 92761 * testsuite/ld-elfweak/elfweak.exp: Likewise. 92762 * testsuite/ld-shared/shared.exp: Likewise. 92763 927642022-11-07 Tsukasa OI <research_trasio@irq.a4lg.com> 92765 92766 RISC-V: Remove RV32EF conflict 92767 Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later 92768 versions beginning with the version 20190608-Base-Ratified removed this 92769 restriction. Because the 'E' extension is still a draft, the author chose 92770 to *just* remove the conflict (not checking the ISA version). 92771 92772 Note that, because RV32E is only used with a soft-float calling convention, 92773 there's no valid official ABI for RV32EF. It means, even if we can assemble 92774 a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept 92775 in an unmanaged state (outside ABI management). 92776 92777 The purpose of this commit is to suppress unnecessary errors while parsing 92778 an ISA string and/or disassembling, not to allow hard-float with RVE. 92779 92780 bfd/ChangeLog: 92781 92782 * elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF 92783 because only older specifications disallowed it. 92784 92785 gas/ChangeLog: 92786 92787 * testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly 92788 prohibited. 92789 * testsuite/gas/riscv/march-fail-rv32ef.l: Likewise. 92790 927912022-11-07 GDB Administrator <gdbadmin@sourceware.org> 92792 92793 Automatic date update in version.in 92794 927952022-11-06 Mike Frysinger <vapier@gentoo.org> 92796 92797 sim: build: respect AM_MAKEFLAGS when entering subdirs 92798 This doesn't matter right now, but it will as we add more flags to 92799 the recursive make step to pass state down. 92800 92801 sim: build: stop passing down SIM_PRIMARY_TARGET 92802 This was needed when the install step was run in subdirs, but now 92803 that we process that entirely in the top-level, we don't need to 92804 pass this down, so drop it. 92805 928062022-11-06 GDB Administrator <gdbadmin@sourceware.org> 92807 92808 Automatic date update in version.in 92809 928102022-11-05 Tom Tromey <tom@tromey.com> 92811 92812 Deprecate MI version 1 92813 MI version 1 is long since obsolete. Rather than remove it 92814 immediately (though I did send a patch for that), instead let's 92815 deprecate it in GDB 13 and then remove it for GDB 14. 92816 92817 This version of the patch incorporates Simon's warning change, and 92818 Luis' recommendation to mention the gdb versions here. 92819 928202022-11-05 Mike Frysinger <vapier@gentoo.org> 92821 92822 sim: fix readline linkage 92823 Now that we link programs in the top dir instead of the arch subdir, 92824 update the readline library path to be relative to the top dir. 92825 92826 sim: use libtool to install programs 92827 Now that we use libtool to link, we have to use it to install instead 92828 of keeping the manual logic so we don't install wrapper shell scripts. 92829 92830 sim: bfin: move linux-fixed-code.h to top-level 92831 928322022-11-05 Mike Frysinger <vapier@gentoo.org> 92833 92834 sim: run: move linking into top-level 92835 Automake will run each subdir individually before moving on to the next 92836 one. This means that the linking phase, a single threaded process, will 92837 not run in parallel with anything else. When we have to link ~32 ports, 92838 that's 32 link steps that don't take advantage of parallel systems. On 92839 my really old 4-core system, this cuts a multi-target build from ~60 sec 92840 to ~30 sec. We eventually want to move all compile+link steps to this 92841 common dir anyways, so might as well move linking now for a nice speedup. 92842 92843 We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care 92844 of the install ourselves rather than letting automake process it. 92845 928462022-11-05 Mike Frysinger <vapier@gentoo.org> 92847 92848 sim: build: add uninstall support 92849 This never worked before, but adding it to the common top-level dir 92850 is pretty easy to do now that we're unified. 92851 92852 sim: build: move install steps to the top-level 92853 We still have to maintain custom install rules due to how we rename 92854 arch-specific files with an arch prefix in their name, but we can at 92855 least unify the logic in the common dir. 92856 92857 sim: cris: move rvdummy linking to top-level 92858 This is only used by `make check`, so we can move it out of the 92859 default build too. 92860 92861 sim: build: add SIM_HW_CFLAGS to top-level build too 92862 This matches what we do with targets already. 92863 92864 sim: drop unused SIM_HARDWARE variable 92865 This hasn't been used since the refactor way back in commit 92866 f872d0d643968c1101bb8c07b252edd54f626da2 ("Only enable H/W 92867 on some mips targets."), so punt it. 92868 92869 sim: adjust sim_hw options style 92870 We use uppercase for other variables, and are already turning it to 92871 uppercase in the arch-subdir.mk, so convert it in the configure step. 92872 92873 sim: ppc: drop unused /dev/zero logic 92874 Nothing in the tree checks this option, or has checked for decades. 92875 The pre-cvs-import ChangeLog suggests this was added & removed back 92876 then, but can't be sure as that history doesn't exist in the VCS. 92877 92878 sim: ppc: delete unused host bitsize settings 92879 Nothing checks this define anywhere, so drop all the logic. We don't 92880 want this to be a configure option in the first place as all such usage 92881 should be automatic & following proper types. 92882 92883 sim: ppc: inline the sim-packages option 92884 This has only ever had a single option that's enabled by default. 92885 The objects it adds are pretty small and don't add overhead at 92886 runtime if it isn't used, so just enable it all the time to make 92887 the build code simpler. 92888 928892022-11-05 GDB Administrator <gdbadmin@sourceware.org> 92890 92891 Automatic date update in version.in 92892 928932022-11-04 H.J. Lu <hjl.tools@gmail.com> 92894 92895 binutils: Run PR binutils/26160 test 92896 Update expected PR binutils/26160 test output for readelf out change 92897 and run PR binutils/26160 test. 92898 92899 PR binutils/26160 92900 * testsuite/binutils-all/pr26160.r: Updated. 92901 * testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test. 92902 929032022-11-04 Lancelot SIX <lancelot.six@amd.com> 92904 92905 [testsuite] gdb.base/dlmopen: Fix test name and use gdb_attach 92906 One test name in gdb.base/dlmopen.exp changes from run to run 92907 since it includes a process id: 92908 92909 PASS: gdb.base/dlmopen.exp: attach 3442682 92910 92911 This is not convenient do diff gdb.sum files to compare test runs. 92912 92913 Fix by using gdb_attach helper function to handle attaching to the 92914 process as it produce a constant test name. 92915 92916 While at it also check gdb_attach's return value to only run the 92917 rest of the test if the attach was successful. 92918 92919 Approved-By: Simon Marchi <simon.marchi@efficios.com> 92920 929212022-11-04 Carl Love <cel@us.ibm.com> 92922 92923 PowerPC update comments for the MMA instruction name changes. 92924 The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*, 92925 pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to 92926 pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*, 92927 pmdmxvi16ger* respectively. The old mnemonics are still supported by the 92928 assembler as extended mnemonics. The disassembler generates the new 92929 mnemonics. The name changes occurred in commit: 92930 92931 commit bb98553cad4e017f1851153fa5de91f2cee98fb2 92932 Author: Peter Bergner <bergner@linux.ibm.com> 92933 Date: Sat Oct 8 16:19:51 2022 -0500 92934 92935 PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions 92936 92937 gas/ 92938 * config/tc-ppc.c (md_assemble): Only check for prefix opcodes. 92939 * testsuite/gas/ppc/rfc02658.s: New test. 92940 * testsuite/gas/ppc/rfc02658.d: Likewise. 92941 * testsuite/gas/ppc/ppc.exp: Run it. 92942 92943 opcodes/ 92944 * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New. 92945 (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp, 92946 dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2, 92947 dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn, 92948 dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4, 92949 pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np, 92950 pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn, 92951 pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn. 92952 92953 This patch updates the comments in the various gdb files to reflect the 92954 name changes. There are no functional changes made by this patch. 92955 92956 The older instruction names are still used in the test 92957 gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility. 92958 92959 Patch has been tested on Power 10 with no regressions. 92960 929612022-11-04 Carl Love <cel@us.ibm.com> 92962 92963 PowerPC fix for the gdb.arch/powerpc-power10.exp test. 92964 The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*, 92965 pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to 92966 pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*, 92967 pmdmxvi16ger* respectively. The old mnemonics are still supported by the 92968 assembler as extended mnemonics. The disassembler generates the new 92969 mnemonics. The name changes occurred in commit: 92970 92971 commit bb98553cad4e017f1851153fa5de91f2cee98fb2 92972 Author: Peter Bergner <bergner@linux.ibm.com> 92973 Date: Sat Oct 8 16:19:51 2022 -0500 92974 92975 PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions 92976 92977 gas/ 92978 * config/tc-ppc.c (md_assemble): Only check for prefix opcodes. 92979 * testsuite/gas/ppc/rfc02658.s: New test. 92980 * testsuite/gas/ppc/rfc02658.d: Likewise. 92981 * testsuite/gas/ppc/ppc.exp: Run it. 92982 92983 opcodes/ 92984 * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New. 92985 (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp, 92986 dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2, 92987 dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn, 92988 dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4, 92989 pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np, 92990 pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn, 92991 pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn. 92992 92993 The above commit results in about 224 failures on Power 10 since the 92994 disassembled names do not match the expected names in the test. This 92995 patch updates the expected names in the test to match the values produced 92996 by the disassembler. 92997 92998 This patch updates file gdb.arch/powerpc-power10.exp with the new expected 92999 values to the instructions. The comment giving the name of the instruction 93000 for each binary value in the file gdb.arch/powerpc-power10.c is updated 93001 with the new name. There are no functional changes in file 93002 gdb.arch/powerpc-power10.c. 93003 930042022-11-04 Carl Love <cel@us.ibm.com> 93005 93006 Powerpc fix for gdb.base/unwind-on-each-insn.exp 93007 The test disassembles function foo and searches for the line 93008 "End of assembler dump" to determing the last address in the function. The 93009 assumption is the last instruction will be given right before the line 93010 "End of assembler dump". This assumption fails on PowerPC. 93011 93012 The PowerPC disassembly of the function foo looks like: 93013 Dump of assembler code for function foo: 93014 # => 0x00000000100006dc <+0>: std r31,-8(r1) 93015 # 0x00000000100006e0 <+4>: stdu r1,-48(r1) 93016 # 0x00000000100006e4 <+8>: mr r31,r1 93017 # 0x00000000100006e8 <+12>: nop 93018 # 0x00000000100006ec <+16>: addi r1,r31,48 93019 # 0x00000000100006f0 <+20>: ld r31,-8(r1) 93020 # 0x00000000100006f4 <+24>: blr 93021 # 0x00000000100006f8 <+28>: .long 0x0 93022 # 0x00000000100006fc <+32>: .long 0x0 93023 # 0x0000000010000700 <+36>: .long 0x1000180 93024 # End of assembler dump. 93025 93026 The blr instruction is the last instruction in function foo. The lines 93027 with .long following the blr instruction need to be ignored. 93028 93029 This patch adds a new condition to the gdb_test_multiple "disassemble foo" 93030 test to ignore the lines with the .long. 93031 93032 The patch has been tested on PowerPC and Intel X86-64. 93033 930342022-11-04 Jan Beulich <jbeulich@suse.com> 93035 93036 x86: adjust recently introduced testcases 93037 The issue addressed by 2c02c72c62d2 ("re: Support Intel AMX-FP16") has 93038 been introduced once again in a number of new tests. 93039 930402022-11-04 Nick Clifton <nickc@redhat.com> 93041 93042 Update release documentation with regard to uploading gprofng docs 93043 930442022-11-04 Bruno Larsen <blarsen@redhat.com> 93045 93046 gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp 93047 Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug 93048 PR record/29745, where we can't skip one funcion forward if we're using 93049 native-gdbserver. This commit just adds kfails to the test. 93050 93051 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745 93052 Approved-By: Simon Marchi <simon.marchi@efficios.com> 93053 930542022-11-04 Andrew Burgess <aburgess@redhat.com> 93055 93056 opcodes/arm: silence compiler warning about uninitialized variable use 93057 After this commit: 93058 93059 commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf 93060 Date: Thu Jul 7 13:43:45 2022 +0100 93061 93062 opcodes/arm: add disassembler styling for arm 93063 93064 Some people were seeing their builds failing with complaints about a 93065 possible uninitialized variable usage. I previously fixed an instance 93066 of this issue in this commit: 93067 93068 commit 2df82cd4b459fbc32120e0ad1ce19e26349506fe 93069 Date: Tue Nov 1 10:36:59 2022 +0000 93070 93071 opcodes/arm: silence compiler warning about uninitialized variable use 93072 93073 which did fix the build problems that the sourceware buildbot was 93074 hitting, however, an additional instance of the same problem was 93075 brought to my attention, and that is fixed in this commit. 93076 93077 Where commit 2df82cd4b4 fixed the uninitialized variable problem in 93078 print_mve_unpredictable, this commit fixes the same problem in 93079 print_mve_undefined. 93080 93081 As with the previous commit, I don't believe we could really ever get 93082 an uninitialized variable usage, based on the current usage of the 93083 function, so I have just initialized the reason variable to "??". 93084 930852022-11-04 Mike Frysinger <vapier@gentoo.org> 93086 93087 sim: rx: drop unused $arch setting 93088 This is only needed for CGEN ports which RX isn't, so drop it. 93089 930902022-11-04 Mike Frysinger <vapier@gentoo.org> 93091 93092 sim: build: remove various obsolete generation dep variables 93093 These manual settings were necessary when we weren't doing automatic 93094 header dependency tracking. That was changed a while ago, and we use 93095 automake now to do it all for us. As a result, many of these vars 93096 aren't even referenced anymore. 93097 93098 Further, some of the source file generation (e.g. .c files, or igen, 93099 or cgen outputs) were moved to the common automake build, and it takes 93100 care of dependency tracking for us with the object files. 93101 931022022-11-04 Mike Frysinger <vapier@gentoo.org> 93103 93104 sim: don't hardcode -ldl for SDL support 93105 Since we use AC_SEARCH_LIBS to find dlopen, we don't need to hardcode 93106 -ldl when using SDL ourselves. 93107 931082022-11-04 konglin1 <lingling.kong@intel.com> 93109 93110 Support Intel AVX-NE-CONVERT 93111 gas/ChangeLog: 93112 93113 * NEWS: Support Intel AVX-NE-CONVERT. 93114 * config/tc-i386.c: Add avx_ne_convert. 93115 * doc/c-i386.texi: Document .avx_ne_convert. 93116 * testsuite/gas/i386/i386.exp: Run AVX NE CONVERT tests. 93117 * testsuite/gas/i386/avx-ne-convert-intel.d: New test. 93118 * testsuite/gas/i386/avx-ne-convert.d: Ditto. 93119 * testsuite/gas/i386/avx-ne-convert.s: Ditto. 93120 * testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto. 93121 * testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto. 93122 * testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto. 93123 93124 opcodes/ChangeLog: 93125 93126 * i386-dis.c (Mw): New. 93127 (PREFIX_VEX_0F3872): Ditto. 93128 (PREFIX_VEX_0F38B0_W_0): Ditto. 93129 (PREFIX_VEX_0F38B1_W_0): Ditto. 93130 (VEX_W_0F3872_P_1): Ditto. 93131 (VEX_W_0F38B0): Ditto. 93132 (VEX_W_0F38B1): Ditto. 93133 (prefix_table): Add PREFIX_VEX_0F3872, PREFIX_VEX_0F38B0_W_0, 93134 PREFIX_VEX_0F38B1_W_0. 93135 (vex_w_table): Add VEX_W_0F3872_P_1, VEX_W_0F38B0, VEX_W_0F38B1. 93136 * i386-gen.c (cpu_flag_init): Add CPU_AVX_NE_CONVERT_FLGAS and 93137 CPU_ANY_AVX_NE_CONVERT_FLAGS. 93138 (cpu_flags): Add CpuAVX_NE_CONVERT. 93139 * i386-init.h: Regenerated. 93140 * i386-opc.h (CpuAVX_NE CONVERT): New. 93141 (i386_cpu_flags): Add cpuavx_ne_convert. 93142 * i386-opc.tbl: Add Intel AVX-NE-CONVERT instructions. 93143 * i386-tbl.h: Regenerated. 93144 931452022-11-04 konglin1 <lingling.kong@intel.com> 93146 93147 i386: Rename <xy> template. 93148 opcodes/ 93149 * i386-opc.tbl: Rename <xy> template for VEX insn with x/y suffix to <Vxy>. 93150 Rename <xy> for EVEX insn with x/y suffix to <Exy>. 93151 931522022-11-04 Jojo R <rjiejie@linux.alibaba.com> 93153 93154 Support multiple .eh_frame sections 93155 This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE, 93156 it allows backend to enable this feature and use '--gc-sections' simply. 93157 93158 * gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New. 93159 (MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. 93160 * gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. 93161 (is_now_linkonce_segment): Likewise. 93162 (get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section. 93163 93164 * bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New. 93165 * bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise. 93166 * bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for 93167 elf_backend_can_make_multiple_eh_frame. 93168 931692022-11-04 Jojo R <rjiejie@linux.alibaba.com> 93170 93171 gas/doc/internals.texi: fix typo 93172 * gas/doc/internals.texi (md_emit_single_noop_insn): 93173 fix '@var missing closing brace' 93174 * gas/doc/internals.texi (Hash tables): 93175 fix '@menu reference to nonexistent node `Hash tables'' 93176 931772022-11-04 Mike Frysinger <vapier@gentoo.org> 93178 93179 sim: drop -lm from SIM_EXTRA_LIBS 93180 We have configure tests for this in the top-level configure script 93181 to link this when necessary, so we don't need to explicitly list it 93182 for specific ports. 93183 93184 sim: build: change AC_CHECK_LIB to AC_SEARCH_LIBS 93185 With more C libraries moving functions entirely into the main -lc, 93186 change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there 93187 first and avoid extra linkage when possible. 93188 93189 sim: build: drop duplicate $(LIBS) usage 93190 COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus 93191 @LIBS@. This leds to the values being used twice. Inline the 93192 CONFIG_LIBS variable without @LIBS@ since it's used only once. 93193 93194 sim: build: switch to bfd & opcodes libtool linker scripts 93195 Now that we use libtool to link, we don't need to duplicate all the 93196 libs that bfd itself uses. This simplifies the configure & Makefile. 93197 93198 sim: build: switch to libtool for linking 93199 The top-level already sets up a libtool script for the host, so use 93200 that when linking rather than invoking CC directly. This will also 93201 happen when we (someday) move the building to pure automake. 93202 932032022-11-04 GDB Administrator <gdbadmin@sourceware.org> 93204 93205 Automatic date update in version.in 93206 932072022-11-03 Mike Frysinger <vapier@gentoo.org> 93208 93209 sim: testsuite: fix cris stat3 in diff setups 93210 This test uses the test itself as an input to stating regular files. 93211 This gets funky though: when we run check in parallel, the output 93212 object dir is the subdir that matches the .exp file. When we run 93213 with -j1, the output object dir is the sim builddir itself. 93214 93215 The old test would append argv[0] to find the file, while the new 93216 test uses basename on it. Each method works in only one of the 93217 aforementioned build scenarios. Rather than complicate this any 93218 more, switch to a different file that we know will always exist: 93219 the Makefile. 93220 932212022-11-03 Mike Frysinger <vapier@gentoo.org> 93222 93223 sim: testsuite: fix cris badarch in multi-target builds 93224 This test assumes that /bin/sh will never be a CRIS ELF by way of 93225 assuming that the current bfd cannot load it (since a basic cris 93226 cross-compiler only understands CRIS ELFs). In a multi-target 93227 build though, bfd understands just about every ELF out there, so 93228 we're able to read the /bin/sh format before failing at a diff 93229 point in the cris code. 93230 93231 Let's switch to using / instead since it'll fail for a similar 93232 reason (at least similar enough for what this test is testing). 93233 932342022-11-03 Mike Frysinger <vapier@gentoo.org> 93235 93236 sim: cleanup unused SIM_EXTRA_CFLAGS 93237 We want to eventually delete this, so at least drop the empty ones. 93238 93239 sim: m32c/rx: drop useless $(ENDLIST) 93240 This is used to allow for dangling \ in object lists, but these are the 93241 only ports that do it, and it isn't really necessary. Punt it to keep 93242 the various makefiles harmonized. 93243 93244 sim: mips: simplify fpu configure logic 93245 The configure code always defaults to HARD_FLOATING_POINT, so inline 93246 that value and drop redundant target checks as a result. 93247 932482022-11-03 Mike Frysinger <vapier@gentoo.org> 93249 93250 sim: erc32: link sis to run program 93251 The erc32 sim does a lot itself, including handling of the CLI. It 93252 used to provide a run-compatible interface in the pre-nrun days, but 93253 it was dropped when the old run interface was punted. Since the old 93254 commit 465fb143c87076b6416a8d0d5dd79bb016060fe3 ("sim: make nrun the 93255 default run program"), the erc32 run & sis programs have been the 93256 same, and erc32 hasn't provide a real run-compatible interface. 93257 93258 Simplify this by linking the two programs via ln/cp instead of running 93259 the linking phase twice to produce the same result. If/when we fix up 93260 the erc32 port to have a proper run interface, it should be easy to 93261 split these back apart into real programs. 93262 93263 Note: the interf.o reference in here is a bit of a misdirect. Since 93264 that object is placed into libsim.a, it's never been linked into the 93265 programs since the linker ignores objects that aren't referenced, and 93266 only gdb uses those symbols. 93267 932682022-11-03 Nick Clifton <nickc@redhat.com> 93269 93270 V850 Linker: do not complain about RWX segments. 93271 PR 29748 93272 * configure.tgt (ac_default_ld_warn_rwx_segments): Set to 0 for 93273 the V850. 93274 932752022-11-03 Mike Frysinger <vapier@gentoo.org> 93276 93277 sim: v850: switch to standard (high-level) trace defines 93278 The v850 port uses -DDEBUG to control whether to enable internal tracing. 93279 We already have such options via the common trace framework, and those 93280 can be controlled at build time via configure flags (which the v850 code 93281 currently cannot). So switch it over to WITH_TRACE_ANY_P to simplify the 93282 v850 build code even if it doesn't (yet) respect any other trace options. 93283 93284 sim: ppc: include copyright & license in --version 93285 This makes it match the other sim run programs and GNU tools. 93286 93287 sim: update --version copyright year 93288 Probably should have done this 11 months ago ... 93289 93290 sim: ppc: drop use of DATE & TIME 93291 No other tool does this, sim or otherwise, and it makes the ppc build 93292 non-reproducible. Drop it to simplify & make reproducible. 93293 932942022-11-03 Bruno Larsen <blarsen@redhat.com> 93295 93296 gdb: Fix issue with Clang CLI macros 93297 Clang up to version 15 (current) adds macros that were defined in the 93298 command line or by "other means", according to the Dwarf specification, 93299 after the last DW_MACRO_end_file, instead of before the first 93300 DW_MACRO_start_file, as the specification dictates. When GDB reads the 93301 macros after the last file is closed, the macros never end up "in scope" 93302 and so we can't print them. This has been submitted as a bug to Clang 93303 developers (https://github.com/llvm/llvm-project/issues/54506), and PR 93304 macros/29034 was opened for GDB to keep track of this. 93305 93306 Seeing as there is no expected date for it to be fixed, add a workaround 93307 for all current versions of Clang. The workaround detects when 93308 the main file would be closed and if the producer is Clang, and turns 93309 that operation into a noop, so we keep a reference to the current_file 93310 as those macros are read. 93311 93312 A test case was added to confirm the functionality, and the KFAIL for 93313 running gdb.base/macro-source-path when using clang. 93314 93315 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29034 93316 Approved-By: Simon Marchi <simon.marchi@efficios.com> 93317 933182022-11-03 Nick Clifton <nickc@redhat.com> 93319 93320 AVR Linker: Allow the start of the data region to be specified on the linker command line. [Fix PR number in ChangeLog entry] 93321 PR 29741 93322 * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value 93323 has not been provided on the command line then use DATA_ORIGIN. 93324 (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region. 93325 93326 AVR Linker: Allow the start of the data region to specified on the command line. 93327 PR 29471 93328 * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value 93329 has not been provided on the command line then use DATA_ORIGIN. 93330 (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region. 93331 933322022-11-03 Mike Frysinger <vapier@gentoo.org> 93333 93334 sim: move common flags to default AM_CPPFLAGS 93335 Since all host files we compile use these settings, move them out of 93336 libcommon.a and into the default AM_CPPFLAGS. This has the effect of 93337 dropping the custom per-target automake rules. Currently it saves us 93338 ~150 lines, but since it's about ~8 lines per object, the overhead 93339 will increase quite a bit as we merge more files into a single build. 93340 93341 This also changes the object output names, so we have to tweak the 93342 rules that were pulling in the common objects when linking. 93343 933442022-11-03 Mike Frysinger <vapier@gentoo.org> 93345 93346 sim: merge gnulib logic into the top-level 93347 We aren't using this just yet, but we will, so make it available to 93348 building of common sim files. 93349 93350 sim: common: remove unused include paths 93351 A bunch of these paths don't include any headers, and most likely 93352 never will, so there's no real need to keep them. This will let 93353 us harmonize paths with the top-level Makefile more easily, which 93354 will in turn make it easier to move more compile steps there. 93355 933562022-11-03 GDB Administrator <gdbadmin@sourceware.org> 93357 93358 Automatic date update in version.in 93359 933602022-11-02 Christophe Lyon <christophe.lyon@arm.com> 93361 93362 arm: PR 29739 Fix typo where ';' should not have been replaced with '@' 93363 ';' does not always indicate the start of a comment, and commit 93364 8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3 93365 instances of ';' with '@' in expected diagnostics, leading to tests 93366 failures. 93367 93368 This patch restores the original ';' as needed in these testcases. 93369 93370 Fixes bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29739 93371 933722022-11-02 Mike Frysinger <vapier@gentoo.org> 93373 93374 sim: split CPPFLAGS between build & host 93375 In order to merge more common/ files into the top-level, we need to 93376 add more host flags to CPPFLAGS, and that conflicts with our current 93377 use with build-time tools. So split them apart like we do with all 93378 other build flags to avoid the issue. 93379 93380 sim: h8300: switch to cpu for state 93381 Rather than rely on pulling out the first cpu from the sim state 93382 for cpu state, pass down the active cpu that's already available. 93383 93384 sim: common: change sim_{fetch,store}_register helpers to use void* buffers 93385 When reading/writing arbitrary data to the system's memory, the unsigned 93386 char pointer type doesn't make that much sense. Switch it to void so we 93387 align a bit with standard C library read/write functions, and to avoid 93388 having to sprinkle casts everywhere. 93389 933902022-11-02 Jon Turney <jon.turney@dronecode.org.uk> 93391 93392 Fix Cygwin build after 20489cca 93393 Update code under __CYGWIN__ which accesses inferior process information 93394 which is now stored in windows_process_info rather than globals. 93395 933962022-11-02 Jon Turney <jon.turney@dronecode.org.uk> 93397 93398 Fix Cygwin build after bcb9251f 93399 Absent _UNICODE being defined (which gdb's Makefile doesn't do), 93400 windows.h will always define STARTUPINFO is as STARTUPINFOA, so this 93401 cast isn't correct when create_process expects a STARTUPINFOW 93402 parameter (i.e. in a Cygwin build). 93403 93404 Instead write this as &info_ex.StartupInfo (which is always of the 93405 correct type). 93406 934072022-11-02 Jan Beulich <jbeulich@suse.com> 93408 93409 x86: drop bogus Tbyte 93410 Prior to commit 1cb0ab18ad24 ("x86/Intel: restrict suffix derivation") 93411 the Tbyte modifier on the FLDT and FSTPT templates was pointless, as 93412 No_ldSuf would have prevented it being accepted. Due to the special 93413 nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these 93414 insns being accepted in Intel syntax mode even when "tbyte ptr" was 93415 present. Restore original behavior by dropping Tbyte there. (Note that 93416 these insns in principle should by marked AT&T syntax only, but since 93417 they haven't been so far we probably shouldn't change that.) 93418 93419 x86: simplify expressions in update_imm() 93420 Comparing the sum of the relevant .imm<N> fields against a constant imo 93421 makes more obvious what is actually meant. It allows dropping of two 93422 static variables, with a 3rd drop requiring two more minor adjustments 93423 elsewhere, utilizing that "i" is zeroed first thing in md_assemble(). 93424 This also increases the chances of the compiler doing the calculations 93425 all in registers. 93426 934272022-11-02 Nelson Chu <nelson@rivosinc.com> 93428 93429 RISC-V: Fixed the missing $x+arch when adding odd paddings for alignment. 93430 Consider the case, 93431 93432 .option arch, rv32i 93433 .option norelax 93434 .option arch, +c 93435 .byte 1 93436 .align 2 93437 addi a0, zero, 1 93438 93439 Assembler adds $d for the odd .byte, and then adds $x+arch for the 93440 alignment. Since norelax, riscv_add_odd_padding_symbol will add the 93441 $d and $x for the odd alignment, but accidently remove the $x+arch because 93442 it has the same address as $d. Therefore, we will get the unexpected result 93443 before applying this patch, 93444 93445 .byte 1 # $d 93446 .align 2 # odd alignment, $xrv32ic replaced by $d + $x 93447 93448 After this patch, the expected result should be, 93449 93450 .byte 1 # $d 93451 .align 2 # odd alignment, $xrv32ic replaced by $d + $xrv32ic 93452 93453 gas/ 93454 * config/tc-riscv.c (make_mapping_symbol): If we are adding mapping symbol 93455 for odd alignment, then we probably will remove the $x+arch by accidently 93456 when it has the same address of $d. Try to add the removed $x+arch back 93457 after the $d rather than just $x. 93458 (riscv_mapping_state): Updated since parameters of make_mapping_symbol are 93459 changed. 93460 (riscv_add_odd_padding_symbol): Likewise. 93461 (riscv_remove_mapping_symbol): Removed and moved the code into the 93462 riscv_check_mapping_symbols. 93463 (riscv_check_mapping_symbols): Updated. 93464 * testsuite/gas/riscv/mapping-dis.d: Updated and added new testcase. 93465 * testsuite/gas/riscv/mapping-symbols.d: Likewise. 93466 * testsuite/gas/riscv/mapping.s: Likewise. 93467 934682022-11-02 Hu, Lin1 <lin1.hu@intel.com> 93469 93470 Support Intel MSRLIST 93471 gas/ChangeLog: 93472 93473 * NEWS: Support Intel MSRLIST. 93474 * config/tc-i386.c: Add msrlist. 93475 * doc/c-i386.texi: Document .msrlist. 93476 * testsuite/gas/i386/i386.exp: Add MSRLIST tests. 93477 * testsuite/gas/i386/msrlist-inval.l: New test. 93478 * testsuite/gas/i386/msrlist-inval.s: Ditto. 93479 * testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto. 93480 * testsuite/gas/i386/x86-64-msrlist.d: Ditto. 93481 * testsuite/gas/i386/x86-64-msrlist.s: Ditto. 93482 93483 opcodes/ChangeLog: 93484 93485 * i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_6_P_1): New. 93486 (X86_64_0F01_REG_0_MOD_3_RM_6_P_3): Ditto. 93487 (prefix_table): New entry for msrlist. 93488 (x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_6_P_1 93489 and X86_64_0F01_REG_0_MOD_3_RM_6_P_3. 93490 * i386-gen.c (cpu_flag_init): Add CPU_MSRLIST_FLAGS 93491 and CPU_ANY_MSRLIST_FLAGS. 93492 * i386-init.h: Regenerated. 93493 * i386-opc.h (CpuMSRLIST): New. 93494 (i386_cpu_flags): Add cpumsrlist. 93495 * i386-opc.tbl: Add MSRLIST instructions. 93496 * i386-tbl.h: Regenerated. 93497 934982022-11-02 Hu, Lin1 <lin1.hu@intel.com> 93499 93500 Support Intel WRMSRNS 93501 gas/ChangeLog: 93502 93503 * NEWS: Support Intel WRMSRNS. 93504 * config/tc-i386.c: Add wrmsrns. 93505 * doc/c-i386.texi: Document .wrmsrns. 93506 * testsuite/gas/i386/i386.exp: Add WRMSRNS tests. 93507 * testsuite/gas/i386/wrmsrns-intel.d: New test. 93508 * testsuite/gas/i386/wrmsrns.d: Ditto. 93509 * testsuite/gas/i386/wrmsrns.s: Ditto. 93510 * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto. 93511 * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto. 93512 93513 opcodes/ChangeLog: 93514 93515 * i386-dis.c (PREFIX_0F01_REG_0_MOD_3_RM_6): New. 93516 (prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_6. 93517 (rm_table): New entry for wrmsrns. 93518 * i386-gen.c (cpu_flag_init): Add CPU_WRMSRNS_FLAGS 93519 and CPU_ANY_WRMSRNS_FLAGS. 93520 (cpu_flags): Add CpuWRMSRNS. 93521 * i386-init.h: Regenerated. 93522 * i386-opc.h (CpuWRMSRNS): New. 93523 (i386_cpu_flags): Add cpuwrmsrns. 93524 * i386-opc.tbl: Add WRMSRNS instructions. 93525 * i386-tbl.h: Regenerated. 93526 935272022-11-02 Kong Lingling <lingling.kong@intel.com> 93528 93529 Add handler for more i386_cpu_flags 93530 gas/ChangeLog: 93531 93532 * config/tc-i386.c (cpu_flags_all_zero): Add new ARRAY_SIZE handle. 93533 (cpu_flags_equal): Ditto. 93534 (cpu_flags_and): Ditto. 93535 (cpu_flags_or): Ditto. 93536 (cpu_flags_and_not): Ditto. 93537 935382022-11-02 Haochen Jiang <haochen.jiang@intel.com> 93539 93540 Support Intel CMPccXADD 93541 gas/ChangeLog: 93542 93543 * NEWS: Support Intel CMPccXADD. 93544 * config/tc-i386.c: Add cmpccxadd. 93545 (build_modrm_byte): Add operations for Vex.VVVV reg 93546 on operand 0 while have memory operand. 93547 * doc/c-i386.texi: Document .cmpccxadd. 93548 * testsuite/gas/i386/i386.exp: Run CMPccXADD tests. 93549 * testsuite/gas/i386/cmpccxadd-inval.s: New test. 93550 * testsuite/gas/i386/cmpccxadd-inval.l: Ditto. 93551 * testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto. 93552 * testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto. 93553 * testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto. 93554 93555 opcodes/ChangeLog: 93556 93557 * i386-dis.c (Mdq): New. 93558 (X86_64_VEX_0F38E0): Ditto. 93559 (X86_64_VEX_0F38E1): Ditto. 93560 (X86_64_VEX_0F38E2): Ditto. 93561 (X86_64_VEX_0F38E3): Ditto. 93562 (X86_64_VEX_0F38E4): Ditto. 93563 (X86_64_VEX_0F38E5): Ditto. 93564 (X86_64_VEX_0F38E6): Ditto. 93565 (X86_64_VEX_0F38E7): Ditto. 93566 (X86_64_VEX_0F38E8): Ditto. 93567 (X86_64_VEX_0F38E9): Ditto. 93568 (X86_64_VEX_0F38EA): Ditto. 93569 (X86_64_VEX_0F38EB): Ditto. 93570 (X86_64_VEX_0F38EC): Ditto. 93571 (X86_64_VEX_0F38ED): Ditto. 93572 (X86_64_VEX_0F38EE): Ditto. 93573 (X86_64_VEX_0F38EF): Ditto. 93574 (x86_64_table): Add X86_64_VEX_0F38E0, X86_64_VEX_0F38E1, 93575 X86_64_VEX_0F38E2, X86_64_VEX_0F38E3, X86_64_VEX_0F38E4, 93576 X86_64_VEX_0F38E5, X86_64_VEX_0F38E6, X86_64_VEX_0F38E7, 93577 X86_64_VEX_0F38E8, X86_64_VEX_0F38E9, X86_64_VEX_0F38EA, 93578 X86_64_VEX_0F38EB, X86_64_VEX_0F38EC, X86_64_VEX_0F38ED, 93579 X86_64_VEX_0F38EE, X86_64_VEX_0F38EF. 93580 * i386-gen.c (cpu_flag_init): Add CPU_CMPCCXADD_FLAGS and 93581 CPU_ANY_CMPCCXADD_FLAGS. 93582 (cpu_flags): Add CpuCMPCCXADD. 93583 * i386-init.h: Regenerated. 93584 * i386-opc.h (CpuCMPCCXADD): New. 93585 (i386_cpu_flags): Add cpucmpccxadd. Comment unused for it is actually 0. 93586 * i386-opc.tbl: Add Intel CMPccXADD instructions. 93587 * i386-tbl.h: Regenerated. 93588 935892022-11-02 Cui,Lili <lili.cui@intel.com> 93590 93591 Support Intel AVX-VNNI-INT8 93592 gas/ 93593 * NEWS: Support Intel AVX-VNNI-INT8. 93594 * config/tc-i386.c: Add avx_vnni_int8. 93595 * doc/c-i386.texi: Document avx_vnni_int8. 93596 * testsuite/gas/i386/avx-vnni-int8-intel.d: New file. 93597 * testsuite/gas/i386/avx-vnni-int8.d: Likewise. 93598 * testsuite/gas/i386/avx-vnni-int8.s: Likewise. 93599 * testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Likewise. 93600 * testsuite/gas/i386/x86-64-avx-vnni-int8.d: Likewise. 93601 * testsuite/gas/i386/x86-64-avx-vnni-int8.s: Likewise. 93602 * testsuite/gas/i386/i386.exp: Run AVX VNNI INT8 tests. 93603 93604 opcodes/ 93605 * i386-dis.c: (PREFIX_VEX_0F3850) New. 93606 (PREFIX_VEX_0F3851): Likewise. 93607 (VEX_W_0F3850_P_0): Likewise. 93608 (VEX_W_0F3850_P_1): Likewise. 93609 (VEX_W_0F3850_P_2): Likewise. 93610 (VEX_W_0F3850_P_3): Likewise. 93611 (VEX_W_0F3851_P_0): Likewise. 93612 (VEX_W_0F3851_P_1): Likewise. 93613 (VEX_W_0F3851_P_2): Likewise. 93614 (VEX_W_0F3851_P_3): Likewise. 93615 (VEX_W_0F3850): Delete. 93616 (VEX_W_0F3851): Likewise. 93617 (prefix_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851. 93618 (vex_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851, 93619 delete VEX_W_0F3850 and VEX_W_0F3851. 93620 (vex_w_table): Add VEX_W_0F3850_P_0, VEX_W_0F3850_P_1, VEX_W_0F3850_P_2 93621 VEX_W_0F3850_P_3, VEX_W_0F3851_P_0, VEX_W_0F3851_P_1, VEX_W_0F3851_P_2 93622 and VEX_W_0F3851_P_3, delete VEX_W_0F3850 and VEX_W_0F3851. 93623 * i386-gen.c: (cpu_flag_init): Add CPU_AVX_VNNI_INT8_FLAGS 93624 and CPU_ANY_AVX_VNNI_INT8_FLAGS. 93625 (cpu_flags): Add CpuAVX_VNNI_INT8. 93626 * i386-opc.h (CpuAVX_VNNI_INT8): New. 93627 * i386-opc.tbl: Add Intel AVX_VNNI_INT8 instructions. 93628 * i386-init.h: Regenerated. 93629 * i386-tbl.h: Likewise. 93630 936312022-11-02 Hongyu Wang <hongyu.wang@intel.com> 93632 Haochen Jiang <haochen.jiang@intel.com> 93633 93634 Support Intel AVX-IFMA 93635 x86: Support Intel AVX-IFMA 93636 93637 Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is 93638 cleared by default. Without {vex} pseudo prefix, Intel IFMA instructions 93639 are encoded with EVEX prefix. {vex} pseudo prefix will turn on VEX 93640 encoding for Intel IFMA instructions. 93641 93642 gas/ 93643 93644 * NEWS: Support Intel AVX-IFMA. 93645 * config/tc-i386.c (cpu_arch): Add avx_ifma. 93646 * doc/c-i386.texi: Document .avx_ifma. 93647 * testsuite/gas/i386/avx-ifma.d: New file. 93648 * testsuite/gas/i386/avx-ifma-intel.d: Likewise. 93649 * testsuite/gas/i386/avx-ifma.s: Likewise. 93650 * testsuite/gas/i386/x86-64-avx-ifma.d: Likewise. 93651 * testsuite/gas/i386/x86-64-avx-ifma-intel.d: Likewise. 93652 * testsuite/gas/i386/x86-64-avx-ifma.s: Likewise. 93653 * testsuite/gas/i386/i386.exp: Run AVX IFMA tests. 93654 93655 opcodes/ 93656 93657 * i386-dis.c (PREFIX_VEX_0F38B4): New. 93658 (PREFIX_VEX_0F38B5): Likewise. 93659 (VEX_W_0F38B4_P_2): Likewise. 93660 (VEX_W_0F38B5_P_2): Likewise. 93661 (prefix_table): Add PREFIX_VEX_0F38B4 and PREFIX_VEX_0F38B5. 93662 (vex_table): Add VEX_W_0F38B4_P_2 and VEX_W_0F38B5_P_2. 93663 * i386-dis-evex.h: Fold AVX512IFMA entries to AVX-IFMA. 93664 * i386-gen.c (cpu_flag_init): Clear the CpuAVX_IFMA bit in 93665 CPU_UNKNOWN_FLAGS. Add CPU_AVX_IFMA_FLGAS and 93666 CPU_ANY_AVX_IFMA_FLAGS. Add CpuAVX_IFMA to CPU_AVX2_FLAGS. 93667 (cpu_flags): Add CpuAVX_IFMA. 93668 * i386-opc.h (CpuAVX_IFMA): New. 93669 (i386_cpu_flags): Add cpuavx_ifma. 93670 * i386-opc.tbl: Add Intel AVX IFMA instructions. 93671 * i386-init.h: Regenerated. 93672 * i386-tbl.h: Likewise. 93673 936742022-11-02 GDB Administrator <gdbadmin@sourceware.org> 93675 93676 Automatic date update in version.in 93677 936782022-11-01 Andrew Burgess <aburgess@redhat.com> 93679 93680 opcodes/arm: don't pass non-string literal to printf like function 93681 The earlier commit: 93682 93683 commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf 93684 Date: Thu Jul 7 13:43:45 2022 +0100 93685 93686 opcodes/arm: add disassembler styling for arm 93687 93688 introduced two places where a register name was passed as the format 93689 string to the disassembler's fprintf_styled_func callback. This will 93690 cause a warning from some compilers, like this: 93691 93692 ../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’: 93693 ../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security] 93694 6005 | func (stream, dis_style_register, arm_regnames[gpr]); 93695 | ^~~~ 93696 93697 This commit fixes these by using "%s" as the format string. 93698 936992022-11-01 Andrew Burgess <aburgess@redhat.com> 93700 93701 opcodes/arm: silence compiler warning about uninitialized variable use 93702 The earlier commit: 93703 93704 commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf 93705 Date: Thu Jul 7 13:43:45 2022 +0100 93706 93707 opcodes/arm: add disassembler styling for arm 93708 93709 was causing a compiler warning about a possible uninitialized variable 93710 usage within opcodes/arm-dis.c. 93711 93712 The problem is in print_mve_unpredictable, and relates to the reason 93713 variable, which is set by a switch table. 93714 93715 Currently the switch table does cover every valid value, though there 93716 is no default case. The variable switched on is passed in as an 93717 argument to the print_mve_unpredictable function. 93718 93719 Looking at how print_mve_unpredictable is used, there is only one use, 93720 the second argument is the one that is used for the switch table, 93721 looking at how this argument is set, I don't believe it is possible 93722 for this argument to take an invalid value. 93723 93724 So, I think the compiler warning is a false positive. As such, my 93725 proposed solution is to initialize the reason variable to the string 93726 "??", this will silence the warning, and the "??" string should never 93727 end up being printed. 93728 937292022-11-01 Andrew Burgess <aburgess@redhat.com> 93730 93731 opcodes/arm: add disassembler styling for arm 93732 This commit adds disassembler styling for the ARM architecture. 93733 93734 The ARM disassembler is driven by several instruction tables, 93735 e.g. cde_opcodes, coprocessor_opcodes, neon_opcodes, etc 93736 93737 The type for elements in each table can vary, but they all have one 93738 thing in common, a 'const char *assembler' field. This field 93739 contains a string that describes the assembler syntax of the 93740 instruction. 93741 93742 Embedded within that assembler syntax are various escape characters, 93743 prefixed with a '%'. Here's an example of a very simple instruction 93744 from the arm_opcodes table: 93745 93746 "pld\t%a" 93747 93748 The '%a' indicates a particular type of operand, the function 93749 print_insn_arm processes the arm_opcodes table, and includes a switch 93750 statement that handles the '%a' operand, and takes care of printing 93751 the correct value for that instruction operand. 93752 93753 It is worth noting that there are many print_* functions, each 93754 function handles a single *_opcodes table, and includes its own switch 93755 statement for operand handling. As a result, every *_opcodes table 93756 uses a different mapping for the operand escape sequences. This means 93757 that '%a' might print an address for one *_opcodes table, but in a 93758 different *_opcodes table '%a' might print a register operand. 93759 93760 Notice as well that in our example above, the instruction mnemonic 93761 'pld' is embedded within the assembler string. Some instructions also 93762 include comments within the assembler string, for example, also from 93763 the arm_opcodes table: 93764 93765 "nop\t\t\t@ (mov r0, r0)" 93766 93767 here, everything after the '@' is a comment that is displayed at the 93768 end of the instruction disassembly. 93769 93770 The next complexity is that the meaning of some escape sequences is 93771 not necessarily fixed. Consider these two examples from arm_opcodes: 93772 93773 "ldrex%c\tr%12-15d, [%16-19R]" 93774 "setpan\t#%9-9d" 93775 93776 Here, the '%d' escape is used with a bitfield modifier, '%12-15d' in 93777 the first instruction, and '%9-9d' in the second instruction, but, 93778 both of these are the '%d' escape. 93779 93780 However, in the first instruction, the '%d' is used to print a 93781 register number, notice the 'r' immediately before the '%d'. In the 93782 second instruction the '%d' is used to print an immediate, notice the 93783 '#' just before the '%d'. 93784 93785 We have two problems here, first, the '%d' needs to know if it should 93786 use register style or immediate style, and secondly, the 'r' and '#' 93787 characters also need to be styled appropriately. 93788 93789 The final thing we must consider is that some escape codes result in 93790 more than just a single operand being printed, for example, the '%q' 93791 operand as used in arm_opcodes ends up calling arm_decode_shift, which 93792 can print a register name, a shift type, and a shift amount, this 93793 could end up using register, sub-mnemonic, and immediate styles, as 93794 well as the text style for things like ',' between the different 93795 parts. 93796 93797 I propose a three layer approach to adding styling: 93798 93799 (1) Basic state machine: 93800 93801 When we start printing an instruction we should maintain the idea 93802 of a 'base_style'. Every character from the assembler string will 93803 be printed using the base_style. 93804 93805 The base_style will start as mnemonic, as each instruction starts 93806 with an instruction mnemonic. When we encounter the first '\t' 93807 character, the base_style will change to text. When we encounter 93808 the first '@' the base_style will change to comment_start. 93809 93810 This simple state machine ensures that for simple instructions the 93811 basic parts, except for the operands themselves, will be printed in 93812 the correct style. 93813 93814 (2) Simple operand styling: 93815 93816 For operands that only have a single meaning, or which expand to 93817 multiple parts, all of which have a consistent meaning, then I 93818 will simply update the operand printing code to print the operand 93819 with the correct style. This will cover a large number of the 93820 operands, and is the most consistent with how styling has been 93821 added to previous architectures. 93822 93823 (3) New styling syntax in assembler strings: 93824 93825 For cases like the '%d' that I describe above, I propose adding a 93826 new extension to the assembler syntax. This extension will allow 93827 me to temporarily change the base_style. Operands like '%d', will 93828 then print using the base_style rather than using a fixed style. 93829 93830 Here are the two examples from above that use '%d', updated with 93831 the new syntax extension: 93832 93833 "ldrex%c\t%{R:r%12-15d%}, [%16-19R]" 93834 "setpan\t%{I:#%9-9d%}" 93835 93836 The syntax has the general form '%{X:....%}' where the 'X' 93837 character changes to indicate a different style. In the first 93838 instruction I use '%{R:...%}' to change base_style to the register 93839 style, and in the second '%{I:...%}' changes base_style to 93840 immediate style. 93841 93842 Notice that the 'r' and '#' characters are included within the new 93843 style group, this ensures that these characters are printed with 93844 the correct style rather than as text. 93845 93846 The function decode_base_style maps from character to style. I've 93847 included a character for each style for completeness, though only 93848 a small number of styles are currently used. 93849 93850 I have updated arm-dis.c to the above scheme, and checked all of the 93851 tests in gas/testsuite/gas/arm/, and the styling looks reasonable. 93852 93853 There are no regressions on the ARM gas/binutils/ld tests that I can 93854 see, so I don't believe I've changed the output layout at all. There 93855 were two binutils tests for which I needed to force the disassembler 93856 styling off. 93857 93858 I can't guarantee that I've not missed some untested corners of the 93859 disassembler, or that I might have just missed some incorrectly styled 93860 output when reviewing the test results, but I don't believe I've 93861 introduced any changes that could break the disassembler - the worst 93862 should be some aspect is not styled correctly. 93863 938642022-11-01 Andrew Burgess <aburgess@redhat.com> 93865 93866 opcodes/arm: use '@' consistently for the comment character 93867 Looking at the ARM disassembler output, every comment seems to start 93868 with a ';' character, so I assumed this was the correct character to 93869 start an assembler comment. 93870 93871 I then spotted a couple of places where there was no ';', but instead, 93872 just a '@' character. I thought that this was a case of a missing 93873 ';', and proposed a patch to add the missing ';' characters. 93874 93875 Turns out I was wrong, '@' is actually the ARM assembler comment 93876 character, while ';' is the statement separator. Thus this: 93877 93878 nop ;@ comment 93879 93880 is two statements, the first is the 'nop' instruction, while the 93881 second contains no instructions, just the '@ comment' comment text. 93882 93883 This: 93884 93885 nop @ comment 93886 93887 is a single 'nop' instruction followed by a comment. And finally, 93888 this: 93889 93890 nop ; comment 93891 93892 is two statements, the first contains the 'nop' instruction, while the 93893 second contains the instruction 'comment', which obviously isn't 93894 actually an instruction at all. 93895 93896 Why this matters is that, in the next commit, I would like to add 93897 libopcodes syntax styling support for ARM. 93898 93899 The question then is how should the disassembler style the three cases 93900 above? 93901 93902 As '@' is the actual comment start character then clearly the '@' and 93903 anything after it can be styled as a comment. But what about ';' in 93904 the second example? Style as text? Style as a comment? 93905 93906 And the third example is even harder, what about the 'comment' text? 93907 Style as an instruction mnemonic? Style as text? Style as a comment? 93908 93909 I think the only sensible answer is to move the disassembler to use 93910 '@' consistently as its comment character, and remove all the uses of 93911 ';'. 93912 93913 Then, in the next commit, it's obvious what to do. 93914 93915 There's obviously a *lot* of tests that get updated by this commit, 93916 the only actual code changes are in opcodes/arm-dis.c. 93917 939182022-11-01 GDB Administrator <gdbadmin@sourceware.org> 93919 93920 Automatic date update in version.in 93921 939222022-10-31 Tom Tromey <tromey@adacore.com> 93923 93924 Add missing TYPE_CODE_* constants to Python 93925 A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb 93926 Python layer. This patch fixes the bug, and prevents future 93927 occurences of this type of bug. 93928 939292022-10-31 Carl Love <cel@us.ibm.com> 93930 93931 Remove REPARSE condition to force hardware resource checking when updating watchpoints 93932 Currently the resource checking is done if REPARSE is true. The hardware 93933 watchpoint resource checking in update_watchpoint needs to be redone on 93934 each call to function update_watchpoints as the value chain may have 93935 changed. The number of hardware registers needed for a watchpoint can 93936 change if the variable being watched changes. This situation occurs in 93937 this test when watching variable **global_ptr_ptr. Initially when the 93938 watch command is issued, only two addresses need to be watched as 93939 **global_ptr_ptr has not yet been initialized. Once the value of 93940 **global_ptr_ptr is initialized the locations to be tracked increase to 93941 three addresses. However, update_watchpoints is not called again with 93942 REPARSE set to 1 to force the resource checking to be redone. When the 93943 test is run on Power 10, an internal gdb error occurs when the PowerPC 93944 routine tries to setup the three hardware watchpoint address since the hw 93945 only has two hardware watchpoint registers. The error occurs because the 93946 resource checking was not redone in update_watchpoints after 93947 **global_ptr_ptr changed. 93948 93949 The following descibes the situation in detail that occurs on Power 10 with 93950 gdb running on the binary for gdb.base/watchpoint.c. 93951 93952 1 break func4 93953 2 run 93954 3 watch *global_ptr 93955 4 next execute source code: buf[0] = 3; 93956 5 next execute source code: global_ptr = buf; 93957 6 next execute source code: buf[0] = 7; 93958 7 delete 2 (delete watch *global_ptr) 93959 8 watch **global_ptr_ptr 93960 9 next execute source code: buf[1] = 5; 93961 10 next global_ptr_ptr = &global_ptr; 93962 11 next buf[0] = 9; 93963 93964 In step 8, the the watch **global_ptr_prt command calls update_watchpoint 93965 in breakpoint.c with REPARSE set to 1. The function update_watchpoint 93966 calls can_use_hardware_watchpoint to see if there are enough 93967 resources available to add the watchpoint since REPARSE is set to 1. At 93968 this point, **global_ptr_ptr has not been initialized so only two addresses 93969 are watched. The val_chain contains the address for **global_ptr_ptr and 0 93970 since **global_ptr_ptr has not been initialized. The update_watchpoint 93971 updates the breakpoint list as follows: 93972 93973 breakpoint 0 93974 loc 0: b->address = 0x100009c0 93975 breakpoint 1 93976 loc 1: b->address = 0x7ffff7f838a0 93977 breakpoint 2 93978 loc 2: b->address = 0x7ffff7b7fc54 93979 breakpoint 3 93980 loc 3: b->address = 0x7ffff7a5788c 93981 breakpoint 4 93982 loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr 93983 loc 5: b->address = 0x100200b8 <-- global_ptr_ptr watchpoint 93984 breakpoint 5 93985 loc 6: b->address = 0x7ffff7b7fc54 93986 93987 In step 10, the next command executes the source code 93988 global_ptr_ptr = &global_ptr. This changes the set of locations to be 93989 watched for the watchpoint **global_ptr_prt. The list of addresses for the 93990 breakpoint consist of the address for global_ptr_prt, global_ptr and buf. 93991 The breakpoint list gets updated by update_watchpoint as follows: 93992 93993 breakpoint 0 93994 loc 0: b->address = 0x100009c0 93995 breakpoint 1 93996 loc 1: b->address = 0x7ffff7f838a0 93997 breakpoint 2 93998 loc 2: b->address = 0x7ffff7b7fc54 93999 breakpoint 3 94000 loc 3: b->address = 0x7ffff7a5788c 94001 breakpoint 4 94002 loc 4: b->address = 0x10020050 buf 94003 loc 5: b->address = 0x100200b0 watch *global_ptr 94004 loc 6: b->address = 0x100200b8 watch **global_ptr_ptr 94005 breakpoint 5 94006 loc 7: b->address = 0x7ffff7b7fc54 94007 breakpoint 6 94008 94009 However, the hardware resource checking was not redone because 94010 update_breakpoint was called with REPARSE equal to 0. 94011 94012 Step 11, execute the third next command. The function 94013 ppc_linux_nat_target::low_prepare_to_resume() attempts a ptrace 94014 call to setup each of the three address for breakpoint 4. The slot 94015 value returned for the third ptrace call is -1 indicating an error 94016 because there are only two hardware watchpoint registers available on 94017 Power 10. 94018 94019 This patch removes just the statement "if (reparse)" in function 94020 update_watchpoint to force the resources to be rechecked on every call to 94021 the function. This ensures that any changes to the val_chain resulting 94022 in needing more resources then available will be caught. 94023 94024 The patch has been tested on Power 8, Power 10 and X86-64. Note the patch 94025 has no effect on Power 9 since hardware watchpoint support is disabled on 94026 that processor. 94027 940282022-10-31 Carl Love <cel@us.ibm.com> 94029 94030 PowerPC, add support for recording pipe2 system call. 94031 Test gdb.reverse/pipe-reverse.exp fails on Power 10 running the fedora 36 94032 distro. The gdb record error message is: 94033 94034 Process record and replay target doesn't support syscall number 317. 94035 94036 System call 317 on PowerPC maps to the pipe2 system call. 94037 94038 This patch adds support for the missing pipe2 system call for PowerPC. 94039 94040 Patch fixes the test failure in gdb.reverse/pipe-reverse.exp. 94041 94042 The patch has been tested on Power 10 with no regression failures. 94043 940442022-10-31 Jan Beulich <jbeulich@suse.com> 94045 94046 x86: minor improvements to optimize_imm() (part III) 94047 Earlier tidying still missed an opportunity: There's no need for the 94048 "anyimm" static variable. Instead of using it in the loop to mask 94049 "allowed" (which is necessary to satisfy operand_type_or()'s assertions) 94050 simply use "mask", requiring it to be calculated first. That way the 94051 post-loop masking by "mask" ahead of the operand_type_all_zero() can be 94052 dropped. 94053 940542022-10-31 Mike Frysinger <vapier@gentoo.org> 94055 94056 sim: reg: constify store helper 94057 These functions only read from memory, so mark the pointer as const. 94058 94059 sim: constify various integer readers 94060 These functions only read from memory, so mark the pointer as const. 94061 94062 sim: cgen: constify GETT helpers 94063 These functions only read from memory, so mark the pointer as const. 94064 94065 sim: common: change sim_read & sim_write to use void* buffers 94066 When reading/writing arbitrary data to the system's memory, the unsigned 94067 char pointer type doesn't make that much sense. Switch it to void so we 94068 align a bit with standard C library read/write functions, and to avoid 94069 having to sprinkle casts everywhere. 94070 940712022-10-31 H.J. Lu <hjl.tools@gmail.com> 94072 94073 x86: Silence GCC 12 warning on tc-i386.c 94074 Silence GCC 12 warning on tc-i386.c: 94075 94076 gas/config/tc-i386.c: In function ‘md_assemble’: 94077 gas/config/tc-i386.c:5039:16: error: too many arguments for format [-Werror=format-extra-args] 94078 5039 | as_warn (_("only support RIP-relative address"), i.tm.name); 94079 94080 * config/tc-i386.c (md_assemble): Print mnemonic in RIP-relative 94081 warning. 94082 * estsuite/gas/i386/x86-64-prefetchi-warn.l: Updated. 94083 940842022-10-31 Tom Tromey <tromey@adacore.com> 94085 94086 Use enum for gdbarch's call_dummy_location 94087 This changes gdbarch to use an enum for call_dummy_location, providing 94088 a little more type safety. 94089 94090 Inline initialization of gdbarch members 94091 This changes gdbarch to use the "predefault" to initialize its members 94092 inline. This required changing a couple of the Value instantiations 94093 to avoid a use of "gdbarch" during initialization, but on the whole I 94094 think this is better -- it removes a hidden ordering dependency. 94095 940962022-10-31 Tom Tromey <tromey@adacore.com> 94097 94098 Fix regression in pointer-to-member printing 94099 PR c++/29243 points out that "info func" on a certain C++ executable 94100 will cause an infinite loop in gdb. 94101 94102 I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle 94103 member pointers directly in generic_value_print"). Before this 94104 commit, the C++ code to print a member pointer would wind up calling 94105 value_print_scalar_formatted; but afterward it simply calls 94106 generic_value_print and gets into a loop. 94107 94108 This patch restores the previous behavior and adds a regression test. 94109 941102022-10-31 Nick Clifton <nickc@redhat.com> 94111 94112 Updated Romainain translation for the binutils sub-directory and Swedish translations for the ld and opcodes sub-directories. 94113 941142022-10-31 Cui, Lili <lili.cui@intel.com> 94115 94116 Support Intel PREFETCHI 94117 gas/ChangeLog: 94118 94119 * NEWS: Add support for Intel PREFETCHI instruction. 94120 * config/tc-i386.c (load_insn_p): Use prefetch* to fold all prefetches. 94121 (md_assemble): Add warning for illegal input of PREFETCHI. 94122 * doc/c-i386.texi: Document .prefetchi. 94123 * testsuite/gas/i386/i386.exp: Run PREFETCHI tests. 94124 * testsuite/gas/i386/x86-64-lfence-load.d: Add PREFETCHI. 94125 * testsuite/gas/i386/x86-64-lfence-load.s: Likewise. 94126 * testsuite/gas/i386/x86-64-prefetch.d: New test. 94127 * testsuite/gas/i386/x86-64-prefetchi-intel.d: Likewise. 94128 * testsuite/gas/i386/x86-64-prefetchi-inval-register.d: Likewise.. 94129 * testsuite/gas/i386/x86-64-prefetchi-inval-register.s: Likewise. 94130 * testsuite/gas/i386/x86-64-prefetchi-warn.l: Likewise. 94131 * testsuite/gas/i386/x86-64-prefetchi-warn.s: Likewise. 94132 * testsuite/gas/i386/x86-64-prefetchi.d: Likewise. 94133 * testsuite/gas/i386/x86-64-prefetchi.s: Likewise. 94134 94135 opcodes/ChangeLog: 94136 94137 * i386-dis.c (reg_table): Add MOD_0F18_REG_6 and MOD_0F18_REG_7 94138 (x86_64_table): Add X86_64_0F18_REG_6_MOD_0 and X86_64_0F18_REG_7_MOD_0. 94139 (mod_table): Add MOD_0F18_REG_6 and MOD_0F18_REG_7. 94140 (prefix_table): Add PREFIX_0F18_REG_6_MOD_0_X86_64 and 94141 PREFIX_0F18_REG_7_MOD_0_X86_64. 94142 (PREFETCHI_Fixup): New. 94143 * i386-gen.c (cpu_flag_init): Add CPU_PREFETCHI_FLAGS. 94144 (cpu_flags): Add CpuPREFETCHI. 94145 * i386-opc.h (CpuPREFETCHI): New. 94146 (i386_cpu_flags): Add cpuprefetchi. 94147 * i386-opc.tbl: Add Intel PREFETCHI instructions. 94148 * i386-init.h: Regenerated. 94149 * i386-tbl.h: Likewise. 94150 941512022-10-31 Bruno Larsen <blarsen@redhat.com> 94152 94153 gdb/testsuite: fix gdb.cp/converts.exp to run with clang 94154 Clang attempts to minimize the size of the debug-info by not adding 94155 complete information about types that aren't constructed in a given 94156 file. Specifically, this meant that there was minimal information about 94157 class B in the test gdb.cp/converts.exp. To fix this, we just need to 94158 construct any object of type B in that file. 94159 94160 Approved-By: Andrew Burgess <aburgess@redhat.com> 94161 941622022-10-31 Bruno Larsen <blarsen@redhat.com> 94163 94164 gdb/testsuite: add XFAIL to gdb.cp/ptype-flags.exp when using clang 94165 When running gdb.cp/ptype-flags.exp using Clang, we get an unexpected 94166 failure when printing the type of a class with an internal typedef. This 94167 happens because Clang doesn't add accessibility information for typedefs 94168 inside classes (see https://github.com/llvm/llvm-project/issues/57608 94169 for more info). To help with Clang testing, an XFAIL was added to this 94170 test. 94171 941722022-10-31 Yoshinori Sato <ysato@users.sourceforge.jp> 94173 94174 RX assembler: switch arguments of thw MVTACGU insn. 94175 941762022-10-31 Nick Clifton <nickc@redhat.com> 94177 94178 objdump: Add configure time option to enable colored disassembly output by default. 94179 PR 29457 94180 * configure.ac: Add --enable-colored-disassembly. 94181 * objdump.c: Add --disassembler-color=terminal. 94182 * doc/binutils.texi (objdump): Document the new option. 94183 * NEWS: Mention new feature. 94184 * config.in: Regenerate in. 94185 * configure: Regenerate. 94186 941872022-10-31 Mark Harmstone <mark@harmstone.com> 94188 94189 ld: Add publics stream to PDB files 94190 94191 ld: Add section header stream to PDB files 94192 94193 ld: Use %E in einfo in pdb.c 94194 Resubmission, taking into account 94195 https://sourceware.org/pipermail/binutils/2022-October/123948.html. 94196 941972022-10-31 GDB Administrator <gdbadmin@sourceware.org> 94198 94199 Automatic date update in version.in 94200 942012022-10-30 Alan Modra <amodra@gmail.com> 94202 94203 Pool section entries for DWP version 1 94204 Ref: https://gcc.gnu.org/wiki/DebugFissionDWP?action=recall&rev=3 94205 94206 Fuzzers have found a weakness in the code stashing pool section 94207 entries. With random nonsensical values in the index entries (rather 94208 than each index pointing to its own set distinct from other sets), 94209 it's possible to overflow the space allocated, losing the NULL 94210 terminator. Without a terminator, find_section_in_set can run off the 94211 end of the shndx_pool buffer. Fix this by scanning the pool directly. 94212 94213 binutils/ 94214 * dwarf.c (add_shndx_to_cu_tu_entry): Delete range check. 94215 (end_cu_tu_entry): Likewise. 94216 (process_cu_tu_index): Fill shndx_pool by directly scanning 94217 pool, rather than indirectly from index entries. 94218 942192022-10-30 GDB Administrator <gdbadmin@sourceware.org> 94220 94221 Automatic date update in version.in 94222 942232022-10-29 Maciej W. Rozycki <macro@embecosm.com> 94224 94225 gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp 94226 Wrap an overlong line in the definition of `param_integer_error' in 94227 gdb.guile/scm-parameter.exp. No functional change. 94228 942292022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94230 94231 sim/sh: Remove redundant function declaration 94232 Clang generates a warning if there is a function declaration/definition 94233 with zero arguments. Such declarations/definitions without a prototype (an 94234 argument list) are deprecated forms of indefinite arguments 94235 ("-Wdeprecated-non-prototype"). On the default configuration, it causes a 94236 build failure (unless "--disable-werror" is specified). 94237 94238 But there is another issue. This function declaration in sim/sh/interp.c 94239 is completely redundant. This commit just removes that declaration. 94240 942412022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94242 94243 sim/m32r: Initialize "list" variable 94244 The variable "list" is only initialized when arg1 > 0 and when arg1 == 0, 94245 an uninitialized value is passed to translate_endian_h2t function. 94246 94247 Although this behavior is harmless, this commit adds initialization to avoid 94248 a GCC warning ("-Wmaybe-uninitialized"). 94249 942502022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94251 94252 sim/erc32: Use int32_t as IRQ callback argument 94253 Clang generates a warning if an argument is passed to a function without 94254 prototype (zero arguments, even without (void)). Such calls are deprecated 94255 forms of indefinite arguments passing ("-Wdeprecated-non-prototype"). 94256 On the default configuration, it (somehow) doesn't cause a build failure but 94257 a warning is generated. 94258 94259 But because the cause is the same as the issue the author fixed in 94260 "sim/erc32: Use int32_t as event callback argument", it would be better to 94261 fix it now to prevent problems in the future. 94262 94263 To fix the issue, this commit makes struct irqcall to use int32_t as a 94264 callback (callback) argument of an IRQ. 94265 942662022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94267 94268 sim/erc32: Use int32_t as event callback argument 94269 Clang generates a warning if an argument is passed to a function without 94270 prototype (zero arguments, even without (void)). Such calls are deprecated 94271 forms of indefinite arguments passing ("-Wdeprecated-non-prototype"). 94272 On the default configuration, it causes a build failure (unless 94273 "--disable-werror" is specified). 94274 94275 To fix that, this commit makes struct evcell to use int32_t as a callback 94276 (cfunc) argument of an event. int32_t is chosen because "event" function 94277 accepts "int32_t arg". 94278 942792022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94280 94281 sim/erc32: Insert void parameter 94282 Clang generates a warning if there is a function declaration/definition 94283 with zero arguments. Such declarations/definitions without a prototype (an 94284 argument list) are deprecated forms of indefinite arguments 94285 ("-Wdeprecated-non-prototype"). On the default configuration, it causes a 94286 build failure (unless "--disable-werror" is specified). 94287 94288 This commit replaces () with (void) to avoid this warning. 94289 942902022-10-29 Tom de Vries <tdevries@suse.de> 94291 94292 [gdb/testsuite] Use ssh -t in remote-*.exp 94293 When running test-case gdb.server/multi-ui-errors.exp on target board 94294 remote-gdbserver-on-localhost.exp, I run into: 94295 ... 94296 (gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver 94297 continue^M 94298 Continuing.^M 94299 PASS: gdb.server/multi-ui-errors.exp: continue - extra UI 94300 Remote debugging from host ::1, port 35466^M 94301 FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running 94302 ... 94303 94304 The problem is that the target board uses ssh -T, which fails to guarantee 94305 that output from the inferior will be available. 94306 94307 Fix this by copying proc ${board}_spawn from local-remote-host.exp, which 94308 ensures using ssh -t. [ It would be nice to define an ssh base board to 94309 get rid of the copies, but I'm not addressing that in this commit. ] 94310 94311 Likewise for target board remote-stdio-gdbserver.exp. 94312 94313 Tested on x86_64-linux. 94314 943152022-10-29 Tom de Vries <tdevries@suse.de> 94316 94317 [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp with local-remote-host-notty 94318 With test-case gdb.server/multi-ui-errors.exp and host board 94319 local-remote-host-notty, I run into: 94320 ... 94321 (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI 94322 Executing on target: kill -9 29666 (timeout = 300) 94323 builtin_spawn -ignore SIGHUP kill -9 29666^M 94324 echo^M 94325 Remote connection closed^M 94326 (gdb) (gdb) FAIL: gdb.server/multi-ui-errors.exp: \ 94327 main UI, prompt after gdbserver dies (timeout) 94328 ... 94329 94330 In contrast, with local-remote-host (so, everything the same but editing off): 94331 ... 94332 (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI 94333 Executing on target: kill -9 31245 (timeout = 300) 94334 builtin_spawn -ignore SIGHUP kill -9 31245^M 94335 Remote connection closed^M 94336 (gdb) echo^M 94337 (gdb) PASS: gdb.server/multi-ui-errors.exp: main UI, prompt after gdbserver dies 94338 ... 94339 94340 The test-case issues a kill, which results in a "Remote connection closed" 94341 message and a prompt. 94342 94343 The problem is that the prompt is not consumed, so the subsequent echo may be 94344 issued before that prompt, which causes a mismatch when matching the result 94345 of the echo. 94346 94347 Fix this by consuming the "Remote connection closed" message and prompt. 94348 94349 Tested on x86_64-linux. 94350 943512022-10-29 Tom de Vries <tdevries@suse.de> 94352 94353 [gdb/testsuite] Consume output asap in gdb.server/multi-ui-errors.exp 94354 With test-case gdb.server/multi-ui-errors.exp we see: 94355 ... 94356 (gdb) PASS: multi-ui-errors.exp: main UI, prompt after gdbserver dies 94357 continue^M 94358 Continuing.^M 94359 echo^M 94360 (gdb) PASS: multi-ui-errors.exp: extra UI, prompt after gdbserver dies 94361 ... 94362 94363 The continue is issued earlier in the test-case, but the output has not been 94364 consumed, which makes it show up much later. 94365 94366 Consume the continue output asap, to make it clear when the continue is issued: 94367 ... 94368 (gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver 94369 continue^M 94370 Continuing.^M 94371 PASS: gdb.server/multi-ui-errors.exp: continue - extra UI 94372 ... 94373 94374 Tested on x86_64-linux. 94375 943762022-10-29 Tom de Vries <tdevries@suse.de> 94377 94378 [gdb/testsuite] Remove REMOTE_PORTNUM in remote-stdio-gdbserver.exp 94379 The usage for board remote-stdio-gdbserver.exp is advertised as: 94380 ... 94381 # bash$ make check RUNTESTFLAGS="--target_board=remote-stdio-gdbserver \ 94382 # REMOTE_USERNAME=... REMOTE_HOSTNAME=... REMOTE_PORTNUM=... \ 94383 # [REMOTE_TMPDIR=${remote_dir}] [GDBSERVER=${remote_gdbserver}]" 94384 ... 94385 but when adding REMOTE_PORTNUM=22, I run into: 94386 ... 94387 Running stop-reply-no-thread-multi.exp ... 94388 ERROR: tcl error sourcing stop-reply-no-thread-multi.exp. 94389 ERROR: couldn't execute "/usr/bin/ssh -p22": no such file or directory 94390 while executing 94391 "builtin_spawn {/usr/bin/ssh -p22} -l vries localhost {/usr/bin/gdbserver \ 94392 --once localhost:2346 \ 94393 /home/vries/gdb_versions/devel/build/gdb/testsuite/outp..." 94394 ... 94395 94396 Fix this by simply removing REMOTE_PORTNUM. 94397 94398 Tested on x86_64-linux. 94399 944002022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com> 94401 94402 sim, sim/{m32c,ppc,rl78}: Use getopt_long 94403 Because of a Libiberty hack, getopt on GNU libc (2.25 or earlier) is 94404 currently unusable on sim, causing a regression on CentOS 7. 94405 94406 This is caused as follows: 94407 94408 1. If HAVE_DECL_GETOPT is defined (getopt declaration with known prototype 94409 is detected while configuration), a declaration of getopt in 94410 "include/getopt.h" is suppressed. 94411 The author started to define HAVE_DECL_GETOPT in sim with the commit 94412 340aa4f6872c ("sim: Check known getopt definition existence"). 94413 2. GNU libc (2.25 or earlier)'s <unistd.h> includes <getopt.h> with a 94414 special purpose macro defined to declare only getopt function but due 94415 to include path (not tested while configuration), it causes <unistd.h> 94416 to include Libiberty's "include/getopt.h". 94417 3. If both 1. and 2. are satisfied, despite that <unistd.h> tries to 94418 declare getopt by including <getopt.h>, "include/getopt.h" does not do 94419 so, causing getopt function undeclared. 94420 94421 Getting rid of "include/getopt.h" (e.g. renaming this header file) is the 94422 best solution to avoid hacking but as a short-term solution, this commit 94423 replaces getopt with getopt_long under sim/. 94424 944252022-10-29 Alan Modra <amodra@gmail.com> 94426 94427 pef: sanity check before malloc 94428 And do the sanity check in a way that can't overflow. 94429 94430 * pef.c (bfd_pef_parse_function_stubs): Sanity check header 94431 imported_library_count and total_imported_symbol_count before 94432 allocating memory. 94433 944342022-10-29 Alan Modra <amodra@gmail.com> 94435 94436 Fix small objcopy memory leak 94437 * objcopy.c (copy_archive): Free l->name. 94438 944392022-10-29 Alan Modra <amodra@gmail.com> 94440 94441 NULL dereference read in som_write_object_contents 94442 objcopy copy_object may omit the call to bfd_copy_private_bfd_data for 94443 various conditions deemed non-fatal, in which case obj_som_exec_data 94444 will be NULL for the output file. 94445 94446 * som.c (som_finish_writing): Don't dereference NULL 94447 obj_som_exec_data. 94448 944492022-10-29 Nelson Chu <nelson@rivosinc.com> 94450 94451 RISC-V: Always generate mapping symbols at the start of the sections. 94452 Before figuring out the suppress rule of mapping symbol with architecture 94453 (changed back to $x), always generate them at the start of the sections. 94454 94455 gas/ 94456 * config/tc-riscv.c (need_arch_map_symbol): Removed. 94457 (riscv_mapping_state): Updated. 94458 (riscv_check_mapping_symbols): Updated. 94459 * testsuite/gas/riscv/mapping-non-arch.d: Removed. 94460 * testsuite/gas/riscv/mapping-non-arch.s: Likewise. 94461 944622022-10-29 GDB Administrator <gdbadmin@sourceware.org> 94463 94464 Automatic date update in version.in 94465 944662022-10-28 Palmer Dabbelt <palmer@rivosinc.com> 94467 94468 gas: NEWS: Note support for RISC-V Zawrs 94469 This has been supported since eb668e50036 ("RISC-V: Add Zawrs ISA 94470 extension support"). 94471 94472 gas: NEWS: Add a missing newline 94473 944742022-10-28 Tom Tromey <tom@tromey.com> 94475 94476 Convert compunit_language to a method 94477 This changes compunit_language to be a method on compunit_symtab. 94478 94479 Approved-By: Simon Marchi <simon.marchi@efficios.com> 94480 944812022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com> 94482 94483 RISC-V: Improve "bits undefined" diagnostics 94484 This commit improves internal error message 94485 "internal: bad RISC-V opcode (bits 0x%lx undefined): %s %s" 94486 to display actual unused bits (excluding non-instruction bits). 94487 94488 gas/ChangeLog: 94489 94490 * config/tc-riscv.c (validate_riscv_insn): Exclude non- 94491 instruction bits from displaying internal diagnostics. 94492 Change error message slightly. 94493 944942022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com> 94495 94496 RISC-V: Fallback for instructions longer than 64b 94497 We don't support instructions longer than 64-bits yet. Still, we can 94498 modify validate_riscv_insn function to prevent unexpected behavior by 94499 limiting the "length" of an instruction to 64-bit (or less). 94500 94501 gas/ChangeLog: 94502 94503 * config/tc-riscv.c (validate_riscv_insn): Fix function 94504 description comment based on current spec. Limit instruction 94505 length up to 64-bit for now. Make sure that required_bits does 94506 not corrupt even if unsigned long long is longer than 64-bit. 94507 945082022-10-28 Jan Beulich <jbeulich@suse.com> 94509 94510 RISC-V/gas: fix build with certain gcc versions 94511 Some versions of gcc warn by default about shadowed outer-scope 94512 declarations. This affects frag_align_code, which is declared in 94513 frags.h. Rename the offending function parameter. While there also 94514 switch to using true/false at the function call sites. 94515 945162022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com> 94517 94518 RISC-V: Fix build failure for -Werror=maybe-uninitialized 94519 Commit 40f1a1a4564b ("RISC-V: Output mapping symbols with ISA string.") 94520 caused a build failure on GCC 12 as follows: 94521 94522 make[3]: Entering directory '$(builddir)/gas' 94523 CC config/tc-riscv.o 94524 In file included from $(srcdir)/gas/config/tc-riscv.c:23: 94525 $(srcdir)/gas/as.h: In function ‘make_mapping_symbol’: 94526 $(srcdir)/gas/as.h:123:15: error: ‘buff’ may be used uninitialized [-Werror=maybe-uninitialized] 94527 123 | #define xfree free 94528 | ^~~~ 94529 $(srcdir)/gas/config/tc-riscv.c:487:9: note: ‘buff’ was declared here 94530 487 | char *buff; 94531 | ^~~~ 94532 cc1: all warnings being treated as errors 94533 make[3]: *** [Makefile:1425: config/tc-riscv.o] Error 1 94534 94535 This is caused by a false positive of "maybe uninitialized" variable 94536 detection (-Wmaybe-uninitialized). To avoid this error, this commit 94537 initializes the local variable buff to NULL first in all cases. 94538 94539 gas/ChangeLog: 94540 94541 * config/tc-riscv.c (make_mapping_symbol): Initialize variable 94542 buff with NULL to avoid build failure caused by a GCC's false 94543 positive of maybe uninitialized variable detection. 94544 945452022-10-28 Markus Metzger <markus.t.metzger@intel.com> 94546 94547 gdb, btrace: fix family and model computation 94548 In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu 94549 structure given to the libipt btrace decoder. 94550 94551 We only consider the extended model field for family 0x6 and forget about 94552 family 0xf and we don't consider the extended family field. Fix it. 94553 945542022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com> 94555 94556 include: Define macro to ignore -Wdeprecated-declarations on GCC 94557 "-Wdeprecated-declarations" warning option can be helpful to track 94558 deprecated function delarations but sometimes we need to disable this 94559 warning for a good reason. 94560 94561 DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS is an existing macro but only 94562 defined on Clang. Since "-Wdeprecated-declarations" is also available on 94563 GCC (>= 3.4.0), this commit adds equivalent definition as Clang. 94564 94565 __GNUC__ and __GNUC_MINOR__ are not checked because this header file seems 94566 to assume GCC >= 4.6 (with "GCC diagnostic push/pop"). 94567 94568 include/ChangeLog: 94569 94570 * diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS): 94571 Define also on GCC. 94572 945732022-10-28 Nelson Chu <nelson@rivosinc.com> 94574 94575 RISC-V: Output mapping symbols with ISA string. 94576 RISC-V Psabi pr196, 94577 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/196 94578 94579 bfd/ 94580 * elfxx-riscv.c (riscv_release_subset_list): Free arch_str if needed. 94581 (riscv_copy_subset_list): Copy arch_str as well. 94582 * elfxx-riscv.h (riscv_subset_list_t): Store arch_str for each subset list. 94583 gas/ 94584 * config/tc-riscv.c (riscv_reset_subsets_list_arch_str): Update the 94585 architecture string in the subset_list. 94586 (riscv_set_arch): Call riscv_reset_subsets_list_arch_str after parsing new 94587 architecture string. 94588 (s_riscv_option): Likewise. 94589 (need_arch_map_symbol): New boolean, used to indicate if .option 94590 directives do affect instructions. 94591 (make_mapping_symbol): New boolean parameter reset_seg_arch_str. Need to 94592 generate $x+arch for MAP_INSN, and then store it into tc_segment_info_data 94593 if reset_seg_arch_str is true. 94594 (riscv_mapping_state): Decide if we need to add $x+arch for MAP_INSN. For 94595 now, only add $x+arch if the architecture strings in subset list and segment 94596 are different. Besides, always add $x+arch at the start of section, and do 94597 not add $x+arch for code alignment, since rvc for alignment can be judged 94598 from addend of R_RISCV_ALIGN. 94599 (riscv_remove_mapping_symbol): If current and previous mapping symbol have 94600 same value, then remove the current $x only if the previous is $x+arch; 94601 Otherwise, always remove previous. 94602 (riscv_add_odd_padding_symbol): Updated. 94603 (riscv_check_mapping_symbols): Don't need to add any $x+arch if 94604 need_arch_map_symbol is false, so changed them to $x. 94605 (riscv_frag_align_code): Updated since riscv_mapping_state is changed. 94606 (riscv_init_frag): Likewise. 94607 (s_riscv_insn): Likewise. 94608 (riscv_elf_final_processing): Call riscv_release_subset_list to release 94609 subset_list of riscv_rps_as, rather than only release arch_str in the 94610 riscv_write_out_attrs. 94611 (riscv_write_out_attrs): No need to call riscv_arch_str, just get arch_str 94612 from subset_list of riscv_rps_as. 94613 * config/tc-riscv.h (riscv_segment_info_type): Record current $x+arch mapping 94614 symbol of each segment. 94615 * testsuite/gas/riscv/mapping-0*: Merged and replaced by mapping.s. 94616 * testsuite/gas/riscv/mapping.s: New testcase, to test most of the cases in 94617 one file. 94618 * testsuite/gas/riscv/mapping-symbols.d: Likewise. 94619 * testsuite/gas/riscv/mapping-dis.d: Likewise. 94620 * testsuite/gas/riscv/mapping-non-arch.s: New testcase for the case that 94621 does need any $x+arch. 94622 * testsuite/gas/riscv/mapping-non-arch.d: Likewise. 94623 * testsuite/gas/riscv/option-arch-01a.d: Updated. 94624 opcodes/ 94625 * riscv-dis.c (riscv_disassemble_insn): Set riscv_fpr_names back to 94626 riscv_fpr_names_abi or riscv_fpr_names_numeric when zfinx is disabled 94627 for some specfic code region. 94628 (riscv_get_map_state): Recognized mapping symbols $x+arch, and then reset 94629 the architecture string once the ISA is different. 94630 946312022-10-28 Lifang Xia <lifang_xia@linux.alibaba.com> 94632 94633 binutils: Update my e-mail and Yunhai's e-mail 94634 binutils/ 94635 * MAINTAINERS(C-SKY): update e-mails of Lifang & Yunhai. 94636 946372022-10-28 Peter Bergner <bergner@linux.ibm.com> 94638 94639 PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions 94640 gas/ 94641 * config/tc-ppc.c (md_assemble): Only check for prefix opcodes. 94642 * testsuite/gas/ppc/rfc02658.s: New test. 94643 * testsuite/gas/ppc/rfc02658.d: Likewise. 94644 * testsuite/gas/ppc/ppc.exp: Run it. 94645 94646 opcodes/ 94647 * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New. 94648 (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp, 94649 dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2, 94650 dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn, 94651 dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4, 94652 pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np, 94653 pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn, 94654 pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn. 94655 946562022-10-28 Peter Bergner <bergner@linux.ibm.com> 94657 94658 PowerPC: Add support for RFC02653 - Dense Math Facility 94659 gas/ 94660 * config/tc-ppc.c (pre_defined_registers): Add dense math registers. 94661 (md_assemble): Check dmr specified in correct operand. 94662 * testsuite/gas/ppc/outerprod.s <dmsetaccz, dmxvbf16ger2, 94663 dmxvbf16ger2nn, dmxvbf16ger2np, dmxvbf16ger2pn, dmxvbf16ger2pp, 94664 dmxvf16ger2, dmxvf16ger2nn, dmxvf16ger2np, dmxvf16ger2pn, dmxvf16ger2pp, 94665 dmxvf32ger, dmxvf32gernn, dmxvf32gernp, dmxvf32gerpn, dmxvf32gerpp, 94666 dmxvf64ger, dmxvf64gernn, dmxvf64gernp, dmxvf64gerpn, dmxvf64gerpp, 94667 dmxvi16ger2, dmxvi16ger2pp, dmxvi16ger2s, dmxvi16ger2spp, dmxvi4ger8, 94668 dmxvi4ger8pp, dmxvi8ger4, dmxvi8ger4pp, dmxvi8ger4spp, dmxxmfacc, 94669 dmxxmtacc, pmdmxvbf16ger2, pmdmxvbf16ger2nn, pmdmxvbf16ger2np, 94670 pmdmxvbf16ger2pn, pmdmxvbf16ger2pp, pmdmxvf16ger2, pmdmxvf16ger2nn, 94671 pmdmxvf16ger2np, pmdmxvf16ger2pn, pmdmxvf16ger2pp, pmdmxvf32ger, 94672 pmdmxvf32gernn, pmdmxvf32gernp, pmdmxvf32gerpn, pmdmxvf32gerpp, 94673 pmdmxvf64ger, pmdmxvf64gernn, pmdmxvf64gernp, pmdmxvf64gerpn, 94674 pmdmxvf64gerpp, pmdmxvi16ger2, pmdmxvi16ger2pp, pmdmxvi16ger2s, 94675 pmdmxvi16ger2spp, pmdmxvi4ger8, pmdmxvi4ger8pp, pmdmxvi8ger4, 94676 pmdmxvi8ger4pp, pmdmxvi8ger4spp>: Add new tests. 94677 * testsuite/gas/ppc/outerprod.d: Likewise. 94678 * testsuite/gas/ppc/rfc02653.s: New test. 94679 * testsuite/gas/ppc/rfc02653.d: Likewise. 94680 * testsuite/gas/ppc/ppc.exp: Run it. 94681 94682 include/ 94683 * opcode/ppc.h (PPC_OPERAND_DMR): Define. Renumber following 94684 PPC_OPERAND defines. 94685 94686 opcodes/ 94687 * ppc-dis.c (print_insn_powerpc): Prepend 'dm' when printing DMR regs. 94688 * ppc-opc.c (insert_p2, (extract_p2, (insert_xa5, (extract_xa5, 94689 insert_xb5, (extract_xb5): New functions. 94690 (insert_xa6a, extract_xa6a, insert_xb6a, extract_xb6a): Disallow 94691 operand overlap only on Power10. 94692 (DMR, DMRAB, P1, P2, XA5p, XB5p, XDMR_MASK, XDMRDMR_MASK, XX2ACC_MASK, 94693 XX2DMR_MASK, XX3DMR_MASK): New defines. 94694 (powerpc_opcodes): Add dmmr, dmsetaccz, dmsetdmrz, dmxor, dmxvbf16ger2, 94695 dmxvbf16ger2nn, dmxvbf16ger2np, dmxvbf16ger2pn, dmxvbf16ger2pp, 94696 dmxvf16ger2, dmxvf16ger2nn, dmxvf16ger2np, dmxvf16ger2pn, dmxvf16ger2pp, 94697 dmxvf32ger, dmxvf32gernn, dmxvf32gernp, dmxvf32gerpn, dmxvf32gerpp, 94698 dmxvf64ger, dmxvf64gernn, dmxvf64gernp, dmxvf64gerpn, dmxvf64gerpp, 94699 dmxvi16ger2, dmxvi16ger2pp, dmxvi16ger2s, dmxvi16ger2spp, dmxvi4ger8, 94700 dmxvi4ger8pp, dmxvi8ger4, dmxvi8ger4pp, dmxvi8ger4spp, dmxxextfdmr256, 94701 dmxxextfdmr512, dmxxinstdmr256, dmxxinstdmr512, dmxxmfacc, dmxxmtacc, 94702 pmdmxvbf16ger2, pmdmxvbf16ger2nn, pmdmxvbf16ger2np, pmdmxvbf16ger2pn, 94703 pmdmxvbf16ger2pp, pmdmxvf16ger2, pmdmxvf16ger2nn, pmdmxvf16ger2np, 94704 pmdmxvf16ger2pn, pmdmxvf16ger2pp, pmdmxvf32ger, pmdmxvf32gernn, 94705 pmdmxvf32gernp, pmdmxvf32gerpn, pmdmxvf32gerpp, pmdmxvf64ger, 94706 pmdmxvf64gernn, pmdmxvf64gernp, pmdmxvf64gerpn, pmdmxvf64gerpp, 94707 pmdmxvi16ger2, pmdmxvi16ger2pp, pmdmxvi16ger2s, pmdmxvi16ger2spp, 94708 pmdmxvi4ger8, pmdmxvi4ger8pp, pmdmxvi8ger4, pmdmxvi8ger4pp, 94709 pmdmxvi8ger4spp. 94710 947112022-10-28 GDB Administrator <gdbadmin@sourceware.org> 94712 94713 Automatic date update in version.in 94714 947152022-10-27 Andrew Burgess <aburgess@redhat.com> 94716 94717 sim/cgen: initialize variable at creation in engine_run_n 94718 Zero initialize engine_fns entirely at creation, then override those 94719 fields we intend to use, rather than zero just initializing the unused 94720 fields later on. 94721 94722 There should be no user visible changes after this commit. 94723 947242022-10-27 Tom de Vries <tdevries@suse.de> 94725 94726 [gdb/testsuite] Remove address from test names 94727 I noticed an address in a test name: 94728 ... 94729 PASS: gdb.base/eh_return.exp: gdb_breakpoint: \ 94730 set breakpoint at *0x000000000040071b 94731 ... 94732 94733 Stabilize the test name by using "set breakpoint on address" instead. 94734 94735 Likewise in two other test-cases. 94736 94737 Tested on x86_64-linux. 94738 947392022-10-27 Tom de Vries <tdevries@suse.de> 94740 94741 [gdb/testsuite] Disable styling in host board local-remote-host-native.exp 94742 Propagate fix from commit 17c68d98f74 ("[gdb/testsuite] Disable styling in host 94743 board local-remote-host.exp") to local-remote-host-native.exp. 94744 94745 Tested on x86_64-linux. 94746 947472022-10-27 Tom de Vries <tdevries@suse.de> 94748 94749 [gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host 94750 I noticed that running test-case gdb.mi/mi-exec-run.exp with host board 94751 local-remote-host.exp takes about 44 seconds. 94752 94753 I found two silent timeouts responsible for this. 94754 94755 The first is in mi_gdb_exit, where we have: 94756 ... 94757 if { [is_remote host] && [board_info host exists fileid] } { 94758 send_gdb "999-gdb-exit\n" 94759 gdb_expect 10 { 94760 -re "y or n" { 94761 send_gdb "y\n" 94762 exp_continue 94763 } 94764 -re "Undefined command.*$gdb_prompt $" { 94765 send_gdb "quit\n" 94766 exp_continue 94767 } 94768 -re "DOSEXIT code" { } 94769 } 94770 } 94771 ... 94772 so in gdb.log we see: 94773 ... 94774 999-gdb-exit^M 94775 999^exit^M 94776 =thread-exited,id="1",group-id="i1"^M 94777 =thread-group-exited,id="i1"^M 94778 ... 94779 after which expect just waits for the timeout. 94780 94781 Fix this by adding a gdb_expect clause to parse the exit: 94782 ... 94783 -re "\r\n999\\^exit\r\n" { } 94784 ... 94785 94786 Note that we're not parsing the thread-exited/thread-group-exited messages, because 94787 they may not be present: 94788 ... 94789 $ gdb -i=mi 94790 =thread-group-added,id="i1" 94791 (gdb) 94792 999-gdb-exit 94793 999^exit 94794 $ 94795 ... 94796 94797 After fixing that, we have: 94798 ... 94799 (gdb) ^M 94800 saw mi error 94801 PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \ 94802 force-fail=1: run failure detected 94803 quit^M 94804 &"quit\n"^M 94805 ... 94806 94807 What seems to be happening is that default_gdb_exit sends a cli interpreter 94808 quit command to an mi interpreter, after which again expect just waits for the 94809 timeout. 94810 94811 Fix this by adding mi_gdb_exit to the end of the test-case, as in many other 94812 gdb.mi/*.exp test-cases. 94813 94814 After these two fixes, the test-case takes about 4 seconds. 94815 94816 Tested on x86_64-linux. 94817 948182022-10-27 Tom de Vries <tdevries@suse.de> 94819 94820 [gdb/testsuite] Use remote_exec chmod instead of remote_spawn 94821 I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into: 94822 ... 94823 (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \ 94824 action=delete: setup: adjust sysroot 94825 builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M 94826 /bin/bash: connect-with-no-symbol-file: Permission denied^M 94827 /bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \ 94828 Permission denied^M 94829 During startup program exited with code 126.^M 94830 Exiting^M 94831 target remote localhost:2385^M 94832 `connect-with-no-symbol-file' has disappeared; keeping its symbols.^M 94833 localhost:2385: Connection timed out.^M 94834 (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \ 94835 action=delete: connection to GDBserver succeeded 94836 ... 94837 94838 The expected series of events is (skipping disconnect and detach as I don't 94839 think they're relevant to the problem): 94840 - enter scenario "permission" 94841 - cp $exec.bak $exec 94842 - gdbserver start with $exec 94843 - chmod 000 $exec 94844 - connect to gdbserver 94845 - enter scenario "delete" 94846 - cp $exec.bak $exec 94847 - gdbserver start with $exec 94848 - delete $exec 94849 - connect to gdbserver 94850 94851 The problem is that the chmod is executed using remote_spawn: 94852 ... 94853 } elseif { $action == "permission" } { 94854 remote_spawn target "chmod 000 $target_exec" 94855 } 94856 ... 94857 without waiting on the resulting spawn id, so we're not sure when the 94858 chmod will have effect. 94859 94860 The FAIL we're seeing above is explained by the chmod having effect during the 94861 delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver 94862 start with $exec". 94863 94864 Fix this by using remote_exec instead. 94865 94866 Likewise, fix a similar case in gdb.mi/mi-exec-run.exp. 94867 94868 Tested on x86_64-linux. 94869 94870 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29726 94871 948722022-10-27 Nelson Chu <nelson@rivosinc.com> 94873 94874 RISC-V: Fix build failures for -Werror=sign-compare. 94875 elfnn-riscv.c: In function ‘riscv_relax_resolve_delete_relocs’: 94876 elfnn-riscv.c:4256:30: error: operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand [-Werror=sign-compare] 94877 94878 So make the operands unsigned could resolve problem. 94879 94880 bfd/ 94881 * elfnn-riscv.c (riscv_relax_resolve_delete_relocs): Fixed build 94882 failures for -Werror=sign-compare. 94883 948842022-10-27 Alan Modra <amodra@gmail.com> 94885 94886 Fuzzed files in archives 94887 Given a fuzzed object file in an archive with section size exceeding 94888 file size, objcopy will report an error like "section size (0xfeffffff 94889 bytes) is larger than file size (0x17a bytes)" but will create a copy 94890 of the object laid out for the large section. That means a large 94891 temporary file on disk that is read back and written to the output 94892 archive, which can take a while. The output archive is then deleted 94893 due to the error. Avoid some of this silliness. 94894 94895 * objcopy.c (copy_section): If section contents cannot be read 94896 set output section size to zero. 94897 948982022-10-27 Martin Liska <mliska@suse.cz> 94899 94900 tests: use canonical option name 94901 ld/ChangeLog: 94902 94903 * testsuite/ld-size/size.exp: Use canonical option name. 94904 949052022-10-27 Alan Modra <amodra@gmail.com> 94906 94907 re: Support Intel AMX-FP16 94908 Fix these fails due to the target padding out sections with nops. 94909 x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns 94910 x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns (Intel disassembly) 94911 94912 * testsuite/gas/i386/x86-64-amx-fp16-intel.d: Accept trailing nops. 94913 * testsuite/gas/i386/x86-64-amx-fp16.d: Likewise. 94914 949152022-10-27 Alan Modra <amodra@gmail.com> 94916 94917 Re: ld/testsuite: adjust ld-arm to run shared tests only when supported 94918 commit 67527cffcd enabled previously disabled tests unresolved-1-dyn, 94919 thumb-plt and thumb-plt-got for nacl. The first fails due to trying 94920 to link against mixed-lib.so which isn't compiled for nacl. The last 94921 two fail with 94922 objdump: tmpdir/dump(.rel.plt): relocation 0 has invalid symbol index 14885104 94923 and 94924 readelf: Error: bad symbol index: 00e320f0 in reloc 94925 94926 Relocation section '.rel.plt' at offset 0x128 contains 1 entry: 94927 Offset Info Type Sym. Value Symbol's Name 94928 e320f000 e320f000 R_ARM_NONE 94929 94930 * testsuite/ld-arm/arm-elf.exp: Disable unresolved-1-dyn, 94931 thumb-plt and thumb-plt-got for nacl. 94932 949332022-10-27 GDB Administrator <gdbadmin@sourceware.org> 94934 94935 Automatic date update in version.in 94936 949372022-10-26 Simon Marchi <simon.marchi@efficios.com> 94938 94939 gdb/testsuite: fix gdb.guile/scm-parameter.exp "wrong type argument" test pattern for Guile >= 2.2 94940 Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value 94941 is boolean"), I see: 94942 94943 FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited) 94944 FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited) 94945 94946 This comes from the fact that GDB outputs this: 94947 94948 ERROR: In procedure set-parameter-value!: 94949 In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited 94950 Error while executing Scheme code. 94951 94952 while the test expects an additional "ERROR:" on the second line, 94953 something like this: 94954 94955 ERROR: In procedure set-parameter-value!: 94956 ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited 94957 Error while executing Scheme code. 94958 94959 Guile 2.0 outputs the `ERROR:` on the second line, while later versions 94960 do not. Change the pattern to accept both outputs. This is similar to 94961 commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp 94962 with guile 3.0"). 94963 94964 Change-Id: I9dc45e7492a4f08340cad974610242ed689de959 94965 949662022-10-26 Luis Machado <luis.machado@arm.com> 94967 94968 gdb/arm: Fix M-profile EXC_RETURN 94969 Arm v8-M Architecture Reference Manual, 94970 D1.2.95 EXC_RETURN, Exception Return Payload 94971 describes ES bit: 94972 94973 "ES, bit [0] 94974 Exception Secure. The security domain the exception was taken to. 94975 The possible values of this bit are: 94976 0 Non-secure. 94977 1 Secure" 94978 94979 arm-tdep.c:3443, arm_m_exception_cache () function tests this bit: 94980 94981 exception_domain_is_secure = (bit (lr, 0) == 0); 94982 94983 The test is negated! 94984 94985 Later on line 3553, the condition evaluates if an additional state 94986 context is stacked: 94987 94988 /* With the Security extension, the hardware saves R4..R11 too. */ 94989 if (tdep->have_sec_ext && secure_stack_used 94990 && (!default_callee_register_stacking || exception_domain_is_secure)) 94991 94992 RM, B3.19 Exception entry, context stacking 94993 reads: 94994 RPLHM "In a PE with the Security Extension, on taking an exception, 94995 the PE hardware: 94996 ... 94997 2. If exception entry requires a transition from Secure state to 94998 Non-secure state, the PE hardware extends the stack frame and also 94999 saves additional state context." 95000 95001 So we should test for !exception_domain_is_secure instead of non-negated 95002 value! 95003 These two bugs compensate each other so unstacking works correctly. 95004 95005 But another test of exception_domain_is_secure (negated due to the 95006 first bug) prevents arm_unwind_secure_frames to work as expected: 95007 95008 /* Unwinding from non-secure to secure can trip security 95009 measures. In order to avoid the debugger being 95010 intrusive, rely on the user to configure the requested 95011 mode. */ 95012 if (secure_stack_used && !exception_domain_is_secure 95013 && !arm_unwind_secure_frames) 95014 95015 Test with GNU gdb (GDB) 13.0.50.20221016-git. 95016 Stopped in a non-secure handler: 95017 95018 (gdb) set arm unwind-secure-frames 0 95019 (gdb) bt 95020 #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490 95021 #1 0x0804081c in SysTick_Handler () 95022 at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134 95023 #2 <signal handler called> 95024 #3 HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192) 95025 at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386 95026 #4 0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86 95027 #5 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278 95028 Backtrace stopped: previous frame inner to this frame (corrupt stack?) 95029 95030 The frames #3 and #4 are secure. backtrace should stop before #3. 95031 95032 Stopped in a secure handler: 95033 95034 (gdb) bt 95035 #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425 95036 #1 0x0c000b6a in SysTick_Handler () 95037 at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234 95038 warning: Non-secure to secure stack unwinding disabled. 95039 #2 <signal handler called> 95040 95041 The exception from secure to secure erroneously stops unwinding. It should 95042 continue as far as the security unlimited backtrace: 95043 95044 (gdb) set arm unwind-secure-frames 1 95045 (gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames 95046 0x0c0008e6 425 if (SecureTimingDelay != 0U) 95047 (gdb) bt 95048 #0 0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425 95049 #1 0x0c000b6a in SysTick_Handler () 95050 at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234 95051 #2 <signal handler called> 95052 #3 0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88 95053 #4 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278 95054 95055 Backtrace stopped: previous frame inner to this frame (corrupt stack?) 95056 95057 Set exception_domain_is_secure to the value expected by its name. 95058 Fix exception_domain_is_secure usage in the additional state context 95059 stacking condition. 95060 950612022-10-26 Luis Machado <luis.machado@arm.com> 95062 95063 gdb/arm: fix IPSR field test in arm_m_exception_cache () 95064 Arm v8-M Architecture Reference Manual, 95065 D1.2.141 IPSR, Interrupt Program Status Register reads 95066 "Exception, bits [8:0]" 95067 95068 9 bits, not 8! It is uncommon but true! 95069 950702022-10-26 Luis Machado <luis.machado@arm.com> 95071 95072 gdb/arm: Terminate frame unwinding in M-profile lockup 95073 In the lockup state the PC value of the the outer frame is irreversibly 95074 lost. The other registers are intact so LR likely contains 95075 PC of some frame next to the outer one, but we cannot analyze 95076 the nearest outer frame without knowing its PC 95077 therefore we do not know SP fixup for this frame. 95078 95079 The frame unwinder possibly gets mad due to the wrong SP value. 95080 To prevent problems terminate unwinding if PC contains the magic 95081 value of the lockup state. 95082 95083 Example session wihtout this change, 95084 Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git: 95085 ---------------- 95086 (gdb) c 95087 Continuing. 95088 95089 Program received signal SIGINT, Interrupt. 95090 0xeffffffe in ?? () 95091 (gdb) bt 95092 #0 0xeffffffe in ?? () 95093 #1 0x0c000a9c in HardFault_Handler () 95094 at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99 95095 #2 0x2002ffd8 in ?? () 95096 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 95097 (gdb) 95098 ---------------- 95099 The frame #1 is at correct PC taken from LR, #2 is a total nonsense. 95100 95101 With the change: 95102 ---------------- 95103 (gdb) c 95104 Continuing. 95105 95106 Program received signal SIGINT, Interrupt. 95107 warning: ARM M in lockup state, stack unwinding terminated. 95108 <signal handler called> 95109 (gdb) bt 95110 #0 <signal handler called> 95111 (gdb) 95112 ---------------- 95113 95114 There is a visible drawback of emitting a warning in a cache buildnig routine 95115 as introduced in Torbjörn SVENSSON's 95116 [PATCH v4] gdb/arm: Stop unwinding on error, but do not assert 95117 The warning is printed just once and not repeated on each backtrace command. 95118 951192022-10-26 Mike Frysinger <vapier@gentoo.org> 95120 95121 gdb: copyright: make file header scan a bit more pythonic 95122 Should be functionally the same, but uses more pythonic idioms to get 95123 fewer lines of code, and to make sure to not leak open file handles. 95124 95125 Approved-By: Simon Marchi <simon.marchi@efficios.com> 95126 951272022-10-26 Mike Frysinger <vapier@gentoo.org> 95128 95129 gdb: make copyright.py interface a bit nicer 95130 This way people can run `./copyright.py --help` and get some info as 95131 to what this does without it going and modifying the tree. 95132 95133 sim: testsuite: improve parallel test processing 95134 The current logic limits itself to a maxdepth of 4 when looking for 95135 results. This wouldn't be a problem if cris didn't have a testsuite 95136 at a depth of 5 which we end up ignoring when summarizing. Rather 95137 than bump the number from 4 to 5, rework the code so that we gather 95138 the exact set of tests that we tried to run. 95139 951402022-10-26 Alan Modra <amodra@gmail.com> 95141 95142 buffer overflow in _bfd_XX_print_ce_compressed_pdata 95143 More fuzzed fun. 95144 95145 * peXXigen.c (_bfd_XX_print_ce_compressed_pdata): Use smaller of 95146 virt_size and bfd section size as limit of function table. 95147 951482022-10-26 Alan Modra <amodra@gmail.com> 95149 95150 Correct ELF reloc size sanity check 95151 The external reloc size check was wrong. Here asect is the code/data 95152 section, not the reloc section. So using this_hdr gave the size of 95153 the code/data section. 95154 95155 * elf.c (_bfd_elf_get_reloc_upper_bound): Properly get 95156 external size from reloc headers. 95157 951582022-10-26 Alan Modra <amodra@gmail.com> 95159 95160 segfault in objdump.c reloc_at 95161 bfd_canonicalize_reloc returns -1L on errors. 95162 95163 * objdump.c (load_specific_debug_section): Properly handle 95164 error return from bfd_canonicalize_reloc. 95165 951662022-10-26 Alan Modra <amodra@gmail.com> 95167 95168 som.c reloc sanity checking 95169 This patch checks that relocations emitted in som_write_fixups have 95170 offsets that are monotonic and within a section. To do that properly 95171 using bfd_reloc_offset_in_range it is necessary to set the reloc howto 95172 size field, which isn't used otherwise by the som backend. Note that 95173 the sizes used are not exactly those in the old sizing switch 95174 statement deleted from som_write_fixups, but all relocs handled by the 95175 main switch statement there get the same size. Most unhandled relocs 95176 get a zero size (exceptions being R_RELOCATION, R_SPACE_REF, 95177 R_MILLI_REL, R_BREAKPOINT which all involve writing one word according 95178 to my SOM reference). I figure it doesn't matter since any unhandled 95179 reloc is converted to 0xff R_RESERVED, and a default of zero is better 95180 for a "don't know" reloc. 95181 95182 Besides tidying the code, stringizing name from type in SOM_HOWTO 95183 fixes R_REPEATED_INIT name. 95184 95185 * som.c (SOM_HOWTO): Add SIZE arg, delete NAME. Stringize type 95186 to name. 95187 (som_hppa_howto_table): Update with sizes. 95188 (som_write_fixups): Delete sizing switch statement. Sanity check 95189 bfd_reloc address against subsection size. 95190 951912022-10-26 Alan Modra <amodra@gmail.com> 95192 95193 som.c buffer overflow 95194 Fuzzed object files can put random values in bfd_reloc->address, 95195 leading to large som_reloc_skip output. 95196 95197 * som.c (som_write_fixups): Allow for maximal som_reloc_skip. 95198 951992022-10-26 Alan Modra <amodra@gmail.com> 95200 95201 PR29720, objdump -S crashes if build-id is missing 95202 PR 29720 95203 * objdump.c (slurp_file): Don't call debuginfod_find_source 95204 when build_id is NULL. 95205 952062022-10-26 GDB Administrator <gdbadmin@sourceware.org> 95207 95208 Automatic date update in version.in 95209 952102022-10-25 Simon Marchi <simon.marchi@efficios.com> 95211 95212 gdb: remove spurious spaces after frame_info_ptr 95213 Fix some whitespace issues introduced with the frame_info_ptr patch. 95214 95215 Change-Id: I158d30d8108c97564276c647fc98283ff7b12163 95216 952172022-10-25 Michael Matz <matz@suse.de> 95218 95219 x86-64: Use only one default max-page-size 95220 On x86-64 the default ELF_MAXPAGESIZE depends on a configure 95221 option (--disable-separate-code). Since 9833b775 95222 ("PR28824, relro security issues") we use max-page-size for relro 95223 alignment (with a short interval, from 31b4d3a ("PR28824, relro 95224 security issues, x86 keep COMMONPAGESIZE relro") to its revert 95225 a1faa5ea, where x86-64 only used COMMONPAGESIZE as relro alignment 95226 target). 95227 95228 But that means that a linker configured with --disable-separate-code 95229 behaves different from one configured with --enable-separate-code 95230 (the default), _even if using "-z {no,}separate-code" option to use 95231 the non-configured behaviour_ . In particular it means that when 95232 configuring with --disable-separate-code the linker will produce 95233 binaries aligned to 2MB pages on disk, and hence generate 2MB 95234 executables for a hello world (and even 6MB when linked with 95235 "-z separate-code"). 95236 95237 Generally we can't have constants that ultimately land in static 95238 variables be depending on configure options if those only influence 95239 behaviour that is overridable by command line options. 95240 95241 So, do away with that, make the default MAXPAGESIZE be 4k (as is default 95242 for most x86-64 configs anyway, as most people won't configure with 95243 --disable-separate-code). If people need more they can use the 95244 "-z max-page-size" (with would have been required right now for a 95245 default configure binutils). 95246 95247 bfd/ 95248 * elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on 95249 DEFAULT_LD_Z_SEPARATE_CODE. 95250 952512022-10-25 Simon Marchi <simon.marchi@efficios.com> 95252 95253 gdb/testsuite: make sure to consume the prompt in gdb.base/unwind-on-each-insn.exp 95254 This test fails quite reliably for me when ran as: 95255 95256 $ taskset -c 1 make check TESTS="gdb.base/unwind-on-each-insn.exp" RUNTESTFLAGS="--target_board=native-gdbserver" 95257 95258 or more simply: 95259 95260 $ make check-read1 TESTS="gdb.base/unwind-on-each-insn.exp" 95261 95262 The problem is that the gdb_test_multiple call that grabs the frame id 95263 from "maint print frame-id" does not consume the prompt. Well, it does 95264 sometimes due to the trailing .*, but not always. If the prompt is not 95265 consumed, the tests that follow get confused: 95266 95267 FAIL: gdb.base/unwind-on-each-insn.exp: gdb_breakpoint: set breakpoint at *foo 95268 FAIL: gdb.base/unwind-on-each-insn.exp: disassemble foo 95269 FAIL: gdb.base/unwind-on-each-insn.exp: get $sp and frame base in foo: get hexadecimal valueof "$sp" 95270 ... many more ... 95271 95272 Use -wrap to make gdb_test_multiple consume the prompt. 95273 95274 While at it, remove the bit that consumes the command name and do 95275 exp_continue, it's not really necessary. And for consistency, do the 95276 same changes to the gdb_test_multiple that consumes the stack address, 95277 although that one was fine, it did consume the prompt explicitly. 95278 95279 Change-Id: I2b7328c8844c7e98921ea494c4c05107162619fc 95280 Reviewed-By: Bruno Larsen <blarsen@redhat.com> 95281 952822022-10-25 Tom de Vries <tdevries@suse.de> 95283 95284 [gdb/testsuite] Handle missing .note.GNU-stack 95285 On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and 95286 some hardcoded assembly test-cases: 95287 ... 95288 Running gdb.dwarf2/fission-absolute-dwo.exp ... 95289 gdb compile failed, ld: warning: fission-absolute-dwo.o: \ 95290 missing .note.GNU-stack section implies executable stack 95291 ld: NOTE: This behaviour is deprecated and will be removed in a future \ 95292 version of the linker 95293 95294 === gdb Summary === 95295 95296 # of untested testcases 1 95297 ... 95298 95299 Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in 95300 proc Dwarf::assemble. 95301 95302 Fix the hard-coded test-cases using this command: 95303 ... 95304 $ for f in $(find gdb/testsuite/gdb.* -name *.S); do 95305 if ! grep -q note.GNU-stack $f; then 95306 echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f; 95307 fi; 95308 done 95309 ... 95310 95311 Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S. 95312 95313 The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08be 95314 ("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so 95315 hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead. 95316 95317 Note that dwarf assembly testcases use %progbits as decided by proc _section. 95318 95319 Tested on x86_64-linux. 95320 95321 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674 95322 953232022-10-25 Tom de Vries <tdevries@suse.de> 95324 95325 [gdb/testsuite] Add missing skip_gdbserver_tests in gdb.multi/attach-no-multi-process.exp 95326 I build gdb without gdbserver, and ran into: 95327 ... 95328 (gdb) PASS: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \ 95329 switch to inferior 2 95330 spawn of --once --multi localhost:2346 failed 95331 ERROR: tcl error sourcing attach-no-multi-process.exp. 95332 ERROR: tcl error code NONE 95333 ERROR: Timeout waiting for gdbserver response. 95334 ... 95335 95336 Add the missing skip_gdbserver_tests. 95337 95338 Tested on x86_64-linux. 95339 953402022-10-25 Tom de Vries <tdevries@suse.de> 95341 95342 [gdb] Rewrite RETHROW_ON_TARGET_CLOSE_ERROR into function 95343 Recent commit b2829fcf9b5 ("[gdb] Fix rethrow exception slicing in 95344 insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR. 95345 95346 I wrote this as a macro in order to have the rethrowing throw be part of the 95347 same function as the catch, but as it turns out that's not necessary. 95348 95349 Rewrite into a function. 95350 95351 Tested on x86_64-linux. 95352 953532022-10-25 Simon Marchi <simon.marchi@polymtl.ca> 95354 95355 gdb: internal_error -> internal_error_loc in gdb-gdb.gdb.in 95356 Commit f34652de0b ("internal_error: remove need to pass 95357 __FILE__/__LINE__") renamed the internal_error function to 95358 internal_error_loc. Change gdb-gdb.gdb.in accordingly. 95359 95360 Change-Id: I876e1623607b6becf74ade53d102ead53a74ed86 95361 953622022-10-25 Nelson Chu <nelson@rivosinc.com> 95363 95364 RISC-V: Should reset `again' flag for _bfd_riscv_relax_pc. 95365 The R_RISCV_DELETE relocations are no longer deleted at another relax pass, 95366 so we should reset 'again' flag to true for _bfd_riscv_relax_pc, while the 95367 deleted bytes are marked as R_RISCV_DELETE. 95368 95369 bfd/ 95370 * elfnn-riscv.c (_bfd_riscv_relax_pc): Set `again' to true while the 95371 deleted bytes are marked as R_RISCV_DELETE. 95372 953732022-10-25 Patrick O'Neill <patrick@rivosinc.com> 95374 95375 RISC-V: Improve link time complexity. 95376 The riscv port does deletion and symbol table update for each relocation 95377 while relaxing, so we are moving section bytes and scanning symbol table once 95378 for each relocation. Compared to microblaze port, they record the relaxation 95379 changes into a table, then do the deletion and symbol table update once per 95380 section, rather than per relocation. Therefore, they should have better link 95381 time complexity than us. 95382 95383 To improve the link time complexity, this patch try to make the deletion in 95384 linear time. Compared to record the relaxation changes into a table, we 95385 replace the unused relocation with R_RISCV_DELETE for the deleted bytes, and 95386 then resolve them at the end of the section. Assuming the number of 95387 R_RISCV_DELETE is m, and the number of symbols is n, the total link complexity 95388 should be O(m) for moving section bytes, and O(m*n^2) for symbol table update. 95389 If we record the relaxation changes into the table, and then sort the symbol 95390 table by values, then probably can reduce the time complexity to O(m*n*log(n)) 95391 for updating symbol table, but it doesn't seem worth it for now. 95392 95393 bfd/ 95394 * elfnn-riscv.c (_riscv_relax_delete_bytes): Renamed from 95395 riscv_relax_delete_bytes, updated to reduce the tiem complexity to O(m) 95396 for memmove. 95397 (typedef relax_delete_t): Function pointer declaration of delete functions. 95398 (riscv_relax_delete_bytes): Can choose to use _riscv_relax_delete_piecewise 95399 or _riscv_relax_delete_immediate for deletion. 95400 (_riscv_relax_delete_piecewise): Just mark the deleted bytes as R_RISCV_DELETE. 95401 (_riscv_relax_delete_immediate): Delete some bytes from a section while 95402 relaxing. 95403 (riscv_relax_resolve_delete_relocs): Delete the bytes for R_RISCV_DELETE 95404 relocations from a section, at the end of _bfd_riscv_relax_section. 95405 (_bfd_riscv_relax_call): Mark deleted bytes as R_RISCV_DELETE by reusing 95406 R_RISCV_RELAX. 95407 (_bfd_riscv_relax_lui): Likewise, but reuse R_RISCV_HI20 for lui, and reuse 95408 R_RISCV_RELAX for c.lui. 95409 (_bfd_riscv_relax_tls_le): Likewise, but resue R_RISCV_TPREL_HI20 and 95410 R_RISCV_TPREL_ADD. 95411 (_bfd_riscv_relax_pc): Likewise, but resue R_RISCV_PCREL_HI20 for auipc. 95412 (_bfd_riscv_relax_align): Updated, don't need to resue relocation since 95413 calling _riscv_relax_delete_immediate. 95414 (_bfd_riscv_relax_delete): Removed. 95415 (_bfd_riscv_relax_section): Set riscv_relax_delete_bytes for each relax_func, 95416 to delete bytes immediately or later. Call riscv_relax_resolve_delete_relocs 95417 to delete bytes for DELETE relocations from a section. 95418 954192022-10-25 GDB Administrator <gdbadmin@sourceware.org> 95420 95421 Automatic date update in version.in 95422 954232022-10-24 Andrew Burgess <aburgess@redhat.com> 95424 95425 gdb/doc: reword description of DisassembleInfo.read_memory 95426 While reading the documentation of DisassembleInfo.read_memory I 95427 spotted the word 'available' in one sentence where it didn't make 95428 sense. 95429 954302022-10-24 Andrew Burgess <aburgess@redhat.com> 95431 95432 sim/lm32: fix some missing function declaration warnings 95433 In the lm32 simulator, I was seeing some warnings about missing 95434 function declarations. 95435 95436 The lm32 simulator has a weird header structure, in order to pull in 95437 the full cpu.h header we need to define WANT_CPU_LM32BF. This is done 95438 in some files, but not in others. Critically, it's not done in some 95439 files that then use functions declared in cpu.h 95440 95441 In this commit I added the missing #define so that the full cpu.h can 95442 be included. 95443 95444 After doing this there are still a few functions that are used 95445 undeclared, these functions appear to be missing any declarations at 95446 all, so I've added some to cpu.h. 95447 95448 With this done all the warnings when compiling lm32 are resolved for 95449 both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from 95450 Makefile.in, this allows lm32 to build with -Werror. 95451 954522022-10-24 Andrew Burgess <aburgess@redhat.com> 95453 95454 sim/h8300: avoid self assignment 95455 There are two places in the h8300 simulator where we assign a variable 95456 to itself. Clang gives a warning for this, which is converted into an 95457 error by -Werror. 95458 95459 Silence the warning by removing the self assignments. As these 95460 assignments were in a complex if/then/else tree, rather than try to 95461 adjust all the conditions, I've just replaced the self assignments 95462 with a comment and an empty statement. 95463 954642022-10-24 Andrew Burgess <aburgess@redhat.com> 95465 95466 sim/aarch64: remove two unused functions 95467 These functions are not used. Clang warns about the unused functions, 95468 which is then converted into an error by -Werror. 95469 95470 Delete the unused functions. 95471 954722022-10-24 Andrew Burgess <aburgess@redhat.com> 95473 95474 sim/ppc: fix for operator precedence warning from clang 95475 In the ppc simulator, clang was warning about some code like this: 95476 95477 busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2; 95478 95479 The warning was: 95480 95481 operator '?:' has lower precedence than '+'; '+' will be evaluated first 95482 95483 I suspect that this is not the original authors intention. 95484 PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+' 95485 first, the condition will always be non-zero, so true. The whole 95486 expression could then be simplified to just '1', which doesn't make 95487 much sense. 95488 95489 I suspect the answer the author was expecting was either 2 or 3. Why 95490 they didn't just write: 95491 95492 busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3; 95493 95494 I have no clue, however, to keep the structure of the code unchanged, 95495 I've updated things to: 95496 95497 busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2); 95498 95499 which silences the warning from clang, and is, I am guessing, what the 95500 original author intended. 95501 955022022-10-24 Andrew Burgess <aburgess@redhat.com> 95503 95504 sim/ppc: initialize a memory buffer in all cases 95505 In the ppc simulator's do_fstat function, which provides the fstat 95506 call for the simulator, if the fstat is going to fail then we 95507 currently write an uninitialized buffer into the simulated target. 95508 95509 In theory, I think this is fine, we also write the error status into 95510 the simulated target, so, given that the fstat has failed, the target 95511 shouldn't be relying on the buffer contents. 95512 95513 However, writing an uninitialized buffer means we might leak simulator 95514 private data into the simulated target, which is probably a bad thing. 95515 Plus it probably makes life easier if something consistent, like all 95516 zeros, is written rather than random junk, which might look like a 95517 successful call (except for the error code). 95518 95519 So, in this commit, I initialize the stat buffer to zero before 95520 it is potentially used. If the stat call is not made then the buffer 95521 will be left initialized as all zeros. 95522 955232022-10-24 Andrew Burgess <aburgess@redhat.com> 95524 95525 sim/ppc: don't try to print an uninitialized variable 95526 The ppc simulator, in sim_create_inferior, tries to print the function 95527 local entry_point variable before the variable is initialized. 95528 95529 In this commit, I defer the debug print line until the variable has 95530 been initialized. 95531 955322022-10-24 Andrew Burgess <aburgess@redhat.com> 95533 95534 sim/sh: use fabs instead of abs 95535 The sh simulator incorrectly uses integer abs instead of the floating 95536 point fabs on some floating point values, fixed in this commit. 95537 955382022-10-24 Tom de Vries <tdevries@suse.de> 95539 95540 [gdb] Fix rethrow exception slicing in insert_bp_location 95541 The preferred way of rethrowing an exception is by using throw without 95542 expression, because it avoids object slicing of the exception [1]. 95543 95544 Fix this in insert_bp_location. 95545 95546 Tested on x86_64-linux. 95547 95548 [1] https://en.cppreference.com/w/cpp/language/throw 95549 95550 Approved-By: Andrew Burgess <aburgess@redhat.com> 95551 955522022-10-24 Tom de Vries <tdevries@suse.de> 95553 95554 [gdb] Fix rethrow exception slicing in pretty_print_insn 95555 The preferred way of rethrowing an exception is by using throw without 95556 expression, because it avoids object slicing of the exception [1]. 95557 95558 Fix this in gdb_pretty_print_disassembler::pretty_print_insn. 95559 95560 Tested on x86_64-linux. 95561 95562 [1] https://en.cppreference.com/w/cpp/language/throw 95563 95564 Approved-By: Andrew Burgess <aburgess@redhat.com> 95565 955662022-10-24 Clément Chigot <chigot@adacore.com> 95567 95568 ld/testsuite: adjust ld-arm to run shared tests only when supported 95569 If a custom arm-elf target is disabling the shared support, a lot of 95570 failures are reported by the testsuite. 95571 Moreover, some tests try to access libraries which have been explicitly 95572 skipped earlier (eg mixed-lib.so). 95573 95574 ld/ChangeLog: 95575 95576 * testsuite/ld-arm/arm-elf.exp: Separate tests needing shared 95577 lib support. 95578 955792022-10-24 Clément Chigot <chigot@adacore.com> 95580 95581 ld/testsuite: skip ld-elf/exclude when -shared is not supported 95582 ld/ChangeLog: 95583 95584 * testsuite/ld-elf/exclude.exp: Call check_shared_lib_support. 95585 to skip for all targets without shared lib support. 95586 955872022-10-24 Jan Beulich <jbeulich@suse.com> 95588 95589 x86: consolidate VPCLMUL tests 95590 There's little point in having Intel syntax disassembler tests when the 95591 purpose of a test is assembler functionality: Drop all 95592 *avx512*_vpclmulqdq-wig1-intel. 95593 95594 For *avx512*_vpclmulqdq-wig1 share source with *avx512*_vpclmulqdq. 95595 95596 Finally put in place similar tests for -mvexwig=1. 95597 955982022-10-24 Jan Beulich <jbeulich@suse.com> 95599 95600 x86: consolidate VAES tests 95601 There's little point in having Intel syntax disassembler tests when the 95602 purpose of a test is assembler functionality: Drop all 95603 *avx512*_vaes-wig1-intel. 95604 95605 For *avx512*_vaes-wig1 share source with *avx512*_vaes. This in 95606 particular makes sure that the 32-bit VL test actually tests any EVEX 95607 encodings in the first place. 95608 95609 Finally put in place similar tests for -mvexwig=1. 95610 956112022-10-24 Jan Beulich <jbeulich@suse.com> 95612 95613 x86: emit {evex} prefix when disassembling ambiguous AVX512VL insns 95614 When no AVX512-specific functionality is in use, the disassembly of 95615 AVX512VL insns is indistinguishable from their AVX counterparts (if such 95616 exist). Emit the {evex} pseudo-prefix in such cases. 95617 95618 Where applicable drop stray uses of PREFIX_OPCODE from table entries. 95619 956202022-10-24 Tom de Vries <tdevries@suse.de> 95621 95622 [gdb/testsuite] Add skip_python_tests in gdb.python/tui-window-names.exp 95623 I did a gdb build without python support, and during testing ran into FAILs in 95624 test-case gdb.python/tui-window-names.exp. 95625 95626 Fix this by adding the missing skip_python_test. 95627 95628 Tested on x86_64-linux. 95629 956302022-10-24 GDB Administrator <gdbadmin@sourceware.org> 95631 95632 Automatic date update in version.in 95633 956342022-10-23 Mike Frysinger <vapier@gentoo.org> 95635 95636 sim: testsuite: update ignored .exp files [PR sim/29596] 95637 Now that we run `check/foo.exp` instead of `check/./foo.exp`, 95638 update the config/ & lib/ exceptions to cover both paths. 95639 95640 Bug: https://sourceware.org/PR29596 95641 956422022-10-23 Mike Frysinger <vapier@gentoo.org> 95643 95644 sim: testsuite: tweak parallel find invocation [PR sim/29596] 95645 Make sure we invoke runtest with the same exp filenames when running in 95646 parallel as it will find when run single threaded. When `runtest` finds 95647 files itself, it will use paths like "aarch64/allinsn.exp". When we run 95648 `find .` with the %p option, it produces "./aarch64/allinsn.exp". Switch 95649 to %P to get "aarch64/allinsn.exp". 95650 95651 Bug: https://sourceware.org/PR29596 95652 956532022-10-23 Mike Frysinger <vapier@gentoo.org> 95654 95655 sim: mips/ppc/riscv: re-add AC_CANONICAL_SYSTEM [PR sim/29439] 95656 These configure scripts check $target and change behavior. They 95657 shouldn't be doing that, but until we can rework the sim to change 95658 behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to 95659 these so that $target is correctly populated. 95660 95661 This was lost in the d3562f83a7b8a1ae6e333cd5561419d3da18fcb4 95662 ("sim: unify toolchain probing logic") refactor as the logic was 95663 hoisted up to the common code. But the fact the vars weren't 95664 passed down to the sub-configure scripts was missed. 95665 95666 Bug: https://sourceware.org/PR29439 95667 956682022-10-23 GDB Administrator <gdbadmin@sourceware.org> 95669 95670 Automatic date update in version.in 95671 956722022-10-22 Simon Marchi <simon.marchi@polymtl.ca> 95673 95674 gdb/testsuite: add max number of instructions check in gdb.base/unwind-on-each-insn.exp 95675 This test sends my CI in an infinite loop of failures. We expect to 95676 have a handful of iterations (5 on my development machine, where the 95677 test passes fine)but the log shows that it went up to 104340 iterations: 95678 95679 FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id 95680 DUPLICATE: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id 95681 FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: [string equal $fid $main_fid] 95682 FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: get hexadecimal valueof "$pc" 95683 95684 Add a max instruction check, exit the loop if we reach 100 iterations. 95685 This should allow the test to fail fast if there's a problem, but 100 95686 iterations should be more than enough for when things are working. 95687 95688 Change-Id: I77978d593aca046068f9209272d82e1675ba17c2 95689 956902022-10-22 GDB Administrator <gdbadmin@sourceware.org> 95691 95692 Automatic date update in version.in 95693 956942022-10-21 Pedro Alves <pedro@palves.net> 95695 95696 Improve Python Unwinders documentation 95697 - avoid "GDB proper" to refer to global locus, as object files and 95698 program spaces are also GDB proper. 95699 95700 - gdb.register_unwinder does not accept locus=gdb. 95701 95702 - "a unwinder" -> "an unwinder" 95703 95704 Approved-by: Eli Zaretskii <eliz@gnu.org> 95705 Change-Id: I98c1b1000e1063815238e945ca71ec6f37b5702e 95706 957072022-10-21 Simon Marchi <simon.marchi@polymtl.ca> 95708 95709 gdb: make inherit_abstract_dies use vector iterators 95710 Small cleanup to use std::vector iterators rather than raw pointers. 95711 95712 Approved-By: Tom Tromey <tom@tromey.com> 95713 Change-Id: I8d50dbb3f2d8dad7ff94066a578d523f1f31b590 95714 957152022-10-21 Simon Marchi <simon.marchi@polymtl.ca> 95716 95717 gdb: check for empty offsets vector in inherit_abstract_dies 95718 When building GDB with clang and --enable-ubsan, I get: 95719 95720 UNRESOLVED: gdb.dwarf2/frame-inlined-in-outer-frame.exp: starti prompt 95721 95722 The cause being: 95723 95724 $ ./gdb --data-directory=data-directory -nx -q -readnow testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame 95725 Reading symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame... 95726 Expanding full symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame... 95727 /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer 95728 95729 I found this to happen with ld-linux on at least Arch Linux and Ubuntu 95730 22.04: 95731 95732 $ ./gdb --data-directory=data-directory -nx -q -readnow -iex "set debuginfod enabled on" /lib64/ld-linux-x86-64.so.2 95733 Reading symbols from /lib64/ld-linux-x86-64.so.2... 95734 Reading symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo... 95735 Expanding full symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo... 95736 /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer 95737 95738 The problem happens when doing this: 95739 95740 sect_offset *offsetp = offsets.data () + 1 95741 95742 When `offsets` is an empty vector, `offsets.data ()` returns nullptr. 95743 Fix it by wrapping that in a `!offsets.empty ()` check. 95744 95745 Change-Id: I6d29ba2fe80ba4308f68effd9c57d4ee8d67c29f 95746 Approved-By: Tom Tromey <tom@tromey.com> 95747 957482022-10-21 Fangrui Song <maskray@google.com> 95749 95750 readelf: support zstd compressed debug sections [PR 29640] 95751 957522022-10-21 Tom Tromey <tromey@adacore.com> 95753 95754 Fix incorrect .gdb_index with new DWARF scanner 95755 PR symtab/29694 points out a regression caused by the new DWARF 95756 scanner when the cc-with-gdb-index target board is used. 95757 95758 What happens here is that an older version of gdb will make an index 95759 describing the "A" type as: 95760 95761 [737] A: 1 [global, type] 95762 95763 whereas the new gdb says: 95764 95765 [1008] A: 0 [global, type] 95766 95767 Here the old one is correct because the A in CU 0 is just a 95768 declaration without a size: 95769 95770 <1><45>: Abbrev Number: 10 (DW_TAG_structure_type) 95771 <46> DW_AT_name : A 95772 <48> DW_AT_declaration : 1 95773 <48> DW_AT_sibling : <0x6d> 95774 95775 This patch fixes the problem by introducing the idea of a "type 95776 declaration". I think gdb still needs to recurse into these types, 95777 searching for methods, but by marking the type itself as a 95778 declaration, gdb can skip this type during lookups and when writing 95779 the index. 95780 95781 Regression tested on x86-64 using the cc-with-gdb-index board. 95782 95783 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29694 95784 957852022-10-21 Tom Tromey <tromey@adacore.com> 95786 95787 Fix crash in value_print_array_elements 95788 A user noticed that gdb would crash when printing a packed array after 95789 doing "set lang c". Packed arrays don't exist in C, but it's 95790 occasionally useful to print things in C mode when working in a non-C 95791 language -- this lets you see under the hood a little bit. 95792 95793 The bug here is that generic value printing does not handle packed 95794 arrays at all. This patch fixes the bug by introducing a new function 95795 to extract a value from a bit offset and width. 95796 95797 The new function includes a hack to avoid problems with some existing 95798 test cases when using -fgnat-encodings=all. Cleaning up this code 95799 looked difficult, and since "all" is effectively deprecated, I thought 95800 it made sense to simply work around the problems. 95801 958022022-10-21 Tom Tromey <tromey@adacore.com> 95803 95804 Fix bug in Ada packed array handling 95805 A user found a bug where an array of packed arrays was printed 95806 incorrectly. The bug here is that the packed array has a bit stride, 95807 but the outer array does not -- and should not. However, 95808 update_static_array_size does not distinguish between an array of 95809 packed arrays and a multi-dimensional packed array, and for the 95810 latter, only the innermost array will end up with a stride. 95811 95812 This patch fixes the problem by adding a flag to indicate whether a 95813 given array type is a constituent of a multi-dimensional array. 95814 958152022-10-21 Simon Marchi <simon.marchi@polymtl.ca> 95816 95817 gdb: declare variables on first use in inherit_abstract_dies 95818 Move variable declarations to where they are first use, plus some random 95819 style fixes. 95820 95821 Change-Id: Idf40d60f9034996fa6a234165cd989a721eb4148 95822 958232022-10-21 Nick Clifton <nickc@redhat.com> 95824 95825 Add a -w option to the linker to suppress warning and error messages. 95826 PR 29654 95827 * ld.h (struct ld_config_type): Add no_warnings field. 95828 * ldlex.h (enum option_values): Add OPTION_NO_WARNINGS. 95829 * lexsup.c (ld_options): Add --no-warnings. 95830 (parse_args): Add support for -w and --no-warnings. 95831 * ldmisc.c (vfinfo): Return early if the message is a warning and 95832 -w has been enabled. 95833 * ld.texi (options): Document new command line option. 95834 * NEWS: Mention the new feature. 95835 95836 Add a note to the binutils/NEWS file about DCO signed contributions. 95837 958382022-10-21 Bruno Larsen <blarsen@redhat.com> 95839 95840 gdb/reverse: Fix stepping over recursive functions 95841 Currently, when using GDB to do reverse debugging, if we try to use the 95842 command "reverse next" to skip a recursive function, instead of skipping 95843 all of the recursive calls and stopping in the previous line, we stop at 95844 the second to last recursive call, and need to manually step backwards 95845 until we leave the first call. This is well documented in PR gdb/16678. 95846 95847 This bug happens because when GDB notices that a reverse step has 95848 entered into a function, GDB will add a step_resume_breakpoint at the 95849 start of the function, then single step out of the prologue once that 95850 breakpoint is hit. The problem was happening because GDB wouldn't give 95851 that step_resume_breakpoint a frame-id, so the first time the breakpoint 95852 was hit, the inferior would be stopped. This is fixed by giving the 95853 current frame-id to the breakpoint. 95854 95855 This commit also changes gdb.reverse/step-reverse.c to contain a 95856 recursive function and attempt to both, skip it altogether, and to skip 95857 the second call from inside the first call, as this setup broke a 95858 previous version of the patch. 95859 958602022-10-21 Bruno Larsen <blarsen@redhat.com> 95861 95862 Change calculation of frame_id by amd64 epilogue unwinder 95863 When GDB is stopped at a ret instruction and no debug information is 95864 available for unwinding, GDB defaults to the amd64 epilogue unwinder, to 95865 be able to generate a decent backtrace. However, when calculating the 95866 frame id, the epilogue unwinder generates information as if the return 95867 instruction was the whole frame. 95868 95869 This was an issue especially when attempting to reverse debug, as GDB 95870 would place a step_resume_breakpoint from the epilogue of a function if 95871 we were to attempt to skip that function, and this breakpoint should 95872 ideally have the current function's frame_id to avoid other problems 95873 such as PR record/16678. 95874 95875 This commit changes the frame_id calculation for the amd64 epilogue, 95876 so that it is always the same as the dwarf2 unwinder's frame_id. 95877 95878 It also adds a test to confirm that the frame_id will be the same, 95879 regardless of using the epilogue unwinder or not, thanks to Andrew 95880 Burgess. 95881 95882 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 95883 958842022-10-21 Nick Clifton <nickc@redhat.com> 95885 95886 Updated Hungarian translation for the gprof sub-directory. 95887 * po/hu.po: Updated Hungarian translation. 95888 958892022-10-21 Maciej W. Rozycki <macro@embecosm.com> 95890 95891 GDB/Python: Make `None' stand for `unlimited' in setting integer parameters 95892 Similarly to booleans and following the fix for PR python/29217 make 95893 `gdb.parameter' accept `None' for `unlimited' with parameters of the 95894 PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZUINTEGER_UNLIMITED types, as 95895 `None' is already returned by parameters of the two former types, so 95896 one might expect to be able to feed it back. It also makes it possible 95897 to avoid the need to know what the internal integer representation is 95898 for the special setting of `unlimited'. 95899 95900 Expand the testsuite accordingly. 95901 95902 Approved-By: Simon Marchi <simon.marchi@polymtl.ca> 95903 959042022-10-21 Maciej W. Rozycki <macro@embecosm.com> 95905 95906 GDB/testsuite: Expand Python integer parameter coverage across all types 95907 Also verify PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZINTEGER parameter 95908 types, in addition to PARAM_ZUINTEGER and PARAM_ZUINTEGER_UNLIMITED 95909 already covered, and verify a choice of existing GDB parameters. Add 95910 verification for reading parameters via `<parameter>.value' in addition 95911 to `gdb.parameter('<parameter>')' as this covers different code paths. 95912 95913 Approved-By: Simon Marchi <simon.marchi@polymtl.ca> 95914 959152022-10-21 Maciej W. Rozycki <macro@embecosm.com> 95916 95917 GDB/Guile: Don't assert that an integer value is boolean 95918 Do not assert that a value intended for an integer parameter, of either 95919 the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean, 95920 causing error messages such as: 95921 95922 ERROR: In procedure make-parameter: 95923 ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3 95924 Error while executing Scheme code. 95925 95926 when initialization with a number is attempted. Instead assert that it 95927 is integer. Keep matching `#:unlimited' keyword as an alternative. Add 95928 suitable test cases. 95929 95930 Approved-By: Simon Marchi <simon.marchi@polymtl.ca> 95931 959322022-10-21 Tom de Vries <tdevries@suse.de> 95933 95934 [gdb/testsuite] Silence compilation fail in gdb.base/rtld-step.exp 95935 With gcc 7.5.0 and test-case gdb.base/rtld-step.exp, I run into: 95936 ... 95937 gdb compile failed, gcc: error: unrecognized command line option \ 95938 '-static-pie'; did you mean '-static'? 95939 ... 95940 95941 Silence this by checking in the test-case that -static-pie is supported, and 95942 emitting instead: 95943 ... 95944 UNTESTED: gdb.base/rtld-step.exp: \ 95945 failed to compile (-static-pie not supported or static libc missing) 95946 ... 95947 95948 Tested on x86_64-linux, with: 95949 - gcc 7.5.0: UNTESTED 95950 - gcc 12.2.1 with static glibc not installed: UNTESTED 95951 - gcc 12.2.1 with static glibc installed: PASS 95952 959532022-10-21 Cui,Lili <lili.cui@intel.com> 95954 95955 Support Intel AMX-FP16 95956 gas/ 95957 95958 * NEWS: Add support for Intel AMX-FP16 instruction. 95959 * config/tc-i386.c: Add amx_fp16. 95960 * doc/c-i386.texi: Document .amx_fp16. 95961 * testsuite/gas/i386/i386.exp: Add AMX-FP16 tests. 95962 * testsuite/gas/i386/x86-64-amx-fp16-intel.d: New test. 95963 * testsuite/gas/i386/x86-64-amx-fp16.d: Likewise. 95964 * testsuite/gas/i386/x86-64-amx-fp16.s: Likewise. 95965 * testsuite/gas/i386/x86-64-amx-fp16-bad.d: Likewise. 95966 * testsuite/gas/i386/x86-64-amx-fp16-bad.s: Likewise. 95967 95968 opcodes/ 95969 95970 * i386-dis.c (MOD_VEX_0F385C_X86_64_P_3_W_0): New. 95971 (VEX_LEN_0F385C_X86_64_P_3_W_0_M_0): Likewise. 95972 (VEX_W_0F385C_X86_64_P_3): Likewise. 95973 (prefix_table): Add VEX_W_0F385C_X86_64_P_3. 95974 (vex_len_table): Add VEX_LEN_0F385C_X86_64_P_3_W_0_M_0. 95975 (vex_w_table): Add VEX_W_0F385C_X86_64_P_3. 95976 (mod_table): Add MOD_VEX_0F385C_X86_64_P_3_W_0. 95977 * i386-gen.c (cpu_flag_init): Add AMX-FP16_FLAGS. 95978 (CPU_ANY_AMX_TILE_FLAGS): Add CpuAMX_FP16. 95979 (cpu_flags): Add CpuAMX-FP16. 95980 * i386-opc.h (enum): Add CpuAMX-FP16. 95981 (i386_cpu_flags): Add cpuamx_fp16. 95982 * i386-opc.tbl: Add Intel AMX-FP16 instruction. 95983 * i386-init.h: Regenerate. 95984 * i386-tbl.h: Likewise. 95985 959862022-10-21 Tsukasa OI <research_trasio@irq.a4lg.com> 95987 95988 sim: Remove unused CXXFLAGS substitution 95989 Not only that sim/configure.ac does not AC_SUBST CXXFLAGS, 95990 unless we need C++ compiler like CXX, substitution @CXXFLAGS@ is useless. 95991 Because of this, this commit removes this substitution. 95992 959932022-10-21 GDB Administrator <gdbadmin@sourceware.org> 95994 95995 Automatic date update in version.in 95996 959972022-10-20 H.J. Lu <hjl.tools@gmail.com> 95998 95999 x86: Check VEX/EVEX encoding before checking vector operands 96000 Since 96001 96002 commit 837e225ba1992f9745e5bbbd5e8443243a7f475f 96003 Author: Jan Beulich <jbeulich@suse.com> 96004 Date: Thu Oct 20 10:01:12 2022 +0200 96005 96006 x86: re-work AVX-VNNI support 96007 96008 moved AVX-VNNI after AVX512-VNNI, vector Disp8 is applied even when VEX 96009 encoding is selected. Check VEX/EVEX encoding before checking vector 96010 operands to avoid vector Disp8 with VEX encoding. 96011 96012 PR gas/29708 96013 * config/tc-i386.c (match_template): Check VEX/EVEX encoding 96014 before checking vector operands. 96015 * testsuite/gas/i386/avx-vnni.d: Updated. 96016 * testsuite/gas/i386/x86-64-avx-vnni.d: Likewise. 96017 * testsuite/gas/i386/avx-vnni.s: Add a Disp32 test. 96018 * testsuite/gas/i386/x86-64-avx-vnni.s: Likewise. 96019 960202022-10-20 Andrew Burgess <aburgess@redhat.com> 96021 96022 gdb/python: break more dependencies between gdbpy_initialize_* functions 96023 In a later commit in this series I will propose removing all of the 96024 explicit gdbpy_initialize_* calls from python.c and replace these 96025 calls with a more generic mechanism. 96026 96027 One of the side effects of this generic mechanism is that the order in 96028 which the various Python sub-systems within GDB are initialized is no 96029 longer guaranteed. 96030 96031 On the whole I don't think this matters, most of the sub-systems are 96032 independent of each other, though testing did reveal a few places 96033 where we did have dependencies, though I don't think those 96034 dependencies were explicitly documented in comment anywhere. 96035 96036 This commit is similar to the previous one, and fixes the second 96037 dependency issue that I found. 96038 96039 In this case the finish_breakpoint_object_type uses the 96040 breakpoint_object_type as its tp_base, this means that 96041 breakpoint_object_type must have been initialized with a call to 96042 PyType_Ready before finish_breakpoint_object_type can be initialized. 96043 96044 Previously we depended on the ordering of calls to 96045 gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in 96046 python.c. 96047 96048 After this commit a new function gdbpy_breakpoint_init_breakpoint_type 96049 exists, this function ensures that breakpoint_object_type has been 96050 initialized, and can be called from any gdbpy_initialize_* function. 96051 96052 I feel that this change makes the dependency explicit, which I think 96053 is a good thing. 96054 96055 There should be no user visible changes after this commit. 96056 960572022-10-20 Andrew Burgess <aburgess@redhat.com> 96058 96059 gdb/python: break dependencies between gdbpy_initialize_* functions 96060 In a later commit in this series I will propose removing all of the 96061 explicit gdbpy_initialize_* calls from python.c and replace these 96062 calls with a more generic mechanism. 96063 96064 One of the side effects of this generic mechanism is that the order in 96065 which the various Python sub-systems within GDB are initialized is no 96066 longer guaranteed. 96067 96068 On the whole I don't think this matters, most of the sub-systems are 96069 independent of each other, though testing did reveal a few places 96070 where we did have dependencies, though I don't think those 96071 dependencies were explicitly documented in a comment anywhere. 96072 96073 This commit removes the first dependency issue, with this and the next 96074 commit, all of the implicit inter-sub-system dependencies will be 96075 replaced by explicit dependencies, which will allow me to, I think, 96076 clean up how the sub-systems are initialized. 96077 96078 The dependency is around the py_insn_type. This type is setup in 96079 gdbpy_initialize_instruction and used in gdbpy_initialize_record. 96080 Rather than depend on the calls to these two functions being in a 96081 particular order, in this commit I propose adding a new function 96082 py_insn_get_insn_type. This function will take care of setting up the 96083 py_insn_type type and calling PyType_Ready. This helper function can 96084 be called from gdbpy_initialize_record and 96085 gdbpy_initialize_instruction, and the py_insn_type will be initialized 96086 just once. 96087 96088 To me this is better, the dependency is now really obvious, but also, 96089 we no longer care in which order gdbpy_initialize_record and 96090 gdbpy_initialize_instruction are called. 96091 96092 There should be no user visible changes after this commit. 96093 960942022-10-20 Andrew Burgess <aburgess@redhat.com> 96095 96096 gdb: some int to bool conversion in breakpoint.c 96097 Some int to bool conversion in breakpoint.c. I've only updated the 96098 function signatures of static functions, but I've updated some 96099 function local variables throughout the file. 96100 96101 There should be no user visible changes after this commit. 96102 96103 Approved-By: Simon Marchi <simon.marchi@efficios.com> 96104 961052022-10-20 Andrew Burgess <aburgess@redhat.com> 96106 96107 gdb: make use of scoped_restore in unduplicated_should_be_inserted 96108 I noticed that we could make use of a scoped_restore in the function 96109 unduplicated_should_be_inserted. I've also converted the function 96110 return type from int to bool. 96111 96112 This change shouldn't make any difference, as I don't think anything 96113 within should_be_inserted could throw an exception, but the change 96114 doesn't hurt, and will help keep us safe if anything ever changes in 96115 the future. 96116 96117 Approved-By: Simon Marchi <simon.marchi@efficios.com> 96118 961192022-10-20 Andrew Burgess <aburgess@redhat.com> 96120 96121 gdb: used scoped_restore_frame in update_watchpoint 96122 I was doing some int to bool cleanup in update_watchpoint, and I 96123 noticed a manual version of scoped_restore_selected_frame. As always 96124 when these things are done manually, there is the chance that, in an 96125 error case, we might leave the wrong frame selected. 96126 96127 This commit updates things to use scoped_restore_selected_frame, and 96128 also converts a local variable from int to bool. 96129 96130 The only user visible change after this commit is in the case where 96131 update_watchpoint throws an error - we should now correctly restore 96132 the previously selected frame. Otherwise, this commit should be 96133 invisible to the user. 96134 96135 Approved-By: Simon Marchi <simon.marchi@efficios.com> 96136 961372022-10-20 Andrew Burgess <aburgess@redhat.com> 96138 96139 gdb: make some bp_location arguments const in breakpoint.c 96140 I spotted a few places where I could make some 'bp_location *' 96141 arguments constant in breakpoint.c. 96142 96143 There should be no user visible changes after this commit. 96144 96145 Approved-By: Simon Marchi <simon.marchi@efficios.com> 96146 961472022-10-20 Дилян Палаузов <dilyan.palauzov@aegee.org> 96148 96149 Reapply "Don't build readline/libreadline.a, when --with-system-readline is supplied" 96150 Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the 96151 change originally done in commit 69961a84c9b ("Don't build 96152 readline/libreadline.a, when --with-system-readline is supplied"). 96153 Re-apply it. 96154 96155 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18632 96156 961572022-10-20 Jan Beulich <jbeulich@suse.com> 96158 96159 x86: re-work AVX-VNNI support 96160 By putting the templates after their AVX512 counterparts, the AVX512 96161 flavors will be picked by default. That way the need to always use {vex} 96162 ceases to exist once respective CPU features (AVX512-VNNI or AVX512VL as 96163 a whole) have been disabled. This way the need for the PseudoVexPrefix 96164 attribute also disappears. 96165 961662022-10-20 Tom de Vries <tdevries@suse.de> 96167 96168 [gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with check-read1 96169 With test-case gdb.debuginfod/fetch_src_and_symbols.exp and check-read1, I run 96170 into: 96171 ... 96172 (gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: \ 96173 file fetch_src_and_symbols (got interactive prompt) 96174 ... 96175 96176 The problem is that this output: 96177 ... 96178 Enable debuginfod for this session? (y or [n]) y^M 96179 ... 96180 is matched using regexp "Enable debuginfod?.*" with matches only the first two 96181 words of the output, after which an implicit clause in gdb_test_multiple triggers 96182 on the second part containing the interactive prompt. 96183 96184 Fix this by included the interactive prompt in the regexp. 96185 96186 Tested on x86_64-linux. 96187 961882022-10-20 Tom de Vries <tdevries@suse.de> 96189 96190 [gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with check-read1 96191 With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into: 96192 ... 96193 FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main 96194 FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)" 96195 ... 96196 96197 The problem for both FAILs is that the output is parsed using 96198 gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can 96199 match before the explicit clauses using $mi_gdb_prompt. 96200 96201 Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple. 96202 96203 Tested on x86-64-linux. 96204 962052022-10-20 Alan Modra <amodra@gmail.com> 96206 96207 Re: aarch64-pe support for LD, GAS and BFD 96208 Fix dependencies for eaarch64pe.c. Generated files aren't handled 96209 fully automatically. 96210 962112022-10-20 Mark Harmstone <mark@harmstone.com> 96212 96213 ld: Add minimal pdb generation 96214 96215 ld: Add --pdb option 96216 Second patch incorporates fixes for endian and UB issues in calc_hash, as per 96217 https://sourceware.org/pipermail/binutils/2022-October/123514.html. 96218 962192022-10-20 Kevin Buettner <kevinb@redhat.com> 96220 96221 Test stepping within a runtime loader / dynamic linker 96222 See the remarks in rtld-step.exp for a description of what this 96223 test is about. 96224 96225 This test case has been tested using gcc on the following x86-64 Linux 96226 distributions/releases: 96227 96228 Fedora 28 96229 Fedora 32 96230 Fedora 33 96231 Fedora 34 96232 Fedora 35 96233 Fedora 36 96234 Fedora 37 96235 rawhide (f38) 96236 RHEL 9.1 96237 Ubuntu 22.04.1 LTS 96238 96239 It's also been tested (and found to be working) with 96240 RUNTESTFLAGS="CC_FOR_TARGET=clang" on all of the above expect for 96241 Fedora 28. The (old) version of clang available on F28 did not 96242 accept the -static-pie option. 96243 96244 I also tried to make this test work on FreeBSD 13.1. While I think I 96245 made significant progress, I was ultimately stymied by this message 96246 which occurs when attempting to run the main program which has been 96247 set to use the fake/pretend RTLD as the ELF interpreter: 96248 96249 ELF interpreter /path/to/rtld-step-rtld not found, error 22 96250 96251 I have left one of the flags (-static) in place which I believe 96252 to be needed for FreeBSD (though since I never got it to work, I 96253 don't know for sure.) I've also left some declarations needed 96254 for FreeBSD in rtld-step-rtld.c. They're currently disabled via 96255 a #if 0; you'll need to enable them if you want to try to make 96256 it work on FreeBSD. 96257 962582022-10-20 Kevin Buettner <kevinb@redhat.com> 96259 96260 Allow debugging of runtime loader / dynamic linker 96261 At present, GDB does not allow for the debugging of the runtime loader 96262 and/or dynamic linker. Much of the time, this makes sense. An 96263 application programmer doesn't normally want to see symbol resolution 96264 code when stepping into a function that hasn't been resolved yet. 96265 96266 But someone who wishes to debug the runtime loader / dynamic linker 96267 might place a breakpoint in that code and then wish to debug it 96268 as normal. At the moment, this is not possible. Attempting to step 96269 will cause GDB to internally step (and not stop) until code 96270 unrelated to the dynamic linker is reached. 96271 96272 This commit makes a minor change to infrun.c which allows the dynamic 96273 loader / linker to be debugged in the case where a step, next, etc. 96274 is initiated from within that code. 96275 96276 While developing this fix, I tried some approaches which weren't quite 96277 right. The GDB testusite definitely contains tests which FAIL when 96278 it's done incorrectly. (At one point, I saw 17 regressions!) This 96279 commit has been tested on x86-64 linux with no regressions. 96280 962812022-10-20 Tsukasa OI <research_trasio@irq.a4lg.com> 96282 96283 binutils: Remove unused substitution PROGRAM 96284 Unlike other substitution, this substitution of @PROGRAM@ was done in 96285 binutils/Makefile and it was intended for binutils/cxxfilt.man. @PROGRAM@ 96286 in binutils/cxxfilt.man is removed in the commit 0285c67df190 ("Automate 96287 generate on man pages") in 2001 and @PROGRAM@ is ineffective since then. 96288 96289 Because PROGRAM substitution does nothing, removing this manual 96290 substitution should be completely safe. 96291 96292 binutils/ChangeLog: 96293 96294 * doc/local.mk: Remove unused substitution PROGRAM. 96295 * Makefile.in: Regenerate. 96296 962972022-10-20 GDB Administrator <gdbadmin@sourceware.org> 96298 96299 Automatic date update in version.in 96300 963012022-10-20 Alan Modra <amodra@gmail.com> 96302 96303 Obsolete beos 96304 * config.bfd: Obsolete *-*-beos*. Simplify x86 beos match. 96305 96306 Regen ld/po/BLD-POTFILES.in 96307 963082022-10-19 Tom de Vries <tdevries@suse.de> 96309 96310 [gdb] Fix assert in handle_jit_event 96311 With the cc-with-tweaks.sh patch submitted here ( 96312 https://sourceware.org/pipermail/gdb-patches/2022-October/192586.html ) we run 96313 with: 96314 ... 96315 $ export STRIP_ARGS_STRIP_DEBUG=--strip-all 96316 $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \ 96317 --target_board cc-with-gnu-debuglink" 96318 ... 96319 into the following assert: 96320 ... 96321 (gdb) run ^M 96322 Starting program: jit-reader ^M 96323 gdb/jit.c:1247: internal-error: jit_event_handler: \ 96324 Assertion `jiter->jiter_data != nullptr' failed.^M 96325 ... 96326 96327 Fix this by handling the 96328 jit_bp_sym.objfile->separate_debug_objfile_backlink != nullptr case in 96329 handle_jit_event. 96330 96331 Tested on x86_64-linux. 96332 96333 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29277 96334 963352022-10-19 Pedro Alves <pedro@palves.net> 96336 96337 internal_error: remove need to pass __FILE__/__LINE__ 96338 Currently, every internal_error call must be passed __FILE__/__LINE__ 96339 explicitly, like: 96340 96341 internal_error (__FILE__, __LINE__, "foo %d", var); 96342 96343 The need to pass in explicit __FILE__/__LINE__ is there probably 96344 because the function predates widespread and portable variadic macros 96345 availability. We can use variadic macros nowadays, and in fact, we 96346 already use them in several places, including the related 96347 gdb_assert_not_reached. 96348 96349 So this patch renames the internal_error function to something else, 96350 and then reimplements internal_error as a variadic macro that expands 96351 __FILE__/__LINE__ itself. 96352 96353 The result is that we now should call internal_error like so: 96354 96355 internal_error ("foo %d", var); 96356 96357 Likewise for internal_warning. 96358 96359 The patch adjusts all calls sites. 99% of the adjustments were done 96360 with a perl/sed script. 96361 96362 The non-mechanical changes are in gdbsupport/errors.h, 96363 gdbsupport/gdb_assert.h, and gdb/gdbarch.py. 96364 96365 Approved-By: Simon Marchi <simon.marchi@efficios.com> 96366 Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06 96367 963682022-10-19 Nick Clifton <nickc@redhat.com> 96369 96370 Fix an illegal memory access when parsing an ELF file containing corrupt symbol version information. 96371 PR 29699 96372 * elf.c (_bfd_elf_slurp_version_tables): Fail if the sh_info field 96373 of the section header is zero. 96374 963752022-10-19 Andrew Burgess <aburgess@redhat.com> 96376 96377 sim/iq2000: silence pointer-sign warnings 96378 When building the iq2000 simulator I see a few warnings like this: 96379 96380 /tmp/build/sim/../../src/sim/iq2000/iq2000.c: In function ‘fetch_str’: 96381 /tmp/build/sim/../../src/sim/iq2000/iq2000.c:50:54: error: pointer targets in passing argument 3 of ‘sim_read’ differ in signedness [-Werror=pointer-sign] 96382 50 | sim_read (CPU_STATE (current_cpu), CPU2DATA(addr), buf, nr); 96383 | ^~~ 96384 | | 96385 | char * 96386 96387 I've silenced these warnings by casting buf to 'unsigned char *'. 96388 With this change I now see no warnings when compiling iq2000.c, so 96389 I've removed the line from Makefile.in that disables -Werror. 96390 96391 Makefile.in was also disabling -Werror when compiling mloop.c, 96392 however, I'm not seeing any warnings when compiling that file, so I've 96393 removed the -Werror disable in that case too. 96394 963952022-10-19 Andrew Burgess <aburgess@redhat.com> 96396 96397 sim/erc32: avoid dereferencing type-punned pointer warnings 96398 When building the erc32 simulator I get a few warnings like this: 96399 96400 /tmp/build/sim/../../src/sim/erc32/exec.c:1377:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 96401 1377 | sregs->fs[rd] = *((float32 *) & ddata[0]); 96402 | ~^~~~~~~~~~~~~~~~~~~~~~~ 96403 96404 The type of '& ddata[0]' will be 'uint32_t *', which is what triggers 96405 the warning. 96406 96407 This commit makes use of memcpy when performing the type-punning, 96408 which resolves the above warnings. 96409 96410 With this change, I now see no warnings when compiling exec.c, which 96411 means that the line in Makefile.in that disables -Werror can be 96412 removed. 96413 96414 There should be no change in behaviour after this commit. 96415 964162022-10-19 Andrew Burgess <aburgess@redhat.com> 96417 96418 sim/ppc: mark device_error function as ATTRIBUTE_NORETURN 96419 The device_error function always ends up calling the error function, 96420 which is itself marked as ATTRIBUTE_NORETURN, so it makes sense that 96421 device_error should also be marked ATTRIBUTE_NORETURN. 96422 96423 Doing this resolves a few warnings from hw_ide.c about possibly 96424 uninitialized variables - the variables are only uninitialized after 96425 passing through a call to device_error, which obviously means the 96426 variables are never really used uninitialized, the simulation will 96427 terminate with the device_error call. 96428 964292022-10-19 Andrew Burgess <aburgess@redhat.com> 96430 96431 sim/ppc: fix warnings related to printf format strings 96432 This commit is a follow on to: 96433 96434 commit 182421c9d2eea8c4877d983a2124e591f0aca710 96435 Date: Tue Oct 11 15:02:08 2022 +0100 96436 96437 sim/ppc: fixes for arguments to printf style functions 96438 96439 where commit 182421c9d2ee addressed issues with printf format 96440 arguments that were causing the compiler to give an error, this commit 96441 addresses issues that caused the compiler to emit a warning. 96442 96443 This commit is mostly either changing the format string to match the 96444 argument, or in some cases, excess, unused arguments are removed. 96445 964462022-10-19 Andrew Burgess <aburgess@redhat.com> 96447 96448 sim/cgen: mask uninitialized variable warning in cgen-run.c 96449 I see an uninitialized variable warning (with gcc 9.3.1) from 96450 cgen-run.c, like this: 96451 96452 /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c: In function ‘sim_resume’: 96453 /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:259:5: warning: ‘engine_fns$’ may be used uninitialized in this function [-Wmaybe-uninitialized] 96454 259 | (* engine_fns[next_cpu_nr]) (cpu); 96455 | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 96456 /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:232:14: note: ‘engine_fns$’ was declared here 96457 232 | ENGINE_FN *engine_fns[MAX_NR_PROCESSORS]; 96458 | ^~~~~~~~~~ 96459 96460 This is a false positive - we over allocate engine_fn, and then only 96461 initialize the nr_cpus entries which we will later go on to use. 96462 96463 However, we can easily silence this warning by initializing the unused 96464 entries in engine_fns to NULL, this might also help if anyone ever 96465 looks at engine_fns in a debugger, it should now be obvious which 96466 entries are in use, and which are not. 96467 96468 With this change the warning is gone. 96469 96470 There should be no change in behaviour with this commit. 96471 964722022-10-19 Alan Modra <amodra@gmail.com> 96473 96474 Fix addr2line test for ppc64 elfv1 and mingw 96475 * testsuite/binutils-all/addr2line.exp: Tidy. For powerpc64 96476 arrange to pass --synthetic to nm, and extract .main and .fn 96477 symbol address for addr2line test. Handle default executable 96478 extension on cygwin/mingw compilers. 96479 964802022-10-19 Nick Clifton <nickc@redhat.com> 96481 96482 Update MAINTAINERS file with details about accepting DCO signed contributions. 96483 * MAINTAINERS: Add section on patches, copyright and DCO. 96484 964852022-10-19 Andrew Burgess <aburgess@redhat.com> 96486 96487 gdb/testsuite: avoid temporary file in gdb/testsuite (unittest.exp) 96488 I spotted that the gdb.gdb/unittest.exp script causes a temporary file 96489 inserters_extractors-2.txt to be created in build/gdb/testsuite/ 96490 instead of in build/gdb/testsuite/output/gdb.gdb/unittest/. 96491 96492 This is because some of the 'maint selftest' tests create temporary 96493 files in GDB's current directory, specifically, the two source files: 96494 96495 gdb/unittests/basic_string_view/inserters/wchar_t/2.cc 96496 gdb/unittests/basic_string_view/inserters/char/2.cc 96497 96498 both create a temporary file called inserters_extractors-2.txt, though 96499 we only run the second of these as part of GDB's selftests. 96500 96501 I initially proposed just using GDB's 'cd' command in unittest.exp to 96502 switch to the test output directory before running the selftests, 96503 however, Pedro pointed out that there was a risk here that, if GDB 96504 crashed during shutdown, the generated core file would be left in the 96505 test output directory rather than in the testsuite directory. As a 96506 result, our clever core file spotting logic would fail to spot the 96507 core file and alert the user. 96508 96509 Instead, I propose this slightly more involved solution. I've added a 96510 new with_gdb_cwd directory proc, used like this: 96511 96512 with_gdb_cwd $directory { 96513 # Tests here... 96514 } 96515 96516 The new proc temporarily switches to $directory and then runs the 96517 tests within the block. After running the tests the previous current 96518 working directory is restored. 96519 96520 Additionally, after switching back to the previous cwd, we check that 96521 GDB is still responsive. This means that if GDB crashed immediately 96522 prior to restoring the previous directory, and left the core file in 96523 the wrong place, then the responsiveness check will fail, and a FAIL 96524 will be emitted, this should be enough to alert the user that 96525 something has gone wrong. 96526 96527 With this commit in place the unittest.exp script now leaves its 96528 temporary file in the test output directory. 96529 965302022-10-19 Andrew Burgess <aburgess@redhat.com> 96531 96532 gdb/testsuite: avoid creating files in gdb/testsuite directory 96533 I spotted that the test gdb.dwarf2/dw2-using-debug-str.exp was 96534 creating an output file called debug_str_section in the root 96535 build/gdb/testsuite directory instead of using the 96536 build/gdb/testsuite/output/gdb.dwarf2/dw2-using-debug-str/ directory. 96537 96538 This appears to be caused by a missing '$' character. We setup a 96539 variable debug_str_section which contains a path within the output 96540 directory, but then when we build the objcopy command we use 96541 'debug_str_section' without a '$' prefix, as a result, we create the 96542 debug_str_section file. 96543 96544 This commit adds the missing '$', the file is now created in the 96545 output directory. 96546 965472022-10-19 Andrew Burgess <aburgess@redhat.com> 96548 96549 bfd: fix undefined references to aarch64_pe_le_vec 96550 After commit: 96551 96552 commit c60b3806799abf1d7f6cf5108a1b0e733a950b13 96553 Date: Wed Oct 19 10:57:12 2022 +0200 96554 96555 aarch64-pe support for LD, GAS and BFD 96556 96557 It appears that bfd/Makefile.in and bfd/configure were not regenerated 96558 correctly. The differences in the configure file are only whitespace, 96559 but in Makefile.in a critical reference to pe-aarch64.lo was missing. 96560 965612022-10-19 Jedidiah Thompson <wej22007@outlook.com> 96562 Jedidiah Thompson <wej22007@outlook.com> 96563 Zac Walker <zac.walker@linaro.org> 96564 96565 aarch64-pe support for LD, GAS and BFD 96566 Allows aarch64-pe to be targeted natively, not having to use objcopy to convert it from ELF to PE. 96567 Based on initial work by Jedidiah Thompson 96568 965692022-10-19 rupesh potharla <rupesh.potharla@amd.com> 96570 96571 Binutils: Adding new testcase for addr2line. 96572 * binutils/testsuite/config/default.exp: Set ADDR2LINE and ADDR2LINEFLAGS. 96573 * binutils/testsuite/binutils-all/addr2line.exp: New file. 96574 965752022-10-19 Tom de Vries <tdevries@suse.de> 96576 96577 [gdb/testsuite] Fix ERROR in gdb.python/py-breakpoint.exp 96578 With test-case gdb.python/py-breakpoint.exp I run into: 96579 ... 96580 (gdb) ERROR: tcl error sourcing gdb.python/py-breakpoint.exp. 96581 ERROR: can't read "skip_hw_watchpoint_tests_p": no such variable 96582 while executing 96583 "if {$skip_hw_watchpoint_tests_p} { 96584 gdb_test_no_output "set can-use-hw-watchpoints 0" "" 96585 }" 96586 ... 96587 96588 Fix this by adding the missing "global skip_hw_watchpoint_tests_p" in two 96589 procs. 96590 96591 Tested on x86_64-linux. 96592 965932022-10-19 Andreas Krebbel <krebbel@linux.ibm.com> 96594 96595 IBM zSystems: Issue error for *DBL relocs on misaligned symbols 96596 Relocs like PC32DBL require a right shift of the symbol value. There 96597 is no situation where dropping symbol value bits with the right shift 96598 is a good thing. Hence we now issue an error to detect such problems. 96599 966002022-10-19 Simon Marchi <simon.marchi@efficios.com> 96601 96602 gdb: check for groups with duplicate names in reggroups:add 96603 In the downstream ROCm GDB port, we would create multiple register 96604 groups with duplicate names. While it did not really hurt, it certainly 96605 wasn't the intent. And I don't think it ever makes sense to do so. 96606 96607 To catch these, change the assert in reggroups::add to check for 96608 duplicate names. It's no longer necessary to check for duplicate 96609 reggroup pointers, because adding the same group twice would be caught 96610 by the duplicate name check. 96611 96612 Change-Id: Id216a58acf91f1b314d3cba2d02de73656f8851d 96613 Approved-By: Tom Tromey <tom@tromey.com> 96614 966152022-10-19 GDB Administrator <gdbadmin@sourceware.org> 96616 96617 Automatic date update in version.in 96618 966192022-10-18 H.J. Lu <hjl.tools@gmail.com> 96620 96621 x86: Disable AVX-VNNI when disabling AVX2 96622 Since AVX-VNNI requires AVX2, disable AVX-VNNI when disabling AVX2. 96623 96624 * i386-gen.c (cpu_flag_init): Add CpuAVX_VNNI to 96625 CPU_ANY_AVX2_FLAGS. 96626 * i386-init.h: Regenerate. 96627 966282022-10-18 Tom Tromey <tom@tromey.com> 96629 96630 Remove dead code from py-finishbreakpoint.c 96631 PR python/16324 points out that comparing a frame id to null_frame_id 96632 can never succeed, and proposes simply removing the dead code. That 96633 is what this patch does. 96634 96635 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16324 96636 966372022-10-18 Carl Love <cel@us.ibm.com> 96638 96639 Update tests to use skip_hw_watchpoint_tests to test for HW watchpoint support. 96640 The hardware watchpoint check has been updated in a couple of recent 96641 patches. This patch updates the hardware watchpoint test in the remaining 96642 gdb tests. 96643 96644 The issue is the PowerPC processors support hardware watchpoints with the 96645 exception of Power 9. The hardware watchpoint support is disabled on 96646 Power 9. The test skip_hw_watchpoint_tests must be used to correctly 96647 determine if the PowerPC processor supports hardware watchpoints. 96648 96649 This patch fixes 6 test failures in test gdb.threads/watchpoint-fork.exp. 96650 96651 Test gdb.base/watch-vfork.exp runs with can-use-hw-watchpoints set to 96652 true and false. When the test is run with can-use-hw-watchpoints set to 96653 true, gdb just falls back to using software watchpoints. The 96654 patch reduces the number of expected passes by 2 since because it now 96655 only runs once with can-use-hw-watchpoints set to false. 96656 96657 Test gdb.mi/mi-watch.exp runs the test with argument hw and sw. If the 96658 argument is hw and hardware watchpoints are not supported the test exits. 96659 The number of expected passes is cut in half with the patch as it now only 96660 runs the test using software breakpoints. Previously the pass to use 96661 hardware watchpoints was not skipped and the test actually ran using 96662 software watchpoints. 96663 96664 The following tests run the same with and without the patch. The tests 96665 are supposed to execute the gdb command "set can-use-hw-watchpoints 0" if 96666 the processor does not support hardware bwatchpoints. However the command 96667 was not being executed and gdb was falling back to using software 96668 watchpoints since the Power 9 watchpoint resource check fails. With the 96669 patch, the tests now execute the command and the test runs using software 96670 watchpoints as it did previously. The tests are: 96671 96672 gdb.base/commands.exp 96673 gdb.base/cond-eval-mode.exp 96674 gdb.base/display.exp 96675 gdb.base/gdb11531.exp 96676 gdb.base/recurse.exp 96677 gdb.base/value-double-free.exp 96678 gdb.base/watch-bitfields.exp 96679 gdb.base/watch-cond-infcall.exp 96680 gdb.base/watch-cond.exp 96681 gdb.base/watchpoint-solib.exp 96682 gdb.base/watchpoints.exp 96683 96684 The following two tests are not supported on the Power 9 system used to 96685 test the changes. The patch does not change the tests results for these 96686 tests: 96687 96688 gdb.python/py-breakpoint.exp 96689 gdb.mi/mi-watch-nonstop.exp 96690 966912022-10-18 Tom de Vries <tdevries@suse.de> 96692 96693 [gdb/testsuite] Handle header files with local-remote-host.exp 96694 With test-case gdb.base/included.exp and host board local-remote-host.exp with 96695 tentative fix for PR29697 I run into: 96696 ... 96697 included.c:18:10: fatal error: included.h: No such file or directory 96698 #include "included.h" 96699 ^~~~~~~~~~~~ 96700 compilation terminated. 96701 ... 96702 96703 Fix this by adding the missing gdb_remote_download calls. 96704 96705 Likewise in a few other test-cases. 96706 96707 Tested on x86_64-linux. 96708 967092022-10-18 Tom de Vries <tdevries@suse.de> 96710 96711 [gdb/testsuite] Fix gdb.server/no-thread-db.exp with local-remote-host.exp 96712 With test-case gdb.server/no-thread-db.exp and host board local-remote-host.exp 96713 with a tentative fix for PR29697 I run into: 96714 ... 96715 (gdb) print foo^M 96716 Cannot find thread-local storage for Thread 29613.29613, executable file \ 96717 $HOME/no-thread-db:^M 96718 Remote target failed to process qGetTLSAddr request^M 96719 (gdb) FAIL: gdb.server/no-thread-db.exp: print foo 96720 ... 96721 96722 The regexp in the test-case expects the full $binfile pathname, but we have 96723 instead $HOME/no-thread-db. 96724 96725 Fix this by making the regexp less strict. 96726 96727 Tested on x86_64-linux. 96728 967292022-10-18 Tom de Vries <tdevries@suse.de> 96730 96731 [gdb/testsuite] Fix gdb.base/return-nodebug.exp with local-remote-host.exp 96732 With host board local-remote-host.exp and test-case 96733 gdb.base/return-nodebug.exp, I run into: 96734 ... 96735 Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never \ 96736 -DTYPE=signed\ char -c -g -o return-nodebug-signed-char0.o \ 96737 /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/return-nodebug.c \ 96738 (timeout = 300) 96739 builtin_spawn [open ...]^M 96740 gcc: error: char: No such file or directory 96741 ... 96742 96743 Avoid the quoting problem by not using spaces in the define. 96744 96745 Tested on x86_64-linux. 96746 967472022-10-18 Tom de Vries <tdevries@suse.de> 96748 96749 [gdb/testsuite] Fix gdb.server/file-transfer.exp with local-remote-host.exp 96750 When running test-case gdb.server/file-transfer.exp with host 96751 board local-remote-host.exp, I get: 96752 ... 96753 Executing on host: cmp -s $outputs/gdb.server/file-transfer/file-transfer \ 96754 down-server (timeout = 300) 96755 builtin_spawn [open ...]^M 96756 XYZ2ZYX 96757 FAIL: gdb.server/file-transfer.exp: compare intermediate binary file 96758 ... 96759 96760 The remote host and remote target cases are handled here together here in proc 96761 test_file_transfer: 96762 ... 96763 if {![is_remote host] && ![is_remote target]} { 96764 set up_server [standard_output_file $up_server] 96765 set down_server [standard_output_file $down_server] 96766 } 96767 ... 96768 96769 Fix this by handling them separately. 96770 96771 Tested on x86_64-linux. 96772 967732022-10-18 Tom de Vries <tdevries@suse.de> 96774 96775 [gdb/testsuite] Update boards/README 96776 Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d 96777 ("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which 96778 means the board now uses a pseudo-tty, but with editing disabled. 96779 967802022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96781 96782 gdb, solib-svr4: support namespaces in DSO iteration 96783 When looking up names, GDB needs to stay within one linker namespace to 96784 find the correct instance in case the same name is provided in more than 96785 one namespace. 96786 96787 Modify svr4_iterate_over_objfiles_in_search_order() to stay within the 96788 namespace of the current_objfile argument. If no current_objfile is 96789 provided (i.e. it is nullptr), iterate over objfiles in the initial 96790 namespace. 96791 96792 For objfiles that do not have a corresponding so_list to provide the 96793 namespace, assume that the objfile was loaded into the initial namespace. 96794 This would cover the main executable objfile (which is indeed loaded into 96795 the initial namespace) as well as manually added symbol files. 96796 96797 Expected fails: 96798 96799 - gdb.base/non-lazy-array-index.exp: the expression parser may lookup 96800 global symbols, which may result in xfers to read auxv for determining 96801 the debug base as part of svr4_iterate_over_objfiles_in_search_order(). 96802 96803 - gdb.server/non-lazy-array-index.exp: symbol lookup may access the 96804 target to read AUXV in order to determine the debug base for SVR4 96805 linker namespaces. 96806 96807 Known issues: 96808 96809 - get_symbol_address() and get_msymbol_address() search objfiles for a 96810 'better' match. This was introduced by 96811 96812 4b610737f02 Handle copy relocations 96813 96814 to handle copy relocations but it now causes a wrong address to be 96815 read after symbol lookup actually cound the correct symbol. This can 96816 be seen, for example, with gdb.base/dlmopen.exp when compiled with 96817 clang. 96818 96819 - gnu ifuncs are only looked up in the initial namespace. 96820 96821 - lookup_minimal_symbol() and lookup_minimal_symbol_text() directly 96822 iterate over objfiles and are not aware of linker namespaces. 96823 968242022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96825 96826 gdb: update gnu ifunc resolve 96827 Update elf_gnu_ifunc_resolve_by_cache() and elf_gnu_ifunc_resolve_by_got() 96828 to use gdbarch_iterate_over_objfiles_in_search_order() in order to 96829 restrict the objfile traversal to the initial namespace. 96830 96831 In order to extend this to other namespaces, we'd need to provide context, 96832 e.g. via an objfile inside that namespace. 96833 968342022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96835 96836 gdb, symtab: inline find_quick_global_symbol_language 96837 There is only one use of find_quick_global_symbol_language that calls it 96838 for the special symbol "main". 96839 96840 Inline the function as it is probably not correct in the general case 96841 where we may have multiple instances of global symbols with the same name 96842 but different languages in different libraries in different linker 96843 namespaces. 96844 96845 Further, change the objfiles iteration into a call to 96846 gdbarch_iterate_over_objfiles_in_search_order, which would only search the 96847 initial linker namespace, where we expect "main" to be located. 96848 968492022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96850 96851 gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol 96852 I stumbled over this while reviewing all objfiles traversals with regards 96853 to impact of linker namespaces. 96854 96855 Recursive grep only finds two occurrences of hppa_lookup_stub_minimal_symbol: 96856 - the declaration in hppa-tdep.h. 96857 - the definition in hppa-tdep.c. 96858 96859 There appear to be no calls to this function. Remove it. 96860 968612022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96862 96863 gdb, cp: update add_symbol_overload_list_qualified 96864 Iterate over objfiles in search order using the objfile of the selected 96865 block as current_objfile so the iteration can stay inside the block's 96866 linker namespace. 96867 96868 fixup! gdb, ada: update ada_lookup_simple_minsym 96869 remove get_selected_block() 96870 96871 gdb, ada: update ada_lookup_simple_minsym 96872 Iterate over objfile in search order using the objfile of the context 96873 block as current_objfile so the iteration can stay inside the block's 96874 linker namespace. 96875 96876 gdb, ada: collect standard exceptions in all objfiles 96877 When searching for standard exceptions for Ada, we lookup the minimal 96878 symbol of each exception. With linker namespaces there can be multiple 96879 instances in different namespaces. Collect them all. 96880 968812022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96882 96883 gdb, python: use gdbarch_iterate_over_objfiles_in_search_order 96884 The implementation of gdb.lookup_objfile() iterates over all objfiles and 96885 compares their name or build id to the user-provided search string. 96886 96887 This will cause problems when supporting linker namespaces as the first 96888 objfile in any namespace will be found. Instead, use 96889 gdbarch_iterate_over_objfiles_in_search_order to only consider the 96890 namespace of gdb.current_objfile() for the search, which defaults to the 96891 initial namespace when gdb.current_objfile() is None. 96892 968932022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96894 96895 gdb, compile: unlink objfile stored in module 96896 When cleaning up after a compile command, we iterate over all objfiles and 96897 unlink the first objfile with the same name as the one we compiled. 96898 96899 Since we already store a pointer to that objfile in the module and use it 96900 to get the name we're comparing against, there's no reason to iterate, at 96901 all. We can simply use that objfile. 96902 96903 This further avoids potential issues when an objfile with the same name is 96904 loaded into a different linker namespace. 96905 969062022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96907 96908 gdb, gdbserver: extend RSP to support namespaces 96909 Introduce a new qXfer:libraries-svr4:read annex key/value pair 96910 96911 lmid=<namespace identifier> 96912 96913 to be used together with start and prev to provide the namespace of start 96914 and prev to gdbserver. 96915 96916 Unknown key/value pairs are ignored by gdbserver so no new supports check 96917 is needed. 96918 96919 Introduce a new library-list-svr4 library attribute 96920 96921 lmid 96922 96923 to provide the namespace of a library entry to GDB. 96924 96925 This implementation uses the address of a namespace's r_debug object as 96926 namespace identifier. 96927 96928 This should have incremented the minor version but since unknown XML 96929 attributes are ignored, anyway, and since changing the version results in 96930 a warning from GDB, the version is left at 1.0. 96931 969322022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96933 96934 gdbserver: move main_lm handling into caller 96935 When listing SVR4 shared libraries, special care has to be taken about the 96936 first library in the default namespace as that refers to the main 96937 executable. The load map address of this main executable is provided in 96938 an attribute of the library-list-svr4 element. 96939 96940 Move that code from where we enumerate libraries inside a single namespace 96941 to where we generate the rest of the library-list-svr4 element. This 96942 allows us to complete the library-list-svr4 element inside one function. 96943 96944 There should be no functional change. 96945 969462022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96947 Lu, Hongjiu <hongjiu.lu@intel.com> 96948 96949 gdb, gdbserver: support dlmopen() 96950 In glibc, the r_debug structure contains (amongst others) the following 96951 fields: 96952 96953 int r_version: 96954 Version number for this protocol. It should be greater than 0. 96955 96956 If r_version is 2, struct r_debug is extended to struct r_debug_extended 96957 with one additional field: 96958 96959 struct r_debug_extended *r_next; 96960 Link to the next r_debug_extended structure. Each r_debug_extended 96961 structure represents a different namespace. The first r_debug_extended 96962 structure is for the default namespace. 96963 96964 1. Change solib_svr4_r_map argument to take the debug base. 96965 2. Add solib_svr4_r_next to find the link map in the next namespace from 96966 the r_next field. 96967 3. Update svr4_current_sos_direct to get the link map in the next namespace 96968 from the r_next field. 96969 4. Don't check shared libraries in other namespaces when updating shared 96970 libraries in a new namespace. 96971 5. Update svr4_same to check the load offset in addition to the name 96972 6. Update svr4_default_sos to also set l_addr_inferior 96973 7. Change the flat solib_list into a per-namespace list using the 96974 namespace's r_debug address to identify the namespace. 96975 96976 Add gdb.base/dlmopen.exp to test this. 96977 96978 To remain backwards compatible with older gdbserver, we reserve the 96979 namespace zero for a flat list of solibs from all namespaces. Subsequent 96980 patches will extend RSP to allow listing libraries grouped by namespace. 96981 96982 This fixes PR 11839. 96983 969842022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96985 96986 gdb, solib-svr4: remove locate_base() 96987 Whenever we call locate_base(), we clear info->debug_base directly before 96988 the call. Thus, we never cache the base location as locate_base() had 96989 intended. 96990 96991 Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline 96992 locate_base() at all call sites, and remove it. 96993 969942022-10-18 Markus Metzger <markus.t.metzger@intel.com> 96995 96996 gdb, testsuite: extend gdb_test_multiple checks 96997 Check for 96998 96999 warning: Corrupted shared library list 97000 97001 and for 97002 97003 Invalid cast. 97004 warning: Probes-based dynamic linker interface failed. 97005 Reverting to original interface. 97006 97007 in gdb_test_multiple. 97008 970092022-10-18 Jan Beulich <jbeulich@suse.com> 97010 97011 x86: generalize gas documentation for disabling of ISA extensions 97012 As of commit ae89daecb132 ("x86: generalize disabling of sub- 97013 architectures") there's no arbitrary subset of ISAs which can also be 97014 disabled. This should have been reflected in documentation right away. 97015 Since I failed to do so, correct this now. 97016 97017 x86: correct CPU_AMX_{BF16,INT8}_FLAGS 97018 AMX-TILE is a prereq to these, as already correctly expressed by 97019 CPU_ANY_AMX_TILE_FLAGS. Express the dependency also in the reverse 97020 ("positive") direction. 97021 970222022-10-18 GDB Administrator <gdbadmin@sourceware.org> 97023 97024 Automatic date update in version.in 97025 970262022-10-17 Tom Tromey <tromey@adacore.com> 97027 97028 kfail an Ada test for GCC < 12 97029 I noticed one particular Ada test was failing on Fedora 34, but works 97030 when I switch to GCC 12. This patch arranges to kfail the test when 97031 an older compiler is used. 97032 97033 I tested this with GCC 11, 12, and 13. I'm going to check it in. 97034 970352022-10-17 Tom Tromey <tromey@adacore.com> 97036 97037 Remove a nullptr check in DWARF scanner 97038 In scan_attributes, The DWARF scanner checks whether maybe_defer is 97039 nullptr, but this can never happen. This patch removes the check. 97040 970412022-10-17 Pedro Alves <pedro@palves.net> 97042 97043 gdbarch-components.py: Remove spurious space from "frame_info_ptr " params 97044 If you run gdbarch.py today, you'll get local modifications compared 97045 to what's in the tree, like: 97046 97047 --- c/gdb/gdbarch-gen.h 97048 +++ w/gdb/gdbarch-gen.h 97049 @@ -315,8 +315,8 @@ extern void set_gdbarch_register_type (struct gdbarch *gdbarch, gdbarch_register 97050 should match the address at which the breakpoint was set in the dummy 97051 frame. */ 97052 97053 -typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame); 97054 -extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame); 97055 +typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame); 97056 +extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame); 97057 extern void set_gdbarch_dummy_id (struct gdbarch *gdbarch, gdbarch_dummy_id_ftype *dummy_id); 97058 97059 etc. 97060 97061 The extra space comes from the "frame_info_ptr " param that appears in 97062 a number of gdbarch methods in gdbarch-components.py. With the extra 97063 space removed, running ./gdbarch.py generates the exact code that's in 97064 the tree already. 97065 97066 Change-Id: If7d20b8c6b2fd9ff466142a01bd2611c9ef9f53e 97067 970682022-10-17 Tom Tromey <tromey@adacore.com> 97069 97070 Change .gdb_index de-duplication implementation 97071 While investigating PR symtab/29179, I found that one Ada test failed 97072 because, although a certain symbol was present in the index, with the 97073 new DWARF reader it pointed to a different CU than was chosen by 97074 earlier versions of gdb. 97075 97076 This patch changes how symbol de-duplication is done, deferring the 97077 process until the entire symbol table has been constructed. This way, 97078 it's possible to always choose the lower-numbered CU among duplicates, 97079 which is how gdb (implicitly) previously worked. 97080 97081 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179 97082 970832022-10-17 Tom Tromey <tromey@adacore.com> 97084 97085 Improve Ada support in .gdb_index 97086 The cooked index work changed how .gdb_index is constructed, and in 97087 the process broke .gdb_index support. This is PR symtab/29179. 97088 97089 This patch partially fixes the problem. It arranges for Ada names to 97090 be encoded in the form expected by the index code. In particular, 97091 linkage names for Ada are emitted, including the "main" name; names 97092 are Ada-encoded; and names are no longer case-folded, something that 97093 prevented operator names from round-tripping correctly. 97094 97095 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179 97096 970972022-10-17 Tom Tromey <tromey@adacore.com> 97098 97099 Don't add type linkage names to cooked index 97100 The compiler will sometimes emit a linkage name for a type, like: 97101 97102 <1d3> DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t 97103 97104 These names aren't very useful, and this patch changes the DWARF 97105 reader so that they are ignored by the cooked index. 97106 971072022-10-17 Tom Tromey <tromey@adacore.com> 97108 97109 Fix regression in c-linkage-name.exp with gdb index 97110 c-linkage-name.exp started failing with the gdb-index target board due 97111 to an earlier patch. The problem here is that some linkage names must 97112 be in the index -- but, based on inspection, not C++ linkage names. 97113 This patch updates the code to exclude only these. 97114 971152022-10-17 TaiseiIto <taisei1212@outlook.jp> 97116 97117 Fix null pointer representations 97118 Since "NULL" and "0" are used to represent invalid address in function 97119 "gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified 97120 them to "nullptr". 97121 971222022-10-17 Simon Marchi <simon.marchi@efficios.com> 97123 97124 gdb: silence unused-but-set-variable warning about yynerrs in cp-name-parser.y 97125 When building with clang 15 on Ubuntu 20.04, I get: 97126 97127 CXX cp-name-parser.o 97128 cp-name-parser.c.tmp:1777:9: error: variable 'cpnameyynerrs' set but not used [-Werror,-Wunused-but-set-variable] 97129 int yynerrs; 97130 ^ 97131 /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:58:18: note: expanded from macro 'yynerrs' 97132 #define yynerrs GDB_YY_REMAP (yynerrs) 97133 ^ 97134 /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:40:29: note: expanded from macro 'GDB_YY_REMAP' 97135 #define GDB_YY_REMAP(YYSYM) GDB_YY_REMAP_1 (GDB_YY_REMAP_PREFIX, YYSYM) 97136 ^ 97137 /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:39:39: note: expanded from macro 'GDB_YY_REMAP_1' 97138 #define GDB_YY_REMAP_1(PREFIX, YYSYM) GDB_YY_REMAP_2 (PREFIX, YYSYM) 97139 ^ 97140 /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:38:39: note: expanded from macro 'GDB_YY_REMAP_2' 97141 #define GDB_YY_REMAP_2(PREFIX, YYSYM) PREFIX ## YYSYM 97142 ^ 97143 <scratch space>:45:1: note: expanded from here 97144 cpnameyynerrs 97145 ^ 97146 97147 This is because clang 15 warns for something like this: 97148 97149 int n; 97150 n = 0; 97151 ++n; 97152 97153 whereas previous versions do not. 97154 97155 yynerrs is defined in yyparse and is there for actions to use. Since 97156 the actions in cp-name-parser.y don't use it, we get a warning. We see 97157 this problem on this particular .y file because it uses `%pure-parser` 97158 [1], which makes yynerrs a local rather than a global. 97159 97160 I initially fixed this by using 97161 DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE (like in commit f7aa1a5acc5 97162 ("gold: Suppress "unused" variable warning on Clang")), but then I 97163 realized we could suppress the warning in a more fine-grained way using 97164 this in a rule: 97165 97166 (void) yynerrs; 97167 97168 [1] https://www.gnu.org/software/bison/manual/html_node/Error-Reporting-Function.html 97169 97170 Change-Id: I6cae7a4207c19fe1b719e2ac19be69122ebe3af1 97171 971722022-10-17 Clément Chigot <chigot@adacore.com> 97173 97174 ld/testsuite: consistently add board_ldflags when linking with GCC 97175 Currently, the functions checking if the compiler is available or if a 97176 feature is available add both board_cflags and board_ldflags. 97177 However, functions running the tests only retrieve board_cflags. This 97178 can lead to unexpected errors when mandaratory flags are defined in 97179 board_ldflags and not board_cflags. 97180 97181 ld/ChangeLog: 97182 97183 * testsuite/ld-unique/unique.exp: Add board_ldflags when 97184 linking with GCC. 97185 * testsuite/lib/ld-lib.exp: Likewise. 97186 971872022-10-17 CaiJingtao <caijingtao@huawei.com> 97188 97189 Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp} 97190 Omitting predicate size specifier in vector form of {sq, uq, }{decp, incp} is deprecated and will be prohibited in a future release of the aarch64, 97191 see https://developer.arm.com/documentation/ddi0602/2021-09/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-. 97192 97193 This allows explicit size specifier, e.g. `decp z0.h, p0.h`, for predicate operand of these SVE instructions. 97194 The existing behaviour of not requiring the specifier is preserved. 97195 And the disasembly is with the specifier with this patch. 97196 97197 The GAS tests passed under our local tests. 97198 97199 opcodes/ 97200 * aarch64-asm.c: Modify `sve_size_hsd` encoding. 97201 * aarch64-tbl.h (aarch64_opcode_table): Add QUALS's type OP_SVE_Vv_HSD 97202 for decp, incp, sqdecp, sqincp, uqdecp and uqincp. 97203 97204 gas/ 97205 * testsuite/gas/aarch64/sve-movprfx_23.s: Update movprfx_23 testcase's 97206 test_sametwo macro, where take the predicate size specifier. 97207 * testsuite/gas/aarch64/sve-movprfx_23.d: Update movprfx_23 testcase's 97208 expected disassembly. 97209 * testsuite/gas/aarch64/sve-movprfx_23.l: Update movprfx_23 testcase's 97210 expected assembler messages. 97211 * testsuite/gas/aarch64/sve.s: Add sve testcase's instructions for 97212 decp, incp, sqdecp, sqincp, uqdecp and uqincp, which take the 97213 predicate size specifier. 97214 * testsuite/gas/aarch64/sve.d: Update sve testcase's expected 97215 disassembly. 97216 972172022-10-17 Richard Sandiford <richard.sandiford@arm.com> 97218 97219 aarch64: Tweak handling of F_STRICT 97220 Current F_STRICT qualifier checking is enforced after the fact 97221 rather than as part of the match. This makes it impossible to 97222 have, e.g.: 97223 97224 QLF2(S_D, S_D) 97225 QLF2(S_D, NIL) 97226 97227 in the same list. 97228 97229 opcodes/ 97230 * aarch64-opc.c (aarch64_find_best_match): Handle F_STRICT here 97231 rather than... 97232 (match_operands_qualifier): ...here. 97233 972342022-10-17 Jan Beulich <jbeulich@suse.com> 97235 97236 x86: properly decode EVEX.W for AVX512_4{FMAPS,VNNIW} insns 97237 These require EVEX.W=0. Use %XS to facilitate the checking, even if for 97238 the AVX512_4VNNIW ones this is kind of an abuse (as 's' there stands for 97239 "signed", not "single"). 97240 97241 While there also correct the 3rd operand for the AVX512_4VNNIW entries: 97242 Only the memory form is allowed (just like for AVX512_4FMAPS, where the 97243 correct type is already in use). 97244 972452022-10-17 Jan Beulich <jbeulich@suse.com> 97246 97247 x86: fold AVX512-VNNI disassembler entries with AVX-VNNI ones 97248 Make %XV also print the separating blank in the VEX case, while making 97249 it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries 97250 can be re-used for AVX512-VNNI, at the same time fixing the lack of 97251 EVEX.W decoding. 97252 97253 For the AVX-VNNI ones further make sure only VEX.66 forms are actually 97254 decoded. 97255 972562022-10-17 GDB Administrator <gdbadmin@sourceware.org> 97257 97258 Automatic date update in version.in 97259 972602022-10-16 Tom Tromey <tom@tromey.com> 97261 97262 More uses of checked_static_cast 97263 This patch changes a few more uses of static_cast to use 97264 checked_static_cast. In this patch, cast-to-references are converted 97265 by moving the dereference outside of the cast, as checked_static_cast 97266 only handles pointers. 97267 972682022-10-16 Tom Tromey <tom@tromey.com> 97269 97270 Use checked_static_cast in more places 97271 I looked through all the uses of static_cast<... *> in gdb and 97272 converted many of them to checked_static_cast. 97273 97274 I couldn't test a few of these changes. 97275 972762022-10-16 Alan Modra <amodra@gmail.com> 97277 97278 PowerPC se_rfmci and VLE, SPE2 and LSP insns with -many 97279 I noticed recently that se_rfmci, a VLE mode instruction, was being 97280 accepted by non-VLE cpus, and also that se_rfmci by itself in a 97281 section did not cause SHF_PPC_VLE to be set. ie. both testcases added 97282 by this patch fail without the changes to tc-ppc.c here. 97283 97284 Also, VLE, SPE2 and LSP insns were not accepted by the assembler with 97285 -many nor were SPE2 and LSP being disassembled with -Many. 97286 97287 gas/ 97288 * config/tc-ppc.c (ppc_setup_opcodes): Wrap long lines. Add 97289 vle_opcodes when PPC_OPCODE_VLE or PPC_OPCODE_ANY. Simplify 97290 disassembler index segment checks. Add LSP and SPE2 opcodes 97291 when PPC_OPCODE_ANY too. 97292 (md_assemble): Correct logic adding PPC_APUINFO_VLE and 97293 SHF_PPC_VLE. 97294 * testsuite/gas/ppc/se_rfmci.s 97295 * testsuite/gas/ppc/se_rfmci.d, 97296 * testsuite/gas/ppc/se_rfmci_bad.d: New tests. 97297 * testsuite/gas/ppc/ppc.exp: Run them. 97298 opcodes/ 97299 * ppc-dis.c (print_insn_powerpc): Disassemble SPE2 and LSP insn 97300 when -Many. 97301 * ppc-opc.c (vle_opcodes <se_rfmci>): Comment. 97302 973032022-10-16 Alan Modra <amodra@gmail.com> 97304 97305 zlib-gabi to zstd woes 97306 So we had a zlib-gabi .debug_info section that increased in size with 97307 zstd, so much so that it was better to leave the section 97308 uncompressed. Things went horribly wrong when the section was read 97309 again later. The section was read again off disk using the 97310 uncompressed size. So you get the zlib section again with some 97311 garbage at the end. Fix that particular problem by setting the 97312 section flag SEC_IN_MEMORY. Any future read will get sec->contents. 97313 97314 Also, if the section is to be left uncompressed, the input 97315 SHF_COMPRESSED flag needs to be reset otherwise objcopy will copy it 97316 to output. 97317 97318 Finally, bfd_convert_section_contents needed a small update to handle 97319 zstd compressed sections, and I've deleted bfd_cache_section_contents. 97320 97321 * bfd.c (bfd_convert_section_contents): Handle zstd. 97322 * compress.c (bfd_compress_section_contents): When section 97323 contents are uncompressed set SEC_IN_MEMORY flag, 97324 compress_status to COMRESS_SECTION_NONE, and clear 97325 SHF_COMPRESSED. Set SEC_IN_MEMORY for compressed contents. 97326 (bfd_get_full_section_contents): Don't check section size 97327 against file size when SEC_IN_MEMORY. 97328 (bfd_cache_section_contents): Delete function. 97329 * elf32-arm.c (elf32_arm_get_synthetic_symtab): Expand 97330 bfd_cache_section_contents here. 97331 * bfd-in2.h: Regenerate. 97332 973332022-10-16 GDB Administrator <gdbadmin@sourceware.org> 97334 97335 Automatic date update in version.in 97336 973372022-10-15 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 97338 97339 gdb/arm: Don't rely on loop detection to stop unwinding 97340 Setting SP of the next frame to the same address as the current frame 97341 is an ugly way to stop the unwinding. A cleaner way is to rely on 97342 the frame_unwind_stop_reason function to return UNWIND_OUTERMOST. 97343 973442022-10-15 GDB Administrator <gdbadmin@sourceware.org> 97345 97346 Automatic date update in version.in 97347 973482022-10-14 Tom de Vries <tdevries@suse.de> 97349 97350 [gdb/testsuite] Add boards/README 97351 Add a file gdb/testsuite/boards/README, to make it easier to get a high-level 97352 overview of the various boards. 97353 973542022-10-14 Tom de Vries <tdevries@suse.de> 97355 97356 [gdb/contrib] Handle STRIP_ARGS_{STRIP,KEEP}_DEBUG in cc-with-tweaks.sh 97357 Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to 97358 --strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily 97359 reproduce the PR29277 assert using: 97360 ... 97361 $ export STRIP_ARGS_STRIP_DEBUG=--strip-all 97362 $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \ 97363 --target_board cc-with-gnu-debuglink" 97364 ... 97365 97366 For completeness sake and to avoid confusion about which of the two used strip 97367 invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG, 97368 defaulting to --only-keep-debug. 97369 97370 Script checked with shellcheck, no new warnings added. 97371 97372 Tested on x86_64-linux. 97373 973742022-10-14 Tom de Vries <tdevries@suse.de> 97375 97376 [gdb] Fix heap-buffer-overflow in find_program_interpreter 97377 With the test-case included in this patch, we run into: 97378 ... 97379 (gdb) target remote localhost:2347^M 97380 `target:twice-connect' has disappeared; keeping its symbols.^M 97381 Remote debugging using localhost:2347^M 97382 warning: Unable to find dynamic linker breakpoint function.^M 97383 GDB will be unable to debug shared library initializers^M 97384 and track explicitly loaded dynamic code.^M 97385 Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M 97386 0x00007ffff7dd4550 in ?? ()^M 97387 (gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started 97388 FAIL: gdb.server/twice-connect.exp: found interpreter 97389 ... 97390 97391 The problem originates in find_program_interpreter, where 97392 bfd_get_section_contents is called to read .interp, but fails. The function 97393 returns false but the result is ignored, so find_program_interpreter returns 97394 some random string. 97395 97396 Fix this by checking the result of the call to bfd_get_section_contents. 97397 97398 Tested on x86_64-linux. 97399 97400 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652 97401 974022022-10-14 Tom de Vries <tdevries@suse.de> 97403 97404 [gdb/testsuite] Fix gdb.server/unittest.exp with host board local-remote-host.exp 97405 With test-case gdb.server/unittest.exp and host board local-remote-host.exp I 97406 run into: 97407 ... 97408 builtin_spawn build/gdbserver/gdbserver --selftest^M 97409 ERROR: : spawn id exp7 not open 97410 while executing 97411 "expect { 97412 -i exp7 -timeout 10 97413 -i $server_spawn_id 97414 -re "Ran ($decimal) unit tests, 0 failed" { 97415 set num_ran $expect_out(1,string) 97416 gdb_assert "..." 97417 ("uplevel" body line 1) 97418 invoked from within 97419 "uplevel $body" NONE : spawn id exp7 not open 97420 UNRESOLVED: gdb.server/unittest.exp: unit tests 97421 ... 97422 97423 The problem is (as fixed for avr in commit df5b8876083 ("gdb/testsuite: better 97424 handle failures in simavr board, reap simavr process")), that gdb_expect through 97425 remote_expect adds a "-i <gdb spawn id> -timeout 10", which is the one causing 97426 the error. 97427 97428 As in aforementioned commit, fix this by using expect instead. 97429 97430 Tested on x86_64-linux. 97431 974322022-10-14 Tom de Vries <tdevries@suse.de> 97433 97434 [gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts 97435 With test-case gdb.server/stop-reply-no-thread-multi.exp and host board 97436 local-remote-host-notty.exp we occasionally run into a silent out, due to 97437 getting: 97438 ... 97439 (gdb) kill^M 97440 (gdb) The program is not being run.^M 97441 ... 97442 instead of the expected: 97443 ... 97444 (gdb) kill^M 97445 The program is not being run.^M 97446 (gdb) 97447 ... 97448 97449 Likewise, we occasionally run into a nonsilent timeout: 97450 ... 97451 (gdb) disconnect^M 97452 (gdb) You can't do that when your target is `exec'^M 97453 FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \ 97454 disconnect (timeout) 97455 ... 97456 97457 Typically, this results in the test-case taking more than two minutes to run. 97458 97459 The problem can be reproduced using just: 97460 ... 97461 $ ssh -l $USER 127.0.0.1 gdb -q -ex kill 97462 ... 97463 97464 Note that ssh by default uses -T which disables pseudo-tty allocation (as 97465 opposed to -t which forces pseudo-tty allocation): 97466 ... 97467 $ ssh -l $USER 127.0.0.1 -T tty 97468 not a tty 97469 $ ssh -l $USER 127.0.0.1 -t tty 97470 /dev/pts/5 97471 Connection to 127.0.0.1 closed. 97472 ... 97473 and according to https://stackoverflow.com/a/63241102 the behaviour we're 97474 seeing is specific to using '-T'. 97475 97476 The related host board local-remote-host.exp does use '-t', and the only 97477 difference between the two boards mentioned is whether editing is on or off. 97478 97479 Fix this by: 97480 - moving the content of local-remote-host-notty.exp into 97481 local-remote-host.exp 97482 - consequently, extending the copyright years in local-remote-host.exp 97483 - including local-remote-host.exp in local-remote-host-notty.exp 97484 (making local-remote-host-notty.exp use '-t') 97485 - adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp 97486 97487 This results in the test-case taking just 6 seconds to run. 97488 97489 Tested on x86_64-linux. 97490 97491 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669 97492 974932022-10-14 Tom de Vries <tdevries@suse.de> 97494 97495 [gdb/testsuite] Disable styling in host board local-remote-host.exp 97496 With test-case gdb.server/stop-reply-no-thread.exp and host board 97497 local-remote-host.exp, I run into: 97498 ... 97499 Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M 97500 21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M 97501 (gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \ 97502 continue to main 97503 ... 97504 97505 The problem is that styling is enabled, and that is causing a regexp mismatch. 97506 97507 With native, styling is disabled in default_gdb_init by doing 97508 'setenv TERM "dumb"', but that only has effect because the build (where we 97509 execute runtest, and consequently the setenv) and the host (where we execute 97510 gdb) are the same. For this host board however, gdb executes on a remote 97511 host, and the setenv has no effect. 97512 97513 We could try to make some generic way to set TERM on the host, but for the 97514 purposes of this test-case it seems sufficient to just add: 97515 ... 97516 set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\"" 97517 ... 97518 so let's go with that for now. 97519 97520 Tested on x86_64-linux. 97521 975222022-10-14 Tom Tromey <tromey@adacore.com> 97523 97524 Use scoped_value_mark in more places 97525 I looked at all the spots using value_mark, and converted all the 97526 straightforward ones to use scoped_value_mark instead. 97527 97528 Regression tested on x86-64 Fedora 34. 97529 975302022-10-14 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 97531 97532 gdb/arm: Stop unwinding on error, but do not assert 97533 When it's impossible to read the FPCCR and XPSR, the unwinding is 97534 unpredictable as the it's not possible to determine the correct 97535 frame size or padding. 97536 The only sane thing to do in this condition is to stop the unwinding. 97537 97538 Example session without this patch: 97539 97540 (gdb) bt 97541 #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112 97542 .../gdb/arm-tdep.c:3594: internal-error: arm_m_exception_cache: Assertion `safe_read_memory_unsigned_integer (FPCCR, ARM_INT_REGISTER_SIZE, byte_order, &fpccr)' failed. 97543 A problem internal to GDB has been detected, 97544 further debugging may prove unreliable. 97545 ----- Backtrace ----- 97546 0x5583bfb2a157 gdb_internal_backtrace_1 97547 ... 97548 --------------------- 97549 97550 This is a bug, please report it. For instructions, see: 97551 <https://www.gnu.org/software/gdb/bugs/>. 97552 97553 Aborted (core dumped) 97554 97555 Example session with this patch: 97556 97557 (gdb) bt 97558 #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112 97559 warning: Could not fetch required FPCCR content. Further unwind is impossible. 97560 #1 <signal handler called> 97561 (gdb) 97562 97563 Reviewed-by: Pedro Alves <pedro@palves.net> 97564 975652022-10-14 Alan Modra <amodra@gmail.com> 97566 97567 PowerPC SPE disassembly and tests 97568 Where sub and subf forms of an instruction exist we generally 97569 disassemble to the extended insn sub form rather than the underlying 97570 machine subf instruction. Do so for SPE evsubw and evsubiw too. 97571 97572 spe_ambiguous.d always was a bit too optimistic. There is no sensible 97573 way to disassemble identical bytes back to different and original 97574 source. Instead change the test to check -Mraw results. 97575 97576 gas/ 97577 * testsuite/gas/ppc/ppc.exp: Run spe_ambiguous test. 97578 * testsuite/gas/ppc/spe.d: Expect evsubw and evsubiw rather than 97579 evsubfw and evsubifw. 97580 * testsuite/gas/ppc/spe_ambiguous.s: Test evnor form equivalent 97581 to evnot. 97582 * testsuite/gas/ppc/spe_ambiguous.d: Test Mraw. 97583 opcodes/ 97584 * ppc-opc.c (powerpc_opcodes): Move evsubw before evsubfw and 97585 evsubiw before evsubifw and mark EXT. 97586 975872022-10-14 Alan Modra <amodra@gmail.com> 97588 97589 e200 LSP support 97590 It has bothered me for a long time that we have disabled LSP (and SPE) 97591 tests. Also the LSP test comment indicating there is something wrong 97592 with get_powerpc_dialect. I don't think there is. Decoding of a VLE 97593 instruction depends on whether the processor is in VLE mode (some 97594 processors support both VLE and standard PPC) which we flag per 97595 section with SHF_PPC_VLE for decoding when disassembling. 97596 97597 Background: Some versions of powerpc e200 have "Lightweight Signal 97598 Processing" support, examples being e200z215 and e200z425. As far as 97599 I can tell, LSP and SPE are mutually exclusive. This seems to be 97600 borne out by insn encoding, for example LSP "zvaddih" and SPE "evaddw" 97601 have the same encoding. So none of the processor descriptions in 97602 ppc_opts ought to have both PPC_OPCODE_LSP and PPC_OPCODE_SPE/2, if we 97603 want disassembly to work. I also could not find anything to suggest 97604 that the LSP insns are enabled only in VLE mode, which means the LSP 97605 insns should not be in vle_opcodes. 97606 97607 Fix all this by moving the LSP insns to their own table, and add a new 97608 e200z2 cpu entry with LSP support, removing LSP from -me200z4 and from 97609 -mvle. (Yes, I know, as I said above some of the e200z4 processors 97610 have LSP. Others have SPE. It's hard to choose good options. Think 97611 of z2 as meaning earlier, z4 as later.) Also add -mlsp to allow 97612 adding the LSP insn set. 97613 97614 include/ 97615 * opcode/ppc.h (lsp_opcodes, lsp_num_opcodes): Declare. 97616 (LSP_OP_TO_SEG): Define. 97617 binutils/ 97618 * doc/binutils.texi: Update ppc docs. 97619 gas/ 97620 * config/tc-ppc.c (ppc_setup_opcodes): Add lsp opcodes to ppc_hash. 97621 * doc/c-ppc.texi: Document e200 and lsp. 97622 * testsuite/gas/ppc/lsp-checks.d: Assemble with -me200z2. 97623 * testsuite/gas/ppc/lsp.d: Likewise, disassembly too. 97624 * testsuite/gas/ppc/ppc.exp: Don't xfail lsp test. 97625 opcodes/ 97626 * ppc-dis.c (ppc_opts): Add e200z2 and lsp. Don't set 97627 PPC_OPCODE_LSP for e200z4 or vle. 97628 (ppc_parse_cpu): Mutually exclude LSP and SPE. 97629 (LSP_OPCD_SEGS): Define. 97630 (lsp_opcd_indices): New array. 97631 (disassemble_init_powerpc): Init lsp_opcd_indices. 97632 (lookup_lsp): New function. 97633 (print_insn_powerpc): Call it. 97634 * ppc-opc.c: Include libiberty.h for ARRAY_SIZE and use throughout. 97635 (vle_opcodes): Move LSP opcodes to.. 97636 (lsp_opcodes): ..here, and sort. 97637 (lsp_num_opcodes): New. 97638 976392022-10-14 Alan Modra <amodra@gmail.com> 97640 97641 PR29677, Field `the_bfd` of `asymbol` is uninitialised 97642 Besides not initialising the_bfd of synthetic symbols, counting 97643 symbols when sizing didn't match symbols created if there were any 97644 dynsyms named "". We don't want synthetic symbols without names 97645 anyway, so get rid of them. Also, simplify and correct sanity checks. 97646 97647 PR 29677 97648 * mach-o.c (bfd_mach_o_get_synthetic_symtab): Rewrite. 97649 976502022-10-14 Tom de Vries <tdevries@suse.de> 97651 97652 [gdb/testsuite] Drop unnecessary -Wl,-soname in gdb.base/skip-solib.exp 97653 I noticed in gdb.base/skip-solib.exp: 97654 ... 97655 if {[gdb_compile_shlib ${srcdir}/${subdir}/${srcfile_lib} ${binfile_lib} \ 97656 [list debug -Wl,-soname,${libname}.so]] != ""} { 97657 return -1 97658 } 97659 ... 97660 that the -Wl,-soname argument is missing an ldflags= prefix, but adding it 97661 gives us a duplicate: 97662 ... 97663 Executing on host: gcc -fno-stack-protector \ 97664 outputs/gdb.base/skip-solib/skip-solib-lib.c.o -fdiagnostics-color=never \ 97665 -shared -g -Wl,-soname,libskip-solib.so -Wl,-soname,libskip-solib.so -lm \ 97666 -o outputs/gdb.base/skip-solib/libskip-solib.so (timeout = 300) 97667 ... 97668 so apparently it's taken care of by gdb_compile_shlib. 97669 97670 Drop the inactive and also unnecessary -Wl,-soname,${libname}.so from the 97671 flags list for the gdb_compile_shlib call. 97672 97673 Tested on x86_64-linux. 97674 976752022-10-14 Tom de Vries <tdevries@suse.de> 97676 97677 [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with PIE 97678 With test-case gdb.base/infoline-reloc-main-from-zero.exp and target board 97679 unix/-fPIE/-pie I run into: 97680 ... 97681 gdb compile failed, ld: infoline-reloc-main-from-zero: error: \ 97682 PHDR segment not covered by LOAD segment 97683 collect2: error: ld returned 1 exit status 97684 ... 97685 97686 When running with native, I find that the executable is static: 97687 ... 97688 $ file infoline-reloc-main-from-zero 97689 infoline-reloc-main-from-zero: ELF 64-bit LSB executable, x86-64, \ 97690 version 1 (SYSV), statically linked, BuildID[sha1]=$hex, with debug_info, \ 97691 not stripped 97692 ... 97693 despite not having been compiled with -static. 97694 97695 Fix the compilation by adding -static to the compilation flags. 97696 97697 Tested on x86_64-linux. 97698 976992022-10-14 Tom de Vries <tdevries@suse.de> 97700 97701 [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with clang 97702 With test-case gdb.base/infoline-reloc-main-from-zero.exp and clang I run into: 97703 ... 97704 gdb compile failed, clang-13.0: warning: -e main: 'linker' input unused \ 97705 [-Wunused-command-line-argument] 97706 clang-13.0: warning: -Wl,-Ttext=0x00: 'linker' input unused \ 97707 [-Wunused-command-line-argument] 97708 clang-13.0: warning: -Wl,-N: 'linker' input unused \ 97709 [-Wunused-command-line-argument] 97710 UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \ 97711 infoline-reloc-main-from-zero.exp 97712 UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile 97713 ... 97714 97715 Fix this by using ldflags instead of additional_flags. 97716 97717 Likewise, fix all occurrences of: 97718 ... 97719 $ find gdb/testsuite -name *.exp | xargs grep additional_flags.*Wl 97720 ... 97721 97722 Tested on x86_64-linux. 97723 977242022-10-14 Tom de Vries <tdevries@suse.de> 97725 97726 [gdb/testsuite] Fix nopie test-cases with target board unix/-fPIE/-pie 97727 Compilers default to either PIE or no-PIE executables. 97728 97729 In order to test PIE executables with a compiler that produces non-PIE by 97730 default, we can use target board unix/-fPIE/-pie, which set the multilib_flags 97731 of the target board to "-fPIE -pie". 97732 97733 Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that 97734 produces PIE by default. 97735 97736 The target board unix/-fno-PIE/-no-pie has a potential problem when compiling 97737 shared libs, because the multilib_flags will override the attempts of 97738 gdb_compile_shlib to compile with -fPIC. This is taken care of by running the 97739 body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered. 97740 97741 The target board unix/-fPIE/-pie has a problem with nopie compilations. The 97742 current approach is to do the compilation hoping for the best, and if we find 97743 out that the resulting executable is PIE despite specifying nopie, we error 97744 out with the standard error message "nopie failed to prevent PIE executable". 97745 97746 That however does not work for hard-coded assembly nopie test-cases, which will 97747 just noisily refuse to compile: 97748 ... 97749 ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \ 97750 used when making a PIE object; recompile with -fPIE^M 97751 ... 97752 97753 Fix this in gdb_compile by filtering out the PIE settings in the target board 97754 multilib_flags when pie or nopie is specified. 97755 97756 Tested on x86_64-linux. 97757 977582022-10-14 Tom de Vries <tdevries@suse.de> 97759 97760 [gdb/testsuite] Factor out with_PIE_multilib_flags_filtered 97761 Factor out new procs with_PIE_multilib_flags_filtered and 97762 with_multilib_flags_filtered from proc gdb_compile_shlib. 97763 97764 Tested on x86_64-linux. 97765 977662022-10-14 Tom de Vries <tdevries@suse.de> 97767 97768 [gdb/testsuite] Add cond_wrap proc 97769 Add a new proc cond_wrap, that can be used to replace the repetitive: 97770 ... 97771 if { $cond } { 97772 wrap { 97773 <body> 97774 } 97775 } else { 97776 <body> 97777 } 97778 ... 97779 with the shorter: 97780 ... 97781 cond_wrap $cond wrap { 97782 <body> 97783 } 97784 ... 97785 97786 Tested on x86_64-linux. 97787 977882022-10-14 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 97789 97790 gdb: add Torbjörn Svensson to gdb/MAINTAINERS 97791 977922022-10-14 Jan Beulich <jbeulich@suse.com> 97793 97794 RISC-V: Zicbo{m,p,z} adjustments to riscv_multi_subset_supports_ext() 97795 The lack thereof did caused gas to issue "internal: unreachable 97796 INSN_CLASS_*" errors when trying to assemble respective insns without 97797 the feature(s) enabled via e.g. ".option arch, ...". Of course a proper 97798 hint towards the missing extension then wasn't given either. 97799 978002022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97801 97802 RISC-V: Imply 'Zicsr' from privileged extensions with CSRs 97803 'H', 'Smstateen', 'Sscofpmf' and 'Sstc' are four privileged extensions with 97804 their CSR definitions and 'Smepmp' is a privileged extension with additional 97805 CSR bits. 97806 97807 Volume II: Privileged Architecture of the RISC-V ISA Manual states that the 97808 privileged architecture requires the 'Zicsr' extension. However, current 97809 GNU Binutils has no direct way whether the program has dependency to the 97810 privileged architecture itself. 97811 97812 As a workaround, we should add implications from privileged extensions that 97813 either add new CSRs, extend existing CSRs or depends on using CSRs. 97814 97815 This commit adds such implications for existing privileged extensions that 97816 satisfy this condition. 97817 97818 gas/ChangeLog: 97819 97820 * testsuite/gas/riscv/march-imply-h.d: New test, at least for 'H'. 97821 97822 bfd/ChangeLog: 97823 97824 * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zicsr' 97825 implicications for privileged extensions 'H', 'Smstateen', 97826 'Sscofpmf', 'Sstc' and 'Smepmp'. 97827 978282022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97829 97830 opcodes/riscv-dis.c: Remove last_map_state 97831 Before changing the core disassembler, we take care of minor code clarity 97832 issues and improve readability. 97833 97834 This commit removes unused variable last_map_state (set by the 97835 print_insn_riscv function but not read anywhere else). 97836 97837 opcodes/ChangeLog: 97838 97839 * riscv-dis.c (last_map_state): Remove. 97840 (print_insn_riscv): Remove setting last_map_state. 97841 978422022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97843 97844 opcodes/riscv-dis.c: Make XLEN variable static 97845 Before changing the core disassembler, we take care of minor code clarity 97846 issues and improve readability. 97847 97848 Since xlen variable is not (and should not) used outside riscv-dis.c, 97849 this commit makes this variable static. 97850 97851 opcodes/ChangeLog: 97852 97853 * riscv-dis.c (xlen): Make this variable static. 97854 978552022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97856 97857 opcodes/riscv-dis.c: Use bool type whenever possible 97858 Before changing the core disassembler, we take care of minor code clarity 97859 issues and improve readability. 97860 97861 This commit replaces uses of int with bool whenever possible. 97862 97863 opcodes/ChangeLog: 97864 97865 * riscv-dis.c (no_aliases) Change type to bool. 97866 (set_default_riscv_dis_options): Use boolean. 97867 (parse_riscv_dis_option_without_args): Likewise. 97868 (riscv_disassemble_insn): Use boolean keywords. 97869 978702022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97871 97872 opcodes/riscv-dis.c: Tidying with spacing 97873 Before changing the core disassembler, we take care of minor code clarity 97874 issues and improve readability. 97875 97876 This commit takes care of improper spacing for code clarity. 97877 97878 opcodes/ChangeLog: 97879 97880 * riscv-dis.c (riscv_disassemble_insn): Tidying with spacing. 97881 978822022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97883 97884 opcodes/riscv-dis.c: Tidying with comments/clarity 97885 Before changing the core disassembler, we take care of minor code clarity 97886 issues and improve readability. 97887 97888 First, we need to clarify the roles of variables and code portions. 97889 97890 opcodes/ChangeLog: 97891 97892 * riscv-dis.c (xlen): Move before default_isa_spec. Add comment. 97893 (default_isa_spec, default_priv_spec): Add comment. 97894 (riscv_gpr_names, riscv_fpr_names): Likewise. 97895 (parse_riscv_dis_option_without_args): Likewise. 97896 (parse_riscv_dis_option, parse_riscv_dis_options): Likewise. 97897 (maybe_print_address): Likewise. 97898 (riscv_disassemble_insn): Fix comment about the Zfinx "extension". 97899 Add comment about the riscv_multi_subset_supports call. 97900 979012022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97902 97903 RISC-V: Test DWARF register number for "fp" 97904 This commit adds "fp" (x8 or s0) to dw-regnums.{s,d}. 97905 97906 gas/ChangeLog: 97907 97908 * testsuite/gas/riscv/dw-regnums.s: Add "fp". 97909 * testsuite/gas/riscv/dw-regnums.d: Likewise. 97910 979112022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97912 97913 RISC-V: Move standard hints before all instructions 97914 Because all standard hints must be placed before corresponding instruction 97915 for the disassembler, they may taint basic RVI instruction section. 97916 97917 This commit moves all standard hints before all basic RVI instructions 97918 to improve maintainability. 97919 97920 opcodes/ChangeLog: 97921 97922 * riscv-opc.c (riscv_opcodes): Move all standard hints before all 97923 standard instructions. 97924 979252022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com> 97926 97927 RISC-V: Move certain arrays to riscv-opc.c 97928 This is a part of small tidying (declare tables in riscv-opc.c). 97929 97930 include/ChangeLog: 97931 97932 * opcode/riscv.h (riscv_rm, riscv_pred_succ): Move declarations to 97933 opcodes/riscv-opc.c. New non-static definitions. 97934 97935 opcodes/ChangeLog: 97936 97937 * riscv-opc.c (riscv_rm, riscv_pred_succ): Move from 97938 include/opcode/riscv.h. Add description. 97939 979402022-10-14 Fangrui Song <i@maskray.me> 97941 97942 ld: Add --undefined-version 97943 This cancels a previous --no-undefined-version. 97944 gold has had --undefined-version for a long time. 97945 979462022-10-14 GDB Administrator <gdbadmin@sourceware.org> 97947 97948 Automatic date update in version.in 97949 979502022-10-13 Carl Love <cel@us.ibm.com> 97951 97952 PowerPC, fix gdb.base/watchpoint.exp on Power 9 97953 Test gdb.base/watchpoint.exp generates 4 test errors on Power 9. The 97954 test uses the test [target_info exists gdb,no_hardware_watchpoints] to 97955 determine if the processor supports hardware watchpoints. The check 97956 only examines the processor type to determine if it supports hardware 97957 watchpoints. 97958 97959 The PowerPC processors support hardware watchpoints with the 97960 exception of Power 9. The hardware watchpoint support is disabled on 97961 Power 9. The test skip_hw_watchpoint_tests must be used to correctly 97962 determine if the PowerPC processor supports hardware watchpoints. 97963 97964 This patch replaces the [target_info exists gdb,no_hardware_watchpoints] 97965 with the skip_hw_watchpoint_tests_p check. With the patch, the test runs 97966 on Power 9 with hardware watchpoint force-disabled. The test runs on 97967 all other PowerPC processors with and without hardware watchpoints 97968 enabled. 97969 97970 The patch has been tested on Power 9 to verify the test only runs with 97971 hardware breakpoints disabled. The patch has been tested on X86-64 with 97972 no regression failures. The test fails on Power 10 due to an internal GDB 97973 error due to resource management. The resource management issue will be 97974 addressed in another patch. 97975 979762022-10-13 Tom de Vries <tdevries@suse.de> 97977 97978 [gdb/testsuite] Fix gdb.dwarf2/macro-source-path.exp with -m32 97979 With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I 97980 run into: 97981 ... 97982 as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \ 97983 unsupported relocation type: 0x1^M 97984 ... 97985 97986 The problem is that we have 64-bit dwarf so the debug_line offset in the 97987 .debug_macro section is an 8-byte entity, emitted using ".8byte": 97988 ... 97989 .section .debug_macro 97990 .Lcu_macros4: 97991 .2byte 5 /* version */ 97992 .byte 3 /* flags */ 97993 .8byte .LLlines3 /* debug_line offset */ 97994 ... 97995 but the linker doesn't support 8-byte relocation types on a 32-bit architecture. 97996 97997 This is similar to what was fixed in commit a5ac8e7fa3b 97998 ("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance 97999 .debug_abbrev. 98000 98001 Fix this in the same way, by using _op_offset to emit the debug_line offset. 98002 98003 Tested on x86_64-linux with native and target board unix/-m32. 98004 980052022-10-13 Tom de Vries <tdevries@suse.de> 98006 98007 [gdb/testsuite] Fix gdb.dwarf2/entry-value-typedef.exp with -m32 98008 With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32, 98009 I run into: 98010 ... 98011 builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \ 98012 gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \ 98013 -fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \ 98014 -o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M 98015 entry-value-typedef.cpp: Assembler messages:^M 98016 entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M 98017 ... 98018 98019 The problem is that the test-cases selects an amd64 .S file based on the check: 98020 ... 98021 if { [istarget "x86_64-*-linux*"] } { 98022 ... 98023 which is also true for target board unix/-m32 on x86_64-linux. 98024 98025 Fix this by adding the missing is_lp64_target check. 98026 98027 Tested on x86_64-linux, using native and target board unix/-m32. 98028 980292022-10-13 Tom de Vries <tdevries@suse.de> 98030 98031 [gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with -m32 98032 With target board unix/-m32 and test-case gdb.mi/mi-disassemble.exp we have: 98033 ... 98034 (gdb) ^M 98035 print/x *((unsigned char *) 0x8048485)^M 98036 &"print/x *((unsigned char *) 0x8048485)\n"^M 98037 ~"$9 = 0x83\n"^M 98038 ^done^M 98039 (gdb) ^M 98040 PASS: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x8048485)" 98041 FAIL: gdb.mi/mi-disassemble.exp: byte at 0x8048485 matches 98042 ... 98043 The test-case passes with native. 98044 98045 With native we see in gdb.log that variable longest_insn_bytes is: 98046 ... 98047 Longest instruction at 0x0000000000400549 with bytes '48 8b 05 20 01 00 00' 98048 ... 98049 and variable split_bytes (added debug puts) ends up as: 98050 ... 98051 SPLIT_BYTES: 48 8b 05 20 01 00 00 98052 ... 98053 98054 But with unix/-m32 we have longest_insn_byte: 98055 ... 98056 Longest instruction at 0x08048481 with bytes '8d 4c 24 04 ' 98057 ... 98058 and split_bytes ends up as: 98059 ... 98060 SPLIT_BYTES: 8d 4c 24 04 {} {} {} {} {} {} {} {} 98061 ... 98062 so the trailing whitespace is translated by split to empty bytes, and the 98063 mismatch FAILs are generated for those. 98064 98065 Fix this by stripping the whitespace, which makes us end up with a different 98066 and indeed longer insn: 98067 ... 98068 Longest instruction at 0x08048492 with bytes 'dd 05 98 85 04 08' 98069 ... 98070 98071 Tested on x86_64-linux, with native and target board unix/-m32. 98072 980732022-10-13 GDB Administrator <gdbadmin@sourceware.org> 98074 98075 Automatic date update in version.in 98076 980772022-10-12 Carl Love <cel@us.ibm.com> 98078 98079 PowerPC, fix test gdb.base/watchpoint-stops-at-right-insn.exp 98080 Test gdb.base/watchpoint-stops-at-right-insn.exp generates 4 test errors 98081 on Power 9. The test uses the test [target_info exists gdb, 98082 no_hardware_watchpoints] to determine if the processor supports hardware 98083 watchpoints. The check only examines the processor type to determine if 98084 it supports hardware watchpoints. Note, the test works fine on Power 10. 98085 98086 The PowerPC processors support hardware watchpoints with the 98087 exception of Power 9. The hardware watchpoint support is disabled on 98088 Power 9. The test skip_hw_watchpoint_tests must be used to correctly 98089 determine if the PowerPC processor supports hardware watchpoints. 98090 98091 This patch replaces the [target_info exists gdb,no_hardware_watchpoints] 98092 with the skip_hw_watchpoint_tests_p check. With the patch, the test is 98093 disabled on Power 9 but runs on all other PowerPC processors. 98094 98095 The patch has been tested on Power 9, Power 10 and X86-64 with no 98096 regression failures. 98097 980982022-10-12 Jan Beulich <jbeulich@suse.com> 98099 98100 x86: drop "regmask" static variable 98101 Replace its two uses by more direct checks, paralleling what's already 98102 there for SIMD registers. 98103 981042022-10-12 Tom de Vries <tdevries@suse.de> 98105 98106 [gdb/symtab] Factor out elf_symfile_read_dwarf2 98107 Factor out elf_symfile_read_dwarf2 from elf_symfile_read. NFC. 98108 98109 Tested on x86_64-linux. 98110 981112022-10-12 Tom de Vries <tdevries@suse.de> 98112 98113 [gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed 98114 When running test-case gdb.base/ctf-constvars.exp on openSUSE Tumbleweed (with 98115 system gcc version 12, providing gcc -gctf support, enabling the ctf test-cases 98116 in the gdb testsuite), I run into: 98117 ... 98118 (gdb) print vox^M 98119 'vox' has unknown type; cast it to its declared type^M 98120 (gdb) FAIL: gdb.base/ctf-constvars.exp: print vox 98121 ... 98122 98123 There are two causes for this: 98124 - the linker flags are missing --ctf-variables, so the information for variable 98125 vox is missing (reported in PR29468), and 98126 - the executable contains some dwarf2 due to some linked-in glibc objects, 98127 so the ctf info is ignored (reported in PR29160). 98128 98129 By using: 98130 - -Wl,--ctf-variable, 98131 - -Wl,--strip-debug, and 98132 we can make the test-case and some similar test-cases pass. 98133 98134 Tested on x86_64-linux. 98135 98136 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29160 98137 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29468 98138 981392022-10-12 Tom de Vries <tdevries@suse.de> 98140 98141 [gdb/testsuite] Silence warnings about obsolete -gstabs 98142 When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with 98143 gcc 12) I get: 98144 ... 98145 gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \ 98146 STABS debugging information is obsolete and not supported anymore 98147 ... 98148 98149 Silence the warning by passing quiet to gdb_compile. Likewise in two other 98150 test-cases. 98151 981522022-10-12 Tom de Vries <tdevries@suse.de> 98153 98154 [gdb/testsuite] Replace remaining -gt with -gctf 98155 With test-cases gdb.base/cvexpr.exp and gdb.base/whatis.exp I run into: 98156 ... 98157 gdb compile failed, gcc: error: unrecognized debug output level 't' 98158 ... 98159 98160 This is due to using additional_flags=-gt. 98161 98162 Commit ffb3f587933 ("CTF: multi-CU and archive support") replaced 98163 additional_flags=-gt with additional_flags=-gctf in gdb.ctf/*.exp and 98164 gdb.base/ctf-*.exp. 98165 98166 Do the same in these two test-cases. 98167 98168 Tested on x86_64-linux. 98169 981702022-10-12 Tom de Vries <tdevries@suse.de> 98171 98172 [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with recent ld 98173 On openSUSE Tumbleweed (with ld 2.39) and test-case 98174 gdb.base/infoline-reloc-main-from-zero.exp, I get: 98175 ... 98176 gdb compile failed, ld: warning: infoline-reloc-main-from-zero has a LOAD \ 98177 segment with RWX permissions 98178 UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \ 98179 infoline-reloc-main-from-zero.exp 98180 ... 98181 98182 Fix this by compiling with -Wl,--no-warn-rwx-segments. 98183 98184 Tested on x86_64-linux. 98185 981862022-10-12 Tom de Vries <tdevries@suse.de> 98187 98188 [gdb/testsuite] Fix gdb.base/nested-subp{2,3}.exp with recent ld 98189 On openSUSE Tumbleweed (with ld 2.39) I get for test-case 98190 gdb.base/nested-subp2.exp: 98191 ... 98192 gdb compile failed, ld: warning: tmp.o: requires executable stack \ 98193 (because the .note.GNU-stack section is executable) 98194 ... 98195 98196 Fix this by compiling with -Wl,--no-warn-execstack. 98197 98198 Likewise in gdb.base/nested-subp3.exp 98199 98200 Tested on x86_64-linux. 98201 982022022-10-12 Tom de Vries <tdevries@suse.de> 98203 98204 [gdb/testsuite] Remove unnecessary perror in some test-cases 98205 On openSUSE Tumbleweed I noticed: 98206 ... 98207 UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp 98208 ERROR: failed to compile fission-absolute-dwo 98209 ... 98210 98211 The ERROR is unnecessary, given that an UNTESTED is already emitted. 98212 98213 Furthermore, it could be argued that it is incorrect because it's not a 98214 testsuite error to not be able to compile something, and UNTESTED or 98215 UNSUPPORTED is more appropriate. 98216 98217 Remove the perror call, likewise in fission-relative-dwo.exp. 98218 98219 Tested on x86_64-linux. 98220 982212022-10-12 Nick Clifton <nickc@redhat.com> 98222 98223 Fix objcopy's error message when it cannot add a .gnu_debuglink section because the section already exists. 98224 PR 29665 98225 * objcopy.c (copy_object): Use the input filename when 98226 reporting that a .gnu_debuglink section already exists. 98227 982282022-10-12 Tsukasa OI <research_trasio@irq.a4lg.com> 98229 98230 sim/ppc: Fix core_find_mapping diagnostics 98231 Because "%p" is the pointer conversion specifier to print a pointer in an 98232 implementation-defined manner, the result with format string containing 98233 "0x%p" can be strange. For instance, core_map_find_mapping prints error 98234 containing "0x0x...." (processor is not NULL) or "0x(null)" (processor is 98235 NULL) on glibc. 98236 98237 This commit replaces "0x%p" with "%p" to prevent unpredictable behavior. 98238 982392022-10-12 Andrew Burgess <aburgess@redhat.com> 98240 98241 sim/ppc: fixes for arguments to printf style functions 98242 After the recent series of fixes to mark more functions in the 98243 simulator with ATTRIBUTE_PRINTF, there were some build failures in the 98244 ppc sim due, in some cases, to bugs with the arguments being passed, 98245 and in other cases, the issues were (maybe) less serious, with 98246 arguments being the wrong size, or type, for the printf format being 98247 used. 98248 98249 This commit fixes all of the issues that I ran into. 98250 98251 In each case I selected the easiest solution to the problem, which is 98252 usually just casting the argument to the correct type. If anyone 98253 later on thinks the print format should change, please feel free to do 98254 that. What we have here should keep the simulator basically working 98255 as it does currently, which is my goal with this commit. 98256 982572022-10-12 Tom de Vries <tdevries@suse.de> 98258 98259 [gdb/contrib] Use OBJCOPY everywhere in cc-with-tweaks.sh 98260 I noticed that the $want_gnu_debuglink code in gdb/contrib/cc-with-tweaks.sh 98261 uses objcopy instead of $OBJCOPY. Fix this. 98262 98263 Script checked with shellcheck, no new warnings added. 98264 98265 Tested on x86_64-linux. 98266 982672022-10-12 Simon Marchi <simon.marchi@efficios.com> 98268 98269 Re-apply "Pass PKG_CONFIG_PATH down from top-level Makefile" 98270 Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the 98271 change originally done in de83289ef32e ("Pass PKG_CONFIG_PATH down from 98272 top-level Makefile"). Re-apply it. 98273 98274 Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf 98275 982762022-10-12 Simon Marchi <simon.marchi@polymtl.ca> 98277 98278 gdb: rename target_read_auxv(target_ops *) to target_read_auxv_raw 98279 Having two overloads of target_read_auxv that don't have the same goals 98280 is confusing. Rename the one that reads from an explicit target_ops to 98281 target_read_auxv_raw. Also, it occured to me that the non-raw version 98282 could use the raw version, that reduces duplication a bit. 98283 98284 Change-Id: I28e5f7cecbfcacd0174d4686efb3e4a23b4ad491 98285 982862022-10-12 GDB Administrator <gdbadmin@sourceware.org> 98287 98288 Automatic date update in version.in 98289 982902022-10-12 Alan Modra <amodra@gmail.com> 98291 98292 Re: Merge configure.ac from gcc project 98293 Also copy over config.acx.m4, and regenerate. 98294 982952022-10-11 Simon Marchi <simon.marchi@polymtl.ca> 98296 98297 gdb: fix auxv caching 98298 There's a flaw in the interaction of the auxv caching and the fact that 98299 target_auxv_search allows reading auxv from an arbitrary target_ops 98300 (passed in as a parameter). This has consequences as explained in this 98301 thread: 98302 98303 https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/ 98304 98305 In summary, when loading an AArch64 core file with MTE support by 98306 passing the executable and core file names directly to GDB, we see the 98307 MTE info: 98308 98309 $ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core 98310 ... 98311 Program terminated with signal SIGSEGV, Segmentation fault 98312 Memory tag violation while accessing address 0x0000ffff8ef5e000 98313 Allocation tag 0x1 98314 Logical tag 0x0. 98315 #0 0x0000aaaade3d0b4c in ?? () 98316 (gdb) 98317 98318 But if we do it as two separate commands (file and core) we don't: 98319 98320 $ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core" 98321 ... 98322 Program terminated with signal SIGSEGV, Segmentation fault. 98323 #0 0x0000aaaade3d0b4c in ?? () 98324 (gdb) 98325 98326 The problem with the latter is that auxv data gets improperly cached 98327 between the two commands. When executing the file command, auxv gets 98328 first queried here, when loading the executable: 98329 98330 #0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383 98331 #1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482 98332 #2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878 98333 #3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933 98334 #4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253 98335 #5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655 98336 #6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555 98337 #7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95 98338 #8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543 98339 #9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692 98340 #10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513 98341 #11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608 98342 #12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299 98343 #13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320 98344 #14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345 98345 #15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 98346 98347 Here, target_auxv_search is called on the inferior's target stack. The 98348 target stack only contains the exec target, so the query returns empty 98349 auxv data. This gets cached for that inferior in `auxv_inferior_data`. 98350 98351 In its constructor (before it is pushed to the inferior's target stack), 98352 the core_target needs to identify the right target description from the 98353 core, and for that asks the gdbarch to read a target description from 98354 the core file. Because some implementations of 98355 gdbarch_core_read_description (such as AArch64's) need to read auxv data 98356 from the core in order to determine the right target description, the 98357 core_target passes a pointer to itself, allowing implementations to call 98358 target_auxv_search it. However, because we have previously cached 98359 (empty) auxv data for that inferior, target_auxv_search searched that 98360 cached (empty) auxv data, not auxv data read from the core. Remember 98361 that this data was obtained by reading auxv on the inferior's target 98362 stack, which only contained an exec target. 98363 98364 The problem I see is that while target_auxv_search offers the 98365 flexibility of reading from an arbitrary (passed as an argument) target, 98366 the caching doesn't do the distinction of which target is being queried, 98367 and where the cached data came from. So, you could read auxv from a 98368 target A, it gets cached, then you try to read auxv from a target B, and 98369 it returns the cached data from target A. That sounds wrong. In our 98370 case, we expect to read different auxv data from the core target than 98371 what we have read from the target stack earlier, so it doesn't make 98372 sense to hit the cache in this case. 98373 98374 To fix this, I propose splitting the code paths that read auxv data from 98375 an inferior's target stack and those that read from a passed-in target. 98376 The code path that reads from the target stack will keep caching, 98377 whereas the one that reads from a passed-in target won't. And since, 98378 searching in auxv data is independent from where this data came from, 98379 split the "read" part from the "search" part. 98380 98381 From what I understand, auxv caching was introduced mostly to reduce 98382 latency on remote connections, when doing many queries. With the change 98383 I propose, only the queries done while constructing the core_target 98384 end up not using cached auxv data. This is fine, because there are just 98385 a handful of queries max, done at this point, and reading core files is 98386 local. 98387 98388 The changes to auxv functions are: 98389 98390 - Introduce 2 target_read_auxv functions. One reads from an explicit 98391 target_ops and doesn't do caching (to be used in 98392 gdbarch_core_read_description context). The other takes no argument, 98393 reads from the current inferior's target stack (it looks just like a 98394 standard target function wrapper) and does caching. 98395 98396 The first target_read_auxv actually replaces get_auxv_inferior_data, 98397 since it became a trivial wrapper around it. 98398 98399 - Change the existing target_auxv_search to not read auxv data from the 98400 target, but to accept it as a parameter (a gdb::byte_vector). This 98401 function doesn't care where the data came from, it just searches in 98402 it. It still needs to take a target_ops and gdbarch to know how to 98403 parse auxv entries. 98404 98405 - Add a convenience target_auxv_search overload that reads auxv 98406 data from the inferior's target stack and searches in it. This 98407 overload is useful to replace the exist target_auxv_search calls that 98408 passed the `current_inferior ()->top_target ()` target and keep the 98409 call sites short. 98410 98411 - Modify parse_auxv to accept a target_ops and gdbarch to use for 98412 parsing entries. Not strictly related to the rest of this change, 98413 but it seems like a good change in the context. 98414 98415 Changes in architecture-specific files (tdep and nat): 98416 98417 - In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two, 98418 similar to target_auxv_search. One version receives auxv data, 98419 target and arch as parameters. The other gets everything from the 98420 current inferior. The latter is for convenience, to avoid making 98421 call sites too ugly. 98422 98423 - Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to 98424 use either of the new versions. The call sites in 98425 gdbarch_core_read_description context explicitly read auxv data from 98426 the passed-in target and call the linux_get_hwcap{,2} function with 98427 parameters. Other call sites use the versions without parameters. 98428 98429 - Same idea for arm_fbsd_read_description_auxv. 98430 98431 - Call sites of target_auxv_search that passed 98432 `current_inferior ()->top_target ()` are changed to use the 98433 target_auxv_search overload that works in the current inferior. 98434 98435 Reviewed-By: John Baldwin <jhb@FreeBSD.org> 98436 Reviewed-By: Luis Machado <luis.machado@arm.com> 98437 Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66 98438 984392022-10-11 Tom de Vries <tdevries@suse.de> 98440 98441 [gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with native-gdbserver 98442 When running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target 98443 board native-gdbserver, I get: 98444 ... 98445 Running gdb.debuginfod/fetch_src_and_symbols.exp ... 98446 ERROR: tcl error sourcing gdb.debuginfod/fetch_src_and_symbols.exp. 98447 ERROR: gdbserver does not support start without extended-remote 98448 while executing 98449 "error "gdbserver does not support $command without extended-remote"" 98450 (procedure "gdb_test_multiple" line 51) 98451 invoked from within 98452 "gdb_test_multiple $command $message {*}$opts $user_code" 98453 (procedure "gdb_test" line 56) 98454 invoked from within 98455 "gdb_test "start" "Temporary breakpoint.*"" 98456 ... 98457 98458 Fix this by replacing gdb_test "start" with runto_main. 98459 98460 Tested on x86_64-linux. 98461 984622022-10-11 Nick Clifton <nickc@redhat.com> 98463 98464 Re: Error: attempt to get value of unresolved symbol `L0' 98465 * symbols.c (S_GET_VALUE): If the unresolved symbol is the fake 98466 label provide a more helpful error message to the user. 98467 (S_GET_VALUE_WHERE): Like S_GET_VALUE, but includes a file/line 98468 number for error reporting purposes. 98469 * symbols.h (S_GET_VALUE_WHERE): Prototype. 98470 * write.c (fixup_segment): Use S_GET_VALUE_WHERE. 98471 984722022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98473 98474 sim: Initialize pbb_br_* by default 98475 On the files generated by sim/common/genmloop.sh, variables pbb_br_type and 98476 pbb_br_npc are declared uninitialized and passed to other functions in some 98477 cases. Despite that those are harmless, they will generate GCC warnings 98478 ("-Wmaybe-uninitialized"). 98479 98480 This commit ensures that pbb_br_type and pbb_br_npc variables are 98481 initialized to a harmless value. 98482 984832022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98484 98485 sim: Check known getopt definition existence 98486 Clang generates a warning if there is a function declaration/definition 98487 with zero arguments. Such declarations/definitions without a prototype (an 98488 argument list) are deprecated forms of indefinite arguments 98489 ("-Wdeprecated-non-prototype"). On the default configuration, it causes a 98490 build failure (unless "--disable-werror" is specified). 98491 98492 include/getopt.h defines some getopt function definitions but one of them 98493 has a form "extern int getopt ();". If this form is selected in 98494 include/getopt.h, Clang generates a warning and the build fails by default. 98495 98496 In really old environments, this getopt definition with no arguments is 98497 necessary (because the definition may change between environments). 98498 However, this definition is now a cause of problems on modern environments. 98499 98500 A good news is, this definition is not always selected (e.g. if used by 98501 binutils/*.c). This is because configuration scripts of binutils, gas, 98502 gprof and ld tries to find known definition of getopt function is used and 98503 defines HAVE_DECL_GETOPT macro. If this macro is defined when getopt.h is 98504 included, a good form of getopt is used and Clang won't generate warnings. 98505 98506 This commit adds a modified portion of ld/configure.ac to find the known 98507 getopt definition. If we could find one (and we *will* in most modern 98508 environments), we don't need to rely on the deprecated definition. 98509 985102022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98511 Andrew Burgess <aburgess@redhat.com> 98512 98513 sim: Suppress non-literal printf warning 98514 Clang generates a warning if the format string of a printf-like function is 98515 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98516 causes a build failure (unless "--disable-werror" is specified). 98517 98518 To avoid this warning, this commit now uses vsnprintf to format error 98519 message and pass the message to sim_engine_abort function with another 98520 printf-style formatting. 98521 98522 This patch is mostly authored by Andrew Burgess and slightly modified by 98523 Tsukasa OI. 98524 985252022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98526 98527 sim: Make WITH_{TRACE,PROFILE}-based macros bool 98528 Clang generates a warning if there is an ambiguous expression (possibly a 98529 bitwise operation (& or |), but a logical operator (&& or ||) is used; 98530 "-Wconstant-logical-operand"). On the default configuration, it causes a 98531 build failure (unless "--disable-werror" is specified). 98532 98533 This is caused by predicate macros that use the form (base_variable & flag). 98534 Clang considers them as regular integer values (not boolean) and 98535 generates that warning. 98536 98537 This commit makes Clang think those predicate macros to be boolean. 98538 985392022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98540 98541 sim: Remove self-assignments 98542 Clang generates a warning if there is a redundant self-assignment 98543 ("-Wself-assign"). On the default configuration, it causes a build failure 98544 (unless "--disable-werror" is specified). 98545 98546 This commit removes redundant self-assignments from two files. 98547 985482022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98549 98550 sim/rl78: Add ATTRIBUTE_PRINTF 98551 Clang generates a warning if the format string of a printf-like function is 98552 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98553 causes a build failure (unless "--disable-werror" is specified). 98554 98555 To avoid warnings on the printf-like wrapper, it requires proper 98556 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98557 98558 This commit adds ATTRIBUTE_PRINTF to the printf-like functions. 98559 985602022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98561 98562 sim/ppc: Add ATTRIBUTE_PRINTF 98563 Clang generates a warning if the format string of a printf-like function is 98564 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98565 causes a build failure (unless "--disable-werror" is specified). 98566 98567 To avoid warnings on the printf-like wrapper, it requires proper 98568 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98569 98570 This commit adds ATTRIBUTE_PRINTF to the printf-like functions. 98571 98572 For the error function defined in sim_calls.c, the ATTRIBUTE_NORETURN 98573 has been moved to the function declaration. 98574 985752022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98576 98577 sim/m68hc11: Add ATTRIBUTE_PRINTF 98578 Clang generates a warning if the format string of a printf-like function is 98579 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98580 causes a build failure (unless "--disable-werror" is specified). 98581 98582 To avoid warnings on the printf-like wrapper, it requires proper 98583 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98584 98585 This commit adds ATTRIBUTE_PRINTF to a printf-like function. 98586 985872022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98588 98589 sim/m32c: Add ATTRIBUTE_PRINTF 98590 Clang generates a warning if the format string of a printf-like function is 98591 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98592 causes a build failure (unless "--disable-werror" is specified). 98593 98594 To avoid warnings on the printf-like wrapper, it requires proper 98595 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98596 98597 This commit adds ATTRIBUTE_PRINTF to the printf-like functions. 98598 985992022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98600 98601 sim/erc32: Add ATTRIBUTE_PRINTF 98602 Clang generates a warning if the format string of a printf-like function is 98603 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98604 causes a build failure (unless "--disable-werror" is specified). 98605 98606 To avoid warnings on the printf-like wrapper, it requires proper 98607 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98608 98609 This commit adds ATTRIBUTE_PRINTF to the printf-like functions. 98610 986112022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98612 98613 sim/cris: Add ATTRIBUTE_PRINTF 98614 Clang generates a warning if the format string of a printf-like function is 98615 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98616 causes a build failure (unless "--disable-werror" is specified). 98617 98618 To avoid warnings on the printf-like wrapper, it requires proper 98619 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98620 98621 This commit adds ATTRIBUTE_PRINTF to a printf-like function. 98622 986232022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98624 98625 sim/common: Add ATTRIBUTE_PRINTF 98626 Clang generates a warning if the format string of a printf-like function is 98627 not a literal ("-Wformat-nonliteral"). On the default configuration, it 98628 causes a build failure (unless "--disable-werror" is specified). 98629 98630 To avoid warnings on the printf-like wrapper, it requires proper 98631 __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason. 98632 98633 This commit adds ATTRIBUTE_PRINTF to a printf-like function. 98634 986352022-10-11 Martin Liska <mliska@suse.cz> 98636 98637 fix compressed_debug_section_names definition for "zlib" 98638 bfd/ChangeLog: 98639 98640 * libbfd.c: Set COMPRESS_DEBUG_GABI_ZLIB for "zlib" value. 98641 986422022-10-11 Martin Liska <mliska@suse.cz> 98643 98644 add --enable-default-compressed-debug-sections-algorithm configure option 98645 ChangeLog: 98646 98647 * configure.ac: Add --enable-default-compressed-debug-sections-algorithm. 98648 * configure: Regenerate. 98649 98650 gas/ChangeLog: 98651 98652 * NEWS: Document the new option. 98653 * as.c (flag_compress_debug): Set default algorithm based 98654 on the configure option. 98655 * configure.ac: Add --enable-default-compressed-debug-sections-algorithm. 98656 * configure: Regenerate. 98657 * config.in: Likewise. 98658 98659 ld/ChangeLog: 98660 98661 * NEWS: Document the new option. 98662 * configure.ac: Add --enable-default-compressed-debug-sections-algorithm. 98663 * configure: Regenerate. 98664 * config.in: Likewise. 98665 * ldmain.c: Set default algorithm based 98666 on the configure option. 98667 986682022-10-11 Martin Liska <mliska@suse.cz> 98669 98670 refactor usage of compressed_debug_section_type 98671 bfd/ChangeLog: 98672 98673 * bfd-in.h (bfd_hash_set_default_size): Add COMPRESS_UNKNOWN 98674 enum value. 98675 (struct compressed_type_tuple): New. 98676 * bfd-in2.h (bfd_hash_set_default_size): Regenerate. 98677 (struct compressed_type_tuple): Likewise. 98678 * libbfd.c (ARRAY_SIZE): New macro. 98679 (bfd_get_compression_algorithm): New function. 98680 (bfd_get_compression_algorithm_name): Likewise. 98681 98682 gas/ChangeLog: 98683 98684 * as.c: Do not special-case, use the new functions. 98685 98686 ld/ChangeLog: 98687 98688 * emultempl/elf.em: Do not special-case, use the new functions. 98689 * lexsup.c (elf_static_list_options): Likewise. 98690 986912022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98692 98693 sim/riscv: fix multiply instructions on simulator 98694 After this commit: 98695 98696 commit 0938b032daa52129b4215d8e0eedb6c9804f5280 98697 Date: Wed Feb 2 10:06:15 2022 +0900 98698 98699 RISC-V: Add 'Zmmul' extension in assembler. 98700 98701 some instructions in the RISC-V simulator stopped working as a new 98702 instruction class 'INSN_CLASS_ZMMUL' was added, and some existing 98703 instructions were moved into this class. 98704 98705 The simulator doesn't currently handle this instruction class, and so 98706 the instructions will now cause an illegal instruction trap. 98707 98708 This commit adds support for INSN_CLASS_ZMMUL, and adds a test that 98709 ensures the affected instructions can be executed by the simulator. 98710 98711 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 98712 Reviewed-by: Andrew Burgess <aburgess@redhat.com> 98713 987142022-10-11 Nick Clifton <nickc@redhat.com> 98715 98716 Error: attempt to get value of unresolved symbol `L0' 98717 * symbols.c (S_GET_VALUE): If the unresolved symbol is the fake 98718 label provide a more helpful error message to the user. 98719 987202022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com> 98721 98722 sim/moxie: add custom directory stamp rule 98723 Because sim/moxie/moxie-gdb.dtb is neither a program nor a library, automake 98724 does not generate dirstamp file ($builddir/sim/moxie/.dirstamp) for it. 98725 98726 When maintainer mode is enabled, it tries to rebuild sim/moxie/moxie-gdb.dtb 98727 but fails because there's no rules for automake-generated dirstamp file 98728 which moxie-gdb.dtb depends. 98729 98730 This commit adds its own rule for the directory stamp (modified copy of the 98731 automake output) and adds the directory stamp file to DISTCLEANFILES to 98732 mimic automake-generated behavior (although "make distclean" does not work 98733 when maintainer mode is enabled). 98734 987352022-10-11 Bruno Larsen <blarsen@redhat.com> 98736 98737 gdb/testsuite: Fix formatting of python script 98738 The python black formatter was complaining about formatting on the 98739 script gdb.python/pretty-print-call-by-hand.py. This commit changed 98740 the offending lines to make the formatter happy. 98741 987422022-10-11 Tom de Vries <tdevries@suse.de> 98743 98744 [gdb/testsuite] Fix prompt parsing in capture_command_output 98745 I noticed in capture_command_output that the output of a single command is 98746 matched using two gdb_test_multiples: 98747 - the first one matching the echoed command and skipping an optional prefix, 98748 - the second one matching the output and the prompt. 98749 98750 This is error-prone, because the first gdb_test_multiple has implicit 98751 clauses which may consume the prompt. 98752 98753 The problem is easy to spot with an example. First consider: 98754 ... 98755 set output [capture_command_output "print 1" "\\\$1 = "] 98756 gdb_assert { [string equal $output "1"] } 98757 ... 98758 for which we get: 98759 ... 98760 PASS: [string equal $output "1"] 98761 ... 98762 98763 If we change the prefix string to a no-match, say "1 = ", and update the 98764 output string match accordingly, we get instead: 98765 ... 98766 FAIL: capture_command_output for print 1 98767 FAIL: [string equal $output "\$1 = 1"] 98768 ... 98769 98770 The first FAIL is produced by the first gdb_test_multiple, consuming the prompt. 98771 98772 The second gdb_test_multiple then silently times out waiting for another prompt, 98773 after which the second FAIL is produced. Note that the timeout is silent 98774 because the gdb_test_multiple is called with an empty message argument. 98775 98776 The second FAIL is because capture_command_output returns "", given that all 98777 the command output was consumed by the first gdb_test_multiple. 98778 98779 Fix this by rewriting capture_command_output to use only a single 98780 gdb_test_multiple. 98781 98782 Tested on x86_64-linux. 98783 987842022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98785 98786 gprofng: no need to build version.texi 98787 gprofng/ChangeLog 98788 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98789 98790 PR gprofng/29465 98791 PR gprofng/29667 98792 * doc/Makefile.am: No need to build version.texi. 98793 * doc/Makefile.in: Rebuild. 98794 987952022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98796 98797 gprofng: use the --libdir path to find libraries 98798 gprofng/ChangeLog 98799 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98800 98801 PR gprofng/29663 98802 * src/Makefile.am: Add -DLIBDIR to CPPFLAGS. 98803 * src/Makefile.in: Rebuild. 98804 * src/envsets.cc (putenv_libcollector_ld_misc): Use LIBDIR to find 98805 the gprofng libraries. 98806 988072022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98808 98809 gprofng: run tests without installation 98810 gprofng/ChangeLog 98811 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 98812 98813 PR gprofng/29107 98814 * testsuite/config/default.exp: Set up environment to run gprofng tests 98815 without installation. 98816 * testsuite/lib/Makefile.skel: Likewise. 98817 * testsuite/lib/display-lib.exp: Likewise. 98818 988192022-10-11 Simon Marchi <simon.marchi@polymtl.ca> 98820 98821 gdb/testsuite: fix race in gdb.base/async-shell.exp 98822 I see some random failures in this test: 98823 98824 FAIL: gdb.base/async-shell.exp: run & (timeout) 98825 98826 It can be reliably reproduced on a recent enough GNU/Linux with this 98827 change: 98828 98829 diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp 98830 index 44cc28b30051..2a3c8253ba5a 100644 98831 --- a/gdb/testsuite/lib/gdb.exp 98832 +++ b/gdb/testsuite/lib/gdb.exp 98833 @@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } { 98834 } 98835 set gdb_test_name "$message" 98836 98837 + sleep 2 98838 set result 0 98839 set code [catch {gdb_expect $code} string] 98840 98841 "recent enough" means a system where libpthread.so was merged with 98842 libc.so, so at least glibc 2.34. 98843 98844 The problem is that the `run &` command prints some things after the 98845 prompt: 98846 98847 (gdb) [Thread debugging using libthread_db enabled] 98848 Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 98849 98850 If expect is quick enough, it will consume only up to the prompt. But 98851 if it is slow enough, it will consume those messages at the same time as 98852 the prompt, in which case the gdb_test used for "run &" won't match. By 98853 default, the prompt used by gdb_test uses a `$` to anchor the match at 98854 the end of the buffer. If there's anything following the prompt, it 98855 won't match. 98856 98857 The diff above adds a delay between sending the command and consuming 98858 the output, giving GDB more time to output the messages, giving a good 98859 chance that expect consumes them at the same time as the prompt. 98860 98861 This is normally handled by using gdb_test_multiple and specifying a 98862 pattern that ends with "$gdb_prompt", but not a trailing $. I think 98863 this is common enough that it deserves its own gdb_test option. 98864 Therefore, add the -no-anchor-prompt option to gdb_test, and 98865 gdb_test_no_output for completeness. Use it in 98866 gdb.base/async-shell.exp. 98867 98868 Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b 98869 Approved-By: Tom de Vries <tdevries@suse.de> 98870 988712022-10-11 GDB Administrator <gdbadmin@sourceware.org> 98872 98873 Automatic date update in version.in 98874 988752022-10-10 Tom Tromey <tom@tromey.com> 98876 98877 Fix a latent bug in print_wchar 98878 print_wchar keeps track of when escape sequences are emitted, to force 98879 an escape sequence if needed by a subsequent character. For example 98880 for the string concatenation "\0" "1", gdb will print "\000\061" -- 98881 because printing "\0001" might be confusing. 98882 98883 However, this code has two errors. First, this logic is not needed 98884 for octal escapes, because there is a length limit of 3 for octal 98885 escapes, and gdb always prints these with "%.3o". Second, though, 98886 this *is* needed for hex escapes, because those do not have a length 98887 limit. 98888 98889 This patch fixes these problems and adds the appropriate tests. 98890 988912022-10-10 Tom Tromey <tom@tromey.com> 98892 98893 Don't use wchar_printable in print_wchar 98894 print_wchar uses wchar_printable, but this isn't needed -- all the 98895 relevant cases are already handled by the 'switch'. This changes the 98896 code to use gdb_iswprint, and removes a somewhat confusing comment 98897 related to this code. 98898 98899 Remove c_printstr 98900 This renames c_printstr, removing a layer of indirection. 98901 98902 Remove c_emit_char 98903 This renames c_emit_char, removing a layer of indirection. 98904 98905 Boolify need_escape in generic_emit_char 98906 This changes 'need_escape' in generic_emit_char to be of type bool, 98907 rather than int. 98908 989092022-10-10 Tom Tromey <tom@tromey.com> 98910 Andrew Burgess <aburgess@redhat.com> 98911 98912 Fix latent quote char bug in generic_printstr 98913 generic_printstr prints an empty string like: 98914 98915 fputs_filtered ("\"\"", stream); 98916 98917 However, this seems wrong to me if the quote character is something 98918 other than double quote. This patch fixes this latent bug. Thanks to 98919 Andrew for the test case. 98920 989212022-10-10 Tom Tromey <tromey@adacore.com> 98922 98923 Fix the guile build 98924 The frame_info_ptr patches broke the build with Guile. This patch 98925 fixes the problem. In mos cases I chose to preserve the use of 98926 frame_info_ptr, at least where I could be sure that the object 98927 lifetime did not interact with Guile's longjmp-based exception scheme. 98928 98929 Tested on x86-64 Fedora 34. 98930 989312022-10-10 Tom de Vries <tdevries@suse.de> 98932 98933 [gdb/testsuite] Detect trailing ^C/^D in command 98934 Detect a trailing ^C/^D in the command argument of gdb_test_multiple, and 98935 error out. 98936 98937 Tested on x86_64-linux. 98938 989392022-10-10 Tom de Vries <tdevries@suse.de> 98940 98941 [gdb/testsuite] Fix error message for cmd with trailing newline 98942 I noticed that the error message in gdb_test_multiple about trailing newline 98943 in a command does not mention the offending command, nor the word command: 98944 ... 98945 if [string match "*\[\r\n\]" $command] { 98946 error "Invalid trailing newline in \"$message\" test" 98947 } 98948 ... 98949 98950 Fix this by using instead: 98951 ... 98952 error "Invalid trailing newline in \"$command\" command" 98953 ... 98954 98955 Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp. 98956 98957 Tested on x86_64-linux. 98958 989592022-10-10 Andrew Burgess <aburgess@redhat.com> 98960 98961 gdb: include the base address in in-memory bfd filenames 98962 The struct target_buffer (in gdb_bfd.c) is used to hold information 98963 about an in-memory BFD object created by GDB. For now this mechanism 98964 is used by GDB when loading information about JIT symfiles. 98965 98966 This commit updates target_buffer (in gdb_bfd.c) to be more C++ like, 98967 and, at the same time, adds the base address of the symfile into the 98968 BFD filename. 98969 98970 Right now, every in-memory BFD is given the filename "<in-memory>". 98971 This filename is visible in things like 'maint info symtabs' and 98972 'maint info line-table'. If there are multiple in-memory BFD objects 98973 then it can be hard to match keep track if which BFD is which. This 98974 commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is 98975 replaced with the base address for where the in-memory symbol file was 98976 read from. 98977 98978 As an example of how this is useful, here's the output of 'maint info 98979 jit' showing a single loaded JIT symfile: 98980 98981 (gdb) maintenance info jit 98982 jit_code_entry address symfile address symfile size 98983 0x00000000004056b0 0x0000000007000000 17320 98984 98985 And here's part of the output from 'maint info symtabs': 98986 98987 (gdb) maintenance info symtabs 98988 ...snip... 98989 { objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250) 98990 { ((struct compunit_symtab *) 0x4f0afb0) 98991 debugformat DWARF 4 98992 producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic 98993 name jit-elf-solib.c 98994 dirname /tmp/binutils-gdb/build/gdb/testsuite 98995 blockvector ((struct blockvector *) 0x5477850) 98996 user ((struct compunit_symtab *) (null)) 98997 { symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030) 98998 fullname (null) 98999 linetable ((struct linetable *) 0x5477880) 99000 } 99001 } 99002 } 99003 99004 I've added a new test that checks the new in-memory file names are 99005 generated correctly, and also checks that the in-memory JIT files can 99006 be dumped back out using 'dump binary memory'. 99007 990082022-10-10 Andrew Burgess <aburgess@redhat.com> 99009 99010 gdb: remove filename arg from gdb_bfd_open_from_target_memory 99011 The filename argument to gdb_bfd_open_from_target_memory was never 99012 used; this argument had a default value of nullptr, and the only call 99013 to this function, in jit.c, relied on the default value. 99014 99015 In the next commit I'm going to make some changes to the 99016 gdb_bfd_open_from_target_memory function, and, though I could take 99017 account of a filename parameter, it seems pointless to maintain an 99018 unused argument. 99019 99020 This commit removes the filename argument. 99021 99022 There should be no user visible changes after this commit. 99023 990242022-10-10 Andrew Burgess <aburgess@redhat.com> 99025 99026 gdb: add infcall specific debugging 99027 Add two new commands: 99028 99029 set debug infcall on|off 99030 show debug infcall 99031 99032 These enable some new debugging related to when GDB makes inferior 99033 function calls. I've added some basic debugging for what I think are 99034 the major steps in the inferior function call process, but I'm sure we 99035 might want to add more later. 99036 990372022-10-10 Andrew Burgess <aburgess@redhat.com> 99038 99039 gdb: extra debug output in thread.c 99040 Add some extra 'threads' debug in a couple of places in thread.c. 99041 I've also added an additional gdb_assert in one case. 99042 99043 gdb: improve infrun_debug_show_threads output 99044 This commit switches to use INFRUN_SCOPED_DEBUG_START_END in the 99045 infrun_debug_show_threads function, which means the output will get an 99046 extra level of indentation, this looks a little nicer I think. 99047 990482022-10-10 Nick Clifton <nickc@redhat.com> 99049 99050 Add ability to create reproducible source tarballs. 99051 * src-release.sh: Add "-r <date>" option to create reproducible 99052 tarballs based upon a fixed timestamp of <date>. 99053 * binutils/README-how-to-make-a-release: Add a line showing how to 99054 use -r <date> when creating a binutils release. 99055 990562022-10-10 Bruno Larsen <blarsen@redhat.com> 99057 99058 gdb/frame: Add reinflation method for frame_info_ptr 99059 Currently, despite having a smart pointer for frame_infos, GDB may 99060 attempt to use an invalidated frame_info_ptr, which would cause internal 99061 errors to happen. One such example has been documented as PR 99062 python/28856, that happened when printing frame arguments calls an 99063 inferior function. 99064 99065 To avoid failures, the smart wrapper was changed to also cache the frame 99066 id, so the pointer can be reinflated later. For this to work, the 99067 frame-id stuff had to be moved to their own .h file, which is included 99068 by frame-info.h. 99069 99070 Frame_id caching is done explicitly using the prepare_reinflate method. 99071 Caching is done manually so that only the pointers that need to be saved 99072 will be, and reinflating has to be done manually using the reinflate 99073 method because the get method and the -> operator must not change 99074 the internals of the class. Finally, attempting to reinflate when the 99075 pointer is being invalidated causes the following assertion errors: 99076 99077 check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed. 99078 get_frame_pc: Assertion `frame->next != NULL` failed. 99079 99080 As for performance concerns, my personal testing with `time make 99081 chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around 99082 10% of time running. 99083 99084 This commit also adds a testcase that exercises the python/28856 bug with 99085 7 different triggers, run, continue, step, backtrace, finish, up and down. 99086 Some of them can seem to be testing the same thing twice, but since this 99087 test relies on stale pointers, there is always a chance that GDB got lucky 99088 when testing, so better to test extra. 99089 99090 Regression tested on x86_64, using both gcc and clang. 99091 99092 Approved-by: Tom Tomey <tom@tromey.com> 99093 990942022-10-10 Tom Tromey <tom@tromey.com> 99095 99096 Change GDB to use frame_info_ptr 99097 This changes GDB to use frame_info_ptr instead of frame_info * 99098 The substitution was done with multiple sequential `sed` commands: 99099 99100 sed 's/^struct frame_info;/class frame_info_ptr;/' 99101 sed 's/struct frame_info \*/frame_info_ptr /g' - which left some 99102 issues in a few files, that were manually fixed. 99103 sed 's/\<frame_info \*/frame_info_ptr /g' 99104 sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace 99105 problems. 99106 99107 The changed files were then manually checked and some 'sed' changes 99108 undone, some constructors and some gets were added, according to what 99109 made sense, and what Tromey originally did 99110 99111 Co-Authored-By: Bruno Larsen <blarsen@redhat.com> 99112 Approved-by: Tom Tomey <tom@tromey.com> 99113 991142022-10-10 Tom Tromey <tom@tromey.com> 99115 99116 Introduce frame_info_ptr smart pointer class 99117 This adds frame_info_ptr, a smart pointer class. Every instance of 99118 the class is kept on an intrusive list. When reinit_frame_cache is 99119 called, the list is traversed and all the pointers are invalidated. 99120 This should help catch the typical GDB bug of keeping a frame_info 99121 pointer alive where a frame ID was needed instead. 99122 99123 Co-Authored-By: Bruno Larsen <blarsen@redhat.com> 99124 Approved-by: Tom Tomey <tom@tromey.com> 99125 991262022-10-10 Tom Tromey <tom@tromey.com> 99127 99128 Remove frame_id_eq 99129 This replaces frame_id_eq with operator== and operator!=. I wrote 99130 this for a version of this series that I later abandoned; but since it 99131 simplifies the code, I left this patch in. 99132 99133 Approved-by: Tom Tomey <tom@tromey.com> 99134 991352022-10-10 Andrew Burgess <aburgess@redhat.com> 99136 99137 gdb/testsuite: use 'end' at the end of python blocks 99138 Within the testsuite, use the keyword 'end' to terminate blocks of 99139 Python code being sent to GDB, rather than sending \004. I could only 99140 find three instances of this, all in tests that I originally wrote. I 99141 have no memory of there being any special reason why I used \004 99142 instead of 'end' - I assume I copied this from somewhere else that has 99143 since changed. 99144 99145 Non of the tests being changed here are specifically about whether 99146 \004 can be used to terminate a Python block, so I think switching to 99147 the more standard 'end' keyword is the right choice. 99148 991492022-10-10 Simon Marchi <simon.marchi@polymtl.ca> 99150 99151 gdbsupport: re-generate configure 99152 I get this diff when re-generating configure, probably leftover from 99153 67d1991b785 ("egrep in binutils"). 99154 99155 Change-Id: I759c88c2bad648736d33ff98089db45c9b686356 99156 991572022-10-10 Alan Modra <amodra@gmail.com> 99158 99159 Merge configure.ac from gcc project 99160 To merge with gcc's copy of configure.ac we need to revert changes to 99161 configure.ac in the following gcc commits: 99162 dc832fb39fc0 2022-08-25 99163 fc259b522c0f 2022-06-25 99164 Then reapply configure.ac changes in binutils from these binutils 99165 commits: 99166 50ad1254d503 2021-01-09 99167 bb368aad297f 2022-03-11 99168 e5f2f7d901ee 2022-07-26 99169 2cac01e3ffff 2022-09-26 99170 Plus copy over gcc's config/ax_cxx_compile_stdcxx.m4, then regenerate 99171 configure. 99172 991732022-10-10 GDB Administrator <gdbadmin@sourceware.org> 99174 99175 Automatic date update in version.in 99176 991772022-10-09 GDB Administrator <gdbadmin@sourceware.org> 99178 99179 Automatic date update in version.in 99180 991812022-10-08 Tom Tromey <tom@tromey.com> 99182 99183 Merge both implementations of debug_names::insert 99184 The class debug_names has two 'insert' overloads, but only one of them 99185 is ever called externally, and it simply forwards to the other 99186 implementation. It seems cleaner to me to have a single method, so 99187 this patch merges the two. 99188 991892022-10-08 Tom de Vries <tdevries@suse.de> 99190 99191 [gdb/testsuite] Fix silent fail in gdb.server/connect-with-no-symbol-file.exp 99192 With native and target boards native-gdbserver, remote-gdbserver-on-localhost and 99193 remote-stdio-gdbserver I have for gdb.server/connect-with-no-symbol-file.exp: 99194 ... 99195 # of expected passes 8 99196 ... 99197 but with native-extended-gdbserver I have instead: 99198 ... 99199 # of expected passes 8 99200 # of unexpected failures 4 99201 ... 99202 99203 The extra FAILs are of the form: 99204 ... 99205 (gdb) detach^M 99206 Detaching from pid process 28985^M 99207 [Inferior 1 (process 28985) detached]^M 99208 (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \ 99209 action=permission: connection to GDBserver succeeded 99210 ... 99211 and are due to the fact that the actual gdb output doesn't match the regexp: 99212 ... 99213 gdb_test "detach" \ 99214 ".*Detaching from program: , process.*Ending remote debugging.*" \ 99215 "connection to GDBserver succeeded" 99216 ... 99217 99218 With native, the actual gdb output is: 99219 ... 99220 (gdb) detach^M 99221 Detaching from pid process 29657^M 99222 Ending remote debugging.^M 99223 [Inferior 1 (process 29657) detached]^M 99224 (gdb) Remote debugging from host ::1, port 51028^M 99225 ... 99226 and because the regexp doesn't match, it triggers an implicit clause for 99227 "Ending remote debugging" in gdb_test_multiple, which has the consequence 99228 that the FAIL is silent. 99229 99230 Fix: 99231 - the regexp by making it less strict 99232 - the silent fail by rewriting into a gdb_test_multiple, and adding an 99233 explicit fail clause. 99234 99235 Tested on x86_64-linux, using native and aforementioned target boards. 99236 992372022-10-08 GDB Administrator <gdbadmin@sourceware.org> 99238 99239 Automatic date update in version.in 99240 992412022-10-07 Lancelot SIX <lancelot.six@amd.com> 99242 99243 gdb/testsuite: fix gdb.threads/linux-dp.exp regex 99244 On ubuntu 22.04 with the libc6-dbg package installed, I have the 99245 following failure: 99246 99247 where 99248 #0 print_philosopher (n=3, left=33 '!', right=33 '!') at .../gdb/testsuite/gdb.threads/linux-dp.c:105 99249 #1 0x000055555555576a in philosopher (data=0x55555555937c) at .../gdb/testsuite/gdb.threads/linux-dp.c:148 99250 #2 0x00007ffff7e11b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 99251 #3 0x00007ffff7ea3a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 99252 (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit 99253 99254 The regex for this test accounts for different situations (with / 99255 without debug symbol) but assumes that if debug info is present the 99256 backtrace shows execution under pthread_create. However, for the 99257 implementation under test, we are under start_thread. 99258 99259 Update the regex to accept start_thread. 99260 99261 Tested on Ubuntu-22.04 x86_64 with and without libc6-dbg debug symbols 99262 available. 99263 99264 Change-Id: I1e1536279890bca2cd07f038e026b41e46af44e0 99265 992662022-10-07 Tom de Vries <tdevries@suse.de> 99267 99268 [gdb/testsuite] Handle host cleanfiles 99269 When running test-case gdb.server/abspath.exp with host board 99270 local-remote-host-notty, I get: 99271 ... 99272 $ git sti 99273 ... 99274 deleted: gdb/testsuite/gdb.xml/trivial.xml 99275 ... 99276 99277 This happens as follows. The test-case calls skip_gdbserver_test, which calls 99278 gdb_skip_xml_test, which does: 99279 ... 99280 set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"] 99281 ... 99282 99283 Then proc gdb_remote_download appends $xml_file (which for this particular 99284 host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which 99285 ends up being handled in gdb_finish by: 99286 ... 99287 eval remote_file target delete $cleanfiles 99288 ... 99289 99290 The problem is that a host file is deleted using target delete. 99291 99292 Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host. 99293 99294 Tested on x86_64-linux. 99295 992962022-10-07 Tom de Vries <tdevries@suse.de> 99297 99298 [gdb/testsuite] Remove unnecessary warning in gdb.base/default.exp 99299 When running test-case gdb.base/default.exp with target board 99300 native-gdbserver, we get: 99301 ... 99302 WARNING: Skipping backtrace and break tests because of GDB stub. 99303 ... 99304 99305 There's no need for such a warning, so remove it. 99306 99307 Tested on x86_64-linux with native and target board native-gdbserver. 99308 993092022-10-07 Tom de Vries <tdevries@suse.de> 99310 99311 [gdb/testsuite] Fix have_mpx with remote-gdbserver-on-localhost 99312 With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp 99313 I run into: 99314 ... 99315 FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation 99316 ... 99317 99318 This is due to the have_mpx test which should return 0, but instead returns 1 99319 because the captured output: 99320 ... 99321 No MPX support 99322 No MPX support 99323 ... 99324 does not match the used regexp: 99325 ... 99326 set status [expr ($status == 0) \ 99327 && ![regexp "^No MPX support\r\n" $output]] 99328 ... 99329 which does match the captured output with native: 99330 ... 99331 No MPX support^M 99332 No MPX support^M 99333 ... 99334 99335 Fix this by making the \r in the regexp optional. 99336 99337 Tested on x86_64-linux, with native and target board 99338 remote-gdbserver-on-localhost. 99339 993402022-10-07 Tom de Vries <tdevries@suse.de> 99341 99342 [gdb/testsuite] Fix DUPLICATEs with remote-gdbserver-on-localhost 99343 Fix some DUPLICATEs that we run into with target board 99344 remote-gdbserver-on-localhost, by using test_with_prefix. 99345 99346 Tested on x86_64-linux, with native and target board 99347 remote-gdbserver-on-localhost. 99348 993492022-10-07 Tom de Vries <tdevries@suse.de> 99350 99351 [gdb/testsuite] Fix path in test name in gdb_load_shlib 99352 When running test-case gdb.server/solib-list.exp with target board 99353 remote-gdbserver-on-localhost, I run into: 99354 ... 99355 (gdb) set solib-search-path $outputs/gdb.server/solib-list^M 99356 (gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \ 99357 set solib-search-path $outputs/gdb.server/solib-list 99358 PATH: gdb.server/solib-list.exp: non-stop 0: \ 99359 set solib-search-path $outputs/gdb.server/solib-list 99360 ... 99361 99362 This is due to this code in gdb_load_shlib: 99363 ... 99364 gdb_test "set solib-search-path [file dirname $file]" "" "" 99365 ... 99366 99367 Fix this by setting an explicit test name. 99368 99369 Tested on x86_64-linux, with native and target boards 99370 remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver. 99371 993722022-10-07 Alan Modra <amodra@gmail.com> 99373 99374 PR29653, objcopy/strip: fuzzed small input file induces large output file 99375 _bfd_check_format functions should not print errors or warnings if 99376 they return NULL. A NULL return means the particular target under 99377 test does not match, so there isn't any reason to make a complaint 99378 about the target. In fact there isn't a good reason to warn even if 99379 the target matches, except via the _bfd_per_xvec_warn mechanism; Some 99380 other target might be a better match. 99381 99382 This patch tidies pe_bfd_object_p with the above in mind, and 99383 restricts the PE optional header SectionAlignment and FileAlignment 99384 fields somewhat. I chose to warn on nonsense values rather than 99385 refusing to match. Refusing to match would be OK too. 99386 99387 PR 29653 99388 * peXXigen.c (_bfd_XXi_swap_aouthdr_in): Don't emit error about 99389 invalid NumberOfRvaAndSizes here. Limit loop copying data 99390 directory to IMAGE_NUMBEROF_DIRECTORY_ENTRIES. 99391 * peicode.h (pe_bfd_object_p): Don't clear and test bfd_error 99392 around bfd_coff_swap_aouthdr_in. Warn on invalid SectionAlignment, 99393 FileAlignment and NumberOfRvaAndSizes. Don't return NULL on 99394 invalid NumberOfRvaAndSizes. 99395 993962022-10-07 GDB Administrator <gdbadmin@sourceware.org> 99397 99398 Automatic date update in version.in 99399 994002022-10-06 Tom Tromey <tromey@adacore.com> 99401 99402 Fix indentation in riscv-tdep.c 99403 This just fixes some indentation in riscv-tdep.c. 99404 994052022-10-06 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 99406 99407 gdb/arm: Handle lazy FPU state preservation 99408 Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together 99409 with FPCAR to identify if lazy FPU state preservation is active for 99410 the current frame. See "Lazy context save of FP state", in B1.5.7, 99411 also ARM AN298, supported by Cortex-M4F architecture for details on 99412 lazy FPU register stacking. The same conditions are valid for other 99413 Cortex-M cores with FPU. 99414 99415 This patch has been verified on a STM32F4-Discovery board by: 99416 a) writing a non-zero value (lets use 0x1122334455667788 as an 99417 example) to all the D-registers in the main function 99418 b) configured the SysTick to fire 99419 c) in the SysTick_Handler, write some other value (lets use 99420 0x0022446688aaccee as an example) to one of the D-registers (D0 as 99421 an example) and then do "SVC #0" 99422 d) in the SVC_Handler, write some other value (lets use 99423 0x0099aabbccddeeff) to one of the D-registers (D0 as an example) 99424 99425 In GDB, suspend the execution in the SVC_Handler function and compare 99426 the value of the D-registers for the SVC_handler frame and the 99427 SysTick_Handler frame. With the patch, the value of the modified 99428 D-register (D0) should be the new value (0x009..eff) on the 99429 SVC_Handler frame, and the intermediate value (0x002..cee) for the 99430 SysTick_Handler frame. Now compare the D-register value for the 99431 SysTick_Handler frame and the main frame. The main frame should 99432 have the initial value (0x112..788). 99433 994342022-10-06 Tom de Vries <tdevries@suse.de> 99435 99436 [gdb/symtab] Factor out have_complaint 99437 After committing 8ba677d3560 ("[gdb/symtab] Don't complain about function 99438 decls") I noticed that quite a bit of code in read_func_scope is used to decide 99439 whether to issue the "cannot get low and high bounds for subprogram DIE at 99440 $hex" complaint, which executes unnecessarily if we have the default 99441 "set complaints 0". 99442 99443 Fix this by (NFC): 99444 - factoring out new static function have_complaint from macro complaint, and 99445 - using it to wrap the relevant code in read_func_scope. 99446 99447 Tested on x86_64-linux. 99448 994492022-10-06 Andrew Burgess <aburgess@redhat.com> 99450 99451 gdb: add missing nullptr checks in bpstat_check_breakpoint_conditions 99452 Add a couple of missing nullptr checks in the function 99453 bpstat_check_breakpoint_conditions. 99454 99455 No user visible change after this commit. 99456 994572022-10-06 Andrew Burgess <aburgess@redhat.com> 99458 99459 gdb: more infrun debug from breakpoint.c 99460 This commit adds additional infrun debug from the breakpoint.c file. 99461 The new debug output all relates to breakpoint condition evaluation. 99462 99463 There is already some infrun debug emitted from the breakpoint.c file, 99464 so hopefully, adding more will not be contentious. I think the 99465 functions being instrumented make sense as part of the infrun process, 99466 the inferior stops, evaluates the condition, and then either stops or 99467 continues. This new debug gives more insight into that process. 99468 99469 I had to make the bp_location* argument to find_loc_num_by_location 99470 const, and add a declaration for find_loc_num_by_location. 99471 99472 There should be no user visible changes unless they turn on debug 99473 output. 99474 994752022-10-06 Andrew Burgess <aburgess@redhat.com> 99476 99477 gdb: add some additional debug in mark_async_event_handler 99478 Extend the existing debug printf call to include the previous state of 99479 the async_event_handler object. 99480 994812022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99482 99483 RISC-V: Print XTheadMemPair literal as "immediate" 99484 The operand type "Xl(...)" denotes that (...) is a literal. Specifically, 99485 they are intended to be a constant immediate value. 99486 99487 This commit prints "Xl(...)" operand with dis_style_immediate style, 99488 not dis_style_text. 99489 99490 opcodes/ChangeLog: 99491 99492 * riscv-dis.c (print_insn_args): Use dis_style_immediate on 99493 the constant literal of the "Xl..." operand. 99494 994952022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99496 99497 RISC-V: Fix T-Head immediate types on printing 99498 This commit fixes two minor typing-related issues for 99499 T-Head immediate operands. 99500 99501 1. A signed type must be specified when printing with %i. 99502 2. unsigned/signed int is not portable enough for max 32-bit immediates. 99503 Instead, we should use unsigned/signed long. 99504 The format string is changed accordingly. 99505 99506 opcodes/ChangeLog: 99507 99508 * riscv-dis.c (print_insn_args): Fix T-Head immediate types on 99509 printing. 99510 995112022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99512 99513 RISC-V: Print comma and tabs as the "text" style 99514 On the RISC-V disassembler, some separators have non-text style when 99515 printed with another word with another style. 99516 99517 This commit splits those, making sure that those comma and tabs are printed 99518 with the "text" style. 99519 99520 opcodes/ChangeLog: 99521 99522 * riscv-dis.c (print_insn_args): Split and print the comma as 99523 text. (riscv_disassemble_insn): Split and print tabs as text. 99524 (riscv_disassemble_data): Likewise. 99525 995262022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99527 99528 RISC-V: Optimize riscv_disassemble_data printf 99529 This commit makes types of printf arguments on riscv_disassemble_data 99530 as small as possible (as long as we can preserve the portability) to reduce 99531 the cost of printf (especially on 32-bit host). 99532 99533 opcodes/ChangeLog: 99534 99535 * riscv-dis.c (riscv_disassemble_data): Use smallest possible type 99536 to printing data. 99537 995382022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99539 99540 RISC-V: Fix printf argument types corresponding %x 99541 "%x" format specifier requires unsigned type, not int. This commit 99542 fixes this issue on the RISC-V disassembler. 99543 99544 opcodes/ChangeLog: 99545 99546 * riscv-dis.c (print_insn_args): Fix printf argument types where 99547 the format specifier is "%x". 99548 995492022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com> 99550 99551 RISC-V: Fix immediates to have "immediate" style 99552 This commit fixes certain print calls on immediate operands to have 99553 dis_style_immediate. 99554 99555 opcodes/ChangeLog: 99556 99557 * riscv-dis.c (print_insn_args): Fix immediates to have 99558 "immediate" style. (riscv_disassemble_data): Likewise. 99559 995602022-10-06 GDB Administrator <gdbadmin@sourceware.org> 99561 99562 Automatic date update in version.in 99563 995642022-10-06 Alan Modra <amodra@gmail.com> 99565 99566 Re: bfd BLD-POTFILES.in dependencies 99567 Removing $BLD_POTFILES from BFD-POTFILES.in was correct, but left a 99568 hole in dependencies. 99569 make[4]: Entering directory '/home/alan/build/gas/all/bfd/po' 99570 make[4]: *** No rule to make target '../elf32-aarch64.c', needed by '/home/alan/src/binutils-gdb/bfd/po/bfd.pot'. Stop. 99571 99572 * Makefile.am (BUILT_SOURCES): Add BUILD_CFILES. 99573 * Makefile.in: Regenerate. 99574 995752022-10-05 Jan Beulich <jbeulich@suse.com> 99576 99577 x86/gas: support quoted address scale factor in AT&T syntax 99578 An earlier attempt (e68c3d59acd0 ["x86: better respect quotes in 99579 parse_operands()"]) needed undoing (cc0f96357e0b ["x86: permit 99580 parenthesized expressions again as addressing scale factor"]) as far its 99581 effect here went. As indicated back then, the issue is the backwards 99582 scanning of the operand string to find the matching opening parenthesis. 99583 Switch to forward scanning, finding the last outermost unquoted opening 99584 parenthesis (which is the one matching the trailing closing one). 99585 99586 Arm64: support CLEARBHB alias 99587 While the Arm v8 ARM (rev I-a) still doesn't mention this alias, it is 99588 (typically via a macro) already in use in kernels and alike. 99589 995902022-10-05 Alan Modra <amodra@gmail.com> 99591 99592 PR29647, objdump -S looping 99593 Fuzzed input with this in .debug_line 99594 [0x0000003b] Special opcode 115: advance Address by 8 to 0x401180 and Line by -2 to -1 99595 99596 PR 29647 99597 * objdump.c (print_line): Don't decrement line number here.. 99598 (dump_lines): ..do so here instead, ensuring loop terminates. 99599 996002022-10-05 Alan Modra <amodra@gmail.com> 99601 99602 Re: stab nearest_line bfd_malloc_and_get_section 99603 It didn't take long for the fuzzers to avoid size checks in 99604 bfd_malloc_and_get_section. Plug this hole. 99605 99606 * syms.c (_bfd_stab_section_find_nearest_line): Ignore fuzzed 99607 sections with no contents. 99608 996092022-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 99610 99611 gprofng: fix build with --enable-pgo-build=lto 99612 gprofng/ChangeLog 99613 2022-10-04 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 99614 99615 PR gprofng/29579 99616 * libcollector/dispatcher.c: Fix the symbol version in SYMVER_ATTRIBUTE. 99617 * libcollector/iotrace.c: Likewise. 99618 * libcollector/linetrace.c: Likewise. 99619 * libcollector/mmaptrace.c: Likewise. 99620 * libcollector/synctrace.c: Likewise. 99621 996222022-10-05 GDB Administrator <gdbadmin@sourceware.org> 99623 99624 Automatic date update in version.in 99625 996262022-10-04 Tom Tromey <tom@tromey.com> 99627 99628 Remove decode_location_spec_default 99629 This removes decode_location_spec_default, inlining it into its sole 99630 caller. 99631 99632 Regression tested on x86-64 Fedora 34. 99633 996342022-10-04 Palmer Dabbelt <palmer@rivosinc.com> 99635 99636 gas: NEWS: Mention the T-Head extensions that were recently added 99637 996382022-10-04 Tom de Vries <tdevries@suse.de> 99639 99640 [gdb/symtab] Don't complain about function decls 99641 [ Requires "[gdb/symtab] Don't complain about inlined functions" as 99642 submitted here ( 99643 https://sourceware.org/pipermail/gdb-patches/2022-September/191762.html ). ] 99644 99645 With the test-case included in this patch, we get: 99646 ... 99647 (gdb) ptype main^M 99648 During symbol reading: cannot get low and high bounds for subprogram DIE \ 99649 at 0xc1^M 99650 type = int (void)^M 99651 (gdb) FAIL: gdb.dwarf2/anon-ns-fn.exp: ptype main without complaints 99652 ... 99653 99654 The DIE causing the complaint is a function declaration: 99655 ... 99656 <2><c1>: Abbrev Number: 3 (DW_TAG_subprogram) 99657 <c2> DW_AT_name : foo 99658 <c8> DW_AT_declaration : 1 99659 ... 99660 which is referred to from the DIE representing the function definition: 99661 ... 99662 <1><f4>: Abbrev Number: 7 (DW_TAG_subprogram) 99663 <f5> DW_AT_specification: <0xc1> 99664 <f9> DW_AT_low_pc : 0x4004c7 99665 <101> DW_AT_high_pc : 0x7 99666 ... 99667 which does contain the low and high bounds. 99668 99669 Fix this by not complaining about function declarations. 99670 99671 Tested on x86_64-linux. 99672 996732022-10-04 Tom de Vries <tdevries@suse.de> 99674 99675 [gdb/symtab] Don't complain about inlined functions 99676 With the test-case included in this patch, we get: 99677 ... 99678 (gdb) ptype main^M 99679 During symbol reading: cannot get low and high bounds for subprogram DIE \ 99680 at 0x113^M 99681 During symbol reading: cannot get low and high bounds for subprogram DIE \ 99682 at 0x11f^M 99683 type = int (void)^M 99684 (gdb) FAIL: gdb.dwarf2/inline.exp: ptype main 99685 ... 99686 99687 The complaints are about foo, with DW_AT_inline == DW_INL_inlined: 99688 ... 99689 <1><11f>: Abbrev Number: 6 (DW_TAG_subprogram) 99690 <120> DW_AT_name : foo 99691 <126> DW_AT_prototyped : 1 99692 <126> DW_AT_type : <0x10c> 99693 <12a> DW_AT_inline : 1 (inlined) 99694 ... 99695 and foo2, with DW_AT_inline == DW_INL_declared_inlined: 99696 ... 99697 <1><113>: Abbrev Number: 5 (DW_TAG_subprogram) 99698 <114> DW_AT_name : foo2 99699 <11a> DW_AT_prototyped : 1 99700 <11a> DW_AT_type : <0x10c> 99701 <11e> DW_AT_inline : 3 (declared as inline and inlined) 99702 ... 99703 99704 Fix this by not complaining about inlined functions. 99705 99706 Tested on x86_64-linux. 99707 997082022-10-04 Tsukasa OI <research_trasio@irq.a4lg.com> 99709 99710 gdb/riscv: Partial support for instructions up to 176-bit 99711 Because riscv_insn_length started to support instructions up to 176-bit, 99712 we need to increase buf size to 176-bit in size. 99713 99714 Also, that would break an assumption in riscv_insn::decode so this commit 99715 fixes it, noting that instructions longer than 64-bit are not fully 99716 supported yet. 99717 997182022-10-04 Tsukasa OI <research_trasio@irq.a4lg.com> 99719 99720 RISC-V: Fix buffer overflow on print_insn_riscv 99721 Because riscv_insn_length started to support instructions up to 176-bit, 99722 we need to increase packet buffer size to 176-bit in size. 99723 99724 include/ChangeLog: 99725 99726 * opcode/riscv.h (RISCV_MAX_INSN_LEN): Max instruction length for 99727 use in buffer size. 99728 99729 opcodes/ChangeLog: 99730 99731 * riscv-dis.c (print_insn_riscv): Increase buffer size for max 99732 176-bit length instructions. 99733 997342022-10-04 Nelson Chu <nelson@rivosinc.com> 99735 99736 RISC-V: Renamed INSN_CLASS for floating point in integer extensions. 99737 Just added suffix _INX for those INSN_CLASS should be enough to represent 99738 their fpr can be replaced by gpr. 99739 997402022-10-04 Nick Clifton <nickc@redhat.com> 99741 99742 Note that at least dejagnu version 1.5.3 is required in order to be ale to run the testsuites. 99743 * README-maintainer-mode: Add a minimum version of dejagnu 99744 requirement. 99745 997462022-10-04 Andrew Burgess <aburgess@redhat.com> 99747 99748 opcodes/riscv: style csr names as registers 99749 While reviewing another patch I noticed that RISC-V CSR names are 99750 given the text style, not the register style. This patch fixes this 99751 mistake. 99752 997532022-10-04 Luis Machado <luis.machado@arm.com> 99754 99755 [AArch64] Update FPSR/FPCR fields for FPU and SVE 99756 I noticed some missing flags/fields from FPSR and FPCR registers in 99757 both the FPU and SVE target descriptions. 99758 99759 This patch adds those and makes the SVE versions of FPSR and FPCR 99760 use the proper flags/bitfields types. 99761 997622022-10-04 Alan Modra <amodra@gmail.com> 99763 99764 Support objcopy changing compression to or from zstd 99765 Commit 2cac01e3ffff lacked support for objcopy changing compression 99766 style. Add that support, which meant a rewrite of 99767 bfd_compress_section_contents. In the process I've fixed some memory 99768 leaks. 99769 99770 * compress.c (bfd_is_section_compressed_info): Rename from 99771 bfd_is_section_compressed_with_header and add ch_type param 99772 to return compression header ch_type field. 99773 Update all callers. 99774 (decompress_section_contents): Remove buffer and size params. 99775 Rewrite. Update callers. 99776 (bfd_init_section_compress_status): Free contents on failure. 99777 (bfd_compress_section): Likewise. 99778 * elf.c (_bfd_elf_make_section_from_shdr): Support objcopy 99779 changing between any of the three compression schemes. Report 99780 "unable to compress/decompress" rather than "unable to 99781 initialize compress/decompress status" on compress/decompress 99782 failures. 99783 * bfd-in2.h: Regenerate. 99784 997852022-10-04 Alan Modra <amodra@gmail.com> 99786 99787 Re: compress .gnu.debuglto_.debug_* sections if requested 99788 Enable zlib-gnu compression for .gnu.debuglto_.debug_*. This differs 99789 from zlib-gnu for .debug_* where the name is changed to .zdebug_*. 99790 The name change isn't really needed. 99791 99792 bfd/ 99793 * elf.c (elf_fake_sections): Replace "." with ".z" in debug 99794 section names only when name was ".d*", ie. ".debug_*". 99795 (_bfd_elf_assign_file_positions_for_non_load): Likewise. 99796 gas/ 99797 * write.c (compress_debug): Compress .gnu.debuglto_.debug_* 99798 for zlib-gnu too. Compress .gnu.linkonce.wi.*. 99799 998002022-10-04 Martin Liska <mliska@suse.cz> 99801 99802 compress .gnu.debuglto_.debug_* sections if requested 99803 Right now, when using LTO, the intermediate object files do contain 99804 debug info in sections starting with .gnu.debuglto_ prefix and are 99805 not compressed when --compress-debug-sections is used. 99806 99807 It's a mistake and we can save quite some disk space. The following 99808 example comes from tramp3d when the corresponding LTO sections 99809 are compressed with zlib: 99810 99811 $ bloaty tramp3d-v4-v2.o -- tramp3d-v4.o 99812 FILE SIZE VM SIZE 99813 -------------- -------------- 99814 +83% +10 [ = ] 0 [Unmapped] 99815 -68.0% -441 [ = ] 0 .gnu.debuglto_.debug_line 99816 -52.3% -759 [ = ] 0 .gnu.debuglto_.debug_line_str 99817 -62.4% -3.24Ki [ = ] 0 .gnu.debuglto_.debug_abbrev 99818 -64.8% -1.12Mi [ = ] 0 .gnu.debuglto_.debug_info 99819 -88.8% -4.58Mi [ = ] 0 .gnu.debuglto_.debug_str 99820 -27.7% -5.70Mi [ = ] 0 TOTAL 99821 99822 bfd/ChangeLog: 99823 99824 * elf.c (_bfd_elf_make_section_from_shdr): Compress all debug 99825 info sections. 99826 99827 gas/ChangeLog: 99828 99829 * write.c (compress_debug): Compress also ".gnu.debuglto_.debug_" 99830 if the compression algorithm is different from zlib-gnu. 99831 998322022-10-04 Jan Beulich <jbeulich@suse.com> 99833 99834 RISC-V/gas: allow generating up to 176-bit instructions with .insn 99835 For the time being simply utilize O_big to avoid widening other fields, 99836 bypassing append_insn() etc. 99837 99838 RISC-V/gas: don't open-code insn_length() 99839 Use the helper when it can be used. 99840 99841 RISC-V/gas: drop stray call to install_insn() 99842 add_fixed_insn(), by calling move_insn(), already invokes install_insn(). 99843 99844 RISC-V/gas: drop riscv_subsets static variable 99845 It's fully redundant with the subset_list member of riscv_rps_as. 99846 99847 RISC-V: don't cast expressions' X_add_number to long in diagnostics 99848 There's no need for such workarounds anymore now that we use C99 99849 uniformly. This addresses several testsuite failures encountered when 99850 (cross-)building on a 32-bit host. 99851 998522022-10-04 Potharla, Rupesh <Rupesh.Potharla@amd.com> 99853 99854 ignore DWARF debug information for -gsplit-dwarf with dwarf-5 99855 Skip dwo_id for split dwarf. 99856 99857 * dwarf2.c (parse_comp_unit): Skip DWO_id for DW_UT_skeleton. 99858 998592022-10-04 GDB Administrator <gdbadmin@sourceware.org> 99860 99861 Automatic date update in version.in 99862 998632022-10-03 Jan-Benedict Glaw <jbglaw@lug-owl.de> 99864 99865 Fix self-move warning check for GCC 13+ 99866 GCC 13 got the self-move warning (0abb78dda084a14b3d955757c6431fff71c263f3), 99867 but that warning is only checked for clang, resulting in: 99868 99869 /usr/lib/gcc-snapshot/bin/g++ -x c++ -I. -I. -I./config -DLOCALEDIR="\"/tmp/gdb-m68k-linux/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/readline/.. -I./../zlib -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/ -I../libbacktrace/ -DTUI=1 -I./.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -g -O2 -c -o unittests/environ-selftests.o -MT unittests/environ-selftests.o -MMD -MP -MF unittests/.deps/environ-selftests.Tpo unittests/environ-selftests.c 99870 unittests/environ-selftests.c: In function 'void selftests::gdb_environ_tests::test_self_move()': 99871 unittests/environ-selftests.c:228:7: error: moving 'env' of type 'gdb_environ' to itself [-Werror=self-move] 99872 228 | env = std::move (env); 99873 | ~~~~^~~~~~~~~~~~~~~~~ 99874 unittests/environ-selftests.c:228:7: note: remove 'std::move' call 99875 cc1plus: all warnings being treated as errors 99876 make[1]: *** [Makefile:1896: unittests/environ-selftests.o] Error 1 99877 make[1]: Leaving directory '/var/lib/laminar/run/gdb-m68k-linux/3/binutils-gdb/gdb' 99878 make: *** [Makefile:13193: all-gdb] Error 2 99879 998802022-10-03 Simon Marchi <simon.marchi@polymtl.ca> 99881 99882 gdb: constify inferior::target_is_pushed 99883 Change-Id: Ia4143b9c63cb76e2c824ba773c66f5c5cd94b2aa 99884 998852022-10-03 Luis Machado <luis.machado@arm.com> 99886 99887 [AArch64] Handle W registers as pseudo-registers instead of aliases of X registers 99888 The aarch64 port handles W registers as aliases of X registers. This is 99889 incorrect because X registers are 64-bit and W registers are 32-bit. 99890 99891 This patch teaches GDB how to handle W registers as pseudo-registers of 99892 32-bit, the bottom half of the X registers. 99893 99894 Testcase included. 99895 998962022-10-03 Luis Machado <luis.machado@arm.com> 99897 99898 [AArch64] Fix pseudo-register numbering in the presence of unexpected additional registers 99899 When using AArch64 GDB with the QEMU debugging stub (in user mode), we get 99900 additional system registers that GDB doesn't particularly care about, so 99901 it doesn't number those explicitly. 99902 99903 But given the pseudo-register numbers are above the number of real registers, 99904 we need to setup/account for the real registers first before going ahead and 99905 numbering the pseudo-registers. This has to happen at the end of 99906 aarch64_gdbarch_init, after the call to tdesc_use_registers, as that 99907 updates the total number of real registers. 99908 99909 This is in preparation to supporting pointer authentication for bare metal 99910 aarch64 (QEMU). 99911 999122022-10-03 Nick Clifton <nickc@redhat.com> 99913 99914 readelf: DO not load section headers from file offset zero 99915 * readelf.c (get_32bit_section_headers): Return false if the 99916 e_shoff field is zero. 99917 (get_64bit_section_headers): Likewise. 99918 999192022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com> 99920 99921 RISC-V: Move supervisor instructions after all unprivileged ones 99922 This location of supervisor instructions is out of place (because many other 99923 privileged instructions are located at the tail but after the supervisor 99924 instructions, we have many unprivileged instructions including bit 99925 manipulation / crypto / vector instructions). 99926 99927 Not only that, this is harmful to implement pseudoinstructions in the latest 99928 'P'-extension proposal (CLROV and RDOV). This commit moves supervisor 99929 instructions after all unprivileged instructions. 99930 99931 opcodes/ChangeLog: 99932 99933 * riscv-opc.c (riscv_opcodes): Adjust indents. Move supervisor 99934 instructions after all unprivileged instructions. 99935 999362022-10-03 Bruno Larsen <blarsen@redhat.com> 99937 99938 Improve GDB's baseclass detection with typedefs 99939 When a class inherits from a typedef'd baseclass, GDB may be unable to 99940 find the baseclass if the user is not using the typedef'd name, as is 99941 tested on gdb.cp/virtbase2.exp; the reason that test case is working 99942 under gcc is that the dwarf generated by gcc links the class to the 99943 original definition of the baseclass, not to the typedef. If the 99944 inheritance is linked to the typedef, such as how clang does it, 99945 gdb.cp/virtbase2.exp starts failing. 99946 99947 This can also be seen in gdb.cp/impl-this.exp, when attempting to print 99948 D::Bint::i, and GDB not being able to find the baseclass Bint. 99949 99950 This happens because searching for baseclasses only uses the macro 99951 TYPE_BASECLASS_NAME, which returns the typedef'd name. However, we can't 99952 switch that macro to checking for typedefs, otherwise we wouldn't be 99953 able to find the typedef'd name anymore. This is fixed by searching for 99954 members or baseclasses by name, we check both the saved name and the 99955 name after checking for typedefs. 99956 99957 This also fixes said long-standing bug in gdb.cp/impl-this.exp when the 99958 compiler adds information about typedefs in the debuginfo. 99959 999602022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com> 99961 99962 RISC-V: Assign DWARF numbers to vector registers 99963 This commit assigns DWARF register numbers to vector registers (v0-v31: 99964 96..127) to implement RISC-V DWARF Specification version 1.0-rc4 99965 (now in the frozen state): 99966 99967 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc4 99968 99969 binutils/ChangeLog: 99970 99971 * dwarf.c (dwarf_regnames_riscv): Assign DWARF register numbers 99972 96..127 to vector registers v0-v31. 99973 99974 gas/ChangeLog: 99975 99976 * config/tc-riscv.c (tc_riscv_regname_to_dw2regnum): Support 99977 vector registers. 99978 * testsuite/gas/riscv/dw-regnums.s: Add vector registers to the 99979 DWARF register number test. 99980 * testsuite/gas/riscv/dw-regnums.d: Likewise. 99981 999822022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com> 99983 99984 RISC-V: Add testcase for DWARF register numbers 99985 Although it had csr-dw-regnums.d (for CSRs), it didn't have DWARF register 99986 number test for GPRs/FPRs. 99987 99988 This commit adds dw-regnums.{s,d} to test such registers. 99989 99990 gas/ChangeLog: 99991 99992 * testsuite/gas/riscv/dw-regnums.s: New DWARF register number test 99993 for GPRs/FPRs. 99994 * testsuite/gas/riscv/dw-regnums.d: Likewise. 99995 999962022-10-03 GDB Administrator <gdbadmin@sourceware.org> 99997 99998 Automatic date update in version.in 99999 1000002022-10-02 Tom de Vries <tdevries@suse.de> 100001 100002 [gdb/testsuite] Fix waitpid testing in next-fork-other-thread.c 100003 In next-fork-other-thread.c, there's this loop: 100004 ... 100005 do 100006 { 100007 ret = waitpid (pid, &stat, 0); 100008 } while (ret == EINTR); 100009 ... 100010 100011 The loop condition tests for "ret == EINTR" but waitpid signals EINTR by 100012 returning -1 and setting errno to EINTR. 100013 100014 Fix this by changing the loop condition to "ret == -1 && errno == EINTR". 100015 100016 Tested on x86_64-linux. 100017 1000182022-10-02 Andrew Burgess <aburgess@redhat.com> 100019 100020 gdb/testsuite: handle invalid .exp names passed in TESTS 100021 I ran some tests like: 100022 100023 $ make check-gdb TESTS="gdb.base/break.exp" 100024 100025 then, then I went to rerun the tests later, I managed to corrupt the 100026 command line, like this: 100027 100028 $ make check-gdb TESTS="gdb.base/breakff.exp" 100029 100030 the make command did exit with an error, but DejaGnu appeared to 100031 report that every test passed! The tail end of the output looks like 100032 this: 100033 100034 Illegal Argument "no-matching-tests-found" 100035 try "runtest --help" for option list 100036 === gdb Summary === 100037 100038 # of expected passes 115 100039 /tmp/build/gdb/gdb version 13.0.50.20220831-git -nw -nx -iex "set height 0" -iex "set width 0" -data-directory /tmp/build/gdb/testsuite/../data-directory 100040 100041 make[3]: *** [Makefile:212: check-single] Error 1 100042 make[3]: Leaving directory '/tmp/build/gdb/testsuite' 100043 make[2]: *** [Makefile:161: check] Error 2 100044 make[2]: Leaving directory '/tmp/build/gdb/testsuite' 100045 make[1]: *** [Makefile:1916: check] Error 2 100046 make[1]: Leaving directory '/tmp/build/gdb' 100047 make: *** [Makefile:13565: check-gdb] Error 2 100048 100049 For a while, I didn't spot that DejaGnu had failed at all, I saw the 100050 115 passes, and thought everything had run correctly - though I was 100051 puzzled that make was reporting an error. 100052 100053 What happens is that in gdb/testsuite/Makefile, in the check-single 100054 rule, we first run DejaGnu, then run the dg-add-core-file-count.sh 100055 script, and finally, we use sed to extract the results from the 100056 gdb.sum file. 100057 100058 In my case, with the invalid test name, DejaGnu fails, but the 100059 following steps are still run, the final result, the 115 passes, is 100060 then extracted from the pre-existing gdb.sum file. 100061 100062 If I use 'make -jN' then the 'check-parallel' rule, rather than the 100063 'check-single' rule is used. In this case the behaviour is slightly 100064 different, the tail end of the output now looks like this: 100065 100066 No matching tests found. 100067 100068 make[4]: Leaving directory '/tmp/build/gdb/testsuite' 100069 find: ‘outputs’: No such file or directory 100070 Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ... 100071 100072 tool The tool (e.g. g++, libffi) for which to create a 100073 new test summary file. If not specified then output 100074 is created for all tools. 100075 variant-list One or more test variant names. If the list is 100076 not specified then one is constructed from all 100077 variants in the files for <tool>. 100078 sum-file A test summary file with the format of those 100079 created by runtest from DejaGnu. 100080 If -L is used, merge *.log files instead of *.sum. In this 100081 mode the exact order of lines may not be preserved, just different 100082 Running *.exp chunks should be in correct order. 100083 find: ‘outputs’: No such file or directory 100084 Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ... 100085 100086 tool The tool (e.g. g++, libffi) for which to create a 100087 new test summary file. If not specified then output 100088 is created for all tools. 100089 variant-list One or more test variant names. If the list is 100090 not specified then one is constructed from all 100091 variants in the files for <tool>. 100092 sum-file A test summary file with the format of those 100093 created by runtest from DejaGnu. 100094 If -L is used, merge *.log files instead of *.sum. In this 100095 mode the exact order of lines may not be preserved, just different 100096 Running *.exp chunks should be in correct order. 100097 make[3]: Leaving directory '/tmp/build/gdb/testsuite' 100098 make[2]: Leaving directory '/tmp/build/gdb/testsuite' 100099 make[1]: Leaving directory '/tmp/build/gdb' 100100 100101 Rather than DejaGnu failing, we now get a nice 'No matching tests 100102 found' message, followed by some other noise. This other noise is 100103 first `find` failing, followed by the dg-extract-results.py script 100104 failing. 100105 100106 What happens here is that, in the check-parallel rule, the outputs 100107 directory is deleted before DejaGnu is invoked. Then we try to run 100108 all the tests, and finally we use find and dg-extract-results.py to 100109 combine all the separate .sun and .log files together. However, if 100110 there are no tests run then the outputs/ directory is never created, 100111 so the find command and consequently the dg-extract-results.py script, 100112 fail. 100113 100114 This commit aims to fix the following issues: 100115 100116 (1) For check-single and check-parallel rules, don't run any of the 100117 post-processing steps if DejaGnu failed to run. This will avoid all 100118 the noise after the initial failure of DejaGnu, 100119 100120 (2) For check-single ensure that we don't accidentally report 100121 previous results, this is related to the above, but is worth calling 100122 out as a separate point, and 100123 100124 (3) For check-single, print the 'No matching tests found' message 100125 just like we do for a parallel test run. This makes the parallel and 100126 non-parallel testing behaviour more similar, and I think is clearer 100127 than the current 'Illegal Argument' error message. 100128 100129 Points (1) and (2) will be handled by moving the post processing steps 100130 inside an if block within the recipe. For check-single I propose 100131 deleting the gdb.sum and gdb.log files before running DejaGnu, this is 100132 similar (I think) to how we delete the outputs/ directory in the 100133 check-parallel rule. 100134 100135 For point (3) I plan to split the check-single rule in two, the 100136 existing check-single will be renamed do-check-single, then a new 100137 check-single rule will be added. The new check-single rule can either 100138 depend on the new do-check-single, or will ensure the 'No matching 100139 tests found' message is printed when appropriate. 100140 1001412022-10-02 Andrew Burgess <aburgess@redhat.com> 100142 100143 gdb/disasm: better intel flavour disassembly styling with Pygments 100144 This commit was inspired by this stackoverflow post: 100145 100146 https://stackoverflow.com/questions/73491793/why-is-there-a-%C2%B1-in-lea-rax-rip-%C2%B1-0xeb3 100147 100148 One of the comments helpfully links to this Python test case: 100149 100150 from pygments import formatters, lexers, highlight 100151 100152 def colorize_disasm(content, gdbarch): 100153 try: 100154 lexer = lexers.get_lexer_by_name("asm") 100155 formatter = formatters.TerminalFormatter() 100156 return highlight(content, lexer, formatter).rstrip().encode() 100157 except: 100158 return None 100159 100160 print(colorize_disasm("lea [rip+0x211] # COMMENT", None).decode()) 100161 100162 Run the test case and you should see that the '+' character is 100163 underlined, and could be confused with a combined +/- symbol. 100164 100165 What's happening is that Pygments is failing to parse the input text, 100166 and the '+' is actually being marked in the error style. The error 100167 style is red and underlined. 100168 100169 It is worth noting that the assembly instruction being disassembled 100170 here is an x86-64 instruction in the 'intel' disassembly style, rather 100171 than the default att style. Clearly the Pygments module expects the 100172 att syntax by default. 100173 100174 If we change the test case to this: 100175 100176 from pygments import formatters, lexers, highlight 100177 100178 def colorize_disasm(content, gdbarch): 100179 try: 100180 lexer = lexers.get_lexer_by_name("asm") 100181 lexer.add_filter('raiseonerror') 100182 formatter = formatters.TerminalFormatter() 100183 return highlight(content, lexer, formatter).rstrip().encode() 100184 except: 100185 return None 100186 100187 res = colorize_disasm("lea rax,[rip+0xeb3] # COMMENT", None) 100188 if res: 100189 print(res.decode()) 100190 else: 100191 print("No result!") 100192 100193 Here I've added the call: lexer.add_filter('raiseonerror'), and I am 100194 now checking to see if the result is None or not. Running this and 100195 the test now print 'No result!' - instead of styling the '+' in the 100196 error style, we instead give up on the styling attempt. 100197 100198 There are two things we need to fix relating to this disassembly 100199 text. First, Pygments is expecting att style disassembly, not the 100200 intel style that this example uses. Fortunately, Pygments also 100201 supports the intel style, all we need to do is use the 'nasm' lexer 100202 instead of the 'asm' lexer. 100203 100204 However, this leads to the second problem; in our disassembler line we 100205 have '# COMMENT'. The "official" Intel disassembler style uses ';' 100206 for its comment character, however, gas and libopcodes use '#' as the 100207 comment character, as gas uses ';' for an instruction separator. 100208 100209 Unfortunately, Pygments expects ';' as the comment character, and 100210 treats '#' as an error, which means, with the addition of the 100211 'raiseonerror' filter, that any line containing a '#' comment, will 100212 not get styled correctly. 100213 100214 However, as the i386 disassembler never produces a '#' character other 100215 than for comments, we can easily "fix" Pygments parsing of the 100216 disassembly line. This is done by creating a filter. This filter 100217 looks for an Error token with the value '#', we then change this into 100218 a comment token. Every token after this (until the end of the line) 100219 is also converted into a comment. 100220 100221 In this commit I do the following: 100222 100223 1. Check the 'disassembly-flavor' setting and select between the 100224 'asm' and 'nasm' lexers based on the setting. If the setting is not 100225 available then the 'asm' lexer is used by default, 100226 100227 2. Use "add_filter('raiseonerror')" to ensure that the formatted 100228 output will not include any error text, which would be underlined, 100229 and might be confusing, 100230 100231 3. If the 'nasm' lexer is selected, then add an additional filter 100232 that will format '#' and all other text on the line, as a comment, 100233 and 100234 100235 4. If Pygments throws an exception, instead of returning None, 100236 return the original, unmodified content. This will mean that this 100237 one instruction is printed without styling, but GDB will continue to 100238 call into the Python code to style later instructions. 100239 100240 I haven't included a test specifically for the above error case, 100241 though I have manually check that the above case now styles 100242 correctly (with no underline). The existing style tests check that 100243 the disassembler styling still works though, so I know I've not 100244 generally broken things. 100245 100246 One final thought I have after looking at this issue is that I wonder 100247 now if using Pygments for styling disassembly from every architecture 100248 is actually a good idea? 100249 100250 Clearly, the 'asm' lexer is OK with att style x86-64, but not OK with 100251 intel style x86-64, so who knows how well it will handle other random 100252 architectures? 100253 100254 When I first added this feature I tested it against some random 100255 RISC-V, ARM, and X86-64 (att style) code, and it seemed fine, but I 100256 never tried to make an exhaustive check of all instructions, so its 100257 quite possible that there are corner cases where things are styled 100258 incorrectly. 100259 100260 With the above changes I think that things should be a bit better 100261 now. If a particular instruction doesn't parse correctly then our 100262 Pygments based styling code will just not style that one instruction. 100263 This is combined with the fact that many architectures are now moving 100264 to libopcodes based styling, which is much more reliable. 100265 100266 So, I think it is fine to keep using Pygments as a fallback mechanism 100267 for styling all architectures, even if we know it might not be perfect 100268 in all cases. 100269 1002702022-10-02 Andrew Burgess <aburgess@redhat.com> 100271 100272 gdb: improve disassembler styling when Pygments raises an exception 100273 While working on another issue relating to GDB's use of the Python 100274 Pygments package for disassembly styling I noticed an issue in the 100275 case where the Pygments package raises an exception. 100276 100277 The intention of the current code is that, should the Pygments package 100278 raise an exception, GDB will disable future attempts to call into the 100279 Pygments code. This was intended to prevent repeated errors during 100280 disassembly if, for some reason, the Pygments code isn't working. 100281 100282 Since the Pygments based styling was added, GDB now supports 100283 disassembly styling using libopcodes, but this is only available for 100284 some architectures. For architectures not covered by libopcodes 100285 Pygments is still the only option. 100286 100287 What I observed is that, if I disable the libopcodes styling, then 100288 setup GDB so that the Pygments based styling code will indicate an 100289 error (by returning None), GDB does, as expected, stop using the 100290 Pygments based styling. However, the libopcodes based styling will 100291 instead be used, despite this feature having been disabled. 100292 100293 The problem is that the disassembler output is produced into a 100294 string_file buffer. When we are using Pygments, this buffer is 100295 created without styling support. However, when Pygments fails, we 100296 recreate the buffer with styling support. 100297 100298 The problem is that we should only recreate the buffer with styling 100299 support only if libopcodes styling is enabled. This was an oversight 100300 in commit: 100301 100302 commit 4cbe4ca5da5cd7e1e6331ce11f024bf3c07b9744 100303 Date: Mon Feb 14 14:40:52 2022 +0000 100304 100305 gdb: add support for disassembler styling using libopcodes 100306 100307 This commit: 100308 100309 1. Factors out some of the condition checking logic into two new 100310 helper functions use_ext_lang_for_styling and 100311 use_libopcodes_for_styling, 100312 100313 2. Reorders gdb_disassembler::m_buffer and gdb_disassembler::m_dest, 100314 this allows these fields to be initialised m_dest first, which means 100315 that the new condition checking functions can rely on m_dest being 100316 set, even when called from the gdb_disassembler constructor, 100317 100318 3. Make use of the new condition checking functions each time 100319 m_buffer is initialised, 100320 100321 4. Add a new test that forces the Python disassembler styling 100322 function to return None, this will cause GDB to disable use of 100323 Pygments for styling, and 100324 100325 5. When we reinitialise m_buffer, and re-disassemble the 100326 instruction, call reset the in-comment flag. If the instruction 100327 being disassembler ends in a comment then the first disassembly pass 100328 will have set the in-comment flag to true. This shouldn't be a 100329 problem as we will only be using Pygments, and thus performing a 100330 re-disassembly pass, if libopcodes is disabled, so the in-comment 100331 flag will never be checked, even if it is set incorrectly. However, 100332 I think that having the flag set correctly is a good thing, even if 100333 we don't check it (you never know what future uses might come up). 100334 1003352022-10-02 Andrew Burgess <aburgess@redhat.com> 100336 100337 gdb/testsuite: extend styling test for libopcodes styling 100338 This commit extends the gdb.base/style.exp test to cover disassembler 100339 styling using libopcodes (where available). 100340 100341 The test will try to enable libopcode based styling, if this 100342 works (because such styling is available) then some tests are run to 100343 check that the output is styled, and that the styling can be disabled 100344 using 'set style disassembler enabled off'. If libopcodes styling is 100345 not available on the current architecture then these new tests will be 100346 skipped. 100347 100348 I've moved the Python Pygments module check inside the 100349 test_disable_disassembler_styling function now, so that the test will 100350 be run even when Python Pygments is not available, this allows the new 100351 tests discussed above. 100352 100353 If the Pygments module is not available then the Pygments based tests 100354 will be skipped just as they were before. 100355 1003562022-10-02 Andrew Burgess <aburgess@redhat.com> 100357 100358 gdb: update now gdbarch_register_name doesn't return nullptr 100359 After the previous few commit, gdbarch_register_name no longer returns 100360 nullptr. This commit audits all the calls to gdbarch_register_name 100361 and removes any code that checks the result against nullptr. 100362 100363 There should be no visible change after this commit. 100364 1003652022-10-02 Andrew Burgess <aburgess@redhat.com> 100366 100367 gdb: final cleanup of various gdbarch_register_name methods 100368 Building on the previous commits, this commit goes through the various 100369 gdbarch_register_name methods and removes all the remaining 'return 100370 NULL' cases, I claim that these either couldn't be hit, or should be 100371 returning the empty string. 100372 100373 In all cases the return of NULL was used if the register number being 100374 passed to gdbarch_register_name was "invalid", i.e. negative, or 100375 greater than the total number of declared registers. I don't believe 100376 either of these cases can occur, and the previous commit asserts that 100377 this is the case. As a result we can simplify the code by removing 100378 these checks. In many cases, where the register names are held in an 100379 array, I was able to add a static assert that the array contains the 100380 correct number of strings, after that, a direct access into the array 100381 is fine. 100382 100383 I don't have any means of testing these changes. 100384 1003852022-10-02 Andrew Burgess <aburgess@redhat.com> 100386 100387 gdb/csky: remove nullptr return from csky_pseudo_register_name 100388 Building on the previous commits, in this commit I remove two 100389 instances of 'return NULL' from csky_pseudo_register_name, and replace 100390 them with a return of the empty string. 100391 100392 These two are particularly interesting, and worth pulling into their 100393 own commit, because these returns of NULL appear to be depended on 100394 within other parts of the csky code. 100395 100396 In csky-linux-tdep.c in the register collect/supply code, GDB checks 100397 for the register name being nullptr in order to decide if a target 100398 supports a particular feature or not. I've updated the code to check 100399 for the empty string. 100400 100401 I have no way of testing this change. 100402 1004032022-10-02 Andrew Burgess <aburgess@redhat.com> 100404 100405 gdb: add asserts to gdbarch_register_name 100406 This commit adds asserts to gdbarch_register_name that validate the 100407 parameters, and the return value. 100408 100409 The interesting thing here is that gdbarch_register_name is generated 100410 by gdbarch.py, and so, to add these asserts, I need to update the 100411 generation script. 100412 100413 I've added two new arguments for Functions and Methods (as declared in 100414 gdbarch-components.py), these arguments are 'param_checks' and 100415 'result_checks'. Each of these new arguments can be used to list some 100416 expressions that are then used within gdb_assert calls in the 100417 generated code. 100418 100419 The asserts that validate the API as described in the comment I added 100420 to gdbarch_register_name a few commits back; the register number 100421 passed in needs to be a valid cooked register number, and the result 100422 being returned should not be nullptr. 100423 1004242022-10-02 Andrew Burgess <aburgess@redhat.com> 100425 100426 gdb: check for duplicate register names in selftest 100427 Building on the previous commit, this commit extends the register_name 100428 selftest to check for duplicate register names. 100429 100430 If two registers in the cooked register set (real + pseudo registers) 100431 have the same name, then this will show up as duplicate registers in 100432 the 'info all-registers' output, but the user will only be able to 100433 interact with one copy of the register. 100434 100435 In this commit I extend the selftest that I added in the previous 100436 commit to check for duplicate register names, I didn't include this 100437 functionality in the previous commit because one architecture needed 100438 fixing, and I wanted to keep those fixes separate from the fixes in 100439 the previous commit. 100440 100441 The problematic architecture(s) are powerpc:750 and powerpc:604. In 100442 both of these cases the 'dabr' register appears twice, there's a 100443 definition of dabr in power-oea.xml which is included into both 100444 powerpc-604.xml and powerpc-750.xml. Both of these later two xml 100445 files also define the dabr register. 100446 100447 I'm hopeful that this change shouldn't break anything, but I don't 100448 have the ability to actually test this change, however: 100449 100450 On the gdbserver side, neither powerpc-604.xml nor powerpc-750.xml are 100451 mentioned in gdbserver/configure.srv, which I think means that 100452 gdbserver will never use these descriptions, and, 100453 100454 Within GDB the problematic descriptions are held in the variables 100455 tdesc_powerpc_604 and tdesc_powerpc_750, which are only mentioned in 100456 the variants array in rs6000-tdep.c, this is used when looking up a 100457 description based on the architecture. 100458 100459 For a native Linux target however, this will not be used as 100460 ppc_linux_nat_target::read_description exists, which calls 100461 ppc_linux_match_description, which I don't believe can return either 100462 of the problematic descriptions. 100463 100464 This leaves the other native targets, FreeBSD, AIX, etc. These don't 100465 appear to override the ::read_description method, so will potentially 100466 return the problematic descriptions, but, in each case I think the 100467 ::fetch_registers and ::store_registers methods will ignore the dabr 100468 register, which will leave the register as <unavailable>. 100469 100470 So, my proposed solution is to just remove the duplicate register from 100471 each of powerpc-604.xml and powerpc-750.xml, then regenerate the 100472 corresponding C++ source file. With this change made, the selftest 100473 now passes for all architectures. 100474 1004752022-10-02 Andrew Burgess <aburgess@redhat.com> 100476 100477 gdb: add a gdbarch_register_name self test, and fix some architectures 100478 This commit adds a self-test that checks that gdbarch_register_name 100479 never returns nullptr for any valid register number. 100480 100481 Most architectures already met this requirement, there were just 6 100482 that failed the new selftest, and are updated in this commit. 100483 100484 Beyond the self-tests I don't have any facilities to test that the 100485 architectures I've adjusted still work correctly. 100486 100487 If you review all the various gdbarch_register_name implementations 100488 then you will see that there are far more architectures that seem like 100489 they might return nullptr in some situations, e.g. alpha, avr, bpf, 100490 etc. This commit doesn't attempt to address these cases as non of 100491 them are hit during the selftest. Many of these cases can never be 100492 hit, for example, in alpha_register_name GDB checks for a register 100493 number less than zero, this case can't happen and could be changed 100494 into an assert. 100495 100496 A later commit in this series will have a general cleanup of all the 100497 various register_name methods, and remove all references to NULL from 100498 their code, however, as that commit will be mostly adjusting code that 100499 is never hit, I want to keep those changes separate. 100500 100501 The selftest has been tested on x86-64, but I don't have access to 100502 suitable systems to fully test any of the *-tdep.c code I've changed 100503 in this commit. 100504 1005052022-10-02 Andrew Burgess <aburgess@redhat.com> 100506 100507 gdb/gdbarch: add a comment to gdbarch_register_name 100508 After the previous commit, this commit sets out to formalise the API 100509 for gdbarch_register_name. Not every architecture is actually in 100510 compliance with the API I set out here, but I believe that most are. 100511 100512 I think architectures that don't comply with the API laid out here 100513 will fail the gdb.base/completion.exp test. 100514 100515 The claims in the comment are I feel, best demonstrated with the 100516 asserts in this code: 100517 100518 const char * 100519 gdbarch_register_name (struct gdbarch *gdbarch, int regnr) 100520 { 100521 gdb_assert (regnr >= 0); 100522 gdb_assert (regnr < gdbarch_num_cooked_regs (gdbarch)); 100523 100524 const char *name = gdbarch->register_name (gdbarch, regnr); 100525 100526 gdb_assert (name != nullptr); 100527 100528 return name; 100529 } 100530 100531 Like I said, I don't believe every architecture follows these rules 100532 right now, which is why I'm not actually adding any asserts. Instead, 100533 this commit adds a comment to gdbarch_register_name, this comment is 100534 where I'd like to get to, rather than where we are right now. 100535 100536 Subsequent commits will fix all targets to be in compliance with this 100537 comment, and will even add the asserts shown above to 100538 gdbarch_register_name. 100539 1005402022-10-02 Andrew Burgess <aburgess@redhat.com> 100541 100542 gdb/riscv: fix failure in gdb.base/completion.exp 100543 I noticed a test failure in gdb.base/completion.exp for RISC-V on 100544 a native Linux target, this is the failure: 100545 100546 (gdb) FAIL: gdb.base/completion.exp: complete 'info registers ' 100547 100548 The problem is caused by a mismatch in the output of 'maint print 100549 registers' and the completion list for 'info registers'. The 'info 100550 registers' completion list contains less registers than 100551 expected. Additionally, the list of registers extracted from the 100552 'maint print registers' list was wrong too, in some cases the test was 100553 grabbing the register number, rather than a register name, 100554 100555 Both of these problems have the same root cause, riscv_register_name 100556 returns nullptr for some registers when it should return an empty 100557 string. 100558 100559 The gdbarch_register_name API is not clearly documented anywhere, and 100560 at first glance it would appear that the function can return either 100561 nullptr, or an empty string to indicate that a register is not 100562 available on the current target. Indeed, there are plenty of places 100563 in GDB where we compare the output of gdbarch_register_name to both 100564 nullptr and '\0' in order to see if a register is supported or not, 100565 and there are plenty of targets that return empty string in some 100566 cases, and nullptr in others. 100567 100568 However, the 'info registers' completion code (reg_or_group_completer) 100569 clearly depends on user_reg_map_regnum_to_name only returning nullptr 100570 when the passed in regnum is greater than the maximum possible 100571 register number (i.e. after all physical registers, pseudo-registers, 100572 and user-registers), this means that gdbarch_register_name should not 100573 be returning nullptr. 100574 100575 I did consider "fixing" user_reg_map_regnum_to_name, if 100576 gdbarch_register_name returns nullptr, I could convert to an empty 100577 string at this point, but that felt like a real hack, so I discarded 100578 that plan. 100579 100580 The next possibility I considered was "fixing" reg_or_group_completer 100581 to not rely on nullptr to indicate the end marker. Or rather, I could 100582 have reg_or_group_completer use gdbarch_num_cooked_regs, we know that 100583 we should check at least that many register numbers. Then, once we're 100584 passed that limit, we keep checking until we hit a nullptr. This 100585 would absolutely work, and didn't actually feel that bad, but, it 100586 still felt a little weird that gdbarch_register_name could return 100587 nullptr OR the empty string to mean the same thing, so I wondered if 100588 the "right" solution was to have gdbarch_register_name not return 100589 nullptr. With this in mind I tried an experiment: 100590 100591 I added a self-test that, for each architecture, calls 100592 gdbarch_register_name for every register number up to the 100593 gdbarch_num_cooked_regs limit, and checks that the name is not 100594 nullptr. 100595 100596 Only a handful of architectures failed this test, RISC-V being one of 100597 them. 100598 100599 This seems to suggest that most architectures agree that the correct 100600 API for gdbarch_register_name is to return an empty string for 100601 registers that are not supported on the current target, and that 100602 returning nullptr is really a mistake. 100603 100604 In this commit I will update the RISC-V target so that GDB no longer 100605 returns nullptr from riscv_register_name, instead we return the empty 100606 string. 100607 100608 In subsequent commits I will add the selftest that I mention above, 100609 and will fix the targets that fail the selftest. 100610 100611 With this change the gdb.base/completion.exp test now passes. 100612 1006132022-10-02 Andrew Burgess <aburgess@redhat.com> 100614 100615 gdb/testsuite: rewrite capture_command_output proc 100616 I noticed a test failure in gdb.base/completion.exp for RISC-V on a 100617 native Linux target. Upon investigation I discovered a couple of 100618 reasons for the failure, this commit addresses one of them. A later 100619 commit will address the other issue. 100620 100621 The completion.exp test makes use of the capture_command_output proc 100622 to collect the output of the 'maint print registers' command. For 100623 RISC-V this command produces a lot of output. 100624 100625 Currently the capture_command_output proc tries to collect the 100626 complete command output in a single expect buffer, and what I see is 100627 an error caused by the expect buffer becoming full. 100628 100629 This commit rewrites capture_command_output to make use of 100630 gdb_test_multiple to collect the command output line at a time, in 100631 this way we avoid overflowing the expect buffer. 100632 100633 The capture_command_output proc has some logic for skipping a prefix 100634 pattern, which is passed in to the proc as an argument. In order to 100635 handle this correctly (only matching the prefix at the start of the 100636 command output), I use two gdb_test_multiple calls, the first spots 100637 and discards the echoed command and the (optional) prefix pattern, the 100638 second gdb_test_multiple call then collects the rest of the command 100639 output line at a time until a prompt is seen. 100640 100641 There is one slight oddity with the current implementation, which I 100642 have changed in my rewrite, this does, slightly, change the behaviour 100643 of the proc. 100644 100645 The current implementation uses this pattern: 100646 100647 -re "[string_to_regexp ${command}]\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $" 100648 100649 Now a typical command output will look like this: 100650 100651 output here\r\n 100652 (gdb) 100653 100654 As the TCL regexp matching is greedy, TCL will try to match as much as 100655 possible in one part of the pattern before moving on to the next. 100656 Thus, when this matches against (.*)[\r\n]+, the (.*) will end up 100657 matching against 'output here\r' and the [\r\n]+ will match '\n' only. 100658 100659 In short the previous implementation would leave the '\r' on the end 100660 of the returned text, but not the final trailing '\n'. 100661 100662 Now clearly I could make a new version of capture_command_output that 100663 maintained this behaviour, but I couldn't see any reason to do this. 100664 So, my new implementation drops the final '\r\n' completely, in our 100665 example above we now return 'output here' with no '\r'. 100666 100667 This change doesn't seem to affect any of the existing tests, but I 100668 thought it was worth mentioning. 100669 1006702022-10-02 Andrew Burgess <aburgess@redhat.com> 100671 100672 gdb/mi: new options for -data-disassemble command 100673 Now that the disassembler has two different strategies for laying out 100674 the opcode bytes of an instruction (see /r vs /b for the disassemble 100675 command), I wanted to add support for this to the MI disassemble 100676 command. 100677 100678 Currently the -data-disassemble command takes a single 'mode' value, 100679 which currently has 6 different values (0 -> 5), 3 of these modes 100680 relate to opcode display. 100681 100682 So, clearly I should just add an additional 3 modes to handle the new 100683 opcode format, right? 100684 100685 No, I didn't think that was a great idea either. 100686 100687 So, I wonder, could I adjust the -data-disassemble command in a 100688 backward compatible way, that would allow GDB to move away from using 100689 the mode value altogether? 100690 100691 I think we can. 100692 100693 In this commit, I propose adding two new options to -data-disassemble, 100694 these are: 100695 100696 --opcodes none|bytes|display 100697 --source 100698 100699 Additionally, I will make the mode optional, and default to mode 0 if 100700 no mode value is given. Mode 0 is the simplest, no source code, no 100701 opcodes disassembly mode. 100702 100703 The two new options are only valid for mode 0, if they are used with 100704 any other mode then an error is thrown. 100705 100706 The --opcodes option can add opcodes to the result, with 'bytes' being 100707 equivalent to 'disassemble /b' and 'display' being 'disassemble /r'. 100708 100709 The --source option will enable the /s style source code display, this 100710 is equivalent to modes 4 and 5. There is no way, using the new 100711 command options to get the now deprecated /m style source code 100712 display, that is mode 1 and 3. 100713 100714 My hope is that new users of the MI will not use the mode at all, and 100715 instead will just use the new options to achieve the output they need. 100716 Existing MI users can continue to use the mode, and will not need to 100717 be updated to use the new options. 100718 1007192022-10-02 Andrew Burgess <aburgess@redhat.com> 100720 100721 gdb/mi: some int to bool conversion 100722 Just some simple int to bool conversion in mi_cmd_disassemble. There 100723 should be no user visible changes after this commit. 100724 1007252022-10-02 Andrew Burgess <aburgess@redhat.com> 100726 100727 gdb/doc: update syntax of -data-disassemble command arguments 100728 The argument documentation for -data-disassemble looks like this: 100729 100730 -data-disassemble 100731 [ -s @var{start-addr} -e @var{end-addr} ] 100732 | [ -a @var{addr} ] 100733 | [ -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ] 100734 -- @var{mode} 100735 100736 However, I believe, according to the 'Notation and Terminology' 100737 section, this means that the there are 3 optional location 100738 specification argument groups for the command, followed by a 100739 non-optional '-- mode'. 100740 100741 However, this is not true, one of the location specifications must be 100742 given, i.e. we can't choose to give NO location specification, which 100743 is what the above implies. 100744 100745 I propose that we change this to instead be: 100746 100747 -data-disassemble 100748 ( -s @var{start-addr} -e @var{end-addr} 100749 | -a @var{addr} 100750 | -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ) 100751 -- @var{mode} 100752 100753 By placing all the location specifications within '( ... )' we 100754 indication that these are a group, from which one of the options, 100755 separated by '|', must be selected. 100756 100757 However, the 'Notation and Terminology' section only describes two 100758 uses for parenthesis: '( GROUP )*' and '( GROUP )+', in the first case 100759 GROUP is repeated zero or more times, and in the second GROUP is 100760 repeated 1 or more times. 100761 100762 Neither of those exactly describe what I want, which is GROUP must 100763 appear exactly once. I propose to extend 'Notation and Terminology' 100764 to include '( GROUP )' which means that GROUP should appear exactly 100765 once. 100766 100767 This change is important because, in a later commit, I want to add 100768 additional optional arguments to the -data-disassemble command, and 100769 things start to get confusing with the original syntax. 100770 1007712022-10-02 Andrew Burgess <aburgess@redhat.com> 100772 100773 gdb: make gdb_disassembly_flag unsigned 100774 In a later commit I want to use operator~ on a gdb_disassembly_flag 100775 flag value. This is currently not possible as gdb_disassembly_flag 100776 is, by default, signed. 100777 100778 This commit just makes this enum unsigned. 100779 100780 There should be no user visible changes after this commit. 100781 1007822022-10-02 Andrew Burgess <aburgess@redhat.com> 100783 100784 gdb: disassembler opcode display formatting 100785 This commit changes the format of 'disassemble /r' to match GNU 100786 objdump. Specifically, GDB will now display the instruction bytes in 100787 as 'objdump --wide --disassemble' does. 100788 100789 Here is an example for RISC-V before this patch: 100790 100791 (gdb) disassemble /r 0x0001018e,0x0001019e 100792 Dump of assembler code from 0x1018e to 0x1019e: 100793 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 100794 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 100795 0x00010196 <call_me+74>: 61 65 lui a0,0x18 100796 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 100797 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> 100798 End of assembler dump. 100799 100800 And here's an example after this patch: 100801 100802 (gdb) disassemble /r 0x0001018e,0x0001019e 100803 Dump of assembler code from 0x1018e to 0x1019e: 100804 0x0001018e <call_me+66>: fe842603 lw a2,-24(s0) 100805 0x00010192 <call_me+70>: fec42583 lw a1,-20(s0) 100806 0x00010196 <call_me+74>: 6561 lui a0,0x18 100807 0x00010198 <call_me+76>: 6a850513 addi a0,a0,1704 100808 0x0001019c <call_me+80>: 22f1 jal 0x10368 <printf> 100809 End of assembler dump. 100810 100811 There are two differences here. First, the instruction bytes after 100812 the patch are grouped based on the size of the instruction, and are 100813 byte-swapped to little-endian order. 100814 100815 Second, after the patch, GDB now uses the bytes-per-line hint from 100816 libopcodes to add whitespace padding after the opcode bytes, this 100817 means that in most cases the instructions are nicely aligned. 100818 100819 It is still possible for a very long instruction to intrude into the 100820 disassembled text space. The next example is x86-64, before the 100821 patch: 100822 100823 (gdb) disassemble /r main 100824 Dump of assembler code for function main: 100825 0x0000000000401106 <+0>: 55 push %rbp 100826 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 100827 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 100828 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 100829 0x0000000000401119 <+19>: 5d pop %rbp 100830 0x000000000040111a <+20>: c3 ret 100831 End of assembler dump. 100832 100833 And after the patch: 100834 100835 (gdb) disassemble /r main 100836 Dump of assembler code for function main: 100837 0x0000000000401106 <+0>: 55 push %rbp 100838 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 100839 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 100840 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 100841 0x0000000000401119 <+19>: 5d pop %rbp 100842 0x000000000040111a <+20>: c3 ret 100843 End of assembler dump. 100844 100845 Most instructions are aligned, except for the very long instruction. 100846 Notice too that for x86-64 libopcodes doesn't request that GDB group 100847 the instruction bytes. This matches the behaviour of objdump. 100848 100849 In case the user really wants the old behaviour, I have added a new 100850 modifier 'disassemble /b', this displays the instruction byte at a 100851 time. For x86-64, which never groups instruction bytes, /b and /r are 100852 equivalent, but for RISC-V, using /b gets the old layout back (except 100853 that the whitespace for alignment is still present). Consider our 100854 original RISC-V example, this time using /b: 100855 100856 (gdb) disassemble /b 0x0001018e,0x0001019e 100857 Dump of assembler code from 0x1018e to 0x1019e: 100858 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 100859 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 100860 0x00010196 <call_me+74>: 61 65 lui a0,0x18 100861 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 100862 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> 100863 End of assembler dump. 100864 100865 Obviously, this patch is a potentially significant change to the 100866 behaviour or /r. I could have added /b with the new behaviour and 100867 left /r alone. However, personally, I feel the new behaviour is 100868 significantly better than the old, hence, I made /r be what I consider 100869 the "better" behaviour. 100870 100871 The reason I prefer the new behaviour is that, when I use /r, I almost 100872 always want to manually decode the instruction for some reason, and 100873 having the bytes displayed in "instruction order" rather than memory 100874 order, just makes this easier. 100875 100876 The 'record instruction-history' command also takes a /r modifier, and 100877 has been modified in the same way as disassemble; /r gets the new 100878 behaviour, and /b has been added to retain the old behaviour. 100879 100880 Finally, the MI command -data-disassemble, is unchanged in behaviour, 100881 this command now requests the raw bytes of the instruction, which is 100882 equivalent to the /b modifier. This means that the MI output will 100883 remain backward compatible. 100884 1008852022-10-02 Andrew Burgess <aburgess@redhat.com> 100886 100887 gdb/disasm: read opcodes bytes with a single read_code call 100888 This commit reduces the number of times we call read_code when 100889 printing the instruction opcode bytes during disassembly. 100890 100891 I've added a new gdb::byte_vector within the 100892 gdb_pretty_print_disassembler class, in line with all the other 100893 buffers that gdb_pretty_print_disassembler needs. This byte_vector is 100894 then resized as needed, and filled with a single read_code call for 100895 each instruction. 100896 100897 There should be no user visible changes after this commit. 100898 1008992022-10-02 Andrew Burgess <aburgess@redhat.com> 100900 100901 gdb/testsuite: new test for -data-disassemble opcodes format 100902 Add another test for the output of MI command -data-disassemble. The 100903 new check validates the format of the 'opcodes' field, specifically, 100904 this test checks that the field contains a series of bytes, separated 100905 by a single space. 100906 100907 We also check that the bytes are in the correct order, that is, the 100908 first byte is from the lowest address, and subsequent bytes are from 100909 increasing addresses. 100910 100911 The motivation for this test (besides more tests being generally good) 100912 is that I plan to make changes to how opcode bytes are displayed in 100913 the disassembler output, and I want to ensure that I don't break any 100914 existing MI behaviour. 100915 100916 There should be no user visible changes to GDB after this commit. 100917 1009182022-10-02 GDB Administrator <gdbadmin@sourceware.org> 100919 100920 Automatic date update in version.in 100921 1009222022-10-01 GDB Administrator <gdbadmin@sourceware.org> 100923 100924 Automatic date update in version.in 100925 1009262022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com> 100927 100928 RISC-V: Relax "fmv.[sdq]" requirements 100929 This commit relaxes requirements to "fmv.s" instructions from 'F' to ('F' 100930 or 'Zfinx'). The same applies to "fmv.d" and "fmv.q". Note that 'Zhinx' 100931 extension already contains "fmv.h" instruction (as well as 'Zfh'). 100932 100933 gas/ChangeLog: 100934 100935 * testsuite/gas/riscv/zfinx.s: Add "fmv.s" instruction. 100936 * testsuite/gas/riscv/zfinx.d: Likewise. 100937 * testsuite/gas/riscv/zdinx.s: Add "fmv.d" instruction. 100938 * testsuite/gas/riscv/zdinx.d: Likewise. 100939 * testsuite/gas/riscv/zqinx.d: Add "fmv.q" instruction. 100940 * testsuite/gas/riscv/zqinx.s: Likewise. 100941 100942 opcodes/ChangeLog: 100943 100944 * riscv-opc.c (riscv_opcodes): Relax requirements to "fmv.[sdq]" 100945 instructions to support those in 'Zfinx'/'Zdinx'/'Zqinx'. 100946 1009472022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com> 100948 100949 RISC-V: Reorganize and enhance 'Zfinx' tests 100950 This commit adds certain test cases for 'Zfinx'/'Zdinx'/'Zqinx' extensions 100951 and reorganizes them, fixing coding style while improving coverage. 100952 This is partially based on jiawei's 'Zhinx' testcases. 100953 100954 gas/ChangeLog: 100955 100956 * testsuite/gas/riscv/zfinx.s: Use different registers for 100957 better encode space testing. Make indentation consistent. 100958 Add tests for instruction with rounding mode. Change march 100959 to minimum required extensions. Remove source line. 100960 * testsuite/gas/riscv/zfinx.d: Likewise. 100961 * testsuite/gas/riscv/zdinx.s: Likewise. 100962 * testsuite/gas/riscv/zdinx.d: Likewise. 100963 * testsuite/gas/riscv/zqinx.s: Likewise. 100964 Also use even-numbered registers to use valid register pairs. 100965 * testsuite/gas/riscv/zqinx.d: Likewise. 100966 1009672022-09-30 Christoph Müllner <christoph.muellner@vrull.eu> 100968 100969 RISC-V: Eliminate long-casts of X_add_number in diagnostics 100970 There is no need for casts to (signed/unsigned) long, as we can use 100971 C99's PRId64/PRIu64 format specifiers. 100972 1009732022-09-30 Jan Beulich <jbeulich@suse.com> 100974 100975 RISC-V: fallout from "re-arrange opcode table for consistent alias handling" 100976 Several new testcasee have appeared since the submission of said change, 100977 some of which now also need adjustment. 100978 100979 RISC-V: fix build after "Add support for arbitrary immediate encoding formats" 100980 Pre- and post-increment/decrement are side effects, the behavior of 100981 which is undefined when combined with passing an address of the accessed 100982 variable in the same function invocation. There's no need for the 100983 increments here - simply adding 1 achieves the intended effect without 100984 triggering compiler diagnostics (which are fatal with -Werror). 100985 100986 objcopy: avoid "shadowing" of remove() function name 100987 remove() is a standard library function (declared in stdio.h), which 100988 triggers a "shadows a global declaration" warning with some gcc versions. 100989 100990 RISC-V: drop stray INSN_ALIAS flags 100991 FENCE.TSO isn't an alias. ZIP and UNZIP in the long run likely are, but 100992 presently they aren't. This fixes disassembly of these insns with 100993 -Mno-aliases. 100994 1009952022-09-30 Jan Beulich <jbeulich@suse.com> 100996 100997 RISC-V: re-arrange opcode table for consistent alias handling 100998 For disassembly to pick up aliases in favor of underlying insns (helping 100999 readability in the common case), the aliases need to come ahead of the 101000 "base" insns. Slightly more code movement is needed because of insns 101001 with the same name needing to stay next to each other. 101002 101003 Note that the "rorw" alias entry also has the missing INSN_ALIAS added 101004 here. 101005 101006 Clone a few testcases to exercise -Mno-aliases some more, better 101007 covering the differences between the default and that disassembly mode. 101008 1010092022-09-30 Jan Beulich <jbeulich@suse.com> 101010 101011 x86: correct build dependencies in opcodes/ 101012 With the command in the rule merely being "echo", i386-tbl.h won't be 101013 rebuilt if missing, when at the same time i386-init.h is present and 101014 up-to-date. Use a pattern rule instead to express the multiple targets 101015 correctly (the &: rule separator is supported only by GNU make 4.3 and 101016 newer). Note that now, for the opposite case to work (i386-tbl.h is 101017 up-to-date but i386-init.h is missing), i386-init.h also needs 101018 mentioning as a dependency somewhere: Add a fake dependency for 101019 i386-opc.lo ("fake" because i386-opc.c doesn't include that header). 101020 101021 At the same time use $(AM_V_GEN) in the actual rule, replacing the 101022 earlier (open-coded) "echo". And while there also drop a duplicate 101023 dependency of i386-gen.o on i386-opc.h. 101024 1010252022-09-30 Jan Beulich <jbeulich@suse.com> 101026 101027 x86: improve match_template()'s diagnostics 101028 At the example of 101029 101030 extractps $0, %xmm0, %xmm0 101031 insertps $0, %xmm0, %eax 101032 101033 (both having respectively the same mistake of using the wrong kind of 101034 destination register) it is easy to see that current behavior is far 101035 from ideal: The former results in "unsupported instruction" for 32-bit 101036 code simply because the 2nd template we have is a Cpu64 one. Instead we 101037 should aim at emitting the "best" possible error, which will typically 101038 be the one where we passed the largest number of checks. Generalize the 101039 original "specific_error" approach by making it apply to the entire 101040 matching loop, utilizing that line numbers increase as we pass further 101041 checks. 101042 1010432022-09-30 Jan Beulich <jbeulich@suse.com> 101044 101045 x86/Intel: restrict suffix derivation 101046 While in some cases deriving an AT&T-style suffix from an Intel syntax 101047 memory operand size specifier is necessary, in many cases this is not 101048 only pointless, but has led to the introduction of various workarounds: 101049 Excessive use of IgnoreSize and NoRex64 as well as the ToDword and 101050 ToQword attributes. Suppress suffix derivation when we can clearly tell 101051 that the memory operand's size isn't going to be needed to infer the 101052 possible need for the low byte/word opcode bit or an operand size prefix 101053 (0x66 or REX.W). 101054 101055 As a result ToDword and ToQword can be dropped entirely, plus a fair 101056 number of IgnoreSize and NoRex64 can also be got rid of. Note that 101057 IgnoreSize needs to remain on legacy encoded SIMD insns with GPR 101058 operand, to avoid emitting an operand size prefix in 16-bit mode. (Since 101059 16-bit code using SIMD insns isn't well tested, clone an existing 101060 testcase just enough to cover a few insns which are potentially 101061 problematic but are being touched here.) 101062 101063 Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI 101064 isn't included there. This is to fulfill the request of not allowing L 101065 and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI. 101066 1010672022-09-30 liuzhensong <liuzhensong@loongson.cn> 101068 101069 LoongArch: Update ELF e_flags handling according to specification. 101070 Update handling of e_flags according to the documentation 101071 update [1] (discussions [2][3]). 101072 101073 Object file bitness is now represented in the EI_CLASS byte. 101074 The e_flags field is now interpreted as follows: 101075 101076 e_flags[2:0]: Base ABI modifier 101077 101078 - 0x1: soft-float 101079 - 0x2: single-precision hard-float 101080 - 0x3: double-precision hard-float 101081 101082 e_flags[7:6]: ELF object ABI version 101083 101084 - 0x0: v0 101085 - 0x1: v1 101086 101087 [1]: https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc#e_flags-identifies-abi-type-and-version 101088 [2]: https://github.com/loongson/LoongArch-Documentation/pull/61 101089 [3]: https://github.com/loongson/LoongArch-Documentation/pull/47 101090 1010912022-09-30 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 101092 101093 gprofng: fix cppcheck warnings 101094 gprofng/ChangeLog 101095 2022-09-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 101096 101097 * common/hwcdrv.c: Fix cppcheck warning. 101098 * src/ABS.h: Likewise. 101099 * src/CompCom.cc: Likewise. 101100 1011012022-09-30 Tom de Vries <tdevries@suse.de> 101102 101103 [gdb/testsuite] Fix gdb.mi/mi-sym-info.exp on openSUSE Tumbleweed 101104 On openSUSE Tumbleweed, I run into: 101105 ... 101106 FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only 101107 ... 101108 101109 The problem is in matching this string: 101110 ... 101111 {name="_start",type="void (void)",description="void _start(void);"} 101112 ... 101113 using regexp fun_re, which requires a line field: 101114 ... 101115 set fun_re \ 101116 "\{line=\"$decimal\",name=${qstr},type=${qstr},description=${qstr}\}" 101117 ... 101118 101119 Fix this by making the line field optional in fun_re. 101120 101121 Tested on x86_64-linux. 101122 1011232022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com> 101124 101125 RISC-V: Add privileged extensions without instructions/CSRs 101126 Currently, GNU Binutils does not support following privileged extensions: 101127 101128 - 'Smepmp' 101129 - 'Svnapot' 101130 - 'Svpbmt' 101131 101132 as they do not provide new CSRs or new instructions ('Smepmp' extends the 101133 privileged architecture CSRs but does not define the CSR itself). However, 101134 adding them might be useful as we no longer have to "filter" ISA strings 101135 just for toolchains (if full ISA string is given by a vendor, we can 101136 straightly use it). 101137 101138 And there's a fact that supports this theory: there's already an 101139 (unprivileged) extension which does not provide CSRs or instructions (but 101140 only an architectural guarantee): 'Zkt' (constant timing guarantee for 101141 certain subset of RISC-V instructions). 101142 101143 This simple commit simply adds three privileged extensions listed above. 101144 101145 bfd/ChangeLog: 101146 101147 * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp', 101148 'Svnapot' and 'Svpbmt' extensions. 101149 1011502022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com> 101151 101152 gdb: Remove unused extra_lines variable 101153 Clang generates a warning if there is a variable that is set but not used 101154 otherwise ("-Wunused-but-set-variable"). On the default configuration, it 101155 causes a build failure (unless "--disable-werror" is specified). 101156 101157 The only extra_lines use in arrange_linetable function is removed on the 101158 commit 558802e4d1c5dcbd0df7d2c6ef62a6deac247a2f 101159 ("gdb: change subfile::line_vector to an std::vector"). So, this variable 101160 should be removed to prevent a build failure. 101161 1011622022-09-30 Tom de Vries <tdevries@suse.de> 101163 101164 [gdb/testsuite] Add aranges to gdb.dwarf2/dw2-dir-file-name.exp 101165 Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp 101166 for ppc64le"), the test-case fails with target board cc-with-debug-names, due 101167 to missing .debug_aranges info. 101168 101169 Add the missing .debug_aranges info. 101170 101171 Also add a file_id option to Dwarf::assemble, to make it possible to contribute 101172 to an already open file. 101173 101174 Tested on x86_64-linux. 101175 1011762022-09-30 Tom de Vries <tdevries@suse.de> 101177 101178 [gdb/c++] Print destructor the same for gcc and clang 101179 Consider the test-case contained in this patch. 101180 101181 With g++ (7.5.0) we have for "ptype A": 101182 ... 101183 type = class A { 101184 public: 101185 int a; 101186 101187 A(void); 101188 ~A(); 101189 } 101190 ... 101191 and with clang++ (13.0.1): 101192 ... 101193 type = class A { 101194 public: 101195 int a; 101196 101197 A(void); 101198 ~A(void); 101199 } 101200 ... 101201 and we observe that the destructor is printed differently. 101202 101203 There's a difference in debug info between the two cases: in the clang case, 101204 there's one artificial parameter, but in the g++ case, there are two, and 101205 these similar cases are handled differently in cp_type_print_method_args. 101206 101207 This is due to this slightly convoluted bit of code: 101208 ... 101209 i = staticp ? 0 : 1; 101210 if (nargs > i) 101211 { 101212 while (i < nargs) 101213 ... 101214 } 101215 else if (varargs) 101216 gdb_printf (stream, "..."); 101217 else if (language == language_cplus) 101218 gdb_printf (stream, "void"); 101219 ... 101220 101221 The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit 101222 this parameter. 101223 101224 In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other 101225 artificial parameters was added, but using a different method: rather than 101226 adjusting the potential loop start, it skips the parameter in the loop. 101227 101228 The observed difference in printing is explained by whether we enter the loop: 101229 - in the clang case, the loop is not entered and we print "void". 101230 - in the gcc case, the loop is entered, and nothing is printed. 101231 101232 Fix this by rewriting the code to: 101233 - always enter the loop 101234 - handle whether arguments need printing in the loop 101235 - keep track of how many arguments are printed, and 101236 use that after the loop to print void etc. 101237 such that we have the same for both gcc and clang: 101238 ... 101239 A(void); 101240 ~A(void); 101241 ... 101242 101243 Note that I consider the discussion of whether we want to print: 101244 - A(void) / ~A(void), or 101245 - A() / ~A() 101246 out-of-scope for this patch. 101247 101248 Tested on x86_64-linux. 101249 1012502022-09-30 Alan Modra <amodra@gmail.com> 101251 101252 PR29626, Segfault when disassembling ARM code 101253 PR 29626 101254 * arm-dis.c (mapping_symbol_for_insn): Return false on zero 101255 symtab_size. Delete later symtab_size test. 101256 1012572022-09-30 GDB Administrator <gdbadmin@sourceware.org> 101258 101259 Automatic date update in version.in 101260 1012612022-09-29 Simon Marchi <simon.marchi@polymtl.ca> 101262 101263 gdb: make target_auxv_parse static and rename 101264 It is only used in auxv.c. Also, given it is not strictly a wrapper 101265 around target_ops::auxv (since 27a48a9223d0 "Add auxv parsing to the 101266 architecture vector."), I think that the name prefixed with target is a 101267 bit misleading. Rename to just parse_auxv. 101268 101269 Change-Id: I41cca055b92c8ede37c258ba6583746a07d8f77e 101270 1012712022-09-29 Simon Marchi <simon.marchi@polymtl.ca> 101272 101273 gdb: make fprint_target_auxv static 101274 It's only used in auxv.c. 101275 101276 Change-Id: I4992d9aae37b6631a074ab99bbab2f619725b642 101277 1012782022-09-29 Simon Marchi <simon.marchi@polymtl.ca> 101279 101280 gdb: constify auxv parse functions 101281 Constify the input parameters of the various auxv parse functions, they 101282 don't need to modify the raw auxv data. 101283 101284 Change-Id: I13eacd5ab8e925ec2b5c1f7722cbab39c41516ec 101285 1012862022-09-29 Simon Marchi <simon.marchi@polymtl.ca> 101287 101288 gdb: constify target_stack::is_pushed 101289 The target_ops parameters here can be made const. 101290 101291 Change-Id: Ibc18b17d6b21d06145251a03e68aca90538117d6 101292 1012932022-09-29 Keith Seitz <keiths@redhat.com> 101294 101295 Constify target_desc declarations 101296 This patch changes various global target_desc declarations to const, thereby 101297 correcting a prominent source of ODR violations in PowerPC-related target code. 101298 The majority of files/changes are mechanical const-ifications accomplished by 101299 regenerating the C files in features/. 101300 101301 This also required manually updating mips-linux-tdep.h, s390-linux-tdep.h, 101302 nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c, 101303 and rs6000-tdep.c. 101304 101305 Patch tested against the sourceware trybot, and fully regression tested against 101306 our (Red Hat's) internal test infrastructure on Rawhide aarch64, s390x, x86_64, 101307 and powerpcle. 101308 101309 With this patch, I can finally enable LTO in our GDB package builds. [Tested 101310 with a rawhide scratch build containing this patch.] 101311 101312 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 101313 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24835 101314 1013152022-09-29 Keith Seitz <keiths@redhat.com> 101316 101317 cleanup: Add missing feature/ XML files to Makefile 101318 This patch adds some missing .xml files to features/Makefile so that when the 101319 directory's C files are regenerated, all files are appropriately remade. 101320 101321 This has demonstrated that there have been several "misses" in regenerating 101322 files in this directory. Namely, arm-secext.c and sparc{32,64}-solaris.c. For 101323 the former case, there was what essentially amounts to a typo regarding the 101324 create feature function's name. In the later case, this file has missed at least 101325 one important update in July, 2020, when allocate_target_description was 101326 changed to return a unique pointer. 101327 101328 Those corrections are included. 101329 1013302022-09-29 Nick Clifton <nickc@redhat.com> 101331 101332 Add -B to the help output from gprof, and add suitable documentation. 101333 PR 29627 101334 * gprof.c (usage): Add -B. 101335 * gprof.texi (synopsis): Add -B. 101336 (Output Options): Add entry for -B. 101337 1013382022-09-29 GDB Administrator <gdbadmin@sourceware.org> 101339 101340 Automatic date update in version.in 101341 1013422022-09-28 Pedro Alves <pedro@palves.net> 101343 101344 Fix GDB build: ELF support check & -lzstd 101345 GDB fails to build for me, on Ubuntu 20.04. I get: 101346 101347 ... 101348 CXXLD gdb 101349 /usr/bin/ld: linux-tdep.o: in function `linux_corefile_thread(thread_info*, linux_corefile_thread_data*)': 101350 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:1831: undefined reference to `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, gdb_signal, bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)' 101351 /usr/bin/ld: linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, bfd*, int*)': 101352 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:2117: undefined reference to `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)' 101353 collect2: error: ld returned 1 exit status 101354 make[2]: *** [Makefile:2149: gdb] Error 1 101355 make[2]: Leaving directory '/home/pedro/gdb/binutils-gdb/build/gdb' 101356 make[1]: *** [Makefile:11847: all-gdb] Error 2 101357 make[1]: Leaving directory '/home/pedro/gdb/binutils-gdb/build' 101358 make: *** [Makefile:1004: all] Error 2 101359 101360 Those undefined functions exist in gdb/gcore-elf.c, which is only 101361 included in the build if GDB's configure thinks that the target you're 101362 configuring for is an ELF target. GDB's configure thinks my system 101363 isn't ELF, which is incorrect. 101364 101365 For the ELF support check, gdb/config.log shows: 101366 101367 configure:17387: checking for ELF support in BFD 101368 configure:17407: gcc -o conftest -I/home/pedro/gdb/binutils-gdb/src/gdb/../include -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdb/../bfd -g3 -O0 -L../bfd -L../libiberty -lzstd conftest.c -lbfd -liberty -lz -lncursesw -lm -ldl >&5 101369 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `decompress_contents': 101370 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:42: undefined reference to `ZSTD_decompress' 101371 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:44: undefined reference to `ZSTD_isError' 101372 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents': 101373 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:195: undefined reference to `ZSTD_compress' 101374 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:198: undefined reference to `ZSTD_isError' 101375 collect2: error: ld returned 1 exit status 101376 configure:17407: $? = 1 101377 ... 101378 configure:17417: result: no 101379 101380 Note how above, in the gcc command line, "-lzstd" appears before 101381 "-lbfd". That explain the link failure. It should appear after, like 101382 -lz does. 101383 101384 This commit fixes it, by moving ZSTD_LIBS from LDFLAGS to LIBS, next 101385 to -lz, in GDB_AC_CHECK_BFD, and regenerating gdb/configure. 101386 101387 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29630 101388 Change-Id: I1f4128dde634e8ea04c9002904f1005a8b3a6863 101389 1013902022-09-28 Simon Marchi <simon.marchi@efficios.com> 101391 101392 gdb: remove trailing spaces in README 101393 Change-Id: Ic7f8e415acd1bff6194cf08ed646bff45571f165 101394 1013952022-09-28 Tom Tromey <tromey@adacore.com> 101396 101397 Treat Character as a discrete type in Ada 101398 A user noticed that gdb would assert when printing a certain array 101399 with array-indexes enabled. This turned out to be caused by the array 101400 having an index type of Character, which is completely valid in Ada. 101401 This patch changes the Ada support to recognize Character as a 101402 discrete type, and adds some tests. 101403 101404 Because this is Ada-specific and was also reviewed internally, I am 101405 checking it in. 101406 1014072022-09-28 Nick Clifton <nickc@redhat.com> 101408 101409 The help document of size misses an option. 101410 PR 29628 101411 * size.c (usage): Add -f. 101412 * doc/binutils.texi (size): Add -f. 101413 1014142022-09-28 Clément Chigot <chigot@adacore.com> 101415 101416 ld/testsuite: force warnings when dealing with execstack tests 101417 Binutils can be configured to avoid printing the execstack or RWD 101418 segment warnings. In this case, the first test of PR ld/29072 will fail. 101419 Fix that by always manually forcing the warnings for it. 101420 101421 ld/ChangeLog: 101422 101423 * testsuite/ld-elf/elf.exp (PR ld/29072): Force execstack and 101424 RWD segment warnings. 101425 1014262022-09-28 Alan Modra <amodra@gmail.com> 101427 101428 Re: egrep in binutils 101429 Multi-line patterns for grep are not supported on some old versions 101430 of grep. 101431 101432 binutils/ 101433 * embedspu.sh: Replace multi-line grep with sed. 101434 ld/ 101435 * testsuite/ld-elfvers/vers.exp: Replace multi-line grep with sed. 101436 1014372022-09-28 Pedro Alves <pedro@palves.net> 101438 101439 Renenerate {gdb,gdbserver}/configure 101440 Pick up config/lib-ld.m4 changes from: 101441 101442 commit 67d1991b785bdfef1d70cddfa0202b99b43ccce9 101443 Author: Alan Modra <amodra@gmail.com> 101444 AuthorDate: Wed Sep 28 13:37:31 2022 +0930 101445 Commit: Alan Modra <amodra@gmail.com> 101446 CommitDate: Wed Sep 28 13:37:31 2022 +0930 101447 101448 egrep in binutils 101449 101450 Change-Id: Ifc84d30f1fca015e80bafa80f9a35616b0077220 101451 1014522022-09-28 Nick Clifton <nickc@redhat.com> 101453 101454 The help document of as misses some many options 101455 PR 29623 101456 * as.c (show_usage): Document the --dump-config, 101457 --gdwarf-cie-version, --hash-size, --multibyte-handling, 101458 and --reduce-memory-overheads options. 101459 * config/tc-i386.c (md_show_usage): Document the -O option. 101460 * doc/as.texi: Document the --dump-config, --emulation, 101461 --hash-size, and --reduce-memory-overheads options. 101462 1014632022-09-28 Alan Modra <amodra@gmail.com> 101464 101465 egrep in binutils 101466 Apparently some distros have a nagging egrep that helpfully tells you 101467 egrep is deprecated and to use "grep -E". The nag message causes a ld 101468 testsuite failure. What's more the advice isn't that good. The "-E" 101469 flag may not be available with older versions of grep. 101470 101471 This patch fixes bare invocation of egrep within binutils, replacing 101472 it with the autoconf $EGREP or with grep. 101473 101474 config/ 101475 * lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and 101476 invoke $EGREP. 101477 (AC_LIB_PROG_LD): Likewise. 101478 binutils/ 101479 * configure: Regenerate. 101480 * embedspu.sh: Replace egrep with grep. 101481 gold/ 101482 * testsuite/Makefile.am (flagstest_compress_debug_sections.check): 101483 Replace egrep with grep. 101484 * testsuite/Makefile.in: Regenerate. 101485 * testsuite/bnd_ifunc_1.sh: Replace egrep with $EGREP. 101486 * testsuite/bnd_ifunc_2.sh: Likewise. 101487 * testsuite/bnd_plt_1.sh: Likewise. 101488 * testsuite/discard_locals_test.sh: Likewise. 101489 * testsuite/gnu_property_test.sh: Likewise. 101490 * testsuite/no_version_test.sh: Likewise. 101491 * testsuite/pr18689.sh: Likewise. 101492 * testsuite/pr26936.sh: Likewise. 101493 * testsuite/retain.sh: Likewise. 101494 * testsuite/split_i386.sh: Likewise. 101495 * testsuite/split_s390.sh: Likewise. 101496 * testsuite/split_x32.sh: Likewise. 101497 * testsuite/split_x86_64.sh: Likewise. 101498 * testsuite/ver_test_pr16504.sh: Likewise. 101499 intl/ 101500 * configure: Regenerate. 101501 ld/ 101502 * testsuite/ld-elfvers/vers.exp (test_ar): Replace egrep with grep. 101503 1015042022-09-28 Alan Modra <amodra@gmail.com> 101505 101506 regen bfd/configure 101507 1015082022-09-28 Alan Modra <amodra@gmail.com> 101509 101510 asan: _bfd_stab_section_find_nearest_line segv 101511 The segv was on "info->strs[strsize - 1] = 0;" with strsize zero. OK, 101512 if strsize is zero we don't have any filenames in stabs so no useful 101513 info. 101514 101515 * syms.c (_bfd_stab_section_find_nearest_line): Exit if either 101516 stabsize or strsize is zero. 101517 1015182022-09-28 Alan Modra <amodra@gmail.com> 101519 101520 asan: segv in _bfd_archive_close_and_cleanup 101521 Uninitialised arelt_data->parent_cache led to this segv. 101522 101523 * pdb.c (pdb_get_elt_at_index): Clear arelt_data. 101524 1015252022-09-28 GDB Administrator <gdbadmin@sourceware.org> 101526 101527 Automatic date update in version.in 101528 1015292022-09-27 Fangrui Song <maskray@google.com> 101530 101531 sim: Link ZSTD_LIBS 101532 This fixes linker errors in a `../../configure --enable-targets 101533 --enable-sim; make all-gdb` build. 101534 1015352022-09-27 Tsukasa OI <research_trasio@irq.a4lg.com> 101536 101537 gold: Suppress "unused" variable warning on Clang 101538 Clang generates a warning if there is a variable that is set but not used 101539 otherwise ("-Wunused-but-set-variable"). On the default configuration, it 101540 causes a build failure (unless "--disable-werror" is specified). 101541 101542 Because the cause of this error is in the Bison-generated code 101543 ($(srcdir)/gold/yyscript.y -> $(builddir)/gold/yyscript.c), 101544 this commit suppresses this warning ("-Wunused-but-set-variable") by placing 101545 DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro at the end of user 101546 prologue on yyscript.y. 101547 101548 * yyscript.y: Suppress -Wunused-but-set-variable warning on 101549 the Bison-generated code. 101550 1015512022-09-27 Fangrui Song <i@maskray.me> 101552 101553 libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true 101554 1015552022-09-27 Fangrui Song <maskray@google.com> 101556 101557 binutils, gdb: support zstd compressed debug sections 101558 PR29397 PR29563: Add new configure option --with-zstd which defaults to 101559 auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support 101560 zstd compressed debug sections for most tools. 101561 101562 * bfd: for addr2line, objdump --dwarf, gdb, etc 101563 * gas: support --compress-debug-sections=zstd 101564 * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd 101565 * objcopy: support ELFCOMPRESS_ZSTD input for 101566 --decompress-debug-sections and --compress-debug-sections=zstd 101567 * gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd 101568 symbols, so gdb has to link against -lzstd in this patch. 101569 101570 If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We 101571 can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this 101572 is too heavyweight, so don't do it for now. 101573 101574 ``` 101575 % ld/ld-new a.o 101576 ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support 101577 ... 101578 101579 % ld/ld-new a.o --compress-debug-sections=zstd 101580 ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support 101581 101582 % binutils/objcopy --compress-debug-sections=zstd a.o b.o 101583 binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support 101584 101585 % binutils/objcopy b.o --decompress-debug-sections 101586 binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support 101587 ... 101588 ``` 101589 1015902022-09-27 Alan Modra <amodra@gmail.com> 101591 101592 PR29617, ld segfaults when bfd_close fails 101593 PR 29617 101594 * ldmain.c (main): Don't access output_bfd after bfd_close. 101595 1015962022-09-27 GDB Administrator <gdbadmin@sourceware.org> 101597 101598 Automatic date update in version.in 101599 1016002022-09-26 Simon Marchi <simon.marchi@polymtl.ca> 101601 101602 gdb/testsuite: update field names in gdb-gdb.py.in 101603 Patches that renamed the type::length and type::target_type fields 101604 didn't update gdb-gdb.py.in accordingly, do that. 101605 101606 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29599 101607 Change-Id: I0f3f37a94d43497789156b0ded4d2f2dd5b89496 101608 1016092022-09-26 Simon Marchi <simon.marchi@polymtl.ca> 101610 101611 gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp 101612 If some command in there gives the wrong answer, we currently have to 101613 wait for a timeout for the test to continue. For instance, I currently 101614 see: 101615 101616 print *val->type 101617 $1 = Python Exception <class 'gdb.error'>: Cannot take address of method length. 101618 101619 (outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout) 101620 101621 We can avoid this and modernize the test at the same time by using the 101622 -prompt option of gdb_test. 101623 101624 gdb_test_no_output currently accepts a -prompt_re option (the variable 101625 name passed to parse_args defines the option name), but I think 101626 it's a typo. It's supposed to be -prompt, like gdb_test. I can't find 101627 anything using -prompt_re using grep. Change it to just "prompt". 101628 101629 Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca 101630 1016312022-09-26 Simon Marchi <simon.marchi@polymtl.ca> 101632 101633 gdb/testsuite: bump duration for the whole test in do_self_tests 101634 When running gdb.gdb/python-helper.exp, I get some timeouts: 101635 101636 continue 101637 Continuing. 101638 print 1 101639 101640 FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout) 101641 101642 At this time, GDB is actually processing the stop and reading in some 101643 CUs. selftest_setup does bump the timeout, but it's not for the whole 101644 test. 101645 101646 Since debugging GDB with GDB is (unfortunately) a bit slow, bump the 101647 timeout for the whole duration of the setup and body. On my optimized 101648 build, the command takes just a bit more than the current timeout of 10 101649 seconds. But it's much slower if running the test on an unoptimized 101650 build, so I think it's necessary to bump the timeout for that in any 101651 case. 101652 101653 Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d 101654 1016552022-09-26 Clément Chigot <chigot@adacore.com> 101656 101657 binutils/testsuite: handle the different install names of c++filt 101658 c++filt is always named cxxfilt in a build directory, but in a install 101659 directory it would be named either cxxfilt or c++filt (depending on 101660 the host). Handle this last case in testsuite. 101661 101662 binutils/ChangeLog: 101663 * testsuite/config/default.exp (CXXFILE): if cxxfilt not found, 101664 try c++filt. 101665 1016662022-09-26 Clément Chigot <chigot@adacore.com> 101667 101668 binutils/testsuite: skip gentestdlls related tests if missing 101669 When launching the testsuite through runtest outside the build tree, 101670 gentestdlls might not be available, this binary being created by make 101671 check. 101672 Simply untested the related tests instead of crashing. 101673 101674 binutils/ChangeLog: 101675 101676 * testsuite/binutils-all/objdump.exp: Skip dotnet tests if 101677 gentestdlls is not available. 101678 1016792022-09-26 Tom de Vries <tdevries@suse.de> 101680 101681 [gdb/testsuite] Fix gdb.dwarf2/dw2-unspecified-type-foo.c with -m32 101682 When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board 101683 unix/-m32, I run into: 101684 ... 101685 (gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo 101686 p ((int (*) ()) foo) ()^M 101687 $1 = -135698472^M 101688 ... 101689 101690 Add the missing "return 0" in foo, which fixes this. 101691 101692 Tested on x86_64-linux. 101693 1016942022-09-26 Alan Modra <amodra@gmail.com> 101695 101696 PR29613, use of uninitialized value in objcopy 101697 PR 29613 101698 * elf.c (_bfd_elf_write_secondary_reloc_section): Trim sh_size 101699 back to relocs written. Use better types for vars. 101700 1017012022-09-26 Alan Modra <amodra@gmail.com> 101702 101703 PR29542, PowerPC gold internal error in get_output_view, 101704 We were attempting to set a BSS style section contents. 101705 101706 PR 29542 101707 * powerpc.cc (Output_data_plt_powerpc::do_write): Don't set .plt, 101708 .iplt or .lplt section contents when position independent. 101709 1017102022-09-26 Alan Modra <amodra@gmail.com> 101711 101712 stab nearest_line bfd_malloc_and_get_section 101713 bfd_malloc_and_get_section performs some sanity checks on the section 101714 size before allocating memory. This patch avails the stab 101715 nearest_line code of that sanity checking, and tidies up memory 101716 afterward. 101717 101718 * coffgen.c (_bfd_coff_close_and_cleanup): Call _bfd_stab_cleanup. 101719 * elf.c (_bfd_elf_close_and_cleanup): Likewise. 101720 * syms.c (_bfd_stab_section_find_nearest_line): Set *pinfo earlier. 101721 Use bfd_malloc_and_get_section. Free malloc'd buffers on failure. 101722 Malloc indextable. 101723 (_bfd_stab_cleanup): New function. 101724 * libbfd-in.h (_bfd_stab_cleanup): Declare. 101725 * libbfd.h: Regnerate. 101726 1017272022-09-26 Alan Modra <amodra@gmail.com> 101728 101729 PKG_CHECK_MODULES for msgpack and jansson 101730 Using AS_IF rather than shell "if" is recommended for conditionals 101731 that contain non-trivial autoconf macros, because autoconf will emit 101732 any AC_REQUIREd autoconf macro expansions outside of the conditional. 101733 This makes them available elsewhere in the configure script. 101734 101735 binutils/ 101736 * configure.ac (msgpack): Use "AS_IF" rather than "if". 101737 * configure: Regenerate. 101738 ld/ 101739 * configure.ac (jansson): Use "AS_IF" rather than "if". 101740 * configure: Regenerate. 101741 1017422022-09-26 GDB Administrator <gdbadmin@sourceware.org> 101743 101744 Automatic date update in version.in 101745 1017462022-09-25 GDB Administrator <gdbadmin@sourceware.org> 101747 101748 Automatic date update in version.in 101749 1017502022-09-24 Magne Hov <mhov@undo.io> 101751 101752 gdb/source.c: Fix undefined behaviour dereferencing empty string 101753 When a source file's dirname is solely made up of directory separators 101754 we end up trying to dereference the last character of an empty string 101755 with std::string::back, which results in undefined behaviour. A typical 101756 use case where this can happen is when the root directory "/" is used as 101757 a compilation directory. 101758 101759 With libstdc++.so.6.0.28 we get no out-of-bounds checks and the byte 101760 preceding the storage of the empty string is returned. The character 101761 value of this byte depends on heap implementation and usage, but when 101762 this byte happens to hold the value of the directory separator character 101763 we go on to call std::string::pop_back on the empty string which results 101764 in an out_of_range exception which terminates GDB. 101765 101766 Fix this by using path_join. prepare_path_for_appending ensures that the 101767 filename component is relative. 101768 101769 The testsuite has been run before and after the change and no 101770 regressions were found. 101771 1017722022-09-24 Enze Li <enze.li@hotmail.com> 101773 101774 gdbserver: remove unused for loop 101775 In this commit, 101776 101777 commit cf6c1e710ee162a5adb0ae47acb731f2bfecc956 101778 Date: Mon Jul 11 20:53:48 2022 +0800 101779 101780 gdbserver: remove unused variable 101781 101782 I removed an unused variable in handle_v_run. Pedro then pointed out 101783 that the for loop after it was also unused. After a period of smoke 101784 testing, no exceptions were found. 101785 101786 Tested on x86_64-linux. 101787 1017882022-09-24 Alan Modra <amodra@gmail.com> 101789 101790 The problem with warning in elf_object_p 101791 elfcode.h can emit three warnings in elf_object_p for various things, 101792 "section extending past end of file", "corrupt string table index", 101793 and "program header with invalid alignment". The problem with doing 101794 this is that the warning can be emitted for multiple possible targets 101795 as each one is tried. I was looking at a fuzzer testcase that had an 101796 object file with 6144 program headers, 5316 of which had invalid 101797 alignment. It would be bad enough to get 5316 messages all the same, 101798 but this object was contained in an archive and resulted in 4975776 101799 repeats. 101800 101801 Some trimming can be done by not warning if the bfd is already marked 101802 read_only, as is done for the "section extending past end of file" 101803 warning, but that still results in an unacceptable number of 101804 warnings for object files in archives. Besides that, it is just wrong 101805 to warn about a problem detected by a target elf_object_p other than 101806 the one that actually matches. At some point we might have more 101807 target specific warnings. 101808 101809 So what to do? One obvious solution is to remove the warnings. 101810 Another is to poke any warning strings into the target xvec, emitting 101811 them if that xvec is the final one chosen. This also has the benefit 101812 of solving the archive problem. A warning when recursing into 101813 _bfd_check_format for the first element of the archive (to find the 101814 correct target for the archive) will still be on the xvec at the point 101815 that target is chosen for the archive. However, target xvecs are 101816 read-only. Thus the need for per_xvec_warn to logically extend 101817 bfd_target with a writable field. I've made per_xvec_warn one larger 101818 than bfd_target_vector to provide one place for user code that makes 101819 private copies of target xvecs. 101820 101821 * elfcode.h (elf_swap_shdr_in, elf_object_p): Stash potential 101822 warnings in _bfd_per_xvec_warn location. 101823 * format.c (clear_warnmsg): New function. 101824 (bfd_check_format_matches): Call clear_warnmsg before trying 101825 a new xvec. Print warnings for the successful non-archive 101826 match. 101827 * targets.c: Include libiberty.h. 101828 (_bfd_target_vector_entries): Use ARRAY_SIZE. 101829 (per_xvec_warn): New. 101830 (_bfd_per_xvec_warn): New function. 101831 * Makefile.am (LIBBFD_H_FILES): Add targets.c. 101832 * Makefile.in: Regenerate. 101833 * libbfd.h: Regenerate. 101834 1018352022-09-24 Alan Modra <amodra@gmail.com> 101836 101837 Re: bfd_cleanup for object_p 101838 Bits still missing from commit cb001c0d283d. 101839 101840 * aoutx.h (aout_@var{size}_some_aout_object_p): Correct synopsis. 101841 * i386lynx.c (lynx_core_file_p): Correct return type. 101842 * ptrace-core.c (ptrace_unix_core_file_p): Likewise. 101843 1018442022-09-24 GDB Administrator <gdbadmin@sourceware.org> 101845 101846 Automatic date update in version.in 101847 1018482022-09-23 John Baldwin <jhb@FreeBSD.org> 101849 101850 Support AT_USRSTACKBASE and AT_USRSTACKLIM. 101851 FreeBSD's kernel has recently added two new ELF auxiliary vector 101852 entries to describe the location of the user stack for the initial 101853 thread in a process. 101854 101855 This change displays the proper name and description of these entries 101856 in 'info auxv'. 101857 1018582022-09-23 Christoph Müllner <christoph.muellner@vrull.eu> 101859 101860 RISC-V: Add Zawrs ISA extension support 101861 This patch adds support for the Zawrs ISA extension 101862 ("wrs.nto" and "wrs.sto" instructions). 101863 101864 The specification can be found here: 101865 https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc 101866 1018672022-09-23 Simon Marchi <simon.marchi@polymtl.ca> 101868 101869 gdb/testsuite/tui: start GDB with "set filename-display basename" 101870 The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I 101871 concluded that it is caused by the long source directory name: 101872 101873 /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb 101874 101875 The long name causes some particular redrawing that doesn't happen for 101876 shorter directories, and causes a Term::command call to return too 101877 early. 101878 101879 This can be reproduced by cloning the binutils-gdb repo in a directory 101880 with a name similar to the one shown above. 101881 101882 $ pwd 101883 /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb 101884 $ make check-read1 TESTS="gdb.tui/tui-missing-src.exp" 101885 FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 () 101886 FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window 101887 FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return 101888 FAIL: gdb.tui/tui-missing-src.exp: Back in main 101889 101890 Note that using "make check" instead of "make check-read1" only shows 101891 the last 2 failures for me. 101892 101893 When running gdb.tui/tui-missing-src.exp in a directory with a shorter 101894 name, the terminal looks like this by the time the "checking if inside 101895 f2" test runs: 101896 101897 Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23): 101898 0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+ 101899 1 | 1 | 101900 2 | 2 int | 101901 3 | 3 f2 (int x) | 101902 4 | 4 { | 101903 5 | > 5 x <<= 1; | 101904 6 | 6 return x+5; | 101905 7 | 7 } | 101906 8 | 8 | 101907 9 | 9 | 101908 10 | 10 | 101909 11 | 11 | 101910 12 | 12 | 101911 13 | 13 | 101912 14 +------------------------------------------------------------------------------+ 101913 15 multi-thre Thread 0x7ffff7cc07 In: f2 L5 PC: 0x555555555143 101914 16 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui- 101915 17 missing-src/main.c:6 101916 18 (gdb) next 101917 19 (gdb) step 101918 20 f2 (x=4) 101919 21 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui- 101920 22 missing-src/f2.c:5 101921 23 (gdb) 101922 PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 () 101923 101924 When running the `Term::command "step"` just before, GDB writes the 101925 "step", which makes the `wait_for` proc go in the "looking for the 101926 prompt" mode, to know when the command's execution is complete. As some 101927 new output appears, lines that must disappear are deleted using the 101928 "Delete Line" operation [1] and some new ones are drawn. The source 101929 window gets redrawn with the contents of the f2.c file. Then, GDB 101930 writes the prompt (at line 23 above), which satisfies `wait_for`, which 101931 then returns. The state of the terminal is therefore correct for the 101932 "check if inside f2" and "f2.c must be displayed in the source window" 101933 tests. 101934 101935 In the non-working case, the terminal looks like this by the time the 101936 "check if inside f2" test runs: 101937 101938 Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17): 101939 0 +------------------------------------------------------------------------------+ 101940 1 | | 101941 2 | | 101942 3 | | 101943 4 | | 101944 5 | | 101945 6 | | 101946 7 | [ No Source Available ] | 101947 8 | | 101948 9 | | 101949 10 | | 101950 11 | | 101951 12 | | 101952 13 | | 101953 14 +------------------------------------------------------------------------------+ 101954 15 multi-thre Thread 0x7ffff7cc1b In: main L7 PC: 0x555555555128 101955 16 sing-src/main.c:6 101956 17 (gdb) ary breakpoint 1, main () 101957 18 at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6 101958 19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis 101959 20 sing-src/main.c:6 101960 21 (gdb) next 101961 22 (gdb) step 101962 23 101963 FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 () 101964 101965 What happened is: GDB wrote the "step" command, which make the 101966 `wait_for` proc go in its "looking for the prompt" mode. However, 101967 curses decided to redraw whatever scrolled up to line 17 using some 101968 standard character insertion operations: 101969 101970 +++ Cursor Down (1), cursor: (16, 0) -> (17, 0) 101971 +++ Inserting string '(' 101972 +++ Inserted char '(', cursor: (17, 0) -> (17, 1) 101973 +++ Inserted string '(', cursor: (17, 0) -> (17, 1) 101974 +++ Inserting string 'g' 101975 +++ Inserted char 'g', cursor: (17, 1) -> (17, 2) 101976 +++ Inserted string 'g', cursor: (17, 1) -> (17, 2) 101977 +++ Inserting string 'd' 101978 +++ Inserted char 'd', cursor: (17, 2) -> (17, 3) 101979 +++ Inserted string 'd', cursor: (17, 2) -> (17, 3) 101980 +++ Inserting string 'b' 101981 +++ Inserted char 'b', cursor: (17, 3) -> (17, 4) 101982 +++ Inserted string 'b', cursor: (17, 3) -> (17, 4) 101983 +++ Inserting string ')' 101984 +++ Inserted char ')', cursor: (17, 4) -> (17, 5) 101985 +++ Inserted string ')', cursor: (17, 4) -> (17, 5) 101986 +++ Inserting string ' ' 101987 +++ Inserted char ' ', cursor: (17, 5) -> (17, 6) 101988 +++ Inserted string ' ', cursor: (17, 5) -> (17, 6) 101989 101990 And that causes `wait_for` to think the "step" command is complete. 101991 This is wrong, as the prompt at line 17 isn't the prompt drawn after the 101992 completion of the "step" command. The subsequent tests now run with a 101993 partially updated screen (what is shown above) and obviously fail. 101994 101995 The ideal way to fix this would be for `wait_for` to be smarter, to 101996 avoid it confusing the different prompts drawn. 101997 101998 However, I would also like to reduce the variations in TUI test results 101999 due to the directories (source and build) in which tests are ran. TUI 102000 tests are more prone to differences in test results due to variations in 102001 directory names than other tests, as it makes curses take different 102002 redrawing decisions. So in this patch, I propose to make TUI tests use 102003 "set filename-display basename", which makes GDB omit directory names 102004 when it prints file names. This way, regardless of where you run the 102005 tests, you should get the same results (all other things being equal). 102006 102007 Doing this happens to fix my failures and makes my CI happy (which in 102008 turns makes me happy). To be clear, I understand that this does not fix 102009 the root issue of `proc wait_for` being confused. However, it makes TUI 102010 test runs be more similar for everyone, such that there's less chance of 102011 TUI tests randomly failing for somebody. If some other change triggers 102012 the `wait_for` problem again in the future, hopefully everybody will see 102013 the problem and we can work on getting it fixed more easily than if just 102014 one unlucky person sees the problem. 102015 102016 Note that there are other reasons why TUI tests could vary, like 102017 different curses library versions taking different re-drawing decisions. 102018 However, I think my change is a good step towards more stable test 102019 results. 102020 102021 [1] https://vt100.net/docs/vt510-rm/DL.html 102022 102023 Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5 102024 1020252022-09-23 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 102026 102027 gdb/csky add cskyv2-linux.xml for cskyv2-linux.c 102028 Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed. 102029 Also update cskyv2-linux.c. 102030 1020312022-09-23 Alan Modra <amodra@gmail.com> 102032 102033 pdb: _bfd_generic_close_and_cleanup 102034 Every format that might appear inside a generic archive needs to call 102035 _bfd_generic_close_and_cleanup, so that the archive element lookup 102036 htab can be tidied on closing an element. Otherwise you get stale 102037 entries in the htab pointing at freed and perhaps reused memory, 102038 resulting in segfaults when the archive is closed. 102039 102040 Calling _bfd_generic_close_and_cleanup on close means tdata needs to 102041 be set up too, since pdb claims to be of format bfd_archive. 102042 102043 * pdb.c (pdb_close_and_cleanup): Define as 102044 _bfd_generic_close_and_cleanup. 102045 (pdb_archive_p): Set up tdata for bfd_archive format. 102046 1020472022-09-23 Alan Modra <amodra@gmail.com> 102048 102049 Don't attempt to compress bss sections 102050 It doesn't make sense to try to compress a section without contents 102051 since those sections take no space on disk. Compression can only 102052 increase the disk image size. 102053 102054 * coffgen.c (make_a_section_from_file): Exclude !SEC_HAS_CONTENTS 102055 sections from compression and decompression. 102056 * elf.c (_bfd_elf_make_section_from_shdr): Likewise. 102057 1020582022-09-23 GDB Administrator <gdbadmin@sourceware.org> 102059 102060 Automatic date update in version.in 102061 1020622022-09-22 Lancelot SIX <lancelot.six@amd.com> 102063 102064 gdb/testsuite/lib/future.exp: follow dejagnu default_target_compile 102065 GDB's testsuite can override dejagnu's default_target_compile if the 102066 system provided dejagnu installation does not provide support to compile 102067 languages GDB needs. 102068 102069 Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272 102070 "Establish a default C compiler by evaluating [find_gcc] if no other 102071 compiler is given."[1]. This commit removed calls such as 102072 `set_board_info compiler "[find_gcc]"` from the various baseboards 102073 and has default_target_compile call `find_gcc` itself to find a compiler 102074 if none was specified by the board description. 102075 102076 On systems with dejagnu-1.6.3, if GDB's overrides is needed to support 102077 languages still unknown to dejagnu, we end up in the following 102078 situation: 102079 - The system board files do not set the C compiler anymore, 102080 - GDB's replacement for default_target_compile assumes that the 102081 compiler should have been set up by the board file. 102082 102083 In this situation, no one sets the C compiler for the board and as a 102084 result many test are not compiled and not executed: 102085 102086 [...] 102087 Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ... 102088 gdb compile failed, default_target_compile: No compiler to compile with 102089 Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ... 102090 gdb compile failed, default_target_compile: No compiler to compile with 102091 Running .../gdb/testsuite/gdb.base/structs3.exp ... 102092 gdb compile failed, default_target_compile: No compiler to compile with 102093 [...] 102094 102095 We are observing this error with ROCgdb[2], a downstream port of GDB 102096 supporting AMD GPUs. This port needs to use GDB's override of 102097 default_target_compile to compile HIP programs since dejagnu does not 102098 provide support for this language yet. 102099 102100 This patch changes gdb_default_target_compile_1 in a similar way 102101 default_target_compile has been updated so both implementations remain 102102 compatible. Even if this is not strictly required by GDB just yet, 102103 I believe keeping both implementations in sync desirable. 102104 102105 Using board files provided with dejagnu <=1.6.2 is still supported: if 102106 the compiler is set by the board file, gdb_default_target_compile_1 uses 102107 it and does not need `find_gcc`. 102108 102109 Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb. 102110 102111 [1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044 102112 [2] https://github.com/ROCm-Developer-Tools/ROCgdb 102113 102114 Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669 102115 1021162022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102117 102118 RISC-V: Add T-Head MemPair vendor extension 102119 T-Head has a range of vendor-specific instructions. 102120 Therefore it makes sense to group them into smaller chunks 102121 in form of vendor extensions. 102122 102123 This patch adds the XTheadMemPair extension, a collection of T-Head specific 102124 two-GP-register memory operations. 102125 The 'th' prefix and the "XTheadMemPair" extension are documented in a PR 102126 for the RISC-V toolchain conventions ([1]). 102127 102128 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102129 102130 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102131 1021322022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102133 102134 RISC-V: Add support for literal instruction arguments 102135 This patch introduces support for arbitrary literal instruction 102136 arguments, that are not encoded in the opcode. 102137 102138 A typical use case for this feature would be an instruction that 102139 applies an implicit shift by a constant value on an immediate 102140 (that is a real operand). With this patch it is possible to make 102141 this shift visible in the dissasembly and support such artificial 102142 parameter as part of the asssembly code. 102143 102144 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102145 1021462022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102147 102148 RISC-V: Add T-Head MemIdx vendor extension 102149 T-Head has a range of vendor-specific instructions. 102150 Therefore it makes sense to group them into smaller chunks 102151 in form of vendor extensions. 102152 102153 This patch adds the XTheadMemIdx extension, a collection of T-Head specific 102154 GPR memory access instructions. 102155 The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR 102156 for the RISC-V toolchain conventions ([1]). 102157 102158 In total XTheadCmo introduces the following 44 instructions 102159 (BU,HU,WU only for loads (zero-extend instead of sign-extend)): 102160 102161 * {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2 102162 * {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 102163 * {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 102164 102165 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102166 102167 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102168 1021692022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102170 102171 RISC-V: Add T-Head FMemIdx vendor extension 102172 T-Head has a range of vendor-specific instructions. 102173 Therefore it makes sense to group them into smaller chunks 102174 in form of vendor extensions. 102175 102176 This patch adds the XTheadFMemIdx extension, a collection of 102177 T-Head-specific floating-point memory access instructions. 102178 The 'th' prefix and the "XTheadFMemIdx" extension are documented 102179 in a PR for the RISC-V toolchain conventions ([1]). 102180 102181 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102182 102183 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102184 1021852022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102186 102187 RISC-V: Add T-Head MAC vendor extension 102188 T-Head has a range of vendor-specific instructions. 102189 Therefore it makes sense to group them into smaller chunks 102190 in form of vendor extensions. 102191 102192 This patch adds the XTheadMac extension, a collection of 102193 T-Head-specific multiply-accumulate instructions. 102194 The 'th' prefix and the "XTheadMac" extension are documented 102195 in a PR for the RISC-V toolchain conventions ([1]). 102196 102197 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102198 102199 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102200 1022012022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102202 102203 RISC-V: Add T-Head CondMov vendor extension 102204 T-Head has a range of vendor-specific instructions. 102205 Therefore it makes sense to group them into smaller chunks 102206 in form of vendor extensions. 102207 102208 This patch adds the XTheadCondMov extension, a collection of 102209 T-Head-specific conditional move instructions. 102210 The 'th' prefix and the "XTheadCondMov" extension are documented 102211 in a PR for the RISC-V toolchain conventions ([1]). 102212 102213 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102214 102215 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102216 1022172022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102218 102219 RISC-V: Add T-Head Bitmanip vendor extension 102220 T-Head has a range of vendor-specific instructions. 102221 Therefore it makes sense to group them into smaller chunks 102222 in form of vendor extensions. 102223 102224 This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of 102225 T-Head-specific bitmanipulation instructions. 102226 The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented 102227 in a PR for the RISC-V toolchain conventions ([1]). 102228 102229 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102230 102231 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102232 1022332022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102234 102235 RISC-V: Add support for arbitrary immediate encoding formats 102236 This patch introduces support for arbitrary signed or unsigned immediate 102237 encoding formats. The formats have the form "XsN@S" and "XuN@S" with N 102238 being the number of bits and S the LSB position. 102239 102240 For example an immediate field of 5 bytes that encodes a signed value 102241 and is stored in the bits 24-20 of the instruction word can use the 102242 format specifier "Xs5@20". 102243 102244 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102245 1022462022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102247 102248 RISC-V: Add T-Head SYNC vendor extension 102249 T-Head has a range of vendor-specific instructions. 102250 Therefore it makes sense to group them into smaller chunks 102251 in form of vendor extensions. 102252 102253 This patch adds the XTheadSync extension, a collection of 102254 T-Head-specific multi-processor synchronization instructions. 102255 The 'th' prefix and the "XTheadSync" extension are documented in a PR 102256 for the RISC-V toolchain conventions ([1]). 102257 102258 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102259 102260 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102261 1022622022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102263 102264 RISC-V: Add T-Head CMO vendor extension 102265 T-Head has a range of vendor-specific instructions. 102266 Therefore it makes sense to group them into smaller chunks 102267 in form of vendor extensions. 102268 102269 This patch adds the XTheadCmo extension, a collection of T-Head specific 102270 cache management operations. 102271 The 'th' prefix and the "XTheadCmo" extension are documented in a PR 102272 for the RISC-V toolchain conventions ([1]). 102273 102274 In total XTheadCmo introduces the following 21 instructions: 102275 102276 * DCACHE.{C,CI,I}ALL 102277 * DCACHE.{C,CI,I}{PA,VA,SW} rs1 102278 * DCACHE.C{PAL1,VAL1} rs1 102279 * ICACHE.I{ALL,ALLS} 102280 * ICACHE.I{PA,VA} rs1 102281 * L2CACHE.{C,CI,I}ALL 102282 102283 Contrary to Zicbom, the XTheadCmo instructions don't have a constant 102284 displacement, therefore we have a different syntax for the arguments. 102285 To clarify this is intended behaviour, there is a set of negative test 102286 for Zicbom-style arguments in x-thead-cmo-fail.s. 102287 102288 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 102289 102290 v2: 102291 - Add missing DECLARE_INSN() list 102292 - Fix ordering 102293 102294 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102295 1022962022-09-22 Christoph Müllner <christoph.muellner@vrull.eu> 102297 102298 RISC-V: Add generic support for vendor extensions 102299 This patch introduces changes that allow the integration of vendor ISA 102300 extensions: 102301 * Define a list of vendor extensions (riscv_supported_vendor_x_ext) 102302 where vendor extensions can be added 102303 * Introduce a section with a table in the documentation where vendor 102304 extensions can be added 102305 102306 To add a vendor extension that consists of instructions only, 102307 the following things need to be done: 102308 * Add the extension to the riscv_supported_vendor_x_ext list 102309 * Add lookup entry in riscv_multi_subset_supports 102310 * Documenting the extension in c-riscv.texti 102311 * Add test cases for all instructions 102312 * Add MATCH*/MASK* constants and DECLARE_INSN() for all instructions 102313 * Add new instruction class to enum riscv_insn_class 102314 * Define the instructions in riscv_opcodes 102315 * Additional changes if necessary (depending on the instructions) 102316 102317 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> 102318 1023192022-09-22 Tom de Vries <tdevries@suse.de> 102320 102321 [gdb/symtab] Add all_comp_units/all_type_units views on all_units 102322 Add all_comp_units/all_type_units views on all_units. 102323 102324 Having the views allows us to: 102325 - easily get the number of CUs or TUs in all_units, and 102326 - easily access the nth CU or TU. 102327 102328 This minimizes the use of tu_stats.nr_tus. 102329 102330 Tested on x86_64-linux. 102331 1023322022-09-22 Tom de Vries <tdevries@suse.de> 102333 102334 [gdb/symtab] Rename all_comp_units to all_units 102335 Mechanically rename all_comp_units to all_units: 102336 ... 102337 $ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/* 102338 ... 102339 102340 Tested on x86_64-linux. 102341 1023422022-09-22 Yoshinori Sato <ysato@users.sourceforge.jp> 102343 102344 opcodes: SH fix bank register disassemble. 102345 * sh-dis.c (print_insn_sh): Enforce bit7 of LDC Rm,Rn_BANK and STC 102346 Rm_BANK,Rn is always 1. 102347 1023482022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com> 102349 102350 include: Add macro to ignore -Wunused-but-set-variable 102351 "-Wunused-but-set-variable" warning option can be helpful to track variables 102352 that are written but not read thereafter. But it can be harmful if some of 102353 the code is auto-generated and we have no ways to deal with it. 102354 102355 The particular example is Bison-generated code. 102356 102357 The new DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro can be helpful on 102358 such cases. A typical use of this macro is to place this macro before the 102359 end of user prologues on Bison (.y) files. 102360 102361 include/ChangeLog: 102362 102363 * diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE): New. 102364 1023652022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com> 102366 102367 include: Add macro to ignore -Wuser-defined-warnings 102368 User-defined warnings (on Clang, "-Wuser-defined-warnings") can be harmful 102369 if we have specified "-Werror" and we have no control to disable the warning 102370 ourself. The particular example is Gnulib. 102371 102372 Gnulib generates a warning if the system version of certain functions 102373 are used (to redirect the developer to use Gnulib version). However, 102374 it can be harmful if we cannot easily replace them (e.g. the target is in 102375 the standard C++ library). 102376 102377 The new DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS macro can be helpful on such 102378 cases. A typical use of this macro is to place this macro before including 102379 certain system headers. 102380 102381 include/ChangeLog: 102382 102383 * diagnostics.h (DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS): New. 102384 1023852022-09-22 Andrew Burgess <aburgess@redhat.com> 102386 102387 gdb/python: restrict the names accepted by gdb.register_window_type 102388 I noticed that, from Python, I could register a new TUI window that 102389 had whitespace in its name, like this: 102390 102391 gdb.register_window_type('my window', MyWindowType) 102392 102393 however, it is not possible to then use this window in a new TUI 102394 layout, e.g.: 102395 102396 (gdb) tui new-layout foo my window 1 cmd 1 102397 Unknown window "my" 102398 (gdb) tui new-layout foo "my window" 1 cmd 1 102399 Unknown window ""my" 102400 (gdb) tui new-layout foo my\ window 1 cmd 1 102401 Unknown window "my\" 102402 102403 GDB clearly uses the whitespace to split the incoming command line. 102404 102405 I could fix this by trying to add a mechanism by which we can use 102406 whitespace within a window name, but it seems like an easier solution 102407 if we just forbid whitespace within a window name. Not only is this 102408 easier, but I think this is probably the better solution, identifier 102409 names with spaces in would mean we'd need to audit all the places a 102410 window name could be printed and ensure that the use of a space didn't 102411 make the output ambiguous. 102412 102413 So, having decided to disallow whitespace, I then thought about other 102414 special characters. We currently accept anything as a window name, 102415 and I wondered if this was a good idea. 102416 102417 My concerns were about how special characters used in a window name 102418 might cause confusion, for example, we allow '$' in window names, 102419 which is maybe fine now, but what if one day we wanted to allow 102420 variable expansion when creating new layouts? Or what about starting 102421 a window name with '-'? We already support a '-horizontal' option, 102422 what if we want to add more in the future? Or use of the special 102423 character '{' which has special meaning within a new layout? 102424 102425 In the end I figured it might make sense to place some restrictive 102426 rules in place, and then relax the rules later if/when users complain, 102427 we can consider each relaxation as its requested. 102428 102429 So, I propose that window names should match this regular expression: 102430 102431 [a-zA-Z][-_.a-zA-Z0-9]* 102432 102433 There is a chance that there is user code in the wild which will break 102434 with the addition of this change, but hopefully adapting to the new 102435 restrictions shouldn't be too difficult. 102436 1024372022-09-22 Bruno Larsen <blarsen@redhat.com> 102438 102439 gdb/testsuite: Add test to step through function epilogue 102440 The testsuite implicitly tests GDB's ability to step through epilogues 102441 in multiple tests, without doing it explicitly anywhere. This is 102442 unfortunate, as clang does not emit epilogue information, so using clang 102443 on our testsuite makes many tests fail. This patch adds a central, 102444 explicit test for walking through the epilogue so we can safely remove 102445 this from other tests and have them working with clang. 102446 102447 The test created attempts to step through a simple epilogue, an 102448 epilogue that ends on another epilogue, and epilogues leading to other 102449 function calls. 102450 1024512022-09-22 Bruno Larsen <blarsen@redhat.com> 102452 102453 gdb.base/skip.exp: Use finish to exit functions 102454 gdb.base/skip.exp was making use of a fixed number of step commands to 102455 exit some functions. This caused some problems when using clang to test 102456 GDB, as GDB would need fewer steps to reach the desired spots. For 102457 instance, when testing in the section "step after disabling 3", the log 102458 looks like this: 102459 102460 Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 102461 32 x = baz ((bar (), foo ())); 102462 (gdb) step 102463 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 102464 21 return 1; 102465 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1 102466 step 102467 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 102468 42 return 0; 102469 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2 102470 step 102471 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34 102472 34 test_skip_file_and_function (); 102473 (gdb) step 102474 test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59 102475 59 test_skip (); 102476 (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3 102477 step 102478 test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48 102479 48 } 102480 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4 102481 step 102482 test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60 102483 60 skip1_test_skip_file_and_function (); 102484 (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5 102485 102486 This shows that the feature is working but because the inferior lands in 102487 a different location, it registers as a failure. Seeing as along with 102488 this difference, there are also some differences that depend on gcc 102489 versions (where gdb might stop back at line 32 before entering foo), it 102490 would not be easy to test for this behavior using steps and analzing 102491 where the inferior stops at each point. On the other hand, using 102492 gdb_step_until is not feasible because we'd possibly gloss over stepping 102493 into baz and rendering the whole test useless. Instead, skip.exp now 102494 uses finish to leave functions, synchronizing through compilers and 102495 compiler versions. Some test names were also changed to be a bit more 102496 descriptive. The new log looks like this, independently of compiler used: 102497 102498 Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 102499 32 x = baz ((bar (), foo ())); 102500 (gdb) step 102501 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 102502 21 return 1; 102503 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar 102504 finish 102505 Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 102506 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 102507 32 x = baz ((bar (), foo ())); 102508 Value returned is $2 = 1 102509 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar 102510 step 102511 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 102512 42 return 0; 102513 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo 102514 finish 102515 Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 102516 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 102517 32 x = baz ((bar (), foo ())); 102518 Value returned is $3 = 0 102519 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo 102520 step 102521 34 test_skip_file_and_function (); 102522 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz 102523 1025242022-09-22 Bruno Larsen <blarsen@redhat.com> 102525 102526 fix gdb.base/jit-elf.exp when testing with clang 102527 When using clang as the compiler for the target, gdb.base/jit-elf.exp 102528 was failing because the filename displayed when GDB attached to the 102529 inferior was only showing up as with a relative path, like so: 102530 102531 (gdb) attach 3674146 102532 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146 102533 Reading symbols from /lib64/libm.so.6... 102534 Reading symbols from .gnu_debugdata for /lib64/libm.so.6... 102535 (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) 102536 Reading symbols from /lib64/libc.so.6... 102537 (No debugging symbols found in /lib64/libc.so.6) 102538 Reading symbols from /lib64/ld-linux-x86-64.so.2... 102539 [Thread debugging using libthread_db enabled] 102540 Using host libthread_db library "/lib64/libthread_db.so.1". 102541 0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 102542 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ 102543 (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach 102544 102545 While gcc's output is as follows: 102546 102547 (gdb) attach 3592961 102548 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961 102549 Reading symbols from /lib64/libm.so.6... 102550 Reading symbols from .gnu_debugdata for /lib64/libm.so.6... 102551 (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) 102552 Reading symbols from /lib64/libc.so.6... 102553 (No debugging symbols found in /lib64/libc.so.6) 102554 Reading symbols from /lib64/ld-linux-x86-64.so.2... 102555 [Thread debugging using libthread_db enabled] 102556 Using host libthread_db library "/lib64/libthread_db.so.1". 102557 main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 102558 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ 102559 (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach 102560 102561 This difference only happens when GDB's configure is ran using a 102562 relative path, but seeing as testing the full path is not important for 102563 this specific test, it feels worth fixing anyway. To fix the false 102564 positive, the regexp for checking where gdb has stopped was relaxed a 102565 little to allow the relative path. 102566 1025672022-09-22 Bruno Larsen <blarsen@redhat.com> 102568 102569 gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang 102570 When trying to test gdb.base/msym-bp-shl.exp using clang, it would have 102571 many failures because one of the version of the foo function was being 102572 optimized away. Adding __attribute__ ((used)) to it fixed this. 102573 1025742022-09-22 Bruno Larsen <blarsen@redhat.com> 102575 102576 gdb/testsuite: fix testing gdb.base/skip-inline.exp with clang 102577 When testing gdb.base/skip-inline.exp using clang, we get failures 102578 when trying to step out of functions, since clang requires one fewer 102579 step when compared to gcc. The inferior gets increasingly out of sync 102580 as the test continues because of this difference, which generates those 102581 failures. 102582 102583 This commit fixes this by switching those hardcoded steps to 102584 gdb_step_until, to guarantee that the inferior is always synced to what 102585 the test expects. This approach does not work for the parts that use 102586 step 2 or step 3, so when we identify that clang is being used, those 102587 tests are skipped. 102588 1025892022-09-22 Bruno Larsen <blarsen@redhat.com> 102590 102591 Change gdb.base/skip-solib.exp deal with lack of epilogue information 102592 When running gdb.base/skip-solib.exp, the backtrace tests could fail with 102593 compilers that associated epilogue instructions with the last statement 102594 line of the function, instead of associating it with the closing brace, 102595 despite the feature being fully functional. As an example, when testing 102596 skipping the function square, the testsuite would show 102597 102598 Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5 102599 5 return square(0); 102600 (gdb) step 102601 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 102602 (gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step 102603 bt 102604 #0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 102605 #1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6 102606 #2 0x0000000000401065 in _start () 102607 (gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt 102608 102609 Which means that the feature is working, the testsuite is just 102610 mis-identifying it. To avoid this problem, the skipped function calls 102611 have been sent to a line before `return`, so epilogues won't factor in. 102612 1026132022-09-22 Bruno Larsen <blarsen@redhat.com> 102614 102615 gdb/testsuite: Add a proc to test where compiler links the epilogue 102616 Different compilers link the epilogue of functions to different lines. 102617 As an example, gcc links it to the closing brace of the function, 102618 whereas clang links it to the last statement of the function. This 102619 difference is important for the testsuite, since the where GDB will land 102620 after a step can be wildly different. Where possible, this dependency 102621 should be side-stepped in the testsuite, but it isn't always possible, 102622 so this commit adds a gdb_caching_proc that is able to detect where the 102623 epilogue is linked, so tests can react accordingly. 102624 1026252022-09-22 Clément Chigot <chigot@adacore.com> 102626 102627 ld/testsuite: allow to force another directory for gcc linker 102628 Add a new variable "ld_testsuite_tmpdir" to enable manual configuration 102629 of the -B flag added to gcc calls. This flag ensure that gcc is invoking 102630 the linker and the assembler we want to test. 102631 102632 When launching the testsuite outside of the build tree, the links made 102633 by the testsuite in tmpdir/ld will point to nothing. Thus, even with the 102634 PATH correctly setup towards the linker directory, gcc might end up 102635 falling back to its default linker. Hence this variable to ensure that 102636 gcc, whatever happens, is using the linker we want. 102637 102638 ld/ChangeLog: 102639 102640 * testsuite/config/default.exp: Allow to change -B flag with 102641 ld_testsuite_bindir variable. 102642 1026432022-09-22 Clément Chigot <chigot@adacore.com> 102644 102645 ld/testsuite: skip bootstrap.exp when OFILES are missing 102646 OFILES are normally provided through an environment variable set by 102647 Makefiles. However, when launching the testsuite directly through 102648 runtest outside the build tree, it can be hard to retrieve them. 102649 Thus, they can be missing. 102650 Instead of letting tcl raise an error when trying to access this 102651 OFILES variable, skip bootstrap.exp if it doesn't exist. 102652 102653 ld/ChangeLog: 102654 102655 * testsuite/ld-bootstrap/bootstrap.exp: Skip if OFILES is 102656 missing 102657 1026582022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com> 102659 102660 RISC-V: Remove "b" operand type from disassembler 102661 There are a few operand types not used by any RISC-V instructions. 102662 102663 - Cx 102664 - Vf 102665 - Ve 102666 - [ 102667 - ] 102668 - b 102669 102670 But most of them has a reasoning to keep them: 102671 102672 - Cx : Same as "Ct" except it has a constraint to have rd == rs2 102673 (similar to "Cw"). Although it hasn't used, its role is clear 102674 enough to implement a new instruction with this operand type. 102675 - Vf, Ve : Used by vector AMO instructions (not ratified and real 102676 instructions are not upstreamed yet). 102677 - [, ] : Unused tokenization symbols. Reserving them is not harmful 102678 and a vendor may use this symbol for special purposes. 102679 102680 ... except "b". I could not have found any reference to this operand type 102681 except it works like the "s" operand type. Historically, it seems... it's 102682 just unused from the beginning. Its role is not clear either. 102683 102684 On such cases, we should vacate this room for the new operand type with 102685 much clearer roles. 102686 102687 opcodes/ChangeLog: 102688 102689 * riscv-dis.c (print_insn_args): Remove 'b' operand type. 102690 1026912022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com> 102692 102693 RISC-V: Add macro-only operands to validate_riscv_insn 102694 Although they are not (and should not be) reachable, following macro-only 102695 operands are parsed in the `validate_riscv_insn' function and ignored. 102696 That function also notes that they are macro-only. 102697 102698 - "A" 102699 - "B" 102700 - "I" 102701 102702 Following this convention, this commit adds three remaining macro-only 102703 operands to this function. By doing this, we could instead choose to reject 102704 those operands from appearing in regular instructions later. 102705 102706 - "c" (used by call, tail and jump macros) 102707 - "VM" (used by vmsge.vx and vmsgeu.vx macros) 102708 - "VT" (likewise) 102709 102710 gas/ChangeLog: 102711 102712 * config/tc-riscv.c (validate_riscv_insn): Add "c", "VM" and "VT" 102713 macro-only operand types. 102714 1027152022-09-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 102716 102717 gprofng: fix -Wduplicated-cond warning 102718 gprofng/ChangeLog 102719 2022-09-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 102720 102721 * src/collctrl.cc: Fix -Wduplicated-cond warning. 102722 1027232022-09-22 GDB Administrator <gdbadmin@sourceware.org> 102724 102725 Automatic date update in version.in 102726 1027272022-09-21 Alan Modra <amodra@gmail.com> 102728 102729 bfd BLD-POTFILES.in dependencies 102730 A file that consists of a list of files doesn't depend on those files 102731 being built. This patch came from trying to avoid a maintainer-mode 102732 make -j bug, where the recipe for targmatch.h was being run twice in 102733 parallel. Typical output shown below. 102734 102735 make[2]: Entering directory '/build/gas/all/bfd' 102736 GEN bfdver.h 102737 GEN elf32-target.h 102738 GEN elf64-target.h 102739 GEN targmatch.h 102740 Making info in po 102741 make[3]: Entering directory '/build/gas/all/bfd/po' 102742 cd .. && make po/SRC-POTFILES.in 102743 cd .. && make po/BLD-POTFILES.in 102744 make[4]: Entering directory '/build/gas/all/bfd' 102745 GEN elf32-aarch64.c 102746 GEN elf64-aarch64.c 102747 GEN elf32-ia64.c 102748 GEN elf64-ia64.c 102749 GEN elf32-loongarch.c 102750 GEN elf64-loongarch.c 102751 GEN elf32-riscv.c 102752 GEN elf64-riscv.c 102753 GEN peigen.c 102754 GEN pepigen.c 102755 GEN pex64igen.c 102756 GEN pe-aarch64igen.c 102757 GEN targmatch.h 102758 make[4]: Entering directory '/build/gas/all/bfd' 102759 CCLD doc/chew.stamp 102760 mv: cannot stat 'targmatch.new': No such file or directory 102761 make[4]: *** [Makefile:2325: targmatch.h] Error 1 102762 102763 * Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES). 102764 (po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES). 102765 1027662022-09-21 Simon Marchi <simon.marchi@polymtl.ca> 102767 102768 gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and rename 102769 gdb_bfd.c and remote.c contain identical implementations of a 102770 fileio_error -> errno function. Factor that out to 102771 gdbsupport/fileio.{h,cc}. 102772 102773 Rename it fileio_error_to_host, for symmetry with host_to_fileio_error. 102774 102775 Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df 102776 1027772022-09-21 Simon Marchi <simon.marchi@efficios.com> 102778 102779 gdbsupport: convert FILEIO_* macros to an enum 102780 Converting from free-form macros to an enum gives a bit of type-safety. 102781 This caught places where we would assign host error numbers to what 102782 should contain a target fileio error number, for instance in 102783 target_fileio_pread. 102784 102785 I added the FILEIO_SUCCESS enumerator, because 102786 remote.c:remote_hostio_parse_result initializes the remote_errno output 102787 variable to 0. It seems better to have an explicit enumerator than to 102788 assign a value for which there is no enumerator. I considered 102789 initializing this variable to FILEIO_EUNKNOWN instead, such that if the 102790 remote side replies with an error and omits the errno value, we'll get 102791 an errno that represents an error instead of 0 (which reprensents no 102792 error). But it's not clear what the consequences of that change would 102793 be, so I prefer to err on the side of caution and just keep the existing 102794 behavior (there is no intended change in behavior with this patch). 102795 102796 Note that remote_hostio_parse_resul still reads blindly what the remote 102797 side sends as a target errno into this variable, so we can still end up 102798 with a nonsensical value here. It's not good, but out of the scope of 102799 this patch. 102800 102801 Convert host_to_fileio_error and fileio_errno_to_host to return / accept 102802 a fileio_error instead of an int, and cascade the change in the whole 102803 chain that uses that. 102804 102805 Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03 102806 1028072022-09-21 Simon Marchi <simon.marchi@efficios.com> 102808 102809 gdbsupport: move include/gdb/fileio.h contents to fileio.h 102810 I don't see why include/gdb/fileio.h is placed there. It's not 102811 installed by "make install", and it's not included by anything outside 102812 of gdb/gdbserver/gdbsupport. 102813 102814 Move its content back to gdbsupport/fileio.h. I have omitted the bits 102815 inside an `#if 0`, since it's obviously not used, as well as the 102816 "limits" constants, which are also unused. 102817 102818 Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9 102819 1028202022-09-21 Simon Marchi <simon.marchi@efficios.com> 102821 102822 gdbsupport: change path_join parameter to array_view<const char *> 102823 When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single 102824 character name, we hit this assertion failure: 102825 102826 $ ./gdb -q --data-directory=data-directory -nx ./x 102827 /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. 102828 102829 The backtrace: 102830 102831 #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60 102832 #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239 102833 #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203 102834 #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84 102835 #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122 102836 #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471 102837 #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513 102838 #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209 102839 #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319 102840 #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344 102841 #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 102842 102843 The problem is this line in path_join: 102844 102845 gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); 102846 102847 ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls 102848 HAS_DRIVE_SPEC_1: 102849 102850 #define HAS_DRIVE_SPEC_1(dos_based, f) \ 102851 ((f)[0] && ((f)[1] == ':') && (dos_based)) 102852 102853 This macro accesses indices 0 and 1 of the input string. However, `f` 102854 is a string_view of length 1, so it's incorrect to try to access index 102855 1. We know that the string_view's underlying object is a null-terminated 102856 string, so in practice there's no harm. But as far as the string_view 102857 is concerned, index 1 is considered out of bounds. 102858 102859 This patch makes the easy fix, that is to change the path_join parameter 102860 from a vector of to a vector of `const char *`. Another solution would 102861 be to introduce a non-standard gdb::cstring_view class, which would be a 102862 view over a null-terminated string. With that class, it would be 102863 correct to access index 1, it would yield the NUL character. If there 102864 is interest in having this class (it has been mentioned a few times in 102865 the past) I can do it and use it here. 102866 102867 This was found by running tests such as gdb.ada/arrayidx.exp, which 102868 produce 1-char long filenames, so adding a new test is not necessary. 102869 102870 Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af 102871 1028722022-09-21 Simon Marchi <simon.marchi@polymtl.ca> 102873 102874 gdb: remove TYPE_LENGTH 102875 Remove the macro, replace all uses with calls to type::length. 102876 102877 Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb 102878 1028792022-09-21 Simon Marchi <simon.marchi@polymtl.ca> 102880 102881 gdb: add type::length / type::set_length 102882 Add the `length` and `set_length` methods on `struct type`, in order to remove 102883 the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the 102884 getter, so all the call sites of the macro that are used as a setter are 102885 changed to use the setter method directly. The next patch will remove the 102886 macro completely. 102887 102888 Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4 102889 1028902022-09-21 Simon Marchi <simon.marchi@polymtl.ca> 102891 102892 gdb: remove TYPE_TARGET_TYPE 102893 Remove the macro, replace all uses by calls to type::target_type. 102894 102895 Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed 102896 1028972022-09-21 Simon Marchi <simon.marchi@polymtl.ca> 102898 102899 gdb: add type::target_type / type::set_target_type 102900 Add the `target_type` and `set_target_type` methods on `struct type`, in order 102901 to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to 102902 use the getter, so all the call sites of the macro that are used as a setter 102903 are changed to use the setter method directly. The next patch will remove the 102904 macro completely. 102905 102906 Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161 102907 1029082022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com> 102909 102910 RISC-V: Fix riscv_set_tso declaration 102911 To avoid -Werror=strict-prototypes, this commit changes () to (void). 102912 This is because "()" possibly means a function prototype with indeterminate 102913 arguments on old C standards. 102914 102915 gas/ChangeLog: 102916 102917 * config/tc-riscv.c (riscv_set_tso): Fix declaration. 102918 1029192022-09-21 Alan Modra <amodra@gmail.com> 102920 102921 PR29566, objdump -p considers an empty .gnu.version_r invalid 102922 Allow and ignore an empty section. 102923 102924 PR 29566 102925 * elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or 102926 elf_dynverref for empty sections. 102927 (_bfd_elf_slurp_version_tables): Remove now redundant tests. 102928 1029292022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com> 102930 102931 RISC-V: Set EF_RISCV_TSO also on .option arch 102932 This is a minor fix to commit 96462b012988d35ebb1137a2ad9fd0a96547d79a 102933 ("RISC-V: Implement Ztso extension"). Currently, it sets EF_RISCV_TSO ELF 102934 flag when initial ISA string contains the 'Ztso' extension. However, GAS 102935 has a way to update the ISA string: ".option arch". 102936 102937 When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag 102938 is set when the 'C' extension is detected. Analogously, this commit sets 102939 the EF_RISCV_TSO when the 'Ztso' extension is detected. 102940 102941 gas/ChangeLog: 102942 102943 * config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the 102944 'Ztso' extension is specified via ".option arch" directive. 102945 1029462022-09-21 Alan Modra <amodra@gmail.com> 102947 102948 PR29573, addr2line doesn't display file/line for local symbols 102949 The DWARF standard is clear that DW_AT_linkage_name is optional. 102950 Compilers may not provide the attribute on functions and variables, 102951 even though the language mangles names. g++ does not for local 102952 variables and functions. Without DW_AT_linkage_name, mangled object 102953 file symbols can't be directly matched against the source-level 102954 DW_AT_name in DWARF info. One possibility is demangling the object 102955 file symbols, but that comes with its own set of problems: 102956 1) A demangler might not be available for the compiler/language. 102957 2) Demangling doesn't give the source function name as stored in 102958 DW_AT_name. Class and template parameters must be stripped at 102959 least. 102960 102961 So this patch takes a simpler approach. A symbol matches DWARF info 102962 if the DWARF address matches the symbol address, and if the symbol 102963 name contains the DWARF name as a sub-string. Very likely the name 102964 matching is entirely superfluous. 102965 102966 PR 29573 102967 * dwarf.c (lookup_symbol_in_function_table): Match a symbol 102968 containing the DWARF source name as a substring. 102969 (lookup_symbol_in_variable_table): Likewise. 102970 (_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast 102971 returns false, fall back to comp_unit_find_line. 102972 1029732022-09-21 Alan Modra <amodra@gmail.com> 102974 102975 dwarf2.c: simplify best_fit_len tests 102976 * dwarf2.c (lookup_address_in_function_table): Simplify 102977 best_fit_len test. 102978 (info_hash_lookup_funcinfo): Likewise. 102979 (lookup_symbol_in_function_table): Likewise, also reorder tests 102980 and check "file" is set. 102981 (lookup_symbol_in_variable_table): Reorder tests. 102982 1029832022-09-21 Alan Modra <amodra@gmail.com> 102984 102985 dwarf2.c: mangle_style 102986 non_mangled incorrectly returned "true" for Ada. Correct that, and 102987 add a few more non-mangled entries. Return a value suitable for 102988 passing to cplus_demangle to control demangling. 102989 102990 * dwarf2.c: Include demangle.h. 102991 (mangle_style): Rename from non_mangled. Return DMGL_* value 102992 to suit lang. Adjust all callers. 102993 1029942022-09-21 Alan Modra <amodra@gmail.com> 102995 102996 dwarf2.c remove varinfo and funcinfo sec field 102997 The "sec" field in these structures is only set and used in lookup 102998 functions. It always starts off as NULL. So the only possible effect 102999 of the field is to modify the return of the lookup, which was its 103000 purpose back in 2005 when HJ fixed PR990. Since then we solved the 103001 problem of relocatable object files with the fix for PR2338, so this 103002 field is now redundant. 103003 103004 * dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field. 103005 (lookup_symbol_in_function_table): Don't set or test "sec". 103006 (lookup_symbol_in_variable_table): Likewise. 103007 (info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise. 103008 1030092022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com> 103010 103011 configure: Pass CPPFLAGS_FOR_BUILD to subdirs 103012 Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through 103013 bfd/warning.m4), not AC_SUBSTing the variable causes minor issues. 103014 103015 Fortunately, it didn't cause severe errors but error messages related to 103016 @CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed 103017 to subdirectories through Makefile) remain in config.log. 103018 103019 To avoid invalid invocation of preprocessor for build environment, we 103020 need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to 103021 subdirectories that need it. This is what this commit does. 103022 103023 ChangeLog: 103024 103025 * configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories. 103026 * configure: Regenerate. 103027 1030282022-09-21 Shihua <shihua@iscas.ac.cn> 103029 103030 RISC-V: Implement Ztso extension 103031 This patch support ZTSO extension. It will turn on the tso flag for elf_flags 103032 once we have enabled Ztso extension. This is intended to implement v0.1 of 103033 the proposed specification which can be found in Chapter 25 of, 103034 https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf. 103035 103036 bfd\ChangeLog: 103037 103038 * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag. 103039 * elfxx-riscv.c: Add Ztso's arch. 103040 103041 binutils\ChangeLog: 103042 103043 * readelf.c (get_machine_flags): Set TSO flag. 103044 103045 gas\ChangeLog: 103046 103047 * config/tc-riscv.c (riscv_set_tso): Ditto. 103048 (riscv_set_arch): Ditto. 103049 * testsuite/gas/riscv/ztso.d: New test. 103050 103051 include\ChangeLog: 103052 103053 * elf/riscv.h (EF_RISCV_TSO): Ditto. 103054 1030552022-09-21 Nelson Chu <nelson@rivosinc.com> 103056 103057 RISC-V: Always generate R_RISCV_CALL_PLT reloc for call in assembler. 103058 Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now, 103059 https://github.com/bminor/binutils-gdb/commit/3b1450b38c644f99aa2e211747b428b9f8d15cca 103060 103061 And the psabi already deprecate the CALL reloc, 103062 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0 103063 103064 Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if 103065 it has @plt postfix. I believe LLVM (https://reviews.llvm.org/D132530) already 103066 support this, so GNU as should do the same thing. 103067 103068 gas/ 103069 * config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for 103070 call, even if it has @plt postfix. 103071 * testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT. 103072 * testsuite/gas/riscv/relax-reloc.d: Likewise. 103073 ld/ 103074 * testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT. 103075 1030762022-09-21 GDB Administrator <gdbadmin@sourceware.org> 103077 103078 Automatic date update in version.in 103079 1030802022-09-21 Alan Modra <amodra@gmail.com> 103081 103082 Re: PowerPC64 pcrel got relocs against local symbols 103083 The last patch wasn't all that shiny. There are rather a lot more 103084 relocations that can hit the assertion in md_apply_fix if the symbol 103085 is local or absolute. Fix them all. 103086 103087 * config/tc-ppc.c (ppc_force_relocation): Add all relocs that 103088 expect a symbol in md_apply_fix. Remove tls pcrel relocs 103089 already covered in general tls match range. 103090 1030912022-09-21 Alan Modra <amodra@gmail.com> 103092 103093 looping in alpha_vms_slurp_relocs 103094 The direct cause for the looping was failing to test for error return 103095 from _bfd_vms_get_object_record inside a while(1) loop. Fix that. 103096 Also record status of first alpha_vms_slurp_relocs call and return 103097 that for all subsequent calls. (The object format has one set of 103098 relocation records for all sections.) If the first call fails, all 103099 others should too. 103100 103101 * vms-alpha.c (struct vms_private_data_struct): Make reloc_done 103102 a tri-state int. 103103 (alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on 103104 failure. Return that status on subsequent calls. Check 103105 _bfd_vms_get_object_record return status. 103106 (alpha_vms_get_reloc_upper_bound): Return status from 103107 alpha_vms_slurp_relocs. 103108 (alpha_vms_write_exec): Exclude sections with contents NULL due 103109 to previous errors from layout, and don't try to write them. 103110 1031112022-09-20 Dmitry Selyutin <ghostmansd@gmail.com> 103112 103113 ppc/svp64: test setvl ms operand 103114 1031152022-09-20 Tom Tromey <tom@tromey.com> 103116 103117 Make stdin_event_handler static 103118 I noticed that stdin_event_handler is only used in event-top.c, so 103119 this patch changes it to be 'static'. 103120 1031212022-09-20 Tom Tromey <tromey@adacore.com> 103122 103123 Constify some target_so_ops instances 103124 This changes some target_so_ops instances to be const. This makes 103125 their use a little more obvious (they can't be mutated) and also 103126 allows for the removal of some initialization code. 103127 103128 Move solib_ops into gdbarch 103129 This changs solib_ops to be an ordinary gdbarch value and updates all 103130 the uses. This removes a longstanding FIXME and makes the code 103131 somewhat cleaner as well. 103132 103133 Remove current_target_so_ops 103134 current_target_so_ops is only set in a single place. It seems better 103135 to simply remove it. 103136 1031372022-09-20 Andrew Burgess <aburgess@redhat.com> 103138 103139 gdb/testsuite: add a debuginfod-support.exp helper library 103140 We currently have a single test for GDB's debuginfod support, this is 103141 gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the 103142 setup, starts debuginfod, and then does the testing. 103143 103144 This commit tries to split the existing script in two, there is a new 103145 library lib/debuginfod-support.exp, which contains a helper functions 103146 related to running debuginfod tests. All the code in the new library 103147 is basically copied from the existing test case (which is why I 103148 retained the copyright date range on the new library), with some minor 103149 adjustments to try and make the code a little more generic. 103150 103151 One change I made, for example, is the library offers functions to 103152 shut down debuginfod, previously we just relied on expect shutting 103153 down debuginfod when dejagnu completed. 103154 103155 The existing test script is updated to make use of the new library 103156 code, and this test is still passing for me. The only change in the 103157 test results is a single test where I changed the name to remove the 103158 port number from the test name - the port number can change from run 103159 to run, so could make it hard to compare test results. 103160 103161 I have also done a little light house keeping on the original test 103162 script, updating and adding new comments, and making use of 103163 proc_with_prefix in a couple of places. 103164 1031652022-09-20 liuzhensong <liuzhensong@loongson.cn> 103166 103167 LoongArch: Set macro SUB_SEGMENT_ALIGN to 0. 103168 1031692022-09-20 Nick Clifton <nickc@redhat.com> 103170 103171 Stop strip from complaining about empty note sections when stripping a binary for a second time. 103172 * objcopy.c (copy_object): Do not issue a warning message when 103173 encountering empty .gnu.build.attribute sections. 103174 103175 New Serbian translations for various binutils sub-directories. 103176 1031772022-09-20 Zeke Lu <lvzecai@gmail.com> 103178 103179 Bug 29580 - typo in warning message: .note.gnu.build-id data size is too bug 103180 1031812022-09-20 Xi Ruoyao <xry111@xry111.site> 103182 103183 LoongArch: Fix R_LARCH_IRELATIVE insertion after elf_link_sort_relocs 103184 loongarch_elf_finish_dynamic_symbol is called after elf_link_sort_relocs 103185 if -z combreloc. elf_link_sort_relocs redistributes the contents of 103186 .rela.* sections those would be merged into .rela.dyn, so the slot for 103187 R_LARCH_IRELATIVE may be out of relplt->contents now. 103188 103189 To make things worse, the boundary check 103190 103191 dyn < dyn + relplt->size / sizeof (*dyn) 103192 103193 is obviously wrong ("x + 10 < x"? :), causing the issue undetected 103194 during the linking process and the resulted executable suddenly crashes 103195 at runtime. 103196 103197 The issue was found during an attempt to add static-pie support to the 103198 toolchain. 103199 103200 Fix it by iterating through the inputs of .rela.dyn to find the slot. 103201 1032022022-09-20 Xi Ruoyao <xry111@xry111.site> 103203 103204 LoongArch: Don't write into GOT for local ifunc 103205 Local ifuncs are always resolved at runtime via R_LARCH_IRELATIVE, so 103206 there is no need to write anything into GOT. And when we write the GOT 103207 we actually trigger a heap-buffer-overflow: If a and b are different 103208 sections, we cannot access something in b with "a->contents + (offset 103209 from a)" because "a->contents" and "b->contents" are heap buffers 103210 allocated separately, not slices of a large buffer. 103211 103212 So stop writing into GOT for local ifunc now. 103213 1032142022-09-20 GDB Administrator <gdbadmin@sourceware.org> 103215 103216 Automatic date update in version.in 103217 1032182022-09-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 103219 103220 gprofng: build documentation only if BUILD_MAN is true 103221 gprofng/ChangeLog 103222 2022-09-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 103223 103224 PR gprofng/29476 103225 * gprofng/Makefile.am: Build documentation only if BUILD_MAN is true 103226 * gprofng/Makefile.in: Rebuild. 103227 * gprofng/configure: Rebuild. 103228 1032292022-09-19 Enze Li <enze.li@hotmail.com> 103230 103231 gdb: add ATTRIBUTE_PRINTF to gdb_bfd_error_handler 103232 I see this error when building with clang, 103233 103234 CXX gdb_bfd.o 103235 gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral] 103236 const std::string str = string_vprintf (fmt, ap_copy); 103237 ^~~ 103238 1 error generated. 103239 103240 This patch adds missing ATTRIBUTE_PRINTF to fix the error. 103241 103242 Tested on x86_64-linux with gcc 12 and clang 14. 103243 1032442022-09-19 GDB Administrator <gdbadmin@sourceware.org> 103245 103246 Automatic date update in version.in 103247 1032482022-09-18 GDB Administrator <gdbadmin@sourceware.org> 103249 103250 Automatic date update in version.in 103251 1032522022-09-17 Tom de Vries <tdevries@suse.de> 103253 103254 [gdb/symtab] Fix "file index out of range" complaint 103255 With the test-case included in this commit, we run into this FAIL: 103256 ... 103257 (gdb) p var^M 103258 During symbol reading: file index out of range^M 103259 $1 = 0^M 103260 (gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints 103261 ... 103262 103263 This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with 103264 --gc-sections"), which contains this change in read_file_scope: 103265 ... 103266 - handle_DW_AT_stmt_list (die, cu, fnd, lowpc); 103267 + if (lowpc != highpc) 103268 + handle_DW_AT_stmt_list (die, cu, fnd, lowpc); 103269 ... 103270 103271 The change intends to avoid a problem with a check in 103272 lnp_state_machine::check_line_address, but also prevents the file and dir 103273 tables from being read, which causes the complaint. 103274 103275 Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the 103276 call to dwarf_decode_lines in handle_DW_AT_stmt_list. 103277 103278 Tested on x86_64-linux. 103279 103280 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561 103281 1032822022-09-17 GDB Administrator <gdbadmin@sourceware.org> 103283 103284 Automatic date update in version.in 103285 1032862022-09-17 Kevin Buettner <kevinb@redhat.com> 103287 103288 BFD error message suppression test case 103289 This commit adds a GDB test case which tests GDB's BFD error handler 103290 hook for suppressing output of all but the first identical messages. 103291 103292 See the comment at the beginning of bfd-errors.exp for details about 103293 this new test. 103294 103295 I've tested this test for both 32- and 64-bit ELF files and also 103296 on both little endian and big endian machines. It also works for 103297 both native and remote targets. The only major restriction is that 103298 it only works for ELF targets. 103299 1033002022-09-17 Kevin Buettner <kevinb@redhat.com> 103301 103302 Suppress printing of superfluous BFD error messages 103303 This commit adds a hook to the BFD error handler for suppressing 103304 identical messages which have been output once already. 103305 103306 It's motivated by this Fedora bug... 103307 103308 https://bugzilla.redhat.com/show_bug.cgi?id=2083315 103309 103310 ...in which over 900,000 BFD error messages are output when attaching 103311 to firefox. From the bug report, the messages all say: 103312 103313 BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38) 103314 103315 Since there's no (additional) context which might assist the user in 103316 determining what's wrong, there's really no point in outputting more 103317 than one message. Of course, if BFD should output some 103318 other/different message, it should be output too, but all future 103319 messages identical to those already output should be suppressed. 103320 103321 For the firefox problem, it turned out that there were only 37 103322 sections, but something was referring to section #38. I haven't 103323 investigated further to find out how this came to be. 103324 103325 Despite this problem, useful debugging might still be done, especially 103326 if the user doesn't care about debugging the problematic library. 103327 103328 If it turns out that knowing the quantity of messages might be useful, 103329 I've implemented the suppression mechanism by keeping a count of each 103330 identical message. A new GDB command, perhaps a 'maintenance' 103331 command, could be added to print out each message along with the 103332 count. I haven't implemented this though because I'm not convinced of 103333 its utility. Also, the BFD message printer has support for BFD- 103334 specific format specifiers. The BFD message strings that GDB stores 103335 in its map are sufficient for distinguishing messages from each 103336 other, but are not identical to those output by BFD's default error 103337 handler. So, that problem would need to be solved too. 103338 1033392022-09-16 Tom de Vries <tdevries@suse.de> 103340 103341 [gdb/symtab] Handle named DW_TAG_unspecified_type DIE 103342 With the test-case included in the patch, we run into: 103343 ... 103344 (gdb) info types -q std::nullptr_t^M 103345 During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M 103346 ^M 103347 File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M 103348 2198: typedef decltype(nullptr) std::nullptr_t;^M 103349 (gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \ 103350 without complaint 103351 ... 103352 103353 Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify 103354 in the test-case using "maint print symbols" that the symbol exists. 103355 103356 Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0. 103357 103358 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271 103359 1033602022-09-16 Tom de Vries <tdevries@suse.de> 103361 103362 [gdb/tdep] Fix PowerPC IEEE 128-bit format arg passing 103363 On a powerpc system with gcc 12 built to default to 128-bit IEEE long double, 103364 I run into: 103365 ... 103366 (gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M 103367 $8 = 0 + 0i^M 103368 (gdb) FAIL: gdb.base/varargs.exp: print \ 103369 find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4) 103370 ... 103371 103372 This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param. 103373 103374 Fix this and similar cases, and expand the test-case to test handling of 103375 homogeneous aggregates. 103376 103377 Tested on ppc64le-linux, power 10. 103378 103379 Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com> 103380 Tested-by: Carl Love <cel@us.ibm.com> 103381 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543 103382 1033832022-09-16 Tom de Vries <tdevries@suse.de> 103384 103385 [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64 103386 [ Another attempt at fixing the problem described in commit cd919f5533c 103387 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ] 103388 103389 When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with 103390 aarch64-linux, we run into: 103391 ... 103392 (gdb) continue^M 103393 Continuing.^M 103394 ^M 103395 Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \ 103396 tmp-dw2-dir-file-name.c:999^M 103397 (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ 103398 compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ 103399 compdir_missing__ldir_missing__file_basename 103400 ... 103401 103402 The breakpoint set at compdir_missing__ldir_missing__file_basename_label, 103403 address 0x400608 starts at a line entry: 103404 ... 103405 CU: tmp-dw2-dir-file-name.c: 103406 File name Line number Starting address View Stmt 103407 tmp-dw2-dir-file-name.c 999 0x400608 x 103408 tmp-dw2-dir-file-name.c 1000 0x40062c x 103409 tmp-dw2-dir-file-name.c - 0x40062c 103410 ... 103411 and therefore the breakpoint is printed without instruction address. 103412 103413 In contrast, for x86_64-linux, we have the breakpoint printed with instruction 103414 address: 103415 ... 103416 (gdb) continue^M 103417 Continuing.^M 103418 ^M 103419 Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \ 103420 at tmp-dw2-dir-file-name.c:999^M 103421 (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ 103422 compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ 103423 compdir_missing__ldir_missing__file_basename 103424 ... 103425 103426 The breakpoint set at compdir_missing__ldir_missing__file_basename_label, 103427 address 0x004004c1 doesn't start at a line entry: 103428 ... 103429 CU: tmp-dw2-dir-file-name.c: 103430 File name Line number Starting address View Stmt 103431 tmp-dw2-dir-file-name.c 999 0x4004bd x 103432 tmp-dw2-dir-file-name.c 1000 0x4004d3 x 103433 tmp-dw2-dir-file-name.c - 0x4004d3 103434 ... 103435 103436 Fix this by: 103437 - unifying behaviour between the archs by adding an explicit line number entry 103438 for the address compdir_missing__ldir_missing__file_basename_label, making 103439 the FAIL reproducible on x86_64-linux. 103440 - expecting the breakpoint to be printed without instruction address. 103441 103442 Tested on x86_64-linux and aarch64-linux. 103443 1034442022-09-16 Tom de Vries <tdevries@suse.de> 103445 103446 [gdb] Handle pending ^C after rl_callback_read_char 103447 In completion tests in various test-cases, we've been running into these 103448 "clearing input line" timeouts: 103449 ... 103450 (gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd" 103451 FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout) 103452 ... 103453 where $cmd == "maintenance selftest name_that_does_not_exist". 103454 103455 AFAIU, the following scenario happens: 103456 - expect sends "$cmd\t" 103457 - gdb detects the stdin event, and calls rl_callback_read_char until it 103458 comes to handle \t 103459 - readline interprets the \t as completion, tries to complete, fails to do so, 103460 outputs a bell (^G) 103461 - expect sees the bell, and proceeds to send ^C 103462 - readline is still in the call to rl_callback_read_char, and stores the 103463 signal in _rl_caught_signal 103464 - readline returns from the call to rl_callback_read_char, without having 103465 handled _rl_caught_signal 103466 - gdb goes to wait for the next event 103467 - expect times out waiting for "Quit", the expected reaction for ^C 103468 103469 Fix this by handling pending signals after each call to rl_callback_read_char. 103470 103471 The fix is only available for readline 8.x, if --with-system-readline provides 103472 an older version, then the fix is disabled due to missing function 103473 rl_check_signals. 103474 103475 Tested on x86_64-linux. 103476 103477 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813 103478 1034792022-09-16 Alan Modra <amodra@gmail.com> 103480 103481 PowerPC64 pcrel got relocs against local symbols 103482 Not that anyone would want to indirect via the GOT when an address can 103483 be loaded directly with pla, the following: 103484 103485 pld 3,x@got@pcrel 103486 x: 103487 103488 leads to "Internal error in md_apply_fix", because the generic parts 103489 of assembler fixup handling convert the fx_pcrel fixup to one without 103490 a symbol. Stop that happening. 103491 103492 * config/tc-ppc.c (ppc_force_relocation): Add PLT_PCREL34 and 103493 assorted GOT_PCREL34 relocs. 103494 1034952022-09-16 Alan Modra <amodra@gmail.com> 103496 103497 pdb sanity check block_size 103498 * pdb.c (pdb_get_elt_at_index): Only allow block_size to be 103499 512, 1024, 2048, or 4096. 103500 1035012022-09-16 Nelson Chu <nelson@rivosinc.com> 103502 103503 RISC-V: Make g imply zmmul extension. 103504 bfd/ 103505 * elfxx-riscv.c (riscv_implicit_subset): Moved entry of m after g, 103506 so that g can imply zmmul. 103507 gas/ 103508 * testsuite/gas/riscv/attribute-01.d: Updated. 103509 * testsuite/gas/riscv/attribute-02.d: Likewise. 103510 * testsuite/gas/riscv/attribute-03.d: Likewise. 103511 * testsuite/gas/riscv/attribute-04.d: Likewise. 103512 * testsuite/gas/riscv/attribute-05.d: Likewise. 103513 * testsuite/gas/riscv/attribute-10.d: Likewise. 103514 * testsuite/gas/riscv/march-imply-g.d: Likewise. 103515 * testsuite/gas/riscv/march-imply-unsupported.d: Likewise. 103516 1035172022-09-16 GDB Administrator <gdbadmin@sourceware.org> 103518 103519 Automatic date update in version.in 103520 1035212022-09-15 Tsukasa OI <research_trasio@irq.a4lg.com> 103522 103523 bfd, binutils, gas: Remove/mark unused variables 103524 Clang generates a warning on unused (technically, written but not read 103525 thereafter) variables. By the default configuration (with "-Werror"), it 103526 causes a build failure (unless "--disable-werror" is specified). 103527 103528 This commit adds ATTRIBUTE_UNUSED attribute to some of them, which means 103529 they are *possibly* unused (can be used but no warnings occur when 103530 unused) and removes others. 103531 103532 bfd/ChangeLog: 103533 103534 * elf32-lm32.c (lm32_elf_size_dynamic_sections): Mark unused 103535 rgot_count variable. 103536 * elf32-nds32.c (elf32_nds32_unify_relax_group): Remove unused 103537 count variable. 103538 * mmo.c (mmo_scan): Mark unused lineno variable. 103539 103540 binutils/ChangeLog: 103541 103542 * windmc.c (write_rc): Remove unused i variable. 103543 103544 gas/ChangeLog: 103545 103546 * config/tc-riscv.c (riscv_ip): Remove unused argnum variable. 103547 103548 ld/ChangeLog: 103549 103550 * pe-dll.c (generate_reloc): Remove unused bi and page_count 103551 variables. 103552 1035532022-09-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 103554 103555 gprofng: fix build issues on musl 103556 gprofng/ChangeLog 103557 2022-09-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 103558 103559 PR gprofng/29477 103560 * configure.ac: Set __MUSL_LIBC. 103561 * configure: Rebuild. 103562 * common/config.h.in: Rebuild. 103563 * src/collector_module.h: Fix compiler errors because mmap64, open64, 103564 pwrite64 are macros and getcontext() is absent on musl. 103565 * libcollector/collector.c: Likewise. 103566 * libcollector/hwprofile.c: Likewise. 103567 * libcollector/iolib.c: Likewise. 103568 * libcollector/libcol_util.c: Likewise. 103569 * libcollector/linetrace.c: Likewise. 103570 * libcollector/memmgr.c: Likewise. 103571 * libcollector/profile.c: Likewise. 103572 * libcollector/unwind.c: Likewise. 103573 * libcollector/dispatcher.c: Likewise. 103574 * src/Experiment.cc: Likewise. 103575 * libcollector/collector.h: Use dlsym() because dlvsym() is not defined 103576 on musl. 103577 * libcollector/iotrace.c: Remove interposition of versioned functions. 103578 * libcollector/mmaptrace.c: Likewise. 103579 * libcollector/libcol_util.h: Fix -Wint-to-pointer-cast warnings. 103580 * libcollector/jprofile.c: Likewise. 103581 * libcollector/synctrace.c: Include "collector.h". 103582 * src/Print.cc: Use get_basename() because basename() is not defined 103583 on musl. 103584 * common/hwcdrv.c: Fix -Wformat= warnings. 103585 1035862022-09-15 GDB Administrator <gdbadmin@sourceware.org> 103587 103588 Automatic date update in version.in 103589 1035902022-09-14 Rupesh Potharla <Rupesh.Potharla@amd.com> 103591 103592 Binutils: Readelf testcase failing with clang 103593 * testsuite/binutils-all/readelf.exp (readelf_wi_test): Extend 103594 regexps to allow for output genreated by the Clang compiler. 103595 1035962022-09-14 Alan Modra <amodra@gmail.com> 103597 103598 looping in bfd_mach_o_fat_openr_next_archived_file 103599 mach-o.c doesn't sanity check mach-o-fat archives, making it easy for 103600 fuzzers to create an archive with mach_o_fat_archentry headers that 103601 point to the same offset. bfd_mach_o_fat_openr_next_archived_file 103602 uses the previous element offset to find its header, and thus the next 103603 element. If two offsets are the same, any tool reading the archive 103604 will get stuck. This patch rejects such archives, and any with 103605 overlapping elements. 103606 103607 * mach-o.c (overlap_previous): New function. 103608 (bfd_mach_o_fat_archive_p): Sanity check that elements do not 103609 overlap each other or the file and archive headers. 103610 1036112022-09-14 Alan Modra <amodra@gmail.com> 103612 103613 regen pofiles 103614 1036152022-09-14 Tsukasa OI <research_trasio@irq.a4lg.com> 103616 103617 bfd: Stop using -Wstack-usage=262144 when built with Clang 103618 Some components of GNU Binutils will pass "-Wstack-usage=262144" when 103619 "GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage", 103620 despite that related configuration part in bfd/warning.m4 handles the latest 103621 Clang (15.0.0 as of this writing) as "GCC >= 5.0". 103622 103623 The option "-Wstack-usage" was ignored when the first version of Clang is 103624 released but even this "ignoring" behavior is removed before Clang 4.0.0. 103625 So, if we give Clang "-Wstack-usage=262144", it generates a warning, making 103626 the build failure. 103627 103628 This commit checks "__clang__" macro to prevent adding the option if the 103629 compiler is identified as Clang. 103630 103631 bfd/ChangeLog: 103632 103633 * warning.m4: Stop appending "-Wstack-usage=262144" option when 103634 compiled with Clang. 103635 * configure: Regenerate. 103636 103637 binutils/ChangeLog: 103638 103639 * configure: Regenerate. 103640 103641 gas/ChangeLog: 103642 103643 * configure: Regenerate. 103644 103645 gold/ChangeLog: 103646 103647 * configure: Regenerate. 103648 103649 gprof/ChangeLog: 103650 103651 * configure: Regenerate. 103652 103653 ld/ChangeLog: 103654 103655 * configure: Regenerate. 103656 103657 opcodes/ChangeLog: 103658 103659 * configure: Regenerate. 103660 1036612022-09-14 Alan Modra <amodra@gmail.com> 103662 103663 Modify ld-ctf test files to suit ARM 103664 The "@" char starts a comment on ARM. 103665 103666 * testsuite/ld-ctf/diag-ctf-version-0.s: Replace @progbits with 103667 %progbits. 103668 * testsuite/ld-ctf/diag-ctf-version-2-unsupported-feature.s: Likewise. 103669 * testsuite/ld-ctf/diag-ctf-version-f.s: Likewise. 103670 * testsuite/ld-ctf/diag-cttname-invalid.s: Likewise. 103671 * testsuite/ld-ctf/diag-cttname-null.s: Likewise. 103672 * testsuite/ld-ctf/diag-cuname.s: Likewise. 103673 * testsuite/ld-ctf/diag-decompression-failure.s: Likewise. 103674 * testsuite/ld-ctf/diag-parlabel.s: Likewise. 103675 * testsuite/ld-ctf/diag-parname.s: Likewise. 103676 * testsuite/ld-ctf/diag-strlen-invalid.s: Likewise. 103677 * testsuite/ld-ctf/diag-unsupported-flag.s: Likewise. 103678 * testsuite/ld-ctf/diag-wrong-magic-number.s: Likewise. 103679 1036802022-09-14 Alan Modra <amodra@gmail.com> 103681 103682 asan: som_set_reloc_info heap buffer overflow 103683 Also a bugfix. The first time the section was read, the contents 103684 didn't supply an addend. 103685 103686 * som.c (som_set_reloc_info): Sanity check offset. Do process 103687 contents after reading. Tidy section->contents after freeing. 103688 1036892022-09-14 Alan Modra <amodra@gmail.com> 103690 103691 ubsan: som_is_space null dereference 103692 On objcopy of fuzzed file. 103693 103694 * som.c (som_write_fixups): Exit loop if space sections all 103695 processed. 103696 1036972022-09-14 Alan Modra <amodra@gmail.com> 103698 103699 msan: vms-alpha use-of-uninitialized-value in dst_retrieve_location 103700 * vms-alpha.c (dst_define_location): Init any unused entries. 103701 1037022022-09-14 Alan Modra <amodra@gmail.com> 103703 103704 ubsan: arm-dis.c index out of bounds 103705 We are way off in the weeds with this one, and will be printing 103706 <UNPREDICTABLE> for S > 10. 103707 103708 * arm-dis.c (print_insn_cde): Wrap 'T' value. 103709 1037102022-09-14 Alan Modra <amodra@gmail.com> 103711 103712 PR29540, R_PPC64_NONE in .rela.dyn when linking Linux vdso 103713 PR 29540 103714 * elf64-ppc.c (allocate_dynrelocs): Don't alloc space for relocs 103715 against discarded sections. 103716 (ppc64_elf_size_dynamic_sections): Use standard test for discarded 103717 sections. 103718 * elf32-ppc.c (allocate_dynrelocs): Don't alloc space for relocs 103719 against discarded sections. 103720 (ppc_elf_size_dynamic_sections): Use standard test for discarded 103721 sections. 103722 1037232022-09-14 GDB Administrator <gdbadmin@sourceware.org> 103724 103725 Automatic date update in version.in 103726 1037272022-09-13 Aaron Merey <amerey@redhat.com> 103728 103729 objdump: '-S' should trigger search for separate debuginfo. 103730 Add with_source_code to the command line options that trigger 103731 might_need_separate_debug_info and dump_any_debugging. This helps 103732 'objdump -S' download missing files via debuginfod without the need for 103733 specifying extra command line options like '-L'. 103734 1037352022-09-13 Bruno Larsen <blarsen@redhat.com> 103736 103737 gdb/testsuite: Update gdb.base/so-impl-ld.exp 103738 gdb.base/so-impl-ld.exp was setup assuming that the compiler would add 103739 epilogue information and that GDB would stop in the } line. This would 103740 make clang tests fail like so: 103741 103742 step^M 103743 solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M 103744 7|__ return arg*arg;|__|___/* HERE */^M 103745 (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call 103746 next^M 103747 main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M 103748 22|_ return 0;^M 103749 (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call 103750 next^M 103751 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M 103752 (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call 103753 103754 This patch changes it so solib_main has 2 lines where GDB can stop 103755 regardless of compiler choices, and updates the exp file to 103756 generically deal with unknown number of steps until leaving that 103757 function. 103758 1037592022-09-13 Bruno Larsen <blarsen@redhat.com> 103760 103761 gdb/testsuite: introduce gdb_step_until 103762 Currently, GDB's testsuite uses a set amount of step commands to exit 103763 functions. This is a problem if a compiler emits different epilogue 103764 information from gcc, or emits no epilogue information at all. It was 103765 most noticeable if Clang was used to test GDB. 103766 103767 To fix this unreliability, this commit introduces a new proc that will 103768 step the inferior until it is stopped at a line that matches the given 103769 regexp, or until it steps too many times - defined as an optional 103770 argument. If the line is found, it shows up as a single PASS in the 103771 test, and if the line is not found, a single FAIL is emitted. 103772 103773 This patch only introduces this proc, but does not add it to any 103774 existing tests, these will be introduced in the following commit. 103775 1037762022-09-13 Bruno Larsen <blarsen@redhat.com> 103777 103778 explicitly test for stderr in gdb.base/dprintf.exp 103779 Not all compilers add stderr debug information when compiling a 103780 program. Clang, for instance, prefers to add nothing from standard 103781 libraries and let an external debug package have this information. 103782 Because of this, gdb.base/dprintf.exp was failing when GDB attempted to 103783 use dprintf as a call to fprintf(stderrr, ...), like this: 103784 103785 (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call 103786 continue 103787 Continuing. 103788 kickoff 1234 103789 also to stderr 1234 103790 'stderr' has unknown type; cast it to its declared type 103791 (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout) 103792 103793 To avoid this false positive, we explicitly test to see if 103794 the compiler has added information about stderr at all, and abort 103795 testing dprintf as an fprintf call if it is unavailable. 103796 1037972022-09-13 Mark Harmstone <mark@harmstone.com> 103798 103799 Add pdb archive format 103800 Resubmitted with changes in 103801 https://sourceware.org/pipermail/binutils/2022-September/122791.html 103802 made. 103803 1038042022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 103805 103806 gdb/csky rm csky_print_registers_info 103807 The reason for implementing this interface is that we want to print 103808 GPR, PC, EPC, PSR and EPSR when the "info register" command 103809 is executed. 103810 103811 A prev patch has added PC, EPC, PSR and EPSR to reggroup 103812 general_group, the purpose has been achieved, so this function is 103813 no longer required. 103814 1038152022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 103816 103817 gdb/csky rm csky_memory_insert/remove_breakpoint 103818 Software breakpoints are inserted or removed by the gdb stub via 103819 remote protocol, these two functions are no longer needed. 103820 1038212022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 103822 103823 gdb/csky add unwinder for long branch cases 103824 There are two sequences of instructions for long branch: 103825 1. jmpi [pc+4] //insn code: 0xeac00001 103826 .long addr 103827 103828 2. lrw t1, [pc+8] //insn code: 0xea8d0002 103829 jmp t1 //insn code: 0x7834 103830 nop //insn code: 0x6c03 103831 .long addr 103832 1038332022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 103834 103835 gdbserver/csky add csky gdbserver support 103836 Add new files: 103837 gdb/arch/csky.c 103838 gdb/arch/csky.h 103839 gdb/features/cskyv2-linux.c 103840 gdbserver/linux-csky-low.cc 103841 103842 1. In gdb/arch/csky.c file, add function "csky_create_target_description()" 103843 for csky_target::low_arch_setup(). later, it can be used for csky native gdb. 103844 103845 2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include 103846 gprs, pc, hi, lo, float, vector and float control registers. 103847 103848 3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to 103849 get/set registers. The main data structures in asm/ptrace.h are: 103850 struct pt_regs { 103851 unsigned long tls; 103852 unsigned long lr; 103853 unsigned long pc; 103854 unsigned long sr; 103855 unsigned long usp; 103856 103857 /* 103858 * a0, a1, a2, a3: 103859 * r0, r1, r2, r3 103860 */ 103861 unsigned long orig_a0; 103862 unsigned long a0; 103863 unsigned long a1; 103864 unsigned long a2; 103865 unsigned long a3; 103866 103867 /* 103868 * r4 ~ r13 103869 */ 103870 unsigned long regs[10]; 103871 103872 /* r16 ~ r30 */ 103873 unsigned long exregs[15]; 103874 103875 unsigned long rhi; 103876 unsigned long rlo; 103877 unsigned long dcsr; 103878 }; 103879 103880 struct user_fp { 103881 unsigned long vr[96]; 103882 unsigned long fcr; 103883 unsigned long fesr; 103884 unsigned long fid; 103885 unsigned long reserved; 103886 }; 103887 1038882022-09-13 GDB Administrator <gdbadmin@sourceware.org> 103889 103890 Automatic date update in version.in 103891 1038922022-09-12 Tom Tromey <tromey@adacore.com> 103893 103894 Use checked_static_cast in more places 103895 I went through all the uses of dynamic_cast<> in gdb, looking for ones 103896 that could be replaced with checked_static_cast. This patch is the 103897 result. Regression tested on x86-64 Fedora 34. 103898 1038992022-09-12 Peter Bergner <bergner@linux.ibm.com> 103900 103901 ppc: Document the -mfuture and -Mfuture options and make them usable 103902 The -mfuture and -Mfuture options which are used for adding potential 103903 new ISA instructions were not documented. They also lacked a bitmask 103904 so new instructions could not be enabled by those options. Fixed. 103905 103906 binutils/ 103907 * doc/binutils.texi: Document -Mfuture. 103908 103909 gas/ 103910 * config/tc-ppc.c: Document -mfuture 103911 * doc/c-ppc.texi: Likewise. 103912 103913 include/ 103914 * opcode/ppc.h (PPC_OPCODE_FUTURE): Define. 103915 103916 opcodes/ 103917 * ppc-dis.c (ppc_opts) <future>: Use it. 103918 * ppc-opc.c (FUTURE): Define. 103919 1039202022-09-12 Bruno Larsen <blarsen@redhat.com> 103921 103922 add xfails to gdb.base/complex-parts.exp when testing with clang 103923 clang doesn't add encoding to the name of complex variables, only says 103924 that the type name is complex, making the relevant tests fail. 103925 This patch adds the xfails to the tests that expect the variable name to 103926 include it. 103927 1039282022-09-12 Bruno Larsen <blarsen@redhat.com> 103929 103930 Fix gdb.base/call-ar-st to work with Clang 103931 When running gdb.base/call-ar-st.exp against Clang, we see one FAIL, 103932 like so: 103933 103934 print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa 103935 ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274 103936 274 print_int_array(array_i); /* -step1- */ 103937 (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays 103938 103939 With GCC we instead see: 103940 103941 print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274 103942 274 print_int_array(array_i); /* -step1- */ 103943 (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays 103944 103945 The difference is that with Clang we get: 103946 103947 array_i=<main.integer_array>, ... 103948 103949 instead of 103950 103951 array_i = <integer_array>, ... 103952 103953 These symbols are local static variables, and "main" is the name of 103954 the function they are defined in. GCC instead appends a sequence 103955 number to the linkage name: 103956 103957 $ nm -A call-ar-st.gcc | grep integer_ 103958 call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968 103959 103960 $ nm -A call-ar-st.clang | grep integer_ 103961 call-ar-st:00000000004061a0 b main.integer_array 103962 103963 This commit changes the testcase to accept both outputs, as they are 103964 functionally identical. 103965 103966 Co-Authored-By: Pedro Alves <pedro@palves.net> 103967 Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4 103968 1039692022-09-12 Bruno Larsen <blarsen@redhat.com> 103970 103971 fix gdb.base/access-mem-running.exp for clang testing 103972 Clang was optimizing global_var away because it was not being used 103973 anywhere. this commit fixes that by adding the attribute used it. 103974 103975 update gdb.base/info-program.exp to not fail with clang 103976 The test specifically mentions that it doesn't care where the program 103977 stops, however it was still testing for a specific location. The clang 103978 compiler emits different line information for epilogue, so GDB reports a 103979 different stopping location, depending on the used compiler. With this 103980 patch the test works even with clang. 103981 1039822022-09-12 Bruno Larsen <blarsen@redhat.com> 103983 103984 gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang 103985 Clang organizes the variables differently to gcc in the original version 103986 of this code, leading to the following differences when testing 103987 p (int*) &dataglobal + 1 103988 103989 gcc: 103990 $16 = (int *) 0x404034 <datalocal> 103991 103992 clang: 103993 $16 = (int *) 0x404034 <dataglobal8> 103994 103995 However, since the important part of this test doesn't seem to be which 103996 symbol is linked, but rather if GDB is correctly increasing the 103997 address. This test was changed to actually measure address changes, 103998 instead of assuming the ordering and naming of symbols. 103999 104000 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 104001 1040022022-09-12 Martin Storsjö <martin@martin.st> 104003 104004 ld: pe: Apply review suggestions on the existing exports/imports arrays 104005 Use a separate explicit max_exports/imports field, instead of 104006 deducing it from the number of allocated elements. Use a named 104007 constant for the incremental growth of the array. 104008 104009 Use bool instead of int for boolean values. 104010 104011 Remove an unnecessary if statement/scope in the def_file_free 104012 function. 104013 104014 Add more verbose comments about parameters, and about insertion 104015 into an array of structs. 104016 104017 Generally use unsigned integers for all array indices and sizes. 104018 The num_exports/imports fields are kept as is as signed integers, 104019 since changing them to unsigned would require a disproportionate 104020 amount of changes ti pe-dll.c to avoid comparisons between signed 104021 and unsigned. 104022 104023 Simply use xrealloc instead of a check and xmalloc/xrealloc; 104024 xrealloc can take NULL as the first parameter (and does a similar 104025 check internally). (This wasn't requested in review though, 104026 but noticed while working on the code.) 104027 1040282022-09-12 Martin Storsjö <martin@martin.st> 104029 104030 ld: pe: Improve performance of object file exclude symbol directives 104031 Store the list of excluded symbols in a sorted list, speeding up 104032 checking for duplicates when inserting new entries. 104033 104034 This is done in the same way as is done for exports and imports 104035 (while the previous implementation was done with a linked list, 104036 based on the implementation for aligncomm). 104037 104038 When linking object files with excluded symbols, there can potentially 104039 be very large numbers of excluded symbols (just like builds with 104040 exports can have a large number of exported symbols). 104041 104042 This improves the link performance somewhat, when linking with large 104043 numbers of excluded symbols. 104044 104045 The later actual use of the excluded symbols within pe-dll.c 104046 handles them via an unordered linked list still, though. 104047 1040482022-09-12 Tom de Vries <tdevries@suse.de> 104049 104050 [gdb] Fix abort in selftest run_on_main_thread with ^C 104051 When running selftest run_on_main_thread and pressing ^C, we can run into: 104052 ... 104053 Running selftest run_on_main_thread. 104054 terminate called without an active exception 104055 104056 Fatal signal: Aborted 104057 ... 104058 104059 The selftest function looks like this: 104060 ... 104061 static void 104062 run_tests () 104063 { 104064 std::thread thread; 104065 104066 done = false; 104067 104068 { 104069 gdb::block_signals blocker; 104070 104071 thread = std::thread (set_done); 104072 } 104073 104074 while (!done && gdb_do_one_event () >= 0) 104075 ; 104076 104077 /* Actually the test will just hang, but we want to test 104078 something. */ 104079 SELF_CHECK (done); 104080 104081 thread.join (); 104082 } 104083 ... 104084 104085 The error message we see is due to the destructor of thread being called while 104086 thread is joinable. 104087 104088 This is supposed to be taken care of by thread.join (), but the ^C prevents 104089 that one from being called, while the destructor is still called. 104090 104091 Fix this by ensuring thread.join () is called (if indeed required) before the 104092 destructor using SCOPE_EXIT. 104093 104094 Tested on x86_64-linux. 104095 104096 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29549 104097 1040982022-09-12 Tom de Vries <tdevries@suse.de> 104099 104100 [gdb/symtab] Support .gdb_index section with TUs in .debug_info 104101 The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support 104102 .debug_names section with TUs in .debug_info"). 104103 104104 Tested on x86_64-linux. 104105 1041062022-09-12 Tom de Vries <tdevries@suse.de> 104107 104108 [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le 104109 In commit cd919f5533c ("[gdb/testsuite] Fix 104110 gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp 104111 independent of prologue analyzers, using this change: 104112 ... 104113 - gdb_breakpoint $func 104114 + gdb_breakpoint *$func 104115 ... 104116 104117 That however caused a regression on ppc64le. For PowerPC, as described in the 104118 ELFv2 ABI, a function can have a global and local entry point. 104119 104120 Setting a breakpoint on *$func effectively creates a breakpoint for the global 104121 entry point, so if the function is entered through the local entry point, the 104122 breakpoint doesn't trigger. 104123 104124 Fix this by reverting commit cd919f5533c, and setting the breakpoint on 104125 ${func}_label instead. 104126 104127 Tested on x86_64-linux and ppc64le-linux. 104128 1041292022-09-12 Tom de Vries <tdevries@suse.de> 104130 104131 [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clang 104132 When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run 104133 into: 104134 ... 104135 (gdb) break *compdir_missing__ldir_missing__file_basename^M 104136 Breakpoint 2 at 0x400580^M 104137 (gdb) continue^M 104138 Continuing.^M 104139 ^M 104140 Breakpoint 2, 0x0000000000400580 in \ 104141 compdir_missing.ldir_missing.file_basename ()^M 104142 (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ 104143 compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ 104144 compdir_missing__ldir_missing__file_basename 104145 ... 104146 104147 The problem is that the test-case uses labels outside functions, which is know 104148 to cause problem with clang, as documented in the comment for proc 104149 function_range. 104150 104151 Fix this by using get_func_info instead. 104152 104153 Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0. 104154 1041552022-09-12 Jan Beulich <jbeulich@suse.com> 104156 104157 x86: avoid i386_dis_printf()'s staging area for a fair part of output 104158 While PR binutils/29483 has now been addressed differently, this 104159 originally proposed change still has its merits: Avoiding vsnprintf() 104160 for typically far more than half of the overall output results in a 2-3% 104161 performance gain in my testing (with debug builds of objdump, libbfd, 104162 and libopcodes). 104163 104164 With that part of output no longer using staging_area[], the array also 104165 doesn't need to be quite as large anymore (the largest presently used 104166 size is 27, from "64-bit address is disabled"). 104167 104168 While limiting the scope of "res" it became apparent that 104169 - no caller cares about the function's return value, 104170 - the comment about the return value was wrong, 104171 - a particular positive return value would have been meaningless to the 104172 caller. 104173 Therefore convert the function to return "void" at the same time. 104174 1041752022-09-12 Nelson Chu <nelson@rivosinc.com> 104176 104177 RISC-V: PR28509, the default visibility symbol cannot be referenced by R_RISCV_JAL. 104178 When generating the shared object, the default visibility symbols may bind 104179 externally, which means they will be exported to the dynamic symbol table, 104180 and are preemptible by default. These symbols cannot be referenced by the 104181 non-pic R_RISCV_JAL and R_RISCV_RVC_JUMP. However, consider that linker 104182 may relax the R_RISCV_CALL relocations to R_RISCV_JAL or R_RISCV_RVC_JUMP, 104183 if these relocations are relocated to the plt entries, then we won't report 104184 error for them. Perhaps we also need the similar checks for the 104185 R_RISCV_BRANCH and R_RISCV_RVC_BRANCH relocations. 104186 104187 After applying this patch, and revert the following glibc patch, 104188 riscv: Fix incorrect jal with HIDDEN_JUMPTARGET 104189 https://sourceware.org/git/?p=glibc.git;a=commit;h=68389203832ab39dd0dbaabbc4059e7fff51c29b 104190 104191 I get the expected errors as follows, 104192 ld: relocation R_RISCV_RVC_JUMP against `__sigsetjmp' which may bind externally can not be used when making a shared object; recompile with -fPIC 104193 ld: relocation R_RISCV_JAL against `exit' which may bind externally can not be used when making a shared object; recompile with -fPIC 104194 104195 Besides, we also have similar changes for libgcc, 104196 RISC-V: jal cannot refer to a default visibility symbol for shared object 104197 https://github.com/gcc-mirror/gcc/commit/45116f342057b7facecd3d05c2091ce3a77eda59 104198 104199 bfd/ 104200 pr 28509 104201 * elfnn-riscv.c (riscv_elf_relocate_section): Report errors when 104202 makeing a shard object, and the referenced symbols of R_RISCV_JAL 104203 relocations are default visibility. Besides, we should handle most 104204 of the cases here, so don't need the unresolvable check later for 104205 R_RISCV_JAL and R_RISCV_RVC_JUMP. 104206 ld/ 104207 pr 28509 104208 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 104209 * testsuite/ld-riscv-elf/lib-nopic-01a.s: Removed. 104210 * testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise. 104211 * testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise. 104212 * testsuite/ld-riscv-elf/shared-lib-nopic-01.d: New testcase. 104213 * testsuite/ld-riscv-elf/shared-lib-nopic-01.s: Likewise. 104214 * testsuite/ld-riscv-elf/shared-lib-nopic-02.d: Likewise. 104215 * testsuite/ld-riscv-elf/shared-lib-nopic-02.s: Likewise. 104216 * testsuite/ld-riscv-elf/shared-lib-nopic-03.d: Likewise. 104217 * testsuite/ld-riscv-elf/shared-lib-nopic-03.s: Likewise. 104218 * testsuite/ld-riscv-elf/shared-lib-nopic-04.d: Likewise. 104219 * testsuite/ld-riscv-elf/shared-lib-nopic-04.s: Likewise. 104220 1042212022-09-12 GDB Administrator <gdbadmin@sourceware.org> 104222 104223 Automatic date update in version.in 104224 1042252022-09-11 Tom de Vries <tdevries@suse.de> 104226 104227 [gdb/symtab] Fix handling of DW_TAG_unspecified_type 104228 Currently, the test-case contained in this patch fails: 104229 ... 104230 (gdb) p (int) foo ()^M 104231 Invalid cast.^M 104232 (gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo () 104233 ... 104234 because DW_TAG_unspecified_type is translated as void. 104235 104236 There's some code in read_unspecified_type that marks the type as stub, but 104237 that's only active for ada: 104238 ... 104239 if (cu->lang () == language_ada) 104240 type->set_is_stub (true); 104241 ... 104242 104243 Fix this by: 104244 - marking the type as a stub for all languages, and 104245 - handling the stub return type case in call_function_by_hand_dummy. 104246 104247 Tested on x86_64-linux. 104248 104249 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29558 104250 1042512022-09-11 GDB Administrator <gdbadmin@sourceware.org> 104252 104253 Automatic date update in version.in 104254 1042552022-09-10 Alan Modra <amodra@gmail.com> 104256 104257 Re: PR29466, APP/NO_APP with linefile 104258 It looks like I copied the SIZE init across from 104259 binutils/testsuite/config/default.exp without some necessary editing. 104260 104261 * testsuite/config/default.exp (SIZE): Adjust relative path. 104262 1042632022-09-10 GDB Administrator <gdbadmin@sourceware.org> 104264 104265 Automatic date update in version.in 104266 1042672022-09-09 Nick Clifton <nickc@redhat.com> 104268 104269 Support debuginfo files with empty group sections. 104270 PR 29532 104271 bfd * elf.c (setup_group): Do not return false if there is no group 104272 information available. 104273 104274 bionutils* objcopy.c (setup_section): Leave group sections intact when 104275 creating separate debuginfo files. 104276 1042772022-09-09 Tsukasa OI <research_trasio@irq.a4lg.com> 104278 104279 RISC-V: Fix vector CSR requirements 104280 Vector CSRs are also required on smaller vector subsets. 104281 104282 Not only that the most of vector CSRs are general purpose (and must be 104283 accessible for every vector subsets), current minimum vector subset 'Zve32x' 104284 requires fixed point arithmetic, making remaining non-general purpose 104285 (fixed point arithmetic only) CSRs mandatory for such subsets. 104286 104287 So, those CSRs must be accessible from 'Zve32x', not just from 'V'. 104288 This commit fixes this issue which caused CSR accessibility warnings. 104289 104290 gas/ChangeLog: 104291 104292 * config/tc-riscv.c (riscv_csr_address): Change vector CSR 104293 requirement from 'V' to 'Zve32x'. 104294 * testsuite/gas/riscv/csr-version-1p9p1.l: Change vector CSR 104295 requirement from 'V' to 'Zve32x'. 104296 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 104297 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 104298 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 104299 1043002022-09-09 GDB Administrator <gdbadmin@sourceware.org> 104301 104302 Automatic date update in version.in 104303 1043042022-09-08 Carl Love <cel@us.ibm.com> 104305 104306 Fix hardware watchpoint check in test gdb.base/watchpoint-reuse-slot.exp 104307 This test generates 48 failures on Power 9 when testing with HW watchpoints 104308 enabled. Note HW watchpoint support is disabled on Power 9 due to a HW bug. 104309 The skip_hw_watchpoint_tests proc must be used to correctly determine 104310 if the processor supports HW watchpoints. 104311 104312 This patch replaces the [target_info exists gdb,no_hardware_watchpoints] 104313 with the skip_hw_watchpoint_tests check. 104314 104315 This patch was tested on Power 9, Power 10 and X86-64 with no regressions. 104316 1043172022-09-08 Nick Clifton <nickc@redhat.com> 104318 104319 Gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE) 104320 PR 29559 104321 * dwarf2dbg.c (out_debug_info): Place DW_TAG_unspecified_type at 104322 the end of the list of children, not at the start of the CU 104323 information. 104324 * testsuite/gas/elf/dwarf-3-func.d: Update expected output. 104325 * testsuite/gas/elf/dwarf-5-func-global.d: Likewise. 104326 * testsuite/gas/elf/dwarf-5-func-local.d: Likewise. 104327 * testsuite/gas/elf/dwarf-5-func.d: Likewise. 104328 1043292022-09-08 Tsukasa OI <research_trasio@irq.a4lg.com> 104330 104331 gdbsupport: Fix config.status dependency 104332 Commit 171fba11ab27 ("Make GDBserver abort on internal error in development mode") 104333 created a new substitution CONFIG_STATUS_DEPENDENCIES but this is used by 104334 Makefile.in (which is not regenerated by that commit). After regenerating 104335 it, it is found that CONFIG_STATUS_DEPENDENCIES value is not valid, making 104336 gdbsupport fail to build. 104337 104338 Since the CONFIG_STATUS_DEPENDENCIES value is used in the Makefile, macro 104339 substitution must have a Makefile format but commit 171fba11ab27 used shell 104340 format "$srcdir/../bfd/development.sh". 104341 104342 This commit fixes this issue by substituting "$srcdir" (shell format) to 104343 "$(srcdir)" (Makefile format). It preserves the dependency as Pedro 104344 intended and fixes the build problem. 104345 104346 It also regenerates corresponding files with the maintainer mode. 104347 104348 gdbsupport/ChangeLog: 104349 104350 * configure.ac: Fix config.status dependency. 104351 * Makefile.in: Regenerate. 104352 * configure: Regenerate. 104353 1043542022-09-08 Nick Clifton <nickc@redhat.com> 104355 104356 Maintainer mode: wrong gettext version? 104357 * README-maintainer-mode: Update minimum version of gettext 104358 required. 104359 104360 i686-w64-mingw32-objdump -WL returns incorrect file paths 104361 PR 29523 104362 * dwarf.c (display_debug_lines_decoded): Correctly handle DWARF-5 104363 directory and filename tables. 104364 1043652022-09-08 GDB Administrator <gdbadmin@sourceware.org> 104366 104367 Automatic date update in version.in 104368 1043692022-09-07 Tom de Vries <tdevries@suse.de> 104370 104371 [gdb/testsuite] xfail gdb.ada/O2_float_param.exp for aarch64 and gcc 7.5.0 104372 On aarch64-linux, with gcc 7.5.0, we run into: 104373 ... 104374 (gdb) frame^M 104375 #0 callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...) at \ 104376 callee.adb:21^M 104377 21 if Val > 200.0 then^M 104378 (gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: frame 104379 ... 104380 104381 The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location 104382 expression for function entry values" ( 104383 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148 ). 104384 104385 Xfail the test for aarch64 and gcc 7. 104386 104387 Tested on x86_64-linux and aarch64-linux. 104388 104389 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29418 104390 1043912022-09-07 Tom de Vries <tdevries@suse.de> 104392 104393 [gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64 104394 On aarch64-linux, I run into: 104395 ... 104396 Breakpoint 2, pck.inspect (obj=0x430eb0 \ 104397 <system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M 104398 17 procedure Inspect (Obj: access Top_T'Class) is^M 104399 (gdb) FAIL: gdb.ada/access_tagged_param.exp: continue 104400 ... 104401 while on x86_64-linux, I see: 104402 ... 104403 Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M 104404 19 null;^M 104405 (gdb) PASS: gdb.ada/access_tagged_param.exp: continue 104406 ... 104407 Note the different line numbers, 17 vs 19. 104408 104409 The difference comes from the gdbarch_skip_prologue implementation. 104410 104411 The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls 104412 back to the architecture-specific prologue analyzer, which correctly skips 104413 past the prologue, to address 0x4022f7: 104414 ... 104415 00000000004022ec <pck__inspect>: 104416 4022ec: 55 push %rbp 104417 4022ed: 48 89 e5 mov %rsp,%rbp 104418 4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp) 104419 4022f4: 89 75 f4 mov %esi,-0xc(%rbp) 104420 4022f7: 90 nop 104421 4022f8: 90 nop 104422 4022f9: 5d pop %rbp 104423 4022fa: c3 ret 104424 ... 104425 104426 The aarch64_skip_prologue implementation does use gcc line numbers, which are: 104427 ... 104428 File name Line number Starting address View Stmt 104429 pck.adb 17 0x402580 x 104430 pck.adb 17 0x402580 1 x 104431 pck.adb 19 0x40258c x 104432 pck.adb 20 0x402590 x 104433 ... 104434 and which are represented like this internally in gdb: 104435 ... 104436 INDEX LINE ADDRESS IS-STMT PROLOGUE-END 104437 0 17 0x0000000000402580 Y 104438 1 17 0x0000000000402580 Y 104439 2 19 0x000000000040258c Y 104440 3 20 0x0000000000402590 Y 104441 4 END 0x00000000004025a0 Y 104442 ... 104443 104444 The second entry is interpreted as end-of-prologue, so 0x402580 is used, while 104445 the actual end of the prologue is at 0x40258c: 104446 ... 104447 0000000000402580 <pck__inspect>: 104448 402580: d10043ff sub sp, sp, #0x10 104449 402584: f90007e0 str x0, [sp, #8] 104450 402588: b90007e1 str w1, [sp, #4] 104451 40258c: d503201f nop 104452 402590: d503201f nop 104453 402594: 910043ff add sp, sp, #0x10 104454 402598: d65f03c0 ret 104455 40259c: d503201f nop 104456 ... 104457 104458 Note that the architecture-specific prologue analyzer would have gotten this 104459 right: 104460 ... 104461 (gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0) 104462 $2 = 0x40258c 104463 ... 104464 104465 Fix the FAIL by making the test-case more robust against problems in prologue 104466 skipping, by setting the breakpoint on line 19 instead. 104467 104468 Likewise in a few similar test-cases. 104469 104470 Tested on x86_64-linux and aarch64-linux. 104471 1044722022-09-07 Luis Machado <luis.machado@arm.com> 104473 Tom de Vries <tdevries@suse.de> 104474 104475 Fix endianness handling for arm record self tests 104476 v2: 104477 104478 - Add 32-bit Arm instruction selftest 104479 - Refactored abstract memory reader into abstract instruction reader 104480 - Adjusted code to use templated type and to use host endianness as 104481 opposed to target endianness. 104482 104483 The arm record tests handle 16-bit and 32-bit thumb instructions, but the 104484 code is laid out in a way that handles the 32-bit thumb instructions as 104485 two 16-bit parts. 104486 104487 This is fine, but it is prone to host-endianness issues given how the two 104488 16-bit parts are stored and how they are accessed later on. Arm is 104489 little-endian by default, so running this test with a GDB built with 104490 --enable-targets=all and on a big endian host will run into the following: 104491 104492 Running selftest arm-record. 104493 Process record and replay target doesn't support syscall number -2036195 104494 Process record does not support instruction 0x7f70ee1d at address 0x0. 104495 Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-tdep.c:14482 104496 104497 It turns out the abstract memory reader class is more generic than it needs to 104498 be, and we can simplify the code a bit by assuming we have a simple instruction 104499 reader that only reads up to 4 bytes, which is the length of a 32-bit 104500 instruction. 104501 104502 Instead of returning a bool, we return instead the instruction that has been 104503 read. This way we avoid having to deal with the endianness conversion, and use 104504 the host endianness instead. The Arm selftests can be executed on non-Arm 104505 hosts. 104506 104507 While at it, Tom suggested adding a 32-bit Arm instruction selftest to increase 104508 the coverage of the selftests. 104509 104510 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29432 104511 1045122022-09-07 Tom de Vries <tdevries@suse.de> 104513 104514 [gdb/testsuite] Use prototype to call libc functions 104515 On openSUSE Tumbleweed (using glibc 2.36), I run into: 104516 ... 104517 (gdb) print /d (int) munmap (4198400, 4096)^M 104518 Invalid cast.^M 104519 (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \ 104520 get integer valueof "(int) munmap (4198400, 4096)" 104521 ... 104522 104523 The problem is that after starting the executable, the symbol has type 104524 "void (*) (void)": 104525 ... 104526 (gdb) p munmap 104527 $1 = {<text variable, no debug info>} 0x401030 <munmap@plt> 104528 (gdb) start 104529 ... 104530 (gdb) p munmap 104531 $2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap> 104532 ... 104533 which causes the "Invalid cast" error. 104534 104535 Looking at the debug info for glibc for symbol __GI_munmap: 104536 ... 104537 <0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit) 104538 <189691> DW_AT_name : ../sysdeps/unix/syscall-template.S 104539 <189699> DW_AT_producer : GNU AS 2.39.0 104540 <1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram) 104541 <1896af> DW_AT_name : __GI___munmap 104542 <1896b3> DW_AT_external : 1 104543 <1896b4> DW_AT_low_pc : 0x10cad0 104544 <1896bc> DW_AT_high_pc : 37 104545 ... 104546 that's probably caused by this bit (or similar bits for other munmap aliases). 104547 104548 This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type 104549 tag to DWARF DIEs generated for function symbols"). 104550 104551 Work around this (for say gas 2.39) by explicitly specifying the prototype for 104552 munmap. 104553 104554 Likewise for getpid in a couple of other test-cases. 104555 104556 Tested on x86_64-linux. 104557 1045582022-09-07 mengqinggang <mengqinggang@loongson.cn> 104559 104560 LoongArch: fix gas BFD_RELOC_8/16/24 bug 104561 If fixP->fx_subsy is NULL, BFD_RELOC_8/16/24 can't convert to 104562 BFD_RELOC_LARCH_xxx. 104563 104564 gas/config/tc-loongarch.c 104565 1045662022-09-07 GDB Administrator <gdbadmin@sourceware.org> 104567 104568 Automatic date update in version.in 104569 1045702022-09-06 Aaron Merey <amerey@redhat.com> 104571 Nick Clifton <nickc@redhat.com> 104572 104573 Add debuginfod support for objdump -S 104574 Currently objdump -S is not able to make use files downloaded from debuginfod. 104575 This is due to bfd_find_nearest_line_discriminator being unable to locate any 104576 separate debuginfo files in the debuginfod cache. Additionally objdump lacked 104577 a call to debuginfod_find_source in order to download missing source files. 104578 104579 Fix this by using bfd_find_nearest_line_with_alt instead of 104580 bfd_find_nearest_line_discriminator. Also add a call to 104581 debuginfod_find_source in order to download missing source files. 104582 1045832022-09-06 Aaron Merey <amerey@redhat.com> 104584 104585 bfd: Add bfd_find_nearest_line_with_alt 104586 bfd_find_nearest_line_with_alt functions like bfd_find_nearest_line with 104587 the addition of a parameter for specifying the filename of a supplementary 104588 debug file such as one referenced by .gnu_debugaltlink or .debug_sup. 104589 104590 This patch focuses on implementing bfd_find_nearest_line_with_alt 104591 support for ELF/DWARF2 .gnu_debugaltlink. For other targets this 104592 function simply sets the invalid_operation bfd_error. 104593 1045942022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com> 104595 104596 gdb: add Tsukasa Oi to gdb/MAINTAINERS 104597 1045982022-09-06 Andrew Burgess <aburgess@redhat.com> 104599 104600 gdb: move a write after approval entry into the correct place 104601 Noticed in passing that an entry in the MAINTAINERS write after 104602 approval list was in the wrong place. 104603 1046042022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com> 104605 104606 gdb: Add non-enum disassembler options 104607 This is paired with "opcodes: Add non-enum disassembler options". 104608 104609 There is a portable mechanism for disassembler options and used on some 104610 architectures: 104611 104612 - ARC 104613 - Arm 104614 - MIPS 104615 - PowerPC 104616 - RISC-V 104617 - S/390 104618 104619 However, it only supports following forms: 104620 104621 - [NAME] 104622 - [NAME]=[ENUM_VALUE] 104623 104624 Valid values for [ENUM_VALUE] must be predefined in 104625 disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC 104626 architecture, opcodes/arc-dis.c builds valid CPU model list from 104627 include/elf/arc-cpu.def. 104628 104629 In this commit, it adds following format: 104630 104631 - [NAME]=[ARBITRARY_VALUE] (cannot contain "," though) 104632 104633 This is identified by NULL value of disasm_option_arg_t.values 104634 (normally, this is a non-NULL pointer to a NULL-terminated list). 104635 104636 gdb/ChangeLog: 104637 104638 * gdb/disasm.c (set_disassembler_options): Add support for 104639 non-enum disassembler options. 104640 (show_disassembler_options_sfunc): Likewise. 104641 1046422022-09-06 Tom de Vries <tdevries@suse.de> 104643 104644 [gdb/symtab] Support .debug_names section with TUs in .debug_info 104645 When running test-case gdb.cp/cpexprs-debug-types.exp on target board 104646 cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with 104647 a .debug_names section, but no .debug_types section. For dwarf-5, the TUs 104648 are no longer put in a separate unit, but instead they're put in the 104649 .debug_info section. 104650 104651 When loading the executable, the .debug_names section is silently ignored 104652 because of this check in dwarf2_read_debug_names: 104653 ... 104654 if (map->tu_count != 0) 104655 { 104656 /* We can only handle a single .debug_types when we have an 104657 index. */ 104658 if (per_bfd->types.size () != 1) 104659 return false; 104660 ... 104661 which triggers because per_bfd->types.size () == 0. 104662 104663 The intention of the check is to make sure we don't have more that one 104664 .debug_types section, as can happen in a object file (see PR12984): 104665 ... 104666 $ grep "\.debug_types" 11.s 104667 .section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat 104668 .section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat 104669 ... 104670 104671 Fix this by: 104672 - changing the check condition to "per_bfd->types.size () > 1", and 104673 - handling per_bfd->types.size () == 0. 104674 104675 Tested on x86_64-linux. 104676 104677 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385 104678 1046792022-09-06 Tom de Vries <tdevries@suse.de> 104680 104681 [gdb/testsuite] Add gdb.dwarf2/debug-names-bad-cu-index.exp 104682 Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for 104683 commit 2fe9a3c41fa ("[gdb/symtab] Fix bad compile unit index complaint"). 104684 104685 Tested on x86_64-linux. 104686 1046872022-09-06 Tom de Vries <tdevries@suse.de> 104688 104689 [gdb/testsuite] Add gdb.dwarf2/debug-names-tu.exp 104690 Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler 104691 to specify a .debug_names index with the TU list referring to a TU from the 104692 .debug_types section. 104693 104694 This is intended to produce something similar to: 104695 ... 104696 $ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4 104697 $ gdb-add-index -dwarf-5 a.out 104698 ... 104699 104700 Tested on x86_64-linux. 104701 1047022022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com> 104703 104704 opcodes: Add non-enum disassembler options 104705 This is paired with "gdb: Add non-enum disassembler options". 104706 104707 There is a portable mechanism for disassembler options and used on some 104708 architectures: 104709 104710 - ARC 104711 - Arm 104712 - MIPS 104713 - PowerPC 104714 - RISC-V 104715 - S/390 104716 104717 However, it only supports following forms: 104718 104719 - [NAME] 104720 - [NAME]=[ENUM_VALUE] 104721 104722 Valid values for [ENUM_VALUE] must be predefined in 104723 disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC 104724 architecture, opcodes/arc-dis.c builds valid CPU model list from 104725 include/elf/arc-cpu.def. 104726 104727 In this commit, it adds following format: 104728 104729 - [NAME]=[ARBITRARY_VALUE] (cannot contain "," though) 104730 104731 This is identified by NULL value of disasm_option_arg_t.values 104732 (normally, this is a non-NULL pointer to a NULL-terminated list). 104733 104734 include/ChangeLog: 104735 104736 * dis-asm.h (disasm_option_arg_t): Update comment of values 104737 to allow non-enum disassembler options. 104738 104739 opcodes/ChangeLog: 104740 104741 * riscv-dis.c (print_riscv_disassembler_options): Support 104742 non-enum disassembler options on printing disassembler help. 104743 * arc-dis.c (print_arc_disassembler_options): Likewise. 104744 * mips-dis.c (print_mips_disassembler_options): Likewise. 104745 1047462022-09-06 GDB Administrator <gdbadmin@sourceware.org> 104747 104748 Automatic date update in version.in 104749 1047502022-09-05 Tsukasa OI <research_trasio@irq.a4lg.com> 104751 104752 sim/riscv: Complete tidying up with SBREAK 104753 This commit removes SBREAK-related references on the simulator as it's 104754 renamed to EBREAK in 2016 (the RISC-V ISA, version 2.1). 104755 104756 sim/ChangeLog: 104757 104758 * riscv/sim-main.c (execute_i): Use "ebreak" instead of "sbreak". 104759 1047602022-09-05 GDB Administrator <gdbadmin@sourceware.org> 104761 104762 Automatic date update in version.in 104763 1047642022-09-04 Andrew Burgess <aburgess@redhat.com> 104765 104766 sim/erc32: fix gdb with simulator build 104767 In commit: 104768 104769 commit 7b01c1cc1d111ba0afa51e60fa9842d3b971e2d1 104770 Date: Mon Apr 4 22:38:04 2022 +0100 104771 104772 sim: fixes for libopcodes styled disassembler 104773 104774 changes were made to the simulator source to handle the new libopcodes 104775 disassembler styling API. 104776 104777 Unfortunately, these changes broke building GDB with the erc32 (sparc) 104778 simulator, like this: 104779 104780 ../src/configure --target=sparc-linux 104781 make all-gdb 104782 .... 104783 /usr/bin/ld: ../sim/erc32/libsim.a(interf.o): in function `sim_open': 104784 /tmp/build/sim/../../src/sim/erc32/interf.c:247: undefined reference to `fprintf_styled' 104785 collect2: error: ld returned 1 exit status 104786 104787 The problem is that in commit 7b01c1cc1d11 the fprintf_styled function 104788 was added into sis.c. This file is only used when building the 'run' 104789 binary, that is, the standalone simulator, and is not included in the 104790 libsim.a library. 104791 104792 Now, the obvious fix would be to move fprintf_styled into libsim.a, 104793 however, that turns out to be tricky. 104794 104795 The erc32 simulator currently has two copies of the function run_sim, 104796 one in sis.c, and one in interf.c, both of these copies are global. 104797 104798 Currently, the 'run' binary links fine, though I suspect this might be 104799 pure luck. When I tried moving fprintf_styled into interf.c, I ran 104800 into multiple-definition (of run_sim) errors. I suspect that by 104801 requiring the linker to pull in fprintf_styled from libsim.a I was 104802 changing the order in which symbols were loaded, and the linker was 104803 now seeing both copies of run_sim, while currently we only see one 104804 copy. 104805 104806 The ideal solution of course, would be to merge the two similar, but 104807 slightly different copies of run_sim, and just use the one copy. Then 104808 we could safely move fprintf_styled into interf.c too, and all would 104809 be good. 104810 104811 But I don't have time right now to start debugging the erc32 104812 simulator, so I wanted a solution that fixes the build without 104813 introducing multiple definition errors. 104814 104815 The easiest solution I think is to just have two copies of 104816 fprintf_styled, one in sis.c, and one in interf.c. Unlike run_sim, 104817 these two copies are both static, so we will not run into multiple 104818 definition issues with this function. The functions themselves are 104819 not very big, so it's not a huge amount of duplicate code. 104820 104821 I am very aware that this is not an ideal solution, and I would 104822 welcome anyone who wants to take on fixing the run_sim problem 104823 properly, and then cleanup the fprintf_styled duplication. 104824 1048252022-09-04 GDB Administrator <gdbadmin@sourceware.org> 104826 104827 Automatic date update in version.in 104828 1048292022-09-03 GDB Administrator <gdbadmin@sourceware.org> 104830 104831 Automatic date update in version.in 104832 1048332022-09-02 Max Filippov <jcmvbkbc@gmail.com> 104834 104835 xtensa: bfd: fix TLS relocations generated for PIE 104836 When generating TLS dynamic relocations the existing xtensa BFD code 104837 treats linking to a PIE exactly as linking to a shared object, resulting 104838 in generation of wrong relocations for TLS entries. Fix that and add 104839 tests. 104840 104841 bfd/ 104842 * elf32-xtensa.c (elf_xtensa_check_relocs): Use bfd_link_dll 104843 instead of bfd_link_pic. Add elf_xtensa_dynamic_symbol_p test 104844 when generating GOT entries. 104845 (elf_xtensa_relocate_section): Use bfd_link_dll instead of 104846 bfd_link_pic. 104847 ld/ 104848 * testsuite/ld-xtensa/tlspie.dd: New file. 104849 * testsuite/ld-xtensa/tlspie.rd: New file. 104850 * testsuite/ld-xtensa/tlspie.sd: New file. 104851 * testsuite/ld-xtensa/tlspie.td: New file. 104852 * testsuite/ld-xtensa/xtensa-linux.exp (TLS PIE transitions): 104853 New test. 104854 1048552022-09-02 Max Filippov <jcmvbkbc@gmail.com> 104856 104857 xtensa: adjust expected output in ld TLS tests 104858 objdump output for l32r opcode was changed in commit b3ea76397a07 104859 ("opcodes: xtensa: display loaded literal value"), but xtensa linker TLS 104860 relaxation tests weren't adjusted accordingly. 104861 readelf output was changed in commit 23356397449a ("Adjust readelf's 104862 output so that section symbols without a name as shown with their 104863 section name."), but xtensa linker TLS relaxation tests weren't adjusted 104864 accordingly. 104865 Fix expected output changes in xtensa ld TLS relaxation tests. 104866 104867 ld/ 104868 * testsuite/ld-xtensa/tlsbin.dd: Adjust expected output for l32r 104869 opcodes. 104870 * testsuite/ld-xtensa/tlsbin.rd: Adjust expected output to allow 104871 for named section symbols. 104872 * testsuite/ld-xtensa/tlspic.dd: Adjust expected output for l32r 104873 opcodes. 104874 * testsuite/ld-xtensa/tlspic.rd: Adjust expected output to allow 104875 for named section symbols. 104876 1048772022-09-02 Frederic Cambus <fred@statdns.com> 104878 104879 Add OpenBSD ARM Little Endian BFD support. 104880 * config.bfd (arm-*-openbsd*): Restore target. 104881 1048822022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com> 104883 104884 RISC-V: Print highest address (-1) on the disassembler 104885 This patch makes possible to print the highest address (-1) and the addresses 104886 related to gp which value is -1. This is particularly useful if the highest 104887 address space is used for I/O registers and corresponding symbols are defined. 104888 Besides, despite that it is very rare to have GP the highest address, it would 104889 be nice because we enabled highest address printing on regular cases. 104890 104891 gas/ChangeLog: 104892 104893 * testsuite/gas/riscv/dis-addr-topaddr.s: New test for the top 104894 address (-1) printing. 104895 * testsuite/gas/riscv/dis-addr-topaddr-32.d: Likewise. 104896 * testsuite/gas/riscv/dis-addr-topaddr-64.d: Likewise. 104897 * testsuite/gas/riscv/dis-addr-topaddr-gp.s: New test for 104898 GP-relative addressing when GP is the highest address (-1). 104899 * testsuite/gas/riscv/dis-addr-topaddr-gp-32.d: Likewise. 104900 * testsuite/gas/riscv/dis-addr-topaddr-gp-64.d: Likewise. 104901 104902 opcodes/ChangeLog: 104903 104904 * riscv-dis.c (struct riscv_private_data): Add `to_print_addr' to 104905 enable printing the highest address. 104906 (maybe_print_address): Utilize `to_print_addr'. 104907 (riscv_disassemble_insn): Likewise. 104908 1049092022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com> 104910 104911 RISC-V: PR29342, Fix RV32 disassembler address computation 104912 If either the base register is `zero', `tp' or `gp' and XLEN is 32, an 104913 incorrectly sign-extended address is produced when printing. This commit 104914 fixes this by fitting an address into a 32-bit value on RV32. 104915 104916 Besides, H. Peter Anvin discovered that we have wrong address computation 104917 for JALR instruction (the initial bug is back in 2018). This commit also 104918 fixes that based on the idea of Palmer Dabbelt. 104919 104920 gas/ 104921 pr29342 104922 * testsuite/gas/riscv/lla32.d: Reflect RV32 address computation fix. 104923 * testsuite/gas/riscv/dis-addr-overflow.s: New testcase. 104924 * testsuite/gas/riscv/dis-addr-overflow-32.d: Likewise. 104925 * testsuite/gas/riscv/dis-addr-overflow-64.d: Likewise. 104926 opcodes/ 104927 pr29342 104928 * riscv-dis.c (maybe_print_address): Fit address into 32-bit on RV32. 104929 (print_insn_args): Fix JALR address by adding EXTRACT_ITYPE_IMM. 104930 1049312022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com> 104932 104933 RISC-V: Add address printer tests with ADDIW 104934 Address sequences involving ADDIW/C.ADDIW instructions require special 104935 handling to sign-extend lower 32-bits of the original result. 104936 104937 This commit tests whether this sign-extension works. 104938 104939 gas/ChangeLog: 104940 104941 * testsuite/gas/riscv/dis-addr-addiw.s: New to test the address 104942 computation with sign extension as used in ADDIW/C.ADDIW. 104943 * testsuite/gas/riscv/dis-addr-addiw-a.d: Test PC sign bit 0. 104944 * testsuite/gas/riscv/dis-addr-addiw-b.d: Test PC sign bit 1. 104945 104946 gas/ChangeLog: 104947 104948 * testsuite/gas/riscv/dis-addr-addiw-a.d: New test. 104949 * testsuite/gas/riscv/dis-addr-addiw-b.d: New test. 104950 * testsuite/gas/riscv/dis-addr-addiw.s: New test. 104951 1049522022-09-02 GDB Administrator <gdbadmin@sourceware.org> 104953 104954 Automatic date update in version.in 104955 1049562022-09-01 Tsukasa OI <research_trasio@irq.a4lg.com> 104957 104958 sim: Update mailing list address 104959 The commit bf1102165389 "* MAINTAINERS: Perform some obvious fixups." 104960 back in 2009 changed the mailing list address gdb-patches@sources.redhat.com 104961 to gdb-patches@sourceware.org. 104962 104963 This commit does the same to sim/MAINTAINERS. 104964 104965 sim/ChangeLog: 104966 104967 * MAINTAINERS: Update mailing list address. 104968 104969 Change-Id: I56c6bf21a4bddfb35ffc3336ffcba7ff9b39926e 104970 1049712022-09-01 Nick Clifton <nickc@redhat.com> 104972 104973 dllwrap, windres and dlltools use mktemp, which should be avoided 104974 PR 29534 104975 * dllwrap.c: Replace uses of choose_temp_base() with 104976 make_temp_file(). 104977 * dlltool.c: Likewise. 104978 * resrc.c: Likewise. 104979 1049802022-09-01 Maciej W. Rozycki <macro@embecosm.com> 104981 104982 GDB/doc: Document the Guile `#:unlimited' keyword 104983 Document the Guile `#:unlimited' keyword and deprecate the internal 104984 integer representation it corresponds to for integer parameters. 104985 1049862022-09-01 Lancelot SIX <lancelot.six@amd.com> 104987 104988 gdb/python-config: replace deprecated distutils.sysconfig 104989 When running the gdb/configure script on ubuntu 22.04 with 104990 python-3.10.4, I see: 104991 104992 checking for python... no 104993 checking for python3... /usr/bin/python3 104994 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives 104995 from distutils import sysconfig 104996 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead 104997 from distutils import sysconfig 104998 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives 104999 from distutils import sysconfig 105000 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead 105001 from distutils import sysconfig 105002 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives 105003 from distutils import sysconfig 105004 [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead 105005 from distutils import sysconfig 105006 checking for python... yes 105007 105008 The distutils module is deprecated as per the PEP 632[1] and will be 105009 removed in python-3.12. 105010 105011 This patch migrates gdb/python/python-config.py from distutils.sysconfig 105012 to the sysconfig module[2]. 105013 105014 The sysconfig module has has been introduced in the standard library in 105015 python 3.2. Given that support for python < 3.2 has been removed by 105016 edae3fd6600f: "gdb/python: remove Python 2 support", this patch does not 105017 need to support both implementations for backward compatibility. 105018 105019 Tested on ubuntu-22.04 and ubuntu 20.04. 105020 105021 [1] https://peps.python.org/pep-0632/ 105022 [2] https://docs.python.org/3/library/sysconfig.html 105023 105024 Change-Id: Id0df2baf3ee6ce68bd01c236b829ab4c0a4526f6 105025 1050262022-09-01 GDB Administrator <gdbadmin@sourceware.org> 105027 105028 Automatic date update in version.in 105029 1050302022-08-31 Tom Tromey <tromey@adacore.com> 105031 105032 Fix interpreter-exec crash 105033 PR mi/10347 points out that using interpreter-exec inside of a 105034 "define" command will crash gdb. The bug here is that 105035 gdb_setup_readline doesn't check for the case where instream==nullptr. 105036 105037 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10347 105038 1050392022-08-31 Tom Tromey <tromey@adacore.com> 105040 105041 Fix "source" with interpreter-exec 105042 PR mi/15811 points out that "source"ing a file that uses 105043 interpreter-exec will put gdb in a weird state, where the CLI stops 105044 working. The bug is that tui_interp::suspend does not unregister the 105045 event file descriptor. 105046 105047 The test case is from Andrew Burgess. 105048 105049 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15811 105050 1050512022-08-31 Tom Tromey <tromey@adacore.com> 105052 105053 Remove a call to clear_interpreter_hooks 105054 mi_interp::resume does not need to call clear_interpreter_hooks, 105055 because this is already done by interp_set. 105056 105057 TUI stdout buffering cleanup 105058 The TUI checks against gdb_stdout to decide when to buffer. It seems 105059 much cleaner to me to simply record this as an attribute of the stream 105060 itself. 105061 105062 Remove a ui-related memory leak 105063 gdb_setup_readline makes new streams and assigns to the various stream 105064 members of struct ui. However, these assignments cause the previous 105065 values to leak. As far as I can, this code is simply unnecessary and 105066 can be removed -- with the exception of the assignment to gdb_stdtarg, 105067 which is not initialized anywhere else. 105068 105069 Remove tui_out_new 105070 tui_out_new is just a simple wrapper for 'new' and can be removed, 105071 simplifying gdb a tiny bit. 105072 105073 Use scoped_restore in safe_parse_type 105074 This changes safe_parse_type to use scoped_restore rather than 105075 explicit assignments. 105076 105077 Use member initialization in 'struct ui' 105078 This changes 'struct ui' to use member initialization. This is 105079 simpler to understand. 105080 105081 Remove two unused members from mi_interp 105082 These members of mi_interp aren't used and can be removed. 105083 105084 Remove obsolete filtering comment 105085 top.h has an obsolete comment about the use of _unfiltered. 105086 105087 Remove the "for moment" comments 105088 A few spots setting some gdb output stream variables have a "for 105089 moment" comment. These comments aren't useful and I think the moment 105090 has passed -- these are permanent now. 105091 105092 Use ui_out_redirect_pop in more places 105093 This changes ui_out_redirect_pop to also perform the redirection, and 105094 then updates several sites to use this, rather than explicit 105095 redirects. 105096 105097 Free ui::line_buffer 105098 A ui initializes its line_buffer, but never calls buffer_free on it. 105099 This patch fixes the oversight. I found this by inspection. 105100 105101 Remove some dead code 105102 This patch removes some dead code and an old FIXME. These no longer 105103 seem useful, even for documentation purposes. 105104 105105 Let ui::input_fd be -1 105106 This changes gdb so that, if ui::input_fd is set to -1, then it will 105107 not be registered with the event loop. This is useful for the DAP 105108 support code I wrote, but as it turns out to also be useful to 105109 Insight, it seems best to check it in separately. 105110 1051112022-08-31 Andrew Burgess <aburgess@redhat.com> 105112 105113 gdb/riscv: better support for fflags and frm registers 105114 First, some background on the RISC-V registers fflags, frm, and fcsr. 105115 105116 These three registers all relate to the floating-point status and 105117 control mechanism on RISC-V. The fcsr is the floatint-point control 105118 status register, and consists of two parts, the flags (bits 0 to 4) 105119 and the rounding-mode (bits 5 to 7). 105120 105121 The fcsr register is just one of many control/status registers (or 105122 CSRs) available on RISC-V. The fflags and frm registers are also 105123 CSRs. These CSRs are aliases for the relevant parts of the fcsr 105124 register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is 105125 an alias for bits 5 to 7 of fcsr. 105126 105127 This means that a user can change the floating-point rounding mode 105128 either, by writing a complete new value into fcsr, or by writing just 105129 the rounding mode into frm. 105130 105131 How this impacts on GDB is like this: a target description could, 105132 legitimately include all three registers, fcsr, fflags, and frm. The 105133 QEMU target currently does this, and this makes sense. The target is 105134 emulating the complete system, and has all three CSRs available, so 105135 why not tell GDB about this. 105136 105137 In contrast, the RISC-V native Linux target only has access to the 105138 fcsr. This is because the ptrace data structure that the kernel uses 105139 for reading and writing floating point state only contains a copy of 105140 the fcsr, after all, this one field really contains both the fflags 105141 and frm fields, so why carry around duplicate data. 105142 105143 So, we might expect that the target description for the RISC-V native 105144 Linux GDB would only contain the fcsr register. Unfortunately, this 105145 is not the case. The RISC-V native Linux target uses GDB's builtin 105146 target descriptions by calling riscv_lookup_target_description, this 105147 will then add an fpu feature from gdb/features/riscv, either 105148 32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features 105149 include an entry for fcsr, fflags, and frm. This means that GDB 105150 expects the target to handle reading and writing these registers. And 105151 the RISC-V native Linux target currently doesn't. 105152 105153 In riscv_linux_nat_target::store_registers and 105154 riscv_linux_nat_target::fetch_registers only the fcsr register is 105155 handled, this means that, for RISC-V native Linux, the fflags and frm 105156 registers always show up as <unavailable> - they are present in the 105157 target description, but the target doesn't know how to access the 105158 registers. 105159 105160 A final complication relating to these floating pointer CSRs is which 105161 target description feature the registers appear in. 105162 105163 These registers are CSRs, so it would seem sensible that these 105164 registers should appear in the CSR target description feature. 105165 105166 However, when I first added RISC-V target description support, I was 105167 using a RISC-V simulator that didn't support any CSRs other than the 105168 floating point related ones. This simulator bundled all the float 105169 related CSRs into the fpu target feature. This didn't feel completely 105170 unreasonable to me, and so I had GDB check for these registers in 105171 either target feature. 105172 105173 In this commit I make some changes relating to how GDB handles the 105174 three floating point CSR: 105175 105176 1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This 105177 means that the default RISC-V target description (which RISC-V native 105178 FreeBSD), and the target descriptions created for RISC-V native Linux, 105179 will not include these registers. There's nothing stopping some other 105180 target (e.g. QEMU) from continuing to include all three of these CSRs, 105181 the code in riscv-tdep.c continues to check for all three of these 105182 registers, and will handle them correctly if they are present. 105183 105184 2. If a target supplied fcsr, but does not supply fflags and/or frm, 105185 then RISC-V GDB will now create two pseudo registers in order to 105186 emulate the two missing CSRs. These new pseudo-registers do the 105187 obvious thing of just reading and writing the fcsr register. 105188 105189 3. With the new pseudo-registers we can no longer make use of the GDB 105190 register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM. 105191 These will be the numbers used if the target supplies the registers in 105192 its target description, but, if GDB falls back to using 105193 pseudo-registers, then new, unique numbers will be used. To handle 105194 this I've added riscv_gdbarch_tdep::fflags_regnum and 105195 riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to 105196 compare against these fields. 105197 105198 When adding the pseudo-register support, it is important that the 105199 pseudo-register numbers are calculated after the call to 105200 tdesc_use_registers. This is because we don't know the total number 105201 of physical registers until after this call, and the psuedo-register 105202 numbers must follow on from the real (target supplied) registers. 105203 105204 I've updated some tests to include more testing of the fflags and frm 105205 registers, as well as adding a new test. 105206 1052072022-08-31 Andrew Burgess <aburgess@redhat.com> 105208 105209 gdb: Add tdesc_found_register function to tdesc API 105210 This commit adds a new function to the target description API within 105211 GDB. This new function is not used in this commit, but will be used 105212 in the next commit, I'm splitting it out into a separate patch for 105213 easier review. 105214 105215 What I want to do in the next commit is check to see if a target 105216 description supplied a particular register, however, the register in 105217 question could appear in one of two possible features. 105218 105219 The new function allows me to ask the tdesc_arch_data whether a 105220 register was found and assigned a particular GDB register number once 105221 all of the features have been checked. I think this is a much simpler 105222 solution than adding code such that, while checking each feature, I 105223 spot if the register I'm processing is the one I care about. 105224 105225 No tests here as the new code is not used, but this code will be 105226 exercised in the next commit. 105227 1052282022-08-31 Andrew Burgess <aburgess@redhat.com> 105229 105230 gdb/riscv: improve (and fix) display of frm field in 'info registers' 105231 On RISC-V the FCSR (float control/status register) is split into two 105232 parts, FFLAGS (the flags) and FRM (the rounding mode). Both of these 105233 two fields are part of the FCSR register, but can also be accessed as 105234 separate registers in their own right. And so, we have three separate 105235 registers, $fflags, $frm, and $fcsr, with the last of these being the 105236 combination of the first two. 105237 105238 Here's how the bits of FCSR are split between FRM and FFLAGS: 105239 105240 ,--------- FFLAGS 105241 |---| 105242 76543210 <----- FCSR 105243 |-| 105244 '--------------FRM 105245 105246 Here's how GDB currently displays these registers: 105247 105248 (gdb) info registers $fflags $frm $fcsr 105249 fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 105250 frm 0x0 FRM:0 [RNE (round to nearest; ties to even)] 105251 fcsr 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)] 105252 105253 Notice the 'RD' field which is present in both $fflags and $fcsr. 105254 This field contains the value of the FRM field, which makes sense when 105255 displaying the $fcsr, but makes no sense when displaying $fflags, as 105256 the $fflags doesn't include the FRM field. 105257 105258 Additionally, the $fcsr already includes an FRM field, so the 105259 information in 'RD' is duplicated. Consider this: 105260 105261 (gdb) set $frm = 0x3 105262 (gdb) info registers $fflags $frm $fcsr │ 105263 fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 105264 frm 0x3 FRM:3 [RUP (Round up towards +INF)] 105265 fcsr 0x60 RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)] 105266 105267 See how the 'RD' field in $fflags still displays 0, while the 'RD' and 105268 'FRM' fields in $fcsr show the same information. 105269 105270 The first change I propose in this commit is to remove the 'RD' 105271 field. After this change the output now looks like this: 105272 105273 (gdb) info registers $fflags $frm $fcsr 105274 fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 105275 frm 0x0 FRM:0 [RNE (round to nearest; ties to even)] 105276 fcsr 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)] 105277 105278 Next, I spotted that the text that goes along with the 'FRM' field was 105279 not wrapped in the i18n markers for internationalisation, so I added 105280 those. 105281 105282 Next, I spotted that: 105283 105284 (gdb) set $frm=0x7 105285 (gdb) info registers $fflags $frm $fcsr 105286 fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 105287 frm 0x7 FRM:3 [RUP (Round up towards +INF)] 105288 fcsr 0xe0 RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)] 105289 105290 Notice that despite being a 3-bit field, FRM masks to 2-bits. 105291 Checking the manual I can see that the FRM field is 3-bits, and is 105292 defined for all 8 values. That GDB masks to 2-bits is just a bug I 105293 think, so I've fixed this. 105294 105295 Finally, the 'FRM' text for value 0x7 is wrong. Currently we use the 105296 text 'dynamic rounding mode' for value 0x7. However, this is not 105297 really correct. 105298 105299 A RISC-V instruction can either encode the rounding mode within the 105300 instruction, or a RISC-V instruction can choose to use a global, 105301 dynamic rounding mode. 105302 105303 So, for the rounding-mode field of an _instruction_ the value 0x7 105304 indicates "dynamic round mode", the instruction should defer to the 105305 rounding mode held in the FRM field of the $fcsr. 105306 105307 But it makes no sense for the FRM of $fcsr to itself be set to 105308 0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point 105309 Control and Status Register" of the RISC-V manual, says that a value 105310 of 0x7 in the $fcsr FRM field is invalid, and if an instruction has 105311 _its_ round-mode set to dynamic, and the FRM field is also set to 0x7, 105312 then an illegal instruction exception is raised. 105313 105314 And so, I propose changing the text for value 0x7 of the FRM field to 105315 be "INVALID[7] (Dynamic rounding mode)". We already use the text 105316 "INVALID[5]" and "INVALID[6]" for the two other invalid fields, 105317 however, I think adding the extra "Dynamic round mode" hint might be 105318 helpful. 105319 105320 I've added a new test that uses 'info registers' to check what GDB 105321 prints for the three registers related to this patch. There is one 105322 slight oddity with this test - for the fflags and frm registers, the 105323 test accepts both the "normal" output (as described above), but also 105324 allows these registers to be reported as '<unavailable>'. 105325 105326 The reason why I accept <unavailable> is that currently, the RISC-V, 105327 native Linux target advertises these registers in its target 105328 description, but then doesn't support reading or writing of these 105329 registers, this results in the registers being reported as 105330 unavailable. 105331 105332 A later patch in this series will address this issue, and will remove 105333 this check for <unavailable>. 105334 1053352022-08-31 Frederic Cambus <fred@statdns.com> 105336 105337 Add OpenBSD AArch64 GAS support. 105338 * configure.tgt (aarch64*-*-openbsd*): Add target. 105339 1053402022-08-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 105341 105342 gdb, dwarf: create symbols for template tags without names 105343 The following GDB behavior was also reported as a GDB bug in 105344 105345 https://sourceware.org/bugzilla/show_bug.cgi?id=28396 105346 105347 I will reiterate the problem a bit and give some more information here. 105348 This patch closes the above mentioned bug. 105349 105350 The DWARF 5 standard 2.23 'Template Parameters' reads: 105351 105352 A template type parameter is represented by a debugging information 105353 entry with the tag DW_TAG_template_type_parameter. A template value 105354 parameter is represented by a debugging information entry with the tag 105355 DW_TAG_template_value_parameter. The actual template parameter entries 105356 appear in the same order as the corresponding template formal 105357 parameter declarations in the source progam. 105358 105359 A type or value parameter entry may have a DW_AT_name attribute, whose 105360 value is a null-terminated string containing the name of the 105361 corresponding formal parameter. 105362 105363 So the DW_AT_name attribute for DW_TAG_template_type_parameter and 105364 DW_TAG_template_value_parameter is optional. 105365 105366 Within GDB, creating a new symbol from some read DIE usually requires the 105367 presence of a DW_AT_name for the DIE (an exception here is the case of 105368 unnamed namespaces or the existence of a linkage name). 105369 105370 This patch makes the presence of the DW_AT_name for template value/type 105371 tags optional, similar to the unnamed namespaces. 105372 105373 For unnamed namespaces dwarf2_name simply returns the constant string 105374 CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a 105375 case was added to the switch statement calling the 105376 unnamed_template_tag_name helper. Within the scope of parent which 105377 the template parameter is a child of, the helper counts the position 105378 of the template tag within the unnamed template tags and returns 105379 '<unnamedNUMBER>' where NUMBER is its position. This way we end up with 105380 unique names within the respective scope of the function/class/struct 105381 (these are the only currenltly supported template kinds within GDB and 105382 usually the compilers) where we discovered the template tags in. 105383 105384 While I do not know of a way to bring GCC to emit template tags without 105385 names there is one for clang/icpx. Consider the following example 105386 105387 template<typename A, typename B, typename C> 105388 class Foo {}; 105389 105390 template<typename, typename B, typename> 105391 class Foo; 105392 105393 int main () { 105394 Foo<double, int, float> f; 105395 return 0; 105396 } 105397 105398 The forward declaration for 'Foo' with the missing template type names 105399 'A' and 'C' makes clang emit a bunch of template tags without names: 105400 105401 ... 105402 <2><43>: Abbrev Number: 3 (DW_TAG_variable) 105403 <44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8) 105404 <47> DW_AT_name : (indirect string, offset: 0x63): f 105405 <4b> DW_AT_decl_file : 1 105406 <4c> DW_AT_decl_line : 8 105407 <4d> DW_AT_type : <0x59> 105408 ... 105409 <1><59>: Abbrev Number: 5 (DW_TAG_class_type) 105410 <5a> DW_AT_calling_convention: 5 (pass by value) 105411 <5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float> 105412 <5f> DW_AT_byte_size : 1 105413 <60> DW_AT_decl_file : 1 105414 <61> DW_AT_decl_line : 2 105415 <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param) 105416 <63> DW_AT_type : <0x76> 105417 <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param) 105418 <68> DW_AT_type : <0x52> 105419 <6c> DW_AT_name : (indirect string, offset: 0x6c): B 105420 <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param) 105421 <71> DW_AT_type : <0x7d> 105422 ... 105423 105424 Befor this patch, GDB would not create any symbols for the read template 105425 tag DIEs and thus lose knowledge about them. Breaking at the return 105426 statement and printing f's type would read 105427 105428 (gdb) ptype f 105429 type = class Foo<double, int, float> [with B = int] { 105430 <no data fields> 105431 } 105432 105433 After this patch GDB does generate symbols from the DWARF (with their 105434 artificial names: 105435 105436 (gdb) ptype f 105437 type = class Foo<double, int, float> [with <unnamed0> = double, B = int, 105438 <unnamed1> = float] { 105439 <no data fields> 105440 } 105441 105442 The same principle theoretically applies to template functions. Also 105443 here, GDB would not record unnamed template TAGs but I know of no visual 105444 way to trigger and test this changed behavior. Template functions do 105445 not emit a '[with...]' list and their name generation also does not 105446 suffer from template tags without names. GDB does not check whether or 105447 not a template tag has a name in 'dwarf2_compute_name' and thus, the 105448 names of the template functions are created independently of whether or 105449 not the template TAGs have a DW_TAT_name attribute. A testcase has 105450 been added in the gdb.dwarf2 for template classes and structs. 105451 105452 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396 105453 1054542022-08-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 105455 105456 gdb, testsuite: adapt function_range expected name 105457 When writing a dwarf testcase for some C++ code I wanted to use the 105458 MACRO_AT_range which in turn uses the function_range proc in dwarf.exp 105459 to extract the bounds of 'main'. 105460 105461 However, the macro failed as GDB prints the C++ 'main' with its 105462 arguments as 'main(int, char**)' or 'main()'. 105463 105464 The reason for this is that in read.c::dwarf2_compute_name we call 105465 c_type_print_args on C++ functions and append their arguments to the 105466 function name. This happens to all C++ functions, but is only visible 105467 when the function doesn't have a linkage name. 105468 105469 An example might make this more clear. Given the following code 105470 105471 >> cat c.cpp 105472 int foo (int a, float b) 105473 { 105474 return 0; 105475 } 105476 105477 int main (int argc, char **argv) 105478 { 105479 return 0; 105480 } 105481 105482 which is legal in both languages, C and C++, and compiling it with 105483 e.g. clang or gcc will make the disassemble command look like: 105484 105485 >> clang --version 105486 clang version 10.0.0-4ubuntu1 105487 ... 105488 >> clang -O0 -g ./c.cpp 105489 >> gdb -q ./a.out -ex "start" 105490 ... 105491 (gdb) disassemble main 105492 Dump of assembler code for function main(int, char**): 105493 0x0000000000401120 <+0>: push %rbp 105494 0x0000000000401121 <+1>: mov %rsp,%rbp 105495 ... 105496 0x0000000000401135 <+21>: ret 105497 End of assembler dump. 105498 (gdb) disassemble foo 105499 Dump of assembler code for function _Z3fooif: 105500 0x0000000000401110 <+0>: push %rbp 105501 0x0000000000401111 <+1>: mov %rsp,%rbp 105502 ... 105503 0x000000000040111f <+15>: ret 105504 End of assembler dump. 105505 105506 Note, that main is emitted with its arguments while for foo the linkage 105507 name is being printed, as also visible in its DWARF: 105508 105509 >> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3 105510 <2b> DW_AT_low_pc : 0x401110 105511 <33> DW_AT_high_pc : 0x10 105512 <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp)) 105513 <39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif 105514 <3d> DW_AT_name : (indirect string, offset: 0x42): foo 105515 <41> DW_AT_decl_file : 1 105516 <42> DW_AT_decl_line : 1 105517 <43> DW_AT_type : <0x9a> 105518 105519 Now, let's rename the C++ file and compile it as C: 105520 105521 >> mv c.cpp c.c 105522 >> clang -O0 -g ./c.c 105523 >> gdb -q ./a.out -ex "start' 105524 ... 105525 (gdb) disassemble main 105526 Dump of assembler code for function main: 105527 0x0000000000401120 <+0>: push %rbp 105528 0x0000000000401121 <+1>: mov %rsp,%rbp 105529 ... 105530 0x0000000000401135 <+21>: ret 105531 End of assembler dump. 105532 (gdb) disassemble foo 105533 Dump of assembler code for function foo: 105534 0x0000000000401110 <+0>: push %rbp 105535 0x0000000000401111 <+1>: mov %rsp,%rbp 105536 ... 105537 0x000000000040111f <+15>: ret 105538 End of assembler dump. 105539 105540 Note, for foo we did not get a linkage name emitted in DWARF, so 105541 it is printed by its name: 105542 105543 >> objdump --dwarf=info ./a.out | grep foo -A3 -B3 105544 <2b> DW_AT_low_pc : 0x401110 105545 <33> DW_AT_high_pc : 0x10 105546 <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp)) 105547 <39> DW_AT_name : (indirect string, offset: 0x37): foo 105548 <3d> DW_AT_decl_file : 1 105549 <3e> DW_AT_decl_line : 1 105550 <3f> DW_AT_prototyped : 1 105551 105552 To make the macro and proc work with C++ as well, an optional argument 105553 list was added to the regex matching the function name in the 105554 disassemble command in function_range. This does not change any used 105555 behavior as currently, there exists no C++ test using the proc 105556 function_range. 105557 1055582022-08-31 Aaron Merey <amerey@redhat.com> 105559 105560 gdb/elfread.c: Use bfd filename instead of objfile->original_name 105561 The call to debuginfod_debuginfo_query in elf_symfile_read is given 105562 objfile->original_name as the filename to print when downloading the 105563 objfile's debuginfo. 105564 105565 In some cases original_name is prefixed with gdb's working directory 105566 even though the objfile is not located in the working directory. This 105567 causes debuginfod to display the wrong path of the objfile during a download. 105568 105569 Fix this by using the objfile's bfd filename instead. 105570 1055712022-08-31 GDB Administrator <gdbadmin@sourceware.org> 105572 105573 Automatic date update in version.in 105574 1055752022-08-30 Martin Storsjö <martin@martin.st> 105576 105577 ld: pe: Fix linking against Microsoft import libraries with multiple DLLs 105578 Initially, since c6c37250e98f113755e0d787f7070e2ac80ce77e (in 1999), 105579 in order to fix linking against Microsoft import libraries, ld did 105580 internally rename members of such libraries. At that point, the 105581 criteria for being considered a Microsoft import library was that 105582 every archive member had the same name (no regard for exactly what 105583 that name was). 105584 105585 This was later amended in 44dbf3639f127af46d569ad96b6242dfbc4c0a89 105586 (in 2003) to allow for Microsoft import libraries with intermixed 105587 static object files. At this point, the criteria were extended, so 105588 that all members following the first member named *.dll either had 105589 the exact same member name, or be named *.obj. (Curiously, this would 105590 allow members with any name if it precedes the first one named *.dll.) 105591 105592 In practice, Microsoft style import libraries can contain 105593 members for linking against more than one DLL (built by merging 105594 multiple regular import libraries into one). 105595 105596 Instead of trying to do validation of the whole archive before 105597 considering it a Microsoft style import library, relax the criteria 105598 for doing the member renaming: If an archive member is named *.dll 105599 and it contains .idata sections, assume that that member is a 105600 Microsoft import file, and apply the renaming scheme. 105601 105602 This works for imports for any number of DLLs in the same library, 105603 intermixed with other static object files (regardless of their 105604 names), and vastly simplifies the code. 105605 105606 LLVM generates Microsoft style import libraries, and Rust builds 105607 seem to bundle up multiple import libraries together with some 105608 Rust specific static objects. This fixes linking directly against 105609 them with ld.bfd. 105610 1056112022-08-30 Simon Marchi <simon.marchi@polymtl.ca> 105612 105613 gdbsupport: add wrapper around result_of and invoke_result 105614 When building with Clang 14 (using gcc 12 libstdc++ headers), I get: 105615 105616 CXX dwarf2/read.o 105617 In file included from /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:94: 105618 /home/simark/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:142:21: error: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' is deprecated: use 'std::invoke_result' instead [-Werror,-Wdeprecated-declarations] 105619 = typename std::result_of<RangeFunction (RandomIt, RandomIt)>::type; 105620 ^ 105621 /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7122:14: note: in instantiation of function template specialization 'gdb::parallel_for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, (lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5)>' requested here 105622 = gdb::parallel_for_each (1, per_bfd->all_comp_units.begin (), 105623 ^ 105624 /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/type_traits:2597:9: note: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' has been explicitly marked deprecated here 105625 { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result"); 105626 ^ 105627 /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:120:45: note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST' 105628 # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT) 105629 ^ 105630 /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:96:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST' 105631 __attribute__ ((__deprecated__ ("use '" ALT "' instead"))) 105632 ^ 105633 105634 It complains about the use of std::result_of, which is deprecated in 105635 C++17 and removed in C++20: 105636 105637 https://en.cppreference.com/w/cpp/types/result_of 105638 105639 Given we'll have to transition to std::invoke_result eventually, make a 105640 GDB wrapper to mimimc std::invoke_result, which uses std::invoke_result 105641 for C++ >= 17 and std::result_of otherwise. This way, it will be easy 105642 to remove the wrapper in the future, just replace gdb:: with std::. 105643 105644 Tested by building with gcc 12 in -std=c++11 and -std=c++17 mode, and 105645 clang in -std=c++17 mode (I did not test fully with clang in -std=c++11 105646 mode because there are other unrelated issues). 105647 105648 Change-Id: I50debde0a3307a7bc67fcf8fceefda51860efc1d 105649 1056502022-08-30 Tom Tromey <tromey@adacore.com> 105651 105652 Fix flush for sys.stderr 105653 GDB overwrites Python's sys.stdout and sys.stderr, but does not 105654 properly implement the 'flush' method -- it only ever will flush 105655 stdout. This patch fixes the bug. I couldn't find a straightforward 105656 way to write a test for this. 105657 105658 Fix gdb.flush documentation 105659 The gdb.flush documentation does not mention the 'stream' argument in 105660 the function signature, only in the description. This patch fixes the 105661 oversight. 105662 1056632022-08-30 Nick Clifton <nickc@redhat.com> 105664 105665 BFD library: Use entry 0 in directory and filename tables of DWARF-5 debug info. 105666 PR 29529 105667 * dwarf2.c (struct line_info_table): Add new field: 105668 use_dir_and_file_0. 105669 (concat_filename): Use new field to help select the correct table 105670 slot. 105671 (read_formatted_entries): Do not skip entry 0. 105672 (decode_line_info): Set new field depending upon the version of 105673 DWARF being parsed. Initialise filename based upon the setting of 105674 the new field. 105675 1056762022-08-30 Enze Li <enze.li@hotmail.com> 105677 105678 gdb: update ranged_breakpoint::print_one_detail in comments 105679 The print_one_detail_ranged_breakpoint has been renamed to 105680 ranged_breakpoint::print_one_detail in this commit: 105681 105682 commit ec45bb676c9c69c30783bcf35ffdac8280f3b8bc 105683 Date: Sat Jan 15 16:34:51 2022 -0700 105684 105685 Convert ranged breakpoints to vtable ops 105686 105687 So their comments should be updated as well. 105688 1056892022-08-30 Nick Clifton <nickc@redhat.com> 105690 105691 Add a testcase for PR 29494. 105692 PR 29494 105693 * testsuite/gas/arm/pr29494.s: New test source file. 105694 * testsuite/gas/arm/pr29494.d: New test driver. 105695 1056962022-08-30 liuzhensong <liuzhensong@loongson.cn> 105697 105698 LoongArch: Fix redefinition of "PACKAGE". 105699 Running configure and make in binutils-gdb. 105700 105701 $ ./configure 105702 $ make 105703 In file included from ./as.h:37, 105704 from ./config/loongarch-lex.l:21, 105705 from config/loongarch-lex-wrapper.c:20: 105706 ./config.h:206: error: “PACKAGE” redefined [-Werror] 105707 #define PACKAGE "gas" 105708 ... 105709 105710 gas/config 105711 * loongarch-lex-wrapper.c 105712 1057132022-08-30 Tsukasa OI <research_trasio@irq.a4lg.com> 105714 105715 RISC-V: Add 'Zmmul' extension in assembler. 105716 Three-part patch set from Tsukasa OI to support zmmul in assembler. 105717 105718 The 'Zmmul' is a RISC-V extension consisting of only multiply instructions 105719 (a subset of 'M' which has multiply and divide instructions). 105720 105721 bfd/ 105722 * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zmmul' implied by 'M'. 105723 (riscv_supported_std_z_ext): Add 'Zmmul' extension. 105724 (riscv_multi_subset_supports): Add handling for new instruction class. 105725 gas/ 105726 * testsuite/gas/riscv/attribute-09.d: Updated implicit 'Zmmul' by 'M'. 105727 * testsuite/gas/riscv/option-arch-02.d: Likewise. 105728 * testsuite/gas/riscv/m-ext.s: New test. 105729 * testsuite/gas/riscv/m-ext-32.d: New test (RV32). 105730 * testsuite/gas/riscv/m-ext-64.d: New test (RV64). 105731 * testsuite/gas/riscv/zmmul-32.d: New expected output. 105732 * testsuite/gas/riscv/zmmul-64.d: Likewise. 105733 * testsuite/gas/riscv/m-ext-fail-xlen-32.d: New test (failure 105734 by using RV64-only instructions in RV32). 105735 * testsuite/gas/riscv/m-ext-fail-xlen-32.l: Likewise. 105736 * testsuite/gas/riscv/m-ext-fail-zmmul-32.d: New failure test 105737 (RV32 + Zmmul but with no M). 105738 * testsuite/gas/riscv/m-ext-fail-zmmul-32.l: Likewise. 105739 * testsuite/gas/riscv/m-ext-fail-zmmul-64.d: New failure test 105740 (RV64 + Zmmul but with no M). 105741 * testsuite/gas/riscv/m-ext-fail-zmmul-64.l: Likewise. 105742 * testsuite/gas/riscv/m-ext-fail-noarch-64.d: New failure test 105743 (no Zmmul or M). 105744 * testsuite/gas/riscv/m-ext-fail-noarch-64.l: Likewise. 105745 include/ 105746 * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZMMUL. 105747 ld/ 105748 * testsuite/ld-riscv-elf/attr-merge-arch-01.d: We don't care zmmul in 105749 these testcases, so just replaced m by a. 105750 * testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise. 105751 * testsuite/ld-riscv-elf/attr-merge-arch-01b.s: Likewise. 105752 * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise. 105753 * testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise. 105754 * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise. 105755 * testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise. 105756 * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Likewise. 105757 * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p0.s: Renamed. 105758 * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p1.s: Renamed. 105759 opcodes/ 105760 * riscv-opc.c (riscv_opcodes): Updated multiply instructions to zmmul. 105761 1057622022-08-30 Tom de Vries <tdevries@suse.de> 105763 105764 [gdb/symtab] Fix assert in set_length 105765 When running the included test-case, we run into: 105766 ... 105767 (gdb) break _start^M 105768 read.h:309: internal-error: set_length: \ 105769 Assertion `m_length == length' failed.^M 105770 ... 105771 105772 The problem is that while there are two CUs: 105773 ... 105774 $ readelf -wi debug-names-missing-cu | grep @ 105775 Compilation Unit @ offset 0x0: 105776 Compilation Unit @ offset 0x2d: 105777 ... 105778 the CU table in the .debug_names section only contains the first one: 105779 ... 105780 CU table: 105781 [ 0] 0x0 105782 ... 105783 105784 The incomplete CU table makes create_cus_from_debug_names_list set the size of 105785 the CU at 0x0 to the actual size of both CUs combined. 105786 105787 This eventually leads to the assert, when we read the actual size from the CU 105788 header. 105789 105790 While having an incomplete CU table in a .debug_names section is incorrect, 105791 we need a better failure mode than asserting. 105792 105793 The easiest way to fix this is to set the length to 0 (meaning: unkown) in 105794 create_cus_from_debug_names_list. 105795 105796 This makes the failure mode to accept the incomplete CU table, but to ignore 105797 the missing CU. 105798 105799 It would be nice to instead reject the .debug_names index, and build a 105800 complete CU list, but the point where we find this out is well after 105801 dwarf2_initialize_objfile, so it looks rather intrusive to restart at that 105802 point. 105803 105804 Tested on x86_64-linux. 105805 105806 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29453 105807 1058082022-08-30 Tom de Vries <tdevries@suse.de> 105809 105810 [gdb/tdep] Declare score-*-* target obsolete 105811 I tried out the script gdb/gdb_mbuild.sh, and ran into: 105812 ... 105813 score-elf ... 105814 ... configure --target=score-elf 105815 ... make score-elf 105816 ... run score-elf 105817 score-elf: gdb dumped core 105818 Terminated 105819 ... 105820 105821 Gdb runs into this internal error in initialize_current_architecture: 105822 ... 105823 if (! gdbarch_update_p (info)) 105824 internal_error (__FILE__, __LINE__, 105825 _("initialize_current_architecture: Selection of " 105826 "initial architecture failed")); 105827 ... 105828 105829 The call to gdbarch_update_p fails because commit 575b4c298a6 ("gdb: Remove 105830 support for S+core") removed support for the architecture. 105831 105832 Fix this by adding score-*-* to the list of obsolete targets in 105833 gdb/configure.tgt, such that we're no longer able to build the configuration: 105834 ... 105835 *** Configuration score-unknown-elf is obsolete. 105836 *** Support has been REMOVED. 105837 make: *** [Makefile:12806: configure-gdb] Error 1 105838 ... 105839 105840 Also remove the related line from the "Target Instruction Set Architectures" 105841 list in gdb/MAINTAINERS, such that gdb/gdb_mbuild.sh no longer tries to build 105842 it. 105843 1058442022-08-30 GDB Administrator <gdbadmin@sourceware.org> 105845 105846 Automatic date update in version.in 105847 1058482022-08-29 GDB Administrator <gdbadmin@sourceware.org> 105849 105850 Automatic date update in version.in 105851 1058522022-08-28 Alan Modra <amodra@gmail.com> 105853 105854 PR29494 Trailing jump table on ARM 105855 out_inc_line_addr and relax_inc_line_addr are passed INT_MAX as 105856 line_delta to flag end of section. This filters its way down to 105857 size_inc_line_addr and emit_inc_line_addr. Pass line_delta on to 105858 scale_addr_delta where it can be used to omit an unaligned opcode 105859 error. 105860 105861 PR 29494 105862 * dwarf2dbg.c (scale_addr_delta): Delete unnecessary forward decl. 105863 Add line_delta param. Don't print error at end of section, just 105864 round the address down. 105865 (size_inc_line_addr, emit_inc_line_addr): Adjust calls. 105866 1058672022-08-28 GDB Administrator <gdbadmin@sourceware.org> 105868 105869 Automatic date update in version.in 105870 1058712022-08-27 rupothar <rupesh.potharla@amd.com> 105872 105873 bfd: Fix minor bug in read_indexed_address function. 105874 read_indexed_address function is using offset_size instead of 105875 addr_size while reading addrx forms. 105876 1058772022-08-27 GDB Administrator <gdbadmin@sourceware.org> 105878 105879 Automatic date update in version.in 105880 1058812022-08-26 Simon Marchi <simon.marchi@polymtl.ca> 105882 105883 gdbsupport: fix gdb::optional compilation with C++11 && _GLIBCXX_DEBUG 105884 Similar to 911438f9f4 ("gdbsupport: fix array-view compilation with 105885 c++11 && _GLIBCXX_DEBUG"), but for gdb::optional. 105886 105887 I get this error when building with Clang 14 and -std=c++11: 105888 105889 CXX agent.o 105890 In file included from /home/simark/src/binutils-gdb/gdbsupport/agent.cc:20: 105891 In file included from /home/simark/src/binutils-gdb/gdbsupport/common-defs.h:210: 105892 In file included from /home/simark/src/binutils-gdb/gdbsupport/common-debug.h:23: 105893 /home/simark/src/binutils-gdb/gdbsupport/../gdbsupport/gdb_optional.h:213:5: error: use of this statement in a constexpr function is a C++14 extension [-Werror,-Wc++14-extensions] 105894 gdb_assert (this->has_value ()); 105895 ^ 105896 /home/simark/src/binutils-gdb/gdbsupport/gdb_assert.h:35:3: note: expanded from macro 'gdb_assert' 105897 ((void) ((expr) ? 0 : \ 105898 ^ 105899 105900 Change-Id: If0cf55607fc9dbd1925ccb97cd9abbf8993ff264 105901 1059022022-08-26 Simon Marchi <simon.marchi@polymtl.ca> 105903 105904 gdb: change bpstat_print's kind parameter to target_waitkind 105905 Change from int to target_waitkind, which is really what is is. While 105906 at it, remove some outdated doc. The return value is described by a 105907 relatively self-describing enum, not a numerical value like the doc 105908 says. 105909 105910 Change-Id: Id899c853a857c7891c45e5b1639024067d5b59cd 105911 1059122022-08-26 Simon Marchi <simon.marchi@efficios.com> 105913 105914 gdb, gdbsupport: configure: factor out yes/no/auto value checking 105915 Factor out the code that checks that a value is yes/no or yes/no/auto. 105916 Add two macros to gdbsupport/common.m4 and use them in gdb/configure.ac 105917 105918 I inspected the changes to configure. Other than whitespace changes, we 105919 have some benign changes to the error messages (one of them had an error 105920 actually). There are changes to the --enable-source-highlight and 105921 --enable-libbacktrace handling, but setting enable_source_highlight / 105922 enable_libbacktrace was not really useful anyway, they already had the 105923 right value. 105924 105925 Change-Id: I92587aec36874309e1605e2d60244649f09a757a 105926 1059272022-08-26 Alan Modra <amodra@gmail.com> 105928 105929 PR12265, Compiling ld/ fails on Solaris 8 105930 The fail was due to -Werror and headers included by dlfcn.h and 105931 elf-bfd.h disagreeing about AT_DCACHEBSIZE and other AT_*. Not a 105932 serious problem obviously, since release versions of binutils don't 105933 enable -Werror and the defines are not used. Anyway, reduce the 105934 number of files that might hit this problem by only including dlfcn.h 105935 where it is needed. 105936 105937 PR 12265 105938 * sysdep.h: Don't include dlfcn.h here. 105939 * plugin.c: Include it here. 105940 1059412022-08-26 GDB Administrator <gdbadmin@sourceware.org> 105942 105943 Automatic date update in version.in 105944 1059452022-08-25 Philippe Waroquiers <philippe.waroquiers@skynet.be> 105946 105947 Allow to document user-defined aliases. 105948 Compared to the previous version, this version fixes the comments reported by 105949 Tom Tromey and ensures that the 'help some-user-documented-alias' 105950 shows the alias definition to ensure the user understands this is an 105951 alias even if specifically documented. 105952 105953 When using 'help ALIASNAME', GDB shows the help of the aliased command. 105954 This is a good default behaviour. 105955 105956 However, GDB alias command allows to define aliases with arguments 105957 possibly changing or tuning significantly the behaviour of 105958 the aliased command. In such a case, showing the help of the aliased 105959 command might not be ideal. 105960 105961 This is particularly true when defining an alias as a set of 105962 nested 'with' followed by a last command to launch, such as: 105963 (gdb) alias pp10 = with print pretty -- with print elements 10 -- print 105964 Asking 'help pp10' shows the help of the 'with' command, which is 105965 not particularly useful: 105966 (gdb) help pp10 105967 with, pp10, w 105968 alias pp10 = with print pretty -- with print elements 10 -- print 105969 Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING. 105970 Usage: with SETTING [VALUE] [-- COMMAND] 105971 .... 105972 105973 Such an alias can now be documented by the user: 105974 (gdb) document pp10 105975 >Pretty printing an expressiong, printing 10 elements. 105976 >Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP 105977 >See 'help print' for more information. 105978 >end 105979 (gdb) help pp10 105980 alias pp10 = with print pretty -- with print elements 10 -- print 105981 Pretty printing an expressiong, printing 10 elements. 105982 Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP 105983 See 'help print' for more information. 105984 (gdb) 105985 105986 When a user-defined alias is documented specifically, help and apropos 105987 use the provided alias documentation instead of the documentation of 105988 the aliased command. 105989 105990 Such a documented alias is also not shown anymore in the help of the 105991 aliased command, and the alias is not listed anymore in the help 105992 of the aliased command. In particular for cases such as pp10 example above, 105993 indicating that pp10 is an alias of the 'with' command is confusing. 105994 1059952022-08-25 Jan-Benedict Glaw <jbglaw@lug-owl.de> 105996 105997 sim/aarch64: Fix aarch64_get_CPSR_bits() declaration 105998 Noticed while doing mass builds with a very recent GCC: 105999 106000 /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -DWITH_HW=1 -DHAVE_DV_SOCKSER -DDEFAULT_INLINE=0 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wno-error=maybe-uninitialized -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-parameter-type -Wpointer-sign -Wold-style-declaration -Werror -I. -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64 -I../common -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../common -I../../include -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../include -I../../bfd -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../bfd -I../../opcodes -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../opcodes -I../.. -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../gnulib/import -I../../gnulib/import -g -O2 -c -o cpustate.o -MT cpustate.o -MMD -MP -MF .deps/cpustate.Tpo cpustate.c 106001 cpustate.c:270:1: error: conflicting types for 'aarch64_get_CPSR_bits' due to enum/integer mismatch; have 'uint32_t(sim_cpu *, FlagMask)' {aka 'unsigned int(struct _sim_cpu *, FlagMask)'} [-Werror=enum-int-mismatch] 106002 270 | aarch64_get_CPSR_bits (sim_cpu *cpu, FlagMask mask) 106003 | ^~~~~~~~~~~~~~~~~~~~~ 106004 In file included from sim-main.h:30, 106005 from cpustate.c:28: 106006 cpustate.h:310:20: note: previous declaration of 'aarch64_get_CPSR_bits' with type 'uint32_t(sim_cpu *, uint32_t)' {aka 'unsigned int(struct _sim_cpu *, unsigned int)'} 106007 310 | extern uint32_t aarch64_get_CPSR_bits (sim_cpu *, uint32_t); 106008 | ^~~~~~~~~~~~~~~~~~~~~ 106009 cc1: all warnings being treated as errors 106010 1060112022-08-25 H.J. Lu <hjl.tools@gmail.com> 106012 106013 x86: Ignore protected visibility in shared libraries on Solaris 106014 On x86, the PLT entry in executable may be used as function address for 106015 functions in shared libraries. If functions are protected, the function 106016 address used in executable can be different from the function address 106017 used in shared library. This will lead to incorrect run-time behavior 106018 if function pointer equality is needed. By default, x86 linker issues 106019 an error in this case. 106020 106021 On Solaris, linker issued an error for 106022 106023 struct tm *tb = (kind == CPP_time_kind::FIXED ? gmtime : localtime) (&tt); 106024 106025 where gmtime is a protected function in libc.so. Use gmtime's PLT entry 106026 in executable as function address is safe since function pointer equality 106027 isn't needed. Ignore protected visibility in shared libraries on Solaris 106028 to disable linker error. If function pointer equality is needed, linker 106029 will silently generate executable with incorrect run-time behavior on 106030 Solaris. 106031 106032 PR ld/29512 106033 * elf32-i386.c (elf_i386_scan_relocs): Ignore protected 106034 visibility in shared libraries on Solaris. 106035 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 106036 1060372022-08-25 Nick Clifton <nickc@redhat.com> 106038 106039 GAS: Add a return type tag to DWARF DIEs generated for function symbols. 106040 PR 29517 106041 * dwarf2dbg.c (GAS_ABBREV_COMP_UNIT): New defined constant. 106042 (GAS_ABBREV_SUBPROG): New defined constant. 106043 (GAS_ABBREV_NO_TYPE): New defined constant. 106044 (out_debug_abbrev): Use the new defined constants when emitting 106045 abbreviation numbers. Generate an abbreviation for an unspecified 106046 type. 106047 (out_debug_info): Use the new defined constants when referring to 106048 abbreviations. Generate a use of the no_type abbreviation. 106049 Reference the use when generating DIEs for functions. 106050 * testsuite/gas/elf/dwarf-3-func.d: Update to allow for newly 106051 extended output from the assembler. 106052 * testsuite/gas/elf/dwarf-5-func-global.d: Likewise. 106053 * testsuite/gas/elf/dwarf-5-func-local.d: Likewise. 106054 * testsuite/gas/elf/dwarf-5-func.d: Likewise. 106055 106056 GAS: Allow AArch64 pseudo-ops to accept the command line separator character. 106057 PR 29519 106058 * config/tc-aarch64.c (s_unreq): Use find_end_of_line(). 106059 (s_aarch64_cpu): Likewise. 106060 (s_aarch64_arch): Likewise. 106061 (s_aarch64_arch_extension): Likewise. 106062 * testsuite/gas/aarch64/pr29519.d: New test driver file. 106063 * testsuite/gas/aarch64/pr29519.s: New test source file. 106064 1060652022-08-25 Palmer Dabbelt <palmer@rivosinc.com> 106066 106067 gas: NEWS: Add the RISC-V features for 2.39 106068 106069 gas: NEWS: Add the RISC-V features for 2.38 106070 106071 gas: NEWS: Add the RISC-V features for 2.37 106072 106073 gas: NEWS: Add the RISC-V features for 2.36 106074 106075 gas: NEWS: Add the RISC-V features for 2.35 106076 106077 gas: NEWS: Add the RISC-V features for 2.31 106078 1060792022-08-25 Alan Modra <amodra@gmail.com> 106080 106081 PR11290, avr-ld "out of range error" is confusing 106082 Don't overload bfd_reloc_outofrange with what is really a domain error 106083 (target at odd address), or an overflow. 106084 106085 PR 11290 106086 * reloc.c (bfd_reloc_other): Correct comment. 106087 * elf32-avr.c (avr_final_link_relocate): Return bfd_reloc_other 106088 for unaligned reloc target values. Return bfd_reloc_overflow 106089 when stubs are too far away and when R_AVR_LDS_STS_16, 106090 R_AVR_PORT6, or R_AVR_PORT5 overflow. 106091 (elf32_avr_relocate_section): Report more descriptive relocation 106092 errors. 106093 * bfd-in2.h: Regenerate. 106094 1060952022-08-25 Martin Storsjö <martin@martin.st> 106096 106097 ld: pe: Move the return type to a separate line from the function name 106098 This fixes the coding style of an old, preexisting function. 106099 1061002022-08-25 Alan Modra <amodra@gmail.com> 106101 106102 PR10372, SH: ld test with sim/sh/run fails always 106103 PR 10372 106104 * testsuite/ld-sh/start.s: Add _start sym. Use trapa 34. Create 106105 an alloc .stack section. 106106 1061072022-08-25 Alan Modra <amodra@gmail.com> 106108 106109 Re: LoongArch: ld: Fix bug not generate plt when link a dso 106110 Fixes loongarch32-elf +FAIL: medium jirl plt 106111 106112 * testsuite/ld-loongarch-elf/cmodel.exp: Don't run test when 106113 no shared library support. 106114 1061152022-08-25 GDB Administrator <gdbadmin@sourceware.org> 106116 106117 Automatic date update in version.in 106118 1061192022-08-24 Martin Storsjö <martin@martin.st> 106120 106121 ld: pe: Make archive member file extension comparisons case insensitive when cross compiling too 106122 On Windows, filename_cmp is case insensitive, but when cross compiling 106123 with libraries that may contain members with uppercase file names, we 106124 should keep those comparisons case insensitive when running the build 106125 tools on other OSes too. 106126 106127 Also make the check for .def consistent with the other ones, fixing 106128 out of bounds reads if file names are shorter than 4 characters. 106129 1061302022-08-24 Richard Earnshaw <rearnsha@arm.com> 106131 106132 gas: arm: handle multiple .directives on a single line (PR29519) 106133 There's been a long-standing bug in the arm backend where 106134 target-specific directives did not correctly handle lines with 106135 multiple statements. This patch fixes the issue for all the cases 106136 I've been able to find. 106137 106138 It does result in a slight change in behaviour when errors are 106139 encountered: where, previously, 106140 106141 .cpu arm6 bar 106142 106143 would result in the error "junk at end of line, first unrecognized 106144 character is `b'", we now get "unknown cpu `arm6 bar'", which I think 106145 is slightly more helpful anyway. Similar errors are generated for 106146 other directives. 106147 1061482022-08-24 Andrew Burgess <aburgess@redhat.com> 106149 106150 gdb: new 'maint print frame-id' command 106151 When debugging a certain class of GDB bug, I often end up wanting to 106152 know what GDB thinks the frame-id is in a particular frame. It's 106153 not too hard to pull this from some debug output, but I thought it 106154 might be nice if there was a maintenance command that could tell us. 106155 106156 This commit adds 'maint print frame-id' which prints the frame-id of 106157 the currently selected frame. You can also pass a frame level number 106158 to find the frame-id for a specific frame. 106159 106160 There's a new test too. 106161 1061622022-08-24 liuzhensong <liuzhensong@loongson.cn> 106163 106164 LoongArch: ld: Fix bug not generate plt when link a dso 106165 Fix the bug that can not generate func@plt 106166 when linking a undefined function with cmodel=medium. 106167 Add testcase. 106168 106169 bfd/ 106170 * elfnn-loongarch.c 106171 ld/testsuite/ld-loongarch-elf/ 106172 * cmodel-libjirl.dd 106173 * cmodel.exp 106174 * libjirl.s 106175 1061762022-08-24 GDB Administrator <gdbadmin@sourceware.org> 106177 106178 Automatic date update in version.in 106179 1061802022-08-23 Alan Modra <amodra@gmail.com> 106181 106182 SHT_RELR sh_link and sh_info 106183 I don't think it makes any sense for a SHT_RELR section to specify a 106184 symbol table with sh_link. SHT_RELR relocations don't use symbols. 106185 There is no real need to specify sh_info either, SHT_RELR is not for 106186 relocatable object files. Anyway, fuzzers of course don't restrict 106187 themselves to even half-sensible objects. So they found a hole in 106188 objcopy using a non-alloc SHT_RELR in an ET_EXEC. In that case BFD 106189 set up the SHT_RELR section as if it were a SHT_REL against the 106190 sh_info target section. When it came to reading in the target section 106191 relocs, the count was horribly wrong which caused a buffer overflow. 106192 106193 * elf.c (bfd_section_from_shdr <SHT_RELR>): Always just make a 106194 normal section, don't treat it as a reloc section. 106195 1061962022-08-23 Alan Modra <amodra@gmail.com> 106197 106198 Re: bfd_elf_set_group_contents assertion 106199 Further to commit 7744e3278b9f. 106200 106201 * elf.c (bfd_elf_set_group_contents): Restrict loc in loop writing 106202 contents, and add another assertion. 106203 1062042022-08-23 Nick Clifton <nickc@redhat.com> 106205 106206 Add an option to dlltool to allow the creation of deterministic libraries. 106207 PR 29489 106208 * dlltool.c (deterministic): New variable. 106209 (gen_lib_file): If deterministic is true set the 106210 BFD_DETERMINISTIC_OUTPUT flag. 106211 (usage): Mention --deterministic-libraries and 106212 --non-deterministic-libraries. 106213 (long_options): Add new options. 106214 (main): Parse new options. 106215 * doc/binutils.texi: Document the new options. 106216 * NEWS: Mention the new feature. 106217 1062182022-08-23 Nelson Chu <nelson@rivosinc.com> 106219 106220 binutils: Updated my email address. 106221 binutils/ 106222 * MAINTAINERS (RISC-V): Updated my email address. 106223 1062242022-08-23 GDB Administrator <gdbadmin@sourceware.org> 106225 106226 Automatic date update in version.in 106227 1062282022-08-22 Tom Tromey <tromey@adacore.com> 106229 106230 Implement target async for Windows 106231 This implements target async for Windows. The basic idea is to have 106232 the worker thread block in WaitForDebugEvent, then notify the event 106233 loop when an event is seen. In a few situations, this blocking 106234 behavior is undesirable, so the functions passed to do_synchronously 106235 are changed to return a boolean indicating which behavior is needed. 106236 1062372022-08-22 Tom Tromey <tromey@adacore.com> 106238 106239 Move some Windows operations to worker thread 106240 On Windows, certain debugging APIs can only be called from the thread 106241 that started (or attached) to the inferior. Also, there is no way on 106242 Windows to wait for a debug event in addition to other events. 106243 Therefore, in order to implement target async for Windows, gdb will 106244 have to call some functions in a worker thread. 106245 106246 This patch implements the worker thread and moves the necessary 106247 operations there. Target async isn't yet implemented, so this patch 106248 does not cause any visible changes. 106249 1062502022-08-22 Tom Tromey <tromey@adacore.com> 106251 106252 Avoid crash with Ravenscar tasks 106253 When using Ravenscar, gdb can crash if the user sets a breakpoint very 106254 early in task startup. This happens because gdb thinks the runtime is 106255 initialized, but in practice the particular task isn't sufficiently 106256 initialized. This patch avoids the issue by turning an assertion into 106257 an early return. 106258 106259 I tested this using the AdaCore internal test suite. I don't know how 106260 to test Ravenscar using the FSF test suite. 106261 1062622022-08-22 Nick Clifton <nickc@redhat.com> 106263 106264 Fix compile time warning from Clang about error messages not being printed safely. 106265 106266 Have readelf warn users if it is asked to decode a LLVM bitcode file or a golang object file. 106267 * readelf.c (check_magic_number): New function. Checks the magic 106268 bytes at the start of a file. If they are not the ELF format 106269 magic values, then attempts to generate a helpful error message. 106270 (process_file_header): Call check_magic_number. 106271 1062722022-08-22 Frederic Cambus <fred@statdns.com> 106273 106274 Add OpenBSD AArch64 Little Endian BFD support. 106275 * config.bfd (aarch64-*-openbsd*): Add target. 106276 1062772022-08-22 tangxiaolin <tangxiaolin@loongson.cn> 106278 106279 LoongArch: gas: add support using constant variable in instructions. 106280 Instructions that can load immediate support using constant 106281 variable like ".equ var, 123 li.w/d resgister, var". 106282 106283 gas/ 106284 * config/loongarch-parse.y 106285 * config/tc-loongarch.c 106286 106287 Add four testcases.One is a program using constant variable, 106288 one test using label is unsupported, and another two test 106289 almost instructions that can load immediate. 106290 106291 gas/ 106292 * testsuite/gas/loongarch/li.d 106293 * testsuite/gas/loongarch/li.s 106294 * testsuite/gas/loongarch/imm_ins_label-fail.d 106295 * testsuite/gas/loongarch/imm_ins_label-fail.l 106296 * testsuite/gas/loongarch/imm_ins_label-fail.s 106297 * testsuite/gas/loongarch/imm_ins.d 106298 * testsuite/gas/loongarch/imm_ins.s 106299 * testsuite/gas/loongarch/imm_ins_32.d 106300 * testsuite/gas/loongarch/imm_ins_32.s 106301 1063022022-08-22 GDB Administrator <gdbadmin@sourceware.org> 106303 106304 Automatic date update in version.in 106305 1063062022-08-21 Tom Tromey <tom@tromey.com> 106307 106308 Fix crash in gdbpy_parse_register_id 106309 I noticed that gdbpy_parse_register_id would assert if passed a Python 106310 object of a type it was not expecting. The included test case shows 106311 this crash. This patch fixes the problem and also changes 106312 gdbpy_parse_register_id to be more "Python-like" -- it always ensures 106313 the Python error is set when it fails, and the callers now simply 106314 propagate the existing exception. 106315 1063162022-08-21 GDB Administrator <gdbadmin@sourceware.org> 106317 106318 Automatic date update in version.in 106319 1063202022-08-20 Alan Modra <amodra@gmail.com> 106321 106322 symbols for bfd_simple_get_relocated_section_contents 106323 If symbols are provided by the caller of this function they are 106324 passed on to bfd_get_relocated_section_contents. No surprises there. 106325 It gets a little weird if they are not provided. In that case they 106326 are read from the bfd by _bfd_generic_link_add_symbols, and global 106327 symbols are added to the generic linker hash table. Global symbols 106328 are not added to the linker hash table if symbols *are* provided. Now 106329 the linker hash table symbols are not used by the generic 106330 bfd_get_relocated_section_conents, and also not by most target 106331 versions when called from bfd_simple_get_relocated_section_contents 106332 except for symbols like "_gp". So it mostly doesn't matter whether 106333 symbols are in the linker hash table, but it's odd that there is a 106334 difference. We could always add them, but I'm inclined to think that 106335 is unnecessary work so this patch always leaves them out. 106336 106337 Also, symbols are canonicalized and written into a malloc'd buffer. 106338 The buffer isn't freed, see commit 8e16317ca5eb. I don't know whether 106339 that matters any more, but in any case I can't see why we need another 106340 copy of the symbols when _bfd_generic_link_read_symbols has already 106341 cached symbols. 106342 106343 * simple.c (bfd_simple_get_relocated_section_contents): If not 106344 provided, read symbols via bfd_generic_link_read_symbols. Do 106345 not create another copy of symbols. Tidy failure exits. 106346 Minor tidy of bfd_get_relocated_section_contents and 106347 bfd_get_full_section_contents arguments. 106348 1063492022-08-20 Alan Modra <amodra@gmail.com> 106350 106351 Re: Missing linking test case for pe dll using a def file 106352 Fixes this when cross-compiling from x86_64-linux 106353 x86_64-w64-mingw32 +FAIL: compiling shared lib fastcall/stdcall 106354 106355 * testsuite/ld-pe/pe-run2-def.exp (test_direct2_link_dll_def): 106356 Use CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS. 106357 1063582022-08-20 GDB Administrator <gdbadmin@sourceware.org> 106359 106360 Automatic date update in version.in 106361 1063622022-08-19 Patrick Monnerat <patrick@monnerat.net> 106363 106364 gdb_do_one_event: use integer test syntax 106365 Timeout is an int, not a bool. 106366 1063672022-08-19 Tom Tromey <tom@tromey.com> 106368 106369 Remove two initialization functions 106370 I noticed a couple of initialization functions that aren't really 106371 needed, and that currently require explicit calls in gdb_init. This 106372 patch removes these functions, simplifying gdb a little. 106373 106374 Regression tested on x86-64 Fedora 34. 106375 1063762022-08-19 Simon Marchi <simon.marchi@efficios.com> 106377 106378 gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE 106379 As Luis pointed out here [1], the AArch64 variant of the test doesn't 106380 work on systems that use PIE by default. For example, on this Debian 106381 11: 106382 106383 $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp" 106384 gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC 106385 /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' 106386 106387 This is because entry-value-typedef-aarch64.S was generated on an old 106388 system that does not generate position-independent code by default, but 106389 the system the test runs on tries to link the test executable as 106390 position-independent. Fix this by regenerating the same binary on the 106391 same system as the original one, but with -fPIE this time. Do the same 106392 for the amd64 binary, although this one was already position-independent 106393 so the generated code doesn't change. 106394 106395 With this patch applied, the test passes on the Debian 11 AArch64 106396 system. 106397 106398 [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html 106399 106400 Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144 106401 1064022022-08-19 Felix Willgerodt <felix.willgerodt@intel.com> 106403 106404 gdb, testsuite: Adapt gdb.base/callfuncs.exp for new clang warning. 106405 Clang 15.0.0 enabled the warning for deprecated non-prototype functions 106406 by default: https://reviews.llvm.org/D122895 106407 Callfuncs.exp is impacted and won't run due to new warnings: 106408 106409 callfuncs.c:339:5: warning: a function declaration without a prototype is 106410 deprecated in all versions of C and is not supported in C2x 106411 [-Wdeprecated-non-prototype] 106412 int t_float_values (float_arg1, float_arg2) 106413 106414 This patch disables those warnings with -Wno-deprecated-non-prototype. 106415 Removing the test for deprecated syntax would also be an option. But I will 106416 leave that up for others to decide/implement. 106417 1064182022-08-19 Felix Willgerodt <felix.willgerodt@intel.com> 106419 106420 gdb, testsuite: Enable testcases that suppress specific warnings, for icc/icx. 106421 To cite gdb.exp: 106422 Some C/C++ testcases unconditionally pass -Wno-foo as additional 106423 options to disable some warning. That is OK with GCC, because 106424 by design, GCC accepts any -Wno-foo option, even if it doesn't 106425 support -Wfoo. Clang however warns about unknown -Wno-foo by 106426 default, unless you pass -Wno-unknown-warning-option as well. 106427 We do that here, so that individual testcases don't have to 106428 worry about it. 106429 106430 This patch adds the same option that already exists for clang for icx and 106431 adds the equivalent icc option. 106432 1064332022-08-19 Tiezhu Yang <yangtiezhu@loongson.cn> 106434 106435 gdb: LoongArch: Handle variadic arguments 106436 According to LoongArch ELF ABI specification [1], variadic arguments 106437 are passed in GARs in the same manner as named arguments. And after 106438 a variadic argument has been passed on the stack, all future arguments 106439 will also be passed on the stack, i.e., the last argument register may 106440 be left unused due to the aligned register pair rule. long double data 106441 tpye is passed in an aligned GAR pair, the first register in the pair 106442 is even-numbered. 106443 106444 [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html 106445 1064462022-08-19 Alan Modra <amodra@gmail.com> 106447 106448 loongarch64_pei_vec garbage in objcopy'd relocs 106449 Like commit a9c09a3667cc, but for loongarch64. 106450 106451 * coff-loongarch64.c (SWAP_IN_RELOC_OFFSET): Define. 106452 (SWAP_OUT_RELOC_OFFSET): Define. 106453 1064542022-08-19 GDB Administrator <gdbadmin@sourceware.org> 106455 106456 Automatic date update in version.in 106457 1064582022-08-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 106459 106460 gprofng: fix bug 29479 Collection fails when built without java support 106461 gprofng/ChangeLog 106462 2022-08-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 106463 106464 PR gprofng/29479 106465 * libcollector/collector.c: Add #if defined(GPROFNG_JAVA_PROFILING) for 106466 java specific code. 106467 * libcollector/unwind.c: Likewise. 106468 1064692022-08-18 Simon Marchi <simon.marchi@polymtl.ca> 106470 106471 gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result 106472 Bug 29374 shows this crash: 106473 106474 $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out 106475 ... 106476 /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. 106477 106478 The backtrace is: 106479 106480 #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 106481 #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 106482 #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 106483 #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 106484 #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 106485 #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 106486 #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 106487 #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 106488 #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 106489 #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 106490 #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 106491 #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 106492 #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 106493 #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 106494 #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 106495 #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 106496 106497 The problem is that the type that gets passed down to 106498 dwarf_expr_context::fetch_result (the type of a variable of which we're 106499 trying to read the entry value) is a typedef whose size has never been 106500 computed yet (check_typedef has never been called on it). As we get in 106501 the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` 106502 variable is therefore set to 0, instead of the actual type length. We 106503 then call allocate_value on subobj_type, which does call check_typedef, 106504 so the length of the typedef gets filled in at that point. We end up 106505 passing to the copy function a source array view of length 0 and a 106506 target array view of length 4, and the assertion fails. 106507 106508 Fix this by calling check_typedef on both type and subobj_type at the 106509 beginning of fetch_result. 106510 106511 I tried writing a test for this using the DWARF assembler, but I haven't 106512 succeeded. It's possible that we need to get into this specific code 106513 path (value_of_dwarf_reg_entry and all) to manage to get to 106514 dwarf_expr_context::fetch_result with a typedef type that has never been 106515 resolved. In all my attempts, the typedef would always be resolved 106516 already, so the bug wouldn't show up. 106517 106518 As a fallback, I made a gdb.dwarf2 test with compiler-generated .S 106519 files. I don't particularly like those, but I think it's better than no 106520 test. The .cpp source code is the smallest reproducer I am able to make 106521 from the reproducer given in the bug (thanks to Pedro for suggestions on 106522 how to minimize it further than I had). Since I tested on both amd64 106523 and aarch64, I added versions of the test for these two architectures. 106524 106525 Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 106526 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 106527 1065282022-08-18 Luis Machado <luis.machado@arm.com> 106529 106530 [aarch64] Remove handling of ADR/ADRP from prologue analyzer 106531 As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html, 106532 the aarch64 prologue analyzer considers the adrp instruction in the 106533 gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue. 106534 106535 The function has no prologue though, and it only loads the volatile variable 106536 from memory. GDB should not skip any instructions in this case. 106537 106538 Doing some archaeology, it seems handling for adr/adrp in prologues was 106539 included with the original aarch64 port. It might've been an oversight. 106540 106541 In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips 106542 a couple instructions and leaves us in a nice spot where the address to the 106543 variable "v" is already in w0. But no prologues exists. 106544 106545 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29481 106546 1065472022-08-18 Tom Tromey <tom@tromey.com> 106548 106549 Change bookmark allocation 106550 This changes how bookmarks are allocated and stored, replacing a 106551 linked list with a vector and removing some ALL_* iterator macros. 106552 Regression tested on x86-64 Fedora 34. 106553 1065542022-08-18 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 106555 106556 Add test for AArch64 Scalable Vector Extension 106557 It exercises a bug that GDB previously had where it would lose track of 106558 some registers when the inferior changed its vector length. 106559 106560 It also checks that the vg register and the size of the z0-z31 registers 106561 correctly reflect the new vector length. 106562 1065632022-08-18 Thiago Jung Bauermann <thiago.bauermann@linaro.org> 106564 106565 Fix thread's gdbarch when SVE vector length changes 106566 When the inferior program changes the SVE length, GDB can stop tracking 106567 some registers as it obtains the new gdbarch that corresponds to the 106568 updated length: 106569 106570 Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44 106571 44 res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0); 106572 (gdb) print i 106573 $2 = 32 106574 (gdb) info registers 106575 ⋮ 106576 [ snip registers x0 to x30 ] 106577 ⋮ 106578 sp 0xffffffffeff0 0xffffffffeff0 106579 pc 0xaaaaaaaaa8ac 0xaaaaaaaaa8ac <do_sve_ioctl_test+112> 106580 cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ] 106581 fpsr 0x0 0 106582 fpcr 0x0 0 106583 vg 0x8 8 106584 tpidr 0xfffff7fcb320 0xfffff7fcb320 106585 (gdb) next 106586 45 if (res < 0) { 106587 (gdb) info registers 106588 ⋮ 106589 [ snip registers x0 to x30 ] 106590 ⋮ 106591 sp 0xffffffffeff0 0xffffffffeff0 106592 pc 0xaaaaaaaaa8cc 0xaaaaaaaaa8cc <do_sve_ioctl_test+144> 106593 cpsr 0x200000 [ EL=0 BTYPE=0 SS ] 106594 fpsr 0x0 0 106595 fpcr 0x0 0 106596 vg 0x4 4 106597 (gdb) 106598 106599 Notice that register tpidr disappeared when vg (which holds the vector 106600 length) changed from 8 to 4. The tpidr register is provided by the 106601 org.gnu.gdb.aarch64.tls feature. 106602 106603 This happens because the code that searches for a new gdbarch to match the 106604 new vector length in aarch64_linux_nat_target::thread_architecture doesn't 106605 take into account the features present in the target description associated 106606 with the previous gdbarch. This patch makes it do that. 106607 106608 Since the id member of struct gdbarch_info is now unused, it's removed. 106609 1066102022-08-18 Ralf Habacker <ralf.habacker@freenet.de> 106611 106612 Missing linking test case for pe dll using a def file. 106613 PR 28362 106614 * testsuite/ld-pe/pe-run2-def.exp: New file. 106615 1066162022-08-18 Patrick Monnerat <patrick@monnerat.net> 106617 106618 gdbsupport/event-loop: add a timeout parameter to gdb_do_one_event 106619 Since commit b2d8657, having a per-interpreter event/command loop is not 106620 possible anymore. 106621 106622 As Insight uses a GUI that has its own event loop, gdb and GUI event 106623 loops have then to be "merged" (i.e.: work together). But this is 106624 problematic as gdb_do_one_event is not aware of this alternate event 106625 loop and thus may wait forever. 106626 106627 A solution is to delegate GUI events handling to the gdb events handler. 106628 Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to 106629 implement such a delegation. The Tcl notifier spec requires the event wait 106630 function to support a timeout parameter. Unfortunately gdb_do_one_event 106631 does not feature such a parameter. 106632 This timeout cannot be implemented externally with a gdb timer, because 106633 it would become an event by itself and thus can cause a legitimate event to 106634 be missed if the timeout is 0. 106635 Tcl implements "idle events" that are (internally) triggered only when no 106636 other event is pending. For this reason, it can call the event wait function 106637 with a 0 timeout quite often. 106638 106639 This patch implements a wait timeout to gdb_do_one_event. The initial 106640 pending events monitoring is performed as before without the possibility 106641 to enter a wait state. If no pending event has been found during this 106642 phase, a timer is then created for the given timeout in order to re-use 106643 the implemented timeout logic and the event wait is then performed. 106644 This "internal" timer only limits the wait time and should never be triggered. 106645 It is deleted upon gdb_do_one_event exit. 106646 106647 The new parameter defaults to "no timeout" (-1): as it is used by Insight 106648 only, there is no need to update calls from the gdb source tree. 106649 1066502022-08-18 Patrick Monnerat <patrick@monnerat.net> 106651 106652 gdb: add Patrick Monnerat to gdb/MAINTAINERS 106653 1066542022-08-18 Jan Beulich <jbeulich@suse.com> 106655 106656 x86: move / quiesce pre-386 non-16-bit warning 106657 Emitting this warning for every insn, including ones having actual 106658 errors, is annoying. Introduce a boolean variable to emit the warning 106659 just once on the first insn after .arch may have changed the things, and 106660 move the warning to output_insn(). (I didn't want to go as far as 106661 checking whether the .arch actually turned off the i386 bit, but doing 106662 so would be an option.) 106663 106664 x86: insert "no error" enumerator in i386_error enumeration 106665 The value of zero would better not indicate any error, but rather hit 106666 the abort() at the top of the consuming switch(). 106667 1066682022-08-18 GDB Administrator <gdbadmin@sourceware.org> 106669 106670 Automatic date update in version.in 106671 1066722022-08-17 Maciej W. Rozycki <macro@embecosm.com> 106673 106674 GDB/testsuite: Fix PARAM_ZUINTEGER reported for PARAM_ZUINTEGER_UNLIMITED 106675 Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER 106676 in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type. 106677 1066782022-08-17 Alan Modra <amodra@gmail.com> 106679 106680 bfd_elf_set_group_contents assertion 106681 objcopy of broken SHT_GROUP sections shouldn't write garbage. 106682 106683 * elf.c (bfd_elf_set_group_contents): If number of entries is 106684 unexpected, fill out section with zeros. 106685 1066862022-08-17 Alan Modra <amodra@gmail.com> 106687 106688 timeout in mmo_get_symbols 106689 Fix mmo_get_byte to return a fail-safe value, not just on the first 106690 call with a read error but on subsequent calls too. 106691 106692 * mmo.c (mmo_get_byte): Return the fail-safe value on every 106693 call after a read error. 106694 1066952022-08-17 Alan Modra <amodra@gmail.com> 106696 106697 mmo.c leak in mmo_make_section 106698 * mmo.c (mmo_make_section): Alloc name using bfd_alloc. Use 106699 bfd_error_no_memory. 106700 (mmo_decide_section): Check for NULL return from mmo_make_section. 106701 1067022022-08-17 Alan Modra <amodra@gmail.com> 106703 106704 asan: heap buffer overflow in mmo_scan 106705 mmo_get_loc needs to handle arbitrary vma and size chunks. Fuzzers 106706 found that it wasn't working so well when the end of chunks were 106707 getting close to address wrap-around. 106708 106709 * mmo.c (mmo_get_loc): Make "size" unsigned. Avoid arithmetic 106710 overflow when calculating whether range hits an existing chunk. 106711 1067122022-08-17 Alan Modra <amodra@gmail.com> 106713 106714 elf.c tidy 106715 Swap params of is_note, so they are section, segment like others used 106716 in rewrite_elf_program_header. Whitespace fixes, plus wrapping of 106717 overlong lines. 106718 1067192022-08-17 GDB Administrator <gdbadmin@sourceware.org> 106720 106721 Automatic date update in version.in 106722 1067232022-08-16 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 106724 106725 bfd: Define ___lc_codepage_func prototype for older MinGW-w64 106726 In commit 68e80d96a84282d547f3b3c1234c99009521630c, the usage of 106727 ___lc_codepage_func was introduced to determine the current encoding. 106728 106729 Prior to version 9.0 of MinGW-w64, the function prototype for 106730 ___lc_codepage_func was missing and trying to build BFD caused the 106731 following error: 106732 106733 error: implicit declaration of function ‘___lc_codepage_func’ 106734 106735 This changeset adds a conditonal definition of 106736 ___lc_codepage_func to allow a sucessful build with MinGW-w64. 106737 1067382022-08-16 H.J. Lu <hjl.tools@gmail.com> 106739 106740 i386: Add MAX_OPERAND_BUFFER_SIZE 106741 When displaying operands, invalid opcodes may overflow operand buffer 106742 due to additional styling characters. Each style is encoded with 3 106743 bytes. Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and 106744 increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles 106745 in an operand. 106746 106747 gas/ 106748 106749 PR binutils/29483 106750 * testsuite/gas/i386/i386.exp: Run pr29483. 106751 * testsuite/gas/i386/pr29483.d: New file. 106752 * testsuite/gas/i386/pr29483.s: Likewise. 106753 106754 opcodes/ 106755 106756 PR binutils/29483 106757 * i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New. 106758 (obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE. 106759 (staging_area): Likewise. 106760 (op_out): Likewise. 106761 1067622022-08-16 Andrew Burgess <aburgess@redhat.com> 106763 106764 gdb/riscv: fix gdb.arch/riscv-unwind-long-insn.exp on RV64 106765 I noticed that the gdb.arch/riscv-unwind-long-insn.exp test was 106766 failing when run on a 64-bit RISC-V target. 106767 106768 The problem was that GDB was failing to stop after a finish command, 106769 and was then running to an unexpected location. 106770 106771 The reason GDB failed to stop at the finish breakpoint was that the 106772 frame-id of the inferior, when we reached the finish breakpoint, 106773 didn't match the expected frame-id that was stored on the breakpoint. 106774 106775 The reason for this mismatch was that the assembler code that is 106776 included in this test, was written only taking 32-bit RISC-V into 106777 account, as a result, the $fp register was being corrupted, and this 106778 was causing the frame-id mismatch. 106779 106780 Specifically, the $fp register would end up being sign-extended from 106781 32 to 64 bits. If the expected $fp value has some significant bits 106782 above bit 31 then the computed and expected frame-ids would not match. 106783 106784 To fix this I propose merging the two .s files into a single .S file, 106785 and making use of preprocessor macros to specialise the file for the 106786 correct size of $fp. There are plenty of existing tests that already 106787 make use of preprocessor macros in assembler files, so I assume this 106788 approach is fine. 106789 106790 Once I'd decided to make use of preprocessor macros to solve the 32/64 106791 bit issue, then I figured I might as well merge the two test assembler 106792 files, they only differed by a single instruction. 106793 106794 With this change in place I now see this test fully passing on 32 and 106795 64 bit RISC-V targets. 106796 1067972022-08-16 Simon Marchi <simon.marchi@polymtl.ca> 106798 106799 gdb/testsuite: fix breakpoint script output in gdb.mi/mi-break.exp 106800 Commit 9db0d8536dbc ("gdb/mi: fix breakpoint script field output") fixed 106801 the output of the script key in the MI breakpoint output, from 106802 106803 script={"print 10","continue"} 106804 106805 to 106806 106807 script=["print 10","continue"] 106808 106809 However, it missed updating this test case, which still tests for the 106810 old (broken) form, causing: 106811 106812 FAIL: gdb.mi/mi-break.exp: mi-mode=main: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output) 106813 FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output) 106814 106815 Update the test to expect the new form. 106816 106817 Change-Id: I174919d4eea53e96d914ca9bd1cf6f01c8de30b8 106818 1068192022-08-16 Tom Tromey <tromey@adacore.com> 106820 106821 Use strwinerror in gdb/windows-nat.c 106822 When working on windows-nat.c, it's useful to see an error message in 106823 addition to the error number given by GetLastError. This patch moves 106824 strwinerror from gdbserver to gdbsupport, and then updates 106825 windows-nat.c to use it. A couple of minor changes to strwinerror 106826 (constify the return type and use the ARRAY_SIZE macro) are also 106827 included. 106828 1068292022-08-16 Tom Tromey <tom@tromey.com> 106830 106831 Remove register_gdbarch_init 106832 This removes the deprecated register_gdbarch_init in favor a default 106833 argument to gdbarch_register. Regression tested on x86-64 Fedora 34. 106834 1068352022-08-16 Alan Modra <amodra@gmail.com> 106836 106837 PR29495, rewrite_elf_program_header looping 106838 This patch, in order of significance: 106839 1) Replaces some macros with inline functions. 106840 2) Those inline functions catch and avoid arithmetic overflows when 106841 comparing addresses. 106842 3) When assigning sections to segments (IS_SECTION_IN_INPUT_SEGMENT) 106843 use bed->want_p_paddr_set_to_zero to decide whether lma vs p_paddr 106844 or vma vs p_vaddr should be tested. When remapping, use the same 106845 test, and use is_note rather than the more restrictive 106846 IS_COREFILE_NOTE. 106847 106848 It's important that the later tests not be more restrictive. If they 106849 are it can lead to the situation triggered by the testcases, where a 106850 section seemingly didn't fit and thus needed a new mapping. It didn't 106851 fit the new mapping either, and this repeated until memory exhausted. 106852 106853 PR 29495 106854 * elf.c (SEGMENT_END, SECTION_SIZE, IS_CONTAINED_BY_VMA): Delete. 106855 (IS_CONTAINED_BY_LMA, IS_NOTE, IS_COREFILE_NOTE): Delete. 106856 (segment_size, segment_end, section_size): New inline function. 106857 (is_contained_by, is_note): Likewise. 106858 (rewrite_elf_program_header): Use new functions. 106859 1068602022-08-16 Jan Beulich <jbeulich@suse.com> 106861 106862 x86: shorten certain template names 106863 Now that we can purge templates, let's use this to improve readability a 106864 little by shortening a few of their names, making functionally similar 106865 ones also have identical names in their multiple incarnations. 106866 1068672022-08-16 Jan Beulich <jbeulich@suse.com> 106868 106869 x86: template-ize certain vector conversion insns 106870 Many of the vector conversion insns come with X/Y/Z suffixed forms, for 106871 disambiguation purposes in AT&T syntax. All of these gorups follow 106872 certain patterns. Introduce "xy" and "xyz" templates to reduce 106873 redundancy. 106874 106875 To facilitate using a uniform name for both AVX and AVX512, further 106876 introduce a means to purge a previously defined template: A standalone 106877 <name> will be recognized to have this effect. 106878 106879 Note that in the course of the conversion VFPCLASSPH is properly split 106880 to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D} and 106881 yielding the intended "ambiguous operand size" diagnostic in Intel mode. 106882 1068832022-08-16 Jan Beulich <jbeulich@suse.com> 106884 106885 x86: template-ize vector packed byte/word integer insns 106886 Many of the vector integer insns come in byte/word element pairs. Most 106887 of these pairs follow certain encoding patterns. Introduce a "bw" 106888 template to reduce redundancy. 106889 106890 Note that in the course of the conversion 106891 - the AVX VPEXTRW template which is not being touched needs to remain 106892 ahead of the new "combined" ones, as (a) this should be tried first 106893 when matching insns against templates and (b) its Load attributes 106894 requires it to be first, 106895 - this add a benign/meaningless IgnoreSize attribute to the memory form 106896 of PEXTRB; it didn't seem worth avoiding this. 106897 1068982022-08-16 Jan Beulich <jbeulich@suse.com> 106899 106900 x86: re-order AVX512 S/G templates 106901 The AVX2 gather ones are nicely grouped - do the same for the various 106902 AVX512 scatter/gather ones. On the moved lines also convert EVex=<n> to 106903 EVex<N>. 106904 1069052022-08-16 Jan Beulich <jbeulich@suse.com> 106906 106907 x86: template-ize vector packed dword/qword integer insns 106908 Many of the vector integer insns come in dword/qword element pairs. Most 106909 of these pairs follow certain encoding patterns. Introduce a "dq" 106910 template to reduce redundancy. 106911 106912 Note that in the course of the conversion 106913 - a few otherwise untouched templates are moved, so they end up next to 106914 their siblings), 106915 - drop an unhelpful Cpu64 from the GPR form of VPBROADCASTQ, matching 106916 what we already have for KMOVQ - the diagnostic is better this way for 106917 insns with multiple forms (i.e. the same Cpu64 attributes on {,V}MOVQ, 106918 {,V}PEXTRQ, and {,V}PINSRQ are useful to keep), 106919 - this adds benign/meaningless IgnoreSize attributes to the GPR forms of 106920 KMOVD and VPBROADCASTD; it didn't seem worth avoiding this. 106921 1069222022-08-16 Jan Beulich <jbeulich@suse.com> 106923 106924 x86: template-ize packed/scalar vector floating point insns 106925 The vast majority of vector FP insns comes in single/double pairs. Many 106926 pairs follow certain encoding patterns. Introduce an "sd" template to 106927 reduce redundancy. Similarly, to further cover similarities between 106928 AVX512F and AVX512-FP16, introduce an "sdh" template. 106929 106930 For element-size Disp8 shift generalize i386-gen's broadcast size 106931 determination, allowing Disp8MemShift to be specified without an operand 106932 in the affected templated templates. While doing the adjustment also 106933 eliminate an unhelpful (lost information) diagnostic combined with a use 106934 after free in what is now get_element_size(). 106935 106936 Note that in the course of the conversion 106937 - the AVX512F form of VMOVUPD has a stray (leftover) Load attribute 106938 dropped, 106939 - VMOVSH has a benign IgnoreSize added (the attribute is still strictly 106940 necessary for VMOVSD, and necessary for VMOVSS as long as we permit 106941 strange combinations like "-march=i286+avx"), 106942 - VFPCLASSPH is properly split to separate AT&T and Intel syntax forms, 106943 matching VFPCLASSP{S,D}. 106944 1069452022-08-16 Jan Beulich <jbeulich@suse.com> 106946 106947 revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl" 106948 This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which 106949 broke i386-gen's emitting of diagnostics. As a replacement to address 106950 the original issue of newer gcc no longer splicing lines when dropping 106951 the line continuation backslashes, switch to using + as the line 106952 continuation character, doing the line splicing in i386-gen. 106953 1069542022-08-16 GDB Administrator <gdbadmin@sourceware.org> 106955 106956 Automatic date update in version.in 106957 1069582022-08-15 Alan Modra <amodra@gmail.com> 106959 106960 PR29362, some binutils memory leaks 106961 2022-08-16 Alan Modra <amodra@gmail.com> 106962 Cunlong Li <shenxiaogll@163.com> 106963 106964 PR 29362 106965 * dwarf.c (free_debug_information): New function, extracted.. 106966 (free_debug_memory): ..from here. 106967 (process_debug_info): Use it when before clearing out unit 106968 debug_information. Clear all fields. 106969 * objcopy.c (delete_symbol_htabs): New function. 106970 (main): Call it via xatexit. 106971 (copy_archive): Free "dir". 106972 * objdump.c (free_debug_section): Free reloc_info. 106973 1069742022-08-15 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 106975 106976 gdb/csky add unwinder for sigtramp frame when kernel 4.x and later 106977 When kernel veriosn >= V4.x, the characteristic values used to 106978 determine whether it is a signal function call are: 106979 movi r7, 139 106980 trap 0 106981 106982 Registers are saved at (sp + CSKY_SIGINFO_OFFSET + CSKY_SIGINFO_SIZE 106983 + CSKY_UCONTEXT_SIGCONTEXT + CSKY_SIGCONTEXT_PT_REGS_TLS). The order 106984 is described in csky_linux_rt_sigreturn_init_pt_regs. 106985 1069862022-08-15 Alan Modra <amodra@gmail.com> 106987 106988 aarch64_pei_vec 106989 I know this target is just a skeleton, but let's not write out relocs 106990 with uninitialised garbage. 106991 106992 * coff-aarch64.c (SWAP_IN_RELOC_OFFSET): Define. 106993 (SWAP_OUT_RELOC_OFFSET): Define. 106994 1069952022-08-15 GDB Administrator <gdbadmin@sourceware.org> 106996 106997 Automatic date update in version.in 106998 1069992022-08-14 Andrew Burgess <aburgess@redhat.com> 107000 107001 gdb/riscv: improve a comment about fcsr, fflags, and frm registers 107002 There's a comment in riscv-tdep.c that explains some of the background 107003 about how we check for the fcsr, fflags, and frm registers within a 107004 riscv target description. 107005 107006 This comment (and the functionality it describes) relates to how QEMU 107007 advertises these registers within its target description. 107008 107009 Unfortunately, QEMU includes these three registers in both the fpu and 107010 crs target description features. To work around this GDB uses one of 107011 the register declarations, and ignores the other, this means the GDB 107012 user sees a single copy of each register, and things just work. 107013 107014 When I originally wrote the comment I thought it didn't matter which 107015 copy of the register GDB selected, the fpu copy or the csr copy, so 107016 long as we just used one of them. The comment reflected this belief. 107017 107018 Upon further investigation, it turns out I was wrong. GDB has to use 107019 the csr copy of the register. If GDB tries to use the register from 107020 the fpu feature then QEMU will return an error when GDB tries to read 107021 or write the register. 107022 107023 Luckily, the code within GDB (currently) will always select the csr 107024 copy of the register, so nothing is broken, but the comment is wrong. 107025 This commit updates the comment to better describe what is actually 107026 going on. 107027 107028 Of course, I should probably also send a patch to QEMU to fix up the 107029 target description that is sent to GDB. 107030 1070312022-08-14 Andrew Burgess <aburgess@redhat.com> 107032 107033 gdb/nds32: update features/nds32.c 107034 After this commit: 107035 107036 commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921 107037 Date: Wed Sep 15 10:10:46 2021 +0200 107038 107039 [bfd] Ensure unique printable names for bfd archs 107040 107041 The printable name field of the default nds32 bfd_arch_info changed 107042 from 'n1h' to 'n1'. As a consequence the generated feature file 107043 within GDB should have been recreated. Recreate it now. 107044 1070452022-08-14 Tom Tromey <tom@tromey.com> 107046 107047 Move decode_location_spec to code_breakpoint 107048 breakpoint::decode_location_spec just asserts if called. It turned 107049 out to be relatively easy to remove this method from breakpoint and 107050 instead move the base implementation to code_breakpoint. 107051 107052 Change location_spec_to_sals to a method 107053 location_spec_to_sals is only ever called for code breakpoints, so 107054 make it a protected method there. 107055 107056 Change breakpoint_re_set_default to a method 107057 breakpoint_re_set_default is only ever called from breakpoint re_set 107058 methods, so make it a protected method on code_breakpoint. 107059 1070602022-08-14 GDB Administrator <gdbadmin@sourceware.org> 107061 107062 Automatic date update in version.in 107063 1070642022-08-13 Alan Modra <amodra@gmail.com> 107065 107066 PR29482 - strip: heap-buffer-overflow 107067 PR 29482 107068 * coffcode.h (coff_set_section_contents): Sanity check _LIB. 107069 107070 asan: NULL dereference in spu_elf_object_p 107071 * elf32-spu.c (spu_elf_object_p): Don't dereference NULL 107072 shdr->bfd_section. 107073 107074 ubsan: undefined shift in sign_extend 107075 * libhppa.h (sign_extend): Avoid undefined behaviour. 107076 107077 asan: NULL dereference in som_set_reloc_info 107078 * som.c (som_set_reloc_info): Ignore non-existent previous 107079 fixup references. 107080 107081 readelf: print 0x0 as 0, and remove trailing spaces 107082 This changes readelf output a little, removing the 0x prefix on hex 107083 output when the value is 0, except in cases where a fixed field 107084 width is shown. %#010x is not a good replacement for 0x%08x. 107085 107086 Make dwarf_vma uint64_t 107087 This replaces dwarf_vma, dwarf_size_type and dwarf_signed_vma with 107088 uint64_t and int64_t everywhere. The patch also gets rid of 107089 DWARF_VMA_FMT since we can't use that with uint64_t, and all of the 107090 configure support for deciding the flavour of HOST_WIDEST_INT. 107091 dwarf_vmatoa also disappears, replacing most uses with one of 107092 PRIx64, PRId64 or PRIu64. Printing of size_t and ptrdiff_t values 107093 now use %z and %t rather than by casting to unsigned long. Also, 107094 most warning messages that used 0x%lx or similar now use %#lx and a 107095 few that didn't print the 0x hex prefix now also use %#. The patch 107096 doesn't change normal readelf output, except in odd cases where values 107097 previously might have been truncated. 107098 107099 Don't use bfd_vma in readelf.c 107100 This replaces bfd_vma with uint64_t in readelf, defines BFD64 107101 unconditionally, removes tests of BFD64 and sizeof (bfd_vma), and 107102 removes quite a few now unnecessary casts. 107103 107104 Don't use bfd_size_type in readelf.c and dwarf.c 107105 Replacing bfd_size_type with dwarf_size_type or uint64_t is mostly 107106 cosmetic. The point of the change is to avoid use of a BFD type 107107 in readelf, where we'd like to keep as independent of BFD as 107108 possible. Also, the patch is a step towards using standard types. 107109 107110 Replace elf_vma with uint64_t 107111 This patch replaces all uses of elf_vma with uint64_t, removes 107112 tests of sizeof (elf_vma), and does a little tidying of 107113 byte_get_little_endian and byte_get_big_endian. 107114 1071152022-08-13 GDB Administrator <gdbadmin@sourceware.org> 107116 107117 Automatic date update in version.in 107118 1071192022-08-12 Tom de Vries <tdevries@suse.de> 107120 107121 [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp 107122 When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we 107123 have: 107124 ... 107125 (gdb) break compdir_missing__ldir_missing__file_basename^M 107126 Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M 107127 (gdb) continue^M 107128 Continuing.^M 107129 ^M 107130 Breakpoint 2, 0x00000000004004c4 in \ 107131 compdir_missing__ldir_missing__file_basename () \ 107132 at tmp-dw2-dir-file-name.c:999^M 107133 (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ 107134 compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ 107135 compdir_missing__ldir_missing__file_basename 107136 ... 107137 107138 When trying to set a breakpoint on 107139 compdir_missing__ldir_missing__file_basename, the architecture-specific 107140 prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4: 107141 ... 107142 00000000004004c0 <compdir_missing__ldir_missing__file_basename>: 107143 4004c0: 55 push %rbp 107144 4004c1: 48 89 e5 mov %rsp,%rbp 107145 4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v> 107146 4004ca: 83 c0 01 add $0x1,%eax 107147 4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v> 107148 4004d3: 90 nop 107149 4004d4: 5d pop %rbp 107150 4004d5: c3 ret 107151 ... 107152 107153 And because the line table info is rudamentary: 107154 ... 107155 CU: tmp-dw2-dir-file-name.c: 107156 File name Line number Starting address View Stmt 107157 tmp-dw2-dir-file-name.c 999 0x4004c0 x 107158 tmp-dw2-dir-file-name.c 1000 0x4004d6 x 107159 tmp-dw2-dir-file-name.c - 0x4004d6 107160 ... 107161 the address does not fall at an actual line, so the breakpoint is shown with 107162 address, both when setting it and hitting it. 107163 107164 when running the test-case with aarch64-linux, we have similarly: 107165 ... 107166 (gdb) break compdir_missing__ldir_missing__file_basename^M 107167 Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M 107168 ... 107169 due to the architecture-specific prologue skipper starting at 0x400610 and 107170 skipping past two insns, to 0x400618: 107171 ... 107172 0000000000400610 <compdir_missing__ldir_missing__file_basename>: 107173 400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17> 107174 400614: 9100b000 add x0, x0, #0x2c 107175 400618: b9400000 ldr w0, [x0] 107176 40061c: 11000401 add w1, w0, #0x1 107177 400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17> 107178 400624: 9100b000 add x0, x0, #0x2c 107179 400628: b9000001 str w1, [x0] 107180 40062c: d503201f nop 107181 400630: d65f03c0 ret 107182 ... 107183 107184 But interestingly, the aarch64 architecture-specific prologue skipper is 107185 wrong. There is no prologue, and the breakpoint should be set at 0x400610. 107186 107187 By using "break *compdir_missing__ldir_missing__file_basename" 107188 we can get the breakpoint set at 0x400610: 107189 ... 107190 (gdb) break *compdir_missing__ldir_missing__file_basename^M 107191 Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M 107192 ... 107193 and make the test-case independent of prologue analysis. 107194 107195 This requires us to update the expected patterns. 107196 107197 The fix ensures that once the aarch64 architecture-specific prologue skipper 107198 will be fixed, this test-case won't start failing. 107199 107200 Tested on x86_64-linux. 107201 1072022022-08-12 GDB Administrator <gdbadmin@sourceware.org> 107203 107204 Automatic date update in version.in 107205 1072062022-08-11 Lancelot SIX <lancelot.six@amd.com> 107207 107208 gdb/varobj: Only re-evaluate invalid globals during re_set 107209 When doing varobj_re_set, we currently try to recreate floating varobj. 107210 This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part 107211 of varobj_invalidate" to deal with use a after free issue. However 107212 since bc20e562ec0 "Fix use after free in varobj" we now ensure that we 107213 never have dangling pointers so this all recreation is not strictly 107214 needed anymore for floating varobjs. 107215 107216 This commit proposes to remove this recreation process for floating 107217 varobjs. 107218 107219 Tested on x86_64-linux. 107220 1072212022-08-11 Tom de Vries <tdevries@suse.de> 107222 Lancelot SIX <lancelot.six@amd.com> 107223 107224 gdb/varobj: Reset varobj after relocations have been computed 107225 [This patch is a followup to the discussion in 107226 https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html] 107227 107228 PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib 107229 test when using a compiler which does not produce a PIE executable by 107230 default. 107231 107232 In the testcase, a varobj is created to track a global variable, and 107233 then the main binary is reloaded in GDB (using the file command). 107234 107235 During the load of the new binary, GDB tries to recreate the varobj to 107236 track the global in the new binary (varobj_invalidate_iter). At this 107237 point, the old process is still in flight. So when we try to access to 107238 the value of the global, in a PIE executable we only have access to the 107239 unrelocated address (the objfile's text_section_offset () is 0). As a 107240 consequence down the line read_value_memory fails to read the unrelated 107241 address, so cannot evaluate the value of the global. Note that the 107242 expression used to access to the global’s value is valid, so the varobj 107243 can be created. When using a non PIE executable, the address of the 107244 global GDB knows about at this point does not need relocation, so 107245 read_value_memory can access the (old binary’s) value. 107246 107247 So at this point, in the case of a non-PIE executable the value field is 107248 set, while it is cleared in the case of PIE executable. Later when the 107249 test issues a "-var-update global_var", the command sees no change in 107250 the case of the non-PIE executable, while in the case of the PIE 107251 executable install_new_value sees that value changes, leading to a 107252 different output. 107253 107254 This patch makes sure that, as we do for breakpoints, we wait until 107255 relocation has happened before we try to recreate varobjs. This way we 107256 have a consistent behavior between PIE and non-PIE binaries. 107257 107258 Tested on x86_64-linux. 107259 107260 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 107261 1072622022-08-11 Lancelot SIX <lancelot.six@amd.com> 107263 107264 gdb/varobj: Do not invalidate locals in varobj_invalidate_iter 107265 The varobj_invalidate_iter function has logic to invalidate any local 107266 varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use 107267 after free in varobj" all varobj containing references to an objfile are 107268 cleared when the objfile goes out of scope. This means that at this 107269 point any local varobj seen by varobj_invalidate_iter either has 107270 already been invalidated by varobj_invalidate_if_uses_objfile or only 107271 contains valid references and there is no reason to invalidate it. 107272 107273 This patch proposes to remove this unnecessary invalidation and adds a 107274 testcase which exercises a scenario where a local varobj can legitimately 107275 survive a call to varobj_invalidate_iter. 107276 107277 At this point the varobj_invalidate and varobj_invalidate_iter seem 107278 misnamed since they deal with re-creating invalid objects and do not do 107279 invalidation, but this will be fixed in a following patch. 107280 107281 Tested on x86_64-linux. 107282 1072832022-08-11 Dmitry Selyutin <ghostmansd@gmail.com> 107284 107285 ppc/svp64: support svindex instruction 107286 https://libre-soc.org/openpower/sv/ 107287 https://libre-soc.org/openpower/sv/remap/#svindex 107288 https://libre-soc.org/openpower/isa/simplev/ 107289 107290 ppc/svp64: support svremap instruction 107291 https://libre-soc.org/openpower/sv/ 107292 https://libre-soc.org/openpower/sv/remap/#svremap 107293 https://libre-soc.org/openpower/isa/simplev/ 107294 107295 ppc/svp64: support svshape instruction 107296 https://libre-soc.org/openpower/sv/ 107297 https://libre-soc.org/openpower/sv/remap/#svshape 107298 https://libre-soc.org/openpower/isa/simplev/ 107299 107300 ppc/svp64: support svstep instructions 107301 https://libre-soc.org/openpower/sv/ 107302 https://libre-soc.org/openpower/sv/svstep/ 107303 https://libre-soc.org/openpower/isa/simplev/ 107304 107305 ppc/svp64: support setvl instructions 107306 https://libre-soc.org/openpower/sv/ 107307 https://libre-soc.org/openpower/sv/setvl/ 107308 https://libre-soc.org/openpower/isa/simplev/ 107309 107310 ppc/svp64: introduce non-zero operand flag 107311 svstep and svshape instructions subtract 1 before encoding some of the 107312 operands. Obviously zero is not supported for these operands. Whilst 107313 PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be 107314 incremented, there is no flag which marks the fact that zero values are 107315 not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this 107316 purpose. 107317 1073182022-08-11 Dmitry Selyutin <ghostmansd@gmail.com> 107319 107320 ppc/svp64: support LibreSOC architecture 107321 This patch adds support for LibreSOC machine and SVP64 extension flag 107322 for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm 107323 Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit 107324 Prefixed instruction format implementing SV. Funded by NLnet through EU 107325 Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly 107326 submitted via the OpenPOWER Foundation ISA Working Group via the 107327 newly-created External RFC Process. 107328 107329 For more details, visit https://libre-soc.org. 107330 1073312022-08-11 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 107332 107333 [Arm] Cleanup arm_m_exception_cache 107334 With this change, only valid contents of LR are accepted when unwinding 107335 exception frames for m-profile targets. 107336 107337 If the contents of LR are anything but EXC_RETURN or FNC_RETURN, it 107338 will cause GDB to print an error and/or abort unwinding of the frame as 107339 it's an invalid state for the unwinder. 107340 107341 The FNC_RETURN pattern requires Security Extensions to be enabled. 107342 1073432022-08-11 Fangrui Song <maskray@google.com> 107344 107345 RISC-V: Remove R_RISCV_GNU_VTINHERIT/R_RISCV_GNU_VTENTRY 107346 They were legacy relocation types copied from other ports. The related 107347 -fvtable-gc was removed from GCC in 2003. 107348 107349 The associated assembler directives (.vtable_inherit and .vtable_entry) 107350 have never been supported by the RISC-V port. Remove related ld code. 107351 107352 Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/323 107353 1073542022-08-11 Alan Modra <amodra@gmail.com> 107355 107356 PR29466, APP/NO_APP with .linefile 107357 Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could 107358 result in losing input. If scrubbing results in expansion past the 107359 holding capacity of do_scrub_chars output buffer, then do_scrub_chars 107360 stashes the extra input for the next call. That call never came 107361 because sb_scrub_and_add_sb wrongly decided it was done. Fix that by 107362 allowing sb_scrub_and_add_sb to see whether there is pending input. 107363 Also allow a little extra space so that in most cases we won't need 107364 to resize the output buffer. 107365 107366 sb_scrub_and_add_sb also limited output to the size of the input, 107367 rather than the actual output buffer size. Fixing that resulted in a 107368 fail of gas/testsuite/macros/dot with an extra warning: "end of file 107369 not at end of a line; newline inserted". OK, so the macro in dot.s 107370 really does finish without end-of-line. Apparently the macro 107371 expansion code relied on do_scrub_chars returning early. So fix that 107372 too by adding a newline if needed in macro_expand_body. 107373 107374 PR 29466 107375 * app.c (do_scrub_pending): New function. 107376 * as.h: Declare it. 107377 * input-scrub.c (input_scrub_include_sb): Add extra space for 107378 two .linefile directives. 107379 * sb.c (sb_scrub_and_add_sb): Take into account pending input. 107380 Allow output to max. 107381 * macro.c (macro_expand_body): Add terminating newline. 107382 * testsuite/config/default.exp (SIZE, SIZEFLAGS): Define. 107383 * testsuite/gas/macros/app5.d, 107384 * testsuite/gas/macros/app5.s: New test. 107385 * testsuite/gas/macros/macros.exp: Run it. 107386 1073872022-08-11 Alan Modra <amodra@gmail.com> 107388 107389 regen potfiles 107390 1073912022-08-11 GDB Administrator <gdbadmin@sourceware.org> 107392 107393 Automatic date update in version.in 107394 1073952022-08-10 Simon Marchi <simon.marchi@polymtl.ca> 107396 107397 gdb/mi: fix breakpoint script field output 107398 The "script" field, output whenever information about a breakpoint with 107399 commands is output, uses wrong MI syntax. 107400 107401 $ ./gdb -nx -q --data-directory=data-directory -x script -i mi 107402 =thread-group-added,id="i1" 107403 =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"} 107404 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"} 107405 (gdb) 107406 -break-info 107407 ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]} 107408 (gdb) 107409 107410 In both the =breakpoint-modified and -break-info output, we have: 107411 107412 script={"aaa","bbb","ccc"} 107413 107414 According to the output syntax [1], curly braces means tuple, and a 107415 tuple contains key=value pairs. This looks like it should be a list, 107416 but uses curly braces by mistake. This would make more sense: 107417 107418 script=["aaa","bbb","ccc"] 107419 107420 Fix it, keeping the backwards compatibility by introducing a new MI 107421 version (MI4), in exactly the same way as was done when fixing 107422 multi-locations breakpoint output in [2]. 107423 107424 - Add a fix_breakpoint_script_output uiout flag. MI uiouts will use 107425 this flag if the version is >= 4. 107426 - Add a fix_breakpoint_script_output_globally variable and the 107427 -fix-breakpoint-script-output MI command to set it, if frontends want 107428 to use the fixed output for this without using the newer MI version. 107429 - When emitting the script field, use list instead of tuple, if we want 107430 the fixed output (depending on the two criteria above) 107431 - 107432 107433 [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax 107434 [2] https://gitlab.com/gnutools/binutils-gdb/-/commit/b4be1b0648608a2578bbed39841c8ee411773edd 107435 107436 Change-Id: I7113c6892832c8d6805badb06ce42496677e2242 107437 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285 107438 1074392022-08-10 Andrew Burgess <aburgess@redhat.com> 107440 107441 objdump: fix extended (256) disassembler colors 107442 After commit: 107443 107444 commit a88c79b77036e4778e70d62081c3cfd1044bb8e3 107445 Date: Tue Aug 9 14:57:48 2022 +0100 107446 107447 Default to enabling colored disassembly if output is to a terminal. 107448 107449 The 256 extended-color support for --disassembler-color was broken. 107450 This is fixed in this commit. 107451 107452 PR 29457 107453 * objdump (objdump_styled_sprintf): Check disassembler_color 107454 against an enum value, don't treat it as a bool. 107455 1074562022-08-10 mga-sc <mark.goncharov@syntacore.com> 107457 107458 gdb/riscv: implement cannot_store_register gdbarch method 107459 The x0 (zero) register is read-only on RISC-V. Implement the 107460 cannot_store_register gdbarch method to tell GDB this. 107461 107462 Without this method GDB will try to write to x0, and relies on the 107463 target to ignore such writes. If you are using a target that 107464 complains (or throws an error) when writing to x0, this change will 107465 prevent this from happening. 107466 107467 The gdb.arch/riscv-reg-aliases.exp test exercises writing to x0, and 107468 will show the errors when using a suitable target. 107469 1074702022-08-10 Luis Machado <luis.machado@arm.com> 107471 107472 Disable year 2038 support on 32-bit hosts by default 107473 With a recent import of gnulib, code has been pulled that tests and enables 107474 64-bit time_t by default on 32-bit hosts that support it. 107475 107476 Although gdb can use the gnulib support, bfd doesn't use gnulib and currently 107477 doesn't do these checks. 107478 107479 As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll 107480 have a mismatch between gdb's notion of time_t and bfd's notion of time_t. 107481 107482 This will lead to mismatches in the struct stat size, leading to memory 107483 corruption and crashes. 107484 107485 This patch disables the year 2038 check for now, which makes things work 107486 reliably again. 107487 107488 I'd consider this a temporary fix until we have proper bfd checks for the year 107489 2038, if it makes sense. 64-bit hosts seems to be more common these days, so 107490 I'm not sure how important it is to have this support enabled and how soon 107491 we want to enable it. 107492 107493 Thoughts? 107494 1074952022-08-10 Jan Beulich <jbeulich@suse.com> 107496 107497 gas/Dwarf: properly skip zero-size functions 107498 PR gas/29451 107499 107500 While out_debug_abbrev() properly skips such functions, out_debug_info() 107501 mistakenly didn't. It needs to calculate the high_pc expression ahead of 107502 time, in order to skip emitting any data for the function if the value 107503 is zero. 107504 107505 The one case which would still leave a zero-size entry is when 107506 symbol_get_obj(symp)->size ends up evaluating to zero. I hope we can 107507 expect that to not be the case, otherwise we'd need to have a way to 107508 post-process .debug_info contents between resolving expressions and 107509 actually writing the data out to the file. Even then it wouldn't be 107510 entirely obvious in which way to alter the data. 107511 1075122022-08-10 Alan Modra <amodra@gmail.com> 107513 107514 PR29462, internal error in relocate, at powerpc.cc:10796 107515 Prior to the inline plt call support (commit 08be322439), the only 107516 local syms with plt entries were local ifunc symbols. There shouldn't 107517 be stubs for other local symbols so don't look for them. The patch 107518 also fixes minor bugs in get_reference_flags; Many relocs are valid 107519 only for ppc64 and a couple only for ppc32. 107520 107521 PR 29462 107522 * powerpc.cc (Target_powerpc::Relocate::relocate): Rename 107523 use_plt_offset to pltcal_to_direct, invert logic. For relocs 107524 not used with inline plt sequences against local symbols, only 107525 look for stubs when the symbol is an ifunc. 107526 (Target_powerpc::Scan::get_reference_flags): Correct reloc 107527 handling for relocs not valid for both 32-bit and 64-bit. 107528 1075292022-08-10 Youling Tang <tangyouling@loongson.cn> 107530 107531 bfd: Add support for LoongArch64 EFI (efi-*-loongarch64). 107532 This adds support for efi-loongarch64 by virtue of adding a new PEI target 107533 pei-loongarch64. This is not a full target and only exists to support EFI at 107534 this time. 107535 107536 This means that this target does not support relocation processing and is mostly 107537 a container format. This format has been added to elf based loongarch64 targets 107538 such that efi images can be made natively on Linux. 107539 107540 However this target is not valid for use with gas but only with objcopy. 107541 107542 We should't limit addresses to 32-bits for 64-bit vma, otherwise there will be 107543 "RVA truncated" error when using objcopy on loongarch64. 107544 107545 With these changes the resulting file is recognized as an efi image. 107546 107547 Any magic number is based on the Microsoft PE specification [1]. 107548 107549 The test results are as follows: 107550 $ make check-binutils RUNTESTFLAGS='loongarch64.exp' 107551 PASS: Check if efi app format is recognized 107552 107553 $ objdump -h -f tmpdir/loongarch64copy.o 107554 tmpdir/loongarch64copy.o: file format pei-loongarch64 107555 architecture: Loongarch64, flags 0x00000132: 107556 EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED 107557 start address 0x0000000000000000 107558 107559 Sections: 107560 Idx Name Size VMA LMA File off Algn 107561 0 .text 0000003c 00000000200000b0 00000000200000b0 00000200 2**2 107562 CONTENTS, ALLOC, LOAD, READONLY, CODE 107563 107564 [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format 107565 107566 bfd: 107567 * .gitignore (pe-loongarch64igen.c): New. 107568 * Makefile.am (pei-loongarch64.lo, pe-loongarch64igen.lo, pei-loongarch64.c, 107569 pe-loongarch64igen.c): Add support. 107570 * Makefile.in: Likewise. 107571 * bfd.c (bfd_get_sign_extend_vma): Add pei-loongarch64. 107572 * coff-loongarch64.c: New file. 107573 * coffcode.h (coff_set_arch_mach_hook, coff_set_flags, 107574 coff_write_object_contents) Add loongarch64 (loongarch64_pei_vec) support. 107575 * config.bfd: Likewise. 107576 * configure: Likewise. 107577 * configure.ac: Likewise. 107578 * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE, 107579 GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE, 107580 GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT, 107581 GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE, 107582 GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT, 107583 GET_PDATA_ENTRY, _bfd_peLoongArch64_bfd_copy_private_bfd_data_common, 107584 _bfd_peLoongArch64_bfd_copy_private_section_data, 107585 _bfd_peLoongArch64_get_symbol_info, _bfd_peLoongArch64_only_swap_filehdr_out, 107586 _bfd_peLoongArch64_print_private_bfd_data_common, 107587 _bfd_peLoongArch64i_final_link_postscript, 107588 _bfd_peLoongArch64i_only_swap_filehdr_out, _bfd_peLoongArch64i_swap_aouthdr_in, 107589 _bfd_peLoongArch64i_swap_aouthdr_out, _bfd_peLoongArch64i_swap_aux_in, 107590 _bfd_peLoongArch64i_swap_aux_out, _bfd_peLoongArch64i_swap_lineno_in, 107591 _bfd_peLoongArch64i_swap_lineno_out, _bfd_peLoongArch64i_swap_scnhdr_out, 107592 _bfd_peLoongArch64i_swap_sym_in, _bfd_peLoongArch64i_swap_sym_out, 107593 _bfd_peLoongArch64i_swap_debugdir_in, _bfd_peLoongArch64i_swap_debugdir_out, 107594 _bfd_peLoongArch64i_write_codeview_record, 107595 _bfd_peLoongArch64i_slurp_codeview_record, 107596 _bfd_peLoongArch64_print_ce_compressed_pdata): New. 107597 * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out, 107598 _bfd_XXi_swap_scnhdr_out, pe_print_pdata, _bfd_XX_print_private_bfd_data_common, 107599 _bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript): 107600 Support COFF_WITH_peLoongArch64, 107601 * pei-loongarch64.c: New file. 107602 * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p): 107603 Support COFF_WITH_peLoongArch64. 107604 (jtab): Add dummy entry that traps. 107605 * targets.c (loongarch64_pei_vec): New. 107606 107607 binutils 107608 * testsuite/binutils-all/loongarch64/loongarch64.exp: New file. 107609 * testsuite/binutils-all/loongarch64/pei-loongarch64.d: New test. 107610 * testsuite/binutils-all/loongarch64/pei-loongarch64.s: New test. 107611 107612 include 107613 * coff/loongarch64.h: New file. 107614 * coff/pe.h (IMAGE_FILE_MACHINE_LOONGARCH64): New. 107615 1076162022-08-10 GDB Administrator <gdbadmin@sourceware.org> 107617 107618 Automatic date update in version.in 107619 1076202022-08-09 Andrew Burgess <aburgess@redhat.com> 107621 107622 gdb/riscv/testsuite: fix failures in gdb.arch/riscv-reg-aliases.exp 107623 When running on a native RISC-V Linux target I currently see failures 107624 in the gdb.arch/riscv-reg-aliases.exp test like this: 107625 107626 set $ft0.float = 501 107627 (gdb) PASS: gdb.arch/riscv-reg-aliases.exp: write non-zero value to ft0 107628 p/d $ft0.float 107629 $263 = 1140490240 107630 (gdb) FAIL: gdb.arch/riscv-reg-aliases.exp: read ft0 after non-zero write to ft0 107631 107632 This test started failing after this commit: 107633 107634 commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e 107635 Date: Thu Feb 17 13:43:59 2022 -0700 107636 107637 Change how "print/x" displays floating-point value 107638 107639 The problem is that when 501 is written to $ft0.float the value is 107640 converted to floating point format and stored in the register. Prior 107641 to the above commit printing with /x and /d would first extract the 107642 value as a float, and then convert the value to an integer for 107643 display. After the above commit GDB now uses the raw register value 107644 when displaying /x and /d, and so we see this behaviour: 107645 107646 (gdb) info registers $ft0 107647 ft0 {float = 501, double = 5.6347704700123827e-315} (raw 0x0000000043fa8000) 107648 (gdb) p/f $ft0.float 107649 $1 = 501 107650 (gdb) p/d $ft0.float 107651 $2 = 1140490240 107652 (gdb) p/x $ft0.float 107653 $3 = 0x43fa8000 107654 107655 To fix this test I now print the float registers using the /f format 107656 rather than /d. With this change the test now passes. 107657 1076582022-08-09 Stepan Nemec <stepnem@gmail.com> 107659 107660 Another gas manual typo correction. 107661 107662 Fix typos in assembler documentation. 107663 1076642022-08-09 Feiyang Chen <chenfeiyang@loongson.cn> 107665 107666 gdb/gdbserver: LoongArch: Improve implementation of fcc registers 107667 The current implementation of the fcc register is referenced to the 107668 user_fp_state structure of the kernel uapi [1]. 107669 107670 struct user_fp_state { 107671 uint64_t fpr[32]; 107672 uint64_t fcc; 107673 uint32_t fcsr; 107674 }; 107675 107676 But it is mistakenly defined as a 64-bit fputype register, resulting 107677 in a confusing output of "info register". 107678 107679 (gdb) info register 107680 ... 107681 fcc {f = 0x0, d = 0x0} {f = 0, d = 0} 107682 ... 107683 107684 According to "Condition Flag Register" in "LoongArch Reference Manual" 107685 [2], there are 8 condition flag registers of size 1. Use 8 registers of 107686 uint8 to make it easier for users to view the fcc register groups. 107687 107688 (gdb) info register 107689 ... 107690 fcc0 0x1 1 107691 fcc1 0x0 0 107692 fcc2 0x0 0 107693 fcc3 0x0 0 107694 fcc4 0x0 0 107695 fcc5 0x0 0 107696 fcc6 0x0 0 107697 fcc7 0x0 0 107698 ... 107699 107700 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h 107701 [2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register 107702 1077032022-08-09 Nick Clifton <nickc@redhat.com> 107704 107705 Default to enabling colored disassembly if output is to a terminal. 107706 PR 29457 107707 * objdump.c (disassembler_color): Change type to an enum. 107708 (disassembler_extended_color): Remove. 107709 (usage): Update. 107710 (objdump_color_for_assembler_style): Update. 107711 (main): Update initialisation of disassembler_color. If not 107712 initialised via a command line option, set based upon terminal 107713 output. 107714 * doc/binutils.texi: Update description of disassmbler-color 107715 option. 107716 * testsuite/binutils-all/arc/objdump.exp: Add 107717 --disassembler-color=off option when disassembling. 107718 * testsuite/binutils-all/arm/objdump.exp: Likewise. 107719 1077202022-08-09 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com> 107721 107722 Fix-for-multiple-thread-detection-in-AIX. 107723 In AIX multiple threads were not added. This patch is a fix for the same 107724 107725 When we create a pthread debug session we have callbacks to read 107726 symbols and memory. One of those call backs is pdc_read_data. 107727 107728 Before we come into aix-thread wait() we switch to no thread and 107729 therefore the current thread is null. 107730 107731 When we get into pdc_read_data we have a dependency that we need to 107732 be in the correct current thread that has caused an event of new 107733 thread, inorder to read memory. 107734 107735 Hence we switch to the correct thread. 107736 107737 This is done by passing the pid in the pthdb_user_t user_current_pid 107738 parameter in every call back. 107739 1077402022-08-09 Tom de Vries <tdevries@suse.de> 107741 107742 [gdb/testsuite] Fix gdb.dwarf2/debug-names.exp 107743 When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I 107744 run into: 107745 ... 107746 (gdb) maint info symtabs^M 107747 ... 107748 ERROR: internal buffer is full. 107749 UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab 107750 ... 107751 107752 Fix this by simplifying the test-case to print _start rather running to it. 107753 107754 Tested on x86_64-linux. 107755 1077562022-08-09 Andrew Burgess <aburgess@redhat.com> 107757 107758 gdb/riscv: use register name enum values in riscv-linux-nat.c 107759 There were a few places where we were using integer values rather than 107760 the RISCV_*_REGNUM constants defined in riscv-tdep.h. This commit 107761 replaces 0 with RISCV_ZERO_REGNUM and 32 with RISCV_PC_REGNUM in a few 107762 places. 107763 107764 There should be no user visible changes after this commit. 107765 1077662022-08-09 Jan Beulich <jbeulich@suse.com> 107767 107768 x86-64: adjust MOVQ to/from SReg attributes 107769 It is unclear to me why the corresponding MOV (no Q suffix) can be 107770 issued without REX.W, but MOVQ has to have that prefix (bit). Add 107771 NoRex64 and in exchange drop Size64. 107772 107773 x86: adjust MOVSD attributes 107774 The non-SSE2AVX form of the SIMD variant of the instruction needlessly 107775 has the (still multi-purpose) IgnoreSize attribute. All other similar 107776 SSE2 insns use NoRex64 instead. Make this consistent, noting that the 107777 SSE2AVX form can't have the same change made - there the memory operand 107778 doesn't at the same time permit RegXMM (which logic uses when deciding 107779 whether a Q suffix is okay outside of 64-bit mode). 107780 107781 x86: fold AVX VGATHERDPD / VPGATHERDQ 107782 While the other three variants each differ in attributes and hence can't 107783 be folded, these two pairs actually can be (and were previously 107784 overlooked). This effectively matches their AVX512VL counterparts, which 107785 are also expressed as a single template. 107786 107787 x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insns 107788 While the x/y/z suffix isn't necessary to use in this case, it is still 107789 odd that these forms don't support broadcast (unlike their AVX512F / 107790 AVX512DQ counterparts). The lack thereof can e.g. make macro-ized 107791 programming more difficult. 107792 107793 x86/Intel: split certain AVX512-FP16 VCVT*2PH templates 107794 One more place where pre-existing templates should have been taken as a 107795 basis: In Intel syntax we want to consistently issue an "ambiguous 107796 operand size" error when a size-less memory operand is specified for an 107797 insn where register use alone isn't sufficient for disambiguation. 107798 1077992022-08-09 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 107800 107801 gdb/csky fix build error in ubuntu20_04 107802 build error in: https://builder.sourceware.org/buildbot/#/builders/170/builds/246 107803 ... 107804 ../../binutils-gdb/gdb/csky-linux-tdep.c: In function ‘void 107805 csky_supply_fregset(const regset*, regcache*, int, const void*, size_t)’: 107806 ../../binutils-gdb/gdb/csky-linux-tdep.c:194:18: error: format ‘%ld’ 107807 expects argument of type ‘long int’, but argument 2 has type ‘size_t’ 107808 {aka ‘unsigned int’} [-Werror=format=] 107809 194 | warning (_("Unknow size %ld of section .reg2, can not get 107810 value" 107811 | 107812 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 107813 195 | " of float registers."), len); 107814 ... 107815 107816 Fix it via using %s vs pulongest suggested by Tom. 107817 1078182022-08-09 GDB Administrator <gdbadmin@sourceware.org> 107819 107820 Automatic date update in version.in 107821 1078222022-08-08 Tom Tromey <tromey@adacore.com> 107823 107824 Fix regression from gdbarch registry change 107825 The gdbarch registry patch introduced a regression that could cause a 107826 crash when opening files in gdb. The bug is that, previously, the 107827 solib ops would default to current_target_so_ops; but the patch 107828 changed this code to default to nullptr. This patch fixes the bug by 107829 reintroducing the earlier behavior. This is PR gdb/29449. 107830 107831 I managed to reproduce the bug with a riscv-elf build and then 107832 verified that this fixes the problem. 107833 107834 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29449 107835 1078362022-08-08 Martin Liska <mliska@suse.cz> 107837 107838 add splay tree for info_ptr -> CU mapping 107839 While using perf top for MozillaThunderbird I noticed quite some slow 107840 dissably call with source code involved. E.g. 107841 107842 time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C /usr/lib64/thunderbird/libxul.so 107843 107844 took 2.071s and I noticed quite some time is spent in 107845 find_abstract_instance: 107846 107847 33.46% objdump objdump [.] find_abstract_instance 107848 18.22% objdump objdump [.] arange_add 107849 13.77% objdump objdump [.] read_attribute_value 107850 4.82% objdump objdump [.] comp_unit_maybe_decode_line_info 107851 3.10% objdump libc.so.6 [.] __memset_avx2_unaligned_erms 107852 107853 where linked list of CU is iterated when searing for where info_ptr 107854 belongs to: 107855 107856 : 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit) 107857 0.00 : 4c61f7: mov 0x10(%rbx),%rax 107858 0.00 : 4c61fb: test %rax,%rax 107859 0.00 : 4c61fe: je 4c6215 <find_abstract_instance+0x365> 107860 : 3453 if (info_ptr >= u->info_ptr_unit && info_ptr < u->end_ptr) 107861 0.00 : 4c6200: cmp 0x60(%rax),%rdx 107862 83.20 : 4c6204: jb 4c620c <find_abstract_instance+0x35c> 107863 0.00 : 4c6206: cmp 0x78(%rax),%rdx 107864 6.89 : 4c620a: jb 4c6270 <find_abstract_instance+0x3c0> 107865 : 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit) 107866 0.00 : 4c620c: mov 0x10(%rax),%rax 107867 7.90 : 4c6210: test %rax,%rax 107868 0.00 : 4c6213: jne 4c6200 <find_abstract_instance+0x350> 107869 107870 The following scan can be replaced with search in a splay tree and with 107871 that I can get to 1.5s and there are other symbols where the difference 107872 is even bigger. 107873 107874 bfd/ChangeLog: 107875 107876 PR 29081 107877 * dwarf2.c (struct addr_range): New. 107878 (addr_range_intersects): Likewise. 107879 (splay_tree_compare_addr_range): Likewise. 107880 (splay_tree_free_addr_range): Likewise. 107881 (struct dwarf2_debug_file): Add comp_unit_tree. 107882 (find_abstract_instance): Use the splay tree when searching 107883 for a info_ptr. 107884 (stash_comp_unit): Insert to the splay tree. 107885 (_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree. 107886 1078872022-08-08 Martin Liska <mliska@suse.cz> 107888 107889 dwarf: use find_abstract_instance for vars and DW_AT_specification 107890 The following simple test case fails when dwz is used: 107891 107892 $ cat demo.C 107893 namespace std { 107894 enum { _S_fixed, _S_floatfield = _S_fixed }; 107895 struct { 107896 struct {}; 107897 } 107898 __ioinit; 107899 } 107900 107901 int main() { 107902 return 0; 107903 } 107904 107905 $ g++ demo.C -g && cp a.out b.out && dwz -m xxx.so a.out b.out && objdump -S a.out >/dev/null 107906 objdump: DWARF error: could not find variable specification at offset 0x3d3 107907 107908 As seen the reference is defined in xxx.so shared part: 107909 107910 $ eu-readelf -w -N a.out | grep -A3 -B3 3d3 107911 decl_column (data1) 11 107912 sibling (ref_udata) [ 387] 107913 [ 387] variable abbrev: 30 107914 specification (GNU_ref_alt) [ 3d3] 107915 location (exprloc) 107916 [ 0] addr 0x404019 107917 [ 396] subprogram abbrev: 32 107918 107919 $ eu-readelf -w -N a.out | less 107920 107921 ... 107922 107923 Compilation unit at offset 920: 107924 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4 107925 Unit type: partial (3) 107926 ... 107927 [ 3d3] variable abbrev: 31 107928 name (strp) "__ioinit" 107929 decl_file (data1) demo.C (10) 107930 decl_line (data1) 6 107931 decl_column (data1) 3 107932 type (ref_udata) [ 3c4] 107933 declaration (flag_present) yes 107934 107935 With the patch the same output is emitted as before usage of dwz. 107936 107937 bfd/ChangeLog: 107938 107939 PR 29442 107940 * dwarf2.c (struct varinfo): Use const char * type. 107941 (scan_unit_for_symbols): Call find_abstract_instance for 107942 DW_AT_specification for variables that can be in a different CU 107943 (e.g. done by dwz) 107944 1079452022-08-08 Tsukasa OI <research_trasio@irq.a4lg.com> 107946 107947 Mach-O: i18n enablement on some error messages. 107948 * config/obj-macho.c (obj_mach_o_get_section_names): Wrap two 107949 string literals within with gettext macro. 107950 1079512022-08-08 Martin Liska <mliska@suse.cz> 107952 107953 ld: fix NEWS typos 107954 ld/ChangeLog: 107955 107956 * NEWS: Fix 2 typos. 107957 1079582022-08-08 Nick Clifton <nickc@redhat.com> 107959 107960 Add a link to the NEWS files in the release announcement email. 107961 1079622022-08-08 Jiangshuai Li <jiangshuai_li@linux.alibaba.com> 107963 107964 gdb/csky support .reg2 for kernel 4.x and later 107965 When kernel's version >= 4.x, the size of .reg2 section will be 400. 107966 Contents of .reg2 are { 107967 unsigned long vr[96]; 107968 unsigned long fcr; 107969 unsigned long fesr; 107970 unsigned long fid; 107971 unsigned long reserved; 107972 }; 107973 107974 VR[96] means: (vr0~vr15) + (fr16~fr31), each Vector register is 107975 128-bits, each Float register is 64 bits, the total size is 107976 (4*96). 107977 107978 In addition, for fr0~fr15, each FRx is the lower 64 bits of the 107979 corresponding VRx. So fr0~fr15 and vr0~vr15 regisetrs use the same 107980 offset. 107981 1079822022-08-08 GDB Administrator <gdbadmin@sourceware.org> 107983 107984 Automatic date update in version.in 107985 1079862022-08-07 Tom de Vries <tdevries@suse.de> 107987 107988 [gdb/build] Fix build with gcc 4.8.5 107989 When building with gcc 4.8.5, I run into: 107990 ... 107991 user-regs.c:85:1: error: could not convert \ 107992 ‘{0l, (& builtin_user_regs.gdb_user_regs::first)}’ from \ 107993 ‘<brace-enclosed initializer list>’ to ‘gdb_user_regs’ 107994 }; 107995 ^ 107996 ... 107997 107998 Fix this by removing the initialization and handling regs.last == nullptr in 107999 append_user_reg. 108000 108001 Tested on x86_64-linux. 108002 1080032022-08-07 Tom de Vries <tdevries@suse.de> 108004 108005 [gdb/symtab] Fix assert in read_addrmap_from_aranges 108006 When loading the debug-names-duplicate-cu executable included in this 108007 test-case, we run into: 108008 ... 108009 (gdb) file debug-names-duplicate-cu^M 108010 Reading symbols from debug-names-duplicate-cu...^M 108011 src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \ 108012 Assertion `insertpair.second' failed.^M 108013 ... 108014 108015 This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix 108016 .debug_aranges duplicate offset warning"). 108017 108018 The assert triggers because the CU table in the .debug_names section contains 108019 a duplicate: 108020 ... 108021 Version 5 108022 Augmentation string: 47 44 42 00 ("GDB") 108023 CU table: 108024 [ 0] 0x0 108025 [ 1] 0x0 108026 ... 108027 108028 Fix this by rejecting the .debug_names index: 108029 ... 108030 (gdb) file debug-names-duplicate-cu^M 108031 Reading symbols from debug-names-duplicate-cu...^M 108032 warning: Section .debug_names has duplicate entry in CU table, \ 108033 ignoring .debug_names.^M 108034 ... 108035 108036 Likewise for the case where the CU table is not sorted by increasing offset. 108037 108038 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29436 108039 1080402022-08-07 Tom de Vries <tdevries@suse.de> 108041 108042 [gdb/testsuite] Add support for .debug_names in dwarf assembler 108043 Add: 108044 - support for a per-module .debug_names section in the dwarf assembler, and 108045 - a test-case excercising this new functionality. 108046 108047 A per-module .debug_names section needs to have an entry in the CU list for 108048 each CU in the module, which is made more difficult by two things: 108049 - linking in other objects, which may contain additional CUs 108050 (typically the case on openSUSE), and 108051 - adding dummy CUs in the dwarf assembler. 108052 We handle this by: 108053 - compiling with -nostartfiles (so the test-case contains _start rather than 108054 main), and 108055 - disabling the dummy CU generation for the test-case. 108056 108057 I've kept things simple by having the test-case specify the hash value, rather 108058 than adding that functionality in the dwarf assembler. 108059 108060 Also I've kept the bucket count to 1, which makes it trivial to satisfy the 108061 requirement that "the symbol is entered into a bucket whose index is the hash 108062 value modulo bucket_count". 108063 108064 The readelf dump of the .debug_names section from the test-case looks like: 108065 ... 108066 Version 5 108067 Augmentation string: 47 44 42 00 ("GDB") 108068 CU table: 108069 [ 0] 0x0 108070 108071 TU table: 108072 108073 Foreign TU table: 108074 108075 Used 1 of 1 bucket. 108076 Out of 2 items there are 1 bucket clashes (longest of 1 entries). 108077 108078 Symbol table: 108079 [ 0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0 108080 [ 1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0 108081 ... 108082 108083 Tested on x86_64-linux. 108084 1080852022-08-07 GDB Administrator <gdbadmin@sourceware.org> 108086 108087 Automatic date update in version.in 108088 1080892022-08-06 Alan Modra <amodra@gmail.com> 108090 108091 asan: heap buffer overflow in _bfd_error_handler 108092 On coff_slurp_symbol_table printing "unrecognized storage class" 108093 for a symbol error. If the symbol name is the last string in its 108094 section and not terminated, we run off the end of the buffer. 108095 108096 * coffgen.c (build_debug_section): Terminate the section with 108097 an extra 0. 108098 1080992022-08-06 Alan Modra <amodra@gmail.com> 108100 108101 asan: segfault in coff_write_auxent_fname 108102 More fuzzed input file nonsense. 108103 108104 * coffgen.c (coff_write_symbol): Don't call coff_write_auxent_fname 108105 when extrap is NULL. 108106 1081072022-08-06 Alan Modra <amodra@gmail.com> 108108 108109 msan: bfd_mach_o_layout_commands use of uninitialised value 108110 Catches fuzzed input with unterminated strings that later run off the 108111 end of their buffers when calling strlen. 108112 108113 * mach-o.c: Use size_t vars where approprite. 108114 (bfd_mach_o_alloc_and_read): Add "extra" param. Allocate that 108115 much extra and clear. Update all callers, those that set up 108116 strings with one extra byte. 108117 1081182022-08-06 Alan Modra <amodra@gmail.com> 108119 108120 objcopy section alignment 108121 bfd_set_section_alignment currently always returns true. This patch 108122 changes it to return false on silly alignment values, avoiding yet 108123 another way to trigger ubsan errors like coffcode.h:3192:12: runtime 108124 error: shift exponent 299 is too large for 32-bit type 'int'. We'll 108125 catch that one in objcopy.c:setup_sections. However, setup_sections 108126 gives up on other setup operations that are necessary even after an 108127 error of some sort. Change that to keep going, which might change the 108128 error message but that shouldn't matter in the least. 108129 108130 bfd/ 108131 * section.c (bfd_set_section_alignment): Return false and 108132 don't set alignment_power for stupidly large alignments. 108133 * bfd-in2.h: Regenerate. 108134 * coffcode.h (coff_compute_section_file_positions): Don't use 108135 an int constant when calculating alignment. 108136 binutils/ 108137 * objcopy.c (setup_section): Keep on going after hitting 108138 non-fatal errors. 108139 1081402022-08-06 Alan Modra <amodra@gmail.com> 108141 108142 ubsan: som.c undefined shift in som_set_reloc_info 108143 Do the shift using unsigned variables to avoid UB on << 8. 108144 108145 * som.c (som_set_reloc_info): Make v unsigned. Localise some 108146 variables to their blocks. 108147 1081482022-08-06 GDB Administrator <gdbadmin@sourceware.org> 108149 108150 Automatic date update in version.in 108151 1081522022-08-05 Alan Modra <amodra@gmail.com> 108153 108154 Get rid of BFD_VMA_FMT 108155 Remove the BFD_VMA_FMT defines in bfd.h and configure support. 108156 108157 * bfd-in.h (BFD_VMA_FMT): Don't define. 108158 * configure.ac (BFD_INT64_FMT): Remove configure test. 108159 * configure.com: Likewise. 108160 * Makefile.in: Regenerate. 108161 * bfd-in2.h: Regenerate. 108162 * configure: Regenerate. 108163 1081642022-08-05 Alan Modra <amodra@gmail.com> 108165 108166 Don't use BFD_VMA_FMT in gdb and sim 108167 Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with 108168 PRIx64 and casts to promote bfd_vma to uint64_t. The one file using 108169 BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the 108170 warning message is fixed. 108171 1081722022-08-05 Tom de Vries <tdevries@suse.de> 108173 108174 [gdb/build] Fix build breaker in language.c with gcc 7.5.0 108175 When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into: 108176 ... 108177 gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’: 108178 gdb/language.c:921:8: error: use of deleted function \ 108179 ‘language_arch_info::language_arch_info(const language_arch_info&)’ 108180 struct language_gdbarch 108181 ^~~~~~~~~~~~~~~~ 108182 In file included from gdbsupport/common-defs.h:104:0, 108183 from gdb/defs.h:28, 108184 from gdb/language.c:31: 108185 gdb/language.h:95:28: note: declared here 108186 DISABLE_COPY_AND_ASSIGN (language_arch_info); 108187 ^ 108188 include/ansidecl.h:342:3: note: in definition of macro \ 108189 ‘DISABLE_COPY_AND_ASSIGN’ 108190 TYPE (const TYPE&) = delete; \ 108191 ^~~~ 108192 gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’: 108193 gdb/language.c:936:22: note: synthesized method ‘constexpr \ 108194 language_gdbarch::language_gdbarch()’ first required here 108195 l = new struct language_gdbarch; 108196 ^~~~~~~~~~~~~~~~ 108197 ... 108198 108199 This seems to be fixed by this change in the struct language_gdbarch 108200 definition: 108201 ... 108202 - struct language_arch_info arch_info[nr_languages] {}; 108203 + struct language_arch_info arch_info[nr_languages]; 108204 ... 108205 108206 Tested on x86_64-linux. 108207 1082082022-08-05 Tom de Vries <tdevries@suse.de> 108209 108210 [gdb] Add unit test for gdb::sequential_for_each 108211 With commit 18a5766d09c ("[gdbsupport] Add sequential_for_each") I added a 108212 drop-in replacement for gdb::parallel_for_each, but there's nothing making 108213 sure that the two remain in sync. 108214 108215 Extend the unit test for gdb::parallel_for_each to test both. 108216 108217 Do this using a slightly unusual file-self-inclusion. Doing so keep things 108218 readable and maintainable, and avoids macrofying functions. 108219 108220 Tested on x86_64-linux. 108221 1082222022-08-05 Tom de Vries <tdevries@suse.de> 108223 108224 [gdb/symtab] Use task size in parallel_for_each in dwarf2_build_psymtabs_hard 108225 In dwarf2_build_psymtabs_hard, we use a parallel_for_each to distribute CUs 108226 over threads. 108227 108228 Ensuring a fair distribution over the worker threads and main thread in terms 108229 of number of CUs might not be the most efficient way, given that CUs can vary 108230 in size. 108231 108232 Fix this by using per_cu->get_length () as the task size. 108233 108234 I've used this experiment to verify the performance impact: 108235 ... 108236 $ for n in $(seq 1 10); do \ 108237 time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \ 108238 2>&1 \ 108239 | grep "real:"; \ 108240 done 108241 ... 108242 and without the patch got: 108243 ... 108244 real: 4.71 108245 real: 4.88 108246 real: 4.29 108247 real: 4.30 108248 real: 4.65 108249 real: 4.27 108250 real: 4.27 108251 real: 4.27 108252 real: 4.75 108253 real: 4.41 108254 ... 108255 and with the patch: 108256 ... 108257 real: 3.68 108258 real: 3.81 108259 real: 3.80 108260 real: 3.68 108261 real: 3.75 108262 real: 3.69 108263 real: 3.69 108264 real: 3.74 108265 real: 3.67 108266 real: 3.74 108267 ... 108268 so that seems a reasonable improvement. 108269 108270 With parallel_for_each_debug set to true, we get some more detail about 108271 the difference in behaviour. Without the patch we have: 108272 ... 108273 Parallel for: n_elements: 2818 108274 Parallel for: minimum elements per thread: 1 108275 Parallel for: elts_per_thread: 704 108276 Parallel for: elements on worker thread 0 : 705 108277 Parallel for: elements on worker thread 1 : 705 108278 Parallel for: elements on worker thread 2 : 704 108279 Parallel for: elements on worker thread 3 : 0 108280 Parallel for: elements on main thread : 704 108281 ... 108282 and with the patch: 108283 ... 108284 Parallel for: n_elements: 2818 108285 Parallel for: total_size: 1483674865 108286 Parallel for: size_per_thread: 370918716 108287 Parallel for: elements on worker thread 0 : 752 (size: 371811790) 108288 Parallel for: elements on worker thread 1 : 360 (size: 371509370) 108289 Parallel for: elements on worker thread 2 : 1130 (size: 372681710) 108290 Parallel for: elements on worker thread 3 : 0 (size: 0) 108291 Parallel for: elements on main thread : 576 (size: 367671995) 108292 ... 108293 108294 Tested on x86_64-linux. 108295 1082962022-08-05 Tom de Vries <tdevries@suse.de> 108297 108298 [gdbsupport] Add task size parameter in parallel_for_each 108299 Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use 108300 the task size to distribute similarly-sized chunks to the threads. 108301 108302 Tested on x86_64-linux. 108303 1083042022-08-05 Pedro Alves <pedro@palves.net> 108305 108306 Introduce gdb::make_function_view 108307 This adds gdb::make_function_view, which lets you create a function 108308 view from a callable without specifying the function_view's template 108309 parameter. For example, this: 108310 108311 auto lambda = [&] (int) { ... }; 108312 auto fv = gdb::make_function_view (lambda); 108313 108314 instead of: 108315 108316 auto lambda = [&] (int) { ... }; 108317 gdb::function_view<void (int)> fv = lambda; 108318 108319 It is particularly useful if you have a template function with an 108320 optional function_view parameter, whose type depends on the function's 108321 template parameters. Like: 108322 108323 template<typename T> 108324 void my_function (T v, gdb::function_view<void(T)> callback = nullptr); 108325 108326 For such a function, the type of the callback argument you pass must 108327 already be a function_view. I.e., this wouldn't compile: 108328 108329 auto lambda = [&] (int) { ... }; 108330 my_function (1, lambda); 108331 108332 With gdb::make_function_view, you can write the call like so: 108333 108334 auto lambda = [&] (int) { ... }; 108335 my_function (1, gdb::make_function_view (lambda)); 108336 108337 Unit tests included. 108338 108339 Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64 108340 GNU/Linux, and running the unit tests. 108341 108342 Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626 108343 1083442022-08-05 Nick Clifton <nickc@redhat.com> 108345 108346 Update following 2.39 release 108347 1083482022-08-05 Alan Modra <amodra@gmail.com> 108349 108350 asan: ppc64_elf_get_synthetic_symtab heap buffer overflow 108351 Fuzzed input files with sizes of .dynamic not a multiple of dynamic 108352 tag size can result in reading past the end of the buffer with the 108353 current simple checks. Fix that, and use the same check in other 108354 files that process input object .dynamic section. (There is no need 108355 for buffer overflow checks in the linker's generated .dynamic 108356 section.) 108357 108358 * elf32-ppc.c (ppc_elf_get_synthetic_symtab): Sanity check 108359 .dynamic content buffer reads. 108360 * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise. 108361 * elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Likewise. 108362 * elf.c (_bfd_elf_print_private_bfd_data): Simplify .dynamic 108363 buffer sanity checks. 108364 * elflink.c (elf_link_add_object_symbols): Avoid possible UB 108365 subtracting sizeof_dyn from pointer. 108366 1083672022-08-05 Alan Modra <amodra@gmail.com> 108368 108369 Sanity check loc_offsets index 108370 Fixes a segfault found by the fuzzers. 108371 108372 * dwarf.c (fetch_indexed_value): Return -1 on error. 108373 (read_and_display_attr_value): Don't display string when 108374 fetch_indexed_value returns an error. Sanity check loc_offsets 108375 index. 108376 1083772022-08-05 Jan Beulich <jbeulich@suse.com> 108378 108379 binutils/Dwarf: avoid "shadowing" of glibc function name 108380 As before: Old enough glibc has an (unguarded) declaration of index() 108381 in string.h, which triggers a "shadows a global declaration" warning. 108382 1083832022-08-05 Tsukasa OI <research_trasio@irq.a4lg.com> 108384 108385 gas: fix a testcase broken by new ZSTD support 108386 The commit 1369522f36eece1b37139a81f7f2139ba3915172 ("Recognize the new ELF 108387 compression type for ZSTD.") added the new ELF compression type but it 108388 accidentally broke a GAS testcase. Since testing for the section type 108389 "2048" (SHF_COMPRESSED) is not going to be portable in the long term, it 108390 now tests SHF_LINK_ORDER ("128") instead. 108391 108392 Using SHF_LINK_ORDER (with possibly sh_link == 0) is an idea by Jan Beulich. 108393 108394 gas/ChangeLog: 108395 108396 * testsuite/gas/elf/section10.s: Use SHF_LINK_ORDER to test 108397 mixed numeric and alpha values. 108398 * testsuite/gas/elf/section10.d: Reflect the change above. 108399 1084002022-08-05 Nick Clifton <nickc@redhat.com> 108401 108402 When gas/read.c calls mbstowcs with a NULL destination, it should set size to 0 108403 PR 29447 108404 * read.c (read_symbol_name): Pass 0 as the length parameter when 108405 invoking mbstowc in order to check the validity of a wide string. 108406 1084072022-08-05 Tom de Vries <tdevries@suse.de> 108408 108409 [gdb] Add debug_{exp,val} 108410 When debugging cc1 I heavily rely on simple one-parameter debug functions 108411 that allow me to inspect a variable of a common type, like: 108412 - debug_generic_expr 108413 - debug_gimple_stmt 108414 - debug_rtx 108415 and I miss similar functions in gdb. 108416 108417 Add functions to dump variables of types 'value' and 'expression': 108418 - debug_exp, and 108419 - debug_val. 108420 108421 Tested on x86_64-linux, by breaking on varobj_create, and doing: 108422 ... 108423 (gdb) call debug_exp (var->root->exp.get ()) 108424 &"Operation: OP_VAR_VALUE\n" 108425 &" Block symbol:\n" 108426 &" Symbol: aaa\n" 108427 &" Block: 0x2d064f0\n" 108428 (gdb) 108429 ... 108430 and: 108431 ... 108432 (gdb) call debug_val (value) 108433 &"5" 108434 (gdb) 108435 ... 108436 1084372022-08-05 Luca Boccassi <bluca@debian.org> 108438 108439 Add gold support for --package-metadata option. 108440 Following the same format as the implementation in ld: 108441 9e2bb0cb5e74aed4158f08495534922d7108f928 108442 108443 Generate a .note.package FDO package metadata ELF note, following 108444 the spec: https://systemd.io/ELF_PACKAGE_METADATA/ 108445 108446 If the jansson library is available at build time (and it is explicitly 108447 enabled), link ld to it, and use it to validate that the input is 108448 correct JSON, to avoid writing garbage to the file. The 108449 configure option --enable-jansson has to be used to explicitly enable 108450 it (error out when not found). This allows bootstrappers (or others who 108451 are not interested) to seamlessly skip it without issues. 108452 108453 elfcpp/ 108454 * elfcpp.h: Add FDO_PACKAGING_METADATA note type. 108455 108456 gold/ 108457 * Makefile.am: Add jansson flags and libraries. 108458 * configure.ac: Check for jansson library. 108459 * layout.cc (Layout::create_notes): Call create_package_metadata(). 108460 (Layout::create_package_metadata): New function. 108461 * layout.h (Layout::create_package_metadata): New function. 108462 (Layout::package_metadata_note_): New data member. 108463 * options.h (class General_options): Add --package-metadata option. 108464 * testsuite/Makefile.am (object_unittest): Add jansson libraries. 108465 (binary_unittest): Likewise. 108466 (leb128_unittest): Likewise. 108467 (overflow_unittest): Likewise. 108468 (package_metadata_test): New test. 108469 * testsuite/package_metadata_main.c: New test source. 108470 1084712022-08-05 Cary Coutant <ccoutant@gmail.com> 108472 108473 Recognize the new ELF compression type for ZSTD. 108474 There is more work to be done to actually support compression and 108475 decompression using the zstd library, but I will leave that to the 108476 champions of the new compression option. 108477 108478 binutils/ 108479 * binutils/readelf.c (process_section_headers): Add support for 108480 ELFCOMPRESS_ZSTD. 108481 1084822022-08-05 GDB Administrator <gdbadmin@sourceware.org> 108483 108484 Automatic date update in version.in 108485 1084862022-08-04 Tom Tromey <tom@tromey.com> 108487 108488 Use registry in gdbarch 108489 gdbarch implements its own registry-like approach. This patch changes 108490 it to instead use registry.h. It's a rather large patch but largely 108491 uninteresting -- it's mostly a straightforward conversion from the old 108492 approach to the new one. 108493 108494 The main benefit of this change is that it introduces type safety to 108495 the gdbarch registry. It also removes a bunch of code. 108496 108497 One possible drawback is that, previously, the gdbarch registry 108498 differentiated between pre- and post-initialization setup. This 108499 doesn't seem very important to me, though. 108500 1085012022-08-04 Tom Tromey <tom@tromey.com> 108502 108503 Allow registry to refer to const types 108504 So far, the registry hasn't been used to refer to a 'const' type, but 108505 this changes with the gdbarch change. This patch arranges to let the 108506 registry store a pointer-to-const, by removing const in the 'set' 108507 method. 108508 108509 Use new and delete for gdbarch 108510 This changes gdbarch to use new and delete. 108511 108512 Use bool in gdbarch 108513 This changes gdbarch to use bool for initialized_p. 108514 1085152022-08-04 Tom de Vries <tdevries@suse.de> 108516 108517 [gdb/testsuite] Fix .debug_aranges in gdb.dwarf2/fission-loclists.S 108518 When running test-case gdb.dwarf2/fission-loclists.exp, I noticed: 108519 ... 108520 warning: Section .debug_aranges in fission-loclists has duplicate \ 108521 debug_info_offset 0x8f, ignoring .debug_aranges.^M 108522 ... 108523 108524 Fix this by removing the duplicate .debug_aranges entry. 108525 108526 Tested on x86_64-linux. 108527 1085282022-08-04 Tom de Vries <tdevries@suse.de> 108529 108530 [gdb/testsuite] Fix ERROR in gdb.base/watchpoint-unaligned.exp 108531 In PR23888 an error is reported: 108532 ... 108533 ERROR: tcl error sourcing watchpoint-unaligned.exp. 108534 ERROR: expected boolean value but got "" 108535 while executing 108536 "if {$wpnum} { 108537 ... 108538 108539 This presumably happens when: 108540 - skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported 108541 - gdb fails to set a hw watchpoint and instead sets a sw watchpoint 108542 108543 That particular situation is handled for arm: 108544 ... 108545 -re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" { 108546 if {[istarget "arm*-*-*"]} { 108547 untested $test 108548 set wpnum 0 108549 } 108550 } 108551 ... 108552 but not for any other targets so wpnum remains "", triggering the ERROR. 108553 108554 Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9 108555 add test for HW watchpoint support."), but it's still possible for other 108556 targets. 108557 108558 Fix this by: 108559 - initializing wpnum to 0 instead of "" 108560 - signalling the failure to set a hw watchpoint by a fail 108561 108562 Tested on x86_64-linux, also by adding: 108563 ... 108564 gdb_test_no_output "set can-use-hw-watchpoints 0" 108565 ... 108566 and verifying that it triggers the fail. 108567 108568 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23888 108569 1085702022-08-04 Tom de Vries <tdevries@suse.de> 108571 108572 [gdb/tdep] Fix gdb.base/large-frame.exp for aarch64 108573 On aarch64, I run into: 108574 ... 108575 FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace 108576 ... 108577 108578 The problem is that the architecture-specific prologue analyzer fails to 108579 handle the first two insns in the prologue properly: 108580 ... 108581 0000000000400610 <func>: 108582 400610: d2880210 mov x16, #0x4010 108583 400614: cb3063ff sub sp, sp, x16 108584 400618: a9007bfd stp x29, x30, [sp] 108585 40061c: 910003fd mov x29, sp 108586 400620: 910043a0 add x0, x29, #0x10 108587 400624: 97fffff0 bl 4005e4 <blah> 108588 ... 108589 so we get: 108590 ... 108591 $ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func" 108592 Breakpoint 1 at 0x400614 108593 ... 108594 108595 Fix this by: 108596 - fixing the support for the first insn to extract the immediate operand, and 108597 - adding support for the second insn, 108598 such that we have: 108599 ... 108600 Breakpoint 1 at 0x400624 108601 ... 108602 Note that we're overshooting by one insn (0x400620 is the first insn after the 108603 prologue), but that's a pre-existing problem. 108604 108605 Tested on aarch64-linux. 108606 108607 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29408 108608 1086092022-08-04 Alan Modra <amodra@gmail.com> 108610 108611 Don't use BFD_VMA_FMT in binutils 108612 BFD_VMA_FMT can't be used in format strings that need to be 108613 translated, because the translation won't work when the type of 108614 bfd_vma differs from the machine used to compile .pot files. We've 108615 known about this for a long time, but patches slip through review. 108616 108617 So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64, 108618 PRIu64, PRIx64 or PRIo64 and SCN variants for scanf. The patch is 108619 mostly mechanical, the only thing requiring any thought is casts 108620 needed to preserve PRId64 output from bfd_vma values, or to preserve 108621 one of the unsigned output formats from bfd_signed_vma values. 108622 1086232022-08-04 Alan Modra <amodra@gmail.com> 108624 108625 Re: Get rid of fprintf_vma and sprintf_vma 108626 Commit f493c2174e messed the formatting in linker map files, 108627 particularly for 32-bit builds where a number of tests using map files 108628 regressed. I should have noticed the BFD64 conditional printing of 108629 spaces to line up output due to the original %V printing hex vmas with 108630 16 digits when BFD64 and 8 digits when not. Besides that, it is nicer 108631 to print 32-bit vmas for 32-bit targets. So change %V back to be 108632 target dependent, now using bfd_sprintf_vma. Since minfo doesn't 108633 return the number of chars printed, that means some places that 108634 currently use %V must instead sprintf to a buffer in order to find the 108635 length printed. 108636 108637 * ldmisc.h (print_spaces): Declare. 108638 (print_space): Change to a macro. 108639 * ldmisc.c (vfinfo): Use bfd_sprintf_vma for %V. Tidy %W case. 108640 (print_space): Delete. 108641 (print_spaces): New function. 108642 * emultempl/aix.em (print_symbol): Use print_spaces. 108643 * ldctor.c (ldctor_build_sets): Likewise. 108644 * ldmain.c (add_archive_element): Likewise. 108645 * ldlang.c (print_one_symbol, lang_print_asneeded): Likewise. 108646 (print_output_section_statement, print_data_statement): Likewise. 108647 (print_reloc_statement, print_padding_statement): Likewise. 108648 (print_assignment): Likewise. Also replace %V printing of vmas 108649 with printing to a buffer in order to properly format output. 108650 (print_input_section, lang_one_common): Likewise. 108651 1086522022-08-04 Alan Modra <amodra@gmail.com> 108653 108654 MIPS: Use R_MIPS_REL16 for BFD_RELOC_16 108655 R_MIPS_REL16 isn't a pc-relative reloc as the name might indicate. 108656 108657 * elf64-mips.c (mips_reloc_map): Map BFD_RELOC_16 to R_MIPS_REL16. 108658 * elfn32-mips.c (mips_reloc_map): Likewise. 108659 1086602022-08-04 GDB Administrator <gdbadmin@sourceware.org> 108661 108662 Automatic date update in version.in 108663 1086642022-08-03 H.J. Lu <hjl.tools@gmail.com> 108665 108666 elf: Reset alignment for each PT_LOAD segment 108667 Reset alignment for each PT_LOAD segment to avoid using alignment from 108668 the previous PT_LOAD segment. 108669 108670 bfd/ 108671 108672 PR ld/29435 108673 * elf.c (assign_file_positions_for_load_sections): Reset 108674 alignment for each PT_LOAD segment. 108675 108676 ld/ 108677 108678 PR ld/29435 108679 * testsuite/ld-elf/pr29435.d: New file. 108680 * testsuite/ld-elf/pr29435.s: Likewise. 108681 1086822022-08-03 Tom Tromey <tom@tromey.com> 108683 108684 Use unique_ptr to destroy per-bfd object 108685 In some cases, the objfile owns the per-bfd object. This is yet 108686 another object that can sometimes be destroyed before the registry is 108687 destroyed, possibly reslting in a use-after-free. Also, I noticed 108688 that the condition for deleting the object is not the same as the 108689 condition used to create it -- so it could possibly result in a memory 108690 leak in some situations. This patch fixes the problem by introducing 108691 a new unique_ptr that holds this object when necessary. 108692 108693 Use auto_obstack in objfile 108694 This changes objfile to use an auto_obstack. This helps prevent 108695 use-after-free bugs, because it ensures that anything allocated on the 108696 objfile obstack will live past the point at which the registry object 108697 is destroyed. 108698 108699 Use gdb_bfd_ref_ptr in objfile 108700 This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to 108701 removing some manual memory management, this fixes a use-after-free 108702 that was introduced by the registry rewrite series. The issue there 108703 was that, in some cases, registry shutdown could refer to memory that 108704 had already been freed. This help fix the bug by delaying the 108705 destruction of the BFD reference (and thus the per-bfd object) until 108706 after the registry has been shut down. 108707 1087082022-08-03 Ruud van der Pas <ruud.vanderpas@oracle.com> 108709 108710 gprofng: fix bug 29410 - Argument " 0." isn't numeric in numeric gt (>) 108711 gprofng/Changelog: 108712 2022-08-02 Ruud van der Pas <ruud.vanderpas@oracle.com> 108713 108714 PR gprofng/29410 108715 * gp-display-html/gp-display-html.in: Remove non-breaking spaces. 108716 1087172022-08-03 Alan Modra <amodra@gmail.com> 108718 108719 Fix a conflict between the linker's need to rename some PE format input libraries and the BFD library's file caching mechanism. 108720 PR 29389 108721 bfd * bfd.c (BFD_CLOSED_BY_CACHE): New bfd flag. 108722 * cache.c (bfd_cache_delete): Set BFD_CLOSED_BY_DELETE on the 108723 closed bfd. 108724 (bfd_cache_lookup_worker): Clear BFD_CLOSED_BY_DELETE on the newly 108725 reopened bfd. 108726 * opncls.c (bfd_set_filename): Refuse to change the name of a bfd 108727 that has been closed by bfd_cache_delete. Mark changed bfds as 108728 uncacheable. 108729 * bfd-in2.h: Regenerate. 108730 108731 ld * ldlang.h (lang_input_statement_struct): Add sort_key field. 108732 * emultempl/pe.em (after_open): If multiple import libraries refer 108733 to the same bfd, store their names in the sort_key field. 108734 * emultempl/pep.em (after_open): Likewise. 108735 * ldlang.c (sort_filename): New function. Returns the filename to 108736 be used when sorting input files. 108737 (wild_sort): Use the sort_filename function. 108738 1087392022-08-03 Enze Li <enze.li@hotmail.com> 108740 108741 gdb/amd64: clean up unused variable 108742 When building with clang 15, I got this, 108743 108744 CXX amd64-tdep.o 108745 amd64-tdep.c:1410:13: error: variable 'insn' set but not used[-Werror,-Wunused-but-set-variable] 108746 gdb_byte *insn = insn_details->raw_insn + modrm_offset; 108747 ^ 108748 1 error generated. 108749 108750 The function that uses this variable has been removed in this commit, 108751 108752 commit 870f88f7551b0f2d6aaaa36fb684b5ff8f468107 108753 Date: Mon Apr 18 13:16:27 2016 -0400 108754 108755 remove trivialy unused variables 108756 108757 Fix this by removing unused variable. 108758 108759 Tested by rebuilding on x86_64-linux with clang 15 and gcc 12. 108760 1087612022-08-03 Lancelot SIX <lancelot.six@amd.com> 108762 108763 gdb: Fix regression in varobj recreation 108764 Commit bc20e562ec0 "Fix use after free in varobj" introduced a 108765 regression. This commit makes sure that the varobj object does not 108766 keeps stale references to object being freed when we unload an objfile. 108767 This includes the "valid_block" field which is reset to nullptr if the 108768 pointed to block is tied to an objfile being freed. 108769 108770 However, at some point varobj_invalidate_iter might try to recreate 108771 varobjs tracking either floating or globals. Varobj tracking globals 108772 are identified as having the "valid_block" field set nullptr, but as 108773 bc20e562ec0 might clear this field, we have lost the ability to 108774 distinguish between varobj referring to globals and non globals. 108775 108776 Fix this by introducing a "global" flag which tracks if a given varobj 108777 was initially created as tracking a global. 108778 108779 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 108780 1087812022-08-03 Alan Modra <amodra@gmail.com> 108782 108783 Re: PE objdump -x 108784 All of these buffer overrun tests are better written as a comparison 108785 against size remaining, due to ISO C 9899 standard 6.5.2 para 8 108786 regarding adding a constant to a pointer: 108787 108788 "If both the pointer operand and the result point to elements of the 108789 same array object, or one past the last element of the array object, 108790 the evaluation shall not produce an overflow; otherwise, the behavior 108791 is undefined." 108792 108793 So "ex_dta + 4" might be undefined behaviour, if you interpret "the 108794 array object" in this case to be the malloc'd section contents! 108795 108796 * pei-x86_64.c (pex64_get_unwind_info): Tidy sanity checks. 108797 (pex64_xdata_print_uwd_codes): Likewise. 108798 1087992022-08-03 Jan Beulich <jbeulich@suse.com> 108800 108801 x86: improve/shorten vector zeroing-idiom optimization conditional 108802 - Drop the rounding type check: We're past template matching, and none 108803 of the involved insns support embedded rounding. 108804 - Drop the extension opcode check: None of the involved opcodes have 108805 variants with it being other than None. 108806 - Instead check opcode space, even if just to be on the safe side going 108807 forward. 108808 - Reduce the number of comparisons by folding two groups. 108809 108810 x86: properly mark i386-only insns 108811 Just like all Size64 insns are marked Cpu64, all Size32 insns ought to 108812 be marked Cpu386. 108813 108814 x86: also use D for MOVBE 108815 First of all rename the meanwhile misleading Opcode_SIMD_FloatD, as it 108816 has also been used for KMOV* and BNDMOV. Then simplify the condition 108817 selecting which form if "reversing" to use - except for the MOV to/from 108818 control/debug/test registers all extended opcode space insns use bit 0 108819 (rather than bit 1) to indicate the direction (from/to memory) of an 108820 operation. With that, D can simply be set on the first of the two 108821 templates, while the other can be dropped. 108822 1088232022-08-03 GDB Administrator <gdbadmin@sourceware.org> 108824 108825 Automatic date update in version.in 108826 1088272022-08-03 Cary Coutant <ccoutant@gmail.com> 108828 108829 Add ELFCOMPRESS_ZSTD. 108830 include/elf/ 108831 * common.h: Add ELFCOMPRESS_ZSTD. 108832 1088332022-08-02 John Baldwin <jhb@FreeBSD.org> 108834 108835 fbsd-nat: Correct the return type of the have_regset method. 108836 During the development of 40c23d880386d6e8202567eaa2a6b041feb1a652, 108837 the return value of fbsd_nat_target::have_regset was changed from a 108838 simple boolean to returning the size of the register set. The 108839 comments and callers were all updated for this change, but the actual 108840 return type was accidentally left as a bool. This change fixes the 108841 return type to be a size_t. 108842 108843 Current callers of this only checked the value against 0 and thus 108844 still worked correctly. 108845 1088462022-08-02 Jan Beulich <jbeulich@suse.com> 108847 108848 ELF: emit symbol table when there are relocations 108849 Even when there are no symbols (e.g. all relocations being against 108850 absolute values), a symbol table (with just the first placeholder entry) 108851 needs to be emitted. Otherwise tools like objdump won't properly process 108852 the relocations. The respective checks in assign_section_numbers() and 108853 _bfd_elf_compute_section_file_positions() support also this view. Oddly 108854 enough so far HAS_RELOC was only set when reading in an object file, but 108855 not when generating one anew; the flag would only have been cleared when 108856 no relocations were found (anymore). 108857 108858 While there also amend the affected function's leading comment to also 108859 mention gas. 108860 1088612022-08-02 Matthew Malcomson <hardenedapple@gmail.com> 108862 108863 ld: aarch64: Adjust TLS relaxation condition 108864 In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we 108865 choose whether to perform a relaxation to an IE access model or an LE 108866 access model based on whether the symbol itself is marked as local (i.e. 108867 `h == NULL`). 108868 108869 This is problematic in two ways. The first is that sometimes a global 108870 dynamic access can be relaxed to an initial exec access when creating a 108871 shared library, and if that happens on a local symbol then we currently 108872 relax it to a local exec access instead. This usually does not happen 108873 since we only relax an access if aarch64_can_relax_tls returns true and 108874 aarch64_can_relax_tls does not have the same problem. However, it can 108875 happen when we have seen both an IE and GD access on the same symbol. 108876 This case is exercised in the newly added testcase tls-relax-gd-ie-2. 108877 108878 The second problem is that deciding based on whether the symbol is local 108879 misses the case when the symbol is global but is still non-interposable 108880 and known to be located in the executable. This happens on all global 108881 symbols in executables. 108882 This case is exercised in the newly added testcase tls-relax-ie-le-4. 108883 108884 Here we adjust the condition we base our relaxation on so that we relax 108885 to local-exec if we are creating an executable and the relevant symbol 108886 we're accessing is stored inside that executable. 108887 108888 -- Updating tests for new relaxation criteria 108889 108890 Many of the tests added to check our relaxation to IE were implemented 108891 by taking advantage of the fact that we did not relax a global symbol 108892 defined in an executable. 108893 108894 Since a global symbol defined in an executable is still not 108895 interposable, we know that a TLS version of such a symbol will be in the 108896 main TLS block. This means that we can perform a stronger relaxation on 108897 such symbols and relax their accesses to a local-exec access. 108898 108899 Hence we have to update all tests that relied on the older suboptimal 108900 decision making. 108901 108902 The two cases when we still would want to relax a general dynamic access 108903 to an initial exec one are: 108904 1) When in a shared library and accessing a symbol which we have already 108905 seen accessed with an initial exec access sequence. 108906 2) When in an executable and accessing a symbol defined in a shared 108907 library. 108908 108909 Both of these require shared library support, which means that these 108910 tests are now only available on targets with that. 108911 108912 I have chosen to switch the existing testcases from a plain executable 108913 to one dynamically linked to a shared object as that doesn't require 108914 changing the testcases quite so much (just requires accessing a 108915 different variable rather than requiring adding another code sequence). 108916 108917 The tls-relax-all testcase was an outlier to the above approach, since 108918 it included a general dynamic access to both a local and global symbol 108919 and inspected for the difference accordingly. 108920 1089212022-08-02 Matthew Malcomson <hardenedapple@gmail.com> 108922 108923 ld: aarch64: Update test linker scripts relocs.ld and relocs-ilp32.ld 108924 The updates are to ensure that the .data section exists. This means 108925 that we always have a data section. That means that we don't create a 108926 RWX segment and avoid the corresponding warning. 108927 108928 We get this warning when testing aarch64-none-elf with -mcmodel=tiny. 108929 N.b. this changes quite a few testcases from fail to pass. 108930 1089312022-08-02 Victor Do Nascimento <Victor.DoNascimento@arm.com> 108932 108933 arm: Add cfi expression support for ra_auth_code 108934 This patch extends assembler support for the use of register names to 108935 allow for pseudo-registers, e.g. ra_auth_code register. 108936 This is done particularly with CFI directives in mind, allowing for 108937 expressions of the type: 108938 108939 .cfi_register ra_auth_code, 12 108940 108941 gas/Changelog: 108942 108943 * config/tc-arm.c (tc_arm_regname_to_dw2regnum): Add 108944 REG_TYPE_PSEUDO handling. 108945 * testsuite/gas/arm/cfi-pacbti-m-readelf.d: New. 108946 * testsuite/gas/arm/cfi-pacbti-m.s: New. 108947 1089482022-08-02 Victor Do Nascimento <Victor.DoNascimento@arm.com> 108949 108950 arm: Use DWARF numbering convention for pseudo-register representation 108951 This patch modifies the internal `struct reg_entry' numbering of DWARF 108952 pseudo-registers to match values assigned in DWARF standards (see "4.1 108953 DWARF register names" in [1])so ra_auth_code goes from 12 to 143 and 108954 amends the unwinder .save directive-processing code to correctly handle 108955 mixed register-type save directives. 108956 108957 The mechanism for splitting the register list is also re-written to 108958 comply with register ordering on push statements, being that registers 108959 are stored on the stack in numerical order, with the lowest numbered 108960 register at the lowest address [2]. 108961 108962 Consequently, the parsing of the hypothetical directive 108963 108964 .save{r4-r7, r10, ra_auth_core, lr} 108965 108966 has been changed such as rather than producing 108967 108968 .save{r4-r7, r10} 108969 .save{ra_auth_code} 108970 .save{lr} 108971 108972 as was the case with previous implementation, now produces: 108973 108974 .save{lr} 108975 .save{ra_auth_code} 108976 .save{r4-r7, r10} 108977 108978 [1] <https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst> 108979 [2] <https://developer.arm.com/documentation/dui0473/j/arm-and-thumb-instructions/push> 108980 108981 gas/Changelog: 108982 108983 * config/tc-arm.c (REG_RA_AUTH_CODE): New. 108984 (parse_dot_save): Likewise. 108985 (parse_reg_list): Remove obsolete code. 108986 (reg_names): Set ra_auth_code to 143. 108987 (s_arm_unwind_save): Handle core and pseudo-register lists via 108988 parse_dot_save. 108989 (s_arm_unwind_save_mixed): Deleted. 108990 (s_arm_unwind_save_pseudo): Handle one register at a time. 108991 * testsuite/gas/arm/unwind-pacbti-m-readelf.d: Fix test. 108992 * testsuite/gas/arm/unwind-pacbti-m.d: Likewise. 108993 1089942022-08-02 Alan Modra <amodra@gmail.com> 108995 108996 PE objdump -x 108997 objdump -x on PE executables produces lots of "xdata section corrupt" 108998 and "corrupt unwind data" warnings, and refuses to dump that info. It 108999 turns out that the sanity checks were bad, not the data. Fix them. 109000 109001 * pei-x86_64.c (pex64_get_unwind_info): Correct buffer overrun 109002 sanity checks. 109003 (pex64_xdata_print_uwd_codes): Similarly. 109004 1090052022-08-02 Jan Beulich <jbeulich@suse.com> 109006 109007 x86: XOP shift insns don't really allow B suffix 109008 By mistake it was permitted to be used from the very introduction of XOP 109009 support. 109010 1090112022-08-02 GDB Administrator <gdbadmin@sourceware.org> 109012 109013 Automatic date update in version.in 109014 1090152022-08-01 Martin Storsjö <martin@martin.st> 109016 109017 ld: Support the -exclude-symbols option via COFF def files, with the EXCLUDE_SYMBOLS keyword 109018 This was requested in review. 109019 109020 ld: Add support for a new option, -exclude-symbols, in COFF object file directives 109021 This maps to the same as ld's --exclude-symbols command line option, 109022 but allowing specifying the option via directives embedded in the 109023 object files instead of passed manually on the command line. 109024 1090252022-08-01 Tom de Vries <tdevries@suse.de> 109026 109027 [gdb/symtab] Fix .debug_aranges duplicate offset warning 109028 The function read_addrmap_from_aranges contains code to issue a warning: 109029 ... 109030 if (!insertpair.second) 109031 { 109032 warning (_("Section .debug_aranges in %s has duplicate " 109033 "debug_info_offset %s, ignoring .debug_aranges."), 109034 objfile_name (objfile), sect_offset_str (per_cu->sect_off)); 109035 return false; 109036 } 109037 ... 109038 but the warning is in fact activated when all_comp_units has duplicate 109039 entries, which is very misleading. 109040 109041 Fix this by: 109042 - adding a test-case that should trigger the warning, 109043 - replacing the current implementation of the warning with an 109044 assert that all_comp_units should not contain duplicates, and 109045 - properly re-implementing the warning, such that it is triggered 109046 by the test-case. 109047 109048 Tested on x86_64-linux. 109049 109050 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381 109051 1090522022-08-01 Jan Beulich <jbeulich@suse.com> 109053 109054 x86: SKINIT with operand needs IgnoreSize 109055 Without it in 16-bit mode a pointless operand size prefix would be 109056 emitted. 109057 1090582022-08-01 WANG Xuerui <git@xen0n.name> 109059 109060 opcodes: LoongArch: add "ret" instruction to reduce typing 109061 This syntactic sugar is present in both classical and emerging 109062 architectures, like Alpha, SPARC and RISC-V, and assembler macros 109063 doing the same thing can already be found in the wild e.g. [1], proving 109064 the feature's popularity. It's better to provide support directly in the 109065 assembler so downstream users wouldn't have to re-invent this over and 109066 over again. 109067 109068 [1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/loongarch/sysdep.h;h=c586df819cd90;hb=HEAD#l28 109069 1090702022-08-01 WANG Xuerui <git@xen0n.name> 109071 109072 opcodes: LoongArch: make all non-native jumps desugar to canonical b{lt/ge}[u] forms 109073 Also re-order the jump/branch opcodes while at it, so that insns are 109074 sorted in ascending order according to opcodes, and the label form 109075 preceding the real definition. 109076 1090772022-08-01 Alan Modra <amodra@gmail.com> 109078 109079 Get rid of fprintf_vma and sprintf_vma 109080 These two macros print either a 16 digit hex number or an 8 digit 109081 hex number. Unfortunately they depend on both target and host, which 109082 means that the output for 32-bit targets may be either 8 or 16 hex 109083 digits. 109084 109085 Replace them in most cases with code that prints a bfd_vma using 109086 PRIx64. In some cases, deliberately lose the leading zeros. 109087 This change some output, notably in base/offset fields of m68k 109088 disassembly which I think looks better that way, and in error 109089 messages. I've kept leading zeros in symbol dumps (objdump -t) 109090 and in PE header dumps. 109091 109092 bfd/ 109093 * bfd-in.h (fprintf_vma, sprintf_vma, printf_vma): Delete. 109094 * bfd-in2.h: Regenerate. 109095 * bfd.c (bfd_sprintf_vma): Don't use sprintf_vma. 109096 (bfd_fprintf_vma): Don't use fprintf_vma. 109097 * coff-rs6000.c (xcoff_reloc_type_tls): Don't use sprintf_vma. 109098 Instead use PRIx64 to print bfd_vma values. 109099 (xcoff_ppc_relocate_section): Likewise. 109100 * cofflink.c (_bfd_coff_write_global_sym): Likewise. 109101 * mmo.c (mmo_write_symbols_and_terminator): Likewise. 109102 * srec.c (srec_write_symbols): Likewise. 109103 * elf32-xtensa.c (print_r_reloc): Similarly for fprintf_vma. 109104 * pei-x86_64.c (pex64_dump_xdata): Likewise. 109105 (pex64_bfd_print_pdata_section): Likewise. 109106 * som.c (som_print_symbol): Likewise. 109107 * ecoff.c (_bfd_ecoff_print_symbol): Use bfd_fprintf_vma. 109108 opcodes/ 109109 * dis-buf.c (perror_memory, generic_print_address): Don't use 109110 sprintf_vma. Instead use PRIx64 to print bfd_vma values. 109111 * i386-dis.c (print_operand_value, print_displacement): Likewise. 109112 * m68k-dis.c (print_base, print_indexed): Likewise. 109113 * ns32k-dis.c (print_insn_arg): Likewise. 109114 * ia64-gen.c (_opcode_int64_low, _opcode_int64_high): Delete. 109115 (opcode_fprintf_vma): Delete. 109116 (print_main_table): Use PRIx64 to print opcode. 109117 binutils/ 109118 * od-macho.c: Replace all uses of printf_vma with bfd_printf_vma. 109119 * objcopy.c (copy_object): Don't use sprintf_vma. Instead use 109120 PRIx64 to print bfd_vma values. 109121 (copy_main): Likewise. 109122 * readelf.c (CHECK_ENTSIZE_VALUES): Likewise. 109123 (dynamic_section_mips_val): Likewise. 109124 (print_vma): Don't use printf_vma. Instead use PRIx64 to print 109125 bfd_vma values. 109126 (dump_ia64_vms_dynamic_fixups): Likewise. 109127 (process_version_sections): Likewise. 109128 * rddbg.c (stab_context): Likewise. 109129 gas/ 109130 * config/tc-i386.c (offset_in_range): Don't use sprintf_vma. 109131 Instead use PRIx64 to print bfd_vma values. 109132 (md_assemble): Likewise. 109133 * config/tc-mips.c (load_register, macro): Likewise. 109134 * messages.c (as_internal_value_out_of_range): Likewise. 109135 * read.c (emit_expr_with_reloc): Likewise. 109136 * config/tc-ia64.c (note_register_values): Don't use fprintf_vma. 109137 Instead use PRIx64 to print bfd_vma values. 109138 (print_dependency): Likewise. 109139 * listing.c (list_symbol_table): Use bfd_sprintf_vma. 109140 * symbols.c (print_symbol_value_1): Use %p to print pointers. 109141 (print_binary): Likewise. 109142 (print_expr_1): Use PRIx64 to print bfd_vma values. 109143 * write.c (print_fixup): Use %p to print pointers. Don't use 109144 fprintf_vma. 109145 * testsuite/gas/all/overflow.l: Update expected output. 109146 * testsuite/gas/m68k/mcf-mov3q.d: Likewise. 109147 * testsuite/gas/m68k/operands.d: Likewise. 109148 * testsuite/gas/s12z/truncated.d: Likewise. 109149 ld/ 109150 * deffilep.y (def_file_print): Don't use fprintf_vma. Instead 109151 use PRIx64 to print bfd_vma values. 109152 * emultempl/armelf.em (gld${EMULATION_NAME}_finish): Don't use 109153 sprintf_vma. Instead use PRIx64 to print bfd_vma values. 109154 * emultempl/pe.em (gld${EMULATION_NAME}_finish): Likewise. 109155 * ldlang.c (lang_map): Use %V to print region origin. 109156 (lang_one_common): Don't use sprintf_vma. 109157 * ldmisc.c (vfinfo): Don't use fprintf_vma or sprintf_vma. 109158 * pe-dll.c (pe_dll_generate_def_file): Likewise. 109159 gdb/ 109160 * remote.c (remote_target::trace_set_readonly_regions): Replace 109161 uses of sprintf_vma with bfd_sprintf_vma. 109162 1091632022-08-01 liuzhensong <liuzhensong@loongson.cn> 109164 109165 LoongArch: Set defaults to exec stack 0. 109166 1091672022-08-01 Alan Modra <amodra@gmail.com> 109168 109169 libctf: Avoid use of uninitialised variables 109170 * ctf-link.c (ctf_link_add_ctf_internal): Don't free uninitialised 109171 pointers. 109172 1091732022-08-01 Alan Modra <amodra@gmail.com> 109174 109175 PR29348, BFD_VMA_FMT wrong 109176 There is a problem with my commit 0e3c1eebb2, which replaced 109177 bfd_uint64_t with uint64_t: Some hosts typedef int64_t to long long 109178 even when long is the same size as long long. That confuses the code 109179 choosing one of "l", "ll", or "I64" for BFD_VMA_FMT, and results in 109180 warnings. 109181 109182 Write a direct configure test for the printf int64_t style instead. 109183 This removes the last use of BFD_HOST_64BIT_LONG, so delete that. 109184 Note that the changes to configure.com are pure guesswork. 109185 109186 PR 29348 109187 * bfd-in.h (BFD_HOST_64BIT_LONG): Don't define. 109188 (BFD_VMA_FMT): Define using BFD_INT64_FMT when 64-bit. 109189 (bfd_vma, bfd_signed_vma): Move comments to 64-bit typedefs. 109190 * configure.ac (BFD_HOST_64BIT_LONG): Delete. 109191 (BFD_INT64_FMT): New config test. 109192 * configure.com: Update similarly. 109193 * Makefile.in: Regenerate. 109194 * bfd-in2.h: Regenerate. 109195 * configure: Regenerate. 109196 1091972022-08-01 GDB Administrator <gdbadmin@sourceware.org> 109198 109199 Automatic date update in version.in 109200 1092012022-07-31 GDB Administrator <gdbadmin@sourceware.org> 109202 109203 Automatic date update in version.in 109204 1092052022-07-30 Tom de Vries <tdevries@suse.de> 109206 109207 [gdb/testsuite] Fix gdb.ada/literals.exp with aarch64 109208 On aarch64-linux, I run into: 109209 ... 109210 (gdb) print 16#ffffffffffffffff#^M 109211 $7 = 18446744073709551615^M 109212 (gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff# 109213 ... 109214 while on x86_64-linux instead, I get: 109215 ... 109216 (gdb) print 16#ffffffffffffffff#^M 109217 $7 = -1^M 109218 (gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff# 109219 ... 109220 109221 We can easily reproduce this on x86_64-linux using: 109222 ... 109223 $ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \ 109224 -ex "print 16#ffffffffffffffff#" 109225 $1 = -1 109226 $ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \ 109227 -ex "print 16#ffffffffffffffff#" 109228 $1 = 18446744073709551615 109229 ... 109230 109231 With i386, we have: 109232 ... 109233 (gdb) p int_bits 109234 $3 = 32 109235 (gdb) p long_bits 109236 $4 = 32 109237 (gdb) p long_long_bits 109238 $5 = 64 109239 ... 109240 and so in processInt we hit the fits-in-unsigned-long-long case where we use 109241 as type long long: 109242 ... 109243 /* Note: Interprets ULLONG_MAX as -1. */ 109244 yylval.typed_val.type = type_long_long (par_state); 109245 ... 109246 109247 With aarch64, we have instead: 109248 ... 109249 (gdb) p int_bits 109250 $1 = 32 109251 (gdb) p long_bits 109252 $2 = 64 109253 (gdb) p long_long_bits 109254 $3 = 64 109255 ... 109256 and so in processInt we hit the fits-in-unsigned-long case where we use 109257 as type unsigned long: 109258 ... 109259 yylval.typed_val.type 109260 = builtin_type (par_state->gdbarch ())->builtin_unsigned_long; 109261 ... 109262 109263 It's not clear why for ada we're using long long for the 109264 fits-in-unsigned-long-long case. 109265 109266 Fix this by using unsigned long long for the fits-in-unsigned-long-long case, 109267 meaning the new reference output is 18446744073709551615 instead of -1. 109268 109269 Tested on x86_64-linux. 109270 109271 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416 109272 1092732022-07-30 Simon Marchi <simon.marchi@efficios.com> 109274 109275 gdb/testsuite: add macros test for source files compiled in various ways 109276 Using different ways of passing source file paths to compilers results n 109277 different file and directory paths in the line header. For example: 109278 109279 - gcc foo.c 109280 - gcc ./foo.c 109281 - gcc ../cwd/foo.c 109282 - gcc $PWD/foo.c 109283 109284 Because of this, GDB sometimes failed to look up macros. The previous 109285 patch fixed that as much as possible. This patch adds the corresponding 109286 tests. 109287 109288 Add both a DWARF assembler-based test and a regular test. The DWARF 109289 assembled-based one tests some hard-coded debug info based on what I 109290 have observed some specific versions of gcc and clang generate. We want 109291 to make sure that GDB keeps handling all these cases correctly, even if 109292 it's not always clear whether they are really valid DWARF. Also, they 109293 will be tested no matter what the current target compiler is for a given 109294 test run. 109295 109296 The regular test is compiled using the target compiler, so it may help 109297 find bugs when testing against some other toolchains than what was used 109298 to generate the DWARF assembler-based test. 109299 109300 For the DWARF assembler-based test, add to testsuite/lib/dwarf.exp the 109301 necessary code to generate a DWARF5 .debug_macro section. The design of 109302 the new procs is based on what was done for rnglists and loclists. 109303 109304 To test against a specific compiler one can use this command, for 109305 example: 109306 109307 $ make check TESTS="gdb.base/macro-source-path.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang --target_board unix/gdb:debug_flags=-gdwarf-5" 109308 109309 Change-Id: Iab8da498e57d10cc2a3d09ea136685d9278cfcf6 109310 1093112022-07-30 Simon Marchi <simon.marchi@polymtl.ca> 109312 109313 gdb: remove code to prepend comp dir in buildsym_compunit::start_subfile 109314 The bit of code removed by this patch was introduced to fix the same 109315 kind of problem that the previous patch fixes. That is, to try to match 109316 existing subfiles when different name forms are used to refer to a same 109317 file. 109318 109319 The thread for the patch that introduced this code is: 109320 109321 https://pi.simark.ca/gdb-patches/45F8CBDF.9090501@hq.tensilica.com/ 109322 109323 The important bits are that the compiler produced a compilation unit 109324 with: 109325 109326 DW_AT_name : test.c 109327 DW_AT_comp_dir : /home/maxim/W/BadgerPass/PR_14999 109328 109329 and DWARF v2 line table with: 109330 109331 The Directory Table: 109332 /home/maxim/W/BadgerPass/PR_14999 109333 109334 The File Name Table: 109335 Entry Dir Time Size Name 109336 1 1 1173897037 152 test.c 109337 109338 Because the main symtab was created with only DW_AT_name, it was named 109339 "test.c". And because the path built from the line header contained the 109340 "directory" part, it was "/home/maxim/W/BadgerPass/PR_14999/test.c". 109341 Because of this mismatch, thing didn't work, so they added this code to 109342 prepend the compilation directory to the existing subfile names, so that 109343 this specific case would work. 109344 109345 With the changes done earlier in this series, where subfiles are 109346 identified using the "most complete path possible", this case would be 109347 handled. The main subfile's would be 109348 "/home/maxim/W/BadgerPass/PR_14999/test.c" from the start 109349 (DW_AT_comp_dir + DW_AT_name). It's not so different from some DWARF 5 109350 cases actually, which make the compilation directory explicit in the 109351 line table header. 109352 109353 I therefore think that this code is no longer needed. It does feel like 109354 a quick hack to make one specific case work, and we have a more general 109355 solution now. Also, this code was introduced to work around a problem 109356 in the DWARF debug info or the DWARF debug info reader. In general, I 109357 think it's preferable for these hacks to be located in the specific 109358 debug info reader code, rather than in the common code. 109359 109360 Even though this code was added to work around a DWARF reader problem, 109361 it's possible that some other debug info reader has started taking 109362 advantage of this code in the mean time. It's very difficult to 109363 know or verify, but I think the likelyhood is quite small, so I'm 109364 proposing to get rid of it to simplify things a little bit. 109365 109366 Change-Id: I710b8ec0d449d1b110d67ddf9fcbdb2b37108306 109367 1093682022-07-30 Simon Marchi <simon.marchi@efficios.com> 109369 109370 gdb: add "id" fields to identify symtabs and subfiles 109371 Printing macros defined in the main source file doesn't work reliably 109372 using various toolchains, especially when DWARF 5 is used. For example, 109373 using the binaries produced by either of these commands: 109374 109375 $ gcc --version 109376 gcc (GCC) 11.2.0 109377 $ ld --version 109378 GNU ld (GNU Binutils) 2.38 109379 $ gcc test.c -g3 -gdwarf-5 109380 109381 $ clang --version 109382 clang version 13.0.1 109383 $ clang test.c -gdwarf-5 -fdebug-macro 109384 109385 I get: 109386 109387 $ ./gdb -nx -q --data-directory=data-directory a.out 109388 (gdb) start 109389 Temporary breakpoint 1 at 0x111d: file test.c, line 6. 109390 Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out 109391 109392 Temporary breakpoint 1, main () at test.c:6 109393 6 return ZERO; 109394 (gdb) p ZERO 109395 No symbol "ZERO" in current context. 109396 109397 When starting to investigate this (taking the gcc-compiled binary as an 109398 example), we see that GDB fails to look up the appropriate macro scope 109399 when evaluating the expression. While stopped in 109400 macro_lookup_inclusion: 109401 109402 (top-gdb) p name 109403 $1 = 0x62100011a980 "test.c" 109404 (top-gdb) p source.filename 109405 $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" 109406 109407 `source` is the macro_source_file that we would expect GDB to find. 109408 `name` comes from the symtab::filename field of the symtab we are 109409 stopped in. GDB doesn't find the appropriate macro_source_file because 109410 the name of the macro_source_file doesn't match exactly the name of the 109411 symtab. 109412 109413 The name of the main symtab comes from the compilation unit's 109414 DW_AT_name, passed to the buildsym_compunit's constructor: 109415 109416 https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 109417 109418 The contents of DW_AT_name, in this case, is "test.c". It is typically 109419 (what I witnessed all compilers do) the same string that was passed to 109420 the compiler on the command-line. 109421 109422 The name of the macro_source_file comes from the line number program 109423 header's file table, from the call to the line_header::file_file_name 109424 method: 109425 109426 https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 109427 109428 line_header::file_file_name prepends the directory path that the file 109429 entry refers to, in the file table (if the file name is not already 109430 absolute). In this case, the file name is "test.c", appended to the 109431 directory "/home/simark/build/binutils-gdb-one-target/gdb". 109432 109433 Because the symtab's name is not created the same way as the 109434 macro_source_file's name is created, we get this mismatch. GDB fails to 109435 find the appropriate macro scope for the symtab, and we can't print 109436 macros when stopped in that symtab. 109437 109438 To make this work, we must ensure that paths produced in these two ways 109439 end up identical. This can be tricky because of the different ways a 109440 path can be passed to the compiler by the user. 109441 109442 Another thing to consider is that while the main symtab's name (or 109443 subfile, before it becomes a symtab) is created using DW_AT_name, the 109444 main symtab is also referred to using its entry in the line table 109445 header's file table, when processing the line table. We must therefore 109446 ensure that the same name is produced in both cases, so that a call to 109447 "start_subfile" for the main subfile will correctly find the 109448 already-created subfile, created by buildsym_compunit's constructor. If 109449 we fail to do that, things still often work, because of a fallback: the 109450 watch_main_source_file_lossage method. This method determines that if 109451 the main subfile has no symbols but there exists another subfile with 109452 the same basename (e.g. "test.c") that does have symbols, it's probably 109453 because there was some filename mismatch. So it replaces the main 109454 subfile with that other subfile. I think that heuristic is useful as a 109455 last effort to work around any bug or bad debug info, but I don't think 109456 we should design things such as to rely on it. It's a heuristic, it can 109457 get things wrong. So in my search for a fix, it is important that given 109458 some good debug info, we don't end up relying on that for things to 109459 work. 109460 109461 A first attempt at fixing this was to try to prepend the compilation 109462 directory here or not prepend it there. In practice, because of all the 109463 possible combinations of debug info the compilers produce, it was not 109464 possible to get something that would produce reliable, consistent paths. 109465 109466 Another attempt at fixing this was to make both macro_source_file 109467 objects and symtab objects use the most complete form of path possible. 109468 That means to prepend directories at least until we get an absolute 109469 path. In theory, we should end up with the same path in all cases. 109470 This generally worked, but because it changed the symtab names, it 109471 resulted in user-visible changes (for example, paths to source files in 109472 Breakpoint hit messages becoming always absolute). I didn't find this 109473 very good, first because there is a "set filename-display" setting that 109474 lets the user control how they want the paths to be displayed, and that 109475 would suddenly make this setting completely ineffective (although even 109476 today, it is a bit dependent on the debug info). Second, it would 109477 require a good amount of testsuite tweaks to make tests accept these 109478 suddenly absolute paths. 109479 109480 This new patch is a slight variation of that: it adds a new field called 109481 "filename_for_id" in struct symtab and struct subfile, next to the 109482 existing filename field. The goal is to separate the internal ids used 109483 for finding objects from the names used for presentation. This field is 109484 used for identifying subfiles, symtabs and macro_source_files 109485 internally. For DWARF symtabs, this new field is meant to contain the 109486 "most complete possible" path, as discussed above. So for a given file, 109487 it must always be in the same form, everywhere. The existing 109488 symtab::filename field remains the one used for printing to the user, so 109489 there shouldn't be any change in how paths are printed. 109490 109491 Changes in the core symtab files are: 109492 109493 - Add "name_for_id" and "filename_for_id" fields to "struct subfile" 109494 and "struct symtab", next to existing "name" and "filename" fields. 109495 - Make buildsym_compunit::buildsym_compunit and 109496 buildsym_compunit::start_subfile accept a "name_for_id" parameter 109497 next to the existing "name" ones. 109498 - Make buildsym_compunit::start_subfile use "name_for_id" for looking 109499 up existing subfiles. This is the key thing for making calls 109500 to start_subfile for the main source file look up the existing 109501 subfile successfully, and avoid relying on 109502 watch_main_source_file_lossage. 109503 - Make sal_macro_scope pass "filename_for_id", rather than "filename", 109504 to macro_lookup_inclusion. This is the key thing to making the 109505 lookup work and macro printing work. 109506 109507 Changes in the DWARF files are: 109508 109509 - Make line_header::file_file_name return the "most complete possible" 109510 name. The only pre-existing user of this method is the macro code, 109511 to give the macro_source_file objects their name. And we now want 109512 them to have this "most complete possible" name, which will match the 109513 corresponding symtab's "filename_for_id". 109514 - Make dwarf2_cu::start_compunit_symtab pass the "most complete 109515 possible" name for the main symtab's "filename_for_id". In this 109516 context, where the info comes from the compilation unit's DW_AT_name 109517 / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if 109518 DW_AT_name is not already absolute. 109519 - Change dwarf2_start_subfile to build a name_for_id for the subfile 109520 being started. The simplest way is to re-use 109521 line_header::file_file_name, since the callers always have a 109522 file_entry handy. This ensures that it will get the exact same path 109523 representation as the macro code does, for the same file (since it 109524 also uses line_header::file_file_name). 109525 - Update calls to allocate_symtab to pass the "name_for_id" from the 109526 subfile. 109527 109528 Tests exercising all this are added by the following patch. 109529 109530 Of all the cases I tried, the only one I found that ends up relying on 109531 watch_main_source_file_lossage is the following one: 109532 109533 $ clang --version 109534 clang version 13.0.1 109535 Target: x86_64-pc-linux-gnu 109536 Thread model: posix 109537 InstalledDir: /usr/bin 109538 $ clang ./test.c -g3 -O0 -gdwarf-4 109539 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out 109540 ... 109541 [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c 109542 [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c 109543 [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c 109544 [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) 109545 [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile 109546 109547 As we can see, there are two forms used for "test.c", one with a "." and 109548 one without. This comes from the fact that the compilation unit DIE 109549 contains: 109550 109551 DW_AT_name ("test.c") 109552 DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") 109553 109554 without a ".", and the line table for that file contains: 109555 109556 include_directories[ 1] = "." 109557 file_names[ 1]: 109558 name: "test.c" 109559 dir_index: 1 109560 109561 When assembling the filename from that entry, we get a ".". 109562 109563 It is a bit unexpected that the main filename resulting from the line 109564 table header does not match exactly the name in the compilation unit. 109565 For instance, gcc uses "./test.c" for the DW_AT_name, which gives 109566 identical paths in the compilation unit and in the line table header. 109567 109568 Similarly, with DWARF 5: 109569 109570 $ clang ./test.c -g3 -O0 -gdwarf-5 109571 109572 clang create two entries that refer to the same file but are of in a different 109573 form. 109574 109575 include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" 109576 include_directories[ 1] = "." 109577 file_names[ 0]: 109578 name: "test.c" 109579 dir_index: 0 109580 file_names[ 1]: 109581 name: "test.c" 109582 dir_index: 1 109583 109584 The first file name produces a path without a "." while the second does. 109585 This is not caught by watch_main_source_file_lossage, because of 109586 dwarf_decode_lines that creates a symtab for each file entry in the line 109587 table. It therefore appears as "non-empty" to 109588 watch_main_source_file_lossage. This results in two symtabs: 109589 109590 (gdb) maintenance info symtabs 109591 { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) 109592 { ((struct compunit_symtab *) 0x62100011aca0) 109593 debugformat DWARF 5 109594 producer clang version 13.0.1 109595 name test.c 109596 dirname /home/simark/build/binutils-gdb-one-target/gdb 109597 blockvector ((struct blockvector *) 0x621000129ec0) 109598 user ((struct compunit_symtab *) (null)) 109599 { symtab test.c ((struct symtab *) 0x62100011ad20) 109600 fullname (null) 109601 linetable ((struct linetable *) 0x0) 109602 } 109603 { symtab ./test.c ((struct symtab *) 0x62100011ad60) 109604 fullname (null) 109605 linetable ((struct linetable *) 0x621000129ef0) 109606 } 109607 } 109608 } 109609 109610 I am not sure what is the consequence of this, but this is also what 109611 happens before my patch, so I think its acceptable to leave it as-is. 109612 109613 To handle these two cases nicely, I think we will need a function that 109614 removes the unnecessary "." from path names, something that can be done 109615 later. 109616 109617 Finally, I made a change in find_file_and_directory is necessary to 109618 avoid breaking test 109619 109620 gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 109621 109622 Without that change, we would get: 109623 109624 (gdb) info source 109625 Current source file is /dir/d/dw2-compdir-oldgcc42.S 109626 Compilation directory is /dir/d 109627 109628 whereas the expected result is: 109629 109630 (gdb) info source 109631 Current source file is dw2-compdir-oldgcc42.S 109632 Compilation directory is /dir/d 109633 109634 This test was added here: 109635 109636 https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html 109637 109638 Long story short, GCC <= 4.2 apparently had a bug where it would 109639 generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") 109640 and no DW_AT_comp_dir. The line table has one entry with filename 109641 "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 109642 normally refers to the compilation unit's comp dir, but it is 109643 non-existent in this case. 109644 109645 This caused some symtab lookup problems, and to work around them, some 109646 workaround was added, which today reads as: 109647 109648 if (res.get_comp_dir () == nullptr 109649 && producer_is_gcc_lt_4_3 (cu) 109650 && res.get_name () != nullptr 109651 && IS_ABSOLUTE_PATH (res.get_name ())) 109652 res.set_comp_dir (ldirname (res.get_name ())); 109653 109654 Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 109655 109656 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no 109657 DW_AT_comp_dir and DW_AT_name is absolute. 109658 109659 Prior to my patch, a subfile would get created with filename 109660 "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get 109661 created with filename "dw2-compdir-oldgcc42.S" from the line table's 109662 file table. Then watch_main_source_file_lossage would kick in and merge 109663 them, keeping only the "dw2-compdir-oldgcc42.S" one: 109664 109665 [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S 109666 [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S 109667 [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S 109668 [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) 109669 [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile 109670 109671 And so "info source" would show "dw2-compdir-oldgcc42.S" as the 109672 filename. 109673 109674 With my patch applied, but without the change in 109675 find_file_and_directory, both DW_AT_name and the line table would try to 109676 start a subfile with the same filename_for_id, and there was no need for 109677 watch_main_source_file_lossage - which is what we want: 109678 109679 [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S 109680 [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S 109681 [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) 109682 [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S 109683 [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) 109684 109685 But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming 109686 from DW_AT_name, gets created first, it wins, and the symtab ends up 109687 with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows 109688 "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. 109689 109690 This is not wrong per-se, after all DW_AT_name is 109691 "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the 109692 current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile 109693 a file passing "/an/absolute/path.c", DW_AT_name typically contains (at 109694 least with GCC) "/an/absolute/path.c" and GDB tells you that the source 109695 file is "/an/absolute/path.c". But we can also keep the existing 109696 behavior fairly easily with a little change in find_file_and_directory. 109697 When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now 109698 modify the name to just keep the file part. The result is coherent with 109699 what compilers do when you compile a file by just passing its filename 109700 ("gcc path.c -g"): 109701 109702 DW_AT_name ("path.c") 109703 DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") 109704 109705 With this change, filename_for_id is still the full name, 109706 "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / 109707 symtab (what ends up shown by "info source") is just 109708 "dw2-compdir-oldgcc42.S", and that makes the test happy. 109709 109710 Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307 109711 1097122022-07-30 Simon Marchi <simon.marchi@polymtl.ca> 109713 109714 gdb/dwarf: pass a file_entry to line_header::file_file_name 109715 In the following patch, there will be some callers of file_file_name 109716 that will already have access to the file_entry object for which they 109717 want the file name. It would be inefficient to have them pass an index, 109718 only for line_header::file_file_name to re-lookup the same file_entry 109719 object. Change line_header::file_file_name to accept a file_entry 109720 object reference, instead of an index to look up. 109721 109722 I think this change makes sense in any case. Callers that have an index 109723 can first obtain a file_entry using line_header::file_name_at or 109724 line_header::file_names. 109725 109726 When passing a file_entry object, we can assume that the file_entry's 109727 index is valid, unlike when passing an index. So, push the special case 109728 about an invalid index to the sole current caller of file_file_name, 109729 macro_start_file. I think that error belongs there anyway, since it 109730 specifically talks about "bad file number in macro information". 109731 109732 This requires recording the file index in the file_entry structure, so 109733 add that. 109734 109735 Change-Id: Ic6e44c407539d92b7863d7ba82405ade17f384ad 109736 1097372022-07-30 Simon Marchi <simon.marchi@polymtl.ca> 109738 109739 gdb/dwarf: pass compilation directory to line header 109740 The following patch changes line_header::file_file_name to prepend the 109741 compilation directory to the file name, if needed. For that, the line 109742 header needs to know about the compilation directory. Prepare for that 109743 by adding a constructor that takes it as a parameter, and passing the 109744 value down everywhere needed. Add a second constructor for the special 109745 case of building a line_header for doing a hash table lookup, since that 109746 case doesn't require a compilation directory value. 109747 109748 Change-Id: Iba3ba0293e4e2d13a64b257cf9a3094684d54330 109749 1097502022-07-30 Simon Marchi <simon.marchi@polymtl.ca> 109751 109752 gdb: add debug prints in buildsym.c 109753 Add a few debug prints in buildsym.c that were helpful to me in writing 109754 this series. 109755 109756 Change-Id: If10a818feaee3ce1b78a2a254013b62dd578002b 109757 1097582022-07-30 Simon Marchi <simon.marchi@polymtl.ca> 109759 109760 gdb: introduce symtab_create_debug_printf 109761 Introduce symtab_create_debug_printf and symtab_create_debug_printf_v, 109762 to print the debug messages enabled by "set debug symtab-create". 109763 109764 Change-Id: I442500903f72d4635c2dd9eaef770111f317dc04 109765 1097662022-07-30 GDB Administrator <gdbadmin@sourceware.org> 109767 109768 Automatic date update in version.in 109769 1097702022-07-29 Tom de Vries <tdevries@suse.de> 109771 109772 [gdb/testsuite] Fix gdb.ada/convvar_comp.exp with broken debug info 109773 On aarch64-linux I run into this failure with gcc 7.5.0: 109774 ... 109775 (gdb) print $item.started^M 109776 $1 = (-5312, 65535, 4202476)^M 109777 (gdb) FAIL: gdb.ada/convvar_comp.exp: print $item.started 109778 ... 109779 109780 The test-case expects (0, 0, 0), but we're getting another value due to 109781 incorrect location information. 109782 109783 Work around this by: 109784 - first printing the value, and then 109785 - verifying that the convenience variable matches the printed value. 109786 109787 I've verified that the test-case still checks what it should by disabling 109788 the fix from commit cc0e770c0d0 ("memory error printing component of record 109789 from convenience variable") and observing the test-case fail. 109790 109791 Tested on x86_64-linux and aarch64-linux. 109792 109793 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29420 109794 1097952022-07-29 Alan Modra <amodra@gmail.com> 109796 109797 Re: PR16005, avr linker crash on a particular instruction sequence with --relax 109798 The last patch wasn't so clever. The contents in fact have already 109799 been read, just not cached where relax_delete_bytes expects them. 109800 relax_delete_bytes also modifies relocs and syms, so they should be 109801 cached too. 109802 109803 PR 16005 109804 * elf32-avr.c (elf32_avr_relax_delete_bytes): Revert last change. 109805 (elf32_avr_relax_section): Cache contents, relocs and syms 109806 before calling relax_delete_bytes. 109807 1098082022-07-29 Andrew Burgess <aburgess@redhat.com> 109809 109810 libopcodes/aarch64: add support for disassembler styling 109811 This commit enables disassembler styling for AArch64. After this 109812 commit it is possible to have objdump style AArch64 disassembler 109813 output (using --disassembler-color option). Once the required GDB 109814 patches are merged, GDB will also style the disassembler output. 109815 109816 The changes to support styling are mostly split between two files 109817 opcodes/aarch64-dis.c and opcodes/aarch64-opc.c. 109818 109819 The entry point for the AArch64 disassembler can be found in 109820 aarch64-dis.c, this file handles printing the instruction mnemonics, 109821 and assembler directives (e.g. '.byte', '.word', etc). Some operands, 109822 mostly relating to assembler directives are also printed from this 109823 file. This commit changes all of this to pass through suitable 109824 styling information. 109825 109826 However, for most "normal" instructions, the instruction operands are 109827 printed using a two step process. From aarch64-dis.c, in the 109828 print_operands function, the function aarch64_print_operand is called, 109829 this function is in aarch64-opc.c, and converts an instruction operand 109830 into a string. Then, back in print_operands (aarch64-dis.c), the 109831 operand string is printed. 109832 109833 Unfortunately, the string returned by aarch64_print_operand can be 109834 quite complex, it will include syntax elements, like '[' and ']', in 109835 addition to register names and immediate values. In some cases, a 109836 single operand will expand into what will appear (to the user) as 109837 multiple operands separated with a ','. 109838 109839 This makes the task of styling more complex, all these different 109840 components need to by styled differently, so we need to get the 109841 styling information out of aarch64_print_operand in some way. 109842 109843 The solution that I propose here is similar to the solution that I 109844 used for the i386 disassembler. 109845 109846 Currently, aarch64_print_operand uses snprintf to write the operand 109847 text into a buffer provided by the caller. 109848 109849 What I propose is that we pass an extra argument to the 109850 aarch64_print_operand function, this argument will be a structure, the 109851 structure contains a callback function and some state. 109852 109853 When aarch64_print_operand needs to format part of its output this can 109854 be done by using the callback function within the new structure, this 109855 callback returns a string with special embedded markers that indicate 109856 which mode should be used for each piece of text. Back in 109857 aarch64-dis.c we can spot these special style markers and use this to 109858 split the disassembler output up and apply the correct style to each 109859 piece. 109860 109861 To make aarch64-opc.c clearer a series of new static functions have 109862 been added, e.g. 'style_reg', 'style_imm', etc. Each of these 109863 functions formats a piece of text in a different style, 'register' and 109864 'immediate' in this case. 109865 109866 Here's an example taken from aarch64-opc.c of the new functions in 109867 use: 109868 109869 snprintf (buf, size, "[%s, %s]!", 109870 style_reg (styler, base), 109871 style_imm (styler, "#%d", opnd->addr.offset.imm)); 109872 109873 The aarch64_print_operand function is also called from the assembler 109874 to aid in printing diagnostic messages. Right now I have no plans to 109875 add styling to the assembler output, and so, the callback function 109876 used in the assembler ignores the styling information and just returns 109877 an plain string. 109878 109879 I've used the source files in gas/testsuite/gas/aarch64/ for testing, 109880 and have manually gone through and checked that the styling looks 109881 reasonable, however, I'm not an AArch64 expert, so it is possible that 109882 the odd piece is styled incorrectly. Please point out any mistakes 109883 I've made. 109884 109885 With objdump disassembler color turned off, there should be no change 109886 in the output after this commit. 109887 1098882022-07-29 Nick Clifton <nickc@redhat.com> 109889 109890 Stop the linker from complaining about unrecognised DW_FORM-rnglistx and DW_FORM_loclistx format attributes. 109891 PR 29424 109892 * dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and 109893 DW_FORM_loclistx. 109894 1098952022-07-29 Alan Modra <amodra@gmail.com> 109896 109897 PR16005, avr linker crash on a particular instruction sequence with --relax 109898 It's possible for relax_delete_bytes to be called with section 109899 contents NULL, as demonstrated by the testcase in this PR. 109900 109901 PR 16005 109902 * elf32-avr.c (elf32_avr_relax_delete_bytes): Get section contents 109903 if not already available. 109904 1099052022-07-29 Jan Beulich <jbeulich@suse.com> 109906 109907 x86: drop stray NoRex64 from KeyLocker insns 109908 It's entirely unclear why some of the KeyLocker insns had NoRex64 on 109909 them - there's nothing here which could cause emission of REX.W (except 109910 of course a user-specified "rex.w", which we ought to honor anyway). 109911 1099122022-07-29 Jan Beulich <jbeulich@suse.com> 109913 109914 Arm64: re-work PR gas/27217 fix 109915 The original approach has resulted in anomalies when . is involved in an 109916 operand of one of the affected insns. We cannot leave . unresolved, or 109917 else it'll be resolved at the end of assembly, then pointing to the 109918 address of a section rather than at the insn of interest. Undo part of 109919 the original change and instead check whether a relocation cannot be 109920 omitted in md_apply_fix(). 109921 109922 By resolving the expressions again, equates (see the adjustment of the 109923 respective testcase) will now be evaluated, and hence relocations 109924 against absolute addresses be emitted. This ought to be okay as long as 109925 the equates aren't global (and hence can't be overridden). If a need 109926 for such arises, quite likely the only way to address this would be to 109927 invent yet another expression evaluation mode, leaving everything 109928 _except_ . un-evaluated. 109929 109930 There's a further anomaly in how transitive equates are handled. In 109931 109932 .set x, 0x12345678 109933 .eqv bar, x 109934 foo: 109935 adrp x0, x 109936 add x0, x0, :lo12:x 109937 109938 adrp x0, bar 109939 add x0, x0, :lo12:bar 109940 109941 the first two relocations are now against *ABS*:0x12345678 (as said 109942 above), whereas the latter two relocations would be against x. (Before 109943 the change here, the first two relocations are against x and the latter 109944 two against bar.) But this is an issue seen elsewhere as well, and would 109945 likely require adjustments in the target-independent parts of the 109946 assembler instead of trying to hack around this for every target. 109947 1099482022-07-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 109949 109950 ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411] 109951 As discussed in PR ld/29411, the ld warning 109952 109953 [...] has a LOAD segment with RWX permissions 109954 109955 needs to be disabled on all SPARC targets, not just Solaris/SPARC: the 109956 .plt section is required to be RWX by the 32-bit SPARC ELF psABI and the 109957 64-bit SPARC Compliance Definition 2.4.1. Given that ld only supports 109958 SPARC ELF targets, this patch implements this. 109959 109960 Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11. 109961 109962 2022-07-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 109963 109964 ld: 109965 PR ld/29411 109966 * configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all 109967 sparc targets. Expand comment. 109968 1099692022-07-29 Tom de Vries <tdevries@suse.de> 109970 109971 [gdb/testsuite] Fix gdb.threads/killed-outside.exp on aarch64 109972 On aarch64 (and likewise on arm), I run into: 109973 ... 109974 (gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior 109975 Executing on target: kill -9 11516 (timeout = 300) 109976 builtin_spawn -ignore SIGHUP kill -9 11516^M 109977 continue^M 109978 Continuing.^M 109979 Unable to fetch general registers: No such process.^M 109980 (gdb) [Thread 0xfffff7d511e0 (LWP 11518) exited]^M 109981 ^M 109982 Program terminated with signal SIGKILL, Killed.^M 109983 The program no longer exists.^M 109984 FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout) 109985 ... 109986 due to a mismatch between the actual "No such process" line and the expected 109987 one: 109988 ... 109989 set no_such_process_msg "Couldn't get registers: No such process\." 109990 ... 109991 109992 Fix this by updating the regexp. 109993 109994 Tested on aarch64-linux, and x86_64-linux. 109995 1099962022-07-29 Tsukasa OI <research_trasio@irq.a4lg.com> 109997 109998 RISC-V: Add `OP_V' to .insn named opcodes 109999 This commit adds `OP_V' (OP-V: vector instruction opcode for now 110000 ratified `V' extension) to .insn opcode name list. Although vector 110001 instruction encoding is not implemented in `.insn' directive, it will 110002 help future implementation of custom vector `.insn'. 110003 110004 gas/ChangeLog: 110005 110006 * config/tc-riscv.c (opcode_name_list): Add `OP_V'. 110007 * testsuite/gas/riscv/insn.s: Add testcase. 110008 * testsuite/gas/riscv/insn.d: Likewise. 110009 * testsuite/gas/riscv/insn-dwarf.d: Reflect insn.s update. 110010 1100112022-07-29 GDB Administrator <gdbadmin@sourceware.org> 110012 110013 Automatic date update in version.in 110014 1100152022-07-28 Tom Tromey <tom@tromey.com> 110016 110017 Remove some unneeded checks in Guile code 110018 The Guile code generally checks to see if an htab is non-null before 110019 destroying it. However, the registry code already ensures this, so we 110020 can change these checks to asserts and simplify the code a little. 110021 110022 Change registry to use less memory 110023 The registry code creates "registry_data" objects that hold the free 110024 function and the index; then the registry keys refer to this object. 110025 However, only the index is really useful, and now that registries have 110026 a private implementation, just the index can be stored and we can 110027 reduce the memory use of registries a little bit. This also 110028 simplifies the code somewhat. 110029 1100302022-07-28 Tom Tromey <tom@tromey.com> 110031 110032 Rewrite registry.h 110033 This rewrites registry.h, removing all the macros and replacing it 110034 with relatively ordinary template classes. The result is less code 110035 than the previous setup. It replaces large macros with a relatively 110036 straightforward C++ class, and now manages its own cleanup. 110037 110038 The existing type-safe "key" class is replaced with the equivalent 110039 template class. This approach ended up requiring relatively few 110040 changes to the users of the registry code in gdb -- code using the key 110041 system just required a small change to the key's declaration. 110042 110043 All existing users of the old C-like API are now converted to use the 110044 type-safe API. This mostly involved changing explicit deletion 110045 functions to be an operator() in a deleter class. 110046 110047 The old "save/free" two-phase process is removed, and replaced with a 110048 single "free" phase. No existing code used both phases. 110049 110050 The old "free" callbacks took a parameter for the enclosing container 110051 object. However, this wasn't truly needed and is removed here as 110052 well. 110053 1100542022-07-28 Tom Tromey <tom@tromey.com> 110055 110056 Remove some unused functions from guile code 110057 The guile code has a couple of unused functions that touch on the 110058 registry API. This patch removes them. 110059 1100602022-07-28 Tom Tromey <tom@tromey.com> 110061 110062 Change allocation of type-copying hash table 110063 When an objfile is destroyed, types that are still in use and 110064 allocated on that objfile are copied. A temporary hash map is created 110065 during this process, and it is allocated on the destroyed objfile's 110066 obstack -- which normally is fine, as that is going to be destroyed 110067 shortly anyway. 110068 110069 However, this approach requires that the objfile be passed to registry 110070 destruction, and this won't be possible in the rewritten registry. 110071 This patch changes the copied type hash table to simply use the heap 110072 instead. It also removes the 'objfile' parameter from 110073 copy_type_recursive, to make this all more clear. 110074 110075 This patch also fixes an apparent bug in copy_type_recursive. 110076 Previously it was copying the dynamic property list to the dying 110077 objfile's obstack: 110078 110079 - = copy_dynamic_prop_list (&objfile->objfile_obstack, 110080 110081 However I think this is incorrect -- that obstack is about to be 110082 destroyed. 110083 1100842022-07-28 Tom Tromey <tom@tromey.com> 110085 110086 Change address_space to use new and delete 110087 This changes address_space to use new and delete, and makes some other 110088 small C++-ification changes as well, like changing address_space_num 110089 to be a method. 110090 110091 This patch was needed for the subsequent patch to rewrite the registry 110092 system. 110093 1100942022-07-28 Simon Farre <simon.farre.cx@gmail.com> 110095 110096 gdb/python: Add BreakpointLocation type 110097 PR python/18385 110098 110099 v7: 110100 This version addresses the issues pointed out by Tom. 110101 110102 Added nullchecks for Python object creations. 110103 110104 Changed from using PyLong_FromLong to the gdb_py-versions. 110105 110106 Re-factored some code to make it look more cohesive. 110107 110108 Also added the more safe Python reference count decrement PY_XDECREF, 110109 even though the BreakpointLocation type is never instantiated by the 110110 user (explicitly documented in the docs) decrementing < 0 is made 110111 impossible with the safe call. 110112 110113 Tom pointed out that using the policy class explicitly to decrement a 110114 reference counted object was not the way to go, so this has instead been 110115 wrapped in a ref_ptr that handles that for us in blocpy_dealloc. 110116 110117 Moved macro from py-internal to py-breakpoint.c. 110118 110119 Renamed section at the bottom of commit message "Patch Description". 110120 110121 v6: 110122 This version addresses the points Pedro gave in review to this patch. 110123 110124 Added the attributes `function`, `fullname` and `thread_groups` 110125 as per request by Pedro with the argument that it more resembles the 110126 output of the MI-command "-break-list". Added documentation for these attributes. 110127 110128 Cleaned up left overs from copy+paste in test suite, removed hard coding 110129 of line numbers where possible. 110130 110131 Refactored some code to use more c++-y style range for loops 110132 wrt to breakpoint locations. 110133 110134 Changed terminology, naming was very inconsistent. Used a variety of "parent", 110135 "owner". Now "owner" is the only term used, and the field in the 110136 gdb_breakpoint_location_object now also called "owner". 110137 110138 v5: 110139 110140 Changes in response to review by Tom Tromey: 110141 - Replaced manual INCREF/DECREF calls with 110142 gdbpy_ref ptrs in places where possible. 110143 - Fixed non-gdb style conforming formatting 110144 - Get parent of bploc increases ref count of parent. 110145 - moved bploc Python definition to py-breakpoint.c 110146 110147 The INCREF of self in bppy_get_locations is due 110148 to the individual locations holding a reference to 110149 it's owner. This is decremented at de-alloc time. 110150 110151 The reason why this needs to be here is, if the user writes 110152 for instance; 110153 110154 py loc = gdb.breakpoints()[X].locations[Y] 110155 110156 The breakpoint owner object is immediately going 110157 out of scope (GC'd/dealloced), and the location 110158 object requires it to be alive for as long as it is alive. 110159 110160 Thanks for your review, Tom! 110161 110162 v4: 110163 Fixed remaining doc issues as per request 110164 by Eli. 110165 110166 v3: 110167 Rewritten commit message, shortened + reworded, 110168 added tests. 110169 110170 Patch Description 110171 110172 Currently, the Python API lacks the ability to 110173 query breakpoints for their installed locations, 110174 and subsequently, can't query any information about them, or 110175 enable/disable individual locations. 110176 110177 This patch solves this by adding Python type gdb.BreakpointLocation. 110178 The type is never instantiated by the user of the Python API directly, 110179 but is produced by the gdb.Breakpoint.locations attribute returning 110180 a list of gdb.BreakpointLocation. 110181 110182 gdb.Breakpoint.locations: 110183 The attribute for retrieving the currently installed breakpoint 110184 locations for gdb.Breakpoint. Matches behavior of 110185 the "info breakpoints" command in that it only 110186 returns the last known or currently inserted breakpoint locations. 110187 110188 BreakpointLocation contains 7 attributes 110189 110190 6 read-only attributes: 110191 owner: location owner's Python companion object 110192 source: file path and line number tuple: (string, long) / None 110193 address: installed address of the location 110194 function: function name where location was set 110195 fullname: fullname where location was set 110196 thread_groups: thread groups (inferiors) where location was set. 110197 110198 1 writeable attribute: 110199 enabled: get/set enable/disable this location (bool) 110200 110201 Access/calls to these, can all throw Python exceptions (documented in 110202 the online documentation), and that's due to the nature 110203 of how breakpoint locations can be invalidated 110204 "behind the scenes", either by them being removed 110205 from the original breakpoint or changed, 110206 like for instance when a new symbol file is loaded, at 110207 which point all breakpoint locations are re-created by GDB. 110208 Therefore this patch has chosen to be non-intrusive: 110209 it's up to the Python user to re-request the locations if 110210 they become invalid. 110211 110212 Also there's event handlers that handle new object files etc, if a Python 110213 user is storing breakpoint locations in some larger state they've 110214 built up, refreshing the locations is easy and it only comes 110215 with runtime overhead when the Python user wants to use them. 110216 110217 gdb.BreakpointLocation Python type 110218 struct "gdbpy_breakpoint_location_object" is found in python-internal.h 110219 110220 Its definition, layout, methods and functions 110221 are found in the same file as gdb.Breakpoint (py-breakpoint.c) 110222 110223 1 change was also made to breakpoint.h/c to make it possible 110224 to enable and disable a bp_location* specifically, 110225 without having its LOC_NUM, as this number 110226 also can change arbitrarily behind the scenes. 110227 110228 Updated docs & news file as per request. 110229 110230 Testsuite: tests the .source attribute and the disabling of 110231 individual locations. 110232 110233 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385 110234 110235 110236 Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0 110237 1102382022-07-28 yaowenbin <yaowenbin1@huawei.com> 110239 110240 gdb/gdb_mbuild.sh: use return instead of continue to avoid shellcheck error 110241 Fix: 110242 110243 In gdb_mbuild.sh line 174: 110244 continue 110245 ^------^ SC2104 (error): In functions, use return instead of continue. 110246 110247 Change-Id: I5ce95b01359c5cfbb1612f2f48b80bfeea66c96c 110248 1102492022-07-28 GDB Administrator <gdbadmin@sourceware.org> 110250 110251 Automatic date update in version.in 110252 1102532022-07-27 GDB Administrator <gdbadmin@sourceware.org> 110254 110255 Automatic date update in version.in 110256 1102572022-07-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 110258 110259 gprofng: check for the makeinfo version 110260 gprofng/ChangeLog 110261 2022-07-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 110262 110263 PR gprofng/29368 110264 * configure.ac: Check for the makeinfo version. 110265 * configure: Rebuild. 110266 1102672022-07-26 Keith Seitz <keiths@redhat.com> 110268 110269 gdb/linux_nat: Write memory using ptrace if /proc/pid/mem is not writable 110270 Commit 05c06f318fd9a112529dfc313e6512b399a645e4 enabled GDB to access 110271 memory while threads are running. It did this by accessing 110272 /proc/PID/task/LWP/mem. 110273 110274 Unfortunately, this interface is not implemented for writing in older 110275 kernels (such as RHEL6). This means that GDB is unable to insert 110276 breakpoints on these hosts: 110277 110278 $ ./gdb -q gdb -ex start 110279 Reading symbols from gdb... 110280 Temporary breakpoint 1 at 0x40fdd5: file ../../src/gdb/gdb.c, line 28. 110281 Starting program: /home/rhel6/fsf/linux/gdb/gdb 110282 Warning: 110283 Cannot insert breakpoint 1. 110284 Cannot access memory at address 0x40fdd5 110285 110286 (gdb) 110287 110288 Before this patch, linux_proc_xfer_memory_partial (previously called 110289 linux_proc_xfer_partial) would return TARGET_XFER_EOF if the write to 110290 /proc/PID/mem failed. [More specifically, linux_proc_xfer_partial 110291 would not "bother for one word," but the effect is the essentially 110292 same.] 110293 110294 This status was checked by linux_nat_target::xfer_partial, which would 110295 then fallback to using ptrace to perform the operation. 110296 110297 This is the specific hunk that removed the fallback: 110298 110299 - xfer = linux_proc_xfer_partial (object, annex, readbuf, writebuf, 110300 - offset, len, xfered_len); 110301 - if (xfer != TARGET_XFER_EOF) 110302 - return xfer; 110303 + return linux_proc_xfer_memory_partial (readbuf, writebuf, 110304 + offset, len, xfered_len); 110305 + } 110306 110307 return inf_ptrace_target::xfer_partial (object, annex, readbuf, writebuf, 110308 offset, len, xfered_len); 110309 110310 This patch makes linux_nat_target::xfer_partial go straight to writing 110311 memory via ptrace if writing via /proc/pid/mem is not possible in the 110312 running kernel, enabling GDB to insert breakpoints on these older 110313 kernels. Note that a recent patch changed the return status from 110314 TARGET_XFER_EOF to TARGET_XFER_E_IO. 110315 110316 Tested on {unix,native-gdbserver,native-extended-gdbserver}/-m{32,64} 110317 on x86_64, s390x, aarch64, and ppc64le. 110318 110319 Change-Id: If1d884278e8c4ea71d8836bedd56e6a6c242a415 110320 1103212022-07-26 Pedro Alves <pedro@palves.net> 110322 110323 gdb/linux-nat: Check whether /proc/pid/mem is writable 110324 Probe whether /proc/pid/mem is writable, by using it to write to a GDB 110325 variable. This will be used in the following patch to avoid falling 110326 back to writing to inferior memory with ptrace if /proc/pid/mem _is_ 110327 writable. 110328 110329 Change-Id: If87eff0b46cbe5e32a583e2977a9e17d29d0ed3e 110330 1103312022-07-26 Tiezhu Yang <yangtiezhu@loongson.cn> 110332 110333 gdb: LoongArch: Handle the function return value 110334 According to LoongArch ELF ABI specification [1], handle the function 110335 return value of various types. 110336 110337 [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_return_values 110338 1103392022-07-26 Tiezhu Yang <yangtiezhu@loongson.cn> 110340 110341 gdb: LoongArch: Fix code style issues 110342 Fix some code style issues suggested by Tom Tromey and Andrew Burgess, 110343 thank you. 110344 110345 (1) Put an introductory comment to explain the purpose for some functions. 110346 110347 (2) Modify the the attribute code to make it portable. 110348 110349 (3) Remove globals and pass pointers to locals. 110350 110351 (4) Remove "*" in the subsequent comment lines. 110352 110353 (5) Put two spaces before "{" and "}". 110354 1103552022-07-26 Nick Clifton <nickc@redhat.com> 110356 110357 Stop the linker from complaining about RWX segments in sparc-solaris targets. 110358 PR 29411 110359 * configure.tgt (ac_default_ld_warn_rwx_segments): Disable for 110360 sparc-solaris configurations. 110361 1103622022-07-26 Tom de Vries <tdevries@suse.de> 110363 110364 [gdb/testsuite] Fix gdb.opt/inline-small-func.exp with clang 110365 When running test-case gdb.opt/inline-small-func.exp with clang 12.0.1, I run 110366 into: 110367 ... 110368 gdb compile failed, /usr/bin/ld: inline-small-func0.o: in function `main': 110369 inline-small-func.c:21: undefined reference to `callee' 110370 clang-12.0: error: linker command failed with exit code 1 \ 110371 (use -v to see invocation) 110372 UNTESTED: gdb.opt/inline-small-func.exp: failed to prepare 110373 ... 110374 110375 Fix this by using __attribute__((always_inline)). 110376 110377 Tested on x86_64-linux. 110378 1103792022-07-26 Alan Modra <amodra@gmail.com> 110380 110381 PowerPC32 ld test fails with --enable-targets=all 110382 Three pppc32 ld tests fail when spe support is included in the linker 110383 due to this snippet in ld/emulparams/elf32ppc.sh. 110384 110385 if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then 110386 DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*) 110387 PROVIDE (__spe_handle = .); 110388 *(.data.spehandle) 110389 . += 4 * (DEFINED (__spe_handle) || . != 0);}" 110390 fi 110391 110392 * testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present. 110393 * testsuite/ld-powerpc/tlsexe32no.r: Likewise. 110394 * testsuite/ld-powerpc/tlsso32.r: Likewise. 110395 1103962022-07-26 Enze Li <enze.li@hotmail.com> 110397 110398 gdb/hurd: pass memory_tagged as false to find_memory_region_ftype 110399 I tried building GDB on GNU/Hurd, and ran into this error: 110400 110401 CXX gnu-nat.o 110402 gnu-nat.c: In member function ‘virtual int gnu_nat_target::find_memory_regions(find_memory_region_ftype, void*)’: 110403 gnu-nat.c:2620:21: error: too few arguments to function 110404 2620 | (*func) (last_region_address, 110405 | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ 110406 2621 | last_region_end - last_region_address, 110407 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110408 2622 | last_protection & VM_PROT_READ, 110409 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110410 2623 | last_protection & VM_PROT_WRITE, 110411 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110412 2624 | last_protection & VM_PROT_EXECUTE, 110413 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110414 2625 | 1, /* MODIFIED is unknown, pass it as true. */ 110415 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110416 2626 | data); 110417 | ~~~~~ 110418 gnu-nat.c:2635:13: error: too few arguments to function 110419 2635 | (*func) (last_region_address, last_region_end - last_region_address, 110420 | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110421 2636 | last_protection & VM_PROT_READ, 110422 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110423 2637 | last_protection & VM_PROT_WRITE, 110424 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110425 2638 | last_protection & VM_PROT_EXECUTE, 110426 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110427 2639 | 1, /* MODIFIED is unknown, pass it as true. */ 110428 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 110429 2640 | data); 110430 | ~~~~~ 110431 make[2]: *** [Makefile:1926: gnu-nat.o] Error 1 110432 110433 This is because in this commit: 110434 110435 commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1 110436 Date: Thu Mar 31 11:42:35 2022 +0100 110437 110438 [AArch64] MTE corefile support 110439 110440 Added a new argument to find_memory_region_ftype, but did not pass it to 110441 the function in gnu-nat.c. Fix this by passing memory_tagged as false. 110442 110443 As Luis pointed out, similar bugs may also appear on FreeBSD and NetBSD, 110444 and I have reproduced them on both systems. This patch fixes them 110445 incidentally. 110446 110447 Tested by rebuilding on GNU/Hurd, FreeBSD/amd64 and NetBSD/amd64. 110448 1104492022-07-26 Enze Li <enze.li@hotmail.com> 110450 110451 gdb/netbsd: add missing header file 110452 I ran into this error when building GDB on NetBSD: 110453 110454 CXX netbsd-nat.o 110455 netbsd-nat.c: In member function 'virtual bool nbsd_nat_target::info_proc(const char*, info_proc_what)': 110456 netbsd-nat.c:314:3: error: 'gdb_argv' was not declared in this scope 110457 gdb_argv built_argv (args); 110458 ^~~~~~~~ 110459 netbsd-nat.c:314:3: note: suggested alternative: 'gdbarch' 110460 gdb_argv built_argv (args); 110461 ^~~~~~~~ 110462 gdbarch 110463 netbsd-nat.c:315:7: error: 'built_argv' was not declared in this scope 110464 if (built_argv.count () == 0) 110465 ^~~~~~~~~~ 110466 netbsd-nat.c:315:7: note: suggested alternative: 'buildargv' 110467 if (built_argv.count () == 0) 110468 ^~~~~~~~~~ 110469 buildargv 110470 gmake[2]: *** [Makefile:1893: netbsd-nat.o] Error 1 110471 110472 Fix this by adding the missing header file, as it is obvious. 110473 110474 Tested by rebuilding on NetBSD/amd64. 110475 1104762022-07-26 Nick Clifton <nickc@redhat.com> 110477 110478 Updated translations for various sub-directories 110479 1104802022-07-26 Andrew Burgess <aburgess@redhat.com> 110481 110482 gdb: rename gdbarch_tdep struct to fix g++ 4.8 build 110483 After the commit: 110484 110485 commit 08106042d9f5fdff60c129bf33190639f1a98b2a 110486 Date: Thu May 19 13:20:17 2022 +0100 110487 110488 gdb: move the type cast into gdbarch_tdep 110489 110490 GDB would no longer build using g++ 4.8. The issue appears to be some 110491 confusion caused by GDB having 'struct gdbarch_tdep', but also a 110492 templated function called 'gdbarch_tdep'. Prior to the above commit 110493 the gdbarch_tdep function was not templated, and this compiled just 110494 fine. Note that the above commit compiles just fine with later 110495 versions of g++, so this issue was clearly fixed at some point, though 110496 I've not tried to track down exactly when. 110497 110498 In this commit I propose to fix the g++ 4.8 build problem by renaming 110499 'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename 110500 better represents that the struct is only ever used as a base class, 110501 and removes the overloading of the name, which allows GDB to build 110502 with g++ 4.8. 110503 110504 I've also updated the comment on 'struct gdbarch_tdep_base' to fix a 110505 typo, and the comment on the 'gdbarch_tdep' function, to mention that 110506 in maintainer mode a run-time type check is performed. 110507 1105082022-07-26 Nick Clifton <nickc@redhat.com> 110509 110510 Fix indentation in loongarch code, preventing a compile time warning. 110511 1105122022-07-26 Lancelot SIX <lancelot.six@amd.com> 110513 110514 gdb/varobj: Fix varobj_invalidate_iter 110515 The varobj_invalidate function is meant to be called when restarting a 110516 process, and check at this point if some of the previously existing 110517 varobj can be recreated in the context of the new process. 110518 110519 Two kind of varobj are subject to re-creation: global varobj (i.e. 110520 varobj which reference a global variable), and floating varobj (i.e. 110521 varobj which are always re-evaluated in the context of whatever is 110522 the currently selected frame at the time of evaluation). 110523 110524 However, in the re-creation process, the varobj_invalidate_iter 110525 recreates floating varobj as non-floating, due to an invalid parameter. 110526 This patches fixes this and adds an assertion to check that if a varobj 110527 is indeed recreated, it matches the original varobj "floating" property. 110528 110529 Another issue is that if at this recreation time the expression watched 110530 by the floating varobj is not in scope, then the varobj is marked as 110531 invalid. If later the user selects a frame where the expression becomes 110532 valid, the varobj remains invalid and this is wrong. This patch also 110533 make sure that floating varobj are not invalidated if they cannot be 110534 evaluated. 110535 110536 The last important thing to note is that due to the previous patch, when 110537 varobj_invalidate is executed (in the context of a new process), any 110538 global var have already been invalidated (this has been done when the 110539 objfile it referred to got invalidated). As a consequence, 110540 varobj_invalidate tries to recreate vars which are already marked as 110541 invalid. This does not entirely feels right, but I keep this behavior 110542 for backward compatibility. 110543 110544 Tested on x86_64-linux 110545 1105462022-07-26 Lancelot SIX <lancelot.six@amd.com> 110547 110548 gdb/varobj: Fix use after free in varobj 110549 Varobj object contains references to types, variables (i.e. struct 110550 variable) and expression. All of those can reference data on an 110551 objfile's obstack. It is possible for this objfile to be deleted (and 110552 the obstack to be feed), while the varobj remains valid. Later, if the 110553 user uses the varobj, this will result in a use-after-free error. With 110554 address sanitizer build, this leads to a plain error. For non address 110555 sanitizer build we might see undefined behaviour, which manifest 110556 themself as assertion failures when accessing data backed by feed 110557 memory. 110558 110559 This can be observed if we create a varobj that refers to ta symbol in a 110560 shared library, after either the objfile gets reloaded (using the `file` 110561 command) or after the shared library is unloaded (with a call to dlclose 110562 for example). 110563 110564 This patch fixes those issues by: 110565 110566 - Adding cleanup procedure to the free_objfile observable. When 110567 activated this observer clears expressions referencing the objfile 110568 being freed, and removes references to blocks belonging to this 110569 objfile. 110570 - Adding varobj support in the `preserve_values` (gdb.value.c). This 110571 ensures that before the objfile is unloaded, any type owned by the 110572 objfile referenced by the varobj is replaced by an equivalent type 110573 not owned by the objfile. This process is done here instead of in the 110574 free_objfile observer in order to reuse the type hash table already 110575 used for similar purpose when replacing types of values kept in the 110576 value history. 110577 110578 This patch also makes sure to keep a reference to the expression's 110579 gdbarch and language_defn members when the varobj->root->exp is 110580 initialized. Those structures outlive the objfile, so this is safe. 110581 This is done because those references might be used initialize a python 110582 context even after exp is invalidated. Another approach could have been 110583 to initialize the python context with default gdbarch and language_defn 110584 (i.e. nullptr) if expr is NULL, but since we might still try to display 110585 the value which was obtained by evaluating exp when it was still valid, 110586 keeping track of the context which was used at this time seems 110587 reasonable. 110588 110589 Tested on x86_64-Linux. 110590 110591 Co-Authored-By: Pedro Alves <pedro@palves.net> 110592 1105932022-07-26 Pedro Alves <pedro@palves.net> 110594 110595 MI: mi_runto -pending 110596 With the CLI testsuite's runto proc, we can pass "allow-pending" as an 110597 option, like: 110598 110599 runto func allow-pending 110600 110601 That is currently not possible with MI's mi_runto, however. This 110602 patch makes it possible, by adding a new "-pending" option to 110603 mi_runto. 110604 110605 A pending breakpoint shows different MI attributes compared to a 110606 breakpoint with a location, so the regexp returned by 110607 mi_make_breakpoint isn't suitable. Thus, add a new 110608 mi_make_breakpoint_pending proc for pending breakpoints. 110609 110610 Tweak mi_runto to let it take and pass down arguments. 110611 110612 Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c 110613 1106142022-07-26 GDB Administrator <gdbadmin@sourceware.org> 110615 110616 Automatic date update in version.in 110617 1106182022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com> 110619 110620 gprofng: fix bug 29356 - Execution fails if gprofng is not included in PATH 110621 gprofng/Changelog: 110622 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com> 110623 110624 PR gprofng/29356 110625 * gp-display-html/gp-display-html.in: fixed a problem to execute 110626 gp-display-text in case gprofng is not included in the search 110627 path. 110628 1106292022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com> 110630 110631 gprofng: fix bug 29392 - Unexpected line format in summary file 110632 gprofng/Changelog: 110633 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com> 110634 110635 PR gprofng/29392 110636 * gp-display-html/gp-display-html.in: modified a regex, plus the 110637 code to handle the results; renamed a variable to improve the 110638 consistency in naming. 110639 1106402022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com> 110641 110642 gprofng: fix bug 29353 - Fix a lay-out issue in the html disassembly files 110643 gprofng/Changelog: 110644 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com> 110645 110646 PR gprofng/29353 110647 * gp-display-html/gp-display-html.in: fixed a problem in the 110648 generation of html for the disassembly where instructions 110649 without arguments were not handled correctly. 110650 1106512022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com> 110652 110653 gprofng: fix bug 29352 - Fix the message Hexadecimal number > 0xffffffff non-portable 110654 gprofng/Changelog: 110655 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com> 110656 110657 PR gprofng/29352 110658 * gp-display-html/gp-display-html.in: the hex subroutine from 110659 the bigint module is now used. 110660 1106612022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com> 110662 110663 gprofng: fix bug 29351 - Move dynamic loading of modules to a later stage 110664 gprofng/Changelog: 110665 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com> 110666 110667 PR gprofng/29351 110668 * gp-display-html/gp-display-html.in: the dynamic loading of 110669 modules occurred too early, resulting in the generation of the 110670 man page to fail in case a module is missing; the loading part is 110671 now done somewhat later in the execution to avoid this problem. 110672 1106732022-07-25 Kevin Buettner <kevinb@redhat.com> 110674 110675 set/show python dont-write-bytecode fixes 110676 GDB uses the environment variable PYTHONDONTWRITEBYTECODE to 110677 determine whether or not to write the result of byte-compiling 110678 python modules when the "python dont-write-bytecode" setting 110679 is "auto". Simon noticed that GDB's implementation doesn't 110680 follow the Python documentation. 110681 110682 At present, GDB only checks for the existence of this environment 110683 variable. That is not sufficient though. Regarding 110684 PYTHONDONTWRITEBYTECODE, this document... 110685 110686 https://docs.python.org/3/using/cmdline.html 110687 110688 ...says: 110689 110690 If this is set to a non-empty string, Python won't try to write 110691 .pyc files on the import of source modules. 110692 110693 This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding 110694 an empty string check. 110695 110696 This commit also corrects the set/show command documentation for 110697 "python dont-write-bytecode". The current doc was just a copy 110698 of that for set/show python ignore-environment. 110699 110700 During his review of an earlier version of this patch, Eli Zaretskii 110701 asked that the help text that I proposed for "set/show python 110702 dont-write-bytecode" be expanded. I've done that in addition to 110703 clarifying the documentation of this option in the GDB manual. 110704 1107052022-07-25 Andrew Burgess <aburgess@redhat.com> 110706 110707 gdb/python: fix invalid use disassemble_info::stream 110708 After this commit: 110709 110710 commit 81384924cdcc9eb2676dd9084b76845d7d0e0759 110711 Date: Tue Apr 5 11:06:16 2022 +0100 110712 110713 gdb: have gdb_disassemble_info carry 'this' in its stream pointer 110714 110715 The disassemble_info::stream field will no longer be a ui_file*. That 110716 commit failed to update one location in py-disasm.c though. 110717 110718 While running some tests using the Python disassembler API, I 110719 triggered a call to gdbpy_disassembler::print_address_func, and, as I 110720 had compiled GDB with the undefined behaviour sanitizer, GDB crashed 110721 as the code currently (incorrectly) casts the stream field to be a 110722 ui_file*. 110723 110724 In this commit I fix this error. 110725 110726 In order to test this case I had to tweak the existing test case a 110727 little. I also spotted some debug printf statements in py-disasm.py, 110728 which I have removed. 110729 1107302022-07-25 Andrew Burgess <aburgess@redhat.com> 110731 110732 gdb: fix use of uninitialised gdb_printing_disassembler::m_in_comment 110733 Simon pointed out that gdb_printing_disassembler::m_in_comment can be 110734 used uninitialised by the Python disassembler API code. This issue 110735 was spotted when GDB was built with the undefined behaviour sanitizer, 110736 and causes the gdb.python/py-disasm.exp test to fail like this: 110737 110738 (gdb) PASS: gdb.python/py-disasm.exp: global_disassembler=GlobalPreInfoDisassembler: python add_global_disassembler(GlobalPreInfoDisassembler) 110739 disassemble main 110740 Dump of assembler code for function main: 110741 0x0000555555555119 <+0>: push %rbp 110742 0x000055555555511a <+1>: mov %rsp,%rbp 110743 0x000055555555511d <+4>: nop 110744 /home/user/src/binutils-gdb/gdb/disasm.h:144:12: runtime error: load of value 118, which is not a valid value for type 'bool' 110745 110746 The problem is that in disasmpy_builtin_disassemble we create a new 110747 instance of gdbpy_disassembler, which is a sub-class of 110748 gdb_printing_disassembler, however, the m_in_comment field is never 110749 initialised. 110750 110751 This commit fixes the issue by providing a default initialisation 110752 value for m_in_comment in disasm.h. As we only ever disassemble a 110753 single instruction in disasmpy_builtin_disassemble then we don't need 110754 to worry about reseting m_in_comment back to false after the single 110755 instruction has been disassembled. 110756 110757 With this commit the above issue is resolved and 110758 gdb.python/py-disasm.exp now passes. 110759 1107602022-07-25 H.J. Lu <hjl.tools@gmail.com> 110761 110762 ld: Compile 2 CTF tests with -O2 110763 When GCC 12 is used to build binutils with -O0, the following 2 tests 110764 failed: 110765 110766 FAIL: Conflicted data syms, partially indexed, stripped, with variables 110767 FAIL: Conflicted data syms, partially indexed, stripped 110768 110769 Compile 2 tests with -O2 to avoid test failures. 110770 110771 PR ld/29378 110772 * testsuite/ld-ctf/data-func-conflicted-vars.d: Compile with -O2. 110773 * testsuite/ld-ctf/data-func-conflicted.d: Likewise. 110774 1107752022-07-25 Pedro Alves <pedro@palves.net> 110776 110777 struct packed: Add fallback byte array implementation 110778 Attribute gcc_struct is not implemented in Clang targeting Windows, so 110779 add a fallback standard-conforming implementation based on arrays. 110780 110781 I ran the testsuite on x86_64 GNU/Linux with this implementation 110782 forced, and saw no regressions. 110783 110784 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 110785 110786 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374 110787 1107882022-07-25 Pedro Alves <pedro@palves.net> 110789 110790 struct packed: Unit tests and more operators 110791 For PR gdb/29373, I wrote an alternative implementation of struct 110792 packed that uses a gdb_byte array for internal representation, needed 110793 for mingw+clang. While adding that, I wrote some unit tests to make 110794 sure both implementations behave the same. While at it, I implemented 110795 all relational operators. This commit adds said unit tests and 110796 relational operators. The alternative gdb_byte array implementation 110797 will come next. 110798 110799 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 110800 110801 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374 110802 1108032022-07-25 Pedro Alves <pedro@palves.net> 110804 110805 struct packed: Use gcc_struct on Windows 110806 Building GDB on mingw/gcc hosts is currently broken, due to a static 110807 assertion failure in gdbsupport/packed.h: 110808 110809 In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201, 110810 from ../../../../../binutils-gdb/gdb/defs.h:28, 110811 from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31: 110812 ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]': 110813 ../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74: required from here 110814 ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed 110815 41 | gdb_static_assert (sizeof (packed) == Bytes); 110816 | ~~~~~~~~~~~~~~~~^~~~~~~~ 110817 ../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert' 110818 27 | #define gdb_static_assert(expr) static_assert (expr, "") 110819 | ^~~~ 110820 ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)' 110821 41 | gdb_static_assert (sizeof (packed) == Bytes); 110822 | ~~~~~~~~~~~~~~~~^~~~~~~~ 110823 110824 110825 The issue is that mingw gcc defaults to "-mms-bitfields", which 110826 affects how bitfields are laid out. We can however tell GCC that we 110827 want the regular GCC layout instead using attribute gcc_struct. 110828 110829 Attribute gcc_struct is not implemented in "clang -target 110830 x86_64-pc-windows-gnu", so that will need a different fix. 110831 110832 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 110833 110834 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374 110835 1108362022-07-25 Andrew Burgess <aburgess@redhat.com> 110837 110838 binutils-gdb/git: highlight whitespace errors in source files 110839 For a long time I've had this in my ~/.gitconfig: 110840 110841 [core] 110842 whitespace = space-before-tab,indent-with-non-tab,trailing-space 110843 110844 which causes git to show me if I muck up and use spaces instead of 110845 tabs, or leave in trailing whitespace. I find this really useful. 110846 110847 I recently proposed adding something like this to the .gitattributes 110848 files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1], 110849 however, the question was asked - couldn't this be done at the top 110850 level? 110851 110852 So, in this commit, I propose to update the top-level .gitattributes 110853 file, after this commit, any git diff on a C, C++, Expect, or TCL 110854 source file, will highlight the following whitespace errors: 110855 110856 (a) Use a space before a tab at the start of a line, 110857 110858 (b) Use of spaces where a tab could be used at the start of a line, 110859 and 110860 110861 (c) Any trailing whitespace. 110862 110863 Errors are only highlighted in the diff on new or modified lines, so 110864 you don't get spammed for errors on context lines that you haven't 110865 modified. 110866 110867 The only downside I see to adding this at the top level is if there 110868 are any sub-directories that don't follow the tabs/spaces indentation 110869 rules very well already, in those directories you'll end up hitting 110870 issues any time you edit a line. For GDB we're usually pretty good, 110871 so having this highlighting isn't an issue. 110872 110873 [1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html 110874 1108752022-07-25 Yvan Roux <yvan.roux@foss.st.com> 110876 110877 gdb/arm: Sync sp with other *sp registers 110878 For Arm Cortex-M33 with security extensions, there are 4 different 110879 stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security 110880 extensions and for other Cortex-M targets, there are 2 different 110881 stack pointers (msp and psp). 110882 110883 With this patch, sp will always be in sync with one of the real stack 110884 pointers on Arm targets that contain more than one stack pointer. 110885 1108862022-07-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 110887 110888 gdb/arm: Use if-else if instead of switch 110889 As the register numbers for the alternative Arm SP registers are not 110890 constant, it's not possible to use switch statement to define the 110891 rules. In order to not have a mix, replace the few existing 110892 switch statements with regular if-else if statements 110893 1108942022-07-25 Tom Tromey <tromey@adacore.com> 110895 110896 Remove dead code from windows_nat_target::detach 110897 windows_nat_target::detach has a variable 'detached' that is only set 110898 after a call to 'error'. However, this can't happen because 'error' 110899 throws an exception. 110900 110901 This patch removes the dead code. 110902 1109032022-07-25 Andrew Burgess <aburgess@redhat.com> 110904 110905 gdb: handle dis_style_sub_mnemonic disassembler style 110906 In commit: 110907 110908 commit 4f46c0bc36471b725de0253bfec1a42a36e2c5c5 110909 Date: Mon Jul 4 17:45:25 2022 +0100 110910 110911 opcodes: add new sub-mnemonic disassembler style 110912 110913 I added a new disassembler style dis_style_sub_mnemonic, but forgot to 110914 add GDB support for this style. Fix this oversight in this commit. 110915 1109162022-07-25 Andrew Burgess <aburgess@redhat.com> 110917 110918 libopcodes/ppc: add support for disassembler styling 110919 This commit adds disassembler styling to the libopcodes ppc 110920 disassembler. This conversion was pretty straight forward, I just 110921 converted the fprintf_func calls to fprintf_styled_func calls and 110922 added an appropriate style. 110923 110924 For testing the new styling I just assembled then disassembled the 110925 source files in gas/testsuite/gas/ppc and manually checked that the 110926 styling looked reasonable. 110927 110928 I think the only slightly weird case was how things like '4*cr1+eq' 110929 are styled. As best I can tell, this construct, used for example in 110930 this instruction: 110931 110932 crand 4*cr1+lt,4*cr1+gt,4*cr1+eq 110933 110934 is used to access a field of a control register. I initially tried 110935 styling this whole construct as a register[1], but during review it 110936 was suggested that instead different parts of the text should have 110937 different styles. In this commit I propose styling '4*cr1+lt' like 110938 this: 110939 110940 4 - immediate, 110941 * - text, 110942 cr1 - register 110943 + - text 110944 lt - sub-mnemonic 110945 110946 If the user does not request styled output from objdump, then there 110947 should be no change in the disassembler output after this commit. 110948 110949 [1] https://sourceware.org/pipermail/binutils/2022-July/121771.html 110950 1109512022-07-25 Andrew Burgess <aburgess@redhat.com> 110952 110953 opcodes: add new sub-mnemonic disassembler style 110954 When adding libopcodes disassembler styling support for AArch64, it 110955 feels like the results would be improved by having a new sub-mnemonic 110956 style. This will be used in cases like: 110957 110958 add w16, w7, w1, uxtb #2 110959 ^^^^----- Here 110960 110961 And: 110962 110963 cinc w0, w1, ne 110964 ^^----- Here 110965 110966 This commit just adds the new style, and prepares objdump to handle 110967 the style. A later commit will add AArch64 styling, and will actually 110968 make use of the style. 110969 110970 As this style is currently unused, there should be no user visible 110971 changes after this commit. 110972 1109732022-07-25 liuzhensong <liuzhensong@loongson.cn> 110974 110975 LoongArch: Add testcases for new relocate types. 110976 gas/testsuite/gas/all/ 110977 gas.exp 110978 gas/testsuite/gas/loongarch/ 110979 jmp_op.d 110980 jmp_op.s 110981 macro_op.d 110982 macro_op.s 110983 macro_op_32.d 110984 macro_op_32.s 110985 macro_op_large_abs.d 110986 macro_op_large_abs.s 110987 macro_op_large_pc.d 110988 macro_op_large_pc.s 110989 reloc.d 110990 reloc.s 110991 110992 ld/testsuite/ld-elf/ 110993 pr26936.d 110994 shared.exp 110995 ld/testsuite/ld-loongarch-elf/ 110996 attr-ifunc-4.c 110997 attr-ifunc-4.out 110998 disas-jirl.d 110999 ifunc.exp 111000 jmp_op.d 111001 jmp_op.s 111002 libnopic-global.s 111003 macro_op.d 111004 macro_op.s 111005 macro_op_32.d 111006 macro_op_32.s 111007 nopic-global-so.rd 111008 nopic-global-so.sd 111009 nopic-global.out 111010 nopic-global.s 111011 nopic-global.sd 111012 nopic-global.xd 111013 nopic-local.out 111014 nopic-local.rd 111015 nopic-local.s 111016 nopic-local.sd 111017 nopic-local.xd 111018 nopic-weak-global-so.rd 111019 nopic-weak-global-so.sd 111020 nopic-weak-global.out 111021 nopic-weak-global.s 111022 nopic-weak-global.sd 111023 nopic-weak-global.xd 111024 nopic-weak-local.out 111025 nopic-weak-local.rd 111026 nopic-weak-local.s 111027 nopic-weak-local.sd 111028 nopic-weak-local.xd 111029 pic.exp 111030 pic.ld 111031 1110322022-07-25 liuzhensong <liuzhensong@loongson.cn> 111033 111034 bfd: Delete R_LARCH_NONE from dyn info of LoongArch. 111035 Some R_LARCH_64 in section .eh_frame will to generate 111036 R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL 111037 from R_LARCH_64 in setction .eh_frame and not generate 111038 dynamic relocation for R_LARCH_32_PCREL. 111039 111040 Add New relocate type R_LARCH_32_PCREL for .eh_frame. 111041 111042 include/elf/ 111043 loongarch.h 111044 111045 bfd/ 111046 bfd/bfd-in2.h 111047 libbfd.h 111048 reloc.c 111049 elfxx-loongarch.c 111050 elfnn-loongarch.c 111051 111052 gas/config/ 111053 tc-loongarch.c 111054 111055 binutils/ 111056 readelf.c 111057 111058 ld/testsuite/ld-elf/ 111059 eh5.d 111060 1110612022-07-25 liuzhensong <liuzhensong@loongson.cn> 111062 111063 LoongArch: Move ifunc info to rela.dyn from rela.plt. 111064 Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when 111065 loading lazy function (rela.plt section). 111066 111067 In dynamic programes, move ifunc dynamic relocate info to section 111068 srelgot from srelplt. 111069 111070 bfd/ 111071 elfnn-loongarch.c 111072 1110732022-07-25 liuzhensong <liuzhensong@loongson.cn> 111074 111075 LoongArch: gas: Add new reloc types. 111076 Generate new relocate types while use new macro insns. 111077 111078 gas/config/ 111079 loongarch-lex.h 111080 loongarch-parse.y 111081 tc-loongarch.c 111082 tc-loongarch.h 111083 1110842022-07-25 liuzhensong <liuzhensong@loongson.cn> 111085 111086 LoongArch:opcodes: Add new reloc types. 111087 opcodes: Replace old insns with news and generate new relocate types 111088 while macro insns expanding. 111089 111090 opcodes/ 111091 loongarch-opc.c 111092 1110932022-07-25 liuzhensong <liuzhensong@loongson.cn> 111094 111095 bfd: Add supported for LoongArch new relocations. 111096 Define new reloc types according to linker needs. 111097 111098 include/elf/ 111099 loongarch.h 111100 111101 bfd/ 111102 bfd-in2.h 111103 libbfd.h 111104 reloc.c 111105 elfnn-loongarch.c 111106 elfxx-loongarch.c 111107 elfxx-loongarch.h 111108 1111092022-07-25 Alan Modra <amodra@gmail.com> 111110 111111 Re: PowerPC64 .branch_lt address 111112 On seeing PR29369 my suspicion was naturally on a recent powerpc64 111113 change, commit 0ab80031430e. Without a reproducer, I spent time 111114 wondering what could have gone wrong, and while I doubt this patch 111115 would have fixed the PR, there are some improvements that can be made 111116 to cater for user silliness. 111117 111118 I also noticed that when -z relro -z now sections are created out of 111119 order, with .got before .plt in the section headers but .got is laid 111120 out at a higher address. That's due to the address expression for 111121 .branch_lt referencing SIZEOF(.got) and so calling init_os (which 111122 creates a bfd section) for .got before the .plt section is created. 111123 Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR 111124 which need to reference section vma and lma respectively, SIZEOF can 111125 and does cope with a missing bfd section by returning zero for its 111126 size, which of course is correct. 111127 111128 PR 29369 111129 * ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF. 111130 * emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise 111131 .branch_lt address to take into account possible user sections 111132 with alignment larger than 8 bytes. 111133 1111342022-07-25 GDB Administrator <gdbadmin@sourceware.org> 111135 111136 Automatic date update in version.in 111137 1111382022-07-24 Enze Li <enze.li@hotmail.com> 111139 111140 gdb/testsuite: add a clear test to py-breakpoint.exp 111141 This patch adds a test case to try to clear an internal python 111142 breakpoint using the clear command. 111143 111144 This was suggested by Pedro during a code review of the following 111145 commit. 111146 111147 commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6 111148 Date: Sun Apr 17 15:09:46 2022 +0800 111149 111150 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) 111151 111152 Tested on x86_64 openSUSE Tumbleweed. 111153 1111542022-07-24 Enze Li <enze.li@hotmail.com> 111155 111156 gdb/testsuite: rename get_maint_bp_addr and move it to gdb-utils.exp 111157 The get_maint_bp_addr procedure will be shared by other test suite, so 111158 move it to gdb-utils.exp. 111159 111160 Following Andrew's suggestion, I renamed get_maint_bp_addr to 111161 gdb_get_bp_addr, since it would have handled normal breakpoints in 111162 addition to the internal ones. Note that there is still room for 111163 improvement in this procedure, which I indicated in comments nearby. 111164 1111652022-07-24 GDB Administrator <gdbadmin@sourceware.org> 111166 111167 Automatic date update in version.in 111168 1111692022-07-23 GDB Administrator <gdbadmin@sourceware.org> 111170 111171 Automatic date update in version.in 111172 1111732022-07-22 Tom de Vries <tdevries@suse.de> 111174 111175 [gdb/symtab] Fix duplicate CUs in all_comp_units 111176 When running test-case gdb.cp/cpexprs-debug-types.exp with target board 111177 cc-with-debug-names on a system with gcc 12.1.1 (defaulting to dwarf 5), I 111178 run into: 111179 ... 111180 (gdb) file cpexprs-debug-types^M 111181 Reading symbols from cpexprs-debug-types...^M 111182 warning: Section .debug_aranges in cpexprs-debug-types has duplicate \ 111183 debug_info_offset 0x0, ignoring .debug_aranges.^M 111184 gdb/dwarf2/read.h:309: internal-error: set_length: \ 111185 Assertion `m_length == length' failed.^M 111186 ... 111187 111188 The exec contains a .debug_names section, which gdb rejects due to 111189 .debug_names containing a list of TUs, while the exec doesn't contain a 111190 .debug_types section (which is what you'd expect for dwarf 4). 111191 111192 Gdb then falls back onto the cooked index, which calls create_all_comp_units 111193 to create all_comp_units. However, the failed index reading left some 111194 elements in all_comp_units, so we end up with duplicates in all_comp_units, 111195 which causes the misleading complaint and the assert. 111196 111197 Fix this by: 111198 - asserting at the start of create_all_comp_units that all_comp_units is empty, 111199 as we do in create_cus_from_index and create_cus_from_debug_names, and 111200 - cleaning up all_comp_units when failing in dwarf2_read_debug_names. 111201 111202 Add a similar cleanup in dwarf2_read_gdb_index. 111203 111204 Tested on x86_64-linux. 111205 111206 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381 111207 1112082022-07-22 Simon Marchi <simon.marchi@polymtl.ca> 111209 111210 gdb/testsuite: give binaries distinct names in Ada tests 111211 Some Ada tests repeat their test sequence with different gnat-encodings, 111212 typically "all" and "minimal". However, they give the same name to both 111213 binaries, meaning the second run overwrites the binary of the first run. 111214 This makes it difficult and confusing when trying to reproduce problems 111215 manually with the test artifacts. Change those tests to use unique 111216 names for each pass. 111217 111218 Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88 111219 1112202022-07-22 Tom Tromey <tromey@adacore.com> 111221 111222 Change target_ops::async to accept bool 111223 This changes the parameter of target_ops::async from int to bool. 111224 Regression tested on x86-64 Fedora 34. 111225 111226 Fix typo in windows-nat.c 111227 I noticed a typo in a printf in windows-nat.c. This fixes it. 111228 1112292022-07-22 Tom de Vries <tdevries@suse.de> 111230 111231 [gdb] Add empty range unit test for gdb::parallel_for_each 111232 Add a unit test that verifies that we can call gdb::parallel_for_each with an 111233 empty range. 111234 111235 Tested on x86_64-linux. 111236 1112372022-07-22 Alan Modra <amodra@gmail.com> 111238 111239 PR17122, OSX 10.9 build failure 111240 sbrk hasn't been used in binutils/ or ld/ for quite some time (so the 111241 PR was fixed a while ago). Tidy up configury. 111242 111243 PR 17122 111244 binutils/ 111245 * configure.ac: Don't check for sbrk. 111246 * sysdep.h (sbrk): Don't supply fallback declaration. 111247 * config.in: Regenerate. 111248 * configure: Regenerate. 111249 ld/ 111250 * configure.ac: Don't check for sbrk. 111251 * config.in: Regenerate. 111252 * configure: Regenerate. 111253 1112542022-07-22 Jiangshuai Li <jiangshuai_li@linux.alibaba-inc.com> 111255 111256 gdb/csky modify registers list for general_reggroup 111257 There are two modification points here: 111258 1. For the debugging of csky architecture, after executing "info register", 111259 we hope to print out GPRs, PC and the registers related to exceptions. 111260 2. With tdesc-xml, users can view the register groups described in XML. 111261 1112622022-07-22 Alan Modra <amodra@gmail.com> 111263 111264 PR15951, binutils testsuite builds status wrapper unconditionally 111265 PR 15951 111266 * testsuite/binutils-all/objcopy.exp: Build testglue.o when 111267 needs_status_wrapper. 111268 1112692022-07-22 GDB Administrator <gdbadmin@sourceware.org> 111270 111271 Automatic date update in version.in 111272 1112732022-07-21 Peter Bergner <bergner@linux.ibm.com> 111274 111275 Add ChangeLog entry from previous commit 111276 1112772022-07-21 Peter Bergner <bergner@linux.ibm.com> 111278 111279 PowerPC: Create new MMA instruction masks and use them 111280 The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that 111281 misses the RC bit/bit 31, so if we disassemble a .long that represents an 111282 MMA instruction except that it also has bit 31 set, we will erroneously 111283 disassemble it to that MMA instruction. We create new masks defines that 111284 contain bit 31 so that doesn't happen anymore. 111285 111286 opcodes/ 111287 * ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines. 111288 (P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4, 111289 xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8, 111290 xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp, 111291 xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp, 111292 xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn, 111293 xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them. 111294 1112952022-07-21 H.J. Lu <hjl.tools@gmail.com> 111296 111297 i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC 111298 We can't use the PLT entry as the function address for PIC since the PIC 111299 register may not be set up properly for indirect call. 111300 111301 bfd/ 111302 111303 PR ld/27998 111304 * elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF 111305 relocation against IFUNC symbol for PIC. 111306 111307 ld/ 111308 111309 PR ld/27998 111310 * testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar. 111311 * testsuite/ld-i386/pr27998b.d: Expect a linker error. 111312 * testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated. 111313 * testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise. 111314 * testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT. 111315 * testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise. 111316 1113172022-07-21 Andrew Burgess <aburgess@redhat.com> 111318 111319 gdb: ensure the cast in gdbarch_tdep is valid 111320 This commit makes use of gdb::checked_static_cast when casting the 111321 generic gdbarch_tdep pointer to a specific sub-class type. This means 111322 that, when compiled in developer mode, GDB will validate that the cast 111323 is correct. 111324 111325 In order to use gdb::checked_static_cast the types involved must have 111326 RTTI, which is why the gdbarch_tdep base class now has a virtual 111327 destructor. 111328 111329 Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer 111330 to the wrong type, then there should be no changes after this commit. 111331 111332 If any bugs do exist, then GDB will now assert (in a developer build). 111333 1113342022-07-21 Andrew Burgess <aburgess@redhat.com> 111335 111336 gdbsupport: add checked_static_cast 111337 This commit was inspired by these mailing list posts: 111338 111339 https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html 111340 https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html 111341 111342 The idea is to add a new function gdb::checked_static_cast, which can, 111343 in some cases, be used as a drop-in replacement for static_cast. And 111344 so, if I previously wrote this: 111345 111346 BaseClass *base = get_base_class_pointer (); 111347 DerivedClass *derived = static_cast<DerivedClass *> (base); 111348 111349 I can now write: 111350 111351 BaseClass *base = get_base_class_pointer (); 111352 DerivedClass *derived = gdb::checked_static_cast<DerivedClass *> (base); 111353 111354 The requirement is that BaseClass and DerivedClass must be 111355 polymorphic. 111356 111357 The benefit of making this change is that, when GDB is built in 111358 developer mode, a run-time check will be made to ensure that `base` 111359 really is of type DerivedClass before the cast is performed. If 111360 `base` is not of type DerivedClass then GDB will assert. 111361 111362 In a non-developer build gdb::checked_static_cast is equivalent to a 111363 static_cast, and there should be no performance difference. 111364 111365 This commit adds the support function, but does not make use of this 111366 function, a use will be added in the next commit. 111367 111368 Co-Authored-By: Pedro Alves <pedro@palves.net> 111369 Co-Authored-By: Tom Tromey <tom@tromey.com> 111370 1113712022-07-21 Andrew Burgess <aburgess@redhat.com> 111372 111373 gdb: move the type cast into gdbarch_tdep 111374 I built GDB for all targets on a x86-64/GNU-Linux system, and 111375 then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run" 111376 the binary on the native target. I got this error: 111377 111378 (gdb) show architecture 111379 The target architecture is set to "auto" (currently "i386"). 111380 (gdb) file /tmp/hello.rv32.exe 111381 Reading symbols from /tmp/hello.rv32.exe... 111382 (gdb) show architecture 111383 The target architecture is set to "auto" (currently "riscv:rv32"). 111384 (gdb) run 111385 Starting program: /tmp/hello.rv32.exe 111386 ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed. 111387 111388 What's going on here is this; initially the architecture is i386, this 111389 is based on the default architecture, which is set based on the native 111390 target. After loading the RISC-V executable the architecture of the 111391 current inferior is updated based on the architecture of the 111392 executable. 111393 111394 When we "run", GDB does a fork & exec, with the inferior being 111395 controlled through ptrace. GDB sees an initial stop from the inferior 111396 as soon as the inferior comes to life. In response to this stop GDB 111397 ends up calling save_stop_reason (linux-nat.c), which ends up trying 111398 to read register from the inferior, to do this we end up calling 111399 target_ops::fetch_registers, which, for the x86-64 native target, 111400 calls amd64_linux_nat_target::fetch_registers. 111401 111402 After this I eventually end up in i387_supply_fxsave, different x86 111403 based targets will end in different functions to fetch registers, but 111404 it doesn't really matter which function we end up in, the problem is 111405 this line, which is repeated in many places: 111406 111407 i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch); 111408 111409 The problem here is that the ARCH in this line comes from the current 111410 inferior, which, as we discussed above, will be a RISC-V gdbarch, the 111411 tdep field will actually be of type riscv_gdbarch_tdep, not 111412 i386_gdbarch_tdep. After this cast we are relying on undefined 111413 behaviour, in my case I happen to trigger an assert, but this might 111414 not always be the case. 111415 111416 The thing I tried that exposed this problem was of course, trying to 111417 start an executable of the wrong architecture on a native target. I 111418 don't think that the correct solution for this problem is to detect, 111419 at the point of cast, that the gdbarch_tdep object is of the wrong 111420 type, but, I did wonder, is there a way that we could protect 111421 ourselves from incorrectly casting the gdbarch_tdep object? 111422 111423 I think that there is something we can do here, and this commit is the 111424 first step in that direction, though no actual check is added by this 111425 commit. 111426 111427 This commit can be split into two parts: 111428 111429 (1) In gdbarch.h and arch-utils.c. In these files I have modified 111430 gdbarch_tdep (the function) so that it now takes a template argument, 111431 like this: 111432 111433 template<typename TDepType> 111434 static inline TDepType * 111435 gdbarch_tdep (struct gdbarch *gdbarch) 111436 { 111437 struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch); 111438 return static_cast<TDepType *> (tdep); 111439 } 111440 111441 After this change we are no better protected, but the cast is now 111442 done within the gdbarch_tdep function rather than at the call sites, 111443 this leads to the second, much larger change in this commit, 111444 111445 (2) Everywhere gdbarch_tdep is called, we make changes like this: 111446 111447 - i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch); 111448 + i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch); 111449 111450 There should be no functional change after this commit. 111451 111452 In the next commit I will build on this change to add an assertion in 111453 gdbarch_tdep that checks we are casting to the correct type. 111454 1114552022-07-21 Andrew Burgess <aburgess@redhat.com> 111456 111457 gdb: select suitable thread for gdbarch_adjust_breakpoint_address 111458 The three targets that implement gdbarch_adjust_breakpoint_address are 111459 arm, frv, and mips. In each of these targets the adjust breakpoint 111460 address function does some combination of reading the symbol table, or 111461 reading memory at the location the breakpoint could be placed. 111462 111463 The problem is that performing these actions requires that the current 111464 inferior and program space be the one in which the breakpoint will be 111465 placed, and this is not currently always the case. 111466 111467 Consider a GDB session with multiple inferiors. One inferior might be 111468 a native target while another could be a remote target of a completely 111469 different architecture. Alternatively, if we consider ARM and 111470 AArch64, one native inferior might be AArch64, while a second native 111471 inferior could be ARM. 111472 111473 In these cases it is possible, and valid, for a user to have one 111474 inferior selected, and place a breakpoint in the other inferior by 111475 placing a breakpoint on a particular symbol. 111476 111477 If this happens, then currently, when 111478 gdbarch_adjust_breakpoint_address is called, the wrong inferior (and 111479 program space) will be selected, and memory reads, and symbol look 111480 ups, will not return the expected results, this could lead to 111481 breakpoints being placed in the wrong location. 111482 111483 There are currently two places where gdbarch_adjust_breakpoint_address 111484 is called: 111485 111486 1. In infrun.c, in the function handle_step_into_function. In this 111487 case, I believe that the correct inferior and program space will 111488 already be selected as this is called as part of the stop event 111489 handling, so I don't think we need to worry about this case, and 111490 111491 2. In breakpoint.c, in the function adjust_breakpoint_address, which 111492 is itself called from code_breakpoint::add_location and 111493 watch_command_1. 111494 111495 The watch_command_1 case I don't think we need to worry about, this 111496 is for when a local watch expression is created, which can only be 111497 in the currently selected inferior, so this case should be fine. 111498 111499 The code_breakpoint::add_location case is the one that needs fixing, 111500 this is what allows a breakpoint to be created between inferiors. 111501 111502 To fix the code_breakpoint::add_location case, I propose that we pass 111503 the "correct" program_space (i.e. the program space in which the 111504 breakpoint will be created) to the adjust_breakpoint_address function. 111505 Then in adjust_breakpoint_address we can make use of 111506 switch_to_program_space_and_thread to switch program_space and 111507 inferior before calling gdbarch_adjust_breakpoint_address. 111508 111509 I discovered this issue while working on a later patch in this 111510 series. This later patch will detect when we cast the result of 111511 gdbarch_tdep to the wrong type. 111512 111513 With this later patch in place I ran gdb.multi/multi-arch.exp on an 111514 AArch64 target. In this situation, two inferiors are created, an 111515 AArch64 inferior, and an ARM inferior. The test selected the AArch64 111516 inferior and tries to create a breakpoint in the ARM inferior. 111517 111518 As a result of this we end up in arm_adjust_breakpoint_address, which 111519 calls arm_pc_is_thumb. Before this commit the AArch64 inferior would 111520 be current. As a result, all of the checks in arm_pc_is_thumb would 111521 fail (they rely on reading symbols from the current program space), 111522 and so, at the end of arm_pc_is_thumb we would call 111523 arm_frame_is_thumb. However, remember, at this point the current 111524 inferior is the AArch64 inferior, so the current frame is an AArch64 111525 frame. 111526 111527 In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls 111528 gdbarch_tdep and casts the result to arm_gdbarch_tdep. This is wrong, 111529 the tdep field is of type aarch64_gdbarch_tdep. After this we have 111530 undefined behaviour. 111531 111532 With this patch in place, we will have switched to a thread in the ARM 111533 program space before calling arm_adjust_breakpoint_address. As a 111534 result, we now succeed in looking up the required symbols in 111535 arm_pc_is_thumb, and so we never call arm_frame_is_thumb. 111536 111537 However, in the worst case scenario, if we did end up calling 111538 arm_frame_is_thumb, as the current inferior should now be the ARM 111539 inferior, the current frame should be an ARM frame, so we still should 111540 not hit undefined behaviour. 111541 111542 I have added an assert to arm_frame_is_thumb. 111543 1115442022-07-21 Andrew Burgess <aburgess@redhat.com> 111545 111546 gdb/mips: rewrite show_mask_address 111547 This commit is similar to the previous commit, but in this case GDB is 111548 actually relying on undefined behaviour. 111549 111550 Consider building GDB for all targets on x86-64/GNU-Linux, then doing 111551 this: 111552 111553 (gdb) show mips mask-address 111554 Zeroing of upper 32 bits of 64-bit addresses is auto. 111555 The 32 bit address mask is set automatically. Currently disabled 111556 (gdb) 111557 111558 The 'show mips mask-address' command ends up in show_mask_address in 111559 mips-tdep.c, and this function does this: 111560 111561 mips_gdbarch_tdep *tdep 111562 = (mips_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ()); 111563 111564 Later we might pass TDEP to mips_mask_address_p. However, in my 111565 example above, on an x86-64 native target, the current target 111566 architecture will be an x86-64 gdbarch, and the tdep field within the 111567 gdbarch will be of type i386_gdbarch_tdep, not of type 111568 mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP 111569 is not pointing at what it thinks it is. 111570 111571 I also think the current output is a little confusing, we appear to 111572 have two lines that show the same information, but using different 111573 words. 111574 111575 The first line comes from calling deprecated_show_value_hack, while 111576 the second line is printed directly from show_mask_address. However, 111577 both of these lines are printing the same mask_address_var value. I 111578 don't think the two lines actually adds any value here. 111579 111580 Finally, none of the text in this function is passed through the 111581 internationalisation mechanism. 111582 111583 It would be nice to remove another use of deprecated_show_value_hack 111584 if possible, so this commit does a complete rewrite of 111585 show_mask_address. 111586 111587 After this commit the output of the above example command, still on my 111588 x86-64 native target is: 111589 111590 (gdb) show mips mask-address 111591 Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS). 111592 111593 The 'current architecture is not MIPS' text is only displayed when the 111594 current architecture is not MIPS. If the architecture is mips then we 111595 get the more commonly seen 'currently "on"' or 'currently "off"', like 111596 this: 111597 111598 (gdb) set architecture mips 111599 The target architecture is set to "mips". 111600 (gdb) show mips mask-address 111601 Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off"). 111602 (gdb) 111603 111604 All the text is passed through the internationalisation mechanism, and 111605 we only call gdbarch_tdep when we know the gdbarch architecture is 111606 bfd_arch_mips. 111607 1116082022-07-21 Andrew Burgess <aburgess@redhat.com> 111609 111610 gdb/arm: move fetch of arm_gdbarch_tdep to a more inner scope 111611 This is a small refactor to resolve an issue before it becomes a 111612 problem in a later commit. 111613 111614 Move the fetching of an arm_gdbarch_tdep into a more inner scope 111615 within two functions in arm-tdep.c. 111616 111617 The problem with the current code is that the functions in question 111618 are used as the callbacks for two set/show parameters. These set/show 111619 parameters are available no matter the current architecture, but are 111620 really about controlling an ARM architecture specific setting. And 111621 so, if I build GDB for all targets on an x86-64/GNU-Linux system, I 111622 can still do this: 111623 111624 (gdb) show arm fpu 111625 (gdb) show arm abi 111626 111627 After these calls we end up in show_fp_model and arm_show_abi 111628 respectively, where we unconditionally do this: 111629 111630 arm_gdbarch_tdep *tdep 111631 = (arm_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ()); 111632 111633 However, the gdbarch_tdep() result will only be a arm_gdbarch_tdep if 111634 the current architecture is ARM, otherwise the result will actually be 111635 of some other type. 111636 111637 This isn't actually a problem, as in both cases the use of tdep is 111638 guarded by a later check that the gdbarch architecture is 111639 bfd_arch_arm. 111640 111641 This commit just moves the call to gdbarch_tdep() after the 111642 architecture check. 111643 111644 In a later commit gdbarch_tdep() will be able to spot when we are 111645 casting the result to the wrong type, and this function will trigger 111646 assertion failures if things are not fixed. 111647 111648 There should be not user visible changes after this commit. 111649 1116502022-07-21 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> 111651 111652 [arm] Rename arm_cache_is_sp_register to arm_is_alternative_sp_register 111653 All usages of this helper are really made to check if the register is 111654 one of the alternative SP registers (MSP/MSP_S/MSP_NS/PSP/PSP_S/PSP_NS) 111655 with the ARM_SP_REGNUM case being handled separately. 111656 1116572022-07-21 Tom de Vries <tdevries@suse.de> 111658 111659 [gdb/python] Fix typo in test_python 111660 Fix typo in ref_output_0 variable in test_python. 111661 111662 Tested by running the selftest on x86_64-linux with python 3.11. 111663 1116642022-07-21 Tom de Vries <tdevries@suse.de> 111665 111666 [gdb/python] Fix python selftest with python 3.11 111667 With python 3.11 I noticed: 111668 ... 111669 $ gdb -q -batch -ex "maint selftest python" 111670 Running selftest python. 111671 Self test failed: self-test failed at gdb/python/python.c:2246 111672 Ran 1 unit tests, 1 failed 111673 ... 111674 111675 In more detail: 111676 ... 111677 (gdb) p output 111678 $5 = "Traceback (most recent call last):\n File \"<string>\", line 0, \ 111679 in <module>\nKeyboardInterrupt\n" 111680 (gdb) p ref_output 111681 $6 = "Traceback (most recent call last):\n File \"<string>\", line 1, \ 111682 in <module>\nKeyboardInterrupt\n" 111683 ... 111684 111685 Fix this by also allowing line number 0. 111686 111687 Tested on x86_64-linux. 111688 111689 This should hopefully fix buildbot builder gdb-rawhide-x86_64. 111690 1116912022-07-21 Tom de Vries <tdevries@suse.de> 111692 111693 [gdbsupport] Fix type of parallel_for_each_debug 111694 When I changed the initialization of parallel_for_each_debug from 0 to false, 111695 I forgot to change the type from int to bool. Fix this. 111696 111697 Tested by rebuilding on x86_64-linux. 111698 1116992022-07-21 Tom de Vries <tdevries@suse.de> 111700 111701 [gdb/symtab] Fix bad compile unit index complaint 111702 I noticed this code in dw2_debug_names_iterator::next: 111703 ... 111704 case DW_IDX_compile_unit: 111705 /* Don't crash on bad data. */ 111706 if (ull >= per_bfd->all_comp_units.size ()) 111707 { 111708 complaint (_(".debug_names entry has bad CU index %s" 111709 " [in module %s]"), 111710 pulongest (ull), 111711 objfile_name (objfile)); 111712 continue; 111713 } 111714 per_cu = per_bfd->get_cu (ull); 111715 break; 111716 ... 111717 111718 This code used to DTRT, before we started keeping both CUs and TUs in 111719 all_comp_units. 111720 111721 Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus" 111722 instead. 111723 111724 It's hard to produce a test-case for this, but let's try at least to trigger 111725 the complaint somehow. We start out by creating an exec with .debug_types and 111726 .debug_names: 111727 ... 111728 $ gcc -g ~/hello.c -fdebug-types-section 111729 $ gdb-add-index -dwarf-5 a.out 111730 ... 111731 and verify that we don't see any complaints: 111732 ... 111733 $ gdb -q -batch -iex "set complaints 100" ./a.out 111734 ... 111735 111736 We look at the CU and TU table using readelf -w and conclude that we have 111737 nr_cus == 6 and nr_tus == 1. 111738 111739 Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit 111740 case to 6, and we have: 111741 ... 111742 $ gdb -q -batch -iex "set complaints 100" ./a.out 111743 During symbol reading: .debug_names entry has bad CU index 6 [in module a.out] 111744 ... 111745 111746 After this, it still crashes because this code in 111747 dw2_debug_names_iterator::next: 111748 ... 111749 /* Skip if already read in. */ 111750 if (m_per_objfile->symtab_set_p (per_cu)) 111751 goto again; 111752 ... 111753 is called with per_cu == nullptr. 111754 111755 Fix this by skipping the entry if per_cu == nullptr. 111756 111757 Now revert the fix and observe that the complaint disappears, so we've 111758 confirmed that the fix is required. 111759 111760 A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed 111761 as PR29367. 111762 111763 Tested on x86_64-linux, with native and target board cc-with-debug-names. 111764 111765 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29336 111766 1117672022-07-21 Jan Beulich <jbeulich@suse.com> 111768 111769 x86: replace wrong attributes on VCVTDQ2PH{X,Y} 111770 A standalone (without SAE) StaticRounding attribute is meaningless, and 111771 indeed all other similar insns have ATTSyntax there instead. I can only 111772 assume this was some strange copy-and-paste mistake. 111773 111774 x86/Intel: correct AVX512F scatter insn element sizes 111775 I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted 111776 operand sizes for AVX512 scatter/gather") giving all AVX512F scatter 111777 insns Dword element size. Update testcases (also their gather parts), 111778 utilizing that there previously were two identical lines each (for no 111779 apparent reason). 111780 1117812022-07-21 Alan Modra <amodra@gmail.com> 111782 111783 PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save 111784 PR 29390 111785 binutils/ 111786 * dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New. 111787 (display_debug_frames): Use them. 111788 (init_dwarf_regnames_aarch64): Set is_aarch64. 111789 (init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64. 111790 (init_dwarf_regnames_by_bfd_arch_and_mach): Likewise. 111791 gas/ 111792 * testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output. 111793 * testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise. 111794 1117952022-07-21 Alan Modra <amodra@gmail.com> 111796 111797 PR29337, readelf CU/TU mixup in .gdb_index 111798 Commit 244e19c79111 changed a number of variables in display_gdb_index 111799 to count entries rather than words. 111800 111801 PR 29337 111802 * dwarf.c (display_gdb_index): Correct use of cu_list_elements. 111803 1118042022-07-21 Alan Modra <amodra@gmail.com> 111805 111806 PR29370, infinite loop in display_debug_abbrev 111807 The PR29370 testcase is a fuzzed object file with multiple 111808 .trace_abbrev sections. Multiple .trace_abbrev or .debug_abbrev 111809 sections are not a violation of the DWARF standard. The DWARF5 111810 standard even gives an example of multiple .debug_abbrev sections 111811 contained in groups. Caching and lookup of processed abbrevs thus 111812 needs to be done by section and offset rather than base and offset. 111813 (Why base anyway?) Or, since section contents are kept, by a pointer 111814 into the contents. 111815 111816 PR 29370 111817 * dwarf.c (struct abbrev_list): Replace abbrev_base and 111818 abbrev_offset with raw field. 111819 (find_abbrev_list_by_abbrev_offset): Delete. 111820 (find_abbrev_list_by_raw_abbrev): New function. 111821 (process_abbrev_set): Set list->raw and list->next. 111822 (find_and_process_abbrev_set): Replace abbrev list lookup with 111823 new function. Don't set list abbrev_base, abbrev_offset or next. 111824 1118252022-07-21 Alan Modra <amodra@gmail.com> 111826 111827 binutils/dwarf.c: abbrev caching 111828 I'm inclined to think that abbrev caching is counter-productive. The 111829 time taken to search the list of abbrevs converted to internal form is 111830 non-zero, and it's easy to decode the raw abbrevs. It's especially 111831 silly to cache empty lists of decoded abbrevs (happens with zero 111832 padding in .debug_abbrev), or abbrevs as they are displayed when there 111833 is no further use of those abbrevs. This patch stops caching in those 111834 cases. 111835 111836 * dwarf.c (record_abbrev_list_for_cu): Add free_list param. 111837 Put abbrevs on abbrev_lists here. 111838 (new_abbrev_list): Delete function. 111839 (process_abbrev_set): Return newly allocated list. Move 111840 abbrev base, offset and size checking to.. 111841 (find_and_process_abbrev_set): ..here, new function. Handle 111842 lookup of cached abbrevs here, and calculate start and end 111843 for process_abbrev_set. Return free_list if newly alloc'd. 111844 (process_debug_info): Consolidate cached list lookup, new list 111845 alloc and processing into find_and_process_abbrev_set call. 111846 Free list when not cached. 111847 (display_debug_abbrev): Similarly. 111848 1118492022-07-21 Alan Modra <amodra@gmail.com> 111850 111851 miscellaneous dwarf.c tidies 111852 * dwarf.c: Leading and trailing whitespace fixes. 111853 (free_abbrev_list): New function. 111854 (free_all_abbrevs): Use the above. Free cu_abbrev_map here too. 111855 (process_abbrev_set): Print actual section name on error. 111856 (get_type_abbrev_from_form): Add overflow check. 111857 (free_debug_memory): Don't free cu_abbrev_map here.. 111858 (process_debug_info): ..or here. Warn on another case of not 111859 finding a neeeded abbrev. 111860 1118612022-07-21 Alan Modra <amodra@gmail.com> 111862 111863 PowerPC64: fix build error on 32-bit hosts 111864 elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=] 111865 11673 | fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset); 111866 | ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~ 111867 | | | 111868 | | bfd_vma {aka long long unsigned int} 111869 | long unsigned int 111870 | %#llx 111871 111872 * elf64-ppc.c (dump_stub): Use BFD_VMA_FMT. 111873 1118742022-07-21 Kevin Buettner <kevinb@redhat.com> 111875 111876 Wrap python_write_bytecode with HAVE_PYTHON ifdef 111877 This commit fixes a build error on machines lacking python headers 111878 and/or libraries. 111879 1118802022-07-21 GDB Administrator <gdbadmin@sourceware.org> 111881 111882 Automatic date update in version.in 111883 1118842022-07-20 Kevin Buettner <kevinb@redhat.com> 111885 111886 Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName 111887 Python 3.11 deprecates PySys_SetPath and Py_SetProgramName. The 111888 PyConfig API replaces these and other functions. This commit uses the 111889 PyConfig API to provide equivalent functionality while also preserving 111890 support for older versions of Python, i.e. those before Python 3.8. 111891 111892 A beta version of Python 3.11 is available in Fedora Rawhide. Both 111893 Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used 111894 Python 3.9. I've tested these changes on Fedora 34, Fedora 36, and 111895 rawhide, though complete testing was not possible on rawhide due to 111896 a kernel bug. That being the case, I decided to enable the newer 111897 PyConfig API by testing PY_VERSION_HEX against 0x030a0000. This 111898 corresponds to Python 3.10. 111899 111900 We could try to use the PyConfig API for Python versions as early as 3.8, 111901 but I'm reluctant to do this as there may have been PyConfig related 111902 bugs in earlier versions which have since been fixed. Recent linux 111903 distributions should have support for Python 3.10. This should be 111904 more than adequate for testing the new Python initialization code in 111905 GDB. 111906 111907 Information about the PyConfig API as well as the motivation behind 111908 deprecating the old interface can be found at these links: 111909 111910 https://github.com/python/cpython/issues/88279 111911 https://peps.python.org/pep-0587/ 111912 https://docs.python.org/3.11/c-api/init_config.html 111913 111914 The v2 commit also addresses several problems that Simon found in 111915 the v1 version. 111916 111917 In v1, I had used Py_DontWriteBytecodeFlag in the new initialization 111918 code, but Simon pointed out that this global configuration variable 111919 will be deprecated in Python 3.12. This version of the patch no longer 111920 uses Py_DontWriteBytecodeFlag in the new initialization code. 111921 Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag 111922 will no longer be used when building GDB against Python 3.10 or higher. 111923 While it's true that both of these global configuration variables are 111924 deprecated in Python 3.12, it makes sense to disable their use for 111925 gdb builds against 3.10 and higher since those are the versions for 111926 which the PyConfig API is now being used by GDB. (The PyConfig API 111927 includes different mechanisms for making the same settings afforded 111928 by use of the soon-to-be deprecated global configuration variables.) 111929 111930 Simon also noted that PyConfig_Clear() would not have be called for 111931 one of the failure paths. I've fixed that problem and also made the 111932 rest of the "bail out" code more direct. In particular, 111933 PyConfig_Clear() will always be called, both for success and failure. 111934 111935 The v3 patch addresses some rebase conflicts related to module 111936 initialization . Commit 3acd9a692dd ("Make 'import gdb.events' work") 111937 uses PyImport_ExtendInittab instead of PyImport_AppendInittab. That 111938 commit also initializes a struct for each module to import. Both the 111939 initialization and the call to were moved ahead of the ifdefs to avoid 111940 having to replicate (at least some of) the code three times in various 111941 portions of the ifdefs. 111942 111943 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28668 111944 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29287 111945 1119462022-07-20 Christopher Di Bella <cjdb@google.com> 111947 111948 gdb/value.c: add several headers to the include list 111949 Building GDB currently fails to build with libc++, because libc++ is 111950 stricter about which headers "leak" entities they're not guaranteed 111951 to support. The following headers have been added: 111952 111953 * `<iterator>`, to support `std::back_inserter` 111954 * `<utility>`, to support `std::move` and `std::swap` 111955 * `<vector>`, to support `std::vector` 111956 111957 Change-Id: Iaeb15057c5fbb43217df77ce34d4e54446dbcf3d 111958 1119592022-07-20 Pedro Alves <pedro@palves.net> 111960 111961 Don't stop all threads prematurely after first step of "step N" 111962 In all-stop mode, when the target is itself in non-stop mode (like 111963 GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step 111964 a thread a number of times: 111965 111966 (gdb) help step 111967 step, s 111968 Step program until it reaches a different source line. 111969 Usage: step [N] 111970 Argument N means step N times (or till program stops for another reason). 111971 111972 ... GDB prematurely stops all threads after the first step, and 111973 doesn't re-resume them for the subsequent N-1 steps. It's as if for 111974 the 2nd and subsequent steps, the command was running with 111975 scheduler-locking enabled. 111976 111977 This can be observed with the testcase added by this commit, which 111978 looks like this: 111979 111980 static pthread_barrier_t barrier; 111981 111982 static void * 111983 thread_func (void *arg) 111984 { 111985 pthread_barrier_wait (&barrier); 111986 return NULL; 111987 } 111988 111989 int 111990 main () 111991 { 111992 pthread_t thread; 111993 int ret; 111994 111995 pthread_barrier_init (&barrier, NULL, 2); 111996 111997 /* We run to this line below, and then issue "next 3". That should 111998 step over the 3 lines below and land on the return statement. If 111999 GDB prematurely stops the thread_func thread after the first of 112000 the 3 nexts (and never resumes it again), then the join won't 112001 ever return. */ 112002 pthread_create (&thread, NULL, thread_func, NULL); /* set break here */ 112003 pthread_barrier_wait (&barrier); 112004 pthread_join (thread, NULL); 112005 112006 return 0; 112007 } 112008 112009 The test hangs and times out without the GDB fix: 112010 112011 (gdb) next 3 112012 [New Thread 0x7ffff7d89700 (LWP 525772)] 112013 FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout) 112014 112015 The problem is a core gdb bug. 112016 112017 When you do "step/stepi/next/nexti N", GDB internally creates a 112018 thread_fsm object and associates it with the stepping thread. For the 112019 stepping commands, the FSM's class is step_command_fsm. That object 112020 is what keeps track of how many steps are left to make. When one step 112021 finishes, handle_inferior_event calls stop_waiting and returns, and 112022 then fetch_inferior_event calls the "should_stop" method of the event 112023 thread's FSM. The implementation of that method decrements the 112024 steps-left counter. If the counter is 0, it returns true and we 112025 proceed to presenting the stop to the user. If it isn't 0 yet, then 112026 the method returns false, indicating to fetch_inferior_event to "keep 112027 going". 112028 112029 Focusing now on when the first step finishes -- we're in "all-stop" 112030 mode, with the target in non-stop mode. When a step finishes, 112031 handle_inferior_event calls stop_waiting, which itself calls 112032 stop_all_threads to stop everything. I.e., after the first step 112033 completes, all threads are stopped, before handle_inferior_event 112034 returns. And after that, now in fetch_inferior_event, we consult the 112035 thread's thread_fsm::should_stop, which as we've seen, for the first 112036 step returns false -- i.e., we need to keep_going for another step. 112037 However, since the target is in non-stop mode, keep_going resumes 112038 _only_ the current thread. All the other threads remain stopped, 112039 inadvertently. 112040 112041 If the target is in non-stop mode, we don't actually need to stop all 112042 threads right after each step finishes, and then re-resume them again. 112043 We can instead defer stopping all threads until all the steps are 112044 completed. 112045 112046 So fix this by delaying the stopping of all threads until after we 112047 called the FSM's "should_stop" method. I.e., move it from 112048 stop_waiting, to handle_inferior_events's callers, 112049 fetch_inferior_event and wait_for_inferior. 112050 112051 New test included. Tested on x86-64 GNU/Linux native and gdbserver. 112052 112053 Change-Id: Iaad50dcfea4464c84bdbac853a89df92ade6ae01 112054 1120552022-07-20 Alan Modra <amodra@gmail.com> 112056 112057 Re: opcodes/arc: Implement style support in the disassembler 112058 * arc-dis.c (print_insn_arc): Fix thinko. 112059 1120602022-07-20 Dmitry Selyutin <ghostmansd@gmail.com> 112061 112062 gas/symbols: introduce md_resolve_symbol 112063 Assuming GMSD is a special operand, marked as O_md1, the code: 112064 112065 .set VREG, GMSD 112066 .set REG, VREG 112067 extsw REG, 2 112068 112069 ...fails upon attempts to resolve the value of the symbol. This happens 112070 since machine-dependent values are not handled in the giant op switch. 112071 We introduce a custom md_resolve_symbol macro; the ports can use this 112072 macro to customize the behavior when resolve_symbol_value hits O_md 112073 operand. 112074 1120752022-07-20 GDB Administrator <gdbadmin@sourceware.org> 112076 112077 Automatic date update in version.in 112078 1120792022-07-19 H.J. Lu <hjl.tools@gmail.com> 112080 112081 x86: Disallow invalid relocations against protected symbols 112082 Since glibc 2.36 will issue warnings for copy relocation against 112083 protected symbols and non-canonical reference to canonical protected 112084 functions, change the linker to always disallow such relocations. 112085 112086 bfd/ 112087 112088 * elf32-i386.c (elf_i386_scan_relocs): Remove check for 112089 elf_has_indirect_extern_access. 112090 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 112091 (elf_x86_64_relocate_section): Remove check for 112092 elf_has_no_copy_on_protected. 112093 * elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building 112094 executable instead of elf_has_no_copy_on_protected. 112095 (_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation 112096 against non-copyable protected symbol. 112097 * elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for 112098 elf_has_no_copy_on_protected. 112099 112100 ld/ 112101 112102 * testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709 112103 test. 112104 * testsuite/ld-i386/pr17709.rd: Removed. 112105 * testsuite/ld-i386/pr17709.err: New file. 112106 * testsuite/ld-x86-64/pr17709.rd: Removed. 112107 * testsuite/ld-x86-64/pr17709.err: New file. 112108 * testsuite/ld-x86-64/pr28875-func.err: Updated. 112109 * testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR 112110 ld/17709 test. Add tests for function pointer against protected 112111 function. 112112 1121132022-07-19 Fangrui Song <i@maskray.me> 112114 112115 x86: Make protected symbols local for -shared 112116 Call _bfd_elf_symbol_refs_local_p with local_protected==true. This has 112117 2 noticeable effects for -shared: 112118 112119 * GOT-generating relocations referencing a protected data symbol no 112120 longer lead to a GLOB_DAT (similar to a hidden symbol). 112121 * Direct access relocations (e.g. R_X86_64_PC32) no longer has the 112122 confusing diagnostic below. 112123 112124 __attribute__((visibility("protected"))) void *foo() { 112125 return (void *)foo; 112126 } 112127 112128 // gcc -fpic -shared -fuse-ld=bfd 112129 relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object 112130 112131 The new behavior matches arm, aarch64 (commit 112132 83c325007c5599fa9b60b8d5f7b84842160e1d1b), and powerpc ports, and other 112133 linkers: gold and ld.lld. 112134 112135 Note: if some code tries to use direct access relocations to take the 112136 address of foo, the pointer equality will break, but the error should be 112137 reported on the executable link, not on the innocent shared object link. 112138 glibc 2.36 will give a warning at relocation resolving time. 112139 112140 With this change, `#define elf_backend_extern_protected_data 1` is no 112141 longer effective. Just remove it. 112142 112143 Remove the test "Run protected-func-1 without PIE" since -fno-pic 112144 address taken operation in the executable doesn't work with protected 112145 symbol in a shared object by default. Similarly, remove 112146 protected-data-1a and protected-data-1b. protected-data-1b can be made 112147 working by removing HAVE_LD_PIE_COPYRELOC from GCC 112148 (https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html). 112149 1121502022-07-19 Luis Machado <luis.machado@arm.com> 112151 112152 Reformat gdbarch-components.py to fix deviations 112153 Reformat to make sure we have a clean file with no deviations 112154 from the expected python code format. 112155 1121562022-07-19 Luis Machado <luis.machado@arm.com> 112157 112158 [AArch64] MTE corefile support 112159 Teach GDB how to dump memory tags for AArch64 when using the gcore command 112160 and how to read memory tag data back from a core file generated by GDB 112161 (via gcore) or by the Linux kernel. 112162 112163 The format is documented in the Linux Kernel documentation [1]. 112164 112165 Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its 112166 own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each 112167 of those segments when reading the core file back. 112168 112169 To save a little bit of space, given MTE tags only take 4 bits, the memory tags 112170 are stored packed as 2 tags per byte. 112171 112172 When reading the data back, the tags are unpacked. 112173 112174 I've added a new testcase to exercise the feature. 112175 112176 Build-tested with --enable-targets=all and regression tested on aarch64-linux 112177 Ubuntu 20.04. 112178 112179 [1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support) 112180 1121812022-07-19 Luis Machado <luis.machado@arm.com> 112182 112183 [AArch64] Support AArch64 MTE memory tag dumps in core files 112184 The Linux kernel can dump memory tag segments to a core file, one segment 112185 per mapped range. The format and documentation can be found in the Linux 112186 kernel tree [1]. 112187 112188 The following patch adjusts bfd and binutils so they can handle this new 112189 segment type and display it accordingly. It also adds code required so GDB 112190 can properly read/dump core file data containing memory tags. 112191 112192 Upon reading, each segment that contains memory tags gets mapped to a 112193 section named "memtag". These sections will be used by GDB to lookup the tag 112194 data. There can be multiple such sections with the same name, and they are not 112195 numbered to simplify GDB's handling and lookup. 112196 112197 There is another patch for GDB that enables both reading 112198 and dumping of memory tag segments. 112199 112200 Tested on aarch64-linux Ubuntu 20.04. 112201 112202 [1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support) 112203 1122042022-07-19 Luis Machado <luis.machado@arm.com> 112205 112206 [AArch64] Fix testcase compilation failure 112207 Newer distros carry newer headers that contains MTE definitions. Account 112208 for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define 112209 constants conditionally to prevent compilation failures. 112210 1122112022-07-19 H.J. Lu <hjl.tools@gmail.com> 112212 112213 ld: Pass -nostdlib to compiler with -r 112214 Pass -nostdlib to compiler with -r to avoid unnecessary .o file and 112215 libraries. 112216 112217 PR ld/29377 112218 * testsuite/ld-elf/linux-x86.exp: Pass -nostdlib with -r. 112219 1122202022-07-19 H.J. Lu <hjl.tools@gmail.com> 112221 112222 x86: Properly check invalid relocation against protected symbol 112223 Only check invalid relocation against protected symbol defined in shared 112224 object. 112225 112226 bfd/ 112227 112228 PR ld/29377 112229 * elf32-i386.c (elf_i386_scan_relocs): Only check invalid 112230 relocation against protected symbol defined in shared object. 112231 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 112232 112233 ld/ 112234 112235 PR ld/29377 112236 * testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests. 112237 * testsuite/ld-elf/pr29377a.c: New file. 112238 * testsuite/ld-elf/pr29377b.c: Likewise. 112239 1122402022-07-19 GDB Administrator <gdbadmin@sourceware.org> 112241 112242 Automatic date update in version.in 112243 1122442022-07-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 112245 112246 gprofng: link libgprofng.so against -lpthread 112247 gprofng/ChangeLog 112248 2022-07-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 112249 112250 PR gprofng/29364 112251 * src/Makefile.am (libgprofng_la_LIBADD): Add -lpthread. 112252 * src/Makefile.in: Rebuild. 112253 1122542022-07-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 112255 112256 gprofng: fix regression in build and a race condition in autoreconf 112257 gprofng/ChangeLog 112258 2022-07-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 112259 112260 PR gprofng/29338 112261 * libcollector/configure.ac (AC_CONFIG_HEADERS): Fix a race condition. 112262 * libcollector/configure: Rebuild. 112263 * libcollector/Makefile.in: Rebuild. 112264 * common/config.h.in: Rebuild. 112265 * common/lib-config.h.in: Created by autoreconf. 112266 1122672022-07-18 Tom Tromey <tromey@adacore.com> 112268 112269 Add gdb.free_objfile event registry 112270 Currently, Python code can use event registries to detect when gdb 112271 loads a new objfile, and when gdb clears the objfile list. However, 112272 there's no way to detect the removal of an objfile, say when the 112273 inferior calls dlclose. 112274 112275 This patch adds a gdb.free_objfile event registry and arranges for an 112276 event to be emitted in this case. 112277 1122782022-07-18 Pedro Alves <pedro@palves.net> 112279 112280 Put gdb.base/bt-on-fatal-signal.exp GDB cores in output dir 112281 I noticed that gdb.base/bt-on-fatal-signal.exp was contributing four 112282 core files to the count of unexpected core files: 112283 112284 $ make check TESTS="gdb.base/bt-on-fatal-signal.exp" 112285 112286 === gdb Summary === 112287 112288 # of unexpected core files 4 112289 # of expected passes 21 112290 112291 These are GDB core dumps. They are expected, however, because the 112292 whole point of the testcase is to crash GDB with a signal. 112293 112294 Make GDB change its current directory to the output dir just before 112295 crashing, so that the core files end up there. The result is now: 112296 112297 === gdb Summary === 112298 112299 # of expected passes 25 112300 112301 and: 112302 112303 $ find . -name "core.*" 112304 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1676506.nelson.1657727692 112305 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1672585.nelson.1657727671 112306 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1674833.nelson.1657727683 112307 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1673709.nelson.1657727676 112308 112309 (Note the test is skipped at the top if on a remote host.) 112310 112311 Change-Id: I79e4fb2e91330279c7a509930b1952194a72e85a 112312 1123132022-07-18 Tom Tromey <tromey@adacore.com> 112314 112315 Remove array typedef assumption for Ada 112316 Currently the Ada code assumes that it can distinguish between a 112317 multi-dimensional array and an array of arrays by looking for an 112318 intervening typedef -- that is, for an array of arrays, there will be 112319 a typedef wrapping the innermost array type. 112320 112321 A recent compiler change removes this typedef, which causes a gdb 112322 failure in the internal AdaCore test suite. 112323 112324 This patch handles this case by checking whether the array type in 112325 question has a name. 112326 1123272022-07-18 Tom Tromey <tromey@adacore.com> 112328 112329 Remove manual lifetime management from cli_interp 112330 cli_interp manually manages its cli_out object. This patch changes it 112331 to use a unique_ptr, and also changes cli_uiout to be a private 112332 member. 112333 112334 Remove cli_out_new 112335 cli_out_new is just a small wrapper around 'new'. This patch removes 112336 it, replacing it with uses of 'new' instead. 112337 112338 Replace input_interactive_p with a method 112339 This replaces the global input_interactive_p function with a new 112340 method ui::input_interactive_p. 112341 112342 Remove ui_register_input_event_handler 112343 This patch removes ui_register_input_event_handler and 112344 ui_unregister_input_event_handler, replacing them with methods on 112345 'ui'. It also changes gdb to use these methods everywhere, rather 112346 than sometimes reaching in to the ui to manage the file descriptor 112347 directly. 112348 1123492022-07-18 Claudiu Zissulescu <claziss@gmail.com> 112350 112351 opcodes/arc: Implement style support in the disassembler 112352 Update the ARC disassembler to supply style information to the 112353 disassembler output. The output formatting remains unchanged. 112354 112355 opcodes/ChangeLog: 112356 * disassemble.c (disassemble_init_for_target): Set 112357 created_styled_output for ARC based targets. 112358 * arc-dis.c (find_format_from_table): Use fprintf_styled_ftype 112359 instead of fprintf_ftype throughout. 112360 (find_format): Likewise. 112361 (print_flags): Likewise. 112362 (print_insn_arc): Likewise. 112363 1123642022-07-18 Claudiu Zissulescu <claziss@synopsys.com> 112365 112366 arc: Update missing cipher. 112367 The ciphers 5,7, and 9 are missing when parsing an assembly 112368 instruction leading to errors when those ciphers are 112369 used. 112370 112371 gas/config 112372 * tc-arc.c (md_assembly): Update strspn string with the 112373 missing ciphers. 112374 1123752022-07-18 Tom de Vries <tdevries@suse.de> 112376 112377 [gdb/testsuite] Remove duplicate of supports_gnuc 112378 In commit 9d9dd861e98 ("[gdb/testsuite] Fix regression in 112379 step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate 112380 of supports_gnuc, which caused: 112381 ... 112382 DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency 112383 ... 112384 112385 Fix this by removing the duplicate. 112386 112387 Tested on x86_64-linux. 112388 1123892022-07-18 Andrew Burgess <aburgess@redhat.com> 112390 112391 gdb/python: look for python, then python 3 at configure time 112392 It is possible that a system might have a python3 executable, but no 112393 python executable. For example, on my Fedora system the python2 112394 package provides /usr/bin/python2, the python3 package provides 112395 /usr/bin/python3, and the python-unversioned-command package provides 112396 /usr/bin/python, which picks between python2 and python3. 112397 112398 It is quite possible to only have python3 available on a system. 112399 112400 Currently, when GDB configures, it looks for a 'python' executable. 112401 If non is found then GDB will be built without python support. Or the 112402 user needs to configure using --with-python=/usr/bin/python3. 112403 112404 This commit updates GDB's configure.ac script to first look for 112405 'python', and then 'python3'. Now, on a system that only has a 112406 python3 executable, GDB will automatically find, and use that in order 112407 to provide python support, no user supplied configure arguments are 112408 needed. 112409 112410 I've tested this on my local machine by removing the 112411 python-unversioned-command package, confirming that there is no longer 112412 a 'python' executable in my $PATH, and then rebuilding GDB from 112413 scratch. GDB with this patch has python support. 112414 1124152022-07-18 Jan Beulich <jbeulich@suse.com> 112416 112417 x86: correct VMOVSH attributes 112418 Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by 112419 suitable means, which would cause #UD). The memory operand form further 112420 was using the wrong Masking value, thus allowing zeroing-masking to be 112421 encoded for the store form (which would again cause #UD). 112422 112423 x86: re-order insn template fields 112424 This saves quite a number of shift instructions: The "operands" field 112425 can now be retrieved by just masking (no shift), and extracting the 112426 "extension_opcode" field now only requires a (signed) right shift, with 112427 no prereq left one. (Of course there may be architectures where, in a 112428 cross build, there might be no difference at all, e.g. when there are 112429 suitable bitfield extraction insns.) 112430 1124312022-07-18 Tom de Vries <tdevries@suse.de> 112432 112433 [gdbsupport] Improve thread scheduling in parallel_for_each 112434 When running a task using parallel_for_each, we get the following 112435 distribution: 112436 ... 112437 Parallel for: n_elements: 7271 112438 Parallel for: minimum elements per thread: 10 112439 Parallel for: elts_per_thread: 1817 112440 Parallel for: elements on worker thread 0 : 1817 112441 Parallel for: elements on worker thread 1 : 1817 112442 Parallel for: elements on worker thread 2 : 1817 112443 Parallel for: elements on worker thread 3 : 0 112444 Parallel for: elements on main thread : 1820 112445 ... 112446 112447 Note that there are 4 active threads, and scheduling elts_per_thread on each 112448 of those handles 4 * 1817 == 7268, leaving 3 "left over" elements. 112449 112450 These leftovers are currently handled in the main thread. 112451 112452 That doesn't seem to matter much for this example, but for say 10 threads and 112453 99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18 112454 elements. 112455 112456 Instead, distribute the left over elements over the worker threads, such that 112457 we have: 112458 ... 112459 Parallel for: elements on worker thread 0 : 1818 112460 Parallel for: elements on worker thread 1 : 1818 112461 Parallel for: elements on worker thread 2 : 1818 112462 Parallel for: elements on worker thread 3 : 0 112463 Parallel for: elements on main thread : 1817 112464 ... 112465 112466 Tested on x86_64-linux. 112467 1124682022-07-18 Tom de Vries <tdevries@suse.de> 112469 112470 [gdb/testsuite] Allow override of ASAN_OPTIONS in lib/gdb.exp 112471 Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp. 112472 112473 This allows us to override the default detect_leaks=0 setting, by manually 112474 doing: 112475 ... 112476 $ export ASAN_OPTIONS=detect_leaks=1 112477 $ make check 112478 ... 112479 112480 Tested on x86_64-linux, by building with -fsanitize=address and running 112481 test-case gdb.dwarf2/gdb-add-index.exp with and without 112482 "export ASAN_OPTIONS=detect_leaks=1". 112483 1124842022-07-18 Tom de Vries <tdevries@suse.de> 112485 112486 [gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7 112487 Since commit 43127ae5714 ("Fix gdb.base/step-indirect-call-thunk.exp") I run 112488 into: 112489 ... 112490 gdb compile failed, gcc: error: unrecognized command line option \ 112491 '-fcf-protection=none'; did you mean '-flto-partition=none'? 112492 UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare 112493 ... 112494 112495 The problem is that -fcf-protection is supported starting gcc 8, but I'm using 112496 system gcc 7.5.0. 112497 112498 Fix this by only adding -fcf-protection=none for gcc 8 and later. 112499 112500 Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1. 112501 1125022022-07-18 Tom de Vries <tdevries@suse.de> 112503 112504 [gdb/testsuite] Fix gdb.arch/i386-mpx.exp 112505 Since commit c4a3dbaf113 ("Expose current 'print' settings to Python") we 112506 have: 112507 ... 112508 (gdb) print /x $bnd0 = {0x10, 0x20}^M 112509 $22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M 112510 (gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0 112511 ... 112512 112513 The regexp in the test-case expects "size 17". 112514 112515 Fix this by updating the regexp. 112516 112517 Tested on x86_64-linux. 112518 1125192022-07-18 Tom de Vries <tdevries@suse.de> 112520 112521 [gdbsupport] Add parallel_for_each_debug 112522 Add a parallel_for_each_debug variable, set to false by default. 112523 112524 With an a.out compiled from hello world, we get with 112525 parallel_for_each_debug == true: 112526 ... 112527 $ gdb -q -batch a.out -ex start 112528 ... 112529 Parallel for: n_elements: 7271 112530 Parallel for: minimum elements per thread: 10 112531 Parallel for: elts_per_thread: 1817 112532 Parallel for: elements on worker thread 0 : 1817 112533 Parallel for: elements on worker thread 1 : 1817 112534 Parallel for: elements on worker thread 2 : 1817 112535 Parallel for: elements on worker thread 3 : 0 112536 Parallel for: elements on main thread : 1820 112537 112538 Temporary breakpoint 1, main () at /home/vries/hello.c:6 112539 6 printf ("hello\n"); 112540 ... 112541 112542 Tested on x86_64-linux. 112543 1125442022-07-18 GDB Administrator <gdbadmin@sourceware.org> 112545 112546 Automatic date update in version.in 112547 1125482022-07-17 GDB Administrator <gdbadmin@sourceware.org> 112549 112550 Automatic date update in version.in 112551 1125522022-07-16 GDB Administrator <gdbadmin@sourceware.org> 112553 112554 Automatic date update in version.in 112555 1125562022-07-15 Aaron Merey <amerey@redhat.com> 112557 112558 gdb-add-index always generates an error when libdebuginfod wasn't compiled in 112559 gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb 112560 is not compiled against libdebuginfod this causes an unnecessary error 112561 message to be printed to stderr indicating that gdb was not built with 112562 debuginfod support. 112563 112564 Fix this by changing the 'set debuginfod enabled off' command to a 112565 no-op when gdb isn't built with libdebuginfod. 112566 1125672022-07-15 Bruno Larsen <blarsen@redhat.com> 112568 112569 gdb/testsuite: modernize gdb.base/maint.exp 112570 gdb.base/maint.exp was using several gdb_expect statements, probably 112571 because this test case predates the existance of gdb_test_multiple. This 112572 commit updates the test case to use gdb_test_multiple, making it more 112573 resilient to internal errors and such. 112574 112575 The only gdb_expect left in the testcase is one that specifically looks 112576 for an internal error being triggered as a PASS. 112577 1125782022-07-15 Tom Tromey <tromey@adacore.com> 112579 112580 Add 'nibbles' to gdb.print_options 112581 When I rebased and updated the print_options patch, I forgot to update 112582 print_options to add the new 'nibbles' feature to the result. This 112583 patch fixes the oversight. I'm checking this in. 112584 1125852022-07-15 Carl Love <cel@us.ibm.com> 112586 112587 PowerPC: Add support for IEEE 128-bit format. 112588 The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert 112589 in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c. The 112590 assert is due to the missing IEEE 128-bit support in file 112591 gdb/ppc-sysv-tdep.c. 112592 112593 The IBM long double was the initial float 128-bit support added by IBM 112594 The IEEE 128-bit support, which is similar IBM long double support, was 112595 made the default starting with GCC 12. The floating point format 112596 differences include the number of bits used to encode the exponent 112597 and significand. Also, IBM long double values are passed in a pair of 112598 floating point registers. The IEEE 128-bit value is passed in a single 112599 vector register. 112600 112601 This patch fixes the gdb_assert (ok); in function 112602 ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT 112603 128-bit type support for PowerPC. 112604 112605 The patch has been tested on Power 10, ELFv2. It fixes the following list 112606 of regression failures on Power 10: 112607 112608 gdb.base/infcall-nested-structs-c.exp 192 112609 gdb.base/infcall-nested-structs-c++.exp 76 112610 gdb.base/structs.exp 9 112611 112612 The patch has been tested on Power 8 BE which is ELFv1. 112613 1126142022-07-15 Tom Tromey <tromey@adacore.com> 112615 112616 Add 'summary' mode to Value.format_string 112617 This adds a 'summary' mode to Value.format_string and to 112618 gdb.print_options. For the former, it lets Python code format values 112619 using this mode. For the latter, it lets a printer potentially detect 112620 if it is being called in a backtrace with 'set print frame-arguments' 112621 set to 'scalars'. 112622 112623 I considered adding a new mode here to let a pretty-printer see 112624 whether it was being called in a 'backtrace' context at all, but I'm 112625 not sure if this is really desirable. 112626 1126272022-07-15 Tom Tromey <tromey@adacore.com> 112628 112629 Expose current 'print' settings to Python 112630 PR python/17291 asks for access to the current print options. While I 112631 think this need is largely satisfied by the existence of 112632 Value.format_string, it seemed to me that a bit more could be done. 112633 112634 First, while Value.format_string uses the user's settings, it does not 112635 react to temporary settings such as "print/x". This patch changes 112636 this. 112637 112638 Second, there is no good way to examine the current settings (in 112639 particular the temporary ones in effect for just a single "print"). 112640 This patch adds this as well. 112641 112642 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291 112643 1126442022-07-15 Carl Love <cel@us.ibm.com> 112645 112646 PowerPC: fix for gdb.base/eh_return.exp 112647 Disable the Traceback Table generation on PowerPC for this test. The 112648 Traceback Table consists of a series of bit fields to indicate things like 112649 the Traceback Table version, language, and specific information about the 112650 function. The Traceback Table is generated following the end of the code 112651 for every function by default. The Traceback Table is defined in the 112652 PowerPC ELF ABI and is intended to support debuggers and exception 112653 handlers. The Traceback Table is displayed in the disassembly of functions 112654 by default and is part of the function length. The table is typically 112655 interpreted by the disassembler as data represented by .long xxx entries. 112656 112657 Generation of the Traceback Table is disabled in this test using the 112658 PowerPC specific gcc compiler option -mtraceback=no, the xlc option 112659 additional_flags-qtable=none and the clang optons 112660 -mllvm -xcoff-traceback-table=false. Disabling the Traceback Table 112661 generation in this test results in the gdb_test_multiple statement 112662 correctly locating the address of the bclr instruction before the statement 112663 "End of assembler dump." in the disassembly output. 112664 1126652022-07-15 Tom Tromey <tromey@adacore.com> 112666 112667 Run 'black' on gdb 112668 Running 'black' on gdb fixed a couple of small issues. This patch is 112669 the result. 112670 1126712022-07-15 GDB Administrator <gdbadmin@sourceware.org> 112672 112673 Automatic date update in version.in 112674 1126752022-07-14 Tom de Vries <tdevries@suse.de> 112676 112677 [gdb/symtab] Fix data race in cooked_index_functions::expand_symtabs_matching 112678 When building gdb with -fsanitize-threads and running test-case 112679 gdb.ada/char_enum_unicode.exp, I run into: 112680 ... 112681 WARNING: ThreadSanitizer: data race (pid=21301)^M 112682 Write of size 8 at 0x7b2000008080 by main thread:^M 112683 #0 free <null> (libtsan.so.2+0x4c5e2)^M 112684 #1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M 112685 #2 convert_between_encodings() charset.c:584^M 112686 ... 112687 #21 cooked_index_functions::expand_symtabs_matching() read.c:18606 112688 ... 112689 112690 This is fixed by making cooked_index_functions::expand_symtabs_matching wait 112691 for the cooked index finalization to be done. 112692 112693 Tested on x86_64-linux. 112694 112695 https://sourceware.org/bugzilla/show_bug.cgi?id=29311 112696 https://sourceware.org/bugzilla/show_bug.cgi?id=29286 112697 1126982022-07-14 Tom de Vries <tdevries@suse.de> 112699 112700 [gdbsupport] Add sequential_for_each 112701 Add a sequential_for_each alongside the parallel_for_each, which can be used 112702 as a drop-in replacement. 112703 112704 This can be useful when debugging multi-threading behaviour, and you want to 112705 limit multi-threading in a fine-grained way. 112706 112707 Tested on x86_64-linux, by using it instead of the parallel_for_each in 112708 dwarf2_build_psymtabs_hard. 112709 1127102022-07-14 Tiezhu Yang <yangtiezhu@loongson.cn> 112711 112712 gdb: Document floating-point support for LoongArch 112713 Update NEWS and gdb.texinfo to document floating-point support 112714 for LoongArch. 112715 1127162022-07-14 Tom de Vries <tdevries@suse.de> 112717 112718 [gdb/build] Fix gdb build with gcc 4.8.5 112719 When building gdb with gcc 4.8.5, we run into: 112720 ... 112721 In file included from /usr/include/c++/4.8/future:43:0, 112722 from gdbsupport/thread-pool.h:30, 112723 from gdb/dwarf2/cooked-index.h:33, 112724 from gdb/dwarf2/read.h:26, 112725 from gdb/dwarf2/abbrev-cache.c:21: 112726 /usr/include/c++/4.8/atomic: In instantiation of \ 112727 ‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \ 112728 packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’: 112729 gdb/dwarf2/read.h:332:44: required from here 112730 /usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \ 112731 ‘packed<dwarf_unit_type, 1ul>::packed()’ 112732 _Tp tmp; 112733 ^ 112734 ... 112735 112736 Fix this by adding the default constructor for packed. 112737 112738 Tested on x86_64-linux, with gdb build with gcc 4.8.5. 112739 1127402022-07-14 Tom de Vries <tdevries@suse.de> 112741 112742 [gdb/symtab] Make per_cu->m_lang atomic 112743 When building gdb with -fsanitize=thread and running test-case 112744 gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race 112745 between: 112746 ... 112747 Read of size 1 at 0x7b2000003010 by thread T4: 112748 #0 packed<language, 1ul>::operator language() const packed.h:54 112749 #1 dwarf2_per_cu_data::set_lang(language) read.h:363 112750 ... 112751 and: 112752 ... 112753 Previous write of size 1 at 0x7b2000003010 by main thread: 112754 #0 dwarf2_per_cu_data::set_lang(language) read.h:365 112755 ... 112756 112757 Fix this by making per_cu->m_lang atomic. 112758 112759 Tested on x86_64-linux. 112760 112761 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286 112762 1127632022-07-14 Tom de Vries <tdevries@suse.de> 112764 112765 [gdb/symtab] Make per_cu->unit_type atomic 112766 With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run 112767 into a data race between: 112768 ... 112769 Read of size 1 at 0x7b2000025f0f by main thread: 112770 #0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54 112771 #1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339 112772 ... 112773 and: 112774 ... 112775 Previous write of size 1 at 0x7b2000025f0f by thread T3: 112776 #0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341 112777 ... 112778 112779 Fix this by making per_cu->unit_type atomic. 112780 112781 Tested on x86_64-linux. 112782 112783 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286 112784 1127852022-07-14 Tom de Vries <tdevries@suse.de> 112786 112787 [gdb/symtab] Fix data race in ~charset_vector 112788 When doing: 112789 ... 112790 $ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26" 112791 ... 112792 with a gdb build with -fsanitize=thread I run into a data race: 112793 ... 112794 WARNING: ThreadSanitizer: data race (pid=30917) 112795 Write of size 8 at 0x7b0400004070 by main thread: 112796 #0 free <null> (libtsan.so.2+0x4c5e2) 112797 #1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17) 112798 #2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354) 112799 #3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3) 112800 #4 <null> <null> (libtsan.so.2+0x32643) 112801 #5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a) 112802 ... 112803 112804 The problem is that we're freeing the charset_vector elements in the destructor, 112805 which may still be used by a worker thread. 112806 112807 Fix this by not freeing the charset_vector elements in the destructor. 112808 112809 Tested on x86_64-linux. 112810 112811 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29311 112812 1128132022-07-14 Alan Modra <amodra@gmail.com> 112814 112815 Re: PowerPC: implement md_operand to parse register names 112816 I meant to make this change before committing, to let compilers know 112817 the code on the false branch of md_parse_name is dead. 112818 112819 * config/tc-ppc.c (ppc_parse_name): Return void. 112820 * config/tc-ppc.h (md_parse_name): Always true. 112821 (ppc_parse_name): Update prototype. 112822 1128232022-07-14 Alan Modra <amodra@gmail.com> 112824 112825 PowerPC: implement md_operand to parse register names 112826 Allows register names to appear in symbol assignments, so for example 112827 tocp = %r2 112828 mr %r3,tocp 112829 now assembles. 112830 112831 * gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with 112832 ARRAY_SIZE. 112833 (register_name): Rename to.. 112834 (md_operand): ..this. Only handle %reg. 112835 (cr_names): Rename to.. 112836 (cr_cond): ..this. Just keep conditions. 112837 (ppc_parse_name): Add mode param. Search both cr_cond and 112838 pre_defined_registers. Handle absolute and register symbol 112839 values here rather than in expr.c:operand(). 112840 (md_assemble): Don't special case register name matching in 112841 operands, except to set cr_operand as appropriate. 112842 * gas/config/tc-ppc.h (md_operand): Don't define. 112843 (md_parse_name, ppc_parse_name): Update. 112844 * read.c (pseudo_set): Copy over entire O_register value. 112845 * testsuite/gas/ppc/regsyms.d. 112846 * testsuite/gas/ppc/regsyms.s: New test. 112847 * testsuite/gas/ppc/ppc.exp: Run it. 112848 1128492022-07-14 GDB Administrator <gdbadmin@sourceware.org> 112850 112851 Automatic date update in version.in 112852 1128532022-07-13 Pedro Alves <pedro@palves.net> 112854 112855 Tighten gdb.threads/no-unwaited-for-left.exp regexps 112856 A WIP version of a patch 112857 (https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html) 112858 resulted in a bug that went unnoticed by the testuite, like so: 112859 112860 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread 112861 continue 112862 Continuing. 112863 [New Thread 1251861.1251861] 112864 No unwaited-for children left. 112865 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits 112866 info threads 112867 Id Target Id Frame 112868 3 Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 112869 4 Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? () 112870 112871 The current thread <Thread ID 1> has terminated. See `help thread'. 112872 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated 112873 112874 Somehow, above, GDB re-added the zombie leader back before printing 112875 "No unwaited-for children left.". The "only thread 3 left, main 112876 thread terminated" test should have caught this, but didn't. That is 112877 because the test's regexp has a ".*" after the part that matches 112878 thread 3. This commit tightens that regexp to catch such a bug. It 112879 also tightens the "only main thread left, thread 2 terminated" test's 112880 regexp in the same way. 112881 112882 Change-Id: I8744f327a0aa0e2669d1ddda88247e99b91cefff 112883 1128842022-07-13 Carl Love <cel@us.ibm.com> 112885 112886 Fix for gdb.base/stap-probe.c 112887 On PowePC, the test fails on a compile error: 112888 112889 /../binutils-gdb-current/gdb/testsuite/gdb.base/stap-probe.c:107:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'use_xmm_reg' 112890 107 | use_xmm_reg (int val) 112891 | ^~~~~~~~~~~ 112892 112893 Where the source code for stap-probe.c is: 112894 112895 static const char * __attribute__((noinline)) ATTRIBUTE_NOCLONE 112896 use_xmm_reg (int val) <-- line 107 112897 { 112898 ... 112899 112900 The issue is the ATTRIBUTE_NOCLONE is not defined as an attribute as 112901 expected. The #define for ATTRIBUTE_NOCLONE can be found in 112902 ../lib/attributes.h. 112903 112904 This patch adds the missing include statement for the definition of 112905 ATTRIBUTE_NOCLONE. 112906 112907 The patch has been tested and verified on a Power10 system. 112908 1129092022-07-13 Carl Love <cel@us.ibm.com> 112910 112911 Add PowerPC support to gdb.cp/call-method-register.cc 112912 This patch adds the needed define ASM_REG for PowerPC. 112913 112914 The patch was run on a Power 10 system. The gdb Summary for the run lists 112915 2 expected passes, no unexpected failures or untested testcases. 112916 112917 Please let me know if this patch is acceptable for mainline. 112918 112919 Carl Love 112920 1129212022-07-13 Carl Love <cel@us.ibm.com> 112922 112923 Fix gdb.base/step-indirect-call-thunk.exp 112924 Due to recent changes in the default value of -fcf-protection for gcc, the 112925 test gdb.base/step-indirect-call-thunk.exp fails on Intel X86-64 with the 112926 error: 112927 112928 Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never 112929 -mindirect-branch=thunk -mfunction-return=thunk -c -g 112930 -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o 112931 /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c 112932 (timeout = 300) builtin_spawn -ignore SIGHUP gcc -fno-stack-protector 112933 -fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c 112934 -g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o 112935 /.../binutils-gdb-current/gdb/testsuite/gdb.base/step-indirect-call-thunk.c 112936 /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c: 112937 In function 'inc': /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c: 112938 22:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible 112939 22 | { /* inc.1 */ 112940 112941 As stated in the error message the default "-fcf-protection" and 112942 "-mindirect-branch' are in compatible. The fcf-protection argument needs 112943 to be "-fcf-protection=none" for the test to compile on Intel. 112944 112945 The gcc command line "-mindirect-branch' is an Intel specific and will give 112946 an error on other platforms. A check for X86 is added so the test will 112947 only run on X86 platforms. 112948 112949 The patch has been tested and verified on Power 10 and Intel X86-64 systems 112950 with no regressions. 112951 1129522022-07-13 Pedro Alves <pedro@palves.net> 112953 112954 Fix "until LINE" in main, when "until" runs into longjmp 112955 With a test like this: 112956 112957 1 #include <dlfcn.h> 112958 2 int 112959 3 main () 112960 4 { 112961 5 dlsym (RTLD_DEFAULT, "FOO"); 112962 6 return 0; 112963 7 } 112964 112965 and then "start" followed by "until 6", GDB currently incorrectly 112966 stops inside the runtime loader, instead of line 6. Vis: 112967 112968 ... 112969 Temporary breakpoint 1, main () at until.c:5 112970 4 { 112971 (gdb) until 6 112972 0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206 112973 206 dl-error-skeleton.c: No such file or directory. 112974 (gdb) 112975 112976 The problem is related to longjmp handling -- dlsym internally 112977 longjmps on error. The testcase can be reduced to this: 112978 112979 1 #include <setjmp.h> 112980 2 void func () { 112981 3 jmp_buf buf; 112982 4 if (setjmp (buf) == 0) 112983 5 longjmp (buf, 1); 112984 6 } 112985 7 112986 8 int main () { 112987 9 func (); 112988 10 return 0; /* until to here */ 112989 11 } 112990 112991 and then with "start" followed by "until 10", GDB currently 112992 incorrectly stops at line 4 (returning from setjmp), instead of line 112993 10. 112994 112995 The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in 112996 infrun.c fails to find the initiating frame, and so infrun thinks that 112997 the longjmp jumped somewhere outer to "until"'s originating frame. 112998 112999 Here: 113000 113001 case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME: 113002 { 113003 struct frame_info *init_frame; 113004 113005 /* There are several cases to consider. 113006 113007 1. The initiating frame no longer exists. In this case we 113008 must stop, because the exception or longjmp has gone too 113009 far. 113010 113011 ... 113012 113013 init_frame = frame_find_by_id (ecs->event_thread->initiating_frame); 113014 113015 if (init_frame) // this is NULL! 113016 { 113017 ... 113018 } 113019 113020 /* For Cases 1 and 2, remove the step-resume breakpoint, if it 113021 exists. */ 113022 delete_step_resume_breakpoint (ecs->event_thread); 113023 113024 end_stepping_range (ecs); // case 1., so we stop. 113025 } 113026 113027 The initiating frame is set by until_break_command -> 113028 set_longjmp_breakpoint. The initiating frame is supposed to be the 113029 frame that is selected when the command was issued, but 113030 until_break_command instead passes the frame id of the _caller_ frame 113031 by mistake. When the "until LINE" command is issued from main, the 113032 caller frame is the caller of main. When later infrun tries to find 113033 that frame by id, it fails to find it, because frame_find_by_id 113034 doesn't unwind past main. 113035 113036 The bug is that we passed the caller frame's id to 113037 set_longjmp_breakpoint. We should have passed the selected frame's id 113038 instead. 113039 113040 Change-Id: Iaae1af7cdddf296b7c5af82c3b5b7d9b66755b1c 113041 1130422022-07-13 Enze Li <enze.li@hotmail.com> 113043 113044 gdbserver: remove unused variable 113045 When building with clang 15, I got this error: 113046 113047 CXX server.o 113048 server.cc:2985:10: error: variable 'new_argc' set but not used [-Werror,-Wunused-but-set-variable] 113049 int i, new_argc; 113050 ^ 113051 Remove the unused variable to eliminate the error. 113052 113053 Tested by rebuilding on x86_64-linux with clang 15. 113054 1130552022-07-13 Tom de Vries <tdevries@suse.de> 113056 113057 [gdb/symtab] Make per_cu->set_lang more strict 113058 We have in per_cu->set_lang this comment: 113059 ... 113060 void set_lang (enum language lang) 113061 { 113062 /* We'd like to be more strict here, similar to what is done in 113063 set_unit_type, but currently a partial unit can go from unknown to 113064 minimal to ada to c. */ 113065 ... 113066 113067 Fix this by not setting m_lang for partial units. 113068 113069 This requires us to move the m_unit_type initialization to ensure that 113070 m_unit_type is initialized before per_cu->m_lang. 113071 113072 Tested on x86_64-linux, with native and target board cc-with-dwz-m. 113073 1130742022-07-13 GDB Administrator <gdbadmin@sourceware.org> 113075 113076 Automatic date update in version.in 113077 1130782022-07-12 Pedro Alves <pedro@palves.net> 113079 113080 Improve "set scheduler-locking" documentation 113081 This improves the "set scheduler-locking" documentation in the GDB 113082 manual: 113083 113084 - Use a table to describe the four available modes. 113085 113086 - Describe "step" in terms of "on" and "off". 113087 113088 - Tweak the "replay" mode's description to describe replay first 113089 instead of recording, and also mention how the mode behaves during 113090 normal execution. 113091 113092 - Say what is the default mode. 113093 113094 Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce 113095 1130962022-07-12 Tom de Vries <tdevries@suse.de> 113097 113098 [gdb/symtab] Add dwarf2_cu::lang () 113099 The cu->per_cu->lang field was added to carry information from the initial 113100 partial symtabs phase to the symtab expansion phase, for the benefit of a 113101 particular optimization in process_imported_unit_die. 113102 113103 Other uses have been added, but since the first phase now has been 113104 parallelized, those have become problematic and sources of race conditions. 113105 113106 Fix this by adding dwarf2_cu::lang () and using it where we can to replace 113107 cu->per_cu->lang () with cu->lang (). 113108 113109 Also assert in dwarf2_cu::lang () that we're not returning language_unknown. 113110 113111 Tested on x86_64-linux. 113112 1131132022-07-12 Martin Liska <mliska@suse.cz> 113114 113115 LTO plugin: sync header file with GCC 113116 include/ChangeLog: 113117 113118 * plugin-api.h (enum ld_plugin_tag): Sync with GCC. 113119 1131202022-07-12 Tom de Vries <tdevries@suse.de> 113121 113122 [gdb/record] Support recording of getrandom 113123 Add missing support for recording of linux syscall getrandom. 113124 113125 Tested on x86_64-linux with native and target board unix/-m32. 113126 113127 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22081 113128 1131292022-07-12 Tiezhu Yang <yangtiezhu@loongson.cn> 113130 113131 gdbserver: LoongArch: Add floating-point support 113132 This commit adds floating-point support for LoongArch gdbserver. 113133 113134 gdb: LoongArch: Add floating-point support 113135 This commit adds floating-point support for LoongArch gdb. 113136 1131372022-07-12 Tom de Vries <tdevries@suse.de> 113138 113139 [gdb/testsuite] Run two test-cases with ASAN_OPTIONS=verify_asan_link_order=0 113140 When building gdb with -fsanitize=address we run into: 113141 ... 113142 builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \ 113143 build/gdb/data-directory^M 113144 ==10637==ASan runtime does not come first in initial library list; you \ 113145 should either link runtime to your application or manually preload it with \ 113146 LD_PRELOAD.^M 113147 ERROR: GDB process no longer exists 113148 ... 113149 113150 Prevent the ASan runtime error by using 113151 ASAN_OPTIONS=verify_asan_link_order=0. This makes both test-cases pass. 113152 113153 Tested on x86_64-linux. 113154 113155 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29358 113156 1131572022-07-12 Tom de Vries <tdevries@suse.de> 113158 113159 [gdb/testsuite] Add tsan-suppressions.txt 113160 Add a new file tsan-suppressions.txt, to suppress the "unlock unlocked mutex" 113161 problem in ncurses, filed in PR29328. 113162 113163 The file is added to the TSAN_OPTIONS in lib/gdb.exp. 113164 113165 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29328 113166 1131672022-07-12 Tom de Vries <tdevries@suse.de> 113168 113169 [gdb/build] Fix build with gcc 4.8.5 113170 When building gdb with gcc 4.8.5, we run into problems due to unconditionally 113171 using: 113172 ... 113173 gdb_static_assert (std::is_trivially_copyable<packed>::value); 113174 ... 113175 in gdbsupport/packed.h. 113176 113177 Fix this by guarding the usage with HAVE_IS_TRIVIALLY_COPYABLE. 113178 113179 Tested by doing a full gdb build with gcc 4.8.5. 113180 1131812022-07-12 Tom de Vries <tdevries@suse.de> 113182 113183 Fix -fsanitize=thread for per_cu fields 113184 When building gdb with -fsanitize=thread and gcc 12, and running test-case 113185 gdb.dwarf2/dwz.exp, we run into a data race between: 113186 ... 113187 Read of size 1 at 0x7b200000300d by thread T2:^M 113188 #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ 113189 abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ 113190 (gdb+0x82ec95)^M 113191 ... 113192 and: 113193 ... 113194 Previous write of size 1 at 0x7b200000300d by main thread:^M 113195 #0 prepare_one_comp_unit gdb/dwarf2/read.c:23588 (gdb+0x86f973)^M 113196 ... 113197 113198 In other words, between: 113199 ... 113200 if (this_cu->reading_dwo_directly) 113201 ... 113202 and: 113203 ... 113204 cu->per_cu->lang = pretend_language; 113205 ... 113206 113207 Likewise, we run into a data race between: 113208 ... 113209 Write of size 1 at 0x7b200000300e by thread T4: 113210 #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720) 113211 ... 113212 and: 113213 ... 113214 Previous read of size 1 at 0x7b200000300e by main thread: 113215 #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ 113216 abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ 113217 (gdb+0x82edab) 113218 ... 113219 113220 In other words, between: 113221 ... 113222 this_cu->unit_type = DW_UT_partial; 113223 ... 113224 and: 113225 ... 113226 if (this_cu->reading_dwo_directly) 113227 ... 113228 113229 Likewise for the write to addresses_seen in cooked_indexer::check_bounds and a 113230 read from is_dwz in dwarf2_find_containing_comp_unit for test-case 113231 gdb.dwarf2/dw2-dir-file-name.exp and target board cc-with-dwz-m. 113232 113233 The problem is that the written fields are part of the same memory location as 113234 the read fields, so executing a read and write in different threads is 113235 undefined behavour. 113236 113237 Making the written fields separate memory locations, using the new 113238 struct packed template fixes this. 113239 113240 The set of fields has been established experimentally to be the 113241 minimal set to get rid of this type of -fsanitize=thread errors, but 113242 more fields might require the same treatment. 113243 113244 Looking at the properties of the lang field, unlike dwarf_version it's 113245 not available in the unit header, so it will be set the first time 113246 during the parallel cooked index reading. The same holds for 113247 unit_type, and likewise for addresses_seen. 113248 113249 dwarf2_per_cu_data::addresses_seen is moved so that the bitfields that 113250 currently follow it can be merged in the same memory location as the 113251 bitfields that currently precede it, for better packing. 113252 113253 Tested on x86_64-linux. 113254 113255 Co-Authored-By: Pedro Alves <pedro@palves.net> 113256 113257 Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532 113258 1132592022-07-12 Pedro Alves <pedro@palves.net> 113260 113261 Introduce struct packed template 113262 When building gdb with -fsanitize=thread and gcc 12, and running test-case 113263 gdb.dwarf2/dwz.exp, we run into a few data races. For example, between: 113264 113265 ... 113266 Write of size 1 at 0x7b200000300e by thread T4: 113267 #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720) 113268 ... 113269 113270 and: 113271 113272 ... 113273 Previous read of size 1 at 0x7b200000300e by main thread: 113274 #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ 113275 abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ 113276 (gdb+0x82edab) 113277 ... 113278 113279 In other words, between: 113280 113281 ... 113282 this_cu->unit_type = DW_UT_partial; 113283 ... 113284 113285 and: 113286 113287 ... 113288 if (this_cu->reading_dwo_directly) 113289 ... 113290 113291 The problem is that the written fields are part of the same memory 113292 location as the read fields, so executing a read and write in 113293 different threads is undefined behavour. 113294 113295 Making the written fields separate memory locations, like this: 113296 113297 ... 113298 struct { 113299 ENUM_BITFIELD (dwarf_unit_type) unit_type : 8; 113300 }; 113301 ... 113302 113303 fixes it, however that also increases the size of struct 113304 dwarf2_per_cu_data, because it introduces padding due to alignment of 113305 these new structs, which align on the natural alignment of the 113306 specified type of their fields. We can fix that with 113307 __attribute__((packed)), like so: 113308 113309 struct { 113310 ENUM_BITFIELD (dwarf_unit_type) unit_type : 8 __attribute__((packed)); 113311 }; 113312 113313 but to avoid having to write that in several places and add suitable 113314 comments explaining how that concoction works, introduce a new struct 113315 packed template that wraps/hides this. Instead of the above, we'll be 113316 able to write: 113317 113318 packed<dwarf_unit_type, 1> unit_type; 113319 113320 Note that we can't change the type of dwarf_unit_type, as that is 113321 defined in include/, and shared with other projects, some of those 113322 written in C. 113323 113324 This patch just adds the struct packed type. Following patches will 113325 make use of it. One of those patches will want to wrap a struct 113326 packed in an std::atomic, like: 113327 113328 std::atomic<std::packed<language, 1>> m_lang; 113329 113330 so the new gdbsupport/packed.h header adds some operators to make 113331 comparisions between that std::atomic and the type that the wrapped 113332 struct packed wraps work, like in: 113333 113334 if (m_lang == language_c) 113335 113336 It would be possible to implement struct packed without using 113337 __attribute__((packed)), by having it store an array of bytes of the 113338 appropriate size instead, however that would make it less convenient 113339 to debug GDB. The way it's implemented, printing a struct packed 113340 variable just prints its field using its natural type, which is 113341 particularly useful if the type is an enum. I believe that 113342 __attribute__((packed)) is supported by all compilers that are able to 113343 build GDB. Even a few BFD headers use on ATTRIBUTE_PACKED on external 113344 types: 113345 113346 include/coff/external.h: } ATTRIBUTE_PACKED 113347 include/coff/external.h:} ATTRIBUTE_PACKED ; 113348 include/coff/external.h:} ATTRIBUTE_PACKED ; 113349 include/coff/pe.h:} ATTRIBUTE_PACKED ; 113350 include/coff/pe.h:} ATTRIBUTE_PACKED; 113351 include/elf/external.h:} ATTRIBUTE_PACKED Elf_External_Versym; 113352 113353 It is not possible to build GDB with MSVC today, but if it could, that 113354 would be one compiler that doesn't support this attribute. However, 113355 it supports packing via pragmas, so there's a way to cross that bridge 113356 if we ever get to it. I believe any compiler worth its salt supports 113357 some way of packing. 113358 113359 In any case, the worse that happens without the attribute is that some 113360 types become larger than ideal. Regardless, I've added a couple 113361 static assertions to catch such compilers in action: 113362 113363 /* Ensure size and aligment are what we expect. */ 113364 gdb_static_assert (sizeof (packed) == Bytes); 113365 gdb_static_assert (alignof (packed) == 1); 113366 113367 Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532 113368 1133692022-07-12 Alan Modra <amodra@gmail.com> 113370 113371 PowerPC md_end: Don't htab_delete(NULL) 113372 It might be possible to hit md_end before md_begin is called, don't 113373 segfault if so. Also, remove a useless check. 113374 113375 * gas/config/tc-ppc.c (insn_calloc): Remove needless overflow 113376 check. 113377 (ppc_md_end): Check ppc_hash before deleting. Clear ppc_hash. 113378 1133792022-07-12 Alan Modra <amodra@gmail.com> 113380 113381 PR29355, ld segfaults with -r/-q and custom-named section .rela* 113382 The bug testcase uses an output section named .rel or .rela which has 113383 input .data sections mapped to it. The input .data section has 113384 relocations. When counting output relocations SHT_REL and SHT_RELA 113385 section reloc_count is ignored, with the justification that reloc 113386 sections themselves can't have relocations and some backends use 113387 reloc_count in reloc sections. However, the test wrongly used the 113388 output section type (which normally would match input section type). 113389 Fix that. Note that it is arguably wrong for ld to leave the output 113390 .rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc 113391 sections are written to it, but I'm not going to change that since it 113392 might be useful to hand-craft relocs in a data section that is then 113393 written to a SHT_REL/SHT_RELA output section. 113394 113395 PR 29355 113396 * elflink.c (bfd_elf_final_link): Use input section type rather 113397 than output section type to determine whether to exclude using 113398 reloc_count from that section. 113399 1134002022-07-12 Jiangshuai Li <jiangshuai_li@c-sky.com> 113401 113402 gdb/csky complete csky_dwarf_reg_to_regnum 113403 For csky arch, the correspondence between Dwarf registers and GDB 113404 registers are as follows: 113405 dwarf regnos 0~31 ==> gdb regs r0~r31 113406 dwarf regno CSKY_HI_REGNUM(36) ==> gdb reg hi 113407 dwarf regno CSKY_LO_REGNUM(37) ==> gdb reg hi 113408 dwarf regno CSKY_PC_REGNUM(72) ==> gdb reg pc 113409 dwarf regnos FV_PSEUDO_REGNO_FIRST(74)~FV_PSEUDO_REGNO_LAST(201) 113410 ==> 113411 gdb regs s0~s127 (pseudo regs for float and vector regs) 113412 113413 other dwarf regnos have no corresponding gdb regs to them. 113414 1134152022-07-12 GDB Administrator <gdbadmin@sourceware.org> 113416 113417 Automatic date update in version.in 113418 1134192022-07-11 Pedro Alves <pedro@palves.net> 113420 113421 Always emit =thread-exited notifications, even if silent 113422 [Note: the testcased added by this commit depends on 113423 https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html, 113424 otherwise GDB just crashes when detaching the core] 113425 113426 Currently, in MI, =thread-created are always emitted, like: 113427 113428 =thread-group-started,id="i1",pid="195680" 113429 =thread-created,id="1",group-id="i1" 113430 ... 113431 113432 but on teardown, if the target uses exit_inferior_silent, then you'll 113433 only see the inferior exit notification (thread-group-exited), no 113434 notification for threads. 113435 113436 The core target is one of the few targets that use 113437 exit_inferior_silent. Here's an example session: 113438 113439 -target-select core $corefile 113440 =thread-group-started,id="i1",pid="195680" 113441 =thread-created,id="1",group-id="i1" 113442 ... 113443 ^connected,frame=.... 113444 (gdb) 113445 -target-detach 113446 =thread-group-exited,id="i1" 113447 ^done 113448 (gdb) 113449 113450 This imbalance of emitting =thread-created but then not =thread-exited 113451 seems off to me. (And, it complicates changes I want to do to 113452 centralize emitting thread exit notifications for the CLI, which is 113453 why I'm looking at this.) 113454 113455 And then, since most other targets use exit_inferior instead of 113456 exit_inferior_silent, MI is already emitting =thread-exited 113457 notifications when tearing down an inferior, for most targets. 113458 113459 This commit makes MI always emit the =thread-exited notifications, 113460 even for exit_inferior_silent. 113461 113462 Afterwards, when debugging a core, MI outputs: 113463 113464 (gdb) 113465 -target-detach 113466 =thread-exited,id="1",group-id="i1" << new line 113467 =thread-group-exited,id="i1" 113468 ^done 113469 (gdb) 113470 113471 Surprisingly, there's no MI testcase debugging a core file. This 113472 commit adds the first. 113473 113474 Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4 113475 1134762022-07-11 Pedro Alves <pedro@palves.net> 113477 113478 Fix core-file -> detach -> crash (corefiles/29275) 113479 After loading a core file, you're supposed to be able to use "detach" 113480 to unload the core file. That unfortunately regressed starting with 113481 GDB 11, with these commits: 113482 113483 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses 113484 408f66864a1a - detach in all-stop with threads running 113485 113486 resulting in a GDB crash: 113487 113488 ... 113489 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 113490 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899 113491 2899 if (proc_target->commit_resumed_state) 113492 (top-gdb) bt 113493 #0 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899 113494 #1 0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023 113495 #2 0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049 113496 #3 0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791 113497 #4 0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95 113498 #5 0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514 113499 #6 0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699 113500 113501 The code that crashes looks like: 113502 113503 static void 113504 maybe_set_commit_resumed_all_targets () 113505 { 113506 scoped_restore_current_thread restore_thread; 113507 113508 for (inferior *inf : all_non_exited_inferiors ()) 113509 { 113510 process_stratum_target *proc_target = inf->process_target (); 113511 113512 if (proc_target->commit_resumed_state) 113513 ^^^^^^^^^^^ 113514 113515 With 'proc_target' above being null. all_non_exited_inferiors filters 113516 out inferiors that have pid==0. We get here at the end of 113517 detach_command, after core_target::detach has already run, at which 113518 point the inferior _should_ have pid==0 and no process target. It is 113519 clear it no longer has a process target, but, it still has a pid!=0 113520 somehow. 113521 113522 The reason the inferior still has pid!=0, is that core_target::detach 113523 just unpushes, and relies on core_target::close to actually do the 113524 getting rid of the core and exiting the inferior. The problem with 113525 that is that detach_command grabs an extra strong reference to the 113526 process stratum target, so the unpush_target inside 113527 core_target::detach doesn't actually result in a call to 113528 core_target::close. 113529 113530 Fix this my moving the cleaning up the core inferior to a shared 113531 routine called by both core_target::close and core_target::detach. We 113532 still need to cleanup the inferior from within core_file::close 113533 because there are paths to it that want to get rid of the core without 113534 going through detach. E.g., "core-file" -> "run". 113535 113536 This commit includes a new test added to gdb.base/corefile.exp to 113537 cover the "core-file core" -> "detach" scenario. 113538 113539 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275 113540 113541 Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893 113542 1135432022-07-11 Pedro Alves <pedro@palves.net> 113544 113545 Fix non-existent "@var{thread-id}" in stop reply descriptions 113546 In the description of stop replies, where the "thread" register is 113547 explained, and where the fork and vfork stop reasons are detailed, 113548 there are references to "@var{thread-id}", but such variable does not 113549 actually exist. This commit fixes it. 113550 113551 Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab 113552 1135532022-07-11 Luis Machado <luis.machado@arm.com> 113554 113555 Try a couple PAuth compilation flags for gdb.arch/aarch64-pauth.exp 113556 The -msign-return-address switch has been dropped from GCC, but some 113557 older compiler may still support it. Make sure we try both 113558 -msign-return-address and -mbranch-protection before bailing out when 113559 running gdb.arch/aarch64-pauth.exp. 113560 1135612022-07-11 Andrew Burgess <aburgess@redhat.com> 113562 113563 gdb: add support for disassembler styling using libopcodes 113564 This commit extends GDB to make use of libopcodes styling support 113565 where available, currently this is just i386 based architectures, and 113566 RISC-V. 113567 113568 For architectures that don't support styling using libopcodes GDB will 113569 fall back to using the Python Pygments package, when the package is 113570 available. 113571 113572 The new libopcodes based styling has the disassembler identify parts 113573 of the disassembled instruction, e.g. registers, immediates, 113574 mnemonics, etc, and can style these components differently. 113575 Additionally, as the styling is now done in GDB we can add settings to 113576 allow the user to configure which colours are used right from the GDB 113577 CLI. 113578 113579 There's some new maintenance commands: 113580 113581 maintenance set libopcodes-styling enabled on|off 113582 maintenance show libopcodes-styling 113583 113584 These can be used to manually disable use of libopcodes styling. This 113585 is a maintenance command as it's not anticipated that a user should 113586 need to do this. But, this could be useful for testing, or, in some 113587 rare cases, a user might want to override the Python hook used for 113588 disassembler styling, and then disable libopcode styling so that GDB 113589 falls back to using Python. Right now I would consider this second 113590 use case a rare situation, which is why I think a maintenance command 113591 is appropriate. 113592 113593 When libopcodes is being used for styling then the user can make use 113594 of the following new styles: 113595 113596 set/show style disassembler comment 113597 set/show style disassembler immediate 113598 set/show style disassembler mnemonic 113599 set/show style disassembler register 113600 113601 The disassembler also makes use of the 'address' and 'function' 113602 styles to style some parts of the disassembler output. I have also 113603 added the following aliases though: 113604 113605 set/show style disassembler address 113606 set/show style disassembler symbol 113607 113608 these are aliases for: 113609 113610 set/show style address 113611 set/show style function 113612 113613 respectively, and exist to make it easier for users to discover 113614 disassembler related style settings. The 'address' style is used to 113615 style numeric addresses in the disassembler output, while the 'symbol' 113616 or 'function' style is used to style the names of symbols in 113617 disassembler output. 113618 113619 As not every architecture supports libopcodes styling, the maintenance 113620 setting 'libopcodes-styling enabled' has an "auto-off" type behaviour. 113621 Consider this GDB session: 113622 113623 (gdb) show architecture 113624 The target architecture is set to "auto" (currently "i386:x86-64"). 113625 (gdb) maintenance show libopcodes-styling enabled 113626 Use of libopcodes styling support is "on". 113627 113628 the setting defaults to "on" for architectures that support libopcodes 113629 based styling. 113630 113631 (gdb) set architecture sparc 113632 The target architecture is set to "sparc". 113633 (gdb) maintenance show libopcodes-styling enabled 113634 Use of libopcodes styling support is "off" (not supported on architecture "sparc") 113635 113636 the setting will show as "off" if the user switches to an architecture 113637 that doesn't support libopcodes styling. The underlying setting is 113638 still "on" at this point though, if the user switches back to 113639 i386:x86-64 then the setting would go back to being "on". 113640 113641 (gdb) maintenance set libopcodes-styling enabled off 113642 (gdb) maintenance show libopcodes-styling enabled 113643 Use of libopcodes styling support is "off". 113644 113645 now the setting is "off" for everyone, even if the user switches back 113646 to i386:x86-64 the setting will still show as "off". 113647 113648 (gdb) maintenance set libopcodes-styling enabled on 113649 Use of libopcodes styling not supported on architecture "sparc". 113650 (gdb) maintenance show libopcodes-styling enabled 113651 Use of libopcodes styling support is "off". 113652 113653 attempting to switch the setting "on" for an unsupported architecture 113654 will give an error, and the setting will remain "off". 113655 113656 (gdb) set architecture auto 113657 The target architecture is set to "auto" (currently "i386:x86-64"). 113658 (gdb) maintenance show libopcodes-styling enabled 113659 Use of libopcodes styling support is "off". 113660 (gdb) maintenance set libopcodes-styling enabled on 113661 (gdb) maintenance show libopcodes-styling enabled 113662 Use of libopcodes styling support is "on". 113663 113664 the user will need to switch back to a supported architecture before 113665 they can one again turn this setting "on". 113666 1136672022-07-11 Andrew Burgess <aburgess@redhat.com> 113668 113669 gdb: have gdb_disassemble_info carry 'this' in its stream pointer 113670 The gdb_disassemble_info class is a wrapper around the libopcodes 113671 disassemble_info struct. The 'stream' field of disassemble_info is 113672 passed as an argument to the fprintf_func and fprintf_styled_func 113673 callbacks when the disassembler wants to print anything. 113674 113675 Previously, GDB would store a pointer to a ui_file object in the 113676 'stream' field, then, when the disassembler wanted to print anything, 113677 the content would be written to the ui_file object. An example of an 113678 fprintf_func callback, from gdb/disasm.c is: 113679 113680 int 113681 gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...) 113682 { 113683 /* Write output to STREAM here. */ 113684 } 113685 113686 This is fine, but has one limitation, within the print callbacks we 113687 only have access to STREAM, we can't access any additional state 113688 stored within the gdb_disassemble_info object. 113689 113690 Right now this isn't a problem, but in a future commit this will 113691 become an issue, how we style the output being written to STREAM will 113692 depend on the state of the gdb_disassemble_info object, and this state 113693 might need to be updated, depending on what is being printed. 113694 113695 In this commit I propose changing the 'stream' field of the 113696 disassemble_info to carry a pointer to the gdb_disassemble_info 113697 sub-class, rather than the stream itself. 113698 113699 We then have the two sub-classes of gdb_disassemble_info to consider, 113700 the gdb_non_printing_disassembler class never cared about the stream, 113701 previously, for this class, the stream was nullptr. With the change 113702 to make stream be a gdb_disassemble_info pointer, no further updates 113703 are needed for gdb_non_printing_disassembler. 113704 113705 The other sub-class is gdb_printing_disassembler. In this case the 113706 sub-class now carries around a pointer to the stream object. The 113707 print callbacks are updated to cast the incoming stream object back to 113708 a gdb_printing_disassembler, and then extract the stream. 113709 113710 This is purely a refactoring commit. A later commit will add 113711 additional state to the gdb_printing_disassembler, and update the 113712 print callbacks to access this state. 113713 113714 There should be no user visible changes after this commit. 113715 1137162022-07-11 Tom de Vries <tdevries@suse.de> 113717 113718 [gdb/symtab] Fix data race in per_cu->length 113719 With gdb build with -fsanitize=thread and test-case 113720 gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data 113721 race between: 113722 ... 113723 Write of size 4 at 0x7b2800002268 by thread T4:^M 113724 #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ 113725 abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \ 113726 (gdb+0x82f525)^M 113727 ... 113728 and this read: 113729 ... 113730 Previous read of size 4 at 0x7b2800002268 by thread T1:^M 113731 #0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \ 113732 (gdb+0x86e22e)^M 113733 ... 113734 113735 In other words, between this write: 113736 ... 113737 this_cu->length = cu->header.get_length (); 113738 ... 113739 and this read: 113740 ... 113741 && mid_cu->sect_off + mid_cu->length > sect_off)) 113742 ... 113743 of per_cu->length. 113744 113745 Fix this similar to the per_cu->dwarf_version case, by only setting it if 113746 needed, and otherwise verifying that the same value is used. [ Note that the 113747 same code is already present in the other cutu_reader constructor. ] 113748 113749 Move this logic into into a member function set_length to make sure it's used 113750 consistenly, and make the field private in order to enforce access through the 113751 member functions, and rename it to m_length. 113752 113753 This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in 113754 fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten. 113755 For now, allow for that exception. 113756 113757 While we're at it, make sure that the length is set before read. 113758 113759 Tested on x86_64-linux. 113760 113761 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29344 113762 1137632022-07-11 Tom de Vries <tdevries@suse.de> 113764 113765 [gdb/symtab] Use comp_unit_head::get_length 113766 There's a spot in read_comp_units_from_section where we explictly use 113767 initial_length_size to get the total length: 113768 ... 113769 this_cu->length = cu_header.length + cu_header.initial_length_size; 113770 ... 113771 113772 Instead, just use cu_header.get_length (). 113773 113774 Tested on x86_64-linux. 113775 1137762022-07-11 GDB Administrator <gdbadmin@sourceware.org> 113777 113778 Automatic date update in version.in 113779 1137802022-07-10 Luis Machado <luis.machado@arm.com> 113781 113782 Fix include guard naming for arch/aarch64-mte-linux.h 113783 It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H. 113784 1137852022-07-10 Youling Tang <tangyouling@loongson.cn> 113786 113787 gdbserver: LoongArch: Add orig_a0 processing 113788 Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set") 113789 introduced orig_a0, similar processing needs to be done in gdbserver. 113790 113791 At the same time, add orig_a0 related comments. 113792 1137932022-07-10 Youling Tang <tangyouling@loongson.cn> 113794 113795 gdbserver: LoongArch: Simplify code with register number macros 113796 Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the 113797 macro definitions can be used in gdbserver/linux-loongarch-low.cc 113798 to simplify the code. 113799 1138002022-07-10 GDB Administrator <gdbadmin@sourceware.org> 113801 113802 Automatic date update in version.in 113803 1138042022-07-09 Alan Modra <amodra@gmail.com> 113805 113806 gas: tc-tic54x.c hash tables 113807 Cleaning up the subsym_hash memory is a real pain. Keys and values 113808 entered into the table are quite diverse. In some cases the key is 113809 allocated and thus needs to be freed, in others the key is a const 113810 string. Values are similar, and in some cases not even a string. 113811 Tidy this by inserting a new subsym_ent_t that describes key/value 113812 type. This meant the math_hash table was no longer needed. The patch 113813 also tidies how math functions are called, those that are supposed to 113814 return int now no longer return their value in a float. 113815 113816 * config/tc-tic54x.c (math_hash): Delete. 113817 (subsym_proc_entry): Move earlier, make proc a union, merge with.. 113818 (math_proc_entry): ..this. Delete type. 113819 (math_procs): Merge into subsym_procs. 113820 (subsym_ent_t): New. Use this type in subsym_hash.. 113821 (stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here.. 113822 (md_begin, subsym_create_or_replace, subsym_lookup): ..and here.. 113823 (subsym_substitute): ..and here. Adjust subsym_proc_entry 113824 function calls. Free replacement when not returned. 113825 (subsym_get_arg): Adjust subsym_lookup. 113826 (free_subsym_ent, subsym_htab_create ): New functions, use when 113827 creating subsym_hash. 113828 (free_local_label_ent, local_label_htab_create): Similarly. 113829 (tic54x_remove_local_label): Delete. 113830 (tic54x_clear_local_labels): Simplify. 113831 (tic54x_asg): Use notes obstack to dup strings. 113832 (tic54x_eval): Likewise. 113833 (subsym_ismember): Likewise. 113834 (math_cvi, math_int, math_sgn): Return int. 113835 (tic54x_macro_start): Decrement macro_level before calling as_fatal. 113836 (tic54x_md_end): New function. 113837 * config/tc-tic54h.c (tic54x_md_end): Declare. 113838 (md_end): Define. 113839 1138402022-07-09 Alan Modra <amodra@gmail.com> 113841 113842 gas: use notes_calloc in string hash 113843 Using notes_calloc means all of the string hash table memory should 113844 now be freed before gas exits, even though htab_delete isn't called. 113845 This also means that the hash table free_f and del_f must be NULL, 113846 because freeing notes obstack memory results in all more recently 113847 allocated notes memory being freed too. So hash table resizing won't 113848 free any memory, and will be a little faster. Also, htab_delete won't 113849 do anything (and be quick about it). 113850 113851 Since htab_traverse can also resize hash tables (to make another 113852 traversal faster if the table is largely empty), stop that happening 113853 when only one traversal is done. 113854 113855 * as.h: Reorder hash.h after symbols.h for notes_calloc decl. 113856 * hash.h (str_htab_create): Use notes_calloc. Do not free. 113857 * symbols.c (resolve_local_symbol_values): Don't resize 113858 during hash table traversal. 113859 * config/obj-elf.c (elf_frob_file_after_relocs): Likewise. 113860 * config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise. 113861 * config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise. 113862 1138632022-07-09 Alan Modra <amodra@gmail.com> 113864 113865 gas: target string hash tables 113866 This allocates entries added to the string hash tables on the notes 113867 obstack, so that at least those do not leak. A followup patch will 113868 switch over the str_hash allocation to notes_calloc, which is why I 113869 haven't implemented deleting all the target string hash tables. 113870 113871 * config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use 113872 notes obstack for string hash table entries. 113873 * config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise. 113874 * config/tc-h8300.c (md_begin): Likewise. 113875 * config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise. 113876 * config/tc-nds32.c (nds32_relax_hint): Likewise. 113877 * config/tc-riscv.c (riscv_init_csr_hash): Likewise. 113878 * config/tc-score.c (s3_insert_reg): Likewise. 113879 (s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise. 113880 * config/tc-score7.c (s7_build_score_ops_hsh): Likewise. 113881 (s7_build_dependency_insn_hsh): Likewise. 113882 * config/tc-tic4x.c (tic4x_asg): Likewise. 113883 1138842022-07-09 Alan Modra <amodra@gmail.com> 113885 113886 arc gas: don't leak arc_opcode_hash memory 113887 The arc opcode hash table has entries that have a realloc'd field. 113888 This doesn't lend itself to obstack allocation, so freeing must be 113889 done with a purpose built hashtab del_f. 113890 113891 * config/tc-arc.c (arc_opcode_free): New function. 113892 (md_begin): Pass the above as del_f to htab_create_alloc. 113893 (arc_md_end): New function. 113894 * config/tc-arc.h (arc_md_end): Declare. 113895 (md_end): Define. 113896 1138972022-07-09 Alan Modra <amodra@gmail.com> 113898 113899 i386 gas: don't leak op_hash or reg_hash memory 113900 This tidies memory used by the two x86 gas string hash tables before 113901 exiting. I'm using a two-pronged approach, firstly the obvious call 113902 to htab_delete plus telling the libiberty/hashtab.c infrastructure to 113903 free tuples generated by str_hash_insert, and secondly putting the x86 113904 core_optab memory on the notes obstack. It would be possible to free 113905 core_optab memory by using a custom hash table del_f on x86, as I do 113906 for arc, but a later patch will move all the string hash memory to the 113907 notes obstack. 113908 113909 * config/tc-i386.c (md_begin): Use notes_alloc for core_optab. 113910 (386_md_end): New function. 113911 * config/tc-i386.h (386_md_end): Declare. 113912 (md_end): Define. 113913 * hash.h (str_htab_create): Pass free as del_f. 113914 1139152022-07-09 Alan Modra <amodra@gmail.com> 113916 113917 ppc gas: don't leak ppc_hash memory 113918 * config/tc-ppc.c (insn_obstack): New. 113919 (insn_calloc): New function. 113920 (ppc_setup_opcodes): Use insn_obstack for ppc_hash. 113921 (ppc_md_end): New function. 113922 * config/tc-ppc.h (ppc_md_end): Declare 113923 (md_end): Define. 113924 1139252022-07-09 Alan Modra <amodra@gmail.com> 113926 113927 gas hash.h tidy 113928 Only inline functions should be defined in hash.h, there's no benefit 113929 in having multiple copies of hash_string_tuple and eq_string_tuple. 113930 Also, use the table alloc_f when allocating tuples to be stored, so 113931 that these functions are usable with different memory allocation 113932 strategies. 113933 113934 * hash.h (struct string_tuple, string_tuple_t): Move earlier. 113935 (string_tuple_alloc): Add table param, allocate using table alloc_f. 113936 (str_hash_insert): Adjust to suit. Call table->free_f when 113937 entry is not used. 113938 (hash_string_tuple, eq_string_tuple): Move to.. 113939 * hash.c: ..here. 113940 1139412022-07-09 Alan Modra <amodra@gmail.com> 113942 113943 gas: rename md_end to md_finish 113944 Currently md_end is typically used for some final actions rather than 113945 freeing memory like other *_end functions. Rename it to md_finish, 113946 and rename target implementation. The renaming of target functions 113947 makes it possible to find them all with "grep md_finish", 113948 eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish. 113949 This patch leaves a number of md_end functions unchanged, those that 113950 either do nothing or deallocate memory, and calls them late. 113951 113952 The idea here is that target maintainers implement md_end functions to 113953 tidy memory, if anyone cares. Freeing persistent memory in gas is 113954 not at all important, except that it can hide more important memory 113955 leaks, those that happen once per some frequent gas operation, amongst 113956 these unimportant memory leaks. 113957 113958 * as.c (main): Rename md_end to md_finish. 113959 * config/tc-alpha.c, * config/tc-alpha.h, 113960 * config/tc-arc.c, * config/tc-arc.h, 113961 * config/tc-arm.c, * config/tc-arm.h, 113962 * config/tc-csky.c, * config/tc-csky.h, 113963 * config/tc-ia64.c, * config/tc-ia64.h, 113964 * config/tc-mcore.c, * config/tc-mcore.h, 113965 * config/tc-mips.c, * config/tc-mips.h, 113966 * config/tc-mmix.c, * config/tc-mmix.h, 113967 * config/tc-msp430.c, * config/tc-msp430.h, 113968 * config/tc-nds32.c, * config/tc-nds32.h, 113969 * config/tc-ppc.c, * config/tc-ppc.h, 113970 * config/tc-pru.c, * config/tc-pru.h, 113971 * config/tc-riscv.c, * config/tc-riscv.h, 113972 * config/tc-s390.c, * config/tc-s390.h, 113973 * config/tc-sparc.c, * config/tc-sparc.h, 113974 * config/tc-tic4x.c, * config/tc-tic4x.h, 113975 * config/tc-tic6x.c, * config/tc-tic6x.h, 113976 * config/tc-v850.c, * config/tc-v850.h, 113977 * config/tc-xtensa.c, * config/tc-xtensa.h, 113978 * config/tc-z80.c, * config/tc-z80.h: Similarly. 113979 * output-file.c (output_file_close): Call md_end. 113980 1139812022-07-09 Alan Modra <amodra@gmail.com> 113982 113983 gas: set up notes obstack earlier 113984 So that the notes obstack can be used for persistent storage in 113985 parse_args. 113986 113987 * as.c (parse_args): Use notes_alloc and notes_strdup. 113988 (free_notes): New function. 113989 (main): Init notes obstack, and arrange to be freed on exit. 113990 * read.c (read_begin): Don't init notes obstack. 113991 (read_end): Free cond_obstack. 113992 * subsegs.c (subsegs_end): Don't free cond_obstack or notes. 113993 1139942022-07-09 Alan Modra <amodra@gmail.com> 113995 113996 gas: itbl_files 113997 itbl_files seems to be debug code. Get rid of it. 113998 113999 * as.c (struct itbl_file_list): Delete. 114000 (itbl_files): Delete. 114001 (parse_args): Don't keep itbl_files list. 114002 1140032022-07-09 Alan Modra <amodra@gmail.com> 114004 114005 gas: free sy_hash, macro_hash and po_hash 114006 * macro.c (macro_end): New function. 114007 * macro.h (macro_end): Declare. 114008 * read.c (read_end, poend): New functions. 114009 * read.h (read_end): Declare. 114010 * symbols.c (symbol_end): New function. 114011 * symbols.h (symbol_end): Declare. 114012 * output-file.c (output_file_close): Call new *_end functions. 114013 1140142022-07-09 Alan Modra <amodra@gmail.com> 114015 114016 dw2gencfi.c: use notes obstack 114017 Use notes obstack for dwcfi_hash entries, and free table. Freeing the 114018 table makes memory checkers complain more about "definitely lost" 114019 memory as we've moved some from the "still reachable" category. 114020 That will be fixed with a later patch. 114021 114022 * dw2gencfi.c (get_debugseg_name): Allocate on notes obstack. 114023 (alloc_debugseg_item): Likewise. 114024 (dwcfi_hash_find_or_make): Adjust failure path free. 114025 (cfi_finish): Delete dwfci_hash. 114026 1140272022-07-09 Alan Modra <amodra@gmail.com> 114028 114029 expr.c make_expr_symbol: use notes obstack 114030 * expr.c (make_expr_symbol): Use notes_alloc. 114031 114032 read.c assign_symbol: use notes obstack for dummy listing frag 114033 * read.c (assign_symbol): Use notes_calloc for dummy_frag. 114034 114035 read.c s_include: use notes obstack for path 114036 * read.c (s_include): Use notes obstack for path mem. 114037 1140382022-07-09 Alan Modra <amodra@gmail.com> 114039 114040 macro.c: use string hash from hash.h for macro_hash 114041 Another case of duplicated hash.h code, the only minor difference 114042 being that macro->format_hash was created with 7 entries vs. str_hash 114043 with 16 entries. 114044 114045 * macro.c (macro_init, define_macro): Use str_htab_create. 114046 (do_formals, define_macro, macro_expand_body): Use str_hash_insert 114047 (macro_expand_body): Use str_hash_find and str_hash_delete. 114048 (delete_macro): Likewise. 114049 (sub_actual, macro_expand, check_macro): Use str_hash_find. 114050 (expand_irp): Use str_htab_create and str_hash_insert. 114051 * macro.h (struct macro_struct): Tidy. 114052 (struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry), 114053 (eq_macro_entry, macro_entry_alloc, macro_entry_find), 114054 (struct formal_hash_entry, formal_hash_entry_t), 114055 (hash_formal_entry, eq_formal_entry, formal_entry_alloc), 114056 (formal_entry_find): Delete. 114057 * config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create 114058 and str_hash_insert. 114059 1140602022-07-09 Alan Modra <amodra@gmail.com> 114061 114062 read.c: use string hash from hash.h for po_hash 114063 po_hash code duplicates the str_hash code in hash.h for no good reason. 114064 114065 * read.c (struct po_entry, po_entry_t): Delete. 114066 (hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete. 114067 (pop_insert): Use str_hash_insert. 114068 (pobegin): Use str_htab_create. 114069 (read_a_source_file, s_macro): Use str_hash_find. 114070 1140712022-07-09 Alan Modra <amodra@gmail.com> 114072 114073 free read_symbol_name string 114074 read_symbol_name mallocs the string it returns. Free it when done. 114075 114076 * read.c (read_symbol_name): Free name on error path. 114077 * config/tc-ppc.c (ppc_GNU_visibility): Free name returned from 114078 read_symbol_name. 114079 (ppc_extern, ppc_globl, ppc_weak): Likewise. 114080 1140812022-07-09 Alan Modra <amodra@gmail.com> 114082 114083 gas: output_file_close 114084 This is mostly a tidy with the aim of being able to free 114085 out_file_name, but it does fix a possible attempt to unlink the output 114086 file twice (not that that matters). 114087 114088 * as.h (keep_it): New global. 114089 * as.c (keep_it): Delete. 114090 (close_output_file): Delete, merged into.. 114091 * output-file.c (output_file_close): ..here. Delete parameter. 114092 * output-file.h (output_file_close): Update prototype. 114093 1140942022-07-09 Alan Modra <amodra@gmail.com> 114095 114096 gas: utility notes memory alloc functions 114097 Makes it a little easier to use the notes obstack for persistent 114098 storage. 114099 114100 * as.h (gas_mul_overflow): Define. 114101 * symbols.h (notes_alloc, notes_calloc, notes_memdup), 114102 (notes_strdup, notes_concat, notes_free): Declare. 114103 * symbols.c (notes_alloc, notes_calloc, notes_memdup), 114104 (notes_strdup, notes_concat, notes_free): New functions. 114105 (save_symbol_name): Use notes_strdup. 114106 (symbol_create, local_symbol_make, local_symbol_convert), 114107 (symbol_clone, decode_local_label_name): Use notes_alloc. 114108 1141092022-07-09 Alan Modra <amodra@gmail.com> 114110 114111 gas: arm -mwarn-syms duplicates 114112 arm gas is only supposed to warn once per symbol for -mwarn-syms, but 114113 doesn't because the str_hash_find added with commit 629310abec88 114114 always returns NULL. That's so because the str_hash_insert inserts a 114115 NULL value for the key,value pair. Let str_hash_insert do the job 114116 instead. 114117 114118 * config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned 114119 logic. 114120 * testsuite/gas/arm/pr18347.s: Modify to generate duplicate 114121 warning without this patch. 114122 1141232022-07-09 Alan Modra <amodra@gmail.com> 114124 114125 Regenerate with automake-1.15.1 114126 Until we update the recommended versions of autoconf/automake, files 114127 should be regenerated with automake-1.15.1 and autoconf-2.69. That's 114128 not because we think those versions are golden, and newer versions are 114129 bad. It's simply because maintainers want to be able to update 114130 configury files without trouble, and if someone regenerates files with 114131 automake-1.16.5 then --enable-maintainer-mode builds will hit errors: 114132 114133 checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1, 114134 configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE 114135 configure.ac:26: comes from Automake 1.16.5. You should recreate 114136 configure.ac:26: aclocal.m4 with aclocal and run automake again. 114137 WARNING: 'automake-1.15' is probably too old. 114138 114139 Correcting this requires regenerating the files by hand. 114140 1141412022-07-09 GDB Administrator <gdbadmin@sourceware.org> 114142 114143 Automatic date update in version.in 114144 1141452022-07-08 Tom Tromey <tom@tromey.com> 114146 114147 Accept gdb.Value in more Python APIs 114148 PR python/27000 points out that gdb.block_for_pc will accept a Python 114149 integer, but not a gdb.Value. This patch corrects this oversight. 114150 114151 I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use 114152 get_addr_from_python instead. I also looked at uses of GDB_PY_LL_ARG, 114153 but those seemed relatively unlikely to be useful with a gdb.Value, so 114154 I didn't change them. My thinking here is that a Value will typically 114155 come from inferior memory, and something like a line number is not too 114156 likely to be found this way. 114157 114158 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000 114159 1141602022-07-08 Tom Tromey <tom@tromey.com> 114161 114162 Handle bool specially in gdb.set_parameter 114163 PR python/29217 points out that gdb.parameter will return bool values, 114164 but gdb.set_parameter will not properly accept them. This patch fixes 114165 the problem by adding a special case to set_parameter. 114166 114167 I looked at a fix involving rewriting set_parameter in C++. However, 114168 this one is simpler. 114169 114170 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217 114171 1141722022-07-08 Ludovic Courtès <ludo@gnu.org> 114173 114174 [gdb/build] Handle deprecation of scm_install_gmp_memory_functions 114175 When building gdb with guile 3.0.8, we run into: 114176 ... 114177 gdb/guile/guile.c: In function \ 114178 'void gdbscm_initialize(const extension_language_defn*)': 114179 gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \ 114180 deprecated [-Werror=deprecated-declarations] 114181 680 | scm_install_gmp_memory_functions = 0; 114182 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 114183 In file included from /usr/include/guile/3.0/libguile.h:128, 114184 from gdb/guile/guile-internal.h:30, 114185 from gdb/guile/guile.c:36: 114186 /usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here 114187 164 | SCM_DEPRECATED int scm_install_gmp_memory_functions; 114188 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 114189 cc1plus: all warnings being treated as errors 114190 make[1]: *** [Makefile:1896: guile/guile.o] Error 1 114191 ... 114192 114193 The variable has been deprecated because it no longer has any effect. 114194 114195 Fix this by disabling the specific deprecation warning. 114196 114197 Also handle upcoming guile versions > 3.0, in which the variable will be 114198 removed, by limiting the usage of the variable to guile versions <= 3.0. 114199 114200 This does not break anything. The variable was merely used to address a 114201 problem present in guile versions <= v3.0.5. 114202 114203 Note that we don't limit the usage of the variable to guile versions <= 3.0.5, 114204 because we want to support f.i. building against 3.0.6 and then using a shared 114205 lib with 3.0.5. 114206 114207 Tested on x86_64-linux. 114208 114209 Co-Authored-By: Tom de Vries <tdevries@suse.de> 114210 114211 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994 114212 1142132022-07-08 Tom de Vries <tdevries@suse.de> 114214 114215 [gdb/symtab] Fix assert in process_imported_unit_die 114216 When running test-case gdb.dwarf2/dw2-symtab-includes.exp with target board 114217 cc-with-debug-names, I run into: 114218 ... 114219 (gdb) maint expand-symtab dw2-symtab-includes.h^M 114220 src/gdb/dwarf2/read.h:311: internal-error: unit_type: \ 114221 Assertion `m_unit_type != 0' failed.^M 114222 A problem internal to GDB has been detected,^M 114223 further debugging may prove unreliable.^M 114224 ----- Backtrace -----^M 114225 FAIL: gdb.dwarf2/dw2-symtab-includes.exp: maint expand-symtab \ 114226 dw2-symtab-includes.h (GDB internal error) 114227 ... 114228 114229 The assert was recently added in commit 2c474c46943 ("[gdb/symtab] Add get/set 114230 functions for per_cu->lang/unit_type"). 114231 114232 The assert is triggered here: 114233 ... 114234 /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit 114235 into another compilation unit, at root level. Regard this as a hint, 114236 and ignore it. */ 114237 if (die->parent && die->parent->parent == NULL 114238 && per_cu->unit_type () == DW_UT_compile 114239 && per_cu->lang () == language_cplus) 114240 return; 114241 ... 114242 114243 We're trying to access unit_type / lang which hasn't been set yet. 114244 114245 Normally, these are set during cooked index creation, but that's not the case 114246 when using an index (or using -readnow). 114247 114248 In other words, this lto binary reading speed optimization only works in the 114249 normal use case. 114250 114251 IWBN to have this working in all use cases, but for now, allow lang () and 114252 unit_type () to return language_unknown and 0 here. 114253 114254 Tested on x86_64-linux. 114255 114256 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29321 114257 1142582022-07-08 Tom de Vries <tdevries@suse.de> 114259 114260 [gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p 114261 When running test-case gdb.cp/cpexprs-debug-types.exp with target board 114262 cc-with-debug-names, I run into: 114263 ... 114264 (gdb) print base::operator new^M 114265 ^M 114266 ^M 114267 Fatal signal: Segmentation fault^M 114268 ----- Backtrace -----^M 114269 0x57ea46 gdb_internal_backtrace_1^M 114270 /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M 114271 0x57eae9 _Z22gdb_internal_backtracev^M 114272 /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M 114273 0x75b8ad handle_fatal_signal^M 114274 /home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M 114275 0x75ba19 handle_sigsegv^M 114276 /home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M 114277 0x7f795f46a8bf ???^M 114278 0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M 114279 /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M 114280 ... 114281 114282 The problem is in this piece of code in dw2_debug_names_iterator::next: 114283 ... 114284 case DW_IDX_type_unit: 114285 /* Don't crash on bad data. */ 114286 if (ull >= per_bfd->tu_stats.nr_tus) 114287 { 114288 complaint (_(".debug_names entry has bad TU index %s" 114289 " [in module %s]"), 114290 pulongest (ull), 114291 objfile_name (objfile)); 114292 continue; 114293 } 114294 per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus); 114295 break; 114296 ... 114297 114298 The all_comp_units vector (which get_cu accesses) contains both CUs and TUs, 114299 with CUs first. 114300 114301 So to get the nth TU we need the element at "nr_cus + n", but 114302 the code uses "nr_tus + n" instead. 114303 114304 Fix this by using "nr_cus + n". 114305 114306 Tested on x86_64-linux. 114307 114308 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29334 114309 1143102022-07-08 Enze Li <enze.li@hotmail.com> 114311 114312 gdb: initialize the data_head variable to eliminate compilation warnings 114313 On a machine with gcc 12, I get this warning: 114314 114315 CXX nat/linux-btrace.o 114316 In function ‘btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’, 114317 inlined from ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29: 114318 ../gdb/nat/linux-btrace.c:865:21: warning: ‘data_head’ may be used uninitialized [-Wmaybe-uninitialized] 114319 865 | pevent->last_head = data_head; 114320 | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ 114321 ../gdb/nat/linux-btrace.c: In function ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’: 114322 ../gdb/nat/linux-btrace.c:792:9: note: ‘data_head’ was declared here 114323 792 | __u64 data_head, data_tail; 114324 | ^~~~~~~~~ 114325 114326 Fix this by initializing the 'data_head' variable. 114327 114328 Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12. 114329 1143302022-07-08 Andrew Burgess <aburgess@redhat.com> 114331 114332 libopcodes/s390: add support for disassembler styling 114333 This commit adds disassembler style to the libopcodes s390 114334 disassembler. This conversion was pretty straight forward, I just 114335 converted the fprintf_func calls to fprintf_styled_func calls and 114336 added an appropriate style. 114337 114338 For testing the new styling I just assembled then disassembled the 114339 source files in gas/testsuite/gas/s390 and manually checked that the 114340 styling looked reasonable. 114341 114342 If the user does not request styled output from objdump, then there 114343 should be no change in the disassembler output after this commit. 114344 1143452022-07-08 Nick Clifton <nickc@redhat.com> 114346 114347 Fix regeneration of ld configure and makefiles 114348 114349 Update release README with new version numbers 114350 114351 Update version to 2.39.50 and regenerate files 114352 114353 Add markers for 2.39 branch 114354 1143552022-07-08 GDB Administrator <gdbadmin@sourceware.org> 114356 114357 Automatic date update in version.in 114358 1143592022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 114360 114361 gprofng: fix regression in testing for not yet installed version 114362 gprofng/ChangeLog 114363 2022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 114364 114365 * src/Settings.cc (Settings::read_rc): Read environment variable 114366 GPROFNG_SYSCONFDIR. 114367 * testsuite/lib/Makefile.skel: Export GPROFNG_SYSCONFDIR. 114368 * testsuite/gprofng.display/display.exp: Shorten the list of tests. 114369 1143702022-07-07 Simon Marchi <simon.marchi@efficios.com> 114371 114372 gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid 114373 Trying to run a simple program (empty main) on AIX, I get: 114374 114375 (gdb) run 114376 Starting program: /scratch/simark/build/gdb/a.out 114377 Child process unexpectedly missing: There are no child processes.. 114378 ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed. 114379 A problem internal to GDB has been detected, 114380 further debugging may prove unreliable. 114381 ----- Backtrace ----- 114382 0x10ef12a8 gdb_internal_backtrace_1() 114383 ../../src/binutils-gdb/gdb/bt-utils.c:122 114384 0x10ef1470 gdb_internal_backtrace() 114385 ../../src/binutils-gdb/gdb/bt-utils.c:168 114386 0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*) 114387 ../../src/binutils-gdb/gdb/utils.c:396 114388 0x1004d8a8 internal_verror(char const*, int, char const*, char*) 114389 ../../src/binutils-gdb/gdb/utils.c:476 114390 0x1004c424 internal_error(char const*, int, char const*, ...) 114391 ../../src/binutils-gdb/gdbsupport/errors.cc:55 114392 0x102ab344 find_inferior_pid(process_stratum_target*, int) 114393 ../../src/binutils-gdb/gdb/inferior.c:304 114394 0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t) 114395 ../../src/binutils-gdb/gdb/inferior.c:318 114396 0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t) 114397 ../../src/binutils-gdb/gdb/thread.c:519 114398 0x10319e98 handle_inferior_event(execution_control_state*) 114399 ../../src/binutils-gdb/gdb/infrun.c:5532 114400 0x10315544 fetch_inferior_event() 114401 ../../src/binutils-gdb/gdb/infrun.c:4221 114402 0x10952e34 inferior_event_handler(inferior_event_type) 114403 ../../src/binutils-gdb/gdb/inf-loop.c:41 114404 0x1032640c infrun_async_inferior_event_handler(void*) 114405 ../../src/binutils-gdb/gdb/infrun.c:9548 114406 0x10673188 check_async_event_handlers() 114407 ../../src/binutils-gdb/gdb/async-event.c:335 114408 0x1066fce4 gdb_do_one_event() 114409 ../../src/binutils-gdb/gdbsupport/event-loop.cc:214 114410 0x10001a94 start_event_loop() 114411 ../../src/binutils-gdb/gdb/main.c:411 114412 0x10001ca0 captured_command_loop() 114413 ../../src/binutils-gdb/gdb/main.c:471 114414 0x10003d74 captured_main(void*) 114415 ../../src/binutils-gdb/gdb/main.c:1329 114416 0x10003e48 gdb_main(captured_main_args*) 114417 ../../src/binutils-gdb/gdb/main.c:1344 114418 0x10000744 main 114419 ../../src/binutils-gdb/gdb/gdb.c:32 114420 --------------------- 114421 ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed. 114422 A problem internal to GDB has been detected, 114423 further debugging may prove unreliable. 114424 Quit this debugging session? (y or n) 114425 114426 This is due to some bit-rot in the AIX port, still relying on the entry 114427 value of inferior_ptid in the wait methods. 114428 114429 Problem #1 is in rs6000_nat_target::wait, here: 114430 114431 /* Ignore terminated detached child processes. */ 114432 if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ()) 114433 pid = -1; 114434 114435 At this point, waitpid has returned an "exited" status for some pid, so 114436 pid is non-zero. Since inferior_ptid is set to null_ptid on entry, the 114437 pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset 114438 pid to -1 and go to waiting again. Since there are not more children to 114439 wait for, waitpid then returns -1 so we get here: 114440 114441 if (pid == -1) 114442 { 114443 gdb_printf (gdb_stderr, 114444 _("Child process unexpectedly missing: %s.\n"), 114445 safe_strerror (save_errno)); 114446 114447 /* Claim it exited with unknown signal. */ 114448 ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN); 114449 return inferior_ptid; 114450 } 114451 114452 We therefore return a "signalled" status with a null_ptid (again, 114453 inferior_ptid is null_ptid). This confuses infrun, because if the 114454 target returns a "signalled" status, it should be coupled with a ptid 114455 for an inferior that exists. 114456 114457 So, the first step is to fix the snippets above to not use 114458 inferior_ptid. In the first snippet, use find_inferior_pid to see if 114459 we know the event process. If there is no inferior with that pid, we 114460 assume it's a detached child process to we ignore the event. That 114461 should be enough to fix the problem, because it should make it so we 114462 won't go into the second snippet. But still, fix the second snippet to 114463 return an "ignore" status. This is copied from inf_ptrace_target::wait, 114464 which is where rs6000_nat_target::wait appears to be copied from in the 114465 first place. 114466 114467 These changes, are not sufficient, as the aix_thread_target, which sits 114468 on top of rs6000_nat_target, also relies on inferior_ptid. 114469 aix_thread_target::wait, by calling pd_update, assumes that 114470 rs6000_nat_target has set inferior_ptid to the appropriate value (the 114471 ptid of the event thread), but that's not the case. pd_update 114472 returns inferior_ptid - null_ptid - and therefore 114473 aix_thread_target::wait returns null_ptid too, and we still hit the 114474 assert shown above. 114475 114476 Fix this by changing pd_activate, pd_update, sync_threadlists and 114477 get_signaled_thread to all avoid using inferior_ptid. Instead, they 114478 accept as a parameter the pid of the process we are working on. 114479 114480 With this patch, I am able to run the program to completion: 114481 114482 (gdb) r 114483 Starting program: /scratch/simark/build/gdb/a.out 114484 [Inferior 1 (process 11010794) exited normally] 114485 114486 As well as break on main: 114487 114488 (gdb) b main 114489 Breakpoint 1 at 0x1000036c 114490 (gdb) r 114491 Starting program: /scratch/simark/build/gdb/a.out 114492 114493 Breakpoint 1, 0x1000036c in main () 114494 (gdb) c 114495 Continuing. 114496 [Inferior 1 (process 26083688) exited normally] 114497 114498 Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9 114499 1145002022-07-07 Pedro Alves <pedro@palves.net> 114501 114502 Fix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp 114503 The DWARF spec says: 114504 114505 Any debugging information entry representing the declaration of an object, 114506 module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and 114507 DW_AT_decl_column attributes, each of whose value is an unsigned integer 114508 ^^^^^^^^ 114509 constant. 114510 114511 Grepping around the DWARF-assembler-based testcases, I noticed that 114512 gdb.trace/unavailable-dwarf-piece.exp emits decl_line with 114513 DW_FORM_sdata, a signed integer form. This commit tweaks it to use 114514 DW_FORM_udata instead. 114515 114516 Unsurprisingly, this: 114517 114518 $ make check \ 114519 TESTS="gdb.trace/unavailable-dwarf-piece.exp" \ 114520 RUNTESTFLAGS="--target_board=native-gdbserver" 114521 114522 ... still passes cleanly for me after this change. 114523 114524 I've noticed this because current llvm-dwarfdump crashed on an 114525 ROCm-internal DWARF-assembler-based testcase that incorrectly used 114526 signed forms for DW_AT_decl_file/DW_AT_decl_line. 114527 114528 The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the 114529 line numbers with signed forms as "0" instead of crashing. Here's the 114530 before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that 114531 llvm-dwarfdump version: 114532 114533 $ diff -up before.txt after.txt 114534 --- before.txt 2022-07-07 13:21:28.387690334 +0100 114535 +++ after.txt 2022-07-07 13:21:39.379801092 +0100 114536 @@ -18,7 +18,7 @@ 114537 DW_AT_name ("s") 114538 DW_AT_byte_size (3) 114539 DW_AT_decl_file (0) 114540 - DW_AT_decl_line (0) 114541 + DW_AT_decl_line (1) 114542 114543 0x0000002f: DW_TAG_member 114544 DW_AT_name ("a") 114545 @@ -41,7 +41,7 @@ 114546 DW_AT_name ("t") 114547 DW_AT_byte_size (3) 114548 DW_AT_decl_file (0) 114549 - DW_AT_decl_line (0) 114550 + DW_AT_decl_line (1) 114551 114552 0x00000054: DW_TAG_member 114553 DW_AT_name ("a") 114554 114555 Change-Id: I5c866946356da421ff944019d0eca2607b2b738f 114556 1145572022-07-07 Tiezhu Yang <yangtiezhu@loongson.cn> 114558 114559 gdb: LoongArch: Fix typos in code comments 114560 "it’s" should be "it's". 114561 1145622022-07-07 Maciej W. Rozycki <macro@embecosm.com> 114563 114564 GDB/testsuite: Add coverage for `print -elements' command 114565 We currently have no coverage for the `print -elements ...' command (or 114566 `p -elements ...' in the shortened form), so add a couple of test cases 114567 mimicking ones using corresponding `set print elements ...' values. 114568 1145692022-07-07 Tiezhu Yang <yangtiezhu@loongson.cn> 114570 114571 gdb: LoongArch: Implement the push_dummy_call gdbarch method 114572 According to "Procedure Calling Convention" in "LoongArch ELF ABI 114573 specification" [1], implement the push_dummy_call gdbarch method 114574 as clear as possible. 114575 114576 [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention 114577 1145782022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com> 114579 114580 RISC-V: Added Zfhmin and Zhinxmin. 114581 This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and 114582 Zhinx extensions, respectively). In the process supporting Zfhmin and 114583 Zhinxmin extension, this commit also changes how instructions are 114584 categorized considering Zfhmin, Zhinx and Zhinxmin extensions. 114585 114586 Detailed changes, 114587 114588 * From INSN_CLASS_ZFH to INSN_CLASS_ZFHMIN: 114589 114590 flh, fsh, fmv.x.h and fmv.h.x. 114591 114592 * From INSN_CLASS_ZFH to INSN_CLASS_ZFH_OR_ZHINX: 114593 114594 fmv.h. 114595 114596 * From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFH_OR_ZHINX: 114597 114598 fneg.h, fabs.h, fsgnj.h, fsgnjn.h, fsgnjx.h, 114599 fadd.h, fsub.h, fmul.h, fdiv.h, fsqrt.h, fmin.h, fmax.h, 114600 fmadd.h, fnmadd.h, fmsub.h, fnmsub.h, 114601 fcvt.w.h, fcvt.wu.h, fcvt.h.w, fcvt.h.wu, 114602 fcvt.l.h, fcvt.lu.h, fcvt.h.l, fcvt.h.lu, 114603 feq.h, flt.h, fle.h, fgt.h, fge.h, 114604 fclass.h. 114605 114606 * From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFHMIN_OR_ZHINXMIN: 114607 114608 fcvt.s.h and fcvt.h.s. 114609 114610 * From INSN_CLASS_D_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_D: 114611 114612 fcvt.d.h and fcvt.h.d. 114613 114614 * From INSN_CLASS_Q_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_Q: 114615 114616 fcvt.q.h and fcvt.h.q. 114617 114618 bfd/ChangeLog: 114619 114620 * elfxx-riscv.c (riscv_implicit_subsets): Change implicit 114621 subsets. Zfh->Zicsr is not needed and Zfh->F is replaced with 114622 Zfh->Zfhmin and Zfhmin->F. Zhinx->Zicsr is not needed and 114623 Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and 114624 Zhinxmin->Zfinx. 114625 (riscv_supported_std_z_ext): Added zfhmin and zhinxmin. 114626 (riscv_multi_subset_supports): Rewrite handling for new 114627 instruction classes. 114628 (riscv_multi_subset_supports_ext): Updated. 114629 (riscv_parse_check_conflicts): Change error message to include 114630 zfh and zfhmin extensions. 114631 114632 gas/ChangeLog: 114633 114634 * testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex 114635 error handling test. 114636 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise. 114637 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise. 114638 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise. 114639 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise. 114640 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise. 114641 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise. 114642 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise. 114643 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise. 114644 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise. 114645 * testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise. 114646 * testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d 114647 and refactored. 114648 * testsuite/gas/riscv/zhinx.s: Likewise. 114649 114650 include/ChangeLog: 114651 114652 * opcode/riscv.h (enum riscv_insn_class): Removed INSN_CLASS_ZFH, 114653 INSN_CLASS_D_AND_ZFH_INX and INSN_CLASS_Q_AND_ZFH_INX. Added 114654 INSN_CLASS_ZFHMIN, INSN_CLASS_ZFHMIN_OR_ZHINXMIN, 114655 INSN_CLASS_ZFHMIN_AND_D and INSN_CLASS_ZFHMIN_AND_Q. 114656 114657 opcodes/ChangeLog: 114658 114659 * riscv-opc.c (riscv_opcodes): Change instruction classes for 114660 Zfh and Zfhmin instructions. Fix `fcvt.h.lu' instruction 114661 (two operand variant) mask. 114662 1146632022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 114664 114665 gprofng: adjust GPROFNG_VARIANT 114666 GPROFNG_VARIANT depends on compiler options, not on $(host). 114667 114668 gprofng/ChangeLog 114669 2022-07-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 114670 114671 PR gprofng/29116 114672 * libcollector/configure.ac: Adjust GPROFNG_VARIANT. 114673 * libcollector/configure: Rebuild. 114674 1146752022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com> 114676 114677 RISC-V: Fix disassembling Zfinx with -M numeric 114678 This commit fixes floating point operand register names from ABI ones 114679 to dynamically set ones. 114680 114681 gas/ChangeLog: 114682 114683 * testsuite/gas/riscv/zfinx-dis-numeric.s: Test new behavior of 114684 Zfinx extension and -M numeric disassembler option. 114685 * testsuite/gas/riscv/zfinx-dis-numeric.d: Likewise. 114686 114687 opcodes/ChangeLog: 114688 114689 * riscv-dis.c (riscv_disassemble_insn): Use dynamically set GPR 114690 names to disassemble Zfinx instructions. 114691 1146922022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com> 114693 114694 RISC-V: Fix requirement handling on Zhinx+{D,Q} 114695 This commit fixes how instructions are masked on Zhinx+Z{d,q}inx. 114696 fcvt.h.d and fcvt.d.h require ((D&&Zfh)||(Zdinx&&Zhinx)) and 114697 fcvt.h.q and fcvt.q.h require ((Q&&Zfh)||(Zqinx&&Zhinx)). 114698 114699 bfd/ChangeLog: 114700 114701 * elfxx-riscv.c (riscv_multi_subset_supports): Fix feature gate 114702 on INSN_CLASS_{D,Q}_AND_ZFH_INX. 114703 (riscv_multi_subset_supports_ext): Fix feature gate diagnostics 114704 on INSN_CLASS_{D,Q}_AND_ZFH_INX. 114705 114706 gas/ChangeLog: 114707 114708 * testsuite/gas/riscv/fp-zhinx-insns.d: Add Zqinx to -march 114709 for proper testing. 114710 1147112022-07-07 Alan Modra <amodra@gmail.com> 114712 114713 PR29320, 'struct obstack' declared inside parameter list 114714 PR 29320 114715 * frags.h: Move declaration of struct obstack.. 114716 * as.h: ..to here. 114717 1147182022-07-07 GDB Administrator <gdbadmin@sourceware.org> 114719 114720 Automatic date update in version.in 114721 1147222022-07-06 Ruud van der Pas <ruud.vanderpas@oracle.com> 114723 114724 gprofng: implement a functional gp-display-html 114725 This patch enables the first support for the "gprofng display html" command. 114726 This command works for C/C++ applications on x86_64. Using one or more gprofng 114727 experiment directories as input, a new directory with html files is created. 114728 Through the index.html file in this directory, the performance results may be 114729 viewed in a browser. 114730 114731 gprofng/Changelog: 114732 2022-06-28 Ruud van der Pas <ruud.vanderpas@oracle.com> 114733 114734 * gp-display-html/gp-display-html.in: implement first support for x86_64 and C/C++ 114735 1147362022-07-06 H.J. Lu <hjl.tools@gmail.com> 114737 114738 elf: Copy p_align of PT_GNU_STACK for stack alignment 114739 commit 74e315dbfe5200c473b226e937935fb8ce391489 114740 Author: H.J. Lu <hjl.tools@gmail.com> 114741 Date: Mon Dec 13 19:46:04 2021 -0800 114742 114743 elf: Set p_align to the minimum page size if possible 114744 114745 may ignore p_align of PT_GNU_STACK when copying ELF program header if 114746 the maximum page size is larger than p_align of PT_LOAD segments. Copy 114747 p_align of PT_GNU_STACK since p_align of PT_GNU_STACK describes stack 114748 alignment, not page size, 114749 114750 PR binutils/29319 114751 * elf.c (copy_elf_program_header): Copy p_align of PT_GNU_STACK 114752 for stack alignment. 114753 1147542022-07-06 Jan Beulich <jbeulich@suse.com> 114755 114756 x86: make D attribute usable for XOP and FMA4 insns 114757 This once again allows to reduce redundancy in (and size of) the opcode 114758 table. 114759 114760 Don't go as far as also making D work on the two 5-operand XOP insns: 114761 This would significantly complicate the code, as there the first 114762 (immediate) operand would need special treatment in several places. 114763 114764 Note that the .s suffix isn't being enabled to have any effect, for 114765 being deprecated. Whereas neither {load} nor {store} pseudo prefixes 114766 make sense here, as the respective operands are inputs (loads) only 114767 anyway, regardless of order. Hence there is (as before) no way for the 114768 programmer to request the alternative encoding to be used for register- 114769 only insns. 114770 114771 Note further that it is always the first original template which is 114772 retained (and altered), to make sure the same encoding as before is 114773 used for register-only insns. This has the slightly odd (but pre- 114774 existing) effect of XOP register-only insns having XOP.W clear, but FMA4 114775 ones having VEX.W set. 114776 1147772022-07-06 Jan Beulich <jbeulich@suse.com> 114778 114779 x86: fold two switch() statements in match_template() 114780 I don't see why two of them were introduced (very long ago) using 114781 similar fall-through logic. 114782 1147832022-07-06 Jan Beulich <jbeulich@suse.com> 114784 114785 x86: fix 3-operand insn reverse-matching 114786 The middle operand would have gone entirely unchecked, allowing e.g. 114787 114788 vmovss %xmm0, %esp, %xmm2 114789 114790 to assemble successfully, or e.g. 114791 114792 vmovss %xmm0, $4, %xmm2 114793 114794 causing an internal error. Alongside dealing with this also drop a 114795 related comment, which hasn't been applicable anymore since the 114796 introduction of 3-operand patterns with D set (and which perhaps never 114797 had been logical to be there, as reverse-matched insns don't make it 114798 there in the first place). 114799 1148002022-07-06 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 114801 114802 Descriptive DWARF operations dump support for DW_AT_rank 114803 DW_AT_rank is a dwarf-5 feature. 114804 1148052022-07-06 Jan Beulich <jbeulich@suse.com> 114806 114807 x86: introduce a state stack for .arch 114808 When using just slightly non-trivial combinations of .arch, it can be 114809 quite useful to be able to go back to prior state without needing to 114810 re-invoke perhaps many earlier directives and without needing to invoke 114811 perhaps many "negative" ones. Like some other architectures allow 114812 saving (pushing) and restoring (popping) present/prior state. 114813 114814 For now require the same .code<N> to be in effect for ".arch pop" that 114815 was in effect for the corresponding ".arch push". 114816 114817 Also change the global "no_cond_jump_promotion" to be bool, to match the 114818 new struct field. 114819 1148202022-07-06 Jan Beulich <jbeulich@suse.com> 114821 114822 x86: generalize disabling of sub-architectures 114823 I never really understood upon what basis ".arch .no*" options were made 114824 available. Let's not have any "criteria" at all, and simply allow 114825 disabling of all of them. Then we also have all data for a sub-arch in 114826 a single place, as we now only need a single table. 114827 1148282022-07-06 Jan Beulich <jbeulich@suse.com> 114829 114830 x86: permit "default" with .arch 114831 So far there was no way to reset the architecture to that assembly would 114832 start with in the absence of any overrides (command line or directives). 114833 Note that for Intel MCU "default" is merely an alias of "iamcu". 114834 114835 While there also zap a stray @item from the doc section, as noticed 114836 when inspecting the generated output (which still has some quirks, but 114837 those aren't easy to address without re-flowing almost the entire 114838 section). 114839 1148402022-07-06 Jan Beulich <jbeulich@suse.com> 114841 114842 x86: don't leak sub-architecture accumulated strings 114843 While it may not be necessary in i386_target_format() (but then setting 114844 the variable to NULL also wouldn't be necessary), at least in the other 114845 cases strings may already have accumulated. 114846 1148472022-07-06 GDB Administrator <gdbadmin@sourceware.org> 114848 114849 Automatic date update in version.in 114850 1148512022-07-05 Tom de Vries <tdevries@suse.de> 114852 114853 [gdb/exp] Fix internal error when printing C++ pointer-to-member 114854 When running the test-case included with this patch, we run into: 114855 ... 114856 (gdb) print ptm^M 114857 $1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \ 114858 Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M 114859 ... 114860 while printing a c++ pointer-to-member. 114861 114862 Fix this by skipping static fields in cp_find_class_member, such that we have: 114863 ... 114864 (gdb) print ptm^M 114865 $1 = &A::i^M 114866 ... 114867 114868 Tested on x86_64-linux. 114869 114870 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294 114871 1148722022-07-05 Tom Tromey <tromey@adacore.com> 114873 114874 Add gdb.Objfile.is_file attribute 114875 Sometimes an objfile comes from memory and not from a file. It can be 114876 useful to be able to check this from Python, so this patch adds a new 114877 "is_file" attribute. 114878 1148792022-07-05 Tom Tromey <tromey@adacore.com> 114880 114881 Make 'import gdb.events' work 114882 Pierre-Marie noticed that, while gdb.events is a Python module, it 114883 can't be imported. This patch changes how this module is created, so 114884 that it can be imported, while also ensuring that the module is always 114885 visible, just as it was in the past. 114886 114887 This new approach required one non-obvious change -- when running 114888 gdb.base/warning.exp, where --data-directory is intentionally not 114889 found, the event registries can now be nullptr. Consequently, this 114890 patch probably also requires 114891 114892 https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html 114893 114894 Note that this patch obsoletes 114895 114896 https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html 114897 1148982022-07-05 Xi Ruoyao <xry111@xry111.site> 114899 114900 gdb: LoongArch: add orig_a0 into register set 114901 The basic support for LoongArch has been merged into the upstream Linux 114902 kernel since 5.19-rc1 on June 5, 2022. This commit adds orig_a0 which 114903 is added into struct user_pt_regs [1] to match the upstream kernel, and 114904 then the upstream GDB will work with the upstream kernel. 114905 114906 Note that orig_a0 was added into struct user_pt_regs in the development 114907 cycle for merging LoongArch port into the upstream Linux kernel, so 114908 earlier kernels (notably, the product kernel with version 4.19 used in 114909 distros like UOS and Loongnix) don't have it. Inspect 114910 arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure. 114911 To build upstream GDB for a kernel lacking orig_a0, it's necessary to 114912 revert this commit locally. 114913 114914 [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24 114915 1149162022-07-05 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 114917 114918 Support for location and range lists for split-dwarf and dwarf-5. 114919 Adding support for location and range lists for split-dwarf and dwarf-5. 114920 Following issues are taken care. 114921 1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx. 114922 2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections. 114923 114924 * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx 114925 and DW_FORM_rnglistx for .dwo files. 114926 (process_debug_info): Load .debug_loclists.dwo and 114927 .debug_rnglists.dwo if exists. 114928 (load_separate_debug_files): Load .debug_loclists and 114929 .debug_rnglists if exists. 114930 Include 2 entries in debug_displays table. 114931 * dwarf.h (enum dwarf_section_display_enum): Include 2 entries. 114932 1149332022-07-05 Jan Beulich <jbeulich@suse.com> 114934 114935 x86: introduce fake processor type to mark sub-arch entries in cpu_arch[] 114936 This is in preparation of dropping the leading . from the strings. 114937 114938 While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD 114939 entries to near the top. 114940 1149412022-07-05 Jan Beulich <jbeulich@suse.com> 114942 114943 x86: macro-ize cpu_arch[] entries 114944 Putting individual elements behind macros, besides (imo) improving 114945 readability, will make subsequent (and likely also future) changes less 114946 intrusive. 114947 114948 Utilize this right away to pack the table a little more tightly, by 114949 converting "skip" to bool and putting it earlier in a group of bitfields 114950 together with "len". 114951 1149522022-07-05 Jan Beulich <jbeulich@suse.com> 114953 114954 x86: de-duplicate sub-architecture strings accumulation 114955 Introduce a helper function to replace 4 instances of similar code. Use 114956 reconcat() to cover the previously explicit free(). 114957 1149582022-07-05 GDB Administrator <gdbadmin@sourceware.org> 114959 114960 Automatic date update in version.in 114961 1149622022-07-04 Nick Clifton <nickc@redhat.com> 114963 114964 Fix snafu in rust demangler recursion limit code 114965 1149662022-07-04 Alan Modra <amodra@gmail.com> 114967 114968 alloc gas seginfo on notes obstack 114969 Lots of memory used in gas should go on this obstack. The patch also 114970 frees all the gas obstacks on exit, which isn't a completely trivial 114971 task. 114972 114973 * subsegs.c (alloc_seginfo): New function. 114974 (subseg_change, subseg_get): Use it. 114975 (subsegs_end): New function. 114976 * as.h (subsegs_end): Declare. 114977 * output-file.c: Include subsegs.h 114978 (stash_frchain_obs): New function. 114979 (output_file_close): Save obstacks attached to output bfd before 114980 closing. Call subsegs_end with the array of obstacks. 114981 1149822022-07-04 Alan Modra <amodra@gmail.com> 114983 114984 objcopy: bfd_alloc orelocation 114985 This fixes an inconsequential objcopy memory leak. I'd normally 114986 ignore reports of leaks like this one, that are merely one block or 114987 fewer per section processed, since objcopy soon exits and frees all 114988 memory. However I thought it worth providing support for allocating 114989 memory on a bfd objalloc in objcopy and other utils. 114990 114991 PR 29233 114992 * bucomm.c (bfd_xalloc): New function. 114993 * bucomm.h (bfd_xalloc): Declare. 114994 * objcopy.c (copy_relocations_in_section): Use it to allocate 114995 array of reloc pointers. Rewrite code stripping relocs to do 114996 without extra memory allocation. 114997 1149982022-07-04 Nick Clifton <nickc@redhat.com> 114999 115000 Synchronize libbierty sources with gcc. 115001 1150022022-07-04 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 115003 115004 Modified changes for split-dwarf and dwarf-5. 115005 * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit. 115006 (display_debug_str_offsets): While dumping .debug_str_offsets.dwo, 115007 pass proper str_offsets_base to fetch_indexed_string(). 115008 (load_separate_debug_files): Skip DWO ID dump for dwarf-5. 115009 1150102022-07-04 Marcus Nilsson <brainbomb@gmail.com> 115011 115012 opcodes/avr: Implement style support in the disassembler 115013 * disassemble.c: (disassemble_init_for_target): Set 115014 created_styled_output for AVR based targets. 115015 * avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype 115016 instead of fprintf_ftype throughout. 115017 (avr_operand): Pass in and fill disassembler_style when 115018 parsing operands. 115019 1150202022-07-04 Tom de Vries <tdevries@suse.de> 115021 115022 [gdb/symtab] Add get/set functions for per_cu->lang/unit_type 115023 The dwarf2_per_cu_data fields lang and unit_type both have a dont-know 115024 initial value (respectively language_unknown and (dwarf_unit_type)0), which 115025 allows us to add certain checks, f.i. checking that that a field is not read 115026 before written. 115027 115028 Add get/set member functions for the two fields as a convenient location to 115029 add such checks, make the fields private to enforce using the member 115030 functions, and add the m_ prefix. 115031 115032 Tested on x86_64-linux. 115033 1150342022-07-04 Jan Beulich <jbeulich@suse.com> 115035 115036 gas/testsuite: properly exclude aout in all/weakref1u 115037 Use the (wider) predicate rather than a triplet. This eliminates the sole 115038 i386-msdos failure in the testsuite. 115039 1150402022-07-04 Jan Beulich <jbeulich@suse.com> 115041 115042 x86: fold Disp32S and Disp32 115043 The only case where 64-bit code uses non-sign-extended (can also be 115044 considered zero-extended) displacements is when an address size override 115045 is in place for a memory operand (i.e. particularly excluding 115046 displacements of direct branches, which - if at all - are controlled by 115047 operand size, and then are still sign-extended, just from 16 bits). 115048 Hence the distinction in templates is unnecessary, allowing code to be 115049 simplified in a number of places. The only place where logic becomes 115050 more complicated is when signed-ness of relocations is determined in 115051 output_disp(). 115052 115053 The other caveat is that Disp64 cannot be specified anymore in an insn 115054 template at the same time as Disp32. Unlike for non-64-bit mode, 115055 templates don't specify displacements for both possible addressing 115056 modes; the necessary adjustment to the expected ones has already been 115057 done in match_template() anyway (but of course the logic there needs 115058 tweaking now). Hence the single template so far doing so is split. 115059 1150602022-07-04 Jan Beulich <jbeulich@suse.com> 115061 115062 x86: restore masking of displacement kinds 115063 Commit 7d5e4556a375 rendered the check near the end of what is now 115064 i386_finalize_displacement() entirely dead for AT&T mode, since for 115065 operands involving a displacement .unspecified will always be set. But 115066 the logic there is bogus anyway - Intel syntax operand size specifiers 115067 are of no interest there either. The only thing which matters in the 115068 "displacement only" determination is .baseindex. 115069 115070 Of course when masking displacement kinds we should not at the same time 115071 also mask off other attributes. 115072 115073 Furthermore the type mask returned by lex_got() also needs to be 115074 adjusted: The only case where we want Disp32 (rather than Disp32S) is 115075 when dealing with 32-bit addressing mode in 64-bit code. 115076 1150772022-07-04 Jan Beulich <jbeulich@suse.com> 115078 115079 x86-64: improve handling of branches to absolute addresses 115080 There are two related problems here: The use of "addr32" on a direct 115081 branch would, besides causing a warning, result in operands to be 115082 permitted which mistakenly are refused without "addr32". Plus at some 115083 point not too long ago I'm afraid it may have been me who regressed the 115084 relocation addends emitted for such branches. Correct both problems, 115085 adding a testcase to guard against regressing this again. 115086 1150872022-07-04 Tsukasa OI <research_trasio@irq.a4lg.com> 115088 115089 RISC-V: Update Zihintpause extension version 115090 Because ratified Zihintpause extension has a version number of 2.0 115091 (not 1.0), we should update the number. 115092 115093 bfd/ChangeLog: 115094 115095 * elfxx-riscv.c (riscv_supported_std_z_ext): Update version 115096 number of Zihintpause extension. 115097 1150982022-07-04 GDB Administrator <gdbadmin@sourceware.org> 115099 115100 Automatic date update in version.in 115101 1151022022-07-03 GDB Administrator <gdbadmin@sourceware.org> 115103 115104 Automatic date update in version.in 115105 1151062022-07-02 Tom de Vries <tdevries@suse.de> 115107 115108 [gdb/symtab] Fix data race on per_cu->dwarf_version 115109 When building gdb with -fsanitize=thread and gcc 12, and running test-case 115110 gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main 115111 thread in the same write: 115112 ... 115113 Write of size 1 at 0x7b200000300c:^M 115114 #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ 115115 abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \ 115116 (gdb+0x82f3b3)^M 115117 ... 115118 which is here: 115119 ... 115120 this_cu->dwarf_version = cu->header.version; 115121 ... 115122 115123 Both writes are called from the parallel for in dwarf2_build_psymtabs_hard, 115124 this one directly: 115125 ... 115126 #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M 115127 #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M 115128 #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M 115129 ... 115130 and this via the PU import: 115131 ... 115132 #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \ 115133 sect_offset, bool, bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M 115134 #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \ 115135 abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M 115136 #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \ 115137 cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M 115138 #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \ 115139 (gdb+0x85e68a)^M 115140 #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M 115141 #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M 115142 #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M 115143 ... 115144 115145 Fix this by setting the field earlier, in read_comp_units_from_section. 115146 115147 The write in cutu_reader::cutu_reader() is still needed, in case 115148 read_comp_units_from_section is not used (run the test-case with say, target 115149 board cc-with-gdb-index). 115150 115151 Make the write conditional, such that it doesn't trigger if the field is 115152 already set by read_comp_units_from_section. Instead, verify that the 115153 field already has the value that we're trying to set it to. 115154 115155 Move this logic into into a member function set_version (in analogy to the 115156 already present member function version) to make sure it's used consistenly, 115157 and make the field private in order to enforce access through the member 115158 functions, and rename it to m_dwarf_version. 115159 115160 While we're at it, make sure that the version is set before read, to avoid 115161 say returning true for "per_cu.version () < 5" if "per_cu.version () == 0". 115162 115163 Tested on x86_64-linux. 115164 1151652022-07-02 Tom de Vries <tdevries@suse.de> 115166 115167 [gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread 115168 When building gdb with -fsanitize=thread, I run into: 115169 ... 115170 FAIL: gdb.base/early-init-file.exp: check startup version string has style \ 115171 version 115172 ... 115173 due to this: 115174 ... 115175 warning: Found custom handler for signal 7 (Bus error) preinstalled.^M 115176 warning: Found custom handler for signal 8 (Floating point exception) \ 115177 preinstalled.^M 115178 warning: Found custom handler for signal 11 (Segmentation fault) \ 115179 preinstalled.^M 115180 Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M 115181 won't be propagated to spawned programs.^M 115182 ... 115183 appearing before the "GNU gdb (GDB) $version" line. 115184 115185 This is similar to the problem fixed by commit f0bbba7886f 115186 ("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with 115187 AddressSanitizer"). 115188 115189 In that commit, the problem was fixed by starting gdb with -quiet, but using 115190 that would mean the "GNU gdb (GDB) $version" line that we're trying to check 115191 would disappear. 115192 115193 Fix this instead by updating the regexp to allow the message. 115194 115195 Tested on x86_64-linux. 115196 1151972022-07-02 GDB Administrator <gdbadmin@sourceware.org> 115198 115199 Automatic date update in version.in 115200 1152012022-07-01 Maciej W. Rozycki <macro@embecosm.com> 115202 115203 GDB/doc: Remove indentation from `print -elements' completion example 115204 Remove indentation from the text of the manual after the example here: 115205 115206 " Completion will in some cases guide you with a suggestion of what 115207 kind of argument an option expects. For example: 115208 115209 (gdb) print -elements <TAB><TAB> 115210 NUMBER unlimited 115211 115212 Here, the option expects a number (e.g., '100'), not literal 115213 'NUMBER'. Such metasyntactical arguments are always presented in 115214 uppercase." 115215 115216 as this is a continuation of the same paragraph. 115217 1152182022-07-01 Maciej W. Rozycki <macro@embecosm.com> 115219 115220 GDB/doc: Remove extraneous spaces from completion examples 115221 Completion results are usually different when the operation is applied 115222 to a word that is or is not followed by a space. In some cases they are 115223 equivalent, however a space would not be produced if completion was used 115224 earlier on in the word processed. 115225 115226 However in the manual we have completion examples given using a space 115227 that actually prevents the example from working. E.g.: 115228 115229 (gdb) info bre <TAB> 115230 115231 (nothing) and: 115232 115233 (gdb) info bre <TAB><TAB> 115234 Display all 200 possibilities? (y or n) 115235 115236 as it now goes on to propose the entire symbol table, while: 115237 115238 (gdb) info bre<TAB> 115239 (gdb) info breakpoints 115240 115241 does the right thing, but is not what is shown in the manual. 115242 115243 In other cases an extraneous space is used that does not correspond to 115244 the actual completion pattern shown, which gives an impression of 115245 sloppiness. 115246 115247 Remove extraneous spaces then from completion examples as appropriate. 115248 1152492022-07-01 Nick Clifton <nickc@redhat.com> 115250 115251 Add newline to the end of the rnglists displsy. 115252 1152532022-07-01 GDB Administrator <gdbadmin@sourceware.org> 115254 115255 Automatic date update in version.in 115256 1152572022-06-30 Maciej W. Rozycki <macro@embecosm.com> 115258 115259 GDB: Add `NUMBER' completion to `set' integer commands 115260 Fix a completion consistency issue with `set' commands accepting integer 115261 values and the special `unlimited' keyword: 115262 115263 (gdb) complete print -elements 115264 print -elements NUMBER 115265 print -elements unlimited 115266 (gdb) 115267 115268 vs: 115269 115270 (gdb) complete set print elements 115271 set print elements unlimited 115272 (gdb) 115273 115274 (there is a space entered at the end of both commands, not shown here) 115275 which also means if you strike <Tab> with `set print elements ' input, 115276 it will, annoyingly, complete to `set print elements unlimited' right 115277 away rather than showing a choice between `NUMBER' and `unlimited'. 115278 115279 Add `NUMBER' then as an available completion for such `set' commands: 115280 115281 (gdb) complete set print elements 115282 set print elements NUMBER 115283 set print elements unlimited 115284 (gdb) 115285 115286 Adjust the testsuite accordingly. Also document the feature in the 115287 Completion section of the manual in addition to the Command Options 115288 section already there. 115289 1152902022-06-30 Bruno Larsen <blarsen@redhat.com> 115291 115292 gdb/testsuite: Expand gdb.cp/mb-ctor.exp to test dynamic allocation 115293 When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp 115294 only tested objects allocated on the stack. This commit adds a couple of 115295 dynamic allocations and tests if GDB can stop in it as well. 115296 1152972022-06-30 Nick Clifton <nickc@redhat.com> 115298 115299 Fix implementation of readelf's -wE and -wN options, 115300 * dwarf.c (dwarf_select_sections_by_name): If the entry's value is 115301 zero then clear the corresponding variable. 115302 (dwarf_select_sections_by_letters): Likewise. 115303 * testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE 115304 debuginfod tests to fail. 115305 1153062022-06-30 Tom de Vries <tdevries@suse.de> 115307 115308 [gdb] Block SIGTERM in worker threads 115309 With gdb build with gcc-12 and -fsanitize=thread, and test-case 115310 gdb.base/gdb-sigterm.exp, I run into: 115311 ... 115312 WARNING: ThreadSanitizer: data race (pid=9722)^M 115313 Write of size 4 at 0x00000325bc68 by thread T1:^M 115314 #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M 115315 ... 115316 Previous read of size 4 at 0x00000325bc68 by main thread:^M 115317 [failed to restore the stack]^M 115318 ^M 115319 Location is global 'sync_quit_force_run' of size 4 at \ 115320 0x00000325bc68 (gdb+0x325bc68)^M 115321 ... 115322 SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \ 115323 handle_sigterm(int)^M 115324 ... 115325 and 3 more data races involving handle_sigterm and locations: 115326 - active_ext_lang 115327 - quit_flag 115328 - heap block of size 40 115329 (XNEW (async_signal_handler) in create_async_signal_handler) 115330 115331 This was reported in PR29297. 115332 115333 The testcase executes a "kill -TERM $gdb_pid", which generates a 115334 process-directed signal. 115335 115336 A process-directed signal can be delivered to any thread, and what we see 115337 here is the fallout of the signal being delivered to a worker thread rather 115338 than the main thread. 115339 115340 Fix this by blocking SIGTERM in the worker threads. 115341 115342 [ I have not been able to reproduce this after it occurred for the first time, 115343 so unfortunately I cannot confirm that the patch fixes the problem. ] 115344 115345 Tested on x86_64-linux, with and without -fsanitize=thread. 115346 115347 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297 115348 1153492022-06-30 Andrew Burgess <aburgess@redhat.com> 115350 115351 gdb/doc: fix column widths in MI compatibility table 115352 In passing I noticed that the column headings for the table of MI 115353 compatibility and breaking changes, were overlapping, at least when 115354 the PDF is generated on my machine. 115355 115356 I propose giving slightly more space to the two version number 115357 columns, this prevents the headers overlapping for me. 115358 1153592022-06-30 GDB Administrator <gdbadmin@sourceware.org> 115360 115361 Automatic date update in version.in 115362 1153632022-06-29 Pedro Alves <pedro@palves.net> 115364 115365 Fix GDBserver regression due to change to avoid reading shell registers 115366 Simon reported that the recent change to make GDB and GDBserver avoid 115367 reading shell registers caused a GDBserver regression, caught with 115368 ASan while running gdb.server/non-existing-program.exp: 115369 115370 $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program 115371 ================================================================= 115372 ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310 115373 WRITE of size 1 at 0x60f0000000e9 thread T0 115374 #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86 115375 #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120 115376 #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991 115377 #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941 115378 #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084 115379 #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2) 115380 #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd) 115381 115382 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0) 115383 freed by thread T0 here: 115384 #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160 115385 #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164 115386 #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454 115387 #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599 115388 #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205 115389 #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515 115390 #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111 115391 #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991 115392 #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941 115393 #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084 115394 #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2) 115395 115396 previously allocated by thread T0 here: 115397 #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99 115398 #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144 115399 #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425 115400 #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985 115401 #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941 115402 #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084 115403 #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2) 115404 115405 Above we see that in the non-existing-program case, the process gets 115406 deleted before the starting_up flag gets restored to false. 115407 115408 This happens because startup_inferior calls target_mourn_inferior 115409 before throwing an error, and in GDBserver, unlike in GDB, mourning 115410 deletes the process. 115411 115412 Fix this by not using a scoped_restore to manage the starting_up flag, 115413 since we should only clear it when startup_inferior doesn't throw. 115414 115415 Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c 115416 1154172022-06-29 Maciej W. Rozycki <macro@embecosm.com> 115418 115419 GDB/testsuite: Tighten `set print elements' error check 115420 Match the whole error message expected to be given rather than omitting 115421 the part about the "unlimited" keyword. There's no point in omitting 115422 the missing part first, and second with an upcoming change the part in 115423 parentheses will no longer be a fixed string, so doing a full match will 115424 ensure the algorithm correctly builds the message expected here. Also 115425 avoid any wildcard matches. 115426 1154272022-06-29 Maciej W. Rozycki <macro@embecosm.com> 115428 115429 GDB: Remove extraneous full stops from `set' command error messages 115430 With errors given for bad commands such as `set annotate' or `set width' 115431 we produce an extraneous full stop within parentheses: 115432 115433 (gdb) set annotate 115434 Argument required (integer to set it to.). 115435 (gdb) set width 115436 Argument required (integer to set it to, or "unlimited".). 115437 (gdb) 115438 115439 This is grammatically incorrect, so remove the full stop and adjust the 115440 testsuite accordingly. 115441 1154422022-06-29 Andrew Burgess <aburgess@redhat.com> 115443 115444 gdb/doc: improve description of --data-disassemble opcodes output 115445 Extend the description of the MI command --data-disassemble. 115446 Specifically, expand the description of the 'opcodes' field to explain 115447 how the bytes are formatted. 115448 1154492022-06-29 Yvan Roux <yvan.roux@foss.st.com> 115450 115451 gdb/arm: Only stack S16..S31 when FPU registers are secure 115452 The FPCCR.TS bit is used to identify if FPU registers are considered 115453 non-secure or secure. If they are secure, then callee saved registers 115454 (S16 to S31) are stacked on exception entry or otherwise skipped. 115455 1154562022-06-29 Andrew Burgess <aburgess@redhat.com> 115457 115458 opcodes/aarch64: split off creation of comment text in disassembler 115459 The function aarch64_print_operand (aarch64-opc.c) is responsible for 115460 converting an instruction operand into the textual representation of 115461 that operand. 115462 115463 In some cases, a comment is included in the operand representation, 115464 though this (currently) only happens for the last operand of the 115465 instruction. 115466 115467 In a future commit I would like to enable the new libopcodes styling 115468 for AArch64, this will allow objdump and GDB[1] to syntax highlight 115469 the disassembler output, however, having operands and comments 115470 combined in a single string like this makes such styling harder. 115471 115472 In this commit, I propose to extend aarch64_print_operand to take a 115473 second buffer. Any comments for the instruction are written into this 115474 extra buffer. The two callers of aarch64_print_operand are then 115475 updated to pass an extra buffer, and print any resulting comment. 115476 115477 In this commit no styling is added, that will come later. However, I 115478 have adjusted the output slightly. Before this commit some comments 115479 would be separated from the instruction operands with a tab character, 115480 while in other cases the comment was separated with two single spaces. 115481 115482 After this commit I use a single tab character in all cases. This 115483 means a few test cases needed updated. If people would prefer me to 115484 move everyone to use the two spaces, then just let me know. Or maybe 115485 there was a good reason why we used a mix of styles, I could probably 115486 figure out a way to maintain the old output exactly if that is 115487 critical. 115488 115489 Other than that, there should be no user visible changes after this 115490 commit. 115491 115492 [1] GDB patches have not been merged yet, but have been posted to the 115493 GDB mailing list: 115494 https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html 115495 1154962022-06-29 Carl Love <cel@us.ibm.com> 115497 Andrew Burgess <aburgess@redhat.com> 115498 115499 gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc 115500 When running the gdb.base/break-idempotent.exp test on ppc, I was 115501 seeing some test failures (or rather errors), that looked like this: 115502 115503 (gdb) watch local 115504 Hardware watchpoint 2: local 115505 115506 has_hw_wp_support: Hardware watchpoint detected 115507 ERROR: no fileid for gcc2-power8 115508 ERROR: Couldn't send delete breakpoints to GDB. 115509 ERROR OCCURED: can't read "gdb_spawn_id": no such variable 115510 while executing 115511 "expect { 115512 -i 1000 -timeout 100 115513 -re ".*A problem internal to GDB has been detected" { 115514 fail "$message (GDB internal error)" 115515 gdb_internal_erro..." 115516 ("uplevel" body line 1) 115517 invoked from within 115518 115519 What happens is that in break-idempotent.exp we basically do this: 115520 115521 if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} { 115522 continue 115523 } 115524 115525 # .... 115526 115527 if {![skip_hw_watchpoint_tests]} { 115528 test_break $always_inserted "watch" 115529 } 115530 115531 The problem with this is that skip_hw_watchpoint_tests, includes this: 115532 115533 if { [istarget "i?86-*-*"] 115534 || [istarget "x86_64-*-*"] 115535 || [istarget "ia64-*-*"] 115536 || [istarget "arm*-*-*"] 115537 || [istarget "aarch64*-*-*"] 115538 || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support]) 115539 || [istarget "s390*-*-*"] } { 115540 return 0 115541 } 115542 115543 For powerpc only we call has_hw_wp_support. This is a caching proc 115544 that runs a test within GDB to detect if we have hardware watchpoint 115545 support or not. 115546 115547 Unfortunately, to run this test we restart GDB, and when the test has 115548 completed, we exit GDB. This means that in break-idempotent.exp, when 115549 we call skip_hw_watchpoint_tests for the first time on powerpc, GDB 115550 will unexpectedly be exited. When we later call delete_breakpoints we 115551 see the errors I reported above. 115552 115553 The fix is to call skip_hw_watchpoint_tests early, before we start GDB 115554 as part of the break-idempotent.exp script, and store the result in a 115555 variable, we can then check this variable in the script as needed. 115556 115557 After this change break-idempotent.exp runs fine on powerpc. 115558 1155592022-06-29 Jan Beulich <jbeulich@suse.com> 115560 115561 x86: drop stray NoRex64 from XBEGIN 115562 Presumably this being there was a result of taking CALL as a reference 115563 when adding the RTM insns. But with No_qSuf the attribute has no effect. 115564 1155652022-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 115566 115567 gprofng: fix build when BUILD_MAN is false 115568 gprofng/ChangeLog 115569 2022-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 115570 115571 PR gprofng/29131 115572 * gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true. 115573 * src/Makefile.am: Likewise. 115574 * gp-display-html/Makefile.in: Rebuild. 115575 * src/Makefile.in: Rebuild. 115576 1155772022-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 115578 115579 gprofng: use $(sysconfdir) instead $(prefix)/etc 115580 gprofng/ChangeLog 115581 2022-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 115582 115583 PR gprofng/29191 115584 * src/Makefile.am: Use $(sysconfdir) instead $(prefix)/etc. 115585 * src/Settings.cc: Likewise. 115586 * src/Makefile.in: Rebuild. 115587 1155882022-06-29 Alan Modra <amodra@gmail.com> 115589 115590 Re: ld/x86: skip p_align-1 tests with unsuitable compiler 115591 commit d0e0f9c87a3e results "ERROR: i586-linux-cc does not exist" if 115592 cross-building an i586-linux target without a target compiler 115593 installed. 115594 115595 * testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New. 115596 Use it after first testing check_compiler_available. 115597 1155982022-06-29 GDB Administrator <gdbadmin@sourceware.org> 115599 115600 Automatic date update in version.in 115601 1156022022-06-28 Pedro Alves <pedro@palves.net> 115603 115604 gdb+gdbserver/Linux: avoid reading registers while going through shell 115605 For every stop, Linux GDB and GDBserver save the stopped thread's PC, 115606 in lwp->stop_pc. This is done in save_stop_reason, in both 115607 gdb/linux-nat.c and gdbserver/linux-low.cc. However, while we're 115608 going through the shell after "run", in startup_inferior, we shouldn't 115609 be reading registers, as we haven't yet determined the target's 115610 architecture -- the shell's architecture may not even be the same as 115611 the final inferior's. 115612 115613 In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has 115614 stopped for a breakpoint, and since when going through the shell, no 115615 breakpoint is going to hit, we could simply teach save_stop_reason to 115616 only record the stop pc when the thread stopped for a breakpoint. 115617 115618 However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases 115619 than breakpoint hits (e.g., it's used in tracepoints & the 115620 "while-stepping" feature). 115621 115622 So to avoid GDB vs GDBserver divergence, we apply the same approach to 115623 both implementations. 115624 115625 We set a flag in the inferior (process in GDBserver) whenever it is 115626 being nursed through the shell, and when that flag is set, 115627 save_stop_reason bails out early. While going through the shell, 115628 we'll only ever get process exits (normal or signalled), random 115629 signals, and exec events, so nothing is lost. 115630 115631 Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad 115632 1156332022-06-28 Tom de Vries <tdevries@suse.de> 115634 115635 [gdb/build] Fix gdb build with -fsanitize=thread and gcc 7 115636 When building gdb with system gcc 7.5.0, I run into: 115637 ... 115638 gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’: 115639 gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \ 115640 [-Werror=return-type] 115641 ... 115642 115643 This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect 115644 -Wreturn-type warning", which has been fixed in gcc-8. 115645 115646 Work around this by moving the default return outside the switch. 115647 115648 Tested on x86_64-linux. 115649 1156502022-06-28 Clément Chigot <chigot@adacore.com> 115651 115652 bfd: handle codepage when opening files on MinGW 115653 Even if MS docs say that CP_UTF8 should always be used on newer 115654 applications, forcing it might produce undefined filename if the 115655 encoding isn't UTF-8. 115656 MinGW seems to call ___lc_codepage_func() in order to retrieve the 115657 current thread codepage. 115658 115659 bfd/ChangeLog: 115660 115661 * bfdio.c (_bfd_real_fopen): Retrieve codepage with 115662 ___lc_codepage_func() on MinGW. 115663 1156642022-06-28 Clément Chigot <chigot@adacore.com> 115665 115666 windres: add quotes around preprocessor cmd if needed 115667 This patch ensures that the gcc binary called by windres is quoted if 115668 needed. Otherwise, errors can occur if the gcc is under a folder having 115669 a name containing a space (eg "Program Files"). 115670 115671 binutils/ 115672 * resrc.c (DEFAULT_PREPROCESSOR): Split into... 115673 (DEFAULT_PREPROCESSOR_CMD): that... 115674 (DEFAULT_PREPROCESSOR_ARGS): and that. 115675 (look_for_default): Add quotes around the command if needed. 115676 (read_rc_file): Adapt to new defines. 115677 1156782022-06-28 Nick Clifton <nickc@redhat.com> 115679 115680 Fix the display of the idnex values for DW_FORM_loclistx and DW_FORM_rnglistx. Correct the display of .debug.loclists sections. 115681 PR 29267 115682 * dwarf.c (display_debug_rnglists): New function, broken out of.. 115683 (display_debug_ranges): ... here. 115684 (read_and_display_attr_value): Correct calculation of index 115685 displayed for DW_FORM_loclistx and DW_FORM_rnglistx. 115686 * testsuite/binutils-all/x86-64/pr26808.dump: Update expected 115687 output. 115688 1156892022-06-28 Jan Beulich <jbeulich@suse.com> 115690 115691 ld/x86: skip p_align-1 tests with unsuitable compiler 115692 When the compiler doesn't properly arrange for foo's alignment, there's 115693 no point even trying these tests. Report the situation as a single 115694 "unsupported" test. 115695 1156962022-06-28 Alan Modra <amodra@gmail.com> 115697 115698 PowerPC64: align plt_branch stubs 115699 plt_branch stubs are similar to plt_call stubs in that they branch 115700 via bctr. Align them too. 115701 115702 bfd/ 115703 * elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for 115704 plt_call stubs. 115705 ld/ 115706 * testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes. 115707 * testsuite/ld-powerpc/notoc.d: Likewise. 115708 * testsuite/ld-powerpc/notoc.wf: Likewise. 115709 * testsuite/ld-powerpc/notoc3.d: Likewise. 115710 * testsuite/ld-powerpc/pr23937.d: Likewise. 115711 1157122022-06-28 Alan Modra <amodra@gmail.com> 115713 115714 PowerPC64: plt_stub_pad 115715 * elf64-ppc.c (plt_stub_pad): Simplify parameters and untangle 115716 from plt_stub_size. 115717 (ppc_size_one_stub): Call plt_stub_size before plt_stub_pad to 115718 provide size. Recalculate size if it might change. 115719 1157202022-06-28 Alan Modra <amodra@gmail.com> 115721 115722 PowerPC64: Tidy stub type changes 115723 It made sense before I started using separate fields for main type and 115724 sub type to add a difference in main type to the type (thus keeping 115725 sub type unchanged). Not so much now. 115726 115727 * elf64-ppc.c (ppc_merge_stub): Simplify stub type change. 115728 (ppc_size_one_stub): Likewise. 115729 1157302022-06-28 Jiangshuai Li <jiangshuai_li@c-sky.com> 115731 115732 gdb:csky add pseudo regs for float and vector regs 115733 In the existing CSKY architecture, there are at most 32 floating 115734 and 16 vector registers. Float registers's count can be configured 115735 as 16 or 32. In the future, the vector registers's count may be 115736 extended to 32. 115737 115738 The bit width of floating-point register is 64bits, and the bit 115739 width of vector register is 128bit. 115740 115741 Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower 115742 64 bits of the corresponding VRx. 115743 115744 Here, we will split each floating-point and vector register to 115745 32bits wide, add the corresponding pseudo registers, and finally 115746 use them for the dwarf registers. 115747 115748 There are 128 pseudo registers in total, s0~s127, including: 115749 1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on. 115750 Every two separated pseudo registers correspond to a float register. 115751 2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1, 115752 and so on. Every four pseudo registers corresponds to a vector register. 115753 115754 Therefore, in s64~s127, there are general registers that are not actually 115755 used. This part is to prepare for the expansion of vector registers to 32 115756 115757 Therefore, in s64~s127, half of the registers are actually unused. This 115758 part is to prepare for the expansion of the vector register to 32. 115759 1157602022-06-28 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi> 115761 115762 PR29293, elfnn-aarch64.c: def_protected member unintialized 115763 PR 29293 115764 * elfnn-aarch64.c (elfNN_aarch64_link_hash_newfunc): Init def_protected. 115765 1157662022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com> 115767 115768 RISC-V: Add 'Sstc' extension and its CSRs 115769 This commit adds "stimecmp / vstimecmp" Extension (Sstc) and its CSRs. 115770 115771 bfd/ChangeLog: 115772 115773 * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sstc' 115774 extension to valid 'S' extension list. 115775 115776 gas/ChangeLog: 115777 115778 * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for 115779 'Sstc' extension. (riscv_csr_address): Add handling for new CSR 115780 classes. 115781 * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. 115782 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 115783 * testsuite/gas/riscv/csr.s: Add new CSRs. 115784 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 115785 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 115786 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 115787 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 115788 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 115789 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 115790 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 115791 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 115792 115793 include/ChangeLog: 115794 115795 * opcode/riscv-opc.h (CSR_STIMECMP, CSR_STIMECMPH, 115796 CSR_VSTIMECMP, CSR_VSTIMECMPH): New CSR macros. 115797 1157982022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com> 115799 115800 RISC-V: Add 'Sscofpmf' extension with its CSRs 115801 This commit adds Count Overflow and Mode-Based Filtering Extension 115802 (Sscofpmf) and its CSRs. 115803 115804 bfd/ChangeLog: 115805 115806 * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sscofpmf' 115807 extension to valid 'S' extension list. 115808 115809 gas/ChangeLog: 115810 115811 * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for 115812 'Sscofpmf' extension. (riscv_csr_address): Add handling for new 115813 CSR classes. 115814 * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. 115815 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 115816 * testsuite/gas/riscv/csr.s: Add new CSRs. 115817 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 115818 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 115819 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 115820 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 115821 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 115822 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 115823 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 115824 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 115825 115826 include/ChangeLog: 115827 115828 * opcode/riscv-opc.h (CSR_SCOUNTOVF, CSR_MHPMEVENT3H, 115829 CSR_MHPMEVENT4H, CSR_MHPMEVENT5H, CSR_MHPMEVENT6H, 115830 CSR_MHPMEVENT7H, CSR_MHPMEVENT8H, CSR_MHPMEVENT9H, 115831 CSR_MHPMEVENT10H, CSR_MHPMEVENT11H, CSR_MHPMEVENT12H, 115832 CSR_MHPMEVENT13H, CSR_MHPMEVENT14H, CSR_MHPMEVENT15H, 115833 CSR_MHPMEVENT16H, CSR_MHPMEVENT17H, CSR_MHPMEVENT18H, 115834 CSR_MHPMEVENT19H, CSR_MHPMEVENT20H, CSR_MHPMEVENT21H, 115835 CSR_MHPMEVENT22H, CSR_MHPMEVENT23H, CSR_MHPMEVENT24H, 115836 CSR_MHPMEVENT25H, CSR_MHPMEVENT26H, CSR_MHPMEVENT27H, 115837 CSR_MHPMEVENT28H, CSR_MHPMEVENT29H, CSR_MHPMEVENT30H, 115838 CSR_MHPMEVENT31H): New CSR macros. 115839 1158402022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com> 115841 115842 RISC-V: Add 'Smstateen' extension and its CSRs 115843 This commit adds State Enable Extension (Smstateen) and its CSRs. 115844 115845 bfd/ChangeLog: 115846 115847 * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smstateen' 115848 extension to valid 'S' extension list. 115849 115850 gas/ChangeLog: 115851 115852 * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for 115853 'Smstateen' extension. (riscv_csr_address): Add handling for 115854 new CSR classes. 115855 * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. 115856 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 115857 * testsuite/gas/riscv/csr.s: Add new CSRs. 115858 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 115859 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 115860 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 115861 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 115862 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 115863 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 115864 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 115865 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 115866 115867 include/ChangeLog: 115868 115869 * opcode/riscv-opc.h (CSR_MSTATEEN0, CSR_MSTATEEN1, 115870 CSR_MSTATEEN2, CSR_MSTATEEN3, CSR_SSTATEEN0, CSR_SSTATEEN1, 115871 CSR_SSTATEEN2, CSR_SSTATEEN3, CSR_HSTATEEN0, CSR_HSTATEEN1, 115872 CSR_HSTATEEN2, CSR_HSTATEEN3, CSR_MSTATEEN0H, CSR_MSTATEEN1H, 115873 CSR_MSTATEEN2H, CSR_MSTATEEN3H, CSR_HSTATEEN0H, CSR_HSTATEEN1H, 115874 CSR_HSTATEEN2H, CSR_HSTATEEN3H): New CSR macros. 115875 1158762022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com> 115877 115878 RISC-V: Add new CSR feature gate handling (RV32,H) 115879 To support feature gate like Smstateen && H, this commit adds certain 115880 CSR feature gate handling. It also changes how RV32-only CSRs are 115881 handled for cleanliness. 115882 115883 gas/ChangeLog: 115884 115885 * config/tc-riscv.c (riscv_csr_address): Add CSR feature gate 115886 handling for H. Change handling on RV32. 115887 1158882022-06-28 Alan Modra <amodra@gmail.com> 115889 115890 Re: Disable execstack and rwx segments warnings for MIPS targets. 115891 PR 29263 115892 * configure.ac: Fix typo. 115893 * testsuite/ld-elf/elf.exp: Add mips to targets that need 115894 --warn-execstack to pass first pr29072 test. 115895 1158962022-06-28 GDB Administrator <gdbadmin@sourceware.org> 115897 115898 Automatic date update in version.in 115899 1159002022-06-27 Bruno Larsen <blarsen@redhat.com> 115901 115902 gdb/testsuite: update bug numbers from Gnats to bugzilla 115903 Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen. 115904 115905 gdb.base/macscp.exp was referencing bug number 555, and the bug 7660 115906 mentions that it used to be 555 on the Gnats system and seems to relate 115907 to the issue at hand. 115908 115909 gdb.base/annota1.exp was referencing bug number 1270, and bug 8375 115910 mentions being number 1270 on Gnats, and mentions annota1 specifically, 115911 so it seemed pretty obvious. 115912 1159132022-06-27 Tom de Vries <tdevries@suse.de> 115914 115915 [gdb/build] Fix build breaker with --enable-shared 115916 When building gdb with --enable-shared, I run into: 115917 ... 115918 ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \ 115919 `.rodata' can not be used when making a shared object; recompile with -fPIC 115920 ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \ 115921 `inflateResetKeep' in read-only section `.text' 115922 collect2: error: ld returned 1 exit status 115923 make[3]: *** [libbfd.la] Error 1 115924 ... 115925 115926 This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver 115927 build with -fsanitize=thread"). 115928 115929 The problem is that a single case statement in configure is shared to handle 115930 special requirements for both the host libiberty and host zlib, which has the 115931 effect that only one is handled. 115932 115933 Fix this by handling libiberty and zlib each in its own case statement. 115934 115935 Build on x86_64-linux, with and without --enable-shared. 115936 115937 ChangeLog: 115938 115939 2022-06-27 Tom de Vries <tdevries@suse.de> 115940 115941 * configure.ac: Set extra_host_libiberty_configure_flags and 115942 extra_host_zlib_configure_flags in separate case statements. 115943 * configure: Regenerate. 115944 1159452022-06-27 Pedro Alves <pedro@palves.net> 115946 115947 Make GDBserver abort on internal error in development mode 115948 Currently, if GDBserver hits some internal assertion, it exits with 115949 error status, instead of aborting. This makes it harder to debug 115950 GDBserver, as you can't just debug a core file if GDBserver fails an 115951 assertion. I've had to hack the code to make GDBserver abort to debug 115952 something several times before. 115953 115954 I believe the reason it exits instead of aborting, is to prevent 115955 potentially littering the filesystem of smaller embedded targets with 115956 core files. I think I recall Daniel Jacobowitz once saying that many 115957 years ago, but I can't be sure. Anyhow, that seems reasonable to me. 115958 115959 Since we nowadays have a distinction between development and release 115960 modes, I propose to make GDBserver abort on internal error if in 115961 development mode, while keeping the status quo when in release mode. 115962 115963 Thus, after this patch, in development mode, you get: 115964 115965 $ ../gdbserver/gdbserver 115966 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. 115967 captured_main: Assertion `0' failed. 115968 Aborted (core dumped) 115969 $ 115970 115971 while in release mode, you'll continue to get: 115972 115973 $ ../gdbserver/gdbserver 115974 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. 115975 captured_main: Assertion `0' failed. 115976 $ echo $? 115977 1 115978 115979 I do not think that this requires a separate configure switch. 115980 115981 A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends 115982 up with: 115983 115984 === gdb Summary === 115985 115986 # of unexpected core files 29 115987 ... 115988 115989 for me, of which 8 are GDBserver core dumps, 7 more than without this 115990 patch. 115991 115992 Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d 115993 1159942022-06-27 Nick Clifton <nickc@redhat.com> 115995 115996 Replace a run-time assertion failure with a warning message when parsing corrupt DWARF data. 115997 PR 29289 115998 * dwarf.c (display_debug_names): Replace assert with a warning 115999 message. 116000 116001 Fix NULL pointer indirection when parsing corrupt DWARF data. 116002 PR 29290 116003 * dwarf.c (read_and_display_attr_value): Check that debug_info_p 116004 is set before dereferencing it. 116005 116006 Have gold's File_read::do_read() function check the start parameter 116007 PR 23765 116008 * fileread.cc (File_read::do_read): Check start parameter before 116009 computing number of bytes to read. 116010 1160112022-06-27 Yvan Roux <yvan.roux@foss.st.com> 116012 116013 gdb/arm: Unwind Non-Secure callbacks from Secure 116014 Without this changeset, the unwinding doesn't take into account 116015 Non-Secure to Secure stack unwinding enablement status and 116016 doesn't choose the proper SP to do the unwinding. 116017 116018 This patch only unwinds the stack when Non-Secure to Secure 116019 unwinding is enabled, previous SP is set w/r to the current mode 116020 (Handler -> msp_s, Thread -> psp_s) and then the Secure stack is 116021 unwound. Ensure thumb bit is set in PSR when needed. Also, drop 116022 thumb bit from PC if set. 116023 1160242022-06-27 Nick Clifton <nickc@redhat.com> 116025 116026 Stop bogus warnings about DWARF indexed string offsets being too big. 116027 * dwarf.c (fetch_indexed_string): Do not use length of first table 116028 in string section as the length of every table in the section. 116029 * testsuite/binutils-all/pr26112.r: Update expected output. 116030 1160312022-06-27 Tom de Vries <tdevries@suse.de> 116032 116033 [gdb/testsuite] Handle older python in gdb.python/py-send-packet.py 116034 With python 3.4, I run into: 116035 ... 116036 Traceback (most recent call last):^M 116037 File "<string>", line 1, in <module>^M 116038 File 116039 "outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \ 116040 run_set_global_var_test^M 116041 res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M 116042 TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M 116043 Error while executing Python code.^M 116044 ... 116045 while with python 3.6 this works fine. 116046 116047 The type of addr is <class 'gdb.Value'>, so the first thing to try is whether 116048 changing it into a string works: 116049 ... 116050 addr_str = "%x" % addr 116051 res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str) 116052 ... 116053 which gets us the more detailed: 116054 ... 116055 TypeError: unsupported operand type(s) for %: 'bytes' and 'str' 116056 ... 116057 116058 Fix this by avoiding the '%' operator in the byte literal, and use instead: 116059 ... 116060 def xpacket_header (addr): 116061 return ("X%x,4:" % addr).encode('ascii') 116062 ... 116063 res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02") 116064 ... 116065 116066 Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was 116067 tested on the gdb-12-branch in combination with python 2.7. 116068 1160692022-06-27 Tom de Vries <tdevries@suse.de> 116070 116071 [gdb/testsuite] Fix gdb.reverse/i387-env-reverse.exp for -pie 116072 When running test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with 116073 target board unix/-m32/-fPIE/-pie, we run into: 116074 ... 116075 (gdb) PASS: gdb.reverse/i387-env-reverse.exp: push st0 116076 info register eax^M 116077 eax 0x56550000 1448411136^M 116078 (gdb) FAIL: gdb.reverse/i387-env-reverse.exp: verify eax == 0x8040000 116079 ... 116080 116081 The problem is that the tested instruction (fstsw) only sets $ax, not $eax. 116082 116083 Fix this by verifying $ax instead of $eax. 116084 116085 Tested on x86_64-linux with target boards unix/-m32 and unix/-m32/-fPIE/-pie. 116086 1160872022-06-27 Tom de Vries <tdevries@suse.de> 116088 116089 [gdb/testsuite] Enable some test-cases for x86_64 -m32 116090 When trying to run test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux 116091 with target board unix/-m32, it's skipped. 116092 116093 Fix this by using is_x86_like_target instead of istarget "i?86-*linux*". 116094 116095 This exposes a number of duplicates, fix those by making the test names unique. 116096 116097 Likewise in a couple of other test-cases. 116098 116099 Tested on x86_64-linux with target boards unix/-m32. 116100 1161012022-06-27 Tom de Vries <tdevries@suse.de> 116102 116103 [gdb/testsuite] Workaround unnecessary .s file with gfortran 4.8 116104 After running test-case gdb.fortran/namelist.exp with gfortran 4.8.5, I'm left 116105 with: 116106 ... 116107 $ git sti 116108 On branch master 116109 Your branch is up to date with 'origin/master'. 116110 116111 Untracked files: 116112 (use "git add <file>..." to include in what will be committed) 116113 gdb/testsuite/lib/compiler.s 116114 116115 nothing added to commit but untracked files present (use "git add" to track) 116116 ... 116117 116118 We're running into PR gcc/60447, which was fixed in gcc 4.9.0. 116119 116120 Workaround this by first copying the source file to the temp dir, such that 116121 the .s file is left there instead: 116122 ... 116123 $ ls build/gdb/testsuite/temp/<runtest pid>/ 116124 compiler.c compiler.F90 compiler.s 116125 ... 116126 116127 Tested on x86_64-linux. 116128 1161292022-06-27 Tom de Vries <tdevries@suse.de> 116130 116131 [gdb/testsuite] Skip gdb.fortran/namelist.exp for gfortran 4.8 116132 The test-case gdb.fortran/namelist.exp uses a gfortran feature (emitting 116133 DW_TAG_namelist in the debug info) that has been supported since gfortran 4.9, 116134 see PR gcc/37132. 116135 116136 Skip the test for gfortran 4.8 and earlier. Do this using gcc_major_version, 116137 and update it to be able to handle "gcc_major_version {gfortran-*} f90". 116138 116139 Tested on x86_64-linux, with gfortran 4.8.5, 7.5.0, and 12.1.1. 116140 1161412022-06-27 Tom de Vries <tdevries@suse.de> 116142 116143 [gdb/symtab] Fix parsing of .debug_str_offsets header 116144 When running test-case gdb.dwarf2/fission-mix.exp with target board dwarf64 116145 and gcc-12 (defaulting to DWARF5), I run into: 116146 ... 116147 (gdb) break func2^M 116148 Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \ 116149 .debug_str.dwo section in CU at offset 0x0 [in module fission-mix]^M 116150 (gdb) FAIL: gdb.dwarf2/fission-mix.exp: break func2 116151 ... 116152 116153 The .debug_str_offsets section has version 5, so as per the standard it has 116154 it's own header, with initial length and version: 116155 ... 116156 Contents of the .debug_str_offsets.dwo section (loaded from fission-mix2.dwo): 116157 116158 Length: 0x1c 116159 Version: 0x5 116160 Index Offset [String] 116161 0 0 build/gdb/testsuite 116162 1 33 GNU C17 116163 2 8f src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c 116164 ... 116165 116166 But when trying to read the string offset at index 0 in the table (which 116167 is 0), we start reading at offset 8, which points in the header, at the last 116168 4 bytes of the initial length (it's 12 bytes because of 64-bit dwarf), as well 116169 at the 2-byte version field and 2 bytes of padding, so we get: 116170 ... 116171 (gdb) p /x str_offset 116172 $1 = 0x500000000 116173 ... 116174 which indeed is an offset that doesn't fit in the .debug_str section. 116175 116176 The offset 8 is based on reader->cu->header.addr_size: 116177 ... 116178 static const char * 116179 read_dwo_str_index (const struct die_reader_specs *reader, ULONGEST str_index) 116180 { 116181 ULONGEST str_offsets_base = reader->cu->header.version >= 5 116182 ? reader->cu->header.addr_size : 0; 116183 ... 116184 which doesn't in look in agreement with the standard. 116185 116186 Note that this happens to give the right answer for 32-bit dwarf and 116187 addr_size == 8, because then we have header size == 116188 (initial length (4) + version (2) + padding (2)) == 8. 116189 116190 Conversely, for 32-bit dwarf and addr_size == 4 (target board unix/-m32) 116191 we run into a similar problem. It just happens to not trigger the warning, 116192 instead we get the wrong strings, like "func2" for DW_AT_producer and 116193 "build/gdb/testsuite" for DW_AT_name of the DW_TAG_compile_unit DIE. 116194 116195 Fix this by parsing the .debug_str_offsets header in read_dwo_str_index. 116196 116197 Add a FIXME that we should not parse this for every call. 116198 116199 Tested on x86_64-linux. 116200 1162012022-06-27 Tom de Vries <tdevries@suse.de> 116202 116203 [gdb/build] Fix gdbserver build with -fsanitize=thread 116204 [ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with 116205 -fsanitize=thread"). ] 116206 116207 When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we 116208 run into: 116209 ... 116210 ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \ 116211 `__tsan_init' in read-only section `.text' 116212 ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \ 116213 against symbol `__tsan_init' can not be used when making a shared object; \ 116214 recompile with -fPIC 116215 ld: final link failed: bad value 116216 collect2: error: ld returned 1 exit status 116217 make[1]: *** [libinproctrace.so] Error 1 116218 ... 116219 which looks similar to what is described in commit 78e49486944 ("[gdb/build] 116220 Fix gdbserver build with -fsanitize=address"). 116221 116222 The gdbserver component builds a shared library libinproctrace.so, which uses 116223 libiberty and therefore requires the pic variant. The gdbserver Makefile is 116224 setup to use this variant, if available, but it's not there. 116225 116226 Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a 116227 component that needs the libiberty pic variant, setting: 116228 ... 116229 extra_host_libiberty_configure_flags=--enable-shared 116230 ... 116231 116232 Tested on x86_64-linux. 116233 116234 ChangeLog: 116235 116236 2022-06-27 Tom de Vries <tdevries@suse.de> 116237 116238 * configure.ac: Build libiberty pic variant for gdbserver. 116239 * configure: Regenerate. 116240 1162412022-06-27 Nick Clifton <nickc@redhat.com> 116242 116243 Disable execstack and rwx segments warnings for MIPS targets. 116244 PR 29263 116245 * configure.ac: Move HPPA specific code from here... 116246 * configure.tgt: ... to here. Add similar code for MIPS. 116247 Move code for CRIS, MIPS and HPPA to block at start of file. 116248 * configure: Regenerate. 116249 1162502022-06-27 Jan Beulich <jbeulich@suse.com> 116251 116252 bfd: prune config.bfd's setting of targ_archs 116253 The final "match all" case can take care of a few explicit entries: 116254 Purge those. Also move s12z* into proper position (the table is 116255 otherwise sorted, after all). 116256 1162572022-06-27 Jan Beulich <jbeulich@suse.com> 116258 116259 drop XC16x bits 116260 Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved 116261 the architecture from the "obsolete but still available" to the 116262 "obsolete / support removed" list in config.bfd, making the architecture 116263 impossible to enable (except maybe via "enable everything" options"). 116264 116265 Note that I didn't touch */po/*.po{,t} on the assumption that these 116266 would be updated by some (half)automatic means. 116267 1162682022-06-27 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 116269 116270 Fix location list offset address dump under DW_AT_location (dwarf-5) 116271 For clang compiled objects with dwarf-5, location list offset address dump 116272 under DW_AT_location is corrected, where DW_FORM_loclistx is used. While 116273 dumping the location list offset, the address dumped is wrong where it was 116274 refering to .debug_addr instead of .debug_loclists 116275 116276 * dwarf.c (fetch_indexed_value): Add base_address as parameter and 116277 use it to access the section offset. 116278 (read_and_display_attr_value): Handle DW_FORM_loclistx form separately. 116279 Pass loclists_base to fetch_indexed_value(). 116280 1162812022-06-27 Alan Modra <amodra@gmail.com> 116282 116283 PowerPC64 .branch_lt address 116284 .branch_lt is really an extension of .plt, as is .iplt. We'd like all 116285 of the PLT sections to be fixed relative to .TOC. after stub sizing, 116286 because changes in offset to PLT entries might mean a change in stub 116287 sizes. When -z relro, the relro layout does this by laying out 116288 sections from the end of the relro segment. So for example, a change 116289 in .eh_frame (which happens after stub sizing) will keep the same GOT 116290 to PLT offset when -z relro. Not so when -z norelro, because then the 116291 usual forward layout of section is done and .got is more aligned than 116292 .branch_lt. 116293 116294 * emulparams/elf64ppc.sh: Set .branch_lt address fixed relative 116295 to .got. 116296 * testsuite/ld-powerpc/elfv2exe.d: Adjust to suit. 116297 1162982022-06-27 Alan Modra <amodra@gmail.com> 116299 116300 -z relro relaxation and ld script SIZEOF 116301 A number of targets use assignments like: 116302 . = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .); 116303 (from i386) in linker scripts to put the end of the relro segment past 116304 the header in .got.plt. Examination of testcases like those edited by 116305 this patch instead sees the end of the relro segment being placed at 116306 the start of .got.plt. For the i386 pie1 test: 116307 116308 [ 9] .got.plt PROGBITS 00002000 001000 00000c 04 WA 0 0 4 116309 116310 GNU_RELRO 0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R 0x1 116311 116312 A map file shows: 116313 116314 .dynamic 0x0000000000001f90 0x70 116315 *(.dynamic) 116316 .dynamic 0x0000000000001f90 0x70 tmpdir/pie1.o 116317 0x0000000000001f90 _DYNAMIC 116318 116319 .got 0x0000000000002000 0x0 116320 *(.got) 116321 .got 0x0000000000002000 0x0 tmpdir/pie1.o 116322 *(.igot) 116323 0x0000000000002ff4 . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0) 116324 116325 .got.plt 0x0000000000002000 0xc 116326 *(.got.plt) 116327 .got.plt 0x0000000000002000 0xc tmpdir/pie1.o 116328 0x0000000000002000 _GLOBAL_OFFSET_TABLE_ 116329 116330 The DATA_SEGMENT_RELRO_END value in the map file is weird too. All of 116331 this is triggered by SIZEOF (.got.plt) being evaluated wrongly as 116332 zero. Fix it by taking into account the action of 116333 lang_reset_memory_regions during relaxation. 116334 116335 * ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset. 116336 * ldlang.c (lang_size_sections_1): Don't reset processed_vma here. 116337 * testsuite/ld-i386/pie1.d: Adjust to suit. 116338 * testsuite/ld-x86-64/pr20830a.d: Likewise. 116339 * testsuite/ld-x86-64/pr20830b.d: Likewise. 116340 * testsuite/ld-x86-64/pr21038a.d: Likewise. 116341 * testsuite/ld-x86-64/pr21038b.d: Likewise. 116342 * testsuite/ld-x86-64/pr21038c.d: Likewise. 116343 1163442022-06-27 GDB Administrator <gdbadmin@sourceware.org> 116345 116346 Automatic date update in version.in 116347 1163482022-06-26 GDB Administrator <gdbadmin@sourceware.org> 116349 116350 Automatic date update in version.in 116351 1163522022-06-25 Fangrui Song <i@maskray.me> 116353 116354 arm: Define elf_backend_extern_protected_data to 0 [PR 18705] 116355 Similar to commit 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2 for aarch64. 116356 116357 Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce 116358 R_ARM_GLOB_DAT but that defeated the purpose of protected visibility 116359 as an optimization. Restore the previous behavior (which matches 116360 ld.lld) by defining elf_backend_extern_protected_data to 0. 116361 1163622022-06-25 Tom Tromey <tom@tromey.com> 116363 116364 Fix corrupt DWARF in dw2-double-set-die-type 116365 The dw2-double-set-die-type.exp test case caused an AddressSanitizer 116366 failure in the new DWARF scanner. 116367 116368 The immediate cause was bad DWARF in the test -- in particular, the 116369 the sibling attribute here: 116370 116371 <2><181>: Abbrev Number: 33 (DW_TAG_subprogram) 116372 <182> DW_AT_external : 1 116373 <183> DW_AT_name : address 116374 <18b> DW_AT_type : <0x171> 116375 <18f> DW_AT_declaration : 1 116376 <190> DW_AT_sibling : <0x1a1> 116377 ... 116378 <1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type) 116379 <1a2> DW_AT_byte_size : 4 116380 <1a3> DW_AT_type : <0x1a7> 116381 116382 ...points to a "sibling" DIE that is at a different child depth. 116383 116384 Because this test case doesn't really require sibling attributes, this 116385 patch fixes the problem by removing them from the test. 116386 116387 Note that gdb is not generally robust against malformed DWARF. 116388 Detecting and compensating for this problem would probably be 116389 expensive and, IMO, is better left to some (still hypothetical) DWARF 116390 linter. 116391 1163922022-06-25 Tom Tromey <tom@tromey.com> 116393 116394 Fix end of CU calculation in cooked_indexer::index_dies 116395 cooked_indexer::index_dies incorrect computes the end of the current 116396 CU in the .debug_info. This isn't readily testable without writing 116397 intentionally corrupt DWARF, but it's apparent through observation: it 116398 is currently based on 'info_ptr', which does not always point to the 116399 start of the CU. This patch fixes the expression. Tested on x86-64 116400 Fedora 34. 116401 1164022022-06-25 Tiezhu Yang <yangtiezhu@loongson.cn> 116403 116404 gdb: LoongArch: Implement loongarch_linux_syscall_next_pc() 116405 When FRAME is at a syscall instruction, return the PC of the next 116406 instruction to be executed. 116407 116408 gdb: LoongArch: Define register numbers and clean up code 116409 This commit defines register numbers of various important registers, 116410 we can use them directly in the related code, and also clean up some 116411 code to make them more clear and readable. 116412 1164132022-06-25 GDB Administrator <gdbadmin@sourceware.org> 116414 116415 Automatic date update in version.in 116416 1164172022-06-24 Pedro Alves <pedro@palves.net> 116418 116419 Eliminate TUI/CLI observers duplication 116420 For historical reasons, the CLI and the TUI observers are basically 116421 exact duplicates, except for the downcast: 116422 116423 cli: 116424 struct cli_interp *cli = as_cli_interp (interp); 116425 tui: 116426 struct interp *tui = as_tui_interp (interp); 116427 116428 and how they get at the interpreter's ui_out: 116429 116430 cli: 116431 cli->cli_uiout 116432 tui: 116433 tui->interp_ui_out () 116434 116435 Since interp_ui_out() is a virtual method that also works for the CLI 116436 interpreter, and, both the CLI and the TUI interpreters inherit from 116437 the same base class (cli_interp_base), we can convert the CLI 116438 observers to cast to cli_interp_base instead and use interp_ui_out() 116439 too. With that, the CLI observers will work for the TUI interpreter 116440 as well. This lets us completely eliminate the TUI observers. That's 116441 what this commit does. 116442 116443 Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0 116444 1164452022-06-24 Pedro Alves <pedro@palves.net> 116446 116447 Revert "Delete delete_thread_silent" 116448 Turns out we'll be gaining a new use of this function very soon, the 116449 incoming AMDGPU port needs it. Let's add it back, as it isn't really 116450 hurting anything. 116451 116452 This reverts commit 39b8a8090ed7e8967ceca3655aa5f3a2ae91219d. 116453 1164542022-06-24 Yvan Roux <yvan.roux@foss.st.com> 116455 116456 gdb/arm: Update the value of active sp when base sp changes 116457 For Arm Cortex-M33 with security extensions, there are 4 different 116458 stacks pointers (msp_s, msp_ns, psp_s, psp_ns). 116459 When plain "sp" is updated during unwinding of the stack, the active 116460 stack pointer of the 4 stack pointers needs to be kept in sync. 116461 1164622022-06-24 Andrew Burgess <aburgess@redhat.com> 116463 116464 gdb/testsuite: remove unneeded calls to get_compiler_info 116465 It is not necessary to call get_compiler_info before calling 116466 test_compiler_info, and, after recent commits that removed setting up 116467 the gcc_compiled, true, and false globals from get_compiler_info, 116468 there is now no longer any need for any test script to call 116469 get_compiler_info directly. 116470 116471 As a result every call to get_compiler_info outside of lib/gdb.exp is 116472 redundant, and this commit removes them all. 116473 116474 There should be no change in what is tested after this commit. 116475 1164762022-06-24 Andrew Burgess <aburgess@redhat.com> 116477 116478 gdb/testsuite: remove global gcc_compiled from gdb.exp 116479 After this commit the gcc_compiled global is no longer exported from 116480 lib/gdb.exp. In theory we could switch over all uses of gcc_compiled 116481 to instead call test_compiler_info directly, however, I have instead 116482 added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated 116483 the testsuite to call this proc instead of using the global. 116484 116485 Having a new proc specifically for this task means that we have a 116486 single consistent pattern for detecting gcc. By wrapping this logic 116487 within a proc that calls test_compiler_info, rather than using the 116488 global, means that test scripts don't need to call get_compiler_info 116489 before they read the global, simply calling the new proc does 116490 everything in one go. 116491 116492 As a result I've been able to remove the get_compiler_info calls from 116493 all the test scripts that I've touched in this commit. 116494 116495 In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was 116496 being checked at the top of the script to decide if the whole script 116497 should be skipped or not. In these cases I've called the new proc 116498 directly and removed all uses of gcc_compiled. 116499 116500 In other cases, e.g. most of the gdb.base scripts, there were many 116501 uses of gcc_compiled. In these cases I set a new global gcc_compiled 116502 near the top of the script, and leave the rest of the script 116503 unchanged. 116504 116505 There should be no changes in what is tested after this commit. 116506 1165072022-06-24 Pedro Alves <pedro@palves.net> 116508 116509 Include count of unexpected core files in gdb.sum summary 116510 If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly 116511 crash while running the GDB testsuite, and you've setup your machine 116512 such that core files are dumped in the current directory instead of 116513 being shoved somewhere by abrt, apport, or similar (as you should for 116514 proper GDB testing), you'll end up with an unexpected core file in the 116515 $build/gdb/testsuite/ directory. 116516 116517 It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit, 116518 during teardown, and thus such a crash won't be noticed by looking at 116519 the gdb.sum file at all. This commit aims at improving that, by 116520 including a new "unexpected core files" line in the testrun summary. 116521 116522 For example, here's what I get on x86-64 Ubuntu 20.04, with this 116523 patch: 116524 116525 === gdb Summary === 116526 116527 # of unexpected core files 12 << new info 116528 # of expected passes 107557 116529 # of unexpected failures 35 116530 # of expected failures 77 116531 # of unknown successes 2 116532 # of known failures 114 116533 # of untested testcases 31 116534 # of unsupported tests 139 116535 116536 I have my core pattern setup like this: 116537 116538 $ cat /proc/sys/kernel/core_pattern 116539 core.%e.%p.%h.%t 116540 116541 That's: 116542 116543 %e: executable filename 116544 %p: pid 116545 %h: hostname 116546 %t: UNIX time of dump 116547 116548 and so I get these core files: 116549 116550 $ ls -1 testsuite/core.* 116551 testsuite/core.connect-with-no.216191.nelson.1656002431 116552 testsuite/core.connect-with-no.217729.nelson.1656002431 116553 testsuite/core.gdb.194247.nelson.1656002423 116554 testsuite/core.gdb.226014.nelson.1656002435 116555 testsuite/core.gdb.232078.nelson.1656002438 116556 testsuite/core.gdb.352268.nelson.1656002441 116557 testsuite/core.gdb.4152093.nelson.1656002337 116558 testsuite/core.gdb.4154515.nelson.1656002338 116559 testsuite/core.gdb.4156668.nelson.1656002339 116560 testsuite/core.gdb.4158871.nelson.1656002341 116561 testsuite/core.gdb.468495.nelson.1656002444 116562 testsuite/core.vgdb.4192247.nelson.1656002366 116563 116564 where we can see that GDB crashed a number of times, but also 116565 Valgrind's vgdb, and a couple testcase programs. Neither of which is 116566 good. 116567 116568 If your core_pattern is just "core" (but why??), then I guess that you 116569 may end up with just a single core file in testsuite/. Still, that is 116570 one core file too many. 116571 116572 Above, we see a couple cores for "connect-with-no", which are the 116573 result of gdb.server/connect-with-no-symbol-file.exp. This is a case 116574 mentioned above -- while the program crashed, that happens during 116575 testcase teardown, and it goes unnoticed (without this commit) by 116576 gdb.sum results. Vis: 116577 116578 $ make check TESTS="gdb.server/connect-with-no-symbol-file.exp" 116579 ... 116580 === gdb Summary === 116581 116582 # of unexpected core files 2 116583 # of expected passes 8 116584 116585 ... 116586 $ 116587 116588 The tests fully passed, but still the testcase program crashed 116589 somehow: 116590 116591 $ ls -1 testsuite/core.* 116592 testsuite/core.connect-with-no.941561.nelson.1656003317 116593 testsuite/core.connect-with-no.941682.nelson.1656003317 116594 116595 Against --target_board=native-extended-gdbserver it's even worse. I 116596 get: 116597 116598 # of unexpected core files 26 116599 116600 and note that when GDBserver hits an assertion failure, it exits with 116601 error, instead of crashing with SIGABRT. I think that should be 116602 changed, at least on development builds, but that would be for another 116603 patch. After such patch, I suspect the number of unexpected cores 116604 will be higher, as there are likely teardown GDBserver assertions that 116605 we're not noticing. 116606 116607 I decided to put this new info in the "gdb Summary" section, as that's 116608 a place people already are used to looking at, either when looking at 116609 the tail of gdb.sum, or when diffing gdb.sum files, and we've already 116610 extended this section before, to include the count of DUPLICATE and 116611 PATH problems, so there's precedent. 116612 116613 Implementation-wise, the new line is appended after DejaGnu is 116614 finished, with a shell script that is invoked by the Makefile. It is 116615 done this way so that serial and parallel testing work the same way. 116616 My initial cut at an implementation was in TCL, straight in 116617 testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are 116618 handled, like so: 116619 116620 @@ -148,6 +159,10 @@ namespace eval ::CheckTestNames { 116621 $counts(paths,$which) 116622 maybe_show_count "# of duplicate test names\t" \ 116623 $counts(duplicates,$which) 116624 + 116625 + set cores [glob -nocomplain -directory $::objdir core*] 116626 + maybe_show_count "# of unexpected core files\t" \ 116627 + [llength $cores] 116628 } 116629 116630 But that would only work for serial testing, as in parallel testing, 116631 the final gdb.sum is generated by aggregating the results of all the 116632 individual gdb.sum files, and dg-extract-results.sh doesn't know about 116633 our new summary line. And I don't think that dg-extract-results.sh 116634 should be taught about it, since the count of core files is not 116635 something that we want to count many times, once per testcase, and 116636 then add up the subcounts at the end. Every time we count the core 116637 files, we're already counting the final count. 116638 116639 I considered using the Tcl implementation in serial mode, and the 116640 script approach for parallel testing, but that has the obvious 116641 downside of implementing and maintaining the same thing twice. In the 116642 end, I settled on the script approach for serial mode too, which 116643 requires making the "check-single" rule print the tail end of the 116644 gdb.sum file, with a side effect being that if you look at the 116645 terminal after a run (instead of at the gdb.sum file), you'll see the 116646 "gdb Summary" section twice, once without the unexpected core lines 116647 printed, and then another with. IMO, this isn't an issue; when 116648 testing in parallel mode, if you look at the terminal after "make -jN 116649 check", you'll also see multiple "gdb Summary" sections printed. 116650 116651 Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491 116652 1166532022-06-24 Pedro Alves <pedro@palves.net> 116654 116655 Improve core file path detection & put cores in output dir 116656 After a testrun, I noticed that I have some kernel-produced cores for 116657 testcase programs, under build/gdb/testsuite/, which shouldn't be 116658 there: 116659 116660 $ ls -1 testsuite/core.* 116661 testsuite/core.annota1.1274351.nelson.1656004407 116662 testsuite/core.annota3.1288474.nelson.1656004414 116663 testsuite/core.exitsignal.1240674.nelson.1656004391 116664 116665 I have my core pattern setup like this: 116666 116667 $ cat /proc/sys/kernel/core_pattern 116668 core.%e.%p.%h.%t 116669 116670 That's: 116671 116672 %e: executable filename 116673 %p: pid 116674 %h: hostname 116675 %t: UNIX time of dump 116676 116677 so it's easy to tell which program produced the core from the core 116678 file name. 116679 116680 From above, we can tell that the corresponding testcases are 116681 gdb.base/annota1.exp, gdb.base/annota3.exp and 116682 gdb.base/exitsignal.exp. 116683 116684 At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in 116685 them to delete the core file. However, that isn't working for me, 116686 because said code only looks for cores named exactly either "core" or 116687 "core.PID", and my core_pattern doesn't match that. 116688 116689 Another issue I noticed, is that I have not been running 116690 gdb.base/bigcore.exp, for a similar reason. I get: 116691 116692 Program terminated with signal SIGABRT, Aborted. 116693 The program no longer exists. 116694 (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT 116695 UNTESTED: gdb.base/bigcore.exp: can't generate a core file 116696 116697 But I actually have a core file under the testcase's output dir: 116698 116699 $ find . -name "core.*" 116700 ./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213 116701 $ 116702 116703 This commit fixes these things, by adding a find_core_file routine 116704 that searches core files in a way that works with my core pattern as 116705 well. This then also adds a convenience remove_core routine as a 116706 wrapper around find_core_file that removes the found core file. 116707 116708 In addition, it changes some testcases that expect to have their 116709 program dump core, to switch the inferior's cwd to the testcase's 116710 output dir, so that the core is dumped there instead of in 116711 build/gdb/testsuite/. Some testcases were already doing that, but not 116712 all. The idea is that any core file dumped in build/gdb/testsuite/ is 116713 an unexpected core file. The next patch will add a count of such 116714 unexpected core files to gdb.sum. 116715 116716 Another change is that the directory changing is now done with "set 116717 cwd" instead of with "cd". "set cwd" only affects the inferior cwd, 116718 while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd", 116719 if GDB dumps core in these testcases, the GDB core dump will still end 116720 up in build/gdb/testsuite/, and can thus be detected as an unexpected 116721 core. 116722 116723 Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607 116724 1167252022-06-24 Andrew Burgess <aburgess@redhat.com> 116726 116727 gdb: make use of RAII in run_inferior_call 116728 In passing I noticed that there are three local variables in 116729 run_inferior_call that are used to save, and then restore some state, 116730 I think these could all be replaced with a RAII style scoped_restore 116731 instead. 116732 116733 Of the three locals that I've changed, the only one that I believe is 116734 now restored in a different location is ui::async, before this commit 116735 the async field was restored after a call to either delete_file_handle 116736 or ui_register_input_event_handler, and after this commit, the field 116737 is restored before these calls. However, I don't believe that either 116738 of these functions depend on the value of the async field, so I 116739 believe the commit is fine. 116740 116741 Tested on x86-64/Linux passes with no regressions. 116742 1167432022-06-24 Pedro Alves <pedro@palves.net> 116744 116745 Delete delete_thread_silent 116746 delete_thread_silent is no longer used anywhere. Delete it. 116747 116748 Change-Id: Iafcec12339861d5ab2e29c14d7b1f884c9e11c0f 116749 1167502022-06-24 GDB Administrator <gdbadmin@sourceware.org> 116751 116752 Automatic date update in version.in 116753 1167542022-06-23 Tom Tromey <tromey@adacore.com> 116755 116756 Don't declare cli_set_logging 116757 cli_set_logging is declared but not defined. It's probably a leftover 116758 from whenever interpreters were changed to use inheritance. This 116759 patch removes the declaration. Tested by grep and rebuilding. 116760 116761 Use PyBool_FromLong 116762 I noticed a few spots that were explicitly creating new references to 116763 Py_True or Py_False. It's simpler here to use PyBool_FromLong, so 116764 this patch changes all the places I found. 116765 1167662022-06-23 Alan Modra <amodra@gmail.com> 116767 116768 PowerPC64: fix assertion in ppc_build_one_stub with -Os code 116769 save_res stubs aren't written in ppc_build_one_stub, their offsets 116770 (which are zero) should not be checked. 116771 116772 * elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets. 116773 1167742022-06-23 Alan Modra <amodra@gmail.com> 116775 116776 Re: PowerPC64: stub debug dump 116777 Let's show the current stub as well as the previous one. Of interest 116778 is the current offset and a new field, id. Check that the build 116779 hash table traversal is in the same order as sizing traversal too. 116780 116781 * elf64-ppc.c (struct ppc_stub_hash_entry): Add id. 116782 (struct ppc_link_hash_table): Add stub_id. 116783 (stub_hash_newfunc): Init id and symtype. 116784 (dump_stub): New function, extracted from.. 116785 (dump_previous_stub): ..here. Deleted. 116786 (ppc_build_one_stub): Sanity check stub id as well as offset. 116787 Show current stub as well as previous. 116788 (ppc_size_one_stub): Set stub id. 116789 (ppc64_elf_size_stubs): Init stub_id before traversal. 116790 (ppc64_elf_build_stubs): Likewise. 116791 1167922022-06-23 Fangrui Song <maskray@google.com> 116793 116794 aarch64: Allow PC-relative relocations against protected STT_FUNC for -shared 116795 __attribute__((visibility("protected"))) void *foo() { 116796 return (void *)foo; 116797 } 116798 116799 gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic: 116800 116801 relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC 116802 116803 Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress 116804 the error. The new behavior matches gold and ld.lld. 116805 116806 Note: if some code tries to use direct access relocations to take the 116807 address of foo (likely due to -fno-pic), the pointer equality will 116808 break, but the error should be reported on the executable link, not on 116809 the innocent shared object link. glibc 2.36 will give a warning at 116810 relocation resolving time. 116811 1168122022-06-23 Fangrui Song <maskray@google.com> 116813 116814 aarch64: Define elf_backend_extern_protected_data to 0 [PR 18705] 116815 Follow-up to commit 90b7a5df152a64d2bea20beb438e8b81049a5c30 116816 ("aarch64: Disallow copy relocations on protected data"). 116817 116818 Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce 116819 R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility 116820 as an optimization. Restore the previous behavior (which matches 116821 ld.lld) by defining elf_backend_extern_protected_data to 0. 116822 1168232022-06-23 GDB Administrator <gdbadmin@sourceware.org> 116824 116825 Automatic date update in version.in 116826 1168272022-06-22 Tom Tromey <tromey@adacore.com> 116828 116829 Use std::string for interpreter_p 116830 The global interpreter_p is a manually-managed 'char *'. This patch 116831 changes it to be a std::string instead, and removes some erroneous 116832 comments. 116833 116834 Move mi_interpreter to mi-interp.h 116835 I noticed that touching interps.h caused a lot of recompilation. I 116836 tracked this down to mi-common.h including this file. This patch 116837 moves the MI interpreter to mi-interp.h, which cuts down on 116838 recompilation when modifying interps.h. 116839 116840 Use unique_xmalloc_ptr in interp 116841 This changes interp::m_name to be a unique_xmalloc_ptr, removing some 116842 manual memory management. It also cleans up the initialization of the 116843 'inited' member, and moves the 'private:' and 'public:' keywords to 116844 their proper spots. 116845 1168462022-06-22 Fangrui Song <i@maskray.me> 116847 116848 aarch64: Disallow copy relocations on protected data 116849 If an executable has copy relocations for extern protected data, that 116850 can only work if the shared object containing the definition is built 116851 with assumptions (a) the compiler emits GOT-generating relocations (b) 116852 the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the 116853 shared object uses its own definition directly and the executable 116854 accesses a stale copy. Note: the GOT relocations defeat the purpose of 116855 protected visibility as an optimization, and it turns out this never 116856 worked perfectly. 116857 116858 glibc 2.36 will warn on copy relocations on protected data. Let's 116859 produce a warning at link time, matching ld.lld which has been used on 116860 many aarch64 OSes. 116861 116862 Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error. 116863 This is to largely due to GCC 5's "x86-64: Optimize access to globals in 116864 PIE with copy reloc" which started to use direct access relocations for 116865 external data symbols in -fpie mode. 116866 116867 GCC's aarch64 port does not have the change. Nowadays with most builds 116868 switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about 116869 copy relocations. So for aarch64 we simply don't check 116870 GNU_PROPERTY_NO_COPY_ON_PROTECTED. 116871 1168722022-06-22 Kumar N, Bhuvanendra <Kavitha.Natarajan@amd.com> 116873 116874 Binutils support for split-dwarf and dwarf-5 116875 * dwarf.c (fetch_indexed_string): Added new parameter 116876 str_offsets_base to calculate the string offset. 116877 (read_and_display_attr_value): Read DW_AT_str_offsets_base 116878 attribute. 116879 (process_debug_info): While allocating memory and initializing 116880 debug_information, do it for do_debug_info also, if its true. 116881 (load_separate_debug_files): Load .debug_str_offsets if exists. 116882 * dwarf.h (struct debug_info): Add str_offsets_base field. 116883 1168842022-06-22 Nelson Chu <nelson.chu@sifive.com> 116885 116886 RISC-V: Reorder the prefixed extensions which are out of order. 116887 This patch has been pending for almost a year... However, I noticed that 116888 llvm can already re-order the extensions, even if they are out of orders. 116889 Not really sure if they can also re-order the single letter extensions, 116890 but at least we can do this for the multi-letter extensions in binutils. 116891 116892 bfd/ 116893 * elfxx-riscv.c (riscv_parse_prefixed_ext): Removed the code which are 116894 used to check the prefixed extension orders. 116895 gas/ 116896 * testsuite/gas/riscv/march-fail-order-x-z.d: Removed since we will help 116897 tp reorder the prefixed extensions for now. 116898 * testsuite/gas/riscv/march-fail-order-x-z.l: Likewise. 116899 * testsuite/gas/riscv/march-fail-order-x.d: Likewise. 116900 * testsuite/gas/riscv/march-fail-order-x.l: Likewise. 116901 * testsuite/gas/riscv/march-fail-order-z.d: Likewise. 116902 * testsuite/gas/riscv/march-fail-order-z.l: Likewise. 116903 1169042022-06-22 Nelson Chu <nelson.chu@sifive.com> 116905 116906 RISC-V: Use single h extension to control hypervisor CSRs and instructions. 116907 According to the picture 28.1 in the current ISA spec, h is no larger the 116908 multi-letter extension, it is a single extension after v. Therefore, this 116909 patch fix the implementation, and use the single h to control hypervisor 116910 CSRs and instructions, which we promised to do before. 116911 116912 bfd/ 116913 * elfxx-riscv.c (riscv_supported_std_ext): Added h with version 1.0 after v. 116914 (riscv_supported_std_h_ext): Removed. 116915 (riscv_all_supported_ext): Updated since riscv_supported_std_h_ext is removed. 116916 (riscv_prefix_ext_class): Removed RV_ISA_CLASS_H. 116917 (parse_config): Updated since riscv_prefix_ext_class is removed. 116918 (riscv_recognized_prefixed_ext): Likewise. 116919 (riscv_get_default_ext_version): Likewise. 116920 (riscv_multi_subset_supports): Handle INSN_CLASS_H for hypervisor instructions. 116921 (riscv_multi_subset_supports_ext): Likewise. 116922 gas/ 116923 * config/tc-riscv.c (riscv_csr_class): Added CSR_CLASS_H and CSR_CLASS_H_32 for 116924 hypervisor CSRs. 116925 (riscv_csr_address): Likewise. 116926 * testsuite/gas/riscv/csr-version-1p10.d: Updated since hypervisor CSRs are 116927 controlled by single h extension for now. 116928 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 116929 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 116930 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 116931 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 116932 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 116933 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 116934 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 116935 * testsuite/gas/riscv/h-ext-32.d: Added h to architecture string. 116936 * testsuite/gas/riscv/h-ext-64.d: Likewise. 116937 * testsuite/gas/riscv/march-fail-single-prefix-h: Removed since h is no 116938 longer multi-letter extension. 116939 * testsuite/gas/riscv/march-fail-unknown-h.d: Likewise. 116940 include/ 116941 * opcode/riscv-opc.h: Control hypervisor CSRs by h extension, rather than 116942 the privileged spec verisons. 116943 * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_H. 116944 opcodes/ 116945 * riscv-opc.c (riscv_opcodes): Control hypervisor instructions by h extension. 116946 1169472022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com> 116948 116949 RISC-V: Add 'H' to canonical extension ordering 116950 This commit adds 'H' to canonical extension ordering based on current 116951 consensus (not officially ratified as a new ISA specification manual 116952 but discussion for software compatibility is made). 116953 116954 bfd/ChangeLog 116955 116956 * elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for 116957 canonical extension ordering based on current consensus. 116958 1169592022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com> 116960 116961 RISC-V: Prepare i18n for required ISA extensions 116962 Some strings returned by the riscv_multi_subset_supports_ext function 116963 contain not just extension names but words like "and" and "or". 116964 This commit wraps such strings with the gettext macro (_) for 116965 internationalization in the future. 116966 116967 bfd/ChangeLog: 116968 116969 * elfxx-riscv.c (riscv_multi_subset_supports_ext): Wrap some 116970 strings with the gettext macro to prepare future i18n. 116971 1169722022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com> 116973 116974 RISC-V: Fix inconsistent error message (range) 116975 This commit fixes inconsistent error message format involving compressed 116976 funct<n> fields. In specific, funct6 had an error message with range 116977 0..2^<n> ("0..64") unlike other funct<n> fields with 0..2^<n>-1 116978 (e.g. funct4 with "0..15"). 116979 116980 gas/ChangeLog: 116981 116982 * config/tc-riscv.c (riscv_ip): Fix inconsistent error message. 116983 1169842022-06-22 Marcus Nilsson <brainbomb@gmail.com> 116985 116986 readelf: replace xmalloc with malloc in slurp_relr_relocs 116987 Using xmalloc makes the null check redundant since failing allocation 116988 will exit the program. Instead use malloc and let the error be 116989 conveyed up the call chain. 116990 1169912022-06-22 Alan Modra <amodra@gmail.com> 116992 116993 PowerPC64: stub debug dump 116994 powerpc64le-linux-ld is failing the assertion in ppc_build_one_stub, 116995 again apparently, which means a stub will overwrite the tail of a 116996 previous stub. The difficulty with debugging these issues is that 116997 it's not a problem with the stub that triggers the assertion, but the 116998 previous stub in that section. This patch keeps track of the last 116999 stub and adds a debug dump. Hopefully that will help. 117000 117001 * elf64-ppc.c (enum _ppc64_sec_type): Add sec_stub. 117002 (struct _ppc64_elf_section_data): Add u.last_ent. 117003 (dump_previous_stub): New function. 117004 (ppc_build_one_stub): Keep track of previous stub, and dump it 117005 when finding an overlapping stub. 117006 1170072022-06-22 Alan Modra <amodra@gmail.com> 117008 117009 PR29270, DW_FORM_udata signed output 117010 PR 29270 117011 * dwarf.c (read_and_display_attr_value): Output DW_FORM_udata 117012 as unsigned. 117013 1170142022-06-22 GDB Administrator <gdbadmin@sourceware.org> 117015 117016 Automatic date update in version.in 117017 1170182022-06-21 Nick Alcock <nick.alcock@oracle.com> 117019 117020 ld: regenerate configure after recent misgeneration 117021 Things work again after this. 117022 117023 ld/ChangeLog: 117024 117025 * configure: Regenerate. 117026 1170272022-06-21 Nick Alcock <nick.alcock@oracle.com> 117028 117029 libctf: tests: prune warnings from compiler output 117030 We were failing to call prune_warnings appropriately, leading to 117031 false-positive test failures on some platforms (observed on 117032 sparclinux). 117033 117034 libctf/ChangeLog: 117035 117036 * testsuite/lib/ctf-lib.exp: Prune warnings from compiler and 117037 linker output. 117038 * testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise, 117039 and ar output too. 117040 1170412022-06-21 Nick Alcock <nick.alcock@oracle.com> 117042 117043 libctf: avoid mingw warning 117044 A missing paren led to an intended cast to avoid dependence on the size 117045 of size_t in one argument of ctf_err_warn applying to the wrong type by 117046 mistake. 117047 117048 libctf/ChangeLog: 117049 117050 * ctf-serialize.c (ctf_write_mem): Fix cast. 117051 1170522022-06-21 Nick Alcock <nick.alcock@oracle.com> 117053 117054 libctf: fix linking together multiple objects derived from the same source 117055 Right now, if you compile the same .c input repeatedly with CTF enabled 117056 and different compilation flags, then arrange to link all of these 117057 together, then things misbehave in various ways. libctf may conflate 117058 either inputs (if the .o files have the same name, say if they are 117059 stored in different .a archives), or per-CU outputs when conflicting 117060 types are found: the latter can lead to entirely spurious errors when 117061 it tries to produce multiple per-CU outputs with the same name 117062 (discarding all but the last, but then looking for types in the earlier 117063 ones which have just been thrown away). 117064 117065 Fixing this is multi-pronged. Both inputs and outputs need to be 117066 differentiated in the hashtables libctf keeps them in: inputs with the 117067 same cuname and filename need to be considered distinct as long as they 117068 have different associated CTF dicts, and per-CU outputs need to be 117069 considered distinct as long as they have different associated input 117070 dicts. Right now there is nothing tying the two together other than the 117071 CU name: fix this by introducing a new field in the ctf_dict_t named 117072 ctf_link_in_out, which (for input dicts) points to the associated per-CU 117073 output dict (if any), and for output dicts points to the associated 117074 input dict. At creation time the name used is completely arbitrary: 117075 it's only important that it be distinct if CTF dicts are distinct. So, 117076 when a clash is found, adjust the CU name by sticking the number of 117077 elements in the input on the end. At output time, the CU name will 117078 appear in the linked object, so it matters a little more that it look 117079 slightly less ugly: in conflicting cases, append an incrementing 117080 integer, starting at 0. 117081 117082 This naming scheme is not very helpful, but it's hard to see what else 117083 we can do. The input .o name may be the same. The input .a name is not 117084 even visible to ctf_link, and even *that* might be the same, because 117085 .a's can contain many members with the same name, all of which 117086 participate in the link. All we really know is that the two have 117087 distinct dictionaries with distinct types in them, and at least this way 117088 they are all represented, any any symbols, variables etc referring to 117089 those types are accurately stored. 117090 117091 (As a side-effect this also fixes a use-after-free and double-free when 117092 errors are found during variable or symbol emission.) 117093 117094 Use the opportunity to prevent a couple of sources of problems, to wit 117095 changing the active CU mappings when a link has already been done 117096 (no effect on ld, which doesn't use CU mappings at all), and causing 117097 multiple consecutive ctf_link's to have the same net effect as just 117098 doing the last one (no effect on ld, which only ever does one 117099 ctf_link) rather than having the links be a sort of half-incremental 117100 not-really-intended mess. 117101 117102 libctf/ChangeLog: 117103 117104 PR libctf/29242 117105 * ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New. 117106 * ctf-dedup.c (ctf_dedup_emit_type): Set it. 117107 * ctf-link.c (ctf_link_add_ctf_internal): Set the input 117108 CU name uniquely when clashes are found. 117109 (ctf_link_add): Document what repeated additions do. 117110 (ctf_new_per_cu_name): New, come up with a consistent 117111 name for a new per-CU dict. 117112 (ctf_link_deduplicating): Use it. 117113 (ctf_create_per_cu): Use it, and ctf_link_in_out, and set 117114 ctf_link_in_out properly. Don't overwrite per-CU dicts with 117115 per-CU dicts relating to different inputs. 117116 (ctf_link_add_cu_mapping): Prevent per-CU mappings being set up 117117 if we already have per-CU outputs. 117118 (ctf_link_one_variable): Adjust ctf_link_per_cu call. 117119 (ctf_link_deduplicating_one_symtypetab): Likewise. 117120 (ctf_link_empty_outputs): New, delete all the ctf_link_outputs 117121 and blank out ctf_link_in_out on the corresponding inputs. 117122 (ctf_link): Clarify the effect of multiple ctf_link calls. 117123 Empty ctf_link_outputs if it already exists rather than 117124 having the old output leak into the new link. Fix a variable 117125 name. 117126 * testsuite/config/default.exp (AR): Add. 117127 (OBJDUMP): Likewise. 117128 * testsuite/libctf-regression/libctf-repeat-cu.exp: New test. 117129 * testsuite/libctf-regression/libctf-repeat-cu*: Main program, 117130 library, and expected results for the test. 117131 1171322022-06-21 Kevin Buettner <kevinb@redhat.com> 117133 117134 Document how GDB searches for files when using -s, -e, and -se options 117135 GDB's documentation of the 'file' command says: 117136 117137 If you do not specify a directory and the file is not found in the 117138 GDB working directory, GDB uses the environment variable PATH as a 117139 list of directories to search, just as the shell does when looking 117140 for a program to run. 117141 117142 The same is true for files specified via commandline options -s, -e, 117143 and -se. 117144 117145 This commit adds a cross reference to the file command for these options. 117146 1171472022-06-21 Nick Clifton <nickc@redhat.com> 117148 117149 Binutils support for dwarf-5 (location and range lists related) 117150 * dwarf.h (struct debug_info): Add rnglists_base field. 117151 * dwarf.c (read_and_display_attr_value): Read attribute DW_AT_rnglists_base. 117152 (display_debug_rnglists_list): While handling DW_RLE_base_addressx, 117153 DW_RLE_startx_endx, DW_RLE_startx_length items, pass the proper parameter 117154 value to fetch_indexed_addr(), i.e. fetch the proper entry in .debug_addr section. 117155 (display_debug_ranges): Add rnglists_base to the .debug_rnglists base address. 117156 (load_separate_debug_files): Load .debug_addr section, if exists. 117157 117158 Default to disabling the linker warnings about execstack and RWX segments if the target is the HPPA architecture. 117159 PR 29263 117160 * configure.ac (ac_default_ld_warn_execstack): Default to 'no' for 117161 HPPA targets. 117162 (ac_default_ld_warn_rwx_segments): Likewise. 117163 * configure: Regenerate. 117164 * testsuite/ld-elf/elf.exp: Add the --warn-execstack command line 117165 option to the command line when running execstack tests for the 117166 HPPA target. 117167 1171682022-06-21 GDB Administrator <gdbadmin@sourceware.org> 117169 117170 Automatic date update in version.in 117171 1171722022-06-20 Tom Tromey <tromey@adacore.com> 117173 117174 Move finish_print out of value_print_options 117175 'finish_print' does not really belong in value_print_options -- this 117176 is consulted only when deciding whether or not to print a value, and 117177 never during the course of printing. This patch removes it from the 117178 structure and makes it a static global in infcmd.c instead. 117179 117180 Tested on x86-64 Fedora 34. 117181 1171822022-06-20 Alan Modra <amodra@gmail.com> 117183 117184 PR29262, memory leak in pr_function_type 117185 PR 29262 117186 * prdbg.c (pr_function_type): Free "s" on failure path. 117187 117188 PR29261, memory leak in parse_stab_struct_fields 117189 PR 29261 117190 * stabs.c (parse_stab_struct_fields): Free "fields" on failure path. 117191 1171922022-06-20 GDB Administrator <gdbadmin@sourceware.org> 117193 117194 Automatic date update in version.in 117195 1171962022-06-19 GDB Administrator <gdbadmin@sourceware.org> 117197 117198 Automatic date update in version.in 117199 1172002022-06-18 Tom Tromey <tom@tromey.com> 117201 117202 Fix assertion failure in copy_type 117203 PR exp/20630 points out a simple way to cause an assertion failure in 117204 copy_type -- but this was found in the wild a few times as well. 117205 117206 copy_type only works for objfile-owned types, but there isn't a deep 117207 reason for this. This patch fixes the bug by updating copy_type to 117208 work for any sort of type. 117209 117210 Better would perhaps be to finally implement type GC, but I still 117211 haven't attempted this. 117212 117213 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20630 117214 1172152022-06-18 Tomoaki Kawada <kawada@kmckk.co.jp> 117216 117217 Fix the sorting algorithm for reloc entries 117218 The optimized insertion sort algorithm in `elf_link_adjust_relocs` 117219 incorrectly assembled "runs" from unsorted entries and inserted them to an 117220 already-sorted prefix, breaking the loop invariants of insertion sort. 117221 This commit updates the run assembly loop to break upon encountering a 117222 non-monotonic change in the sort key. 117223 117224 PR 29259 117225 bfd/ 117226 * elflink.c (elf_link_adjust_relocs): Ensure run being inserted 117227 is sorted. 117228 ld/ 117229 * testsuite/ld-elf/pr29259.d, 117230 * testsuite/ld-elf/pr29259.s, 117231 * testsuite/ld-elf/pr29259.t: New test. 117232 1172332022-06-18 Enze Li <enze.li@hotmail.com> 117234 117235 gdb/python: Export nibbles to python layer 117236 This patch makes it possible to allow Value.format_string() to return 117237 nibbles output. 117238 117239 When we set the parameter of nibbles to True, we can achieve the 117240 displaying binary values in groups of every four bits. 117241 117242 Here's an example: 117243 (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True)) 117244 0100 1100 1110 117245 (gdb) 117246 117247 Note that the parameter nibbles is only useful if format='t' is also used. 117248 117249 This patch also includes update to the relevant testcase and 117250 documentation. 117251 117252 Tested on x86_64 openSUSE Tumbleweed. 117253 1172542022-06-18 Enze Li <enze.li@hotmail.com> 117255 117256 gdb/doc: Documentation for the new print command 117257 Document the new command "print nibbles" and add a NEWS entry. 117258 1172592022-06-18 Enze Li <enze.li@hotmail.com> 117260 117261 gdb: Add new 'print nibbles' feature 117262 Make an introduction of a new print setting that can be set by 'set 117263 print nibbles [on|off]'. The default value if OFF, which can be changed 117264 by user manually. Of course, 'show print nibbles' is also included in 117265 the patch. 117266 117267 The new feature displays binary values by group, with four bits per 117268 group. The motivation for this work is to enhance the readability of 117269 binary values. 117270 117271 Here's a GDB session before this patch is applied. 117272 (gdb) print var_a 117273 $1 = 1230 117274 (gdb) print/t var_a 117275 $2 = 10011001110 117276 117277 With this patch applied, we can use the new print setting to display the 117278 new form of the binary values. 117279 (gdb) print var_a 117280 $1 = 1230 117281 (gdb) print/t var_a 117282 $2 = 10011001110 117283 (gdb) set print nibbles on 117284 (gdb) print/t var_a 117285 $3 = 0100 1100 1110 117286 117287 Tested on x86_64 openSUSE Tumbleweed. 117288 1172892022-06-18 GDB Administrator <gdbadmin@sourceware.org> 117290 117291 Automatic date update in version.in 117292 1172932022-06-17 Tiezhu Yang <yangtiezhu@loongson.cn> 117294 117295 gdb: NEWS: Move LoongArch gdbserver to the correct section 117296 commit e5ab6af52d38 ("gdbserver: Add LoongArch/Linux support") 117297 was merged into the master since GDB 12, so we should put the 117298 news in the "Changes since GDB 12" section. 117299 117300 Thanks Tom Tromey for your correction [1], sorry for that. 117301 117302 [1] https://sourceware.org/pipermail/gdb-patches/2022-June/190122.html 117303 1173042022-06-17 Alan Modra <amodra@gmail.com> 117305 117306 PR29256, memory leak in obj_elf_section_name 117307 When handling section names in quotes obj_elf_section_name calls 117308 demand_copy_C_string, which puts the name on the gas notes obstack. 117309 Such strings aren't usually freed, since obstack_free frees all more 117310 recently allocated objects as well as its arg. When handling 117311 non-quoted names, obj_elf_section_name mallocs the name. Due to the 117312 mix of allocation strategies it isn't possible for callers to free 117313 names, if that was desirable. Partially fix this by always creating 117314 names on the obstack, which is more efficient anyway. (You still 117315 can't obstack_free on error paths due to the xtensa 117316 tc_canonicalize_section_name.) Also remove a couple of cases where 117317 the name is dup'd for no good reason as far as I know. 117318 117319 PR 29256 117320 * config/obj-elf.c (obj_elf_section_name): Create name on notes 117321 obstack. 117322 (obj_elf_attach_to_group): Don't strdup group name. 117323 (obj_elf_section): Likewise. 117324 (obj_elf_vendor_attribute): Use xmemdup0 rather than xstrndup. 117325 1173262022-06-17 Alan Modra <amodra@gmail.com> 117327 117328 PR29255, memory leak in make_tempdir 117329 PR 29255 117330 * bucomm.c (make_tempdir, make_tempname): Free template on all 117331 failure paths. 117332 117333 PR29254, memory leak in stab_demangle_v3_arg 117334 PR 29254 117335 * stabs.c (stab_demangle_v3_arg): Free dt on failure path. 117336 1173372022-06-17 Pedro Alves <pedro@palves.net> 117338 117339 Fix GDB build with GCC 4.8 & 4.9 117340 With gcc 4.8/4.9, we run into this build failure (and other similar 117341 ones): 117342 117343 /home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’ 117344 struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN}; 117345 ^ 117346 117347 The issue is that at around the GCC 4.8/4.9 era, a default member 117348 initializer prevented the struct from being an aggregate, so you 117349 cannot use aggregate initialization on them. That rule changed after 117350 GCC 4.9 and GCC 5 & later uses new rules. 117351 117352 Fix this by not using aggregate initialization for struct line_offset. 117353 The default member initization already leaves line_offset as {0, 117354 LINE_OFFSET_UNKNOWN}, so initialization to those values can just go 117355 away. The remaining cases are of the form {0, LINE_OFFSET_NONE}, and 117356 those cases can be better rewritten to delay setting the sign field 117357 until we know we have a valid offset. 117358 117359 Change-Id: I0506ea4a83c5fa2f15e159569db68b3b0a7509b4 117360 1173612022-06-17 Pedro Alves <pedro@palves.net> 117362 117363 Convert set_location_spec_string to a method 117364 This converts set_location_spec_string to a method of location_spec, 117365 and makes the location_spec::as_string field protected, renaming it to 117366 m_as_string along the way. 117367 117368 Change-Id: Iccfb1654e9fa7808d0512df89e775f9eacaeb9e0 117369 1173702022-06-17 Pedro Alves <pedro@palves.net> 117371 117372 Convert location_spec_to_string to a method 117373 This converts location_spec_to_string to a method of location_spec, 117374 simplifying the code using it, as it no longer has to use 117375 std::unique_ptr::get(). 117376 117377 Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5 117378 1173792022-06-17 Pedro Alves <pedro@palves.net> 117380 117381 Convert location_spec_type to a method 117382 This converts location_spec_type to location_spec::type(). 117383 117384 Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273 117385 1173862022-06-17 Pedro Alves <pedro@palves.net> 117387 117388 Convert location_spec_empty_p to a method 117389 This converts location_spec_empty_p to a method of location_spec, 117390 simplifying users, as they no longer have to use 117391 std::unique_ptr::get(). 117392 117393 Change-Id: I83381a729896f12e1c5a1b4d6d4c2eb1eb6582ff 117394 1173952022-06-17 Pedro Alves <pedro@palves.net> 117396 117397 Eliminate copy_location_spec 117398 copy_location_spec is just a wrapper around location_spec::clone(), so 117399 remove it and call clone() directly. This simplifies users, as they 117400 no longer have to use std::unique_ptr::get(). 117401 117402 Change-Id: I8ce8658589460b98888283b306b315a5b8f73976 117403 1174042022-06-17 Pedro Alves <pedro@palves.net> 117405 117406 Eliminate the two-level data structures behind location_specs 117407 Currently, there's the location_spec hierarchy, and then some 117408 location_spec subclasses have their own struct type holding all their 117409 data fields. 117410 117411 I.e., there is this: 117412 117413 location_spec 117414 explicit_location_spec 117415 linespec_location_spec 117416 address_location_spec 117417 probe_location_spec 117418 117419 and then these separate types: 117420 117421 explicit_location 117422 linespec_location 117423 117424 where: 117425 117426 explicit_location_spec 117427 has-a explicit_location 117428 linespec_location_spec 117429 has-a linespec_location 117430 117431 This patch eliminates explicit_location and linespec_location, 117432 inlining their members in the corresponding location_spec type. 117433 117434 The location_spec subclasses were the ones currently defined in 117435 location.c, so they are moved to the header. Since the definitions of 117436 the classes are now visible, we no longer need location_spec_deleter. 117437 117438 Some constructors that are used for cloning location_specs, like: 117439 117440 explicit explicit_location_spec (const struct explicit_location *loc) 117441 117442 ... were converted to proper copy ctors. 117443 117444 In the process, initialize_explicit_location is eliminated, and some 117445 functions that returned the "data type behind a locspec", like 117446 get_linespec_location are converted to downcast functions, like 117447 as_linespec_location_spec. 117448 117449 Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a 117450 1174512022-06-17 Pedro Alves <pedro@palves.net> 117452 117453 event_location -> location_spec 117454 Currently, GDB internally uses the term "location" for both the 117455 location specification the user input (linespec, explicit location, or 117456 an address location), and for actual resolved locations, like the 117457 breakpoint locations, or the result of decoding a location spec to 117458 SaLs. This is expecially confusing in the breakpoints module, as 117459 struct breakpoint has these two fields: 117460 117461 breakpoint::location; 117462 breakpoint::loc; 117463 117464 "location" is the location spec, and "loc" is the resolved locations. 117465 117466 And then, we have a method called "locations()", which returns the 117467 resolved locations as range... 117468 117469 The location spec type is presently called event_location: 117470 117471 /* Location we used to set the breakpoint. */ 117472 event_location_up location; 117473 117474 and it is described like this: 117475 117476 /* The base class for all an event locations used to set a stop event 117477 in the inferior. */ 117478 117479 struct event_location 117480 { 117481 117482 and even that is incorrect... Location specs are used for finding 117483 actual locations in the program in scenarios that have nothing to do 117484 with stop events. E.g., "list" works with location specs. 117485 117486 To clean all this confusion up, this patch renames "event_location" to 117487 "location_spec" throughout, and then all the variables that hold a 117488 location spec, they are renamed to include "spec" in their name, like 117489 e.g., "location" -> "locspec". Similarly, functions that work with 117490 location specs, and currently have just "location" in their name are 117491 renamed to include "spec" in their name too. 117492 117493 Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca 117494 1174952022-06-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 117496 117497 gprofng: fix build with -Werror=format-truncation 117498 gprofng/ChangeLog 117499 2022-06-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 117500 117501 * configure.ac: Remove -Wno-format-truncation. 117502 * src/Makefile.am: Likewise. 117503 * configure: Rebuild. 117504 * src/Makefile.in: Rebuild. 117505 * common/hwctable.c: Fix -Werror=format-truncation errors. 117506 * src/ipc.cc: Likewise. 117507 * src/parse.cc: Likewise. 117508 1175092022-06-17 GDB Administrator <gdbadmin@sourceware.org> 117510 117511 Automatic date update in version.in 117512 1175132022-06-16 Tom de Vries <tdevries@suse.de> 117514 117515 [gdb/testsuite] Fix have_mpx test 117516 When testing on openSUSE Leap 15.4 I ran into this FAIL: 117517 ... 117518 FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer 117519 ... 117520 and likewise for all the other mpx tests. 117521 117522 The problem is that have_mpx is supposed to return 0, but it doesn't because 117523 it tries to match this output: 117524 ... 117525 builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M 117526 No MPX support^M 117527 No MPX support^M 117528 ... 117529 using: 117530 ... 117531 && ![string equal $output "No MPX support\r\n"]] 117532 ... 117533 117534 Fix this by matching using a regexp instead. 117535 117536 Tested on x86_64-linux. 117537 1175382022-06-16 Alan Modra <amodra@gmail.com> 117539 117540 use of uninitialised value in input_file_open 117541 Triggered by a file containing just "#N" or "#A". fgets when hitting 117542 EOF before reading anything returns NULL and does not write to buf. 117543 strchr (buf, '\n') then is reading from uninitialised memory. 117544 117545 * input-file.c (input_file_open): Don't assume buf contains 117546 zero string terminator when fgets returns NULL. 117547 1175482022-06-16 Alan Modra <amodra@gmail.com> 117549 117550 Always free matching vector from bfd_check_format_matches 117551 At least one place calling list_matching_formats failed to free the 117552 "matching" vector from bfd_check_format_matches afterwards. Fix that 117553 by calling free inside list_matching_formats. 117554 117555 binutils/ 117556 * bucomm.c (list_matching_formats): Free arg. 117557 * addr2line.c (process_file): Adjust to suit. 117558 * ar.c (open_inarch, ranlib_touch): Likewise. 117559 * coffdump.c (main): Likewise. 117560 * nm.c (display_archive, display_file): Likewise. 117561 * objcopy.c (copy_file): Likewise. 117562 * objdump.c (display_object_bfd): Likewise. 117563 * size.c (display_bfd): Likewise. 117564 * srconv.c (main): Likewise. 117565 ld/ 117566 * ldlang.c (load_symbols): Free "matching". 117567 1175682022-06-16 Alan Modra <amodra@gmail.com> 117569 117570 Revert "Revert "Fix fbsd core matching"" 117571 This reverts commit 476288fa2bddecf0f0e13dee826a076309bf01fe. 117572 1175732022-06-16 Alan Modra <amodra@gmail.com> 117574 117575 Restore readelf -wF 117576 Commit 94585d6d4495 resulted in readelf -wF failing with 117577 Unrecognized debug letter option 'F' 117578 117579 binutils/ 117580 * dwarf.c (debug_dump_long_opts): Add letter. 117581 (debug_option_table): New, replacing.. 117582 (opts_table, letter_table): ..these. 117583 (dwarf_select_sections_by_names): Adjust to suit. Set 117584 do_debug_frames outside of loop. 117585 (dwarf_select_sections_by_letters): Similarly. 117586 gas/ 117587 * testsuite/gas/i386/ehinterp.d: Use readelf -wF. 117588 1175892022-06-16 Alan Modra <amodra@gmail.com> 117590 117591 PR29250, readelf erases CIE initial register state 117592 PR 29250 117593 binutils/ 117594 * dwarf.c (display_debug_frames): Set col_type[reg] on sizing 117595 pass over FDE to cie->col_type[reg] if CIE specifies reg. 117596 Handle DW_CFA_restore and DW_CFA_restore_extended on second 117597 pass using the same logic. Remove unnecessary casts. Don't 117598 call frame_need_space on second pass over FDE. 117599 gas/ 117600 * testsuite/gas/i386/ehinterp.d, 117601 * testsuite/gas/i386/ehinterp.s: New test. 117602 * testsuite/gas/i386/i386.exp: Run it. 117603 1176042022-06-16 GDB Administrator <gdbadmin@sourceware.org> 117605 117606 Automatic date update in version.in 117607 1176082022-06-15 Sergei Trofimovich <siarheit@google.com> 117609 117610 sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184] 117611 Noticed format mismatch when attempted to build gdb on i686-linux-gnu 117612 in --enable-64-bit-bfd mode: 117613 117614 sim/../../sim/cris/sim-if.c:576:28: 117615 error: format '%lx' expects argument of type 'long unsigned int', 117616 but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=] 117617 576 | sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx", 117618 | ^~~~~~~~~~~~~~~~~~~ 117619 577 | interp_load_addr, interpsiz); 117620 | ~~~~~~~~~ 117621 | | 117622 | bfd_size_type {aka long long unsigned int} 117623 117624 While at it fixed format string for time-related types. 117625 1176262022-06-15 Tom Tromey <tromey@adacore.com> 117627 117628 Check for listeners in emit_exiting_event 117629 I noticed that emit_exiting_event does not check whether there are any 117630 listeners before creating the event object. All other event emitters 117631 do this, so this patch updates this one as well. 117632 1176332022-06-15 Tom Tromey <tom@tromey.com> 117634 117635 Add to documentation of Python 'dont_repeat' method 117636 PR python/28533 points out that the Python 'dont_repeat' documentation 117637 is a bit ambiguous about when the method ought to be called. This 117638 patch spells it out. 117639 1176402022-06-15 Yvan Roux <yvan.roux@foss.st.com> 117641 117642 gdb/arm: Make sp alias for one of the other stack pointers 117643 For Cortex-M targets, SP register is never detached from msp or 117644 psp, it always has the same value as one of them. Let GDB treat 117645 ARM_SP_REGNUM as an alias similar to what is done in hardware. 117646 1176472022-06-15 Yvan Roux <yvan.roux@foss.st.com> 117648 117649 gdb/arm: Track msp and psp 117650 For Arm Cortex-M33 with security extensions, there are 4 different 117651 stack pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible 117652 with earlier Cortex-M derivates, the msp and psp registers are 117653 aliases for one of the 4 real stack pointer registers. 117654 117655 These are the combinations that exist: 117656 sp -> msp -> msp_s 117657 sp -> msp -> msp_ns 117658 sp -> psp -> psp_s 117659 sp -> psp -> psp_ns 117660 117661 This means that when the GDB client is to show the value of "msp", 117662 the value should always be equal to either "msp_s" or "msp_ns". 117663 Same goes for "psp". 117664 117665 To add a bit more context; GDB does not really use the register msp 117666 (or psp) internally, but they are part of the set of registers which 117667 are provided by the target.xml file. As a result, they will be part 117668 of the set of registers printed by the "info r" command. 117669 117670 Without this particular patch, GDB will hit the assert in the bottom 117671 of arm_cache_get_sp_register function. 117672 117673 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121 117674 1176752022-06-15 Yvan Roux <yvan.roux@foss.st.com> 117676 117677 gdb/arm: Fetch initial sp value prior to compare 117678 For Arm Cortex-M33 with security extensions, there are 4 different 117679 stack pointers (msp_s, msp_ns, psp_s, psp_ns). In order to 117680 identify the active one, compare the values of the different 117681 stacks. The value of the initial sp register needs to be fetched to 117682 perform this comparison. 117683 1176842022-06-15 Andrew Burgess <aburgess@redhat.com> 117685 117686 gdb: unify two dis_asm_read_memory functions in disasm.c 117687 After the recent restructuring of the disassembler code, GDB has ended 117688 up with two identical class static functions, both called 117689 dis_asm_read_memory, with identical implementations. 117690 117691 My first thought was to move these out of their respective classes, 117692 and just make them global functions, then I'd only need a single 117693 copy. 117694 117695 And maybe that's the right way to go. But I disliked that by doing 117696 that I loose the encapsulation of the method with the corresponding 117697 disassembler class. 117698 117699 So, instead, I placed the static method into its own class, and had 117700 both the gdb_non_printing_memory_disassembler and gdb_disassembler 117701 classes inherit from this new class as an additional base-class. 117702 117703 In terms of code generated, I don't think there's any significant 117704 difference with this approach, but I think this better reflects how 117705 the function is closely tied to the disassembler. 117706 117707 There should be no user visible changes after this commit. 117708 1177092022-06-15 Andrew Burgess <aburgess@redhat.com> 117710 117711 gdb: refactor the non-printing disassemblers 117712 This commit started from an observation I made while working on some 117713 other disassembler patches, that is, that the function 117714 gdb_buffered_insn_length, is broken ... sort of. 117715 117716 I noticed that the gdb_buffered_insn_length function doesn't set up 117717 the application data field if the disassemble_info structure. 117718 117719 Further, I noticed that some architectures, for example, ARM, require 117720 that the application_data field be set, see gdb_print_insn_arm in 117721 arm-tdep.c. 117722 117723 And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will 117724 likely crash. Which is why I said only "sort of" broken. Right now 117725 we don't use gdb_buffered_insn_length with ARM, so maybe it isn't 117726 broken yet? 117727 117728 Anyway to prove to myself that there was a problem here I extended the 117729 disassembler self tests in disasm-selftests.c to include a test of 117730 gdb_buffered_insn_length. As I run the test for all architectures, I 117731 do indeed see GDB crash for ARM. 117732 117733 To fix this we need gdb_buffered_insn_length to create a disassembler 117734 that inherits from gdb_disassemble_info, but we also need this new 117735 disassembler to not print anything. 117736 117737 And so, I introduce a new gdb_non_printing_disassembler class, this is 117738 a disassembler that doesn't print anything to the output stream. 117739 117740 I then observed that both ARC and S12Z also create non-printing 117741 disassemblers, but these are slightly different. While the 117742 disassembler in gdb_non_printing_disassembler reads the instruction 117743 from a buffer, the ARC and S12Z disassemblers read from target memory 117744 using target_read_code. 117745 117746 And so, I further split gdb_non_printing_disassembler into two 117747 sub-classes, gdb_non_printing_memory_disassembler and 117748 gdb_non_printing_buffer_disassembler. 117749 117750 The new selftests now pass, but otherwise, there should be no user 117751 visible changes after this commit. 117752 1177532022-06-15 Andrew Burgess <andrew.burgess@embecosm.com> 117754 117755 gdb/python: implement the print_insn extension language hook 117756 This commit extends the Python API to include disassembler support. 117757 117758 The motivation for this commit was to provide an API by which the user 117759 could write Python scripts that would augment the output of the 117760 disassembler. 117761 117762 To achieve this I have followed the model of the existing libopcodes 117763 disassembler, that is, instructions are disassembled one by one. This 117764 does restrict the type of things that it is possible to do from a 117765 Python script, i.e. all additional output has to fit on a single line, 117766 but this was all I needed, and creating something more complex would, 117767 I think, require greater changes to how GDB's internal disassembler 117768 operates. 117769 117770 The disassembler API is contained in the new gdb.disassembler module, 117771 which defines the following classes: 117772 117773 DisassembleInfo 117774 117775 Similar to libopcodes disassemble_info structure, has read-only 117776 properties: address, architecture, and progspace. And has methods: 117777 __init__, read_memory, and is_valid. 117778 117779 Each time GDB wants an instruction disassembled, an instance of 117780 this class is passed to a user written disassembler function, by 117781 reading the properties, and calling the methods (and other support 117782 methods in the gdb.disassembler module) the user can perform and 117783 return the disassembly. 117784 117785 Disassembler 117786 117787 This is a base-class which user written disassemblers should 117788 inherit from. This base class provides base implementations of 117789 __init__ and __call__ which the user written disassembler should 117790 override. 117791 117792 DisassemblerResult 117793 117794 This class can be used to hold the result of a call to the 117795 disassembler, it's really just a wrapper around a string (the text 117796 of the disassembled instruction) and a length (in bytes). The user 117797 can return an instance of this class from Disassembler.__call__ to 117798 represent the newly disassembled instruction. 117799 117800 The gdb.disassembler module also provides the following functions: 117801 117802 register_disassembler 117803 117804 This function registers an instance of a Disassembler sub-class 117805 as a disassembler, either for one specific architecture, or, as a 117806 global disassembler for all architectures. 117807 117808 builtin_disassemble 117809 117810 This provides access to GDB's builtin disassembler. A common 117811 use case that I see is augmenting the existing disassembler output. 117812 The user code can call this function to have GDB disassemble the 117813 instruction in the normal way. The user gets back a 117814 DisassemblerResult object, which they can then read in order to 117815 augment the disassembler output in any way they wish. 117816 117817 This function also provides a mechanism to intercept the 117818 disassemblers reads of memory, thus the user can adjust what GDB 117819 sees when it is disassembling. 117820 117821 The included documentation provides a more detailed description of the 117822 API. 117823 117824 There is also a new CLI command added: 117825 117826 maint info python-disassemblers 117827 117828 This command is defined in the Python gdb.disassemblers module, and 117829 can be used to list the currently registered Python disassemblers. 117830 1178312022-06-15 Andrew Burgess <andrew.burgess@embecosm.com> 117832 117833 gdb: add extension language print_insn hook 117834 This commit is setup for the next commit. 117835 117836 In the next commit I will add a Python API to intercept the print_insn 117837 calls within GDB, each print_insn call is responsible for 117838 disassembling, and printing one instruction. After the next commit it 117839 will be possible for a user to write Python code that either wraps 117840 around the existing disassembler, or even, in extreme situations, 117841 entirely replaces the existing disassembler. 117842 117843 This commit does not add any new Python API. 117844 117845 What this commit does is put the extension language framework in place 117846 for a print_insn hook. There's a new callback added to 'struct 117847 extension_language_ops', which is then filled in with nullptr for Python 117848 and Guile. 117849 117850 Finally, in the disassembler, the code is restructured so that the new 117851 extension language function ext_lang_print_insn is called before we 117852 delegate to gdbarch_print_insn. 117853 117854 After this, the next commit can focus entirely on providing a Python 117855 implementation of the new print_insn callback. 117856 117857 There should be no user visible change after this commit. 117858 1178592022-06-15 Andrew Burgess <andrew.burgess@embecosm.com> 117860 117861 gdb: add new base class to gdb_disassembler 117862 The motivation for this change is an upcoming Python disassembler API 117863 that I would like to add. As part of that change I need to create a 117864 new disassembler like class that contains a disassemble_info and a 117865 gdbarch. The management of these two objects is identical to how we 117866 manage these objects within gdb_disassembler, so it might be tempting 117867 for my new class to inherit from gdb_disassembler. 117868 117869 The problem however, is that gdb_disassembler has a tight connection 117870 between its constructor, and its print_insn method. In the 117871 constructor the ui_file* that is passed in is replaced with a member 117872 variable string_file*, and then in print_insn, the contents of the 117873 member variable string_file are printed to the original ui_file*. 117874 117875 What this means is that the gdb_disassembler class has a tight 117876 coupling between its constructor and print_insn; the class just isn't 117877 intended to be used in a situation where print_insn is not going to be 117878 called, which is how my (upcoming) sub-class would need to operate. 117879 117880 My solution then, is to separate out the management of the 117881 disassemble_info and gdbarch into a new gdb_disassemble_info class, 117882 and make this class a parent of gdb_disassembler. 117883 117884 In arm-tdep.c and mips-tdep.c, where we used to cast the 117885 disassemble_info->application_data to a gdb_disassembler, we can now 117886 cast to a gdb_disassemble_info as we only need to access the gdbarch 117887 information. 117888 117889 Now, my new Python disassembler sub-class will still want to print 117890 things to an output stream, and so we will want access to the 117891 dis_asm_fprintf functionality for printing. 117892 117893 However, rather than move this printing code into the 117894 gdb_disassemble_info base class, I have added yet another level of 117895 hierarchy, a gdb_printing_disassembler, thus the class structure is 117896 now: 117897 117898 struct gdb_disassemble_info {}; 117899 struct gdb_printing_disassembler : public gdb_disassemble_info {}; 117900 struct gdb_disassembler : public gdb_printing_disassembler {}; 117901 117902 In a later commit my new Python disassembler will inherit from 117903 gdb_printing_disassembler. 117904 117905 The reason for adding the additional layer to the class hierarchy is 117906 that in yet another commit I intend to rewrite the function 117907 gdb_buffered_insn_length, and to do this I will be creating yet more 117908 disassembler like classes, however, these will not print anything, 117909 thus I will add a gdb_non_printing_disassembler class that also 117910 inherits from gdb_disassemble_info. Knowing that that change is 117911 coming, I've gone with the above class hierarchy now. 117912 117913 There should be no user visible changes after this commit. 117914 1179152022-06-15 Andrew Burgess <aburgess@redhat.com> 117916 117917 gdb/python: convert gdbpy_err_fetch to use gdbpy_ref 117918 Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this 117919 removes the need for manual reference count management, and allows the 117920 destructor to be removed. 117921 117922 There should be no functional change after this commit. 117923 117924 I think this cleanup is worth doing on its own, however, in a later 117925 commit I will want to copy instances of gdbpy_err_fetch, and switching 117926 to using gdbpy_ref means that I can rely on the default copy 117927 constructor, without having to add one that handles the reference 117928 counts, so this is good preparation for that upcoming change. 117929 1179302022-06-15 Jan Beulich <jbeulich@suse.com> 117931 117932 x86: drop print_operand_value()'s "hex" parameter 117933 For quite some time all callers have been passing 1 / true. While there 117934 fold the final oappend_with_style() calls. 117935 1179362022-06-15 Tom de Vries <tdevries@suse.de> 117937 117938 [gdb/build] Fix build for gcc < 11 117939 When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into: 117940 ... 117941 In file included from ../bfd/bfd.h:46:0, 117942 from gdb/defs.h:37, 117943 from gdb/debuginfod-support.c:19: 117944 gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’: 117945 gdb/../include/diagnostics.h:42:3: error: unknown option after \ 117946 ‘#pragma GCC diagnostic’ kind [-Werror=pragmas] 117947 _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option)) 117948 ^ 117949 gdb/../include/diagnostics.h:80:3: note: in expansion of macro \ 117950 ‘DIAGNOSTIC_IGNORE’ 117951 DIAGNOSTIC_IGNORE ("-Wstringop-overread") 117952 ^~~~~~~~~~~~~~~~~ 117953 gdb/debuginfod-support.c:201:4: note: in expansion of macro \ 117954 ‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’ 117955 DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD 117956 ^ 117957 ... 117958 117959 The problem is that the warning -Wstringop-overread has been introduced for 117960 gcc 11, and we can only tell gcc to ignore if it knows about it. 117961 117962 Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in 117963 diagnostics.c with '#if __GNUC__ >= 11'. 117964 117965 Tested on x86_64-linux, by completing a build. 117966 1179672022-06-15 Alan Modra <amodra@gmail.com> 117968 117969 PR29230, segv in lookup_symbol_in_variable_table 117970 The PR23230 testcase uses indexed strings without specifying 117971 SW_AT_str_offsets_base. In this case we left u.str with garbage (from 117972 u.val) which then led to a segfault when attempting to access the 117973 string. Fix that by clearing u.str. The patch also adds missing 117974 sanity checks in the recently committed read_indexed_address and 117975 read_indexed_string functions. 117976 117977 PR 29230 117978 * dwarf2.c (read_indexed_address): Return uint64_t. Sanity check idx. 117979 (read_indexed_string): Use uint64_t for str_offset. Sanity check idx. 117980 (read_attribute_value): Clear u.str for indexed string forms when 117981 DW_AT_str_offsets_base is not yet read or missing. 117982 1179832022-06-15 Mark Wielaard <mark@klomp.org> 117984 117985 gdb: Always suppress stringop-overread warning in debuginfod-support.c 117986 Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11 117987 on hppa produces a spurious warning for stringop-overread in 117988 debuginfod_is_enabled for url_view. Just always suppress it on all 117989 arches. 117990 117991 https://sourceware.org/bugzilla/show_bug.cgi?id=29198 117992 117993 gdb/ChangeLog: 117994 117995 * debuginfod-support.c (debuginfod_is_enabled): Always use 117996 DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD. 117997 1179982022-06-15 GDB Administrator <gdbadmin@sourceware.org> 117999 118000 Automatic date update in version.in 118001 1180022022-06-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 118003 118004 gprofng docs: provide help for <rate> == <interval> 118005 The help message from 'gprofng collect app -h', in 118006 the section on <rate> == <interval>, had a dangling 118007 reference to a non-existent manpage. Provide basic 118008 info, including reasons for caution. 118009 118010 gprofng docs: mention HTML / PDF in the gprofng README 118011 The HTML and PDF formats are described in the gprofng tutorial (info 118012 topic "Other Document Formats"). In addition, describe them in the 118013 README because: they are important; they are easily searchable; and the 118014 README is primarily oriented to the person who is installing gprofng, 118015 who may differ from the person who follows a user tutorial. 118016 1180172022-06-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 118018 118019 gprofng: fix build with -Werror=format-security 118020 gprofng/ChangeLog 118021 2022-06-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 118022 118023 PR gprofng/28968 118024 * src/src/Hist_data.cc (print_row): Make param const. 118025 * src/src/Hist_data.h (print_row): Likewise. 118026 * src/src/Print.h: Remove unused functions and variables. 118027 * src/Print.cc: Fix -Werror=format-security errors. 118028 * src/parse.cc: Likewise. 118029 1180302022-06-14 Tom de Vries <tdevries@suse.de> 118031 118032 [gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp 118033 When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with 118034 python 3.4, I occasionally run into: 118035 ... 118036 Expecting: ^(-pycmd dct[^M 118037 ]+)?(\^done,result={hello="world",times="42"}[^M 118038 ]+[(]gdb[)] ^M 118039 [ ]*) 118040 -pycmd dct^M 118041 ^done,result={times="42",hello="world"}^M 118042 (gdb) ^M 118043 FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output) 118044 ... 118045 118046 The problem is that the data type used here in py-mi-cmd.py: 118047 ... 118048 elif argv[0] == "dct": 118049 return {"result": {"hello": "world", "times": 42}} 118050 ... 118051 is a dictionary, and only starting version 3.6 are dictionaries insertion 118052 ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a 118053 fixed order. 118054 118055 Fix this by allowing the alternative order. 118056 118057 Tested on x86_64-linux. 118058 1180592022-06-14 Tom Tromey <tromey@adacore.com> 118060 118061 Implement lazy FPU initialization for ravenscar 118062 Some ravenscar runtimes implement lazy FPU handling. On these 118063 runtimes, the FPU is only initialized when a task tries to use it. 118064 Furthermore, the FP registers aren't automatically saved on a task 118065 switch -- instead, the save is deferred until the new task tries to 118066 use the FPU. Furthermore, each task's context area has a flag 118067 indicating whether the FPU has been initialized for this task. 118068 118069 This patch teaches GDB to understand this implementation. When 118070 fetching or storing registers, GDB now checks to see whether the live 118071 FP registers should be used. If not, the task's saved FP registers 118072 will be used if the task has caused FPU initialization. 118073 118074 Currently only AArch64 uses this code. bb-runtimes implements this 118075 for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c. 118076 1180772022-06-14 Tom Tromey <tromey@adacore.com> 118078 118079 Reimplement ravenscar registers using tables 118080 Currently, the ravenscar-thread implementation for each architecture 118081 is written by hand. However, these are actually written by 118082 copy-paste. It seems better to switch to a table-driven approach. 118083 118084 The previous code also fetched all registers whenever any register was 118085 requested. This is corrected in the new implementation. 118086 1180872022-06-14 Tom Tromey <tromey@adacore.com> 118088 118089 Fix bugs in aarch64-ravenscar-thread.c 118090 We found a few bugs in aarch64-ravenscar-thread.c. 118091 118092 First, some of the register offsets were incorrect. The "bb-runtimes" 118093 file for this runtime had the wrong offsets in comments, which GDB 118094 took to be correct. However, those comments didn't account for 118095 alignment. This patch adjusts the offsets. 118096 118097 Next, the "FPU Saved field" is not a register -- it is an 118098 implementation detail of the runtime. This is removed. 118099 118100 Finally, I think the FP registers are actually named V0-V31, and the 118101 "Q" names are pseudo-registers. This patch fixes the comment. 118102 1181032022-06-14 Tom Tromey <tromey@adacore.com> 118104 118105 Allow 'interrupt -a' in all-stop mode 118106 PR gdb/17160 points out that "interrupt -a" errors in all-stop mode, 118107 but there's no good reason for this. This patch removes the error. 118108 118109 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17160 118110 1181112022-06-14 Youling Tang <tangyouling@loongson.cn> 118112 118113 gdbserver: Add LoongArch/Linux support 118114 Implement LoongArch/Linux support, including XML target description 118115 handling based on features determined, GPR regset support, and software 118116 breakpoint handling. 118117 118118 In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR 118119 and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is 118120 set to yes. 118121 118122 With this patch on LoongArch: 118123 118124 $ make check-gdb TESTS="gdb.server/server-connect.exp" 118125 [...] 118126 # of expected passes 18 118127 [...] 118128 1181292022-06-14 Tom de Vries <tdevries@suse.de> 118130 118131 Revert "Fix fbsd core matching" 118132 This reverts commit a7e29f797cecd5a2f73c27838b09eae1f1b6c657. 118133 118134 I accidentally pushed this, so revert. 118135 1181362022-06-14 Tom de Vries <tdevries@suse.de> 118137 118138 [gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp 118139 With gcc-12 and target board unix/-m32, we run into: 118140 ... 118141 (gdb) ^M 118142 Expecting: ^(-var-create A_String_Access \* A_String_Access[^M 118143 ]+)?(\^done,name="A_String_Access",numchild="1",.*[^M 118144 ]+[(]gdb[)] ^M 118145 [ ]*) 118146 -var-create A_String_Access * A_String_Access^M 118147 ^error,msg="Value out of range."^M 118148 (gdb) ^M 118149 FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) 118150 ... 118151 118152 What happens is easier to understand if we take things out of the mi context: 118153 ... 118154 $ gdb -q -batch \ 118155 outputs/gdb.ada/mi_var_access/mi_access \ 118156 -ex "b mi_access.adb:19" \ 118157 -ex run \ 118158 -ex "p A_String_Access" 118159 ... 118160 Breakpoint 1, mi_access () at mi_access.adb:19 118161 19 A_String : String (3 .. 5) := "345"; -- STOP 118162 $1 = (pck.string_access) <error reading variable: Value out of range.> 118163 ... 118164 while with target board unix we have instead: 118165 ... 118166 $1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks> 118167 ... 118168 118169 The var-create command samples the value of the variable at a location where 118170 the variable is not yet initialized, and with target board unix we 118171 accidentally hit a valid address, but with target board unix/-m32 that's not 118172 the case. 118173 118174 Fix the FAIL by accepting the error message. 118175 118176 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28464 118177 1181782022-06-14 Alan Modra <amodra@gmail.com> 118179 118180 Fix fbsd core matching 118181 On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote: 118182 > On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote: 118183 > > Hi, 118184 > > 118185 > > With an --enable-targets=all build and target board unix/-m32 I run into a 118186 > > FAIL in test-case gdb.base/corefile.exp: 118187 > > ... 118188 > > (gdb) file outputs/gdb.base/corefile/corefile^M 118189 > > Reading symbols from outputs/gdb.base/corefile/corefile...^M 118190 > > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M 118191 > > warning: core file may not match specified executable file.^M 118192 > > [New LWP 12011]^M 118193 > > Core was generated by `outputs/gdb.base/corefile/co'.^M 118194 > > Program terminated with signal SIGABRT, Aborted.^M 118195 > > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free 118196 > > ... 118197 > > 118198 > > The warning is there because of this mismatch between core and exec: 118199 > > ... 118200 > > (gdb) p core_bfd->xvec 118201 > > $3 = (const struct bfd_target *) 0x20112a0 <i386_elf32_fbsd_vec> 118202 > > (gdb) p exec_bfd->xvec 118203 > > $4 = (const struct bfd_target *) 0x2010b00 <i386_elf32_vec> 118204 > > ... 118205 > > 118206 > > In the exec case, the detected architecture is i386_elf32_vec because this bit 118207 > > of code in elfcode.h:elf_object_p(): 118208 > > ... 118209 > > if (ebd->elf_machine_code != EM_NONE 118210 > > && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi 118211 > > && ebd->elf_osabi != ELFOSABI_NONE) 118212 > > goto got_wrong_format_error; 118213 > > ... 118214 > > prevents i386_elf32_fbsd from matching. 118215 > > 118216 > > Fix the core matching by copying that code to elfcore.h:elf_core_file_p(). 118217 > > 118218 > > Tested on x86_64-linux. 118219 > > 118220 > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227 118221 > > 118222 > > Any comments? 118223 118224 Looks good. 118225 118226 > Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over 118227 > time and is a bit rotted. I suspect that all of changes made in commit 0aabe54e6222 118228 > that added these lines in elfcode.h (along with several other changes) need to 118229 > be applied to this function in elfcore.h, not just adding these lines. 118230 118231 Yes, the commit 0aabe54e6222 changes likely should go in too. I'm a 118232 little wary of adding all the sanity checks to elf_core_file_p since 118233 that might result in some core files not being recognised at all. For 118234 example, despite the FIXME I'd guess leaving out the EI_VERSION check 118235 was deliberate. The following seems reasonable to me. Please test. 118236 1182372022-06-14 Kavitha Natarajan <kavitha.natarajan@amd.com> 118238 118239 Debug support for global alias variable 118240 Starting with (future) Clang 15 (since 118241 https://reviews.llvm.org/D120989), Clang emits the DWARF information 118242 of global alias variables as DW_TAG_imported_declaration. However, 118243 GDB does not handle it. It incorrectly always reads this tag as 118244 C++/Fortran imported declaration (type alias, namespace alias and 118245 Fortran module). This commit adds support to handle this tag as an 118246 alias variable. 118247 118248 This change fixes the failures in the gdb.base/symbol-alias.exp 118249 testcase with current git Clang. This testcase is also updated to 118250 test nested (recursive) aliases. 118251 1182522022-06-14 Alan Modra <amodra@gmail.com> 118253 118254 BFD_RELOC_MIPS_16 118255 MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation, 118256 since R_MIPS_16 specifies a 16-bit field in a 32-bit word. 118257 BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data 118258 directives, expects fixups to operate on the whole of a 16-bit word. 118259 118260 This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd 118261 reloc that is used to generate R_MIPS_16. BFD_RELOC_16 is handled in 118262 md_apply_fix for cases where the fixup can be applied at assembly 118263 time. Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object 118264 file relocation, and thus .half, .hword, .short and .dc.w must be 118265 resolved at assembly time. BFD_RELOC_MIPS_REL16 is removed by this 118266 patch since it isn't used. 118267 118268 PR 3243 118269 PR 26542 118270 * reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16. 118271 * elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16. 118272 * elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16. 118273 * elfn32-mips.c (mips_reloc_map): Likewise. 118274 * libbfd.h: Regenerate. 118275 * bfd-in2.h: Regenerate. 118276 gas/ 118277 * config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16. 118278 (macro_build): Likewise. 118279 (mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16. 118280 (md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done. 118281 ld/ 118282 * testsuite/ld-mips-elf/reloc-local-overflow.d, 118283 * testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite. 118284 1182852022-06-14 Alan Modra <amodra@gmail.com> 118286 118287 Correct R_MIPS_16 n32 howto 118288 If the howto is actually used, an all-zero dst_mask will result in 118289 unchanged section contents on attempting to apply R_MIPS_16. 118290 118291 * elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct 118292 dst_mask. 118293 1182942022-06-14 Alan Modra <amodra@gmail.com> 118295 118296 asan: applying zero offset to NULL pointer 118297 * dwarf.c (fetch_indexed_string): Move initialisation of "curr" 118298 and "end" after checking for missing section. 118299 1183002022-06-14 Alan Modra <amodra@gmail.com> 118301 118302 gas dwarf2dbg.c tidy 118303 Make it a little more obvious that remap_debug_filename returns an 118304 allocated string (that should be freed) by returning a char * rather 118305 than const char *. Free a few missed cases in dwarf2dbg.c, and free 118306 other memory allocated in dwarf2dbg.c. Also remove static 118307 initialisation of variables and initialise in dwarf2_init instead, 118308 in order to ensure gas state is saner for oss-fuzz. 118309 118310 * remap.c (remap_debug_filename): Remove const from return. 118311 * as.h (remap_debug_filename): Update prototype. 118312 * config/obj-elf.c (obj_elf_ident): Simplify free of 118313 remap_debug_filename output. 118314 * stabs.c (stabs_generate_asm_file): Likewise. 118315 * dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't 118316 initialise statically.. 118317 (dwarf2_init): ..do so here, along with most other static vars. 118318 (assign_file_to_slot): Don't set files_allocated until we 118319 succeed in allocating memory. 118320 (purge_generated_debug): Add bool param, free more stuff if true. 118321 (dwarf2_directive_filename): Adjust purge_generated_debug call. 118322 (process_entries): Don't free line_entry here.. 118323 (dwarf2_cleanup): ..do so here instead, new function. 118324 (dwarf2_finish): Call dwarf2_cleanup. When chaining together 118325 subseg line entries, unhook entries from old subseg list. 118326 (dwarf2_directive_loc): Free remap_debug_filename string. 118327 (out_dir_and_file_list): Likewise. 118328 (out_debug_str): Likewise. 118329 1183302022-06-14 GDB Administrator <gdbadmin@sourceware.org> 118331 118332 Automatic date update in version.in 118333 1183342022-06-13 Tom de Vries <tdevries@suse.de> 118335 118336 [gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo 118337 When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo 118338 installed, I run into: 118339 ... 118340 (gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call 118341 step^M 118342 __tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \ 118343 ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M 118344 45 {^M 118345 (gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW 118346 ... 118347 118348 The problem is that the step is expected to step over the call to tcsetattr, 118349 but due to glibc debuginfo being installed, we step into the call. 118350 118351 Fix this by using next instead of step. 118352 118353 Tested on x86_64-linux. 118354 1183552022-06-13 Tom de Vries <tdevries@suse.de> 118356 118357 [gdb] Avoid warnings in cooked_{read,write}_test for m68hc11 118358 With --enable-targets=all we have: 118359 ... 118360 $ gdb -q -batch -ex "maint selftest" 118361 ... 118362 Running selftest regcache::cooked_read_test::m68hc11. 118363 warning: No frame soft register found in the symbol table. 118364 Stack backtrace will not work. 118365 Running selftest regcache::cooked_read_test::m68hc12. 118366 warning: No frame soft register found in the symbol table. 118367 Stack backtrace will not work. 118368 Running selftest regcache::cooked_read_test::m68hc12:HCS12. 118369 warning: No frame soft register found in the symbol table. 118370 Stack backtrace will not work. 118371 ... 118372 118373 Likewise for regcache::cooked_write_test. 118374 118375 The warning has no use in the selftest context. 118376 118377 Fix this by skipping the specific selftests. 118378 118379 Tested on x86_64-linux. 118380 118381 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29224 118382 1183832022-06-13 Tiezhu Yang <yangtiezhu@loongson.cn> 118384 118385 gdb: LoongArch: Deal with atomic sequence 118386 We can't put a breakpoint in the middle of a ll/sc atomic sequence, 118387 so look for the end of the sequence and put the breakpoint there. 118388 1183892022-06-13 Sam James <sam@gentoo.org> 118390 118391 gdb: don't use bashism in configure test 118392 Results in configure output like: 118393 ``` 118394 checking for X... no 118395 /var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator 118396 checking whether to use babeltrace... auto 118397 ``` 118398 118399 ... when /bin/sh is provided by a POSIX-compliant shell, like dash, 118400 instead of bash. 118401 1184022022-06-13 Jiangshuai Li <jiangshuai_li@c-sky.com> 118403 118404 gdb:csky add support target-descriptions for CSKY arch 118405 Registers in CSKY architecture included: 118406 1. 32 gprs 118407 2. 16 ars (alternative gprs used for quick interrupt) 118408 3. hi, lo, pc 118409 4. fr0~fr31, fcsr, fid, fesr 118410 5. vr0~vr15 118411 6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank) 118412 118413 For register names: 118414 Except over control registers, other registers, like gprs, hi, lo ... 118415 are fixed names. Among the 32*32 control registers, some used registers 118416 will have fixed names, others will have a default name "cpxcry". 'x' 118417 refers to bank, y refers index in the bank(a control register in bank 118418 4 with index 14 will has a default name cp4cr14). 118419 118420 For register numbers in GDB: 118421 We assign a fixed number to each register in GDB, like: 118422 r0~r31 with 0~31 118423 hi, lo with 36, 37 118424 fpu/vpu with 40~71 118425 ... 118426 described in function csky_get_supported_register_by_index(). 118427 118428 Function csky_get_supported_tdesc_registers_count(): 118429 To calculate the total number of registers that GDB can analyze, 118430 including those with fixed names and those with default register names. 118431 118432 Function csky_get_supported_register_by_index(): 118433 To find a supported struct csky_supported_tdesc_register, return a 118434 struct include name with regnum via index. 118435 118436 Arrays csky_supported_tdesc_feature_names[]: 118437 Include all supported feature names in tdesc-xmls. 118438 118439 We use the information described above to load the register description 118440 file of the target from the stub. When loading, do a little check that 118441 whether the register description file contains SP, LR and PC. 118442 1184432022-06-13 Tom de Vries <tdevries@suse.de> 118444 118445 [gdb/testsuite] Handle quotes in gdb_py_module_available 118446 On openSUSE Leap 42.3 with python 3.4, I run into: 118447 ... 118448 (gdb) python import pygments^M 118449 Traceback (most recent call last):^M 118450 File "<string>", line 1, in <module>^M 118451 ImportError: No module named 'pygments'^M 118452 Error while executing Python code.^M 118453 (gdb) FAIL: gdb.base/style.exp: python import pygments 118454 ERROR: unexpected output from python import 118455 ... 118456 because gdb_py_module_available doesn't handle the single quotes around the 118457 module name in the ImportError. 118458 118459 Fix this by allowing the single quotes. 118460 118461 Tested on x86_64-linux. 118462 1184632022-06-13 Jan Beulich <jbeulich@suse.com> 118464 118465 x86: fix incorrect indirection 118466 Commit 384e201e5aec ("x86: properly initialize struct instr_info 118467 instance(s)") was based on an improperly refreshed patch. Correct the 118468 oversight. 118469 1184702022-06-13 Jan Beulich <jbeulich@suse.com> 118471 118472 x86: replace global scratch buffer 118473 With its movement to the stack, and with the subsequent desire to 118474 initialize the entire instr_info instances, this has become doubly 118475 inefficient. Individual users have better knowledge of how big a buffer 118476 they need, and in a number of cases going through an intermediate buffer 118477 can be avoided altogether. 118478 118479 Having got confirmation that it wasn't intentional to print memory 118480 operand displacements with inconsistent style, print_displacement() is 118481 now using dis_style_address_offset consistently (eliminating the need 118482 for callers to pass in a style). 118483 118484 While touching print_operand_value() also convert its "hex" parameter to 118485 bool. And while altering (and moving) oappend_immediate(), fold 118486 oappend_maybe_intel_with_style() into its only remaining caller. Finally 118487 where doing adjustments, use snprintf() in favor of sprintf(). 118488 1184892022-06-13 Jan Beulich <jbeulich@suse.com> 118490 118491 x86: avoid string copy when swapping Vex.W controlled operands 118492 Now that op_out[] is an array of pointers, there's no need anymore to 118493 copy strings. Simply swap the pointers. 118494 1184952022-06-13 Jan Beulich <jbeulich@suse.com> 118496 118497 x86: shrink prefix related disassembler state fields 118498 By changing the values used for "artificial" prefix values, 118499 all_prefixes[] can be shrunk to array of unsigned char. All that 118500 additionally needs adjusting is the printing of possible apparently 118501 standalone prefixes when recovering from longjmp(): Simply check 118502 whether any prefixes were successfully decoded, to avoid converting 118503 opcode bytes matching the "artificial" values to prefix mnemonics. 118504 118505 Similarly by re-arranging the bits assigned to PREFIX_* mask values 118506 we can fit all segment register masks in a byte and hence shrink 118507 active_seg_prefix to unsigned char. 118508 118509 Somewhat similarly with last_*_prefix representing offsets into the 118510 opcode being disassembled, signed char is sufficient to hold all possible 118511 values. 118512 1185132022-06-13 Jan Beulich <jbeulich@suse.com> 118514 118515 x86: properly initialize struct instr_info instance(s) 118516 Commit 39fb369834a3 ("opcodes: Make i386-dis.c thread-safe") introduced 118517 a lot of uninitialized data. Alan has in particular observed ubsan 118518 taking issue with the loop inverting the order of operands, where 118519 op_riprel[] - an array of bool - can hold values other than 0 or 1. 118520 118521 Move instantiation of struct instr_info into print_insn() (thus having 118522 just a single central point), and make use of C99 dedicated initializers 118523 to fill fields right in the initializer where possible. This way all 118524 fields not explicitly initialized will be zero-filled, which in turn 118525 allows dropping of some other explicit initialization later in the 118526 function or in ckprefix(). Additionally this removes a lot of 118527 indirection, as all "ins->info" uses can simply become "info". 118528 118529 Make one further arrangement though, to limit the amount of data needing 118530 (zero)initializing on every invocation: Convert the op_out structure 118531 member to just an array of pointers, with the actual arrays living 118532 inside print_insn() (and, as befoe, having just their 1st char filled 118533 with nul). 118534 118535 While there, instead of adjusting print_insn()'s forward declaration, 118536 arrange for no such declaration to be needed in the first place. 118537 1185382022-06-13 GDB Administrator <gdbadmin@sourceware.org> 118539 118540 Automatic date update in version.in 118541 1185422022-06-12 Tom Tromey <tom@tromey.com> 118543 118544 Fix self-test failure in addrmap 118545 Mark pointed out that my recent addrmap C++-ficiation changes caused a 118546 regression in the self-tests. This patch fixes the problem by 118547 updating this test not to allocate the mutable addrmap on an obstack. 118548 118549 Remove psymtab_addrmap 118550 While working on addrmaps, I noticed that psymtab_addrmap is no longer 118551 needed now. It was introduced in ancient times as an optimization for 118552 DWARF, but no other symbol reader was ever updated to use it. Now 118553 that DWARF does not use psymtabs, it can be deleted. 118554 118555 Use malloc for mutable addrmaps 118556 Mutable addrmaps currently require an obstack. This was probably done 118557 to avoid having to call splay_tree_delete, but examination of the code 118558 shows that all mutable obstacks have a limited lifetime -- now it's 118559 simple to treat them as ordinary C++ objects, in some cases 118560 stack-allocating them, and have a destructor to make the needed call. 118561 This patch implements this change. 118562 118563 Remove addrmap::create_fixed 118564 addrmap::create_fixed is just a simple wrapper for 'new', so remove it 118565 in favor of uses of 'new'. 118566 118567 Remove addrmap_create_mutable 118568 This removes addrmap_create_mutable in favor of using 'new' at the 118569 spots where the addrmap is created. 118570 118571 Remove addrmap wrapper functions 118572 This removes the various addrmap wrapper functions in favor of simple 118573 method calls on the objects themselves. 118574 118575 Move addrmap classes to addrmap.h 118576 This moves the addrmap class definitions to addrmap.h. This is safe 118577 to do now that the contents are private. 118578 118579 Privacy for addrmap_mutable 118580 This changes addrmap_mutable so that its data members are private. 118581 118582 Privacy for addrmap_fixed 118583 This changes addrmap_fixed so that its data members are private. 118584 It also makes struct addrmap_transition private as well. 118585 118586 Use inheritance for addrmap 118587 This is a simply C++-ification of the basics of addrmap: it uses 118588 virtual methods rather than a table of function pointers, and it 118589 changes the concrete implementations to be subclasses. 118590 1185912022-06-12 Jon Turney <jon.turney@dronecode.org.uk> 118592 118593 Trivial fixes to Cygwin build after 8fea1a81 118594 * Remove a stray semicolon 118595 * Restore dropped nullptr program argument in use of create_process() under CYGWIN 118596 118597 Simplify __USEWIDE 118598 Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not 118599 defined for Cygwin 1.5. After that, it's always defined if __CYGWIN__ 118600 is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals. 118601 118602 Simplify cygwin_buf_t 118603 Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was 118604 defined as char for Cygwin 1.5. After that, it's always wchar_t, so 118605 just use that. 118606 1186072022-06-12 GDB Administrator <gdbadmin@sourceware.org> 118608 118609 Automatic date update in version.in 118610 1186112022-06-11 GDB Administrator <gdbadmin@sourceware.org> 118612 118613 Automatic date update in version.in 118614 1186152022-06-10 Tom Tromey <tom@tromey.com> 118616 118617 Fix warning-avoidance initialization in xcoffread.c 118618 With the registry rewrite series, on Fedora 34, I started seeing this 118619 error in xcoffread.c: 118620 118621 ../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’: 118622 ../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized] 118623 948 | union internal_auxent fcn_aux_saved = main_aux; 118624 | ^~~~~~~~~~~~~ 118625 ../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here 118626 933 | union internal_auxent main_aux; 118627 | ^~~~~~~~ 118628 118629 I don't know why this error started suddenly... that seems weird, 118630 because it's not obviously related to the changes I made. 118631 118632 Looking into it, it seems this line was intended to avoid a similar 118633 warning -- but since 'main_aux' is uninitialized at the point where it 118634 is used, this fix was incomplete. 118635 118636 This patch avoids the warning by initializing using "{}". I'm 118637 checking this in. 118638 1186392022-06-10 Carl Love <cel@us.ibm.com> 118640 118641 Fix comparison of unsigned long int to int in record_linux_system_call. 118642 The if statement in case gdb_sys_ioctl in function 118643 record_linux_system_call in file gdb/linux-record.c is as follows: 118644 118645 if (tmpulongest == tdep->ioctl_FIOCLEX 118646 || tmpulongest == tdep->ioctl_FIONCLEX 118647 .... 118648 || tmpulongest == tdep->ioctl_TCSETSW 118649 ... 118650 } 118651 118652 The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415. The variable 118653 ioctl_TCSETW is defined in gdb/linux-record.h as an int. The TCSETW value 118654 has the MSB set to one so it is a negative integer. The comparison of the 118655 unsigned long value tmpulongest to a negative integer value for 118656 ioctl_TCSETSW fails. 118657 118658 This patch changes the declarations for the ioctl_* values in struct 118659 linux_record_tdep to unsigned long to fix the comparisons between 118660 tmpulongest and the tdep->ioctl_* values. 118661 118662 An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify 118663 the gdb record_linux_system_call() if statement for the ioctl TCSETSW 118664 succeeds. 118665 118666 This patch has been tested on Power 10 and Intel with no test failures. 118667 1186682022-06-10 Carl Love <cel@us.ibm.com> 118669 118670 PowerPC, correct the gdb ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF. 118671 Some of the ioctl numbers are based on the size of kernel termios structure. 118672 Currently the PowerPC GDB definitions are "hard coded" into the ioctl 118673 number. 118674 118675 The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are 118676 defined in gdb/ppc-linux-tdep.c as: 118677 118678 record_tdep->ioctl_TCGETS = 0x403c7413; 118679 record_tdep->ioctl_TCSETS = 0x803c7414; 118680 record_tdep->ioctl_TCSETSW = 0x803c7415; 118681 record_tdep->ioctl_TCSETSF = 0x803c7416; 118682 118683 Where the termios structure size is in hex digits [5:4] as 0x3c. 118684 118685 The definition for the PowerPC termios structure is given in: 118686 arch/powerpc/include/uapi/asm/termbits.h 118687 118688 The size of the termios data structure in this file is 0x2c not 0x3c. 118689 118690 This patch changes the hex digits for the size of the PowerPC termios size 118691 in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c. 118692 This patch also changes the hard coding to generate the number based on a 118693 it easier to update the ioctl numbers. 118694 1186952022-06-10 Andrew Burgess <aburgess@redhat.com> 118696 118697 gdb/testsuite: remove definition of true/false from gdb_compiler_info 118698 Since pretty much forever the get_compiler_info function has included 118699 these lines: 118700 118701 # Most compilers will evaluate comparisons and other boolean 118702 # operations to 0 or 1. 118703 uplevel \#0 { set true 1 } 118704 uplevel \#0 { set false 0 } 118705 118706 These define global variables true (to 1) and false (to 0). 118707 118708 It seems odd to me that these globals are defined in 118709 get_compiler_info, I guess maybe the original thinking was that if a 118710 compiler had different true/false values then we would detect it there 118711 and define true/false differently. 118712 118713 I don't think we should be bundling this logic into get_compiler_info, 118714 it seems weird to me that in order to use $true/$false a user needs to 118715 first call get_compiler_info. 118716 118717 It would be better I think if each test script that wants these 118718 variables just defined them itself, if in the future we did need 118719 different true/false values based on compiler version then we'd just 118720 do: 118721 118722 if { [test_compiler_info "some_pattern"] } { 118723 # Defined true/false one way... 118724 } else { 118725 # Defined true/false another way... 118726 } 118727 118728 But given the current true/false definitions have been in place since 118729 at least 1999, I suspect this will not be needed any time soon. 118730 118731 Given that the definitions of true/false are so simple, right now my 118732 suggestion is just to define them in each test script that wants 118733 them (there's not that many). If we ever did need more complex logic 118734 then we can always add a function in gdb.exp that sets up these 118735 globals, but that seems overkill for now. 118736 118737 There should be no change in what is tested after this commit. 118738 1187392022-06-10 Luis Machado <luis.machado@arm.com> 118740 118741 Document the ARM_CC_FOR_TARGET testsuite variable 118742 This variable is useful when exercising AArch64 multi-arch support (debugging 118743 32-bit AArch32 executables). 118744 118745 Unfortunately it isn't well documented. This patch adds information about it 118746 and explains how to use it. 118747 1187482022-06-10 Tom de Vries <tdevries@suse.de> 118749 118750 [gdb/testsuite] Fix XPASS with gcc-12 in gdb.base/vla-struct-fields.exp 118751 With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp: 118752 ... 118753 (gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M 118754 $7 = 1^M 118755 (gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object 118756 ... 118757 118758 Fix this by limiting the xfailing to gcc-11 and earlier. Also, limit the 118759 xfailing to the equality test. 118760 118761 Tested on x86_64-linux. 118762 1187632022-06-10 Tom de Vries <tdevries@suse.de> 118764 118765 [gdb/testsuite] Fix timeout in gdb.ada/ghost.exp 118766 On openSUSE Tumbleweed with gcc-12, I run into a timeout: 118767 ... 118768 (gdb) print value^M 118769 Multiple matches for value^M 118770 [0] cancel^M 118771 [1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \ 118772 character) return character at a-strmap.adb:599^M 118773 [2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M 118774 [3] system.object_reader.value (<ref> system.object_reader.object_symbol) \ 118775 return system.object_reader.uint64 at s-objrea.adb:2279^M 118776 [4] system.traceback.symbolic.value (system.address) return string at \ 118777 s-trasym.adb:200^M 118778 > FAIL: gdb.ada/ghost.exp: print value (timeout) 118779 print ghost_value^M 118780 Argument must be choice number^M 118781 (gdb) FAIL: gdb.ada/ghost.exp: print ghost_value 118782 ... 118783 118784 Fix this by prefixing value (as well as the other printed values) with the 118785 package name: 118786 ... 118787 (gdb) print pck.value^M 118788 ... 118789 118790 Tested on x86_64-linux. 118791 118792 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29055 118793 1187942022-06-10 GDB Administrator <gdbadmin@sourceware.org> 118795 118796 Automatic date update in version.in 118797 1187982022-06-09 Tom Tromey <tromey@adacore.com> 118799 118800 Minor fix to Python breakpoint event documentation 118801 I noticed that the Python event documentation referred to the event's 118802 "breakpoint" field as a function, whereas it is actually an attribute. 118803 This patch fixes the error. 118804 1188052022-06-09 Andrew Burgess <aburgess@redhat.com> 118806 118807 gdb/aarch64: fix 32-bit arm compatibility 118808 GDB's ability to run 32-bit ARM processes on an AArch64 native target 118809 is currently broken. The test gdb.multi/multi-arch.exp currently 118810 fails with a timeout. 118811 118812 The cause of these problems is the following three functions: 118813 118814 aarch64_linux_nat_target::thread_architecture 118815 aarch64_linux_nat_target::fetch_registers 118816 aarch64_linux_nat_target::store_registers 118817 118818 What has happened, over time, is that these functions have been 118819 modified, forgetting that any particular thread (running on the native 118820 target) might be an ARM thread, or might be an AArch64 thread. 118821 118822 The problems always start with a line similar to this: 118823 118824 aarch64_gdbarch_tdep *tdep 118825 = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch); 118826 118827 The problem with this line is that if 'inf->gdbarch' is an ARM 118828 architecture, then gdbarch_tdep will return a pointer to an 118829 arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object. The 118830 result of the above cast will, as a consequence, be undefined. 118831 118832 In aarch64_linux_nat_target::thread_architecture, after the undefined 118833 cast we then proceed to make use of TDEP, like this: 118834 118835 if (vq == tdep->vq) 118836 return inf->gdbarch; 118837 118838 Obviously at this point the result is undefined, but, if this check 118839 returns false we then proceed with this code: 118840 118841 struct gdbarch_info info; 118842 info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64); 118843 info.id = (int *) (vq == 0 ? -1 : vq); 118844 return gdbarch_find_by_info (info); 118845 118846 As a consequence we will return an AArch64 gdbarch object for our ARM 118847 thread! Things go downhill from there on. 118848 118849 There are similar problems, with similar undefined behaviour, in the 118850 fetch_registers and store_registers functions. 118851 118852 The solution is to make use of a check like this: 118853 118854 if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32) 118855 118856 If the word size is 32 then we know we have an ARM architecture. We 118857 just need to make sure that we perform this check before trying to 118858 read the tdep field. 118859 118860 In aarch64_linux_nat_target::thread_architecture a little reordering, 118861 and the addition of the above check allows us to easily avoid the 118862 undefined behaviour. 118863 118864 For fetch_registers and store_registers I made the decision to split 118865 each of the functions into two new helper functions, and so 118866 aarch64_linux_nat_target::fetch_registers now calls to either 118867 aarch64_fetch_registers or aarch32_fetch_registers, and there's a 118868 similar change for store_registers. 118869 118870 One thing I had to decide was whether to place the new aarch32_* 118871 functions into the aarch32-linux-nat.c file. In the end I decided to 118872 NOT place the functions there, but instead leave them in 118873 aarch64-linux-nat.c, my reasoning was this: 118874 118875 The existing functions in that file are shared from arm-linux-nat.c 118876 and aarch64-linux-nat.c, this generic code to support 32-bit ARM 118877 debugging from either native target. 118878 118879 In contrast, the two new aarch32 functions I have added _only_ make 118880 sense when debugging on an AArch64 native target. These function 118881 shouldn't be called from arm-linux-nat.c at all, and so, if we places 118882 the functions into aarch32-linux-nat.c, the functions would be built 118883 into a 32-bit ARM GDB, but never used. 118884 118885 With that said, there's no technical reason why they couldn't go in 118886 aarch32-linux-nat.c, so if that is preferred I'm happy to move them. 118887 118888 After this commit the gdb.multi/multi-arch.exp passes. 118889 1188902022-06-09 Yvan Roux <yvan.roux@foss.st.com> 118891 118892 gdb/arm: Document and fix exception stack offsets 118893 Add a description of exception entry context stacking and fix next 118894 frame offset (at 0xA8 relative to R0 location) as well as FPU 118895 registers ones (starting at 0x68 relative to R0). 118896 118897 gdb/arm: Simplify logic for updating addresses 118898 Small performance improvement by fetching previous SP value only 118899 once before the loop and reuse it to avoid fetching at every 118900 iteration. 118901 1189022022-06-09 Pedro Alves <pedro@palves.net> 118903 118904 Fix ARM_CC_FOR_TARGET handling 118905 The previous patch that introduced the arm_cc_for_target procedure 118906 moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot 118907 to tell tcl that ARM_CC_FOR_TARGET is a global. As a result, 118908 specifying ARM_CC_FOR_TARGET on the command line actually does 118909 nothing. This fixes it. 118910 118911 Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153 118912 1189132022-06-09 Yvan Roux <yvan.roux@foss.st.com> 118914 118915 gdb/arm: Terminate unwinding when LR is 0xffffffff 118916 ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states 118917 that LR is set to 0xffffffff on reset. 118918 118919 ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set 118920 to 0xffffffff on warm reset if Main Extension is implemented, 118921 otherwise the value is unknown. 118922 1189232022-06-09 Andrew Burgess <aburgess@redhat.com> 118924 118925 gdb/testsuite: solve problems with compiler_info caching 118926 After this commit: 118927 118928 commit 44d469c5f85a4243462b8966722dafa62b602bf5 118929 Date: Tue May 31 16:43:44 2022 +0200 118930 118931 gdb/testsuite: add Fortran compiler identification to GDB 118932 118933 Some regressions were noticed: 118934 118935 https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html 118936 118937 The problem is associated with how compiler_info variable is cached 118938 between calls to get_compiler_info. 118939 118940 Even before the above commit, get_compiler_info supported two 118941 language, C and C++. Calling get_compiler_info would set the global 118942 compiler_info based on the language passed as an argument to 118943 get_compiler_info, and, in theory, compiler_info would not be updated 118944 for the rest of the dejagnu run. 118945 118946 This obviously is slightly broken behaviour. If the first call to 118947 get_compiler_info was for the C++ language then compiler_info would be 118948 set based on the C++ compiler in use, while if the first call to 118949 get_compiler_info was for the C language then compiler_info would be 118950 set based on the C compiler. 118951 118952 This probably wasn't very noticable, assuming a GCC based test 118953 environment then in most cases the C and C++ compiler would be the 118954 same version. 118955 118956 However, if the user starting playing with CC_FOR_TARGET or 118957 CXX_FOR_TARGET, then they might not get the behaviour they expect. 118958 118959 Except, to make matters worse, most of the time, the user probably 118960 would get the behaviour they expected .... except when they didn't! 118961 I'll explain: 118962 118963 In gdb.exp we try to avoid global variables leaking between test 118964 scripts, this is done with the help of the two procs 118965 gdb_setup_known_globals and gdb_cleanup_globals. All known globals 118966 are recorded before a test script starts, and then, when the test 118967 script ends, any new globals are deleted. 118968 118969 Normally, compiler_info is only set as a result of a test script 118970 calling get_compiler_info or test_compiler_info. This means that the 118971 compiler_info global will not exist when the test script starts, but 118972 will exist when the test script end, and so, the compiler_info 118973 variable is deleted at the end of each test. 118974 118975 This means that, in reality, the compiler_info is recalculated once 118976 for each test script, hence, if a test script just checks on the C 118977 compiler, or just checks on the C++ compiler, then compiler_info will 118978 be correct and the user will get the behaviour they expect. 118979 118980 However, if a single test script tries to check both the C and C++ 118981 compiler versions then this will not work (even before the above 118982 commit). 118983 118984 The situation is made worse be the behaviour or the load_lib proc. 118985 This proc (provided by dejagnu) will only load each library once. 118986 This means that if a library defines a global, then this global would 118987 normally be deleted at the end of the first test script that includes 118988 the library. 118989 118990 As future attempts to load the library will not actually reload it, 118991 then the global will not be redefined and would be missing for later 118992 test scripts that also tried to load that library. 118993 118994 To work around this issue we override load_lib in gdb.exp, this new 118995 version adds all globals from the newly loaded library to the list of 118996 globals that should be preserved (not deleted). 118997 118998 And this is where things get interesting for us. The library 118999 trace-support.exp includes calls, at the file scope, to things like 119000 is_amd64_regs_target, which cause get_compiler_info to be called. 119001 This means that after loading the library the compiler_info global is 119002 defined. 119003 119004 Our override of load_lib then decides that this new global has to be 119005 preserved, and adds it to the gdb_persistent_globals array. 119006 119007 From that point on compiler_info will never be recomputed! 119008 119009 This commit addresses all the caching problems by doing the following: 119010 119011 Change the compiler_info global into compiler_info_cache global. This 119012 new global is an array, the keys of this array will be each of the 119013 supported languages, and the values will be the compiler version for 119014 that language. 119015 119016 Now, when we call get_compiler_info, if the compiler information for 119017 the specific language has not been computed, then we do that, and add 119018 it to the cache. 119019 119020 Next, compiler_info_cache is defined by calling 119021 gdb_persistent_global. This automatically adds the global to the list 119022 of persistent globals. Now the cache will not be deleted at the end 119023 of each test script. 119024 119025 This means that, for a single test run, we will compute the compiler 119026 version just once for each language, this result will then be cached 119027 between test scripts. 119028 119029 Finally, the legacy 'gcc_compiled' flag is now only set when we call 119030 get_compiler_info with the language 'c'. Without making this change 119031 the value of 'gcc_compiled' would change each time a new language is 119032 passed to get_compiler_info. If the last language was e.g. Fortran, 119033 then gcc_compiled might be left false. 119034 1190352022-06-09 Andrew Burgess <aburgess@redhat.com> 119036 119037 gdb/testsuite: handle errors better in test_compiler_info 119038 Now that get_compiler_info might actually fail (if the language is not 119039 handled), then we should try to handle this failure better in 119040 test_compiler_info. 119041 119042 After this commit, if get_compiler_info fails then we will return a 119043 suitable result depending on how the user called test_compiler_info. 119044 119045 If the user does something like: 119046 119047 set version [test_compiler_info "" "unknown-language"] 119048 119049 Then test_compiler_info will return an empty string. My assumption is 119050 that the user will be trying to match 'version' against something, and 119051 the empty string hopefully will not match. 119052 119053 If the user does something like: 119054 119055 if { [test_compiler_info "some_pattern" "unknown-language"] } { 119056 .... 119057 } 119058 119059 Then test_compiler_info will return false which seems the obvious 119060 choice. 119061 119062 There should be no change in the test results after this commit. 119063 1190642022-06-09 Andrew Burgess <aburgess@redhat.com> 119065 119066 gdb/testsuite: make 'c' default language for get/test compiler info 119067 This commit is a minor cleanup for the two functions (in gdb.exp) 119068 get_compiler_info and test_compiler_info. 119069 119070 Instead of using the empty string as the default language, and just 119071 "knowing" that this means the C language. Make this explicit. The 119072 language argument now defaults to "c" if not specified, and the if 119073 chain in get_compiler_info that checks the language not explicitly 119074 handles "c" and gives an error for unknown languages. 119075 119076 This is a good thing, now that the API appears to take a language, if 119077 somebody does: 119078 119079 test_compiler_info "xxxx" "rust" 119080 119081 to check the version of the rust compiler then we will now give an 119082 error rather than just using the C compiler and leaving the user 119083 having to figure out why they are not getting the results they 119084 expect. 119085 119086 After a little grepping, I think the only place we were explicitly 119087 passing the empty string to either get_compiler_info or 119088 test_compiler_info was in gdb_compile_shlib_1, this is now changed to 119089 pass "c" as the default language. 119090 119091 There should be no changes to the test results after this commit. 119092 1190932022-06-09 Andrew Burgess <aburgess@redhat.com> 119094 119095 gdb/testsuite: remove get_compiler_info calls from gdb.exp and dwarf.exp 119096 We don't need to call get_compiler_info before calling 119097 test_compiler_info; test_compiler_info includes a call to 119098 get_compiler_info. 119099 119100 This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by 119101 removing some unneeded calls to get_compiler_info. We could do the 119102 same cleanup throughout the testsuite, but I'm leaving that for 119103 another day. 119104 119105 There should be no change in the test results after this commit. 119106 1191072022-06-09 Nils-Christian Kempke <nils-christian.kempke@intel.com> 119108 119109 gdb/testsuite: use test_compiler_info in gcc_major_version 119110 The procedure gcc_major_version was earlier using the global variable 119111 compiler_info to retrieve gcc's major version. This is discouraged and 119112 (as can be read in a comment in compiler.c) compiler_info should be 119113 local to get_compiler_info and test_compiler_info. 119114 119115 The preferred way of getting the compiler string is via calling 119116 test_compiler_info without arguments. Gcc_major_version was changed to 119117 do that. 119118 1191192022-06-09 Yvan Roux <yvan.roux@foss.st.com> 119120 119121 gdb: add Yvan Roux to gdb/MAINTAINERS 119122 1191232022-06-09 Andrew Burgess <aburgess@redhat.com> 119124 119125 gdb/testsuite: resolve duplicate test names in gdb.threads/tls.exp 119126 While running the gdb.threads/tls.exp test with a GDB configured 119127 without Python, I noticed some duplicate test names. 119128 119129 This is caused by a call to skip_python_tests that is within a proc 119130 that is called multiple times by the test script. Each call to 119131 skip_python_tests results in a call to 'unsupported', and this causes 119132 the duplicate test names. 119133 119134 After this commit we now call skip_python_tests just once and place 119135 the result into a variable. Now, instead of calling skip_python_tests 119136 multiple times, we just check the variable. 119137 119138 There should be no change in what is tested after this commit. 119139 1191402022-06-09 Andrew Burgess <aburgess@redhat.com> 119141 119142 gdb/testsuite: resolve duplicate test name in gnu_vector.exp 119143 While testing on AArch64 I spotted a duplicate test name in the 119144 gdb.base/gnu_vector.exp test. 119145 119146 This commit adds a 'with_test_prefix' to resolve the duplicate. 119147 119148 While I was in the area I updated a 'gdb_test_multiple' call to make 119149 use of $gdb_test_name. 119150 119151 There should be no change in what is tested after this commit. 119152 1191532022-06-09 GDB Administrator <gdbadmin@sourceware.org> 119154 119155 Automatic date update in version.in 119156 1191572022-06-08 Andrew Burgess <aburgess@redhat.com> 119158 119159 gdb: make throw_perror_with_name static 119160 The throw_perror_with_name function is not used outside of utils.c 119161 right now. And as perror_with_name is just a wrapper around 119162 throw_perror_with_name, then any future calls would be to 119163 perror_with_name. 119164 119165 Lets make throw_perror_with_name static. 119166 119167 There should be no user visible changes after this commit. 119168 1191692022-06-08 Andrew Burgess <aburgess@redhat.com> 119170 119171 gdb: remove trailing '.' from perror_with_name calls 119172 I ran into this error while working on AArch64 GDB: 119173 119174 Unable to fetch VFP registers.: Invalid argument. 119175 119176 Notice the '.:' in the middle of this error message. 119177 119178 This is because of this call in aarch64-linux-nat.c: 119179 119180 perror_with_name (_("Unable to fetch VFP registers.")); 119181 119182 The perror_with_name function take a string, and adds ': <message>' to 119183 the end the string, so I don't think the string that we pass to 119184 perror_with_name should end in '.'. 119185 119186 This commit removes all of the trailing '.' characters from 119187 perror_with_name calls, which give more readable error messages. 119188 119189 I don't believe that any of these errors are tested in the 119190 testsuite (after a little grepping). 119191 1191922022-06-08 Tom Tromey <tom@tromey.com> 119193 119194 Move CU queue to dwarf2_per_objfile 119195 The CU queue is a member of dwarf2_per_bfd, but it is only used when 119196 expanding CUs. Also, the dwarf2_per_objfile destructor checks the 119197 queue -- however, if the per-BFD object is destroyed first, this will 119198 not work. This was pointed out Lancelot as fallout from the patch to 119199 rewrite the registry system. 119200 119201 This patch avoids this problem by moving the queue to the per-objfile 119202 object. 119203 1192042022-06-08 Tom Tromey <tom@tromey.com> 119205 119206 Change allocation of m_dwarf2_cus 119207 m_dwarf2_cus manually manages the 'dwarf2_cu' pointers it owns. This 119208 patch simplifies the code by changing it to use unique_ptr. 119209 1192102022-06-08 Andrew Burgess <aburgess@redhat.com> 119211 119212 libopcodes: extend the styling within the i386 disassembler 119213 The i386 disassembler is pretty complex. Most disassembly is done 119214 indirectly; operands are built into buffers within a struct instr_info 119215 instance, before finally being printed later in the disassembly 119216 process. 119217 119218 Sometimes the operand buffers are built in a different order to the 119219 order in which they will eventually be printed. 119220 119221 Each operand can contain multiple components, e.g. multiple registers, 119222 immediates, other textual elements (commas, brackets, etc). 119223 119224 When looking for how to apply styling I guess the ideal solution would 119225 be to move away from the operands being a single string that is built 119226 up, and instead have each operand be a list of "parts", where each 119227 part is some text and a style. Then, when we eventually print the 119228 operand we would loop over the parts and print each part with the 119229 correct style. 119230 119231 But it feels like a huge amount of work to move from where we are 119232 now to that potentially ideal solution. Plus, the above solution 119233 would be pretty complex. 119234 119235 So, instead I propose a .... different solution here, one that works 119236 with the existing infrastructure. 119237 119238 As each operand is built up, piece be piece, we pass through style 119239 information. This style information is then encoded into the operand 119240 buffer (see below for details). After this the code can continue to 119241 operate as it does right now in order to manage the set of operand 119242 buffers. 119243 119244 Then, as each operand is printed we can split the operand buffer into 119245 chunks at the style marker boundaries, with each chunk being printed 119246 with the correct style. 119247 119248 For encoding the style information I use a single character, currently 119249 \002, followed by the style encoded as a single hex digit, followed 119250 again by the \002 character. 119251 119252 This of course relies on there not being more than 16 styles, but that 119253 is currently true, and hopefully will remain true for the foreseeable 119254 future. 119255 119256 The other major concern that has arisen around this work is whether 119257 the escape character could ever be encountered in output naturally 119258 generated by the disassembler. If this did happen then the escape 119259 characters would be stripped from the output, and the wrong styling 119260 would be applied. 119261 119262 However, I don't believe that this is currently a problem. 119263 Disassembler content comes from a number of sources. First there's 119264 content that copied directly from the i386-dis.c file, this is things 119265 like register names, and other syntax elements (brackets, commas, 119266 etc). We can easily check that the i386-dis.c file doesn't contain 119267 our special character. 119268 119269 The next source of content are immediate operands. The text for these 119270 operands is generated by calls into libc. By selecting a 119271 non-printable character we can be confident that this is not something 119272 that libc will generate as part of an immediate representation. 119273 119274 The other output that appears to be from the disassembler is operands 119275 that contain addresses and (possibly) symbol names. It is quite 119276 possible that a symbol name might contain any special character we 119277 could imagine, so is this a problem? 119278 119279 I don't think it is, we don't actually print address and symbol 119280 operands through the disassembler, instead, the disassembler calls 119281 back to the user (objdump, gdb, etc) to print the address and symbol 119282 on its behalf. This content is printed directly to the output stream, 119283 it does not pass through the i386 disassembler output buffers. As a 119284 result, we never check this particular output for styling escape 119285 characters. 119286 119287 In some (not very scientific) benchmarking on my machine, 119288 disassembling a reasonably large (142M) shared library, I'm not seeing 119289 any significant slow down in disassembler speed with this change. 119290 119291 Most instructions are now being fully syntax highlighted when I 119292 disassemble using the --disassembler-color=extended-color option. I'm 119293 sure that there are probably still a few corner cases that need fixing 119294 up, but we can come back to them later I think. 119295 119296 When disassembler syntax highlighting is not being used, then there 119297 should be no user visible changes after this commit. 119298 1192992022-06-08 Carl Love <cel@us.ibm.com> 119300 119301 Fix gdb.arch/powerpc-power7.exp isel disassembly output. 119302 The following commit changes the output format for the isel instruction on 119303 PowerPC. 119304 119305 commit dd4832bf3efc1bd1797a6b9188260692b8b0db52 Introduces error in test 119306 Author: Dmitry Selyutin <ghostmansd@gmail.com> 119307 Date: Tue May 24 13:46:35 2022 +0000 119308 119309 opcodes: introduce BC field; fix isel 119310 119311 Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB 119312 field present in binutils sources. Also, per 1.6.2, BC has the same 119313 semantics as BA and BB fields, so this should keep the same flags and 119314 mask, only with the different offset. 119315 119316 opcodes/ 119317 * ppc-opc.c 119318 (BC): Define new field, with the same definition as CRB field, 119319 but with the PPC_OPERAND_CR_BIT flag present. 119320 gas/ 119321 * testsuite/gas/ppc/476.d: Update. 119322 * testsuite/gas/ppc/a2.d: Update. 119323 * testsuite/gas/ppc/e500.d: Update. 119324 * testsuite/gas/ppc/power7.d: Update. 119325 <snip> 119326 --- a/gas/testsuite/gas/ppc/476.d 119327 +++ b/gas/testsuite/gas/ppc/476.d 119328 @@ -209,7 +209,7 @@ Disassembly of section \.text: 119329 .*: (7c 20 07 8c|8c 07 20 7c) ici 1 119330 .*: (7c 03 27 cc|cc 27 03 7c) icread r3,r4 119331 .*: (50 83 65 36|36 65 83 50) rlwimi r3,r4,12,20,27 119332 -.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,28 119333 +.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,4\*cr7\+lt 119334 119335 The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp 119336 on Power 7, Power 8, Power 9 and Power 10. 119337 119338 This patch updates the regression test gdb.arch/powerpc-power7.exp with 119339 the new expected output for the isel instruction. 119340 119341 The patch has been tested on Power 7 and Power 10 to verify the patch fixes 119342 the test. 119343 1193442022-06-08 Pedro Alves <pedro@palves.net> 119345 119346 aarch64: Add fallback if ARM_CC_FOR_TARGET not set 119347 On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit 119348 compiler to use when testing gdb.multi/multi-arch.exp and 119349 gdb.multi/multi-arch-exec.exp. If you don't set it, then those 119350 testcases don't run. 119351 119352 I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET. 119353 119354 This commit adds a fallback. If ARM_CC_FOR_TARGET is not set, and 119355 testing for Linux, try arm-linux-gnueabi-gcc, 119356 arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit 119357 compilers, making sure that the produced executable runs on the target 119358 machine before claiming that the compiler produces useful executables. 119359 119360 Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39 119361 1193622022-06-08 Alan Modra <amodra@gmail.com> 119363 119364 Don't encode reloc.size 119365 I expect the encoded reloc.size field originally came from aout 119366 r_length ecoding, but somehow went wrong for 64-bit relocs (which 119367 should have been encoded as 3). Toss all that out, just use a byte 119368 size instead. The changes outside of reloc.c in this patch should 119369 make the code independent of how reloc.size is encoded. 119370 119371 * reloc.c (struct reloc_howto_struct): Increase size field by 119372 one bit. Comment. 119373 (HOWTO_RSIZE): Don't encode size. 119374 (bfd_get_reloc_size): Adjust, and make it an inline function. 119375 (read_reloc, write_reloc): Adjust. 119376 * bfd-in2.h: Regenerate. 119377 * aout-ns32k.c: Include libbfd.h. 119378 (put_reloc): Don't use howto->size directly. Calculate r_length 119379 using bfd_log2 and bfd_get_reloc_size. 119380 * aoutx.h (swap_std_reloc_out): Likewise. 119381 (aout_link_reloc_link_order): Likewise. 119382 * i386lynx.c (swap_std_reloc_out 119383 * mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out 119384 * pdp11.c (aout_link_reloc_link_order 119385 * coff-arm.c (coff_arm_reloc): Don't use howto->size directly, 119386 use bfd_get_reloc_size instead and adjust switch cases. 119387 * coff-i386.c (coff_i386_reloc): Similarly. 119388 * coff-x86_64.c (coff_amd64_reloc): Likewise. 119389 * cpu-ns32k.c (do_ns32k_reloc): Likewise. 119390 * elf32-arc.c (arc_do_relocation): Likewise. 119391 * elf32-arm.c (elf32_arm_final_link_relocate): Likewise. 119392 * elf32-bfin.c (bfin_bfd_reloc): Likewise. 119393 * elf32-cr16.c (cr16_elf_final_link_relocate): Likewise. 119394 * elf32-cris.c (cris_elf_pcrel_reloc): Likewise. 119395 * elf32-crx.c (crx_elf_final_link_relocate): Likewise. 119396 * elf32-csky.c (csky_elf_relocate_section): Likewise. 119397 * elf32-d10v.c (extract_rel_addend, insert_rel_addend): Likewise. 119398 * elf32-i386.c (elf_i386_relocate_section): Likewise. 119399 * elf32-m32r.c (m32r_elf_generic_reloc): Likewise. 119400 * elf32-nds32.c (nds32_elf_generic_reloc): Likewise. 119401 * syms.c (_bfd_stab_section_find_nearest_line): Likewise. 119402 * coff-rs6000.c (xcoff_ppc_relocate_section): Adjust howto.size. 119403 * coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise. 119404 1194052022-06-08 Alan Modra <amodra@gmail.com> 119406 119407 bfin reloc offset checks 119408 These all ought to use bfd_reloc_offset_in_range. In particular, replace 119409 the check using howto->size + 1u. 119410 119411 * elf32-bfin.c (bfin_pcrel24_reloc): Use bfd_reloc_offset_in_range. 119412 (bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc), 119413 (bfin_final_link_relocate): Likewise. 119414 1194152022-06-08 Alan Modra <amodra@gmail.com> 119416 119417 Revert reloc howto nits 119418 The "HOWTO size encoding" patch put 1 as the HOWTO size arg for 119419 numerous howtos that are unused, describe dynamic relocs, are markers, 119420 or otherwise are special purpose reloc howtos that don't care about 119421 the size. The idea was to ensure no howto changed by inspecting 119422 object files. Revert those changes, making them zero size. 119423 119424 * coff-alpha.c: Give special purpose reloc howtos a size of zero. 119425 * coff-mcore.c, * elf-hppa.h, * elf-m10300.c, * elf32-arm.c, 119426 * elf32-csky.c, * elf32-m32c.c, * elf32-m68k.c, * elf32-mep.c, 119427 * elf32-mips.c, * elf32-ppc.c, * elf32-rx.c, * elf32-s390.c, 119428 * elf32-spu.c, * elf32-tic6x.c, * elf32-tilepro.c, *elf32-vax.c, 119429 * elf32-xtensa.c, * elf64-alpha.c, * elf64-mips.c, 119430 * elf64-mmix.c, * elf64-ppc.c, * elf64-s390.c, * elfn32-mips.c, 119431 * elfxx-loongarch.c, * elfxx-riscv.c, * elfxx-sparc.c, 119432 * elfxx-tilegx.c, * som.c, * vms-alpha.c: Likewise. 119433 1194342022-06-08 Alan Modra <amodra@gmail.com> 119435 119436 HOWTO size encoding 119437 This changes the HOWTO macro to encode the howto.size field from a 119438 value given in bytes. This of course requires editing all target 119439 uses of HOWTO, a major pain, but makes it a little nicer to specify 119440 new target HOWTOs. Object files before/after this patch are 119441 unchanged in .data and .rodata. 119442 119443 bfd/ 119444 * reloc.c (HOWTO_RSIZE): Encode size in bytes. 119445 (EMPTY_HOWTO): Adjust to keep it all zero. 119446 * aout-ns32k.c, * aoutx.h, * coff-alpha.c, * coff-arm.c, 119447 * coff-i386.c, * coff-mcore.c, * coff-mips.c, * coff-rs6000.c, 119448 * coff-sh.c, * coff-tic30.c, * coff-tic4x.c, * coff-tic54x.c, 119449 * coff-x86_64.c, * coff-z80.c, * coff-z8k.c, * coff64-rs6000.c, 119450 * elf-hppa.h, * elf-m10200.c, * elf-m10300.c, * elf32-arc.c, 119451 * elf32-arm.c, * elf32-avr.c, * elf32-bfin.c, * elf32-cr16.c, 119452 * elf32-cris.c, * elf32-crx.c, * elf32-csky.c, * elf32-d10v.c, 119453 * elf32-d30v.c, * elf32-dlx.c, * elf32-epiphany.c, 119454 * elf32-fr30.c, * elf32-frv.c, * elf32-ft32.c, * elf32-gen.c, 119455 * elf32-h8300.c, * elf32-i386.c, * elf32-ip2k.c, * elf32-iq2000.c, 119456 * elf32-lm32.c, * elf32-m32c.c, * elf32-m32r.c, * elf32-m68hc11.c, 119457 * elf32-m68hc12.c, * elf32-m68k.c, * elf32-mcore.c, * elf32-mep.c, 119458 * elf32-metag.c, * elf32-microblaze.c, * elf32-mips.c, 119459 * elf32-moxie.c, * elf32-msp430.c, * elf32-mt.c, * elf32-nds32.c, 119460 * elf32-nios2.c, * elf32-or1k.c, * elf32-pj.c, * elf32-ppc.c, 119461 * elf32-pru.c, * elf32-rl78.c, * elf32-rx.c, * elf32-s12z.c, 119462 * elf32-s390.c, * elf32-score.c, * elf32-score7.c, 119463 * elf32-sh-relocs.h, * elf32-spu.c, * elf32-tic6x.c, 119464 * elf32-tilepro.c, * elf32-v850.c, * elf32-vax.c, 119465 * elf32-visium.c, * elf32-wasm32.c, * elf32-xc16x.c, 119466 * elf32-xgate.c, * elf32-xstormy16.c, * elf32-xtensa.c, 119467 * elf32-z80.c, * elf64-alpha.c, * elf64-bpf.c, * elf64-gen.c, 119468 * elf64-mips.c, * elf64-mmix.c, * elf64-nfp.c, * elf64-ppc.c, 119469 * elf64-s390.c, * elf64-x86-64.c, * elfn32-mips.c, 119470 * elfnn-aarch64.c, * elfxx-ia64.c, * elfxx-loongarch.c, 119471 * elfxx-mips.c, * elfxx-riscv.c, * elfxx-sparc.c, 119472 * elfxx-tilegx.c, * mach-o-aarch64.c, * mach-o-arm.c, 119473 * mach-o-i386.c, * mach-o-x86-64.c, * pdp11.c, * reloc.c, 119474 * som.c, * vms-alpha.c: Adjust all uses of HOWTO. 119475 * bfd-in2.h: Regenerate. 119476 include/ 119477 * elf/arc-reloc.def: Adjust all uses of HOWTO. 119478 1194792022-06-08 Alan Modra <amodra@gmail.com> 119480 119481 HOWTO_RSIZE 119482 Define a helper macro for HOWTO. 119483 119484 * reloc.c (HOWTO_RSIZE): Define. 119485 (HOWTO): Use it. 119486 * bfd-in2.h: Regenerate. 119487 1194882022-06-08 Alan Modra <amodra@gmail.com> 119489 119490 elf64-nfp reloc fix 119491 These are all dummy howtos, there is no reason one of them should 119492 have partial_inplace true. 119493 119494 * elf64-nfp.c (elf_nfp_howto_table <R_NFP_IMMED_LO16_I_B>): Don't 119495 set partial_inplace. 119496 1194972022-06-08 Alan Modra <amodra@gmail.com> 119498 119499 coff-z80 reloc howto fixes 119500 Mostly cosmetic unless attempting to link coff-z80 into another output 119501 format. 119502 119503 * coff-z80.c (howto_table <R_IMM24, R_WORD0, R_WORD1>): Correct size. 119504 (extra_case): Use bfd_{get,put}_24 when applying R_IMM24. 119505 1195062022-06-08 Alan Modra <amodra@gmail.com> 119507 119508 NONE reloc fixes 119509 Make them all zero size standard do-nothing howtos. 119510 119511 * elf32-csky.c (csky_elf_howto_table <R_CKCORE_NONE>): Correct howto. 119512 * elf32-ft32.c (ft32_elf_howto_table <R_FT32_NONE>): Likewise. 119513 * elf32-gen.c (dummy): Likewise. 119514 * elf32-nds32.c (none_howto): Likewise. 119515 * elf32-nios2.c (elf_nios2_r2_howto_table_rel <R_NIOS2_NONE>): 119516 Likewise. 119517 * elf32-pru.c (elf_pru_howto_table_rel <R_PRU_NONE>): Likewise. 119518 * elf32-v850.c (v800_elf_howto_table <R_V810_NONE>): Likewise. 119519 * elf64-gen.c (dummy): Likewise. 119520 * elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_NONE): Likewise. 119521 * elfxx-mips.c (none_howto): Likewise. 119522 * reloc.c (none_howto): Likewise. 119523 1195242022-06-08 Alan Modra <amodra@gmail.com> 119525 119526 asan: double free sb_kill 119527 oss-fuzz hits a flaky crash with a double-free. I think this is due 119528 to gas static state not being reinitialised between testcases, a bug 119529 with oss-fuzz not gas. Anyway, this patch should avoid the problem. 119530 119531 * input-scrub.c (input_scrub_push): Move init of sb_index.. 119532 (input_scrub_reinit): ..to here. 119533 1195342022-06-08 GDB Administrator <gdbadmin@sourceware.org> 119535 119536 Automatic date update in version.in 119537 1195382022-06-07 Tom Tromey <tromey@adacore.com> 119539 119540 Use subclasses of windows_process_info 119541 This changes windows_process_info to use virtual methods for its 119542 callbacks, and then changes the two clients of this code to subclass 119543 this class to implement the methods. 119544 119545 I considered using CRTP here, but that would require making the new 119546 structures visible to the compilation of of nat/windows-nat.c. This 119547 seemed like a bit of a pain, so I didn't do it. 119548 119549 This change then lets us change all the per-inferior globals to be 119550 members of the new subclass. Note that there can still only be a 119551 single inferior -- currently there's a single global of the new type. 119552 This is just another step toward possibly implementing multi-inferior 119553 for Windows. 119554 119555 It's possible this could be cleaned up further... ideally I'd like to 119556 move more of the data into the base class. However, because gdb 119557 supports Cygwin and gdbserver does not, and because I don't have a way 119558 to build or test Cygwin, larger refactorings are difficult. 119559 1195602022-06-07 Tom Tromey <tromey@adacore.com> 119561 119562 Turn some windows-nat.c static functions into methods 119563 This patch turns some windows-nat.c static functions into methods on 119564 windows_nat_target. This avoids having to reference the 119565 windows_nat_target singleton in some more spots -- a minor code 119566 cleanup. 119567 119568 Allow ASLR to be disabled on Windows 119569 On Windows, it is possible to disable ASLR when creating a process. 119570 This patch adds code to do this, and hooks it up to gdb's existing 119571 disable-randomization feature. Because the Windows documentation 119572 cautions that this isn't available on all versions of Windows, the 119573 CreateProcess wrapper function is updated to make the attempt, and 119574 then fall back to the current approach if it fails. 119575 119576 Introduce wrapper for CreateProcess 119577 This is a small refactoring that introduces a wrapper for the Windows 119578 CreateProcess function. This is done to make the next patch a bit 119579 simpler. 119580 1195812022-06-07 Enze Li <enze.li@hotmail.com> 119582 119583 Update my email address in gdb/MAINTAINERS 119584 1195852022-06-07 Tom Tromey <tromey@adacore.com> 119586 119587 Constify solib_name_from_address 119588 I noticed that solib_name_from_address returned a non-const string, 119589 but it's more appropriate to return const. This patch implements 119590 this. Tested by rebuilding. 119591 1195922022-06-07 Tom de Vries <tdevries@suse.de> 119593 119594 [gdb/rust] Add missing _() for error call 119595 In commit 1390b65a1b9 ("[gdb/rust] Fix literal truncation") I forgot to add 119596 _() around a string using in an error call. 119597 119598 Fix this by adding the missing _(). 119599 119600 Tested on x86_64-linux. 119601 1196022022-06-07 Tom de Vries <tdevries@suse.de> 119603 119604 [gdb] Allow frv::fr300 in selftests 119605 In skip_arch in gdb/selftest-arch.c we skip architecture fr300 because of 119606 PR20946, but the PR has been fixed by commit 0ae60c3ef45 ("Prevent an abort in 119607 the FRV disassembler if the target bfd name is unknown.") in Januari 2017. 119608 119609 Remove the skipping of frv::fr300. 119610 119611 Tested on x86_64-linux. 119612 1196132022-06-07 GDB Administrator <gdbadmin@sourceware.org> 119614 119615 Automatic date update in version.in 119616 1196172022-06-06 Tom Tromey <tromey@adacore.com> 119618 119619 Consolidate "Python API" sections in NEWS 119620 I noticed that the gdb NEWS file had two "Python API" sections in 119621 "Changes since GDB 12". This patch consolidates the two. I chose to 119622 preserve the second one, first because it is longer, and second 119623 because I felt that user command changes should come before API 119624 changes. 119625 119626 Simplify varobj "change" logic 119627 varobj used to store 'print_value' as a C string, where NULL was a 119628 valid value, and so it had logic to handle this situation. However, 119629 at some point this was changed to be a std::string, and so the code 119630 can be simplified in this spot. 119631 1196322022-06-06 Tom Tromey <tromey@adacore.com> 119633 119634 Remove "-break-insert -r" tests 119635 PR mi/14270 points out that mi-break.exp has some tests for an 119636 unimplemented "-r" switch for "-break-insert". This switch was never 119637 implemented, and is not documented -- though it is mentioned in a 119638 comment in the documentation. This patch removes the test and the doc 119639 comment. 119640 119641 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14270 119642 1196432022-06-06 Tom de Vries <tdevries@suse.de> 119644 119645 [gdb] Name arch selftests more clearly 119646 When running some all archs selftest I get: 119647 ... 119648 $ gdb -q -batch -ex "maint selftest unpack_field_as_long" 119649 Running selftest unpack_field_as_long::A6. 119650 ... 119651 119652 By now I know that A6 is an arc architecture, but for others that's less 119653 clear. 119654 119655 Fix this by using unpack_field_as_long::arc::A6 instead. 119656 119657 This then introduces redundant names like arm::arm, so try to avoid those, 119658 though I'm not entirely convinced that that's worth the trouble. 119659 119660 This introduces the following new names: 119661 ... 119662 +Running selftest unpack_field_as_long::am33_2::am33-2. 119663 +Running selftest unpack_field_as_long::arc::A6. 119664 +Running selftest unpack_field_as_long::arc::A7. 119665 +Running selftest unpack_field_as_long::arc::EM. 119666 +Running selftest unpack_field_as_long::arc::HS. 119667 +Running selftest unpack_field_as_long::arm::ep9312. 119668 +Running selftest unpack_field_as_long::arm::iwmmxt. 119669 +Running selftest unpack_field_as_long::arm::iwmmxt2. 119670 +Running selftest unpack_field_as_long::arm::xscale. 119671 +Running selftest unpack_field_as_long::bpf::xbpf. 119672 +Running selftest unpack_field_as_long::frv::fr400. 119673 +Running selftest unpack_field_as_long::frv::fr450. 119674 +Running selftest unpack_field_as_long::frv::fr500. 119675 +Running selftest unpack_field_as_long::frv::fr550. 119676 +Running selftest unpack_field_as_long::frv::simple. 119677 +Running selftest unpack_field_as_long::frv::tomcat. 119678 +Running selftest unpack_field_as_long::iq2000::iq10. 119679 +Running selftest unpack_field_as_long::m32c::m16c. 119680 +Running selftest unpack_field_as_long::mep::c5. 119681 +Running selftest unpack_field_as_long::mep::h1. 119682 +Running selftest unpack_field_as_long::nds32::n1. 119683 +Running selftest unpack_field_as_long::nds32::n1h. 119684 +Running selftest unpack_field_as_long::nds32::n1h_v2. 119685 +Running selftest unpack_field_as_long::nds32::n1h_v3. 119686 +Running selftest unpack_field_as_long::nds32::n1h_v3m. 119687 +Running selftest unpack_field_as_long::z80::ez80-adl. 119688 +Running selftest unpack_field_as_long::z80::ez80-z80. 119689 +Running selftest unpack_field_as_long::z80::gbz80. 119690 +Running selftest unpack_field_as_long::z80::r800. 119691 +Running selftest unpack_field_as_long::z80::z180. 119692 ... 119693 119694 Tested on x86_64-linux. 119695 1196962022-06-06 Tom de Vries <tdevries@suse.de> 119697 119698 [gdb] Enable some more print_one_insn selftests 119699 In print_one_insn_test we have this cluster of skipped tests: 119700 ... 119701 case bfd_arch_ia64: 119702 case bfd_arch_mep: 119703 case bfd_arch_mips: 119704 case bfd_arch_tic6x: 119705 case bfd_arch_xtensa: 119706 return; 119707 ... 119708 119709 Enable some of these, and document in more detail why they're enabled or 119710 skipped. 119711 119712 Likewise, document bfd_arch_or1k because it's an odd case. 119713 119714 Tested on x86_64-linux. 119715 1197162022-06-06 Tom de Vries <tdevries@suse.de> 119717 119718 [gdb] Fix maint selftest -v print_one_insn 119719 When running the print_one_insn selftests with -v, I get: 119720 ... 119721 $ gdb -q -batch -ex "maint selftest -v print_one_insn" 119722 Running selftest print_one_insn::A6. 119723 .shor 0x783eRunning selftest print_one_insn::A7. 119724 trap_s 0x1Running selftest print_one_insn::ARC600. 119725 .shor 0x783eRunning selftest print_one_insn::ARC601. 119726 Running selftest print_one_insn::ARC700. 119727 trap_s 0x1Running selftest print_one_insn::ARCv2. 119728 trap_s 0x1Running selftest print_one_insn::EM. 119729 trap_s 0x1Running selftest print_one_insn::HS. 119730 trap_s 0x1Running selftest print_one_insn::Loongarch32. 119731 ... 119732 119733 The insn is written to gdb_stdout, and there is code in the selftest to add a 119734 newline after the insn, which writes to stream(). 119735 119736 The stream() ui_file points into a string buffer, which the disassembler uses 119737 before writing to gdb_stdout, so writing into it after the disassembler has 119738 finished has no effect. 119739 119740 Fix this by using gdb_stdlog and debug_printf (which is what the unit test 119741 infrastructure itself uses) instead, such that we have: 119742 ... 119743 Running selftest print_one_insn::A6. 119744 .shor 0x783e 119745 Running selftest print_one_insn::A7. 119746 trap_s 0x1 119747 Running selftest print_one_insn::ARC600. 119748 .shor 0x783e 119749 Running selftest print_one_insn::ARC601. 119750 Running selftest print_one_insn::ARC700. 119751 trap_s 0x1 119752 Running selftest print_one_insn::ARCv2. 119753 trap_s 0x1 119754 Running selftest print_one_insn::Loongarch32. 119755 ... 119756 119757 Note: I've also removed the printing of arch_name, which would give 119758 us otherwise the redundant: 119759 ... 119760 Running selftest print_one_insn::A6. 119761 arc .shor 0x783e 119762 Running selftest print_one_insn::A7. 119763 arc trap_s 0x1 119764 ... 119765 119766 Tested on x86_64-linux. 119767 1197682022-06-06 Andrew Burgess <aburgess@redhat.com> 119769 119770 gdb/testsuite: add missing skip_python_tests call in py-doc-reformat.exp 119771 In commit: 119772 119773 commit 51e8dbe1fbe7d8955589703140ca5eba7b4f1bd7 119774 Date: Mon May 16 19:26:54 2022 +0100 119775 119776 gdb/python: improve formatting of help text for user defined commands 119777 119778 the test that was added (gdb.python/py-doc-reformat.exp) was missing a 119779 call to skip_python_tests. As a result, this test would fail for any 119780 GDB built within Python support. 119781 119782 This commit adds a call to skip_python_tests. 119783 1197842022-06-06 GDB Administrator <gdbadmin@sourceware.org> 119785 119786 Automatic date update in version.in 119787 1197882022-06-05 Tom Tromey <tom@tromey.com> 119789 119790 Remove obsolete Python 2 comment 119791 I found a comment that referred to Python 2, but that is now obsolete 119792 -- the code it refers to is gone. I'm checking in this patch to 119793 remove the comment. 119794 119795 There's a similar comment elsewhere, but I plan to remove that one in 119796 another patch I'm going to submit shortly. 119797 1197982022-06-05 GDB Administrator <gdbadmin@sourceware.org> 119799 119800 Automatic date update in version.in 119801 1198022022-06-04 Alan Modra <amodra@gmail.com> 119803 119804 asan: null dereference in coff_count_linenumbers 119805 * coffgen.c (coff_count_linenumbers): Don't segfault when asymbol 119806 the_bfd is NULL. 119807 119808 asan: uninitialised write in bfd_mach_o_write_contents 119809 * mach-o.c (bfd_mach_o_write_contents): Always set 119810 bfd_mach_o_dyld_info_command *_off fields. 119811 1198122022-06-04 Tom de Vries <tdevries@suse.de> 119813 119814 [gdb/ada] Fix literal truncation 119815 Make sure we error out on overflow instead of truncating in all cases. 119816 119817 Tested on x86_64-linux, with a build with --enable-targets=all. 119818 1198192022-06-04 Tom de Vries <tdevries@suse.de> 119820 119821 [gdb/m2] Fix UB and literal truncation 119822 Rewrite parse_number to use ULONGEST instead of LONGEST, to fix UB errors as 119823 mentioned in PR29163. 119824 119825 Furthermore, make sure we error out on overflow instead of truncating in all 119826 cases. 119827 119828 Tested on x86_64-linux, with a build with --enable-targets=all. 119829 119830 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29163 119831 1198322022-06-04 Tom de Vries <tdevries@suse.de> 119833 119834 [gdb/rust] Fix literal truncation 119835 Make sure we error out on overflow instead of truncating in all cases. 119836 119837 I've used as overflow string: "Integer literal is too large", based 119838 on what I found at 119839 <rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs 119840 but perhaps someone has a better idea. 119841 119842 Tested on x86_64-linux, with a build with --enable-targets=all. 119843 1198442022-06-04 Tom de Vries <tdevries@suse.de> 119845 119846 [gdb/pascal] Fix literal truncation 119847 Make sure we error out on overflow instead of truncating in all cases. 119848 119849 The current implementation of parse_number contains a comment about PR16377, 119850 but that's related to C-like languages. In absence of information of whether 119851 the same fix is needed for pascal, take the conservative approach and keep 119852 behaviour for decimals unchanged. 119853 119854 Tested on x86_64-linux, with a build with --enable-targets=all. 119855 1198562022-06-04 Tom de Vries <tdevries@suse.de> 119857 119858 [gdb/go] Fix literal truncation 119859 Make sure we error out on overflow instead of truncating in all cases. 119860 119861 The current implementation of parse_number contains a comment about PR16377, 119862 but that's related to C-like languages. In absence of information of whether 119863 the same fix is needed for go, take the conservative approach and keep 119864 behaviour for decimals unchanged. 119865 119866 Tested on x86_64-linux, with a build with --enable-targets=all. 119867 1198682022-06-04 Tom de Vries <tdevries@suse.de> 119869 119870 [gdb/fortran] Fix literal truncation 119871 As mentioned in commit 5b758627a18 ("Make gdb.base/parse_number.exp test all 119872 architectures"): 119873 ... 119874 There might be a bug that 32-bit fortran truncates 64-bit values to 119875 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". 119876 ... 119877 119878 More concretely, we have: 119879 ... 119880 $ for arch in i386:x86-64 i386; do \ 119881 gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \ 119882 -ex "p /x 0xffffffffffffffff"; \ 119883 done 119884 The target architecture is set to "i386:x86-64". 119885 $1 = 0xffffffffffffffff 119886 The target architecture is set to "i386". 119887 $1 = 0xffffffff 119888 ... 119889 119890 Fix this by adding a range check in parse_number in gdb/f-exp.y. 119891 119892 Furthermore, make sure we error out on overflow instead of truncating in all 119893 other cases. 119894 119895 Tested on x86_64-linux. 119896 1198972022-06-04 Tom de Vries <tdevries@suse.de> 119898 119899 [gdb/c] Fix type of 2147483648 and literal truncation 119900 [ Assuming arch i386:x86-64, sizeof (int) == 4, 119901 sizeof (long) == sizeof (long long) == 8. ] 119902 119903 Currently we have (decimal for 0x80000000): 119904 ... 119905 (gdb) ptype 2147483648 119906 type = unsigned int 119907 ... 119908 119909 According to C language rules, unsigned types cannot be used for decimal 119910 constants, so the type should be long instead (reported in PR16377). 119911 119912 Fix this by making sure the type of 2147483648 is long. 119913 119914 The next interesting case is (decimal for 0x8000000000000000): 119915 ... 119916 (gdb) ptype 9223372036854775808 119917 type = unsigned long 119918 ... 119919 119920 According to the same rules, unsigned long is incorrect. 119921 119922 Current gcc uses __int128 as type, which is allowed, but we don't have that 119923 available in gdb, so the strict response here would be erroring out with 119924 overflow. 119925 119926 Older gcc without __int128 support, as well as clang use an unsigned type, but with 119927 a warning. Interestingly, clang uses "unsigned long long" while gcc uses 119928 "unsigned long", which seems the better choice. 119929 119930 Given that the compilers allow this as a convience, do the same in gdb 119931 and keep type "unsigned long", and make this explicit in parser and test-case. 119932 119933 Furthermore, make sure we error out on overflow instead of truncating in all 119934 cases. 119935 119936 Tested on x86_64-linux with --enable-targets=all. 119937 119938 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16377 119939 1199402022-06-04 Tom de Vries <tdevries@suse.de> 119941 119942 [gdb/testsuite] Test more values in gdb.base/parse_numbers.exp 119943 Currently we only test value 0xffffffffffffffff in test-case 119944 gdb.base/parse_numbers.exp. 119945 119946 Test more interesting values, both in decimal and hex format, as well as 119947 negative decimals for language modula-2. 119948 119949 This results in an increase in total tests from 15572 to 847448 (55 times 119950 more tests). 119951 119952 Balance out the increase in runtime by reducing the number of architectures 119953 tested: only test one architecture per sizeof longlong/long/int/short 119954 combination, while keeping the possibility intact to run with all 119955 architectures (through setting a variable in the test-case) 119956 119957 Results in slight reduction of total tests: 15572 -> 13853. 119958 119959 Document interesting cases in the expected results: 119960 - wrapping from unsigned to signed 119961 - truncation 119962 - PR16377: using unsigned types to represent decimal constants in C 119963 119964 Running the test-case with a gdb build with -fsanitize=undefined, we trigger 119965 two UB errors in the modula-2 parser, filed as PR29163. 119966 119967 Tested on x86_64-linux with --enable-targets=all. 119968 1199692022-06-04 Tom de Vries <tdevries@suse.de> 119970 119971 [gdb/testsuite] Fix ERROR in gdb.ctf/funcreturn.exp 119972 On openSUSE Tumbleweed (with gcc-12, enabling ctf tests) I run into: 119973 ... 119974 ERROR: tcl error sourcing src/gdb/testsuite/gdb.ctf/funcreturn.exp. 119975 ERROR: tcl error code NONE 119976 ERROR: Unexpected arguments: \ 119977 {print v_double_func} \ 119978 {[0-9]+ = {double \(\)} 0x[0-9a-z]+.*} \ 119979 {print double function} \ 119980 } 119981 ... 119982 119983 The problem is a curly brace as fourth argument to gdb_test, which errors out 119984 due to recently introduced more strict argument checking in gdb_test. 119985 119986 Fix the error by removing the brace. 119987 119988 Though this fixes the error for me, due to PR29160 I get only FAILs, so I can't 119989 claim proper testing on x86_64-linux. 119990 1199912022-06-04 Tom de Vries <tdevries@suse.de> 119992 119993 [gdb/testsuite] Fix gdb.threads/manythreads.exp with check-read1 119994 When running test-case gdb.threads/manythreads.exp with check-read1, I ran 119995 into this hard-to-reproduce FAIL: 119996 ... 119997 [New Thread 0x7ffff7318700 (LWP 31125)]^M 119998 [Thread 0x7ffff7321700 (LWP 31124) exited]^M 119999 [New T^C^M 120000 ^M 120001 Thread 769 "manythreads" received signal SIGINT, Interrupt.^M 120002 [Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M 120003 0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M 120004 (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 120005 ... 120006 120007 The matching in the failing gdb_test_multiple is done in an intricate way, 120008 trying to pass on some order and fail on another order. 120009 120010 Fix this by rewriting the regexps to match one line at most, and detecting 120011 invalid order by setting and checking state variables. 120012 120013 Tested on x86_64-linux. 120014 120015 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29177 120016 1200172022-06-04 Tom de Vries <tdevries@suse.de> 120018 120019 [gdb] Fix warning in print_one_insn::ez80-adl 120020 When running selftest print_one_insn::ez80-adl we run into this warning: 120021 ... 120022 Running selftest print_one_insn::ez80-adl. 120023 warning: Unable to determine inferior's software breakpoint type: couldn't 120024 find `_break_handler' function in inferior. Will be used default software \ 120025 breakpoint instruction RST 0x08. 120026 ... 120027 120028 Fix this by explicitly handling bfd_arch_z80 in print_one_insn_test. 120029 120030 Tested on x86_64-linux. 120031 1200322022-06-04 GDB Administrator <gdbadmin@sourceware.org> 120033 120034 Automatic date update in version.in 120035 1200362022-06-03 Tom Tromey <tromey@adacore.com> 120037 120038 Use bool for evregpy_no_listeners_p 120039 I noticed that evregpy_no_listeners_p should return a bool. This 120040 patch makes this change. I'm checking it in. 120041 1200422022-06-03 Alan Modra <amodra@gmail.com> 120043 120044 asan: heap buffer overflow in _bfd_mips_elf_section_from_shdr 120045 * elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Sanity check 120046 intopt.size and remaining bytes in section for reginfo. 120047 1200482022-06-03 Alan Modra <amodra@gmail.com> 120049 120050 Re: ubsan: undefined shift in frag_align_code 120051 This one needs the same fix too. 120052 120053 * config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed 120054 integer overflow. 120055 1200562022-06-03 Tom de Vries <tdevries@suse.de> 120057 120058 [gdb] Fix warning in foreach_arch selftests 120059 When running the selftests, I run into: 120060 ... 120061 $ gdb -q -batch -ex "maint selftest" 120062 ... 120063 Running selftest execute_cfa_program::aarch64:ilp32. 120064 warning: A handler for the OS ABI "GNU/Linux" is not built into this 120065 configuration of GDB. Attempting to continue with the default aarch64:ilp32 120066 settings. 120067 ... 120068 and likewise for execute_cfa_program::i8086 and 120069 execute_cfa_program::ia64-elf32. 120070 120071 The warning can easily be reproduced outside the selftests by doing: 120072 ... 120073 $ gdb -q -batch -ex "set arch aarch64:ilp32" 120074 ... 120075 and can be prevented by first doing "set osabi none". 120076 120077 Fix the warning by setting osabi to none while doing selftests that iterate 120078 over all architectures. 120079 120080 This causes a regression in the print_one_insn selftests for the ARC 120081 architecture. 120082 120083 The problem is pre-existing, and can be demonstrated (already without this 120084 patch) using: 120085 ... 120086 $ gdb -q -batch -ex "set osabi none" -ex "maint selftest print_one_insn::A6" 120087 Running selftest print_one_insn::A6. 120088 Self test failed: Cannot access memory at address 0x0 120089 Ran 1 unit tests, 1 failed 120090 $ 120091 ... 120092 120093 For ARC, we use the generic case in print_one_insn_test, containing this code: 120094 ... 120095 int kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc); 120096 ... 120097 insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen); 120098 ... 120099 120100 The problem is that with osabi linux we trigger: 120101 ... 120102 static int 120103 arc_linux_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr) 120104 { 120105 return trap_size; 120106 } 120107 ... 120108 but with osabi none: 120109 ... 120110 arc_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr) 120111 { 120112 size_t length_with_limm = gdb_insn_length (gdbarch, *pcptr); 120113 ... 120114 which needs access to memory, and will consequently fail. 120115 120116 Fix this in print_one_insn_test, in the default case, by iterating over 120117 supported osabi's to makes sure we trigger arc_linux_breakpoint_kind_from_pc 120118 which will give us a usable instruction to disassemble. 120119 120120 Tested on x86_64-linux. 120121 1201222022-06-03 Tom de Vries <tdevries@suse.de> 120123 120124 Revert "[gdb] Fix warning in foreach_arch selftests" 120125 This reverts commit fc18b1c5afd ("[gdb] Fix warning in foreach_arch 120126 selftests"). 120127 120128 The commit introduced regressions for an --enable-targets=all build: 120129 ... 120130 Running selftest print_one_insn::A6.^M 120131 Self test failed: Cannot access memory at address 0x0^M 120132 ... 120133 and while investigating those I realized that the commit fc18b1c5afd 120134 complicates things by trying to set the current osabi. 120135 120136 So, revert the patch in preparation for a simpler solution. 120137 120138 Tested on x86_64-linux. 120139 1201402022-06-03 Jan Beulich <jbeulich@suse.com> 120141 120142 x86: exclude certain ISA extensions from v3/v4 ISA 120143 Like TBM and LWP, XOP and FMA4 also shouldn't be included in v3. 120144 120145 Like AVX512-4VNNIW, AVX512-4FMAPS also shouldn't be included in v4. 120146 1201472022-06-03 Roland McGrath <mcgrathr@google.com> 120148 120149 gdb: LoongArch: Remove nonportable #include 120150 Don't use gregset.h in *-tdep.c since it's not usable on 120151 hosts that don't have <sys/procfs.h>. It's not needed by 120152 this file, and should only be needed by *-nat.c files. 120153 1201542022-06-03 Alan Modra <amodra@gmail.com> 120155 120156 Re: asan: mips_gprel_reloc segfault 120157 Similarly for the elf mips support. 120158 120159 * elf32-mips.c (mips_elf_final_gp): Don't segfault on symbols 120160 in any of the bfd_is_const_section sections. 120161 * elf64-mips.c (mips_elf64_final_gp): Likewise. 120162 * elfn32-mips.c (mips_elf_final_gp): Likewise. 120163 1201642022-06-03 Alan Modra <amodra@gmail.com> 120165 120166 asan: mips_gprel_reloc segfault 120167 Not just the undefined section has a NULL owner, the absolute section 120168 has too. Which means we can't find output_bfd for __gp. Also, may as 120169 well test directly for output_bfd == NULL. 120170 120171 * coff-mips.c (mips_gprel_reloc): Don't segfault on any of 120172 bfd_is_const_section sections. 120173 1201742022-06-03 GDB Administrator <gdbadmin@sourceware.org> 120175 120176 Automatic date update in version.in 120177 1201782022-06-02 Tom de Vries <tdevries@suse.de> 120179 120180 [gdb/testsuite] Detect change instead of init in gdb.mi/mi-var-block.exp 120181 On openSUSE Tumbleweed with target board unix/-m32, I run into: 120182 ... 120183 PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2 120184 Expecting: ^(-var-update \*[^M 120185 ]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"}, 120186 {name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M 120187 ]+[(]gdb[)] ^M 120188 [ ]*) 120189 -var-update *^M 120190 ^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M 120191 (gdb) ^M 120192 FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output) 120193 ... 120194 120195 The problem is that the test-case attempts to detect a change in the cb 120196 variable caused by this initialization: 120197 ... 120198 void 120199 do_block_tests () 120200 { 120201 int cb = 12; 120202 ... 120203 but that only works if the stack location happens to be unequal to 12 before 120204 the initialization. 120205 120206 Fix this by first initializing to 0, and then changing the value to 12: 120207 ... 120208 - int cb = 12; 120209 + int cb = 0; 120210 + cb = 12; 120211 ... 120212 and detecting that change. 120213 120214 Tested on x86_64-linux. 120215 120216 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29195 120217 1202182022-06-02 Eli Zaretskii <eliz@gnu.org> 120219 120220 Rearrange and slightly reword the "Location Specification" section 120221 This rearranges and changes the wording of the "Location 120222 Specification" section of the GDB manual in minor ways. 120223 1202242022-06-02 Tom Tromey <tromey@adacore.com> 120225 120226 ODR warning for "main" 120227 "main" is redeclared with a different type in maint.c. I think this 120228 might have come from my first gdb patch, many many years ago. While I 120229 wonder if this profiling code is actually useful at all any more, in 120230 the meantime it's simple to fix the declaration. 120231 120232 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120233 1202342022-06-02 Tom Tromey <tromey@adacore.com> 120235 120236 ODR warnings for "struct coff_symbol" 120237 "struct coff_symbol" is defined in multiple .c files, causing ODR 120238 warnings. This patch renames just the xcoffread.c type. 120239 120240 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120241 1202422022-06-02 Tom Tromey <tromey@adacore.com> 120243 120244 ODR warnings for "struct insn_decode_record_t" 120245 "struct insn_decode_record_t" is defined in multiple .c files, causing 120246 ODR warnings. This patch renames the types, and removes the use of 120247 "typedef" here -- this is a C-ism that's no longer needed. 120248 120249 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120250 1202512022-06-02 Tom Tromey <tromey@adacore.com> 120252 120253 ODR warnings for "struct insn_info" 120254 "struct insn_info" is defined in multiple .c files, causing ODR 120255 warnings. This patch renames the type in z80-tdep.c, leaving the 120256 other one alone. 120257 120258 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120259 1202602022-06-02 Tom Tromey <tromey@adacore.com> 120261 120262 ODR warnings from overlay constants 120263 Some overlay-related constants are duplicated in z80-tdep.c, causing 120264 ODR warnings. This patch renames just the z80-specific ones. 120265 120266 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120267 1202682022-06-02 Tom Tromey <tromey@adacore.com> 120269 120270 ODR warning for "enum string_repr_result" 120271 "enum string_repr_result" is defined in multiple .c files, causing ODR 120272 warnings. This patch renames the types. 120273 120274 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120275 1202762022-06-02 Tom Tromey <tromey@adacore.com> 120277 120278 ODR warning for "struct find_targ_sec_arg" 120279 "struct find_targ_sec_arg" is defined in multiple .c files, causing 120280 ODR warnings. This patch renames the types. 120281 120282 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120283 1202842022-06-02 Tom Tromey <tromey@adacore.com> 120285 120286 ODR warning for "struct stack_item" 120287 "struct stack_item" is defined in multiple .c files, causing ODR 120288 warnings. This patch renames these types. 120289 120290 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120291 1202922022-06-02 Tom Tromey <tromey@adacore.com> 120293 120294 ODR warning for "struct instruction_type" 120295 "struct instruction_type" is defined in multiple .c files, causing an 120296 ODR warning. This patch renames the types. 120297 120298 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120299 1203002022-06-02 Tom Tromey <tromey@adacore.com> 120301 120302 ODR warning for struct ext_link_map 120303 This renames the solib-dsbt.c copy of "struct ext_link_map" to avoid 120304 an ODR warning. 120305 120306 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120307 1203082022-06-02 Tom Tromey <tromey@adacore.com> 120309 120310 ODR warning for struct field_info 120311 This renames one of the instance of "struct field_info" to avoid an 120312 ODR warning. 120313 120314 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120315 1203162022-06-02 Tom Tromey <tromey@adacore.com> 120317 120318 ODR warnings for struct nextfield 120319 "struct nextfield" is defined in multiple places in GDB. This patch 120320 renames just the stabs one, leaving the DWARF one untouched. 120321 120322 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120323 1203242022-06-02 Tom Tromey <tromey@adacore.com> 120325 120326 ODR warnings for struct symloc 120327 "struct symloc" is defined in multiple spots in gdb, causing ODR 120328 warnings. This patch renames these. 120329 120330 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120331 1203322022-06-02 Tom Tromey <tromey@adacore.com> 120333 120334 Fix ODR warning in observable.h 120335 observable.h triggers an ODR warning because this line: 120336 120337 extern observable<struct target_ops */* target */> target_changed; 120338 120339 ... may be the only declaration of "struct target_ops" in scope 120340 (depending on the particular .c file) -- and this declares it in a 120341 namespace, resulting in confusion. 120342 120343 This patch fixes the problem by adding a forward declaration. 120344 120345 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 120346 1203472022-06-02 Tiezhu Yang <yangtiezhu@loongson.cn> 120348 120349 gdb: LoongArch: Implement the software_single_step gdbarch method 120350 When execute the following command on LoongArch: 120351 120352 make check-gdb TESTS="gdb.base/branch-to-self.exp" 120353 120354 there exist the following failed testcases: 120355 120356 FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout) 120357 FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout) 120358 FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout) 120359 120360 Implement the software_single_step gdbarch method to decode the current 120361 branch instruction and determine the address of the next instruction on 120362 LoongArch to fix the above failed testcases. 120363 1203642022-06-02 Ilya Leoshkevich <iii@linux.ibm.com> 120365 120366 gdb: Do not add empty sections to the section map 120367 From: Ulrich Weigand <ulrich.weigand@de.ibm.com> 120368 120369 build_objfile_section_table () creates four synthetic sections per 120370 objfile, which are collected by update_section_map () and passed to 120371 std::sort (). When there are a lot of objfiles, for example, when 120372 debugging JITs, the presence of these sections slows down the sorting 120373 significantly. 120374 120375 The output of update_section_map () is used by find_pc_section (), 120376 which can never return any of these sections: their size is 0, so they 120377 cannot be accepted by bsearch_cmp (). 120378 120379 Filter them (and all the other empty sections) out in 120380 insert_section_p (), which is used only by update_section_map (). 120381 1203822022-06-02 Jon Turney <jon.turney@dronecode.org.uk> 120383 120384 Fix a new warning on Cygwin 120385 > ../../gdb/windows-nat.c: In function ‘windows_solib* windows_make_so(const char*, LPVOID)’: 120386 > ../../gdb/windows-nat.c:714:12: error: declaration of ‘char name [512]’ shadows a parameter [-Werror=shadow=compatible-local] 120387 > 714 | char name[SO_NAME_MAX_PATH_SIZE]; 120388 > | ^~~~ 120389 > ../../gdb/windows-nat.c:655:30: note: shadowed declaration is here 120390 > 655 | windows_make_so (const char *name, LPVOID load_addr) 120391 > | ~~~~~~~~~~~~^~~~ 120392 120393 Fix Cygwin build after 85b25bd9 120394 Fix Cygwin build after 85b25bd9 ("Simplify windows-nat.c solib handling"). 120395 120396 Fix Cygwin build after 0578e87f 120397 Fix Cygwin build after 0578e87f ("Remove some globals from 120398 nat/windows-nat.c"). Update code under ifdef __CYGWIN__ for globals 120399 moved to members of struct windows_process_info. 120400 120401 Fix Cygwin build after fcab5839 120402 Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows 120403 in gdbserver"). That change moves code from gdb/windows-nat.c to 120404 gdb/nat/windows-nat.c, but doesn't add the required typedefs and 120405 includes for parts of that code under ifdef __CYGWIN__. 120406 1204072022-06-02 Alan Modra <amodra@gmail.com> 120408 120409 Re: ubsan: signed integer overflow in atof_generic 120410 Oops. 120411 120412 * atof-generic.c: Include limits.h. 120413 1204142022-06-02 Alan Modra <amodra@gmail.com> 120415 120416 ubsan: signed integer overflow in atof_generic 120417 Fix the signed overflows by using unsigned variables and detect 120418 overflow at BUG! comment. 120419 120420 * atof-generic.c (atof_generic): Avoid signed integer overflow. 120421 Return ERROR_EXPONENT_OVERFLOW if exponent overflows a long. 120422 1204232022-06-02 Alan Modra <amodra@gmail.com> 120424 120425 asan: uninit write _bfd_ecoff_write_object_contents 120426 * ecoff.c (_bfd_ecoff_write_object_contents): zalloc reloc_buff. 120427 120428 asan: null deref in coff_write_relocs 120429 * coffcode.h (coff_write_relocs): Don't deref NULL howto. 120430 120431 ubsan: undefined shift in frag_align_code 120432 * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed integer 120433 overflow. 120434 1204352022-06-02 Alan Modra <amodra@gmail.com> 120436 120437 gas read_a_source_file #APP processing 120438 This fixes some horrible code using do_scrub_chars. What we had ran 120439 text through do_scrub_chars twice, directly in read_a_source_file and 120440 again via the input_scrub_include_sb call. That's silly, and since 120441 do_scrub_chars is a state machine, possibly wrong. More silliness is 120442 evident in the temporary malloc'd buffer for do_scrub_chars output, 120443 which should have been written directly to sbuf. 120444 120445 So, get rid of the do_scrub_chars call and support functions, leaving 120446 scrubbing to input_scrub_include_sb. I did wonder about #NO_APP 120447 overlapping input_scrub_next_buffer buffers, but that should only 120448 happen if the string starts in one file and finishes in another. 120449 120450 * read.c (scrub_string, scrub_string_end): Delete. 120451 (scrub_from_string): Delete. 120452 (read_a_source_file): Rewrite #APP processing. 120453 1204542022-06-02 Alan Modra <amodra@gmail.com> 120455 120456 sb_scrub_and_add_sb not draining input string buffer 120457 It is possible for sb_scrub_and_add_sb to not consume all of the input 120458 string buffer. If this happens for reasons explained in the comment, 120459 do_scrub_chars can leave pointers to the string buffer for the next 120460 call. This patch fixes that by ensuring the input is drained. Note 120461 that the behaviour for an empty string buffer is also changed, 120462 avoiding another do_scrub_chars bug where empty input and single char 120463 sized output buffers could result in a write past the end of the 120464 output. 120465 120466 sb.c (sb_scrub_and_add_sb): Loop until all of input sb is 120467 consumed. 120468 1204692022-06-02 Alan Modra <amodra@gmail.com> 120470 120471 asan: heap buffer overflow in dwarf2_directive_filename 120472 Seen with .file 4294967289 "xxx.c" 120473 120474 * dwarf2dbg.c (assign_file_to_slot): Catch more cases of integer 120475 overflow. Make param i an unsigned int. 120476 1204772022-06-02 Alan Modra <amodra@gmail.com> 120478 120479 asan: NULL deref in scan_unit_for_symbols 120480 Since commit b43771b045 it has been possible to look up addresses 120481 that match a unit with errors, since ranges are added to a trie while 120482 the unit is being parsed. On error, parse_comp_unit leaves 120483 first_child_die_ptr NULL which results in a NULL info_ptr being passed 120484 to scan_unit_for_symbols. Fix this by setting unit->error. 120485 120486 Also wrap some overlong lines, and fix some formatting errors. 120487 120488 * dwarf2.c: Formatting. 120489 (parse_comp_unit): Set unit->error on err_exit path. 120490 1204912022-06-02 GDB Administrator <gdbadmin@sourceware.org> 120492 120493 Automatic date update in version.in 120494 1204952022-06-01 Tom de Vries <tdevries@suse.de> 120496 120497 [gdb] Fix warning in foreach_arch selftests 120498 When running the selftests, I run into: 120499 ... 120500 $ gdb -q -batch -ex "maint selftest" 120501 ... 120502 Running selftest execute_cfa_program::aarch64:ilp32. 120503 warning: A handler for the OS ABI "GNU/Linux" is not built into this 120504 configuration of GDB. Attempting to continue with the default aarch64:ilp32 120505 settings. 120506 ... 120507 and likewise for execute_cfa_program::i8086 and 120508 execute_cfa_program::ia64-elf32. 120509 120510 The warning can easily be reproduced outside the selftests by doing: 120511 ... 120512 $ gdb -q -batch -ex "set arch aarch64:ilp32" 120513 ... 120514 and can be prevented by first doing "set osabi none". 120515 120516 Fix the warning by setting osabi to none while doing selftests that iterate 120517 over all architectures. 120518 120519 Tested on x86_64-linux. 120520 1205212022-06-01 Tom Tromey <tromey@adacore.com> 120522 120523 Add gdb.current_language and gdb.Frame.language 120524 This adds the gdb.current_language function, which can be used to find 120525 the current language without (1) ever having the value "auto" or (2) 120526 having to parse the output of "show language". 120527 120528 It also adds the gdb.Frame.language, which can be used to find the 120529 language of a given frame. This is normally preferable if one has a 120530 Frame object handy. 120531 1205322022-06-01 Yvan Roux <yvan.roux@foss.st.com> 120533 120534 [arm] Don't use special treatment for PC 120535 In an exception frame the PC register is extracted from the stack 120536 just like other base registers, so there is no need for a special 120537 treatment. 120538 120539 [arm] Add support for FPU registers in prologue unwinder 120540 The prologue unwinder had support for FPU registers, but only to 120541 calculate the correct offset on the stack, the values were not saved. 120542 1205432022-06-01 Yvan Roux <yvan.roux@foss.st.com> 120544 120545 [arm] d0..d15 are 64-bit each, not 32-bit 120546 When unwinding the stack, the floating point registers d0 to d15 120547 need to be handled as double words, not words. 120548 120549 Only the first 8 registers have been confirmed fixed with this patch 120550 on a STM32F407-DISC0 board, but the upper 8 registers on Cortex-M33 120551 should be handled in the same way. 120552 120553 The test consisted of running a program compiled with float-abi=hard. 120554 In the main function, a function taking a double as an argument was 120555 called. After the function call, a hardware timer was used to 120556 trigger an interrupt. 120557 120558 In the debug session, a breakpoint was set in the function called 120559 from main to verify the content of the registers using "info float" 120560 and another breakpoint in the interrupt handler was used to check 120561 the same registers using "info float" on frame 2 (the frame just 120562 before the dummy frame created for the signal handler in gdb). 120563 1205642022-06-01 Yvan Roux <yvan.roux@foss.st.com> 120565 120566 [arm] Cleanup: use hex for offsets 120567 Changed offset from decimal to hex to match architecture reference 120568 manual terminology and keep coherency with the rest of the code. 120569 1205702022-06-01 Jiangshuai Li <jiangshuai_li@c-sky.com> 120571 120572 gdb:csky save fpu and vdsp info to struct csky_gdbarch_tdep 120573 First, add three variables fpu_abi, fpu_hardfp and vdsp_version 120574 to csky_gdbarch_tdep. They will be initialized from info.abfd in 120575 cskg_gdbarch_init. 120576 120577 Now, they are just used to find a candidate among the list of pre-declared 120578 architectures 120579 120580 Later, they will be used in gdbarch_return_value and gdbarch_push_dummy_call 120581 for funtions described below: 120582 fpu_abi: to check if the bfd is using VAL_CSKY_FPU_ABI_HARD or 120583 VAL_CSKY_FPU_ABI_SOFT 120584 fpu_hardfp: to check if the bfd is using VAL_CSKY_FPU_HARDFP_SINGLE 120585 or VAL_CSKY_FPU_HARDFP_DOUBLE 120586 vdsp_version: to check if a function is returned with CSKY_VRET_REGNUM 120587 1205882022-06-01 Alan Modra <amodra@gmail.com> 120589 120590 Re: use libiberty xmalloc in bfd/doc/chew.c 120591 We can't use libiberty.a in chew. libiberty is a host library, chew 120592 a build program. Partly revert commit 7273d78f3f7a, instead define 120593 local versions of the libiberty functions. ansidecl.h also isn't 120594 needed. 120595 120596 * doc/chew.c: Don't include libiberty.h or ansidecl.h. 120597 (xmalloc, xrealloc, xstrdup): New functions. 120598 * doc/local.mk (LIBIBERTY): Don't define or use. 120599 * Makefile.in: Regenerate. 120600 1206012022-06-01 GDB Administrator <gdbadmin@sourceware.org> 120602 120603 Automatic date update in version.in 120604 1206052022-06-01 H.J. Lu <hjl.tools@gmail.com> 120606 120607 x86: Properly handle IFUNC function pointer reference 120608 Update 120609 120610 commit 68c4956b1401de70173848a6bdf620cb42fa9358 120611 Author: H.J. Lu <hjl.tools@gmail.com> 120612 Date: Tue Apr 26 09:08:54 2022 -0700 120613 120614 x86: Properly handle function pointer reference 120615 120616 to properly handle IFUNC function pointer reference. Since IFUNC symbol 120617 value is only known at run-time, set pointer_equality_needed for IFUNC 120618 function pointer reference in PDE so that it will be resolved to its PLT 120619 entry directly. 120620 120621 bfd/ 120622 120623 PR ld/29216 120624 * elf32-i386.c (elf_i386_scan_relocs): Set pointer_equality_needed 120625 for IFUNC function pointer reference in PDE. 120626 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 120627 120628 ld/ 120629 120630 PR ld/29216 120631 * testsuite/ld-ifunc/ifunc.exp: Run PR ld/29216 test. 120632 * testsuite/ld-ifunc/pr29216.c: New file. 120633 1206342022-05-31 H.J. Lu <hjl.tools@gmail.com> 120635 120636 i386: Ajdust more tests for opcodes/i386: remove trailing whitespace 120637 This fixes: 120638 120639 FAIL: Build ifunc-1a with -z ibtplt 120640 FAIL: Build ifunc-1a with PIE -z ibtplt 120641 FAIL: Build libno-plt-1b.so 120642 FAIL: No PLT (dynamic 1a) 120643 FAIL: No PLT (dynamic 1b) 120644 FAIL: No PLT (dynamic 1c) 120645 FAIL: No PLT (static 1d) 120646 FAIL: No PLT (PIE 1e) 120647 FAIL: No PLT (PIE 1f) 120648 FAIL: No PLT (PIE 1g) 120649 FAIL: No PLT (dynamic 1h) 120650 FAIL: No PLT (dynamic 1i) 120651 FAIL: No PLT (static 1j) 120652 120653 * ld-i386/libno-plt-1b.dd: Remove trailing whitespaces. 120654 * ld-i386/no-plt-1a.dd: Likewise. 120655 * ld-i386/no-plt-1b.dd: Likewise. 120656 * ld-i386/no-plt-1c.dd: Likewise. 120657 * ld-i386/no-plt-1d.dd: Likewise. 120658 * ld-i386/no-plt-1e.dd: Likewise. 120659 * ld-i386/no-plt-1f.dd: Likewise. 120660 * ld-i386/no-plt-1g.dd: Likewise. 120661 * ld-i386/no-plt-1h.dd: Likewise. 120662 * ld-i386/no-plt-1i.dd: Likewise. 120663 * ld-i386/no-plt-1j.dd: Likewise. 120664 * ld-i386/plt-main-ibt.dd: Likewise. 120665 * ld-i386/plt-pie-ibt.dd: Likewise. 120666 1206672022-05-31 Tom Tromey <tom@tromey.com> 120668 120669 Use unique_ptr for objfiles 120670 A while back, I changed objfiles to be held via a shared_ptr. The 120671 idea at the time was that this was a step toward writing to the index 120672 cache in the background, and this would let gdb keep a reference alive 120673 to do so. However, since then we've rewritten the DWARF reader, and 120674 the new index can do this without requiring a shared pointer -- in 120675 fact there are patches pending to implement this. 120676 120677 This patch switches objfile management to unique_ptr, which makes more 120678 sense now. 120679 120680 Regression tested on x86-64 Fedora 34. 120681 1206822022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 120683 120684 gdb/testsuite: fixup common-block.exp for intel compilers 120685 The order in which the variables in info common and info locals are 120686 displayed is compiler (and dwarf) dependent. While all symbols should 120687 be displayed the order is not fixed. 120688 120689 I added a gdb_test_multiple that lets ifx and ifort pass in cases where 120690 only the order differs. 120691 1206922022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 120693 120694 gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers 120695 When value-printing a pointer within GDB by default GDB will look for 120696 defined symbols residing at the address of the pointer. For the given 120697 test the Intel/LLVM compiler stacks both display a symbol associated 120698 with a printed pointer while the gnu stack does not. This leads to 120699 failures in the test when running the test with CC_FOR_TARGET='clang' 120700 CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'" 120701 120702 (gdb) b 37 120703 (gdb) r 120704 (gdb) f 6 120705 (gdb) info args 120706 a = 1 120707 b = 2 120708 c = 3 120709 d = 4 + 5i 120710 f = 0x419ed0 "abcdef" 120711 g = 0x4041a0 <.BSS4> 120712 120713 or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'" 120714 120715 (gdb) b 37 120716 (gdb) r 120717 (gdb) f 6 120718 (gdb) info args 120719 a = 1 120720 b = 2 120721 c = 3 120722 d = 4 + 5i 120723 f = 0x52eee0 "abcdef" 120724 g = 0x4ca210 <mixed_func_1a_$OBJ> 120725 120726 For the compiled binary the Intel/LLVM compilers both decide to move the 120727 local variable g into the .bss section of their executable. The gnu 120728 stack will keep the variable locally on the stack and not define a 120729 symbol for it. 120730 120731 Since the behavior for Intel/LLVM is actually expected I adapted the 120732 testcase at this point to be a bit more allowing for other outputs. 120733 I added the optional "<SYMBOLNAME>" to the regex testing for g. 120734 120735 The given changes reduce the test fails for Intel/LLVM stack by 4 each. 120736 1207372022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 120738 120739 gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp 120740 While testing mixed-lang-stack I realized that valgrind actually 120741 complained about a double free in the test. 120742 120743 All done 120744 ==2503051== 120745 ==2503051== HEAP SUMMARY: 120746 ==2503051== in use at exit: 0 bytes in 0 blocks 120747 ==2503051== total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated 120748 ==2503051== 120749 ==2503051== All heap blocks were freed -- no leaks are possible 120750 ==2503051== 120751 ==2503051== For lists of detected and suppressed errors, rerun with: -s 120752 ==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) 120753 120754 Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an 120755 object "derived_type obj" goes on the stack which is then passed-by-value 120756 (so copied) to mixed_func_1g. The default copy-ctor will be called but, 120757 since derived_type contains a heap allocated string and the copy 120758 constructor is not implemented it will only be able to shallow copy the 120759 object. Right after each of the functions the object gets freed - on the 120760 other hand the d'tor of derived_type actually is implemented and calls 120761 free on the heap allocated string which leads to a double free. Instead 120762 of obeying the rule of 3/5 I just got rid of all that since it does not 120763 serve the test. The string is now just a const char* = ".." object 120764 member. 120765 1207662022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 120767 120768 testsuite, fortran: allow additional completions in module.exp 120769 For ifort, ifx, and flang the tests "complete modm" and "complete 120770 modmany" fail. This is because all three emit additional completion 120771 suggestions. These additional suggestions have their origin in symbols 120772 emitted by the compilers which can also be completed from the respective 120773 incomplete word (modm or modmany). For this specific example gfortran 120774 does not emit any additional symbols. 120775 120776 For example, in this test the linkage name for var_a in ifx is 120777 "modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead. 120778 Since modmany_mp_var_a can be completed from modm and also modmany they 120779 will get displayed, while gfortran's symbol starts with "__" and thus will 120780 be ignored (it cannot be a completion of a word starting with "m"). 120781 120782 Similar things happen in flang and ifort. Some example output is shown 120783 below: 120784 120785 FLANG 120786 (gdb) complete p modm 120787 p modmany 120788 p modmany::var_a 120789 p modmany::var_b 120790 p modmany::var_c 120791 p modmany::var_i 120792 p modmany_ 120793 120794 IFX/IFORT 120795 (gdb) complete p modm 120796 p modmany 120797 p modmany._ 120798 p modmany::var_a 120799 p modmany::var_b 120800 p modmany::var_c 120801 p modmany::var_i 120802 p modmany_mp_var_a_ 120803 p modmany_mp_var_b_ 120804 p modmany_mp_var_c_ 120805 p modmany_mp_var_i_ 120806 120807 GFORTRAN 120808 (gdb) complete p modm 120809 p modmany 120810 p modmany::var_a 120811 p modmany::var_b 120812 p modmany::var_c 120813 p modmany::var_i 120814 120815 I want to emphasize: for Fortran (and also C/C++) the complete command 120816 does not actually check whether its suggestions make sense - all it does 120817 is look for any symbol (in the minimal symbols, partial symbols etc.) 120818 that a given substring can be completed to (meaning that the given substring 120819 is the beginning of the symbol). One can easily produce a similar 120820 output for the gfortran compiled executable. For this look at the 120821 slightly modified "complete p mod" in gfortran: 120822 120823 (gdb) complete p mod 120824 p mod1 120825 p mod1::var_const 120826 ... 120827 p mod_1.c 120828 p modcounter 120829 p mode_t 120830 p modf 120831 ... 120832 p modify_ldt 120833 p modmany 120834 p modmany::var_a 120835 p modmany::var_b 120836 p modmany::var_c 120837 p modmany::var_i 120838 p module 120839 p module.f90 120840 p module_entry 120841 p moduse 120842 p moduse::var_x 120843 p moduse::var_y 120844 120845 Many of the displayed symbols do not actually work with print: 120846 120847 (gdb) p mode_t 120848 Attempt to use a type name as an expression 120849 (gdb) p mod_1.c 120850 No symbol "mod_1" in current context. 120851 (gdb) 120852 120853 I think that in the given test the output for gfortran only looks nice 120854 "by chance" rather than is actually expected. Expected is any output 120855 that also contains the completions 120856 120857 p modmany 120858 120859 p modmany::var_a 120860 p modmany::var_b 120861 p modmany::var_c 120862 p modmany::var_i 120863 120864 while anythings else can be displayed as well (depending on the 120865 compiler and its emitted symbols). 120866 120867 This, I'd consider all three outputs as valid and expected - one is just 120868 somewhat lucky that gfortran does not produce any additional symbols that 120869 got matched. 120870 120871 The given patch improves test performance for all three compilers 120872 by allowing additional suggested completions inbetween and after 120873 the two given blocks in the test. I did not allow additional print 120874 within the modmany_list block since the output is ordered alphabetically 120875 and there should normally not appear any additional symbols there. 120876 120877 For flang/ifx/ifort I each see 2 failures less (which are exactly the two 120878 complete tests). 120879 120880 As a side note and since I mentioned C++ in the beginning: I also tried 120881 the gdb.cp/completion.exp. The output seems a bit more reasonable, 120882 mainly since C++ actually has a demangler in place and linkage symbols 120883 do not appear in the output of complete. Still, with a poor enough 120884 to-be-completed string one can easily produce similar results: 120885 120886 (gdb) complete p t 120887 ... 120888 p typeinfo name for void 120889 p typeinfo name for void const* 120890 p typeinfo name for void* 120891 p typeinfo name for wchar_t 120892 p typeinfo name for wchar_t const* 120893 p typeinfo name for wchar_t* 120894 p t *** List may be truncated, max-completions reached. *** 120895 (gdb) p typeinfo name for void* 120896 No symbol "typeinfo" in current context. 120897 (gdb) complete p B 120898 p BACK_SLASH 120899 p BUF_FIRST 120900 p BUF_LAST 120901 ... 120902 p Base 120903 p Base::Base() 120904 p Base::get_foo() 120905 p bad_key_err 120906 p buf 120907 p buffer 120908 p buffer_size 120909 p buflen 120910 p bufsize 120911 p build_charclass.isra 120912 (gdb) p bad_key_err 120913 No symbol "bad_key_err" in current context. 120914 120915 (compiled with gcc/g++ and breaking at main). 120916 120917 This patch is only about making the referenced test more 'fair' for the 120918 other compilers. Generally, I find the behavior of complete a bit 120919 confusing and maybe one wants to change this at some point but this 120920 would be a bigger task. 120921 1209222022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 120923 120924 testsuite, fortran: fix info-types for intel compilers 120925 This info-types.exp test case had a few issues that this patch fixes. 120926 120927 First, the emitted symbol character(kind=1)/character*1 (different 120928 compilers use different naming converntions here) which is checkedin the 120929 test is not actually expected given the test program. There is no 120930 variable of that type in the test. Still, gfortran emits it for every 120931 Fortran program there is. The reason is the way gfortran handles Fortran's 120932 named main program. It generates a wrapper around the Fortran program 120933 that is quite similar to a C main function. This C-like wrapper has 120934 argc and argv arguments for command line argument passing and the argv 120935 pointer type has a base type character(kind=1) DIE emitted at CU scope. 120936 120937 Given the program 120938 120939 program prog 120940 end program prog 120941 120942 the degbug info gfortran emits looks somewhat like 120943 120944 <0><c>: Abbrev Number: 3 (DW_TAG_compile_unit) 120945 ... 120946 <1><2f>: Abbrev Number: 4 (DW_TAG_subprogram) 120947 <30> DW_AT_external : 1 120948 <30> DW_AT_name : (indirect string, ...): main 120949 ... 120950 <2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter) 120951 <52> DW_AT_name : (indirect string, ...): argc 120952 ... 120953 <2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter) 120954 <5e> DW_AT_name : (indirect string, ...): argv 120955 ... 120956 <62> DW_AT_type : <0x77> 120957 ... 120958 <2><6a>: Abbrev Number: 0 120959 ... 120960 <1><77>: Abbrev Number: 6 (DW_TAG_pointer_type) 120961 <78> DW_AT_byte_size : 8 120962 <79> DW_AT_type : <0x7d> 120963 <1><7d>: Abbrev Number: 2 (DW_TAG_base_type) 120964 <7e> DW_AT_byte_size : 1 120965 <7f> DW_AT_encoding : 8 (unsigned char) 120966 <80> DW_AT_name : (indirect string, ...): character(kind=1) 120967 <1><84>: Abbrev Number: 7 (DW_TAG_subprogram) 120968 <85> DW_AT_name : (indirect string, ...): prog 120969 ... 120970 120971 Ifx and flang do not emit any debug info for a wrapper main method so 120972 the type is missing here. There was the possibility of actually adding 120973 a character*1 type variable to the Fortran executable, but both, ifx and 120974 gfortran chose to emit this variable's type as a DW_TAG_string_type of 120975 length one (instead of a character(kind=1), or whatever the respective 120976 compiler naming convention is). While string types are printed as 120977 character*LENGHT in the fortran language part (e.g. when issuing a 120978 'ptype') they do not generate any symbols inside GDB. In read.c it says 120979 120980 /* These dies have a type, but processing them does not create 120981 a symbol or recurse to process the children. Therefore we can 120982 read them on-demand through read_type_die. */ 120983 120984 So they did not add any output to 'info types'. Only flang did emit a 120985 character type here. 120986 As adding a type would have a) not solved the problem for ifx and would 120987 have b) somehow hidden the curious behavior of gfortran, instead, the 120988 check for this character type was chagened to optional with the 120989 check_optional_entry to allow for the symbols's absence and to allow 120990 flang and ifx to pass this test as well. 120991 120992 Second, the line checked for s1 was hardcoded as 37 in the test. Given 120993 that the type is actually defined on line 41 (which is what is emitted by 120994 ifx) it even seems wrong. The line check for s1 was changed to actually 120995 check for 41 and a gfortran bug has been filed here 120996 120997 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454 120998 120999 The test is now marked as xfail for gfortran. 121000 121001 Third, the whole test of checking for the 'Type s1' in info types seemed 121002 questionable. The type s1 is declared iside the scope of the Fortran 121003 program info_types_test. Its DIE however is emitted as a child of the 121004 whole compilation unit making it visible outside of the program's scope. 121005 The 'info types' command checks for types stored in the GLOBAL_BLOCK, 121006 or STATIC_BLOCKm wgucm according to block.h 121007 121008 The GLOBAL_BLOCK contains all the symbols defined in this compilation 121009 whose scope is the entire program linked together. 121010 The STATIC_BLOCK contains all the symbols whose scope is the 121011 entire compilation excluding other separate compilations. 121012 121013 so for gfortran, the type shows up in the output of 'info types'. For 121014 flang and ifx on the other hand this is not the case. The two compilers 121015 emit the type (correctly) as a child of the Fortran program, thus not 121016 adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK. A bug has 121017 been opened for the gfortran scoping issue: 121018 121019 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454 121020 121021 While the most correct change might have been removing the check for s1, 121022 the change made here was to only check for this type in case of gfortran 121023 being used as the compiler, as this check also covers the declaration 121024 line issue mentioned above. A comment was added to maybe remove this 121025 check once the scoping issue is resolved (and it starts to fail with 121026 newer gfortran versions). The one used to test these changes was 13.0. 121027 1210282022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121029 121030 testsuite/lib: add check_optional_entry for GDBInfoSymbols 121031 There was already a similar functionality for the GDBInfoModuleSymbols. 121032 This just extends the GDBInfoSymbols. We will use this feature in a 121033 later commit to make a testcase less GNU specific and more flexible for 121034 other compilers. 121035 121036 Namely, in gdb.fortran/info-types.exp currenlty 121037 GDBInfoSymbols::check_entry is used to verify and test the output of the 121038 info symbols command. The test, however was written with gfortran as a 121039 basis and some of the tests are not fair with e.g. ifx and ifort as 121040 they test for symbols that are not actually required to be emitted. The 121041 lines 121042 GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}" 121043 and 121044 GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;" 121045 121046 check for types that are either not used in the source file (character1) 121047 or should not be emitted by the compiler at global scope (s1) thus no 121048 appearing in the info symbols command. In order to fix this we will 121049 later use the newly introduced check_optional_entry over check_entry. 121050 1210512022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121052 121053 testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort 121054 In order for ifx and ifort to emit all debug entries, even for unused 121055 parameters in modules we have to define the '-debug-parameters all' flag. 121056 121057 This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp. 121058 1210592022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121060 121061 testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis 121062 The test was earlier not using the compiler dependent type print system 121063 in fortran.exp. I changed this. It should generally improve the test 121064 performance for different compilers. For ifx and gfortran I do not see 121065 any failures. 121066 1210672022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121068 121069 testsuite, fortran: add required external keyword 121070 Currenlty, ifx/ifort cannot compile the given executable as it is not 121071 valid Fortran. It is missing the external keyword on the 121072 no_arg_subroutine. Gfortran compiles the example but this is actually 121073 a bug and there is an open gcc ticket for this here: 121074 121075 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377 121076 121077 Adding the keyword does not change the gfortran compiling of the example. 121078 It will, however, prevent a future fail once 50377 has been addressed. 121079 1210802022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121081 121082 gdb/testsuite: disable charset.exp for intel compilers 121083 The test specifically tests for the Fortran CHARACTER(KIND=4) which is 121084 not available in ifx/ifort. 121085 121086 Since the other characters are also printed elsewhere, we disable this 121087 test for the unsupported compilers. 121088 1210892022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121090 121091 gdb/testsuite: rename intel next gen c/cpp compilers 121092 The name for icx and icpx in the testsuite was earlier set to 'intel-*' 121093 by the compiler identification. This commit changes this to 'icx-*'. 121094 121095 Note, that currently these names are not used within the testsuite so no 121096 tests have to be adapted here. 121097 1210982022-05-31 Cristian Sandu <cristian.sandu@intel.com> 121099 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121100 121101 gdb/testsuite: add Fortran compiler identification to GDB 121102 This commit adds a separate Fortran compiler identification mechanism to 121103 the testsuite, similar to the existing one for C/C++. Before this 121104 change, the options and version for the Fortran compiler specified when 121105 running the testsuite with F90_FOR_TARGET set, was detected via its 121106 respective C compiler. So running the testsuite as 121107 121108 make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx 121109 121110 or even 121111 121112 make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx 121113 121114 would use the gcc compiler inside the procedures get_compiler_info and 121115 test_compiler_info to identify compiler flags and the compiler version. 121116 This could sometimes lead to unpredictable outputs. It also limited 121117 testsuite execution to combinations where C and Fortran compiler would 121118 come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx, 121119 clang/flang ..). This commit enables GDB to detect C and Fortran 121120 compilers independently of each other. 121121 121122 As most/nearly all Fortran compilers have a mechanism for preprocessing 121123 files in a C like fashion we added the exact same meachnism that already 121124 existed for C/CXX. We let GDB preprocess a file with the compilers 121125 Fortran preprocessor and evaluate the preprocessor defined macros in that 121126 file. 121127 121128 This enables GDB to properly run heterogeneous combinations of C and 121129 Fortran compilers such as 121130 121131 CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort' 121132 121133 or enables one to run the testsuite without specifying a C compiler as in 121134 121135 make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx' 121136 make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang' 121137 121138 On the other hand this also requires one to always specify a 121139 identification mechanism for Fortran compilers in the compiler.F90 file. 121140 121141 We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX, 121142 IFORT, and ARMFLANG for now. 121143 121144 Classic and LLVM flang were each tested with their latest releases on 121145 their respective release pages. Both get recognized by the new compiler 121146 identification and we introduced the two names flang-classic and 121147 flang-llvm to distinguish the two. While LLVM flang is not quite mature 121148 enough yet for running the testsuite we still thought it would be a good 121149 idea to include it already. For this we added a case for the fortran_main 121150 procedure. LLVM flang uses 'MAIN__' as opposed to classic flang which 121151 uses 'MAIN_' here. 121152 121153 We did not have the possibility to test ARMFLANG - the versioning scheme 121154 here was extracted from its latest online documentation. 121155 121156 We changed the test_compiler_info procedure to take another optional 121157 argument, the language string, which will be passed though to the 121158 get_compiler_info procedure. Passing 'f90' or 'c++' here will then 121159 trigger the C++/Fortran compiler identification within 121160 get_compiler_info. The latter procedure was extended to also handle 121161 the 'f90' argument (similarly to the already existing 'c++' one). 121162 1211632022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121164 121165 gdb/testsuite: move getting_compiler_info to front of gdb_compile 121166 The procedure gdb_compile queries its options via 121167 121168 [lsearch -exact $options getting_compiler_info] 121169 121170 to check whether or not it was called in with the option 121171 getting_compiler_info. If it was called with this option it would 121172 preprocess some test input to try and figure out the actual compiler 121173 version of the compiler used. While doing this we cannot again try to 121174 figure out the current compiler version via the 'getting_compiler_info' 121175 option as this would cause infinite recursion. As some parts of the 121176 procedure do recursively test for the compiler version to e.g. set 121177 certain flags, at several places gdb_compile there are checks for the 121178 getting_compiler_info option needed. 121179 121180 In the procedure, there was already a variable 'getting_compiler_info' 121181 which was set to the result of the 'lsearch' query and used instead of 121182 again and again looking for getting_compiler_info in the procedure 121183 options. But, this variable was actually set too late within the code. 121184 This lead to a mixture of querying 'getting_compiler_info' or 121185 doing an lserach on the options passed to the procedure. 121186 121187 I found this inconsistent and instead moved the variable 121188 getting_compiler_info to the front of the procedure. It is set to true 121189 or false depending on whether or not the argument is found in the 121190 procedure's options (just as before) and queried instead of doing an 121191 lsearch on the procedure options in the rest of the procedure. 121192 1211932022-05-31 Felix Willgerodt <felix.willgerodt@intel.com> 121194 Abdul Basit Ijaz <abdul.b.ijaz@intel.com> 121195 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121196 121197 gdb/testsuite: Fix fortran types for Intel compilers. 121198 Newer Intel compilers emit their dwarf type name in a slightly different 121199 format. Therefore, this needs adjustment to make more tests pass in the 121200 Fortran testsuite. 121201 1212022022-05-31 Abdul Basit Ijaz <abdul.b.ijaz@intel.com> 121203 121204 gdb/testsuite: Use -module option for Intel Fortran compilers 121205 The '-J' option is not supported in Intel compilers (ifx and ifort). 121206 The Intel version of the flag is '-module' which serves the same purpose. 121207 1212082022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 121209 121210 gdb/testsuite: remove F77_FOR_TARGET support 121211 The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile 121212 procedure were removed in this commit 121213 121214 commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257 121215 Author: Tom Tromey <tromey@redhat.com> 121216 Date: Wed Jun 29 17:50:47 2011 +0000 121217 121218 over 10 years ago. The last .f files in the testsuite by now are all 121219 being compiled by passing 'f90' to the GDB compile, thus only actually 121220 using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f). 121221 Gfortran in this case is backwards compatible with most f77 code as 121222 claimed on gcc.gnu.org/fortran. 121223 121224 The reason we'd like to get rid of this now is, that we'll be 121225 implementing a Fortran compiler identification mechanism, similar to the 121226 C/Cpp existing ones. It would be using the Fortran preprocessor macro 121227 defines to identify the Fortran compiler version at hand. We found it 121228 inconsequent to only implement this for f90 but, on the other hand, f77 121229 seems deprecated. So, with this commit we remove the remaining lines for 121230 its support. 121231 1212322022-05-31 Pedro Alves <pedro@palves.net> 121233 121234 Improve clear command's documentation 121235 Co-Authored-By: Eli Zaretskii <eliz@gnu.org> 121236 121237 Change-Id: I9440052fd28f795d6f7c93a4576beadd21f28885 121238 1212392022-05-31 Pedro Alves <pedro@palves.net> 121240 121241 Clarify why we unit test matching symbol names with 0xff characters 121242 In the name matching unit tests in gdb/dwarf2/read.c, explain better 121243 why we test symbols with \377 / 0xff characters (Latin1 'ÿ'). 121244 121245 Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e 121246 1212472022-05-31 Pedro Alves <pedro@palves.net> 121248 121249 Improve break-range's documentation 121250 Change-Id: Iac26e1d2e7d8dc8a7d9516e6bdcc5c3fc4af45c8 121251 121252 Explicitly mention yet-unloaded shared libraries in location spec examples 121253 Change-Id: I05639ddb3bf620c7297b57ed286adc3aa926b7b6 121254 1212552022-05-31 Alan Modra <amodra@gmail.com> 121256 121257 sparc64 segfault in finish_dynamic_symbol 121258 SYMBOL_REFERENCES_LOCAL can return true for undefined symbols. This 121259 can result in a segfault when running sparc64 ld/testsuite/ld-vsb 121260 tests that expect a failure. 121261 121262 * elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't 121263 access u.def.section on non-default visibility undefined symbol. 121264 1212652022-05-31 Alan Modra <amodra@gmail.com> 121266 121267 ia64 gas: Remove unnecessary init 121268 The whole struct is cleared by alloc_record. 121269 121270 * config/tc-ia64.c (output_prologue, output_prologue_gr): Don't 121271 zero r.record.r.mask. 121272 1212732022-05-31 Alan Modra <amodra@gmail.com> 121274 121275 v850_elf_set_note prototype 121276 v850_elf_set_note is declared using an unsigned int note param in 121277 elf32-v850.h but defined with enum c850_notes note in elf32-v850.c. 121278 Current mainline gcc is warning about this. Huh. 121279 121280 * elf32-v850.c (v850_elf_set_note): Make "note" param an 121281 unsigned int. 121282 1212832022-05-31 Alan Modra <amodra@gmail.com> 121284 121285 Import libiberty from gcc 121286 PR 29200 121287 include/ 121288 * ansidecl.h, 121289 * demangle.h: Import from gcc. 121290 libiberty/ 121291 * cp-demangle.c, 121292 * testsuite/demangle-expected: Import from gcc. 121293 1212942022-05-31 Andrew Burgess <aburgess@redhat.com> 121295 121296 gdb/testsuite: resolve duplicate test name in gdb.trace/signal.exp 121297 Spotted a duplicate test name in gdb.trace/signal.exp, resolved in 121298 this commit by making use of 'with_test_prefix'. 121299 1213002022-05-31 Alan Modra <amodra@gmail.com> 121301 121302 Ajdust more tests for opcodes/i386: remove trailing whitespace 121303 git commit 202be274a4 also missed adjusting a few testsuite files. 121304 This fixes 121305 i686-vxworks +FAIL: VxWorks shared library test 1 121306 i686-vxworks +FAIL: VxWorks executable test 1 (dynamic) 121307 1213082022-05-31 Alan Modra <amodra@gmail.com> 121309 121310 Trailing spaces in objdump -r header 121311 git commit 202be274a4 went a little wild in removing trailing spaces 121312 in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing 121313 x86_64-w64-mingw32 +FAIL: i386 secrel reloc 121314 x86_64-w64-mingw32 +FAIL: i386 secidx reloc 121315 121316 I could have just replaced the trailing space, but let's fix the 121317 objdump output instead. Touches lots of testsuite files. 121318 1213192022-05-31 GDB Administrator <gdbadmin@sourceware.org> 121320 121321 Automatic date update in version.in 121322 1213232022-05-30 Simon Marchi <simon.marchi@efficios.com> 121324 121325 gdb/testsuite: fix gdb.trace/signal.exp on x86 121326 Patch 121327 121328 202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands") 121329 121330 causes this regression: 121331 121332 FAIL: gdb.trace/signal.exp: find syscall insn in kill 121333 121334 It's because the test still expects to match a whitespace after the 121335 instruction, which the patch mentioned above removed. Remove the 121336 whitespaces for the regexp. 121337 121338 Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428 121339 1213402022-05-30 Pedro Alves <pedro@palves.net> 121341 121342 gdb/manual: Introduce location specs 121343 The current "Specify Location" section of the GDB manual starts with: 121344 121345 "Several @value{GDBN} commands accept arguments that specify a location 121346 of your program's code." 121347 121348 And then, such commands are documented as taking a "location" 121349 argument. For example, here's a representative subset: 121350 121351 @item break @var{location} 121352 @item clear @var{location} 121353 @item until @var{location} 121354 @item list @var{location} 121355 @item edit @var{location} 121356 @itemx info line @var{location} 121357 @item info macros @var{location} 121358 @item trace @var{location} 121359 @item info scope @var{location} 121360 @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression} 121361 121362 The issue here is that "location" isn't really correct for most of 121363 these commands. Instead, the "location" argument is really a 121364 placeholder that represent an umbrella term for all of the 121365 "linespecs", "explicit location", and "address location" input 121366 formats. GDB parses these and then finds the actual code locations 121367 (plural) in the program that match. For example, a "location" 121368 specified like "-function func" will actually match all the code 121369 locations in the program that correspond to the address/file/lineno of 121370 all the functions named "func" in all the loaded programs and shared 121371 libraries of all the inferiors. A location specified like "-function 121372 func -label lab" matches all the addresses of C labels named "lab" in 121373 all functions named "func". Etc. 121374 121375 This means that several of the commands that claim they accept a 121376 "location", actually end up working with multiple locations, and the 121377 manual doesn't explain that all that well. In some cases, the command 121378 will work with all the resolved locations. In other cases, the 121379 command aborts with an error if the location specification resolves to 121380 multiple locations in the program. In other cases, GDB just 121381 arbitrarily and silently picks whatever is the first resolved code 121382 location (which sounds like should be improved). 121383 121384 To clarify this, I propose we use the term "Location Specification", 121385 with shorthand "locaction spec", when we're talking about the user 121386 input, the argument or arguments that is/are passed to commands to 121387 instruct GDB how to find locations of interest. This is distinct from 121388 the actual code locations in the program, which are what GDB finds 121389 based on the user-specified location spec. Then use "location 121390 specification or the shorter "location spec" thoughout instead of 121391 "location" when we're talking about the user input. 121392 121393 Thus, this commit does the following: 121394 121395 - renames the "Specify Location" section of the manual to "Location 121396 Specifications". 121397 121398 - It then introduces the term "Location Specification", with 121399 corresponding shorthand "location spec", as something distinct from 121400 an actual code location in the program. It explains what a concrete 121401 code location is. It explains that a location specification may be 121402 incomplete, and that may match multiple code locations in the 121403 program, or no code location at all. It gives examples. Some 121404 pre-existing examples were moved from the "Set Breaks" section, and 121405 a few new ones that didn't exist yet were added. I think it is 121406 better to have these centralized in this "Location Specification" 121407 section, since all the other commands that accept a location spec 121408 have an xref that points there. 121409 121410 - Goes through the manual, and where "@var{location}" was used for a 121411 command argument, updated it to say "@var{locspec}" instead. At the 121412 same time, tweaks the description of the affected commands to 121413 describe what happens when the location spec resolves to more than 121414 one location. Most commands just did not say anything about that. 121415 121416 One command -- "maint agent -at @var{location}" -- currently says it 121417 accepts a "location", suggesting it can accept address and explicit 121418 locations too, but that's incorrect. In reality, it only accepts 121419 linespecs, so fix it accordingly. 121420 121421 One MI command -- "-trace-find line" -- currently says it accepts a 121422 "line specification", but it can accept address and explicit 121423 locations too, so fix it accordingly. 121424 121425 Special thanks goes to Eli Zaretskii for reviews and rewording 121426 suggestions. 121427 121428 Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b 121429 1214302022-05-30 Luis Machado <luis.machado@arm.com> 121431 121432 Move 64-bit BFD files from ALL_TARGET_OBS to ALL_64_TARGET_OBS 121433 Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link 121434 properly. 121435 121436 -- 121437 121438 loongarch-tdep.o: In function `loongarch_gdbarch_init': 121439 binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name' 121440 loongarch-tdep.o: In function `loongarch_fetch_instruction': 121441 binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length' 121442 loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]': 121443 binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length' 121444 binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm' 121445 binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm' 121446 binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm' 121447 binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm' 121448 binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm' 121449 121450 -- 121451 121452 Given the list of 64-bit BFD files in 121453 opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's 121454 ALL_TARGET_OBS list is including files that should be included in 121455 ALL_64_TARGET_OBS instead. 121456 121457 This patch accomplishes this and enables a 32-bit build with 121458 "--enable-targets=all --disable-sim" to complete. 121459 121460 Moving the bpf, tilegx and loongarch files to the correct list means GDB can 121461 find the correct disassembler function instead of finding a null pointer. 121462 121463 We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to 121464 make a 32-bit build with "--enable-targets=all" complete correctly 121465 1214662022-05-30 Luis Machado <luis.machado@arm.com> 121467 121468 Fix failing test for armeb-gnu-eabi 121469 The following test fails on the armeb-gnu-eabi target: 121470 121471 FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension 121472 121473 This patch adjusts the expected output for big endian. 121474 1214752022-05-30 Alan Modra <amodra@gmail.com> 121476 121477 Use a union to avoid casts in bfd/doc/chew.c 121478 This fixes -Wpedantic warnings in chew.c. Conversion between function 121479 and object pointers is not guaranteed. They can even be different 121480 sizes, not that we're likely to encounter build machines like that 121481 nowadays. 121482 121483 PR 29194 121484 * doc/chew.c (pcu): New union typedef. 121485 (dict_type, pc): Use it here. Adjust uses of pc. 121486 (add_to_definition): Make "word" param a pcu. Adjust all uses 121487 of function. 121488 (stinst_type): Delete. 121489 1214902022-05-30 Alan Modra <amodra@gmail.com> 121491 121492 use libiberty xmalloc in bfd/doc/chew.c 121493 Catch out of memory. 121494 121495 * doc/chew.c: Include libibery.h. 121496 (init_string_with_size, nextword): Replace malloc with xmalloc. 121497 (newentry, add_to_definition): Likewise. 121498 (catchar, catbuf): Replace realloc with xrealloc. 121499 (add_intrinsic): Replace strdup with xstrdup. 121500 * doc/local.mk (LIBIBERTY): Define. 121501 (chew): Link against libiberty. 121502 * Makefile.in: Regenerate. 121503 1215042022-05-30 Alan Modra <amodra@gmail.com> 121505 121506 Update K&R functions in bfd/doc/chew.c 121507 * doc/chew.c: Update function definitions to ISO C, remove 121508 now unnecessary prototypes. 121509 1215102022-05-30 Alan Modra <amodra@gmail.com> 121511 121512 Reorganise bfd/doc/chew.c a little 121513 This also removes some unused variables, and deletes support for the 121514 "var" keyword which isn't used and was broken. (No means to set 121515 variables, and add_var used push_number inconsistent with its use 121516 elsewhere.) 121517 121518 * doc/chew.c: Move typedefs before variables, variables before 121519 functions. 121520 (die): Move earlier. 121521 (word_type, sstack, ssp): Delete. 121522 (dict_type): Delete var field. 121523 (add_var): Delete. 121524 (compile): Remove "var" support. 121525 1215262022-05-30 jiawei <jiawei@iscas.ac.cn> 121527 121528 RISC-V: Add zhinx extension supports. 121529 The zhinx extension is a sub-extension in zfinx, corresponding to 121530 zfh extension but use GPRs instead of FPRs. 121531 121532 This patch expanded the zfh insn class define, since zfh and zhinx 121533 use the same opcodes, thanks for Nelson's works. 121534 121535 changelog in V2: Add missing classes of 'zfh' and 'zhinx' in 121536 "riscv_multi_subset_supports_ext". 121537 121538 bfd/ChangeLog: 121539 121540 * elfxx-riscv.c (riscv_multi_subset_supports): New extensions. 121541 (riscv_multi_subset_supports_ext): New extensions. 121542 121543 gas/ChangeLog: 121544 121545 * testsuite/gas/riscv/fp-zhinx-insns.d: New test. 121546 * testsuite/gas/riscv/fp-zhinx-insns.s: New test. 121547 121548 include/ChangeLog: 121549 121550 * opcode/riscv.h (enum riscv_insn_class): New INSN classes. 121551 121552 opcodes/ChangeLog: 121553 121554 * riscv-opc.c: Modify INSN_CLASS. 121555 1215562022-05-30 GDB Administrator <gdbadmin@sourceware.org> 121557 121558 Automatic date update in version.in 121559 1215602022-05-29 GDB Administrator <gdbadmin@sourceware.org> 121561 121562 Automatic date update in version.in 121563 1215642022-05-28 Andrew Burgess <aburgess@redhat.com> 121565 121566 gdb/python: improve formatting of help text for user defined commands 121567 Consider this command defined in Python (in the file test-cmd.py): 121568 121569 class test_cmd (gdb.Command): 121570 """ 121571 This is the first line. 121572 Indented second line. 121573 This is the third line. 121574 """ 121575 121576 def __init__ (self): 121577 super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE) 121578 121579 def invoke (self, arg, from_tty): 121580 print ("In test-cmd") 121581 121582 test_cmd() 121583 121584 Now, within a GDB session: 121585 121586 (gdb) source test-cmd.py 121587 (gdb) help test-cmd 121588 121589 This is the first line. 121590 Indented second line. 121591 This is the third line. 121592 121593 (gdb) 121594 121595 I think there's three things wrong here: 121596 121597 1. The leading blank line, 121598 2. The trailing blank line, and 121599 3. Every line is indented from the left edge slightly. 121600 121601 The problem of course, is that GDB is using the Python doc string 121602 verbatim as its help text. While the user has formatted the help text 121603 so that it appears clear within the .py file, this means that the text 121604 appear less well formatted when displayed in the "help" output. 121605 121606 The same problem can be observed for gdb.Parameter objects in their 121607 set/show output. 121608 121609 In this commit I aim to improve the "help" output for commands and 121610 parameters. 121611 121612 To do this I have added gdbpy_fix_doc_string_indentation, a new 121613 function that rewrites the doc string text following the following 121614 rules: 121615 121616 1. Leading blank lines are removed, 121617 2. Trailing blank lines are removed, and 121618 3. Leading whitespace is removed in a "smart" way such that the 121619 relative indentation of lines is retained. 121620 121621 With this commit in place the above example now looks like this: 121622 121623 (gdb) source ~/tmp/test-cmd.py 121624 (gdb) help test-cmd 121625 This is the first line. 121626 Indented second line. 121627 This is the third line. 121628 (gdb) 121629 121630 Which I think is much neater. Notice that the indentation of the 121631 second line is retained. Any blank lines within the help text (not 121632 leading or trailing) will be retained. 121633 121634 I've added a NEWS entry to note that there has been a change in 121635 behaviour, but I didn't update the manual. The existing manual is 121636 suitably vague about how the doc string is used, so I think the new 121637 behaviour is covered just as well by the existing text. 121638 1216392022-05-28 Andrew Burgess <aburgess@redhat.com> 121640 121641 gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init 121642 Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation 121643 string in cmdpy_init (when creating a custom GDB command in Python). 121644 I think this is all pretty straight forward, the only slight weirdness 121645 is the removal of the call to free toward the end of this function. 121646 121647 Prior to this commit, if an exception was thrown after the GDB command 121648 was created then we would (I think) end up freeing the documentation 121649 string even though the command would remain registered with GDB, which 121650 would surely lead to undefined behaviour. 121651 121652 After this commit we release the doc string at the point that we hand 121653 it over to the command creation routines. If we throw _after_ the 121654 command has been created within GDB then the doc string will be left 121655 live. If we throw during the command creation itself (either from 121656 add_prefix_cmd or add_cmd) then it is up to those functions to free 121657 the doc string (I suspect we don't, but I think in general the 121658 commands are pretty bad at cleaning up after themselves, so I don't 121659 think this is a huge problem). 121660 1216612022-05-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121662 121663 gprofng: fix build with -mx32 121664 gprofng/ChangeLog 121665 2022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121666 121667 PR gprofng/28983 121668 PR gprofng/29143 121669 * src/Experiment.cc (write_header): Fix argument for ctime. 121670 Fix -Wformat= warnings. 121671 * src/Dbe.cc: Likewise. 121672 * src/DwarfLib.h: Fix [-Wsign-compare] warnings. 121673 * src/Experiment.h: Likewise. 121674 * src/ipc.cc: Fix -Wformat= warnings. 121675 1216762022-05-28 GDB Administrator <gdbadmin@sourceware.org> 121677 121678 Automatic date update in version.in 121679 1216802022-05-27 Tom Tromey <tom@tromey.com> 121681 121682 Fix crash with "maint print arc" 121683 Luis noticed that "maint print arc" would crash, because the command 121684 handler did not find "show" in the command name, violating an 121685 invariant. This patch fixes the bug by changing the registration to 121686 use add_basic_prefix_cmd instead. 121687 1216882022-05-27 Andrew Burgess <aburgess@redhat.com> 121689 121690 opcodes/i386: remove trailing whitespace from insns with zero operands 121691 While working on another patch[1] I had need to touch this code in 121692 i386-dis.c: 121693 121694 ins->obufp = ins->mnemonicendp; 121695 for (i = strlen (ins->obuf) + prefix_length; i < 6; i++) 121696 oappend (ins, " "); 121697 oappend (ins, " "); 121698 (*ins->info->fprintf_styled_func) 121699 (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf); 121700 121701 What this code does is add whitespace after the instruction mnemonic 121702 and before the instruction operands. 121703 121704 The problem I ran into when working on this code can be seen by 121705 assembling this input file: 121706 121707 .text 121708 nop 121709 retq 121710 121711 Now, when I disassemble, here's the output. I've replaced trailing 121712 whitespace with '_' so that the issue is clearer: 121713 121714 Disassembly of section .text: 121715 121716 0000000000000000 <.text>: 121717 0: 90 nop 121718 1: c3 retq___ 121719 121720 Notice that there's no trailing whitespace after 'nop', but there are 121721 three spaces after 'retq'! 121722 121723 What happens is that instruction mnemonics are emitted into a buffer 121724 instr_info::obuf, then instr_info::mnemonicendp is setup to point to 121725 the '\0' character at the end of the mnemonic. 121726 121727 When we emit the whitespace, this is then added starting at the 121728 mnemonicendp position. Lets consider 'retq', first the buffer is 121729 setup like this: 121730 121731 'r' 'e' 't' 'q' '\0' 121732 121733 Then we add whitespace characters at the '\0', converting the buffer 121734 to this: 121735 121736 'r' 'e' 't' 'q' ' ' ' ' ' ' '\0' 121737 121738 However, 'nop' is actually an alias for 'xchg %rax,%rax', so, 121739 initially, the buffer is setup like this: 121740 121741 'x' 'c' 'h' 'g' '\0' 121742 121743 Then in NOP_Fixup we spot that we have an instruction that is an alias 121744 for 'nop', and adjust the buffer to this: 121745 121746 'n' 'o' 'p' '\0' '\0' 121747 121748 The second '\0' is left over from the original buffer contents. 121749 However, when we rewrite the buffer, we don't afjust mnemonicendp, 121750 which still points at the second '\0' character. 121751 121752 Now, when we insert whitespace we get: 121753 121754 'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0' 121755 121756 Notice the whitespace is inserted after the first '\0', so, when we 121757 print the buffer, the whitespace is not printed. 121758 121759 The fix for this is pretty easy, I can change NOP_Fixup to adjust 121760 mnemonicendp, but now a bunch of tests start failing, we now produce 121761 whitespace after the 'nop', which the tests don't expect. 121762 121763 So, I could update the tests to expect the whitespace.... 121764 121765 ...except I'm not a fan of trailing whitespace, so I'd really rather 121766 not. 121767 121768 Turns out, I can pretty easily update the whitespace emitting code to 121769 spot instructions that have zero operands and just not emit any 121770 whitespace in this case. So this is what I've done. 121771 121772 I've left in the fix for NOP_Fixup, I think updating mnemonicendp is 121773 probably a good thing, though this is not really required any more. 121774 121775 I've then updated all the tests that I saw failing to adjust the 121776 expected patterns to account for the change in whitespace. 121777 121778 [1] https://sourceware.org/pipermail/binutils/2022-April/120610.html 121779 1217802022-05-27 Alan Modra <amodra@gmail.com> 121781 121782 Replace bfd_hostptr_t with uintptr_t 121783 bfd_hostptr_t is defined as a type large enough to hold either a long 121784 or a pointer. It mostly appears in the coff backend code in casts. 121785 include/coff/internal.h struct internal_syment and union 121786 internal_auxent have the only uses in data structures, where 121787 comparison with include/coff/external.h and other code reveals that 121788 the type only needs to be large enough for a 32-bit integer or a 121789 pointer. That should mean replacing with uintptr_t is OK. 121790 121791 Remove much of BFD_HOST configury 121792 This patch removes the definition of bfd_uint64_t and bfd_int64_t as 121793 well as most BFD_HOST_* which are now unused. 121794 121795 Remove use of bfd_uint64_t and similar 121796 Requiring C99 means that uses of bfd_uint64_t can be replaced with 121797 uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and 121798 BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_* 121799 and tidies a few places that print 64-bit values. 121800 1218012022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121802 121803 gprofng: fix build with --disable-shared 121804 gprofng/ChangeLog 121805 2022-05-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121806 121807 * libcollector/configure.ac: Use AC_MSG_WARN instead of AC_MSG_ERROR 121808 * libcollector/configure: Rebuild. 121809 1218102022-05-27 Jan Beulich <jbeulich@suse.com> 121811 121812 x86/Intel: allow MASM representation of embedded rounding / SAE 121813 MASM doesn't support the separate operand form; the modifier belongs 121814 after the instruction instead. Accept this form alongside the original 121815 (now legacy) one. Short of having access to a MASM version to actually 121816 check in how far "after the instruction" is a precise statement in their 121817 documentation, allow both that and the SDM mandated form where the 121818 modifier is on the last register operand (with a possible immediate 121819 operand following). 121820 121821 Sadly the split out function, at least for the time being, needs to cast 121822 away constness at some point, as the two callers disagree in this 121823 regard. 121824 121825 Adjust some, but not all of the testcases. 121826 1218272022-05-27 Jan Beulich <jbeulich@suse.com> 121828 121829 x86: re-work AVX512 embedded rounding / SAE 121830 As a preparatory step to allowing proper non-operand forms of specifying 121831 embedded rounding / SAE, convert the internal representation to non- 121832 operand form. While retaining properties (and in a few cases perhaps 121833 providing more meaningful diagnostics), this means doing away with a few 121834 hundred standalone templates, thus - as a nice side effect - reducing 121835 memory consumption / cache occupancy. 121836 121837 x86/Intel: adjust representation of embedded rounding / SAE 121838 MASM doesn't consider {sae} and alike a separate operand; it is attached 121839 to the last register operand instead, just like spelled out by the SDM. 121840 Make the disassembler follow this first, before also adjusting the 121841 assembler (such that it'll be easy to see that the assembler change 121842 doesn't alter generated code). 121843 1218442022-05-27 Jan Beulich <jbeulich@suse.com> 121845 121846 x86/Intel: allow MASM representation of embedded broadcast 121847 MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling 121848 DWORD PTR) and alike are to be used there instead. Accept these forms 121849 alongside the original (now legacy) ones. 121850 121851 Acceptance of the original {1to<n>} operand suffix is retained both for 121852 backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector 121853 conversions with shrinking element sizes. I have no insight (yet) into 121854 how MASM expects those to be disambiguated. 121855 121856 Adjust some, but not all of the testcases. 121857 1218582022-05-27 Jan Beulich <jbeulich@suse.com> 121859 121860 x86/Intel: adjust representation of embedded broadcast 121861 MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling 121862 DWORD PTR) and alike are to be used there instead. Make the disassembler 121863 follow this first, before also adjusting the assembler (such that it'll 121864 be easy to see that the assembler change doesn't alter generated code). 121865 121866 For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes 121867 the original {1to<n>} operand suffix is retained, to disambiguate 121868 output. I have no insight (yet) into how MASM expects those to be 121869 disambiguated. 121870 1218712022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121872 121873 gprofng: fix build with -mx32 121874 gprofng/ChangeLog 121875 2022-05-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 121876 121877 PR gprofng/28983 121878 * libcollector/libcol_util.h (__collector_getsp, __collector_getfp, 121879 __collector_getpc): Adapt for build with -mx32 121880 * libcollector/heaptrace.c: Fix -Wpointer-to-int-cast warnings. 121881 * libcollector/hwprofile.h: Likewise. 121882 * libcollector/mmaptrace.c: Likewise. 121883 * libcollector/synctrace.c: Likewise. 121884 * libcollector/unwind.c: Likewise. 121885 1218862022-05-27 GDB Administrator <gdbadmin@sourceware.org> 121887 121888 Automatic date update in version.in 121889 1218902022-05-27 Hans-Peter Nilsson <hp@axis.com> 121891 121892 ld: cris*-elf: Default to --no-warn-rwx-segment 121893 ld: 121894 configure.tgt (cris-*-*, crisv32-*-* sans *-aout and *-linux): Unless 121895 specified through the --enable-* -option, default to 121896 --no-warn-rwx-segment. 121897 121898 Change-Id: I846bcd3e6762da807b17215a9fe337461ea0d710 121899 1219002022-05-27 Hans-Peter Nilsson <hp@axis.com> 121901 121902 cris: bfd: Correct default to no execstack 121903 In the now-historical CRIS glibc port, the default stack permission 121904 was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the 121905 gcc port only emits the executable-stack marker when needed; when 121906 emitting code needing it. In other words, the binutils setting 121907 mismatches. It doesn't matter much, except being confusing and 121908 defaulting to "off" is more sane. 121909 121910 ld: 121911 121912 * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0 121913 for cris*-*-*. 121914 121915 bfd: 121916 * elf32-cris.c (elf_backend_default_execstack): Define to 0. 121917 121918 Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396 121919 1219202022-05-26 John Baldwin <jhb@FreeBSD.org> 121921 121922 aarch64-fbsd-nat: Move definition of debug_regs_probed under HAVE_DBREG. 121923 This fixes the build on older FreeBSD systems without support for 121924 hardware breakpoints/watchpoints. 121925 1219262022-05-26 Lancelot SIX <lancelot.six@amd.com> 121927 121928 gdb: Change psymbol_functions::require_partial_symbols to partial_symbols 121929 The previous patch ensured that partial symbols are read before calling 121930 most of the quick_function's methods. 121931 121932 The psymbol_functions class has the require_partial_symbols method which 121933 serves this exact purpose, and does not need to do it anymore. 121934 121935 This patch renames this method to partial_symbols and makes it an accessor 121936 which asserts that partial symbols have been read at this point. 121937 121938 Regression tested on x86_64-linux. 121939 1219402022-05-26 Lancelot SIX <lancelot.six@amd.com> 121941 121942 gdb: Require psymtab before calling quick_functions in objfile 121943 The recent DWARF indexer rewrite introduced a regression when debugging 121944 a forking program. 121945 121946 Here is a way to reproduce the issue (there might be other ways, but one 121947 is enough and this one mimics the situation we encountered). Consider a 121948 program which forks, and the child loads a shared library and calls a 121949 function in this shared library: 121950 121951 if (fork () == 0) 121952 { 121953 void *solib = dlopen (some_solib, RTLD_NOW); 121954 void (*foo) () = dlsym (some_solib, "foo"); 121955 foo (); 121956 } 121957 121958 Suppose that this program is compiled without debug info, but the shared 121959 library it loads has debug info enabled. 121960 121961 When debugging such program with the following options: 121962 121963 - set detach-on-fork off 121964 - set follow-fork-mode child 121965 121966 we see something like: 121967 121968 (gdb) b foo 121969 Function "foo" not defined. 121970 Make breakpoint pending on future shared library load? (y or [n]) y 121971 Breakpoint 1 (foo) pending. 121972 (gdb) run 121973 Starting program: a.out 121974 [Attaching after process 19720 fork to child process 19723] 121975 [New inferior 2 (process 19723)] 121976 [Switching to process 19723] 121977 121978 Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so 121979 (gdb) list 121980 121981 Fatal signal: Segmentation fault 121982 ----- Backtrace ----- 121983 0x55a278f77d76 gdb_internal_backtrace_1 121984 ../../gdb/bt-utils.c:122 121985 0x55a278f77f83 _Z22gdb_internal_backtracev 121986 ../../gdb/bt-utils.c:168 121987 0x55a27940b83b handle_fatal_signal 121988 ../../gdb/event-top.c:914 121989 0x55a27940bbb1 handle_sigsegv 121990 ../../gdb/event-top.c:987 121991 0x7effec0343bf ??? 121992 /build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 121993 0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv 121994 /usr/include/c++/9/bits/unique_ptr.h:154 121995 0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv 121996 /usr/include/c++/9/bits/unique_ptr.h:361 121997 0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile 121998 ../../gdb/dwarf2/read.c:3164 121999 0x55a279afb93e _ZN7objfile23find_last_source_symtabEv 122000 ../../gdb/symfile-debug.c:139 122001 0x55a279aa3040 _Z20select_source_symtabP6symtab 122002 ../../gdb/source.c:365 122003 0x55a279aa22a1 _Z34set_default_source_symtab_and_linev 122004 ../../gdb/source.c:268 122005 0x55a27903c44c list_command 122006 ../../gdb/cli/cli-cmds.c:1185 122007 0x55a279051233 do_simple_func 122008 ../../gdb/cli/cli-decode.c:95 122009 0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci 122010 ../../gdb/cli/cli-decode.c:2514 122011 0x55a279c3b0ba _Z15execute_commandPKci 122012 ../../gdb/top.c:660 122013 0x55a27940a6c3 _Z15command_handlerPKc 122014 ../../gdb/event-top.c:598 122015 0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE 122016 ../../gdb/event-top.c:797 122017 0x55a279caf401 tui_command_line_handler 122018 ../../gdb/tui/tui-interp.c:278 122019 0x55a279409098 gdb_rl_callback_handler 122020 ../../gdb/event-top.c:230 122021 0x55a279ed5df2 rl_callback_read_char 122022 ../../../readline/readline/callback.c:281 122023 0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept 122024 ../../gdb/event-top.c:188 122025 0x55a279408de7 gdb_rl_callback_read_char_wrapper 122026 ../../gdb/event-top.c:205 122027 0x55a27940a061 _Z19stdin_event_handleriPv 122028 ../../gdb/event-top.c:525 122029 0x55a27a23771e handle_file_event 122030 ../../gdbsupport/event-loop.cc:574 122031 0x55a27a237f5f gdb_wait_for_event 122032 ../../gdbsupport/event-loop.cc:700 122033 0x55a27a235d81 _Z16gdb_do_one_eventv 122034 ../../gdbsupport/event-loop.cc:237 122035 0x55a2796c2ef0 start_event_loop 122036 ../../gdb/main.c:418 122037 0x55a2796c3217 captured_command_loop 122038 ../../gdb/main.c:478 122039 0x55a2796c717b captured_main 122040 ../../gdb/main.c:1340 122041 0x55a2796c7217 _Z8gdb_mainP18captured_main_args 122042 ../../gdb/main.c:1355 122043 0x55a278d0b381 main 122044 ../../gdb/gdb.c:32 122045 --------------------- 122046 A fatal error internal to GDB has been detected, further 122047 debugging is not possible. GDB will now terminate. 122048 122049 This is a bug, please report it. For instructions, see: 122050 <https://www.gnu.org/software/gdb/bugs/>. 122051 122052 The first issue observed is in the message printed when hitting the 122053 breakpoint. It says that there was a break in the .so file as if there 122054 was no debug info associated with it, but there is. Later, if we try to 122055 display the source where the execution stopped, we have a segfault. 122056 122057 Note that not having the debug info on the main binary is not strictly 122058 required to encounter some issues, it only is to encounter the segfault. 122059 If the main binary has debug information, GDB shows some source form the 122060 main binary, unrelated to where we stopped. 122061 122062 The core of the issue is that GDB never loads the psymtab for the 122063 library. It is not loaded when we first see the .so because in case of 122064 detach-on-fork off, follow-fork-mode child, infrun.c sets 122065 child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading 122066 as much as possible. If we compare to what was done to handle this 122067 before the new indexer was activated, the psymatb construction for the 122068 shared library was done under 122069 psymbol_functions::expand_symtabs_matching: 122070 122071 bool 122072 psymbol_functions::expand_symtabs_matching (...) 122073 { 122074 for (partial_symtab *ps : require_partial_symbols (objfile)) 122075 ... 122076 } 122077 122078 The new indexer's expand_symtabs_matching callback does not have a call 122079 to the objfile's require_partial_symbols, so if the partial symbol table 122080 is not loaded at this point, there is no mechanism to fix this. 122081 122082 Instead of requiring each implementation of the quick_functions to check 122083 that partial symbols have been read, I think it is safer to enforce this 122084 when calling the quick functions. The general pattern for calling the 122085 quick functions is: 122086 122087 for (auto *iter : qf) 122088 iter->the_actual_method_call (...) 122089 122090 This patch proposes to wrap the access of the `qf` field with an accessor 122091 which ensures that partial symbols have been read before iterating: 122092 qf_require_partial_symbols. All calls to quick functions are updated 122093 except: 122094 122095 - quick_functions::dump 122096 - quick_functions::read_partial_symbols (from 122097 objfile::require_partial_symbols) 122098 - quick_functions::can_lazily_read_symbols and quick_functions::has_symbols 122099 (from objfile::has_partial_symbols) 122100 122101 Regression tested on x86_64-gnu-linux. 122102 122103 Change-Id: I39a13a937fdbaae613a5cf68864b021000554546 122104 1221052022-05-26 Tom Tromey <tom@tromey.com> 122106 122107 Fix crash in new DWARF indexer 122108 PR gdb/29128 points out a crash in the new DWARF index code. This 122109 happens if the aranges for a CU claims a PC, but the symtab that is 122110 created during CU expansion does not actually contain the PC. This 122111 can only occur due to bad debuginfo, but at the same time, gdb should 122112 not crash. 122113 122114 This patch fixes the bug and further merges some code into 122115 dwarf2_base_index_functions. This merger helps prevent the same issue 122116 from arising from the other index implementations. 122117 122118 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29128 122119 1221202022-05-26 Tom Tromey <tromey@adacore.com> 122121 122122 Finalize each cooked index separately 122123 After DWARF has been scanned, the cooked index code does a 122124 "finalization" step in a worker thread. This step combines all the 122125 index entries into a single master list, canonicalizes C++ names, and 122126 splits Ada names to synthesize package names. 122127 122128 While this step is run in the background, gdb will wait for the 122129 results in some situations, and it turns out that this step can be 122130 slow. This is PR symtab/29105. 122131 122132 This can be sped up by parallelizing, at a small memory cost. Now 122133 each index is finalized on its own, in a worker thread. The cost 122134 comes from name canonicalization: if a given non-canonical name is 122135 referred to by multiple indices, there will be N canonical copies (one 122136 per index) rather than just one. 122137 122138 This requires changing the users of the index to iterate over multiple 122139 results. However, this is easily done by introducing a new "chained 122140 range" class. 122141 122142 When run on gdb itself, the memory cost seems rather low -- on my 122143 current machine, "maint space 1" reports no change due to the patch. 122144 122145 For performance testing, using "maint time 1" and "file" will not show 122146 correct results. That approach measures "time to next prompt", but 122147 because the patch only affects background work, this shouldn't (and 122148 doesn't) change. Instead, a simple way to make gdb wait for the 122149 results is to set a breakpoint. 122150 122151 Before: 122152 122153 $ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \ 122154 -ex 'break main' /tmp/gdb 122155 Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28. 122156 2.00 122157 122158 After: 122159 122160 $ /bin/time -f%e ./gdb/gdb -nx -q -batch \ 122161 -ex 'break main' /tmp/gdb 122162 Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28. 122163 0.65 122164 122165 Regression tested on x86-64 Fedora 34. 122166 122167 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 122168 1221692022-05-26 Alan Modra <amodra@gmail.com> 122170 122171 bit-rot in target before_parse function 122172 Copy initialisation over from the elf.em before_parse. Commit 122173 ba951afb999 2022-05-03 changed behaviour on arm and score regarding 122174 exec stack. This patch restores the previous behaviour. 122175 122176 * emultempl/aarch64elf.em (before_parse): Init separate_code, 122177 warn_execstack, no_warn_rwx_segments and default_execstack. 122178 * emultempl/armelf.em (before_parse): Likewise. 122179 * emultempl/scoreelf.em (before_parse): Likewise. 122180 * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return 122181 true for arm and nacl. 122182 1221832022-05-26 Richard Earnshaw <rearnsha@arm.com> 122184 122185 arm: avoid use of GNU builtin function in s_arm_unwind_save_mixed 122186 Whilst reviewing Luis' proposed change to s_arm_unwind_save_mixed 122187 yesterday I noticed that we were making use of __builting_clzl 122188 directly within the main function, which is not guaranteed to be 122189 portable. Whilst studying the code further, I also realized that it 122190 could be rewritten without using it and also reworked to remove a lot 122191 of unnecessary iterations steps. So this patch does that (and also 122192 removes the source of the warning that Luis was trying to fix). 122193 Finally, with the rewrite we can also simplify the caller of this 122194 routine as the new version can handle all the cases directly. 122195 122196 * config/tc-arm.c (s_arm_unwind_save_mixed): Rewrite without 122197 using __builtin_clzl. 122198 (s_arm_unwind_save): Simplify logic for simple/mixed register saves. 122199 1222002022-05-26 Lancelot SIX <lancelot.six@amd.com> 122201 122202 gdb/linux-nat: xfer_memory_partial return E_IO on error 122203 When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters 122204 an error and return -1, linux_proc_xfer_memory_partial return 122205 TARGET_XFER_EOF. 122206 122207 I think it should return TARGET_XFER_E_IO in this case. TARGET_XFER_EOF 122208 is returned when pread64/pwrite64/read/frite returns 0, which indicates 122209 that the address space is gone and the whole process has exited or 122210 execed. 122211 122212 This patch makes this change. 122213 122214 Regression tested on x86_64-linux-gnu. 122215 122216 Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221 122217 1222182022-05-26 Lancelot SIX <lancelot.six@amd.com> 122219 122220 gdb/testsuite: prefer gdb_test in gdb.dwarf2/calling-convention 122221 Since ed01945057c "Make gdb_test's question non-optional if specified", 122222 if the question and response parameters are given to gdb_test, the 122223 framework enforces that GDB asks the question. Before this patch, tests 122224 needed to use gdb_test_multiple to enforce this. 122225 122226 This patch updates the gdb.dwarf2/calling-convention.exp testcase to use 122227 gdb_test to check that GDB asks a question. This replaces the more 122228 complicated gdb_test_multiple based implementation. 122229 122230 Tested on x86_64-gnu-linux. 122231 122232 Change-Id: I7216e822ca68f2727e0450970097d74c27c432fe 122233 1222342022-05-26 Potharla, Rupesh <Rupesh.Potharla@amd.com> 122235 122236 bfd: Add Support for DW_FORM_strx* and DW_FORM_addrx* 122237 1222382022-05-26 Luca Boccassi <bluca@debian.org> 122239 122240 ld: add --package-metadata 122241 Generate a .note.package FDO package metadata ELF note, following 122242 the spec: https://systemd.io/ELF_PACKAGE_METADATA/ 122243 122244 If the jansson library is available at build time (and it is explicitly 122245 enabled), link ld to it, and use it to validate that the input is 122246 correct JSON, to avoid writing garbage to the file. The 122247 configure option --enable-jansson has to be used to explicitly enable 122248 it (error out when not found). This allows bootstrappers (or others who 122249 are not interested) to seamlessly skip it without issues. 122250 1222512022-05-26 GDB Administrator <gdbadmin@sourceware.org> 122252 122253 Automatic date update in version.in 122254 1222552022-05-26 Natarajan, Kavitha <Kavitha.Natarajan@amd.com> 122256 122257 Re: Add bionutils support for DWARF v5's DW_OP_addrx 122258 Testsuite files belonging to commit 3ac9da49378c. 122259 1222602022-05-25 Pedro Alves <pedro@palves.net> 122261 122262 Show enabled locations with disabled breakpoint parent as "y-" 122263 Currently, breakpoint locations that are enabled while their parent 122264 breakpoint is disabled are displayed with "y" in the Enb colum of 122265 "info breakpoints": 122266 122267 (gdb) info breakpoints 122268 Num Type Disp Enb Address What 122269 1 breakpoint keep n <MULTIPLE> 122270 1.1 y 0x00000000000011b6 in ... 122271 1.2 y 0x00000000000011c2 in ... 122272 1.3 n 0x00000000000011ce in ... 122273 122274 Such locations won't trigger a break, so to avoid confusion, show "y-" 122275 instead. For example: 122276 122277 (gdb) info breakpoints 122278 Num Type Disp Enb Address What 122279 1 breakpoint keep n <MULTIPLE> 122280 1.1 y- 0x00000000000011b6 in ... 122281 1.2 y- 0x00000000000011c2 in ... 122282 1.3 n 0x00000000000011ce in ... 122283 122284 The "-" sign is inspired on how the TUI represents breakpoints on the 122285 left side of the source window, with "b-" for a disabled breakpoint. 122286 122287 Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09 122288 1222892022-05-25 Natarajan, Kavitha <Kavitha.Natarajan@amd.com> 122290 122291 Add bionutils support for DWARF v5's DW_OP_addrx. 122292 1222932022-05-25 Pedro Alves <pedro@palves.net> 122294 122295 gdb: Fix DUPLICATE and PATH regressions throughout 122296 The previous patch to add -prompt/-lbl to gdb_test introduced a 122297 regression: Before, you could specify an explicit empty message to 122298 indicate you didn't want to PASS, like so: 122299 122300 gdb_test COMMAND PATTERN "" 122301 122302 After said patch, gdb_test no longer distinguishes 122303 no-message-specified vs empty-message, so tests that previously would 122304 be silent on PASS, now started emitting PASS messages based on 122305 COMMAND. This in turn introduced a number of PATH/DUPLICATE 122306 violations in the testsuite. 122307 122308 This commit fixes all the regressions I could see. 122309 122310 This patch uses the new -nopass feature introduced in the previous 122311 commit, but tries to avoid it if possible. Most of the patch fixes 122312 DUPLICATE issues the usual way, of using with_test_prefix or explicit 122313 unique messages. 122314 122315 See previous commit's log for more info. 122316 122317 In addition to looking for DUPLICATEs, I also looked for cases where 122318 we would now end up with an empty message in gdb.sum, due to a 122319 gdb_test being passed both no message and empty command. E.g., this 122320 in gdb.ada/bp_reset.exp: 122321 122322 gdb_run_cmd 122323 gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*" 122324 122325 was resulting in this in gdb.sum: 122326 122327 PASS: gdb.ada/bp_reset.exp: 122328 122329 I fixed such cases by passing an explicit message. We may want to 122330 make such cases error out. 122331 122332 Tested on x86_64 GNU/Linux, native and native-extended-gdbserver. I 122333 see zero PATH cases now. I get zero DUPLICATEs with native testing 122334 now. I still see some DUPLICATEs with native-extended-gdbserver, but 122335 those were preexisting, unrelated to the gdb_test change. 122336 122337 Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2 122338 1223392022-05-25 Pedro Alves <pedro@palves.net> 122340 122341 Add -nopass option to gdb_test/gdb_test_multiple 122342 The previous patch to add -prompt/-lbl to gdb_test introduced a 122343 regression: Before, you could specify an explicit empty message to 122344 indicate you didn't want to PASS, like so: 122345 122346 gdb_test COMMAND PATTERN "" 122347 122348 After said patch, gdb_test no longer distinguishes 122349 no-message-specified vs empty-message, so tests that previously would 122350 be silent on PASS, now started emitting PASS messages based on 122351 COMMAND. This in turn introduced a number of PATH/DUPLICATE 122352 violations in the testsuite. 122353 122354 I think that not issuing a PASS should be restricted to only a few 122355 cases -- namely in shared routines exported by gdb.exp, which happen 122356 to use gdb_test internally. In tests that iterate an unknown number 122357 of tests exercising some racy scenario. In the latter case, if we 122358 emit PASSes for each iteration, we run into the situation where 122359 different testsuite runs emit a different number of PASSes. 122360 122361 Thus, this patch preserves the current behavior, and, instead, adds a 122362 new "-nopass" option to gdb_test and gdb_test_no_output. Compared to 122363 the old way of supressing PASS with an empty message, this has the 122364 advantage that you can specify a FAIL message that is distinct from 122365 the command string, and, it's also more explicit. 122366 122367 Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2 122368 1223692022-05-25 Tsukasa OI <research_trasio@irq.a4lg.com> 122370 122371 RISC-V: Fix RV32Q conflict 122372 This commit makes RV32 + 'Q' extension (version 2.2 or later) not 122373 conflicting since this combination is no longer prohibited by the 122374 specification. 122375 122376 bfd/ChangeLog: 122377 122378 * elfxx-riscv.c (riscv_parse_check_conflicts): Remove conflict 122379 detection that prohibits RV32Q on 'Q' version 2.2 or later. 122380 122381 gas/ChangeLog: 122382 122383 * testsuite/gas/riscv/march-fail-rv32iq.d: Removed. 122384 * testsuite/gas/riscv/march-fail-rv32iq.l: Likewise. 122385 * testsuite/gas/riscv/march-fail-rv32iq2p0.d: New test 122386 showing RV32IQ fails on 'Q' extension version 2.0. 122387 * testsuite/gas/riscv/march-fail-rv32iq2p0.l: Likewise. 122388 * testsuite/gas/riscv/march-fail-rv32iq2.d: Likewise. 122389 * testsuite/gas/riscv/march-fail-rv32iq-isa-2p2.d: New test 122390 showing RV32IQ fails on ISA specification version 2.2. 122391 * testsuite/gas/riscv/march-ok-rv32iq2p2.d: New test 122392 showing RV32IQ succesds on 'Q' extension version 2.2. 122393 * testsuite/gas/riscv/march-ok-rv32iq-isa-20190608.d: New test 122394 showing RV32IQ succesds on ISA specification 20190608. 122395 1223962022-05-25 Dmitry Selyutin <ghostmansd@gmail.com> 122397 122398 opcodes: introduce BC field; fix isel 122399 Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB 122400 field present in binutils sources. Also, per 1.6.2, BC has the same 122401 semantics as BA and BB fields, so this should keep the same flags and 122402 mask, only with the different offset. 122403 122404 opcodes/ 122405 * ppc-opc.c 122406 (BC): Define new field, with the same definition as CRB field, 122407 but with the PPC_OPERAND_CR_BIT flag present. 122408 gas/ 122409 * testsuite/gas/ppc/476.d: Update. 122410 * testsuite/gas/ppc/a2.d: Update. 122411 * testsuite/gas/ppc/e500.d: Update. 122412 * testsuite/gas/ppc/power7.d: Update. 122413 1224142022-05-25 Dmitry Selyutin <ghostmansd@gmail.com> 122415 122416 ppc: extend opindex to 16 bits 122417 With the upcoming SVP64 extension[0] to PowerPC architecture, it became 122418 evident that PowerPC operand indices no longer fit 8 bits. This patch 122419 switches the underlying type to uint16_t, also introducing a special 122420 typedef so that any future extension goes even smoother. 122421 122422 [0] https://libre-soc.org 122423 122424 include/ 122425 * opcode/ppc.h (ppc_opindex_t): New typedef. 122426 (struct powerpc_opcode): Use it. 122427 (PPC_OPINDEX_MAX): Define. 122428 gas/ 122429 * write.h (struct fix): Increase size of fx_pcrel_adjust. 122430 Reorganise. 122431 * config/tc-ppc.c (insn_validate): Use ppc_opindex_t for operands. 122432 (md_assemble): Likewise. 122433 (md_apply_fix): Likewise. Mask fx_pcrel_adjust with PPC_OPINDEX_MAX. 122434 (ppc_setup_opcodes): Adjust opcode index assertion. 122435 opcodes/ 122436 * ppc-dis.c (skip_optional_operands): Use ppc_opindex_t for 122437 operand pointer. 122438 (lookup_powerpc, lookup_prefix, lookup_vle, lookup_spe2): Likewise. 122439 (print_insn_powerpc): Likewise. 122440 1224412022-05-25 GDB Administrator <gdbadmin@sourceware.org> 122442 122443 Automatic date update in version.in 122444 1224452022-05-24 Tom de Vries <tdevries@suse.de> 122446 122447 [gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with clang 122448 When running test-case gdb.opt/clobbered-registers-O2.exp with clang 12.0.1, I 122449 get: 122450 ... 122451 (gdb) run ^M 122452 Starting program: clobbered-registers-O2 ^M 122453 ^M 122454 Program received signal SIGSEGV, Segmentation fault.^M 122455 gen_movsd (operand0=<optimized out>, operand1=<optimized out>) at \ 122456 clobbered-registers-O2.c:31^M 122457 31 return *start_sequence(operand0, operand1);^M 122458 (gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: runto: run to start_sequence 122459 ... 122460 122461 The problem is that the breakpoint in start_sequence doesn't trigger, because: 122462 - the call to start_sequence in gen_movsd is optimized away, despite the 122463 __attribute__((noinline)), so the actual function start_sequence doesn't get 122464 called, and 122465 - the debug info doesn't contain inlined function info, so there's only one 122466 breakpoint location. 122467 122468 Adding noclone and noipa alongside the noinline attribute doesn't fix this. 122469 122470 Adding the clang-specific attribute optnone in start_sequence does, but since 122471 it inhibits all optimization, that's not a preferred solution in a gdb.opt 122472 test-case, and it would work only for clang and not other compilers that 122473 possibly have the same issue. 122474 122475 Fix this by moving functions start_sequence and gen_movsd into their own 122476 files, as a way of trying harder to enforce noinline/noipa/noclone. 122477 122478 Tested on x86_64-linux. 122479 1224802022-05-24 Tom de Vries <tdevries@suse.de> 122481 122482 [gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with gcc-12 122483 When running test-case gdb.opt/clobbered-registers-O2.exp with gcc-12, I run 122484 into: 122485 ... 122486 (gdb) PASS: gdb.opt/clobbered-registers-O2.exp: backtracing 122487 print operand0^M 122488 $1 = (unsigned int *) 0x7fffffffd070^M 122489 (gdb) print *operand0^M 122490 $2 = 4195541^M 122491 (gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: print operand0 122492 ... 122493 122494 The problem is that starting gcc-12, the assignments to x and y in main are 122495 optimized away: 122496 ... 122497 int main(void) 122498 { 122499 unsigned x, y; 122500 122501 x = 13; 122502 y = 14; 122503 return (int)gen_movsd (&x, &y); 122504 ... 122505 122506 Fix this by making x and y volatile. 122507 122508 Note that the test-case intends to check the handling of debug info for 122509 optimized code in function gen_movsd, so inhibiting optimization in main 122510 doesn't interfere with that. 122511 122512 Tested on x86_64-linux. 122513 122514 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29161 122515 1225162022-05-24 Tiezhu Yang <yangtiezhu@loongson.cn> 122517 122518 gdb: LoongArch: Define LOONGARCH_LINUX_NUM_GREGSET as 45 122519 LOONGARCH_LINUX_NUM_GREGSET should be defined as 45 (32 + 1 + 1 + 11) 122520 due to reserved 11 for extension in glibc, otherwise when execute: 122521 122522 make check-gdb TESTS="gdb.base/corefile.exp" 122523 122524 there exists the following failed testcase: 122525 122526 (gdb) core-file /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile.core 122527 [New LWP 7742] 122528 warning: Unexpected size of section `.reg/7742' in core file. 122529 Core was generated by `/home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile'. 122530 Program terminated with signal SIGABRT, Aborted. 122531 warning: Unexpected size of section `.reg/7742' in core file. 122532 #0 0x000000fff76f4e24 in raise () from /lib/loongarch64-linux-gnu/libc.so.6 122533 (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free 122534 1225352022-05-24 Christophe Lyon <christophe.lyon@arm.com> 122536 122537 AArch64: add support for DFP (Decimal Floating point) 122538 This small patch adds support for TYPE_CODE_DECFLOAT in 122539 aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate, 122540 so that GDB for AArch64 knows how to pass DFP parameters and how to 122541 read DFP results when calling a function. 122542 122543 Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH, 122544 all of GDB's DFP tests pass. 122545 1225462022-05-24 Christophe Lyon <christophe.lyon@arm.com> 122547 122548 Merge config/ changes from GCC, to enable DFP on AArch64 122549 2022-04-28 Christophe Lyon <christophe.lyon@arm.com> 122550 122551 config/ 122552 * dfp.m4 (enable_decimal_float): Enable BID for AArch64. 122553 122554 libdecnumber/ 122555 * configure: Regenerate. 122556 1225572022-05-24 Alan Modra <amodra@gmail.com> 122558 122559 PR29171, invalid read causing SIGSEGV 122560 The fix here is to pass "section" down to read_and_display_attr_value. 122561 The test in read_and_display_attr_value is a little bit of hardening. 122562 122563 PR 29171 122564 * dwarf.c (display_debug_macro, display_debug_names): Pass section 122565 to read_and_display_attr_value2. 122566 (read_and_display_attr_value): Don't attempt to check for .dwo 122567 section name when section is NULL. 122568 1225692022-05-24 Alan Modra <amodra@gmail.com> 122570 122571 PR29170, divide by zero displaying fuzzed .debug_names 122572 PR 29170 122573 * dwarf.c (display_debug_names): Don't attempt to display bucket 122574 clashes when bucket count is zero. 122575 122576 PR29169, invalid read displaying fuzzed .gdb_index 122577 PR 29169 122578 * dwarf.c (display_gdb_index): Combine sanity checks. Calculate 122579 element counts, not word counts. 122580 1225812022-05-24 GDB Administrator <gdbadmin@sourceware.org> 122582 122583 Automatic date update in version.in 122584 1225852022-05-23 John Baldwin <jhb@FreeBSD.org> 122586 122587 Tweak the std::hash<> specialization for aarch64_features. 122588 Move the specialization into an explicit std namespace to workaround a 122589 bug in older compilers. GCC 6.4.1 at least fails to compile the previous 122590 version with the following error: 122591 122592 gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive] 122593 122594 struct std::hash<aarch64_features> 122595 1225962022-05-23 John Baldwin <jhb@FreeBSD.org> 122597 122598 Fix loongarch_iterate_over_regset_sections for non-native targets. 122599 Define a constant for the number of registers stored in a register set 122600 and use this with register_size to compute the size of the 122601 general-purpose register set in core dumps. 122602 122603 This also fixes the build on hosts such as FreeBSD that do not define 122604 an elf_gregset_t type. 122605 1226062022-05-23 Tiezhu Yang <yangtiezhu@loongson.cn> 122607 122608 gdb: LoongArch: Implement the iterate_over_regset_sections gdbarch method 122609 When execute the following command on LoongArch: 122610 122611 make check-gdb TESTS="gdb.base/auxv.exp" 122612 122613 there exist the following unsupported and failed testcases: 122614 122615 UNSUPPORTED: gdb.base/auxv.exp: gcore 122616 FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump 122617 FAIL: gdb.base/auxv.exp: info auxv on native core dump 122618 FAIL: gdb.base/auxv.exp: matching auxv data from live and core 122619 UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump 122620 UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore 122621 122622 we can see the following messages in gdb/testsuite/gdb.log: 122623 122624 gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore 122625 Target does not support core file generation. 122626 (gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore 122627 122628 In order to fix the above issues, implement the iterate_over_regset_sections 122629 gdbarch method to iterate over core file register note sections on LoongArch. 122630 122631 By the way, with this patch, the failed testcases in gdb.base/corefile.exp 122632 and gdb.base/gcore.exp can also be fixed. 122633 1226342022-05-23 Tom de Vries <tdevries@suse.de> 122635 122636 [gdb/testsuite] Fix -prompt handling in gdb_test 122637 With check-read1 I run into: 122638 ... 122639 [infrun] maybe_set_commit_resumed_all_targets: not requesting 122640 commit-resumed for target native, no resumed threads^M 122641 (gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue 122642 [infrun] fetch_inferior_event: exit^M 122643 ... 122644 122645 The problem is that proc gdb_test doesn't pass down the -prompt option to proc 122646 gdb_test_multiple, due to a typo making this lappend without effect: 122647 ... 122648 set opts {} 122649 lappend "-prompt $prompt" 122650 ... 122651 122652 Fix this by actually appending to opts. 122653 122654 Tested on x86_64-linux. 122655 1226562022-05-23 Tom de Vries <tdevries@suse.de> 122657 122658 [gdbsupport] Fix UB in print-utils.cc:int_string 122659 When building gdb with -fsanitize=undefined, I run into: 122660 ... 122661 (gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on 122662 maint print symbols^M 122663 print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \ 122664 be represented in type 'long int'; cast to an unsigned type to negate this \ 122665 value to itself 122666 (gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols 122667 ... 122668 122669 By running in a debug session, we find that this happens during printing of: 122670 ... 122671 typedef system.storage_elements.storage_offset: \ 122672 range -9223372036854775808 .. 9223372036854775807; 122673 ... 122674 Possibly, an ada test-case could be created that exercises this in isolation. 122675 122676 The problem is here in int_string, where we negate a val with type LONGEST: 122677 ... 122678 return decimal2str ("-", -val, width); 122679 ... 122680 122681 Fix this by, as recommend, using "-(ULONGEST)val" instead. 122682 122683 Tested on x86_64-linux. 122684 1226852022-05-23 Tom de Vries <tdevries@suse.de> 122686 122687 [gdb/exp] Fix UB in scalar_binop 122688 When building gdb with -fsanitize=undefined, I run into: 122689 ... 122690 $ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)" 122691 src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \ 122692 0 - -9223372036854775808 cannot be represented in type 'long int' 122693 $1 = -9223372036854775808 122694 ... 122695 122696 Fix this by performing the substraction in scalar_binop using unsigned types. 122697 122698 Tested on x86_64-linux. 122699 1227002022-05-23 Tom de Vries <tdevries@suse.de> 122701 122702 [gdb/ada] Fix gdb.ada/dynamic-iface.exp with gcc 7 122703 This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8: 122704 ... 122705 (gdb) print obj^M 122706 $1 = (n => 3, a => "ABC", value => 93)^M 122707 (gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface 122708 ... 122709 but fails with gcc 7: 122710 ... 122711 (gdb) print obj^M 122712 $1 = ()^M 122713 (gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface 122714 ... 122715 122716 More concretely, we have trouble finding the type of obj. With gcc 8: 122717 ... 122718 $ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj" 122719 ... 122720 type = <ref> new concrete.intermediate with record 122721 value: integer; 122722 end record 122723 ... 122724 and with gcc 7: 122725 ... 122726 type = <ref> tagged record null; end record 122727 ... 122728 122729 The translation from tagged type to "full view" type happens in 122730 ada_tag_value_at_base_address, where we hit this code: 122731 ... 122732 /* Storage_Offset'Last is used to indicate that a dynamic offset to 122733 top is used. In this situation the offset is stored just after 122734 the tag, in the object itself. */ 122735 if (offset_to_top == last) 122736 { 122737 struct value *tem = value_addr (tag); 122738 tem = value_ptradd (tem, 1); 122739 tem = value_cast (ptr_type, tem); 122740 offset_to_top = value_as_long (value_ind (tem)); 122741 } 122742 ... 122743 resulting in an offset_to_top for gcc 8: 122744 ... 122745 (gdb) p offset_to_top 122746 $1 = -16 122747 ... 122748 and for gcc 7: 122749 ... 122750 (gdb) p offset_to_top 122751 $1 = 16 122752 ... 122753 122754 The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple 122755 changes]") which mentions this change. 122756 122757 There's some code right after the code quoted above that deals with this 122758 change: 122759 ... 122760 else if (offset_to_top > 0) 122761 { 122762 /* OFFSET_TO_TOP used to be a positive value to be subtracted 122763 from the base address. This was however incompatible with 122764 C++ dispatch table: C++ uses a *negative* value to *add* 122765 to the base address. Ada's convention has therefore been 122766 changed in GNAT 19.0w 20171023: since then, C++ and Ada 122767 use the same convention. Here, we support both cases by 122768 checking the sign of OFFSET_TO_TOP. */ 122769 offset_to_top = -offset_to_top; 122770 } 122771 ... 122772 but it's not activated because of the 'else'. 122773 122774 Fix this by removing the 'else'. 122775 122776 Tested on x86_64-linux, with gcc 7.5.0. 122777 122778 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057 122779 1227802022-05-23 Mark Harmstone <mark@harmstone.com> 122781 122782 ld: use definitions in generate_reloc rather than raw literals 122783 1227842022-05-23 Tom de Vries <tdevries@suse.de> 122785 122786 [gdb/testsuite] Skip language auto in gdb.base/parse_number.exp 122787 In test-case gdb.base/parse_number.exp, we skip architecture auto in the 122788 $supported_archs loop, to prevent duplicate testing. 122789 122790 Likewise, skip language auto and its alias local in the $::all_languages 122791 loop. This reduces the number of tests from 17744 to 15572. 122792 122793 Tested on x86_64-linux, with a build with --enable-targets=all. 122794 1227952022-05-23 GDB Administrator <gdbadmin@sourceware.org> 122796 122797 Automatic date update in version.in 122798 1227992022-05-22 Alok Kumar Sharma <AlokKumar.Sharma@amd.com> 122800 122801 Accept functions with DW_AT_linkage_name present 122802 Currently GDB is not able to debug (Binary generated with Clang) variables 122803 present in shared/private clause of OpenMP Task construct. Please note that 122804 LLVM debugger LLDB is able to debug. 122805 122806 In case of OpenMP, compilers generate artificial functions which are not 122807 present in actual program. This is done to apply parallelism to block of 122808 code. 122809 122810 For non-artifical functions, DW_AT_name attribute should contains the name 122811 exactly as present in actual program. 122812 (Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices) 122813 Since artificial functions are not present in actual program they not having 122814 DW_AT_name and having DW_AT_linkage_name instead should be fine. 122815 122816 Currently GDB is invalidating any function not havnig DW_AT_name which is why 122817 it is not able to debug OpenMP (Clang). 122818 122819 It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name 122820 is absent. 122821 1228222022-05-22 GDB Administrator <gdbadmin@sourceware.org> 122823 122824 Automatic date update in version.in 122825 1228262022-05-21 GDB Administrator <gdbadmin@sourceware.org> 122827 122828 Automatic date update in version.in 122829 1228302022-05-20 Pedro Alves <pedro@palves.net> 122831 122832 Rename base_breakpoint -> code_breakpoint 122833 Even after the previous patches reworking the inheritance of several 122834 breakpoint types, the present breakpoint hierarchy looks a bit 122835 surprising, as we have "breakpoint" as the superclass, and then 122836 "base_breakpoint" inherits from "breakpoint". Like so, simplified: 122837 122838 breakpoint 122839 base_breakpoint 122840 ordinary_breakpoint 122841 internal_breakpoint 122842 momentary_breakpoint 122843 ada_catchpoint 122844 exception_catchpoint 122845 tracepoint 122846 watchpoint 122847 catchpoint 122848 exec_catchpoint 122849 ... 122850 122851 The surprising part to me is having "base_breakpoint" being a subclass 122852 of "breakpoint". I'm just refering to naming here -- I mean, you'd 122853 expect that it would be the top level baseclass that would be called 122854 "base". 122855 122856 Just flipping the names of breakpoint and base_breakpoint around 122857 wouldn't be super great for us, IMO, given we think of every type of 122858 *point as a breakpoint at the user visible level. E.g., "info 122859 breakpoints" shows watchpoints, tracepoints, etc. So it makes to call 122860 the top level class breakpoint. 122861 122862 Instead, I propose renaming base_breakpoint to code_breakpoint. The 122863 previous patches made sure that all code breakpoints inherit from 122864 base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts 122865 nicely with a watchpoint also being typically known as a "data 122866 breakpoint". 122867 122868 After this commit, the resulting hierarchy looks like: 122869 122870 breakpoint 122871 code_breakpoint 122872 ordinary_breakpoint 122873 internal_breakpoint 122874 momentary_breakpoint 122875 ada_catchpoint 122876 exception_catchpoint 122877 tracepoint 122878 watchpoint 122879 catchpoint 122880 exec_catchpoint 122881 ... 122882 122883 ... which makes a lot more sense to me. 122884 122885 I've left this patch as last in the series in case people want to 122886 bikeshed on the naming. 122887 122888 "code" has a nice property that it's exactly as many letters as 122889 "base", so this patch didn't require any reindentation. :-) 122890 122891 Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66 122892 1228932022-05-20 Pedro Alves <pedro@palves.net> 122894 122895 Test "set multiple-symbols on" creating multiple breakpoints 122896 To look for code paths that lead to create_breakpoints_sal creating 122897 multiple breakpoints, I ran the whole testsuite with this hack: 122898 122899 --- a/gdb/breakpoint.c 122900 +++ b/gdb/breakpoint.c 122901 @@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch, 122902 int from_tty, 122903 int enabled, int internal, unsigned flags) 122904 { 122905 - if (canonical->pre_expanded) 122906 - gdb_assert (canonical->lsals.size () == 1); 122907 + gdb_assert (canonical->lsals.size () == 1); 122908 122909 surprisingly, the assert never failed... 122910 122911 The way to get to create_breakpoints_sal with multiple lsals is to use 122912 "set multiple-symbols ask" and then select multiple options from the 122913 menu, like so: 122914 122915 (gdb) set multiple-symbols ask 122916 (gdb) b overload1arg 122917 [0] cancel 122918 [1] all 122919 [2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg() 122920 [3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char) 122921 [4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double) 122922 [5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float) 122923 [6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int) 122924 [7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long) 122925 [8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short) 122926 [9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char) 122927 [10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char) 122928 [11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int) 122929 [12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long) 122930 [13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short) 122931 > 2-3 122932 Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107. 122933 Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110. 122934 warning: Multiple breakpoints were set. 122935 Use the "delete" command to delete unwanted breakpoints. 122936 122937 ... which would trigger the assert. 122938 122939 This commit makes gdb.cp/ovldbreak.exp test this scenario. It does 122940 that by making set_bp_overloaded take a list of expected created 122941 breakpoints rather than just one breakpoint. It converts the 122942 procedure to use gdb_test_multiple instead of send_gdb/gdb_expect 122943 along the way. 122944 122945 Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e 122946 1229472022-05-20 Pedro Alves <pedro@palves.net> 122948 122949 Make sure momentary breakpoints are always thread-specific 122950 This adds a new ctor to momentary_breakpoints with a few parameters 122951 that are always necessary for momentary breakpoints. 122952 122953 In particular, I noticed that set_std_terminate_breakpoint doesn't 122954 make the breakpoint be thread specific, which looks like a bug to me. 122955 122956 The point of that breakpoint is to intercept std::terminate calls that 122957 happen as result of the called thread throwing an exception that won't 122958 be caught by the dummy frame. If some other thread calls 122959 std::terminate, IMO, it's no different from some other thread calling 122960 exit/_exit, for example. 122961 122962 Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02 122963 1229642022-05-20 Pedro Alves <pedro@palves.net> 122965 122966 Momentary breakpoints should have no breakpoint number 122967 Momentary breakpoints have no breakpoint number, their breakpoint 122968 number should be always 0, to avoid constantly incrementing (or 122969 decrementing) the internal breakpoint count. 122970 122971 Indeed, set_momentary_breakpoint installs the created breakpoint 122972 without a number. 122973 122974 However, momentary_breakpoint_from_master incorrectly gives an 122975 internal breakpoint number to the new breakpoint. This commit fixes 122976 that. 122977 122978 Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95 122979 1229802022-05-20 Pedro Alves <pedro@palves.net> 122981 122982 Add/tweak intro comments of struct breakpoint and several subclasses 122983 This tweaks the intro comments of the following classes: 122984 122985 internal_breakpoint 122986 momentary_breakpoint 122987 breakpoint 122988 base_breakpoint 122989 watchpoint 122990 catchpoint 122991 122992 Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8 122993 1229942022-05-20 Pedro Alves <pedro@palves.net> 122995 122996 Move add_location(sal) to base_breakpoint 122997 After the previous patches, only base_breakpoint subclasses use 122998 add_location(sal), so we can move it to base_breakpoint (a.k.a. base 122999 class for code breakpoints). 123000 123001 This requires a few casts here and there, but always at spots where 123002 you can see from context what the breakpoint's type actually is. 123003 123004 I inlined new_single_step_breakpoint into its only caller exactly for 123005 this reason. 123006 123007 I did try to propagate more use of base_breakpoint to avoid casts, but 123008 that turned out unwieldy for this patch. 123009 123010 Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8 123011 1230122022-05-20 Pedro Alves <pedro@palves.net> 123013 123014 Move common bits of catchpoint/exception_catchpoint to breakpoint's ctor 123015 Move common bits of catchpoint and exception_catchpoint to 123016 breakpoint's ctor, to avoid duplicating code. 123017 123018 Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2 123019 1230202022-05-20 Pedro Alves <pedro@palves.net> 123021 123022 Make catchpoint inherit breakpoint, eliminate init_raw_breakpoint 123023 struct catchpoint's ctor currently calls init_raw_breakpoint, which is 123024 a bit weird, as that ctor-like function takes a sal argument, but 123025 catchpoints don't have code locations. 123026 123027 Instead, make struct catchpoint's ctor add the catchpoint's dummy 123028 location using add_dummy_location. 123029 123030 init_raw_breakpoint uses add_location under the hood, and with a dummy 123031 sal it would ultimately use the breakpoint's gdbarch for the 123032 location's gdbarch, so replace the references to loc->gdbarch (which 123033 is now NULL) in syscall_catchpoint to references to the catchpoint's 123034 gdbarch. 123035 123036 struct catchpoint's ctor was the last user of init_raw_breakpoint, so 123037 this commit eliminates the latter. 123038 123039 Since catchpoint locations aren't code locations, make struct 123040 catchpoint inherit struct breakpoint instead of base_breakpoint. This 123041 let's us delete the tracepoint::re_set override too. 123042 123043 Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869 123044 1230452022-05-20 Pedro Alves <pedro@palves.net> 123046 123047 Make breakpoint_address_bits look at the location kind 123048 Software watchpoints allocate a special dummy location using 123049 software_watchpoint_add_no_memory_location, and then 123050 breakpoint_address_bits checks whether the location is that special 123051 location to decide whether the location has a meaninful address to 123052 print. 123053 123054 Introduce a new bp_loc_software_watchpoint location kind, and make 123055 breakpoint_address_bits use bl_address_is_meaningful instead, which 123056 returns false for bp_loc_other, which is in accordance with we 123057 document for bp_location::address: 123058 123059 /* (... snip ...) Valid for all types except 123060 bp_loc_other. */ 123061 CORE_ADDR address = 0; 123062 123063 Rename software_watchpoint_add_no_memory_location to 123064 add_dummy_location, and simplify it. This will be used by catchpoints 123065 too in a following patch. 123066 123067 Note that neither "info breakpoints" nor "maint info breakpoints" 123068 actually prints the addresses of watchpoints, but I think it would be 123069 useful to do so in "maint info breakpoints". This approach let's us 123070 implement that in the future. 123071 123072 Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7 123073 1230742022-05-20 Pedro Alves <pedro@palves.net> 123075 123076 Make exception_catchpoint inherit base_breakpoint instead of catchpoint 123077 exception_catchpoint is really a code breakpoint, with locations set 123078 by sals, re-set like other code breakpoints, etc., so make it inherit 123079 base_breakpoint. 123080 123081 This adds a bit of duplicated code to exception_catchpoint's ctor 123082 (copied from struct catchpoint's ctor), but it will be eliminated in a 123083 following patch. 123084 123085 Change-Id: I9fbb2927491120e9744a4f5e5cb5e6870ca07009 123086 1230872022-05-20 Pedro Alves <pedro@palves.net> 123088 123089 Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location} 123090 This commit makes set_momentary_breakpoint allocate the breakpoint 123091 type without relying on set_raw_breakpoint, and similarly, 123092 momentary_breakpoint_from_master not rely on 123093 set_raw_breakpoint_without_location. This will let us convert 123094 init_raw_breakpoint to a ctor in a following patch. 123095 123096 The comment about set_raw_breakpoint being used in gdbtk sources is 123097 stale. gdbtk no longer uses it. 123098 123099 Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a 123100 1231012022-05-20 Pedro Alves <pedro@palves.net> 123102 123103 Refactor set_internal_breakpoint / internal_breakpoint ctor 123104 This moves initialization of internal_breakpoint's breakpoint fields 123105 to internal_breakpoint's ctor, and stops using 123106 new_breakpoint_from_type for internal_breakpoint breakpoints. 123107 123108 Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d 123109 1231102022-05-20 Pedro Alves <pedro@palves.net> 123111 123112 Convert init_ada_exception_catchpoint to a ctor 123113 Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I 123114 presume so it can call the static describe_other_breakpoints function. 123115 I think this is a dependency inversion. 123116 init_ada_exception_catchpoint, being code specific to Ada catchpoints, 123117 should be in ada-lang.c, and describe_other_breakpoints, a core 123118 function, should be exported. 123119 123120 And then, we can convert init_ada_exception_catchpoint to an 123121 ada_catchpoint ctor. 123122 123123 Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1 123124 1231252022-05-20 Pedro Alves <pedro@palves.net> 123126 123127 Make ada_catchpoint_location's owner ctor parameter be ada_catchpoint 123128 This commit changes ada_catchpoint_location's ctor from: 123129 123130 ada_catchpoint_location (breakpoint *owner) 123131 123132 to: 123133 123134 ada_catchpoint_location (ada_catchpoint *owner) 123135 123136 just to make the code better document intention. 123137 123138 To do this, we need to move the ada_catchpoint_location type's 123139 definition to after ada_catchpoint is defined, otherwise the compiler 123140 doesn't know that ada_catchpoint is convertible to struct breakpoint. 123141 123142 Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d 123143 1231442022-05-20 Pedro Alves <pedro@palves.net> 123145 123146 init_breakpoint_sal -> base_breakpoint::base_breakpoint 123147 This converts init_breakpoint_sal to a base_breakpoint constructor. 123148 123149 It removes a use of init_raw_breakpoint. 123150 123151 To avoid manually adding a bunch of parameters to 123152 new_breakpoint_from_type, and manually passing them down to the 123153 constructors of a number of different base_breakpoint subclasses, make 123154 new_breakpoint_from_type a variable template function. 123155 123156 Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510 123157 1231582022-05-20 Pedro Alves <pedro@palves.net> 123159 123160 Remove "internal" parameter from a couple functions 123161 None of init_breakpoint_sal, create_breakpoint_sal, and 123162 strace_marker_create_breakpoints_sal make use of their "internal" 123163 parameter, so remove it. 123164 123165 Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435 123166 1231672022-05-20 Pedro Alves <pedro@palves.net> 123168 123169 More breakpoint_ops parameter elimination 123170 Remove breakpoint_ops parameters from a few functions that don't need 123171 it. 123172 123173 Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28 123174 1231752022-05-20 Pedro Alves <pedro@palves.net> 123176 123177 Make a few functions work with base_breakpoint instead of breakpoint 123178 This makes tracepoints inherit from base_breakpoint, since their 123179 locations are code locations. If we do that, then we can eliminate 123180 tracepoint::re_set and tracepoint::decode_location, as they are doing 123181 the same as the base_breakpoint implementations. 123182 123183 With this, all breakpoint types created by new_breakpoint_from_type 123184 are code breakpoints, i.e., base_breakpoint subclasses, and thus we 123185 can make it return a base_breakpoint pointer. 123186 123187 Finally, init_breakpoint_sal can take a base_breakpoint pointer as 123188 "self" pointer too. This will let us convert this function to a 123189 base_breakpoint ctor in a following patch. 123190 123191 Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54 123192 1231932022-05-20 Pedro Alves <pedro@palves.net> 123194 123195 ranged_breakpoint: move initialization to ctor 123196 Move initialization of ranged_breakpoint's fields to its ctor. 123197 123198 Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3 123199 1232002022-05-20 Pedro Alves <pedro@palves.net> 123201 123202 ranged_breakpoint: use install_breakpoint 123203 This commit replaces a chunk of code in break_range_command by an 123204 equivalent call to install_breakpoint. 123205 123206 Change-Id: I31c06cabd36f5be91740aab029265f678aa78e35 123207 1232082022-05-20 Pedro Alves <pedro@palves.net> 123209 123210 ranged_breakpoint: don't use init_raw_breakpoint 123211 ranged_breakpoint's ctor already sets the breakpoint's type to 123212 bp_hardware_breakpoint. 123213 123214 Since this is a "regular" breakpoint, b->pspace should remain NULL. 123215 123216 Thus, the only thing init_raw_breakpoint is needed for, is to add the 123217 breakpoint's location. Do that directly. 123218 123219 Change-Id: I1505de94c3919881c2b300437e2c0da9b05f76bd 123220 1232212022-05-20 Pedro Alves <pedro@palves.net> 123222 123223 Make structs breakpoint/base_breakpoint/catchpoint be abstract 123224 You should never instanciate these types directly. 123225 123226 Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f 123227 1232282022-05-20 Pedro Alves <pedro@palves.net> 123229 123230 add_location_to_breakpoint -> breakpoint::add_location 123231 Make add_location_to_breakpoint be a method of struct breakpoint. 123232 123233 A patch later in the series will move this to base_breakpoint, but for 123234 now, it needs to be here. 123235 123236 Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129 123237 1232382022-05-20 Carl Love <cel@us.ibm.com> 123239 123240 PowerPC: Make test gdb.arch/powerpc-power10.exp Endian independent. 123241 The .quad statement stores the 64-bit hex value in Endian order. When used 123242 to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad 123243 statement stores the 32-bit suffix followed by the 32-bit prefix rather 123244 than the expected order of prefix word followed by the suffix word. GDB 123245 fetches 32-bits at a time when disassembling instructions. The disassembly 123246 on BE gets messed up since GDB fetches the suffix first and interprets it 123247 as a word instruction not a prefixed instruction. When gdb fetches the 123248 prefix part of the instruction, following the initial suffix word, gdb 123249 associates the prefix word incorrectly with the following 32-bits as the 123250 suffix for the instruction when in fact it is the following instruction. 123251 123252 For example on BE we have two prefixed instructions stored using the 123253 .quad statement as follows: 123254 123255 addr word GDB action 123256 --------------------------------------------- 123257 1 suffix inst A <- GDB interprets as a word instruction 123258 2 prefix inst A <- GDB uses this prefix with 123259 123260 3 suffix inst B <- this suffix rather than the suffix at addr 1. 123261 4 prefix inst B 123262 123263 This patch changes the .quad statement into two .longs to explicitly store 123264 the prefix followed by the suffix of the instruction. 123265 123266 The patch rearranges the instructions to put all of the word instructions 123267 together followed by the prefix instructions for clarity. 123268 123269 The patch has been tested on Power 10 and Power 7 BE and LE to verify 123270 the change works as expected. 123271 1232722022-05-20 Tom Tromey <tromey@adacore.com> 123273 123274 Remove obsolete text from documentation 123275 The documentation says that -enable-pretty-printing is experimental in 123276 7.0 and may change -- that's long enough ago that I think we can say 123277 that this text is no longer correct or useful. 123278 1232792022-05-20 Nick Clifton <nickc@redhat.com> 123280 123281 Stop readekf and objdump from aggressively following links. 123282 * dwarf.c (dwarf_select_sections_by_names): Return zero if no 123283 sections were selected. 123284 (dwarf_select_sections_by_letters): Likewise. 123285 * dwarf.h: (dwarf_select_sections_by_names): Update prototype. 123286 (dwarf_select_sections_by_letters): Update prototype. 123287 * objdump.c (might_need_separate_debug_info): New function. 123288 (dump_bfd): Call new function before attempting to load separate 123289 debug info files. 123290 (main): Do not enable dwarf section dumping for -WK or -WN. 123291 * readelf.c (parse_args): Do not enable dwarf section dumping for 123292 -wK or -wN. 123293 (might_need_separate_debug_info): New function. 123294 (process_object): Call new function before attempting to load 123295 separate debug info files. 123296 * testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE 123297 debuginfod tests to pass. 123298 * testsuite/binutils-all/objdump.Wk: Add extra regexps. 123299 * testsuite/binutils-all/readelf.k: Add extra regexps. 123300 1233012022-05-20 Jia-Wei Chen <jiawei@iscas.ac.cn> 123302 123303 RISC-V: Update zfinx implement with zicsr. 123304 Update zfinx implement with zicsr, fix missing fcsr use by zfinx. 123305 add zicsr imply by zfinx. 123306 123307 bfd/ChangeLog: 123308 123309 * elfxx-riscv.c: New imply. 123310 123311 gas/ChangeLog: 123312 123313 * testsuite/gas/riscv/csr-insns-pseudo-zfinx.d: New test. 123314 123315 opcodes/ChangeLog: 123316 123317 * riscv-opc.c: Update insn class. 123318 1233192022-05-20 Tsukasa OI <research_trasio@irq.a4lg.com> 123320 123321 RISC-V: Remove RV128-only fmv instructions 123322 As fmv.x.q and fmv.q.x instructions are RV128-only (not RV64-only), 123323 it should be removed until RV128 support for GNU Binutils is required 123324 again. 123325 123326 gas/ChangeLog: 123327 123328 * testsuite/gas/riscv/fmv.x.q-rv64-fail.d: New failure test. 123329 * testsuite/gas/riscv/fmv.x.q-rv64-fail.l: Likewise. 123330 * testsuite/gas/riscv/fmv.x.q-rv64-fail.s: Likewise. 123331 123332 include/ChangeLog: 123333 123334 * opcode/riscv-opc.h (MATCH_FMV_X_Q, MASK_FMV_X_Q, 123335 MATCH_FMV_Q_X, MASK_FMV_Q_X): Remove RV128-only instructions. 123336 123337 opcodes/ChangeLog: 123338 123339 * riscv-opc.c (riscv_opcodes): Remove RV128-only instructions. 123340 1233412022-05-20 Aditya Vidyadhar Kamath <ADITYA.VIDYADHAR.KAMATH@ibm.com> 123342 123343 Fix non-pointer type compilation error in aix-thread.c 123344 In aix-thread.c we use ms->value_address () to get the symbol address. 123345 This triggers the following compiler error... 123346 123347 base operand of '->' has non-pointer type 'bound_minimal_symbol' 123348 123349 ... because ms is not a pointer. 123350 123351 This commit fixes this error by using ms.value_address () instead. 123352 1233532022-05-20 Steinar H. Gunderson <sesse@google.com> 123354 123355 add a trie to map quickly from address range to compilation unit 123356 When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line() 123357 becomes a hotspot, as perf wants to get line number information 123358 (for inline-detection purposes) for each and every sample. In Chromium 123359 in particular (the content_shell binary), this entails going through 123360 475k address ranges, which takes a long time when done repeatedly. 123361 123362 Add a radix-256 trie over the address space to quickly map address to 123363 compilation unit spaces; for content_shell, which is 1.6 GB when some 123364 (but not full) debug information turned is on, we go from 6 ms to 123365 0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x 123366 speedup. 123367 123368 There is a modest RAM increase of 180 MB in this binary (the existing 123369 linked list over ranges uses about 10 MB, and the entire perf job uses 123370 between 2–3 GB for a medium-size profile); for smaller binaries with few 123371 ranges, there should be hardly any extra RAM usage at all. 123372 1233732022-05-20 Alan Modra <amodra@gmail.com> 123374 123375 Tidy warn-execstack handling 123376 Make ld and bfd values consistent by swapping values 0 and 2 in 123377 link_info.warn_execstack. This has the benefit of making the value an 123378 "extended" boolean, with 0 meaning no warning, 1 meaning warn, other 123379 values a conditional warning. 123380 123381 Yes, this patch introduces fails on arm/aarch64. Not a problem with 123382 this patch but an arm/aarch64 before_parse problem. 123383 123384 bfd/ 123385 * elflink.c (bfd_elf_size_dynamic_sections): Adjust 123386 warn_execstack test. 123387 include/ 123388 * bfdlink.h (warn_execstack): Swap 0 and 2 meaning. 123389 ld/ 123390 * configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0, 123391 1, 2 consistent with link_info.warn_execstack. 123392 * ld.texi: Typo fixes. 123393 * lexsup.c (parse_args): Adjust setting of link_info.warn_execstack. 123394 (elf_static_list_options): Adjust help message conditions. 123395 * configure: Regenerate. 123396 1233972022-05-20 GDB Administrator <gdbadmin@sourceware.org> 123398 123399 Automatic date update in version.in 123400 1234012022-05-19 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 123402 123403 arm: Fix system register fpcxt_ns and fpcxt_s naming convention. 123404 The current assembler accepts system registers FPCXTNS and FPCXTS for Armv8.1-M 123405 Mainline Instructions VSTR, VLDR, VMRS and VMSR. 123406 Assembler should be also allowing FPCXT_NS, fpcxt_ns, fpcxtns, FPCXT_S, fpcxt_s 123407 and fpcxts. This patch fixes the issue. 123408 1234092022-05-19 Andrew Burgess <aburgess@redhat.com> 123410 123411 gdb/doc: use @value{GDBP} in 'info pretty-printer' example 123412 Update the 'info pretty-printer' example in the manual to make use of 123413 @value{GDBP} instead of hard-coding '(gdb)'. 123414 1234152022-05-19 Andrew Burgess <aburgess@redhat.com> 123416 123417 gdb/doc: make use of group/end group in 'info pretty-printers' example 123418 The 'info pretty-printers' example is pretty long and consists of many 123419 commands and their output. 123420 123421 Currently, when the pdf manual is generated this example spans a 123422 page-break, with the page-break falling part way through some example 123423 output from GDB. 123424 123425 This commit breaks up the example using @group .... @end group, within 123426 each group is a single GDB command and all its output. 123427 123428 Now, when the pdf manual is created, the page-break is placed after 123429 the output of one GDB command, and before the subsequent command, this 123430 looks much nicer. 123431 1234322022-05-19 Nikolaos Chatzikonstantinou <nchatz314@gmail.com> 123433 123434 gdb/doc: fix inconsistent info pretty-printer example 123435 The example for 'info pretty-printer' in the manual passes an 123436 object-regexp in some cases, but presents output as though no 123437 object-regexp was passed. 123438 123439 This commit fixes the two mistakes, in one case, fixing the output to 123440 filter based on object-regexp, and in the other, to remove the 123441 object-regexp from the command and leave all the output. 123442 1234432022-05-19 Nick Clifton <nickc@redhat.com> 123444 123445 Fix potentially uninitialised variables in the Windows tools 123446 1234472022-05-19 Tiezhu Yang <yangtiezhu@loongson.cn> 123448 123449 gdb: testsuite: Support displaced stepping on LoongArch 123450 When execute the following command on LoongArch: 123451 123452 make check-gdb TESTS="gdb.base/async-shell.exp" 123453 123454 we can see the following message in gdb/testsuite/gdb.sum: 123455 123456 UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping 123457 123458 modify support_displaced_stepping to support displaced stepping 123459 on LoongArch. 123460 123461 With this patch: 123462 123463 PASS: gdb.base/async-shell.exp: run & 123464 PASS: gdb.base/async-shell.exp: shell echo foo 123465 PASS: gdb.base/async-shell.exp: interrupt 123466 PASS: gdb.base/async-shell.exp: process stopped 123467 123468 I did the following tests that use support_displaced_stepping 123469 with this patch on LoongArch, there is no failed testcases. 123470 123471 loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.* 123472 gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } { 123473 gdb/testsuite/gdb.base/step-over-no-symbols.exp: if { $displaced != "off" && ![support_displaced_stepping] } { 123474 gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } { 123475 gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } { 123476 gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } { 123477 gdb/testsuite/gdb.base/step-over-syscall.exp: if {$displaced == "on" && ![support_displaced_stepping]} { 123478 gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } { 123479 gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } { 123480 gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } { 123481 gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } { 123482 gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } { 123483 gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } { 123484 gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } { 123485 gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] { 123486 gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } { 123487 gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } { 123488 gdb/testsuite/gdb.threads/interrupt-while-step-over.exp: if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } { 123489 gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } { 123490 1234912022-05-19 Simon Marchi <simon.marchi@polymtl.ca> 123492 123493 gdbsupport: fix path_join crash with -std=c++17 and -D_GLIBCXX_DEBUG 123494 When building GDB with -std=c++17 and -D_GLIBCXX_DEBUG=1, I get: 123495 123496 $ ./gdb -nx --data-directory=data-directory -q -ex "maint selftest path_join" 123497 /usr/include/c++/11.2.0/string_view:233: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. 123498 123499 The problem is that we're passing an empty string_view to 123500 IS_ABSOLUTE_PATH. IS_ABSOLUTE_PATH accesses [0] on that string_view, 123501 which is out-of-bounds. 123502 123503 The reason this is not seen with -std less than c++17 is that our local 123504 copy of string_view (used with C++ < 17) does not have the assert in 123505 operator[], as that wouldn't work in a constexpr method: 123506 123507 https://gitlab.com/gnutools/binutils-gdb/-/blob/5890af36e5112bcbb8d7555e63570f68466e6944/gdbsupport/gdb_string_view.h#L180 123508 123509 IS_ABSOLUTE_PATH is normally used with null-terminated string. It's 123510 fine to pass an empty null-terminated string to IS_ABSOLUTE_PATH, 123511 because index 0 in such a string is valid. But not with an empty 123512 string_view. 123513 123514 Fix that by avoiding the "call" to IS_ABSOLUTE_PATH if the string_view 123515 is empty. 123516 123517 Change-Id: Idf4df961b63f513b3389235e93814c02b89ea32e 123518 1235192022-05-19 Jan Beulich <jbeulich@suse.com> 123520 123521 Arm64: force emission of ILP32-dependent relocs 123522 Like the placeholder types added in 04dfe7aa5217 ("Arm64: follow-on to 123523 PR gas/27217 fix"), these are also placeholders which are subsequently 123524 resolved (albeit later, hence this being a separate issue). As for the 123525 resolved types 1 is returned, these pseudo-relocs should also have 1 123526 returned to force retaining of the [eventual] relocations. This is also 123527 spelled out individually for each of them in md_apply_fix(). 123528 1235292022-05-19 Jan Beulich <jbeulich@suse.com> 123530 123531 COFF: use hash for string table also when copying / stripping 123532 Otherwise the string table may grow and hence e.g. change a final binary 123533 (observed with PE/COFF ones) even if really there's no change. Doing so 123534 in fact reduces the overall amount of code, and in particular the number 123535 of places which need to remain in sync. 123536 123537 Afaics there's no real equivalent to the "traditional_format" field used 123538 when linking, so hashing is always enabled when copying / stripping. 123539 1235402022-05-19 Jan Beulich <jbeulich@suse.com> 123541 123542 COFF/PE: keep linker version during objcopy / strip 123543 Neither of the tools is really a linker, so whatever was originally 123544 recorded should be retained rather than being overwritten by these 123545 tools' versions. 123546 123547 COFF/PE: don't leave zero timestamp after objcopy / strip 123548 Fill the timestamp field suitably for _bfd_XXi_only_swap_filehdr_out(). 123549 Instead of re-arranging the present if(), fold this logic with that of 123550 copying the optional header. 123551 1235522022-05-19 Jan Beulich <jbeulich@suse.com> 123553 123554 COFF: make objcopy / strip honor --keep-file-symbols 123555 So far this option had no effect when used together with e.g. 123556 --strip-debug. Set BSF_FILE on these symbols to change that. 123557 123558 While altering this also join two adjacent blocks of case labeled 123559 statements with identical code. 123560 1235612022-05-19 Jan Beulich <jbeulich@suse.com> 123562 123563 don't over-align file positions of PE executable sections 123564 When a sufficiently small alignment was specified via --file-alignment, 123565 individual section alignment shouldn't affect placement within the file. 123566 This involves first of all clearing D_PAGED for images when section and 123567 file alignment together don't permit paging of the image. The involved 123568 comparison against COFF_PAGE_SIZE in turn helped point out (through a 123569 compiler warning) that 'page_size' should be of unsigned type (as in 123570 particular FileAlignment is). This yet in turn pointed out a dubious 123571 error condition (which is being deleted). 123572 123573 For the D_PAGED case I think the enforced file alignment may still be 123574 too high, but I'm wary of changing that logic without knowing of 123575 possible corner cases. 123576 123577 Furthermore file positions in PE should be independent of the alignment 123578 recorded in section headers anyway. Otherwise there are e.g. anomalies 123579 following commit 6f8f6017a0c4 ("PR27567, Linking PE files adds alignment 123580 section flags to executables") in that linking would use information a 123581 subsequent processing step (e.g. stripping) wouldn't have available 123582 anymore, and hence a binary could change in that 2nd step for no actual 123583 reason. (Similarly stripping a binary linked with a linker pre-dating 123584 that commit would change the binary again when stripping it a 2nd time.) 123585 1235862022-05-19 Yvan Roux <yvan.roux@foss.st.com> 123587 123588 _bfd_real_fopen should not use ccs parameter on Windows 123589 PR 25713 123590 * bfdio.c (_bfd_real_fopen): Delete ccs string. 123591 1235922022-05-19 Tsukasa OI <research_trasio@irq.a4lg.com> 123593 123594 RISC-V: Fix canonical extension order (K and J) 123595 This commit fixes canonical extension order to follow the RISC-V ISA 123596 Manual draft-20210402-1271737 or later. 123597 123598 bfd/ChangeLog: 123599 123600 * elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension 123601 prefix to be placed before "J". 123602 1236032022-05-19 GDB Administrator <gdbadmin@sourceware.org> 123604 123605 Automatic date update in version.in 123606 1236072022-05-18 John Baldwin <jhb@FreeBSD.org> 123608 123609 Use aarch64_features to describe register features in target descriptions. 123610 Replace the sve bool member of aarch64_features with a vq member that 123611 holds the vector quotient. It is zero if SVE is not present. 123612 123613 Add std::hash<> specialization and operator== so that aarch64_features 123614 can be used as a key with std::unordered_map<>. 123615 123616 Change the various functions that create or lookup aarch64 target 123617 descriptions to accept a const aarch64_features object rather than a 123618 growing number of arguments. 123619 123620 Replace the multi-dimension tdesc_aarch64_list arrays used to cache 123621 target descriptions with unordered_maps indexed by aarch64_feature. 123622 1236232022-05-18 Jan Beulich <jbeulich@suse.com> 123624 123625 Arm64: follow-on to PR gas/27217 fix 123626 PR gas/27217 123627 123628 Prior to trying to address PR gas/28888 I noticed anomalies in how 123629 certain insns would / wouldn't be affected in similar ways. 123630 123631 Commit eac4eb8ecb26 ("Fix a problem assembling AArch64 sources when a 123632 relocation is generated against a symbol that has a defined value") had 123633 two copy-and-paste mistakes, passing the wrong type to 123634 aarch64_force_reloc(). 123635 123636 It further failed to add placeholder relocation types to that function's 123637 block of case labels leading to a return of 1. While not of interest for 123638 aarch64_force_relocation() (these placeholders are resolved right in 123639 parse_operands()), calls to aarch64_force_reloc() happen before that 123640 resolution would take place. 123641 1236422022-05-18 Nick Clifton <nickc@redhat.com> 123643 123644 Fix compile time warning building gold with Clang-14. 123645 * int_encoding.cc (get_length_as_unsigned_LEB_128): Remove 123646 current_length variable. 123647 1236482022-05-18 Victor Do Nascimento <victor.donascimento@arm.com> 123649 123650 oops - forgot changelog entry for the previous delta. 123651 123652 arm: Add unwind support for mixed register lists 123653 * config/tc-arm.c (parse_reg_list): Add handling of mixed register 123654 types. 123655 (reg_names): Enumerate pseudoregister according to mapped physical 123656 register number. 123657 (s_arm_unwind_save_pseudo): Modify function signature. 123658 (s_arm_unwind_save_core): Likewise. 123659 (s_arm_unwind_save_mixed): New function. 123660 (s_arm_unwind_save): Generate register list mask to pass to nested 123661 functions. 123662 * testsuite/gas/arm/unwind-pacbti-m.s: Expand test for mixed 123663 register type lists. 123664 * testsuite/gas/arm/unwind-pacbti-m.d: Likewise. 123665 * testsuite/gas/arm/unwind-pacbti-m-readelf.d: Likewise. 123666 1236672022-05-18 Carl Love <cel@us.ibm.com> 123668 123669 PowerPC: bp-permanent.exp, kill-after-signal fix 123670 Fix changes that didn't make it into commit: 123671 dd9cd55e990bcc9f8448cac38d242d53974b3604. 123672 123673 Fix missing -wrap on gdb_test_multiple in gdb.base/kill-after-signal.exp 123674 that is causing regression test on x86_64-linux with taskset -c 0. 123675 1236762022-05-18 Yichao Yu <yyc1992@gmail.com> 123677 123678 [AArch64] Return the regnum for PC (32) on aarch64 123679 This will allow the unwind info to explicitly specify a different value 123680 for the return address from the link register. 123681 Such usage, although uncommon, is valid and useful for signal frames. 123682 It is also supported by aadwarf64 from ARM (Note 9 in [1]). 123683 123684 Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html 123685 123686 [1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names 123687 1236882022-05-18 Jan Beulich <jbeulich@suse.com> 123689 123690 x86: shrink op_riprel 123691 It is only ever initialized from a boolean, so it as well as related 123692 variables' types can simply be bool and there's no masking to 32 bits 123693 needed in set_op(). 123694 1236952022-05-18 Nick Clifton <nickc@redhat.com> 123696 123697 Add a --no-weak option to nm. 123698 PR 29135 123699 * nm.c (non_weak): New variable. 123700 (filter_symbols): When non-weak is true, ignore weak symbols. 123701 (long_options): Add --no-weak. 123702 (usage): Mention --no-weak. 123703 (main): Handle -W/--no-weak. 123704 * doc/binutils.texi: Document new feature. 123705 * NEWS: Mention the new feature. 123706 * testsuite/binutils-all/nm.exp: Add test of new feature. 123707 * testsuite/binutils-all/no-weak.s: New test source file. 123708 1237092022-05-18 Pedro Alves <pedro@palves.net> 123710 123711 Support -prompt and -lbl in gdb_test 123712 This teaches gdb_test to forward the -prompt and -lbl options to 123713 gdb_test_multiple. 123714 123715 The option parsing is done with parse_args. 123716 123717 As a cleanup, instead of using llength and lindex to get at the 123718 positional arguments, use lassign, and check whether the corresponding 123719 variable is empty. 123720 123721 Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use 123722 gdb_test -prompt/-lbl instead of gdb_test_multiple as examples. 123723 123724 Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0 123725 1237262022-05-18 Luis Machado <luis.machado@arm.com> 123727 123728 Remove unused DWARF PAUTH registers 123729 The AARCH64_DWARF_PAUTH_DMASK and AARCH64_DWARF_PAUTH_CMASK DWARF registers 123730 never made their way into the aadwarf64. The following patch removes these 123731 constants and their use. 123732 123733 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26295 123734 1237352022-05-18 Luis Machado <luis.machado@arm.com> 123736 123737 Rename PAUTH_RA_STATE to RA_SIGN_STATE 123738 The aadwarf64 [1] names this register RA_SIGN_STATE, so update the code to use 123739 the same name. 123740 123741 [1] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst 123742 1237432022-05-18 Tom de Vries <tdevries@suse.de> 123744 123745 [gdb/testsuite] Simplify unknown lang testing in gdb.base/parse_number.exp 123746 Move testing of language unknown out of the $supported_archs loop in 123747 gdb.base/parse_number.exp. This reduces total amount of tests from 18466 to 123748 17744. 123749 123750 Tested on x86_64-linux. 123751 1237522022-05-18 Tom de Vries <tdevries@suse.de> 123753 123754 [gdb/testsuite] Use hex_for_lang in gdb.base/parse_number.exp 123755 In gdb.base/parse_number.exp, add a new proc hex_for_lang that formats a hex 123756 number appropriately for a given language. 123757 123758 Tested on x86_64-linux. 123759 1237602022-05-18 Tom de Vries <tdevries@suse.de> 123761 123762 [gdb/tdep] Add gdb/syscalls/update-linux-from-src.sh 123763 Add a new script gdb/syscalls/update-linux-from-src.sh, that can be used to 123764 generate *-linux.xml.in files from linux kernel sources, like so: 123765 ... 123766 $ ./update-linux-from-src.sh ~/upstream/linux-stable.git 123767 Skipping aarch64-linux.xml.in, no syscall.tbl 123768 Generating amd64-linux.xml.in 123769 Skipping arm-linux.xml.in, use arm-linux.py instead 123770 Skipping bfin-linux.xml.in, no longer supported 123771 Generating i386-linux.xml.in 123772 Generating mips-n32-linux.xml.in 123773 Generating mips-n64-linux.xml.in 123774 Generating mips-o32-linux.xml.in 123775 Generating ppc64-linux.xml.in 123776 Generating ppc-linux.xml.in 123777 Generating s390-linux.xml.in 123778 Generating s390x-linux.xml.in 123779 Generating sparc64-linux.xml.in 123780 Generating sparc-linux.xml.in 123781 ... 123782 123783 Update *-linux.xml.in and *-linux.xml using linux kernel tag v5.18-rc6. 123784 1237852022-05-18 Tamar Christina <tamar.christina@arm.com> 123786 123787 AArch64: Enable FP16 by default for Armv9-A. 123788 In Armv9-A SVE is mandatory, and for SVE FP16 is mandatory. This fixes a disconnect 123789 between GCC and binutils where GCC has FP16 on by default and gas doesn't. 123790 123791 include/ChangeLog: 123792 123793 2022-05-16 Tamar Christina <tamar.christina@arm.com> 123794 123795 * opcode/aarch64.h (AARCH64_ARCH_V9_FEATURES): Add AARCH64_FEATURE_F16. 123796 1237972022-05-18 Jan Beulich <jbeulich@suse.com> 123798 123799 gas: avoid octal numbers being accepted when processing .linefile 123800 Compilers would put decimal numbers there, so I think we should treat 123801 finding octal numbers the same as finding bignums - ignore them as 123802 actually being comments of some very specific form. 123803 1238042022-05-18 Jan Beulich <jbeulich@suse.com> 123805 123806 gas: avoid bignum related errors when processing .linefile 123807 Any construct which to the scrubber looks like a C preprocessor 123808 line/file "directive" is converted to .linefile, but the amount of 123809 checking the scrubber does is minimal (albeit it does let through only 123810 decimal digits for the line part of the contruct). Since the scrubber 123811 conversion is further tied to # being a line comment character, anything 123812 which upon closer inspection turns out not to be a line/file "directive" 123813 is supposed to be treated as a comment, i.e. ignored. Therefore we 123814 cannot use get_absolute_expression(), as this may raise errors. Open- 123815 code the function instead, treating everything not resulting in 123816 O_constant as a comment as well. 123817 123818 Furthermore also bounds-check the parsed value. This bounds check tries 123819 to avoid implementation defined behavior (which may be the raising of an 123820 implementation defined signal), but for now makes the assumption that 123821 int has less than 64 bits. The way bfd_signed_vma (which is what offsetT 123822 aliases) is defined in bfd.h for the BFD64 case I cannot really see a 123823 clean way of avoiding this assumption. Omitting the #ifdef, otoh, would 123824 risk "condition is always false" warnings by compilers. 123825 123826 Convert get_linefile_number() to return bool at this occasion as well. 123827 1238282022-05-18 Jan Beulich <jbeulich@suse.com> 123829 123830 gas: fold do_repeat{,_with_expander}() 123831 do_repeat_with_expander() already deals with the "no expander" case 123832 quite fine, so there's really little point having two functions. What it 123833 lacks compared with do_repeat() is a call to sb_build(), which can 123834 simply be moved (and the then redundant sb_new() be avoided). Along with 123835 this moving also flip if the main if()'s condition such that the "no 123836 expander" case is handled first. 123837 123838 gas: don't ignore .linefile inside false conditionals 123839 When assembling code previously pre-processed by a C compiler, long 123840 enough comments may have been collapsed into "# <line> <file>" 123841 constructs. If we skip these, line numbers (and possibly even file 123842 names) will be off / wrong in both diagnostics and debug info. 123843 123844 gas: simplify ignore_input() 123845 First of all convert to switch(), in preparation of adding another 123846 directive here which may not be ignored. While doing so drop dead code: 123847 A string the first two characters of which do not match "if" also wont 123848 match "ifdef" or "ifndef". 123849 123850 gas: tweak .irp and alike file/line handling for M68K/MRI 123851 In commit 2ee1792bec22 ("gas: further adjust file/line handling for .irp 123852 and alike") I neglected the need to omit the leading . in M68K/MRI mode. 123853 1238542022-05-18 Xi Ruoyao <xry111@mengyan1223.wang> 123855 123856 gold: don't invoke IA32 syscall in x86_64 assembly testcase 123857 pr17704a_test.s is a x86_64 assembly file, but it invokes IA32 exit 123858 syscall with "int 0x80". This causes a segfault on kernels with 123859 CONFIG_IA32_EMULATION disabled. 123860 123861 gold/ 123862 123863 * testsuite/pr17704a_test.s (_start): Invoke x86_64 exit syscall 123864 instead of its IA32 counterpart. 123865 1238662022-05-18 GDB Administrator <gdbadmin@sourceware.org> 123867 123868 Automatic date update in version.in 123869 1238702022-05-17 Nikolaos Chatzikonstantinou <nchatz314@gmail.com> 123871 123872 Fix typo in info page 123873 1238742022-05-17 Pedro Alves <pedro@palves.net> 123875 123876 Fix gdb.python/py-connection.exp with remote targets 123877 After the patch to make gdb_test's question non-optional when 123878 specified, gdb.python/py-connection.exp started failing like so: 123879 123880 $ make check TESTS="gdb.python/py-connection.exp" RUNTESTFLAGS="--target_board=native-gdbserver" 123881 (gdb) PASS: gdb.python/py-connection.exp: info connections while the connection is still around 123882 disconnect^M 123883 Ending remote debugging.^M 123884 (gdb) FAIL: gdb.python/py-connection.exp: kill the inferior 123885 123886 The problem is that "disconnect" when debugging with the native target 123887 asks the user whether to kill the program, while with remote targets, 123888 it doesn't. 123889 123890 Fix it by explicitly killing before disconnecting. 123891 123892 Tested with --target_board unix, native-gdbserver, and native-extended-gdbserver. 123893 123894 Change-Id: Icd85015c76deb84b71894715d43853c1087eba0b 123895 1238962022-05-17 Felix Willgerodt <felix.willgerodt@intel.com> 123897 123898 gdb, btrace: Throw an error for empty recordings when replaying starts. 123899 This makes record_btrace_start_replaying() more consistent, as it already 123900 errors out e.g. on a recording with only gaps. 123901 1239022022-05-17 Pedro Alves <pedro@palves.net> 123903 123904 Make gdb_test's question non-optional if specified 123905 gdb_test supports handling scenarios where GDB asks a question before 123906 finishing handling some command. The full prototype of gdb_test is: 123907 123908 # gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE 123909 123910 However, QUESTION is a question that GDB _may_ ask, not one that GDB 123911 _must_ ask: 123912 123913 # QUESTION is a question GDB may ask in response to COMMAND, like 123914 # "are you sure?" 123915 # RESPONSE is the response to send if QUESTION appears. 123916 123917 If GDB doesn't raise the question, the test still passes. 123918 123919 I think that this is a misfeature. If GDB regresses and stops asking 123920 a question, the testsuite won't notice. So I think that if a QUESTION 123921 is specified, gdb_test should ensure it comes out of GDB. 123922 123923 Running the testsuite exposed a number of tests that pass 123924 QUESTION/RESPONSE to GDB, but no question comes out. The previous 123925 commits fixed them all, so this commit changes gdb_test's behavior. 123926 123927 A related issue is that gdb_test doesn't enforce that if you specify 123928 QUESTION, that you also specify RESPONSE. I.e., you should pass 1, 2, 123929 3, or 5 arguments to gdb_test, but never 4, or more than 5. Making 123930 gdb_test detect bogus arguments actually regressed some testcases, 123931 also all fixed in previous commits. 123932 123933 Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db 123934 1239352022-05-17 Pedro Alves <pedro@palves.net> 123936 123937 gdb.base/skip.exp: Don't abuse gdb_test's question support 123938 gdb.base/skip.exp abuses gdb_test's support for answering a GDB 123939 question to do this: 123940 123941 # With gcc 9.2.0 we jump once back to main before entering foo here. 123942 # If that happens try to step a second time. 123943 gdb_test "step" "foo \\(\\) at.*" "step 3" \ 123944 "main \\(\\) at .*\r\n$gdb_prompt " "step" 123945 123946 After a patch later in this series, gdb_test will FAIL if GDB does NOT 123947 issue the question, so this test would start failing on older GCCs. 123948 123949 Switch to using gdb_test_multiple instead. There are three spots in 123950 the file that have the same pattern, and they're actually in a 123951 sequence of commands that is repeated those 3 times. Factor all that 123952 out to a procedure. 123953 123954 I don't have gcc 9.2 handy, but I do have gcc 6.5, and that one is 123955 affected as well, so update the comment. 123956 123957 Change-Id: If0a7e3cdf5191b4eec95ce0c8845c3a4d801c39e 123958 1239592022-05-17 Pedro Alves <pedro@palves.net> 123960 123961 Avoid having to unload file in gdb.server/connect-with-no-symbol-file.exp 123962 gdb.server/connect-with-no-symbol-file.exp's connect_no_symbol_file 123963 does: 123964 123965 gdb_test "file" ".*" "discard symbol table" \ 123966 {Discard symbol table from `.*'\? \(y or n\) } "y" 123967 123968 A following patch will make gdb_test expect the question out of GDB if 123969 one is passed down as argument to gdb_test. With that, this test 123970 starts failing. This is because connect_no_symbol_file is called in a 123971 loop, and the first time around, there's a loaded file, so "file" asks 123972 the "Discard symbol table ... ?" question, while in the following 123973 iterations there's no file, so there's no question. 123974 123975 Fix this by not loading a file into GDB in the first place. 123976 123977 Change-Id: I810c036b57842c4c5b47faf340466b0d446d1abc 123978 1239792022-05-17 Pedro Alves <pedro@palves.net> 123980 123981 Fix bogus gdb_test invocations 123982 A following patch will make gdb_test error out if bogus arguments are 123983 passed, which exposed bugs in a few testcases: 123984 123985 - gdb.python/py-parameter.exp, passing a spurious "1" as extra 123986 parameter, resulting in: 123987 123988 ERROR: Unexpected arguments: {set test-file-param bar.txt} {The name of the file has been changed to bar.txt} {set new file parameter} 1 123989 123990 - gdb.python/py-xmethods.exp, a missing test message, resulting in 123991 the next gdb_test being interpreted as message, question and 123992 response! With the enforcing patch, this was caught with: 123993 123994 ERROR: Unexpected arguments: {p g.mul<char>('a')} {From Python G<>::mul.*} gdb_test {p g_ptr->mul<char>('a')} {From Python G<>::mul.*} {after: g_ptr->mul<char>('a')} 123995 123996 - gdb.base/pointers.exp, missing a quote. 123997 123998 Change-Id: I66f2db4412025a64121db7347dfb0b48240d46d4 123999 1240002022-05-17 Pedro Alves <pedro@palves.net> 124001 124002 gdb.base/scope.exp: Remove bogus gdb_test questions 124003 This test is abusing the QUESTION/RESPONSE feature to send an 124004 alternative command to GDB if the first command fails. Like so: 124005 124006 gdb_test "print 'scope0.c'::filelocal" \ 124007 "\\\$$decimal = 1" "print 'scope0.c'::filelocal at main" \ 124008 "No symbol \"scope0.c\" in current context.*" \ 124009 "print '$srcdir/$subdir/scope0.c'::filelocal" 124010 124011 So if 'scope0.c' doesn't work, we try again with 124012 '$srcdir/$subdir/scope0.c'. I strongly suspect this is really an 124013 obsolete test. I think that if '$srcdir/$subdir/scope0.c' works, then 124014 'scope0.c' should have worked too, thus I'd think that if we pass due 124015 to the question path, then it's a bug. So just remove the question 124016 part passed to gdb_test. 124017 124018 Change-Id: I2acc99285f1d519284051b49693b5441fbdfe3cd 124019 1240202022-05-17 Pedro Alves <pedro@palves.net> 124021 124022 Remove gdb_test questions that GDB doesn't ask 124023 Change-Id: Ib2616dc883e9dc9ee100f6c86d83a921a0113c16 124024 1240252022-05-17 Nelson Chu <nelson.chu@sifive.com> 124026 124027 RISC-V: Added half-precision floating-point v1.0 instructions. 124028 bfd/ 124029 * elfxx-riscv.c (riscv_implicit_subsets): Added implicit f 124030 and zicsr for zfh. 124031 (riscv_supported_std_z_ext): Added default v1.0 version for zfh. 124032 (riscv_multi_subset_supports): Handle INSN_CLASS_ZFH, 124033 INSN_CLASS_D_AND_ZFH and INSN_CLASS_Q_AND_ZFH. 124034 gas/ 124035 * config/tc-riscv.c (FLT_CHARS): Added "hH". 124036 (macro): Expand Pseudo M_FLH and M_FSH. 124037 (riscv_pseudo_table): Added .float16 directive. 124038 * testsuite/gas/riscv/float16-be.d: New testcase for .float16. 124039 * testsuite/gas/riscv/float16-le.d: Likewise. 124040 * testsuite/gas/riscv/float16.s: Likewise. 124041 * testsuite/gas/riscv/fp-zfh-insns.d: New testcase for zfh. 124042 * testsuite/gas/riscv/fp-zfh-insns.s: Likewise. 124043 include/ 124044 * opcode/riscv-opc.h: Added MASK and MATCH encodings for zfh. 124045 * opcode/riscv.h: Added INSN_CLASS and pseudo macros for zfh. 124046 opcodes/ 124047 * riscv-opc.c (riscv_opcodes): Added zfh instructions. 124048 1240492022-05-17 GDB Administrator <gdbadmin@sourceware.org> 124050 124051 Automatic date update in version.in 124052 1240532022-05-16 Ilya Leoshkevich <iii@linux.ibm.com> 124054 124055 IBM zSystems: Fix left-shifting negative PCRel32 values (PR gas/29152) 124056 s390_insert_operand ()'s val, min and max are encoded PCRel32 values 124057 and need to be left-shifted by 1 before being shown to the user. 124058 Left-shifting negative values is undefined behavior in C, but the 124059 current code does not try to prevent it, causing UBSan to complain. 124060 124061 Fix by casting the values to their unsigned equivalents before 124062 shifting. 124063 1240642022-05-16 Pedro Alves <pedro@palves.net> 124065 124066 Reindent gdbsupport/event-loop.cc:handle_file_event 124067 The handle_file_event function has a few unnecessary {} lexical 124068 blocks, presumably because they were originally if blocks, and the 124069 conditions were removed, or something along those lines. 124070 124071 Remove the unnecessary blocks, and reindent. 124072 124073 Change-Id: Iaecbe5c9f4940a80b81dbbc42e51ce506f6aafb2 124074 1240752022-05-16 Pedro Alves <pedro@palves.net> 124076 124077 gdbsupport/event-loop.cc: simplify !HAVE_POLL paths 124078 gdbsupport/event-loop.cc throughout handles the case of use_poll being 124079 true on a system where HAVE_POLL is not defined, by calling 124080 internal_error if that situation ever happens. 124081 124082 Simplify this by moving the "use_poll" global itself under HAVE_POLL, 124083 so that it's way more unlikely to ever end up in such a situation. 124084 Then, move the code that checks the value of use_poll under HAVE_POLL 124085 too, and remove the internal_error calls. Like, from: 124086 124087 if (use_poll) 124088 { 124089 #ifdef HAVE_POLL 124090 // poll code 124091 #else 124092 internal_error (....); 124093 #endif /* HAVE_POLL */ 124094 } 124095 else 124096 { 124097 // select code 124098 } 124099 124100 to 124101 124102 #ifdef HAVE_POLL 124103 if (use_poll) 124104 { 124105 // poll code 124106 } 124107 else 124108 #endif /* HAVE_POLL */ 124109 { 124110 // select code 124111 } 124112 124113 While at it, make use_poll be a bool. The current code is using 124114 unsigned char most probably to save space, but I don't think it really 124115 matters here. 124116 124117 Co-Authored-By: Youling Tang <tangyouling@loongson.cn> 124118 Change-Id: I0dd74fdd4d393ccd057906df4cd75e8e83c1cdb4 124119 1241202022-05-16 Eli Zaretskii <eliz@gnu.org> 124121 124122 gdb: Fix typo in last change in gdb.texinfo 124123 124124 gdb: Document the 'metadata' styling in GDB displays. 124125 The 'metadata' styling was never documented in the GDB manual. 124126 This fills that gap. 124127 1241282022-05-16 Tom Tromey <tromey@adacore.com> 124129 124130 Fix Ada exception regression on Windows 124131 The breakpoint c++-ification series introduced another bug in Ada -- 124132 it caused "catch exception" and related commands to fail on Windows. 124133 The problem is that the re_set method calls the wrong superclass 124134 method, so the breakpoint doesn't get correctly re-set when the 124135 runtime offsets change. This patch fixes the problem. 124136 1241372022-05-16 Bruno Larsen <blarsen@redhat.com> 124138 124139 gdb/testsuite: fix "continue outside of loop" TCL errors 124140 Many test cases had a few lines in the beginning that look like: 124141 124142 if { condition } { 124143 continue 124144 } 124145 124146 Where conditions varied, but were mostly in the form of ![runto_main] or 124147 [skip_*_tests], making it quite clear that this code block was supposed 124148 to finish the test if it entered the code block. This generates TCL 124149 errors, as most of these tests are not inside loops. All cases on which 124150 this was an obvious mistake are changed in this patch. 124151 1241522022-05-16 GDB Administrator <gdbadmin@sourceware.org> 124153 124154 Automatic date update in version.in 124155 1241562022-05-15 GDB Administrator <gdbadmin@sourceware.org> 124157 124158 Automatic date update in version.in 124159 1241602022-05-14 GDB Administrator <gdbadmin@sourceware.org> 124161 124162 Automatic date update in version.in 124163 1241642022-05-13 Tom Tromey <tromey@adacore.com> 124165 124166 Remove unused field cooked_index::m_start 124167 cooked_index::m_start is unused and can be removed. I think this was 124168 a leftover from a previous approach in the index finalization code, 124169 and then when rewriting it I forgot to remove it. 124170 124171 Tested by rebuilding. 124172 1241732022-05-13 Tom Tromey <tromey@adacore.com> 124174 124175 Implement pid_to_exec_file for Windows in gdbserver 124176 I noticed that gdbserver did not implement pid_to_exec_file for 124177 Windows, while gdb did implement it. This patch moves the code to 124178 nat/windows-nat.c, so that it can be shared. This makes the gdbserver 124179 implementation trivial. 124180 124181 Remove windows_process_info::id 124182 I noticed that windows_process_info::id is only used by gdbserver, and 124183 not really necessary. This patch removes it. 124184 124185 Constify target_pid_to_exec_file 124186 This changes target_pid_to_exec_file and target_ops::pid_to_exec_file 124187 to return a "const char *". I couldn't build many of these targets, 124188 but did examine the code by hand -- also, as this only affects the 124189 return type, it's normally pretty safe. This brings gdb and gdbserver 124190 a bit closer, and allows for the removal of a const_cast as well. 124191 124192 Put corefile-run.core into test subdirectory 124193 I noticed that corefile-run.core ends up in the 'runtest' directory. 124194 It's better, when at all possible, for test files to end up in the 124195 test's designated subdirectory. This patch makes this change. 124196 1241972022-05-13 Tom Tromey <tromey@adacore.com> 124198 124199 Do not double-read minimal symbols for PE COFF 124200 This changes coffread.c to avoid re-reading minimal symbols when 124201 possible. This only works when there are no COFF symbols to be read, 124202 but at least for my mingw builds of gdb, this seems to be the case. 124203 124204 Tested using the AdaCore internal test suite on Windows. I also did 124205 some local builds to ensure that no warnings crept in. 124206 1242072022-05-13 Pedro Alves <pedro@palves.net> 124208 124209 Fix "gdb --write" with core files 124210 If you load a core file into GDB with the --write option, or "set 124211 write on" (equivalent), and then poke memory expecting it to patch the 124212 core binary, you'll notice something odd -- the write seems to 124213 succeed, but in reality, it doesn't. The value you wrote doesn't 124214 persist. Like so: 124215 124216 $ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test 124217 [New LWP 615986] 124218 Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'. 124219 Program terminated with signal SIGTRAP, Trace/breakpoint trap. 124220 #0 0x0000555555555131 in ?? () 124221 (gdb) p *(unsigned char *)0x0000555555555131 = 1 124222 $1 = 1 '\001' 124223 (gdb) p *(unsigned char *)0x0000555555555131 124224 $2 = 185 '\271' 124225 (gdb) 124226 124227 Diffing hexdumps of before/after patching, reveals that a "0x1" was 124228 actually written somewhere in the file. The problem is that the "0x1" 124229 was written at the wrong offset in the file... 124230 124231 That happens because _bfd_elf_set_section_contents does this to seek 124232 to the section's offset: 124233 124234 pos = hdr->sh_offset + offset; 124235 if (bfd_seek (abfd, pos, SEEK_SET) != 0 124236 || bfd_bwrite (location, count, abfd) != count) 124237 return false; 124238 124239 ... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is 124240 incorrect. The reason 'hdr->sh_offset' is zero is that 124241 kernel-generated core files normally don't even have a section header 124242 table (gdb-generated ones do, but that's more an accident than a 124243 feature), and indeed elf_core_file_p doesn't even try to read sections 124244 at all: 124245 124246 /* Core files are simply standard ELF formatted files that partition 124247 the file using the execution view of the file (program header table) 124248 rather than the linking view. In fact, there is no section header 124249 table in a core file. 124250 124251 The process status information (including the contents of the general 124252 register set) and the floating point register set are stored in a 124253 segment of type PT_NOTE. We handcraft a couple of extra bfd sections 124254 that allow standard bfd access to the general registers (.reg) and the 124255 floating point registers (.reg2). */ 124256 124257 bfd_cleanup 124258 elf_core_file_p (bfd *abfd) 124259 124260 Changing _bfd_elf_set_section_contents from: 124261 124262 pos = hdr->sh_offset + offset; 124263 124264 to: 124265 124266 pos = section->filepos + offset; 124267 124268 fixes it. If we do that however, the tail end of 124269 _bfd_elf_set_section_contents ends up as a copy of 124270 _bfd_generic_set_section_contents, so just call the latter, thus 124271 eliminating some duplicate code. 124272 124273 New GDB testcase included, which exercises both patching an executable 124274 and patching a core file. Patching an executable already works 124275 without this fix, because in that case BFD reads in the sections 124276 table. Still, we had no testcase for that yet. In fact, we have no 124277 "set write on" testcases at all, this is the first one. 124278 124279 Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas. 124280 124281 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227 124282 Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce 124283 1242842022-05-13 Alan Modra <amodra@gmail.com> 124285 124286 Import libiberty from gcc 124287 124288 sim: remove use of PTR 124289 PTR will soon disappear from ansidecl.h. Remove uses in sim. Where 124290 a PTR cast is used in assignment or function args to a void* I've 124291 simply removed the unnecessary (in C) cast rather than replacing with 124292 (void *). 124293 1242942022-05-13 GDB Administrator <gdbadmin@sourceware.org> 124295 124296 Automatic date update in version.in 124297 1242982022-05-13 Alan Modra <amodra@gmail.com> 124299 124300 gdb: remove use of PTR 124301 PTR will disappear from ansidecl.h and libiberty on the next import 124302 from gcc. Remove current uses in gdb. 124303 1243042022-05-12 Tom de Vries <tdevries@suse.de> 124305 124306 [gdb/testsuite] Fix gdb.cp/break-f-std-string.cc with older gcc 124307 When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3 124308 with system gcc 7.5.0, I run into: 124309 ... 124310 (gdb) whatis /r std::string^M 124311 No symbol "string" in namespace "std".^M 124312 (gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \ 124313 whatis /r std::string 124314 ... 124315 The same for gcc 8.2.1, but it passes with gcc 9.3.1. 124316 124317 At source level (as we can observe in the .ii file with -save-temps) we have 124318 indeed: 124319 ... 124320 namespace std { 124321 namespace __cxx11 { 124322 typedef basic_string<char> string; 124323 } 124324 } 124325 ... 124326 while with gcc 9.3.1, we have instead: 124327 ... 124328 namespace std { 124329 namespace __cxx11 { 124330 ... 124331 } 124332 typedef basic_string<char> string; 124333 } 124334 ... 124335 due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs 124336 outside __cxx11 namespace"). 124337 124338 Fix this by adding the missing typedef for gcc version 5 (the first version to 124339 have the dual abi) to 8 (the last version missing aforementioned gcc commit). 124340 124341 Tested on x86_64-linux, with: 124342 - system gcc 7.5.0 124343 - gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1 124344 - clang 8.0.1, 12.0.1 124345 1243462022-05-12 Alan Modra <amodra@gmail.com> 124347 124348 Fix an illegal memory access when creating DLLs. 124349 PR 29006 124350 * pe-dll.c (dll_name): Delete, replacing with.. 124351 (dll_filename): ..this, moved earlier in file. 124352 (generate_edata): Delete parameters. Don't set up dll_name here.. 124353 (pe_process_import_defs): ..instead set up dll_filename and 124354 dll_symname here before returning. 124355 (dll_symname_len): Delete write-only variable. 124356 (pe_dll_generate_implib): Don't set up dll_symname here. 124357 1243582022-05-12 Mark Wielaard <mark@klomp.org> 124359 124360 gdb: Workaround stringop-overread warning in debuginfod-support.c on powerpc64 124361 Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a 124362 spurious warning for stringop-overread in debuginfod_is_enabled 124363 for url_view. Also suppress it on powerpc64. 124364 124365 gdb/ChangeLog: 124366 124367 * debuginfod-support.c (debuginfod_is_enabled): Use 124368 DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64. 124369 1243702022-05-12 Luis Machado <luis.machado@arm.com> 124371 124372 Make gdb.ada/float-bits.exp more generic 124373 There are assumptions in the test about the long double format 124374 being used. While the results are OK for i387 128-bit long doubles, it 124375 is not correct for IEEE quad 128-bit long doubles. 124376 124377 Also, depending on the target (64-bit/32-bit), long doubles may not 124378 be available at all. And it may be the case that the compiler for a 64-bit 124379 target doesn't support 128-bit long doubles, but GDB might still support it 124380 internally. 124381 124382 Lastly, not every long double format has invalid values. Some formats 124383 consider all values as valid floating point numbers. 124384 124385 These divergences cause the following FAIL's on aarch64/arm: 124386 124387 FAIL: gdb.ada/float-bits.exp: print val_long_double 124388 FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment 124389 124390 With the above in mind, extend the test a little so it behaves well on 124391 different architectures and so it works with different long double 124392 formats. 124393 124394 Main changes: 124395 124396 - Use long double values appropriate for the long double format. 124397 - Test long double assignment to compiler-generated long 124398 double variables. 124399 - Test long double assignment to GDB internal variables. 124400 124401 Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS). 124402 1244032022-05-12 Tom de Vries <tdevries@suse.de> 124404 124405 [gdb/tdep] Improve gdb/syscalls/update-linux.sh 124406 Fix two things in update-linux.sh: 124407 - remove use of unnecessary tmp file 124408 - inline gen-header.py into update-linux.sh 124409 124410 Tested on x86_64-linux. 124411 1244122022-05-12 Tom de Vries <tdevries@suse.de> 124413 124414 [gdb/testsuite] Fix gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on aarch64 124415 On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I 124416 run into: 124417 ... 124418 (gdb) run ^M 124419 Starting program: dw2-out-of-range-end-of-seq ^M 124420 ^M 124421 Program received signal SIGILL, Illegal instruction.^M 124422 main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M 124423 1 /* This testcase is part of GDB, the GNU debugger.^M 124424 (gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main 124425 ... 124426 124427 There are two problems here: 124428 - the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the 124429 breakpoint pointing in the middle of an insn 124430 - the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the 124431 test-case uses 'main_label' as the address of the first and only valid entry 124432 in the line table, and: 124433 - on aarch64-linux, there's no prologue, so main_label and main coincide, 124434 while 124435 - on x86_64-linux, there's a prologue, so main_label is different from main. 124436 124437 Fix these problems by: 124438 - eliminating the use of "DW_LNS_advance_pc 1", and using 124439 "DW_LNE_set_address $main_end" instead, and 124440 - eliminating the use of main_label, using "DW_LNE_set_address $main_start" 124441 instead. 124442 124443 Tested on both x86_64-linux and aarch64-linux. 124444 1244452022-05-12 Alan Modra <amodra@gmail.com> 124446 124447 cgen: increase buffer for hash_insn_list 124448 As was done for hash_insn_array in commit d3d1cc7b13b4. 124449 124450 * cgen-dis.c (hash_insn_list): Increase size of buf. Assert 124451 size is large enough. 124452 1244532022-05-12 Alan Modra <amodra@gmail.com> 124454 124455 PR29142, segv in ar with empty archive and libdeps specified 124456 PR 29142 124457 * ar.c (main): Properly handle libdeps for zero file_count. 124458 1244592022-05-12 Alan Modra <amodra@gmail.com> 124460 124461 Re: IBM zSystems: Accept (. - 0x100000000) PCRel32 operands 124462 The new test failed on s390-linux due to bfd_sprintf_vma trimming 124463 output to 32 bits for 32-bit targets. The test was faulty anyway, 124464 expecting zero as the min end of the range is plainly wrong, but 124465 that's what you get if you cast min to int. 124466 124467 * config/tc-s390.c (s390_insert_operand): Print range error using 124468 PRId64. 124469 * testsuite/gas/s390/zarch-z900-err.l: Correct expected output. 124470 1244712022-05-12 GDB Administrator <gdbadmin@sourceware.org> 124472 124473 Automatic date update in version.in 124474 1244752022-05-11 Tom de Vries <tdevries@suse.de> 124476 124477 [gdb/testsuite] Fix gdb.base/catch-syscall.exp with --with-expat=no 124478 When doing a gdb build with --with-expat=no, I run into: 124479 ... 124480 (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \ 124481 continue to breakpoint: before pipe call 124482 catch syscall pipe^M 124483 Unknown syscall name 'pipe'.^M 124484 (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \ 124485 catch syscall pipe 124486 catch syscall pipe2^M 124487 Unknown syscall name 'pipe2'.^M 124488 (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \ 124489 catch syscall pipe2 124490 continue^M 124491 Continuing.^M 124492 [Detaching after vfork from child process 18538]^M 124493 [Inferior 1 (process 18537) exited normally]^M 124494 (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue 124495 ... 124496 124497 This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle 124498 pipe2 syscall in gdb.base/catch-syscall.exp"). 124499 124500 Fix this by using pipe/pipe2 syscall numbers instead. 124501 124502 Tested on x86_64-linux. 124503 1245042022-05-11 Nick Clifton <nickc@redhat.com> 124505 124506 nm: use -U as an alias for --defines-only, in line with llvm-nm 124507 1245082022-05-11 Tom de Vries <tdevries@suse.de> 124509 124510 [gdb/testsuite] Fix gdb.base/catch-syscall.exp without --enable-targets 124511 When doing a gdb build without --enable-targets, I run into: 124512 ... 124513 (gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \ 124514 s390:31-bit vs s390:64-bit: set architecture s390:64-bit 124515 delete breakpoints^M 124516 (gdb) info breakpoints^M 124517 No breakpoints or watchpoints.^M 124518 (gdb) break -qualified main^M 124519 No symbol table is loaded. Use the "file" command.^M 124520 Make breakpoint pending on future shared library load? (y or [n]) n^M 124521 (gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main 124522 ... 124523 124524 The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove 124525 target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no 124526 longer is called at the end of test_catch_syscall_multi_arch. 124527 124528 Fix this by moving "clean_restart $binfile" back to 124529 test_catch_syscall_multi_arch. 124530 124531 Tested on x86_64-linux. 124532 1245332022-05-11 Tom de Vries <tdevries@suse.de> 124534 124535 [gdb/testsuite] Fix gdb.base/maint.exp on powerpc64le 124536 On powerpc64le-linux, I ran into: 124537 ... 124538 FAIL: gdb.base/maint.exp: maint print objfiles: symtabs 124539 ... 124540 124541 The problem is that: 124542 - the "Cooked index in use" line occurs twice in the gdb output: 124543 - once for exec maint, and 124544 - once for "Object file system-supplied DSO". 124545 - the matching of the second "Cooked index in use" also consumes 124546 the "Symtabs:" string, and consequently the corresponding 124547 clause does not trigger and $symtabs remains 0. 124548 124549 Fix this by limiting the output of the command to the exec. 124550 124551 Tested on x86_64-linux and powerpcle-linux. 124552 1245532022-05-11 Tom de Vries <tdevries@suse.de> 124554 124555 [gdb/tdep] Update syscalls/{ppc64,ppc}-linux.xml 124556 Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel. 124557 1245582022-05-11 Tom de Vries <tdevries@suse.de> 124559 124560 [gdb/testsuite] Remove target limits in gdb.base/catch-syscall.exp 124561 In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we 124562 test for supported targets using istarget, like so: 124563 ... 124564 if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } { 124565 ... 124566 } elseif { [istarget "powerpc-*-linux*"] \ 124567 || [istarget "powerpc64*-linux*"] } { 124568 ... 124569 ... 124570 but the tests excercised there can all be executed if gdb is configured with 124571 --enable-targets=all. 124572 124573 Rewrite the proc to iterate over all cases, and check if the test is supported 124574 by trying "set arch $arch1" and "set arch $arch2". 124575 124576 Tested on x86_64-linux, with: 124577 - a gdb build with --enable-targets=all, and 124578 - a gdb build build with my usual --enable-targets setting (too long to 124579 include here) which means the sparc vs sparc:v9 case is unsupported. 124580 1245812022-05-11 Tom de Vries <tdevries@suse.de> 124582 124583 [gdb/record] Handle statx system call 124584 When running test-case gdb.reverse/fstatat-reverse.exp with target board 124585 unix/-m32 on openSUSE Tumbleweed, I run into: 124586 ... 124587 (gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2 124588 continue^M 124589 Continuing.^M 124590 Process record and replay target doesn't support syscall number 383^M 124591 Process record: failed to record execution log.^M 124592 ^M 124593 Program stopped.^M 124594 0xf7fc5555 in __kernel_vsyscall ()^M 124595 (gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2 124596 ... 124597 124598 The problems is that while with native we're trying to record these syscalls 124599 (showing strace output): 124600 ... 124601 openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3 124602 newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0 124603 ... 124604 with unix/-m32 we have instead: 124605 ... 124606 openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3 124607 statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \ 124608 {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \ 124609 stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0 124610 ... 124611 and statx is not supported. 124612 124613 Fix this by adding support for recording syscall statx. 124614 124615 Tested on x86_64-linux. 124616 124617 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28461 124618 1246192022-05-11 Alan Modra <amodra@gmail.com> 124620 124621 opcodes cgen: remove use of PTR 124622 Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted, 124623 due to failure of bpf to compile with that patch applied. 124624 124625 .../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow] 124626 57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } } 124627 plus other similar errors. 124628 124629 cpu/ 124630 * mep.opc (print_tpreg, print_spreg): Delete unnecessary 124631 forward declarations. Replace PTR with void *. 124632 * mt.opc (print_dollarhex, print_pcrel): Delete forward decls. 124633 opcodes/ 124634 * bpf-desc.c, * bpf-dis.c, * cris-desc.c, 124635 * epiphany-desc.c, * epiphany-dis.c, 124636 * fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c, 124637 * ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c, 124638 * lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c, 124639 * m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c, 124640 * mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c, 124641 * xc16x-desc.c, * xc16x-dis.c, 124642 * xstormy16-desc.c, * xstormy16-dis.c: Regenerate. 124643 1246442022-05-11 GDB Administrator <gdbadmin@sourceware.org> 124645 124646 Automatic date update in version.in 124647 1246482022-05-10 Youling Tang <tangyouling@loongson.cn> 124649 124650 gdb: mips: Fix large-frame.exp test case failure 124651 $ objdump -d outputs/gdb.base/large-frame/large-frame-O2 124652 0000000120000b20 <func>: 124653 120000b20: 67bdbff0 daddiu sp,sp,-16400 124654 120000b24: ffbc4000 sd gp,16384(sp) 124655 120000b28: 3c1c0002 lui gp,0x2 124656 120000b2c: 679c8210 daddiu gp,gp,-32240 124657 120000b30: 0399e02d daddu gp,gp,t9 124658 120000b34: df998058 ld t9,-32680(gp) 124659 120000b38: ffbf4008 sd ra,16392(sp) 124660 120000b3c: 0411ffd8 bal 120000aa0 <blah> 124661 ... 124662 124663 The disassembly of the above func function shows that we may use 124664 instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n", 124665 "daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue 124666 function to fix the large-frame.exp test case. 124667 124668 Before applying the patch: 124669 124670 backtrace 124671 #0 blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24 124672 #1 0x0000000120000b44 in func () 124673 Backtrace stopped: frame did not save the PC 124674 (gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace 124675 124676 # of expected passes 5 124677 # of unexpected failures 1 124678 124679 After applying the patch: 124680 124681 # of expected passes 6 124682 1246832022-05-10 Tiezhu Yang <yangtiezhu@loongson.cn> 124684 124685 gdb: LoongArch: Use GDB style to check readbuf and writebuf 124686 The GDB style is to write 'if (readbuf != nullptr)', and the same for 124687 writebuf. 124688 1246892022-05-10 Tom Tromey <tromey@adacore.com> 124690 124691 Fix --disable-threading build 124692 PR build/29110 points out that GDB fails to build on mingw when the 124693 "win32" thread model is in use. It turns out that the Fedora cross 124694 tools using the "posix" thread model, which somehow manages to support 124695 std::future, whereas the win32 model does not. 124696 124697 While looking into this, I found that the configuring with 124698 --disable-threading will also cause a build failure. 124699 124700 This patch fixes this build by introducing a compatibility wrapper for 124701 std::future. 124702 124703 I am not able to test the win32 thread model build, but I'm going to 124704 ask the reporter to try this patch. 124705 124706 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110 124707 1247082022-05-10 Pedro Alves <pedro@palves.net> 124709 124710 Fix "b f(std::string)" when current language is C 124711 If you try to set a breakpoint at a function such as "b 124712 f(std::string)", and the current language is C, the breakpoint fails 124713 to be set, like so: 124714 124715 (gdb) set language c 124716 break f(std::string) 124717 Function "f(std::string)" not defined. 124718 Make breakpoint pending on future shared library load? (y or [n]) n 124719 (gdb) 124720 124721 The problem is that the code in GDB that expands the std::string 124722 typedef hits this in c-typeprint.c: 124723 124724 /* If we have "typedef struct foo {. . .} bar;" do we want to 124725 print it as "struct foo" or as "bar"? Pick the latter for 124726 C++, because C++ folk tend to expect things like "class5 124727 *foo" rather than "struct class5 *foo". We rather 124728 arbitrarily choose to make language_minimal work in a C-like 124729 way. */ 124730 if (language == language_c || language == language_minimal) 124731 { 124732 if (type->code () == TYPE_CODE_UNION) 124733 gdb_printf (stream, "union "); 124734 else if (type->code () == TYPE_CODE_STRUCT) 124735 { 124736 if (type->is_declared_class ()) 124737 gdb_printf (stream, "class "); 124738 else 124739 gdb_printf (stream, "struct "); 124740 } 124741 else if (type->code () == TYPE_CODE_ENUM) 124742 gdb_printf (stream, "enum "); 124743 } 124744 124745 I.e., std::string is expanded to "class std::..." instead of just 124746 "std::...", and then the "f(class std::..." symbol doesn't exist. 124747 124748 Fix this by making cp-support.c:inspect_type print the expanded 124749 typedef type using the language of the symbol whose type we're 124750 expanding the typedefs for -- in the example in question, the 124751 "std::string" typedef symbol, which is a C++ symbol. 124752 124753 Use type_print_raw_options as it seems to me that in this scenario we 124754 always want raw types, to match the real symbol names. 124755 124756 Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a 124757 breakpoint at "f(std::string)" in both C and C++. 124758 124759 Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b 124760 1247612022-05-10 Pedro Alves <pedro@palves.net> 124762 124763 Always pass an explicit language down to c_type_print 124764 The next patch will want to do language->print_type(type, ...), to 124765 print a type in a given language, avoiding a dependency on the current 124766 language. That doesn't work correctly currently, however, because 124767 most language implementations of language_defn::print_type call 124768 c_print_type without passing down the language. There are two 124769 overloads of c_print_type, one that takes a language, and one that 124770 does not. The one that does not uses the current language, defeating 124771 the point of calling language->print_type()... 124772 124773 This commit removes the c_print_type overload that does not take a 124774 language, and adjusts the codebase throughout to always pass down a 124775 language. In most places, there's already an enum language handy. 124776 language_defn::print_type implementations naturally pass down 124777 this->la_language. In a couple spots, like in ada-typeprint.c and 124778 rust-lang.c there's no enum language handy, but the code is written 124779 for a specific language, so we just hardcode the language. 124780 124781 In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++ 124782 here, and we don't have an enum language handy, so I made it use the 124783 current language, just like today. Can always be improved later. 124784 124785 Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b 124786 1247872022-05-10 Pedro Alves <pedro@palves.net> 124788 124789 Fix "b f(std::string)", always use DMGL_VERBOSE 124790 Currently, on any remotely modern GNU/Linux system, 124791 gdb.cp/no-dmgl-verbose.exp fails like so: 124792 124793 break 'f(std::string)' 124794 Function "f(std::string)" not defined. 124795 (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)' 124796 break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)' 124797 Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined. 124798 (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined 124799 124800 This testcase was added back in 2011, here: 124801 124802 [patch] Remove DMGL_VERBOSE 124803 https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html 124804 124805 Back then, the testcase would pass cleanly. It turns out that the 124806 reason it fails today is that the testcase is exercising something in 124807 GDB that only makes sense if the program is built for the pre-C++11 124808 libstc++ ABI. Back then the C++11 ABI didn't exist yet, but nowadays, 124809 you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old 124810 ABI. See "Dual ABI" in the libstdc++ manual, at 124811 <https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>. 124812 124813 If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old 124814 ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly. 124815 124816 So why is it that setting a breakpoint at "f(std::string)" fails with 124817 modern ABI, but passes with old ABI? 124818 124819 This is where libiberty demangler's DMGL_VERBOSE option comes in. The 124820 Itanium ABI mangling scheme has a shorthand form for std::string (and 124821 some other types). See 124822 <https://itanium-cxx-abi.github.io/cxx-abi/abi.html>: 124823 124824 "In addition, the following catalog of abbreviations of the form "Sx" are used: 124825 124826 <substitution> ::= St # ::std:: 124827 <substitution> ::= Sa # ::std::allocator 124828 <substitution> ::= Sb # ::std::basic_string 124829 <substitution> ::= Ss # ::std::basic_string < char, 124830 ::std::char_traits<char>, 124831 ::std::allocator<char> > 124832 <substitution> ::= Si # ::std::basic_istream<char, std::char_traits<char> > 124833 <substitution> ::= So # ::std::basic_ostream<char, std::char_traits<char> > 124834 <substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> > 124835 " 124836 124837 When the libiberty demangler encounters such a abbreviation, by 124838 default, it expands it to the user-friendly typedef "std::string", 124839 "std::iostream", etc.. If OTOH DMGL_VERBOSE is specified, the 124840 abbreviation is expanded to the underlying, non-typedefed fullname 124841 "std::basic_string<char, std::char_traits<char>, std::allocator<char> >" 124842 etc. as documented in the Itanium ABI, and pasted above. You can see 124843 the standard abbreviations/substitutions in 124844 libiberty/cp-demangle.c:standard_subs. 124845 124846 Back before Jan's patch in 2011, there were parts of GDB that used 124847 DMGL_VERBOSE, and others that did not, leading to mismatches. The 124848 solution back then was to stop using DMGL_VERBOSE throughout. 124849 124850 GDB has code in place to let users set a breakpoint at a function with 124851 typedefs in its parameters, like "b f(uint32_t)". Demangled function 124852 names as they appear in the symbol tables almost (more on this is in a 124853 bit) never have typedefs in them, so when processing "b f(uint32_t)" 124854 GDB first replaces "uint32_t" for its underlying type, and then sets a 124855 breakpoint on the resulting prototype, in this case "f(unsigned int)". 124856 124857 Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the 124858 mangled name of a function such as "void f(std::string)" that was 124859 mangled using the standard abbreviations mentioned above really as: 124860 124861 "void f(std::string)". 124862 124863 For example, the mangled name of "void f(std::string)" if you compile 124864 with old pre-C++11 ABI is "_Z1fSs". That uses the abbreviation "Ss", 124865 so if you demangle that without DMGL_VERBOSE, you get: 124866 124867 $ echo "_Z1fSs" | c++filt --no-verbose 124868 f(std::string) 124869 124870 while with DMGL_VERBOSE you'd get: 124871 124872 $ echo "_Z1fSs" | c++filt 124873 f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >) 124874 124875 If, when the user sets a breakpoint at "f(std::string)", GDB would 124876 replace the std::string typedef for its underlying type using the same 124877 mechanism I mentioned for the "f(uint32_t)" example above, then GDB 124878 would really try to set a breakpoint at "f(std::basic_string<char, 124879 std::char_traits<char>, std::allocator<char> >)", and that would fail, 124880 as the function symbol GDB knows about for that function, given no 124881 DMGL_VERBOSE, is "f(std::string)". 124882 124883 For this reason, the code that expands typedefs in function parameter 124884 names has an exception for std::string (and other standard 124885 abbreviation types), such that "std::string" is never 124886 typedef-expanded. 124887 124888 And here lies the problem when you try to do "b f(std::string)" with a 124889 program compiled with the C++11 ABI. In that case, std::string 124890 expands to a different underlying type, like so: 124891 124892 f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) 124893 124894 and this symbol naturally mangles differently, as: 124895 124896 _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 124897 124898 and then because this doesn't use the shorthand mangling abbreviation 124899 for "std::string" anymore, it always demangles as: 124900 124901 f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) 124902 124903 Now, when using the C++11 ABI, and you set a breakpoint at 124904 "f(std::string)", GDB's typedefs-in-parameters expansion code hits the 124905 exception for "std::string" and doesn't expand it, so the breakpoint 124906 fails to be inserted, because the symbol that exists is really the 124907 124908 f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) 124909 124910 one, not "f(std::string)". 124911 124912 So to fix things for C++11 ABI, clearly we need to remove the 124913 "std::string" exception from the typedef-in-parameters expansion 124914 logic. If we do just that, then "b f(std::string)" starts working 124915 with the C++11 ABI. 124916 124917 However, if we do _just_ that, and nothing else, then we break 124918 pre-C++11 ABI... 124919 124920 The solution is then to in addition switch GDB to always use 124921 DMGL_VERBOSE. If we do this, then pre-C++11 ABI symbols works the 124922 same as C++11 ABI symbols overall -- the demangler expands the 124923 standard abbreviation for "std::string" as "std::basic_string<char, 124924 std::char_traits<char>, std::allocator<char> >" and letting GDB expand 124925 the "std::string" typedef (etc.) too is no longer a problem. 124926 124927 To avoid getting in the situation where some parts of GDB use 124928 DMGL_VERBOSE and others not, this patch adds wrappers around the 124929 demangler's entry points that GDB uses, and makes those force 124930 DMGL_VERBOSE. 124931 124932 The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to 124933 ensure that DMGL_VERBOSE doesn't creep back in: 124934 124935 gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \ 124936 {Function ".*" not defined\.} \ 124937 "DMGL_VERBOSE-demangled f(std::string) is not defined" 124938 124939 This obviously no longer makes sense to have, since we now depend on 124940 DMGL_VERBOSE. So the patch replaces gdb.cp/no-dmgl-verbose.exp with a 124941 new gdb.cp/break-f-std-string.exp testcase whose purpose is to make 124942 sure that setting a breakpoint at "f(std::string)" works. It 124943 exercises both pre-C++11 ABI and C++11 ABI. 124944 124945 Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b 124946 1249472022-05-10 Nils-Christian Kempke <nils-christian.kempke@intel.com> 124948 124949 gdb/testsuite: fix testsuite regressions for unix/-m32 board 124950 This commit fixes two regressions introduced by 124951 891e4190ba705373eec7b374209478215fff5401. 124952 124953 Reason for the failures was, that on a 32 bit machine the maximum 124954 array length as well as the maximum allocatable memory for arrays 124955 (in bytes) both seem to be limited by the maximum value of a 4 124956 byte (signed) Fortran integer. This lead to compiler errors/unexpected 124957 behavior when compiling/running the test with the -m32 board. This 124958 behavior is compiler dependent and can differ for different compiler 124959 implementations, but generally, it seemed like a good idea to simply 124960 avoid such situations. 124961 124962 The affected tests check for GDB's overflow behavior when using KIND 124963 parameters with GDB implemented Fortran intrinsic functions. If these 124964 KIND parameters are too small to fit the actual intrinsic function's 124965 result, an overflow is expected. This was done for 1, 2, and 4 124966 byte overflows. The last one caused problems, as it tried to allocate 124967 arrays of length/byte-size bigger than the 4 byte signed integers which 124968 would then be used with the LBOUND/UBOUND/SIZE intrinsics. 124969 124970 The tests were adapted to only execute the 4 byte overflow tests when 124971 running on targets with 64 bit. For this, the compiled tests evaluate the 124972 byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING 124973 module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the 124974 C_SIZEOF a Fortran 2008 extension. Both have been implemented in their 124975 respective compilers for while (e.g. C_SIZEOF is available since 124976 gfortran 4.6). If this byte size evaluates to less than 8 we skip the 124977 4 byte overflow tests in the compiled tests of size.f90 and 124978 lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we skip 124979 the 4 byte overflow tests if the procedure is_64_target evaluates to false. 124980 124981 In size.f90, additionally, the to-be-allocated amount of bytes did not 124982 fit into 4 byte signed integers for some of the arrays, as it was 124983 approximately 4 times the maximum size of a 4 byte signed integer. We 124984 adapted the dimensions of the arrays in question as the meaningfulness 124985 of the test does not suffer from this. 124986 124987 With this patch both test run fine with the unix/-m32 board and 124988 gcc/gfortran (9.4) as well as the standard board file. 124989 124990 We also thought about completely removing the affected test from the 124991 testsuite. We decided against this as the 32 bit identification comes 124992 with Fortran 2008 and removing tests would have decreased coverage. 124993 124994 A last change that happened with this patch was due to gfortran's and 124995 ifx's type resolution when assigning big constants to Fortran Integer*8 124996 variables. Before the above changes this happened in a parameter 124997 statement. Here, both compilers happily accepted a line like 124998 124999 integer*8, parameter :: var = 2147483647 + 5. 125000 125001 After this change the assignment is not done as a parameter 125002 anymore, as this triggered compile time overflow errors. Instead, 125003 the assignment is done dynamically, depending on the kind of machine one 125004 is on. Sadly, just changing this line to 125005 125006 integer*8 :: var 125007 var = 2147483647 + 5 125008 125009 does not work with ifx (or flang for that matter, they behave similarly 125010 here). It will create an integer overflow in the addition as ifx deduces 125011 the type the additon is done in as Integer*4. So var will actually 125012 contain the value -2147483644 after this. The lines 125013 125014 integer*8 :: var 125015 var = 2147483652 125016 125017 on the other hand fail to compile with gfortran (9.4.0) as the compiler 125018 identifies an Integer overflow here. Finally, to make this work with 125019 all three compilers an additional parameter has been introduced 125020 125021 integer*8, parameter :: helper = 2147483647 125022 integer*8 :: var 125023 var = helper + 5. 125024 125025 This works on all 3 compilers as expected. 125026 125027 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053 125028 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054 125029 1250302022-05-10 Pedro Alves <pedro@palves.net> 125031 125032 Move non-dependent gdb::observers::observable::visit_state outside template 125033 The other day, while looking at the symbols that end up in a GDB 125034 index, I noticed that the gdb::observers::observable::visit_state enum 125035 class appears a number of times: 125036 125037 $ grep VISIT gdb-index-symbol-names.txt 125038 gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED 125039 gdb::observers::observable<bpstat*, int>::visit_state::VISITED 125040 gdb::observers::observable<bpstat*, int>::visit_state::VISITING 125041 gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED 125042 gdb::observers::observable<breakpoint*>::visit_state::VISITED 125043 gdb::observers::observable<breakpoint*>::visit_state::VISITING 125044 gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED 125045 gdb::observers::observable<char const*, char const*>::visit_state::VISITED 125046 gdb::observers::observable<char const*, char const*>::visit_state::VISITING 125047 gdb::observers::observable<char const*>::visit_state::NOT_VISITED 125048 gdb::observers::observable<char const*>::visit_state::VISITED 125049 gdb::observers::observable<char const*>::visit_state::VISITING 125050 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED 125051 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED 125052 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING 125053 gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED 125054 gdb::observers::observable<frame_info*, int>::visit_state::VISITED 125055 gdb::observers::observable<frame_info*, int>::visit_state::VISITING 125056 gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED 125057 gdb::observers::observable<gdbarch*>::visit_state::VISITED 125058 gdb::observers::observable<gdbarch*>::visit_state::VISITING 125059 gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED 125060 gdb::observers::observable<gdb_signal>::visit_state::VISITED 125061 gdb::observers::observable<gdb_signal>::visit_state::VISITING 125062 [... snip ...] 125063 125064 $ grep VISIT gdb-index-symbol-names.txt | wc -l 125065 72 125066 125067 enum class visit_state is defined inside the class template 125068 observable, but it doesn't have to be, as it does not depend on the 125069 template parameters. This commit moves it out, so that only one such 125070 type exists. This reduces the size of a -O0 -g3 build for me by 125071 around 0.6%, like so: 125072 125073 $ du -b gdb.before gdb.after 125074 164685280 gdb.before 125075 163707424 gdb.fixed 125076 125077 and codesize by some 0.5%. 125078 125079 Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e 125080 1250812022-05-10 Nick Clifton <nickc@redhat.com> 125082 125083 Fix compiling binutils/resbin.c with Clang version 14 125084 1250852022-05-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 125086 125087 gprofng: include percentages in default metrics list 125088 gprofng/ChangeLog 125089 2022-05-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 125090 125091 * src/gprofng.rc: Include percentages in default metrics list. 125092 1250932022-05-10 Alan Modra <amodra@gmail.com> 125094 125095 gprof: remove use of PTR 125096 * basic_blocks.c: Replace uses of PTR with void * throughout. 125097 * cg_arcs.c: Likewise. 125098 * cg_print.c: Likewise. 125099 * hist.c: Likewise. 125100 * source.h: Likewise. 125101 * symtab.c: Likewise. 125102 125103 gas: remove use of PTR 125104 * config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR. 125105 1251062022-05-10 Alan Modra <amodra@gmail.com> 125107 125108 opcodes: remove use of PTR 125109 The non-cgen parts of opcodes. 125110 125111 * cr16-dis.c (print_arg): Replace PTR with void *. 125112 * crx-dis.c (print_arg): Likewise. 125113 * rl78-dis.c (print_insn_rl78_common): Don't use PTR cast. 125114 * rx-dis.c (print_insn_rx): Likewise. 125115 * visium-dis.c (print_insn_visium): Likewise. 125116 * z8k-dis.c (print_insn_z8k): Likewise. 125117 1251182022-05-10 Alan Modra <amodra@gmail.com> 125119 125120 bfd: remove use of PTR 125121 * coffcode.h (coff_write_object_contents): Don't cast to PTR. 125122 * elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR 125123 and PARAMS. 125124 (csky_allocate_dynrelocs): Don't use PTR cast. 125125 * elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace 125126 PTR with void *. 125127 * elf32-visium.c (visium_elf_howto_parity_reloc): Likewise. 125128 * elfxx-ia64.c (ia64_elf_reloc): Likewise. 125129 * plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise. 125130 125131 include: remove use of PTR 125132 * hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *. 125133 (HTAB_DELETED_ENTRY): Likewise. 125134 1251352022-05-10 GDB Administrator <gdbadmin@sourceware.org> 125136 125137 Automatic date update in version.in 125138 1251392022-05-09 Ilya Leoshkevich <iii@linux.ibm.com> 125140 125141 IBM zSystems: Accept (. - 0x100000000) PCRel32 operands 125142 as does not accept instructions like brasl %r0,.-0x100000000, because 125143 of two problems with the generic overflow check: 125144 125145 1. PCRel32 operands are signed, but are treated as unsigned. 125146 125147 2. The allowed range for these operands is [-(1 << 32), (1 << 32) - 1], 125148 and not [-(1 << 31), (1 << 31) - 1]. 125149 125150 Fix both by disabling the generic overflow check - it's not needed, 125151 because s390_insert_operand () performs its own. 125152 125153 gas/ 125154 125155 * config/tc-s390.c (md_gather_operands): Set fx_no_overflow. 125156 * testsuite/gas/s390/s390.exp: Add zarch-z900-err. 125157 * testsuite/gas/s390/esa-z900.d: New test. 125158 * testsuite/gas/s390/esa-z900.s: New test. 125159 * testsuite/gas/s390/zarch-z900-err.l: New test. 125160 * testsuite/gas/s390/zarch-z900-err.s: New test. 125161 1251622022-05-09 Andrew Burgess <aburgess@redhat.com> 125163 125164 gdb/testsuite: fix occasional failure in gdb.mi/mi-multi-commands.exp 125165 In bug PR gdb/29036, another failure was reported for the test 125166 gdb.mi/mi-multi-commands.exp. This test sends two commands to GDB as 125167 a single write, and then checks that both commands are executed. 125168 125169 The problem that was encountered here is that the output of the first 125170 command, which looks like this: 125171 125172 ^done,value="\"FIRST COMMAND\"" 125173 125174 Is actually produced in parts, first the '^done' is printed, then the 125175 ',value="\"FIRST COMMAND\"" is printed. 125176 125177 What was happening is that some characters from the second command 125178 were being echoed after the '^done' had been printed, but before the 125179 value part had been printed. To avoid this issue I've relaxed the 125180 pattern that checks for the first command a little. With this fix in 125181 place the occasional failure in this test is no longer showing up. 125182 125183 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29036 125184 1251852022-05-09 Tom de Vries <tdevries@suse.de> 125186 125187 [gdb] Update syscalls/{amd64,i386}-linux.xml 125188 - Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py. 125189 - Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and 125190 update-netbsd.sh). 125191 - Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in. 125192 - Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile. 125193 125194 In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect: 125195 ... 125196 - <syscall name="madvise1" number="220"/> 125197 - <syscall name="getdents64" number="221"/> 125198 - <syscall name="fcntl64" number="222"/> 125199 + <syscall name="getdents64" number="220"/> 125200 + <syscall name="fcntl64" number="221"/> 125201 ... 125202 125203 I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are 125204 correct. 125205 125206 Tested on x86_64-linux. 125207 1252082022-05-09 Tom de Vries <tdevries@suse.de> 125209 125210 [gdb] Add gdb/syscalls/Makefile 125211 Add a Makefile in gdb/syscalls that can be used to translate 125212 gdb/syscalls/*.xml.in into gdb/syscalls/*.xml. 125213 125214 Calling make reveals that bfin-linux.xml is missing, so add it. 125215 125216 Tested on x86_64-linux. 125217 1252182022-05-09 Tiezhu Yang <yangtiezhu@loongson.cn> 125219 125220 gdb: LoongArch: Implement the return_value gdbarch method 125221 When execute the following command on LoongArch: 125222 125223 make check-gdb TESTS="gdb.base/async.exp" 125224 125225 there exist the following failed testcases: 125226 125227 FAIL: gdb.base/async.exp: finish& (timeout) 125228 FAIL: gdb.base/async.exp: jump& (timeout) 125229 FAIL: gdb.base/async.exp: until& (timeout) 125230 FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error) 125231 125232 we can see the following messages in gdb/testsuite/gdb.log: 125233 125234 finish& 125235 Run till exit from #0 foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9 125236 (gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed. 125237 A problem internal to GDB has been detected, 125238 further debugging may prove unreliable. 125239 125240 In order to fix the above failed testcases, implement the return_value 125241 gdbarch method on LoongArch. 125242 1252432022-05-09 Andrew Burgess <aburgess@redhat.com> 125244 125245 gdb: fix for gdb.base/eof-exit.exp test failures 125246 This fix relates to PR gdb/29032, this makes the test more stable by 125247 ensuring that the Ctrl-D is only sent once the prompt has been 125248 displayed. This issue was also discussed on the mailing list here: 125249 125250 https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html 125251 125252 The problem identified in the bug report is that sometimes the Ctrl-D 125253 (that the test sends to GDB) arrives while GDB is processing a 125254 command. When this happens the Ctrl-D is handled differently than if 125255 the Ctrl-D is sent while GDB is waiting for input at a prompt. 125256 125257 The original intent of the test was that the Ctrl-D be sent while GDB 125258 was waiting at a prompt, and that is the case the occurs most often, 125259 but, when the Ctrl-D arrives during command processing, then GDB will 125260 ignore the Ctrl-D, and the test will fail. 125261 125262 This commit ensures the Ctrl-D is always sent while GDB is waiting at 125263 a prompt, which makes this test stable. 125264 125265 But, that still leaves an open question, what should happen when the 125266 Ctrl-D arrives while GDB is processing a command? This commit doesn't 125267 attempt to answer that question, which is while bug PR gdb/29032 will 125268 not be closed once this commit is merged. 125269 125270 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032 125271 1252722022-05-09 Tom de Vries <tdevries@suse.de> 125273 125274 [gdb] Make btrace maintainer entry more clear 125275 Do: 125276 ... 125277 -record btrace <name> <email> 125278 +record 125279 + btrace <name> <email> 125280 ... 125281 to clarify that the listed maintainer is only maintainer of the btrace part of 125282 record. 125283 1252842022-05-09 Martin Liska <mliska@suse.cz> 125285 125286 ansidecl.h: sync from GCC 125287 include/ChangeLog: 125288 125289 * ansidecl.h: Sync from GCC. 125290 1252912022-05-09 Tom de Vries <tdevries@suse.de> 125292 125293 [gdb/tdep] Support catch syscall pipe2 for i386 125294 With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run 125295 into: 125296 ... 125297 (gdb) catch syscall pipe2^M 125298 Unknown syscall name 'pipe2'.^M 125299 (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2 125300 ... 125301 125302 Fix this by: 125303 - adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and 125304 - regenerating gdb/syscalls/i386-linux.xml using 125305 "xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in". 125306 125307 Tested on x86_64-linux with native and unix/-m32. 125308 125309 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056 125310 1253112022-05-09 Tom de Vries <tdevries@suse.de> 125312 125313 [gdb/testsuite] Handle pipe2 syscall in gdb.base/catch-syscall.exp 125314 When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed, 125315 I run into: 125316 ... 125317 (gdb) continue^M 125318 Continuing.^M 125319 ^M 125320 Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M 125321 (gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \ 125322 syscall pipe has returned 125323 ... 125324 125325 The current glibc on Tumbleweed is 2.35, which contains commit 125326 "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2 125327 is used instead of syscall pipe. 125328 125329 Fix this by detecting whether syscall pipe or pipe2 is used before running the 125330 tests. 125331 125332 Tested on x86_64-linux, specifically on: 125333 - openSUSE Tumbleweed (with glibc 2.35), and 125334 - openSUSE Leap 15.3 (with glibc 2.31). 125335 125336 On openSUSE Tumbleweed + target board unix/-m32, this exposes: 125337 ... 125338 (gdb) catch syscall pipe2^M 125339 Unknown syscall name 'pipe2'.^M 125340 ... 125341 which will be fixed in a folllow-up patch. 125342 125343 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056 125344 1253452022-05-09 Tom de Vries <tdevries@suse.de> 125346 125347 [gdb/tdep] Handle pipe2 syscall for amd64 125348 When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed, 125349 I run into: 125350 ... 125351 (gdb) continue^M 125352 Continuing.^M 125353 Process record and replay target doesn't support syscall number 293^M 125354 Process record: failed to record execution log.^M 125355 ^M 125356 Program stopped.^M 125357 0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M 125358 (gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2 125359 ... 125360 125361 The current glibc on Tumbleweed is 2.35, which contains commit 125362 "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2 125363 is used in stead of syscall pipe. 125364 125365 There is already support added for syscall pipe2 for aarch64 (which only has 125366 syscall pipe2, not syscall pipe), so enable the same for amd64, by: 125367 - adding amd64_sys_pipe2 in enum amd64_syscall 125368 - translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall 125369 125370 Tested on x86_64-linux, specifically on: 125371 - openSUSE Tumbleweed (with glibc 2.35), and 125372 - openSUSE Leap 15.3 (with glibc 2.31). 125373 125374 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056 125375 1253762022-05-09 GDB Administrator <gdbadmin@sourceware.org> 125377 125378 Automatic date update in version.in 125379 1253802022-05-08 Tom de Vries <tdevries@suse.de> 125381 125382 [gdb/testsuite] Fix gdb.tui/scroll.exp with read1 125383 When running test-case gdb.tui/scroll.exp, I get: 125384 ... 125385 Box Dump (80 x 8) @ (0, 0): 125386 0 $17 = 16 125387 1 (gdb) p 17 125388 2 $18 = 17 125389 3 (gdb) p 18 125390 4 $19 = 18 125391 5 (gdb) p 19 125392 6 $20 = 19 125393 7 (gdb) 125394 PASS: gdb.tui/scroll.exp: check cmd window in flip layout 125395 ... 125396 but with check-read1 I get instead: 125397 ... 125398 Box Dump (80 x 8) @ (0, 0): 125399 0 (gdb) 15 125400 1 (gdb) p 16 125401 2 $17 = 16 125402 3 (gdb) p 17 125403 4 $18 = 17 125404 5 (gdb) p 18 125405 6 $19 = 18 125406 7 (gdb) p 19 125407 FAIL: gdb.tui/scroll.exp: check cmd window in flip layout 125408 ... 125409 125410 The "p 19" command is handled by Term::command, which sends the command and then 125411 does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which: 125412 - matches the line with "(gdb) p 19", and 125413 - tries to match the following prompt "(gdb) " 125414 125415 The problem is that scrolling results in reissuing output before the "(gdb) p 125416 19", and the second matching triggers on that. Consequently, wait_for no 125417 longer translates gdb output into screen actions, and the screen does not 125418 reflect the result of "p 19". 125419 125420 Fix this by using a new proc wait_for_region_contents, which in contrast to 125421 wait_for can handle a multi-line regexp. 125422 125423 Tested on x86_64-linux with make targets check and check-read1. 125424 1254252022-05-08 Tom de Vries <tdevries@suse.de> 125426 125427 [gdb/testsuite] Fix gdb.cp/casts.exp with -m32 125428 When running test-case gdb.cp/casts.exp with target board unix/-m32, I run 125429 into: 125430 ... 125431 (gdb) print (unsigned long long) &gd == gd_value^M 125432 $31 = false^M 125433 (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value 125434 ... 125435 125436 With some additional printing, we can see in more detail why the comparison 125437 fails: 125438 ... 125439 (gdb) print /x &gd^M 125440 $31 = 0xffffc5c8^M 125441 (gdb) PASS: gdb.cp/casts.exp: print /x &gd 125442 print /x (unsigned long long)&gd^M 125443 $32 = 0xffffc5c8^M 125444 (gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd 125445 print /x gd_value^M 125446 $33 = 0xffffffffffffc5c8^M 125447 (gdb) PASS: gdb.cp/casts.exp: print /x gd_value 125448 print (unsigned long long) &gd == gd_value^M 125449 $34 = false^M 125450 (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value 125451 ... 125452 125453 The gd_value is set by this assignment: 125454 ... 125455 unsigned long long gd_value = (unsigned long long) &gd; 125456 ... 125457 125458 The problem here is directly casting from a pointer to a non-pointer-sized 125459 integer. 125460 125461 Fix this by adding an intermediate cast to std::uintptr_t. 125462 125463 Tested on x86_64-linux with native and target board unix/-m32. 125464 1254652022-05-08 Tom de Vries <tdevries@suse.de> 125466 125467 [gdb/testsuite] Handle init errors in gdb.mi/user-selected-context-sync.exp 125468 In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into: 125469 ... 125470 (gdb) builtin_spawn -pty^M 125471 new-ui mi /dev/pts/5^M 125472 New UI allocated^M 125473 (gdb) =thread-group-added,id="i1"^M 125474 (gdb) ERROR: MI channel failed 125475 warning: Error detected on fd 11^M 125476 thread 1.1^M 125477 Unknown thread 1.1.^M 125478 (gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \ 125479 test_cli_inferior: reset selection to thread 1.1 125480 ... 125481 with many more UNRESOLVED following. 125482 125483 The ERROR is a common problem, filed as 125484 https://sourceware.org/bugzilla/show_bug.cgi?id=28561 . 125485 125486 But the many UNRESOLVEDs are due to not checking whether the setup as done in 125487 the test_setup function succeeds or not. 125488 125489 Fix this by: 125490 - making test_setup return an error upon failure 125491 - handling test_setup error at the call site 125492 - adding a "setup done" pass/fail to be turned into an unresolved 125493 in case of error during setup. 125494 125495 Tested on x86_64-linux, by manually triggering the error in 125496 mi_gdb_start_separate_mi_tty. 125497 1254982022-05-08 Tom de Vries <tdevries@suse.de> 125499 125500 [gdb/testsuite] Fix gdb.ada/catch_ex_std.exp with remote-gdbserver-on-localhost 125501 When running test-case gdb.ada/catch_ex_std.exp on target board 125502 remote-gdbserver-on-localhost, I run into: 125503 ... 125504 (gdb) continue^M 125505 Continuing.^M 125506 [Inferior 1 (process 15656) exited with code 0177]^M 125507 (gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main 125508 Remote debugging from host ::1, port 49780^M 125509 /home/vries/foo: error while loading shared libraries: libsome_package.so: \ 125510 cannot open shared object file: No such file or directory^M 125511 ... 125512 125513 Fix this by adding the usual shared-library + remote-target helper 125514 "gdb_load_shlib $sofile". 125515 125516 Tested on x86_64-linux with native and target board 125517 remote-gdbserver-on-localhost. 125518 1255192022-05-08 Tom de Vries <tdevries@suse.de> 125520 125521 [gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with check-readmore 125522 When running test-case gdb.threads/fork-plus-threads.exp with check-readmore, 125523 I run into: 125524 ... 125525 [Inferior 11 (process 7029) exited normally]^M 125526 [Inferior 1 (process 6956) exited normally]^M 125527 FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \ 125528 inferior 1 exited (timeout) 125529 ... 125530 125531 The problem is that the regexp consuming the "Inferior exited normally" 125532 messages: 125533 - consumes more than one of those messages at a time, but 125534 - counts only one of those messages. 125535 125536 Fix this by adopting a line-by-line approach, which deals with those messages 125537 one at a time. 125538 125539 Tested on x86_64-linux with native, check-read1 and check-readmore. 125540 1255412022-05-08 GDB Administrator <gdbadmin@sourceware.org> 125542 125543 Automatic date update in version.in 125544 1255452022-05-07 Tom Tromey <tom@tromey.com> 125546 125547 Fix "catch syscall" 125548 Simon pointed out that some recent patches of mine broke "catch 125549 syscall". Apparently I forgot to finish the conversion of this code 125550 when removing init_catchpoint. This patch completes the conversion 125551 and fixes the bug. 125552 1255532022-05-07 Andrew Burgess <aburgess@redhat.com> 125554 125555 gdb/readline: fix extra 'quit' message problem 125556 After these two commits: 125557 125558 commit 4fb7bc4b147fd30b781ea2dad533956d0362295a 125559 Date: Mon Mar 7 13:49:21 2022 +0000 125560 125561 readline: back-port changes needed to properly detect EOF 125562 125563 commit 91395d97d905c31ac38513e4aaedecb3b25e818f 125564 Date: Tue Feb 15 17:28:03 2022 +0000 125565 125566 gdb: handle bracketed-paste-mode and EOF correctly 125567 125568 It was observed that, if a previous command is selected at the 125569 readline prompt using the up arrow key, then when the command is 125570 accepted (by pressing return) an unexpected 'quit' message will be 125571 printed by GDB. Here's an example session: 125572 125573 (gdb) p 123 125574 $1 = 123 125575 (gdb) p 123 125576 quit 125577 $2 = 123 125578 (gdb) 125579 125580 In this session the second 'p 123' was entered not by typing 'p 123', 125581 but by pressing the up arrow key to select the previous command. It 125582 is important that the up arrow key is used, typing Ctrl-p will not 125583 trigger the bug. 125584 125585 The problem here appears to be readline's EOF detection when handling 125586 multi-character input sequences. I have raised this issue on the 125587 readline mailing list here: 125588 125589 https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html 125590 125591 a solution has been proposed here: 125592 125593 https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html 125594 125595 This patch includes a test for this issue as well as a back-port of 125596 (the important bits of) readline commit: 125597 125598 commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1 125599 Date: Wed May 4 11:18:04 2022 -0400 125600 125601 fix for setting RL_STATE_EOF in callback mode 125602 125603 That commit also includes some updates to the readline documentation 125604 and tests that I have not included in this commit. 125605 125606 With this commit in place the unexpected 'quit' messages are resolved. 125607 1256082022-05-07 Alan Modra <amodra@gmail.com> 125609 125610 Fix multiple ubsan warnings in i386-dis.c 125611 Commit 39fb369834a3 "opcodes: Make i386-dis.c thread-safe" introduced 125612 a number of casts to bfd_signed_vma that cause undefined behaviour 125613 with a 32-bit libbfd. Revert those changes. 125614 125615 * i386-dis.c (OP_E_memory): Do not cast disp to bfd_signed_vma 125616 for negation. 125617 (get32, get32s): Don't use bfd_signed_vma here. 125618 1256192022-05-07 Alan Modra <amodra@gmail.com> 125620 125621 Re: Fix new linker testsuite failures due to rwx segment test problems 125622 Fix it some more. 125623 125624 bfd/ 125625 * elfnn-loongarch.c: Remove commented out elf_backend_* defines. 125626 ld/ 125627 * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Match 125628 arm*. Delete loongarch. 125629 1256302022-05-07 GDB Administrator <gdbadmin@sourceware.org> 125631 125632 Automatic date update in version.in 125633 1256342022-05-07 Carl Love <cel@us.ibm.com> 125635 125636 PowerPC fix for gdb.server/sysroot.exp 125637 On PowerPC, the stop in the printf function is of the form: 125638 125639 Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6 125640 125641 On other architectures the output looks like: 125642 125643 Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6 125644 125645 The following patch modifies the printf test by matchine any character 125646 starting immediately after the printf. The test now works for PowerPC 125647 output as well as the output from other architectures. 125648 125649 The test has been run on a Power 10 system and and Intel x86_64 system. 125650 1256512022-05-06 Nick Clifton <nickc@redhat.com> 125652 125653 Fix new linker testsuite failures due to rwx segment test problems 125654 1256552022-05-06 Tom Tromey <tom@tromey.com> 125656 125657 Introduce catchpoint class 125658 This introduces a catchpoint class that is used as the base class for 125659 all catchpoints. init_catchpoint is rewritten to be a constructor 125660 instead. 125661 125662 This changes the hierarchy a little -- some catchpoints now inherit 125663 from base_breakpoint whereas previously they did not. This isn't a 125664 problem, as long as re_set is redefined in catchpoint. 125665 1256662022-05-06 Tom Tromey <tom@tromey.com> 125667 125668 Add initializers to tracepoint 125669 This adds some initializers to tracepoint. I think right now these 125670 may not be needed, due to obscure rules about zero initialization. 125671 However, this will change in the next patch, and anyway it is clearer 125672 to be explicit. 125673 125674 Remove init_raw_breakpoint_without_location 125675 This removes init_raw_breakpoint_without_location, replacing it with a 125676 constructor on 'breakpoint' itself. The subclasses and callers are 125677 all updated. 125678 125679 Disable copying for breakpoint 125680 It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN. 125681 This patch does this. 125682 125683 Add constructor to exception_catchpoint 125684 This adds a constructor to exception_catchpoint and simplifies the 125685 caller. 125686 125687 Add constructor to syscall_catchpoint 125688 This adds a constructor to syscall_catchpoint and simplifies the 125689 caller. 125690 125691 Add constructor to signal_catchpoint 125692 This adds a constructor to signal_catchpoint and simplifies the 125693 caller. 125694 125695 Add constructor to solib_catchpoint 125696 This adds a constructor to solib_catchpoint and simplifies the caller. 125697 125698 Add constructor to fork_catchpoint 125699 This adds a constructor to fork_catchpoint and simplifies the caller. 125700 125701 Remove unnecessary line from catch_exec_command_1 125702 catch_exec_command_1 clears the new catchpoint's "exec_pathname" 125703 field, but this is already done by virtue of calling "new". 125704 125705 Constify breakpoint::print_recreate 125706 This constifies breakpoint::print_recreate. 125707 125708 Constify breakpoint::print_mention 125709 This constifies breakpoint::print_mention. 125710 125711 Constify breakpoint::print_one 125712 This constifies breakpoint::print_one. 125713 125714 Constify breakpoint::print_it 125715 This constifies breakpoint::print_it. Doing this pointed out some 125716 code in ada-lang.c that can be simplified a little as well. 125717 125718 Move works_in_software_mode to watchpoint 125719 works_in_software_mode is only useful for watchpoints. This patch 125720 moves it from breakpoint to watchpoint, and changes it to return bool. 125721 125722 Boolify breakpoint::explains_signal 125723 This changes breakpoint::explains_signal to return bool. 125724 125725 Remove breakpoint::ops 125726 The breakpoint::ops field is set but never used. This removes it. 125727 125728 Change print_recreate_thread to a method 125729 This changes print_recreate_thread to be a method on breakpoint. This 125730 function is only used as a helper by print_recreate methods, so I 125731 thought this transformation made sense. 125732 1257332022-05-06 Carl Love <cel@us.ibm.com> 125734 125735 PowerPC: bp-permanent.exp, kill-after-signal fix 125736 The break point after the stepi on Intel is the entry point of the user 125737 signal handler function test_signal_handler. The code at the break point 125738 looks like: 125739 125740 0x<hex address> <test_signal_handler>: endbr64 125741 125742 On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops 125743 after the stepi is in the vdso code inserted by the kernel. The code at the 125744 breakpoint looks like: 125745 125746 0x<hex address> <__kernel_start_sigtramp_rt64>: bctrl 125747 125748 This is different from other architectures. As discussed below, recent 125749 kernel changes involving the vdso for PowerPC have been made changes to the 125750 signal handler code flow. PowerPC is now stopping in function 125751 __kernel_start_sigtramp_rt64. PowerPC now requires an additional stepi to 125752 reach the user signal handler unlike other architectures. 125753 125754 The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an 125755 kernel that is older than Linux 5.9. 125756 125757 The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1: 125758 125759 commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9 125760 powerpc/64/signal: Balance return predictor stack in signal trampoline 125761 125762 An additional change to the PowerPC 64 signal handler was made in Linux 125763 kernel version 5.11-rc7 : 125764 125765 commit id: 24321ac668e452a4942598533d267805f291fdc9 125766 powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics 125767 125768 The first kernel change, puts code into the user space signal handler (in 125769 the vdso) as a performance optimization to prevent the call/return stack 125770 from getting out of balance. The patch ensures that the entire 125771 user/kernel/vdso cycle is balanced with the addition of the "brctl" 125772 instruction. 125773 125774 The second patch, fixes the semantics of __kernel_sigtramp_rt64(). A new 125775 symbol is introduced to serve as the jump target from the kernel to the 125776 trampoline which now consists of two parts. 125777 125778 The above changes for PowerPC signal handler, causes gdb to stop in the 125779 kernel code not the user signal handler as expected. The kernel dispatches 125780 to the vdso code which in turn calls into the signal handler. PowerPC is 125781 special in that the kernel is using a vdso instruction (bctrl) to enter the 125782 signal handler. 125783 125784 I do not have access to a system with the first patch but not the second. I did 125785 test on Power 9 with the Linux 5.15.0-27-generic kernel. Both tests fail on 125786 this Power 9 system. The two tests also fail on Power 10 with the Linux 125787 5.14.0-70.9.1.el9_0.ppc64le kernel. 125788 125789 The following patch fixes the issue by checking if gdb stopped at "signal 125790 handler called". If gdb stopped there, the tests verifies gdb is in the kernel 125791 function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the 125792 user signal handler. With the patch below, the tests run without errors on both 125793 the Power 9 and Power 10 systems with out any failures. 125794 1257952022-05-06 Alan Modra <amodra@gmail.com> 125796 125797 bfd targmatch.h makefile rule 125798 I hit this just now with a make -j build after touching config.bfd. 125799 mv: cannot stat 'targmatch.new': No such file or directory 125800 make[2]: *** [Makefile:2336: targmatch.h] Error 1 125801 make[2]: *** Waiting for unfinished jobs.... 125802 125803 Fix that by not removing the target of the rule, a practice that seems 125804 likely to cause parallel running of the rule recipe. The bug goes 125805 back to 1997, the initial c0734708814c commit. 125806 125807 * Makefile.am (targmatch.h): rm the temp file, not targmatch.h. 125808 * Makefile.in: Regenerate. 125809 1258102022-05-06 Tom de Vries <tdevries@suse.de> 125811 125812 [gdb/testsuite] Fix gdb.dwarf2/locexpr-data-member-location.exp with nopie 125813 When running test-case gdb.dwarf2/locexpr-data-member-location.exp with 125814 target board unix/-fno-PIE/-no-pie/-m32 I run into: 125815 ... 125816 (gdb) step^M 125817 26 return 0;^M 125818 (gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo 125819 ... 125820 125821 The problem is that the test-case tries to mimic some gdb_compile_shlib 125822 behaviour using: 125823 ... 125824 set flags {additional_flags=-fpic debug} 125825 get_func_info foo $flags 125826 ... 125827 but this doesn't work with the target board setting, because we end up doing: 125828 ... 125829 gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \ 125830 -o func_addr23029.x 125831 ... 125832 while gdb_compile_shlib properly filters out the -fno-PIE -no-pie. 125833 125834 Consequently, the address for foo determined by get_func_info doesn't match 125835 the actual address of foo. 125836 125837 Fix this by printing the address of foo using the result of gdb_compile_shlib. 125838 1258392022-05-06 GDB Administrator <gdbadmin@sourceware.org> 125840 125841 Automatic date update in version.in 125842 1258432022-05-05 Simon Marchi <simon.marchi@polymtl.ca> 125844 125845 gdb: use gdb::function_view for gdbarch_iterate_over_objfiles_in_search_order callback 125846 A rather straightforward patch to change an instance of callback + 125847 void pointer to gdb::function_view, allowing pasing lambdas that 125848 capture, and eliminating the need for the untyped pointer. 125849 125850 Change-Id: I73ed644e7849945265a2c763f79f5456695b0037 125851 1258522022-05-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 125853 125854 gprofng: use $host instead $target 125855 By mistake, $target was used instead of $host to configure the gprogng build. 125856 125857 gprofng/ChangeLog 125858 2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 125859 125860 PR gprofng/29113 125861 PR gprofng/29116 125862 * configure.ac: Use $host instead $target. 125863 * libcollector/configure.ac: Likewise. 125864 * configure: Rebuild. 125865 * libcollector/configure: Rebuild. 125866 1258672022-05-05 Simon Marchi <simon.marchi@efficios.com> 125868 125869 gdb: make regcache's cooked_write_test selftest work with native-extended-gdbserver board 125870 Running 125871 125872 $ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" 125873 125874 I get some failures: 125875 125876 Running selftest regcache::cooked_write_test::i386.^M 125877 Self test failed: target already pushed^M 125878 Running selftest regcache::cooked_write_test::i386:intel.^M 125879 Self test failed: target already pushed^M 125880 Running selftest regcache::cooked_write_test::i386:x64-32.^M 125881 Self test failed: target already pushed^M 125882 Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M 125883 Self test failed: target already pushed^M 125884 Running selftest regcache::cooked_write_test::i386:x86-64.^M 125885 Self test failed: target already pushed^M 125886 Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M 125887 Self test failed: target already pushed^M 125888 Running selftest regcache::cooked_write_test::i8086.^M 125889 Self test failed: target already pushed^M 125890 125891 This is because the native-extended-gdbserver automatically connects GDB 125892 to a GDBserver on startup, and therefore pushes a remote target on the 125893 initial inferior. cooked_write_test is currently written in a way that 125894 errors out if the current inferior has a process_stratum_target pushed. 125895 125896 Rewrite it to use scoped_mock_context, so it doesn't depend on the 125897 current inferior (the current one upon entering the function). 125898 125899 Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad 125900 1259012022-05-05 Luis Machado <luis.machado@arm.com> 125902 125903 Move TILE-Gx files to TARGET64_LIBOPCODES_CFILES 125904 TILE-Gx is a 64-bit core, so we should include those files in the 125905 TARGET64_LIBOPCODES_CFILES as opposed to TARGET32_LIBOPCODES_CFILES. 125906 125907 Don't define ARCH_cris for BFD64 125908 I believe it is a mistake to define ARCH_cris when BFD64 is defined. It is 125909 a 32-bit architecture, so should be placed outside of the BFD64 block. 125910 1259112022-05-05 Xi Ruoyao <xry111@mengyan1223.wang> 125912 125913 loongarch: Don't check ABI flags if no code section 125914 Various packages (glib and gtk4 for example) produces data-only objects 125915 using `ld -r -b binary` or `objcopy`, with no elf header flags set. But 125916 these files also have no code sections, so they should be compatible 125917 with all ABIs. 125918 125919 bfd/ 125920 * elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data): 125921 Skip ABI checks if the input has no code sections. 125922 125923 Reported-by: Wu Xiaotian <yetist@gmail.com> 125924 Suggested-by: Wang Xuerui <i@xen0n.name> 125925 1259262022-05-05 Andreas Krebbel <krebbel@linux.ibm.com> 125927 125928 IBM zSystems: mgrk, mg first operand requires register pair 125929 opcodes/ 125930 125931 * s390-opc.c (INSTR_RRF_R0RER): New instruction type. 125932 (MASK_RRF_R0RER): Define mask for new instruction type. 125933 * s390-opc.txt: Use RRF_R0RER for mgrk and RXY_RERRD for mg. 125934 1259352022-05-05 H.J. Lu <hjl.tools@gmail.com> 125936 125937 bfd: Check NULL pointer before setting ref_real 125938 PR ld/29086 125939 * linker.c (bfd_wrapped_link_hash_lookup): Check NULL pointer 125940 before setting ref_real. 125941 1259422022-05-05 GDB Administrator <gdbadmin@sourceware.org> 125943 125944 Automatic date update in version.in 125945 1259462022-05-05 H.J. Lu <hjl.tools@gmail.com> 125947 125948 LTO: Handle __real_SYM reference in IR 125949 When an IR symbol SYM is referenced in IR via __real_SYM, its resolution 125950 should be LDPR_PREVAILING_DEF, not PREVAILING_DEF_IRONLY, since LTO 125951 doesn't know that __real_SYM should be resolved by SYM. 125952 125953 bfd/ 125954 125955 PR ld/29086 125956 * linker.c (bfd_wrapped_link_hash_lookup): Mark SYM is referenced 125957 via __real_SYM. 125958 125959 include/ 125960 125961 PR ld/29086 125962 * bfdlink.h (bfd_link_hash_entry): Add ref_real. 125963 125964 ld/ 125965 125966 PR ld/29086 125967 * plugin.c (get_symbols): Resolve SYM definition to 125968 LDPR_PREVAILING_DEF for __real_SYM reference. 125969 * testsuite/ld-plugin/lto.exp: Run PR ld/29086 test. 125970 * testsuite/ld-plugin/pr29086.c: New file. 125971 1259722022-05-04 Alan Modra <amodra@gmail.com> 125973 125974 cris bfd config 125975 cris support will be built into a 32-bit bfd if using --enable-targets=all 125976 on a 32-bit host, so we may as well make targmatch.h include cris. 125977 125978 * config.bfd (cris): Remove #idef BFD64. 125979 1259802022-05-04 Alan Modra <amodra@gmail.com> 125981 125982 PowerPC64 check_relocs 125983 Tidy the dynamic reloc handling code in check_relocs, removing 125984 leftover comments and code from when check_relocs was called as each 125985 object file was read in. 125986 125987 * elf64-ppc.c (ppc64_elf_check_relocs): Tidy dynamic reloc 125988 handling code. 125989 (dec_dynrel_count): Do the same here. 125990 1259912022-05-04 Tom Tromey <tromey@adacore.com> 125992 125993 Fix crash when creating index from index 125994 My patches yesterday to unify the DWARF index base classes had a bug 125995 -- namely, I did the wholesale dynamic_cast-to-static_cast too hastily 125996 and introduced a crash. This can be seen by trying to add an index to 125997 a file that has an index, or by running a test like gdb-index-cxx.exp 125998 using the cc-with-debug-names.exp target board. 125999 126000 This patch fixes the crash by introducing a new virtual method and 126001 removing some of the static casts. 126002 1260032022-05-04 Luis Machado <luis.machado@arm.com> 126004 126005 Fix build failure for aarch64 gdbserver 126006 We're missing an argument. 126007 1260082022-05-04 Mark Wielaard <mark@klomp.org> 126009 126010 gdb: Workaround stringop-overread warning in debuginfod-support.c on s390x 126011 For some reason g++ 11.2.1 on s390x produces a spurious warning for 126012 stringop-overread in debuginfod_is_enabled for url_view. Add a new 126013 DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning. 126014 126015 include/ChangeLog: 126016 126017 * diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New 126018 macro. 126019 126020 gdb/ChangeLog: 126021 126022 * debuginfod-support.c (debuginfod_is_enabled): Use 126023 DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x. 126024 1260252022-05-04 Pedro Alves <pedro@palves.net> 126026 126027 Fix GDBserver Aarch64 Linux regression 126028 Luis noticed that the recent changes to gdbserver to make it track 126029 process and threads independently regressed a few gdb.multi/*.exp 126030 tests for aarch64-linux. 126031 126032 We started seeing the following internal error for 126033 gdb.multi/multi-target-continue.exp for example: 126034 126035 Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M 126036 Error in re-setting breakpoint 2: Remote connection closed^M 126037 ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M 126038 A problem internal to GDB has been detected,^M 126039 further debugging may prove unreliable. 126040 126041 A backtrace looks like: 126042 126043 #0 thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120 126044 #1 0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31 126045 #2 0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194 126046 #3 0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=<optimized out>, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226 126047 #4 0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226 126048 #5 check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862 126049 #6 0x0000aaaaaaacc660 in read_inferior_memory (memaddr=<optimized out>, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93 126050 #7 0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071 126051 #8 gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048 126052 #9 0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307 126053 #10 handle_serial_event (err=<optimized out>, client_data=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520 126054 #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700 126055 #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596 126056 #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237 126057 #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518 126058 #15 captured_main (argc=4, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998 126059 #16 0x0000aaaaaaab66dc in main (argc=<optimized out>, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084 126060 126061 This sequence of functions is invoked due to a series of conditions: 126062 126063 1 - The probe-based breakpoint mechanism failed (for some reason) so ... 126064 126065 2 - ... gdbserver has to know what type of architecture it is dealing 126066 with so it can pick the right breakpoint kind, so it wants to 126067 check if we have a 64-bit target. 126068 126069 3 - To determine the size of a register, we currently fetch the 126070 current thread's register cache, and the current thread pointer 126071 is now nullptr. 126072 126073 In #3, the current thread is nullptr because gdb_read_memory clears it 126074 on purpose, via set_desired_process, exactly to expose code relying on 126075 the current thread when it shouldn't. It was always possible to end 126076 up in this situation (when the current thread exits), but it was 126077 harder to reproduce before. 126078 126079 This commit fixes it by tweaking is_64bit_tdesc to look at the current 126080 process's tdesc instead of the current thread's tdesc. 126081 126082 Note that the thread's tdesc is itself filled from the process's 126083 tdesc, so this should be equivalent: 126084 126085 struct regcache * 126086 get_thread_regcache (struct thread_info *thread, int fetch) 126087 { 126088 struct regcache *regcache; 126089 126090 regcache = thread_regcache_data (thread); 126091 126092 ... 126093 if (regcache == NULL) 126094 { 126095 struct process_info *proc = get_thread_process (thread); 126096 126097 gdb_assert (proc->tdesc != NULL); 126098 126099 regcache = new_register_cache (proc->tdesc); 126100 set_thread_regcache_data (thread, regcache); 126101 } 126102 ... 126103 126104 Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc 126105 1261062022-05-04 Simon Marchi <simon.marchi@efficios.com> 126107 126108 gdb/remote: send qSymbol to all inferiors on startup 126109 start_remote_1 calls remote_check_symbols after things are set up to 126110 give the remote side a chance to look up symbols. One call to 126111 remote_check_symbols sets the "general thread", if needed, and sends one 126112 qSymbol packet. However, a remote target could have more than one 126113 process on initial connection, and this would send a qSymbol for only 126114 one of these processes. 126115 126116 Change it to iterate on all the target's inferiors and send a qSymbol 126117 packet for each one. 126118 126119 I tested this by changing gdbserver to spawn two processes on startup: 126120 126121 diff --git a/gdbserver/server.cc b/gdbserver/server.cc 126122 index 33c42714e72..9b682e9f85f 100644 126123 --- a/gdbserver/server.cc 126124 +++ b/gdbserver/server.cc 126125 @@ -3939,6 +3939,7 @@ captured_main (int argc, char *argv[]) 126126 126127 /* Wait till we are at first instruction in program. */ 126128 target_create_inferior (program_path.get (), program_args); 126129 + target_create_inferior (program_path.get (), program_args); 126130 126131 /* We are now (hopefully) stopped at the first instruction of 126132 the target process. This assumes that the target process was 126133 126134 Instead of hacking GDBserver, it should also be possible to test this by 126135 starting manually two inferiors on an "extended-remote" connection, 126136 disconnecting from GDBserver (with the disconnect command), and 126137 re-connecting. 126138 126139 I was able to see qSymbol being sent for each inferior: 126140 126141 [remote] Sending packet: $Hgp828dc.828dc#1f 126142 [remote] Packet received: OK 126143 [remote] Sending packet: $qSymbol::#5b 126144 [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572 126145 [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e 126146 [remote] Packet received: qSymbol:6e70746c5f76657273696f6e 126147 [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d 126148 [remote] Packet received: OK 126149 [remote] Sending packet: $Hgp828dd.828dd#21 126150 [remote] Packet received: OK 126151 [remote] Sending packet: $qSymbol::#5b 126152 [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572 126153 [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e 126154 [remote] Packet received: qSymbol:6e70746c5f76657273696f6e 126155 [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d 126156 [remote] Packet received: OK 126157 126158 Note that there would probably be more work to be done to fully support 126159 this scenario, more things that need to be done for each discovered 126160 inferior instead of just for one. 126161 126162 Change-Id: I21c4ecf6367391e2e389b560f0b4bd906cf6472f 126163 1261642022-05-04 Simon Marchi <simon.marchi@polymtl.ca> 126165 126166 gdb/remote: iterate on pspace inferiors in remote_new_objfile 126167 Commit 152a17495663 ("gdb: prune inferiors at end of 126168 fetch_inferior_event, fix intermittent failure of 126169 gdb.threads/fork-plus-threads.exp") broke some tests with the 126170 native-gdbserver board, such as: 126171 126172 (gdb) PASS: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : vfork: break marker 126173 continue^M 126174 Continuing.^M 126175 terminate called after throwing an instance of 'gdb_exception_error'^M 126176 126177 I can manually reproduce the issue by running (just the commands that 126178 the test does as a one liner): 126179 126180 $ ./gdb -q --data-directory=data-directory \ 126181 testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork \ 126182 -ex "tar rem | ../gdbserver/gdbserver - testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork" \ 126183 -ex "b main" \ 126184 -ex c \ 126185 -ex "d 1" \ 126186 -ex "set displaced-stepping off" \ 126187 -ex "b *0x7ffff7d7ac5a if main == 0" \ 126188 -ex "set detach-on-fork off" \ 126189 -ex "set follow-fork-mode child" \ 126190 -ex c \ 126191 -ex "inferior 1" \ 126192 -ex "b marker" \ 126193 -ex c 126194 126195 ... where 0x7ffff7d7ac5a is the exact address of the vfork syscall 126196 (which can be found by looking at gdb.log). 126197 126198 The important part of the above is that a vfork syscall creates inferior 126199 2, then inferior 2 executes until exit, then we switch back to inferior 126200 1 and try to resume it. 126201 126202 The uncaught exception happens here: 126203 126204 #4 0x00005596969d81a9 in error (fmt=0x559692da9e40 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.") 126205 at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43 126206 #5 0x0000559695af6f66 in remote_target::putpkt_binary (this=0x617000038080, buf=0x559692da4380 "qSymbol::", cnt=9) at /home/simark/src/binutils-gdb/gdb/remote.c:9560 126207 #6 0x0000559695af6aaf in remote_target::putpkt (this=0x617000038080, buf=0x559692da4380 "qSymbol::") at /home/simark/src/binutils-gdb/gdb/remote.c:9518 126208 #7 0x0000559695ab50dc in remote_target::remote_check_symbols (this=0x617000038080) at /home/simark/src/binutils-gdb/gdb/remote.c:5141 126209 #8 0x0000559695b3cccf in remote_new_objfile (objfile=0x0) at /home/simark/src/binutils-gdb/gdb/remote.c:14600 126210 #9 0x0000559693bc52a9 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:61 126211 #10 0x0000559693bb2848 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:111 126212 #11 0x0000559693b8dddf in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffe0bae0590: 0x0) at /usr/include/c++/11.2.0/bits/std_function.h:291 126213 #12 0x00005596956374b2 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x61b0000167f8, __args#0=0x0) at /usr/include/c++/11.2.0/bits/std_function.h:560 126214 #13 0x0000559695633c64 in gdb::observers::observable<objfile*>::notify (this=0x55969ef5c480 <gdb::observers::new_objfile>, args#0=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:150 126215 #14 0x0000559695df6cc2 in clear_symtab_users (add_flags=...) at /home/simark/src/binutils-gdb/gdb/symfile.c:2873 126216 #15 0x000055969574c263 in program_space::~program_space (this=0x6120000c8a40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/progspace.c:154 126217 #16 0x0000559694fc086b in delete_inferior (inf=0x61700003bf80) at /home/simark/src/binutils-gdb/gdb/inferior.c:205 126218 #17 0x0000559694fc341f in prune_inferiors () at /home/simark/src/binutils-gdb/gdb/inferior.c:390 126219 #18 0x0000559695017ada in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4293 126220 #19 0x0000559694f629e6 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:41 126221 #20 0x0000559695b3b0e3 in remote_async_serial_handler (scb=0x6250001ef100, context=0x6170000380a8) at /home/simark/src/binutils-gdb/gdb/remote.c:14466 126222 #21 0x0000559695c59eb7 in run_async_handler_and_reschedule (scb=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:138 126223 #22 0x0000559695c5a42a in fd_event (error=0, context=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:189 126224 #23 0x00005596969d9ebf in handle_file_event (file_ptr=0x60700005af40, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:574 126225 #24 0x00005596969da7fa in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:700 126226 #25 0x00005596969d8539 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212 126227 126228 If I enable "set debug infrun" just before the last continue, we see: 126229 126230 (gdb) continue 126231 Continuing. 126232 [infrun] clear_proceed_status_thread: 965604.965604.0 126233 [infrun] proceed: enter 126234 [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT 126235 [infrun] scoped_disable_commit_resumed: reason=proceeding 126236 [infrun] start_step_over: enter 126237 [infrun] start_step_over: stealing global queue of threads to step, length = 0 126238 [infrun] operator(): step-over queue now empty 126239 [infrun] start_step_over: exit 126240 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c 126241 [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0 126242 [infrun] prepare_to_wait: prepare_to_wait 126243 [infrun] reset: reason=proceeding 126244 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote 126245 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote 126246 [infrun] proceed: exit 126247 [infrun] fetch_inferior_event: enter 126248 [infrun] scoped_disable_commit_resumed: reason=handling event 126249 [infrun] do_target_wait: Found 2 inferiors, starting at #1 126250 [infrun] random_pending_event_thread: None found. 126251 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 126252 [infrun] print_target_wait_results: 965604.965604.0 [Thread 965604.965604], 126253 [infrun] print_target_wait_results: status->kind = VFORK_DONE 126254 [infrun] handle_inferior_event: status->kind = VFORK_DONE 126255 [infrun] context_switch: Switching context from 0.0.0 to 965604.965604.0 126256 [infrun] handle_vfork_done: not waiting for a vfork-done event 126257 [infrun] start_step_over: enter 126258 [infrun] start_step_over: stealing global queue of threads to step, length = 0 126259 [infrun] operator(): step-over queue now empty 126260 [infrun] start_step_over: exit 126261 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c 126262 [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0 126263 [infrun] prepare_to_wait: prepare_to_wait 126264 [infrun] reset: reason=handling event 126265 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote 126266 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote 126267 terminate called after throwing an instance of 'gdb_exception_error' 126268 126269 What happens is: 126270 126271 - After doing the "continue" on inferior 1, the remote target gives us 126272 a VFORK_DONE event. The core ignores it and resumes inferior 1. 126273 - Since prune_inferiors is now called after each handled event, in 126274 fetch_inferior_event, it is called after we handled that VFORK_DONE 126275 event and resumed inferior 1. 126276 - Inferior 2 is pruned, which (see backtrace above) causes its program 126277 space to be deleted, which clears the symtabs for that program space, 126278 which calls the new_objfile observable and remote_new_objfile 126279 observer (with a nullptr objfile, to indicate that the previously 126280 loaded symbols have been discarded), which calls 126281 remote_check_symbols. 126282 126283 remote_check_symbols is the function that sends the qSymbol packet, to 126284 let the remote side ask for symbol addresses. The problem is that the 126285 remote target is working in all-stop / sync mode and is currently 126286 resumed. It has sent a vCont packet to resume the target and is waiting 126287 for a stop reply. It can't send any packets in the mean time. That 126288 causes the exception to be thrown. 126289 126290 This wasn't a problem before, when prune_inferiors was called in 126291 normal_stop, because it was always called at a time the target was not 126292 resumed. 126293 126294 An important observation here is that the new_objfile observable is 126295 invoked for a change in inferior 2's program space (inferior 2's program 126296 space is the current program space). Inferior 2 isn't bound to any 126297 process on the remote side (it has exited, that's why it's being 126298 pruned). It doesn't make sense to try to send a qSymbol packet for a 126299 process that doesn't exist on the remote side. remote_check_symbols 126300 actually attempts to avoid that: 126301 126302 /* The remote side has no concept of inferiors that aren't running 126303 yet, it only knows about running processes. If we're connected 126304 but our current inferior is not running, we should not invite the 126305 remote target to request symbol lookups related to its 126306 (unrelated) current process. */ 126307 if (!target_has_execution ()) 126308 return; 126309 126310 The problem here is that while inferior 2's program space is the current 126311 program space, inferior 1 is the current inferior. So the check above 126312 passes, since inferior has execution. We therefore try to send a 126313 qSymbol packet for inferior 1 in reaction to a change in inferior 2's 126314 program space, that's wrong. 126315 126316 This exposes a conceptual flaw in remote_new_objfile. The "new_objfile" 126317 event concerns a specific program space, which can concern multiple 126318 inferiors, as inferiors can share a program space. We shouldn't 126319 consider the current inferior at all, but instead all inferiors bound to 126320 the affected program space. Especially since the current inferior can 126321 be unrelated to the current program space at that point. 126322 126323 To be clear, we are in this state because ~program_space sets itself as 126324 the current program space, but there is no more inferior having that 126325 program space to switch to, inferior 2 has already been unlinked. 126326 126327 To fix this, make remote_new_objfile iterate on all inferiors bound to 126328 the affected program space. Remove the target_has_execution check from 126329 remote_check_symbols, replace it with an assert. All callers must 126330 ensure that the current inferior has execution before calling it. 126331 126332 Change-Id: Ica643145bcc03115248290fd310cadab8ec8371c 126333 1263342022-05-04 Jan Beulich <jbeulich@suse.com> 126335 126336 Dwarf: rename yet another instance of "index" 126337 As before, on sufficiently old glibc this conflicts with a global 126338 identifier in the library headers. While there also zap the unusual 126339 padding by blanks. 126340 1263412022-05-04 Martin Liska <mliska@suse.cz> 126342 126343 LTO plugin: sync header file with GCC 126344 include/ChangeLog: 126345 126346 * plugin-api.h (enum ld_plugin_tag): Sync with GCC. 126347 1263482022-05-04 Alan Modra <amodra@gmail.com> 126349 126350 PowerPC32 treatment of absolute symbols 126351 As already done for PowerPC64, fix dynamic relocs for absolute symbols. 126352 The patch also tidies the dynamic reloc handling code in check_relocs, 126353 removing leftover comments and code from when check_relocs was called 126354 as each object file was read in. 126355 126356 bfd/ 126357 * elf32-ppc.c (ppc_elf_check_relocs): Set isym and ifunc earlier. 126358 Rearrange tests for dynamic relocs, handling absolute symbols. 126359 (allocate_dynrelocs): Don't allocate dynamic relocs for locally 126360 defined absolute symbols. 126361 (ppc_elf_size_dynamic_sections): Similarly. 126362 (ppc_elf_relocate_section): Similarly. 126363 ld/ 126364 * testsuite/ld-powerpc/abs32-pie.d, 126365 * testsuite/ld-powerpc/abs32-pie.r, 126366 * testsuite/ld-powerpc/abs32-reloc.s, 126367 * testsuite/ld-powerpc/abs32-shared.d, 126368 * testsuite/ld-powerpc/abs32-shared.r, 126369 * testsuite/ld-powerpc/abs32-static.d, 126370 * testsuite/ld-powerpc/abs32-static.r: New tests. 126371 * testsuite/ld-powerpc/powerpc.exp: Run them. 126372 1263732022-05-04 John Baldwin <jhb@FreeBSD.org> 126374 126375 gdbserver: Fix build after adding tls feature to arm tdesc. 126376 1263772022-05-04 GDB Administrator <gdbadmin@sourceware.org> 126378 126379 Automatic date update in version.in 126380 1263812022-05-04 John Baldwin <jhb@FreeBSD.org> 126382 126383 NEWS: Add a note for TLS support on FreeBSD/arm and FreeBSD/Aarch64. 126384 126385 Read the tpidr register from NT_ARM_TLS on Linux. 126386 126387 gdbserver: Read the tpidr register from NT_ARM_TLS on Linux. 126388 126389 Read the tpidr register from NT_ARM_TLS core dump notes on Linux Aarch64. 126390 126391 Fetch the NT_ARM_TLS register set for native FreeBSD/Aarch64 processes. 126392 This permits resolving TLS variables. 126393 126394 Support TLS variables on FreeBSD/Aarch64. 126395 Derive the pointer to the DTV array from the tpidr register. 126396 126397 Read the tpidr register from NT_ARM_TLS core dump notes on FreeBSD/Aarch64. 126398 126399 Add an aarch64-tls feature which includes the tpidr register. 126400 126401 Fetch the NT_ARM_TLS register set for native FreeBSD/arm processes. 126402 This permits resolving TLS variables. 126403 126404 Support TLS variables on FreeBSD/arm. 126405 Derive the pointer to the DTV array from the tpidruro register. 126406 126407 Read the tpidruro register from NT_ARM_TLS core dump notes on FreeBSD/arm. 126408 126409 Add an arm-tls feature which includes the tpidruro register from CP15. 126410 126411 fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET. 126412 FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET 126413 operations to fetch a register set named by an ELF note type. These 126414 helper routines provide helpers to check for a register set's 126415 existence, fetch registers for a register set, and store registers to 126416 a register set. 126417 1264182022-05-03 H.J. Lu <hjl.tools@gmail.com> 126419 126420 ld: Regenerate aclocal.m4 with automake 1.15.1 126421 * aclocal.m4: Regenerate with automake 1.15.1. 126422 1264232022-05-03 Pedro Alves <pedro@palves.net> 126424 126425 gdbserver: track current process as well as current thread 126426 The recent commit 421490af33bf ("gdbserver/linux: Access memory even 126427 if threads are running") caused a regression in 126428 gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I 126429 somehow missed. Like so: 126430 126431 (gdb) print global_var 126432 Cannot access memory at address 0x555555558010 126433 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1) 126434 126435 The problem starts with GDB telling GDBserver to select a thread, via 126436 the Hg packet, which GDBserver complies with, then that thread exits, 126437 and GDB, without knowing the thread is gone, tries to write to memory, 126438 through the context of the previously selected Hg thread. 126439 126440 GDBserver's GDB-facing memory access routines, gdb_read_memory and 126441 gdb_write_memory, call set_desired_thread to make GDBserver re-select 126442 the thread that GDB has selected with the Hg packet. Since the thread 126443 is gone, set_desired_thread returns false, and the memory access 126444 fails. 126445 126446 Now, to access memory, it doesn't really matter which thread is 126447 selected. All we should need is the target process. Even if the 126448 thread that GDB previously selected is gone, and GDB does not yet know 126449 about that exit, it shouldn't matter, GDBserver should still know 126450 which process that thread belonged to. 126451 126452 Fix this by making GDBserver track the current process separately, 126453 like GDB also does. Add a new set_desired_process routine that is 126454 similar to set_desired_thread, but just sets the current process, 126455 leaving the current thread as NULL. Use it in the GDB-facing memory 126456 read and write routines, to avoid failing if the selected thread is 126457 gone, but the process is still around. 126458 126459 Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd 126460 1264612022-05-03 Pedro Alves <pedro@palves.net> 126462 126463 Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver 126464 When testing gdb.threads/access-mem-running-thread-exit.exp with 126465 --target_board=native-extended-gdbserver, we get: 126466 126467 Running gdb.threads/access-mem-running-thread-exit.exp ... 126468 FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main 126469 WARNING: Timed out waiting for EOF in server after monitor exit 126470 126471 === gdb Summary === 126472 126473 # of expected passes 3 126474 # of unexpected failures 1 126475 # of unsupported tests 1 126476 126477 The problem is that the testcase spawns a second inferior with 126478 -no-connection, and then runto_main does "run", which fails like so: 126479 126480 (gdb) run 126481 Don't know how to run. Try "help target". 126482 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main 126483 126484 That "run" above failed because native-extended-gdbserver forces "set 126485 auto-connect-native-target off", to prevent testcases from mistakenly 126486 running programs with the native target, which would exactly be the 126487 case here. 126488 126489 Fix this by letting the second inferior share the first inferior's 126490 connection everywhere except on targets that do reload on run (e.g., 126491 --target_board=native-gdbserver). 126492 126493 Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed 126494 1264952022-05-03 Andrew Burgess <aburgess@redhat.com> 126496 126497 gdb: add some additional thread status debug output 126498 While working on this patch: 126499 126500 https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html 126501 126502 I found it really useful to print the executing/resumed status of all 126503 threads (or all threads in a particular inferior) at various 126504 places (e.g. when a new inferior is started, when GDB attaches, etc). 126505 126506 This debug was originally part of the above patch, but I wanted to 126507 rewrite this as a separate patch and move the code into a new function 126508 in infrun.h, which is what this patch does. 126509 126510 Unless 'set debug infrun on' is in effect, then there should be no 126511 user visible changes after this commit. 126512 1265132022-05-03 Nick Clifton <nickc@redhat.com> 126514 126515 Add a linker warning when creating potentially dangerous executable segments. Add tests, options to disabke and configure switches to choose defaults. 126516 126517 Fix potential arithmetic overflow in the linker's plugin handling code. 126518 PR 29101 126519 * libdep_plugin.c (get_libdeps): Check for overflow when computing 126520 amount of memory to allocate. 126521 1265222022-05-03 Andrew Burgess <aburgess@redhat.com> 126523 126524 objdump: fix styled printing of addresses 126525 Previous work to add styled disassembler output missed a case in 126526 objdump_print_addr, which is fixed in this commit. 126527 1265282022-05-03 Andrew Burgess <aburgess@redhat.com> 126529 126530 gdb/testsuite: small cleanup in mi-break-qualified.exp 126531 It is not necessary to pass an empty string to mi_gdb_start, passing 126532 the empty string is equivalent to passing no arguments, which is what 126533 we do everywhere else (that we don't need to specify an actual 126534 argument). 126535 126536 The only place we use 'mi_gdb_start ""' is in 126537 gdb.mi/mi-break-qualified.exp, so in this commit I just replace that 126538 with a call to 'mi_gdb_start' - just for consistency. 126539 126540 There should be no change in what is tested after this commit. 126541 1265422022-05-03 Andrew Burgess <aburgess@redhat.com> 126543 126544 gdb/testsuite: change mi_gdb_start to take a list of flags 126545 After this previous commit I was thinking about the API of 126546 mi_gdb_start. I felt that the idea of passing flags as separate 126547 arguments and using 'args' to gather these into a list, though clever, 126548 was not an intuitive API. 126549 126550 In this commit I modify mi_gdb_start so that it expects a single 126551 argument, which should be a list of flags. Thus, where we previously 126552 would have said: 126553 126554 mi_gdb_start separate-mi-tty separate-inferior-tty 126555 126556 We would now say: 126557 126558 mi_gdb_start { separate-mi-tty separate-inferior-tty } 126559 126560 However, it turns out we never actually call mi_gdb_start passing two 126561 arguments in this way at all. We do in some places do this: 126562 126563 mi_gdb_start separate-inferior-tty 126564 126565 But that's fine, a single string like this works equally well as a 126566 single item list, so this will not need updating. 126567 126568 There is also one place where we do this: 126569 126570 eval mi_gdb_start $start_ops 126571 126572 where $start_ops is a list that might contains 0, 1, or 2 items. The 126573 eval here is used to expand the $start_ops list so mi_gdb_start sees 126574 the list contents as separate arguments. In this case we just need to 126575 drop the use of eval. 126576 126577 I think that the new API is more intuitive, but others might 126578 disagree, in which case I can drop this change. 126579 126580 There should be no change in what is tested after this commit. 126581 1265822022-05-03 Andrew Burgess <aburgess@redhat.com> 126583 126584 gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver board 126585 When running with the native-extended-gdbserver board, I currently see 126586 one failure in gdb.mi/mi-exec-run.exp: 126587 126588 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) 126589 126590 In this test the MI interface should be started in a separate tty, 126591 which means we should have a CLI tty and an MI tty, however, this is 126592 not happening. Instead GDB is just started in MI mode and there is no 126593 CLI tty. 126594 126595 The test script tries to switch between the CLI an MI terminals and 126596 look for some expected output on each, however, as there is no CLI 126597 terminal the expected output never arrives, and the test times out. 126598 126599 It turns out that this is not a GDB problem, rather, this is an issue 126600 with argument passing within the test script. 126601 126602 The proc default_mi_gdb_start expects to take a set of flags (strings) 126603 as arguments, each of flag is expected to be a separate argument. The 126604 default_mi_gdb_start proc collects all its arguments into a list using 126605 the special 'args' parameter name, and then iterates over this list to 126606 see which flags were passed. 126607 126608 In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments 126609 are also gathered into the 'args' parameter list, but are then 126610 expanded back to be separate arguments using the eval trick, i.e.: 126611 126612 proc mi_gdb_start { args } { 126613 return [eval default_mi_gdb_start $args] 126614 } 126615 126616 This ensures that when we arrive in default_mi_gdb_start each flag is 126617 a separate argument, rather than appearing as a single list containing 126618 all arguments. 126619 126620 When using the native-extended-gdbserver board however, the file 126621 boards/native-extended-gdbserver.exp is loaded, and this file replaces 126622 the default mi_gdb_start with its own version. 126623 126624 This new mi_gdb_start also gathers the arguments into an 'args' list, 126625 but forgets to expand the arguments out using the eval trick. 126626 126627 As a result, when using the native-extended-gdbserver board, by the 126628 time we get to default_mi_gdb_start, we end up with the args list 126629 containing a single item, which is a list containing all the arguments 126630 the user passed. 126631 126632 What this means is that if the user passes two arguments, then, in 126633 default_mi_gdb_start, instead of seeing two separate arguments, we see 126634 a single argument made by concatenating the two arguments together. 126635 126636 The only place this is a problem is in the test mi-exec-run.exp, 126637 which (as far as I can see) is the only test where we might try to 126638 pass both arguments at the same time. Currently we think we passed 126639 both arguments to mi_gdb_start, but mi_gdb_start behaves as if no 126640 arguments were passed. 126641 126642 This commit fixes the problem by making use of the eval trick within 126643 the native-extended-gdbserver version of mi_gdb_start. After this, 126644 the FAIL listed at the top of this message is resolved. 126645 1266462022-05-03 Andrew Burgess <aburgess@redhat.com> 126647 126648 gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver 126649 When running the gdb.mi/mi-exec-run.exp test using the 126650 native-extended-gdbserver I see failures like this: 126651 126652 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected 126653 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected 126654 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected 126655 126656 There's a race condition here, so you might see a slightly different 126657 set of failures, but I always see some from the 'run failure detected' 126658 test. 126659 126660 NOTE: I also see an additional test failure: 126661 126662 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) 126663 126664 but that is a completely different issue, and is not being addressed 126665 in this commit. 126666 126667 The problem for the 'run failure detected' test is that we end up 126668 in gdb_expect looking for output from two spawn-ids, one from 126669 gdbserver, and one from gdb. We're looking for one output pattern 126670 from each spawn-id, and for the test to pass we need to see both 126671 patterns. 126672 126673 Now, if gdb exits then this is a test failure (this would indicate gdb 126674 crashing, which is bad), so we have an eof pattern associated with 126675 the gdb spawn-id. 126676 126677 However, in this particular test we expect gdbserver to fail to 126678 execute the binary (the test binary is set non-executable), and so we 126679 get an error message from gdbserver (which matches the pattern), and 126680 then gdbserver exits, this is expected. 126681 126682 The problem is that after spotting the pattern from gdbserver, we 126683 often see the eof from gdbserver before we see the pattern from gdb. 126684 If this happens then we drop out of the gdb_expect without ever seeing 126685 the pattern from gdb, and fail the test. 126686 126687 In this commit, I place the spawn-id of gdbserver into a global 126688 variable, and then use this global variable as the -i option within 126689 the gdb_expect. 126690 126691 Now, once we have seen the expected pattern on the gdbserver spawn-id, 126692 the global variable is cleared. After this the gdb_expect no longer 126693 checks the gdbserver spawn-id for additional output, and so never sees 126694 the eof event. This leaves the gdb_expect running, which allows the 126695 pattern from gdb to be seen, and for the test to pass. 126696 126697 I now see no failures relating to 'run failure detected'. 126698 1266992022-05-03 GDB Administrator <gdbadmin@sourceware.org> 126700 126701 Automatic date update in version.in 126702 1267032022-05-02 Tom de Vries <tdevries@suse.de> 126704 126705 [gdb/testsuite] Fix gdb.cp/align.exp with gcc 12.1 / 11.3 126706 Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into: 126707 ... 126708 align.cc:29:23: error: invalid application of 'alignof' to a void type^M 126709 29 | unsigned a_void = alignof (void);^M 126710 | ^~~~~~~~~~~~~~^M 126711 ... 126712 126713 Fix this by using __alignof__ instead. 126714 126715 Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1. 126716 1267172022-05-02 Aaron Merey <amerey@redhat.com> 126718 126719 gdb/debuginfod: Whitespace-only URL should disable debuginfod 126720 Currently debuginfod is disabled when the string of server URLs 126721 is unset or set to be the empty string (via the $DEBUGINFOD_URLS 126722 environment variable or the 'set debuginfod urls' gdb command). 126723 126724 Extend this functionality so that a whitespace-only URL also disables 126725 debuginfod. 126726 126727 Modify a testcase to verify that a whitespace-only URL disables 126728 debuginfod. 126729 1267302022-05-02 Simon Marchi <simon.marchi@efficios.com> 126731 126732 gdb: remove type_wanted parameter from a few functions 126733 The type_wanted value, passed down to the create_sals_from_location 126734 callback, is never used. Remove it. 126735 126736 Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c 126737 1267382022-05-02 Simon Marchi <simon.marchi@efficios.com> 126739 126740 gnulib: update to bd11400942d6 126741 Update the gnulib import to fixes these issues: 126742 126743 - GDB build with clang + glibc < 2.33. 126744 126745 https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d6a07b4dc21b3118727743142c678858df442853 126746 https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00072.html 126747 126748 With glibc < 2.33, gnulib (since relatively recently) enables a 126749 replacement for free (see gnulib/import/m4/free.m4). In that path, 126750 clang shows this error: 126751 126752 make[2]: Entering directory '/home/smarchi/build/binutils-gdb-clang/gdbsupport' 126753 CXX agent.o 126754 In file included from /home/smarchi/src/binutils-gdb/gdbsupport/agent.cc:20: 126755 In file included from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:95: 126756 ../gnulib/import/string.h:636:19: error: exception specification in declaration does not match previous declaration 126757 _GL_EXTERN_C void free (void *) throw (); 126758 ^ 126759 ../gnulib/import/stdlib.h:737:17: note: expanded from macro 'free' 126760 # define free rpl_free 126761 ^ 126762 ../gnulib/import/stdlib.h:739:1: note: previous declaration is here 126763 _GL_FUNCDECL_RPL (free, void, (void *ptr)); 126764 ^ 126765 ../gnulib/import/sys/select.h:251:23: note: expanded from macro '_GL_FUNCDECL_RPL' 126766 _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes) 126767 ^ 126768 <scratch space>:139:1: note: expanded from here 126769 rpl_free 126770 ^ 126771 126772 The gnulib commit mentioned fixes the exception specification of `free`. 126773 126774 - GDB build on RHEL 7: 126775 126776 CC libgnu_a-openat-proc.o 126777 In file included from /usr/include/string.h:633, 126778 from ./string.h:41, 126779 from ../../../binutils-gdb/gnulib/import/openat-proc.c:30: 126780 ./string.h:1105:1: error: expected identifier or '(' before '__extension__' 126781 1105 | _GL_FUNCDECL_SYS (strndup, char *, 126782 | ^~~~~~~~~~~~~~~~ 126783 126784 https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b 126785 https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00075.html 126786 126787 Change-Id: Ibd51302feece6f385d0c53e0d08921b5d95e2776 126788 1267892022-05-02 Tom Tromey <tromey@adacore.com> 126790 126791 Fix Ada catchpoint regression 126792 The breakpoint C++-ification series introduced a regression for Ada 126793 catchpoints. Specifically, commit 2b5ab5b8 ("Convert base breakpoints 126794 to vtable ops") caused these to start failing. I didn't notice this 126795 because testing Ada using a Linux distro compiler requires installing 126796 the GNAT debuginfo, which I hadn't done. 126797 126798 This patch fixes the problem. I'm checking it in. 126799 1268002022-05-02 GDB Administrator <gdbadmin@sourceware.org> 126801 126802 Automatic date update in version.in 126803 1268042022-05-01 Tom de Vries <tdevries@suse.de> 126805 126806 [gdb/testsuite] Fix gdb.multi/attach-no-multi-process.exp with check-readmore 126807 When running test-case gdb.multi/attach-no-multi-process.exp with 126808 check-readmore, I get: 126809 ... 126810 (gdb) attach 13411^M 126811 Attaching to Remote target^M 126812 No unwaited-for children left.^M 126813 (gdb) Reading symbols from attach-no-multi-process...^M 126814 Reading symbols from /lib64/libm.so.6...^M 126815 (No debugging symbols found in /lib64/libm.so.6)^M 126816 Reading symbols from /lib64/libc.so.6...^M 126817 (No debugging symbols found in /lib64/libc.so.6)^M 126818 Reading symbols from /lib64/ld-linux-x86-64.so.2...^M 126819 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M 126820 0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M 126821 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \ 126822 attach to the program via remote (timeout) 126823 ... 126824 126825 The problem is that the attach output is matched using gdb_test, which uses 126826 the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is 126827 not the last available output. 126828 126829 Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so 126830 without the '$' anchor. 126831 126832 Tested on x86_64-linux with native, check-read1 and check-readmore. 126833 1268342022-05-01 GDB Administrator <gdbadmin@sourceware.org> 126835 126836 Automatic date update in version.in 126837 1268382022-04-30 Thomas Hebb <tommyhebb@gmail.com> 126839 126840 opcodes: don't assume ELF in riscv, csky, rl78, mep disassemblers 126841 Currently, the get_disassembler() implementations for riscv, csky, and 126842 rl78--and mep_print_insn() for mep--access ELF variants of union fields 126843 without first checking that the bfd actually represents an ELF. This 126844 causes undefined behavior and crashes when disassembling non-ELF files 126845 (the "binary" BFD, for example). Fix that. 126846 1268472022-04-30 GDB Administrator <gdbadmin@sourceware.org> 126848 126849 Automatic date update in version.in 126850 1268512022-04-29 Tom Tromey <tom@tromey.com> 126852 126853 Remove create_breakpoints_sal_default 126854 create_breakpoints_sal_default is just a simple wrapper, so remove it. 126855 126856 Remove allocate_bp_location 126857 allocate_bp_location is just a small wrapper for a method call, so 126858 inline it everywhere. 126859 126860 Constify breakpoint_ops 126861 Now that all breakpoint_ops are statically initialized, they can all 126862 be made const. 126863 126864 Remove breakpoint ops initialization 126865 initialize_breakpoint_ops does not do much any more, so remove it in 126866 favor of statically-initialize objects. 126867 126868 Remove vtable_breakpoint_ops 126869 There's no need to have vtable_breakpoint_ops any more, so remove it 126870 in favor of base_breakpoint_ops. 126871 126872 Remove most fields from breakpoint_ops 126873 At this point, all implementations of breakpoints use the vtable. So, 126874 we can now remove most function pointers from breakpoint_ops and 126875 switch to using methods directly in the callers. Only the two "static 126876 virtual" methods remain in breakpoint_ops. 126877 126878 Remove breakpoint_ops from init_catchpoint 126879 init_catchpoint is only ever passed a single breakpoint_ops pointer, 126880 so remove the parameter. 126881 126882 Remove breakpoint_ops from init_ada_exception_breakpoint 126883 init_ada_exception_breakpoint is only ever passed a single 126884 breakpoint_ops structure, so remove the parameter. 126885 1268862022-04-29 Tom Tromey <tom@tromey.com> 126887 126888 Merge probe and ordinary tracepoints 126889 Right now, probe tracepoints are handled by a separate ops object. 126890 However, they differ only in a small way from ordinary tracepoints, 126891 and furthermore can be distinguished by their event location. 126892 126893 This patch merges the two cases, just as was done for breakpoints. 126894 1268952022-04-29 Tom Tromey <tom@tromey.com> 126896 126897 Merge probe and ordinary breakpoints 126898 Right now, probe breakpoints are handled by a separate ops object. 126899 However, they differ only in a small way from ordinary breakpoints, 126900 and furthermore can be distinguished by their "probe" object. 126901 126902 This patch merges the two cases. This avoids having to introduce a 126903 new bp_ constant (which can be quite subtle to do correctly) and a new 126904 subclass. 126905 1269062022-04-29 Tom Tromey <tom@tromey.com> 126907 126908 Remove bkpt_base_breakpoint_ops 126909 An earlier patch removed the last use of bkpt_base_breakpoint_ops, so 126910 remove the object entirely. 126911 126912 Convert static marker tracepoints to vtable ops 126913 This converts static marker tracepoints to use vtable_breakpoint_ops. 126914 126915 Add bp_static_marker_tracepoint 126916 Because the actual construction of a breakpoint is buried deep in 126917 create_breakpoint, at present it's necessary to have a new bp_ 126918 enumerator constant any time a new subclass is needed. Static marker 126919 tracepoints are one such case, so this patch introduces 126920 bp_static_marker_tracepoint and updates various spots to recognize it. 126921 126922 Convert ranged breakpoints to vtable ops 126923 This converts ranged breakpoints to use vtable_breakpoint_ops. This 126924 requires introducing a new ranged_breakpoint type, but this is 126925 relatively simple because ranged breakpoints can only be created by 126926 break_range_command. 126927 126928 Convert dprintf to vtable ops 126929 This converts dprintf to use vtable_breakpoint_ops. 126930 126931 Convert Ada catchpoints to vtable ops 126932 This converts Ada catchpoints to use vtable_breakpoint_ops. 126933 126934 Convert ordinary breakpoints to vtable ops 126935 This converts "ordinary" breakpoint to use vtable_breakpoint_ops. 126936 Recall that an ordinary breakpoint is both the kind normally created 126937 by users, and also a base class used by other classes. 126938 126939 Change inheritance of dprintf 126940 The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops, 126941 except it's written out explicitly -- and, importantly, there's 126942 nothing that bpkt_breakpoint_ops overrides that dprintf does not. 126943 This changes dprintf to simply inherit directly, and updates struct 126944 dprintf_breakpoint to reflect the change as well. 126945 126946 Convert momentary breakpoints to vtable ops 126947 This converts momentary breakpoints to use vtable_breakpoint_ops. 126948 126949 Convert internal breakpoints to vtable ops 126950 This converts internal breakpoints to use vtable_breakpoint_ops. 126951 126952 Convert break-catch-throw to vtable ops 126953 This converts break-catch-throw.c to use vtable_breakpoint_ops. 126954 126955 Convert base breakpoints to vtable ops 126956 This converts base breakpoints to use vtable_breakpoint_ops. 126957 1269582022-04-29 Tom Tromey <tom@tromey.com> 126959 126960 Add some new subclasses of breakpoint 126961 This adds a few new subclasses of breakpoint. The inheritance 126962 hierarchy is chosen to reflect what's already present in 126963 initialize_breakpoint_ops -- it mirrors the way that the _ops 126964 structures are filled in. 126965 126966 This patch also changes new_breakpoint_from_type to create the correct 126967 sublcass based on bptype. This is important due to the somewhat 126968 inverted way in which create_breakpoint works; and in particular later 126969 patches will change some of these entries. 126970 1269712022-04-29 Tom Tromey <tom@tromey.com> 126972 126973 Convert tracepoints to vtable ops 126974 This converts tracepoints to use vtable_breakpoint_ops. 126975 126976 Convert watchpoints to vtable ops 126977 This converts watchpoints and masked watchpoints. to use 126978 vtable_breakpoint_ops. For masked watchpoints, a new subclass must be 126979 introduced, and watch_command_1 is changed to create one. 126980 126981 Convert break-catch-load to vtable ops 126982 This converts break-catch-load.c to use vtable_breakpoint_ops. 126983 126984 Convert break-catch-fork to vtable ops 126985 This converts break-catch-fork.c to use vtable_breakpoint_ops. 126986 126987 Convert break-catch-exec to vtable ops 126988 This converts break-catch-exec.c to use vtable_breakpoint_ops. 126989 126990 Convert break-catch-syscall to vtable ops 126991 This converts break-catch-syscall.c to use vtable_breakpoint_ops. 126992 126993 Convert break-catch-sig to use vtable ops 126994 This converts break-catch-sig.c to use vtable_breakpoint_ops. 126995 1269962022-04-29 Tom Tromey <tom@tromey.com> 126997 126998 Add a vtable-based breakpoint ops 126999 This adds methods to struct breakpoint. Each method has a similar 127000 signature to a corresponding function in breakpoint_ops, with the 127001 exceptions of create_sals_from_location and create_breakpoints_sal, 127002 which can't be virtual methods on breakpoint -- they are only used 127003 during the construction of breakpoints. 127004 127005 Then, this adds a new vtable_breakpoint_ops structure and populates it 127006 with functions that simply forward a call from breakpoint_ops to the 127007 corresponding virtual method. These are all done with lambdas, 127008 because they are just a stepping stone -- by the end of the series, 127009 this structure will be deleted. 127010 1270112022-04-29 Tom Tromey <tom@tromey.com> 127012 127013 Return bool from breakpoint_ops::print_one 127014 This changes breakpoint_ops::print_one to return bool, and updates all 127015 the implementations and the caller. The caller is changed so that a 127016 NULL check is no longer needed -- something that will be impossible 127017 with a real method. 127018 127019 Delete some unnecessary wrapper functions 127020 This patch deletes a few unnecessary wrapper functions from 127021 breakpoint.c. 127022 127023 Add an assertion to clone_momentary_breakpoint 127024 This adds an assertion to clone_momentary_breakpoint. This will 127025 eventually be removed, but in the meantime is is useful for helping 127026 convince oneself that momentary breakpoints will always use 127027 momentary_breakpoint_ops. This understanding will help when cleaning 127028 up the code later. 127029 127030 Boolify print_solib_event 127031 Change print_solib_event to accept a bool parameter and update the 127032 callers. 127033 127034 Move "catch load" to a new file 127035 The "catch load" code is reasonably self-contained, and so this patch 127036 moves it out of breakpoint.c and into a new file, break-catch-load.c. 127037 One function from breakpoint.c, print_solib_event, now has to be 127038 exposed, but this seems pretty reasonable. 127039 1270402022-04-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 127041 127042 gprofng: assertion in gprofng/src/Expression.cc:139 127043 gprofng/ChangeLog 127044 2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 127045 127046 PR gprofng/29102 127047 * src/Expression.h: Remove fixupValues. 127048 * src/Expression.cc (Expression::copy): Fix a bug. 127049 1270502022-04-29 Tom Tromey <tromey@adacore.com> 127051 127052 De-duplicate .gdb_index 127053 This de-duplicates variables and types in .gdb_index, making the new 127054 index closer to what gdb generated before the new DWARF scanner 127055 series. Spot-checking the resulting index for gdb itself, it seems 127056 that the new scanner picks up some extra symbols not detected by the 127057 old one. I tested both the new and old versions of gdb on both new 127058 and old versions of the index, and startup time in all cases is 127059 roughly the same (it's worth noting that, for gdb itself, the index no 127060 longer provides any benefit over the DWARF scanner). So, I think this 127061 fixes the size issue with the new index writer. 127062 127063 Regression tested on x86-64 Fedora 34. 127064 1270652022-04-29 Tom Tromey <tromey@adacore.com> 127066 127067 Fix .debug_names regression with new indexer 127068 At AdaCore, we run the internal gdb test suite in several modes, 127069 including one using the .debug_names index. This caught a regression 127070 caused by the new DWARF indexer. 127071 127072 First, the psymtabs-based .debug_names generator was completely wrong. 127073 However, to avoid making the rewrite series even bigger (fixing the 127074 writer will also require rewriting the .debug_names reader), it 127075 attempted to preserve the weirdness. 127076 127077 However, this was not done properly. For example the old writer did 127078 this: 127079 127080 - case STRUCT_DOMAIN: 127081 - return DW_TAG_structure_type; 127082 127083 The new code, instead, simply preserves the actual DWARF tag -- but 127084 this makes future lookups fail, because the .debug_names reader only 127085 looks for DW_TAG_structure_type. 127086 127087 This patch attempts to revert to the old behavior in the writer. 127088 1270892022-04-29 Simon Marchi <simon.marchi@polymtl.ca> 127090 127091 gdb/infrun: make fetch_inferior_event restore thread if exited or signalled 127092 Commit 152a1749566 ("gdb: prune inferiors at end of 127093 fetch_inferior_event, fix intermittent failure of 127094 gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related 127095 test failures, such as: 127096 127097 info inferiors^M 127098 Num Description Connection Executable ^M 127099 * 1 process 634972 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M 127100 2 process 634975 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M 127101 (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors 127102 inferior 2^M 127103 [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M 127104 [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M 127105 #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M 127106 (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2 127107 continue^M 127108 Continuing.^M 127109 [Inferior 2 (process 634975) exited normally]^M 127110 [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M 127111 (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end 127112 break callee^M 127113 Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M 127114 (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee 127115 127116 What happens here is: 127117 127118 - inferior 2 is selected 127119 - we continue, leading to inferior 2's exit 127120 - we set breakpoint, expect 2 locations, but only one location is 127121 resolved 127122 127123 Reading between the lines, we understand that inferior 2 got pruned, 127124 when it shouldn't have been. 127125 127126 The issue can be reproduced by hand with: 127127 127128 $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun" 127129 ... 127130 Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14 127131 14 int v = 5; 127132 [New inferior 2 (process 637627)] 127133 [Thread debugging using libthread_db enabled] 127134 Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 127135 17 if (pid == 0) /* set breakpoint here */ 127136 [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)] 127137 [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))] 127138 #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6 127139 (gdb) continue 127140 Continuing. 127141 [infrun] clear_proceed_status_thread: 637627.637627.0 127142 [infrun] proceed: enter 127143 [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT 127144 [infrun] scoped_disable_commit_resumed: reason=proceeding 127145 [infrun] start_step_over: enter 127146 [infrun] start_step_over: stealing global queue of threads to step, length = 0 127147 [infrun] operator(): step-over queue now empty 127148 [infrun] start_step_over: exit 127149 [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop 127150 [infrun] proceed: resuming 637627.637627.0 127151 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7 127152 [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0 127153 [infrun] infrun_async: enable=1 127154 [infrun] prepare_to_wait: prepare_to_wait 127155 [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop 127156 [infrun] reset: reason=proceeding 127157 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native 127158 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native 127159 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native 127160 [infrun] proceed: exit 127161 [infrun] fetch_inferior_event: enter 127162 [infrun] scoped_disable_commit_resumed: reason=handling event 127163 [infrun] do_target_wait: Found 2 inferiors, starting at #1 127164 [infrun] random_pending_event_thread: None found. 127165 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 127166 [infrun] print_target_wait_results: 637627.637627.0 [process 637627], 127167 [infrun] print_target_wait_results: status->kind = EXITED, exit_status = 0 127168 [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0 127169 [Inferior 2 (process 637627) exited normally] 127170 [infrun] stop_waiting: stop_waiting 127171 [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1 127172 [infrun] stop_all_threads: pass=0, iterations=0 127173 [infrun] stop_all_threads: 637624.637624.0 not executing 127174 [infrun] stop_all_threads: pass=1, iterations=1 127175 [infrun] stop_all_threads: 637624.637624.0 not executing 127176 [infrun] stop_all_threads: done 127177 [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1 127178 [Switching to Thread 0x7ffff7c9a740 (LWP 637624)] 127179 [infrun] infrun_async: enable=0 127180 [infrun] reset: reason=handling event 127181 [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads 127182 (gdb) [infrun] fetch_inferior_event: exit 127183 (gdb) info inferiors 127184 Num Description Connection Executable 127185 * 1 process 637624 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork 127186 (gdb) i th 127187 Id Target Id Frame 127188 * 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17 127189 127190 After handling the EXITED event for inferior 2, inferior 2 should have 127191 stayed the current inferior, which should have prevented it from getting 127192 pruned. When debugging, we find that when getting at the 127193 prune_inferiors call, the current inferior is inferior 1. Further 127194 debugging shows that prior to the call to 127195 clean_up_just_stopped_threads_fsms, the current inferior is inferior 2, 127196 and after, it's inferior 1. Then, back in fetch_inferior_event, the 127197 restore_thread object is disabled, due to: 127198 127199 /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the 127200 previously selected thread is gone. We have two 127201 choices - switch to no thread selected, or restore the 127202 previously selected thread (now exited). We chose the 127203 later, just because that's what GDB used to do. After 127204 this, "info threads" says "The current thread <Thread 127205 ID 2> has terminated." instead of "No thread 127206 selected.". */ 127207 if (!non_stop 127208 && cmd_done 127209 && ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED) 127210 restore_thread.dont_restore (); 127211 127212 So in the end, inferior 1 stays current, and inferior 2 gets wrongfully 127213 pruned. 127214 127215 I'd say clean_up_just_stopped_threads_fsms is the culprit here. It 127216 actually attempts to restore the event_thread to be current at the end, 127217 after the loop (I presume the current thread on entry is always supposed 127218 to be the event thread). But in this case, the event is of kind EXITED, 127219 and ecs->event_thread is not set, so the current inferior isn't 127220 restored. 127221 127222 Fix that by using scoped_restore_current_thread. If there is no current 127223 thread, scoped_restore_current_thread will still restore the current 127224 inferior, and that's what we want. 127225 127226 Random note: the thread_info object for inferior 2's thread is never 127227 freed. It is held (by refcount) by the restore_thread object in 127228 fetch_inferior_event, while the inferior's thread list gets cleared, in 127229 the exit event processing. When the refcount reaches 0 (when the 127230 restore_thread object is destroyed), there's nothing that actually 127231 deletes the thread_info object. And I think that nothing in GDB points 127232 to it anymore, so it leaks. I don't want to fix that in this patch, but 127233 thought it would be good to mention it, in case somebody has an idea for 127234 how to fix that. 127235 127236 Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8 127237 1272382022-04-29 Pedro Alves <pedro@palves.net> 127239 127240 Slightly tweak and clarify target_resume's interface 127241 The current target_resume interface is a bit odd & non-intuitive. 127242 I've found myself explaining it a couple times the recent past, while 127243 reviewing patches that assumed STEP/SIGNAL always applied to the 127244 passed in PTID. It goes like this today: 127245 127246 - if the passed in PTID is a thread, then the step/signal request is 127247 for that thread. 127248 127249 - otherwise, if PTID is a wildcard (all threads or all threads of 127250 process), the step/signal request is for inferior_ptid, and PTID 127251 indicates which set of threads run free. 127252 127253 Because GDB always switches the current thread to "leader" thread 127254 being resumed/stepped/signalled, we can simplify this a bit to: 127255 127256 - step/signal are always for inferior_ptid. 127257 127258 - PTID indicates the set of threads that run free. 127259 127260 Still not ideal, but it's a minimal change and at least there are no 127261 special cases this way. 127262 127263 That's what this patch does. It renames the PTID parameter to 127264 SCOPE_PTID, adds some assertions to target_resume, and tweaks 127265 target_resume's description. In addition, it also renames PTID to 127266 SCOPE_PTID in the remote and linux-nat targets, and simplifies their 127267 implementation a little bit. Other targets could do the same, but 127268 they don't have to. 127269 127270 Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf 127271 1272722022-04-29 GDB Administrator <gdbadmin@sourceware.org> 127273 127274 Automatic date update in version.in 127275 1272762022-04-28 Tom Tromey <tromey@adacore.com> 127277 127278 Fix libinproctrace.so build on PPC 127279 The recent gnulib import caused a build failure of libinproctrace.so 127280 on PPC: 127281 127282 alloc.c:(.text+0x20): undefined reference to `rpl_malloc' 127283 alloc.c:(.text+0x70): undefined reference to `rpl_realloc' 127284 127285 This patch fixes the problem using the same workaround that was 127286 previously used for free. 127287 1272882022-04-28 H.J. Lu <hjl.tools@gmail.com> 127289 127290 x86: Properly handle function pointer reference 127291 Update 127292 127293 commit ebb191adac4ab45498dec0bfaac62f0a33537ba4 127294 Author: H.J. Lu <hjl.tools@gmail.com> 127295 Date: Wed Feb 9 15:51:22 2022 -0800 127296 127297 x86: Disallow invalid relocation against protected symbol 127298 127299 to allow function pointer reference and make sure that PLT entry isn't 127300 used for function reference due to function pointer reference. 127301 127302 bfd/ 127303 127304 PR ld/29087 127305 * elf32-i386.c (elf_i386_scan_relocs): Don't set 127306 pointer_equality_needed nor check non-canonical reference for 127307 function pointer reference. 127308 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 127309 127310 ld/ 127311 127312 PR ld/29087 127313 * testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests. 127314 * testsuite/ld-x86-64/protected-func-3.c: New file. 127315 1273162022-04-28 Tom Tromey <tom@tromey.com> 127317 127318 Check OBJF_NOT_FILENAME in DWARF index code 127319 The DWARF index code currently uses 'stat' to see if an objfile 127320 represents a real file. However, I think it's more correct to check 127321 OBJF_NOT_FILENAME instead. 127322 127323 Regression tested on x86-64 Fedora 34. 127324 1273252022-04-28 Tom Tromey <tromey@adacore.com> 127326 127327 Remove "typedef enum ..." 127328 I noticed a few spots in GDB that use "typedef enum". However, in C++ 127329 this isn't as useful, as the tag is automatically entered as a 127330 typedef. This patch removes most uses of "typedef enum" -- the 127331 exceptions being in some nat-* code I can't compile, and 127332 glibc_thread_db.h, which I think is more or less a copy of some C code 127333 from elsewhere. 127334 127335 Tested by rebuilding. 127336 1273372022-04-28 Andrew Burgess <aburgess@redhat.com> 127338 127339 gdb: fix nullptr dereference in block::ranges() 127340 This commit: 127341 127342 commit f5cb8afdd297dd68273d98a10fbfd350dff918d8 127343 Date: Sun Feb 6 22:27:53 2022 -0500 127344 127345 gdb: remove BLOCK_RANGES macro 127346 127347 introduces a potential nullptr dereference in block::ranges, this is 127348 breaking most tests, e.g. gdb.base/break.exp is failing for me. 127349 127350 In the above patch BLOCK_CONTIGUOUS_P is changed from this: 127351 127352 #define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \ 127353 || BLOCK_NRANGES (bl) <= 1) 127354 127355 to this: 127356 127357 #define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \ 127358 || (bl)->ranges ().size () == 1) 127359 127360 So, before the commit we checked for the block ranges being nullptr, 127361 but afterwards we just call block::ranges() in all cases. 127362 127363 The problem is that block::ranges() looks like this: 127364 127365 /* Return a view on this block's ranges. */ 127366 gdb::array_view<blockrange> ranges () 127367 { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } 127368 127369 where m_ranges is: 127370 127371 struct blockranges *m_ranges; 127372 127373 And so, we see that the nullptr check has been lost, and we might end 127374 up dereferencing a nullptr. 127375 127376 My proposed fix is to move the nullptr check into block::ranges, and 127377 return an explicit empty array_view if m_ranges is nullptr. 127378 127379 After this, everything seems fine again. 127380 1273812022-04-28 Stefan Liebler <stli@linux.ibm.com> 127382 127383 s390: Add DT_JMPREL pointing to .rela.[i]plt with static-pie 127384 In static-pie case, there are IRELATIVE-relocs in 127385 .rela.iplt (htab->irelplt), which will later be grouped 127386 to .rela.plt. On s390, the IRELATIVE relocations are 127387 always located in .rela.iplt - even for non-static case. 127388 Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added 127389 to the dynamic section even if htab->srelplt->size == 0. 127390 See _bfd_elf_add_dynamic_tags in bfd/elflink.c. 127391 127392 bfd/ 127393 elf64-s390.c (elf_s390_size_dynamic_sections): 127394 Enforce DT_JMPREL via htab->elf.dt_jmprel_required. 127395 1273962022-04-28 Stefan Liebler <stli@linux.ibm.com> 127397 127398 s390: Avoid dynamic TLS relocs in PIE 127399 No dynamic relocs are needed for TLS defined in an executable, the 127400 TP relative offset is known at link time. 127401 127402 Fixes 127403 FAIL: Build pr22263-1 127404 127405 bfd/ 127406 PR ld/22263 127407 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll 127408 instead of bfd_link_pic for TLS. 127409 (elf_s390_check_relocs): Likewise. 127410 (allocate_dynrelocs): Likewise. 127411 (elf_s390_relocate_section): Likewise. 127412 1274132022-04-28 Nick Alcock <nick.alcock@oracle.com> 127414 127415 libctf: impose an ordering on conflicting types 127416 When two types conflict and they are not types which can have forwards 127417 (say, two arrays of different sizes with the same name in two different 127418 TUs) the CTF deduplicator uses a popularity contest to decide what to 127419 do: the type cited by the most other types ends up put into the shared 127420 dict, while the others are relegated to per-CU child dicts. 127421 127422 This works well as long as one type *is* most popular -- but what if 127423 there is a tie? If several types have the same popularity count, 127424 we end up picking the first we run across and promoting it, and 127425 unfortunately since we are working over a dynhash in essentially 127426 arbitrary order, this means we promote a random one. So multiple 127427 runs of ld with the same inputs can produce different outputs! 127428 All the outputs are valid, but this is still undesirable. 127429 127430 Adjust things to use the same strategy used to sort types on the output: 127431 when there is a tie, always put the type that appears in a CU that 127432 appeared earlier on the link line (and if there is somehow still a tie, 127433 which should be impossible, pick the type with the lowest type ID). 127434 127435 Add a testcase -- and since this emerged when trying out extern arrays, 127436 check that those work as well (this requires a newer GCC, but since all 127437 GCCs that can emit CTF at all are unreleased this is probably OK as 127438 well). 127439 127440 Fix up one testcase that has slight type ordering changes as a result 127441 of this change. 127442 127443 libctf/ChangeLog: 127444 127445 * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use 127446 cd_output_first_gid to break ties. 127447 127448 ld/ChangeLog: 127449 127450 * testsuite/ld-ctf/array-conflicted-ordering.d: New test, using... 127451 * testsuite/ld-ctf/array-char-conflicting-1.c: ... this... 127452 * testsuite/ld-ctf/array-char-conflicting-2.c: ... and this. 127453 * testsuite/ld-ctf/array-extern.d: New test, using... 127454 * testsuite/ld-ctf/array-extern.c: ... this. 127455 * testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering 127456 changes. 127457 1274582022-04-28 Nick Alcock <nick.alcock@oracle.com> 127459 127460 libctf: add a comment explaining how to use ctf_*open 127461 Specifically, tell users what to pass to those functions that accept raw 127462 section content, since it's fairly involved and easy to get wrong. 127463 (.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab). 127464 127465 include/ChangeLog: 127466 127467 * ctf-api.h (ctf_*open): Improve comment. 127468 1274692022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 127470 127471 gprofng: test suite problems 127472 gprofng/ChangeLog 127473 2022-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 127474 127475 PR gprofng/29065 127476 * testsuite/lib/Makefile.skel: Search parent dir for libs too. 127477 1274782022-04-28 Simon Marchi <simon.marchi@polymtl.ca> 127479 127480 gdb: remove BLOCKVECTOR_MAP macro 127481 Replace with equivalent methods. 127482 127483 Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0 127484 1274852022-04-28 Simon Marchi <simon.marchi@polymtl.ca> 127486 127487 gdb: constify addrmap_find 127488 addrmap_find shouldn't need to modify the addrmap, so constify the 127489 addrmap parameter. This helps for the following patch, where getting 127490 the map of a const blockvector will return a const addrmap. 127491 127492 Change-Id: If670e425ed013724a3a77aab7961db50366dccb2 127493 1274942022-04-28 Simon Marchi <simon.marchi@efficios.com> 127495 127496 gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macros 127497 Replace with calls to blockvector::blocks, and the appropriate method 127498 call on the returned array_view. 127499 127500 Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd 127501 1275022022-04-28 Simon Marchi <simon.marchi@efficios.com> 127503 127504 gdb: remove BLOCK_ENTRY_PC macro 127505 Replace with equivalent method. 127506 127507 Change-Id: I0e033095e7358799930775e61028b48246971a7d 127508 1275092022-04-28 Simon Marchi <simon.marchi@efficios.com> 127510 127511 gdb: remove BLOCK_CONTIGUOUS_P macro 127512 Replace with an equivalent method. 127513 127514 Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5 127515 1275162022-04-28 Simon Marchi <simon.marchi@efficios.com> 127517 127518 gdb: remove BLOCK_RANGE macro 127519 Replace with access through the block::ranges method. 127520 127521 Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121 127522 1275232022-04-28 Simon Marchi <simon.marchi@efficios.com> 127524 127525 gdb: remove BLOCK_NRANGES macro 127526 Replace with range for loops. 127527 127528 Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3 127529 1275302022-04-28 Simon Marchi <simon.marchi@efficios.com> 127531 127532 gdb: remove BLOCK_RANGES macro 127533 Replace with an equivalent method on struct block. 127534 127535 Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a 127536 1275372022-04-28 Simon Marchi <simon.marchi@efficios.com> 127538 127539 gdb: remove BLOCK_RANGE_{START,END} macros 127540 Replace with equivalent methods on blockrange. 127541 127542 Change-Id: I20fd8f624e0129782c36768291891e7582d77c74 127543 1275442022-04-28 Simon Marchi <simon.marchi@efficios.com> 127545 127546 gdb: remove BLOCK_NAMESPACE macro 127547 Replace with equivalent methods. 127548 127549 Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a 127550 1275512022-04-28 Simon Marchi <simon.marchi@efficios.com> 127552 127553 gdb: remove BLOCK_MULTIDICT macro 127554 Replace with equivalent methods. 127555 127556 Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2 127557 1275582022-04-28 Simon Marchi <simon.marchi@efficios.com> 127559 127560 gdb: remove BLOCK_SUPERBLOCK macro 127561 Replace with equivalent methods. 127562 127563 Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630 127564 1275652022-04-28 Simon Marchi <simon.marchi@efficios.com> 127566 127567 gdb: remove BLOCK_FUNCTION macro 127568 Replace with equivalent methods. 127569 127570 Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101 127571 1275722022-04-28 Simon Marchi <simon.marchi@efficios.com> 127573 127574 gdb: remove BLOCK_{START,END} macros 127575 Replace with equivalent methods. 127576 127577 Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310 127578 1275792022-04-28 GDB Administrator <gdbadmin@sourceware.org> 127580 127581 Automatic date update in version.in 127582 1275832022-04-27 H.J. Lu <hjl.tools@gmail.com> 127584 127585 x86: Disable 2 tests with large memory requirement 127586 gas/ 127587 127588 * testsuite/gas/i386/i386.exp: Disable rept. 127589 127590 ld/ 127591 127592 * testsuite/ld-x86-64/x86-64.exp: Disable pr17618. 127593 1275942022-04-27 Pedro Alves <pedro@palves.net> 127595 127596 Make gdb.base/parse_number.exp test all architectures 127597 There are some subtle differences between architectures, like the size 127598 of a "long" type, and this isn't currently accounted for in 127599 gdb.base/parse_number.exp. 127600 127601 For example, on aarch64 a long type is 8 bytes, whereas a long type is 127602 4 bytes for x86_64. This causes the following FAIL's: 127603 127604 FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff 127605 FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff 127606 FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff 127607 FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff 127608 FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff 127609 FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff 127610 FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff 127611 FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff 127612 FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff 127613 FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff 127614 FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff 127615 FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff 127616 127617 There are some fortran-specific divergences as well, where 32-bit 127618 architectures show "unsigned int" for both 32-bit and 64-bit integers 127619 and 64-bit architectures show "unsigned int" and "unsigned long" for 127620 32-bit and 64-bit integers. 127621 127622 There might be a bug that 32-bit fortran truncates 64-bit values to 127623 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". 127624 127625 Here's what we get for aarch64: 127626 127627 (gdb) ptype 0xffffffff 127628 type = unsigned int 127629 (gdb) ptype 0xffffffffffffffff 127630 type = unsigned long 127631 (gdb) p sizeof (0xffffffff) 127632 $1 = 4 127633 (gdb) p sizeof (0xffffffffffffffff) 127634 quit 127635 $2 = 8 127636 (gdb) ptype 0xffffffff 127637 type = unsigned int 127638 (gdb) ptype 0xffffffffffffffff 127639 type = unsigned long 127640 127641 And for arm: 127642 127643 (gdb) ptype 0xffffffff 127644 type = unsigned int 127645 (gdb) ptype 0xffffffffffffffff 127646 quit 127647 type = unsigned long long 127648 (gdb) p sizeof (0xffffffff) 127649 quit 127650 $1 = 4 127651 (gdb) p sizeof (0xffffffffffffffff) 127652 quit 127653 $2 = 8 127654 (gdb) ptype 0xffffffff 127655 type = unsigned int 127656 (gdb) ptype 0xffffffffffffffff 127657 type = unsigned long 127658 127659 This patch... 127660 127661 * Makes the testcase iterate over all architectures, thus covering all 127662 the different combinations of types/sizes every time. 127663 127664 * Adjusts the expected values and types based on the sizes of long 127665 long, long and int. 127666 127667 A particularly curious architecture is s12z, which has 32-bit long 127668 long, and thus no way to represent 64-bit integers in C-like 127669 languages. 127670 127671 Co-Authored-By: Luis Machado <luis.machado@arm.com> 127672 Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b 127673 1276742022-04-27 Tom Tromey <tromey@adacore.com> 127675 127676 Fix gdbserver build for x86-64 Windows 127677 I broke the gdbserver build on x86-64 Windows a little while back. 127678 Previously, I could not build this configuration, but today I found 127679 out that if I configure with: 127680 127681 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 127682 127683 using the Fedora 34 tools, it will in fact build. I'm not certain, 127684 but maybe the gnulib update helped with this. 127685 127686 This patch fixes the build. I'm checking it in. 127687 1276882022-04-27 John Baldwin <jhb@FreeBSD.org> 127689 127690 Create pseudo sections for NT_ARM_TLS notes on FreeBSD. 127691 bfd/ChangeLog: 127692 127693 * elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes. 127694 1276952022-04-27 Christophe Lyon <christophe.lyon@arm.com> 127696 127697 gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add unwind-secure-frames command 127698 This patch makes use of the support for several stack pointers 127699 introduced by the previous patch to switch between them as needed 127700 during unwinding. 127701 127702 It introduces a new 'unwind-secure-frames' arm command to enable/disable 127703 mode switching during unwinding. It is enabled by default. 127704 127705 It has been tested using an STM32L5 board (with cortex-m33) and the 127706 sample applications shipped with the STM32Cube development 127707 environment: GTZC_TZSC_MPCBB_TrustZone in 127708 STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC. 127709 127710 The test consisted in setting breakpoints in various places and check 127711 that the backtrace is correct: SecureFault_Callback (Non-secure mode), 127712 __gnu_cmse_nonsecure_call (before and after the vpush instruction), 127713 SecureFault_Handler (Secure mode). 127714 127715 This implies that we tested only some parts of this patch (only MSP* 127716 were used), but remaining parts seem reasonable. 127717 1277182022-04-27 Christophe Lyon <christophe.lyon@arm.com> 127719 127720 gdb/arm: Add support for multiple stack pointers on Cortex-M 127721 Armv8-M architecture with Security extension features four stack pointers 127722 to handle Secure and Non-secure modes. 127723 127724 This patch adds support to switch between them as needed during 127725 unwinding, and replaces all updates of cache->prev_sp with calls to 127726 arm_cache_set_prev_sp. 127727 1277282022-04-27 Christophe Lyon <christophe.lyon@arm.com> 127729 127730 gdb/arm: Introduce arm_cache_init 127731 This patch is a preparation for the rest of the series and adds two 127732 arm_cache_init helper functions. It updates every place that updates 127733 cache->saved_regs to call the helper instead. 127734 127735 gdb/arm: Define MSP and PSP registers for M-Profile 127736 This patch removes the hardcoded access to PSP in 127737 arm_m_exception_cache() and relies on the definition with the XML 127738 descriptions. 127739 1277402022-04-27 Christophe Lyon <christophe.lyon@arm.com> 127741 127742 gdb/arm: Fix prologue analysis to support vpush 127743 While working on adding support for Non-secure/Secure modes unwinding, 127744 I noticed that the prologue analysis lacked support for vpush, which 127745 is used for instance in the CMSE stub routine. 127746 127747 This patch updates thumb_analyze_prologue accordingly, adding support 127748 for vpush of D-registers. 127749 1277502022-04-27 Enze Li <lienze2010@hotmail.com> 127751 127752 gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.exp 127753 Tom and Simon feedback that there is a test failing in this commit: 127754 127755 commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6 127756 Date: Sun Apr 17 15:09:46 2022 +0800 127757 127758 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) 127759 127760 Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I 127761 fixed the nit in this patch. The root of the problem is not correctly 127762 matching the presentation of internal breakpoints. 127763 127764 In addition, as Pedro pointed out, the original testcase is not portable 127765 in some methods, so this patch fixes this issue and some other 127766 improvements. 127767 127768 Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425"). 127769 1277702022-04-27 Jan Beulich <jbeulich@suse.com> 127771 127772 x86: VFPCLASSSH is Evex.LLIG 127773 This also was mistakenly flagged as Evex.128. 127774 1277752022-04-27 Nick Clifton <nickc@redhat.com> 127776 127777 Fix potential buffer overruns when creating DLLs. 127778 PR 29006 127779 * pe-dll.c (make_head): Use asprintf to allocate and populate a 127780 buffer containing the temporary name. 127781 (make_tail, make_one, make_singleton_name_thunk): Likewise. 127782 (make_import_fixup_mark, make_import_fixup_entry): Likewise. 127783 (make_runtime_pseudo_reloc): Likewise. 127784 (pe_create_runtime_relocator_reference): Likewise. 127785 1277862022-04-27 Alan Modra <amodra@gmail.com> 127787 127788 Revert pr29072 lto test changes 127789 Revert commit 65daf5bed6 testsuite changes in ld-plugin/. -z isn't 127790 supported for non-ELF targets, and isn't needed since we now prune the 127791 exec stack warning (commit 333cd559ba). 127792 127793 PR 29072 127794 1277952022-04-27 Simon Marchi <simon.marchi@polymtl.ca> 127796 127797 gdb/testsuite: use with_cwd where possible 127798 I learned about with_cwd today. I spotted a few spots that could use 127799 it, to make the code more robust. 127800 127801 Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1 127802 1278032022-04-27 GDB Administrator <gdbadmin@sourceware.org> 127804 127805 Automatic date update in version.in 127806 1278072022-04-26 Carl Love <cel@us.ibm.com> 127808 127809 GDB PowerPC record test cases for ISA 2.06 and ISA 3.1 127810 This patch adds PowerPC specific tests to verify recording of various 127811 instructions. The first test case checks the ISA 2.06 lxvd2x instruction. 127812 The second test case tests several of the ISA 3.01 instructions. Specifically, 127813 it checks the word and prefixed instructions and some of the Matrix 127814 Multiply Assist (MMA) instructions. 127815 127816 The patch has been run on both Power 10 and Power 9 to verify the ISA 127817 2.06 test case runs on both platforms without errors. The ISA 3.1 test 127818 runs without errors on Power 10 and is skipped as expected on Power 9. 127819 1278202022-04-26 Carl Love <cel@us.ibm.com> 127821 127822 Add recording support for the ISA 3.1 PowerPC instructions. 127823 This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC 127824 gdb instruction recording routines. Case statement entries are added to a 127825 number of the existing routines for recording the 32-bit word instructions. 127826 A few new functions were added to handle the new word instructions. The 64-bit 127827 prefix instructions are all handled by a set of new routines. The function 127828 ppc_process_prefix_instruction() is the primary function to handle the 127829 prefixed instructions. It calls additional functions to handle specific 127830 sets of prefixed instructions. These new functions are: 127831 ppc_process_record_prefix_vsx_d_form(), 127832 ppc_process_record_prefix_store_vsx_ds_form(), 127833 ppc_process_record_prefix_op34(), 127834 ppc_process_record_prefix_op33(), 127835 ppc_process_record_prefix_op32(), 127836 ppc_process_record_prefix_store(), 127837 ppc_process_record_prefix_op59_XX3(), 127838 ppc_process_record_prefix_op42(). 127839 1278402022-04-26 Tom Tromey <tromey@adacore.com> 127841 127842 Handle encoding failures in Windows thread names 127843 Internally at AdaCore, we noticed that the new Windows thread name 127844 code could fail. First, it might return a zero-length string, but in 127845 gdb conventions it should return nullptr instead. Second, an encoding 127846 failure could wind up showing replacement characters to the user; this 127847 is confusing and not useful; it's better to recognize such errors and 127848 simply discard the name. This patch makes both of these changes. 127849 1278502022-04-26 H.J. Lu <hjl.tools@gmail.com> 127851 127852 i386: Pass -z noexecstack to linker tests 127853 PR ld/29072 127854 * testsuite/ld-i386/i386.exp: Pass -z noexecstack to gotpc1 127855 and property-6. 127856 1278572022-04-26 John Baldwin <jhb@FreeBSD.org> 127858 127859 bsd-kvm: Fix build after recent changes to path handling functions. 127860 Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to 127861 std::string rather than simple char * pointers freed by xfree. 127862 1278632022-04-26 Simon Marchi <simon.marchi@polymtl.ca> 127864 127865 gdb: make some random Python files Python 3-compatible 127866 I noticed that these files failed to format with Black, because they use 127867 print without parenthesis (which isn't Python 3 compatible). 127868 127869 I don't know if these files are still relevant, but the change is 127870 trivial, so here it is. 127871 127872 Change-Id: I116445c2b463486016f824d32effffc915b60766 127873 1278742022-04-26 Carl Love <cel@us.ibm.com> 127875 127876 PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp and gdb.arch/vsx-regs.exp 127877 The format for printing the floating point values was changed by commit: 127878 127879 commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e 127880 Author: Tom Tromey <tromey@adacore.com> 127881 Date: Thu Feb 17 13:43:59 2022 -0700 127882 127883 Change how "print/x" displays floating-point value 127884 127885 Currently, "print/x" will display a floating-point value by first 127886 casting it to an integer type. This yields weird results like: 127887 127888 (gdb) print/x 1.5 127889 $1 = 0x1 127890 ... 127891 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242 127892 127893 The above change results in 417 regression test failures since the expected 127894 Power vector register output no longer match. 127895 127896 This patch updates the expected Altivec floating point register prints to 127897 the hexadecimal format for both big endian and little endian systems. The 127898 patch also fixes a formatting isue with the decimal_vector expected value 127899 assign statements. 127900 127901 The expected VSX vector_register1, vector_register1_vr, vector_register2, 127902 vector_register2_vr variables are updated to include the new float128 entry. 127903 Additionally, the comment in the vsx expect file about the initialization 127904 of the vs registers is updated. 127905 127906 The patch has been tested on Power 10, Power 8 LE and Power 8 BE. 127907 1279082022-04-26 John Baldwin <jhb@FreeBSD.org> 127909 127910 gdbsupport/pathstuff.h: #include <array> explicitly for std::array<> 127911 This fixes build breakage using clang with libc++ on FreeBSD where 127912 std::array<> is not yet declared when used by the path_join variadic 127913 function template. 127914 1279152022-04-26 GDB Administrator <gdbadmin@sourceware.org> 127916 127917 Automatic date update in version.in 127918 1279192022-04-25 Tom Tromey <tromey@adacore.com> 127920 127921 Do not put linkage names into .gdb_index 127922 This changes the .gdb_index writer to skip linkage names. This was 127923 always done historically (though somewhat implicitly). 127924 1279252022-04-25 Nick Clifton <nickc@redhat.com> 127926 127927 Emit a note warning the user that creating an executable stack because of a missing .note.GNU-stack section is deprecated. 127928 PR 29072 127929 bfd * elflink.c (bfd_elf_size_dynamic_sections): Display a note to the 127930 user that the current ehaviour of creating an executable stack 127931 because of a missing .note.GNU-stack section is deprecated and 127932 will be changed in a future release. 127933 127934 binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter 127935 out notes about the executable stacjk behaviour beign deprecated. 127936 127937 ld * testsuite/ld-elf/pr29072.b.warn: Update to include the note 127938 about the linker's behaviour being depreccated. 127939 1279402022-04-25 rupothar <rupesh.potharla@amd.com> 127941 127942 gdb/fortran: Support for assumed rank zero 127943 If a variable is passed to function in FORTRAN as an argument the 127944 variable is treated as an array with rank zero. GDB currently does 127945 not support the case for assumed rank 0. This patch provides support 127946 for assumed rank 0 and updates the testcase as well. 127947 127948 Without patch: 127949 Breakpoint 1, arank::sub1 (a=<error reading variable: 127950 failed to resolve dynamic array rank>) at assumedrank.f90:11 127951 11 PRINT *, RANK(a) 127952 (gdb) p a 127953 failed to resolve dynamic array rank 127954 (gdb) p rank(a) 127955 failed to resolve dynamic array rank 127956 127957 With patch: 127958 Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11 127959 11 PRINT *, RANK(a) 127960 (gdb) p a 127961 $1 = 0 127962 (gdb) p rank(a) 127963 $2 = 0 127964 1279652022-04-25 Lancelot SIX <lancelot.six@amd.com> 127966 127967 gdb/infrun: assert !step_over_info_valid_p in restart_threads 127968 While working in gdb/infrun.c:restart_threads, I was wondering what are 127969 the preconditions to call the function. It seems to me that 127970 !step_over_info_valid_p should be a precondition (i.e. if we are doing 127971 an inline step over breakpoint, we do not want to resume non stepping 127972 threads as one of them might miss the breakpoint which is temporally 127973 disabled). 127974 127975 To convince myself that this is true, I have added an assertion to 127976 enforce this, and got one regression in the testsuite: 127977 127978 FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error) 127979 127980 This call to restart_threads originates from handle_vfork_done which 127981 does not check if a step over is active when restarting other threads: 127982 127983 if (target_is_non_stop_p ()) 127984 { 127985 scoped_restore_current_thread restore_thread; 127986 127987 insert_breakpoints (); 127988 restart_threads (event_thread, event_thread->inf); 127989 start_step_over (); 127990 } 127991 127992 In this patch, I propose to: 127993 - Call start_step_over before restart_threads. If a step over is already 127994 in progress (as it is the case in the failing testcase), 127995 start_step_over return immediately, and there is no point in restarting 127996 all threads just to stop them right away for a step over breakpoint. 127997 - Only call restart_threads if no step over is in progress at this 127998 point. 127999 128000 In this patch, I also propose to keep the assertion in restart_threads 128001 to help enforce this precondition, and state it explicitly. 128002 128003 I have also checked all other places which call restart_threads, and 128004 they all seem to check that there is no step over currently active 128005 before doing the call. 128006 128007 As for infrun-related things, I am never completely sure I did not miss 128008 something. So as usual, all feedback and thoughts are very welcome. 128009 128010 Tested on x86_64-linux-gnu. 128011 128012 Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37 128013 1280142022-04-25 GDB Administrator <gdbadmin@sourceware.org> 128015 128016 Automatic date update in version.in 128017 1280182022-04-24 Andrew Burgess <aburgess@redhat.com> 128019 128020 gdb: move setbuf calls out of gdb_readline_no_editing_callback 128021 After this commit: 128022 128023 commit d08cbc5d3203118da5583296e49273cf82378042 128024 Date: Wed Dec 22 12:57:44 2021 +0000 128025 128026 gdb: unbuffer all input streams when not using readline 128027 128028 Issues were reported with some MS-Windows hosts, see the thread 128029 starting here: 128030 128031 https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html 128032 128033 Filed in bugzilla as: PR mi/29002 128034 128035 The problem seems to be that calling setbuf on terminal file handles 128036 is not always acceptable, see this mail for more details: 128037 128038 https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html 128039 128040 This commit does two things, first moving the setbuf calls out of 128041 gdb_readline_no_editing_callback so that we don't end up calling 128042 setbuf so often. 128043 128044 Then, for MS-Windows hosts, we don't call setbuf for terminals, this 128045 appears to resolve the issues that have been reported. 128046 128047 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002 128048 1280492022-04-24 GDB Administrator <gdbadmin@sourceware.org> 128050 128051 Automatic date update in version.in 128052 1280532022-04-23 GDB Administrator <gdbadmin@sourceware.org> 128054 128055 Automatic date update in version.in 128056 1280572022-04-22 Simon Marchi <simon.marchi@efficios.com> 128058 128059 gdb: handle_no_resumed: only update thread list of event target 128060 When running: 128061 128062 $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver" 128063 128064 I get: 128065 128066 target remote localhost:2347^M 128067 Remote debugging using localhost:2347^M 128068 Reading symbols from /lib64/ld-linux-x86-64.so.2...^M 128069 Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M 128070 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M 128071 (gdb) continue^M 128072 Continuing.^M 128073 Cannot execute this command while the target is running.^M 128074 Use the "interrupt" command to stop the target^M 128075 and then try again.^M 128076 (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started 128077 128078 The test does: 128079 128080 - Connect to a remote target with inferior 2, continue and stop on the 128081 all_started function 128082 - Connect to a separate remote target / GDBserver instance with inferior 1, 128083 continue and (expect to) stop on the all_started function 128084 128085 The failure seen above happens when trying to continue inferior 1. 128086 128087 What happens is: 128088 128089 - GDB tells inferior 1's remote target to continue 128090 - We go into fetch_inferior_event, try to get an event at random from 128091 the targets 128092 - do_target_wait happens to pick inferior 2's target 128093 - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense: 128094 inferior 2 is stopped, that target has no resumed thread 128095 - handle_no_resumed tries to update the thread list of all targets: 128096 128097 for (auto *target : all_non_exited_process_targets ()) 128098 { 128099 switch_to_target_no_thread (target); 128100 update_thread_list (); 128101 } 128102 128103 - When trying to update the thread list of inferior 1's target, it hits 128104 the "Cannot execute this command while the target is running" error. 128105 This target is working in "remote all-stop" mode, and it is currently 128106 waiting for a stop reply, so it can't send packets to update the 128107 thread list at this time. 128108 128109 To handle the problem described in the comment in handle_no_resumed, I 128110 don't think it is necessary to update the thread list of all targets, 128111 but only the event target. That comment describes a kind of race 128112 condition where some target reports a breakpoint hit for a thread and 128113 then its last remaining resumed thread exits, so sends a "no resumed" 128114 event. If we ended up resuming the thread that hit a breakpoint, we 128115 want to ignore the "no resumed" and carry on. 128116 128117 But I don't really see why we need to update the thread list on the 128118 other targets. I can't really articulate this, it's more a gut feeling, 128119 maybe I just fail to imagine the situation where this is needed. But 128120 here is the patch anyway, so we can discuss it. The patch changes 128121 handle_no_resumed to only update the thread list of the event target. 128122 This fixes the test run shown above. 128123 128124 The way I originally tried to fix this was to make 128125 remote_target::update_thread_list return early if the target is 128126 currently awaiting a stop reply, since there's no way it can update the 128127 thread list at that time. But that felt more like papering over the 128128 problem. I then thought that we probably shouldn't be asking the target 128129 to update the thread list unnecessarily. 128130 128131 Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58 128132 1281332022-04-22 Simon Marchi <simon.marchi@polymtl.ca> 128134 128135 gdbserver/linux: free process_info_private and arch_process_info when failing to attach 128136 Running 128137 128138 $ ../gdbserver/gdbserver --once --attach :1234 539436 128139 128140 with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents 128141 attaching) shows that we fail to free some platform-specific objects 128142 tied to the process_info (process_info_private and arch_process_info): 128143 128144 Direct leak of 32 byte(s) in 1 object(s) allocated from: 128145 #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 128146 #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100 128147 #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122 128148 #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426 128149 #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132 128150 #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308 128151 #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949 128152 #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084 128153 #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f) 128154 128155 Indirect leak of 56 byte(s) in 1 object(s) allocated from: 128156 #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 128157 #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100 128158 #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122 128159 #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723 128160 #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428 128161 #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132 128162 #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308 128163 #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949 128164 #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084 128165 #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f) 128166 128167 Those objects are deleted by linux_process_target::mourn, but that is 128168 not called if we fail to attach, we only call remove_process. I 128169 initially fixed this by making linux_process_target::attach call 128170 linux_process_target::mourn on failure (before calling error). But this 128171 isn't done anywhere else (including in GDB) so it would just be 128172 confusing to do things differently here. 128173 128174 Instead, add a linux_process_target::remove_linux_process helper method 128175 (which calls remove_process), and call that instead of remove_process in 128176 the Linux target. Move the free-ing of the extra data from the mourn 128177 method to that new method. 128178 128179 Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85 128180 1281812022-04-22 Andrew Burgess <aburgess@redhat.com> 128182 128183 gdb: handle bracketed-paste-mode and EOF correctly 128184 This commit replaces an earlier commit that worked around the issues 128185 reported in bug PR gdb/28833. 128186 128187 The previous commit just implemented a work around in order to avoid 128188 the worst results of the bug, but was not a complete solution. The 128189 full solution was considered too risky to merge close to branching GDB 128190 12. This improved fix has been applied after GDB 12 branched. See 128191 this thread for more details: 128192 128193 https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html 128194 128195 This commit replaces this earlier commit: 128196 128197 commit 74a159a420d4b466cc81061c16d444568e36740c 128198 Date: Fri Mar 11 14:44:03 2022 +0000 128199 128200 gdb: work around prompt corruption caused by bracketed-paste-mode 128201 128202 Please read that commit for a full description of the bug, and why is 128203 occurs. 128204 128205 In this commit I extend GDB to use readline's rl_deprep_term_function 128206 hook to call a new function gdb_rl_deprep_term_function. From this 128207 new function we can now print the 'quit' message, this replaces the 128208 old printing of 'quit' in command_line_handler. Of course, we only 128209 print 'quit' in gdb_rl_deprep_term_function when we are handling EOF, 128210 but thanks to the previous commit (to readline) we now know when this 128211 is. 128212 128213 There are two aspects of this commit that are worth further 128214 discussion, the first is in the new gdb_rl_deprep_term_function 128215 function. In here I have used a scoped_restore_tmpl to disable the 128216 readline global variable rl_eof_found. 128217 128218 The reason for this is that, in rl_deprep_terminal, readline will 128219 print an extra '\n' character before printing the escape sequence to 128220 leave bracketed paste mode. You might then think that in the 128221 gdb_rl_deprep_term_function function, we could simply print "quit" and 128222 rely on rl_deprep_terminal to print the trailing '\n'. However, 128223 rl_deprep_terminal only prints the '\n' when bracketed paste mode is 128224 on. If the user has turned this feature off, no '\n' is printed. 128225 This means that in gdb_rl_deprep_term_function we need to print 128226 "quit" when bracketed paste mode is on, and "quit\n" when bracketed 128227 paste mode is off. 128228 128229 We could absolutely do that, no problem, but given we know how 128230 rl_deprep_terminal is implemented, it's easier (I think) to just 128231 temporarily clear rl_eof_found, this prevents the '\n' being printed 128232 from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can 128233 now always print "quit\n" and this works for all cases. 128234 128235 The second issue that should be discussed is backwards compatibility 128236 with older versions of readline. GDB can be built against the system 128237 readline, which might be older than the version contained within GDB's 128238 tree. If this is the case then the system readline might not contain 128239 the fixes needed to support correctly printing the 'quit' string. 128240 128241 To handle this situation I have retained the existing code in 128242 command_line_handler for printing 'quit', however, this code is only 128243 used now if the version of readline we are using doesn't not include 128244 the required fixes. And so, if a user is using an older version of 128245 readline, and they have bracketed paste mode on, then they will see 128246 the 'quit' sting printed on the line below the prompt, like this: 128247 128248 (gdb) 128249 quit 128250 128251 I think this is the best we can do when someone builds GDB against an 128252 older version of readline. 128253 128254 Using a newer version of readline, or the patched version of readline 128255 that is in-tree, will now give a result like this in all cases: 128256 128257 (gdb) quit 128258 128259 Which is what we want. 128260 128261 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833 128262 1282632022-04-22 Andrew Burgess <aburgess@redhat.com> 128264 128265 readline: back-port changes needed to properly detect EOF 128266 This commit is a partial back-port of this upstream readline commit: 128267 128268 commit 002d31aa5f5929eb32d0e0e2e8b8d35d99e59961 128269 Author: Chet Ramey <chet.ramey@case.edu> 128270 Date: Thu Mar 3 11:11:47 2022 -0500 128271 128272 add rl_eof_found to public API; fix pointer aliasing problems \ 128273 with history-search-backward; fix a display problem with \ 128274 runs of invisible characters at the end of a physical \ 128275 screen line 128276 128277 I have only pulled in the parts of this commit that relate to the new 128278 rl_eof_found global, and the RL_STATE_EOF state flag. These changes 128279 are needed in order to fix PR cli/28833, and are discussed in this 128280 thread to the bug-readline mailing list: 128281 128282 https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html 128283 128284 The above commit is not yet in any official readline release, but my 128285 hope is that now it has been merged into the readline tree it should 128286 be safe enough to back port this fix to GDB's tree. 128287 128288 At some point in the future we will inevitably want to roll forward 128289 the version of readline that we maintain in the binutils-gdb 128290 repository. When that day comes the changes in this commit can be 128291 replaced with the latest upstream readline code, as I have not changed 128292 the meaning of this code at all from what is in upstream readline. 128293 128294 This commit alone does not fix the PR cli/28833 issue, for that see 128295 the next commit, which changes GDB itself. 128296 128297 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833 128298 1282992022-04-22 Andrew Burgess <aburgess@redhat.com> 128300 128301 gdb: improved EOF handling when using readline 7 128302 In this commit: 128303 128304 commit a6b413d24ccc5d76179bab866834e11fd6fec294 128305 Date: Fri Mar 11 14:44:03 2022 +0000 128306 128307 gdb: work around prompt corruption caused by bracketed-paste-mode 128308 128309 a change was made to GDB to work around bug PR gdb/28833. The 128310 consequence of this work around is that, when bracketed paste mode is 128311 enabled in readline, and GDB is quit by sending EOF, then the output 128312 will look like this: 128313 128314 (gdb) 128315 quit 128316 128317 The ideal output, which is what we get when bracketed paste mode is 128318 off, is this: 128319 128320 (gdb) quit 128321 128322 The reason we need to make this change is explained in the original 128323 commit referenced above. What isn't mentioned in the above commit, is 128324 that the change that motivated this work around was only added in 128325 readline 8, older versions of readline don't require the change. 128326 128327 In later commits in this series I will add a fix to GDB's in-tree copy 128328 of readline (this fix is back-ported from upstream readline), and then 128329 I will change GDB so that, when using the (patched) in-tree readline, 128330 we can have the ideal output in all cases. 128331 128332 However, GDB can be built against the system readline. When this is 128333 done, and the system readline is version 8, then we will still have to 128334 use the work around (two line) style output. 128335 128336 But, if GDB is built against the system readline, and the system 128337 readline is an older version 7 readline, then there's no reason why we 128338 can't have the ideal output, after all, readline 7 doesn't include the 128339 change that we need to work around. 128340 128341 This commit changes GDB so that, when using readline 7 we get the 128342 ideal output in all cases. This change is trivial (a simple check 128343 against the readline version number) so I think this should be fine to 128344 include. 128345 128346 For testing this commit, you need to configure GDB including the 128347 '--with-system-readline' flag, and build GDB on a system that uses 128348 readline 7, for example 'Ubuntu 18.04'. Then run the test 128349 'gdb.base/eof-exit.exp', you should expect everything to PASS. 128350 128351 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833 128352 1283532022-04-22 Simon Marchi <simon.marchi@efficios.com> 128354 128355 gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp 128356 This test sometimes fail like this: 128357 128358 info threads^M 128359 Id Target Id Frame ^M 128360 11.12 process 2270719 Couldn't get registers: No such process.^M 128361 (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left 128362 [Inferior 11 (process 2270719) exited normally]^M 128363 info inferiors^M 128364 Num Description Connection Executable ^M 128365 * 1 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M 128366 11 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M 128367 (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited) 128368 128369 I can get it to fail quite reliably by pinning it to a core: 128370 128371 $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp" 128372 128373 The previous attempt at fixing this was: 128374 128375 https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html 128376 128377 What we see is part due to a possible unfortunate ordering of events 128378 given by the kernel, and what could be considered a bug in GDB. 128379 128380 The test program makes a number of forks, waits them all, then exits. 128381 Most of the time, GDB will get and process the exit event for inferior 1 128382 after the exit events of all the children. But this is not guaranteed. 128383 After the last child exits and is waited by the parent, the parent can 128384 exit quickly, such that GDB collects from the kernel the exit events for 128385 the parent and that child at the same time. It then chooses one event 128386 at random, which can be the event for the parent. This will result in 128387 the parent appearing to exit before its child. There's not much we can 128388 do about it, so I think we have to adjust the test to cope. 128389 128390 After expect has seen the "exited normally" notification for inferior 1, 128391 it immediately does an "info thread" that it expects to come back empty. 128392 But at this point, GDB might not have processed inferior 11's (the last 128393 child) exit event, so it will look like there is still a thread. Of 128394 course that thread is dead, we just don't know it yet. But that makes 128395 the "no thread" test fail. If the test waited just a bit more for the 128396 "exited normally" notification for inferior 11, then the list of threads 128397 would be empty. 128398 128399 So, first change, make the test collect all the "exited normally" 128400 notifications for all inferiors before proceeding, that should ensure we 128401 see an empty thread list. That would fix the first FAIL above. 128402 128403 However, we would still have the second FAIL, as we expect inferior 11 128404 to not be there, it should have been deleted automatically. Inferior 11 128405 is normally deleted when prune_inferiors is called. That is called by 128406 normal_stop, which is only called by fetch_inferior_event only if the 128407 event thread completed an execution command FSM (thread_fsm). But the 128408 FSM for the continue command completed when inferior 1 exited. At that 128409 point inferior 11 was not prunable, as it still had a thread. When 128410 inferior 11 exits, prune_inferiors is not called. 128411 128412 I think that can be considered a GDB bug. From the user point of view, 128413 there's no reason why in one case inferior 11 would be deleted and not 128414 in the other case. 128415 128416 This patch makes the somewhat naive change to call prune_inferiors in 128417 fetch_inferior_event, so that it is called in this case. It is placed 128418 at this particular point in the function so that it is called after the 128419 user inferior / thread selection is restored. If it was called before 128420 that, inferior 11 wouldn't be pruned, because it would still be the 128421 current inferior. 128422 128423 Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a 128424 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272 128425 1284262022-04-22 Tom Tromey <tromey@adacore.com> 128427 128428 Un-break the coff-pe-read.c build 128429 This fixes a build breakage in my recent coff-pe-read.c change. 128430 128431 I'm sorry about this. I don't understand how it happened, because I 128432 definitely built and tested the series on Windows, and I didn't change 128433 it before pushing. Something must have gone wrong on the Windows 128434 build, but I don't know what. I'll investigate and and re-test to be 128435 sure. 128436 1284372022-04-22 Tom Tromey <tromey@adacore.com> 128438 128439 More const use and alloca avoidance in coff-pe-read.c 128440 This changes another function in coff-pe-read.c to use 'const' more, 128441 and to avoid the use of alloca by instead using std::string. 128442 128443 Use std::string in coff-pe-read.c 128444 coff-pe-read.c uses xsnprintf and alloca, but using std::string is 128445 better, and just as easy. In general I think alloca is something to 128446 be avoided, and unbounded uses especially so. 128447 128448 Remove a const-removing cast from coff-pe-read.c 128449 coff-pe-read.c casts away const at one spot, but this is easily 128450 replaced by calling bfd_get_filename directly in a couple of debugging 128451 prints. 128452 128453 Simplify BFD section iteration in coff-pe-read.c 128454 coff-pe-read.c iterates over BFD sections using bfd_map_over_sections, 128455 but it's much simpler to use a for-each loop. This allows for the 128456 removal of helper functions and types. 128457 1284582022-04-22 Tom Tromey <tromey@adacore.com> 128459 128460 Fix method naming bug in new DWARF indexer 128461 Pedro pointed out that gdb-add-index is much slower with the new DWARF 128462 indexer. He also noticed that, in some cases, the generated 128463 .gdb_index would have the wrong fully-qualified name for a method. 128464 128465 I tracked this down to a bug in the indexer. If a type could have 128466 methods but was marked as a declaration, the indexer was ignoring it. 128467 However, this meant that the internal map to find the qualified name 128468 was not updated for this container. 128469 1284702022-04-22 Christoph Muellner <cmuellner@gcc.gnu.org> 128471 128472 RISC-V: Add missing DECLARE_INSNs for Zicbo{m,p,z} 128473 The recently added support for the Zicbo{m,p,z} extensions did not 128474 include DECLARE_INSN() declarations for the instructions. 128475 These declarations are needed by GDB's instruction detection code. 128476 This patch adds them. 128477 1284782022-04-22 GDB Administrator <gdbadmin@sourceware.org> 128479 128480 Automatic date update in version.in 128481 1284822022-04-21 Carl Love <cel@us.ibm.com> 128483 128484 Fix for gdb.base/solib-search.exp test. 128485 The variable right_lib_flags is not being set correctly to define RIGHT. 128486 The value RIGHT is needed to force the address of the library functions 128487 lib1_func3 and lib2_func4 to occur at different address in the wrong and 128488 right libraries. 128489 128490 With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur 128491 at different addresses the test runs correctly on Powerpc. 128492 128493 The test needs the lib2 addresses to be different in the right and 128494 wrong cases. That is the point of introducing function lib2_spacer 128495 with the ifdef RIGHT compiler directive. 128496 128497 On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the 128498 dynamic linker to move the addresses of the library. You can also get 128499 the same effect on PowerPC but you must use a value much larger than 128500 8192. 128501 128502 The key thing is that the test was not properly setting RIGHT to 128503 defined to get the lib2_spacer function on Intel and Powerpc. 128504 128505 Without the patch, we have the Intel backtrace for the bad libraries: 128506 128507 backtrace 128508 #0 break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30 128509 #1 0x00007ffff7fae156 in ?? () 128510 #2 0x00007fffffffc150 in ?? () 128511 #3 0x00007ffff7fbb156 in ?? () 128512 #4 0x00007fffffffc160 in ?? () 128513 #5 0x00007ffff7fae146 in ?? () 128514 #6 0x00007fffffffc170 in ?? () 128515 #7 0x00007ffff7fbb146 in ?? () 128516 #8 0x00007fffffffc180 in ?? () 128517 #9 0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23 128518 Backtrace stopped: previous frame inner to this frame (corrupt stack?) 128519 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection) 128520 128521 The backtrace on Intel with the good libraries is: 128522 128523 backtrace 128524 #0 break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30 128525 #1 0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49 128526 #2 0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49 128527 #3 0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30 128528 #4 0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30 128529 #5 0x0000555555555156 in main () at /...solib-search.c:23 128530 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) 128531 PASS: gdb.base/solib-search.exp: backtrace (with right libs) 128532 128533 In one case the backtrace is correct and the other it 128534 is wrong on Intel. This is due to the fact that the ARRAY_SIZE caused 128535 the dynamic linker to move the library function addresses around. I 128536 believe it has to do with the default size of the data and code 128537 sections used by the dynamic linker. 128538 128539 So without the patch the backtrace on PowerPC looks like: 128540 128541 backtrace 128542 #0 break_here () at /.../solib-search.c:30 128543 #1 0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49 128544 #2 0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49 128545 #3 0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30 128546 #4 0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30 128547 #5 0x000000001000074c in main () at /.../solib-search.c:23 128548 128549 for both the good and bad libraries. 128550 128551 The patch fixes defining RIGHT in solib-search-lib1.c and solib-search- 128552 lib2.c. Note, without the patch the lib1_spacer and lib2_spacer 128553 functions do not show up in the object dump of the Intel or Powerpc 128554 libraries as it should. The patch fixes that by making sure RIGHT gets 128555 defined. 128556 128557 Now with the patch the backtrace for the bad library on PowerPC looks 128558 like: 128559 128560 backtrace 128561 #0 break_here () at /.../solib-search.c:30 128562 #1 0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so 128563 Backtrace stopped: frame did not save the PC 128564 128565 And the backtrace for the good libraries on PowerPC looks like: 128566 128567 backtrace 128568 #0 break_here () at /.../solib-search.c:30 128569 #1 0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49 128570 #2 0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49 128571 #3 0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30 128572 #4 0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30 128573 #5 0x000000001000074c in main () at /.../solib-search.c:23 128574 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) 128575 PASS: gdb.base/solib-search.exp: backtrace (with right libs) 128576 128577 The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not 128578 sufficient to cause the dymanic linker to allocate the libraries at 128579 different addresses. I don't claim to understand the specifics of how 128580 the dynamic linker works and what the default size is for the data and 128581 code sections are. My guess is by default PowerPC allocates a larger 128582 data size by default, which is large enough to hold array[8192]. The 128583 default size of the data section allocated by the dynamic linker on 128584 Intel is not large enough to hold array[8192] thus causing the code 128585 section on Intel to have to move when the large array is defined. 128586 128587 Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause 128588 the library addresses to occur at different addresses as the larger 128589 data section forces the code section to a different address. That was 128590 actually my original fix for the program until I spoke with Doug Evans 128591 who originally wrote the test. Doug noticed that RIGHT was not getting 128592 defined as he originally intended in the test. 128593 128594 With the patch to fix the definition of RIGHT, PowerPC has a bad and a 128595 good backtrace because the address of lib1_func3 and lib2_func4 both 128596 move because lib1_spacer and lib2_spacer are now defined 128597 before lib1_func3 and lib2_func4. 128598 128599 Without the patch, the lib1_spacer and lib2_spacer function doesn't show 128600 up in the binary for the correct or incorrect library on Intel or PowerPC. 128601 With the patch, RIGHT gets defined as originally intended for the test on 128602 both architectures and lib1_spacer and lib2_spacer function show up in the 128603 binaries on both architectures changing the other function addresses as 128604 intended thus causing the test work as intended on PowerPC. 128605 1286062022-04-21 Simon Marchi <simon.marchi@efficios.com> 128607 128608 gdb/dwarf: remove line_header::header_length field 128609 This can be a local in dwarf_decode_line_header. 128610 128611 Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af 128612 1286132022-04-21 Simon Marchi <simon.marchi@efficios.com> 128614 128615 gdb/dwarf: remove line_header::total_length field 128616 This doesn' have to be a field, it can simply be a local variable in 128617 dwarf_decode_line_header. Name the local variable "unit_length", since 128618 that's what the field in called in DWARF 4 and 5. It's always easier to 128619 follow the code with the standard on the side when we use the same 128620 terminology. 128621 128622 Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633 128623 1286242022-04-21 Simon Marchi <simon.marchi@efficios.com> 128625 128626 gdb/testsuite: fix "set temporary breakpoint" DUPLICATEs 128627 Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at 128628 expected location") introduced some DUPLICATEs in MI tests using 128629 mi_continue_to_line, for example: 128630 128631 DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint 128632 128633 These test names were previously differentiated by the location passed 128634 to mi_continue_to_line. Since the location can contain a path, that 128635 commit removed the location from the test name, in favor of a hardcoded 128636 string "set temporary breakpoint", hence removing the differentiator. 128637 128638 mi_continue_to_line receives a "test" parameter, containing a test 128639 name. Add a "with_test_prefix" with that name, so that all tests 128640 recorded during mi_continue_to_line have this in their name. 128641 128642 mi_continue_to_line passes that "test" string to mi_get_stop_line, that 128643 is a bit superfluous. mi_get_stop_line only uses that string in case of 128644 failures (it doesn't record a pass if everything goes fine). Since it's 128645 not crucial, just remove it, and adjust all callers. 128646 128647 Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate 128648 the multiple calls to mi_run_inline_test (which calls 128649 mi_continue_to_line). 128650 128651 Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74 128652 1286532022-04-21 Tom Tromey <tromey@adacore.com> 128654 128655 Always use dwarf2_initialize_objfile 128656 Internally we noticed that some tests would fail like so on Windows: 128657 128658 warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges. 128659 128660 Debugging showed that, in fact, a second CU was being created at this 128661 offset. We tracked this down to the fact that, while the ELF reader 128662 is careful to re-use the per-BFD data, other readers are not, and 128663 could re-read the DWARF data multiple times. 128664 128665 However, since the change to allow an objfile to have multiple "quick 128666 symbol" implementations, there's no reason for this approach -- it's 128667 safe and easy for all symbol readers to reuse the per-BFD data when 128668 reading DWARF. 128669 128670 This patch implements this idea, simplifying dwarf2_build_psymtabs and 128671 making it private, and then switching to dwarf2_initialize_objfile as 128672 the sole way to start the DWARF reader. 128673 128674 Note that, while I think the call to dwarf2_build_frame_info in 128675 machoread.c is also obsolete, I haven't attempted to remove it here. 128676 1286772022-04-21 Andrew Burgess <aburgess@redhat.com> 128678 128679 gdb: fix 'remote show FOO-packet' aliases 128680 The following behaviour was observed in GDB: 128681 128682 (gdb) show remote X-packet 128683 Support for the `p' packet is auto-detected, currently unknown. 128684 128685 Note the message mentions the 'p' packet. This is a regression since 128686 this commit: 128687 128688 commit 8579fd136a614985bd27f20539c7bb7c5a51287d 128689 Date: Mon Nov 8 14:58:46 2021 +0000 128690 128691 gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr 128692 128693 Before this commit the behaviour was: 128694 128695 (gdb) show remote X-packet 128696 Support for the `X' packet is auto-detected, currently unknown. 128697 128698 The problem was caused by a failed attempt to ensure that some 128699 allocated strings were deleted when GDB exits. The code in the above 128700 commit attempted to make use of 'static' to solve this problem, 128701 however, the solution was just wrong. 128702 128703 In this new commit I instead allocate a static vector into which all 128704 the allocated strings are stored, this ensures the strings are 128705 released when GDB exits (which makes output from tools like valgrind 128706 cleaner), but each string within the vector can be unique, which fixes 128707 the regression. 128708 1287092022-04-21 Simon Marchi <simon.marchi@efficios.com> 128710 128711 gdbsupport: add path_join function 128712 In this review [1], Eli pointed out that we should be careful when 128713 concatenating file names to avoid duplicated slashes. On Windows, a 128714 double slash at the beginning of a file path has a special meaning. So 128715 naively concatenating "/" and "foo/bar" would give "//foo/bar", which 128716 would not give the desired results. We already have a few spots doing: 128717 128718 if (first_path ends with a slash) 128719 path = first_path + second_path 128720 else 128721 path = first_path + slash + second_path 128722 128723 In general, I think it's nice to avoid superfluous slashes in file 128724 paths, since they might end up visible to the user and look a bit 128725 unprofessional. 128726 128727 Introduce the path_join function that can be used to join multiple path 128728 components together (along with unit tests). 128729 128730 I initially wanted to make it possible to join two absolute paths, to 128731 support the use case of prepending a sysroot path to a target file path, 128732 or the prepending the debug-file-directory to a target file path. But 128733 the code in solib_find_1 shows that it is more complex than this anyway 128734 (for example, when the right hand side is a Windows path with a drive 128735 letter). So I don't think we need to support that case in path_join. 128736 That also keeps the implementation simpler. 128737 128738 Change a few spots to use path_join to show how it can be used. I 128739 believe that all the spots I changed are guarded by some checks that 128740 ensure the right hand side operand is not an absolute path. 128741 128742 Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also 128743 ran the new unit-test there. 128744 128745 [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html 128746 128747 Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752 128748 1287492022-04-21 Lancelot SIX <lancelot.six@amd.com> 128750 128751 gdb_spawn_attach_cmdline: use unsupported instead of untested 128752 In a previous commit (b750766ac96: gdb/testsuite: Introduce and use 128753 gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB 128754 attach to the process because of ptrace restrictions (operation not 128755 permitted), the proc issues UNTESTED. This should really be 128756 UNSUPPORTED, as it is done in gdb_attach. 128757 128758 This patch fixes this oversight. 128759 128760 Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d 128761 1287622022-04-21 Enze Li <lienze2010@hotmail.com> 128763 128764 gdb/testsuite: add binary testcases to py-format-string.exp 128765 We currently only test decimal and hexadecimal for the 128766 gdb.Value.format_string() interface, this patch adds testcases for 128767 binary format. 128768 128769 Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413"). 128770 1287712022-04-21 Pedro Alves <pedro@palves.net> 128772 128773 gdb.debuginfod/fetch_src_and_symbols.exp: Fix "notice empty URL" test 128774 The gdb_test_multiple pattern for the "notice empty URL" test in 128775 gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt. 128776 Fix it by using -re -wrap. 128777 128778 Also, by using "confirm off", the message GDB prints if Debuginfod 128779 downloading is available doesn't contain "Enable debuginfod" any 128780 longer. E.g.: 128781 128782 ~~~ 128783 (gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols 128784 Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols... 128785 128786 This GDB supports auto-downloading debuginfo from the following URLs: 128787 <http://localhost:123> 128788 Enable debuginfod for this session? (y or [n]) 128789 ~~~ 128790 128791 ~~~ 128792 (gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols 128793 Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols... 128794 128795 This GDB supports auto-downloading debuginfo from the following URLs: 128796 <http://127.0.0.1:8000> 128797 <127.0.0.1:8000> 128798 Debuginfod has been disabled. 128799 To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. 128800 (No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols) 128801 (gdb) 128802 ~~~ 128803 128804 I handled that correctly in the other tests that use test_urls, but 128805 had forgotten to update the "notice empty URL" one. 128806 128807 Change-Id: I00040c83466e1494b3875574eb009c571a1504bf 128808 1288092022-04-21 Alan Modra <amodra@gmail.com> 128810 128811 prune .note.GNU-stack warning from testsuite 128812 binutils/ 128813 * testsuite/lib/binutils-common.exp (prune_warnings_extra): Remove 128814 .note.GNU-stack warning. 128815 (run_dump_test): Call prune_warnings for ld and objcopy output. 128816 ld/ 128817 * testsuite/ld-elf/elf.exp: Disable prune_warnings_extra temporarily 128818 around test for absent .note.GNU-stack 128819 * testsuite/ld-cris/globsymw2.s, 128820 * testsuite/ld-cris/warn3.d: Modify "is not implemented" message 128821 to avoid dejagnu prune_warnings. 128822 128823 ld testsuite xcoff XPASS 128824 * testsuite/ld-scripts/defined5.d: Don't xfail xcoff targets. 128825 128826 Delete unused COFF gas macro 128827 * config/obj-coff.h (sy_obj): Don't define. 128828 (OBJ_SYMFIELD_TYPE): Revise comments. 128829 1288302022-04-21 GDB Administrator <gdbadmin@sourceware.org> 128831 128832 Automatic date update in version.in 128833 1288342022-04-20 Aaron Merey <amerey@redhat.com> 128835 128836 gdb/debuginfod: Prevent out_of_range exception 128837 Trailing whitespace in the string of debuginfod URLs causes an 128838 out_of_range exception during the printing of URLs for the first 128839 use notice. 128840 128841 To fix this, stop printing URLs when the substring to be printed 128842 consists only of whitespace. 128843 128844 Also add first use notice testcases. 128845 128846 Co-Authored-By: Pedro Alves <pedro@palves.net> 128847 1288482022-04-20 Lancelot SIX <lancelot.six@amd.com> 128849 128850 gdb/testsuite: Introduce and use gdb_spawn_attach_cmdline 128851 Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add 128852 new gdb_attach to check "attach" command", this commit proposes to 128853 introduce the gdb_spawn_attach_cmdline helper and use it in 128854 gdb.base/attach.exp. 128855 128856 This helper starts GDB and adds the "--pid=$PID" argument. 128857 128858 Also note that both the original and new implementation use 128859 gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn. 128860 This makes sure that we use $INTERNAL_GDBFLAGS, which by default already 128861 contain "-iex \"set height 0\" -iex \"set width 0\"". To avoid 128862 repetition of those arguments, gdb_spawn_attach_cmdline does not repeat 128863 those arguments. 128864 128865 To maintain a behavior similat to what gdb.base/attach.exp used to do, 128866 gdb_spawn_attach_cmdline keeps the -quiet flag. 128867 128868 Tested on x86_64-gnu-linux 128869 128870 Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358 128871 1288722022-04-20 Tom Tromey <tom@tromey.com> 128873 128874 Replace symbol_symtab with symbol::symtab 128875 This turns symbol_symtab into a method on symbol. It also replaces 128876 symbol_set_symtab with a method. 128877 128878 Replace symbol_arch with symbol::arch 128879 This turns symbol_arch into a method on symbol. 128880 128881 Replace symbol_objfile with symbol::objfile 128882 This turns symbol_objfile into a method on symbol. 128883 128884 Remove symbol::aclass_index 128885 Symbols have an aclass_index method, but this isn't needed, because 128886 the aclass index isn't useful outside of the symbol implementation. 128887 128888 Use array_view for symbol_impls 128889 It seemed to me that using array_view for symbol_impls would give a 128890 bit more error checking, at least when gdb is built in libstdc++ debug 128891 mode. 128892 128893 Add accessors for symbol's artificial field 128894 For a series I'm experimenting with, it was handy to hide a symbol's 128895 "artificial" field behind accessors. This patch is the result. 128896 128897 Unify the DWARF index holders 128898 The dwarf2_per_bfd object has a separate field for each possible kind 128899 of index. Until an earlier patch in this series, two of these were 128900 even derived from a common base class, but still had separate slots. 128901 This patch unifies all the index fields using the common base class 128902 that was introduced earlier in this series. This makes it more 128903 obvious that only a single index can be active at a time, and also 128904 removes some code from dwarf2_initialize_objfile. 128905 128906 Add an ad hoc version check to dwarf_scanner_base 128907 Some generic code in the DWARF reader has a special case for older 128908 versions of .gdb_index. This patch adds an ad hoc version check 128909 method so that these spots can work without specific knowledge of 128910 which index is in use. 128911 128912 Simplify version check in dw2_symtab_iter_next 128913 This simplifies the index versio check in dw2_symtab_iter_next, by 128914 passing a reference to the index object to this function. This avoids 128915 an indirection via the per_bfd object. 128916 128917 Introduce and use dwarf_scanner_base 128918 This introduces dwarf_scanner_base, a base class for all the index 128919 readers in the DWARF code. Then, it changes both mapped_index_base 128920 and cooked_index_vector to derive from this new base class. 128921 128922 Introduce readnow_functions 128923 This introduces readnow_functions, a new subclass of 128924 dwarf2_base_index_functions, and changes the DWARF reader to use it. 128925 This lets us drop the "index is NULL" hack from the gdb index code. 128926 128927 Remove some "OBJF_READNOW" code from dwarf2_debug_names_index 128928 The dwarf2_debug_names_index code treats a NULL debug_names_table as 128929 if it were from OBJF_READNOW. However, this trick is only done for 128930 gdb_index, never for debug_names -- see dwarf2_initialize_objfile. 128931 128932 Let mapped index classes create the quick_symbol_functions object 128933 This changes the mapped index classes to create the 128934 quick_symbol_functions objects. This is a step toward having a more 128935 abstract interface to mapped indices. 128936 128937 Give mapped_index_base a virtual destructor 128938 This changes mapped_index_base to have a virtual destructor, so it can 128939 be destroyed via its base class. 128940 128941 Move mapped_index_base to new header file 128942 This moves mapped_index_base and the helper struct name_component to a 128943 new header file in gdb/dwarf2/. 128944 1289452022-04-20 Jan Beulich <jbeulich@suse.com> 128946 128947 x86: reject all invalid SAE variants 128948 So far an SAE-only specifier was accepted for static-rounding insns, 128949 while SAE-only insns didn't accept static rounding specifiers. If 128950 anything it would make sense the other way around, allowing SAE-only 128951 insns to have the (ignored) rounding mode specified individually rather 128952 than globally via -mevexrcig=. But for now make things match the SDM. 128953 1289542022-04-20 Alan Modra <amodra@gmail.com> 128955 128956 Re: xcoff: implement linker relaxation 128957 * xcofflink.c (xcoff_stub_csect_name): Increase buffer size. 128958 (xcoff_stub_get_csect_in_range, xcoff_build_one_stub): Whitespace. 128959 (bfd_xcoff_size_stubs): Cast PRIx64 arg to required type. 128960 Don't use freed stub_name. 128961 128962 Revert "as: Reject unknown -gXXX option" testsuite 128963 This reverts the test committed as part of 6ea673e2d6. 128964 1289652022-04-20 Cl?ment Chigot <clement.chigot@atos.net> 128966 128967 xcoff: implement linker relaxation 128968 bfd/ChangeLog: 128969 128970 * coff-rs6000.c (xcoff_reloc_type_noop): Add info argument. 128971 (xcoff_reloc_type_fail): Likewise. 128972 (xcoff_reloc_type_pos): Likewise. 128973 (xcoff_reloc_type_neg): Likewise. 128974 (xcoff_reloc_type_rel): Likewise. 128975 (xcoff_reloc_type_toc): Likewise. 128976 (xcoff_reloc_type_ba): Likewise. 128977 (xcoff_reloc_type_crel): Likewise. 128978 (xcoff_reloc_type_tls): Likewise. 128979 (xcoff_reloc_type_br): Add stub handler. 128980 (xcoff_ppc_relocate_section): Add info to 128981 xcoff_calculate_relocation. 128982 (xcoff_stub_indirect_call_code): New constant. 128983 (xcoff_stub_shared_call_code): Likewise. 128984 (bfd_xcoff_backend_data): Add stub code fields. 128985 (bfd_pmac_xcoff_backend_data): Likewise. 128986 * coff64-rs6000.c (xcoff64_reloc_type_br): Add stub handler. 128987 (xcoff64_ppc_relocate_section): Add info to 128988 xcoff64_calculate_relocation. 128989 (xcoff64_stub_indirect_call_code): New constant. 128990 (xcoff64_stub_shared_call_code): Likewise. 128991 (bfd_xcoff_backend_data): Add stub code fields. 128992 (bfd_xcoff_aix5_backend_data): Likewise. 128993 * libxcoff.h (struct xcoff_backend_data_rec): Add stub fields. 128994 (bfd_xcoff_stub_indirect_call_code): New define. 128995 (bfd_xcoff_stub_indirect_call_size): New define. 128996 (bfd_xcoff_stub_shared_call_code): New define. 128997 (bfd_xcoff_stub_shared_call_size): New define. 128998 (xcoff_reloc_function): Add info argument. 128999 (enum xcoff_stub_type): New enum. 129000 (struct xcoff_stub_hash_entry): New structure. 129001 * xcofflink.c (struct xcoff_link_hash_table): Add stub hash 129002 table and params fields. 129003 (xcoff_stub_hash_entry): New define. 129004 (xcoff_stub_hash_lookup): New define. 129005 (stub_hash_newfunc): New function. 129006 (_bfd_xcoff_bfd_link_hash_table_free): Free the new stub hash 129007 table. 129008 (_bfd_xcoff_bfd_link_hash_table_create): Create the new stub 129009 hash table. 129010 (xcoff_link_add_symbols): Save rawsize for XTY_SD. 129011 (bfd_xcoff_link_init): New function. 129012 (xcoff_stub_csect_name): New function. 129013 (xcoff_stub_get_csect_in_range): New function. 129014 (xcoff_stub_name): New function. 129015 (bfd_xcoff_get_stub_entry): New function. 129016 (bfd_xcoff_type_of_stub): New function. 129017 (xcoff_add_stub): New function. 129018 (xcoff_build_one_stub): New function. 129019 (bfd_xcoff_size_stubs): New function. 129020 (bfd_xcoff_build_stubs): New function. 129021 (xcoff_stub_create_relocations): New function. 129022 (xcoff_link_input_bfd): Adapt relocations to stub. 129023 (xcoff_write_global_symbol): Adapt to new TOC entries generated 129024 for stubs. 129025 (_bfd_xcoff_bfd_final_link): Handle stub file. 129026 * xcofflink.h (struct bfd_xcoff_link_params): New structure. 129027 129028 ld/ChangeLog: 129029 129030 * emultempl/aix.em (params): New variable. 129031 (stub_file): New variable. 129032 (xcoff_add_stub_section): New function. 129033 (xcoff_layout_sections_again): New function 129034 (hook_in_stub): New function. 129035 (_after_allocation): Add stub creation. 129036 (_create_output_section_statements): Allocate stub file and 129037 pass params to backend. 129038 1290392022-04-20 Cl?ment Chigot <clement.chigot@atos.net> 129040 129041 Stubs (added in a later patch) will generate new .loader symbols, once the allocations have been done. Thus, the .loader section cannot be layout before that. 129042 bfd/ChangeLog: 129043 129044 * coff-rs6000.c (_bfd_xcoff_put_ldsymbol_name): Write len in 129045 ldinfo->strings instead of directly in the output_bfd. 129046 * coff64-rs6000.c (_bfd_xcoff64_put_ldsymbol_name): Likewise. 129047 * xcofflink.c (struct xcoff_link_hash_table): Remove ldrel_count 129048 field. Add ldinfo field. 129049 (xcoff_mark_symbol): Adjust to new ldinfo field. 129050 (xcoff_mark): Likewise. 129051 (bfd_xcoff_link_count_reloc): Likewise. 129052 (xcoff_build_loader_section): Split into two functions: one that 129053 build the loader section (this function) and one that only size 129054 it... 129055 (xcoff_size_loader_section): ... (this function). 129056 (bfd_xcoff_size_dynamic_sections): Adapt to new ldinfo field. 129057 Move the part where the dynamic sections are build to ... 129058 (bfd_xcoff_build_dynamic_sections): ... this function. 129059 * xcofflink.h: Add bfd_xcoff_build_dynamic_sections prototype. 129060 129061 include/ChangeLog: 129062 129063 * coff/xcoff.h (struct xcoff_loader_info): Add ldrel_count and 129064 libpath fields. 129065 129066 ld/ChangeLog: 129067 129068 * emultempl/aix.em (_after_allocation): New function. 129069 1290702022-04-20 Tom Tromey <tom@tromey.com> 129071 129072 Use symbol_symtab accessor in compile-object-load.c 129073 I noticed that compile-object-load.c directly references owner.symtab 129074 of a symbol. However, I think it's better for all users to call 129075 symbol_symtab. This patch makes this change. 129076 1290772022-04-20 Nick Clifton <nickc@redhat.com> 129078 129079 Add linker warning for when it creates an executable stack. 129080 PR 29072 129081 1290822022-04-20 Tom Tromey <tom@tromey.com> 129083 129084 Micro-optimize cooked_index_entry::full_name 129085 I noticed that cooked_index_entry::full_name can return the canonical 129086 string when there is no parent entry. 129087 129088 Regression tested on x86-64 Fedora 34. 129089 1290902022-04-20 Tiezhu Yang <yangtiezhu@loongson.cn> 129091 129092 gdb: LoongArch: Implement loongarch_scan_prologue() 129093 If can't determine prologue from the symbol table, need to examine 129094 instructions. Implement loongarch_scan_prologue() to analyze the 129095 function prologue from START_PC to LIMIT_PC, return the address of 129096 the first instruction past the prologue. 129097 1290982022-04-20 GDB Administrator <gdbadmin@sourceware.org> 129099 129100 Automatic date update in version.in 129101 1291022022-04-19 H.J. Lu <hjl.tools@gmail.com> 129103 129104 as: Reject unknown -gXXX option 129105 * as.c (parse_args): Reject unknown -gXXX option. 129106 * testsuite/gas/all/empty.s: New file. 129107 * testsuite/gas/all/pr29067.d: Likewise. 129108 * testsuite/gas/all/pr29067.err: Likewise. 129109 * testsuite/gas/all/gas.exp: Run pr29067. 129110 1291112022-04-19 Lancelot SIX <lancelot.six@amd.com> 129112 129113 gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazily 129114 The register_test_foreach_arch is used to instantiate a given selftest 129115 for all architectures supported by GDB. It is used in many _initialize_* 129116 functions (under initialize_all_files, called by gdb_init). 129117 129118 Because the call is done during GDB's initialization, and because there 129119 is no guaranty about the order in which all the _initialize_* functions 129120 are executed, when register_test_foreach_arch is called, GDB is not 129121 fully initialized. Specifically, when a particular initialize function 129122 is executed, only the architectures registered at that point are listed 129123 by gdbarch_printable_names. 129124 129125 As a consequence, the list of selftest effectively executed depends on 129126 the order the _initialize_* functions are called. This can be observed 129127 with the following: 129128 129129 $ ./gdb/gdb \ 129130 -data-directory ./gdb/data-directory \ 129131 -quiet -batch -ex "maint selftest" 2>&1 \ 129132 | grep -E "Ran [0-9]+ unit tests" 129133 Ran 145 unit tests, 0 failed 129134 $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \ 129135 -data-directory ./gdb/data-directory \ 129136 -quiet -batch -ex "maint selftest" 2>&1 \ 129137 | grep -E "Ran [0-9]+ unit tests" 129138 Ran 82 unit tests, 0 failed 129139 129140 To fix this, make register_test_foreach_arch register a lazy selftest 129141 generator. This way when the test generator is eventually executed, all 129142 architectures are registered and we do not have a dependency on the 129143 order the initialize functions are executed in. 129144 129145 Tested on x86_64-linux 129146 129147 Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925 129148 1291492022-04-19 Lancelot SIX <lancelot.six@amd.com> 129150 129151 gdbsupport/selftest: Allow lazy registration 129152 This patch adds a way to delay the registration of tests until the 129153 latest possible moment. This is intended for situations where GDB needs 129154 to be fully initialized in order to decide if a particular selftest can 129155 be executed or not. 129156 129157 This mechanism will be used in the next patch. 129158 129159 Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0 129160 1291612022-04-19 Lancelot SIX <lancelot.six@amd.com> 129162 129163 gdbsupport/selftest: Replace for_each_selftest with an iterator_range 129164 Remove the callback-based selftests::for_each_selftest function and use 129165 an iterator_range instead. 129166 129167 Also use this iterator range in run_tests so all iterations over the 129168 selftests are done in a consistent way. This will become useful in a 129169 later commit. 129170 129171 Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583 129172 1291732022-04-19 Jan Beulich <jbeulich@suse.com> 129174 129175 x86: don't mistake ordinary immediates for SAE / rounding control 129176 The way SAE templates are constructed was always puzzling me (including 129177 the need for separate templates in the first place), and expressing the 129178 extzra attribute via Imm8 actually has a bad effect: Ordinary immediates 129179 would also be accepted, leading to an extra byte being added after the 129180 instruction (i.e. generating bad code). Before re-working this (in 129181 particular to accept proper Intel syntax there), fix the immediate issue 129182 by adding the so far missing check. 129183 129184 x86: VCMPSH is Evex.LLIG 129185 These were mistakenly flagged as Evex.128. Getting the LLIG status right 129186 for insns allowing for SAE is a prereq for planned further work. 129187 129188 x86: drop stray CheckRegSize from VFPCLASSPH 129189 Like VFPCLASSP{S,D} it has only a single operand allowing multiple 129190 sizes, hence there are no pairs of operands to check for consistent 129191 size. 129192 129193 x86/Intel: test non-legacy VCVT{,U}SI2SH insn forms 129194 For an unclear reason corresponding AVX512F tests were apparently not 129195 cloned or used as reference here, and instead the bogus legacy forms of 129196 the insns (with the embedded rounding specifier not last) were used. 129197 1291982022-04-19 Jan Beulich <jbeulich@suse.com> 129199 129200 x86: correct and simplify NOP disassembly 129201 It's not just REX.W which is ignored with opcode 0x90. The same goes for 129202 REX.R and REX.X as well as empty REX. None of these are forms of 129203 "xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they 129204 also shouldn't be disassembled this way. 129205 129206 While there simplify things: A single hook function suffices, thus 129207 making it unnecessary to keep two expressions in sync. And checking 129208 ins->address_mode for mode_64bit also is unnecessary, as "rex" can be 129209 non-zero only in that case anyway. 129210 1292112022-04-19 GDB Administrator <gdbadmin@sourceware.org> 129212 129213 Automatic date update in version.in 129214 1292152022-04-18 Simon Marchi <simon.marchi@efficios.com> 129216 129217 gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5 129218 To support DWARF 5 in the DWARF assembler line tables, we currently copy 129219 the first user-provided directory and the first user-provided files and 129220 make them elements at indices 0 in the directory and file name tables. 129221 That was a sufficient behavior at the time (see commit 44fda089397a 129222 ("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in 129223 the following patches, I would need to have finer grained control on 129224 what is generated exactly. For example, I'd like to generate a DWARF 5 line 129225 table with just a single file and a single directory. 129226 129227 Get rid of this behavior, and implement what is suggested in 129228 44fda089397a: make include_dir return the directory index that can be 129229 used to refer to that directory entry (based on the DWARF version), and 129230 use it afterwards. 129231 129232 Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced 129233 DWARF5 binaries will change a bit, in that they will now have a single 129234 directory and file, where they had two before. But it doesn't change 129235 the expected GDB behavior. 129236 129237 Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b 129238 1292392022-04-18 Simon Marchi <simon.marchi@efficios.com> 129240 129241 gdb: use gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search 129242 Since this is the latest use of gdb_tilde_expand_up, remove it. 129243 129244 Change-Id: I964c812ce55fe087876abf91e7a3577ad79c0425 129245 1292462022-04-18 Simon Marchi <simon.marchi@efficios.com> 129247 129248 gdbsupport: make gdb_realpath_keepfile return an std::string 129249 I'm trying to switch these functions to use std::string instead of char 129250 arrays, as much as possible. Some callers benefit from it (can avoid 129251 doing a copy of the result), while others suffer (have to make one more 129252 copy). 129253 129254 Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc 129255 1292562022-04-18 Simon Marchi <simon.marchi@efficios.com> 129257 129258 gdbsupport: make gdb_abspath return an std::string 129259 I'm trying to switch these functions to use std::string instead of char 129260 arrays, as much as possible. Some callers benefit from it (can avoid 129261 doing a copy of the result), while others suffer (have to make one more 129262 copy). 129263 129264 Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993 129265 1292662022-04-18 Simon Marchi <simon.marchi@polymtl.ca> 129267 129268 gdb: call gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search 129269 This removes a use of gdb_tilde_expand_up, which is removed later in 129270 this series. 129271 129272 Change-Id: I5887d526cea987103e4ca24514a982b0a28e992a 129273 1292742022-04-18 Tom Tromey <tromey@adacore.com> 129275 129276 Update gnulib 129277 This updates gnulib to a relatively recent commit. Most of this was 129278 done by the gnulib import script; the only change I made was to 129279 update-gnulib.sh. 129280 129281 Tested on x86-64 Fedora 34. I also did a mingw cross build. 129282 1292832022-04-18 Tom Tromey <tom@tromey.com> 129284 129285 Fix C++ cast of derived class to base class 129286 PR c++/28907 points out that casting from a derived class to a base 129287 class fails in some situations. The problem turned out to be a 129288 missing use of value_embedded_offset. One peculiarity here is that, 129289 if you managed to construct a pointer-to-derived with an embedded 129290 offset of 0, the cast would work -- for example, one of the two new 129291 tests here passes without the patch. 129292 129293 This embedded offset stuff is an endless source of bugs. I wonder if 129294 it's possible to get rid of it somehow. 129295 129296 Regression tested on x86-64 Fedora 34. 129297 129298 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28907 129299 1293002022-04-18 Simon Marchi <simon.marchi@polymtl.ca> 129301 129302 gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location 129303 This test attempts to run until the line marked "STOP", which is at 129304 prot.adb:34. It first runs until the "main" symbol, then tries to place 129305 a breakpoint by line at line 34, without specifying the source file. When looking at the logs: 129306 129307 -break-insert -t 34^M 129308 ^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M 129309 ... continues ... 129310 *stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/ mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co re="8"^M 129311 129312 ... we see that the breakpoint is placed in some generated file, not in 129313 the test source file as we expect. The problem is that "b main" in Ada 129314 does not place a breakpoint on the "Ada main", but on some symbol in a 129315 generated source file. So when stopped at the "main" symbol, we are not 129316 stopped in the file that contains the STOP marker at line 34. 129317 129318 The test passes anyway today, so it doesn't seem to matter that we are 129319 stopped at an unexpected location. But it starts failing with this 129320 patch [1], because b~prot.adb:34 happens to be between two functions, so 129321 the breakpoint doesn't resolve. 129322 129323 Fix this by placing the breakpoint at "$srcfile:$line", which works 129324 regardless of what is the current source file. 129325 129326 However, this ends up introducing a path in the test name. Modify 129327 mi_tbreak and mi_continue_to_line to avoid that. 129328 129329 [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html 129330 129331 Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75 129332 1293332022-04-18 Vignesh Balasubramanian <Vignesh.Balasubrmanian@amd.com> 129334 129335 gdb/testsuite: add text_segment option to gdb_compile 129336 LLVM's lld linker doesn't have the "-Ttext-segment" option, but 129337 "--image-base" can be used instead. 129338 129339 To centralize the logic of checking which option is supported, add the 129340 text_segment option to gdb_compile. Change tests that are currently 129341 using -Ttext-segment to use that new option instead. 129342 129343 This patch fixes only compilation error, for example: 129344 129345 Before: 129346 129347 $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld" 129348 Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ... 129349 gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument] 129350 129351 After: 129352 129353 $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld" 129354 Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ... 129355 FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1 129356 FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2 129357 FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1 129358 FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function 129359 FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2 129360 FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1 129361 FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach 129362 FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1 129363 FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 129364 129365 === gdb Summary === 129366 129367 # of expected passes 26 129368 # of unexpected failures 9 129369 129370 Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635 129371 1293722022-04-18 Enze Li <lienze2010@hotmail.com> 129373 129374 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) 129375 The clear command shouldn't delete momentary and internal breakpoints, 129376 nor internal breakpoints created via Python's gdb.Breakpoint. 129377 129378 This patch fixes this issue and adds a testcase. 129379 129380 Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413"). 129381 129382 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7161 129383 1293842022-04-18 GDB Administrator <gdbadmin@sourceware.org> 129385 129386 Automatic date update in version.in 129387 1293882022-04-17 GDB Administrator <gdbadmin@sourceware.org> 129389 129390 Automatic date update in version.in 129391 1293922022-04-16 Tom Tromey <tom@tromey.com> 129393 129394 Add comments to dwarf2/abbrev-cache.h 129395 This patch started when I noticed that the unordered_set include 129396 wasn't needed in abbrev-cache.h. (That was probably leftover from 129397 some earlier implementation of the class.) Then, I noticed that the 129398 class itself was under-commented. This patch fixes both issues. 129399 1294002022-04-16 GDB Administrator <gdbadmin@sourceware.org> 129401 129402 Automatic date update in version.in 129403 1294042022-04-15 Tom Tromey <tom@tromey.com> 129405 129406 Return void from gdb_putc 129407 I don't think it's very useful to return the character from gdb_putc, 129408 so this patch changes it to return void. 129409 1294102022-04-15 Tom Tromey <tom@tromey.com> 129411 129412 Handle "set height 1" 129413 PR cli/17151 points out that "set height 1" has pathological behavior 129414 in gdb. What I see is that gdb will endlessly print the pagination 129415 prompt. This patch takes a simple and expedient approach to a fix: 129416 pretend that the height is really 2. 129417 129418 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17151 129419 1294202022-04-15 Tom Tromey <tom@tromey.com> 129421 129422 Allow word wrapping even when paging is disabled 129423 PR cli/20741 points out that when pagination is disabled, this also 129424 disabled word wrapping. However, the manual documents that these 129425 settings are separate -- if you intend to disable the wrapping, you 129426 must use "set width unlimited". 129427 129428 This patch fixes the bug by letting the pagination-disabled case fall 129429 through to the code that also handles word-wrapping. 129430 129431 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20741 129432 1294332022-04-15 Tom Tromey <tom@tromey.com> 129434 129435 Implement value_print for Rust 129436 This adds an implementation of the value_print method to Rust. As 129437 described in PR rust/22254, this removes a bit of weird-looking output 129438 from some "print"s -- because c_value_print is bypassed. I don't have 129439 a test for the bug that inspired this patch, because I only know how 129440 to reproduce it when using a relatively old Rust compiler. However, 129441 the new "cast-printing" code in value_print is required, because 129442 omitting this causes some existing tests to fail. 129443 129444 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22254 129445 1294462022-04-15 Tom Tromey <tom@tromey.com> 129447 129448 Reimplement Rust slice printing 129449 The current nightly Rust compiler (aka 1.61) added better DWARF 129450 representation for unsized types. Fixing this is PR rust/21466; but 129451 the code is actually the same as what is required to make slice 129452 printing more useful, which is PR rust/23871. This patch implements 129453 this. I tested this against various Rust compilers: 1.48, current 129454 stable, current beta, and current nightly. 129455 129456 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466 129457 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871 129458 1294592022-04-15 Tom Tromey <tom@tromey.com> 129460 129461 Remove some dead code from the Rust value printer 129462 This removes a bit of dead code from the Rust value printer. This 129463 code wasn't always dead -- it fixed a real bug, and a test case was 129464 added for it. However, once val_print was removed, it became 129465 unnecessary. 129466 1294672022-04-15 Tom Tromey <tom@tromey.com> 129468 129469 Match rustc beta versions 129470 The rust_compiler_version proc extracts the Rust compiler version from 129471 the "rustc --version" output. For a beta compiler, the output looks 129472 like: 129473 129474 rustc 1.60.0-beta.6 (7bccde197 2022-03-22) 129475 129476 This patch slightly relaxes the regexp -- removing a space -- so that 129477 this can be understood by this proc. 129478 1294792022-04-15 Tom de Vries <tdevries@suse.de> 129480 129481 [gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 129482 With test-case gdb.ada/float-bits.exp and native we get: 129483 ... 129484 (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M 129485 $9 = 5.0e+25^M 129486 (gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8# 129487 ... 129488 but with target board unix/-m32 we have instead: 129489 ... 129490 (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M 129491 Cannot export value 2596145952482202326224873165792712 as 96-bits \ 129492 unsigned integer (must be between 0 and 79228162514264337593543950335)^M 129493 (gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8# 129494 ... 129495 129496 Fix this by testing whether 16llf is supported by doing ptype long_long_float 129497 which gets us either: 129498 ... 129499 type = <16-byte float>^M 129500 ... 129501 or: 129502 ... 129503 type = <12-byte float>^M 129504 ... 129505 129506 Tested on x86_64-linux with native and unix/-m32. 129507 129508 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29041 129509 1295102022-04-15 Tom Tromey <tom@tromey.com> 129511 129512 Remove WITH_SIM define 129513 Since score-tdep.c was removed, the WITH_SIM define is not used in 129514 gdb. This patch removes it. 129515 129516 Note that re-running autoheader shows a separate change that was 129517 missed. I've kept it in this patch to avoid extra work. 129518 1295192022-04-15 Tom de Vries <tdevries@suse.de> 129520 129521 [gdb/testsuite] Fix gdb.go/methods.exp with check-readmore 129522 When running test-case gdb.go/methods.exp with make check we have: 129523 ... 129524 (gdb) break main.T.Foo^M 129525 Function "main.T.Foo" not defined.^M 129526 Make breakpoint pending on future shared library load? (y or [n]) n^M 129527 (gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo 129528 ... 129529 but with make check-readmore the XFAIL fails to trigger: 129530 ... 129531 (gdb) break main.T.Foo^M 129532 Function "main.T.Foo" not defined.^M 129533 Make breakpoint pending on future shared library load? (y or [n]) n^M 129534 (gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo 129535 ... 129536 129537 This happens because this gdb_test_multiple "maintenance print symbols" 129538 regexp: 129539 ... 129540 -re "\r\n$gdb_prompt $" { 129541 ... 129542 matches the entire command output. 129543 129544 Fix this by adding the missing ^ at the regexp start. 129545 129546 Tested on x86_64-linux. 129547 129548 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29064 129549 1295502022-04-15 GDB Administrator <gdbadmin@sourceware.org> 129551 129552 Automatic date update in version.in 129553 1295542022-04-14 Pedro Alves <pedro@palves.net> 129555 129556 gdbserver: Eliminate prepare_to_access_memory 129557 Given: 129558 129559 - The prepare_to_access_memory machinery was added for non-stop mode. 129560 129561 - Only Linux supports non-stop. 129562 129563 - Linux no longer needs the prepare_to_access_memory machinery. In 129564 fact, after the previous patch, 129565 linux_process_target::prepare_to_access_memory became a nop. 129566 129567 Thus, prepare_to_access_memory can go away, simplifying core GDBserver 129568 code. 129569 129570 Change-Id: I93ac8bfe66bd61c3d1c4a0e7d419335163120ecf 129571 1295722022-04-14 Pedro Alves <pedro@palves.net> 129573 129574 gdbserver/linux: Access memory even if threads are running 129575 Similarly to how the native Linux target was changed 129576 and subsequently reworked in these commits: 129577 129578 05c06f318fd9 Linux: Access memory even if threads are running 129579 8a89ddbda2ec Avoid /proc/pid/mem races (PR 28065) 129580 129581 ... teach GDBserver to access memory even when the current thread is 129582 running, by always accessing memory via /proc/PID/mem. 129583 129584 The existing comment: 129585 129586 /* Neither ptrace nor /proc/PID/mem allow accessing memory through a 129587 running LWP. */ 129588 129589 ... is incorrect for /proc/PID/mem does allow that. 129590 129591 Actually, from GDB's perspective, GDBserver could already access 129592 memory while threads were running, but at the expense of pausing all 129593 threads for the duration of the memory access, via 129594 prepare_to_access_memory. This new implementation does not require 129595 pausing any thread, thus 129596 linux_process_target::prepare_to_access_memory / 129597 linux_process_target::done_accessing_memory become nops. A subsequent 129598 patch will remove the whole prepare_to_access_memory infrastructure 129599 completely. 129600 129601 The GDBserver linux-low.cc implementation is simpler than GDB's 129602 linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork 129603 children to the process list immediately when the fork/vfork event is 129604 seen out of ptrace. I.e., there's no need to keep the file descriptor 129605 stored on a side map, we can store it directly in the process 129606 structure. 129607 129608 Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61 129609 1296102022-04-14 Pedro Alves <pedro@palves.net> 129611 129612 gdbserver: special case target_write_memory len==0 129613 The next patch in this series adds a common helper routine for both 129614 memory reads and writes, like this: 129615 129616 static int 129617 proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf, 129618 const gdb_byte *writebuf, int len) 129619 { 129620 gdb_assert ((readbuf == nullptr) != (writebuf == nullptr)); 129621 ... 129622 } 129623 129624 int 129625 linux_process_target::read_memory (CORE_ADDR memaddr, 129626 unsigned char *myaddr, int len) 129627 { 129628 return proc_xfer_memory (memaddr, myaddr, nullptr, len); 129629 } 129630 129631 linux_process_target::write_memory (CORE_ADDR memaddr, 129632 const unsigned char *myaddr, int len) 129633 { 129634 return proc_xfer_memory (memaddr, nullptr, myaddr, len); 129635 } 129636 129637 Surprisingly, the assertion fails. That happens because it can happen 129638 that target_write_memory is called with LEN==0, due to this in 129639 gdb/remote.c: 129640 129641 /* Determine whether the remote target supports binary downloading. 129642 This is accomplished by sending a no-op memory write of zero length 129643 to the target at the specified address. (...) */ 129644 129645 void 129646 remote_target::check_binary_download (CORE_ADDR addr) 129647 { 129648 ... 129649 p = rs->buf.data (); 129650 *p++ = 'X'; 129651 p += hexnumstr (p, (ULONGEST) addr); 129652 *p++ = ','; 129653 p += hexnumstr (p, (ULONGEST) 0); 129654 *p++ = ':'; 129655 *p = '\0'; 129656 129657 In this scenario, in gdbserver's target_write_memory, the "myaddr" 129658 argument of the_target->write_memory is passed the data() of a local 129659 gdb::byte_vector (which is a specialized std::vector). It's valid for 129660 std::vector::data() to return NULL when the vector is empty. 129661 129662 This commit adds an early return to target_write_memory to avoid 129663 target backends having to care about this. For good measure, do the 129664 same on the read side, in read_inferior_memory. 129665 129666 Change-Id: Iac8f04fcf99014c624ef4036bd318ca1771ad491 129667 1296682022-04-14 Pedro Alves <pedro@palves.net> 129669 129670 gdbserver/qXfer::threads, prepare_to_access_memory=>target_pause_all 129671 handle_qxfer_threads_proper needs to pause all threads even if the 129672 target can read memory when threads are running, so use 129673 target_pause_all instead, which is what the Linux implementation of 129674 prepare_to_access_memory uses. (Only Linux implements this hook.) 129675 129676 A following patch will make the Linux backend be able to access memory 129677 when threads are running, and thus will also make 129678 prepare_to_access_memory do nothing, which would cause testsuite 129679 regressions without this change. 129680 129681 Change-Id: I127fec7246b7c45b60dfa7341e781606bf54b5da 129682 1296832022-04-14 Tom Tromey <tromey@adacore.com> 129684 129685 Ignore 0,0 entries in .debug_aranges 129686 When running the internal AdaCore test suite against the new DWARF 129687 indexer, I found one regression on RISC-V. The test in question uses 129688 --gc-sections, and winds up with an entry in the middle of a 129689 .debug_aranges that has both address and length of 0. In this 129690 scenario, gdb assumes the entries are terminated and then proceeds to 129691 reject the section because it reads a subsequent entry as if it were a 129692 header. 129693 129694 It seems to me that, because each header describes the size of each 129695 .debug_aranges CU, it's better to simply ignore 0,0 entries and simply 129696 read to the end. That is what this patch does. 129697 129698 I've patched an existing test to provide a regression test for this. 129699 1297002022-04-14 Tom Tromey <tromey@adacore.com> 129701 129702 Use GetThreadDescription on Windows 129703 Windows 10 introduced SetThreadDescription and GetThreadDescription, a 129704 simpler way to set a thread's name. This changes gdb and gdbserver to 129705 use this convention when it is available. 129706 129707 This is part of PR win32/29050. 129708 129709 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050 129710 1297112022-04-14 Tom Tromey <tromey@adacore.com> 129712 129713 Set the worker thread name on Windows 129714 This patch is a bit different from the rest of the series, in that it 129715 is a change to gdb's behavior on the host. It changes gdb's thread 129716 pool to try to set the thread name on Windows, if SetThreadDescription 129717 is available. 129718 129719 This is part of PR win32/29050. 129720 129721 This patch isn't likely to be useful to many people in the short term, 129722 because the Windows port of the libstdc++ thread code is not upstream. 129723 (AdaCore uses it, and sent it upstream, but it did not land, I don't 129724 know why.) However, if that patch does ever go in, or presumably if 129725 you build using some other C++ runtime library, then this will be 129726 useful. 129727 129728 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050 129729 1297302022-04-14 Tom Tromey <tromey@adacore.com> 129731 129732 Implement thread_name for gdbserver 129733 This changes gdbserver to implement thread_name method. 129734 129735 Share handle_ms_vc_exception with gdbserver 129736 Currently, gdb's native Windows target implements the exception-based 129737 approach for setting thread names, but gdbserver does not. This patch 129738 moves handle_ms_vc_exception to the shared nat/windows-nat.c code, as 129739 preparation for adding this support to gdbserver. 129740 129741 Move target_read_string to target/target.c 129742 This moves the two overloads of target_read_string to a new file, 129743 target/target.c, and updates both gdb and gdbserver to build this. 129744 129745 Remove the byte order parameter to target_read_string 129746 target_read_string takes a byte order parameter, but only uses this to 129747 check whether a given character is zero. This is readily done without 129748 requiring the parameter, so remove it. 129749 129750 Rename read_string 129751 This renames read_string to be an overload of target_read_string. 129752 This makes it more consistent for the eventual merger with gdbserver. 129753 129754 Don't call QUIT in read_string 129755 read_string does not need to call QUIT, because target_read_memory 129756 already does. This change is needed to make string-reading usable by 129757 gdbserver. 129758 129759 Fix possible Cygwin build problem 129760 I noticed that nat/windows-nat.c checks __USEWIDE, but nothing sets it 129761 there -- I forgot to copy over the definition when making this file. 129762 This patch tries to fix the problem. I don't have a Cygwin setup, so 129763 I don't know whether this is sufficient, but it's probably necessary. 129764 1297652022-04-14 Lancelot SIX <lancelot.six@amd.com> 129766 Pedro Alves <pedro@palves.net> 129767 129768 gdb/testsuite: Fix race in gdb.dwarf2/calling-convention.exp 129769 Pedro Alves warned me that there is a race in 129770 gdb.dwarf2/calling-convention.exp making the test sometimes fail on his 129771 setup. This can be reliably reproduced using : 129772 129773 make check-read1 TESTS="gdb.dwarf2/calling-convention.exp" 129774 129775 The relevant part of the gdb.log file is: 129776 129777 return 35 129778 Function 'foo' does not follow the target calling convention. 129779 If you continue, setting the return value will probably lead to unpredictable behaviors. 129780 Make foo return now? (y or n) PASS: gdb.dwarf2/calling-convention.exp: return 35 129781 n 129782 Not confirmed 129783 (gdb) FAIL: gdb.dwarf2/calling-convention.exp: finish 129784 129785 The issue is that when doing the test for "return 35", the DejaGnu test 129786 sends "n" (to tell GDB not to perform the return action) but never 129787 consumes the "Not confirmed" acknowledgment sent by GDB. Later, when 129788 trying to do the next test, DejaGnu tries to match the leftover output 129789 from the "return" test. As this output is not expected, the test fails. 129790 129791 Fix by using gdb_test to send the "n" answer and match the confirmation 129792 and consume all output to the prompt. 129793 129794 Also do minor adjustments to the main regex: 129795 - Remove the leading ".*" which is not required. 129796 - Ensure that the "?" from the question is properly escaped. 129797 129798 Tested on x86_64-gnu-linux, using 129799 129800 - make check TESTS="gdb.dwarf2/calling-convention.exp" 129801 - make check-read1 TESTS="gdb.dwarf2/calling-convention.exp" 129802 - make check-readmore TESTS="gdb.dwarf2/calling-convention.exp" 129803 129804 Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938 129805 1298062022-04-14 Tom Tromey <tromey@adacore.com> 129807 129808 Silence -Wmaybe-uninitialized warning from target_waitstatus 129809 Currently, one use of target_waitstatus yields a warning: 129810 129811 target/waitstatus.h: In function 'void stop_all_threads()': 129812 target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized] 129813 175 | m_value = other.m_value; 129814 | ~~~~~~~~^~~~~~~~~~~~~~~ 129815 129816 This patch silences the warning. I tried the "volatile member" 129817 approach that was used for gdb::optional, but that didn't work, so 129818 this patch simply initializes the member. 129819 1298202022-04-14 Tom Tromey <tromey@adacore.com> 129821 129822 Fix regression on Windows with WOW64 129823 Internally at AdaCore, we recently started testing a 64-bit gdb 129824 debugging 32-bit processes. This failed with gdb head, but not with 129825 gdb 11. 129826 129827 The tests fail like this: 129828 129829 Starting program: [...].exe 129830 warning: Could not load shared library symbols for WOW64_IMAGE_SECTION. 129831 Do you need "set solib-search-path" or "set sysroot"? 129832 warning: Could not load shared library symbols for WOW64_IMAGE_SECTION. 129833 Do you need "set solib-search-path" or "set sysroot"? 129834 warning: Could not load shared library symbols for NOT_AN_IMAGE. 129835 Do you need "set solib-search-path" or "set sysroot"? 129836 warning: Could not load shared library symbols for NOT_AN_IMAGE. 129837 Do you need "set solib-search-path" or "set sysroot"? 129838 129839 After some debugging and bisecting, to my surprise the bug was 129840 introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus 129841 safe"). 129842 129843 The problem occurs in handle_exception. Previously the code did: 129844 129845 - ourstatus->kind = TARGET_WAITKIND_STOPPED; 129846 [...] 129847 case EXCEPTION_BREAKPOINT: 129848 [...] 129849 - ourstatus->kind = TARGET_WAITKIND_SPURIOUS; 129850 [...] 129851 /* FALLTHROUGH */ 129852 case STATUS_WX86_BREAKPOINT: 129853 DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT"); 129854 - ourstatus->value.sig = GDB_SIGNAL_TRAP; 129855 [...] 129856 - last_sig = ourstatus->value.sig; 129857 129858 However, in the new code, the fallthrough case does: 129859 129860 + ourstatus->set_stopped (GDB_SIGNAL_TRAP); 129861 129862 ... which changes the 'kind' in 'ourstatus' after falling through. 129863 129864 This patch rearranges the 'last_sig' setting to more closely match 129865 what was done before (this is probably not strictly needed but also 129866 seemed harmless), and removes the fall-through in the 129867 'ignore_first_breakpoint' case when __x86_64__ is defined. 129868 1298692022-04-14 Tom Tromey <tromey@adacore.com> 129870 129871 Reorganize Python events documentation 129872 This slightly reorganizes the Python events documentation. It hoists 129873 the "ThreadEvent" text out of the list of events, where it seemed to 129874 be misplaced. It tidies the formatting a little bit (adding some 129875 vertical space for easier reading in info), fixes a typo, adds some 129876 missing commas, and fixes an incorrect reference to NewInferiorEvent. 129877 1298782022-04-14 Simon Marchi <simon.marchi@polymtl.ca> 129879 129880 gdb: remove move constructor and move assignment operator from cooked_index 129881 Building with clang++-14, I see: 129882 129883 CXX dwarf2/cooked-index.o 129884 In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21: 129885 /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:172:12: error: explicitly defaulted move constructor is implicitly deleted [-Werror,-Wdefaulted-function-deleted] 129886 explicit cooked_index (cooked_index &&other) = default; 129887 ^ 129888 /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move constructor of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move constructor 129889 auto_obstack m_storage; 129890 ^ 129891 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:28: note: 'auto_obstack' has been explicitly marked deleted here 129892 DISABLE_COPY_AND_ASSIGN (auto_obstack); 129893 ^ 129894 In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21: 129895 /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:174:17: error: explicitly defaulted move assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted] 129896 cooked_index &operator= (cooked_index &&other) = default; 129897 ^ 129898 /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move assignment operator of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move assignment operator 129899 auto_obstack m_storage; 129900 ^ 129901 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:3: note: 'operator=' has been explicitly marked deleted here 129902 DISABLE_COPY_AND_ASSIGN (auto_obstack); 129903 ^ 129904 /home/smarchi/src/binutils-gdb/gdb/../include/ansidecl.h:425:8: note: expanded from macro 'DISABLE_COPY_AND_ASSIGN' 129905 void operator= (const TYPE &) = delete 129906 ^ 129907 129908 We explicitly make cooked_index have a default move constructor and 129909 move assignment operator. But it doesn't actually happen because 129910 cooked_index has a field of type auto_obstack, which isn't movable. 129911 We don't actually need cooked_index to be movable at the moment, so 129912 remove those lines. 129913 129914 Change-Id: Ifc1fe3d7d67e3ae1a14363d6c1869936fe80b0a2 129915 1299162022-04-14 Tom Tromey <tromey@adacore.com> 129917 129918 Let std::thread check pass even without pthreads 129919 Currently, the configure check for std::thread relies on pthreads 129920 existing. However, this means that if std::thread is implemented for 129921 a non-pthreads host, then the check will yield the wrong answer. This 129922 happened in AdaCore internal builds. Here, we have this GCC patch: 129923 129924 https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html 129925 129926 ... which adds mingw support to GCC's gthreads implementation, and 129927 also to std::thread. 129928 129929 This configure change fixes this problem and enables threading for 129930 gdb. 129931 1299322022-04-14 Tiezhu Yang <yangtiezhu@loongson.cn> 129933 129934 gdb: fix build errors in gdbsupport/thread-pool.h used with old gcc 129935 When I build gdb with gcc 8.3, there exist the following build errors, 129936 rename the typedef to task_t to fix them. 129937 129938 CXX thread-pool.o 129939 In file included from /home/loongson/gdb.git/gdbsupport/thread-pool.cc:21: 129940 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<void> gdb::thread_pool::post_task(std::function<void()>&&)’: 129941 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:69:44: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local] 129942 std::packaged_task<void ()> task (std::move (func)); 129943 ^~~~ 129944 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here 129945 typedef std::packaged_task<void ()> task; 129946 ^~~~ 129947 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<_Res> gdb::thread_pool::post_task(std::function<T()>&&)’: 129948 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:80:41: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local] 129949 std::packaged_task<T ()> task (std::move (func)); 129950 ^~~~ 129951 /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here 129952 typedef std::packaged_task<void ()> task; 129953 ^~~~ 129954 1299552022-04-14 Tom de Vries <tdevries@suse.de> 129956 129957 [gdb/testsuite] Detect 'No MPX support' 129958 On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into: 129959 ... 129960 (gdb) run ^M 129961 Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M 129962 [Thread debugging using libthread_db enabled]^M 129963 Using host libthread_db library "/lib64/libthread_db.so.1".^M 129964 No MPX support^M 129965 ... 129966 and eventually into all sort of fails in this and other mpx test-cases. 129967 129968 Fix this by detecting the "No MPX support" message in have_mpx. 129969 129970 Tested on x86_64-linux with target boards unix and unix/-m32. 129971 1299722022-04-14 Sergei Trofimovich <siarheit@google.com> 129973 129974 M68K: avoid quadratic slowdlow in label alignment check 129975 Before the change tc-m68k maintained a list of seen labels. 129976 Alignment check traversed label list to resolve symbol to label. 129977 This caused quadratic slowdown as each symbol was checked against 129978 each label. Worst affected files are the ones built with debugging 129979 enabled as DWARF generates many labels. 129980 129981 The change embeds auxiliary label information right into symbol using 129982 TC_SYMFIELD_TYPE. 129983 129984 Before the change test from PR 29058 did not finish in 10 minutes. After 129985 the change it finishes in 2 seconds. 129986 129987 gas/ChangeLog: 129988 129989 PR 29058 129990 * config/tc-m68k.h (TC_SYMFIELD_TYPE): define as m68k_tc_sy. 129991 * config/tc-m68k.c (m68k_frob_label): Use TC_SYMFIELD_TYPE to 129992 store label information. 129993 1299942022-04-14 caiyinyu <caiyinyu@loongson.cn> 129995 129996 ld:LoongArch: Fix glibc fail: tst-audit25a/b. 129997 bfd/ 129998 129999 * elfnn-loongarch.c: Add new func elf_loongarch64_hash_symbol. 130000 1300012022-04-14 GDB Administrator <gdbadmin@sourceware.org> 130002 130003 Automatic date update in version.in 130004 1300052022-04-13 Simon Marchi <simon.marchi@efficios.com> 130006 130007 gdb: add ATTRIBUTE_PRINTF to complaint_interceptor::issue_complaint 130008 Fix this error when building with clang++-14: 130009 130010 CXX complaints.o 130011 /home/smarchi/src/binutils-gdb/gdb/complaints.c:130:65: error: format string is not a string literal [-Werror,-Wformat-nonliteral] 130012 g_complaint_interceptor->m_complaints.insert (string_vprintf (fmt, args)); 130013 ^~~ 130014 130015 Change-Id: I0ef11f970510eb8638d1651fa0d5eeecd6a9d31a 130016 1300172022-04-13 Simon Marchi <simon.marchi@efficios.com> 130018 130019 gdb: fix clang build failure in msymbol_is_mips 130020 Building with clang++-14, I see: 130021 130022 CXX mips-tdep.o 130023 /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] 130024 return !(MSYMBOL_TARGET_FLAG_MIPS16 (msym) 130025 ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 130026 /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16' 130027 (sym)->target_flag_1 () 130028 ^ 130029 /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: note: cast one or both operands to int to silence this warning 130030 /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16' 130031 (sym)->target_flag_1 () 130032 ^ 130033 130034 That's since commit e165fcef1e7 ("gdb: remove MSYMBOL_TARGET_FLAG_{1,2} 130035 macros"). Fix this by using the boolean || rather than the bitwise |, 130036 since the new methods return bool values. No change in behavior 130037 expected. 130038 130039 Change-Id: Ia82664135aa25db64c29c92f5c1141859d345bf7 130040 1300412022-04-13 Alexander von Gluck IV <kallisti5@unixzen.com> 130042 130043 binutils: enable PE on 32bit haiku build 130044 * config.bfd (x86-haiku): Add i386_pei_vec as a selectable format. 130045 1300462022-04-13 Pedro Alves <pedro@palves.net> 130047 130048 Make intrusive_list_node's next/prev private 130049 Tromey noticed that intrusive_list_node leaves its data members 130050 public, which seems sub-optimal. 130051 130052 This commit makes intrusive_list_node's data fields private. 130053 intrusive_list_iterator, intrusive_list_reverse_iterator, and 130054 intrusive_list do need to access the fields, so they are made friends. 130055 130056 Change-Id: Ia8b306b40344cc218d423c8dfb8355207a612ac5 130057 1300582022-04-13 Pedro Alves <pedro@palves.net> 130059 130060 Tidy gdb.base/parse_number.exp 130061 Now that Ada is able to parse & print 0xffffffffffffffff (2^64-1) in 130062 hex, move it to the else branch like most other languages. 130063 130064 Change-Id: Ib305f6bb2b6b230a1190ea783b245b865821094c 130065 1300662022-04-13 Alan Modra <amodra@gmail.com> 130067 130068 ubsan: member access within null pointer of union 130069 Add some nonsense to cover "undefined behaviour". 130070 130071 * ldlang.c (section_for_dot): Avoid UB. 130072 1300732022-04-13 GDB Administrator <gdbadmin@sourceware.org> 130074 130075 Automatic date update in version.in 130076 1300772022-04-12 Tom Tromey <tromey@adacore.com> 130078 130079 Fix bug in Ada number lexing 130080 On irc, Pedro pointed out that Ada couldn't properly handle 130081 0xffffffffffffffff. This used to work, but is a regression due to 130082 some patches I wrote in the Ada lexer. This patch fixes the bug. 130083 1300842022-04-12 Simon Marchi <simon.marchi@efficios.com> 130085 130086 gdb: fix "passing NULL to memcpy" UBsan error in dwarf2/cooked-index.c 130087 Reading a simple file compiled with : 130088 130089 $ gcc -DONE=1 -gdwarf-4 -g3 test.c 130090 $ gcc --version 130091 gcc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0 130092 130093 I get: 130094 130095 Reading symbols from /tmp/cwd/a.out... 130096 /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:332:11: runtime error: null pointer passed as argument 2, which is declared to never be null 130097 130098 It looks like even if the size is 0 (the size of the `entries` vector is 130099 0), we shouldn't be passing a NULL pointer to memcpy. And 130100 `entries.data ()` returns NULL. 130101 130102 Fix that by using std::vector::insert to insert the items of entries 130103 into m_entries. I haven't checked, but it should essentially compile 130104 down to a memcpy, since the vector elements are trivially copyiable. 130105 130106 Change-Id: I75f1c901e9b522e42e89eb5936e2c70d68eb21e5 130107 1301082022-04-12 Simon Marchi <simon.marchi@polymtl.ca> 130109 130110 gdb: change subfile::line_vector to an std::vector 130111 Change this field to an std::vector to facilitate memory management. 130112 Since the linetable_entry array is copied into the symtab resulting from 130113 the subfile, it is possible to change it without changing how symtab 130114 stores the linetable entries (which would be a much larger change). 130115 130116 There is a small change in buildsym_compunit::record_line to avoid 130117 accessing a now invalid linetable_entry. Before this patch, we keep a 130118 pointer to the last linetable entry, pop it from the vector, and then 130119 read last->line. It works with the manually-maintained array, but since 130120 we now use std::vector::pop_back, I am afraid that it could be flagged 130121 as an invalid access by the various static / dynamic analysis tools to 130122 access the linetable_entry object after popping it from the vector. 130123 Instead, record just the line number in an optional and use it. 130124 130125 There are substantial changes in xcoffread.c that simplify the code, but 130126 I can't test them. I was hesitant to do this change because of that, 130127 but I decided to send it anyway. I don't think that an almost dead 130128 platform should hold back improving the code in the common parts of GDB. 130129 130130 The changes in xcoffread.c are: 130131 130132 - Make arrange_linetable "arrange" the linetable passed as a parameter, 130133 instead of returning possibly a new one, possibly the same one. 130134 - In the "Process main file's line numbers.", I'm not too sure what 130135 happens. We get the lintable from "main_subfile", "arrange" it, but 130136 then assign the result to the current subfile, obtained with 130137 get_current_subfile. I assume that the current subfile is also the 130138 main one, so now I just call arrange_linetable on the main subfile's 130139 line table. 130140 - Remove that weird "Useless if!!!" FIXME comment. It's been there 130141 forever, but the "if" is still there, so I guess the "if" can stay 130142 there. 130143 130144 Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80 130145 1301462022-04-12 Simon Marchi <simon.marchi@efficios.com> 130147 130148 gdb: use std::vector for temporary linetable_entry array in arrange_linetable 130149 Reduce manual memory management and make the code a bit easier to read. 130150 This helps me a bit in the following patch. 130151 130152 I don't have a way to test this, it's best-effort. 130153 130154 Change-Id: I64af9cd756311deabc6cd95e701dfb21234a40a5 130155 1301562022-04-12 Simon Marchi <simon.marchi@efficios.com> 130157 130158 gdb: change subfile::name and buildsym_compunit::m_comp_dir to strings 130159 Change subfile::name to be a string, for easier memory management. 130160 Change buildsym_compunit::m_comp_dir as well, since we move one in to 130161 the other at some point in patch_subfile_names, so it's easier to do 130162 both at the same time. There are various NULL checks for both fields 130163 currently, replace them with empty checks, I think it ends up 130164 equivalent. 130165 130166 I can't test the change in xcoffread.c, it's best-effort. 130167 130168 Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016 130169 1301702022-04-12 Simon Marchi <simon.marchi@polymtl.ca> 130171 130172 gdb: allocate subfile with new 130173 Allocate struct subfile with new, initialize its fields instead of 130174 memset-ing it to 0. Use a unique_ptr for the window after a subfile has 130175 been allocated but before it is linked in the buildsym_compunit's list 130176 of subfile (and therefore owned by the buildsym_compunit. 130177 130178 I can't test the change in xcoffread.c, it's best-effort. I couldn't 130179 find where subfiles are freed in that file, I assume they were 130180 intentionally (or not) leaked. 130181 130182 Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24 130183 1301842022-04-12 Simon Marchi <simon.marchi@efficios.com> 130185 130186 gdb: use decltype instead of typeof in dwarf2/read.c 130187 When building with -std=c++11, I get: 130188 130189 CXX dwarf2/read.o 130190 /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function ‘void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’: 130191 /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before ‘typeof’ 130192 7130 | using iter_type = typeof (per_bfd->all_comp_units.begin ()); 130193 | ^~~~~~ 130194 130195 This is because typeof is a GNU extension. Use C++'s decltype keyword 130196 instead. 130197 130198 Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14 130199 1302002022-04-12 Simon Marchi <simon.marchi@efficios.com> 130201 130202 gdbsupport: use result_of_t instead of result_of in parallel-for.h 130203 When building with -std=c++11, I get: 130204 130205 In file included from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:134:10: error: ‘result_of_t’ is not a member of ‘std’; did you mean ‘result_of’? 130206 134 | std::result_of_t<RangeFunction (RandomIt, RandomIt)> 130207 | ^~~~~~~~~~~ 130208 | result_of 130209 130210 This is because result_of_t has been introduced in C++14. Use the 130211 equivalent result_of<...>::type instead. 130212 130213 result_of and result_of_t have been removed in C++20 though, so I think 130214 we'll need some patches eventually to make the code use invoke_result 130215 instead, depending on the C++ version. 130216 130217 Change-Id: I4817f361c0ebcdd4b32976898fc368bb302b61b9 130218 1302192022-04-12 Tom Tromey <tom@tromey.com> 130220 130221 Remove dwarf2_per_cu_data::v 130222 Now that the psymtab reader has been removed, the 130223 dwarf2_per_cu_data::v union is no longer needed. Instead, we can 130224 simply move the members from dwarf2_per_cu_quick_data into 130225 dwarf2_per_cu_data and remove the "quick" object entirely. 130226 130227 Delete DWARF psymtab code 130228 This removes the DWARF psymtab reader. 130229 1302302022-04-12 Tom Tromey <tom@tromey.com> 130231 130232 Enable the new DWARF indexer 130233 This patch finally enables the new indexer. It is left until this 130234 point in the series to avoid any regressions; in particular, it has to 130235 come after the changes to the DWARF index writer to avoid this 130236 problem. 130237 130238 However, if you experiment with the series, this patch can be moved 130239 anywhere from the patch to wire in the new reader to this point. 130240 Moving this patch around is how I got separate numbers for the 130241 parallelization and background finalization patches. 130242 130243 In the ongoing performance example, this reduces the time from the 130244 baseline of 1.598869 to 0.903534. 130245 1302462022-04-12 Tom Tromey <tom@tromey.com> 130247 130248 Adapt .debug_names writer to new DWARF scanner 130249 This updates the .debug_names writer to work with the new DWARF 130250 scanner. 130251 1302522022-04-12 Tom Tromey <tom@tromey.com> 130253 130254 Adapt .gdb_index writer to new DWARF scanner 130255 This updates the .gdb_index writer to work with the new DWARF scanner. 130256 The .debug_names writer is deferred to another patch, to make review 130257 simpler. 130258 130259 This introduces a small hack to psyms_seen_size, but is 130260 inconsequential because this function will be deleted in a subsequent 130261 patch. 130262 1302632022-04-12 Tom Tromey <tom@tromey.com> 130264 130265 Genericize addrmap handling in the DWARF index writer 130266 This updates the DWARF index writing code to make the addrmap-writing 130267 a bit more generic. Now, it can handle multiple maps, and it can work 130268 using the maps generated by the new indexer. 130269 130270 Note that the new addrmap_index_data::using_index field will be 130271 deleted in a future patch, when the rest of the DWARF psymtab code is 130272 removed. 130273 1302742022-04-12 Tom Tromey <tom@tromey.com> 130275 130276 Change parameters to write_address_map 130277 To support the removal of partial symtabs from the DWARF index writer, 130278 this makes a small change to have write_address_map accept the address 130279 map as a parameter, rather than assuming it always comes from the 130280 per-BFD object. 130281 130282 Change the key type in psym_index_map 130283 In order to change the DWARF index writer to avoid partial symtabs, 130284 this patch changes the key type in psym_index_map (and renames that 130285 type as well). Using the dwarf2_per_cu_data as the key makes it 130286 simpler to reuse this code with the new indexer. 130287 130288 Rename write_psymtabs_to_index 130289 We'll be removing all the psymtab code from the DWARF reader. As a 130290 preparatory step, this renames write_psymtabs_to_index to avoid the 130291 "psymtab" name. 130292 1302932022-04-12 Tom Tromey <tom@tromey.com> 130294 130295 "Finalize" the DWARF index in the background 130296 After scanning the CUs, the DWARF indexer merges all the data into a 130297 single vector, canonicalizing C++ names as it proceeds. While not 130298 necessarily single-threaded, this process is currently done in just 130299 one thread, to keep memory costs lower. 130300 130301 However, this work is all done without reference to any data outside 130302 of the indexes. This patch improves the apparent performance of GDB 130303 by moving it to the background. All uses of the index are then made 130304 to wait for this process to complete. 130305 130306 In our ongoing example, this reduces the scanning time on gdb itself 130307 to 0.173937 (wall). Recall that before this patch, the time was 130308 0.668923; and psymbol reader does this in 1.598869. That is, at the 130309 end of this series, we see about a 10x speedup. 130310 1303112022-04-12 Tom Tromey <tom@tromey.com> 130312 130313 Parallelize DWARF indexing 130314 This parallelizes the new DWARF indexer. The indexer's storage was 130315 designed so that each storage object and each indexer is fully 130316 independent. This setup makes it simple to scan different CUs 130317 independently. 130318 130319 This patch creates a new cooked index storage object per thread, and 130320 then scans a subset of all the CUs in each such thread, using gdb's 130321 existing thread pool. 130322 130323 In the ongoing "gdb gdb" example, this patch reduces the wall time 130324 down to 0.668923, from 0.903534. (Note that the 0.903534 is the time 130325 for the new index -- that is, when the "enable the new index" patch is 130326 rebased to before this one. However, in the final series, that patch 130327 appears toward the end. Hopefully this isn't too confusing.) 130328 1303292022-04-12 Tom Tromey <tom@tromey.com> 130330 130331 Pre-read DWARF section data 130332 Because BFD is not thread-safe, we need to be sure that any section 130333 data that is needed is read before trying to do any DWARF indexing in 130334 the background. 130335 130336 This patch takes a simple approach to this -- it pre-reads the 130337 "info"-related sections. This is done for the main file, but also any 130338 auxiliary files as well, such as the DWO file. 130339 130340 This patch could be perhaps enhanced by removing some now-redundant 130341 calls to dwarf2_section_info::read. 130342 1303432022-04-12 Tom Tromey <tom@tromey.com> 130344 130345 Introduce thread-safe handling for complaints 130346 This introduces a new class that can be used to make the "complaint" 130347 code thread-safe. Instantiating the class installs a new handler that 130348 collects complaints, and then prints them all when the object is 130349 destroyed. 130350 130351 This approach requires some locks. I couldn't think of a better way 130352 to handle this, though, because the I/O system is not thread-safe. 130353 130354 It seemed to me that only GDB developers are likely to enable 130355 complaints, and because the complaint macro handle this case already 130356 (before any locks are required), I reasoned that any performance 130357 degradation that would result here would be fine. 130358 130359 As an aside about complaints -- are they useful at all? I just ignore 130360 them, myself, since mostly they seem to indicate compiler problems 130361 that can't be solved in the GDB world anyway. I'd personally prefer 130362 them to be in a separate tool, like a hypothetical 'dwarflint'. 130363 1303642022-04-12 Tom Tromey <tom@tromey.com> 130365 130366 Wire in the new DWARF indexer 130367 This wires the new DWARF indexer into the existing reader code. That 130368 is, this patch makes the modification necessary to enable the new 130369 indexer. It is not actually enabled by this patch -- that will be 130370 done later. 130371 130372 I did a bit of performance testing for this patch and a few others. I 130373 copied my built gdb to /tmp, so that each test would be done on the 130374 same executable. Then, each time, I did: 130375 130376 $ ./gdb -nx 130377 (gdb) maint time 1 130378 (gdb) file /tmp/gdb 130379 130380 This patch is the baseline and on one machine came in at 1.598869 wall 130381 time. 130382 1303832022-04-12 Tom Tromey <tom@tromey.com> 130384 130385 Implement quick_symbol_functions for cooked DWARF index 130386 This implements quick_symbol_functions for the cooked DWARF index. 130387 This is the code that interfaces between the new index and the rest of 130388 gdb. Cooked indexes still aren't created by anything. 130389 130390 For the most part this is straightforward. It shares some concepts 130391 with the existing DWARF indices. However, because names are stored 130392 pre-split in the cooked index, name lookup here is necessarily 130393 different; see expand_symtabs_matching for the gory details. 130394 1303952022-04-12 Tom Tromey <tom@tromey.com> 130396 130397 The new DWARF indexer 130398 This patch adds the code to index DWARF. This is just the scanner; it 130399 reads the DWARF and constructs the index, but nothing calls it yet. 130400 130401 The indexer is split into two parts: a storage object and an indexer 130402 object. This is done to support the parallelization of this code -- a 130403 future patch will create a single storage object per thread. 130404 1304052022-04-12 Tom Tromey <tom@tromey.com> 130406 130407 Introduce the new DWARF index class 130408 This patch introduces the new DWARF index class. It is called 130409 "cooked" to contrast against a "raw" index, which is mapped from disk 130410 without extra effort. 130411 130412 Nothing constructs a cooked index yet. The essential idea here is 130413 that index entries are created via the "add" method; then when all the 130414 entries have been read, they are "finalize"d -- name canonicalization 130415 is performed and the entries are added to a sorted vector. 130416 130417 Entries use the DWARF name (DW_AT_name) or linkage name, not the full 130418 name as is done for partial symbols. 130419 130420 These two facets -- the short name and the deferred canonicalization 130421 -- help improve the performance of this approach. This will become 130422 clear in later patches, when parallelization is added. 130423 130424 Some special code is needed for Ada, because GNAT only emits mangled 130425 ("encoded", in the Ada lingo) names, and so we reconstruct the 130426 hierarchical structure after the fact. This is also done in the 130427 finalization phase. 130428 130429 One other aspect worth noting is that the way the "main" function is 130430 found is different in the new code. Currently gdb will notice 130431 DW_AT_main_subprogram, but won't recognize "main" during reading -- 130432 this is done later, via explicit symbol lookup. This is done 130433 differently in the new code so that finalization can be done in the 130434 background without then requiring a synchronization to look up the 130435 symbol. 130436 1304372022-04-12 Tom Tromey <tom@tromey.com> 130438 130439 Update skip_one_die for new abbrev properties 130440 This updates skip_one_die to speed it up in the cases where either 130441 sibling_offset or size_if_constant are set. 130442 1304432022-04-12 Tom Tromey <tom@tromey.com> 130444 130445 Statically examine abbrev properties 130446 The new DIE scanner works more or less along the lines indicated by 130447 the text for the .debug_names section, disregarding the bugs in the 130448 specification. 130449 130450 While working on this, I noticed that whether a DIE is interesting is 130451 a static property of the DIE's abbrev. It also turns out that many 130452 abbrevs imply a static size for the DIE data, and additionally that 130453 for many abbrevs, the sibling offset is stored at a constant offset 130454 from the start of the DIE. 130455 130456 This patch changes the abbrev reader to analyze each abbrev and stash 130457 the results on the abbrev. These combine to speed up the new indexer. 130458 If the "interesting" flag is false, GDB knows to skip the DIE 130459 immediately. If the sibling offset is statically known, skipping can 130460 be done without reading any attributes; and in some other cases, the 130461 DIE can be skipped using simple arithmetic. 130462 1304632022-04-12 Tom Tromey <tom@tromey.com> 130464 130465 Introduce DWARF abbrev cache 130466 The replacement for the DWARF psymbol reader works in a somewhat 130467 different way. The current reader reads and stores all the DIEs that 130468 might be interesting. Then, if it is missing a DIE, it re-scans the 130469 CU and reads them all. This approach is used for both intra- and 130470 inter-CU references. 130471 130472 I instrumented the partial DIE hash to see how frequently it was used: 130473 130474 [ 0] -> 1538165 130475 [ 1] -> 4912 130476 [ 2] -> 96102 130477 [ 3] -> 175 130478 [ 4] -> 244 130479 130480 That is, most DIEs are never used, and some are looked up twice -- but 130481 this is just an artifact of the implementation of 130482 partial_die_info::fixup, which may do two lookups. 130483 130484 Based on this, the new implementation doesn't try to store any DIEs, 130485 but instead just re-scans them on demand. In order to do this, 130486 though, it is convenient to have a cache of DWARF abbrevs. This way, 130487 if a second CU is needed to resolve an inter-CU reference, the abbrevs 130488 for that CU need only be computed a single time. 130489 1304902022-04-12 Tom Tromey <tom@tromey.com> 130491 130492 Add "fullname" handling to file_and_directory 130493 This changes the file_and_directory object to be able to compute and 130494 cache the "fullname" in the same way that is done by other code, like 130495 the psymtab reader. 130496 130497 Specialize std::hash for gdb_exception 130498 This adds a std::hash specialization for gdb_exception. This lets us 130499 store these objects in a hash table, which is used later in this 130500 series to de-duplicate the exception output from multiple threads. 130501 130502 Return vector of results from parallel_for_each 130503 This changes gdb::parallel_for_each to return a vector of the results. 130504 However, if the passed-in function returns void, the return type 130505 remains 'void'. This functionality is used later, to parallelize the 130506 new indexer. 130507 130508 Add batching parameter to parallel_for_each 130509 parallel_for_each currently requires each thread to process at least 130510 10 elements. However, when indexing, it's fine for a thread to handle 130511 just a single CU. This patch parameterizes this, and updates the one 130512 user. 130513 130514 Refactor build_type_psymtabs_reader 130515 The new DWARF scanner needs to save the entire cutu_reader object, not 130516 just parts of it. In order to make this possible, this patch 130517 refactors build_type_psymtabs_reader. This change is done separately 130518 because it is easy to review in isolation and it helps make the later 130519 patches smaller. 130520 130521 Add new overload of dwarf5_djb_hash 130522 This adds a new overload of dwarf5_djb_hash. This is used in 130523 subsequent patches. 130524 1305252022-04-12 Tom Tromey <tom@tromey.com> 130526 130527 Add name splitting 130528 The new DWARF index code works by keeping names pre-split. That is, 130529 rather than storing a symbol name like "a::b::c", the names "a", "b", 130530 and "c" will be stored separately. 130531 130532 This patch introduces some helper code to split a full name into its 130533 components. 130534 1305352022-04-12 Tom Tromey <tom@tromey.com> 130536 130537 Let skip_one_die not skip children 130538 This patch adds an option to skip_one_die that causes it not to skip 130539 child DIEs. This is needed in the new scanner. 130540 130541 Allow ada_decode not to decode operators 130542 The new DWARF scanner records names as they appear in DWARF. However, 130543 because Ada is unusual, it also decodes the Ada names to synthesize 130544 package components for them. In order for this to work out properly, 130545 gdb also needs a mode where ada_decode can be instructed not to decode 130546 Ada operator names. That is what this patch implements. 130547 130548 Refactor dwarf2_get_pc_bounds 130549 This changes dwarf2_get_pc_bounds so that it does not directly access 130550 a psymtab or psymtabs_addrmap. Instead, both the addrmap and the 130551 desired payload are passed as parameters. This makes it suitable to 130552 be used by the new indexer. 130553 130554 Add dwarf2_per_cu_data::addresses_seen 130555 This adds a new member to dwarf2_per_cu_data that indicates whether 130556 addresses have been seen for this CU. This is then set by the 130557 .debug_aranges reader. The idea here is to detect when a CU does not 130558 have address information, so that the new indexer will know to do 130559 extra scanning in that case. 130560 130561 Fix latent bug in read_addrmap_from_aranges 130562 Tom de Vries found a failure that we tracked down to a latent bug in 130563 read_addrmap_from_aranges (previously create_addrmap_from_aranges). 130564 The bug is that this code can erroneously reject .debug_aranges when 130565 dwz is in use, due to CUs at duplicate offsets. Because aranges can't 130566 refer to a CU coming from the dwz file, the fix is to simply skip such 130567 CUs in the loop. 130568 130569 Split create_addrmap_from_aranges 130570 This patch splits create_addrmap_from_aranges into a wrapper function 130571 and a worker function. The worker function is then used in a later 130572 patch. 130573 1305742022-04-12 Tom Tromey <tom@tromey.com> 130575 130576 Allow thread-pool.h to work without threads 130577 thread-pool.h requires CXX_STD_THREAD in order to even be included. 130578 However, there's no deep reason for this, and during review we found 130579 that one patch in the new DWARF indexer series unconditionally 130580 requires the thread pool. 130581 130582 Because the thread pool already allows a task to be run in the calling 130583 thread (for example if it is configured to have no threads in the 130584 pool), it seemed straightforward to make this code ok to use when host 130585 threads aren't available at all. 130586 130587 This patch implements this idea. I built it on a thread-less host 130588 (mingw, before my recent configure patch) and verified that the result 130589 builds. 130590 130591 After the thread-pool change, parallel-for.h no longer needs any 130592 CXX_STD_THREAD checks at all, so this patch removes these as well. 130593 1305942022-04-12 Nick Clifton <nickc@redhat.com> 130595 130596 Rebase the zlib sources to the 1.2.12 release 130597 1305982022-04-12 Tom de Vries <tdevries@suse.de> 130599 130600 [gdb/testsuite] Fix gdb.base/stap-probe.exp with read1 130601 When running test-case gdb.base/stap-probe.exp with make target check-read1, I 130602 run into this and similar: 130603 ... 130604 FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \ 130605 info probes stap (timeout) 130606 ... 130607 130608 Fix this by using gdb_test_lines instead of gdb_test. 130609 130610 Tested on x86_64-linux. 130611 1306122022-04-12 Tom Tromey <tom@tromey.com> 130613 130614 Add C++ "save gdb-index" test 130615 I found a bug in the new DWARF reader series, related to the handling 130616 of enumerator names. This bug caused a crash, so this patch adds a 130617 regression test for this particular case. I'm checking this in. 130618 1306192022-04-12 Tom Tromey <tromey@adacore.com> 130620 130621 Remove "Ada Settings" node from the manual 130622 A while back, I sent a patch to unify the Ada varsize-limit setting 130623 with the more generic max-value-size: 130624 130625 https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html 130626 130627 However, it turns out I somehow neglected to send part of the patch. 130628 Internally, I also removed the "Ada Settings" node from the manual, as 130629 it only documents the obsolete setting. 130630 130631 This patch removes this text. 130632 1306332022-04-12 Tom Tromey <tromey@adacore.com> 130634 130635 Require GNAT debug info for some Ada tests 130636 A few Ada tests require some debug info in the GNAT runtime. When run 130637 without this info, these tests can't pass. This patch changes these 130638 tests to detect this situation and stop with "untested". 130639 1306402022-04-12 Nick Clifton <nickc@redhat.com> 130641 130642 Stop strip from removing debuglink sections. 130643 PR 28992 130644 * objcopy.c (is_strip_section_1): Do not delete debuglink sections 130645 when stripping debug information. 130646 1306472022-04-12 Jan Beulich <jbeulich@suse.com> 130648 130649 gas: new_logical_line{,_flags}() can return "void" 130650 With the sole user of the return value gone, convert the return type to 130651 void. This in turn allows simplifying another construct, by moving it 130652 slightly later in the function. 130653 130654 gas: drop .appfile and .appline 130655 These were used originally to represent "# <line> <file>" constructs 130656 inserted by (typically) compilers when pre-processing. Quite some time 130657 ago they were replaced by .linefile though. Since the original 130658 directives were never documented, we ought to be able to remove support 130659 for them. As a result in a number of case function parameter aren't used 130660 anymore and can hence be dropped. 130661 1306622022-04-12 Jan Beulich <jbeulich@suse.com> 130663 130664 gas: further adjust file/line handling for .macro 130665 Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp 130666 and alike blocks"), while dealing okay with actual assembly source files 130667 not using .file/.line and alike outside but not inside of .macro, has 130668 undue effects when the logical file/line pair was already overridden: 130669 Line numbers would continuously increment while processing the expanded 130670 macro, while the goal of the PR gas/16908 workaround is to keep the 130671 expansion associated with the line invoking the macro. However, as soon 130672 as enough state was overridden _inside_ the macro to cause as_where() to 130673 no longer fall back top as_where_physical(), honor this by resuming the 130674 bumping of the logical line number. 130675 130676 Note that from_sb_is_expansion's initializer was 1 for an unknown 130677 reason. While renaming the variable and changing its type, also change 130678 the initializer to "expanding_none", which would have been "0" in the 130679 original code. Originally the initializer value itself wasn't ever used 130680 anyway (requiring sb_index != -1), as it necessarily had changed in 130681 input_scrub_include_sb() alongside setting sb_index to other than -1. 130682 130683 Strictly speaking input_scrub_insert_line() perhaps shouldn't use 130684 expanding_none, yet none of the other enumerators fit there either. And 130685 then strictly speaking that function probably shouldn't exist in the 130686 first place. It's used only by tic54x. 130687 1306882022-04-12 Jan Beulich <jbeulich@suse.com> 130689 130690 gas: further adjust file/line handling for .irp and alike 130691 Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp 130692 and alike blocks"), while dealing okay with actual assembly source files 130693 not using .file/.line and alike outside but not inside of .irp et al, 130694 has undue effects when the logical file/line pair was already 130695 overridden: Line numbers would continuously increment upon every 130696 iteration, thus potentially getting far off. Furthermore it left it to 130697 the user to actually insert .file/.line inside such constructs. Note 130698 though that before aforementioned change things weren't pretty either: 130699 Diagnostics (and debug info) would be associated with the directive 130700 terminating the iteration construct, rather than with the actual lines. 130701 130702 Handle this automatically by simply latching the present line and then 130703 re-instating coordinates first thing on every iteration; note that the 130704 file can't change from what was previously pushed on the scrubber's 130705 state stack, and hence can be taken from there by using a new flavor of 130706 .linefile (which is far better memory-footprint-wise than recording the 130707 full path in the inserted directive). (This then leaves undisturbed any 130708 file/line control occurring in the body of the construct, as these will 130709 only be seen and processed afterwards.) 130710 1307112022-04-12 Jan Beulich <jbeulich@suse.com> 130712 130713 x86: make {disp16} work similarly to {disp32} 130714 In a few places {disp32} was handled specially when really {disp16} 130715 wants handling just the same. 130716 1307172022-04-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 130718 130719 gprofng doesn't build with gcc 5.5 130720 gprofng/ChangeLog 130721 2022-04-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 130722 130723 PR gprofng/29026 130724 * configure.ac: Check version of bison. 130725 * src/Makefile.am (QLParser.yy): Run bison 130726 * src/QLParser.yy: Adapted for bison 3.04 or later. 130727 * src/DbeSession.cc: make some params const. 130728 * src/DbeSession.h: Likewise. 130729 * configure: Regenerate. 130730 * Makefile.in: Regenerate. 130731 * src/Makefile.in: Regenerate. 130732 * src/QLParser.tab.cc: Deleted. 130733 * src/QLParser.tab.hh: Deleted. 130734 * doc/Makefile.in: Regenerate. 130735 * gp-display-html/Makefile.in: Regenerate. 130736 * libcollector/configure: Regenerate. 130737 1307382022-04-12 GDB Administrator <gdbadmin@sourceware.org> 130739 130740 Automatic date update in version.in 130741 1307422022-04-11 John Baldwin <jhb@FreeBSD.org> 130743 130744 i386-fbsd-nat: Remove two unused variables. 130745 Earlier versions of the change in 130746 1285ce8629b37f800bf21731ee7c7a8b1b8d0233 used this variable, but not 130747 the final version that landed. 130748 1307492022-04-11 Simon Marchi <simon.marchi@efficios.com> 130750 130751 gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macros 130752 Replace with equivalent getter/setter macros. 130753 130754 Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2 130755 1307562022-04-11 Simon Marchi <simon.marchi@efficios.com> 130757 130758 gdb: remove minimal symbol size macros 130759 Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them 130760 with equivalent methods. 130761 130762 Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538 130763 1307642022-04-11 Simon Marchi <simon.marchi@efficios.com> 130765 130766 gdb: remove MSYMBOL_TYPE macro 130767 Add a getter and a setter for a minimal symbol's type. Remove the 130768 corresponding macro and adjust all callers. 130769 130770 Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d 130771 1307722022-04-11 Simon Marchi <simon.marchi@efficios.com> 130773 130774 gdb: remove symbol value macros 130775 Remove all macros related to getting and setting some symbol value: 130776 130777 #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue 130778 #define SYMBOL_VALUE_ADDRESS(symbol) \ 130779 #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ 130780 #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes 130781 #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block 130782 #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block 130783 #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain 130784 #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue 130785 #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) 130786 #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ 130787 #define BMSYMBOL_VALUE_ADDRESS(symbol) \ 130788 #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ 130789 #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes 130790 #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block 130791 130792 Replace them with equivalent methods on the appropriate objects. 130793 130794 Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50 130795 1307962022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130797 130798 gdb/doc: add section about Fortran intrinsic functions and types 130799 The earlier version of this document had no sections about the 130800 available Fortran intrinsic functions or the Fortran builtin types. 130801 130802 I added two sections 'Fortran intrinsics' and 'Fortran types' to 130803 document the available Fortran language features. The subsection 130804 'Fortran Defaults' has been integrated into the Fortran subsection. 130805 1308062022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130807 130808 gdb/fortran/testsuite: add complex from integers test 130809 When working on the files I noted that there was no actual test for a 130810 COMPLEX built from two INTEGERS. I added that now for completion. 130811 1308122022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130813 130814 gdb/fortran: rewrite intrinsic handling and add some missing overloads 130815 The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept 130816 (some only with Fortran 2003) the optional parameter KIND. This 130817 parameter determines the kind of the associated return value. So far, 130818 implementation of this kind parameter has been missing in GDB. 130819 Additionally, the one argument overload for the CMPLX intrinsic function 130820 was not yet available. 130821 130822 This patch adds overloads for all above mentioned functions to the 130823 Fortran intrinsics handling in GDB. 130824 130825 It re-writes the intrinsic function handling section to use the helper 130826 methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic. 130827 These methods define the action taken when a Fortran intrinsic function 130828 is called with a certain amount of arguments (1/2/3). The helper methods 130829 fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents 130830 to the existing wrap and wrap2 methods. 130831 130832 After adding more overloads to the intrinsics handling, some of the 130833 operation names were no longer accurate. E.g. UNOP_FORTRAN_CEILING 130834 has been renamed to FORTRAN_CEILING as it is no longer a purely unary 130835 intrinsic function. This patch also introduces intrinsic functions with 130836 one, two, or three arguments to the Fortran parser and the 130837 UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added. 130838 1308392022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130840 130841 gdb/fortran: rename f77_keywords to f_keywords 130842 Rename f77_keywords to f_keywords since some of the introduced keywords 130843 in the array are f90 only. 130844 1308452022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130846 130847 gdb/fortran: Change GDB print for fortran default types 130848 Currently, when asking GDB to print the type of a Fortran default type 130849 such as INTEGER or REAL, GDB will return the default name of that type, 130850 e.g. "integer"/"real": 130851 130852 (gdb) ptype integer 130853 type = integer 130854 (gdb) ptype real 130855 type = real 130856 130857 For LOGICAL and COMPLEX it would return the actual underlying types 130858 130859 (gdb) ptype logical 130860 type = logical*4 130861 (gdb) ptype complex 130862 type = complex*4 130863 130864 Similarly, GDB would print the default integer type for the underlying 130865 default type: 130866 130867 (gdb) ptype integer*4 130868 type = integer 130869 (gdb) ptype real*4 130870 type = real 130871 (gdb) ptype logical 130872 type = logical*4 130873 (gdb) ptype complex*4 130874 type = complex*4 130875 130876 This is inconsistent and a bit confusing. Both options somehow indicate 130877 what the internal underlying type for the default type is - but I think 130878 the logical/complex version is a bit clearer. 130879 130880 Consider again: 130881 130882 (gdb) ptype integer 130883 type = integer 130884 130885 This indicates to a user that the type of "integer" is Fortran's default 130886 integer type. Without examining "ptype integer*4" I would expect, that 130887 any variable declared integer in the actual code would also fit into a 130888 GDB integer. But, since we cannot adapt out internal types to the 130889 compiler flags used at compile time of a debugged binary, this might be 130890 wrong. Consider debugging Fortran code compiled with GNU and e.g. the 130891 "-fdefault-integer-8" flag. In this case the gfortran default integer 130892 would be integer*8 while GDB internally still would use a builtin_integer, 130893 so an integer of the size of an integer*4 type. On the other hand having 130894 GDB print 130895 130896 (gdb) ptype integer 130897 type = integer*4 130898 130899 makes this clearer. I would still be tempted to fit a variable declared 130900 integer in the code into a GDB integer - but at least ptype would 130901 directly tell me what is going on. Note, that when debugging a binary 130902 compiled with "-fdefault-integer-8" a user will always see the actual 130903 underlying type of any variable declared "integer" in the Fortran code. 130904 So having the code 130905 130906 program test 130907 integer :: a = 5 130908 print *, a ! breakpt 130909 end program test 130910 130911 will, when breaking at breakpt print 130912 130913 (gdb) ptype var 130914 type = integer(kind=4) 130915 130916 or 130917 130918 (gdb) ptype var 130919 type = integer(kind=8) 130920 130921 depending on the compiler flag. 130922 130923 This patch changes the outputs for the REAL and INTEGER default types to 130924 actually print the internally used type over the default type name. 130925 130926 The new behavior for the above examples is: 130927 130928 (gdb) ptype integer 130929 type = integer*4 130930 (gdb) ptype integer*4 130931 type = integer*4 130932 130933 Existing testcases have been adapted to reflect the new behavior. 130934 1309352022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 130936 130937 gdb/fortran: clean-up Fortran intrinsic types 130938 The currently implemented intrinsic type handling for Fortran missed some 130939 tokens and their parsing. While still not all Fortran type kinds are 130940 implemented this patch at least makes the currently handled types 130941 consistent. As an example for what this patch does, consider the 130942 intrinsic type INTEGER. GDB implemented the handling of the 130943 keywords "integer" and "integer_2" but missed "integer_4" and "integer_8" 130944 even though their corresponding internal types were already available as 130945 the Fortran builtin types builtin_integer and builtin_integer_s8. 130946 Similar problems applied to LOGICAL, REAL, and COMPLEX. This patch adds 130947 all missing tokens and their parsing. Whenever a section containing the 130948 type handling was touched, it also was reordered to be in a more easy to 130949 grasp order. All INTEGER/REAL/LOGICAL/COMPLEX types were grouped 130950 together and ordered ascending in their size making a missing one more 130951 easy to spot. 130952 130953 Before this change GDB would print the following when tyring to use the 130954 INTEGER keywords: 130955 130956 (gdb) set language fortran 130957 (gdb) ptype integer*1 130958 unsupported kind 1 for type integer 130959 (gdb) ptype integer_1 130960 No symbol table is loaded. Use the "file" command. 130961 (gdb) ptype integer*2 130962 type = integer*2 130963 (gdb) ptype integer_2 130964 type = integer*2 130965 (gdb) ptype integer*4 130966 type = integer 130967 (gdb) ptype integer_4 130968 No symbol table is loaded. Use the "file" command. 130969 (gdb) ptype integer*8 130970 type = integer*8 130971 (gdb) ptype integer_8 130972 No symbol table is loaded. Use the "file" command. 130973 (gdb) ptype integer 130974 type = integer 130975 130976 With this patch all keywords are available and the GDB prints: 130977 130978 (gdb) set language fortran 130979 (gdb) ptype integer*1 130980 type = integer*1 130981 (gdb) ptype integer_1 130982 type = integer*1 130983 (gdb) ptype integer*2 130984 type = integer*2 130985 (gdb) ptype integer_2 130986 type = integer*2 130987 (gdb) ptype integer*4 130988 type = integer*4 130989 (gdb) ptype integer_4 130990 type = integer*4 130991 (gdb) ptype integer*8 130992 type = integer*8 130993 (gdb) ptype integer_8 130994 type = integer*8 130995 (gdb) ptype integer 130996 type = integer 130997 130998 The described changes have been applied to INTEGER, REAL, COMPLEX, 130999 and LOGICAL. Existing testcases have been adapted to reflect the 131000 new behavior. Tests for formerly missing types have been added. 131001 1310022022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131003 131004 gdb/fortran: change default logical type to builtin_logical 131005 According to the Fortran standard, logical is of the size of a 131006 'single numeric storage unit' (just like real and integer). For 131007 gfortran, flang and ifx/ifort this storage unit (or the default 131008 logical type) is of size kind 4, actually occupying 4 bytes of 131009 storage, and so the default type for logical expressions in 131010 Fortran should probably also be Logical*4 and not Logical*2. I 131011 adapted GDB's behavior to be in line with 131012 gfortran/ifort/ifx/flang. 131013 131014 gdb/fortran: reformat build_fortran_types in f-lang.c 131015 Add a few newlines after the type definitions and remove some 131016 unnecessary linebreaks. 131017 1310182022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131019 131020 gdb/fortran: fix complex type in Fortran builtin types 131021 Before this patch things like 131022 131023 (gdb) ptype complex*8 131024 complex*16 131025 (gdb) ptype complex*4 131026 complex*8 131027 131028 were possible in GDB, which seems confusing for a user. The reason 131029 is a mixup in the implementation of the Fortran COMPLEX type. In 131030 Fortran the "*X" after a type would normally (I don't think this 131031 is language required) specify the type's size in memory. For the 131032 COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang) 131033 specify not the size of the whole type but the size of the individual 131034 two REALs used to form the COMPLEX. Thus, a COMPLEX*4 will usually 131035 consist of two REAL*4s. Internally this type was represented by a 131036 builtin_complex_s8 - but here I think the s8 actually meant the raw 131037 size of the type. This is confusing and I renamed the types (e.g. 131038 builting_complex_s8 became builtin_complex_s4 according to its most 131039 common useage) and their printed names to their language equivalent. 131040 Additionally, I added the default COMPLEX type "COMPLEX" being the same 131041 as a COMPLEX*4 (as is normally the case) and removed the latter. I added 131042 a few tests for this new behavior as well. 131043 131044 The new behavior is 131045 131046 (gdb) ptype complex*8 131047 complex*8 131048 (gdb) ptype complex*4 131049 complex*4 131050 1310512022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131052 131053 gdb/f-lang: remove hidden ^L characters 131054 131055 gdb/f-lang: add Integer*1 to Fortran builtin types 131056 Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types. 131057 1310582022-04-11 Tom de Vries <tdevries@suse.de> 131059 131060 [gdb/testsuite] Fix gdb.base/annota1.exp with pie 131061 Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more 131062 robust") we see this fail with target board unix/-fPIE/-pie: 131063 ... 131064 FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) 131065 ... 131066 131067 The problem is that the commit makes the number and order of matched 131068 annotations fixed, while between target boards unix and unix/-fPIE/-pie there 131069 is a difference: 131070 ... 131071 \032\032post-prompt 131072 Starting program: outputs/gdb.base/annota1/annota1 131073 131074 +\032\032breakpoints-invalid 131075 + 131076 \032\032starting 131077 131078 \032\032frames-invalid 131079 ... 131080 131081 Fix this by optionally matching the additional annotation. 131082 131083 Tested on x86_64-linux. 131084 1310852022-04-11 Tom de Vries <tdevries@suse.de> 131086 131087 [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp for m32 pie 131088 As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with 131089 target board unix/-m32/-fPIE/-pie, we run into: 131090 ... 131091 Breakpoint 2, 0x56555540 in bar ()^M 131092 (gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \ 131093 continue to breakpoint: foo \(1\) 131094 next^M 131095 Single stepping until exit from function bar,^M 131096 which has no line number information.^M 131097 0x56555587 in main ()^M 131098 (gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \ 131099 next to foo (2) 131100 ... 131101 131102 The problem is that the bar breakpoint ends up at an unexpected location 131103 because: 131104 - the synthetic debug info is incomplete and doesn't provide line info 131105 for the prologue part of the function, so consequently gdb uses the i386 131106 port prologue skipper to get past the prologue 131107 - the i386 port prologue skipper doesn't get past a get_pc_thunk call. 131108 131109 Work around this in the test-case by breaking on bar_label instead. 131110 131111 Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and 131112 unix/-m32/-fPIE/-pie. 131113 1311142022-04-11 GDB Administrator <gdbadmin@sourceware.org> 131115 131116 Automatic date update in version.in 131117 1311182022-04-10 GDB Administrator <gdbadmin@sourceware.org> 131119 131120 Automatic date update in version.in 131121 1311222022-04-09 Tom Tromey <tom@tromey.com> 131123 131124 Remove MSYMBOL_VALUE_CHAIN 131125 I noticed that MSYMBOL_VALUE_CHAIN is unused, so this patch removes it. 131126 1311272022-04-09 Alan Modra <amodra@gmail.com> 131128 131129 Rearrange struct bfd_section a little 131130 For better packing on 64-bit hosts. 131131 131132 * section.c (struct bfd_section): Move next and prev field earlier. 131133 Move alignment_power later. 131134 (BFD_FAKE_SECTION): Adjust to suit. 131135 * bfd-in2.h: Regenerate. 131136 1311372022-04-09 Alan Modra <amodra@gmail.com> 131138 131139 Don't run pr27228 test for hppa 131140 As the comment says, hppa doesn't support use of BFD_RELOC_* in 131141 .reloc directives. Using xfail can result in a spurious XPASS result 131142 as BFD_RELOC values change. 131143 131144 * testsuite/gas/elf/pr27228.d: Change xfail to notarget for hppa. 131145 1311462022-04-09 Alan Modra <amodra@gmail.com> 131147 131148 Correct nds32 readelf reloc numbers 131149 * readelf.c (is_32bit_abs_reloc, is_16bit_abs_reloc): Comment fixes. 131150 (is_none_reloc): Correct nds32 reloc numbers. 131151 1311522022-04-09 GDB Administrator <gdbadmin@sourceware.org> 131153 131154 Automatic date update in version.in 131155 1311562022-04-08 Fangrui Song <i@maskray.me> 131157 131158 gas: Port "copy st_size only if unset" to aarch64 and riscv 131159 And disable the new test gas/elf/size.s for alpha which uses its own 131160 .set, for hppa*-*-hpux* which does not allow .size before declaration. 131161 1311622022-04-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 131163 131164 gprofng: fprintf_styled_func not inizialized for disassembler 131165 gprofng/ChangeLog 131166 2022-04-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 131167 131168 * libcollector/unwind.c: inizialize fprintf_styled_func. 131169 * src/Disasm.cc: Likewise. 131170 1311712022-04-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 131172 131173 gprofng: zlib handling 131174 gprofng/ChangeLog 131175 2022-04-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 131176 131177 * configure.ac: Add AM_ZLIB. 131178 * src/Makefile.am: Add $(ZLIBINC) and $(ZLIB). 131179 * gprofng/src/DbeSession.h: Likewise. 131180 * configure: Regenerate. 131181 * Makefile.in: Regenerate. 131182 * doc/Makefile.in: Regenerate. 131183 * gp-display-html/Makefile.in: Regenerate. 131184 * src/Makefile.in: Regenerate. 131185 1311862022-04-08 Pedro Alves <pedro@palves.net> 131187 131188 gdb: Avoid undefined shifts, fix Go shifts 131189 I noticed that a build of GDB with GCC + --enable-ubsan, testing 131190 against GDBserver showed this GDB crash: 131191 131192 (gdb) PASS: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: advance to trace begin 131193 tstart 131194 ../../src/gdb/valarith.c:1365:15: runtime error: left shift of 48320975398096333 by 46 places cannot be represented in type 'long int' 131195 ERROR: GDB process no longer exists 131196 GDB process exited with wait status 269549 exp9 0 1 131197 UNRESOLVED: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: start trace experiment 131198 131199 The problem is that, "0x00abababcdcdcdcd << 46" is an undefined signed 131200 left shift, because the result is not representable in the type of the 131201 lhs, which is signed. This actually became defined in C++20, and if 131202 you compile with "g++ -std=c++20 -Wall", you'll see that GCC no longer 131203 warns about it, while it warns if you specify prior language versions. 131204 131205 While at it, there are a couple other situations that are undefined 131206 (and are still undefined in C++20) and result in GDB dying: shifting 131207 by a negative ammount, or by >= than the bit size of the promoted lhs. 131208 For the latter, GDB shifts using (U)LONGEST internally, so you have to 131209 shift by >= 64 bits to see it: 131210 131211 $ gdb --batch -q -ex "p 1 << -1" 131212 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent -1 is negative 131213 $ # gdb exited 131214 131215 $ gdb --batch -q -ex "p 1 << 64" 131216 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent 64 is too large for 64-bit type 'long int' 131217 $ # gdb exited 131218 131219 Also, right shifting a negative value is implementation-defined 131220 (before C++20, after which it is defined). For this, I chose to 131221 change nothing in GDB other than adding tests, as I don't really know 131222 whether we need to do anything. AFAIK, most implementations do an 131223 arithmetic right shift, and it may be we don't support any host or 131224 target that behaves differently. Plus, this becomes defined in C++20 131225 exactly as arithmetic right shift. 131226 131227 Compilers don't error out on such shifts, at best they warn, so I 131228 think GDB should just continue doing the shifts anyhow too. 131229 131230 Thus: 131231 131232 - Adjust scalar_binop to avoid the undefined paths, either by adding 131233 explicit result paths, or by casting the lhs of the left shift to 131234 unsigned, as appropriate. 131235 131236 For the shifts by a too-large count, I made the result be what you'd 131237 get if you split the large count in a series of smaller shifts. 131238 Thus: 131239 131240 Left shift, positive or negative lhs: 131241 131242 V << 64 131243 => V << 16 << 16 << 16 << 16 131244 => 0 131245 131246 Right shift, positive lhs: 131247 131248 Vpos >> 64 131249 => Vpos >> 16 >> 16 >> 16 >> 16 131250 => 0 131251 131252 Right shift, negative lhs: 131253 131254 Vneg >> 64 131255 => Vneg >> 16 >> 16 >> 16 >> 16 131256 => -1 131257 131258 This is actually Go's semantics (the compiler really emits 131259 instructions to make it so that you get 0 or -1 if you have a 131260 too-large shift). So for that language GDB does the shift and 131261 nothing else. For other C-like languages where such a shift is 131262 undefined, GDB warns in addition to performing the shift. 131263 131264 For shift by a negative count, for Go, this is a hard error. For 131265 other languages, since their compilers only warn, I made GDB warn 131266 too. The semantics I chose (we're free to pick them since this is 131267 undefined behavior) is as-if you had shifted by the count cast to 131268 unsigned, thus as if you had shifted by a too-large count, thus the 131269 same as the previous scenario illustrated above. 131270 131271 Examples: 131272 131273 (gdb) set language go 131274 (gdb) p 1 << 100 131275 $1 = 0 131276 (gdb) p -1 << 100 131277 $2 = 0 131278 (gdb) p 1 >> 100 131279 $3 = 0 131280 (gdb) p -1 >> 100 131281 $4 = -1 131282 (gdb) p -2 >> 100 131283 $5 = -1 131284 (gdb) p 1 << -1 131285 left shift count is negative 131286 131287 (gdb) set language c 131288 (gdb) p -2 >> 100 131289 warning: right shift count >= width of type 131290 $6 = -1 131291 (gdb) p -2 << 100 131292 warning: left shift count >= width of type 131293 $7 = 0 131294 (gdb) p 1 << -1 131295 warning: left shift count is negative 131296 $8 = 0 131297 (gdb) p -1 >> -1 131298 warning: right shift count is negative 131299 $9 = -1 131300 131301 - The warnings' texts are the same as what GCC prints. 131302 131303 - Add comprehensive tests in a new gdb.base/bitshift.exp testcase, so 131304 that we exercise all these scenarios. 131305 131306 Change-Id: I8bcd5fa02de3114b7ababc03e65702d86ec8d45d 131307 1313082022-04-08 Pedro Alves <pedro@palves.net> 131309 131310 Fix undefined behavior in the Fortran, Go and Pascal number parsers 131311 This commit ports these two fixes to the C parser: 131312 131313 commit ebf13736b42af47c9907b5157c8e80c78dbe00e1 131314 CommitDate: Thu Sep 4 21:46:28 2014 +0100 131315 131316 parse_number("0") reads uninitialized memory 131317 131318 commit 20562150d8a894bc91657c843ee88c508188e32e 131319 CommitDate: Wed Oct 3 15:19:06 2018 -0600 131320 131321 Avoid undefined behavior in parse_number 131322 131323 ... to the Fortran, Go, and Fortran number parsers, fixing the same 131324 problems there. 131325 131326 Also add a new testcase that exercises printing 0xffffffffffffffff 131327 (max 64-bit) in all languages, which crashes a GDB built with UBsan 131328 without the fix. 131329 131330 I moved get_set_option_choices out of all-architectures.exp.tcl to 131331 common code to be able to extract all the supported languages. I did 131332 a tweak to it to generalize it a bit -- you now have to pass down the 131333 "set" part of the command as well. This is so that the proc can be 131334 used with "maintenance set" commands as well in future. 131335 131336 Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a 131337 1313382022-04-08 Nick Clifton <nickc@redhat.com> 131339 131340 Debug info for function in Windows PE binary on wrong instruction 131341 PR 29038 131342 * coffgen.c (coff_find_nearest_line_with_names): Fix typo 131343 retrieving saved bias. 131344 1313452022-04-08 Simon Marchi <simon.marchi@efficios.com> 131346 131347 Pass PKG_CONFIG_PATH down from top-level Makefile 131348 [Sending to binutils, gdb-patches and gcc-patches, since it touches the 131349 top-level Makefile/configure] 131350 131351 I have my debuginfod library installed in a non-standard location 131352 (/opt/debuginfod), which requires me to set 131353 PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during 131354 configure: 131355 131356 $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure --with-debuginfod 131357 $ make 131358 131359 or 131360 131361 $ ./configure --with-debuginfod PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config 131362 $ make 131363 131364 Then PKG_CONFIG_PATH is only present (and ignored) during the top-level 131365 configure. When running make (which runs gdb's and binutils' 131366 configure), PKG_CONFIG_PATH is not set, which results in their configure 131367 script not finding the library: 131368 131369 checking for libdebuginfod >= 0.179... no 131370 configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable." 131371 131372 Change the top-level configure/Makefile system to capture the value 131373 passed when configuring the top-level and pass it down to 131374 subdirectories (similar to CFLAGS, LDFLAGS, etc). 131375 131376 I don't know much about the top-level build system, so I really don't 131377 know if I did this correctly. The changes are: 131378 131379 - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that 131380 @PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value 131381 in config files (i.e. Makefile) 131382 - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized 131383 to @PKG_CONFIG_PATH@ 131384 - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the 131385 variables set when running the sub-configures 131386 131387 I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but 131388 I don't think it's needed. AFAIU, this defines the flags to pass down 131389 when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to 131390 be passed down during configure. After that, it's captured in 131391 gdb/config.status, so even if a "make" causes a re-configure later 131392 (because gdb/configure has changed, for example), the PKG_CONFIG_PATH 131393 value will be remembered. 131394 131395 ChangeLog: 131396 131397 * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH). 131398 * configure: Re-generate. 131399 * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH. 131400 (PKG_CONFIG_PATH): New. 131401 * Makefile.in: Re-generate. 131402 131403 Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf 131404 1314052022-04-08 Simon Marchi <simon.marchi@efficios.com> 131406 131407 gdb/testsuite: use nopie in gdb.dwarf2/dw2-inline-param.exp 131408 I see this failure: 131409 131410 (gdb) run ^M 131411 Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M 131412 Warning:^M 131413 Cannot insert breakpoint 1.^M 131414 Cannot access memory at address 0x113b^M 131415 ^M 131416 (gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b 131417 131418 The test loads the binary in GDB, grabs the address of a symbol, strips 131419 the binary, reloads it in GDB, runs the program, and then tries to place 131420 a breakpoint at that address. The problem is that the binary is built 131421 as position independent, so the address GDB grabs in the first place 131422 isn't where the code ends up after running. 131423 131424 Fix this by linking the binary as non-position-independent. The 131425 alternative would be to compute the relocated address where to place the 131426 breakpoint, but that's not very straightforward, unfortunately. 131427 131428 I was confused for a while, I was trying to load the binary in GDB 131429 manually to get the symbol address, but GDB was telling me the symbol 131430 could not be found. Meanwhile, it clearly worked in gdb.log. The thing 131431 is that GDB strips the binary in-place, so we don't have access to the 131432 intermediary binary with symbols. Change the test to output the 131433 stripped binary to a separate file instead. 131434 131435 Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba 131436 1314372022-04-08 Alan Modra <amodra@gmail.com> 131438 131439 gdb maintainer commit rights 131440 Formalise what ought to be obvious. The top level of the binutils-gdb 131441 repository isn't owned by binutils. 131442 131443 * MAINTAINERS: Spelling fix. GDB global maintainer rights. 131444 1314452022-04-08 Bernhard Heckel <bernhard.heckel@intel.com> 131446 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131447 131448 gdb/fortran: print fortran extended types with ptype 131449 Add the print of the base-class of an extended type to the output of 131450 ptype. This requires the Fortran compiler to emit DW_AT_inheritance 131451 for the extended type. 131452 1314532022-04-08 Bernhard Heckel <bernhard.heckel@intel.com> 131454 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131455 131456 gdb/fortran: add support for accessing fields of extended types 131457 Fortran 2003 supports type extension. This patch allows access 131458 to inherited members by using their fully qualified name as described 131459 in the Fortran standard. 131460 131461 In doing so the patch also fixes a bug in GDB when trying to access the 131462 members of a base class in a derived class via the derived class' base 131463 class member. 131464 131465 This patch fixes PR22497 and PR26373 on GDB side. 131466 131467 Using the example Fortran program from PR22497 131468 131469 program mvce 131470 implicit none 131471 131472 type :: my_type 131473 integer :: my_int 131474 end type my_type 131475 131476 type, extends(my_type) :: extended_type 131477 end type extended_type 131478 131479 type(my_type) :: foo 131480 type(extended_type) :: bar 131481 131482 foo%my_int = 0 131483 bar%my_int = 1 131484 131485 print*, foo, bar 131486 131487 end program mvce 131488 131489 and running this with GDB and setting a BP at 17: 131490 131491 Before: 131492 (gdb) p bar%my_type 131493 A syntax error in expression, near `my_type'. 131494 (gdb) p bar%my_int 131495 There is no member named my_int. 131496 (gdb) p bar%my_type%my_int 131497 A syntax error in expression, near `my_type%my_int'. 131498 (gdb) p bar 131499 $1 = ( my_type = ( my_int = 1 ) ) 131500 131501 After: 131502 (gdb) p bar%my_type 131503 $1 = ( my_int = 1 ) 131504 (gdb) p bar%my_int 131505 $2 = 1 # this line requires DW_TAG_inheritance to work 131506 (gdb) p bar%my_type%my_int 131507 $3 = 1 131508 (gdb) p bar 131509 $4 = ( my_type = ( my_int = 1 ) ) 131510 131511 In the above example "p bar%my_int" requires the compiler to emit 131512 information about the inheritance relationship between extended_type 131513 and my_type which gfortran and flang currently do not de. The 131514 respective issue gcc/49475 has been put as kfail. 131515 131516 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373 131517 https://sourceware.org/bugzilla/show_bug.cgi?id=22497 131518 1315192022-04-08 Nils-Christian Kempke <nils-christian.kempke@intel.com> 131520 131521 gdb: add Nils-Christian Kempke to gdb/MAINTAINERS 131522 1315232022-04-08 Simon Marchi <simon.marchi@polymtl.ca> 131524 131525 gdb: change file_file_name to return an std::string 131526 Straightforward change, return an std::string instead of a 131527 gdb::unique_xmalloc_ptr<char>. No behavior change expected. 131528 131529 Change-Id: Ia5e94c94221c35f978bb1b7bdffbff7209e0520e 131530 1315312022-04-08 GDB Administrator <gdbadmin@sourceware.org> 131532 131533 Automatic date update in version.in 131534 1315352022-04-07 Andrew Burgess <aburgess@redhat.com> 131536 131537 gdb/fortran: fix fetching assumed rank array content 131538 Commit: 131539 131540 commit df7a7bdd9766adebc6b117c31bc617d81c1efd43 131541 Date: Thu Mar 17 18:56:23 2022 +0000 131542 131543 gdb: add support for Fortran's ASSUMED RANK arrays 131544 131545 Added support for Fortran assumed rank arrays. Unfortunately, this 131546 commit contained a bug that means though GDB can correctly calculate 131547 the rank of an assumed rank array, GDB can't fetch the contents of an 131548 assumed rank array. 131549 131550 The history of this patch can be seen on the mailing list here: 131551 131552 https://sourceware.org/pipermail/gdb-patches/2022-January/185306.html 131553 131554 The patches that were finally committed can be found here: 131555 131556 https://sourceware.org/pipermail/gdb-patches/2022-March/186906.html 131557 131558 The original patches did support fetching the array contents, it was 131559 only the later series that introduced the regression. 131560 131561 The problem is that when calculating the array rank the result is a 131562 count of the number of ranks, i.e. this is a 1 based result, 1, 2, 3, 131563 etc. 131564 131565 In contrast, when computing the details of any particular rank the 131566 value passed to the DWARF expression evaluator should be a 0 based 131567 rank offset, i.e. a 0 based number, 0, 1, 2, etc. 131568 131569 In the patches that were originally merged, this was not the case, and 131570 we were passing the 1 based rank number to the expression evaluator, 131571 e.g. passing 1 when we should pass 0, 2 when we should pass 1, etc. 131572 As a result the DWARF expression evaluator was reading the 131573 wrong (undefined) memory, and returning garbage results. 131574 131575 In this commit I have extended the test case to cover checking the 131576 array contents, I've then ensured we make use of the correct rank 131577 value, and extended some comments, and added or adjusted some asserts 131578 as appropriate. 131579 1315802022-04-07 Simon Marchi <simon.marchi@efficios.com> 131581 131582 gdb/testsuite: add "macros" option to gdb_compile 131583 Make gdb_compile handle a new "macros" option, which makes it pass the 131584 appropriate flag to make the compiler include macro information in the 131585 debug info. This will help simplify tests using macros, reduce 131586 redundant code, and make it easier to add support for a new compiler. 131587 131588 Right now it only handles clang specially (using -fdebug-macro) and 131589 falls back to -g3 otherwise (which works for gcc). Other compilers can 131590 be added as needed. 131591 131592 There are some tests that are currently skipped if the compiler is nor 131593 gcc nor clang. After this patch, the tests will attempt to run (the -g3 131594 fall back will be used). That gives a chance to people using other 131595 compilers to notice something is wrong and maybe add support for their 131596 compiler. If it is needed to support a compiler that doesn't have a way 131597 to include macro information, then we can always introduce a 131598 "skip_macro_tests" that can be used to skip over them. 131599 131600 Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b 131601 1316022022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131603 131604 gdb: remove subfile::buildsym_compunit field 131605 It is only set, never used. 131606 131607 Change-Id: Ia46ed2f9da243b0ccfc4588c1b57be2a0f3939de 131608 1316092022-04-07 Tom de Vries <tdevries@suse.de> 131610 131611 [gdb/testsuite] Make gdb.base/annota1.exp more robust 131612 On openSUSE Tumbleweed I run into: 131613 ... 131614 FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) 131615 ... 131616 131617 The problem is that the libthread_db message occurs at a location where it's 131618 not expected: 131619 ... 131620 Starting program: outputs/gdb.base/annota1/annota1 ^M 131621 ^M 131622 ^Z^Zstarting^M 131623 ^M 131624 ^Z^Zframes-invalid^M 131625 [Thread debugging using libthread_db enabled]^M 131626 Using host libthread_db library "/lib64/libthread_db.so.1".^M 131627 ^M 131628 ^Z^Zbreakpoints-invalid^M 131629 ^M 131630 ... 131631 131632 Fix this by making the matching more robust: 131633 - rewrite the regexp such that each annotation is on a single line, 131634 starting with \r\n\032\032 and ending with \r\n 131635 - add a regexp variable optional_re, that matches all possible optional 131636 output, and use it as a separator in the first part of the regexp 131637 131638 Tested on x86_64-linux. 131639 1316402022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131641 131642 gdb/testsuite/dwarf: simplify line number program syntax 131643 By calling `uplevel $body` in the program proc (a pattern we use at many 131644 places), we can get rid of curly braces around each line number program 131645 directive. That seems like a nice small improvement to me. 131646 131647 Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b 131648 1316492022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131650 131651 gdb/testsuite/dwarf: remove two unused variables 131652 These variables seem to be unused, remove them. 131653 131654 Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb 131655 1316562022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131657 131658 gdb: remove symtab::pspace 131659 Same idea as previous patch, but for symtab::pspace. 131660 131661 Change-Id: I1023abe622bea75ef648c6a97a01b53775d4104d 131662 1316632022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131664 131665 gdb: remove symtab::objfile 131666 Same idea as previous patch, but for symtab::objfile. I find 131667 it clearer without this wrapper, as it shows that the objfile is 131668 common to all symtabs of a given compunit. Otherwise, you could think 131669 that each symtab (of a given compunit) can have a specific objfile. 131670 131671 Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6 131672 1316732022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131674 131675 gdb: remove symtab::blockvector 131676 symtab::blockvector is a wrapper around compunit_symtab::blockvector. 131677 It is a bit misleadnig, as it gives the impression that a symtab has a 131678 blockvector. Remove it, change all users to fetch the blockvector 131679 through the compunit instead. 131680 131681 Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf 131682 1316832022-04-07 Simon Marchi <simon.marchi@efficios.com> 131684 131685 gdb: remove symtab::dirname 131686 I think the symtab::dirname method is bogus, or at least very 131687 misleading. It makes you think that it returns the directory that was 131688 used to find that symtab's file during compilation (i.e. the directory 131689 the file refers to in the DWARF line header file table), or the 131690 directory part of the symtab's filename maybe. In fact, it returns the 131691 compilation unit's directory, which is the CWD of the compiler, at 131692 compilation time. At least for DWARF, if the symtab's filename is 131693 relative, it will be relative to that directory. But if the symtab's 131694 filename is absolute, then the directory returned by symtab::dirname has 131695 nothing to do with the symtab's filename. 131696 131697 Remove symtab::dirname to avoid this confusion, change all users to 131698 fetch the same information through the compunit. At least, it will be 131699 clear that this is a compunit property, not a symtab property. 131700 131701 Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0 131702 1317032022-04-07 Simon Marchi <simon.marchi@polymtl.ca> 131704 131705 gdb/testsuite: make gdb_breakpoint and runto take a linespec 131706 Change gdb_breakpoint to accept a linespec, not just a function. In 131707 fact, no behavior changes are necessary, this only changes the parameter 131708 name and documentation. Change runto as well, since the two are so 131709 close (runto forwards all its arguments to gdb_breakpoint). 131710 131711 I wrote this for a downstrean GDB port, but thought it could be 131712 useful upstream, eventually, even though not callers take advantage of 131713 it yet. 131714 131715 Change-Id: I08175fd444d5a60df90fd9985e1b5dfd87c027cc 131716 1317172022-04-07 Andrew Burgess <aburgess@redhat.com> 131718 131719 gdb: update comments throughout reggroups.{c,h} files 131720 This commit updates the comments in the gdb/reggroups.{c,h} files. 131721 Fill in some missing comments, correct a few comments that were not 131722 clear, and where we had comments duplicated between .c and .h files, 131723 update the .c to reference the .h. 131724 131725 No user visible changes after this commit. 131726 1317272022-04-07 Andrew Burgess <aburgess@redhat.com> 131728 131729 gdb: move struct reggroup into reggroups.h header 131730 Move 'struct reggroup' into the reggroups.h header. Remove the 131731 reggroup_name and reggroup_type accessor functions, and just use the 131732 name/type member functions within 'struct reggroup', update all uses 131733 of these removed functions. 131734 131735 There should be no user visible changes after this commit. 131736 1317372022-04-07 Andrew Burgess <aburgess@redhat.com> 131738 131739 gdb: convert reggroup to a C++ class with constructor, etc 131740 Convert the 'struct reggroup' into a real class, with a constructor 131741 and getter methods. 131742 131743 There should be no user visible changes after this commit. 131744 1317452022-04-07 Andrew Burgess <aburgess@redhat.com> 131746 131747 gdb: make the pre-defined register groups const 131748 Convert the 7 global, pre-defined, register groups const, and fix the 131749 fall out (a minor tweak required in riscv-tdep.c). 131750 131751 There should be no user visible changes after this commit. 131752 1317532022-04-07 Andrew Burgess <aburgess@redhat.com> 131754 131755 gdb: more 'const' in gdb/reggroups.{c,h} 131756 Convert the reggroup_new and reggroup_gdbarch_new functions to return 131757 a 'const regggroup *', and fix up all the fallout. 131758 131759 There should be no user visible changes after this commit. 131760 1317612022-04-07 Andrew Burgess <aburgess@redhat.com> 131762 131763 gdb: remove reggroup_next and reggroup_prev 131764 Add a new function gdbarch_reggroups that returns a reference to a 131765 vector containing all the reggroups for an architecture. 131766 131767 Make use of this function throughout GDB instead of the existing 131768 reggroup_next and reggroup_prev functions. 131769 131770 Finally, delete the reggroup_next and reggroup_prev functions. 131771 131772 Most of these changes are pretty straight forward, using range based 131773 for loops instead of the old style look using reggroup_next. There 131774 are two places where the changes are less straight forward. 131775 131776 In gdb/python/py-registers.c, the register group iterator needed to 131777 change slightly. As the iterator is tightly coupled to the gdbarch, I 131778 just fetch the register group vector from the gdbarch when needed, and 131779 use an index counter to find the next item from the vector when 131780 needed. 131781 131782 In gdb/tui/tui-regs.c the tui_reg_next and tui_reg_prev functions are 131783 just wrappers around reggroup_next and reggroup_prev respectively. 131784 I've just inlined the logic of the old functions into the tui 131785 functions. As the tui function had its own special twist (wrap around 131786 behaviour) I think this is OK. 131787 131788 There should be no user visible changes after this commit. 131789 1317902022-04-07 Andrew Burgess <aburgess@redhat.com> 131791 131792 gdb: convert reggroups to use a std::vector 131793 Replace manual linked list with a std::vector. This commit doesn't 131794 change the reggroup_next and reggroup_prev API, but that will change 131795 in a later commit. 131796 131797 This commit is focused on the minimal changes needed to manage the 131798 reggroups using a std::vector, without changing the API exposed by the 131799 reggroup.c file. 131800 131801 There should be no user visible changes after this commit. 131802 1318032022-04-07 Andrew Burgess <aburgess@redhat.com> 131804 131805 gdb: always add the default register groups 131806 There's a set of 7 default register groups. If we don't add any 131807 gdbarch specific register groups during gdbarch initialisation, then 131808 when we iterate over the register groups using reggroup_next and 131809 reggroup_prev we will make use of these 7 default groups. See the use 131810 of default_groups in gdb/reggroups.c for details on this. 131811 131812 However, if the gdbarch adds its own groups during gdbarch 131813 initialisation, then these groups will be used in preference to the 131814 default groups. 131815 131816 A problem arises though if the particular architecture makes use of 131817 the target description mechanism. If the default target 131818 description(s) (i.e. those internal to GDB that are used when the user 131819 doesn't provide their own) don't mention any additional register 131820 groups then the default register groups will be used. 131821 131822 But if the target description does mention additional groups then the 131823 default groups are not used, and instead, the groups from the target 131824 description are used. 131825 131826 The problem with this is that what usually happens is that the target 131827 description will mention additional groups, e.g. groups for special 131828 registers. Most architectures that use target descriptions work 131829 around this by adding all (or most) of the default register groups in 131830 all cases. See i386_add_reggroups, aarch64_add_reggroups, 131831 riscv_add_reggroups, xtensa_add_reggroups, and others. 131832 131833 In this patch, my suggestion is that we should just add the default 131834 register groups for every architecture, always. This change is in 131835 gdb/reggroups.c. 131836 131837 All the remaining changes are me updating the various architectures to 131838 not add the default groups themselves. 131839 131840 So, where will this change be visible to the user? I think the 131841 following commands will possibly change: 131842 131843 * info registers / info all-registers: 131844 131845 The user can provide a register group to these commands. For example, 131846 on csky, we previously never added the 'vector' group. Now, as a 131847 default group, this will be available, but (presumably) will not 131848 contain any registers. I don't think this is necessarily a bad 131849 thing, there's something to be said for having some consistent 131850 defaults available. There are other architectures that didn't add 131851 all 7 of the defaults, which will now have gained additional groups. 131852 131853 * maint print reggroups 131854 131855 This prints the set of all available groups. As a maintenance 131856 command I'm less concerned with the output changing here. 131857 Obviously, for the architectures that didn't previously add all the 131858 defaults, this list just got bigger. 131859 131860 * maint print register-groups 131861 131862 This prints all the registers, and the groups they are in. If the 131863 defaults were not previously being added then a register (obviously) 131864 can't appear in one of the default groups. Now the groups are 131865 available then registers might be in more groups than previously. 131866 However, this is again a maintenance command, so I'm less concerned 131867 about this changing. 131868 1318692022-04-07 Andrew Burgess <aburgess@redhat.com> 131870 131871 gdb/tui: fix 'tui reg next/prev' command when data window is hidden 131872 Start GDB like: 131873 131874 $ gdb -q executable 131875 (gdb) start 131876 (gdb) layout src 131877 ... tui windows are now displayed ... 131878 (gdb) tui reg next 131879 131880 At this point the data (register) window should be displayed, but will 131881 contain the message 'Register Values Unavailable', and at the console 131882 you'll see the message "unknown register group 'next'". 131883 131884 The same happens with 'tui reg prev' (but the error message is 131885 slightly different). 131886 131887 At this point you can continue to use 'tui reg next' and/or 'tui reg 131888 prev' and you'll keep getting the error message. 131889 131890 The problem is that when the data (register) window is first 131891 displayed, it's current register group is nullptr. As a consequence 131892 tui_reg_next and tui_reg_prev (tui/tui-regs.c) will always just return 131893 nullptr, which triggers an error in tui_reg_command. 131894 131895 In this commit I change tui_reg_next and tui_reg_prev so that they 131896 instead return the first and last register group respectively if the 131897 current register group is nullptr. 131898 131899 So, after this, using 'tui reg next' will (in the above case) show the 131900 first register group, while 'tui reg prev' will display the last 131901 register group. 131902 1319032022-04-07 Andrew Burgess <aburgess@redhat.com> 131904 131905 gdb/tui: avoid theoretical bug with 'tui reg' command 131906 While looking at the 'tui reg' command as part of another patch, I 131907 spotted a theoretical bug. 131908 131909 The 'tui reg' command takes the name of a register group, but also 131910 handles partial register group matches, though the partial match has to 131911 be unique. The current command logic goes: 131912 131913 With the code as currently written, if a target description named a 131914 register group either 'prev' or 'next' then GDB would see this as an 131915 ambiguous register name, and refuse to switch groups. 131916 131917 Naming a register group 'prev' or 'next' seems pretty unlikely, but, 131918 by adding a single else block we can prevent this problem. 131919 131920 Now, if there's a 'prev' or 'next' register group, the user will not 131921 be able to select the group directly, the 'prev' and 'next' names will 131922 always iterate through the available groups instead. But at least the 131923 user could select their groups by iteration, rather than direct 131924 selection. 131925 1319262022-04-07 Andrew Burgess <aburgess@redhat.com> 131927 131928 gdb: have reggroup_find return a const 131929 Update reggroup_find to return a const reggroup *. 131930 131931 There are other function in gdb/reggroup.{c,h} files that could 131932 benefit from returning const, these will be updated in later commits. 131933 131934 There should be no user visible changes after this commit. 131935 1319362022-04-07 Andrew Burgess <aburgess@redhat.com> 131937 131938 gdb: use 'const reggroup *' in python/py-registers.c file 131939 Convert uses of 'struct reggroup *' in python/py-registers.c to be 131940 'const'. 131941 131942 There should be no user visible changes after this commit. 131943 1319442022-04-07 Andrew Burgess <aburgess@redhat.com> 131945 131946 gdb: switch to using 'const reggroup *' in tui-regs.{c,h} 131947 Make uses of 'reggroup *' const throughout tui-regs.{c,h}. 131948 131949 There should be no user visible changes after this commit. 131950 1319512022-04-07 Andrew Burgess <aburgess@redhat.com> 131952 131953 gdb: make gdbarch_register_reggroup_p take a const reggroup * 131954 Change gdbarch_register_reggroup_p to take a 'const struct reggroup *' 131955 argument. This requires a change to the gdb/gdbarch-components.py 131956 script, regeneration of gdbarch.{c,h}, and then updates to all the 131957 architectures that implement this method. 131958 131959 There should be no user visible changes after this commit. 131960 1319612022-04-07 Andrew Burgess <aburgess@redhat.com> 131962 131963 gdb: add some const in gdb/reggroups.c 131964 This commit makes the 'struct reggroup *' argument const for the 131965 following functions: 131966 131967 reggroup_next 131968 reggroup_prev 131969 reggroup_name 131970 reggroup_type 131971 131972 There are other places that could benefit from const in the 131973 reggroup.{c,h} files, but these will be changing in further commits. 131974 131975 There should be no user visible changes after this commit. 131976 1319772022-04-07 Andrew Burgess <aburgess@redhat.com> 131978 131979 gdb: don't try to use readline before it's initialized 131980 While working on a different patch, I triggered an assertion from the 131981 initialize_current_architecture code, specifically from one of 131982 the *_gdbarch_init functions in a *-tdep.c file. This exposes a 131983 couple of issues with GDB. 131984 131985 This is easy enough to reproduce by adding 'gdb_assert (false)' into a 131986 suitable function. For example, I added a line into i386_gdbarch_init 131987 and can see the following issue. 131988 131989 I start GDB and immediately hit the assert, the output is as you'd 131990 expect, except for the very last line: 131991 131992 $ ./gdb/gdb --data-directory ./gdb/data-directory/ 131993 ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed. 131994 A problem internal to GDB has been detected, 131995 further debugging may prove unreliable. 131996 ----- Backtrace ----- 131997 ... snip ... 131998 --------------------- 131999 ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed. 132000 A problem internal to GDB has been detected, 132001 further debugging may prove unreliable. 132002 Quit this debugging session? (y or n) ../../src.dev-1/gdb/ser-event.c:212:16: runtime error: member access within null pointer of type 'struct serial' 132003 132004 Something goes wrong when we try to query the user. Note, I 132005 configured GDB with --enable-ubsan, I suspect that without this the 132006 above "error" would actually just be a crash. 132007 132008 The backtrace from ser-event.c:212 looks like this: 132009 132010 (gdb) bt 10 132011 #0 serial_event_clear (event=0x675c020) at ../../src/gdb/ser-event.c:212 132012 #1 0x0000000000769456 in invoke_async_signal_handlers () at ../../src/gdb/async-event.c:211 132013 #2 0x000000000295049b in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:194 132014 #3 0x0000000001f015f8 in gdb_readline_wrapper ( 132015 prompt=0x67135c0 "../../src/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugg"...) 132016 at ../../src/gdb/top.c:1141 132017 #4 0x0000000002118b64 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) ( 132018 ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ", defchar=0 '\000', args=0x7fffffffa6e0) 132019 at ../../src/gdb/utils.c:934 132020 #5 0x0000000002118f72 in query (ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ") 132021 at ../../src/gdb/utils.c:1026 132022 #6 0x00000000021170f6 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x6107bc0 <internal_error_problem>, file=0x2b976c8 "../../src/gdb/i386-tdep.c", 132023 line=8455, fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:417 132024 #7 0x00000000021175a0 in internal_verror (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455, 132025 fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:485 132026 #8 0x00000000029503b3 in internal_error (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455, 132027 fmt=0x2b96d7f "%s: Assertion `%s' failed.") at ../../src/gdbsupport/errors.cc:55 132028 #9 0x000000000122d5b6 in i386_gdbarch_init (info=..., arches=0x0) at ../../src/gdb/i386-tdep.c:8455 132029 (More stack frames follow...) 132030 132031 It turns out that the problem is that the async event handler 132032 mechanism has been invoked, but this has not yet been initialized. 132033 132034 If we look at gdb_init (in gdb/top.c) we can indeed see the call to 132035 gdb_init_signals is after the call to initialize_current_architecture. 132036 132037 If I reorder the calls, moving gdb_init_signals earlier, then the 132038 initial error is resolved, however, things are still broken. I now 132039 see the same "Quit this debugging session? (y or n)" prompt, but when 132040 I provide an answer and press return GDB immediately crashes. 132041 132042 So what's going on now? The next problem is that the call_readline 132043 field within the current_ui structure is not initialized, and this 132044 callback is invoked to process the reply I entered. 132045 132046 The problem is that call_readline is setup as a result of calling 132047 set_top_level_interpreter, which is called from captured_main_1. 132048 Unfortunately, set_top_level_interpreter is called after gdb_init is 132049 called. 132050 132051 I wondered how to solve this problem for a while, however, I don't 132052 know if there's an easy "just reorder some lines" solution here. 132053 Looking through captured_main_1 there seems to be a bunch of 132054 dependencies between printing various things, parsing config files, 132055 and setting up the interpreter. I'm sure there is a solution hiding 132056 in there somewhere.... I'm just not sure I want to spend any longer 132057 looking for it. 132058 132059 So. 132060 132061 I propose a simpler solution, more of a hack/work-around. In utils.c 132062 we already have a function filtered_printing_initialized, this is 132063 checked in a few places within internal_vproblem. In some of these 132064 cases the call gates whether or not GDB will query the user. 132065 132066 My proposal is to add a new readline_initialized function, which 132067 checks if the current_ui has had readline initialized yet. If this is 132068 not the case then we should not attempt to query the user. 132069 132070 After this change GDB prints the error message, the backtrace, and 132071 then aborts (including dumping core). This actually seems pretty sane 132072 as, if GDB has not yet made it through the initialization then it 132073 doesn't make much sense to allow the user to say "no, I don't want to 132074 quit the debug session" (I think). 132075 1320762022-04-07 Luis Machado <luis.machado@arm.com> 132077 132078 Recognize the NT_ARM_SYSTEM_CALL register set 132079 Update binutils to recognize the NT_ARM_SYSTEM_CALL set that is dumped by 132080 Linux to core files. 132081 1320822022-04-07 Mark Harmstone <mark@harmstone.com> 132083 132084 Add support for COFF secidx relocations 132085 bfd * coff-i386.c (in_reloc_p): Add R_SECTION. 132086 (howto_table): Add R_SECTION. 132087 (coff_pe_i386_relocation_section): Add support for R_SECTION. 132088 (coff_i386_reloc_type_lookup): Add support for 132089 BFD_RELOC_16_SECCIDX. 132090 * coff-x86_64.c (in_reloc_p): Add R_SECTION. 132091 (howto_table): Add R_SECTION. 132092 (coff_pe_amd64_relocation_section): Add support for R_SECTION. 132093 (coff_amd64_reloc_type_lookup): Add support for 132094 BFD_RELOC_16_SECCIDX. 132095 * reloc.c: Add BFD_RELOC_16_SECIDX. 132096 * bfd-in2.h: Regenerate. 132097 * libbfd.h: Regenerate. 132098 132099 gas * config/tc-i386.c (pe_directive_secidx): New function. 132100 (md_pseudo_table): Add support for secidx. 132101 (x86_cons_fix_new): Likewise. 132102 (tc_gen_reloc): Likewise. 132103 * expr.c (op_rank): Add O_secidx. 132104 * expr.h (operatorT): Likewise. 132105 * symbols.c (resolve_symbol_value): Add support for O_secidx. 132106 * testsuite/gas/i386/secidx.s: New test source file. 132107 * testsuite/gas/i386/secidx.d: New test driver file. 132108 * testsuite/gas/i386/i386.exp: Run new test. 132109 132110 include * coff/i386.h: Define R_SECTION. 132111 * coff/x86_64.h: Likewise. 132112 132113 ld * testsuite/ld-pe/secidx1.s: New test source file. 132114 * testsuite/ld-pe/secidx2.s: New test source file. 132115 * testsuite/ld-pe/secidx.d: New test driver file. 132116 * testsuite/ld-pe/secidx_64.d: New test driver file. 132117 * testsuite/ld-pe/pe.exp: Add new tests. 132118 1321192022-04-07 Jan Beulich <jbeulich@suse.com> 132120 132121 gas/Dwarf: record functions 132122 To help tools like addr2line looking up function names, in particular 132123 when dealing with e.g. PE/COFF binaries (linked from ELF objects), where 132124 there's no ELF symbol table to fall back to, emit minimalistic 132125 information for functions marked as such and having their size 132126 specified. 132127 132128 Notes regarding the restriction to (pure) ELF: 132129 - I realize this is a layering violation; I don't see how to deal with 132130 that in a better way. 132131 - S_GET_SIZE(), when OBJ_MAYBE_ELF is defined, looks wrong: Unlike 132132 S_SET_SIZE() it does not check whether the hook is NULL. 132133 - symbol_get_obj(), when OBJ_MAYBE_ELF is defined, looks unusable, as 132134 its return type can only ever be one object format's type (and this 132135 may then not be ELF's). 132136 132137 The new testcases are limited to x86 because I wanted to include the 132138 case where function size can't be determined yet at the time Dwarf2 info 132139 is generated. As .nops gains support by further targets, they could also 132140 be added here then (with, as necessary, expecations suitably relaxed to 132141 cover for insn size differences). 132142 1321432022-04-07 Jan Beulich <jbeulich@suse.com> 132144 132145 Arm64: arrange for line number emission for .inst 132146 Just like insns encoded the more conventional way these should have line 132147 number info associated with them. 132148 132149 Arm32: arrange for line number emission for .inst 132150 Just like insns encoded the more conventional way these should have line 132151 number info associated with them. 132152 132153 RISC-V: add testcase to check line number emission for .insn 132154 Since no such test looks to exist, derive one from insn.s. 132155 1321562022-04-07 Andreas Krebbel <krebbel@linux.ibm.com> 132157 132158 IBM zSystems: Add support for z16 as CPU name. 132159 So far z16 was identified as arch14. After the machine has been 132160 announced we can now add the real name. 132161 132162 gas/ChangeLog: 132163 132164 * config/tc-s390.c (s390_parse_cpu): Add z16 as alternate CPU 132165 name. 132166 * doc/as.texi: Add z16 and arch14 to CPU string list. 132167 * doc/c-s390.texi: Add z16 to CPU string list. 132168 132169 opcodes/ChangeLog: 132170 132171 * s390-mkopc.c (main): Enable z16 as CPU string in the opcode 132172 table. 132173 1321742022-04-07 GDB Administrator <gdbadmin@sourceware.org> 132175 132176 Automatic date update in version.in 132177 1321782022-04-06 Youling Tang <tangyouling@loongson.cn> 132179 132180 gdb: mips: Fix the handling of complex type of function return value 132181 $ objdump -d outputs/gdb.base/varargs/varargs 132182 00000001200012e8 <find_max_float_real>: 132183 ... 132184 1200013b8: c7c10000 lwc1 $f1,0(s8) 132185 1200013bc: c7c00004 lwc1 $f0,4(s8) 132186 1200013c0: 46000886 mov.s $f2,$f1 132187 1200013c4: 46000046 mov.s $f1,$f0 132188 1200013c8: 46001006 mov.s $f0,$f2 132189 1200013cc: 46000886 mov.s $f2,$f1 132190 1200013d0: 03c0e825 move sp,s8 132191 1200013d4: dfbe0038 ld s8,56(sp) 132192 1200013d8: 67bd0080 daddiu sp,sp,128 132193 1200013dc: 03e00008 jr ra 132194 1200013e0: 00000000 nop 132195 132196 From the above disassembly, we can see that when the return value of the 132197 function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value 132198 will be passed through $f0 and $f2, so fix the corresponding processing 132199 in mips_n32n64_return_value(). 132200 132201 $ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test' 132202 132203 Before applying the patch: 132204 FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4) 132205 FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4) 132206 132207 # of expected passes 9 132208 # of unexpected failures 2 132209 132210 After applying the patch: 132211 # of expected passes 11 132212 132213 This also fixes: 132214 FAIL: gdb.base/callfuncs.exp: call inferior func with struct - returns float _Complex 132215 132216 Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk> 132217 1322182022-04-06 Tom Tromey <tom@tromey.com> 132219 132220 Use new and delete in jit.c 132221 This changes jit.c to use new and delete, rather than XCNEW. This 132222 simplifies the code a little. This was useful for another patch I'm 132223 working on, and I thought it would make sense to send it separately. 132224 132225 Regression tested on x86-64 Fedora 34. 132226 1322272022-04-06 Simon Marchi <simon.marchi@efficios.com> 132228 132229 gdb: don't copy entirely optimized out values in value_copy 132230 Bug 28980 shows that trying to value_copy an entirely optimized out 132231 value causes an internal error. The original bug report involves MI and 132232 some Python pretty printer, and is quite difficult to reproduce, but 132233 another easy way to reproduce (that is believed to be equivalent) was 132234 proposed: 132235 132236 $ ./gdb -q -nx --data-directory=data-directory -ex "py print(gdb.Value(gdb.Value(5).type.optimized_out()))" 132237 /home/smarchi/src/binutils-gdb/gdb/value.c:1731: internal-error: value_copy: Assertion `arg->contents != nullptr' failed. 132238 132239 This is caused by 5f8ab46bc691 ("gdb: constify parameter of 132240 value_copy"). It added an assertion that the contents buffer is 132241 allocated if the value is not lazy: 132242 132243 if (!value_lazy (val)) 132244 { 132245 gdb_assert (arg->contents != nullptr); 132246 132247 This was based on the comment on value::contents, which suggest that 132248 this is the case: 132249 132250 /* Actual contents of the value. Target byte-order. NULL or not 132251 valid if lazy is nonzero. */ 132252 gdb::unique_xmalloc_ptr<gdb_byte> contents; 132253 132254 However, it turns out that it can also be nullptr also if the value is 132255 entirely optimized out, for example on exit of 132256 allocate_optimized_out_value. That function creates a lazy value, marks 132257 the entire value as optimized out, and then clears the lazy flag. But 132258 contents remains nullptr. 132259 132260 This wasn't a problem for value_copy before, because it was calling 132261 value_contents_all_raw on the input value, which caused contents to be 132262 allocated before doing the copy. This means that the input value to 132263 value_copy did not have its contents allocated on entry, but had it 132264 allocated on exit. The result value had it allocated on exit. And that 132265 we copied bytes for an entirely optimized out value (i.e. meaningless 132266 bytes). 132267 132268 From here I see two choices: 132269 132270 1. respect the documented invariant that contents is nullptr only and 132271 only if the value is lazy, which means making 132272 allocate_optimized_out_value allocate contents 132273 2. extend the cases where contents can be nullptr to also include 132274 values that are entirely optimized out (note that you could still 132275 have some entirely optimized out values that do have contents 132276 allocated, it depends on how they were created) and adjust 132277 value_copy accordingly 132278 132279 Choice #1 is safe, but less efficient: it's not very useful to allocate 132280 a buffer for an entirely optimized out value. It's even a bit less 132281 efficient than what we had initially, because values coming out of 132282 allocate_optimized_out_value would now always get their contents 132283 allocated. 132284 132285 Choice #2 would be more efficient than what we had before: giving an 132286 optimized out value without allocated contents to value_copy would 132287 result in an optimized out value without allocated contents (and the 132288 input value would still be without allocated contents on exit). But 132289 it's more risky, since it's difficult to ensure that all users of the 132290 contents (through the various_contents* accessors) are all fine with 132291 that new invariant. 132292 132293 In this patch, I opt for choice #2, since I think it is a better 132294 direction than choice #1. #1 would be a pessimization, and if we go 132295 this way, I doubt that it will ever be revisited, it will just stay that 132296 way forever. 132297 132298 Add a selftest to test this. I initially started to write it as a 132299 Python test (since the reproducer is in Python), but a selftest is more 132300 straightforward. 132301 132302 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28980 132303 Change-Id: I6e2f5c0ea804fafa041fcc4345d47064b5900ed7 132304 1323052022-04-06 Jeff Law <jeffreyalaw@gmail.com> 132306 132307 Fix for v850e divq instruction 132308 This is the last of the correctness fixes I've been carrying around for the 132309 v850. 132310 132311 Like the other recent fixes, this is another case where we haven't been as 132312 careful as we should WRT host vs target types. For the divq instruction 132313 both operands are 32 bit types. Yet in the simulator code we convert them 132314 from unsigned int to signed long by assignment. So 0xfffffffb (aka -5) 132315 turns into 4294967291 and naturally that changes the result of our division. 132316 132317 The fix is simple, insert a cast to int32_t to force interpretation as a 132318 signed value. 132319 132320 Testcase for the simulator is included. It has a trivial dependency on the 132321 bins patch. 132322 1323232022-04-06 Jeff Law <jeffreyalaw@gmail.com> 132324 132325 Fix "bins" simulation for v850e3v5 132326 I've been carrying this for a few years. One test in the GCC testsuite is 132327 failing due to a bug in the handling of the v850e3v5 instruction "bins". 132328 132329 When the "bins" instruction specifies a 32bit bitfield size, the simulator 132330 exhibits undefined behavior by trying to shift a 32 bit quantity by 32 bits. 132331 In the case of a 32 bit shift, we know what the resultant mask should be. So 132332 we can just set it. 132333 132334 That seemed better than using 1UL for the constant (on a 32bit host unsigned 132335 long might still just be 32 bits) or needlessly forcing everything to 132336 long long types. 132337 132338 Thankfully the case where this shows up is only bins <src>, 0, 32, <dest> 132339 which would normally be encoded as a simple move. 132340 132341 * testsuite/v850/allinsns.exp: Add v850e3v5. 132342 * testsuite/v850/bins.cgs: New test. 132343 * v850/simops.c (v850_bins): Avoid undefined behavior on left shift. 132344 1323452022-04-06 Tiezhu Yang <yangtiezhu@loongson.cn> 132346 132347 gdb: LoongArch: prepend tramp frame unwinder for signal 132348 Implement the "init" method of struct tramp_frame to prepend tramp 132349 frame unwinder for signal on LoongArch. 132350 132351 With this patch, the following failed testcases can be fixed: 132352 132353 FAIL: gdb.base/annota1.exp: backtrace @ signal handler (timeout) 132354 FAIL: gdb.base/annota3.exp: backtrace @ signal handler (pattern 2) 132355 1323562022-04-06 Andrew Burgess <aburgess@redhat.com> 132357 132358 gdb: make interp_add static 132359 Since this commit: 132360 132361 commit 8322445e0584be846f5873b9aab257dc9fbda05d 132362 Date: Tue Jun 21 01:11:45 2016 +0100 132363 132364 Introduce interpreter factories 132365 132366 Interpreters should be registered with GDB, not by calling interp_add, 132367 but with a call to interp_factory_register. I've checked the insight 132368 source, and it too has moved over to using interp_factory_register. 132369 132370 In this commit I make interp_add static within interps.c. 132371 132372 There should be no user visible change after this commit. 132373 1323742022-04-06 Nick Clifton <nickc@redhat.com> 132375 132376 Add code to display the contents of .debug_loclists sections which contain offset entry tables. 132377 PR 28981 132378 * dwarf.c (fetch_indexed_value): Rename to fecth_indexed_addr and 132379 return the address, rather than a string. 132380 (fetch_indexed_value): New function - returns a value indexed by a 132381 DW_FORM_loclistx or DW_FORM_rnglistx form. 132382 (read_and_display_attr_value): Add support for DW_FORM_loclistx 132383 and DW_FORM_rnglistx. 132384 (process_debug_info): Load the loclists and rnglists sections. 132385 (display_loclists_list): Add support for DW_LLE_base_addressx, 132386 DW_LLE_startx_endx, DW_LLE_startx_length and 132387 DW_LLE_default_location. 132388 (display_offset_entry_loclists): New function. Displays a 132389 .debug_loclists section that contains offset entry tables. 132390 (display_debug_loc): Call the new function. 132391 (display_debug_rnglists_list): Add support for 132392 DW_RLE_base_addressx, DW_RLE_startx_endx and DW_RLE_startx_length. 132393 (display_debug_ranges): Display the contents of the section's 132394 header. 132395 * dwarf.h (struct debug_info): Add loclists_base field. 132396 * testsuite/binutils-all/dw5.W: Update expected output. 132397 * testsuite/binutils-all/x86-64/pr26808.dump: Likewise. 132398 1323992022-04-06 Luis Machado <luis.machado@linaro.org> 132400 132401 Enable ARMv8.1-m PACBTI support 132402 This set of changes enable support for the ARMv8.1-m PACBTI extensions [1]. 132403 132404 The goal of the PACBTI extensions is similar in scope to that of a-profile 132405 PAC/BTI (aarch64 only), but the underlying implementation is different. 132406 132407 One important difference is that the pointer authentication code is stored 132408 in a separate register, thus we don't need to mask/unmask the return address 132409 from a function in order to produce a correct backtrace. 132410 132411 The patch introduces the following modifications: 132412 132413 - Extend the prologue analyser for 32-bit ARM to handle some instructions 132414 from ARMv8.1-m PACBTI: pac, aut, pacg, autg and bti. Also keep track of 132415 return address signing/authentication instructions. 132416 132417 - Adds code to identify object file attributes that indicate the presence of 132418 ARMv8.1-m PACBTI (Tag_PAC_extension, Tag_BTI_extension, Tag_PACRET_use and 132419 Tag_BTI_use). 132420 132421 - Adds support for DWARF pseudo-register RA_AUTH_CODE, as described in the 132422 aadwarf32 [2]. 132423 132424 - Extends the dwarf unwinder to track the value of RA_AUTH_CODE. 132425 132426 - Decorates backtraces with the "[PAC]" identifier when a frame has signed 132427 the return address. 132428 132429 - Makes GDB aware of a new XML feature "org.gnu.gdb.arm.m-profile-pacbti". This 132430 feature is not included as an XML file on GDB's side because it is only 132431 supported for bare metal targets. 132432 132433 - Additional documentation. 132434 132435 [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension 132436 [2] https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst 132437 1324382022-04-06 Andrew Burgess <aburgess@redhat.com> 132439 132440 gdb: move gdb_disassembly_flag into a new disasm-flags.h file 132441 While working on the disassembler I was getting frustrated. Every 132442 time I touched disasm.h it seemed like every file in GDB would need to 132443 be rebuilt. Surely the disassembler can't be required by that many 132444 parts of GDB, right? 132445 132446 Turns out that disasm.h is included in target.h, so pretty much every 132447 file was being rebuilt! 132448 132449 The only thing from disasm.h that target.h needed is the 132450 gdb_disassembly_flag enum, as this is part of the target_ops api. 132451 132452 In this commit I move gdb_disassembly_flag into its own file. This is 132453 then included in target.h and disasm.h, after which, the number of 132454 files that depend on disasm.h is much reduced. 132455 132456 I also audited all the other includes of disasm.h and found that the 132457 includes in mep-tdep.c and python/py-registers.c are no longer needed, 132458 so I've removed these. 132459 132460 Now, after changing disasm.h, GDB rebuilds much quicker. 132461 132462 There should be no user visible changes after this commit. 132463 1324642022-04-06 GDB Administrator <gdbadmin@sourceware.org> 132465 132466 Automatic date update in version.in 132467 1324682022-04-05 Tom Tromey <tom@tromey.com> 132469 132470 Introduce wrapped_file 132471 Simon pointed out that timestamped_file probably needed to implement a 132472 few more methods. This patch introduces a new file-wrapping file that 132473 forwards most of its calls, making it simpler to implement new such 132474 files. It also converts timestamped_file and pager_file to use it. 132475 132476 Regression tested on x86-64 Fedora 34. 132477 1324782022-04-05 Tom Tromey <tromey@adacore.com> 132479 132480 Don't call init_thread_list in windows-nat.c 132481 I don't think there's any need to call init_thread_list in 132482 windows-nat.c. This patch removes it. I tested this using the 132483 internal AdaCore test suite on Windows, which FWIW does include some 132484 multi-threaded inferiors. 132485 1324862022-04-05 Simon Marchi <simon.marchi@efficios.com> 132487 132488 gdb/testsuite: fix intermittent failure in gdb.base/vfork-follow-parent.exp 132489 Tom de Vries reported some failures in this test: 132490 132491 continue 132492 Continuing. 132493 [New inferior 2 (process 14967)] 132494 132495 Thread 1.1 "vfork-follow-pa" hit Breakpoint 2, break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23 132496 23 } 132497 (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 132498 inferior 1 132499 [Switching to inferior 1 [process 14961] (/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vfork-follow-parent)] 132500 [Switching to thread 1.1 (process 14961)] 132501 #0 break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23 132502 23 } 132503 (gdb) PASS: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 132504 continue 132505 Continuing. 132506 [Inferior 2 (process 14967) exited normally] 132507 (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (the program exited) 132508 132509 Here, we continue both the vfork parent and child, since 132510 schedule-multiple is on. The child exits, which un-freezes the parent 132511 and makes an exit event available to GDB. We expect GDB to consume this 132512 exit event and present it to the user. Here, we see that GDB shows the 132513 parent hitting a breakpoint before showing the child exit. 132514 132515 Because of the vfork, we know that chronologically, the child exiting 132516 must have happend before the parent hitting a breakpoint. However, 132517 scheduling being what it is, it is possible for the parent to un-freeze 132518 and exit quickly, such that when GDB pulls events out of the kernel, 132519 exit events for both processes are available. And then, GDB may chose 132520 at random to return the one for the parent first. This is what I 132521 imagine what causes the failure shown above. 132522 132523 We could change the test to expect both possible outcomes, but I wanted 132524 to avoid complicating the .exp file that way. Instead, add a variable 132525 that the parent loops on that we set only after we confirmed the exit of 132526 the child. That should ensure that the order is always the same. 132527 132528 Note that I wasn't able to reproduce the failure, so I can't tell if 132529 this fix really fixes the problem. 132530 132531 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29021 132532 Change-Id: Ibc8e527e0e00dac54b22021fe4d9d8ab0f3b28ad 132533 1325342022-04-05 Simon Marchi <simon.marchi@efficios.com> 132535 132536 gdb/testsuite: fix intermittent failures in gdb.mi/mi-cmd-user-context.exp 132537 I got failures like this once on a CI: 132538 132539 frame^M 132540 &"frame\n"^M 132541 ~"#0 child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M 132542 ~"33\t dummy = !dummy; /* thread loop line */\n"^M 132543 ^done^M 132544 (gdb) ^M 132545 FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output) 132546 132547 The problem is that the test expects the following regexp: 132548 132549 ".*#0 0x.*" 132550 132551 And that typically works, when the output of the frame command looks 132552 like: 132553 132554 #0 0x00005555555551bb in child_sub_function () at ... 132555 132556 Note the lack of hexadecimal address in the failing case. Whether or 132557 not the hexadecimal address is printed (roughly) depends on whether the 132558 current PC is at the beginning of a line. So depending on where thread 132559 2 was when GDB stopped it (after thread 1 hit its breakpoint), we can 132560 get either output. Adjust the regexps to not expect an hexadecimal 132561 prefix (0x) but a function name instead (either child_sub_function or 132562 child_function). That one is always printed, and is also a good check 132563 that we are in the frame we expect. 132564 132565 Note that for test "frame 5", we are showing a pthread frame (on my 132566 system), so the function name is internal to pthread, not something we 132567 can rely on. In that case, it's almost certain that we are not at the 132568 beginning of a line, or that we don't have debug info, so I think it's 132569 fine to expect the hex prefix. 132570 132571 And for test "frame 6", it's ok to _not_ expect a hex prefix (what the 132572 test currently does), since we are showing thread 1, which has hit a 132573 breakpoint placed at the beginning of a line. 132574 132575 When testing this, Tom de Vries pointed out that the current test code 132576 doesn't ensure that the child threads are in child_sub_function when 132577 they are stopped. If the scheduler chooses so, it is possible for the 132578 child threads to be still in the pthread_barrier_wait or child_function 132579 functions when they get stopped. So that would be another racy failure 132580 waiting to happen. 132581 132582 The only way I can think of to ensure the child threads are in the 132583 child_sub_function function when they get stopped is to synchronize the 132584 threads using some variables instead of pthread_barrier_wait. So, 132585 replace the barrier with an array of flags (one per child thread). Each 132586 child thread flips its flag in child_sub_function to allow the main 132587 thread to make progress and eventually hit the breakpoint. 132588 132589 I copied user-selected-context-sync.c to a new mi-cmd-user-context.c and 132590 made modifications to that, to avoid interfering with 132591 user-selected-context-sync.exp. 132592 132593 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29025 132594 Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90 132595 1325962022-04-05 Luis Machado <luis.machado@arm.com> 132597 132598 Fix qRcmd error code parsing 132599 Someone at IRC spotted a bug in qRcmd handling. This looks like an oversight 132600 or it is that way for historical reasons. 132601 132602 The code in gdb/remote.c:remote_target::rcmd uses isdigit instead of 132603 isxdigit. One could argue that we are expecting decimal numbers, but further 132604 below we use fromhex (). 132605 132606 Update the function to use isxdigit instead and also update the documentation. 132607 132608 I see there are lots of other cases of undocumented number format for error 132609 messages, mostly described as NN instead of nn. For now I'll just update 132610 this particular function. 132611 1326122022-04-05 Simon Marchi <simon.marchi@efficios.com> 132613 132614 gdb: resume ongoing step after handling fork or vfork 132615 The test introduced by this patch would fail in this configuration, with 132616 the native-gdbserver or native-extended-gdbserver boards: 132617 132618 FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=2: next to for loop 132619 132620 The problem is that the step operation is forgotten when handling the 132621 fork/vfork. With "debug infrun" and "debug remote", it looks like this 132622 (some lines omitted for brevity). We do the next: 132623 132624 [infrun] proceed: enter 132625 [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT 132626 [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154304.0] at 0x5555555553bf 132627 [infrun] do_target_resume: resume_ptid=4154304.0.0, step=1, sig=GDB_SIGNAL_0 132628 [remote] Sending packet: $vCont;r5555555553bf,5555555553c4:p3f63c0.3f63c0;c:p3f63c0.-1#cd 132629 [infrun] proceed: exit 132630 132631 We then handle a fork event: 132632 132633 [infrun] fetch_inferior_event: enter 132634 [remote] wait: enter 132635 [remote] Packet received: T05fork:p3f63ee.3f63ee;06:0100000000000000;07:b08e59f6ff7f0000;10:bf60e8f7ff7f0000;thread:p3f63c0.3f63c6;core:17; 132636 [remote] wait: exit 132637 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 132638 [infrun] print_target_wait_results: 4154304.4154310.0 [Thread 4154304.4154310], 132639 [infrun] print_target_wait_results: status->kind = FORKED, child_ptid = 4154350.4154350.0 132640 [infrun] handle_inferior_event: status->kind = FORKED, child_ptid = 4154350.4154350.0 132641 [remote] Sending packet: $D;3f63ee#4b 132642 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154310.0] at 0x7ffff7e860bf 132643 [infrun] do_target_resume: resume_ptid=4154304.0.0, step=0, sig=GDB_SIGNAL_0 132644 [remote] Sending packet: $vCont;c:p3f63c0.-1#73 132645 [infrun] fetch_inferior_event: exit 132646 132647 In the first snippet, we resume the stepping thread with the range-stepping (r) 132648 vCont command. But after handling the fork (detaching the fork child), we 132649 resumed the whole process freely. The stepping thread, which was paused by 132650 GDBserver while reporting the fork event, was therefore resumed freely, instead 132651 of confined to the addresses of the stepped line. Note that since this 132652 is a "next", it could be that we have entered a function, installed a 132653 step-resume breakpoint, and it's ok to continue freely the stepping 132654 thread, but that's not the case here. The two snippets shown above were 132655 next to each other in the logs. 132656 132657 For the fork case, we can resume stepping right after handling the 132658 event. 132659 132660 However, for the vfork case, where we are waiting for the 132661 external child process to exec or exit, we only resume the thread that 132662 called vfork, and keep the others stopped (see patch "gdb: fix handling of 132663 vfork by multi-threaded program" prior in this series). So we can't 132664 resume the stepping thread right now. Instead, do it after handling the 132665 vfork-done event. 132666 132667 Change-Id: I92539c970397ce880110e039fe92b87480f816bd 132668 1326692022-04-05 Simon Marchi <simon.marchi@polymtl.ca> 132670 132671 gdb/remote: remove_new_fork_children don't access target_waitstatus::child_ptid if kind == TARGET_WAITKIND_THREAD_EXITED 132672 Following the previous patch, running 132673 gdb.threads/forking-threads-plus-breakpoints.exp continuously eventually 132674 gives me an internal error. 132675 132676 gdb/target/waitstatus.h:372: internal-error: child_ptid: Assertion `m_kind == TARGET_WAITKIND_FORKED || m_kind == TARGET_WAITKIND_VFORKED' failed.^M 132677 FAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=0: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error) 132678 132679 The backtrace is: 132680 132681 0x55925b679c85 internal_error(char const*, int, char const*, ...) 132682 /home/simark/src/binutils-gdb/gdbsupport/errors.cc:55 132683 0x559258deadd2 target_waitstatus::child_ptid() const 132684 /home/simark/src/binutils-gdb/gdb/target/waitstatus.h:372 132685 0x55925a7cbac9 remote_target::remove_new_fork_children(threads_listing_context*) 132686 /home/simark/src/binutils-gdb/gdb/remote.c:7311 132687 0x55925a79dfdb remote_target::update_thread_list() 132688 /home/simark/src/binutils-gdb/gdb/remote.c:3981 132689 0x55925ad79b83 target_update_thread_list() 132690 /home/simark/src/binutils-gdb/gdb/target.c:3793 132691 0x55925addbb15 update_thread_list() 132692 /home/simark/src/binutils-gdb/gdb/thread.c:2031 132693 0x559259d64838 stop_all_threads(char const*, inferior*) 132694 /home/simark/src/binutils-gdb/gdb/infrun.c:5104 132695 0x559259d88b45 keep_going_pass_signal 132696 /home/simark/src/binutils-gdb/gdb/infrun.c:8215 132697 0x559259d8951b keep_going 132698 /home/simark/src/binutils-gdb/gdb/infrun.c:8251 132699 0x559259d78835 process_event_stop_test 132700 /home/simark/src/binutils-gdb/gdb/infrun.c:6858 132701 0x559259d750e9 handle_signal_stop 132702 /home/simark/src/binutils-gdb/gdb/infrun.c:6580 132703 0x559259d6c07b handle_inferior_event 132704 /home/simark/src/binutils-gdb/gdb/infrun.c:5832 132705 0x559259d57db8 fetch_inferior_event() 132706 /home/simark/src/binutils-gdb/gdb/infrun.c:4222 132707 132708 Indeed, the code accesses target_waitstatus::child_ptid when the kind 132709 is TARGET_WAITKIND_THREAD_EXITED, which is not right. A 132710 TARGET_WAITKIND_THREAD_EXITED event does not have a child_ptid value 132711 associated, it has an exit status, which we are not interested in. The 132712 intent is to remove from the thread list the thread that has exited. 132713 Its ptid is found in the stop reply event, get it from there. 132714 132715 Change-Id: Icb298cbb80b8779fdf0c660dde9a5314d5591535 132716 1327172022-04-05 Simon Marchi <simon.marchi@efficios.com> 132718 132719 gdbserver: report correct status in thread stop race condition 132720 The test introduced by the following patch would sometimes fail in this 132721 configuration: 132722 132723 FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=14: next to for loop 132724 132725 The test has multiple threads constantly forking or vforking while the 132726 main thread keep doing "next"s. 132727 132728 (After writing the commit message, I realized this also fixes a similar 132729 failure in gdb.threads/forking-threads-plus-breakpoint.exp with the 132730 native-gdbserver and native-extended-gdbserver boards.) 132731 132732 As stop_all_threads is called, because the main thread finished its 132733 "next", it inevitably happens at some point that we ask the remote 132734 target to stop a thread and wait() reports that this thread stopped with 132735 a fork or vfork event, instead of the SIGSTOP we sent to try to stop it. 132736 132737 While running this test, I attached to GDBserver and stopped at 132738 linux-low.cc:3626. We can see that the status pulled from the kernel 132739 for 2742805 is indeed a vfork event: 132740 132741 (gdb) p/x w 132742 $3 = 0x2057f 132743 (gdb) p WIFSTOPPED(w) 132744 $4 = true 132745 (gdb) p WSTOPSIG(w) 132746 $5 = 5 132747 (gdb) p/x (w >> 8) & (PTRACE_EVENT_VFORK << 8) 132748 $6 = 0x200 132749 132750 However, the statement at line 3626 overrides that: 132751 132752 ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w))); 132753 132754 OURSTATUS becomes "stopped by a SIGTRAP". The information about the 132755 fork or vfork is lost. 132756 132757 It's then all downhill from there, stop_all_threads eventually asks for 132758 a thread list update. That thread list includes the child of that 132759 forgotten fork or vfork, the remote target goes "oh cool, a new process, 132760 let's attach to it!", when in fact that vfork child's destiny was to be 132761 detached. 132762 132763 My reverse-engineered understanding of the code around there is that the 132764 if/else between lines 3562 and 3583 (in the original code) makes sure 132765 OURSTATUS is always initialized (not "ignore"). Either the details are 132766 already in event_child->waitstatus (in the case of fork/vfork, for 132767 example), in which case we just copy event_child->waitstatus to 132768 ourstatus. Or, if the event is a plain "stopped by a signal" or a 132769 syscall event, OURSTATUS is set to "stopped", but without a signal 132770 number. Lines 3601 to 3629 (in the original code) serve to fill in that 132771 last bit of information. 132772 132773 The problem is that when `w` holds the vfork status, the code wrongfully 132774 takes this branch, because WSTOPSIG(w) returns SIGTRAP: 132775 132776 else if (current_thread->last_resume_kind == resume_stop 132777 && WSTOPSIG (w) != SIGSTOP) 132778 132779 The intent of this branch is, for example, when we sent SIGSTOP to try 132780 to stop a thread, but wait() reports that it stopped with another signal 132781 (that it must have received from somewhere else simultaneously), say 132782 SIGWINCH. In that case, we want to report the SIGWINCH. But in our 132783 fork/vfork case, we don't want to take this branch, as the thread didn't 132784 really stop because it received a signal. For the non "stopped by a 132785 signal" and non "syscall signal" cases, we would ideally skip over all 132786 that snippet that fills in the signal or syscall number. 132787 132788 The fix I propose is to move this snipppet of the else branch of the 132789 if/else above. In addition to moving the code, the last two "else if" 132790 branches: 132791 132792 else if (current_thread->last_resume_kind == resume_stop 132793 && WSTOPSIG (w) != SIGSTOP) 132794 { 132795 /* A thread that has been requested to stop by GDB with vCont;t, 132796 but, it stopped for other reasons. */ 132797 ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w))); 132798 } 132799 else if (ourstatus->kind () == TARGET_WAITKIND_STOPPED) 132800 ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w))); 132801 132802 are changed into a single else: 132803 132804 else 132805 ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w))); 132806 132807 This is the default path we take if: 132808 132809 - W is not a syscall status 132810 - W does not represent a SIGSTOP that have sent to stop the thread and 132811 therefore want to suppress it 132812 132813 Change-Id: If2dc1f0537a549c293f7fa3c53efd00e3e194e79 132814 1328152022-04-05 Simon Marchi <simon.marchi@efficios.com> 132816 132817 gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on) 132818 There is a problem with how GDB handles a vfork happening in a 132819 multi-threaded program. This problem was reported to me by somebody not 132820 using vfork directly, but using system(3) in a multi-threaded program, 132821 which may be implemented using vfork. 132822 132823 This patch only deals about the follow-fork-mode=parent, 132824 detach-on-fork=on case, because it would be too much to chew at once to 132825 fix the bugs in the other cases as well (I tried). 132826 132827 The problem 132828 ----------- 132829 132830 When a program vforks, the parent thread is suspended by the kernel 132831 until the child process exits or execs. Specifically, in a 132832 multi-threaded program, only the thread that called vfork is suspended, 132833 other threads keep running freely. This is documented in the vfork(2) 132834 man page ("Caveats" section). 132835 132836 Let's suppose GDB is handling a vfork and the user's desire is to detach 132837 from the child. Before detaching the child, GDB must remove the software 132838 breakpoints inserted in the shared parent/child address space, in case 132839 there's a breakpoint in the path the child is going to take before 132840 exec'ing or exit'ing (unlikely, but possible). Otherwise the child could 132841 hit a breakpoint instruction while running outside the control of GDB, 132842 which would make it crash. GDB must also avoid re-inserting breakpoints 132843 in the parent as long as it didn't receive the "vfork done" event (that 132844 is, when the child has exited or execed): since the address space is 132845 shared with the child, that would re-insert breakpoints in the child 132846 process also. So what GDB does is: 132847 132848 1. Receive "vfork" event for the parent 132849 2. Remove breakpoints from the (shared) address space and set 132850 program_space::breakpoints_not_allowed to avoid re-inserting them 132851 3. Detach from the child thread 132852 4. Resume the parent 132853 5. Wait for and receive "vfork done" event for the parent 132854 6. Clean program_space::breakpoints_not_allowed and re-insert 132855 breakpoints 132856 7. Resume the parent 132857 132858 Resuming the parent at step 4 is necessary in order for the kernel to 132859 report the "vfork done" event. The kernel won't report a ptrace event 132860 for a thread that is ptrace-stopped. But the theory behind this is that 132861 between steps 4 and 5, the parent won't actually do any progress even 132862 though it is ptrace-resumed, because the kernel keeps it suspended, 132863 waiting for the child to exec or exit. So it doesn't matter for that 132864 thread if breakpoints are not inserted. 132865 132866 The problem is when the program is multi-threaded. In step 4, GDB 132867 resumes all threads of the parent. The thread that did the vfork stays 132868 suspended by the kernel, so that's fine. But other threads are running 132869 freely while breakpoints are removed, which is a problem because they 132870 could miss a breakpoint that they should have hit. 132871 132872 The problem is present with all-stop and non-stop targets. The only 132873 difference is that with an all-stop targets, the other threads are 132874 stopped by the target when it reports the vfork event and are resumed by 132875 the target when GDB resumes the parent. With a non-stop target, the 132876 other threads are simply never stopped. 132877 132878 The fix 132879 ------- 132880 132881 There many combinations of settings to consider (all-stop/non-stop, 132882 target-non-stop on/off, follow-fork-mode parent/child, detach-on-fork 132883 on/off, schedule-multiple on/off), but for this patch I restrict the 132884 scope to follow-fork-mode=parent, detach-on-fork=on. That's the 132885 "default" case, where we detach the child and keep debugging the 132886 parent. I tried to fix them all, but it's just too much to do at once. 132887 The code paths and behaviors for when we don't detach the child are 132888 completely different. 132889 132890 The guiding principle for this patch is that all threads of the vforking 132891 inferior should be stopped as long as breakpoints are removed. This is 132892 similar to handling in-line step-overs, in a way. 132893 132894 For non-stop targets (the default on Linux native), this is what 132895 happens: 132896 132897 - In follow_fork, we call stop_all_threads to stop all threads of the 132898 inferior 132899 - In follow_fork_inferior, we record the vfork parent thread in 132900 inferior::thread_waiting_for_vfork_done 132901 - Back in handle_inferior_event, we call keep_going, which resumes only 132902 the event thread (this is already the case, with a non-stop target). 132903 This is the thread that will be waiting for vfork-done. 132904 - When we get the vfork-done event, we go in the (new) handle_vfork_done 132905 function to restart the previously stopped threads. 132906 132907 In the same scenario, but with an all-stop target: 132908 132909 - In follow_fork, no need to stop all threads of the inferior, the 132910 target has stopped all threads of all its inferiors before returning 132911 the event. 132912 - In follow_fork_inferior, we record the vfork parent thread in 132913 inferior::thread_waiting_for_vfork_done. 132914 - Back in handle_inferior_event, we also call keep_going. However, we 132915 only want to resume the event thread here, not all inferior threads. 132916 In internal_resume_ptid (called by resume_1), we therefore now check 132917 whether one of the inferiors we are about to resume has 132918 thread_waiting_for_vfork_done set. If so, we only resume that 132919 thread. 132920 132921 Note that when resuming multiple inferiors, one vforking and one not 132922 non-vforking, we could resume the vforking thread from the vforking 132923 inferior plus all threads from the non-vforking inferior. However, 132924 this is not implemented, it would require more work. 132925 - When we get the vfork-done event, the existing call to keep_going 132926 naturally resumes all threads. 132927 132928 Testing-wise, add a test that tries to make the main thread hit a 132929 breakpoint while a secondary thread calls vfork. Without the fix, the 132930 main thread keeps going while breakpoints are removed, resulting in a 132931 missed breakpoint and the program exiting. 132932 132933 Change-Id: I20eb78e17ca91f93c19c2b89a7e12c382ee814a1 132934 1329352022-04-05 Simon Marchi <simon.marchi@polymtl.ca> 132936 132937 gdb/infrun: add logging statement to do_target_resume 132938 This helped me, it shows which ptid we actually call target_resume with. 132939 132940 Change-Id: I2dfd771e83df8c25f39371a13e3e91dc7882b73d 132941 1329422022-04-05 Simon Marchi <simon.marchi@polymtl.ca> 132943 132944 gdb/infrun: add inferior parameters to stop_all_threads and restart_threads 132945 A following patch will want to stop all threads of a given inferior (as 132946 opposed to all threads of all inferiors) while handling a vfork, and 132947 restart them after. To help with this, add inferior parameters to 132948 stop_all_threads and restart_threads. This is done as a separate patch 132949 to make sure this doesn't cause regressions on its own, and to keep the 132950 following patches more concise. 132951 132952 No visible changes are expected here, since all calls sites pass 132953 nullptr, which should keep the existing behavior. 132954 132955 Change-Id: I4d9ba886ce842042075b4e346cfa64bbe2580dbf 132956 1329572022-04-05 Simon Marchi <simon.marchi@polymtl.ca> 132958 132959 gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork_done 132960 The inferior::waiting_for_vfork_done flag indicates that some thread in 132961 that inferior is waiting for a vfork-done event. Subsequent patches 132962 will need to know which thread precisely is waiting for that event. 132963 132964 Replace the boolean flag (waiting_for_vfork_done) with a thread_info 132965 pointer (thread_waiting_for_vfork_done). 132966 132967 I think there is a latent buglet in that waiting_for_vfork_done is 132968 currently not reset on inferior exec or exit. I could imagine that if a 132969 thread in the parent process calls exec or exit while another thread of 132970 the parent process is waiting for its vfork child to exec or exit, we 132971 could end up with inferior::waiting_for_vfork_done without a thread 132972 actually waiting for a vfork-done event anymore. And since that flag is 132973 checked in resume_1, things could misbehave there. 132974 132975 Since the new field points to a thread_info object, and those are 132976 destroyed on exec or exit, it could be worse now since we could try to 132977 access freed memory, if thread_waiting_for_vfork_done were to point to a 132978 stale thread_info. To avoid this, clear the field in 132979 infrun_inferior_exit and infrun_inferior_execd. 132980 132981 Change-Id: I31b847278613a49ba03fc4915f74d9ceb228fdce 132982 1329832022-04-05 Simon Marchi <simon.marchi@efficios.com> 132984 132985 gdb: make timestamped_file implement write_async_safe 132986 Trying to use "set debug linux-nat 1", I get an internal error: 132987 132988 /home/smarchi/src/binutils-gdb/gdb/ui-file.h:70: internal-error: write_async_safe: write_async_safe 132989 132990 The problem is that timestamped_file doesn't implement write_async_safe, 132991 which linux-nat's sigchld_handler uses. Implement it. 132992 132993 Change-Id: I830981010c6119f13ae673605ed015cced0f5ee8 132994 1329952022-04-05 GDB Administrator <gdbadmin@sourceware.org> 132996 132997 Automatic date update in version.in 132998 1329992022-04-04 Andrew Burgess <aburgess@redhat.com> 133000 133001 gdb/testsuite: fix timeout in server-pipe.exp test 133002 I noticed that the gdb.server/server-pipe.exp test would sometimes 133003 timeout when my machine was more heavily loaded. Turns out the test 133004 is reading all the shared libraries over GDB's remote protocol, which 133005 can be slow. 133006 133007 We avoid this in other tests by setting the sysroot in GDBFLAGS, 133008 something which is missing from the gdb.server/server-pipe.exp test. 133009 133010 Fix the timeouts by setting sysroot in GDBFLAGS, after this the shared 133011 libraries are no longer copied over the remote protocol, and I no 133012 longer see the test timeout. 133013 1330142022-04-04 John Baldwin <jhb@FreeBSD.org> 133015 133016 Handle TLS variable lookups when using separate debug files. 133017 Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that 133018 a separate debug file was passed as the objfile for a shared library 133019 to svr4_fetch_objfile_link_map. However, a separate debug file can 133020 also be passed for TLS variables in the main executable. In addition, 133021 frv_fetch_objfile_link_map also expects to be passed the original 133022 objfile rather than a separate debug file, so pull the code to resolve 133023 a separate debug file to the main objfile up into 133024 target_translate_tls_address. 133025 1330262022-04-04 Lancelot SIX <lancelot.six@amd.com> 133027 133028 gdb: Add maint set ignore-prologue-end-flag 133029 The previous patch added support for the DWARF prologue-end flag in line 133030 table. This flag can be used by DWARF producers to indicate where to 133031 place breakpoints past a function prologue. However, this takes 133032 precedence over prologue analyzers. So if we have to debug a program 133033 with erroneous debug information, the overall debugging experience will 133034 be degraded. 133035 133036 This commit proposes to add a maintenance command to instruct GDB to 133037 ignore the prologue_end flag. 133038 133039 Tested on x86_64-gnu-linux. 133040 133041 Change-Id: Idda6d1b96ba887f4af555b43d9923261b9cc6f82 133042 1330432022-04-04 Lancelot SIX <lancelot.six@amd.com> 133044 133045 gdb: Add support for DW_LNS_set_prologue_end in line-table 133046 Add support for DW_LNS_set_prologue_end when building line-tables. This 133047 attribute can be set by the compiler to indicate that an instruction is 133048 an adequate place to set a breakpoint just after the prologue of a 133049 function. 133050 133051 The compiler might set multiple prologue_end, but considering how 133052 current skip_prologue_using_sal works, this commit modifies it to accept 133053 the first instruction with this marker (if any) to be the place where a 133054 breakpoint should be placed to be at the end of the prologue. 133055 133056 The need for this support came from a problematic usecase generated by 133057 hipcc (i.e. clang). The problem is as follows: There's a function 133058 (lets call it foo) which covers PC from 0xa800 to 0xa950. The body of 133059 foo begins with a call to an inlined function, covering from 0xa800 to 133060 0xa94c. The issue is that when placing a breakpoint at 'foo', GDB 133061 inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is 133062 foo's first address past the prologue. 133063 133064 Later, when hitting the breakpoint, GDB reports the stop within the 133065 inlined function because the PC falls in its range while the user 133066 expects to stop in FOO. 133067 133068 Looking at the line-table for this location, we have: 133069 133070 INDEX LINE ADDRESS IS-STMT 133071 [...] 133072 14 293 0x000000000000a66c Y 133073 15 END 0x000000000000a6e0 Y 133074 16 287 0x000000000000a800 Y 133075 17 END 0x000000000000a818 Y 133076 18 287 0x000000000000a824 Y 133077 [...] 133078 133079 For comparison, let's look at llvm-dwarfdump's output for this CU: 133080 133081 Address Line Column File ISA Discriminator Flags 133082 ------------------ ------ ------ ------ --- ------------- ------------- 133083 [...] 133084 0x000000000000a66c 293 12 2 0 0 is_stmt 133085 0x000000000000a6e0 96 43 82 0 0 is_stmt 133086 0x000000000000a6f8 102 18 82 0 0 is_stmt 133087 0x000000000000a70c 102 24 82 0 0 133088 0x000000000000a710 102 18 82 0 0 133089 0x000000000000a72c 101 16 82 0 0 is_stmt 133090 0x000000000000a73c 2915 50 83 0 0 is_stmt 133091 0x000000000000a74c 110 1 1 0 0 is_stmt 133092 0x000000000000a750 110 1 1 0 0 is_stmt end_sequence 133093 0x000000000000a800 107 0 1 0 0 is_stmt 133094 0x000000000000a800 287 12 2 0 0 is_stmt prologue_end 133095 0x000000000000a818 114 59 81 0 0 is_stmt 133096 0x000000000000a824 287 12 2 0 0 is_stmt 133097 0x000000000000a828 100 58 82 0 0 is_stmt 133098 [...] 133099 133100 The main difference we are interested in here is that llvm-dwarfdump's 133101 output tells us that 0xa800 is an adequate place to place a breakpoint 133102 past a function prologue. Since we know that foo covers from 0xa800 to 133103 0xa94c, 0xa800 is the address at which the breakpoint should be placed 133104 if the user wants to break in foo. 133105 133106 This commit proposes to add support for the prologue_end flag in the 133107 line-program processing. 133108 133109 The processing of this prologue_end flag is made in skip_prologue_sal, 133110 before it calls gdbarch_skip_prologue_noexcept. The intent is that if 133111 the compiler gave information on where the prologue ends, we should use 133112 this information and not try to rely on architecture dependent logic to 133113 guess it. 133114 133115 The testsuite have been executed using this patch on GNU/Linux x86_64. 133116 Testcases have been compiled with both gcc/g++ (verison 9.4.0) and 133117 clang/clang++ (version 10.0.0) since at the time of writing GCC does not 133118 set the prologue_end marker. Tests done with GCC 11.2.0 (not over the 133119 entire testsuite) show that it does not emit this flag either. 133120 133121 No regression have been observed with GCC or Clang. Note that when 133122 using Clang, this patch fixes a failure in 133123 gdb.opt/inline-small-func.exp. 133124 133125 Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8 133126 1331272022-04-04 Lancelot SIX <lancelot.six@amd.com> 133128 133129 gdb/buildsym: Line record use a record flag 133130 Currently when recording a line entry (with 133131 buildsym_compunit::record_line), a boolean argument argument is used to 133132 indicate that the is_stmt flag should be set for this particular record. 133133 As a later commit will add support for new flags, instead of adding a 133134 parameter to record_line for each possible flag, transform the current 133135 is_stmt parameter into a enum flag. This flags parameter will allow 133136 greater flexibility in future commits. 133137 133138 This enum flags type is not propagated into the linetable_entry type as 133139 this would require a lot of changes across the codebase for no practical 133140 gain (it currently uses a bitfield where each interesting flag only 133141 occupy 1 bit in the structure). 133142 133143 Tested on x86_64-linux, no regression observed. 133144 133145 Change-Id: I5d061fa67bdb34918742505ff983d37453839d6a 133146 1331472022-04-04 Simon Marchi <simon.marchi@polymtl.ca> 133148 133149 gdb: make timestamped_file implement can_emit_style_escape 133150 In our AMDGPU downstream port, we use styling in some logging output. 133151 We noticed it stopped working after the gdb_printf changes. Making 133152 timestamped_file implement can_emit_style_escape (returning the value of 133153 the stream it wraps) fixes it. To show that it works, modify some 133154 logging statements in auto-load.c to output style filenames. You can 133155 see it in action by setting "set debug auto-load 1" and running a 133156 program. We can incrementally add styling to other debug statements 133157 throughout GDB, as needed. 133158 133159 Change-Id: I78a2fd1e078f80f2263251cf6bc53b3a9de9c17a 133160 1331612022-04-04 Simon Marchi <simon.marchi@polymtl.ca> 133162 133163 gdb: remove assertion in psymbol_functions::expand_symtabs_matching 133164 psymtab_to_symtab is documented as possibly returning nullptr, if the 133165 primary symtab of the partial symtab has no symbols. However, 133166 psymbol_functions::expand_symtabs_matching asserts that the result of 133167 psymtab_to_symtab as non-nullptr. 133168 133169 I caught this assert by trying the CTF symbol reader on a library I 133170 built with -gctf: 133171 133172 $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 133173 ... 133174 Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0... 133175 (gdb) maintenance expand-symtabs 133176 /home/simark/src/binutils-gdb/gdb/psymtab.c:1142: internal-error: expand_symtabs_matching: Assertion `symtab != nullptr' failed. 133177 133178 The "symtab" in question is: 133179 133180 $ readelf --ctf=.ctf /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 133181 ... 133182 CTF archive member: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c: 133183 133184 Header: 133185 Magic number: 0xdff2 133186 Version: 4 (CTF_VERSION_3) 133187 Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR) 133188 Parent name: .ctf 133189 Compilation unit name: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c 133190 Type section: 0x0 -- 0x13 (0x14 bytes) 133191 String section: 0x14 -- 0x5f (0x4c bytes) 133192 133193 Labels: 133194 133195 Data objects: 133196 133197 Function objects: 133198 133199 Variables: 133200 133201 Types: 133202 0x80000001: (kind 5) bt_bool (*) (const bt_value *) (aligned at 0x8) 133203 133204 Strings: 133205 0x0: 133206 0x1: .ctf 133207 0x6: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c 133208 133209 It contains a single type, and it is skipped by ctf_add_type_cb, because 133210 an identical type was already seen earlier in this objfile. As a 133211 result, no compunit_symtab is created. 133212 133213 Change psymbol_functions::expand_symtabs_matching to expect that 133214 psymtab_to_symtab can return nullptr. 133215 133216 Another possibility would be to make the CTF symbol reader always create 133217 a compunit_symtab, even if there are no symbols in it (like the DWARF 133218 parser does), but so far I don't see any advantage in doing so. 133219 133220 Change-Id: Ic43c38202c838a5eb87630ed1fd61d33528164f4 133221 1332222022-04-04 Andrew Burgess <aburgess@redhat.com> 133223 133224 sim: fixes for libopcodes styled disassembler 133225 In commit: 133226 133227 commit 60a3da00bd5407f07d64dff82a4dae98230dfaac 133228 Date: Sat Jan 22 11:38:18 2022 +0000 133229 133230 objdump/opcodes: add syntax highlighting to disassembler output 133231 133232 I broke several sim/ targets by forgetting to update their uses of the 133233 libopcodes disassembler to take account of the new styled printing. 133234 133235 These should all be fixed by this commit. 133236 133237 I've not tried to add actual styled output to the simulator traces, 133238 instead, the styled print routines just ignore the style and print the 133239 output unstyled. 133240 1332412022-04-04 Tom Tromey <tromey@adacore.com> 133242 133243 Remove some globals from nat/windows-nat.c 133244 nat/windows-nat.c has a number of globals that it uses to communicate 133245 with its clients (gdb and gdbserver). However, if we ever want the 133246 Windows ports to be multi-inferior, globals won't work. 133247 133248 This patch takes a step toward that by moving most nat/windows-nat.c 133249 globals into a new struct windows_process_info. Many functions are 133250 converted to be methods on this object. 133251 133252 A couple of globals remain, as they are needed to truly be global due 133253 to the way that the Windows debugging APIs work. 133254 133255 The clients still have a global for the current process. That is, 133256 this patch is a step toward the end goal, but doesn't implement the 133257 goal itself. 133258 1332592022-04-04 Tom Tromey <tromey@adacore.com> 133260 133261 Remove windows_thread_info destructor 133262 windows_thread_info declares and defines a destructor, but this 133263 doesn't need to be explicit. 133264 133265 Use unique_ptr in the Windows thread list 133266 windows-nat.c uses some manual memory management when manipulating the 133267 thread_list global. Changing this to use unique_ptr simplifies the 133268 code, in particular windows_init_thread_list. (Note that, while I 133269 think the the call to init_thread_list in there is wrong, I haven't 133270 removed it in this patch.) 133271 133272 Use auto_obstack in windows-nat.c 133273 One spot in windows-nat.c can use auto_obstack, removing some manual 133274 memory management. 133275 1332762022-04-04 Tom Tromey <tromey@adacore.com> 133277 133278 Simplify windows-nat.c solib handling 133279 Currently windows-nat.c uses struct so_list to record its local idea 133280 of which shared libraries have been loaded. However, many fields in 133281 this are not needed, and furthermore I found this quite confusing at 133282 first -- Windows actually uses solib-target and so the use of so_list 133283 here is weird. 133284 133285 This patch simplifies this code by changing it to use a std::vector 133286 and a new type that holds exactly what's needed for the Windows code. 133287 1332882022-04-04 Pedro Alves <pedro@palves.net> 133289 133290 Avoid undefined behavior in gdbscm_make_breakpoint 133291 Running gdb.guile/scm-breakpoint.exp against an --enable-ubsan build, 133292 we see: 133293 133294 UNRESOLVED: gdb.guile/scm-breakpoint.exp: test_watchpoints: create a breakpoint with an invalid type number 133295 ... 133296 guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999)) 133297 ../../src/gdb/guile/scm-breakpoint.c:377:11: runtime error: load of value 999, which is not a valid value for type 'bptype' 133298 ERROR: GDB process no longer exists 133299 133300 Fix this by parsing the user/guile input as plain int, and cast to 133301 internal type only after we know we have a number that would be valid. 133302 133303 Change-Id: I03578d07db00be01b610a8f5ce72e5521aea6a4b 133304 1333052022-04-04 Tom Tromey <tromey@adacore.com> 133306 133307 Add context-sensitive field name completion to Ada parser 133308 This updates the Ada expression parser to implement context-sensitive 133309 field name completion. This is PR ada/28727. 133310 133311 This is somewhat complicated due to some choices in the Ada lexer -- 133312 it chooses to represent a sequence of "."-separated identifiers as a 133313 single token, so the parser must partially recreate the completer's 133314 logic to find the completion word boundaries. 133315 133316 Despite the minor warts in this patch, though, it is a decent 133317 improvement. It's possible that the DWARF reader rewrite will help 133318 fix the package completion problem pointed out in this patch as well. 133319 133320 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28727 133321 1333222022-04-04 Tom Tromey <tromey@adacore.com> 133323 133324 Consolidate single-char tokens in ada-lex.l 133325 There are two rules in ada-lex.l that match single-character tokens. 133326 This merges them. 133327 133328 Also, this removes '.' from the list of such tokens. '.' is not used 133329 in any production in ada-exp.y, and removing it here helps the 133330 subsequent completion patches. 133331 1333322022-04-04 Tom Tromey <tromey@adacore.com> 133333 133334 Remove the Ada DOT_ALL token 133335 The Ada parser has a DOT_ALL token to represent ".all", and another 133336 token to represent other ".<identifier>" forms. However, for 133337 completion it is a bit more convenient to unify these cases, so this 133338 patch removes DOT_ALL. 133339 133340 Refactor ada-lex.l:processId 133341 processId in ada-lex.l is a bit funny -- it uses an "if" and a 133342 "switch", and a nested loop. This patch cleans it up a bit, changing 133343 it to use a boolean flag and a simpler "if". 133344 133345 Implement completion for Ada attributes 133346 This adds a completer for Ada attributes. Some work in the lexer is 133347 required in order to match end-of-input correctly, as flex does not 133348 have a general-purpose way of doing this. (The approach taken here is 133349 recommended in the flex manual.) 133350 1333512022-04-04 Tom Tromey <tromey@adacore.com> 133352 133353 Refactor expression completion 133354 This refactors the gdb expression completion code to make it easier to 133355 add more types of completers. 133356 133357 In the old approach, just two kinds of completers were supported: 133358 field names for some sub-expression, or tag names (like "enum 133359 something"). The data for each kind was combined in single structure, 133360 "expr_completion_state", and handled explicitly by 133361 complete_expression. 133362 133363 In the new approach, the parser state just holds an object that is 133364 responsible for implementing completion. This way, new completion 133365 types can be added by subclassing this base object. 133366 133367 The structop completer is moved into structop_base_operation, and new 133368 objects are defined for use by the completion code. This moves much 133369 of the logic of expression completion out of completer.c as well. 133370 1333712022-04-04 Tom Tromey <tromey@adacore.com> 133372 133373 Enable "set debug parser" for Ada 133374 I noticed that "set debug parser 1" did not affect Ada parsing. This 133375 patch fixes the problem. 133376 133377 Because this is rarely useful, and pretty much only for maintainers, I 133378 didn't write a test case. 133379 1333802022-04-04 Tom Tromey <tromey@adacore.com> 133381 133382 Fix bug in Ada attributes lexing 133383 The Ada lexer allows whitespace between the apostrophe and the 133384 attribute text, but processAttribute does not handle this. This patch 133385 fixes the problem and introduces a regression test. 133386 133387 Remove null sentinel from 'attributes' 133388 In a subsequent patch, it's handy if the 'attributes' array in 133389 ada-lex.l does not have a NULL sentinel at the end. In C++, this is 133390 easy to avoid. 133391 133392 Handle ghost entities in symbol lookup 133393 Normally, SPARK ghost entities are removed from the executable. 133394 However, with -gnata, they will be preserved. In this situation, it's 133395 handy to be able to inspect them. This patch allows this by removing 133396 the "___ghost_" prefix in the appropriate places. 133397 1333982022-04-04 Simon Marchi <simon.marchi@efficios.com> 133399 133400 gdb: rename start_symtab/end_symtab to start_compunit_symtab/end_compunit_symtab 133401 It's a bit confusing because we have both "compunit_symtab" and "symtab" 133402 types, and many methods and functions containing "start_symtab" or 133403 "end_symtab", which actually deal with compunit_symtabs. I believe this 133404 comes from the time before compunit_symtab was introduced, where 133405 symtab did the job of both. 133406 133407 Rename everything I found containing start_symtab or end_symtab to use 133408 start_compunit_symtab or end_compunit_symtab. 133409 133410 Change-Id: If3849b156f6433640173085ad479b6a0b085ade2 133411 1334122022-04-04 Simon Marchi <simon.marchi@efficios.com> 133413 133414 gdb: remove some unused buildsym-legacy functions 133415 Pretty much self-explanatory. 133416 133417 Change-Id: I5b658d017cd891ecdd1df61075eacb0f44316935 133418 1334192022-04-04 Fangrui Song <i@maskray.me> 133420 133421 gas: copy st_size only if unset 133422 For 133423 ``` 133424 .size foo1, 1 133425 foo1: 133426 133427 .set bar1, foo1 133428 .size bar1, 2 133429 .size bar2, 2 133430 .set bar2, foo1 133431 133432 .set bar3, foo2 133433 .size bar3, 2 133434 .size bar4, 2 133435 .set bar4, foo2 133436 133437 .size foo2, 1 133438 foo2: 133439 ``` 133440 133441 bar1's size is 2 while bar2, bar3, bar4's is 1. The behavior of bar1 makes sense 133442 (generally directives on the new symbol should win) and is relied upon by glibc 133443 stdio-common/errlist.c: 133444 133445 ``` 133446 .hidden _sys_errlist_internal 133447 .globl _sys_errlist_internal 133448 .type _sys_errlist_internal, @object 133449 .size _sys_errlist_internal, 1072 133450 _sys_errlist_internal: 133451 133452 .globl __GLIBC_2_1_sys_errlist 133453 .set __GLIBC_2_1_sys_errlist, _sys_errlist_internal 133454 .type __GLIBC_2_1_sys_errlist, %object 133455 .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) 133456 133457 // glibc expects that .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) wins. 133458 ``` 133459 133460 The behavior of bar2/bar3/bar4 seems brittle. To avoid the reordering of the two 133461 code blocks which will result in the bar3 situation, glibc compiles errlist.c 133462 with gcc -fno-toplevel-reorder (previously -fno-unit-at-a-time). 133463 133464 To fix the inconsistency and improve robustness, make bar2/bar3/bar4 match bar1, 133465 removing the directive order sensitivity. 133466 133467 There is a pity that `.size dest, 0` is indistinguishable from the case where 133468 dest is unset, but the compromise seems fine. 133469 133470 PR gas/29012 133471 * config/obj-elf.c (elf_copy_symbol_attributes): don't copy if src's size 133472 has been set. 133473 * testsuite/gas/elf/elf.exp: New test. 133474 * testsuite/gas/elf/size.d: New file. 133475 * testsuite/gas/elf/size.s: Likewise. 133476 1334772022-04-04 Andrew Burgess <aburgess@redhat.com> 133478 133479 gdb: remove use of vfprintf_filtered 133480 Commit: 133481 133482 commit 60a3da00bd5407f07d64dff82a4dae98230dfaac 133483 Date: Sat Jan 22 11:38:18 2022 +0000 133484 133485 objdump/opcodes: add syntax highlighting to disassembler output 133486 133487 Introduced a new use of vfprintf_filtered, which has been deprecated. 133488 This commit replaces this with gdb_vprintf instead. 133489 1334902022-04-04 Andrew Burgess <aburgess@redhat.com> 133491 133492 opcodes/i386: partially implement disassembler style support 133493 This commit adds partial support for disassembler styling in the i386 133494 disassembler. 133495 133496 The i386 disassembler collects the instruction arguments into an array 133497 of strings, and then loops over the array printing the arguments out 133498 later on. The problem is that by the time we print the arguments out 133499 it's not obvious what the type of each argument is. 133500 133501 Obviously this can be fixed, but I'd like to not do that as part of 133502 this commit, rather, I'd prefer to keep this commit as small as 133503 possible to get the basic infrastructure in place, then we can improve 133504 on this, to add additional styling, in later commits. 133505 133506 For now then, I think this commit should correctly style mnemonics, 133507 some immediates, and comments. Everything else will be printed as 133508 plain text, which will include most instruction arguments, unless the 133509 argument is printed as a symbol, by calling the print_address_func 133510 callback. 133511 133512 Ignoring colours, there should be no other user visible changes in the 133513 output of the disassembler in either objdump or gdb. 133514 133515 opcodes/ChangeLog: 133516 133517 * disassembler.c (disassemble_init_for_target): Set 133518 created_styled_output for i386 based targets. 133519 * i386-dis.c: Changed throughout to use fprintf_styled_func 133520 instead of fprintf_func. 133521 1335222022-04-04 Andrew Burgess <aburgess@redhat.com> 133523 133524 opcodes/riscv: implement style support in the disassembler 133525 Update the RISC-V disassembler to supply style information. This 133526 allows objdump to apply syntax highlighting to the disassembler 133527 output (when the appropriate command line flag is used). 133528 133529 Ignoring colours, there should be no other user visible changes in the 133530 output of the disassembler in either objdump or gdb. 133531 133532 opcodes/ChangeLog: 133533 133534 * disassembler.c (disassemble_init_for_target): Set 133535 created_styled_output for riscv. 133536 * riscv-dis.c: Changed throughout to use fprintf_styled_func 133537 instead of fprintf_func. 133538 1335392022-04-04 Andrew Burgess <aburgess@redhat.com> 133540 133541 objdump/opcodes: add syntax highlighting to disassembler output 133542 This commit adds the _option_ of having disassembler output syntax 133543 highlighted in objdump. This option is _off_ by default. The new 133544 command line options are: 133545 133546 --disassembler-color=off # The default. 133547 --disassembler-color=color 133548 --disassembler-color=extended-color 133549 133550 I have implemented two colour modes, using the same option names as we 133551 use of --visualize-jumps, a basic 8-color mode ("color"), and an 133552 extended 8bit color mode ("extended-color"). 133553 133554 The syntax highlighting requires that each targets disassembler be 133555 updated; each time the disassembler produces some output we now pass 133556 through an additional parameter indicating what style should be 133557 applied to the text. 133558 133559 As updating all target disassemblers is a large task, the old API is 133560 maintained. And so, a user of the disassembler (i.e. objdump, gdb) 133561 must provide two functions, the current non-styled print function, and 133562 a new, styled print function. 133563 133564 I don't currently have a plan for converting every single target 133565 disassembler, my hope is that interested folk will update the 133566 disassemblers they are interested in. But it is possible some might 133567 never get updated. 133568 133569 In this initial series I intend to convert the RISC-V disassembler 133570 completely, and also do a partial conversion of the x86 disassembler. 133571 Hopefully having the x86 disassembler at least partial converted will 133572 allow more people to try this out easily and provide feedback. 133573 133574 In this commit I have focused on objdump. The changes to GDB at this 133575 point are the bare minimum required to get things compiling, GDB makes 133576 no use of the styling information to provide any colors, that will 133577 come later, if this commit is accepted. 133578 133579 This first commit in the series doesn't convert any target 133580 disassemblers at all (the next two commits will update some targets), 133581 so after this commit, the only color you will see in the disassembler 133582 output, is that produced from objdump itself, e.g. from 133583 objdump_print_addr_with_sym, where we print an address and a symbol 133584 name, these are now printed with styling information, and so will have 133585 colors applied (if the option is on). 133586 133587 Finally, my ability to pick "good" colors is ... well, terrible. I'm 133588 in no way committed to the colors I've picked here, so I encourage 133589 people to suggest new colors, or wait for this commit to land, and 133590 then patch the choice of colors. 133591 133592 I do have an idea about using possibly an environment variable to 133593 allow the objdump colors to be customised, but I haven't done anything 133594 like that in this commit, the color choices are just fixed in the code 133595 for now. 133596 133597 binutils/ChangeLog: 133598 133599 * NEWS: Mention new feature. 133600 * doc/binutils.texi (objdump): Describe --disassembler-color 133601 option. 133602 * objdump.c (disassembler_color): New global. 133603 (disassembler_extended_color): Likewise. 133604 (disassembler_in_comment): Likewise. 133605 (usage): Mention --disassembler-color option. 133606 (long_options): Add --disassembler-color option. 133607 (objdump_print_value): Use fprintf_styled_func instead of 133608 fprintf_func. 133609 (objdump_print_symname): Likewise. 133610 (objdump_print_addr_with_sym): Likewise. 133611 (objdump_color_for_disassembler_style): New function. 133612 (objdump_styled_sprintf): New function. 133613 (fprintf_styled): New function. 133614 (disassemble_jumps): Use disassemble_set_printf, and reset 133615 disassembler_in_comment. 133616 (null_styled_print): New function. 133617 (disassemble_bytes): Use disassemble_set_printf, and reset 133618 disassembler_in_comment. 133619 (disassemble_data): Update init_disassemble_info call. 133620 (main): Handle --disassembler-color option. 133621 133622 include/ChangeLog: 133623 133624 * dis-asm.h (enum disassembler_style): New enum. 133625 (struct disassemble_info): Add fprintf_styled_func field, and 133626 created_styled_output field. 133627 (disassemble_set_printf): Declare. 133628 (init_disassemble_info): Add additional parameter. 133629 (INIT_DISASSEMBLE_INFO): Add additional parameter. 133630 133631 opcodes/ChangeLog: 133632 133633 * dis-init.c (init_disassemble_info): Take extra parameter, 133634 initialize the new fprintf_styled_func and created_styled_output 133635 fields. 133636 * disassembler.c (disassemble_set_printf): New function definition. 133637 1336382022-04-04 Tom Tromey <tom@tromey.com> 133639 133640 Remove more Python 2 code 133641 I found another more place that still had a workaround for Python 2. 133642 This patch removes it. 133643 1336442022-04-04 Tom de Vries <tdevries@suse.de> 133645 133646 [gdb/testsuite] Fix KPASS in gdb.ada/arrayptr.exp 133647 On openSUSE Leap 15.3 I run into: 133648 ... 133649 KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all \ 133650 (PRMS minimal encodings) 133651 KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) \ 133652 (PRMS minimal encodings) 133653 KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all(3) \ 133654 (PRMS minimal encodings) 133655 ... 133656 133657 The test-case KFAILs some tests. However, the analysis in the corresponding 133658 PR talks of a compiler problem, so it should use XFAILs instead. 133659 133660 The KFAILs are setup for pre-gcc-12, but apparantly the fix has been 133661 backported to system compiler 7.5.0, hence the KPASS. 133662 133663 Fix this by: 133664 - using an XFAIL instead of a KFAIL 133665 - matching the specific gdb output that corresponds to the XFAILs 133666 (reproduced on Fedora 34). 133667 133668 Tested on x86_64-linux, specifically openSUSE Leap 15.3 and Fedora 34. 133669 1336702022-04-04 GDB Administrator <gdbadmin@sourceware.org> 133671 133672 Automatic date update in version.in 133673 1336742022-04-03 rupothar <rupesh.potharla@amd.com> 133675 133676 gdb: add support for Fortran's ASSUMED RANK arrays 133677 This patch adds a new dynamic property DYN_PROP_RANK, this property is 133678 read from the DW_AT_rank attribute and stored within the type just 133679 like other dynamic properties. 133680 133681 As arrays with dynamic ranks make use of a single 133682 DW_TAG_generic_subrange to represent all ranks of the array, support 133683 for this tag has been added to dwarf2/read.c. 133684 133685 The final piece of this puzzle is to add support in gdbtypes.c so that 133686 we can resolve an array type with dynamic rank. To do this the 133687 existing resolve_dynamic_array_or_string function is split into two, 133688 there's a new resolve_dynamic_array_or_string_1 core that is 133689 responsible for resolving each rank of the array, while the now outer 133690 resolve_dynamic_array_or_string is responsible for figuring out the 133691 array rank (which might require resolving a dynamic property) and then 133692 calling the inner core. 133693 133694 The resolve_dynamic_range function now takes a rank, which is passed 133695 on to the dwarf expression evaluator. This rank will only be used in 133696 the case where the array itself has dynamic rank, but we now pass the 133697 rank in all cases, this should be harmless if the rank is not needed. 133698 133699 The only small nit is that resolve_dynamic_type_internal actually 133700 handles resolving dynamic ranges itself, which now obviously requires 133701 us to pass a rank value. But what rank value to use? In the end I 133702 just passed '1' through here as a sane default, my thinking is that if 133703 we are in resolve_dynamic_type_internal to resolve a range, then the 133704 range isn't part of an array with dynamic rank, and so the range 133705 should actually be using the rank value at all. 133706 133707 An alternative approach would be to make the rank value a 133708 gdb::optional, however, this ends up adding a bunch of complexity to 133709 the code (e.g. having to conditionally build the array to pass to 133710 dwarf2_evaluate_property, and handling the 'rank - 1' in 133711 resolve_dynamic_array_or_string_1) so I haven't done that, but could, 133712 if people think that would be a better approach. 133713 133714 Finally, support for assumed rank arrays was only fixed very recently 133715 in gcc, so you'll need the latest gcc in order to run the tests for 133716 this. 133717 133718 Here's an example test program: 133719 133720 PROGRAM arank 133721 REAL :: a1(10) 133722 CALL sub1(a1) 133723 133724 CONTAINS 133725 133726 SUBROUTINE sub1(a) 133727 REAL :: a(..) 133728 PRINT *, RANK(a) 133729 END SUBROUTINE sub1 133730 END PROGRAM arank 133731 133732 Compiler Version: 133733 gcc (GCC) 12.0.0 20211122 (experimental) 133734 133735 Compilation command: 133736 gfortran assumedrank.f90 -gdwarf-5 -o assumedrank 133737 133738 Without Patch: 133739 133740 gdb -q assumedrank 133741 Reading symbols from assumedrank... 133742 (gdb) break sub1 133743 Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10. 133744 (gdb) run 133745 Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank 133746 133747 Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787 133748 /bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10 133749 10 PRINT *, RANK(a) 133750 (gdb) print RANK(a) 133751 'a' has unknown type; cast it to its declared type 133752 133753 With patch: 133754 133755 gdb -q assumedrank 133756 Reading symbols from assumedrank... 133757 (gdb) break sub1 133758 Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10. 133759 (gdb) run 133760 Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank 133761 133762 Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10 133763 10 PRINT *, RANK(a) 133764 (gdb) print RANK(a) 133765 $1 = 1 133766 (gdb) ptype a 133767 type = real(kind=4) (10) 133768 (gdb) 133769 133770 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 133771 1337722022-04-03 Andrew Burgess <aburgess@redhat.com> 133773 133774 gdb/dwarf: pass an array of values to the dwarf evaluator 133775 When we need to evaluate a DWARF expression in order to resolve some 133776 dynamic property of a type we call the dwarf2_evaluate_property 133777 function, which is declared in gdb/dwarf/loc.h and defined in 133778 gdb/dwarf/loc.c. 133779 133780 Currently, this function takes (amongst other things) an argument of 133781 type property_addr_info called addr_stack and a boolean called 133782 push_initial_value. When push_initial_value then the top value of 133783 addr_stack is pushed onto the dwarf expression evaluation stack before 133784 the expression is evaluated. 133785 133786 So far this has worked fine, as the only two cases we needed to handle 133787 are the case the DWARF expression doesn't require the object 133788 address (what the top of addr_stack represents), and the case where 133789 the DWARF expression does require the address. 133790 133791 In the next commit this is going to change. As we add support for 133792 Fortran assumed rank arrays, we need to start resolving the dynamic 133793 properties of arrays. To do this, we need to push the array rank onto 133794 the dwarf expression evaluation stack before the expression is 133795 evaluated. 133796 133797 This commit is a refactoring commit aimed at making it easier to 133798 support Fortran assumed rank arrays. Instead of passing a boolean, 133799 and using this to decide if we should push the object address or not, 133800 we instead pass an array (view) of values that should be pushed to the 133801 dwarf expression evaluation stack. 133802 133803 In the couple of places where we previously passed push_initial_value 133804 as true (mostly this was defaulting to false), we now have to pass the 133805 address from the addr_stack as an item in the array view. 133806 133807 In the next commit, when we want to handle passing the array rank, 133808 this will easily be supported too. 133809 133810 There should be no user visible changes after this commit. 133811 1338122022-04-03 Andrew Burgess <aburgess@redhat.com> 133813 133814 gdb: small simplification in dwarf2_locexpr_baton_eval 133815 While examining the dwarf expression evaluator, I noticed that in 133816 dwarf2_locexpr_baton_eval, whenever push_initial_value is true, the 133817 addr_stack will never be nullptr. 133818 133819 This allows for a small cleanup, replacing an if/then/else with an 133820 assertion. 133821 133822 There should be no user visible changes after this commit. 133823 1338242022-04-03 Andrew Burgess <aburgess@redhat.com> 133825 133826 gdb/testsuite: resolve some duplicate test names in gdb.base 133827 This commit resolves all the duplicate test names that I see in the 133828 script: 133829 133830 gdb.base/attach-pie-misread.exp 133831 133832 The duplicate names all come from a second call to 133833 build_executable_own_libs, so in this commit I've places the second 133834 call inside a with_test_prefix block. 133835 133836 While I was making this change I've also modified the value being 133837 passed as the testname for the second build_executable_own_libs call. 133838 Previously we used ${test}, however, I think this was likely a 133839 mistake, the 'test' variable is setup for the previous test. I 133840 suspect that ${testfile} is a better choice - especially now we have a 133841 testname prefix. 133842 133843 As the testname is only used (after various calls) from within 133844 build_executable_from_specs should the build fail, I don't think this 133845 change really makes much difference though. 133846 133847 There should be no change in what is tested after this commit. 133848 1338492022-04-03 Andrew Burgess <aburgess@redhat.com> 133850 133851 gdb/testsuite: resolve a duplicate test name in a gdb.mi test 133852 Solve two duplicate test names in the test script: 133853 133854 gdb.mi/mi-catch-cpp-exceptions.exp 133855 133856 by moving the call to restart_for_test inside the with_test_prefix 133857 block. There should be no difference in what is tested after this 133858 commit. 133859 1338602022-04-03 Andrew Burgess <aburgess@redhat.com> 133861 133862 gdb/Makefile.in: move ALLDEPFILES earlier in Makefile.in 133863 If I do 'make tags' in the gdb build directory, the tags target does 133864 complete, but I see these warnings: 133865 133866 ../../src/gdb/arm.c: No such file or directory 133867 ../../src/gdb/arm-get-next-pcs.c: No such file or directory 133868 ../../src/gdb/arm-linux.c: No such file or directory 133869 133870 The reason for this is the ordering of build rules and make variables 133871 in gdb/Makefile.in, specifically, the placement of the tags related 133872 rules, and the ALLDEPFILES variable. The ordering is like this: 133873 133874 TAGFILES_NO_SRCDIR = .... $(ALLDEPFILES) .... 133875 133876 TAGS: $(TAGFILES_NO_SRCDIR) .... 133877 # Recipe uses $(TAGFILES_NO_SRCDIR) 133878 133879 tags: TAGS 133880 133881 ALLDEPFILES = ..... 133882 133883 When the TAGS rule is parsed TAGFILES_NO_SRCDIR is expanded, which 133884 then expands ALLDEPFILES, which, at that point in the Makefile is 133885 undefined, and so expands to the empty string. As a result TAGS does 133886 not depend on any file listed in ALLDEPFILES. 133887 133888 However, when the TAGS recipe is invoked ALLDEPFILES is now defined. 133889 As a result, all the files in ALLDEPFILES are passed to the etags 133890 program. 133891 133892 The ALLDEPFILES references three files, arm.c, arm-get-next-pcs.c, and 133893 arm-linux.c, which are actually in the gdb/arch/ directory, but, in 133894 ALLDEPFILES these files don't include the arch/ prefix. As a result, 133895 the etags program ends up looking for these files in the wrong 133896 location. 133897 133898 As ALLDEPFILES is only used by the TAGS rule, this mistake was not 133899 previously noticed (the TAGS rule itself was broken until a recent 133900 commit). 133901 133902 In this commit I make two changes, first, I move ALLDEPFILES to be 133903 defined before TAGFILES_NO_SRCDIR, this means that the TAGS rule will 133904 depend on all the files in ALLDEPFILES. With this change the TAGS 133905 rule now breaks complaining that there's no rule to build the 3 files 133906 mentioned above. 133907 133908 Next, I have added all *.c files in gdb/arch/ to ALLDEPFILES, 133909 including their arch/ prefix, and removed the incorrect (missing arch/ 133910 prefix) references. 133911 133912 With these two changes the TAGS (or tags if you prefer) target now 133913 builds without any errors or warnings. 133914 1339152022-04-03 Reuben Thomas <rrt@sc3d.org> 133916 133917 gdb/Makefile.in: fix 'make tags' build target 133918 The gdb_select.h file was moved to the gdbsupport directory long ago, 133919 but a reference was accident left in gdb/Makefile.in (in the 133920 HFILES_NO_SRCDIR variable), this commit removes that reference. 133921 133922 Before this commit, if I use 'make tags' here's what I see: 133923 133924 $ make tags 133925 make: *** No rule to make target 'gdb_select.h', needed by 'TAGS'. Stop. 133926 133927 After this commit 'make tags' completes, but I still see these 133928 warnings: 133929 133930 ../../src/gdb/arm.c: No such file or directory 133931 ../../src/gdb/arm-get-next-pcs.c: No such file or directory 133932 ../../src/gdb/arm-linux.c: No such file or directory 133933 133934 These are caused by a separate issue, and will be addressed in the 133935 next commit. 133936 1339372022-04-03 Andrew Burgess <aburgess@redhat.com> 133938 133939 gdb/Makefile.in: remove SOURCES variable 133940 The SOURCES variable was added to gdb/Makefile.in as part of commit: 133941 133942 commit fb40c20903110ed8af9701ce7c2635abd3770d52 133943 Date: Wed Feb 23 00:25:43 2000 +0000 133944 133945 Add mi/ and testsuite/gdb.mi/ subdirectories. 133946 133947 But as far as I can tell was not used at the time it was added, and is 133948 not used today. 133949 133950 Lets remove it. 133951 1339522022-04-03 Andrew Burgess <aburgess@redhat.com> 133953 133954 gdb/tui: fair split of delta after a resize 133955 Currently, in master gdb, when a tui window is changed in size, the 133956 screen delta is mostly just added to the next available window. We 133957 do take care to respect the min/max size, but in most cases, these 133958 limits are just "the terminal size", and so, we end up placing the 133959 whole delta on the next window. 133960 133961 Consider these steps in an 80 column, 24 line terminal: 133962 133963 (gdb) tui enable 133964 (gdb) layout src 133965 (gdb) layout split 133966 (gdb) info win 133967 Name Lines Columns Focus 133968 src 8 80 (has focus) 133969 asm 8 80 133970 status 1 80 133971 cmd 8 80 133972 (gdb) winheight cmd +2 133973 (gdb) info win 133974 Name Lines Columns Focus 133975 src 6 80 (has focus) 133976 asm 8 80 133977 status 1 80 133978 cmd 10 80 133979 133980 Notice that initially, the windows were balanced, 8 lines each for the 133981 major windows. Then, when the cmd window was adjusted, the extra two 133982 lines were given to the asm window. 133983 133984 I think it would be nicer if the delta was spread more evenly over the 133985 available windows. In the example above, after the adjustment the 133986 layout now looks like: 133987 133988 (gdb) info win 133989 Name Lines Columns Focus 133990 src 7 80 (has focus) 133991 asm 7 80 133992 status 1 80 133993 cmd 10 80 133994 133995 This is achieved within tui_layout_split::set_size, by just handing 133996 out the delta in increments of 1 to each window (except for the window 133997 the user adjusted), until there's no more delta left. Of course, we 133998 continue to respect the min/max window sizes. 133999 1340002022-04-03 Andrew Burgess <aburgess@redhat.com> 134001 134002 gdb/tui: relax restrictions on window max height and width 134003 This commit removes some arbitrary adjustments made in 134004 tui_cmd_window::max_height, tui_win_info::max_height, and 134005 tui_win_info::max_width. 134006 134007 These member functions all subtract some constant from the theoretical 134008 maximum height or width. I've looked back through the history a 134009 little and can see no real reason why these adjustments should be 134010 needed, with these adjustments removed all the existing tui tests 134011 still pass. 134012 134013 However, retaining these restrictions causes some bugs, consider: 134014 134015 (gdb) tui new-layout hsrc {-horizontal src 1 cmd 1} 1 134016 134017 When this layout is selected with current master, gdb will leave a 4 134018 line gap at the bottom of the terminal. 134019 134020 The problem is that the maximum height is restricted, for the cmd 134021 window, to 4 less than the terminal height. 134022 134023 By removing this restriction gdb is able to size the windows to the 134024 complete terminal height, and the layout is done correctly. 134025 134026 This 4 line restriction is also what prevents this layout from working 134027 correctly: 134028 134029 (gdb) tui new-layout conly cmd 1 134030 134031 Previously, this layout would present a cmd window only, but there 134032 would be a 4 line gap at the bottom of the terminal. This issue was 134033 mentioned in an earlier commit in this series (when a different bug 134034 was fixed), but with this commit, the above layout now correctly fills 134035 the terminal. The associated test is updated. 134036 134037 After removing the adjustment in tui_cmd_window::max_height, the 134038 implementation is now the same as the implementation in the parent 134039 class tui_win_info, so I've completely removed the max_height call 134040 from tui_cmd_window. 134041 1340422022-04-03 Andrew Burgess <aburgess@redhat.com> 134043 134044 gdb/testsuite: some additional tests in gdb.tui/scroll.exp 134045 This commit just adds an extra check of the src window size prior to 134046 sending all the commands to gdb. We also set the cmd window height to 134047 its existing height, this (obviously) shouldn't change the window 134048 layout, which we check. 134049 134050 My main motivation was adding the initial window layout check, the 134051 winheight and recheck are just extras. All of these test pass both 134052 before and after this commit. 134053 1340542022-04-03 Andrew Burgess <aburgess@redhat.com> 134055 134056 gdb/tui: support placing the cmd window into a horizontal layout 134057 This commit allows the user to place the cmd window within horizontal 134058 tui layouts. Consider this set of steps, carried out in an 80 columns 134059 by 24 lines terminal, using current master gdb: 134060 134061 (gdb) tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1 134062 (gdb) tui layout hsrc 134063 134064 What you end up with is a full width cmd window with the status bar 134065 beneath. Where's the src window gone? We then try: 134066 134067 (gdb) info win 134068 Name Lines Columns Focus 134069 src 23 3 (has focus) 134070 cmd 23 80 134071 status 1 80 134072 (gdb) 134073 134074 Something weird has gone on, gdb has overlapped the cmd window with 134075 the src window. If we trigger the src window to redraw is content, 134076 for example, 'list main', then we see corruption in the cmd window as 134077 the src window overwrites it. 134078 134079 So, what's going on? 134080 134081 The problem is some code in tui_layout_split::apply, in tui-layout.c. 134082 Within 'Step 1', there is a loop that calculates the min/max window 134083 sizes for all windows within a tui_layout_split. However, there's a 134084 special case for the cmd window. 134085 134086 This special case is trying to have the cmd window retain its current 134087 size when a layout is re-applied, or a new layout is applied. This 134088 makes sense, consider moving from the 'src' layout to the 'asm' 134089 layout, this looks something like this (status window removed): 134090 134091 .-------. .-------. 134092 | src | | asm | 134093 |-------| ====> |-------| 134094 | cmd | | cmd | 134095 '-------' '-------' 134096 134097 If the user has gone to the effort of adjusting the cmd window size, 134098 then, the thinking goes, we shouldn't reset the cmd window size when 134099 switching layouts like this. 134100 134101 The problem though, is that when we do a switch more like this: 134102 134103 .-----------. .-----------. 134104 | src | | | | 134105 |-----------| ====> | asm | cmd | 134106 | cmd | | | | 134107 '-----------' '-----------' 134108 134109 Now retaining the cmd window width makes no sense; the new layout has 134110 a completely different placement for the cmd window, instead of sizing 134111 by height, we're now sizing by width. The existing code doesn't 134112 understand this though, and tried to retain the full width for the cmd 134113 window. 134114 134115 To solve this problem, I propose we introduce the idea of a layout 134116 "fingerprint". The fingerprint tries to capture, in an abstract way, 134117 where the cmd window lives within the layout. 134118 134119 Only when two layouts have the same fingerprint will we attempt to 134120 retain the cmd window size. 134121 134122 The fingerprint for a layout is represented as a string, the string is 134123 a series of 'V' or 'H' characters, ending with a single 'C' 134124 character. The series of 'V' and 'H' characters represent the 134125 vertical or horizontal layouts that must be passed through to find the 134126 cmd window. 134127 134128 Here are a few examples: 134129 134130 # This layout is equivalent to the builtin 'src' layout. 134131 # Fingerprint: VC 134132 tui new-layout example1 src 2 status 0 cmd 1 134133 134134 # This layout is equivalent to the builtin 'split' layout. 134135 # Fingerprint: VC 134136 tui new-layout example2 src 1 asm 1 status 0 cmd 1 134137 134138 # This is the same layout that was given at the top. 134139 # Fingerprint: VHC 134140 tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1 134141 134142 And so, when switching between example1 and example2, gdb knows that 134143 the cmd window is, basically, in the same sort of position within the 134144 layout, and will retain the cmd window size. 134145 134146 In contrast, when switching to the hsrc layout, gdb understands that 134147 the position of the cmd window is different, and does not try to 134148 retain the cmd window size. 134149 1341502022-04-03 Andrew Burgess <aburgess@redhat.com> 134151 134152 gdb/tui: allow cmd window to change size in tui_layout_split::apply 134153 When we switch layouts we call the tui_layout_split::apply member 134154 function to reapply the layout, and recalculate all the window sizes. 134155 134156 One special case is the cmd window, which we try to keep at its 134157 existing size. 134158 134159 However, in some cases it is not appropriate to keep the cmd window at 134160 its existing size. I will describe two such cases here, in one, we 134161 want the cmd window to reduce in size, and in the other, we want the 134162 cmd window to grow in size. 134163 134164 Try these steps in a 80 columns, by 24 lines terminal: 134165 134166 (gdb) tui enable 134167 (gdb) layout src 134168 (gdb) winheight cmd 20 134169 (gdb) layout split 134170 134171 You should see that the status window is missing from the new layout, 134172 and that the cmd window has been placed over the border of the asm 134173 window. The 'info win' output is: 134174 134175 (gdb) info win 134176 Name Lines Columns Focus 134177 src 3 80 (has focus) 134178 asm 3 80 134179 status 1 80 134180 cmd 20 80 134181 134182 Notice that gdb has assigned 27 lines of screen space, even with the 134183 border overlap between the src and asm windows, this is still 2 lines 134184 too many. 134185 134186 The problem here is that after switching layouts, gdb has forced the 134187 cmd window to retain its 20 line height. Really, we want the cmd 134188 window to reduce in height so that the src and asm windows can occupy 134189 their minimum required space. 134190 134191 This commit allows this (details on how are below). After this 134192 commit, in the above situation, we now see the status window displayed 134193 correctly, and the 'info win' output is: 134194 134195 (gdb) info win 134196 Name Lines Columns Focus 134197 src 3 80 (has focus) 134198 asm 3 80 134199 status 1 80 134200 cmd 18 80 134201 134202 The cmd window has been reduced in size by 2 lines so that everything 134203 can fit on the screen. 134204 134205 The second example is one which was discussed in a recent commit, 134206 consider this case (still in the 80 column, 24 line terminal): 134207 134208 (gdb) tui enable 134209 (gdb) tui new-layout conly cmd 1 134210 (gdb) layout conly 134211 (gdb) info win 134212 Name Lines Columns Focus 134213 cmd 8 80 (has focus) 134214 (gdb) 134215 134216 This layout only contains a cmd window, which we would expect to 134217 occupy the entire terminal. But instead, the cmd window only occupies 134218 the first 8 lines, and the rest of the terminal is unused! 134219 134220 The reason is, again, that the cmd window is keeping its previous 134221 size (8 lines). 134222 134223 After this commit things are slightly different, the 'info win' output 134224 is now: 134225 134226 (gdb) info win 134227 Name Lines Columns Focus 134228 cmd 20 80 (has focus) 134229 134230 Which is a little better, but why only 20 lines? Turns out there's 134231 yet another bug hitting this case. That bug will be addressed in a 134232 later commit, so, for now, we're accepting the 20 lines. 134233 134234 What this commit does is modify the phase of tui_layout_split::apply 134235 that handles any left over space. Usually, in "Step 2", each 134236 sub-layout has a size calculated. As the size is an integer, then, 134237 when all sizes are calculated we may have some space left over. 134238 134239 This extra space is then distributed between all the windows fairly 134240 until all the space is used up. 134241 134242 When we consider windows minimum size, or fixed size windows, then it 134243 is possible that we might try to use more space than is available, 134244 this was our first example above. The same code that added extra 134245 space to the windows, can also be used to reclaim space (in the over 134246 allocation case) to allow all windows to fit. 134247 134248 The problem then is the cmd window, which we often force to a fixed 134249 size. Inside the loop that handles the allocation of excess space, if 134250 we find that we have tried every window, and still have space either 134251 left to give, or we need to claim back more space, then, if the cmd 134252 window was changed to a fixed size, we can change the cmd window back 134253 to a non-fixed-size window, and proceed to either give, or take space 134254 from the cmd window as needed. 134255 1342562022-04-03 Andrew Burgess <aburgess@redhat.com> 134257 134258 gdb/tui: fairer distribution of excess space during apply 134259 When applying layouts gdb computes the size of each window (or rather, 134260 each sub-layout within a layout) using integer arithmetic. As this 134261 rounds down the results, then, when all sub-layouts are sized, there 134262 is the possibility that we have some space left over. 134263 134264 Currently, this space is just assigned to an arbitrary sub-layout. 134265 134266 This can result in some unbalanced results. Consider this set of 134267 steps with current master: 134268 134269 (gdb) tui enable 134270 (gdb) layout regs 134271 (gdb) info win 134272 Name Lines Columns Focus 134273 regs 7 80 134274 src 9 80 (has focus) 134275 status 1 80 134276 cmd 8 80 134277 134278 Notice the weird split between the src and regs windows, the original 134279 layout specification has these windows given equal weight. The 134280 problem is that, with rounding, both the regs and src windows are 134281 initially sized to 7, the extra 2 lines are then arbitrarily added to 134282 the src window. 134283 134284 In this commit, rather than add all the extra space to one single 134285 window, I instead hand out the extra space 1 line at a time, looping 134286 over all the sub-layouts. We take care to respect the min/max sizes, 134287 and so, we now get this result: 134288 134289 (gdb) tui enable 134290 (gdb) layout regs 134291 (gdb) info win 134292 Name Lines Columns Focus 134293 regs 8 80 134294 src 8 80 (has focus) 134295 status 1 80 134296 cmd 8 80 134297 134298 This looks more natural to me. 134299 134300 This is obviously a change in behaviour, and so, lots of the existing 134301 tests need to be updated to take this into account. None of the 134302 changes are huge, it's just a line or two (or column for width) moved 134303 between windows. 134304 1343052022-04-03 Andrew Burgess <aburgess@redhat.com> 134306 134307 gdb/tui: avoid fp exception when applying layouts 134308 Consider: 134309 134310 (gdb) tui enable 134311 (gdb) layout src 134312 (gdb) tui new-layout conly cmd 1 134313 (gdb) layout conly 134314 134315 After this, with current master, gdb crashes with a floating-point 134316 exception. 134317 134318 The problem is that in tui_layout_split::apply, when we switch from 134319 'src' to 'conly', we will try to retain the cmd window height. As 134320 such, the cmd window will become a fixed size window, which decreases 134321 the available_size, but doesn't count towards the total_weight. 134322 134323 As the cmd window is the only window, the total_weight stays at zero, 134324 and, when we move into step 2, where we attempt to size the windows, 134325 we perform a divide by zero, and crash. 134326 134327 After this commit we avoid the divide by zero, and just directly set 134328 the window size based on the fixed size. 134329 134330 There is still a problem after this commit, when the conly layout is 134331 selected the cmd window retains its original height, which will only 134332 be part of the terminal. The rest of the terminal is left unused. 134333 This issue will be addressed in a later commit, this commit is just 134334 about the floating-point exception. 134335 1343362022-04-03 Andrew Burgess <aburgess@redhat.com> 134337 134338 gdb/tui/testsuite: refactor new-layout.exp test 134339 This commit changes the gdb.tui/new-layout.exp test to make use of a 134340 list of test descriptions, and a loop to check each description in 134341 turn. There's no change to what is actually tested after this commit. 134342 134343 In future commits I plan to add additional tests to this file, and 134344 this will be easier now that all I have to do is add a new test 134345 description to the list. 134346 1343472022-04-03 Andrew Burgess <aburgess@redhat.com> 134348 134349 gdb/tui: add left_boxed_p and right_boxed_p member functions 134350 When I initially saw this code in tui_layout_split::apply, I assumed 134351 that this must be a bug: 134352 134353 /* Two adjacent boxed windows will share a border, making a bit 134354 more size available. */ 134355 if (i > 0 134356 && m_splits[i - 1].layout->bottom_boxed_p () 134357 && m_splits[i].layout->top_boxed_p ()) 134358 ... 134359 134360 After all, the apply might be laying out a horizontal layout, right? 134361 So checking bottom_boxed_p and top_boxed_p is clearly wrong. 134362 134363 Well, it turns on, that due to the implementations of these things, 134364 bottom_boxed_p is equivalent to an imagined right_boxed_p, and 134365 top_boxed_p is equivalent to an imagined left_boxed_p. 134366 134367 In this commit I've renamed both top_boxed_p and bottom_boxed_p to 134368 first_edge_has_border_p and last_edge_has_border_p respectively, and 134369 extended the comments in tui_layout_base to mention that these methods 134370 handle both horizontal and vertical layouts. 134371 134372 Now, hopefully, the code shouldn't look like it only applies for 134373 vertical layouts. 134374 134375 There should be no user visible changes after this commit. 134376 1343772022-04-03 Andrew Burgess <aburgess@redhat.com> 134378 134379 gdb/tui: add a tui debugging flag 134380 This commit adds 'set debug tui on|off' and 'show debug tui'. This 134381 commit adds the control variable, and the printing macros in 134382 tui/tui.h. I've then added some uses of these in tui.c and 134383 tui-layout.c. 134384 134385 To help produce more useful debug output in tui-layout.c, I've added 134386 some helper member functions in the class tui_layout_split, and also 134387 moved the size_info struct out of tui_layout_split::apply into the 134388 tui_layout_split class. 134389 134390 If tui debug is not turned on, then there should be no user visible 134391 changes after this commit. 134392 134393 One thing to note is that, due to the way that the tui terminal is 134394 often cleared, the only way I've found this useful is when I do: 134395 134396 (gdb) tui enable 134397 (gdb) set logging file /path/to/file 134398 (gdb) set logging debugredirect on 134399 (gdb) set logging enable on 134400 134401 Additionally, gdb has some quirks when it comes to setting up logging 134402 redirect and switching interpreters. Thus, the above only really 134403 works if the logging is enabled after the tui is enabled, and disabled 134404 again before the tui is disabled. 134405 134406 Enabling logging and switching interpreters can cause undefined 134407 results, including crashes. This is an existing bug in gdb[1], and 134408 has nothing directly to do with tui debug, but it is worth mentioning 134409 here I think. 134410 134411 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28948 134412 1344132022-04-03 Andrew Burgess <aburgess@redhat.com> 134414 134415 gdb/tui: add new 'tui window width' command and 'winwidth' alias 134416 This commit adds a new command 'tui window width', and an alias 134417 'winwidth'. This command is equivalent to the old 'winheight' 134418 command (which was recently renamed 'tui window height'). 134419 134420 Even though I recently moved the old tui commands under the tui 134421 namespace, and I would strongly encourage all new tui commands to be 134422 added as 'tui ....' only (users can create their own top-level aliases 134423 if they want), I'm breaking that suggestion here, and adding a 134424 'winwidth' alias. 134425 134426 Given that we already have 'winheight' and have done for years, it 134427 just didn't seem right to no have the matching 'winwidth'. 134428 134429 You might notice in the test that the window resizing doesn't quite 134430 work right. I setup a horizontal layout, then grow and shrink the 134431 windows. At the end of the test the windows should be back to their 134432 original size... 134433 134434 ... they are not. This isn't my fault, honest! GDB's window resizing 134435 is a little ... temperamental, and is prone to getting things slightly 134436 wrong during resizes, off by 1 type things. This is true for height 134437 resizing, as well as the new width resizing. 134438 134439 Later patches in this series will rework the resizing algorithm, which 134440 should improve things in this area. For now, I'm happy that the width 134441 resizing is as good as the height resizing, given the existing quirks. 134442 134443 For the docs side I include a paragraph that explains how multiple 134444 windows are required before the width can be adjusted. For 134445 completeness, I've added the same paragraph to the winheight 134446 description. With the predefined layouts this extra paragraph is not 134447 really needed for winheight, as there are always multiple windows on 134448 the screen. However, with custom layouts, this might not be true, so 134449 adding the paragraph seems like a good idea. 134450 134451 As for the changes in gdb itself, I've mostly just taken the existing 134452 height adjustment code, changed the name to make it generic 'size' 134453 adjustment, and added a boolean flag to indicate if we are adjusting 134454 the width or the height. 134455 1344562022-04-03 Andrew Burgess <aburgess@redhat.com> 134457 134458 gdb/tui: rename tui_layout_split:set_weights_from_heights 134459 In a following commit I'm going to add the ability to change the width 134460 of a tui window (when in a horizontal layout). As a result, some of 134461 the places where we currently hard-code references to height need to 134462 be changed to handle either height, or width, based on whether we are 134463 in a vertical, or horizontal layout. 134464 134465 This commit renames set_weights_from_heights to 134466 set_weights_from_sizes, and makes the function use either the height, 134467 or width as appropriate. 134468 134469 Currently, the only place that we call this function is from the 134470 tui_layout_split::set_height function, in a part of the code we will 134471 only reach for vertical layouts, so the new code is not actually being 134472 used, but, this small change will help make later patches smaller, so 134473 I'm proposing this as a stand alone change. 134474 134475 There should be no user visible changes after this commit. 134476 1344772022-04-03 Andrew Burgess <aburgess@redhat.com> 134478 134479 gdb/tui: rename tui_layout_base::adjust_size to ::set_height 134480 Rename tui_layout_base::adjust_size to tui_layout_base::set_height, 134481 the new name more accurately reflects what this member function does, 134482 and makes it easier for a later commit to add a new 134483 tui_layout_base::set_width member function. 134484 134485 There should be no user visible changes after this commit. 134486 1344872022-04-03 Andrew Burgess <aburgess@redhat.com> 134488 134489 gdb: move some commands into the tui namespace 134490 There are a lot of tui related commands that live in the top-level 134491 command name space, e.g. layout, focus, refresh, winheight. 134492 134493 Having them at the top level means less typing for the user, which is 134494 good, but, I think, makes command discovery harder. 134495 134496 In this commit, I propose moving all of the above mentioned commands 134497 into the tui namespace, so 'layout' becomes 'tui layout', etc. But I 134498 will then add aliases so that the old commands will still work, 134499 e.g. I'll make 'layout' an alias for 'tui layout'. 134500 134501 The benefit I see in this work is that tui related commands can be 134502 more easily discovered by typing 'tui ' and then tab-completing. Also 134503 the "official" command is now a tui-sub-command, this is visible in, 134504 for example, the help output, e.g.: 134505 134506 (gdb) help layout 134507 tui layout, layout 134508 Change the layout of windows. 134509 Usage: tui layout prev | next | LAYOUT-NAME 134510 134511 List of tui layout subcommands: 134512 134513 tui layout asm -- Apply the "asm" layout. 134514 tui layout next -- Apply the next TUI layout. 134515 tui layout prev -- Apply the previous TUI layout. 134516 tui layout regs -- Apply the TUI register layout. 134517 tui layout split -- Apply the "split" layout. 134518 tui layout src -- Apply the "src" layout. 134519 134520 Which I think is a good thing, it makes it clearer that this is a tui 134521 command. 134522 134523 I've added a NEWS entry and updated the docs to mention the new and 134524 old command names, with the new name being mentioned first. 134525 1345262022-04-03 Simon Marchi <simon.marchi@polymtl.ca> 134527 134528 gdb: fix gdb_print -> gdb_printf typo 134529 This caused a build failure with !CXX_STD_THREAD. 134530 134531 Change-Id: I30f0c89c43a76f85c0db34809192644fa64a9d18 134532 1345332022-04-03 Alan Modra <amodra@gmail.com> 134534 134535 Move microblaze relax info to target specific data 134536 Target specific data shouldn't be put in struct bfd_section. 134537 134538 * section.c (struct bfd_section): Delete relax and relax_count. 134539 (BFD_FAKE_SECTION): Adjust to suit. 134540 (struct relax_table): Move to.. 134541 * elf32-microblaze.c (struct relax_table): ..here. 134542 (struct _microblaze_elf_section_data): New. 134543 (microblaze_elf_section_data): Define. 134544 (microblaze_elf_new_section_hook): New function. 134545 (bfd_elf32_new_section_hook): Define. 134546 (calc_fixup): Return a size_t. Adjust to suit new location of 134547 relax and relax_count. 134548 (microblaze_elf_relax_section): Adjust to suit new location of 134549 relax and relax_count. Make some variables size_t. 134550 * bfd-in2.h: Regenerate. 134551 1345522022-04-03 Alan Modra <amodra@gmail.com> 134553 134554 Revert commit 240d6706c6a2 134555 PR 28592 134556 PR 15994 134557 PR 15935 134558 * dwarf2.c (lookup_address_in_line_info_table): Return bool rather 134559 than a range. 134560 (comp_unit_find_nearest_line): Likewise. Return true if function 134561 info found without line info. 134562 (_bfd_dwarf2_find_nearest_line): Revert range handling code. 134563 134564 Regen bfd po/SRC-POTFILES.in 134565 1345662022-04-03 GDB Administrator <gdbadmin@sourceware.org> 134567 134568 Automatic date update in version.in 134569 1345702022-04-02 Tiezhu Yang <yangtiezhu@loongson.cn> 134571 134572 gdb: rename floatformats_ia64_quad to floatformats_ieee_quad 134573 It is better to rename floatformats_ia64_quad to floatformats_ieee_quad 134574 to reflect the reality, and then we can clean up the related code. 134575 134576 As Tom Tromey said [1]: 134577 134578 These files are maintained in gcc and then imported into the 134579 binutils-gdb repository, so any changes to them will have to 134580 be proposed there first. 134581 134582 the related changes have been merged into gcc master now [2], it is time 134583 to do it for gdb. 134584 134585 [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html 134586 [2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6 134587 1345882022-04-02 GDB Administrator <gdbadmin@sourceware.org> 134589 134590 Automatic date update in version.in 134591 1345922022-04-01 John Baldwin <jhb@FreeBSD.org> 134593 134594 Remove unused variable. 134595 1345962022-04-01 Aaron Merey <amerey@redhat.com> 134597 134598 gdb/debuginfod-support.c: Always display debuginfod errors 134599 Errors encountered when downloading files from debuginfod servers 134600 are not displayed if debuginfod verbosity is set to 0 (via 134601 'set debuginfod verbose 0'). 134602 134603 Tom recommended that these errors always be displayed, regardless 134604 of the verbosity setting [1]. Fix this. 134605 134606 [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html 134607 1346082022-04-01 John Baldwin <jhb@FreeBSD.org> 134609 134610 Use I386_GSBASE_REGNUM in i386fbsd_get_thread_local_address. 134611 32-bit x86 arches always the I386_*BASE_REGNUM values. Only code that 134612 needs to support both 64-bit and 32-bit arches needs to use 134613 tdep->fsbase_regnum to compute a segment base register number. 134614 134615 FreeBSD/x86: Read segment base registers from NT_X86_SEGBASES. 134616 FreeBSD kernels recently grew a new register core dump note containing 134617 the base addresses of the %fs and %gs segments (corresponding to the 134618 %fsbase and %gsbase registers). Parse this note to permit inspecting 134619 TLS variables in core dumps. Native processes already supported TLS 134620 via older ptrace() operations. 134621 1346222022-04-01 John Baldwin <jhb@FreeBSD.org> 134623 134624 Use pseudosections for NT_FREEBSD_X86_SEGBASES core dump notes. 134625 This includes adding pseudosections when reading a core dump as well 134626 as support for writing out a core dump note from a pseudosection. 134627 134628 bfd/ChangeLog: 134629 134630 * elf-bfd.h (elfcore_write_x86_segbases): New. 134631 * elf.c (elfcore_grok_freebsd_note): Add pseudosections for 134632 NT_FREEBSD_X86_SEGBASES register notes. 134633 (elfcore_write_x86_segbases): New. 134634 (elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES 134635 register notes. 134636 1346372022-04-01 John Baldwin <jhb@FreeBSD.org> 134638 134639 Recognize FreeBSD core dump note for x86 segment base registers. 134640 This core dump note contains the value of the base address of the %fs 134641 and %gs segments for both i386 and amd64 core dumps. It is primarily 134642 useful in resolving the address of TLS variables in core dumps. 134643 134644 binutils/ChangeLog: 134645 134646 * readelf.c (get_freebsd_elfcore_note_type): Handle 134647 NT_FREEBSD_X86_SEGBASES. 134648 134649 include/ChangeLog: 134650 134651 * elf/common.h (NT_FREEBSD_X86_SEGBASES): Define. 134652 1346532022-04-01 John Baldwin <jhb@FreeBSD.org> 134654 134655 elfcore_grok_freebsd_note: Remove checks of note->namesz. 134656 This function is only called if the note name is "FreeBSD", so 134657 checking the name size is unnecessary. 134658 134659 bfd/ChangeLog: 134660 134661 * elf.c (elfcore_grok_freebsd_note): Remove checks for namesz. 134662 1346632022-04-01 Andrew Burgess <aburgess@redhat.com> 134664 134665 gdb/testing/tui: add new _csi_{L,S,T} 134666 This patch was original part of this series: 134667 134668 https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html 134669 https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html 134670 134671 I've pulled this out as it might be useful ahead of the bigger series 134672 being merged. 134673 134674 This commit adds: 134675 134676 _csi_L - insert line 134677 _csi_S - pan down 134678 _csi_T - pan up 134679 1346802022-04-01 H.J. Lu <hjl.tools@gmail.com> 134681 134682 x86: Remove bfd_arch_l1om and bfd_arch_k1om 134683 Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been 134684 removed from gas, ld and opcodes. 134685 134686 bfd/ 134687 134688 * Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo. 134689 (ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c. 134690 * archures.c (bfd_mach_l1om): Removed. 134691 (bfd_mach_l1om_intel_syntax): Likewise. 134692 (bfd_mach_k1om): Likewise. 134693 (bfd_mach_k1om_intel_syntax): Likewise. 134694 (bfd_k1om_arch): Likewise. 134695 (bfd_l1om_arch): Likewise. 134696 (bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch 134697 references. 134698 * config.bfd (targ_selvecs): Remove l1om_elf64_vec. 134699 l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec. 134700 (targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch. 134701 * configure.ac (k1om_elf64_vec): Removed. 134702 (k1om_elf64_fbsd_vec): Likewise. 134703 (l1om_elf64_vec): Likewise. 134704 (l1om_elf64_fbsd_vec): Likewise. 134705 * cpu-k1om.c: Removed. 134706 * cpu-l1om.c: Likewise. 134707 * elf64-x86-64.c (elf64_l1om_elf_object_p): Removed. 134708 (elf64_k1om_elf_object_p): Likewise. 134709 (l1om_elf64_vec): Removed. 134710 (l1om_elf64_fbsd_vec): Likewise. 134711 (k1om_elf64_vec): Likewise. 134712 (k1om_elf64_fbsd_vec): Likewise. 134713 (ELF_TARGET_OS): Undefine. 134714 * targets.c (_bfd_target_vector): Remove k1om_elf64_vec, 134715 k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec. 134716 * Makefile.in: Regenerate. 134717 * bfd-in2.h: Likewise. 134718 * configure: Likewise. 134719 134720 opcodes/ 134721 134722 * configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references. 134723 * disassemble.c (disassembler): Likewise. 134724 * configure: Regenerate. 134725 1347262022-04-01 Simon Marchi <simon.marchi@polymtl.ca> 134727 134728 gdb/ctf: pass partial symtab's filename to buildsym_compunit 134729 I noticed that the CTF symbol reader passes the objfile's name to all 134730 buildsym_compunit instances it creates. The result is that all 134731 compunit_symtabs created have the same name, that of the objfile: 134732 134733 { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00) 134734 { ((struct compunit_symtab *) 0x621000286760) 134735 debugformat ctf 134736 producer (null) 134737 name libbabeltrace2.so.0.0.0 134738 dirname (null) 134739 blockvector ((struct blockvector *) 0x6210003911d0) 134740 user ((struct compunit_symtab *) (null)) 134741 { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0) 134742 fullname (null) 134743 linetable ((struct linetable *) 0x0) 134744 } 134745 } 134746 { ((struct compunit_symtab *) 0x621000275c10) 134747 debugformat ctf 134748 producer (null) 134749 name libbabeltrace2.so.0.0.0 134750 dirname (null) 134751 blockvector ((struct blockvector *) 0x621000286710) 134752 user ((struct compunit_symtab *) (null)) 134753 { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730) 134754 fullname (null) 134755 linetable ((struct linetable *) 0x0) 134756 } 134757 } 134758 134759 Notice the two "name libbabeltrace2.so.0.0.0". 134760 134761 Change it to pass the partial_symtab's filename instead. The output 134762 becomes: 134763 134764 { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00) 134765 { ((struct compunit_symtab *) 0x621000295610) 134766 debugformat ctf 134767 producer (null) 134768 name libbabeltrace2.so.0.0.0 134769 dirname (null) 134770 blockvector ((struct blockvector *) 0x6210003a15d0) 134771 user ((struct compunit_symtab *) (null)) 134772 { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0) 134773 fullname (null) 134774 linetable ((struct linetable *) 0x0) 134775 } 134776 } 134777 { ((struct compunit_symtab *) 0x621000288700) 134778 debugformat ctf 134779 producer (null) 134780 name current-thread.c 134781 dirname (null) 134782 blockvector ((struct blockvector *) 0x6210002955c0) 134783 user ((struct compunit_symtab *) (null)) 134784 { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0) 134785 fullname (null) 134786 linetable ((struct linetable *) 0x0) 134787 } 134788 } 134789 134790 Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as 134791 its name. This is because the CTF symbol reader really creates a 134792 partial symtab named like this. It appears to be because the debug info 134793 contains information that has been factored out of all CUs and is at the 134794 "top-level" of the objfile, outside any real CU. So it creates a 134795 partial symtab and an artificial CU that's named after the objfile. 134796 134797 Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b 134798 1347992022-04-01 Simon Marchi <simon.marchi@polymtl.ca> 134800 134801 gdb: print compunit_symtab name in "maint info symtabs" 134802 I think it would make sense to print a compunit_symtab's name in "maint 134803 info symtabs". If you are looking for a given CU in the list, that's 134804 probably the field you will be looking at. As the doc of 134805 compunit_symtab::name says, it is not meant to be a reliable file name, 134806 it is for debugging purposes (and "maint info symtabs" exists for 134807 debugging purposes). 134808 134809 Sample output with the new field: 134810 134811 (gdb) maintenance info symtabs 134812 { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) 134813 { ((struct compunit_symtab *) 0x621000131630) 134814 debugformat DWARF 5 134815 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 134816 name test.c 134817 dirname /home/simark/build/binutils-gdb-one-target/gdb 134818 blockvector ((struct blockvector *) 0x621000131d10) 134819 user ((struct compunit_symtab *) (null)) 134820 { symtab test.c ((struct symtab *) 0x6210001316b0) 134821 fullname (null) 134822 linetable ((struct linetable *) 0x621000131d40) 134823 } 134824 { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0) 134825 fullname (null) 134826 linetable ((struct linetable *) 0x0) 134827 } 134828 { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710) 134829 fullname (null) 134830 linetable ((struct linetable *) 0x0) 134831 } 134832 } 134833 { ((struct compunit_symtab *) 0x6210001170a0) 134834 debugformat DWARF 5 134835 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 134836 name foo.c 134837 dirname /home/simark/build/binutils-gdb-one-target/gdb 134838 blockvector ((struct blockvector *) 0x621000131580) 134839 user ((struct compunit_symtab *) (null)) 134840 { symtab foo.c ((struct symtab *) 0x621000117120) 134841 fullname (null) 134842 linetable ((struct linetable *) 0x6210001315b0) 134843 } 134844 { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150) 134845 fullname (null) 134846 linetable ((struct linetable *) 0x0) 134847 } 134848 } 134849 } 134850 134851 Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211 134852 1348532022-04-01 Simon Marchi <simon.marchi@polymtl.ca> 134854 134855 gdb/ctf: don't create a buildsym_compunit when building partial symbols 134856 I am trying to do some changes to buildsym_compunit, so I am auditing 134857 the current uses. Something seems odd with this use of 134858 buildsym_compunit (that this patch removes). 134859 134860 A buildsym_compunit is normally used when building a compunit_symtab. 134861 That is, when expanding a partial symtab into a full compunit symtab. 134862 In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which 134863 is only used when creating partial symtabs. At this moment, I don't 134864 see how that's useful. ctf_start_archive creates a new 134865 buildsym_compunit and starts a subfile. But that buildsym_compunit is 134866 never used again. It's just overriden in ctf_start_symtab, which means 134867 we leak the old buildsym_compunit, I suppose. 134868 134869 Remove ctf_start_archive completely. Add an assert in 134870 ctf_start_symtab to verify that we are not overwriting an existing 134871 buildsym_compunit (meaning we'd leak the existing one). This assert 134872 triggers without the other part of the fix. When doing: 134873 134874 $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 134875 ... 134876 (gdb) maintenance expand-symtabs 134877 /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed. 134878 134879 Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592 134880 1348812022-04-01 Tom Tromey <tom@tromey.com> 134882 134883 Style URLs in GDB output 134884 I noticed that GDB will display URLs in a few spots. This changes 134885 them to be styled. Originally I thought I'd introduce a new "url" 134886 style, but there aren't many places to use this, so I just reused 134887 filename styling instead. This patch also changes the debuginfod URL 134888 list to be printed one URL per line. I think this is probably a bit 134889 easier to read. 134890 1348912022-04-01 GDB Administrator <gdbadmin@sourceware.org> 134892 134893 Automatic date update in version.in 134894 1348952022-03-31 Simon Marchi <simon.marchi@polymtl.ca> 134896 134897 gdb: initialize ctf_context::builder in create_partial_symtab 134898 I built a random project with -gctf, in order to test the CTF support in 134899 GDB. With my ASan/UBSan/etc-enabled build of GDB, I get: 134900 134901 $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 134902 ... 134903 Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0... 134904 /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment 134905 0xbebebebebebebebe: note: pointer points here 134906 134907 The 0xbebebebebebebebe value is a sign that the ctf_context::builder 134908 field is uninitialized. The problem probably goes under the radar if 134909 the field happens to be zero-initialized, because ctf_start_archive 134910 contains this code: 134911 134912 if (ccx->builder == nullptr) 134913 { 134914 ccx->builder = new buildsym_compunit (of, 134915 of->original_name, nullptr, language_c, 0); 134916 134917 If the field was zero-initialized (by chance), this will create a new 134918 buildsym_compunit. But if the field was purposely filled with random 134919 bytes by one of the sanitizers, we won't create a buildsym_compunit here 134920 and we'll continue with ccx->builder equal to 0xbebebebebebebebe. 134921 134922 Fix this the easy way by initializing ccx->builder where the other 134923 ctf_context fields are initialized (yeah, this code could be made nicer 134924 C++, but I am going for the obvious fix here). 134925 134926 With this patch, this passes cleanly on my system: 134927 134928 $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc" 134929 # of expected passes 40 134930 134931 ... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my 134932 system gcc does not have it. 134933 134934 Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9 134935 1349362022-03-31 Tom Tromey <tromey@adacore.com> 134937 134938 Remove dbx mode 134939 This patch removes gdb's dbx mode. Regression tested on x86-64 Fedora 134940 34. 134941 1349422022-03-31 H.J. Lu <hjl.tools@gmail.com> 134943 134944 gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml 134945 1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate 134946 them into a single keys.xml. 134947 2. Enable PKU for x32 to fix: 134948 134949 $ gdbserver :123456 x32-program 134950 ... 134951 .../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected 134952 . 134953 Unknown register pkru requested 134954 134955 on Tiger Lake. 134956 1349572022-03-31 Simon Marchi <simon.marchi@polymtl.ca> 134958 134959 gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait 134960 The check removed by this patch, using current_inferior, looks wrong. 134961 When debugging multiple inferiors with the Linux native target and 134962 linux_handle_extended_wait is called, there's no guarantee about which 134963 is the current inferior. The vfork-done event we receive could be for 134964 any inferior. If the vfork-done event is for a non-current inferior, we 134965 end up wrongfully ignoring it. As a result, the core never processes a 134966 TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed 134967 is never cleared, and breakpoints are never reinserted. However, 134968 because the Linux native target decided to ignore the event, it resumed 134969 the thread - while breakpoints out. And that's bad. 134970 134971 The proposed fix is to remove this check. Always report vfork-done 134972 events and let infrun's logic decide if it should be ignored. We don't 134973 save much cycles by filtering the event here. 134974 134975 Add a test that replicates the situation described above. See comments 134976 in the test for more details. 134977 134978 Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf 134979 1349802022-03-31 Simon Marchi <simon.marchi@polymtl.ca> 134981 134982 gdbserver/linux: set lwp !stopped when failing to resume 134983 I see some failures, at least in gdb.multi/multi-re-run.exp and 134984 gdb.threads/interrupted-hand-call.exp. Running `stress -C $(nproc)` at 134985 the same time as the test makes those tests relatively frequent. 134986 134987 Let's take gdb.multi/multi-re-run.exp as an example. The failure looks 134988 like this, an unexpected "no resumed": 134989 134990 continue 134991 Continuing. 134992 No unwaited-for children left. 134993 (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit 134994 134995 The situation is: 134996 134997 - Inferior 1 is stopped somewhere, it won't really play a role here. 134998 - Inferior 2 has 2 threads, both stopped. 134999 - We resume inferior 2, the leader thread is expected to exit, making 135000 the process exit. 135001 135002 From GDB's perspective, a failing run looks like this: 135003 135004 [infrun] fetch_inferior_event: enter 135005 [infrun] scoped_disable_commit_resumed: reason=handling event 135006 [infrun] do_target_wait: Found 2 inferiors, starting at #1 135007 [infrun] random_pending_event_thread: None found. 135008 [remote] wait: enter 135009 [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e; 135010 [remote] wait: exit 135011 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 135012 [infrun] print_target_wait_results: 713933.713933.0 [Thread 713933.713933], 135013 [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP 135014 [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP 135015 [infrun] clear_step_over_info: clearing step over info 135016 [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0 135017 [infrun] handle_signal_stop: stop_pc=0x555555555195 135018 [infrun] start_step_over: enter 135019 [infrun] start_step_over: stealing global queue of threads to step, length = 0 135020 [infrun] operator(): step-over queue now empty 135021 [infrun] start_step_over: exit 135022 [infrun] process_event_stop_test: no stepping, continue 135023 [remote] Sending packet: $Z0,555555555194,1#8e 135024 [remote] Packet received: OK 135025 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195 135026 [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a 135027 [remote] Packet received: OK 135028 [remote] Sending packet: $vCont;c:pae4cd.-1#9f 135029 [infrun] prepare_to_wait: prepare_to_wait 135030 [infrun] reset: reason=handling event 135031 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote 135032 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote 135033 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote 135034 [infrun] fetch_inferior_event: exit 135035 [infrun] fetch_inferior_event: enter 135036 [infrun] scoped_disable_commit_resumed: reason=handling event 135037 [infrun] do_target_wait: Found 2 inferiors, starting at #0 135038 [infrun] random_pending_event_thread: None found. 135039 [remote] wait: enter 135040 [remote] Packet received: N 135041 [remote] wait: exit 135042 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 135043 [infrun] print_target_wait_results: -1.0.0 [process -1], 135044 [infrun] print_target_wait_results: status->kind = NO_RESUMED 135045 [infrun] handle_inferior_event: status->kind = NO_RESUMED 135046 [remote] Sending packet: $Hgp0.0#ad 135047 [remote] Packet received: OK 135048 [remote] Sending packet: $qXfer:threads:read::0,1000#92 135049 [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n 135050 [infrun] stop_waiting: stop_waiting 135051 [remote] Sending packet: $qXfer:threads:read::0,1000#92 135052 [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n 135053 [infrun] infrun_async: enable=0 135054 [infrun] reset: reason=handling event 135055 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote 135056 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote 135057 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote 135058 [infrun] fetch_inferior_event: exit 135059 135060 We can see that we resume the inferior with vCont;c, but got NO_RESUMED. 135061 When the test passes, we get an EXITED status to indicate the process 135062 has exited. 135063 135064 From GDBserver's point of view, it looks like this. The logs contain 135065 some logging I added and that are part of this patch. 135066 135067 [remote] getpkt: getpkt ("vCont;c:pae4cf.-1"); [no ack sent] 135068 [threads] resume: enter 135069 [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped 135070 [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped 135071 [threads] get_pc: pc is 0x555555555195 135072 [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195 135073 [threads] get_pc: pc is 0x7ffff7d35a95 135074 [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95 135075 [threads] resume: Resuming, no pending status or step over needed 135076 [threads] resume_one_thread: resuming LWP 713935 135077 [threads] proceed_one_lwp: lwp 713935 135078 [threads] resume_one_lwp_throw: continue from pc 0x555555555195 135079 [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected) 135080 [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0 135081 [threads] resume_one_thread: resuming LWP 713936 135082 [threads] proceed_one_lwp: lwp 713936 135083 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 135084 [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected) 135085 [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) 135086 [threads] resume: exit 135087 [threads] wait_1: enter 135088 [threads] wait_1: [<all threads>] 135089 [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK 135090 [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0 135091 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 135092 [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected) 135093 [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) 135094 [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0 135095 [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1 135096 [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd). 135097 [threads] delete_lwp: deleting 713935 135098 [threads] wait_for_event_filtered: exit (no unwaited-for LWP) 135099 sigchld_handler 135100 [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED 135101 [threads] wait_1: exit 135102 135103 What happens is: 135104 135105 - We resume the leader (713935) successfully. 135106 - The leader exits. 135107 - We resume the secondary thread (713936), we get ESRCH. This is 135108 expected this the leader has exited. 135109 - resume_one_lwp_throw throws, it's caught by resume_one_lwp. 135110 - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the 135111 failure can be explained by the LWP becoming zombie, and swallows the 135112 error. 135113 - Note that this means that the secondary lwp still has stopped==1. 135114 - wait_1 is called, probably because linux_process_target::resume marks 135115 the async pipe at the end. 135116 - The exit event isn't ready yet, probably because the machine is under 135117 load, so waitpid returns nothing. 135118 - check_zombie_leaders detects that the leader is zombie and deletes 135119 - We try to find a resumed (non-stopped) LWP to get an event from, 135120 there's none since the leader (that was resumed) is now deleted, and 135121 the secondary thread is still marked stopped. 135122 wait_for_event_filtered returns -1, causing wait_1 to return 135123 NO_RESUMED. 135124 135125 What I notice here is that there is some kind of race between the 135126 availability of the process' exit notification and the call to wait_1 135127 that results from marking the async pipe at the end of resume. 135128 135129 I think what we want from this wait_1 invocation is to keep waiting, as 135130 we will eventually get thread exit notifications for both of our 135131 threads. 135132 135133 The fix I came up with is to mark the secondary thread as !stopped (or 135134 resumed) when we fail to resume it. This makes wait_1 see that there is 135135 at least one resume lwp, so it won't return NO_RESUMED. I think this 135136 makes sense to consider it resumed, because we are going to receive an 135137 exit event for it. Here's the GDBserver logs with the fix applied: 135138 135139 [threads] resume: enter 135140 [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped 135141 [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped 135142 [threads] get_pc: pc is 0x555555555195 135143 [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195 135144 [threads] get_pc: pc is 0x7ffff7d35a95 135145 [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95 135146 [threads] resume: Resuming, no pending status or step over needed 135147 [threads] resume_one_thread: resuming LWP 724597 135148 [threads] proceed_one_lwp: lwp 724597 135149 [threads] resume_one_lwp_throw: continue from pc 0x555555555195 135150 [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected) 135151 [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0 135152 [threads] resume_one_thread: resuming LWP 724598 135153 [threads] proceed_one_lwp: lwp 724598 135154 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 135155 [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected) 135156 [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) 135157 [threads] resume: exit 135158 [threads] wait_1: enter 135159 [threads] wait_1: [<all threads>] 135160 sigchld_handler 135161 [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK 135162 [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0 135163 [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1 135164 [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd). 135165 [threads] delete_lwp: deleting 724597 135166 [threads] wait_for_event_filtered: sigsuspend'ing 135167 sigchld_handler 135168 [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK 135169 [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited) 135170 [threads] filter_event: 724598 exited 135171 [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK 135172 [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited) 135173 [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK 135174 sigchld_handler 135175 [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0 135176 [threads] wait_1: exit 135177 135178 Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100 135179 1351802022-03-31 Simon Marchi <simon.marchi@efficios.com> 135181 135182 gdb/testsuite/tui: implement _csi_P proc 135183 Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these 135184 errors when running gdb.tui/scroll.exp: 135185 135186 ERROR: invalid command name "_csi_P" 135187 while executing 135188 "::gdb_tcl_unknown _csi_P 2" 135189 ("uplevel" body line 1) 135190 invoked from within 135191 "uplevel 1 ::gdb_tcl_unknown $args" 135192 (procedure "::unknown" line 5) 135193 invoked from within 135194 "_csi_P 2" 135195 ("eval" body line 1) 135196 invoked from within 135197 "eval _csi_$cmd $params" 135198 135199 It looks like GDB is emitting a CSI that it did not emit before, the 135200 "Delete character" one: 135201 135202 https://vt100.net/docs/vt510-rm/DCH.html 135203 135204 Implement it. 135205 135206 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 135207 Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7 135208 1352092022-03-31 Simon Marchi <simon.marchi@polymtl.ca> 135210 135211 gdb: fix use of fprintf_filtered in top.c 135212 A race condition in how patches were pushed causes this build failure: 135213 135214 CXX top.o 135215 /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’: 135216 /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’? 135217 1622 | fprintf_filtered (stream, _("\ 135218 | ^~~~~~~~~~~~~~~~ 135219 135220 fprintf_filtered has been removed, gdb_printf must be used now. Fix 135221 this. 135222 135223 Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b 135224 1352252022-03-31 Richard Sandiford <richard.sandiford@arm.com> 135226 135227 aarch64: Relax check for RNG system registers 135228 FEAT_RNG is an optional Armv8.5-A extension, but it can be backported 135229 to earlier architectures as well. GAS previously made the RNG registers 135230 conditional on having both armv8.5-a and +rng, but only +rng should be 135231 required. 135232 135233 This seems to be the only feature that was handled like this. 135234 135235 opcodes/ 135236 * aarch64-opc.c (SR_RNG): Don't require V8_5. 135237 135238 gas/ 135239 * testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New 135240 test. 135241 1352422022-03-31 Eli Zaretskii <eliz@gnu.org> 135243 135244 * gdb/top.c (print_gdb_configuration): Announce --enable-threading. 135245 This includes the reporting of --enable/disable-threading as part of 135246 the GDB configuration description. 135247 1352482022-03-31 Simon Marchi <simon.marchi@efficios.com> 135249 135250 gdb/infrun: add reason parameter to stop_all_threads 135251 Add a "reason" parameter, only used to show in debug messages what is 135252 the reason for stopping all threads. This helped me understand the 135253 debug logs while adding some new uses of stop_all_threads, so I am 135254 proposing to merge it. 135255 135256 Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55 135257 1352582022-03-31 Simon Marchi <simon.marchi@efficios.com> 135259 135260 gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.* 135261 I forgot to do this before pushing the previous commit. 135262 135263 Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805 135264 1352652022-03-31 Simon Marchi <simon.marchi@efficios.com> 135266 135267 gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off 135268 The particular behavior we have when using that combination of settings 135269 doesn't seem tested at all (at least, I don't find it if I grep for "Can 135270 not resume the parent process"). Add a simple test for that. 135271 135272 Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5 135273 1352742022-03-31 Nick Clifton <nickc@redhat.com> 135275 135276 Accept the + character as part of filenames for MRI scripts. 135277 1352782022-03-31 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 135279 135280 Fix procfs.c compilation 135281 procfs.c doesn't compile on Solaris: 135282 135283 /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’: 135284 /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope 135285 3302 | gdb_argv built_argv (args); 135286 | ^~~~~~~~ 135287 /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’? 135288 3303 | for (char *arg : built_argv) 135289 | ^~~~~~~~~~ 135290 | buildargv 135291 135292 Fixed by including "gdbsupport/buildargv.h". 135293 135294 Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11. 135295 1352962022-03-31 GDB Administrator <gdbadmin@sourceware.org> 135297 135298 Automatic date update in version.in 135299 1353002022-03-30 Simon Marchi <simon.marchi@polymtl.ca> 135301 135302 gdb/testsuite: add tests for Term 135303 While trying to review Andrew's patch here [1], I thought I spotted a 135304 bug in the handling of a CSI, but I had no way to know for sure. So I 135305 thought it would be useful to have unit tests for the handling of 135306 control characters and control sequences of our toy terminal 135307 implementation. It might help avoid chasing bugs in the GDB TUI when in 135308 reality it's a problem with the testsuite's terminal implementation. 135309 135310 Add the gdb.tui/tuiterm.exp file to do that. All currently supported 135311 control sequences and characters are tested, except _csi_m (the one that 135312 handles colors and stuff). _csi_m should probably be tested too, but it 135313 will require more work. 135314 135315 Fix a few issues that the tests spotted: 135316 135317 - backspace: according to [3] (table 4-1), a backspace when the cursor 135318 is at the beginning of a line should have no effect. Our 135319 implementation did wrap to the end of the previous line. Change our 135320 implementation to match the doc (and the test). 135321 - insert character: this control sequence is supposed to insert blank 135322 characters, shifting all the rest of the line right. The current 135323 implementation moves N characters right, but it overwrites the 135324 characters on the right instead of shifting them. It also doesn't 135325 insert blank characters at the cursor. 135326 - Cursor down, forward, next line: off-by-one error when reaching the 135327 end of the display. 135328 - erase in display, line: off-by-one errors. 135329 - vertical line position absolute: allowed setting the cursor outside 135330 the display, when it should clamp it to the display size. 135331 135332 I found that this web page [2] gave some good clues on the expected 135333 behavior of some control characters or sequences that some other pages 135334 didn't. 135335 135336 [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html 135337 [2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences 135338 [3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3 135339 135340 Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d 135341 1353422022-03-30 Tom Tromey <tom@tromey.com> 135343 135344 Only allow QUIT on the main thread 135345 Pedro pointed out that gdb worker threads should not react to quits. 135346 While I don't think that the new DWARF reader can call QUIT from a 135347 worker thread (and I don't think the existing minsym threading code 135348 can either), it seems safest to address this before checking in the 135349 new code. This patch arranges for the QUIT macro to only work on the 135350 main thread. 135351 1353522022-03-30 Tom Tromey <tromey@adacore.com> 135353 135354 Use gdb_printf and gdb_vprintf in more places 135355 Luis pointed out that I missed a spot in the gdb_printf conversion -- 135356 namely aarch64-nat.c. While looking at this, I found another spot in 135357 darwin-nat.c that I also missed. I can't build either of these, but I 135358 think this patch should fix the problems. 135359 135360 Consolidate definition of current_directory 135361 I noticed that both gdbserver and gdb define current_directory. 135362 However, as it is referenced by gdbsupport, it seemed better to define 135363 it there as well. This patch also moves the declaration to 135364 pathstuff.h. Tested by rebuilding. 135365 1353662022-03-30 Tom Tromey <tromey@adacore.com> 135367 135368 Decode "dynamic" interface types in Ada 135369 In Ada, if a class implements an interface and has a dynamic 135370 superclass, then the "offset to top" -- the offset that says how to 135371 turn a pointer to the interface into a pointer to the whole object -- 135372 is stored in the object itself. This patch changes GDB to understand 135373 this. 135374 135375 Because this only touches Ada code, and because Joel already reviewed 135376 it internally, I am checking it in. 135377 1353782022-03-30 Jeff Law <jeffreyalaw@gmail.com> 135379 135380 Fix for MUL instruction on the v850 135381 * sim/v850/simops.c (Multiply64): Properly test if we need to 135382 negate either of the operands. 135383 135384 * sim/testsuite/v850/mul.cgs: New test. 135385 1353862022-03-30 GDB Administrator <gdbadmin@sourceware.org> 135387 135388 Automatic date update in version.in 135389 1353902022-03-29 Tom Tromey <tom@tromey.com> 135391 135392 Remove two unused hooks 135393 I noticed that a couple of deprecated hooks aren't ever called, so 135394 they can't really be used by Insight. This patch removes them 135395 entirely. I checked the Insight sources, and these aren't mentioned 135396 there, either. 135397 1353982022-03-29 Tom Tromey <tom@tromey.com> 135399 135400 Remove unnecessary calls to wrap_here and gdb_flush 135401 Various spots in gdb currently know about the wrap buffer, and so are 135402 careful to call wrap_here to be certain that all output has been 135403 flushed. 135404 135405 Now that the pager is just an ordinary stream, this isn't needed, and 135406 a simple call to gdb_flush is enough. 135407 135408 Similarly, there are places where gdb prints to gdb_stderr, but first 135409 flushes gdb_stdout. stderr_file already flushes gdb_stdout, so these 135410 aren't needed. 135411 1354122022-03-29 Tom Tromey <tom@tromey.com> 135413 135414 Minor comment updates in utils.h 135415 This patch updates some comments in utils.h to more closely reflect 135416 the new reality. 135417 135418 Remove vfprintf_styled 135419 Nothing calls vfprintf_styled any more, so remove it. 135420 135421 Remove ui_out_flag::unfiltered_output 135422 There is no longer any need for ui_out_flag::unfiltered_output -- 135423 nothing ever sets this flag. This used to be needed to make the 135424 _unfiltered output work, but now only printf_unfiltered can be used, 135425 and it uses the puts_unfiltered method. This patch removes the flag 135426 and the dead code. 135427 135428 Rename fprintf_symbol_filtered 135429 fprintf_symbol_filtered is misnamed, because whether filtering happens 135430 is now up to the stream. This renames it to fprintf_symbol, which 135431 isn't a great name (the first "f" doesn't mean much and the second one 135432 is truly meaningless here), but "print_symbol" was already taken. 135433 135434 Rename puts_filtered_tabular 135435 puts_filtered_tabular is now misnamed, because whether filtering 135436 happens is now up to the stream. So, rename it. (This function is 135437 pretty weird, and should probably be rewritten to avoid using the 135438 chars_printed global, and moved into objc-lang.c. However, I haven't 135439 done so.) 135440 135441 Rename print_spaces_filtered 135442 print_spaces_filtered is now misnamed, because whether filtering 135443 happens is up to the stream. So, rename it. 135444 135445 Unify gdb printf functions 135446 Now that filtered and unfiltered output can be treated identically, we 135447 can unify the printf family of functions. This is done under the name 135448 "gdb_printf". Most of this patch was written by script. 135449 135450 Unify gdb putc functions 135451 Now that filtered and unfiltered output can be treated identically, we 135452 can unify the putc family of functions. This is done under the name 135453 "gdb_putc". Most of this patch was written by script. 135454 135455 Unify gdb puts functions 135456 Now that filtered and unfiltered output can be treated identically, we 135457 can unify the puts family of functions. This is done under the name 135458 "gdb_puts". Most of this patch was written by script. 135459 135460 Unify vprintf functions 135461 Now that filtered and unfiltered output can be treated identically, we 135462 can unify the vprintf family of functions: vprintf_filtered, 135463 vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For 135464 the gdb_stdout variants, recall that only printf_unfiltered gets truly 135465 unfiltered output at this point.) This removes one such function and 135466 renames the remaining two to "gdb_vprintf". All callers are updated. 135467 Much of this patch was written by script. 135468 135469 Remove fputs_styled_unfiltered 135470 fputs_styled_unfiltered is only called from cli_ui_out, so remove it. 135471 This area will be further simplified in future patches. 135472 1354732022-03-29 Tom Tromey <tom@tromey.com> 135474 135475 Change the pager to a ui_file 135476 This rewrites the output pager as a ui_file implementation. 135477 135478 A new header is introduced to declare the pager class. The 135479 implementation remains in utils.c for the time being, because there 135480 are some static globals there that must be used by this code. (This 135481 could be cleaned up at some future date.) 135482 135483 I went through all the text output in gdb to ensure that this change 135484 should be ok. There are a few cases: 135485 135486 * Any existing call to printf_unfiltered is required to be avoid the 135487 pager. This is ensured directly in the implementation. 135488 135489 * All remaining calls to the f*_unfiltered functions -- the ones that 135490 take an explicit ui_file -- either send to an unfiltered stream 135491 (e.g., gdb_stderr), which is obviously ok; or conditionally send to 135492 gdb_stdout 135493 135494 I investigated all such calls by searching for: 135495 135496 grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr 135497 135498 This yields a number of candidates to check. 135499 135500 * The breakpoint _print_recreate family, and 135501 save_trace_state_variables. These are used for "save" commands 135502 and so are fine. 135503 135504 * Things printing to a temporary stream. Obviously ok. 135505 135506 * Disassembly selftests. 135507 135508 * print_gdb_help - this is non-obvious, but ok because paging isn't 135509 yet enabled at this point during startup. 135510 135511 * serial.c - doens't use gdb_stdout 135512 135513 * The code in compile/. This is all printing to a file. 135514 135515 * DWARF DIE dumping - doesn't reference gdb_stdout. 135516 135517 * Calls to the _filtered form -- these are all clearly ok, because if 135518 they are using gdb_stdout, then filtering will still apply; and if 135519 not, then filtering never applied and still will not. 135520 135521 Therefore, at this point, there is no longer any distinction between 135522 all the other _filtered and _unfiltered calls, and they can be 135523 unified. 135524 135525 In this patch, take special note of the vfprintf_maybe_filtered and 135526 ui_file::vprintf change. This is one instance of the above idea, 135527 erasing the distinction between filtered and unfiltered -- in this 135528 part of the change, the "unfiltered_output" flag is never passe to 135529 cli_ui_out. Subsequent patches will go much further in this 135530 direction. 135531 135532 Also note the can_emit_style_escape changes in ui-file.c. Checking 135533 against gdb_stdout or gdb_stderr was always a bit of a hack; and now 135534 it is no longer needed, because this is decision can be more fully 135535 delegated to the particular ui_file implementation. 135536 135537 ui_file::can_page is removed, because this patch removed the only call 135538 to it. 135539 135540 I think this is the main part of fixing PR cli/7234. 135541 135542 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7234 135543 1355442022-03-29 Tom Tromey <tom@tromey.com> 135545 135546 Remove vfprintf_styled_no_gdbfmt 135547 This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point 135548 of call. 135549 135550 Add style-escape methods to ui_file 135551 This adds emit_style_escape and reset_style methods to ui_file. These 135552 aren't used yet, but they will be once the pager is converted to be a 135553 ui_file subclass. 135554 135555 Add puts_unfiltered method to ui_file 135556 When the pager is rewritten as a ui_file, gdb will still need a way to 135557 bypass the filtering. After examining a few approaches, I chose this 135558 patch, which adds a puts_unfiltered method to ui_file. For most 135559 implementations of ui_file, this will just delegate to puts. This 135560 patch also switches printf_unfiltered to use the new method. 135561 135562 Only have one API for unfiltered output 135563 At the end of this series, the use of unfiltered output will be very 135564 restricted -- only places that definitely need it will use it. To 135565 this end, I thought it would be good to reduce the number of 135566 _unfiltered APIs that are exposed. This patch changes gdb so that 135567 only printf_unfiltered exists. (After this patch, the f* variants 135568 still exist as well, but those will be removed later.) 135569 1355702022-03-29 Tom Tromey <tom@tromey.com> 135571 135572 Remove some uses of printf_unfiltered 135573 A number of spots call printf_unfiltered only because they are in code 135574 that should not be interrupted by the pager. However, I believe these 135575 cases are all handled by infrun's blanket ban on paging, and so can be 135576 converted to the default (_filtered) API. 135577 135578 After this patch, I think all the remaining _unfiltered calls are ones 135579 that really ought to be. A few -- namely in complete_command -- could 135580 be replaced by a scoped assignment to pagination_enabled, but for the 135581 remainder, the code seems simple enough like this. 135582 1355832022-03-29 Tom Tromey <tom@tromey.com> 135584 135585 Use unfiltered output in annotate.c 135586 It seems to me that annotations should not be filtered. While it 135587 might be weird for an annotation-based UI to use the pager, it's not, 135588 I think, out of the question. This patch makes this change. 135589 1355902022-03-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 135591 Aleksandar Paunovic <aleksandar.paunovic@intel.com> 135592 135593 gdb/remote: use current_inferior in read_ptid if multi-process not supported 135594 When parsing the ptid out of a reply package, if the multi-process 135595 extensions are not supported, use current_inferior's pid as the pid of 135596 the reported thread, instead of inferior_ptid. This is needed because 135597 the inferior_ptid may be null_ptid although a legit context exists, 135598 due to a prior context switch via switch_to_inferior_no_thread. 135599 135600 Below is a scenario that illustrates what could go wrong. First, 135601 setup a multi-target scenario. This is needed, because in a 135602 multi-target setting, the inferior_ptid is cleared out before waiting 135603 on targets. The second inferior below sits on top of a remote target. 135604 Multi-process packets are disabled. 135605 135606 $ # First, spawn a process with PID 26253 to attach to later. 135607 $ gdb-up a.out 135608 Reading symbols from a.out... 135609 (gdb) maint set target-non-stop on 135610 (gdb) set remote multiprocess-feature-packet off 135611 (gdb) start 135612 ... 135613 (gdb) add-inferior -no-connection 135614 [New inferior 2] 135615 Added inferior 2 135616 (gdb) inferior 2 135617 [Switching to inferior 2 [<null>] (<noexec>)] 135618 (gdb) target extended-remote | gdbserver --multi - 135619 Remote debugging using | gdbserver --multi - 135620 Remote debugging using stdio 135621 (gdb) attach 26253 135622 Attaching to Remote target 135623 Attached; pid = 26253 135624 [New Thread 26253] 135625 [New inferior 3] 135626 Reading /tmp/a.out from remote target... 135627 ... 135628 [New Thread 26253] 135629 ... 135630 Reading /usr/local/lib/debug/....debug from remote target... 135631 >>> GDB seems to hang here. 135632 135633 After attaching to a process and reading some library files, GDB 135634 seems to hang. One interesting thing to note is that 135635 135636 [New Thread 26253] 135637 135638 appears twice. We also see 135639 135640 [New inferior 3] 135641 135642 Running the same scenario with "debug infrun on" reveals more details. 135643 135644 ... 135645 (gdb) attach 26253 135646 [infrun] scoped_disable_commit_resumed: reason=attaching 135647 Attaching to Remote target 135648 Attached; pid = 26253 135649 [New Thread 26253] 135650 [infrun] infrun_async: enable=1 135651 [infrun] attach_command: immediately after attach: 135652 [infrun] attach_command: thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING 135653 [infrun] clear_proceed_status_thread: 26253.26253.0 135654 [infrun] reset: reason=attaching 135655 [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads 135656 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote 135657 [infrun] fetch_inferior_event: enter 135658 [infrun] scoped_disable_commit_resumed: reason=handling event 135659 [infrun] do_target_wait: Found 2 inferiors, starting at #1 135660 [infrun] random_pending_event_thread: None found. 135661 [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) = 135662 [infrun] print_target_wait_results: 26253.26253.0 [Thread 26253], 135663 [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_0 135664 [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0 135665 [infrun] start_step_over: enter 135666 [infrun] start_step_over: stealing global queue of threads to step, length = 0 135667 [infrun] operator(): step-over queue now empty 135668 [infrun] start_step_over: exit 135669 [infrun] context_switch: Switching context from 0.0.0 to 26253.26253.0 135670 [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151 135671 [infrun] stop_waiting: stop_waiting 135672 [infrun] stop_all_threads: starting 135673 [infrun] stop_all_threads: pass=0, iterations=0 135674 [New inferior 3] 135675 Reading /tmp/a.out from remote target... 135676 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. 135677 Reading /tmp/a.out from remote target... 135678 Reading symbols from target:/tmp/a.out... 135679 [New Thread 26253] 135680 [infrun] stop_all_threads: 4723.4723.0 not executing 135681 [infrun] stop_all_threads: 26253.26253.0 not executing 135682 [infrun] stop_all_threads: 42000.26253.0 executing, need stop 135683 [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) = 135684 [infrun] print_target_wait_results: -1.0.0 [Thread 0], 135685 [infrun] print_target_wait_results: status->kind = IGNORE 135686 [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) = 135687 [infrun] print_target_wait_results: -1.0.0 [Thread 0], 135688 [infrun] print_target_wait_results: status->kind = IGNORE 135689 135690 GDB tried to stop Thread 42000.26253.0, which does not exist, and we 135691 are waiting for a stop event that will never happen. The PID in 135692 '42000.26253.0', namely 42000, is the PID of magic_null_ptid. 135693 It comes from gdb/remote.c:read_ptid: 135694 135695 /* Since the stub is not sending a process id, then default to 135696 what's in inferior_ptid, unless it's null at this point. If so, 135697 then since there's no way to know the pid of the reported 135698 threads, use the magic number. */ 135699 if (inferior_ptid == null_ptid) 135700 pid = magic_null_ptid.pid (); 135701 else 135702 pid = inferior_ptid.pid (); 135703 135704 if (obuf) 135705 *obuf = pp; 135706 return ptid_t (pid, tid); 135707 135708 Because multi-process was turned off, GDB did not parse an explicitly 135709 specified PID. Furthermore, inferior_ptid == null_ptid, and 135710 eventually GDB picked the PID from magic_null_ptid. 135711 135712 If target-non-stop is not turned on at the beginning, the same bug 135713 reveals itself as a duplicated thread as shown below. 135714 135715 # Same setup as above, without 'maint set target-non-stop on'. 135716 ... 135717 (gdb) attach 26253 135718 Attaching to Remote target 135719 Attached; pid = 26253 135720 [New inferior 3] 135721 ... 135722 [New Thread 26253] 135723 ... 135724 (gdb) info threads 135725 Id Target Id Frame 135726 1.1 process 13517 "a.out" main () at test.c:3 135727 * 2.1 Thread 26253 "a.out" 0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6 135728 3.1 Thread 26253 "a.out" Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 135729 (gdb) 135730 135731 Fix the problem by preferring current_inferior()'s pid instead of 135732 magic_null_ptid. 135733 135734 Regression-tested on X86-64 Linux. 135735 1357362022-03-29 Andrew Burgess <aburgess@redhat.com> 135737 135738 gdb/testsuite: fix test failure when building against readline v7 135739 The test added in the commit: 135740 135741 commit a6b413d24ccc5d76179bab866834e11fd6fec294 135742 Date: Fri Mar 11 14:44:03 2022 +0000 135743 135744 gdb: work around prompt corruption caused by bracketed-paste-mode 135745 135746 Was not written with readline 7 in mind, only readline 8+. Between 135747 readline 7 and 8 the escape sequence used to disable bracketed paste 135748 mode changed, an additional '\r' character was added to the end. In 135749 fact, it was the addition of this '\r' character that triggered the 135750 issue for which the above commit is part of the solution. 135751 135752 Anyway, the test tries to spot the case where the output from GDB is 135753 not perfect, but does have the above work around applied. However, 135754 the pattern in the test assumes that the problematic '\r' will be 135755 present, and this is only true for readline 8+. With readline 7 the 135756 test was failing. 135757 135758 In this commit I generalise the pattern a little so that the test will 135759 still KFAIL with readline 7. 135760 135761 It's a little unfortunate that the test is KFAILing with readline 7, 135762 as without the problematic '\r' there's actually no reason that GDB 135763 couldn't "do the right thing" in this case, in which case, the test 135764 would PASS, but that would require changes within GDB itself. 135765 135766 My preference then is that initially we patch the test to get it 135767 KFAILing, then in a separate commit I can modify GDB so that it can 135768 PASS with readline 7. 135769 1357702022-03-29 Andrew Burgess <aburgess@redhat.com> 135771 135772 gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp 135773 The test gdb.python/py-format-address.exp, added in commit: 135774 135775 commit 25209e2c6979c3838e14e099f0333609810db280 135776 Date: Sat Oct 23 09:59:25 2021 +0100 135777 135778 gdb/python: add gdb.format_address function 135779 135780 included 3 copy & paste errors where the wrong address was used in the 135781 expected output patterns. 135782 135783 The test compiles two almost identical test binaries (one function 135784 changes its name, that's the only difference), two inferiors are 135785 created, each inferior using one of the test binaries. 135786 135787 We then take the address of the name changing function in both 135788 inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests 135789 are carried out using these addresses. 135790 135791 What we're checking for is that symbols 'foo' and 'bar' show up in the 135792 correct inferior, and that (as this test is for a Python API feature), 135793 the user can have one inferior selected, but ask about the other 135794 inferior, and see the correct symbol in the result. 135795 135796 The hope is that the two binaries will be laid out identically by the 135797 compiler, and that 'foo' and 'bar' will be at the same address. This 135798 is fine, unless the executable is compiled as PIE (position 135799 independent executable), in which case there is a problem. 135800 135801 The problem is that though inferior 1 is set running, the inferior 2 135802 never is. If the executables are compiled as PIE, then the address in 135803 the inferior 2 will not have been resolved, while the address in the 135804 inferior 1 will have been, and so the two addresses we use in the 135805 tests will be different. 135806 135807 This issue was reported here: 135808 135809 https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html 135810 135811 The first part of the fix is to use the correct address variable in 135812 the expected output patterns, with this change the tests pass even 135813 when the executables are compiled as PIE. 135814 135815 A second part of this fix is to pass the 'nopie' option when we 135816 compile the tests, this should ensure that the address obtained in 135817 inferior 2 is the same as the address from inferior 1, which makes the 135818 test more useful. 135819 1358202022-03-29 Andrew Burgess <aburgess@redhat.com> 135821 135822 gdb/mi: fix use after free of frame_info causing spurious notifications 135823 In commit: 135824 135825 commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f 135826 Date: Wed Mar 16 15:08:22 2022 +0000 135827 135828 gdb/mi: consistently notify user when GDB/MI client uses -thread-select 135829 135830 Changes were made to GDB to address some inconsistencies in when 135831 notifications are sent from a MI terminal to a CLI terminal (when 135832 multiple terminals are in use, see new-ui command). 135833 135834 Unfortunately, in order to track when the currently selected frame has 135835 changed, that commit grabs a frame_info pointer before and after an MI 135836 command has executed, and compares the pointers to see if the frame 135837 has changed. 135838 135839 This is not safe. 135840 135841 If the frame cache is deleted for any reason then the frame_info 135842 pointer captured before the command started, is no longer valid, and 135843 any comparisons based on that pointer are undefined. 135844 135845 This was leading to random test failures for some folk, see: 135846 135847 https://sourceware.org/pipermail/gdb-patches/2022-March/186867.html 135848 135849 This commit changes GDB so we no longer hold frame_info pointers, but 135850 instead store the frame_id and frame_level, this is safe even when the 135851 frame cache is flushed. 135852 1358532022-03-29 Jan Beulich <jbeulich@suse.com> 135854 135855 bfd/Dwarf2: gas doesn't mangle names 135856 Include the language identifier emitted by gas in the set of ones where 135857 no mangled names are expected. Even if there could be "hand-mangled" 135858 names, gas doesn't emit DW_AT_linkage_name in the first place. 135859 135860 bfd/Dwarf2: make find-nearest-line returned function name consistent 135861 Prior to entering the enclosing "else if()" the earlier associated if() 135862 checks function->is_linkage and, if set, uses function->name. The 135863 comment in patch context precedes (and explains) the setting 135864 function->is_linkage. Yet with the flag set, we should then also return 135865 the function name, just like said earlier if() would do when we came 135866 here a 2nd time for the same "addr". And indeed passing the same address 135867 twice on addr2line's command line would resolve the function for the 2nd 135868 instance, but not for the 1st (if this code path is taken). (This, 135869 obviously, is particularly relevant when there's no ELF symbol table in 135870 the first place, like would be the case - naturally - in PE/COFF 135871 binaries, for example.) 135872 135873 gas/Dwarf: special-case .linefile only for macros 135874 Restrict the PR gas/16908 workaround to just macros, matching the 135875 original intention as well as the comment there. For constructs like 135876 .irp or .rept the reasoning doesn't apply, as there's no separate 135877 "invocation" point which may be of interest to record (for, as said 135878 there, short macros). 135879 1358802022-03-29 Jan Beulich <jbeulich@suse.com> 135881 135882 RISC-V: correct FCVT.Q.L[U] 135883 While the spec isn't explicit about this, it pointing out the similarity 135884 with the D extension ought to extend to the ignoring of a meaningless 135885 rounding mode: "Note FCVT.D.W[U] always produces an exact result and is 135886 unaffected by rounding mode." Hence the chosen encodings also ought to 135887 match. 135888 135889 Note that to avoid breaking existing code the forms with a 3rd operand 135890 are not removed, which means there continues to be a difference to 135891 FCVT.D.W[U]. 135892 1358932022-03-29 Mike Frysinger <vapier@gentoo.org> 135894 135895 sim: add arch/.gdbinit stub scripts 135896 Make it easy to load the common gdbinit script even when running in 135897 the arch/ subdir instead of the top-level sim dir. 135898 1358992022-03-29 Alan Modra <amodra@gmail.com> 135900 135901 asan: heap buffer overflow in pa_chk_field_selector 135902 The buffer overflow showed up running the gas "all macro" test. 135903 135904 PR 29005 135905 * config/tc-hppa.c (pa_chk_field_selector): Don't read past end 135906 of line. 135907 1359082022-03-29 GDB Administrator <gdbadmin@sourceware.org> 135909 135910 Automatic date update in version.in 135911 1359122022-03-28 Tom Tromey <tom@tromey.com> 135913 135914 Add Rust parser check for end of expression 135915 I noticed that "print 5," passed in Rust -- the parser wasn't checking 135916 that the entire input was used. This patch fixes the problem. This 135917 in turn pointed out another bug in the parser, namely that it didn't 135918 lex the next token after handling a string token. This is also fixed 135919 here. 135920 1359212022-03-28 Tom Tromey <tom@tromey.com> 135922 135923 Switch gdb_stdlog to use timestamped_file 135924 Currently, timestamps for logging are done by looking for the use of 135925 gdb_stdlog in vfprintf_unfiltered. This seems potentially buggy, in 135926 that during logging or other redirects (like execute_fn_to_ui_file) we 135927 might have gdb_stdout==gdb_stdlog and so, conceivably, wind up with 135928 timestamps in a log when they were not desired. 135929 135930 It seems better, instead, for timestamps to be a property of the 135931 ui_file itself. 135932 135933 This patch changes gdb to use the new timestamped_file for gdb_stdlog 135934 where appropriate, and removes the special case from 135935 vfprintf_unfiltered. 135936 135937 Note that this may somewhat change the output in some cases -- in 135938 particular, when going through execute_fn_to_ui_file (or the _string 135939 variant), timestamps won't be emitted. This could be fixed in those 135940 functions, but it wasn't clear to me whether this is really desirable. 135941 135942 Note also that this changes the TUI to send gdb_stdlog to gdb_stderr. 135943 I imagine that the previous use of gdb_stdout here was inadvertent. 135944 (And in any case it probably doesn't matter.) 135945 1359462022-03-28 Tom Tromey <tom@tromey.com> 135947 135948 Add new timestamped_file class 135949 This adds a "timestamped_file" subclass of ui_file. This class adds a 135950 timestamp to its output when appropriate. That is, it follows the 135951 rule already used in vfprintf_unfiltered of adding a timestamp at most 135952 once per write. 135953 135954 The new class is not yet used. 135955 1359562022-03-28 Tom Tromey <tom@tromey.com> 135957 135958 Use unique_ptr in CLI logging code 135959 This changes the CLI logging code to avoid manual memory management 135960 (to the extent possible) by using unique_ptr in a couple of spots. 135961 This will come in handy in a later patch. 135962 1359632022-03-28 Tom Tromey <tom@tromey.com> 135964 135965 Simplify the CLI set_logging logic 135966 The CLI's set_logging logic seemed unnecessarily complicated to me. 135967 This patch simplifies it, with an eye toward changing it to use RAII 135968 objects in a subsequent patch. 135969 135970 I did not touch the corresponding MI code. That code seems incorrect 135971 (nothing ever uses raw_stdlog, and nothing ever sets 135972 saved_raw_stdlog). I didn't attempt to fix this, because I question 135973 whether this is even useful for MI. 135974 1359752022-03-28 Tom Tromey <tromey@adacore.com> 135976 135977 Handle multiple addresses in call_site_target 135978 A large customer program has a function that is partitioned into hot 135979 and cold parts. A variable in a callee of this function is described 135980 using DW_OP_GNU_entry_value, but gdb gets confused when trying to find 135981 the caller. I tracked this down to dwarf2_get_pc_bounds interpreting 135982 the function's changes so that the returned low PC is the "wrong" 135983 function. 135984 135985 Intead, when processing DW_TAG_call_site, the low PC of each range in 135986 DW_AT_ranges should be preserved in the call_site_target. This fixes 135987 the variable lookup in the test case I have. 135988 135989 I didn't write a standalone test for this as it seemed excessively 135990 complicated. 135991 1359922022-03-28 Tom Tromey <tromey@adacore.com> 135993 135994 Change call_site_target to iterate over addresses 135995 In order to handle the case where a call site target might refer to 135996 multiple addresses, we change the code to use a callback style. Any 135997 spot using call_site_target::address now passes in a callback function 135998 that may be called multiple times. 135999 1360002022-03-28 Tom Tromey <tromey@adacore.com> 136001 136002 Change call_site_find_chain_1 to work recursively 136003 call_site_find_chain_1 has a comment claiming that recursive calls 136004 would be too expensive. However, I doubt this is so expensive; and 136005 furthermore the explicit state management approach here is difficult 136006 both to understand and to modify. This patch changes this code to use 136007 explicit recursion, so that a subsequent patch can generalize this 136008 code without undue trauma. 136009 136010 Additionally, I think this patch detects a latent bug in the recursion 136011 code. (It's hard for me to be completely certain.) The bug is that 136012 when a new target_call_site is entered, the code does: 136013 136014 if (target_call_site) 136015 { 136016 if (addr_hash.insert (target_call_site->pc ()).second) 136017 { 136018 /* Successfully entered TARGET_CALL_SITE. */ 136019 136020 chain.push_back (target_call_site); 136021 break; 136022 } 136023 } 136024 136025 Here, if entering the target_call_site fails, then any tail_call_next 136026 elements in this call site are not visited. However, if this code 136027 does happen to enter a call site, then the tail_call_next elements 136028 will be visited during backtracking. This applies when doing the 136029 backtracking as well -- it will only continue through a given chain as 136030 long as each element in the chain can successfully be visited. 136031 136032 I'd appreciate some review of this. If this behavior is intentional, 136033 it can be added to the new implementation. 136034 1360352022-03-28 Tom Tromey <tromey@adacore.com> 136036 136037 Constify chain_candidate 136038 While investigating this bug, I wasn't sure if chain_candidate might 136039 update 'chain'. I changed it to accept a const reference, making it 136040 clear that it cannot. This simplifies the code a tiny bit as well. 136041 136042 Make call_site_target members private 136043 This makes the data members of call_site_target 'private'. This lets 136044 us remove most of its public API. call_site_to_target_addr is changed 136045 to be a method of this type. This is a preparatory refactoring for 136046 the fix at the end of this series. 136047 136048 Change call_site_target to use custom type and enum 136049 call_site_target reuses field_loc_kind and field_location. However, 136050 it has never used the full range of the field_loc_kind enum. In a 136051 subsequent patch, I plan to add a new 'kind' here, so it seemed best 136052 to avoid this reuse and instead introduce new types here. 136053 1360542022-03-28 GDB Administrator <gdbadmin@sourceware.org> 136055 136056 Automatic date update in version.in 136057 1360582022-03-27 GDB Administrator <gdbadmin@sourceware.org> 136059 136060 Automatic date update in version.in 136061 1360622022-03-26 Tom Tromey <tom@tromey.com> 136063 136064 Remove an unused declaration from value.h 136065 value.h has a declaration of value_print_array_elements that is 136066 incorrect. In C, this would have been an error, but in C++ this is a 136067 declaration of an overload that is neither defined nor used. This 136068 patch removes the declaration. 136069 1360702022-03-26 GDB Administrator <gdbadmin@sourceware.org> 136071 136072 Automatic date update in version.in 136073 1360742022-03-25 Nick Alcock <nick.alcock@oracle.com> 136075 136076 libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case 136077 My previous nm patch handled all cases but one -- if the user set NM in 136078 the environment to a path which contained an option, libtool's nm 136079 detection tries to run nm against a copy of nm with the options in it: 136080 e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the 136081 test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". 136082 This is unlikely to be desirable: in this case we should run 136083 "/usr/bin/nm --blargle /usr/bin/nm". 136084 136085 Furthermore, as part of this nm has to detect when the passed-in $NM 136086 contains a path, and in that case avoid doing a path search itself. 136087 This too was thrown off if an option contained something that looked 136088 like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run 136089 "nm -B../prev-gcc nm" which rarely works well (and indeed it looks 136090 to see whether that nm exists, finds it doesn't, and wrongly concludes 136091 that nm -p or whatever does not work). 136092 136093 Fix all of these by clipping all options (defined as everything 136094 including and after the first " -") before deciding whether nm 136095 contains a path (but not using the clipped value for anything else), 136096 and then removing all options from the path-modified nm before 136097 looking to see whether that nm existed. 136098 136099 NM=my-nm now does a path search and runs e.g. 136100 /usr/bin/my-nm -B /usr/bin/my-nm 136101 136102 NM=/usr/bin/my-nm now avoids a path search and runs e.g. 136103 /usr/bin/my-nm -B /usr/bin/my-nm 136104 136105 NM="my-nm -p../wombat" now does a path search and runs e.g. 136106 /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm 136107 136108 NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: 136109 ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm 136110 136111 This seems to be all combinations, including those used by GCC bootstrap 136112 (which, before this commit, fails to bootstrap when configured 136113 --with-build-config=bootstrap-lto, because the lto plugin is now using 136114 --export-symbols-regex, which requires libtool to find a working nm, 136115 while also using -B../prev-gcc to point at the lto plugin associated 136116 with the GCC just built.) 136117 136118 Regenerate all affected configure scripts. 136119 136120 * libtool.m4 (LT_PATH_NM): Handle user-specified NM with 136121 options, including options containing paths. 136122 1361232022-03-25 Alan Modra <amodra@gmail.com> 136124 136125 Re: gas/Dwarf: improve debug info generation from .irp and alike blocks 136126 am33_2.0-linux is a mn10300 target. 136127 136128 * testsuite/gas/elf/dwarf-5-irp.d: xfail am33. 136129 1361302022-03-25 GDB Administrator <gdbadmin@sourceware.org> 136131 136132 Automatic date update in version.in 136133 1361342022-03-24 Aaron Merey <amerey@redhat.com> 136135 136136 Remove download size from debuginfod progress messages if unavailable 136137 Currently debuginfod progress update messages include the size of 136138 each download: 136139 136140 Downloading 7.5 MB separate debug info for /lib/libxyz.so.0 136141 136142 This value originates from the Content-Length HTTP header of the 136143 transfer. However this header is not guaranteed to be present for 136144 each download. This can happen when debuginfod servers compress files 136145 on-the-fly at the time of transfer. In this case gdb wrongly prints 136146 "-0.00 MB" as the size. 136147 136148 This patch removes download sizes from progress messages when they are 136149 not available. It also removes usage of the progress bar until 136150 a more thorough reworking of progress updating is implemented. [1] 136151 136152 [1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html 136153 1361542022-03-24 Reuben Thomas <rrt@sc3d.org> 136155 136156 sim: fix a comment typo in sim-load.c 136157 Fix a typo where the documentation refers to a function parameter by the 136158 wrong name. 136159 136160 Change-Id: I99494efe62cd4aa76fb78a0bd5da438d35740ebe 136161 1361622022-03-24 Reuben Thomas <rrt@sc3d.org> 136163 136164 sim: fix “alligned” typos 136165 Change-Id: Ifd574e38524dd4f1cf0fc003e0c5c7499abc84a0 136166 1361672022-03-24 Jan Beulich <jbeulich@suse.com> 136168 136169 x86: mention dropped L1OM/K1OM support in ld/ as well 136170 This amends e961c696dcb2 ("x86: drop L1OM/K1OM support from ld"). Also 136171 remove the marker that I mistakenly added in c085ab00c7b2 ("x86: drop 136172 L1OM/K1OM support from gas"). 136173 1361742022-03-24 Simon Marchi <simon.marchi@efficios.com> 136175 136176 gdb/testsuite: remove gdb.python/pretty-print-call-by-hand.exp 136177 This test was added without a corresponding fix, with some setup_kfails. 136178 However, it results in UNRESOLVED results when GDB is built with ASan. 136179 136180 ERROR: GDB process no longer exists 136181 GDB process exited with wait status 1946871 exp7 0 1 136182 UNRESOLVED: gdb.python/pretty-print-call-by-hand.exp: frame print: backtrace test (PRMS gdb/28856) 136183 136184 Remove the test from the tree, I'll attach it to the Bugzilla bug 136185 instead [1]. 136186 136187 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28856 136188 136189 Change-Id: Id95d8949fb8742874bd12aeac758aa4d7564d678 136190 1361912022-03-24 Jan Beulich <jbeulich@suse.com> 136192 136193 x86: drop L1OM/K1OM support from ld 136194 This was only rudimentary support anyway; none of the sub-architecture 136195 specific insns were ever supported. 136196 136197 x86: drop L1OM special case from disassembler 136198 There wasn't any real support anyway: None of the sub-architecture 136199 specific insns were ever supported. 136200 1362012022-03-24 Jan Beulich <jbeulich@suse.com> 136202 136203 MAINTAINERS: add myself 136204 I much appreciate Nick offering this role to me. Nevertheless there's 136205 still a lot for me to learn here. 136206 136207 At this occasion also update my email address in the pre-existing, much 136208 more narrow entry. 136209 1362102022-03-24 GDB Administrator <gdbadmin@sourceware.org> 136211 136212 Automatic date update in version.in 136213 1362142022-03-23 Andrew Burgess <aburgess@redhat.com> 136215 136216 gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp 136217 The gdb.mi/mi-multi-commands.exp test was added in commit: 136218 136219 commit d08cbc5d3203118da5583296e49273cf82378042 136220 Date: Wed Dec 22 12:57:44 2021 +0000 136221 136222 gdb: unbuffer all input streams when not using readline 136223 136224 And then tweaked in commit: 136225 136226 commit 144459531dd68a1287905079aaa131b777a8cc82 136227 Date: Mon Feb 7 20:35:58 2022 +0000 136228 136229 gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test 136230 136231 The second of these commits was intended to address periodic test 136232 failures that I was seeing, and this change did fix some problems, 136233 but, unfortunately, introduced other issues. 136234 136235 The problem is that the test relies on sending two commands to GDB in 136236 a single write. As the characters that make these two commands arrive 136237 they are echoed to GDB's console. However, there is a race between 136238 how quickly the characters are echoed and how quickly GDB decides to 136239 act on the incoming commands. 136240 136241 Usually, both commands are echoed in full before GDB acts on the first 136242 command, but sometimes this is not the case, and GDB can execute the 136243 first command before both commands are fully echoed to the console. 136244 In this case, the output of the first command will be mixed in with 136245 the echoing of the second command. 136246 136247 This mixing of the command echoing and the first command output is 136248 what was causing failures in the original version of the test. 136249 136250 The second commit relaxed the expected output pattern a little, but 136251 was still susceptible to failures, so this commit further relaxes the 136252 pattern. 136253 136254 Now, we look for the first command output with no regard to what is 136255 before, or after the command. Then we look for the first mi prompt to 136256 indicate that the first command has completed. 136257 136258 I believe that this change should make the test more stable than it 136259 was before. 136260 1362612022-03-23 Nick Alcock <nick.alcock@oracle.com> 136262 136263 libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging option 136264 libctf has always handled endianness differences by detecting 136265 foreign-endian CTF dicts on the input and endian-flipping them: dicts 136266 are always written in native endianness. This makes endian-awareness 136267 very low overhead, but it means that the foreign-endian code paths 136268 almost never get routinely tested, since "make check" usually reads in 136269 dicts ld has just written out: only a few corrupted-CTF tests are 136270 actually in fixed endianness, and even they only test the foreign- 136271 endian code paths when you run make check on a big-endian machine. 136272 (And the fix is surely not to add more .s-based tests like that, because 136273 they are a nightmare to maintain compared to the C-code-based ones.) 136274 136275 To improve on this, add a new environment variable, 136276 LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally 136277 endian-flip at ctf_write time, so the output is always in the wrong 136278 endianness. This then tests the foreign-endian read paths properly 136279 at open time. 136280 136281 Make this easier by restructuring the writeout code in ctf-serialize.c, 136282 which duplicates the maybe-gzip-and-write-out code three times (once 136283 for ctf_write_mem, with thresholding, and once each for 136284 ctf_compress_write and ctf_write just so those can avoid thresholding 136285 and/or compression). Instead, have the latter two call the former 136286 with thresholds of 0 or (size_t) -1, respectively. 136287 136288 The endian-flipping code itself gains a bit of complexity, because 136289 one single endian-flipper (flip_types) was assuming the input to be 136290 in foreign-endian form and assuming it could pull things out of the 136291 input once they had been flipped and make sense of them. At the 136292 cost of a few lines of duplicated initializations, teach it to 136293 read before flipping if we're flipping to foreign-endianness instead 136294 of away from it. 136295 136296 libctf/ 136297 * ctf-impl.h (ctf_flip_header): No longer static. 136298 (ctf_flip): Likewise. 136299 * ctf-open.c (flip_header): Rename to... 136300 (ctf_flip_header): ... this, now it is not private to one file. 136301 (flip_ctf): Rename... 136302 (ctf_flip): ... this too. Add FOREIGN_ENDIAN arg. 136303 (flip_types): Likewise. Use it. 136304 (ctf_bufopen_internal): Adjust calls. 136305 * ctf-serialize.c (ctf_write_mem): Add flip_endian path via 136306 a newly-allocated bounce buffer. 136307 (ctf_compress_write): Move below ctf_write_mem and reimplement 136308 in terms of it. 136309 (ctf_write): Likewise. 136310 (ctf_gzwrite): Note that this obscure writeout function does not 136311 support endian-flipping. 136312 1363132022-03-23 Nick Alcock <nick.alcock@oracle.com> 136314 136315 libctf, ld: diagnose corrupted CTF header cth_strlen 136316 The last section in a CTF dict is the string table, at an offset 136317 represented by the cth_stroff header field. Its length is recorded in 136318 the next field, cth_strlen, and the two added together are taken as the 136319 size of the CTF dict. Upon opening a dict, we check that none of the 136320 header offsets exceed this size, and we check when uncompressing a 136321 compressed dict that the result of the uncompression is the same length: 136322 but CTF dicts need not be compressed, and short ones are not. 136323 Uncompressed dicts just use the ctf_size without checking it. This 136324 field is thankfully almost unused: it is mostly used when reserializing 136325 a dict, which can't be done to dicts read off disk since they're 136326 read-only. 136327 136328 However, when opening an uncompressed foreign-endian dict we have to 136329 copy it out of the mmaped region it is stored in so we can endian- 136330 swap it, and we use ctf_size when doing that. When the cth_strlen is 136331 corrupt, this can overrun. 136332 136333 Fix this by checking the ctf_size in all uncompressed cases, just as we 136334 already do in the compressed case. Add a new test. 136335 136336 This came to light because various corrupted-CTF raw-asm tests had an 136337 incorrect cth_strlen: fix all of them so they produce the expected 136338 error again. 136339 136340 libctf/ 136341 PR libctf/28933 136342 * ctf-open.c (ctf_bufopen_internal): Always check uncompressed 136343 CTF dict sizes against the section size in case the cth_strlen is 136344 corrupt. 136345 136346 ld/ 136347 PR libctf/28933 136348 * testsuite/ld-ctf/diag-strlen-invalid.*: New test, 136349 derived from diag-cttname-invalid.s. 136350 * testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen. 136351 * testsuite/ld-ctf/diag-cttname-null.s: Likewise. 136352 * testsuite/ld-ctf/diag-cuname.s: Likewise. 136353 * testsuite/ld-ctf/diag-parlabel.s: Likewise. 136354 * testsuite/ld-ctf/diag-parname.s: Likewise. 136355 1363562022-03-23 Nick Alcock <nick.alcock@oracle.com> 136357 136358 include, libctf, ld: extend variable section to contain functions too 136359 The CTF variable section is an optional (usually-not-present) section in 136360 the CTF dict which contains name -> type mappings corresponding to data 136361 symbols that are present in the linker input but not in the output 136362 symbol table: the idea is that programs that use their own symbol- 136363 resolution mechanisms can use this section to look up the types of 136364 symbols they have found using their own mechanism. 136365 136366 Because these removed symbols (mostly static variables, functions, etc) 136367 all have names that are unlikely to appear in the ELF symtab and because 136368 very few programs have their own symbol-resolution mechanisms, a special 136369 linker flag (--ctf-variables) is needed to emit this section. 136370 136371 Historically, we emitted only removed data symbols into the variable 136372 section. This seemed to make sense at the time, but in hindsight it 136373 really doesn't: functions are symbols too, and a C program can look them 136374 up just like any other type. So extend the variable section so that it 136375 contains all static function symbols too (if it is emitted at all), with 136376 types of kind CTF_K_FUNCTION. 136377 136378 This is a little fiddly. We relied on compiler assistance for data 136379 symbols: the compiler simply emits all data symbols twice, once into the 136380 symtypetab as an indexed symbol and once into the variable section. 136381 136382 Rather than wait for a suitably adjusted compiler that does the same for 136383 function symbols, we can pluck unreported function symbols out of the 136384 symtab and add them to the variable section ourselves. While we're at 136385 it, we do the same with data symbols: this is redundant right now 136386 because the compiler does it, but it costs very little time and lets the 136387 compiler drop this kludge and save a little space in .o files. 136388 136389 include/ 136390 * ctf.h: Mention the new things we can see in the variable 136391 section. 136392 136393 ld/ 136394 * testsuite/ld-ctf/data-func-conflicted-vars.d: New test. 136395 136396 libctf/ 136397 * ctf-link.c (ctf_link_deduplicating_variables): Duplicate 136398 symbols into the variable section too. 136399 * ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename 136400 to... 136401 (symtypetab_delete_nonstatics): ... this. Check the funchash 136402 when pruning redundant variables. 136403 (ctf_symtypetab_sect_sizes): Adjust accordingly. 136404 * NEWS: Describe this change. 136405 1364062022-03-23 Nick Alcock <nick.alcock@oracle.com> 136407 136408 ld, testsuite: improve CTF-availability test 136409 The test for -gctf support in the compiler is used to determine when to 136410 run the ld-ctf tests and most of those in libctf. Unfortunately, 136411 because it uses check_compiler_available and compile_one_cc, it will 136412 fail whenever the compiler emits anything on stderr, even if it 136413 actually does support CTF perfectly well. 136414 136415 So, instead, ask the compiler to emit assembler output and grep it for 136416 references to ".ctf": this is highly unlikely to be present if the 136417 compiler does not support CTF. (This will need adjusting when CTF grows 136418 support for non-ELF platforms that don't dot-prepend their section 136419 names, but right now the linker doesn't link CTF on any such platforms 136420 in any case.) 136421 136422 With this in place we can do things like run all the libctf tests under 136423 leak sanitizers etc even if those spray warnings on simple CTF 136424 compilations, rather than being blocked from doing so just when we would 136425 most like to. 136426 136427 ld/ 136428 * testsuite/lib/ld-lib.exp (check_ctf_available): detect CTF 136429 even if a CTF-capable compiler emits warnings. 136430 1364312022-03-23 Simon Marchi <simon.marchi@efficios.com> 136432 136433 gdb/python: remove Python 2/3 compatibility macros 136434 New in this version: 136435 136436 - Rebase on master, fix a few more issues that appeared. 136437 136438 python-internal.h contains a number of macros that helped make the code 136439 work with both Python 2 and 3. Remove them and adjust the code to use 136440 the Python 3 functions. 136441 136442 Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d 136443 1364442022-03-23 Simon Marchi <simon.marchi@polymtl.ca> 136445 136446 gdb/python: remove Python 2 support 136447 New in this version: 136448 136449 - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If 136450 the user passes --with-python=python2, this will cause a configure 136451 failure saying that GDB only supports Python 3. 136452 136453 Support for Python 2 is a maintenance burden for any patches touching 136454 Python support. Among others, the differences between Python 2 and 3 136455 string and integer types are subtle. It requires a lot of effort and 136456 thinking to get something that behaves correctly on both. And that's if 136457 the author and reviewer of the patch even remember to test with Python 136458 2. 136459 136460 See this thread for an example: 136461 136462 https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html 136463 136464 So, remove Python 2 support. Update the documentation to state that GDB 136465 can be built against Python 3 (as opposed to Python 2 or 3). 136466 136467 Update all the spots that use: 136468 136469 - sys.version_info 136470 - IS_PY3K 136471 - PY_MAJOR_VERSION 136472 - gdb_py_is_py3k 136473 136474 ... to only keep the Python 3 portions and drop the use of some 136475 now-removed compatibility macros. 136476 136477 I did not update the configure script more than just removing the 136478 explicit references to Python 2. We could maybe do more there, like 136479 check the Python version and reject it if that version is not 136480 supported. Otherwise (with this patch), things will only fail at 136481 compile time, so it won't really be clear to the user that they are 136482 trying to use an unsupported Python version. But I'm a bit lost in the 136483 configure code that checks for Python, so I kept that for later. 136484 136485 Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62 136486 1364872022-03-23 Jan Beulich <jbeulich@suse.com> 136488 136489 x86: reject relocations involving registers 136490 To prevent fatal or even internal errors, add a simple check to 136491 i386_validate_fix(), rejecting relocations when their target symbol is 136492 an equate of a register (or resolved to reg_section for any other 136493 reason). 136494 136495 x86: improve resolution of register equates 136496 Allow transitive (or recursive) equates to work in addition to direct 136497 ones. The only requirements are that 136498 - the equate being straight of a register, i.e. no expressions involved 136499 (albeit I'm afraid something like "%eax + 0" will be viewed as %eax), 136500 - at the point of use there's no forward ref left which cannot be 136501 resolved, yet. 136502 136503 Revert "PR28977 tc-i386.c internal error in parse_register" 136504 This reverts commit 5fac3f02edacfca458f7eeaaaa33a87e26e0e332, 136505 which was superceeded / replaced by 4faaa10f3fab. 136506 1365072022-03-23 Jan Beulich <jbeulich@suse.com> 136508 136509 x86: don't attempt to resolve equates and alike from i386_parse_name() 136510 PR gas/28977 136511 136512 Perhaps right from its introduction in 4d1bb7955a8b it was wrong for 136513 i386_parse_name() to call parse_register(). This being a hook from the 136514 expression parser, it shouldn't be resolving e.g. equated symbols. 136515 That's relevant only for all other callers of parse_register(). 136516 136517 To compensate, in Intel syntax mode check_register() needs calling; 136518 perhaps not doing so was an oversight right when the function was 136519 introduced. This is necessary in particular to force EVEX encoding when 136520 VRex registers are used (but of course also to reject bad uses of 136521 registers, i.e. fully matching what parse_register() needs it for). 136522 1365232022-03-23 Luis Machado <luis.machado@arm.com> 136524 136525 Update the list of recognized m-profile TAG_CPU_ARCH_* 136526 Check 3 additional variants previously not recognized: 136527 136528 - TAG_CPU_ARCH_V7E_M 136529 - TAG_CPU_ARCH_V8M_BASE 136530 - TAG_CPU_ARCH_V8M_MAIN 136531 1365322022-03-23 Jan Beulich <jbeulich@suse.com> 136533 136534 gas/Dwarf5: re-use file 0 line string table entry when faking file 0 136535 No need to emit the same string a 2nd time for file 1 in this case. 136536 136537 gas/Dwarf5: adjust .debug_line file 0 checking 136538 First of all when a table entry has a NULL filename, the two inner if()s 136539 are better done the other way around: The 2nd doesn't depend on what the 136540 first does. This then renders redundant half of the conditions of the 136541 other if() and clarifies that subsequently only entry 0 is dealt with 136542 (indicating that part of the comment was wrong). Finally for there to be 136543 a usable name in slot 1, files_in_use needs to be larger than 1 and slot 136544 1's (rather than slot 0's) name needs to be non-NULL. 136545 1365462022-03-23 Jan Beulich <jbeulich@suse.com> 136547 136548 gas/Dwarf5: drop dead code 136549 Commit 3417bfca676f ("GAS: DWARF-5: Ensure that the 0'th entry in the 136550 directory table contains the current... ") added a "dwarf_level < 5" 136551 check to out_dir_and_file_list(). This rendered dead that branch of the 136552 construct, due to the enclosing if()'s "DWARF2_LINE_VERSION >= 5". 136553 Delete that code as well as the corresponding part of the comment. 136554 136555 While there also drop a redundant "dirs != NULL": "dirs" will always be 136556 non-NULL when dirs_in_use is not zero. 136557 1365582022-03-23 Jan Beulich <jbeulich@suse.com> 136559 136560 gas/Dwarf: improve debug info generation from .irp and alike blocks 136561 Tying the bumping of the logical line number to reading from the 136562 original source file looks wrong: Upon finishing of the processing of an 136563 sb the original values will be restored anyway. Yet without bumping the 136564 line counter uses of .line inside e.g. an .irp construct won't have the 136565 intended effect: Such uses may be necessary to ensure proper debug info 136566 is emitted in particular when switching sections inside the .irp body, 136567 as dwarf2_gen_line_info() would bail without doing anything when it 136568 finds the line number unchanged from what it saw last. 136569 1365702022-03-23 Jan Beulich <jbeulich@suse.com> 136571 136572 ELF32: don't silently truncate relocation addends 136573 At least x86-64's x32 sub-mode and RISC-V's 32-bit mode calculate 136574 addends as 64-bit values, but store them in signed 32-bit fields when 136575 generating the file without encountering any earlier error. When the 136576 relocated field is a 64-bit one, the value resulting after processing 136577 the relocation record when linking (or the latest when loading) may 136578 thus be wrong due to the truncation. 136579 136580 With the code change in place, one x32 testcase actually triggers the 136581 new diagnostic. That one case of too large a (negative) addend is being 136582 adjusted alongside the addition of a new testcase to actually trigger 136583 the new error. (Note that due to internal BFD behavior the relocation in 136584 .data doesn't get processed anymore after the errors in .text.) 136585 136586 Note that in principle it is possible to express 64-bit relocations in 136587 ELF32, but this would require .rel relocations, i.e. with the addend 136588 stored in the 64-bit field being relocated. But I guess it would be a 136589 lot of effort for little gain to actually support this. 136590 1365912022-03-23 Jan Beulich <jbeulich@suse.com> 136592 136593 gas: retain whitespace between strings 136594 Macro arguments may be separated by commas or just whitespace. Macro 136595 arguments may also be quoted (where one level of quotes is removed in 136596 the course of determining the values for the respective formal 136597 parameters). Furthermore this quote removal knows _two_ somewhat odd 136598 escaping mechanisms: One, apparently in existence forever, is that a 136599 pair of quotes counts as the escaping of a quote, with the pair being 136600 transformed to a single quote in the course of quote removal. The other 136601 (introduced by c06ae4f232e6) looks more usual on the surface in that it 136602 deals with \" sequences, but it _retains_ the escaping \. Hence only the 136603 former mechanism is suitable when the value to be used by the macro body 136604 is to contain a quote. Yet this results in ambiguity of what "a""b" is 136605 intended to mean; elsewhere (e.g. for .ascii) it represents two 136606 successive string literals. However, in any event is the above different 136607 from "a" "b": I don't think this can be viewed the same as "a""b" when 136608 processing macro arguments. 136609 136610 Change the scrubber to retain such whitespace, by making the processing 136611 of strings more similar to that of symbols. And indeed this appears to 136612 make sense when taking into account that for quite a while gas has been 136613 supporting quoted symbol names. 136614 136615 Taking a more general view, however, the change doesn't go quite far 136616 enough. There are further cases where significant whitespace is removed 136617 by the scrubber. The new testcase enumerates a few in its ".if 0" 136618 section. I'm afraid the only way that I see to deal with this would be 136619 to significantly simplify the scrubber, such that it wouldn't do much 136620 more than collapse sequences of unquoted whitespace into a single blank. 136621 To be honest problems in this area aren't really surprising when seeing 136622 that there's hardly any checking of .macro use throughout the testsuite 136623 (and in particular in the [relatively] generic tests under all/). 136624 1366252022-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 136626 136627 Only .so files are used in libcollector. Remove the other files. 136628 * libcollector/Makefile.am (install-data-local): Remove the *.la 136629 and *.a libraries. 136630 * libcollector/Makefile.in: Regenerate. 136631 1366322022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn> 136633 136634 gdb: testsuite: use gdb_attach to fix jit-elf.exp 136635 If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following 136636 command without superuser: 136637 136638 make check-gdb TESTS="gdb.base/jit-elf.exp" 136639 136640 we can see the following messages in gdb/testsuite/gdb.log: 136641 136642 (gdb) attach 1650108 136643 Attaching to program: /home/yangtiezhu/build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 1650108 136644 ptrace: Operation not permitted. 136645 (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach 136646 136647 use gdb_attach to fix the above issue, at the same time, the clean_reattach 136648 proc should return a value to indicate whether it worked, and the callers 136649 should return early as well on failure. 136650 1366512022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn> 136652 136653 gdb: testsuite: use gdb_attach to fix attach-pie-noexec.exp 136654 If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following 136655 command without superuser: 136656 136657 make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" 136658 136659 we can see the following messages in gdb/testsuite/gdb.log: 136660 136661 (gdb) attach 6500 136662 Attaching to process 6500 136663 ptrace: Operation not permitted. 136664 (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach 136665 136666 It is obviously wrong, the expected result should be UNSUPPORTED in such 136667 a case. 136668 136669 With this patch, we can see "Operation not permitted" in the log info, 136670 and then we can do the following processes to test: 136671 (1) set ptrace_scope as 0 136672 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope 136673 $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" 136674 (2) use sudo 136675 $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" 136676 1366772022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn> 136678 136679 gdb: testsuite: add new gdb_attach to check "attach" command 136680 This commit adds new gdb_attach to centralize the failure checking of 136681 "attach" command. Return 0 if attach failed, otherwise return 1. 136682 1366832022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn> 136684 136685 gdb: testsuite: remove attach test from can_spawn_for_attach 136686 As Pedro Alves said, caching procs should not issue pass/fail [1], 136687 this commit removes attach test from can_spawn_for_attach, at the 136688 same time, use "verbose -log" instead of "unsupported" to get a 136689 trace about why a test run doesn't support spawning for attach. 136690 136691 [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html 136692 1366932022-03-23 GDB Administrator <gdbadmin@sourceware.org> 136694 136695 Automatic date update in version.in 136696 1366972022-03-22 John Baldwin <jhb@FreeBSD.org> 136698 136699 Add support for hardware breakpoints/watchpoints on FreeBSD/Aarch64. 136700 This shares aarch64-nat.c and nat/aarch64-hw-point.c with the Linux 136701 native target. Since FreeBSD writes all of the debug registers in one 136702 ptrace op, use an unordered_set<> to track the "dirty" state for 136703 threads rather than bitmasks of modified registers. 136704 136705 fbsd-nat: Add a low_prepare_to_resume virtual method. 136706 This method can be overridden by architecture-specific targets to 136707 perform additional work before a thread is resumed. 136708 1367092022-03-22 John Baldwin <jhb@FreeBSD.org> 136710 136711 fbsd-nat: Add a low_delete_thread virtual method. 136712 This method can be overridden by architecture-specific targets to 136713 perform additional work when a thread is deleted. 136714 136715 Note that this method is only invoked on systems supporting LWP 136716 events, but the pending use case (aarch64 debug registers) is not 136717 supported on older kernels that do not support LWP events. 136718 1367192022-03-22 John Baldwin <jhb@FreeBSD.org> 136720 136721 fbsd-nat: Add helper routine to fetch siginfo_t for a ptid. 136722 1367232022-03-22 John Baldwin <jhb@FreeBSD.org> 136724 136725 aarch64: Add an aarch64_nat_target mixin class. 136726 This class includes platform-independent target methods for hardware 136727 breakpoints and watchpoints using routines from 136728 nat/aarch64-hw-point.c. 136729 136730 stopped_data_address is not platform-independent since the FAR 136731 register holding the address for a breakpoint hit must be fetched in a 136732 platform-specific manner. However, aarch64_stopped_data_address is 136733 provided as a helper routine which performs platform-independent 136734 validation given the value of the FAR register. 136735 136736 For tracking the per-process debug register mirror state, use an 136737 unordered_map indexed by pid as recently adopted in x86-nat.c rather 136738 than a manual linked-list. 136739 1367402022-03-22 John Baldwin <jhb@FreeBSD.org> 136741 136742 nat: Split out platform-independent aarch64 debug register support. 136743 Move non-Linux-specific support for hardware break/watchpoints from 136744 nat/aarch64-linux-hw-point.c to nat/aarch64-hw-point.c. Changes 136745 beyond a simple split of the code are: 136746 136747 - aarch64_linux_region_ok_for_watchpoint and 136748 aarch64_linux_any_set_debug_regs_state renamed to drop linux_ as 136749 they are not platform specific. 136750 136751 - Platforms must implement the aarch64_notify_debug_reg_change 136752 function which is invoked from the platform-independent code when a 136753 debug register changes for a given debug register state. This does 136754 not use the indirection of a 'low' structure as is done for x86. 136755 136756 - The handling for kernel_supports_any_contiguous_range is not 136757 pristine. For non-Linux it is simply defined to true. Some uses of 136758 this could perhaps be implemented as new 'low' routines for the 136759 various places that check it instead? 136760 136761 - Pass down ptid into aarch64_handle_breakpoint and 136762 aarch64_handle_watchpoint rather than using current_lwp_ptid which 136763 is only defined on Linux. In addition, pass the ptid on to 136764 aarch64_notify_debug_reg_change instead of the unused state 136765 argument. 136766 1367672022-03-22 John Baldwin <jhb@FreeBSD.org> 136768 136769 x86-fbsd-nat: Copy debug register state on fork. 136770 Use the FreeBSD native target low_new_fork hook to copy the 136771 per-process debug state from the parent to the child on fork. 136772 136773 fbsd-nat: Add a low_new_fork virtual method. 136774 This method can be overridden by architecture-specific targets to 136775 perform additional work when a new child process is forked. 136776 1367772022-03-22 John Baldwin <jhb@FreeBSD.org> 136778 136779 Add an x86_fbsd_nat_target mixin class for FreeBSD x86 native targets. 136780 This class implements debug register support common between the i386 136781 and amd64 native targets. 136782 136783 While here, remove #ifdef's for HAVE_PT_GETDBREGS in FreeBSD-specific 136784 code. The ptrace request has been present on FreeBSD x86 136785 architectures since 4.0 (released in March 2000). The last FreeBSD 136786 release without this support is 3.5 released in June 2000. 136787 1367882022-03-22 John Baldwin <jhb@FreeBSD.org> 136789 136790 x86-nat: Add x86_lookup_debug_reg_state. 136791 This function returns nullptr if debug register state does not yet 136792 exist for a given process rather than creating new state. 136793 136794 x86-nat: Use an unordered_map to store per-pid debug reg state. 136795 This replaces a manual linked list which used O(n) lookup and removal. 136796 136797 Remove USE_SIGTRAP_SIGINFO condition for FreeBSD/x86 debug regs support. 136798 For BSD x86 targets, stopped_by_hw_breakpoint doesn't check siginfo_t 136799 but inspects the DR6 register directly via PT_GETDBREGS. 136800 1368012022-03-22 Tom Tromey <tom@tromey.com> 136802 136803 Remove two unused variables 136804 I found a couple of spots that declare a symtab_and_line but don't 136805 actually use it. I think this probably isn't detected as unused 136806 because it has a constructor. 136807 1368082022-03-22 Steiner H Gunderson <steinar+sourceware@gunderson.no> 136809 136810 Fix return code in _bfd_dwarf2_find_nearest_line(). 136811 * dwarf2.c (_bfd_dwarf2_find_nearest_line): if a function name is 136812 found, but no line number info, then return a result of 2. 136813 1368142022-03-22 Andrew Burgess <andrew.burgess@embecosm.com> 136815 136816 gdb/python: add gdb.format_address function 136817 Add a new function, gdb.format_address, which is a wrapper around 136818 GDB's print_address function. 136819 136820 This method takes an address, and returns a string with the format: 136821 136822 ADDRESS <SYMBOL+OFFSET> 136823 136824 Where, ADDRESS is the original address, formatted as hexadecimal, 136825 SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is 136826 the offset from SYMBOL to ADDRESS in decimal. 136827 136828 If there's no SYMBOL suitably close to ADDRESS then the 136829 <SYMBOL+OFFSET> part is not included. 136830 136831 This is useful if a user wants to write a Python script that 136832 pretty-prints addresses, the user no longer needs to do manual symbol 136833 lookup, or worry about correctly formatting addresses. 136834 136835 Additionally, there are some settings that effect how GDB picks 136836 SYMBOL, and whether the file name and line number should be included 136837 with the SYMBOL name, the gdb.format_address function ensures that the 136838 users Python script also benefits from these settings. 136839 136840 The gdb.format_address by default selects SYMBOL from the current 136841 inferiors program space, and address is formatted using the 136842 architecture for the current inferior. However, a user can also 136843 explicitly pass a program space and architecture like this: 136844 136845 gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE) 136846 136847 In order to format an address for a different inferior. 136848 136849 Notes on the implementation: 136850 136851 In py-arch.c I extended arch_object_to_gdbarch to add an assertion for 136852 the type of the PyObject being worked on. Prior to this commit all 136853 uses of arch_object_to_gdbarch were guaranteed to pass this function a 136854 gdb.Architecture object, but, with this commit, this might not be the 136855 case. 136856 136857 So, with this commit I've made it a requirement that the PyObject be a 136858 gdb.Architecture, and this is checked with the assert. And in order 136859 that callers from other files can check if they have a 136860 gdb.Architecture object, I've added the new function 136861 gdbpy_is_architecture. 136862 136863 In py-progspace.c I've added two new function, the first 136864 progspace_object_to_program_space, converts a PyObject of type 136865 gdb.Progspace to the associated program_space pointer, and 136866 gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not. 136867 1368682022-03-22 Luis Machado <luis.machado@arm.com> 136869 136870 Fix some stale header names from dwarf files 136871 Some of these references were not updated when they were moved to a separate 136872 directory. 136873 1368742022-03-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 136875 136876 Install gprofng libraries under $(pkglibdir) 136877 gprofng/ChangeLog 136878 2022-03-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 136879 136880 PR gprofng/28972 136881 * gprofng/libcollector/Makefile.am: Rename lib_LTLIBRARIES to 136882 pkglib_LTLIBRARIES. Add install-data-local. 136883 * gprofng/src/Makefile.am: Likewise. 136884 * gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of 136885 the gprofng libraries. 136886 * gprofng/configure.ac: Removed an unused GPROFNG_LIBDIR. 136887 * gprofng/Makefile.am: Removed an unused GPROFNG_LIBDIR. Add 136888 install-data-local. 136889 * gprofng/configure: Regenerate. 136890 * gprofng/Makefile.in: Likewise. 136891 * gprofng/doc/Makefile.in: Likewise. 136892 * gprofng/gp-display-htmllibcollector/Makefile.in: Likewise. 136893 * gprofng/libcollector/Makefile.in: Likewise. 136894 * gprofng/src/Makefile.in: Likewise. 136895 1368962022-03-22 GDB Administrator <gdbadmin@sourceware.org> 136897 136898 Automatic date update in version.in 136899 1369002022-03-21 Roland McGrath <mcgrathr@google.com> 136901 136902 gdb: Add missing #include in solib.h 136903 The gdb_bfd_ref_ptr type is used in solib.h declarations. 136904 1369052022-03-21 Aaron Merey <amerey@redhat.com> 136906 136907 PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings 136908 Add debuginfod support to core_target::build_file_mappings and 136909 locate_exec_from_corefile_build_id to enable the downloading of 136910 missing executables and shared libraries referenced in core files. 136911 136912 Also add debuginfod support to solib_map_sections so that previously 136913 downloaded shared libraries can be retrieved from the local debuginfod 136914 cache. 136915 136916 When core file shared libraries are found locally, verify that their 136917 build-ids match the corresponding build-ids found in the core file. 136918 If there is a mismatch, attempt to query debuginfod for the correct 136919 build and print a warning if unsuccessful: 136920 136921 warning: Build-id of /lib64/libc.so.6 does not match core file. 136922 136923 Also disable debuginfod when gcore invokes gdb. Debuginfo is not 136924 needed for core file generation so debuginfod queries will slow down 136925 gcore unnecessarily. 136926 1369272022-03-21 Aaron Merey <amerey@redhat.com> 136928 136929 gdb: Add soname to build-id mapping for core files 136930 Since commit aa2d5a422 gdb has been able to read executable and shared 136931 library build-ids within core files. 136932 136933 Expand this functionality so that each core file bfd maintains a map of 136934 soname to build-id for each shared library referenced in the core file. 136935 136936 This feature may be used to verify that gdb has found the correct shared 136937 libraries for core files and to facilitate downloading shared libaries via 136938 debuginfod. 136939 1369402022-03-21 Pedro Alves <pedro@palves.net> 136941 136942 Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621) 136943 If GDB reports a watchpoint hit, and then the next event is not 136944 TARGET_WAITKIND_STOPPED, but instead some event for which there's a 136945 catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly 136946 thinks the watchpoint triggered. Vis, using foll-fork.c: 136947 136948 (gdb) awatch v 136949 Hardware access (read/write) watchpoint 2: v 136950 (gdb) catch fork 136951 Catchpoint 3 (fork) 136952 (gdb) c 136953 Continuing. 136954 136955 Hardware access (read/write) watchpoint 2: v 136956 136957 Old value = 0 136958 New value = 5 136959 main () at gdb.base/foll-fork.c:16 136960 16 pid = fork (); 136961 (gdb) 136962 Continuing. 136963 136964 Hardware access (read/write) watchpoint 2: v <<<< 136965 <<<< these lines are spurious 136966 Value = 5 <<<< 136967 136968 Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49 136969 49 arch-fork.h: No such file or directory. 136970 (gdb) 136971 136972 The problem is that when we handle the fork event, nothing called 136973 watchpoints_triggered before calling bpstat_stop_status. Thus, each 136974 watchpoint's watchpoint_triggered field was still set to 136975 watch_triggered_yes from the previous (real) watchpoint stop. 136976 watchpoint_triggered is only current called in the handle_signal_stop 136977 path, when handling TARGET_WAITKIND_STOPPED. 136978 136979 This fixes it by adding watchpoint_triggered calls in the other events 136980 paths that call bpstat_stop_status. But instead of adding them 136981 explicitly, it adds a new function bpstat_stop_status_nowatch that 136982 wraps bpstat_stop_status and calls watchpoint_triggered, and then 136983 replaces most calls to bpstat_stop_status with calls to 136984 bpstat_stop_status_nowatch. 136985 136986 This required constifying watchpoints_triggered. 136987 136988 New test included, which fails without the fix. 136989 136990 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621 136991 136992 Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c 136993 1369942022-03-21 Pedro Alves <pedro@palves.net> 136995 136996 gdbserver: Fixup previous patch 136997 The previous prepare_resume_reply change missed updating the 'buf' 136998 reference that overwrites the 'T', so if 'buf' was advanced, we'd 136999 still overwrite the wrong character. This fixes it. 137000 137001 Change-Id: Ia8ce433366b85af4e268c1c49e7b447da3130a4d 137002 1370032022-03-21 Pedro Alves <pedro@palves.net> 137004 137005 gdbserver: Fix incorrect assertion 137006 While playing with adding a new event kind, I noticed that 137007 prepare_resume_reply TARGET_WAITKIND_FORKED, etc. advance 'buf', so if 137008 we force-disable the T packet, we'd fail the *buf == 'T' assertion. 137009 137010 Fix it by tweaking the assertion to always look at the beginning of 137011 the buffer. 137012 137013 Change-Id: I8c38e32353db115edcde418b3b1e8ba12343c22b 137014 1370152022-03-21 Simon Marchi <simon.marchi@efficios.com> 137016 137017 gdb: re-generate config.in 137018 I'm getting this diff when running `autoreconf -vf`. 137019 137020 Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d 137021 1370222022-03-21 Andrew Burgess <aburgess@redhat.com> 137023 137024 gdb/x86: handle stap probe arguments in xmm registers 137025 On x86 machines with xmm register, and with recent versions of 137026 systemtap (and gcc?), it can occur that stap probe arguments will be 137027 placed into xmm registers. 137028 137029 I notice this happening on a current Fedora Rawhide install with the 137030 following package versions installed: 137031 137032 $ rpm -q glibc systemtap gcc 137033 glibc-2.35.9000-10.fc37.x86_64 137034 systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64 137035 gcc-12.0.1-0.12.fc37.x86_64 137036 137037 If I check the probe data in libc, I see this: 137038 137039 $ readelf -n /lib64/libc.so.6 137040 ... 137041 stapsdt 0x0000004d NT_STAPSDT (SystemTap probe descriptors) 137042 Provider: libc 137043 Name: pthread_start 137044 Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000 137045 Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx) 137046 stapsdt 0x00000050 NT_STAPSDT (SystemTap probe descriptors) 137047 Provider: libc 137048 Name: pthread_create 137049 Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000 137050 Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp) 137051 ... 137052 137053 Notice that for both of these probes, the first argument is a uint64_t 137054 stored in the xmm1 register. 137055 137056 Unfortunately, if I try to use this probe within GDB, then I can't 137057 view the first argument. Here's an example session: 137058 137059 $ gdb $(which gdb) 137060 (gdb) start 137061 ... 137062 (gdb) info probes stap libc pthread_create 137063 ... 137064 (gdb) break *0x00007ffff729e2f1 # Use address of probe. 137065 (gdb) continue 137066 ... 137067 (gdb) p $_probe_arg0 137068 Invalid cast. 137069 137070 What's going wrong? If I re-run my session, but this time use 'set 137071 debug stap-expression 1', this is what I see: 137072 137073 (gdb) set debug stap-expression 1 137074 (gdb) p $_probe_arg0 137075 Operation: UNOP_CAST 137076 Operation: OP_REGISTER 137077 String: xmm1 137078 Type: uint64_t 137079 Operation: UNOP_CAST 137080 Operation: OP_REGISTER 137081 String: r13 137082 Type: uint64_t 137083 Operation: UNOP_CAST 137084 Operation: UNOP_IND 137085 Operation: UNOP_CAST 137086 Operation: BINOP_ADD 137087 Operation: OP_LONG 137088 Type: long 137089 Constant: 0x0000000000000008 137090 Operation: OP_REGISTER 137091 String: rsp 137092 Type: uint64_t * 137093 Type: uint64_t 137094 Operation: UNOP_CAST 137095 Operation: UNOP_IND 137096 Operation: UNOP_CAST 137097 Operation: BINOP_ADD 137098 Operation: OP_LONG 137099 Type: long 137100 Constant: 0x0000000000000010 137101 Operation: OP_REGISTER 137102 String: rsp 137103 Type: uint64_t * 137104 Type: uint64_t 137105 Invalid cast. 137106 (gdb) 137107 137108 The important bit is this: 137109 137110 Operation: UNOP_CAST 137111 Operation: OP_REGISTER 137112 String: xmm1 137113 Type: uint64_t 137114 137115 Which is where we cast the xmm1 register to uint64_t. And the final 137116 piece of the puzzle is: 137117 137118 (gdb) ptype $xmm1 137119 type = union vec128 { 137120 v8bf16 v8_bfloat16; 137121 v4f v4_float; 137122 v2d v2_double; 137123 v16i8 v16_int8; 137124 v8i16 v8_int16; 137125 v4i32 v4_int32; 137126 v2i64 v2_int64; 137127 uint128_t uint128; 137128 } 137129 137130 So, we are attempting to cast a union type to a scalar type, which is 137131 not supporting in C/C++, and as a consequence GDB's expression 137132 evaluator throws an error when we attempt to do this. 137133 137134 The first approach I considered for solving this problem was to try 137135 and make use of gdbarch_stap_adjust_register. We already have a 137136 gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak 137137 the name of the register that we access. Currently only x86 137138 architectures use this to transform things like ax to eax in some 137139 cases. 137140 137141 I wondered, what if we change gdbarch_stap_adjust_register to do more 137142 than just change the register names? What if this method instead 137143 became gdbarch_stap_read_register. This new method would return a 137144 operation_up, and would take the register name, and the type we are 137145 trying to read from the register, and return the operation that 137146 actually reads the register. 137147 137148 The default implementation of this method would just use 137149 user_reg_map_name_to_regnum, and then create a register_operation, 137150 like we already do in stap_parse_register_operand. But, for x86 137151 architectures this method would fist possibly adjust the register 137152 name, then do the default action to read the register. Finally, for 137153 x86 this method would spot when we were accessing an xmm register, 137154 and, based on the type being pulled from the register, would extract 137155 the correct field from the union. 137156 137157 The benefit of this approach is that it would work with the expression 137158 types that GDB currently supports. The draw back would be that this 137159 approach would not be very generic. We'd need code to handle each 137160 sub-field size with an xmm register. If other architectures started 137161 using vector registers for probe arguments, those architectures would 137162 have to create their own gdbarch_stap_read_register method. And 137163 finally, the type of the xmm registers comes from the type defined in 137164 the target description, there's a risk that GDB might end up 137165 hard-coding the names of type sub-fields, then if a target uses a 137166 different target description, with different field names for xmm 137167 registers, the stap probes would stop working. 137168 137169 And so, based on all the above draw backs, I rejected this first 137170 approach. 137171 137172 My second plan involves adding a new expression type to GDB called 137173 unop_extract_operation. This new expression takes a value and a type, 137174 during evaluation the value contents are fetched, and then a new value 137175 is extracted from the value contents (based on type). This is similar 137176 to the following C expression: 137177 137178 result_value = *((output_type *) &input_value); 137179 137180 Obviously we can't actually build this expression in this case, as the 137181 input_value is in a register, but hopefully the above makes it clearer 137182 what I'm trying to do. 137183 137184 The benefit of the new expression approach is that this code can be 137185 shared across all architectures, and it doesn't care about sub-field 137186 names within the union type. 137187 137188 The draw-backs that I see are potential future problems if arguments 137189 are not stored within the least significant bytes of the register. 137190 However if/when that becomes an issue we can adapt the 137191 gdbarch_stap_read_register approach to allow architectures to control 137192 how a value is extracted. 137193 137194 For testing, I've extended the existing gdb.base/stap-probe.exp test 137195 to include a function that tries to force an argument into an xmm 137196 register. Obviously, that will only work on a x86 target, so I've 137197 guarded the new function with an appropriate GCC define. In the exp 137198 script we use readelf to check if the probe exists, and is using the 137199 xmm register. 137200 137201 If the probe doesn't exist then the associated tests are skipped. 137202 137203 If the probe exists, put isn't using the xmm register (which will 137204 depend on systemtap/gcc versions), then again, the tests are skipped. 137205 137206 Otherwise, we can run the test. I think the cost of running readelf 137207 is pretty low, so I don't feel too bad making all the non-xmm targets 137208 running this step. 137209 137210 I found that on a Fedora 35 install, with these packages installed, I 137211 was able to run this test and have the probe argument be placed in an 137212 xmm register: 137213 137214 $ rpm -q systemtap gcc glibc 137215 systemtap-4.6-4.fc35.x86_64 137216 gcc-11.2.1-9.fc35.x86_64 137217 glibc-2.34-7.fc35.x86_64 137218 137219 Finally, as this patch adds a new operation type, then I need to 137220 consider how to generate an agent expression for the new operation 137221 type. 137222 137223 I have kicked the can down the road a bit on this. In the function 137224 stap_parse_register_operand, I only create a unop_extract_operation in 137225 the case where the register type is non-scalar, this means that in 137226 most cases I don't need to worry about generating an agent expression 137227 at all. 137228 137229 In the xmm register case, when an unop_extract_operation will be 137230 created, I have sketched out how the agent expression could be 137231 handled, however, this code is currently not reached. When we try to 137232 generate the agent expression to place the xmm register on the stack, 137233 GDB hits this error: 137234 137235 (gdb) trace -probe-stap test:xmmreg 137236 Tracepoint 1 at 0x401166 137237 (gdb) actions 137238 Enter actions for tracepoint 1, one per line. 137239 End with a line saying just "end". 137240 >collect $_probe_arg0 137241 Value not scalar: cannot be an rvalue. 137242 137243 This is because GDB doesn't currently support placing non-scalar types 137244 on the agent expression evaluation stack. Solving this is clearly 137245 related to the original problem, but feels a bit like a second 137246 problem. I'd like to get feedback on whether my approach to solving 137247 the original problem is acceptable or not before I start looking at 137248 how to handle xmm registers within agent expressions. 137249 1372502022-03-21 Steiner H Gunderson <steinar+sourceware@gunderson.no> 137251 137252 Reduce O(n2) performance overhead when parsing DWARF unit information. 137253 PR 28978 137254 * dwarf2.c (scan_unit_for_symbols): When performing second pass, 137255 check to see if the function or variable being processed is the 137256 same as the previous one. 137257 1372582022-03-21 Jan Beulich <jbeulich@suse.com> 137259 137260 x86: don't suppress overflow diagnostics in x32 mode 137261 Unlike in 64-bit mode, where values wrap at the 64-bit boundary anyway, 137262 there's no wrapping at the 32-bit boundary here, and hence overflow 137263 detection shouldn't be suppressed just because rela relocations are 137264 going to be used. 137265 137266 The extra check against NO_RELOC is actually a result of an ilp32 test 137267 otherwise failing. But thinking about it, reporting overflows for 137268 not-really-relocations (typically because of earlier errors) makes 137269 little sense in general. Perhaps this should even be extended to non- 137270 64-bit modes. 137271 1372722022-03-21 Simon Marchi <simon.marchi@efficios.com> 137273 137274 gdb/testsuite: reformat gdb.python/pretty-print-call-by-hand.py 137275 Run black on the file. 137276 137277 Change-Id: Ifb576137fb7158a0227173f61c1202f0695b3685 137278 1372792022-03-21 Bruno Larsen <blarsen@redhat.com> 137280 137281 [gdb/testsuite] test a function call by hand from pretty printer 137282 The test case added here is testing the bug gdb/28856, where calling a 137283 function by hand from a pretty printer makes GDB crash. There are 6 137284 mechanisms to trigger this crash in the current test, using the commands 137285 backtrace, up, down, finish, step and continue. Since the failure happens 137286 because of use-after-free (more details below) the tests will always 137287 have a chance of passing through sheer luck, but anecdotally they seem 137288 to fail all of the time. 137289 137290 The reason GDB is crashing is a use-after-free problem. The above 137291 mentioned functions save a pointer to the current frame's information, 137292 then calls the pretty printer, and uses the saved pointer for different 137293 reasons, depending on the function. The issue happens because 137294 call_function_by_hand needs to reset the obstack to get the current 137295 frame, invalidating the saved pointer. 137296 1372972022-03-21 Pedro Alves <pedro@palves.net> 137298 137299 gdb/testsuite: Installed-GDB testing & data-directory 137300 In testsuite/README, we suggest that you can run the testsuite against 137301 some other GDB binary by using: 137302 137303 make check RUNTESTFLAGS=GDB=/usr/bin/gdb 137304 137305 However, that example isn't fully correct, because with that command 137306 line, the testsuite will still pass 137307 137308 -data-directory=[pwd]/../data-directory 137309 137310 to /usr/bin/gdb, like e.g.: 137311 137312 ... 137313 builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0 137314 ... 137315 137316 while if you're testing an installed GDB (the system GDB being the 137317 most usual scenario), then you should normally let it use its own 137318 configured directory, not the just-built GDB's data directory. 137319 137320 This commit improves the status quo with the following two changes: 137321 137322 - if the user specifies GDB on the command line, then by default, 137323 don't start GDB with the -data-directory command line option. 137324 I.e., let the tested GDB use its own configured data directory. 137325 137326 - let the user override the data directory, via a new 137327 GDB_DATA_DIRECTORY global. This replaces the existing 137328 BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which 137329 wasn't overridable, and was a bit misnamed for the new purpose. 137330 137331 So after this, the following commands I believe behave intuitively: 137332 137333 # Test the non-installed GDB in some build dir: 137334 137335 make check \ 137336 RUNTESTFLAGS="GDB=/path/to/other/build/gdb \ 137337 GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory" 137338 137339 # Test the GDB installed in some prefix: 137340 137341 make check \ 137342 RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb" 137343 137344 # Test the built GDB with some alternative data directory, e.g., the 137345 system GDB's data directory: 137346 137347 make check \ 137348 RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb" 137349 137350 Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb 137351 1373522022-03-21 Nick Clifton <nickc@redhat.com> 137353 137354 z80 assembler: Fix new unexpected overflow warning in v2.37 137355 PR 28791 137356 * config/tc-z80.c (emit_data_val): Do not warn about overlarge 137357 constants generated by bit manipulation operators. 137358 * testsuite/gas/z80/pr28791.s: New test source file. 137359 * testsuite/gas/z80/pr28791.d: New test driver file. 137360 1373612022-03-21 Andreas Schwab <schwab@linux-m68k.org> 137362 137363 Add support for readline 8.2 137364 In readline 8.2 the type of rl_completer_word_break_characters changed to 137365 include const. 137366 1373672022-03-21 GDB Administrator <gdbadmin@sourceware.org> 137368 137369 Automatic date update in version.in 137370 1373712022-03-20 Andreas Schwab <schwab@linux-m68k.org> 137372 137373 RISC-V: Fix misplaced @end table 137374 Move the csr-check and arch items inside the table for the .option directive. 137375 1373762022-03-20 Alan Modra <amodra@gmail.com> 137377 137378 PR28979, internal error in demand_empty_rest_of_line 137379 The change in read_a_source_file prevents the particular testcase in 137380 the PR from triggering the assertion in demand_empty_rest_of_line. 137381 I've also removed the assertion. Nothing much goes wrong with gas if 137382 something else triggers it, so it's not worthy of an abort. 137383 137384 I've also changed my previous patch to ignore_rest_of_line to allow 137385 that function to increment input_line_pointer past buffer_limit, like 137386 demand_empty_rest_of_line: The two functions ought to behave the 137387 same in that respect. Finally, demand_empty_rest_of_line gets a 137388 little hardening to prevent accesses past buffer_limit plus one. 137389 137390 PR 28979 137391 * read.c (read_a_source_file): Calculate known size for sbuf 137392 rather than calling strlen. 137393 (demand_empty_rest_of_line): Remove "know" check. Expand comment. 137394 Don't dereference input_line_pointer when past buffer_limit. 137395 (ignore_rest_of_line): Allow input_line_pointer to increment to 137396 buffer_limit plus one. Expand comment. 137397 1373982022-03-20 Joel Brobecker <brobecker@adacore.com> 137399 137400 Update gdb/NEWS after GDB 12 branch creation. 137401 This commit a new section for the next release branch, and renames 137402 the section of the current branch, now that it has been cut. 137403 1374042022-03-20 Joel Brobecker <brobecker@adacore.com> 137405 137406 Bump version to 13.0.50.DATE-git. 137407 Now that the GDB 12 branch has been created, 137408 this commit bumps the version number in gdb/version.in to 137409 13.0.50.DATE-git 137410 137411 For the record, the GDB 12 branch was created 137412 from commit 2be64de603f8b3ae359d2d3fbf5db0e79869f32b. 137413 137414 Also, as a result of the version bump, the following changes 137415 have been made in gdb/testsuite: 137416 137417 * gdb.base/default.exp: Change $_gdb_major to 13. 137418 1374192022-03-20 liuzhensong <liuzhensong@loongson.cn> 137420 137421 ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64 137422 ld/testsuite/ld-loongarch-elf 137423 137424 * ld-loongarch-elf.exp: Test LoongArch32 and LoongArch64 testcases respectively. 137425 * jmp_op.d: Fix bug in test LoongArch32. 137426 * disas-jirl-32.d: New test case for LoongArch32. 137427 * disas-jirl-32.s: New test case for LoongArch32. 137428 * disas-jirl.d: Skip test case LoongArch32. 137429 * macro_op_32.d: New test case for LoongArch32. 137430 * macro_op_32.s: New test case for LoongArch32. 137431 * macro_op.d: Skip test case LoongArch32. 137432 1374332022-03-20 liuzhensong <liuzhensong@loongson.cn> 137434 137435 gas:LoongArch: Fix "make check" pr21884 fail in LoongArch32. 137436 gas/config/ 137437 * tc-loongarch.c: Add function to select target mach. 137438 * tc-loongarch.h: Define macro TARGET_MACH. 137439 137440 ld: loongarch: Skip unsupport test cases. 137441 ld/testsuite/ld-elf/ 137442 * eh5.d Skip loongarch64 target. 137443 * pr21884.d Skip loongarch* targets. 137444 * pr26936.d Skip loongarch* targets. 137445 1374462022-03-20 liuzhensong <liuzhensong@loongson.cn> 137447 137448 LoongArch: Fix LD check fails. 137449 Some test cases about ifunc. 137450 137451 bfd/ 137452 * elfnn-loongarch.c 137453 * elfxx-loongarch.h 137454 137455 === ld Summary === 137456 of expected passes 1430 137457 of expected failures 11 137458 of untested testcases 1 137459 of unsupported tests 154 137460 1374612022-03-20 liuzhensong <liuzhensong@loongson.cn> 137462 137463 LoongArch: Update ABI eflag in elf header. 137464 Update LoongArch ABI eflag in elf header. 137465 ilp32s 0x5 137466 ilp32f 0x6 137467 ilp32d 0x7 137468 lp64s 0x1 137469 lp64f 0x2 137470 lp64d 0x3 137471 137472 bfd/ 137473 * elfnn-loongarch.c Check object flags while ld. 137474 137475 gas/ 137476 * tc-loongarch.c Write eflag to elf header. 137477 137478 include/elf 137479 * loongarch.h Define ABI number. 137480 1374812022-03-20 liuzhensong <liuzhensong@loongson.cn> 137482 137483 gas:LoongArch: Fix wrong line number in .debug_line 137484 The dwarf2_emit_insn() can create debuginfo of line. But it is called 137485 too late in append_fixp_and_insn. It causes extra offs when debuginfo 137486 of line sets address. 137487 137488 gas/config/ 137489 * tc-loongarch.c 137490 1374912022-03-20 liuzhensong <liuzhensong@loongson.cn> 137492 137493 gas:LoongArch: Fix segment error in compilation due to too long symbol name. 137494 Change "char buffer[8192];" into "char *buffer = 137495 (char *) malloc(1000 + 6 * len_str);" in function 137496 loongarch_expand_macro_with_format_map. 137497 137498 gas/ 137499 * config/tc-loongarch.c 137500 137501 include/ 137502 * opcode/loongarch.h 137503 137504 opcodes/ 137505 * loongarch-coder.c 137506 1375072022-03-20 liuzhensong <liuzhensong@loongson.cn> 137508 137509 LoongArch: Use functions instead of magic numbers. 137510 Replace the magic numbers in gas(tc-loongarch.c) and 137511 bfd(elfnn-loongarch.c) with the functions defined in 137512 the howto table(elfxx-loongarch.c). 137513 137514 gas/ 137515 * config/tc-loongarch.c: use functions. 137516 137517 bfd/ 137518 * elfnn-loongarch.c: use functions. 137519 * elfxx-loongarch.c: define functions. 137520 * elfxx-loongarch.h 137521 1375222022-03-20 liuzhensong <liuzhensong@loongson.cn> 137523 137524 ubsan: loongarch : signed integer shift overflow. 137525 opcodes/ 137526 * loongarch-coder.c : 137527 int32_t ret = 0; 137528 ret <<= sizeof (ret) * 8 - len; 137529 ret >>= sizeof (ret) * 8 - len; 137530 ... 137531 Avoid ubsan warning. 137532 1375332022-03-20 GDB Administrator <gdbadmin@sourceware.org> 137534 137535 Automatic date update in version.in 137536 1375372022-03-19 Simon Marchi <simon.marchi@efficios.com> 137538 137539 gdb/python: remove gdb._mi_commands dict 137540 The motivation for this patch is the fact that py-micmd.c doesn't build 137541 with Python 2, due to PyDict_GetItemWithError being a Python 3-only 137542 function: 137543 137544 CXX python/py-micmd.o 137545 /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: 137546 /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 137547 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), 137548 | ^~~~~~~~~~~~~~~~~~~~~~~ 137549 | PyDict_GetItemString 137550 137551 A first solution to fix this would be to try to replace 137552 PyDict_GetItemWithError equivalent Python 2 code. But I looked at why 137553 we are doing this in the first place: it is to maintain the 137554 `gdb._mi_commands` Python dictionary that we use as a `name -> 137555 gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is 137556 never actually used in Python, it seems like a lot of trouble to use a 137557 Python object for this. 137558 137559 My first idea was to replace it with a C++ map 137560 (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While 137561 implementing this, I realized we don't really need this map at all. The 137562 mi_command_py objects registered in the main MI command table can own 137563 their backing micmdpy_object (that's a gdb.MICommand, but seen from the 137564 C++ code). To know whether an mi_command is an mi_command_py, we can 137565 use a dynamic cast. Since there's one less data structure to maintain, 137566 there are less chances of messing things up. 137567 137568 - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is 137569 now what keeps the MICommand alive. 137570 - Set micmdpy_object::mi_command in the constructor of mi_command_py. 137571 If mi_command_py manages setting/clearing that field in 137572 swap_python_object, I think it makes sense that it also takes care of 137573 setting it initially. 137574 - Move a bunch of checks from micmdpy_install_command to 137575 swap_python_object, and make them gdb_asserts. 137576 - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is 137577 needed to know whether there's a Python MI command already registered 137578 with that name. But we can already tell if there's a non-Python 137579 command registered with that name. Return an error if that happens, 137580 rather than waiting for insert_mi_cmd_entry to fail. Change the 137581 error message to "name is already in use" rather than "may already be 137582 in use", since it's more precise. 137583 137584 I asked Andrew about the original intent of using a Python dictionary 137585 object to hold the command objects. The reason was to make sure the 137586 objects get destroyed when the Python runtime gets finalized, not later. 137587 Holding the objects in global C++ data structures and not doing anything 137588 more means that the held Python objects will be decref'd after the 137589 Python interpreter has been finalized. That's not desirable. I tried 137590 it and it indeed segfaults. 137591 137592 Handle this by adding a gdbpy_finalize_micommands function called in 137593 finalize_python. This is the mirror of gdbpy_initialize_micommands 137594 called in do_start_initialization. In there, delete all Python MI 137595 commands. I think it makes sense to do it this way: if it was somehow 137596 possible to unload Python support from GDB in the middle of a session 137597 we'd want to unregister any Python MI command. Otherwise, these MI 137598 commands would be backed with a stale PyObject or simply nothing. 137599 137600 Delete tests that were related to `gdb._mi_commands`. 137601 137602 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 137603 Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3 137604 1376052022-03-19 GDB Administrator <gdbadmin@sourceware.org> 137606 137607 Automatic date update in version.in 137608 1376092022-03-18 Pedro Alves <pedro@palves.net> 137610 137611 Fix crash with stepi, no debug info, and "set debug infrun 1" 137612 A stepi in a function without debug info with "set debug infrun 1" 137613 crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun 137614 debug print statements), due to a reference to 137615 "tp->current_symtab->filename" when tp->current_symtab is null. 137616 137617 This commit adds the missing null check. The output in this case 137618 becomes: 137619 137620 [infrun] set_step_info: symtab = <null>, line = 0, step_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}, step_stack_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special} 137621 137622 Change-Id: I5171a9d222bc7e15b9dba2feaba7d55c7acd99f8 137623 1376242022-03-18 Tom Tromey <tromey@adacore.com> 137625 137626 Implement gdbarch_stack_frame_destroyed_p for aarch64 137627 The internal AdaCore testsuite has a test that checks that an 137628 out-of-scope watchpoint is deleted. This fails on some aarch64 137629 configurations, reporting an extra stop: 137630 137631 (gdb) continue 137632 Continuing. 137633 137634 Thread 3 hit Watchpoint 2: result 137635 137636 Old value = 64 137637 New value = 0 137638 0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13 137639 13 end Get_Val; 137640 137641 I believe what is happening here is that the variable is stored at: 137642 137643 <efa> DW_AT_location : 2 byte block: 91 7c (DW_OP_fbreg: -4) 137644 137645 and the extra stop is reported just before a return, when the ldp 137646 instruction is executed: 137647 137648 0x0000000040021644 <+204>: ldp x29, x30, [sp], #48 137649 0x0000000040021648 <+208>: ret 137650 137651 This instruction modifies the frame base calculation, and so the test 137652 picks up whatever memory is pointed to in the callee frame. 137653 137654 Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes 137655 this problem. 137656 137657 As usual with this sort of patch, it has passed internal testing, but 137658 I don't have a good way to try it with dejagnu. So, I don't know 137659 whether some existing test covers this. I suspect there must be one, 137660 but it's also worth noting that this test passes for aarch64 in some 137661 configurations -- I don't know what causes one to fail and another to 137662 succeed. 137663 1376642022-03-18 Nick Clifton <nickc@redhat.com> 137665 137666 Fix Build issues due to patch "gprofng: a new GNU profiler" 137667 Find and fix more places where clock_gettime() and CLOCK_MONOTONIC_RAW are used. 137668 1376692022-03-18 Simon Marchi <simon.marchi@efficios.com> 137670 137671 gdb: run black to format some Python files 137672 Seems like some leftovers from previous commits. 137673 137674 Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83 137675 1376762022-03-18 Viorel Preoteasa <viorel.preoteasa@gmail.com> 137677 137678 Fix ld-arm bug in encoding of blx calls jumping from thumb to arm instructions 137679 PR 28924 137680 * elf32-arm.c (THM_MAX_FWD_BRANCH_OFFSET): Fix definition. 137681 (THM2_MAX_FWD_BRANCH_OFFSET): Likewise. 137682 1376832022-03-18 Jan Beulich <jbeulich@suse.com> 137684 137685 x86: also fold remaining multi-vector-size shift insns 137686 By slightly relaxing the checking in operand_type_register_match() we 137687 can fold the vector shift insns with an XMM source as well. While 137688 strictly speaking an overlap in just one size (see the code comment) is 137689 not enough (both operands could have multiple sizes with just a single 137690 common one), this is good enough for all templates we have, or which 137691 could sensibly / usefully appear (within the scope of the present 137692 operand matching model). 137693 137694 Tightening this a little would be possible, but would require broadcast 137695 related information to be passed into the function. 137696 1376972022-03-18 Jan Beulich <jbeulich@suse.com> 137698 137699 x86: drop stray CheckRegSize from VEXTRACT{F,I}32X4 137700 They have only a single operand allowing multiple sizes, hence there are 137701 no pairs of operands to check for consistent size. 137702 137703 x86: fold certain AVX2 templates into their AVX counterparts 137704 Like for AVX512VL we can make the handling of operand sizes a little 137705 more flexible to allow reducing the number of templates we have. 137706 1377072022-03-18 Tsukasa OI <research_trasio@irq.a4lg.com> 137708 137709 RISC-V: Cache management instructions 137710 This commit adds 'Zicbom' / 'Zicboz' instructions. 137711 137712 bfd/ChangeLog: 137713 137714 * elfxx-riscv.c (riscv_multi_subset_supports): Add handling for 137715 new instruction classes. 137716 137717 include/ChangeLog: 137718 137719 * opcode/riscv-opc.h (MATCH_CBO_CLEAN, MASK_CBO_CLEAN, 137720 MATCH_CBO_FLUSH, MASK_CBO_FLUSH, MATCH_CBO_INVAL, 137721 MASK_CBO_INVAL, MATCH_CBO_ZERO, MASK_CBO_ZERO): New macros. 137722 * opcode/riscv.h (enum riscv_insn_class): Add new instruction 137723 classes INSN_CLASS_ZICBOM and INSN_CLASS_ZICBOZ. 137724 137725 opcodes/ChangeLog: 137726 137727 * riscv-opc.c (riscv_opcodes): Add cache-block management 137728 instructions. 137729 1377302022-03-18 Tsukasa OI <research_trasio@irq.a4lg.com> 137731 137732 RISC-V: Prefetch hint instructions and operand set 137733 This commit adds 'Zicbop' hint instructions. 137734 137735 bfd/ChangeLog: 137736 137737 * elfxx-riscv.c (riscv_multi_subset_supports): Add handling for 137738 new instruction class. 137739 137740 gas/ChangeLog: 137741 137742 * config/tc-riscv.c (riscv_ip): Add handling for new operand 137743 type 'f' (32-byte aligned pseudo S-type immediate for prefetch 137744 hints). 137745 (validate_riscv_insn): Likewise. 137746 137747 include/ChangeLog: 137748 137749 * opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I, 137750 MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W, 137751 MASK_PREFETCH_W): New macros. 137752 * opcode/riscv.h (enum riscv_insn_class): Add new instruction 137753 class INSN_CLASS_ZICBOP. 137754 137755 opcodes/ChangeLog: 137756 137757 * riscv-dis.c (print_insn_args): Add handling for new operand 137758 type. 137759 * riscv-opc.c (riscv_opcodes): Add prefetch hint instructions. 137760 1377612022-03-18 Alan Modra <amodra@gmail.com> 137762 137763 PR28977 tc-i386.c internal error in parse_register 137764 PR 28977 137765 * config/tc-i386.c (parse_register): Handle X_op not O_register 137766 as for a non-reg_section symbol. Simplify array bounds check. 137767 1377682022-03-18 Alan Modra <amodra@gmail.com> 137769 137770 Tidy gas current_frame before exit 137771 Releases some obstack memory on an error path. 137772 137773 * cond.c (cond_finish_check): Call cond_exit_macro. 137774 1377752022-03-18 Alan Modra <amodra@gmail.com> 137776 137777 ubsan: logical_input_line signed integer overflow 137778 To avoid a completely useless fuzzing ubsan "bug" report, I decided to 137779 make logical_input_line unsigned. 137780 137781 * input-scrub.c (logical_input_line): Make unsigned. 137782 (struct input_save): Here too. 137783 (input_scrub_reinit, input_scrub_close, bump_line_counters), 137784 (as_where): Adjust to suit. 137785 1377862022-03-18 GDB Administrator <gdbadmin@sourceware.org> 137787 137788 Automatic date update in version.in 137789 1377902022-03-17 H.J. Lu <hjl.tools@gmail.com> 137791 137792 gprofng: Skip jsynprog with a broken javac 137793 On CET enabled Linux/x86-64 machines, one can get 137794 137795 $ javac simple.java 137796 Error: dl failure on line 894 137797 Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled 137798 137799 Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the 137800 jsynprog test with a broken javac. 137801 137802 PR gprofng/28965 137803 * Makefile.am (GPROFNG_BROKEN_JAVAC): New. 137804 (check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest. 137805 * configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST. Set to yes 137806 with a broken javac. 137807 * Makefile.in: Regenerate. 137808 * configure: Likewise. 137809 * testsuite/gprofng.display/display.exp: Skip jsynprog with a 137810 broken javac. 137811 1378122022-03-17 John Baldwin <jhb@FreeBSD.org> 137813 137814 Remove fall throughs in core_target::xfer_partial. 137815 The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX 137816 can try to fetch different data objects (such as 137817 TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data 137818 aren't present. Return with TARGET_XFER_E_IO if the gdbarch method 137819 isn't present instead. 137820 1378212022-03-17 Pedro Alves <pedro@palves.net> 137822 137823 gdb: Remove support for S+core 137824 GCC removed support for score back in 2014 already. Back then, we 137825 basically agreed about removing it from GDB too, but it ended up being 137826 forgotten. See: 137827 137828 https://sourceware.org/pipermail/gdb/2014-October/044643.html 137829 137830 Following through this time around. 137831 137832 Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4 137833 1378342022-03-17 Tom Tromey <tromey@adacore.com> 137835 137836 Add another test for Ada Wide_Wide_String 137837 In an earlier patch, I had written that I wanted to add this test: 137838 137839 ptype Wide_Wide_String'("literal") 137840 137841 ... but that it failed with the distro GNAT. Further investigation 137842 showed that it could be made to work by adding a function using 137843 Wide_Wide_String to the program -- this caused the type to end up in 137844 the debug info. 137845 137846 This patch adds the test. I'm checking this in. 137847 1378482022-03-17 Alan Modra <amodra@gmail.com> 137849 137850 ubsan: Null dereference in parse_module 137851 * vms-alpha.c (parse_module): Sanity check that DST__K_RTNBEG 137852 has set module->func_table for DST__K_RTNEND. Check return 137853 of bfd_zalloc. 137854 1378552022-03-17 Alan Modra <amodra@gmail.com> 137856 137857 asan: Buffer overflow in evax_bfd_print_dst 137858 With "name" a char*, the length at name[0] might be negative, escaping 137859 buffer limit checks. 137860 137861 * vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*. 137862 (evax_bfd_print_emh): Likewise. 137863 1378642022-03-17 Alan Modra <amodra@gmail.com> 137865 137866 asan: Buffer overflow in som_set_reloc_info 137867 * som.c (som_set_reloc_info): Add symcount parameter. Don't 137868 access symbols past symcount. Don't access fixup past end_fixups. 137869 (som_slurp_reloc_table): Adjust som_set_reloc_info calls. 137870 1378712022-03-17 Alan Modra <amodra@gmail.com> 137872 137873 asan: use of uninitialized value in buffer_and_nest 137874 More occurences of the same as commit d12b8d620c6a. 137875 137876 * macro.c (buffer_and_nest): Sanity check length in buffer 137877 before calling strncasecmp. 137878 1378792022-03-17 Alan Modra <amodra@gmail.com> 137880 137881 gprofng configure target tests 137882 ${target} in configure.ac should be the canonical target, so that for 137883 example, someone configuring with --target=x86_64-linux will match 137884 x86_64-*-linux*. 137885 137886 * configure.ac: Invoke AC_CANONICAL_TARGET. 137887 * libcollector/configure.ac: Likewise. 137888 * Makefile.in: Regenerate. 137889 * configure: Regenerate. 137890 * doc/Makefile.in: Regenerate. 137891 * gp-display-html/Makefile.in: Regenerate. 137892 * libcollector/Makefile.in: Regenerate. 137893 * libcollector/configure: Regenerate. 137894 * src/Makefile.in: Regenerate. 137895 1378962022-03-17 Alan Modra <amodra@gmail.com> 137897 137898 Re: asan: buffer overflow in peXXigen.c 137899 In the process of fixing a buffer overflow in commit fe69d4fcf0194a, 137900 I managed to introduce a fairly obvious NULL pointer dereference.. 137901 137902 * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't 137903 segfault on not finding section. Wrap overlong lines. 137904 1379052022-03-17 Alan Modra <amodra@gmail.com> 137906 137907 asan: buffer overflows after calling ignore_rest_of_line 137908 operand() is not a place that should be calling ignore_rest_of_line. 137909 ignore_rest_of_line shouldn't increment input_line_pointer if already 137910 at buffer limit. 137911 137912 * expr.c (operand): Don't call ignore_rest_of_line. 137913 * read.c (s_mri_common): Likewise. 137914 (ignore_rest_of_line): Don't increment input_line_pointer if 137915 already at buffer_limit. 137916 1379172022-03-17 Alan Modra <amodra@gmail.com> 137918 137919 Re: bfd: add AMDGCN architecture 137920 * po/SRC-POTFILES.in: Regenerate. 137921 1379222022-03-17 Jan Beulich <jbeulich@suse.com> 137923 137924 x86: don't accept base architectures as extensions 137925 The -march= intentions are quite clear: A base architecture may be 137926 followed by any number of extensions. Accepting a base architecture in 137927 place of an extension will at best result in confusion, as the first of 137928 the two (or more) items specified simply would not take effect, due to 137929 being overridden by the later one(s). 137930 1379312022-03-17 Jan Beulich <jbeulich@suse.com> 137932 137933 x86: never set i386_cpu_flags' "unused" field 137934 Setting this field risks cpu_flags_all_zero() mistakenly returning 137935 "false" when the object passed in was e.g. the result of ANDing together 137936 two objects which had the bit set, or ANDNing together an object with 137937 the field set and one with the field clear. 137938 137939 While there also avoid setting CpuNo64: Like Cpu64 this is driven 137940 differently anyway and hence shouldn't be set anywhere by default. 137941 137942 Note that the moving of the two items in i386-gen.c's cpu_flags[] is 137943 only for documentation purposes (and slight reducing of overhead), as 137944 the fields are sorted anyway upon program start. 137945 1379462022-03-17 Jan Beulich <jbeulich@suse.com> 137947 137948 x86: unify CPU flag on/off processing 137949 There's no need for the arbitrary special "unknown" token: Simply 137950 recognize the leading ~ and process everything else the same, merely 137951 recording whether to set individual fields to 1 or 0. 137952 137953 While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS 137954 override cpu_arch_flags anyway when -march=iamcu is passed, and there's 137955 no reason to have the stray flag set even if no insn actually is keyed 137956 to it. 137957 1379582022-03-17 Jan Beulich <jbeulich@suse.com> 137959 137960 x86: add another IAMCU testcase 137961 Now that {L,K}1OM support is gone, and with it the brokenness in 137962 check_cpu_arch_compatible(), put in place a test making sure that only 137963 extensions can be enabled via .arch for IAMCU, and that the base 137964 architecture cannot be changed. 137965 137966 x86: drop L1OM/K1OM support from gas 137967 This was only rudimentary support anyway; none of the sub-architecture 137968 specific insns were ever supported. 137969 137970 x86: assorted IAMCU CPU checking fixes 137971 The checks done by check_cpu_arch_compatible() were halfway sensible 137972 only at the time where only L1OM support was there. The purpose, 137973 however, has always been to prevent bad uses of .arch (turning off the 137974 base CPU "feature" flag) while at the same time permitting extensions to 137975 be enabled / disabled. In order to achieve this (and to prevent 137976 regressions when L1OM and K1OM support are removed) 137977 - set CpuIAMCU in CPU_IAMCU_FLAGS, 137978 - adjust the IAMCU check in the function itself (the other two similarly 137979 broken checks aren't adjusted as they're slated to be removed anyway), 137980 - avoid calling the function for extentions (which would never have the 137981 base "feature" flag set), 137982 - add a new testcase actually exercising ".arch iamcu" (which would also 137983 regress with the planned removal). 137984 1379852022-03-17 GDB Administrator <gdbadmin@sourceware.org> 137986 137987 Automatic date update in version.in 137988 1379892022-03-16 Andrew Burgess <aburgess@redhat.com> 137990 137991 gdb: work around prompt corruption caused by bracketed-paste-mode 137992 In this commit: 137993 137994 commit b4f26d541aa7224b70d363932e816e6e1a857633 137995 Date: Tue Mar 2 13:42:37 2021 -0700 137996 137997 Import GNU Readline 8.1 137998 137999 We imported readline 8.1 into GDB. As a consequence bug PR cli/28833 138000 was reported. This bug spotted that, when the user terminated GDB by 138001 sending EOF (usually bound to Ctrl+d), the last prompt would become 138002 corrupted. Here's what happens, the user is sat at a prompt like 138003 this: 138004 138005 (gdb) 138006 138007 And then the user sends EOF (Ctrl+d), we now see this: 138008 138009 quit) 138010 ... gdb terminates, and we return to the shell ... 138011 138012 Notice the 'quit' was printed over the prompt. 138013 138014 This problem is a result of readline 8.1 enabling bracketed paste mode 138015 by default. This problem is present in readline 8.0 too, but in that 138016 version of readline bracketed paste mode is off by default, so a user 138017 will not see the bug unless they specifically enable the feature. 138018 138019 Bracketed paste mode is available in readline 7.0 too, but the bug 138020 is not present in this version of readline, see below for why. 138021 138022 What causes this problem is how readline disables bracketed paste 138023 mode. Bracketed paste mode is a terminal feature that is enabled and 138024 disabled by readline emitting a specific escape sequence. The problem 138025 for GDB is that the escape sequence to disable bracketed paste mode 138026 includes a '\r' character at the end, see this thread for more 138027 details: 138028 138029 https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html 138030 138031 The change to add the '\r' character to the escape sequence used to 138032 disable bracketed paste mode was introduced between readline 7.0 and 138033 readline 8.0, this is why the bug would not occur when using older 138034 versions of readline (note: I don't know if its even possible to build 138035 GDB using readline 7.0. That really isn't important, I'm just 138036 documenting the history of this issue). 138037 138038 So, the escape sequence to disable bracketed paste mode is emitted 138039 from the readline function rl_deprep_terminal, this is called after 138040 the user has entered a complete command and pressed return, or, if the 138041 user sends EOF. 138042 138043 However, these two cases are slightly different. In the first case, 138044 when the user has entered a command and pressed return, the cursor 138045 will have moved to the next, empty, line, before readline emits the 138046 escape sequence to leave bracketed paste mode. The final '\r' 138047 character moves the cursor back to the beginning of this empty line, 138048 which is harmless. 138049 138050 For the EOF case though, this is not what happens. Instead, the 138051 escape sequence to leave bracketed paste mode is emitted on the same 138052 line as the prompt. The final '\r' moves the cursor back to the start 138053 of the prompt line. This leaves us ready to override the prompt. 138054 138055 It is worth noting, that this is not the intended behaviour of 138056 readline, in rl_deprep_terminal, readline should emit a '\n' character 138057 when EOF is seen. However, due to a bug in readline this does not 138058 happen (the _rl_eof_found flag is never set). This is the first 138059 readline bug that effects GDB. 138060 138061 GDB prints the 'quit' message from command_line_handler (in 138062 event-top.c), this function is called (indirectly) from readline to 138063 process the complete command line, but also in the EOF case (in which 138064 case the command line is set to nullptr). As this is part of the 138065 callback to process a complete command, this is called after readline 138066 has disabled bracketed paste mode (by calling rl_deprep_terminal). 138067 138068 And so, when bracketed paste mode is in use, rl_deprep_terminal leaves 138069 the cursor at the start of the prompt line (in the EOF case), and 138070 command_line_handler then prints 'quit', which overwrites the prompt. 138071 138072 The solution to this problem is to print the 'quit' message earlier, 138073 before rl_deprep_terminal is called. This is easy to do by using the 138074 rl_deprep_term_function hook. It is this hook that usually calls 138075 rl_deprep_terminal, however, if we replace this with a new function, 138076 we can print the 'quit' string, and then call rl_deprep_terminal 138077 ourselves. This allows the 'quit' to be printed before 138078 rl_deprep_terminal is called. 138079 138080 The problem here is that there is no way in rl_deprep_terminal to know 138081 if readline is processing EOF or not, and as a result, we don't know 138082 when we should print 'quit'. This is the second readline bug that 138083 effects GDB. 138084 138085 Both of these readline issues are discussed in this thread: 138086 138087 https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html 138088 138089 The result of that thread was that readline was patched to address 138090 both of these issues. 138091 138092 Now it should be easy to backport the readline fix to GDB's in tree 138093 copy of readline, and then change GDB to make use of these fixes to 138094 correctly print the 'quit' string. 138095 138096 However, we are just about to branch GDB 12, and there is concern from 138097 some that changing readline this close to a new release is a risky 138098 idea, see this thread: 138099 138100 https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html 138101 138102 So, this commit doesn't change readline at all. Instead, this commit 138103 is the smallest possible GDB change in order to avoid the prompt 138104 corruption. 138105 138106 In this commit I change GDB to print the 'quit' string on the line 138107 after the prompt, but only when bracketed paste mode is on. This 138108 avoids the overwriting issue, the user sees this: 138109 138110 (gdb) 138111 quit 138112 ... gdb terminates, and returns to the shell ... 138113 138114 This isn't ideal, but is better than the existing behaviour. After 138115 GDB 12 has branched, we can backport the readline fix, and apply a 138116 real fix to GDB. 138117 138118 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833 138119 1381202022-03-16 Fangrui Song <i@maskray.me> 138121 138122 objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbols 138123 PR binutils/28926 138124 * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols 138125 * NEWS: Mention feature. 138126 * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test. 138127 * testsuite/binutils-all/weaken-gnu-unique.s: New. 138128 1381292022-03-16 Tom Tromey <tromey@adacore.com> 138130 138131 Reimplement array concatenation for Ada and D 138132 This started as a patch to implement string concatenation for Ada. 138133 However, while working on this, I looked at how this code could 138134 possibly be called. It turns out there are only two users of 138135 concat_operation: Ada and D. So, in addition to implementing this for 138136 Ada, this patch rewrites value_concat, removing the odd "concatenate 138137 or repeat" semantics, which were completely unused. As Ada and D both 138138 seem to represent strings using TYPE_CODE_ARRAY, this removes the 138139 TYPE_CODE_STRING code from there as well. 138140 138141 Remove eval_op_concat 138142 eval_op_concat has code to search for an operator overload of 138143 BINOP_CONCAT. However, the operator overloading code is specific to 138144 C++, which does not have this operator. And, 138145 binop_types_user_defined_p rejects this case right at the start, and 138146 value_x_binop does not handle this case. I think this code has been 138147 dead for a very long time. This patch removes it and hoists the 138148 remaining call into concatenation::evaluate, removing eval_op_concat 138149 entirely. 138150 1381512022-03-16 Tom Tromey <tromey@adacore.com> 138152 138153 Ada support for wide strings 138154 This adds some basic support for Wide_String and Wide_Wide_String to 138155 the Ada expression evaluator. In particular, a string literal may be 138156 converted to a wide or wide-wide string depending on context. 138157 138158 The patch updates an existing test case. Note that another test, 138159 namely something like: 138160 138161 ptype Wide_Wide_String'("literal") 138162 138163 ... would be nice to add, but when tested against a distro GNAT, this 138164 did not work (probably due to lack of debuginfo); so, I haven't 138165 included it here. 138166 1381672022-03-16 Tom Tromey <tromey@adacore.com> 138168 138169 Remove eval_op_string 138170 eval_op_string is only used in a single place -- the implementation of 138171 string_operation. This patch turns it into the 138172 string_operation::evaluate method, removing a bit of extraneous code. 138173 1381742022-03-16 Carl Love <cel@us.ibm.com> 138175 138176 Powerpc fix for gdb.base/ending-run.exp 138177 The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the 138178 system does not have the needed glibc debug-info files loaded. In this 138179 case, gdb is not able to determine where execution stopped. This behavior 138180 looks as follows for the test case: 138181 138182 The next to the last test does a next command when the program is stopped 138183 at the closing bracket for main. The message printed is: 138184 138185 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 138186 138187 which fails to match any of the test_multiple options. 138188 138189 The test then does another next command. On Powerpc, the 138190 message printed it: 138191 138192 Cannot find bounds of current function 138193 138194 The test fails as the output does not match any of the options for the 138195 gdb_test_multiple. 138196 138197 I checked the behavior on Powerpc to see if this is typical. 138198 I ran gdb on the following simple program as shown below. 138199 138200 #include <stdio.h> 138201 int 138202 main(void) 138203 { 138204 printf("Hello, world!\n"); 138205 return 0; 138206 } 138207 138208 gdb ./hello_world 138209 <snip the gdb start info> 138210 138211 Type "apropos word" to search for commands related to "word"... 138212 Reading symbols from ./hello_world... 138213 (No debugging symbols found in ./hello_world) 138214 (gdb) break main 138215 Breakpoint 1 at 0x818 138216 (gdb) r 138217 138218 Starting program: /home/carll/hello_world 138219 [Thread debugging using libthread_db enabled] 138220 Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". 138221 138222 Breakpoint 1, 0x0000000100000818 in main () 138223 (gdb) n 138224 Single stepping until exit from function main, 138225 which has no line number information. 138226 Hello, world! 138227 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 138228 (gdb) n 138229 Cannot find bounds of current function 138230 138231 So it would seem that the messages seen from the test case are 138232 "normal" output for Powerpc when the debug-info is not available. 138233 138234 The following patch adds the output from Powerpc as an option 138235 to the gdb_test_multiple statement, identifying the output as the expected 138236 output on Powerpc without the needed debug-info files installed. 138237 138238 The patch has been tested on a Power 10 system and an Intel 138239 64-bit system. No additional regression failures were seen on 138240 either platform. 138241 1382422022-03-16 Martin Storsj? <martin@martin.st> 138243 138244 dlltool: Use the output name as basis for deterministic temp prefixes 138245 PR 28885 138246 * dlltool.c (main): use imp_name rather than dll_name when 138247 generating a temporary file name. 138248 1382492022-03-16 Jan Vrany <jan.vrany@labware.com> 138250 Andrew Burgess <aburgess@redhat.com> 138251 138252 gdb/mi: consistently notify user when GDB/MI client uses -thread-select 138253 GDB notifies users about user selected thread changes somewhat 138254 inconsistently as mentioned on gdb-patches mailing list here: 138255 138256 https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html 138257 138258 Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI 138259 interfaces connected to separate terminals. 138260 138261 Assuming inferior is stopped and thread 1 is selected, when a thread 138262 2 is selected using '-thread-select 2' command on GDB/MI terminal: 138263 138264 -thread-select 2 138265 ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"} 138266 (gdb) 138267 138268 and on CLI terminal we get the notification (as expected): 138269 138270 [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))] 138271 #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30 138272 30 volatile int dummy = 0; 138273 138274 However, now that thread 2 is selected, if thread 1 is selected 138275 using 'thread-select --thread 1 1' command on GDB/MI terminal 138276 terminal: 138277 138278 -thread-select --thread 1 1 138279 ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"} 138280 (gdb) 138281 138282 but no notification is printed on CLI terminal, despite the fact 138283 that user selected thread has changed. 138284 138285 The problem is that when `-thread-select --thread 1 1` is executed 138286 then thread is switched to thread 1 before mi_cmd_thread_select () is 138287 called, therefore the condition "inferior_ptid != previous_ptid" 138288 there does not hold. 138289 138290 To address this problem, we have to move notification logic up to 138291 mi_cmd_execute () where --thread option is processed and notify 138292 user selected contents observers there if context changes. 138293 138294 However, this in itself breaks GDB/MI because it would cause context 138295 notification to be sent on MI channel. This is because by the time 138296 we notify, MI notification suppression is already restored (done in 138297 mi_command::invoke(). Therefore we had to lift notification suppression 138298 logic also up to mi_cmd_execute (). This change in made distinction 138299 between mi_command::invoke() and mi_command::do_invoke() unnecessary 138300 as all mi_command::invoke() did (after the change) was to call 138301 do_invoke(). So this patches removes do_invoke() and moves the command 138302 execution logic directly to invoke(). 138303 138304 With this change, all gdb.mi tests pass, tested on x86_64-linux. 138305 138306 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631 138307 1383082022-03-16 H.J. Lu <hjl.tools@gmail.com> 138309 138310 gprofng: Use symver attribute if available 138311 Use symver attribute if available, instead of asm statement, to support 138312 LTO build. 138313 138314 PR gprof/28962 138315 * libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use 138316 SYMVER_ATTRIBUTE. 138317 (timer_create@GLIBC_2.2): Likewise. 138318 (timer_create@GLIBC_2.2.5): Likewise. 138319 (pthread_create@@GLIBC_2.1): Likewise. 138320 (pthread_create@GLIBC_2.0): Likewise. 138321 * libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise. 138322 (open64@GLIBC_2.1): Likewise. 138323 (fopen@@GLIBC_2.1): Likewise. 138324 (fopen@GLIBC_2.0): Likewise. 138325 (fclose@@GLIBC_2.1): Likewise. 138326 (fclose@GLIBC_2.0): Likewise. 138327 (fdopen@@GLIBC_2.1): Likewise. 138328 (fdopen@GLIBC_2.0): Likewise. 138329 (pread@@GLIBC_2.2): Likewise. 138330 (pread@GLIBC_2.1): Likewise. 138331 (pwrite@@GLIBC_2.2): Likewise. 138332 (pwrite@GLIBC_2.1): Likewise. 138333 (pwrite64@@GLIBC_2.2): Likewise. 138334 (pwrite64@GLIBC_2.1): Likewise. 138335 (fgetpos@@GLIBC_2.2): Likewise. 138336 (fgetpos@GLIBC_2.0): Likewise. 138337 (fgetpos64@@GLIBC_2.2): Likewise. 138338 (fgetpos64@GLIBC_2.1): Likewise. 138339 (fsetpos@@GLIBC_2.2): Likewise. 138340 (fsetpos@GLIBC_2.0): Likewise. 138341 (fsetpos64@@GLIBC_2.2): Likewise. 138342 (fsetpos64@GLIBC_2.1): Likewise. 138343 * libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise. 138344 (posix_spawn@GLIBC_2.2): Likewise. 138345 (posix_spawn@GLIBC_2.2.5): Likewise. 138346 (posix_spawnp@@GLIBC_2.15): Likewise. 138347 (posix_spawnp@GLIBC_2.2): Likewise. 138348 (posix_spawnp@GLIBC_2.2.5): Likewise. 138349 (popen@@GLIBC_2.1): Likewise. 138350 (popen@GLIBC_2.0): Likewise. 138351 (_popen@@GLIBC_2.1): Likewise. 138352 (_popen@GLIBC_2.0): Likewise. 138353 * libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise. 138354 (dlopen@GLIBC_2.0): Likewise. 138355 * libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2): 138356 Likewise. 138357 (pthread_cond_wait@GLIBC_2.0): Likewise. 138358 (pthread_cond_wait@GLIBC_2.2.5): Likewise. 138359 (pthread_cond_wait@GLIBC_2.2): Likewise. 138360 (pthread_cond_timedwait@@GLIBC_2.3.2): Likewise. 138361 (pthread_cond_timedwait@GLIBC_2.0): Likewise. 138362 (pthread_cond_timedwait@GLIBC_2.2.5): Likewise. 138363 (pthread_cond_timedwait@GLIBC_2.2): Likewise. 138364 (sem_wait@@GLIBC_2.1): Likewise. 138365 (sem_wait@GLIBC_2.0): Likewise. 138366 * src/collector_module.h (SYMVER_ATTRIBUTE): New. 138367 1383682022-03-16 H.J. Lu <hjl.tools@gmail.com> 138369 138370 gprofng: Don't hardcode -Wno-format-truncation/-Wno-switch 138371 Use -Wno-format-truncation and -Wno-switch only if they are supported. 138372 138373 PR gprof/28969 138374 * configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New 138375 AC_SUBST for -Wno-format-truncation. 138376 (GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch. 138377 * Makefile.in: Regenerate. 138378 * configure: Likewise. 138379 * src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation 138380 and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and 138381 GPROFNG_NO_SWITCH_CFLAGS. 138382 * src/Makefile.in: Regenerate. 138383 1383842022-03-16 H.J. Lu <hjl.tools@gmail.com> 138385 138386 gprofng: Don't hardcode -Wno-nonnull-compare 138387 Use -Wno-nonnull-compare only if it is supported. 138388 138389 PR gprof/28969 138390 * libcollector/Makefile.am (AM_CFLAGS): Replace 138391 -Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS. 138392 * libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS): 138393 New AC_SUBST for -Wno-nonnull-compare. 138394 * libcollector/Makefile.in: Regenerate. 138395 * libcollector/aclocal.m4: Likewise. 138396 * libcollector/configure: Likewise. 138397 1383982022-03-16 H.J. Lu <hjl.tools@gmail.com> 138399 138400 gprofng: Define ATTRIBUTE_FALLTHROUGH 138401 Define ATTRIBUTE_FALLTHROUGH to __attribute__ ((fallthrough)) only for 138402 GCC 7 or above. 138403 138404 PR gprof/28969 138405 * common/gp-defs.h (ATTRIBUTE_FALLTHROUGH): New. 138406 * src/gp-collect-app.cc (collect::check_args): Replace 138407 /* FALLTHROUGH */ with ATTRIBUTE_FALLTHROUGH. 138408 1384092022-03-16 Simon Marchi <simon.marchi@efficios.com> 138410 138411 binutils/readelf: handle AMDGPU relocation types 138412 Make readelf recognize AMDGPU relocation types, as documented here: 138413 138414 https://llvm.org/docs/AMDGPUUsage.html#amdgpu-relocation-records 138415 138416 The user-visible change looks like: 138417 138418 -000000000004 000400000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD0 138419 -00000000000c 000500000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD1 138420 -000000000014 000600000007 unrecognized: 7 0000000000000000 global_var0 138421 -00000000001c 000700000008 unrecognized: 8 0000000000000000 global_var1 138422 -000000000024 000800000009 unrecognized: 9 0000000000000000 global_var2 138423 -00000000002c 00090000000a unrecognized: a 0000000000000000 global_var3 138424 -000000000034 000a0000000b unrecognized: b 0000000000000000 global_var4 138425 +000000000004 000400000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD0 138426 +00000000000c 000500000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD1 138427 +000000000014 000600000007 R_AMDGPU_GOTPCREL 0000000000000000 global_var0 138428 +00000000001c 000700000008 R_AMDGPU_GOTPCREL 0000000000000000 global_var1 138429 +000000000024 000800000009 R_AMDGPU_GOTPCREL 0000000000000000 global_var2 138430 +00000000002c 00090000000a R_AMDGPU_REL32_LO 0000000000000000 global_var3 138431 +000000000034 000a0000000b R_AMDGPU_REL32_HI 0000000000000000 global_var4 138432 138433 binutils/ChangeLog: 138434 138435 * readelf.c (dump_relocations): Handle EM_AMDGPU. 138436 138437 include/ChangeLog: 138438 138439 * elf/amdgpu.h: Add relocation values. 138440 138441 Change-Id: I2ed4589f4cd37ea11ad2e0cb38d4b682271e1334 138442 1384432022-03-16 Simon Marchi <simon.marchi@efficios.com> 138444 138445 binutils/readelf: build against msgpack, dump NT_AMDGPU_METADATA note contents 138446 The AMDGPU HSA OS ABI (code object v3 and above) defines the 138447 NT_AMDGPU_METADATA ELF note [1]. The content is a msgpack object 138448 describing, among other things, the kernels present in the code object 138449 and how to call them. 138450 138451 I think it would be useful for readelf to be able to display the content 138452 of those notes. msgpack is a structured format, a bit like JSON, except 138453 not text-based. It is therefore possible to dump the contents in 138454 human-readable form without knowledge of the specific layout of the 138455 note. 138456 138457 Add configury to binutils to optionally check for the msgpack C library 138458 [2]. Add There is a new --with{,out}-msgpack configure flag, and the actual 138459 library lookup is done using pkg-config. 138460 138461 If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks 138462 like: 138463 138464 $ readelf --notes amdgpu-code-object 138465 Displaying notes found in: .note 138466 Owner Data size Description 138467 AMDGPU 0x0000040d NT_AMDGPU_METADATA (code object metadata) 138468 { 138469 "amdhsa.kernels": [ 138470 { 138471 ".args": [ 138472 { 138473 ".address_space": "global", 138474 ".name": "out.coerce", 138475 ".offset": 0, 138476 ".size": 8, 138477 ".value_kind": "global_buffer", 138478 }, 138479 <snip> 138480 138481 If msgpack support is disabled, dump the contents as hex, as is done 138482 with notes that are not handled in a special way. This allows one to 138483 decode the contents manually (maybe using a command-line msgpack 138484 decoder) if really needed. 138485 138486 [1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata 138487 [2] https://github.com/msgpack/msgpack-c/tree/c_master 138488 138489 binutils/ChangeLog: 138490 138491 * Makefile.am (readelf_CFLAGS): New. 138492 (readelf_LDADD): Add MSGPACK_LIBS. 138493 * Makefile.in: Re-generate. 138494 * config.in: Re-generate. 138495 * configure: Re-generate. 138496 * configure.ac: Add --with-msgpack flag and check for msgpack 138497 using pkg-config. 138498 * readelf.c: Include msgpack.h if HAVE_MSGPACK. 138499 (print_note_contents_hex): New. 138500 (print_indents): New. 138501 (dump_msgpack_obj): New. 138502 (dump_msgpack): New. 138503 (print_amdgpu_note): New. 138504 (process_note): Handle NT_AMDGPU_METADATA note contents. 138505 Use print_note_contents_hex. 138506 138507 Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84 138508 1385092022-03-16 Simon Marchi <simon.marchi@efficios.com> 138510 138511 binutils/readelf: handle NT_AMDGPU_METADATA note name 138512 Handle the NT_AMDGPU_METADATA note, which is described here: 138513 138514 https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records 138515 138516 As of this patch, just print out the name, not the contents, which is in 138517 the msgpack format. 138518 138519 binutils/ChangeLog: 138520 138521 * readelf.c (get_amdgpu_elf_note_type): New. 138522 (process_note): Handle "AMDGPU" notes. 138523 138524 include/ChangeLog: 138525 138526 * elf/amdgcn.h (NT_AMDGPU_METADATA): New. 138527 138528 Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23 138529 1385302022-03-16 Simon Marchi <simon.marchi@efficios.com> 138531 138532 binutils/readelf: decode AMDGPU-specific e_flags 138533 Decode and print the AMDGPU-specific fields of e_flags, as documented 138534 here: 138535 138536 https://llvm.org/docs/AMDGPUUsage.html#header 138537 138538 That is: 138539 138540 - The specific GPU model 138541 - Whether the xnack and sramecc features are enabled 138542 138543 The result looks like: 138544 138545 - Flags: 0x52f 138546 + Flags: 0x52f, gfx906, xnack any, sramecc any 138547 138548 The flags for the "HSA" OS ABI are properly versioned and documented on 138549 that page. But the NONE, PAL and MESA3D OS ABIs are not well documented 138550 nor versioned. Taking a peek at the LLVM source code, we see that they 138551 encode their flags the same way as HSA v3. For example, for PAL: 138552 138553 https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601 138554 138555 So for those other OS ABIs, we read them the same as HSA v3. 138556 138557 binutils/ChangeLog: 138558 138559 * readelf.c: Include elf/amdgcn.h. 138560 (decode_AMDGPU_machine_flags): New. 138561 (get_machine_flags): Handle flags for EM_AMDGPU machine type. 138562 138563 include/ChangeLog: 138564 138565 * elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and 138566 EF_AMDGPU_FEATURE_* defines. 138567 138568 Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12 138569 1385702022-03-16 Simon Marchi <simon.marchi@efficios.com> 138571 138572 binutils/readelf: handle AMDGPU OS ABIs 138573 When the machine is EM_AMDGPU, handle the various OS ABIs described 138574 here: 138575 138576 https://llvm.org/docs/AMDGPUUsage.html#header 138577 138578 For a binary with the HSA OS ABI, the change looks like: 138579 138580 - OS/ABI: <unknown: 40> 138581 + OS/ABI: AMD HSA 138582 138583 binutils/ChangeLog: 138584 138585 * readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs. 138586 138587 include/ChangeLog: 138588 138589 * elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D): 138590 New. 138591 138592 Change-Id: I383590c390f7dc2fe0f902f50038735626d71863 138593 1385942022-03-16 Simon Marchi <simon.marchi@efficios.com> 138595 138596 opcodes: handle bfd_amdgcn_arch in configure script 138597 There isn't an actual opcodes implementation for the AMDGCN arch (yet), 138598 this is just the bare minimum to get 138599 138600 $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas 138601 $ make all-binutils 138602 138603 working later in this series. 138604 138605 opcodes/ChangeLog: 138606 138607 * configure.ac: Handle bfd_amdgcn_arch. 138608 * configure: Re-generate. 138609 138610 Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79 138611 1386122022-03-16 Simon Marchi <simon.marchi@efficios.com> 138613 138614 bfd: add AMDGCN architecture 138615 Add support for the AMDGCN architecture to BFD. 138616 138617 This is the bare minimum to get 138618 138619 $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas 138620 $ make all-binutils 138621 138622 working later in this series. 138623 138624 The specific AMDGCN models added here are a bit arbitrary, based on 138625 what we intend to initially support in GDB. This list will need to be 138626 updated in the future anyway. The complete up-to-date list of existing 138627 AMDGPU models can be found here: 138628 138629 https://llvm.org/docs/AMDGPUUsage.html#processors 138630 138631 The ELF format for this architecture is documented here: 138632 138633 https://llvm.org/docs/AMDGPUUsage.html#elf-code-object 138634 138635 The flags for the "HSA" OS ABI are properly versioned and documented on 138636 that page. But the NONE, PAL and MESA3D OS ABIs are not well documented 138637 nor versioned. Taking a peek at the LLVM source code, we see that they 138638 encode their flags the same way as HSA v3. For example, for PAL: 138639 138640 https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601 138641 138642 So at least, we know that all AMDGPU objects (of which AMDGCN objects 138643 are a subset of) at the time of writing encode the specific GPU model in 138644 the EF_AMDGPU_MACH field of e_flags. 138645 138646 bfd/ChangeLog: 138647 138648 * Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES): 138649 Add cpu-amdgcn.c. 138650 (BFD64_BACKENDS): Add elf64-amdgcn.lo. 138651 (BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c. 138652 * Makefile.in: Re-generate. 138653 * cpu-amdgcn.c: New. 138654 * elf64-amdgcn.c: New. 138655 * archures.c (bfd_architecture): Add bfd_arch_amdgcn and related 138656 mach defines. 138657 (bfd_amdgcn_arch): New. 138658 (bfd_archures_list): Add bfd_amdgcn_arch. 138659 * bfd-in2.h: Re-generate. 138660 * config.bfd: Handle amdgcn* target. 138661 * configure.ac: Handle amdgcn_elf64_le_vec. 138662 * configure: Re-generate. 138663 * elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA. 138664 * targets.c (amdgcn_elf64_le_vec): New. 138665 (_bfd_target_vector): Add amdgcn_elf64_le_vec. 138666 138667 include/ChangeLog: 138668 138669 * elf/amdgpu.h: New. 138670 * elf/common.h (ELFOSABI_AMDGPU_HSA): Add. 138671 138672 Change-Id: I969f7b14960797e88891c308749a6e341eece5b2 138673 1386742022-03-16 Nick Clifton <nickc@redhat.com> 138675 138676 Updated Serbian (for binutils/) and Russian (for gprof/) translations 138677 1386782022-03-16 Pedro Alves <pedro@palves.net> 138679 138680 Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserver 138681 gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were 138682 recently disabled unless testing with the native target, because they 138683 rely on inferior I/O. However, when testing against gdbserver using 138684 the native-gdbserver/native-extended-gdbserver boards, we do have 138685 access to inferior I/O. 138686 138687 The right way to check whether the board can do I/O, is via checking 138688 the gdb,noinferiorio board variable. Switch to using that. 138689 138690 And then, tweak the testcases to expect output to appear in 138691 inferior_spawn_id, instead of gdb_spawn_id. When testing against the 138692 native target, inferior_spawn_id is the same as gdb_spawn_id. When 138693 testing against gdbserver, it maps to gdbserver_spawn_id. 138694 138695 This exposed a buglet in gdb.fortran/array-slices.f90's show_1d 138696 subroutine -- it was missing printing newline at the end of the 138697 "Expected GDB Output" text, leading to a test timeout. All other 138698 subroutines end with advance=yes, except this one. Fix it by using 138699 advance=yes here too. 138700 138701 Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5 138702 1387032022-03-16 GDB Administrator <gdbadmin@sourceware.org> 138704 138705 Automatic date update in version.in 138706 1387072022-03-15 Alan Modra <amodra@gmail.com> 138708 138709 Delete PowerPC macro insn support 138710 Let's hope this stays dead, but it's here as a patch separate from 138711 those that removed use of powerpc_macros just in case it needs to be 138712 resurrected. 138713 138714 include/ 138715 * opcode/ppc.h (struct powerpc_macro): Delete declaration. 138716 (powerpc_macros, powerpc_num_macros): Likewise.. 138717 opcodes/ 138718 * ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete. 138719 gas/ 138720 * config/tc-ppc.c (ppc_macro): Delete function. 138721 (ppc_macro_hash): Delete. 138722 (ppc_setup_opcodes, md_assemble): Delete macro support. 138723 1387242022-03-15 Alan Modra <amodra@gmail.com> 138725 138726 PowerPC SPE/SPE2 aliases in powerpc_macros 138727 * ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs", 138728 "evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt", 138729 "evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui", 138730 "evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz", 138731 "evststgt", "evststlt", "evststeq".. 138732 (powerpc_opcodes): ..to here. 138733 (powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi", 138734 and "evdotpwsssia".. 138735 (spe2_opcodes): ..to here. 138736 1387372022-03-15 Alan Modra <amodra@gmail.com> 138738 138739 PowerPC VLE extended instructions in powerpc_macros 138740 This moves VLE insn out of the macro table. "e_slwi" and "e_srwi" 138741 already exist in vle_opcodes as distinct instructions rather than 138742 encodings of e_rlwinm. 138743 138744 opcodes/ 138745 * ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand. 138746 Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi", 138747 "e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi". 138748 (powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too. 138749 gas/ 138750 * testsuite/gas/ppc/vle-simple-5.d: Update. 138751 1387522022-03-15 Alan Modra <amodra@gmail.com> 138753 138754 PowerPC32 extended instructions in powerpc_macros 138755 As for PowerPC64, move instructions to the main opcode table. 138756 138757 opcodes/ 138758 * ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn), 138759 (insert_erwn, extract_erwn, insert_erwb, extract_erwb), 138760 (insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn), 138761 (insert_irwb, extract_irwn, insert_rrwn, extract_rrwn), 138762 (insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions. 138763 (CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb), 138764 (RRWn, SLWn, SRWn): Define and add powerpc_operands entries. 138765 (MMB_MASK, MME_MASK, MSHMB_MASK): Define. 138766 (powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi", 138767 "slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding 138768 record (ie. dot suffix) forms. 138769 (powerpc_macros): Delete same. 138770 gas/ 138771 * testsuite/gas/ppc/476.d: Update. 138772 * testsuite/gas/ppc/simpshft.d: Update. 138773 1387742022-03-15 Alan Modra <amodra@gmail.com> 138775 138776 PowerPC64 extended instructions in powerpc_macros 138777 The extended instructions implemented in powerpc_macros aren't used by 138778 the disassembler. That means instructions like "sldi r3,r3,2" appear 138779 in disassembly as "rldicr r3,r3,2,61", which is annoying since many 138780 other extended instructions are shown. 138781 138782 Note that some of the instructions moved out of the macro table to the 138783 opcode table won't appear in disassembly, because they are aliases 138784 rather than a subset of the underlying raw instruction. If enabled, 138785 rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all 138786 occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many 138787 occurrences in the case of clrlsldi if n <= b was added to the extract 138788 functions.) 138789 138790 The patch also fixes a small bug in opcode sanity checking. 138791 138792 include/ 138793 * opcode/ppc.h (PPC_OPSHIFT_SH6): Define. 138794 opcodes/ 138795 * ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn), 138796 (insert_crdn, extract_crdn, insert_rrdn, extract_rrdn), 138797 (insert_sldn, extract_sldn, insert_srdn, extract_srdn), 138798 (insert_erdb, extract_erdb, insert_csldn, extract_csldb), 138799 (insert_irdb, extract_irdn): New functions. 138800 (ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb): 138801 Define and add associated powerpc_operands entries. 138802 (powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi", 138803 "sldi", "extldi", "clrlsldi", "insrdi" and corresponding record 138804 (ie. dot suffix) forms. 138805 (powerpc_macros): Delete same from here. 138806 gas/ 138807 * config/tc-ppc.c (insn_validate): Don't modify value passed 138808 to operand->insert for PPC_OPERAND_PLUS1 when calculating mask. 138809 Handle PPC_OPSHIFT_SH6. 138810 * testsuite/gas/ppc/prefix-reloc.d: Update. 138811 * testsuite/gas/ppc/simpshft.d: Update. 138812 ld/ 138813 * testsuite/ld-powerpc/elfv2so.d: Update. 138814 * testsuite/ld-powerpc/notoc.d: Update. 138815 * testsuite/ld-powerpc/notoc3.d: Update. 138816 * testsuite/ld-powerpc/tlsdesc2.d: Update. 138817 * testsuite/ld-powerpc/tlsget.d: Update. 138818 * testsuite/ld-powerpc/tlsget2.d: Update. 138819 * testsuite/ld-powerpc/tlsopt5.d: Update. 138820 * testsuite/ld-powerpc/tlsopt6.d: Update. 138821 1388222022-03-15 Tom Tromey <tom@tromey.com> 138823 138824 Do not capture updated 'pc' in add_local_symbols 138825 Simon pointed out that commit 13835d88 ("Use function view when 138826 iterating over block symbols") caused a regression. The bug is that 138827 the new closure captures 'pc' by reference, but later code updates 138828 this variable -- but the earlier code did not update the callback 138829 structure with the new value. 138830 138831 This patch restores the old behavior by using a new varible name in an 138832 inner scope. 138833 1388342022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com> 138835 138836 gprofng: avoid using `fallthrough' attributes 138837 gprofng didn't build with gcc 6.3 due to the usage of __attribute__ 138838 ((fallthrough)). This patch uses /* FALLTHROUGH */ instead. 138839 138840 2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com> 138841 138842 * gprofng/src/gp-collect-app.cc (collect::check_args): Use 138843 fallthrough comment instead of attribute. 138844 1388452022-03-15 Tom Tromey <tromey@adacore.com> 138846 138847 Fix bug in dwarf-mode.el 138848 I noticed that, occasionally, dwarf-mode would think that the objdump 138849 subprocess was still running after it had clearly exited. I managed 138850 to reliably reproduce this today and learned that a process sentinel 138851 is not guaranteed to be run with the current buffer set to the process 138852 buffer. This patch fixes the problem. 138853 138854 I've bumped the version number of dwarf-mode.el to make it easier to 138855 install for users who already have an earlier one installed. 138856 138857 I'm checking this in. 138858 138859 2022-03-15 Tom Tromey <tromey@adacore.com> 138860 138861 * dwarf-mode.el: Now 1.7. 138862 (dwarf--sentinel): Switch to the process buffer. 138863 1388642022-03-15 Andrew Burgess <aburgess@redhat.com> 138865 138866 gdb/testsuite: rename a proc and fix a typo 138867 Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the 138868 old name was most likely a typo. The old name 138869 match_re_or_ensure_not_output seems (to me) to imply we're in some way 138870 checking that the regexp was not output. But that's not what we are 138871 doing, we're checking either for the regexp, or for no output, hence 138872 the new name match_re_or_ensure_no_output. 138873 138874 Additionally, I found a definite typo in one of the comments that I've 138875 also fixed. 138876 138877 I also updated some test names. These tests (probably due to copy & 138878 paste errors) has 'on MI' on their name, when they were actually 138879 checking CLI output. For these test I changed the name to use 'on 138880 CLI'. 138881 138882 There should be no change in what is tested after this commit. 138883 1388842022-03-15 Nick Clifton <nickc@redhat.com> 138885 138886 gprofng: Add a configure test for clock_gettime and a use of the test in getthrtime.c 138887 1388882022-03-15 H.J. Lu <hjl.tools@gmail.com> 138889 138890 gprofng: Don't generate gprofng.info in source 138891 Add info-in-builddir to AUTOMAKE_OPTIONS. 138892 138893 PR gprof/28967 138894 * doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir. 138895 * doc/Makefile.in: Regenerate. 138896 1388972022-03-15 Tiezhu Yang <yangtiezhu@loongson.cn> 138898 138899 gdb: LoongArch: fix failed testcases in gdb.base/align-c.exp 138900 When execute the following command on LoongArch: 138901 138902 make check-gdb TESTS="gdb.base/align-c.exp" 138903 138904 there exist some failed testcases: 138905 138906 ... 138907 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float) 138908 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double) 138909 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double) 138910 ... 138911 138912 According to LoongArch ELF ABI specification [1], set the target data types 138913 of floating-point to fix the above failed testcases. 138914 138915 [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html 138916 1389172022-03-15 GDB Administrator <gdbadmin@sourceware.org> 138918 138919 Automatic date update in version.in 138920 1389212022-03-14 Andrew Burgess <aburgess@redhat.com> 138922 138923 gdb/python/mi: create MI commands using python 138924 This commit allows a user to create custom MI commands using Python 138925 similarly to what is possible for Python CLI commands. 138926 138927 A new subclass of mi_command is defined for Python MI commands, 138928 mi_command_py. A new file, gdb/python/py-micmd.c contains the logic 138929 for Python MI commands. 138930 138931 This commit is based on work linked too from this mailing list thread: 138932 138933 https://sourceware.org/pipermail/gdb/2021-November/049774.html 138934 138935 Which has also been previously posted to the mailing list here: 138936 138937 https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html 138938 138939 And was recently reposted here: 138940 138941 https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html 138942 138943 The version in this patch takes some core code from the previously 138944 posted patches, but also has some significant differences, especially 138945 after the feedback given here: 138946 138947 https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html 138948 138949 A new MI command can be implemented in Python like this: 138950 138951 class echo_args(gdb.MICommand): 138952 def invoke(self, args): 138953 return { 'args': args } 138954 138955 echo_args("-echo-args") 138956 138957 The 'args' parameter (to the invoke method) is a list 138958 containing (almost) all command line arguments passed to the MI 138959 command (--thread and --frame are handled before the Python code is 138960 called, and removed from the args list). This list can be empty if 138961 the MI command was passed no arguments. 138962 138963 When used within gdb the above command produced output like this: 138964 138965 (gdb) 138966 -echo-args a b c 138967 ^done,args=["a","b","c"] 138968 (gdb) 138969 138970 The 'invoke' method of the new command must return a dictionary. The 138971 keys of this dictionary are then used as the field names in the mi 138972 command output (e.g. 'args' in the above). 138973 138974 The values of the result returned by invoke can be dictionaries, 138975 lists, iterators, or an object that can be converted to a string. 138976 These are processed recursively to create the mi output. And so, this 138977 is valid: 138978 138979 class new_command(gdb.MICommand): 138980 def invoke(self,args): 138981 return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 138982 'result_two': [ { 'a': 1, 'b': 2 }, 138983 { 'c': 3, 'd': 4 } ] } 138984 138985 Which produces output like: 138986 138987 (gdb) 138988 -new-command 138989 ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] 138990 (gdb) 138991 138992 I have required that the fields names used in mi result output must 138993 match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). 138994 This restriction was never written down anywhere before, but seems 138995 sensible to me, and we can always loosen this rule later if it proves 138996 to be a problem. Much harder to try and add a restriction later, once 138997 people are already using the API. 138998 138999 What follows are some details about how this implementation differs 139000 from the original patch that was posted to the mailing list. 139001 139002 In this patch, I have changed how the lifetime of the Python 139003 gdb.MICommand objects is managed. In the original patch, these object 139004 were kept alive by an owned reference within the mi_command_py object. 139005 As such, the Python object would not be deleted until the 139006 mi_command_py object itself was deleted. 139007 139008 This caused a problem, the mi_command_py were held in the global mi 139009 command table (in mi/mi-cmds.c), which, as a global, was not cleared 139010 until program shutdown. By this point the Python interpreter has 139011 already been shutdown. Attempting to delete the mi_command_py object 139012 at this point was causing GDB to try and invoke Python code after 139013 finalising the Python interpreter, and we would crash. 139014 139015 To work around this problem, the original patch added code in 139016 python/python.c that would search the mi command table, and delete the 139017 mi_command_py objects before the Python environment was finalised. 139018 139019 In contrast, in this patch, I have added a new global dictionary to 139020 the gdb module, gdb._mi_commands. We already have several such global 139021 data stores related to pretty printers, and frame unwinders. 139022 139023 The MICommand objects are placed into the new gdb.mi_commands 139024 dictionary, and it is this reference that keeps the objects alive. 139025 When GDB's Python interpreter is shut down gdb._mi_commands is deleted, 139026 and any MICommand objects within it are deleted at this point. 139027 139028 This change avoids having to make the mi_cmd_table global, and walk 139029 over it from within GDB's python related code. 139030 139031 This patch handles command redefinition entirely within GDB's python 139032 code, though this does impose one small restriction which is not 139033 present in the original code (detailed below), I don't think this is a 139034 big issue. However, the original patch relied on being able to 139035 finish executing the mi_command::do_invoke member function after the 139036 mi_command object had been deleted. Though continuing to execute a 139037 member function after an object is deleted is well defined, it is 139038 also (IMHO) risky, its too easy for someone to later add a use of the 139039 object without realising that the object might sometimes, have been 139040 deleted. The new patch avoids this issue. 139041 139042 The one restriction that is added to avoid this, is that an MICommand 139043 object can't be reinitialised with a different command name, so: 139044 139045 (gdb) python cmd = MyMICommand("-abc") 139046 (gdb) python cmd.__init__("-def") 139047 can't reinitialize object with a different command name 139048 139049 This feels like a pretty weird edge case, and I'm happy to live with 139050 this restriction. 139051 139052 I have also changed how the memory is managed for the command name. 139053 In the most recently posted patch series, the command name is moved 139054 into a subclass of mi_command, the python mi_command_py, which 139055 inherits from mi_command is then free to use a smart pointer to manage 139056 the memory for the name. 139057 139058 In this patch, I leave the mi_command class unchanged, and instead 139059 hold the memory for the name within the Python object, as the lifetime 139060 of the Python object always exceeds the c++ object stored in the 139061 mi_cmd_table. This adds a little more complexity in py-micmd.c, but 139062 leaves the mi_command class nice and simple. 139063 139064 Next, this patch adds some extra functionality, there's a 139065 MICommand.name read-only attribute containing the name of the command, 139066 and a read-write MICommand.installed attribute that can be used to 139067 install (make the command available for use) and uninstall (remove the 139068 command from the mi_cmd_table so it can't be used) the command. This 139069 attribute will be automatically updated if a second command replaces 139070 an earlier command. 139071 139072 This patch adds additional error handling, and makes more use the 139073 gdbpy_handle_exception function. 139074 139075 Co-Authored-By: Jan Vrany <jan.vrany@labware.com> 139076 1390772022-03-14 Andrew Burgess <aburgess@redhat.com> 139078 139079 gdb/gdbarch: compare some fields against 0 verify_gdbarch 139080 After the previous commit, which removes the predicate function 139081 gdbarch_register_type_p, I noticed that the gdbarch->register_type 139082 field was not checked at in the verify_gdbarch function. 139083 139084 More than not being checked, the field wasn't mentioned at all. 139085 139086 I find this strange, I would expect that every field would at least be 139087 mentioned - we already generate comments for some fields saying that 139088 this field is _not_ being checked, so the fact that this field isn't 139089 being checked looks (to me), like this field is somehow slipping 139090 through the cracks. 139091 139092 The comment at the top of gdbarch-components.py tries to explain how 139093 the validation is done. I didn't understand this comment completely, 139094 but, I think this final sentence: 139095 139096 "Otherwise, the check is done against 0 (really NULL for function 139097 pointers, but same idea)." 139098 139099 Means that, if non of the other cases apply, then the field should be 139100 checked against 0, with 0 indicating that the field is invalid (was 139101 not set by the tdep code). However, this is clearly not being done. 139102 139103 Looking in gdbarch.py at the code to generate verify_gdbarch we do 139104 find that there is a case that is not handled, the case where the 139105 'invalid' field is set true True, but non of the other cases apply. 139106 139107 In this commit I propose two changes: 139108 139109 1. Handle the case where the 'invalid' field of a property is set to 139110 True, this should perform a check for the field of gdbarch still 139111 being set to 0, and 139112 139113 2. If the if/else series that generates verify_gdbarch doesn't handle 139114 a property then we should raise an exception. This means that if a 139115 property is added which isn't handled, we should no longer silently 139116 ignore it. 139117 139118 After doing this, I re-generated the gdbarch files and saw that the 139119 following gdbarch fields now had new validation checks: 139120 139121 register_type 139122 believe_pcc_promotion 139123 register_to_value 139124 value_to_register 139125 frame_red_zone_size 139126 displaced_step_restore_all_in_ptid 139127 solib_symbols_extension 139128 139129 Looking at how these are currently set in the various -tdep.c files, I 139130 believe the only one of these that is required to be set for all 139131 architectures is the register_type field. 139132 139133 And so, for all of the other fields, I've changed the property 139134 definition on gdbarch-components.py, setting the 'invalid' field to 139135 False. 139136 139137 Now, after re-generation, the register_type field is checked against 139138 0, thus an architecture that doesn't set_gdbarch_register_type will 139139 now fail during validation. For all the other fields we skip the 139140 validation, in which case, it is find for an architecture to not set 139141 this field. 139142 139143 My expectation is that there should be no user visible changes after 139144 this commit. Certainly for all fields except register_type, all I've 139145 really done is cause some extra comments to be generated, so I think 139146 that's clearly fine. 139147 139148 For the register_type field, my claim is that any architecture that 139149 didn't provide this would fail when creating its register cache, and I 139150 couldn't spot an architecture that doesn't provide this hook. As 139151 such, I think this change should be fine too. 139152 1391532022-03-14 Andrew Burgess <aburgess@redhat.com> 139154 139155 gdb/gdbarch: remove the predicate function for gdbarch_register_type 139156 I don't believe that the gdbarch_register_type_p predicate is called 139157 anywhere in GDB, and the gdbarch_register_type function is called 139158 without checking the gdbarch_register_type_p predicate function 139159 everywhere it is used, for example in 139160 init_regcache_descr (regcache.c). 139161 139162 My claim is that the gdbarch_register_type function is required for 139163 every architecture, and GDB will not work if this function is not 139164 supplied. 139165 139166 And so, in this commit, I remove the 'predicate=True' from 139167 gdbarch-components.py for the 'register_type' field, and regenerate 139168 the gdbarch files. 139169 139170 There should be no user visible changes after this commit. 139171 1391722022-03-14 Patrick Monnerat <patrick@monnerat.net> 139173 139174 Replace deprecated_target_wait_hook by observers 139175 Commit b60cea7 (Make target_wait options use enum flags) broke 139176 deprecated_target_wait_hook usage: there's a commit comment telling 139177 this hook has not been converted. 139178 139179 Rather than trying to mend it, this patch replaces the hook by two 139180 target_wait observers: 139181 139182 target_pre_wait (ptid_t ptid) 139183 target_post_wait (ptid_t event_ptid) 139184 139185 Upon target_wait entry, target_pre_wait is notified with the ptid 139186 passed to target_wait. Upon exit, target_post_wait is notified with 139187 the event ptid returned by target_wait. Should an exception occur, 139188 event_ptid is null_ptid. 139189 139190 This change benefits to Insight (out-of-tree): there's no real use of the 139191 late hook in gdb itself. 139192 1391932022-03-14 Tom Tromey <tromey@adacore.com> 139194 139195 Correctly print subrange types in generic_value_print 139196 I noticed that generic_value_print assumes that a subrange type is 139197 always a subrange of an integer type. However, this isn't necessarily 139198 the case. In Ada, for example, one has subranges of character and 139199 enumeration types. 139200 139201 This code isn't often exercised, I think, because languages with real 139202 subrange types tend to implement their own printers. However, it 139203 still seemed worth fixing. 139204 1392052022-03-14 Luis Machado <luis.machado@arm.com> 139206 139207 [aarch64/arm] Properly extract the return value returned in memory 139208 When running gdb.cp/non-trivial-retval.exp, the following shows up for 139209 both aarch64-linux and armhf-linux: 139210 139211 Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 139212 35 A a; 139213 (gdb) finish 139214 Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 139215 main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163 139216 163 B b = f2 (i1, i2); 139217 Value returned is $6 = {a = -11952} 139218 (gdb) 139219 139220 The return value should be {a = 123} instead. This happens because the 139221 backends don't extract the return value from the correct location. GDB should 139222 fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf. 139223 139224 With the patch, gdb.cp/non-trivial-retval.exp has full passes on 139225 aarch64-linux and armhf-linux on Ubuntu 20.04/18.04. 139226 139227 The problem only shows up with the "finish" command. The "call" command 139228 works correctly and displays the correct return value. 139229 139230 This is also related to PR gdb/28681 139231 (https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in 139232 gdb.ada/mi_var_array.exp. 139233 139234 A new testcase is provided, and it exercises GDB's ability to "finish" a 139235 function that returns a large struct (> 16 bytes) and display the 139236 contents of this struct correctly. This has always been incorrect for 139237 these backends, but no testcase exercised this particular scenario. 139238 1392392022-03-14 GDB Administrator <gdbadmin@sourceware.org> 139240 139241 Automatic date update in version.in 139242 1392432022-03-13 Alan Modra <amodra@gmail.com> 139244 139245 PR28959, obdump doesn't disassemble mftb instruction 139246 Without a -M cpu option given, powerpc objdump defaults currently to 139247 -Mpower10 but -Many is also given. Commit 1ff6a3b8e562 regressed 139248 -Many disassembly of instructions that are encoded differently 139249 depending on cpu, such as mftb which has pre- and post-power4 139250 encodings. 139251 139252 PR 28959 139253 * ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change. Instead 139254 only look at deprecated PPC_OPCODE_RAW bit when -Many. 139255 1392562022-03-13 GDB Administrator <gdbadmin@sourceware.org> 139257 139258 Automatic date update in version.in 139259 1392602022-03-12 Tom Tromey <tom@tromey.com> 139261 139262 Relax regexp in gdb.rust/unsized.exp 139263 With nightly rustc, gdb.rust/unsized.exp fails: 139264 139265 (gdb) ptype *us 139266 Structure has no component named operator*. 139267 139268 rustc changed to emit a bit more debug info for unsized types. 139269 Because the original test is just to make sure that ptype of an 139270 unsized array looks right, this patch relaxes the regexp and changes 139271 the expression. I think this keeps the original test meaning, but 139272 also works with nightly. I also tested stable and 1.48. 139273 1392742022-03-12 GDB Administrator <gdbadmin@sourceware.org> 139275 139276 Automatic date update in version.in 139277 1392782022-03-11 Tom Tromey <tromey@adacore.com> 139279 139280 Avoid crash with cross-linux core file 139281 An internal test case creates a core file using gcore, then restarts 139282 gdb with that core. When run with a cross-linux gdb (in this case, 139283 x86-64 host with ppc64-linux target), the test fails: 139284 139285 | (gdb) core core 139286 | [New LWP 18437] 139287 | warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. 139288 | warning: Could not load shared library symbols for /lib64/ld64.so.1. 139289 | Do you need "set solib-search-path" or "set sysroot"? 139290 | ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed. 139291 | A problem internal to GDB has been detected, 139292 | further debugging may prove unreliable. 139293 | Quit this debugging session? (y or n) y 139294 139295 What's happening here is that the core file lists some shared 139296 libraries. These aren't available via the solib search path, and so 139297 gdb finds the local (x86-64) libraries. This is not ideal, but on the 139298 other hand, it is what was asked for -- while the test does set 139299 solib-search-path, it does not set the sysroot. 139300 139301 But, because gdb isn't configured to handle these libraries, it 139302 crashes. 139303 139304 It seems to me that it's better to avoid the crash by having 139305 solib_bfd_open fail in the case where a library is incompatible. That 139306 is what this patch does. Now it looks like: 139307 139308 | [New LWP 15488] 139309 | Error while mapping shared library sections: 139310 | `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. 139311 139312 ... and does not crash gdb. 139313 139314 I don't have a good setup for testing this using dejagnu, so I don't 139315 know whether an existing gdb test covers this scenario. 139316 1393172022-03-11 Andrew Burgess <aburgess@redhat.com> 139318 139319 gdb/testsuite: remove duplicates from gdb.base/stap-probe.exp 139320 Remove the duplicate test names from gdb.base/stap-probe.exp, this is 139321 done by actually passing a unique test name in a couple of 139322 places (rather than using the command as the test name), and in 139323 another couple of places, a test has a duplicate name due to a cut & 139324 paste error, which I've fixed. 139325 139326 There's no change in what is actually being tested after this commit. 139327 1393282022-03-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 139329 139330 gprofng: a new GNU profiler 139331 top-level 139332 * Makefile.def: Add gprofng module. 139333 * configure.ac: Add --enable-gprofng option. 139334 * src-release.sh: Add gprofng. 139335 * Makefile.in: Regenerate. 139336 * configure: Regenerate. 139337 * gprofng: New directory. 139338 139339 binutils 139340 * MAINTAINERS: Add gprofng maintainer. 139341 * README-how-to-make-a-release: Add gprofng. 139342 139343 include. 139344 * collectorAPI.h: New file. 139345 * libcollector.h: New file. 139346 * libfcollector.h: New file. 139347 1393482022-03-11 GDB Administrator <gdbadmin@sourceware.org> 139349 139350 Automatic date update in version.in 139351 1393522022-03-10 Aaron Merey <amerey@redhat.com> 139353 139354 gdb/auto-load: Remove repeating "auto-load" from debug message 139355 Remove "auto-load:" from a format string passed to auto_load_debug_printf. 139356 It is unnecessary since this function will prefix the string with "[auto-load]" 139357 when printing it. 139358 1393592022-03-10 Tom Tromey <tromey@adacore.com> 139360 139361 Change how "print/x" displays floating-point value 139362 Currently, "print/x" will display a floating-point value by first 139363 casting it to an integer type. This yields weird results like: 139364 139365 (gdb) print/x 1.5 139366 $1 = 0x1 139367 139368 This has confused users multiple times -- see PR gdb/16242, where 139369 there are several dups. I've also seen some confusion from this 139370 internally at AdaCore. 139371 139372 The manual says: 139373 139374 'x' 139375 Regard the bits of the value as an integer, and print the integer 139376 in hexadecimal. 139377 139378 ... which seems more useful. So, perhaps what happened is that this 139379 was incorrectly implemented (or maybe correctly implemented and then 139380 regressed, as there don't seem to be any tests). 139381 139382 This patch fixes the bug. 139383 139384 There was a previous discussion where we agreed to preserve the old 139385 behavior: 139386 139387 https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html 139388 139389 However, I think it makes more sense to follow the manual. 139390 139391 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242 139392 1393932022-03-10 Tom Tromey <tromey@adacore.com> 139394 139395 Simplify the ui-out progress API 139396 I noticed that 'progress' is a method on ui-out, but it seems to me 139397 that it would be better if the only API were via the progress_meter 139398 class. This patch makes this change, changing progress to be a method 139399 on the meter itself. 139400 1394012022-03-10 Andrew Burgess <aburgess@redhat.com> 139402 139403 gdb/gdbarch: fix typo in gdbarch-components.py 139404 Fixes a minor typo, in a comment, in the gdbarch-components.py script. 139405 139406 There should be no user visible changes after this commit. 139407 1394082022-03-10 Lancelot SIX <lancelot.six@amd.com> 139409 139410 Process exit status is leader exit status testcase 139411 This adds a multi-threaded testcase that has all threads in the 139412 process exit with a different exit code, and ensures that GDB reports 139413 the thread group leader's exit status as the whole-process exit 139414 status. Before this set of patches, this would randomly report the 139415 exit code of some other thread, and thus fail. 139416 139417 Tested on Linux-x86_64, native and gdbserver. 139418 139419 Co-Authored-By: Pedro Alves <pedro@palves.net> 139420 Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557 139421 1394222022-03-10 Pedro Alves <pedro@palves.net> 139423 139424 Re-add zombie leader on exit, gdbserver/linux 139425 Same as the previous patch, but for GDBserver. 139426 139427 In summary, the current zombie leader detection code in linux-low.cc 139428 has a race -- if a multi-threaded inferior exits just before 139429 check_zombie_leaders finds that the leader is now zombie via checking 139430 /proc/PID/status, check_zombie_leaders deletes the leader, assuming we 139431 won't get an event for that exit (which we won't in some scenarios, 139432 but not in this one), which is a false-positive scenario, where the 139433 whole process is simply exiting. Later when we see the last LWP in 139434 our list exit, we report that LWP's exit status as exit code, even 139435 though for the (real) parent process, the exit code that counts is the 139436 child's leader thread's exit code. 139437 139438 Like for GDB, the solution here is to: 139439 139440 - only report whole-process exit events for the leader. 139441 - re-add the leader back to the LWP list when we finally see it 139442 exit. 139443 139444 Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d 139445 1394462022-03-10 Pedro Alves <pedro@palves.net> 139447 139448 Re-add zombie leader on exit, gdb/linux 139449 The current zombie leader detection code in linux-nat.c has a race -- 139450 if a multi-threaded inferior exits just before check_zombie_leaders 139451 finds that the leader is now zombie via checking /proc/PID/status, 139452 check_zombie_leaders deletes the leader, assuming we won't get an 139453 event for that exit (which we won't in some scenarios, but not in this 139454 one). That might seem mostly harmless, but it has some downsides: 139455 139456 - later when we continue pulling events out of the kernel, we will 139457 collect the exit event of the non-leader threads, and once we see 139458 the last lwp in our list exit, we return _that_ lwp's exit code as 139459 whole-process exit code to infrun, instead of the leader's exit 139460 code. 139461 139462 - this can cause a hang in stop_all_threads in infrun.c. Say there 139463 are 2 threads in the process. stop_all_threads stops each of those 139464 threads, and then waits for two stop or exit events, one for each 139465 thread. If the whole process exits, and check_zombie_leaders hits 139466 the false-positive case, linux-nat.c will only return one event to 139467 GDB (the whole-process exit returned when we see the last thread, 139468 the non-leader thread, exit), making stop_all_threads hang forever 139469 waiting for a second event that will never come. 139470 139471 However, in this false-positive scenario, where the whole process is 139472 exiting, as opposed to just the leader (with pthread_exit(), for 139473 example), we _will_ get an exit event shortly for the leader, after we 139474 collect the exit event of all the other non-leader threads. Or put 139475 another way, we _always_ get an event for the leader after we see it 139476 become zombie. 139477 139478 I tried a number of approaches to fix this: 139479 139480 #1 - My first thought to address the race was to make GDB always 139481 report the whole-process exit status for the leader thread, not for 139482 whatever is the last lwp in the list. We _always_ get a final exit 139483 (or exec) event for the leader, and when the race triggers, we're not 139484 collecting it. 139485 139486 #2 - My second thought was to try to plug the race in the first place. 139487 139488 I thought of making GDB call waitpid/WNOHANG for all non-leader 139489 threads immediately when the zombie leader is detected, assuming there 139490 would be an exit event pending for each of them waiting to be 139491 collected. Turns out that that doesn't work -- you can see the leader 139492 become zombie _before_ the kernel kills all other threads. Waitpid in 139493 that small time window returns 0, indicating no-event. Thankfully we 139494 hit that race window all the time, which avoided trading one race for 139495 another. Looking at the non-leader thread's status in /proc doesn't 139496 help either, the threads are still in running state for a bit, for the 139497 same reason. 139498 139499 #3 - My next attempt, which seemed promising, was to synchronously 139500 stop and wait for the stop for each of the non-leader threads. For 139501 the scenario in question, this will collect all the exit statuses of 139502 the non-leader threads. Then, if we are left with only the zombie 139503 leader in the lwp list, it means we either have a normal while-process 139504 exit or an exec, in which case we should not delete the leader. If 139505 _only_ the leader exited, like in gdb.threads/leader-exit.exp, then 139506 after pausing threads, we will still have at least one live non-leader 139507 thread in the list, and so we delete the leader lwp. I got this 139508 working and polished, and it was only after staring at the kernel code 139509 to convince myself that this would really work (and it would, for the 139510 scenario I considered), that I realized I had failed to account for 139511 one scenario -- if any non-leader thread is _already_ stopped when 139512 some thread triggers a group exit, like e.g., if you have some threads 139513 stopped and then resume just one thread with scheduler-locking or 139514 non-stop, and that thread exits the process. I also played with 139515 PTRACE_EVENT_EXIT, see if it would help in any way to plug the race, 139516 and I couldn't find a way that it would result in any practical 139517 difference compared to looking at /proc/PID/status, with respect to 139518 having a race. 139519 139520 So I concluded that there's no way to plug the race, we just have to 139521 deal with it. Which means, going back to approach #1. That is the 139522 approach taken by this patch. 139523 139524 Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979 139525 1395262022-03-10 Pedro Alves <pedro@palves.net> 139527 139528 gdbserver: Reindent check_zombie_leaders 139529 This fixes the indentation of 139530 linux_process_target::check_zombie_leaders, which will help with 139531 keeping its comments in sync with the gdb/linux-nat.c counterpart. 139532 139533 Change-Id: I37332343bd80423d934249e3de2d04feefad1891 139534 1395352022-03-10 Pedro Alves <pedro@palves.net> 139536 139537 gdbserver: Reorganize linux_process_target::filter_event 139538 Reorganize linux-low.cc:linux_process_target::filter_event such that 139539 all the handling for events for LWPs not in the LWP list is together. 139540 This helps make a following patch clearer. The comments and debug 139541 messages have also been tweaked to have them synchronized with the GDB 139542 counterpart. 139543 139544 Change-Id: If9019635f63a846607cfda44b454b4254a404019 139545 1395462022-03-10 Pedro Alves <pedro@palves.net> 139547 139548 gdb: Reorganize linux_nat_filter_event 139549 Reorganize linux-nat.c:linux_nat_filter_event such that all the 139550 handling for events for LWPs not in the LWP list is together. This 139551 helps make a following patch clearer. The comments and debug messages 139552 have also been tweaked - the end goal is to have them synchronized 139553 with the gdbserver counterpart. 139554 139555 Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22 139556 1395572022-03-10 Pedro Alves <pedro@palves.net> 139558 139559 Fix gdb.threads/current-lwp-dead.exp race 139560 If we make GDB report the process EXIT event for the leader thread, as 139561 will be done in a latter patch of this series, then 139562 gdb.threads/current-lwp-dead.exp starts failing: 139563 139564 (gdb) break fn_return 139565 Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45. 139566 (gdb) continue 139567 Continuing. 139568 [New LWP 2138466] 139569 [Inferior 1 (process 2138459) exited normally] 139570 (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited) 139571 139572 The inferior exit reported is actually correct. The main thread has 139573 indeed exited, and that's the thread that has the right exit code to 139574 report to the user, as that's the exit code that is reported to the 139575 program's parent. In this case, GDB managed to collect the exit code 139576 for the leader thread before reaping the other thread, because in 139577 reality, the testcase isn't creating standard threads, it is using raw 139578 clone, and the new clones are put in their own thread group. 139579 139580 Fix it by making the main "thread" not exit until the scenario we're 139581 exercising plays out. Also, run the program to completion for 139582 completeness. 139583 139584 The original program really wanted the leader thread to exit before 139585 the fn_return function was reached -- it was important that the 139586 current thread as pointed by inferior_ptid was gone when infrun got 139587 the breakpoint event. I've tweaked the testcase to ensure that that 139588 condition is still held, though it is no longer the main thread that 139589 exits. This required a bit of synchronization between the threads, 139590 which required using CLONE_VM unconditionally. The #ifdef guards were 139591 added as a fix for 139592 https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't 139593 think they were necessary because the program is not using TLS. If it 139594 turns out they were necessary, we can link the testcase with "-z now" 139595 instead, which was mentioned as an alternative workaround in that 139596 Bugzilla. 139597 139598 Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa 139599 1396002022-03-10 Pedro Alves <pedro@palves.net> 139601 139602 Fix gdb.threads/clone-new-thread-event.exp race 139603 If we make GDB report the process EXIT event for the leader thread, 139604 instead of whatever is the last thread in the LWP list, as will be 139605 done in a latter patch of this series, then 139606 gdb.threads/current-lwp-dead.exp starts failing: 139607 139608 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited) 139609 139610 This is a testcase race -- the main thread does not wait for the 139611 spawned clone "thread" to finish before exiting, so the main program 139612 may exit before the second thread is scheduled and reports its 139613 SIGUSR1. With the change to make GDB report the EXIT for the leader, 139614 the race is 100% reproducible by adding a sleep(), like so: 139615 139616 --- c/gdb/testsuite/gdb.threads/clone-new-thread-event.c 139617 +++ w/gdb/testsuite/gdb.threads/clone-new-thread-event.c 139618 @@ -51,6 +51,7 @@ local_gettid (void) 139619 static int 139620 fn (void *unused) 139621 { 139622 + sleep (1); 139623 tkill (local_gettid (), SIGUSR1); 139624 return 0; 139625 } 139626 139627 Resulting in: 139628 139629 Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65 139630 65 stack = malloc (STACK_SIZE); 139631 (gdb) continue 139632 Continuing. 139633 [New LWP 3715562] 139634 [Inferior 1 (process 3715555) exited normally] 139635 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited) 139636 139637 That inferior exit reported is actually correct. The main thread has 139638 indeed exited, and that's the thread that has the right exit code to 139639 report to the user, as that's the exit code that is reported to the 139640 program's parent. In this case, GDB managed to collect the exit code 139641 for the leader thread before reaping the other thread, because in 139642 reality, the testcase isn't creating standard threads, it is using raw 139643 clone, and the new clones are put in their own thread group. 139644 139645 Fix it by making the main thread wait for the child to exit. Also, 139646 run the program to completion for completeness. 139647 139648 Change-Id: I315cd3dc2b9e860395dcab9658341ea868d7a6bf 139649 1396502022-03-10 Pedro Alves <pedro@palves.net> 139651 139652 Fix gdbserver/linux target_waitstatus logging assert 139653 Turning on debug output in gdbserver leads to an assertion failure if 139654 gdbserver reports a non-signal event: 139655 139656 [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1 139657 [threads] wait_1: Hit a non-gdbserver trap event. 139658 ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected. 139659 sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed. 139660 139661 Fix it in the obvious way, using target_waitstatus::to_string(), 139662 resulting in, for example: 139663 139664 [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP 139665 139666 Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645 139667 1396682022-03-10 Nick Clifton <nickc@redhat.com> 139669 139670 Add option to objdump/readelf to disable access to debuginfod servers. 139671 * dwarf.c (use_debuginfod): New variable. Set to 1. 139672 (load_separate_debug_info): Only call 139673 debuginfod_fetch_separate_debug_info is use_debuginfod is true. 139674 (dwarf_select_sections_by_names): Add do-not-use-debuginfod and 139675 use-debuginfod options. 139676 (dwarf_select_sections_by_letters): Add D and E options. 139677 * dwarf.h (use_debuginfod): New extern. 139678 * objdump.c (usage): Mention the new options. 139679 * readelf.c (usage): Likewise. 139680 * doc/binutils.texi: Document the new options. 139681 * doc/debug-options.texi: Describe the new options. 139682 * NEWS: Mention the new feature. 139683 * testsuite/binutils-all/debuginfod.exp: Add tests of the new 139684 options. 139685 1396862022-03-10 Alan Modra <amodra@gmail.com> 139687 139688 Re: ld: Add a before_plugin_all_symbols_read hook 139689 * testsuite/ld-plugin/pr28849.d: Adjust for powerpc64 function 139690 descriptors. 139691 1396922022-03-10 H.J. Lu <hjl.tools@gmail.com> 139693 139694 ld: Add a before_plugin_all_symbols_read hook 139695 Add a before_plugin_all_symbols_read hook to load symbol references from 139696 DT_NEEDED entries, included from --copy-dt-needed-entries, before reading 139697 plugin symbols to properly resolve plugin symbol references. 139698 139699 bfd/ 139700 139701 PR ld/28849 139702 * elf-bfd.h (elf_link_hash_table): Add handling_dt_needed. 139703 * elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic 139704 before plugin 'all symbols read' hook is called. 139705 139706 ld/ 139707 139708 PR ld/28849 139709 * ldelf.c (ldelf_handle_dt_needed): New function. 139710 (ldelf_before_plugin_all_symbols_read): Likewise. 139711 (ldelf_after_open): Call ldelf_handle_dt_needed. 139712 * ldelf.h (ldelf_before_plugin_all_symbols_read): New. 139713 * ldemul.c (ldemul_before_plugin_all_symbols_read): Likewise. 139714 * ldemul.h (ldemul_before_plugin_all_symbols_read): Likewise. 139715 (ld_emulation_xfer_struct): Add before_plugin_all_symbols_read. 139716 * ldlang.c (lang_process): Call 139717 ldemul_before_plugin_all_symbols_read before calling 139718 plugin_call_all_symbols_read. 139719 * emultempl/elf.em 139720 (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New. 139721 (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): New. 139722 * emultempl/emulation.em (ld_${EMULATION_NAME}_emulation): 139723 Initialize the before_plugin_all_symbols_read field. 139724 * testsuite/ld-plugin/lto.exp: Run PR ld/28849 tests. 139725 * testsuite/ld-plugin/pr28849.d: New file. 139726 * testsuite/ld-plugin/pr28849a.c: Likewise. 139727 * testsuite/ld-plugin/pr28849b.c: Likewise. 139728 1397292022-03-10 GDB Administrator <gdbadmin@sourceware.org> 139730 139731 Automatic date update in version.in 139732 1397332022-03-09 Hans-Peter Nilsson <hp@axis.com> 139734 139735 toplevel: Makefile.def: Make configure-sim depend on all-readline 139736 Without this, a "make all-sim" without the equivalent of 139737 libreadline-dev installed on the build system, won't 139738 properly pick up the in-tree readline build, and you'll see: 139739 139740 mkdir -p -- ./sim 139741 Configuring in ./sim 139742 configure: creating cache ./config.cache 139743 checking build system type... x86_64-pc-linux-gnu 139744 checking host system type... x86_64-pc-linux-gnu 139745 checking target system type... cris-axis-elf 139746 checking for x86_64-pc-linux-gnu-gcc... gcc 139747 checking whether the C compiler works... yes 139748 ... 139749 checking for library containing tgetent... -ltermcap 139750 checking for readline in -lreadline... no 139751 configure: error: the required "readline" library is missing 139752 make[1]: *** [Makefile:11188: configure-sim] Error 1 139753 make[1]: Leaving directory '/home/hp/sim/b' 139754 139755 The sim dependency on readline is apparently (nominally) 139756 valid as there's a readline call in sim/erc32/sis.c. 139757 139758 2022-02-21 Hans-Peter Nilsson <hp@axis.com> 139759 139760 * Makefile.def (dependencies): Make configure-sim depend on 139761 all-readline. 139762 1397632022-03-09 Maciej W. Rozycki <macro@embecosm.com> 139764 139765 GDB/testsuite: Fix a "displayed" typo in gdb.base/default.exp 139766 Fix a typo, s/dislayed/displayed/ in default.exp at the top level. 139767 139768 GDB/testsuite: Remove a stray backslash from gdb.base/settings.exp 139769 Remove a stray trailing backslash from `test-integer' in settings.exp. 139770 It is harmless as only white space follows in the next line before the 139771 closing brace, so it merely swallows the newline character, but it may 139772 look confusing to the reader. 139773 1397742022-03-09 Christina Schimpe <christina.schimpe@intel.com> (tiny change) 139775 139776 * gdb/doc/gdb.texinfo (Requirements): Fix a typo. 139777 1397782022-03-09 Alan Modra <amodra@gmail.com> 139779 139780 Constant fold view increment expressions 139781 The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3. 139782 139783 * dwarf2dbg.c (set_or_check_view): Remove useless assertion. 139784 Resolve multiple view increments. 139785 * testsuite/gas/elf/dwarf2-18.d: Don't xfail mep. 139786 1397872022-03-09 Alan Modra <amodra@gmail.com> 139788 139789 Reduce duplicated symbol_clone_if_forward_ref work 139790 * symbol.c (struct symbol_flags): Add forward_resolved. 139791 (symbol_entry_find): Update needle initialisation. 139792 (symbol_clone_if_forward_ref): Do no work when forward_resolved 139793 is already set. Set forward_resolved. 139794 1397952022-03-09 Aaron Merey <amerey@redhat.com> 139796 139797 gdb: Try searching for auto-load script using .gnu_debuglink 139798 If an auto-load script cannot be found and objfile is a separate 139799 debuginfo whose filename does not match the name found in the parent 139800 file's .gnu_debuglink section, then repeat the search using the 139801 parent's filename where the last component is replaced with the 139802 .gnu_debuglink name. 139803 139804 For example if the parent's filename is "/usr/lib/libxyz.so" and the 139805 name in its .gnu_debuglink section is "libxyz.so.debug", then 139806 if no auto-load script is otherwise found the search will be 139807 repeated with the filename "/usr/lib/libxyz.so.debug". 139808 139809 This helps gdb locate auto-load scripts when debuginfo files do not have 139810 the expected filename, such as when they are aquired from debuginfod. 139811 1398122022-03-09 GDB Administrator <gdbadmin@sourceware.org> 139813 139814 Automatic date update in version.in 139815 1398162022-03-08 Aaron Merey <amerey@redhat.com> 139817 139818 PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source 139819 Source files downloaded from debuginfod currently use their original DWARF 139820 filename as their "fullname". This causes a mismatch between the fullname 139821 and the actual location of the source file in the debuginfod client cache. 139822 139823 MI consumers such as VSCode will fail to open debuginfod-downloaded 139824 source files due to this. Also 'info source' will fail to include the 139825 true paths of these files. 139826 139827 To fix this, use the debuginfod cache path as the fullname for debuginfod- 139828 downloaded source files. 139829 1398302022-03-08 Jan Vrany <jan.vrany@labware.com> 139831 139832 gdb/mi: preserve user selected thread and frame when invoking MI commands 139833 Fix for PR gdb/20684. When invoking MI commands with --thread and/or 139834 --frame, the user selected thread and frame was not preserved: 139835 139836 (gdb) 139837 info thread 139838 &"info thread\n" 139839 ~" Id Target Id Frame \n" 139840 ~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n" 139841 ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" 139842 ~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" 139843 ^done 139844 (gdb) 139845 info frame 139846 &"info frame\n" 139847 ~"Stack level 0, frame at 0x7fffffffdf90:\n" 139848 ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n" 139849 ~" source language c.\n" 139850 ~" Arglist at 0x7fffffffdf80, args: \n" 139851 ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n" 139852 ~" Saved registers:\n " 139853 ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n" 139854 ^done 139855 (gdb) 139856 -stack-info-depth --thread 3 139857 ^done,depth="4" 139858 (gdb) 139859 info thread 139860 &"info thread\n" 139861 ~" Id Target Id Frame \n" 139862 ~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n" 139863 ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" 139864 ~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" 139865 ^done 139866 (gdb) 139867 info frame 139868 &"info frame\n" 139869 ~"Stack level 0, frame at 0x7ffff742dee0:\n" 139870 ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n" 139871 ~" called by frame at 0x7ffff742df00\n" 139872 ~" source language c.\n" 139873 ~" Arglist at 0x7ffff742ded0, args: \n" 139874 ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n" 139875 ~" Saved registers:\n " 139876 ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n" 139877 ^done 139878 (gdb) 139879 139880 This caused problems for frontends that provide access to CLI because UI 139881 may silently change the context for CLI commands (as demonstrated above). 139882 139883 This commit fixes the problem by restoring thread and frame in 139884 mi_cmd_execute (). With this change, there are only two GDB/MI commands 139885 that can change user selected context: -thread-select and -stack-select-frame. 139886 This allows us to remove all and rather complicated logic of notifying 139887 about user selected context change from mi_execute_command (), leaving it 139888 to these two commands themselves to notify. 139889 139890 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684 139891 1398922022-03-08 Andrew Burgess <aburgess@redhat.com> 139893 139894 gdb: announce upcoming removal of Python 2 support from gdb 139895 As has been discussed here: 139896 139897 https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html 139898 139899 Python 2 support will be removed from GDB after GDB 12 has branched. 139900 This commit places an entry in the NEWS file to inform users of this 139901 decision. 139902 1399032022-03-08 GDB Administrator <gdbadmin@sourceware.org> 139904 139905 Automatic date update in version.in 139906 1399072022-03-07 Andrew Burgess <aburgess@redhat.com> 139908 139909 gdb/testsuite: add new test for comparing char types in Python 139910 There's an interesting property of the 'char' type in C and C++, the 139911 three types 'char', 'unsigned char', and 'signed char', are all 139912 considered distinct. 139913 139914 In contrast, and 'int' is signed by default, and so 'int' and 'signed 139915 int' are considered the same type. 139916 139917 This commit adds a test to ensure that this edge case is visible to a 139918 user from Python. 139919 139920 It is worth noting that for any particular compiler implementation (or 139921 the flags a compiler was invoked with), a 'char' will be either signed 139922 or unsigned; it has to be one or the other, and a user can access this 139923 information by using the Type.is_signed property. However, for 139924 something like function overload resolution, the 'char' type is 139925 considered distinct from the signed and unsigned variants. 139926 139927 There's no change to GDB with this commit, this is just adding a new 139928 test to guard some existing functionality. 139929 1399302022-03-07 Andrew Burgess <aburgess@redhat.com> 139931 139932 gdb/python: add Type.is_signed property 139933 Add a new read-only property, Type.is_signed, which is True for signed 139934 types, and False otherwise. 139935 139936 This property should only be read on types for which Type.is_scalar is 139937 true, attempting to read this property for non-scalar types will raise 139938 a ValueError. 139939 139940 I chose 'is_signed' rather than 'is_unsigned' in order to match the 139941 existing Architecture.integer_type method, which takes a 'signed' 139942 parameter. As far as I could find, that was the only existing 139943 signed/unsigned selector in the Python API, so it seemed reasonable to 139944 stay consistent. 139945 1399462022-03-07 Andrew Burgess <aburgess@redhat.com> 139947 139948 gdb/python: add Type.is_scalar property 139949 Add a new read-only property which is True for scalar types, 139950 otherwise, it's False. 139951 1399522022-03-07 Andrew Burgess <aburgess@redhat.com> 139953 139954 gdb/mi: add --no-connection to MI -add-inferior command 139955 Following on from the previous commit, where the -add-inferior command 139956 now uses the same connection as the current inferior, this commit adds 139957 a --no-connection option to -add-inferior. 139958 139959 This new option matches the existing option of the same name for the 139960 CLI version of add-inferior; the new inferior is created with no 139961 connection. 139962 139963 I've added a new 'connection' field to the MI output of -add-inferior, 139964 which includes the connection number and short name. I haven't 139965 included the longer description field, this is the MI after all. My 139966 expectation would be that if the frontend wanted to display all the 139967 connection details then this would be looked up from 'info 139968 connection' (or the MI equivalent if/when such a command is added). 139969 139970 The existing -add-inferior tests are updated, as are the docs. 139971 1399722022-03-07 Umair Sair <umair_sair@hotmail.com> 139973 139974 gdb/mi: fix regression in mi -add-inferior command 139975 Prior to the multi-target support commit: 139976 139977 commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 139978 Date: Fri Jan 10 20:06:08 2020 +0000 139979 139980 Multi-target support 139981 139982 When a new inferior was added using the MI -add-inferior command, the 139983 new inferior would be using the same target as all the other 139984 inferiors. This makes sense, GDB only supported a single target stack 139985 at a time. 139986 139987 After the above commit, each inferior has its own target stack. 139988 139989 To maintain backward compatibility, for the CLI add-inferior command, 139990 when a new inferior is added the above commit has the new inferior 139991 inherit a copy of the target stack from the current inferior. 139992 139993 Unfortunately, this same backward compatibility is missing for the MI. 139994 139995 This commit fixes this oversight. 139996 139997 Now, when the -add-inferior MI command is used, the new inferior will 139998 inherit a copy of the target stack from the current inferior. 139999 1400002022-03-07 Tom Tromey <tromey@adacore.com> 140001 140002 Deprecate dbx mode 140003 GDB has a dbx emulation mode that adds a few aliases and helper 140004 commands. This mode is barely documented and is very superficial 140005 besides. I suspect it is rarely used, and I would like to propose 140006 deprecating it for GDB 12, and then removing it in GDB 13. 140007 1400082022-03-07 Pedro Alves <pedro@palves.net> 140009 140010 Remove unnecessary inferior lookup in infrun:handle_one 140011 infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we 140012 already have a thread pointer handy, and the thread has a pointer to 140013 the inferior. This commit removes the unnecessary lookup. 140014 140015 Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339 140016 1400172022-03-07 Tom Tromey <tromey@adacore.com> 140018 140019 Fix bug in ada_print_floating 140020 ada_print_floating rewrites a floating-point string representation to 140021 conform to Ada syntax. However, if you managed to get a floating 140022 point error, you might see: 140023 140024 (gdb) print whatever 140025 $2 = <invalid float valu.0e> 140026 140027 What's happening here is that ada_print_floating doesn't recognize 140028 this error case, and proceeds to modify the error text. 140029 140030 This patch fixes this problem. 140031 1400322022-03-07 Tom Tromey <tromey@adacore.com> 140033 140034 Implement real literal extension for Ada 140035 Sometimes it is convenient to be able to specify the exact bits of a 140036 floating-point literal. For example, you may want to set a 140037 floating-point register to a denormalized value, or to a particular 140038 NaN. 140039 140040 In C, you can do this by combining the "{}" cast with an array 140041 literal, like: 140042 140043 (gdb) p {double}{0x576488BDD2AE9FFE} 140044 $1 = 9.8765449999999996e+112 140045 140046 This patch adds a somewhat similar idea to Ada. It extends the lexer 140047 to allow "l" and "f" suffixes in a based literal. The "f" indicates a 140048 floating-point literal, and the "l"s control the size of the 140049 floating-point type. 140050 140051 Note that this differs from Ada's based real literals. I believe 140052 those can also be used to control the bits of a floating-point value, 140053 but they are a bit more cumbersome to use (simplest is binary but 140054 that's also very lengthy). Also, these aren't implemented in GDB. 140055 140056 I chose not to allow this extension to work with based integer 140057 literals with exponents. That didn't seem very useful. 140058 1400592022-03-07 Tom Tromey <tromey@adacore.com> 140060 140061 Fix Ada integer literals with exponents 140062 While working on another patch, I noticed that Ada integer literals 140063 with exponents did not work. For example, with one form you get an 140064 error: 140065 140066 (gdb) print 8e2 140067 Invalid digit `e' in based literal 140068 140069 And with another form you get an incorrect value: 140070 140071 (gdb) print 16#8#e2 140072 $2 = 8 140073 140074 This patch fixes the bugs and adds tests. 140075 1400762022-03-07 Tom Tromey <tromey@adacore.com> 140077 140078 Fix gdb.ada/arrayptr.exp results 140079 PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12, 140080 but fails with minimal encodings in earlier versions. 140081 140082 This patch updates the test to try to report the results correctly. I 140083 tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12 140084 built from git trunk sometime relatively recently. 140085 140086 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115 140087 1400882022-03-07 Tom Tromey <tromey@adacore.com> 140089 140090 Handle non-ASCII identifiers in Ada 140091 Ada allows non-ASCII identifiers, and GNAT supports several such 140092 encodings. This patch adds the corresponding support to gdb. 140093 140094 GNAT encodes non-ASCII characters using special symbol names. 140095 140096 For character sets like Latin-1, where all characters are a single 140097 byte, it uses a "U" followed by the hex for the character. So, for 140098 example, thorn would be encoded as "Ufe" (0xFE being lower case 140099 thorn). 140100 140101 For wider characters, despite what the manual says (it claims 140102 Shift-JIS and EUC can be used), in practice recent versions only 140103 support Unicode. Here, characters in the base plane are represented 140104 using "Wxxxx" and characters outside the base plane using 140105 "WWxxxxxxxx". 140106 140107 GNAT has some further quirks here. Ada is case-insensitive, and GNAT 140108 emits symbols that have been case-folded. For characters in ASCII, 140109 and for all characters in non-Unicode character sets, lower case is 140110 used. For Unicode, however, characters that fit in a single byte are 140111 converted to lower case, but all others are converted to upper case. 140112 140113 Furthermore, there is a bug in GNAT where two symbols that differ only 140114 in the case of "Y WITH DIAERESIS" (and potentially others, I did not 140115 check exhaustively) can be used in one program. I chose to omit 140116 handling this case from gdb, on the theory that it is hard to figure 140117 out the logic, and anyway if the bug is ever fixed, we'll regret 140118 having a heuristic. 140119 140120 This patch introduces a new "ada source-charset" setting. It defaults 140121 to Latin-1, as that is GNAT's default. This setting controls how "U" 140122 characters are decoded -- W/WW are always handled as UTF-32. 140123 140124 The ada_tag_name_from_tsd change is needed because this function will 140125 read memory from the inferior and interpret it -- and this caused an 140126 encoding failure on PPC when running a test that tries to read 140127 uninitialized memory. 140128 140129 This patch implements its own UTF-32-based case folder. This avoids 140130 host platform quirks, and is relatively simple. A short Python 140131 program to generate the case-folding table is included. It simply 140132 relies on whatever version of Unicode is used by the host Python, 140133 which seems basically acceptable. 140134 140135 Test cases for UTF-8, Latin-1, and Latin-3 are included. This 140136 exercises most of the new code paths, aside from Y WITH DIAERESIS as 140137 noted above. 140138 1401392022-03-07 Tom Tromey <tromey@adacore.com> 140140 140141 Define HOST_UTF32 in charset.h 140142 rust-parse.c has a #define for the host-specific UTF-32 charset name. 140143 A later patch needs the same thing, so this patch moves the definition 140144 to charset.h for easier reuse. 140145 1401462022-03-07 Tom Tromey <tromey@adacore.com> 140147 140148 Let phex and phex_nz handle sizeof_l==1 140149 Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let 140150 this case fall through to the default case. However, a subsequent 140151 patch in this series needs this case to work correctly. 140152 140153 I looked at all calls to these functions that pass a 1 for the 140154 sizeof_l parameter. The only such case seems to be correct with this 140155 change. 140156 1401572022-03-07 Tom Tromey <tromey@adacore.com> 140158 140159 Don't pre-size result string in ada_decode 140160 Currently, ada_decode pre-sizes the output string, filling it with 'X' 140161 characters. However, it's a bit simpler and more flexible to let 140162 std::string do the work here, and simply append characters to the 140163 string as we go. This turns out to be useful for a subsequent patch. 140164 140165 Simplify a regular expression in ada-lex.l 140166 ada-lex.l uses "%option case-insensitive", so there is no need for 140167 regular expressions to match upper case. 140168 1401692022-03-07 GDB Administrator <gdbadmin@sourceware.org> 140170 140171 Automatic date update in version.in 140172 1401732022-03-06 Maciej W. Rozycki <macro@orcam.me.uk> 140174 140175 MIPS/opcodes: Fix alias annotation for branch instructions 140176 Correct issues with INSN2_ALIAS annotation for branch instructions: 140177 140178 - regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for 140179 BEQ/L and BNE/L respectively with the `rs' operand equal to $0, 140180 140181 - microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for 140182 BEQ and BNE respectively with the `rt' operand equal to $0, 140183 140184 - regular MIPS BAL assembly instruction is an idiom for architecture 140185 levels of up to the MIPSr5 ISA and a machine instruction on its own 140186 from the MIPSr6 ISA up. 140187 140188 Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a 140189 new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug: 140190 140191 $ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o 140192 140193 bal.o: file format elf32-tradlittlemips 140194 140195 Disassembly of section .text: 140196 140197 00000000 <foo>: 140198 0: 04110000 0x4110000 140199 ... 140200 $ 140201 140202 Add test cases accordingly. 140203 140204 Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel. 140205 140206 2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk> 140207 140208 binutils/ 140209 * testsuite/binutils-all/mips/mips1-branch-alias.d: New test. 140210 * testsuite/binutils-all/mips/mips1-branch-noalias.d: New test. 140211 * testsuite/binutils-all/mips/mips2-branch-alias.d: New test. 140212 * testsuite/binutils-all/mips/mips2-branch-noalias.d: New test. 140213 * testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test. 140214 * testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New 140215 test. 140216 * testsuite/binutils-all/mips/micromips-branch-alias.d: New 140217 test. 140218 * testsuite/binutils-all/mips/micromips-branch-noalias.d: New 140219 test. 140220 * testsuite/binutils-all/mips/mips-branch-alias.s: New test 140221 source. 140222 * testsuite/binutils-all/mips/micromips-branch-alias.s: New test 140223 source. 140224 * testsuite/binutils-all/mips/mips.exp: Run the new tests. 140225 140226 2022-03-06 Sagar Patel <sagarmp@cs.unc.edu> 140227 Maciej W. Rozycki <macro@orcam.me.uk> 140228 140229 opcodes/ 140230 * mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation 140231 for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions. 140232 * micromips-opc.c (micromips_opcodes): Likewise for "beqz" and 140233 "bnez" instructions. 140234 1402352022-03-06 Tom Tromey <tom@tromey.com> 140236 140237 Use function view when iterating over block symbols 140238 This changes iterate_over_block_local_vars and 140239 iterate_over_block_arg_vars to take a gdb::function_view rather than a 140240 function pointer and a user-data. In one spot, this allows us to 140241 remove a helper structure and helper function. In another spot, this 140242 looked more complicated, so I changed the helper function to be an 140243 "operator()" -- also a simplification, just not as big. 140244 1402452022-03-06 Tom Tromey <tom@tromey.com> 140246 140247 Simplify hppa-tdep.c use of objfile_key 140248 I happened to notice a couple of unnecessary casts in hppa-tdep.c, and 140249 then I saw that the use of objfile_key could be simplified -- removing 140250 some code and using the default deleter rather than noop_deleter. 140251 140252 Tested by rebuilding. Let me know what you think. 140253 1402542022-03-06 Simon Marchi <simon.marchi@polymtl.ca> 140255 140256 gdb: constify parameter of value_copy 140257 In a following patch, I have a const value I want to copy using a 140258 value_copy. However, value_copy takes a non-const source value, at the 140259 moment. Change the paramter to be const, 140260 140261 If the source value is not lazy, we currently call 140262 value_contents_all_raw, which calls allocate_value_contents, to get a 140263 view on the contents. They both take a non-const value, that's a 140264 problem. My first attempt at solving it was to add a const version of 140265 value_contents_all_raw, make allocate_value_contents take a const value, 140266 and either: 140267 140268 - make value::contents mutable 140269 - make allocate_value_contents cast away the const 140270 140271 The idea being that allocating the value contents buffer does modify the 140272 value at the bit level, but logically that doesn't change its state. 140273 140274 That was getting a bit complicated, so what I ended up doing is make 140275 value_copy not call value_contents_all_raw. We know at this point that 140276 the value is not lazy, so value::contents must have been allocate 140277 already. 140278 140279 Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4 140280 1402812022-03-06 Simon Marchi <simon.marchi@polymtl.ca> 140282 140283 gdb: remove internalvar_funcs::destroy 140284 No kind of internal var uses it remove it. This makes the transition to 140285 using a variant easier, since we don't need to think about where this 140286 should be called (in a destructor or not), if it can throw, etc. 140287 140288 Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd 140289 1402902022-03-06 GDB Administrator <gdbadmin@sourceware.org> 140291 140292 Automatic date update in version.in 140293 1402942022-03-05 GDB Administrator <gdbadmin@sourceware.org> 140295 140296 Automatic date update in version.in 140297 1402982022-03-04 Tom Tromey <tromey@adacore.com> 140299 140300 Mark vDSO as not a file 140301 The vDSO objfile is not a real file, so mark it as such. I noticed 140302 this because, when playing with debuginfod, I saw: 140303 140304 Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000 140305 140306 That "/tmp" is wrong -- it's just gdb's cwd. This patch corrects the 140307 problem, resulting in: 140308 140309 Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000 140310 140311 Regression tested on x86-64 Fedora 34. 140312 1403132022-03-04 Simon Marchi <simon.marchi@polymtl.ca> 140314 140315 binutils/readelf: fix indentation in process_dynamic_section 140316 Clangd shows a warning about misleading indentation in this file, fix 140317 it. 140318 140319 binutils/ChangeLog: 140320 140321 * readelf.c (process_dynamic_section): Fix indentation. 140322 140323 Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297 140324 1403252022-03-04 Christina Schimpe <christina.schimpe@intel.com> 140326 140327 gdb: Use a typedef's scoped type name to identify local typedefs 140328 GDB prints the wrong type for typedefs in case there is another typedef 140329 available for the same raw type (gdb/16040). The reason is that the 140330 current hashmap based substitution mechanism always compares the target 140331 type of a typedef and not its scoped name. 140332 140333 The original output of GDB for a program like 140334 140335 ~~~~ 140336 namespace ns 140337 { 140338 typedef double scoped_double; 140339 } 140340 140341 typedef double global_double; 140342 140343 class TypedefHolder 140344 { 140345 public: 140346 double a; 140347 ns::scoped_double b; 140348 global_double c; 140349 140350 private: 140351 typedef double class_double; 140352 class_double d; 140353 140354 double method1(ns::scoped_double) { return 24.0; } 140355 double method2(global_double) { return 24.0; } 140356 }; 140357 140358 int main() 140359 { 140360 TypedefHolder th; 140361 return 0; 140362 } 140363 ~~~~ 140364 140365 is 140366 ~~~~ 140367 140368 (gdb) b 27 140369 Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27. 140370 (gdb) r 140371 Starting program: /tmp/typedefholder 140372 140373 Breakpoint 1, main () at TypedefHolder.cc:27 140374 27 return 0; 140375 (gdb) ptype th 140376 type = class TypedefHolder { 140377 public: 140378 class_double a; 140379 class_double b; 140380 class_double c; 140381 private: 140382 class_double d; 140383 140384 class_double method1(class_double); 140385 class_double method2(class_double); 140386 140387 typedef double class_double; 140388 } 140389 ~~~~ 140390 140391 Basically all attributes of a class which have the raw type "double" are 140392 substituted by "class_double". 140393 140394 With the patch the output is the following 140395 140396 ~~~~ 140397 type = class TypedefHolder { 140398 public: 140399 double a; 140400 ns::scoped_double b; 140401 global_double c; 140402 private: 140403 class_double d; 140404 140405 double method1(ns::scoped_double); 140406 double method2(global_double); 140407 140408 typedef double class_double; 140409 } 140410 ~~~~ 140411 1404122022-03-04 Jan Beulich <jbeulich@suse.com> 140413 140414 RISC-V: make .insn actually work for 64-bit insns 140415 Presently in this case, due to an undefined behavior shift, at least 140416 with x86 cross builds I'm observing: 140417 140418 Error: value conflicts with instruction length `8,0x0000003f' 140419 140420 Eliminate the UB and extend the respective testcase. 140421 1404222022-03-04 Jan Beulich <jbeulich@suse.com> 140423 140424 x86: drop redundant x86-64-code16-2 test 140425 The code16-2 test is already meaningless enough as a gas test, identical 140426 to this one, and is run uniformly for all ELF targets anyway. 140427 1404282022-03-04 GDB Administrator <gdbadmin@sourceware.org> 140429 140430 Automatic date update in version.in 140431 1404322022-03-03 Roland McGrath <mcgrathr@google.com> 140433 140434 Fix typo in last change. 140435 1404362022-03-03 Roland McGrath <mcgrathr@google.com> 140437 140438 Avoid conflict with gnulib open/close macros. 140439 On some systems, the gnulib configuration will decide to define open 140440 and/or close as macros to replace the POSIX C functions. This 140441 interferes with using those names in C++ class or namespace scopes. 140442 140443 gdbsupport/ 140444 * event-pipe.cc (event_pipe::open): Renamed to ... 140445 (event_pipe::open_pipe): ... this. 140446 (event_pipe::close): Renamed to ... 140447 (event_pipe::close_pipe): ... this. 140448 * event-pipe.h (class event_pipe): Updated. 140449 gdb/ 140450 * inf-ptrace.h (async_file_open, async_file_close): Updated. 140451 gdbserver/ 140452 * gdbserver/linux-low.cc (linux_process_target::async): Likewise. 140453 1404542022-03-03 Alan Modra <amodra@gmail.com> 140455 140456 Adjust ld ctf test for 32-bit targets 140457 powerpc-linux, and I suspect other 32-bit targets, report "aligned at 140458 0x4" for this test. 140459 140460 * testsuite/ld-ctf/nonrepresentable.d: Accept any alignment. 140461 1404622022-03-03 Luis Machado <luis.machado@arm.com> 140463 140464 Update my e-mail address in the MAINTAINERS file 140465 Update the information accordingly. 140466 1404672022-03-03 Tiezhu Yang <yangtiezhu@loongson.cn> 140468 140469 gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.exp 140470 When execute the following command: 140471 140472 make check-gdb TESTS="gdb.base/gdb-caching-proc.exp" 140473 140474 we can see there exist some failed testcases: 140475 140476 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt) 140477 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt) 140478 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt) 140479 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt) 140480 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt) 140481 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt) 140482 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt) 140483 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt) 140484 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt) 140485 FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt) 140486 140487 here are the detailed messages in gdb/testsuite/gdb.log: 140488 140489 attach 873776 140490 A program is being debugged already. Kill it? (y or n) n 140491 Not killed. 140492 (gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt) 140493 140494 so handle the case "A program is being debugged already. Kill it" in 140495 can_spawn_for_attach to fix the failed testcases. 140496 1404972022-03-03 Alan Modra <amodra@gmail.com> 140498 140499 comment typo fix 140500 1405012022-03-03 Alan Modra <amodra@gmail.com> 140502 140503 PowerPC64 DT_RELR relative reloc addresses 140504 Section addresses can change between ppc64_elf_size_stubs and 140505 ppc64_elf_build_stubs due to .eh_frame editing. The idea of stashing 140506 r_offset final addresses calculated in ppc64_elf_size_stubs for use by 140507 ppc64_elf_build_stubs was never a good idea. Instead, we need to keep 140508 section/offset pairs. 140509 140510 * elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr. 140511 Add relr section/offset array. 140512 (append_relr_off): Rewrite. Update all callers. 140513 (sort_relr): New function. 140514 (ppc64_elf_size_stubs): Adjust to suit new relative reloc stash. 140515 (ppc64_elf_build_stubs): Likewise. 140516 1405172022-03-03 GDB Administrator <gdbadmin@sourceware.org> 140518 140519 Automatic date update in version.in 140520 1405212022-03-02 John Baldwin <jhb@FreeBSD.org> 140522 140523 configure: Stop checking for PT_GETXMMREGS. 140524 This request is present on all modern *BSD/i386 systems (those 140525 released since mid-2006), and the *BSD/i386 targets now assume it is 140526 present unconditionally. 140527 140528 i386-bsd-nat: Assume PT_GETXMMREGS is present. 140529 NetBSD has included PT_GETXMMREGS since 1.6 released in September 140530 2002. OpenBSD has included PT_GETXMMREGS since 3.8 released in 140531 November 2005. 140532 140533 i386-fbsd-nat: Assume PT_GETXMMREGS is present. 140534 PT_GETXMMREGS was first added in FreeBSD 6.0 released in November 2005. 140535 The last FreeBSD release without support was 5.5 released in May 2006. 140536 1405372022-03-02 John Baldwin <jhb@FreeBSD.org> 140538 140539 fbsd-tdep: Implement the vsyscall_range gdbarch hook. 140540 FreeBSD recently added a real vDSO in its shared page for the amd64 140541 architecture. The vDSO is mapped at the address given by the 140542 AT_KPRELOAD ELF auxiliary vector entry. To find the end of the 140543 mapping range, parse the list of virtual map entries used by 'info 140544 proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or 140545 via the kinfo_getvmmap function for native targets (fetched from the 140546 native target as the TARGET_OBJECT_FREEBSD_VMMAP object). 140547 140548 This silences warnings on recent FreeBSD/amd64 kernels due to not 140549 finding symbols for the vdso: 140550 140551 warning: Could not load shared library symbols for [vdso]. 140552 Do you need "set solib-search-path" or "set sysroot"? 140553 1405542022-03-02 Tom Tromey <tromey@adacore.com> 140555 140556 Rewrite make-target-delegates in Python 140557 I think gdb is probably better off having fewer languages involved 140558 when generating code. 'sh' is unavoidable for build-time generation, 140559 but for other things, let's use Python. 140560 140561 This rewrites make-target-delegates in Python. I've stuck pretty 140562 closely to the original code in this rewrite, so it may look slightly 140563 weird from a Python perspective. 140564 140565 The only output difference is that a copyright header is now 140566 generated, using the code introduced in the previous patch. 140567 140568 make-target-delegates.py is simpler to invoke, as it knows the correct 140569 input file to scan and it creates the output file itself. 140570 1405712022-03-02 Tom Tromey <tromey@adacore.com> 140572 140573 Move copyright code from gdbarch.py to new file 140574 This moves the copyright code from gdbarch.py to a new Python source 140575 file, gdbcopyright.py. The function in this file will find the 140576 copyright dates by scanning the calling script. This will be reused 140577 in a future patch. 140578 140579 This involved minor changes to the output of gdbarch.py. Also, I've 140580 updated copyright.py to remove the reference to gdbarch.sh. We don't 140581 need to mention gdbarch.py there, either. 140582 1405832022-03-02 GDB Administrator <gdbadmin@sourceware.org> 140584 140585 Automatic date update in version.in 140586 1405872022-03-01 Tom Tromey <tom@tromey.com> 140588 140589 Some "distclean" fixes in gdb 140590 PR build/12440 points out that "make distclean" is broken in gdb. 140591 Most of the breakage comes from other projects in the tree, but we can 140592 fix some of the issues, which is what this patch does. 140593 140594 Note that the yacc output files, like c-exp.c, are left alone. In a 140595 source distribution, these are included in the tarball, and if the 140596 user builds in-tree, we would not want to remove them. 140597 140598 While that seems a bit obscure, it seems to me that "distclean" is 140599 only really useful for in-tree builds anyway -- out-of-tree I simply 140600 delete the entire build directory and start over. 140601 140602 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440 140603 1406042022-03-01 Tom Tromey <tom@tromey.com> 140605 140606 Fix typo in the "alias" example 140607 PR cli/17332, filed around 8 years ago, points out a typo in the docs 140608 -- in one example, the command and its output are obviously out of 140609 sync. This patch fixes it. I'm checking this in as obvious. 140610 140611 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332 140612 1406132022-03-01 Nick Clifton <nickc@redhat.com> 140614 140615 Fix a typo in the previous delta to bfdio.c. 140616 PR 25713 140617 * bfdio.c (_bfd_real_fopen): Fix typo. 140618 1406192022-03-01 Alan Modra <amodra@gmail.com> 140620 140621 Revert "Check thin archive element file size against archive header" 140622 This reverts commit 48e3e6aec8a4f37d00ea6c0da3ab45e76490e3db. 140623 140624 PR 28929 140625 * archive.c (_bfd_get_elt_at_filepos): Don't check thin archive 140626 element file size. 140627 1406282022-03-01 Nick Clifton <nickc@redhat.com> 140629 140630 Fix linker tests to compile with gcc-12. 140631 PR 21964 140632 * testsuite/ld-elf/pr21964-1a.c: Fix array comparisons. 140633 * testsuite/ld-elf/pr21964-1b.c: Likewise. 140634 * testsuite/ld-elf/pr21964-1c.c: Likewise. 140635 * testsuite/ld-elf/pr21964-2a.c: Likewise. 140636 * testsuite/ld-elf/pr21964-2b.c: Likewise. 140637 * testsuite/ld-elf/pr21964-3a.c: Likewise. 140638 140639 Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes. 140640 PR 28848 140641 PR 28859 140642 * elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first 140643 input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have 140644 TAG_FP_arch set then reset the TAG_ABI_HardFP_use. 140645 1406462022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn> 140647 140648 gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp 140649 If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case 140650 gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the 140651 following info: 140652 140653 (gdb) attach 6500 140654 Attaching to process 6500 140655 ptrace: Operation not permitted. 140656 (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach 140657 140658 It is obviously wrong, the expected result should be UNSUPPORTED in such 140659 a case. 140660 140661 It is better to make can_spawn_for_attach to return false for this case. 140662 It would have to setup a small test program, compile it to exec, spawn it 140663 and try to attach to it. 140664 140665 With this patch, we can see "Operation not permitted" in the log info, 140666 and then we can do the following processes to test: 140667 (1) set ptrace_scope as 0 140668 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope 140669 $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" 140670 (2) use sudo 140671 $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" 140672 140673 Additionally, handle the other cases when test with RUNTESTFLAGS= 140674 "--target_board=native-extended-gdbserver". 140675 1406762022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn> 140677 140678 gdb: testsuite: print explicit test result in can_spawn_for_attach 140679 In the current code, there is no test result when execute the following 140680 commands: 140681 140682 $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost" 140683 $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver" 140684 140685 It is better to print explicit test result in can_spawn_for_attach. 140686 1406872022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn> 140688 140689 gdb: add Tiezhu Yang as LoongArch maintainer 140690 The patch series "gdb: Add basic support for LoongArch" has been 140691 merged into master, list Tiezhu Yang as LoongArch maintainer. 140692 1406932022-03-01 GDB Administrator <gdbadmin@sourceware.org> 140694 140695 Automatic date update in version.in 140696 1406972022-02-28 Keith Seitz <keiths@redhat.com> 140698 140699 Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp 140700 Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64} 140701 causes several Tcl errors to appear. For example, 140702 140703 (gdb) 140704 ERROR: : spawn id exp20 not open 140705 while executing 140706 "expect { 140707 -i exp11 -timeout 10 140708 -i "$inferior_spawn_id" 140709 -re ".*Cannot exec.*Permission denied" { 140710 set saw_perm_error 1 140711 verbose -log "saw..." 140712 ("uplevel" body line 1) 140713 invoked from within 140714 "uplevel $body" NONE : spawn id exp20 not open 140715 UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof) 140716 140717 This is happening because of the way this test is implemented: 140718 140719 while {1} { 140720 gdb_expect { 140721 -i "$inferior_spawn_id" 140722 -re ".*Cannot exec.*Permission denied" { 140723 set saw_perm_error 1 140724 verbose -log "saw mi error" 140725 } 140726 -i "$gdb_spawn_id" 140727 -re "\\^error,msg=\"During startup program exited with code 127" { 140728 set saw_mi_error 1 140729 verbose -log "saw mi error" 140730 } 140731 # and so on 140732 } 140733 } 140734 140735 The first time this loop is executed, `inferior_spawn_id' is valid. When the 140736 first branch of the expect statement is reached, gdbserver has exited, closing 140737 the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed 140738 again. The first branch now refers to a non-existent spawn_id, leading to the error. 140739 140740 This can be fixed by using exp_continue to loop in expect instead of looping around 140741 expect, which is the approach I have used[1]. Note I've had to update the expected 140742 message for the "During startup..." error message when running with gdbserver. 140743 140744 One other small change I've made is to add a log entry which spills the values of 140745 the two variables, saw_mi_error and saw_perm_error (and updated the log output 140746 for the later). This should make the log output clearer about why the test failed. 140747 140748 With this patch installed, all the ERRORs disappear, leaving previously masked 140749 FAILs (which I have not attempted to fix). 140750 140751 [1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only 140752 assume that it was intentionally written this way, and I've modified the code with 140753 that assumption. I have tested a version using gdb_test_multiple, and that appears 140754 to work fine, too, if that is preferred. [It still employs exp_continue to fix the 140755 spawn_id errors.] 140756 1407572022-02-28 Tom Tromey <tromey@adacore.com> 140758 140759 Add more filename styling 140760 I found a few spots where filename styling ought to be applied, but is 140761 not. 140762 1407632022-02-28 Tom Tromey <tromey@adacore.com> 140764 140765 Fix maybe-uninitialized warning in py-infthread.c 140766 I got this warning from py-infthread.c using the Fedora 34 system GCC: 140767 140768 ../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized] 140769 140770 I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an 140771 'if' whose condition is always true -- but GCC can't know this. This 140772 patch avoids the warning by adding a harmless initialization. 140773 1407742022-02-28 Tom Tromey <tromey@adacore.com> 140775 140776 Handle multi-byte bracket sequences in Ada lexer 140777 As noted in an earlier patch, the Ada lexer does not handle multi-byte 140778 bracket sequences. This patch adds support for these for character 140779 literals. gdb does not generally seem to handle the Ada wide string 140780 types, so for the time being these continue to be excluded -- but an 140781 explicit error is added to make this more clear. 140782 1407832022-02-28 Tom Tromey <tromey@adacore.com> 140784 140785 Handle 'QWW' encoding case in Ada enums 140786 In Ada, an enum can contain character literals. GNAT encodes these 140787 values in a special way. For example, the Unicode character U+0178 140788 would be represented as 'QW0178' in the DWARF: 140789 140790 <3><112f>: Abbrev Number: 2 (DW_TAG_enumerator) 140791 <1130> DW_AT_name : (indirect string, offset: 0x19ff): QW0178 140792 <1134> DW_AT_const_value : 2 140793 140794 gdb handles this reasonably well, but failed to handle the 'QWW' 140795 encoding, which is used for characters outside the base plane. 140796 140797 Also, while working on this, I noticed that gdb will print the decimal 140798 value for an enum character constant: 140799 140800 (gdb) print Char_X 140801 $2 = 1 'x' 140802 140803 This is a nice feature, IMO, because in this situation the 'x' enum 140804 constant does not have its usual decimal value -- it has the value 140805 that's assigned based on the enumeration type. 140806 140807 However, gdb did not do this when it decided to print the constant 140808 using the bracket notation: 140809 140810 (gdb) print Char_Thorn 140811 $3 = ["de"] 140812 140813 This patch changes gdb to print the decimal value here as well, and to 140814 put the bracket notation in single quotes -- otherwise gdb will be 140815 printing something that it can't then read. Now it looks like: 140816 140817 (gdb) print Char_Thorn 140818 $3 = 4 '["de"]' 140819 140820 Note that gdb can't read longer bracket notations, like the other ones 140821 printed in this test case: 140822 140823 (gdb) print Char_King 140824 $4 = 3 '["01fa00"]' 140825 140826 While I think this is a bug, I plan to fix it separately. 140827 140828 Finally, in the new test case, the copyright dates are chosen this way 140829 because this all started as a copy of an existing test. 140830 1408312022-02-28 Andrew Burgess <aburgess@redhat.com> 140832 140833 gdb/python: Add gdb.InferiorThread.details attribute 140834 This adds a new read-only attribute gdb.InferiorThread.details, this 140835 attribute contains a string, the results of target_extra_thread_info 140836 for the thread, or None, if target_extra_thread_info returns nullptr. 140837 140838 As the string returned by target_extra_thread_info is unstructured, 140839 this attribute is only really useful for echoing straight through to 140840 the user, but, if a user wants to write a command that displays the 140841 same, or a similar 'Thread Id' to the one seen in 'info threads', then 140842 they need access to this string. 140843 140844 Given that the string produced by target_extra_thread_info varies by 140845 target, there's only minimal testing of this attribute, I check that 140846 the attribute can be accessed, and that the return value is either 140847 None, or a string. 140848 1408492022-02-28 Keith Seitz <keiths@redhat.com> 140850 140851 Error when gdb_is_target_1 is called without running gdb instance 140852 This is a snafu that I encountered while implementing the previous 140853 patch, which attempted to use gdb_is_target_native. This proc and 140854 gdb_is_target_remote both rely on gdb_is_target_1, which actually 140855 cannot be called without gdb already running. 140856 140857 This patch adds appropriate warning comments to these procs and 140858 causes gdb_is_target_1 to issue a Tcl error if it is called without a 140859 gdb instance already running. This should prevent unwitting callers 140860 from using this at the wrong time. 140861 1408622022-02-28 Keith Seitz <keiths@redhat.com> 140863 140864 Fix gdb.fortran "failed to extract expected results" errors 140865 When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp, 140866 the test suite throws several ERRORs on native-gdbserver/-m{32,64}, 140867 and native-extended-gdbsever/-m{32,64}: 140868 140869 [on native-extended-gdbserver/-m64] 140870 Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ... 140871 ERROR: failed to extract expected results 140872 ERROR: failed to extract expected results 140873 Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ... 140874 ERROR: failed to extract expected results for lbound 140875 140876 This occurs because the tests require inferior I/O which we do not have 140877 access to while using these targets. 140878 140879 This patch skips these tests when running on non-native targets. 140880 1408812022-02-28 Torbj?rn Svensson <torbjorn.svensson@st.com> 140882 140883 Further correct the handling of long pathnames on Windows hosts. 140884 PR 25713 140885 * bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260 140886 characters on Windows hosts. 140887 1408882022-02-28 Nick Clifton <nickc@redhat.com> 140889 140890 Clarify the wording of the error message when an obsolete configuration is encountered. 140891 PR 28886 140892 * config.bfd: Update error message for obsolete configurations. 140893 1408942022-02-28 GDB Administrator <gdbadmin@sourceware.org> 140895 140896 Automatic date update in version.in 140897 1408982022-02-27 GDB Administrator <gdbadmin@sourceware.org> 140899 140900 Automatic date update in version.in 140901 1409022022-02-26 Kevin Buettner <kevinb@redhat.com> 140903 140904 Handle recursive internal problem in gdb_internal_error_resync 140905 I came across this problem when testing gdb.base/gdb-sigterm.exp 140906 on a machine with a pre-release version of glib-2.34 installed: 140907 140908 A problem internal to GDB has been detected, 140909 further debugging may prove unreliable. 140910 Quit this debugging session? (y or n) Recursive internal problem. 140911 FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error) 140912 Resyncing due to internal error. 140913 ERROR: : spawn id exp11 not open 140914 while executing 140915 "expect { 140916 -i exp11 -timeout 10 140917 -re "Quit this debugging session\\? \\(y or n\\) $" { 140918 send_gdb "n\n" answer 140919 incr count 140920 } 140921 -re "Create..." 140922 ("uplevel" body line 1) 140923 invoked from within 140924 "uplevel $body" NONE : spawn id exp11 not open 140925 ERROR: Could not resync from internal error (timeout) 140926 gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times 140927 UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes 140928 140929 I don't have a problem with the latter ERROR nor the UNRESOLVED 140930 messages. However the first ERROR regarding the exp11 spawn id 140931 not being open is not especially useful. 140932 140933 This commit handles the "Recursive internal problem" case, avoiding 140934 the problematic ERROR shown above. 140935 140936 With this commit in place, the log messages look like this instead: 140937 140938 A problem internal to GDB has been detected, 140939 further debugging may prove unreliable. 140940 Quit this debugging session? (y or n) Recursive internal problem. 140941 FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error) 140942 Resyncing due to internal error. 140943 ERROR: Could not resync from internal error (recursive internal problem) 140944 gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times 140945 UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes 140946 140947 gdb/testsuite/ChangeLog: 140948 140949 * lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive 140950 internal problem". 140951 1409522022-02-26 GDB Administrator <gdbadmin@sourceware.org> 140953 140954 Automatic date update in version.in 140955 1409562022-02-25 Aaron Merey <amerey@redhat.com> 140957 140958 gdb-add-index: disable debuginfod 140959 gdb-add-index may trigger debuginfod's first-use notice. The notice 140960 is misleading in this case. It instructs the user to modify .gdbinit 140961 in order to permanently enable/disable debuginfod but gdb-add-index 140962 invokes gdb with -nx which ignores .gdbinit. 140963 140964 Additionally debuginfod is not needed for gdb-add-index since the 140965 symbol file is given as an argument and should already be present 140966 locally. 140967 140968 Fix this by disabling debuginfod when gdb-add-index invokes gdb. 140969 1409702022-02-25 Andrew Burgess <aburgess@redhat.com> 140971 140972 gdb: add operator+= and operator+ overload for std::string 140973 This commit adds operator+= and operator+ overloads for adding 140974 gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3 140975 places in GDB where this was useful right now, and these all make use 140976 of operator+=. 140977 140978 I've also added a self test for gdb::unique_xmalloc_ptr<char>, which 140979 makes use of both operator+= and operator+, so they are both getting 140980 used/tested. 140981 140982 There should be no user visible changes after this commit, except when 140983 running 'maint selftest', where the new self test is visible. 140984 1409852022-02-25 Tom Tromey <tromey@adacore.com> 140986 140987 Print MI prompt on interrupted command 140988 Joel noticed that if the remote dies unexpectedly during a command -- 140989 you can simulate this by using "continue" and then killing gdbserver 140990 -- then the CLI will print a new prompt, but MI will not. Later, we 140991 found out that this was also filed in bugzilla as PR mi/23820. 140992 140993 The output looks something like this: 140994 140995 | (gdb) 140996 | cont 140997 | &"cont\n" 140998 | ~"Continuing.\n" 140999 | ^running 141000 | *running,thread-id="all" 141001 | (gdb) 141002 | [... some output from GDB during program startup...] 141003 | =thread-exited,id="1",group-id="i1" 141004 | =thread-group-exited,id="i1" 141005 | &"Remote connection closed\n" 141006 141007 Now, what about that "(gdb)" in the middle? 141008 141009 That prompt comes from this questionable code in 141010 mi-interp.c:mi_on_resume_1: 141011 141012 /* This is what gdb used to do historically -- printing prompt 141013 even if it cannot actually accept any input. This will be 141014 surely removed for MI3, and may be removed even earlier. */ 141015 if (current_ui->prompt_state == PROMPT_BLOCKED) 141016 fputs_unfiltered ("(gdb) \n", mi->raw_stdout); 141017 141018 ... which seems like something to remove. But maybe the intent here 141019 is that this prompt is sufficient, and MI clients must be ready to 141020 handle output coming after a prompt. On the other hand, if this code 141021 *is* removed, then nothing would print a prompt in this scenario. 141022 141023 Anyway, the CLI and the TUI handle emitting the prompt here by hooking 141024 into gdb::observers::command_error, but MI doesn't install an observer 141025 here. 141026 141027 This patch adds the missing observer and arranges to show the MI 141028 prompt. Regression tested on x86-64 Fedora 34. 141029 141030 It seems like this area could be improved a bit, by having 141031 start_event_loop call the prompt-displaying code directly, rather than 141032 indirecting through an observer. However, I haven't done this. 141033 141034 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820 141035 1410362022-02-25 Andrew Burgess <aburgess@redhat.com> 141037 Tom Tromey <tromey@adacore.com> 141038 141039 gdb/testsuite: fix list.exp test cases 141040 PR testsuite/7142 -- old enough to have been converted from Gnats -- 141041 points out that test_list_filename_and_function in gdb.base/list.exp 141042 has "fails" that are unmatched with passes. This patch cleans this up 141043 a little. 141044 141045 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142 141046 1410472022-02-25 Tsukasa OI <research_trasio@irq.a4lg.com> 141048 141049 RISC-V: Remove a loop in the ISA parser 141050 Since commit e601909a3287bf541c6a7d82214bb387d2c76d82 ("RISC-V: Support 141051 to parse the multi-letter prefix in the architecture string.") changed 141052 so that all prefixed extensions are parsed in single 141053 riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset 141054 is no longer required. 141055 141056 bfd/ChangeLog: 141057 141058 * elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop. 141059 1410602022-02-25 Tsukasa OI <research_trasio@irq.a4lg.com> 141061 141062 RISC-V: Fix mask for some fcvt instructions 141063 This commit fixes incorrect uses of mask values in 'fcvt' instruction 141064 family. 141065 141066 opcodes/ChangeLog: 141067 141068 * riscv-opc.c (riscv_opcodes): Fix incorrect uses of mask values 141069 in 'fcvt' instruction family. 141070 1410712022-02-25 Keith Seitz <keiths@redhat.com> 141072 141073 Support template lookups in strncmp_iw_with_mode 141074 This patch adds support for wild template parameter list matches, similar 141075 to how ABI tags or function overloads are now handled. 141076 141077 With this patch, users will be able to "gloss over" the details of matching 141078 template parameter lists. This is accomplished by adding (yet more) logic 141079 to strncmp_iw_with_mode to skip parameter lists if none is explicitly given 141080 by the user. 141081 141082 Here's a simple example using gdb.linespec/cpls-ops.exp: 141083 141084 Before 141085 ------ 141086 (gdb) ptype test_op_call 141087 type = struct test_op_call { 141088 public: 141089 void operator()(void); 141090 void operator()(int); 141091 void operator()(long); 141092 void operator()<int>(int *); 141093 } 141094 (gdb) b test_op_call::operator() 141095 Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations) 141096 (gdb) i b 141097 Num Type Disp Enb Address What 141098 1 breakpoint keep y <MULTIPLE> 141099 1.1 y 0x400583 in test_op_call::operator()(int) 141100 at cpls-ops.cc:43 141101 1.2 y 0x40058e in test_op_call::operator()() 141102 at cpls-ops.cc:47 141103 1.3 y 0x40059e in test_op_call::operator()(long) 141104 at cpls-ops.cc:51 141105 141106 The breakpoint at test_op_call::operator()<int> was never set. 141107 141108 After 141109 ----- 141110 (gdb) b test_op_call::operator() 141111 Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations) 141112 (gdb) i b 141113 Num Type Disp Enb Address What 141114 1 breakpoint keep y <MULTIPLE> 141115 1.1 y 0x400583 in test_op_call::operator()(int) 141116 at cpls-ops.cc:43 141117 1.2 y 0x40058e in test_op_call::operator()() 141118 at cpls-ops.cc:47 141119 1.3 y 0x40059e in test_op_call::operator()(long) 141120 at cpls-ops.cc:51 141121 1.4 y 0x4008d0 in test_op_call::operator()<int>(int*) 141122 at cpls-ops.cc:57 141123 141124 Similar to how scope lookups work, passing "-qualified" to the break command 141125 will cause a literal lookup of the symbol. In the example immediately above, 141126 this will cause GDB to only find the three non-template functions. 141127 1411282022-02-25 Keith Seitz <keiths@redhat.com> 141129 141130 Unit tests for strncmp_iw_with_mode 141131 This patch attempts to make a start at adding unit tests for 141132 strncmp_iw_with_mode. While there is quite a bit of testing 141133 of this function in other tests, these are currently end-to-end 141134 tests. 141135 141136 This patch attempts to cover the basics of string matching, white 141137 space, C++ ABI tags, and several other topics. However, one area 141138 that is ostensibly missing is testing the `match_for_lcd' feature. 141139 This is otherwise tested as part of our end-to-end DejaGNU-based 141140 testing. 141141 1411422022-02-25 Keith Seitz <keiths@redhat.com> 141143 141144 Move find_toplevel_char to cp-support.[ch] 141145 find_toplevel_char is being used more and more outside of linespec.c, so 141146 this patch moves it into cp-support.[ch]. 141147 1411482022-02-25 GDB Administrator <gdbadmin@sourceware.org> 141149 141150 Automatic date update in version.in 141151 1411522022-02-24 Tom Tromey <tom@tromey.com> 141153 Andrew Burgess <aburgess@redhat.com> 141154 141155 Fix crash in Fortran code 141156 PR fortran/28801 points out a gdb crash that can be provoked by 141157 certain Fortran code. The bug is that f77_get_upperbound assumes the 141158 property is either a constant or undefined, but in this case it is 141159 PROP_LOCEXPR. 141160 141161 This patch fixes the crash by making this function (and the 141162 lower-bound one as well) do the correct check before calling 141163 'const_val'. 141164 141165 Thanks to Andrew for writing the test case. 141166 141167 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801 141168 1411692022-02-24 John Baldwin <jhb@FreeBSD.org> 141170 141171 Revert "do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async." 141172 Commit 14b3360508b1 ("do_target_wait_1: Clear 141173 TARGET_WNOHANG if the target isn't async.") broke some multi-target 141174 tests, such as gdb.multi/multi-target-info-inferiors.exp. The symptom 141175 is that execution just hangs at some point. What happens is: 141176 141177 1. One remote inferior is started, and now sits stopped at a breakpoint. 141178 It is not "async" at this point (but it "can async"). 141179 141180 2. We run a native inferior, the event loop gets woken up by the native 141181 target's fd. 141182 141183 3. In do_target_wait, we randomly choose an inferior to call target_wait 141184 on first, it happens to be the remote inferior. 141185 141186 4. Because the target is currently not "async", we clear 141187 TARGET_WNOHANG, resulting in synchronous wait. We therefore block 141188 here: 141189 141190 #0 0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6 141191 #1 0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31 141192 #2 0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134 141193 #3 0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240 141194 #4 0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365 141195 #5 0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444 141196 #6 0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471 141197 #7 0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393 141198 #8 0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446 141199 #9 0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928 141200 #10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037 141201 #11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147 141202 #12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337 141203 #13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612 141204 #14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636 141205 #15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697 141206 #16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716 141207 #17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061 141208 141209 Before the aforementioned commit, we would not have cleared 141210 TARGET_WNOHANG, the remote target's wait would have returned nothing, 141211 and we would have consumed the native target's event. 141212 141213 After applying this revert, the testsuite state looks as good as before 141214 for me on Ubuntu 20.04 amd64. 141215 141216 Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f 141217 1412182022-02-24 Andrew Burgess <aburgess@redhat.com> 141219 141220 gdb: use a range based for loop when iterating over an array 141221 Make use of a range based for loop to iterate over a static global 141222 array, removing the need to have a null entry at the end of the 141223 array. 141224 141225 There should be no user visible changes after this commit. 141226 1412272022-02-24 Dominique Quatravaux <dominique.quatravaux@epfl.ch> 141228 Louis-He <1726110778@qq.com> 141229 Philippe Blain <levraiphilippeblain@gmail.com> 141230 141231 gdb/darwin: skip over WIFSTOPPED wait4 status 141232 On modern Darwin's, there appears to be a new circumstance in which a 141233 MACH_NOTIFY_DEAD_NAME message can be received, and which was not 141234 previously accounted for: to signal the WIFSTOPPED condition in the 141235 debuggee. In that case the debuggee is not dead yet (and in fact, 141236 counting it as dead would cause a zombie leak - A process in such a 141237 state reparents to PID 1, but cannot be killed). 141238 141239 - Read and ignore such messages (counting on the next exception message 141240 to let us know of the inferior's new state again) 141241 - Refactor logging so as to clearly distinguish between the 141242 MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or 141243 something else), and warn in the last case 141244 141245 Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1 141246 1412472022-02-24 Simon Marchi <simon.marchi@polymtl.ca> 141248 141249 gdb/linux-tdep: move "Perms" column right 141250 Commit 29ef4c0699e1 ("gdb/linux-tdep.c: Add Perms to the 'info proc 141251 mappings' output") has broken test gdb.base/info-proc.exp on Linux, 141252 because it changes the output of "info proc mappings" in a way that the 141253 test does not expect (my bad for not testing before pushing). 141254 141255 I looked at how FreeBSD handles this, since I remembered it did show 141256 permission flags. It looks like this: 141257 141258 Start Addr End Addr Size Offset Flags File 141259 0x200000 0x243000 0x43000 0x0 r-- CN-- /usr/local/bin/tmux 141260 141261 (I think that `Flags` and the flags not being aligned is not 141262 intentional) 141263 141264 The test passes on FreeBSD, because the test looks for four hex numbers 141265 in a row and ignores the rest: 141266 141267 ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*" 141268 141269 I suggest fixing it on Linux by moving the flags column to the same 141270 place as in the FreeBSD output. It makes things a bit more consistent 141271 between OSes, and we don't have to touch the test. 141272 141273 At the same time, make use of the actual length of the permission's 141274 string to specify the number of characters to print. 141275 141276 Before this patch, the output looks like: 141277 141278 Start Addr End Addr Perms Size Offset objfile 141279 0x55dd4b544000 0x55dd4b546000 r--p 0x2000 0x0 /usr/bin/sleep 141280 141281 and after, it looks like: 141282 141283 Start Addr End Addr Size Offset Perms objfile 141284 0x5622ae662000 0x5622ae664000 0x2000 0x0 r--p /usr/bin/sleep 141285 141286 Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f 141287 1412882022-02-24 Simon Marchi <simon.marchi@polymtl.ca> 141289 141290 gdb/linux-tdep: make read_mapping return a structure 141291 Change read_mapping to return a structure instead of taking many output 141292 parameters. Change the string + length output parameters (permissions 141293 and device) to be gdb::string_view, since that's what string_view is 141294 for (a non-NULL terminated view on a string). No changes in behavior 141295 expected. 141296 141297 Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112 141298 1412992022-02-24 GDB Administrator <gdbadmin@sourceware.org> 141300 141301 Automatic date update in version.in 141302 1413032022-02-23 Tom Tromey <tromey@adacore.com> 141304 141305 Fix bug in C++ overload resolution 141306 PR c++/28901 points out a bug in C++ overload resolution. When 141307 comparing two overloads, one might be better than the other for 141308 certain parameters -- but, if that one also has some invalid 141309 conversion, then it should never be considered the better choice. 141310 Instead, a valid-but-not-apparently-quite-as-good overload should be 141311 preferred. 141312 141313 This patch fixes this problem by changing how overload comparisons are 141314 done. I don't believe it should affect any currently valid overload 141315 resolution; nor should it affect resolutions where all the choices are 141316 equally invalid. 141317 1413182022-02-23 Dominik 'Disconnect3d' Czarnota <dominik.b.czarnota@gmail.com> 141319 141320 gdb/linux-tdep.c: Add Perms to the 'info proc mappings' output 141321 Fixes #28914 and so it adds a 'Perms' (permissions) column to the 141322 'info proc mappings' command output. This will allow users to know 141323 the memory pages permissions right away from GDB instead of having 141324 to fetch them from the /proc/$pid/maps file (which is also what GDB 141325 does internally, but it just did not print that column). 141326 141327 Below I am also showing how an example output looks like before and 141328 after this commit in case someone wonders. 141329 141330 On i386 targets - before this commit: 141331 ``` 141332 (gdb) info proc mappings 141333 process 3461464 141334 Mapped address spaces: 141335 141336 Start Addr End Addr Size Offset objfile 141337 0x56555000 0x56556000 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out 141338 0x56556000 0x56557000 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out 141339 0x56557000 0x56558000 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141340 0x56558000 0x5655a000 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141341 0xf7fc4000 0xf7fc8000 0x4000 0x0 [vvar] 141342 0xf7fc8000 0xf7fca000 0x2000 0x0 [vdso] 141343 0xf7fca000 0xf7fcb000 0x1000 0x0 /usr/lib/i386-linux-gnu/ld-2.33.so 141344 0xf7fcb000 0xf7fee000 0x23000 0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so 141345 0xf7fee000 0xf7ffb000 0xd000 0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so 141346 0xf7ffb000 0xf7ffe000 0x3000 0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so 141347 0xfffdc000 0xffffe000 0x22000 0x0 [stack] 141348 (gdb) 141349 ``` 141350 141351 On i386 targets - after this commit: 141352 ``` 141353 (gdb) info proc mappings 141354 process 3461464 141355 Mapped address spaces: 141356 141357 Start Addr End Addr Perms Size Offset objfile 141358 0x56555000 0x56556000 r--p 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out 141359 0x56556000 0x56557000 r-xp 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out 141360 0x56557000 0x56558000 r--p 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141361 0x56558000 0x5655a000 rw-p 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141362 0xf7fc4000 0xf7fc8000 r--p 0x4000 0x0 [vvar] 141363 0xf7fc8000 0xf7fca000 r-xp 0x2000 0x0 [vdso] 141364 0xf7fca000 0xf7fcb000 r--p 0x1000 0x0 /usr/lib/i386-linux-gnu/ld-2.33.so 141365 0xf7fcb000 0xf7fee000 r-xp 0x23000 0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so 141366 0xf7fee000 0xf7ffb000 r--p 0xd000 0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so 141367 0xf7ffb000 0xf7ffe000 rw-p 0x3000 0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so 141368 0xfffdc000 0xffffe000 rw-p 0x22000 0x0 [stack] 141369 (gdb) 141370 ``` 141371 141372 On amd64 targets - after this commit: 141373 ``` 141374 (gdb) info proc mappings 141375 process 3461869 141376 Mapped address spaces: 141377 141378 Start Addr End Addr Perms Size Offset objfile 141379 0x555555554000 0x555555555000 r--p 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out 141380 0x555555555000 0x555555556000 r-xp 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out 141381 0x555555556000 0x555555557000 r--p 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141382 0x555555557000 0x555555559000 rw-p 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out 141383 0x7ffff7fc3000 0x7ffff7fc7000 r--p 0x4000 0x0 [vvar] 141384 0x7ffff7fc7000 0x7ffff7fc9000 r-xp 0x2000 0x0 [vdso] 141385 0x7ffff7fc9000 0x7ffff7fca000 r--p 0x1000 0x0 /usr/lib/x86_64-linux-gnu/ld-2.33.so 141386 0x7ffff7fca000 0x7ffff7ff1000 r-xp 0x27000 0x1000 /usr/lib/x86_64-linux-gnu/ld-2.33.so 141387 0x7ffff7ff1000 0x7ffff7ffb000 r--p 0xa000 0x28000 /usr/lib/x86_64-linux-gnu/ld-2.33.so 141388 0x7ffff7ffb000 0x7ffff7fff000 rw-p 0x4000 0x31000 /usr/lib/x86_64-linux-gnu/ld-2.33.so 141389 0x7ffffffdd000 0x7ffffffff000 rw-p 0x22000 0x0 [stack] 141390 0xffffffffff600000 0xffffffffff601000 --xp 0x1000 0x0 [vsyscall] 141391 (gdb) 141392 ``` 141393 141394 Change-Id: I4991f6cc758cd532eae3ae98c29d22e7bd9d9c36 141395 1413962022-02-23 Patrick O'Neill <patrick@rivosinc.com> 141397 141398 RISC-V: PR28733, add missing extension info to 'unrecognized opcode' error 141399 Currently we report errors as "unrecognized opcode `fence.i'" when the 141400 opcode isn't part of the selected extensions. 141401 This patch expands that error message to include the missing extension 141402 information. For example, now the error message would be "unrecognized 141403 opcode `fence.i', extension `zifencei' required". 141404 If the opcode is not a part of any extension, the error message reverts 141405 to "unrecognized opcode `<op statement>'". 141406 141407 141408 bfd/ 141409 pr 28733 141410 * elfxx-riscv.c (riscv_multi_subset_supports_ext): New function, 141411 used to return the extension string for each INSN_CLASS_*. 141412 * elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext. 141413 gas/ 141414 pr 28733 141415 * config/tc-riscv.c (struct riscv_ip_error): New structure, 141416 contains information about errors that occur within the riscv_ip. 141417 (riscv_ip): Use struct riscv_ip_error to report more detailed errors. 141418 * testsuite/gas/riscv/c-fld-fsd-fail.l: Updated. 141419 * testsuite/gas/riscv/march-imply-i2p1-01.: Likewise. 141420 1414212022-02-23 Patrick O'Neill <patrick@rivosinc.com> 141422 141423 RISC-V: PR28733, add missing extension info to 'invalid CSR' error 141424 Currently we report errors as "invalid CSR 'fscr' for the current ISA" 141425 when the instruction isn't valid. 141426 141427 This patch expands that error message to include the missing extension 141428 information. For example, now the error message would be "invalid CSR 141429 'fscr' for the current ISA, CSR 'fscr' needs 'f' extension". 141430 141431 141432 gas/ 141433 pr 28733 141434 * config/tc-riscv.c (riscv_csr_address): Report more details 141435 when the CSR is invalid. 141436 * testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors. 141437 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 141438 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 141439 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 141440 1414412022-02-23 Alan Modra <amodra@gmail.com> 141442 141443 binutils 2.38 vs. ppc32 linux kernel 141444 Commit b25f942e18d6 made .machine more strict. Weaken it again. 141445 141446 * config/tc-ppc.c (ppc_machine): Treat an early .machine specially, 141447 keeping sticky options to work around gcc bugs. 141448 1414492022-02-23 Nelson Chu <nelson.chu@sifive.com> 141450 141451 RISC-V: Updated CSRs to privileged spec v1.12 and debug spec v1.0. 141452 * Removed N extension CSRs, 141453 ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip. 141454 141455 * Removed two supervisor CSRs, 141456 sedeleg and sideleg. 141457 141458 * Changed debug CSR address of scontext from 0x7aa to 0x5a8. We cannot support 141459 different versions of debug specs for now, so only supporting the latest one is 141460 the only way to move forward. 141461 141462 * Added debug CSRs, 141463 mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1). 141464 141465 * Regarded hcontext as a debug CSR. 141466 141467 include/ 141468 * opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and 141469 debug spec v1.0. 141470 gas/ 141471 * testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12 141472 and debug spec v1.0. 141473 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 141474 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 141475 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 141476 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 141477 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 141478 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 141479 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 141480 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 141481 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 141482 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 141483 * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. 141484 1414852022-02-23 Tsukasa OI <research_trasio@irq.a4lg.com> 141486 141487 RISC-V: Add Privileged Architecture 1.12 CSRs 141488 This commit adds, 141489 141490 * Most of CSRs as listed in the Privileged Architecture, 141491 version 1.12 (except scontext and mscontext). 141492 141493 * Testcases for most CSRs added on the Privileged 141494 Architecture, version 1.12 (except moved "scontext" and 141495 new "mscontext"). 141496 141497 include/ChangeLog: 141498 141499 * opcode/riscv-opc.h (CSR_SENVCFG, CSR_MCONFIGPTR, CSR_MENVCFG, 141500 CSR_MSTATUSH, CSR_MENVCFGH, CSR_MTINST, CSR_MTVAL2, CSR_MSECCFG, 141501 CSR_MSECCFGH, CSR_PMPCFG4, CSR_PMPCFG5, CSR_PMPCFG6, 141502 CSR_PMPCFG7, CSR_PMPCFG8, CSR_PMPCFG9, CSR_PMPCFG10, 141503 CSR_PMPCFG11, CSR_PMPCFG12, CSR_PMPCFG13, CSR_PMPCFG14, 141504 CSR_PMPCFG15, CSR_PMPADDR16, CSR_PMPADDR17, CSR_PMPADDR18, 141505 CSR_PMPADDR19, CSR_PMPADDR20, CSR_PMPADDR21, CSR_PMPADDR22, 141506 CSR_PMPADDR23, CSR_PMPADDR24, CSR_PMPADDR25, CSR_PMPADDR26, 141507 CSR_PMPADDR27, CSR_PMPADDR28, CSR_PMPADDR29, CSR_PMPADDR30, 141508 CSR_PMPADDR31, CSR_PMPADDR32, CSR_PMPADDR33, CSR_PMPADDR34, 141509 CSR_PMPADDR35, CSR_PMPADDR36, CSR_PMPADDR37, CSR_PMPADDR38, 141510 CSR_PMPADDR39, CSR_PMPADDR40, CSR_PMPADDR41, CSR_PMPADDR42, 141511 CSR_PMPADDR43, CSR_PMPADDR44, CSR_PMPADDR45, CSR_PMPADDR46, 141512 CSR_PMPADDR47, CSR_PMPADDR48, CSR_PMPADDR49, CSR_PMPADDR50, 141513 CSR_PMPADDR51, CSR_PMPADDR52, CSR_PMPADDR53, CSR_PMPADDR54, 141514 CSR_PMPADDR55, CSR_PMPADDR56, CSR_PMPADDR57, CSR_PMPADDR58, 141515 CSR_PMPADDR59, CSR_PMPADDR60, CSR_PMPADDR61, CSR_PMPADDR62, 141516 CSR_PMPADDR63): New CSR macros. 141517 141518 gas/ChangeLog: 141519 141520 * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. 141521 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 141522 * testsuite/gas/riscv/csr.s: Add new CSRs. 141523 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 141524 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 141525 * testsuite/gas/riscv/csr-version-1p10.d: Likewise. 141526 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 141527 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 141528 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 141529 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 141530 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 141531 1415322022-02-23 Tsukasa OI <research_trasio@irq.a4lg.com> 141533 141534 RISC-V: Reorganize testcases for CFI directives 141535 This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to 141536 make it test the same CSRs as csr.s. 141537 141538 gas/ChangeLog: 141539 141540 * testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add 141541 defined CSRs tested in csr.s. 141542 * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. 141543 1415442022-02-23 GDB Administrator <gdbadmin@sourceware.org> 141545 141546 Automatic date update in version.in 141547 1415482022-02-22 John Baldwin <jhb@FreeBSD.org> 141549 141550 NEWS: Note that the FreeBSD async target supports async mode. 141551 1415522022-02-22 John Baldwin <jhb@FreeBSD.org> 141553 141554 inf-ptrace: Add an event_pipe to be used for async mode in subclasses. 141555 Subclasses of inf_ptrace_target have to opt-in to using the event_pipe 141556 by implementing the can_async_p and async methods. For subclasses 141557 which do this, inf_ptrace_target provides is_async_p, async_wait_fd 141558 and closes the pipe in the close target method. 141559 141560 inf_ptrace_target also provides wrapper routines around the event pipe 141561 (async_file_open, async_file_close, async_file_flush, and 141562 async_file_mark) for use in target methods such as async. 141563 inf_ptrace_target also exports a static async_file_mark_if_open 141564 function which can be used in SIGCHLD signal handlers. 141565 1415662022-02-22 John Baldwin <jhb@FreeBSD.org> 141567 141568 Enable async mode in the target in attach_cmd. 141569 If the attach target supports async mode, enable it after the 141570 attach target's ::attach method returns. 141571 141572 fbsd-nat: Return nullptr rather than failing ::thread_name. 141573 ptrace on FreeBSD cannot be used against running processes and instead 141574 fails with EBUSY. This meant that 'info threads' would fail if any of 141575 the threads were running (for example when using schedule-multiple=on 141576 in gdb.base/fork-running-state.exp). Instead of throwing errors, just 141577 return nullptr as no thread name is better than causing info threads to 141578 fail completely. 141579 1415802022-02-22 John Baldwin <jhb@FreeBSD.org> 141581 141582 fbsd-nat: Various cleanups to the ::resume entry debug message. 141583 Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat' 141584 since it is helpful for debugging async target support and not just 141585 LWP support. 141586 141587 Use target_pid_to_str to format the ptid and log the step and signo 141588 arguments. 141589 1415902022-02-22 John Baldwin <jhb@FreeBSD.org> 141591 141592 fbsd-nat: Include ptrace operation in error messages. 141593 1415942022-02-22 John Baldwin <jhb@FreeBSD.org> 141595 141596 fbsd-nat: Implement async target support. 141597 This is a fairly simple version of async target support. 141598 141599 Synchronous mode still uses blocking waitpid() calls in 141600 inf_ptrace::wait() unlike the Linux native target which always uses 141601 WNOHANG and uses sigsuspend() for synchronous operation. 141602 141603 Asynchronous mode registers an event pipe with the core as a file 141604 handle and writes to the pipe when SIGCHLD is raised. TARGET_WNOHANG 141605 is handled by inf_ptrace::wait(). 141606 1416072022-02-22 John Baldwin <jhb@FreeBSD.org> 141608 141609 inf-ptrace: Support async targets in inf_ptrace_target::wait. 141610 - Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning 141611 TARGET_WAITKIND_IGNORE if there are no events to report. 141612 141613 - Handle a race in async mode where SIGCHLD might signal the event 141614 pipe for an event that has already been reported. If the event was 141615 the exit of the last child process, waitpid() will fail with ECHILD 141616 rather than returning a pid of 0. For this case, return 141617 TARGET_WAITKIND_NO_RESUMED. 141618 1416192022-02-22 John Baldwin <jhb@FreeBSD.org> 141620 141621 inf-ptrace: Return an IGNORE event if waitpid() fails. 141622 Previously this returned a TARGET_WAITKIND_SIGNALLED event for 141623 inferior_ptid. However, inferior_ptid is invalid during ::wait() 141624 methods after the multi-target changes, so this was triggering an 141625 assertion further up the stack. 141626 141627 do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async. 141628 Previously, TARGET_WNOHANG was cleared if a target supported async 141629 mode even if async mode wasn't currently enabled. This change only 141630 permits TARGET_WNOHANG if async mode is enabled. 141631 1416322022-02-22 John Baldwin <jhb@FreeBSD.org> 141633 141634 Don't enable async mode at the end of target ::resume methods. 141635 Now that target_resume always enables async mode after target::resume 141636 returns, these calls are redundant. 141637 141638 The other place that target resume methods are invoked outside of 141639 target_resume are as the beneath target in record_full_wait_1. In 141640 this case, async mode should already be enabled when supported by the 141641 target before the resume method is invoked due to the following: 141642 141643 In general, targets which support async mode run as async until 141644 ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are 141645 no unwaited for children (either they have exited or are stopped). 141646 When that occurs, the loop in wait_one disables async mode. Later 141647 if a stopped child is resumed, async mode is re-enabled in 141648 do_target_resume before waiting for the next event. 141649 141650 In the case of record_full_wait_1, this function is invoked from the 141651 ::wait target method when fetching an event. If the underlying 141652 target supports async mode, then an earlier call to do_target_resume 141653 to resume the child reporting an event in the loop in 141654 record_full_wait_1 would have already enabled async mode before 141655 ::wait was invoked. In addition, nothing in the code executed in 141656 the loop in record_full_wait_1 disables async mode. Async mode is 141657 only disabled higher in the call stack in wait_one after ::wait 141658 returns. 141659 141660 It is also true that async mode can be disabled by an 141661 INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of 141662 the places that invoke that are in the gdb core which is "above" a 141663 target ::wait method. 141664 141665 Note that there is an earlier call to enable async mode in 141666 linux_nat_target::resume. That call also marks the async event pipe 141667 to report an existing event after enabling async mode, so it needs to 141668 stay. 141669 1416702022-02-22 John Baldwin <jhb@FreeBSD.org> 141671 141672 Enable async mode on supported targets in target_resume. 141673 Enabling async mode above the target layer removes duplicate code in 141674 ::resume methods of async-capable targets. Commit 5b6d1e4fa4f 141675 ("Multi-target support") enabled async mode in do_target_resume after 141676 target_resume returns which is a step in this direction. However, 141677 other callers of target_resume such as target_continue do not enable 141678 async mode. Rather than enabling async mode in each of the callers 141679 after target_resume returns, enable async mode at the end of 141680 target_resume. 141681 141682 gdbserver linux-low: Convert linux_event_pipe to the event_pipe class. 141683 Use event_pipe from gdbsupport in place of the existing file 141684 descriptor array. 141685 141686 gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class. 141687 Use event_pipe from gdbsupport in place of the existing file 141688 descriptor array. 141689 1416902022-02-22 John Baldwin <jhb@FreeBSD.org> 141691 141692 gdbsupport: Add an event-pipe class. 141693 This pulls out the implementation of an event pipe used to implement 141694 target async support in both linux-low.cc (gdbserver) and linux-nat.c 141695 (gdb). 141696 141697 This will be used to replace the existing event pipe in linux-low.cc 141698 and linux-nat.c in future commits. 141699 141700 Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com> 141701 1417022022-02-22 Ruslan Kabatsayev <b7.10110111@gmail.com> 141703 141704 gdb: fix detection of compilation and linking flags for source-highlight 141705 Currently there are two problems with the detection of 141706 source-highlight via pkg-config in GDB's configure script: 141707 141708 1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output 141709 to AC_LINK_IFELSE, which results in the "-L/some/path 141710 -lsource-highlight" preceding the conftest.cpp, which can result in a 141711 failure to find symbols referenced in conftest.cpp, if the linker is 141712 using --as-needed by default. 141713 141714 2. The CFLAGS variable is used to pass the 'pkg-config --cflags' 141715 output to AC_LINK_IFELSE. However, as the current language is C++, 141716 AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags 141717 returned from pkg-config will not be seen. 141718 141719 This patch fixes both of these mistakes, allowing GDB to correctly 141720 configure and build using source-highlight installed into a custom 141721 prefix, e.g. ~/opt/gdb-git (because the system version of 141722 source-highlight is too old). 141723 1417242022-02-22 Philippe Blain <levraiphilippeblain@gmail.com> 141725 141726 gdb/testsuite/README: point to default value of INTERNAL_GDBFLAGS 141727 The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013 141728 ([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to 141729 disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07) 141730 to point to the data directory, but its default value mentioned in the 141731 testsuite's README was not kept up to date. 141732 141733 To avoid it getting out of sync even more, point the reader to the 141734 definition of the variable in lib/gdb.exp, and move the explanation of 141735 the different flags there. Also adjust the example in the README 141736 so it follows the flags added in 55c3ad88013. 141737 141738 Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7 141739 1417402022-02-22 Kito Cheng <kito.cheng@sifive.com> 141741 141742 RISC-V: Maintain a string to hold the canonical order 141743 Using dummy entry in riscv_supported_std_ext cause confusing and wrongly 141744 support `b` and `k` extensions. 141745 141746 bfd/ 141747 * elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported 141748 extensions. 141749 (riscv_ext_canonical_order): New. 141750 (riscv_init_ext_order): Use riscv_ext_canonical_order rather 141751 than riscv_supported_std_ext to compute canonical order. 141752 141753 V2 Changes: 141754 141755 - Use `*ext` rather than `*ext != NULL` for checking is reach end of 141756 string. 141757 1417582022-02-22 GDB Administrator <gdbadmin@sourceware.org> 141759 141760 Automatic date update in version.in 141761 1417622022-02-21 Alan Modra <amodra@gmail.com> 141763 141764 Re: ld: Support customized output section type 141765 "DO NOT EDIT!" says the comment at the top of bfd-in2.h. Move the new 141766 type field where it belongs. 141767 141768 PR ld/28841 141769 * section.c (struct bfd_section): Add type. Formatting. 141770 (BFD_FAKE_SECTION): Formatting. 141771 * bfd-in2.h: Regenerate. 141772 1417732022-02-21 Mike Frysinger <vapier@gentoo.org> 141774 141775 sim: gdbinit: hoist setup to common code 141776 This was left in subdirs because of the dynamic cgen usage. However, 141777 we can move this breakpoint call to runtime and let gdb detect whether 141778 the symbol exists. 141779 1417802022-02-21 Andrew Burgess <aburgess@redhat.com> 141781 141782 gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test 141783 I saw some failures in the test gdb.mi/mi-multi-commands.exp that I 141784 added recently. This test was added in commit: 141785 141786 commit d08cbc5d3203118da5583296e49273cf82378042 141787 Date: Wed Dec 22 12:57:44 2021 +0000 141788 141789 gdb: unbuffer all input streams when not using readline 141790 141791 The failures I see only occurred when my machine was very heavily 141792 loaded. 141793 141794 In this test I send multiple commands from dejagnu to gdb with a 141795 single send_gdb call. In a well behaving world what I want to happen 141796 is that the gdb console sees both commands arrive and echos the text 141797 of those commands. Then gdb starts processing the first command, 141798 prints the result, and then processes the second command, and prints 141799 the result. 141800 141801 However, what I saw in my loaded environment was that only after 141802 sending the two commands, only the first command was echoed to gdb's 141803 terminal. Then gdb started processing the first command, and started 141804 to write the output. Now, mixed in with the first command output, the 141805 second command was echoed to gdb's terminal. Finally, gdb would 141806 finish printing the first command output, and would read and handle 141807 the second command. 141808 141809 This mixing of command echoing with the first command output was 141810 causing the test matching patterns to fail. 141811 141812 In this commit I change the command I use in the test from a CLI 141813 command to an MI command, this reduces the number of lines of output 141814 that come from the test, CLI commands sent through the MI interpreter 141815 are echoed back like this: 141816 141817 (gdb) 141818 set $a = "FIRST COMMAND" 141819 &"set $a = \"FIRST COMMAND\"\n" 141820 ^done 141821 (gdb) 141822 141823 While this is not the case for true MI command: 141824 141825 (gdb) 141826 -data-evaluate-expression $a 141827 ^done,value="\"FIRST COMMAND\"" 141828 (gdb) 141829 141830 Less output makes for simpler patterns to match against. 141831 141832 Next, when sending two command to gdb I was previously trying to spot 141833 the output of the first command followed by the prompt with nothing 141834 between. This is not really needed, for the first command I can look 141835 for just the ^done,value="\"FIRST COMMAND\"" string, then I can start 141836 looking for the output of the second command. 141837 141838 So long as the second pattern matches up to the gdb prompt, then I can 141839 be sure than nothing is left over in the expect buffer to muck up 141840 later matches. 141841 141842 As to see the second command output gdb must have read in the second 141843 command, the second command output never suffers from the corruption 141844 that the first command output does. 141845 141846 Since making this change, I've not seen a failure in this test. 141847 1418482022-02-21 Andrew Burgess <aburgess@redhat.com> 141849 141850 gdb: avoid nullptr access in dbxread.c from read_dbx_symtab 141851 This fixes a GDB crash reported in bug pr/28900, related to reading in 141852 some stabs debug information. 141853 141854 In this commit my goal is to stop GDB crashing. I am not trying to 141855 ensure that GDB makes the best possible use of the available stabs 141856 debug information. At this point I consider stabs a legacy debug 141857 format, with only limited support in GDB. 141858 141859 So, the problem appears to be that, when reading in the stabs data, we 141860 need to find a N_SO entry, this is the entry that defines the start of 141861 a compilation unit (or at least the location of a corresponding source 141862 file). 141863 141864 It is while handling an N_SO that GDB creates a psymtab to hold the 141865 incoming debug information (symbols, etc). 141866 141867 The problem we hit in the bug is that we encounter some symbol 141868 information (an N_PC entry) outside of an N_SO entry - that is we find 141869 some symbol information that is not associated with any source file. 141870 141871 We already have some protection for this case, look (in 141872 read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f', 141873 if we have no psymtab (the pst variable is nullptr) then we issue a 141874 complaint. However, for whatever reason, in both 'f' and 'F' 141875 handling, there is one place where we assume that the pst 141876 variable (the psymtab) is not nullptr. This is a mistake. 141877 141878 In this commit, I guard these two locations (in 'f' and 'F' handling) 141879 so we no longer assume pst is not nullptr. 141880 141881 While I was at it, I audited all the other uses of pst in 141882 read_dbx_symtab, and in every potentially dangerous case I added a 141883 nullptr check, and issue a suitable complaint if pst is found to be 141884 nullptr. 141885 141886 It might well be true that we could/should do something smarter if we 141887 see a debug symbol outside of an N_SO entry, and if anyone wanted to 141888 do that work, they're welcome too. But this commit is just about 141889 preventing the nullptr access, and the subsequent GDB crash. 141890 141891 I don't have any tests for this change, I have no idea how to generate 141892 weird stabs data for testing. The original binary from the bug report 141893 now loads just fine without GDB crashing. 141894 141895 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28900 141896 1418972022-02-21 Andrew Burgess <aburgess@redhat.com> 141898 141899 gdb: make use of std::string in dbxread.c and xcoffread.c 141900 While taking a look through dbxread.c I spotted a couple of places 141901 where making use of std::string would remove the need for manual 141902 memory allocation and memcpy. 141903 141904 During review Simon pointed out that the same code exists in 141905 xcoffread.c, so I've applied the same fix there too. 141906 141907 There should be no user visible changes after this commit. 141908 1419092022-02-21 GDB Administrator <gdbadmin@sourceware.org> 141910 141911 Automatic date update in version.in 141912 1419132022-02-20 Lancelot SIX <lancelot.six@amd.com> 141914 141915 gdb: Only paginate for filtered output in fputs_maybe_filtered 141916 A have had situation where a unfiltered output (done using 141917 fputs_unfiltered) ended up triggering pagination. The backtrace for this was: 141918 141919 ... 141920 #24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335 141921 #25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216 141922 #26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148 141923 #27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438 141924 #28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752 141925 #29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811 141926 ... 141927 141928 This comes from what appears to be a oversight in fputs_maybe_filtered. This 141929 function has a FILTER parameter which if true makes the function pause after 141930 every screenful (i.e. triggers pagination). 141931 141932 The filter parameter is correctly used to guard the first place where 141933 prompt_for_continue. There is a second place in the function which can call 141934 prompt_for_continue, but is currently unguarded. I believe that this is an 141935 oversight, this patch fixes that. 141936 141937 Tested on Linux-x86_64, no regression observed. 141938 141939 Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece 141940 1419412022-02-20 GDB Administrator <gdbadmin@sourceware.org> 141942 141943 Automatic date update in version.in 141944 1419452022-02-19 Dominique Quatravaux <dominique.quatravaux@epfl.ch> 141946 141947 gdb/darwin: remove not-so-harmless spurious call to `wait4` 141948 As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this 141949 code will typically wait4() a second time on the same process that was 141950 already wait4()'d a few lines above. While this used to be 141951 harmless/idempotent (when we assumed that the process already exited), 141952 this now causes a deadlock in the WIFSTOPPED case. 141953 141954 The early (~2019) history of bug #24069 cautiously suggests to use 141955 WNOHANG instead of outright deleting the call. However, tests on the 141956 current version of Darwin (Big Sur) demonstrate that gdb runs just fine 141957 without a redundant call to wait4(), as would be expected. 141958 Notwithstanding the debatable value of conserving bug compatibility with 141959 an OS release that is more than a decade old, there is scant evidence of 141960 what that double-wait4() was supposed to achieve in the first place - A 141961 cursory investigation with `git blame` pinpoints commits bb00b29d7802 141962 and a80b95ba67e2 from the 2008-2009 era, but fails to answer the 141963 "why" question conclusively. 141964 141965 Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com> 141966 Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0 141967 1419682022-02-19 GDB Administrator <gdbadmin@sourceware.org> 141969 141970 Automatic date update in version.in 141971 1419722022-02-18 Tom Tromey <tromey@adacore.com> 141973 141974 Add constructor to bound_minimal_symbol 141975 This adds a constructor to bound_minimal_symbol, to avoid a build 141976 failure with clang that Simon pointed out. 141977 141978 I also took the opportunity to remove some redundant initializations, 141979 and to change one use of push_back to emplace_back, as suggested by 141980 Simon. 141981 1419822022-02-18 Roland McGrath <mcgrathr@google.com> 141983 141984 Fix typo in ld.texi 141985 ld/ 141986 * ld.texi (Output Section Type): Fix typo in @code syntax. 141987 1419882022-02-18 Simon Marchi <simon.marchi@polymtl.ca> 141989 141990 gdb: remove newlines from some linux_nat_debug_printf calls 141991 Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10 141992 1419932022-02-18 GDB Administrator <gdbadmin@sourceware.org> 141994 141995 Automatic date update in version.in 141996 1419972022-02-17 Nick Clifton <nickc@redhat.com> 141998 141999 Updated Serbian translations for the bfd, gold, ld and opcodes directories 142000 1420012022-02-17 GDB Administrator <gdbadmin@sourceware.org> 142002 142003 Automatic date update in version.in 142004 1420052022-02-16 Fangrui Song <maskray@google.com> 142006 142007 ld: Support customized output section type 142008 bfd/ 142009 PR ld/28841 142010 * bfd-in2.h (struct bfd_section): Add type. 142011 (discarded_section): Add field. 142012 * elf.c (elf_fake_sections): Handle bfd_section::type. 142013 * section.c (BFD_FAKE_SECTION): Add field. 142014 * mri.c (mri_draw_tree): Update function call. 142015 142016 ld/ 142017 PR ld/28841 142018 * ld.texi: Document new output section type. 142019 * ldlex.l: Add new token TYPE. 142020 * ldgram.y: Handle TYPE=exp. 142021 * ldlang.h: Add type_section to list of section types. 142022 * ldlang.c (lang_add_section): Handle type_section. 142023 (map_input_to_output_sections): Handle type_section. 142024 * testsuite/ld-scripts/output-section-types.t: Add tests. 142025 * testsuite/ld-scripts/output-section-types.d: Update. 142026 1420272022-02-16 Andrew Burgess <aburgess@redhat.com> 142028 142029 gdb/tui: add a missing white space character 142030 Just adds a missing space. There should be no user visible changes 142031 after this commit. 142032 142033 gdb: convert callback_handler_installed from int to bool 142034 Simple int to bool conversion on callback_handler_installed in 142035 event-top.c. There should be no user visible changes after this 142036 commit. 142037 1420382022-02-16 Alan Modra <amodra@gmail.com> 142039 142040 gas local label and dollar label handling 142041 Much of the gas source and older BFD source use "long" for function 142042 parameters and variables, when other types would be more appropriate. 142043 This patch fixes one of those cases. Dollar labels and numeric local 142044 labels do not need large numbers. Small positive itegers are usually 142045 all that is required. Due to allowing longs, it was possible for 142046 fb_label_name and dollar_label_name to overflow their buffers. 142047 142048 * symbols.c: Delete unnecessary forward declarations. 142049 (dollar_labels, dollar_label_instances): Use unsigned int. 142050 (dollar_label_defined, dollar_label_instance): Likewise. 142051 (define_dollar_label): Likewise. 142052 (fb_low_counter, fb_labels, fb_label_instances): Likewise. 142053 (fb_label_instance_inc, fb_label_instance): Likewise. 142054 (fb_label_count, fb_label_max): Make them size_t. 142055 (dollar_label_name, fb_label_name): Rewrite using sprintf. 142056 * symbols.h (dollar_label_defined): Update prototype. 142057 (define_dollar_label, dollar_label_name): Likewise. 142058 (fb_label_instance_inc, fb_label_name): Likewise. 142059 * config/bfin-lex.l (yylex): Remove unnecessary casts. 142060 * expr.c (integer_constant): Likewise. 142061 * read.c (read_a_source_file): Limit numeric label range to int. 142062 1420632022-02-16 Alan Modra <amodra@gmail.com> 142064 142065 ubsan: s_app_line integer overflow 142066 There are quite a few ubsan warnings in gas. This one disappears with 142067 a code tidy. 142068 142069 * read.c (s_app_line): Rename 'l' to 'linenum'. Avoid ubsan 142070 warning. 142071 1420722022-02-16 Alan Modra <amodra@gmail.com> 142073 142074 pe_ILF_make_a_symbol_reloc segfault 142075 pei-aarch64-little apparently lacks support for BFD_RELOC_RVA. 142076 142077 * peicode.h (pe_ILF_make_a_symbol_reloc): Don't segfault on 142078 NULL howto. 142079 1420802022-02-16 Alan Modra <amodra@gmail.com> 142081 142082 What to do when sh_addralign isn't a power of two 142083 BFD generally doesn't handle anything but a power of two section 142084 alignment, and ELF sh_addralign is required to be an integral power of 142085 two (or zero) by the ELF spec. Of course this is ignored by fuzzers, 142086 and because bfd_log2 rounds up, we can end up with alignment_power 142087 being 32 on a 32-bit object or 64 on a 64-bit object. That then 142088 triggers ubsan warnings in places like bfd_update_compression_header 142089 where we want to convert from alignment_power back to an alignment. 142090 I suppose we could reject object files that have non-compliant 142091 sh_addralign, but I think it's also reasonable to use the greatest 142092 power of two divisor of sh_addralign, ie. the rightmost 1 bit. 142093 142094 * elf.c (_bfd_elf_make_section_from_shdr): Use greatest power 142095 of two divisor of sh_addralign. 142096 (_bfd_elf_assign_file_position_for_section): Likewise. 142097 (assign_file_positions_for_non_load_sections): Likewise. 142098 1420992022-02-16 Alan Modra <amodra@gmail.com> 142100 142101 asan: buffer overflow in vms-alpha.c 142102 * vms-alpha.c (evax_bfd_print_dst): Sanity check another place 142103 printing strings. 142104 142105 asan : use of uninitialized value in buffer_and_nest 142106 * macro.c (buffer_and_nest): Don't read past end of string buffer. 142107 142108 asan: buffer overflow in peXXigen.c 142109 * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Properly 142110 sanity check DataDirectory[PE_DEBUG_DATA].Size. 142111 1421122022-02-16 Hans-Peter Nilsson <hp@axis.com> 142113 142114 sim/common: Improve sim_dump_memory head comment 142115 As requested by Mike. 142116 142117 * sim-memopt.c: Improve head comment. 142118 1421192022-02-16 Hans-Peter Nilsson <hp@axis.com> 142120 142121 sim/testsuite/cris/c/stat3.c: Fix formatting nit 142122 * c/stat3.c (main): Fix formatting nit. 142123 1421242022-02-16 Mike Frysinger <vapier@gentoo.org> 142125 142126 sim: testsuite: cleanup the istarget * logic 142127 Now that the multitarget testing has settled, clean up the cases where 142128 istarget * is used. This ends up being mostly style unindenting. 142129 1421302022-02-16 GDB Administrator <gdbadmin@sourceware.org> 142131 142132 Automatic date update in version.in 142133 1421342022-02-15 H.J. Lu <hjl.tools@gmail.com> 142135 142136 i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL 142137 Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation 142138 in read-only section. 142139 142140 bfd/ 142141 142142 PR ld/28894 142143 * elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow 142144 R_386_TLS_IE. 142145 142146 ld/ 142147 PR ld/28894 142148 * testsuite/ld-i386/i386.exp: Run pr28894. 142149 * testsuite/ld-i386/pr28894.d: New file. 142150 * testsuite/ld-i386/pr28894.s: Likewise. 142151 1421522022-02-15 Hans-Peter Nilsson <hp@axis.com> 142153 142154 sim/testsuite: Default global_cc_os and global_cc_works properly 142155 There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set 142156 global_cc_os also when no compiler is found"; global_cc_os 142157 wasn't set for other than the primary target, which means 142158 that the "unguarded" use of global_cc_os in 142159 testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read 142160 "global_cc_os": no such variable" when e.g. configuring for 142161 pru-elf and doing "make check-sim". Better initializing 142162 both variables at the top to default values, rather than 142163 adding another single 'set global_cc_os ""', to reduce the 142164 risk of not setting them properly if or when that 142165 if-statement-chain is made longer. 142166 142167 sim/testsuite: 142168 * lib/sim-defs.exp (sim_init_toolchain): Default 142169 global_cc_os and global_cc_works properly, before if-chain. 142170 1421712022-02-15 H.J. Lu <hjl.tools@gmail.com> 142172 142173 x86: Add has_sib to struct instr_info 142174 Add has_sib to struct instr_info and use SIB info only if ins->has_sib 142175 is true. 142176 142177 PR binutils/28892 142178 * i386-dis.c (instr_info): Add has_sib. 142179 (get_sib): Set has_sib. 142180 (OP_E_memory): Replace havesib with ins->has_sib. 142181 (OP_VEX): Use ins->sib.index only if ins->has_sib is true. 142182 1421832022-02-15 Lancelot SIX <lancelot.six@amd.com> 142184 142185 gdb: Respect the DW_CC_nocall attribute 142186 It is possible for a compiler to optimize a function in a such ways that 142187 the function does not follow the calling convention of the target. In 142188 such situation, the compiler can use the DW_AT_calling_convention 142189 attribute with the value DW_CC_nocall to tell the debugger that it is 142190 unsafe to call the function. The DWARF5 standard states, in 3.3.1.1: 142191 142192 > If the value of the calling convention attribute is the constant 142193 > DW_CC_nocall, the subroutine does not obey standard calling 142194 > conventions, and it may not be safe for the debugger to call this 142195 > subroutine. 142196 142197 Non standard calling convention can affect GDB's assumptions in multiple 142198 ways, including how arguments are passed to the function, how values are 142199 returned, and so on. For this reason, it is unsafe for GDB to try to do 142200 the following operations on a function with marked with DW_CC_nocall: 142201 142202 - call / print an expression requiring the function to be evaluated, 142203 - inspect the value a function returns using the 'finish' command, 142204 - force the value returned by a function using the 'return' command. 142205 142206 This patch ensures that if a command which relies on GDB's knowledge of 142207 the target's calling convention is used on a function marked nocall, GDB 142208 prints an appropriate message to the user and does not proceed with the 142209 operation which is unreliable. 142210 142211 Note that it is still possible for someone to use a vendor specific 142212 value for the DW_AT_calling_convention attribute for example to indicate 142213 the use of an alternative calling convention. This commit does not 142214 prevent this, and target dependent code can be adjusted if one wanted to 142215 support multiple calling conventions. 142216 142217 Tested on x86_64-Linux, with no regression observed. 142218 142219 Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540 142220 1422212022-02-15 Lancelot SIX <lancelot.six@amd.com> 142222 Simon Marchi <simon.marchi@polymtl.ca> 142223 142224 gdb: add a symbol* argument to get_return_value 142225 Add an argument to the get_return_value function to indicate the symbol 142226 of the function the debuggee is returning from. This will be used by 142227 the following patch. 142228 142229 Since the function return type can be deduced from the symbol remove the 142230 value_type argument which becomes redundant. 142231 142232 No user visible change after this patch. 142233 142234 Tested on x86_64-linux. 142235 142236 Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc 142237 1422382022-02-15 H.J. Lu <hjl.tools@gmail.com> 142239 142240 x86-64: Use MAXPAGESIZE for the relro segment alignment 142241 Adjust x86-64 linker tests after reverting 142242 142243 commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be 142244 Author: Alan Modra <amodra@gmail.com> 142245 Date: Thu Feb 3 08:57:47 2022 +1030 142246 142247 PR28824, relro security issues, x86 keep COMMONPAGESIZE relro 142248 142249 to use MAXPAGESIZE for the end of the relro segment alignment, like other 142250 ELF targets. 142251 142252 * testsuite/ld-x86-64/plt-main-bnd.dd: Updated. 142253 * testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise. 142254 * testsuite/ld-x86-64/plt-main-ibt.dd: Likewise. 142255 * testsuite/ld-x86-64/pr14207.d: Likewise. 142256 * testsuite/ld-x86-64/pr18176.d: Likewise. 142257 * testsuite/ld-x86-64/pr20830a-now.d: Likewise. 142258 * testsuite/ld-x86-64/pr20830a.d: Likewise. 142259 * testsuite/ld-x86-64/pr20830b-now.d: Likewise. 142260 * testsuite/ld-x86-64/pr20830b.d: Likewise. 142261 * testsuite/ld-x86-64/pr21038a-now.d: Likewise. 142262 * testsuite/ld-x86-64/pr21038a.d: Likewise. 142263 * testsuite/ld-x86-64/pr21038b-now.d: Likewise. 142264 * testsuite/ld-x86-64/pr21038b.d: Likewise. 142265 * testsuite/ld-x86-64/pr21038c-now.d: Likewise. 142266 * testsuite/ld-x86-64/pr21038c.d: Likewise. 142267 1422682022-02-15 H.J. Lu <hjl.tools@gmail.com> 142269 142270 Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro" 142271 This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be. 142272 1422732022-02-15 GDB Administrator <gdbadmin@sourceware.org> 142274 142275 Automatic date update in version.in 142276 1422772022-02-14 Hans-Peter Nilsson <hp@axis.com> 142278 142279 sim/testsuite/cris: If failing compilation, mark C tests as errors 142280 ...when we know we have a working compiler. This will reduce 142281 the risk of faulty edits by exposing them rather than hiding 142282 them as "unresolved". It also harmonizes behavior with that of 142283 run_sim_test. 142284 142285 * c/c.exp: Mark C tests failing compilation test errors. 142286 1422872022-02-14 Hans-Peter Nilsson <hp@axis.com> 142288 142289 sim/testsuite/cris: Remove faulty use of basename in C tests 142290 Calls to basename were added here as part of commit 142291 e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that 142292 commit missed adding "#include <libgen.h>" or the equivalent 142293 GNU extension, see basename(3). Fixing that shows a logical 142294 error in the change to openpf1.c; the non-/-prefixed 142295 code-path was changed instead of the "/"-prefixed code-path, 142296 which is the one executed after that commit. 142297 142298 For "newlib" these tests failed linking after that commit. 142299 Recent newlib has the (asm-renamed) GNU-extension-variant of 142300 basename, but we're better off not using it at all. 142301 142302 Unfortunately, compilation failures for C tests run by the 142303 machinery in c.exp are currently just marked "unresolved", 142304 in contrast to C and assembler tests run by calling 142305 run_sim_test. 142306 142307 The interaction of calling with the full program-path vs. 142308 use of --sysroot exposes a consistency problem: when 142309 --sysroot is used, argv[0] isn't the path by which the 142310 program can find itself. It's undecided whether argv[0] for 142311 the program running in the simulator should be edited 142312 (related to the naked argument to the simulator before 142313 passing on to the simulated program) to remove a leading 142314 --sysroot. Either way, such a change would be out of scope 142315 for this commit. 142316 142317 * c/stat3.c (mybasename): New macro. Use it instead of basename. 142318 * c/openpf1.c: Correct basename-related change and update related 142319 comment. 142320 1423212022-02-14 Hans-Peter Nilsson <hp@axis.com> 142322 142323 sim: Add sim_dump_memory for debugging 142324 Intended to be called from the debugger tool. 142325 142326 sim/common: 142327 * sim-memopt.c (sim_dump_memory): New function. 142328 1423292022-02-14 Hans-Peter Nilsson <hp@axis.com> 142330 142331 sim: Fix use of out-of-tree assembler and linker when testing 142332 With commit 7a259895bb2d "sim: testsuite: expand arch specific 142333 toolchain settings", trying to use out-of-tree ld and as at test-time 142334 broke for the "primary target", like when testing a release-tarball. 142335 142336 Subsequent to that commit, all assembler tests without in-tree-built 142337 tools FAIL, getting errors when trying to call 142338 $(abs_builddir)/../gas/as-new. But, that isn't the actual culprint; 142339 it's actually it's its immediate predecessor, commit 8996c21067373 142340 "sim: testsuite: setup per-port toolchain settings for multitarget 142341 build", which hardcodes in-tree-paths to those tools instead of 142342 considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable 142343 for single-target builds, as set up by the toplevel Makefile. 142344 142345 This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific 142346 features aren't used) from toplev/config/acx.m4, somewhat like calls 142347 in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS 142348 step, for each X to find a value for $(<X>_FOR_TARGET). N.B.: in-tree 142349 tools still override any ${target}-${tool} found in $PATH, i.e. only 142350 previously broken builds are affected. 142351 142352 The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel 142353 Makefile to the same value or better, but has to be set here too, as 142354 automake "wants" Makefiles to be self-contained (you get an error 142355 pointing out that the variable may be empty). If it hadn't been for 142356 that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed. 142357 This detail should only (positively) affect users invoking "make 142358 check" in sim/ instead of "make check-sim" (or "make check") at the 142359 toplevel. Now the output from "configure" matches the target tools 142360 actually used by sim at test-time, for the "primary target". 142361 142362 Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as 142363 that appears to be a deliberate special-case. 142364 142365 Note that all tools still have to be installed and present in 142366 $PATH at configure-time to be properly used at test-time. 142367 142368 sim: 142369 * m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET): 142370 New defun. 142371 (SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables 142372 AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded 142373 values. 142374 * Makefile.in, configure: Regenerate. 142375 1423762022-02-14 Hans-Peter Nilsson <hp@axis.com> 142377 142378 sim cris: Unbreak --disable-sim-hardware builds 142379 With --disable-sim-hardware (--enable-sim-hardware=no), 142380 whose default was changed to --enable-sim-hardware(=yes) in 142381 commit 34cf51120683, building for cris-elf fails as 142382 sim_hw_parse then doesn't exist. 142383 142384 A cris-elf simulator configured for --enable-sim-hardware 142385 (or the default after to the mentioned commit) runs about 142386 2.5x slower than one configured --disable-sim-hardware. 142387 A further 2-5% performance regression was not investigated. 142388 142389 When sim_hw_parse doesn't exist, --cris-900000xx can't be 142390 supported. The best action here is to remove it completely, 142391 so its absence can be identified through --help, but 142392 avoiding littering the code with "#if WITH_HW". 142393 142394 sim/cris: 142395 * sim-if.c (cris_options) [WITH_HW]: Conditionalize 142396 support of option --cris-900000xx. 142397 (sim_open) [WITH_HW]: Conditionalize sim_hw_parse 142398 call. 142399 1424002022-02-14 Hans-Peter Nilsson <hp@axis.com> 142401 142402 sim/testsuite/cris: As applicable, require simoption --cris-900000xx 142403 Apply the new run_sim_test option "require" as in "#require 142404 simoption --cris-900000xx" for all tests using that option. 142405 This allows a clean test-suite-run for a build with 142406 --disable-sim-hardware, where that option is not supported, 142407 by skipping those tests as "untested". 142408 142409 sim/testsuite/cris: 142410 * asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms, 142411 asm/io7.ms: Call "#require: simoption --cris-900000xx". 142412 1424132022-02-14 Hans-Peter Nilsson <hp@axis.com> 142414 142415 sim/testsuite: Support "requires: simoption <--name-of-option>" 142416 Simulator features can be present or not, typically 142417 depending on different-valued configure options, like 142418 --enable-sim-hardware[=off|=on]. To avoid failures in 142419 test-suite-runs when testing such configurations, a new 142420 predicate is needed, as neither "target", "progos" nor 142421 "mach" fits cleanly. 142422 142423 The immediate need was to check for presence of a simulator 142424 option, but rather than a specialized "requires-simoption:" 142425 predicate I thought I'd handle the general (parametrized) 142426 need, so here's a generic predicate machinery and a (first) 142427 predicate to use together with it; checking whether a 142428 particular option is supported, by looking at "run --help" 142429 output. This was inspired by the check_effective_target_ 142430 machinery in the gcc test-suite. 142431 142432 Multiple "requires: <requirement> <parameter>" form a list of 142433 predicates (with parameters), to be used as a conjunction. 142434 142435 sim/testsuite: 142436 * lib/sim-defs.exp (sim_check_requires_simoption): New function. 142437 (run_sim_test): Support "requires: <requirement> <parameter>". 142438 1424392022-02-14 Hans-Peter Nilsson <hp@axis.com> 142440 142441 sim/testsuite/cris/hw/rv-n-cris/irq1.ms: Disable due to randomness 142442 For reasons that remain largely to be investigated (besides 142443 the apparent lack of synchronization between two processes), 142444 this test fails randomly, with two different sets of common 142445 outputs. Curiously, that doesn't happen for the other 142446 similar tests. There's a comment that mentions this, though 142447 that doesn't make it a sustainable part of a test-suite. 142448 (Known-blinking tests should be disabled until fixed.) 142449 142450 sim/testsuite/cris: 142451 * hw/rv-n-cris/irq1.ms: Disable by use of a never-matched 142452 "progos" value. 142453 1424542022-02-14 Hans-Peter Nilsson <hp@axis.com> 142455 142456 sim/testsuite/cris/c: Use -sim3 but only for newlib targets 142457 Commit a39487c6685f "sim: cris: use -sim with C tests for cris-elf 142458 targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for 142459 cris*-*-elf, where testing had until then relied on 142460 "RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make 142461 check-sim", adding the right options. While "-sim" happens to work, 142462 the baseboard-file cris-sim.exp uses "-sim3" so for consistency use 142463 that instead. 142464 142465 Then commit b42f20d2ac72 "sim: testsuite: drop most specific istarget 142466 checks" caused " -sim" to be appended for *all* targets, which just 142467 doesn't work. For example, for crisv32-linux-gnu, that's not a 142468 recognized option and will cause a dejagnu error and further testing 142469 in c.exp will be aborted. 142470 142471 While cris-sim.exp appends "-static" for *-linux-gnu, further changes 142472 in the test-suite have caused "linux"-specific tests to break, so that 142473 part will be tended to separately. 142474 142475 But, save and restore CFLAGS_FOR_TARGET around the modification and 142476 use where needed, to not have the CRIS-specific modification affect a 142477 continuing test-run (possibly for other targets). 142478 142479 sim/testsuite/cris: 142480 * c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim" 142481 with " -sim3", but do it conditionally for newlib targets. Save 142482 and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such 142483 that it doesn't affect the value of CFLAGS_FOR_TARGET outside 142484 c.exp. 142485 1424862022-02-14 Hans-Peter Nilsson <hp@axis.com> 142487 142488 sim/testsuite: Set global_cc_os also when no compiler is found 142489 If we don't set this variable, it doesn't exist, and using "#progos:" 142490 in an assembler-file will cause an error rather than just skipping the 142491 test, viz: 142492 142493 Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ... 142494 ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp. 142495 ERROR: can't read "global_cc_os": no such variable 142496 while executing 142497 "if { $opts(progos) != "" && $opts(progos) != $global_cc_os } { 142498 untested $subdir/$name 142499 return 142500 }" 142501 (procedure "run_sim_test" line 102) 142502 142503 Neither the commit introducing progos, nor the top comment 142504 in run_sim_test, mentions progos as intended only for C 142505 tests, or that its use must be gated on $global_cc_works != 142506 0, so (not) setting it in the no-working-compiler path seems 142507 just overlooked. 142508 142509 Allowing it to be used for assembler tests makes it usable 142510 for e.g. an always-false predicate and in expressions in 142511 .exp files without gating on $global_cc_works != 0. 142512 142513 With this patch, global_cc_os is set to "", just as for "unknown OS". 142514 142515 sim/testsuite: 142516 * lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when 142517 no working target C compiler is found. 142518 1425192022-02-14 Hans-Peter Nilsson <hp@axis.com> 142520 142521 sim/testsuite/cris: Assembler testcase for PRIx32 usage bug 142522 Several C test-cases exposed the bug, but let's have one for 142523 people who test using just the assembler and linker. 142524 142525 * asm/endmem1.ms: New test. 142526 1425272022-02-14 Hans-Peter Nilsson <hp@axis.com> 142528 142529 sim cris: Correct PRIu32 to PRIx32 142530 In 5ee0bc23a68f "sim: clean up bfd_vma printing" there was 142531 an additional introduction of PRIx32 and PRIu32 but just in 142532 sim/cris/sim-if.c. One type of bug was fixed in commit 142533 d16ce6e4d581 "sim: cris: fix memory setup typos" but one 142534 remained; the PRIu32 usage is wrong, as hex output is 142535 desired; note the 0x prefix. 142536 142537 Without this fix, you'll see output like: 142538 memory map 0:0x4000..0x5fff (8192 bytes) overlaps 0:0x0..0x16383 (91012 bytes) 142539 program stopped with signal 6 (Aborted). 142540 for some C programs, like some of the ones in the sim/cris/c 142541 testsuite from where the example is taken (freopen2.c). 142542 142543 The bug behavior was with memory allocation. With an 142544 attempt to allocate memory using the brk syscall such that 142545 the room up to the next 8192-byte "page boundary" wasn't 142546 sufficient, the simulator memory allocation machinery horked 142547 on a consistency error when trying to allocate a memory 142548 block to raise the "end of the data segment": there was 142549 already memory allocated at that address. 142550 142551 Unfortunately, none of the programs in sim/cris/asm exposed 142552 this bug at the time, but an assembler test-case is 142553 committed after this fix. 142554 142555 sim/cris: 142556 * sim-if.c (sim_open): Correct PRIu32 to PRIx32. 142557 1425582022-02-14 Sergei Trofimovich <siarheit@google.com> 142559 142560 microblaze: fix fsqrt collicion to build on glibc-2.35 142561 * microblaze-opcm.h: Renamed 'fsqrt' to 'microblaze_fsqrt'. 142562 * microblaze-opc.h: Follow 'fsqrt' rename. 142563 1425642022-02-14 Tom Tromey <tom@tromey.com> 142565 142566 Remove LA_PRINT_STRING 142567 This removes the LA_PRINT_STRING macro, in favor of using ordinary 142568 method calls. 142569 142570 Remove LA_PRINT_CHAR 142571 This removes the LA_PRINT_CHAR macro, in favor of using ordinary 142572 method calls. 142573 142574 Remove LA_PRINT_TYPE 142575 This removes the LA_PRINT_TYPE macro, in favor of using ordinary 142576 method calls. 142577 1425782022-02-14 Andrew Burgess <andrew.burgess@embecosm.com> 142579 142580 gdb/python: move styling support to gdb.styling 142581 This commit moves the two Python functions that are used for styling 142582 into a new module, gdb.styling, there's then a small update in 142583 python.c so GDB can find the functions in their new location. 142584 142585 The motivation for this change is purely to try and reduce the clutter 142586 in the top-level gdb module, and encapsulate related functions into 142587 modules. I did ponder documenting these functions as part of the 142588 Python API, however, doing so would effectively "fix" the API, and I'm 142589 still wondering if there's improvements that could be made, also, the 142590 colorize function is only called in some cases now that GDB prefers 142591 libsource-highlight, so it's not entirely sure how this would work as 142592 part of a user facing API. 142593 142594 Still, despite these functions never having been part of a documented 142595 API, it is possible that a user out there has overridden these to, in 142596 some way, customize how GDB performs styling. Moving the function as 142597 I propose in this patch could break things for that user, however, 142598 fixing this breakage is trivial, and, as these functions were never 142599 documented, I don't think we should be obliged to not break user code 142600 that relies on them. 142601 1426022022-02-14 Andrew Burgess <andrew.burgess@embecosm.com> 142603 142604 gdb: use python to colorize disassembler output 142605 This commit adds styling support to the disassembler output, as such 142606 two new commands are added to GDB: 142607 142608 set style disassembler enabled on|off 142609 show style disassembler enabled 142610 142611 In this commit I make use of the Python Pygments package to provide 142612 the styling. I did investigate making use of libsource-highlight, 142613 however, I found the highlighting results to be inferior to those of 142614 Pygments; only some mnemonics were highlighted, and highlighting of 142615 register names such as r9d and r8d (on x86-64) was incorrect. 142616 142617 To enable disassembler highlighting via Pygments, I've added a new 142618 extension language hook, which is then implemented for Python. This 142619 hook is very similar to the existing hook for source code 142620 colorization. 142621 142622 One possibly odd choice I made with the new hook is to pass a 142623 gdb.Architecture through, even though this is currently unused. The 142624 reason this argument is not used is that, currently, styling is 142625 performed identically for all architectures. 142626 142627 However, even though the Python function used to perform styling of 142628 disassembly output is not part of any documented API, I don't want 142629 to close the door on a user overriding this function to provide 142630 architecture specific styling. To do this, the user would inevitably 142631 require access to the gdb.Architecture, and so I decided to add this 142632 field now. 142633 142634 The styling is applied within gdb_disassembler::print_insn, to achieve 142635 this, gdb_disassembler now writes its output into a temporary buffer, 142636 styling is then applied to the contents of this buffer. Finally the 142637 gdb_disassembler buffer is copied out to its final destination stream. 142638 142639 There's a new test to check that the disassembler output includes some 142640 escape sequences, though I don't check for specific colours; the 142641 precise colors will depend on which instructions are in the 142642 disassembler output, and, I guess, how pygments is configured. 142643 142644 The only negative change with this commit is how we currently style 142645 addresses in GDB. 142646 142647 Currently, when the disassembler wants to print an address, we call 142648 back into GDB, and GDB prints the address value using the `address` 142649 styling, and the symbol name using `function` styling. After this 142650 commit, if pygments is used, then all disassembler styling is done 142651 through pygments, and this include the address and symbol name parts 142652 of the disassembler output. 142653 142654 I don't know how much of an issue this will be for people. There's 142655 already some precedent for this in GDB when we look at source styling. 142656 For example, function names in styled source listings are not styled 142657 using the `function` style, but instead, either GNU Source Highlight, 142658 or pygments gets to decide how the function name should be styled. 142659 142660 If the Python pygments library is not present then GDB will continue 142661 to behave as it always has, the disassembler output is mostly 142662 unstyled, but the address and symbols are styled using the `address` 142663 and `function` styles, as they are today. 142664 142665 However, if the user does `set style disassembler enabled off`, then 142666 all disassembler styling is switched off. This obviously covers the 142667 use of pygments, but also includes the minimal styling done by GDB 142668 when pygments is not available. 142669 1426702022-02-14 H.J. Lu <hjl.tools@gmail.com> 142671 142672 ld: Keep indirect symbol from IR if referenced from shared object 142673 Don't change indirect symbol defined in IR to undefined if it is 142674 referenced from shared object. 142675 142676 bfd/ 142677 142678 PR ld/28879 142679 * elflink.c (_bfd_elf_merge_symbol): Don't change indirect 142680 symbol defined in IR to undefined if it is referenced from 142681 shared object. 142682 142683 ld/ 142684 142685 PR ld/28879 142686 * testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests. 142687 * testsuite/ld-plugin/pr28879a.cc: New file. 142688 * testsuite/ld-plugin/pr28879b.cc: Likewise. 142689 1426902022-02-14 GDB Administrator <gdbadmin@sourceware.org> 142691 142692 Automatic date update in version.in 142693 1426942022-02-13 Alan Modra <amodra@gmail.com> 142695 142696 PR28882, build failure with gcc-4.2 due to use of 0b literals 142697 PR 28882 142698 * elf/loongarch.h: Replace binary literals with hex. 142699 1427002022-02-13 Alan Modra <amodra@gmail.com> 142701 142702 Don't pass around expld.dataseg pointer 142703 The better to see any code that accesses expld.dataseg. 142704 142705 * ldexp.c (fold_segment_end): Remove seg parameter. Adjust calls. 142706 (fold_segment_align, fold_segment_relro_end): Likewise. 142707 * ldlang.c (lang_size_segment): Likewise. 142708 (lang_size_relro_segment_1, lang_find_relro_sections_1): Likewise. 142709 1427102022-02-13 Alan Modra <amodra@gmail.com> 142711 142712 Remove bfd ELF_RELROPAGESIZE 142713 Now that ld properly aligns the end of the relro segment, the hack to 142714 make relro work on powerpc can disappear. 142715 142716 bfd/ 142717 * bfd.c (bfd_emul_get_commonpagesize): Remove relro param. 142718 Don't return bed->relropagesize. 142719 * elf-bfd.h (struct elf_backend_data): Remove relropagesize. 142720 * elfxx-target.h (ELF_RELROPAGESIZE): Remove. 142721 * elf32-ppc.c (ELF_RELROPAGESIZE): Don't define. 142722 * elf64-ppc.c: Likewise. 142723 * bfd-in2.h: Regenerate. 142724 ld/ 142725 * ldemul.c (after_parse_default): Adjust 142726 bfd_emul_get_commonpagesize call. 142727 1427282022-02-13 Alan Modra <amodra@gmail.com> 142729 142730 PR28824, relro security issues, x86 keep COMMONPAGESIZE relro 142731 x86 treats MAXPAGESIZE as a memory optimisation parameter, actual 142732 hardware paging is always COMMPAGESIZE of 4k. Use COMMONPAGESIZE for 142733 the end of the relro segment alignment. 142734 142735 The previous patch regresses pr18176, increasing the testcase file 142736 size from 322208 to 2099872 bytes. Fixing this on x86 will require 142737 introducing a gap after the end of the relro segment (of up to 142738 relropagesize-1 bytes). 142739 142740 PR 28824 142741 PR 18176 142742 * ld.h (ld_config_type): Add relro_use_commonpagesize field. 142743 * ldexp.c (fold_segment_align): Set relropagesize depending on 142744 relro_use_commonpagesize. 142745 * emultempl/elf-x86.em (elf_x86_create_output_section_statements): 142746 Set relro_use_commonpagesize. 142747 * testsuite/ld-x86-64/pr18176.d: xfail. 142748 1427492022-02-13 Alan Modra <amodra@gmail.com> 142750 142751 PR28824, relro security issues 142752 Background 142753 ========== 142754 There are constraints on layout of binaries to meet demand paging and 142755 memory protection requirements. Demand paged binaries must have file 142756 offset mod pagesize equal to vma mod pagesize. Memory protection 142757 (executable, read, write status) can only change at page boundaries. 142758 The linker's MAXPAGESIZE variable gives the page size for these layout 142759 constraints. 142760 142761 In a typical basic executable with two memory segments, text (RE) and 142762 data (RW), the data segment must start on a different page to the 142763 last text segment page. For example, with 64k pages and a small 142764 executable of 48k text and 1k data, the text segment might start at 142765 address 0x10000 and data at 0x20000 for a total of two 64k memory 142766 pages. Demand paging would require the image on disk to be 64k+1k 142767 in size. We can do better than that. If the data segment instead 142768 starts at 0x2c000 (the end of the text segment plus one 64k page) then 142769 there are still only two memory pages, but the disk image is now 142770 smaller, 48k+1k in size. This is why the linker normally starts the 142771 data segment at the end of the text segment plus one page. That 142772 simple heuristic isn't ideal in all cases. Changing our simple 142773 example to one with 64k-1 text size, following that heuristic would 142774 result in data starting at 0x2ffff. Now we have two 64k memory data 142775 pages for a data segment of 1k! If the data segment instead started 142776 at 0x30000 we'd get a single data segment page at the cost of 1 byte 142777 extra in the disk image, which is likely a good trade-off. So the 142778 linker does adjust the simple heuristic. Just how much disk image 142779 size increase is allowed is controlled by the linker's COMMONPAGESIZE 142780 variable. 142781 142782 A PT_GNU_RELRO segment overlays the initial part of the data segment, 142783 saying that those pages should be made read-only after relocation by 142784 the dynamic loader. Page granularity for memory protection means that 142785 the end of the relro segment must be at a page boundary. 142786 142787 The problem 142788 =========== 142789 Unfortunately most targets currently only align the end of the relro 142790 segment to COMMONPAGESIZE. That results in only partial relro 142791 protection if an executable is running with MAXPAGESIZE pages, since 142792 any part of the relro segment past the last MAXPAGESIZE boundary can't 142793 be made read-only without also affecting sections past the end of the 142794 relro segment. I believe this problem arose because x86 always runs 142795 with 4k (COMMPAGESIZE) memory pages, and therefore using a larger 142796 MAXPAGESIZE on x86 is for reasons other than the demand paging and 142797 memory page protection boundary requirements. 142798 142799 The solution 142800 ============ 142801 Always end the relro segment on a MAXPAGESIZE boundary, except for 142802 x86. Note that the relro segment, comprising of sections at the start 142803 of the data segment, is sized according to how those sections are laid 142804 out. That means the start of the relro segment is fixed relative to 142805 its end. Which also means the start of the data segment must be at a 142806 fixed address mod MAXPAGESIZE. So for relro the linker can't play 142807 games with the start of the data segment to save disk space. At 142808 least, not without introducing gaps between the relro sections. In 142809 fact, because the linker was starting layout using its simple 142810 heuristic of starting the data segment at the end of the text segment 142811 plus one page, it was sometimes introducing page gaps for no reason. 142812 See pr28743. 142813 142814 PR 28824 142815 PR 28734 142816 * ldexp.c (fold_segment_align): When relro, don't adjust up by 142817 offset within page. Set relropagesize. 142818 (fold_segment_relro_end): Align to relropagesize. 142819 * ldexp.h (seg_align_type): Rename pagesize to commonpagesize. 142820 Add relropagesize. Comment. 142821 * ldlang.c (lang_size_segment): Adjust to suit field renaming. 142822 (lang_size_relro_segment_1): Align relro_end using relropagesize. 142823 1428242022-02-13 GDB Administrator <gdbadmin@sourceware.org> 142825 142826 Automatic date update in version.in 142827 1428282022-02-12 GDB Administrator <gdbadmin@sourceware.org> 142829 142830 Automatic date update in version.in 142831 1428322022-02-11 H.J. Lu <hjl.tools@gmail.com> 142833 142834 x86: Disallow invalid relocation against protected symbol 142835 I am checking this into master and will backport it to 2.38 branch. 142836 142837 H.J 142838 ---- 142839 On x86, GCC 12 supports -mno-direct-extern-access to enable canonical 142840 reference to protected function and disable copy relocation. With 142841 -mno-direct-extern-access, the canonical protected function symbols must 142842 be accessed via canonical reference and the protected data symbols in 142843 shared libraries are non-copyable. Under glibc 2.35, non-canonical 142844 reference to the canonical protected function will get the run-time error: 142845 142846 ./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function 142847 142848 and copy relocations against the non-copyable protected symbols will get 142849 the run-time error: 142850 142851 ./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol 142852 142853 Update x86 linker to disallow non-canonical reference to the canonical 142854 protected function: 142855 142856 ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so 142857 ld: failed to set dynamic section sizes: bad value 142858 142859 and copy relocation against the non-copyable protected symbol: 142860 142861 ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so 142862 142863 at link-time. 142864 142865 bfd/ 142866 142867 PR ld/28875 142868 * elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip 142869 shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. 142870 * elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical 142871 reference to canonical protected function. 142872 * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 142873 * elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy 142874 relocation against non-copyable protected symbol. 142875 142876 ld/ 142877 142878 PR ld/28875 142879 * testsuite/ld-i386/i386.exp: Check non-canonical reference to 142880 canonical protected function and check copy relocation against 142881 non-copyable protected symbol. 142882 * testsuite/ld-i386/pr21997-1.err: New file. 142883 * testsuite/ld-i386/pr28875.err: Likewise. 142884 * testsuite/ld-i386/pr28875a.c: Likewise. 142885 * testsuite/ld-i386/pr28875b.c: Likewise. 142886 * testsuite/ld-x86-64/pr21997-1a.err: Updated. 142887 * testsuite/ld-x86-64/pr21997-1b.err: Likewise. 142888 * testsuite/ld-x86-64/pr28875-data.err: New file. 142889 * testsuite/ld-x86-64/pr28875-func.err: Likewise. 142890 * testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference 142891 to canonical protected function and check copy relocation against 142892 non-copyable protected symbol. 142893 1428942022-02-11 Tom Tromey <tromey@adacore.com> 142895 142896 Add initializers to bound_minimal_symbol 142897 This adds initializers to bound_minimal_symbol, allowing for the 142898 removal of some calls to memset. 142899 1429002022-02-11 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 142901 142902 gdb/fortran: support ptype and print commands for namelist variables 142903 Gfortran supports namelists (a Fortran feature); it emits 142904 DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not 142905 process these dies and does not support 'print' or 'ptype' commands on 142906 namelist variables. 142907 142908 An attempt to print namelist variables results in gdb bailing out with 142909 the error message as shown below. 142910 142911 (gdb) print nml 142912 No symbol "nml" in current context. 142913 142914 This commit is to make the print and ptype commands work for namelist 142915 variables and its items. Sample output of these commands is shared 142916 below, with fixed gdb. 142917 142918 (gdb) ptype nml 142919 type = Type nml 142920 integer(kind=4) :: a 142921 integer(kind=4) :: b 142922 End Type nml 142923 (gdb) print nml 142924 $1 = ( a = 10, b = 20 ) 142925 1429262022-02-11 Bruno Larsen <blarsen@redhat.com> 142927 142928 gdb: fix until behavior with trailing !is_stmt lines 142929 When using the command "until", it is expected that GDB will exit a 142930 loop if the current instruction is the last one related to that loop. 142931 However, if there were trailing non-statement instructions, "until" 142932 would just behave as "next". This was noticeable in clang-compiled 142933 code, but might happen with gcc-compiled as well. PR gdb/17315 relates 142934 to this problem, as running gdb.base/watchpoint.exp with clang 142935 would fail for this reason. 142936 142937 To better understand this issue, consider the following source code, 142938 with line numbers marked on the left: 142939 142940 10: for (i = 0; i < 10; ++i) 142941 11: loop_body (); 142942 12: other_stuff (); 142943 142944 If we transform this to pseudo-assembler, and generate a line table, 142945 we could end up with something like this: 142946 142947 Address | Pseudo-Assembler | Line | Is-Statement? 142948 142949 0x100 | i = 0 | 10 | Yes 142950 0x104 | loop_body () | 11 | Yes 142951 0x108 | i = i + 1 | 10 | Yes 142952 0x10c | if (i < 10): | 10 | No 142953 0x110 | goto 0x104 | 10 | No 142954 0x114 | other_stuff () | 12 | Yes 142955 142956 Notice the two non-statement instructions at the end of the loop. 142957 142958 The problem is that when we reach address 0x108 and use 'until', 142959 hoping to leave the loop, GDB sets up a stepping range that runs from 142960 the start of the function (0x100 in our example) to the end of the 142961 current line table entry, that is 0x10c in our example. GDB then 142962 starts stepping forward. 142963 142964 When 0x10c is reached GDB spots that we have left the stepping range, 142965 that the new location is not a statement, and that the new location is 142966 associated with the same source line number as the previous stepping 142967 range. GDB then sets up a new stepping range that runs from 0x10c to 142968 0x114, and continues stepping forward. 142969 142970 Within that stepping range the inferior hits the goto (at 0x110) and 142971 loops back to address 0x104. 142972 142973 At 0x104 GDB spots that we have left the previous stepping range, that 142974 the new address is marked as a statement, and that the new address is 142975 for a different source line. As a result, GDB stops and returns 142976 control to the user. This is not what the user was expecting, they 142977 expected GDB to exit the loop. 142978 142979 The fix proposed in this patch, is that, when the user issues the 142980 'until' command, and GDB sets up the initial stepping range, GDB will 142981 check subsequent SALs (symtab_and_lines) to see if they are 142982 non-statements associated with the same line number. If they are then 142983 the end of the initial stepping range is extended to the end of the 142984 non-statement SALs. 142985 142986 In our example above, the user is at 0x108 and uses 'until', GDB now 142987 sets up a stepping range from the start of the function 0x100 to 142988 0x114, the first address associated with a different line. 142989 142990 Now as GDB steps around the loop it never leaves the initial stepping 142991 range. It is only when GDB exits the loop that we leave the stepping 142992 range, and the stepping finishes at address 0x114. 142993 142994 This patch also adds a test case that can be run with gcc to test that 142995 this functionality is not broken in the future. 142996 142997 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17315 142998 1429992022-02-11 Richard Sandiford <richard.sandiford@arm.com> 143000 143001 gas/doc: Fix "a true results" typo 143002 1430032022-02-11 Jan Vrany <jan.vrany@labware.com> 143004 143005 gdb: extend the information printed by 'maint info jit' 143006 This commit updates the output of 'maint info jit' to print not just 143007 the jit_code_entry address, but also the symfile address, and the 143008 symfile size. 143009 143010 The new information could be obtained by looking into target memory at 143011 the contents of the jit_code_entry, but, by storing this information 143012 within gdb at the time the jit object is loaded, it is now possible to 143013 check if the jit_code_entry has been modified in target memory behind 143014 gdb's back. 143015 143016 Additionally, the symfile address is the same address that is now used 143017 in the objfile names after commit 4a620b7e. 143018 143019 One test that relies on the output of 'maint info jit' was updated to 143020 allow for the new output format. 143021 1430222022-02-11 Michael Forney <mforney@mforney.org> 143023 143024 bfd: Remove return with expression in void function 143025 * bfd.c (bfd_set_gp_value): Remove return with expression 143026 in void function. 143027 1430282022-02-11 Tiezhu Yang <yangtiezhu@loongson.cn> 143029 143030 gdb: LoongArch: Add Makefile, configure and NEWS 143031 This commit adds Makefile, configure and NEWS for LoongArch. 143032 143033 gdb: LoongArch: Add initial native Linux support 143034 This commit adds initial native Linux support for LoongArch. 143035 143036 gdb: LoongArch: Add initial Linux target support 143037 This commit adds initial Linux target support for LoongArch. 143038 143039 gdb: LoongArch: Add initial baremetal support 143040 This commit adds initial baremetal support for LoongArch. 143041 143042 gdb: LoongArch: Add initial target description support 143043 This commit adds initial target description support for LoongArch. 143044 1430452022-02-11 Mike Frysinger <vapier@gentoo.org> 143046 143047 libctf: delete unused libctf_TEXINFOS 143048 It's not clear what this was meant for, but it's not used by anything, 143049 and the info pages still generate fine without it. 143050 1430512022-02-11 Simon Marchi <simon.marchi@polymtl.ca> 143052 143053 gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, clone, sysgood 143054 I think it's safe to remove checking support for these ptrace features, 143055 they have all been added in what is now ancient times (around the 143056 beginning of Linux 2.6). This allows removing a bit of complexity in 143057 linux-nat.c and nat/linux-ptrace.c. 143058 143059 It also allows saving one extra fork every time we start debugging on 143060 Linux: linux_check_ptrace_features forks a child process to test if some 143061 ptrace features are supported. That child process forks a grand-child, 143062 to test whether ptrace reports an event for the fork by the child. This 143063 is no longer needed, if we assume the kernel supports reporting forks. 143064 143065 PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003: 143066 143067 https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416 143068 143069 PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002: 143070 143071 https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964 143072 143073 PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and 143074 PTRACE_O_TRACECLONE were introduced in this change, in 2002: 143075 143076 https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46 143077 143078 Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d 143079 1430802022-02-11 GDB Administrator <gdbadmin@sourceware.org> 143081 143082 Automatic date update in version.in 143083 1430842022-02-10 Andrew Burgess <aburgess@redhat.com> 143085 143086 gdb/infrun: some extra infrun debug print statements 143087 While reviewing a different patch I wanted to know more about what was 143088 going on during GDB's stepping. I added some extra infrun debug print 143089 calls, and I thought these might be useful to others. 143090 1430912022-02-10 GDB Administrator <gdbadmin@sourceware.org> 143092 143093 Automatic date update in version.in 143094 1430952022-02-09 Nick Clifton <nickc@redhat.com> 143096 143097 Update the obsolete list and how-to-make-a-release documentation now that the 2.38 release is out. 143098 1430992022-02-09 Alan Modra <amodra@gmail.com> 143100 143101 PR28763, SIGSEGV during processing of program headers via readelf 143102 PR 28763 143103 * readelf.c (process_file_header): Discard any cached program 143104 headers if there is an extension field for e_phnum in first 143105 section header. 143106 1431072022-02-09 Alan Modra <amodra@gmail.com> 143108 143109 Work around gcc-4 warnings in elf64-ppc.c 143110 elf64-ppc.c: In function 'ppc64_elf_size_dynamic_sections': 143111 elf64-ppc.c:10309:45: error: value computed is not used [-Werror=unused-value] 143112 ++lgot_ents, ++lgot_masks, isym != NULL && isym++) 143113 143114 It is of course a silly warning, fixed in later versions of gcc. I 143115 wrote "isym != NULL && isym++" rather than the simpler "isym++" to 143116 stop sanitisers complaining about incrementing a NULL pointer. isym 143117 is of course unused in any code path where it might start off as 143118 NULL. Sometimes you can't win. So don't try to be clever in reading 143119 local symbols only when needed. 99 times out of 100 they will be 143120 cached anyway. 143121 143122 * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Avoid annoying 143123 warnings by always reading local syms. 143124 (ppc64_elf_layout_multitoc): Likewise. 143125 1431262022-02-09 Peilin Ye <peilin.ye@bytedance.com> 143127 143128 Test --only-keep-debug on ELF relocatables 143129 Add a test for commit 7c4643efe7be, which fixed --only-keep-debug for ELF 143130 relocatables. 143131 143132 * testsuite/binutils-all/objcopy.exp 143133 (keep_debug_symbols_for_elf_relocatable): New test. 143134 1431352022-02-09 GDB Administrator <gdbadmin@sourceware.org> 143136 143137 Automatic date update in version.in 143138 1431392022-02-08 Palmer Dabbelt <palmer@rivosinc.com> 143140 143141 RISC-V: Stop reporting warnings for mismatched extension versions 143142 The extension version checking logic is really just too complicated to 143143 encode into the linker, trying to do so causes more harm than good. 143144 This removes the checks and the associated tests, leaving the logic to 143145 keep the largest version of each extension linked into the target. 143146 143147 bfd/ 143148 143149 * elfnn-riscv.c (riscv_version_mismatch): Rename to 143150 riscv_update_subset_version, and stop reporting warnings on 143151 version mismatches. 143152 (riscv_merge_std_ext): Adjust calls to riscv_version_mismatch. 143153 (riscv_merge_multi_letter_ext): Likewise. 143154 143155 ld/ 143156 * testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d: Remove 143157 * testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s: Likewise 143158 * testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s: Likewise 143159 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Likewise 143160 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02a.s: Likewise 143161 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02b.s: Likewise 143162 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02c.s: Likewise 143163 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02d.s: Likewise 143164 * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: New test. 143165 * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p0.s: 143166 Likewise. 143167 * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p1.s: 143168 Likewise. 143169 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Remove obselete 143170 attr-merge-arch-failed-{01,02}, replace with 143171 attr-merge-user-ext-01. 143172 1431732022-02-08 Alan Modra <amodra@gmail.com> 143174 143175 PR28862, heap-buffer-overflow in parse_stab_string 143176 I have no info on the format of a "SUNPRO C++ Namespace" stab, so am 143177 relying on the previous code being correct in parsing these stabs. 143178 Just don't allow NULs anywhere in the stab. 143179 143180 PR 28862 143181 * stabs.c (parse_stab_string): Don't overrun buffer when parsing 143182 'Y' stab. 143183 1431842022-02-08 Alan Modra <amodra@gmail.com> 143185 143186 Re: elf: Check symbol version without any symbols 143187 * testsuite/ld-elf/pr24718-1.d: Don't xfail for hppa64. 143188 1431892022-02-08 Andrew Burgess <aburgess@redhat.com> 143190 143191 gdb: remove tailing newlines from index_cache_debug calls 143192 I noticed that most of the calls to index_cache_debug include a 143193 trailing newline. As the new debug mechanism already adds a newline, 143194 that means all of these debug calls result in a blank line being 143195 printed, which I think is a mistake. 143196 143197 Remove all the trailing newlines. 143198 143199 I also reformatted one of the index_cache_debug where a string will 143200 now fit onto a single line. 143201 143202 Unless 'set debug index-cache on' is used, there should be no visible 143203 change in output after this commit. 143204 1432052022-02-08 H.J. Lu <hjl.tools@gmail.com> 143206 143207 i386: Allow GOT32 relocations against ABS symbols 143208 GOT32 relocations are allowed since absolute value + addend is stored in 143209 the GOT slot. 143210 143211 Tested on glibc 2.35 build with GCC 11.2 and -Os. 143212 143213 bfd/ 143214 143215 PR ld/28870 143216 * elfxx-x86.c (_bfd_elf_x86_valid_reloc_p): Also allow GOT32 143217 relocations. 143218 143219 ld/ 143220 143221 PR ld/28870 143222 * testsuite/ld-i386/i386.exp: Run pr28870. 143223 * testsuite/ld-i386/pr28870.d: New file. 143224 * testsuite/ld-i386/pr28870.s: Likewise. 143225 1432262022-02-08 GDB Administrator <gdbadmin@sourceware.org> 143227 143228 Automatic date update in version.in 143229 1432302022-02-07 Andrew Burgess <aburgess@redhat.com> 143231 143232 gdb/python: allow Value.format_string to return styled output 143233 Add a new argument to the gdb.Value.format_string method, 'styling'. 143234 This argument is False by default. 143235 143236 When this argument is True, then the returned string can contain output 143237 styling escape sequences. 143238 143239 When this argument is False, then the returned string will not contain 143240 any styling escape sequences. 143241 143242 If the returned string is going to be printed to the user, then it is 143243 often nice to retain the GDB styling. 143244 143245 For the testing, we need to adjust the TERM environment variable, as 143246 we do for all the styling tests. I'm now running all of the C tests 143247 in gdb.python/py-format-string.exp in an environment where styling 143248 could be generated, but only my new test should actually produce 143249 styled output, hopefully this will catch the case where a bug might 143250 cause format_string to always produce styled output. 143251 1432522022-02-07 Lancelot SIX <lancelot.six@amd.com> 143253 143254 gdb: make thread_info::m_thread_fsm a std::unique_ptr 143255 While working on function calls, I realized that the thread_fsm member 143256 of struct thread_info is a raw pointer to a resource it owns. This 143257 commit changes the type of the thread_fsm member to a std::unique_ptr in 143258 order to signify this ownership relationship and slightly ease resource 143259 management (no need to manually call delete). 143260 143261 To ensure consistent use, the field is made a private member 143262 (m_thread_fsm). The setter method (set_thread_fsm) can then check 143263 that it is incorrect to associate a FSM to a thread_info object if 143264 another one is already in place. This is ensured by an assertion. 143265 143266 The function run_inferior_call takes an argument as a pointer to a 143267 call_thread_fsm and installs it in it in a thread_info instance. Also 143268 change this function's signature to accept a unique_ptr in order to 143269 signify that the ownership of the call_thread_fsm is transferred during 143270 the call. 143271 143272 No user visible change expected after this commit. 143273 143274 Tested on x86_64-linux with no regression observed. 143275 143276 Change-Id: Ia1224f72a4afa247801ce6650ce82f90224a9ae8 143277 1432782022-02-07 Andrew Burgess <aburgess@redhat.com> 143279 143280 gdb: unbuffer all input streams when not using readline 143281 This commit should fix PR gdb/28711. What's actually going on is 143282 pretty involved, and there's still a bit of the story that I don't 143283 understand completely, however, from my observed results, I think that 143284 the change I propose making here (or something very similar) is going 143285 to be needed. 143286 143287 The original bug report involves using eclipse to drive gdb using mi 143288 commands. A separate tty is spun off in which to send gdb the mi 143289 commands, this tty is created using the new-ui command. 143290 143291 The behaviour observed is that, given a particular set of mi commands 143292 being sent to gdb, we sometimes see an ESPIPE error from a lseek 143293 call, which ultimately results in gdb terminating. 143294 143295 The problems all originate from gdb_readline_no_editing_callback in 143296 gdb/event-top.c, where we can (sometimes) perform calls to fgetc, and 143297 allow glibc to perform buffering on the FILE object being used. 143298 143299 I say sometime, because, gdb_readline_no_editing_callback already 143300 includes a call to disable the glibc buffering, but this is only done 143301 if the input stream is not a tty. In our case the input stream is a 143302 tty, so the buffering is left in place. 143303 143304 The first step to understanding why this problem occurs is to 143305 understand that eclipse sends multiple commands to gdb very quickly 143306 without waiting for and answer to each command, eclipse plans to 143307 collect all of the command results after sending all the commands to 143308 gdb. In fact, eclipse sends the commands to gdb that they appear to 143309 arrive in the gdb process as a single block of data. When reproducing 143310 this issue within the testsuite I find it necessary to send multiple 143311 commands using a single write call. 143312 143313 The next bit of the story gets a little involved, and this is where my 143314 understanding is not complete. I can describe the behaviour that I 143315 observe, and (for me at least) I'm happy that what I'm seeing, if a 143316 little strange, is consistent. In order to fully understand what's 143317 going on I think I would likely need to dive into kernel code, which 143318 currently seems unnecessary given that I'm happy with the solution I'm 143319 proposing. 143320 143321 The following description all relates to input from a tty in which I'm 143322 not using readline. I see the same problems either when using a 143323 new-ui tty, or with gdb's standard, non-readline, mi tty. 143324 143325 Here's what I observe happening when I send multiple commands to gdb 143326 using a single write, if I send gdb this: 143327 143328 command_1\ncommand_2\ncommand_3 143329 143330 then gdb's event loop will wake up (from its select) as it sees there 143331 is input available. We call into gdb_readline_no_editing_callback, 143332 where we call fgetc, glibc will do a single big read, and get back 143333 just: 143334 143335 command_1\n 143336 143337 that is, despite there being multiple lines of input available, I 143338 consistently get just a single line. From glibc a single character is 143339 returned from the fgetc call, and within gdb we accumulate characters, 143340 one at a time, into our own buffer. Eventually gdb sees the '\n' 143341 character, and dispatches the whole 'command_1' into gdb's command 143342 handler, which processes the command and prints the result. We then 143343 return to gdb_readline_no_editing_callback, which in turn returns to 143344 gdb's event loop where we re-enter the select. 143345 143346 Inside the select we immediately see that there is more input waiting 143347 on the input stream, drop out of the select, and call back into 143348 gdb_readline_no_editing_callback. In this function we again call 143349 fgetc where glibc performs another big read. This time glibc gets: 143350 143351 command_2\n 143352 143353 that is, we once again get just a single line, despite there being a 143354 third line available. Just like the first command we copy the whole 143355 string, character by character into gdb's buffer, then handle the 143356 command. After handling the command we go to the event loop, enter, 143357 and then exit the select, and call back to the function 143358 gdb_readline_no_editing_callback. 143359 143360 In gdb_readline_no_editing_callback we again call fgetc, this time 143361 glibc gets the string: 143362 143363 command_3\n 143364 143365 like before, we copy this to gdb's buffer and handle the command, then 143366 we return to the event loop. At this point the select blocks while we 143367 wait for more input to arrive. 143368 143369 The important bit of this is that someone, somewhere is, it appears, 143370 taking care to split the incoming write into lines. 143371 143372 My next experiment is to try something like: 143373 143374 this_is_a_very_long_command\nshort_command\n 143375 143376 However, I actually make 'this_is_a_very_long_command' very long, as 143377 in many hundreds of characters long. One way to do this is: 143378 143379 echo xxxxxx.....xxxxx 143380 143381 and just adding more and more 'x' characters as needed. What I'm 143382 aiming for is to have the first command be longer than glibc's 143383 internal read buffer, which, on my machine, is 1024 characters. 143384 143385 However, for this discussion, lets imagine that glibc's buffer is just 143386 8 characters (we can create just this situation by adding a suitable 143387 setbuf call into gdb_readline_no_editing_callback). 143388 143389 Now, if I send gdb this data: 143390 143391 abcdefghij\nkl\n 143392 143393 The first read from glibc will get 'abcdefgh', that is a full 8 143394 character buffer. Once gdb has copied these to its buffer we call 143395 fgetc again, and now glibc will get 'ij\n', that is, just like before, 143396 multiple lines are split at the '\n' character. The full command, 143397 which is now in gdb's buffer can be handled 'abcdefghij', after which 143398 we go (via the event loop) back to gdb_readline_no_editing_callback. 143399 Now we call fgetc, and glibc will get 'kl\n', which is then handled in 143400 the normal way. 143401 143402 So far, so good. However, there is, apparently, one edge case where 143403 the above rules don't apply. 143404 143405 If the '\n' character is the first character read from the kernel, 143406 then the incoming lines are not split up. So, given glibc's 8 143407 character buffer, if I send gdb this: 143408 143409 abcdefgh\nkl\n 143410 143411 that is the first command is 8 characters plus a newline, then, on the 143412 first read (from within glibc) we get 'abcdefgh' in a single buffer. 143413 As there's no newline gdb calls fgetc again, and glibc does another 143414 large read, now we get: 143415 143416 \nkl\n 143417 143418 which doesn't follow the above pattern - the lines are not split into 143419 separate buffers! 143420 143421 So, gdb reads the first character from glibc using fgetc, this is the 143422 newline. Now gdb has a complete command, and so the command is 143423 handled. We then return to the event loop and enter the select. 143424 143425 The problem is that, as far as the kernel is concerned, there is no 143426 more input pending, it's all been read into glibc's buffer, and so the 143427 select doesn't return. The second command is basically stuck in 143428 glibc's buffer. 143429 143430 If I send another command to gdb, or even just send an empty 143431 command (a lone newline) then the select returns, we call into 143432 gdb_readline_no_editing_callback, and now gdb sees the second 143433 command. 143434 143435 OK, so the above is interesting, but it doesn't explain the ESPIPE 143436 error. 143437 143438 Well, that's a slightly different, but related issue. The ESPIPE 143439 case will _only_ show up when using new-ui to create the separate tty 143440 for mi commands, and is a consequence of this commit: 143441 143442 commit afe09f0b6311a4dd1a7e2dc6491550bb228734f8 143443 Date: Thu Jul 18 17:20:04 2019 +0100 143444 143445 Fix for using named pipes on Windows 143446 143447 Prior to this commit, the new-ui command would open the tty three 143448 times, once each for stdin, stderr, and stdout. After this commit we 143449 open the tty just once and reuse the FILE object for all three roles. 143450 143451 Consider the problem case, where glibc has (unexpectedly) read the 143452 second command into its internal buffer. When we handle the first 143453 command we usually end up having to write something to the mi output 143454 stream. 143455 143456 After the above commit the same FILE object represents both the input 143457 and output streams, so, when gdb tries to write to the FILE object, 143458 glibc spots that there is input pending within the input buffer, and 143459 so assumes that we have read ahead of where we should be in the input 143460 file. To correct for this glibc tries to do an lseek call to 143461 reposition the file offset of the output stream prior to writing to 143462 it. However, as the output stream is a tty, and seeking is not 143463 supported on a tty, this lseek call fails, this results in the ESPIPE, 143464 which ultimately causes gdb to terminate. 143465 143466 So, now we understand why the ESPIPE triggers (which was what caused 143467 the gdb crash in the original bug report), and we also understand that 143468 sometime gdb will not handle the second command in a timely 143469 fashion (if the first command is just the wrong length). So, what to 143470 do about all this? 143471 143472 We could revert the commit mentioned above (and implement its 143473 functionality another way). This would certainly resolve the ESPIPE 143474 issue, the buffered input would now only be on the input stream, the 143475 output stream would have no buffered input, and so glibc would never 143476 try to lseek, and so we'd never get the ESPIPE error. 143477 143478 However, this only solves one of the two problems. We would still 143479 suffer from the problem where, if the first command is just the wrong 143480 length, the second command will not (immediately) get handled. 143481 143482 The only solution I can see to this problem is to unbuffer the input 143483 stream. If glibc is not buffering the input, but instead, we read 143484 incoming data character by character from the kernel, then everything 143485 will be fine. As soon as we see the newline at the end of the first 143486 command we will handle the first command. As glibc will have no 143487 buffered input it will not be tempted to lseek, so no ESPIPE error. 143488 When we go have to the event loop there will be more data pending in 143489 the kernel, so the select will immediately return, and the second 143490 command will be processed. 143491 143492 I'm tempted to suggest that we should move the unbuffering of the 143493 input stream out of gdb_readline_no_editing_callback and do it 143494 somewhere earlier, more like when we create the input streams. 143495 However, I've not done that in this commit for a couple of reasons: 143496 143497 1. By keeping the unbuffering in gdb_readline_no_editing_callback 143498 I'm making the smallest possible change that fixes the bug. Moving 143499 the unbuffering somewhere better can be done as a refactor later, if 143500 that 's felt to be important, 143501 143502 2. I don't think making repeated calls to unbuffer the input will 143503 have that much performance impact. We only make the unbuffer call 143504 once per call to gdb_readline_no_editing_callback, and, if the input 143505 stream is already unbuffered we'll return pretty quickly, so I don't 143506 see this as being massively costly, 143507 143508 3. Tom is currently doing lots of gdb stream management changes and 143509 I want to minimise the chances we'll conflict. 143510 143511 So, this commit just changes gdb_readline_no_editing_callback to 143512 always unbuffer the input stream. 143513 143514 The test for this issue sends two commands in a loop, with the first 143515 command growing bigger each time around the loop. I actually make the 143516 first command bigger by just adding whitespace to the front, as gdb 143517 still has to read the complete command (including whitespace) via 143518 glibc, so this is enough to trigger the bug. 143519 143520 The original bug was reported when using a virtual machine, and in 143521 this situation we see this in the strace output: 143522 143523 read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) = 64 143524 read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67 143525 143526 I'm not completely sure what's going on here, but it appears that the 143527 kernel on the virtual machine is delivering the input to glibc slower 143528 than I see on my real hardware; glibc asks for 1024 bytes, but only 143529 gets 64 bytes the first time. In the second read we see the problem 143530 case, the first character is the newline, but then the entire second 143531 command is included. 143532 143533 If I run this exact example on my real hardware then the first command 143534 would not be truncated at 64 bytes, instead, I'd expect to see the 143535 newline included in the first read, with the second command split into 143536 a second read. 143537 143538 So, for testing, I check cases where the first command is just a few 143539 characters (starting at 8 character), all the way up to 2048 143540 characters. Hopefully, this should mean we hit the problem case for 143541 most machine setups. 143542 143543 The only last question relates to commit afe09f0b6311a4d that I 143544 mentioned earlier. That commit was intended to provide support for 143545 Microsoft named pipes: 143546 143547 https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes 143548 143549 I know next to nothing about this topic beyond a brief scan of the 143550 above link, but I think these windows named pipe are closer in 143551 behaviour to unix sockets than to unix named fifos. 143552 143553 I am a little nervous that, after the above commit, we now use the 143554 same FILE for in, err, and out streams. In contrast, in a vanilla C 143555 program, I would expect different FILE objects for each stream. 143556 143557 Still, I'm reluctant to revert the above commit (and provide the same 143558 functionality a different way) without a specific bug to point at, 143559 and, now that the streams are unbuffered, I expect a lot of the read 143560 and write calls are going straight to the kernel with minimal glibc 143561 involvement, so maybe it doesn't really matter. Anyway, I haven't 143562 touched the above patch, but it is something to keep in mind when 143563 working in this area. 143564 143565 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28711 143566 1435672022-02-07 Andrew Burgess <aburgess@redhat.com> 143568 143569 gdb/disasm: combine the no printing disassembler setup code 143570 We have three places in gdb where we initialise a disassembler that 143571 will not print anything (used for figuring out the length of 143572 instructions, or collecting other information from the disassembler). 143573 143574 Each of these places has its own stub function to act as a print like 143575 callback, the stub function is identical in each case, and just does 143576 nothing. 143577 143578 In this commit I create a new function to initialise a disassembler 143579 that doesn't print anything, and have all three locations use this new 143580 function. There's now only one non-printing stub function. 143581 143582 There should be no user visible changes after this commit. 143583 1435842022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 143585 143586 gdb: add the 'set/show suppress-cli-notifications' command 143587 GDB already has a flag to suppress printing notification events, such 143588 as thread and inferior context switches, on the CLI. This is used 143589 internally when executing commands. Make the flag available to the 143590 user via a new command. This is expected to be useful in scripts. 143591 143592 For instance, suppose that when Inferior 1 gets to a certain state, 143593 you want to add and set up a new inferior using the commands below, 143594 but you also want to have a reduced/clean output. 143595 143596 define do-setup 143597 printf "Setting up Inferior 2...\n" 143598 add-inferior -exec a.out 143599 inferior 2 143600 break file.c:3 143601 run 143602 inferior 1 143603 printf "Done\n" 143604 end 143605 143606 Currently, GDB prints 143607 143608 (gdb) do-setup 143609 Setting up Inferior 2... 143610 [New inferior 2] 143611 Added inferior 2 on connection 1 (native) 143612 [Switching to inferior 2 [<null>] (/tmp/a.out)] 143613 Breakpoint 2 at 0x1155: file file.c, line 3. 143614 143615 Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3 143616 3 return 0; 143617 [Switching to inferior 1 [process 7670] (/tmp/test)] 143618 [Switching to thread 1.1 (process 7670)] 143619 #0 main () at test.c:2 143620 2 int a = 1; 143621 Done 143622 143623 GDB's Python API make it possible to capture and return GDB's output, 143624 but this does not work for all the streams. In particular, CLI 143625 notification events are not captured: 143626 143627 (gdb) python gdb.execute("do-setup", False, True) 143628 [Switching to inferior 2 [<null>] (/tmp/a.out)] 143629 143630 Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3 143631 3 return 0; 143632 [Switching to inferior 1 [process 8263] (/tmp/test)] 143633 [Switching to thread 1.1 (process 8263)] 143634 #0 main () at test.c:2 143635 2 int a = 1; 143636 143637 You can use the new "set suppress-cli-notifications" command to 143638 suppress the output: 143639 143640 (gdb) set suppress-cli-notifications on 143641 (gdb) do-setup 143642 Setting up Inferior 2... 143643 [New inferior 2] 143644 Added inferior 2 on connection 1 (native) 143645 Breakpoint 2 at 0x1155: file file.c, line 3. 143646 Done 143647 1436482022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 143649 143650 gdb/cli: add a 'normal_stop' option to 'cli_suppress_notification' 143651 Extend the 'cli_suppress_notification' struct with a new field, 143652 'normal_stop', that can be used for checking if printing normal stop 143653 events on the CLI should be suppressed. 143654 143655 This patch only introduces the flag. The subsequent patch adds a user 143656 command to turn the flag off/on. 143657 1436582022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 143659 143660 gdb/cli: convert cli_suppress_notification from int to bool 143661 Convert the suppress_notification flag for the CLI from int to bool. 143662 1436632022-02-07 Alan Modra <amodra@gmail.com> 143664 143665 Revert "elf: Remove the 1-page gap before the RELRO segment" 143666 This reverts commit 2f83249c13d86065b4c7cdb198ea871017b4bba1. 143667 143668 PR ld/28743 143669 * ldlang.c (lang_size_relro_segment_1): Revert 2022-01-10 changes. 143670 * testsuite/ld-i386/pr20830.d: Likewise. 143671 * testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise. 143672 * testsuite/ld-x86-64/pr14207.d: Likewise. 143673 * testsuite/ld-x86-64/pr18176.d: Likewise. 143674 * testsuite/ld-x86-64/pr20830a-now.d: Likewise. 143675 * testsuite/ld-x86-64/pr20830a.d: Likewise. 143676 * testsuite/ld-x86-64/pr20830b-now.d: Likewise. 143677 * testsuite/ld-x86-64/pr20830b.d: Likewise. 143678 * testsuite/ld-x86-64/pr21038a-now.d: Likewise. 143679 * testsuite/ld-x86-64/pr21038a.d: Likewise. 143680 * testsuite/ld-x86-64/pr21038b-now.d: Likewise. 143681 * testsuite/ld-x86-64/pr21038c-now.d: Likewise. 143682 * testsuite/ld-x86-64/pr21038c.d: Likewise. 143683 1436842022-02-07 Alan Modra <amodra@gmail.com> 143685 143686 Revert "ld: Rewrite lang_size_relro_segment_1" 143687 This reverts commit c804c6f98d342c3d46f73d7a7ec6229d5ab1c9f3. 143688 143689 PR ld/28743 143690 PR ld/28819 143691 * ldlang.c (lang_size_relro_segment_1): Revert 2022-01-14 change. 143692 * testsuite/ld-x86-64/pr28743-1.d: Likewise. 143693 * testsuite/ld-x86-64/pr28743-1.s: Likewise. 143694 * testsuite/ld-x86-64/x86-64.exp: Likewise. 143695 1436962022-02-07 GDB Administrator <gdbadmin@sourceware.org> 143697 143698 Automatic date update in version.in 143699 1437002022-02-06 Alan Modra <amodra@gmail.com> 143701 143702 A more elegant pr28827-1 testcase 143703 Use .irpc macros in pr28827-1.s 143704 143705 * testsuite/ld-powerpc/pr28827-1.s: Make the testcase more 143706 elegant. Comment. 143707 1437082022-02-06 Tom Tromey <tom@tromey.com> 143709 143710 Merge do_val_print and common_val_print 143711 The only caller of do_val_print just does a small bit of work before 143712 the call. This patch merges the two functions, and removes an 143713 unnecessary local variable, making gdb a bit simpler. 143714 1437152022-02-06 Simon Marchi <simon.marchi@efficios.com> 143716 143717 gdb: remove SYMBOL_LINE macro 143718 Add a getter and a setter for a symbol's line. Remove the corresponding macro 143719 and adjust all callers. 143720 143721 Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5 143722 1437232022-02-06 Simon Marchi <simon.marchi@efficios.com> 143724 143725 gdb: remove SYMBOL_TYPE macro 143726 Add a getter and a setter for a symbol's type. Remove the corresponding 143727 macro and adjust all callers. 143728 143729 Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de 143730 1437312022-02-06 Simon Marchi <simon.marchi@efficios.com> 143732 143733 gdb: remote SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION macro 143734 Add a getter for a whether a symbol is a C++ template function. Remove 143735 the corresponding macro and adjust all callers. 143736 143737 Change-Id: I89abc2802a952b77b0e0eb73a25c2306cb8e8bcc 143738 1437392022-02-06 Simon Marchi <simon.marchi@efficios.com> 143740 143741 gdb: remove SYMBOL_INLINED macro 143742 Add a getter and a setter for whether a symbol is inlined. Remove the 143743 corresponding macro and adjust all callers. 143744 143745 Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279 143746 1437472022-02-06 Simon Marchi <simon.marchi@efficios.com> 143748 143749 gdb: remove SYMBOL_IS_ARGUMENT macro 143750 Add a getter and a setter for whether a symbol is an argument. Remove 143751 the corresponding macro and adjust all callers. 143752 143753 Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81 143754 1437552022-02-06 Simon Marchi <simon.marchi@efficios.com> 143756 143757 gdb: remove SYMBOL_OBJFILE_OWNED macro 143758 Add a getter and a setter for whether a symbol is objfile owned. Remove 143759 the corresponding macro and adjust all callers. 143760 143761 Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c 143762 1437632022-02-06 Simon Marchi <simon.marchi@efficios.com> 143764 143765 gdb: remove SYMBOL_DOMAIN macro 143766 Add a getter and a setter for a symbol's domain. Remove the 143767 corresponding macro and adjust all callers. 143768 143769 Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3 143770 1437712022-02-06 Simon Marchi <simon.marchi@efficios.com> 143772 143773 gdb: remove SYMBOL_CLASS macro, add getter 143774 Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a 143775 1437762022-02-06 Simon Marchi <simon.marchi@efficios.com> 143777 143778 gdb: remove SYMBOL_IMPL macro, add method 143779 Add a getter for a symbol's "impl". Remove the corresponding macro and 143780 adjust all callers. 143781 143782 Change-Id: Ibe26ed442f0f99a0f5cddafca30bd96ec7fb9fa8 143783 1437842022-02-06 Simon Marchi <simon.marchi@efficios.com> 143785 143786 gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setter 143787 Add a getter and a setter for a symbol's aclass index. Remove the 143788 corresponding macro and adjust all callers. 143789 143790 Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39 143791 1437922022-02-06 Simon Marchi <simon.marchi@efficios.com> 143793 143794 gdb: remove SYMBOL_MATCHES_SEARCH_NAME 143795 It seems like this macro is not needed at all anymore, it just wraps the 143796 function of the same name with the same arguments. 143797 143798 Change-Id: I3c342ac8d89c27af5aee1a819dc32cc6396fd41b 143799 1438002022-02-06 Simon Marchi <simon.marchi@efficios.com> 143801 143802 gdb: remove SYMTAB_DIRNAME macro 143803 Remove the macro, replace with an equivalent method. 143804 143805 Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed 143806 1438072022-02-06 Simon Marchi <simon.marchi@efficios.com> 143808 143809 gdb: remove SYMTAB_PSPACE macro 143810 Remove the macro, replace with an equivalent method. 143811 143812 Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69 143813 1438142022-02-06 Simon Marchi <simon.marchi@efficios.com> 143815 143816 gdb: remove SYMTAB_OBJFILE macro 143817 Remove the macro, replace with an equivalent method. 143818 143819 Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb 143820 1438212022-02-06 Simon Marchi <simon.marchi@efficios.com> 143822 143823 gdb: remove SYMTAB_BLOCKVECTOR macro 143824 Remove the macro, replace with an equivalent method. 143825 143826 Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c 143827 1438282022-02-06 Simon Marchi <simon.marchi@efficios.com> 143829 143830 gdb: remove SYMTAB_LANGUAGE macro, add getter/setter 143831 Add a getter and a setter for a symtab's language. Remove the 143832 corresponding macro and adjust all callers. 143833 143834 Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f 143835 1438362022-02-06 Simon Marchi <simon.marchi@efficios.com> 143837 143838 gdb: remove SYMTAB_LINETABLE macro, add getter/setter 143839 Add a getter and a setter for a symtab's linetable. Remove the 143840 corresponding macro and adjust all callers. 143841 143842 Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c 143843 1438442022-02-06 Simon Marchi <simon.marchi@efficios.com> 143845 143846 gdb: remove SYMTAB_COMPUNIT macro, add getter/setter 143847 Add a getter and a setter for a symtab's compunit_symtab. Remove the 143848 corresponding macro and adjust all callers. 143849 143850 For brevity, I chose the name "compunit" instead of "compunit_symtab" 143851 the the field, getter and setter names. Since we are already in symtab 143852 context, the _symtab suffix seems redundant. 143853 143854 Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92 143855 1438562022-02-06 Simon Marchi <simon.marchi@efficios.com> 143857 143858 gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setter 143859 Add a getter and a setter for a compunit_symtab's macro table. Remove the 143860 corresponding macro and adjust all callers. 143861 143862 Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a 143863 1438642022-02-06 Simon Marchi <simon.marchi@efficios.com> 143865 143866 gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setter 143867 Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag. 143868 Remove the corresponding macro and adjust all callers. 143869 143870 Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a 143871 1438722022-02-06 Simon Marchi <simon.marchi@efficios.com> 143873 143874 gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setter 143875 Add a getter and a setter for a compunit_symtab's locations valid flag. 143876 Remove the corresponding macro and adjust all callers. 143877 143878 Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01 143879 1438802022-02-06 Simon Marchi <simon.marchi@efficios.com> 143881 143882 gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setter 143883 Add a getter and a setter for a compunit_symtab's block line section. Remove 143884 the corresponding macro and adjust all callers. 143885 143886 Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455 143887 1438882022-02-06 Simon Marchi <simon.marchi@efficios.com> 143889 143890 gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setter 143891 Add a getter and a setter for a compunit_symtab's blockvector. Remove 143892 the corresponding macro and adjust all callers. 143893 143894 Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64 143895 1438962022-02-06 Simon Marchi <simon.marchi@efficios.com> 143897 143898 gdb: remove COMPUNIT_DIRNAME macro, add getter/setter 143899 Add a getter and a setter for a compunit_symtab's dirname. Remove the 143900 corresponding macro and adjust all callers. 143901 143902 Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e 143903 1439042022-02-06 Simon Marchi <simon.marchi@efficios.com> 143905 143906 gdb: remove COMPUNIT_PRODUCER macro, add getter/setter 143907 Add a getter and a setter for a compunit_symtab's producer. Remove the 143908 corresponding macro and adjust all callers. 143909 143910 Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b 143911 1439122022-02-06 Simon Marchi <simon.marchi@efficios.com> 143913 143914 gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setter 143915 Add a getter and a setter for a compunit_symtab's debugformat. Remove 143916 the corresponding macro and adjust all callers. 143917 143918 Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975 143919 1439202022-02-06 Simon Marchi <simon.marchi@efficios.com> 143921 143922 gdb: remove COMPUNIT_FILETABS macro 143923 I think that most remaining uses of COMPUNIT_FILETABS intend to get the 143924 primary filetab of the compunit_symtab specifically (and not to iterate 143925 over all filetabs, for example, those cases would use compunit_filetabs, 143926 which has been converted to compunit_symtab::filetabs), so replace mosts 143927 uses with compunit_symtab::primary_filetab. 143928 143929 In jit.c, function finalize_symtab, we can save the symtab object 143930 returned by allocate_symtab and use it, it makes things simpler. 143931 143932 Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38 143933 1439342022-02-06 Simon Marchi <simon.marchi@efficios.com> 143935 143936 gdb: move compunit_filetabs to compunit_symtab::filetabs 143937 Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a 143938 method of compunit_symtab. The name filetabs conflicts with the current 143939 name of the field. Rename the field to m_filetabs, since at this point 143940 nothing outside of compunit_symtab uses it, so we should treat it as 143941 private (even though it's not actually private). Rename the 143942 last_filetab field to m_last_filetab as well (it's only used on 143943 compunit_symtab::add_filetab). 143944 143945 Adjust the COMPUNIT_FILETABS macro to keep its current behavior of 143946 returning the first filetab. 143947 143948 Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3 143949 1439502022-02-06 Simon Marchi <simon.marchi@efficios.com> 143951 143952 gdb: add compunit_symtab::set_primary_filetab method 143953 Add a method to set the primary filetab of the CU. This is currently 143954 done in buildsym_compunit::end_symtab_with_blockvector. 143955 143956 Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74 143957 1439582022-02-06 Simon Marchi <simon.marchi@efficios.com> 143959 143960 gdb: add compunit_symtab::add_filetab method 143961 Add a method to append a filetab/symtab to a compunit_symtab. There is 143962 a single place where this is done currently, in allocate_symtab. 143963 143964 Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d 143965 1439662022-02-06 Simon Marchi <simon.marchi@efficios.com> 143967 143968 gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetab 143969 Make compunit_primary_filetab a method of compunit_symtab. 143970 143971 Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768 143972 1439732022-02-06 Simon Marchi <simon.marchi@efficios.com> 143974 143975 gdb: remove COMPUNIT_OBJFILE macro 143976 Remove the macro, update all users to use the getter directly. 143977 143978 Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6 143979 1439802022-02-06 Simon Marchi <simon.marchi@efficios.com> 143981 143982 gdb: add getter/setter for compunit_symtab::objfile 143983 Rename the field to m_objfile, and add a getter and a setter. Update 143984 all users. 143985 143986 Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317 143987 1439882022-02-06 Tom Tromey <tom@tromey.com> 143989 143990 Allow non-ASCII characters in Rust identifiers 143991 Rust 1.53 (quite a while ago now) ungated the support for non-ASCII 143992 identifiers. This didn't work in gdb. This is PR rust/20166. 143993 143994 This patch fixes the problem by allowing non-ASCII characters to be 143995 considered as identifier components. It seemed simplest to just pass 143996 them through -- doing any extra checking didn't seem worthwhile. 143997 143998 The new test also verifies that such characters are allowed in strings 143999 and character literals as well. The latter also required a bit of 144000 work in the lexer. 144001 144002 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166 144003 1440042022-02-06 Tom Tromey <tom@tromey.com> 144005 144006 Fix Rust parser bug with function fields 144007 In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a 144008 function-valued field 'f' in 'obj'. The Rust parser in gdb currently 144009 gets this wrong. This is PR rust/24082. 144010 144011 The expression and Rust parser rewrites made this simple to fix -- 144012 simply wrapping a parenthesized expression in a new operation handles 144013 it. This patch has a slight hack because I didn't want to introduce a 144014 new exp_opcode enumeration constant just for this. IMO this doesn't 144015 matter, since we should work toward removing dependencies on these 144016 opcodes anyway; but let me know what you think of this. 144017 144018 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082 144019 1440202022-02-06 H.J. Lu <hjl.tools@gmail.com> 144021 144022 ld: Add emultempl/emulation.em 144023 Add emultempl/emulation.em to define ld_${EMULATION_NAME}_emulation so 144024 that new emulation hooks can be added easily. 144025 144026 * emultempl/aix.em (LDEMUL_AFTER_OPEN): New. 144027 (LDEMUL_SET_OUTPUT_ARCH): Likewise. 144028 (LDEMUL_CHOOSE_TARGET): Likewise. 144029 (LDEMUL_BEFORE_ALLOCATION): Likewise. 144030 (LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS): Likewise. 144031 (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise. 144032 (LDEMUL_PARSE_ARGS): Likewise. 144033 (LDEMUL_ADD_OPTIONS): Likewise. 144034 (LDEMUL_HANDLE_OPTION): Likewise. 144035 (LDEMUL_UNRECOGNIZED_FILE): Likewise. 144036 (LDEMUL_PRINT_SYMBOL): Likewise. 144037 (ld_${EMULATION_NAME}_emulation): Removed. 144038 Source ${srcdir}/emultempl/emulation.em. 144039 * emultempl/beos.em (gld_${EMULATION_NAME}_before_parse): 144040 Renamed to ... 144041 (gld${EMULATION_NAME}_before_parse): This. 144042 (gld_${EMULATION_NAME}_set_symbols): Renamed to ... 144043 (gld${EMULATION_NAME}_set_symbols): This. 144044 (gld_${EMULATION_NAME}_after_open): Renamed to ... 144045 (gld${EMULATION_NAME}_after_open): This. 144046 (gld_${EMULATION_NAME}_before_allocation): Renamed to ... 144047 (gld${EMULATION_NAME}_before_allocation): This. 144048 (gld_${EMULATION_NAME}_get_script): Renamed to ... 144049 (gld${EMULATION_NAME}_get_script): This. 144050 (LDEMUL_AFTER_OPEN): New. 144051 (LDEMUL_BEFORE_ALLOCATION): Likewise. 144052 (LDEMUL_PLACE_ORPHAN): Likewise. 144053 (LDEMUL_SET_SYMBOLS): Likewise. 144054 (LDEMUL_ADD_OPTIONS): Likewise. 144055 (LDEMUL_HANDLE_OPTION): Likewise. 144056 (ld_${EMULATION_NAME}_emulation): Removed. 144057 Source ${srcdir}/emultempl/emulation.em. 144058 * emultempl/elf.em (LDEMUL_AFTER_PARSE): New. 144059 (LDEMUL_AFTER_OPEN): Likewise. 144060 (LDEMUL_BEFORE_PLACE_ORPHANS): Likewise. 144061 (LDEMUL_AFTER_ALLOCATION): Likewise. 144062 (LDEMUL_SET_OUTPUT_ARCH): Likewise. 144063 (LDEMUL_BEFORE_ALLOCATION): Likewise. 144064 (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise. 144065 (LDEMUL_PLACE_ORPHAN): Likewise. 144066 (LDEMUL_ADD_OPTIONS): Likewise. 144067 (LDEMUL_HANDLE_OPTION): Likewise. 144068 (LDEMUL_LIST_OPTIONS): Likewise. 144069 (LDEMUL_UNRECOGNIZED_FILE): Likewise. 144070 (ld_${EMULATION_NAME}_emulation): Removed. 144071 Source ${srcdir}/emultempl/emulation.em. 144072 * emultempl/emulation.em: New file. 144073 * emultempl/generic.em (ld_${EMULATION_NAME}_emulation): Removed. 144074 Source ${srcdir}/emultempl/emulation.em. 144075 * emultempl/msp430.em (LDEMUL_AFTER_OPEN): New. 144076 (LDEMUL_AFTER_ALLOCATION): Likewise. 144077 (LDEMUL_PLACE_ORPHAN): Likewise. 144078 (LDEMUL_FINISH): Likewise. 144079 (LDEMUL_ADD_OPTIONS): Likewise. 144080 (LDEMUL_HANDLE_OPTION): Likewise. 144081 (LDEMUL_LIST_OPTIONS): Likewise. 144082 (ld_${EMULATION_NAME}_emulation): Removed. 144083 Source ${srcdir}/emultempl/emulation.em. 144084 * emultempl/pe.em (gld_${EMULATION_NAME}_before_parse): Renamed 144085 to ... 144086 (gld${EMULATION_NAME}_before_parse): This. 144087 (gld_${EMULATION_NAME}_list_options): Renamed to ... 144088 (gld${EMULATION_NAME}_list_options): This. 144089 (gld_${EMULATION_NAME}_set_symbols): Renamed to ... 144090 (gld${EMULATION_NAME}_set_symbols): This. 144091 (gld_${EMULATION_NAME}_after_parse): Renamed to ... 144092 (gld${EMULATION_NAME}_after_parse): This. 144093 (gld_${EMULATION_NAME}_after_open): Renamed to ... 144094 (gld${EMULATION_NAME}_after_open): This. 144095 (gld_${EMULATION_NAME}_before_allocation): Renamed to ... 144096 (gld${EMULATION_NAME}_before_allocation): This. 144097 (gld_${EMULATION_NAME}_unrecognized_file): Renamed to ... 144098 (gld${EMULATION_NAME}_unrecognized_file): This. 144099 (gld_${EMULATION_NAME}_recognized_file): Renamed to ... 144100 (gld${EMULATION_NAME}_recognized_file): This. 144101 (gld_${EMULATION_NAME}_finish): Renamed to ... 144102 (gld${EMULATION_NAME}_finish): This. 144103 (gld_${EMULATION_NAME}_place_orphan): Renamed to ... 144104 (gld${EMULATION_NAME}_place_orphan): This. 144105 (gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ... 144106 (gld${EMULATION_NAME}_open_dynamic_archive): This. 144107 (gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ... 144108 (gld${EMULATION_NAME}_find_potential_libraries): This. 144109 (gld_${EMULATION_NAME}_get_script): Renamed to ... 144110 (gld${EMULATION_NAME}_get_script): This. 144111 (LDEMUL_AFTER_PARSE): New. 144112 (LDEMUL_AFTER_OPEN): Likewise. 144113 (LDEMUL_BEFORE_ALLOCATION): Likewise. 144114 (LDEMUL_FINISH=): Likewise. 144115 (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise. 144116 (LDEMUL_PLACE_ORPHAN): Likewise. 144117 (LDEMUL_SET_SYMBOLS): Likewise. 144118 (LDEMUL_ADD_OPTIONS): Likewise. 144119 (LDEMUL_HANDLE_OPTION): Likewise. 144120 (LDEMUL_UNRECOGNIZED_FILE): Likewise. 144121 (LDEMUL_LIST_OPTIONS): Likewise. 144122 (LDEMUL_RECOGNIZED_FILE): Likewise. 144123 (LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise. 144124 (ld_${EMULATION_NAME}_emulation): Removed. 144125 Source ${srcdir}/emultempl/emulation.em. 144126 * emultempl/pep.em (gld_${EMULATION_NAME}_before_parse): Renamed 144127 to ... 144128 (gld${EMULATION_NAME}_before_parse): This. 144129 (gld_${EMULATION_NAME}_list_options): Renamed to ... 144130 (gld${EMULATION_NAME}_list_options): This. 144131 (gld_${EMULATION_NAME}_set_symbols): Renamed to ... 144132 (gld${EMULATION_NAME}_set_symbols): This. 144133 (gld_${EMULATION_NAME}_after_parse): Renamed to ... 144134 (gld${EMULATION_NAME}_after_parse): This. 144135 (gld_${EMULATION_NAME}_after_open): Renamed to ... 144136 (gld${EMULATION_NAME}_after_open): This. 144137 (gld_${EMULATION_NAME}_before_allocation): Renamed to ... 144138 (gld${EMULATION_NAME}_before_allocation): This. 144139 (gld_${EMULATION_NAME}_unrecognized_file): Renamed to ... 144140 (gld${EMULATION_NAME}_unrecognized_file): This. 144141 (gld_${EMULATION_NAME}_recognized_file): Renamed to ... 144142 (gld${EMULATION_NAME}_recognized_file): This. 144143 (gld_${EMULATION_NAME}_finish): Renamed to ... 144144 (gld${EMULATION_NAME}_finish): This. 144145 (gld_${EMULATION_NAME}_place_orphan): Renamed to ... 144146 (gld${EMULATION_NAME}_place_orphan): This. 144147 (gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ... 144148 (gld${EMULATION_NAME}_open_dynamic_archive): This. 144149 (gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ... 144150 (gld${EMULATION_NAME}_find_potential_libraries): This. 144151 (gld_${EMULATION_NAME}_get_script): Renamed to ... 144152 (gld${EMULATION_NAME}_get_script): This. 144153 (LDEMUL_AFTER_PARSE): New. 144154 (LDEMUL_AFTER_OPEN): Likewise. 144155 (LDEMUL_BEFORE_ALLOCATION): Likewise. 144156 (LDEMUL_FINISH=): Likewise. 144157 (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise. 144158 (LDEMUL_PLACE_ORPHAN): Likewise. 144159 (LDEMUL_SET_SYMBOLS): Likewise. 144160 (LDEMUL_ADD_OPTIONS): Likewise. 144161 (LDEMUL_HANDLE_OPTION): Likewise. 144162 (LDEMUL_UNRECOGNIZED_FILE): Likewise. 144163 (LDEMUL_LIST_OPTIONS): Likewise. 144164 (LDEMUL_RECOGNIZED_FILE): Likewise. 144165 (LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise. 144166 (ld_${EMULATION_NAME}_emulation): Removed. 144167 Source ${srcdir}/emultempl/emulation.em. 144168 * emultempl/ticoff.em (gld_${EMULATION_NAME}_list_options): 144169 Renamed to ... 144170 (gld${EMULATION_NAME}_list_options): This. 144171 (gld_${EMULATION_NAME}_before_parse): Renamed to ... 144172 (gld_${EMULATION_NAME}_get_script): Renamed to ... 144173 (gld${EMULATION_NAME}_get_script): This. 144174 (LDEMUL_ADD_OPTIONS): New. 144175 (LDEMUL_HANDLE_OPTION): Likewise. 144176 (LDEMUL_LIST_OPTIONS): Likewise. 144177 (ld_${EMULATION_NAME}_emulation): Removed. 144178 Source ${srcdir}/emultempl/emulation.em. 144179 * emultempl/vanilla.em (LDEMUL_BEFORE_PARSE): New. 144180 (LDEMUL_SET_OUTPUT_ARCH): Likewise. 144181 (LDEMUL_GET_SCRIPT): Likewise. 144182 (EMULATION_NAME): Likewise. 144183 (OUTPUT_FORMAT): Likewise. 144184 (ld_vanilla_emulation): Removed. 144185 Source ${srcdir}/emultempl/emulation.em. 144186 1441872022-02-06 Andrew Burgess <aburgess@redhat.com> 144188 144189 gdb/doc: update docs for 'info win' and 'winheight' commands 144190 This started by noticing that the docs for 'winheight' are out of 144191 date, the docs currently give a specific list of possible window 144192 names. However, now that windows can be implemented in Python, it is 144193 not possible to list all possible names. 144194 144195 I now link the user to a mechanism by which they can discover the 144196 valid names for themselves at run time (by using 'info win'). That, 144197 and the fact that gdb provides tab-completion of the name at the 144198 command line, feels good enough. 144199 144200 Finally, I noticed that the docs for 'win info' don't explicitly say 144201 that the name of the window is given in the output. This could 144202 probably have been inferred, but given I'm now linking to this as a 144203 mechanism to find the window name, I'd prefer to mention that the name 144204 can be found in the output. 144205 1442062022-02-06 Andrew Burgess <aburgess@redhat.com> 144207 144208 gdb/tui: add window width information to 'info win' output 144209 Now that we support horizontal window placement in the tui, it makes 144210 sense to have 'info win' include the width, as well as the height, of 144211 the currently visible windows. 144212 144213 That's what this commit does. Example output is now: 144214 144215 (gdb) info win 144216 Name Lines Columns Focus 144217 src 12 40 (has focus) 144218 asm 12 41 144219 status 1 80 144220 cmd 11 80 144221 144222 I've added a NEWS entry, but the documentation was already suitably 144223 vague, it just says that 'info win' displays the size of the visible 144224 windows, so I don't think anything needs to be added there. 144225 144226 I've also added some tests, as far as I could find, the 'info win' 144227 command was previously untested. 144228 1442292022-02-06 GDB Administrator <gdbadmin@sourceware.org> 144230 144231 Automatic date update in version.in 144232 1442332022-02-05 H.J. Lu <hjl.tools@gmail.com> 144234 144235 x86: Skip undefined symbol when finishing DT_RELR 144236 Don't abort for undefined symbol when finishing DT_RELR. Instead, skip 144237 undefined symbol. Undefined symbol will be reported by relocate_section. 144238 144239 * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Skip 144240 undefined symbol in finishing phase. 144241 1442422022-02-05 Alan Modra <amodra@gmail.com> 144243 144244 Tweak assembler invocation for pr28827-1 test 144245 PR 28827 144246 * testsuite/ld-powerpc/pr28827-1.d: Pass -a64 to gas. 144247 1442482022-02-05 Alan Modra <amodra@gmail.com> 144249 144250 PR28827 testcase 144251 This testcase triggers a stub sizing error with the patches applied 144252 for PR28743 (commit 2f83249c13d8 and c804c6f98d34). 144253 144254 PR 28827 144255 * testsuite/ld-powerpc/pr28827-1.s, 144256 * testsuite/ld-powerpc/pr28827-1.d: New test. 144257 * testsuite/ld-powerpc/powerpc.exp: Run it. 144258 1442592022-02-05 Alan Modra <amodra@gmail.com> 144260 144261 Enable "size" as a dumpprog in ld 144262 binutils/ 144263 * testsuite/lib/binutils-common.exp (run_dump_test): Reference 144264 global SIZE and SIZEFLAGS. 144265 ld/ 144266 * testsuite/config/default.exp: Define SIZE and SIZEFLAGS. 144267 1442682022-02-05 Alan Modra <amodra@gmail.com> 144269 144270 Detect .eh_frame_hdr earlier for SIZEOF_HEADERS 144271 Current code detects the need for PT_GNU_EH_FRAME using a field set by 144272 _bfd_elf_discard_section_eh_frame_hdr, which is called fairly late in 144273 the linking process. Use the elf hash table eh_info instead, which is 144274 set up earlier by size_dynamic_sections. 144275 144276 * elf-bfd.h (struct output_elf_obj_tdata): Delete eh_frame_hdr. 144277 (elf_eh_frame_hdr): Don't define. 144278 (_bfd_elf_discard_section_eh_frame_hdr): Update prototype. 144279 * elf-eh-frame.c (_bfd_elf_discard_section_eh_frame_hdr): Delete 144280 abfd parameter. Don't set elf_eh_frame_hdr. 144281 * elf.c (elf_eh_frame_hdr): New function. 144282 (get_program_header_size): Adjust elf_eh_frame_hdr call. 144283 (_bfd_elf_map_sections_to_segments): Likewise. 144284 1442852022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com> 144286 144287 sim: mips: Add simulator support for mips32r6/mips64r6 144288 2022-02-01 Ali Lown <ali.lown@imgtec.com> 144289 Andrew Bennett <andrew.bennett@imgtec.com> 144290 Dragan Mladjenovic <dragan.mladjenovic@rt-rk.com> 144291 Faraz Shahbazker <fshahbazker@wavecomp.com> 144292 144293 sim/common/ChangeLog: 144294 * sim-bits.h (EXTEND9, EXTEND18 ,EXTEND19, EXTEND21, 144295 EXTEND26): New macros. 144296 144297 sim/mips/ChangeLog: 144298 * Makefile.in (IGEN_INCLUDE): Add mips3264r6.igen. 144299 * configure: Regenerate. 144300 * configure.ac: Support mipsisa32r6 and mipsisa64r6. 144301 (sim_engine_run): Pick simulator model from processor specified 144302 in e_flags. 144303 * cp1.c (value_fpr): Handle fmt_dc32. 144304 (fp_unary, fp_binary): Zero initialize locals. 144305 (update_fcsr, fp_classify, fp_rint, fp_r6_cmp, inner_fmac, 144306 fp_fmac, fp_min, fp_max, fp_mina, fp_maxa, fp_fmadd, fp_fmsub): 144307 New functions. 144308 (sim_fpu_class_mips_mapping): New. 144309 * cp1.h (fcsr_ABS2008_mask, fcsr_ABS2008_shift): New define. 144310 * interp.c (MIPSR6_P): New. 144311 (load_word): Allow unaligned memory access for MIPSR6. 144312 * micromips.igen (sc, scd): Adapt to new do_sc* helper signature. 144313 * mips.igen: Add *r6 models. 144314 (signal_if_cti, forbiddenslot32): New helpers. 144315 (delayslot32): Use signal_if_cti. 144316 (do_sc, do_scd); Add store_ll_bit parameter. 144317 (sc, scd): Adapt to previous change. 144318 (nal, beq, bal): New definitions for *r6. 144319 (sll): Split nop and ssnop cases into ... 144320 (nop, ssnop): New definitions. 144321 (loadstore_ea): Use the 32-bit compatibility adressing. 144322 (cache): Split logic into ... 144323 (do_cache): New helper. 144324 (check_fpu): Select IEEE 754-2008 mode for R6. 144325 (not_word_value, unpredictable, check_mt_hilo, check_mf_hilo, 144326 check_multi_hilo, check_div_hilo, check_u64, do_dmfc1b, add, 144327 li, addu, and, andi, bgez, bgtz, blez, bltz, bne, break, dadd, 144328 daddiu, daddu, dror, dror32, drorv, dsll, dsll32, dsllv, dsra, 144329 dsra32, dsrav, dsrl, dsrl32, dsub, dsubu, j, jal, jalr, 144330 jalr.hb, lb, lbu, ld, lh, lhu, lui, lw, lwu, nor, or, ori, ror, 144331 rorv, sb, sd, sh, sll, sllv, slt, slti, sltiu, sltu, sra, srav, 144332 srl, srlv, sub, subu, sw, sync, syscall, teq, tge, tgeu, tlt, 144333 tltu, tne, xor, xori, check_fmt_p, do_load_double, 144334 do_store_double, abs.FMT, add.FMT, ceil.l.FMT, ceil.w.FMT, 144335 cfc1, ctc1, cvt.d.FMT, cvt.l.FMT, cvt.w.FMT, div.FMT, dfmc1, 144336 dmtc1, floor.l.FMT, floor.w.FMT, ldc1, lwc1, mfc1, mov.FMT, 144337 mtc1, mul.FMT, recip.FMT, round.l.FMT, round.w.FMT, rsqrt.FMT, 144338 sdc1, sqrt.FMT, sub.FMT, swc1, trunc.l.FMT, trunc.w.FMT, bc0f, 144339 bc0fl, bc0t, bc0tl, dmfc0, dmtc0, eret, mfc0, mtc0, cop, tlbp, 144340 tlbr, tlbwi, tlbwr): Enable on *r6 models. 144341 * mips3264r2.igen (dext, dextm, dextu, di, dins, dinsm, dinsu, 144342 dsbh, dshd, ei, ext, mfhc1, mthc1, ins, seb, seh, synci, rdhwr, 144343 wsbh): Likewise. 144344 * mips3264r6.igen: New file. 144345 * sim-main.h (FP_formats): Add fmt_dc32. 144346 (FORBIDDEN_SLOT): New macros. 144347 (simFORBIDDENSLOT, FP_R6CMP_*, FP_R6CLASS_*): New defines. 144348 (fp_r6_cmp, fp_classify, fp_rint, fp_min, fp_max, fp_mina, 144349 fp_maxa, fp_fmadd, fp_fmsub): New declarations. 144350 (R6Compare, Classify, RoundToIntegralExact, Min, Max, MinA, 144351 MaxA, FusedMultiplyAdd, FusedMultiplySub): New macros. Wrapping 144352 previous declarations. 144353 144354 sim/testsuite/mips/ChangeLog: 144355 * basic.exp: Add r6-*.s tests. 144356 (run_r6_removed_test): New function. 144357 (run_endian_tests): New function. 144358 * hilo-hazard-3.s: Skip for mips*r6. 144359 * r2-fpu.s: New test. 144360 * r6-64.s: New test. 144361 * r6-branch.s: New test. 144362 * r6-forbidden.s: New test. 144363 * r6-fpu.s: New test. 144364 * r6-llsc-dp.s: New test. 144365 * r6-llsc-wp.s: New test. 144366 * r6-removed.csv: New test. 144367 * r6-removed.s: New test. 144368 * r6.s: New test. 144369 * utils-r6.inc: New inc. 144370 1443712022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com> 144372 144373 sim: Add partial support for IEEE 754-2008 144374 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com> 144375 144376 sim/common/ChangeLog: 144377 * sim-fpu.c (sim_fpu_minmax_nan): New. 144378 (sim_fpu_max): Add variant behaviour for IEEE 754-2008. 144379 (sim_fpu_min): Likewise. 144380 (sim_fpu_is_un, sim_fpu_is_or): New. 144381 (sim_fpu_un, sim_fpu_or): New. 144382 (sim_fpu_is_ieee754_2008, sim_fpu_is_ieee754_1985): New. 144383 (sim_fpu_set_mode): New. 144384 (sim_fpu_classify): New. 144385 * sim-fpu.h (sim_fpu_minmax_nan): New declaration. 144386 (sim_fpu_un, sim_fpu_or): New declarations. 144387 (sim_fpu_is_un, sim_fpu_is_or): New declarations. 144388 (sim_fpu_mode): New enum. 144389 [sim_fpu_state](current_mode): New field. 144390 (sim_fpu_current_mode): New define. 144391 (sim_fpu_is_ieee754_2008): New declaration. 144392 (sim_fpu_is_ieee754_1985): New declaration. 144393 (sim_fpu_set_mode): New declaration. 144394 (sim_fpu_classify): New declaration. 144395 1443962022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com> 144397 144398 sim: Factor out NaN handling in floating point operations 144399 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com> 144400 144401 sim/common/ChangeLog: 144402 * sim-fpu.c (sim_fpu_op_nan): New. 144403 (sim_fpu_add): Factor out NaN operand handling with 144404 a call to sim_fpu_op_nan. 144405 (sim_fpu_sub, sim_fpu_mul, sim_fpu_div): Likewise. 144406 (sim_fpu_rem, sim_fpu_max, sim_fpu_min): Likewise. 144407 * sim-fpu.h (sim_fpu_op_nan): New declaration. 144408 1444092022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com> 144410 144411 sim: Allow toggling of quiet NaN-bit semantics 144412 IEEE754-1985 specifies the top bit of the mantissa as an indicator 144413 of signalling vs. quiet NaN, but does not define the precise semantics. 144414 Most architectures treat this bit as indicating quiet NaN, but legacy 144415 (pre-R6) MIPS goes the other way and treats it as signalling NaN. 144416 144417 This used to be controlled by a macro that was only defined for MIPS. 144418 This patch replaces the macro with a variable to track the current 144419 semantics of the NaN bit and allows differentiation between older 144420 (pre-R6) and and newer MIPS cores. 144421 144422 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com> 144423 144424 sim/common/ChangeLog: 144425 * sim-fpu.c (_sim_fpu): New. 144426 (pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics. 144427 * sim-fpu.h (sim_fpu_state): New struct. 144428 (_sim_fpu): New extern. 144429 (sim_fpu_quiet_nan_inverted): New define. 144430 144431 sim/mips/ChangeLog: 144432 * cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New. 144433 * mips.igen (check_fpu): Select default quiet NaN mode 144434 for legacy MIPS. 144435 * sim-main.h (SIM_QUIET_NAN_NEGATED): Remove. 144436 1444372022-02-05 GDB Administrator <gdbadmin@sourceware.org> 144438 144439 Automatic date update in version.in 144440 1444412022-02-04 H.J. Lu <hjl.tools@gmail.com> 144442 144443 ld: Remove emultempl/armcoff.em 144444 Remove emultempl/armcoff.em which has been unused after 144445 144446 commit 2ac93be706418f3b2aebeb22159a328023faed52 144447 Author: Alan Modra <amodra@gmail.com> 144448 Date: Mon Apr 16 20:33:36 2018 +0930 144449 144450 Remove arm-aout and arm-coff support 144451 144452 This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and 144453 arm-riscix. Those targets weren't on the obsolete list but they are 144454 all aout, and it doesn't make all that much sense to remove arm-aout 144455 without removing them too. 144456 144457 * emultempl/armcoff.em: Removed. 144458 1444592022-02-04 Simon Marchi <simon.marchi@efficios.com> 144460 144461 gdb: include jit_code_entry::symfile_addr value in names of objfiles created by jit reader API 144462 This commit includes the JIT object's symfile address in the names of 144463 objfiles created by JIT reader API (e.g., << JIT compiled code at 144464 0x7ffd8a0c77a0 >>). This allows one to at least differentiate one from 144465 another. 144466 144467 The address is the one that the debugged program has put in 144468 jit_code_entry::symfile_addr, and that the JIT reader's read function 144469 receives. As we can see in gdb.base/jit-reader-host.c and 144470 gdb.base/jit-reader.c, that may not be the actual value of where the 144471 JIT-ed code is. But it is a value chosen by the author of the JIT 144472 engine and the JIT reader, so including this value in the objfile name 144473 may help them correlate the JIT objfiles created by with their logs / 144474 data structures. 144475 144476 To access this field, we need to pass down a reference to the 144477 jit_code_entry. So make jit_dbg_reader_data a structure (instead of an 144478 alias for a CORE_ADDR) that includes the address of the code entry in 144479 the inferior's address space (the previous meaning of 144480 jit_dbg_reader_data) plus a reference to the jit_code_entry as read into 144481 GDB's address space. And while at it, pass down the gdbarch, so that we 144482 don't have to call target_gdbarch. 144483 144484 Co-Authored-By: Jan Vrany <jan.vrany@labware.com> 144485 Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5 144486 1444872022-02-04 Tom Tromey <tromey@adacore.com> 144488 144489 Improve Ada unchecked union type printing 144490 Currently, "ptype" of an Ada unchecked union may show a 144491 compiler-generated wrapper structure in its output. It's more 144492 Ada-like to elide this structure, which is what this patch implements. 144493 It turned out to be simplest to reuse a part of print_variant_clauses 144494 for this. 144495 144496 As this is Ada-specific, and Joel already reviewed it internally, I am 144497 going to check it in. 144498 1444992022-02-04 Tom Tromey <tromey@adacore.com> 144500 144501 Remove host_hex_value 144502 I noticed that host_hex_value is redundant, because gdbsupport already 144503 has fromhex. This patch removes the former in favor of the latter. 144504 144505 Regression tested on x86-64 Fedora 34. 144506 1445072022-02-04 Andi Kleen <andi@firstfloor.org> 144508 144509 Support symbol+offset lookup in addr2line 144510 The Linux kernel usually ouputs symbol+offset instead of plain code 144511 addresses these days, to avoid leaking ASLR secrets and to handle 144512 dynamically loaded modules. 144513 144514 Converting those with addr2line is somewhat involved: it requires 144515 looking up the symbol first using nm and then manually compute the 144516 offset, and then pass it to addr2line. 144517 144518 This patch implements the necessary steps directly in addr2line, 144519 by looking up the symbol (with demangling if needed) and computing 144520 the offset. 144521 144522 It's possible that a symbol is ambigious with a hex number. In this 144523 case it uses the symbol lookup if the string contains a +. When it isn't 144524 ambigious the + is optional. 144525 1445262022-02-04 GDB Administrator <gdbadmin@sourceware.org> 144527 144528 Automatic date update in version.in 144529 1445302022-02-03 Cary Coutant <ccoutant@gmail.com> 144531 144532 Rename EM_56800V4 to EM_56800EF. 144533 include/elf: 144534 * common.h: Rename EM_56800V4 to EM_56800EF. 144535 1445362022-02-03 H.J. Lu <hjl.tools@gmail.com> 144537 144538 x86: Update X86_64_GOT_TYPE_P to cover more GOT relocations 144539 Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and 144540 R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations. 144541 144542 PR ld/28858 144543 * elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32, 144544 R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64. 144545 1445462022-02-03 Cary Coutant <ccoutant@gmail.com> 144547 144548 Add new e_machine values. 144549 include/elf: 144550 * common.h: Add EM_U16_U8CORE, EM_TACHYUM, EM_56800V4. 144551 1445522022-02-03 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 144553 144554 testsuite: fix failure in gdb.threads/killed-outside.exp 144555 Starting with commit 144556 144557 commit 1da5d0e664e362857153af8682321a89ebafb7f6 144558 Date: Tue Jan 4 08:02:24 2022 -0700 144559 144560 Change how Python architecture and language are handled 144561 144562 we see a failure in gdb.threads/killed-outside.exp: 144563 144564 ... 144565 Executing on target: kill -9 16622 (timeout = 300) 144566 builtin_spawn -ignore SIGHUP kill -9 16622 144567 continue 144568 Continuing. 144569 Couldn't get registers: No such process. 144570 (gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited] 144571 144572 Program terminated with signal SIGKILL, Killed. 144573 The program no longer exists. 144574 FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout) 144575 144576 This is not a regression but a failure due to a change in GDB's 144577 output. Prior to the aforementioned commit, GDB has been printing the 144578 "Couldn't get registers: No such process." message twice. The second 144579 one came from 144580 144581 (top-gdb) bt 144582 #0 amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225 144583 #1 0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502 144584 #2 0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945 144585 #3 0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587 144586 #4 0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601 144587 #5 0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690 144588 #6 0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748 144589 #7 0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53 144590 #8 0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235 144591 #9 0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580, 144592 realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143 144593 #10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199 144594 #11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972 144595 #12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007 144596 #13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948 144597 #14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572 144598 #15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602 144599 #16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665 144600 #17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890 144601 #18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720 144602 #19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810 144603 #20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848 144604 #21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") 144605 at /gdb-up/gdb/python/python.c:1063 144606 #22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922 144607 #23 0x0000555555f7d442 in std::_Function_handler<void (char const*), void (*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&) (__functor=..., 144608 __args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316 144609 #24 0x0000555555f752dd in std::function<void (char const*)>::operator()(char const*) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ") 144610 at /usr/include/c++/7/bits/std_function.h:706 144611 #25 0x0000555555f75100 in gdb::observers::observable<char const*>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ") 144612 at /gdb-up/gdb/../gdbsupport/observable.h:150 144613 #26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444 144614 #27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411 144615 #28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205 144616 #29 0x0000555555c2173f in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316 144617 #30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706 144618 #31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150 144619 #32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438 144620 #33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481 144621 #34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348 144622 #35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363 144623 #36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32 144624 144625 Commit 1da5d0e664 eliminated the call to 'get_current_arch' 144626 in 'gdbpy_before_prompt_hook'. Hence, the second instance of 144627 "Couldn't get registers: No such process." does not appear anymore. 144628 144629 Fix the failure by updating the regular expression in the test. 144630 1446312022-02-03 Alan Modra <amodra@gmail.com> 144632 144633 PowerPC64 treatment of absolute symbols 144634 Supporting -static-pie on PowerPC64 requires the linker to properly 144635 treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used 144636 absolute symbol. I've been slow to fix the linker on powerpc because 144637 there is some chance that this will break some shared libraries or 144638 PIEs. 144639 144640 bfd/ 144641 * elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym 144642 handling code. Don't count dyn relocs against non-dynamic 144643 absolute symbols. 144644 (dec_dynrel_count): Adjust to suit. 144645 (ppc64_elf_edit_toc): Don't remove entries for absolute symbols 144646 when pic. 144647 (allocate_got): Don't allocate space for got relocs against 144648 non-dynamic absolute syms. 144649 (ppc64_elf_layout_multitoc): Likewise. 144650 (got_and_plt_relr): Likewise. 144651 (ppc64_elf_size_dynamic_sections): Likewise for local got. 144652 (got_and_plt_relr_for_local_syms): Likewise. 144653 (ppc64_elf_size_stubs): Don't allocate space for relr either. 144654 (ppc64_elf_relocate_section): Don't write relocs against non-dynamic 144655 absolute symbols. Don't optimise got and toc code sequences 144656 loading absolute symbol entries. 144657 ld/ 144658 * testsuite/ld-powerpc/abs-reloc.s, 144659 * testsuite/ld-powerpc/abs-static.d, 144660 * testsuite/ld-powerpc/abs-static.r, 144661 * testsuite/ld-powerpc/abs-pie.d, 144662 * testsuite/ld-powerpc/abs-pie.r, 144663 * testsuite/ld-powerpc/abs-shared.d, 144664 * testsuite/ld-powerpc/abs-shared.r, 144665 * testsuite/ld-powerpc/abs-pie-relr.d, 144666 * testsuite/ld-powerpc/abs-pie-relr.r, 144667 * testsuite/ld-powerpc/abs-shared-relr.d, 144668 * testsuite/ld-powerpc/abs-shared-relr.r: New tests. 144669 * testsuite/ld-powerpc/powerpc.exp: Run them. 144670 1446712022-02-03 GDB Administrator <gdbadmin@sourceware.org> 144672 144673 Automatic date update in version.in 144674 1446752022-02-02 Nick Clifton <nickc@redhat.com> 144676 144677 Stop the BFD library complaining about compressed dwarf debug string sections being too big. 144678 PR 28834 144679 * dwarf2.c (read_section): Change the heuristic that checks for 144680 overlarge dwarf debug info sections. 144681 1446822022-02-02 Andrew Burgess <aburgess@redhat.com> 144683 144684 gdb: fix formatting for help set/show extended-prompt 144685 The formatting of the help text for 'help set extended-prompt' and 144686 'help show extended-prompt' is a little off. 144687 144688 Here's the offending snippet: 144689 144690 Substitutions are applied to VALUE to compute the real prompt. 144691 144692 The currently defined substitutions are: 144693 \[ Begins a sequence of non-printing characters. 144694 \\ A backslash. 144695 \] Ends a sequence of non-printing characters. 144696 \e The ESC character. 144697 144698 Notice that the line for '\[' is indented more that the others. 144699 144700 Turns out this is due to how we build this help text, something which 144701 is done in Python. We extended a classes __doc__ string with some 144702 dynamically generated text. 144703 144704 The classes doc string looks like this: 144705 144706 """Set the extended prompt. 144707 144708 Usage: set extended-prompt VALUE 144709 144710 Substitutions are applied to VALUE to compute the real prompt. 144711 144712 The currently defined substitutions are: 144713 """ 144714 144715 Notice the closing """ are in a line of their own, and include some 144716 white space just before. It's this extra white space that's causing 144717 the problem. 144718 144719 Fix the formatting issue by moving the """ to the end of the previous 144720 line. I then add the extra newline in at the point where the doc 144721 string is merged with the dynamically generated text. 144722 144723 Now everything lines up correctly. 144724 1447252022-02-02 Andrew Burgess <aburgess@redhat.com> 144726 144727 gdb: test to check one aspect of the linespec parsing code 144728 While working on the fix for PR cli/28665 (see previous couple of 144729 commits), I was playing with making a change in the linespec parsing 144730 code. Specifically, I was thinking about whether the spec_string for 144731 LINESPEC_LOCATION locations should ever be nullptr. 144732 144733 I made a change to prevent the spec_string from ever being nullptr, 144734 tested gdb, and saw no regressions. 144735 144736 However, as part of this work I was reviewing how the breakpoint code 144737 handles this case (spec_string being nullptr), and spotted that in 144738 parse_breakpoint_sals the nullptr case is specifically handled, so 144739 changing this should have caused a regression. But I didn't see one. 144740 144741 So, this commit adds a comment in location.c mentioning that the 144742 nullptr case is (a) not an oversight, and (b) is required. Then I add 144743 a new test to gdb.base/break.exp that ensures a change in this area 144744 will cause a regression. 144745 144746 This test passes on current gdb, but with my modified (and broken) 144747 gdb, the test would fail. 144748 1447492022-02-02 Andrew Burgess <aburgess@redhat.com> 144750 144751 gdb: handle calls to edit command passing only a linespec condition 144752 While working on the previous commit to fix PR cli/28665, I noticed 144753 that the 'edit' command would suffer from the same problem. That is, 144754 something like: 144755 144756 (gdb) edit task 123 144757 144758 would cause GDB to break. For a full explanation of what's going on 144759 here, see the commit message for the previous commit. 144760 144761 As with the previous commit, this issue can be prevented by detecting, 144762 and throwing, a junk at the end of the line error earlier, before 144763 calling decode_line_1. 144764 144765 So, that's what this commit does. I've also added some tests for this 144766 issue. 144767 144768 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 144769 1447702022-02-02 Andrew Burgess <aburgess@redhat.com> 144771 144772 gdb: handle calls to list command passing only a linespec condition 144773 In PR cli/28665, it was reported that GDB would crash when given a 144774 command like: 144775 144776 (gdb) list task 123 144777 144778 The problem here is that in cli/cli-cmd.c:list_command, the string 144779 'task 123' is passed to string_to_event_location in find a location 144780 specification. However, this location parsing understands about 144781 breakpoint conditions, and so, will stop parsing when it sees 144782 something that looks like a condition, in this case, the 'task 123' 144783 looks like a breakpoint condition. 144784 144785 As a result, the location we get back from string_to_event_location 144786 has no actual location specification attached to it. The actual call 144787 path is: 144788 144789 list_command 144790 string_to_event_location 144791 string_to_event_location_basic 144792 new_linespec_location 144793 144794 In new_linespec_location we call linespec_lex_to_end, which looks at 144795 'task 123' and decides that there's nothing there that describes a 144796 location. As such, in new_linespec_location, the spec_string field of 144797 the location is left as nullptr. 144798 144799 Back in list_command we then call decode_line_1, which calls 144800 event_location_to_sals, which calls parse_linespec, which takes the 144801 spec_string we found earlier, and tries to converts this into a list 144802 of sals. 144803 144804 However, parse_linespec is not intended to be passed a nullptr, for 144805 example, calling is_ada_operator will try to access through the 144806 nullptr, causing undefined behaviour. But there are other cases 144807 within parse_linespec which don't expect to see a nullptr. 144808 144809 When looking at how to fix this issue, I first considered having 144810 linespec_lex_to_end detect the problem. That function understands 144811 when the first thing in the linespec is a condition keyword, and so, 144812 could throw an error saying something like: "no linespec before 144813 condition keyword", however, this is not going to work, at least, not 144814 without additional changes to GDB, it is valid to place a breakpoint 144815 like: 144816 144817 (gdb) break task 123 144818 144819 This will place a breakpoint at the current location with the 144820 condition 'task 123', and changing linespec_lex_to_end breaks this 144821 behaviour. 144822 144823 So, next, I considered what would happen if I added a condition to an 144824 otherwise valid list command, this is what I see: 144825 144826 (gdb) list file.c:1 task 123 144827 Junk at end of line specification. 144828 (gdb) 144829 144830 So, then I wondered, could we just pull the "Junk" detection forward, 144831 so that we throw the error earlier, before we call decode_line_1? 144832 144833 It turns out that yes we can. Well, sort of. 144834 144835 It is simpler, I think, to add a separate check into the list_command 144836 function, after calling string_to_event_location, but before calling 144837 decode_line_1. We know when we call string_to_event_location that the 144838 string in question is not empty, so, after calling 144839 string_to_event_location, if non of the string has been consumed, then 144840 the content of the string must be junk - it clearly doesn't look like 144841 a location specification. 144842 144843 I've reused the same "Junk at end of line specification." error for 144844 consistency, and added a few tests to cover this issue. 144845 144846 While the first version of this patch was on the mailing list, a 144847 second bug PR gdb/28797 was raised. This was for a very similar 144848 issue, but this time the problem command was: 144849 144850 (gdb) list ,, 144851 144852 Here the list command understands about the first comma, list can have 144853 two arguments separated by a comma, and the first argument can be 144854 missing. So we end up trying to parse the second command "," as a 144855 linespec. 144856 144857 However, in linespec_lex_to_end, we will stop parsing a linespec at a 144858 comma, so, in the above case we end up with an empty linespec (between 144859 the two commas), and, like above, this results in the spec_string 144860 being nullptr. 144861 144862 As with the previous case, I've resolved this issue by adding an extra 144863 check for junk at the end of the line - after parsing (or failing to 144864 parse) the nothing between the two commas, we still have the "," left 144865 at the end of the list command line - when we see this we can throw 144866 the same "junk at the end of the line" error, and all is good. 144867 144868 I've added tests for this case too. 144869 144870 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 144871 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797 144872 1448732022-02-02 Andrew Burgess <aburgess@redhat.com> 144874 144875 gdb/testsuite: move linespec test into gdb.linespec/ directory 144876 The gdb.base/linespecs.exp test should really live in the gdb.linespec 144877 directory, so lets move it there. 144878 144879 As we already have gdb.linespec/linespec.exp, I've renamed the test to 144880 gdb.linespec/errors.exp, as this better reflects what the test is 144881 actually checking. 144882 144883 Finally, the test script doesn't have its own source file, it was 144884 reusing a random other source file, gdb.base/memattr.c. Now the tests 144885 script is in gdb.linespec/, I've updated the test to use a different 144886 source file from that directory. 144887 1448882022-02-02 Andrew Burgess <aburgess@redhat.com> 144889 144890 gdb: add empty string check in parse_linespec 144891 If parse_linespec (linespec.c) is passed ARG as an empty string then 144892 we end up calling `strchr (linespec_quote_characters, '\0')`, which 144893 will return a pointer to the '\0' at the end of 144894 linespec_quote_characters. This then results in GDB calling 144895 skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG 144896 only contained a single character, the '\0'). 144897 144898 Fix this by checking for the first character of ARG being '\0' before 144899 the call to strchr. 144900 144901 I have additionally added an assertion that ARG can't itself be 144902 nullptr, as calling is_ada_operator with nullptr can end up calling 144903 'startswith' on the nullptr, which is undefined behaviour. 144904 144905 Finally, I moved the declaration of TOKEN into the body of 144906 parse_linespec, to where TOKEN is defined. 144907 144908 This patch came about while I was working on fixes for PR cli/28665 144909 and PR gdb/28797. The actual fixes for these two issues will be in a 144910 later commit in this series, but, with this patch in place, both of 144911 the above bugs would hit the new assertion rather than accessing 144912 invalid memory and crashing. The '\0' check is not currently ever 144913 hit, but just makes the code a little safer. 144914 144915 Because this patch only changes the nature of the failure for the 144916 above two bugs, there's no tests here. A later commit will fix the 144917 above two issues, at which point I'll add some tests. 144918 144919 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 144920 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797 144921 1449222022-02-02 Andrew Burgess <aburgess@redhat.com> 144923 144924 gdb: update the comment on string_to_event_location 144925 The comment on string_to_event_location is (I believe) out of date. 144926 This commit fixes the two issues I see: 144927 144928 1. This function can't return NULL any more. The implementation 144929 calls string_to_explicit_location which can return NULL, but if this 144930 is the case we then call string_to_event_location_basic, which I 144931 don't believe can ever return NULL. 144932 144933 2. I've removed the mention that the returned string is malloc'd, 144934 though this is true, now that we return a managed pointer, I believe 144935 the source of the memory allocation is irrelevant, and so, shouldn't 144936 be discussed in the header comment. 144937 144938 There should be no user visible changes after this commit. 144939 1449402022-02-02 Nick Clifton <nickc@redhat.com> 144941 144942 Updated French translation for the ld/ and gold/ sub-directories 144943 1449442022-02-02 Stafford Horne <shorne@gmail.com> 144945 144946 or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto 144947 Previously when fixing PR 21464 we masked out upper bits of the 144948 relocation value in order to avoid overflow complaints when acceptable. 144949 It turns out this does not work when the relocation value ends up being 144950 signed. 144951 144952 To fix this this patch introduces a special howto with 144953 complain_on_overflow set to complain_overflow_dont. This is used in 144954 place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16 144955 relocations. 144956 144957 bfd/ChangeLog: 144958 144959 PR 28735 144960 * elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define. 144961 (or1k_elf_relocate_section): Use new howto instead of trying to 144962 mask out relocation bits. 144963 1449642022-02-02 GDB Administrator <gdbadmin@sourceware.org> 144965 144966 Automatic date update in version.in 144967 1449682022-02-01 Tom Tromey <tromey@adacore.com> 144969 144970 Fix flex rule in gdb 144971 Currently, if flex fails, it will leave the resulting .c file in the 144972 tree. This will cause a cascade of errors, and requires the manual 144973 deletion of the .c file in order to recreate the problem. 144974 144975 It's better for the rule to fail such that the .c file is not updated. 144976 This way, 'make' will fail the same way every time -- which is much 144977 handier for debugging syntax errors. 144978 144979 This fix just updates the Makefile rule to follow the way that the 144980 "yacc" rule already works. 144981 1449822022-02-01 Markus Metzger <markus.t.metzger@intel.com> 144983 144984 gdb, btrace: improve error messages 144985 When trying to use 'record btrace' on a system that does not support it, 144986 the error message isn't as clear as it could be. See 144987 https://sourceware.org/pipermail/gdb/2022-January/049870.html. 144988 144989 Improve the error message in a few cases. 144990 144991 Reported-by: Simon Sobisch <simonsobisch@gnu.org> 144992 1449932022-02-01 Jan Vrany <jan.vrany@labware.com> 144994 144995 gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code 144996 While experimenting with JIT reader API I realized that calling repr () 144997 on objfile created by JIT reader crashes GDB. 144998 144999 The problem was that objfpy_repr () called objfile_filename () which 145000 returned NULL, causing PyString_FromFormat () to crash. 145001 145002 This commit fixes this problem by using objfile_name () instead of 145003 objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable. 145004 1450052022-02-01 Samuel Thibault <samuel.thibault@gnu.org> 145006 145007 hurd: Fix RPC prototypes 145008 The last updates of MIG introduced qualifying strings and arrays with 145009 const as appropriate. We thus have to update the protypes in gdb too. 145010 145011 Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df 145012 1450132022-02-01 Samuel Thibault <samuel.thibault@gnu.org> 145014 145015 hurd: Fix RPC link names 145016 The RPC stub code expects to be calling a C function, not a C++ 145017 function. 145018 145019 Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f 145020 1450212022-02-01 GDB Administrator <gdbadmin@sourceware.org> 145022 145023 Automatic date update in version.in 145024 1450252022-01-31 H.J. Lu <hjl.tools@gmail.com> 145026 145027 elf: Check symbol version without any symbols 145028 VER_FLG_WEAK doesn't indicate that all symbol references of the symbol 145029 version have STB_WEAK. VER_FLG_WEAK indicates a weak symbol version 145030 definition with no symbols associated with it. It is used to verify 145031 the existence of a particular implementation without any symbol references 145032 to the weak symbol version. 145033 145034 PR ld/24718 145035 * testsuite/ld-elf/pr24718-1.d: New file. 145036 * testsuite/ld-elf/pr24718-1.s: Likewise. 145037 * testsuite/ld-elf/pr24718-1.t: Likewise. 145038 1450392022-01-31 H.J. Lu <hjl.tools@gmail.com> 145040 145041 Load debug section only when dumping debug sections 145042 Don't load debug sections if we aren't dumping any debug sections. 145043 145044 PR binutils/28843 145045 * objdump.c (dump_any_debugging): New. 145046 (load_debug_section): Return false if dump_any_debugging isn't 145047 set. 145048 (main): Set dump_any_debugging when dumping any debug sections. 145049 * readelf (dump_any_debugging): New. 145050 (parse_args): Set dump_any_debugging when dumping any debug 145051 sections. 145052 (load_debug_section): Return false if dump_any_debugging isn't 145053 set. 145054 1450552022-01-31 Simon Marchi <simon.marchi@efficios.com> 145056 145057 gdb: fix some clang-tidy readability-misleading-indentation warnings 145058 I have warnings like these showing in my editor all the time, so I 145059 thought I'd run clang-tidy with this diagnostic on all the files (that I 145060 can compile) and fix them. 145061 145062 There is still one warning, in utils.c, but that's because some code 145063 is mixed up with preprocessor macros (#ifdef TUI), so I think there no 145064 good solution there. 145065 145066 Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b 145067 1450682022-01-31 Nils-Christian Kempke <nils-christian.kempke@intel.com> 145069 145070 gdb, testsuite, fortran: adapt info symbol expected output for intel compilers 145071 Info symbol is expected to print the symbol table name of a symbol, since 145072 symbol lookup happens via the minimal symbol table. This name 145073 corresponds to the linkage name in the full symbol table. 145074 145075 For gfortran (and maybe others) these names currently have the form 145076 XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler 145077 generated appendix for mangling. 145078 An example taken from the modified nested-funcs-2.exp would be 145079 145080 ~~~~ 145081 $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \ 145082 increment 145083 00000000000014ab l F .text 0000000000000095 increment.3883 145084 000000000000141c l F .text 000000000000008f increment_program_global.3881 145085 ~~~~ 145086 145087 This mangled name gets recognized by the Ada demangler/decoder and decoded as 145088 Ada to XXXX (setting the symbol language to Ada). This leads to output 145089 of XXXX over XXXX.NUMBER for info symbol on gfortran symbols. 145090 145091 For ifort and ifx the generated linkage names have the form 145092 SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any 145093 other demangler for that matter) and thus printed as is. 145094 The respective objdump in the above case looks like 145095 145096 ~~~~ 145097 $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \ 145098 increment 145099 0000000000403a44 l F .text 0000000000000074 contains_keyword_IP_increment_ 145100 0000000000403ab8 l F .text 0000000000000070 145101 contains_keyword_IP_increment_program_global_ 145102 ~~~~ 145103 145104 In the unmodified testcase this results in 'fails' when ran with the intel 145105 compilers: 145106 145107 ~~~~ 145108 >> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \ 145109 GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'" 145110 145111 ... 145112 145113 === gdb Summary === 145114 145115 \# of expected passes 80 145116 \# of unexpected failures 14 145117 ~~~~ 145118 145119 Note that there is no Fortran mangling standard. We keep the gfortran 145120 behavior as is and modify the test to reflect ifx and ifort mangled 145121 names which fixes above fails. 145122 1451232022-01-31 Nick Clifton <nickc@redhat.com> 145124 145125 Import patch from mainline GCC to fix an infinite recusion in the Rust demangler. 145126 PR 98886 145127 PR 99935 145128 * rust-demangle.c (struct rust_demangler): Add a recursion 145129 counter. 145130 (demangle_path): Increment/decrement the recursion counter upon 145131 entry and exit. Fail if the counter exceeds a fixed limit. 145132 (demangle_type): Likewise. 145133 (rust_demangle_callback): Initialise the recursion counter, 145134 disabling if requested by the option flags. 145135 1451362022-01-31 Alan Modra <amodra@gmail.com> 145137 145138 Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu 145139 In trying to find a testcase for PR28827, I managed to hit a linker 145140 error in bfd_set_section_contents with a .branch_lt input section 145141 being too large for the output .branch_lt. 145142 145143 bfd/ 145144 PR 28827 145145 * elf64-ppc.c (ppc64_elf_size_stubs): Set section size to 145146 maxsize past STUB_SHRINK_ITER before laying out. Remove now 145147 unnecessary conditional setting of maxsize at start of loop. 145148 ld/ 145149 * testsuite/ld-powerpc/pr28827-2.d, 145150 * testsuite/ld-powerpc/pr28827-2.lnk, 145151 * testsuite/ld-powerpc/pr28827-2.s: New test. 145152 * testsuite/ld-powerpc/powerpc.exp: Run it. 145153 1451542022-01-31 Tom Tromey <tom@tromey.com> 145155 145156 Remove unused variables in fbsd-tdep.c files 145157 i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64 145158 Fedora 34 machine, using the system gcc, after a recent patch. These 145159 two files now have unused variables, which provokes a warning in this 145160 configuration. 145161 145162 I'm checking in this patch to remove the unused variables. 145163 1451642022-01-31 GDB Administrator <gdbadmin@sourceware.org> 145165 145166 Automatic date update in version.in 145167 1451682022-01-30 GDB Administrator <gdbadmin@sourceware.org> 145169 145170 Automatic date update in version.in 145171 1451722022-01-29 Alan Modra <amodra@gmail.com> 145173 145174 Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu 145175 The previous patch wasn't quite correct. The size and padding depends 145176 on offset used in the current iteration, and if we're fudging the 145177 offset past STUB_SHRINK_ITER then we'd better use that offset. We 145178 can't have plt_stub_pad using stub_sec->size as the offset. 145179 145180 PR 28827 145181 * elf64-ppc.c (plt_stub_pad): Add stub_off param. 145182 (ppc_size_one_stub): Set up stub_offset to value used in this 145183 iteration before sizing the stub. Adjust plt_stub_pad calls. 145184 1451852022-01-29 Alan Modra <amodra@gmail.com> 145186 145187 objcopy --only-keep-debug 145188 From: Peilin Ye <peilin.ye@bytedance.com> 145189 objcopy's --only-keep-debug option has been broken for ELF files since 145190 commit 8c803a2dd7d3. 145191 145192 1. binutils/objcopy.c:setup_section() marks non-debug sections as 145193 SHT_NOBITS, then calls bfd_copy_private_section_data(); 145194 2. If ISEC and OSEC share the same section flags, 145195 bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's 145196 section type back to ISEC's section type, effectively undoing 145197 "make_nobits". 145198 145199 * objcopy.c (setup_section): Act on make_nobits after calling 145200 bfd_copy_private_section_data. 145201 1452022022-01-29 GDB Administrator <gdbadmin@sourceware.org> 145203 145204 Automatic date update in version.in 145205 1452062022-01-28 John Baldwin <jhb@FreeBSD.org> 145207 145208 gdb: fix ppc-sysv-tdep.c build on 32-bit platforms 145209 The previous code triggered the following error on an i386 host: 145210 145211 /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing] 145212 unscaled.read ({writebuf, TYPE_LENGTH (valtype)}, 145213 ^~~~~~~~~~~~~~~~~~~~~ 145214 /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH' 145215 ^~~~~~~~~~~~~~~~~~ 145216 /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue 145217 unscaled.read ({writebuf, TYPE_LENGTH (valtype)}, 145218 ^~~~~~~~~~~~~~~~~~~~~ 145219 static_cast<size_t>( ) 145220 /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH' 145221 ^~~~~~~~~~~~~~~~~~ 145222 1 error generated. 145223 145224 Fix this by using gdb::make_array_view. 145225 1452262022-01-28 John Baldwin <jhb@FreeBSD.org> 145227 145228 FreeBSD x86 nat: Use register maps for GP register sets. 145229 Rather than using the x86-specific register offset tables, use 145230 register maps to describe the layout of the general purpose registers 145231 fetched via PT_GETREGS. The sole user-visible difference is that 145232 FreeBSD/amd64 will now report additional segment registers ($ds, $es, 145233 $fs, and $gs) for both 32-bit and 64-bit processes. 145234 145235 As part of these changes, the FreeBSD x86 native targets no longer use 145236 amd64-bsd-nat.c or i386-bsd-nat.c. Remove FreeBSD-specific register 145237 handling (for $fs_base, $gs_base, and XSAVE state) from these files. 145238 Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c. The 145239 FreeBSD x86 native targets use a static xsave_len instead. 145240 145241 While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386. 145242 Probe the ptrace op once in the target read_description method and 145243 cache the result for the future similar to the way the status of XSAVE 145244 support is probed in the read_description method. In addition, return 145245 the proper xcr0 mask (X87-only) for old kernels or systems without 145246 either XSAVE or XMM support. 145247 1452482022-01-28 John Baldwin <jhb@FreeBSD.org> 145249 145250 fbsd-nat: Return a bool from fetch_register_set and store_register_set. 145251 Change these helper functions to return true if they did any work. 145252 1452532022-01-28 John Baldwin <jhb@FreeBSD.org> 145254 145255 FreeBSD x86: Use tramp-frame for signal frames. 145256 Use a register map to describe the registers in mcontext_t as part of 145257 the signal frame as is done on several other FreeBSD arches. This 145258 permits fetching the fsbase and gsbase register values from the signal 145259 frame for both amd64 and i386 and permits fetching additional segment 145260 registers stored as 16-bit values on amd64. 145261 145262 While signal frames on FreeBSD do contain floating point/XSAVE state, 145263 these unwinders do not attempt to supply those registers. The 145264 existing x86 signal frame uwinders do not support these registers, and 145265 the only existing functions which handle FSAVE/FXSAVE/XSAVE state all 145266 work with regcaches. In the future these unwinders could create a 145267 tempory regcache, collect floating point registers, and then supply 145268 values out of the regcache into the trad-frame. 145269 1452702022-01-28 John Baldwin <jhb@FreeBSD.org> 145271 145272 Use register maps for gp regsets on FreeBSD/x86 core dumps. 145273 In particular, this permits reporting the value of the $ds, $es, $fs, 145274 and $gs segment registers from amd64 core dumps since they are stored 145275 as 16-bit values rather than the 32-bit size assumed by i386_gregset. 145276 1452772022-01-28 John Baldwin <jhb@FreeBSD.org> 145278 145279 regcache: Zero-extend small registers described by a register map. 145280 When registers are supplied via regcache_supply_register from a 145281 register block described by a register map, registers may be stored in 145282 slots smaller than GDB's native register size (e.g. x86 segment 145283 registers are 16 bits, but the GDB registers for those are 32-bits). 145284 regcache_collect_regset is careful to zero-extend slots larger than a 145285 register size, but regcache_supply_regset just used 145286 regcache::raw_supply_part and did not initialize the upper bytes of a 145287 register value. 145288 145289 trad_frame_set_reg_regmap assumes these semantics (zero-extending 145290 short registers). Upcoming patches also require these semantics for 145291 handling x86 segment register values stored in 16-bit slots on 145292 FreeBSD. Note that architecturally x86 segment registers are 16 bits, 145293 but the x86 gdb architectures treat these registers as 32 bits. 145294 1452952022-01-28 John Baldwin <jhb@FreeBSD.org> 145296 145297 FreeBSD x86: Remove fallback for detecting signal trampolines by address. 145298 A few FreeBSD releases did not include the page holding the signal 145299 code in core dumps. As a workaround, a sysctl was used to fetch the 145300 default location of the signal code instead. The youngest affected 145301 FreeBSD release is 10.1 released in November 2014 and EOLed in 145302 December 2016. The fallback only works for native processes and would 145303 require a separate unwinder once the FreeBSD arches are converted to 145304 use tramp_frame for signal frames. 145305 145306 Remove support for pre-5.0 FreeBSD/i386 signal trampolines. 145307 The last relevant release (FreeBSD 4.11) was released in January of 145308 2005. 145309 145310 Remove vestigal FreeBSD/i386 3.x support. 145311 This was orphaned when a.out support was removed as the FreeBSD/i386 145312 ELF support always used the register layouts from 4.0+. 145313 1453142022-01-28 Bruno Larsen <blarsen@redhat.com> 145315 145316 Add Bruno Larsen to gdb/MAINTAINERS 145317 1453182022-01-28 Enze Li <lienze2010@hotmail.com> 145319 145320 gdb/build: Fix Wpessimizing-move in clang build 145321 When building with clang, I run into an error: 145322 145323 ... 145324 tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy 145325 elision [-Werror,-Wpessimizing-move] 145326 tal.addr_string = std::move (gdb_dis_out.release ()); 145327 ^ 145328 tui/tui-disasm.c:138:25: note: remove std::move call here 145329 tal.addr_string = std::move (gdb_dis_out.release ()); 145330 ^~~~~~~~~~~ ~ 145331 ... 145332 145333 The error above is caused by the recent commit 5d10a2041eb8 ("gdb: add 145334 string_file::release method"). 145335 145336 Fix this by removing std::move. 145337 145338 Build on x86_64-linux with clang 13.0.0. 145339 1453402022-01-28 Simon Marchi <simon.marchi@polymtl.ca> 145341 145342 Add top-level .editorconfig file 145343 Add a .editorconfig [1] file. This helps configure editors 145344 automatically with the right whitespace settings. It will help me, 145345 since I need to juggle with different whitespace settings for different 145346 projects. But I think it can also help newcomers get things right from 145347 the start. 145348 145349 Some editors have native support for reading these files, while others 145350 require a plug-in [2]. And if you don't want to use it, then this file 145351 doesn't change anything to your life. 145352 145353 I added rules for the kinds of files I edit most often, but more can be 145354 added later. I assumed that the rules were the same for GDB and the 145355 other projects, but if that's not the case, we can always put 145356 .editorconfig files in project subdirectories to override settings. 145357 145358 [1] https://editorconfig.org/ 145359 [2] https://editorconfig.org/#download 145360 145361 Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b 145362 1453632022-01-28 Nick Clifton <nickc@redhat.com> 145364 145365 Updated French translation for the gas sub-directory. 145366 1453672022-01-28 Alan Modra <amodra@gmail.com> 145368 145369 Set __ehdr_start rel_from_abs earlier 145370 This is just a tidy, making the __ehdr_start symbol flag tweaks all in 145371 one place. 145372 145373 * ldelf.c (ldelf_before_allocation): Don't set rel_from_abs 145374 for __ehdr_start. 145375 * ldlang.c (lang_symbol_tweaks): Set it here instead. 145376 1453772022-01-28 Alan Modra <amodra@gmail.com> 145378 145379 PowerPC64 handling of @tocbase 145380 * elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol 145381 on R_PPC64_TOC isn't local. 145382 1453832022-01-28 Alan Modra <amodra@gmail.com> 145384 145385 Update PowerPC64 symtocbase test 145386 Using a symbol other than .TOC. with @tocbase is an extension to the 145387 ABI. It is never valid to use a symbol without a definition in the 145388 binary, and symbols on these expressions cannot be overridden. Make 145389 this explicit by using ".hidden" in the testcase. 145390 145391 * testsuite/ld-powerpc/symtocbase-1.s: Align data. Make function 145392 entry symbol hidden. 145393 * testsuite/ld-powerpc/symtocbase-2.s: Likewise. 145394 * testsuite/ld-powerpc/symtocbase.d: Adjust expected output. 145395 1453962022-01-28 Alan Modra <amodra@gmail.com> 145397 145398 PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu 145399 The assertion is this one in ppc_build_one_stub 145400 BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size); 145401 It is checking that a stub doesn't overwrite the tail of a previous 145402 stub, so not something trivial. 145403 145404 Normally, stub sizing iterates until no stubs are added, detected by 145405 no change in stub section size. Iteration also continues if no stubs 145406 are added but one or more stubs increases in size, which also can be 145407 detected by a change in stub section size. But there is a 145408 pathological case where stub section sizing decreases one iteration 145409 then increases the next. To handle that situation, stub sizing also 145410 stops at more than STUB_SHRINK_ITER (20) iterations when calculated 145411 stub section size is smaller. The previous larger size is kept for 145412 the actual layout (so that building the stubs, which behaves like 145413 another iteration of stub sizing, will see the stub section sizes 145414 shrink). The problem with that stopping condition is that it assumes 145415 that stub sizing is only affected by addresses external to the stub 145416 sections, which isn't always true. 145417 145418 This patch fixes that by also keeping larger individual stub_offset 145419 addresses past STUB_SHRINK_ITER. It also catches a further 145420 pathological case where one stub shrinks and another expands in such a 145421 way that no stub section size change is seen. 145422 145423 PR 28827 145424 * elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed. 145425 (STUB_SHRINK_ITER): Move earlier in file. 145426 (ppc_size_one_stub): Detect any change in stub_offset. Keep 145427 larger one if past STUB_SHRINK_ITER. 145428 (ppc64_elf_size_stubs): Iterate on stub_changed too. 145429 1454302022-01-28 Alan Modra <amodra@gmail.com> 145431 145432 PR28826 x86_64 ld segfaults building xen 145433 Fallout from commit e86fc4a5bc37 145434 145435 PR 28826 145436 * coffgen.c (coff_write_alien_symbol): Init dummy to zeros. 145437 1454382022-01-28 Alan Modra <amodra@gmail.com> 145439 145440 PR28753, buffer overflow in read_section_stabs_debugging_info 145441 PR 28753 145442 * rddbg.c (read_section_stabs_debugging_info): Don't read past 145443 end of section when concatentating stab strings. 145444 1454452022-01-28 GDB Administrator <gdbadmin@sourceware.org> 145446 145447 Automatic date update in version.in 145448 1454492022-01-27 Simon Marchi <simon.marchi@polymtl.ca> 145450 145451 gdb: work around negative DW_AT_data_member_location GCC 11 bug 145452 g++ 11.1.0 has a bug where it will emit a negative 145453 DW_AT_data_member_location in some cases: 145454 145455 $ cat test.cpp 145456 #include <memory> 145457 145458 int 145459 main() 145460 { 145461 std::unique_ptr<int> ptr; 145462 } 145463 $ g++ -g test.cpp 145464 $ llvm-dwarfdump -F a.out 145465 ... 145466 0x00000964: DW_TAG_member 145467 DW_AT_name [DW_FORM_strp] ("_M_head_impl") 145468 DW_AT_decl_file [DW_FORM_data1] ("/usr/include/c++/11.1.0/tuple") 145469 DW_AT_decl_line [DW_FORM_data1] (125) 145470 DW_AT_decl_column [DW_FORM_data1] (0x27) 145471 DW_AT_type [DW_FORM_ref4] (0x0000067a "default_delete<int>") 145472 DW_AT_data_member_location [DW_FORM_sdata] (-1) 145473 ... 145474 145475 This leads to a GDB crash (when built with ASan, otherwise probably 145476 garbage results), since it tries to read just before (to the left, in 145477 ASan speak) of the value's buffer: 145478 145479 ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18 145480 READ of size 1 at 0x6020000c52af thread T0 145481 #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 145482 #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347 145483 #2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126 145484 #3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333 145485 #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145486 #5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145487 #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145488 #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145489 #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145490 #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145491 #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145492 #11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145493 #12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145494 #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145495 #14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 145496 #15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 145497 #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145498 #17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145499 #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145500 #19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145501 #20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145502 #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145503 #22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 145504 #23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 145505 #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145506 #25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145507 #26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145508 #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145509 #28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 145510 #29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587 145511 #30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614 145512 #31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189 145513 #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337 145514 #33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258 145515 #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367 145516 #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458 145517 #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97 145518 #37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475 145519 #38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670 145520 #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523 145521 #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618 145522 #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317 145523 #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338 145524 #43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363 145525 #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32 145526 #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) 145527 #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d) 145528 145529 0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8) 145530 allocated by thread T0 here: 145531 #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 145532 #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100 145533 #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29 145534 #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029 145535 #4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040 145536 #5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092 145537 #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501 145538 #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145539 #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145540 #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145541 #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145542 #11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145543 #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145544 #13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145545 #14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145546 #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145547 #16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 145548 #17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 145549 #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 145550 #19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 145551 #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145552 #21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145553 #22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145554 #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145555 #24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 145556 #25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 145557 #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 145558 #27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 145559 #28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 145560 #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 145561 145562 Since there are some binaries with this in the wild, I think it would be 145563 useful for GDB to work around this. I did the obvious simple thing, if 145564 the DW_AT_data_member_location's value is -1, replace it with 0. I 145565 added a producer check to only apply this fixup for GCC 11. The idea is 145566 that if some other compiler ever uses a DW_AT_data_member_location value 145567 of -1 by mistake, we don't know (before analyzing the bug at least) if 145568 they did mean 0 or some other value. So I wouldn't want to apply the 145569 fixup in that case. 145570 145571 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063 145572 Change-Id: Ieef3459b0b9bbce8bdad838ba83b4b64e7269d42 145573 1455742022-01-27 Kevin Buettner <kevinb@redhat.com> 145575 145576 Fix GDB internal error by using text (instead of data) section offset 145577 Fedora Rawhide is now using gcc-12.0. As part of updating to the 145578 gcc-12.0 package set, Rawhide is also now using a version of libgcc_s 145579 which lacks a .data section. This causes gdb to fail in the following 145580 fashion while debugging a program (such as gdb) which uses libgcc_s: 145581 145582 (top-gdb) run 145583 Starting program: rawhide-master/bld/gdb/gdb 145584 ... 145585 objfiles.h:467: internal-error: sect_index_data not initialized 145586 A problem internal to GDB has been detected, 145587 further debugging may prove unreliable. 145588 ... 145589 145590 I snipped the backtrace from the above output. Instead, here's a 145591 portion of a backtrace obtained using GDB's backtrace command. 145592 (Obviously, in order to obtain it, I used a GDB which has been patched 145593 with this commit.) 145594 145595 #0 internal_error ( 145596 file=0xc6a508 "gdb/objfiles.h", line=467, 145597 fmt=0xc6a4e8 "sect_index_data not initialized") 145598 at gdbsupport/errors.cc:51 145599 #1 0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0) 145600 at gdb/objfiles.h:467 145601 #2 0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0) 145602 at gdb/stap-probe.c:1333 145603 #3 0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0, 145604 objfile=0x4fa48f0) 145605 at gdb/stap-probe.c:1341 145606 #4 0x00000000004d7025 in create_exception_master_breakpoint_probe ( 145607 objfile=0x4fa48f0) 145608 at gdb/breakpoint.c:3505 145609 #5 0x00000000004d7426 in create_exception_master_breakpoint () 145610 at gdb/breakpoint.c:3575 145611 #6 0x00000000004efcc1 in breakpoint_re_set () 145612 at gdb/breakpoint.c:13407 145613 #7 0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1) 145614 at gdb/solib.c:1001 145615 #8 0x00000000009576a8 in handle_solib_event () 145616 at gdb/solib.c:1269 145617 ... 145618 145619 The function 'relocate_address' in gdb/stap-probe.c attempts to do 145620 its "relocation" by using objfile->data_section_offset(). That 145621 method, data_section_offset() is defined as follows in objfiles.h: 145622 145623 CORE_ADDR data_section_offset () const 145624 { 145625 return section_offsets[SECT_OFF_DATA (this)]; 145626 } 145627 145628 The internal error occurs when the SECT_OFF_DATA macro finds that the 145629 'sect_index_data' field is -1: 145630 145631 #define SECT_OFF_DATA(objfile) \ 145632 ((objfile->sect_index_data == -1) \ 145633 ? (internal_error (__FILE__, __LINE__, \ 145634 _("sect_index_data not initialized")), -1) \ 145635 : objfile->sect_index_data) 145636 145637 relocate_address() is obtaining the section offset in order to compute 145638 a relocated address. For some ABIs, such as the System V ABI, the 145639 section offsets will all be the same. So for those ABIs, it doesn't 145640 matter which offset is used. However, other ABIs, such as the FDPIC 145641 ABI, will have different offsets for the various sections. Thus, for 145642 those ABIs, it is vital that this and other relocation code use the 145643 correct offset. 145644 145645 In stap_probe::get_relocated_address, the address to which to add the 145646 offset (thus forming the relocated address) is obtained via 145647 this->get_address (); get_address is a getter for m_address in 145648 probe.h. It's documented/defined as follows (also in probe.h): 145649 145650 /* The address where the probe is inserted, relative to 145651 SECT_OFF_TEXT. */ 145652 CORE_ADDR m_address; 145653 145654 (Thanks to Tom Tromey for this observation.) 145655 145656 So, based on this, the current use of data_section_offset / 145657 SECT_OFF_DATA is wrong. This relocation code should have been using 145658 text_section_offset / SECT_OFF_TEXT all along. That being the 145659 case, I've adjusted the stap-probe.c relocation code accordingly. 145660 145661 Searching the sources turned up one other use of data_section_offset, 145662 in gdb/dtrace-probe.c, so I've updated that code as well. The same 145663 reasoning presented above applies to this case too. 145664 145665 Summary: 145666 145667 * gdb/dtrace-probe.c (dtrace_probe::get_relocated_address): 145668 Use method text_section_offset instead of data_section_offset. 145669 * gdb/stap-probe.c (relocate_address): Likewise. 145670 1456712022-01-27 Markus Metzger <markus.t.metzger@intel.com> 145672 145673 gdb, remote, btrace: move switch_to_thread call right before xfer call 145674 In remote_target::remote_btrace_maybe_reopen, we switch to the currently 145675 iterated thread in order to set inferior_ptid for a subsequent xfer. 145676 145677 Move the switch_to_thread call directly before the target_read_stralloc 145678 call to clarify why we need to switch threads. 145679 1456802022-01-27 Markus Metzger <markus.t.metzger@intel.com> 145681 145682 gdb, gdbserver: update thread identifier in enable_btrace target method 145683 The enable_btrace target method takes a ptid_t to identify the thread on 145684 which tracing shall be enabled. 145685 145686 Change this to thread_info * to avoid translating back and forth between 145687 the two. This will be used in a subsequent patch. 145688 1456892022-01-27 Markus Metzger <markus.t.metzger@intel.com> 145690 145691 gdb, btrace: switch threads in remote_btrace_maybe_reopen() 145692 In remote_btrace_maybe_reopen() we iterate over threads and use 145693 set_general_thread() to set the thread from which to transfer the btrace 145694 configuration. 145695 145696 This sets the remote general thread but does not affect inferior_ptid. On 145697 the xfer request later on, remote_target::xfer_partial() again sets the 145698 remote general thread to inferior_ptid, overwriting what 145699 remote_btrace_maybe_reopen() had done. 145700 145701 In one case, this led to inferior_ptid being null_ptid when we tried to 145702 enable tracing on a newly created thread inside a newly created process 145703 during attach. 145704 145705 This, in turn, led to find_inferior_pid() asserting when we iterated over 145706 threads in record_btrace_is_replaying(), which was called from 145707 record_btrace_target::xfer_partial() when reading the btrace configuration 145708 of the new thread to check whether it was already being recorded. 145709 145710 The bug was exposed by 145711 145712 0618ae41497 gdb: optimize all_matching_threads_iterator 145713 145714 and found by 145715 145716 FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error) 145717 145718 Use switch_to_thread() in remote_btrace_maybe_reopen(). 145719 1457202022-01-27 Markus Metzger <markus.t.metzger@intel.com> 145721 145722 gdb, btrace: rename record_btrace_enable_warn() 145723 We use record_btrace_enable_warn() as the new-thread observer callback. 145724 It is not used in other contexts. 145725 145726 Rename it to record_btrace_on_new_thread() to make its role more clear. 145727 1457282022-01-27 Nick Clifton <nickc@redhat.com> 145729 145730 Updated Swedish translation for the binutils subdirectory 145731 1457322022-01-27 GDB Administrator <gdbadmin@sourceware.org> 145733 145734 Automatic date update in version.in 145735 1457362022-01-26 Andrew Burgess <aburgess@redhat.com> 145737 145738 gdb/python: handle non utf-8 characters when source highlighting 145739 This commit adds support for source files that contain non utf-8 145740 characters when performing source styling using the Python pygments 145741 package. This does not change the behaviour of GDB when the GNU 145742 Source Highlight library is used. 145743 145744 For the following problem description, assume that either GDB is built 145745 without GNU Source Highlight support, of that this has been disabled 145746 using 'maintenance set gnu-source-highlight enabled off'. 145747 145748 The initial problem reported was that a source file containing non 145749 utf-8 characters would cause GDB to print a Python exception, and then 145750 display the source without styling, e.g.: 145751 145752 Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 142: invalid start byte 145753 /* Source code here, without styling... */ 145754 145755 Further, as the user steps through different source files, each time 145756 the problematic source file was evicted from the source cache, and 145757 then later reloaded, the exception would be printed again. 145758 145759 Finally, this problem is only present when using Python 3, this issue 145760 is not present for Python 2. 145761 145762 What makes this especially frustrating is that GDB can clearly print 145763 the source file contents, they're right there... If we disable 145764 styling completely, or make use of the GNU Source Highlight library, 145765 then everything is fine. So why is there an error when we try to 145766 apply styling using Python? 145767 145768 The problem is the use of PyString_FromString (which is an alias for 145769 PyUnicode_FromString in Python 3), this function converts a C string 145770 into a either a Unicode object (Py3) or a str object (Py2). For 145771 Python 2 there is no unicode encoding performed during this function 145772 call, but for Python 3 the input is assumed to be a uft-8 encoding 145773 string for the purpose of the conversion. And here of course, is the 145774 problem, if the source file contains non utf-8 characters, then it 145775 should not be treated as utf-8, but that's what we do, and that's why 145776 we get an error. 145777 145778 My first thought when looking at this was to spot when the 145779 PyString_FromString call failed with a UnicodeDecodeError and silently 145780 ignore the error. This would mean that GDB would print the source 145781 without styling, but would also avoid the annoying exception message. 145782 145783 However, I also make use of `pygmentize`, a command line wrapper 145784 around the Python pygments module, which I use to apply syntax 145785 highlighting in the output of `less`. And this command line wrapper 145786 is quite happy to syntax highlight my source file that contains non 145787 utf-8 characters, so it feels like the problem should be solvable. 145788 145789 It turns out that inside the pygments module there is already support 145790 for guessing the encoding of the incoming file content, if the 145791 incoming content is not already a Unicode string. This is what 145792 happens for Python 2 where the incoming content is of `str` type. 145793 145794 We could try and make GDB smarter when it comes to converting C 145795 strings into Python Unicode objects; this would probably require us to 145796 just try a couple of different encoding schemes rather than just 145797 giving up after utf-8. 145798 145799 However, I figure, why bother? The pygments module already does this 145800 for us, and the colorize API is not part of the documented external 145801 API of GDB. So, why not just change the colorize API, instead of the 145802 content being a Unicode string (for Python 3), lets just make the 145803 content be a bytes object. The pygments module can then take 145804 responsibility for guessing the encoding. 145805 145806 So, currently, the colorize API receives a unicode object, and returns 145807 a unicode object. I propose that the colorize API receive a bytes 145808 object, and return a bytes object. 145809 1458102022-01-26 Tom Tromey <tom@tromey.com> 145811 145812 Remove global wrap_here function 145813 This removes the global wrap_here function, so that future calls 145814 cannot be introduced. Instead, all callers must use the method on the 145815 appropriate ui_file. 145816 145817 This temporarily moves the implementation of this method to utils.c. 145818 This will change once the remaining patches to untangle the pager have 145819 been written. 145820 1458212022-01-26 Tom Tromey <tom@tromey.com> 145822 145823 Always call the wrap_here method 145824 This changes all existing calls to wrap_here to call the method on the 145825 appropriate ui_file instead. The choice of ui_file is determined by 145826 context. 145827 1458282022-01-26 Tom Tromey <tom@tromey.com> 145829 145830 Add ui_file::wrap_here 145831 Right now, wrap_here is a global function. In the long run, we'd like 145832 output streams to be relatively self-contained objects, and having a 145833 global function like this is counter to that goal. Also, existing 145834 code freely mixes writes to some parameterized stream with calls to 145835 wrap_here -- but wrap_here only really affects gdb_stdout, so this is 145836 also incoherent. 145837 145838 This step is a patch toward making wrap_here more sane. It adds a 145839 wrap_here method to ui_file and changes ui_out implementations to use 145840 it. 145841 1458422022-01-26 Tom Tromey <tom@tromey.com> 145843 145844 Convert wrap_here to use integer parameter 145845 I think it only really makes sense to call wrap_here with an argument 145846 consisting solely of spaces. Given this, it seemed better to me that 145847 the argument be an int, rather than a string. This patch is the 145848 result. Much of it was written by a script. 145849 1458502022-01-26 Andrew Burgess <aburgess@redhat.com> 145851 145852 gdb/python: improve the auto help text for gdb.Parameter 145853 This commit attempts to improve the help text that is generated for 145854 gdb.Parameter objects when the user fails to provide their own 145855 documentation. 145856 145857 Documentation for a gdb.Parameter is currently pulled from two 145858 sources: the class documentation string, and the set_doc/show_doc 145859 class attributes. Thus, a fully documented parameter might look like 145860 this: 145861 145862 class Param_All (gdb.Parameter): 145863 """This is the class documentation string.""" 145864 145865 show_doc = "Show the state of this parameter" 145866 set_doc = "Set the state of this parameter" 145867 145868 def get_set_string (self): 145869 val = "on" 145870 if (self.value == False): 145871 val = "off" 145872 return "Test Parameter has been set to " + val 145873 145874 def __init__ (self, name): 145875 super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) 145876 self._value = True 145877 145878 Param_All ('param-all') 145879 145880 Then in GDB we see this: 145881 145882 (gdb) help set param-all 145883 Set the state of this parameter 145884 This is the class documentation string. 145885 145886 Which is fine. But, if the user skips both of the documentation parts 145887 like this: 145888 145889 class Param_None (gdb.Parameter): 145890 145891 def get_set_string (self): 145892 val = "on" 145893 if (self.value == False): 145894 val = "off" 145895 return "Test Parameter has been set to " + val 145896 145897 def __init__ (self, name): 145898 super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) 145899 self._value = True 145900 145901 Param_None ('param-none') 145902 145903 Now in GDB we see this: 145904 145905 (gdb) help set param-none 145906 This command is not documented. 145907 This command is not documented. 145908 145909 That's not great, the duplicated text looks a bit weird. If we drop 145910 different parts we get different results. Here's what we get if the 145911 user drops the set_doc and show_doc attributes: 145912 145913 (gdb) help set param-doc 145914 This command is not documented. 145915 This is the class documentation string. 145916 145917 That kind of sucks, we say it's undocumented, then proceed to print 145918 the documentation. Finally, if we drop the class documentation but 145919 keep the set_doc and show_doc: 145920 145921 (gdb) help set param-set-show 145922 Set the state of this parameter 145923 This command is not documented. 145924 145925 That seems OK. 145926 145927 So, I think there's room for improvement. 145928 145929 With this patch, for the four cases above we now see this: 145930 145931 # All values provided by the user, no change in this case: 145932 (gdb) help set param-all 145933 Set the state of this parameter 145934 This is the class documentation string. 145935 145936 # Nothing provided by the user, the first string is now different: 145937 (gdb) help set param-none 145938 Set the current value of 'param-none'. 145939 This command is not documented. 145940 145941 # Only the class documentation is provided, the first string is 145942 # changed as in the previous case: 145943 (gdb) help set param-doc 145944 Set the current value of 'param-doc'. 145945 This is the class documentation string. 145946 145947 # Only the set_doc and show_doc are provided, this case is unchanged 145948 # from before the patch: 145949 (gdb) help set param-set-show 145950 Set the state of this parameter 145951 This command is not documented. 145952 145953 The one place where this change might be considered a negative is when 145954 dealing with prefix commands. If we create a prefix command but don't 145955 supply the set_doc / show_doc strings, then this is what we saw before 145956 my patch: 145957 145958 (gdb) python Param_None ('print param-none') 145959 (gdb) help set print 145960 set print, set pr, set p 145961 Generic command for setting how things print. 145962 145963 List of set print subcommands: 145964 145965 ... snip ... 145966 set print param-none -- This command is not documented. 145967 ... snip ... 145968 145969 And after my patch: 145970 145971 (gdb) python Param_None ('print param-none') 145972 (gdb) help set print 145973 set print, set pr, set p 145974 Generic command for setting how things print. 145975 145976 List of set print subcommands: 145977 145978 ... snip ... 145979 set print param-none -- Set the current value of 'print param-none'. 145980 ... snip ... 145981 145982 This seems slightly less helpful than before, but I don't think its 145983 terrible. 145984 145985 Additionally, I've changed what we print when the get_show_string 145986 method is not provided in Python. 145987 145988 Back when gdb.Parameter was first added to GDB, we didn't provide a 145989 show function when registering the internal command object within 145990 GDB. As a result, GDB would make use of its "magic" mangling of the 145991 show_doc string to create a sentence that would display the current 145992 value (see deprecated_show_value_hack in cli/cli-setshow.c). 145993 145994 However, when we added support for the get_show_string method to 145995 gdb.Parameter, there was an attempt to maintain backward compatibility 145996 by displaying the show_doc string with the current value appended, see 145997 get_show_value in py-param.c. Unfortunately, this isn't anywhere 145998 close to what deprecated_show_value_hack does, and the results are 145999 pretty poor, for example, this is GDB before my patch: 146000 146001 (gdb) show param-none 146002 This command is not documented. off 146003 146004 I think we can all agree that this is pretty bad. 146005 146006 After my patch, we how show this: 146007 146008 (gdb) show param-none 146009 The current value of 'param-none' is "off". 146010 146011 Which at least is a real sentence, even if it's not very informative. 146012 146013 This patch does change the way that the Python API behaves slightly, 146014 but only in the cases when the user has missed providing GDB with some 146015 information. In most cases I think the new behaviour is a lot better, 146016 there's the one case (noted above) which is a bit iffy, but I think is 146017 still OK. 146018 146019 I've updated the existing gdb.python/py-parameter.exp test to cover 146020 the modified behaviour. 146021 146022 Finally, I've updated the documentation to (I hope) make it clearer 146023 how the various bits of help text come together. 146024 1460252022-01-26 Andrew Burgess <aburgess@redhat.com> 146026 146027 gdb/python: add gdb.history_count function 146028 Add a new function gdb.history_count to the Python api, this function 146029 returns an integer, the number of items in GDB's value history. 146030 146031 This is useful if you want to pull items from the history by their 146032 absolute number, for example, if you wanted to show a complete history 146033 list. Previously we could figure out how many items are in the 146034 history list by trying to fetch the items, and then catching the 146035 exception when the item is not available, but having this function 146036 seems nicer. 146037 1460382022-01-26 Tom Tromey <tromey@adacore.com> 146039 146040 Remove unused declaration 146041 This removes an unused declaration from top.h. This type is not 146042 defined anywhere. 146043 1460442022-01-26 Simon Marchi <simon.marchi@efficios.com> 146045 146046 gdb: convert maintenance target-async and target-non-stop settings to callbacks 146047 This simplifies things a bit, as we don't need two variables and think 146048 about reverting target_async_permitted_1 and target_non_stop_enabled_1 146049 values if we can't change the setting. 146050 146051 Change-Id: I36acab045dacf02ae1988486cfdb27c1dff309f6 146052 1460532022-01-26 Keith Seitz <keiths@redhat.com> 146054 146055 Reference array of structs instead of first member during memcpy 146056 aarch64-tdep.c defines the following macro: 146057 146058 #define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \ 146059 do \ 146060 { \ 146061 unsigned int mem_len = LENGTH; \ 146062 if (mem_len) \ 146063 { \ 146064 MEMS = XNEWVEC (struct aarch64_mem_r, mem_len); \ 146065 memcpy(&MEMS->len, &RECORD_BUF[0], \ 146066 sizeof(struct aarch64_mem_r) * LENGTH); \ 146067 } \ 146068 } \ 146069 while (0) 146070 146071 This is simlpy allocating a new array and copying it. However, for 146072 the destination address, it is actually copying into the first member 146073 of the first element of the array (`&MEMS->len"). This elicits a 146074 warning with GCC 12: 146075 146076 ../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’: 146077 ../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=] 146078 3711 | memcpy(&MEMS->len, &RECORD_BUF[0], \ 146079 | ^ 146080 ../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’ 146081 4394 | MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count, 146082 | ^~~~~~~~~ 146083 ../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8 146084 3721 | uint64_t len; /* Record length. */ 146085 | ^~~ 146086 146087 The simple fix is to reference the array, `MEMS' as the destination of the copy. 146088 146089 Tested by rebuilding. 146090 146091 146092 # Please enter the commit message for your changes. Lines starting 146093 # with '#' will be kept; you may remove them yourself if you want to. 146094 # An empty message aborts the commit. 146095 # 146096 # Date: Tue Jan 25 08:28:32 2022 -0800 146097 # 146098 # On branch master 146099 # Your branch is ahead of 'origin/master' by 1 commit. 146100 # (use "git push" to publish your local commits) 146101 # 146102 # Changes to be committed: 146103 # modified: aarch64-tdep.c 146104 # 146105 1461062022-01-26 Simon Marchi <simon.marchi@polymtl.ca> 146107 146108 gdb: add string_file::release method 146109 A common pattern for string_file is to want to move out the internal 146110 string buffer, because it is the result of the computation that we want 146111 to return. It is the reason why string_file::string returns a non-const 146112 reference, as explained in the comment. I think it would make sense to 146113 have a dedicated method for that instead and make string_file::string 146114 return a const reference. 146115 146116 This allows removing the explicit std::move in the typical case. Note 146117 that compile_program::compute was missing a move, meaning that the 146118 resulting string was copied. With the new version, it's not possible to 146119 forget to move. 146120 146121 Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79 146122 1461232022-01-26 Tom Tromey <tromey@adacore.com> 146124 146125 Add a way to temporarily set a gdb parameter from Python 146126 It's sometimes useful to temporarily set some gdb parameter from 146127 Python. Now that the 'endian' crash is fixed, and now that the 146128 current language is no longer captured by the Python layer, it seems 146129 reasonable to add a helper function for this situation. 146130 146131 This adds a new gdb.with_parameter function. This creates a context 146132 manager which temporarily sets some parameter to a specified value. 146133 The old value is restored when the context is exited. This is most 146134 useful with the Python "with" statement: 146135 146136 with gdb.with_parameter('language', 'ada'): 146137 ... do Ada stuff 146138 146139 This also adds a simple function to set a parameter, 146140 gdb.set_parameter, as suggested by Andrew. 146141 146142 This is PR python/10790. 146143 146144 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790 146145 1461462022-01-26 Tom Tromey <tromey@adacore.com> 146147 146148 Fix another crash with gdb parameters in Python 146149 While looking into the language-capturing issue, I found another way 146150 to crash gdb using parameters from Python: 146151 146152 (gdb) python print(gdb.parameter('endian')) 146153 146154 (This is related to PR python/12188, though this patch isn't going to 146155 fix what that bug is really about.) 146156 146157 The problem here is that the global variable that underlies the 146158 "endian" parameter is initialized to NULL. However, that's not a 146159 valid value for an "enum" set/show parameter. 146160 146161 My understanding is that, in gdb, an "enum" parameter's underlying 146162 variable must have a value that is "==" (not just strcmp-equal) to one 146163 of the values coming from the enum array. This invariant is relied on 146164 in various places. 146165 146166 I started this patch by fixing the problem with "endian". Then I 146167 added some assertions to add_setshow_enum_cmd to try to catch other 146168 problems of the same type. 146169 146170 This patch fixes all the problems that I found. I also looked at all 146171 the calls to add_setshow_enum_cmd to ensure that they were all 146172 included in the gdb I tested. I think they are: there are no calls in 146173 nat-* files, or in remote-sim.c; and I was trying a build with all 146174 targets, Python, and Guile enabled. 146175 146176 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188 146177 1461782022-01-26 Tom Tromey <tromey@adacore.com> 146179 146180 Change how Python architecture and language are handled 146181 Currently, gdb's Python layer captures the current architecture and 146182 language when "entering" Python code. This has some undesirable 146183 effects, and so this series changes how this is handled. 146184 146185 First, there is code like this: 146186 146187 gdbpy_enter enter_py (python_gdbarch, python_language); 146188 146189 This is incorrect, because both of these are NULL when not otherwise 146190 assigned. This can cause crashes in some cases -- I've added one to 146191 the test suite. (Note that this crasher is just an example, other 146192 ones along the same lines are possible.) 146193 146194 Second, when the language is captured in this way, it means that 146195 Python code cannot affect the current language for its own purposes. 146196 It's reasonable to want to write code like this: 146197 146198 gdb.execute('set language mumble') 146199 ... stuff using the current language 146200 gdb.execute('set language previous-value') 146201 146202 However, this won't actually work, because the language is captured on 146203 entry. I've added a test to show this as well. 146204 146205 This patch changes gdb to try to avoid capturing the current values. 146206 The Python concept of the current gdbarch is only set in those few 146207 cases where a non-default value is computed or needed; and the 146208 language is not captured at all -- instead, in the cases where it's 146209 required, the current language is temporarily changed. 146210 1462112022-01-26 H.J. Lu <hjl.tools@gmail.com> 146212 146213 bfd: Make bfd.stamp depend on source bfd.texi 146214 Make bfd.stamp depend on source bfd.texi to avoid regenerating 146215 doc/bfd.info for each make run. 146216 146217 PR binutils/28807 146218 * Makefile.in: Regenerate. 146219 * doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi. 146220 1462212022-01-26 H.J. Lu <hjl.tools@gmail.com> 146222 146223 ld: Rewrite lang_size_relro_segment_1 146224 1. Compute the desired PT_GNU_RELRO segment base and find the maximum 146225 section alignment of sections starting from the PT_GNU_RELRO segment. 146226 2. Find the first preceding load section. 146227 3. Don't add the 1-page gap between the first preceding load section and 146228 the relro segment if the maximum page size >= the maximum section 146229 alignment. Align the PT_GNU_RELRO segment first. Subtract the maximum 146230 page size if therer is still a 1-page gap. 146231 146232 PR ld/28743 146233 PR ld/28819 146234 * ldlang.c (lang_size_relro_segment_1): Rewrite. 146235 * testsuite/ld-x86-64/pr28743-1.d: New file. 146236 * testsuite/ld-x86-64/pr28743-1.s: Likewise. 146237 * testsuite/ld-x86-64/x86-64.exp: Run pr28743-1. 146238 1462392022-01-26 Lancelot SIX <lancelot.six@amd.com> 146240 146241 gdb/testsuite: Ensure constant test name in gdb.base/break-interp.exp 146242 When running the testsuite, I have lines similar to the following in the 146243 gdb.sum file: 146244 146245 ~~~ 146246 PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1 146247 ... 146248 PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5 146249 ... 146250 ~~~ 146251 146252 The address part of the command might change between execution of the 146253 test, which adds noise to a diff between two .sum files. 146254 146255 This patch changes to test name to "p /x $pc" in order to have constant 146256 test name. 146257 146258 Tested on x86_64-Linux. 146259 146260 Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21 146261 1462622022-01-26 GDB Administrator <gdbadmin@sourceware.org> 146263 146264 Automatic date update in version.in 146265 1462662022-01-25 Tom Tromey <tom@tromey.com> 146267 146268 Always print the "host libthread-db" message to stdout 146269 linux-thread-db.c has a bit of unusual code that unconditionally 146270 prints a message, but decides whether to print to gdb_stdout or 146271 gdb_stdlog based on a debug flag. It seems better to me to simply 146272 always print this; and this is the only spot in gdb where we 146273 conditionally pass gdb_stdout to one of the f*_unfiltered functions. 146274 1462752022-01-25 Tom Tromey <tom@tromey.com> 146276 146277 Reduce explicit use of gdb_stdout 146278 In an earlier version of the pager rewrite series, it was important to 146279 audit unfiltered output calls to see which were truly necessary. 146280 146281 This is no longer necessary, but it still seems like a decent cleanup 146282 to change calls to avoid explicitly passing gdb_stdout. That is, 146283 rather than using something like fprintf_unfiltered with gdb_stdout, 146284 the code ought to use plain printf_unfiltered instead. 146285 146286 This patch makes this change. I went ahead and converted all the 146287 _filtered calls I could find, as well, for the same clarity. 146288 1462892022-01-25 Tom Tromey <tom@tromey.com> 146290 146291 Sent timing stats to gdb_stdlog 146292 This changes the time / space / symtab per-command statistics code to 146293 send its output to gdb_stdlog rather than gdb_stdout. This seems 146294 slightly more correct to me. 146295 146296 Send some error output to gdb_stderr 146297 This changes some code to send some error messages to gdb_stderr 146298 rather than gdb_stdout. 146299 1463002022-01-25 Klaus Ziegler <klausz@haus-gisela.de> 146301 146302 Fix a probem building the binutils on SPARC/amd64 146303 PR 28816 146304 * elf/common.h (AT_SUN_HWCAP): Make definition conditional. 146305 1463062022-01-25 H.J. Lu <hjl.tools@gmail.com> 146307 146308 bfd: Regenerate Makefile.in 146309 * Makefile.in: Regenerate. 146310 1463112022-01-25 Mike Frysinger <vapier@gentoo.org> 146312 146313 gold: drop old cygnus install hack 146314 The gold subdir doesn't actually have a manual, so this hack doesn't 146315 do anything. Plus the automake cygnus option was removed years ago 146316 by Simon in d0ac1c44885daf68f631befa37e ("Bump to autoconf 2.69 and 146317 automake 1.15.1"). So delete it here. 146318 146319 gas: drop old cygnus install hack 146320 This was needed when gas was using the automake cygnus option, but 146321 this was removed years ago by Simon in d0ac1c44885daf68f631befa37e 146322 ("Bump to autoconf 2.69 and automake 1.15.1"). So delete it here. 146323 The info pages are already & still installed by default w/out it. 146324 1463252022-01-25 GDB Administrator <gdbadmin@sourceware.org> 146326 146327 Automatic date update in version.in 146328 1463292022-01-24 H.J. Lu <hjl.tools@gmail.com> 146330 146331 bfd: Update doc/local.mk 146332 PR binutils/28807 146333 * Makefile.in: Regenerate. 146334 * doc/local.mk (AM_MAKEINFOFLAGS): Add -I "$(srcdir)/%D%" -I %D%. 146335 (TEXI2DVI): New. 146336 (%D%/bfd.texi): Removed. 146337 (doc/bfd/index.html): Remove -I$(srcdir). Replace bfd.texi with 146338 %D%/bfd.texi. 146339 1463402022-01-24 Roland McGrath <mcgrathr@google.com> 146341 146342 bfd/doc: Fix racy build failure from missing mkdir 146343 bfd/ 146344 * doc/local.mk (%D%/bfdver.texi): Add mkdir command. 146345 1463462022-01-24 Martin Sebor <msebor@redhat.com> 146347 146348 Fix a proble building the libiberty library with gcc-12. 146349 PR 28779 146350 * regex.c: Suppress -Wuse-after-free. 146351 1463522022-01-24 Andrew Burgess <aburgess@redhat.com> 146353 146354 gdb/doc: improve description for Window.click on Python TUI windows 146355 The description of the Window.click method doesn't mention where the 146356 coordinates are anchored (it's the top left corner). 146357 146358 This minor tweak just mentions this point. 146359 1463602022-01-24 Nick Clifton <nickc@redhat.com> 146361 146362 Update Bulgarian, French, Romaniam and Ukranian translation for some of the sub-directories 146363 1463642022-01-24 GDB Administrator <gdbadmin@sourceware.org> 146365 146366 Automatic date update in version.in 146367 1463682022-01-23 Tom Tromey <tom@tromey.com> 146369 146370 Simplify some Rust expression-evaluation code 146371 A few Rust operations do a bit of work in their 'evaluate' functions 146372 and then call another function -- but are also the only caller. This 146373 patch simplifies this code by removing the extra layer. 146374 146375 Tested on x86-64 Fedora 34. I'm checking this in. 146376 1463772022-01-23 H.J. Lu <hjl.tools@gmail.com> 146378 146379 bfd: Partially revert commit 0e3839bde6f 146380 Partially revert 146381 146382 commit 0e3839bde6f93e1e3eefce815be3636e3d81054d 146383 Author: H.J. Lu <hjl.tools@gmail.com> 146384 Date: Sun Jan 23 07:29:27 2022 -0800 146385 146386 bfd: Properly install library and header files 146387 146388 PR binutils/28807 146389 * Makefile.am: Revert bfdlib_LTLIBRARIES and bfdinclude_HEADERS 146390 changes. 146391 * Makefile.in: Regenerate. 146392 1463932022-01-23 H.J. Lu <hjl.tools@gmail.com> 146394 146395 bfd: Properly install library and header files 146396 Rename bfdlib_LTLIBRARIES and bfdinclude_HEADERS to lib_LTLIBRARIES and 146397 include_HEADERS to fix the missing installed library and header files in 146398 bfd caused by 146399 146400 commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3 146401 Author: Mike Frysinger <vapier@gentoo.org> 146402 Date: Fri Dec 3 00:23:20 2021 -0500 146403 146404 bfd: merge doc subdir up a level 146405 146406 PR binutils/28807 146407 * Makefile.am (bfdlib_LTLIBRARIES): Renamed to ... 146408 (lib_LTLIBRARIES): This. 146409 (bfdinclude_HEADERS): Renamed to ... 146410 (include_HEADERS): This. 146411 * Makefile.in: Regenerate. 146412 * doc/local.mk (install): Removed. 146413 1464142022-01-23 H.J. Lu <hjl.tools@gmail.com> 146415 146416 Regenerate Makefile.in files with automake 1.15.1 146417 Regenerate Makefile.in files with the unmodified automake 1.15.1 to 146418 remove 146419 146420 runstatedir = @runstatedir@ 146421 146422 bfd/ 146423 146424 * Makefile.in: Regenerate. 146425 146426 binutils/ 146427 146428 * Makefile.in: Regenerate. 146429 146430 gas/ 146431 146432 * Makefile.in: Regenerate. 146433 146434 gold/ 146435 146436 * Makefile.in: Regenerate. 146437 * testsuite/Makefile.in: Likewise. 146438 146439 gprof/ 146440 146441 * Makefile.in: Regenerate. 146442 146443 ld/ 146444 146445 * Makefile.in: Regenerate. 146446 146447 opcodes/ 146448 146449 * Makefile.in: Regenerate. 146450 1464512022-01-23 H.J. Lu <hjl.tools@gmail.com> 146452 146453 Regenerate configure files with autoconf 2.69 146454 Regenerate configure files with the unmodified autoconf 2.69 to remove 146455 146456 --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] 146457 146458 bfd/ 146459 146460 * configure: Regenerate. 146461 146462 binutils/ 146463 146464 * configure: Regenerate. 146465 146466 gas/ 146467 146468 * configure: Regenerate. 146469 146470 gold/ 146471 146472 * configure: Regenerate. 146473 146474 gprof/ 146475 146476 * configure: Regenerate. 146477 146478 ld/ 146479 146480 * configure: Regenerate. 146481 146482 opcodes/ 146483 146484 * configure: Regenerate. 146485 1464862022-01-23 GDB Administrator <gdbadmin@sourceware.org> 146487 146488 Automatic date update in version.in 146489 1464902022-01-22 Mike Frysinger <vapier@gentoo.org> 146491 146492 bfd: merge doc subdir up a level 146493 This avoids a recursive make into the doc subdir and speeds up the 146494 build slightly. It also allows for more parallelism. 146495 146496 bfd: rename core.texi to corefile.texi 146497 This is a generated file name from a correspondingly named C file. 146498 Rename it to avoid unique build rules since there's no difference 146499 to the generated manual. 146500 146501 bfd: replace doc header generation with pattern rules 146502 This unifies boilerplate rules for most files with pattern rules. 146503 1465042022-01-22 Martin Storsj? <martin@martin.st> 146505 146506 Allow inferring tmp_prefix from the dll name from a def file. 146507 1465082022-01-22 Alexander von Gluck IV <kallisti5@unixzen.com> 146509 146510 Adjust default page sizes for haiku arm. 146511 * configure.tgt (arm-haiku): Fix typo. 146512 * emulparams/armelf_haiku.su (MAXPAGESIZE): Use the default value. 146513 (COMMONPAGESIZE): Likewise. 146514 1465152022-01-22 Nick Clifton <nickc@redhat.com> 146516 146517 Update release makeing script with new release numbers 146518 146519 Change version number to 2.38.50 and regenerate files 146520 146521 Add markers for 2.38 branch 146522 1465232022-01-22 Lifang Xia <lifang_xia@linux.alibaba.com> 146524 146525 RISC-V: create new frag after alignment. 146526 PR 28793: 146527 146528 The alignment may be removed in linker. We need to create new frag after 146529 alignment to prevent the assembler from computing static offsets. 146530 146531 gas/ 146532 * config/tc-riscv.c (riscv_frag_align_code): Create new frag. 146533 1465342022-01-22 GDB Administrator <gdbadmin@sourceware.org> 146535 146536 Automatic date update in version.in 146537 1465382022-01-21 Simon Marchi <simon.marchi@polymtl.ca> 146539 146540 gdb: include gdbsupport/buildargv.h in ser-mingw.c 146541 Fixes: 146542 146543 CXX ser-mingw.o 146544 /home/simark/src/binutils-gdb/gdb/ser-mingw.c: In function ‘int pipe_windows_open(serial*, const char*)’: 146545 /home/simark/src/binutils-gdb/gdb/ser-mingw.c:870:3: error: ‘gdb_argv’ was not declared in this scope 146546 870 | gdb_argv argv (name); 146547 | ^~~~~~~~ 146548 146549 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28802 146550 Change-Id: I7f3e8ec5f9ca8582d587545fdf6b69901259f199 146551 1465522022-01-21 Nick Clifton <nickc@redhat.com> 146553 146554 Updated Serbian translation for the ld sub-directory 146555 1465562022-01-21 Andrew Burgess <aburgess@redhat.com> 146557 146558 gdb/doc: fill in two missing @r 146559 I noticed two places in the docs where we appear to be missing @r. 146560 makeinfo seems to do the correct things despite these being 146561 missing (at least, I couldn't see any difference in the pdf or info 146562 output), but it doesn't hurt to have the @r in place. 146563 1465642022-01-21 Mike Frysinger <vapier@gentoo.org> 146565 146566 drop old unused stamp-h.in file 146567 This was needed by ancient versions of automake, but that hasn't been 146568 the case since at least automake-1.5, so punt this from the tree. 146569 1465702022-01-21 Simon Marchi <simon.marchi@polymtl.ca> 146571 146572 gdbsupport/gdb_regex.cc: replace defs.h include with common-defs.h 146573 This was forgotten when gdb_regex was moved from gdb to gdbsupport. 146574 146575 Change-Id: I73b446f71861cabbf7afdb7408ef9d59fa64b804 146576 1465772022-01-21 GDB Administrator <gdbadmin@sourceware.org> 146578 146579 Automatic date update in version.in 146580 1465812022-01-20 Tom Tromey <tromey@adacore.com> 146582 146583 Avoid bad breakpoints with --gc-sections 146584 We found a case where --gc-sections can cause gdb to set an invalid 146585 breakpoint. In the included test case, gdb will set a breakpoint with 146586 two locations, one of which is 0x0. 146587 146588 The code in lnp_state_machine::check_line_address is intended to 146589 filter out this sort of problem, but in this case, the entire CU is 146590 empty, causing unrelocated_lowpc==0x0 -- which circumvents the check. 146591 146592 It seems to me that if a CU is empty like this, then it is ok to 146593 simply ignore the line table, as there won't be any locations anyway. 146594 1465952022-01-20 GDB Administrator <gdbadmin@sourceware.org> 146596 146597 Automatic date update in version.in 146598 1465992022-01-19 Maciej W. Rozycki <macro@embecosm.com> 146600 146601 Add `set print array-indexes' tests for C/C++ arrays 146602 Add `set print array-indexes' tests for C/C++ arrays, complementing one 146603 for Fortran arrays. 146604 1466052022-01-19 Maciej W. Rozycki <macro@embecosm.com> 146606 146607 Respect `set print array-indexes' with Fortran arrays 146608 Add `set print array-indexes' handling for Fortran arrays. Currently 146609 the setting is ignored and indices are never shown. 146610 146611 Keep track of the most recent index handled so that any outstanding 146612 repeated elements printed when the limit set by `set print elements' is 146613 hit have the correct index shown. 146614 146615 Output now looks like: 146616 146617 (gdb) set print array-indexes on 146618 (gdb) print array_1d 146619 $1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1) 146620 (gdb) set print repeats 4 146621 (gdb) set print elements 12 146622 (gdb) print array_2d 146623 $2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...) 146624 (gdb) 146625 146626 for a 5-element vector and a 5 by 5 array filled with the value of 2. 146627 1466282022-01-19 Maciej W. Rozycki <macro@embecosm.com> 146629 146630 Add `set print repeats' tests for C/C++ arrays 146631 Add `set print repeats' tests for C/C++ arrays, complementing one for 146632 Fortran arrays and covering the different interpretation of the `set 146633 print elements' setting in particular where the per-dimension count of 146634 the elements handled is matched against the trigger rather than the 146635 total element count as with Fortran arrays. 146636 1466372022-01-19 Maciej W. Rozycki <macro@embecosm.com> 146638 146639 Respect `set print repeats' with Fortran arrays 146640 Implement `set print repeats' handling for Fortran arrays. Currently 146641 the setting is ignored and always treated as if no limit was set. 146642 146643 Unlike the generic array walker implemented decades ago the Fortran one 146644 is a proper C++ class. Rather than trying to mimic the old walker then, 146645 which turned out a bit of a challenge where interacting with the `set 146646 print elements' setting, write it entirely from scratch, by adding an 146647 extra specialization handler method for processing dimensions other than 146648 the innermost one and letting the specialization class call the `walk_1' 146649 method from the handler as it sees fit. This way repeats can be tracked 146650 and the next inner dimension recursed into as a need arises only, or 146651 unconditionally in the base class. 146652 146653 Keep track of the dimension number being handled in the class rather as 146654 a parameter to the walker so that it does not have to be passed across 146655 by the specialization class. 146656 146657 Use per-dimension element count tracking, needed to terminate processing 146658 early when the limit set by `set print elements' is hit. This requires 146659 extra care too where the limit triggers exactly where another element 146660 that is a subarray begins. In that case rather than recursing we need 146661 to terminate processing or lone `(...)' would be printed. Additionally 146662 if the skipped element is the last one in the current dimension we need 146663 to print `...' by hand, because `continue_walking' won't print it at the 146664 upper level, because it can see the last element has already been taken 146665 care of. 146666 146667 Preserve the existing semantics of `set print elements' where the total 146668 count of the elements handled is matched against the trigger level which 146669 is unlike with the C/C++ array printer where the per-dimension element 146670 count is used instead. 146671 146672 Output now looks like: 146673 146674 (gdb) set print repeats 4 146675 (gdb) print array_2d 146676 $1 = ((2, <repeats 5 times>) <repeats 5 times>) 146677 (gdb) set print elements 12 146678 (gdb) print array_2d 146679 $2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...) 146680 (gdb) 146681 146682 for a 5 by 5 array filled with the value of 2. 146683 146684 Amend existing test cases accordingly that rely on the current incorrect 146685 behavior and explicitly request that there be no limit for printing 146686 repeated elements there. 146687 146688 Add suitable test cases as well covering sliced arrays in particular. 146689 146690 Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com> 146691 1466922022-01-19 John Baldwin <jhb@FreeBSD.org> 146693 146694 fbsd-nat: Add include for gdb_argv. 146695 1466962022-01-19 Alan Modra <amodra@gmail.com> 146697 146698 PowerPC64 DT_RELR ELFv1 146699 More fun with R_PPC64_NONE found in .opd. Fixed by the 146700 allocate_dynrelocs and ppc64_elf_size_dynamic_sections changes, and 146701 since we are doing ifunc, opd and SYMBOL_REFERENCES_LOCAL tests later, 146702 don't duplicate that work in check_relocs. 146703 146704 * elf64-ppc.c (ppc64_elf_check_relocs): Remove opd and ifunc 146705 conditions for rel_count. 146706 (dec_dynrel_count): Likewise. 146707 (allocate_dynrelocs): Test for opd and ifunc when allocating 146708 relative relocs. 146709 (ppc64_elf_size_dynamic_sections): Likewise. 146710 1467112022-01-19 Alan Modra <amodra@gmail.com> 146712 146713 PowerPC64 DT_RELR local PLT 146714 Similarly to the local GOT case. 146715 146716 * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate 146717 space for PLT relocs against local syms when enable_dt_relr. 146718 1467192022-01-19 Alan Modra <amodra@gmail.com> 146720 146721 PowerPC64 DT_RELR local GOT 146722 Fixes another case where we end up with superfluous R_PPC64_NONE. 146723 146724 * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate 146725 space for GOT relocs against non-TLS local syms when enable_dt_relr. 146726 (ppc64_elf_layout_multitoc): Likewise. 146727 1467282022-01-19 GDB Administrator <gdbadmin@sourceware.org> 146729 146730 Automatic date update in version.in 146731 1467322022-01-18 Alan Modra <amodra@gmail.com> 146733 146734 Re: PowerPC64 DT_RELR 146735 HJ: "There are 238 R_PPC64_NONEs in libc.so.6 alone." 146736 Indeed, let's make them go away. I had the SYMBOL_REFERENCES_LOCAL 146737 test in the wrong place. check_relocs is too early to know whether a 146738 symbol is dynamic in a shared library. Lots of glibc symbols are made 146739 local by version script, but that doesn't happen until 146740 size_dynamic_sections. 146741 146742 * elf64-ppc.c (ppc64_elf_check_relocs): Don't count relative relocs 146743 here depending on SYMBOL_REFERENCES_LOCAL. 146744 (dec_dynrel_count): Likewise. 146745 (allocate_dynrelocs): Do so here instead. 146746 1467472022-01-18 Tom Tromey <tom@tromey.com> 146748 146749 Fix the remote-sim.c build 146750 My earlier patch to move gdb_argv broke the remote-sim.c build. This 146751 patch fixes the bug. I'm checking it in. 146752 1467532022-01-18 Simon Marchi <simon.marchi@polymtl.ca> 146754 146755 gdbserver: introduce remote_debug_printf 146756 Add remote_debug_printf, and use it for all debug messages controlled by 146757 remote_debug. 146758 146759 Change remote_debug to be a bool, which is trivial in this case. 146760 146761 Change-Id: I90de13cb892faec3830047b571661822b126d6e8 146762 1467632022-01-18 Simon Marchi <simon.marchi@polymtl.ca> 146764 146765 gdbserver: introduce threads_debug_printf, THREADS_SCOPED_DEBUG_ENTER_EXIT 146766 Add the threads_debug_printf and THREADS_SCOPED_DEBUG_ENTER_EXIT, which 146767 use the logging infrastructure from gdbsupport/common-debug.h. Replace 146768 all debug_print uses that are predicated by debug_threads with 146769 threads_dethreads_debug_printf. Replace uses of the debug_enter and 146770 debug_exit macros with THREADS_SCOPED_DEBUG_ENTER_EXIT, which serves 146771 essentially the same purpose, but allows showing what comes between the 146772 enter and the exit in an indented form. 146773 146774 Note that "threads" debug is currently used for a bit of everything in 146775 GDBserver, not only threads related stuff. It should ideally be cleaned 146776 up and separated logically as is done in GDB, but that's out of the 146777 scope of this patch. 146778 146779 Change-Id: I2d4546464462cb4c16f7f1168c5cec5a89f2289a 146780 1467812022-01-18 Simon Marchi <simon.marchi@polymtl.ca> 146782 146783 gdbserver: turn debug_threads into a boolean 146784 debug_threads is always used as a boolean. Except in ax.cc and 146785 tracepoint.cc. These files have their own macros that use 146786 debug_threads, and have a concept of verbosity level. But they both 146787 have a single level, so it's just a boolean in the end. 146788 146789 Remove this concept of level. If we ever want to re-introduce it, I 146790 think it will be better implemented in a more common location. 146791 146792 Change debug_threads to bool and adjust some users that were treating it 146793 as an int. 146794 146795 Change-Id: I137f596eaf763a08c977dd74417969cedfee9ecf 146796 1467972022-01-18 Tom Tromey <tom@tromey.com> 146798 146799 Simplify Ada catchpoints 146800 All the Ada catchpoints use the same breakpoint_ops contents, because 146801 the catchpoint itself records its kind. This patch simplifies the 146802 code by removing the redundant ops structures. 146803 146804 Move "catch exec" to a new file 146805 The "catch exec" code is reasonably self-contained, and so this patch 146806 moves it out of breakpoint.c (the second largest source file in gdb) 146807 and into a new file, break-catch-exec.c. 146808 146809 Move "catch fork" to a new file 146810 The "catch fork" code is reasonably self-contained, and so this patch 146811 moves it out of breakpoint.c (the second largest source file in gdb) 146812 and into a new file, break-catch-fork.c. 146813 146814 Unify "catch fork" and "catch vfork" 146815 I noticed that "catch fork" and "catch vfork" are nearly identical. 146816 This patch simplifies the code by unifying these two cases. 146817 146818 Move gdb_regex to gdbsupport 146819 This moves the gdb_regex convenience class to gdbsupport. 146820 146821 Introduce gdb-hashtab module in gdbsupport 146822 gdb has some extensions and helpers for working with the libiberty 146823 hash table. This patch consolidates these and moves them to 146824 gdbsupport. 146825 146826 Move gdb obstack code to gdbsupport 146827 This moves the gdb-specific obstack code -- both extensions like 146828 obconcat and obstack_strdup, and things like auto_obstack -- to 146829 gdbsupport. 146830 146831 Move gdb_argv to gdbsupport 146832 This moves the gdb_argv class to a new header in gdbsupport. 146833 146834 Simplify event_location_probe 146835 event_location_probe currently stores two strings, but really only 146836 needs one. This patch simplifies it and removes some unnecessary 146837 copies as well. 146838 146839 Use std::string in event_location 146840 This changes event_location to use std::string, removing some manual 146841 memory management, and an unnecessary string copy. 146842 146843 Split event_location into subclasses 146844 event_location uses the old C-style discriminated union approach. 146845 However, it's better to use subclassing, as this makes the code 146846 clearer and removes some chances for error. This also enables future 146847 cleanups to avoid manual memory management and copies. 146848 146849 Remove EL_* macros from location.c 146850 This patch removes the old-style EL_* macros from location.c. This 146851 cleans up the code by itself, IMO, but also enables further cleanups 146852 in subsequent patches. 146853 146854 Boolify explicit_to_string_internal 146855 This changes explicit_to_string_internal to use 'bool' rather than 146856 'int'. 146857 146858 Remove a use of xfree in location.c 146859 This small cleanup removes a use of xfree from location.c, by 146860 switching to unique_xmalloc_ptr. One function is only used in 146861 location.c, so it is made static. And, another function is changed to 146862 avoid a copy. 146863 1468642022-01-18 Simon Marchi <simon.marchi@polymtl.ca> 146865 146866 gdb: use ptid_t::to_string instead of target_pid_to_str in debug statements 146867 Same idea as 0fab79556484 ("gdb: use ptid_t::to_string in infrun debug 146868 messages"), but throughout GDB. 146869 146870 Change-Id: I62ba36eaef29935316d7187b9b13d7b88491acc1 146871 1468722022-01-18 Andrew Burgess <aburgess@redhat.com> 146873 146874 gdb: preserve `|` in connection details string 146875 Consider this GDB session: 146876 146877 $ gdb -q 146878 (gdb) target remote | gdbserver - ~/tmp/hello.x 146879 Remote debugging using | gdbserver - ~/tmp/hello.x 146880 ... snip ... 146881 (gdb) info connections 146882 Num What Description 146883 * 1 remote gdbserver - ~/tmp/hello.x Remote target using gdb-specific protocol 146884 (gdb) python conn = gdb.selected_inferior().connection 146885 (gdb) python print(conn.details) 146886 gdbserver - ~/tmp/hello.x 146887 (gdb) 146888 146889 I think there are two things wrong here, first in the "What" column of 146890 the 'info connections' output, I think the text should be: 146891 146892 remote | gdbserver - ~/tmp/hello.x 146893 146894 to correctly show the user how the connection was established. And in 146895 a similar fashion, I think that the `details` string of the 146896 gdb.TargetConnection object should be: 146897 146898 | gdbserver - ~/tmp/hello.x 146899 146900 This commit makes this change. Currently the '|' is detected and 146901 removed in gdb/serial.c. The string passed to the pipe_ops 146902 structure (from gdb/ser-pipe.c), doesn't then, contain the `|`, this 146903 is instead implied by the fact that it is a pipes based implementation 146904 of the serial_ops interface. 146905 146906 After this commit we still detect the `|` in gdb/serial.c, but we now 146907 store the full string (including the `|`) in the serial::name member 146908 variable. 146909 146910 For pipe based serial connections, this name is only used for 146911 displaying the two fields I mention above, and in pipe_open (from 146912 gdb/ser-pipe.c), and in pipe_open, we now know to skip over the `|`. 146913 146914 The benefit I see from this change is that GDB's output now more 146915 accurately reflects the commands used to start a target, thus making 146916 it easier for a user to understand what is going on. 146917 1469182022-01-18 Tiezhu Yang <yangtiezhu@loongson.cn> 146919 146920 gdb: testsuite: print explicit test result for gdb.base/dfp-test.exp 146921 In the current code, if decimal floating point is not supported for 146922 this target, there is no binary file dfp-test, and also there is no 146923 test result after execute the following commands: 146924 146925 $ make check-gdb TESTS="gdb.base/dfp-test.exp" 146926 $ grep error gdb/testsuite/gdb.log 146927 /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.c:39:1: error: decimal floating point not supported for this target 146928 [...] 146929 $ cat gdb/testsuite/gdb.sum 146930 [...] 146931 Running target unix 146932 Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ... 146933 146934 === gdb Summary === 146935 [...] 146936 146937 With this patch: 146938 146939 $ make check-gdb TESTS="gdb.base/dfp-test.exp" 146940 $ cat gdb/testsuite/gdb.sum 146941 [...] 146942 Running target unix 146943 Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ... 146944 UNSUPPORTED: gdb.base/dfp-test.exp: decimal floating point not supported for this target. 146945 146946 === gdb Summary === 146947 146948 # of unsupported tests 1 146949 [...] 146950 1469512022-01-18 Simon Marchi <simon.marchi@efficios.com> 146952 146953 bfd/elf64-ppc.c: fix clang -Wbitwise-instead-of-logical warning in ppc64_elf_check_init_fini 146954 I see this error with clang-14: 146955 146956 CC elf64-ppc.lo 146957 /home/smarchi/src/binutils-gdb/bfd/elf64-ppc.c:13131:11: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical] 146958 return (check_pasted_section (info, ".init") 146959 ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 146960 146961 Fix by replacing & with &&. But given that the check_pasted_section 146962 function has side-effects and we want to make sure both calls are made, 146963 assign to temporary variables before evaluating the `&&`. 146964 146965 Change-Id: I849e1b2401bea5f4d8ef3ab9af99ba9e3ef42490 146966 1469672022-01-18 Alan Modra <amodra@gmail.com> 146968 146969 PR28029, debuginfod tests 146970 binutils/NEWS says of the change in --process-links semantics: 146971 If other debug section display options are also enabled (eg 146972 --debug-dump=info) then the contents of matching sections in both the main 146973 file and the separate debuginfo file *will* be displayed. This is because in 146974 most cases the debug section will only be present in one of the files. 146975 146976 Implying that debug info is dumped without --process-links. Indeed 146977 that appears to be the case for readelf. This does the same for 146978 objdump. 146979 146980 PR 28029 146981 * objdump.c (dump_bfd): Do not exit early when !is_mainfile 146982 && !processlinks, instead just exclude non-debug output. 146983 (dump_dwarf): Add is_mainfile parameter and pass to 146984 dump_dwarf_section. 146985 (dump_dwarf_section): Only display debug sections when 146986 !is_mainfile and !process_links. 146987 1469882022-01-18 Alan Modra <amodra@gmail.com> 146989 146990 Check thin archive element file size against archive header 146991 Makes it a little less likely for someone to break their thin archives. 146992 146993 * archive.c (_bfd_get_elt_at_filepos): Check thin archive 146994 element file size. 146995 1469962022-01-18 Alan Modra <amodra@gmail.com> 146997 146998 lang_size_relro_segment tidy 146999 This function has seen too many minimal change style edits. 147000 No functional changes in this patch. 147001 147002 * ldlang.c (lang_size_relro_segment): Tidy. 147003 1470042022-01-18 Alan Modra <amodra@gmail.com> 147005 147006 PowerPC64 DT_RELR 147007 PowerPC64 takes a more traditional approach to DT_RELR than x86. Count 147008 relative relocs in check_relocs, allocate space for them and output in 147009 the usual places but not doing so when enable_dt_relr. DT_RELR is 147010 sized in the existing ppc stub relaxation machinery, run via the 147011 linker's ldemul_after_allocation hook. DT_RELR is output in the same 147012 function that writes ppc stubs, run via ldemul_finish. 147013 147014 This support should be considered experimental. 147015 147016 bfd/ 147017 * elf64-ppc.c (struct ppc_local_dyn_relocs): Renamed from 147018 ppc_dyn_relocs. Add rel_count field. Update uses. 147019 (struct ppc_dyn_relocs): New. Replace all uses of elf_dyn_relocs. 147020 (struct ppc_link_hash_table): Add relr_alloc, relr_count and 147021 relr_addr. 147022 (ppc64_elf_copy_indirect_symbol): Merge rel_count. 147023 (ppc64_elf_check_relocs): Init rel_count for global and local syms. 147024 (dec_dynrel_count): Change r_info param to reloc pointer. Update 147025 all callers. Handle decrementing rel_count. 147026 (allocate_got): Don't allocate space for relative relocs when 147027 enable_dt_relr. 147028 (allocate_dynrelocs): Likewise. 147029 (ppc64_elf_size_dynamic_sections): Likewise. Handle srelrdyn. 147030 (ppc_build_one_stub): Don't emit relative relocs on .branch_lt. 147031 (compare_relr_address, append_relr_off): New functions. 147032 (got_and_plt_relr_for_local_syms, got_and_plt_relr): Likewise. 147033 (ppc64_elf_size_stubs): Size .relr.syn. 147034 (ppc64_elf_build_stubs): Emit .relr.dyn. 147035 (build_global_entry_stubs_and_plt): Don't output relative relocs 147036 when enable_dt_relr. 147037 (write_plt_relocs_for_local_syms): Likewise. 147038 (ppc64_elf_relocate_section): Likewise. 147039 binutils/ 147040 * testsuite/lib/binutils-common.exp (supports_dt_relr): Add 147041 powerpc64. 147042 ld/ 147043 * emulparams/elf64ppc.sh: Source dt-relr.sh. 147044 * testsuite/ld-elf/dt-relr-2b.d: Adjust for powerpc. 147045 * testsuite/ld-elf/dt-relr-2c.d: Likewise. 147046 * testsuite/ld-elf/dt-relr-2d.d: Likewise. 147047 * testsuite/ld-elf/dt-relr-2e.d: Likewise. 147048 1470492022-01-18 Alan Modra <amodra@gmail.com> 147050 147051 tweak __ehdr_start visibility and flags for check_relocs 147052 bfd/ 147053 * elf-bfd.h (UNDEFWEAK_NO_DYNAMIC_RELOC): Test linker_def. 147054 ld/ 147055 * ldelf.c (ldelf_before_allocation): Don't force __ehdr_start 147056 local and hidden here.. 147057 * ldlang.c (lang_symbol_tweaks): ..do so here instead and set 147058 def_regular and linker_def for check_relocs. New function 147059 extracted from lang_process. 147060 1470612022-01-18 GDB Administrator <gdbadmin@sourceware.org> 147062 147063 Automatic date update in version.in 147064 1470652022-01-17 Nick Clifton <nickc@redhat.com> 147066 147067 Update the config.guess and config.sub files from the master repository and regenerate files. 147068 1470692022-01-17 Sergey Belyashov <sergey.belyashov@gmail.com> 147070 147071 Fix Z80 assembly failure. 147072 PR 28762 147073 * app.c (do_scrub_chars): Correct handling when the symbol is not 'af'. 147074 1470752022-01-17 Simon Marchi <simon.marchi@polymtl.ca> 147076 147077 gdb/infrun: rename variable and move to more specific scope 147078 Move the "started" variable to the scope it's needed, and rename it to 147079 "step_over_started". 147080 147081 Change-Id: I56f3384dbd328f55198063bb855edda10f1492a3 147082 1470832022-01-17 Jan Beulich <jbeulich@suse.com> 147084 147085 x86: adjust struct instr_info field types 147086 Now that this lives on the stack, let's have it be a little less 147087 wasteful in terms of space. Switch boolean fields to "bool" (also when 147088 this doesn't change their size) and also limit the widths of "rex", 147089 "rex_used", "op_ad", and "op_index". Do a little bit of re-ordering as 147090 well to limit the number of padding holes. 147091 147092 x86: drop index16 field 147093 There's a single use on a generally infrequently taken code path. Put 147094 the necessary conditional there instead. 147095 147096 x86: drop most Intel syntax register name arrays 147097 By making use of, in particular, oappend_maybe_intel() there's no need 147098 for this redundant set of static data. 147099 147100 x86: fold variables in memory operand index handling 147101 There's no real need for the pseudo-boolean "haveindex" or for separate 147102 32-bit / 64-bit index pointers. Fold them into a single "indexes" and 147103 set that uniformly to AT&T names, compensating by emitting the register 147104 name via oappend_maybe_intel(). 147105 147106 x86: constify disassembler static data 147107 Now that the code is intended to be largely thread-safe, we'd better not 147108 have any writable static objects. 147109 1471102022-01-17 GDB Administrator <gdbadmin@sourceware.org> 147111 147112 Automatic date update in version.in 147113 1471142022-01-16 Joel Brobecker <brobecker@adacore.com> 147115 147116 gdb/copyright.py: Do not update gdbsupport/Makefile.in 147117 This file is generated, so we should not modify it (any modification 147118 we make is going to be undone at the next re-generation anyway). 147119 1471202022-01-16 GDB Administrator <gdbadmin@sourceware.org> 147121 147122 Automatic date update in version.in 147123 1471242022-01-15 GDB Administrator <gdbadmin@sourceware.org> 147125 147126 Automatic date update in version.in 147127 1471282022-01-14 Simon Marchi <simon.marchi@efficios.com> 147129 147130 gdb.dlang/demangle.exp: update expected output for _D8demangle4testFnZv 147131 Since commit ce2d3708bc8b ("Synchronize binutils libiberty sources with 147132 gcc version."), I see this failure: 147133 147134 demangle _D8demangle4testFnZv^M 147135 demangle.test(typeof(null))^M 147136 (gdb) FAIL: gdb.dlang/demangle.exp: _D8demangle4testFnZv 147137 147138 The commit imported the commit 0e32a5aa8bc9 ("libiberty: Add support for 147139 D `typeof(*null)' types") from the gcc repository. That commit includes 147140 an update to libiberty/testsuite/d-demangle-expected, which updates a 147141 test for the exact same mangled name: 147142 147143 _D8demangle4testFnZv 147144 -demangle.test(none) 147145 +demangle.test(typeof(null)) 147146 147147 I don't know anything about D, but give that the change was made by Iain 147148 Buclaw, the D language maintainer, I trust him on that. 147149 147150 Fix our test by updating the expected output in the same way. 147151 147152 Note: it's not really useful to have all these D demangling tests in the 147153 GDB testsuite, since there are demangling tests in libiberty. We should 147154 consider removing them, but we first need to make sure that everything 147155 that is covered in gdb/testsuite/gdb.dlang/demangle.exp is also covered 147156 in libiberty/testsuite/d-demangle-expected. 147157 147158 Change-Id: If2b290ea8367b8e1e0b90b20d4a6e0bee517952d 147159 1471602022-01-14 Nils-Christian Kempke <nils-christian.kempke@intel.com> 147161 147162 gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info 147163 Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides 147164 version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113). 147165 147166 gdb/testsuite/ChangeLog: 147167 2020-12-07 Abdul Basit Ijaz <abdul.b.ijaz@intel.com> 147168 147169 * lib/compiler.c: Add Intel next gen compiler pre-processor check. 147170 * lib/compiler.cc: Ditto. 147171 * lib/fortran.exp (fortran_main): Check Intel next gen compiler in 147172 test_compiler_info. 147173 1471742022-01-14 Alan Modra <amodra@gmail.com> 147175 147176 PR28751 mbind2a / mbind2b regressions on powerpc*-linux 147177 include/ 147178 * bfdlink.h (struct bfd_link_info): Add commonpagesize_is_set. 147179 ld/ 147180 PR 28751 147181 * emultempl/elf.em (handle_option): Set commonpagesize_is_set. 147182 * ldelf.c (ldelf_after_parse): Don't error when only one of 147183 -z max-page-size or -z common-page-size is given, correct the 147184 other value to make it sane. 147185 * testsuite/ld-elf/elf.exp (mbind2a, mbind2b): Do not pass 147186 -z max-page-size. 147187 1471882022-01-14 Jan Beulich <jbeulich@suse.com> 147189 147190 x86: drop ymmxmm_mode 147191 This enumerator is not used by any table entry. 147192 147193 x86: share yet more VEX table entries with EVEX decoding 147194 On top of prior similar work more opportunities have appeared in the 147195 meantime. Note that this also happens to address the prior lack of 147196 decoding of EVEX.L'L for VMOV{L,H}P{S,D} and VMOV{LH,HL}PS. 147197 147198 x86: consistently use scalar_mode for AVX512-FP16 scalar insns 147199 For some reason the original AVFX512F insns were not taken as a basis 147200 here, causing unnecessary divergence. While not an active issue, it is 147201 still relevant to note that OP_XMM() has special treatment of e.g. 147202 scalar_mode (marking broadcast as invalid). Such would better be 147203 consistent for all sufficiently similar insns. 147204 147205 x86: record further wrong uses of EVEX.b 147206 For one EVEX.W set does not imply EVEX.b is uniformly valid. Reject it 147207 for modes which occur for insns allowing for EVEX.W to be set (noticed 147208 with VMOV{H,L}PD and VMOVDDUP, and only in AT&T mode, but not checked 147209 whether further insns would also have been impacted; I expect e.g. 147210 VCMPSD would have had the same issue). And then the present concept of 147211 broadcast makes no sense at all when the memory operand of an insn is 147212 the destination. 147213 1472142022-01-14 Jan Beulich <jbeulich@suse.com> 147215 147216 x86: reduce AVX512 FP set of insns decoded through vex_w_table[] 147217 Like for AVX512-FP16, there's not that many FP insns where going through 147218 this table is easier / cheaper than using suitable macros. Utilize %XS 147219 and %XD more to eliminate a fair number of table entries. 147220 147221 While doing this I noticed a few anomalies. Where lines get touched / 147222 moved anyway, these are being addressed right here: 147223 - vmovshdup used EXx for its 2nd operand, thus displaying seemingly 147224 valid broadcast when EVEX.b is set with a memory operand; use 147225 EXEvexXNoBcst instead just like vmovsldup already does 147226 - vmovlhps used EXx for its 3rd operand, when all sibling entries use 147227 EXq; switch to EXq there for consistency (the two differ only for 147228 memory operands) 147229 1472302022-01-14 Jan Beulich <jbeulich@suse.com> 147231 147232 x86: reduce AVX512-FP16 set of insns decoded through vex_w_table[] 147233 Like already indicated during review of the original submission, there's 147234 really only very few insns where going through this table is easier / 147235 cheaper than using suitable macros. Utilize %XH more and introduce 147236 similar %XS and %XD (which subsequently can be used for further table 147237 size reduction). 147238 147239 While there also switch to using oappend() in 'XH' macro processing. 147240 1472412022-01-14 GDB Administrator <gdbadmin@sourceware.org> 147242 147243 Automatic date update in version.in 147244 1472452022-01-13 H.J. Lu <hjl.tools@gmail.com> 147246 147247 ld: Disable DT_RELR in some -z relro tests 147248 Disable DT_RELR in the following -z relro tests which don't expect 147249 DT_RELR in linker outputs. 147250 147251 * testsuite/ld-i386/pr20830.d: Pass $NO_DT_RELR_LDFLAGS to ld. 147252 * testsuite/ld-x86-64/pr20830a-now.d: Likewise. 147253 * testsuite/ld-x86-64/pr20830a.d: Likewise. 147254 * testsuite/ld-x86-64/pr20830b-now.d: Likewise. 147255 * testsuite/ld-x86-64/pr20830b.d: Likewise. 147256 * testsuite/ld-x86-64/pr21038a-now.d: Likewise. 147257 * testsuite/ld-x86-64/pr21038a.d: Likewise. 147258 * testsuite/ld-x86-64/pr21038b-now.d: Likewise. 147259 * testsuite/ld-x86-64/pr21038c-now.d: Likewise. 147260 * testsuite/ld-x86-64/pr21038c.d: Likewise. 147261 1472622022-01-13 H.J. Lu <hjl.tools@gmail.com> 147263 147264 Reapply libiberty: Pass --plugin to AR and RANLIB 147265 Reapply the patch to detect GCC LTO plugin used for libiberty build to 147266 support LTO build in libiberty. 147267 147268 * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ 147269 (RANLIB): Add @RANLIB_PLUGIN_OPTION@. 147270 (configure_deps): Depend on ../config/gcc-plugin.m4. 147271 * aclocal.m4: Include ../config/gcc-plugin.m4. 147272 * configure.ac: AC_SUBST AR_PLUGIN_OPTION and 147273 RANLIB_PLUGIN_OPTION. 147274 * configure: Regenerate. 147275 1472762022-01-13 H.J. Lu <hjl.tools@gmail.com> 147277 147278 elf: Remove the 1-page gap before the RELRO segment 147279 The existing RELRO scheme may leave a 1-page gap before the RELRO segment 147280 and align the end of the RELRO segment to the page size: 147281 147282 [18] .eh_frame PROGBITS 408fa0 008fa0 005e80 00 A 0 0 8 147283 [19] .init_array INIT_ARRAY 410de0 00fde0 000008 08 WA 0 0 8 147284 [20] .fini_array FINI_ARRAY 410de8 00fde8 000008 08 WA 0 0 8 147285 [21] .dynamic DYNAMIC 410df0 00fdf0 000200 10 WA 7 0 8 147286 [22] .got PROGBITS 410ff0 00fff0 000010 08 WA 0 0 8 147287 [23] .got.plt PROGBITS 411000 010000 000048 08 WA 0 0 8 147288 147289 Instead, we can remove the 1-page gap if the maximum page size >= the 147290 maximum section alignment: 147291 147292 [18] .eh_frame PROGBITS 408fa0 008fa0 005e80 00 A 0 0 8 147293 [19] .init_array INIT_ARRAY 40fde0 00fde0 000008 08 WA 0 0 8 147294 [20] .fini_array FINI_ARRAY 40fde8 00fde8 000008 08 WA 0 0 8 147295 [21] .dynamic DYNAMIC 40fdf0 00fdf0 000200 10 WA 7 0 8 147296 [22] .got PROGBITS 40fff0 00fff0 000010 08 WA 0 0 8 147297 [23] .got.plt PROGBITS 410000 010000 000048 08 WA 0 0 8 147298 147299 Because the end of the RELRO segment is always aligned to the page size 147300 and may not be moved, the RELRO segment size may be increased: 147301 147302 [ 3] .dynstr STRTAB 000148 000148 000001 00 A 0 0 1 147303 [ 4] .eh_frame PROGBITS 000150 000150 000000 00 A 0 0 8 147304 [ 5] .init_array INIT_ARRAY 200150 000150 000010 08 WA 0 0 1 147305 [ 6] .fini_array FINI_ARRAY 200160 000160 000010 08 WA 0 0 1 147306 [ 7] .jcr PROGBITS 200170 000170 000008 00 WA 0 0 1 147307 [ 8] .data.rel.ro PROGBITS 200180 000180 000020 00 WA 0 0 16 147308 [ 9] .dynamic DYNAMIC 2001a0 0001a0 0001c0 10 WA 3 0 8 147309 [10] .got PROGBITS 200360 000360 0002a8 00 WA 0 0 8 147310 [11] .bss NOBITS 201000 000608 000840 00 WA 0 0 1 147311 147312 vs the old section layout: 147313 147314 [ 3] .dynstr STRTAB 000148 000148 000001 00 A 0 0 1 147315 [ 4] .eh_frame PROGBITS 000150 000150 000000 00 A 0 0 8 147316 [ 5] .init_array INIT_ARRAY 200b48 000b48 000010 08 WA 0 0 1 147317 [ 6] .fini_array FINI_ARRAY 200b58 000b58 000010 08 WA 0 0 1 147318 [ 7] .jcr PROGBITS 200b68 000b68 000008 00 WA 0 0 1 147319 [ 8] .data.rel.ro PROGBITS 200b70 000b70 000020 00 WA 0 0 16 147320 [ 9] .dynamic DYNAMIC 200b90 000b90 0001c0 10 WA 3 0 8 147321 [10] .got PROGBITS 200d50 000d50 0002a8 00 WA 0 0 8 147322 [11] .bss NOBITS 201000 000ff8 000840 00 WA 0 0 1 147323 147324 But there is no 1-page gap. 147325 147326 PR ld/28743 147327 * ldlang.c (lang_size_relro_segment_1): Remove the 1-page gap 147328 before the RELRO segment if the maximum page size >= the maximum 147329 section alignment. 147330 * testsuite/ld-i386/pr20830.d: Adjusted. 147331 * testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise. 147332 * testsuite/ld-x86-64/pr14207.d: Likewise. 147333 * testsuite/ld-x86-64/pr18176.d: Likewise. 147334 * testsuite/ld-x86-64/pr20830a-now.d: Likewise. 147335 * testsuite/ld-x86-64/pr20830a.d: Likewise. 147336 * testsuite/ld-x86-64/pr20830b-now.d: Likewise. 147337 * testsuite/ld-x86-64/pr20830b.d: Likewise. 147338 * testsuite/ld-x86-64/pr21038a-now.d: Likewise. 147339 * testsuite/ld-x86-64/pr21038a.d: Likewise. 147340 * testsuite/ld-x86-64/pr21038b-now.d: Likewise. 147341 * testsuite/ld-x86-64/pr21038c-now.d: Likewise. 147342 * testsuite/ld-x86-64/pr21038c.d: Likewise. 147343 1473442022-01-13 Nick Clifton <nickc@redhat.com> 147345 147346 Synchronize binutils libiberty sources with gcc version. 147347 +2021-12-30 Lancelot SIX <lsix@lancelotsix.com> 147348 + 147349 + * cp-demangle.c (d_clone_suffix): Support digits in clone tag 147350 + names. 147351 + * testsuite/demangle-expected: Check demangling of clone symbols 147352 + with digits in name. 147353 + 147354 +2021-12-16 H.J. Lu <hjl.tools@gmail.com> 147355 + 147356 + Revert: 147357 + 2021-12-16 H.J. Lu <hjl.tools@gmail.com> 147358 + 147359 + * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ 147360 + (RANLIB): Add @RANLIB_PLUGIN_OPTION@. 147361 + (configure_deps): Depend on ../config/gcc-plugin.m4. 147362 + * configure.ac: AC_SUBST AR_PLUGIN_OPTION and 147363 + RANLIB_PLUGIN_OPTION. 147364 + * aclocal.m4: Regenerated. 147365 + * configure: Likewise. 147366 + 147367 +2021-12-15 H.J. Lu <hjl.tools@gmail.com> 147368 + 147369 + * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ 147370 + (RANLIB): Add @RANLIB_PLUGIN_OPTION@. 147371 + (configure_deps): Depend on ../config/gcc-plugin.m4. 147372 + * configure.ac: AC_SUBST AR_PLUGIN_OPTION and 147373 + RANLIB_PLUGIN_OPTION. 147374 + * aclocal.m4: Regenerated. 147375 + * configure: Likewise. 147376 + 147377 +2021-11-29 Eric Gallager <egallager@gcc.gnu.org> 147378 + 147379 + PR other/103021 147380 + * Makefile.in: Use ETAGS variable in TAGS target. 147381 + * configure: Regenerate. 147382 + * configure.ac: Allow ETAGS variable to be overridden. 147383 + 147384 +2021-11-29 Andrew Pinski <apinski@marvell.com> 147385 + 147386 + * make-temp-file.c (try_dir): Check to see if the dir 147387 + is actually a directory. 147388 + 147389 +2021-10-22 Eric Gallager <egallager@gcc.gnu.org> 147390 + 147391 + PR other/102663 147392 + * Makefile.in: Allow dvi-formatted documentation 147393 + to be installed. 147394 + 147395 +2021-10-17 Lu?s Ferreira <contact@lsferreira.net> 147396 + 147397 + PR d/102618 147398 + * d-demangle.c (dlang_parse_qualified): Handle anonymous 147399 + symbols correctly. 147400 + * testsuite/d-demangle-expected: New tests to cover anonymous 147401 + symbols. 147402 + 147403 +2021-10-14 Lu?s Ferreira <contact@lsferreira.net> 147404 + 147405 + * testsuite/d-demangle-expected: Add test case for function literals. 147406 + 147407 +2021-10-14 Lu?s Ferreira <contact@lsferreira.net> 147408 + 147409 + * testsuite/d-demangle-expected: Add test cases for simple special 147410 + mangles. 147411 + 147412 +2021-10-12 Lu?s Ferreira <contact@lsferreira.net> 147413 + 147414 + * d-demangle.c (dlang_parse_qualified): Remove redudant parenthesis 147415 + around lhs and rhs of assignments. 147416 + 147417 +2021-10-01 Lu?s Ferreira <contact@lsferreira.net> 147418 + 147419 + * testsuite/d-demangle-expected: Add missing format for new test 147420 + 147421 +2021-09-23 Lu?s Ferreira <contact@lsferreira.net> 147422 + 147423 + * d-demangle.c (dlang_Type): Validate MANGLED is nonnull. 147424 + * testsuite/d-demangle-expected: New test. 147425 + 147426 +2021-09-23 Lu?s Ferreira <contact@lsferreira.net> 147427 + 147428 + * d-demangle.c (dlang_symbol_backref): Ensure strlen of 147429 + string is less than length computed by dlang_number. 147430 + 147431 +2021-09-01 Iain Sandoe <iain@sandoe.co.uk> 147432 147433 * configure: Regenerate. 147434 + * configure.ac: Do not search for sbrk on Darwin. 147435 + * xmalloc.c: Do not declare sbrk unless it has been found 147436 + by configure. 147437 + 147438 +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org> 147439 + 147440 + * d-demangle.c (dlang_identifier): Skip over fake parent manglings. 147441 + * testsuite/d-demangle-expected: Add tests. 147442 + 147443 +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org> 147444 + 147445 + * d-demangle.c (dlang_parse_arrayliteral): Add 'info' parameter. 147446 + (dlang_parse_assocarray): Likewise. 147447 + (dlang_parse_structlit): Likewise. 147448 + (dlang_value): Likewise. Handle function literal symbols. 147449 + (dlang_template_args): Pass 'info' to dlang_value. 147450 + * testsuite/d-demangle-expected: Add new test. 147451 + 147452 +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org> 147453 + 147454 + * d-demangle.c (dlang_attributes): Handle typeof(*null). 147455 + (dlang_type): Likewise. Demangle 'n' as typeof(null). 147456 + * testsuite/d-demangle-expected: Update tests. 147457 + 147458 +2021-08-23 Iain Sandoe <iain@sandoe.co.uk> 147459 + 147460 + * simple-object-mach-o.c (simple_object_mach_o_write_segment): 147461 + Cast the first argument to set_32 as needed. 147462 147463 -2021-07-03 Nick Clifton <nickc@redhat.com> 147464 +2021-08-18 Iain Sandoe <iain@sandoe.co.uk> 147465 147466 + * simple-object-mach-o.c (simple_object_mach_o_write_segment): 147467 + Arrange to swap the LTO index tables where needed. 147468 # Please enter the commit message for your changes. Lines starting 147469 1474702022-01-13 Andrew Burgess <aburgess@redhat.com> 147471 147472 gdb: don't use -Wmissing-prototypes with g++ 147473 This commit aims to not make use of -Wmissing-prototypes when 147474 compiling with g++. 147475 147476 Use of -Wmissing-prototypes was added with this commit: 147477 147478 commit a0761e34f054767de6d6389929d27e9015fb299b 147479 Date: Wed Mar 11 15:15:12 2020 -0400 147480 147481 gdb: enable -Wmissing-prototypes warning 147482 147483 Because clang can provide helpful warnings with this flag. 147484 Unfortunately, g++ doesn't accept this flag, and will give this 147485 warning: 147486 147487 cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ 147488 147489 In theory the fact that this flag is not supported should be detected 147490 by the configure check in gdbsupport/warning.m4, but for users of 147491 ccache, this check doesn't work due to a long standing ccache issue: 147492 147493 https://github.com/ccache/ccache/issues/738 147494 147495 The ccache problem is that -W... options are reordered on the command 147496 line, and so -Wmissing-prototypes is seen before -Werror. Usually 147497 this doesn't matter, but the above warning (about the flag not being 147498 valid) is issued before the -Werror flag is processed, and so is not 147499 fatal. 147500 147501 There have been two previous attempts to fix this that I'm aware of. 147502 The first is: 147503 147504 https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html 147505 147506 In this attempt, instead of just relying on a compile to check if a 147507 flag is valid, the proposal was to both compile and link. As linking 147508 doesn't go through ccache, we don't suffer from the argument 147509 reordering problem, and the link phase will correctly fail when using 147510 -Wmissing-prototypes with g++. The configure script will then disable 147511 the use of this flag. 147512 147513 This approach was rejected, and the suggestion was to only add the 147514 -Wmissing-prototypes flag if we are compiling with gcc. 147515 147516 The second attempt, attempts this approach, and can be found here: 147517 147518 https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html 147519 147520 This attempt only adds the -Wmissing-prototypes flag is the value of 147521 GCC is not 'yes'. This feels like it is doing the right thing, 147522 unfortunately, the GCC flag is really a 'is gcc like' flag, not a 147523 strict, is gcc check. As such, GCC is set to 'yes' for clang, which 147524 would mean the flag was not included for clang or gcc. The entire 147525 point of the original commit was to add this flag for clang, so 147526 clearly the second attempt is not sufficient either. 147527 147528 In this new attempt I have added gdbsupport/compiler-type.m4, this 147529 file defines AM_GDB_COMPILER_TYPE. This macro sets the variable 147530 GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future 147531 the list of values might be extended to cover other compilers, if this 147532 is ever useful. 147533 147534 I've then modified gdbsupport/warning.m4 to only add the problematic 147535 -Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'. 147536 147537 I've tested this with both gcc and clang and see the expected results, 147538 gcc no longer attempts to use the -Wmissing-prototypes flag, while 147539 clang continues to use it. 147540 147541 When compiling using ccache, I am no longer seeing the warning. 147542 1475432022-01-13 Andrew Burgess <aburgess@redhat.com> 147544 147545 gdb: add some extra debug information to attach_command 147546 While working on another patch I wanted to add some extra debug 147547 information to the attach_command function. This required me to add a 147548 new function to convert the thread_info::state variable to a string. 147549 147550 The new debug might be useful to others, and the state to string 147551 function might be useful in other locations, so I thought I'd merge 147552 it. 147553 1475542022-01-13 Alan Modra <amodra@gmail.com> 147555 147556 Re: gas: add visibility support using GNU syntax on XCOFF 147557 tc-ppc.c: In function 'ppc_comm': 147558 tc-ppc.c:4560:40: error: 'visibility' may be used uninitialized in this function [-Werror=maybe-uninitialized] 147559 147560 With that fixed we hit lots of segfaults in the ld testsuite. 147561 147562 PR 22085 147563 bfd/ 147564 * xcofflink.c (xcoff_link_input_bfd): Don't segfault on NULL 147565 sym_hash. 147566 gas/ 147567 * config/tc-ppc.c (ppc_comm): Init visibility. 147568 1475692022-01-13 Alan Modra <amodra@gmail.com> 147570 147571 dt-relr.exp --no-as-needed 147572 Otherwise the very simple test may not be linked with libc.so at all, 147573 and thus correctly have no version reference added. Causing failure 147574 of the dt-relr-glibc-1b.so test. 147575 147576 * testsuite/ld-elf/dt-relr.exp: Link with --no-as-needed. 147577 1475782022-01-13 Alan Modra <amodra@gmail.com> 147579 147580 Correct .relr.dyn nocombreloc script 147581 * scripttempl/elf.sc (.relr.dyn): Don't depend on $COMBRELOC. 147582 1475832022-01-13 Alan Modra <amodra@gmail.com> 147584 147585 testsuite supports_dt_relr 147586 Tidy, and fix "FAIL: Build dt-relr-glibc-1b.so" on all non-x86 147587 linux targets. 147588 147589 binutils/ 147590 * binutils-common.exp (supports_dt_relr): New proc. 147591 ld/ 147592 * testsuite/config/default.exp (DT_RELR_LDFLAGS, NO_DT_RELR_LDFLAGS), 147593 (DT_RELR_CC_LDFLAGS, NO_DT_RELR_CC_LDFLAGS): Use supports_dt_relr. 147594 * testsuite/ld-elf/dt-relr.exp: Don't run unless supports_dt_relr. 147595 * testsuite/ld-elf/dt-relr-1a.d: Likewise. 147596 * testsuite/ld-elf/dt-relr-1b.d: Likewise. 147597 * testsuite/ld-elf/dt-relr-1c.d: Likewise. 147598 * testsuite/ld-elf/dt-relr-2a.d: Likewise. 147599 * testsuite/ld-elf/dt-relr-2b.d: Likewise. 147600 * testsuite/ld-elf/dt-relr-2c.d: Likewise. 147601 * testsuite/ld-elf/dt-relr-2d.d: Likewise. 147602 * testsuite/ld-elf/dt-relr-2e.d: Likewise. 147603 * testsuite/ld-elf/dt-relr-2f.d: Likewise. 147604 * testsuite/ld-elf/dt-relr-2g.d: Likewise. 147605 * testsuite/ld-elf/dt-relr-2h.d: Likewise. 147606 * testsuite/ld-elf/dt-relr-3a.d: Likewise. 147607 * testsuite/ld-elf/dt-relr-3b.d: Likewise. 147608 1476092022-01-13 Alan Modra <amodra@gmail.com> 147610 147611 Don't use C++ comments in assembly 147612 It might seem to work, but only if '/' is a start of comment char. 147613 147614 * testsuite/ld-elf/dt-relr-1.s: Use # for comment. 147615 * testsuite/ld-elf/dt-relr-2.s: Likewise. 147616 * testsuite/ld-elf/dt-relr-3.s: Likewise. 147617 1476182022-01-13 Alan Modra <amodra@gmail.com> 147619 147620 Move DT_RELR tag setting to elflink.c 147621 This makes the code setting DT_RELR tags generally available. Many 147622 targets will be able to use the defaults. Those that can't should set 147623 up sh_entsize for .relr.dyn output section before reaching the dynamic 147624 tag code in bfd_elf_final_link. 147625 147626 * elflink.c (bfd_elf_final_link): Set up DT_RELR tags and sh_entsize. 147627 * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Don't do any 147628 of that here. 147629 1476302022-01-13 Alan Modra <amodra@gmail.com> 147631 147632 Re: Set SEC_ELF_REVERSE_COPY earlier 147633 Let's not rely on .init/.fini having relocs for the size sanity check. 147634 This is mainly to squash reports of "my fuzzed object made ld hang". 147635 1476362022-01-13 Tiezhu Yang <yangtiezhu@loongson.cn> 147637 147638 gdb: testsuite: make string[] type as char in gdb.base/charset.c 147639 This reverts the commit ff656e2e1cb1 ("gdb: testsuite: fix failed 147640 testcases in gdb.base/charset.exp"). 147641 147642 The original test code has no problem. On an architecture where 147643 char is signed, then both 'A' and ebcdic_us_string[7] will yield 147644 -63, which makes the equality true. On an architecture where char 147645 is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193, 147646 which also makes the equality true. 147647 147648 The test cases only failed on LoongArch. The default type of char 147649 is signed char on LoongArch, like x86-64. But when use gdb print 147650 command on LoongArch, the default type of char is unsigned char, 147651 this is wrong, I will look into it later, sorry for that. 147652 147653 On LoongArch: 147654 147655 $ cat test_char.c 147656 #include <stdio.h> 147657 147658 int main() 147659 { 147660 char c1 = 193; 147661 unsigned char c2 = 193; 147662 147663 printf("%d\n", c1); 147664 printf("%d\n", c1 == c2); 147665 147666 return 0; 147667 } 147668 $ gcc test_char.c -o test_char 147669 $ ./test_char 147670 -63 147671 0 147672 147673 (gdb) set target-charset EBCDIC-US 147674 (gdb) print 'A' 147675 $1 = 193 'A' 147676 (gdb) print /c 'A' 147677 $2 = 193 'A' 147678 (gdb) print /u 'A' 147679 $3 = 193 147680 (gdb) print /d 'A' 147681 $4 = -63 147682 (gdb) print /x 'A' 147683 $5 = 0xc1 147684 1476852022-01-13 GDB Administrator <gdbadmin@sourceware.org> 147686 147687 Automatic date update in version.in 147688 1476892022-01-12 Carl Love <cel@us.ibm.com> 147690 147691 gdb Power 9 add test for HW watchpoint support. 147692 The Power 9 processor revision 2.2 has HW watchpoint support disabled due 147693 to a HW bug. The support is fixed in Power 9 processor revision 2.3. This 147694 patch add a test to lib/gdb.exp for Power to determine if the processor 147695 supports HW watchpoints or not. If the Power processor doesn't support HW 147696 watchpoints the proceedure skip_hw_watchpoint_tests will return 1 to 147697 disable the various HW watchpoint tests. 147698 147699 The patch has been tested on Power 9, processor revesions 2.2 and 2.3. The 147700 patch has also been tested on Power 10. No regression test failures were 147701 found. 147702 1477032022-01-12 Andrew Burgess <aburgess@redhat.com> 147704 147705 gdb/python: add gdb.host_charset function 147706 We already have gdb.target_charset and gdb.target_wide_charset. This 147707 commit adds gdb.host_charset along the same lines. 147708 1477092022-01-12 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 147710 147711 gdb/testsuite: fix gdb.python/py-events.exp for finding process id 147712 When executed with --target_board=native-extended-gdbserver, the 147713 gdb.python/py-events.exp test errors out with 147714 147715 ERROR: tcl error sourcing /path/to/gdb/testsuite/gdb.python/py-events.exp. 147716 ERROR: can't read "process_id": no such variable 147717 while executing 147718 "lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr"" 147719 (file "/path/to/gdb/testsuite/gdb.python/py-events.exp" line 103) 147720 invoked from within 147721 "source /path/to/gdb/testsuite/gdb.python/py-events.exp" 147722 ("uplevel" body line 1) 147723 invoked from within 147724 "uplevel #0 source /path/to/gdb/testsuite/gdb.python/py-events.exp" 147725 invoked from within 147726 "catch "uplevel #0 source $test_file_name"" 147727 147728 There are multiple problems around this: 147729 147730 1. The process_id variable is not initialized to a default value. 147731 147732 2. The test attempts to find the PID of the current thread, but the 147733 regexp that it uses is not tailored for the output printed by the 147734 remote target. 147735 147736 3. The test uses "info threads" to find the current thread PID. 147737 Using the "thread" command instead is simpler. 147738 147739 Fix these problems. 147740 1477412022-01-12 Tom Tromey <tromey@adacore.com> 147742 147743 Don't mention "serial" in target remote description 147744 PR remote/9177 points out that "info files" mentions "serial" a couple 147745 of times: 147746 147747 Remote serial target in gdb-specific protocol: 147748 Debugging a target over a serial line. 147749 147750 However, often the remote target isn't really a serial connection. 147751 147752 It seems to me that this text could be a bit clearer; and furthermore 147753 since "info files" prints the target's long description, 147754 remote_target::files_info doesn't really add much and can simply be 147755 removed. 147756 147757 Regression tested on x86-64 Fedora 34. 147758 147759 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9177 147760 1477612022-01-12 H.J. Lu <hjl.tools@gmail.com> 147762 147763 ld: Add glibc dependency for DT_RELR 147764 When DT_RELR is enabled, to avoid random run-time crash with older glibc 147765 binaries without DT_RELR support, add a GLIBC_ABI_DT_RELR symbol version, 147766 which is provided by glibc with DT_RELR support, dependency on the shared 147767 C library if it provides a GLIBC_2.XX symbol version. 147768 147769 bfd/ 147770 147771 * elflink.c (elf_link_add_dt_relr_dependency): New function. 147772 (bfd_elf_size_dynamic_sections): Call 147773 elf_link_add_dt_relr_dependency if DT_RELR is enabled. 147774 147775 ld/ 147776 147777 * ld.texi: Mention GLIBC_ABI_DT_RELR in -z pack-relative-relocs 147778 entry. 147779 * testsuite/ld-elf/dt-relr-glibc-1.c: New file. 147780 * testsuite/ld-elf/dt-relr-glibc-1a.rd: Likewise. 147781 * testsuite/ld-elf/dt-relr-glibc-1b.rd: Likewise. 147782 * testsuite/ld-elf/dt-relr.exp: Likewise. 147783 1477842022-01-12 H.J. Lu <hjl.tools@gmail.com> 147785 147786 ld: Add simple DT_RELR tests 147787 * testsuite/ld-elf/dt-relr-1.s: New file. 147788 * testsuite/ld-elf/dt-relr-1a.d: Likewise. 147789 * testsuite/ld-elf/dt-relr-1b.d: Likewise. 147790 * testsuite/ld-elf/dt-relr-1c.d: Likewise. 147791 * testsuite/ld-elf/dt-relr-2.s: Likewise. 147792 * testsuite/ld-elf/dt-relr-2a.d: Likewise. 147793 * testsuite/ld-elf/dt-relr-2b.d: Likewise. 147794 * testsuite/ld-elf/dt-relr-2c.d: Likewise. 147795 * testsuite/ld-elf/dt-relr-2d.d: Likewise. 147796 * testsuite/ld-elf/dt-relr-2e.d: Likewise. 147797 * testsuite/ld-elf/dt-relr-2f.d: Likewise. 147798 * testsuite/ld-elf/dt-relr-2g.d: Likewise. 147799 * testsuite/ld-elf/dt-relr-2h.d: Likewise. 147800 * testsuite/ld-elf/dt-relr-3.s: Likewise. 147801 * testsuite/ld-elf/dt-relr-3a.d: Likewise. 147802 * testsuite/ld-elf/dt-relr-3b.d: Likewise. 147803 * testsuite/ld-i386/dt-relr-1.s: Likewise. 147804 * testsuite/ld-i386/dt-relr-1a.d: Likewise. 147805 * testsuite/ld-i386/dt-relr-1b.d: Likewise. 147806 * testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise. 147807 * testsuite/ld-x86-64/dt-relr-1a.d: Likewise. 147808 * testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise. 147809 * testsuite/ld-x86-64/dt-relr-1b.d: Likewise. 147810 * testsuite/ld-x86-64/dt-relr-1.s: Likewise. 147811 * testsuite/ld-i386/i386.exp: Run dt-relr-1a and dt-relr-1b. 147812 * testsuite/ld-x86-64/x86-64.exp: Run dt-relr-1a, dt-relr-1a-x32 147813 dt-relr-1b and dt-relr-1b-x32. 147814 1478152022-01-12 H.J. Lu <hjl.tools@gmail.com> 147816 147817 x86: Add DT_RELR support 147818 DT_RELR is implemented with linker relaxation: 147819 147820 1. During linker relaxation, we scan input relocations with the same 147821 logic in relocate_section to determine if a relative relocation should 147822 be generated and save the relative relocation candidate information for 147823 sizing the DT_RELR section later after all symbols addresses can be 147824 determined. For these relative relocations which can't be placed in 147825 the DT_RELR section, they will be placed in the rela.dyn/rel.dyn 147826 section. 147827 2. When DT_RELR is enabled, _bfd_elf_map_sections_to_segments calls a 147828 backend function to size the DT_RELR section which will compute the 147829 DT_RELR section size and tell ldelf_map_segments to layout sections 147830 again when the DT_RELR section size has been increased. 147831 3. After regular symbol processing is finished, bfd_elf_final_link calls 147832 a backend function to finish the DT_RELR section. 147833 147834 * elf32-i386.c (elf_i386_relocate_section): Don't generate 147835 relative relocation when DT_RELR is enabled. 147836 (elf_i386_finish_dynamic_symbol): Likewise. 147837 * elf64-x86-64.c (elf_x86_64_relocate_section): Don't generate 147838 relative relocation when DT_RELR is enabled. 147839 (elf_x86_64_finish_dynamic_symbol): Likewise. 147840 * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize 147841 relative_r_type, relative_r_name, elf_append_reloc, 147842 elf_write_addend and elf_write_addend_in_got. 147843 (elf_x86_relative_reloc_record_add): New function. 147844 (_bfd_x86_elf_link_relax_section): Likewise. 147845 (elf64_dt_relr_bitmap_add): Likewise. 147846 (elf32_dt_relr_bitmap_add): Likewise. 147847 (_bfd_elf32_write_addend): Likewise. 147848 (_bfd_elf64_write_addend): Likewise. 147849 (elf_x86_size_or_finish_relative_reloc): Likewise. 147850 (elf_x86_compute_dl_relr_bitmap): Likewise. 147851 (elf_x86_write_dl_relr_bitmap): Likewise. 147852 (elf_x86_relative_reloc_compare ): Likewise. 147853 (_bfd_elf_x86_size_relative_relocs): Likewise. 147854 (_bfd_elf_x86_finish_relative_relocs): Likewise. 147855 (_bfd_x86_elf_size_dynamic_sections): Skip the .relr.dyn section. 147856 (_bfd_x86_elf_finish_dynamic_sections): Convert 3 spare dynamic 147857 tags to DT_RELR, DT_RELRSZ and for compact relative relocation. 147858 * elfxx-x86.h (X86_64_GOT_TYPE_P): New. 147859 (I386_GOT_TYPE_P): Likewise. 147860 (X86_GOT_TYPE_P): Likewise. 147861 (X86_64_RELATIVE_RELOC_TYPE_P): Likewise. 147862 (I386_RELATIVE_RELOC_TYPE_P): Likewise. 147863 (X86_RELATIVE_RELOC_TYPE_P): Likewise. 147864 (X86_LOCAL_GOT_RELATIVE_RELOC_P): Likewise. 147865 (I386_PCREL_TYPE_P): Likewise. 147866 (X86_64_PCREL_TYPE_P): Likewise. 147867 (X86_64_NEED_DYNAMIC_RELOC_TYPE_P): Rewrite. 147868 (I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise. 147869 (GENERATE_DYNAMIC_RELOCATION_P): Also check rel_from_abs. 147870 (elf_x86_link_hash_entry): Add got_relative_reloc_done. 147871 (elf_x86_relative_reloc_record): New. 147872 (elf_x86_relative_reloc_data): Likewise. 147873 (elf_dt_relr_bitmap): Likewise. 147874 (elf_x86_link_hash_table): Add dt_relr_bitmap, relative_reloc, 147875 unaligned_relative_reloc, relative_r_type, relative_r_name, 147876 elf_append_reloc, elf_write_addend, elf_write_addend_in_got and 147877 relative_reloc_done. 147878 (elf_x86_relative_reloc_done): New. 147879 (relative_reloc_packed): Likewise. 147880 (_bfd_x86_elf_link_relax_section): Likewise. 147881 (_bfd_elf_x86_size_relative_relocs): Likewise. 147882 (_bfd_elf_x86_finish_relative_relocs): Likewise. 147883 (_bfd_elf32_write_addend): Likewise. 147884 (_bfd_elf64_write_addend): Likewise. 147885 (bfd_elf32_bfd_relax_section): Likewise. 147886 (bfd_elf64_bfd_relax_section): Likewise. 147887 (elf_backend_size_relative_relocs): Likewise. 147888 (elf_backend_finish_relative_relocs): Likewise. 147889 (elf_x86_allocate_local_got_info): Also allocate 147890 relative_reloc_done. 147891 1478922022-01-12 H.J. Lu <hjl.tools@gmail.com> 147893 147894 elf: Support DT_RELR in linker tests 147895 Allow eabling and disabling DT_RELR in linker tests. Disable DT_RELR in 147896 linker tests which don't expect DT_RELR in linker outputs. 147897 147898 binutils/ 147899 147900 * testsuite/lib/binutils-common.exp (run_dump_test): Make 147901 DT_RELR_LDFLAGS and NO_DT_RELR_LDFLAGS global. 147902 147903 ld/ 147904 147905 * testsuite/config/default.exp (DT_RELR_LDFLAGS): New. 147906 (DT_RELR_CC_LDFLAGS): Likewise. 147907 (NO_DT_RELR_LDFLAGS): Likewise. 147908 (NO_DT_RELR_CC_LDFLAGS): Likewise. 147909 * testsuite/ld-elf/shared.exp: Pass $NO_DT_RELR_LDFLAGS to 147910 linker for some tests. 147911 * testsuite/ld-i386/export-class.exp: Likewise. 147912 * testsuite/ld-i386/i386.exp: Likewise. 147913 * testsuite/ld-i386/ibt-plt-2a.d: Pass $NO_DT_RELR_LDFLAGS to 147914 linker. 147915 * testsuite/ld-i386/ibt-plt-3a.d: Likewise. 147916 * testsuite/ld-i386/ibt-plt-3c.d: Likewise. 147917 * testsuite/ld-i386/pr26869.d: Likewise. 147918 * testsuite/ld-i386/report-reloc-1.d: Likewise. 147919 * testsuite/ld-ifunc/ifunc-2-i386-now.d: Likewise. 147920 * testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise. 147921 * testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise. 147922 * testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise. 147923 * testsuite/ld-ifunc/pr17154-x86-64.d: Likewise. 147924 * testsuite/ld-x86-64/bnd-branch-1-now.d: Likewise. 147925 * testsuite/ld-x86-64/bnd-ifunc-1-now.d: Likewise. 147926 * testsuite/ld-x86-64/bnd-ifunc-2-now.d: Likewise. 147927 * testsuite/ld-x86-64/bnd-ifunc-2.d: Likewise. 147928 * testsuite/ld-x86-64/bnd-plt-1-now.d: Likewise. 147929 * testsuite/ld-x86-64/bnd-plt-1.d: Likewise. 147930 * testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise. 147931 * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise. 147932 * testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise. 147933 * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise. 147934 * testsuite/ld-x86-64/ilp32-4.d: Likewise. 147935 * testsuite/ld-x86-64/load1c.d: Likewise. 147936 * testsuite/ld-x86-64/load1d.d: Likewise. 147937 * testsuite/ld-x86-64/pr13082-2b.d: Likewise. 147938 * testsuite/ld-x86-64/pr14207.d: Likewise. 147939 * testsuite/ld-x86-64/pr18176.d: Likewise. 147940 * testsuite/ld-x86-64/pr19162.d: Likewise. 147941 * testsuite/ld-x86-64/pr19636-2d.d: Likewise. 147942 * testsuite/ld-x86-64/pr19636-2l.d: Likewise. 147943 * testsuite/ld-x86-64/pr20253-1d.d: Likewise. 147944 * testsuite/ld-x86-64/pr20253-1f.d: Likewise. 147945 * testsuite/ld-x86-64/pr20253-1j.d: Likewise. 147946 * testsuite/ld-x86-64/pr20253-1l.d: Likewise. 147947 * testsuite/ld-x86-64/report-reloc-1-x32.d: Likewise. 147948 * testsuite/ld-x86-64/report-reloc-1.d: Likewise. 147949 * testsuite/ld-x86-64/export-class.exp (x86_64_export_class_test): 147950 Pass $NO_DT_RELR_LDFLAGS to linker. 147951 * testsuite/ld-x86-64/x86-64.exp: Pass $NO_DT_RELR_LDFLAGS to 147952 linker for some tests. 147953 1479542022-01-12 H.J. Lu <hjl.tools@gmail.com> 147955 147956 elf: Add size_relative_relocs and finish_relative_relocs 147957 On some targets, the DT_RELR section size can be computed only after all 147958 symbols addresses can be determined. Set the preliminary DT_RELR section 147959 size before mapping sections to segments and set the final DT_RELR section 147960 size after regular symbol processing is done. 147961 147962 * elf-bfd.h (elf_backend_data): Add size_relative_relocs and 147963 finish_relative_relocs. 147964 * elf.c (_bfd_elf_map_sections_to_segments): Call 147965 size_relative_relocs if DT_RELR is enabled. 147966 * elflink.c (bfd_elf_final_link): Call finish_relative_relocs 147967 after regular symbol processing is finished if DT_RELR is enabled. 147968 * elfxx-target.h (elf_backend_size_relative_relocs): New. 147969 (elf_backend_finish_relative_relocs): Likewise. 147970 (elfNN_bed): Add elf_backend_size_relative_relocs and 147971 elf_backend_finish_relative_relocs. 147972 1479732022-01-12 H.J. Lu <hjl.tools@gmail.com> 147974 147975 ld: Initial DT_RELR support 147976 Add a -z pack-relative-relocs option to enable DT_RELR and create a 147977 relr.dyn section for DT_RELR. DT_RELR is implemented with the linker 147978 relaxation infrastructure, but it doesn't require the --relax option 147979 enabled. -z pack-relative-relocs implies -z combreloc. -z nocombreloc 147980 implies -z nopack-relative-relocs. 147981 147982 -z pack-relative-relocs is chosen over the similar option in lld, 147983 --pack-dyn-relocs=relr, to implement a glibc binary lockout mechanism 147984 with a special glibc version symbol, to avoid random crashes of DT_RELR 147985 binaries with the existing glibc binaries. 147986 147987 bfd/ 147988 147989 * elf-bfd.h (elf_link_hash_table): Add srelrdyn. 147990 * elflink.c (_bfd_elf_link_create_dynamic_sections): Create a 147991 .relr.dyn section for DT_RELR. 147992 147993 include/ 147994 147995 * bfdlink.h (bfd_link_info): Add enable_dt_relr. 147996 147997 ld/ 147998 147999 * News: Mention -z pack-relative-relocs and 148000 -z nopack-relative-relocs. 148001 * ld.texi: Document -z pack-relative-relocs and 148002 -z nopack-relative-relocs. 148003 * ldelf.c (ldelf_after_parse): Disable DT_RELR if not building 148004 PIE nor shared library. Add 3 spare dynamic tags for DT_RELR, 148005 DT_RELRSZ and DT_RELRENT. 148006 * ldlang.c (lang_relax_sections): Also enable relaxation if 148007 DT_RELR is enabled. 148008 * emulparams/elf32_x86_64.sh: Source dt-relr.sh. 148009 * emulparams/elf_i386.sh: Likewise. 148010 * emulparams/elf_x86_64.sh: Likewise. 148011 * emulparams/dt-relr.sh: New file. 148012 * scripttempl/elf.sc: Support .relr.dyn. 148013 1480142022-01-12 H.J. Lu <hjl.tools@gmail.com> 148015 148016 elf: Pass need_layout to _bfd_elf_map_sections_to_segments 148017 On some targets, the DT_RELR section size can be computed only after all 148018 symbols addresses can be determined. Update ldelf_map_segments to pass 148019 need_layout to _bfd_elf_map_sections_to_segments which will size DT_RELR 148020 section and set need_layout to true if the DT_RELR section size is changed. 148021 148022 bfd/ 148023 148024 * elf-bfd.h (_bfd_elf_map_sections_to_segments): Add a bool 148025 pointer argument. 148026 * elf.c (_bfd_elf_map_sections_to_segments): Add a bool pointer 148027 argument to indicate if section layout needs update. 148028 (assign_file_positions_for_load_sections): Pass NULL to 148029 _bfd_elf_map_sections_to_segments. 148030 * elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Pass 148031 NULL to _bfd_elf_map_sections_to_segments. 148032 148033 ld/ 148034 148035 * ldelfgen.c (ldelf_map_segments): Pass &need_layout to 148036 _bfd_elf_map_sections_to_segments. 148037 1480382022-01-12 H.J. Lu <hjl.tools@gmail.com> 148039 148040 elf: Add .relr.dyn to special_sections_r 148041 * elf.c (special_sections_r): Add .relr.dyn. 148042 1480432022-01-12 Andrew Burgess <aburgess@redhat.com> 148044 148045 gdb: add 'maint set/show gnu-source-highlight enabled' command 148046 In a later commit I want to address an issue with the Python pygments 148047 based code styling solution. As this approach is only used when the 148048 GNU Source Highlight library is not available, testing bugs in this 148049 area can be annoying, as it requires GDB to be rebuilt with use of GNU 148050 Source Highlight disabled. 148051 148052 This commit adds a pair of new maintenance commands: 148053 148054 maintenance set gnu-source-highlight enabled on|off 148055 maintenance show gnu-source-highlight enabled 148056 148057 these commands can be used to disable use of the GNU Source Highlight 148058 library, allowing me, in a later commit, to easily test bugs that 148059 would otherwise be masked by GNU Source Highlight being used. 148060 148061 I made this a maintenance command, rather than a general purpose 148062 command, as it didn't seem like this was something a general user 148063 would need to adjust. We can always convert the maintenance command 148064 to a general command later if needed. 148065 148066 There's no test for this here, but this feature will be used in a 148067 later commit. 148068 1480692022-01-12 Andrew Burgess <aburgess@redhat.com> 148070 148071 gdb: erase items from the source_cache::m_offset_cache 148072 The source_cache class has two member variables m_source_map, which 148073 stores the file contents, and m_offset_cache, which stores offsets 148074 into the file contents. 148075 148076 As source files are read the contents of the file, as well as the 148077 offset data, are stored in the cache using these two member variables. 148078 148079 Whenever GDB needs either the files contents, or the offset data, 148080 source_cache::ensure is called. This function looks for the file in 148081 m_source_map, and if it's found then this implies the file is also in 148082 m_offset_cache, and we're done. 148083 148084 If the file is not in m_source_map then GDB calls 148085 source_cache::get_plain_source_lines to open the file and read its 148086 contents. ::get_plain_source_lines also calculates the offset data, 148087 which is then inserted into m_offset_cache. 148088 148089 Back in ::ensure, the file contents are added into m_source_map. And 148090 finally, if m_source_map contains more than MAX_ENTRIES, an entry is 148091 removed from m_source_map. 148092 148093 The problem is entries are not removed from m_offset_cache at the same 148094 time. 148095 148096 This means that if a program contains enough source files, GDB will 148097 hold at most MAX_ENTRIES cached source file contents, but can contain 148098 offsets data for every source file. 148099 148100 Now, the offsets data is going to be smaller than the cached file 148101 contents, so maybe there's no harm here. But, when we reload the file 148102 contents we always recalculate the offsets data. And, when we 148103 ::get_line_charpos asking for offset data we still call ::ensure which 148104 will ends up loading and caching the file contents. 148105 148106 So, given the current code does the work of reloading the offset data 148107 anyway, we may as well save memory by capping m_offset_cache to 148108 MAX_ENTRIES just like we do m_source_map. 148109 148110 That's what this commit does. 148111 148112 There should be no user visible changes after this commit, except for 148113 ever so slightly lower memory usage in some cases. 148114 1481152022-01-12 Andrew Burgess <aburgess@redhat.com> 148116 148117 gdb: new 'maint flush source-cache' command 148118 This commit adds a new 'maint flush source-cache' command, this 148119 flushes the cache of source file contents. 148120 148121 After flushing GDB is forced to reread source files the next time any 148122 source lines are to be displayed. 148123 148124 I've added a test for this new feature. The test is a little weird, 148125 in that it modifies a source file after compilation, and makes use of 148126 the cache flush so that the changes show up when listing the source 148127 file. I'm not sure when such a situation would ever crop up in real 148128 life, but maybe we can imagine such cases. 148129 148130 In reality, this command is useful for testing the syntax highlighting 148131 within GDB, we can adjust the syntax highlighting settings, flush the 148132 cache, and then get the file contents re-highlighted using the new 148133 settings. 148134 1481352022-01-12 Andrew Burgess <aburgess@redhat.com> 148136 148137 gdb: rename lin-lwp to linux-nat in set/show debug 148138 Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug 148139 lin-lwp' to 'show debug linux-nat'. 148140 148141 I've updated the documentation and help text to match, as well as 148142 making it clear that the debug that is coming out relates to all 148143 aspects of Linux native inferior support, not just the LWP aspect of 148144 it. 148145 148146 The boundary between general "native" target debug, and the lwp 148147 specific part of that debug was always a little blurry, but the actual 148148 debug variable inside GDB is debug_linux_nat, and the print routine 148149 linux_nat_debug_printf, is used throughout the linux-nat.c file, not 148150 just for lwp related debug, so the new name seems to make more sense. 148151 1481522022-01-12 Clément Chigot <clement.chigot@atos.net> 148153 148154 ld: add hidden and internal visibility support for XCOFF 148155 This patch adds a primary support for hidden and internal visibility in 148156 GNU linker for XCOFF format. 148157 The protected visibility isn't yet supported. 148158 148159 PR 22085 148160 148161 bfd/ChangeLog: 148162 148163 * xcofflink.c (xcoff_dynamic_definition_p): Add hidden 148164 and internal visibility support. 148165 (xcoff_link_add_symbols): Likewise. 148166 (xcoff_auto_export_p): Likewise. 148167 (bfd_xcoff_export_symbol): Likewise. 148168 (xcoff_link_input_bfd): Likewise. 148169 148170 ld/ChangeLog: 148171 148172 * testsuite/ld-vsb/main.c: Adapt for XCOFF. 148173 * testsuite/ld-vsb/sh1.c: Likewse. 148174 * testsuite/ld-vsb/vsb.exp: Likewise. 148175 * testsuite/ld-vsb/visibility-1-xcoff-32.d: New test. 148176 * testsuite/ld-vsb/visibility-1-xcoff-64.d: New test. 148177 * testsuite/ld-vsb/visibility-2-xcoff-32.d: New test. 148178 * testsuite/ld-vsb/visibility-2-xcoff-64.d: New test. 148179 * testsuite/ld-vsb/xcoffvsb.dat: New test. 148180 1481812022-01-12 Clément Chigot <clement.chigot@atos.net> 148182 148183 ld/testsuite: prepare ld-elfvsb to support XCOFF 148184 A following patch will add visibility support in ld for XCOFF. Thus, 148185 ld-elfvsb is renamed ld-vsb and a suffix is added to files targeting only 148186 ELF format. 148187 148188 ld/ChangeLog: 148189 148190 * testsuite/ld-elfvsb: rename as ld-vsb. 148191 * testsuite/ld-elfvsb/hidden0.d: move to ld-vsb and rename with 148192 suffix -elf.d. 148193 * testsuite/ld-elfvsb/hidden1.d: Likewise. 148194 * testsuite/ld-elfvsb/hidden2.d: Likewise. 148195 * testsuite/ld-elfvsb/internal0.d: Likewise. 148196 * testsuite/ld-elfvsb/internal1.d: Likewise. 148197 * testsuite/ld-elfvsb/protected0.d: Likewise. 148198 * testsuite/ld-elfvsb/protected1.d: Likewise. 148199 1482002022-01-12 Clément Chigot <clement.chigot@atos.net> 148201 148202 gas: add visibility support using GNU syntax on XCOFF 148203 In order to ease port of GNU assembly code and especially ld testsuite, 148204 this patch allows XCOFF to accept the usual GNU syntax for visibility. 148205 148206 PR 22085 148207 148208 gas/ChangeLog: 148209 148210 * config/tc-ppc.c (ppc_GNU_visibility): New function. 148211 * testsuite/gas/ppc/aix.exp: Add new tests. 148212 * testsuite/gas/ppc/xcoff-visibility-2-32.d: New test. 148213 * testsuite/gas/ppc/xcoff-visibility-2-64.d: New test. 148214 * testsuite/gas/ppc/xcoff-visibility-2.s: New test. 148215 1482162022-01-12 Clément Chigot <clement.chigot@atos.net> 148217 148218 gas: add visibility support for XCOFF 148219 XCOFF assembly defines the visibility using an additional argument 148220 on several pseudo-ops: .globl, .weak, .extern and .comm. 148221 This implies that .globl and .weak syntax is different than the 148222 usual GNU syntax. But we want to provide compatibility with AIX 148223 assembler, especially because GCC is generating the visibility 148224 using this XCOFF syntax. 148225 148226 PR 22085 148227 148228 bfd/ChangeLog: 148229 148230 * coffcode.h (coff_write_object_contents): Change XCOFF header 148231 vstamp field to 2. 148232 * coffgen.c (coff_print_symbol): Increase the size for n_type. 148233 148234 gas/ChangeLog: 148235 148236 * config/tc-ppc.c (ppc_xcoff_get_visibility): New function. 148237 (ppc_globl): New function. 148238 (ppc_weak): New function. 148239 (ppc_comm): Add visibility field support. 148240 (ppc_extern): Likewise. 148241 * testsuite/gas/all/cofftag.d: Adjust to new n_type size 148242 providing by objdump. 148243 * testsuite/gas/ppc/test1xcoff32.d: Likewise. 148244 * testsuite/gas/ppc/aix.exp: Add new tests. 148245 * testsuite/gas/ppc/xcoff-visibility-1-32.d: New test. 148246 * testsuite/gas/ppc/xcoff-visibility-1-64.d: New test. 148247 * testsuite/gas/ppc/xcoff-visibility-1.s: New test. 148248 148249 include/ChangeLog: 148250 148251 * coff/internal.h (SYM_V_INTERNAL, SYM_V_HIDDEN, 148252 SYM_V_PROTECTED, SYM_V_EXPORTED, SYM_V_MASK): New defines. 148253 * coff/xcoff.h (struct xcoff_link_hash_entry): Add visibility 148254 field. 148255 148256 ld/ChangeLog: 148257 148258 * testsuite/ld-pe/pr19803.d: Adjust to new n_type size 148259 providing by objdump. 148260 1482612022-01-12 Hans-Peter Nilsson <hp@axis.com> 148262 148263 objdump, readelf: Emit "CU:" format only when wide output is requested 148264 As pre-approved by Alan in 148265 https://sourceware.org/pipermail/binutils/2021-September/118019.html 148266 and I believe people have run into getting testsuite failures for 148267 test-environments with "long" directory names, at least once more 148268 since that time. Enough. I grepped the gas, binutils and ld 148269 testsuites for "CU:" to catch target-specific occurrences, but I 148270 noticed none. I chose to remove "CU:" on the objdump tests instead of 148271 changing options to get the wide format, so as to keep the name of the 148272 test consistent with actual options; but added it to the readelf 148273 options for the gas test as I believe the "CU:" format is preferable. 148274 148275 Tested for cris-elf and native x86_64-pc-linux-gnu. 148276 148277 binutils: 148278 * dwarf.c (display_debug_lines_decoded): Don't check the 148279 string length of the directory, instead emit the "CU: dir/name" 148280 format only if wide output is requested. 148281 * testsuite/binutils-all/dw5.W, testsuite/binutils-all/objdump.WL: 148282 Adjust accordingly. 148283 148284 gas: 148285 * testsuite/gas/elf/dwarf-5-loc0.d: Add -W to readelf options. 148286 1482872022-01-12 Alan Modra <amodra@gmail.com> 148288 148289 Set SEC_ELF_REVERSE_COPY earlier 148290 For the sake of DT_RELR. 148291 148292 bfd/ 148293 * elflink.c (elf_link_input_bfd): Don't set SEC_ELF_REVERSE_COPY 148294 here. Move sanity checks to reverse copying code. 148295 ld/ 148296 * ldlang.c (lang_add_section): Set SEC_ELF_REVERSE_COPY for 148297 .ctors/.dtors in .init_array/.fini_array. 148298 1482992022-01-12 Tiezhu Yang <yangtiezhu@loongson.cn> 148300 148301 gdb: testsuite: fix wrong comment in gdb.base/charset.c 148302 In gdb/testsuite/gdb.base/charset.c, use "IBM1047" instead of "EBCDIC" 148303 to fix the wrong comment. 148304 1483052022-01-12 Tiezhu Yang <yangtiezhu@loongson.cn> 148306 148307 gdb: testsuite: fix failed testcases in gdb.base/charset.exp 148308 In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127 148309 when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is 148310 char, this will change the value due to sign extension. 148311 148312 For example, ebcdic_us_string[7] will be -63 instead of the original 193 in 148313 EBCDIC-US. 148314 148315 Make the type of string[] as unsigned char to fix the following six failed 148316 testcases: 148317 148318 $ grep FAIL gdb/testsuite/gdb.sum 148319 FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US 148320 FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US 148321 FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US 148322 FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047 148323 FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047 148324 FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047 148325 1483262022-01-12 GDB Administrator <gdbadmin@sourceware.org> 148327 148328 Automatic date update in version.in 148329 1483302022-01-11 Fangrui Song <maskray@google.com> 148331 148332 ar: Add --thin for creating thin archives 148333 In many ar implementations (FreeBSD, elfutils, etc), -T has the X/Open 148334 System Interface specified semantics. Therefore -T for thin archives is 148335 not recommended for portability. -T is deprecated without diagnostics. 148336 148337 PR binutils/28759 148338 * ar.c (long_options): Add --thin. 148339 (usage) Add --thin. Deprecate -T without diagnostics. 148340 * doc/binutils.texi: Add doc. 148341 * NEWS: Mention --thin. 148342 * binutils/testsuite/binutils-all/ar.exp: Add tests. 148343 1483442022-01-11 Martin Storsj <martin@martin.st> 148345 148346 Fix multiple problems with DLL generation. 148347 ld * pe-dll.c (make_head): Prefix the symbol name with the dll name. 148348 (make_tail, make_one, make_singleton_name_thunk): Likewise. 148349 (make_import_fixup_entry, make_runtime_pseudo_reloc): Likewise. 148350 (pe_create_runtime_relocator_reference): Likewise. 148351 (pe_dll_generate_implib): Set dll_symname_len. 148352 (pe_process_import_defs): Likewise. 148353 148354 binutils 148355 * dlltool.c (main): If a prefix has not been provided, attempt to 148356 use a deterministic one based upon the dll name. 148357 1483582022-01-11 Jan Beulich <jbeulich@suse.com> 148359 148360 gas/doc: mention quoted symbol names 148361 1483622022-01-11 Andrew Burgess <aburgess@redhat.com> 148363 148364 gdbsupport: regenerate Makefile.in 148365 I had cause to regenerate gdbsupport/Makefile.in, and noticed some 148366 unexpected changes in the copyright header dates. 148367 148368 I suspect that this was caused by the end of year date range update 148369 process. 148370 148371 The Makefile.in contains two date ranges. The first range appears to 148372 be the date range for the version of automake being used, that is the 148373 range runs up to 2017 only, when automake 1.15.1 was released. 148374 148375 The second date range in Makefile.in represents the date range for the 148376 generated file, and so, now runs up to 2022. 148377 148378 Anyway, this is the result of running autoreconf (using automake 148379 1.15.1) in the gdbsupport directory. 148380 1483812022-01-11 GDB Administrator <gdbadmin@sourceware.org> 148382 148383 Automatic date update in version.in 148384 1483852022-01-10 Clément Chigot <clement.chigot@atos.net> 148386 148387 XCOFF: add support for TLS relocations on hidden symbols 148388 This patch adds support for TLS relocation targeting C_HIDEXT symbols. 148389 In gas, TLS relocations, except R_TLSM and R_TLMSL, must keep the value 148390 of their target symbol. 148391 In ld, it simply ensures that internal TLS symbols are added to the 148392 linker hash table for xcoff_reloc_type_tls. 148393 148394 It also improves the tests made by both. 148395 148396 bfd/ChangeLog: 148397 148398 * coff-rs6000.c (xcoff_howto_table): Fix name of R_TLSML. 148399 (xcoff_reloc_type_tls): Replace the error when h is NULL by 148400 an assert. 148401 (xcoff_complain_overflow_unsigned_func): Adjust comments. 148402 * coff64-rs6000.c (xcoff64_howto_table): Fix name of R_TLSML. 148403 * xcofflink.c (xcoff_link_add_symbols_to_hash_table): New 148404 function. 148405 (xcoff_link_add_symbols): Add C_HIDEXT TLS symbols to the linker 148406 hash table. 148407 148408 gas/ChangeLog: 148409 148410 * config/tc-ppc.c (md_apply_fix): Enable support for TLS 148411 relocation over internal symbols. 148412 * testsuite/gas/ppc/aix.exp: Replace xcoff-tlms by xcoff-tls. 148413 * testsuite/gas/ppc/xcoff-tlsm-32.d: Removed. 148414 * testsuite/gas/ppc/xcoff-tlsm-64.d: Removed. 148415 * testsuite/gas/ppc/xcoff-tlsm.s: Removed. 148416 * testsuite/gas/ppc/xcoff-tls-32.d: New test. 148417 * testsuite/gas/ppc/xcoff-tls-64.d: New test. 148418 * testsuite/gas/ppc/xcoff-tls.s: New test. 148419 148420 ld/ChangeLog: 148421 148422 * testsuite/ld-powerpc/aix52.exp: Improve aix-tls-reloc test. 148423 * testsuite/ld-powerpc/aix-tls-reloc.s: Likewise. 148424 * testsuite/ld-powerpc/aix-tls-reloc-32.d: Removed. 148425 * testsuite/ld-powerpc/aix-tls-reloc-64.d: Removed. 148426 * testsuite/ld-powerpc/aix-tls-reloc-32.dd: New test. 148427 * testsuite/ld-powerpc/aix-tls-reloc-32.dt: New test. 148428 * testsuite/ld-powerpc/aix-tls-reloc-64.dd: New test. 148429 * testsuite/ld-powerpc/aix-tls-reloc-64.dt: New test. 148430 1484312022-01-10 Tiezhu Yang <yangtiezhu@loongson.cn> 148432 148433 gdb: add Tiezhu Yang to MAINTAINERS 148434 1484352022-01-10 Tom Tromey <tom@tromey.com> 148436 148437 Reduce use of unfiltered output in Darwin code 148438 The Darwin code uses unfiltered output liberally. This patch changes 148439 this code to send some output to gdb_stdlog (in some cases via the use 148440 of debug_prefixed_printf_cond_nofunc), or to gdb_stderr, or to simply 148441 switch to filtered output. 148442 148443 Note that I didn't switch inferior_debug to use 148444 debug_prefixed_printf_cond_nofunc, because that would affect the 148445 output by removing the information about the inferior. I wasn't sure 148446 if this was important or not, so I left it in. 148447 148448 v2 of this patch uses warning rather than prints to gdb_stderr, and 148449 removes some trailing whitespace. 148450 148451 I can't compile this patch, so it's "best effort". 148452 1484532022-01-10 GDB Administrator <gdbadmin@sourceware.org> 148454 148455 Automatic date update in version.in 148456 1484572022-01-09 GDB Administrator <gdbadmin@sourceware.org> 148458 148459 Automatic date update in version.in 148460 1484612022-01-08 Andrew Burgess <aburgess@redhat.com> 148462 148463 gdb/hurd: handle inferiors exiting 148464 While testing on GNU/Hurd (i386) I noticed that GDB crashes when an 148465 inferior exits, with this error: 148466 148467 inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. 148468 148469 The problem appears to be in gnu_nat_target::wait. 148470 148471 We always set inferior_ptid to null_ptid before calling target_wait, 148472 this has been the case since the multi-target changes were made to GDB 148473 in commit: 148474 148475 commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 148476 Date: Fri Jan 10 20:06:08 2020 +0000 148477 148478 Multi-target support 148479 148480 With follow up changes in commit: 148481 148482 commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493 148483 Date: Thu Jan 30 14:35:40 2020 +0000 148484 148485 gdb/remote: Restore support for 'S' stop reply packet 148486 148487 Unfortunately, the GNU/Hurd target is still relying on the value of 148488 inferior_ptid in the case where an inferior exits - we return the 148489 value of inferior_ptid as the pid of the process that exited. This 148490 was fine in the single target world, where inferior_ptid identified 148491 the one running inferior, but this is no longer good enough. 148492 148493 Instead, we should return a ptid containing the pid of the process 148494 that exited, as obtained from the wait event, and this is what this 148495 commit does. 148496 148497 I've not run the full testsuite on GNU/Hurd as there appear to be lots 148498 of other issues with this target that makes running the full testsuite 148499 very painful, but I think this looks like a small easy improvement. 148500 1485012022-01-08 Tom Tromey <tom@tromey.com> 148502 148503 Add explicit check for nullptr to target_announce_attach 148504 Lancelot pointed out that target_announce_attach was missing an 148505 explicit check against nullptr. This patch adds it. 148506 1485072022-01-08 Hannes Domani <ssbssa@yahoo.de> 148508 148509 Add _sigsys info to siginfo struct 148510 This patch adds information about _sigsys structure from newer 148511 kernels, so that $_siginfo decoding can show information about 148512 _sigsys, making it easier for developers to debug seccomp failures. 148513 Requested in PR gdb/24283. 148514 148515 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283 148516 1485172022-01-08 Tiezhu Yang <yangtiezhu@loongson.cn> 148518 148519 gdb: testsuite: show print array-indexes after set in arrayidx.exp 148520 Add "show print array-indexes" testcases after set print array-indexes 148521 to off or on. 148522 148523 Without this patch: 148524 148525 PASS: gdb.base/arrayidx.exp: set print array-indexes to off 148526 PASS: gdb.base/arrayidx.exp: print array with array-indexes off 148527 PASS: gdb.base/arrayidx.exp: set print array-indexes to on 148528 PASS: gdb.base/arrayidx.exp: print array with array-indexes on 148529 148530 With this patch: 148531 148532 PASS: gdb.base/arrayidx.exp: set print array-indexes to off 148533 PASS: gdb.base/arrayidx.exp: show print array-indexes is off 148534 PASS: gdb.base/arrayidx.exp: print array with array-indexes off 148535 PASS: gdb.base/arrayidx.exp: set print array-indexes to on 148536 PASS: gdb.base/arrayidx.exp: show print array-indexes is on 148537 PASS: gdb.base/arrayidx.exp: print array with array-indexes on 148538 1485392022-01-08 H.J. Lu <hjl.tools@gmail.com> 148540 148541 ld: Extract _bfd_elf_link_iterate_on_relocs 148542 DT_RELR encodes consecutive R_*_RELATIVE relocations in GOT (the global 148543 offset table) and data sections in a compact format: 148544 148545 https://groups.google.com/g/generic-abi/c/bX460iggiKg 148546 148547 On some targets, R_*_RELATIVE relocations are counted and the GOT offsets 148548 are allocated when setting the dynamic section sizes after seeing all 148549 relocations. R_*_RELATIVE relocations are generated while relocating 148550 sections after section layout has been finalized. 148551 148552 To prepare for DT_RELR implementation on these targets, extract 148553 _bfd_elf_link_iterate_on_relocs from _bfd_elf_link_check_relocs so 148554 that a backend can scan relocations in elf_backend_always_size_sections 148555 148556 For x86 targets, the old check_relocs is renamed to scan_relocs and a 148557 new check_relocs is added to chek input sections and create dynamic 148558 relocation sections so that they will be mapped to output sections. 148559 scan_relocs is now called from elf_backend_always_size_sections. 148560 148561 Since relocations are scanned after __start, __stop, .startof. and 148562 .sizeof. symbols have been finalized on x86, __[start|stop]_SECNAME for 148563 --gc-sections -z start-stop-gc are now zero when all SECNAME sections 148564 been garbage collected. This is no need for elf_x86_start_stop_gc_p. 148565 148566 bfd/ 148567 148568 * elf-bfd.h (_bfd_elf_link_iterate_on_relocs): New. 148569 * elf32-i386.c (elf_i386_convert_load_reloc): Don't call 148570 elf_x86_start_stop_gc_p. 148571 (elf_i386_check_relocs): Renamed to ... 148572 (elf_i386_scan_relocs): This. Don't call 148573 _bfd_elf_make_dynamic_reloc_section. 148574 (elf_i386_always_size_sections): New. 148575 (elf_backend_check_relocs): Removed. 148576 (elf_backend_always_size_sections): New. 148577 * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Don't call 148578 elf_x86_start_stop_gc_p. 148579 (elf_x86_64_check_relocs): Renamed to ... 148580 (elf_x86_64_scan_relocs): This. Don't call 148581 _bfd_elf_make_dynamic_reloc_section. 148582 (elf_x86_64_always_size_sections): New. 148583 (elf_backend_check_relocs): Removed. 148584 (elf_backend_always_size_sections): New. 148585 * elflink.c (elf_link_check_or_scan_relocs): 148586 New. Extracted from _bfd_elf_link_check_relocs. 148587 (_bfd_elf_link_check_relocs): Call elf_link_check_or_scan_relocs. 148588 * elfxx-x86.c (_bfd_x86_elf_check_relocs): New. 148589 * elfxx-x86.h (X86_64_NEED_DYNAMIC_RELOC_TYPE_P): New. 148590 (I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise. 148591 (X86_NEED_DYNAMIC_RELOC_TYPE_P): Likewise. 148592 (_bfd_x86_elf_check_relocs): Likewise. 148593 (elf_backend_check_relocs): Likewise. 148594 (elf_backend_always_size_sections): Removed. 148595 (elf_x86_start_stop_gc_p): Likewise. 148596 148597 ld/ 148598 148599 * testsuite/ld-i386/pr27491-1a.d: Updated. 148600 * testsuite/ld-x86-64/pr27491-1a.d: Likewise. 148601 1486022022-01-08 GDB Administrator <gdbadmin@sourceware.org> 148603 148604 Automatic date update in version.in 148605 1486062022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148607 148608 gdb/testsuite: Remove duplicates from gdb.mi/mi-catch-load.exp 148609 When I run the testsuite, I have: 148610 148611 Running .../gdb/testsuite/gdb.mi/mi-catch-load.exp ... 148612 DUPLICATE: gdb.mi/mi-catch-load.exp: breakpoint at main 148613 DUPLICATE: gdb.mi/mi-catch-load.exp: mi runto main 148614 148615 Fix by grouping the various phases in with_test_prefix blocks. Since 148616 the tests now have a prefix, remove the manually written prefixes in 148617 testnames. 148618 148619 Also change some messages with the pattern "(timeout) $testname" into 148620 "$estname (timeout)" since tools will handle this as $testname[1] (which 148621 is what we want in this particular scenario). 148622 148623 Tested on x86_64-linux. 148624 148625 [1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages 148626 1486272022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148628 148629 gdb/testsuite: Remove duplicates from gdb.threads/staticthreads.ex 148630 When running the testsuite, I have: 148631 148632 Running .../gdb/testsuite/gdb.threads/staticthreads.exp ... 148633 DUPLICATE: gdb.threads/staticthreads.exp: couldn't compile staticthreads.c: unrecognized error 148634 148635 Fix by using foreach_with_prefix instead of foreach when preparing the 148636 test case. 148637 148638 Testeed on x86_64-linux both in a setup where the test fails to prepare 148639 and in a setup where the test fails to setup. 148640 1486412022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148642 148643 gdb/testsuite: Remove duplicates from gdb.mi/mi-language.exp 148644 When running the testsuite, I have: 148645 148646 Running .../gdb/testsuite/gdb.mi/mi-language.exp ... 148647 DUPLICATE: gdb.mi/mi-language.exp: set lang ada 148648 148649 This is due to an erroneous explicit test name. This explicit test name 148650 also happens to be useless (at least it would have been if it was 148651 correct) since it only repeats the command, so just remove the explicit 148652 test name and let the command be used as default test name. Also remove 148653 explicit test name at another location in the file since it also just 148654 repeat the command. 148655 148656 Tested on x86_64-linux. 148657 1486582022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148659 148660 gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop-exit.exp 148661 When running the testsuite, I have: 148662 148663 Running .../gdb/testsuite/gdb.mi/mi-nonstop-exit.exp ... 148664 DUPLICATE: gdb.mi/mi-nonstop-exit.exp: breakpoint at main 148665 DUPLICATE: gdb.mi/mi-nonstop-exit.exp: mi runto main 148666 148667 This test runs the same sequence of operations twice. Refactor the code 148668 by running both of those sequences within a foreach_with_prefix block to 148669 ensure that the commands have unique test names. 148670 148671 Tested on x86_64-linux. 148672 1486732022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148674 148675 gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop.exp 148676 When running the testsuite, I have: 148677 148678 Running .../gdb/testsuite/gdb.mi/mi-nonstop.exp ... 148679 DUPLICATE: gdb.mi/mi-nonstop.exp: check varobj, w1, 1 148680 DUPLICATE: gdb.mi/mi-nonstop.exp: stacktrace of stopped thread 148681 148682 Fix by adjusting the problematic test names. 148683 148684 Tested on x86_64-linux. 148685 1486862022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148687 148688 gdb/testsuite: Remove duplicates from gdb.mi/mi-nsthrexec.exp 148689 When running the testsuite, I have: 148690 148691 Running .../gdb/testsuite/gdb.mi/mi-nsthrexec.exp ... 148692 DUPLICATE: gdb.mi/mi-nsthrexec.exp: breakpoint at main 148693 148694 Fix by adjusting the duplicated test name. 148695 148696 Tested on x86_64-linux. 148697 1486982022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148699 148700 gdb/testsuite: Remove duplicates from gdb.base/watchpoints.exp 148701 When running the testsuite, I have: 148702 148703 Running ../gdb/testsuite/gdb.base/watchpoints.exp ... 148704 DUPLICATE: gdb.base/watchpoints.exp: watchpoint hit, first time 148705 148706 Fix by adjusting the test names where appropriate. 148707 148708 Tested on x86_64-linux. 148709 1487102022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148711 148712 gdb/testsuite: Remove duplicates from gdb.base/nested-subp2.exp 148713 When running the testsuite, I have: 148714 148715 Running .../gdb/testsuite/gdb.base/nested-subp2.exp ... 148716 DUPLICATE: gdb.base/nested-subp2.exp: continue to the STOP marker 148717 DUPLICATE: gdb.base/nested-subp2.exp: print c 148718 DUPLICATE: gdb.base/nested-subp2.exp: print count 148719 148720 Fix by using with_test_prefix to differentiate the test that are 148721 performed at different points during the execution of the debuggee. 148722 148723 Tested on x86_64-linux. 148724 1487252022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148726 148727 gdb/testsuite: Remove duplicates from gdb.base/call-signal-resume.exp 148728 When running the testsuite, I have: 148729 148730 Running .../gdb/testsuite/gdb.base/call-signal-resume.exp ... 148731 DUPLICATE: gdb.base/call-signal-resume.exp: dummy stack frame number 148732 DUPLICATE: gdb.base/call-signal-resume.exp: set confirm off 148733 DUPLICATE: gdb.base/call-signal-resume.exp: return 148734 148735 This is due to the fact that a pattern was probably copy/pasted to 148736 re-use the logic while not adjusting the test names to avoid the 148737 duplication. 148738 148739 Fix by removing the redundant tests ('set confirm off' only needs to be 148740 used once) and adjusting the test names where appropriate. 148741 148742 Tested on x86_64-linux. 148743 1487442022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148745 148746 gdb/testsuite: Remove duplicates from gdb.base/pointers.exp 148747 When I run the testsuite, I have : 148748 148749 Running .../gdb/testsuite/gdb.base/pointers.exp ... 148750 DUPLICATE: gdb.base/pointers.exp: pointer assignment 148751 148752 Fix by placing the sections with duplication in with_test_prefix blocks. 148753 This removes the duplication and gives a better organization the file. 148754 148755 Tested on x86_64-linux. 148756 Co-Authored-By: Pedro Alves <pedro@palves.net> 148757 1487582022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148759 148760 gdb/testsuite: Remove duplicates from gdb.base/unload.exp 148761 When running the testsuite, I have: 148762 148763 Running .../gdb/testsuite/gdb.base/unload.exp ... 148764 DUPLICATE: gdb.base/unload.exp: continuing to unloaded libfile 148765 148766 Fix by adjusting the test name. 148767 148768 Tested on x86_64-linux. 148769 1487702022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148771 148772 gdb/testsuite: Remove duplicates from gdb.base/define-prefix.exp 148773 When running the testsuite, I have: 148774 148775 Running .../gdb/testsuite/gdb.base/define-prefix.exp ... 148776 DUPLICATE: gdb.base/define-prefix.exp: define user command: ghi-prefix-cmd 148777 148778 Fix by adjusting test names. 148779 148780 Tested on x86_64-linux. 148781 1487822022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148783 148784 gdb/testsuite: Remove duplicates from gdb.base/funcargs.exp 148785 When running the testsuite, I have: 148786 148787 Running .../gdb/testsuite/gdb.base/funcargs.exp ... 148788 DUPLICATE: gdb.base/funcargs.exp: run to call2a 148789 148790 Fix by using proc_with_prefix instead on plain proc to create logical 148791 function blocks. 148792 148793 Tested on x86_64-linux. 148794 1487952022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148796 148797 gdb/testsuite: Remove duplicates from gdb.base/shlib-call.exp 148798 When I run the testsuite, I have: 148799 148800 Running .../gdb/testsuite/gdb.base/shlib-call.exp ... 148801 DUPLICATE: gdb.base/shlib-call.exp: print g 148802 DUPLICATE: gdb.base/shlib-call.exp: set print sevenbit-strings 148803 DUPLICATE: gdb.base/shlib-call.exp: set print address off 148804 DUPLICATE: gdb.base/shlib-call.exp: set width 0 148805 DUPLICATE: gdb.base/shlib-call.exp: continue until exit 148806 148807 Fix by adjusting the test names when required, and by removing 148808 un-necessary commands. 148809 148810 While at it, do some cleanup: 148811 - Replace an explicit GDB restart sequence with a call to clean_restart. 148812 - Remove trailing whitespaces. 148813 - Use $gdb_test_name in gdb_test_multiple. 148814 148815 Tested on x86_64-linux. 148816 1488172022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148818 148819 gdb/testsuite: Remove duplicates from gdb.base/set-cfd.exp 148820 When running the testsuite, I have: 148821 148822 Running .../gdb/testsuite/gdb.base/set-cwd.exp ... 148823 DUPLICATE: gdb.base/set-cwd.exp: test_cwd_reset: continue to breakpoint: break-here 148824 148825 Fix by moving the tests after the 'runto_main' within the same 148826 with_test_prefix scope. 148827 148828 While at it, I fix some indentation issues. 148829 148830 Tested on x86_64-linux. 148831 1488322022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148833 148834 gdb/testsuite: Remove duplicates from gdb.base/exprs.exp 148835 When running the testsuite, I have: 148836 148837 Running .../gdb/testsuite/gdb.base/exprs.exp ... 148838 DUPLICATE: gdb.base/exprs.exp: \$[0-9]* = red (setup) 148839 148840 Fix by using with_test_prefix where appropriate. 148841 148842 Tested on x86_64-linux. 148843 1488442022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148845 148846 gdb/testsuite: Remove duplicates from gdb.base/readline.exp 148847 When running the testsuite, I have: 148848 148849 Running .../gdb/testsuite/gdb.base/readline.exp ... 148850 DUPLICATE: gdb.base/readline.exp: Simple operate-and-get-next - final prompt 148851 148852 Fix by adjusting the prefix given to the second 'simple' call to 148853 operate_and_get_next. 148854 148855 Tested on x86_64-linux. 148856 1488572022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148858 148859 gdb/testsuite: Remove duplicates from gdb.base/pretty-array.exp 148860 When I run the testsuite, I have: 148861 148862 Running .../gdb/testsuite/gdb.base/pretty-array.exp ... 148863 DUPLICATE: gdb.base/pretty-array.exp: print nums 148864 DUPLICATE: gdb.base/pretty-array.exp: print nums 148865 148866 Fix by giving a name to the test cases. 148867 148868 Tested on x86_64-linux. 148869 1488702022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148871 148872 gdb/testsuite: Remove duplicates from gdb.base/ui-redirect.exp 148873 When running the testsuite, I have: 148874 148875 Running .../gdb/testsuite/gdb.base/ui-redirect.exp ... 148876 DUPLICATE: gdb.base/ui-redirect.exp: redirect while already logging: set logging redirect off 148877 148878 Fix by moving the first 'set logging redirect off' to the end of the 148879 previous [with_test_prefix] test block. The statement's purpose is to 148880 clean the on flag set in this previous block, so moving it there makes 148881 sense and does not change the sequence of commands in the test file. 148882 148883 Tested on x86_64-linux. 148884 1488852022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148886 148887 gdb: completion-support.exp: improve leading whitespace support 148888 There is a expect support library in the source tree designed to help 148889 developers test the auto-completion capabilities of GDB. 148890 148891 One of the functions is test_gdb_complete_unique_re. It is used 148892 (usually indirectly via test_gdb_complete_unique) to test that a given 148893 input line is completed as a given output line. The test checks for two 148894 ways to do the completion: using tab-completion, or using the 148895 'complete' command. To do this, calls to two dedicated functions are 148896 performed. If we omit few details, we can consider that a call to 148897 148898 test_gdb_complete_unique $input $expected 148899 148900 is equivalent to the two following calls: 148901 148902 test_gdb_complete_tab_unique $input $expected 148903 test_gdb_complete_cmd_unique $input $expected 148904 148905 When using the tab-completion, everything works as expected, but some 148906 care must be taken when using the 'complete' command if the given input 148907 has leading whitespaces. In such situation, the output of the 148908 'complete' command will drop the leading whitespaces. 148909 148910 The current approach is that in such situation, the input and expected 148911 outputs are right trimmed (i.e. all leading whitespaces are removed) 148912 when performing the command completion check. 148913 148914 This means that the following call: 148915 148916 test_gdb_complete_unique " $input" " $expected" 148917 148918 is almost equivalent to (again, omitting few details and arguments): 148919 148920 test_gdb_complete_tab_unique " $input" " $expected" 148921 test_gdb_complete_cmd_unique "$input" "$expected" 148922 148923 This approach comes with a problem that we encounter when running the 148924 tests in complete-empty.exp. When doing so, we have: 148925 148926 Running .../gdb/testsuite/gdb.base/complete-empty.exp ... 148927 DUPLICATE: gdb.base/complete-empty.exp: empty-input-line: cmd complete "" 148928 148929 This is because the test file does something like: 148930 148931 test_gdb_complete_unique "" "!" " " 1 148932 test_gdb_complete_unique " " " !" " " 1¬ 148933 148934 which, if we do the substitution introduced above is equivalent to: 148935 148936 test_gdb_complete_tab_unique "" "!" 148937 test_gdb_complete_cmd_unique "" "!" 148938 test_gdb_complete_tab_unique " " " !" 148939 test_gdb_complete_cmd_unique "" "!" 148940 148941 We see that the lines 2 and 4 are now the same, and for this reason the 148942 testing framework complains about DUPLICATE test names. 148943 148944 To fix that, this commit proposes that instead of left trimming both 148945 input and expected outputs, only the expected output is trimmed. 148946 148947 Care must be taken in the case the completion gives more possibilities 148948 than allowed by the max-completions setting. In this case, the input 148949 will be repeated in the output in its left trimmed version. This commit 148950 also ensures that this is taken care of. 148951 148952 With this commit, the gdb.base/complete-empty.exp still passes all its 148953 tests but does not report the DUPLICATE anymore. 148954 148955 Tested on x86_64-linux. 148956 1489572022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148958 148959 gdb/testsuite: Remove duplicates from gdb.base/subst.exp 148960 When I run the testsuite, I have: 148961 148962 Running .../gdb/testsuite/gdb.base/subst.ex ... 148963 DUPLICATE: gdb.base/subst.exp: unset substitute-path from, no rule entered yet 148964 148965 Fix by adjusting the problematic test name. 148966 148967 Tested on x86_64-linux. 148968 1489692022-01-07 Pedro Alves <pedro@palves.net> 148970 148971 gdb/testsuite: Remove duplicates from gdb.base/dfp-exprs.exp 148972 When I run the testsuite, I have: 148973 148974 Running ../gdb/testsuite/gdb.base/dfp-exprs.exp ... 148975 DUPLICATE: gdb.base/dfp-exprs.exp: p 1.2dl < 1.3df 148976 148977 Replace hand-written tests checking various comparison operators between 148978 various decimal floating point types with a loop to programmatically 148979 generate all the combinations. This removes the need to eyeball for all 148980 suffixes, which lead to the original duplication. 148981 148982 Also add a lot more combinations, testing all comparison operators 148983 comprehensively. The result is 262 unique tests vs 104 before this 148984 patch. 148985 148986 Tested on x86_86-linux. 148987 148988 Change-Id: Id215a3d610aa8e032bf06ee160b5e3aed4a92d1e 148989 1489902022-01-07 Lancelot SIX <lsix@lancelotsix.com> 148991 148992 gdb/testsuite: Remove duplicates from gdb.base/ptype.exp 148993 When running the testsuite, I have: 148994 148995 Running .../gdb/testsuite/gdb.base/ptype.exp ... 148996 DUPLICATE: gdb.base/ptype.exp: ptype the_highest 148997 DUPLICATE: gdb.base/ptype.exp: list intfoo 148998 DUPLICATE: gdb.base/ptype.exp: list charfoo 148999 149000 Fix by adjusting the offending test names. 149001 149002 Tested on x86_64-linux. 149003 1490042022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149005 149006 gdb/testsuite: Remove duplicates from gdb.base/dfp-test.exp 149007 When running the testsuite, I have: 149008 149009 Running .../gdb/testsuite/gdb.base/dfp-test.exp ... 149010 DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number 149011 DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number 149012 DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number 149013 DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number 149014 149015 Fix by using proc_with_prefix where appropriate. 149016 149017 Tested on x86_64-linux. 149018 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> 149019 1490202022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149021 149022 gdb/testsuite: Remove duplicates from gdb.base/del.exp 149023 When running the testsuite, I have: 149024 149025 Running .../gdb/testsuite/gdb.base/del.exp ... 149026 DUPLICATE: gdb.base/del.exp: info break after removing break on main 149027 149028 Refactor slightly this test to run the various configurations under 149029 foreach_with_prefix so each variant is automatically prefixed, ensuring 149030 that the forgotten custom test name cannot happen. 149031 149032 Tested on x86_64-linux. 149033 1490342022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149035 149036 gdb/testsuite: Remove duplicates from gdb.base/solib-display.exp 149037 When running the testsuite, I have: 149038 149039 Running .../gdb/testsuite/gdb.base/solib-display.exp ... 149040 DUPLICATE: gdb.base/solib-display.exp: NO: break 25 149041 DUPLICATE: gdb.base/solib-display.exp: NO: continue 149042 DUPLICATE: gdb.base/solib-display.exp: IN: break 25 149043 DUPLICATE: gdb.base/solib-display.exp: IN: continue 149044 DUPLICATE: gdb.base/solib-display.exp: SEP: break 25 149045 DUPLICATE: gdb.base/solib-display.exp: SEP: continue 149046 149047 The 'break 25' appears because the test inserts two breakpoints at the 149048 same location. Fix this by only inserting the breakpoint once. 149049 149050 Fix the 'continue' DUPLICATE by giving a phony name to the second 149051 continue: 'continue two'. 149052 149053 While at it, this commit also removes a trailing space. 149054 149055 Tested on x86_64-linux. 149056 1490572022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149058 149059 gdb/testsuite: Remove duplicates from gdb.base/decl-before-def.exp 149060 When running the testsuite, I have: 149061 149062 Running .../gdb/testsuite/gdb.base/decl-before-def.exp ... 149063 DUPLICATE: gdb.base/decl-before-def.exp: p a 149064 149065 Fix by giving explicit names to the two tests that use the same command. 149066 149067 Tested on x86_64-linux. 149068 1490692022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149070 149071 gdb/testsuite: Remove duplicates from gdb.base/pending.exp 149072 When running the testsuite, I have: 149073 149074 Running .../gdb/testsuite/gdb.base/pending.exp ... 149075 DUPLICATE: gdb.base/pending.exp: disable other breakpoints 149076 149077 Fix by adjusting the test names. 149078 149079 Tested on x86_64-linux. 149080 1490812022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149082 149083 gdb/testsuite: Remove duplicates from gdb.base/checkpoint.exp 149084 When running the testsuite, I have: 149085 149086 Running .../gdb/testsuite/gdb.base/checkpoint.exp ... 149087 DUPLICATE: gdb.base/checkpoint.exp: verify lines 5 two 149088 DUPLICATE: gdb.base/checkpoint.exp: restart 0 one 149089 149090 This patch fixes the various erroneous incorrect test names. 149091 149092 While at it, this patch also remove some trailing white spaces across 149093 the file. 149094 149095 Tested on x86_64-linux. 149096 1490972022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149098 149099 gdb/testsuite: Remove duplicates from gdb.base/pie-fork.exp 149100 When running the testsuite, I have: 149101 149102 Running .../gdb/testsuite/gdb.base/pie-fork.exp ... 149103 DUPLICATE: gdb.base/pie-fork.exp: test_no_detach_on_fork: continue 149104 149105 Fix by giving explicit names to the 'continue' commands that cause the 149106 duplicate message. 149107 149108 Tested on x86_64-linux. 149109 1491102022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149111 149112 gdb/testsuite: Remove duplicates from gdb.base/realname-expand.exp 149113 When running the testsuite, I have: 149114 149115 Running .../gdb/testsuite/gdb.base/realname-expand.exp ... 149116 DUPLICATE: gdb.base/realname-expand.exp: set basenames-may-differ on 149117 149118 This is due to the fact that the test restarts GDB twice and each time 149119 sets the basenames-may-differ setting. This patch proposes to fix this 149120 by not restarting GDB so the setting is maintained. It just clears the 149121 breakpoints between the two tests and updates the breakpoints number as 149122 required. 149123 149124 This patch also perform some minor refactorings to improve visibility. 149125 149126 Tested on x86_64-linux. 149127 1491282022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149129 149130 gdb/testsuite: Remove duplicates from gdb.base/interp.exp 149131 When running the testsuite I have: 149132 149133 Running .../gdb/testsuite/gdb.base/interp.exp ... 149134 DUPLICATE: gdb.base/interp.exp: interpreter-exec mi "-var-update *" 149135 149136 This is due to the fact that multiple successive instances of 149137 gdb_test_multiple use 'pass $cmd', but one of them forgets to reset $cmd 149138 to a new test name. 149139 149140 Fix by using 'pass $gdb_test_name', given that the gdb_test_name is set 149141 by gdb_test_multiple. 149142 149143 While fixing this, this patch refactors all occurrences of the following 149144 pattern: 149145 149146 set cmd foo 149147 gdb_test_multiple $cmd $cmd { 149148 -re ... { 149149 pass $cmd 149150 } 149151 } 149152 149153 into 149154 149155 gdb_test_multiple foo "" { 149156 -re ... { 149157 pass $gdb_test_name 149158 } 149159 } 149160 149161 This makes this test file coherent in its use of $gdb_test_name. 149162 149163 Tested on x86_64-linux. 149164 1491652022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149166 149167 gdb/testsuite: Remove duplicates from gdb.base/miscexprs.exp 149168 When running the testsuite I see: 149169 149170 Running .../gdb/testsuite/gdb.base/miscexprs.exp ... 149171 DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100] 149172 DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100] 149173 149174 This is due to an explicit test name repeated across multiple tests. 149175 The actual test explicit names do not add much over the command from 149176 wich default test names are derived. 149177 149178 Fix by removing the explicit test names across the file where they do 149179 not add value. While at doing some cleaning, also use $gdb_test_name in 149180 the various uses of gdb_test_multiple. 149181 149182 Tested on x86_64-linux. 149183 1491842022-01-07 Lancelot SIX <lsix@lancelotsix.com> 149185 149186 gdb/testsuite: Remove duplicates from gdb.base/stack-checking.exp 149187 When running the testsuite I have: 149188 149189 Running .../gdb/testsuite/gdb.base/stack-checking.exp ... 149190 DUPLICATE: gdb.base/stack-checking.exp: bt 149191 DUPLICATE: gdb.base/stack-checking.exp: bt 149192 149193 Fix by using with_test_prefix. 149194 149195 Tested on x86_64-linux. 149196 1491972022-01-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 149198 149199 RISC-V: update docs to reflect privileged spec v1.9 has been dropped 149200 After commit d8af286fffa ("RISC-V: Drop the privileged spec v1.9 149201 support.") has removed support for privileged spec v1.9, this removes 149202 it from the documentation. 149203 149204 References: d8af286fffa ("RISC-V: Drop the privileged spec v1.9 support.") 149205 149206 gas/ChangeLog: 149207 149208 * configure: Regenerate. 149209 * configure.ac: Remove reference to priv spec 1.9. 149210 * po/fr.po: Same. 149211 * po/ru.po: Same. 149212 * po/uk.po: Same. 149213 1492142022-01-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 149215 149216 RISC-V: update docs for -mpriv-spec/--with-priv-spec for 1.12 149217 While support for the privileged spec was added in a63375ac337 149218 ("RISC-V: Hypervisor ext: support Privileged Spec 1.12"), the 149219 documentation has not been updated. Add 1.12 to the relevant 149220 documentation. 149221 149222 References: a63375ac337 ("RISC-V: Hypervisor ext: support Privileged Spec 1.12") 149223 149224 gas/ChangeLog: 149225 149226 * config/tc-riscv.c: Add 1.12 to the usage message. 149227 * configure: Regenerate. 149228 * configure.ac: Add 1.12 to the help/usage message. 149229 * po/fr.po: Same. 149230 * po/ru.po: Same. 149231 * po/uk.po: Same. 149232 1492332022-01-07 Tom Tromey <tromey@adacore.com> 149234 149235 Do not use CC_HAS_LONG_LONG 149236 ax.cc checks CC_HAS_LONG_LONG, but nothing defines this. However, 149237 PRINTF_HAS_LONG_LONG is checked in configure. This patch removes the 149238 former and keeps the latter. This is PR remote/14976 (filed by me in 149239 2012, lol). 149240 149241 I'm checking this in. 149242 149243 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14976 149244 1492452022-01-07 Andrew Burgess <aburgess@redhat.com> 149246 149247 gdb/doc: shorten some source lines, and prevent some line breaks 149248 Building on the previous commit, this makes use of a trailing @ to 149249 split long @deffn lines in the guile.texi source file. This splitting 149250 doesn't change how the document is laid out by texinfo. 149251 149252 I have also wrapped keyword and argument name pairs in @w{...} to 149253 prevent line breaks appearing between the two. I've currently only 149254 done this for the longer @deffn lines, where a line break is 149255 possible. This makes the @deffn lines much nicer to read in the 149256 generated pdf. 149257 1492582022-01-07 Andrew Burgess <aburgess@redhat.com> 149259 149260 gdb/doc: Remove (...) around guile procedure names in @deffn lines 149261 Most guile procedures in the guile.texi file are defined like: 149262 149263 @deffn {Scheme Procedure} name arg1 arg2 arg3 149264 149265 But there are two places where we do this: 149266 149267 @deffn {Scheme Procedure} (name arg1 arg2 arg3) 149268 149269 Notice the added (...). Though this does represent how a procedure 149270 call is written in scheme, it's not the normal style throughout the 149271 manual. I also checked the 'info guile' info page to see how they 149272 wrote there declarations, and they use the first style too. 149273 149274 The second style also has the drawback that index entries are added as 149275 '(name', and so they are grouped in the '(' section of the index, 149276 which is not very user friendly. 149277 149278 In this commit I've changed the definitions of make-command and 149279 make-parameter to use the first style. 149280 149281 The procedure declaration lines can get pretty long with all of the 149282 arguments, and this was true for both of the procedures I am changing 149283 in this commit. I have made use of a trailing '@' to split the deffn 149284 lines, and keep them under 80 characters in the texi source. This 149285 makes no difference to how the final document looks. 149286 149287 Finally, our current style for keyword arguments, appears to be: 149288 149289 [#:keyword-name argument-name] 149290 149291 I don't really understand the reason for this, 'info guile' just seems 149292 to use: 149293 149294 [#:keyword-name] 149295 149296 which seems just as good to me. But I don't propose to change 149297 that just now. What I do notice though, is that sometimes, texinfo 149298 will place a line break between the keyword-name and the 149299 argument-name, for example, the pdf of make-command is: 149300 149301 make-command name [#:invoke invoke] [#:command-class 149302 command-class] [#:completer-class completer] [#:prefix? prefix] [#:doc 149303 doc-string] 149304 149305 Notice the line break after '#:command-class' and after '#:doc', 149306 neither of which are ideal. And so, for the two commands I am 149307 changing in this commit, I have made use of @w{...} to prevent line 149308 breaks between the keyword-name and the argument-name. Now the pdf 149309 looks like this: 149310 149311 make-command name [#:invoke invoke] 149312 [#:command-class command-class] [#:completer-class completer] 149313 [#:prefix? prefix] [#:doc doc-string] 149314 149315 Which seems much better. I'll probably update the other deffn lines 149316 at some point. 149317 1493182022-01-07 Pavel Mayorov <pmayorov@cloudlinux.com> 149319 149320 Revert previous delta to debug.c. Replace with patch to reject indirect types that point to indirect types. 149321 PR 28718 149322 * dwarf.c: Revert previous delta. 149323 (debug_get_real_type): Reject indirect types that point to 149324 indirect types. 149325 (debug_get_type_name, debug_get_type_size, debug_write_type): 149326 Likewise. 149327 1493282022-01-07 Nelson Chu <nelson.chu@sifive.com> 149329 149330 RISC-V: Updated the default ISA spec to 20191213. 149331 Update the default ISA spec from 2.2 to 20191213 will change the default 149332 version of i from 2.0 to 2.1. Since zicsr and zifencei are separated 149333 from i 2.1, users need to add them in the architecture string if they need 149334 fence.i and csr instructions. Besides, we also allow old ISA spec can 149335 recognize zicsr and zifencei, but we won't output them since they are 149336 already included in the i extension when i's version is less than 2.1. 149337 149338 bfd/ 149339 * elfxx-riscv.c (riscv_parse_add_subset): Allow old ISA spec can 149340 recognize zicsr and zifencei. 149341 gas/ 149342 * config/tc-riscv.c (DEFAULT_RISCV_ISA_SPEC): Updated to 20191213. 149343 * testsuite/gas/riscv/csr-version-1p10.d: Added zicsr to -march since 149344 the default version of i is 2.1. 149345 * testsuite/gas/riscv/csr-version-1p11.d: Likewise. 149346 * testsuite/gas/riscv/csr-version-1p12.d: Likewise. 149347 * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. 149348 * testsuite/gas/riscv/option-arch-03.d: Updated i's version to 2.1. 149349 * testsuite/gas/riscv/option-arch-03.s: Likewise. 149350 ld/ 149351 * testsuite/ld-riscv-elf/call-relax.d: Added zicsr to -march since 149352 the default version of i is 2.1. 149353 * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated i's version to 2.1. 149354 * testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise. 149355 * testsuite/ld-riscv-elf/attr-merge-arch-01b.: Likewise. 149356 * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise. 149357 * testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise. 149358 * testsuite/ld-riscv-elf/attr-merge-arch-02b.s: Likewise. 149359 * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise. 149360 * testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise. 149361 * testsuite/ld-riscv-elf/attr-merge-arch-03b.s: Likewise. 149362 * testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Added zifencei 149363 into Tag_RISCV_arch since it is added implied when i's version is 149364 larger than 2.1. 149365 1493662022-01-07 Alan Modra <amodra@gmail.com> 149367 149368 Move elf_backend_always_size_sections earlier 149369 * elflink.c (bfd_elf_size_dynamic_sections): Move plt/got init 149370 earlier and call elf_backend_always_size_sections at the start 149371 of this function. 149372 1493732022-01-07 GDB Administrator <gdbadmin@sourceware.org> 149374 149375 Automatic date update in version.in 149376 1493772022-01-06 H.J. Lu <hjl.tools@gmail.com> 149378 149379 ldelfgen.c: Add missing newlines when calling einfo 149380 * ldelfgen.c (ldelf_map_segments): Add the missing newline to 149381 einfo. 149382 1493832022-01-06 Nick Clifton <nickc@redhat.com> 149384 149385 Fix a stack exhaustion bug parsing malicious STABS format debug information. 149386 PR 28718 149387 * debug.c (debug_write_type): Allow for malicious recursion via 149388 indirect debug types. 149389 1493902022-01-06 Richard Sandiford <richard.sandiford@arm.com> 149391 149392 aarch64: Add support for new SME instructions 149393 This patch adds support for three new SME instructions: ADDSPL, 149394 ADDSVL and RDSVL. They behave like ADDPL, ADDVL and RDVL, but read 149395 the streaming vector length instead of the current vector length. 149396 149397 opcodes/ 149398 * aarch64-tbl.h (aarch64_opcode_table): Add ADDSPL, ADDSVL and RDSVL. 149399 * aarch64-dis-2.c: Regenerate. 149400 149401 gas/ 149402 * testsuite/gas/aarch64/sme.s, testsuite/gas/aarch64/sme.d: Add tests 149403 for ADDSPL, ADDSVL and RDSVL. 149404 1494052022-01-06 Tom Tromey <tom@tromey.com> 149406 149407 Use target_announce_detach in more targets 149408 target_announce_detach was added in commit 0f48b757 ("Factor out 149409 "Detaching from program" message printing"). There, Pedro wrote: 149410 149411 (For now, I left the couple targets that print this a bit differently 149412 alone. Maybe this could be further pulled out into infcmd.c. If we 149413 did that, and those targets want to continue printing differently, 149414 this new function could be converted to a target method.) 149415 149416 It seems to me that the differences aren't very big, and in some cases 149417 other targets handled the output a bit more nicely. In particular, 149418 some targets will print a different message when exec_file==NULL, 149419 rather than printing the same output with an empty string as 149420 exec_file. 149421 149422 This patch incorporates the nicer output into target_announce_detach, 149423 then changes the remaining ports to use this function. 149424 1494252022-01-06 Tom Tromey <tom@tromey.com> 149426 149427 Introduce target_announce_attach 149428 This introduces target_announce_attach, by analog with 149429 target_announce_detach. Then it converts existing targets to use 149430 this, rather than emitting their own output by hand. 149431 1494322022-01-06 Andrew Burgess <aburgess@redhat.com> 149433 149434 gdb: make use add_setshow_prefix_cmd in gnu-nat.c 149435 In gnu-nat.c we currently implement some set/show prefix commands 149436 "manually", that is, we call add_prefix_cmd, and assign a set and show 149437 function to each prefix command. 149438 149439 These set/show functions print an error indicating that the user 149440 didn't type a complete command. 149441 149442 If we instead switch to using add_setshow_prefix_cmd then we can 149443 delete the set/show functions, GDB provides some default functions, 149444 which give a nice help style summary that lists all of the available 149445 sub-commands, along with a one line summary of what each does. 149446 149447 Though this clearly changes the existing behaviour, I think this 149448 change is acceptable as the new behaviour is more inline with other 149449 set/show prefix commands, and the new behaviour is more informative. 149450 149451 This change will conflict with Tom's change here: 149452 149453 https://sourceware.org/pipermail/gdb-patches/2022-January/184724.html 149454 149455 Where Tom changes the set/show functions that I delete. My suggestion 149456 is that the set/show functions still be deleted even after Tom's 149457 patch (or instead of Tom's patch). 149458 149459 For testing I've build GDB on GNU/Hurd, and manually tested these 149460 functions. I did a grep over the testsuite, and don't believe the 149461 existing error messages are being checked for in any tests. 149462 1494632022-01-06 Tom Tromey <tom@tromey.com> 149464 149465 Use warning in windows-nat error messages 149466 A warning in windows-nat.c can be converted to use the warning 149467 function. As a side effect, this arranges for the output to be sent 149468 to gdb_stderr. 149469 1494702022-01-06 Tom Tromey <tom@tromey.com> 149471 149472 Clean up some dead code in windows-tdep.c 149473 windows-tdep.c checks the result of xmalloc, which isn't necessary. I 149474 initially removed this dead check, but then went a bit further and 149475 modified the code so that some "goto"s and explicit memory management 149476 could be removed. Then, I added a couple of missing bounds checks. 149477 149478 I believe this also fixes a possible bug with a missing 0-termination 149479 of a string. I am not certain, but that is why I think the existing 149480 code allocates a buffer that is 1 byte too long -- but then it fails 149481 to set this byte to 0. 149482 1494832022-01-06 Tom Tromey <tromey@adacore.com> 149484 149485 Avoid crash in language_info 149486 language_info calls: 149487 149488 show_language_command (NULL, 1, NULL, NULL); 149489 149490 ... "knowing" that show_language_command does not use its ui_file 149491 parameter. However, this was changed in commit 7514a661 149492 ("Consistently Use ui_file parameter to show callbacks"). 149493 149494 This patch changes language_info to pass a ui_file. 149495 149496 It took a while to write the test -- this function is only called when 149497 'verbose' is on and when switching the "expected" language in auto 149498 mode. 149499 1495002022-01-06 Tom Tromey <tromey@adacore.com> 149501 149502 Fix some failures in langs.exp 149503 langs.exp currently has some fails for me because the stack trace 149504 includes full paths to the source files. 149505 149506 FAIL: gdb.base/langs.exp: up to foo in langs.exp 149507 FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp 149508 FAIL: gdb.base/langs.exp: up to fsub in langs.exp 149509 149510 This fixes the failures by making the filename regexps a bit more lax. 149511 1495122022-01-06 Jan Beulich <jbeulich@suse.com> 149513 149514 x86: drop NoAVX insn attribute 149515 To avoid issues like that addressed by 6e3e5c9e4181 ("x86: extend SSE 149516 check to PCLMULQDQ, AES, and GFNI insns"), base the check on opcode 149517 attributes and operand types. 149518 149519 x86: drop NoAVX from POPCNT 149520 With the introduction of CpuPOPCNT the NoAVX attribute has become 149521 meaningless for POPCNT. 149522 149523 x86: drop some "comm" template parameters 149524 As already indicated in a remark when introducing these templates, the 149525 "commutative" attribute is ignored for legacy encoding templates. Hence 149526 it is possible to shorten a number of templates by specifying C directly 149527 rather than through a template parameter. I think this helps readability 149528 a bit. 149529 149530 x86: templatize FMA insn templates 149531 The operand ordering portion of the mnemonics repeats, causing a flurry 149532 of almost identical templates. Abstract this out. 149533 149534 x86-64: restrict PC32 -> PLT32 conversion 149535 Neither non-64-bit code nor uses with a non-zero offset from a symbol 149536 should be converted to PLT32, as an eventual PLT entry would not express 149537 what was requested. 149538 1495392022-01-06 Lancelot SIX <lancelot.six@amd.com> 149540 149541 gdb: Fix copyright year in gdb/testsuite/gdb.base/inferior-clone.exp 149542 I just realized that I forgot to update the year before pushing the 149543 patch that created this file. Since it landed after the global 149544 copyright year update have been done, this file’s copyright year is 149545 updated. 149546 149547 This patch fixes that. 149548 149549 Change-Id: I280f7d86e02d38425f7afdcf19a1c3500d51c23f 149550 1495512022-01-06 Mike Frysinger <vapier@gentoo.org> 149552 149553 sim: ppc: migrate to standard uintXX_t types 149554 Drop the sim-specific unsignedXX types and move to the standard uintXX_t 149555 types that C11 provides. 149556 149557 sim: common: migrate to standard uintXX_t types 149558 Drop the sim-specific unsignedXX types and move to the standard uintXX_t 149559 types that C11 provides. 149560 149561 sim: igen: migrate to standard uintXX_t types 149562 Move off the custom local 64-bit types and to the standard uintXX_t 149563 types that C11 provides. 149564 149565 sim: mips: migrate to standard uintXX_t types 149566 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149567 types that C11 provides. 149568 149569 sim: cris: migrate to standard uintXX_t types 149570 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149571 types that C11 provides. 149572 149573 sim: iq2000: migrate to standard uintXX_t types 149574 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149575 types that C11 provides. 149576 149577 sim: synacor: migrate to standard uintXX_t types 149578 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149579 types that C11 provides. 149580 149581 sim: msp430: migrate to standard uintXX_t types 149582 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149583 types that C11 provides. 149584 149585 sim: riscv: migrate to standard uintXX_t types 149586 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149587 types that C11 provides. 149588 149589 sim: bfin: migrate to standard uintXX_t types 149590 Move off the sim-specific unsignedXX types and to the standard uintXX_t 149591 types that C11 provides. 149592 149593 sim: testsuite: migrate to standard uintXX_t types 149594 This old code setup its own uintXX types, but since we require C11 149595 now, we can assume the standard uintXX_t types exist and use them. 149596 149597 sim: erc32: migrate to standard uintXX_t types 149598 This old port setup its own uintXX types, but since we require C11 149599 now, we can assume the standard uintXX_t types exist and use them. 149600 149601 sim: mn10300: migrate to standard uintXX_t types 149602 This old port setup its own uintXX types, but since we require C11 149603 now, we can assume the standard uintXX_t types exist and use them. 149604 149605 sim: v850: migrate to standard uintXX_t types 149606 This old port setup its own uintXX types, but since we require C11 149607 now, we can assume the standard uintXX_t types exist and use them. 149608 1496092022-01-06 Mike Frysinger <vapier@gentoo.org> 149610 149611 sim: m68hc11: migrate to standard uintXX_t types 149612 This old port setup its own uintXX types, but since we require C11 149613 now, we can assume the standard uintXX_t types exist and use them. 149614 149615 Also migrate off the sim-specific unsignedXX types. 149616 1496172022-01-06 Mike Frysinger <vapier@gentoo.org> 149618 149619 sim: d10v: migrate to standard uintXX_t types 149620 This old port setup its own uintXX types, but since we require C11 149621 now, we can assume the standard uintXX_t types exist and use them. 149622 149623 Also migrate off the sim-specific unsignedXX types. 149624 1496252022-01-06 Mike Frysinger <vapier@gentoo.org> 149626 149627 sim: cr16: migrate to standard uintXX_t types 149628 This old port setup its own uintXX types, but since we require C11 149629 now, we can assume the standard uintXX_t types exist and use them. 149630 149631 Also migrate off the sim-specific unsignedXX types. 149632 1496332022-01-06 GDB Administrator <gdbadmin@sourceware.org> 149634 149635 Automatic date update in version.in 149636 1496372022-01-05 H.J. Lu <hjl.tools@gmail.com> 149638 149639 x86: Add elf_x86_allocate_local_got_info 149640 Add elf_x86_allocate_local_got_info to allocate x86 GOT info for local 149641 symbols. 149642 149643 * elf32-i386.c (elf_i386_check_relocs): Call 149644 elf_x86_allocate_local_got_info. 149645 * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise. 149646 * elfxx-x86.h (elf_x86_allocate_local_got_info): New. 149647 1496482022-01-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 149649 149650 opcodes: Make i386-dis.c thread-safe 149651 Improve thread safety in print_insn_i386_att, print_insn_i386_intel and 149652 print_insn_i386 by removing the use of static variables. 149653 149654 Tested on x86_64-pc-linux-gnu. 149655 149656 2022-01-04 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 149657 149658 * i386-dis.c: Make print_insn_i386_att, print_insn_i386_intel 149659 and print_insn_i386 thread-safe 149660 1496612022-01-05 H.J. Lu <hjl.tools@gmail.com> 149662 149663 doc: Replace =frame-interp with =frames-interp 149664 The actual objdump and readelf option name is =frames-interp, not 149665 =frames-interp. 149666 149667 PR binutils/28747 149668 * doc/debug.options.texi: Replace =frame-interp with 149669 =frames-interp. 149670 1496712022-01-05 Tom Tromey <tromey@adacore.com> 149672 149673 Change riscv_return_value to use RETURN_VALUE_ABI_PRESERVES_ADDRESS 149674 Internally, AdaCore has a test that is equivalent to (really a direct 149675 translation of) gdb.base/gnu_vector.exp. On 32-bit RISC-V, the 149676 "return" part of this test fails. 149677 149678 Joel tracked this down to riscv_return_value returning 149679 RETURN_VALUE_ABI_RETURNS_ADDRESS. Using 149680 RETURN_VALUE_ABI_PRESERVES_ADDRESS is more correct here, and fixes the 149681 bug. 149682 149683 I tested this for both 32- and 64-bit RISC-V using the AdaCore 149684 internal test suite, and Andrew Burgess tested it using 149685 gnu_vector.exp. 149686 1496872022-01-05 Tom Tromey <tom@tromey.com> 149688 149689 Filtered output cleanup in expression dumping 149690 Most of the expression-dumping code uses filtered output, but a few 149691 functions did not. This patch cleans up these instance. 149692 149693 Note that this won't cause any behavior change, because the only calls 149694 to dump_prefix_expression pass in gdb_stdlog. However, in the long 149695 run it's easier to audit the code if the number of uses of _unfiltered 149696 is reduced. 149697 1496982022-01-05 Tom Tromey <tom@tromey.com> 149699 149700 Use filtered output in terminal_info implementations 149701 This changes one terminal_info implementation, and 149702 default_terminal_info, to use filtered output. Other implementations 149703 of this method already use filtered output. 149704 149705 I can't compile go32-nat.c, so this is a 'best effort' patch. 149706 1497072022-01-05 Tom Tromey <tom@tromey.com> 149708 149709 Use filtered output in gnu-nat.c commands 149710 gnu-nat.c has a number of ordinary commands that should use filtered 149711 output. In a few cases, I changed the output to use gdb_stderr as 149712 well. I can't compile this file, so this patch is split out as a 149713 "best effort". 149714 149715 Use filtered output in *-tdep commands 149716 Various targets introduce their own commands, which then use 149717 unfiltered output. It's better to use filtered output by default, so 149718 this patch fixes the instances I found. 149719 149720 Use filtered output in btrace-related commands 149721 This changes btrace.c and record-btrace.c to use filtered output in 149722 the commands implemented there. 149723 149724 Use filtered output in some dumping commands 149725 There are several commands that may optionally send their output to a 149726 file -- they take an optional filename argument and open a file. This 149727 patch changes these commands to use filtered output. The rationale 149728 here is that, when printing to gdb_stdout, filtering is appropriate -- 149729 it is, and should be, the default for all commands. And, when writing 149730 to a file, paging will not happen anyway (it only happens when the 149731 stream==gdb_stdout), so using the _filtered form will not change 149732 anything. 149733 149734 Use filtered output in kill command 149735 This changes the kill command to use filtered output. I split this 149736 one into its own patch because, out of an abundance of caution, I 149737 changed the function to call bfd_cache_close_all a bit earlier, in 149738 case pagination caused an exception. 149739 1497402022-01-05 Tom Tromey <tom@tromey.com> 149741 149742 Use filtered output in ordinary commands 149743 Many otherwise ordinary commands choose to use unfiltered output 149744 rather than filtered. I don't think there's any reason for this, so 149745 this changes many such commands to use filtered output instead. 149746 149747 Note that complete_command is not touched due to a comment there 149748 explaining why unfiltered output is believed to be used. 149749 1497502022-01-05 Tom Tromey <tom@tromey.com> 149751 149752 Use filtered output in language_info 149753 Change language_info to use filtered output. This is ok because the 149754 sole caller uses filtered output elsewhere, and because this function 149755 calls show_language_command, which also uses filtered output. 149756 149757 Use filtered output in files_info implementations 149758 This changes the implementations of the target files_info method to 149759 use filtered output. This makes sense because the sole caller of this 149760 method is an ordinary command (info_program_command). This patch 149761 changes this command to use filtered output as well. 149762 149763 Use filtered output in target-descriptions.c 149764 target-descriptions.c uses unfiltered output. However, if you happen 149765 to invoke this command interactively, it's probably better for it to 149766 use filtering. For non-interactive use, this doesn't matter. 149767 149768 Use filtered output for gdbarch dump 149769 This changes gdbarch dumping to use filtered output. This seems a bit 149770 better to me, both on the principle that this is an ordinary command, 149771 and because the output can be voluminous, so it may be nice to stop in 149772 the middle. 149773 1497742022-01-05 Tom Tromey <tom@tromey.com> 149775 149776 Implement putstr and putstrn in ui_file 149777 In my tour of the ui_file subsystem, I found that fputstr and fputstrn 149778 can be simplified. The _filtered forms are never used (and IMO 149779 unlikely to ever be used) and so can be removed. And, the interface 149780 can be simplified by removing a callback function and moving the 149781 implementation directly to ui_file. 149782 149783 A new self-test is included. Previously, I think nothing was testing 149784 this code. 149785 149786 Regression tested on x86-64 Fedora 34. 149787 1497882022-01-05 Tom Tromey <tromey@adacore.com> 149789 149790 Change how versioned symbols are recorded 149791 A change to BFD caused a gdb regression when using the Ada "catch 149792 exception" feature. The bug is visible when a shared library throws 149793 an exception that is caught in the main executable. 149794 149795 This was discussed here: 149796 149797 https://sourceware.org/pipermail/binutils/2021-July/117538.html 149798 149799 This patch implements Alan's proposed fix, namely to use VERSYM_HIDDEN 149800 rather than the name when deciding to install a version-less symbol. 149801 149802 The internal test case is identical to the catch_ex_std.exp that is 149803 in-tree, so I haven't added a new test. I could not make that one 149804 fail on x86-64 Linux, though. It's possible that maybe I'd have to 149805 update the system linker first, but I didn't want to try that. 149806 149807 Regression tested on x86-64 Fedora 32. 149808 1498092022-01-05 Hannes Domani <ssbssa@yahoo.de> 149810 149811 Fix inferior_thread attribute in new_thread event 149812 Commit 72ee03ff58 fixed a use-after-move bug in add_thread_object, but 149813 it changed the inferior_thread attribute to contain the inferior instead 149814 of the actual thread. 149815 This now uses the thread_obj in its new location instead. 149816 149817 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28429 149818 1498192022-01-05 Tom Tromey <tom@tromey.com> 149820 149821 Simplify execute_control_commands_to_string 149822 execute_control_commands_to_string can be rewritten in terms of 149823 execute_fn_to_string, which consolidates some knowledge about which 149824 streams to redirect. 149825 149826 Regression tested on x86-64 Fedora 34. 149827 1498282022-01-05 Tom Tromey <tromey@adacore.com> 149829 149830 Do not print anything when self-backtrace unavailable 149831 Right now, gdb's self-backtrace feature will still print something 149832 when a backtrace is unavailable: 149833 149834 sig_write (_("----- Backtrace -----\n")); 149835 [...] 149836 sig_write (_("Backtrace unavailable\n")); 149837 sig_write ("---------------------\n"); 149838 149839 However, if GDB_PRINT_INTERNAL_BACKTRACE is undefined, it seems better 149840 to me to print nothing at all. 149841 149842 This patch implements this change. It also makes a couple of other 149843 small changes in this same module: it adds a header guard to 149844 bt-utils.h, and it protects the definitions of 149845 gdb_internal_backtrace_1 with a check of GDB_PRINT_INTERNAL_BACKTRACE. 149846 1498472022-01-05 Tom Tromey <tromey@adacore.com> 149848 149849 Fix pager regression 149850 The patch to fix paging with redirection caused a regression in the 149851 internal AdaCore test suite. The problem occurs when running an MI 149852 command from the CLI using interpreter-exec, when paging is enabled. 149853 This scenario isn't covered by the current test suite, so this patch 149854 includes a new test. 149855 149856 The problem is that, in this situation, MI does: 149857 149858 fputs_unfiltered (strcmp (context->command, "target-select") == 0 149859 ? "^connected" : "^done", mi->raw_stdout); 149860 149861 Here raw_stdout is a stdio_file wrapping stdout, so the pager thinks 149862 that it is ok to buffer the output. However, in this setup, it isn't 149863 ok, and flushing the wrap buffer doesn't really work properly. Also, 149864 MI next does: 149865 149866 mi_out_put (uiout, mi->raw_stdout); 149867 149868 ... but this uses ui_file::write, which also doesn't flush the wrap 149869 buffer. 149870 149871 I think all this will be fixed by the pager rewrite series I'm working 149872 on. However, in the meantime, adding the old gdb_stdout check back to 149873 the pager fixes this problem. 149874 149875 Regression tested on x86-64 Fedora 34. 149876 1498772022-01-05 H.J. Lu <hjl.tools@gmail.com> 149878 149879 elf: Set p_align to the minimum page size if possible 149880 Currently, on 32-bit and 64-bit ARM, it seems that ld generates p_align 149881 values of 0x10000 even if no section alignment is greater than 0x1000. 149882 The issue is more general and probably affects other targets with multiple 149883 page sizes. 149884 149885 While file layout absolutely must take 64K page size into account, that 149886 does not have to be reflected in the p_align value. If running on a 64K 149887 kernel, the file will be loaded at a 64K page boundary by necessity. On 149888 a 4K kernel, 64K alignment is not needed. 149889 149890 The glibc loader has been fixed to honor p_align: 149891 149892 https://sourceware.org/bugzilla/show_bug.cgi?id=28676 149893 149894 similar to kernel: 149895 149896 commit ce81bb256a224259ab686742a6284930cbe4f1fa 149897 Author: Chris Kennelly <ckennelly@google.com> 149898 Date: Thu Oct 15 20:12:32 2020 -0700 149899 149900 fs/binfmt_elf: use PT_LOAD p_align values for suitable start address 149901 149902 This means that on 4K kernels, we will start to do extra work for 64K 149903 p_align, but this pointless for pretty much all binaries (whose section 149904 alignment rarely exceeds 16). 149905 149906 The minimum page size is used, instead of the maximum section alignment 149907 due to this glibc bug: 149908 149909 https://sourceware.org/bugzilla/show_bug.cgi?id=28688 149910 149911 It has been fixed in glibc 2.35. But linker output must work on existing 149912 glibc binaries. 149913 149914 1. Set p_align to the minimum page size while laying out segments aligning 149915 to the maximum page size or section alignment. The run-time loader can 149916 align segments to the minimum page size or above, depending on system page 149917 size. 149918 2. If -z max-page-size=NNN is used, p_align will be set to the maximum 149919 page size or the largest section alignment. 149920 3. If a section requires alignment higher than the minimum page size, 149921 don't set p_align to the minimum page size. 149922 4. If a section requires alignment higher than the maximum page size, 149923 set p_align to the section alignment. 149924 5. For objcopy, when the minimum page size != the maximum page size, 149925 p_align may be set to the minimum page size while segments are aligned 149926 to the maximum page size. In this case, the input p_align will be 149927 ignored and the maximum page size will be used to align the ouput 149928 segments. 149929 6. Update linker to disallow the common page size > the maximum page size. 149930 7. Update linker to avoid the common page size > the maximum page size. 149931 8. Adjust pru_irq_map-1.d to expect p_align == sh_addralign: 149932 149933 Section Headers: 149934 [Nr] Name Type Addr Off Size ES Flg Lk Inf Al 149935 [ 0] NULL 00000000 000000 000000 00 0 0 0 149936 [ 1] .text PROGBITS 20000000 00007c 000004 00 AX 0 0 4 149937 ... 149938 Program Headers: 149939 Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 149940 LOAD 0x000074 0x00000000 0x00000000 0x00008 0x00008 RW 0x1 149941 LOAD 0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x4 149942 149943 vs. 149944 149945 Section Headers: 149946 [Nr] Name Type Addr Off Size ES Flg Lk Inf Al 149947 [ 0] NULL 00000000 000000 000000 00 0 0 0 149948 [ 1] .text PROGBITS 20000000 00007c 000004 00 AX 0 0 4 149949 ... 149950 Program Headers: 149951 Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 149952 LOAD 0x000074 0x00000000 0x00000000 0x00008 0x00008 RW 0x1 149953 LOAD 0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x1 149954 149955 To enable this linker optimization, the backend should define ELF_P_ALIGN 149956 to ELF_MINPAGESIZE. 149957 149958 bfd/ 149959 149960 PR ld/28689 149961 PR ld/28695 149962 * elf-bfd.h (elf_backend_data): Add p_align. 149963 * elf.c (assign_file_positions_for_load_sections): Set p_align 149964 to the default p_align value while laying out segments aligning 149965 to maximum page size or section alignment. 149966 (elf_is_p_align_valid): New function. 149967 (copy_elf_program_header): Call elf_is_p_align_valid to determine 149968 if p_align is valid. 149969 * elfxx-target.h (ELF_P_ALIGN): New. Default to 0. 149970 (elfNN_bed): Add ELF_P_ALIGN. 149971 * elfxx-x86.h (ELF_P_ALIGN): New. Set to ELF_MINPAGESIZE. 149972 149973 include/ 149974 149975 PR ld/28689 149976 PR ld/28695 149977 * bfdlink.h (bfd_link_info): Add maxpagesize_is_set. 149978 149979 ld/ 149980 149981 PR ld/28689 149982 PR ld/28695 149983 * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Set 149984 link_info.maxpagesize_is_set for -z max-page-size=NNN. 149985 * ldelf.c (ldelf_after_parse): Disallow link_info.commonpagesize 149986 > link_info.maxpagesize. 149987 * testsuite/ld-elf/elf.exp: Pass -z max-page-size=0x4000 to 149988 linker to build mbind2a and mbind2b. 149989 * testsuite/ld-elf/header.d: Add -z common-page-size=0x100. 149990 * testsuite/ld-elf/linux-x86.exp: Add PR ld/28689 tests. 149991 * testsuite/ld-elf/p_align-1.c: New file. 149992 * testsuite/ld-elf/page-size-1.d: New test. 149993 * testsuite/ld-elf/pr26936.d: Add -z common-page-size=0x1000. 149994 * testsuite/ld-elf/seg.d: Likewise. 149995 * testsuite/ld-scripts/rgn-at5.d: Likewise. 149996 * testsuite/ld-pru/pru_irq_map-1.d: Append 1 to name. Adjust 149997 expected PT_LOAD segment alignment. 149998 * testsuite/ld-pru/pru_irq_map-2.d: Append 2 to name. 149999 * testsuite/ld-scripts/pr23571.d: Add -z max-page-size=0x1000. 150000 1500012022-01-05 Alan Modra <amodra@gmail.com> 150002 150003 Adjust quoted-sym-names test 150004 Some targets restrict symbol addresses in .text to instruction 150005 boundaries. 150006 150007 * testsuite/gas/all/quoted-sym-names.s: Define syms in .data. 150008 * testsuite/gas/all/quoted-sym-names.d: Adjust to suit. 150009 1500102022-01-05 Alan Modra <amodra@gmail.com> 150011 150012 infinite recursion detected in gold testcase 150013 gold/testsuite/icf_test.cc:32:5: error: infinite recursion detected [-Werror=infinite-recursion] 150014 32 | int kept_func() 150015 | ^~~~~~~~~ 150016 150017 * testsuite/icf_test.cc: Avoid infinite recursion error. 150018 1500192022-01-05 GDB Administrator <gdbadmin@sourceware.org> 150020 150021 Automatic date update in version.in 150022 1500232022-01-04 H.J. Lu <hjl.tools@gmail.com> 150024 150025 ld/x86: Update -z report-relative-reloc 150026 Use 0x%v, instead of bfd_sprintf_vma, to report relative relocations. 150027 Change linker relative relocations report from 150028 150029 tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x0000000000002000, info: 0x0000000000000025, addend: 0x0000000000001007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o 150030 150031 to 150032 150033 tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x2000, info: 0x25, addend: 0x1007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o 150034 150035 bfd/ 150036 150037 * elfxx-x86.c (_bfd_x86_elf_link_report_relative_reloc): Use 150038 0x%v instead of bfd_sprintf_vma. 150039 150040 ld/ 150041 150042 * testsuite/ld-i386/report-reloc-1.l: Updated. 150043 * testsuite/ld-x86-64/report-reloc-1.l: Likewise. 150044 1500452022-01-04 H.J. Lu <hjl.tools@gmail.com> 150046 150047 ld: Improve thin archive member error message 150048 Improve thin archive member error message with: 150049 150050 ld: libbar.a(bar.o): error opening thin archive member: No such file or directory 150051 150052 instead of 150053 150054 ld: libbar.a: error adding symbols: No such file or directory 150055 150056 PR ld/28722 150057 * archive.c (_bfd_get_elt_at_filepos): Add a pointer argument 150058 for struct bfd_link_info. Call linker callback when failing to 150059 open thin archive member. 150060 (_bfd_generic_get_elt_at_index): Pass NULL to 150061 _bfd_get_elt_at_filepos. 150062 (bfd_generic_openr_next_archived_file): Likewise. 150063 * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Add a pointer 150064 argument for struct bfd_link_info and pass it to 150065 _bfd_get_elt_at_filepos. 150066 (alpha_ecoff_openr_next_archived_file): Pass NULL to 150067 _bfd_get_elt_at_filepos. 150068 (alpha_ecoff_get_elt_at_index): Likewise. 150069 * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Likewise. 150070 * ecoff.c (ecoff_link_add_archive_symbols): Pass info to 150071 backend->get_elt_at_filepos. 150072 * elflink.c (elf_link_is_defined_archive_symbol): info to 150073 _bfd_get_elt_at_filepos. 150074 * libbfd-in.h (_bfd_get_elt_at_filepos): Add a pointer argument 150075 for struct bfd_link_info. 150076 * libbfd.h: Regenerate. 150077 * libecoff.h (ecoff_backend_data): Add a pointer argument for 150078 struct bfd_link_info to get_elt_at_filepos. 150079 * linker.c (_bfd_generic_link_add_archive_symbols): Pass info to 150080 _bfd_get_elt_at_filepos. 150081 1500822022-01-04 Lancelot SIX <lancelot.six@amd.com> 150083 150084 gdb/testsuite: fix inferior-clone.exp for native-extended-gdbserver 150085 003aae076207dbf32f98ba846158fc32669ef85f (gdb: Copy inferior properties 150086 in clone-inferior) introduced a testcase that fails when testing with 150087 the native-extended-gdbserver board: 150088 150089 Running ../gdb/testsuite/gdb.base/inferior-clone.exp ... 150090 FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior 150091 FAIL: gdb.base/inferior-clone.exp: inferior 3: clone-inferior 150092 150093 The error is as follows: 150094 150095 clone-inferior 150096 [New inferior 2] 150097 Added inferior 2 on connection 1 (extended-remote localhost:2346) 150098 (gdb) FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior 150099 150100 This fails because the testcase only expect the 'Added inferior 2' part 150101 of the message. The 'on connection 1 [...]' part is unexpected. 150102 150103 Fix by adjusting the testcase to a account for the possible trailing 150104 part of the message. 150105 150106 Tested on x86_64-linux with native-extende-gdbserver and unix boards. 150107 150108 Change-Id: Ie3d6f04c9ffe9cab1fbda8ddf4935ee09b858c7a 150109 1501102022-01-04 Nick Clifton <nickc@redhat.com> 150111 150112 Add ATTRIBUTE_UNUSED to load_build_id_debug_file()'s main_filename parameter. 150113 1501142022-01-04 Andrew Burgess <aburgess@redhat.com> 150115 150116 gdb: don't pass nullptr to sigwait 150117 I tried building GDB on GNU/Hurd, and ran into this warning: 150118 150119 gdbsupport/scoped_ignore_signal.h:78:16: error: null argument where non-null required (argument 2) [-Werror=nonnull] 150120 150121 This is because in this commit: 150122 150123 commit 99624310dd82542c389c89c2e55d8cae36bb74e1 150124 Date: Sun Jun 27 15:13:14 2021 -0400 150125 150126 gdb: fall back on sigpending + sigwait if sigtimedwait is not available 150127 150128 A call to sigwait was introduced that passes nullptr as the second 150129 argument, this call is only reached if sigtimedwait is not supported. 150130 150131 The original patch was written for macOS, I assume on that target 150132 passing nullptr as the second argument is fine. 150133 150134 On my GNU/Linux box, the man-page for sigwait doesn't mention that 150135 nullptr is allowed for the second argument, so my assumption would be 150136 that nullptr is not OK, and, if I change the '#ifdef 150137 HAVE_SIGTIMEDWAIT' introduced by the above patch to '#if 0', and 150138 rebuild on GNU/Linux, I see the same warning that I see on GNU/Hurd. 150139 150140 I propose that we stop passing nullptr as the second argument to 150141 sigwait, and instead pass a valid int pointer. The value returned in 150142 the int can then be used in an assert. 150143 150144 For testing, I (locally) made the change to the #ifdef I mentioned 150145 above, compiled GDB, and ran the usual tests, this meant I was using 150146 sigwait instead on sigtimedwait on GNU/Linux, I saw no regressions. 150147 1501482022-01-04 Nick Clifton <nickc@redhat.com> 150149 150150 Remove a spurious debugging message. 150151 PR 28716 150152 * dwarf.c (load_build_id_debug_file): Remove spurious printf. 150153 1501542022-01-04 Tom de Vries <tdevries@suse.de> 150155 150156 [gdb/build] Fix build breaker in gdb/cli/cli-logging.c 150157 Fix build breaker in gdb/cli/cli-logging.c: 150158 ... 150159 gdb/cli/cli-logging.c: In function \ 150160 ‘void show_logging_enabled(ui_file*, int, cmd_list_element*, const char*)’: 150161 gdb/gdbsupport/gdb_locale.h:28:28: error: cannot convert ‘char*’ to ‘ui_file*’ 150162 28 | # define _(String) gettext (String) 150163 | ~~~~~~~~^~~~~~~~ 150164 | | 150165 | char* 150166 gdb/cli/cli-logging.c:202:25: note: in expansion of macro ‘_’ 150167 202 | fprintf_unfiltered (_("on: Logging is enabled.\n")); 150168 | ^ 150169 ... 150170 150171 Build and tested on x86_64-linux. 150172 150173 Fixes: 45aec4e5ed8 ("[gdb/cli] Improve show logging output") 150174 1501752022-01-04 Jan Beulich <jbeulich@suse.com> 150176 150177 x86/Intel: correct VFPCLASSP{S,D} handling when displacement is present 150178 fits_in_disp8() can be called before ambiguous operands get resolved 150179 or rejected (in process_suffix()), which requires that i.memshift be 150180 non-negative to avoid an internal error. This case wasn't covered by 150181 6c0946d0d28d ("x86: correct VFPCLASSP{S,D} operand size handling"). 150182 1501832022-01-04 Jan Beulich <jbeulich@suse.com> 150184 150185 gas: rework handling of backslashes in quoted symbol names 150186 Strange effects can result from the present handling, e.g.: 150187 150188 .if 1 150189 "backslash\\": 150190 .endif 150191 150192 yields first (correctly) "missing closing `"'" but then also "invalid 150193 character '\' in mnemonic" and further "end of file inside conditional". 150194 Symbols names ending in \ are in principle not expressable with that 150195 scheme. 150196 150197 Instead of recording whether a backslash was seen, inspect the 150198 subsequent character right away. Only accept \\ (meaning a single 150199 backslash in the resulting symbol name) and \" (meaning an embedded 150200 double quote in the resulting symbol name) for now, warning about any 150201 other combination. 150202 150203 While perhaps not necessary immediately, also permit concatenated 150204 strings to form a symbol name. This may become useful if going forward 150205 we would want to support \<octal> or \x<hex> sequences, where closing 150206 and re-opening quotes can be useful to delimit such sequences. 150207 150208 The ELF "Multibyte symbol names" test gets switched away from using 150209 .set, as that would now also mean excluding nios2 and pru. By using 150210 .equiv instead, even the existing #notarget can be dropped. (For h8300 150211 the .section directive additionally needs attributes specified, to avoid 150212 a target specific warning.) 150213 1502142022-01-04 GDB Administrator <gdbadmin@sourceware.org> 150215 150216 Automatic date update in version.in 150217 1502182022-01-03 Tom de Vries <tdevries@suse.de> 150219 150220 [gdb/cli] Improve show logging output 150221 Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the 150222 following output for "show logging": 150223 ... 150224 $ gdb -q -batch -ex "set trace-commands on" \ 150225 -ex "set logging off" \ 150226 -ex "show logging" \ 150227 -ex "set logging on" \ 150228 -ex "show logging" 150229 +set logging off 150230 +show logging 150231 Future logs will be written to gdb.txt. 150232 Logs will be appended to the log file. 150233 Output will be logged and displayed. 150234 Debug output will be logged and displayed. 150235 +set logging on 150236 +show logging 150237 Currently logging to "gdb.txt". 150238 Logs will be appended to the log file. 150239 Output will be logged and displayed. 150240 Debug output will be logged and displayed. 150241 ... 150242 150243 After that commit we have instead: 150244 ... 150245 +set logging off 150246 +show logging 150247 debugredirect: The logging output mode is off. 150248 file: The current logfile is "gdb.txt". 150249 overwrite: Whether logging overwrites or appends to the log file is off. 150250 redirect: The logging output mode is off. 150251 +set logging on 150252 +show logging 150253 debugredirect: The logging output mode is off. 150254 file: The current logfile is "gdb.txt". 150255 overwrite: Whether logging overwrites or appends to the log file is off. 150256 redirect: The logging output mode is off. 150257 ... 150258 which gives less clear output for some subcommands. 150259 150260 OTOH, it's explicit about whether boolean values are on or off. 150261 150262 The new text seems to have been chosen to match the set/show help texts: 150263 ... 150264 (gdb) help show logging 150265 Show logging options. 150266 150267 List of show logging subcommands: 150268 150269 show logging debugredirect -- Show the logging debug output mode. 150270 show logging file -- Show the current logfile. 150271 show logging overwrite -- \ 150272 Show whether logging overwrites or appends to the log file. 150273 show logging redirect -- Show the logging output mode. 150274 ... 150275 150276 Make the show logging messages more clear, while still keep the boolean 150277 values explicit, such that we have: 150278 ... 150279 $ ./gdb.sh -q -batch -ex "show logging" 150280 logging debugredirect: off: \ 150281 Debug output will go to both the screen and the log file. 150282 logging enabled: off: Logging is disabled. 150283 logging file: The current logfile is "gdb.txt". 150284 logging overwrite: off: Logging appends to the log file. 150285 logging redirect: off: Output will go to both the screen and the log file. 150286 ... 150287 150288 Tested on x86_64-linux. 150289 1502902022-01-03 Tom Tromey <tromey@adacore.com> 150291 150292 Fix use of 'printf' in gdbtypes.c 150293 An earlier patch of mine, commit 64b7cc50 ("Remove 150294 gdb_print_host_address") inadvertently changed a function in 150295 gdbtypes.c to use printf rather than printf_filtered. This patch 150296 fixes the problem. 150297 150298 Fix regression in page-logging.exp 150299 Simon and Tom pointed out that page-logging.exp failed on their 150300 machines. Tom tracked this down to the "width" setting. Since 150301 there's no need in the test to change the width, it seems simplest to 150302 remove the setting. I confirmed that the test still fails if the fix 150303 is backed out, ensuring that the test is still testing what it 150304 purports to. 150305 150306 Small indentation fix in eval.c 150307 I noticed that the AdaCore tree had a small divergence in eval.c -- it 150308 had a fix for an indentation problem in binop_promote. I'm checking 150309 in this small fix as obvious. 150310 1503112022-01-03 Tom de Vries <tdevries@suse.de> 150312 150313 [gdb/testsuite] Handle for loop initial decl with gcc 4.8.5 150314 When running test-case gdb.threads/schedlock-thread-exit.exp on a system with 150315 system compiler gcc 4.8.5, I run into: 150316 ... 150317 src/gdb/testsuite/gdb.threads/schedlock-thread-exit.c:33:3: error: \ 150318 'for' loop initial declarations are only allowed in C99 mode 150319 ... 150320 150321 Fix this by: 150322 - using -std=c99, or 150323 - using -std=gnu99, in case that's required, or 150324 - in the case of the jit test-cases, rewriting the for loops. 150325 150326 Tested on x86_64-linux, both with gcc 4.8.5 and gcc 7.5.0. 150327 1503282022-01-03 GDB Administrator <gdbadmin@sourceware.org> 150329 150330 Automatic date update in version.in 150331 1503322022-01-02 Tom Tromey <tom@tromey.com> 150333 150334 Update copying.awk for _initialize declaration patch 150335 Commit 6c265988 ("gdb: add back declarations for _initialize 150336 functions") modified copying.c, but not copying.awk. This patch 150337 updates copying.awk to backport the appropriate fix. This way, if 150338 copying.awk is run again, it will create the correct output. 150339 150340 I'm checking this in as obvious. 150341 1503422022-01-02 Tom Tromey <tom@tromey.com> 150343 150344 Use filtered output in print_i387_ext 150345 print_i387_ext mostly uses filtered output, but one call in the middle 150346 of the function uses the _unfiltered form. This patch fixes this 150347 call. I'm checking this in as obvious. 150348 1503492022-01-02 Alan Modra <amodra@gmail.com> 150350 150351 Update year range in copyright notice of binutils files 150352 The result of running etc/update-copyright.py --this-year, fixing all 150353 the files whose mode is changed by the script, plus a build with 150354 --enable-maintainer-mode --enable-cgen-maint=yes, then checking 150355 out */po/*.pot which we don't update frequently. 150356 150357 The copy of cgen was with commit d1dd5fcc38ead reverted as that commit 150358 breaks building of bfp opcodes files. 150359 1503602022-01-02 GDB Administrator <gdbadmin@sourceware.org> 150361 150362 Automatic date update in version.in 150363 1503642022-01-01 Mike Frysinger <vapier@gentoo.org> 150365 150366 gdb: copyright: fix a few comment typos 150367 150368 sim: ppc: drop natural types 150369 These are almost entirely unused. For the very few places using them, 150370 replace with explicit signed types. This matches what was done in the 150371 common sim code. 150372 150373 sim: mips: clean up bad style/whitespace 150374 This doesn't fix all the problems, but grabs a bunch of the more 150375 obvious ones. 150376 150377 sim: tweak copyright lines for gnulib update-copyright 150378 The regex it uses does not like so many leading spaces which causes 150379 it to think the files lack copyright. Trim them down so the script 150380 can find & update them accordingly. 150381 150382 gdb: update sim mips testsuite copyright exemption 150383 The sim testsuite was reorganized last year, so update the path. 150384 1503852022-01-01 Mike Frysinger <vapier@gentoo.org> 150386 150387 unify 64-bit bfd checks 150388 Move the 64-bit bfd logic out of bfd/configure.ac and into bfd64.m4 150389 under config so it can be shared between all the other subdirs. 150390 150391 This replaces want64 with enable_64_bit_bfd which was already being 150392 declared, but not used directly. 150393 1503942022-01-01 Joel Brobecker <brobecker@adacore.com> 150395 150396 Update Copyright year in gdb/testsuite/gdb.arch/powerpc-power10.exp 150397 This commit updates the copyright year range in the script 150398 gdb/testsuite/gdb.arch/powerpc-power10.exp. The update was 150399 performed by running gdb/copyright.py again, to make sure 150400 that the copyright year range will be automatically updated 150401 in years forward. 150402 1504032022-01-01 Joel Brobecker <brobecker@adacore.com> 150404 150405 Fix copyright header in gdb/testsuite/gdb.arch/powerpc-power10.exp 150406 The copyright year and holder line is slight malformed, missing 150407 a space after a comma, and this is sufficient for gdb's 150408 copyright.py script to miss this file during its automated 150409 copyright year update. 150410 150411 This commit fixes this. 150412 1504132022-01-01 Joel Brobecker <brobecker@adacore.com> 150414 150415 gdb/copyright.py: Add update-netbsd.sh to MULTIPLE_COPYRIGHT_HEADERS 150416 Add gdb/syscalls/update-netbsd.sh to the reminder printed 150417 at the end of the execution listing all the files where 150418 a manual update of the copyright header is needed. This 150419 scripts contains some inline code which includes a copyright 150420 header. 150421 150422 Manual copyright year update of various GDB files 150423 This commit updates the copyright year in some files where 150424 we have a copyright year outside of the copyright year, 150425 and thus are not included in gdb's copyright.py script. 150426 1504272022-01-01 Joel Brobecker <brobecker@adacore.com> 150428 150429 Automatic Copyright Year update after running gdb/copyright.py 150430 This commit brings all the changes made by running gdb/copyright.py 150431 as per GDB's Start of New Year Procedure. 150432 150433 For the avoidance of doubt, all changes in this commits were 150434 performed by the script. 150435 1504362022-01-01 Joel Brobecker <brobecker@adacore.com> 150437 150438 Update Copyright Year in gdb, gdbserver and gdbreplay version output 150439 This commit changes the copyright year printed by gdb, gdbserver 150440 and gdbreplay when printing the tool's version. 150441 1504422022-01-01 Alan Modra <amodra@gmail.com> 150443 150444 ubsan: next_char_of_string signed integer overflow 150445 Squash another totally useless fuzz report that I should have ignored. 150446 150447 * read.c (next_char_of_string): Avoid integer overflow. 150448 1504492022-01-01 Alan Modra <amodra@gmail.com> 150450 150451 ubsan: bfd_mach_o_build_commands shift exponent 64 is too large 150452 * mach-o.c (bfd_mach_o_read_section_32): Limit alignment further. 150453 (bfd_mach_o_read_section_64): Likewise. 150454 1504552022-01-01 Alan Modra <amodra@gmail.com> 150456 150457 ubsan: signed integer multiply overflow 150458 9223371018427387904 * 2 cannot be represented in type 'long', yes, but 150459 we don't care. 150460 150461 * expr.c (expr): Avoid signed overflow. 150462 1504632022-01-01 Alan Modra <amodra@gmail.com> 150464 150465 asan: Null-dereference in _bfd_xcoff_copy_private_bfd_data 150466 sec->output_section will be NULL when objcopy removes sections. 150467 150468 * coff-rs6000.c (_bfd_xcoff_copy_private_bfd_data): Protect against 150469 objcopy removing sections. 150470 1504712022-01-01 Alan Modra <amodra@gmail.com> 150472 150473 ubsan: integer overflow in section filepos subtraction 150474 * elf.c (assign_file_positions_for_non_load_sections): Avoid 150475 signed integer overflow. 150476 1504772022-01-01 Alan Modra <amodra@gmail.com> 150478 150479 Remove unnecessary ELF_MINPAGESIZE defines 150480 The idea of this patch is to make it easy to see which targets (just 150481 sparc) have ELF_MINPAGESIZE != ELF_COMMONPAGESIZE. 150482 150483 * elf32-arm.c (ELF_MINPAGESIZE): Don't define. 150484 * elf32-metag.c: Likewise. 150485 * elfnn-aarch64.c: Likewise. 150486 * elf64-x86-64.c: Likewise. Also don't redefine a bunch of other 150487 macros for l1om elf64-target.h use that are unchanged from default. 150488 1504892022-01-01 H.J. Lu <hjl.tools@gmail.com> 150490 150491 ld-x86-64: Pass options to linker with "-Wl," 150492 * testsuite/ld-x86-64/x86-64.exp: Pass options to linker with 150493 "-Wl,". 150494 1504952022-01-01 GDB Administrator <gdbadmin@sourceware.org> 150496 150497 Automatic date update in version.in 150498 1504992021-12-31 Tom Tromey <tom@tromey.com> 150500 150501 Do not call reinitialize_more_filter from avr_io_reg_read_command 150502 avr_io_reg_read_command is an ordinary gdb command, and so should not 150503 be calling reinitialize_more_filter. This patch removes it. I'm 150504 checking this in as obvious. Tested by rebuilding. 150505 1505062021-12-31 H.J. Lu <hjl.tools@gmail.com> 150507 150508 x86: Define check_relocs_failed in elfxx-x86.h 150509 * elf32-i386.c (check_relocs_failed): Moved to ... 150510 * elfxx-x86.h (check_relocs_failed): Here. New. 150511 * elf64-x86-64.c (check_relocs_failed): Removed. 150512 150513 Define X86_PCREL_TYPE_P/X86_SIZE_TYPE_P in elfxx-x86.h 150514 * elf32-i386.c: Don't include "elf/i386.h". 150515 (X86_PCREL_TYPE_P): Removed. 150516 (X86_SIZE_TYPE_P): Likewise. 150517 (elf_i386_check_relocs): Pass false to NEED_DYNAMIC_RELOCATION_P. 150518 (elf_i386_relocate_section): Pass false to 150519 GENERATE_DYNAMIC_RELOCATION_P and COPY_INPUT_RELOC_P. 150520 * elf64-x86-64.c: Don't include "elf/x86-64.h". 150521 (X86_PCREL_TYPE_P): Removed. 150522 (X86_SIZE_TYPE_P): Likewise. 150523 (elf_x86_64_check_relocs): Pass true to NEED_DYNAMIC_RELOCATION_P 150524 and X86_PCREL_TYPE_P. 150525 (elf_x86_64_relocate_section): Pass true to X86_PCREL_TYPE_P, 150526 X86_SIZE_TYPE_P, GENERATE_DYNAMIC_RELOCATION_P and 150527 COPY_INPUT_RELOC_P. 150528 * elfxx-x86.c: Don't include "elf/i386.h" nor "elf/x86-64.h". 150529 * elfxx-x86.h (X86_64_PCREL_TYPE_P): New. 150530 (I386_PCREL_TYPE_P): Likewise. 150531 (X86_PCREL_TYPE_P): Likewise. 150532 (X86_64_SIZE_TYPE_P): Likewise. 150533 (I386_SIZE_TYPE_P): Likewise. 150534 (X86_SIZE_TYPE_P): Likewise. 150535 (NEED_DYNAMIC_RELOCATION_P): Add IS_X86_64 and pass it to 150536 X86_PCREL_TYPE_P. 150537 (COPY_INPUT_RELOC_P): Likewise. 150538 (GENERATE_DYNAMIC_RELOCATION_P): Add IS_X86_64, pass it to 150539 X86_PCREL_TYPE_P and X86_SIZE_TYPE_P. 150540 1505412021-12-31 Tamar Christina <tamar.christina@arm.com> 150542 150543 ld: fix coff PE SEH 150544 COFF_WITH_pex64 and COFF_WITH_peAArch64 can't be true at the same time. 150545 That means that two conditionals that control the sorting of the .pdata section 150546 became a falsum. 150547 150548 The testsuite doesn't catch this because the linker does the sorting and to link 150549 you require library support from the unwinder so we can't test from binutils in 150550 isolation. 150551 150552 bfd/ChangeLog: 150553 150554 2021-12-31 Tamar Christina <tamar.christina@arm.com> 150555 150556 PR ld/28682 150557 * peXXigen.c: Fix conditional. 150558 1505592021-12-31 GDB Administrator <gdbadmin@sourceware.org> 150560 150561 Automatic date update in version.in 150562 1505632021-12-30 GDB Administrator <gdbadmin@sourceware.org> 150564 150565 Automatic date update in version.in 150566 1505672021-12-29 Tom Tromey <tom@tromey.com> 150568 150569 Use filtered output in show callbacks 150570 "show" command callbacks, like most ordinary gdb commands, should use 150571 filtered output. I found a few that did not, so this patch changes 150572 them to use the filtered form. 150573 1505742021-12-29 Tom Tromey <tom@tromey.com> 150575 150576 Consistently Use ui_file parameter to show callbacks 150577 I happened to notice that one "show" callback was printing to 150578 gdb_stdout rather than to the passed-in ui_file parameter. I went 150579 through all such callbacks and fixed them to consistently use the 150580 ui_file. 150581 150582 Regression tested on x86-64 Fedora 34. 150583 1505842021-12-29 Tom Tromey <tom@tromey.com> 150585 150586 Use gdb_stdlog for MI debugging 150587 When MI debugging is enabled, the logging output should be sent to 150588 gdb_stdlog. This is part of PR gdb/7233. 150589 150590 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150591 1505922021-12-29 Tom Tromey <tom@tromey.com> 150593 150594 Use debug_prefixed_printf_cond_nofunc in index-cache 150595 This changes index-cache.c to use debug_prefixed_printf_cond_nofunc. 150596 As a side effect, logs are now written to gdb_stdlog. This is part of 150597 PR gdb/7233. 150598 150599 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150600 1506012021-12-29 Tom Tromey <tom@tromey.com> 150602 150603 Send minsym logging to gdb_stdlog 150604 This changes minsyms.c to send logging output to gdb_stdlog. This is 150605 part of PR gdb/7233. 150606 150607 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150608 1506092021-12-29 Tom Tromey <tom@tromey.com> 150610 150611 Use gdb_stdlog for separate debug file logging 150612 This changes the separate debug file logging code (spread across two 150613 files) to use gdb_stdlog for its output. This is part of PR gdb/7233. 150614 150615 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150616 1506172021-12-29 Tom Tromey <tom@tromey.com> 150618 150619 Use debug_prefixed_printf_cond_nofunc in machoread 150620 This changes machoread.c to use debug_prefixed_printf_cond_nofunc. As 150621 a side effect, the logs are now written to gdb_stdlog. This is part 150622 of PR gdb/7233. 150623 150624 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150625 1506262021-12-29 Tom Tromey <tom@tromey.com> 150627 150628 Use debug_prefixed_printf_cond_nofunc in microblaze.c 150629 This changes microblaze.c to use the standard logging macro. As a 150630 side effect, logs will now go to gdb_stdlog. This is part of PR gdb/7233. 150631 150632 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150633 1506342021-12-29 Tom Tromey <tom@tromey.com> 150635 150636 Send debugging data to gdb_stdlog in mips-linux-nat.c 150637 This changes mips-linux-nat.c to send some logging output to 150638 gdb_stdlog, rather than stdout. This is part of PR gdb/7233. 150639 150640 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150641 1506422021-12-29 Tom Tromey <tom@tromey.com> 150643 150644 Send arch-utils error messages to gdb_stderr 150645 This changes arch-utils.c to send some error messages to gdb_stderr. 150646 This is part of PR gdb/7233. 150647 150648 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150649 1506502021-12-29 Tom Tromey <tom@tromey.com> 150651 150652 Use correct stream for process record output 150653 The process record code often emits unfiltered output. In some cases, 150654 this output ought to go to gdb_stderr (but see below). In other 150655 cases, the output is guarded by a logging variable and so ought to go 150656 to gdb_stdlog. This patch makes these changes. 150657 150658 Note that in many cases, the output to stderr is followed by a 150659 "return -1", which is how process record indicates an error. It seems 150660 to me that calling error here would be preferable, because, in many 150661 cases, that's all the caller does when it sees a -1. However, I 150662 haven't made this change. 150663 150664 This is part of PR gdb/7233. 150665 150666 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150667 1506682021-12-29 Tom Tromey <tom@tromey.com> 150669 150670 Send jit.c errors to gdb_stderr 150671 jit.c writes some error messages to gdb_stdout, but using gdb_stderr 150672 is better. This is part of PR gdb/7233. 150673 150674 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233 150675 1506762021-12-29 Tom Tromey <tom@tromey.com> 150677 150678 Fix logging redirection bug with pager 150679 I noticed yesterday that if gdb output is redirected to a file, the 150680 pager will still be active. This is irritating, because the output 150681 isn't actually visible -- just the pager prompt. Looking in bugzilla, 150682 I found that this had been filed 17 years ago, as PR cli/8798. 150683 150684 This patch fixes the bug. It changes the pagination code to query the 150685 particular ui-file to see if paging is allowable. The ui-file 150686 implementations are changed so that only the stdout implementation and 150687 a tee (where one sub-file is stdout) can page. 150688 150689 Regression tested on x86-64 Fedora 34. 150690 150691 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8798 150692 1506932021-12-29 Tom Tromey <tom@tromey.com> 150694 150695 Remove unusual use of core_addr_eq and core_addr_hash 150696 gdbtypes.h uses core_addr_eq and core_addr_hash in a weird way: taking 150697 the address of a member and then passing this (as a void*) to these 150698 functions. 150699 150700 It seems better to simply inline the ordinary code here. CORE_ADDR is 150701 a scalar so it can be directly compared, and the identity hash 150702 function seems safe to assume as well. 150703 150704 After this, core_addr_eq and core_addr_hash are unused, so this patch 150705 removes them. 150706 1507072021-12-29 Lancelot SIX <lancelot.six@amd.com> 150708 150709 gdb: Copy inferior properties in clone-inferior 150710 This commit ensures that the following settings are cloned from one 150711 inferior to the new one when processing the clone-inferior command: 150712 - inferior-tty 150713 - environment variables 150714 - cwd 150715 - args 150716 150717 Some of those parameters can be passed as command line arguments to GDB 150718 (-args and -tty), so one could expect the clone-inferior to respect 150719 those flags. The following debugging session illustrates that: 150720 150721 gdb -nx -quiet -batch \ 150722 -ex "show args" \ 150723 -ex "show inferior-tty" \ 150724 -ex "clone-inferior" \ 150725 -ex "inferior 2" \ 150726 -ex "show args" \ 150727 -ex "show inferior-tty" \ 150728 -tty=/some/tty \ 150729 -args echo foo bar 150730 Argument list to give program being debugged when it is started is "foo bar". 150731 Terminal for future runs of program being debugged is "/some/tty". 150732 [New inferior 2] 150733 Added inferior 2. 150734 [Switching to inferior 2 [<null>] (/bin/echo)] 150735 Argument list to give program being debugged when it is started is "". 150736 Terminal for future runs of program being debugged is "". 150737 150738 The other properties this commit copies on clone (i.e. CWD and the 150739 environment variables) are included since they are related (in the sense 150740 that they influence the runtime behavior of the program) even if they 150741 cannot be directly set using command line switches. 150742 150743 There is a chance that this patch changes existing user workflow. I 150744 think that this change is mostly harmless. If users want to start a new 150745 inferior based on an existing one, they probably already propagate those 150746 settings to the new inferior in some way. 150747 150748 Tested on x86_64-linux. 150749 150750 Change-Id: I3b1f28b662f246228b37bb24c2ea1481567b363d 150751 1507522021-12-29 GDB Administrator <gdbadmin@sourceware.org> 150753 150754 Automatic date update in version.in 150755 1507562021-12-28 H.J. Lu <hjl.tools@gmail.com> 150757 150758 elf32-i386: Fix a typo in GOT comments 150759 Entry offsets in the global offset table are multiples of 4, not 8. 150760 150761 * elf32-i386.c (elf_i386_relocate_section): Fix a typo in GOT 150762 comments. 150763 1507642021-12-28 H.J. Lu <hjl.tools@gmail.com> 150765 150766 bfd: Don't check non-thin archive member file size 150767 There is no need to check member file size for thin archive member. 150768 150769 * bfdio.c (bfd_bread): Don't check non-thin archive member file 150770 size. 150771 1507722021-12-28 Alan Modra <amodra@gmail.com> 150773 150774 gas reloc sorting 150775 In some cases, eg. riscv_pre_output_hook, gas generates out-of-order 150776 relocations. Various places in the linker assume relocs are sorted 150777 by increasing r_offset, which is normally the case. Provide 150778 GAS_SORT_RELOCS to handle unsorted relocs. 150779 150780 bfd/ 150781 PR 28709 150782 * elf32-nds32.c (nds32_insertion_sort): Make static. 150783 * elf32-nds32.h (nds32_insertion_sort): Delete declaration. 150784 gas/ 150785 PR 28709 150786 * write.c (write_relocs): Implement reloc sorting by r_offset 150787 when GAS_SORT_RELOCS. 150788 * config/tc-nds32.c (compar_relent, nds32_set_section_relocs): Delete. 150789 * config/tc-nds32.h (nds32_set_section_relocs): Don't declare. 150790 (SET_SECTION_RELOCS): Don't define. 150791 (GAS_SORT_RELOCS): Define. 150792 * config/tc-riscv.h (GAS_SORT_RELOCS): Define. 150793 1507942021-12-28 jiawei <jiawei@iscas.ac.cn> 150795 150796 ld: Fix testcase errors due to -shared not support. 150797 Reviewed-by: Jim Wilson <jim.wilson.gcc@gmail.com> 150798 150799 ld/ChangeLog: 150800 150801 * testsuite/ld-ctf/ctf.exp: Add shared lib check. 150802 * testsuite/ld-plugin/lto.exp: Add lto shared check. 150803 1508042021-12-28 GDB Administrator <gdbadmin@sourceware.org> 150805 150806 Automatic date update in version.in 150807 1508082021-12-27 H.J. Lu <hjl.tools@gmail.com> 150809 150810 elf: Update comments for check_relocs in elf_backend_data 150811 Since 150812 150813 commit 5c3261b0e834647cf9eb555320e20871b7854f98 150814 Author: H.J. Lu <hjl.tools@gmail.com> 150815 Date: Mon Oct 16 03:49:54 2017 -0700 150816 150817 ELF: Call check_relocs after opening all inputs 150818 150819 check_relocs is called after opening all inputs. 150820 150821 * elf-bfd.h (elf_backend_data::check_relocs): Update comments. 150822 1508232021-12-27 H.J. Lu <hjl.tools@gmail.com> 150824 150825 ld: Remove emultempl/linux.em 150826 Remove emultempl/linux.em whose last usage was removed by 150827 150828 commit c65c21e1ffd1e02d9970a4bca0b7e384788a50f0 150829 Author: Alan Modra <amodra@gmail.com> 150830 Date: Mon Apr 16 22:14:01 2018 +0930 150831 150832 various i386-aout and i386-coff target removal 150833 150834 Also tidies some other aout leftovers in binutils-common.exp. 150835 1508362021-12-27 GDB Administrator <gdbadmin@sourceware.org> 150837 150838 Automatic date update in version.in 150839 1508402021-12-26 GDB Administrator <gdbadmin@sourceware.org> 150841 150842 Automatic date update in version.in 150843 1508442021-12-25 GDB Administrator <gdbadmin@sourceware.org> 150845 150846 Automatic date update in version.in 150847 1508482021-12-24 Tom Tromey <tom@tromey.com> 150849 150850 Remove gdb_print_host_address 150851 gdb_print_host_address is just a simple wrapper around 150852 fprintf_filtered. However, it is readily replaced in all callers by a 150853 combination of %s and call to host_address_to_string. This also 150854 simplifies the code, so I think it's worthwhile to remove this 150855 function. 150856 150857 Regression tested on x86-64 Fedora 64. 150858 1508592021-12-24 Tom Tromey <tom@tromey.com> 150860 150861 Move gdb_bfd_errmsg to gdb_bfd.c 150862 gdb_bfd.c contains most of gdb's BFD-related utility functions. 150863 However, gdb_bfd_errmsg is in utils.c. It seemed better to me to move 150864 this out of util.[ch] and into the BFD-related file instead. 150865 150866 Tested by rebuilding. 150867 1508682021-12-24 Nelson Chu <nelson.chu@sifive.com> 150869 150870 RISC-V: Rewrite the csr testcases. 150871 Maskray (Fangrui Song) had suggested me before that we should combine 150872 multiple testcases into one file as possible as we can. So that we can 150873 more easily understand what these test cases are testing, and easier to 150874 maintain. Therefore, this patch rewrites all csr testcases, to make them 150875 more clean. 150876 150877 gas/ 150878 * testsuite/gas/riscv/csr-fail-nonexistent.d: Renamed from 150879 priv-reg-fail-nonexistent testcase. 150880 * testsuite/gas/riscv/csr-fail-nonexistent.: Likewise. 150881 * testsuite/gas/riscv/csr-fail-nonexistent.s: Likewise. 150882 * testsuite/gas/riscv/csr-insns-pseudo-noalias.d: Renamed from 150883 priv-reg-pseudo testcase. 150884 * testsuite/gas/riscv/csr-insns-pseudo.d: Likewise. 150885 * testsuite/gas/riscv/csr-insns-pseudo.s: Likewise. 150886 * testsuite/gas/riscv/csr-insns-read-only.d: Renamed from 150887 priv-reg-fail-read-only-02 testcase. 150888 * testsuite/gas/riscv/csr-insns-read-only.l: Likewise. 150889 * testsuite/gas/riscv/csr-insns-read-only.s: Likewise. 150890 * testsuite/gas/riscv/h-ext-32.d: Moved hypervisor csrs to csr.s. 150891 * testsuite/gas/riscv/h-ext-32.s: Likewise. 150892 * testsuite/gas/riscv/h-ext-64.d: Likewise. 150893 * testsuite/gas/riscv/h-ext-64.s: Likewise. 150894 * testsuite/gas/riscv/csr.s: Renamed from priv-reg.s, and then 150895 added the hypervisor csrs. 150896 * testsuite/gas/riscv/csr-version-1p9p1.d: The csr testcase when 150897 the privileged spec is 1.9.1. Also tested all invalid csr warnings 150898 when -mcsr-check is enabled. 150899 * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. 150900 * testsuite/gas/riscv/csr-version-1p10.d: Likewise, but the 150901 privileged spec is 1.10.. 150902 * testsuite/gas/riscv/csr-version-1p10.l: Likewise. 150903 * testsuite/gas/riscv/csr-version-1p11.d: Likewise, but the 150904 privileged spec is 1.11. 150905 * testsuite/gas/riscv/csr-version-1p11.l: Likewise. 150906 * testsuite/gas/riscv/csr-version-1p12.d: Likewise, but the 150907 privileged spec is 1.12. 150908 * testsuite/gas/riscv/csr-version-1p12.l: Likewise. 150909 * testsuite/gas/riscv/priv-reg*: Removed or Renamed. 150910 1509112021-12-24 Vineet Gupta <vineetg@rivosinc.com> 150912 150913 RISC-V: Hypervisor ext: support Privileged Spec 1.12 150914 This is the Hypervisor Extension 1.0 150915 150916 - Hypervisor Memory-Management Instructions 150917 HFENCE.VVMA, HFENCE.GVMA, 150918 150919 - Hypervisor Virtual Machine Load and Store Instructions 150920 HLV.B, HLV.BU, HSV.B, 150921 HLV.H, HLV.HU, HLVX.HU, HSB.H, 150922 HLV.W, HLV.WU, HLVX.WU, HSV.W, 150923 HLV.D, HSV.D 150924 150925 - Hypervisor CSRs (some new, some address changed) 150926 hstatus, hedeleg, hideleg, hie, hcounteren, hgeie, htval, hip, hvip, 150927 htinst, hgeip, henvcfg, henvcfgh, hgatp, hcontext, htimedelta, htimedeltah, 150928 vsstatus, vsie, vstvec, vsscratch, vsepc, vscause, vstval, vsip, vsatp, 150929 150930 Note that following were added already as part of svinval extension 150931 support: 150932 HINVAL.GVMA, HINVAL.VVMA 150933 150934 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 150935 Reviewed-by: Nelson Chu <nelson.chu@sifive.com> 150936 150937 bfd/ 150938 * cpu-riscv.c (riscv_priv_specs): Added entry for 1.12. 150939 * cpu-riscv.h (enum riscv_spec_class): Added PRIV_SPEC_CLASS_1P12. 150940 gas/ 150941 * config/tc-riscv.c (abort_version): Updated comment. 150942 (validate_riscv_insn): Annotate switch-break. 150943 * testsuite/gas/riscv/h-ext-32.d: New testcase for hypervisor. 150944 * testsuite/gas/riscv/h-ext-32.s: Likewise. 150945 * testsuite/gas/riscv/h-ext-64.d: Likewise. 150946 * testsuite/gas/riscv/h-ext-64.s: Likewise. 150947 include/ 150948 * opcode/riscv-opc.h: Added encodings for hypervisor csrs and 150949 instrcutions. 150950 opcodes/ 150951 * riscv-opc.c (riscv_opcodes): Added hypervisor instrcutions. 150952 1509532021-12-24 Vineet Gupta <vineetg@rivosinc.com> 150954 150955 RISC-V: Hypervisor ext: drop Privileged Spec 1.9.1 implementation/tests 150956 This makes way for a clean 1.12 based Hypervisor Ext support. 150957 150958 There are no known implementors of 1.9.1 H-ext. (Per Jim, kendryte k210 150959 is based on priv spec 1.9.1, but it seems unlikely that they implemented 150960 H-ext). 150961 150962 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 150963 Reviewed-by: Nelson Chu <nelson.chu@sifive.com> 150964 150965 gas/ 150966 * testsuite/gas/riscv/csr-dw-regnums.d: Drop the hypervisor csrs 150967 defined in the privileged spec 1.9.1. 150968 * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. 150969 * testsuite/gas/riscv/priv-reg-fail-read-only-01.s: Likewise. 150970 * testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise. 150971 * testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise. 150972 * testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise. 150973 * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise. 150974 * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise. 150975 * testsuite/gas/riscv/priv-reg.s: Likewise. 150976 include/ 150977 * opcode/riscv-opc.h: Drop the hypervisor csrs defined in the 150978 privileged spec 1.9.1. 150979 1509802021-12-24 GDB Administrator <gdbadmin@sourceware.org> 150981 150982 Automatic date update in version.in 150983 1509842021-12-23 Andrew Burgess <aburgess@redhat.com> 150985 150986 gdb/testsuite: resolve some duplicate testnames in gdb.mi 150987 Set of fixes to resolve some duplicate test names in the gdb.mi/ 150988 directory. There should be no real test changes after this set of 150989 fixes, they are all either: 150990 150991 - Adding with_test_prefix type constructs to make test names unique, 150992 or 150993 150994 - Changing the test name to be more descriptive, or better reflect 150995 the test being run. 150996 1509972021-12-23 Andrew Burgess <andrew.burgess@embecosm.com> 150998 150999 gdb/remote: handle attach when stop packet lacks thread-id 151000 Bug PR gdb/28405 reports a regression when using attach with an 151001 extended-remote target. In this case the target is not including a 151002 thread-id in the stop packet it sends back after the attach. 151003 151004 The regression was introduced with this commit: 151005 151006 commit 8f66807b98f7634c43149ea62e454ea8f877691d 151007 Date: Wed Jan 13 20:26:58 2021 -0500 151008 151009 gdb: better handling of 'S' packets 151010 151011 The problem is that when GDB processes the stop packet, it sees that 151012 there is no thread-id and so has to "guess" which thread the stop 151013 should apply to. 151014 151015 In this case the target only has one thread, so really, there's no 151016 guessing needed, but GDB still runs through the same process, this 151017 shouldn't cause us any problems. 151018 151019 However, after the above commit, GDB now expects itself to be more 151020 internally consistent, specifically, only a thread that GDB thinks is 151021 resumed, can be a candidate for having stopped. 151022 151023 It turns out that, when GDB attaches to a process through an 151024 extended-remote target, the threads of the process being attached too, 151025 are not, initially, marked as resumed. 151026 151027 And so, when GDB tries to figure out which thread the stop might apply 151028 too, it finds no threads in the processes marked resumed, and so an 151029 assert triggers. 151030 151031 In extended_remote_target::attach we create a new thread with a call 151032 to add_thread_silent, rather than remote_target::remote_add_thread, 151033 the reason is that calling the latter will result in a call to 151034 'add_thread' rather than 'add_thread_silent'. However, 151035 remote_target::remote_add_thread includes additional 151036 actions (i.e. calling remote_thread_info::set_resumed and set_running) 151037 which are missing from extended_remote_target::attach. These missing 151038 calls are what would serve to mark the new thread as resumed. 151039 151040 In this commit I propose that we add an extra parameter to 151041 remote_target::remote_add_thread. This new parameter will force the 151042 new thread to be added with a call to add_thread_silent. We can now 151043 call remote_add_thread from the ::attach method, the extra 151044 actions (listed above) will now be performed, and the thread will be 151045 left in the correct state. 151046 151047 Additionally, in PR gdb/28405, a segfault is reported. This segfault 151048 triggers when 'set debug remote 1' is used before trying to reproduce 151049 the original assertion failure. The cause of this is in 151050 remote_target::select_thread_for_ambiguous_stop_reply, where we do 151051 this: 151052 151053 remote_debug_printf ("first resumed thread is %s", 151054 pid_to_str (first_resumed_thread->ptid).c_str ()); 151055 remote_debug_printf ("is this guess ambiguous? = %d", ambiguous); 151056 151057 gdb_assert (first_resumed_thread != nullptr); 151058 151059 Notice that when debug printing is on we dereference 151060 first_resumed_thread before we assert that the pointer is not 151061 nullptr. This is the cause of the segfault, and is resolved by moving 151062 the assert before the debug printing code. 151063 151064 I've extended an existing test, ext-attach.exp, so that the original 151065 test is run multiple times; we run in the original mode, as normal, 151066 but also, we now run with different packets disabled in gdbserver. In 151067 particular, disabling Tthread would trigger the assertion as it was 151068 reported in the original bug. I also run the test in all-stop and 151069 non-stop modes now for extra coverage, we also run the tests with 151070 target-async enabled, and disabled. 151071 151072 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28405 151073 1510742021-12-23 Andrew Burgess <aburgess@redhat.com> 151075 151076 gdb: on x86-64 non-trivial C++ objects are returned in memory 151077 Fixes PR gdb/28681. It was observed that after using the `finish` 151078 command an incorrect value was displayed in some cases. Specifically, 151079 this behaviour was observed on an x86-64 target. 151080 151081 Consider this test program: 151082 151083 struct A 151084 { 151085 int i; 151086 151087 A () 151088 { this->i = 0; } 151089 A (const A& a) 151090 { this->i = a.i; } 151091 }; 151092 151093 A 151094 func (int i) 151095 { 151096 A a; 151097 a.i = i; 151098 return a; 151099 } 151100 151101 int 151102 main () 151103 { 151104 A a = func (3); 151105 return a.i; 151106 } 151107 151108 And this GDB session: 151109 151110 $ gdb -q ex.x 151111 Reading symbols from ex.x... 151112 (gdb) b func 151113 Breakpoint 1 at 0x401115: file ex.cc, line 14. 151114 (gdb) r 151115 Starting program: /home/andrew/tmp/ex.x 151116 151117 Breakpoint 1, func (i=3) at ex.cc:14 151118 14 A a; 151119 (gdb) finish 151120 Run till exit from #0 func (i=3) at ex.cc:14 151121 main () at ex.cc:23 151122 23 return a.i; 151123 Value returned is $1 = { 151124 i = -19044 151125 } 151126 (gdb) p a 151127 $2 = { 151128 i = 3 151129 } 151130 (gdb) 151131 151132 Notice how after the `finish` the contents of $1 are junk, but, when I 151133 immediately ask for the value of `a`, I get back the correct value. 151134 151135 The problem here is that after the finish command GDB calls the 151136 function amd64_return_value to figure out where the return value can 151137 be found (on x86-64 targets anyway). 151138 151139 This function makes the wrong choice for the struct A in our case, as 151140 sizeof(A) <= 8, then amd64_return_value decides that A will be 151141 returned in a register. GDB then reads the return value register an 151142 interprets the contents as an instance of A. 151143 151144 Unfortunately, A is not trivially copyable (due to its copy 151145 constructor), and the sys-v specification for argument and return 151146 value passing, says that any non-trivial C++ object should have space 151147 allocated for it by the caller, and the address of this space is 151148 passed to the callee as a hidden first argument. The callee should 151149 then return the address of this space as the return value. 151150 151151 And so, the register that GDB is treating as containing an instance of 151152 A, actually contains the address of an instance of A (in this case on 151153 the stack), this is why GDB shows the incorrect result. 151154 151155 The call stack within GDB for where we actually go wrong is this: 151156 151157 amd64_return_value 151158 amd64_classify 151159 amd64_classify_aggregate 151160 151161 And it is in amd64_classify_aggregate that we should be classifying 151162 the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently 151163 do (via a call to amd64_classify_aggregate_field). 151164 151165 At the top of amd64_classify_aggregate we already have this logic: 151166 151167 if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type)) 151168 { 151169 theclass[0] = theclass[1] = AMD64_MEMORY; 151170 return; 151171 } 151172 151173 Which handles some easy cases where we know a struct will be placed 151174 into memory, that is (a) the struct is more than 16-bytes in size, 151175 or (b) the struct has any unaligned fields. 151176 151177 All we need then, is to add a check here to see if the struct is 151178 trivially copyable. If it is not then we know the struct will be 151179 passed in memory. 151180 151181 I originally structured the code like this: 151182 151183 if (TYPE_LENGTH (type) > 16 151184 || amd64_has_unaligned_fields (type) 151185 || !language_pass_by_reference (type).trivially_copyable) 151186 { 151187 theclass[0] = theclass[1] = AMD64_MEMORY; 151188 return; 151189 } 151190 151191 This solved the example from the bug, and my small example above. So 151192 then I started adding some more extensive tests to the GDB testsuite, 151193 and I ran into a problem. I hit this error: 151194 151195 gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed. 151196 151197 This problem is triggered from: 151198 151199 amd64_classify_aggregate 151200 amd64_has_unaligned_fields 151201 field::loc_bitpos 151202 151203 Inside the unaligned field check we try to get the bit position of 151204 each field. Unfortunately, in some cases the field location is not 151205 FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK. 151206 151207 An example that shows this bug is: 151208 151209 struct B 151210 { 151211 short j; 151212 }; 151213 151214 struct A : virtual public B 151215 { 151216 short i; 151217 151218 A () 151219 { this->i = 0; } 151220 A (const A& a) 151221 { this->i = a.i; } 151222 }; 151223 151224 A 151225 func (int i) 151226 { 151227 A a; 151228 a.i = i; 151229 return a; 151230 } 151231 151232 int 151233 main () 151234 { 151235 A a = func (3); 151236 return a.i; 151237 } 151238 151239 It is the virtual base class, B, that causes the problem. The base 151240 class is represented, within GDB, as a field within A. However, the 151241 location type for this field is a DWARF_BLOCK. 151242 151243 I spent a little time trying to figure out how to convert the 151244 DWARF_BLOCK to a BITPOS, however, I realised that, in this case at 151245 least, conversion is not needed. 151246 151247 The C++ standard says that a class is not trivially copyable if it has 151248 any virtual base classes. And so, in this case, even if I could 151249 figure out the BITPOS for the virtual base class fields, I know for 151250 sure that I would immediately fail the trivially_copyable check. So, 151251 lets just reorder the checks in amd64_classify_aggregate to: 151252 151253 if (TYPE_LENGTH (type) > 16 151254 || !language_pass_by_reference (type).trivially_copyable 151255 || amd64_has_unaligned_fields (type)) 151256 { 151257 theclass[0] = theclass[1] = AMD64_MEMORY; 151258 return; 151259 } 151260 151261 Now, if we have a class with virtual bases we will fail quicker, and 151262 avoid the unaligned fields check completely. 151263 151264 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28681 151265 1512662021-12-23 Andrew Burgess <aburgess@redhat.com> 151267 151268 gdb: make use of SCOPE_EXIT to manage thread executing state 151269 While working on another patch relating to how GDB manages threads 151270 executing and resumed state, I spotted the following code in 151271 record-btrace.c: 151272 151273 executing = tp->executing (); 151274 set_executing (proc_target, inferior_ptid, false); 151275 151276 id = null_frame_id; 151277 try 151278 { 151279 id = get_frame_id (get_current_frame ()); 151280 } 151281 catch (const gdb_exception &except) 151282 { 151283 /* Restore the previous execution state. */ 151284 set_executing (proc_target, inferior_ptid, executing); 151285 151286 throw; 151287 } 151288 151289 /* Restore the previous execution state. */ 151290 set_executing (proc_target, inferior_ptid, executing); 151291 151292 return id; 151293 151294 I notice that we only catch the exception so we can call 151295 set_executing, and this is the same call to set_executing that we need 151296 to perform in the non-exception return path. 151297 151298 This would be much cleaner if we could use SCOPE_EXIT to avoid the 151299 try/catch, so lets do that. 151300 151301 While cleaning this up, I also applied a similar patch to 151302 record-full.c, though there's no try/catch in that case, but using 151303 SCOPE_EXIT makes the code safe if, in the future, we do start throwing 151304 exceptions. 151305 151306 There should be no user visible changes after this commit. 151307 1513082021-12-23 GDB Administrator <gdbadmin@sourceware.org> 151309 151310 Automatic date update in version.in 151311 1513122021-12-22 Andrew Burgess <aburgess@redhat.com> 151313 151314 gdb/doc: add some index entries relating to mi-async setting 151315 I noticed that the mi-async setting was not referenced from the index 151316 in any way, this commit tries to rectify that a bit. 151317 151318 The @cindex lines I think are not controversial, these same index 151319 entries are used elsewhere in the manual for async related topics (see 151320 @node Background Execution). 151321 151322 The only bit that might be controversial is that I've added a @kindex 151323 entry for 'set mi-async' when the command is documented as '-gdb-set 151324 mi-async' (with a similar difference for the show/-gdb-show). 151325 151326 My reasoning here is that nothing else is indexed under -gdb-set or 151327 -gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for 151328 set/show anything that is documented under set/show can be adjusted 151329 using -gdb-set/-gdbshow, and so, I've tried to keep the index 151330 consistent for mi-async. 151331 1513322021-12-22 Andrew Burgess <aburgess@redhat.com> 151333 151334 gdb: convert 'set debug lin-lwp' to a boolean command 151335 Convert the 'set debug lin-lwp' command to a boolean. Adds a new 151336 LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one 151337 place (linux_nat_target::stop). 151338 151339 The manual entry for 'set debug lin-lwp' is already vague about 151340 exactly what arguments this command takes, and the description talks 151341 about turning debug on and off, so I don't think there's any updates 151342 required there. 151343 151344 I have updated the doc strings shown when the users enters 'help show 151345 debug lin-lwp' or 'help show debug lin-lwp'. The old title lines used 151346 to talk about the 'GNU/Linux lwp module', but this debug flag is now 151347 used for any native linux target debug, so we now talk about 151348 'GNU/Linux native target'. The body string for this setting has been 151349 changed from 'Enables printf debugging output.' to 'When on, print 151350 debug messages relating to the GNU/Linux native target.', the old 151351 value looks like a cut&paste error to me. 151352 1513532021-12-22 Andrew Burgess <aburgess@redhat.com> 151354 151355 gdb: add threads debugging switch 151356 Add new commands: 151357 151358 set debug threads on|off 151359 show debug threads 151360 151361 Prints additional debug information relating to thread creation and 151362 deletion. 151363 151364 GDB already announces when threads are created of course.... most of 151365 the time, but sometimes threads are added silently, in which case this 151366 debug message is the only mechanism to see the thread being added. 151367 Also, though GDB does announce when a thread exits, it doesn't 151368 announce when the thread object is deleted, I've added a debug message 151369 for that. 151370 151371 Additionally, having message printed through the debug system will 151372 cause the messages to be nested to an appropriate depth when other 151373 debug sub-systems are turned on (especially things like `infrun` and 151374 `lin-lwp`). 151375 1513762021-12-22 jiawei <jiawei@iscas.ac.cn> 151377 151378 RISC-V: Update Scalar Crypto testcases. 151379 Add opcodes in testcases to make sure every instruction generate 151380 right opcode after disassemble. 151381 151382 gas/ChangeLog: 151383 151384 * testsuite/gas/riscv/k-ext-64.d: Add opcode detect. 151385 * testsuite/gas/riscv/k-ext.d: Ditto. 151386 * testsuite/gas/riscv/zbkb-32.d: Ditto. 151387 * testsuite/gas/riscv/zbkb-64.d: Ditto. 151388 * testsuite/gas/riscv/zbkc-32.d: Ditto. 151389 * testsuite/gas/riscv/zbkc-64.d: Ditto. 151390 * testsuite/gas/riscv/zbkx-32.d: Ditto. 151391 * testsuite/gas/riscv/zbkx-64.d: Ditto. 151392 * testsuite/gas/riscv/zknd-32.d: Ditto. 151393 * testsuite/gas/riscv/zknd-64.d: Ditto. 151394 * testsuite/gas/riscv/zkne-32.d: Ditto. 151395 * testsuite/gas/riscv/zkne-64.d: Ditto. 151396 * testsuite/gas/riscv/zknh-32.d: Ditto. 151397 * testsuite/gas/riscv/zknh-64.d: Ditto. 151398 * testsuite/gas/riscv/zksed-32.d: Ditto. 151399 * testsuite/gas/riscv/zksed-64.d: Ditto. 151400 * testsuite/gas/riscv/zksh-32.d: Ditto. 151401 * testsuite/gas/riscv/zksh-64.d: Ditto. 151402 1514032021-12-22 Simon Marchi <simon.marchi@polymtl.ca> 151404 151405 gdbarch-components.py: change empty "params" tuples to empty lists 151406 During review, it was suggested to change the "params" parameter from a 151407 tuple to a list, for esthetic reasons. The empty ones are still tuples 151408 though, they should probably be changed to be empty lists, for 151409 consistency. It does not change anything in the script result. 151410 151411 Change-Id: If13c6c527aa167a5ee5b45740e5f1bda1e9517e4 151412 1514132021-12-22 GDB Administrator <gdbadmin@sourceware.org> 151414 151415 Automatic date update in version.in 151416 1514172021-12-21 Luis Machado <luis.machado@linaro.org> 151418 151419 [AArch64] Fix typo in error messages 151420 Fix mispelling of PROT_ME to PROT_MTE in the error messages. 151421 1514222021-12-21 Joel Sherrill <joel@rtems.org> 151423 151424 Obsolete m32c-rtems and m32r-rtems 151425 2020-12-20 Joel Sherrill <joel@rtems.org> 151426 151427 bfd/ 151428 * config.bfd (m32c-*-rtems*): Remove target. 151429 151430 ld/ 151431 * configure.tgt (m32c-*-rtems*): Remove target. 151432 * configure.tgt (m32r-*-rtems*): Remove target. 151433 1514342021-12-21 Jan Beulich <jbeulich@suse.com> 151435 151436 x86: -mfence-as-lock-add=yes doesn't work for 16-bit mode 151437 Rather than trying to fix this (which would require making an assumption 151438 on the upper half of %esp being zero), simply issue an error. While at 151439 it, since the generated code is in conflict with -momit-lock-prefix=yes, 151440 issue an error in that case as well. 151441 151442 gas/ELF: avoid below-base ref in obj_elf_parse_section_letters() 151443 We would better be prepared for 'm' being the first character of the 151444 incoming string. 151445 1514462021-12-21 Alan Modra <amodra@gmail.com> 151447 151448 Typo fixes in binutils doc 151449 * doc/binutils.texi: Fix typos. 151450 1514512021-12-21 GDB Administrator <gdbadmin@sourceware.org> 151452 151453 Automatic date update in version.in 151454 1514552021-12-20 Tom Tromey <tom@tromey.com> 151456 151457 Remove print_spaces 151458 This removes the print_spaces helper function, in favor of using the 151459 "*%s" idiom that's already used in many places in gdb. One spot (in 151460 symmisc.c) is changed to use print_spaces_filtered, because the rest 151461 of that function is using filtered output. (This highlights one way 151462 that the printf idiom is better -- this error is harder to make when 151463 using that.) 151464 151465 Regression tested on x86-64 Fedora 34. 151466 1514672021-12-20 Tom Tromey <tom@tromey.com> 151468 151469 Remove puts_debug 151470 I noticed that puts_debug isn't used in the tree. git log tells me 151471 that the last use was removed in 2015: 151472 151473 commit 40e0b27177e747600d3ec186458fe0e482a1cf77 151474 Author: Pedro Alves <palves@redhat.com> 151475 Date: Mon Aug 24 15:40:26 2015 +0100 151476 151477 Delete the remaining ROM monitor targets 151478 151479 ... and this commit mentions that the code being removed here probably 151480 hadn't worked for 6 years prior to that. 151481 151482 Based on this, I'm removing puts_debug. I don't think it's useful. 151483 Tested by rebuilding. 151484 1514852021-12-20 Tom Tromey <tom@tromey.com> 151486 151487 Make n_spaces return a const char * 151488 n_spaces keeps the spaces in a static buffer. If a caller overwrites 151489 these, it may give an incorrect result to a subsequent caller. So, 151490 make the return type const to help avoid this outcome. 151491 1514922021-12-20 Enze Li <lienze2010@hotmail.com> 151493 151494 Add Enze Li to gdb/MAINTAINERS 151495 1514962021-12-20 Joel Brobecker <brobecker@adacore.com> 151497 151498 gdb/ada-exp.y: Reformat comment to follow GDB's coding standards 151499 This commit reformats a comment in gdb/ada-exp.y to avoid 151500 the leading '*' at the beginning of each line of the comment. 151501 151502 gdb/ada-lang.h: Reformat comment to follow coding standards 151503 This commit reformats a comment in gdb/ada-lang.h to avoid 151504 the leading '*' at the beginning of each line of the comment. 151505 1515062021-12-20 GDB Administrator <gdbadmin@sourceware.org> 151507 151508 Automatic date update in version.in 151509 1515102021-12-19 Alan Modra <amodra@gmail.com> 151511 151512 Obsolete m32c-rtems 151513 151514 readelf: avoid a possible divide by zero 151515 * readelf.c (process_section_headers): Check SHT_RELR entsize. 151516 1515172021-12-19 GDB Administrator <gdbadmin@sourceware.org> 151518 151519 Automatic date update in version.in 151520 1515212021-12-18 Enze Li <lienze2010@hotmail.com> 151522 151523 gdb: add "exit" command as an alias for "quit" 151524 This command adds the "exit" command as an alias for the "quit" 151525 command, as requested in PR gdb/28406. 151526 151527 The documentation is also updated to mention this new command. 151528 151529 Tested on x86_64-linux. 151530 151531 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28406 151532 1515332021-12-18 Andrew Burgess <aburgess@redhat.com> 151534 151535 gdb: add assert in remote_target::wait relating to async being off 151536 While working on another patch I ended up in a situation where I had 151537 async mode disabled (with 'maint set target-async off'), but the async 151538 event token got marked anyway. 151539 151540 In this situation GDB was continually calling into 151541 remote_target::wait, however, the async token would never become 151542 unmarked as the unmarking is guarded by target_is_async_p. 151543 151544 We could just unconditionally unmark the token, but that would feel 151545 like just ignoring a bug, so, instead, lets assert that if 151546 !target_is_async_p, then the async token should not be marked. 151547 151548 This assertion would have caught my earlier mistake. 151549 151550 There should be no user visible changes with this commit. 151551 1515522021-12-18 Andrew Burgess <aburgess@redhat.com> 151553 151554 gdb/remote: some fixes for 'maint set target-async off' 151555 While working on another patch relating to remote targets, I wanted to 151556 test with 'maint set target-async off' in place. Unfortunately I ran 151557 into some problems. This commit is an attempt to fix one of the 151558 issues I hit. 151559 151560 In my particular case I was actually running with: 151561 151562 maint set target-async off 151563 maint set target-non-stop off 151564 151565 that is, we're telling GDB to force the targets to operate in 151566 non-async mode, and in all-stop mode. Here's my GDB session showing 151567 the problem: 151568 151569 (gdb) maintenance set target-async off 151570 (gdb) maintenance set target-non-stop off 151571 (gdb) target extended-remote :54321 151572 Remote debugging using :54321 151573 (gdb) attach 2365960 151574 Attaching to process 2365960 151575 No unwaited-for children left. 151576 (gdb) 151577 151578 Notice the 'No unwaited-for children left.' error, this is the 151579 problem. There's no reason why GDB should not be able to attach to 151580 the process. 151581 151582 The problem is this: 151583 151584 1. The user runs 'attach PID' and this sends GDB into attach_command 151585 in infcmd.c. From here we call the ::attach method on the attach 151586 target, which will be the extended_remote_target. 151587 151588 2. In extended_remote_target::attach, we attach to the remote target 151589 and get the first reply (which is a stop packet). We put off 151590 processing the stop packet until the end of ::attach. We setup the 151591 inferior and thread to represent the process we attached to, and 151592 download the target description. Finally, we process the initial 151593 stop packet. 151594 151595 If '!target_is_non_stop_p ()' and '!target_can_async_p ()', which is 151596 the case for us given the maintenance commands we used, we cache the 151597 stop packet within the remote_state::buf for later processing. 151598 151599 3. Back in attach_command, if 'target_is_non_stop_p ()' then we 151600 request that the target stops. This will either process any cached 151601 stop replies, or request that the target stops, and process the stop 151602 replies. However, this code is not what we use due to non-stop mode 151603 being disabled. So, we skip to the next step which is to call 151604 validate_exec_file. 151605 151606 4. Calling validate_exec_file can cause packets to be sent to the 151607 remote target, and replies received, the first path I hit is the 151608 call to target_pid_to_exec_file, which calls 151609 remote_target::pid_to_exec_file, which can then try to read the 151610 executable from the remote. Sending an receiving packets will make 151611 use of the remote_state::buf object. 151612 151613 5. The attempt to attach continues, but the damage is already done... 151614 151615 So, the problem is that, in step #2 we cache a stop reply in the 151616 remote_state::buf, and then in step #4 we reuse the remote_state::buf 151617 object, discarding any cached stop reply. As a result, the initial 151618 stop, which is sent when GDB first attaches to the target, is lost. 151619 151620 This problem can clearly be seen, I feel, by looking at the 151621 remote_state::cached_wait_status flag. This flag tells GDB if there 151622 is a wait status cached in remote_state::buf. However, in 151623 remote_target::putpkt_binary and remote_target::getpkt_or_notif_sane_1 151624 this flag is just set back to 0, doing this immediately discards any 151625 cached data. 151626 151627 I don't know if this scheme ever made sense, looking at commit 151628 2d717e4f8a54, where the cached_wait_status flag was added, it appears 151629 that there was nothing between where the stop was cached, and where 151630 the stop was consumed, so, I suspect, there never was a situation 151631 where we ended up in putpkt_binary or getpkt_or_notif_sane_1 and 151632 needed to clear to the flag, maybe the clearing was added "just in 151633 case". Whatever the history, I claim that this clearing this flag is 151634 no longer a good idea. 151635 151636 So, my first step toward fixing this issue was to replace the two 151637 instances of 'rs->cached_wait_status = 0;' in ::putpkt_binary and 151638 ::getpkt_or_notif_sane_1 with 'gdb_assert (rs->cached_wait_status == 151639 0);', this, at least would show me when GDB was doing something 151640 dangerous, and indeed, this assert is now hit in my test case above. 151641 151642 I did play with using some kind of scoped restore to backup, and 151643 restore the remote_state::buf object in all the places within remote.c 151644 that I was hitting where the ::buf was being corrupted. The first 151645 problem with this is that, where the ::cached_wait_status flag is 151646 reset is _not_ where ::buf is corrupted. For the ::putpkt_binary 151647 case, by the time we get to the method the buffer has already been 151648 corrupted in many cases, so we end up needing to add the scoped 151649 save/restore within the callers, which means we need the save/restore 151650 in _lots_ of places. 151651 151652 Plus, using this save/restore model feels like the wrong solution. I 151653 don't think that it's obvious that the buffer might be holding cached 151654 data, and I think it would be too easy for new corruptions of the 151655 buffer to be introduced, which could easily go unnoticed for a long 151656 time. 151657 151658 So, I really wanted a solution that didn't require us to cache data in 151659 the ::buf object. 151660 151661 Luckily, I think we already have such a solution in place, the 151662 remote_state::stop_reply_queue, it seems like this does exactly the 151663 same task, just in a slightly different way. With the 151664 ::stop_reply_queue, the stop packets are processed upon receipt and 151665 the stop_reply object is added to the queue. With the ::buf cache 151666 solution, the unprocessed stop reply is cached in the ::buf, and 151667 processed later. 151668 151669 So, finally, in this commit, I propose to remove the 151670 remote_state::cached_wait_status flag and to stop using the ::buf to 151671 cache stop replies. Instead, stop replies will now always be stored 151672 in the ::stop_reply_queue. 151673 151674 There are two places where we use the ::buf to hold a cached stop 151675 reply, the first is in the ::attach method, and the second is in 151676 remote_target::start_remote, however, the second of these cases is far 151677 less problematic, as after caching the stop reply in ::buf we call the 151678 global start_remote function, which does very little work before 151679 calling normal_stop, which processes the cached stop reply. However, 151680 my plan is to switch both users over to using ::stop_reply_queue so 151681 that the old (unsafe) ::cached_wait_status mechanism can be completely 151682 removed. 151683 151684 The next problem is that the ::stop_reply_queue is currently only used 151685 for async-mode, and so, in remote_target::push_stop_reply, where we 151686 push stop_reply objects into the ::stop_reply_queue, we currently also 151687 mark the async event token. I've modified this so we only mark the 151688 async event token if 'target_is_async_p ()' - note, _is_, not _can_ 151689 here. The ::push_stop_reply method is called in places where async 151690 mode has been temporarily disabled, but, when async mode is switched 151691 back on (see remote_target::async) we will mark the event token if 151692 there are events in the queue. 151693 151694 Another change of interest is in remote_target::remote_interrupt_as. 151695 Previously this code checked ::cached_wait_status, but didn't check 151696 for events in the ::stop_reply_queue. Now that ::cached_wait_status 151697 has been removed we now check the queue length instead, which should 151698 have the same result. 151699 151700 Finally, in remote_target::wait_as, I've tried to merge the processing 151701 of the ::stop_reply_queue with how we used to handle the 151702 ::cached_wait_status flag. 151703 151704 Currently, when processing the ::stop_reply_queue we call 151705 process_stop_reply and immediately return. However, when handling 151706 ::cached_wait_status we run through the whole of ::wait_as, and return 151707 at the end of the function. 151708 151709 If we consider a standard stop packet, the two differences I see are: 151710 151711 1. Resetting of the remote_state::waiting_for_stop_reply, flag; this 151712 is not currently done when processing a stop from the 151713 ::stop_reply_queue. 151714 151715 2. The final return value has the possibility of being adjusted at 151716 the end of ::wait_as, as well as there being calls to 151717 record_currthread, non of which are done if we process a stop from 151718 the ::stop_reply_queue. 151719 151720 After discussion on the mailing list: 151721 151722 https://sourceware.org/pipermail/gdb-patches/2021-December/184535.html 151723 151724 it was suggested that, when an event is pushed into the 151725 ::stop_reply_queue, the ::waiting_for_stop_reply flag is never going 151726 to be set. As a result, we don't need to worry about the first 151727 difference. I have however, added a gdb_assert to validate the 151728 assumption that the flag is never going to be set. If in future the 151729 situation ever changes, then we should find out pretty quickly. 151730 151731 As for the second difference, I have resolved this by having all stop 151732 packets taken from the ::stop_reply_queue, pass through the return 151733 value adjustment code at the end of ::wait_as. 151734 151735 An example of a test that reveals the benefits of this commit is: 151736 151737 make check-gdb \ 151738 RUNTESTFLAGS="--target_board=native-extended-gdbserver \ 151739 GDBFLAGS='-ex maint\ set\ target-async\ off \ 151740 -ex maint\ set\ target-non-stop\ off' \ 151741 gdb.base/attach.exp" 151742 151743 For testing I've been running test on x86-64/GNU Linux, and run with 151744 target boards unix, native-gdbserver, and native-extended-gdbserver. 151745 For each board I've run with the default GDBFLAGS, as well as with: 151746 151747 GDBFLAGS='-ex maint\ set\ target-async\ off \ 151748 -ex maint\ set\ target-non-stop\ off' \ 151749 151750 Though running with the above GDBFLAGS is clearly a lot more unstable 151751 both before and after my patch, I'm not seeing any consistent new 151752 failures with my patch, except, with the native-extended-gdbserver 151753 board, where I am seeing new failures, but only because more tests are 151754 now running. For that configuration alone I see the number of 151755 unresolved go down by 49, the number of passes goes up by 446, and the 151756 number of failures also increases by 144. All of the failures are new 151757 tests as far as I can tell. 151758 1517592021-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 151760 151761 x86: Terminate mnemonicendp in swap_operand() 151762 Tested on x86_64-pc-linux-gnu. 151763 151764 opcodes/ChangeLog: 151765 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 151766 151767 * i386-dis.c (swap_operand): Terminate mnemonicendp. 151768 151769 gas/ChangeLog: 151770 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> 151771 151772 * testsuite/gas/i386/opts-intel.d: Updated expected disassembly. 151773 * testsuite/gas/i386/opts.d: Likewise. 151774 * testsuite/gas/i386/sse2avx-opts-intel.d: Likewise. 151775 * testsuite/gas/i386/sse2avx-opts.d: Likewise. 151776 * testsuite/gas/i386/x86-64-opts-intel.d: Likewise. 151777 * testsuite/gas/i386/x86-64-opts.d: Likewise. 151778 * testsuite/gas/i386/x86-64-sse2avx-opts-intel.d: Likewise. 151779 * testsuite/gas/i386/x86-64-sse2avx-opts.d: Likewise. 151780 1517812021-12-18 GDB Administrator <gdbadmin@sourceware.org> 151782 151783 Automatic date update in version.in 151784 1517852021-12-17 Tom Tromey <tom@tromey.com> 151786 151787 Document gdbarch-components.py 151788 This adds a comment to document how to update gdbarch. 151789 151790 Remove gdbarch.sh 151791 This patch runs gdbarch.py and removes gdbarch.sh. 151792 1517932021-12-17 Simon Marchi <simon.marchi@efficios.com> 151794 151795 Add new gdbarch generator 151796 The new gdbarch generator is a Python program. It reads the 151797 "components.py" that was created in the previous patch, and generates 151798 gdbarch.c and gdbarch-gen.h. 151799 151800 This is a relatively straightforward translation of the existing .sh 151801 code. It doesn't try very hard to be idiomatic Python or to be 151802 especially smart. 151803 151804 It is, however, incredibly faster: 151805 151806 $ time ./gdbarch.sh 151807 151808 real 0m8.197s 151809 user 0m5.779s 151810 sys 0m3.384s 151811 151812 $ time ./gdbarch.py 151813 151814 real 0m0.065s 151815 user 0m0.053s 151816 sys 0m0.011s 151817 151818 Co-Authored-By: Tom Tromey <tom@tromey.com> 151819 1518202021-12-17 Tom Tromey <tom@tromey.com> 151821 151822 Generate new gdbarch-components.py from gdbarch.sh 151823 The new gdbarch.sh approach will be to edit a Python file, rather than 151824 adding a line to a certain part of gdbarch.sh. We use the existing sh 151825 code, though, to generate the first draft of this .py file. 151826 151827 Documentation on the format will come in a subsequent patch. 151828 151829 Note that some info (like "staticdefault") in the current code is 151830 actually unused, and so is ignored by this new generator. 151831 1518322021-12-17 Tom Tromey <tom@tromey.com> 151833 151834 Do not sort the fields in gdbarch_dump 151835 This changes gdbarch.sh so that it no longer sorts the fields in 151836 gdbarch_dump. This sorting isn't done anywhere else by gdbarch.sh, 151837 and this simplifies the new generator a little bit. 151838 151839 Do not generate gdbarch.h 151840 Now that gdbarch.h has been split, we no longer need the generator 151841 code in gdbarch.sh, so remove it. 151842 1518432021-12-17 Tom Tromey <tom@tromey.com> 151844 151845 Split gdbarch.h into two files 151846 This patch splits gdbarch.h into two files -- gdbarch.h now is 151847 editable and hand-maintained, and the new gdbarch-gen.h file is the 151848 only thing generated by gdbarch.sh. This lets us avoid maintaining 151849 boilerplate in the gdbarch.sh file. 151850 151851 Note that gdbarch.sh still generates gdbarch.h after this patch. This 151852 makes it easier to re-run when rebasing. This code is removed in a 151853 subsequent patch. 151854 1518552021-12-17 Tom Tromey <tom@tromey.com> 151856 151857 Move ordinary gdbarch code to arch-utils 151858 While I think it makes sense to generate gdbarch.c, at the same time I 151859 think it is better for ordinary code to be editable in a C file -- not 151860 as a hunk of C code embedded in the generator. 151861 151862 This patch moves this sort of code out of gdbarch.sh and gdbarch.c and 151863 into arch-utils.c, then has arch-utils.c include gdbarch.c. 151864 1518652021-12-17 Maciej W. Rozycki <macro@embecosm.com> 151866 151867 Avoid redundant operations in `fortran_array_walker' 151868 Move inner dimension's element type determination outside the respective 151869 loops in `fortran_array_walker'. The operation is exactly the same with 151870 each iteration, so there is no point in redoing it for each element and 151871 while a smart compiler might be able to move it outside the loop it is 151872 regardless a bad coding style. No functional change. 151873 151874 Initialize `m_ndimensions' in the member initializer list 151875 Following our coding convention initialize the `m_ndimensions' member in 151876 the member initializer list rather than in the body of the constructor 151877 of the `fortran_array_walker' class. No functional change. 151878 1518792021-12-17 Lancelot SIX <lancelot.six@amd.com> 151880 Pedro Alves <pedro@palves.net> 151881 151882 gdb/tui: install SIGWINCH only when connected to a TTY 151883 PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it 151884 crashes when it receives a SIGWINCH signal. 151885 151886 This can be reproduced as follows: 151887 151888 $ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat 151889 151890 # from another terminal: 151891 $ kill -WINCH %(pidof gdb) 151892 151893 When doing so, the process crashes in a call to rl_resize_terminal: 151894 151895 void 151896 rl_resize_terminal (void) 151897 { 151898 _rl_get_screen_size (fileno (rl_instream), 1); 151899 ... 151900 } 151901 151902 The problem is that at this point rl_instream has the value NULL. 151903 151904 The rl_instream variable is supposed to be initialized during a call to 151905 readline_initialize_everything, which in a normal startup sequence is 151906 called under this call chain: 151907 151908 tui_interp::init 151909 tui_ensure_readline_initialized 151910 rl_initialize 151911 readline_initialize_everything 151912 151913 In tui_interp::init, we have the following sequence: 151914 151915 tui_initialize_io (); 151916 tui_initialize_win (); // <- Installs SIGWINCH 151917 if (gdb_stdout->isatty ()) 151918 tui_ensure_readline_initialized (); // <- Initializes rl_instream 151919 151920 This function unconditionally installs the SIGWINCH signal handler (this 151921 is done by tui_initialize_win), and then if gdb_stdout is a TTY it 151922 initializes readline. Therefore, if stdout is not a TTY, SIGWINCH is 151923 installed but readline is not initialized. In such situation 151924 rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its 151925 handler and in fine tries to access rl_instream leading to the crash. 151926 151927 This patch proposes to fix this issue by installing the SIGWINCH signal 151928 handler only if GDB is connected to a TTY. Given that this 151929 initialization it the only task of tui_initialize_win, this patch moves 151930 tui_initialize_win just after the call to 151931 tui_ensure_readline_initialized. 151932 151933 Tested on x86_64-linux. 151934 151935 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056 151936 Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9 151937 1519382021-12-17 Alan Modra <amodra@gmail.com> 151939 151940 asan: NULL dereference in bfd_elf_set_group_contents 151941 * elf-bfd.h (struct output_elf_obj_tdata): Make num_section_syms 151942 unsigned. 151943 * elf.c (bfd_elf_set_group_contents): Bounds check sec->index 151944 and check that entry in elf_section_syms for sec is non-NULL. 151945 (_bfd_elf_symbol_from_bfd_symbol): Adjust. 151946 1519472021-12-17 Alan Modra <amodra@gmail.com> 151948 151949 asan: use after free in _bfd_elf_mips_get_relocated_section_contents 151950 Leaving entries on mips_hi16_list from a previous pass over relocs 151951 leads to confusing bugs. 151952 151953 * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents): 151954 Free mips_hi16_list entries on error exit. 151955 1519562021-12-17 Alan Modra <amodra@gmail.com> 151957 151958 asan: abort in wasm_scan_name_function_section 151959 Macros like READ_LEB128 in wasm-module.c that alter control flow are 151960 evil. Maintainers will break your code if you have hidden ways to 151961 reach labels. 151962 151963 * wasm-module.c (wasm_scan_name_function_section): Don't 151964 attempt to bfd_release NULL. 151965 1519662021-12-17 Alan Modra <amodra@gmail.com> 151967 151968 asan: heap-buffer-overflow in bpf_elf_generic_reloc 151969 The bpf reloc howtos are a bit weird, using bitpos to specify an 151970 offset from r_offset that is outside the size of the reloc as given by 151971 howto.size. That means bfd_get_reloc_size gives the wrong answer for 151972 range checking, and thus bfd_reloc_offset_in_range can't be used. 151973 151974 * elf64-bpf.c (bpf_elf_generic_reloc): Handle bitpos offset reloc 151975 range checking. 151976 1519772021-12-17 Alan Modra <amodra@gmail.com> 151978 151979 ubsan: bfd.c:2519:8: shift exponent 34 is too large 151980 * bfd.c (bfd_update_compression_header): Avoid integer overflow. 151981 151982 asan: buffer overflow in mmo_get_symbols 151983 * mmo.c (mmo_get_symbols): Error on symbol name exceeding max length. 151984 1519852021-12-17 Alan Modra <amodra@gmail.com> 151986 151987 asan: buffer overflow in elfnn-aarch64.c get_plt_type 151988 We can't assume .dynamic is a multiple of ElfNN_External_Dyn, at least 151989 not when presented with fuzzed object files. 151990 151991 * elfnn-aarch64.c (get_plt_type): Don't access past end of 151992 improperly sized .dynamic. 151993 1519942021-12-17 Alan Modra <amodra@gmail.com> 151995 151996 try_build_id_prefix gcc-10 -Wformat-security errors 151997 dwarf.c:11300:3: error: format not a string literal and no format arguments [-Werror=format-security] 151998 11300 | f += sprintf (f, prefix); 151999 152000 PR 28697 152001 * dwarf.c (try_build_id_prefix): Avoid -Wformat-security error. 152002 1520032021-12-17 GDB Administrator <gdbadmin@sourceware.org> 152004 152005 Automatic date update in version.in 152006 1520072021-12-16 Nick Clifton <nickc@redhat.com> 152008 152009 Fix AVR assembler so that it creates relocs that will work with linker relaxation. 152010 PR 28686 152011 gas * config/tc-avr.h (tc_fix_adjustable): Define. 152012 * config/tc-avr.c (avr_fix_adjustable): New function. 152013 * testsuite/gas/all/gas.exp: Skip tests that need adjustable fixups. 152014 * testsuite/gas/elf/elf.exp: Likewise. 152015 * testsuite/gas/avr/diffreloc_withrelax.d: Adjust expected output. 152016 * testsuite/gas/avr/pc-relative-reloc.d: Adjust expected output. 152017 152018 ld * testsuite/ld-avr/avr-prop-7.d: Adjust expected output. 152019 * testsuite/ld-avr/avr-prop-8.d: Likewise. 152020 * testsuite/ld-avr/pr13402.d: Likewise. 152021 1520222021-12-16 Nick Clifton <nickc@redhat.com> 152023 152024 When loading separate debug info files, also attempt to locate a file based upon the build-id. 152025 PR 28697 152026 * dwarf.c (load_build_id_debug_file): New function. 152027 (try_build_id_prefix): New function. 152028 (check_for_and_load_links): Call load_build_id_debug_file. 152029 (debug_displays): Add entry for .note.gnu.build-id. 152030 * dwarf.h (enum dwarf_section_display_enum): Add 152031 note_gnu_build_id. 152032 * testsuite/binutils-all/debuginfod.exp (test_fetch_debuglink): 152033 Fix regexp for loads via debuglink section. 152034 1520352021-12-16 Richard Sandiford <richard.sandiford@arm.com> 152036 152037 arm: Add support for Armv9.1-A to Armv9.3-A 152038 This patch adds AArch32 support for -march=armv9.[123]-a. 152039 The behaviour of the new options can be expressed using a 152040 combination of existing feature flags and tables. 152041 152042 The cpu_arch_ver entries for ARM_ARCH_V9_2A and ARM_ARCH_V9_3A 152043 are technically redundant but it seemed less surprising to include 152044 them anyway. 152045 152046 include/ 152047 * opcode/arm.h (ARM_ARCH_V9_1A, ARM_ARCH_V9_2A): New macros. 152048 (ARM_ARCH_V9_3A): Likewise. 152049 152050 gas/ 152051 * doc/c-arm.texi: Add armv9.1-a, armv9.2-a and armv9.3-a. 152052 * config/tc-arm.c (armv91a_ext_table, armv92a_ext_table): New macros. 152053 (armv93a_ext_table): Likewise. 152054 (arm_archs): Add armv9.1-a, armv9.2-a and armv9.3-a. 152055 (cpu_arch_ver): Add ARM_ARCH_V9_1A, ARM_ARCH_V9_2A and ARM_ARCH_V9_3A. 152056 * NEWS: Mention the above. 152057 * testsuite/gas/arm/attr-march-armv9_1-a.d: New test. 152058 * testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise. 152059 * testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise. 152060 * testsuite/gas/arm/bfloat16-armv9.1-a.d: Likewise. 152061 * testsuite/gas/arm/bfloat16-armv9.2-a.d: Likewise. 152062 * testsuite/gas/arm/bfloat16-armv9.3-a.d: Likewise. 152063 * testsuite/gas/arm/i8mm-armv9.1-a.d: Likewise. 152064 * testsuite/gas/arm/i8mm-armv9.2-a.d: Likewise. 152065 * testsuite/gas/arm/i8mm-armv9.3-a.d: Likewise. 152066 1520672021-12-16 Richard Sandiford <richard.sandiford@arm.com> 152068 152069 arm: Add support for Armv8.7-A and Armv8.8-A 152070 This patch adds AArch32 support for -march=armv8.[78]-a. 152071 The behaviour of the new options can be expressed using a 152072 combination of existing feature flags and tables. 152073 152074 The cpu_arch_ver entries are technically redundant but 152075 it seemed less surprising to include them anyway. 152076 152077 include/ 152078 * opcode/arm.h (ARM_ARCH_V8_7A, ARM_ARCH_V8_8A): New macros. 152079 152080 gas/ 152081 * doc/c-arm.texi: Add armv8.7-a and armv8.8-a. 152082 * config/tc-arm.c (armv87a_ext_table, armv88a_ext_table): New macros. 152083 (arm_archs): Add armv8.7-a and armv8.8-a. 152084 (cpu_arch_ver): Add ARM_ARCH_V8_7A and ARM_ARCH_V8_8A. 152085 * NEWS: Mention the above. 152086 * testsuite/gas/arm/attr-march-armv8_7-a.d: New test. 152087 * testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise. 152088 * testsuite/gas/arm/bfloat16-armv8.7-a.d: Likewise. 152089 * testsuite/gas/arm/bfloat16-armv8.8-a.d: Likewise. 152090 * testsuite/gas/arm/i8mm-armv8.7-a.d: Likewise. 152091 * testsuite/gas/arm/i8mm-armv8.8-a.d: Likewise. 152092 1520932021-12-16 Richard Sandiford <richard.sandiford@arm.com> 152094 152095 aarch64: Add support for Armv9.1-A to Armv9.3-A 152096 This patch adds AArch64 support for -march=armv9.[123]-a. 152097 The behaviour of the new options can be expressed using a 152098 combination of existing feature flags, so we don't need to 152099 eat into the vanishing number of spare AARCH64_FEATURE_* bits. 152100 Hoewver, it was more convenient to separate out the |s of 152101 feature flags so that Armv9.1-A could reuse the set for 152102 Armv8.6-A, and so on. 152103 152104 include/ 152105 * opcode/aarch64.h (AARCH64_ARCH_V8_FEATURES): New macro, 152106 split out from... 152107 (AARCH64_ARCH_V8): ...here. 152108 (AARCH64_ARCH_V8_1_FEATURES): New macro, split out from... 152109 (AARCH64_ARCH_V8_1): ...here. 152110 (AARCH64_ARCH_V8_2_FEATURES): New macro, split out from... 152111 (AARCH64_ARCH_V8_2): ...here. 152112 (AARCH64_ARCH_V8_3_FEATURES): New macro, split out from... 152113 (AARCH64_ARCH_V8_3): ...here. 152114 (AARCH64_ARCH_V8_4_FEATURES): New macro, split out from... 152115 (AARCH64_ARCH_V8_4): ...here. 152116 (AARCH64_ARCH_V8_5_FEATURES): New macro, split out from... 152117 (AARCH64_ARCH_V8_5): ...here. 152118 (AARCH64_ARCH_V8_6_FEATURES): New macro, split out from... 152119 (AARCH64_ARCH_V8_6): ...here. 152120 (AARCH64_ARCH_V8_7_FEATURES): New macro, split out from... 152121 (AARCH64_ARCH_V8_7): ...here. 152122 (AARCH64_ARCH_V8_8_FEATURES): New macro, split out from... 152123 (AARCH64_ARCH_V8_8): ...here. 152124 (AARCH64_ARCH_V9_FEATURES): New macro, split out from... 152125 (AARCH64_ARCH_V9): ...here. 152126 (AARCH64_ARCH_V9_1_FEATURES, AARCH64_ARCH_V9_1): New macros. 152127 (AARCH64_ARCH_V9_2_FEATURES, AARCH64_ARCH_V9_2): New macros. 152128 (AARCH64_ARCH_V9_3_FEATURES, AARCH64_ARCH_V9_3): New macros. 152129 152130 gas/ 152131 * doc/c-aarch64.texi: Add armv9.1-a, armv9-2-a and armv9.3-a. 152132 * config/tc-aarch64.c (aarch64_archs): Likewise. 152133 * NEWS: Mention the above. 152134 * testsuite/gas/aarch64/armv9_invalid.d, 152135 testsuite/gas/aarch64/armv9_invalid.s, 152136 testsuite/gas/aarch64/armv9_invalid.l: New test. 152137 * testsuite/gas/aarch64/armv9_1.d, 152138 testsuite/gas/aarch64/armv9_1.s: Likewise. 152139 * testsuite/gas/aarch64/armv9_1_invalid.d, 152140 testsuite/gas/aarch64/armv9_1_invalid.s, 152141 testsuite/gas/aarch64/armv9_1_invalid.l: Likewise. 152142 * testsuite/gas/aarch64/armv9_2.d, 152143 testsuite/gas/aarch64/armv9_2.s: Likewise. 152144 * testsuite/gas/aarch64/armv9_2_invalid.d, 152145 testsuite/gas/aarch64/armv9_2_invalid.s, 152146 testsuite/gas/aarch64/armv9_2_invalid.l: Likewise. 152147 * testsuite/gas/aarch64/armv9_3.d, 152148 testsuite/gas/aarch64/armv9_3.s: Likewise. 152149 1521502021-12-16 Nelson Chu <nelson.chu@sifive.com> 152151 152152 RISC-V: Support svinval extension with frozen version 1.0. 152153 According to the privileged spec, there are five new instructions for 152154 svinval extension. Two of them (HINVAL.VVMA and HINVAL.GVMA) need to 152155 enable the hypervisor extension. But there is no implementation of 152156 hypervisor extension in mainline for now, so let's consider the related 152157 issues later. 152158 152159 31..25 24..20 19..15 14..12 11...7 6..2 1..0 152160 sinval.vma 0001011 rs2 rs1 000 00000 11100 11 152161 sfence.w.inval 0001100 00000 00000 000 00000 11100 11 152162 sfence.inval.ir 0001100 00001 00000 000 00000 11100 11 152163 hinval.vvma 0010011 rs2 rs1 000 00000 11100 11 152164 hinval.gvma 0110011 rs2 rs1 000 00000 11100 11 152165 152166 This patch is cherry-picked from the riscv integration branch since the 152167 svinval extension is frozen for now. Besides, we fix the funct7 encodings 152168 of hinval.vvma and hinval.gvma, from 0x0011011 and 0x0111011 to 0x0010011 152169 and 0x0110011. 152170 152171 bfd/ 152172 * elfxx-riscv.c (riscv_supported_std_s_ext): Added svinval. 152173 (riscv_multi_subset_supports): Handle INSN_CLASS_SVINVAL. 152174 gas/ 152175 * testsuite/gas/riscv/svinval.d: New testcase. 152176 * testsuite/gas/riscv/svinval.s: Likewise. 152177 include/ 152178 * opcode/riscv-opc.h: Added encodings for svinval. 152179 * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_SVINVAL. 152180 opcodes/ 152181 * riscv-opc.c (riscv_opcodes): Added svinval instructions. 152182 1521832021-12-16 Mike Frysinger <vapier@gentoo.org> 152184 152185 sim: mips/or1k: drop redundant arg to bitsize macro 152186 These are just using the default behavior for the 3rd arg, so drop 152187 it to make it more clear. This also makes them match all other 152188 ports that only use the first 2 arguments. 152189 1521902021-12-16 Mike Frysinger <vapier@gentoo.org> 152191 152192 bfd: unify texi generation rules 152193 The logic between these rules are extremely similar, so unify them 152194 into a single variable by leveraging make $@ and $< variables. 152195 152196 Also add automake silent rule support while we're here. 152197 1521982021-12-16 Mike Frysinger <vapier@gentoo.org> 152199 152200 sim: fix mingw builds with replacement gnulib open 152201 The header shuffling in here broke the workaround for gnulib defining 152202 "open". Move it back before the sim-specific includes to fix. This 152203 is because the callback struct in the headers has an "open" member and 152204 this file tries to call that. 152205 1522062021-12-16 Sandra Loosemore <sandra@codesourcery.com> 152207 152208 Adjust compare_link_order for unstable qsort 152209 In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host 152210 using binutils 2.37, we observed a failure that didn't show up on 152211 x86_64-linux-gnu host: testcase pr25490-5.s was failing with 152212 152213 C:\path\to\nios2-elf-ld.exe: looping in map_segments 152214 FAIL: __patchable_function_entries section 5 152215 152216 * ldelfgen.c (compare_link_order): Don't use section id in 152217 sorting. Keep original ordering instead. Update comments. 152218 1522192021-12-16 Alan Modra <amodra@gmail.com> 152220 152221 Re: Fix an undefined behaviour in the BFD library's DWARF parser 152222 Using an unsigned int cast (to 32 bits) on a pointer difference (of 152223 possibly 64 bits) is wrong. Even though it will work on all real 152224 object files, the fuzzers will eventually find this hole. 152225 152226 PR 28687 152227 * dwarf1.c (parse_die): Cast pointer difference to size_t. 152228 Catch another possible pointer overflow. 152229 1522302021-12-16 Simon Marchi <simon.marchi@polymtl.ca> 152231 152232 gdb: re-format with black 21.12b0 152233 Run black 21.12b0 on gdb/, there is a single whitespace change. I will 152234 update the wiki [1] in parallel to bump the version of black to 21.12b0. 152235 152236 [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards 152237 152238 Change-Id: Ib3b859e3506c74a4f15d16f1e44ef402de3b98e2 152239 1522402021-12-16 Simon Marchi <simon.marchi@polymtl.ca> 152241 152242 gdb: re-format with black 21.9b0 152243 Run black 21.9b0 on gdb/ (this is the version currently mentioned on the 152244 wiki [1], the subsequent commit will bump that version). 152245 152246 [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards 152247 152248 Change-Id: I5ceaab42c42428e053e2572df172aa42a88f0f86 152249 1522502021-12-16 GDB Administrator <gdbadmin@sourceware.org> 152251 152252 Automatic date update in version.in 152253 1522542021-12-15 Alan Modra <amodra@gmail.com> 152255 152256 PR28691, validate dwarf attribute form 152257 PR28691 is a fuzzing PR that triggers a non-problem of "output changes 152258 per run" with PIEs and/or different compilers. I've closed similar 152259 PRs before as wontfix, but I guess there will be no end of this type 152260 of PR. The trigger is an attribute that usually takes one of the 152261 offset/constant reference DW_FORMs being given an indexed string 152262 DW_FORM. The bfd reader doesn't support indexed strings and returns 152263 an error string instead. The address of the string varies with PIE 152264 runs and/or compiler, and we allow that address to appear in output. 152265 Fix this by validating integer attribute forms, as we do for string 152266 form attributes. 152267 152268 PR 28691 152269 * dwarf2.c (is_str_attr): Rename to.. 152270 (is_str_form): ..this. Change param type. Update calls. 152271 (is_int_form): New function. 152272 (read_attribute_value): Handle DW_FORM_addrx2. 152273 (find_abstract_instance): Validate form when using attr.u.val. 152274 (scan_unit_for_symbols, parse_comp_unit): Likewise. 152275 1522762021-12-15 Luis Machado <luis.machado@linaro.org> 152277 152278 New --enable-threading configure option to control use of threads in GDB/GDBserver 152279 Add the --enable-threading configure option so multithreading can be disabled 152280 at configure time. This is useful for statically-linked builds of 152281 GDB/GDBserver, since the thread library doesn't play well with that setup. 152282 152283 If you try to run a statically-linked GDB built with threading, it will crash 152284 when setting up the number of worker threads. 152285 152286 This new option is also convenient when debugging GDB in a system with lots of 152287 threads, where the thread discovery code in GDB will emit too many messages, 152288 like so: 152289 152290 [New Thread 0xfffff74d3a50 (LWP 2625599)] 152291 152292 If you have X threads, that message will be repeated X times. 152293 152294 The default for --enable-threading is "yes". 152295 1522962021-12-15 Nikita Popov <npv1310@gmail.com> 152297 152298 Fix an undefined behaviour in the BFD library's DWARF parser. 152299 PR 28687 152300 * dwarf1.c (parse_die): Fix undefined behaviour in range tests. 152301 1523022021-12-15 Alan Modra <amodra@gmail.com> 152303 152304 PR28694, Out-of-bounds write in stab_xcoff_builtin_type 152305 PR 28694 152306 * stabs.c (stab_xcoff_builtin_type): Make typenum unsigned. 152307 Negate typenum earlier, simplifying bounds checking. Correct 152308 off-by-one indexing. Adjust switch cases. 152309 1523102021-12-15 GDB Administrator <gdbadmin@sourceware.org> 152311 152312 Automatic date update in version.in 152313 1523142021-12-14 Alan Modra <amodra@gmail.com> 152315 152316 loongarch32 build failure on 32-bit host 152317 gas/config/tc-loongarch.c: In function ‘assember_macro_helper’: 152318 gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow] 152319 915 | hi32 = insn->args[1] >> 32; 152320 | ^~ 152321 152322 One possible fix is to make offsetT a 64-bit type for loongarch32. 152323 This also makes bfd/targmatch.h (generated from bfd/config.bfd) 152324 consistent since the loongarch32 match is inside #ifdef BFD64. 152325 152326 * config.bfd (loongarch32-*): Set want64. 152327 1523282021-12-14 Alan Modra <amodra@gmail.com> 152329 152330 loongarch64 build failure on 32-bit host 152331 gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’: 152332 gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer 152333 -to-int-cast] 152334 661 | imm = (offsetT) str_hash_find (r_htab, arg); 152335 | ^ 152336 152337 Cast it to the correct size int, relying on normal integer promotions 152338 if offsetT is larger than a pointer. 152339 152340 * config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper): 152341 Cast return from str_hash_find to intptr_t, not offsetT. 152342 1523432021-12-14 Alan Modra <amodra@gmail.com> 152344 152345 XCOFF C_STSYM test failure on 32-bit host 152346 This test was failing here and on another similar symbol: 152347 [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs 152348 where correct output is 152349 [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x000000000000000a .bs 152350 152351 The problem is caused by a 32-bit host pointer being sign-extended 152352 when stored into a 64-bit bfd_vma, and then that value not being 152353 trimmed back to 32 bits when used. The following belt-and-braces 152354 patch fixes both the store and subsequent reads. 152355 152356 * coffcode.h (coff_slurp_symbol_table): Do not sign extend 152357 when storing a host pointer to syment.n_value. 152358 * coffgen.c (coff_get_symbol_info): Cast syment.n_value to a 152359 bfd_hostptr_t before using in arithmetic. 152360 (coff_print_symbol): Likewise. 152361 1523622021-12-14 Simon Marchi <simon.marchi@efficios.com> 152363 152364 gdbserver/tracepoint.cc: use snprintf in gdb_agent_socket_init 152365 If we modify tracepoint.cc to try to use a too long unix socket name, 152366 for example by modifying SOCK_DIR to be: 152367 152368 #define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut" 152369 152370 ... trying to start an application with libinproctrace.so loaded 152371 crashes: 152372 152373 $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls 152374 /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected. 152375 xsnprintf: Assertion `ret < size' failed. 152376 152377 Looking at the rest of the socket initialization code, the intent seems 152378 to be that if something goes wrong, we warn but let the program 152379 execute. So crashing on this failed assertions seems against the intent. 152380 152381 Commit 6cebaf6e1ae4 ("use xsnprintf instead of snprintf.") changed this 152382 code to use xsnprintf instead of snprintf, introducing this assertion. 152383 Before that, snprintf would return a value bigger that UNIX_PATH_MAX and 152384 the "if" after would catch it and emit a warning, which is exactly what 152385 we want. That change was done because LynxOS didn't have snprintf. 152386 Since LynxOS isn't supported anymore, we can simply revert to use 152387 snprintf there. 152388 152389 With this patch, we get a warning (printed by the caller of 152390 gdb_agent_socket_init), but the program keeps executing: 152391 152392 $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls 152393 ipa: could not create sync socket 152394 ... 152395 152396 Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd 152397 1523982021-12-14 Simon Marchi <simon.marchi@efficios.com> 152399 152400 gdbserver/tracepoint.cc: work around -Wstringop-truncation error 152401 When building gdb with on AArch64 with g++ 11.1.0 (and some preceding 152402 versions too), -O2 and -fsanitize=address, I get this error. 152403 152404 CXX tracepoint-ipa.o 152405 cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ 152406 In file included from /usr/include/string.h:519, 152407 from ../gnulib/import/string.h:41, 152408 from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95, 152409 from /home/simark/src/binutils-gdb/gdbserver/server.h:22, 152410 from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19: 152411 In function ‘char* strncpy(char*, const char*, size_t)’, 152412 inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11, 152413 inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26, 152414 inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41: 152415 /usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation] 152416 95 | return __builtin___strncpy_chk (__dest, __src, __len, 152417 | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ 152418 96 | __glibc_objsize (__dest)); 152419 | ~~~~~~~~~~~~~~~~~~~~~~~~~ 152420 152421 Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar 152422 error if I use -D_FORTIFY_SOURCE=0. 152423 152424 I am pretty sure it's spurious and might be related to this GCC bug: 152425 152426 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 152427 152428 From what I can see, we are copying from a static 108 bytes long buffer 152429 (the global array agent_socket_name) to a 108 bytes long array, 152430 sockaddr_un::sun_path. I don't see anything wrong. 152431 152432 Still, it would make things easier if we didn't see this error. Change 152433 the code to check that the source string length is smaller than the 152434 destination buffer (including space for the NULL byte) and use strcpy. 152435 152436 For anybody who would like to try to reproduce, the full command line 152437 is: 152438 152439 g++ -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc 152440 152441 Change-Id: I18e86c0487feead7e7677e69398405e7057cf464 152442 1524432021-12-14 Simon Marchi <simon.marchi@polymtl.ca> 152444 152445 bfd: fix -Wunused errors with clang 13+ 152446 Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for 152447 situations where gcc doesn't. In particular, when a variable is set and 152448 then used in a way to update its own value. For example, if `i` is only 152449 used in this way: 152450 152451 int i = 2; 152452 i++; 152453 i = i + 1; 152454 152455 gcc won't warn, but clang will. 152456 152457 Fix all such errors found in an --enable-targets=all build. It would be 152458 important for somebody who knows what they're doing to just make sure 152459 that these variables can indeed be deleted, and that there a no cases 152460 where it's a bug, and the variable should actually be used. 152461 152462 The first instance of this error fix by this patch is: 152463 152464 CC elf32-score.lo 152465 /home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable] 152466 bfd_vma relocation; 152467 ^ 152468 152469 Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6 152470 1524712021-12-14 Andrew Burgess <aburgess@redhat.com> 152472 152473 gdb/mi: rename build_table to add_builtin_mi_commands 152474 Just give the function build_table a more descriptive name. There 152475 should be no user visible changes after this commit. 152476 1524772021-12-14 Jan Vrany <jan.vrany@labware.com> 152478 152479 gdb/mi: rename mi_cmd to mi_command 152480 Just give this class a new name, more inline with the name of the 152481 sub-classes. I've also updated mi_cmd_up to mi_command_up in 152482 mi-cmds.c inline with this new naming scheme. 152483 152484 There should be no user visible changes after this commit. 152485 1524862021-12-14 Jan Vrany <jan.vrany@labware.com> 152487 152488 gdb/mi: use separate classes for different types of MI command 152489 This commit changes the infrastructure in mi-cmds.{c,h} to add new 152490 sub-classes for the different types of MI command. Instances of these 152491 sub-classes are then created and added into mi_cmd_table. 152492 152493 The existing mi_cmd class becomes the abstract base class, this has an 152494 invoke method and takes care of the suppress notifications handling, 152495 before calling a do_invoke virtual method which is implemented by all 152496 of the sub-classes. 152497 152498 There's currently two different sub-classes, one of pure MI commands, 152499 and a second for MI commands that delegate to CLI commands. 152500 152501 There should be no user visible changes after this commit. 152502 1525032021-12-14 Andrew Burgess <aburgess@redhat.com> 152504 152505 gdb/mi: int to bool conversion in mi_execute_cli_command 152506 Change an argument of mi_execute_cli_command from int to bool. Update 152507 the callers to take this into account. Within mi_execute_cli_command, 152508 update a comparison of a pointer to 0 with a comparison to nullptr, 152509 and add an assert, if we are not using the argument string then the 152510 string should be nullptr. Also removed a cryptic 'gdb_????' comment, 152511 which isn't really helpful. 152512 152513 There should be no user visible changes after this commit. 152514 1525152021-12-14 Jan Vrany <jan.vrany@labware.com> 152516 152517 gdb/mi: use std::map for MI commands in mi-cmds.c 152518 This changes the hashmap used in mi-cmds.c from a custom structure to 152519 std::map. Not only is replacing a custom container with a standard 152520 one an improvement, but using std::map will make it easier to 152521 dynamically add commands; which is something that is planned for a 152522 later series, where we will allow MI commands to be implemented in 152523 Python. 152524 152525 There should be no user visible changes after this commit. 152526 1525272021-12-14 Jan Vrany <jan.vrany@labware.com> 152528 152529 gdb/mi: rename mi_lookup to mi_cmd_lookup 152530 Lets give this function a more descriptive name. I've also improved 152531 the comments in the header and source files. 152532 152533 There should be no user visible changes after this commit. 152534 1525352021-12-14 Nelson Chu <nelson.chu@sifive.com> 152536 152537 RISC-V: Added ld testcases for the medlow and medany code models. 152538 There are two linker scripts, code-model-01.ld and code-model-02.ld, 152539 which are corresponding to the two different memory layouts, 152540 152541 * code-model-01.ld: the text section is in the 32-bit address range, but 152542 the data section is far away from the text section, which means the data 152543 section is over the 32-bit address range. 152544 152545 * code-model-02.ld: the text section is over the 32-bit address range, but 152546 the data section is placed nearly zero address. 152547 152548 We use the two linker scripts, to test the current medlow and medany behaviors 152549 of GNU ld, including the weak symbol references and the relaxations behaviors. 152550 Besides, these testcases also show the limits of the current medlow and medany 152551 code models, that is - we may get the truncated to fit errors when linking 152552 with the above two linker scripts. 152553 152554 ld/ 152555 * testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the 152556 behaviors of the current medlow and medany code models. 152557 * testsuite/ld-riscv-elf/code-model-02.ld: Likewise. 152558 * testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise. 152559 * testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise. 152560 * testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise. 152561 * testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise. 152562 * testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise. 152563 * testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise. 152564 * testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise. 152565 * testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise. 152566 * testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise. 152567 * testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise. 152568 * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise. 152569 * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise. 152570 * testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise. 152571 * testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise. 152572 * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise. 152573 * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise. 152574 * testsuite/ld-riscv-elf/code-model.s: Likewise. 152575 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 152576 1525772021-12-14 GDB Administrator <gdbadmin@sourceware.org> 152578 152579 Automatic date update in version.in 152580 1525812021-12-13 H.J. Lu <hjl.tools@gmail.com> 152582 152583 x86: Adjust linker tests for --disable-separate-code 152584 Adjust linker tests for linker configured with --disable-separate-code: 152585 152586 1. Update expected outputs. 152587 2. Pass -z max-page-size=0x1000 -z separate-code" to linker. 152588 152589 * testsuite/ld-i386/report-reloc-1.l: Updated. 152590 * testsuite/ld-x86-64/report-reloc-1.l: Likewise. 152591 * testsuite/ld-x86-64/pe-x86-64.exp: Pass 152592 "-z max-page-size=0x1000 -z separate-code" to linker. 152593 * testsuite/ld-x86-64/pr19609-4e.d: Likewise. 152594 * testsuite/ld-x86-64/pr19609-6a.d: Likewise. 152595 * testsuite/ld-x86-64/pr19609-6b.d: Likewise. 152596 * testsuite/ld-x86-64/pr19609-7b.d: Likewise. 152597 * testsuite/ld-x86-64/pr19609-7d.d: Likewise. 152598 1525992021-12-13 Carl Love <cel@us.ibm.com> 152600 152601 gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp 152602 Powerpc is not reporting the 152603 152604 Catchpoint 1 (returned from syscall execve), .... 152605 152606 as expected. The issue appears to be with the kernel not returning the 152607 expected result. This patch marks the test failure as an xfail. 152608 152609 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623 152610 1526112021-12-13 Andrew Burgess <andrew.burgess@embecosm.com> 152612 152613 gdb: improve reuse of value contents when fetching array elements 152614 While working on a Python script, which was interacting with a remote 152615 target, I noticed some weird slowness in GDB. In my program I had a 152616 structure something like this: 152617 152618 struct foo_t 152619 { 152620 int array[5]; 152621 }; 152622 152623 struct foo_t global_foo; 152624 152625 Then in the Python script I was fetching a complete copy of global 152626 foo, like: 152627 152628 val = gdb.parse_and_eval('global_foo') 152629 val.fetch_lazy() 152630 152631 Then I would work with items in foo_t.array, like: 152632 152633 print(val['array'][1]) 152634 152635 I called the fetch_lazy method specifically because I knew I was going 152636 to end up accessing almost all of the contents of val, and so I wanted 152637 GDB to do a single remote protocol call to fetch all the contents in 152638 one go, rather than trying to do lazy fetches for a couple of bytes at 152639 a time. 152640 152641 What I observed was that, after the fetch_lazy call, GDB does, 152642 correctly, fetch the entire contents of global_foo, including all of 152643 the contents of array, however, when I access val.array[1], GDB still 152644 goes and fetches the value of this element from the remote target. 152645 152646 What's going on is that in valarith.c, in value_subscript, for C like 152647 languages, we always end up treating the array value as a pointer, and 152648 then doing value_ptradd, and value_ind, the second of these calls 152649 always returns a lazy value. 152650 152651 My guess is that this approach allows us to handle indexing off the 152652 end of an array, when working with zero element arrays, or when 152653 indexing a raw pointer as an array. And, I agree, that in these 152654 cases, where, even when the original value is non-lazy, we still will 152655 not have the content of the array loaded, we should be using the 152656 value_ind approach. 152657 152658 However, for cases where we do have the array contents loaded, and we 152659 do know the bounds of the array, I think we should be using 152660 value_subscripted_rvalue, which is what we use for non C like 152661 languages. 152662 152663 One problem I did run into, exposed by gdb.base/charset.exp, was that 152664 value_subscripted_rvalue stripped typedefs from the element type of 152665 the array, which means the value returned will not have the same type 152666 as an element of the array, but would be the raw, non-typedefed, 152667 type. In charset.exp we got back an 'int' instead of a 152668 'wchar_t' (which is a typedef of 'int'), and this impacts how we print 152669 the value. Removing typedefs from the resulting value just seems 152670 wrong, so I got rid of that, and I don't see any test regressions. 152671 152672 With this change in place, my original Python script is now doing no 152673 additional memory accesses, and its performance increases about 10x! 152674 1526752021-12-13 Andrew Burgess <aburgess@redhat.com> 152676 152677 gdb: update gdb-gdb.py.in for latest changes to struct field 152678 This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and 152679 'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after 152680 this commit: 152681 152682 commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404 152683 Date: Thu Sep 30 22:38:29 2021 -0400 152684 152685 gdb: add accessors for field (and call site) location 152686 152687 I have also incorporated this change: 152688 152689 https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html 152690 152691 Which means we print 'm_name' instead of 'name' when displaying the 152692 'm_name' member variable. 152693 152694 Finally, I have also added support for the new TYPE_SPECIFIC_INT 152695 fields, which were added with this commit: 152696 152697 commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d 152698 Date: Wed Sep 23 09:39:24 2020 -0600 152699 152700 Handle bit offset and bit size in base types 152701 152702 I updated the gdb.gdb/python-helper.exp test to cover all of these 152703 changes. 152704 1527052021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 152706 152707 gdbserver/linux-low: replace direct assignment to current_thread 152708 Use scoped_restore_current_thread and switch_to_thread in 152709 linux_process_target::wait_for_sigstop. 152710 1527112021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 152712 152713 gdbserver: replace direct assignments to current_thread 152714 Replace the direct assignments to current_thread with 152715 switch_to_thread. Use scoped_restore_current_thread when appropriate. 152716 There is one instance remaining in linux-low.cc's wait_for_sigstop. 152717 This will be handled in a separate patch. 152718 152719 Regression-tested on X86-64 Linux using the native-gdbserver and 152720 native-extended-gdbserver board files. 152721 1527222021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 152723 152724 gdbserver: introduce scoped_restore_current_thread and switch_to_thread 152725 Introduce a class for restoring the current thread and a function to 152726 switch to the given thread. This is a preparation for a refactoring 152727 that aims to remove direct assignments to 'current_thread'. 152728 1527292021-12-13 Andrew Burgess <aburgess@redhat.com> 152730 152731 gdb: make post_startup_inferior a virtual method on inf_ptrace_target 152732 While working on a later patch that required me to understand how GDB 152733 starts up inferiors, I was confused by the 152734 target_ops::post_startup_inferior method. 152735 152736 The post_startup_inferior target function is only called from 152737 inf_ptrace_target::create_inferior. 152738 152739 Part of the target class hierarchy looks like this: 152740 152741 inf_child_target 152742 | 152743 '-- inf_ptrace_target 152744 | 152745 |-- linux_nat_target 152746 | 152747 |-- fbsd_nat_target 152748 | 152749 |-- nbsd_nat_target 152750 | 152751 |-- obsd_nat_target 152752 | 152753 '-- rs6000_nat_target 152754 152755 Every sub-class of inf_ptrace_target, except rs6000_nat_target, 152756 implements ::post_startup_inferior. The rs6000_nat_target picks up 152757 the implementation of ::post_startup_inferior not from 152758 inf_ptrace_target, but from inf_child_target. 152759 152760 No descendent of inf_child_target, outside the inf_ptrace_target 152761 sub-tree, implements ::post_startup_inferior, which isn't really 152762 surprising, as they would never see the method called (remember, the 152763 method is only called from inf_ptrace_target::create_inferior). 152764 152765 What I find confusing is the role inf_child_target plays in 152766 implementing, what is really a helper function for just one of its 152767 descendents. 152768 152769 In this commit I propose that we formally make ::post_startup_inferior 152770 a helper function of inf_ptrace_target. To do this I will remove the 152771 ::post_startup_inferior from the target_ops API, and instead make this 152772 a protected, pure virtual function on inf_ptrace_target. 152773 152774 I'll remove the empty implementation of ::post_startup_inferior from 152775 the inf_child_target class, and add a new empty implementation to the 152776 rs6000_nat_target class. 152777 152778 All the other descendents of inf_ptrace_target already provide an 152779 implementation of this method and so don't need to change beyond 152780 making the method protected within their class declarations. 152781 152782 To me, this makes much more sense now. The helper function, which is 152783 only called from within the inf_ptrace_target class, is now a part of 152784 the inf_ptrace_target class. 152785 152786 The only way in which this change is visible to a user is if the user 152787 turns on 'set debug target 1'. With this debug flag on, prior to this 152788 patch the user would see something like: 152789 152790 -> native->post_startup_inferior (...) 152791 <- native->post_startup_inferior (2588939) 152792 152793 After this patch these lines are no longer present, as the 152794 post_startup_inferior is no longer a top level target method. For me, 152795 this is an acceptable change. 152796 1527972021-12-13 Andrew Burgess <aburgess@redhat.com> 152798 152799 gdb: have mips_nbsd_nat_target inherit from nbsd_nat_target 152800 While working on another patch I had reason to look at 152801 mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target 152802 inherits directly from inf_ptrace_target. 152803 152804 This is a little strange as alpha_bsd_nat_target, 152805 arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target, 152806 ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all 152807 inherit from nbsd_nat_target. 152808 152809 Originally, in this commit: 152810 152811 commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e 152812 Date: Thu May 3 00:37:22 2018 +0100 152813 152814 Convert struct target_ops to C++ 152815 152816 When the target tree was converted to C++, all of the above classes 152817 inherited from inf_ptrace_target except for hppa_nbsd_nat_target, 152818 which was the only class that originally inherited from 152819 nbsd_nat_target. 152820 152821 Later on all the remaining targets (except mips) were converted to 152822 inherit from nbsd_nat_target, these are the commits: 152823 152824 commit 4fed520be264b60893aa674071947890f8172915 152825 Date: Sat Mar 14 16:05:24 2020 +0100 152826 152827 Inherit alpha_netbsd_nat_target from nbsd_nat_target 152828 152829 commit 6018d381a00515933016c539d2fdc18ad0d304b8 152830 Date: Sat Mar 14 14:50:51 2020 +0100 152831 152832 Inherit arm_netbsd_nat_target from nbsd_nat_target 152833 152834 commit 01a801176ea15ddfc988cade2e3d84c3b0abfec3 152835 Date: Sat Mar 14 16:54:42 2020 +0100 152836 152837 Inherit m68k_bsd_nat_target from nbsd_nat_target 152838 152839 commit 9faa006d11a5e08264a007463435f84b77864c9c 152840 Date: Thu Mar 19 14:52:57 2020 +0100 152841 152842 Inherit ppc_nbsd_nat_target from nbsd_nat_target 152843 152844 commit 9809762324491b851332ce600ae9bde8dd34f601 152845 Date: Tue Mar 17 15:07:39 2020 +0100 152846 152847 Inherit sh_nbsd_nat_target from nbsd_nat_target 152848 152849 commit d5be5fa4207da00d039a1d5a040ba316e7092cbd 152850 Date: Sat Mar 14 13:21:58 2020 +0100 152851 152852 Inherit vax_bsd_nat_target from nbsd_nat_target 152853 152854 I could only find mailing list threads for ppc and sh in the archive , 152855 and unfortunately, none of the commits has any real detail that might 152856 explain why mips was missed out, the only extra context I could find 152857 was this message: 152858 152859 https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html 152860 152861 Which says that "proper" OS support is going to be added to 152862 nbsd_nat_target, hence the need to inherit from that class. 152863 152864 My guess is that leaving mips_nbsd_nat_target unchanged was an 152865 oversight, so, in this commit, I propose changing mips_nbsd_nat_target 152866 to inherit from nbsd_nat_target just like all the other nbsd targets. 152867 152868 My motivation for this patch relates to the post_startup_inferior 152869 target method. In a future commit I want to change how this method is 152870 handled. Currently the mips_nbsd_nat_target will pick up the empty 152871 implementation of inf_child_target::post_startup_inferior rather than 152872 the version in netbsd-nat.c. This feels like a bug to me, as surely, 152873 enabling of proc events is something that would need to be done for 152874 all netbsd targets, regardless of architecture. 152875 152876 In my future patch I have a choice then, either (a) add a new, empty 152877 implementation of post_startup_inferior to mips_nbsd_nat_target, 152878 or (b) this commit, have mips_nbsd_nat_target inherit from 152879 nbsd_nat_target. Option (b) seems like the right way to go, hence, 152880 this commit. 152881 152882 I've done absolutely no testing for this change, not even building it, 152883 as that would require at least an environment in which I can x-build 152884 mips-netbsd applications, which I have no idea how to set up. 152885 1528862021-12-13 Andrew Burgess <aburgess@redhat.com> 152887 152888 gdb: only include mips and riscv targets if building with 64-bit bfd 152889 While testing another patch I was trying to build different 152890 configurations of GDB, and, during one test build I ran into a 152891 problem, I configured with `--enable-targets=all 152892 --host=i686-w64-mingw32` and saw this error while linking GDB: 152893 152894 .../i686-w64-mingw32/bin/ld: mips-tdep.o: in function `mips_gdbarch_init': 152895 .../src/gdb/mips-tdep.c:8730: undefined reference to `disassembler_options_mips' 152896 .../i686-w64-mingw32/bin/ld: riscv-tdep.o: in function `riscv_gdbarch_init': 152897 .../src/gdb/riscv-tdep.c:3851: undefined reference to `disassembler_options_riscv' 152898 152899 So the `disassembler_options_mips` and `disassembler_options_riscv` 152900 symbols are missing. 152901 152902 This turns out to be because mips-dis.c and riscv-dis.c, in which 152903 these symbols are defined, are in the TARGET64_LIBOPCODES_CFILES list 152904 in opcodes/Makefile.am, these files are only built when we are 152905 building with a 64-bit bfd. 152906 152907 If we look further, into bfd/Makefile.am, we can see that all the 152908 files matching elf*-riscv.lo are in the BFD64_BACKENDS list, as are 152909 the elf*-mips.lo files, and (I know because I tried), the two 152910 disassemblers do, not surprisingly, depend on features supplied from 152911 libbfd. 152912 152913 So, though we can build most of GDB just fine for riscv and mips with 152914 a 32-bit bfd, if I understand correctly, the final GDB 152915 executable (assuming we could get it to link) would not understand 152916 these architectures at the bfd level, nor would there be any 152917 disassembler available. This sounds like a pretty useless GDB to me. 152918 152919 So, in this commit, I move the riscv and mips targets into GDB's list 152920 of targets that require a 64-bit bfd. After this I can build GDB just 152921 fine with the configure options given above. 152922 152923 This was discussed on the mailing list in a couple of threads: 152924 152925 https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html 152926 https://sourceware.org/pipermail/binutils/2021-November/118498.html 152927 152928 and it is agreed, that it is unfortunate that the 32-bit riscv and 152929 32-bit mips targets require a 64-bit bfd. If in the future this 152930 situation ever changes then it would be expected that some (or all) of 152931 this patch would be reverted. Until then though, this patch allows 152932 GDB to build when configured with --enable-targets=all, and when using 152933 a 32-bit libbfd. 152934 1529352021-12-13 GDB Administrator <gdbadmin@sourceware.org> 152936 152937 Automatic date update in version.in 152938 1529392021-12-12 Tom Tromey <tom@tromey.com> 152940 152941 C++-ify path substitution code 152942 I found some uses of xfree in the path substitution code in source.c. 152943 C++-ifying struct substitute_path_rule both simplifies the code and 152944 removes manual memory management. 152945 152946 Regression tested on x86-64 Fedora 34. 152947 1529482021-12-12 GDB Administrator <gdbadmin@sourceware.org> 152949 152950 Automatic date update in version.in 152951 1529522021-12-11 Alan Modra <amodra@gmail.com> 152953 152954 [GOLD] PowerPC64 @notoc in non-power10 code 152955 Gold version of commit 7aba54da42. 152956 152957 elfcpp/ 152958 * powerpc.h (R_PPC64_REL24_P9NOTOC): Define. 152959 gold/ 152960 * powerpc.cc (Target_powerpc::maybe_skip_tls_get_addr_call, 152961 is_branch_reloc, max_branch_delta): Handle R_PPC64_REL24_P9NOTOC. 152962 (Target_powerpc::Branch_info::make_stub): Likewise. 152963 (struct Plt_stub_ent): Add p9notoc_, p9off_, tsize_. 152964 (struct Branch_stub_ent): Add p9notoc_, p9off_. 152965 (Stub_table::add_plt_call_entry): Handle R_PPC64_REL24_P9NOTOC. 152966 (Stub_table::add_long_branch_entry): Likewise. 152967 (Stub_table::add_eh_frame): Likewise. 152968 (Stub_table::plt_call_size): Return aligned size. Adjust callers. 152969 Handle p9notoc_ sizing. 152970 (Stub_table::do_write): Write out p9notoc_ stubs. 152971 (Target_powerpc::Scan::get_reference_flags, local, global): 152972 Handle R_PPC64_REL24_P9NOTOC. 152973 (Target_powerpc::Relocate::relocate): Likewise. 152974 1529752021-12-11 H.J. Lu <hjl.tools@gmail.com> 152976 152977 Don't return the main file as the separate debug info 152978 On Fedora 35, 152979 152980 $ readelf -d /usr/bin/npc 152981 152982 caused readelf to run out of stack since load_separate_debug_info 152983 returned the input main file as the separate debug info: 152984 152985 (gdb) bt 152986 #0 load_separate_debug_info ( 152987 main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo", 152988 xlink=xlink@entry=0x4e5180 <debug_displays+4480>, 152989 parse_func=parse_func@entry=0x431550 <parse_gnu_debuglink>, 152990 check_func=check_func@entry=0x432ae0 <check_gnu_debuglink>, 152991 func_data=func_data@entry=0x7fffffffdb60, file=file@entry=0x51d430) 152992 at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057 152993 #1 0x000000000043328d in check_for_and_load_links (file=0x51d430, 152994 filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") 152995 at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381 152996 #2 0x00000000004332ae in check_for_and_load_links (file=0x51b070, 152997 filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") 152998 152999 Return NULL if the separate debug info is the same as the input main 153000 file to avoid infinite recursion. 153001 153002 PR binutils/28679 153003 * dwarf.c (load_separate_debug_info): Don't return the input 153004 main file. 153005 1530062021-12-11 Alan Modra <amodra@gmail.com> 153007 153008 Don't edit bogus sh_link on reading relocatable objects (Oracle fix) 153009 This reverts a 1995 fix to handle bogus object files. Presumably such 153010 object files have long gone. 153011 153012 * elf.c (bfd_section_from_shdr): Remove old hack for Oracle 153013 libraries. 153014 1530152021-12-11 GDB Administrator <gdbadmin@sourceware.org> 153016 153017 Automatic date update in version.in 153018 1530192021-12-10 Jan Vrany <jan.vrany@labware.com> 153020 153021 gdb/testsuite: respect GDBSERVER variable in remote-stdio-gdbserver "board" 153022 The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says 153023 that user can specify path to gdbserver on remote system by setting 153024 GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver 153025 was used unconditionally. 153026 153027 This commit updates the code to respect GDBSERVER if set and fall back to 153028 /usr/bin/gdbserver if not. 153029 1530302021-12-10 Simon Marchi <simon.marchi@polymtl.ca> 153031 153032 Revert "gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`" 153033 This reverts commit fe72c32765e1190c8a17d309fc3a7e1882d6a430. 153034 153035 It turns out it was wrong, libinproctrace.so does build its own 153036 gdbsupport/tdesc.cc. This broke the build: 153037 153038 make[1]: Entering directory '/home/simark/build/binutils-gdb-one-target/gdbserver' 153039 CXXLD libinproctrace.so 153040 /usr/bin/ld: gdbsupport/tdesc-ipa.o: in function `print_xml_feature::visit_pre(target_desc const*)': 153041 /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:407: undefined reference to `tdesc_architecture_name(target_desc const*)' 153042 /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:408: undefined reference to `tdesc_architecture_name(target_desc const*)' 153043 /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:411: undefined reference to `tdesc_osabi_name(target_desc const*)' 153044 /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:416: undefined reference to `tdesc_compatible_info_list(target_desc const*)' 153045 /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:418: undefined reference to `tdesc_compatible_info_arch_name(std::unique_ptr<tdesc_compatible_info, std::default_delete<tdesc_compatible_info> > const&)' 153046 1530472021-12-10 GDB Administrator <gdbadmin@sourceware.org> 153048 153049 Automatic date update in version.in 153050 1530512021-12-09 Alan Modra <amodra@gmail.com> 153052 153053 PR28674, objdump crash 153054 Not returning an error indication here leaves the attribute 153055 uninitialised, which then leads to intemperate behaviour. 153056 153057 PR 28674 153058 * dwarf2.c (read_attribute_value): Return NULL on trying to read 153059 past end of attributes. 153060 1530612021-12-09 Alan Modra <amodra@gmail.com> 153062 153063 Set sh_link for reloc sections created as normal sections 153064 binutils-all/strip-13 and binutils-all/strip-14 tests create 153065 SHT_REL/SHT_RELA sections by hand. These don't have sh_link set to 153066 the .symtab section as they should, leading to readelf warnings if you 153067 happen to be looking at the object files. 153068 153069 * elf.c (assign_section_numbers): Formatting. Set sh_link for 153070 reloc sections created as normal sections in relocatable 153071 objects. 153072 1530732021-12-09 Simon Marchi <simon.marchi@efficios.com> 153074 153075 gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT` 153076 I suppose this code was copied from GDBserver and this ifndef was left 153077 there. As far as I know, IN_PROCESS_AGENT will never be defined when 153078 building this file, so we can remove this. 153079 153080 Change-Id: I84fc408e330b3a29106df830a09342861cadbaf6 153081 1530822021-12-09 Simon Marchi <simon.marchi@polymtl.ca> 153083 153084 gdb/microblaze-tdep.c: fix -Wunused-but-set-variable 153085 Fix this, seen when building with clang 14: 153086 153087 CXX microblaze-tdep.o 153088 /home/simark/src/binutils-gdb/gdb/microblaze-tdep.c:207:7: error: variable 'flags' set but not used [-Werror,-Wunused-but-set-variable] 153089 int flags = 0; 153090 ^ 153091 153092 Change-Id: I59f726ed33e924912748bc475b6fd9a9394fc0d0 153093 1530942021-12-09 Simon Marchi <simon.marchi@polymtl.ca> 153095 153096 gdb/csky-tdep.c: fix -Wunused-but-set-variable error 153097 Fix these, seen when building with clang 14: 153098 153099 CXX csky-tdep.o 153100 /home/simark/src/binutils-gdb/gdb/csky-tdep.c:332:7: error: variable 'need_dummy_stack' set but not used [-Werror,-Wunused-but-set-variable] 153101 int need_dummy_stack = 0; 153102 ^ 153103 /home/simark/src/binutils-gdb/gdb/csky-tdep.c:805:12: error: variable 'offset' set but not used [-Werror,-Wunused-but-set-variable] 153104 int offset = 0; 153105 ^ 153106 153107 Change-Id: I6703bcb50e83c50083f716f4084ef6aa30d659c4 153108 1531092021-12-09 Simon Marchi <simon.marchi@polymtl.ca> 153110 153111 gdb/testsuite: fix default behavior of runto 153112 The documented behavior of proc runto is to not emit a PASS when 153113 succeeding to to run to the specified location, but emit a FAIL when 153114 failing to do so. I suppose the intent is that it won't pollute the 153115 results normally passing tests (although I don't see why we would care), 153116 but make visible any problems. 153117 153118 However, it seems like the implementation makes it default to never 153119 print anything. "no-message" is prependend to "args", so if "message" 153120 is not passed, we will always take the path that sets print_fail to 0, 153121 which will silence any failure. 153122 153123 This unfortunately means that tests relying on runto_main won't emit a 153124 FAIL if failing to run to main. And since commit 4dfef5be6812 153125 ("gdb/testsuite: make runto_main not pass no-message to runto"), tests 153126 don't emit a FAIL themselves when failing to run to main. This means 153127 that tests failing to run to main just fail silently, and that's bad. 153128 153129 This can be reproduced by hacking gdb.base/template.exp like so: 153130 153131 diff --git a/gdb/testsuite/gdb.base/template.c b/gdb/testsuite/gdb.base/template.c 153132 index bcf39c377d92..052be5b79d73 100644 153133 --- a/gdb/testsuite/gdb.base/template.c 153134 +++ b/gdb/testsuite/gdb.base/template.c 153135 @@ -15,6 +15,14 @@ 153136 You should have received a copy of the GNU General Public License 153137 along with this program. If not, see <http://www.gnu.org/licenses/>. */ 153138 153139 +#include <stdlib.h> 153140 + 153141 +__attribute__((constructor)) 153142 +static void c (void) 153143 +{ 153144 + exit (1); 153145 +} 153146 + 153147 int 153148 main (void) 153149 { 153150 153151 Running the modified gdb.base/template.exp shows that it exits without 153152 printing any result. 153153 153154 Remove the line that prepends no-message to args, that should make 153155 runto's behavior match its documentation. 153156 153157 This patch will appear to add many failures, but in reality they already 153158 existed, they were just silenced. 153159 153160 Change-Id: I2a730d5bc72b6ef0698cd6aad962d9902aa7c3d6 153161 1531622021-12-09 Carl Love <cel@us.ibm.com> 153163 153164 gdb fix elfv1 Powerpc gdb.dwarf2/frame-inlined-in-outer-frame.exp 153165 On ELFv1, the _start symbol must point to the *function descriptor* (in 153166 the .opd section), not to the function code (in the .text section) like 153167 with ELFv2 and other architectures. 153168 1531692021-12-09 Tom de Vries <tdevries@suse.de> 153170 153171 [gdb/testsuite] Fix gdb.base/maint.exp with -readnow 153172 With test-case gdb.base/maint.exp and target board -readnow, I run into: 153173 ... 153174 FAIL: gdb.base/maint.exp: maint info line-table w/o a file name 153175 ... 153176 153177 The problem is that this and other regexps anchored using '^': 153178 ... 153179 -re "^$gdb_prompt $" { 153180 ... 153181 don't trigger because other regexps don't consume the entire preceding line. 153182 153183 This is partly due to the addition of the IS-STMT column. 153184 153185 Fix this by making the regexps consume entire lines. 153186 153187 Tested on x86_64-linux with native and target board readnow, as well as 153188 check-read1 and check-readmore. 153189 1531902021-12-09 Tom de Vries <tdevries@suse.de> 153191 153192 [gdb/testsuite] Fix gdb.base/include-main.exp with -readnow 153193 With test-case gdb.base/include-main.exp and target board readnow, I run into: 153194 ... 153195 FAIL: gdb.base/include-main.exp: maint info symtab 153196 ... 153197 153198 The corresponding check in gdb.base/include-main.exp: 153199 ... 153200 gdb_test_no_output "maint info symtab" 153201 ... 153202 checks that no CU was expanded, while -readnow ensures that all CUs are 153203 expanded. 153204 153205 Fix this by skipping the check with -readnow. 153206 153207 Tested on x86_64-linux, with native and target board readnow. 153208 1532092021-12-09 Nelson Chu <nelson.chu@sifive.com> 153210 153211 RISC-V: Clarify the behavior of .option arch directive. 153212 * To be consistent with -march option, removed the "=" operator when 153213 user want to reset the whole architecture string. So the formats are, 153214 153215 .option arch, +<extension><version>, ... 153216 .option arch, -<extension> 153217 .option arch, <ISA string> 153218 153219 * Don't allow to add or remove the base extensions in the .option arch 153220 directive. Instead, users should reset the whole architecture string 153221 while they want to change the base extension. 153222 153223 * The operator "+" won't update the version of extension, if the 153224 extension is already in the subset list. 153225 153226 bfd/ 153227 * elfxx-riscv.c (riscv_add_subset): Don't update the version 153228 if the extension is already in the subset list. 153229 (riscv_update_subset): To be consistent with -march option, 153230 removed the "=" operator when user want to reset the whole 153231 architecture string. Besides, Don't allow to add or remove 153232 the base extensions in the .option arch directive. 153233 gas/ 153234 * testsuite/gas/riscv/option-arch-01.s: Updated since we cannot 153235 add or remove the base extensions in the .option arch directive. 153236 * testsuite/gas/riscv/option-arch-02.s: Likewise. 153237 * testsuite/gas/riscv/option-arch-fail.l: Likewise. 153238 * testsuite/gas/riscv/option-arch-fail.s: Likewise. 153239 * testsuite/gas/riscv/option-arch-01a.d: Set -misa-spec=2.2. 153240 * testsuite/gas/riscv/option-arch-01b.d: Likewise. 153241 * testsuite/gas/riscv/option-arch-02.d: Updated since the .option 153242 arch, + won't change the version of extension, if the extension is 153243 already in the subset list. 153244 * testsuite/gas/riscv/option-arch-03.s: Removed the "=" operator 153245 when resetting the whole architecture string. 153246 1532472021-12-09 Mike Frysinger <vapier@gentoo.org> 153248 153249 sim: use ## for automake comments 153250 The ## marker tells automake to not include the comment in its 153251 generated output, so use that in most places where the comment 153252 only makes sense in the inputs. 153253 1532542021-12-09 Simon Marchi <simon.marchi@efficios.com> 153255 153256 gdb, gdbserver: detach fork child when detaching from fork parent 153257 While working with pending fork events, I wondered what would happen if 153258 the user detached an inferior while a thread of that inferior had a 153259 pending fork event. What happens with the fork child, which is 153260 ptrace-attached by the GDB process (or by GDBserver), but not known to 153261 the core? Sure enough, neither the core of GDB or the target detach the 153262 child process, so GDB (or GDBserver) just stays ptrace-attached to the 153263 process. The result is that the fork child process is stuck, while you 153264 would expect it to be detached and run. 153265 153266 Make GDBserver detach of fork children it knows about. That is done in 153267 the generic handle_detach function. Since a process_info already exists 153268 for the child, we can simply call detach_inferior on it. 153269 153270 GDB-side, make the linux-nat and remote targets detach of fork children 153271 known because of pending fork events. These pending fork events can be 153272 stored in: 153273 153274 - thread_info::pending_waitstatus, if the core has consumed the event 153275 but then saved it for later (for example, because it got the event 153276 while stopping all threads, to present an all-stop stop on top of a 153277 non-stop target) 153278 - thread_info::pending_follow: if we ran to a "catch fork" and we 153279 detach at that moment 153280 153281 Additionally, pending fork events can be in target-specific fields: 153282 153283 - For linux-nat, they can be in lwp_info::status and 153284 lwp_info::waitstatus. 153285 - For the remote target, they could be stored as pending stop replies, 153286 saved in `remote_state::notif_state::pending_event`, if not 153287 acknowledged yet, or in `remote_state::stop_reply_queue`, if 153288 acknowledged. I followed the model of remove_new_fork_children for 153289 this: call remote_notif_get_pending_events to process / 153290 acknowledge any unacknowledged notification, then look through 153291 stop_reply_queue. 153292 153293 Update the gdb.threads/pending-fork-event.exp test (and rename it to 153294 gdb.threads/pending-fork-event-detach.exp) to try to detach the process 153295 while it is stopped with a pending fork event. In order to verify that 153296 the fork child process is correctly detached and resumes execution 153297 outside of GDB's control, make that process create a file in the test 153298 output directory, and make the test wait $timeout seconds for that file 153299 to appear (it happens instantly if everything goes well). 153300 153301 This test catches a bug in linux-nat.c, also reported as PR 28512 153302 ("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig() 153303 const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == 153304 TARGET_WAITKIND_SIGNALLED' failed.). When detaching a thread with a 153305 pending event, get_detach_signal unconditionally fetches the signal 153306 stored in the waitstatus (`tp->pending_waitstatus ().sig ()`). However, 153307 that is only valid if the pending event is of type 153308 TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit 153309 would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean 153310 the thread does not exist anymore, so we wouldn't be detaching it). Add 153311 a condition in get_detach_signal to access the signal number only if the 153312 wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0 153313 instead (since the thread was not stopped with a signal to begin with). 153314 153315 Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to 153316 verify that we consider events in pending stop replies in the remote 153317 target. This test has many threads constantly forking, and we detach 153318 from the program while the program is executing. That gives us some 153319 chance that we detach while a fork stop reply is stored in the remote 153320 target. To verify that we correctly detach all fork children, we ask 153321 the parent to exit by sending it a SIGUSR1 signal and have it write a 153322 file to the filesystem before exiting. Because the parent's main thread 153323 joins the forking threads, and the forking threads wait for their fork 153324 children to exit, if some fork child is not detach by GDB, the parent 153325 will not write the file, and the test will time out. If I remove the 153326 new remote_detach_pid calls in remote.c, the test fails eventually if I 153327 run it in a loop. 153328 153329 There is a known limitation: we don't remove breakpoints from the 153330 children before detaching it. So the children, could hit a trap 153331 instruction after being detached and crash. I know this is wrong, and 153332 it should be fixed, but I would like to handle that later. The current 153333 patch doesn't fix everything, but it's a step in the right direction. 153334 153335 Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd 153336 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512 153337 1533382021-12-09 Simon Marchi <simon.marchi@efficios.com> 153339 153340 gdb: move clearing of tp->pending_follow to follow_fork_inferior 153341 A following patch will change targets so that when they detach an 153342 inferior, they also detach any pending fork children this inferior may 153343 have. While doing this, I hit a case where we couldn't differentiate 153344 two cases, where in one we should detach the fork detach but not in the 153345 other. 153346 153347 Suppose we continue past a fork with "follow-fork-mode == child" && 153348 "detach-on-fork on". follow_fork_inferior calls target_detach to detach 153349 the parent. In that case the target should not detach the fork 153350 child, as we'll continue debugging the child. As of now, the 153351 tp->pending_follow field of the thread who called fork still contains 153352 the details about the fork. 153353 153354 Then, suppose we run to a fork catchpoint and the user types "detach". 153355 In that case, the target should detach the fork child in addition to the 153356 parent. In that case as well, the tp->pending_follow field contains 153357 the details about the fork. 153358 153359 To allow targets to differentiate the two cases, clear 153360 tp->pending_follow a bit earlier, when following a fork. Targets will 153361 then see that tp->pending_follow contains TARGET_WAITKIND_SPURIOUS, and 153362 won't detach the fork child. 153363 153364 As of this patch, no behavior changes are expected. 153365 153366 Change-Id: I537741859ed712cb531baaefc78bb934e2a28153 153367 1533682021-12-09 Simon Marchi <simon.marchi@efficios.com> 153369 153370 gdb/remote.c: refactor pending fork status functions 153371 In preparation for a following patch, refactor a few things that I did 153372 find a bit awkward, and to make them a bit more reusable. 153373 153374 - Pass an inferior to kill_new_fork_children instead of a pid. That 153375 allows iterating on only this inferior's threads and avoid further 153376 filtering on the thread's pid. 153377 - Change thread_pending_fork_status to return a non-nullptr value only 153378 if the thread does have a pending fork status. 153379 - Remove is_pending_fork_parent_thread, as one can just use 153380 thread_pending_fork_status and check for nullptr. 153381 - Replace is_pending_fork_parent with is_fork_status, which just 153382 returns if the given target_waitkind if a fork or a vfork. Push 153383 filtering on the pid to the callers, when it is necessary. 153384 153385 Change-Id: I0764ccc684d40f054e39df6fa5458cc4c5d1cd7b 153386 1533872021-12-09 Simon Marchi <simon.marchi@efficios.com> 153388 153389 gdb/remote.c: move some things up 153390 Move the stop_reply and a few functions up. Some code above them in the 153391 file will need to use them in a following patch. No behavior changes 153392 expected here. 153393 153394 Change-Id: I3ca57d0e3ec253f56e1ba401289d9d167de14ad2 153395 1533962021-12-09 Simon Marchi <simon.marchi@efficios.com> 153397 153398 gdb/linux-nat: factor ptrace-detach code to new detach_one_pid function 153399 The following patch will add some code paths that need to ptrace-detach 153400 a given PID. Factor out the code that does this and put it in its own 153401 function, so that it can be re-used. 153402 153403 Change-Id: Ie65ca0d89893b41aea0a23d9fc6ffbed042a9705 153404 1534052021-12-09 Simon Marchi <simon.marchi@efficios.com> 153406 153407 gdbserver: hide fork child threads from GDB 153408 This patch aims at fixing a bug where an inferior is unexpectedly 153409 created when a fork happens at the same time as another event, and that 153410 other event is reported to GDB first (and the fork event stays pending 153411 in GDBserver). This happens for example when we step a thread and 153412 another thread forks at the same time. The bug looks like (if I 153413 reproduce the included test by hand): 153414 153415 (gdb) show detach-on-fork 153416 Whether gdb will detach the child of a fork is on. 153417 (gdb) show follow-fork-mode 153418 Debugger response to a program call of fork or vfork is "parent". 153419 (gdb) si 153420 [New inferior 2] 153421 Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target... 153422 Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target... 153423 Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread... 153424 [New Thread 965190.965190] 153425 [Switching to Thread 965190.965190] 153426 Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): ... <long series of bytes> 153427 153428 The sequence of events leading to the problem is: 153429 153430 - We are using the all-stop user-visible mode as well as the 153431 synchronous / all-stop variant of the remote protocol 153432 - We have two threads, thread A that we single-step and thread B that 153433 calls fork at the same time 153434 - GDBserver's linux_process_target::wait pulls the "single step 153435 complete SIGTRAP" and the "fork" events from the kernel. It 153436 arbitrarily choses one event to report, it happens to be the 153437 single-step SIGTRAP. The fork stays pending in the thread_info. 153438 - GDBserver send that SIGTRAP as a stop reply to GDB 153439 - While in stop_all_threads, GDB calls update_thread_list, which ends 153440 up querying the remote thread list using qXfer:threads:read. 153441 - In the reply, GDBserver includes the fork child created as a result 153442 of thread B's fork. 153443 - GDB-side, the remote target sees the new PID, calls 153444 remote_notice_new_inferior, which ends up unexpectedly creating a new 153445 inferior, and things go downhill from there. 153446 153447 The problem here is that as long as GDB did not process the fork event, 153448 it should pretend the fork child does not exist. Ultimately, this event 153449 will be reported, we'll go through follow_fork, and that process will be 153450 detached. 153451 153452 The remote target (GDB-side), has some code to remove from the reported 153453 thread list the threads that are the result of forks not processed by 153454 GDB yet. But that only works for fork events that have made their way 153455 to the remote target (GDB-side), but haven't been consumed by the core 153456 yet, so are still lingering as pending stop replies in the remote target 153457 (see remove_new_fork_children in remote.c). But in our case, the fork 153458 event hasn't made its way to the GDB-side remote target. We need to 153459 implement the same kind of logic GDBserver-side: if there exists a 153460 thread / inferior that is the result of a fork event GDBserver hasn't 153461 reported yet, it should exclude that thread / inferior from the reported 153462 thread list. 153463 153464 This was actually discussed a while ago, but not implemented AFAIK: 153465 153466 https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t 153467 https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html 153468 153469 Implementation details-wise, the fix for this is all in GDBserver. The 153470 Linux layer of GDBserver already tracks unreported fork parent / child 153471 relationships using the lwp_info::fork_relative, in order to avoid 153472 wildcard actions resuming fork childs unknown to GDB. This information 153473 needs to be made available to the handle_qxfer_threads_worker function, 153474 so it can filter the reported threads. Add a new thread_pending_parent 153475 target function that allows the Linux target to return the parent of an 153476 eventual fork child. 153477 153478 Testing-wise, the test replicates pretty-much the sequence of events 153479 shown above. The setup of the test makes it such that the main thread 153480 is about to fork. We stepi the other thread, so that the step completes 153481 very quickly, in a single event. Meanwhile, the main thread is resumed, 153482 so very likely has time to call fork. This means that the bug may not 153483 reproduce every time (if the main thread does not have time to call 153484 fork), but it will reproduce more often than not. The test fails 153485 without the fix applied on the native-gdbserver and 153486 native-extended-gdbserver boards. 153487 153488 At some point I suspected that which thread called fork and which thread 153489 did the step influenced the order in which the events were reported, and 153490 therefore the reproducibility of the bug. So I made the test try both 153491 combinations: main thread forks while other thread steps, and vice 153492 versa. I'm not sure this is still necessary, but I left it there 153493 anyway. It doesn't hurt to test a few more combinations. 153494 153495 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28288 153496 Change-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990 153497 1534982021-12-09 GDB Administrator <gdbadmin@sourceware.org> 153499 153500 Automatic date update in version.in 153501 1535022021-12-08 Tom Tromey <tom@tromey.com> 153503 153504 Use for-each more in gdb 153505 There are some loops in gdb that use ARRAY_SIZE (or a wordier 153506 equivalent) to loop over a static array. This patch changes some of 153507 these to use foreach instead. 153508 153509 Regression tested on x86-64 Fedora 34. 153510 1535112021-12-08 Tom Tromey <tromey@adacore.com> 153512 153513 Fix error in file_and_directory patch 153514 In my earlier C++-ization patch for file_and_directory, I introduced 153515 an error: 153516 153517 - if (strcmp (fnd.name, "<unknown>") != 0) 153518 + if (fnd.is_unknown ()) 153519 153520 This change inverted the sense of the test, which causes failures with 153521 .debug_names. 153522 153523 This patch fixes the bug. Regression tested on x86-64 Fedora 34. I 153524 also tested it using the AdaCore internal test suite, with 153525 .debug_names -- this was failing before, and now it works. 153526 1535272021-12-08 Andrew Burgess <aburgess@redhat.com> 153528 153529 gdb/python: Use tp_init instead of tp_new to setup gdb.Value 153530 The documentation suggests that we implement gdb.Value.__init__, 153531 however, this is not currently true, we really implement 153532 gdb.Value.__new__. This will cause confusion if a user tries to 153533 sub-class gdb.Value. They might write: 153534 153535 class MyVal (gdb.Value): 153536 def __init__ (self, val): 153537 gdb.Value.__init__(self, val) 153538 153539 obj = MyVal(123) 153540 print ("Got: %s" % obj) 153541 153542 But, when they source this code they'll see: 153543 153544 (gdb) source ~/tmp/value-test.py 153545 Traceback (most recent call last): 153546 File "/home/andrew/tmp/value-test.py", line 7, in <module> 153547 obj = MyVal(123) 153548 File "/home/andrew/tmp/value-test.py", line 5, in __init__ 153549 gdb.Value.__init__(self, val) 153550 TypeError: object.__init__() takes exactly one argument (the instance to initialize) 153551 (gdb) 153552 153553 The reason for this is that, as we don't implement __init__ for 153554 gdb.Value, Python ends up calling object.__init__ instead, which 153555 doesn't expect any arguments. 153556 153557 The Python docs suggest that the reason why we might take this 153558 approach is because we want gdb.Value to be immutable: 153559 153560 https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new 153561 153562 But I don't see any reason why we should require gdb.Value to be 153563 immutable when other types defined in GDB are not. This current 153564 immutability can be seen in this code: 153565 153566 obj = gdb.Value(1234) 153567 print("Got: %s" % obj) 153568 obj.__init__ (5678) 153569 print("Got: %s" % obj) 153570 153571 Which currently runs without error, but prints: 153572 153573 Got: 1234 153574 Got: 1234 153575 153576 In this commit I propose that we switch to using __init__ to 153577 initialize gdb.Value objects. 153578 153579 This does introduce some additional complexity, during the __init__ 153580 call a gdb.Value might already be associated with a gdb value object, 153581 in which case we need to cleanly break that association before 153582 installing the new gdb value object. However, the cost of doing this 153583 is not great, and the benefit - being able to easily sub-class 153584 gdb.Value seems worth it. 153585 153586 After this commit the first example above works without error, while 153587 the second example now prints: 153588 153589 Got: 1234 153590 Got: 5678 153591 153592 In order to make it easier to override the gdb.Value.__init__ method, 153593 I have tweaked the definition of gdb.Value.__init__. The second, 153594 optional argument to __init__ is a gdb.Type, if this argument is not 153595 present then GDB figures out a suitable type. 153596 153597 However, if we want to override the __init__ method in a sub-class, 153598 and still support the default argument, it is easier to write: 153599 153600 class MyVal (gdb.Value): 153601 def __init__ (self, val, type=None): 153602 gdb.Value.__init__(self, val, type) 153603 153604 Currently, passing None for the Type will result in an error: 153605 153606 TypeError: type argument must be a gdb.Type. 153607 153608 After this commit I now allow the type argument to be None, in which 153609 case GDB figures out a suitable type just as if the type had not been 153610 passed at all. 153611 153612 Unless a user is trying to reinitialize a value, or create sub-classes 153613 of gdb.Value, there should be no user visible changes after this 153614 commit. 153615 1536162021-12-08 Andrew Burgess <aburgess@redhat.com> 153617 153618 gdb: use try/catch around a gdb_disassembler::print_insn call 153619 While investigating some disassembler problems I ran into this case; 153620 GDB compiled on a 32-bit arm target, with --enable-targets=all. Then 153621 in GDB: 153622 153623 (gdb) set architecture i386 153624 (gdb) disassemble 0x0,+4 153625 unknown disassembler error (error = -1) 153626 153627 This is interesting because it shows a case where the libopcodes 153628 disassembler is returning -1 without first calling the 153629 memory_error_func callback. Indeed, the return from libopcodes 153630 happens from this code snippet in i386-dis.c in the print_insn 153631 function: 153632 153633 if (address_mode == mode_64bit && sizeof (bfd_vma) < 8) 153634 { 153635 (*info->fprintf_func) (info->stream, 153636 _("64-bit address is disabled")); 153637 return -1; 153638 } 153639 153640 Notice how, prior to the return the disassembler tries to print a 153641 helpful message out, but GDB doesn't print this message. 153642 153643 The reason this message goes missing is the call stack, it looks like 153644 this: 153645 153646 gdb_pretty_print_disassembler::pretty_print_insn 153647 gdb_disassembler::print_insn 153648 gdbarch_print_insn 153649 ... 153650 i386-dis.c:print_insn 153651 153652 When i386-dis.c:print_insn returns -1 this is handled in 153653 gdb_disassembler::print_insn, where an exception is thrown. However, 153654 the actual printing of the disassembler output is done in 153655 gdb_pretty_print_disassembler::pretty_print_insn, and is only done if 153656 an exception is not thrown. 153657 153658 In this commit I change this. The pretty_print_insn now uses 153659 try/catch around the call to gdb_disassembler::print_insn, if we catch 153660 an error then we first print any pending output in the instruction 153661 buffer, before rethrowing the exception. As a result, even if an 153662 exception is thrown we still print any pending disassembler output to 153663 the screen; in the above case the helpful message will now be shown. 153664 153665 Before my patch we might expect to see this output: 153666 153667 (gdb) disassemble 0x0,+4 153668 Dump of assembler code from 0x0 to 0x4: 153669 0x0000000000000000: unknown disassembler error (error = -1) 153670 (gdb) 153671 153672 But now we see this: 153673 153674 (gdb) disassemble 0x0,+4 153675 Dump of assembler code from 0x0 to 0x4: 153676 0x0000000000000000: 64-bit address is disabled 153677 unknown disassembler error (error = -1) 153678 153679 If the disassembler returns -1 without printing a helpful message then 153680 we would still expect a change in output, something like: 153681 153682 (gdb) disassemble 0x0,+4 153683 Dump of assembler code from 0x0 to 0x4: 153684 0x0000000000000000: 153685 unknown disassembler error (error = -1) 153686 153687 Which I think is still acceptable, though at this point I think a 153688 strong case can be made that this is a disassembler bug (not printing 153689 anything, but still returning -1). 153690 153691 Notice however, that the error message is always printed on a new line 153692 now. This is also true for the memory error case, where before we 153693 might see this: 153694 153695 (gdb) disassemble 0x0,+4 153696 Dump of assembler code from 0x0 to 0x4: 153697 0x00000000: Cannot access memory at address 0x0 153698 153699 We now get this: 153700 153701 (gdb) disassemble 0x0,+4 153702 Dump of assembler code from 0x0 to 0x4: 153703 0x00000000: 153704 Cannot access memory at address 0x0 153705 153706 For me, I'm happy to accept this change, having the error on a line by 153707 itself, rather than just appended to the end of the previous line, 153708 seems like an improvement, but I'm aware others might feel 153709 differently, so I'd appreciate any feedback. 153710 1537112021-12-08 Jan Vrany <jan.vrany@labware.com> 153712 153713 ppc: recognize all program traps 153714 Permanent program breakpoints (ones inserted into the code) other than 153715 the one GDB uses for POWER (0x7fe00008) did not result in stop but 153716 caused GDB to loop infinitely. 153717 153718 This was because GDB did not recognize trap instructions other than 153719 "trap". For example, "tw 12, 4, 4" was not be recognized, causing GDB 153720 to loop forever. 153721 153722 This commit fixes this by providing POWER specific hook 153723 (gdbarch_program_breakpoint_here_p) recognizing all tw, twi, td and tdi 153724 instructions. 153725 153726 Tested on Linux on PowerPC e500 and on QEMU PPC64le. 153727 1537282021-12-08 Jan Vrany <jan.vrany@labware.com> 153729 153730 ppc: use "trap" ("tw, 31, 0, 0") as breakpoint instruction 153731 Power ISA 3.0 B spec [1], sections 3.3.11 "Fixed-Point Trap Instructions" 153732 and section C.6 "Trap Mnemonics" specify "tw, 31, 0, 0" (encoded as 153733 0x7fe00008) as canonical unconditional trap instruction. 153734 153735 This commit changes the breakpoint instruction used by GDB from 153736 "tw 12, r2, r2" to unconditional "trap". 153737 153738 [1]: https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 153739 1537402021-12-08 Fangrui Song <maskray@google.com> 153741 153742 bfd_section_from_shdr: Support SHT_RELR sections 153743 If a.so contains an SHT_RELR section, objcopy a.so will fail with: 153744 153745 a.so: unknown type [0x13] section `.relr.dyn' 153746 153747 This change allows objcopy to work. 153748 153749 bfd/ 153750 * elf.c (bfd_section_from_shdr): Support SHT_RELR. 153751 1537522021-12-08 Alan Modra <amodra@gmail.com> 153753 153754 PR28673, input file 'gcov' is the same as output file 153755 PR 28673 153756 * ldlang.c (open_output): Use local_sym_name when checking 153757 output against input files rather than filename. 153758 1537592021-12-08 Tom Tromey <tom@tromey.com> 153760 153761 Fix bug in source.c change 153762 My earlier change to source.c ("Remove an xfree from add_path") 153763 introduced a regression. This patch fixes the problem. 153764 1537652021-12-08 Simon Marchi <simon.marchi@polymtl.ca> 153766 153767 gdb: make struct linespect contain vectors, not pointers to vectors 153768 struct linespec contains pointers to vectors, instead of containing 153769 vectors directly. This is probably historical, when linespec_parser 153770 (which contains a struct linespec field) was not C++-ified yet. But it 153771 seems easy to change the pointers to vectors to just vectors today. 153772 This simplifies the code, we don't need to manually allocate and delete 153773 the vectors and there's no pointer that can be NULL. 153774 153775 As far as I understand, there was not meaningful distinction between a 153776 NULL pointer to vector and an empty vector. So all NULL checks are 153777 changed for !empty checks. 153778 153779 Change-Id: Ie759707da14d9d984169b93233343a86e2de9ee6 153780 1537812021-12-08 GDB Administrator <gdbadmin@sourceware.org> 153782 153783 Automatic date update in version.in 153784 1537852021-12-07 Tom Tromey <tom@tromey.com> 153786 153787 Remove an xfree from add_path 153788 This removes a temporary \0 assignment and an xfree from add_path, 153789 replacing it with a simpler use of std::string. 153790 1537912021-12-07 Simon Marchi <simon.marchi@polymtl.ca> 153792 153793 gdb/linespec.c: simplify condition 153794 We can remove the empty check: if the vector has size 1, it is obviously 153795 not empty. This code ended up like this because the empty check used to 153796 be a NULL check. 153797 153798 Change-Id: I1571bd0228818ca93f6a6b444e9b010dc2da4c08 153799 1538002021-12-07 Simon Marchi <simon.marchi@polymtl.ca> 153801 153802 gdb: rename "maint agent" functions 153803 Functions agent_eval_command and agent_command are used to implement 153804 maintenance commands, rename them accordingly (with the maint_ prefix), 153805 as well as the agent_command_1 helper function. 153806 153807 Change-Id: Iacf96d4a0a26298e8dd4648a0f38da649ea5ef61 153808 1538092021-12-07 Simon Marchi <simon.marchi@polymtl.ca> 153810 153811 gdb: make set_raw_breakpoint static 153812 set_raw_breakpoint is only used in breakpoint.c, make it static. 153813 153814 Change-Id: I7fbeda067685309a30b88aceaf957eff7a28e310 153815 1538162021-12-07 John Baldwin <jhb@FreeBSD.org> 153817 153818 Support AT_FXRNG and AT_KPRELOAD on FreeBSD. 153819 FreeBSD's kernel has recently added two new ELF auxiliary vector 153820 entries. AT_FXRNG points to a root seed version for the kernel's 153821 PRNG. Userland can use this to reseed a userland PRNG after the 153822 kernel's PRNG has reseeded. AT_KPRELOAD is the base address of a 153823 kernel-provided vDSO. 153824 153825 This change displays the proper name and description of these entries 153826 in 'info auxv'. 153827 153828 include/ChangeLog: 153829 153830 * elf/common.h (AT_FREEBSD_FXRNG, AT_FREEBSD_KPRELOAD): Define. 153831 1538322021-12-07 Tom Tromey <tromey@adacore.com> 153833 153834 Avoid extra work in global_symbol_searcher::expand_symtabs 153835 I noticed that global_symbol_searcher::expand_symtabs always passes a 153836 file matcher to expand_symtabs_matching. However, if 'filenames' is 153837 empty, then this always returns true. It's slightly more efficient to 153838 pass a null file matcher in this case, because that lets the "quick" 153839 symbol implementations skip any filename checks. 153840 153841 Regression tested on x86-64 Fedora 34. 153842 1538432021-12-07 Tom de Vries <tdevries@suse.de> 153844 153845 [gdb/testsuite] Fix options arg handling in compile_jit_elf_main_as_so 153846 In commit 80ad340c902 ("[gdb/testsuite] use -Ttext-segment for jit-elf tests") 153847 the following change was made: 153848 ... 153849 proc compile_jit_elf_main_as_so {main_solib_srcfile main_solib_binfile options} { 153850 - set options [concat $options debug] 153851 + global jit_load_address jit_load_increment 153852 + 153853 + set options [list \ 153854 + additional_flags="-DMAIN=jit_dl_main" \ 153855 + additional_flags=-DLOAD_ADDRESS=$jit_load_address \ 153856 + additional_flags=-DLOAD_INCREMENT=$jit_load_increment \ 153857 + debug] 153858 ... 153859 153860 Before the change, the options argument was used, but after the change not 153861 anymore. 153862 153863 Fix this by reverting back to using "set options [concat $options ...]". 153864 153865 Fixing this gets us twice the -DMAIN=jit_dl_main bit, once from a caller, and 153866 once from compile_jit_elf_main_as_so. Fix this by removing the bit from 153867 compile_jit_elf_main_as_so, which makes the code similar to compile_jit_main. 153868 153869 Tested on x86_64-linux. 153870 1538712021-12-07 Tom de Vries <tdevries@suse.de> 153872 153873 [gdb/testsuite] Fix FAIL in gdb.tui/basic.exp 153874 On openSUSE Leap 15.2 aarch64 I ran into: 153875 ... 153876 FAIL: gdb.tui/basic.exp: check main is where we expect on the screen 153877 ... 153878 while this is passing on x86_64. 153879 153880 On x86_64-linux we have at the initial screen dump for "list -q main": 153881 ... 153882 0 +-/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.tui/tui-layout.c--+ 153883 1 | 15 You should have received a copy of the GNU General Public | 153884 2 | 16 along with this program. If not, see <http://www.gnu.org/| 153885 3 | 17 | 153886 4 | 18 int | 153887 5 | 19 main () | 153888 6 | 20 { | 153889 7 | 21 return 0; | 153890 8 | 22 } | 153891 9 | 23 | 153892 ... 153893 but on aarch64: 153894 ... 153895 0 +-/home/tdevries/gdb/src/gdb/testsuite/gdb.tui/tui-layout.c--------------+ 153896 1 | 16 along with this program. If not, see <http://www.gnu.org/| 153897 2 | 17 | 153898 3 | 18 int | 153899 4 | 19 main () | 153900 5 | 20 { | 153901 6 | 21 return 0; | 153902 7 | 22 } | 153903 8 | 23 | 153904 9 | 24 | 153905 ... 153906 153907 The cause of the diffferent placement is that we have as line number for main 153908 on x86_64: 153909 ... 153910 $ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main" 153911 Line 20 of "tui-layout.c" starts at address 0x4004a7 <main> \ 153912 and ends at 0x4004ab <main+4>. 153913 ... 153914 and on aarch64 instead: 153915 ... 153916 $ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main" 153917 Line 21 of "tui-layout.c" starts at address 0x4005f4 <main> \ 153918 and ends at 0x4005f8 <main+4>. 153919 ... 153920 153921 Fix this by using a new source file main-one-line.c, that implements the 153922 entire main function on a single line, in order to force the compiler to use 153923 that line number. 153924 153925 Also try to do less hard-coding in the test-case. 153926 153927 Tested on x86_64-linux and aarch64-linux. 153928 1539292021-12-07 Tom de Vries <tdevries@suse.de> 153930 153931 [gdb/tdep] Fix inferior plt calls in PIE for i386 153932 Consider test-case test.c: 153933 ... 153934 int main (void) { 153935 void *p = malloc (10); 153936 return 0; 153937 } 153938 ... 153939 153940 When compiled to a non-PIE exec: 153941 ... 153942 $ gcc -m32 test.c 153943 ... 153944 the call sequence looks like: 153945 ... 153946 8048447: 83 ec 0c sub $0xc,%esp 153947 804844a: 6a 0a push $0xa 153948 804844c: e8 bf fe ff ff call 8048310 <malloc@plt> 153949 ... 153950 which calls to: 153951 ... 153952 08048310 <malloc@plt>: 153953 8048310: ff 25 0c a0 04 08 jmp *0x804a00c 153954 8048316: 68 00 00 00 00 push $0x0 153955 804831b: e9 e0 ff ff ff jmp 8048300 <.plt> 153956 ... 153957 where the first insn at 0x8048310 initially jumps to the following address 153958 0x8048316, read from the .got.plt @ 0x804a00c: 153959 ... 153960 804a000 0c9f0408 00000000 00000000 16830408 ................ 153961 804a010 26830408 &... 153962 ... 153963 153964 Likewise, when compiled as a PIE: 153965 ... 153966 $ gcc -m32 -fPIE -pie test.c 153967 ... 153968 we have this call sequence (with %ebx setup to point to the .got.plt): 153969 ... 153970 0000055d <main>: 153971 579: 83 ec 0c sub $0xc,%esp 153972 57c: 6a 0a push $0xa 153973 57e: 89 c3 mov %eax,%ebx 153974 580: e8 6b fe ff ff call 3f0 <malloc@plt> 153975 ... 153976 which calls to: 153977 ... 153978 000003f0 <malloc@plt>: 153979 3f0: ff a3 0c 00 00 00 jmp *0xc(%ebx) 153980 3f6: 68 00 00 00 00 push $0x0 153981 3fb: e9 e0 ff ff ff jmp 3e0 <.plt> 153982 ... 153983 where the insn at 0x3f0 initially jumps to following address 0x3f6, read from 153984 the .got.plt at offset 0xc: 153985 ... 153986 2000 f41e0000 00000000 00000000 f6030000 ................ 153987 2010 06040000 .... 153988 ... 153989 153990 When instead doing an inferior call to malloc (with nosharedlib to force 153991 malloc to resolve to malloc@plt rather than the functions in ld.so or libc.so) 153992 with the non-PIE exec, we have the expected: 153993 ... 153994 $ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)" 153995 Temporary breakpoint 1 at 0x8048444 153996 153997 Temporary breakpoint 1, 0x08048444 in main () 153998 $1 = 0x804b160 153999 ... 154000 154001 But with the PIE exec, we run into: 154002 ... 154003 $ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)" 154004 Temporary breakpoint 1 at 0x56c 154005 154006 Temporary breakpoint 1, 0x5655556c in main () 154007 154008 Program received signal SIGSEGV, Segmentation fault. 154009 0x565553f0 in malloc@plt () 154010 ... 154011 154012 The segfault happens because: 154013 - the inferior call mechanism doesn't setup %ebx 154014 - %ebx instead is 0 154015 - the jump to "*0xc(%ebx)" reads from memory at 0xc 154016 154017 Fix this by setting up %ebx properly in i386_thiscall_push_dummy_call. 154018 154019 Fixes this failure with target board unix/-m32/-pie/-fPIE reported in 154020 PR28467: 154021 ... 154022 FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2) 154023 ... 154024 154025 Tested on x86_64-linux, with target board unix/-m32 and unix/-m32/-fPIE/-pie. 154026 154027 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28467 154028 1540292021-12-07 Tom de Vries <tdevries@suse.de> 154030 154031 [gdb/symtab] Support -readnow during reread 154032 When running test-case gdb.base/cached-source-file.exp with target board 154033 readnow, we run into: 154034 ... 154035 FAIL: gdb.base/cached-source-file.exp: rerun program (the program exited) 154036 ... 154037 154038 The problem is that when rereading, the readnow is ignored. 154039 154040 Fix this by copying the readnow handling code from symbol_file_add_with_addrs 154041 to reread_symbols. 154042 154043 Tested on x86_64-linux. 154044 154045 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26800 154046 1540472021-12-07 Tom de Vries <tdevries@suse.de> 154048 154049 [gdb/ada] Fix assert in ada_is_unconstrained_packed_array_type 154050 On openSUSE Leap 42.3, with system compiler gcc 4.8.5 I run into: 154051 ... 154052 (gdb) print u_one_two_three^M 154053 src/gdb/gdbtypes.h:1050: internal-error: field: \ 154054 Assertion `idx >= 0 && idx < num_fields ()' failed.^M 154055 ... 154056 154057 We run into trouble while doing this in 154058 ada_is_unconstrained_packed_array_type: 154059 ... 154060 1953 return TYPE_FIELD_BITSIZE (type, 0) > 0; 154061 ... 154062 which tries to get field 0 from a type without fields: 154063 ... 154064 (gdb) p type->num_fields () 154065 $6 = 0 154066 ... 154067 which is the case because the type is a typedef: 154068 ... 154069 (gdb) p type->code () 154070 $7 = TYPE_CODE_TYPEDEF 154071 ... 154072 154073 Fix this by using the type referenced by the typedef instead. 154074 154075 Tested on x86_64-linux. 154076 154077 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28323 154078 1540792021-12-07 Alan Modra <amodra@gmail.com> 154080 154081 Re: Add support for AArch64 EFI (efi-*-aarch64) 154082 Commit b69c9d41e8 was broken in multiple ways regarding the realloc 154083 of the target string, most notably in that "-little" wasn't actually 154084 appended to the input_target or output_target. This caused asan 154085 errors and "FAIL: Check if efi app format is recognized". I also 154086 noticed that the input_target string wasn't being copied but rather 154087 the output_target when dealing with the input target. Fix that too. 154088 154089 PR 26206 154090 * objcopy.c (convert_efi_target): Rewrite. Allocate modified 154091 target strings here.. 154092 (copy_main): ..rather than here. Do handle input_target, 154093 not output_target for input. 154094 1540952021-12-07 Alan Modra <amodra@gmail.com> 154096 154097 Error on ld output file name matching input file name 154098 It's not foolproof, for example we don't catch output to a linker 154099 script, to a library specified with -l, or to an element of a thin 154100 archive. 154101 154102 * ldlang.c (open_output): Exit with error on output file matching 154103 an input file. 154104 * testsuite/ld-misc/just-symbols.exp: Adjust ld -r test to suit. 154105 1541062021-12-07 GDB Administrator <gdbadmin@sourceware.org> 154107 154108 Automatic date update in version.in 154109 1541102021-12-06 Carl Love <cel@us.ibm.com> 154111 154112 gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame 154113 This patch adds an #elif defined for PowerPC to setup the exit_0 macro. 154114 This patch addes the needed macro definitionald logic to handle both elfV1 154115 and elfV2. 154116 154117 The patch has been successfully tested on both PowerPC BE, Powerpc LE and 154118 X86_64 with no regressions. 154119 1541202021-12-06 Tom de Vries <tdevries@suse.de> 154121 154122 [gdb/testsuite] Use precise align in gdb.arch/i386-{avx,sse}.exp 154123 Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require 154124 the memory operands to be aligned to a certain boundary, and the test-cases 154125 use C11's _Alignas to make that happen. 154126 154127 The draw-back of using _Alignas is that while it does enforce a minimum 154128 alignment, the actual alignment may be bigger, which makes the following 154129 scenario possible: 154130 - copy say, gdb.arch/i386-avx.c as basis for a new test-case 154131 - run the test-case and observe a PASS 154132 - commit the new test-case in the supposition that the test-case is correct 154133 and well-tested 154134 - run later into a failure on a different test setup (which may be a setup 154135 where reproduction and investigation is more difficult and time-consuming), 154136 and find out that the specified alignment was incorrect and should have been 154137 updated to say, 64 bytes. The initial PASS occurred only because the actual 154138 alignment happened to be greater than required. 154139 154140 The idea of having precise alignment as a means of having more predictable 154141 execution which allows flushing out bugs earlier, has been filed as PR 154142 gcc/103095. 154143 154144 Add a new file lib/precise-aligned-alloc.c with functions 154145 precise_aligned_alloc and precise_aligned_dup, to support precise alignment. 154146 154147 Use precise_aligned_dup in aforementioned test-cases to: 154148 - verify that the specified alignment is indeed sufficient, rather 154149 than too little but accidentally over-aligned. 154150 - prevent the same type of problems in any new test-cases based on these 154151 154152 Tested on x86_64-linux, with both gcc and clang. 154153 1541542021-12-06 Tom de Vries <tdevries@suse.de> 154155 154156 [gdb/testsuite] Fix data alignment in gdb.arch/i386-{avx,sse}.exp 154157 When running test-case gdb.arch/i386-avx.exp with clang I ran into: 154158 ... 154159 (gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main 154160 continue^M 154161 Continuing.^M 154162 ^M 154163 Program received signal SIGSEGV, Segmentation fault.^M 154164 0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M 154165 54 asm ("vmovaps 0(%0), %%ymm0\n\t"^M 154166 (gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \ 154167 continue to first breakpoint in main 154168 ... 154169 154170 The problem is that the vmovaps insn requires an 256-bit (or 32-byte) aligned 154171 address, and it's only 16-byte aligned: 154172 ... 154173 (gdb) p /x $rax 154174 $1 = 0x601030 154175 ... 154176 154177 Fix this by using a sufficiently aligned address, using _Alignas. 154178 154179 Compile using -std=gnu11 to support _Alignas. 154180 154181 Likewise in gdb.arch/i386-sse.exp. 154182 154183 Tested on x86_64-linux, with both gcc and clang. 154184 1541852021-12-06 Alan Modra <amodra@gmail.com> 154186 154187 [GOLD] PowerPC64 inline plt sequences 154188 The fixes gold failures to handle inline PLT sequences properly. 154189 PowerPC gold was always turning these back into direct calls due to 154190 gsym->use_plt_offset() returning false. This is fixed for dynamic 154191 linking by correcting get_reference_flags, and for static linking by 154192 overriding use_plt_offset() in relocate(). The rest of the patch 154193 revolves around needing to create PLT entries for inline PLT calls 154194 when statically linking (for gcc -mlongcall). The lplt section 154195 handled that for local symbols, now it does globals too. 154196 154197 * powerpc.cc (Target_powerpc::plt_off): Return proper section 154198 for static link. 154199 (Target_powerpc::symval_for_branch): Make public. 154200 (Target_powerpc::make_lplt_section): Add Symbol_table* param. 154201 Adjust all calls. 154202 (Target_powerpc::make_local_plt_entry): Likewise. 154203 (Target_powerpc::make_local_plt_entry): New variant for global syms. 154204 (Powerpc_relobj::do_relocate_sections): Don't write lplt contents. 154205 (Output_data_plt_powerpc::do_write): Write lplt contents here. 154206 (Output_data_plt_powerpc::Output_data_plt_powerpc): Save 154207 symbol table pointer. Adjust all uses. 154208 (Output_data_plt_powerpc::add_entry): Add stash parameter. Don't 154209 do dynamic reloc handling when no reloc section. Save symbol 154210 for local plt entries. 154211 (Output_data_plt_powerpc::add_local_entry): Save symbol. 154212 (Output_data_plt_powerpc::Local_plt_ent): New class. 154213 (Output_data_plt_powerpc::sym_ents_): New vector. 154214 (Target_powerpc::Scan::get_reference_flags): Return 154215 FUNCTION_CALL|RELATIVE_REF for inline plt relocs. 154216 (Target_powerpc::Scan::global): Make entries in lplt for inline 154217 plt call relocation symbols. 154218 (Target_powerpc::Relocate::relocate): Rename has_plt_offset to 154219 use_plt_offset. Set use_plt_offset for inline plt relocs. 154220 1542212021-12-06 Clément Chigot <clement.chigot@atos.net> 154222 154223 ld: improve shared tests for AIX 154224 It's now possible to refer symbols in the main program from the 154225 shared library. However, it still impossible to have the same 154226 overriden features between shared objects and mains than ELF, 154227 without using the runtime linking feature which isn't yet fully 154228 available. 154229 154230 ld/ChangeLog: 154231 154232 * testsuite/ld-shared/shared.exp: Improve XCOFF support 154233 * testsuite/ld-shared/main.c: Likewise. 154234 * testsuite/ld-shared/sh1.c: Likewise. 154235 * testsuite/ld-shared/xcoff.dat: Likewise. 154236 1542372021-12-06 GDB Administrator <gdbadmin@sourceware.org> 154238 154239 Automatic date update in version.in 154240 1542412021-12-05 Tom Tromey <tom@tromey.com> 154242 154243 Preserve artificial CU name in process_psymtab_comp_unit_reader 154244 This fixes a use-after-free that Simon pointed out. 154245 process_psymtab_comp_unit_reader was allocating an artificial name for 154246 a CU, and then discarding it. However, this name was preserved in the 154247 cached file_and_directory. This patch arranges for the allocated name 154248 to be preserved there. 154249 1542502021-12-05 Mike Frysinger <vapier@gentoo.org> 154251 154252 sim: include ansidecl.h when needed 154253 Avoid implicit include deps with this to help untangle sim headers 154254 so we can get rid of arch-specific sim-main.h. 154255 154256 sim: include stdint.h when needed 154257 Avoid implicit include deps with this to help untangle sim headers 154258 so we can get rid of arch-specific sim-main.h. 154259 154260 sim: include stdarg.h when used 154261 Avoid implicit include deps with this to help untangle sim headers 154262 so we can get rid of arch-specific sim-main.h. 154263 1542642021-12-05 Mike Frysinger <vapier@gentoo.org> 154265 154266 sim: reorder header includes 154267 We're including system headers after local headers in a bunch of 154268 places, but this leads to conflicts when our local headers happen 154269 to define symbols that show up in the system headers. 154270 154271 Use the more standard order of: 154272 * config.h (via defs.h) 154273 * system headers 154274 * local library headers (e.g. bfd & libiberty) 154275 * sim specific headers 154276 1542772021-12-05 Simon Marchi <simon.marchi@polymtl.ca> 154278 154279 gdbsupport: fix memory leak in create_file_handler when re-using file handler 154280 ASan made me notice a memory leak, where the memory tied to the file 154281 handle name string wasn't freed. When register a file handler with an 154282 fd that is already registered, we re-use the file_handler object, so we 154283 ended up creating a new std::string object and overwriting the 154284 file_handler::name pointer, without free-ing the old std::string. 154285 154286 Fix this by allocating file_handler with new, deleting it with 154287 delete, and making file_handler::name not a pointer. 154288 154289 Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43 154290 1542912021-12-05 GDB Administrator <gdbadmin@sourceware.org> 154292 154293 Automatic date update in version.in 154294 1542952021-12-04 Mike Frysinger <vapier@gentoo.org> 154296 154297 sim: moxie: hoist dtb rules up to common builds 154298 These rules don't depend on the target compiler settings, so hoist 154299 the build logic up to the common builds for better parallelization. 154300 154301 sim: m68hc11: delete unused profile flags 154302 These were moved to the common configure script a while ago and have 154303 the same default as these, so just delete it. 154304 154305 sim: msp430: delete redundant comments & settings 154306 These were copied from the example docs, so aren't adding any value. 154307 154308 sim: erc32: drop old configure target 154309 There is no configure script in here anymore to regenerate. 154310 154311 sim: m32c/rl78: drop redundant -Wall settings 154312 We already turn these on in the configure script. 154313 1543142021-12-04 Tom Tromey <tom@tromey.com> 154315 154316 Cache the result of find_file_and_directory 154317 This changes the DWARF reader to cache the result of 154318 find_file_and_directory. This is not especially important now, but it 154319 will help the new DWARF indexer. 154320 154321 Move file_and_directory to new file and C++-ize 154322 This moves file_and_directory to a new file, and then C++-izes it -- 154323 replacing direct assignments with methods, and arranging for it to own 154324 any string that must be computed. Finally, the CU's objfile will only 154325 be used on demand; this is an important property for the new DWARF 154326 indexer's parallel mode. 154327 154328 Remove Irix case from find_file_and_directory 154329 find_file_and_directory has a special case for the Irix 6.2 compiler. 154330 Since this is long obsolete, this patch removes it. 154331 1543322021-12-04 Mike Frysinger <vapier@gentoo.org> 154333 154334 sim: frv: split up testsuite a bit 154335 Running frv's allinsn in serial is quite slow due to the sheer number 154336 of tests it contains. By splitting it up and running in parallel, the 154337 execution time on my system goes from ~100sec to ~60sec. 154338 1543392021-12-04 Simon Marchi <simon.marchi@polymtl.ca> 154340 154341 gdb: don't show deprecated aliases 154342 I don't think it's very useful to show deprecated aliases to the 154343 user. It encourages the user to use them, when the goal is the 154344 opposite. 154345 154346 For example, before: 154347 154348 (gdb) help set index-cache enabled 154349 set index-cache enabled, set index-cache off, set index-cache on 154350 alias set index-cache off = set index-cache enabled off 154351 alias set index-cache on = set index-cache enabled on 154352 Enable the index cache. 154353 When on, enable the use of the index cache. 154354 154355 (gdb) help set index-cache on 154356 Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated. 154357 Use 'set index-cache enabled on'. 154358 154359 set index-cache enabled, set index-cache off, set index-cache on 154360 alias set index-cache off = set index-cache enabled off 154361 alias set index-cache on = set index-cache enabled on 154362 Enable the index cache. 154363 When on, enable the use of the index cache. 154364 154365 After: 154366 154367 (gdb) help set index-cache enabled 154368 Enable the index cache. 154369 When on, enable the use of the index cache. 154370 (gdb) help set index-cache on 154371 Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated. 154372 Use 'set index-cache enabled on'. 154373 154374 Enable the index cache. 154375 When on, enable the use of the index cache. 154376 154377 Change-Id: I989b618a5ad96ba975367e9d16db95523cd57a4c 154378 1543792021-12-04 Simon Marchi <simon.marchi@polymtl.ca> 154380 154381 gdb/testsuite: fix two "maint info line-table"-related tests 154382 Commit 92228a334ba2 ("gdb: small "maintenance info line-table" 154383 readability improvements") change the output format of "maint info 154384 line-table" slightly, adding some empty lines between each 154385 line-table. This causes two tests to start failing, update them to 154386 account for those empty lines. 154387 154388 Change-Id: I9d33a58fce3e860ba0554b25f5582e8066a5c519 154389 1543902021-12-04 Simon Marchi <simon.marchi@efficios.com> 154391 154392 gdb: revert one array_view copy change in ada-lang.c 154393 Commit 4bce7cdaf481 ("gdbsupport: add array_view copy function") caused 154394 an internal error when running gdb.ada/packed_array_assign.exp: 154395 154396 print pra(1) := pr^M 154397 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.^M 154398 154399 I am not sure what's the root cause of this, whether it is a GDB bug 154400 exposed by using the array_view copy function or not. Back out the 154401 change that triggers the internal error for now, while we investigate 154402 it. 154403 154404 Change-Id: I055ab14143e4cfd3ca7ce8f4855c6c3c05db52a7 154405 1544062021-12-04 Mike Frysinger <vapier@gentoo.org> 154407 154408 bfd: unify header generation rules 154409 The logic between these rules are extremely similar, so unify them 154410 into a single variable. 154411 1544122021-12-04 Mike Frysinger <vapier@gentoo.org> 154413 154414 bfd: move header updates up a directory 154415 The rules for rebuilding the bfd headers live in the doc/ subdir 154416 (most likely) because they rely on the chew & related tools. But 154417 we can collapse them into the main Makefile while keeping the tools 154418 in the doc subdir easily enough. This makes the code simpler and 154419 allows for rebuilding them in parallel. 154420 154421 Also add automake silent rule support while we're here. 154422 1544232021-12-04 Mike Frysinger <vapier@gentoo.org> 154424 154425 bfd: convert bfdver.h to silent automake rules 154426 1544272021-12-04 GDB Administrator <gdbadmin@sourceware.org> 154428 154429 Automatic date update in version.in 154430 1544312021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154432 154433 gdb: small "maintenance info line-table" readability improvements 154434 - separate each entry with a newline, to visually separate them 154435 - style filenames with the filename style 154436 - print the name of the compunit_symtab 154437 154438 A header now looks like this, with the compunit_symtab name added (and 154439 the coloring, but you can't really see it here): 154440 154441 objfile: /home/simark/build/babeltrace/src/cli/.libs/babeltrace2 ((struct objfile *) 0x613000005980) 154442 compunit_symtab: babeltrace2-cfg-cli-args.c ((struct compunit_symtab *) 0x62100da1ed10) 154443 symtab: /usr/include/glib-2.0/glib/gdatetime.h ((struct symtab *) 0x62100d9ee530) 154444 linetable: ((struct linetable *) 0x0): 154445 154446 Change-Id: Idc23e10aaa66e2e692adb0a6a74144f72c4fa1c7 154447 1544482021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154449 154450 gdb: change some alias functions parameters to const-reference 154451 Now that we use intrusive list to link aliases, it becomes easier to 154452 pass cmd_list_element arguments by const-reference rather than by 154453 pointer to some functions, change a few. 154454 154455 Change-Id: Id0df648ed26e9447da0671fc2c858981cda31df8 154456 1544572021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154458 154459 gdb: use intrusive_list for cmd_list_element aliases list 154460 Change the manually-implemented linked list to use intrusive_list. This 154461 is not strictly necessary, but it makes the code much simpler. 154462 154463 Change-Id: Idd08090ebf2db8bdcf68e85ef72a9635f1584ccc 154464 1544652021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154466 154467 gdb: trivial changes to use array_view 154468 Change a few relatively obvious spots using value contents to propagate 154469 the use array_view a bit more. 154470 154471 Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15 154472 1544732021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154474 154475 gdb: make extract_integer take an array_view 154476 I think it would make sense for extract_integer, extract_signed_integer 154477 and extract_unsigned_integer to take an array_view. This way, when we 154478 extract an integer, we can validate that we don't overflow the buffer 154479 passed by the caller (e.g. ask to extract a 4-byte integer but pass a 154480 2-byte buffer). 154481 154482 - Change extract_integer to take an array_view 154483 - Add overloads of extract_signed_integer and extract_unsigned_integer 154484 that take array_views. Keep the existing versions so we don't 154485 need to change all callers, but make them call the array_view 154486 versions. 154487 154488 This shortens some places like: 154489 154490 result = extract_unsigned_integer (value_contents (result_val).data (), 154491 TYPE_LENGTH (value_type (result_val)), 154492 byte_order); 154493 154494 into 154495 154496 result = extract_unsigned_integer (value_contents (result_val), byte_order); 154497 154498 value_contents returns an array view that is of length 154499 `TYPE_LENGTH (value_type (result_val))` already, so the length is 154500 implicitly communicated through the array view. 154501 154502 Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95 154503 1545042021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154505 154506 gdbsupport: add array_view copy function 154507 An assertion was recently added to array_view::operator[] to ensure we 154508 don't do out of bounds accesses. However, when the array_view is copied 154509 to or from using memcpy, it bypasses that safety. 154510 154511 To address this, add a `copy` free function that copies data from an 154512 array view to another, ensuring that the destination and source array 154513 views have the same size. When copying to or from parts of an 154514 array_view, we are expected to use gdb::array_view::slice, which does 154515 its own bounds check. With all that, any copy operation that goes out 154516 of bounds should be caught by an assertion at runtime. 154517 154518 copy is implemented using std::copy and std::copy_backward, which, at 154519 least on libstdc++, appears to pick memmove when copying trivial data. 154520 So in the end there shouldn't be much difference vs using a bare memcpy, 154521 as we do right now. When copying non-trivial data, std::copy and 154522 std::copy_backward assigns each element in a loop. 154523 154524 To properly support overlapping ranges, we must use std::copy or 154525 std::copy_backward, depending on whether the destination is before the 154526 source or vice-versa. std::copy and std::copy_backward don't support 154527 copying exactly overlapping ranges (where the source range is equal to 154528 the destination range). But in this case, no copy is needed anyway, so 154529 we do nothing. 154530 154531 The order of parameters of the new copy function is based on std::copy 154532 and std::copy_backward, where the source comes before the destination. 154533 154534 Change a few randomly selected spots to use the new function, to show 154535 how it can be used. 154536 154537 Add a test for the new function, testing both with arrays of a trivial 154538 type (int) and of a non-trivial type (foo). Test non-overlapping 154539 ranges as well as three kinds of overlapping ranges: source before dest, 154540 dest before source, and dest == source. 154541 154542 Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03 154543 1545442021-12-03 Simon Marchi <simon.marchi@efficios.com> 154545 154546 gdb: change store_waitstatus to return a target_waitstatus by value 154547 store_waitstatus is basically a translation function between a status 154548 integer and an equivalent target_waitstatus object. It would make sense 154549 for it to take the integer as a parameter and return the 154550 target_waitstatus by value. Do that, and rename to 154551 host_status_to_waitstatus. Users can then do: 154552 154553 ws = host_status_to_waitstatus (status) 154554 154555 which does the right thing, given the move constructor of 154556 target_waitstatus. 154557 154558 Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b 154559 1545602021-12-03 Simon Marchi <simon.marchi@efficios.com> 154561 154562 gdb: return *this in target_waitstatus setters 154563 While playing with some code creating target_waitstatus objects, I was 154564 mildly annoyed by the fact that we can't just return a new 154565 target_waitstatus object. We have to do: 154566 154567 target_waitstatus ws; 154568 ws.set_exited (123); 154569 return ws; 154570 154571 Make the setters return the "this" object as a reference, such that it's 154572 possible to do: 154573 154574 return target_waitstatus ().set_exited (123); 154575 154576 I initially thought of adding static creation functions, which you would 154577 use like: 154578 154579 return target_waitstatus::make_exited (123); 154580 154581 However, making the setters return a reference to the object achieves 154582 pretty much the same thing, with less new code. 154583 154584 Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147 154585 1545862021-12-03 Simon Marchi <simon.marchi@polymtl.ca> 154587 154588 gdb: make saved_filename an std::string 154589 Make this variable an std::string, avoiding manual memory management. 154590 154591 Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947 154592 1545932021-12-03 Richard Sandiford <richard.sandiford@arm.com> 154594 154595 aarch64: Fix uninitialised memory 154596 AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B 154597 are not paired with an error string, but we had an assert that the 154598 error was nonnull. Previously this assert was testing uninitialised 154599 memory and so could pass or fail arbitrarily. 154600 154601 opcodes/ 154602 * aarch64-opc.c (verify_mops_pme_sequence): Initialize the error 154603 field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and 154604 AARCH64_OPDE_A_SHOULD_FOLLOW_B. 154605 * aarch64-dis.c (print_verifier_notes): Move assert. 154606 1546072021-12-03 Andrew Burgess <andrew.burgess@embecosm.com> 154608 154609 gdb: make value_subscripted_rvalue static 154610 The function value_subscripted_rvalue is only used in valarith.c, so 154611 lets make it a static function. 154612 154613 There should be no user visible change after this commit. 154614 1546152021-12-03 Andrew Burgess <aburgess@redhat.com> 154616 154617 gdb/testsuite: give a test a real name 154618 A test in gdb.python/py-send-packet.exp added in this commit: 154619 154620 commit 24b2de7b776f8f23788d855b1eec290c6e208821 154621 Date: Tue Aug 31 14:04:36 2021 +0100 154622 154623 gdb/python: add gdb.RemoteTargetConnection.send_packet 154624 154625 included a large amount of binary data in the command sent to GDB. As 154626 this test didn't have a real test name the binary data was included in 154627 the gdb.sum file. The contents of the binary data could change 154628 between different runs of GDB, and this makes comparing results 154629 harder. 154630 154631 This commit gives the test a real test name. 154632 1546332021-12-03 Andrew Burgess <aburgess@redhat.com> 154634 154635 gdb/remote: fix use after free bug 154636 This commit: 154637 154638 commit 288712bbaca36bff6578bc839ebcdc3707662f81 154639 Date: Mon Nov 22 15:16:27 2021 +0000 154640 154641 gdb/remote: use scoped_restore to control starting_up flag 154642 154643 introduced a use after free bug. The scoped restore added in the 154644 above commit resets a flag within a remote_target's remote_state 154645 object. 154646 154647 However, in some situations, the remote_target can be unpushed before 154648 the error is thrown. If the only reference to the target is the one 154649 in the target stack, then unpushing the target will cause the 154650 remote_target to be deleted, which, in turn, will delete the 154651 remote_state object. The scoped restore will then try to reset the 154652 flag within a deleted object. 154653 154654 This problem was caught in the gdb.server/server-connect.exp test, 154655 which, when run with the address sanitizer enabled, highlights the 154656 write after free bug described above. 154657 154658 This commit resolves this issue by adding a new class specifically for 154659 the purpose of managing the starting_up flag. As well as setting, and 154660 then clearing the starting_up flag, this new class increments, and 154661 then decrements the reference count on the remote_target object. This 154662 prevents the remote_target from being deleted until after the flag has 154663 been reset. 154664 154665 The gdb.server/server-connect.exp now runs cleanly with the address 154666 sanitizer enabled. 154667 1546682021-12-03 Mike Frysinger <vapier@gentoo.org> 154669 154670 libctf: workaround automake bug with conditional info pages 154671 It looks like automake makes assumptions about its ability to build info 154672 pages based on the GNU standard behavior of shipping info pages with the 154673 distributions. So even though the info pages were conditionalized, and 154674 automake disabled some of the targets, it was still creeping in by way 154675 of unconditional INFO_DEPS settings. 154676 154677 We can workaround this by adding a stub target for the info page when 154678 building info pages are disabled. This tricks automake into disabling 154679 its own extended generation target. I'll follow up with the automake 154680 folks to see what they think. 154681 1546822021-12-03 Chenghua Xu <xuchenghua@loongson.cn> 154683 154684 Add myself and Zhensong Liu as the LoongArch port maintainer. 154685 1546862021-12-03 Alan Modra <amodra@gmail.com> 154687 154688 Revert "Re: Don't compile some opcodes files when bfd is 32-bit only" 154689 This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41. 154690 The bpf sim doesn't work with a 32-bit bfd after all. 154691 1546922021-12-03 GDB Administrator <gdbadmin@sourceware.org> 154693 154694 Automatic date update in version.in 154695 1546962021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 154697 154698 gdb: remove unexpected xstrdup in _initialize_maint_test_settings 154699 That xstrdup is not correct, since we are assigning an std::string. The 154700 result of xstrdup is used to initialize the string, and then lost 154701 forever. Remove it. 154702 154703 Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335 154704 1547052021-12-02 Nick Clifton <nickc@redhat.com> 154706 154707 Fix illegal memory access whilst parsing corrupt DWARF debug information. 154708 PR 28645 154709 * dwarf.c (process_cu_tu_index): Add test for overruning section 154710 whilst processing slots. 154711 1547122021-12-02 Tom de Vries <tdevries@suse.de> 154713 154714 [gdb/tdep] Fix avx512 -m32 support in gdbserver 154715 PR27257 reports a problem that can be reproduced as follows: 154716 - use x86_64 machine with avx512 support 154717 - compile a hello world with -m32 to a.out 154718 - start a gdbserver session with a.out 154719 - use gdb to connect to the gdbserver session 154720 154721 This makes us run into: 154722 ... 154723 Listening on port 2346 154724 Remote debugging from host ::1, port 34940 154725 src/gdbserver/regcache.cc:257: \ 154726 A problem internal to GDBserver has been detected. 154727 Unknown register zmm16h requested 154728 ... 154729 154730 The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a 154731 register zmm16h in the register cache. 154732 154733 To understand how this happens, first some background. 154734 154735 SSE has 16 128-bit wide xmm registers. 154736 154737 AVX extends the SSE registers set as follows: 154738 - it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm 154739 registers. 154740 154741 AVX512 extends the AVX register set as follows: 154742 - it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm 154743 registers. 154744 - it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and 154745 xmm subregisters added as well) 154746 154747 However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers. 154748 154749 The problem we're running into is that gdbserver/i387-fp.cc uses these 154750 constants to describe the size of the register file: 154751 ... 154752 static const int num_avx512_zmmh_low_registers = 16; 154753 static const int num_avx512_zmmh_high_registers = 16; 154754 static const int num_avx512_ymmh_registers = 16; 154755 static const int num_avx512_xmm_registers = 16; 154756 ... 154757 which are all incorrect for the 32-bit case. 154758 154759 Fix this by replacing the constants with variables that have the appropriate 154760 values in 64-bit and 32-bit mode. 154761 154762 Tested on x86_64-linux with native and unix/-m32. 154763 1547642021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 154765 154766 gdb/testsuite: update tests looking for "DWARF 2" debug format 154767 Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's 154768 debugformat field") changes the debug format string in "info source" to 154769 show the actual DWARF version, rather than always show "DWARF 2". 154770 154771 However, it failed to consider that some tests checked for the "DWARF 2" 154772 string to see if the test program is compiled with DWARF debug 154773 information. Since everything is compiled with DWARF 4 or 5 nowadays, 154774 that changed the behavior of those tests. Notably, it prevent the 154775 tests using skip_inline_var_tests to run. 154776 154777 Grep through the testsuite for "DWARF 2" and change all occurrences I 154778 could find to use "DWARF [0-9]" instead (that string is passed to TCL's 154779 string match). 154780 154781 Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885 154782 1547832021-12-02 Joel Brobecker <brobecker@adacore.com> 154784 154785 (PPC64) fix handling of fixed-point values when using "return" command 154786 In the gdb.ada/fixed_points_function.exp testcase, we have the following 154787 Ada code... 154788 154789 type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary 154790 function Call_FP1 (F : FP1_Type) return FP1_Type is 154791 begin 154792 FP1_Arg := F; 154793 return FP1_Arg; 154794 end Call_FP1; 154795 154796 ... used as follow: 154797 154798 F1 : FP1_Type := 1.0; 154799 F1 := Call_FP1 (F1); 154800 154801 The testcase, among other things, verifies that "return" works 154802 properly as follow: 154803 154804 | (gdb) return 1.0 154805 | Make pck.call_fp1 return now? (y or n) y 154806 | [...] 154807 | 9 F1 := Call_FP1 (F1); 154808 | (gdb) next 154809 | (gdb) print f1 154810 | $1 = 0.0625 154811 154812 The output of the last command shows that we returned the wrong 154813 value. The value printed gives a clue about the problem, since 154814 it is 1/16th of the value we expected, where 1/16 is FP1_Type's 154815 scaling factor. 154816 154817 The problem, here, comes from the fact that the function 154818 handling return values for base types (ppc64_sysv_abi_return_value_base) 154819 writes the return value using unpack_long which, upon seeing that 154820 the value being unpacked is a fixed point type, applies the scaling 154821 factor, to get the integer-representation of our fixed-point value 154822 (similar to what it does with floats, for instance). 154823 154824 So, the fix consists in teaching ppc64_sysv_abi_return_value_base 154825 about fixed-point types, and to avoid the unwanted application 154826 of the scaling factor. 154827 154828 Note that the "finish" function, on the other hand, does not 154829 suffer from this issue, simply becaue the value returned by 154830 the function is read from register without the use of a type, 154831 thus avoiding an unwanted application of a scaling factor. 154832 154833 No test added, as this change is already tested by 154834 gdb.ada/fixed_points_function.exp. 154835 154836 Co-Authored-By: Tristan Gingold <gingold@adacore.com> 154837 1548382021-12-02 Joel Brobecker <brobecker@adacore.com> 154839 154840 (RISCV) fix handling of fixed-point type return values 154841 This commit adds support for TYPE_CODE_FIXED_POINT types for 154842 "finish" and "return" commands. 154843 154844 Consider the following Ada code... 154845 154846 type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary 154847 function Call_FP1 (F : FP1_Type) return FP1_Type is 154848 begin 154849 FP1_Arg := F; 154850 return FP1_Arg; 154851 end Call_FP1; 154852 154853 ... used as follow: 154854 154855 F1 : FP1_Type := 1.0; 154856 F1 := Call_FP1 (F1); 154857 154858 "finish" currently behaves as follow: 154859 154860 | (gdb) finish 154861 | [...] 154862 | Value returned is $1 = 0 154863 154864 We expect the returned value to be "1". 154865 154866 Similarly, "return" makes the function return the wrong value: 154867 154868 | (gdb) return 1.0 154869 | Make pck.call_fp1 return now? (y or n) y 154870 | [...] 154871 | 9 F1 := Call_FP1 (F1); 154872 | (gdb) next 154873 | (gdb) print f1 154874 | $1 = 0.0625 154875 154876 (we expect it to print "1" instead). 154877 154878 This problem comes from the handling of integral return values 154879 when the return value is actually fixed point type. Our type 154880 here is actually a range of a fixed point type, but the same 154881 principles should also apply to pure fixed-point types. For 154882 the record, here is what the debugging info looks like: 154883 154884 <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type) 154885 <239> DW_AT_lower_bound : -16 154886 <23a> DW_AT_upper_bound : 16 154887 <23b> DW_AT_name : pck__fp1_type 154888 <23f> DW_AT_type : <0x248> 154889 154890 <1><248>: Abbrev Number: 4 (DW_TAG_base_type) 154891 <249> DW_AT_byte_size : 1 154892 <24a> DW_AT_encoding : 13 (signed_fixed) 154893 <24b> DW_AT_binary_scale: -4 154894 <24c> DW_AT_name : pck__Tfp1_typeB 154895 <250> DW_AT_artificial : 1 154896 154897 ... where the scaling factor is 1/16. 154898 154899 Looking at the "finish" command, what happens is that riscv_arg_location 154900 determines that our return value should be returned by parameter using 154901 an integral convention (via builtin type long). And then, 154902 riscv_return_value uses a cast to that builtin type long to 154903 store the value of into a buffer with the right register size. 154904 This doesn't work in our case, because the underlying value 154905 returned by the function is unscaled, which means it is 16, 154906 and thus the cast is like doing: 154907 154908 arg_val = (FP1_Type) 16 154909 154910 ... In other words, it is trying to create an FP1_Type enty whose 154911 value is 16. Applying the scaling factor, that's 256, and because 154912 the size of FP1_Type is 1 byte, we overflow and thus it ends up 154913 being zero. 154914 154915 The same happen with the "return" function, but the other way around. 154916 154917 The fix consists in handling fixed-point types separately from 154918 integral types. 154919 1549202021-12-02 Joel Brobecker <brobecker@adacore.com> 154921 154922 (ARM/fixed-point) wrong value shown by "finish" command: 154923 Consider the following Ada code: 154924 154925 type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary 154926 FP1_Arg : FP1_Type := 0.0; 154927 154928 function Call_FP1 (F : FP1_Type) return FP1_Type is 154929 begin 154930 FP1_Arg := F; 154931 return FP1_Arg; 154932 end Call_FP1; 154933 154934 After having stopped inside function Call_FP1 as follow: 154935 154936 Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5 154937 5 FP1_Arg := F; 154938 154939 Returning from that function call using "finish" should show 154940 that the function return "1.0" (the same value as was passed 154941 as an argument). However, this is not the case: 154942 154943 (gdb) finish 154944 Run till exit from #0 pck.call_fp1 (f=1) 154945 [...] 154946 9 F1 := Call_FP1 (F1); 154947 Value returned is $1 = 0 154948 154949 This patch enhances the extraction of the return value to know about 154950 fixed point types. 154951 1549522021-12-02 Xavier Roirand <roirand@adacore.com> 154953 154954 (Ada/AArch64) fix fixed point argument passing in inferior funcall 154955 Consider the following code: 154956 154957 type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary 154958 154959 function Call_FP1 (F : FP1_Type) return FP1_Type is 154960 begin 154961 return F; 154962 end Call_FP1; 154963 154964 When the default in GCC is to generate proper DWARF info for fixed point 154965 types, then in gdb, printing the result of a call to call_fp1 with a 154966 decimal parameter leads to: 154967 154968 (gdb) p call_fp1(0.5) 154969 $1 = 0 154970 154971 The displayed value is wrong, and we actually expected: 154972 154973 (gdb) p call_fp1(0.5) 154974 $1 = 0.5 154975 154976 What happened is that our fixed point type parameter got promoted to a 154977 32bit integer because we detected that the length of that object was less 154978 than 4 bytes. The compiler does not perform this promotion and therefore 154979 GDB should not either. 154980 154981 This patch fixes the behavior described above. 154982 1549832021-12-02 Tom Tromey <tromey@adacore.com> 154984 154985 Implement 'task apply' 154986 This adds a 'task apply' command, which is the Ada tasking analogue of 154987 'thread apply'. Unlike 'thread apply', it doesn't offer the 154988 'ascending' flag; but otherwise it's essentially the same. 154989 154990 Add "task" keyword to the "watch" command 154991 Breakpoints in gdb can be made specific to an Ada task using the 154992 "task" qualifier. This patch applies this same idea to watchpoints. 154993 1549942021-12-02 Richard Sandiford <richard.sandiford@arm.com> 154995 154996 aarch64: Update gas/NEWS for recent changes 154997 gas/ 154998 * NEWS: Mention support for Armv8.8-A and for new system registers. 154999 1550002021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155001 155002 aarch64: Add BC instruction 155003 This patch adds support for the Armv8.8-A BC instruction. 155004 [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/BC-cond--Branch-Consistent-conditionally-?lang=en] 155005 155006 include/ 155007 * opcode/aarch64.h (AARCH64_FEATURE_HBC): New macro. 155008 (AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_HBC. 155009 155010 opcodes/ 155011 * aarch64-tbl.h (aarch64_feature_hbc): New variable. 155012 (HBC, HBC_INSN): New macros. 155013 (aarch64_opcode_table): Add BC.C. 155014 * aarch64-dis-2.c: Regenerate. 155015 155016 gas/ 155017 * doc/c-aarch64.texi: Document +hbc. 155018 * config/tc-aarch64.c (aarch64_features): Add "hbc". 155019 * testsuite/gas/aarch64/hbc.s, testsuite/gas/aarch64/hbc.d: New test. 155020 * testsuite/gas/aarch64/hbc-invalid.s, 155021 testsuite/gas/aarch64/hbc-invalid.l, 155022 testsuite/gas/aarch64/hbc-invalid.d: New test. 155023 1550242021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155025 155026 aarch64: Enforce P/M/E order for MOPS instructions 155027 The MOPS instructions should be used as a triple, such as: 155028 155029 cpyfp [x0]!, [x1]!, x2! 155030 cpyfm [x0]!, [x1]!, x2! 155031 cpyfe [x0]!, [x1]!, x2! 155032 155033 The registers should also be the same for each writeback operand. 155034 This patch adds a warning for code that doesn't follow this rule, 155035 along similar lines to the warning that we already emit for 155036 invalid uses of MOVPRFX. 155037 155038 include/ 155039 * opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E) 155040 (C_SCAN_MOPS_PME): New macros. 155041 (AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind. 155042 (AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise. 155043 (aarch64_operand_error): Make each data value a union between 155044 an int and a string. 155045 155046 opcodes/ 155047 * aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags. 155048 (MOPS_SET_OP1_OP2_INSN): Likewise. 155049 * aarch64-opc.c (set_out_of_range_error): Update after change to 155050 aarch64_operand_error. 155051 (set_unaligned_error, set_reg_list_error): Likewise. 155052 (init_insn_sequence): Use a 3-instruction sequence for 155053 MOPS P instructions. 155054 (verify_mops_pme_sequence): New function. 155055 (verify_constraints): Call it. 155056 * aarch64-dis.c (print_verifier_notes): Handle 155057 AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B. 155058 155059 gas/ 155060 * config/tc-aarch64.c (operand_mismatch_kind_names): Add entries 155061 for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B. 155062 (operand_error_higher_severity_p): Check that 155063 AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B 155064 come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR; 155065 their relative order is not significant. 155066 (record_operand_error_with_data): Update after change to 155067 aarch64_operand_error. 155068 (output_operand_error_record): Likewise. Handle 155069 AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B. 155070 * testsuite/gas/aarch64/mops_invalid_2.s, 155071 testsuite/gas/aarch64/mops_invalid_2.d, 155072 testsuite/gas/aarch64/mops_invalid_2.l: New test. 155073 1550742021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155075 155076 aarch64: Add support for +mops 155077 This patch adds support for FEAT_MOPS, an Armv8.8-A extension 155078 that provides memcpy and memset acceleration instructions. 155079 155080 I took the perhaps controversial decision to generate the individual 155081 instruction forms using macros rather than list them out individually. 155082 This becomes useful with a follow-on patch to check that code follows 155083 the correct P/M/E sequence. 155084 [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en] 155085 155086 include/ 155087 * opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro. 155088 (AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS. 155089 (AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd. 155090 (AARCH64_OPND_MOPS_ADDR_Rs): Likewise. 155091 (AARCH64_OPND_MOPS_WB_Rn): Likewise. 155092 155093 opcodes/ 155094 * aarch64-asm.h (ins_x0_to_x30): New inserter. 155095 * aarch64-asm.c (aarch64_ins_x0_to_x30): New function. 155096 * aarch64-dis.h (ext_x0_to_x30): New extractor. 155097 * aarch64-dis.c (aarch64_ext_x0_to_x30): New function. 155098 * aarch64-tbl.h (aarch64_feature_mops): New feature set. 155099 (aarch64_feature_mops_memtag): Likewise. 155100 (MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN) 155101 (MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN) 155102 (MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN) 155103 (MOPS_SET_INSN): New macros. 155104 (aarch64_opcode_table): Add MOPS instructions. 155105 (aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd, 155106 AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn. 155107 * aarch64-opc.c (aarch64_print_operand): Handle 155108 AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and 155109 AARCH64_OPND_MOPS_WB_Rn. 155110 (verify_three_different_regs): New function. 155111 * aarch64-asm-2.c: Regenerate. 155112 * aarch64-dis-2.c: Likewise. 155113 * aarch64-opc-2.c: Likewise. 155114 155115 gas/ 155116 * doc/c-aarch64.texi: Document +mops. 155117 * config/tc-aarch64.c (parse_x0_to_x30): New function. 155118 (parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd, 155119 AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn. 155120 (aarch64_features): Add "mops". 155121 * testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test. 155122 * testsuite/gas/aarch64/mops_invalid.s, 155123 * testsuite/gas/aarch64/mops_invalid.d, 155124 * testsuite/gas/aarch64/mops_invalid.l: Likewise. 155125 1551262021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155127 155128 aarch64: Add Armv8.8-A system registers 155129 Armv8.8-A defines two new system registers: allint and icc_nmiar1_el1. 155130 Both of them were previously unmapped. allint supports a 0/1 immediate. 155131 [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ALLINT--All-Interrupt-Mask-Bit?lang=en] 155132 [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ICC-NMIAR1-EL1--Interrupt-Controller-Non-maskable-Interrupt-Acknowledge-Register-1?lang=en] 155133 155134 opcodes/ 155135 * aarch64-opc.c (SR_V8_8): New macro. 155136 (aarch64_sys_regs): Add allint and icc_nmiar1_el1. 155137 (aarch64_pstatefields): Add allint. 155138 155139 gas/ 155140 * testsuite/gas/aarch64/armv8_8-a-sysregs.s, 155141 * testsuite/gas/aarch64/armv8_8-a-sysregs.d: New test. 155142 * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.s, 155143 * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.l, 155144 * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.d: New test. 155145 1551462021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155147 155148 aarch64: Add id_aa64isar2_el1 155149 Armv8.8-A defines a read-only system register called id_aa64isar2_el1. 155150 The register was previously RES0 and should therefore be accepted 155151 at all architecture levels. 155152 [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en] 155153 155154 opcodes/ 155155 * aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1. 155156 155157 gas/ 155158 * testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to 155159 id_aa64isar2_el1. 155160 * testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly. 155161 * testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise. 155162 * testsuite/gas/aarch64/sysreg.s: Test reads from 155163 id_aa64isar2_el1. 155164 * testsuite/gas/aarch64/sysreg.d: Update accordingly. 155165 1551662021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155167 155168 aarch64: Add support for Armv8.8-A 155169 This patch adds skeleton support for -march=armv8.8-a, testing only 155170 that it correctly inherits from armv8.7-a. 155171 155172 include/ 155173 * opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro. 155174 (AARCH64_ARCH_V8_8): Likewise. 155175 155176 gas/ 155177 * doc/c-aarch64.texi: Document armv8.8-a. 155178 * config/tc-aarch64.c (aarch64_archs): Add armv8-8-a 155179 * testsuite/gas/aarch64/v8-8-a.s, 155180 * testsuite/gas/aarch64/v8-8-a.d: New test. 155181 1551822021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155183 155184 aarch64: Provide line info for unclosed sequences 155185 We warn about MOVPRFX instructions that have no following 155186 instruction. This patch adds a line number to the message, 155187 which is useful if the assembly code has multiple text sections. 155188 155189 The new code is unconditional since OBJ_ELF is always defined 155190 for aarch64. 155191 155192 gas/ 155193 * config/tc-aarch64.h (aarch64_segment_info_type): Add last_file 155194 and last_line. 155195 * config/tc-aarch64.c (now_instr_sequence): Delete. 155196 (force_automatic_sequence_close): Provide a line number when 155197 reporting unclosed sequences. 155198 (md_assemble): Record the location of the instruction in 155199 tc_segment_info. 155200 * testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error 155201 message. 155202 * testsuite/gas/aarch64/sve-movprfx_7.l: Likewise. 155203 * testsuite/gas/aarch64/sve-movprfx_8.l: Likewise. 155204 1552052021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155206 155207 aarch64: Tweak insn sequence code 155208 libopcodes has some code to check constraints across sequences 155209 of consecutive instructions. It was added to support MOVPRFX 155210 sequences but is going to be useful for the Armv8.8-A MOPS 155211 feature as well. 155212 155213 Currently the structure has one field to record the instruction 155214 that started a sequence and another to record the remaining 155215 instructions in the sequence. It's more convenient for the 155216 MOPS code if we put the instructions into a single array instead. 155217 155218 No functional change intended. 155219 155220 include/ 155221 * opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns 155222 and current_insns with num_added_insns and num_allocated_insns. 155223 155224 opcodes/ 155225 * aarch64-opc.c (add_insn_to_sequence): New function. 155226 (init_insn_sequence): Update for new aarch64_instr_sequence layout. 155227 Add the first instruction to the inst array. 155228 (verify_constraints): Update for new aarch64_instr_sequence layout. 155229 Don't add the last instruction to the array. 155230 1552312021-12-02 Richard Sandiford <richard.sandiford@arm.com> 155232 155233 aarch64: Add maximum immediate value to aarch64_sys_reg 155234 The immediate form of MSR has a 4-bit immediate field (in CRm). 155235 However, many forms of MSR require a smaller immediate. These cases 155236 are identified by value in operand_general_constraint_met_p, 155237 but they're now the common case rather than the exception. 155238 155239 This patch therefore adds the maximum value to the sys_reg 155240 description and gets the range from there. It also enforces 155241 the minimum of 0, which avoids a situation in which: 155242 155243 msr dit, #2 155244 155245 would give the expected: 155246 155247 Error: immediate value out of range 0 to 1 155248 155249 whereas: 155250 155251 msr dit, #-1 155252 155253 would give: 155254 155255 Error: immediate value out of range 0 to 15 155256 155257 (from the later UIMM4 checking). 155258 155259 Also: 155260 155261 - we were reporting the first error above against the wrong operand 155262 - TCO takes a single-bit immediate, but we previously allowed 155263 all 16 values. 155264 [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en] 155265 155266 opcodes/ 155267 * aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros. 155268 * aarch64-opc.c (operand_general_constraint_met_p): Read the 155269 maximum MSR immediate value from aarch64_pstatefields. 155270 (aarch64_pstatefields): Add the maximum immediate value 155271 for each register. 155272 155273 gas/ 155274 * testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1 155275 rather than 8 for the TCO test. 155276 * testsuite/gas/aarch64/sysreg-4.d: Update accordingly. 155277 * testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number 155278 in MSR immediate error messages. 155279 * testsuite/gas/aarch64/diagnostic.l: Likewise. 155280 * testsuite/gas/aarch64/pan-illegal.l: Likewise. 155281 * testsuite/gas/aarch64/ssbs-illegal1.l: Likewise. 155282 * testsuite/gas/aarch64/illegal-sysreg-4b.s, 155283 * testsuite/gas/aarch64/illegal-sysreg-4b.d, 155284 * testsuite/gas/aarch64/illegal-sysreg-4b.l: New test. 155285 1552862021-12-02 Marcus Nilsson <brainbomb@gmail.com> 155287 155288 Allow the --visualize-jumps feature to work with the AVR disassembler. 155289 * avr-dis.c (avr_operand); Pass in disassemble_info and fill 155290 in insn_type on branching instructions. 155291 1552922021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 155293 155294 gdb, include: replace pragmas with DIAGNOSTIC macros, fix build with g++ 4.8 155295 When introducing this code, I forgot that we had some macros for this. 155296 Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros, 155297 provided by include/diagnostics.h. 155298 155299 In diagnostics.h: 155300 155301 - Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level. 155302 - Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for 155303 both gcc and clang. 155304 155305 Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and 155306 DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these 155307 errors: 155308 155309 CXX ada-tasks.o 155310 /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks(): 155311 /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch] 155312 switch (data->known_tasks_kind) 155313 ^ 155314 155315 Because of the POP, the diagnostic should go back to being disabled, 155316 since it was disabled in the beginning, but that's not what we see 155317 here. Versions of GCC >= 5 compile correctly. 155318 155319 Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5. 155320 155321 Note that this code (already as it exists in master today) enables 155322 -Wswitch at the error level even if --disable-werror is passed. It 155323 shouldn't be a problem, as it's not like a new enumerator will appear 155324 out of nowhere and cause a build error if building with future 155325 compilers. Still, for correctness, we would ideally want to ask the 155326 compiler to enable -Wswitch at its default level (as if the user had 155327 passed -Wswitch on the command-line). There doesn't seem to be a way to 155328 do this. 155329 155330 Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d 155331 1553322021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 155333 155334 gas: re-generate configure 155335 When configuring gas, I get: 155336 155337 config.status: error: cannot find input file: `doc/Makefile.in' 155338 155339 This is because configure is out-of-date, re-generate it. 155340 155341 Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498 155342 1553432021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 155344 155345 libctf: re-generate configure 155346 When configuring libctf, I get: 155347 155348 config.status: error: cannot find input file: `doc/Makefile.in' 155349 155350 This is because configure is out-of-date, re-generate it. 155351 155352 Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169 155353 1553542021-12-02 H.J. Lu <hjl.tools@gmail.com> 155355 155356 x86: Skip __[start|stop]_SECNAME for --gc-sections -z start-stop-gc 155357 Don't convert memory load to immediate load on __start_SECNAME and 155358 __stop_SECNAME for --gc-sections -z start-stop-gc if all SECNAME 155359 sections been garbage collected. 155360 155361 bfd/ 155362 155363 PR ld/27491 155364 * elf32-i386.c (elf_i386_convert_load_reloc): Skip __start_SECNAME 155365 and __stop_SECNAME for --gc-sections -z start-stop-gc if the input 155366 section been garbage collected. 155367 * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise. 155368 * elfxx-x86.h (elf_x86_start_stop_gc_p): New function. 155369 155370 ld/ 155371 PR ld/27491 155372 * testsuite/ld-i386/i386.exp: Run PR ld/27491 tests. 155373 * testsuite/ld-x86-64/x86-64.exp: Likewise. 155374 * testsuite/ld-i386/pr27491-1.s: New file. 155375 * testsuite/ld-i386/pr27491-1a.d: Likewise. 155376 * testsuite/ld-i386/pr27491-1b.d: Likewise. 155377 * testsuite/ld-i386/pr27491-1c.d: Likewise. 155378 * testsuite/ld-i386/pr27491-2.d: Likewise. 155379 * testsuite/ld-i386/pr27491-2.s: Likewise. 155380 * testsuite/ld-i386/pr27491-3.d: Likewise. 155381 * testsuite/ld-i386/pr27491-3.s: Likewise. 155382 * testsuite/ld-i386/pr27491-4.d: Likewise. 155383 * testsuite/ld-i386/pr27491-4a.s: Likewise. 155384 * testsuite/ld-i386/pr27491-4b.s: Likewise. 155385 * testsuite/ld-x86-64/pr27491-1.s: Likewise. 155386 * testsuite/ld-x86-64/pr27491-1a.d: Likewise. 155387 * testsuite/ld-x86-64/pr27491-1b.d: Likewise. 155388 * testsuite/ld-x86-64/pr27491-1c.d: Likewise. 155389 * testsuite/ld-x86-64/pr27491-2.d: Likewise. 155390 * testsuite/ld-x86-64/pr27491-2.s: Likewise. 155391 * testsuite/ld-x86-64/pr27491-3.d: Likewise. 155392 * testsuite/ld-x86-64/pr27491-3.s: Likewise. 155393 * testsuite/ld-x86-64/pr27491-4.d: Likewise. 155394 * testsuite/ld-x86-64/pr27491-4a.s: Likewise. 155395 * testsuite/ld-x86-64/pr27491-4b.s: Likewise. 155396 1553972021-12-02 Mike Frysinger <vapier@gentoo.org> 155398 155399 bfd: delete unused proto settings 155400 These have been around for decades but don't appear to be used, and 155401 trying to build them (e.g. `make archive.p archive.ip`) doesn't work, 155402 so just delete it all. 155403 155404 gas: merge doc subdir up a level 155405 This avoids a recursive make into the doc subdir and speeds up the 155406 build slightly. It also allows for more parallelism. 155407 155408 libctf: merge doc subdir up a level 155409 This avoids a recursive make into the doc subdir and speeds up the 155410 build slightly. It also allows for more parallelism. 155411 1554122021-12-02 Simon Marchi <simon.marchi@polymtl.ca> 155413 155414 gdb: use actual DWARF version in compunit's debugformat field 155415 The "info source" command, with a DWARF-compile program, always show 155416 that the debug info is "DWARF 2": 155417 155418 (gdb) info source 155419 Current source file is test.c 155420 Compilation directory is /home/smarchi/build/binutils-gdb/gdb 155421 Located in /home/smarchi/build/binutils-gdb/gdb/test.c 155422 Contains 2 lines. 155423 Source language is c. 155424 Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection. 155425 Compiled with DWARF 2 debugging format. 155426 Includes preprocessor macro info. 155427 155428 Change it to display the actual DWARF version: 155429 155430 (gdb) info source 155431 Current source file is test.c 155432 Compilation directory is /home/smarchi/build/binutils-gdb/gdb 155433 Located in /home/smarchi/build/binutils-gdb/gdb/test.c 155434 Contains 2 lines. 155435 Source language is c. 155436 Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection. 155437 Compiled with DWARF 5 debugging format. 155438 Includes preprocessor macro info. 155439 155440 The comp_unit_head::version field is guaranteed to be between 2 and 5, 155441 thanks to the check in read_comp_unit_head. So we can still use static 155442 strings to pass to record_debugformat, and keep it efficient. 155443 155444 In the future, when somebody will update GDB to support DWARF 6, they'll 155445 hit this assert and have to update this code. 155446 155447 Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172 155448 1554492021-12-02 H.J. Lu <hjl.tools@gmail.com> 155450 155451 elf: Discard input .note.gnu.build-id sections 155452 1. Discard input .note.gnu.build-id sections. 155453 2. Clear the build ID field before writing. 155454 3. Use bfd_make_section_anyway_with_flags to create the output 155455 .note.gnu.build-id section. 155456 155457 PR ld/28639 155458 * ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id 155459 sections, excluding the first one. 155460 (write_build_id): Clear the build ID field before writing. 155461 (ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags 155462 to create the output .note.gnu.build-id section. 155463 * testsuite/ld-elf/build-id.exp: New file. 155464 * testsuite/ld-elf/pr28639a.rd: Likewise. 155465 * testsuite/ld-elf/pr28639b.rd: Likewise. 155466 * testsuite/ld-elf/pr28639c.rd: Likewise. 155467 * testsuite/ld-elf/pr28639d.rd: Likewise. 155468 1554692021-12-02 GDB Administrator <gdbadmin@sourceware.org> 155470 155471 Automatic date update in version.in 155472 1554732021-12-01 Mike Frysinger <vapier@gentoo.org> 155474 155475 binutils: add missing prefix for binutils/index.html rule 155476 1554772021-12-01 Luca Boccassi <luca.boccassi@gmail.com> 155478 155479 readelf: recognize FDO Packaging Metadata ELF note. (Correcting snafu during patch application) 155480 1554812021-12-01 Luca Boccassi <luca.boccassi@gmail.com> 155482 155483 readelf: recognize FDO Packaging Metadata ELF note 155484 As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/ 155485 this note will be used starting from Fedora 36. Allow 155486 readelf --notes to pretty print it: 155487 155488 Displaying notes found in: .note.package 155489 Owner Data size Description 155490 FDO 0x00000039 FDO_PACKAGING_METADATA 155491 Packaging Metadata: {"type":"deb","name":"fsverity-utils","version":"1.3-1"} 155492 1554932021-12-01 Tom de Vries <tdevries@suse.de> 155494 155495 [gdb/testsuite] Fix typo in gdb.multi/multi-arch-exec.exp 155496 With gdb.multi/multi-arch-exec.exp I run into: 155497 ... 155498 Running src/gdb/testsuite/gdb.multi/multi-arch-exec.exp ... 155499 ERROR: tcl error sourcing src/gdb/testsuite/gdb.multi/multi-arch-exec.exp. 155500 ERROR: wrong # args: extra words after "else" clause in "if" command 155501 while executing 155502 "if [istarget "powerpc64*-*-*"] { 155503 set march "-m64" 155504 } else if [istarget "s390*-*-*"] { 155505 set march "-m31" 155506 } else { 155507 set march "-m32" 155508 }" 155509 ... 155510 155511 Fix the else if -> elseif typo. 155512 155513 Tested on x86_64-linux. 155514 1555152021-12-01 Tom de Vries <tdevries@suse.de> 155516 155517 [gdb/testsuite] Fix gdb.arch/i386-pkru.exp on linux 155518 When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory 155519 Protection Keys for Userspace" support, we run into: 155520 ... 155521 (gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support 155522 print $pkru^M 155523 $2 = 1431655764^M 155524 (gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register 155525 ... 155526 155527 The test-case expects the $pkru register to have the default value 0, matching 155528 the "init state" of 0 defined by the XSAVE hardware. 155529 155530 Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys: 155531 Default to a restrictive init PKRU"), the register is set to 0x55555554 by 155532 default (which matches the printed decimal value above). 155533 155534 Fix the FAIL by accepting this value for linux. 155535 155536 Tested on x86_64-linux. 155537 1555382021-12-01 Nick Clifton <nickc@redhat.com> 155539 155540 Fix the fields in the x_n union inside the the x_file structure so that pointers can be stored. 155541 PR 28630 155542 * coff/internal.h (x_n): Use bfd_hostptr_t for the fields in this 155543 structure. 155544 1555452021-12-01 Andrew Burgess <aburgess@redhat.com> 155546 155547 gdb/remote: use scoped_restore to control starting_up flag 155548 This commit makes use of a scoped_restore object to control the 155549 remote_state::starting_up flag within the remote_target::start_remote 155550 method. 155551 155552 Ideally I would have liked to create the scoped_restore inside 155553 start_remote and just leave the restore in place until the end of the 155554 scope, however, I'm worried that doing this would change the behaviour 155555 of GDB. Specifically, in start_remote, the following code is executed 155556 once the starting_up flag has been restored to its previous value: 155557 155558 if (breakpoints_should_be_inserted_now ()) 155559 insert_breakpoints (); 155560 155561 I think (but am not 100% sure) that calling install_breakpoints could 155562 end up back inside remote_target::can_download_tracepoint, which does 155563 check the value of remote_state::starting_up. And so, I'm concerned 155564 that leaving the scoped_restore in place until the end of start_remote 155565 will cause a possible change in behaviour. 155566 155567 To avoid this, and to leave things as close to the current behaviour 155568 as possible, I've split remote_target::start_remote into two, there's 155569 the main function body which moves into remote_target::start_remote_1, 155570 this function uses the scoped_restore to change the ::starting_up 155571 flag, then there's the old remote_target::start_remote, which now just 155572 calls ::start_remote_1, and then does the insert_breakpoints call. 155573 155574 There should be no user visible changes after this commit, unless 155575 there's a situation where the ::starting_up flag could previously have 155576 been left set, if this was the case, then this situation should no 155577 longer be possible. 155578 1555792021-12-01 Simon Marchi <simon.marchi@polymtl.ca> 155580 155581 gdb.base/corefile-buildid.exp: fix DUPLICATEs when failing to generate a core file 155582 When my system isn't properly configured to generate core files in the 155583 local directory, I see these DUPLICATEs: 155584 155585 DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file 155586 155587 Fix that by having a single with_test_prefix around that message and 155588 what follows. 155589 155590 Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba 155591 1555922021-12-01 Mike Frysinger <vapier@gentoo.org> 155593 155594 gold: enable silent build rules 155595 1555962021-12-01 GDB Administrator <gdbadmin@sourceware.org> 155597 155598 Automatic date update in version.in 155599 1556002021-11-30 Carl Love <cel@us.ibm.com> 155601 155602 gdb: Powerpc fix gdb.multi/multi-arch-exec.exp test 155603 The expect file has a procedure append_arch_options which sets march based 155604 the istarget. The current if / else statement does not check for 155605 powerpc64. The else statement is hit which sets march to -m32. This 155606 results in compilation errors on 64-bit PowerPC. 155607 155608 This patch adds an if statement to check for powerpc64 and if true sets mach 155609 to -m64. 155610 155611 The patch was tested on a Power 10 system. No compile errors were generated. 155612 The test completes with 1 expected pass and no failures. 155613 1556142021-11-30 Mike Frysinger <vapier@gentoo.org> 155615 155616 binutils: regenerate Makefile.in after doc/ changes 155617 1556182021-11-30 Roland McGrath <mcgrathr@google.com> 155619 155620 Fix missing build dependency for binutils man pages 155621 binutils/ 155622 * doc/local.mk: Give each man page target its missing dependency on 155623 doc/$(am__dirstamp). 155624 1556252021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155626 155627 aarch64: Add missing system registers [PR27145] 155628 This patch adds support for various system registers, up to Armv8.7-A. 155629 This includes all the registers that were mentioned in the PR and that 155630 hadn't become supported since. 155631 155632 opcodes/ 155633 PR aarch64/27145 155634 * aarch64-opc.c (SR_V8_4): Remove duplicate definition. 155635 (SR_V8_6, SR_V8_7, SR_GIC, SR_AMU): New macros. 155636 (aarch64_sys_regs): Add missing entries (up to Armv8.7-A). 155637 155638 gas/ 155639 PR aarch64/27145 155640 * testsuite/gas/aarch64/sysreg-8.s, 155641 * testsuite/gas/aarch64/sysreg-8.d, 155642 * testsuite/gas/aarch64/illegal-sysreg-8.s, 155643 * testsuite/gas/aarch64/illegal-sysreg-8.d, 155644 * testsuite/gas/aarch64/illegal-sysreg-8.l, 155645 * testsuite/gas/aarch64/illegal-sysreg-8b.s, 155646 * testsuite/gas/aarch64/illegal-sysreg-8b.d, 155647 * testsuite/gas/aarch64/illegal-sysreg-8b.l: New tests. 155648 * testsuite/gas/aarch64/sysreg.s: Change system register numbers 155649 to ones that are still unallocated. 155650 * testsuite/gas/aarch64/sysreg.d: Update accordingly. 155651 1556522021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155653 155654 aarch64: Make LOR registers conditional on +lor 155655 We have a +lor feature flag for the Limited Ordering Regions 155656 extension, but the associated registers didn't use it. 155657 155658 opcodes/ 155659 * aarch64-opc.c (SR_LOR): New macro. 155660 (aarch64_sys_regs): Use it for lorc_el1, lorea_el1, lorn_el1 and 155661 lorsa_el1. 155662 155663 gas/ 155664 * testsuite/gas/aarch64/sysreg-7.s: Enable +lor. 155665 * testsuite/gas/aarch64/illegal-sysreg-7.s: Test for LOR registers 155666 without +lor. 155667 * testsuite/gas/aarch64/illegal-sysreg-7.d: Update accordingly. 155668 * testsuite/gas/aarch64/illegal-sysreg-7.l: Likewise. 155669 1556702021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155671 155672 aarch64: Remove ZIDR_EL1 155673 ZIDR_EL1 was part of an early version of SVE, but didn't make 155674 it to the final release. 155675 155676 opcodes/ 155677 * aarch64-opc.c (aarch64_sys_regs): Remove zidr_el1 entry. 155678 155679 gas/ 155680 * testsuite/gas/aarch64/sve-sysreg.s: Remove zidr_el1. 155681 * testsuite/gas/aarch64/sve-sysreg.d: Update accordingly. 155682 * testsuite/gas/aarch64/sve-sysreg-invalid.l: Likewise. 155683 1556842021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155685 155686 aarch64: Allow writes to MFAR_EL3 155687 MFAR_EL3 is a read/write register, but was incorrectly marked as 155688 read-only 155689 [https://developer.arm.com/documentation/ddi0601/2021-09/AArch64-Registers/MFAR-EL3--PA-Fault-Address-Register?lang=en] 155690 155691 opcodes/ 155692 * aarch64-opc.c (aarch64_sys_regs): Mark mfar_el3 as read-write. 155693 155694 gas/ 155695 * testsuite/gas/aarch64/rme.s: Test writing to mfar_el3. 155696 * testsuite/gas/aarch64/rme.d: Update accordingly. 155697 * testsuite/gas/aarch64/rme-invalid.s: Delete. 155698 * testsuite/gas/aarch64/rme-invalid.l: Likewise. 155699 * testsuite/gas/aarch64/rme-invalid.d: Likewise. 155700 1557012021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155702 155703 aarch64: Mark PMSIDR_EL1 as read-only 155704 We were incorrectly allowing writes to PMSIDR_EL1, which is 155705 a read-only register. 155706 [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/PMSIDR-EL1--Sampling-Profiling-ID-Register?lang=en] 155707 155708 opcodes/ 155709 * aarch64-opc.c (aarch64_sys_regs): Make pmsidr_el1 as F_REG_READ. 155710 155711 gas/ 155712 * testsuite/gas/aarch64/msr.s: Remove write to pmsidr_el1. 155713 * testsuite/gas/aarch64/msr.d: Update accordingly. 155714 * testsuite/gas/aarch64/illegal-sysreg-2.s, 155715 * testsuite/gas/aarch64/illegal-sysreg-2.d, 155716 * testsuite/gas/aarch64/illegal-sysreg-2.l: New test. 155717 1557182021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155719 155720 aarch64: Remove duplicate system register entries 155721 There is a lot of overlap between the ETM and ETE system registers, 155722 so some registers were listed twice. 155723 155724 Already tested by etm.[sd] and ete.[sd]. 155725 155726 opcodes/ 155727 * aarch64-opc.c (aarch64_sys_regs): Combine ETE and ETM blocks 155728 and remove redundant entries. 155729 155730 gas/ 155731 * testsuite/gas/aarch64/etm.s: Remove duplicated test. 155732 * testsuite/gas/aarch64/etm.d: Update accordingly. 155733 1557342021-11-30 Richard Sandiford <richard.sandiford@arm.com> 155735 155736 aarch64: Check for register aliases before mnemonics 155737 Previously we would not accept: 155738 155739 A .req B 155740 155741 if A happened to be the name of an instruction. Adding new 155742 instructions could therefore invalidate existing register aliases. 155743 155744 I noticed this with a test that used "zero" as a register alias 155745 for "xzr", where "zero" is now also the name of an SME instruction. 155746 I don't have any evidence that "real" code is doing this, but it 155747 seems at least plausible. 155748 155749 This patch switches things so that we check for register aliases 155750 first. It might slow down parsing slightly, but the difference 155751 is unlikely to be noticeable. 155752 155753 Things like: 155754 155755 b .req + 0 155756 155757 still work, since create_register_alias checks for " .req ", 155758 and with the input scrubber, we'll only keep whitespace after 155759 .req if it's followed by another name. If there's some valid 155760 expression that I haven't thought about that is scrubbed to 155761 " .req ", users could avoid the ambiguity by wrapping .req 155762 in parentheses. 155763 155764 The new test for invalid aliases already passed. I just wanted 155765 something to exercise the !dot condition. 155766 155767 I can't find a way of exercising the (existing) p == base condition, 155768 but I'm not brave enough to say that it can never happen. If it does 155769 happen, get_mnemonic_name would return an empty string. 155770 155771 gas/ 155772 * config/tc-aarch64.c (opcode_lookup): Move mnemonic extraction 155773 code to... 155774 (md_assemble): ...here. Check for register aliases first. 155775 * testsuite/gas/aarch64/register_aliases.d, 155776 testsuite/gas/aarch64/register_aliases.s: Test for a register 155777 alias called "zero". 155778 * testsuite/gas/aarch64/register_aliases_invalid.d, 155779 testsuite/gas/aarch64/register_aliases_invalid.l, 155780 testsuite/gas/aarch64/register_aliases_invalid.s: New test. 155781 1557822021-11-30 Andrew Burgess <aburgess@redhat.com> 155783 155784 gdb/python: don't use the 'p' format for parsing args 155785 When running the gdb.python/py-arch.exp tests on a GDB built 155786 against Python 2 I ran into some errors. The problem is that this 155787 test script exercises the gdb.Architecture.integer_type method, and 155788 this method uses 'p' as an argument format specifier in a call to 155789 gdb_PyArg_ParseTupleAndKeywords. 155790 155791 Unfortunately this specified was only added in Python 3.3, so will 155792 cause an error for earlier versions of Python. 155793 155794 This commit switches to use the 'O' specifier to collect a PyObject, 155795 and then uses PyObject_IsTrue to convert the object to a boolean. 155796 155797 An earlier version of this patch incorrectly switched from using 'p' 155798 to use 'i', however, it was pointed out during review that this would 155799 cause some changes in behaviour, for example both of these will work 155800 with 'p', but not with 'i': 155801 155802 gdb.selected_inferior().architecture().integer_type(32, None) 155803 gdb.selected_inferior().architecture().integer_type(32, "foo") 155804 155805 The new approach of using 'O' works fine with these cases. I've added 155806 some new tests to cover both of the above. 155807 155808 There should be no user visible changes after this commit. 155809 1558102021-11-30 Tom de Vries <tdevries@sdflex.arch.suse.de> 155811 155812 [gdb/testsuite] Fix gdb.base/style.exp with stub-termcap 155813 When running test-case gdb.base/style.exp with a gdb build using 155814 stub-termcap.c, we run into: 155815 ... 155816 (gdb) PASS: gdb.base/style.exp: all styles enabled: frame when width=20 155817 ^M<et width 30^M 155818 (gdb) FAIL: gdb.base/style.exp: all styles enabled: set width 30 155819 ... 155820 155821 The problem is that we're trying to issue the command "set width 30" while 155822 width is set to 20, which causes horizontal scrolling. 155823 155824 Fix this by resetting the width to 0 before issuing the "set width 30" 155825 command. 155826 155827 Tested on x86_64-linux. 155828 155829 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24582 155830 1558312021-11-30 Nick Clifton <nickc@redhat.com> 155832 155833 Use dwarf_vma type for offsets, ranges and section sizes in DWARF decoder. 155834 * dwarf.c (find_debug_info_for_offset): Use dwarf_vma type for 155835 offsets, sizes and ranges. 155836 (display_loc_list): Likewise. Also use print_dwarf_vma to print 155837 the offset. 155838 (display_loclists_list): Likewise. 155839 (display_loc_list_dwo): Likewise. 155840 (display_debug_str): Likewise. 155841 (display_debug_aranges): Likewise. 155842 (display_debug_ranges_list): Likewise. 155843 (display_debug_rnglists_list): Likewise. 155844 (display_debug_ranges): Likewise. 155845 155846 ld: pru: Add pru_irq_map output section 155847 * scripttempl/pru.sc (.pru_irq_map): Define output section. 155848 * testsuite/ld-pru/pru_irq_map-1.d: New test. 155849 * testsuite/ld-pru/pru_irq_map-2.d: New test. 155850 * testsuite/ld-pru/pru_irq_map.s: New test. 155851 1558522021-11-30 Andrew Burgess <aburgess@redhat.com> 155853 155854 gdb/testsuite: check the python module is available before using it 155855 The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc 155856 module. When running the Python tests with a GDB built against Python 155857 2 I ran into a test failure due to the tracemalloc module not being 155858 available. 155859 155860 This commit adds a new helper function to lib/gdb-python.exp that 155861 checks if a named module is available. Using this we can then skip 155862 the py-inferior-leak.exp test when the tracemalloc module is not 155863 available. 155864 1558652021-11-30 Andrew Burgess <aburgess@redhat.com> 155866 155867 gdb: fix disassembler regressions for 32-bit arm 155868 After this commit: 155869 155870 commit 76b43c9b5c2b275cbf4f927bfc25984410cb5dd5 155871 Date: Tue Oct 5 15:10:12 2021 +0100 155872 155873 gdb: improve error reporting from the disassembler 155874 155875 We started seeing FAILs in the gdb.base/all-architectures*.exp tests, 155876 when running on a 32-bit ARM target, though I suspect running on any 155877 target that compiles such that bfd_vma is 32-bits would also trigger 155878 the failures. 155879 155880 The problem is that the test is expected GDB's disassembler to print 155881 an error like this: 155882 155883 Cannot access memory at address 0x0 155884 155885 However, after the above commit we see an error like: 155886 155887 unknown disassembler error (error = -1) 155888 155889 The reason for this is this code in opcodes/i386-dis.c (in the 155890 print_insn function): 155891 155892 if (address_mode == mode_64bit && sizeof (bfd_vma) < 8) 155893 { 155894 (*info->fprintf_func) (info->stream, 155895 _("64-bit address is disabled")); 155896 return -1; 155897 } 155898 155899 This code effectively disallows us from ever disassembling 64-bit x86 155900 code if we compiled GDB with a 32-bit bfd_vma. Notice we return 155901 -1 (indicating a failure to disassemble), but never call the 155902 memory_error_func callback. 155903 155904 Prior to the above commit GDB, when it received the -1 return value 155905 would assume that a memory error had occurred and just print whatever 155906 value happened to be in the memory error address variable, the default 155907 value of 0 just happened to be fine because the test had asked GDB to 155908 do this 'disassemble 0x0,+4'. 155909 155910 If we instead change the test to do 'disassemble 0x100,+4' then GDB 155911 would (previously) have still reported: 155912 155913 Cannot access memory at address 0x0 155914 155915 which makes far less sense. 155916 155917 In this commit I propose to fix this issue by changing the test to 155918 accept either the "Cannot access memory ..." string, or the newer 155919 "unknown disassembler error ..." string. With this change done the 155920 test now passes. 155921 155922 However, there is one weakness with this strategy; if GDB broke such 155923 that we _always_ reported "unknown disassembler error ..." we would 155924 never notice. This clearly would be bad. To avoid this issue I have 155925 adjusted the all-architectures*.exp tests so that, when we disassemble 155926 for the default architecture (the one selected by "auto") we _only_ 155927 expect to get the "Cannot access memory ..." error string. 155928 155929 [ Note: In an ideal world we should be able to disassemble any 155930 architecture at all times. There's no reason why the 64-bit x86 155931 disassembler requires a 64-bit bfd_vma, other than the code happens 155932 to be written that way. We could rewrite the disassemble to not 155933 have this requirement, but, I don't plan to do that any time soon. ] 155934 155935 Further, I have changed the all-architectures*.exp test so that we now 155936 disassemble at address 0x100, this should avoid us being able to pass 155937 by printing a default address of 0x0. I did originally change the 155938 address we disassembled at to 0x4, however, some architectures, 155939 e.g. ia64, have a default instruction alignment that is greater than 155940 4, so would still round down to 0x0. I could have just picked 0x8 as 155941 an address, but I figured that 0x100 was likely to satisfy most 155942 architectures alignment requirements. 155943 1559442021-11-30 Andrew Burgess <aburgess@redhat.com> 155945 155946 gdb/python: add gdb.RemoteTargetConnection.send_packet 155947 This commits adds a new sub-class of gdb.TargetConnection, 155948 gdb.RemoteTargetConnection. This sub-class is created for all 155949 'remote' and 'extended-remote' targets. 155950 155951 This new sub-class has one additional method over its base class, 155952 'send_packet'. This new method is equivalent to the 'maint 155953 packet' CLI command, it allows a custom packet to be sent to a remote 155954 target. 155955 155956 The outgoing packet can either be a bytes object, or a Unicode string, 155957 so long as the Unicode string contains only ASCII characters. 155958 155959 The result of calling RemoteTargetConnection.send_packet is a bytes 155960 object containing the reply that came from the remote. 155961 1559622021-11-30 Andrew Burgess <aburgess@redhat.com> 155963 155964 gdb: make packet_command function available outside remote.c 155965 In a later commit I will add a Python API to access the 'maint packet' 155966 functionality, that is, sending a user specified packet to the target. 155967 155968 To make implementing this easier, this commit refactors how this 155969 command is currently implemented so that the packet_command function 155970 is now global. 155971 155972 The new global send_remote_packet function takes an object that is an 155973 implementation of an abstract interface. Two functions within this 155974 interface are then called, one just before a packet is sent to the 155975 remote target, and one when the reply has been received from the 155976 remote target. Using an interface object in this way allows (1) for 155977 the error checking to be done before the first callback is made, this 155978 means we only print out what packet it being sent once we know we are 155979 going to actually send it, and (2) we don't need to make a copy of the 155980 reply if all we want to do is print it. 155981 155982 One user visible changes after this commit are the error 155983 messages, which I've changed to be less 'maint packet' command 155984 focused, this will make them (I hope) better for when 155985 send_remote_packet can be called from Python code. 155986 155987 So: "command can only be used with remote target" 155988 Becomes: "packets can only be sent to a remote target" 155989 155990 And: "remote-packet command requires packet text as argument" 155991 Becomes: "a remote packet must not be empty" 155992 155993 Additionally, in this commit, I've added support for packet replies 155994 that contain binary data. Before this commit, the code that printed 155995 the reply treated the reply as a C string, it assumed that the string 155996 only contained printable characters, and had a null character only at 155997 the end. 155998 155999 One way to show the problem with this is if we try to read the auxv 156000 data from a remote target, the auxv data is binary, so, before this 156001 commit: 156002 156003 (gdb) target remote :54321 156004 ... 156005 (gdb) maint packet qXfer:auxv:read::0,1000 156006 sending: "qXfer:auxv:read::0,1000" 156007 received: "l!" 156008 (gdb) 156009 156010 And after this commit: 156011 156012 (gdb) target remote :54321 156013 ... 156014 (gdb) maint packet qXfer:auxv:read::0,1000 156015 sending: "qXfer:auxv:read::0,1000" 156016 received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf> 156017 (gdb) 156018 156019 The binary contents of the reply are now printed as escaped hex. 156020 1560212021-11-30 Andrew Burgess <aburgess@redhat.com> 156022 156023 gdb/python: introduce gdb.TargetConnection object type 156024 This commit adds a new object type gdb.TargetConnection. This new 156025 type represents a connection within GDB (a connection as displayed by 156026 'info connections'). 156027 156028 There's three ways to find a gdb.TargetConnection, there's a new 156029 'gdb.connections()' function, which returns a list of all currently 156030 active connections. 156031 156032 Or you can read the new 'connection' property on the gdb.Inferior 156033 object type, this contains the connection for that inferior (or None 156034 if the inferior has no connection, for example, it is exited). 156035 156036 Finally, there's a new gdb.events.connection_removed event registry, 156037 this emits a new gdb.ConnectionEvent whenever a connection is removed 156038 from GDB (this can happen when all inferiors using a connection exit, 156039 though this is not always the case, depending on the connection type). 156040 The gdb.ConnectionEvent has a 'connection' property, which is the 156041 gdb.TargetConnection being removed from GDB. 156042 156043 The gdb.TargetConnection has an 'is_valid()' method. A connection 156044 object becomes invalid when the underlying connection is removed from 156045 GDB (as discussed above, this might be when all inferiors using a 156046 connection exit, or it might be when the user explicitly replaces a 156047 connection in GDB by issuing another 'target' command). 156048 156049 The gdb.TargetConnection has the following read-only properties: 156050 156051 'num': The number for this connection, 156052 156053 'type': e.g. 'native', 'remote', 'sim', etc 156054 156055 'description': The longer description as seen in the 'info 156056 connections' command output. 156057 156058 'details': A string or None. Extra details for the connection, for 156059 example, a remote connection's details might be 156060 'hostname:port'. 156061 1560622021-11-30 Nelson Chu <nelson.chu@sifive.com> 156063 156064 RISC-V: The vtype immediate with more than the defined 8 bits are preserved. 156065 According the rvv spec, 156066 https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc 156067 156068 The bits of vtype immediate from 8 to (xlen - 1) should be reserved. 156069 Therefore, we should also dump the vtype immediate as numbers, when 156070 they are set over 8-bits. I think this is a bug that we used to support 156071 vediv extension and use the bit 8 and 9 of vtype, but forgot to update 156072 the behavior when removing the vediv. 156073 156074 Consider the testcases, 156075 156076 vsetvli a0, a1, 0x700 # the reserved bit 10, 9 and 8 are used. 156077 vsetvli a0, a1, 0x400 # the reserved bit 10 is used. 156078 vsetvli a0, a1, 0x300 # the reserved bit 9 and 8 are used. 156079 vsetvli a0, a1, 0x100 # the reserved bit 8 is used. 156080 vsetivli a0, 0xb, 0x300 # the reserved bit 9 and 8 are used. 156081 vsetivli a0, 0xb, 0x100 # the reserved bit 8 is used. 156082 156083 The original objdump shows the following result, 156084 156085 0000000000000000 <.text>: 156086 0: 7005f557 vsetvli a0,a1,1792 156087 4: 4005f557 vsetvli a0,a1,1024 156088 8: 3005f557 vsetvli a0,a1,e8,m1,tu,mu 156089 c: 1005f557 vsetvli a0,a1,e8,m1,tu,mu 156090 10: f005f557 vsetivli a0,11,e8,m1,tu,mu 156091 14: d005f557 vsetivli a0,11,e8,m1,tu,mu 156092 156093 But in fact the correct result should be, 156094 156095 0000000000000000 <.text>: 156096 0: 7005f557 vsetvli a0,a1,1792 156097 4: 4005f557 vsetvli a0,a1,1024 156098 8: 3005f557 vsetvli a0,a1,768 156099 c: 1005f557 vsetvli a0,a1,256 156100 10: f005f557 vsetivli a0,11,768 156101 14: d005f557 vsetivli a0,11,256 156102 156103 gas/ 156104 * testsuite/gas/riscv/vector-insns.d: Added testcases to 156105 test the reserved bit 8 to (xlen-1) of vtype. 156106 * testsuite/gas/riscv/vector-insns.s: Likewise. 156107 include/ 156108 * opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES, 156109 since they are different for operand Vc and Vb. 156110 opcodes/ 156111 * riscv-dis.c (print_insn_args): Updated imm_vtype_res to 156112 extract the reserved immediate of vtype correctly. 156113 1561142021-11-30 Nelson Chu <nelson.chu@sifive.com> 156115 156116 RISC-V: Dump vset[i]vli immediate as numbers once vsew or vlmul is reserved. 156117 Consider the following case, 156118 156119 vsetvli a0, a1, 0x4 # unrecognized vlmul 156120 vsetvli a0, a1, 0x20 # unrecognized vsew 156121 vsetivli a0, 0xb, 0x4 # unrecognized vlmul 156122 vsetivli a0, 0xb, 0x20 # unrecognized vsew 156123 156124 For the current dis-assembler, we get the result, 156125 156126 0000000000000000 <.text>: 156127 0: 0045f557 vsetvli a0,a1,e8,(null),tu,mu 156128 4: 0205f557 vsetvli a0,a1,e128,m1,tu,mu 156129 8: c045f557 vsetivli a0,11,e8,(null),tu,mu 156130 c: c205f557 vsetivli a0,11,e128,m1,tu,mu 156131 156132 The vsew e128 and vlmul (null) are preserved according to the spec, 156133 so dump these fields looks wrong. Consider that we are used to dump 156134 the unrecognized csr as csr numbers directly, we should also dump 156135 the whole vset[i]vli immediates as numbers, once the vsew or vlmul 156136 is reserved. Therefore, following is what I expected, 156137 156138 0000000000000000 <.text>: 156139 0: 0045f557 vsetvli a0,a1,4 156140 4: 0205f557 vsetvli a0,a1,32 156141 8: c045f557 vsetivli a0,11,4 156142 c: c205f557 vsetivli a0,11,32 156143 156144 gas/ 156145 * testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli 156146 testcases since we should dump the immediate as numbers once 156147 the vsew or vlmul is reserved. 156148 * testsuite/gas/riscv/vector-insns.s: Likewise. 156149 opcodes/ 156150 * riscv-dis.c (print_insn_args): The reserved vsew and vlmul 156151 are NULL string in the riscv_vsew and riscv_vlmul, so dump the 156152 whole imm as numbers once one of them is NULL. 156153 * riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL. 156154 (riscv_vlmul): Set the reserved vlmul to NULL. 156155 1561562021-11-30 Mike Frysinger <vapier@gentoo.org> 156157 156158 zlib: enable silent build rules 156159 156160 ld: enable silent build rules 156161 Also add $(AM_V_xxx) to various manual rules in here. 156162 156163 libctf: enable silent build rules 156164 Also add $(AM_V_xxx) to various manual rules in here. 156165 156166 gprof: enable silent build rules 156167 Also add $(AM_V_xxx) to various manual rules in here. 156168 156169 binutils: merge doc subdir up a level 156170 This avoids a recursive make into the doc subdir and speeds up the 156171 build slightly. It also allows for more parallelism. 156172 156173 binutils: enable silent build rules 156174 Also add $(AM_V_xxx) to various manual rules in here. 156175 156176 bfd: enable silent build rules 156177 Also add $(AM_V_xxx) to various manual rules in here. 156178 156179 opcodes: enable silent build rules 156180 Also add $(AM_V_xxx) to various manual rules in here. 156181 1561822021-11-30 GDB Administrator <gdbadmin@sourceware.org> 156183 156184 Automatic date update in version.in 156185 1561862021-11-29 Tom Tromey <tom@tromey.com> 156187 156188 Allow DW_ATE_UTF for Rust characters 156189 The Rust compiler plans to change the encoding of a Rust 'char' type 156190 to use DW_ATE_UTF. You can see the discussion here: 156191 156192 https://github.com/rust-lang/rust/pull/89887 156193 156194 However, this fails in gdb. I looked into this, and it turns out that 156195 the handling of DW_ATE_UTF is currently fairly specific to C++. In 156196 particular, the code here assumes the C++ type names, and it creates 156197 an integer type. 156198 156199 This comes from commit 53e710acd ("GDB thinks char16_t and char32_t 156200 are signed in C++"). The message says: 156201 156202 Both places need fixing. But since I couldn't tell why dwarf2read.c 156203 needs to create a new type, I've made it use the per-arch built-in 156204 types instead, so that the types are only created once per arch 156205 instead of once per objfile. That seems to work fine. 156206 156207 ... which is fine, but it seems to me that it's also correct to make a 156208 new character type; and this approach is better because it preserves 156209 the type name as well. This does use more memory, but first we 156210 shouldn't be too concerned about the memory use of types coming from 156211 debuginfo; and second, if we are, we should implement type interning 156212 anyway. 156213 156214 Changing this code to use a character type revealed a couple of 156215 oddities in the C/C++ handling of TYPE_CODE_CHAR. This patch fixes 156216 these as well. 156217 156218 I filed PR rust/28637 for this issue, so that this patch can be 156219 backported to the gdb 11 branch. 156220 1562212021-11-29 Aaron Merey <amerey@redhat.com> 156222 Tom de Vries <tdevries@suse.de> 156223 156224 [PR gdb/27026] CTRL-C is ignored when debug info is downloaded 156225 During debuginfod downloads, ctrl-c should result in the download 156226 being cancelled and skipped. However in some cases, ctrl-c fails to 156227 get delivered to gdb during downloading. This can result in downloads 156228 being unskippable. 156229 156230 Fix this by ensuring that target_terminal::ours is in effect for the 156231 duration of each download. 156232 156233 https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3 156234 1562352021-11-29 Nick Clifton <nickc@redhat.com> 156236 156237 strings: Replace references to -u option with references to -U. 156238 PR 28632 156239 1562402021-11-29 Tom de Vries <tdevries@suse.de> 156241 156242 [gdb/symtab] Fix segfault in search_one_symtab 156243 PR28539 describes a segfault in lambda function search_one_symtab due to 156244 psymbol_functions::expand_symtabs_matching calling expansion_notify with a 156245 nullptr symtab: 156246 ... 156247 struct compunit_symtab *symtab = 156248 psymtab_to_symtab (objfile, ps); 156249 156250 if (expansion_notify != NULL) 156251 if (!expansion_notify (symtab)) 156252 return false; 156253 ... 156254 156255 This happens as follows. The partial symtab ps is a dwarf2_include_psymtab 156256 for some header file: 156257 ... 156258 (gdb) p ps.filename 156259 $5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h" 156260 ... 156261 156262 The includer of ps is a shared symtab for a partial unit, with as user: 156263 ... 156264 (gdb) p ps.includer().user.filename 156265 $11 = 0x64fc9f0 \ 156266 "/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp" 156267 ... 156268 156269 The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently 156270 the shared symtab), but returns nullptr because: 156271 ... 156272 struct dwarf2_include_psymtab : public partial_symtab 156273 { 156274 ... 156275 compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override 156276 { 156277 return nullptr; 156278 } 156279 ... 156280 156281 Fix this by returning the Decl.cpp symtab instead, which fixes the segfault 156282 in the PR. 156283 156284 Tested on x86_64-linux. 156285 156286 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28539 156287 1562882021-11-29 Nick Clifton <nickc@redhat.com> 156289 156290 Update description of string's -n option. 156291 PR 28632 156292 * strings.c (usage): Update desciption of -n option. 156293 * doc/binutils.texi: Likewise. 156294 1562952021-11-29 Tom de Vries <tdevries@suse.de> 156296 156297 [gdb/testsuite] Fix typo in proc lines 156298 Proc lines contains a typo: 156299 ... 156300 string_form { set $_line_string_form $value } 156301 ... 156302 156303 Remove the incorrect '$' in '$_line_string_form'. 156304 156305 Tested on x86_64-linux. 156306 1563072021-11-29 Tom de Vries <tdevries@suse.de> 156308 156309 [gdb/testsuite] Use unique files in gdb.dwarf2/dw2-lines.exp 156310 While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the 156311 test-case generates all executables and associated temporary files using the 156312 same filenames. 156313 156314 Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the 156315 test-case. 156316 156317 Tested on x86_64-linux. 156318 1563192021-11-29 Tom de Vries <tdevries@suse.de> 156320 156321 [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp with -m32 156322 When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32, 156323 we run into another instance of PR28383, where the dwarf assembler generates 156324 64-bit relocations which are not supported by the 32-bit assembler: 156325 ... 156326 dw2-lines-dw.S: Assembler messages:^M 156327 outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \ 156328 cannot represent relocation type BFD_RELOC_64^M 156329 ... 156330 156331 Fix this by using _op_offset in _line_finalize_header. 156332 156333 Tested on x86_64-linux. 156334 1563352021-11-29 Mike Frysinger <vapier@gentoo.org> 156336 156337 sim: testsuite: drop most specific istarget checks 156338 We'll rely on the toolchain probing to determine whether each arch's 156339 tests can be run rather the current configure target. This allows 156340 testing all of the ports in a multitarget configuration. 156341 156342 For now, we don't reformat the files entirely to make it easier to 156343 review, and in case we need to make adjustments. Once this feels 156344 like it's stable, we can flatten the code a bit by removing the if 156345 statement entirely. 156346 1563472021-11-29 Mike Frysinger <vapier@gentoo.org> 156348 156349 sim: testsuite: support parallel execution 156350 Break up the dejagnu logic so that we can parallelize the testsuite. 156351 This takes a page from gcc & gdb where each .exp is run in isolation 156352 instead of in serial. 156353 156354 For most targets, this doesn't make much of a difference as they only 156355 have a single .exp. A few (like cris & frv) have multiple .exp though 156356 and will see a bit of a speed up. 156357 156358 The real gain is when testing a multitarget build. This way we can 156359 run all the targets in parallel and cut the execution time a bit. 156360 On my system, it goes from ~155sec to ~100sec. 156361 156362 We can gain further speedups by splitting up some of the larger .exp 156363 files into smaller groups. We'll do that in a followup though. 156364 1563652021-11-29 Mike Frysinger <vapier@gentoo.org> 156366 156367 sim: testsuite: expand arch specific toolchain settings 156368 Leverage the new per-port toolchain settings to initialize the env 156369 for eeach set of tests. This allows us to run all the tests in a 156370 multitarget build if the user sets up the vars. If they don't, we 156371 can still skip all the tests. 156372 1563732021-11-29 Mike Frysinger <vapier@gentoo.org> 156374 156375 sim: testsuite: setup per-port toolchain settings for multitarget build 156376 Gas does not support multitarget builds -- it still only supports 156377 a single input & output format. ld is a bit better, but requires 156378 manual flags to select the right output. This makes it impossible 156379 to run the complete testsuite in a multitarget build. 156380 156381 To address this limitation, create a suite of FOR_TARGET variables 156382 so these can be set to precompiled as & ld programs. It requires 156383 a bit of setup ahead of time, but it's a one-time cost, and makes 156384 running the full testsuite at once much easier. 156385 1563862021-11-29 GDB Administrator <gdbadmin@sourceware.org> 156387 156388 Automatic date update in version.in 156389 1563902021-11-28 Alan Modra <amodra@gmail.com> 156391 156392 PR28629 NIOS2 fallout 156393 The test exactly matched wrong output. 156394 156395 PR 28629 156396 * testsuite/gas/nios2/relax.d: Update expected output. 156397 1563982021-11-28 Mike Frysinger <vapier@gentoo.org> 156399 156400 sim: add checks to core headers to prevent incorrect common building 156401 Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro 156402 which can change the size of core types. Since these haven't been 156403 unified across ports, add checks to make sure they aren't accidentally 156404 included when building for all ports. This caught the sim-load file 156405 using poisoned headers that it didn't actually need. 156406 156407 sim: unify syscall.o building 156408 Now that we've unified all the syscall tables, this file does not rely 156409 on any port-specific settings, so move it up to building as part of the 156410 common step so we only do it once in a multibuild. 156411 156412 sim: drop unused gentmap & nltvals.def logic 156413 Now that all ports have switched to target-newlib-* files, there's 156414 no need for these files & generating things at build time. So punt 156415 the logic and make target-newlib-syscall a hard requirement. 156416 156417 sim: mcore: switch to new target-newlib-syscall 156418 Use the new target-newlib-syscall module. This is needed to merge all 156419 the architectures into a single build, and mcore has a custom syscall 156420 table for its newlib/libgloss port. 156421 156422 sim: riscv: switch to new target-newlib-syscall 156423 Use the new target-newlib-syscall module. This is needed to merge all 156424 the architectures into a single build, and riscv has a custom syscall 156425 table for its newlib/libgloss port. 156426 1564272021-11-28 Mike Frysinger <vapier@gentoo.org> 156428 156429 sim: cr16: switch to new target-newlib-syscall 156430 Use the new target-newlib-syscall module. This is needed to merge all 156431 the architectures into a single build, and cr16 has a custom syscall 156432 table for its newlib/libgloss port. 156433 156434 This allows cleaning up the syscall ifdef logic. We know these will 156435 always exist now. 156436 1564372021-11-28 Mike Frysinger <vapier@gentoo.org> 156438 156439 sim: d10v: switch to new target-newlib-syscall 156440 Use the new target-newlib-syscall module. This is needed to merge all 156441 the architectures into a single build, and d10v has a custom syscall 156442 table for its newlib/libgloss port. 156443 156444 This allows cleaning up the syscall ifdef logic. We know these will 156445 always exist now. 156446 1564472021-11-28 Mike Frysinger <vapier@gentoo.org> 156448 156449 sim: sh: switch to new target-newlib-syscall 156450 Use the new target-newlib-syscall module. This is needed to merge all 156451 the architectures into a single build, and sh has a custom syscall 156452 table for its newlib/libgloss port. 156453 1564542021-11-28 Mike Frysinger <vapier@gentoo.org> 156455 156456 sim: v850: switch to new target-newlib-syscall 156457 Use the new target-newlib-syscall module. This is needed to merge all 156458 the architectures into a single build, and v850 has a custom syscall 156459 table for its newlib/libgloss port. 156460 156461 This allows cleaning up the syscall ifdef logic. We know these will 156462 always exist now. 156463 1564642021-11-28 Mike Frysinger <vapier@gentoo.org> 156465 156466 sim: iq2000/lm32/m32c/moxie/rx: switch to new target-newlib-syscall.h 156467 Use the new target-newlib-syscall.h to provide the target syscall 156468 defines. These code paths are written specifically for the newlib 156469 ABI rather than being generalized, so switching them to the defines 156470 rather than trying to go through the dynamic callback conversion 156471 seems like the best trade-off for now. Might have to reconsider 156472 this in the future. 156473 1564742021-11-28 Mike Frysinger <vapier@gentoo.org> 156475 156476 sim: nltvals: pull target syscalls out into a dedicated source file 156477 Like we just did for pulling out the errno map, pull out the syscall 156478 maps into a dedicated common file. Most newlib ports are using the 156479 same syscall map, but not all, which means we have to do a bit more 156480 work to migrate. 156481 156482 This commit adds the maps and switches the ports using the common 156483 default syscall table over to it. Ports using unique syscall tables 156484 are still using the old targ-map.c logic. 156485 156486 Switching common ports over is easy by checking NL_TARGET, but the 156487 ppc code needs a bit more cleanup here hence its larger diff. 156488 1564892021-11-28 Mike Frysinger <vapier@gentoo.org> 156490 156491 sim: frv: resolve syscalls dynamically 156492 Avoid use of TARGET_<syscall> defines and rely on the callback layers 156493 to resolve these dynamically so we can support multiple syscall layers 156494 instead of assuming the newlib/libgloss numbers all the time. 156495 156496 sim: mn10300: resolve syscalls dynamically 156497 Avoid use of TARGET_<syscall> defines and rely on the callback layers 156498 to resolve these dynamically so we can support multiple syscall layers 156499 instead of assuming the newlib/libgloss numbers all the time. 156500 156501 sim: nltvals: drop i960 156502 This port was dropped from gdb/bfd/sim years ago, so stop including 156503 its syscall constants too. 156504 156505 sim: moxie: fix datadir handling 156506 Expand the value at `make` time rather than configure generation time 156507 so that we handle $(datarootdir) setting properly. 156508 1565092021-11-28 GDB Administrator <gdbadmin@sourceware.org> 156510 156511 Automatic date update in version.in 156512 1565132021-11-27 Simon Marchi <simon.marchi@polymtl.ca> 156514 156515 gdb: fix typos in configure 156516 The variable names used to restore CFLAGS and LDFLAGS here don't quite 156517 match the names used above, resulting in losing the original CFLAGS and 156518 LDFLAGS. Fix that. 156519 156520 Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a 156521 1565222021-11-27 Mike Frysinger <vapier@gentoo.org> 156523 156524 sim: hw: mark hw_descriptors const 156525 156526 sim: testsuite: add dedicated flag for init toolchain tests 156527 As we setup more reliable CC_FOR_TARGET variables for each target, the 156528 bfin way of overriding it to stuff custom CFLAGS doesn't scale well. 156529 Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests 156530 can setup if they want to add custom options. 156531 156532 sim: testsuite: clean up arch specific toolchain settings 156533 In a multitarget build, we process all targets in order, so make sure 156534 the toolchain settings from one don't leak into the next. 156535 1565362021-11-27 Mike Frysinger <vapier@gentoo.org> 156537 156538 sim: cris: always search for local rvdummy tool 156539 If the board info sets the sim to a basename that is found via $PATH 156540 (which is the default dejagnu behavior), the logic here to use its 156541 dirname to find rvdummy fails because it looks for `./rvdummy`. So 156542 switch it to always use the local build of rvdummy which is the one 156543 we want to be testing against in the first place. 156544 156545 If we get a request for testing against a different setup, we can 156546 figure out & document the needs at that point, and then setup some 156547 config knobs to control it. 156548 1565492021-11-27 Tom de Vries <tdevries@suse.de> 156550 156551 [gdb/testsuite] Fix FAIL in gdb.base/list-missing-source.exp 156552 In commit f8080fb7a44 "[gdb/testsuite] Add gdb.base/include-main.exp" a 156553 file gdb.base/main.c was added, which caused the following regression: 156554 ... 156555 (gdb) list^M 156556 <gdb.base/main.c> 156557 (gdb) FAIL: gdb.base/list-missing-source.exp: list 156558 ... 156559 156560 The problem is that the test-case does not expect to find a file main.c, but 156561 now it finds gdb.base/main.c. 156562 156563 Fix this by using the more specific file name list-missing-source.c. 156564 156565 Tested on x86_64-linux. 156566 1565672021-11-27 Mike Frysinger <vapier@gentoo.org> 156568 156569 sim: testsuite: fix bits-gen EXEEXT handling 156570 Add missing $(EXEEXT) to dependencies on bits-gen. These are actually 156571 build-only tools, but automake doesn't allow for build & host tools, so 156572 the rules are re-using EXEEXT. 156573 1565742021-11-27 Mike Frysinger <vapier@gentoo.org> 156575 156576 sim: testsuite: initial support for OS-specific tests 156577 We usually test against the newlib/libgloss environment, but for a 156578 few ports that also support Linux apps, we want to test that logic 156579 too. A lot of the C code is written such that it works with either 156580 newlib/libgloss or glibc/linux toolchains, but we have some tests 156581 that end up being Linux-specific. Cris has been using the target 156582 tuple as a rough proxy for this (where cris*-*-elf is assumed to be 156583 newlib/libgloss, and everything else is glibc/linux), but that is a 156584 bit too rough, and it doesn't work in a multitarget build. 156585 156586 So lets create a few stub files that we can do compile tests with 156587 to detect the different setups, and then let tests declare which 156588 one they require (if they require any at all). 156589 1565902021-11-27 Mike Frysinger <vapier@gentoo.org> 156591 156592 sim: testsuite: unify basic C compiler checks 156593 Both bfin & cris ports test the C compiler to see if it works, but in 156594 their own way. Unify the checks in the common code so we can leverage 156595 them in more ports in the future, and collapse the bfin & cris code. 156596 1565972021-11-27 Mike Frysinger <vapier@gentoo.org> 156598 156599 sim: testsuite: rework sim_init usage 156600 The sim_init function was called by runtest for each test when --tool 156601 was set to sim. When we changed to --tool '' to collapse the testsuite 156602 dir, the init function was no longer called on every test. However, it 156603 was still being called explicitly by config/default.exp. It's not clear 156604 why that explicit call ever existed since, in the past, it meant it was 156605 redundant. 156606 156607 Lets drop the single sim_init call in config/default.exp and move it out 156608 to all our tests. This replicates the runtest behavior so we can setup 156609 variables on a per-test basis which allows us to recollapse the sim_path 156610 logic back. We'll also leverage this in the future for toolchain setup. 156611 156612 Also add a few comments clarifying the overall runtime behavior. 156613 1566142021-11-27 Mike Frysinger <vapier@gentoo.org> 156615 156616 sim: cris: fix testsuite hang when sim is missing 156617 If the cris sim hasn't been built yet, trying to run its testsuite 156618 will hang indefinitely. The common sim APIs already have this, so 156619 copy it over to the cris forks of the test+run functions. 156620 1566212021-11-27 Mike Frysinger <vapier@gentoo.org> 156622 156623 sim: testsuite: fix objdir handling 156624 The tests assume that the cwd is the objdir directory and write its 156625 intermediates to there all the time. When using runtest's --objdir 156626 setting though, this puts the files in the wrong place. This isn't 156627 a big problem currently as we never change --objdir, but in order to 156628 support parallel test execution, we're going to start setting that 156629 option, so clean up the code ahead of time. 156630 156631 We also have to tweak some of the cris tests which were making 156632 assumptions about the argv[0] value. 156633 1566342021-11-27 Mike Frysinger <vapier@gentoo.org> 156635 156636 sim: testsuite: rename global_sim_options to SIMFLAGS_FOR_TARGET 156637 Now that all the other toolchain settings have been renamed to match 156638 the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to 156639 SIMFLAGS_FOR_TARGET too. 156640 156641 sim: testsuite: replace global_ld_options with LDFLAGS_FOR_TARGET 156642 Only a few tests actually use global_ld_options, but we can replace the 156643 sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get 156644 the same result. 156645 1566462021-11-27 GDB Administrator <gdbadmin@sourceware.org> 156647 156648 Automatic date update in version.in 156649 1566502021-11-26 John David Anglin <danglin@gcc.gnu.org> 156651 156652 Fix ifunc test fails on hppa*-*-* 156653 2021-11-26 John David Anglin <danglin@gcc.gnu.org> 156654 156655 PR ld/27442 156656 156657 ld/ChangeLog: 156658 156659 * ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust 156660 regexp. 156661 Skip static ifunc-using executable test on hppa*-*-*. 156662 1566632021-11-26 H.J. Lu <hjl.tools@gmail.com> 156664 156665 gas: Update commit 4780e5e4933 156666 Update 156667 156668 commit 4780e5e4933a2497a5aecc4ceabbbb8e82aaf822 156669 Author: Tom de Vries <tdevries@suse.de> 156670 Date: Fri Nov 26 09:59:45 2021 +0100 156671 156672 [gas] Fix file 0 dir with -gdwarf-5 156673 156674 1. Replace i with j in 156675 156676 for (j = 0; i < NUM_MD5_BYTES; ++j) 156677 156678 2. Pass -W to readelf to force CU: in output due to: 156679 156680 if (do_wide || strlen (directory) < 76) 156681 printf (_("CU: %s/%s:\n"), directory, file_table[0].name); 156682 else 156683 printf ("%s:\n", file_table[0].name); 156684 156685 PR gas/28629 156686 * dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit 156687 4780e5e4933. 156688 * testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to 156689 readelf. 156690 1566912021-11-26 Mike Frysinger <vapier@gentoo.org> 156692 156693 sim: testsuite: replace global_as_options with ASFLAGS_FOR_TARGET 156694 Only a few tests actually use global_as_options, but we can replace the 156695 sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get 156696 the same result. 156697 1566982021-11-26 Tom de Vries <tdevries@suse.de> 156699 156700 [gdb/testsuite] Add gdb.base/include-main.exp 156701 The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with 156702 -gnatG. 156703 156704 This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be 156705 expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the 156706 debug information should refer to the x.adb.dg file. 156707 156708 That is the case for the .debug_line part: 156709 ... 156710 The Directory Table is empty. 156711 156712 The File Name Table (offset 0x1c): 156713 Entry Dir Time Size Name 156714 1 0 0 0 x.adb.dg 156715 ... 156716 but not for the .debug_info part: 156717 ... 156718 <11> DW_AT_name : $src/gdb/testsuite/gdb.ada/dgopt/x.adb 156719 <15> DW_AT_comp_dir : $build/gdb/testsuite/outputs/gdb.ada/dgopt 156720 ... 156721 156722 Filed as PR gcc/103436. 156723 156724 In C we can generate similar debug information, using a source file that does 156725 not contain any code, but includes another one that does: 156726 ... 156727 $ cat gdb/testsuite/gdb.base/include-main.c 156728 #include "main.c" 156729 ... 156730 such that in the .debug_line part we have: 156731 ... 156732 The Directory Table (offset 0x1c): 156733 1 /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base 156734 156735 The File Name Table (offset 0x57): 156736 Entry Dir Time Size Name 156737 1 1 0 0 main.c 156738 ... 156739 and in the .debug_info part: 156740 ... 156741 <11> DW_AT_name : $src/gdb/testsuite/gdb.base/include-main.c 156742 <15> DW_AT_comp_dir : $build/gdb/testsuite 156743 ... 156744 156745 Add a C test-case that mimics gdb.ada/dgopt.exp, that is: 156746 - generate debug info as described above, 156747 - issue a list of a line in include-main.c, while the corresponding 156748 CU is not expanded yet. 156749 156750 Tested on x86_64-linux. 156751 1567522021-11-26 Mike Frysinger <vapier@gentoo.org> 156753 156754 sim: testsuite: drop unused global_cc_options 156755 Nothing in the testsuite is using this setting, so let's drop it. 156756 Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET 156757 instead to get the same effect. 156758 156759 sim: testsuite: punt unused toolchain variables 156760 These haven't been used in over 20 years. The sim testsuite used to 156761 run these tools itself directly, but back in ~1999 it switched to the 156762 dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu 156763 logic only utilizes XXX_FOR_TARGET variables. Punt them here to avoid 156764 confusion with dead code. 156765 1567662021-11-26 Andrew Burgess <aburgess@redhat.com> 156767 Simon Cook <simon.cook@embecosm.com> 156768 156769 gdb: add risc-v disassembler options support 156770 This commit adds support for RISC-V disassembler options to GDB. This 156771 commit is based on this patch which was never committed: 156772 156773 https://sourceware.org/pipermail/binutils/2021-January/114944.html 156774 156775 All of the binutils refactoring has been moved to a separate, earlier, 156776 commit, so this commit is pretty straight forward, just registering 156777 the required gdbarch hooks. 156778 1567792021-11-26 Andrew Burgess <aburgess@redhat.com> 156780 Simon Cook <simon.cook@embecosm.com> 156781 156782 opcodes/riscv: add disassembler options support to libopcodes 156783 In preparation for the next commit, which will add GDB support for 156784 RISC-V disassembler options, this commit restructures how the 156785 disassembler options are managed within libopcodes. 156786 156787 The implementation provided here is based on this mailing list patch 156788 which was never committed: 156789 156790 https://sourceware.org/pipermail/binutils/2021-January/114944.html 156791 156792 which in turn took inspiration from the MIPS implementation of the 156793 same feature. 156794 156795 The biggest changes from the original mailing list post are: 156796 156797 1. The GDB changes have been split into a separate patch, and 156798 156799 2. The `riscv_option_args_privspec` variable, which held the valid 156800 priv-spec values is now gone, instead we use the `riscv_priv_specs` 156801 array from bfd/cpu-riscv.c instead. 156802 156803 156804 include/ChangeLog: 156805 156806 * dis-asm.h (disassembler_options_riscv): Declare. 156807 156808 opcodes/ChangeLog: 156809 156810 * riscv-dis.c (enum riscv_option_arg_t): New enum typedef. 156811 (riscv_options): New static global. 156812 (disassembler_options_riscv): New function. 156813 (print_riscv_disassembler_options): Rewrite to use 156814 disassembler_options_riscv. 156815 1568162021-11-26 Tom de Vries <tdevries@suse.de> 156817 156818 [gas] Fix file 0 dir with -gdwarf-5 156819 In out_dir_and_file_list, if file 0 is copied from file 1, only the filename 156820 is copied, and the dir and md5 fields are left to their default values. 156821 156822 Fix this by adding the copy of the dir and md5 fields. 156823 156824 gas/ChangeLog: 156825 156826 2021-11-26 Tom de Vries <tdevries@suse.de> 156827 156828 PR 28629 156829 * dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0, 156830 also copy dir and md5 fields. 156831 * testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output. 156832 1568332021-11-26 Mike Frysinger <vapier@gentoo.org> 156834 156835 sim: mips: avoid _ namespace 156836 Some C libraries export _P symbols in their headers (like older 156837 newlib and its ctype.h), so use P_ instead to avoid conflicts. 156838 156839 ld: fix POSIX shell test usage 156840 POSIX test uses = for compares, not == which is a bashism. 156841 156842 gas: enable silent build rules 156843 156844 ld: fix --disable-multiple-abs-defs alignment in help 156845 1568462021-11-26 GDB Administrator <gdbadmin@sourceware.org> 156847 156848 Automatic date update in version.in 156849 1568502021-11-25 Enze Li <lienze2010@hotmail.com> 156851 156852 gdb: ensure extension_language_python is always defined 156853 In this commit: 156854 156855 commit c6a6aad52d9e839d6a84ac31cabe2b7e1a2a31a0 156856 Date: Mon Oct 25 17:25:45 2021 +0100 156857 156858 gdb/python: make some global variables static 156859 156860 building without Python was broken. The extension_language_python 156861 global was moved from being always defined, to only being defined when 156862 the HAVE_PYTHON macro was defined. As a consequence, building without 156863 Python support would result in errors like: 156864 156865 /usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python' 156866 156867 This commit fixes the problem by moving the definition of 156868 extension_language_python outside of the HAVE_PYTHON macro protection. 156869 1568702021-11-25 Andrew Burgess <aburgess@redhat.com> 156871 156872 Revert "gdb: add assert in remote_target::wait relating to async being off" 156873 This commit introduced a test failure in gdb.server/attach-flag.exp. 156874 I didn't spot this failure originally as the problem is fixed by this, 156875 as yet unpushed patch: 156876 156877 https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html 156878 156879 I unfortunately didn't test each patch in the original series 156880 independently. I'll repost this patch after the above patch has been 156881 merged. 156882 156883 This reverts commit 32b1f5e8d6b8ddd3be6e471c26dd85a1dac31dda. 156884 1568852021-11-25 Nick Clifton <nickc@redhat.com> 156886 156887 Fix building the AArch64 assembler and disassembler when assertions are disabled. 156888 PR 28614 156889 * aarch64-asm.c: Replace assert(0) with real code. 156890 * aarch64-dis.c: Likewise. 156891 * aarch64-opc.c: Likewise. 156892 1568932021-11-25 Bruno Larsen <blarsen@redhat.com> 156894 156895 PR gdb/28480: Improve ambiguous member detection 156896 Basic ambiguity detection assumes that when 2 fields with the same name 156897 have the same byte offset, it must be an unambiguous request. This is not 156898 always correct. Consider the following code: 156899 156900 class empty { }; 156901 156902 class A { 156903 public: 156904 [[no_unique_address]] empty e; 156905 }; 156906 156907 class B { 156908 public: 156909 int e; 156910 }; 156911 156912 class C: public A, public B { }; 156913 156914 if we tried to use c.e in code, the compiler would warn of an ambiguity, 156915 however, since A::e does not demand an unique address, it gets the same 156916 address (and thus byte offset) of the members, making A::e and B::e have the 156917 same address. however, "print c.e" would fail to report the ambiguity, 156918 and would instead print it as an empty class (first path found). 156919 156920 The new code solves this by checking for other found_fields that have 156921 different m_struct_path.back() (final class that the member was found 156922 in), despite having the same byte offset. 156923 156924 The testcase gdb.cp/ambiguous.exp was also changed to test for this 156925 behavior. 156926 1569272021-11-25 Jan W. Jagersma <jwjagersma@gmail.com> 156928 156929 coff-go32: consistent 16-byte section alignment 156930 Section alignment for coff-go32 is inconsistent - The '.text' and 156931 '.data' sections are 16-byte aligned, but named sections '.text.*' and 156932 '.data.*' are only 4-byte aligned. '.gnu.linkonce.r.*' is aligned to 156933 16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes. For 156934 '.bss' all input sections are only aligned to 4 bytes. 156935 156936 This primarily can cause trouble when using SSE instructions, which 156937 require their memory operands to be aligned to 16-byte boundaries. 156938 156939 This patch solves the issue simply by setting the section alignment 156940 to 16 bytes, for all code and data sections referenced in the default 156941 linker script. 156942 156943 * coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES): Use partial 156944 name match for .text, .data. Add entries for .const, .rodata, 156945 .bss, .gnu.linkonce.b. 156946 1569472021-11-25 Alan Modra <amodra@gmail.com> 156948 156949 Re: AArch64: Add support for AArch64 EFI (efi-*-aarch64) 156950 Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake, 156951 which meant a typo in Makefile.am was not discovered and other 156952 differences in Makefile.in are seen with a proper regeneration. One 156953 difference was lack of an empty line between the pe-aarch64igen.c rule 156954 and the following $(BFD32_LIBS) etc. dependency rule, in the 156955 regenerated file. Not that it matters for proper "make" behaviour, 156956 but it's nicer with a line between those rules. Moving the rule 156957 earlier seems to cure the missing empty line. 156958 156959 * Makefile.am (BFD64_BACKENDS): Correct typo. 156960 (BFD_H_DEPS, LOCAL_H_DEPS): Move earlier. Move rule using these 156961 deps earlier too. 156962 * Makefile.in: Regenerate. 156963 * po/BLD-POTFILES.in: Regenerate. 156964 * po/SRC-POTFILES.in: Regenerate. 156965 1569662021-11-25 Nick Clifton <nickc@redhat.com> 156967 156968 Updated French translation for the opcodes directory. 156969 * po/fr.po; Updated French translation. 156970 1569712021-11-25 Andrew Burgess <aburgess@redhat.com> 156972 156973 gdb: rename source_styling_changed observer 156974 In a later commit I plan to add disassembler styling. In the same way 156975 that we have a source_styling_changed observer I would need to add a 156976 disassembler_styling_changed observer. 156977 156978 However, currently, these observers would only be notified from 156979 cli-style.c:set_style_enabled, and observed in tui-winsource.c, 156980 tui_source_window::style_changed, as a result, having two observers 156981 seems unnecessary right now, so, in this commit, I plan to rename 156982 source_styling_changed to just styling_changed, then, in the later 156983 commit, when disassembler styling is added, I can use the same 156984 observer for both source styling, and disassembler styling. 156985 156986 There should be no user visible changes after this commit. 156987 1569882021-11-25 Andrew Burgess <andrew.burgess@embecosm.com> 156989 156990 gdb/python: make some global variables static 156991 Make a couple of global variables static in python/python.c. To do 156992 this I had to move the definition of extension_language_python to 156993 later in the file. 156994 156995 There should be no user visible changes after this commit. 156996 1569972021-11-25 Andrew Burgess <aburgess@redhat.com> 156998 156999 gdb: add assert in remote_target::wait relating to async being off 157000 While working on another patch I ended up in a situation where I had 157001 async mode disabled (with 'maint set target-async off'), but the async 157002 event token got marked anyway. 157003 157004 In this situation GDB was continually calling into 157005 remote_target::wait, however, the async token would never become 157006 unmarked as the unmarking is guarded by target_is_async_p. 157007 157008 We could just unconditionally unmark the token, but that would feel 157009 like just ignoring a bug, so, instead, lets assert that if 157010 !target_is_async_p, then the async token should not be marked. 157011 157012 This assertion would have caught my earlier mistake. 157013 157014 There should be no user visible changes with this commit. 157015 1570162021-11-25 Andrew Burgess <aburgess@redhat.com> 157017 157018 gdb: simplify remote_target::is_async_p 157019 This commit simplifies remote_target::is_async_p by removing the 157020 target_async_permitted check. 157021 157022 In previous commits I have added additional assertions around the 157023 target_async_permitted flag into target.c, as a result we should now 157024 be confident that if target_can_async_p returns false, a target will 157025 never have async mode enabled. Given this, it should not be necessary 157026 to check target_async_permitted in remote_target::is_async_p, if this 157027 flag is false ::is_async_p should return false anyway. There is an 157028 assert to this effect in target_is_async_p. 157029 157030 There should be no user visible change after this commit. 157031 1570322021-11-25 Andrew Burgess <aburgess@redhat.com> 157033 157034 gdb: add asserts in target.c for target_async_permitted 157035 The target_async_permitted flag allows a user to override whether a 157036 target can act in async mode or not. In previous commits I have moved 157037 the checking of this flag out of the various ::can_async_p methods and 157038 into the common target.c code. 157039 157040 In this commit I will add some additional assertions into 157041 target_is_async_p and target_async. The rules these assertions are 157042 checking are: 157043 157044 1. A target that returns false for target_can_async_p should never 157045 become "async enabled", and so ::is_async_p should always return 157046 false. This is being checked in target_is_async_p. 157047 157048 2. GDB should never try to enable async mode for a target that 157049 returns false for target_can_async_p, this is checked in 157050 target_async. 157051 157052 There are a few places where we call the ::is_async_p method directly, 157053 in these cases we will obviously not pass through the assert in 157054 target_is_async_p, however, there are also plenty of places where we 157055 do call target_is_async_p so if GDB starts to misbehave we should 157056 catch it quickly enough. 157057 157058 There should be no user visible changes after this commit. 157059 1570602021-11-25 Andrew Burgess <aburgess@redhat.com> 157061 157062 gdb: hoist target_async_permitted checks into target.c 157063 This commit moves the target_async_permitted check out of each targets 157064 ::can_async_p method and into the target_can_async_p wrapper function. 157065 157066 I've left some asserts in the two ::can_async_p methods that I 157067 changed, which will hopefully catch any direct calls to these methods 157068 that might be added in the future. 157069 157070 There should be no user visible changes after this commit. 157071 1570722021-11-25 Andrew Burgess <aburgess@redhat.com> 157073 157074 gdb: introduce a new overload of target_can_async_p 157075 There are a few places where we call the target_ops::can_async_p 157076 member function directly, instead of using the target_can_async_p 157077 wrapper. 157078 157079 In some of these places this is because we need to ask before the 157080 target has been pushed, and in another location (in target.c) it seems 157081 unnecessary to go through the wrapper when we are already in target.c 157082 code. 157083 157084 However, in the next commit I'd like to hoist some common checks out 157085 of target specific code into target.c. To achieve this, in this 157086 commit, I introduce a new overload of target_can_async_p which takes a 157087 target_ops pointer, and calls the ::can_async_p method directly. I 157088 then make use of the new overload where appropriate. 157089 157090 There should be no user visible changes after this commit. 157091 1570922021-11-25 Clément Chigot <clement.chigot@atos.net> 157093 157094 ld/testsuite/ld-elfvsb: correctly test "weak hidden symbol DSO last" 157095 The test must be done with the shared object and not with the object 157096 file which is already being tested above. 157097 157098 ld/ 157099 * testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden 157100 symbol DSO last" 157101 1571022021-11-25 Tom de Vries <tdevries@suse.de> 157103 157104 [gdb/cli] Add "set logging enabled", deprecate "set logging on/off" 157105 Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the 157106 following output for "show logging file": 157107 ... 157108 $ gdb -q -batch -ex "set trace-commands on" \ 157109 -ex "set logging off" \ 157110 -ex "show logging file" \ 157111 -ex "set logging on" \ 157112 -ex "show logging file" 157113 +set logging off 157114 +show logging file 157115 Future logs will be written to gdb.txt. 157116 +set logging on 157117 +show logging file 157118 Currently logging to "gdb.txt". 157119 ... 157120 157121 After that commit we have instead: 157122 ... 157123 +set logging off 157124 +show logging file 157125 The current logfile is "gdb.txt". 157126 +set logging on 157127 +show logging file 157128 The current logfile is "gdb.txt". 157129 ... 157130 157131 Before the commit, whether logging is enabled or not can be deduced from the 157132 output of the command. After the commit, the message is unified and it's no 157133 longer clear whether logging is enabled or not. 157134 157135 Fix this by: 157136 - adding a new command "show logging enabled" 157137 - adding a corresponding new command "set logging enabled on/off" 157138 - making the commands "set logging on/off" deprecated aliases of the 157139 "set logging enabled on/off" command. 157140 157141 Update the docs and testsuite to use "set logging enabled". Mention the new 157142 and deprecated commands in NEWS. 157143 157144 Tested on x86_64-linux. 157145 1571462021-11-25 Tom de Vries <tdevries@suse.de> 157147 157148 [gdb/cli] Fix typo in logging overwrite help text 157149 Currently we have: 157150 ... 157151 $ gdb -q -batch -ex "help set logging overwrite" 157152 Set whether logging overwrites or appends to the log file. 157153 If set, logging overrides the log file. 157154 ... 157155 157156 Fix overrides -> overwrites typo. 157157 1571582021-11-25 GDB Administrator <gdbadmin@sourceware.org> 157159 157160 Automatic date update in version.in 157161 1571622021-11-24 Simon Marchi <simon.marchi@efficios.com> 157163 157164 gdb: fix help doc for "set index-cache enabled" 157165 When implementing this command, I put "help doc" as a placeholder for 157166 the help string, and forgot to update it. Change it for a real help 157167 string. 157168 157169 Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09 157170 1571712021-11-24 Simon Marchi <simon.marchi@efficios.com> 157172 157173 Revert (part of) "gdb fix for catch-syscall.exp" 157174 This reverts (par of) commit ab198279120fe7937c0970a8bb881922726678f9. 157175 This commit changed what the test expects when catching the execve 157176 syscall based on the behavior seen on a Linux PowerPC machine. That is, 157177 we get an "entry" event, but no "return" event. This is not what we get 157178 on Linux with other architectures, though, and it seems like a 157179 PowerPC-specific bug. 157180 157181 Revert the part of the patch related to this, but not the other hunk. 157182 157183 Change-Id: I4248776e4299f10999487be96d4acd1b33639996 157184 1571852021-11-24 Nick Clifton <nickc@redhat.com> 157186 157187 Fix an illegal memory access parsing a corrupt sysroff file. 157188 PR 28564 157189 * sysdump.c (getCHARS): Check for an out of bounds read. 157190 1571912021-11-24 Andrew Burgess <aburgess@redhat.com> 157192 157193 gdb: fix crash when reading ECOFF debug information 157194 In commit: 157195 157196 commit 633cf2548bcd3dafe297e21a1dd3574240280d48 157197 Date: Wed May 9 15:42:28 2018 -0600 157198 157199 Remove cleanups from mdebugread.c 157200 157201 the following change was made in the function parse_partial_symbols in 157202 mdebugread.c: 157203 157204 - fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1); 157205 - old_chain = make_cleanup (xfree, fdr_to_pst); 157206 + gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1); 157207 + fdr_to_pst = fdr_to_pst_holder.data (); 157208 157209 The problem with this change is that XCNEWVEC calls xcalloc, which in 157210 turn calls calloc, and calloc zero initializes the allocated memory. 157211 In contrast, the new line gdb::def_vector<struct pst_map> specifically 157212 does not initialize the underlying memory. 157213 157214 This is a problem because, later on in this same function, we 157215 increment the n_globals field within 'struct pst_map' objects stored 157216 in the vector. The incrementing is now being done from an 157217 uninitialized starting point. 157218 157219 In this commit we switch from using gdb::def_vector to using 157220 std::vector, this alone should be enough to ensure that the fields are 157221 initialized to zero. 157222 157223 However, for extra clarity, I have also added initial values in the 157224 'struct pst_map' to make it crystal clear how the struct will start 157225 up. 157226 157227 This issue was reported on the mailing list here: 157228 157229 https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html 157230 157231 Co-Authored-By: Lightning <lightningth@gmail.com> 157232 1572332021-11-24 GDB Administrator <gdbadmin@sourceware.org> 157234 157235 Automatic date update in version.in 157236 1572372021-11-23 Alexandra Hájková <ahajkova@redhat.com> 157238 157239 configure.ac: Check for the readline.h explicitly 157240 When readline development package is missing make fails with 157241 "configure: error: system readline is not new enough" which 157242 might be confusing. This patch checks for the readline.h explicitly 157243 and makes make to warn about the missing package. 157244 1572452021-11-23 Tamar Christina <tamar.christina@arm.com> 157246 157247 AArch64: Add support for AArch64 EFI (efi-*-aarch64). 157248 This adds support for efi-*-aarch64 by virtue of adding a new PEI target 157249 pei-aarch64-little. This is not a full target and only exists to support EFI 157250 at this time. 157251 157252 This means that this target does not support relocation processing and is mostly 157253 a container format. This format has been added to elf based aarch64 targets 157254 such that efi images can be made natively on Linux. 157255 157256 However this target is not valid for use with gas but only with objcopy. 157257 157258 With these changes the resulting file is recognized as an efi image by 157259 third party tools: 157260 157261 > pecli info hello.efi 157262 157263 Metadata 157264 ================================================================================ 157265 MD5: 598c32a778b0f0deebe977fef8578c4e 157266 SHA1: 4580121edd5cb4dc40f51b28f171fd15250df84c 157267 SHA256: 3154bd7cf42433d1c957f6bf55a17ad8c57ed41b29df2d485703349fd6ff1d5c 157268 Imphash: 157269 Size: 47561 bytes 157270 Type: PE32+ executable (EFI application) (stripped to external PDB), for MS Windows 157271 Compile Time: 1970-01-01 00:00:00 (UTC - 0x0 ) 157272 Entry point: 0x2000 (section .text) 157273 157274 Sections 157275 ================================================================================ 157276 Name RWX VirtSize VirtAddr RawAddr RawSize Entropy md5 157277 .text R-X 0x5bb0 0x2000 0x400 0x5c00 6.39 551fbc264256a3f387de8a891500ae0d 157278 .reloc R-- 0xc 0x8000 0x6000 0x200 0.02 0c45f6d812d079821c1d54c09ab89e1d 157279 .data RW- 0x1d88 0x9000 0x6200 0x1e00 4.18 5d1137c09f01289dc62bf754f7290db3 157280 .dynamic RW- 0xf0 0xb000 0x8000 0x200 0.34 5c94ed3206f05a277e6f04fbf131f131 157281 .rela R-- 0xe58 0xc000 0x8200 0x1000 1.87 8b5c6bc30f3acb7ca7bf2e6789d68519 157282 .dynsym R-- 0x138 0xd000 0x9200 0x200 0.96 bdcf5101da51aadc663ca8859f88138c 157283 157284 Imports 157285 ================================================================================ 157286 157287 Any magic number is based on the Microsoft PE specification [1]. 157288 157289 [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format 157290 157291 bfd/ChangeLog: 157292 157293 2021-10-21 Tamar Christina <tamar.christina@arm.com> 157294 157295 PR binutils/26206 157296 * .gitignore (pe-aarch64igen.c): New. 157297 * Makefile.am (pei-aarch64.lo, pe-aarch64igen.lo, pei-aarch64.c, 157298 pe-aarch64igen.c): Add support. 157299 * Makefile.in: Likewise. 157300 * bfd.c (bfd_get_sign_extend_vma): Add pei-aarch64-little. 157301 * coff-aarch64.c: New file. 157302 * coffcode.h (coff_set_arch_mach_hook, coff_set_flags, 157303 coff_write_object_contents) Add aarch64 (aarch64_pei_vec) support. 157304 * config.bfd: Likewise. 157305 * configure: Likewise. 157306 * configure.ac: Likewise. 157307 * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE, 157308 GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE, 157309 GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT, 157310 GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE, 157311 GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT, 157312 GET_PDATA_ENTRY, _bfd_peAArch64_bfd_copy_private_bfd_data_common, 157313 _bfd_peAArch64_bfd_copy_private_section_data, 157314 _bfd_peAArch64_get_symbol_info, _bfd_peAArch64_only_swap_filehdr_out, 157315 _bfd_peAArch64_print_private_bfd_data_common, 157316 _bfd_peAArch64i_final_link_postscript, 157317 _bfd_peAArch64i_only_swap_filehdr_out, _bfd_peAArch64i_swap_aouthdr_in, 157318 _bfd_peAArch64i_swap_aouthdr_out, _bfd_peAArch64i_swap_aux_in, 157319 _bfd_peAArch64i_swap_aux_out, _bfd_peAArch64i_swap_lineno_in, 157320 _bfd_peAArch64i_swap_lineno_out, _bfd_peAArch64i_swap_scnhdr_out, 157321 _bfd_peAArch64i_swap_sym_in, _bfd_peAArch64i_swap_sym_out, 157322 _bfd_peAArch64i_swap_debugdir_in, _bfd_peAArch64i_swap_debugdir_out, 157323 _bfd_peAArch64i_write_codeview_record, 157324 _bfd_peAArch64i_slurp_codeview_record, 157325 _bfd_peAArch64_print_ce_compressed_pdata): New. 157326 * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out, 157327 pe_print_pdata, _bfd_XX_print_private_bfd_data_common, 157328 _bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript): 157329 Support COFF_WITH_peAArch64, 157330 * pei-aarch64.c: New file. 157331 * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p): 157332 Support COFF_WITH_peAArch64. 157333 (jtab): Add dummy entry that traps. 157334 * targets.c (aarch64_pei_vec): New. 157335 157336 binutils/ChangeLog: 157337 157338 2021-10-21 Tamar Christina <tamar.christina@arm.com> 157339 157340 PR binutils/26206 157341 * NEWS: Add new support. 157342 * objcopy.c (convert_efi_target): Add efi-*-aarch64 support. 157343 * testsuite/binutils-all/aarch64/pei-aarch64-little.d: New test. 157344 * testsuite/binutils-all/aarch64/pei-aarch64-little.s: New test. 157345 157346 include/ChangeLog: 157347 157348 2021-10-21 Tamar Christina <tamar.christina@arm.com> 157349 157350 PR binutils/26206 157351 * coff/aarch64.h: New file. 157352 * coff/pe.h (IMAGE_FILE_MACHINE_ARM64): New. 157353 1573542021-11-23 Alan Modra <amodra@gmail.com> 157355 157356 binutils debuginfod test 157357 A missing "return" resulted in this non-ELF fail: 157358 x86_64-w64-mingw32 +FAIL: debuginfod (create separate debug info file) 157359 157360 Also, the debuginfod I have installed does not appear to handle 157361 non-native ELF objects, so only run the test when native. 157362 157363 * testsuite/binutils-all/debuginfod.exp: Don't run test unless 157364 native ELF. 157365 1573662021-11-23 Alan Modra <amodra@gmail.com> 157367 157368 Update bug reporting address 157369 https://sourceware.org/bugzilla/ everywhere 157370 157371 bfd/ 157372 * configure.ac (ACX_BUGURL): Set to https://sourceware.org/bugzilla/ 157373 * po/Make-in (msgid-bugs-address): Likewise. 157374 * README: Report bugs to the above. 157375 * configure: Regenerate. 157376 binutils/ 157377 * po/Make-in (msgid-bugs-address): Update. 157378 gas/ 157379 * README: Update bug address. Delete mention of gcc. 157380 * po/Make-in: Update bug address. 157381 gold/ 157382 * po/Make-in: Update bug address. 157383 gprof/ 157384 * po/Make-in: Update bug address. 157385 ld/ 157386 * po/Make-in: Update bug address. 157387 opcodes/ 157388 * po/Make-in: Update bug address. 157389 1573902021-11-23 Jan (janneke) Nieuwenhuizen <janneke@gnu.org> 157391 157392 gdb: more compile fixes for gnu-nat.c 157393 This fixes compile errors like 157394 157395 ../../gdb-11.1/gdb/gnu-nat.c: In function void add_task_commands(): 157396 ../../gdb-11.1/gdb/gnu-nat.c:3204:17: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**) 157397 3204 | &setlist); 157398 | ^ 157399 In file included from ../../gdb-11.1/gdb/completer.h:21, 157400 from ../../gdb-11.1/gdb/symtab.h:36, 157401 from ../../gdb-11.1/gdb/infrun.h:21, 157402 from ../../gdb-11.1/gdb/target.h:42, 157403 from ../../gdb-11.1/gdb/inf-child.h:23, 157404 from ../../gdb-11.1/gdb/gnu-nat.h:38, 157405 from ../../gdb-11.1/gdb/gnu-nat.c:24: 157406 ../../gdb-11.1/gdb/command.h:160:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, void (*)(const char*, int), const char*, cmd_list_element**) 157407 160 | extern struct cmd_list_element *add_cmd (const char *, enum command_class, 157408 | ^~~~~~~ 157409 ../../gdb-11.1/gdb/command.h:161:30: note: no known conversion for argument 3 from cmd_list_element* to void (*)(const char*, int) 157410 161 | cmd_const_cfunc_ftype *fun, 157411 | ~~~~~~~~~~~~~~~~~~~~~~~^~~ 157412 ../../gdb-11.1/gdb/command.h:167:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, const char*, cmd_list_element**) 157413 167 | extern struct cmd_list_element *add_cmd (const char *, enum command_class, 157414 | ^~~~~~~ 157415 ../../gdb-11.1/gdb/command.h:167:33: note: candidate expects 4 arguments, 5 provided 157416 ../../gdb-11.1/gdb/gnu-nat.c:3210:18: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**) 157417 3210 | &showlist); 157418 | ^ 157419 157420 Change-Id: Ie9029363d3fb40e34e8f5b1ab503745bc44bfe3f 157421 1574222021-11-23 Andrea Monaco <andrea.monaco@autistici.org> 157423 157424 gnu-nat.c: fix calls to add_info_alias 157425 Some time ago add_info_alias was changed (commit 157426 e0f25bd9717c7973197095523db7c1cdc956cea2). These calls were not updated 157427 and caused errors on compilation. 157428 157429 Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de 157430 1574312021-11-23 GDB Administrator <gdbadmin@sourceware.org> 157432 157433 Automatic date update in version.in 157434 1574352021-11-22 Simon Marchi <simon.marchi@efficios.com> 157436 157437 gdb: pass more const target_waitstatus by reference 157438 While working on target_waitstatus changes, I noticed a few places where 157439 const target_waitstatus objects could be passed by reference instead of 157440 by pointers. And in some cases, places where a target_waitstatus could 157441 be passed as const, but was not. Convert them as much as possible. 157442 157443 Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a 157444 1574452021-11-22 Simon Marchi <simon.marchi@efficios.com> 157446 157447 gdb: introduce target_waitkind_str, use it in target_waitstatus::to_string 157448 I would like to print target_waitkind values in debug messages, so I 157449 think that a target_waitkind-to-string function would be useful. While 157450 at it, use it in target_waitstatus::to_string. This changes the output 157451 of target_waitstatus::to_string a bit, but I think it is for the better. 157452 The debug messages will show a string matching exactly the 157453 target_waitkind enumerator (minus the TARGET_WAITKIND prefix). 157454 157455 As a convenience, make string_appendf return the same reference to 157456 string it got as a parameter. This allows doing this: 157457 157458 return string_appendf (str, "foo"); 157459 157460 ... keeping the code concise. 157461 157462 Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7 157463 1574642021-11-22 Simon Marchi <simon.marchi@efficios.com> 157465 157466 gdb: rename target_waitstatus_to_string to target_waitstatus::to_string 157467 Make target_waitstatus_to_string a "to_string" method of 157468 target_waitstatus, a bit like we have ptid_t::to_string already. This 157469 will save a bit of typing. 157470 157471 Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905 157472 1574732021-11-22 Nelson Chu <nelson.chu@sifive.com> 157474 157475 RISC-V: Removed the redundant NULL pointer check in the riscv_update_subset. 157476 If we always use the .option arch to call the riscv_update_subset, then 157477 it is almost impossible that the input string will be NULL. Therefore, 157478 just remove the redundant NULL pointer check in the riscv_update_subset. 157479 157480 bfd/ 157481 * elfxx-riscv.c (riscv_update_subset): Removed the redundant NULL 157482 pointer check. 157483 1574842021-11-22 Nelson Chu <nelson.chu@sifive.com> 157485 157486 RISC-V: Replace .option rvc/norvc with .option arch, +c/-c. 157487 Since the .option rvc/norvc directives are obsolete, replace them with 157488 the new proposed diretives: .option arch, +c/-c. And also reset the 157489 riscv_opts.rvc flag for the .option arch directives. 157490 157491 gas/ 157492 * config/tc-riscv.c (s_riscv_option): Reset the riscv_opts.rvc 157493 for the .option arch directives. 157494 * testsuite/gas/riscv/align-1.s: Replace the obsolete .option 157495 rvc/norvc with .option arch, +c/-c. 157496 * testsuite/gas/riscv/c-add-addi.s: Likewise. 157497 * testsuite/gas/riscv/c-nonzero-imm.s: Likewise. 157498 * testsuite/gas/riscv/c-nonzero-reg.s: Likewise. 157499 * testsuite/gas/riscv/c-zero-imm-64.s: Likewise. 157500 * testsuite/gas/riscv/c-zero-imm.s: Likewise. 157501 * testsuite/gas/riscv/c-zero-reg.s: Likewise. 157502 * testsuite/gas/riscv/ext.s: Likewise. 157503 * testsuite/gas/riscv/mapping-01.s: Likewise. 157504 * testsuite/gas/riscv/mapping-02.s: Likewise. 157505 * testsuite/gas/riscv/mapping-03.s: Likewise. 157506 * testsuite/gas/riscv/mapping-04.s: Likewise. 157507 * testsuite/gas/riscv/no-relax-align-2.s: Likewise. 157508 * testsuite/gas/riscv/shamt-32.s: Likewise. 157509 * testsuite/gas/riscv/shamt-64.s: Likewise. 157510 1575112021-11-22 Tom de Vries <tdevries@suse.de> 157512 157513 [gdb/build] Fix x86_64 x32 build 157514 A build error on x86_64 with x32 abi was reported here ( 157515 https://sourceware.org/pipermail/gdb/2021-November/049787.html ): 157516 ... 157517 gdb/nat/amd64-linux-siginfo.c:280:42: error: \ 157518 'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \ 157519 named 'si_addr_bnd' 157520 280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower 157521 | ^~~~~~~~~~~ 157522 gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower' 157523 337 | to->cpt_si_lower = from_ptrace.cpt_si_lower; 157524 | ^~~~~~~~~~~~ 157525 ... 157526 157527 The problem is that code added in commit d3d7d1ba3bb "[gdb/tdep] Handle 157528 si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32 157529 setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields. 157530 157531 Fix this conservatively by disabling the code for x32. 157532 157533 Tested on x86_64-linux. 157534 1575352021-11-22 Nelson Chu <nelson.chu@sifive.com> 157536 157537 RISC-V: PR28610, Fix ASAN heap-buffer-overflow error in riscv_update_subset. 157538 The architecture parser in riscv_update_subset shouldn't check (or access) 157539 the pointer space which doesn't exist. 157540 157541 bfd/ 157542 pr 28610 157543 * elfxx-riscv.c (riscv_update_subset): The architecture parser 157544 shouldn't access the pointer space which doesn't exist. 157545 1575462021-11-22 Tom de Vries <tdevries@suse.de> 157547 157548 [gdb/symtab] Support .debug_line with DW_FORM_line_strp 157549 I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1). 157550 157551 With a test-case hello.c: 157552 ... 157553 int 157554 main (void) 157555 { 157556 printf ("hello\n"); 157557 return 0; 157558 } 157559 ... 157560 compiled like this: 157561 ... 157562 $ gcc -g -gdwarf64 ~/hello.c 157563 ... 157564 I ran into: 157565 ... 157566 $ gdb -q -batch a.out 157567 DW_FORM_line_strp pointing outside of .debug_line_str section \ 157568 [in module a.out] 157569 ... 157570 157571 Debugging gdb revealed that the string offset is: 157572 ... 157573 (gdb) up 157574 objfile=0x182ab70, str_offset=1378684502312, 157575 form_name=0xeae9b5 "DW_FORM_line_strp") 157576 at src/gdb/dwarf2/section.c:208 157577 208 error (_("%s pointing outside of %s section [in module %s]"), 157578 (gdb) p /x str_offset 157579 $1 = 0x14100000128 157580 (gdb) 157581 ... 157582 which is read when parsing a .debug_line entry at 0x1e0. 157583 157584 Looking with readelf at the 0x1e0 entry, we have: 157585 ... 157586 The Directory Table (offset 0x202, lines 2, columns 1): 157587 Entry Name 157588 0 (indirect line string, offset: 0x128): /data/gdb_versions/devel 157589 1 (indirect line string, offset: 0x141): /home/vries 157590 ... 157591 which in a hexdump looks like: 157592 ... 157593 0x00000200 1f022801 00004101 00000201 1f020f02 157594 ... 157595 157596 What happens is the following: 157597 - readelf interprets the DW_FORM_line_strp reference to .debug_line_str as 157598 a 4 byte value, and sees entries 0x00000128 and 0x00000141. 157599 - gdb instead interprets it as an 8 byte value, and sees as first entry 157600 0x0000014100000128, which is too big so it bails out. 157601 157602 AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis 157603 that the corresponding CU is 64-bit DWARF. However, the .debug_line 157604 contribution has it's own initial_length field, and encodes there that it's 157605 32-bit DWARF. 157606 157607 Fix this by using the correct offset size for DW_FORM_line_strp references 157608 in .debug_line. 157609 157610 Note: the described test-case does trigger this complaint (both with and 157611 without this patch): 157612 ... 157613 $ gdb -q -batch -iex "set complaints 10" a.out 157614 During symbol reading: intermixed 32-bit and 64-bit DWARF sections 157615 ... 157616 157617 The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to 157618 gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's 157619 what gas generates. Perhaps this is complaint-worthy, but I don't think it 157620 is wrong. 157621 157622 Tested on x86_64-linux, using native and target board dwarf64.exp. 157623 1576242021-11-22 Tom de Vries <tdevries@suse.de> 157625 157626 [gdb/testsuite] Add target board dwarf64.exp 157627 Add a new target board dwarf64.exp, that runs test with -gdwarf64. 157628 157629 Tested on x86_64-linux. 157630 1576312021-11-22 Tom de Vries <tdevries@suse.de> 157632 157633 [gdb/testsuite] Support .debug_line v5 in dwarf assembler 157634 The v5 section version for .debug_line has: 157635 - two new fields address_size and segment_selector_size 157636 - a different way to encode the directory and filename tables. 157637 157638 Add support for this in the dwarf assembler. 157639 157640 For now, make the v5 directory and filename tables work with the v4 type of 157641 specification in the test-cases by adding duplicate entries at position 0. 157642 157643 This will need to be properly fixed with an intrusive fix that changes how 157644 directory and filename entries are specified in the test-cases, f.i: 157645 ... 157646 set diridx [include_dir "${srcdir}/${subdir}"] 157647 set fileidx [file_name "$srcfile" $diridx] 157648 ... 157649 157650 Tested on x86_64-linux. 157651 1576522021-11-22 Tom de Vries <tdevries@suse.de> 157653 157654 [gdb/testsuite] Factor out _line_finalize_header 157655 Rather than generate dwarf immediately in procs include_dir and file_name, 157656 postpone generation and store the data in variables. Then handle the 157657 generation in a new proc _line_finalize_header. 157658 157659 Tested on x86-64-linux. 157660 1576612021-11-22 Tom de Vries <tdevries@suse.de> 157662 157663 [gdb/testsuite] Support .debug_line v4 in dwarf assembler 157664 The .debug_line header got a new field in v4: 157665 maximum_operations_per_instruction. 157666 157667 Generate this field in the dwarf assembler, for now hardcoding the value to 1, 157668 meaning non-VLIW. 157669 157670 Tested on x86_64-linux. 157671 1576722021-11-22 Tom de Vries <tdevries@suse.de> 157673 157674 [gdb/testsuite] Add test-case gdb.dwarf2/dw2-lines.exp 157675 Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line 157676 sections. 157677 157678 Tested on x86_64-linux. 157679 1576802021-11-22 Tom de Vries <tdevries@suse.de> 157681 157682 [gdb/testsuite] Speed up MACRO_AT_* calls 157683 Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the 157684 following is done: 157685 - $srcdir/$subdir/$srcfile is compiled to an executable using 157686 flags "debug" 157687 - a new gdb instance is started 157688 - the new executable is loaded. 157689 157690 This is inefficient, because the executable is identical within the same 157691 Dwarf::assemble call. 157692 157693 Share the gdb instance in the same Dwarf::assemble invocation, which speeds 157694 up a make check with RUNTESTFLAGS like this to catch all dwarf assembly 157695 test-cases: 157696 ... 157697 rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \ 157698 | xargs grep -l Dwarf::assemble)) 157699 ... 157700 from: 157701 ... 157702 real 1m39.916s 157703 user 1m25.668s 157704 sys 0m21.377s 157705 ... 157706 to: 157707 ... 157708 real 1m29.512s 157709 user 1m17.316s 157710 sys 0m19.100s 157711 ... 157712 157713 Tested on x86_64-linux. 157714 1577152021-11-22 GDB Administrator <gdbadmin@sourceware.org> 157716 157717 Automatic date update in version.in 157718 1577192021-11-21 Lancelot SIX <lsix@lancelotsix.com> 157720 157721 gdb/testsuite: Remove duplicates in gdb.base/catch-signal.exp 157722 When running the testsuite I have the following: 157723 157724 Running .../gdb/testsuite/gdb.base/catch-signal.exp ... 157725 DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue 157726 DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue 157727 DUPLICATE: gdb.base/catch-signal.exp: 1: continue 157728 DUPLICATE: gdb.base/catch-signal.exp: 1: continue 157729 DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue 157730 DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue 157731 157732 This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly 157733 giving names to the offending 'gdb_test "continue"' statements to make 157734 them distinct. 157735 157736 Tested on x86_64-linux. 157737 1577382021-11-21 Mike Frysinger <vapier@gentoo.org> 157739 157740 sim: v850: fix cpu_option testsuite handling 157741 The v850 testsuite code has been testing the $opt variable, but this 157742 was never actually set anywhere globally or v850-specific. Instead, 157743 this was a random variable leaking out of the sh testsuite code. As 157744 far as I can tell, it has always been this way. That means the code 157745 only ever tested the v850 cpu target (which is the default). 157746 157747 This failure can be easily seen in practice by running the v850 code 157748 in isolation and seeing it crash: 157749 $ runtest v850/allinsns.exp 157750 ... 157751 Running target unix 157752 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. 157753 Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. 157754 Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file. 157755 WARNING: Assuming target board is the local machine (which is probably wrong). 157756 You may need to set your DEJAGNU environment variable. 157757 Running ../../../sim/testsuite/v850/allinsns.exp ... 157758 ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp. 157759 ERROR: tcl error code TCL LOOKUP VARNAME opt 157760 ERROR: can't read "opt": no such variable 157761 while executing 157762 "switch -regexp -- $opt { 157763 157764 Backing up a bit, the reason for this logic in the first place is 157765 because the common sim testsuite code makes an assumption about the 157766 assembler options with cpu_option -- the option and its value are 157767 always separated by an =. This is not the case with v850. So tweak 157768 the core sim logic a bit to support omitting the = so that we can 157769 switch v850 to the standard all_machs setting and avoid opt entirely. 157770 1577712021-11-21 GDB Administrator <gdbadmin@sourceware.org> 157772 157773 Automatic date update in version.in 157774 1577752021-11-20 Jeff Law <jeffreyalaw@gmail.com> 157776 157777 Fix intermittent failures on the H8, particularly H8/SX tests. 157778 The upstream GCC tester has showed spurious execution failures on the 157779 H8 target for the H8/SX multilibs. I suspected memory corruption or an 157780 uninitialized variable early as the same binary would sometimes work and 157781 sometimes it got the wrong result. Worse yet, the point where the test 157782 determined it was getting the wrong result would change. 157783 157784 Because it only happened on the H8/SX variant I was able to zero in on 157785 the "mova" support and the "short form" of those instructions in particular. 157786 157787 As the code stands it checks if code->op3.type == 0 to try and identify cases 157788 where op3 wasn't filled in and thus we've got the short form of the mova 157789 instruction. 157790 157791 But for the short-form of those instructions we never set any of the "op3" 157792 data structure. We get whatever was lying around -- it's usually zero and 157793 thus things usually work, but if the stale data was nonzero, then we'd 157794 fail to recognize the instruction as a short-form and fail to set up the 157795 various fields appropriately. 157796 157797 I initially initialized the op3.type field to zero, but didn't like that 157798 because it was inconsistent with how other operands were initialized. 157799 Bringing consistency meant using -1 as the initializer value and adjusting 157800 the check for short form mova appropriately. 157801 157802 I've had this in the upstream GCC tester for perhaps a year at this point 157803 and haven't seen any of the intermittent failures again. 157804 1578052021-11-20 Simon Marchi <simon.marchi@efficios.com> 157806 157807 gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUG 157808 When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors 157809 like: 157810 157811 CXX unittests/array-view-selftests.o 157812 In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25, 157813 from /home/smarchi/src/binutils-gdb/gdb/defs.h:630, 157814 from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20: 157815 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int: 157816 /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29: required from here 157817 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement 157818 192 | } 157819 | ^ 157820 157821 This is because constexpr functions in c++11 can only consist of a 157822 single return statement, so we can't have the gdb_assert in there. Make 157823 the gdb_assert presence conditional to the __cplusplus version, to 157824 enable it only for c++14 and later. 157825 157826 Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0 157827 1578282021-11-20 Tom de Vries <tdevries@suse.de> 157829 157830 [gdb/build] Check if libsource-highlight is usable 157831 When building gdb with g++ 4.8.5, I ran into: 157832 ... 157833 ld: source-cache.o: in function `source_cache::ensure(symtab*)': 157834 source-cache.c:207: undefined reference to \ 157835 srchilite::SourceHighlight::SourceHighlight(std::string const&) 157836 ... 157837 157838 [ I configured gdb without explicit settings related to source-highlight, so 157839 we're excercising the enable_source_highlight=auto scenario. ] 157840 157841 The problem is that: 157842 - the source-highlight library is build with system compiler 157843 g++ 7.5.0 which uses the new libstdc++ library abi (see 157844 https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ) 157845 - gdb is build using g++ 4.8.5 which uses the old abi. 157846 157847 [ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work 157848 for this case. Instead, it enables the opposite case where the 157849 source-highlight library is build with g++ 4.8.5 and gdb is build with 157850 g++ 7.5.0. ] 157851 157852 Fix this by checking whether the source-highlight library is usable during 157853 configuration. 157854 157855 In the enable_source_highlight=auto scenario, this allows the build to skip 157856 the unusable library and finish successfully. 157857 157858 In the enable_source_highlight=yes scenario, this allows the build to error 157859 out earlier. 157860 157861 Tested on x86_64-linux. 157862 1578632021-11-20 Clément Chigot <clement.chigot@atos.net> 157864 157865 bfd: remove wrong comment in xcofflink.c 157866 This comment was long time ago associated to the function 157867 "xcoff_build_ldsyms" which have since been replaced by 157868 "xcoff_build_ldsym". 157869 157870 * xcofflink.c: Remove wrong comment. 157871 1578722021-11-20 Mike Frysinger <vapier@gentoo.org> 157873 157874 sim: bfin: fix short --env usage in testsuite 157875 Now that we have more than one option that matches "--env", the test 157876 config here doesn't work. Use the explicit --environment. 157877 1578782021-11-20 GDB Administrator <gdbadmin@sourceware.org> 157879 157880 Automatic date update in version.in 157881 1578822021-11-19 H.J. Lu <hjl.tools@gmail.com> 157883 157884 elfedit: Align --[in|out]put-abiversion usage 157885 Align 157886 157887 --input-abiversion [0-255] Set input ABIVERSION 157888 --output-abiversion [0-255] Set output ABIVERSION 157889 157890 instead of 157891 157892 --input-abiversion [0-255] 157893 Set input ABIVERSION 157894 --output-abiversion [0-255] 157895 Set output ABIVERSION 157896 157897 * elfedit.c (usage): Align --[in|out]put-abiversion usage. 157898 1578992021-11-19 Tom de Vries <tdevries@suse.de> 157900 157901 [gdb/testsuite] Handle runto fail in gdb.mi/mi-var-cp.exp 157902 On OBS I ran into: 157903 ... 157904 PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint) 157905 UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target 157906 ... 157907 followed by 81 FAILs and two more UNRESOLVEDs. 157908 157909 I didn't manage to reproduce this, but I did notice that the initial 157910 problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs. 157911 157912 I emulated the problem by commenting out the send_gdb "run\n" in 157913 mi_run_cmd_full. 157914 157915 Fix this by: 157916 - handling mi_run_cmd failure in mi_get_inline_test 157917 - handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and 157918 other test-cases using mi_get_inline_test 157919 157920 Tested on x86_64-linux. 157921 1579222021-11-19 Tom de Vries <tdevries@suse.de> 157923 157924 [gdb/testsuite] Fix 64-bit dwarf test-cases with -m32 157925 When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32, 157926 I run into: 157927 ... 157928 builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \ 157929 -fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \ 157930 loc-sec-offset-dw64.S^M 157931 as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M 157932 loc-sec-offset-dw64.S: Assembler messages:^M 157933 loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \ 157934 BFD_RELOC_64^M 157935 ... 157936 157937 Looking at line 29, we have: 157938 ... 157939 .8byte .Labbrev1_begin /* Abbrevs */ 157940 ... 157941 157942 It would be nice if the assembler could handle this somehow. But I guess 157943 it's not unreasonable that an assembler for a 32-bit architecture will object 157944 to handling 64-bit labels. 157945 157946 Instead, work around this in the dwarf assembler by emitting: 157947 ... 157948 .4byte .Labbrev1_begin /* Abbrevs (lsw) */ 157949 .4byte 0 /* Abbrevs (msw) */ 157950 ... 157951 157952 Tested on x86_64-linux with target board unix/-m32. 157953 157954 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383 157955 1579562021-11-19 Tom de Vries <tdevries@suse.de> 157957 157958 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp 157959 On OBS I ran into a failure in test-case gdb.threads/thread-specific-bp.exp: 157960 ... 157961 (gdb) PASS: gdb.threads/thread-specific-bp.exp: non-stop: continue to end 157962 info breakpoint^M 157963 Num Type Disp Enb Address What^M 157964 1 breakpoint keep y 0x0000555555555167 in main at $src:36^M 157965 breakpoint already hit 1 time^M 157966 2 breakpoint keep y 0x0000555555555151 in start at $src:23^M 157967 breakpoint already hit 1 time^M 157968 3 breakpoint keep y 0x0000555555555167 in main at $src:36 thread 2^M 157969 stop only in thread 2^M 157970 4 breakpoint keep y 0x000055555555515c in end at $src:29^M 157971 breakpoint already hit 1 time^M 157972 (gdb) [Thread 0x7ffff7db1640 (LWP 19984) exited]^M 157973 Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M 157974 FAIL: gdb.threads/thread-specific-bp.exp: non-stop: \ 157975 thread-specific breakpoint was deleted (timeout) 157976 ... 157977 157978 Fix this by waiting for the "[Thread 0x7ffff7db1640 (LWP 19984) exited]" 157979 message before issuing the "info breakpoint command". 157980 157981 Tested on x86_64-linux. 157982 1579832021-11-19 Christina Schimpe <christina.schimpe@intel.com> 157984 157985 gdb/testsuite: Extend tests for print of cv qualifiers 157986 This commit supplements whatis and ptype command tests for print of 157987 const-volatile qualifiers. 157988 157989 gdb/testsuite/ChangeLog: 157990 2021-11-16 Christina Schimpe <christina.schimpe@intel.com> 157991 157992 * gdb.cp/ptype-cv-cp.cc: New const and volatile typedef 157993 variables. 157994 * gdb.cp/ptype-cv-cp.exp: Add new tests. 157995 1579962021-11-19 Christina Schimpe <christina.schimpe@intel.com> 157997 157998 gdb: Print cv qualifiers if class attributes are substituted 157999 Make ptype print const/volatile qualifiers when template or typedef 158000 attributes are substituted. 158001 158002 For a programm like 158003 ~~~ 158004 template<typename DataT> 158005 class Cfoo 158006 { 158007 typedef float myfloat; 158008 public: 158009 DataT me0; 158010 const DataT me1=1; 158011 const myfloat me2=2.0; 158012 }; 158013 158014 int main() 158015 { 158016 Cfoo<int> cfoo; 158017 return 0; 158018 } 158019 ~~~ 158020 158021 gdb outputs the following type for cfoo's attributes: 158022 158023 ~~~ 158024 (gdb) b 14 158025 Breakpoint 1 at 0x1170: file tmp.cc, line 14. 158026 (gdb) run 158027 Starting program: /tmp 158028 158029 Breakpoint 1, main () at tmp.cc:14 158030 14 return 0; 158031 (gdb) ptype cfoo 158032 type = class Cfoo<int> [with DataT = int] { 158033 public: 158034 DataT me0; 158035 DataT me1; 158036 myfloat me2; 158037 158038 private: 158039 typedef float myfloat; 158040 } 158041 158042 ~~~ 158043 158044 The cv qualifiers (const in this case) are ignored for me1 and me2. 158045 158046 After: 158047 ~~~ 158048 (gdb) ptype cfoo 158049 type = class Cfoo<int> [with DataT = int] { 158050 public: 158051 DataT me0; 158052 const DataT me1; 158053 const myfloat me2; 158054 158055 private: 158056 typedef float myfloat; 158057 } 158058 ~~~ 158059 158060 gdb/ChangeLog: 158061 2021-11-16 Christina Schimpe <christina.schimpe@intel.com> 158062 158063 * gdb/c-typeprint.c: Print cv qualifiers in case of parameter 158064 substitution. 158065 158066 gdb/testsuite/ChangeLog: 158067 2021-11-16 Christina Schimpe <christina.schimpe@intel.com> 158068 158069 * gdb.cp/templates.cc: New template class Cfoo with const, 158070 template, typdef and integer attributes. 158071 * gdb.cp/templates.exp: Add new test using ptype and ptype/r 158072 commmands for template class CFoo. 158073 1580742021-11-19 Nelson Chu <nelson.chu@sifive.com> 158075 158076 RISC-V: Support new .option arch directive. 158077 https://github.com/riscv/riscv-asm-manual/pull/67 158078 158079 Format: 158080 .option arch, +<extension><version>, ... 158081 .option arch, -<extension> 158082 .option arch, =<ISA string> 158083 158084 The new direcitve is used to enable/disable extensions for the specific 158085 code region. For example, 158086 158087 .attribute arch, "rv64ic" # arch = rv64i2p0_c2p0 158088 .option push 158089 .option arch, +d2p0, -c # arch = rv64i2p0_f2p0_d2p0, f is added implied 158090 .option arch, =rv32gc # arch = rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0 158091 .option pop # arch = rv64i2p0_c2p0 158092 158093 Note that, 158094 1. ".option rvc/norvc" have the same behavior as ".option arch +c/-c". 158095 2. ".option arch -i" is illegal, since we cannot remove base i extension. 158096 3. If arch=rv64i2p0, then ".option arch, +i3p0" will update the i's version 158097 from 2.0 to 3.0. 158098 4. If arch=rv64i3p0, then ".option arch, +i" will update the i's version 158099 from 2.0 to the default one according to the chosen isa spec. 158100 158101 bfd/ 158102 * elfxx-riscv.c (riscv_add_subset): If the subset is already added, 158103 and the new versions are not RISCV_UNKNOWN_VERSION, then update the 158104 versions to the subset list. 158105 (riscv_copy_subset): New function. Copy the subset from list. 158106 (riscv_copy_subset_list): New function. Return the new copyed list. 158107 (riscv_update_subset): Updated to make .option arch directives workable. 158108 * elfxx-riscv.h: Updated. 158109 gas/ 158110 * config/tc-riscv.c (riscv_subsets): Defined as a pointer. 158111 (riscv_rps_as): Init the subset_list to NULL, we will set it later 158112 once riscv_opts_stack is created or updated. 158113 (struct riscv_option_stack, riscv_opts_stack): Moved forward. 158114 (riscv_set_arch): Updated. 158115 (s_riscv_option): Support new .option arch directive, to add, remove 158116 or update subsets for the specific code region. 158117 (riscv_write_out_attrs): Updated. 158118 * doc/c-riscv.texi: Added document for new .option arch directive. 158119 * testsuite/gas/riscv/option-arch-01a.d: New testcase. 158120 * testsuite/gas/riscv/option-arch-01b.d: Likewise. 158121 * testsuite/gas/riscv/option-arch-01.s: Likewise.. 158122 * testsuite/gas/riscv/option-arch-02.d: Likewise. 158123 * testsuite/gas/riscv/option-arch-02.s: Likewise. 158124 * testsuite/gas/riscv/option-arch-fail.d: Likewise. 158125 * testsuite/gas/riscv/option-arch-fail.l: Likewise. 158126 * testsuite/gas/riscv/option-arch-fail.s: Likewise. 158127 1581282021-11-19 Alan Modra <amodra@gmail.com> 158129 158130 Re: Add multibyte character warning option to the assembler. 158131 On hppa*-hp-hpux* run_dump_test edits the test file, adjusting .comm 158132 directives to suit those target's unusual syntax. Thus gas is passed 158133 a temporary file name. 158134 158135 * testsuite/gas/all/multibyte1.l: Ignore file name. 158136 1581372021-11-19 Mike Frysinger <vapier@gentoo.org> 158138 158139 sim: install various doc files 158140 1581412021-11-19 Nelson Chu <nelson.chu@sifive.com> 158142 158143 RISC-V: Support STO_RISCV_VARIANT_CC and DT_RISCV_VARIANT_CC. 158144 This is the original discussion, 158145 https://github.com/riscv/riscv-elf-psabi-doc/pull/190 158146 158147 And here is the glibc part, 158148 https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html 158149 158150 For binutils part, we need to support a new direcitve: .variant_cc. 158151 The function symbol marked by .variant_cc means it need to be resolved 158152 directly without resolver for dynamic linker. We also add a new dynamic 158153 entry, STO_RISCV_VARIANT_CC, to indicate there are symbols with the 158154 special attribute in the dynamic symbol table of the object. 158155 158156 I heard that llvm already have supported this in their mainline, so 158157 I think it's time to commit this. 158158 158159 bfd/ 158160 * elfnn-riscv.c (riscv_elf_link_hash_table): Added variant_cc 158161 flag. It is used to check if relocations for variant CC symbols 158162 may be present. 158163 (allocate_dynrelocs): If the symbol has STO_RISCV_VARIANT_CC 158164 flag, then raise the variant_cc flag of riscv_elf_link_hash_table. 158165 (riscv_elf_size_dynamic_sections): Added dynamic entry for 158166 variant_cc. 158167 (riscv_elf_merge_symbol_attribute): New function, used to merge 158168 non-visibility st_other attributes, including STO_RISCV_VARIANT_CC. 158169 binutils/ 158170 * readelf.c (get_riscv_dynamic_type): New function. 158171 (get_dynamic_type): Called get_riscv_dynamic_type for riscv targets. 158172 (get_riscv_symbol_other): New function. 158173 (get_symbol_other): Called get_riscv_symbol_other for riscv targets. 158174 gas/ 158175 * config/tc-riscv.c (s_variant_cc): Marked symbol that it follows a 158176 variant CC convention. 158177 (riscv_elf_copy_symbol_attributes): Same as elf_copy_symbol_attributes, 158178 but without copying st_other. If a function symbol has special st_other 158179 value set via directives, then attaching an IFUNC resolver to that symbol 158180 should not override the st_other setting. 158181 (riscv_pseudo_table): Support variant_cc diretive. 158182 * config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Defined. 158183 * testsuite/gas/riscv/variant_cc-set.d: New testcase. 158184 * testsuite/gas/riscv/variant_cc-set.s: Likewise. 158185 * testsuite/gas/riscv/variant_cc.d: Likewise. 158186 * testsuite/gas/riscv/variant_cc.s: Likewise. 158187 include/ 158188 * elf/riscv.h (DT_RISCV_VARIANT_CC): Defined to (DT_LOPROC + 1). 158189 (STO_RISCV_VARIANT_CC): Defined to 0x80. 158190 ld/ 158191 * testsuite/ld-riscv-elf/variant_cc-1.s: New testcase. 158192 * testsuite/ld-riscv-elf/variant_cc-2.s: Likewise. 158193 * testsuite/ld-riscv-elf/variant_cc-now.d: Likewise. 158194 * testsuite/ld-riscv-elf/variant_cc-r.d: Likewise. 158195 * testsuite/ld-riscv-elf/variant_cc-shared.d: Likewise. 158196 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 158197 1581982021-11-19 Mike Frysinger <vapier@gentoo.org> 158199 158200 sim: use program_transform_name for libsim 158201 Instead of always using target_alias as a prefix on the name, use 158202 program_transform_name instead so that the library is scoped in the 158203 same way as the run program. 158204 158205 sim: avoid installing headers when there is no sim 158206 If we aren't building any sims, don't install the sim headers as they 158207 won't be useful to anyone. 158208 1582092021-11-19 GDB Administrator <gdbadmin@sourceware.org> 158210 158211 Automatic date update in version.in 158212 1582132021-11-18 Kevin Buettner <kevinb@redhat.com> 158214 158215 dprintf-execution-x-script.exp: Adjust test for native-extended-gdbserver 158216 Without this commit, doing... 158217 158218 make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \ 158219 TESTS="gdb.base/dprintf-execution-x-script.exp" 158220 158221 ...will show one failure. 158222 158223 Here's a snippet from gdb.log showing the circumstances - I've trimmed 158224 the paths for readability: 158225 158226 builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script 158227 ... 158228 Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script... 158229 Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38. 158230 Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26. 158231 testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file: 158232 Don't know how to run. Try "help target". 158233 (gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x 158234 ... 158235 GNU gdb (GDB) 12.0.50.20211118-git 158236 Copyright (C) 2021 Free Software Foundation, Inc. 158237 ... 158238 (gdb) set height 0 158239 (gdb) set width 0 158240 (gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346 158241 Listening on port 2346 158242 target extended-remote localhost:2346 158243 Remote debugging using localhost:2346 158244 ... 158245 [Tests after this point will pass.] 158246 158247 Note that the command which spawns gdb prevents the gdb script from 158248 using the native target via "-iex set auto-connect-native-target off". 158249 158250 Moreover, the script in question contains a "run" command, so GDB 158251 doesn't know how to run (since it's prevented from using the native 158252 target and no alternate "target" command has been issued. But, once 158253 GDB finishes starting up, the test will spawn a gdbserver and then 158254 connect to it. The other (two) tests after this point both pass. 158255 158256 I've fixed this by using gdb_test_multiple instead of gdb_test. 158257 When a "Don't know how to run message" is received, the test is 158258 unsupported. 158259 158260 I've also added a comment explaining the reason for needing to check 158261 for "Don't know how to run" despite bailing out at the top of the test 158262 via: 158263 158264 if ![target_can_use_run_cmd] { 158265 return 0 158266 } 158267 1582682021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158269 158270 gdb: fix array-view-selftests.c build with g++ 4.8 158271 When building with g++ 4.8, I get: 158272 158273 CXX unittests/array-view-selftests.o 158274 /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:123:42: error: expected 'class' before 'Container' 158275 template<template<typename ...> typename Container> 158276 ^ 158277 158278 I am no C++ template expert, but it looks like if I change "typename" for 158279 "class", as the compiler kind of suggests, the code compiles. 158280 158281 Change-Id: I9c3edd29fb2b190069f0ce0dbf3bc3604d175f48 158282 1582832021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158284 158285 gdb: fix ia64-tdep.c build with g++ 4.8 158286 When building with g++ 4.8, I get: 158287 158288 CXX ia64-tdep.o 158289 /home/smarchi/src/binutils-gdb/gdb/ia64-tdep.c:3862:1: error: could not convert '{ia64_allocate_new_rse_frame, ia64_store_argument_in_slot, ia64_set_function_addr}' from '<brace 158290 -enclosed initializer list>' to 'const ia64_infcall_ops' 158291 }; 158292 ^ 158293 158294 This happens since commit 345bd07cce3 ("gdb: fix gdbarch_tdep ODR 158295 violation"), which added default values for ia64_infcall_ops fields. It 158296 looks like g++ 4.8 doesn't like initializing the ia64_infcall_ops object 158297 using the brace-enclosed initializer list when the ia64_infcall_ops 158298 fields are assigned default values. 158299 158300 Later compilers don't have a problem with that, so I suppose that the 158301 code is correct, but still, change it to make gcc 4.8 happy. Don't 158302 initialize the fields of ia64_infcall_ops directly, instead 158303 default-initialize ia64_gdbarch_tdep::infcall_ops. 158304 158305 Change-Id: I35e3a61abd7b7bbcafe6cb207078c738c5266d76 158306 1583072021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158308 158309 gdb: move AIX_TEXT_SEGMENT_BASE to rs6000-aix-tdep.c, remove rs6000-tdep.h 158310 The contents of rs6000-tdep.h (AIX_TEXT_SEGMENT_BASE) is AIX-specific, 158311 so I thought that this file should be named rs6000-aix-tdep.h. But 158312 there's already a rs6000-aix-tdep.h, so then I though 158313 AIX_TEXT_SEGMENT_BASE should simply be moved there, and rs6000-tdep.h 158314 deleted. But then I realized that AIX_TEXT_SEGMENT_BASE is only used in 158315 rs6000-aix-tdep.c, so move it to the beginning of that file. 158316 158317 Change-Id: Ia212c6fae202f31aedb46575821cd642beeda7a3 158318 1583192021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158320 158321 gdb: rename rs6000-nat.c to rs6000-aix-nat.c 158322 This file seems to be AIX-specific, according to its contents and 158323 configure.nat. Rename it to rs6000-aix-nat.c, to make that clear (and 158324 to follow the convention). 158325 158326 Change-Id: Ib418dddc6b79b2e28f64431121742b5e87f5f4f5 158327 1583282021-11-18 Tom de Vries <tdevries@suse.de> 158329 158330 [gdb/doc] Fix negative repeat count examining memory example 158331 The documentation for the examining memory command x contains an example: 158332 ... 158333 You can also specify a negative repeat count to examine memory backward from 158334 the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h) 158335 at 0x54314, 0x54328, and 0x5431c. 158336 ... 158337 158338 The 0x54328 looks like a typo, which was intended to be 0x54318. 158339 158340 But the series uses a 4-byte distance, while the halfword size used in the 158341 command means a 2-byte distance, so the series should be: 158342 ... 158343 0x5431a, 0x5431c, and 0x5431e. 158344 ... 158345 158346 Fix this by updating the addresses in the example accordingly. 158347 158348 Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html 158349 ). 158350 1583512021-11-18 Nick Clifton <nickc@redhat.com> 158352 158353 Add multibyte character warning option to the assembler. 158354 * as.c (parse_args): Add support for --multibyte-handling. 158355 * as.h (multibyte_handling): Declare. 158356 * app.c (scan_for_multibyte_characters): New function. 158357 (do_scrub_chars): Call the new function if multibyte warning is 158358 enabled. 158359 * input-scrub,c (input_scrub_next_buffer): Call the multibyte 158360 scanning function if multibyte warnings are enabled. 158361 * symbols.c (struct symbol_flags): Add multibyte_warned bit. 158362 (symbol_init): Call the multibyte scanning function if multibyte 158363 symbol warnings are enabled. 158364 (S_SET_SEGMENT): Likewise. 158365 * NEWS: Mention the new feature. 158366 * doc/as.texi: Document the new feature. 158367 * testsuite/gas/all/multibyte.s: New test source file. 158368 * testsuite/gas/all/multibyte1.d: New test driver file. 158369 * testsuite/gas/all/multibyte1.l: New test expected output. 158370 * testsuite/gas/all/multibyte2.d: New test driver file. 158371 * testsuite/gas/all/multibyte2.l: New test expected output. 158372 * testsuite/gas/all/gas.exp: Run the new tests. 158373 1583742021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158375 158376 gdb: include gdbarch.h in all files extending gdbarch_tdep 158377 Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") made a bunch 158378 of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep 158379 base. But some of these files don't include gdbarch.h, where 158380 gdbarch_tdep is defined. This may cause build errors if gdbarch.h isn't 158381 already included by chance by some other header file. Avoid this by 158382 making them include gdbarch.h. 158383 158384 Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a 158385 1583862021-11-18 Simon Marchi <simon.marchi@polymtl.ca> 158387 158388 gdbsupport: make gdb_assert_not_reached accept a format string 158389 Change gdb_assert_not_reached to accept a format string plus 158390 corresponding arguments. This allows giving more precise messages. 158391 158392 Because the format string passed by the caller is prepended with a "%s:" 158393 to add the function name, the callers can no longer pass a translated 158394 string (`_(...)`). Make the gdb_assert_not_reached include the _(), 158395 just like the gdb_assert_fail macro just above. 158396 158397 Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7 158398 1583992021-11-18 Carl Love <cel@us.ibm.com> 158400 158401 gdb fix for catch-syscall.exp 158402 Remove check_continue "execve" from Proc test_catch_syscall_execve. 158403 158404 The check_continue proceedure checs that the command, execve, starts and 158405 checks for the return from the command. The execve command starts a new 158406 program and thus the return from the command causing the test to fail. 158407 158408 The call to proc check_continue "execve" is removed and replaced with 158409 just the call to check_call_to_syscall "execve" to verify the command 158410 executed. The next test in proc test_catch_syscall_execve verifies that 158411 the new program started and hit the break point in main. 158412 158413 Update the check for the PowerPC architecture. Power Little Endian systems 158414 include "le" in the name. The istarget "power64-*-linux*" check fails to 158415 match LE sytems. The expected string is updated to capture both Big Endian 158416 and Little Endian systems. Power 10 LE istarget prints as: 158417 powerpc64le-unknown-linux-gnu. 158418 158419 This patch fixes three failures and the error: 158420 158421 ERROR: can't read "arch1": no such variable 158422 158423 Patch tested on Power 10 ppc64le GNU/Linux platform. 158424 1584252021-11-18 Carl Love <cel@us.ibm.com> 158426 158427 gdb: PowerPC fix gdb.base/break-interp.exp 158428 This patch fixes eight test failures on PowerPC for the test 158429 gdb.base/break-interp.exp. The patch adds a funtion and registers it to 158430 setup the displaced stepping for ppc-linux platform. The patch moves the 158431 struct ppc_inferior_data to the ppc-tdep.h include file to make it visible 158432 to the ppc-linux-tdep.c and rs6000-tdep.c files. Additionally the function 158433 get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in 158434 both files. 158435 158436 Tested on Power 10 ppc64le-linux with no regressions. 158437 1584382021-11-18 Carl Love <cel@us.ibm.com> 158439 158440 gdb fix PowerPC test gdb.arch/ppc-longdouble.exp 158441 The test complains of duplicate tests. 158442 158443 DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return 158444 158445 The do_test calls gdb_continue_to_breakpoint "return". The duplicates 158446 are the result of calling do_test three times with different arguments. 158447 158448 This patch fixes the duplicate tests by adding $name to the 158449 gdb_continue_to_breakpoint argument. 158450 158451 Patch tested on Power 10 ppc64le GNU/Linux, no duplicate tests reported, 158452 no new regression errors. 158453 1584542021-11-18 H.J. Lu <hjl.tools@gmail.com> 158455 158456 elf/x86: Issue an error on discarded output .plt section 158457 Issue an error, instead of crash, on discarded output .plt section. 158458 158459 bfd/ 158460 158461 PR ld/28597 158462 * elf32-i386.c (elf_i386_finish_dynamic_sections): Issue an error 158463 on discarded output .plt section. 158464 * elf64-x86-64.c (elf_x86_64_finish_dynamic_sections): Likewise. 158465 158466 ld/ 158467 158468 PR ld/28597 158469 * testsuite/ld-elf/pr28597.d: New file. 158470 * testsuite/ld-elf/pr28597.s: Likewise. 158471 * testsuite/ld-elf/pr28597.t: Likewise. 158472 1584732021-11-18 Tom de Vries <tdevries@suse.de> 158474 158475 [gdb/testsuite] Add missing wait in gdb.base/signals-state-child.exp 158476 On OBS I ran into: 158477 ... 158478 (gdb) shell diff -s outputs/gdb.base/signals-state-child/standalone.txt \ 158479 outputs/gdb.base/signals-state-child/gdb.txt^M 158480 diff: outputs/gdb.base/signals-state-child/standalone.txt: \ 158481 No such file or directory^M 158482 (gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical 158483 ... 158484 158485 I managed to reproduce this by adding "sleep (5)" at the start of main in 158486 signals-state-child.c. 158487 158488 Fix this by waiting on the result of the spawned command. 158489 158490 Tested on x86_64-linux. 158491 1584922021-11-18 Alan Modra <amodra@gmail.com> 158493 158494 Re: Don't compile some opcodes files when bfd is 32-bit only 158495 Put bpf back in the 32-bit targets, even though bpf requires a 64-bit 158496 bfd. bpf sim support apparently works without being 64-bit. 158497 158498 * Makefile.am (TARGET64_LIBOPCODES_CFILES): Move bpf files.. 158499 (TARGET32_LIBOPCODES_CFILES): ..to here. 158500 * Makefile.in: Regenerate. 158501 1585022021-11-18 Alan Modra <amodra@gmail.com> 158503 158504 Pass DEBUGINFOD_CFLAGS when compiling dwarf.c 158505 Pick up the elfutils/debuginfod.h install location -I flags from 158506 a variable set by debuginfod.m4 (via pkg.m4 and pkg-config). 158507 158508 * Makefile.am (DEBUGINFOD_CFLAGS): Define. 158509 (dwarf.@OBJECT@): New rule. 158510 1585112021-11-18 jiawei <jiawei@iscas.ac.cn> 158512 158513 RISC-V: Add testcases for z[fdq]inx 158514 Use gpr when the zfinx enable, the testcases contain float 158515 instructions that reuse by z[fdq]inx. 158516 158517 gas/ChangeLog: 158518 158519 * testsuite/gas/riscv/zdinx.d: New test. 158520 * testsuite/gas/riscv/zdinx.s: New test. 158521 * testsuite/gas/riscv/zfinx.d: New test. 158522 * testsuite/gas/riscv/zfinx.s: New test. 158523 * testsuite/gas/riscv/zqinx.d: New test. 158524 * testsuite/gas/riscv/zqinx.s: New test. 158525 158526 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 158527 1585282021-11-18 jiawei <jiawei@iscas.ac.cn> 158529 158530 RISC-V: Add instructions and operand set for z[fdq]inx 158531 Reuse float instructions in INSN_CLASS_F/D/Q, use riscv_subset_supports to 158532 verify if z*inx enabled and use gpr instead of fpr when z*inx is enable. 158533 158534 bfd/ChangeLog: 158535 158536 * elfxx-riscv.c (riscv_multi_subset_supports): Added support for 158537 z*inx extension. 158538 158539 gas/ChangeLog: 158540 158541 * config/tc-riscv.c (riscv_ip): Added register choice for z*inx. 158542 158543 include/ChangeLog: 158544 158545 * opcode/riscv.h (enum riscv_insn_class): Reused INSN_CLASS_* for z*inx. 158546 158547 opcodes/ChangeLog: 158548 158549 * riscv-dis.c (riscv_disassemble_insn): Added disassemble check for 158550 z*inx. 158551 * riscv-opc.c: Reused INSN_CLASS_* for z*inx. 158552 158553 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 158554 1585552021-11-18 jiawei <jiawei@iscas.ac.cn> 158556 158557 RISC-V: Add mininal support for z[fdq]inx 158558 Minimal support for zfinx, zdinx, zqinx. Like f/d/q, the zqinx 158559 imply zdinx and zdinx imply zfinx, where zfinx are not compatible 158560 with f/d/q. 158561 158562 bfd/ChangeLog: 158563 158564 * elfxx-riscv.c (riscv_implicit_subsets): Added implicit rules 158565 for z*inx extensions. 158566 (riscv_supported_std_z_ext): Added entries for z*inx. 158567 (riscv_parse_check_conflicts): Added conflict check for z*inx. 158568 158569 Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> 158570 1585712021-11-18 GDB Administrator <gdbadmin@sourceware.org> 158572 158573 Automatic date update in version.in 158574 1585752021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158576 158577 aarch64: [SME] SVE2 instructions added to support SME 158578 This patch is adding new SVE2 instructions added to support SME extension. 158579 The following SVE2 instructions are added by the SME architecture: 158580 * PSEL, 158581 * REVD, SCLAMP and UCLAMP. 158582 158583 gas/ChangeLog: 158584 158585 * config/tc-aarch64.c (parse_sme_pred_reg_with_index): 158586 New parser. 158587 (parse_operands): New parser. 158588 * testsuite/gas/aarch64/sme-9-illegal.d: New test. 158589 * testsuite/gas/aarch64/sme-9-illegal.l: New test. 158590 * testsuite/gas/aarch64/sme-9-illegal.s: New test. 158591 * testsuite/gas/aarch64/sme-9.d: New test. 158592 * testsuite/gas/aarch64/sme-9.s: New test. 158593 158594 include/ChangeLog: 158595 158596 * opcode/aarch64.h (enum aarch64_opnd): New operand 158597 AARCH64_OPND_SME_PnT_Wm_imm. 158598 158599 opcodes/ChangeLog: 158600 158601 * aarch64-asm.c (aarch64_ins_sme_pred_reg_with_index): 158602 New inserter. 158603 * aarch64-dis.c (aarch64_ext_sme_pred_reg_with_index): 158604 New extractor. 158605 * aarch64-opc.c (aarch64_print_operand): Printout of 158606 OPND_SME_PnT_Wm_imm. 158607 * aarch64-opc.h (enum aarch64_field_kind): New bitfields 158608 FLD_SME_Rm, FLD_SME_i1, FLD_SME_tszh, FLD_SME_tszl. 158609 * aarch64-tbl.h (OP_SVE_NN_BHSD): New qualifier. 158610 (OP_SVE_QMQ): New qualifier. 158611 (struct aarch64_opcode): New instructions PSEL, REVD, 158612 SCLAMP and UCLAMP. 158613 aarch64-asm-2.c: Regenerate. 158614 aarch64-dis-2.c: Regenerate. 158615 aarch64-opc-2.c: Regenerate. 158616 1586172021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158618 158619 aarch64: [SME] Add new SME system registers 158620 This patch is adding miscellaneous SME related system registers. 158621 158622 gas/ChangeLog: 158623 158624 * testsuite/gas/aarch64/sme-sysreg.d: New test. 158625 * testsuite/gas/aarch64/sme-sysreg.s: New test. 158626 * testsuite/gas/aarch64/sme-sysreg-illegal.d: New test. 158627 * testsuite/gas/aarch64/sme-sysreg-illegal.l: New test. 158628 * testsuite/gas/aarch64/sme-sysreg-illegal.s: New test. 158629 158630 opcodes/ChangeLog: 158631 158632 * aarch64-opc.c: New system registers id_aa64smfr0_el1, 158633 smcr_el1, smcr_el12, smcr_el2, smcr_el3, smpri_el1, 158634 smprimap_el2, smidr_el1, tpidr2_el0 and mpamsm_el1. 158635 1586362021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158637 158638 aarch64: [SME] Add SME mode selection and state access instructions 158639 This patch is adding new SME mode selection and state access instructions: 158640 * Add SMSTART and SMSTOP instructions. 158641 * Add SVCR system register. 158642 158643 gas/ChangeLog: 158644 158645 * config/tc-aarch64.c (parse_sme_sm_za): New parser. 158646 (parse_operands): New parser. 158647 * testsuite/gas/aarch64/sme-8-illegal.d: New test. 158648 * testsuite/gas/aarch64/sme-8-illegal.l: New test. 158649 * testsuite/gas/aarch64/sme-8-illegal.s: New test. 158650 * testsuite/gas/aarch64/sme-8.d: New test. 158651 * testsuite/gas/aarch64/sme-8.s: New test. 158652 158653 include/ChangeLog: 158654 158655 * opcode/aarch64.h (enum aarch64_opnd): New operand 158656 AARCH64_OPND_SME_SM_ZA. 158657 (enum aarch64_insn_class): New instruction classes 158658 sme_start and sme_stop. 158659 158660 opcodes/ChangeLog: 158661 158662 * aarch64-asm.c (aarch64_ins_pstatefield): New inserter. 158663 (aarch64_ins_sme_sm_za): New inserter. 158664 * aarch64-dis.c (aarch64_ext_imm): New extractor. 158665 (aarch64_ext_pstatefield): New extractor. 158666 (aarch64_ext_sme_sm_za): New extractor. 158667 * aarch64-opc.c (operand_general_constraint_met_p): 158668 New pstatefield value for SME instructions. 158669 (aarch64_print_operand): Printout for OPND_SME_SM_ZA. 158670 (SR_SME): New register SVCR. 158671 * aarch64-opc.h (F_REG_IN_CRM): New register endcoding. 158672 * aarch64-opc.h (F_IMM_IN_CRM): New immediate endcoding. 158673 (PSTATE_ENCODE_CRM): Encode CRm field. 158674 (PSTATE_DECODE_CRM): Decode CRm field. 158675 (PSTATE_ENCODE_CRM_IMM): Encode CRm immediate field. 158676 (PSTATE_DECODE_CRM_IMM): Decode CRm immediate field. 158677 (PSTATE_ENCODE_CRM_AND_IMM): Encode CRm and immediate 158678 field. 158679 * aarch64-tbl.h (struct aarch64_opcode): New SMSTART 158680 and SMSTOP instructions. 158681 aarch64-asm-2.c: Regenerate. 158682 aarch64-dis-2.c: Regenerate. 158683 aarch64-opc-2.c: Regenerate. 158684 1586852021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158686 158687 aarch64: [SME] Add LD1x, ST1x, LDR and STR instructions 158688 This patch is adding new loads and stores defined by SME instructions. 158689 158690 gas/ChangeLog: 158691 158692 * config/tc-aarch64.c (parse_sme_address): New parser. 158693 (parse_sme_za_hv_tiles_operand_with_braces): New parser. 158694 (parse_sme_za_array): New parser. 158695 (output_operand_error_record): Print error details if 158696 present. 158697 (parse_operands): Support new operands. 158698 * testsuite/gas/aarch64/sme-5-illegal.d: New test. 158699 * testsuite/gas/aarch64/sme-5-illegal.l: New test. 158700 * testsuite/gas/aarch64/sme-5-illegal.s: New test. 158701 * testsuite/gas/aarch64/sme-5.d: New test. 158702 * testsuite/gas/aarch64/sme-5.s: New test. 158703 * testsuite/gas/aarch64/sme-6-illegal.d: New test. 158704 * testsuite/gas/aarch64/sme-6-illegal.l: New test. 158705 * testsuite/gas/aarch64/sme-6-illegal.s: New test. 158706 * testsuite/gas/aarch64/sme-6.d: New test. 158707 * testsuite/gas/aarch64/sme-6.s: New test. 158708 * testsuite/gas/aarch64/sme-7-illegal.d: New test. 158709 * testsuite/gas/aarch64/sme-7-illegal.l: New test. 158710 * testsuite/gas/aarch64/sme-7-illegal.s: New test. 158711 * testsuite/gas/aarch64/sme-7.d: New test. 158712 * testsuite/gas/aarch64/sme-7.s: New test. 158713 158714 include/ChangeLog: 158715 158716 * opcode/aarch64.h (enum aarch64_opnd): New operands. 158717 (enum aarch64_insn_class): Added sme_ldr and sme_str. 158718 (AARCH64_OPDE_UNTIED_IMMS): New operand error kind. 158719 158720 opcodes/ChangeLog: 158721 158722 * aarch64-asm.c (aarch64_ins_sme_za_hv_tiles): New inserter. 158723 (aarch64_ins_sme_za_list): New inserter. 158724 (aarch64_ins_sme_za_array): New inserter. 158725 (aarch64_ins_sme_addr_ri_u4xvl): New inserter. 158726 * aarch64-asm.h (AARCH64_DECL_OPD_INSERTER): Added 158727 ins_sme_za_list, ins_sme_za_array and ins_sme_addr_ri_u4xvl. 158728 * aarch64-dis.c (aarch64_ext_sme_za_hv_tiles): New extractor. 158729 (aarch64_ext_sme_za_list): New extractor. 158730 (aarch64_ext_sme_za_array): New extractor. 158731 (aarch64_ext_sme_addr_ri_u4xvl): New extractor. 158732 * aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR): Added 158733 ext_sme_za_list, ext_sme_za_array and ext_sme_addr_ri_u4xvl. 158734 * aarch64-opc.c (operand_general_constraint_met_p): 158735 (aarch64_match_operands_constraint): Handle sme_ldr, sme_str 158736 and sme_misc. 158737 (aarch64_print_operand): New operands supported. 158738 * aarch64-tbl.h (OP_SVE_QUU): New qualifier. 158739 (OP_SVE_QZU): New qualifier. 158740 aarch64-asm-2.c: Regenerate. 158741 aarch64-dis-2.c: Regenerate. 158742 aarch64-opc-2.c: Regenerate. 158743 1587442021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158745 158746 aarch64: [SME] Add ZERO instruction 158747 This patch is adding ZERO (a list of 64-bit element ZA tiles) 158748 instruction. 158749 158750 gas/ChangeLog: 158751 158752 * config/tc-aarch64.c (parse_sme_list_of_64bit_tiles): 158753 New parser. 158754 (parse_operands): Handle OPND_SME_list_of_64bit_tiles. 158755 * testsuite/gas/aarch64/sme-4-illegal.d: New test. 158756 * testsuite/gas/aarch64/sme-4-illegal.l: New test. 158757 * testsuite/gas/aarch64/sme-4-illegal.s: New test. 158758 * testsuite/gas/aarch64/sme-4.d: New test. 158759 * testsuite/gas/aarch64/sme-4.s: New test. 158760 158761 include/ChangeLog: 158762 158763 * opcode/aarch64.h (enum aarch64_opnd): New operand 158764 AARCH64_OPND_SME_list_of_64bit_tiles. 158765 158766 opcodes/ChangeLog: 158767 158768 * aarch64-opc.c (print_sme_za_list): New printing function. 158769 (aarch64_print_operand): Handle OPND_SME_list_of_64bit_tiles. 158770 * aarch64-opc.h (enum aarch64_field_kind): New bitfield 158771 FLD_SME_zero_mask. 158772 * aarch64-tbl.h (struct aarch64_opcode): New ZERO instruction. 158773 aarch64-asm-2.c: Regenerate. 158774 aarch64-dis-2.c: Regenerate. 158775 aarch64-opc-2.c: Regenerate. 158776 1587772021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158778 158779 aarch64: [SME] Add MOV and MOVA instructions 158780 This patch is adding new MOV (alias) and MOVA SME instruction. 158781 158782 gas/ChangeLog: 158783 158784 * config/tc-aarch64.c (enum sme_hv_slice): new enum. 158785 (struct reloc_entry): Added ZAH and ZAV registers. 158786 (parse_sme_immediate): Immediate parser. 158787 (parse_sme_za_hv_tiles_operand): ZA tile parser. 158788 (parse_sme_za_hv_tiles_operand_index): Index parser. 158789 (parse_operands): Added ZA tile parser calls. 158790 (REGNUMS): New macro. Regs with suffix. 158791 (REGSET16S): New macro. 16 regs with suffix. 158792 * testsuite/gas/aarch64/sme-2-illegal.d: New test. 158793 * testsuite/gas/aarch64/sme-2-illegal.l: New test. 158794 * testsuite/gas/aarch64/sme-2-illegal.s: New test. 158795 * testsuite/gas/aarch64/sme-2.d: New test. 158796 * testsuite/gas/aarch64/sme-2.s: New test. 158797 * testsuite/gas/aarch64/sme-2a.d: New test. 158798 * testsuite/gas/aarch64/sme-2a.s: New test. 158799 * testsuite/gas/aarch64/sme-3-illegal.d: New test. 158800 * testsuite/gas/aarch64/sme-3-illegal.l: New test. 158801 * testsuite/gas/aarch64/sme-3-illegal.s: New test. 158802 * testsuite/gas/aarch64/sme-3.d: New test. 158803 * testsuite/gas/aarch64/sme-3.s: New test. 158804 * testsuite/gas/aarch64/sme-3a.d: New test. 158805 * testsuite/gas/aarch64/sme-3a.s: New test. 158806 158807 include/ChangeLog: 158808 158809 * opcode/aarch64.h (enum aarch64_opnd): New enums 158810 AARCH64_OPND_SME_ZA_HV_idx_src and 158811 AARCH64_OPND_SME_ZA_HV_idx_dest. 158812 (struct aarch64_opnd_info): New ZA tile vector struct. 158813 158814 opcodes/ChangeLog: 158815 158816 * aarch64-asm.c (aarch64_ins_sme_za_hv_tiles): 158817 New inserter. 158818 * aarch64-asm.h (AARCH64_DECL_OPD_INSERTER): 158819 New inserter ins_sme_za_hv_tiles. 158820 * aarch64-dis.c (aarch64_ext_sme_za_hv_tiles): 158821 New extractor. 158822 * aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR): 158823 New extractor ext_sme_za_hv_tiles. 158824 * aarch64-opc.c (aarch64_print_operand): 158825 Handle SME_ZA_HV_idx_src and SME_ZA_HV_idx_dest. 158826 * aarch64-opc.h (enum aarch64_field_kind): New enums 158827 FLD_SME_size_10, FLD_SME_Q, FLD_SME_V and FLD_SME_Rv. 158828 (struct aarch64_operand): Increase fields size to 5. 158829 * aarch64-tbl.h (OP_SME_BHSDQ_PM_BHSDQ): New qualifiers 158830 aarch64-asm-2.c: Regenerate. 158831 aarch64-dis-2.c: Regenerate. 158832 aarch64-opc-2.c: Regenerate. 158833 1588342021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158835 158836 aarch64: [SME] Add SME instructions 158837 Patch is adding new SME matrix instructions. Please note additional 158838 instructions will be added in following patches. 158839 158840 gas/ChangeLog: 158841 158842 * config/tc-aarch64.c (parse_sme_zada_operand): 158843 New parser. 158844 * config/tc-aarch64.c (parse_reg_with_qual): 158845 New reg parser. 158846 * config/tc-aarch64.c (R_ZA): New egister type. 158847 (parse_operands): New parser. 158848 * testsuite/gas/aarch64/sme-illegal.d: New test. 158849 * testsuite/gas/aarch64/sme-illegal.l: New test. 158850 * testsuite/gas/aarch64/sme-illegal.s: New test. 158851 * testsuite/gas/aarch64/sme.d: New test. 158852 * testsuite/gas/aarch64/sme.s: New test. 158853 * testsuite/gas/aarch64/sme-f64.d: New test. 158854 * testsuite/gas/aarch64/sme-f64.s: New test. 158855 * testsuite/gas/aarch64/sme-i64.d: New test. 158856 * testsuite/gas/aarch64/sme-i64.s: New test. 158857 158858 include/ChangeLog: 158859 158860 * opcode/aarch64.h (enum aarch64_opnd): New operands 158861 AARCH64_OPND_SME_ZAda_2b, AARCH64_OPND_SME_ZAda_3b and 158862 AARCH64_OPND_SME_Pm. 158863 (enum aarch64_insn_class): New instruction class sme_misc. 158864 158865 opcodes/ChangeLog: 158866 158867 * aarch64-opc.c (aarch64_print_operand): 158868 Print OPND_SME_ZAda_2b and OPND_SME_ZAda_3b operands. 158869 (verify_constraints): Handle OPND_SME_Pm. 158870 * aarch64-opc.h (enum aarch64_field_kind): 158871 New bit fields FLD_SME_ZAda_2b, FLD_SME_ZAda_3b and FLD_SME_Pm. 158872 * aarch64-tbl.h (OP_SME_ZADA_PN_PM_ZN_S): New qualifier set. 158873 (OP_SME_ZADA_PN_PM_ZN_D): New qualifier. 158874 (OP_SME_ZADA_PN_PM_ZN_ZM): New qualifier. 158875 (OP_SME_ZADA_S_PM_PM_S_S): New qualifier. 158876 (OP_SME_ZADA_D_PM_PM_D_D): New qualifier. 158877 (OP_SME_ZADA_S_PM_PM_H_H): New qualifier. 158878 (OP_SME_ZADA_S_PM_PM_B_B): New qualifier. 158879 (OP_SME_ZADA_D_PM_PM_H_H): New qualifier. 158880 (SME_INSN): New instruction macro. 158881 (SME_F64_INSN): New instruction macro. 158882 (SME_I64_INSN): New instruction macro. 158883 (SME_INSNC): New instruction macro. 158884 (struct aarch64_opcode): New SME instructions. 158885 aarch64-asm-2.c: Regenerate. 158886 aarch64-dis-2.c: Regenerate. 158887 aarch64-opc-2.c: Regenerate. 158888 1588892021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 158890 158891 aarch64: [SME] Add +sme option to -march 158892 This series of patches (tagged [SME]) add support for the Scalable 158893 Matrix Extension. Patch introduces new command line options: +sme, +sme-f64 and 158894 +sme-i64 to -march command line options. 158895 158896 gas/ChangeLog: 158897 158898 * NEWS: Updated docs. 158899 * config/tc-aarch64.c: New SME command line options. 158900 * doc/c-aarch64.texi: Update docs. 158901 158902 include/ChangeLog: 158903 158904 * opcode/aarch64.h (AARCH64_FEATURE_SME): New flag. 158905 (AARCH64_FEATURE_SME_F64): New flag. 158906 (AARCH64_FEATURE_SME_I64): New flag. 158907 158908 opcodes/ChangeLog: 158909 158910 * aarch64-tbl.h (SME): New feature object. 158911 1589122021-11-17 Jeremy Drake <cygwin@jdrake.com> 158913 158914 Set the default DLL chracteristics to 0 for Cygwin based targets. 158915 * emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Set to 0 for 158916 Cygwin targets. 158917 * emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Likewise. 158918 1589192021-11-17 Nick Clifton <nickc@redhat.com> 158920 158921 Fix the linker script parser so that it will recognise the PT_GNU_RELRO segment type, and the linker itself so that it will gracefully handle being unable to assign any sections to such a segment. 158922 PR 28452 158923 bfd * elf.c (assign_file_positions_for_non_load_sections): Replace 158924 assertion with a warning message. 158925 158926 ld * ldgram.y: Add support for PT_GNU_RELRO and PT_GNU_PROPERTY. 158927 * ldgram.c: Regenerate. 158928 1589292021-11-17 Andreas Arnez <arnez@linux.ibm.com> 158930 158931 [gdb/build, s390x] Fix build after gdbarch_tdep changes 158932 Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") changes a 158933 declaration in s390-tdep.h from 158934 158935 struct gdbarch_tdep { ... }; 158936 158937 to 158938 158939 struct s390_gdbarch_tdep : gdbarch_tdep { ... }; 158940 158941 and now requires that gdbarch_tdep has been declared before. Which is 158942 usually the case, except when compiling s390-linux-nat.c, where 158943 s390-tdep.h is included before gdbarch.h. Thus the s390x build errors out 158944 with the compiler complaining about a missing class name after the colon. 158945 158946 Fix this in s390-linux-nat.c, by including gdbarch.h before s390-tdep.h. 158947 1589482021-11-17 Luis Machado <luis.machado@linaro.org> 158949 158950 Expose the BTI BTYPE more explicitly in the registers 158951 Augment the register description XML to expose the BTI BTYPE field contained 158952 in the CPSR register. It will be displayed like so: 158953 158954 cpsr 0x60001000 [ EL=0 BTYPE=0 SSBS C Z ] 158955 1589562021-11-17 H.J. Lu <hjl.tools@gmail.com> 158957 158958 elfedit: Add --output-abiversion option to update ABIVERSION 158959 * NEWS: Mention --output-abiversion. 158960 * elfedit.c (input_elf_abiversion): New. 158961 (output_elf_abiversion): Likewise. 158962 (update_elf_header): Update EI_ABIVERSION. 158963 (command_line_switch): Add OPTION_INPUT_ABIVERSION and 158964 OPTION_OUTPUT_ABIVERSION. 158965 (options): Add --input-abiversion and --output-abiversion. 158966 (usage): Likewise. 158967 (main): Handle --input-abiversion and --output-abiversion. 158968 * doc/binutils.texi: Document --input-abiversion and 158969 --output-abiversion. 158970 * testsuite/binutils-all/elfedit.exp: Run elfedit-6. 158971 * testsuite/binutils-all/elfedit-6.d: New file. 158972 1589732021-11-17 Nelson Chu <nelson.chu@sifive.com> 158974 158975 RISC-V: Support rvv extension with released version 1.0. 158976 2021-11-17 Jim Wilson <jimw@sifive.com> 158977 Kito Cheng <kito.cheng@sifive.com> 158978 Nelson Chu <nelson.chu@sifive.com> 158979 158980 This patch is porting from the following riscv github, 158981 https://github.com/riscv/riscv-binutils-gdb/tree/rvv-1.0.x 158982 158983 And here is the vector spec, 158984 https://github.com/riscv/riscv-v-spec 158985 158986 bfd/ 158987 * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules 158988 of v, zve and zvl extensions. 158989 (riscv_supported_std_ext): Updated verison of v to 1.0. 158990 (riscv_supported_std_z_ext): Added zve and zvl extensions. 158991 (riscv_parse_check_conflicts): The zvl extensions need to 158992 enable either v or zve extension. 158993 (riscv_multi_subset_supports): Check the subset list to know 158994 if the INSN_CLASS_V and INSN_CLASS_ZVEF instructions are supported. 158995 gas/ 158996 * config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_V. 158997 (enum reg_class): Added RCLASS_VECR and RCLASS_VECM. 158998 (validate_riscv_insn): Check whether the rvv operands are valid. 158999 (md_begin): Initialize register hash for rvv registers. 159000 (macro_build): Added rvv operands when expanding rvv pseudoes. 159001 (vector_macro): Expand rvv macros into one or more instructions. 159002 (macro): Likewise. 159003 (my_getVsetvliExpression): Similar to my_getVsetvliExpression, 159004 but used for parsing vsetvli operands. 159005 (riscv_ip): Parse and encode rvv operands. Besides, The rvv loads 159006 and stores with EEW 64 cannot be used when zve32x is enabled. 159007 * testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated -march 159008 to rv32ifv_zkr. 159009 * testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise. 159010 * testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise. 159011 * testsuite/gas/riscv/priv-reg.s: Added rvv csr testcases. 159012 * testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise. 159013 * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise. 159014 * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise. 159015 * testsuite/gas/riscv/march-imply-v.d: New testcase. 159016 * testsuite/gas/riscv/vector-insns-fail-zve32xf.d: Likewise. 159017 * testsuite/gas/riscv/vector-insns-fail-zve32xf.l: Likewise. 159018 * testsuite/gas/riscv/vector-insns-fail-zvl.d: Likewise. 159019 * testsuite/gas/riscv/vector-insns-fail-zvl.l: Likewise. 159020 * testsuite/gas/riscv/vector-insns-vmsgtvx.d: Likewise. 159021 * testsuite/gas/riscv/vector-insns-vmsgtvx.s: Likewise. 159022 * testsuite/gas/riscv/vector-insns-zero-imm.d: Likewise. 159023 * testsuite/gas/riscv/vector-insns-zero-imm.s: Likewise. 159024 * testsuite/gas/riscv/vector-insns.d: Likewise. 159025 * testsuite/gas/riscv/vector-insns.s: Likewise. 159026 include/ 159027 * opcode/riscv-opc.h: Defined mask/match encodings and csrs for rvv. 159028 * opcode/riscv.h: Defined rvv immediate encodings and fields. 159029 (enum riscv_insn_class): Added INSN_CLASS_V and INSN_CLASS_ZVEF. 159030 (INSN_V_EEW64): Defined. 159031 (M_VMSGE, M_VMSGEU): Added for the rvv pseudoes. 159032 opcodes/ 159033 * riscv-dis.c (print_insn_args): Dump the rvv operands. 159034 * riscv-opc.c (riscv_vecr_names_numeric): Defined rvv registers. 159035 (riscv_vecm_names_numeric): Likewise. 159036 (riscv_vsew): Likewise. 159037 (riscv_vlmul): Likewise. 159038 (riscv_vta): Likewise. 159039 (riscv_vma): Likewise. 159040 (match_vs1_eq_vs2): Added for rvv Vu operand. 159041 (match_vd_eq_vs1_eq_vs2): Added for rvv Vv operand. 159042 (riscv_opcodes): Added rvv v1.0 instructions. 159043 1590442021-11-17 Sergei Trofimovich <siarheit@google.com> 159045 159046 gdb/nat/linux-osdata.c: fix build on gcc-12 (string overfow) 159047 On gcc-12 build fails as: 159048 159049 ../../gdbserver/../gdb/nat/linux-osdata.c: In function 'void linux_xfer_osdata_processes(buffer*)': 159050 ../../gdbserver/../gdb/nat/linux-osdata.c:330:39: error: 159051 '__builtin___sprintf_chk' may write a terminating nul past the end of the destination [-Werror=format-overflow=] 159052 330 | sprintf (core_str, "%d", i); 159053 | ^ 159054 159055 It's an off-by-one case in an infeasible scenario for negative 159056 huge core count. The change switches to std::string for memory 159057 handling. 159058 159059 Tested by running 'info os processes' and checking CPU cores column. 159060 1590612021-11-17 Aaron Merey <amerey@redhat.com> 159062 159063 gdb: Add aliases for read_core_file_mappings callbacks 159064 Add aliases read_core_file_mappings_loop_ftype and 159065 read_core_file_mappings_pre_loop_ftype. Intended for use with 159066 read_core_file_mappings. 159067 159068 Also add build_id parameter to read_core_file_mappings_loop_ftype. 159069 1590702021-11-17 Mike Frysinger <vapier@gentoo.org> 159071 159072 sim: testsuite: add support for $pwd replacements 159073 Extend the common test framework to support $pwd replacements in 159074 settings. This allows replacing the custom cris @exedir@ with it. 159075 159076 sim: cris: replace @srcdir@ test extension with $srcdir/$subdir 159077 The common framework supports $srcdir & $subdir replacements already, 159078 so replace the custom @srcdir@ logic with those. Since the replace 159079 happens in slurp_options that cris already uses, we don't have any 159080 logic to port over there. We have to duplicate that into the cris 159081 slurp_rv helper though. 159082 1590832021-11-17 Mike Frysinger <vapier@gentoo.org> 159084 159085 sim: cris: drop custom "dynamic" test field 159086 This tag is used to force tests to be built dynamically (i.e. without 159087 -static linking). This is because cris-sim.exp in dejagnu turns on 159088 static linking in ldflags. 159089 159090 The default configs and runtest flags shouldn't load these boards. 159091 If these settings are still needed, we should figure out a different 159092 way of suppressing the stock settings wholesale. We want these to 159093 all pass out of the box with little to no configuration so that they 159094 can run in a multitarget build. 159095 159096 With dropping "dynamic", it'll be easier to merge the custom cris 159097 test logic with the common sim test logic. 159098 1590992021-11-17 Mike Frysinger <vapier@gentoo.org> 159100 159101 sim: testsuite: add more silent build rules 159102 site.exp is still verbose, but that comes from automake, so have 159103 to get it fixed upstream. 159104 1591052021-11-17 GDB Administrator <gdbadmin@sourceware.org> 159106 159107 Automatic date update in version.in 159108 1591092021-11-16 Sergei Trofimovich <siarheit@google.com> 159110 159111 sim: cr16: fix build on gcc-12 (NULL comparison) 159112 On gcc-12 build fails as: 159113 159114 sim/cr16/interp.c: In function 'lookup_hash': 159115 sim/cr16/interp.c:89:25: error: 159116 the comparison will always evaluate as 'true' 159117 for the address of 'mnimonic' will never be NULL [-Werror=address] 159118 89 | if ((h->ops->mnimonic != NULL) && 159119 | ^~ 159120 159121 'mnimonic' is a sharr array within ops. It can never be NULL. 159122 159123 While at it renamed 'mnimonic' to 'mnemonic'. 159124 1591252021-11-16 Simon Marchi <simon.marchi@polymtl.ca> 159126 159127 gdb: fix length of array view returned by some value_contents functions 159128 In commit 50888e42dcd3 ("gdb: change functions returning value contents 159129 to use gdb::array_view"), I believe I made a mistake with the length of 159130 the array views returned by some functions. All functions return a view 159131 of `TYPE_LENGTH (value_type (type))` length. This is not correct when 159132 the value's enclosing type is larger than the value's type. In that 159133 case, the value's contents buffer is of the size of the enclosing type, 159134 and the value's actual contents is a slice of that (as returned by 159135 value_contents). So, functions value_contents_all_raw, 159136 value_contents_for_printing and value_contents_for_printing_const are 159137 not correct. Since they are meant to return the value's contents buffer 159138 as a whole, they should have the size of the enclosing type. 159139 159140 There is nothing that uses the returned array view size at the moment, 159141 so this didn't cause a problem. But it became apparent when trying to 159142 adjust some callers. 159143 159144 Change-Id: Ib4e8837e1069111d2b2784d3253d5f3002419e68 159145 1591462021-11-16 Fangrui Song <maskray@google.com> 159147 159148 readelf: Support SHT_RELR/DT_RELR for -r 159149 The -r output for SHT_RELR looks like: 159150 159151 Relocation section '.relr.dyn' at offset 0x530 contains 4 entries: 159152 7 offsets 159153 00000000000028c0 159154 00000000000028c8 159155 0000000000003ad0 159156 0000000000003ad8 159157 0000000000003ae0 159158 0000000000003ae8 159159 0000000000003af0 159160 159161 For --use-dynamic, the header looks like 159162 159163 'RELR' relocation section at offset 0x530 contains 32 bytes: 159164 159165 include/ 159166 * elf/common.h (DT_ENCODING): Bump to 38. 159167 * elf/external.h (Elf32_External_Relr): New. 159168 (Elf64_External_Relr): New. 159169 binutils/ 159170 * readelf.c (enum relocation_type): New. 159171 (slurp_relr_relocs): New. 159172 (dump_relocations): Change is_rela to rel_type. 159173 Dump RELR. 159174 (dynamic_relocations): Add DT_RELR. 159175 (process_relocs): Check SHT_RELR and DT_RELR. 159176 (process_dynamic_section): Store into dynamic_info for 159177 DT_RELR/DT_RELRENT/DT_RELRSZ. 159178 1591792021-11-16 Simon Marchi <simon.marchi@polymtl.ca> 159180 159181 gdbsupport: remove FUNCTION_NAME 159182 __func__ is standard C++11: 159183 159184 https://en.cppreference.com/w/cpp/language/function 159185 159186 Also, in C++11, __func__ expands to the demangled function name, so the 159187 mention in the comment above FUNCTION_NAME doesn't apply anymore. 159188 Finally, in places where FUNCTION_NAME is used, I think it's enough to 159189 print the function name, no need to print the whole signature. 159190 Therefore, I propose to just remove FUNCTION_NAME and update users to 159191 use the standard __func__. 159192 159193 Change-Id: I778f28155422b044402442dc18d42d0cded1017d 159194 1591952021-11-16 Andrew Burgess <aburgess@redhat.com> 159196 159197 gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr 159198 The motivation is to reduce the number of places where unmanaged 159199 pointers are returned from allocation type routines. All of the 159200 callers are updated. 159201 159202 There should be no user visible changes after this commit. 159203 1592042021-11-16 Andrew Burgess <aburgess@redhat.com> 159205 159206 gdbsupport: move xfree into its own file 159207 In the next commit I'd like to reference gdb_unique_ptr within the 159208 common-utils.h file. However, this requires that I include 159209 gdb_unique_ptr.h, which requires that xfree be defined. 159210 159211 Interestingly, gdb_unique_ptr.h doesn't actually include anything that 159212 defines xfree, but I was finding that when I added a gdb_unique_ptr.h 159213 include to common-utils.h I was getting a dependency cycle; before my 159214 change xfree was defined when gdb_unique_ptr.h was processed, while 159215 after my change it was not, and this made g++ unhappy. 159216 159217 To break this cycle, I propose to move xfree into its own header file, 159218 gdb-xfree.h, which I'll then include into gdb_unique_ptr.h and 159219 common-utils.cc. 159220 1592212021-11-16 Andrew Burgess <aburgess@redhat.com> 159222 159223 gdb: throw OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR 159224 While reviewing this patch: 159225 159226 https://sourceware.org/pipermail/gdb-patches/2021-November/183227.html 159227 159228 I spotted that the patch could be improved if we threw 159229 OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR in a few places. 159230 159231 This commit updates error_value_optimized_out and 159232 require_not_optimized_out to throw OPTIMIZED_OUT_ERROR. 159233 159234 I ran the testsuite and saw no regressions. This doesn't really 159235 surprise me, we don't usually write code like: 159236 159237 catch (const gdb_exception_error &ex) 159238 { 159239 (if ex.error == GENERIC_ERROR) 159240 ... 159241 else 159242 ... 159243 } 159244 159245 There are a three places where we write something like: 159246 159247 catch (const gdb_exception_error &ex) 159248 { 159249 (if ex.error == OPTIMIZED_OUT_ERROR) 159250 ... 159251 } 159252 159253 In frame.c:unwind_pc, stack.c:info_frame_command_core, and 159254 value.c:value_optimized_out, but if we are hitting these cases then 159255 it's not significantly changing GDB's behaviour. 159256 1592572021-11-16 Tom Tromey <tromey@adacore.com> 159258 159259 Remove config.cache in gdbserver's "distclean" 159260 PR gdb/28586 points out that "make distclean" fails to delete 159261 config.cache from gdbserver/. This patch fixes the bug, and removes a 159262 duplicate "Makefile" deletion that was also pointed out in the PR. 159263 1592642021-11-16 Tom de Vries <tdevries@suse.de> 159265 159266 [gdb/testsuite] Remove inferior output in gdb.base/foll-vfork.exp 159267 Test-case gdb.base/foll-vfork.exp has inferior output that is not needed, but 159268 which makes the regexp matching more difficult (see commit 1f28b70def1 159269 "[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp"). 159270 159271 Remove the inferior output, and revert commit 1f28b70def1 to make the matching 159272 more restrictive. 159273 159274 Tested on x86_64-linux. 159275 1592762021-11-16 H.J. Lu <hjl.tools@gmail.com> 159277 159278 x86: Don't allow KMOV in TLS code sequences 159279 Don't allow KMOV in TLS code sequences which require integer MOV 159280 instructions. 159281 159282 PR target/28595 159283 * config/tc-i386.c (match_template): Don't allow KMOV in TLS 159284 code sequences. 159285 * testsuite/gas/i386/i386.exp: Run inval-tls and x86-64-inval-tls 159286 tests. 159287 * testsuite/gas/i386/inval-tls.l: New file. 159288 * testsuite/gas/i386/inval-tls.s: Likewise. 159289 * testsuite/gas/i386/x86-64-inval-tls.l: Likewise. 159290 * testsuite/gas/i386/x86-64-inval-tls.s: Likewise. 159291 1592922021-11-16 Mike Frysinger <vapier@gentoo.org> 159293 159294 sim: run: support concise env var settings 159295 Support the same syntax as other common utilities where env vars can 159296 be specified before the program to be run without an explicit option. 159297 159298 This behavior can be suppressed by using the -- marker. 159299 1593002021-11-16 Mike Frysinger <vapier@gentoo.org> 159301 159302 sim: nrun: add --env-{set,unset,clear} command line options 159303 Provide explicit control over the program's environment with the 159304 basic set/unset/clear options. These are a bit clunky to use, 159305 but they're functional. 159306 159307 The env set operation is split out into a separate function as it'll 159308 be used in the next commit. 159309 159310 With these in place, we can adjust the custom cris testsuite to use 159311 the now standard options and not its one-off hack. 159312 1593132021-11-16 Mike Frysinger <vapier@gentoo.org> 159314 159315 sim: syscall: hoist argc/argn/argnlen to common code 159316 Now that the callback framework supports argv & envp, we can move 159317 the Blackfin implementation of these syscalls to the common code. 159318 159319 sim: syscall: fix argvlen & argv implementation 159320 Now that we have access to the argv & envp strings, finish implementing 159321 these syscalls. Delete unused variables, fix tbuf by incrementing the 159322 pointer instead of setting to the length, and make sure we don't write 159323 more data than the bufsize says is available. 159324 159325 sim: callback: expose argv & environ 159326 Pass the existing strings data to the callbacks so that common 159327 libgloss syscalls can be implemented (which we'll do shortly). 159328 1593292021-11-16 Mike Frysinger <vapier@gentoo.org> 159330 159331 sim: keep track of program environment strings 159332 We've been passing the environment strings to sim_create_inferior, 159333 but most ports don't do anything with them. A few will use ad-hoc 159334 logic to stuff the stack for user-mode programs, but that's it. 159335 159336 Let's formalize this across the board by storing the strings in the 159337 normal sim state. This will allow (in future commits) supporting 159338 more functionality in the run interface, and to unify some of the 159339 libgloss syscalls. 159340 1593412021-11-16 Mike Frysinger <vapier@gentoo.org> 159342 159343 sim: iq2000: fix some missing prototypes warnings 159344 Turns out some of these were hiding real bugs like not passing the 159345 pc variable down. 159346 1593472021-11-16 jiawei <jiawei@iscas.ac.cn> 159348 159349 RISC-V: Scalar crypto instruction and entropy source CSR testcases. 159350 Add testcases for Scalar Crypto extension, with total testcase contain all 159351 instructions in k-ext/k-ext-64 and sub-extension testcase for zbk* zk*. Also 159352 add testcase for new CSR name 'seed' which is the Entropy Source in zkr. 159353 159354 In fact these whole testcases can be combined into one file, after we have 159355 supported the .option arch +-= directives. 159356 159357 gas/ 159358 * testsuite/gas/riscv/k-ext-64.d: New testcase for crypto instructions. 159359 * testsuite/gas/riscv/k-ext-64.s: Likewise. 159360 * testsuite/gas/riscv/k-ext.d: Likewise. 159361 * testsuite/gas/riscv/k-ext.s: Likewise. 159362 * testsuite/gas/riscv/zbkb-32.d: Likewise. 159363 * testsuite/gas/riscv/zbkb-32.s: Likewise. 159364 * testsuite/gas/riscv/zbkb-64.d: Likewise. 159365 * testsuite/gas/riscv/zbkb-64.s: Likewise. 159366 * testsuite/gas/riscv/zbkc-32.d: Likewise. 159367 * testsuite/gas/riscv/zbkc-64.d: Likewise. 159368 * testsuite/gas/riscv/zbkc.s: Likewise. 159369 * testsuite/gas/riscv/zbkx-32.d: Likewise. 159370 * testsuite/gas/riscv/zbkx-64.d: Likewise. 159371 * testsuite/gas/riscv/zbkx.s: Likewise. 159372 * testsuite/gas/riscv/zknd-32.d: Likewise. 159373 * testsuite/gas/riscv/zknd-32.s: Likewise. 159374 * testsuite/gas/riscv/zknd-64.d: Likewise. 159375 * testsuite/gas/riscv/zknd-64.s: Likewise. 159376 * testsuite/gas/riscv/zkne-32.d: Likewise. 159377 * testsuite/gas/riscv/zkne-32.s: Likewise. 159378 * testsuite/gas/riscv/zkne-64.d: Likewise. 159379 * testsuite/gas/riscv/zkne-64.s: Likewise. 159380 * testsuite/gas/riscv/zknh-32.d: Likewise. 159381 * testsuite/gas/riscv/zknh-32.s: Likewise. 159382 * testsuite/gas/riscv/zknh-64.d: Likewise. 159383 * testsuite/gas/riscv/zknh-64.s: Likewise. 159384 * testsuite/gas/riscv/zksed-32.d: Likewise. 159385 * testsuite/gas/riscv/zksed-64.d: Likewise. 159386 * testsuite/gas/riscv/zksed.s: Likewise. 159387 * testsuite/gas/riscv/zksh-32.d: Likewise. 159388 * testsuite/gas/riscv/zksh-64.d: Likewise. 159389 * testsuite/gas/riscv/zksh.s: Likewise. 159390 * testsuite/gas/riscv/priv-reg-fail-zkr.d: New testcase for zkr 159391 csr check. 159392 * testsuite/gas/riscv/priv-reg-fail-zkr.l: Likewise. 159393 * testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated march to 159394 rv32if_zkr. 159395 * testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise. 159396 * testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise. 159397 * testsuite/gas/riscv/priv-reg-version-1p10.d: Added Crypto seed csr. 159398 * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise. 159399 * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise. 159400 * testsuite/gas/riscv/priv-reg.s: Likewise. 159401 1594022021-11-16 jiawei <jiawei@iscas.ac.cn> 159403 159404 RISC-V: Scalar crypto instructions and operand set. 159405 Add instructions in k-ext, some instruction in zbkb, zbkc is reuse from 159406 zbb,zbc, we just change the class attribute to make them both support. 159407 The 'aes64ks1i' and 'aes64ks2' instructions are present in both the Zknd 159408 and Zkne extensions on rv64. Add new operand letter 'y' to present 'bs' 159409 symbol and 'Y' to present 'rnum' symbolc for zkn instructions. Also add 159410 a new Entropy Source CSR define 'seed' located at address 0x015. 159411 159412 bfd/ 159413 * elfxx-riscv.c (riscv_multi_subset_supports): Added support for 159414 crypto extension. 159415 gas/ 159416 *config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_ZKR. 159417 (riscv_csr_address): Checked for CSR_CLASS_ZKR. 159418 (validate_riscv_insn): Added y and Y for bs and rnum operands. 159419 (riscv_ip): Handle y and Y operands. 159420 include/ 159421 * opcode/riscv-opc.h: Added encodings of crypto instructions. 159422 Also defined new csr seed, which address is 0x15. 159423 * opcode/riscv.h: Defined OP_* and INSN_CLASS_* for crypto. 159424 opcodes/ 159425 * riscv-dis.c (print_insn_args): Recognized new y and Y operands. 159426 * riscv-opc.c (riscv_opcodes): Added crypto instructions. 159427 1594282021-11-16 jiawei <jiawei@iscas.ac.cn> 159429 159430 RISC-V: Minimal support of scalar crypto extension. 159431 Minimal support of scalar crypto extension, add "k" in the 159432 riscv_supported_std_ext, to make the order check right with 159433 "zk" behind "zb". 159434 159435 bfd/ 159436 * elfxx-riscv.c (riscv_implicit_subsets): Added implicit 159437 rules for zk* extensions. 159438 (riscv_supported_std_ext): Added entry for k. 159439 (riscv_supported_std_z_ext): Added entries for zk*. 159440 1594412021-11-16 Simon Marchi <simon.marchi@efficios.com> 159442 159443 gdb: rework "set debuginfod" commands 159444 As discussed here [1], do some re-work in the "set debuginfod commands". 159445 159446 First, use "set debuginfod enabled on/off/ask" instead of "set 159447 debuginfod on/off/ask". This is more MI-friendly, and it gives an 159448 output that makes more sense in "info set", for example. 159449 159450 Then, make the show commands not call "error" when debuginfod support is 159451 not compiled in. This makes the commands "show" and "show debuginfod" 159452 stop early, breaking gdb.base/default.exp: 159453 159454 Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ... 159455 FAIL: gdb.base/default.exp: info set 159456 FAIL: gdb.base/default.exp: show 159457 159458 - Make the "debuginfod enabled" setting default to "off" when debuginfod 159459 support is not compiled in, and "ask" otherwise. 159460 - Make the setter of "debuginfod enabled" error out when debuginfod 159461 support is not compiled in, so that "debuginfod enabled" will always 159462 remain "off" in that case. 159463 - Make the setter of "debuginfod verbose" work in any case. I don't 159464 see the harm in letting the user change that setting, since the user will 159465 hit an error if they try to enable the use of debuginfod. 159466 - I would do the same for the "debuginfod urls" setter, but because 159467 this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by 159468 libdebuginfod, I made that one error out as well if debuginfod 159469 support is not compiled it (otherwise, I would have left it like 159470 "debuginfod verbose". Alternatively, we could hard-code 159471 "DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch, 159472 but I think it was an oversight, as other spots use 159473 DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting, 159474 but I don't really see the value in that. 159475 159476 Rename debuginfod_enable to debuginfod_enabled, just so it matches the 159477 setting name. 159478 159479 [1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html 159480 159481 Change-Id: I45fdb2993f668226a5639228951362b7800f09d5 159482 Co-Authored-By: Aaron Merey <amerey@redhat.com> 159483 1594842021-11-16 Simon Marchi <simon.marchi@polymtl.ca> 159485 159486 gdb: adjust gdbarch_tdep calls in nat files 159487 Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") forgot to 159488 update the gdbarch_tdep calls in the native files other than x86-64 159489 Linux. This patch updates them all (to the best of my knowledge). 159490 These are the files I was able to build-test: 159491 159492 aarch64-linux-nat.c 159493 amd64-bsd-nat.c 159494 arm-linux-nat.c 159495 ppc-linux-nat.c 159496 windows-nat.c 159497 xtensa-linux-nat.c 159498 159499 And these are the ones I could not build-test: 159500 159501 aix-thread.c 159502 arm-netbsd-nat.c 159503 ppc-fbsd-nat.c 159504 ppc-netbsd-nat.c 159505 ia64-tdep.c (the part that needs libunwind) 159506 ppc-obsd-nat.c 159507 rs6000-nat.c 159508 159509 If there are still some build problems related to gdbarch_tdep in them, 159510 they should be pretty obvious to fix. 159511 159512 Change-Id: Iaa3d791a850e4432973757598e634e3da6061428 159513 1595142021-11-16 Simon Marchi <simon.marchi@polymtl.ca> 159515 159516 gdb: remove unused variables in xtensa-linux-nat.c 159517 While build-testing this file, the compiler complained about these two 159518 unused variables, remove them. 159519 159520 Change-Id: I3c54f779f12c16ef6184af58aca75eaad042ce4e 159521 1595222021-11-16 Simon Marchi <simon.marchi@polymtl.ca> 159523 159524 gdb: add arc-newlib-tdep.c to ALL_TARGET_OBS 159525 This file is currently not compiled in an --enable-targets=all build, 159526 but it should be. Add it to ALL_TARGET_OBS. 159527 159528 Update the gdbarch_tdep call that commit 345bd07cce33 ("gdb: fix 159529 gdbarch_tdep ODR violation") forgot to update. 159530 159531 Change-Id: I86248a01493eea5e70186e9c46a298ad3994b034 159532 1595332021-11-16 Jim Wilson <wilson@tuliptree.org> 159534 159535 Update my email address. 159536 I've left SiFive and have a new gmail account because it is convenient 159537 to use with git send-email. I'm planning to use this for my RISC-V 159538 work. My tuliptree address still works, it just isn't as convenient. 159539 159540 binutils: 159541 * MAINTAINERS (RISC-V): Update my address. 159542 1595432021-11-16 GDB Administrator <gdbadmin@sourceware.org> 159544 159545 Automatic date update in version.in 159546 1595472021-11-15 Tom de Vries <tdevries@suse.de> 159548 159549 [gdb] Don't use gdb_stdlog for inferior-events 159550 The test-case gdb.base/foll-vfork.exp contains: 159551 ... 159552 if [gdb_debug_enabled] { 159553 untested "debug is enabled" 159554 return 0 159555 } 159556 ... 159557 159558 To understand what it does, I disabled this bit and ran with GDB_DEBUG=infrun, 159559 like so: 159560 ... 159561 $ cd $build/gdb/testsuite 159562 $ make check GDB_DEBUG=infrun RUNTESTFLAGS=gdb.base/foll-vfork.exp 159563 ... 159564 and ran into: 159565 ... 159566 (gdb) PASS: gdb.base/foll-vfork.exp: exec: \ 159567 vfork parent follow, through step: set follow-fork parent 159568 next^M 159569 33 if (pid == 0) {^M 159570 (gdb) FAIL: gdb.base/foll-vfork.exp: exec: \ 159571 vfork parent follow, through step: step 159572 ... 159573 159574 The problem is that the test-case expects: 159575 ... 159576 (gdb) PASS: gdb.base/foll-vfork.exp: exec: \ 159577 vfork parent follow, through step: set follow-fork parent 159578 next^M 159579 [Detaching after vfork from child process 28169]^M 159580 33 if (pid == 0) {^M 159581 (gdb) PASS: gdb.base/foll-vfork.exp: exec: \ 159582 vfork parent follow, through step: step 159583 ... 159584 but the "Detaching" line has been redirected to 159585 $outputs/gdb.base/foll-vfork/gdb.debug. 159586 159587 I looked at the documentation of "set logging debugredirect [on|off]": 159588 ... 159589 By default, GDB debug output will go to both the terminal and the logfile. 159590 Set debugredirect if you want debug output to go only to the log file. 159591 ... 159592 and my interpretation of it was that "debug output" did not match the 159593 "messages" description of inferior-events: 159594 ... 159595 The set print inferior-events command allows you to enable or disable printing 159596 of messages when GDB notices that new inferiors have started or that inferiors 159597 have exited or have been detached. 159598 ... 159599 159600 Fix the discrepancy by not using gdb_stdlog for inferior-events. 159601 159602 Update the gdb.base/foll-vfork.exp test-case to not require 159603 gdb_debug_enabled == 0. 159604 159605 Tested on x86_64-linux. 159606 159607 Tested test-case gdb.base/foll-vfork.exp with and without GDB_DEBUG=infrun. 159608 1596092021-11-15 Roland McGrath <mcgrathr@google.com> 159610 159611 ld: Fix testsuite failures under --enable-textrel-check=error 159612 ld/ 159613 * testsuite/ld-aarch64/dt_textrel.d: Pass explicit -z notext in 159614 case ld was configured with --enable-textrel-check=error. 159615 * testsuite/ld-aarch64/pr22764.d: Likewise. 159616 * testsuite/ld-aarch64/pr20402.d: Likewise. 159617 1596182021-11-15 Luis Machado <luis.machado@linaro.org> 159619 159620 Extend the prologue analyzer to handle the bti instruction 159621 Handle the BTI instruction in the prologue analyzer. The patch handles all 159622 the variations of the BTI instruction. 159623 1596242021-11-15 Simon Marchi <simon.marchi@polymtl.ca> 159625 159626 gdb: fix gdbarch_tdep ODR violation 159627 I would like to be able to use non-trivial types in gdbarch_tdep types. 159628 This is not possible at the moment (in theory), because of the one 159629 definition rule. 159630 159631 To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and 159632 make them inherit from a gdbarch_tdep base class. The inheritance is 159633 necessary to be able to pass pointers to all these <arch>_gdbarch_tdep 159634 objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep. 159635 159636 These objects are never deleted through a base class pointer, so I 159637 didn't include a virtual destructor. In the future, if gdbarch objects 159638 deletable, I could imagine that the gdbarch_tdep objects could become 159639 owned by the gdbarch objects, and then it would become useful to have a 159640 virtual destructor (so that the gdbarch object can delete the owned 159641 gdbarch_tdep object). But that's not necessary right now. 159642 159643 It turns out that RISC-V already has a gdbarch_tdep that is 159644 non-default-constructible, so that provides a good motivation for this 159645 change. 159646 159647 Most changes are fairly straightforward, mostly needing to add some 159648 casts all over the place. There is however the xtensa architecture, 159649 doing its own little weird thing to define its gdbarch_tdep. I did my 159650 best to adapt it, but I can't test those changes. 159651 159652 Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b 159653 1596542021-11-15 Clément Chigot <clement.chigot@atos.net> 159655 159656 COFF: avoid modifications over C_FILE filename aux entries. 159657 Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file 159658 on XCOFF") introduces C_FILE entries which can store additional 159659 information. 159660 However, some modifications are needed by them but not by the original 159661 C_FILE entries, usually representing the filename. 159662 This patch ensures that filename entries are kept as is, in order to 159663 protect targets not supporting the additional entries. 159664 159665 * coffgen.c (coff_write_symbol): Protect filename entries 159666 (coff_write_symbols): Likewise. 159667 (coff_print_symbol): Likewise. 159668 1596692021-11-15 Eric Botcazou <ebotcazou@gcc.gnu.org> 159670 159671 Deal with full path in .file 0 directive 159672 Gas uses the directory part, if present, of the .file 0 directive to set 159673 entry 0 of the directory table in DWARF 5, which represents the "current 159674 directory". 159675 159676 Now Gas also uses the file part of the same directive to set entry 0 of the 159677 file table, which represents the "current compilation file". But the latter 159678 need not be located in the former so GCC will use a full path in the file 159679 part when it is passed a full path: 159680 159681 gcc -c /full/path/test.c -save-temps 159682 159683 yields: 159684 159685 .file 0 "/current/directory" "/full/path/test.c" 159686 159687 in the assembly file and: 159688 159689 The Directory Table (offset 0x22, lines 2, columns 1): 159690 Entry Name 159691 0 (indirect line string, offset: 0x25): /current/directory 159692 1 (indirect line string, offset: 0x38): /full/path 159693 159694 The File Name Table (offset 0x30, lines 2, columns 2): 159695 Entry Dir Name 159696 0 0 (indirect line string, offset: 0x43): /full/path/test.c 159697 159698 in the object file. Note the full path and the questionable Dir value in 159699 the 0 entry of the file table. 159700 1597012021-11-15 Mike Frysinger <vapier@gentoo.org> 159702 159703 sim: cris: make error message test a little more flexible 159704 The point of this test is to just make sure the usage text is shown, 159705 not the exact details of the usage text. So shorten the output test 159706 to match the beginning. This fixes breakage when the output changed 159707 slightly to include [--]. 159708 159709 sim: run: fix crash in argc==0 error situation 159710 The new argv processing code assumed that we were always passed a 159711 command line. If we weren't, make sure we don't crash before we 159712 get a chance to output an error message about incorrect usage. 159713 159714 sim: cris: touch up rvdummy handling 159715 Add quiet build support and make sure it's removed with `make clean`. 159716 159717 sim: cris: replace custom "dest" test field with new --argv0 159718 The #dest field used in the cris testsuite is a bit of hack to set the 159719 argv[0] for the tests to read out later on. Now that the sim has an 159720 option to set argv[0] explicitly, we don't need this custom field, so 159721 let's drop it to harmonize the testsuites a little. 159722 159723 sim: run: add --argv0 option to control argv[0] 159724 We default argv[0] to the program we run which is a standard *NIX 159725 convention, but sometimes we want to be able to control the argv[0] 159726 setting independently (especially for programs that inspect argv[0] 159727 to change their behavior or output). Add an option to control it. 159728 1597292021-11-15 Mike Frysinger <vapier@gentoo.org> 159730 159731 sim: split program path out of argv vector 159732 We use the program argv to both find the program to run (argv[0]) and 159733 to hold the arguments to the program. Most of the time this is fine, 159734 but if we want to let programs specify argv[0] independently (which is 159735 possible in standard *NIX programs), this double duty doesn't work. 159736 159737 So let's split the path to the program to run out into a separate 159738 field by itself. This simplifies the various sim_open funcs too. 159739 159740 By itself, this code is more of a logical cleanup than something that 159741 is super useful. But it will open up customization of argv[0] in a 159742 follow up commit. Split the changes to make it easier to review. 159743 1597442021-11-15 Mike Frysinger <vapier@gentoo.org> 159745 159746 sim: bfin: fix mach/xfail usage in tests 159747 Set the mach to the right value all the time, and update xfail to 159748 say the test fails on all targets. WIth multitarget testing, the 159749 idea of target here doesn't make much sense. 159750 1597512021-11-15 Alan Modra <amodra@gmail.com> 159752 159753 -Waddress fixes for gold testsuite 159754 Current mainline gcc. 159755 common_test_1.c: In function 'main': 159756 common_test_1.c:56:14: error: comparison between two arrays [-Werror=array-compare] 159757 56 | assert (c5 > c4); 159758 | ^ 159759 common_test_1.c:56:14: note: use '&c5[0] > &c4[0]' to compare the addresses 159760 159761 * testsuite/common_test_1.c: Avoid -Waddress warnings. 159762 * testsuite/common_test_1_v1.c: Likewise. 159763 * testsuite/common_test_1_v2.c: Likewise. 159764 * testsuite/script_test_2.cc: Likewise. 159765 1597662021-11-15 Alan Modra <amodra@gmail.com> 159767 159768 PowerPC64 @notoc in non-power10 code 159769 R_PPC64_REL24_P9NOTOC is a variant of R_PPC64_REL24_NOTOC for use on 159770 @notoc cals from non-power10 code in the rare case that using such a 159771 construct is useful. R_PPC64_REL24_P9NOTOC will be emitted by gas 159772 rather than R_PPC64_REL24_NOTOC when @notoc is used in a branch 159773 instruction if power10 instructions are not enabled at that point. 159774 The new relocation tells the linker to not use power10 instructions on 159775 any stub emitted for that branch, unless overridden by 159776 --power10-stubs=yes. 159777 159778 The current linker heuristic of only generating power10 instructions 159779 for stubs if power10-only relocations are detected, continues to be 159780 used. 159781 159782 include/ 159783 * elf/ppc64.h (R_PPC64_REL24_P9NOTOC): Define. 159784 bfd/ 159785 * reloc.c (BFD_RELOC_PPC64_REL24_P9NOTOC): Define. 159786 * elf64-ppc.c (ppc64_elf_howto_raw): Add entry for new reloc. 159787 (ppc64_elf_reloc_type_lookup): Handle it. 159788 (enum ppc_stub_type): Delete. 159789 (enum ppc_stub_main_type, ppc_stub_sub_type): New. 159790 (struct ppc_stub_type): New. 159791 (struct ppc_stub_hash_entry): Use the above new type. 159792 (struct ppc_link_hash_table): Update stub_count. 159793 (is_branch_reloc, ppc64_elf_check_relocs), 159794 (toc_adjusting_stub_needed): Handle new reloc. 159795 (stub_hash_newfunc, select_alt_stub, ppc_merge_stub), 159796 (ppc_type_of_stub, plt_stub_size, build_plt_stub), 159797 (build_tls_get_addr_head, build_tls_get_addr_tail), 159798 (ppc_build_one_stub, ppc_size_one_stub, ppc64_elf_size_stubs), 159799 (ppc64_elf_build_stubs, ppc64_elf_relocate_section): Handle new 159800 reloc. Modify stub handling to suit new scheme. 159801 * bfd-in2.h: Regenerate. 159802 * libbfd.h: Regenerate. 159803 gas/ 159804 * config/tc-ppc.c (ppc_elf_suffix): When power10 is not enabled 159805 return BFD_RELOC_PPC64_REL24_P9NOTOC for @notoc. 159806 (fixup_size, ppc_force_relocation, ppc_fix_adjustable): Handle 159807 BFD_RELOC_PPC64_REL24_P9NOTOC. 159808 ld/ 159809 * testsuite/ld-powerpc/callstub-2.s: Add .machine power10. 159810 1598112021-11-15 Alan Modra <amodra@gmail.com> 159812 159813 Regenerate a couple of files 159814 A couple of files changed on my latest --enable-maintainer-mode 159815 build. ld/Makefile.in had a missing dependency but better sorting of 159816 the loongson entries. 159817 159818 intl/ 159819 * configure: Regenerate. 159820 ld/ 159821 * Makefile.am: Sort loongson entries. 159822 * Makefile.in: Regenerate. 159823 1598242021-11-15 Pedro Alves <pedro@palves.net> 159825 159826 Fix build with current GCC: EL_EXPLICIT(location) always non-NULL 159827 Compiling GDB with current GCC (1b4a63593b) runs into this: 159828 159829 src/gdb/location.c: In function 'int event_location_empty_p(const event_location*)': 159830 src/gdb/location.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' will never be NULL [-Werror=address] 159831 963 | return (EL_EXPLICIT (location) == NULL 159832 | ^ 159833 src/gdb/location.c:57:30: note: 'event_location::<unnamed union>::explicit_loc' declared here 159834 57 | struct explicit_location explicit_loc; 159835 | ^~~~~~~~~~~~ 159836 159837 GCC is right, EL_EXPLICIT is defined as returning the address of an 159838 union field: 159839 159840 /* An explicit location. */ 159841 struct explicit_location explicit_loc; 159842 #define EL_EXPLICIT(P) (&((P)->u.explicit_loc)) 159843 159844 and thus must always be non-NULL. 159845 159846 Change-Id: Ie74fee7834495a93affcefce03c06e4d83ad8191 159847 1598482021-11-15 GDB Administrator <gdbadmin@sourceware.org> 159849 159850 Automatic date update in version.in 159851 1598522021-11-14 Lancelot SIX <lsix@lancelotsix.com> 159853 159854 [PR gdb/16238] Add completer for the show user command 159855 The 'show user' command (which shows the definition of non-python/scheme 159856 user defined commands) is currently missing a completer. This is 159857 mentioned in PR 16238. Having one can improve the user experience. 159858 159859 In this commit I propose an implementation for such completer as well as 159860 the associated tests. 159861 159862 Tested on x86_64 GNU/Linux. 159863 159864 All feedbacks are welcome. 159865 159866 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16238 159867 1598682021-11-14 Alan Modra <amodra@gmail.com> 159869 159870 sync libbacktrace from gcc 159871 1598722021-11-14 GDB Administrator <gdbadmin@sourceware.org> 159873 159874 Automatic date update in version.in 159875 1598762021-11-13 H.J. Lu <hjl.tools@gmail.com> 159877 159878 Sync Makefile.tpl with GCC 159879 * Makefile.tpl: Sync with GCC. 159880 * Makefile.in: Regenerate. 159881 1598822021-11-13 Mike Frysinger <vapier@gentoo.org> 159883 159884 sim: sh: fix switch-bool warnings 159885 This code triggers -Werror=switch-bool warnings with <=gcc-5 versions. 159886 Rework it to use if statements instead as it also simplifies a bit. 159887 159888 sim: sh: rework carry checks to not rely on integer overflows 159889 In <=gcc-7 versions, -fstrict-overflow is enabled by default, and that 159890 triggers warnings in this code that relies on integer overflows to test 159891 for carries. Change the logic to test against the limit directly. 159892 1598932021-11-13 GDB Administrator <gdbadmin@sourceware.org> 159894 159895 Automatic date update in version.in 159896 1598972021-11-12 Carl Love <cel@us.ibm.com> 159898 159899 Fix gdb.base/sigstep.exp test for ppc 159900 The test stops at <signal_handler called> which is the call to the handler 159901 rather than in the handler as intended. This patch replaces the 159902 gdb_test "$enter_cmd to handler" with a gdb_test_multiple test. The multiple 159903 test looks for the stop at <signal_handler called>. If found, the command 159904 is issued again. The test passes if gdb stops in the handler as expected. 159905 159906 (gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, step 159907 from handler: continue to signal 159908 stepi 159909 <signal handler called> 159910 1: x/i $pc 159911 => 0x7ffff7f80440 <__kernel_start_sigtramp_rt64>: bctrl 159912 (gdb) stepi 159913 handler (sig=551) at sigstep.c:32 159914 32 { 159915 1: x/i $pc 159916 => 0x10000097c <handler>: addis r2,r12,2 159917 (gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, 159918 step from handler: stepi to handler 159919 159920 Patch has been tested on x86_64-linux and ppc64le-linux with no test failures. 159921 1599222021-11-12 Tom de Vries <tdevries@suse.de> 159923 159924 [gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp 159925 On OBS I ran into: 159926 ... 159927 (gdb) PASS: gdb.base/foll-vfork.exp: exit: \ 159928 vfork relations in info inferiors: continue to child exit 159929 info inferiors^M 159930 Num Description Connection Executable ^M 159931 1 <null> foll-vfork-exit ^M 159932 * 2 <null> foll-vfork-exit ^M 159933 (gdb) I'm the proud parent of child #5044!^M 159934 FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: \ 159935 vfork relation no longer appears in info inferiors (timeout) 159936 ... 159937 159938 Fix this by removing the '$' anchor in the corresponding '$gdb_prompt $' 159939 regexps. 159940 159941 Tested on x86_64-linux. 159942 1599432021-11-12 Alan Modra <amodra@gmail.com> 159944 159945 Don't compile some opcodes files when bfd is 32-bit only 159946 * Makefile.am (TARGET_LIBOPCODES_CFILES): Split into.. 159947 (TARGET64_LIBOPCODES_CFILES): ..this and.. 159948 (TARGET32_LIBOPCODES_CFILES): ..this. 159949 (ALL_MACHINES): Likewise split to 159950 (ALL64_MACHINES, ALL32_MACHINES): ..this. 159951 * disassemble.c: Define some ARCH_* when ARCH_all only if BFD64. 159952 * configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE. 159953 * Makefile.in: Regenerate. 159954 * configure: Regenerate. 159955 159956 Import Makefile.def from gcc 159957 * Makefile.def: Import from gcc. 159958 * Makefile.in: Regenerate. 159959 1599602021-11-12 Alan Modra <amodra@gmail.com> 159961 159962 Fix demangle style usage info 159963 Extract allowed styles from libiberty, so we don't have to worry about 159964 our help messages getting out of date. The function probably belongs 159965 in libiberty/cplus-dem.c but it can be here for a while to iron out 159966 bugs. 159967 159968 PR 28581 159969 * demanguse.c: New file. 159970 * demanguse.h: New file. 159971 * nm.c (usage): Break up output. Use display_demangler_styles. 159972 * objdump.c (usage): Use display_demangler_styles. 159973 * readelf.c (usage): Likewise. 159974 * Makefile.am: Add demanguse.c and demanguse.h. 159975 * Makefile.in: Regenerate. 159976 * po/POTFILESin: Regenerate. 159977 1599782021-11-12 GDB Administrator <gdbadmin@sourceware.org> 159979 159980 Automatic date update in version.in 159981 1599822021-11-11 Simon Marchi <simon.marchi@efficios.com> 159983 159984 gdb: fix "set scheduler-locking" thread exit hang 159985 GDB hangs when doing this: 159986 159987 - launch inferior with multiple threads 159988 - multiple threads hit some breakpoint(s) 159989 - one breakpoint hit is presented as a stop, the rest are saved as 159990 pending wait statuses 159991 - "set scheduler-locking on" 159992 - resume the currently selected thread (because of scheduler-locking, 159993 it's the only one resumed), let it execute until exit 159994 - GDB hangs, not showing the prompt, impossible to interrupt with ^C 159995 159996 When the resumed thread exits, we expect the target to return a 159997 TARGET_WAITKIND_NO_RESUMED event, and that's what we see: 159998 159999 [infrun] fetch_inferior_event: enter 160000 [infrun] scoped_disable_commit_resumed: reason=handling event 160001 [infrun] random_pending_event_thread: None found. 160002 [Thread 0x7ffff7d9c700 (LWP 309357) exited] 160003 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 160004 [infrun] print_target_wait_results: -1.0.0 [process -1], 160005 [infrun] print_target_wait_results: status->kind = no-resumed 160006 [infrun] handle_inferior_event: status->kind = no-resumed 160007 [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed) 160008 [infrun] prepare_to_wait: prepare_to_wait 160009 [infrun] reset: reason=handling event 160010 [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads 160011 [infrun] fetch_inferior_event: exit 160012 160013 The problem is in handle_no_resumed: we check if some other thread is 160014 actually resumed, to see if we should ignore that event (see comments in 160015 that function for more info). If this condition is true: 160016 160017 (thread->executing () || thread->has_pending_waitstatus ()) 160018 160019 ... then we ignore the event. The problem is that there are some non-resumed 160020 threads with a pending event, which makes us ignore the event. But these 160021 threads are not resumed, so we end up waiting while nothing executes, hence 160022 waiting for ever. 160023 160024 My first fix was to change the condition to: 160025 160026 (thread->executing () 160027 || (thread->resumed () && thread->has_pending_waitstatus ())) 160028 160029 ... but then it occured to me that we could simply check for: 160030 160031 (thread->resumed ()) 160032 160033 Since "executing" implies "resumed", checking simply for "resumed" 160034 covers threads that are resumed and executing, as well as threads that 160035 are resumed with a pending status, which is what we want. 160036 160037 Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780 160038 1600392021-11-11 Tom de Vries <tdevries@suse.de> 160040 160041 [gdb/build] Fix Wimplicit-exception-spec-mismatch in clang build 160042 When building with clang 13 (and -std=gnu++17 to work around an issue in 160043 string_view-selftests.c), we run into a few Wimplicit-exception-spec-mismatch 160044 warnings: 160045 ... 160046 src/gdbsupport/new-op.cc:102:1: error: function previously declared with an \ 160047 explicit exception specification redeclared with an implicit exception \ 160048 specification [-Werror,-Wimplicit-exception-spec-mismatch] 160049 operator delete (void *p) 160050 ^ 160051 /usr/include/c++/11/new:130:6: note: previous declaration is here 160052 void operator delete(void*) _GLIBCXX_USE_NOEXCEPT 160053 ^ 160054 ... 160055 160056 These are due to recent commit 5fff6115fea "Fix 160057 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb". 160058 160059 Fix this by adding the missing noexcept. 160060 160061 Build on x86_64-linux, using gcc 7.5.0 and clang 13.0.0. 160062 1600632021-11-11 Tom de Vries <tdevries@suse.de> 160064 160065 [gdb/build] Fix build with -std=c++11 160066 When building with -std=c++11, we run into two Werror=missing-declarations: 160067 ... 160068 new-op.cc: In function 'void operator delete(void*, std::size_t)': 160069 new-op.cc:114:1: error: no previous declaration for \ 160070 'void operator delete(void*, std::size_t)' [-Werror=missing-declarations] 160071 operator delete (void *p, std::size_t) noexcept 160072 ^~~~~~~~ 160073 new-op.cc: In function 'void operator delete [](void*, std::size_t)': 160074 new-op.cc:132:1: error: no previous declaration for \ 160075 'void operator delete [](void*, std::size_t)' [-Werror=missing-declarations] 160076 operator delete[] (void *p, std::size_t) noexcept 160077 ^~~~~~~~ 160078 ... 160079 160080 These are due to recent commit 5fff6115fea "Fix 160081 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb". 160082 160083 The declarations are provided by <new> (which is included) for c++14 onwards, 160084 but they are missing for c++11. 160085 160086 Fix this by adding the missing declarations. 160087 160088 Tested on x86_64-linux, with gcc 7.5.0, both without (implying -std=gnu++14) and 160089 with -std=c++11. 160090 1600912021-11-11 Tom de Vries <tdevries@suse.de> 160092 160093 [gdb/testsuite] Add gdb.arch/ppc64-break-on-_exit.exp 160094 Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't 160095 skip system call in skip_prologue": 160096 - set a breakpoint on a local copy of glibc's _exit, and 160097 - verify that it triggers. 160098 160099 The test-case uses an assembly file by default, but also has the possibility 160100 to use a C source file instead. 160101 160102 Tested on ppc64le-linux. Verified that the test-case fails without 160103 aforementioned commit, and passes with the commit. Both with assembly 160104 and C source. 160105 1601062021-11-11 Nelson Chu <nelson.chu@sifive.com> 160107 160108 RISC-V: Dump objects according to the elf architecture attribute. 160109 For now we should always generate the elf architecture attribute both for 160110 elf and linux toolchains, so that we could dump the objects correctly 160111 according to the generated architecture string. This patch resolves the 160112 problem that we probably dump an object with c.nop instructions, but 160113 in fact the c extension isn't allowed. Consider the following case, 160114 160115 nelson@LAPTOP-QFSGI1F2:~/test$ cat temp.s 160116 .option norvc 160117 .option norelax 160118 .text 160119 add a0, a0, a0 160120 .byte 0x1 160121 .balign 16 160122 nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-as temp.s -o temp.o 160123 nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o 160124 160125 temp.o: file format elf32-littleriscv 160126 160127 Disassembly of section .text: 160128 160129 00000000 <.text>: 160130 0: 00a50533 add a0,a0,a0 160131 4: 01 .byte 0x01 160132 5: 00 .byte 0x00 160133 6: 0001 nop 160134 8: 00000013 nop 160135 c: 00000013 nop 160136 nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-readelf -A temp.o 160137 Attribute Section: riscv 160138 File Attributes 160139 Tag_RISCV_arch: "rv32i2p0_m2p0_a2p0_f2p0_d2p0" 160140 160141 The c.nop at address 0x6 is generated for alignment, but since the rvc isn't 160142 allowed for this object, dump it as a c.nop instruction looks wrong. After 160143 applying this patch, I get the following result, 160144 160145 nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o 160146 160147 temp.o: file format elf32-littleriscv 160148 160149 Disassembly of section .text: 160150 160151 00000000 <.text>: 160152 0: 00a50533 add a0,a0,a0 160153 4: 01 .byte 0x01 160154 5: 00 .byte 0x00 160155 6: 0001 .2byte 0x1 160156 8: 00000013 nop 160157 c: 00000013 nop 160158 160159 For the current objdump, we dump data to .byte/.short/.word/.dword, and 160160 dump the unknown or unsupported instructions to .2byte/.4byte/.8byte, which 160161 respectively are 2, 4 and 8 bytes instructions. Therefore, we shouldn't 160162 dump the 0x0001 as a c.nop instruction in the above case, we should dump 160163 it to .2byte 0x1 as a unknown instruction, since the rvc is disabled. 160164 160165 However, consider that some people may use the new objdump to dump the old 160166 objects, which don't have any elf attributes. We usually set the default 160167 architecture string to rv64g by bfd/elfxx-riscv.c:riscv_set_default_arch. 160168 But this will cause rvc instructions to be unrecognized. Therefore, we 160169 set the default architecture string to rv64gc for disassembler, to keep 160170 the previous behavior. 160171 160172 This patch pass the riscv-gnu-toolchain gcc/binutils regressions for 160173 rv32emc-elf, rv32gc-linux, rv32i-elf, rv64gc-elf and rv64gc-linux 160174 toolchains. Also, tested by --enable-targets=all and can build 160175 riscv-gdb successfully. 160176 160177 bfd/ 160178 * elfnn-riscv.c (riscv_merge_arch_attr_info): Tidy the 160179 codes for riscv_parse_subset_t setting. 160180 * elfxx-riscv.c (riscv_get_default_ext_version): Updated. 160181 (riscv_subset_supports): Moved from gas/config/tc-riscv.c. 160182 (riscv_multi_subset_supports): Likewise. 160183 * elfxx-riscv.h: Added extern for riscv_subset_supports and 160184 riscv_multi_subset_supports. 160185 gas/ 160186 * config/tc-riscv.c (riscv_subset_supports): Moved to 160187 bfd/elfxx-riscv.c. 160188 (riscv_multi_subset_supports): Likewise. 160189 (riscv_rps_as): Defined for architectrue parser. 160190 (riscv_set_arch): Updated. 160191 (riscv_set_abi_by_arch): Likewise. 160192 (riscv_csr_address): Likewise. 160193 (reg_lookup_internal): Likewise. 160194 (riscv_ip): Likewise. 160195 (s_riscv_option): Updated. 160196 * testsuite/gas/riscv/mapping-04b.d: Updated. 160197 * testsuite/gas/riscv/mapping-norelax-03b.d: Likewise. 160198 * testsuite/gas/riscv/mapping-norelax-04b.d: Likewise. 160199 opcodes/ 160200 * riscv-dis.c: Include elfxx-riscv.h since we need the 160201 architecture parser. Also removed the cpu-riscv.h, it 160202 is already included in elfxx-riscv.h. 160203 (default_isa_spec): Defined since the parser need this 160204 to set the default architecture string. 160205 (xlen): Moved out from riscv_disassemble_insn as a global 160206 variable, it is more convenient to initialize riscv_rps_dis. 160207 (riscv_subsets): Defined to recoed the supported 160208 extensions. 160209 (riscv_rps_dis): Defined for architectrue parser. 160210 (riscv_disassemble_insn): Call riscv_multi_subset_supports 160211 to make sure if the instructions are valid or not. 160212 (print_insn_riscv): Initialize the riscv_subsets by parsing 160213 the elf architectrue attribute. Otherwise, set the default 160214 architectrue string to rv64gc. 160215 1602162021-11-11 Mike Frysinger <vapier@gentoo.org> 160217 160218 sim: testsuite: drop sim_compile cover function 160219 Most code isn't using this, and the only call site (in one cris file) 160220 can use target_compile directly. So switch it over to simplify. 160221 160222 sim: cris: stop testing a.out explicitly [ld/13900] 160223 Since gcc dropped support for a.out starting with 4.4.0 in 2009, it's 160224 been impossible to verify this code actually still works. Since it 160225 crashes in ld, and it uses a config option that no other tests uses 160226 and we want to remove, drop the test to avoid all the trouble. 160227 160228 sim: io: tweak compiler workaround with error output 160229 Outputting an extra space broke a cris test. Change the workaround 160230 to use %s with an empty string to avoid the compiler warning but not 160231 output an extra space. 160232 160233 sim: testsuite: delete unused arm remote host logic 160234 There's no need to sync testutils.inc with remote hosts. The one 160235 we have in the source tree is all we need and only thing we test. 160236 Delete it to simplify. 160237 160238 sim: synacor: simplify test generation 160239 Objcopy was used to create a binary file of just the executable code 160240 since the environment requires code to based at address 0. We can 160241 accomplish the same thing with the -Ttext=0 flag, so switch to that 160242 to get rid of custom logic. 160243 1602442021-11-11 GDB Administrator <gdbadmin@sourceware.org> 160245 160246 Automatic date update in version.in 160247 1602482021-11-10 Tom Tromey <tromey@adacore.com> 160249 160250 Handle PIE in .debug_loclists 160251 Simon pointed out that my recent patches to .debug_loclists caused 160252 some regressions. After a brief discussion we realized it was because 160253 his system compiler defaults to PIE. 160254 160255 This patch changes this code to unconditionally apply the text offset 160256 here. It also changes loclist_describe_location to work more like 160257 dwarf2_find_location_expression. 160258 160259 I tested this by running the gdb.dwarf2 tests both with and without 160260 -pie. 160261 1602622021-11-10 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 160263 160264 arm: enable Cortex-A710 CPU 160265 This patch is adding support for Cortex-A710 CPU in Arm. 160266 160267 bfd/ 160268 160269 * cpu-arm.c (processors): Add cortex-a710. 160270 160271 gas/ 160272 160273 * NEWS: Update docs. 160274 * config/tc-arm.c (arm_cpus): Add cortex-a710 to -mcpu. 160275 * doc/c-arm.texi: Update docs. 160276 * testsuite/gas/arm/cpu-cortex-a710.d: New test. 160277 1602782021-11-10 Clément Chigot <clement.chigot@atos.net> 160279 160280 gdb: adjust x_file fields on COFF readers 160281 Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file 160282 on XCOFF") changes the structure associated to the internal 160283 representation of files in COFF formats. However, gdb directory update 160284 has been forgotten, leading to compilation errors of this kind: 160285 160286 CXX coffread.o 160287 /home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)': 160288 /home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes' 160289 1343 | if (aux_entry->x_file.x_n.x_zeroes == 0) 160290 | ^~~~~~~~ 160291 160292 Fix it by adjusting the COFF code in GDB. 160293 160294 Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c 160295 1602962021-11-10 Tom de Vries <tdevries@suse.de> 160297 160298 [gdb/testsuite] Add gdb.opt/break-on-_exit.exp 160299 Add a test-case to excercise the problem scenario reported in PR28527 and 160300 fixed in commit a50bdb99afe "[gdb/tdep, rs6000] Don't skip system call in 160301 skip_prologue": 160302 - set a breakpoint on _exit, and 160303 - verify that it triggers. 160304 160305 Note that this is not a regression test for that commit. Since the actual 160306 code in _exit may vary across os instances, we cannot guarantee that the 160307 problem will always trigger with this test-case. 160308 160309 Rather, this test-case is a version of the original test-case 160310 (gdb.threads/process-dies-while-detaching.exp) that is minimal while still 160311 reproducing the problem reported in PR28527, in that same setting. 160312 160313 The benefit of this test-case is that it exercise real-life code and may 160314 expose similar problems in other settings. Also, it provides a much easier 160315 test-case to investigate in case a similar problem occurs. 160316 160317 Tested on x86_64-linux and ppc64le-linux. 160318 1603192021-11-10 Mike Frysinger <vapier@gentoo.org> 160320 160321 sim: frv: flip trapdump default back to off 160322 When I refactored this by scoping it to sim-frv-xxx in commit 160323 e7954ef5e5ed90fb7d28c013518f4c2e6bcd20a1 ("sim: frv: scope the 160324 unique configure flag"), I changed the default from off to on. 160325 While the feature is nice for developers, it breaks a bunch of 160326 tests which aren't expecting this extra output. So flip it back 160327 to off by default. 160328 1603292021-11-10 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi> 160330 160331 PR28575, readelf.c and strings.c use undefined type uint 160332 Since --unicode support (commit b3aa80b45c4) both binutils/readelf.c 160333 and binutils/strings.c use 'uint' in a few locations. It likely 160334 should be 'unsigned int' since there isn't anything defining 'uint' 160335 within binutils (besides zlib) and AFAIK it isn't a standard type. 160336 160337 * readelf.c (print_symbol): Replace uint with unsigned int. 160338 * strings.c (string_min, display_utf8_char): Likewise. 160339 (print_unicode_stream_body, print_unicode_stream): Likewise. 160340 (print_strings): Likewise. 160341 (get_unicode_byte): Wrap long line. 160342 1603432021-11-10 Clément Chigot <clement.chigot@atos.net> 160344 160345 ld: set correct flags for AIX shared tests 160346 Previous flags were aimed to be run with XLC. 160347 Nowadays, only GCC is being tested with GNU toolchain. Moreover, 160348 recent XLC versions might also accept "-shared". 160349 160350 * testsuite/ld-shared/shared.exp: Adjust shared flags. 160351 1603522021-11-10 Clément Chigot <clement.chigot@atos.net> 160353 160354 PR 28447: implement multiple parameters for .file on XCOFF 160355 On XCOFF, ".file" pseudo-op allows 3 extras parameters to provide 160356 additional information to AIX linker, or its debugger. These are 160357 stored in auxiliary entries of the C_FILE symbol. 160358 160359 bfd/ 160360 PR 28447 160361 * coffcode.h (combined_entry_type): Add extrap field. 160362 (coff_bigobj_swap_aux_in): Adjust names of x_file fields. 160363 (coff_bigobj_swap_aux_out): Likewise. 160364 * coffgen.c (coff_write_auxent_fname): New function. 160365 (coff_fix_symbol_name): Write x_file using 160366 coff_write_auxent_fname. 160367 (coff_write_symbol): Likewise. 160368 (coff_write_symbols): Add C_FILE auxiliary entries to 160369 string table if needed. 160370 (coff_get_normalized_symtab): Adjust names of x_file fields. 160371 Normalize C_FILE auxiliary entries. 160372 (coff_print_symbol): Print C_FILE auxiliary entries. 160373 * coff-rs6000.c (_bfd_xcoff_swap_aux_in): Adjust names of 160374 x_file fields. 160375 (_bfd_xcoff_swap_aux_out): Likewise. 160376 * coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Likewise. 160377 (_bfd_xcoff64_swap_aux_out): Likewise. 160378 * cofflink.c (_bfd_coff_final_link): Likewise. 160379 (_bfd_coff_link_input_bfd): Likewise. 160380 * coffswap.h (coff_swap_aux_in): Likewise. 160381 * peXXigen.c (_bfd_XXi_swap_aux_in): Likewise. 160382 (_bfd_XXi_swap_aux_out): Likewise. 160383 * xcofflink.c (xcoff_link_input_bfd): Likewise. 160384 * libcoff.h: Regenerate. 160385 gas/ 160386 * config/tc-ppc.c (ppc_file): New function. 160387 * config/tc-ppc.h (OBJ_COFF_MAX_AUXENTRIES): Change to 4. 160388 * testsuite/gas/ppc/aix.exp: Add tests. 160389 * testsuite/gas/ppc/xcoff-file-32.d: New test. 160390 * testsuite/gas/ppc/xcoff-file-64.d: New test. 160391 * testsuite/gas/ppc/xcoff-file.s: New test. 160392 include/ 160393 * coff/internal.h (union internal_auxent): Change x_file to be a 160394 struct instead of a union. Add x_ftype field. 160395 * coff/rs6000.h (union external_auxent): Add x_resv field. 160396 * coff/xcoff.h (XFT_FN): New define. 160397 (XFT_CT): Likewise. 160398 (XFT_CV): Likewise. 160399 (XFT_CD): Likewise. 160400 1604012021-11-10 Kevin Buettner <kevinb@redhat.com> 160402 160403 Test case for Bug 28308 160404 The purpose of this test is described in the comments in 160405 dprintf-execution-x-script.exp. 160406 160407 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308 160408 160409 The name of this new test was based on that of an existing test, 160410 bp-cmds-execution-x-script.exp. I started off by copying that test, 160411 adding to it, and then rewriting almost all of it. It's different 160412 enough that I decided that listing the copyright year as 2021 160413 was sufficient. 160414 1604152021-11-10 Kevin Buettner <kevinb@redhat.com> 160416 160417 Fix PR 28308 - dprintf breakpoints not working when run from script 160418 This commit fixes Bug 28308, titled "Strange interactions with 160419 dprintf and break/commands": 160420 160421 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308 160422 160423 Since creating that bug report, I've found a somewhat simpler way of 160424 reproducing the problem. I've encapsulated it into the GDB test case 160425 which I've created along with this bug fix. The name of the new test 160426 is gdb.base/dprintf-execution-x-script.exp, I'll demonstrate the 160427 problem using this test case, though for brevity, I've placed all 160428 relevant files in the same directory and have renamed the files to all 160429 start with 'dp-bug' instead of 'dprintf-execution-x-script'. 160430 160431 The script file, named dp-bug.gdb, consists of the following commands: 160432 160433 dprintf increment, "dprintf in increment(), vi=%d\n", vi 160434 break inc_vi 160435 commands 160436 continue 160437 end 160438 run 160439 160440 Note that the final command in this script is 'run'. When 'run' is 160441 instead issued interactively, the bug does not occur. So, let's look 160442 at the interactive case first in order to see the correct/expected 160443 output: 160444 160445 $ gdb -q -x dp-bug.gdb dp-bug 160446 ... eliding buggy output which I'll discuss later ... 160447 (gdb) run 160448 Starting program: /mesquite2/sourceware-git/f34-master/bld/gdb/tmp/dp-bug 160449 vi=0 160450 dprintf in increment(), vi=0 160451 160452 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160453 26 in dprintf-execution-x-script.c 160454 vi=1 160455 dprintf in increment(), vi=1 160456 160457 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160458 26 in dprintf-execution-x-script.c 160459 vi=2 160460 dprintf in increment(), vi=2 160461 160462 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160463 26 in dprintf-execution-x-script.c 160464 vi=3 160465 [Inferior 1 (process 1539210) exited normally] 160466 160467 In this run, in which 'run' was issued from the gdb prompt (instead 160468 of at the end of the script), there are three dprintf messages along 160469 with three 'Breakpoint 2' messages. This is the correct output. 160470 160471 Now let's look at the output that I snipped above; this is the output 160472 when 'run' is issued from the script loaded via GDB's -x switch: 160473 160474 $ gdb -q -x dp-bug.gdb dp-bug 160475 Reading symbols from dp-bug... 160476 Dprintf 1 at 0x40116e: file dprintf-execution-x-script.c, line 38. 160477 Breakpoint 2 at 0x40113a: file dprintf-execution-x-script.c, line 26. 160478 vi=0 160479 dprintf in increment(), vi=0 160480 160481 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160482 26 dprintf-execution-x-script.c: No such file or directory. 160483 vi=1 160484 160485 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160486 26 in dprintf-execution-x-script.c 160487 vi=2 160488 160489 Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26 160490 26 in dprintf-execution-x-script.c 160491 vi=3 160492 [Inferior 1 (process 1539175) exited normally] 160493 160494 In the output shown above, only the first dprintf message is printed. 160495 The 2nd and 3rd dprintf messages are missing! However, all three 160496 'Breakpoint 2...' messages are still printed. 160497 160498 Why does this happen? 160499 160500 bpstat_do_actions_1() in gdb/breakpoint.c contains the following 160501 comment and code near the start of the function: 160502 160503 /* Avoid endless recursion if a `source' command is contained 160504 in bs->commands. */ 160505 if (executing_breakpoint_commands) 160506 return 0; 160507 160508 scoped_restore save_executing 160509 = make_scoped_restore (&executing_breakpoint_commands, 1); 160510 160511 Also, as described by this comment prior to the 'async' field 160512 in 'struct ui' in top.h, the main UI starts off in sync mode 160513 when processing command line arguments: 160514 160515 /* True if the UI is in async mode, false if in sync mode. If in 160516 sync mode, a synchronous execution command (e.g, "next") does not 160517 return until the command is finished. If in async mode, then 160518 running a synchronous command returns right after resuming the 160519 target. Waiting for the command's completion is later done on 160520 the top event loop. For the main UI, this starts out disabled, 160521 until all the explicit command line arguments (e.g., `gdb -ex 160522 "start" -ex "next"') are processed. */ 160523 160524 This combination of things, the state of the static global 160525 'executing_breakpoint_commands' plus the state of the async 160526 field in the main UI causes this behavior. 160527 160528 This is a backtrace after hitting the dprintf breakpoint for 160529 the second time when doing 'run' from the script file, i.e. 160530 non-interactively: 160531 160532 Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffc2b8) 160533 at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431 160534 4431 if (executing_breakpoint_commands) 160535 160536 #0 bpstat_do_actions_1 (bsp=0x7fffffffc2b8) 160537 at gdb/breakpoint.c:4431 160538 #1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x1538090) 160539 at gdb/breakpoint.c:13048 160540 #2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x137f450, ws=0x7fffffffc718, 160541 stop_chain=0x1538090) at gdb/breakpoint.c:5498 160542 #3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffc6f0) 160543 at gdb/infrun.c:6172 160544 #4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffc6f0) 160545 at gdb/infrun.c:5662 160546 #5 0x0000000000763cd5 in fetch_inferior_event () 160547 at gdb/infrun.c:4060 160548 #6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT) 160549 at gdb/inf-loop.c:41 160550 #7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0) 160551 at gdb/linux-nat.c:4207 160552 #8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0) 160553 at gdbsupport/event-loop.cc:701 160554 #9 0x0000000000b8d032 in gdb_wait_for_event (block=0) 160555 at gdbsupport/event-loop.cc:597 160556 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212 160557 #11 0x00000000009d19b6 in wait_sync_command_done () 160558 at gdb/top.c:528 160559 #12 0x00000000009d1a3f in maybe_wait_sync_command_done (was_sync=0) 160560 at gdb/top.c:545 160561 #13 0x00000000009d2033 in execute_command (p=0x7fffffffcb18 "", from_tty=0) 160562 at gdb/top.c:676 160563 #14 0x0000000000560d5b in execute_control_command_1 (cmd=0x13b9bb0, from_tty=0) 160564 at gdb/cli/cli-script.c:547 160565 #15 0x000000000056134a in execute_control_command (cmd=0x13b9bb0, from_tty=0) 160566 at gdb/cli/cli-script.c:717 160567 #16 0x00000000004c3bbe in bpstat_do_actions_1 (bsp=0x137f530) 160568 at gdb/breakpoint.c:4469 160569 #17 0x00000000004c3d40 in bpstat_do_actions () 160570 at gdb/breakpoint.c:4533 160571 #18 0x00000000006a473a in command_handler (command=0x1399ad0 "run") 160572 at gdb/event-top.c:624 160573 #19 0x00000000009d182e in read_command_file (stream=0x113e540) 160574 at gdb/top.c:443 160575 #20 0x0000000000563697 in script_from_file (stream=0x113e540, file=0x13bb0b0 "dp-bug.gdb") 160576 at gdb/cli/cli-script.c:1642 160577 #21 0x00000000006abd63 in source_gdb_script (extlang=0xc44e80 <extension_language_gdb>, stream=0x113e540, 160578 file=0x13bb0b0 "dp-bug.gdb") at gdb/extension.c:188 160579 #22 0x0000000000544400 in source_script_from_stream (stream=0x113e540, file=0x7fffffffd91a "dp-bug.gdb", 160580 file_to_open=0x13bb0b0 "dp-bug.gdb") 160581 at gdb/cli/cli-cmds.c:692 160582 #23 0x0000000000544557 in source_script_with_search (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1, search_path=0) 160583 at gdb/cli/cli-cmds.c:750 160584 #24 0x00000000005445cf in source_script (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1) 160585 at gdb/cli/cli-cmds.c:759 160586 #25 0x00000000007cf6d9 in catch_command_errors (command=0x5445aa <source_script(char const*, int)>, 160587 arg=0x7fffffffd91a "dp-bug.gdb", from_tty=1, do_bp_actions=false) 160588 at gdb/main.c:523 160589 #26 0x00000000007cf85d in execute_cmdargs (cmdarg_vec=0x7fffffffd1b0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, 160590 ret=0x7fffffffd18c) at gdb/main.c:615 160591 #27 0x00000000007d0c8e in captured_main_1 (context=0x7fffffffd3f0) 160592 at gdb/main.c:1322 160593 #28 0x00000000007d0eba in captured_main (data=0x7fffffffd3f0) 160594 at gdb/main.c:1343 160595 #29 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0) 160596 at gdb/main.c:1368 160597 #30 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508) 160598 at gdb/gdb.c:32 160599 160600 There are two frames for bpstat_do_actions_1(), one at frame #16 and 160601 the other at frame #0. The one at frame #16 is processing the actions 160602 for Breakpoint 2, which is a 'continue'. The one at frame #0 is attempting 160603 to process the dprintf breakpoint action. However, at this point, 160604 the value of 'executing_breakpoint_commands' is 1, forcing an early 160605 return, i.e. prior to executing the command(s) associated with the dprintf 160606 breakpoint. 160607 160608 For the sake of comparison, this is what the stack looks like when hitting 160609 the dprintf breakpoint for the second time when issuing the 'run' 160610 command from the GDB prompt. 160611 160612 Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffccd8) 160613 at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431 160614 4431 if (executing_breakpoint_commands) 160615 160616 #0 bpstat_do_actions_1 (bsp=0x7fffffffccd8) 160617 at gdb/breakpoint.c:4431 160618 #1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x16b0290) 160619 at gdb/breakpoint.c:13048 160620 #2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x13f0e60, ws=0x7fffffffd138, 160621 stop_chain=0x16b0290) at gdb/breakpoint.c:5498 160622 #3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffd110) 160623 at gdb/infrun.c:6172 160624 #4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffd110) 160625 at gdb/infrun.c:5662 160626 #5 0x0000000000763cd5 in fetch_inferior_event () 160627 at gdb/infrun.c:4060 160628 #6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT) 160629 at gdb/inf-loop.c:41 160630 #7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0) 160631 at gdb/linux-nat.c:4207 160632 #8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0) 160633 at gdbsupport/event-loop.cc:701 160634 #9 0x0000000000b8d032 in gdb_wait_for_event (block=0) 160635 at gdbsupport/event-loop.cc:597 160636 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212 160637 #11 0x00000000007cf512 in start_event_loop () 160638 at gdb/main.c:421 160639 #12 0x00000000007cf631 in captured_command_loop () 160640 at gdb/main.c:481 160641 #13 0x00000000007d0ebf in captured_main (data=0x7fffffffd3f0) 160642 at gdb/main.c:1353 160643 #14 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0) 160644 at gdb/main.c:1368 160645 #15 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508) 160646 at gdb/gdb.c:32 160647 160648 This relatively short backtrace is due to the current UI's async field 160649 being set to 1. 160650 160651 Yet another thing to be aware of regarding this problem is the 160652 difference in the way that commands associated to dprintf breakpoints 160653 versus regular breakpoints are handled. While they both use a command 160654 list associated with the breakpoint, regular breakpoints will place 160655 the commands to be run on the bpstat chain constructed in 160656 bp_stop_status(). These commands are run later on. For dprintf 160657 breakpoints, commands are run via the 'after_condition_true' function 160658 pointer directly from bpstat_stop_status(). (The 'commands' field in 160659 the bpstat is cleared in dprintf_after_condition_true(). This 160660 prevents the dprintf commands from being run again later on when other 160661 commands on the bpstat chain are processed.) 160662 160663 Another thing that I noticed is that dprintf breakpoints are the only 160664 type of breakpoint which use 'after_condition_true'. This suggests 160665 that one possible way of fixing this problem, that of making dprintf 160666 breakpoints work more like regular breakpoints, probably won't work. 160667 (I must admit, however, that my understanding of this code isn't 160668 complete enough to say why. I'll trust that whoever implemented it 160669 had a good reason for doing it this way.) 160670 160671 The comment referenced earlier regarding 'executing_breakpoint_commands' 160672 states that the reason for checking this variable is to avoid 160673 potential endless recursion when a 'source' command appears in 160674 bs->commands. We know that a dprintf command is constrained to either 160675 1) execution of a GDB printf command, 2) an inferior function call of 160676 a printf-like function, or 3) execution of an agent-printf command. 160677 Therefore, infinite recursion due to a 'source' command cannot happen 160678 when executing commands upon hitting a dprintf breakpoint. 160679 160680 I chose to fix this problem by having dprintf_after_condition_true() 160681 directly call execute_control_commands(). This means that it no 160682 longer attempts to go through bpstat_do_actions_1() avoiding the 160683 infinite recursion check for potential 'source' commands on the 160684 command chain. I think it simplifies this code a little bit too, a 160685 definite bonus. 160686 160687 Summary: 160688 160689 * breakpoint.c (dprintf_after_condition_true): Don't call 160690 bpstat_do_actions_1(). Call execute_control_commands() 160691 instead. 160692 1606932021-11-10 Alan Modra <amodra@gmail.com> 160694 160695 Re: Add --unicode option 160696 * objdump: Whitespace fixes. 160697 (long_options): Correct "ctf" entry. 160698 1606992021-11-10 Alan Modra <amodra@gmail.com> 160700 160701 Re: Add --unicode option 160702 At low optimisation levels gcc may warn. 160703 160704 * strings.c (print_unicode_stream_body): Avoid bogus "may be 160705 used unitialised" warning. 160706 1607072021-11-10 GDB Administrator <gdbadmin@sourceware.org> 160708 160709 Automatic date update in version.in 160710 1607112021-11-09 Alan Modra <amodra@gmail.com> 160712 160713 PR28543, readelf entered an infinite loop 160714 This little tweak terminates fuzzed binary readelf output a little 160715 quicker. 160716 160717 PR 28543 160718 * dwarf.c (read_and_display_attr_value): Consume a byte when 160719 form is unrecognized. 160720 1607212021-11-09 Alan Modra <amodra@gmail.com> 160722 160723 PR28542, Undefined behaviours in readelf.c 160724 PR 28542 160725 * readelf.c (dump_relocations): Check that section headers have 160726 been read before attempting to access section name. 160727 (print_dynamic_symbol): Likewise. 160728 (process_mips_specific): Delete dead code. 160729 1607302021-11-09 Pedro Alves <pedro@palves.net> 160731 160732 gdb::array_view slicing/container selftest - test std::array too 160733 Change-Id: I2141b0b8a09f6521a59908599eb5ba1a19b18dc6 160734 1607352021-11-09 Simon Marchi <simon.marchi@efficios.com> 160736 160737 gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with AddressSanitizer 160738 This test fails for me, showing: 160739 160740 ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp. 160741 ERROR: This GDB was configured as follows: 160742 configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu 160743 --with-auto-load-dir=$debugdir:$datadir/auto-load 160744 --with-auto-load-safe-path=$debugdir:$datadir/auto-load 160745 ... and much more ... 160746 160747 The problem is that TCL's exec throws an error as soon as the exec'ed 160748 process outputs on stderr. When GDB is built with ASan, it prints some 160749 warnings about pre-existing signal handlers: 160750 160751 warning: Found custom handler for signal 7 (Bus error) preinstalled. 160752 warning: Found custom handler for signal 8 (Floating point exception) preinstalled. 160753 warning: Found custom handler for signal 11 (Segmentation fault) preinstalled. 160754 160755 Pass --quiet to GDB to avoid these warnings. 160756 160757 Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f 160758 1607592021-11-09 Tom Tromey <tromey@adacore.com> 160760 160761 Correctly handle DW_LLE_start_end 160762 When the code to handle DW_LLE_start_end was added (as part of some 160763 DWARF 5 work), it was written to add the base address. However, this 160764 seems incorrect -- the DWARF standard describes this as an address, 160765 not an offset from the base address. 160766 160767 This patch changes a couple of spots in dwarf2/loc.c to fix this 160768 problem. It then changes decode_debug_loc_addresses to return 160769 DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics. 160770 160771 This only showed up on the RISC-V target internally, due to the 160772 combination of DWARF 5 and a newer version of GCC. I've updated a 160773 couple of existing loclists test cases to demonstrate the bug. 160774 1607752021-11-09 Tom Tromey <tromey@adacore.com> 160776 160777 Fix build on rhES5 160778 The rhES5 build failed due to an upstream import a while back. The 160779 bug here is that, while the 'personality' function exists, 160780 ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not 160781 <sys/personality.h>. 160782 160783 However, <linux/personality.h> does not declare the 'personality' 160784 function, and <sys/personality.h> and <linux/personality.h> cannot 160785 both be included. 160786 160787 This patch restores one of the removed configure checks and updates 160788 the code to check it. 160789 160790 We had this as a local patch at AdaCore, because it seemed like there 160791 was no interest upstream. However, now it turns out that this fixes 160792 PR build/28555, so I'm sending it now. 160793 1607942021-11-09 H.J. Lu <hjl.tools@gmail.com> 160795 160796 doc/ctf-spec.texi: Remove "@validatemenus off" 160797 Remove @validatemenus from ctf-spec.texi, which has been removed from 160798 texinfo by 160799 160800 commit a16dd1a9ece08568a1980b9a65a3a9090717997f 160801 Author: Gavin Smith <gavinsmith0123@gmail.com> 160802 Date: Mon Oct 12 16:32:37 2020 +0100 160803 160804 * doc/texinfo.texi 160805 (Writing a Menu, Customization Variables for @-Commands) 160806 (Command List), 160807 * doc/refcard/txirefcard.tex 160808 Remove @validatemenus. 160809 * tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead 160810 of awk. Avoid discouraged "$p" usage, using "$(p)" instead. 160811 * tp/Texinfo/XS/configure.ac: Check for gawk. 160812 160813 commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4 160814 Author: Gavin Smith <gavinsmith0123@gmail.com> 160815 Date: Thu Jan 3 14:51:53 2019 +0000 160816 160817 Update refcard. 160818 160819 * doc/refcard/txirefcard.tex: @setfilename is no longer 160820 mandatory. Do not mention @validatemenus or explicitly giving 160821 @node pointers, as these are not very important features. 160822 160823 PR libctf/28567 160824 * doc/ctf-spec.texi: Remove "@validatemenus off". 160825 1608262021-11-09 Nick Clifton <nickc@redhat.com> 160827 160828 Add --unicode option to control how unicode characters are handled by display tools. 160829 * nm.c: Add --unicode option to control how unicode characters are 160830 handled. 160831 * objdump.c: Likewise. 160832 * readelf.c: Likewise. 160833 * strings.c: Likewise. 160834 * binutils.texi: Document the new feature. 160835 * NEWS: Document the new feature. 160836 * testsuite/binutils-all/unicode.exp: New file. 160837 * testsuite/binutils-all/nm.hex.unicode 160838 * testsuite/binutils-all/strings.escape.unicode 160839 * testsuite/binutils-all/objdump.highlight.unicode 160840 * testsuite/binutils-all/readelf.invalid.unicode 160841 1608422021-11-09 Mike Frysinger <vapier@gentoo.org> 160843 160844 sim: sh: simplify testsuite a bit 160845 Switch from the centralized list in the exp file to each test declaring 160846 its own requirements which they're already (mostly) doing. This will 160847 increase coverage slightly by running more tests in more configurations 160848 since the hardcoded exp list was a little out of date. 160849 160850 We have to mark the psh* tests as shdsp only (to match what the exp 160851 file was doing), mark the fsca & fsrra tests as failing (since they 160852 weren't even being run by the exp file), and to fix the expected 160853 output & status of the fail test. 160854 1608552021-11-09 Mike Frysinger <vapier@gentoo.org> 160856 160857 sim: cris: clean up missing func prototype warnings 160858 Move some unused funcs under existing #if 0 protection, mark a few 160859 local funcs as static, and add missing prototypes for the rest which 160860 are used from other files. This fixes all the fatal warnings in the 160861 mloop files so we can turn -Werror on here fully. 160862 1608632021-11-09 GDB Administrator <gdbadmin@sourceware.org> 160864 160865 Automatic date update in version.in 160866 1608672021-11-08 Lancelot SIX <lsix@lancelotsix.com> 160868 160869 Improve gdb::array_view ctor from contiguous containers 160870 While reading the interface of gdb::array_view, I realized that the 160871 constructor that builds an array_view on top of a contiguous container 160872 (such as std::vector, std::array or even gdb::array_view) can be 160873 missused. 160874 160875 Lets consider the following code sample: 160876 160877 struct Parent 160878 { 160879 Parent (int a): a { a } {} 160880 int a; 160881 }; 160882 160883 std::ostream &operator<< (std::ostream& os, const Parent & p) 160884 { os << "Parent {a=" << p.a << "}"; return os; } 160885 160886 struct Child : public Parent 160887 { 160888 Child (int a, int b): Parent { a }, b { b } {} 160889 int b; 160890 }; 160891 160892 std::ostream &operator<< (std::ostream& os, const Child & p) 160893 { os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; } 160894 160895 template <typename T> 160896 void print (const gdb::array_view<const T> &p) 160897 { 160898 std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; }); 160899 } 160900 160901 Then with the current interface nothinng prevents this usage of 160902 array_view to be done: 160903 160904 const std::array<Child, 3> elts = { 160905 Child {1, 2}, 160906 Child {3, 4}, 160907 Child {5, 6} 160908 }; 160909 print_all<Parent> (elts); 160910 160911 This compiles fine and produces the following output: 160912 160913 Parent {a=1} 160914 Parent {a=2} 160915 Parent {a=3} 160916 160917 which is obviously wrong. There is nowhere in memory a Parent-like 160918 object for which the A member is 2 and this call to print_all<Parent> 160919 shold not compile at all (calling print_all<Child> is however fine). 160920 160921 This comes down to the fact that a Child* is convertible into a Parent*, 160922 and that an array view is constructed to a pointer to the first element 160923 and a size. The valid type pointed to that can be used with this 160924 constructor are restricted using SFINAE, which requires that a 160925 pointer to a member into the underlying container can be converted into a 160926 pointer the array_view's data type. 160927 160928 This patch proposes to change the constraints on the gdb::array_view 160929 ctor which accepts a container now requires that the (decayed) type of 160930 the elements in the container match the (decayed) type of the array_view 160931 being constructed. 160932 160933 Applying this change required minimum adjustment in GDB codebase, which 160934 are also included in this patch. 160935 160936 Tested by rebuilding. 160937 1609382021-11-08 Lancelot SIX <lsix@lancelotsix.com> 160939 160940 Add a const version of gdb_argv:as_array_view 160941 This commits adds const versions for the GET and AS_ARRAX_VIEW methods 160942 of gdb_argv. Those methods will be required in the following patch of 160943 the series. 160944 1609452021-11-08 Simon Marchi <simon.marchi@polymtl.ca> 160946 160947 gdb: fix nulltr -> nullptr typo 160948 Change-Id: I04403bd85ec3fa75ea14130d68daba675a2a8aeb 160949 1609502021-11-08 Simon Marchi <simon.marchi@polymtl.ca> 160951 160952 gdb: tweak scoped_disable_commit_resumed uses when resuming all threads in non-stop 160953 When doing "continue -a" in non-stop mode, each thread is individually 160954 resumed while the commit resumed state is enabled. This forces the 160955 target to commit each resumption immediately, instead of being able to 160956 batch things. 160957 160958 The reason is that there is no scoped_disable_commit_resumed around the 160959 loop over threads in continue_1, when "non_stop && all_threads" is true. 160960 Since the proceed function is called once for each thread, the 160961 scoped_disable_commit_resumed in proceed therefore forces commit-resumed 160962 between each thread resumption. Add the necessary 160963 scoped_disable_commit_resumed in continue_1 to avoid that. 160964 160965 I looked at the MI side of things, the function exec_continue, and found 160966 that it was correct. There is a similar iteration over threads, and 160967 there is a scoped_disable_commit_resumed at the function scope. This is 160968 not wrong, but a bit more than we need. The branches that just call 160969 continue_1 do not need it, as continue_1 takes care of disabling commit 160970 resumed. So, move the scoped_disable_commit_resumed to the inner scope 160971 where we iterate on threads and proceed them individually. 160972 160973 Here's an example debugging a multi-threaded program attached by 160974 gdbserver (debug output trimmed for brevity): 160975 160976 $ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234" 160977 (gdb) set debug remote 160978 (gdb) set debug infrun 160979 (gdb) c -a 160980 Continuing. 160981 [infrun] proceed: enter 160982 [infrun] scoped_disable_commit_resumed: reason=proceeding 160983 [remote] Sending packet: $vCont;c:p14388.14388#90 160984 [infrun] reset: reason=proceeding 160985 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote 160986 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote 160987 [infrun] proceed: exit 160988 [infrun] proceed: enter 160989 [infrun] scoped_disable_commit_resumed: reason=proceeding 160990 [remote] Sending packet: $vCont;c:p14388.1438a#b9 160991 [infrun] reset: reason=proceeding 160992 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote 160993 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote 160994 [infrun] proceed: exit 160995 ... and so on for each thread ... 160996 160997 Notice how we send one vCont;c for each thread. With the patch applied, we 160998 send a single vCont;c at the end: 160999 161000 [infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop 161001 [infrun] proceed: enter 161002 [infrun] scoped_disable_commit_resumed: reason=proceeding 161003 [infrun] reset: reason=proceeding 161004 [infrun] proceed: exit 161005 [infrun] clear_proceed_status_thread: Thread 85790.85792 161006 [infrun] proceed: enter 161007 [infrun] scoped_disable_commit_resumed: reason=proceeding 161008 [infrun] reset: reason=proceeding 161009 [infrun] proceed: exit 161010 ... proceeding threads individually ... 161011 [infrun] reset: reason=continue all threads in non-stop 161012 [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote 161013 [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote 161014 [remote] Sending packet: $vCont;c#a8 161015 161016 Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb 161017 1610182021-11-08 Simon Marchi <simon.marchi@polymtl.ca> 161019 161020 gdb: make dwarf2_find_containing_comp_unit take a dwarf2_per_bfd 161021 While reading another patch, I saw that this function didn't need to 161022 take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead. 161023 It doesn't change the behavior, but doing this shows that this function 161024 is objfile-independent (can work with only the shared per-bfd data). 161025 161026 Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f 161027 1610282021-11-08 Simon Marchi <simon.marchi@polymtl.ca> 161029 161030 gdb: remove bpstat typedef, rename bpstats to bpstat 161031 I don't find that the bpstat typedef, which hides a pointer, is 161032 particularly useful. In fact, it confused me many times, and I just see 161033 it as something to remember that adds cognitive load. Also, with C++, 161034 we might want to be able to pass bpstats objects by const-reference, not 161035 necessarily by pointer. 161036 161037 So, remove the bpstat typedef and rename struct bpstats to bpstat (since 161038 it represents one bpstat, it makes sense that it is singular). 161039 161040 Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849 161041 1610422021-11-08 Nick Alcock <nick.alcock@oracle.com> 161043 161044 libctf: add CTF format specification 161045 It's been a long time since most of this was written: it's long past 161046 time to put it in the binutils source tree. It's believed correct and 161047 complete insofar as it goes: it documents format v3 (the current 161048 version) but not the libctf API or any earlier versions. (The 161049 earlier versions can be read by libctf but not generated by it, and you 161050 are highly unlikely ever to see an example of any of them.) 161051 161052 libctf/ChangeLog 161053 2021-11-08 Nick Alcock <nick.alcock@oracle.com> 161054 161055 * doc/ctf-spec.texi: New file. 161056 * configure.ac (MAKEINFO): Add. 161057 (BUILD_INFO): Likewise. 161058 (AC_CONFIG_FILES) [doc/Makefile]: Add. 161059 * Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/. 161060 * doc/Makefile.am: New file. 161061 * doc/Makefile.in: Likewise. 161062 * configure: Regenerated. 161063 * Makefile.in: Likewise. 161064 1610652021-11-08 GDB Administrator <gdbadmin@sourceware.org> 161066 161067 Automatic date update in version.in 161068 1610692021-11-07 Alan Modra <amodra@gmail.com> 161070 161071 Correct ld script wildcard matching description 161072 Goes with commit 68bbb9f788d0 161073 161074 * ld.texi (Input Section Wildcards): Delete paragraph incorrectly 161075 saying '*' does not match '/'. 161076 1610772021-11-07 Mike Frysinger <vapier@gentoo.org> 161078 161079 sim: sh: fix conversion of PC to an integer 161080 On LLP64 targets where sizeof(long) != sizeof(void*), this code fails: 161081 sim/sh/interp.c:704:24: error: cast from pointer to integer of different size -Werror=pointer-to-int-cast] 161082 704 | do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0) 161083 | ^ 161084 161085 Since this code simply needs to check alignment, cast it using uintptr_t 161086 which is the right type for this. 161087 1610882021-11-07 Mike Frysinger <vapier@gentoo.org> 161089 161090 sim: sh: clean up time(NULL) call 161091 Casting 0 to a pointer via (long *) doesn't work on LLP64 targets: 161092 error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 161093 161094 It's also unnecessary here. We can simply pass NULL like every other 161095 bit of code does. 161096 1610972021-11-07 Mike Frysinger <vapier@gentoo.org> 161098 161099 sim: sh: break utime logic out of _WIN32 check 161100 Some _WIN32 targets provide utime (like mingw), so move the header 161101 include out from _WIN32 and under the specific HAVE_UTIME_H check. 161102 161103 sim: sh: drop errno extern 161104 This isn't needed on any reasonable target nowadays, and no other 161105 source does this, and breaks with some mingw targets, so punt the 161106 extern entirely. 161107 161108 sim: sh: fix isnan redefinition with mingw targets 161109 The code assumes that all _WIN32 targets are the same and can 161110 define isnan to _isnan. For mingw targets, they provide an isnan 161111 define already, so no need for the fallback here. 161112 161113 sim: arm/bfin/rx: undefine page size from system headers 161114 Some targets (like cygwin) will export page size defines that clash 161115 with our local usage here. Undefine the system one to fix building 161116 for these targets. 161117 161118 sim: ppc: switch to libiberty environ.h 161119 Drop our compat code and assume environ exists to simplify. 161120 We did this for all other targets already, but ppc was missed. 161121 161122 sim: sh: enable -Werror everywhere 161123 With most of the warnings fixed in interp.c, we can enable -Werror 161124 here too now. There are some -Wmaybe-uninitialized warnings still 161125 lurking that look legitimate, but we don't flag those are fatal, 161126 and I don't have the expertise to dive into each opcode to figure 161127 out the right way to clean them up. 161128 161129 sim: sh: fix uninitialized variable usage with pdmsb 161130 This block of code relies on i to control which bits to test and how 161131 many times to run through the loop, but it never actually initialized 161132 it. There is another chunk of code that handles the pdmsb instruction 161133 that sets i to 16, so use that here too assuming it's correct. The 161134 programming manual suggests this is the right value too, but I am by 161135 no means a SuperH DSP expert. The tests are still passing though ... 161136 161137 sim: sh: constify a few read-only lookup tables 161138 161139 sim: sh: fix various parentheses warnings 161140 Add parentheses to a bunch of places where the compiler suggests we 161141 do to avoid confusion to most readers. 161142 161143 sim: sh: fix unused-value warnings 161144 These macro expansions are deliberate in not using the computed value 161145 so that they trigger side-effects (possible invalid memory accesses) 161146 but while otherwise being noops. Add a (void) cast so the compiler 161147 knows these are intentional. 161148 161149 sim: sh: rework register layout with anonymous unions & structs 161150 Now that we require C11, we can leverage anonymous unions & structs 161151 to fix a long standing issue with the SH register layout. The use 161152 of sregs.i for sh-dsp has generated a lot of compiler warnings about 161153 the access being out of bounds -- it only has 7 elements declared, 161154 but code goes beyond that to reach into the fregs that follow. But 161155 now that we have anonymous unions, we can reduce the nested names 161156 and have sregs cover all of these registers. 161157 1611582021-11-07 GDB Administrator <gdbadmin@sourceware.org> 161159 161160 Automatic date update in version.in 161161 1611622021-11-06 Tiezhu Yang <yangtiezhu@loongson.cn> 161163 161164 sim: mips: use sim_fpu_to{32,64}u to fix build warnings 161165 Since the first argument type is unsigned32 or unsigned64, just use 161166 sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following 161167 build warnings: 161168 161169 CC cp1.o 161170 .../sim/mips/cp1.c: In function 'convert': 161171 .../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign] 161172 status |= sim_fpu_to32i (&result32, &wop, round); 161173 ^~~~~~~~~ 161174 In file included from .../sim/mips/sim-main.h:67, 161175 from .../sim/mips/cp1.c:46: 161176 .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'} 161177 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f, 161178 ^~~~~~~~~~~~~ 161179 .../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign] 161180 status |= sim_fpu_to64i (&result64, &wop, round); 161181 ^~~~~~~~~ 161182 In file included from .../sim/mips/sim-main.h:67, 161183 from .../sim/mips/cp1.c:46: 161184 .../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'} 161185 INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f, 161186 ^~~~~~~~~~~~~ 161187 .../sim/mips/cp1.c: In function 'convert_ps': 161188 .../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign] 161189 status_u |= sim_fpu_to32i (&res_u, &wop_u, round); 161190 ^~~~~~ 161191 In file included from .../sim/mips/sim-main.h:67, 161192 from .../sim/mips/cp1.c:46: 161193 .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'} 161194 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f, 161195 ^~~~~~~~~~~~~ 161196 .../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign] 161197 status_l |= sim_fpu_to32i (&res_l, &wop_l, round); 161198 ^~~~~~ 161199 In file included from .../sim/mips/sim-main.h:67, 161200 from .../sim/mips/cp1.c:46: 161201 .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'} 161202 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f, 161203 ^~~~~~~~~~~~~ 161204 1612052021-11-06 Alan Modra <amodra@gmail.com> 161206 161207 Modernise yyerror 161208 Newer versions of bison emit a prototype for yyerror 161209 void yyerror (const char *); 161210 This clashes with some of our old code that declares yyerror to return 161211 an int. Fix that in most cases by modernizing yyerror. bfin-parse.y 161212 uses the return value all over the place, so for there disable 161213 generation of the prototype as specified by posix. 161214 161215 binutils/ 161216 * arparse.y (yyerror): Return void. 161217 * dlltool.c (yyerror): Likewise. 161218 * dlltool.h (yyerror): Likewise. 161219 * sysinfo.y (yyerror): Likewise. 161220 * windmc.h (yyerror): Likewise. 161221 * mclex.c (mc_error): Extract from .. 161222 (yyerror): ..here, both now returning void. 161223 gas/ 161224 * config/bfin-parse.y (yyerror): Define. 161225 (yyerror): Make static. 161226 * itbl-parse.y (yyerror): Return void. 161227 ld/ 161228 * deffilep.y (def_error): Return void. 161229 1612302021-11-06 Alan Modra <amodra@gmail.com> 161231 161232 ubsan: undefined shift in mach-o.c 161233 This one was logically wrong too. If file_ptr was 64 bits, then -1U 161234 is extended to 0x00000000ffffffff, probably not what was intended 161235 here. 161236 161237 * mach-o.c (FILE_ALIGN): Correct expression. 161238 1612392021-11-06 Fangrui Song <maskray@google.com> 161240 161241 readelf: Support RELR in -S and -d and output 161242 readelf -r dumping support is not added in this patch. 161243 161244 include/ 161245 * elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT} 161246 bfd/ 161247 * elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}. 161248 binutils/ 161249 * readelf.c (get_dynamic_type): Add DT_RELR{,SZ,ENT}. 161250 (get_section_type_name): Add SHT_RELR. 161251 1612522021-11-06 Fangrui Song <maskray@google.com> 161253 161254 readelf: Make DT_PREINIT_ARRAYSZ's output style match DT_INIT_ARRAYSZ 161255 The output now looks like: 161256 161257 - 0x0000000000000021 (PREINIT_ARRAYSZ) 0x10 161258 + 0x0000000000000021 (PREINIT_ARRAYSZ) 16 (bytes) 161259 0x0000000000000019 (INIT_ARRAY) 0xbefc90 161260 0x000000000000001b (INIT_ARRAYSZ) 536 (bytes) 161261 161262 * readelf.c (process_dynamic_section): Handle DT_PREINIT_ARRAYSZ. 161263 1612642021-11-06 Mike Frysinger <vapier@gentoo.org> 161265 161266 sim: clarify license text via COPYING file 161267 The project has been using GPL v3 for a while now in the source files, 161268 and the arm & ppc ports have carried a copy of the COPYING file. Lets 161269 move those up to the top sim dir like other projects to make it clear. 161270 161271 Also drop the ppc/COPYING.LIB as it's not really referenced by any 161272 source as everything is GPL v3. 161273 1612742021-11-06 GDB Administrator <gdbadmin@sourceware.org> 161275 161276 Automatic date update in version.in 161277 1612782021-11-05 Tom Tromey <tom@tromey.com> 161279 161280 Introduce make_unique_xstrndup 161281 This adds a new make_unique_xstrndup function, which is the "n" 161282 analogue of make_unique_xstrdup. It also updates a couple existing 161283 places to use this function. 161284 1612852021-11-05 Pedro Alves <pedro@palves.net> 161286 161287 Avoid /proc/pid/mem races (PR 28065) 161288 PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent 161289 failure) shows that GDB can hit an unexpected scenario -- it can 161290 happen that the kernel manages to open a /proc/PID/task/LWP/mem file, 161291 but then reading from the file returns 0/EOF, even though the process 161292 hasn't exited or execed. 161293 161294 "0" out of read/write is normally what you get when the address space 161295 of the process the file was open for is gone, because the process 161296 execed or exited. So when GDB gets the 0, it returns memory access 161297 failure. In the bad case in question, the process hasn't execed or 161298 exited, so GDB fails a memory access when the access should have 161299 worked. 161300 161301 GDB has code in place to gracefully handle the case of opening the 161302 /proc/PID/task/LWP/mem just while the LWP is exiting -- most often the 161303 open fails with EACCES or ENOENT. When it happens, GDB just tries 161304 opening the file for a different thread of the process. The testcase 161305 is written such that it stresses GDB's logic of closing/reopening the 161306 /proc/PID/task/LWP/mem file, by constantly spawning short lived 161307 threads. 161308 161309 However, there's a window where the kernel manages to find the thread, 161310 but the thread exits just after and clears its address space pointer. 161311 In this case, the kernel creates a file successfully, but the file 161312 ends up with no address space associated, so a subsequent read/write 161313 returns 0/EOF too, just like if the whole process had execed or 161314 exited. This is the case in question that GDB does not handle. 161315 161316 Oleg Nesterov gave this suggestion as workaround for that race: 161317 161318 gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm. 161319 If statm reports something non-zero, then open() was "successfull". 161320 161321 I think that might work. However, I didn't try it, because I realized 161322 we have another nasty race that that wouldn't fix. 161323 161324 The other race I realized is that because we close/reopen the 161325 /proc/PID/task/LWP/mem file when GDB switches to a different inferior, 161326 then it can happen that GDB reopens /proc/PID/task/LWP/mem just after 161327 a thread execs, and before GDB has seen the corresponding exec event. 161328 I.e., we can open a /proc/PID/task/LWP/mem file accessing the 161329 post-exec address space thinking we're accessing the pre-exec address 161330 space. 161331 161332 A few months back, Simon, Oleg and I discussed a similar race: 161333 161334 [Bug gdb/26754] Race condition when resuming threads and one does an exec 161335 https://sourceware.org/bugzilla/show_bug.cgi?id=26754 161336 161337 The solution back then was to make the kernel fail any ptrace 161338 operation until the exec event is consumed, with this kernel commit: 161339 161340 commit dbb5afad100a828c97e012c6106566d99f041db6 161341 Author: Oleg Nesterov <oleg@redhat.com> 161342 AuthorDate: Wed May 12 15:33:08 2021 +0200 161343 Commit: Linus Torvalds <torvalds@linux-foundation.org> 161344 CommitDate: Wed May 12 10:45:22 2021 -0700 161345 161346 ptrace: make ptrace() fail if the tracee changed its pid unexpectedly 161347 161348 This however, only applies to ptrace, not to the /proc/pid/mem file 161349 opening case. Also, even if it did apply to the file open case, we 161350 would want to support current kernels until such a fix is more wide 161351 spread anyhow. 161352 161353 So all in all, this commit gives up on the idea of only ever keeping 161354 one /proc/pid/mem file descriptor open. Instead, make GDB open a 161355 /proc/pid/mem per inferior, and keep it open until the inferior exits, 161356 is detached or execs. Make GDB open the file right after the inferior 161357 is created or is attached to or forks, at which point we know the 161358 inferior is stable and stopped and isn't thus going to exec, or have a 161359 thread exit, and so the file open won't fail (unless the whole process 161360 is SIGKILLed from outside GDB, at which point it doesn't matter 161361 whether we open the file). 161362 161363 This way, we avoid both races described above, at the expense of using 161364 more file descriptors (one per inferior). 161365 161366 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065 161367 Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419 161368 1613692021-11-05 Andrew Burgess <aburgess@redhat.com> 161370 161371 gdb/testsuite: use gdb_get_line_number 161372 Replaces a hard coded line number with a use of gdb_get_line_number. 161373 161374 I suspect that the line number has, over time, come adrift from where 161375 it was supposed to be stopping. When the test was first added, line 161376 770 pointed at the final 'return 0' in function main. Over time, as 161377 things have been added, line 770 now points at some random location in 161378 the middle of main. 161379 161380 So, I've marked the 'return 0' with a comment, and now the test will 161381 always stop there. 161382 161383 I also removed an old comment from 1997 talking about how these tests 161384 will only pass with the HP compiler, followed by an additional comment 161385 from 2000 saying that the tests now pass with GCC. 161386 161387 I get the same results before and after this change. 161388 1613892021-11-05 Alan Modra <amodra@gmail.com> 161390 161391 PR28541, unstable cie offset in the output of readelf 161392 Calculating "0 - pointer" can indeed result in seeming randomness as 161393 the pointer address varies. 161394 161395 PR 28541 161396 * dwarf.c (display_debug_frames): Don't print cie offset when 161397 invalid, print "invalid" instead. Remove now redundant warning. 161398 1613992021-11-05 Alan Modra <amodra@gmail.com> 161400 161401 Missing va_end in aarch64-dis.c 161402 * aarch64-dis.c (extract_fields): Invoke va_end. 161403 1614042021-11-05 Alan Modra <amodra@gmail.com> 161405 161406 PR28530, Hang in objdump on machine with 196GB RAM 161407 Investigating the PR28530 testcase, which has a fuzzed compression 161408 header with an enormous size, I noticed that decompress_contents is 161409 broken when the size doesn't fit in strm.avail_out. It wouldn't be 161410 too hard to support larger sizes (patches welcome!) but for now just 161411 stop decompress_contents from returning rubbish. 161412 161413 PR 28530 161414 * compress.c (decompress_contents): Fail when uncompressed_size 161415 is too big. 161416 (bfd_init_section_decompress_status): Likewise. 161417 1614182021-11-05 Alan Modra <amodra@gmail.com> 161419 161420 asan: alpha-vms: objdump buffer overflows 161421 * vms-alpha.c (evax_bfd_print_desc): Sanity check buffer access. 161422 (evax_bfd_print_valspec, evax_bfd_print_typspec): Likewise. 161423 (evax_bfd_print_dst): Likewise. 161424 1614252021-11-05 GDB Administrator <gdbadmin@sourceware.org> 161426 161427 Automatic date update in version.in 161428 1614292021-11-04 Simon Marchi <simon.marchi@polymtl.ca> 161430 161431 gdb: introduce "set index-cache enabled", deprecate "set index-cache on/off" 161432 The "set index-cache" command is used at the same time as a prefix 161433 command (prefix for "set index-cache directory", for example), and a 161434 boolean setting for turning the index-cache on and off. Even though I 161435 did introduce that, I now don't think it's a good idea to do something 161436 non-standard like this. 161437 161438 First, there's no dedicated CLI command to show whether the index-cache 161439 is enabled, so it has to be custom output in the "show index-cache 161440 handler". Also, it means there's no good way a MI frontend can find out 161441 if the index-cache is enabled. "-gdb-show index-cache" doesn't show it 161442 in the MI output record: 161443 161444 (gdb) interpreter-exec mi "-gdb-show index-cache" 161445 ~"\n" 161446 ~"The index cache is currently disabled.\n" 161447 ^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}} 161448 161449 Fix this by introducing "set/show index-cache enabled on/off", regular 161450 boolean setting commands. Keep commands "set index-cache on" and "set 161451 index-cache off" as deprecated aliases of "set index-cache enabled", 161452 with respectively the default arguments "on" and "off". 161453 161454 Update tests using "set index-cache on/off" to use the new command. 161455 Update the regexps in gdb.base/maint.exp to figure out whether the 161456 index-cache is enabled or not. Update the doc to mention the new 161457 commands. 161458 161459 Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3 161460 1614612021-11-04 Simon Marchi <simon.marchi@polymtl.ca> 161462 161463 gdb: pass/return setting setter/getter scalar values by value 161464 The getter and setter in struct setting always receive and return values 161465 by const reference. This is not necessary for scalar values (like bool 161466 and int), but more importantly it makes it a bit annoying to write a 161467 getter, you have to use a scratch static variable or something similar 161468 that you can refer to: 161469 161470 const bool & 161471 my_getter () 161472 { 161473 static bool value; 161474 value = function_returning_bool (); 161475 return value; 161476 } 161477 161478 Change the getter and setter function signatures to receive and return 161479 value by value instead of by reference, when the underlying data type is 161480 scalar. This means that string-based settings will still use 161481 references, but all others will be by value. The getter above would 161482 then be re-written as: 161483 161484 bool 161485 my_getter () 161486 { 161487 return function_returning_bool (); 161488 } 161489 161490 This is useful for a patch later in this series that defines a boolean 161491 setting with a getter and a setter. 161492 161493 Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd 161494 1614952021-11-04 Simon Marchi <simon.marchi@polymtl.ca> 161496 161497 gdb: remove command_class enum class_deprecated 161498 The class_deprecated enumerator isn't assigned anywhere, so remove it. 161499 Commands that are deprecated have cmd_list_element::cmd_deprecated set 161500 instead. 161501 161502 Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c 161503 1615042021-11-04 Simon Marchi <simon.marchi@polymtl.ca> 161505 161506 gdb: remove unnecessary cmd_list_element::aliases nullptr checks 161507 Remove two unnecessary nullptr checks. If aliases is nullptr, then the 161508 for loops will simply be skipped. 161509 161510 Change-Id: I9132063bb17798391f8d019af305383fa8e0229f 161511 1615122021-11-04 Simon Marchi <simon.marchi@polymtl.ca> 161513 161514 gdbserver: re-generate configure 161515 I get some diffs when running autoconf in gdbserver, probably leftovers 161516 from commit 5dfe4bfcb969 ("Fix format_pieces selftest on Windows"). 161517 Re-generate configure in that directory. 161518 161519 Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08 161520 1615212021-11-04 H.J. Lu <hjl.tools@gmail.com> 161522 161523 Revert "bfd: Always check sections with the corrupt size" 161524 This reverts commit e0f7ea91436dd308a094c4c101fd4169e8245a91. 161525 1615262021-11-04 H.J. Lu <hjl.tools@gmail.com> 161527 161528 bfd: Always check sections with the corrupt size 161529 Always check sections with the corrupt size for non-MMO files. Skip MMO 161530 files for compress_status == COMPRESS_SECTION_NONE since MMO has special 161531 handling for COMPRESS_SECTION_NONE. 161532 161533 PR binutils/28530 161534 * compress.c (bfd_get_full_section_contents): Always check 161535 sections with the corrupt size. 161536 1615372021-11-04 Nelson Chu <nelson.chu@sifive.com> 161538 161539 RISC-V: Clarify the behavior of .option rvc or norvc. 161540 Add/Remove the rvc extension to/from the riscv_subsets once the 161541 .option rvc/norvc is set. So that we don't need to always check 161542 the riscv_opts.rvc in the riscv_subset_supports, just call the 161543 riscv_lookup_subset to search the subset list is enough. 161544 161545 Besides, we will need to dump the instructions according to the 161546 elf architecture attributes. That means the dis-assembler needs 161547 to parse the architecture string from the elf attribute before 161548 dumping any instructions, and also needs to recognized the 161549 INSN_CLASS* classes from riscv_opcodes. Therefore, I suppose 161550 some functions will need to be moved from gas/config/tc-riscv.c 161551 to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and 161552 riscv_subset_supports. This is one of the reasons why we need 161553 this patch. 161554 161555 This patch passes the gcc/binutils regressions of rv32emc-elf, 161556 rv32i-elf, rv64gc-elf and rv64gc-linux toolchains. 161557 161558 bfd/ 161559 * elfxx-riscv.c (riscv_remove_subset): Remove the extension 161560 from the subset list. 161561 (riscv_update_subset): Add/Remove an extension to/from the 161562 subset list. This is used for the .option rvc or norvc. 161563 * elfxx-riscv.h: Added the extern bool riscv_update_subset. 161564 gas/ 161565 * config/tc-riscv.c (riscv_set_options): Removed the unused 161566 rve flag. 161567 (riscv_opts): Likewise. 161568 (riscv_set_rve): Removed. 161569 (riscv_subset_supports): Removed the riscv_opts.rvc check. 161570 (riscv_set_arch): Don't need to call riscv_set_rve. 161571 (reg_lookup_internal): Call riscv_subset_supports to check 161572 whether the rve is supported. 161573 (s_riscv_option): Add/Remove the rvc extension to/from the 161574 subset list once the .option rvc/norvc is set. 161575 1615762021-11-04 Mike Frysinger <vapier@gentoo.org> 161577 161578 sim: mips: fix missing prototype in multi-run generation 161579 The multi-run logic for mips involves a bit of codegen and rewriting 161580 of files to include per-architecture prefixes. That can result in 161581 files with missing prototypes which cause compiler errors. In the 161582 case of mips-sde-elf targets, we have: 161583 $srcdir/m16run.c -> $builddir/m16mips64r2_run.c 161584 sim_engine_run -> m16mips64r2_engine_run 161585 $srcdir/micromipsrun.c -> micromipsmicromips_run.c 161586 sim_engine_run -> micromips64micromips_engine_run 161587 161588 micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes] 161589 80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus, 161590 161591 We generate headers for those prototypes in the configure script, 161592 but only include them in the generated multi-run.c file. Update the 161593 rewrite logic to turn the sim-engine.h include into the relevant 161594 generated engine include so these files also have their prototypes. 161595 $srcdir/m16run.c -> $builddir/m16mips64r2_run.c 161596 sim-engine.h -> m16mips64r2_engine.h 161597 $srcdir/micromipsrun.c -> micromipsmicromips_run.c 161598 sim-engine.h -> micromips64micromips_engine.h 161599 1616002021-11-04 Alan Modra <amodra@gmail.com> 161601 161602 PR28540, segmentation fault on NULL byte_get 161603 PR 28540 161604 * objdump.c (dump_bfd): Don't attempt load_separate_debug_files 161605 when byte_get is NULL. 161606 1616072021-11-04 GDB Administrator <gdbadmin@sourceware.org> 161608 161609 Automatic date update in version.in 161610 1616112021-11-03 Mike Frysinger <vapier@gentoo.org> 161612 161613 sim: ppc: inline common sim-fpu.c logic 161614 We will never bother building w/out a ../common/ sim directory, 161615 so drop ancient logic supporting that method. 161616 1616172021-11-03 Mike Frysinger <vapier@gentoo.org> 161618 161619 sim: ppc: switch to common builds for callback objects 161620 We don't need to build this anymore ourselves since the common build 161621 includes it and produces the same object code. We also need to pull 161622 in the split constant modules after the refactoring and pulling them 161623 out of nltvals.def & targ-map.o. This doesn't matter for the sim 161624 directly, but does for gdb and other users of libsim. 161625 161626 We also delete some conditional source tree logic since we already 161627 require this be the "new" combined tree with a ../common/ dir. This 161628 has been the case for decades at this point. 161629 1616302021-11-03 Simon Marchi <simon.marchi@polymtl.ca> 161631 161632 gdb: fix gnu-nat build 161633 When building gnu-nat.c, we get: 161634 161635 CXX gnu-nat.o 161636 gnu-nat.c: In member function 'virtual void gnu_nat_target::create_inferior(const char*, const string&, char**, int)': 161637 gnu-nat.c:2117:13: error: 'struct inf' has no member named 'target_is_pushed' 161638 2117 | if (!inf->target_is_pushed (this)) 161639 | ^~~~~~~~~~~~~~~~ 161640 gnu-nat.c:2118:10: error: 'struct inf' has no member named 'push_target' 161641 2118 | inf->push_target (this); 161642 | ^~~~~~~~~~~ 161643 161644 This is because of a confusion between the generic `struct inferior` 161645 variable and the gnu-nat-specific `struct inf` variable. Fix by 161646 referring to `inferior`, not `inf`. 161647 161648 Adjust the comment on top of `struct inf` to clarify the purpose of that 161649 type. 161650 161651 Co-Authored-By: Andrea Monaco <andrea.monaco@autistici.org> 161652 Change-Id: I2fe2f7f6ef61a38d79860fd262b08835c963fc77 161653 1616542021-11-03 Simon Marchi <simon.marchi@polymtl.ca> 161655 161656 gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests 161657 We see some additional failures when running the testsuite against a GDB 161658 compiled with ASan, compared to a GDB compiled without ASan. Some of 161659 them are caused by the memory leak report shown by the GDB process when 161660 it exits, and the fact that it makes it exit with a non-zero exit code. 161661 161662 I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my 161663 environment when running the tests, but I don't always do it. I think 161664 it would be nice if the testsuite did it. I don't see any use to have 161665 leak detection when running the tests. That is, unless we ever have a 161666 test that ensures GDB doesn't leak memory, which isn't going to happen 161667 any time soon. 161668 161669 Here are some tests I found that were affected by this: 161670 161671 gdb.base/batch-exit-status.exp 161672 gdb.base/many-headers.exp 161673 gdb.base/quit.exp 161674 gdb.base/with-mf.exp 161675 gdb.dwarf2/gdb-add-index.exp 161676 gdb.dwarf2/gdb-add-index-symlink.exp 161677 gdb.dwarf2/imported-unit-runto-main.exp 161678 161679 Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca 161680 1616812021-11-03 Tom Tromey <tromey@adacore.com> 161682 161683 Use section name in warnings in display_debug_loc 161684 While looking at an apparently malformed executable with 161685 "readelf --debug-dump=loc", I got this warning: 161686 161687 readelf: ./main: Warning: There is a hole [0x89 - 0x95] in .debug_loc section. 161688 161689 However, the executable only has a .debug_loclists section. 161690 161691 This patch fixes the warning messages in display_debug_loc to use the 161692 name of the section that is being processed. 161693 161694 binutils/ChangeLog 161695 2021-11-03 Tom Tromey <tromey@adacore.com> 161696 161697 * dwarf.c (display_debug_loc): Use section name in warnings. 161698 1616992021-11-03 Luis Machado <luis.machado@linaro.org> 161700 161701 [AArch64] Make gdbserver register set selection dynamic 161702 The current register set selection mechanism for AArch64 is static, based 161703 on a pre-populated array of register sets. 161704 161705 This means that we might potentially probe register sets that are not 161706 available. This is OK if the kernel errors out during ptrace, but probing the 161707 tag_ctl register, for example, does not result in a ptrace error if the kernel 161708 supports the tagged address ABI but not MTE (PR 28355). 161709 161710 Making the register set selection dynamic, based on feature checks, solves 161711 this and simplifies the code a bit. It allows us to list all of the register 161712 sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties. 161713 161714 I plan to backport this fix to GDB 11 as well. 161715 161716 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28355 161717 1617182021-11-03 Jan Kratochvil <jan.kratochvil@redhat.com> 161719 161720 Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb 161721 Currently for a binary compiled normally (without -fsanitize=address) but with 161722 LD_PRELOAD of ASAN one gets: 161723 161724 $ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb 161725 ================================================================= 161726 ==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570 161727 #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7) 161728 ... 161729 0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572) 161730 allocated by thread T0 here: 161731 #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f) 161732 #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81) 161733 SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*) 161734 ==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0 161735 ==1909567==ABORTING 161736 161737 Despite the code called properly operator new[] and operator delete[]. 161738 But GDB's new-op.cc provides its own operator new[] which gets translated into 161739 malloc() (which gets recogized as operatore new(size_t)) but as it does not 161740 translate also operators delete[] Address Sanitizer gets confused. 161741 161742 The question is how many variants of the delete operator need to be provided. 161743 There could be 14 operators new but there are only 4, GDB uses 3 of them. 161744 There could be 16 operators delete but there are only 6, GDB uses 2 of them. 161745 It depends on libraries and compiler which of the operators will get used. 161746 Currently being used: 161747 U operator new[](unsigned long) 161748 U operator new(unsigned long) 161749 U operator new(unsigned long, std::nothrow_t const&) 161750 U operator delete[](void*) 161751 U operator delete(void*, unsigned long) 161752 161753 Tested on x86_64-linux. 161754 1617552021-11-03 Alan Modra <amodra@gmail.com> 161756 161757 asan: dlltool buffer overflow: embedded NUL in string 161758 yyleng gives the pattern length, xstrdup just copies up to the NUL. 161759 So it is quite possible writing at an index of yyleng-2 overflows 161760 the xstrdup allocated string buffer. xmemdup quite handily avoids 161761 this problem, even writing the terminating NUL over the trailing 161762 quote. Use it in ldlex.l too where we'd already had a report of this 161763 problem and fixed it by hand, and to implement xmemdup0 in gas. 161764 161765 binutils/ 161766 * deflex.l (single and double quote strings): Use xmemdup. 161767 gas/ 161768 * as.h (xmemdup0): Use xmemdup. 161769 ld/ 161770 PR 20906 161771 * ldlex.l (double quote string): Use xmemdup. 161772 1617732021-11-03 Mike Frysinger <vapier@gentoo.org> 161774 161775 sim: mloop: mark a few conditionally used funcs as unused 161776 These are marked inline, so building w/gcc at higher optimization 161777 levels will automatically discard them. But building with -O0 will 161778 trigger unused function warnings, so fix that. 161779 161780 The common before/after cover functions in the common mloop generator 161781 are not used by all architecture ports. Doesn't seem to be a hard 161782 requirement, so marking them optional (i.e. unused) is fine. 161783 161784 The cris execute function is conditionally used depending on the 161785 fast-build mode settings, so mark it unused too. 161786 1617872021-11-03 Alan Modra <amodra@gmail.com> 161788 161789 asan: assert (addr_ranges) <= (start) 161790 That assert would be more obvious if it were reported as 161791 "addr_ranges <= end_ranges". Fix that by using the obvious variable 161792 in the final loop. Stop the assertion by using a signed comparison: 161793 It's possible for the rounding up of the arange pointer to exceed the 161794 end of the block when the block size is fuzzed. 161795 161796 * dwarf.c (display_debug_aranges): Use "end_ranges" in loop 161797 displaying ranges rather that "start". Simplify rounding up 161798 to 2*address_size boundary. Use signed comparison in loop. 161799 1618002021-11-03 Mike Frysinger <vapier@gentoo.org> 161801 161802 sim: hoist cgen mloop rules up to common builds 161803 These rules don't depend on the target compiler settings, so hoist 161804 the build logic up to the common builds for better parallelization. 161805 161806 We have to extend the genmloop.sh logic a bit to allow outputting 161807 to a subdir since it always assumed cwd was the right place. 161808 161809 We leave the cgen maintainer rules in the subdirs for now as they 161810 aren't normally run, and they rely on cgen logic that has not yet 161811 been generalized. 161812 1618132021-11-03 Mike Frysinger <vapier@gentoo.org> 161814 161815 sim: hoist mn10300 & v850 igen rules up to common builds 161816 These rules don't depend on the target compiler settings, so hoist 161817 the build logic up to the common builds for better parallelization. 161818 161819 We leave the mips rules in place as they depend on complicated 161820 arch-specific configure logic that needs to be untangled first. 161821 1618222021-11-03 Mike Frysinger <vapier@gentoo.org> 161823 161824 sim: hoist gencode & opc2c build rules up to common builds 161825 These rules don't depend on the target compiler settings, so hoist 161826 the build logic up to the common builds for better parallelization. 161827 1618282021-11-03 Mike Frysinger <vapier@gentoo.org> 161829 161830 opcodes: d10v: simplify header includes 161831 This file doesn't use anything from bfd (sysdep.h), so drop that 161832 include. This avoids an implicit dependency on the generated 161833 config.h which can be problematic for build-time tools. 161834 161835 Also swap stdio.h for stddef.h. This file isn't doing or using 161836 any I/O structures, but it does need NULL. 161837 1618382021-11-03 Alan Modra <amodra@gmail.com> 161839 161840 PR28523, ld.bfd created undefined symbols on ppc64 161841 This patch removes any fake (linker created) function descriptor 161842 symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic 161843 symbols are not created. The change to func_desc_adjust requires that 161844 it be run only once, which means ppc64_elf_tls_setup can't call it for 161845 just a few selected symbols. 161846 161847 PR 28523 161848 * elf64-ppc.c (func_desc_adjust): If a function entry sym is 161849 not dynamic and has no plt entry, hide any associated fake 161850 function descriptor symbol. 161851 (ppc64_elf_edit): Move func_desc_adjust iteration over syms to.. 161852 (ppc64_elf_tls_setup): ..here. 161853 1618542021-11-03 GDB Administrator <gdbadmin@sourceware.org> 161855 161856 Automatic date update in version.in 161857 1618582021-11-02 Tom de Vries <tdevries@suse.de> 161859 161860 [gdb/tdep, rs6000] Don't skip system call in skip_prologue 161861 I ran into a case where a breakpoint on _exit never triggered, because it was 161862 set past the end of the _exit prologue, past the end of the exit_group system 161863 call (which does not return). 161864 161865 More concretely, the breakpoint was set at the last insn show here: 161866 ... 161867 Dump of assembler code for function _exit: 161868 0x00007ffff7e42ea0 <+0>: 12 00 4c 3c addis r2,r12,18 161869 0x00007ffff7e42ea4 <+4>: 60 43 42 38 addi r2,r2,17248 161870 0x00007ffff7e42ea8 <+8>: 00 00 00 60 nop 161871 0x00007ffff7e42eac <+12>: f8 ff e1 fb std r31,-8(r1) 161872 0x00007ffff7e42eb0 <+16>: 78 1b 7f 7c mr r31,r3 161873 0x00007ffff7e42eb4 <+20>: f0 ff c1 fb std r30,-16(r1) 161874 0x00007ffff7e42eb8 <+24>: ea 00 00 38 li r0,234 161875 0x00007ffff7e42ebc <+28>: a0 8b 22 e9 ld r9,-29792(r2) 161876 0x00007ffff7e42ec0 <+32>: 78 fb e3 7f mr r3,r31 161877 0x00007ffff7e42ec4 <+36>: 14 6a c9 7f add r30,r9,r13 161878 0x00007ffff7e42ec8 <+40>: 02 00 00 44 sc 161879 0x00007ffff7e42ecc <+44>: 26 00 00 7c mfcr r0 161880 0x00007ffff7e42ed0 <+48>: 00 10 09 74 andis. r9,r0,4096 161881 ... 161882 161883 Fix this by treating system calls the same as branches in skip_prologue: 161884 by default, don't skip, such that the breakpoint is set at 0x00007ffff7e42eb8 161885 instead. 161886 161887 Tested on ppc64le-linux, on a power 8 machine. 161888 161889 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28527 161890 1618912021-11-02 Tom de Vries <tdevries@zinfandel-3.arch.suse.de> 161892 161893 [gdb/testsuite] Handle SIGILL in two gdb.arch powerpc test-cases 161894 On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into 161895 SIGILL: 161896 ... 161897 (gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3" 161898 stepi^M 161899 ^M 161900 Program terminated with signal SIGILL, Illegal instruction.^M 161901 The program no longer exists.^M 161902 (gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4 161903 ... 161904 because it's a power9 insn, and I'm running on a power8 machine. 161905 161906 Fix this by handling the SIGILL. Likewise in gdb.arch/powerpc-lnia.exp. 161907 161908 Tested on powerpc64le-linux. 161909 1619102021-11-02 Andrew Burgess <andrew.burgess@embecosm.com> 161911 161912 gdb/sim: update my email address 161913 gdb: 161914 161915 * MAINTAINERS (Global Maintainers): Update my address. 161916 (Responsible Maintainers): Likewise. 161917 (Write After Approval): Likewise. 161918 161919 sim: 161920 161921 * MAINTAINERS (Global Maintainers): Update my address. 161922 1619232021-11-02 Tom de Vries <tdevries@suse.de> 161924 161925 [gdb/testsuite] Fix stepi test-cases with unix/-m32/-fPIE/-pie 161926 When running test-case gdb.base/step-indirect-call-thunk.exp with target board 161927 unix/-m32/-fPIE/-pie, I run into: 161928 ... 161929 (gdb) stepi^M 161930 0x5655552e 22 { /* inc.1 */^M 161931 (gdb) stepi^M 161932 0x56555530 22 { /* inc.1 */^M 161933 (gdb) stepi^M 161934 0x565555f7 in __x86.get_pc_thunk.ax ()^M 161935 (gdb) FAIL: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk 161936 ... 161937 161938 In contrast, with unix/-m32 we have instead: 161939 ... 161940 (gdb) stepi^M 161941 0x08048407 22 { /* inc.1 */^M 161942 (gdb) stepi^M 161943 23 return x + 1; /* inc.2 */^M 161944 (gdb) stepi^M 161945 0x0804840c 23 return x + 1; /* inc.2 */^M 161946 (gdb) stepi^M 161947 24 } /* inc.3 */^M 161948 (gdb) stepi^M 161949 0x08048410 24 } /* inc.3 */^M 161950 (gdb) stepi^M 161951 0x0804848f in __x86_return_thunk ()^M 161952 (gdb) PASS: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk 161953 ... 161954 161955 The test-case doesn't expect to run into __x86.get_pc_thunk.ax, which is a 161956 PIC helper function for x86_64-linux. 161957 161958 Fix this by insn-stepping through it. 161959 161960 Likewise in a few other test-cases. 161961 161962 Tested on x86_64-linux. 161963 1619642021-11-02 GDB Administrator <gdbadmin@sourceware.org> 161965 161966 Automatic date update in version.in 161967 1619682021-11-01 Alan Modra <amodra@gmail.com> 161969 161970 ARM: match armeb output for unwind-pacbti-m test 161971 * testsuite/gas/arm/unwind-pacbti-m.d: Match armeb output. 161972 1619732021-11-01 Bruno Larsen <blarsen@redhat.com> 161974 161975 [gdb/doc]: Updated manpages to be consistent with help 161976 Updated manpages to be consistent with help information provided by the 161977 binary. The main changes are: 161978 161979 * Making all long-form options have '--', instead of a single '-'; 161980 * added most of the missing options to the manpage; 161981 * removed the information about using '+' instead of '-', since it 161982 doesn't seem to be supported anymore. 161983 161984 This also fixes 2 upstream bugs: 161985 * https://sourceware.org/bugzilla/show_bug.cgi?id=23965; by adding 161986 --args to the manpage 161987 * https://sourceware.org/bugzilla/show_bug.cgi?id=10619; by adding the 161988 double dashes 161989 1619902021-11-01 Alan Modra <amodra@gmail.com> 161991 161992 macho-o archive sanity checks 161993 Anti-fuzzing checks. 161994 161995 * mach-o.c (bfd_mach_o_fat_archive_p): Sanity check entry offset 161996 and size against file size. 161997 1619982021-11-01 Alan Modra <amodra@gmail.com> 161999 162000 objcopy buffer overflow 162001 "tocopy" in this code was an int, which when the size to be copied was 162002 larger than MAXINT could result in tocopy being negative. A negative 162003 value of course is less than BUFSIZE, but when converted to 162004 bfd_size_type is extremely large. 162005 162006 PR 995 162007 * objcopy.c (copy_unknown_object): Correct calculation of "tocopy". 162008 Use better variable types. 162009 1620102021-11-01 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 162011 162012 arm: add armv9-a architecture to -march 162013 Update also include: 162014 + New value of Tag_CPU_arch EABI attribute (22) is added. 162015 + Updated missing Tag_CPU_arch EABI attributes. 162016 + Updated how we combine archs 'v4t_plus_v6_m' as this mechanism 162017 have to handle new Armv9 as well. 162018 162019 Regression tested on `arm-none-eabi` cross Binutils and no issues. 162020 162021 bfd/ 162022 162023 * archures.c: Define bfd_mach_arm_9. 162024 * bfd-in2.h (bfd_mach_arm_9): Define bfd_mach_arm_9. 162025 * cpu-arm.c: Add 'armv9-a' option to -march. 162026 * elf32-arm.c (using_thumb2_bl): Update assert check. 162027 (arch_has_arm_nop): Add TAG_CPU_ARCH_V9. 162028 (bfd_arm_get_mach_from_attributes): Add case for TAG_CPU_ARCH_V9. 162029 Update assert. 162030 (tag_cpu_arch_combine): Updated table. 162031 (v9): New table.. 162032 162033 binutils/ 162034 162035 * readelf.c (arm_attr_tag_CPU_arch): Update with 162036 162037 elfcpp/ 162038 162039 * arm.h: Update TAG_CPU_ARCH_ enums with correct values. 162040 162041 gas/ 162042 162043 * NEWS: Update docs. 162044 * config/tc-arm.c (get_aeabi_cpu_arch_from_fset): Return Armv9-a 162045 for -amarch=all. 162046 (aeabi_set_public_attributes): Update assert. 162047 * doc/c-arm.texi: Update docs. 162048 * testsuite/gas/arm/armv9-a_arch.d: New test. 162049 * testsuite/gas/arm/attr-march-all.d: Update test with v9. 162050 162051 include/ 162052 162053 * elf/arm.h Update TAG_CPU_ARCH_ defines with correct values. 162054 * opcode/arm.h (ARM_EXT3_V9A): New macro. 162055 (ARM_ARCH_NONE): Updated with arm_feature_set.core size. 162056 (FPU_NONE): Updated. 162057 (ARM_ANY): Updated. 162058 (ARM_ARCH_UNKNOWN): New macro. 162059 (ARM_FEATURE_LOW): Updated. 162060 (ARM_FEATURE_CORE): Updated. 162061 (ARM_FEATURE_CORE_LOW): Updated. 162062 (ARM_FEATURE_CORE_HIGH): Updated. 162063 (ARM_FEATURE_COPROC): Updated. 162064 (ARM_FEATURE): Updated. 162065 (ARM_FEATURE_ALL): New macro. 162066 162067 opcodes/ 162068 162069 * arm-dis.c (select_arm_features): Support bfd_mach_arm_9. 162070 Also Update bfd_mach_arm_unknown to use new macro ARM_ARCH_UNKNOWN. 162071 1620722021-11-01 Mike Frysinger <vapier@gentoo.org> 162073 162074 sim: iq2000: reduce -Wno-error scope 162075 Clean up the warnings in sim-if, then reduce the -Werror disable to 162076 the files that still aren't clean that now that we require GNU make 162077 and can set variables on a per-object basis. 162078 162079 sim: lm32: reduce -Wno-error scope 162080 Clean up some warnings in dv-lm32cpu, and all in sim-if, then reduce 162081 the -Werror disable to the files that still aren't clean that now that 162082 we require GNU make and can set variables on a per-object basis. 162083 162084 sim: frv: reduce -Wno-error scope 162085 Only two files in here still generates warnings, so reduce the -Werror 162086 disable to that now that we require GNU make and can set variables on 162087 a per-object basis. 162088 162089 sim: m32r: reduce -Wno-error scope 162090 Only two files in here still generates warnings, so reduce the -Werror 162091 disable to that now that we require GNU make and can set variables on 162092 a per-object basis. 162093 162094 sim: mips: reduce -Wno-error scope 162095 Fix a few printf warnings in sim-main.c, and then we're left with only 162096 one file in here still generating warnings, so reduce the -Werror 162097 disable to that alone now that we require GNU make and can set variables 162098 on a per-object basis. 162099 162100 sim: erc32: reduce -Wno-error scope 162101 Only one file in here still generates warnings, so reduce the -Werror 162102 disable to that alone now that we require GNU make and can set variables 162103 on a per-object basis. 162104 162105 sim: cris: reduce -Wno-error scope 162106 Only two files in here still generates warnings, so reduce the -Werror 162107 disable to that now that we require GNU make and can set variables on 162108 a per-object basis. 162109 162110 sim: sh: reduce -Wno-error scope 162111 Only one file in here still generates warnings, so reduce the -Werror 162112 disable to that alone now that we require GNU make and can set variables 162113 on a per-object basis. 162114 162115 sim: or1k: build with -Werror 162116 The only warnings left in this port are a few maybe-uninitialized, 162117 but we don't abort the build for them, so turn on -Werror everywhere. 162118 162119 sim: igen: minor build output alignment fix 162120 The custom echo was off by one space relative to all the others. 162121 162122 sim: ppc: fix the printf fix for 32-bit systems 162123 The time delta is a 64-bit value too. 162124 162125 sim: m68hc11: clean up pointer casts 162126 The void *data field is used to past arbitrary data between event 162127 handlers, and these are using it to pass an integer. Fix up the 162128 casts to avoid using (long) to cast to/from pointers since there 162129 is no guarantee that's the right size. 162130 162131 sim: d10v: clean up pointer casts 162132 Use %p to print pointers instead of trying to cast them to longs. 162133 162134 sim: bfin: cast pointers using uintptr_t 162135 We can't assume that sizeof(long) == sizeof(void*), so change all 162136 these casts over to uintptr_t. 162137 162138 sim: ppc: clean up printf format handling 162139 Don't blindly cast every possible type to (long). Change to the right 162140 printf format specifier whether it be a 64-bit type or a pointer. 162141 162142 sim: ppc: switch core types to stdint.h types 162143 There's no need to define these ourselves anymore, so switch to the 162144 stdint.h types. This will be important when we start using PRI* 162145 defines with printf formats. 162146 162147 sim: mn10300: clean up pointer casts 162148 The void *data field is used to past arbitrary data between event 162149 handlers, and these are using it to pass an enum. Fix up the casts 162150 to avoid using (long) to cast to/from pointers since there is no 162151 guarantee that's the right size. 162152 162153 sim: events: clean up trace casts 162154 Don't blindly cast every possible type to (long). Change to the right 162155 printf format specifier whether it be a 64-bit type or a pointer. 162156 162157 sim: ppc: handle \r in igen inputs [PR sim/28476] 162158 Make sure we consume & ignore \r bytes in inputs in case the file 162159 encodings are from a non-LF systems (e.g. Windows). 162160 162161 sim: ppc: constify strings in igen tooling 162162 1621632021-11-01 GDB Administrator <gdbadmin@sourceware.org> 162164 162165 Automatic date update in version.in 162166 1621672021-10-31 Tom Tromey <tom@tromey.com> 162168 162169 Fix latent bug in DWARF test case 162170 On my branch that replaces the DWARF psymtab reader, 162171 dw2-stack-boundary.exp started failing. However, when I look at the 162172 output in gdb.log, it is correct: 162173 162174 file /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary 162175 Reading symbols from /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary... 162176 During symbol reading: location description stack overflow 162177 During symbol reading: location description stack underflow 162178 162179 What happens to cause the failure is that the two branches in 162180 gdb_test_multiple appear in this order: 162181 162182 -re "\r\nDuring symbol reading: location description stack underflow" { 162183 [...] 162184 -re "\r\nDuring symbol reading: location description stack overflow" { 162185 162186 The first one will match the above, without causing the second one to 162187 ever match -- leading to a spurious failure. 162188 162189 Anchoring the regexps seems to fix the problem, and works for the 162190 current gdb as well. 162191 1621922021-10-31 Tom Tromey <tom@tromey.com> 162193 162194 Fix unittest.exp failure due to 'set debuginfod' addition 162195 The 'set debuginfod' change caused a regression in unittest.exp: 162196 162197 Running selftest help_doc_invariants. 162198 help doc broken invariant: command 'info set debuginfod' help doc first line is not terminated with a '.' character 162199 help doc broken invariant: command 'set debuginfod' help doc first line is not terminated with a '.' character 162200 help doc broken invariant: command 'show debuginfod' help doc first line is not terminated with a '.' character 162201 Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/command-def-selftests.c:100 162202 162203 This patch fixes the problem. I'm checking it in. 162204 1622052021-10-31 Mike Frysinger <vapier@gentoo.org> 162206 162207 sim: ppc: use silent build rules here too 162208 The ppc codebase is unique and doesn't leverage common/, so have to 162209 add silent rules to it specifically. 162210 162211 sim: rl78: drop obsolete manual dependency rules 162212 We have GNU make generate these for us automatically now, so there's 162213 no need to manually specify any deps. 162214 162215 sim: drop unused targ-vals.h includes 162216 This is used in a few places where it's not needed. Drop the include 162217 to avoid the build-time generated header file as we move to drop it. 162218 162219 sim: unify callback.o building 162220 Now that the use of TARGET_xxx defines have been removed, we can move 162221 this to the common logic so we only build it once for multi-targets. 162222 162223 sim: nltvals: pull target open flags out into a dedicated source file 162224 Like we just did for pulling out the errno & signal maps, pull out the 162225 open flag map into a dedicated common file. All newlib ports are using 162226 the same map which makes it easy. 162227 162228 sim: nltvals: localize TARGET_<open> defines 162229 Code should not be using these directly, instead they should be 162230 resolving these dynamically via the open_map. Rework the common 162231 callback code that was using the defines to use symbolic names 162232 instead, and localize some of the defines in the ARM code (since 162233 it's a bit unclear how many different APIs it supports currently), 162234 then remove the defines out of the header so no new code can rely on 162235 them. 162236 162237 sim: nltvals: pull target signal out into a dedicated source file 162238 Like we just did for pulling out the errno map, pull out the signal 162239 map into a dedicated common file. All newlib ports are using the 162240 same signal map which makes it easy. 162241 1622422021-10-31 Mike Frysinger <vapier@gentoo.org> 162243 162244 sim: nltvals: pull target errno out into a dedicated source file 162245 The current system maintains a list of target errno constants in the 162246 nltvals.def file, then runs a build-time tool to turn that into a C 162247 file. This list of errno values is the same for all arches, so we 162248 don't need the arch-specific flexibility. Further, these are only 162249 for newlib/libgloss environments, which makes it confusing to support 162250 other userland runtimes (like Linux). Let's simplify to make this 162251 easier to understand & build. We don't namespace the variables yet, 162252 but sets up the framework for it. 162253 162254 Create a new target-newlib-errno.c template file. The template file 162255 is hand written, but the inline map is still automatically generated. 162256 162257 This allows us to move it to the common set of objects so it's only 162258 built once in a multi-target build. 162259 162260 Now we can remove the output from the gentmap build-time tool since 162261 it's checked into the tree. 162262 162263 Then we stop including the errno lists in nltvals.def since nothing 162264 uses it. 162265 1622662021-10-31 Mike Frysinger <vapier@gentoo.org> 162267 162268 sim: erc32: use silent build rules with sis linkage 162269 1622702021-10-31 Mike Frysinger <vapier@gentoo.org> 162271 162272 sim: erc32: fix a few more build warnings 162273 Tweak the if indentation & brace style to avoid ambiguous warnings. 162274 162275 Add ATTRIBUTE_UNUSED to UART functions that aren't used when FAST_UART 162276 is defined (which is the default). 162277 1622782021-10-31 Orgad Shaneh <orgads@gmail.com> 162279 162280 sim: erc32: fix signedness compatibility and redefinition warnings 162281 1622822021-10-31 Mike Frysinger <vapier@gentoo.org> 162283 162284 sim: add arch-specific conditional logic 162285 This will make it easy to include arch-specific logic (build files) 162286 as we migrate ports to the common top level build. 162287 162288 sim: v850: delete old gencode logic 162289 The v850 port used to have a gencode helper, but it was deleted long 162290 ago. Clean up the settings that no longer make sense w/out it. 162291 162292 sim: common: merge multiple clean commands 162293 This provides a minor speedup when cleaning in a multi-target build. 162294 162295 sim: m32c: tighten up opc2c build output 162296 Drop the single debugging line that repeats the command line option, 162297 and use the silent build helpers to tighten up output. 162298 162299 sim: tighten up build regen rules 162300 Update the makefile & configure related rules to use the silent 162301 build helpers. 162302 162303 sim: tighten up gencode output 162304 Update the gencode rules to use the silent build helpers. 162305 162306 sim: igen: tighten up build output 162307 Add a new stamp helper for quiet builds, and don't dump the command 162308 line options when it runs. That isn't standard tool behavior, and 162309 doesn't really seem necessary in any way. 162310 162311 sim: tighten up stamp rules 162312 Add a new ECHO_STAMP helper and convert existing stamp code over 162313 to it. This is mostly common rules and cgen mloop rules. 162314 162315 sim: silence stamp touch rules 162316 We pretty much never care about these stamp touches, so silence them. 162317 Also switch to using $@ when it makes sense. 162318 162319 sim: standardize move-if-change rules 162320 Use the srcroot path and make them all silent. 162321 162322 sim: mips/v850: remove redundant variable setup 162323 The common/Make-common.in fragment already provides these variables. 162324 1623252021-10-31 Orgad Shaneh <orgads@gmail.com> 162326 162327 sim: fix compilation on mingw64 [PR sim/28476] 162328 ...by reordering includes. 162329 162330 1. sim-utils.c 162331 162332 sim/mips/sim-main.h defines UserMode, while there is a struct in winnt.h 162333 which has UserMode as a member. So if sim-main.h is included before winnt.h, 162334 compilation fails. 162335 162336 2. ppc 162337 162338 registers.h defines CR, which is used as a member in winnt.h. 162339 162340 winsock2.h is included by sys/time.h, so sys/time.h has to be included 162341 before registers.h. 162342 162343 Bug: https://sourceware.org/PR28476 162344 1623452021-10-31 Alan Modra <amodra@gmail.com> 162346 162347 Don't include coff/pe.h in coff-x86_64.c 162348 This (and other) code from coffcode.h is broken for x86_64_coff_vec, 162349 and has been ever since support was added in 2006 commit 99ad839030c1 162350 Here, bfd_coff_aoutsz must match coff_swap_aouthdr_out otherwise we 162351 end up writing garbage. 162352 162353 /* Note that peicode.h fills in a PEAOUTHDR, not an AOUTHDR. 162354 include/coff/pe.h sets AOUTSZ == sizeof (PEAOUTHDR)). */ 162355 char * buff; 162356 bfd_size_type amount = bfd_coff_aoutsz (abfd); 162357 162358 buff = (char *) bfd_malloc (amount); 162359 if (buff == NULL) 162360 return false; 162361 162362 coff_swap_aouthdr_out (abfd, & internal_a, buff); 162363 amount = bfd_bwrite (buff, amount, abfd); 162364 162365 We have removed support for --target=x86_64-coff, likely because it 162366 never worked properly, but still produce coff-x86_64.o with 162367 --enable-targets=all. This means objcopy can recognize x86_64 COFF 162368 files but will write garbage to the output file, a fact found by 162369 fuzzers. I suspect x86_64 COFF is still broken after this fix, and 162370 mention of coff-x86_64.* should be removed from bfd/Makefile.am. 162371 162372 * coff-x86_64.c: Don't include coff/pe.h. 162373 (COFF_WITH_pex64): Don't define here. 162374 * pe-x86_64.c: Include coff/pe.h and other headers. 162375 (PEI_HEADERS): Define. 162376 1623772021-10-31 Alan Modra <amodra@gmail.com> 162378 162379 Re: PR28420, ecoff fuzzing failures 162380 sym_ptr_ptr NULL results in segfaults. 162381 162382 PR 28420 162383 * ecoff.c (ecoff_slurp_reloc_table): Don't leave sym_ptr_ptr NULL. 162384 1623852021-10-31 Alan Modra <amodra@gmail.com> 162386 162387 ubsan: alpha-vms: undefined shift 162388 * vms-alpha.c (evax_bfd_print_image): Shift left 1u. 162389 162390 PR28518: signed integer overflow & free on unmalloced address 162391 PR 28518 162392 * vms-alpha.c (build_module_list): Don't lose malloc buffer address. 162393 Use unsigned variables. 162394 1623952021-10-31 GDB Administrator <gdbadmin@sourceware.org> 162396 162397 Automatic date update in version.in 162398 1623992021-10-30 Simon Marchi <simon.marchi@polymtl.ca> 162400 162401 gdb: fix gdb.gdb/unittest.exp with C++17 compiler 162402 On a machine with gcc 11, I get: 162403 162404 FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_v" (second tab) (timeout) 162405 FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_vie" (timeout) 162406 162407 That's because when compiling with C++ >= 17, we use the standard 162408 version of string_view, and don't have a selftest for it. So the list 162409 of selftests shown by the tab completion when completing "string_v" 162410 differs. 162411 162412 Change the test to use the copy_* tests instead. 162413 162414 Change-Id: I85f6aa44ee5fc9652b9bd4451e0506b89773526b 162415 1624162021-10-30 Aaron Merey <amerey@redhat.com> 162417 162418 gdb.texinfo: Expand documentation for debuginfod 162419 Add section describing GDB's usage of debuginfod. 162420 162421 Refer to this new section in the description of the '--with-debuginfod' 162422 configure option. 162423 162424 Mention debuginfod in the 'Separate Debug Files' section. 162425 1624262021-10-30 Aaron Merey <amerey@redhat.com> 162427 162428 gdb: add set/show commands for managing debuginfod 162429 Add 'set debuginfod' command. Accepts 'on', 'off' or 'ask' as an 162430 argument. 'on' enables debuginfod for the current session. 'off' 162431 disables debuginfod for the current session. 'ask' will prompt 162432 the user to either enable or disable debuginfod when the next query 162433 is about to be performed: 162434 162435 This GDB supports auto-downloading debuginfo from the following URLs: 162436 <URL1> <URL2> ... 162437 Enable debuginfod for this session? (y or [n]) y 162438 Debuginfod has been enabled. 162439 To make this setting permanent, add 'set debuginfod on' to .gdbinit. 162440 162441 For interactive sessions, 'ask' is the default. For non-interactive 162442 sessions, 'off' is the default. 162443 162444 Add 'show debuginfod status' command. Displays whether debuginfod 162445 is set to 'on', 'off' or 'ask'. 162446 162447 Add 'set/show debuginfod urls' commands. Accepts a string of 162448 space-separated debuginfod server URLs to be queried. The default 162449 value is copied from the DEBUGINFOD_URLS environment variable. 162450 162451 Finally add 'set/show debuginfod verbose' commands to control whether 162452 debuginfod-related output is displayed. Verbose output is enabled 162453 by default. 162454 162455 (gdb) run 162456 Starting program: /bin/sleep 5 162457 Download failed: No route to host. Continuing without debug info for /lib64/libc.so.6. 162458 162459 If GDB is not built with debuginfod then these commands will just display 162460 162461 Support for debuginfod is not compiled into GDB. 162462 1624632021-10-30 GDB Administrator <gdbadmin@sourceware.org> 162464 162465 Automatic date update in version.in 162466 1624672021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162468 162469 gdb: remove TYPE_FIELD_DWARF_BLOCK 162470 Remove TYPE_FIELD_DWARF_BLOCK, replace with type::field + 162471 field::loc_dwarf_block. 162472 162473 Change-Id: I10af9410bb5f46d342b8358a7956998c7e804b64 162474 1624752021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162476 162477 gdb: remove TYPE_FIELD_STATIC_PHYSADDR 162478 Remove TYPE_FIELD_STATIC_PHYSADDR replace with type::field + 162479 field::loc_physaddr. 162480 162481 Change-Id: Ica9bc4a48f34750ec82ec86c298d3ecece81bcbd 162482 1624832021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162484 162485 gdb: remove TYPE_FIELD_STATIC_PHYSNAME 162486 Remove TYPE_FIELD_STATIC_PHYSNAME, replace with type::field + 162487 field::loc_physname. 162488 162489 Change-Id: Ie35d446b67dd1d02f39998b406001bdb7e6d5abb 162490 1624912021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162492 162493 gdb: remove TYPE_FIELD_ENUMVAL 162494 Remove TYPE_FIELD_ENUMVAL, replace with type::field + 162495 field::loc_enumval. 162496 162497 Change-Id: I2ada73e4635aad3363ce2eb22c1dc52698ee2072 162498 1624992021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162500 162501 gdb: remove TYPE_FIELD_BITPOS 162502 Remove TYPE_FIELD_BITPOS, replace its uses with type::field + 162503 field::loc_bitpos. 162504 162505 Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320 162506 1625072021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162508 162509 gdb: remove TYPE_FIELD_LOC_KIND 162510 Remove TYPE_FIELD_LOC_KIND, replace its uses with type::field + 162511 field::loc_kind. 162512 162513 Change-Id: Ib124a26365df82ac1d23df7962d954192913bd90 162514 1625152021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162516 162517 gdb: remove FIELD_DWARF_BLOCK macro 162518 Remove FIELD_DWARF_BLOCK, replace its uses with field::loc_dwarf_block. 162519 162520 Change-Id: I66b7d6a960cb5e341e61e21bd3cc9a6ac26de6a8 162521 1625222021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162523 162524 gdb: remove FIELD_STATIC_PHYSADDR macro 162525 Remove FIELD_LOC_KIND_PHYSADDR, replace its uses with 162526 field::loc_physaddr. 162527 162528 Change-Id: Ifd8b2bdaad75f42bfb1404ef8c396ffe7e10ac55 162529 1625302021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162531 162532 gdb: remove FIELD_STATIC_PHYSNAME macro 162533 Remove FIELD_STATIC_PHYSNAME, replace its uses with field::loc_physname. 162534 162535 Change-Id: Iaa8952410403b4eb5bbd68411feea27e2405d657 162536 1625372021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162538 162539 gdb: remove FIELD_ENUMVAL macro 162540 Remove FIELD_ENUMVAL, replace its uses with field::loc_enumval. 162541 162542 Change-Id: Id4861cee91a8bb583a9836f1aa5da0a320fbf4d9 162543 1625442021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162545 162546 gdb: remove FIELD_BITPOS macro 162547 Remove FIELD_BITPOD, replace its uses with field::loc_bitpos. 162548 162549 Change-Id: Idb99297e0170661254276c206383a7e9bf1a935a 162550 1625512021-10-29 Simon Marchi <simon.marchi@polymtl.ca> 162552 162553 gdb: remove FIELD_LOC_KIND macro 162554 Remove FIELD_LOC_KIND, replace its uses with field::loc_kind or 162555 call_site_target::loc_kind. 162556 162557 Change-Id: I0368d8c3ea269d491bb215aa70e32edbdf55f389 162558 1625592021-10-29 Tom Tromey <tromey@adacore.com> 162560 162561 Add gdb.Architecture.integer_type Python function 162562 This adds a new Python function, gdb.Architecture.integer_type, which 162563 can be used to look up an integer type of a given size and 162564 signed-ness. This is useful to avoid dependency on debuginfo when a 162565 particular integer type would be useful. 162566 162567 v2 moves this to be a method on gdb.Architecture and addresses other 162568 review comments. 162569 1625702021-10-29 Tom Tromey <tromey@adacore.com> 162571 162572 Remove ada_value_print_inner 162573 I noticed that the only caller of ada_value_print_inner is 162574 valprint.c:do_val_print (via ada_language::value_print_inner), meaning 162575 that the try/catch logic in this function is redundant. This patch 162576 removes the wrapper function. 162577 162578 Regression tested on x86-64 Fedora 34. 162579 1625802021-10-29 Tom Tromey <tromey@adacore.com> 162581 162582 Document resolve_dynamic_type oddity 162583 Today I re-learned that resolve_dynamic_type can return a type for 162584 which is_dynamic_type returns true. This can happen for an array 162585 whose elements have dynamic type -- the array is reported as dynamic, 162586 but resolving the elements would be incorrect, because each element 162587 might have a different type after resolution. 162588 162589 You can see the special case in resolve_dynamic_array_or_string: 162590 162591 if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY) 162592 ... 162593 else 162594 ... 162595 162596 I looked into having the TYPE_CODE_ARRAY case in 162597 is_dynamic_type_internal follow this same logic, but that breaks down 162598 on the gdb.fortran/dynamic-ptype-whatis.exp test case. In particular 162599 this code in fortran_undetermined::evaluate: 162600 162601 value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside); 162602 if (noside == EVAL_AVOID_SIDE_EFFECTS 162603 && is_dynamic_type (value_type (callee))) 162604 callee = std::get<0> (m_storage)->evaluate (nullptr, exp, EVAL_NORMAL); 162605 162606 ... relies on is_dynamic_type returning true for such an array. 162607 162608 I wasn't really sure of the best way to fix this, so in the meantime I 162609 wrote this patch, which documents the oddity so that I might have a 162610 chance of remembering this in the future. 162611 1626122021-10-29 Tom Tromey <tromey@adacore.com> 162613 162614 Avoid self-test failures on x86-linux 162615 The disassembly tests in "maint selftest" will fail on x86-linux. 162616 This happens because opcodes rejects an attempt to disassemble for an 162617 arch with a 64-bit address size when bfd_vma is 32-bit. 162618 162619 This patch avoids this problem by avoiding the test in this case. I 162620 chose to do it this way because this seems to be the only situation 162621 where opcodes checks the size of bfd_vma. 162622 162623 For v2 of this patch, I've also updated memory_error_test to do the 162624 same thing. This is needed due to the "improve error reporting from 162625 the disassembler" patch. 162626 1626272021-10-29 Tom de Vries <tdevries@suse.de> 162628 162629 [gdb/build] Fix build with --disable-unit-tests 162630 A build with --disable-unit-tests currently run into: 162631 ... 162632 ld: maint.o: in function \ 162633 `maintenance_selftest_completer(cmd_list_element*, completion_tracker&, 162634 char const*, char const*)': 162635 src/gdb/maint.c:1183: undefined reference to \ 162636 `selftests::for_each_selftest( 162637 gdb::function_view< 162638 void (std::__cxx11::basic_string<char,std::char_traits<char>, 162639 std::allocator<char> > const&)>)' 162640 ... 162641 162642 Fix this by guarding the call to selftests::for_each_selftest in 162643 maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose" 162644 completion still works. 162645 162646 Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp. 162647 1626482021-10-29 Enze Li <lienze2010@hotmail.com> 162649 162650 Document "memory-tag-violations". 162651 * gdb/doc/gdb.texinfo: (Data): Document '-memory-tag-violations'. 162652 (Command Options): Update the example. 162653 1626542021-10-29 Tejas Belagod <tejas.belagod@arm.com> 162655 162656 Support for a new pacbti unwind opcode. 162657 This patch adds readelf support for decoding the exception table 162658 opcode for restoring the RA_AUTH_CODE pseudo register defined by the 162659 EHABI 162660 (https://github.com/ARM-software/abi-aa/releases/download/2021Q1/ehabi32.pdf 162661 Section 10.3). 162662 162663 * readelf.c (decode_arm_unwind_bytecode): Add support to decode 162664 restoring RA_AUTH_CODE pseudo register. 162665 1626662021-10-29 Alan Modra <amodra@gmail.com> 162667 162668 Re: arm: add unwinder encoding support for PACBTI 162669 Move the gas testsuite files to where they belong. 162670 1626712021-10-29 Alan Modra <amodra@gmail.com> 162672 162673 ELF core file size checks 162674 Catch fuzzed segments where p_offset + p_filesz wraps, and limit error 162675 output. 162676 162677 * elfcore.h (elf_core_file_p): Rewrite segment checks using 162678 bfd_get_file_size. Set read_only on file size errors. 162679 * elfcode.h (elf_swap_shdr_in): Don't repeat error message. 162680 1626812021-10-29 Alan Modra <amodra@gmail.com> 162682 162683 obcopy vs. files with silly section alignment 162684 We already ignore stupid segment alignment when rewriting headers, 162685 ignore section alignment too. 162686 162687 * elf.c (rewrite_elf_program_header): Ignore section alignment 162688 power greater than 62. 162689 1626902021-10-29 GDB Administrator <gdbadmin@sourceware.org> 162691 162692 Automatic date update in version.in 162693 1626942021-10-28 Stafford Horne <shorne@gmail.com> 162695 162696 gdb: Add OpenRISC gdbserver and native config news 162697 The previous patches added gdbserver and native debugging support 162698 for OpenRISC targets. This patch documents that in the news. 162699 162700 gdb: or1k: add single step for linux native debugging 162701 Needed for single stepping in Linux, this adds the or1k implementation 162702 of or1k_software_single_step. Most of the implementation is borrowed 162703 from the bare metal single step code from or1k_single_step_through_delay 162704 which has been extracted and shared in helper function 162705 or1k_delay_slot_p. 162706 1627072021-10-28 Stafford Horne <shorne@gmail.com> 162708 162709 gdb: or1k: add native linux support 162710 This patch adds support for running gdb natively on OpenRISC linux. 162711 Debugging support is provided via the linux PTRACE interface which is 162712 mostly handled by GDB genric code. This patch provides the logic of how 162713 to read and write the ptrace registers between linux and GDB. 162714 162715 Single stepping is privided in a separate patch. 162716 1627172021-10-28 Stafford Horne <shorne@gmail.com> 162718 162719 gdb: or1k: add generated linux descriptor file 162720 162721 gdb: or1k: fixup linux regcache comment 162722 The old comment was not properly updated from the RISC-V example used. 162723 Update it to match OpenRISC. 162724 1627252021-10-28 Stafford Horne <shorne@gmail.com> 162726 162727 gdb: or1k: implement gdb server 162728 This patch adds gdbserver support for OpenRISC. This has been used for 162729 debugging the glibc port that in being worked on here: 162730 162731 https://github.com/openrisc/or1k-glibc/tree/or1k-port-2 162732 162733 Hence the comment about registers definitions being inline with glibc. 162734 1627352021-10-28 Christian Biesinger <cbiesinger@google.com> 162736 162737 [sim] Include defs.h in ppc/hw_memory.c 162738 To fix this error (seen on cygwin): 162739 /../../sim/ppc/../common ../../../sim/ppc/hw_memory.c 162740 In file included from ../../gnulib/import/stdlib.h:100, 162741 from ../../../sim/ppc/hw_memory.c:28: 162742 ../../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first." 162743 663 | #error "Please include config.h first." 162744 | ^~~~~ 162745 ../../gnulib/import/unistd.h:665:24: error: expected ';' before 'extern' 162746 665 | _GL_INLINE_HEADER_BEGIN 162747 | ^ 162748 | ; 162749 ../../gnulib/import/unistd.h:2806:22: error: expected ';' before 'extern' 162750 2806 | _GL_INLINE_HEADER_END 162751 | ^ 162752 | ; 162753 1627542021-10-28 Markus Klein <markus.klein@sma.de> 162755 162756 ARM assembler: Allow up to 32 single precision registers in the VPUSH and VPOP instructions. 162757 PR 28436 162758 * config/tc-arm.c (do_vfp_nsyn_push_pop_check): New function. 162759 (do_vfp_nsyn_pop): Use the new function. 162760 (do_vfp_nsyn_push): Use the new function. 162761 * testsuite/gas/arm/v8_1m-mve.s: Add new instructions. 162762 * testsuite/gas/arm/v8_1m-mve.d: Updated expected disassembly. 162763 1627642021-10-28 Simon Marchi <simon.marchi@efficios.com> 162765 162766 gdb: use ptid_t::to_string in infrun debug messages 162767 In debug messages, I think it would be more helpful to print ptid using 162768 the simple "pid.lwp.tid" notation in infrun debug messages. I am 162769 currently debugging some fork issues, and find the pid_to_str output not 162770 so useful, as it doesn't tell which process a thread belongs to. 162771 162772 It currently shows up like this: 162773 162774 [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7d95740 (LWP 892942)] at 0x55555555521f 162775 162776 With the patch, it shows up like this: 162777 162778 [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [894072.894077.0] at 0x5555555551d9 162779 162780 Change-Id: I130796d7dfb0d8e763b8358d8a6002701d80c4ea 162781 1627822021-10-28 Simon Marchi <simon.marchi@polymtl.ca> 162783 162784 gdb: add selftest name completion 162785 After the previous commit, it is easy to add completion for selftest 162786 names. Again, this is not particularly high value, but I rarely touched 162787 completion, so it served as a simple example to get some practice. 162788 162789 Change the for_each_selftest_ftype parameter to gdb::function_view, so 162790 that we can pass a lambda that captures things. 162791 162792 Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c 162793 1627942021-10-28 Tejas Belagod <Tejas.Belagod@arm.com> 162795 162796 arm: add unwinder encoding support for PACBTI 162797 This patch adds support for encoding the Return Address Authentication pseudo 162798 register - '.save {ra_auth_code}' as defined by the DWARF ABI - in the 162799 exception tables where the opcode is defined by the EHABI 162800 162801 gas/Changelog: 162802 162803 * config/tc-arm.c (arm_reg_type): Add new type REG_TYPE_PSEUDO. 162804 (reg_expected_msgs): Add message for pseudo reg type. 162805 (reg_list_els): Add new reg list type REGLIST_PSEUDO. 162806 (parse_reg_list): Handle new REGLIST_PSEUDO type. 162807 (s_arm_unwind_save_pseudo): Encode pseudo reg list save in exception 162808 tables. 162809 (s_arm_unwind_save): Handle new REG_TYPE_PSEUDO. 162810 (reg_names): Add ra_auth_code pseudo register. 162811 * testsuite/gas/arm/unwind-pacbti-m.s: New test. 162812 * testsuite/gas/arm/unwind-pacbti-m.d: New test. 162813 * testsuite/gas/arm/unwind-pacbti-m-readelf.d: New test. 162814 1628152021-10-28 Simon Marchi <simon.marchi@polymtl.ca> 162816 162817 gdb: add "maint set/show selftest verbose" commands and use process_options 162818 I saw the new -verbose switch to "maint selftests" and thought it would 162819 be nice for it to use the option framework. For example, that makes 162820 having completion easy. It's not that high value, given this is a 162821 maintenance command, but I had never used the framework myself, so it 162822 was a good way to practice. 162823 162824 This patch also adds the "maint set/show selftest verbose" setting. It 162825 would be possible to use option framework without adding the setting, 162826 but using the framework makes adding the option almost trivial, so I 162827 thought why not. 162828 162829 Change-Id: I6687faa0713ff3da60b398253211777100094144 162830 1628312021-10-28 Tom de Vries <tdevries@suse.de> 162832 162833 [gdb/testsuite] Update some test-cases to GPLv3 162834 I noticed some files in the test-suite have GPLv2 notices. 162835 162836 Update these to GPLv3. 162837 1628382021-10-28 Simon Marchi <simon.marchi@polymtl.ca> 162839 162840 gdb: add add_setshow_prefix_cmd 162841 There's a common pattern to call add_basic_prefix_cmd and 162842 add_show_prefix_cmd to add matching set and show commands. Add the 162843 add_setshow_prefix_cmd function to factor that out and use it at a few 162844 places. 162845 162846 Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd 162847 1628482021-10-28 Tom de Vries <tdevries@suse.de> 162849 162850 [gdb/testsuite] Require python in gdb.server/server-kill-python.exp 162851 I came across this when running test-case gdb.server/server-kill-python.exp 162852 with a gdb configured without python: 162853 ... 162854 builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 \ 162855 -iex set width 0 -quiet -iex set height 0 -iex set width 0 \ 162856 -ex source outputs/gdb.server/server-kill-python/file1.py^M 162857 FAIL: gdb.server/server-kill-python.exp: ensure inferior is running 162858 Executing on target: kill -9 28535 (timeout = 300) 162859 builtin_spawn -ignore SIGHUP kill -9 28535^M 162860 file1.py:1: Error in sourced command file:^M 162861 Undefined command: "import". Try "help".^M 162862 ... 162863 162864 Fix this by testing for python support in the test-case. 162865 162866 Tested on aarch64-linux (with python support disabled) and x86_64-linux (with 162867 python support enabled). 162868 1628692021-10-28 Tom de Vries <tdevries@suse.de> 162870 162871 [gdb/testsuite] Fix assembly comments in gdb.dwarf2/clang-debug-names.exp.tcl 162872 On openSUSE Leap 15.2 aarch64 I ran into: 162873 ... 162874 clang-debug-names-debug.S:72: \ 162875 Error: junk at end of line, first unrecognized character is `#' 162876 ... 162877 due to: 162878 ... 162879 71 .Ldebug_names_start: 162880 72 .short 5 # Header: version 162881 ... 162882 162883 Fix this by using the /* ... */ comment style instead: 162884 ... 162885 $ sed -i 's% #\([^"]*\)%/*\1 */%' clang-debug-names.exp.tcl 162886 ... 162887 162888 Tested on aarch64-linux and x86_64-linux. 162889 1628902021-10-28 Tom de Vries <tdevries@suse.de> 162891 162892 [gdb/symtab] Handle DW_AT_string_length with location list 162893 Consider a fortran routine where a string variable s is modified: 162894 ... 162895 subroutine f(s) 162896 character*(*) s 162897 print *, s 162898 s(1:3) = 'oof' 162899 print *, s 162900 end subroutine f 162901 ... 162902 162903 When compiling with optimization level -O1 and printing the type of 162904 variable s we get: 162905 ... 162906 $ gdb -q -batch outputs/gdb.opt/fortran-string/fortran-string \ 162907 -ex "b f" \ 162908 -ex run \ 162909 -ex "ptype s" 162910 Breakpoint 1 at 0x4006f7: file fortran-string.f90, line 21. 162911 162912 Breakpoint 1, f (s=..., _s=_s@entry=3) at fortran-string.f90:21 162913 21 subroutine f(s) 162914 type = character*1 162915 ... 162916 while with -O0 we have instead: 162917 ... 162918 type = character (3) 162919 ... 162920 162921 The problem is that the type of s is: 162922 ... 162923 <1><2d6>: Abbrev Number: 21 (DW_TAG_string_type) 162924 <2d7> DW_AT_string_length: 0xbf (location list) 162925 <2db> DW_AT_byte_size : 4 162926 ... 162927 where the DW_AT_string_length is a location list, a case that is not handled 162928 by attr_to_dynamic_prop. 162929 162930 Fix this by handling attr->form_is_section_offset () in attr_to_dynamic_prop. 162931 162932 Tested on x86_64-linux. 162933 162934 The test-case is based on gdb.opt/fortran-string.exp from 162935 https://src.fedoraproject.org/rpms/gdb/raw/f32/f/gdb-archer-vla-tests.patch . 162936 I've updated the copyrights to stretch to 2021. 162937 162938 [ I've tried to create a dwarf assembly test-case for this, but didn't 162939 manage. ] 162940 162941 Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> 162942 162943 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26910 162944 1629452021-10-28 Kavitha Natarajan <kavitha.natarajan@amd.com> 162946 162947 [gdb/testsuite] Initialize anonymous union in gdb.cp/koenig.cc 162948 GDB test fails while running the test case gdb.cp/koenig.exp using 162949 clang compiler: 162950 [...] 162951 p foo (p_union) 162952 No symbol "p_union" in current context. 162953 (gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union) 162954 [...] 162955 162956 In the testcase, "p_union" is an unused/uninitialized variable of 162957 anonymous union type. Clang does not emit symbol for unused anonymous 162958 union/struct variables at any optimization level. Since the compiler 162959 itself is not emitting the symbol for "p_union", debug info is also 162960 not emitted when built with debug option. If the anonymous union is 162961 initialized (or used), then clang emits the symbol "p_union" which 162962 enables emitting debug info for "p_union". 162963 [...] 162964 p foo (p_union) 162965 Cannot resolve function foo to any overloaded instance 162966 (gdb) PASS: gdb.cp/koenig.exp: p foo (p_union) 162967 [...] 162968 1629692021-10-28 Alan Modra <amodra@gmail.com> 162970 162971 asan: mmo: NULL dereferenc in mmo_xore_32 162972 mmo_get_loc can return NULL. It's commented even, and that the caller 162973 then must handle a split field. mmo_xore_* don't handle split fields, 162974 instead just segfault. Stop that happening, and refuse to recognise 162975 fuzzed mmo files that trigger this problem. 162976 162977 * mmo.c (mmo_get_loc): Don't declare inline. 162978 (mmo_xore_64, mmo_xore_32, mmo_xore_16): Remove forward decls. 162979 Return pointer, don't dereference NULL. 162980 (mmo_scan): Return error on mmo_get_loc returning NULL. 162981 1629822021-10-28 Alan Modra <amodra@gmail.com> 162983 162984 bfd: remove use of INLINE 162985 No need to use anything fancy, plain inline works just as well. 162986 162987 * bfd-in.h (INLINE): Don't define. 162988 * bfd-in2.h: Regenerate. 162989 * aoutx.h: Replace use of INLINE with inline. 162990 * elf-eh-frame.c: Likewise. 162991 * elf32-score7.c: Likewise. 162992 * elfxx-mips.c: Likewise. 162993 * ihex.c: Likewise. 162994 * mach-o.c: Likewise. 162995 * mmo.c: Likewise. 162996 1629972021-10-28 Alan Modra <amodra@gmail.com> 162998 162999 ASSERT in empty output section with address 163000 * ldlang.c (lang_do_assignments_1): Correct "dot" inside ignored 163001 sections. 163002 * testsuite/ld-scripts/empty-address-4.d, 163003 * testsuite/ld-scripts/empty-address-4.s, 163004 * testsuite/ld-scripts/empty-address-4.t: New test. 163005 * testsuite/ld-scripts/empty-address.exp: Run it. 163006 1630072021-10-28 GDB Administrator <gdbadmin@sourceware.org> 163008 163009 Automatic date update in version.in 163010 1630112021-10-27 Alan Modra <amodra@gmail.com> 163012 163013 asan: alpha-vms: buffer overflows 163014 Yet more anti-fuzzer sanity checking 163015 163016 * vms-alpha.c (evax_bfd_print_egsd): Sanity check record and 163017 name lengths before access. 163018 (evax_bfd_print_etir_stc_ir, evax_bfd_print_etir): Likewise. 163019 1630202021-10-27 Alan Modra <amodra@gmail.com> 163021 163022 ubsan: arm: undefined shift 163023 left shift of 2 by 31 places cannot be represented in type 'int' 163024 163025 * arm-dis.c (print_insn_thumb16): Avoid undefined behaviour. 163026 1630272021-10-27 Tom Tromey <tromey@adacore.com> 163028 163029 Fix watchpoints with multiple threads on Windows 163030 A recent internal change pointed out that watchpoints were not working 163031 on Windows when the inferior was multi-threaded. This happened 163032 because the debug registers were only updated for certain threads -- 163033 in particular, those that were being resumed and that were not marked 163034 as suspended. In the case of single-stepping, the need to update the 163035 debug registers in other threads could also be "forgotten". 163036 163037 This patch changes windows-nat.c to mark all threads needing a debug 163038 register update. This brings the code closer to what gdbserver does 163039 (though, unfortunately, it still seems more complicated than needed). 163040 1630412021-10-27 Tom de Vries <tdevries@suse.de> 163042 163043 [gdb/testsuite] Fix port detection in gdb.debuginfod/fetch_src_and_symbols.exp 163044 On OBS I ran into this failure with test-case 163045 gdb.debuginfod/fetch_src_and_symbols.exp: 163046 ... 163047 Failed to listen for connections: Address already in use^M 163048 [Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M 163049 ... 163050 FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout 163051 ... 163052 163053 The test-case is trying to start debuginfod on a port to see if it's 163054 available, and it handles either this message: 163055 "started http server on IPv4 IPv6 port=$port" 163056 meaning success, or: 163057 "failed to bind to port" 163058 meaning failure, in which case the debuginfod instance is killed, and we try 163059 the next port. 163060 163061 The test-case only uses the v4 address 127.0.0.1, so fix this by: 163062 - accepting "started http server on IPv4 port=$port" 163063 - rejecting "started http server on IPv6 port=$port" 163064 163065 Tested on x86_64-linux. 163066 1630672021-10-27 Simon Marchi <simon.marchi@efficios.com> 163068 163069 gdb: fix value.c build on 32-bits 163070 When building on ARM (32-bits), we errors like this: 163071 163072 /home/smarchi/src/binutils-gdb/gdb/value.c: In function 'gdb::array_view<const unsigned char> value_contents_for_printing(value*)': 163073 /home/smarchi/src/binutils-gdb/gdb/value.c:1252:35: error: narrowing conversion of 'length' from 'ULONGEST' {aka 'long long unsigned int'} to 'size_t' {aka 'unsigned int'} [-Werror=narrowing] 163074 1252 | return {value->contents.get (), length}; 163075 | ^~~~~~ 163076 163077 Fix that by using gdb::make_array_view, which does the appropriate 163078 conversion. 163079 163080 Change-Id: I7d6f2e75d7440d248b8fb18f8272ee92954b404d 163081 1630822021-10-27 Nelson Chu <nelson.chu@sifive.com> 163083 163084 RISC-V: Tidy riscv assembler and disassembler. 163085 Tidy the gas/config/tc-riscv.c and opcodes/riscv-dis.c, to prepare for 163086 moving the released extensions (including released vendor extensions) 163087 from integration branch back to mainline. 163088 163089 * Added parts of missing comments. 163090 163091 * Updated md_show_usage. 163092 163093 * For validate_riscv_insn, riscv_ip and print_insn_args, unify the 163094 following pointer names, 163095 - oparg: pointed to the parsed operand defined in the riscv_opcodes. 163096 - asarg: pointed to the parsed operand from assembly. 163097 - opargStart: recorded the parsed operand name from riscv_opcodes. 163098 - asargStart: recorded the parsed operand name from assembly. 163099 163100 gas/ 163101 * config/tc-riscv.c: Added parts of missind comments and updated 163102 the md_show_usage. 163103 (riscv_multi_subset_supports): Tidy codes. 163104 (validate_riscv_insn): Unify the pointer names, oparg, asarg, 163105 opargStart and asargStart, to prepare for moving the released 163106 extensions from integration branch back to mainline. 163107 (riscv_ip): Likewise. 163108 (macro_build): Added fmtStart, also used to prepare for moving 163109 released extensions. 163110 (md_show_usage): Added missing descriptions for new options. 163111 opcodes/ 163112 * riscv-dis.c (print_insn_args): Unify the pointer names, 163113 oparg and opargStart, to prepare for moving the released 163114 extensions from integration branch back to mainline. 163115 1631162021-10-27 Maciej W. Rozycki <macro@embecosm.com> 163117 163118 opcodes: Fix RPATH not being set for dynamic libbfd dependency 163119 If built as a shared library, libopcodes has a load-time dependency on 163120 libbfd, which is recorded in the dynamic section, however without a 163121 corresponding RPATH entry for the directory to find libbfd in. This 163122 causes loading to fail whenever libbfd is only pulled by libopcodes 163123 indirectly and libbfd has been installed in a directory that is not in 163124 the dynamic loader's search path. 163125 163126 It does not happen with the programs included with binutils or GDB, 163127 because they all also pull libbfd when using libopcodes, but it can 163128 happen with external software, e.g.: 163129 163130 $ gdbserver --help 163131 gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory 163132 $ 163133 163134 (not our `gdbserver'). 163135 163136 Indirect dynamic dependencies are handled by libtool automatically by 163137 adding RPATH entries as required, however our setup for libopcodes 163138 prevents this from happening by linking in libbfd with an explicit file 163139 reference sneaked through to the linker directly behind libtool's back 163140 via the `-Wl' linker command-line option rather than via `-l' combined 163141 with a suitable library search path specified via `-L', as it would be 163142 usually the case, or just referring to the relevant .la file in a fully 163143 libtool-enabled configuration such as ours. 163144 163145 According to an observation in the discussion back in 2007[1][2][3] that 163146 has led to the current arrangement it is to prevent libtool from picking 163147 up the wrong version of libbfd. It does not appear to be needed though, 163148 not at least with our current libtool incarnation, as directly referring 163149 `libbfd.la' does exactly what it should, as previously suggested[4], and 163150 with no link-time reference to the installation directory other than to 163151 set RPATH. Uninstalled version of libopcodes has libbfd's build-time 163152 location prepended to RPATH too, as also expected. 163153 163154 Use a direct reference to `libbfd.la' then, making the load error quoted 163155 above go away. Alternatively `-L' and `-l' could be used to the same 163156 effect, but it seems an unnecessary complication and just another way to 163157 circumvent rather than making use of libtool. 163158 163159 References: 163160 163161 [1] "compile failure due to undefined symbol", 163162 <https://sourceware.org/ml/binutils/2007-08/msg00476.html> 163163 163164 [2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html> 163165 163166 [3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html> 163167 163168 [4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html> 163169 163170 opcodes/ 163171 * Makefile.am: Remove obsolete comment. 163172 * configure.ac: Refer `libbfd.la' to link shared BFD library 163173 except for Cygwin. 163174 * Makefile.in: Regenerate. 163175 * configure: Regenerate. 163176 1631772021-10-27 GDB Administrator <gdbadmin@sourceware.org> 163178 163179 Automatic date update in version.in 163180 1631812021-10-27 H.J. Lu <hjl.tools@gmail.com> 163182 163183 gold: Place .note.gnu.property section before other note sections 163184 Place the .note.gnu.property section before all other note sections to 163185 avoid being placed between other note sections with different alignments. 163186 163187 PR gold/28494 163188 * layout.cc (Layout::create_note): Set order to ORDER_PROPERTY_NOTE 163189 for the .note.gnu.property section. 163190 * layout.h (Output_section_order): Add ORDER_PROPERTY_NOTE. 163191 1631922021-10-26 Tom de Vries <tdevries@suse.de> 163193 163194 [gdb/doc] Fix print inferior-events default 163195 In the docs about print inferior-events we read: 163196 ... 163197 By default, these messages will not be printed. 163198 ... 163199 163200 That used to be the case, but is no longer so since commit f67c0c91715 "Enable 163201 'set print inferior-events' and improve detach/fork/kill/exit messages". 163202 163203 Fix this by updating the docs. 163204 1632052021-10-26 GDB Administrator <gdbadmin@sourceware.org> 163206 163207 Automatic date update in version.in 163208 1632092021-10-25 Simon Marchi <simon.marchi@polymtl.ca> 163210 163211 gdb: change functions returning value contents to use gdb::array_view 163212 The bug fixed by this [1] patch was caused by an out-of-bounds access to 163213 a value's content. The code gets the value's content (just a pointer) 163214 and then indexes it with a non-sensical index. 163215 163216 This made me think of changing functions that return value contents to 163217 return array_views instead of a plain pointer. This has the advantage 163218 that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view 163219 are checked, making bugs more apparent / easier to find. 163220 163221 This patch changes the return types of these functions, and updates 163222 callers to call .data() on the result, meaning it's not changing 163223 anything in practice. Additional work will be needed (which can be done 163224 little by little) to make callers propagate the use of array_view and 163225 reap the benefits. 163226 163227 [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html 163228 163229 Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3 163230 1632312021-10-25 Simon Marchi <simon.marchi@efficios.com> 163232 163233 gdbsupport: add assertions in array_view 163234 Add assertions to ensure we don't access an array_view out of bounds. 163235 Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for 163236 gdb::optional. 163237 163238 Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3 163239 1632402021-10-25 Simon Marchi <simon.marchi@polymtl.ca> 163241 163242 gdbserver: make target_pid_to_str return std::string 163243 I wanted to write a warning that included two target_pid_to_str calls, 163244 like this: 163245 163246 warning (_("Blabla %s, blabla %s"), 163247 target_pid_to_str (ptid1), 163248 target_pid_to_str (ptid2)); 163249 163250 This doesn't work, because target_pid_to_str stores its result in a 163251 static buffer, so my message would show twice the same ptid. Change 163252 target_pid_to_str to return an std::string to avoid this. I don't think 163253 we save much by using a static buffer, but it is more error-prone. 163254 163255 Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2 163256 1632572021-10-25 H.J. Lu <hjl.tools@gmail.com> 163258 163259 x86: Also handle stores for -muse-unaligned-vector-move 163260 * config/tc-i386.c (encode_with_unaligned_vector_move): Also 163261 handle stores. 163262 * testsuite/gas/i386/unaligned-vector-move.s: Add stores. 163263 * testsuite/gas/i386/unaligned-vector-move.d: Updated. 163264 * testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise. 163265 1632662021-10-25 Tom de Vries <tdevries@suse.de> 163267 163268 [gdb/testsuite] Fix duplicate in gdb.mi/mi-var-cp.exp 163269 With test-case gdb.mi/mi-var-cp.exp I run into this duplicate: 163270 ... 163271 PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint) 163272 PASS: gdb.mi/mi-var-cp.exp: create varobj for s 163273 PASS: gdb.mi/mi-var-cp.exp: create varobj for s 163274 DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s 163275 ... 163276 163277 This is due to a duplicate test name here: 163278 ... 163279 $ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc 163280 ... 163281 100 int reference_to_struct () 163282 101 { 163283 102 /*: BEGIN: reference_to_struct :*/ 163284 103 S s = {7, 8}; 163285 104 S& r = s; 163286 105 /*: 163287 106 mi_create_varobj S s "create varobj for s" 163288 107 mi_create_varobj R r "create varobj for s" 163289 ... 163290 163291 Fix this by using "create varobj for r" instead. 163292 163293 Tested on x86_64-linux. 163294 1632952021-10-25 Nick Alcock <nick.alcock@oracle.com> 163296 163297 libctf, ld: handle nonrepresentable types better 163298 ctf_type_visit (used, among other things, by the type dumping code) was 163299 aborting when it saw a nonrepresentable type anywhere: even a single 163300 structure member with a nonrepresentable type caused an abort with 163301 ECTF_NONREPRESENTABLE. This is not useful behaviour, given that the 163302 abort comes from a type-resolution we are only doing in order to 163303 determine whether the type is a structure or union. We know 163304 nonrepresentable types can't be either, so handle that case and 163305 pass the nonrepresentable type down. 163306 163307 (The added test verifies that the dumper now handles this case and 163308 prints nonrepresentable structure members as it already does 163309 nonrepresentable top-level types, rather than skipping the whole 163310 structure -- or, without the previous commit, skipping the whole types 163311 section.) 163312 163313 ld/ChangeLog 163314 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163315 163316 * testsuite/ld-ctf/nonrepresentable-member.*: New test. 163317 163318 libctf/ChangeLog 163319 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163320 163321 * ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types. 163322 1633232021-10-25 Nick Alcock <nick.alcock@oracle.com> 163324 163325 libctf: dump: do not stop dumping types on error 163326 If dumping of a single type fails, we obviously can't dump it; but just 163327 as obviously this doesn't make the other types in the types section 163328 invalid or undumpable. So we should not propagate errors seen when 163329 type-dumping, but rather ignore them and carry on, so we dump as many 163330 types as we can (leaving out the ones we can't grok). 163331 163332 libctf/ChangeLog 163333 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163334 163335 * ctf-dump.c (ctf_dump_type): Do not abort on error. 163336 1633372021-10-25 Nick Alcock <nick.alcock@oracle.com> 163338 163339 binutils, ld: make objdump --ctf's parameter optional 163340 ld by default (and always, unless adjusted with a hand-rolled linker 163341 script) emits deduplicated CTF into the .ctf section. But viewing 163342 it needs you to explicitly tell objdump this: it doesn't default 163343 its argument, even though what you always end up typing is 163344 --ctf=.ctf. 163345 163346 This is annoying, so make the argument optional. 163347 163348 binutils/ChangeLog 163349 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163350 163351 * objdump.c (usage): --ctf now has an optional argument. 163352 (main): Adjust accordingly. 163353 (dump_ctf): Default it. 163354 * doc/ctf.options.texi: Adjust. 163355 163356 ld/ChangeLog 163357 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163358 163359 * testsuite/ld-ctf/array.d: Change --ctf=.ctf to --ctf. 163360 * testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise. 163361 * testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise. 163362 * testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise. 163363 * testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise. 163364 * testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise. 163365 * testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise. 163366 * testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise. 163367 * testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise. 163368 * testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise. 163369 * testsuite/ld-ctf/conflicting-enums.d: Likewise. 163370 * testsuite/ld-ctf/conflicting-typedefs.d: Likewise. 163371 * testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise. 163372 * testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise. 163373 * testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise. 163374 * testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise. 163375 * testsuite/ld-ctf/cycle-1.d: Likewise. 163376 * testsuite/ld-ctf/cycle-2.A.d: Likewise. 163377 * testsuite/ld-ctf/cycle-2.B.d: Likewise. 163378 * testsuite/ld-ctf/cycle-2.C.d: Likewise. 163379 * testsuite/ld-ctf/data-func-conflicted.d: Likewise. 163380 * testsuite/ld-ctf/diag-cttname-null.d: Likewise. 163381 * testsuite/ld-ctf/diag-cuname.d: Likewise. 163382 * testsuite/ld-ctf/diag-parlabel.d: Likewise. 163383 * testsuite/ld-ctf/enum-forward.d: Likewise. 163384 * testsuite/ld-ctf/enums.d: Likewise. 163385 * testsuite/ld-ctf/forward.d: Likewise. 163386 * testsuite/ld-ctf/function.d: Likewise. 163387 * testsuite/ld-ctf/nonrepresentable.d: Likewise. 163388 * testsuite/ld-ctf/slice.d: Likewise. 163389 * testsuite/ld-ctf/super-sub-cycles.d: Likewise. 163390 1633912021-10-25 Nick Alcock <nick.alcock@oracle.com> 163392 163393 binutils: make objdump/readelf --ctf-parent actually useful 163394 This option has been present since the very early days of the 163395 development of libctf as part of binutils, and it shows. Back in the 163396 earliest days, I thought we might handle ambiguous types by introducing 163397 new ELF sections on the fly named things like .ctf.foo.c for ambiguous 163398 types found only in foo.c, etc. This turned out to be a terrible idea, 163399 so we moved to using a CTF archive in the .ctf section which contained 163400 all the CTF dictionaries -- but the --ctf-parent option in objdump and 163401 readelf was never adjusted, and lingered as a mechanism to specify CTF 163402 parent dictionaries in sections other than .ctf, even though the linker 163403 has no way to produce parent dictionaries in different sections from 163404 their children, libctf's ctf_open can't handle such split-up 163405 parent/child dicts, and they are never found in the wild, emitted by GNU 163406 ld or by any known third-party linking tool. 163407 163408 Meanwhile, the actually-useful ctf_link feature (albeit not used by ld) 163409 which lets you remap the names of CTF archive members (so you can end up 163410 with a parent archive member named something other than ".ctf", still 163411 contained with all its children in a single .ctf section) had no support 163412 in objdump or readelf: there was no way to tell them that these members 163413 were parents, so all the types in the associated child dicts always 163414 appeared corrupted, referencing nonexistent types from a parent objdump 163415 couldn't find. 163416 163417 So adjust --ctf-parent so that rather than taking a section name it 163418 takes a member name instead (if not specified, the name is ".ctf", which 163419 is what GNU ld emits). Because the option was always useless before 163420 now, this is expected to have no backward-compatibility implications. 163421 163422 As part of this, we have to slightly adjust the code which skips the 163423 archive member name if redundant: right now it skips it if it's ".ctf", 163424 on the assumption that this name will almost always be at the start 163425 of the objdump output and thus we'll end up with a shared dump 163426 and then smaller, headed dumps for the per-TU child dicts; but if 163427 the parent name has been changed, that won't be true any more. 163428 163429 So change the rules to "members named .ctf which appear first in the 163430 first have their member name skipped". Since we now need to count 163431 members, move from ctf_archive_iter (for which passing in extra 163432 parameters requires defining a new struct and is clumsy) to 163433 ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and 163434 maintain a member count in the obvious way. In the process we fix a 163435 tiny difference between readelf and objdump: if a ctf_dump ever failed, 163436 readelf skipped every later member, while objdump tried to keep going as 163437 much as it could. For a dumping tool the former is clearly preferable. 163438 163439 binutils/ChangeLog 163440 2021-10-25 Nick Alcock <nick.alcock@oracle.com> 163441 163442 * objdump.c (usage): --ctf-parent now takes a name, not a section. 163443 (dump_ctf): Don't open a separate section; use the parent_name in 163444 ctf_dict_open instead. Use ctf_archive_next, not ctf_archive_iter, 163445 so we can pass down a member count. 163446 (dump_ctf_archive_member): Add the member count; don't return 163447 anything. Import parents into children no matter what the 163448 parent's name, while still avoiding displaying the header for the 163449 common parent name of ".ctf". 163450 * readelf.c (usage): Adjust similarly. 163451 (dump_section_as_ctf): Likewise. 163452 (dump_ctf_archive_member): Likewise. Never stop iterating over 163453 archive members, even if ctf_dump of one member fails. 163454 * doc/ctf.options.texi: Adjust. 163455 1634562021-10-25 Alan Modra <amodra@gmail.com> 163457 163458 objdump doesn't accept -L option 163459 A followup to commit ca0e11aa4b. 163460 163461 * objdump.c (main): Add 'L' to short options and sort them. 163462 1634632021-10-25 Alan Modra <amodra@gmail.com> 163464 163465 bfd_nonfatal_message, localise va_start 163466 Nothing to see here, just a little tidier. 163467 163468 * bucomm.c (bfd_nonfatal_message): Localise va_list args. 163469 1634702021-10-25 Alan Modra <amodra@gmail.com> 163471 163472 ubsan: _bfd_xcoff64_swap_aux_in left shift of negative value 163473 * coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Use bfd_vma for h. 163474 163475 asan: evax_bfd_print_image buffer overflow 163476 * vms-alpha.c (evax_bfd_print_image): Sanity check printing of 163477 "image activator fixup" section. 163478 (evax_bfd_print_relocation_records): Sanity check buffer offsets. 163479 (evax_bfd_print_address_fixups): Likewise. 163480 (evax_bfd_print_reference_fixups): Likewise. 163481 1634822021-10-25 GDB Administrator <gdbadmin@sourceware.org> 163483 163484 Automatic date update in version.in 163485 1634862021-10-24 Alan Modra <amodra@gmail.com> 163487 163488 asan: c4x, c54x coff_canonicalize_reloc buffer overflow 163489 Sometimes the investigation of a fuzzing bug report leads into areas 163490 you'd rather not go. In this instance by the time I'd figured out the 163491 real cause was a target variant that had never been properly supported 163492 in binutils, the time needed to fix it was less than the time needed 163493 to rip it out. 163494 163495 * coffcode.h (coff_set_alignment_hook): Call bfd_coff_swap_reloc_in 163496 not coff_swap_reloc_in. 163497 (coff_slurp_reloc_table): Likewise. Don't use RELOC type. 163498 (ticoff0_swap_table): Use coff_swap_reloc_v0_out and 163499 coff_swap_reloc_v0_in. 163500 * coffswap.h (coff_swap_reloc_v0_in, coff_swap_reloc_v0_out): New. 163501 * coff-tic54x.c (tic54x_lookup_howto): Don't abort. 163502 * coffgen.c (coff_get_normalized_symtab): Use PTR_ADD. 163503 * bfd-in.h (PTR_ADD, NPTR_ADD): Avoid warnings when passing an 163504 expression. 163505 * bfd-in2.h: Regenerate. 163506 1635072021-10-24 Alan Modra <amodra@gmail.com> 163508 163509 asan: arm-darwin: buffer overflow 163510 PR 21813 163511 * mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Sanity 163512 check PAIR reloc in other branch of condition as was done for 163513 PR21813. Formatting. Delete debug printf. 163514 163515 asan: aout: heap buffer overflow 163516 * aoutx.h (aout_get_external_symbols): Sanity check before writing 163517 zero index entry. Remove outdated comment. 163518 * pdp11.c (aout_get_external_symbols): Likewise. 163519 1635202021-10-24 liuzhensong <liuzhensong@loongson.cn> 163521 163522 LoongArch ld support 163523 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> 163524 Zhensong Liu <liuzhensong@loongson.cn> 163525 Weinan Liu <liuweinan@loongson.cn> 163526 Xiaolin Tang <tangxiaolin@loongson.cn> 163527 163528 ld/ 163529 * Makefile.am: Add LoongArch. 163530 * NEWS: Mention LoongArch support. 163531 * configure.tgt: Add LoongArch. 163532 * emulparams/elf32loongarch-defs.sh: New. 163533 * emulparams/elf32loongarch.sh: Likewise. 163534 * emulparams/elf64loongarch-defs.sh: Likewise. 163535 * emulparams/elf64loongarch.sh: Likewise. 163536 * emultempl/loongarchelf.em: Likewise. 163537 * Makefile.in: Regenerate. 163538 * po/BLD-POTFILES.in: Regenerate. 163539 ld/testsuite/ 163540 * ld-loongarch-elf/disas-jirl.d: New. 163541 * ld-loongarch-elf/disas-jirl.s: Likewise. 163542 * ld-loongarch-elf/jmp_op.d: Likewise. 163543 * ld-loongarch-elf/jmp_op.s: Likewise. 163544 * ld-loongarch-elf/ld-loongarch-elf.exp: Likewise. 163545 * ld-loongarch-elf/macro_op.d: Likewise. 163546 * ld-loongarch-elf/macro_op.s: Likewise. 163547 * ld-loongarch-elf/syscall-0.s: Likewise. 163548 * ld-loongarch-elf/syscall-1.s: Likewise. 163549 * ld-loongarch-elf/syscall.d: Likewise. 163550 * ld-srec/srec.exp: Add LoongArch. 163551 * ld-unique/pr21529.d: Likewise. 163552 1635532021-10-24 liuzhensong <liuzhensong@loongson.cn> 163554 163555 LoongArch gas support 163556 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> 163557 Zhensong Liu <liuzhensong@loongson.cn> 163558 Weinan Liu <liuweinan@loongson.cn> 163559 Xiaolin Tang <tangxiaolin@loongson.cn> 163560 163561 gas/ 163562 * Makefile.am: Add LoongArch. 163563 * NEWS: Mention LoongArch support. 163564 * config/loongarch-lex-wrapper.c: New. 163565 * config/loongarch-lex.h: New. 163566 * config/loongarch-lex.l: New. 163567 * config/loongarch-parse.y: New. 163568 * config/tc-loongarch.c: New. 163569 * config/tc-loongarch.h: New. 163570 * configure.ac: Add LoongArch. 163571 * configure.tgt: Likewise. 163572 * doc/as.texi: Likewise. 163573 * doc/c-loongarch.texi: Likewise. 163574 * Makefile.in: Regenerate. 163575 * configure: Regenerate. 163576 * po/POTFILES.in: Regenerate. 163577 gas/testsuite/ 163578 * gas/all/gas.exp: Add LoongArch. 163579 * gas/elf/elf.exp: Likewise. 163580 * gas/loongarch/4opt_op.d: New. 163581 * gas/loongarch/4opt_op.s: Likewise. 163582 * gas/loongarch/fix_op.d: Likewise. 163583 * gas/loongarch/fix_op.s: Likewise. 163584 * gas/loongarch/float_op.d: Likewise. 163585 * gas/loongarch/float_op.s: Likewise. 163586 * gas/loongarch/imm_op.d: Likewise. 163587 * gas/loongarch/imm_op.s: Likewise. 163588 * gas/loongarch/jmp_op.d: Likewise. 163589 * gas/loongarch/jmp_op.s: Likewise. 163590 * gas/loongarch/load_store_op.d: Likewise. 163591 * gas/loongarch/load_store_op.s: Likewise. 163592 * gas/loongarch/loongarch.exp: Likewise. 163593 * gas/loongarch/macro_op.d: Likewise. 163594 * gas/loongarch/macro_op.s: Likewise. 163595 * gas/loongarch/nop.d: Likewise. 163596 * gas/loongarch/nop.s: Likewise. 163597 * gas/loongarch/privilege_op.d: Likewise. 163598 * gas/loongarch/privilege_op.s: Likewise. 163599 * gas/loongarch/syscall.d: Likewise. 163600 * gas/loongarch/syscall.s: Likewise. 163601 * lib/gas-defs.exp: Add LoongArch. 163602 1636032021-10-24 liuzhensong <liuzhensong@loongson.cn> 163604 163605 LoongArch binutils support 163606 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> 163607 Zhensong Liu <liuzhensong@loongson.cn> 163608 Weinan Liu <liuweinan@loongson.cn> 163609 binutils/ 163610 * NEWS: Mention LoongArch support. 163611 * readelf.c: Add LoongArch. 163612 * testsuite/binutils-all/objdump.exp: Add LoongArch. 163613 1636142021-10-24 liuzhensong <liuzhensong@loongson.cn> 163615 163616 LoongArch opcodes support 163617 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> 163618 Zhensong Liu <liuzhensong@loongson.cn> 163619 Weinan Liu <liuweinan@loongson.cn> 163620 163621 include/ 163622 * opcode/loongarch.h: New. 163623 * dis-asm.h: Declare print_loongarch_disassembler_options. 163624 opcodes/ 163625 * Makefile.am: Add LoongArch. 163626 * configure.ac: Likewise. 163627 * disassemble.c: Likewise. 163628 * disassemble.h: Declare print_insn_loongarch. 163629 * loongarch-coder.c: New. 163630 * loongarch-dis.c: New. 163631 * loongarch-opc.c: New. 163632 * Makefile.in: Regenerate. 163633 * configure: Regenerate. 163634 * po/POTFILES.in: Regenerate. 163635 1636362021-10-24 liuzhensong <liuzhensong@loongson.cn> 163637 163638 LoongArch bfd support 163639 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> 163640 Zhensong Liu <liuzhensong@loongson.cn> 163641 Weinan Liu <liuweinan@loongson.cn> 163642 bfd/ 163643 * Makefile.am: Add LoongArch. 163644 * archures.c: Likewise. 163645 * config.bfd: Likewise. 163646 * configure.ac: Likewise. 163647 * cpu-loongarch.c: New. 163648 * elf-bfd.h: Add LoongArch. 163649 * elf.c: Add LoongArch elfcore_grok_xxx. 163650 * elfnn-loongarch.c: New. 163651 * elfxx-loongarch.c: New. 163652 * elfxx-loongarch.h: New. 163653 * reloc.c: Add LoongArch BFD RELOC ENUM. 163654 * targets.c: Add LoongArch target. 163655 * Makefile.in: Regenerate. 163656 * bfd-in2.h: Regenerate. 163657 * configure: Regenerate. 163658 * libbfd.h: Regenerate. 163659 * po/BLD-POTFILES.in: Regenerate. 163660 * po/SRC-POTFILES.in: Regenerate. 163661 163662 include/ 163663 * elf/common.h: Add NT_LARCH_{CPUCFG,CSR,LSX,LASX}. 163664 * elf/loongarch.h: New. 163665 1636662021-10-24 GDB Administrator <gdbadmin@sourceware.org> 163667 163668 Automatic date update in version.in 163669 1636702021-10-23 GDB Administrator <gdbadmin@sourceware.org> 163671 163672 Automatic date update in version.in 163673 1636742021-10-22 H.J. Lu <hjl.tools@gmail.com> 163675 163676 x86: Add -muse-unaligned-vector-move to assembler 163677 Unaligned load/store instructions on aligned memory or register are as 163678 fast as aligned load/store instructions on modern Intel processors. Add 163679 a command-line option, -muse-unaligned-vector-move, to x86 assembler to 163680 encode encode aligned vector load/store instructions as unaligned 163681 vector load/store instructions. 163682 163683 * NEWS: Mention -muse-unaligned-vector-move. 163684 * config/tc-i386.c (use_unaligned_vector_move): New. 163685 (encode_with_unaligned_vector_move): Likewise. 163686 (md_assemble): Call encode_with_unaligned_vector_move for 163687 -muse-unaligned-vector-move. 163688 (OPTION_MUSE_UNALIGNED_VECTOR_MOVE): New. 163689 (md_longopts): Add -muse-unaligned-vector-move. 163690 (md_parse_option): Handle -muse-unaligned-vector-move. 163691 (md_show_usage): Add -muse-unaligned-vector-move. 163692 * doc/c-i386.texi: Document -muse-unaligned-vector-move. 163693 * testsuite/gas/i386/i386.exp: Run unaligned-vector-move and 163694 x86-64-unaligned-vector-move. 163695 * testsuite/gas/i386/unaligned-vector-move.d: New file. 163696 * testsuite/gas/i386/unaligned-vector-move.s: Likewise. 163697 * testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise. 163698 1636992021-10-22 Tom Tromey <tromey@adacore.com> 163700 163701 Fix 'uninstall' target 163702 This adds some missing code to the 'uninstall' targets in gdb and 163703 gdbserver. It also changes gdb's uninstall target so that it no 163704 longer tries to remove any man page -- this is already done (and more 163705 correctly) by doc/Makefile.in. 163706 163707 I tested this with 'make install' followed by 'make uninstall', then 163708 examining the install tree for regular files. Only the 'dir' file 163709 remains, but this appears to just be how 'install-info' is intended to 163710 work. 163711 1637122021-10-22 Tom Tromey <tromey@adacore.com> 163713 163714 Remove unused variables from gdbserver's Makefile 163715 This removes a number of unused variables from gdbserver's Makefile. 163716 I found these while working on the subsequent patches, and figured it 163717 would be cleaner to have a separate patch for the deletions. 163718 1637192021-10-22 Tom de Vries <tdevries@suse.de> 163720 163721 [gdb/testsuite] Fix gdb.threads/linux-dp.exp 163722 On openSUSE Tumbleweed with glibc-debuginfo installed I get: 163723 ... 163724 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print 163725 where^M 163726 #0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M 163727 #1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M 163728 #2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \ 163729 at pthread_create.c:435^M 163730 #3 0x00007ffff7ddb640 in clone3 () \ 163731 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M 163732 (gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit 163733 ... 163734 while without debuginfo installed I get instead: 163735 ... 163736 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print 163737 where^M 163738 #0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M 163739 #1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M 163740 #2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M 163741 #3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M 163742 (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit 163743 ... 163744 163745 The problem is that the regexp used: 163746 ... 163747 "\(from .*libpthread\|at pthread_create\|in pthread_create\)" 163748 ... 163749 expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has 163750 been merged into libc. 163751 163752 Fix this by updating the regexp. 163753 163754 Tested on x86_64-linux. 163755 1637562021-10-22 Tom de Vries <tdevries@suse.de> 163757 163758 [gdb/testsuite] Fix FAILs in gdb.mi/mi-breakpoint-changed.exp 163759 Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in 163760 mi_gdb_test" we run into: 163761 ... 163762 PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main 163763 Expecting: ^(-break-insert -f pendfunc1[^M 163764 ]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\ 163765 bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M 163766 ]+[(]gdb[)] ^M 163767 [ ]*) 163768 -break-insert -f pendfunc1^M 163769 ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\ 163770 addr="0x00007ffff7bd559e",func="pendfunc1",\ 163771 file="gdb/testsuite/gdb.mi/pendshr1.c",\ 163772 fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\ 163773 times="0",original-location="pendfunc1"}^M 163774 (gdb) ^M 163775 FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \ 163776 -break-insert -f pendfunc1 (unexpected output) 163777 ... 163778 163779 The regexp expects a breakpoint-created event, but that's actually suppressed 163780 by the command: 163781 ... 163782 DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert, 163783 &mi_suppress_notification.breakpoint), 163784 ... 163785 163786 Fix this by updating the regexp. 163787 163788 Likewise for the following: 163789 ... 163790 PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \ 163791 -break-insert -f pendfunc1 163792 Expecting: ^(-break-enable count 1 2[^M 163793 ]+)?(=breakpoint-modified,\ 163794 bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M 163795 ]+[(]gdb[)] ^M 163796 [ ]*) 163797 -break-enable count 1 2^M 163798 ^done^M 163799 (gdb) ^M 163800 FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \ 163801 -break-enable count 1 2 (unexpected out\ 163802 put) 163803 ... 163804 163805 Tested on x86_64-linux. 163806 1638072021-10-22 Andrew Burgess <andrew.burgess@embecosm.com> 163808 163809 gdb/python: move gdb.Membuf support into a new file 163810 In a future commit I'm going to be creating gdb.Membuf objects from a 163811 new file within gdb/python/py*.c. Currently all gdb.Membuf objects 163812 are created directly within infpy_read_memory (as a result of calling 163813 gdb.Inferior.read_memory()). 163814 163815 Initially I split out the Membuf creation code into a new function, 163816 and left the new function in gdb/python/py-inferior.c, however, it 163817 felt a little random that the Membuf creation code should live with 163818 the inferior handling code. 163819 163820 So, then I moved all of the Membuf related code out into a new file, 163821 gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which 163822 wraps an array of bytes into a gdb.Membuf object. 163823 163824 Most of the code is moved directly from py-inferior.c with only minor 163825 tweaks to layout and replacing NULL with nullptr, hence, I've left the 163826 copyright date on py-membuf.c as 2009-2021 to match py-inferior.c. 163827 163828 Currently, the only user of this code is still py-inferior.c, but in 163829 later commits this will change. 163830 163831 There should be no user visible changes after this commit. 163832 1638332021-10-22 Andrew Burgess <andrew.burgess@embecosm.com> 163834 163835 gdb/python: new gdb.architecture_names function 163836 Add a new function to the Python API, gdb.architecture_names(). This 163837 function returns a list containing all of the supported architecture 163838 names within the current build of GDB. 163839 163840 The values returned in this list are all of the possible values that 163841 can be returned from gdb.Architecture.name(). 163842 1638432021-10-22 Andrew Burgess <andrew.burgess@embecosm.com> 163844 163845 gdb: make disassembler fprintf callback a static member function 163846 The disassemble_info structure has four callbacks, we have three of 163847 them as static member functions within gdb_disassembler, the fourth is 163848 just a global static function. 163849 163850 However, this fourth callback, is still only used from the 163851 disassemble_info struct, so there's no real reason for its special 163852 handling. 163853 163854 This commit makes fprintf_disasm a static method within 163855 gdb_disassembler. 163856 163857 There should be no user visible changes after this commit. 163858 1638592021-10-22 Lewis Revill <lewis.revill@embecosm.com> 163860 163861 RISC-V: Added ld testcase for pcgp relaxation. 163862 Consider the the pcgp-relax-02 testcase, 163863 163864 .text 163865 .globl _start 163866 _start: 163867 .L1: auipc a0, %pcrel_hi(data_a) 163868 .L2: auipc a1, %pcrel_hi(data_b) 163869 addi a0, a0, %pcrel_lo(.L1) 163870 addi a1, a1, %pcrel_lo(.L2) 163871 163872 .data 163873 .word 0x0 163874 .globl data_a 163875 data_a: 163876 .word 0x1 163877 163878 .section .rodata 163879 .globl data_b 163880 data_b: 163881 .word 0x2 163882 163883 If the first auipc is deleted, but we are still building the pcgp 163884 table (connect the high and low pcrel relocations), then there is 163885 an aliasing issue that we need some way to disambiguate which of 163886 the two symbols we are targeting. Therefore, Palmer thought of a 163887 way to use R_RISCV_DELETE to split this into two phases, so we 163888 could resolve the addresses before creating the ambiguities. 163889 163890 This patch just add the ld testcase for the above case, in case we 163891 have changed something but break this. 163892 163893 ld/ 163894 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax 163895 to pcgp-relax-01, and added pcgp-relax-02. 163896 * testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax. 163897 * testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise. 163898 * testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase. 163899 * testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise. 163900 1639012021-10-22 Lewis Revill <lewis.revill@embecosm.com> 163902 163903 RISC-V: Don't separate pcgp relaxation to another relax pass. 163904 Commit abd20cb637008da9d32018b4b03973e119388a0a and 163905 ebdcad3fddf6ec21f6d4dcc702379a12718cf0c4 introduced additional 163906 complexity into the paths run by the RISC-V relaxation pass in order to 163907 resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo 163908 pairs. The first commit split up relaxation of these relocs into a pass 163909 which occurred after other relaxations in order to prevent the situation 163910 where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting 163911 our ability to find the corresponding pcrel_hi relocation from the 163912 address attached to the pcrel_lo. 163913 163914 Since the relaxation was split into two passes the 'again' parameter 163915 could not be used to perform the entire relaxation process again and so 163916 the second commit added a way to restart ldelf_map_segments, thus 163917 starting the whole process again. 163918 163919 Unfortunately this process could not account for the fact that we were 163920 not finished with the relaxation process so in some cases - such as the 163921 case where code would not fit in a memory region before the 163922 R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code 163923 would fail. 163924 163925 This patch fixes all three of these concerns by reverting back to a 163926 system of having only one target relax pass but updating entries in the 163927 table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus 163928 we can keep track of the pairs accurately, and we can use the 'again' 163929 parameter to restart the entire target relax pass, behaving in the way 163930 that generic code expects. Unfortunately we must still have an 163931 additional pass to delay deleting AUIPC bytes to avoid ambiguity between 163932 pcrel_hi relocs stored in the table after deletion. This pass can only 163933 be run once so we may potentially miss out on relaxation opportunities 163934 but this is likely to be rare. 163935 163936 https://sourceware.org/bugzilla/show_bug.cgi?id=28410 163937 163938 bfd/ 163939 * elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax. 163940 (riscv_elf_link_hash_table_create): Updated. 163941 (riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs. 163942 Update the pcgp_relocs table whenever bytes are deleted. 163943 (riscv_update_pcgp_relocs): Add function to update the section 163944 offset of pcrel_hi and pcrel_lo, and also update the symbol value 163945 of pcrel_hi. 163946 (_bfd_riscv_relax_call): Need to update the pcgp_relocs table 163947 when deleting codes. 163948 (_bfd_riscv_relax_lui): Likewise. 163949 (_bfd_riscv_relax_tls_le): Likewise. 163950 (_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN, 163951 we can't relax anything else, so set the sec->sec_flg0 to true. 163952 Besides, we don't need to update the pcgp_relocs table at this 163953 stage, so just pass NULL pointer as the pcgp_relocs table for 163954 riscv_relax_delete_bytes. 163955 (_bfd_riscv_relax_section): Use only one pass for all target 163956 relaxations. 163957 (_bfd_riscv_relax_delete): Likewise, we don't need to update 163958 the pcgp_relocs table at this stage, and don't need to set 163959 the `again' since restart_relax mechanism is abandoned. 163960 (bfd_elfNN_riscv_restart_relax_sections): Removed. 163961 (_bfd_riscv_relax_section): Updated. 163962 * elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed. 163963 (bfd_elf64_riscv_restart_relax_sections): Likewise. 163964 ld/ 163965 * emultempl/riscvelf.em: Revert restart_relax changes and set 163966 relax_pass to 3. 163967 * testsuite/ld-riscv-elf/align-small-region.d: New testcase. 163968 * testsuite/ld-riscv-elf/align-small-region.ld: Likewise. 163969 * testsuite/ld-riscv-elf/align-small-region.s: Likewise. 163970 * testsuite/ld-riscv-elf/restart-relax.d: Removed sine the 163971 restart_relax mechanism is abandoned. 163972 * testsuite/ld-riscv-elf/restart-relax.s: Likewise. 163973 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. 163974 1639752021-10-22 Simon Marchi <simon.marchi@polymtl.ca> 163976 163977 gdb: fix remote-sim.c build 163978 Commit 183be222907a ("gdb, gdbserver: make target_waitstatus safe") 163979 broke the remote-sim.c build. In fact, it does some wrong changes, 163980 result of a bad sed invocation. 163981 163982 Fix it by adjusting the code to the new target_waitstatus API. 163983 163984 Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91 163985 1639862021-10-22 GDB Administrator <gdbadmin@sourceware.org> 163987 163988 Automatic date update in version.in 163989 1639902021-10-21 Simon Marchi <simon.marchi@efficios.com> 163991 163992 gdb, gdbserver: make target_waitstatus safe 163993 I stumbled on a bug caused by the fact that a code path read 163994 target_waitstatus::value::sig (expecting it to contain a gdb_signal 163995 value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This 163996 meant that the active union field was in fact 163997 target_waitstatus::value::related_pid, and contained a ptid. The read 163998 signal value was therefore garbage, and that caused GDB to crash soon 163999 after. Or, since that GDB was built with ubsan, this nice error 164000 message: 164001 164002 /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal' 164003 164004 Despite being a large-ish change, I think it would be nice to make 164005 target_waitstatus safe against that kind of bug. As already done 164006 elsewhere (e.g. dynamic_prop), validate that the type of value read from 164007 the union matches what is supposed to be the active field. 164008 164009 - Make the kind and value of target_waitstatus private. 164010 - Make the kind initialized to TARGET_WAITKIND_IGNORE on 164011 target_waitstatus construction. This is what most users appear to do 164012 explicitly. 164013 - Add setters, one for each kind. Each setter takes as a parameter the 164014 data associated to that kind, if any. This makes it impossible to 164015 forget to attach the associated data. 164016 - Add getters, one for each associated data type. Each getter 164017 validates that the data type fetched by the user matches the wait 164018 status kind. 164019 - Change "integer" to "exit_status", "related_pid" to "child_ptid", 164020 just because that's more precise terminology. 164021 - Fix all users. 164022 164023 That last point is semi-mechanical. There are a lot of obvious changes, 164024 but some less obvious ones. For example, it's not possible to set the 164025 kind at some point and the associated data later, as some users did. 164026 But in any case, the intent of the code should not change in this patch. 164027 164028 This was tested on x86-64 Linux (unix, native-gdbserver and 164029 native-extended-gdbserver boards). It was built-tested on x86-64 164030 FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native 164031 files was done as a best effort. If I forgot any place to update in 164032 these files, it should be easy to fix (unless the change happens to 164033 reveal an actual bug). 164034 164035 Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7 164036 1640372021-10-21 Simon Marchi <simon.marchi@polymtl.ca> 164038 164039 gdbserver: initialize the members of lwp_info in-class 164040 Add a constructor to initialize the waitstatus members. Initialize the 164041 others in the class directly. 164042 164043 Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442 164044 1640452021-10-21 Simon Marchi <simon.marchi@polymtl.ca> 164046 164047 gdbserver: make thread_info non-POD 164048 Add a constructor and a destructor. The constructor takes care of the 164049 initialization that happened in add_thread, while the destructor takes 164050 care of the freeing that happened in free_one_thread. This is needed to 164051 make target_waitstatus non-POD, as thread_info contains a member of that 164052 type. 164053 164054 Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7 164055 1640562021-10-21 Andrew Pinski <apinski@marvell.com> 164057 164058 Fix ARMv8.4 for hw watchpoint and breakpoint 164059 Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4), 164060 this adds ARMv8.4 debug arch as being compatible for hw watchpoint 164061 and breakpoints. 164062 164063 Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity) 164064 Since the two locations which check the debug arch are the same code currently, it is 164065 a good idea to factor it out to a new function and just use that function from 164066 aarch64_linux_get_debug_reg_capacity. This is also the first step to support 164067 ARMv8.4 debug arch. 164068 1640692021-10-21 Carl Love <cel@us.ibm.com> 164070 164071 Fixes for gdb.mi/mi-break.exp 164072 Update the expected pattern for two of the tests. 164073 164074 Matching pattern \" doesn't work. Use .* to match the \* pattern. 164075 1640762021-10-21 Tom de Vries <tdevries@suse.de> 164077 164078 [gdb/tui] Fix breakpoint display functionality 164079 In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop 164080 body was transformed into a lambda function body: 164081 ... 164082 - for (bp = breakpoint_chain; 164083 - bp != NULL; 164084 - bp = bp->next) 164085 + iterate_over_breakpoints ([&] (breakpoint *bp) -> bool 164086 ... 164087 and consequently: 164088 - a continue was replaced by a return, and 164089 - a final return was added. 164090 164091 Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we 164092 transformed back to a loop body: 164093 ... 164094 - iterate_over_breakpoints ([&] (breakpoint *bp) -> bool 164095 + for (breakpoint *bp : all_breakpoints ()) 164096 ... 164097 but without reverting the changes that introduced the two returns. 164098 164099 Consequently, breakpoints no longer show up in the tui source window. 164100 164101 Fix this by reverting the changes that introduced the two returns. 164102 164103 Build on x86_64-linux, tested with all .exp test-cases that contain 164104 tuiterm_env. 164105 164106 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483 164107 1641082021-10-21 Carl Love <cel@us.ibm.com> 164109 164110 Fix test step-and-next-inline.cc 164111 The test expect the runto_main to stop at the first line of the function. 164112 Depending on the optimization level, gdb may stop in the prolog or after 164113 the prolog at the first line. To ensure the test stops at the first line 164114 of main, have it explicitly stop at a break point on the first line of the 164115 function. 164116 164117 On PowerPC, the test passes when compiled with no optimization but fails 164118 with all levels of optimization due to gdb stopping in the prolog. 164119 1641202021-10-21 Tom Tromey <tromey@adacore.com> 164121 164122 Fix latent Ada bug when accessing field offsets 164123 The "add accessors for field (and call site) location" patch caused a 164124 gdb crash when running the internal AdaCore testsuite. This turned 164125 out to be a latent bug in ada-lang.c. 164126 164127 The immediate cause of the bug is that find_struct_field 164128 unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a 164129 dynamic type. 164130 164131 This patch fixes the problem by doing two things. First, it changes 164132 find_struct_field to use a dummy value for the field offset in the 164133 situation where the offset is not actually needed by the caller. This 164134 works because the offset isn't used in any other way -- only as a 164135 result. 164136 164137 Second, this patch assures that calls to find_struct_field use a 164138 resolved type when the offset is needed. For 164139 value_tag_from_contents_and_address, this is done by resolving the 164140 type explicitly. In ada_value_struct_elt, this is done by passing 164141 nullptr for the out parameters when they are not needed (the second 164142 call in this function already uses a resolved type). 164143 164144 Note that, while we believe the parent field probably can't occur at a 164145 variable offset, the patch still updates this code path, just in case. 164146 164147 I've updated an existing test case to reproduce the crash. 164148 I'm checking this in. 164149 1641502021-10-21 Alan Modra <amodra@gmail.com> 164151 164152 -Waddress warning in ldelf.c 164153 ldelf.c: In function 'ldelf_after_open': 164154 ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress] 164155 1049 | && elf_tdata (abfd)->elf_header != NULL 164156 | ^~ 164157 In file included from ldelf.c:37: 164158 ../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here 164159 1957 | Elf_Internal_Ehdr elf_header[1]; /* Actual data, but ref like ptr */ 164160 164161 * ldelf.c (ldelf_after_open): Remove useless elf_header test. 164162 1641632021-10-21 Alan Modra <amodra@gmail.com> 164164 164165 Avoid -Waddress warnings in readelf 164166 Mainline gcc: 164167 readelf.c: In function 'find_section': 164168 readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address] 164169 349 | ((X) != NULL \ 164170 | ^~ 164171 readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID' 164172 761 | if (SECTION_NAME_VALID (filedata->section_headers + i) 164173 | ^~~~~~~~~~~~~~~~~~ 164174 164175 This will likely be fixed in gcc, but inline functions are nicer than 164176 macros. 164177 164178 * readelf.c (SECTION_NAME, SECTION_NAME_VALID), 164179 (SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME), 164180 (GET_DYNAMIC_NAME): Delete. Replace with.. 164181 (section_name, section_name_valid, section_name_print), 164182 (valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these 164183 new inline functions. Update use throughout file. 164184 1641852021-10-21 GDB Administrator <gdbadmin@sourceware.org> 164186 164187 Automatic date update in version.in 164188 1641892021-10-20 Alan Modra <amodra@gmail.com> 164190 164191 PR28417, std::string no longer allows accepting nullptr_t 164192 PR 28417 164193 * incremental.cc (Sized_relobj_incr::do_section_name): Avoid 164194 std:string undefined behaviour. 164195 * options.h (Search_directory::Search_directory): Likewise. 164196 1641972021-10-20 Alan Modra <amodra@gmail.com> 164198 164199 Re: PR27625, powerpc64 gold __tls_get_addr calls 164200 My previous PR27625 patch had a problem or two. For one, the error 164201 "__tls_get_addr call lacks marker reloc" on processing some calls 164202 before hitting a call without markers typically isn't seen. Instead a 164203 gold assertion fails. Either way it would be a hard error, which 164204 triggers on a file contained in libphobos.a when running the gcc 164205 testsuite. A warning isn't even appropriate since the call involved 164206 is one built by hand without any of the arg setup relocations that 164207 might result in linker optimisation. 164208 164209 So this patch reverts most of commit 0af4fcc25dd5, instead entirely 164210 ignoring the problem of mis-optimising old-style __tls_get_addr calls 164211 without marker relocs. We can't handle them gracefully without 164212 another pass over relocations before decisions are made about GOT 164213 entries in Scan::global or Scan::local. That seems too costly, just 164214 to link object files from 2009. What's more, there doesn't seem to be 164215 any way to allow the libphobos explicit __tls_get_addr call, but not 164216 old TLS sequences without marker relocs. Examining instructions 164217 before the __tls_get_addr call is out of the question: program flow 164218 might reach the call via a branch. Putting an R_PPC64_TLSGD marker 164219 with zero sym on the call might be a solution, but current linkers 164220 will then merrily optimise away the call! 164221 164222 PR gold/27625 164223 * powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_, 164224 and tls_opt_error_ variables and accessors. Remove all uses. 164225 1642262021-10-20 Tom Tromey <tom@tromey.com> 164227 164228 Use std::string in print_one_catch_syscall 164229 This changes print_one_catch_syscall to use std::string, removing a 164230 bit of manual memory management. 164231 164232 Use unique_xmalloc_ptr in breakpoint 164233 This changes struct breakpoint to use unique_xmalloc_ptr in a couple 164234 of spots, removing a bit of manual memory management. 164235 164236 Use unique_xmalloc_ptr in bp_location 164237 This changes struct bp_location to use a unique_xmalloc_ptr, removing 164238 a bit of manual memory management. 164239 164240 Use unique_xmalloc_ptr in watchpoint 164241 This changes struct watchpoint to use unique_xmalloc_ptr in a couple 164242 of places, removing a bit of manual memory management. 164243 164244 Use unique_xmalloc_ptr in exec_catchpoint 164245 This changes struct exec_catchpoint to use a unique_xmalloc_ptr, 164246 removing a bit of manual memory management. 164247 164248 Use unique_xmalloc_ptr in solib_catchpoint 164249 This changes struct solib_catchpoint to use a unique_xmalloc_ptr, 164250 removing a bit of manual memory management. 164251 1642522021-10-20 Christian Biesinger <cbiesinger@google.com> 164253 164254 Make c-exp.y work with Bison 3.8+ 164255 When using Bison 3.8, we get this error: 164256 164257 ../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function] 164258 164259 That's because bison 3.8 removed YYPRINT support: 164260 https://savannah.gnu.org/forum/forum.php?forum_id=10047 164261 164262 Accordingly, this patch only defines that function for Bison < 3.8. 164263 164264 Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad 164265 1642662021-10-20 GDB Administrator <gdbadmin@sourceware.org> 164267 164268 Automatic date update in version.in 164269 1642702021-10-19 Tom de Vries <tdevries@suse.de> 164271 164272 [gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest 164273 The test-case gdb.gdb/python-interrupts.exp: 164274 - runs to captured_command_loop 164275 - sets a breakpoint at set_active_ext_lang 164276 - calls a python command 164277 - verifies the command triggers the breakpoint 164278 - sends a signal and verifies the result 164279 164280 The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed 164281 that captured_command_loop and set_active_ext_lang are available for setting 164282 breakpoints. 164283 164284 Reimplement the test-case as unittest, using: 164285 - execute_command_to_string to capture the output 164286 - try/catch to catch the "Error while executing Python code" exception 164287 - a new hook selftests::hook_set_active_ext_lang to raise the signal 164288 164289 Tested on x86_64-linux. 164290 1642912021-10-19 Tom Tromey <tromey@adacore.com> 164292 164293 Check index in type::field 164294 This changes gdb to check the index that is passed to type::field. 164295 This caught one bug in the Ada code when running the test suite 164296 (actually I found the bug first, then realized that the check would 164297 have helped), so this patch fixes that as well. 164298 164299 Regression tested on x86-64 Fedora 34. 164300 1643012021-10-19 Tom Tromey <tromey@adacore.com> 164302 164303 Fix Rust lex selftest when using libiconv 164304 The Rust lex selftest fails on our Windows build. I tracked this down 164305 to a use of UTF-32 as a parameter to convert_between_encodings. Here, 164306 iconv_open succeeds, but the actual conversion of a tab character 164307 fails with EILSEQ. I suspect that "UTF-32" is being interpreted as 164308 big-endian, as changing the call to use "UTF-32LE" makes it work. 164309 This patch implements this fix. 164310 1643112021-10-19 Tom Tromey <tromey@adacore.com> 164312 164313 Fix format_pieces selftest on Windows 164314 The format_pieces selftest currently fails on Windows hosts. 164315 164316 The selftest doesn't handle the "%ll" -> "%I64" rewrite that the 164317 formatter may perform, but also gdbsupport was missing a configure 164318 check for PRINTF_HAS_LONG_LONG. This patch fixes both issues. 164319 1643202021-10-19 Tom Tromey <tromey@adacore.com> 164321 164322 Fix bug in dynamic type resolution 164323 A customer-reported problem led us to a bug in dynamic type 164324 resolution. resolve_dynamic_struct will recursively call 164325 resolve_dynamic_type_internal, passing it the sub-object for the 164326 particular field being resolved. While it offsets the address here, 164327 it does not also offset the "valaddr" -- the array of bytes describing 164328 the memory. 164329 164330 This patch fixes the bug, by offsetting both. A test case is included 164331 that can be used to reproduce the bug. 164332 1643332021-10-19 Tom Tromey <tromey@adacore.com> 164334 164335 Always use std::function for self-tests 164336 Now that there is a register_test variant that accepts std::function, 164337 it seems to me that the 'selftest' struct and accompanying code is 164338 obsolete -- simply always using std::function is simpler. This patch 164339 implements this idea. 164340 1643412021-10-19 Daniel Black <daniel@mariadb.org> 164342 164343 Fix PR gdb/17917 Lookup build-id in remote binaries 164344 GDB doesn't support loading debug files using build-id from remote 164345 target filesystems. 164346 164347 This is the case when gdbserver attached to a process and a gdb target 164348 remote occurs over tcp. 164349 164350 With this change we make build-id lookups possible: 164351 164352 (gdb) show debug-file-directory 164353 The directory where separate debug symbols are searched for is "/usr/local/lib/debug". 164354 (gdb) set debug-file-directory /usr/lib/debug 164355 (gdb) show sysroot 164356 The current system root is "target:". 164357 (gdb) target extended-remote :46615 164358 Remote debugging using :46615 164359 warning: Can not parse XML target description; XML support was disabled at compile time 164360 Reading /usr/sbin/mariadbd from remote target... 164361 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. 164362 Reading /usr/sbin/mariadbd from remote target... 164363 Reading symbols from target:/usr/sbin/mariadbd... 164364 Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164365 Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164366 Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug... 164367 Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target... 164368 ... 164369 164370 Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34): 164371 164372 (gdb) target extended-remote :46615 164373 Remote debugging using :46615 164374 Reading /usr/sbin/mariadbd from remote target... 164375 warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. 164376 Reading /usr/sbin/mariadbd from remote target... 164377 Reading symbols from target:/usr/sbin/mariadbd... 164378 Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164379 Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164380 Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164381 Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164382 Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target... 164383 Missing separate debuginfo for target:/usr/sbin/mariadbd 164384 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug 164385 (No debugging symbols found in target:/usr/sbin/mariadbd) 164386 164387 Observe it didn't look for 164388 /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug 164389 on the remote target (where it is) and expected them to be installed 164390 locally. 164391 164392 As a minor optimization, this also changes the build-id lookup such that 164393 if sysroot is empty, no second lookup of the same location is performed. 164394 164395 Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55 164396 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917 164397 1643982021-10-19 Nick Clifton <nickc@redhat.com> 164399 164400 Fix a potential illegal memory access when testing for a special LTO symbol name. 164401 bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL 164402 name before checking to see if the symbol is __gnu_lto_slim. 164403 * archive.c (_bfd_compute_and_write_armap): Likewise. 164404 binutils 164405 * nm.c (filter_symbols): Test for a NULL name before checking to 164406 see if the symbol is __gnu_lto_slim. 164407 * objcopy.c (filter_symbols): Likewise. 164408 1644092021-10-19 GDB Administrator <gdbadmin@sourceware.org> 164410 164411 Automatic date update in version.in 164412 1644132021-10-18 Weimin Pan <weimin.pan@oracle.com> 164414 164415 CTF: incorrect underlying type setting for enumeration types 164416 A bug was filed against the incorrect underlying type setting for 164417 an enumeration type, which was caused by a copy and paste error. 164418 This patch fixes the problem by setting it by calling objfile_int_type, 164419 which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits. 164420 Also add error checking on ctf_func_type_info call. 164421 1644222021-10-18 GDB Administrator <gdbadmin@sourceware.org> 164423 164424 Automatic date update in version.in 164425 1644262021-10-17 Alan Modra <amodra@gmail.com> 164427 164428 PR28459, readelf issues bogus warning 164429 I'd missed the fact that the .debug_rnglists dump doesn't exactly 164430 display the contents of the section. Instead readelf rummages through 164431 .debug_info looking for DW_AT_ranges entries, then displays the 164432 entries in .debug_rnglists pointed at, sorted. A simpler dump of the 164433 actual section contents might be more useful and robust, but it was 164434 likely done that way to detect overlap and holes. 164435 164436 Anyway, the headers in .debug_rnglists besides the first are ignored, 164437 and limiting to the unit length of the first header fails if there is 164438 more than one unit. 164439 164440 PR 28459 164441 * dwarf.c (display_debug_ranges): Don't constrain data to length 164442 in header. 164443 1644442021-10-17 GDB Administrator <gdbadmin@sourceware.org> 164445 164446 Automatic date update in version.in 164447 1644482021-10-16 H.J. Lu <hjl.tools@gmail.com> 164449 164450 ld: Adjust pr28158.rd for glibc 2.34 164451 Adjust pr28158.rd for glibc 2.34: 164452 164453 $ readelf -W --dyn-syms tmpdir/pr28158 164454 164455 Symbol table '.dynsym' contains 4 entries: 164456 Num: Value Size Type Bind Vis Ndx Name 164457 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 164458 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.34 (2) 164459 2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ 164460 3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (3) 164461 $ 164462 164463 vs older glibc: 164464 164465 $ readelf -W --dyn-syms tmpdir/pr28158 164466 164467 Symbol table '.dynsym' contains 4 entries: 164468 Num: Value Size Type Bind Vis Ndx Name 164469 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 164470 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (3) 164471 2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ 164472 3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (2) 164473 164474 $ 164475 164476 * testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34. 164477 1644782021-10-16 GDB Administrator <gdbadmin@sourceware.org> 164479 164480 Automatic date update in version.in 164481 1644822021-10-15 GDB Administrator <gdbadmin@sourceware.org> 164483 164484 Automatic date update in version.in 164485 1644862021-10-14 Carl Love <cel@us.ibm.com> 164487 164488 Powerpc: Add support for openat and fstatat syscalls 164489 [gdb] update ppc-linux-tdep.c 164490 164491 Add argument to ppc_canonicalize_syscall for the wordsize. 164492 Add syscall entries for the openat and fstatat system calls. 164493 1644942021-10-14 Tom de Vries <tdevries@suse.de> 164495 164496 [gdb/testsuite] Add .debug_loc support in dwarf assembler 164497 Add .debug_loc support in the dwarf assembler, and use it in new test-case 164498 gdb.dwarf2/loc-sec-offset.exp (which is based on 164499 gdb.dwarf2/loclists-sec-offset.exp). 164500 164501 Tested on x86_64-linux. 164502 1645032021-10-14 Alan Modra <amodra@gmail.com> 164504 164505 [GOLD] Re: PowerPC64: Don't pretend to support multi-toc 164506 We can't get at section->address() until everything is laid out, so 164507 trying to generalise the offset calculation rather than using a value 164508 of 0x8000 (the old object->toc_base_offset()) was bound to fail. 164509 got->g_o_t() is a little better than a hard-coded 0x8000. 164510 164511 * powerpc.cc (Target_powerpc::Scan::local, global): Don't use 164512 toc_pointer() here. 164513 1645142021-10-14 Alan Modra <amodra@gmail.com> 164515 164516 [GOLD] Two GOT sections for PowerPC64 164517 Split .got into two piece, one with the header and entries for small 164518 model got entries, the other with entries for medium/large model got 164519 entries. The idea is to better support mixed pcrel/non-pcrel code 164520 where non-pcrel small-model .toc entries need to be within 32k of the 164521 toc pointer. 164522 164523 * target.h (Target::tls_offset_for_local): Add got param. 164524 (Target::tls_offset_for_global): Likewise. 164525 (Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise. 164526 * output.h (Output_data_got::Got_entry::write): Add got param. 164527 * output.cc (Output_data_got::Got_entry::write): Likewise, pass to 164528 tls_offset_for_local/global calls. 164529 (Output_data_got::do_write): Adjust to suit. 164530 * s390.cc (Target_s390::do_tls_offset_for_local): Likewise. 164531 (Target_s390::do_tls_offset_for_global): Likewise. 164532 * powerpc.cc (enum Got_type): Extend with small types, move from 164533 class Target_powerpc. 164534 (Target_powerpc::biggot_): New. 164535 (Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global, 164536 got_size, got_section, got_base_offset): Handle biggot_. 164537 (Target_powerpc::do_define_standard_symbols): Adjust. 164538 (Target_powerpc::make_plt_section, do_finalize_sections): Likewise. 164539 (Output_data_got_powerpc::Output_data_got_powerpc): Only make 164540 64-bit header for small got section. 164541 (Output_data_got_powerpc::g_o_t): Only return a result for small 164542 got section. 164543 (Output_data_got_powerpc::write): Only write small got section 164544 header. 164545 (Target_powerpc::Scan::local, global): Select small/big Got_type 164546 and section to suit reloc. 164547 (Target_powerpc::Relocate::relocate): Similarly. 164548 (Sort_toc_sections): Rewrite. 164549 1645502021-10-14 Alan Modra <amodra@gmail.com> 164551 164552 [GOLD] PowerPC64: Don't pretend to support multi-toc 164553 Code in powerpc.cc is pretending to support a per-object toc pointer 164554 value, but powerpc gold has no real support for multi-toc. This patch 164555 removes the pretense, tidying quite a lot in preparation for a 164556 followup patch. If multi-toc is ever to be supported, don't revert 164557 this patch but start by adding object parameter to toc_pointer() and 164558 an object to Branch_stub_key. 164559 164560 * powerpc.cc (Powerpc_relobj::toc_base_offset): Delete. 164561 (Target_powerpc::toc_pointer): New function. Use throughout. 164562 (Target_powerpc::got_base_offset): New function. Use throughout.. 164563 (Output_data_got_powerpc::got_base_offset): ..in place of 164564 this. Delete. 164565 (Output_data_got_powerpc::Output_data_got_powerpc): Init 164566 header_index_ to -1u for 64-bit, and make header here. 164567 (Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't 164568 make 64-bit header here. 164569 (Output_data_got_powerpc::g_o_t): Return toc pointer offset in 164570 section for 64-bit. Use throughout. 164571 (Stub_table): Remove toc_base_off_ from Branch_stub_key, and 164572 object param on add_long_branch_entry and find_long_branch_entry. 164573 Adjust all uses. 164574 1645752021-10-14 Alan Modra <amodra@gmail.com> 164576 164577 Re: s12z/disassembler: call memory_error_func when appropriate 164578 Adjust for commit ba7c18a48457. 164579 164580 * testsuite/gas/s12z/truncated.d: Update expected output. 164581 1645822021-10-14 GDB Administrator <gdbadmin@sourceware.org> 164583 164584 Automatic date update in version.in 164585 1645862021-10-13 Tom de Vries <tdevries@suse.de> 164587 164588 [gdb/exp] Improve <error reading variable> message 164589 When printing a variable x in a subroutine foo: 164590 ... 164591 subroutine foo (x) 164592 integer(4) :: x (*) 164593 x(3) = 1 164594 end subroutine foo 164595 ... 164596 where x is an array with unknown bounds, we get: 164597 ... 164598 $ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \ 164599 -ex "break foo" \ 164600 -ex run \ 164601 -ex "print x" 164602 Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18. 164603 164604 Breakpoint 1, foo (x=...) at array-no-bounds.f90:18 164605 18 x(3) = 1 164606 $1 = <error reading variable> 164607 ... 164608 164609 Improve the error message by printing the details of the error, such that we 164610 have instead: 164611 ... 164612 $1 = <error reading variable: failed to get range bounds> 164613 ... 164614 164615 This is a change in gdb/valprint.c, and grepping through the sources reveals 164616 that this is a common pattern. 164617 164618 Tested on x86_64-linux. 164619 1646202021-10-13 Carl Love <cel@us.ibm.com> 164621 164622 PPC fix for stfiwx instruction (and additional stores with primary opcode of 31) 164623 [gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31. 164624 164625 The GDB record function was recording the variable addr that was passed in 164626 rather than the calculated effective address (ea) by the 164627 ppc_process_record_op31 function. 164628 1646292021-10-13 Andrew Burgess <andrew.burgess@embecosm.com> 164630 164631 gdb: improve error reporting from the disassembler 164632 If the libopcodes disassembler returns a negative value then this 164633 indicates that the disassembly failed for some reason. In disas.c, in 164634 the function gdb_disassembler::print_insn we can see how this is 164635 handled; when we get a negative value back, we call the memory_error 164636 function, which throws an exception. 164637 164638 The problem here is that the address used in the memory_error call is 164639 gdb_disassembler::m_err_memaddr, which is set in 164640 gdb_disassembler::dis_asm_memory_error, which is called from within 164641 the libopcodes disassembler through the 164642 disassembler_info::memory_error_func callback. 164643 164644 However, for this to work correctly, every time the libopcodes 164645 disassembler returns a negative value, the libopcodes disassembler 164646 must have first called the memory_error_func callback. 164647 164648 My first plan was to make m_err_memaddr a gdb::optional, and assert 164649 that it always had a value prior to calling memory_error, however, a 164650 quick look in opcodes/*-dis.c shows that there _are_ cases where a 164651 negative value is returned without first calling the memory_error_func 164652 callback, for example in arc-dis.c and cris-dis.c. 164653 164654 Now, I think that a good argument can be made that these disassemblers 164655 must therefore be broken, except for the case where we can't read 164656 memory, we should always be able to disassemble the memory contents to 164657 _something_, even if it's just '.word 0x....'. However, I certainly 164658 don't plan to go and fix all of the disassemblers. 164659 164660 What I do propose to do then, is make m_err_memaddr a gdb::optional, 164661 but now, instead of always calling memory_error, I add a new path 164662 which just calls error complaining about an unknown error. This new 164663 path is only used if m_err_memaddr doesn't have a value (indicating 164664 that the memory_error_func callback was not called). 164665 164666 To test this I just augmented one of the disassemblers to always 164667 return -1, before this patch I see this: 164668 164669 Dump of assembler code for function main: 164670 0x000101aa <+0>: Cannot access memory at address 0x0 164671 164672 And after this commit I now see: 164673 164674 Dump of assembler code for function main: 164675 0x000101aa <+0>: unknown disassembler error (error = -1) 164676 164677 This doesn't really help much, but that's because there's no way to 164678 report non memory errors out of the disasembler, because, it was not 164679 expected that the disassembler would ever report non memory errors. 164680 1646812021-10-13 Tom de Vries <tdevries@suse.de> 164682 164683 [gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver 164684 When running test-case gdb.fortran/call-no-debug.exp with target board 164685 native-gdbserver, I run into: 164686 ... 164687 (gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3) 164688 call (integer) string_func_ (&'abcdefg', 3)^M 164689 $2 = 0^M 164690 (gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3) 164691 ... 164692 164693 The problem is that gdb_test is used to match inferior output. 164694 164695 Fix this by using gdb_test_stdio. 164696 164697 Tested on x86_64-linux. 164698 1646992021-10-13 Tom de Vries <tdevries@suse.de> 164700 164701 [gdb/testsuite] Require use_gdb_stub == 0 where appropriate 164702 When running with target board native-gdbserver, we run into a number of FAILs 164703 due to use of the start command (and similar), which is not supported when 164704 use_gdb_stub == 1. 164705 164706 Fix this by: 164707 - requiring use_gdb_stub == 0 for the entire test-case, or 164708 - guarding some tests in the test-case with use_gdb_stub == 0. 164709 164710 Tested on x86_64-linux. 164711 1647122021-10-13 Tom de Vries <tdevries@suse.de> 164713 164714 [gdb/testsuite] Fix test name in gdb.python/python.exp 164715 When running test-case gdb.python/python.exp, we have: 164716 ... 164717 PASS: gdb.python/python.exp: starti via gdb.execute, not from tty 164718 PASS: gdb.python/python.exp: starti via interactive input 164719 ... 164720 164721 The two tests are instances of the same test, with different values for 164722 starti command argument from_tty, so it's strange that the test names are so 164723 different. 164724 164725 This is due to using a gdb_test nested in a gdb_test_multiple, with the inner 164726 one using a different test name than the outer one. [ That could still make 164727 sense if both produced passes, but that's not the case here. ] 164728 164729 Fix this by using $gdb_test_name, such that we have: 164730 ... 164731 PASS: gdb.python/python.exp: starti via gdb.execute, not from tty 164732 PASS: gdb.python/python.exp: starti via gdb.execute, from tty 164733 ... 164734 164735 Also make this more readable by using variables. 164736 164737 Tested on x86_64-linux. 164738 1647392021-10-13 Tom de Vries <tdevries@suse.de> 164740 164741 [gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver 164742 When running test-case gdb.base/batch-exit-status.exp with target board 164743 native-gdbserver, I run into (added missing double quotes for clarity): 164744 ... 164745 builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ 164746 -data-directory $build/gdb/testsuite/../data-directory \ 164747 -iex "set height 0" -iex "set width 0" \ 164748 -ex "set auto-connect-native-target off" \ 164749 -iex "set sysroot" -batch ""^M 164750 : No such file or directory.^M 164751 PASS: gdb.base/batch-exit-status.exp: 1x: \ 164752 No such file or directory: [lindex $result 2] == 0 164753 FAIL: gdb.base/batch-exit-status.exp: 1x: \ 164754 No such file or directory: [lindex $result 3] == $expect_status 164755 ... 164756 164757 As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in 164758 local-board.exp", the problem is the use of -ex for 164759 "set auto-connect-native-target off", which makes that the last command to 164760 be executed, and consequently determines the return status. 164761 164762 Fix this by using -iex instead. 164763 164764 Tested on x86_64-linux. 164765 1647662021-10-13 Tom de Vries <tdevries@suse.de> 164767 164768 [gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp 164769 When running test-case gdb.arch/i386-mpx.exp with target board 164770 native-gdbserver, I run into: 164771 ... 164772 (gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0 164773 Remote debugging from host ::1, port 42328^M 164774 quit^M 164775 A debugging session is active.^M 164776 ^M 164777 Inferior 1 [process 19679] will be killed.^M 164778 ^M 164779 Quit anyway? (y or n) monitor exit^M 164780 Please answer y or n.^M 164781 A debugging session is active.^M 164782 ^M 164783 Inferior 1 [process 19679] will be killed.^M 164784 ^M 164785 Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit 164786 ... 164787 164788 The problem is that the test-case sends a quit at the end (without verifying 164789 the result of this in any way): 164790 ... 164791 send_gdb "quit\n" 164792 ... 164793 164794 Fix this by removing the quit. 164795 164796 Tested on x86_64-linux. 164797 1647982021-10-13 GDB Administrator <gdbadmin@sourceware.org> 164799 164800 Automatic date update in version.in 164801 1648022021-10-12 GDB Administrator <gdbadmin@sourceware.org> 164803 164804 Automatic date update in version.in 164805 1648062021-10-11 Srinath Parvathaneni <srinath.parvathaneni@arm.com> 164807 164808 [ARM] Add support for M-profile MVE extension 164809 This patch adds support for the M-profile MVE extension, which includes the 164810 following: 164811 164812 - New M-profile XML feature m-profile-mve 164813 - MVE vector predication status and control register (VPR) 164814 - p0 pseudo register (contained in the VPR) 164815 - q0 ~ q7 pseudo vector registers 164816 - New feature bits 164817 - Documentation update 164818 164819 Pseudo register p0 is the least significant bits of vpr and can be accessed 164820 as $p0 or displayed through $vpr. For more information about the register 164821 layout, please refer to [1]. 164822 164823 The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers 164824 per q register. 164825 164826 The register dump looks like this: 164827 164828 (gdb) info reg all 164829 r0 0x0 0 164830 r1 0x0 0 164831 r2 0x0 0 164832 r3 0x0 0 164833 r4 0x0 0 164834 r5 0x0 0 164835 r6 0x0 0 164836 r7 0x0 0 164837 r8 0x0 0 164838 r9 0x0 0 164839 r10 0x0 0 164840 r11 0x0 0 164841 r12 0x0 0 164842 sp 0x0 0x0 <__Vectors> 164843 lr 0xffffffff -1 164844 pc 0xd0c 0xd0c <Reset_Handler> 164845 xpsr 0x1000000 16777216 164846 d0 0 (raw 0x0000000000000000) 164847 d1 0 (raw 0x0000000000000000) 164848 d2 0 (raw 0x0000000000000000) 164849 d3 0 (raw 0x0000000000000000) 164850 d4 0 (raw 0x0000000000000000) 164851 d5 0 (raw 0x0000000000000000) 164852 d6 0 (raw 0x0000000000000000) 164853 d7 0 (raw 0x0000000000000000) 164854 d8 0 (raw 0x0000000000000000) 164855 d9 0 (raw 0x0000000000000000) 164856 d10 0 (raw 0x0000000000000000) 164857 d11 0 (raw 0x0000000000000000) 164858 d12 0 (raw 0x0000000000000000) 164859 d13 0 (raw 0x0000000000000000) 164860 d14 0 (raw 0x0000000000000000) 164861 d15 0 (raw 0x0000000000000000) 164862 fpscr 0x0 0 164863 vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ] 164864 s0 0 (raw 0x00000000) 164865 s1 0 (raw 0x00000000) 164866 s2 0 (raw 0x00000000) 164867 s3 0 (raw 0x00000000) 164868 s4 0 (raw 0x00000000) 164869 s5 0 (raw 0x00000000) 164870 s6 0 (raw 0x00000000) 164871 s7 0 (raw 0x00000000) 164872 s8 0 (raw 0x00000000) 164873 s9 0 (raw 0x00000000) 164874 s10 0 (raw 0x00000000) 164875 s11 0 (raw 0x00000000) 164876 s12 0 (raw 0x00000000) 164877 s13 0 (raw 0x00000000) 164878 s14 0 (raw 0x00000000) 164879 s15 0 (raw 0x00000000) 164880 s16 0 (raw 0x00000000) 164881 s17 0 (raw 0x00000000) 164882 s18 0 (raw 0x00000000) 164883 s19 0 (raw 0x00000000) 164884 s20 0 (raw 0x00000000) 164885 s21 0 (raw 0x00000000) 164886 s22 0 (raw 0x00000000) 164887 s23 0 (raw 0x00000000) 164888 s24 0 (raw 0x00000000) 164889 s25 0 (raw 0x00000000) 164890 s26 0 (raw 0x00000000) 164891 s27 0 (raw 0x00000000) 164892 s28 0 (raw 0x00000000) 164893 s29 0 (raw 0x00000000) 164894 s30 0 (raw 0x00000000) 164895 s31 0 (raw 0x00000000) 164896 q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164897 q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164898 q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164899 q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164900 q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164901 q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164902 q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164903 q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} 164904 p0 0x0 0 164905 164906 Built and regtested with a simulator. 164907 164908 [1] https://developer.arm.com/documentation/ddi0553/bn 164909 164910 Co-Authored-By: Luis Machado <luis.machado@linaro.org> 164911 1649122021-10-11 Luis Machado <luis.machado@linaro.org> 164913 164914 [ARM] Refactor pseudo register numbering 164915 The pseudo register handling for ARM uses some hardcoded constants to 164916 determine types and names. In preparation to the upcoming MVE support 164917 patch (that will add another pseudo register), this patch refactors and 164918 reorganizes things in order to simplify handling of future pseudo registers. 164919 164920 We keep track of the first pseudo register number in a group and the number of 164921 pseudo registers in that group. 164922 164923 Right now we only have the S and Q pseudo registers. 164924 1649252021-10-11 Luis Machado <luis.machado@linaro.org> 164926 164927 [ARM] Small refactoring of arm gdbarch initialization 164928 This is in preparation to MVE support, where we will define another 164929 pseudo register. We need to define the pseudo register numbers *after* 164930 accounting for all the registers in the XML description, so move 164931 the call to tdesc_use_registers up. 164932 164933 If we don't do it, GDB's register count won't consider registers contained 164934 in the XML but ignored by GDB, throwing the register numbering off. 164935 1649362021-10-11 Luis Machado <luis.machado@linaro.org> 164937 164938 [ARM] Refactor some constants 164939 In preparation for the MVE extension patch, this one refactors some of 164940 the register-related constants we have for ARM. 164941 164942 Basically I'm separating counting constants from numbering constants. 164943 164944 For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS 164945 is a counting constant. 164946 1649472021-10-11 Tom de Vries <tdevries@suse.de> 164948 164949 [gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp 164950 When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed 164951 (with glibc 2.34) I run into: 164952 ... 164953 (gdb) ^M 164954 PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array 164955 Expecting: ^(-var-create array \* array[^M 164956 ]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M 164957 ]+[(]gdb[)] ^M 164958 [ ]*) 164959 -var-create array * array^M 164960 &"Attempt to use a type name as an expression.\n"^M 164961 ^error,msg="-var-create: unable to create variable object"^M 164962 (gdb) ^M 164963 FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output) 164964 ... 164965 164966 The problem is that the name array is used both: 164967 - as the name for a local variable 164968 - as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included 164969 by nss/nss_files/files-hosts.c. 164970 164971 Fix this by ignoring the shared lib symbols. 164972 164973 Likewise in a couple of other fortran tests. 164974 164975 Tested on x86_64-linux. 164976 1649772021-10-11 Andrew Burgess <andrew.burgess@embecosm.com> 164978 164979 z80/disassembler: call memory_error_func when appropriate 164980 If a call to the read_memory_func fails then we should call the 164981 memory_error_func to notify the user of the disassembler of the 164982 address that was a problem. 164983 164984 Without this GDB will report all memory errors as being at address 164985 0x0. 164986 164987 opcodes/ChangeLog: 164988 164989 * z80-dis.c (fetch_data): Call memory_error_func if the 164990 read_memory_func call fails. 164991 1649922021-10-11 Andrew Burgess <andrew.burgess@embecosm.com> 164993 164994 s12z/disassembler: call memory_error_func when appropriate 164995 If a call to the read_memory_func fails then we should call the 164996 memory_error_func to notify the user of the disassembler of the 164997 address that was a problem. 164998 164999 Without this GDB will report all memory errors as being at address 165000 0x0. 165001 165002 opcodes/ChangeLog: 165003 165004 * s12z-disc.c (abstract_read_memory): Call memory_error_func if 165005 the read_memory_func call fails. 165006 1650072021-10-11 Tom de Vries <tdevries@suse.de> 165008 165009 [gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp 165010 A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range 165011 in gdb.dwarf2/dw2-ref-missing-frame.exp". 165012 165013 Before the commit the main file was compiled with debug info, and the two 165014 others not: 165015 ... 165016 if {[prepare_for_testing_full "failed to prepare" \ 165017 [list $testfile {} $srcfile {} $srcfuncfile {} \ 165018 $srcmainfile debug]]} { 165019 ... 165020 165021 After the commit, all were compiled with debug info, and consequently, there 165022 are two versions of debug info for $srcfuncfile. This shows up as a FAIL when 165023 running the test-case with target boards readnow and cc-with-debug-names. 165024 165025 Fix this by using prepare_for_testing_full, as before. 165026 165027 Tested on x86_64-linux. 165028 165029 Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in 165030 gdb.dwarf2/dw2-ref-missing-frame.exp") 165031 1650322021-10-11 Tom de Vries <tdevries@suse.de> 165033 165034 [gdb/testsuite] Use require for ensure_gdb_index 165035 Replace: 165036 ... 165037 if { [ensure_gdb_index $binfile] == -1 } { 165038 return -1 165039 } 165040 ... 165041 with: 165042 ... 165043 require {ensure_gdb_index $binfile} != -1 165044 ... 165045 and consequently, add a missing UNTESTED message. 165046 165047 Tested on x86_64-linux, both with native and target board readnow. 165048 1650492021-10-11 Tom de Vries <tdevries@suse.de> 165050 165051 [gdb/testsuite] Handle readnow in ensure_gdb_index 165052 When running test-case gdb.base/with-mf.exp with target board readnow, I run 165053 into: 165054 ... 165055 FAIL: gdb.base/with-mf.exp: check if index present 165056 ... 165057 This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in 165058 gdb.rust/dwindex.exp". 165059 165060 Before that commit, the proc ensure_gdb_index would treat the line: 165061 ... 165062 .gdb_index: faked for "readnow"^M 165063 ... 165064 as proof that an index is already present (which is incorrect). 165065 165066 Now, instead it generates aforementioned FAIL and continues to generate an 165067 index. 165068 165069 Fix this by explicitly handling the readnow case in proc ensure_gdb_index, 165070 such that we bail out instead. 165071 165072 Tested on x86_64-linux. 165073 1650742021-10-11 Tom de Vries <tdevries@suse.de> 165075 165076 [gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.exp 165077 The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to 165078 add an index as a failure to add an index for a symlink: 165079 ... 165080 if { [ensure_gdb_index $symlink] == -1 } { 165081 fail "Unable to call gdb-add-index with a symlink to a symfile" 165082 return -1 165083 } 165084 ... 165085 165086 However, it's possible that the gdb-add-index also fails with a regular 165087 file. Add a check for that situation. 165088 165089 Tested on x86_64-linux. 165090 1650912021-10-11 Tom de Vries <tdevries@suse.de> 165092 165093 [gdb/testsuite] Add proc require in lib/gdb.exp 165094 Add a new proc require in lib/gdb.exp, and use it to shorten: 165095 ... 165096 if { [gdb_skip_xml_test] } { 165097 # Valgrind gdbserver requires gdb with xml support. 165098 untested "missing xml support" 165099 return 0 165100 } 165101 ... 165102 into: 165103 ... 165104 require gdb_skip_xml_test 0 165105 ... 165106 165107 Tested on x86_64-linux, both with and without a trigger patch that forces 165108 gdb_skip_xml_test to return 1. 165109 1651102021-10-11 Michael Forney <mforney@mforney.org> 165111 165112 bfd: Remove use of void pointer arithmetic 165113 This is not valid in ISO C. Instead, use a pointer to bfd_byte. 165114 165115 * peicode.h (pe_bfd_object_p): Remove use of void pointer 165116 arithmetic. 165117 1651182021-10-11 GDB Administrator <gdbadmin@sourceware.org> 165119 165120 Automatic date update in version.in 165121 1651222021-10-10 GDB Administrator <gdbadmin@sourceware.org> 165123 165124 Automatic date update in version.in 165125 1651262021-10-09 Tom de Vries <tdevries@suse.de> 165127 165128 [gdb] Make execute_command_to_string return string on throw 165129 The pattern for using execute_command_to_string is: 165130 ... 165131 std::string output; 165132 output = execute_fn_to_string (fn, term_out); 165133 ... 165134 165135 This results in a problem when using it in a try/catch: 165136 ... 165137 try 165138 { 165139 output = execute_fn_to_string (fn, term_out) 165140 } 165141 catch (const gdb_exception &e) 165142 { 165143 /* Use output. */ 165144 } 165145 ... 165146 165147 If an expection was thrown during execute_fn_to_string, then the output 165148 remains unassigned, while it could be worthwhile to known what output was 165149 generated by gdb before the expection was thrown. 165150 165151 Fix this by returning the string using a parameter instead: 165152 ... 165153 execute_fn_to_string (output, fn, term_out) 165154 ... 165155 165156 Also add a variant without string parameter, to support places where the 165157 function is used while ignoring the result: 165158 ... 165159 execute_fn_to_string (fn, term_out) 165160 ... 165161 165162 Tested on x86_64-linux. 165163 1651642021-10-09 Tom de Vries <tdevries@suse.de> 165165 165166 [gdb/testsuite] Add check-readmore 165167 Consider the gdb output: 165168 ... 165169 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M 165170 (gdb) ^M 165171 Thread 2 "run-attach-whil" stopped.^M 165172 ... 165173 165174 When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $', 165175 it may pass or fail. 165176 165177 This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's 165178 currently no way to reliably find this type of FAILs. 165179 165180 We have check-read1, but that one actually make the test pass reliably. 165181 165182 We need something like the opposite of check-read1: something that makes 165183 expect read a bit slower, or more exhaustively. 165184 165185 Add a new test target check-readmore that implements this. 165186 165187 There are two methods of implementing this in read1.c: 165188 - the first method waits a bit before doing a read 165189 - the second method does a read and then decides whether to 165190 return or to wait a bit and do another read, and so on. 165191 165192 The second method is potentially faster, has less risc of timeout and could 165193 potentially detect more problems. The first method has a simpler 165194 implementation. 165195 165196 The second method is enabled by default. The default waiting period is 10 165197 miliseconds. 165198 165199 The first method can be enabled using: 165200 ... 165201 $ export READMORE_METHOD=1 165202 ... 165203 and the waiting period can be specified in miliseconds using: 165204 ... 165205 $ export READMORE_SLEEP=9 165206 ... 165207 165208 Also a log file can be specified using: 165209 ... 165210 $ export READMORE_LOG=$(pwd -P)/LOG 165211 ... 165212 165213 Tested on x86_64-linux. 165214 165215 Testing with check-readmore showed these regressions: 165216 ... 165217 FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue) 165218 FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue) 165219 ... 165220 165221 I have not been able to find a problem in the test-case, and I think it's the 165222 nature of both the test-case and readmore that makes it run longer. Make 165223 these pass by increasing the alarm timeout from 60 to 120 seconds. 165224 165225 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957 165226 1652272021-10-09 Tom de Vries <tdevries@suse.de> 165228 165229 [gdb/testsuite] Fix fortran module tests with stressed cpu 165230 When running these test-cases: 165231 - gdb.fortran/info-modules.exp 165232 - gdb.fortran/module.exp 165233 - gdb.mi/mi-fortran-modules.exp 165234 in conjunction with: 165235 ... 165236 $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) 165237 ... 165238 I run into timeouts. 165239 165240 Fix this by using: 165241 - "set auto-solib-add off" to avoid symbols of shared libs 165242 (which doesn't work for libc, now that libpthread_name_p has been 165243 updated to match libc) 165244 - "nosharedlibrary" to avoid symbols of libc 165245 165246 Tested on x86_64-linux. 165247 165248 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133 165249 1652502021-10-09 Guillermo E. Martinez <guillermo.e.martinez@oracle.com> 165251 165252 PR28415, invalid read in xtensa_read_table_entries 165253 PR 28415 165254 PR 28416 165255 * elf32-xtensa.c (xtensa_read_table_entries): Handle error 165256 return from retrieve_contents. 165257 1652582021-10-09 GDB Administrator <gdbadmin@sourceware.org> 165259 165260 Automatic date update in version.in 165261 1652622021-10-08 Tom de Vries <tdevries@suse.de> 165263 165264 [gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpu 165265 When running test-case gdb.base/info-types-c++.exp in conjunction with: 165266 ... 165267 $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1)) 165268 ... 165269 we get: 165270 ... 165271 FAIL: gdb.base/info-types-c++.exp: info types (timeout) 165272 ... 165273 165274 Fix this by setting auto-solib-add to off. 165275 165276 Tested on x86_64-linux. 165277 1652782021-10-08 Tom de Vries <tdevries@suse.de> 165279 165280 [gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1 165281 When running test-case gdb.base/info_sources_2.exp with check-read1, I run 165282 into: 165283 ... 165284 FAIL: gdb.base/info_sources_2.exp: args: : info sources (timeout) 165285 ... 165286 165287 Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than 165288 as one whole line. 165289 165290 Also add the missing handling of "Objfile has no debug information". 165291 165292 Tested on x86_64-linux. 165293 1652942021-10-08 Tom de Vries <tdevries@suse.de> 165295 165296 [gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1 165297 When running test-case gdb.mi/gdb2549.exp with check-read1, I run into: 165298 ... 165299 FAIL: gdb.mi/gdb2549.exp: register values x (timeout) 165300 ... 165301 165302 Fix this by applying the same fix as for "register values t" in commit 165303 478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1". 165304 165305 Tested on x86_64-linux. 165306 1653072021-10-08 Tom de Vries <tdevries@suse.de> 165308 165309 [gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1 165310 When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1, 165311 I run into: 165312 ... 165313 (gdb) maint internal-error foobar^M 165314 src/gdb/maint.c:82: internal-error: foobar^M 165315 A problem internal to GDB has been detectedFAIL: \ 165316 gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \ 165317 scan for backtrace (GDB internal error) 165318 Resyncing due to internal error. 165319 ,^M 165320 ... 165321 165322 The corresponding gdb_test_multiple in the test-case contains: 165323 ... 165324 -early -re "^A problem internal to GDB has been detected,\r\n" { 165325 incr header_lines 165326 exp_continue 165327 } 165328 ... 165329 but instead this one triggers in gdb_test_multiple: 165330 ... 165331 -re ".*A problem internal to GDB has been detected" { 165332 fail "$message (GDB internal error)" 165333 gdb_internal_error_resync 165334 set result -1 165335 } 165336 ... 165337 165338 Fix this by likewise shortening the regexp to before the comma. 165339 165340 Tested on x86_64-linux. 165341 1653422021-10-08 Tom de Vries <tdevries@suse.de> 165343 165344 [gdb/testsuite] Add nopie in two test-cases 165345 When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with 165346 gcc-PIE installed (switching compiler default to -fPIE/-pie), I get: 165347 ... 165348 gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \ 165349 warning: relocation in read-only section `.text' 165350 ld: warning: creating DT_TEXTREL in a PIE 165351 UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare 165352 ... 165353 165354 This is due to using a hardcoded .S file that was generated with -fno-PIE. 165355 165356 Fix this by adding the missing nopie. 165357 165358 Likewise in gdb.arch/amd64-tailcall-noret.exp. 165359 165360 Tested on x86_64-linux. 165361 1653622021-10-08 GDB Administrator <gdbadmin@sourceware.org> 165363 165364 Automatic date update in version.in 165365 1653662021-10-07 Tom de Vries <tdevries@suse.de> 165367 165368 [gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34 165369 When running test-case gdb.threads/check-libthread-db.exp on openSUSE 165370 Tumbleweed (with glibc 2.34) I get: 165371 ... 165372 (gdb) continue^M 165373 Continuing.^M 165374 [Thread debugging using libthread_db enabled]^M 165375 Using host libthread_db library "/lib64/libthread_db.so.1".^M 165376 Stopped due to shared library event:^M 165377 Inferior loaded /lib64/libm.so.6^M 165378 /lib64/libc.so.6^M 165379 (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue 165380 ... 165381 165382 The check expect the inferior to load libpthread, but since glibc 2.34 165383 libpthread has been integrated into glibc, and consequently it's no longer 165384 a dependency: 165385 ... 165386 $ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db 165387 linux-vdso.so.1 (0x00007ffe4cae4000) 165388 libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000) 165389 libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000) 165390 /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000) 165391 ... 165392 165393 Fix this by updating the regexp to expect libpthread or libc. 165394 165395 Tested on x86_64-linux. 165396 1653972021-10-07 Tom de Vries <tdevries@suse.de> 165398 165399 [gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8 165400 With gcc 7.5.0, I get: 165401 ... 165402 (gdb) guile (print (type-range (field-type (type-field (value-type \ 165403 (value-dereference f)) "items"))))^M 165404 = (0 0)^M 165405 (gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \ 165406 on flexible array member: $cmd 165407 ... 165408 but with gcc 4.8.5, I get instead: 165409 ... 165410 (gdb) guile (print (type-range (field-type (type-field (value-type \ 165411 (value-dereference f)) "items"))))^M 165412 = (0 -1)^M 165413 (gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \ 165414 on flexible array member: $cmd 165415 ... 165416 165417 There's a difference in debug info. With gcc 4.8.5, we have: 165418 ... 165419 <2><224>: Abbrev Number: 15 (DW_TAG_member) 165420 <225> DW_AT_name : items 165421 <22b> DW_AT_type : <0x231> 165422 <1><231>: Abbrev Number: 4 (DW_TAG_array_type) 165423 <232> DW_AT_type : <0x105> 165424 <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type) 165425 <23b> DW_AT_type : <0x11a> 165426 <23f> DW_AT_upper_bound : 0xffffffffffffffff 165427 ... 165428 and with gcc 7.5.0, we have instead: 165429 ... 165430 <2><89f>: Abbrev Number: 12 (DW_TAG_member) 165431 <8a0> DW_AT_name : items 165432 <8a6> DW_AT_type : <0x8ac> 165433 <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type) 165434 <8ad> DW_AT_type : <0x29d> 165435 <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type) 165436 <2><8b6>: Abbrev Number: 0 165437 ... 165438 165439 As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust 165440 gdb.python/flexible-array-member.exp expected pattern": 165441 ... 165442 Ideally, GDB would present a consistent and documented value for an 165443 array member declared with size 0, regardless of how the debug info 165444 looks like. 165445 ... 165446 165447 As in gdb.python/flexible-array-member.exp, change the test to accept the two 165448 values. 165449 165450 Tested on x86_64-linux. 165451 1654522021-10-07 Simon Marchi <simon.marchi@polymtl.ca> 165453 165454 gdb: add accessors for field (and call site) location 165455 Add accessors for the various location values in struct field. This 165456 lets us assert that when we get a location value of a certain kind (say, 165457 bitpos), the field's location indeed contains a value of that kind. 165458 165459 Remove the SET_FIELD_* macros, instead use the new setters directly. 165460 Update the FIELD_* macros used to access field locations to go through 165461 the getters. They will be removed in a subsequent patch. 165462 165463 There are places where the FIELD_* macros are used on call_site_target 165464 structures, because it contains members of the same name (loc_kind and 165465 loc). For now, I have replicated the getters/setters in 165466 call_site_target. But we could perhaps eventually factor them in a 165467 "location" structure that can be used at both places. 165468 165469 Note that the field structure, being zero-initialized, defaults to a 165470 bitpos location with value 0. While writing this patch, I tried to make 165471 it default to an "unset" location, to catch places where we would miss 165472 setting a field's location. However, I found that some places relied on 165473 the default being "bitpos 0", so I left it as-is. This change could 165474 always be done as follow-up work, making these places explicitly set the 165475 "bitpos 0" location. 165476 165477 I found two issues to fix: 165478 165479 - I got some failures in the gdb.base/infcall-nested-structs-c++.exp 165480 test. They were caused by two functions in amd64-tdep.c using 165481 TYPE_FIELD_BITPOS before checking if the location is of the bitpos 165482 kind, which they do indirectly through `field_is_static`. Simply 165483 move getting the bitpos below the field_is_static call. 165484 165485 - I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in 165486 make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS, 165487 and later access them through FIELD_ENUMVAL. Fix that by using 165488 set_loc_enumval to set the value. 165489 165490 Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8 165491 1654922021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 165493 165494 RISC-V: Support aliases for Zbs instructions 165495 Add aliases for the non-immediate mnemonics of b{set,clr,inv,ext} to 165496 yencode the respective immediate insn b{set,clr,inv,ext}i when the 165497 second source operand is an immediate. 165498 165499 2021-01-11 Philipp Tomsich <philipp.tomsich@vrull.eu> 165500 165501 gas/ 165502 * testsuite/gas/riscv/b-ext.d: Add tests. 165503 * testsuite/gas/riscv/b-ext.s: Likewise. 165504 * testsuite/gas/riscv/b-ext-64.d: Likewise. 165505 * testsuite/gas/riscv/b-ext-64.s: Likewise. 165506 opcodes/ 165507 * riscv-opc.c (riscv_opcodes): Add aliases for Zbs. 165508 165509 Suggested-by: Jan Beulich <jbeulich@suse.com> 165510 1655112021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 165512 165513 RISC-V: Add support for Zbs instructions 165514 This change adds the Zbs instructions from the Zbs 1.0.0 specification. 165515 See 165516 https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0 165517 for the frozen specification. 165518 165519 2021-01-09 Philipp Tomsich <philipp.tomsich@vrull.eu> 165520 165521 bfd/ 165522 * elfxx-riscv.c (riscv_supported_std_z_ext): Added zbs. 165523 gas/ 165524 * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZBS. 165525 * testsuite/gas/riscv/b-ext.d: Test Zbs instructions. 165526 * testsuite/gas/riscv/b-ext.s: Likewise. 165527 * testsuite/gas/riscv/b-ext-64.d: Likewise. 165528 * testsuite/gas/riscv/b-ext-64.s: Likewise. 165529 include/ 165530 * opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for Zbs. 165531 * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZBS. 165532 opcodes/ 165533 * riscv-opc.c (riscv_supported_std_z_ext): Add zbs. 165534 1655352021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 165536 165537 RISC-V: Update extension version for Zb[abc] to 1.0.0 165538 2021-10-06 Philipp Tomsich <philipp.tomsich@vrull.eu> 165539 165540 bfd/ 165541 * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version 165542 number for zba, zbb and zbc to 1.0.0 165543 165544 165545 Version-changes: 3 165546 - Updated version numbers for zba, zbb and zbc to 1.0.0 165547 1655482021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu> 165549 165550 RISC-V: Split Zb[abc] into commented sections 165551 The Zb[abc] opcodes are bundled just below the Privileged opcodes in 165552 riscv_opcodes, possibly giving the appearance that they are part of 165553 the Privileged spec for an uninitiated reader. This separates them 165554 out and adds comments above each section to clearly identify them as 165555 Zba, Zbb or Zbc opcodes. 165556 165557 2021-10-04 Philipp Tomsich <philipp.tomsich@vrull.eu> 165558 165559 opcodes/ 165560 * riscv-opc.c: Split of Zb[abc] instructions and add comments. 165561 1655622021-10-07 Alan Modra <amodra@gmail.com> 165563 165564 PR28423, use-after-free in objdump 165565 XCOFF archives use a bi-directional linked list for file members. So 165566 one member points to both the previous member and the next member. 165567 Members may not be sequentially ordered in the file. This of course 165568 is over-engineered nonsense and an attractive target for fuzzers. 165569 (There is even a free list of members!) The testcase in PR28423 is an 165570 XCOFF archive with one member pointing to itself, which results in 165571 lots of bad behaviour. For example, "ar t" never terminates. 165572 165573 The use-after-free with "objdump -r" happens like this: The first 165574 archive element is opened, its symbols are read and "canonicalized" 165575 for objdump, then relocations are read and printed. Those relocations 165576 use the canonicalized symbols, and also happen to be cached by the 165577 coff bfd backend support. objdump frees the symbols. The next 165578 archive element is then opened. This must be done before the first 165579 element is closed, because finding the next element uses data held in 165580 the currect element. Unfortunately the next element happens to be the 165581 original, so we aren't opening, we're reopening a bfd which has cached 165582 data. When the relocations are printed they use the cached copy 165583 containing references to the freed canonical symbols. 165584 165585 This patch adds a little sanity checking to the XCOFF "open next 165586 archive file" support, so that it rejects archive members pointing at 165587 themselves. That is sufficient to cure this problem. Anything more 165588 is overkill. If someone deliberately fuzzes an XCOFF archive with an 165589 element loop then reports an "ar" bug when it runs forever, they will 165590 find their bug report closed WONTFIX. 165591 165592 PR 28423 165593 * coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied 165594 by member name in areltdata.extra_size. 165595 (_bfd_xcoff_openr_next_archived_file): Sanity check nextoff. 165596 * coff64-rs6000.c (xcoff64_openr_next_archived_file): Call 165597 _bfd_xcoff_openr_next_archived_file. 165598 1655992021-10-07 Alan Modra <amodra@gmail.com> 165600 165601 PR28422, build_id use-after-free 165602 This fixes a bug in commit 5d9bbb73c1df. All fields preserved from a 165603 bfd in struct bfd_preserve need to be cleared in bfd_reinit. 165604 165605 PR 28422 165606 * format.c (bfd_reinit): Clear build_id. 165607 1656082021-10-07 Alan Modra <amodra@gmail.com> 165609 165610 Change ridiculous section size error 165611 Rather than reporting "memory exhausted", report "file truncated". 165612 You can hit this error on small fuzzed object files, or on files that 165613 are actually truncated. In either case sizes can be such that an out 165614 of memory error is a little confusing. 165615 165616 * compress.c (bfd_get_full_section_contents): Set 165617 bfd_error_file_truncated rather than bfd_error_no_memory when 165618 section size exceeds file size. 165619 1656202021-10-07 Tom de Vries <tdevries@suse.de> 165621 165622 [gdb/testsuite] Fix FAIL in gdb.base/annota1.exp 165623 On openSUSE tumbleweed I run into: 165624 ... 165625 FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) 165626 ... 165627 due to a message related to libthread_db: 165628 ... 165629 ^Z^Zstarting^M 165630 [Thread debugging using libthread_db enabled]^M 165631 Using host libthread_db library "/lib64/libthread_db.so.1".^M 165632 ^M 165633 ^Z^Zframes-invalid^M 165634 ... 165635 which is not matched by the regexp. 165636 165637 Fix this by updating the regexp. 165638 165639 Tested on x86_64-linux. 165640 1656412021-10-07 Tom de Vries <tdevries@suse.de> 165642 165643 [gdb/testsuite] Refactor regexp in gdb.base/annota1.exp 165644 Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition. 165645 165646 Tested on x86_64-linux. 165647 1656482021-10-07 GDB Administrator <gdbadmin@sourceware.org> 165649 165650 Automatic date update in version.in 165651 1656522021-10-06 Andrew Burgess <andrew.burgess@embecosm.com> 165653 165654 gdb/doc: improve 'show print elements' description 165655 The documentation for 'show print elements' contains the line: 165656 165657 If the number is 0, then the printing is unlimited. 165658 165659 However, this line is now out of date as can be seen by this GDB 165660 session: 165661 165662 (gdb) set print elements 0 165663 (gdb) show print elements 165664 Limit on string chars or array elements to print is unlimited. 165665 165666 The value 0 does indeed mean unlimited, and this is described in the 165667 'set print elements' section, however, for 'show print elements' the 165668 user will never see the value 0, so lets just remove that bit from the 165669 docs. 165670 1656712021-10-06 Tom de Vries <tdevries@suse.de> 165672 165673 [gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.exp 165674 When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed, 165675 I run into: 165676 ... 165677 PASS: gdb.tui/corefile-run.exp: load corefile 165678 FAIL: gdb.tui/corefile-run.exp: run until the end 165679 ... 165680 165681 What's going on is easier to see when also doing dump_screen if 165682 check_contents passes, and inspecting state at the preceding PASS: 165683 ... 165684 +-------------------------------------------------------------------------+ 165685 exec No process In: L?? PC: ?? 165686 [New LWP 16629] 165687 [Thread debugging using libthread_db enabled] 165688 Using host libthread_db library "/lib64/libthread_db.so.1". 165689 Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output 165690 s/gdb.tui/corefile-run/corefi'. 165691 Program terminated with signal SIGTRAP, Trace/breakpoint trap. 165692 #0 main () 165693 --Type <RET> for more, q to quit, c to continue without paging-- 165694 ... 165695 165696 The problem is that we're getting a pagination prompt, and the subsequent run 165697 command is interpreted as an answer to that prompt. 165698 165699 Fix this by: 165700 - detecting the gdb prompt in response to "load corefile", such that 165701 we detect the failure earlier, and 165702 - doing a "set pagination off" in Term::clean_restart. 165703 165704 Tested on x86_64-linux. 165705 1657062021-10-06 Alan Modra <amodra@gmail.com> 165707 165708 PR28420, ecoff fuzzing failures 165709 PR 28420 165710 * coff-mips.c (mips_adjust_reloc_in): Replace abort with error 165711 message and return. 165712 * ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts, 165713 instead handle errors gracefully. 165714 1657152021-10-06 Alan Modra <amodra@gmail.com> 165716 165717 PR28402, fail to allocate line number array 165718 This fixes a situation where the COFF code allocated memory for 165719 internal representaion arrays before reading the external file data. 165720 That meant the allocation didn't have any sanity check against file 165721 size. 165722 165723 PR 28402 165724 * coffcode.h (buy_and_read): Malloc rather than alloc memory. 165725 (coff_slurp_line_table): Read native line number info before 165726 allocating memory for internal line number array. Adjust error 165727 paths to suit. Remove now unnecessary line number count check. 165728 (coff_slurp_reloc_table): Adjust to suit buy_and_read change. 165729 1657302021-10-06 Alan Modra <amodra@gmail.com> 165731 165732 PR28403, null pointer dereference in disassemble_bytes 165733 Indexing of symbol and howto arrays wasn't checked in aout targets. 165734 165735 PR 28403 165736 * aout-ns32k.c (MY (reloc_howto)): Sanity check howto_table index. 165737 Make r_index unsigned. 165738 (MY_swap_std_reloc_in): Make r_index unsigned. 165739 * aoutx.h (MOVE_ADDRESS): Sanity check symbol r_index. 165740 (aout_link_input_section_std): Make r_index unsigned. 165741 (aout_link_input_section_ext): Likewise. 165742 * i386lynx.c (MOVE_ADDRESS): Sanity check symbol r_index. 165743 (swap_ext_reloc_in, swap_std_reloc_in): Make r_index unsigned. 165744 * pdp11.c (MOVE_ADDRESS): Sanity check symbol r_index. 165745 1657462021-10-06 Alan Modra <amodra@gmail.com> 165747 165748 PR28401, invalid section name lookup 165749 The PR28401 testcase has a section named "", ie. an empty string. 165750 This results in some silly behaviour in load_debug_section, and 165751 dump_dwarf_section. Fix that. Note that this patch doesn't correct 165752 the main complaint in PR28401, "failed to allocate", since malloc 165753 failures on sections having huge bogus sizes are to be expected. We 165754 can't safely catch all such cases by comparing with file size, for 165755 example, where sections contain compressed data. 165756 165757 PR 28401 165758 * objdump.c (load_debug_section): Don't attempt to retrieve 165759 empty name sections. 165760 (dump_dwarf_section): Likewise. 165761 1657622021-10-06 GDB Administrator <gdbadmin@sourceware.org> 165763 165764 Automatic date update in version.in 165765 1657662021-10-06 Tom de Vries <tdevries@suse.de> 165767 165768 [gdb/testsuite] Make tui testing less verbose 165769 Currently, tui testing is rather verbose. When using these RUNTESTFLAGS to 165770 pick up all tui tests (17 in total): 165771 ... 165772 rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \ 165773 | xargs grep -l tuiterm_env) ) 165774 ... 165775 we have: 165776 ... 165777 $ wc -l gdb.log 165778 120592 gdb.log 165779 ... 165780 165781 Most of the output is related to controlling the tui screen, but that does 165782 not give a top-level sense of how the test-case progresses. 165783 165784 Put differently: a lot of bandwith is used to describe how we arrive at a 165785 certain tui screen state. But we don't actually always show the state we 165786 arrive at, unless there's a FAIL. 165787 165788 And if there's say, a PASS that should actually be FAILing, it's hard to 165789 detect. 165790 165791 Fix this by: 165792 - dropping the -log on the call to verbose in _log. We still can get the 165793 same info back using runtest -v. 165794 - dumping the screen or box that we're checking, also when the test passes. 165795 165796 Brings down verbosity to something more reasonable: 165797 ... 165798 $ wc -l gdb.log 165799 3221 gdb.log 165800 ... 165801 165802 Tested on x86_64-linux. 165803 1658042021-10-06 Tom de Vries <tdevries@suse.de> 165805 165806 [gdb/testsuite] Add Term::dump_box in lib/tuiterm.exp 165807 Factor out new proc Term::get_region and use it to implement a 165808 new proc Term::dump_box, similar to Term::dump_screen. 165809 165810 Tested on x86_64-linux. 165811 1658122021-10-05 Lancelot SIX <lsix@lancelotsix.com> 165813 165814 gdb: Remove deprecated assertion in setting::get 165815 The commit 702991711a91bd47b209289562843a11e7009396 (gdb: Have setter 165816 and getter callbacks for settings) makes it possible for a setting not 165817 to be backed by a memory buffer but use callback functions instead to 165818 retrieve or set the setting's value. 165819 165820 An assertion was not properly updated to take into account that the 165821 m_var member (which points to a memory buffer, if used) might be nullptr 165822 if the setting uses callback functions. If the setting is backed by a 165823 memory buffer, the m_var has to be non nullptr, which is already checked 165824 before the pointer is dereferenced. 165825 165826 This commit removes this assertion as it is not valid anymore. 165827 1658282021-10-05 Tom Tromey <tromey@adacore.com> 165829 165830 Remove 'varsize-limit' 165831 This makes the Ada-specific "varsize-limit" a synonym for 165832 "max-value-size", and removes the Ada-specific checks of the limit. 165833 165834 I am not certain of the history here, but it seems to me that this 165835 code is fully obsolete now. And, removing this makes it possible to 165836 index large Ada arrays without triggering an error. A new test case 165837 is included to demonstrate this. 165838 1658392021-10-05 Tom Tromey <tromey@adacore.com> 165840 165841 Allow lazy 'zero' value 165842 This changes value_zero to create a lazy value. In many cases, 165843 value_zero is called in expression evaluation to wrap a type in a 165844 non-eval context. It seems senseless to allocate a buffer in these 165845 cases. 165846 165847 A new 'is_zero' flag is added so we can preserve the existing 165848 assertions in value_fetch_lazy. 165849 165850 A subsequent patch will add a test where creating a zero value would 165851 fail, due to the variable size check. However, the contents of this 165852 value are never needed, and so creating a lazy value avoids the error 165853 case. 165854 1658552021-10-05 Tom Tromey <tromey@adacore.com> 165856 165857 Add lval_funcs::is_optimized_out 165858 This adds an is_optimized_out function pointer to lval_funcs, and 165859 changes value_optimized_out to call it. This new function lets gdb 165860 determine if a value is optimized out without necessarily fetching the 165861 value. This is needed for a subsequent patch, where an attempt to 165862 access a lazy value would fail due to the value size limit -- however, 165863 the access was only needed to determine the optimized-out state. 165864 1658652021-10-05 Tom de Vries <tdevries@suse.de> 165866 165867 [gdb/testsuite] Fix FAIL in gdb.mi/mi-nsmoribund.exp 165868 Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in 165869 mi_gdb_test" we run into: 165870 ... 165871 PASS: gdb.mi/mi-nsmoribund.exp: print done = 1 165872 Expecting: ^(.*[^M 165873 ]+)?([^ 165874 ]*^M 165875 \*running,thread-id="[0-9]+"^M 165876 \*running,thread-id="[0-9]+"^M 165877 \*running,thread-id="[0-9]+"^M 165878 \*running,thread-id="[0-9]+"^M 165879 \*running,thread-id="[0-9]+"^M 165880 \*running,thread-id="[0-9]+"^M 165881 \*running,thread-id="[0-9]+"^M 165882 \*running,thread-id="[0-9]+"^M 165883 \*running,thread-id="[0-9]+"^M 165884 \*running,thread-id="[0-9]+"[^M 165885 ]+[(]gdb[)] ^M 165886 [ ]*) 165887 103-exec-continue --all^M 165888 =library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\ 165889 host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\ 165890 ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M 165891 103^running^M 165892 *running,thread-id="5"^M 165893 (gdb) ^M 165894 FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output) 165895 ... 165896 165897 The regexp expect running messages for all threads, but we only get one for 165898 thread 5. 165899 165900 The test-case uses non-stop mode, and when the exec-continue --all command is 165901 issued, thread 5 is stopped and all other threads are running. Consequently, 165902 only thread 5 is resumed, and reported as running. 165903 165904 Fix this by updating the regexp. 165905 165906 Tested on x86_64-linux. 165907 1659082021-10-05 Andrew Burgess <andrew.burgess@embecosm.com> 165909 165910 gdb/python: fix memory leak in python inferior code 165911 When a user creates a gdb.Inferior object for the first time a new 165912 Python object is created. This object is then cached within GDB's 165913 inferior object using the registry mechanism (see 165914 inferior_to_inferior_object in py-inferior.c, specifically the calls 165915 to inferior_data and set_inferior_data). 165916 165917 The Python Reference to the gdb.Inferior object held within the real 165918 inferior object ensures that the reference count on the Python 165919 gdb.Inferior object never reaches zero while the GDB inferior object 165920 continues to exist. 165921 165922 At the same time, the gdb.Inferior object maintains a C++ pointer back 165923 to GDB's real inferior object. We therefore end up with a system that 165924 looks like this: 165925 165926 Python Reference 165927 | 165928 | 165929 .----------. | .--------------. 165930 | |------------------->| | 165931 | inferior | | gdb.Inferior | 165932 | |<-------------------| | 165933 '----------' | '--------------' 165934 | 165935 | 165936 C++ Pointer 165937 165938 When GDB's inferior object is deleted (say the inferior exits) then 165939 py_free_inferior is called (thanks to the registry system), this 165940 function looks up the Python gdb.Inferior object and sets the C++ 165941 pointer to nullptr and finally reduces the reference count on the 165942 Python gdb.Inferior object. 165943 165944 If at this point the user still holds a reference to the Python 165945 gdb.Inferior object then nothing happens. However, the gdb.Inferior 165946 object is now in the non-valid state (see infpy_is_valid in 165947 py-inferior.c), but otherwise, everything is fine. 165948 165949 However, if there are no further references to the Python gdb.Inferior 165950 object, or, once the user has given up all their references to the 165951 gdb.Inferior object, then infpy_dealloc is called. 165952 165953 This function currently checks to see if the inferior pointer within 165954 the gdb.Inferior object is nullptr or not. If the pointer is nullptr 165955 then infpy_dealloc immediately returns. 165956 165957 Only when the inferior point in the gdb.Inferior is not nullptr do 165958 we (a) set the gdb.Inferior reference inside GDB's inferior to 165959 nullptr, and (b) call the underlying Python tp_free function. 165960 165961 There are a number things wrong here: 165962 165963 1. The Python gdb.Inferior reference within GDB's inferior object 165964 holds a reference count, thus, setting this reference to nullptr 165965 without first decrementing the reference count would leak a 165966 reference, however... 165967 165968 2. As GDB's inferior holds a reference then infpy_dealloc will never 165969 be called until GDB's inferior object is deleted. Deleting a GDB 165970 inferior ohject calls py_free_inferior, and so gives up the 165971 reference. At this point there is no longer a need to call 165972 set_inferior_data to set the field back to NULL, that field must 165973 have been cleared in order to get the reference count to zero, which 165974 means... 165975 165976 3. If we know that py_free_inferior must be called before 165977 infpy_dealloc, then we know that the inferior pointer in 165978 gdb.Inferior will always be nullptr when infpy_dealloc is called, 165979 this means that the call to the underlying tp_free function will 165980 always be skipped. Skipping this call will cause Python to leak the 165981 memory associated with the gdb.Inferior object, which is what we 165982 currently always do. 165983 165984 Given all of the above, I assert that the C++ pointer within 165985 gdb.Inferior will always be nullptr when infpy_dealloc is called. 165986 That's what this patch does. 165987 165988 I wrote a test for this issue making use of Pythons tracemalloc 165989 module, which allows us to spot this memory leak. 165990 1659912021-10-05 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com> 165992 165993 [gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp 165994 Following 2 test points are failing with clang compiler 165995 165996 (gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_nofb print 165997 (gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_loopfb print 165998 165999 As in commit f677852bbda "[gdb/testsuite] Use function_range in 166000 gdb.dwarf2/dw2-abs-hi-pc.exp", the problem is that the CU and functions 166001 have an empty address range, due to using asm labels in global scope, 166002 which is a known source of problems, as explained in the comment of proc 166003 function_range in gdb/testsuite/lib/dwarf.exp. Hence fix this also by 166004 using function_range. 166005 166006 Tested on x86_64-linux with gcc and clang. 166007 1660082021-10-05 Andrew Burgess <andrew.burgess@embecosm.com> 166009 166010 gdb/python: add a new gdb_exiting event 166011 Add a new event, gdb.events.gdb_exiting, which is called once GDB 166012 decides it is going to exit. 166013 166014 This event is not triggered in the case that GDB performs a hard 166015 abort, for example, when handling an internal error and the user 166016 decides to quit the debug session, or if GDB hits an unexpected, 166017 fatal, signal. 166018 166019 This event is triggered if the user just types 'quit' at the command 166020 prompt, or if GDB is run with '-batch' and has processed all of the 166021 required commands. 166022 166023 The new event type is gdb.GdbExitingEvent, and it has a single 166024 attribute exit_code, which is the value that GDB is about to exit 166025 with. 166026 166027 The event is triggered before GDB starts dismantling any of its own 166028 internal state, so, my expectation is that most Python calls should 166029 work just fine at this point. 166030 166031 When considering this functionality I wondered about using the 166032 'atexit' Python module. However, this is triggered when the Python 166033 environment is shut down, which is done from a final cleanup. At 166034 this point we don't know for sure what other GDB state has already 166035 been cleaned up. 166036 1660372021-10-05 Andrew Burgess <andrew.burgess@embecosm.com> 166038 166039 gdb/python: update events test to handle missing exit_code 166040 The test gdb.python/py-events.exp sets up a handler for the gdb.exited 166041 event. Unfortunately the handler is slightly broken, it assumes that 166042 the exit_code attribute will always be present. This is not always 166043 the case. 166044 166045 In a later commit I am going to add more tests to py-events.exp test 166046 script, and in so doing I expose the bug in our handling of gdb.exited 166047 events. 166048 166049 Just to be clear, GDB itself is fine, it is the test that is not 166050 written correctly according to the Python Events API. 166051 166052 So, in this commit I fix the Python code in the test, and extend the 166053 test case to exercise more paths through the Python code. 166054 166055 Additionally, I noticed that the gdb.exited event is used as an 166056 example in the documentation for how to write an event handler. 166057 Unfortunately the same bug that we had in our test was also present in 166058 the example code in the manual. 166059 166060 So I've fixed that too. 166061 166062 After this commit there is no functional change to GDB. 166063 1660642021-10-05 GDB Administrator <gdbadmin@sourceware.org> 166065 166066 Automatic date update in version.in 166067 1660682021-10-04 Tom Tromey <tromey@adacore.com> 166069 166070 Use unique_xmalloc_ptr<char> when demangling 166071 I noticed that some methods in language_defn could use 166072 unique_xmalloc_ptr<char> rather than a plain 'char *'. This patch 166073 implements this change, fixing up the fallout and changing 166074 gdb_demangle to also return this type. In one spot, std::string is 166075 used to simplify some related code, and in another, an auto_obstack is 166076 used to avoid manual management. 166077 166078 Regression tested on x86-64 Fedora 34. 166079 1660802021-10-04 Tom Tromey <tromey@adacore.com> 166081 166082 Minor boolean fix in windows-nat.c 166083 I noticed a spot in windows-nat.c that used '1' rather than the more 166084 appropriate 'true'. This patch fixes it. 166085 1660862021-10-04 Tom de Vries <tdevries@suse.de> 166087 166088 [gdb/build] Add CXX_DIALECT to CXX 166089 Say we use a gcc version that (while supporting c++11) does not support c++11 166090 by default, and needs an -std setting to enable it. 166091 166092 If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then 166093 we'd have: 166094 ... 166095 CXX="g++ -std=gnu++11" 166096 ... 166097 166098 That mechanism however has the following problem (quoting from commit 166099 0bcda685399): 166100 ... 166101 the top level Makefile passes CXX down to subdirs, and that overrides whatever 166102 gdb/Makefile may set CXX to. The result would be that a make invocation from 166103 the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a 166104 make invocation at the top level would not. 166105 ... 166106 166107 Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which 166108 does: 166109 ... 166110 CXX=g++ 166111 CXX_DIALECT=-std=gnu++11 166112 ... 166113 166114 The problem reported in PR28318 is that using the custom instead of the 166115 default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread 166116 support fail. 166117 166118 We could simply add $CXX_DIALECT to the test for std::thread support, but 166119 that would have to be repeated for each added c++ support test. 166120 166121 Instead, fix this by doing: 166122 ... 166123 CXX="g++ -std=gnu++11" 166124 CXX_DIALECT=-std=gnu++11 166125 ... 166126 166127 This is somewhat awkward, since it results in -std=gnu++11 occuring twice in 166128 some situations: 166129 ... 166130 $ touch src/gdb/dwarf2/read.c 166131 $ ( cd build/gdb; make V=1 dwarf2/read.o ) 166132 g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ... 166133 ... 166134 166135 However, both settings are needed: 166136 - the switch in CXX for the std::thread tests (and other tests) 166137 - the switch in CXX_DIALECT so it can be appended in Makefiles, to 166138 counteract the fact that the top-level Makefile overrides CXX 166139 166140 The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default 166141 AX_CXX_COMPILE_STDCXX from autoconf-archive. 166142 166143 Tested on x86_64-linux. 166144 166145 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318 166146 1661472021-10-04 Simon Marchi <simon.marchi@polymtl.ca> 166148 166149 [gdb/symtab] Use unrelocated addresses in call_site 166150 Consider test-case gdb.trace/entry-values.exp with target board 166151 unix/-fPIE/-pie. 166152 166153 Using this command we have an abbreviated version, and can see the correct 166154 @entry values for foo: 166155 ... 166156 $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \ 166157 -ex start \ 166158 -ex "break foo" \ 166159 -ex "set print entry-values both" \ 166160 -ex continue 166161 Temporary breakpoint 1 at 0x679 166162 166163 Temporary breakpoint 1, 0x0000555555554679 in main () 166164 Breakpoint 2 at 0x55555555463e 166165 166166 Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3) 166167 ... 166168 166169 Now, let's try the same again, but run directly to foo rather than stopping at 166170 main: 166171 ... 166172 $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \ 166173 -ex "break foo" \ 166174 -ex "set print entry-values both" \ 166175 -ex run 166176 Breakpoint 1 at 0x63e 166177 166178 Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=<optimized out>, \ 166179 j=2, j@entry=<optimized out>) 166180 ... 166181 166182 So, what explains the difference? Noteworthy, this is a dwarf assembly 166183 test-case, with debug info for foo and bar, but not for main. 166184 166185 In the first case: 166186 - we run to main 166187 - this does not trigger expanding debug info, because there's none for main 166188 - we set a breakpoint at foo 166189 - this triggers expanding debug info. Relocated addresses are used in 166190 call_site info (because the exec is started) 166191 - we continue to foo, and manage to find the call_site info 166192 166193 In the second case: 166194 - we set a breakpoint at foo 166195 - this triggers expanding debug info. Unrelocated addresses are used in 166196 call_site info (because the exec is not started) 166197 - we run to foo 166198 - this triggers objfile_relocate1, but it doesn't update the call_site 166199 info addresses 166200 - we don't manage to find the call_site info 166201 166202 We could fix this by adding the missing call_site relocation in 166203 objfile_relocate1. 166204 166205 This solution however is counter-trend in the sense that we're trying to 166206 work towards the situation where when starting two instances of an executable, 166207 we need only one instance of debug information, implying the use of 166208 unrelocated addresses. 166209 166210 So, fix this instead by using unrelocated addresses in call_site info. 166211 166212 Tested on x86_64-linux. 166213 166214 This fixes all remaining unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie 166215 regressions, like f.i. PR24892. 166216 166217 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24892 166218 166219 Co-Authored-By: Tom de Vries <tdevries@suse.de> 166220 1662212021-10-04 Simon Marchi <simon.marchi@polymtl.ca> 166222 166223 [gdb/symtab] C++-ify call_site 166224 - add constructor 166225 - add member function call_site::pc () 166226 166227 Tested on x86_64-linux. 166228 166229 Co-Authored-By: Tom de Vries <tdevries@suse.de> 166230 1662312021-10-04 Tom de Vries <tdevries@suse.de> 166232 166233 [gdb/symtab] Add call_site_eq and call_site_hash 166234 In commit b4c919f7525 "[gdb/symtab] Fix htab_find_slot call in 166235 read_call_site_scope" , I removed the comment: 166236 ... 166237 It must be the first field as we overload core_addr_hash and core_addr_eq for 166238 it. 166239 ... 166240 for field pc of struct call_site. 166241 166242 However, this was not tested, and when indeed moving field pc to the second 166243 location, we run into a testsuite failure in gdb.trace/entry-values.exp. 166244 166245 This is caused by core_addr_eq (the eq_f function for the htab) being 166246 called with a pointer to the pc field (as passed into htab_find_slot) and a 166247 pointer to a hash table element. Now that pc is no longer the first field, 166248 the pointer to hash table element no longer points to the pc field. 166249 166250 This could be fixed by simply reinstating the comment, but we're trying to 166251 get rid of this kind of tricks that make refactoring more difficult. 166252 166253 Instead, fix this by: 166254 - reverting commit b4c919f7525, apart from the comment removal, such that 166255 we're passing a pointer to element to htab_find_slot 166256 - updating the htab_find_slot call in compunit_symtab::find_call_site 166257 in a similar manner 166258 - adding a call_site_eq and call_site_hash, and using these in the hash table 166259 instead of core_addr_eq and core_addr_hash. 166260 166261 Tested on x86_64-linux, both with and without a trigger patch that moves pc to 166262 the second location in struct call_site. 166263 1662642021-10-04 Tom Tromey <tromey@adacore.com> 166265 166266 Fix remote-sim.c compilation 166267 The change "make string-like set show commands use std::string 166268 variable" caused remote-sim.c to fail to build. The issue is that the 166269 code does: 166270 166271 const std::string &sysroot = gdb_sysroot; 166272 if (is_target_filename (sysroot)) 166273 sysroot += strlen (TARGET_SYSROOT_PREFIX); 166274 166275 ... which isn't valid. 166276 166277 This patch changes this code to use a 'const char *' again, fixing the 166278 build. 166279 1662802021-10-04 Bruno Larsen <blarsen@redhat.com> 166281 166282 [gdb/testsuite] update analyze-racy-logs.py to python3 166283 Since python 2 is no longer supported on most distributions, update the 166284 script to run under python while while still being runnable under 166285 python2. 166286 1662872021-10-04 Andrew Burgess <andrew.burgess@embecosm.com> 166288 166289 gdbsupport: remove attempt to define TARGET_WORD_SIZE 166290 In the gdbsupport configure.ac file, there is an attempt to define 166291 TARGET_WORD_SIZE. This is done by running grep on the file 166292 ../bfd/bfd-in3.h. 166293 166294 The problem with this is, the file bfd-in3.h is generated into the bfd 166295 build directory when bfd is configured, and there is no dependency 166296 between the gdbsupport module and the bfd module, so, for example, if 166297 I do: 166298 166299 $ ../src/configure 166300 $ make all-gdbsupport 166301 166302 Then bfd will neither be configured, or built. In this case 166303 TARGET_WORD_SIZE ends up being defined, but with no value because the 166304 grep on bfd-in3.h fails. 166305 166306 However, it turns out that this doesn't matter; we don't actually use 166307 TARGET_WORD_SIZE anywhere. 166308 166309 My proposal in this commit is to just remove the definition of 166310 TARGET_WORD_SIZE, the alternative would be to add a dependency between 166311 configure-gdbsupport and configure-bfd into Makefile.def, but adding a 166312 dependency for something we don't need seems pretty pointless. 166313 1663142021-10-04 Mike Frysinger <vapier@gentoo.org> 166315 166316 sim: add --info-target for listing supported BFD targets 166317 It can be difficult to guess the exact bfd name, so add an option to 166318 list all the targets that the current build supports. This aligns with 166319 other simulator options like --info-architecture. 166320 1663212021-10-04 GDB Administrator <gdbadmin@sourceware.org> 166322 166323 Automatic date update in version.in 166324 1663252021-10-03 Lancelot SIX <lsix@lancelotsix.com> 166326 166327 gdb: Setting setter return a bool to tell if the value changed 166328 GDB can notify observers when a parameter is changed. 166329 166330 To do that, do_set_command (in gdb/cli/cli-setshow.c) compares the new 166331 value against the old one before updating it, and based on that notifies 166332 observers. This looks like something like: 166333 166334 int valuechanged = 0; 166335 switch (cmd->var.type ()) 166336 { 166337 case var_integer: 166338 { 166339 LONGEST new_val = parse_and_eval_long (arg) 166340 if (new_val != cmd->var.get<int> ()) 166341 { 166342 cmd->var.get<int> (new_val); 166343 value_changes = 1; 166344 } 166345 } 166346 case var_uinteger: 166347 case var_zuinteger: 166348 { 166349 unsigned int val 166350 = parse_cli_var_uinteger (c->var->type (), &arg, true); 166351 if (c->var->get<unsigned int> () != val) 166352 { 166353 c->var->set<unsigned int> (val); 166354 option_changed = true; 166355 } 166356 } 166357 case... 166358 /* And so on for all possible var_types. */ 166359 } 166360 166361 This comparison is done for each possible var_type, which leads to 166362 unnecessary logic duplication. 166363 166364 In this patch I propose to move all those checks in one place within the 166365 setting setter method. This limits the code duplication and simplifies 166366 the do_set_command implementation. 166367 166368 This patch also changes slightly the way a value change is detected. 166369 Instead of comparing the user provided value against the current value 166370 of the setting, we compare the value of the setting before and after the 166371 set operation. This is meant to handle edge cases where trying to set 166372 an unrecognized value would be equivalent to a noop (the actual value 166373 remains unchanged). Doing this requires that the original value needs 166374 to be copied before the update, which can be non trivial for 166375 std::string. 166376 166377 There should be no user visible change introduced by this commit. 166378 166379 Tested on x86_64 GNU/Linux. 166380 166381 [1] https://review.lttng.org/c/binutils-gdb/+/5831/41 166382 166383 Change-Id: If064b9cede3eb56275aacd2b286f74eceb1aed11 166384 1663852021-10-03 Lancelot SIX <lsix@lancelotsix.com> 166386 Simon Marchi <simon.marchi@polymtl.ca> 166387 166388 gdb: Have setter and getter callbacks for settings 166389 The main motivation behind this improvement is to help the 166390 implementation of a patch Simon Marchi is preparing to fix a bug when 166391 MI or Python try to access parameters that are inferior dependent (see 166392 PR/28085). 166393 166394 This commit extends the previous ones, which introduces the setting 166395 object to represent a static variable whose value can be set or shown 166396 with the appropriate commands. This patch proposes that a setting can 166397 either contain a pointer to a static variable holding a setting, or 166398 pointers to a pair of setter and getter callback functions. 166399 166400 The callbacks functions can be used to retrieve or change the value with 166401 custom logic. This is useful when the source of truth for a given 166402 setting is not contained in the variable pointed to by the setting 166403 instance. 166404 166405 Given that the callback function call is hidden within the setting 166406 abstraction introduced earlier, none of the sites accessing the setting 166407 needs to be updated. The registered getter or setter is used whatever 166408 the way to access it is (through MI, Python, Guile, the "with" command 166409 and the $_gdb_setting / $_gdb_setting_str convenience functions). 166410 166411 All the add_setshow_*_cmd are given a new overload that will accept the 166412 pair of function pointers (set / get functions) instead of the pointer 166413 to a global variable. 166414 166415 Tested on GNU/Linux x86_64 with no regression observed. 166416 166417 Change-Id: Ieb81fef57550632ff66e6aa85f637372a226be8c 166418 1664192021-10-03 Simon Marchi <simon.marchi@efficios.com> 166420 Lancelot SIX <lsix@lancelotsix.com> 166421 166422 gdb: make string-like set show commands use std::string variable 166423 String-like settings (var_string, var_filename, var_optional_filename, 166424 var_string_noescape) currently take a pointer to a `char *` storage 166425 variable (typically global) that holds the setting's value. I'd like to 166426 "mordernize" this by changing them to use an std::string for storage. 166427 166428 An obvious reason is that string operations on std::string are often 166429 easier to write than with C strings. And they avoid having to do any 166430 manual memory management. 166431 166432 Another interesting reason is that, with `char *`, nullptr and an empty 166433 string often both have the same meaning of "no value". String settings 166434 are initially nullptr (unless initialized otherwise). But when doing 166435 "set foo" (where `foo` is a string setting), the setting now points to 166436 an empty string. For example, solib_search_path is nullptr at startup, 166437 but points to an empty string after doing "set solib-search-path". This 166438 leads to some code that needs to check for both to check for "no value". 166439 Or some code that converts back and forth between NULL and "" when 166440 getting or setting the value. I find this very error-prone, because it 166441 is very easy to forget one or the other. With std::string, we at least 166442 know that the variable is not "NULL". There is only one way of 166443 representing an empty string setting, that is with an empty string. 166444 166445 I was wondering whether the distinction between NULL and "" would be 166446 important for some setting, but it doesn't seem so. If that ever 166447 happens, it would be more C++-y and self-descriptive to use 166448 optional<string> anyway. 166449 166450 Actually, there's one spot where this distinction mattered, it's in 166451 init_history, for the test gdb.base/gdbinit-history.exp. init_history 166452 sets the history filename to the default ".gdb_history" if it sees that 166453 the setting was never set - if history_filename is nullptr. If 166454 history_filename is an empty string, it means the setting was explicitly 166455 cleared, so it leaves it as-is. With the change to std::string, this 166456 distinction doesn't exist anymore. This can be fixed by moving the code 166457 that chooses a good default value for history_filename to 166458 _initialize_top. This is ran before -ex commands are processed, so an 166459 -ex command can then clear that value if needed (what 166460 gdb.base/gdbinit-history.exp tests). 166461 166462 Another small improvement, in my opinion is that we can now easily 166463 give string parameters initial values, by simply initializing the global 166464 variables, instead of xstrdup-ing it in the _initialize function. 166465 166466 In Python and Guile, when registering a string-like parameter, we 166467 allocate (with new) an std::string that is owned by the param_smob (in 166468 Guile) and the parmpy_object (in Python) objects. 166469 166470 This patch started by changing all relevant add_setshow_* commands to 166471 take an `std::string *` instead of a `char **` and fixing everything 166472 that failed to build. That includes of course all string setting 166473 variable and their uses. 166474 166475 string_option_def now uses an std::string also, because there's a 166476 connection between options and settings (see 166477 add_setshow_cmds_for_options). 166478 166479 The add_path function in source.c is really complex and twisted, I'd 166480 rather not try to change it to work on an std::string right now. 166481 Instead, I added an overload that copies the std:string to a `char *` 166482 and back. This means more copying, but this is not used in a hot path 166483 at all, so I think it is acceptable. 166484 166485 Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 166486 1664872021-10-03 Lancelot SIX <lsix@lancelotsix.com> 166488 Simon Marchi <simon.marchi@polymtl.ca> 166489 166490 gdb: Introduce setting construct within cmd_list_element 166491 cmd_list_element can contain a pointer to data that can be set and / or 166492 shown. This is achieved with the void* VAR member which points to the 166493 data that can be accessed, while the VAR_TYPE member (of type enum 166494 var_types) indicates how to interpret the data pointed to. 166495 166496 With this pattern, the user of the cmd_list_element needs to know what 166497 is the storage type associated with a given VAR_TYPES in order to do 166498 the proper casting. No automatic safeguard is available to prevent 166499 miss-use of the pointer. Client code typically looks something like: 166500 166501 switch (c->var_type) 166502 { 166503 case var_zuinteger: 166504 unsigned int v = *(unsigned int*) c->var; 166505 ... 166506 break; 166507 case var_boolean: 166508 bool v = *(bool *) c->var; 166509 ... 166510 break; 166511 ... 166512 } 166513 166514 This patch proposes to add an abstraction around the var_types and void* 166515 pointer pair. The abstraction is meant to prevent the user from having 166516 to handle the cast and verify that the data is read or written as a type 166517 that is coherent with the setting's var_type. This is achieved by 166518 introducing the struct setting which exposes a set of templated get / 166519 set member functions. The template parameter is the type of the 166520 variable that holds the referred variable. 166521 166522 Using those accessors allows runtime checks to be inserted in order to 166523 ensure that the data pointed to has the expected type. For example, 166524 instantiating the member functions with bool will yield something 166525 similar to: 166526 166527 const bool &get<bool> () const 166528 { 166529 gdb_assert (m_var_type == var_boolean); 166530 gdb_assert (m_var != nullptr); 166531 return *static_cast<bool *> (m_var); 166532 } 166533 void set<bool> (const bool &var) 166534 { 166535 gdb_assert (m_var_type == var_boolean); 166536 gdb_assert (m_var != nullptr); 166537 *static_cast<bool *> (m_var) = var; 166538 } 166539 166540 Using the new abstraction, our initial example becomes: 166541 166542 switch (c->var_type) 166543 { 166544 case var_zuinteger: 166545 unsigned int v = c->var->get<unsigned int> (); 166546 ... 166547 break; 166548 case var_boolean: 166549 bool v = c->var->get<bool> (); 166550 ... 166551 break; 166552 ... 166553 } 166554 166555 While the call site is still similar, the introduction of runtime checks 166556 help ensure correct usage of the data. 166557 166558 In order to avoid turning the bulk of add_setshow_cmd_full into a 166559 templated function, and following a suggestion from Pedro Alves, a 166560 setting can be constructed from a pre validated type erased reference to 166561 a variable. This is what setting::erased_args is used for. 166562 166563 Introducing an opaque abstraction to describe a setting will also make 166564 it possible to use callbacks to retrieve or set the value of the setting 166565 on the fly instead of pointing to a static chunk of memory. This will 166566 be done added in a later commit. 166567 166568 Given that a cmd_list_element may or may not reference a setting, the 166569 VAR and VAR_TYPES members of the struct are replaced with a 166570 gdb::optional<setting> named VAR. 166571 166572 Few internal function signatures have been modified to take into account 166573 this new abstraction: 166574 166575 -The functions value_from_setting, str_value_from_setting and 166576 get_setshow_command_value_string used to have a 'cmd_list_element *' 166577 parameter but only used it for the VAR and VAR_TYPE member. They now 166578 take a 'const setting &' parameter instead. 166579 - Similarly, the 'void *' and a 'enum var_types' parameters of 166580 pascm_param_value and gdbpy_parameter_value have been replaced with a 166581 'const setting &' parameter. 166582 166583 No user visible change is expected after this patch. 166584 166585 Tested on GNU/Linux x86_64, with no regression noticed. 166586 166587 Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34 166588 1665892021-10-03 Mike Frysinger <vapier@gentoo.org> 166590 166591 sim: filter out SIGSTKSZ [PR sim/28302] 166592 We map target signals to host signals so we can propagate signals 166593 between the host & simulated worlds. That means we need to know 166594 the symbolic names & values of all signals that might be sent. 166595 166596 The tools that generate that list use signal.h and include all 166597 symbols that start with "SIG" so as to automatically include any 166598 new symbols that the C library might add. Unfortunately, this 166599 also picks up "SIGSTKSZ" which is not actually a signal itself, 166600 but a signal related setting -- it's the size of the stack when 166601 a signal is handled. 166602 166603 By itself this doesn't super matter as we will never see a signal 166604 with that same value (since the range of valid signals tend to be 166605 way less than 1024, and the size of the default signal stack will 166606 never be that small). But with recent glibc changes that make this 166607 into a dynamic value instead of a compile-time constant, some users 166608 see build failures when building the sim. 166609 166610 As suggested by Adam Sampson, update our scripts to ignore this 166611 symbol to simplify everything and avoid the build failure. 166612 166613 Bug: https://sourceware.org/PR28302 166614 1666152021-10-03 Mike Frysinger <vapier@gentoo.org> 166616 166617 sim: ppc: fallback when ln is not available [PR sim/18864] 166618 Not all systems have easy access to hard links or symlinks, so add 166619 fallback logic to the run->psim build code to handle those. 166620 166621 Bug: https://sourceware.org/PR18864 166622 1666232021-10-03 Lancelot SIX <lsix@lancelotsix.com> 166624 166625 gdb: Fix comment in riscv_scan_prologue 166626 I found an inaccurate comment in riscv_scan_prologue. This commit fixes 166627 it. 166628 1666292021-10-03 Lancelot SIX <lsix@lancelotsix.com> 166630 166631 gdb: Support the c.mv insn in the riscv prologue scanner. 166632 While working on other problems, I encountered situations where GDB 166633 fails to properly unwind the stack because some functions use the C.MV 166634 instruction in the prologue. The prologue scanner stops when it hits 166635 this instruction assuming its job is done at this point. Unfortunately 166636 the prologue is not necessarily finished yet, preventing GDB to properly 166637 unwind. 166638 166639 This commit adds support for handling such instruction in 166640 riscv_scan_prologue. 166641 166642 Note that C.MV is part of the compressed instruction set. The MV 166643 counterpart from the base ISA is a pseudo instruction that expands to 166644 'ADDI RD,RS1,0' which is already supported. 166645 166646 Tested on riscv64-linux-gnu. 166647 166648 All feedback are welcome. 166649 1666502021-10-03 GDB Administrator <gdbadmin@sourceware.org> 166651 166652 Automatic date update in version.in 166653 1666542021-10-02 Simon Marchi <simon.marchi@polymtl.ca> 166655 166656 [gdb/symtab] Remove COMPUNIT_CALL_SITE_HTAB 166657 Remove macro COMPUNIT_CALL_SITE_HTAB, and provide access to the htab using 166658 member functions: 166659 - compunit_symtab::find_call_site 166660 - compunit_symtab::set_call_site_htab 166661 166662 Tested on x86_64-linux. 166663 166664 Co-Authored-By: Tom de Vries <tdevries@suse.de> 166665 1666662021-10-02 Simon Marchi <simon.marchi@polymtl.ca> 166667 166668 gdb/python: fix a few flake8 warnings 166669 Fix these rather obvious warnings reported by flake8: 166670 166671 ./lib/gdb/FrameIterator.py:16:1: F401 'gdb' imported but unused 166672 ./lib/gdb/FrameIterator.py:17:1: F401 'itertools' imported but unused 166673 ./lib/gdb/command/prompt.py:55:26: E712 comparison to False should be 'if cond is False:' or 'if not cond:' 166674 ./lib/gdb/command/explore.py:526:9: F841 local variable 'has_explorable_fields' is assigned to but never used 166675 ./lib/gdb/command/explore.py:697:56: E712 comparison to False should be 'if cond is False:' or 'if not cond:' 166676 ./lib/gdb/command/explore.py:736:62: E712 comparison to False should be 'if cond is False:' or 'if not cond:' 166677 ./lib/gdb/command/explore.py:767:61: E712 comparison to False should be 'if cond is False:' or 'if not cond:' 166678 ./lib/gdb/command/frame_filters.py:21:1: F401 'copy' imported but unused 166679 ./lib/gdb/command/frame_filters.py:22:1: F401 'gdb.FrameIterator.FrameIterator' imported but unused 166680 ./lib/gdb/command/frame_filters.py:23:1: F401 'gdb.FrameDecorator.FrameDecorator' imported but unused 166681 ./lib/gdb/command/frame_filters.py:25:1: F401 'itertools' imported but unused 166682 ./lib/gdb/command/frame_filters.py:179:17: E712 comparison to True should be 'if cond is True:' or 'if cond:' 166683 166684 Change-Id: I4f49c0cb430359ee872222600c61d9c5283b09ab 166685 1666862021-10-02 GDB Administrator <gdbadmin@sourceware.org> 166687 166688 Automatic date update in version.in 166689 1666902021-10-01 Luis Machado <luis.machado@linaro.org> 166691 166692 Fix build failure for 32-bit targets 166693 When building master GDB, I ran into the following: 166694 166695 binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)': 166696 binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=] 166697 snprintf (buf, sizeof (buf), "0x%lx ", pc); 166698 166699 Fix this by using %PRIxPTR as opposed to %lx. 166700 1667012021-10-01 Nick Clifton <nickc@redhat.com> 166702 166703 Fix mistake in RX assembler documentation (special section names) 166704 1667052021-10-01 Simon Marchi <simon.marchi@polymtl.ca> 166706 166707 [gdb/symtab] Fix htab_find_slot call in read_call_site_scope 166708 In read_call_site_scope we have: 166709 ... 166710 call_site_local.pc = pc; 166711 slot = htab_find_slot (cu->call_site_htab, &call_site_local, INSERT); 166712 ... 166713 166714 The call passes a call_site pointer as element. OTOH, the hashtab is created 166715 using hash_f == core_addr_hash and eq_f == core_addr_eq, so the element 166716 will be accessed through a CORE_ADDR pointer. 166717 166718 This is not wrong (at least in C), given that pc is the first field in 166719 call_site. 166720 166721 Nevertheless, as in call_site_for_pc, make the htab_find_slot call match the 166722 used hash_f and eq_f by using &pc instead: 166723 ... 166724 slot = htab_find_slot (cu->call_site_htab, &pc, INSERT); 166725 ... 166726 166727 Tested on x86_64-linux. 166728 166729 Co-Authored-By: Tom de Vries <tdevries@suse.de> 166730 1667312021-10-01 Andrea Corallo <andrea.corallo@arm.com> 166732 166733 PATCH bfd: Fix linker warning for recently introduced arm attributes 166734 2021-09-27 Andrea Corallo <andrea.corallo@arm.com> 166735 166736 * elf-bfd.h (NUM_KNOWN_OBJ_ATTRIBUTES): Update value to cover 166737 'Tag_BTI_use' and 'Tag_PACRET_use'. 166738 1667392021-10-01 Simon Marchi <simon.marchi@polymtl.ca> 166740 166741 gdb/testsuite/dwarf: use options for rnglists/loclists procs 166742 Change how rnglists and loclists procs to align them with how procs for 166743 aranges (and other things in the DWARF assembler) work. Instead of 166744 using "args" (variable number of parameters in TCL) and command-line 166745 style option arguments, use one leading "option" parameters, used as a 166746 kind of key/value dictionary of options parsed using `parse_options`. 166747 166748 Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a 166749 1667502021-10-01 Simon Marchi <simon.marchi@polymtl.ca> 166751 166752 gdb/testsuite/dwarf: don't define nested procs for rnglists/loclists 166753 When I wrote support for rnglists and loclists in the testsuite's DWARF 166754 assembler, I made it with nested procs, for example proc "table" inside 166755 proc "rnglists". The intention was that this proc "table" could only be 166756 used by the user while inside proc "rnglists"'s body. I had chosen very 166757 simple names, thinking there was no chance of name clashes. I recently 166758 learned that this is not how TCL works. This ends up defining a proc 166759 "table" in the current namespace ("Dwarf" in this case). 166760 166761 Things still work if you generate rnglists and loclists in the same 166762 file, as each redefines its own procedures when executing. But if a 166763 user of the assembler happened to define a convenience "table" or 166764 "start_end" procedure, for example, it would get overriden. 166765 166766 I'd like to change how this works to reduce the chances of a name clash. 166767 166768 - Move the procs out of each other, so they are not defined in a nested 166769 fashion. 166770 - Prefix them with "_rnglists_" or "_loclists_". 166771 - While calling $body in the various procs, temporarily make the procs 166772 available under their "short" name. For example, while in rngllists' 166773 body, make _rnglists_table available as just "table". This allows 166774 existing code to keep working and keeps it not too verbose. 166775 - Modify with_override to allow the overriden proc to not exist. In 166776 that case, the temporary proc is deleted on exit. 166777 166778 Note the non-conforming indentation when calling with_override in 166779 _loclists_list. This is on purpose: as we implement more loclists (and 166780 rnglists) entry types, the indentation would otherwise get larger and 166781 larger without much value for readability. So I think it's reasonable 166782 here to put them on the same level. 166783 166784 Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328 166785 1667862021-10-01 Simon Marchi <simon.marchi@polymtl.ca> 166787 166788 gdb: remove TYPE_FIELD_NAME and FIELD_NAME macros 166789 Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the 166790 call sites to use field::name directly. 166791 166792 Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6 166793 1667942021-10-01 Simon Marchi <simon.marchi@polymtl.ca> 166795 166796 gdb: add field::name / field::set_name 166797 Add the `name` and `set_name` methods on `struct field`, in order to 166798 remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the 166799 macros are changed to use `field::name`, so all the call sites that are 166800 used to set the field's name are changed to use `field::set_name`. 166801 The next patch will remove the macros completely. 166802 166803 Note that because of the name clash between the existing field named 166804 `name` and the new method, I renamed the field `m_name`. It is not 166805 private per-se, because we can't make `struct field` a non-POD yet, but 166806 it should be considered private anyway (not accessed outside `struct 166807 field`). 166808 166809 Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896 166810 1668112021-10-01 GDB Administrator <gdbadmin@sourceware.org> 166812 166813 Automatic date update in version.in 166814 1668152021-09-30 Sergio Durigan Junior <sergiodj@sergiodj.net> 166816 166817 [PR gdb/28369] Use get_shell on gdb/ser-pipe.c 166818 PR gdb/28369 reports that gdb/ser-pipe.c has an 'execl' function call 166819 with a hard-coded "/bin/sh" as its argument. We've had 'get_shell' 166820 for a while now, which is conscious about the SHELL environment and a 166821 better alternative to always calling "/bin/sh". 166822 166823 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28369 166824 1668252021-09-30 Tom de Vries <tdevries@suse.de> 166826 166827 [gdb/testsuite] Add untested for missing xml support in gdb.base/valgrind*.exp 166828 Add untested in case missing xml support is detected in test-cases 166829 gdb.base/valgrind*.exp. 166830 166831 Tested on x86_64-linux. 166832 1668332021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166834 166835 arm: enable Cortex-R52+ CPU 166836 Patch is adding Cortex-R52+ as 'cortex-r52plus' command line 166837 flag for -mcpu option. 166838 166839 bfd/ 166840 166841 * cpu-arm.c: New Cortex-R52+ CPU. 166842 166843 gas/ 166844 166845 * NEWS: Update docs. 166846 * config/tc-arm.c: New Cortex-R52+ CPU. 166847 * doc/c-arm.texi: Update docs. 166848 * testsuite/gas/arm/cpu-cortex-r52plus.d: New test. 166849 1668502021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166851 166852 aarch64: Enable Cortex-X2 CPU 166853 This patch is adding support for Cortex-X2 CPU. 166854 166855 gas: 166856 166857 * NEWS: Update docs. 166858 * config/tc-aarch64.c: Add Cortex-X2. 166859 * doc/c-aarch64.texi: Update docs. 166860 1668612021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166862 166863 aarch64: Enable Cortex-A710 CPU 166864 This patch is adding support for Cortex-A710 CPU. 166865 166866 gas/ 166867 166868 * NEWS: Update docs. 166869 * config/tc-aarch64.c: Add Cortex-A710. 166870 * doc/c-aarch64.texi: Update docs. 166871 1668722021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166873 166874 aarch64: Enable Cortex-A510 CPU 166875 This patch is adding support for Cortex-A510 CPU. 166876 166877 gas/ 166878 166879 * NEWS: Update docs. 166880 * config/tc-aarch64.c: Add Cortex-A510. 166881 * doc/c-aarch64.texi: Update docs. 166882 1668832021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166884 166885 aarch64: Update AArch64 features command line options docs 2/2 166886 Patch is only sorting by 'Extension` column 'Architecture Extension' 166887 table. 166888 166889 gas/ 166890 166891 * doc/c-aarch64.texi: Update docs. 166892 1668932021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166894 166895 aarch64: Update AArch64 features command line options docs 1/2 166896 Patch is improving entries in "Architecture extensions" table in GAS 166897 documentation. 166898 166899 gas/ 166900 166901 * doc/c-aarch64.texi: Update docs. 166902 1669032021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com> 166904 166905 aarch64: add armv9-a architecture to -march 166906 Patch is adding new 'armv9-a` command line flag to -march for AArch64. 166907 166908 gas/ 166909 166910 * config/tc-aarch64.c: Add 'armv9-a' command line flag. 166911 * docs/c-aarch64.text: Update docs. 166912 * NEWS: Update docs. 166913 166914 include/ 166915 166916 * opcode/aarch64.h (AARCH64_FEATURE_V9): New define. 166917 (AARCH64_ARCH_V9): New define. 166918 1669192021-09-30 Simon Marchi <simon.marchi@polymtl.ca> 166920 166921 gdb/testsuite: make runto_main not pass no-message to runto 166922 As follow-up to this discussion: 166923 166924 https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html 166925 166926 ... make runto_main not pass no-message to runto. This means that if we 166927 fail to run to main, for some reason, we'll emit a FAIL. This is the 166928 behavior we want the majority of (if not all) the time. 166929 166930 Without this, we rely on tests logging a failure if runto_main fails, 166931 otherwise. They do so in a very inconsisteny mannet, sometimes using 166932 "fail", "unsupported" or "untested". The messages also vary widly. 166933 This patch removes all these messages as well. 166934 166935 Also, remove a few "fail" where we call runto (and not runto_main). by 166936 default (without an explicit no-message argument), runto prints a 166937 failure already. In two places, gdb.multi/multi-re-run.exp and 166938 gdb.python/py-pp-registration.exp, remove "message" passed to runto. 166939 This removes a few PASSes that we don't care about (but FAILs will still 166940 be printed if we fail to run to where we want to). This aligns their 166941 behavior with the rest of the testsuite. 166942 166943 Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023 166944 1669452021-09-30 Simon Marchi <simon.marchi@polymtl.ca> 166946 166947 gdbsupport: make gdb_mkostemp_cloexec return a scoped_fd 166948 This encourages the callers to use automatic file descriptor management. 166949 166950 Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344 166951 1669522021-09-30 Simon Marchi <simon.marchi@polymtl.ca> 166953 166954 gdbsupport: make gdb_open_cloexec return scoped_fd 166955 Make gdb_open_cloexec return a scoped_fd, to encourage using automatic 166956 management of the file descriptor closing. Except in the most trivial 166957 cases, I changed the callers to just release the fd, which retains their 166958 existing behavior. That will allow the transition to using scoped_fd 166959 more to go gradually, one caller at a time. 166960 166961 Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554 166962 1669632021-09-30 Simon Marchi <simon.marchi@polymtl.ca> 166964 166965 gdbsupport: move gdb_file_up to its own file 166966 The following patches wants to change gdb_fopen_cloexec and 166967 gdb_mkostemp_cloexec to return a scoped_fd. Doing this causes a cyclic 166968 include between scoped_fd.h and filestuff.h, that both want to include 166969 each other. scoped_fd.h includes filestuff.h because of the 166970 scoped_fd::to_file method's return value. filestuff.h would then 166971 include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's 166972 return values. 166973 166974 To fix that, move gdb_file_up to its own file, gdb_file.h. 166975 166976 Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d 166977 1669782021-09-30 Dimitar Dimitrov <dimitar@dinux.eu> 166979 166980 ld: pru: Fix resource_table output section alignment 166981 My commit 261980de18b added alignment for the resource table symbol. 166982 But it is wrong. The Linux remoteproc driver loads and interprets the 166983 contents of the .resource_table ELF section, not of a table symbol. 166984 166985 Without this patch, if the linker happens to output padding for symbol 166986 alignment, then the resource table contents as viewed by the kernel 166987 loader would "shift" and look corrupted. 166988 166989 ld/ChangeLog: 166990 166991 * scripttempl/pru.sc (.resource_table): Align the output 166992 section, not the first symbol. 166993 1669942021-09-30 Tom Tromey <tromey@adacore.com> 166995 166996 Fix Windows crash from stop_pc change 166997 The "make thread_suspend_state::stop_pc optional" patch caused a 166998 regression on Windows when using shared libraries. I tracked this 166999 down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED 167000 case of handle_inferior_event. This patch fixes the bug by ensuring 167001 that the stop PC is set at this point. 167002 1670032021-09-30 Tom de Vries <tdevries@suse.de> 167004 167005 [gdb/testsuite] Use untested in gdb.debuginfod/fetch_src_and_symbols.exp 167006 With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target 167007 board unix/-bad, I get: 167008 ... 167009 gcc: error: unrecognized command line option '-bad'^M 167010 compiler exited with status 1 167011 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167012 FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile 167013 ... 167014 167015 Replace the FAIL with the usual: 167016 ... 167017 UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile 167018 ... 167019 167020 Tested on x86_64-linux. 167021 1670222021-09-30 Tom de Vries <tdevries@suse.de> 167023 167024 [gdb/testsuite] Remove redundant FAIL in gdb.base/info-os.exp 167025 When running test-case gdb.base/info-os.exp with target board unix/-bad, I run 167026 into: 167027 ... 167028 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167029 UNTESTED: gdb.base/info-os.exp: failed to prepare 167030 FAIL: gdb.base/info-os.exp: cannot compile test program 167031 ... 167032 167033 Remove the redundant FAIL. 167034 167035 Tested on x86_64-linux. 167036 1670372021-09-30 Tom de Vries <tdevries@suse.de> 167038 167039 [gdb/testsuite] Fix DUPLICATE in gdb.base/info-os.exp 167040 When running test-case gdb.base/info-os.exp, I run into: 167041 ... 167042 PASS: gdb.base/info-os.exp: get threads 167043 PASS: gdb.base/info-os.exp: get threads 167044 DUPLICATE: gdb.base/info-os.exp: get threads 167045 ... 167046 167047 Fix this not doing pass followed by exp_continue in gdb_test_multiple. 167048 167049 Tested on x86_64-linux. 167050 1670512021-09-30 Tom de Vries <tdevries@suse.de> 167052 167053 [gdb/testsuite] Check compilation result in gdb.dwarf2/dw2-opt-structptr.exp 167054 When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board 167055 unix/-bad, I get: 167056 ... 167057 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167058 UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp 167059 UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile 167060 ERROR: (dw2-opt-structptr) No such file or directory 167061 UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on 167062 ... 167063 167064 Merge the two UNTESTEDs. 167065 167066 Fix the UNRESOLVED by checking result of compilation. 167067 167068 Tested on x86_64-linux. 167069 1670702021-09-30 Tom de Vries <tdevries@suse.de> 167071 167072 [gdb/testsuite] Check compilation result in gdb.base/structs.exp 167073 When running test-case gdb.base/structs.exp with target board unix/-bad, I 167074 get: 167075 ... 167076 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167077 UNTESTED: gdb.base/structs.exp: failed to prepare 167078 ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp. 167079 ERROR: can't read "use_gdb_stub": no such variable 167080 ... 167081 167082 Fix this by checking the compilation result. 167083 167084 Fix the resulting DUPLICATEs using with_test_prefix. 167085 167086 Tested on x86_64-linux. 167087 1670882021-09-30 Tom de Vries <tdevries@suse.de> 167089 167090 [gdb/testsuite] Prepare nodebug exec in gdb.base/cvexpr.exp 167091 When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get: 167092 ... 167093 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167094 ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp. 167095 ERROR: can't read "use_gdb_stub": no such variable 167096 ... 167097 167098 This is triggered in a part of the test that claims to require no debug 167099 information, but uses the exec containing either dwarf or ctf. 167100 167101 Fix this by preparing another executable compiled with nodebug, and using 167102 that one instead. 167103 167104 Also use with_test_prefix to mark the nodebug part, such that we have: 167105 ... 167106 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167107 UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare 167108 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167109 UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare 167110 ... 167111 167112 Tested on x86_64-linux. 167113 1671142021-09-30 Tom de Vries <tdevries@suse.de> 167115 167116 [gdb/testsuite] Fix DUPLICATE in gdb.base/cvexpr.exp 167117 Fix: 167118 ... 167119 DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict 167120 ... 167121 using with_test_prefix. 167122 167123 Tested on x86_64-linux. 167124 1671252021-09-30 Tom de Vries <tdevries@suse.de> 167126 167127 [gdb/testsuite] Check compilation result in gdb.base/call-sc.exp 167128 When running test-case gdb.base/call-sc.exp with target board unix/-bad, I 167129 get: 167130 ... 167131 gdb compile failed, gcc: error: unrecognized command line option '-bad' 167132 UNTESTED: gdb.base/call-sc.exp: failed to prepare 167133 ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp. 167134 ERROR: can't read "use_gdb_stub": no such variable 167135 ... 167136 167137 Fix this by checking the compilation result. 167138 167139 Fix the resulting DUPLICATE: 167140 ... 167141 DUPLICATE: gdb.base/call-sc.exp: failed to prepare 167142 ... 167143 using with_test_prefix. 167144 167145 Tested on x86_64-linux. 167146 1671472021-09-30 Tom de Vries <tdevries@suse.de> 167148 167149 [gdb/testsuite] Fix untested messages in gdb.mi/*.exp 167150 The effect of: 167151 ... 167152 untested "y.exp" 167153 ... 167154 in a gdb.x/y.exp is: 167155 ... 167156 UNTESTED: gdb.x/y.exp: y.exp 167157 ... 167158 which is a bit pointless. 167159 167160 Replace these untested messages in gdb.mi/*.exp with the usual "failed to 167161 compile". 167162 167163 Likewise for an: 167164 ... 167165 untested $testname 167166 ... 167167 where the variable is undefined. 167168 167169 Tested on x86_64-linux. 167170 1671712021-09-30 Nick Clifton <nickc@redhat.com> 167172 167173 make objcopy fail if it is asked to redefine symbols in an object file containing LTO information. 167174 * objcopy.c (filter_symbols): Fail if attempting to dredefine 167175 symbols in an LTO object file. 167176 1671772021-09-30 Tom de Vries <tdevries@suse.de> 167178 167179 [gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp 167180 On ubuntu 18.04.5, I run into: 167181 ... 167182 (gdb) mt print objfiles dwindex^M 167183 ^M 167184 Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex: \ 167185 Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M 167186 ^M 167187 Psymtabs:^M 167188 vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M 167189 ... 167190 library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M 167191 ERROR: internal buffer is full. 167192 UNRESOLVED: gdb.rust/dwindex.exp: check if index present 167193 ... 167194 167195 Fix this by using -lbl in proc ensure_gdb_index. 167196 167197 Tested on x86_64-linux. 167198 1671992021-09-30 Libor Bukata <libor.bukata@oracle.com> 167200 167201 Add Solaris specific ELF note processing 167202 Add elfcore_grok_solaris_note function that enables to 167203 obtain process status, register values, and program info 167204 from Solaris's core files. 167205 167206 bfd/ 167207 * elf.c (elfcore_grok_solaris_note): Solaris specific ELF 167208 note parser. Better GDB's coredump analysis on Solaris... 167209 (elfcore_grok_solaris_note_impl): New function. 167210 (elfcore_grok_solaris_prstatus): New function. 167211 (elfcore_grok_solaris_info): New function. 167212 (elfcore_grok_solaris_lwpstatus): New function. 167213 (elf_parse_notes): Added "CORE" groker element. 167214 include/ 167215 * elf/common.h: Add note segment constants for core files on 167216 Solaris systems. 167217 1672182021-09-30 Frederic Cambus <fred@statdns.com> 167219 167220 Add support to readelf for reading OpenBSD ELF core notes. 167221 * readelf.c (get_openbsd_elfcore_note_type): New function. 167222 (process_note): Add support for OpenBSD core notes. 167223 1672242021-09-30 GDB Administrator <gdbadmin@sourceware.org> 167225 167226 Automatic date update in version.in 167227 1672282021-09-29 Tom de Vries <tdevries@suse.de> 167229 167230 [gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug 167231 When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get: 167232 ... 167233 (gdb) info addr dl_main^M 167234 Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M 167235 (gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main 167236 ... 167237 while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\." 167238 167239 Fix this by also accepting this variant. 167240 167241 Tested on x86_64-linux. 167242 1672432021-09-29 H.J. Lu <hjl.tools@gmail.com> 167244 167245 Add a testcase for PR binutils/27202 167246 PR binutils/27202 167247 * testsuite/gas/elf/dwarf-5-loc0.d: New file. 167248 * testsuite/gas/elf/dwarf-5-loc0.s: Likewise. 167249 * testsuite/gas/elf/elf.exp: Run dwarf-5-loc0. 167250 1672512021-09-29 Pedro Alves <pedro@palves.net> 167252 167253 Fix gdb.multi/multi-term-settings.exp race 167254 The gdb.multi/multi-term-settings.exp testcase sometimes fails like so: 167255 167256 Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ... 167257 FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) 167258 167259 It's easier to reproduce if you stress the machine at the same time, like e.g.: 167260 167261 $ stress -c 24 167262 167263 Looking at gdb.log, we see: 167264 167265 (gdb) attach 60422 167266 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422 167267 [New Thread 60422.60422] 167268 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... 167269 Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so... 167270 Reading symbols from /lib64/ld-linux-x86-64.so.2... 167271 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 167272 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 167273 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory. 167274 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach 167275 set schedule-multiple on 167276 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on 167277 info inferiors 167278 Num Description Connection Executable 167279 1 process 60404 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings 167280 * 2 process 60422 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings 167281 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors 167282 pid=60422, count=46 167283 pid=60422, count=47 167284 pid=60422, count=48 167285 pid=60422, count=49 167286 pid=60422, count=50 167287 pid=60422, count=51 167288 pid=60422, count=52 167289 pid=60422, count=53 167290 pid=60422, count=54 167291 pid=60422, count=55 167292 pid=60422, count=56 167293 pid=60422, count=57 167294 pid=60422, count=58 167295 pid=60422, count=59 167296 pid=60422, count=60 167297 pid=60422, count=61 167298 pid=60422, count=62 167299 pid=60422, count=63 167300 pid=60422, count=64 167301 pid=60422, count=65 167302 pid=60422, count=66 167303 pid=60422, count=67 167304 pid=60422, count=68 167305 pid=60422, count=69 167306 pid=60404, count=54 167307 pid=60404, count=55 167308 pid=60404, count=56 167309 pid=60404, count=57 167310 pid=60404, count=58 167311 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue 167312 Quit 167313 (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) 167314 167315 If you look at the testcase's sources, you'll see that the intention 167316 is to resumes the program with "continue", wait to see a few of those 167317 "pid=..., count=..." lines, and then interrupt the program with 167318 Ctrl-C. But somehow, that resulted in GDB printing "Quit", instead of 167319 the Ctrl-C stopping the program with SIGINT. 167320 167321 Here's what is happening: 167322 167323 #1 - those "pid=..., count=..." lines we see above weren't actually 167324 output by the inferior after it has been continued (see #1). 167325 Note that "inf1_how" and "inf2_how" are "attach". What happened 167326 is that those "pid=..., count=..." lines were output by the 167327 inferiors _before_ they were attached to. We see them at that 167328 point instead of earlier, because that's where the testcase 167329 reads from the inferiors' spawn_ids. 167330 167331 #2 - The testcase mistakenly thinks those "pid=..., count=..." lines 167332 happened after the continue was processed by GDB, meaning it has 167333 waited enough, and so sends the Ctrl-C. GDB hasn't yet passed 167334 the terminal to the inferior, so the Ctrl-C results in that 167335 Quit. 167336 167337 The fix here is twofold: 167338 167339 #1 - flush inferior output right after attaching 167340 167341 #2 - consume the "Continuing" printed by "continue", indicating the 167342 inferior has the terminal. This is the same as done throughout 167343 the testsuite to handle this exact problem of sending Ctrl-C too 167344 soon. 167345 167346 gdb/testsuite/ChangeLog: 167347 yyyy-mm-dd Pedro Alves <pedro@palves.net <mailto:pedro@palves.net>> 167348 167349 * gdb.multi/multi-term-settings.exp (create_inferior): Flush 167350 inferior output. 167351 (coretest): Use $gdb_test_name. After issuing "continue", wait 167352 for "Continuing". 167353 167354 Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9 167355 1673562021-09-29 Tom de Vries <tdevries@suse.de> 167357 167358 [gdb/testsuite] Disable vgdb tests if xml not supported 167359 I build gdb without xml support using --without-expat, and ran into: 167360 ... 167361 (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M 167362 Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M 167363 relaying data between gdb and process 22032^M 167364 warning: Can not parse XML target description; XML support was disabled at \ 167365 compile time^M 167366 ... 167367 (gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1 167368 p gdb_test_infcall ()^M 167369 Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M 167370 (gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall () 167371 ... 167372 167373 After googling the error message with context valgrind gdbserver, I found 167374 indications that the Remote 'g' packet reply error is due to missing xml 167375 support. 167376 167377 And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I 167378 found: 167379 ... 167380 GDB version needed for ARM and PPC32/64. 167381 167382 You must use a GDB version which is able to read XML target description sent 167383 by a gdbserver. This is the standard setup if GDB was configured and built 167384 with the "expat" library. If your GDB was not configured with XML support, it 167385 will report an error message when using the "target" command. Debugging will 167386 not work because GDB will then not be able to fetch the registers from the 167387 Valgrind gdbserver. 167388 ... 167389 167390 So I guess I'm running into the same problem for x86_64. 167391 167392 Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not 167393 available. Although only the gdb.base/valgrind-infcall*.exp produce fails, 167394 the Remote 'g' packet reply error occurs in all tests, so it seems prudent to 167395 disable them all. 167396 167397 Tested on x86_64-linux. 167398 1673992021-09-29 Tom de Vries <tdevries@suse.de> 167400 167401 [gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2 167402 With a gdb build using python 2.7, I run into: 167403 ... 167404 (gdb) python \ 167405 gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M 167406 File "<string>", line 1^M 167407 gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M 167408 ^^M 167409 SyntaxError: invalid syntax^M 167410 Error while executing Python code.^M 167411 (gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \ 167412 trap breakpoint_modified event 167413 ... 167414 167415 This is caused by the following: 167416 - a lambda function body needs to be an expression 167417 - in python 2, print is a statement, while in python 3 it's a function 167418 - a function call is an expression, and a statement is not. 167419 167420 Fix this by defining a function print_bp_enabled: 167421 ... 167422 def print_bp_enabled (bp): 167423 print (bp.enabled) 167424 end 167425 ... 167426 and using that instead. 167427 167428 Tested on x86_64-linux. 167429 1674302021-09-29 Tom de Vries <tdevries@suse.de> 167431 167432 [gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp 167433 With a gdb configured to be somewhat minimal, while still supporting python: 167434 ... 167435 $ gdb --configuration 167436 This GDB was configured as follows: 167437 configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu 167438 --with-auto-load-dir=$debugdir:$datadir/auto-load 167439 --with-auto-load-safe-path=$debugdir:$datadir/auto-load 167440 --without-expat 167441 --with-gdb-datadir=$install/share/gdb (relocatable) 167442 --with-jit-reader-dir=$install/lib64/gdb (relocatable) 167443 --without-libunwind-ia64 167444 --without-lzma 167445 --without-babeltrace 167446 --without-intel-pt 167447 --with-mpfr 167448 --without-xxhash 167449 --with-python=/usr 167450 --with-python-libdir=/usr/lib 167451 --with-debuginfod 167452 --without-guile 167453 --disable-source-highlight 167454 --with-separate-debug-dir=/usr/lib/debug 167455 --with-system-gdbinit=$devel/system-gdbinit 167456 ... 167457 and using gcc 4.8 to build gdb (causing std::thread not to be used due to 167458 PR28318) I ran into: 167459 ... 167460 (gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb 167461 print 1^M 167462 ^M 167463 Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M 167464 1174 scoped_value_mark free_values;^M 167465 (xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout) 167466 ... 167467 167468 The problem is that the regexp expects "hit Breakpoint $decimal". The "hit" 167469 part is missing. 167470 167471 The "hit" is printed by maybe_print_thread_hit_breakpoint, when 167472 show_thread_that_caused_stop returns true: 167473 ... 167474 int 167475 show_thread_that_caused_stop (void) 167476 { 167477 return highest_thread_num > 1; 167478 } 167479 ... 167480 Apparently, that's not the case. 167481 167482 Fix this by removing "hit" from the regexp, making the regexp more similar to 167483 what is used in say, continue_to_breakpoint. 167484 167485 Tested on x86_64-linux. 167486 1674872021-09-29 Andrew Burgess <andrew.burgess@embecosm.com> 167488 167489 gdb: fix build when libbacktrace and execinfo backtrace are not available 167490 In this commit: 167491 167492 commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0 167493 Date: Wed Aug 11 13:24:33 2021 +0100 167494 167495 gdb: use libbacktrace to create a better backtrace for fatal signals 167496 167497 The build of GDB was broken iff, the execinfo backtrace API is not 167498 available, and, libbacktrace is either disabled, or not usable. In 167499 this case you'll see build errors like this: 167500 167501 CXX bt-utils.o 167502 /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()': 167503 /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope 167504 gdb_internal_backtrace_1 (); 167505 ^~~~~~~~~~~~~~~~~~~~~~~~ 167506 167507 This commit fixes the issue by guarding the call to 167508 gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE', 167509 which is only defined when one of the backtrace libraries are 167510 available. 167511 1675122021-09-29 Andrew Burgess <andrew.burgess@embecosm.com> 167513 167514 gdb/doc: use 'standard error stream' instead of 'stderr' in some places 167515 With this commit: 167516 167517 commit 91f2597bd24d171c1337a4629f8237aa47c59082 167518 Date: Thu Aug 12 18:24:59 2021 +0100 167519 167520 gdb: print backtrace for internal error/warning 167521 167522 I included some references to 'stderr', which, it was pointed out, 167523 would be better written as 'standard error stream'. See: 167524 167525 https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html 167526 167527 This commit replaces the two instances of 'stderr' that I introduced. 167528 1675292021-09-29 Andrew Burgess <andrew.burgess@embecosm.com> 167530 167531 gdb: fix manor -> manner typo in some comments 167532 In a recent commit I used 'manor' in some comments rather than 167533 'manner'. This commit fixes those two mistakes. 167534 167535 I also looked through the gdb/ tree and found one additional instance 167536 of this mistake that this commit also fixes. 167537 1675382021-09-29 Alan Modra <amodra@gmail.com> 167539 167540 PR27202, readelf -wL doesn't work on ".loc 0" 167541 For DWARF revision 4 and earlier, display_debug_lines_decoded 167542 populates the file_table array with entries read from .debug_line 167543 after the directory table. file_table[0] contains the first entry. 167544 DWARF rev 4 line number programs index this entry as file number one. 167545 DWARF revision 5 changes .debug_line format quite extensively, and in 167546 particular gives file number zero a meaning. 167547 167548 PR 27202 167549 * dwarf.c (display_debug_lines_decoded): Correct indexing used 167550 for DWARF5 files. 167551 1675522021-09-29 Simon Marchi <simon.marchi@polymtl.ca> 167553 167554 gdb: enable target_async around stop_all_threads call in process_initial_stop_replies 167555 The following scenario hangs: 167556 167557 - maint set target-non-stop on 167558 - `gdbserver --attach` 167559 - a multi-threaded program 167560 167561 For example: 167562 167563 Terminal 1: 167564 167565 $ gnome-calculator& 167566 [1] 495731 167567 $ ../gdbserver/gdbserver --once --attach :1234 495731 167568 Attached; pid = 495731 167569 Listening on port 1234 167570 167571 Terminal 2: 167572 167573 $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234" 167574 Reading symbols from /usr/bin/gnome-calculator... 167575 (No debugging symbols found in /usr/bin/gnome-calculator) 167576 Remote debugging using :1234 167577 * hangs * 167578 167579 What happens is: 167580 167581 - The protocol between gdb and gdbserver is in non-stop mode, but the 167582 user-visible behavior is all-stop 167583 - On connect, gdbserver sends one stop reply for one thread that is 167584 stops, the others stay running 167585 - In process_initial_stop_replies, gdb calls stop_all_threads to stop 167586 these other threads, because we are using the all-stop user-visible 167587 mode 167588 - stop_all_threads sends a stop request for all the running threads and 167589 then waits for resulting events 167590 - At this point, the remote target is in target_async(0) mode, which 167591 makes stop_all_threads not consider it for events 167592 - stop_all_threads loops indefinitely (it does not even block 167593 indefinitely, it is in an infinite busy loop) because there are no 167594 event sources. wait_one_event returns a TARGET_WAITKIND_NO_RESUMED 167595 wait status. 167596 167597 Fix that by making the remote target async around the stop_all_threads 167598 call. 167599 167600 I haven't implemented it because I'm not sure how to do it, but I think 167601 it would be a good idea to have, in stop_all_threads / wait_one / 167602 handle_one, an assert to check that if we are expecting one or more 167603 event, then there are some targets that are in a state where they can 167604 supply some events. Otherwise, we'll necessarily be stuck in this 167605 infinite loop, and it's probably due to a bug in GDB. I'm not too sure 167606 where to put this or how to express it though. Perhaps in 167607 stop_all_threads, here: 167608 167609 for (int i = 0; i < waits_needed; i++) 167610 { 167611 wait_one_event event = wait_one (); 167612 *here* 167613 if (handle_one (event)) 167614 break; 167615 } 167616 167617 If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED, 167618 there's a problem. We expect some event, because we've asked some 167619 threads to stop, but all targets are answering that they won't have any 167620 events for us. That's a contradiction, and a sign that something has 167621 gone wrong. It could perhaps event be: 167622 167623 gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED); 167624 167625 in handle_one, as the idea is the same in prepare_for_detach. 167626 167627 A bit more sophisticated would be: we know which targets we are 167628 expecting waits from, since we know which threads we have asked to 167629 stop. So if any of these targets returns TARGET_WAITKIND_NO_RESUMED, 167630 something is fishy. 167631 167632 Add a test that tests attaching with gdbserver's --attach flag to a 167633 multi-threaded program, and then connecting to it. Without the fix, the 167634 test reproduces the hang. 167635 167636 Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f 167637 1676382021-09-29 GDB Administrator <gdbadmin@sourceware.org> 167639 167640 Automatic date update in version.in 167641 1676422021-09-29 Simon Marchi <simon.marchi@polymtl.ca> 167643 167644 gdb: fix darwin-nat build (again) 167645 I made a mistake in the previous patch. Adjust the format string to 167646 match the arguments. 167647 167648 Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba 167649 1676502021-09-29 Simon Marchi <simon.marchi@polymtl.ca> 167651 167652 gdb: fix darwin-nat build 167653 There are two errors of this kind: 167654 167655 CXX darwin-nat.o 167656 /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat] 167657 ptid.pid (), ptid.tid ()); 167658 ^~~~~~~~~~~ 167659 167660 Fix them by using ptid_t's to_string method. 167661 167662 Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7 167663 1676642021-09-29 Simon Marchi <simon.marchi@polymtl.ca> 167665 167666 gdb.base/foll-fork.exp: accept "info breakpoints" output in any order 167667 The test currently requires the "inf 1" breakpoint to be before the "inf 167668 2" breakpoint. This is not always the case: 167669 167670 info breakpoints 2 167671 Num Type Disp Enb Address What 167672 2 breakpoint keep y <MULTIPLE> 167673 2.1 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2 167674 2.2 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1 167675 (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints 167676 167677 Since add_location_to_breakpoint uses only the address as a criterion to 167678 sort locations, the order of locations at the same address is not 167679 stable: it will depend on the insertion order. Here, the insertion 167680 order comes from the order of SALs when creating the breakpoint, which 167681 can vary from machine to machine. While it would be more user-friendly 167682 to have a more stable order for printed breakpoint locations, it doesn't 167683 really matter for this test, and it would be hard to define an order 167684 that will be the same everywhere, all the time. 167685 167686 So, loosen the regexp to accept "inf 1" and "inf 2" in any order. 167687 167688 Co-Authored-By: Pedro Alves <pedro@palves.net> 167689 Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16 167690 1676912021-09-28 Cooper Qu <cooper.qu@linux.alibaba.com> 167692 167693 RISC-V: Fix wrong version number when arch contains 'p'. 167694 When specify a default version for p extension in 167695 riscv_supported_std_ext[](elfxx-riscv.c) and assembling with 167696 -march=rv32imacp, the c extension's version in attribute will become 167697 0p0, the expectation is 2p0. 167698 167699 TODO: Remember to add testcase when we have supported standrad p in 167700 the future. 167701 167702 bfd/ 167703 PR gas/28372 167704 * elfxx-riscv.c (riscv_parsing_subset_version): Break if p 167705 represent the 'p' extension. 167706 167707 Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59 167708 1677092021-09-28 Nelson Chu <nelson.chu@sifive.com> 167710 167711 RISC-V: Allow to add numbers in the prefixed extension names. 167712 We need to allow adding numbers in the prefixed extension names, since 167713 the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec 167714 recently. But there are two restrictions as follows, 167715 167716 * The extension name ends with <number>p is invalid, since this may 167717 be confused with extension with <number>.0 version. We report errors 167718 for this case. 167719 167720 Invalid format: [z|h|s|zvm|x][0-9a-z]+[0-9]+p 167721 167722 * The extension name ends with numbers is valid, but the numbers will 167723 be parsed as major version, so try to avoid naming extensions like this. 167724 167725 bfd/ 167726 * elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from 167727 riscv_valid_prefixed_ext/ 167728 (riscv_parsing_subset_version): The extensions end with <number>p 167729 is forbidden, we already report the detailed errors in the 167730 riscv_parse_prefixed_ext, so clean the code and unused parameters. 167731 (riscv_parse_std_ext): Updated. 167732 (riscv_parse_prefixed_ext): Rewrite the parser to allow numbers 167733 in the prefixed extension names. 167734 gas/ 167735 * testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases. 167736 * testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise. 167737 * testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise. 167738 * testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise. 167739 * testsuite/gas/riscv/march-fail-invalid.l: Likewise. 167740 * testsuite/gas/riscv/march-fail-version-x.d: Removed. 167741 * testsuite/gas/riscv/march-fail-version-z.d: Likewise. 167742 * testsuite/gas/riscv/march-fail-version.l: Likewise. 167743 1677442021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167745 167746 gdb: print backtrace for internal error/warning 167747 This commit builds on previous work to allow GDB to print a backtrace 167748 of itself when GDB encounters an internal-error or internal-warning. 167749 This fixes PR gdb/26377. 167750 167751 There's not many places where we call internal_warning, and I guess in 167752 most cases the user would probably continue their debug session. And 167753 so, in order to avoid cluttering up the output, by default, printing 167754 of a backtrace is off for internal-warnings. 167755 167756 In contrast, printing of a backtrace is on by default for 167757 internal-errors, as I figure that in most cases hitting an 167758 internal-error is going to be the end of the debug session. 167759 167760 Whether a backtrace is printed or not can be controlled with the new 167761 settings: 167762 167763 maintenance set internal-error backtrace on|off 167764 maintenance show internal-error backtrace 167765 167766 maintenance set internal-warning backtrace on|off 167767 maintenance show internal-warning backtrace 167768 167769 Here is an example of what an internal-error now looks like with the 167770 backtrace included: 167771 167772 (gdb) maintenance internal-error blah 167773 ../../src.dev-3/gdb/maint.c:82: internal-error: blah 167774 A problem internal to GDB has been detected, 167775 further debugging may prove unreliable. 167776 ----- Backtrace ----- 167777 0x5c61ca gdb_internal_backtrace_1 167778 ../../src.dev-3/gdb/bt-utils.c:123 167779 0x5c626d _Z22gdb_internal_backtracev 167780 ../../src.dev-3/gdb/bt-utils.c:165 167781 0xe33237 internal_vproblem 167782 ../../src.dev-3/gdb/utils.c:393 167783 0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag 167784 ../../src.dev-3/gdb/utils.c:470 167785 0x1549652 _Z14internal_errorPKciS0_z 167786 ../../src.dev-3/gdbsupport/errors.cc:55 167787 0x9c7982 maintenance_internal_error 167788 ../../src.dev-3/gdb/maint.c:82 167789 0x636f57 do_simple_func 167790 ../../src.dev-3/gdb/cli/cli-decode.c:97 167791 .... snip, lots more backtrace lines .... 167792 --------------------- 167793 ../../src.dev-3/gdb/maint.c:82: internal-error: blah 167794 A problem internal to GDB has been detected, 167795 further debugging may prove unreliable. 167796 Quit this debugging session? (y or n) y 167797 167798 This is a bug, please report it. For instructions, see: 167799 <https://www.gnu.org/software/gdb/bugs/>. 167800 167801 ../../src.dev-3/gdb/maint.c:82: internal-error: blah 167802 A problem internal to GDB has been detected, 167803 further debugging may prove unreliable. 167804 Create a core file of GDB? (y or n) n 167805 167806 My hope is that this backtrace might make it slightly easier to 167807 diagnose GDB issues if all that is provided is the console output, I 167808 find that we frequently get reports of an assert being hit that is 167809 located in pretty generic code (frame.c, value.c, etc) and it is not 167810 always obvious how we might have arrived at the assert. 167811 167812 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377 167813 1678142021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167815 167816 gdb: use libbacktrace to create a better backtrace for fatal signals 167817 GDB recently gained the ability to print a backtrace when a fatal 167818 signal is encountered. This backtrace is produced using the backtrace 167819 and backtrace_symbols_fd API available in glibc. 167820 167821 However, in order for this API to actually map addresses to symbol 167822 names it is required that the application (GDB) be compiled with 167823 -rdynamic, which GDB is not by default. 167824 167825 As a result, the backtrace produced often looks like this: 167826 167827 Fatal signal: Bus error 167828 ----- Backtrace ----- 167829 ./gdb/gdb[0x80ec00] 167830 ./gdb/gdb[0x80ed56] 167831 /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0] 167832 /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f] 167833 ./gdb/gdb[0x15495ba] 167834 ./gdb/gdb[0x15489b8] 167835 ./gdb/gdb[0x9b794d] 167836 ./gdb/gdb[0x9b7a6d] 167837 ./gdb/gdb[0x9b943b] 167838 ./gdb/gdb[0x9b94a1] 167839 ./gdb/gdb[0x4175dd] 167840 /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3] 167841 ./gdb/gdb[0x4174de] 167842 --------------------- 167843 167844 This is OK if you have access to the exact same build of GDB, you can 167845 manually map the addresses back to symbols, however, it is next to 167846 useless if all you have is a backtrace copied into a bug report. 167847 167848 GCC uses libbacktrace for printing a backtrace when it encounters an 167849 error. In recent commits I added this library into the binutils-gdb 167850 repository, and in this commit I allow this library to be used by 167851 GDB. Now (when GDB is compiled with debug information) the backtrace 167852 looks like this: 167853 167854 ----- Backtrace ----- 167855 0x80ee08 gdb_internal_backtrace 167856 ../../src/gdb/event-top.c:989 167857 0x80ef0b handle_fatal_signal 167858 ../../src/gdb/event-top.c:1036 167859 0x7f24539dd6af ??? 167860 0x7f2453a97a5f ??? 167861 0x154976f gdb_wait_for_event 167862 ../../src/gdbsupport/event-loop.cc:613 167863 0x1548b6d _Z16gdb_do_one_eventv 167864 ../../src/gdbsupport/event-loop.cc:237 167865 0x9b7b02 start_event_loop 167866 ../../src/gdb/main.c:421 167867 0x9b7c22 captured_command_loop 167868 ../../src/gdb/main.c:481 167869 0x9b95f0 captured_main 167870 ../../src/gdb/main.c:1353 167871 0x9b9656 _Z8gdb_mainP18captured_main_args 167872 ../../src/gdb/main.c:1368 167873 0x4175ec main 167874 ../../src/gdb/gdb.c:32 167875 --------------------- 167876 167877 Which seems much more useful. 167878 167879 Use of libbacktrace is optional. If GDB is configured with 167880 --disable-libbacktrace then the libbacktrace directory will not be 167881 built, and GDB will not try to use this library. In this case GDB 167882 would try to use the old backtrace and backtrace_symbols_fd API. 167883 167884 All of the functions related to writing the backtrace of GDB itself 167885 have been moved into the new files gdb/by-utils.{c,h}. 167886 1678872021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167888 167889 src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS 167890 After the previous commit that imported libbacktrace from gcc, this 167891 commit updates src-release.sh so that the libbacktrace directory is 167892 included in the gdb release tar file. 167893 167894 ChangeLog: 167895 167896 * src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace. 167897 1678982021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167899 167900 Copy in libbacktrace from gcc 167901 This copies in libbacktrace from the gcc repository as it was in the 167902 commit 62e420293a293608f383d9b9c7f2debd666e9fc9. GDB is going to 167903 start using this library soon. 167904 167905 A dependency between GDB and libbacktrace has already been added to 167906 the top level Makefile, so, after this commit, when building GDB, 167907 libbacktrace will be built first. However, libbacktrace is not yet 167908 linked into GDB, or used by GDB in any way. 167909 167910 It is possible to stop libbacktrace being built by configuring the 167911 tree with --disable-libbacktrace. 167912 167913 This commit does NOT update src-release.sh, that will be done in the 167914 next commit, this commit ONLY imports libbacktrace from gcc. This 167915 means that if you try to make a release of GDB from exactly this 167916 commit then the release tar file will not include libbacktrace. 167917 However, as libbacktrace is an optional dependency this is fine. 167918 1679192021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167920 167921 gdb: Add a dependency between gdb and libbacktrace 167922 GDB is going to start using libbacktrace, so add a build dependency. 167923 167924 ChangeLog: 167925 167926 * Makefile.def: Add all-gdb dependency on all-libbacktrace. 167927 * Makefile.in: Regenerate. 167928 1679292021-09-28 Andrew Burgess <andrew.burgess@embecosm.com> 167930 167931 top-level configure: setup target_configdirs based on repository 167932 The top-level configure script is shared between the gcc repository 167933 and the binutils-gdb repository. 167934 167935 The target_configdirs variable in the configure.ac script, defines 167936 sub-directories that contain components that should be built for the 167937 target using the target tools. 167938 167939 Some components, e.g. zlib, are built as both host and target 167940 libraries. 167941 167942 This causes problems for binutils-gdb. If we run 'make all' in the 167943 binutils-gdb repository we end up trying to build a target version of 167944 the zlib library, which requires the target compiler be available. 167945 Often the target compiler isn't immediately available, and so the 167946 build fails. 167947 167948 The problem with zlib impacted a previous attempt to synchronise the 167949 top-level configure scripts from gcc to binutils-gdb, see this thread: 167950 167951 https://sourceware.org/pipermail/binutils/2019-May/107094.html 167952 167953 And I'm in the process of importing libbacktrace in to binutils-gdb, 167954 which is also a host and target library, and triggers the same issues. 167955 167956 I believe that for binutils-gdb, at least at the moment, there are no 167957 target libraries that we need to build. 167958 167959 In the configure script we build three lists of things we want to 167960 build, $configdirs, $build_configdirs, and $target_configdirs, we also 167961 build two lists of things we don't want to build, $skipdirs and 167962 $noconfigdirs. We then remove anything that is in the lists of things 167963 not to build, from the list of things that should be built. 167964 167965 My proposal is to add everything in target_configdirs into skipdirs, 167966 if the source tree doesn't contain a gcc/ sub-directory. The result 167967 is that for binutils-gdb no target tools or libraries will be built, 167968 while for the gcc repository, nothing should change. 167969 167970 If a user builds a unified source tree, then the target tools and 167971 libraries should still be built as the gcc/ directory will be present. 167972 167973 I've tested a build of gcc on x86-64, and the same set of target 167974 libraries still seem to get built. On binutils-gdb this change 167975 resolves the issues with 'make all'. 167976 167977 ChangeLog: 167978 167979 * configure: Regenerate. 167980 * configure.ac (skipdirs): Add the contents of target_configdirs if 167981 we are not building gcc. 167982 1679832021-09-28 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> 167984 167985 PR28391, strip/objcopy --preserve-dates *.a: cannot set time 167986 After commit 985e0264516 copy_archive function began to pass invalid 167987 values to the utimensat(2) function when it tries to preserve 167988 timestamps in ar archives. This happens because the bfd_stat_arch_elt 167989 implementation for ar archives fills only the st_mtim.tv_sec part of 167990 the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part 167991 and the whole st_atim timespec untouched leaving them uninitialized 167992 167993 PR 28391 167994 * ar.c (extract_file): Clear buf for preserve_dates. 167995 * objcopy.c (copy_archive): Likewise. 167996 1679972021-09-28 Mike Frysinger <vapier@gentoo.org> 167998 167999 sim: drop weak func attrs on module inits 168000 When I first wrote this, I was thinking we'd scan all source files 168001 that existed and generate a complete init list. That means for any 168002 particular build, we'd probably have a few functions that didn't 168003 exist, so weak attributes was necessary. What I ended up scanning 168004 though was only the source files that went into a particular build. 168005 168006 There was another concern too: a source file might be included, but 168007 the build settings would cause all of its contents to be skipped 168008 (via CPP defines). So scanning via naive grep would pick up names 168009 not actually available. A check of the source tree shows that we 168010 never do this, and it's pretty easy to institute a policy that we 168011 don't start (by at the very least including a stub init func). 168012 168013 The use of weak symbols ends up causing a problem in practice: for 168014 a few modules (like profiling), nothing else pulls it in, so the 168015 linker omits it entirely, which leads to the profiling module never 168016 being available. So drop the weak markings since we know all these 168017 funcs will be available. 168018 1680192021-09-28 Cui,Lili <lili.cui@intel.com> 168020 168021 x86: Print {bad} on invalid broadcast in OP_E_memory 168022 Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast. 168023 168024 gas/ 168025 168026 PR binutils/28381 168027 * testsuite/gas/i386/bad-bcast.s: Add a new testcase. 168028 * testsuite/gas/i386/bad-bcast.d: Likewise. 168029 * testsuite/gas/i386/bad-bcast-intel.d: New. 168030 168031 opcodes/ 168032 168033 PR binutils/28381 168034 * i386-dis.c (static struct): Add no_broadcast. 168035 (OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it. 168036 (intel_operand_size): mark invalid broadcast with no_broadcast=1. 168037 (OP_XMM): Mark scalar_mode with no_broadcast=1. 168038 1680392021-09-28 Simon Marchi <simon.marchi@polymtl.ca> 168040 168041 gdb: use intrusive_list for linux-nat lwp_list 168042 Replace the manually maintained linked list of lwp_info objects with 168043 intrusive_list. Replace the ALL_LWPS macro with all_lwps, which returns 168044 a range. Add all_lwps_safe as well, for use in iterate_over_lwps, which 168045 currently iterates in a safe manner. 168046 168047 Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c 168048 1680492021-09-28 Simon Marchi <simon.marchi@polymtl.ca> 168050 168051 gdb: add destructor to lwp_info 168052 Replace the lwp_free function with a destructor. Make lwp_info 168053 non-copyable, since there is now a destructor (we wouldn't want an 168054 lwp_info object getting copied and this->arch_private getting deleted 168055 twice). 168056 168057 Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa 168058 1680592021-09-28 Simon Marchi <simon.marchi@polymtl.ca> 168060 168061 gdb: make lwp_info non-POD 168062 Initialize all fields in the class declaration directly. This opens the 168063 door to using intrusive_list, done in the following patch. 168064 168065 Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05 168066 1680672021-09-28 GDB Administrator <gdbadmin@sourceware.org> 168068 168069 Automatic date update in version.in 168070 1680712021-09-27 Simon Marchi <simon.marchi@efficios.com> 168072 168073 gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child" 168074 We found that when handling forks, two inferiors can unexpectedly share 168075 their program space and address space. To reproduce: 168076 168077 1. Using a test program that forks... 168078 2. "set follow-fork-mode child" 168079 3. "set detach-on-fork on" (the default) 168080 4. run to a breakpoint somewhere after the fork 168081 168082 Step 4 should have created a new inferior: 168083 168084 (gdb) info inferiors 168085 Num Description Connection Executable 168086 1 <null> /home/smarchi/build/wt/amd/gdb/fork 168087 * 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork 168088 168089 By inspecting the state of GDB, we can see that the two inferiors now 168090 share one program space and one address space: 168091 168092 Inferior 1: 168093 168094 (top-gdb) p inferior_list.m_front.num 168095 $2 = 1 168096 (top-gdb) p inferior_list.m_front.aspace 168097 $3 = (struct address_space *) 0x5595e2520400 168098 (top-gdb) p inferior_list.m_front.pspace 168099 $4 = (struct program_space *) 0x5595e2520440 168100 168101 Inferior 2: 168102 168103 (top-gdb) p inferior_list.m_front.next.num 168104 $5 = 2 168105 (top-gdb) p inferior_list.m_front.next.aspace 168106 $6 = (struct address_space *) 0x5595e2520400 168107 (top-gdb) p inferior_list.m_front.next.pspace 168108 $7 = (struct program_space *) 0x5595e2520440 168109 168110 You can then run inferior 1 again and the two inferiors will still 168111 erroneously share their spaces, but already at this point this is wrong. 168112 168113 The cause of the bad {a,p}space sharing is in follow_fork_inferior. 168114 When following the child and detaching from the parent, we just re-use 168115 the parent's spaces, rather than cloning them. When we switch back to 168116 inferior 1 and run again, we find ourselves with two unrelated inferiors 168117 sharing spaces. 168118 168119 Fix that by creating new spaces for the parent after having moved them 168120 to the child. My initial implementation created new spaces for the 168121 child instead. Doing this breaks doing "next" over fork(). When "next" 168122 start, we record the symtab of the starting location. When the program 168123 stops, we compare that symtab with the symtab the program has stopped 168124 at. If the symtab or the line number has changed, we conclude the 168125 "next" is done. If we create a new program space for the child and copy 168126 the parent's program space to it with clone_program_space, it creates 168127 new symtabs for the child as well. When the child stop, but still on 168128 the fork() line, GDB thinks the "next" is done because the symtab 168129 pointers no longer match. In reality they are two symtab instances that 168130 represent the same file. But moving the spaces to the child and 168131 creating new spaces for the parent, we avoid this problem. 168132 168133 Note that the problem described above happens today with "detach-on-fork 168134 off" and "follow-fork-mode child", because we create new spaces for the 168135 child. This will have to be addressed later. 168136 168137 Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is 168138 expected to have a location in each inferiors. Without the fix, when 168139 the two inferiors erroneously share a program space, GDB reports a 168140 single location. 168141 168142 Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e 168143 1681442021-09-27 Simon Marchi <simon.marchi@efficios.com> 168145 168146 gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixes 168147 No behavior change in the test expected, other than in the test names. 168148 168149 Change-Id: I111137483858ab0f23138439f2930009779a2b3d 168150 1681512021-09-27 Simon Marchi <simon.marchi@efficios.com> 168152 168153 gdb.base/foll-fork.exp: rename variables 168154 Rename the variables / parameters used to match the corresponding GDB 168155 setting name, I find that easier to follow. 168156 168157 Change-Id: Idcbddbbb369279fcf1e808b11a8c478f21b2a946 168158 1681592021-09-27 Simon Marchi <simon.marchi@efficios.com> 168160 168161 gdb.base/foll-fork.exp: refactor to restart GDB between each portion of the test 168162 This test is difficult to follow and modify because the state of GDB is 168163 preserved some tests. Add a setup proc, which starts a new GDB and runs 168164 to main, and use it in all test procs. Use proc_with_prefix to avoid 168165 duplicates. 168166 168167 The check_fork_catchpoints proc also seems used to check for follow-fork 168168 support by checking if catchpoints are supported. If they are not, it 168169 uses "return -code return", which makes its caller return. I find this 168170 unnecessary complex, versus just returning a boolean. Modify it to do 168171 so. 168172 168173 Change-Id: I23e62b204286c5e9c5c86d2727f7d33fb126ed08 168174 1681752021-09-27 Simon Marchi <simon.marchi@efficios.com> 168176 168177 gdb.base/foll-fork.exp: remove gating based on target triplet 168178 It looks like this test has some code to check at runtime the support of 168179 fork handling of the target (see check_fork_catchpoints). So, it seems 168180 to me that the check based on target triplet at the beginning of the 168181 test is not needed. This kind of gating is generally not desirable, 168182 because we wouldn't think of updating it when adding fork support to a 168183 target. For example, FreeBSD supports fork, but it wasn't listed here. 168184 168185 Change-Id: I6b55f2298edae6b37c3681fb8633d8ea1b5aabee 168186 1681872021-09-27 Simon Marchi <simon.marchi@efficios.com> 168188 168189 gdb.base/foll-fork.exp: remove DUPLICATEs 168190 Remove DUPLICATEs, and and at the same time replace two uses of 168191 gdb_test_multiple with gdb_test. I don't think using gdb_test_multiple 168192 is necessary here. 168193 168194 Change-Id: I8dcf097c3364e92d4f0e11f0c0f05dbb88e86742 168195 1681962021-09-27 Nick Alcock <nick.alcock@oracle.com> 168197 168198 libctf, lookup: fix bounds of pptrtab lookup 168199 An off-by-one bug in the check for pptrtab lookup meant that we could 168200 access the pptrtab past its bounds (*well* past its bounds), 168201 particularly if we called ctf_lookup_by_name in a child dict with "*foo" 168202 where "foo" is a type that exists in the parent but not the child and no 168203 previous lookups by name have been carried out. (Note that "*foo" is 168204 not even a valid thing to call ctf_lookup_by_name with: foo * is. 168205 Nonetheless, users sometimes do call ctf_lookup_by_name with invalid 168206 content, and it should return ECTF_NOTYPE, not crash.) 168207 168208 ctf_pptrtab_len, as its name suggests (and as other tests of it in 168209 ctf-lookup.c confirm), is one higher than the maximum valid permissible 168210 index, so the comparison is wrong. 168211 168212 (Test added, which should fail pretty reliably in the presence of this 168213 bug on any machine with 4KiB pages.) 168214 168215 libctf/ChangeLog 168216 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168217 168218 * ctf-lookup.c (ctf_lookup_by_name_internal): Fix pptrtab bounds. 168219 * testsuite/libctf-writable/pptrtab-writable-page-deep-lookup.*: 168220 New test. 168221 1682222021-09-27 Nick Alcock <nick.alcock@oracle.com> 168223 168224 libctf, testsuite: fix various warnings in tests 168225 These warnings are all off by default, but if they do fire you get 168226 spurious ERRORs when running make check-libctf. 168227 168228 libctf/ChangeLog 168229 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168230 168231 * testsuite/libctf-lookup/enum-symbol.c: Remove unused label. 168232 * testsuite/libctf-lookup/conflicting-type-syms.c: Remove unused 168233 variables. 168234 * testsuite/libctf-regression/pptrtab.c: Likewise. 168235 * testsuite/libctf-regression/type-add-unnamed-struct.c: Likewise. 168236 * testsuite/libctf-writable/pptrtab.c: Likewise. 168237 * testsuite/libctf-writable/reserialize-strtab-corruption.c: 168238 Likewise. 168239 * testsuite/libctf-regression/nonstatic-var-section-ld-r.c: Fix 168240 format string. 168241 * testsuite/libctf-regression/nonstatic-var-section-ld.c: 168242 Likewise. 168243 * testsuite/libctf-regression/nonstatic-var-section-ld.lk: Adjust. 168244 * testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Fix 168245 initializer. 168246 1682472021-09-27 Nick Alcock <nick.alcock@oracle.com> 168248 168249 libctf: fix handling of CTF symtypetab sections emitted by older GCC 168250 Older (pre-upstreaming) GCC emits a function symtypetab section of a 168251 format never read by any extant libctf. We can detect such CTF dicts by 168252 the lack of the CTF_F_NEWFUNCINFO flag in their header, and we do so 168253 when reading in the symtypetab section -- but if the set of symbols with 168254 types is sufficiently sparse, even an older GCC will emit a function 168255 index section. 168256 168257 In NEWFUNCINFO-capable compilers, this section will always be the exact 168258 same length as the corresponding function section (each is an array of 168259 uint32_t, associated 1:1 with each other). But this is not true for the 168260 older compiler, for which the sections are different lengths. We check 168261 to see if the function symtypetab section and its index are the same 168262 length, but we fail to skip this check when this is not a NEWFUNCINFO 168263 dict, and emit a spurious corruption error for a CTF dict we could 168264 have perfectly well opened and used. 168265 168266 Fix trivial: check the flag (and fix the terrible grammar of the error 168267 message at the same time). 168268 168269 libctf/ChangeLog 168270 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168271 168272 * ctf-open.c (ctf_bufopen_internal): Don't complain about corrupt 168273 function index symtypetab sections if this is an old-format 168274 function symtypetab section (which should be ignored in any case). 168275 Fix bad grammar. 168276 1682772021-09-27 Nick Alcock <nick.alcock@oracle.com> 168278 168279 configure: regenerate in all projects that use libtool.m4 168280 (including sim/, which has no changelog.) 168281 168282 bfd/ChangeLog 168283 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168284 168285 * configure: Regenerate. 168286 168287 binutils/ChangeLog 168288 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168289 168290 * configure: Regenerate. 168291 168292 gas/ChangeLog 168293 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168294 168295 * configure: Regenerate. 168296 168297 gprof/ChangeLog 168298 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168299 168300 * configure: Regenerate. 168301 168302 ld/ChangeLog 168303 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168304 168305 * configure: Regenerate. 168306 168307 libctf/ChangeLog 168308 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168309 168310 * configure: Regenerate. 168311 * Makefile.in: Regenerate. 168312 168313 opcodes/ChangeLog 168314 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168315 168316 * configure: Regenerate. 168317 168318 zlib/ChangeLog 168319 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168320 168321 * configure: Regenerate. 168322 1683232021-09-27 Nick Alcock <nick.alcock@oracle.com> 168324 168325 libctf: try several possibilities for linker versioning flags 168326 Checking for linker versioning by just grepping ld --help output for 168327 mentions of --version-script is inadequate now that Solaris 11.4 168328 implements a --version-script with different semantics. Try linking a 168329 test program with a small wildcard-using version script with each 168330 supported set of flags in turn, to make sure that linker versioning is 168331 not only advertised but actually works. 168332 168333 The Solaris "GNU-compatible" linker versioning is not quite 168334 GNU-compatible enough, but we can work around the differences by 168335 generating a new version script that removes the comments from the 168336 original (Solaris ld requires #-style comments), and making another 168337 version script for libctf-nonbfd in particular which doesn't mention any 168338 of the symbols that appear in libctf.la, to avoid Solaris ld introducing 168339 corresponding new NOTYPE symbols to match the version script. 168340 168341 libctf/ChangeLog 168342 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168343 168344 PR libctf/27967 168345 * configure.ac (VERSION_FLAGS): Replace with... 168346 (ac_cv_libctf_version_script): ... this multiple test. 168347 (VERSION_FLAGS_NOBFD): Substitute this too. 168348 * Makefile.am (libctf_nobfd_la_LDFLAGS): Use it. Split out... 168349 (libctf_ldflags_nover): ... non-versioning flags here. 168350 (libctf_la_LDFLAGS): Use it. 168351 * libctf.ver: Give every symbol not in libctf-nobfd a comment on 168352 the same line noting as much. 168353 1683542021-09-27 Nick Alcock <nick.alcock@oracle.com> 168355 168356 libtool.m4: fix nm BSD flag detection 168357 Libtool needs to get BSD-format (or MS-format) output out of the system 168358 nm, so that it can scan generated object files for symbol names for 168359 -export-symbols-regex support. Some nms need specific flags to turn on 168360 BSD-formatted output, so libtool checks for this in its AC_PATH_NM. 168361 Unfortunately the code to do this has a pair of interlocking flaws: 168362 168363 - it runs the test by doing an nm of /dev/null. Some platforms 168364 reasonably refuse to do an nm on a device file, but before now this 168365 has only been worked around by assuming that the error message has a 168366 specific textual form emitted by Tru64 nm, and that getting this 168367 error means this is Tru64 nm and that nm -B would work to produce 168368 BSD-format output, even though the test never actually got anything 168369 but an error message out of nm -B. This is fixable by nm'ing *nm 168370 itself* (since we necessarily have a path to it). 168371 168372 - the test is entirely skipped if NM is set in the environment, on the 168373 grounds that the user has overridden the test: but the user cannot 168374 reasonably be expected to know that libtool wants not only nm but 168375 also flags forcing BSD-format output. Worse yet, one such "user" is 168376 the top-level Cygnus configure script, which neither tests for 168377 nor specifies any BSD-format flags. So platforms needing BSD-format 168378 flags always fail to set them when run in a Cygnus tree, breaking 168379 -export-symbols-regex on such platforms. Libtool also needs to 168380 augment $LD on some platforms, but this is done unconditionally, 168381 augmenting whatever the user specified: the nm check should do the 168382 same. 168383 168384 One wrinkle: if the user has overridden $NM, a path might have been 168385 provided: so we use the user-specified path if there was one, and 168386 otherwise do the path search as usual. (If the nm specified doesn't 168387 work, this might lead to a few extra pointless path searches -- but 168388 the test is going to fail anyway, so that's not a problem.) 168389 168390 (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a 168391 symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where 168392 *that* is a symlink to /usr/bin/nm.) 168393 168394 ChangeLog 168395 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168396 168397 PR libctf/27967 168398 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided 168399 NM, if there is one. Run nm on itself, not on /dev/null, to avoid 168400 errors from nms that refuse to work on non-regular files. Remove 168401 other workarounds for this problem. Strip out blank lines from the 168402 nm output. 168403 1684042021-09-27 Nick Alcock <nick.alcock@oracle.com> 168405 168406 libtool.m4: augment symcode for Solaris 11 168407 This reports common symbols like GNU nm, via a type code of 'C'. 168408 168409 ChangeLog 168410 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168411 168412 PR libctf/27967 168413 * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for 168414 Solaris 11. 168415 1684162021-09-27 Nick Alcock <nick.alcock@oracle.com> 168417 168418 libctf: link against libiberty before linking in libbfd or libctf-nobfd 168419 This ensures that the CTF_LIBADD, which always contains at least this 168420 when doing a shared link: 168421 168422 -L`pwd`/../libiberty/pic -liberty 168423 168424 appears in the link line before any requirements pulled in by libbfd.la, 168425 which include -liberty but because it is install-time do not include the 168426 -L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path 168427 comes from the libbfd.la file, and is an install path). libiberty also 168428 appears after libbfd in the link line by virtue of libctf-nobfd.la, 168429 because libctf-nobfd has to follow libbfd in the link line, and that 168430 needs symbols from libiberty too. 168431 168432 Without this, an installed liberty might well be pulled in by libbfd, 168433 and if --enable-install-libiberty is not specified this libiberty might 168434 be completely incompatible with what is being installed and break either 168435 or boht of libbfd and libctf. (The specific problem observed here is 168436 that bsearch_r was not present, but other problems might easily be 168437 observed in future too.) 168438 168439 Because ld links against libctf, this has a tendency to break the system 168440 linker at install time too, if installing with --prefix=/usr. That's 168441 quite unpleasant to recover from. 168442 168443 libctf/ChangeLog 168444 2021-09-27 Nick Alcock <nick.alcock@oracle.com> 168445 168446 PR libctf/27360 168447 * Makefile.am (libctf_la_LIBADD): Link against libiberty 168448 before pulling in libbfd.la or pulling in libctf-nobfd.la. 168449 * Makefile.in: Regenerate. 168450 1684512021-09-27 Tom de Vries <tdevries@suse.de> 168452 168453 [gdb/build] Fix build with g++-4.8 168454 When building g++-4.8, we run into: 168455 ... 168456 src/gdb/dwarf2/read.c:919:5: error: multiple fields in union \ 168457 'partial_die_info::<anonymous union>' initialized 168458 ... 168459 168460 This is due to: 168461 ... 168462 union 168463 { 168464 struct 168465 { 168466 CORE_ADDR lowpc = 0; 168467 CORE_ADDR highpc = 0; 168468 }; 168469 ULONGEST ranges_offset; 168470 }; 168471 ... 168472 168473 The error looks incorrect, given that only one union member is initialized, 168474 and does not reproduce with newer g++. 168475 168476 Nevertheless, work around this by moving the initialization to a constructor. 168477 168478 [ I considered just removing the initialization, with the idea that access 168479 should be guarded by has_pc_info, but I ran into one failure in the testsuite, 168480 for gdb.base/check-psymtab.exp due to add_partial_symbol using lowpc without 168481 checking has_pc_info. ] 168482 168483 Tested on x86_64-linux. 168484 1684852021-09-27 Andrew Burgess <andrew.burgess@embecosm.com> 168486 168487 gdb: add setting to disable reading source code files 168488 In some situations it is possible that a user might not want GDB to 168489 try and access source code files, for example, the source code might 168490 be stored on a slow to access network file system. 168491 168492 It is almost certainly possible that using some combination of 'set 168493 directories' and/or 'set substitute-path' a user can trick GDB into 168494 being unable to find the source files, but this feels like a rather 168495 crude way to solve the problem. 168496 168497 In this commit a new option is add that stops GDB from opening and 168498 reading the source files. A user can run with source code reading 168499 disabled if this is required, then re-enable later if they decide 168500 that they now want to view the source code. 168501 1685022021-09-27 Andrew Burgess <andrew.burgess@embecosm.com> 168503 168504 gdb: remove duplicate cmd_list_element declarations 168505 For some reason we have two locations where cmd_list_elements are 168506 declared, cli/cli-cmds.h and gdbcmd.h. Worse still there is 168507 duplication between these two locations. 168508 168509 In this commit I have moved all of the cmd_list_element declarations 168510 from gdbcmd.h into cli/cli-cmds.h and removed the duplicates. 168511 168512 There should be no user visible changes after this commit. 168513 1685142021-09-27 Andrew Burgess <andrew.burgess@embecosm.com> 168515 168516 gdb: prevent an assertion when computing the frame_id for an inline frame 168517 I ran into this assertion while GDB was trying to unwind the stack: 168518 168519 gdb/inline-frame.c:173: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed. 168520 168521 That is, when building the frame_id for an inline frame, GDB asks for 168522 the frame_id of the previous frame. Unfortunately, no valid frame_id 168523 was returned for the previous frame, and so the assertion triggers. 168524 168525 What is happening is this, I had a stack that looked something like 168526 this (the arrows '->' point from caller to callee): 168527 168528 normal_frame -> inline_frame 168529 168530 However, for whatever reason (e.g. broken debug information, or 168531 corrupted stack contents in the inferior), when GDB tries to unwind 168532 "normal_frame", it ends up getting back effectively the same frame, 168533 thus the call stack looks like this to GDB: 168534 168535 .-> normal_frame -> inline_frame 168536 | | 168537 '-----' 168538 168539 Given such a situation we would expect GDB to terminate the stack with 168540 an error like this: 168541 168542 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 168543 168544 However, the inline_frame causes a problem, and here's why: 168545 168546 When unwinding we start from the sentinel frame and call 168547 get_prev_frame. We eventually end up in get_prev_frame_if_no_cycle, 168548 in here we create a raw frame, and as this is frame #0 we immediately 168549 return. 168550 168551 However, eventually we will try to unwind the stack further. When we 168552 do this we inevitably needing to know the frame_id for frame #0, and 168553 so, eventually, we end up in compute_frame_id. 168554 168555 In compute_frame_id we first find the right unwinder for this frame, 168556 in our case (i.e. for inline_frame) the $pc is within the function 168557 normal_frame, but also within a block associated with the inlined 168558 function inline_frame, as such the inline frame unwinder claims this 168559 frame. 168560 168561 Back in compute_frame_id we next compute the frame_id, for our 168562 inline_frame this means a call to inline_frame_this_id. 168563 168564 The ID of an inline frame is based on the id of the previous frame, so 168565 from inline_frame_this_id we call get_prev_frame_always, this 168566 eventually calls get_prev_frame_if_no_cycle again, which creates 168567 another raw frame and calls compute_frame_id (for frames other than 168568 frame 0 we immediately compute the frame_id). 168569 168570 In compute_frame_id we again identify the correct unwinder for this 168571 frame. Our $pc is unchanged, however, the fact that the next frame is 168572 of type INLINE_FRAME prevents the inline frame unwinder from claiming 168573 this frame again, and so, the standard DWARF frame unwinder claims 168574 normal_frame. 168575 168576 We return to compute_frame_id and call the standard DWARF function to 168577 build the frame_id for normal_frame. 168578 168579 With the frame_id of normal_frame figured out we return to 168580 compute_frame_id, and then to get_prev_frame_if_no_cycle, where we add 168581 the ID for normal_frame into the frame_id cache, and return the frame 168582 back to inline_frame_this_id. 168583 168584 From inline_frame_this_id we build a frame_id for inline_frame and 168585 return to compute_frame_id, and then to get_prev_frame_if_no_cycle, 168586 which adds the frame_id for inline_frame into the frame_id cache. 168587 168588 So far, so good. 168589 168590 However, as we are trying to unwind the complete stack, we eventually 168591 ask for the previous frame of normal_frame, remember, at this point 168592 GDB doesn't know the stack is corrupted (with a cycle), GDB still 168593 needs to figure that out. 168594 168595 So, we eventually end up in get_prev_frame_if_no_cycle where we create 168596 a raw frame and call compute_frame_id, remember, this is for the frame 168597 before normal_frame. 168598 168599 The first task for compute_frame_id is to find the unwinder for this 168600 frame, so all of the frame sniffers are tried in order, this includes 168601 the inline frame sniffer. 168602 168603 The inline frame sniffer asks for the $pc, this request is sent up the 168604 stack to normal_frame, which, due to its cyclic behaviour, tells GDB 168605 that the $pc in the previous frame was the same as the $pc in 168606 normal_frame. 168607 168608 GDB spots that this $pc corresponds to both the function normal_frame 168609 and also the inline function inline_frame. As the next frame is not 168610 an INLINE_FRAME then GDB figures that we have not yet built a frame to 168611 cover inline_frame, and so the inline sniffer claims this new frame. 168612 Our stack is now looking like this: 168613 168614 inline_frame -> normal_frame -> inline_frame 168615 168616 But, we have not yet computed the frame id for the outer most (on the 168617 left) inline_frame. After the frame sniffer has claimed the inline 168618 frame GDB returns to compute_frame_id and calls inline_frame_this_id. 168619 168620 In here GDB calls get_prev_frame_always, which eventually ends up 168621 in get_prev_frame_if_no_cycle again, where we create a raw frame and 168622 call compute_frame_id. 168623 168624 Just like before, compute_frame_id tries to find an unwinder for this 168625 new frame, it sees that the $pc is within both normal_frame and 168626 inline_frame, but the next frame is, again, an INLINE_FRAME, so, just 168627 like before the standard DWARF unwinder claims this frame. Back in 168628 compute_frame_id we again call the standard DWARF function to build 168629 the frame_id for this new copy of normal_frame. 168630 168631 At this point the stack looks like this: 168632 168633 normal_frame -> inline_frame -> normal_frame -> inline_frame 168634 168635 After compute_frame_id we return to get_prev_frame_if_no_cycle, where 168636 we try to add the frame_id for the new normal_frame into the frame_id 168637 cache, however, unlike before, we fail to add this frame_id as it is 168638 a duplicate of the previous normal_frame frame_id. Having found a 168639 duplicate get_prev_frame_if_no_cycle unlinks the new frame from the 168640 stack, and returns nullptr, the stack now looks like this: 168641 168642 inline_frame -> normal_frame -> inline_frame 168643 168644 The nullptr result from get_prev_frame_if_no_cycle is fed back to 168645 inline_frame_this_id, which forwards this to get_frame_id, which 168646 immediately returns null_frame_id. As null_frame_id is not considered 168647 a valid frame_id, this is what triggers the assertion. 168648 168649 In summary then: 168650 168651 - inline_frame_this_id currently assumes that as the inline frame 168652 exists, we will always get a valid frame back from 168653 get_prev_frame_always, 168654 168655 - get_prev_frame_if_no_cycle currently assumes that it is safe to 168656 return nullptr when it sees a cycle. 168657 168658 Notice that in frame.c:compute_frame_id, this code: 168659 168660 fi->this_id.value = outer_frame_id; 168661 fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value); 168662 gdb_assert (frame_id_p (fi->this_id.value)); 168663 168664 The assertion makes it clear that the this_id function must always 168665 return a valid frame_id (e.g. null_frame_id is not a valid return 168666 value), and similarly in inline_frame.c:inline_frame_this_id this 168667 code: 168668 168669 *this_id = get_frame_id (get_prev_frame_always (this_frame)); 168670 /* snip comment */ 168671 gdb_assert (frame_id_p (*this_id)); 168672 168673 Makes it clear that every inline frame expects to be able to get a 168674 previous frame, which will have a valid frame_id. 168675 168676 As I have discussed above, these assumptions don't currently hold in 168677 all cases. 168678 168679 One possibility would be to move the call to get_prev_frame_always 168680 forward from inline_frame_this_id to inline_frame_sniffer, however, 168681 this falls foul of (in frame.c:frame_cleanup_after_sniffer) this 168682 assertion: 168683 168684 /* No sniffer should extend the frame chain; sniff based on what is 168685 already certain. */ 168686 gdb_assert (!frame->prev_p); 168687 168688 This assert prohibits any sniffer from trying to get the previous 168689 frame, as getting the previous frame is likely to depend on the next 168690 frame, I can understand why this assertion is a good thing, and I'm in 168691 no rush to alter this rule. 168692 168693 The solution proposed here takes onboard feedback from both Pedro, and 168694 Simon (see the links below). The get_prev_frame_if_no_cycle function 168695 is renamed to get_prev_frame_maybe_check_cycle, and will now not do 168696 cycle detection for inline frames, even when we spot a duplicate frame 168697 it is still returned. This is fine, as, if the normal frame has a 168698 duplicate frame-id then the inline frame will also have a duplicate 168699 frame-id. And so, when we reject the inline frame, the duplicate 168700 normal frame, which is previous to the inline frame, will also be 168701 rejected. 168702 168703 In inline-frame.c the call to get_prev_frame_always is no longer 168704 nested inside the call to get_frame_id. There are reasons why 168705 get_prev_frame_always can return nullptr, for example, if there is a 168706 memory error while trying to get the previous frame, if this should 168707 happen then we now give a more informative error message. 168708 168709 Historical Links: 168710 168711 Patch v2: https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html 168712 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/180651.html 168713 https://sourceware.org/pipermail/gdb-patches/2021-July/180663.html 168714 168715 Patch v3: https://sourceware.org/pipermail/gdb-patches/2021-July/181029.html 168716 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/181035.html 168717 168718 Additional input: https://sourceware.org/pipermail/gdb-patches/2021-September/182040.html 168719 1687202021-09-27 Tom de Vries <tdevries@suse.de> 168721 168722 [gdb/testsuite] Fix gdb.base/dcache-flush.exp 168723 When running test-case gdb.base/dcache-flush.exp on ubuntu 18.04.5, I run into: 168724 ... 168725 (gdb) PASS: gdb.base/dcache-flush.exp: p var2 168726 info dcache^M 168727 Dcache 4096 lines of 64 bytes each.^M 168728 Contains data for Thread 0x7ffff7fc6b80 (LWP 3551)^M 168729 Line 0: address 0x7fffffffd4c0 [47 hits]^M 168730 Line 1: address 0x7fffffffd500 [31 hits]^M 168731 Line 2: address 0x7fffffffd5c0 [7 hits]^M 168732 Cache state: 3 active lines, 85 hits^M 168733 (gdb) FAIL: gdb.base/dcache-flush.exp: check dcache before flushing 168734 ... 168735 The regexp expects "Contains data for process $decimal". 168736 168737 This is another case of thread_db_target::pid_to_str being used. 168738 168739 Fix this by updating the regexp. 168740 168741 Tested on x86_64-linux. 168742 1687432021-09-27 Tom de Vries <tdevries@suse.de> 168744 168745 [gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp 168746 The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s 168747 when using hw watchpoints, but when forcing sw watchpoints (using the patch 168748 mentioned in PR28375#c0), the test-case takes instead 3m14s. 168749 168750 Also, it show a FAIL: 168751 ... 168752 (gdb) continue^M 168753 Continuing.^M 168754 Cannot find user-level thread for LWP 10324: generic error^M 168755 (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: 168756 continue: watchpoint: continue 168757 ... 168758 for which PR28375 was filed. 168759 168760 Modify the test-case to: 168761 - add the hw/sw axis to the watchpoint testing, to ensure that we 168762 observe the sw watchpoint behaviour also on can-use-hw-watchpoints 168763 architectures. 168764 - skip the hw breakpoint testing if not supported 168765 - set the sw watchpoint later to avoid making the test 168766 too slow. This still triggers the same PR, but now takes just 24s. 168767 168768 This patch adds a KFAIL for PR28375. 168769 168770 Tested on x86_64-linux. 168771 1687722021-09-27 Simon Marchi <simon.marchi@polymtl.ca> 168773 168774 gdb: fix indentation in gdbtypes.c 168775 Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771 168776 1687772021-09-27 GDB Administrator <gdbadmin@sourceware.org> 168778 168779 Automatic date update in version.in 168780 1687812021-09-26 GDB Administrator <gdbadmin@sourceware.org> 168782 168783 Automatic date update in version.in 168784 1687852021-09-26 Peter Bergner <bergner@linux.ibm.com> 168786 168787 PowerPC: Enable mfppr mfppr32, mtppr and mtppr32 extended mnemonics on POWER5 168788 SPR 896 and the mfppr mfppr32, mtppr and mtppr32 extended mnemonics were added 168789 in ISA 2.03, so enable them on POWER5 and later. 168790 168791 opcodes/ 168792 * ppc-opc.c (powerpc_opcodes) <mfppr, mfppr32, mtppr, mtppr32>: Enable 168793 on POWER5 and later. 168794 168795 gas/ 168796 * testsuite/gas/ppc/power5.s: New test. 168797 * testsuite/gas/ppc/power5.d: Likewise. 168798 * testsuite/gas/ppc/ppc.exp: Run it. 168799 * testsuite/gas/ppc/power7.s: Remove tests for mfppr, mfppr32, mtppr 168800 and mtppr32. 168801 * testsuite/gas/ppc/power7.d: Likewise. 168802 1688032021-09-25 Tom de Vries <tdevries@suse.de> 168804 168805 [gdb/testsuite] Minimize gdb restarts 168806 Minimize gdb restarts, applying the following rules: 168807 - don't use prepare_for_testing unless necessary 168808 - don't use clean_restart unless necessary 168809 168810 Also, if possible, replace build_for_executable + clean_restart 168811 with prepare_for_testing for brevity. 168812 168813 Touches 68 test-cases. 168814 168815 Tested on x86_64-linux. 168816 1688172021-09-25 Alan Modra <amodra@gmail.com> 168818 168819 PR28346, segfault attempting to disassemble raw binary 168820 Don't attempt to access elf_section_data for non-ELF sections. 168821 168822 PR 28346 168823 * elf32-xtensa.c (xtensa_read_table_entries): Return zero entries 168824 for non-ELF. 168825 1688262021-09-25 GDB Administrator <gdbadmin@sourceware.org> 168827 168828 Automatic date update in version.in 168829 1688302021-09-24 Hans-Peter Nilsson <hp@axis.com> 168831 168832 gas/testsuite/ld-elf/dwarf2-21.d: Pass -W 168833 Required for the expected "CU:" to be emitted for long 168834 source-paths. See binutils/dwarf.c: 168835 168836 if (do_wide || strlen (directory) < 76) 168837 printf (_("CU: %s/%s:\n"), directory, file_table[0].name); 168838 else 168839 printf ("%s:\n", file_table[0].name); 168840 168841 See also commit 5f410aa50ce2c, "testsuite/ld-elf/pr26936.d: 168842 Pass -W." 168843 168844 gas/ChangeLog: 168845 * testsuite/ld-elf/dwarf2-21.d: Pass -W. 168846 1688472021-09-24 Simon Marchi <simon.marchi@polymtl.ca> 168848 168849 gdb: change thread_info::name to unique_xmalloc_ptr, add helper function 168850 This started out as changing thread_info::name to a unique_xmalloc_ptr. 168851 That showed that almost all users of that field had the same logic to 168852 get a thread's name: use thread_info::name if non-nullptr, else ask the 168853 target. Factor out this logic in a new thread_name free function. Make 168854 the field private (rename to m_name) and add some accessors. 168855 168856 Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc 168857 1688582021-09-24 Tom Tromey <tom@tromey.com> 168859 168860 Move value_true to value.h 168861 I noticed that value_true is declared in language.h and defined in 168862 language.c. However, as part of the value API, I think it would be 168863 better in one of those files. And, because it is very short, I 168864 changed it to be an inline function in value.h. I've also removed a 168865 comment from the implementation, on the basis that it seems obsolete 168866 -- if the change it suggests was needed, it probably would have been 168867 done by now; and if it is needed in the future, odds are it would be 168868 done differently anyway. 168869 168870 Finally, this patch also changes value_true and value_logical_not to 168871 return a bool, and updates some uses. 168872 1688732021-09-24 Pedro Alves <pedro@palves.net> 168874 168875 Make dcache multi-target-safe 168876 By inspection, I noticed that this code in dcache.c is not 168877 multi-target-aware: 168878 168879 /* If this is a different inferior from what we've recorded, 168880 flush the cache. */ 168881 168882 if (inferior_ptid != dcache->ptid) 168883 168884 This doesn't take into account that threads of different targets may 168885 have the same ptid. 168886 168887 Fixed by also storing/comparing the process_stratum_target. 168888 168889 Tested on x86-64-linux-gnu, native and gdbserver. 168890 168891 Change-Id: I4d9d74052c696b72d28cb1c77b697b911725c8d3 168892 1688932021-09-24 Pedro Alves <pedro@palves.net> 168894 168895 Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()' 168896 We currently have one FAIL while running "make check-perf": 168897 168898 PerfTest::assemble, run ... 168899 python Disassemble().run() 168900 Traceback (most recent call last): 168901 File "<string>", line 1, in <module> 168902 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run 168903 self.warm_up() 168904 File "<string>", line 25, in warm_up 168905 gdb.error: No symbol "ada_evaluate_subexp" in current context. 168906 Error while executing Python code. 168907 (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run() 168908 ... 168909 168910 The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to 168911 main, and then disassembles a few GDB functions. The problem is that 168912 most(!) functions it is trying to disassemble are now gone... 168913 168914 This commit fixes the issue by simply picking some other functions to 168915 disassemble. 168916 168917 It would perhaps be better to come up with some test program to 168918 disassemble, one that would stay the same throughout the years, 168919 instead of disassembling GDB itself. I don't know why that wasn't 168920 done to begin with. I'll have to leave that for another rainy day, 168921 though. 168922 168923 gdb/testsuite/ 168924 yyyy-mm-dd Pedro Alves <pedro@palves.net> 168925 168926 * gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble 168927 evaluate_subexp_do_call instead of ada_evaluate_subexp. 168928 (Disassemble::warm_up): Disassemble "captured_main", 168929 "run_inferior_call" and "update_global_location_list" instead of 168930 "evaluate_subexp_standard" and "c_parse_internal". 168931 168932 Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df 168933 1689342021-09-24 Pedro Alves <pedro@palves.net> 168935 168936 Fix all PATH problems in testsuite/gdb.perf/ 168937 Currently "make check-perf" triggers ~40 PATH messages in gdb.sum: 168938 168939 ... 168940 PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib")) 168941 PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) 168942 ... 168943 168944 This commit fixes them. E.g. before/after gdb.sum diff: 168945 168946 -PASS: gdb.perf/backtrace.exp: python import os, sys 168947 -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) 168948 -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) 168949 -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) 168950 -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) 168951 +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys 168952 +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib")) 168953 +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ()) 168954 168955 gdb/testsuite/ 168956 yyyy-mm-dd Pedro Alves <pedro@palves.net> 168957 168958 * lib/perftest.exp (PerfTest::_setup_perftest): Use 168959 with_test_prefix. Add explicit test names to python invocations, 168960 with "$srcdir" not expanded. 168961 168962 Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4 168963 1689642021-09-24 Pedro Alves <pedro@palves.net> 168965 168966 Fix all DUPLICATE problems in testsuite/gdb.perf/ 168967 Currently running "make check-perf" shows: 168968 168969 ... 168970 # of duplicate test names 6008 168971 ... 168972 168973 All those duplicate test names come from gdb.perf/skip-command.exp. 168974 This commit fixes them, using with_test_prefix. 168975 168976 gdb/testsuite/ 168977 yyyy-mm-dd Pedro Alves <pedro@palves.net> 168978 168979 * gdb.perf/skip-command.exp (run_skip_bench): Wrap each for 168980 iteration in with_test_prefix. 168981 168982 Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b 168983 1689842021-09-24 Tom Tromey <tromey@adacore.com> 168985 168986 Fix handling of DW_AT_data_bit_offset 168987 A newer version of GCC will now emit member locations using just 168988 DW_AT_data_bit_offset, like: 168989 168990 <3><14fe>: Abbrev Number: 1 (DW_TAG_member) 168991 <14ff> DW_AT_name : (indirect string, offset: 0x215e): nb_bytes 168992 <1503> DW_AT_decl_file : 1 168993 <1503> DW_AT_decl_line : 10 168994 <1504> DW_AT_decl_column : 7 168995 <1505> DW_AT_type : <0x150b> 168996 <1509> DW_AT_bit_size : 31 168997 <150a> DW_AT_data_bit_offset: 64 168998 168999 whereas earlier versions would emit something like: 169000 169001 <3><164f>: Abbrev Number: 7 (DW_TAG_member) 169002 <1650> DW_AT_name : (indirect string, offset: 0x218d): nb_bytes 169003 <1654> DW_AT_decl_file : 1 169004 <1655> DW_AT_decl_line : 10 169005 <1656> DW_AT_decl_column : 7 169006 <1657> DW_AT_type : <0x165f> 169007 <165b> DW_AT_byte_size : 4 169008 <165c> DW_AT_bit_size : 31 169009 <165d> DW_AT_bit_offset : 1 169010 <165e> DW_AT_data_member_location: 8 169011 169012 That is, DW_AT_data_member_location is not emitted any more. This is 169013 a change due to the switch to DWARF 5 by default. 169014 169015 This change pointed out an existing bug in gdb, namely that the 169016 attr_to_dynamic_prop depends on the presence of 169017 DW_AT_data_member_location. This patch moves the handling of 169018 DW_AT_data_bit_offset into handle_data_member_location, and updates 169019 attr_to_dynamic_prop to handle this new case. 169020 169021 A new test case is included. This test fails with GCC 11, but passes 169022 with an earlier version of GCC. 169023 1690242021-09-24 Tom de Vries <tdevries@suse.de> 169025 169026 [gdb/testsuite] Don't leave gdb instance running after function_range 169027 A typical dwarf assembly test-case start like this: 169028 ... 169029 standard_testfile .c -debug.S 169030 169031 set asm_file [standard_output_file $srcfile2] 169032 Dwarf::assemble $asm_file { 169033 ... 169034 } 169035 169036 if { [prepare_for_testing "failed to prepare" ${testfile} \ 169037 [list $srcfile $asm_file] {nodebug}] } { 169038 return -1 169039 } 169040 ... 169041 169042 When accidentally using build_for_executable instead of 169043 prepare_for_testing (or intentionally using it but forgetting to add 169044 clean_restart $binfile or some such) the mistake may not be caught, because 169045 another gdb instance is still running, and we may silently end up testing 169046 compiler-generated DWARF. 169047 169048 This can be caused by something relatively obvious, like an earlier 169049 prepare_for_testing or clean_restart, but also by something more obscure like 169050 function_range, which may even be triggered by dwarf assembly like this: 169051 ... 169052 {MACRO_AT_func {main}} 169053 ... 169054 169055 Fix this by calling gdb_exit at the end of function_range. 169056 169057 Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a 169058 get_sizeof call used the gdb instance left lingering by function_range. 169059 169060 [ A better and more complete fix would add a new proc get_exec_info, that would 169061 be called at the start of the dwarf assembly body: 169062 ... 169063 Dwarf::assemble $asm_file { 169064 get_exec_info {main foo} {int void*} 169065 ... 169066 that would: 169067 - do a prepare_for_testing with $srcfile (roughtly equivalent to what 169068 MACRO_AT_func does, 169069 - call function_range for all functions main and foo, without starting a 169070 new gdb instance 169071 - set corresponding variables at the call-site: main_start, main_len, 169072 main_end, foo_start, foo_len, foo_end. 169073 - get size for types int and void* 169074 - set corresponding variables at the call-site: int_size, void_ptr_size. 169075 - do a gdb_exit. ] 169076 169077 Tested on x86_64-linux. 169078 1690792021-09-24 Tom de Vries <tdevries@suse.de> 169080 169081 [gdb/testsuite] Use pie instead of -fpie/-pie 169082 I noticed two test-cases where -fpie is used. Using the canonical pie option 169083 will usually get one -fPIE instead. 169084 169085 That choice is justified here in gdb_compile: 169086 ... 169087 # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC 169088 # and SPARC, fpie can cause compile errors due to the GOT exceeding 169089 # a maximum size. On other architectures the two flags are 169090 # identical (see the GCC manual). Note Debian9 and Ubuntu16.10 169091 # onwards default GCC to using fPIE. If you do require fpie, then 169092 # it can be set using the pie_flag. 169093 set flag "additional_flags=-fPIE" 169094 ... 169095 169096 There is no indication that using -fpie rather than -fPIE is on purpose, so 169097 use pie instead. 169098 169099 Tested on x86_64-linux. 169100 1691012021-09-24 Tom de Vries <tdevries@suse.de> 169102 169103 [gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.exp 169104 Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp, 169105 and in the process: 169106 - fix a few typos 169107 - remove unnecessary "test -r /proc/cpuinfo" 169108 169109 Tested on x86_64-linux. 169110 169111 Co-Authored-By: Pedro Alves <pedro@palves.net> 169112 1691132021-09-24 Pedro Alves <pedro@palves.net> 169114 169115 gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclists 169116 It is currently not possible to use variables in locations lists. For 169117 example, with: 169118 169119 diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp 169120 index 6b4f5c8cbb8..cdbf948619f 100644 169121 --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp 169122 +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp 169123 @@ -30,6 +30,8 @@ if {![dwarf2_support]} { 169124 return 0 169125 } 169126 169127 +set myconst 0x123456 169128 + 169129 # Test with 32-bit and 64-bit DWARF. 169130 foreach_with_prefix is_64 {false true} { 169131 if { $is_64 } { 169132 @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} { 169133 global func1_addr func1_len 169134 global func2_addr func2_len 169135 global is_64 169136 + global myconst 169137 169138 # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists 169139 # section. 169140 @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} { 169141 list_ { 169142 # When in func1. 169143 start_length $func1_addr $func1_len { 169144 - DW_OP_constu 0x123456 169145 + DW_OP_constu $myconst 169146 DW_OP_stack_value 169147 } 169148 169149 we get: 169150 169151 $ make check TESTS="*/loclists-multiple-cus.exp" 169152 ... 169153 gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages: 169154 build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst 169155 ... 169156 169157 That means $myconst was copied literally to the generated assembly 169158 file. 169159 169160 This patch fixes it, by running subst on the location list body, in 169161 the context of the caller. The fix is applied to both 169162 Dwarf::loclists::table::list_::start_length and 169163 Dwarf::loclists::table::list_::start_end. 169164 169165 Reported-by: Zoran Zaric <Zoran.Zaric@amd.com> 169166 169167 Change-Id: I615a64431857242d9f477d5699e3732df1b31322 169168 1691692021-09-24 Tom de Vries <tdevries@suse.de> 169170 169171 [gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.exp 169172 When running test-case gdb.dwarf2/implptr-64bit.exp with target board 169173 unix/-m32, I noticed: 169174 ... 169175 DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare 169176 ... 169177 169178 Fix this by using with_test_prefix. 169179 169180 Tested on x86_64-linux. 169181 1691822021-09-24 Tom de Vries <tdevries@suse.de> 169183 169184 [gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.exp 169185 Fix these DUPLICATEs by using with_test_prefix: 169186 ... 169187 DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1 169188 DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2 169189 ... 169190 169191 Tested on x86_64-linux. 169192 1691932021-09-24 Tom de Vries <tdevries@suse.de> 169194 169195 [gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.exp 169196 When doing a testrun with: 169197 ... 169198 $ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp) 169199 ... 169200 I ran into: 169201 ... 169202 ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp. 169203 ERROR: expected integer but got "dw2-abs-hi-pc-world.c" 169204 while executing 169205 "incr i" 169206 ... 169207 169208 The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to 169209 gdb.dwarf2/dw2-is-stmt.exp. It's not removed by gdb_cleanup_globals because i 169210 is set as global variable by runtest.exp, which does: 169211 ... 169212 for { set i 0 } { $i < $argc } { incr i } { 169213 ... 169214 at toplevel but forgets to unset the variable. 169215 169216 Fix this by removing '$' in front of the variable name when doing set: 169217 ... 169218 -set $i 0 169219 +set i 0 169220 ... 169221 169222 Tested on x86_64-linux. 169223 1692242021-09-24 Tom de Vries <tdevries@suse.de> 169225 169226 [gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.exp 169227 Fix this duplicate: 169228 ... 169229 DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable 169230 ... 169231 by using with_test_prefix. 169232 169233 Tested on x86_64-linux. 169234 1692352021-09-24 Tom de Vries <tdevries@suse.de> 169236 169237 [gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pie 169238 I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of 169239 the canonical pie and nopie options, which would typically also add 169240 additional_flags=-fPIE respectively additional_flags=-fno-pie. 169241 169242 There is no indication that this is on purpose, so replace these with pie and 169243 nopie. 169244 169245 Tested on x86_64-linux. 169246 1692472021-09-24 Tom de Vries <tdevries@suse.de> 169248 169249 [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp 169250 When interpreting the testsuite results, it's often relevant what kind of 169251 machine the testsuite ran on. On a local machine one can just do 169252 /proc/cpuinfo, but in case of running tests using a remote system 169253 that distributes test runs to other remote systems that are not directly 169254 accessible, that's not possible. 169255 169256 Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a 169257 and uname -a. 169258 169259 We could do this at the start of each test run, by putting it into unix.exp 169260 or some such. However, this might be too verbose, so we choose to put it into 169261 its own test-case, such that it get triggered in a full testrun, but not when 169262 running one or a subset of tests. 169263 169264 We put the test-case into the gdb.testsuite directory, which is currently the 169265 only place in the testsuite where we do not test gdb. [ Though perhaps this 169266 could be put into a new gdb.info directory, since the test-case doesn't 169267 actually test the testsuite. ] 169268 169269 Tested on x86_64-linux. 169270 1692712021-09-24 GDB Administrator <gdbadmin@sourceware.org> 169272 169273 Automatic date update in version.in 169274 1692752021-09-23 Tom Tromey <tom@tromey.com> 169276 169277 Change pointer_type to a method of struct type 169278 I noticed that pointer_type is declared in language.h and defined in 169279 language.c. However, it really has to do with types, so it should 169280 have been in gdbtypes.h all along. 169281 169282 This patch changes it to be a method on struct type. And, I went 169283 through uses of TYPE_IS_REFERENCE and updated many spots to use the 169284 new method as well. (I didn't update ones that were in arch-specific 169285 code, as I couldn't readily test that.) 169286 1692872021-09-23 Tom de Vries <tdevries@suse.de> 169288 169289 [gdb/testsuite] Support -fPIE/-fno-PIE/-pie/-no-pie in gdb_compile_rust 169290 When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I 169291 run into: 169292 ... 169293 builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \ 169294 -g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M 169295 error: Unrecognized option: 'f'^M 169296 ^M 169297 compiler exited with status 1 169298 ... 169299 169300 The problem is that -fPIE and -fpie are gcc options, but for rust we use 169301 rustc, which has different compilation options. 169302 169303 Fix this by translating the gcc options to rustc options in gdb_compile_rust, 169304 similar to how that is done for ada in target_compile_ada_from_dir. 169305 169306 Likewise for unix/-fno-PIE/-no-pie. 169307 169308 Tested on x86_64-linux, with: 169309 - native 169310 - unix/-fPIE/-pie 169311 - unix/-fno-PIE/-no-pie 169312 specifically, on openSUSE Leap 15.2 both with package gcc-PIE: 169313 - installed (making gcc default to PIE) 169314 - uninstalled (making gcc default to non-PIE). 169315 and rustc 1.52.1. 169316 1693172021-09-23 Tom de Vries <tdevries@suse.de> 169318 169319 [gdb/testsuite] Use pie instead of -fPIE -pie 169320 Replace {additional_flags=-fPIE ldflags=-pie} with {pie}. 169321 169322 This makes sure that the test-cases properly error out when using target board 169323 unix/-fno-PIE/-no-pie. 169324 169325 Tested on x86_64-linux. 169326 1693272021-09-23 Tom de Vries <tdevries@suse.de> 169328 169329 [gdb/testsuite] Fix probe test in gdb.base/break-interp.exp 169330 When running test-case gdb.base/break-interp.exp on ubuntu 18.04.5, we have: 169331 ... 169332 (gdb) bt^M 169333 #0 0x00007eff7ad5ae12 in ?? () from break-interp-LDprelinkNOdebugNO^M 169334 #1 0x00007eff7ad71f50 in ?? () from break-interp-LDprelinkNOdebugNO^M 169335 #2 0x00007eff7ad59128 in ?? () from break-interp-LDprelinkNOdebugNO^M 169336 #3 0x00007eff7ad58098 in ?? () from break-interp-LDprelinkNOdebugNO^M 169337 #4 0x0000000000000002 in ?? ()^M 169338 #5 0x00007fff505d7a32 in ?? ()^M 169339 #6 0x00007fff505d7a94 in ?? ()^M 169340 #7 0x0000000000000000 in ?? ()^M 169341 (gdb) FAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: \ 169342 first backtrace: dl bt 169343 ... 169344 169345 Using the backtrace, the test-case tries to establish that we're stopped in 169346 dl_main. 169347 169348 However, the backtrace only shows an address, because: 169349 - the dynamic linker contains no minimal symbols and no debug info, and 169350 - gdb is build without --with-separate-debug-dir so it can't find the 169351 corresponding .debug file, which does contain the mimimal symbols and 169352 debug info. 169353 169354 As in "[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp", 169355 fix this by doing info probes and grepping for the address. 169356 169357 Tested on x86_64-linux. 169358 1693592021-09-23 Tom de Vries <tdevries@suse.de> 169360 169361 [gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp 169362 When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have: 169363 ... 169364 (gdb) run^M 169365 Starting program: break-probes^M 169366 Stopped due to shared library event (no libraries added or removed)^M 169367 (gdb) bt^M 169368 #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169369 #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169370 #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169371 #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169372 #4 0x0000000000000001 in ?? ()^M 169373 #5 0x00007fffffffdaac in ?? ()^M 169374 #6 0x0000000000000000 in ?? ()^M 169375 (gdb) UNSUPPORTED: gdb.base/break-probes.exp: probes not present on this system 169376 ... 169377 169378 Using the backtrace, the test-case tries to establish that we're stopped in 169379 dl_main, which is used as proof that we're using probes. 169380 169381 However, the backtrace only shows an address, because: 169382 - the dynamic linker contains no minimal symbols and no debug info, and 169383 - gdb is build without --with-separate-debug-dir so it can't find the 169384 corresponding .debug file, which does contain the mimimal symbols and 169385 debug info. 169386 169387 Fix this by instead printing the pc and grepping for the value in the 169388 info probes output: 169389 ... 169390 (gdb) p /x $pc^M 169391 $1 = 0x7ffff7dd6e12^M 169392 (gdb) info probes^M 169393 Type Provider Name Where Object ^M 169394 ... 169395 stap rtld init_start 0x00007ffff7dd6e12 /lib64/ld-linux-x86-64.so.2 ^M 169396 ... 169397 (gdb) 169398 ... 169399 169400 Tested on x86_64-linux. 169401 1694022021-09-23 Tom de Vries <tdevries@suse.de> 169403 169404 [gdb/testsuite] Handle failing probe detection in gdb.base/break-probes.exp 169405 When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have: 169406 ... 169407 (gdb) bt^M 169408 #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169409 #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169410 #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169411 #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M 169412 #4 0x0000000000000001 in ?? ()^M 169413 #5 0x00007fffffffdaac in ?? ()^M 169414 #6 0x0000000000000000 in ?? ()^M 169415 (gdb) FAIL: gdb.base/break-probes.exp: ensure using probes 169416 ... 169417 169418 The test-case intends to emit an UNTESTED in this case, but fails to do so 169419 because it tries to do it in a regexp clause in a gdb_test_multiple, which 169420 doesn't trigger. Instead, a default clause triggers which produces the FAIL. 169421 169422 Also the use of UNTESTED is not appropriate, and we should use UNSUPPORTED 169423 instead. 169424 169425 Fix this by silencing the FAIL, and emitting an UNSUPPORTED after the 169426 gdb_test_multiple: 169427 ... 169428 if { ! $using_probes } { 169429 + unsupported "probes not present on this system" 169430 return -1 169431 } 169432 ... 169433 169434 Tested on x86_64-linux. 169435 1694362021-09-23 Tom de Vries <tdevries@suse.de> 169437 169438 [gdb/testsuite] Use early-out style in gdb.base/break-probes.exp 169439 Reduce indentation and improve readability in test-case 169440 gdb.base/break-probes.exp by replacing: 169441 ... 169442 if { <cond> } { 169443 <lots-of-code> 169444 } 169445 ... 169446 with: 169447 ... 169448 if { ! <cond> } { 169449 return -1 169450 } 169451 <lots-of-code> 169452 ... 169453 169454 Tested on x86_64-linux. 169455 1694562021-09-23 Pedro Alves <pedro@palves.net> 169457 169458 Test that frame info/IDs are stable/consistent 169459 This adds a testcase that tests that the unwinder produces consistent 169460 frame info and frame IDs by making sure that "info frame" shows the 169461 same result when stopped at a function (level == 0), compared to when 169462 we find the same frame in the stack at a level > 0. 169463 169464 E.g., on x86-64, right after running to main, we see: 169465 169466 (gdb) info frame 169467 Stack level 0, frame at 0x7fffffffd340: 169468 rip = 0x555555555168 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3 169469 source language c. 169470 Arglist at 0x7fffffffd330, args: 169471 Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340 169472 Saved registers: 169473 rbp at 0x7fffffffd330, rip at 0x7fffffffd338 169474 (gdb) 169475 169476 and then after continuing to a function called by main, and selecting 169477 the "main" frame again, we see: 169478 169479 (gdb) info frame 169480 Stack level 3, frame at 0x7fffffffd340: 169481 rip = 0x555555555172 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3 169482 caller of frame at 0x7fffffffd330 169483 source language c. 169484 Arglist at 0x7fffffffd330, args: 169485 Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340 169486 Saved registers: 169487 rbp at 0x7fffffffd330, rip at 0x7fffffffd338 169488 (gdb) 169489 169490 The only differences should be in the stack level, the 'rip = ' 169491 address, and the presence of the "caller of frame at" info. All the 169492 rest should be the same. If it isn't, it probably means that the 169493 frame base, the frame ID, etc. aren't stable & consistent. 169494 169495 The testcase exercises both the DWARF and the heuristic unwinders, 169496 using "maint set dwarf unwinder on/off". 169497 169498 Tested on {x86-64 -m64, x86-64 -m32, Aarch64, Power8} GNU/Linux. 169499 169500 Change-Id: I795001c82cc70d543d197415e3f80ce5dc7f3452 169501 1695022021-09-23 Tom Tromey <tromey@adacore.com> 169503 169504 Change get_ada_task_ptid parameter type 169505 get_ada_task_ptid currently takes a 'long' as its 'thread' parameter 169506 type. However, on some platforms this is actually a pointer, and 169507 using 'long' can sometimes end up with the value being sign-extended. 169508 This sign extension can cause problems later, if the tid is then later 169509 used as an address again. 169510 169511 This patch changes the parameter type to ULONGEST and updates all the 169512 uses. This approach preserves sign extension on the targets where it 169513 is apparently intended, while avoiding it on others. 169514 169515 Co-Authored-By: John Baldwin <jhb@FreeBSD.org> 169516 1695172021-09-23 Tom Tromey <tromey@adacore.com> 169518 169519 Change ptid_t::tid to ULONGEST 169520 The ptid_t 'tid' member is normally used as an address in gdb -- both 169521 bsd-uthread and ravenscar-thread use it this way. However, because 169522 the type is 'long', this can cause problems with sign extension. 169523 169524 This patch changes the type to ULONGEST to ensure that sign extension 169525 does not occur. 169526 1695272021-09-23 Tom Tromey <tromey@adacore.com> 169528 169529 Remove defaulted 'tid' parameter to ptid_t constructor 169530 I wanted to find, and potentially modify, all the spots where the 169531 'tid' parameter to the ptid_t constructor was used. So, I temporarily 169532 removed this parameter and then rebuilt. 169533 169534 In order to make it simpler to search through the "real" (nonzero) 169535 uses of this parameter, something I knew I'd have to do multiple 169536 times, I removed any ", 0" from constructor calls. 169537 169538 Co-Authored-By: John Baldwin <jhb@FreeBSD.org> 169539 1695402021-09-23 Tom Tromey <tom@tromey.com> 169541 169542 Style the "XXX" text in ptype/o 169543 This patch changes gdb to use the 'highlight' style on the "XXX" text 169544 in the output of ptype/o. 169545 1695462021-09-23 GDB Administrator <gdbadmin@sourceware.org> 169547 169548 Automatic date update in version.in 169549 1695502021-09-22 Tom de Vries <tdevries@suse.de> 169551 169552 [gdb/testsuite] Fix gdb.python/py-events.exp 169553 With test-case gdb.python/py-events.exp on ubuntu 18.04.5 we run into: 169554 ... 169555 (gdb) info threads^M 169556 Id Target Id Frame ^M 169557 * 1 Thread 0x7ffff7fc3740 (LWP 31467) "py-events" do_nothing () at \ 169558 src/gdb/testsuite/gdb.python/py-events-shlib.c:19^M 169559 (gdb) FAIL: gdb.python/py-events.exp: get current thread 169560 ... 169561 169562 The info thread commands uses "Thread" instead of "process" because 169563 libpthread is already loaded: 169564 ... 169565 new objfile name: /lib/x86_64-linux-gnu/libdl.so.2^M 169566 [Thread debugging using libthread_db enabled]^M 169567 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M 169568 event type: new_objfile^M 169569 new objfile name: /lib/x86_64-linux-gnu/libpthread.so.0^M 169570 ... 169571 and consequently thread_db_target::pid_to_str is used. 169572 169573 Fix this by parsing the "Thread" expression. 169574 169575 Tested on x86_64-linux. 169576 1695772021-09-22 Tom de Vries <tdevries@suse.de> 169578 169579 [gdb] Add maint selftest -verbose option 169580 The print_one_insn selftest in gdb/disasm-selftests.c contains: 169581 ... 169582 /* If you want to see the disassembled instruction printed to gdb_stdout, 169583 set verbose to true. */ 169584 static const bool verbose = false; 169585 ... 169586 169587 Make this parameter available in the maint selftest command using a new option 169588 -verbose, such that we can do: 169589 ... 169590 (gdb) maint selftest -verbose print_one_insn 169591 ... 169592 169593 Tested on x86_64-linux. 169594 1695952021-09-22 Alan Modra <amodra@gmail.com> 169596 169597 dwarf2 sub-section test 169598 This is a testcase for the bug fixed by commit 5b4846283c3d. When 169599 running the testcase on ia64 targets I found timeouts along with lots 169600 of memory being consumed, due to ia64 gas not tracking text 169601 sub-sections. Trying to add nops for ".nop 16" in ".text 1" resulting 169602 in them being added to subsegment 0, with no increase to subsegment 1 169603 size. This patch also fixes that problem. 169604 169605 Note that the testcase fails on ft32-elf, mn10200-elf, score-elf, 169606 tic5x-elf, and xtensa-elf. The first two are relocation errors, the 169607 last three appear to be the .nop directive failing to emit the right 169608 number of nops. I didn't XFAIL any of them. 169609 169610 * config/tc-ia64.c (md): Add last_text_subseg. 169611 (ia64_flush_insns, dot_endp): Use last_text_subseg. 169612 (ia64_frob_label, md_assemble): Set last_text_subseg. 169613 * testsuite/gas/elf/dwarf2-21.d, 169614 * testsuite/gas/elf/dwarf2-21.s: New test. 169615 * testsuite/gas/elf/elf.exp: Run it. 169616 1696172021-09-22 Alan Modra <amodra@gmail.com> 169618 169619 Fix x86 "FAIL: TLS -fno-pic -shared" 169620 Fix a typo in commit 5d0869d9872a 169621 169622 * testsuite/ld-i386/tlsnopic.rd: Typo fix. 169623 1696242021-09-22 GDB Administrator <gdbadmin@sourceware.org> 169625 169626 Automatic date update in version.in 169627 1696282021-09-21 Nick Clifton <nickc@redhat.com> 169629 169630 Change the linker's heuristic for computing the entry point for binaries so that shared libraries default to an entry point of 0. 169631 * ldlang.c (lang_end): When computing the entry point, only 169632 try the start address of the entry section when creating an 169633 executable. 169634 * ld.texi (Entry point): Update description of heuristic used to 169635 choose the entry point. 169636 testsuite/ld-alpha/tlspic.rd: Update expected entry point address. 169637 testsuite/ld-arm/tls-gdesc-got.d: Likewise. 169638 testsuite/ld-i386/tlsnopic.rd: Likewise. 169639 testsuite/ld-ia64/tlspic.rd: Likewise. 169640 testsuite/ld-sparc/gotop32.rd: Likewise. 169641 testsuite/ld-sparc/gotop64.rd: Likewise. 169642 testsuite/ld-sparc/tlssunnopic32.rd: Likewise. 169643 testsuite/ld-sparc/tlssunnopic64.rd: Likewise. 169644 testsuite/ld-sparc/tlssunpic32.rd: Likewise. 169645 testsuite/ld-sparc/tlssunpic64.rd: Likewise. 169646 testsuite/ld-tic6x/shlib-1.rd: Likewise. 169647 testsuite/ld-tic6x/shlib-1b.rd: Likewise. 169648 testsuite/ld-tic6x/shlib-1r.rd: Likewise. 169649 testsuite/ld-tic6x/shlib-1rb.rd: Likewise. 169650 testsuite/ld-tic6x/shlib-noindex.rd: Likewise. 169651 testsuite/ld-x86-64/pr14207.d: Likewise. 169652 testsuite/ld-x86-64/tlsdesc.rd: Likewise. 169653 testsuite/ld-x86-64/tlspic.rd: Likewise. 169654 testsuite/ld-x86-64/tlspic2.rd: Likewise. 169655 1696562021-09-21 Tom de Vries <tdevries@suse.de> 169657 169658 [gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.exp 169659 In test-case gdb.base/gdb-caching-proc.exp, we run all procs declared with 169660 gdb_caching_proc. Some of these require a gdb instance, some not. 169661 169662 We could just do a clean_restart every time, but that would amount to 44 gdb 169663 restarts. We try to minimize this by doing this only for the few procs that 169664 need it, and hardcoding those in the test-case. 169665 169666 For those procs, we do a clean_restart, execute the proc, and then do a 169667 gdb_exit, to make sure the gdb instance doesn't linger such that we detect 169668 procs that need a gdb instance but are not listed in the test-case. 169669 169670 However, that doesn't work in the case of gnat_runtime_has_debug_info. This 169671 proc doesn't require a gdb instance because it starts its own. But it doesn't 169672 clean up the gdb instance, and since it's not listed, the test-case 169673 doesn't clean up the gdb instance eiter. Consequently, the proc 169674 supports_memtag (which should be listed, but isn't) uses the gdb instance 169675 started by gnat_runtime_has_debug_info rather than throwing an error. Well, 169676 unless gnat_runtime_has_debug_info fails before starting a gdb instance, in 169677 which case we do run into the error. 169678 169679 Fix this by: 169680 - doing gdb_exit unconditionally 169681 - fixing the resulting error by adding supports_memtag in the test-case to 169682 the "needing gdb instance" list 169683 169684 Tested on x86_64-linux. 169685 1696862021-09-21 Felix Willgerodt <felix.willgerodt@intel.com> 169687 169688 gdb, doc: Add ieee_half and bfloat16 to list of predefined target types. 169689 For some reason these two weren't added to the list when they were orginally 169690 added to GDB. 169691 169692 gdb/doc/ChangeLog: 169693 2021-09-21 Felix Willgerodt <felix.willgerodt@intel.com> 169694 169695 * gdb.texinfo (Predefined Target Types): Mention ieee_half and bfloat16. 169696 1696972021-09-21 GDB Administrator <gdbadmin@sourceware.org> 169698 169699 Automatic date update in version.in 169700 1697012021-09-20 Tom de Vries <tdevries@suse.de> 169702 169703 [gdb/testsuite] Fix gdb.ada/interface.exp with gcc-9 169704 When running test-case gdb.ada/interface.exp with gcc-9, we run into: 169705 ... 169706 (gdb) info locals^M 169707 s = (x => 1, y => 2, w => 3, h => 4)^M 169708 r = (x => 1, y => 2, w => 3, h => 4)^M 169709 (gdb) FAIL: gdb.ada/interface.exp: info locals 169710 ... 169711 169712 The failure is caused by the regexp expecting variable r followed by 169713 variable s. 169714 169715 Fix this by allowing variable s followed by variable r as well. 169716 169717 Tested on x86_64-linux. 169718 1697192021-09-20 Tom de Vries <tdevries@suse.de> 169720 169721 [gdb/testsuite] Fix gdb.ada/mi_prot.exp 169722 When running test-case gdb.ada/mi_prot.exp with gcc 8.5.0, we run into: 169723 ... 169724 (gdb) ^M 169725 Expecting: ^(-stack-list-arguments --no-frame-filters 1[^M 169726 ]+)?(\^done,stack=.*[^M 169727 ]+[(]gdb[)] ^M 169728 [ ]*) 169729 -stack-list-arguments --no-frame-filters 1^M 169730 ^done,stack-args=[frame={level="0",args=[{name="<_object>",value="(ceiling_priority =\ 169731 > 97, local => 0)"},{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={le\ 169732 vel="1",args=[{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={level="2\ 169733 ",args=[]}]^M 169734 (gdb) ^M 169735 FAIL: gdb.ada/mi_prot.exp: -stack-list-arguments --no-frame-filters 1 (unexpected out\ 169736 put) 169737 ... 169738 169739 Fix this by updating the regexp to expect "^done,stack-args=" instead of 169740 "^done,stack=". 169741 169742 Tested on x86_64-linux. 169743 1697442021-09-20 Tom de Vries <tdevries@suse.de> 169745 169746 [gdb/testsuite] Register test for each arch separately in register_test_foreach_arch 169747 In gdb/disasm-selftests.c we have: 169748 ... 169749 selftests::register_test_foreach_arch ("print_one_insn", 169750 selftests::print_one_insn_test); 169751 ... 169752 and we get: 169753 ... 169754 $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \ 169755 | grep ^Running 169756 Running selftest print_one_insn. 169757 $ 169758 ... 169759 169760 Change the semantics register_test_foreach_arch such that a version of 169761 print_one_insn is registered for each architecture, such that we have: 169762 ... 169763 $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \ 169764 | grep ^Running 169765 Running selftest print_one_insn::A6. 169766 Running selftest print_one_insn::A7. 169767 Running selftest print_one_insn::ARC600. 169768 ... 169769 $ 169770 ... 169771 169772 This makes it f.i. possible to do: 169773 ... 169774 $ gdb -q -batch a.out -ex "maint selftest print_one_insn::armv8.1-m.main" 169775 Running selftest print_one_insn::armv8.1-m.main. 169776 Self test failed: self-test failed at src/gdb/disasm-selftests.c:165 169777 Ran 1 unit tests, 1 failed 169778 ... 169779 169780 Tested on x86_64-linux with an --enable-targets=all build. 169781 1697822021-09-20 Tom de Vries <tdevries@suse.de> 169783 169784 [gdb] Change register_test to use std::function arg 169785 Change register_test to use std::function arg, such that we can do: 169786 ... 169787 register_test (test_name, [=] () { SELF_CHECK (...); }); 169788 ... 169789 169790 Tested on x86_64-linux. 169791 1697922021-09-20 Tom de Vries <tdevries@suse.de> 169793 169794 [gdb/testsuite] Fix gdb.ada/big_packed_array.exp xfail for -m32 169795 With test-case gdb.ada/big_packed_array.exp and target board unix/-m32 I run 169796 into: 169797 ... 169798 (gdb) print bad^M 169799 $2 = (0 => 0 <repeats 24 times>, 160)^M 169800 (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad 169801 ... 169802 169803 The problem is that while the variable is an array of 196 bits (== 24.5 bytes), 169804 the debug information describes it as 25 unsigned char. This is PR 169805 gcc/101643, and the test-case contains an xfail for this, which catches only: 169806 ... 169807 (gdb) print bad^M 169808 $2 = (0 => 0 <repeats 25 times>)^M 169809 ... 169810 169811 Fix this by updating the xfail pattern. 169812 169813 Tested on x86_64-linux. 169814 1698152021-09-20 Simon Marchi <simon.marchi@polymtl.ca> 169816 169817 gdbsupport/gdb_proc_service.h: use decltype instead of typeof 169818 Bug 28341 shows that GDB fails to compile when built with -std=c++11. 169819 I don't know much about the use case, but according to the author of the 169820 bug: 169821 169822 I encountered the scenario where CXX is set to "g++ -std=c++11" when 169823 I try to compile binutils under GCC as part of the GCC 3-stage 169824 compilation, which is common for building a cross-compiler. 169825 169826 The author of the bug suggests using __typeof__ instead of typeof. But 169827 since we're using C++, we might as well use decltype, which is standard. 169828 This is what this patch does. 169829 169830 The failure (and fix) can be observed by configuring GDB with CXX="g++ 169831 -std=c++11": 169832 169833 CXX linux-low.o 169834 In file included from /home/simark/src/binutils-gdb/gdbserver/gdb_proc_service.h:22, 169835 from /home/simark/src/binutils-gdb/gdbserver/linux-low.h:27, 169836 from /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:20: 169837 /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:177:50: error: expected constructor, destructor, or type conversion before (token 169838 177 | __attribute__((visibility ("default"))) typeof (SYM) SYM 169839 | ^ 169840 /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:179:1: note: in expansion of macro PS_EXPORT 169841 179 | PS_EXPORT (ps_get_thread_area); 169842 | ^~~~~~~~~ 169843 169844 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28341 169845 Change-Id: I84fbaae938209d8d935ca08dec9b7e6a0dd1bda0 169846 1698472021-09-20 Andrew Burgess <andrew.burgess@embecosm.com> 169848 169849 riscv: print .2byte or .4byte before an unknown instruction encoding 169850 When the RISC-V disassembler encounters an unknown instruction, it 169851 currently just prints the value of the bytes, like this: 169852 169853 Dump of assembler code for function custom_insn: 169854 0x00010132 <+0>: addi sp,sp,-16 169855 0x00010134 <+2>: sw s0,12(sp) 169856 0x00010136 <+4>: addi s0,sp,16 169857 0x00010138 <+6>: 0x52018b 169858 0x0001013c <+10>: 0x9c45 169859 169860 My proposal, in this patch, is to change the behaviour to this: 169861 169862 Dump of assembler code for function custom_insn: 169863 0x00010132 <+0>: addi sp,sp,-16 169864 0x00010134 <+2>: sw s0,12(sp) 169865 0x00010136 <+4>: addi s0,sp,16 169866 0x00010138 <+6>: .4byte 0x52018b 169867 0x0001013c <+10>: .2byte 0x9c45 169868 169869 Adding the .4byte and .2byte opcodes. The benefit that I see here is 169870 that in the patched version of the tools, the disassembler output can 169871 be fed back into the assembler and it should assemble to the same 169872 binary format. Before the patch, the disassembler output is invalid 169873 assembly. 169874 169875 I've started a RISC-V specific test file under binutils so that I can 169876 add a test for this change. 169877 169878 binutils/ChangeLog: 169879 169880 * testsuite/binutils-all/riscv/riscv.exp: New file. 169881 * testsuite/binutils-all/riscv/unknown.d: New file. 169882 * testsuite/binutils-all/riscv/unknown.s: New file. 169883 169884 opcodes/ChangeLog: 169885 169886 * riscv-dis.c (riscv_disassemble_insn): Print a .%dbyte opcode 169887 before an unknown instruction, '%d' is replaced with the 169888 instruction length. 169889 1698902021-09-20 Alan Modra <amodra@gmail.com> 169891 169892 Fix allocate_filenum last dir/file checks 169893 * dwarf2dbg.c (allocate_filenum) Correct use of last_used_dir_len. 169894 1698952021-09-20 Alan Modra <amodra@gmail.com> 169896 169897 Re: PR28149, debug info with wrong file association 169898 Fixes segfaults when building aarch64-linux kernel, due to only doing 169899 part of the work necessary when allocating file numbers late. I'd 169900 missed looping over subsegments, which resulted in some u.filename 169901 entries left around and later interpreted as u.view. 169902 169903 PR 28149 169904 * dwarf2dbg.c (purge_generated_debug): Iterate over subsegs too. 169905 (dwarf2_finish): Call do_allocate_filenum for all subsegs too, 169906 in a separate loop before subsegs are chained. 169907 1699082021-09-20 Alan Modra <amodra@gmail.com> 169909 169910 Move eelf_mipsel_haiki.c to ALL_64_EMULATION_SOURCES 169911 --enable-targets=all on a 32-bit host results in a link failure with 169912 undefined references due to elfxx-mips.c not being compiled. This 169913 patch fixes that by putting eelf_mipsel_haiki.c in the correct 169914 EMULATION_SOURCES Makefile variable. I've also added a bunch of 169915 missing file dependencies and sorted a few things so that it's easier 169916 to verify dependencies are present. 169917 169918 * Makfile.am: Add missing haiku dependencies, sort. 169919 (ALL_EMULATION_SOURCES): Sort. Move eelf_mipsel_haiku.c to.. 169920 (ALL_64_EMULATION_SOURCES): ..here. Sort. 169921 * Makfile.in: Regenerate. 169922 1699232021-09-20 GDB Administrator <gdbadmin@sourceware.org> 169924 169925 Automatic date update in version.in 169926 1699272021-09-19 H.J. Lu <hjl.tools@gmail.com> 169928 169929 elf: Don't set version info on unversioned symbols 169930 Don't set version info on unversioned symbols when seeing a hidden 169931 versioned symbol after an unversioned definition and the default 169932 versioned symbol. 169933 169934 bfd/ 169935 169936 PR ld/28348 169937 * elflink.c (elf_link_add_object_symbols): Don't set version info 169938 on unversioned symbols. 169939 169940 ld/ 169941 169942 PR ld/28348 169943 * testsuite/ld-elf/pr28348.rd: New file. 169944 * testsuite/ld-elf/pr28348.t: Likewise. 169945 * testsuite/ld-elf/pr28348a.c: Likewise. 169946 * testsuite/ld-elf/pr28348b.c: Likewise. 169947 * testsuite/ld-elf/pr28348c.c: Likewise. 169948 * testsuite/ld-elf/shared.exp: Run PR ld/28348 tests. 169949 1699502021-09-19 Mike Frysinger <vapier@gentoo.org> 169951 169952 gdb: manual: update @inforef to @xref 169953 The @inforef command is deprecated, and @xref does the samething. 169954 Also had to update the text capitalization to match current manual. 169955 Verified that info & HTML links work. 169956 1699572021-09-19 Weimin Pan <weimin.pan@oracle.com> 169958 169959 CTF: multi-CU and archive support 169960 Now gdb is capable of debugging executable, which consists of multiple 169961 compilation units (CUs) with the CTF debug info. An executable could 169962 potentially have one or more archives, which, in CTF context, contain 169963 conflicting types. 169964 169965 all changes were made in ctfread.c in which elfctf_build_psymtabs was 169966 modified to handle archives, via the ctf archive iterator and its callback 169967 build_ctf_archive_member and scan_partial_symbols was modified to scan 169968 archives, which are treated as subfiles, to build the psymtabs. 169969 169970 Also changes were made to handle CTF's data object section and function 169971 info section which now share the same format of their contents - an array 169972 of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by 169973 ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries, 169974 which is called by add_stt_obj and add_stt_func when setting up psymtabs 169975 and full symtab, respectively. 169976 1699772021-09-19 GDB Administrator <gdbadmin@sourceware.org> 169978 169979 Automatic date update in version.in 169980 1699812021-09-18 Tom de Vries <tdevries@suse.de> 169982 169983 [gdb/testsuite] Fix gdb.server/server-kill.exp with -m32 169984 When running test-case gdb.server/server-kill.exp with target board unix/-m32, 169985 I run into: 169986 ... 169987 0xf7fd6b20 in _start () from /lib/ld-linux.so.2^M 169988 (gdb) Executing on target: kill -9 13082 (timeout = 300) 169989 builtin_spawn -ignore SIGHUP kill -9 13082^M 169990 bt^M 169991 (gdb) FAIL: gdb.server/server-kill.exp: kill_pid_of=server: test_unwind_syms: bt 169992 ... 169993 169994 The test-case expects the backtrace command to trigger remote communication, 169995 which then should result in a "Remote connection closed" or similar. 169996 169997 However, no remote communication is triggered, because we hit the "Check that 169998 this frame is unwindable" case in get_prev_frame_always_1. 169999 170000 We don't hit this problem in the kill_pid_of=inferior case, because there we 170001 run to main before doing the backtrace. 170002 170003 Fix this by doing the same in the kill_pid_of=server case. 170004 170005 Tested on x86_64-linux. 170006 1700072021-09-18 Tom de Vries <tdevries@suse.de> 170008 170009 [gdb/ada] Handle artificial local symbols 170010 With current master and gcc 7.5.0/8.5.0, we have this timeout: 170011 ... 170012 (gdb) print s^M 170013 Multiple matches for s^M 170014 [0] cancel^M 170015 [1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M 170016 [2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M 170017 > FAIL: gdb.ada/interface.exp: print s (timeout) 170018 ... 170019 170020 [ The FAIL doesn't reproduce with gcc 9.3.1. This difference in 170021 behaviour bisects to gcc commit d70ba0c10de. 170022 170023 The FAIL with earlier gcc bisects to gdb commit ba8694b650b. ] 170024 170025 The FAIL is caused by gcc generating this debug info describing a named 170026 artificial variable: 170027 ... 170028 <2><1204>: Abbrev Number: 31 (DW_TAG_variable) 170029 <1205> DW_AT_name : s.14 170030 <1209> DW_AT_type : <0x1213> 170031 <120d> DW_AT_artificial : 1 170032 <120d> DW_AT_location : 5 byte block: 91 e0 7d 23 18 \ 170033 (DW_OP_fbreg: -288; DW_OP_plus_uconst: 24) 170034 ... 170035 170036 An easy way to fix this would be to simply not put named artificial variables 170037 into the symbol table. However, that causes regressions for Ada. It relies 170038 on being able to get the value from such variables, using a named reference. 170039 170040 Fix this instead by marking the symbol as artificial, and: 170041 - ignoring such symbols in ada_resolve_variable, which fixes the FAIL 170042 - ignoring such ada symbols in do_print_variable_and_value, which prevents 170043 them from showing up in "info locals" 170044 170045 Note that a fix for the latter was submitted here ( 170046 https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and 170047 this patch borrows from it. 170048 170049 Tested on x86_64-linux. 170050 170051 Co-Authored-By: Joel Brobecker <brobecker@adacore.com> 170052 170053 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180 170054 1700552021-09-18 GDB Administrator <gdbadmin@sourceware.org> 170056 170057 Automatic date update in version.in 170058 1700592021-09-17 Alan Modra <amodra@gmail.com> 170060 170061 PR28149 part 2, purge generated line info 170062 Mixing compiler generated line info with gas generated line info is 170063 generally just confusing. Also .loc directives with non-zero view 170064 fields might reference a previous .loc. It becomes a little more 170065 tricky to locate that previous .loc if there might be gas generated 170066 line info present too. Mind you, we turn off gas generation of line 170067 info on seeing compiler generated line info, so any reference back 170068 won't hit gas generated line info. At least, if the view info is 170069 sane. Unfortunately, gas needs to handle mangled source. 170070 170071 PR 28149 170072 * dwarf2dbg.c (purge_generated_debug): New function. 170073 (dwarf2_directive_filename): Call the above. 170074 (out_debug_line): Don't segfault after purging. 170075 * testsuite/gas/i386/dwarf2-line-4.d: Update expected output. 170076 * testsuite/gas/i386/dwarf4-line-1.d: Likewise. 170077 * testsuite/gas/i386/dwarf5-line-1.d: Likewise. 170078 * testsuite/gas/i386/dwarf5-line-2.d: Likewise. 170079 1700802021-09-17 Alan Modra <amodra@gmail.com> 170081 170082 PR28149, debug info with wrong file association 170083 gcc-11 and gcc-12 pass -gdwarf-5 to gas, in order to prime gas for 170084 DWARF 5 level debug info. Unfortunately it seems there are cases 170085 where the compiler does not emit a .file or .loc dwarf debug directive 170086 before any machine instructions. (Note that the .file directive 170087 typically emitted as the first line of assembly output doesn't count as 170088 a dwarf debug directive. The dwarf .file has a file number before the 170089 file name string.) 170090 170091 This patch delays allocation of file numbers for gas generated line 170092 debug info until the end of assembly, thus avoiding any clashes with 170093 compiler generated file numbers. Two fixes for test case source are 170094 necessary; A .loc can't use a file number that hasn't already been 170095 specified with .file. 170096 170097 A followup patch will remove all the gas generated line info on 170098 seeing a .file directive. 170099 170100 PR 28149 170101 * dwarf2dbg.c (num_of_auto_assigned): Delete. 170102 (current): Update initialisation. 170103 (set_or_check_view): Replace all accesses to view with u.view. 170104 (dwarf2_consume_line_info): Likewise. 170105 (dwarf2_directive_loc): Likewise. Assert that we aren't generating 170106 line info. 170107 (dwarf2_gen_line_info_1): Don't call set_or_check_view on 170108 gas generated line entries. 170109 (dwarf2_gen_line_info): Set and track filenames for gas generated 170110 line entries. Simplify generation of labels. 170111 (get_directory_table_entry): Use filename_cmp when comparing dirs. 170112 (do_allocate_filenum): New function. 170113 (dwarf2_where): Set u.filename and filenum to -1 for gas generated 170114 line entries. 170115 (dwarf2_directive_filename): Remove num_of_auto_assigned handling. 170116 (process_entries): Update view field access. Call 170117 do_allocate_filenum. 170118 * dwarf2dbg.h (struct dwarf2_line_info): Add filename field in 170119 union aliasing view. 170120 * testsuite/gas/i386/dwarf2-line-3.s: Add .file directive. 170121 * testsuite/gas/i386/dwarf2-line-4.s: Likewise. 170122 * testsuite/gas/i386/dwarf2-line-4.d: Update expected output. 170123 * testsuite/gas/i386/dwarf4-line-1.d: Likewise. 170124 * testsuite/gas/i386/dwarf5-line-1.d: Likewise. 170125 * testsuite/gas/i386/dwarf5-line-2.d: Likewise. 170126 1701272021-09-17 Alan Modra <amodra@gmail.com> 170128 170129 [GOLD] PowerPC64 support for sym+addend GOT entries 170130 Pass addends to all the GOT handling functions, plus remove some 170131 extraneous asserts. 170132 170133 PR 28192 170134 * powerpc.cc (Output_data_got_powerpc): Add addend parameter to 170135 all methods creating got entries. 170136 (Target_powerpc::Scan::local): Pass reloc addend to got handling 170137 functions, and when creating dynamic got relocations. 170138 (Target_powerpc::Scan::global): Likewise. 170139 (Target_powerpc::Relocate::relocate): Likewise. Remove extraneous 170140 assertions. 170141 1701422021-09-17 Alan Modra <amodra@gmail.com> 170143 170144 [GOLD] Got_entry::write addends 170145 This takes care of writing out GOT entries with addends. The local 170146 symbol case was already largely handled, except for passing the addend 170147 to tls_offset_for_local which might need the addend in a 170148 local_got_offset call. That's needed also in tls_offset_for_global. 170149 170150 I'm assuming here that GOT entries for function symbols won't ever 170151 have addends, and in particular that a GOT entry referencing PLT call 170152 stub code won't want an offset into the code. 170153 170154 PR 28192 170155 * output.cc (Output_data_got::Got_entry::write): Include addend 170156 in global symbol value. Pass addend to tls_offset_for_*. 170157 * powerpc.cc (Target_powerpc::do_tls_offset_for_local): Handle addend. 170158 (Target_powerpc::do_tls_offset_for_global): Likewise. 170159 * s390.cc (Target_s390::do_tls_offset_for_local): Likewise. 170160 (Target_s390::do_tls_offset_for_global): Likewise. 170161 * target.h (Target::tls_offset_for_local): Add addend param. 170162 (Target::tls_offset_for_global): Likewise. 170163 (Target::do_tls_offset_for_local): Likewise. 170164 (Target::do_tls_offset_for_global): Likewise. 170165 1701662021-09-17 Alan Modra <amodra@gmail.com> 170167 170168 [GOLD] Output_data_got create entry method addends 170169 This patch makes all the Output_data_got methods that create new 170170 entries accept an optional addend. 170171 170172 PR 28192 170173 * output.h (Output_data_got::add_global): Add optional addend 170174 parameter. Update comment. Delete overload without addend. 170175 (Output_data_got::add_global_plt): Likewise. 170176 (Output_data_got::add_global_tls): Likewise. 170177 (Output_data_got::add_global_with_rel): Likewise. 170178 (Output_data_got::add_global_pair_with_rel): Likewise. 170179 (Output_data_got::add_local_plt): Likewise. 170180 (Output_data_got::add_local_tls): Likewise. 170181 (Output_data_got::add_local_tls_pair): Likewise. 170182 (Output_data_got::reserve_local): Likewise. 170183 (Output_data_got::reserve_global): Likewise. 170184 (Output_data_got::Got_entry): Include addend in global sym 170185 constructor. Delete local sym constructor without addend. 170186 * output.cc (Output_data_got::add_global): Add addend param, 170187 pass to got handling methods. 170188 (Output_data_got::add_global_plt): Likewise. 170189 (Output_data_got::add_global_with_rel): Likewise. 170190 (Output_data_got::add_global_pair_with_rel): Likewise. 170191 (Output_data_got::add_local_plt): Likewise. 170192 (Output_data_got::add_local_tls_pair): Likewise. 170193 (Output_data_got::reserve_local): Likewise. 170194 (Output_data_got::reserve_global): Likewise. 170195 1701962021-09-17 Alan Modra <amodra@gmail.com> 170197 170198 [GOLD] Output_data_got tidy 170199 Some Output_data_got methods already have support for addends, but 170200 were implemented as separate methods. This removes unnecessary code 170201 duplication. 170202 170203 Relobj::local_has_got_offset and others there get a similar treatment. 170204 Comments are removed since it should be obvious without a comment, and 170205 the existing comments are not precisely what the code does. For 170206 example, a local_has_got_offset call without an addend does not return 170207 whether the local symbol has *a* GOT offset of type GOT_TYPE, it 170208 returns whether there is a GOT entry of type GOT_TYPE for the symbol 170209 with addend of zero. 170210 170211 PR 28192 170212 * output.h (Output_data_got::add_local): Make addend optional. 170213 (Output_data_got::add_local_with_rel): Likewise. 170214 (Output_data_got::add_local_pair_with_rel): Likewise. 170215 * output.cc (Output_data_got::add_local): Delete overload 170216 without addend. 170217 (Output_data_got::add_local_with_rel): Likewise. 170218 (Output_data_got::add_local_pair_with_rel): Likewise. 170219 * object.h (Relobj::local_has_got_offset): Make addend optional. 170220 Delete overload without addend later. Update comment. 170221 (Relobj::local_got_offset): Likewise. 170222 (Relobj::set_local_got_offset): Likewise. 170223 1702242021-09-17 Alan Modra <amodra@gmail.com> 170225 170226 [GOLD] Remove addend from Local_got_entry_key 170227 This patch removes the addend from Local_got_entry_key, which is 170228 unnecessary now that Got_offset_list has an addend. Note that it 170229 might be advantageous to keep the addend in Local_got_entry_key when 170230 linking objects containing a large number of section_sym+addend@got 170231 relocations. I opted to save some memory by removing the field but 170232 left the class there in case we might need to restore {sym,addend} 170233 lookup. That's also why this change is split out from the 170234 Got_offset_list change. 170235 170236 PR 28192 170237 * object.h (Local_got_entry_key): Delete addend_ field. 170238 Adjust constructor and methods to suit. 170239 * object.cc (Sized_relobj::do_for_all_local_got_entries): 170240 Update key. 170241 1702422021-09-17 Alan Modra <amodra@gmail.com> 170243 170244 [GOLD] Got_offset_list: addend field 170245 This is the first in a series of patches aimed at supporting GOT 170246 entries against symbol plus addend generally for PowerPC64 rather than 170247 just section symbol plus addend as gold has currently. 170248 170249 This patch adds an addend field to Got_offset_list, so that both local 170250 and global symbols can have GOT entries with addend. 170251 170252 PR 28192 170253 * object.h (Got_offset_list): Add addend_ field, init in both 170254 constructors. Adjust all accessors to suit. 170255 (Sized_relobj::do_local_has_got_offset): Adjust to suit. 170256 (Sized_relobj::do_local_got_offset): Likewise. 170257 (Sized_relobj::do_set_local_got_offset): Likewise. 170258 * symtab.h (Symbol::has_got_offset): Add optional addend param. 170259 (Symbol::got_offset, Symbol::set_got_offset): Likewise. 170260 * incremental.cc (Local_got_offset_visitor::visit): Add unused 170261 uint64_t parameter with FIXME. 170262 (Global_got_offset_visitor::visit): Add unused uint64_t parameter. 170263 1702642021-09-17 Henry Castro <hcvcastro@gmail.com> 170265 170266 Fix segfault when running ia16-elf-gdb 170267 "A problem internal to GDB has been detected, 170268 further debugging may prove unreliable." 170269 170270 Segmentation fault 170271 1702722021-09-17 Nelson Chu <nelson.chu@sifive.com> 170273 170274 RISC-V: Merged extension string tables and their version tables into one. 170275 There are two main reasons for this patch, 170276 170277 * In the past we had two extension tables, one is used to record all 170278 supported extensions in bfd/elfxx-riscv.c, another is used to get the 170279 default extension versions in gas/config/tc-riscv.c. It is hard to 170280 maintain lots of tables in different files, but in fact we can merge 170281 them into just one table. Therefore, we now define many riscv_supported_std* 170282 tables, which record names and versions for all supported extensions. 170283 We not only use these tables to initialize the riscv_ext_order, but 170284 also use them to get the default versions of extensions, and decide if 170285 the extensions should be enbaled by default. 170286 170287 * We add a new filed `default_enable' for the riscv_supported_std* tables, 170288 to decide if the extension should be enabled by default. For now if the 170289 `default_enable' field of the extension is set to EXT_DEFAULT, then we 170290 should enable the extension when the -march and elf architecture attributes 170291 are not set. In the future, I suppose the `default_enable' can be set 170292 to lots of EXT_<VENDOR>, each vendor can decide to open which extensions, 170293 when the target triple of vendor is chosen. 170294 170295 The elf/linux regression tests of riscv-gnu-toolchain are passed. 170296 170297 bfd/ 170298 * elfnn-riscv.c (cpu-riscv.h): Removed sine it is included in 170299 bfd/elfxx-riscv.h. 170300 (riscv_merge_std_ext): Updated since the field of rpe is changed. 170301 * elfxx-riscv.c (cpu-riscv.h): Removed. 170302 (riscv_implicit_subsets): Added implicit extensions for g. 170303 (struct riscv_supported_ext): Used to be riscv_ext_version. Moved 170304 from gas/config/tc-riscv.c, and added new field `default_enable' to 170305 decide if the extension should be enabled by default. 170306 (EXT_DEFAULT): Defined for `default_enable' field. 170307 (riscv_supported_std_ext): It used to return the supported standard 170308 architecture string, but now we move ext_version_table from 170309 gas/config/tc-riscv.c to here, and rename it to riscv_supported_std_ext. 170310 Currently we not only use the table to initialize riscv_ext_order, but 170311 also get the default versions of extensions, and decide if the extensions 170312 should be enbaled by default. 170313 (riscv_supported_std_z_ext): Likewise, but is used for z* extensions. 170314 (riscv_supported_std_s_ext): Likewise, but is used for s* extensions. 170315 (riscv_supported_std_h_ext): Likewise, but is used for h* extensions. 170316 (riscv_supported_std_zxm_ext): Likewise, but is used for zxm* extensions. 170317 (riscv_all_supported_ext): Includes all supported extension tables. 170318 (riscv_known_prefixed_ext): Updated. 170319 (riscv_valid_prefixed_ext): Updated. 170320 (riscv_init_ext_order): Init the riscv_ext_order table according to 170321 riscv_supported_std_ext. 170322 (riscv_get_default_ext_version): Moved from gas/config/tc-riscv.c. 170323 Get the versions of extensions from riscv_supported_std* tables. 170324 (riscv_parse_add_subset): Updated. 170325 (riscv_parse_std_ext): Updated. 170326 (riscv_set_default_arch): Set the default subset list according to 170327 the default_enable field of riscv_supported_*ext tables. 170328 (riscv_parse_subset): If the input ARCH is NULL, then we call 170329 riscv_set_default_arch to set the default subset list. 170330 * elfxx-riscv.h (cpu-riscv.h): Included. 170331 (riscv_parse_subset_t): Removed get_default_version field, and added 170332 isa_spec field to replace it. 170333 (extern riscv_supported_std_ext): Removed. 170334 gas/ 170335 * (bfd/cpu-riscv.h): Removed. 170336 (struct riscv_ext_version): Renamed and moved to bfd/elfxx-riscv.c. 170337 (ext_version_table): Likewise. 170338 (riscv_get_default_ext_version): Likewise. 170339 (ext_version_hash): Removed. 170340 (init_ext_version_hash): Removed. 170341 (riscv_set_arch): Updated since the field of rps is changed. Besides, 170342 report error when the architecture string is empty. 170343 (riscv_after_parse_args): Updated. 170344 1703452021-09-17 GDB Administrator <gdbadmin@sourceware.org> 170346 170347 Automatic date update in version.in 170348 1703492021-09-16 Tom de Vries <tdevries@suse.de> 170350 170351 [gdb/testsuite] Fix interrupted sleep in multi-threaded test-cases 170352 When running test-case gdb.threads/continue-pending-status.exp with native, I 170353 have: 170354 ... 170355 (gdb) continue^M 170356 Continuing.^M 170357 PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c 170358 ^C^M 170359 Thread 1 "continue-pendin" received signal SIGINT, Interrupt.^M 170360 [Switching to Thread 0x7ffff7fc4740 (LWP 1276)]^M 170361 0x00007ffff758e4c0 in __GI___nanosleep () at nanosleep.c:27^M 170362 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M 170363 (gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: caught interrupt 170364 ... 170365 but with target board unix/-m32, I run into: 170366 ... 170367 (gdb) continue^M 170368 Continuing.^M 170369 PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c 170370 [Thread 0xf74aeb40 (LWP 31957) exited]^M 170371 [Thread 0xf7cafb40 (LWP 31956) exited]^M 170372 [Inferior 1 (process 31952) exited normally]^M 170373 (gdb) Quit^M 170374 ... 170375 170376 The problem is that the sleep (300) call at the end of main is interrupted, 170377 which causes the inferior to exit before the ctrl-c can be send. 170378 170379 This problem is described at "Interrupted System Calls" in the docs, and the 170380 suggested solution (using a sleep loop) indeed fixes the problem. 170381 170382 Fix this instead using the more prevalent: 170383 ... 170384 alarm (300); 170385 ... 170386 while (1) sleep (1); 170387 ... 170388 which is roughly equivalent because the sleep is called at the end of main, 170389 but slightly better because it guards against hangs from the start rather than 170390 from the end of main. 170391 170392 Likewise in gdb.base/watch_thread_num.exp. 170393 170394 Likewise in gdb.btrace/enable-running.exp, but use the sleep loop there, 170395 because the sleep is not called at the end of main. 170396 170397 Tested on x86_64-linux. 170398 1703992021-09-16 Mike Frysinger <vapier@gentoo.org> 170400 170401 gdb: manual: fix werrors typo 170402 1704032021-09-16 GDB Administrator <gdbadmin@sourceware.org> 170404 170405 Automatic date update in version.in 170406 1704072021-09-15 Tom de Vries <tdevries@suse.de> 170408 170409 [gdb/testsuite] Use function_range in gdb.dwarf2/dw2-abs-hi-pc.exp 170410 When I run test-case gdb.dwarf2/dw2-abs-hi-pc.exp with gcc, we have: 170411 ... 170412 (gdb) break hello^M 170413 Breakpoint 1 at 0x4004c0: file dw2-abs-hi-pc-hello.c, line 24.^M 170414 (gdb) PASS: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello 170415 ... 170416 but with clang, I run into: 170417 ... 170418 (gdb) break hello^M 170419 Breakpoint 1 at 0x4004e4^M 170420 (gdb) FAIL: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello 170421 ... 170422 170423 The problem is that the CU and function both have an empty address range: 170424 ... 170425 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit) 170426 <108> DW_AT_name : dw2-abs-hi-pc-hello.c 170427 <123> DW_AT_low_pc : 0x4004e0 170428 <127> DW_AT_high_pc : 0x4004e0 170429 <1><12f>: Abbrev Number: 2 (DW_TAG_subprogram) 170430 <131> DW_AT_name : hello 170431 <13a> DW_AT_low_pc : 0x4004e0 170432 <13e> DW_AT_high_pc : 0x4004e0 170433 ... 170434 170435 The address ranges are set like this in dw2-abs-hi-pc-hello-dbg.S: 170436 ... 170437 .4byte .hello_start /* DW_AT_low_pc */ 170438 .4byte .hello_end /* DW_AT_high_pc */ 170439 ... 170440 where the labels refer to dw2-abs-hi-pc-hello.c: 170441 ... 170442 extern int v; 170443 170444 asm (".hello_start: .globl .hello_start\n"); 170445 void 170446 hello (void) 170447 { 170448 asm (".hello0: .globl .hello0\n"); 170449 v++; 170450 asm (".hello1: .globl .hello1\n"); 170451 } 170452 asm (".hello_end: .globl .hello_end\n"); 170453 ... 170454 170455 Using asm labels in global scope is a known source of problems, as explained 170456 in the comment of proc function_range in gdb/testsuite/lib/dwarf.exp. 170457 170458 Fix this by using function_range instead. 170459 170460 Tested on x86_64-linux with gcc and clang-7 and clang-12. 170461 1704622021-09-15 Claudiu Zissulescu <claziss@synopsys.com> 170463 170464 arc: Fix got-weak linker test 170465 Use regular expressions to fix the got-weak linker test. 170466 170467 ld/ 170468 * testsuite/got-weak.d: Update test. 170469 1704702021-09-15 Andrew Burgess <andrew.burgess@embecosm.com> 170471 170472 bfd: fix incorrect type used in sizeof 170473 Noticed in passing that we used 'sizeof (char **)' when calculating 170474 the size of a list of 'char *' pointers. Of course, this isn't really 170475 going to make a difference anywhere, but we may as well be correct. 170476 170477 There should be no user visible changes after this commit. 170478 170479 bfd/ChangeLog: 170480 170481 * archures.c (bfd_arch_list): Use 'char *' instead of 'char **' 170482 when calculating space for a string list. 170483 1704842021-09-15 Tom de Vries <tdevries@suse.de> 170485 170486 [gdb/doc] Fix typo in maint selftest entry 170487 Fix typo "will by" -> "will be". 170488 1704892021-09-15 Tom de Vries <tdevries@suse.de> 170490 170491 [bfd] Ensure unique printable names for bfd archs 170492 Remove duplicate entry in bfd_ft32_arch and bfd_rx_arch. 170493 170494 Fix printable name for bfd_mach_n1: "nh1" -> "n1". 170495 170496 PR 28336 170497 * cpu-ft32.c (arch_info_struct): Remove "ft32" entry. 170498 * cpu-rx.c (arch_info_struct): Remove "rx" entry. 170499 * cpu-nds32.c (bfd_nds32_arch): Fix printable name for bfd_mach_n1 170500 entry. 170501 1705022021-09-15 Alan Modra <amodra@gmail.com> 170503 170504 PR28328, dlltool ice 170505 PR 28328 170506 * archive.c (bfd_ar_hdr_from_filesystem): Don't use bfd_set_input_error 170507 here, our caller will do that. 170508 1705092021-09-15 GDB Administrator <gdbadmin@sourceware.org> 170510 170511 Automatic date update in version.in 170512 1705132021-09-14 Tom de Vries <tdevries@suse.de> 170514 170515 [gdb/testsuite] Fix gdb_load_no_complaints with gnu-debuglink 170516 When running test-case gdb.dwarf2/dw2-ranges-psym-warning.exp with target 170517 board gnu-debuglink I run into: 170518 ... 170519 (gdb) file dw2-ranges-psym-warning^M 170520 Reading symbols from dw2-ranges-psym-warning...^M 170521 Reading symbols from .debug/dw2-ranges-psym-warning.debug...^M 170522 (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: No complaints 170523 ... 170524 170525 Fix this by updating the regexp in gdb_load_no_complaints. 170526 170527 Tested on x86_64-linux. 170528 1705292021-09-14 Tom de Vries <tdevries@suse.de> 170530 170531 [gdb/symtab] Fix function range handling in psymtabs 170532 Consider the test-case from this patch. 170533 170534 We run into: 170535 ... 170536 (gdb) PASS: gdb.dwarf2/dw2-ranges-psym-warning.exp: continue 170537 bt^M 170538 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170539 ^M 170540 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170541 ^M 170542 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170543 ^M 170544 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170545 ^M 170546 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170547 ^M 170548 warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M 170549 ^M 170550 read in psymtab, but not in symtab.)^M 170551 ^M 170552 )^M 170553 (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: bt 170554 ... 170555 170556 This happens as follows. 170557 170558 The function foo: 170559 ... 170560 <1><31>: Abbrev Number: 4 (DW_TAG_subprogram) 170561 <33> DW_AT_name : foo 170562 <37> DW_AT_ranges : 0x0 170563 ... 170564 has these ranges: 170565 ... 170566 00000000 00000000004004c1 00000000004004d2 170567 00000000 00000000004004ae 00000000004004af 170568 00000000 <End of list> 170569 ... 170570 which have a hole at at [0x4004af,0x4004c1). 170571 170572 However, the address map of the partial symtabs incorrectly maps addresses 170573 in the hole (such as 0x4004b6 in the backtrace) to the foo CU. 170574 170575 The address map of the full symbol table of the foo CU however does not 170576 contain the addresses in the hole, which is what the warning / internal error 170577 complains about. 170578 170579 Fix this by making sure that ranges of functions are read correctly. 170580 170581 The patch adds a bit to struct partial_die_info, in this hole (shown for 170582 x86_64-linux): 170583 ... 170584 /* 11: 7 | 4 */ unsigned int canonical_name : 1; 170585 /* XXX 4-byte hole */ 170586 /* 16 | 8 */ const char *raw_name; 170587 ... 170588 So there's no increase in size for 64-bit, but AFAIU there will be an increase 170589 for 32-bit. 170590 170591 Tested on x86_64-linux. 170592 170593 gdb/ChangeLog: 170594 170595 2021-08-10 Tom de Vries <tdevries@suse.de> 170596 170597 PR symtab/28200 170598 * dwarf2/read.c (struct partial_die_info): Add has_range_info and 170599 range_offset field. 170600 (add_partial_subprogram): Handle pdi->has_range_info. 170601 (partial_die_info::read): Set pdi->has_range_info. 170602 170603 gdb/testsuite/ChangeLog: 170604 170605 2021-08-10 Tom de Vries <tdevries@suse.de> 170606 170607 PR symtab/28200 170608 * gdb.dwarf2/dw2-ranges-psym-warning-main.c: New test. 170609 * gdb.dwarf2/dw2-ranges-psym-warning.c: New test. 170610 * gdb.dwarf2/dw2-ranges-psym-warning.exp: New file. 170611 1706122021-09-14 Tom de Vries <tdevries@suse.de> 170613 170614 [gdb/symtab] Fix CU list in .debug_names for dummy CUs 170615 With current trunk and target board cc-with-debug-names we have: 170616 ... 170617 (gdb) file dw2-ranges-psym^M 170618 Reading symbols from dw2-ranges-psym...^M 170619 warning: Section .debug_names in dw2-ranges-psym has abbreviation_table of \ 170620 size 1 vs. written as 28, ignoring .debug_names.^M 170621 (gdb) set complaints 0^M 170622 (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints 170623 ... 170624 170625 The executable has 8 compilation units: 170626 ... 170627 $ readelf -wi dw2-ranges-psym | grep @ 170628 Compilation Unit @ offset 0x0: 170629 Compilation Unit @ offset 0x2e: 170630 Compilation Unit @ offset 0xa5: 170631 Compilation Unit @ offset 0xc7: 170632 Compilation Unit @ offset 0xd2: 170633 Compilation Unit @ offset 0x145: 170634 Compilation Unit @ offset 0x150: 170635 Compilation Unit @ offset 0x308: 170636 ... 170637 of which the ones at 0xc7 and 0x145 are dummy CUs (that is, they do not 170638 contain a single DIE), which were added by recent commit 5ef670d81fd 170639 "[gdb/testsuite] Add dummy start and end CUs in dwarf assembly". 170640 170641 The .debug_names section contains this CU table: 170642 ... 170643 [ 0] 0x0 170644 [ 1] 0x2e 170645 [ 2] 0xa5 170646 [ 3] 0xd2 170647 [ 4] 0x150 170648 [ 5] 0x308 170649 [ 6] 0x1 170650 [ 7] 0x0 170651 ... 170652 The last two entries are incorrect, and the entries for the dummy CUs are 170653 missing. 170654 170655 The last two entries are incorrect because here in write_debug_names we write 170656 the dimension of the CU list as 8: 170657 ... 170658 /* comp_unit_count - The number of CUs in the CU list. */ 170659 header.append_uint (4, dwarf5_byte_order, 170660 per_objfile->per_bfd->all_comp_units.size () 170661 - per_objfile->per_bfd->tu_stats.nr_tus); 170662 ... 170663 while the actual dimension of the CU list is 6. 170664 170665 The discrepancy is caused by this code which skips the dummy CUs: 170666 ... 170667 for (int i = 0; i < per_objfile->per_bfd->all_comp_units.size (); ++i) 170668 { 170669 ... 170670 /* CU of a shared file from 'dwz -m' may be unused by this main 170671 file. It may be referenced from a local scope but in such 170672 case it does not need to be present in .debug_names. */ 170673 if (psymtab == NULL) 170674 continue; 170675 ... 170676 because they have a null partial symtab. 170677 170678 We can fix this by writing the actual dimension of the CU list, but that still 170679 leaves the dummy CUs out of the CU list. The purpose of having these is to 170680 delimit the end of preceding CUs. 170681 170682 So, fix this by: 170683 - removing the code that skips the dummy CUs (note that the same change 170684 was done for .gdb_index in commit efba5c2319d '[gdb/symtab] Handle PU 170685 without import in "save gdb-index"'. 170686 - verifying that all units are represented in the CU/TU lists 170687 - using the actual CU list size when writing the dimension of the CU list 170688 (and likewise for the TU list). 170689 170690 Tested on x86_64-linux with native and target board cc-with-debug-names. 170691 170692 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28261 170693 1706942021-09-14 Tom de Vries <tdevries@suse.de> 170695 170696 [gdb/testsuite] Generate .debug_aranges in gdb.dwarf2/locexpr-data-member-location.exp 170697 When running test-case gdb.dwarf2/locexpr-data-member-location.exp with target 170698 board cc-with-debug-names, all tests pass but we run into PR28261: 170699 ... 170700 (gdb) run ^M 170701 Starting program: locexpr-data-member-location ^M 170702 warning: Section .debug_names in locexpr-data-member-location-lib.so has \ 170703 abbreviation_table of size 1 vs. written as 37, ignoring .debug_names.^M 170704 ... 170705 170706 Using a patch that fixes PR28261, the warning is gone, but we run into: 170707 ... 170708 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo 170709 ... 170710 170711 This is due a missing .debug_aranges contribution for the CU declared in 170712 gdb.dwarf2/locexpr-data-member-location.exp. 170713 170714 Fix this by adding the missing .debug_aranges contribution. 170715 170716 Tested on x86_64-linux. 170717 1707182021-09-14 Claudiu Zissulescu <claziss@synopsys.com> 170719 170720 arc: Fix potential invalid pointer access when fixing got symbols. 170721 When statically linking, it can arrive to an undefined weak symbol of 170722 which its value cannot be determined. However, we are having pieces of 170723 code which doesn't take this situation into account, leading to access 170724 a structure which may not be initialized. Fix this situation and add a 170725 test. 170726 170727 bfd/ 170728 xxxx-xx-xx Cupertino Miranda <cmiranda@synopsys.com> 170729 Claudiu Zissulescu <claziss@synopsys.com> 170730 170731 * arc-got.h (arc_static_sym_data): New structure. 170732 (get_static_sym_data): New function. 170733 (relocate_fix_got_relocs_for_got_info): Move the computation fo 170734 symbol value and section to above introduced function, and use 170735 this new function. 170736 170737 ld/testsuite/ 170738 xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> 170739 170740 * ld-arc/got-weak.d: New file. 170741 * ld-arc/got-weak.s: Likewise. 170742 170743 170744 fix 170745 1707462021-09-14 Mike Frysinger <vapier@gentoo.org> 170747 170748 sim: bfin: add support for SDL2 170749 This probably should have been ported long ago, but better late than 170750 never. We keep support for both versions for now since both projects 170751 tend to have long lifetimes. Maybe consider dropping SDL1 in another 170752 ten years. 170753 1707542021-09-14 GDB Administrator <gdbadmin@sourceware.org> 170755 170756 Automatic date update in version.in 170757 1707582021-09-14 Tom Tromey <tom@tromey.com> 170759 170760 Remove use of __CYGNUSCLIB__ 170761 I found a check of __CYGNUSCLIB__ in dbxread.c. I think this is dead 170762 code. This patch removes it. 170763 1707642021-09-13 Tom de Vries <tdevries@suse.de> 170765 170766 [gdb/testsuite] Check for valid test name 170767 When running gdb.base/batch-exit-status.exp I noticed that the test name 170768 contains a newline: 170769 ... 170770 PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M 170771 : No such file or directory\.: [lindex $result 2] == 0 170772 ... 170773 170774 Check for this in ::CheckTestNames::check, such that we have a warning: 170775 ... 170776 PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M 170777 : No such file or directory\.: [lindex $result 2] == 0 170778 WARNING: Newline in test name 170779 ... 170780 170781 Tested on x86_64-linux. 170782 1707832021-09-13 Tom de Vries <tdevries@suse.de> 170784 170785 [gdb/tdep] Fix exec check in gdb_print_insn_arm 170786 With a gdb build with --enable-targets=all we run into a KFAIL: 170787 ... 170788 KFAIL: gdb.gdb/unittest.exp: executable loaded: maintenance selftest, \ 170789 failed none (PRMS: gdb/27891) 170790 ... 170791 due to: 170792 ... 170793 Running selftest print_one_insn.^M 170794 Self test failed: arch armv8.1-m.main: self-test failed at \ 170795 disasm-selftests.c:165^M 170796 ... 170797 170798 The test fails because we expect disassembling of one arm insn to consume 4 170799 bytes and produce (using verbose = true in disasm-selftests.c): 170800 ... 170801 arm mov r0, #0 170802 ... 170803 but instead the disassembler uses thumb mode and only consumes 2 170804 bytes and produces: 170805 ... 170806 arm movs r0, r0 170807 ... 170808 170809 The failure does not show up in the "no executable loaded" variant because 170810 this code in gdb_print_insn_arm isn't triggered: 170811 ... 170812 if (current_program_space->exec_bfd () != NULL) 170813 info->flags |= USER_SPECIFIED_MACHINE_TYPE; 170814 ... 170815 and consequently we do this in print_insn: 170816 ... 170817 if ((info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0) 170818 info->mach = bfd_mach_arm_unknown; 170819 ... 170820 and don't set force_thumb to true in select_arm_features. 170821 170822 The code in gdb_print_insn_arm makes the assumption that the disassembly 170823 architecture matches the exec architecture, which in this case is incorrect, 170824 because the exec architecture is x86_64, and the disassembly architecture is 170825 armv8.1-m.main. Fix that by explicitly checking it: 170826 ... 170827 if (current_program_space->exec_bfd () != NULL 170828 && (current_program_space->exec_bfd ()->arch_info 170829 == gdbarch_bfd_arch_info (gdbarch))) 170830 ... 170831 170832 This fixes the print_one_insn failure, so remove the KFAIL. 170833 170834 Tested on x86_64-linux. 170835 170836 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27891 170837 1708382021-09-13 Tom de Vries <tdevries@suse.de> 170839 170840 [gdb/tdep] Reset force_thumb in parse_arm_disassembler_options 170841 With a gdb build with --enable-targets=all, we have 2 arch-specific failures 170842 in selftest print_one_insn: 170843 ... 170844 $ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \ 170845 | grep "Self test failed: arch " 170846 Self test failed: arch armv8.1-m.main: self-test failed at \ 170847 disasm-selftests.c:165 170848 Self test failed: arch arm_any: self-test failed at disasm-selftests.c:165 170849 $ 170850 ... 170851 170852 During the first failed test, force_thumb is set to true, and remains so until 170853 and during the second test, which causes the second failure. 170854 170855 Fix this by resetting force_thumb to false in parse_arm_disassembler_options, 170856 such that we get just one failure: 170857 ... 170858 $ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \ 170859 | grep "Self test failed: arch " 170860 Self test failed: arch armv8.1-m.main: self-test failed at \ 170861 disasm-selftests.c:165 170862 $ 170863 ... 170864 170865 Tested on x86_64-linux. 170866 1708672021-09-13 Tom Tromey <tromey@adacore.com> 170868 170869 Fix no-Python build 170870 A build without Python will currently fail, because 170871 selftests::test_python uses gdb_python_initialized, which is only 170872 conditionally defined. 170873 170874 This patch fixes the build by making test_python also be conditionally 170875 defined. I chose this approach because the selftest will fail if 170876 Python is not enabled, so it didn't seem useful to leave it defined. 170877 1708782021-09-13 Nelson Chu <nelson.chu@sifive.com> 170879 170880 RISC-V: Update the assembler insn testcase. 170881 Since the 0x57 is preserved for the vadd.vv instruction in the integration 170882 branch, remove it to make sure the testcase can work. 170883 170884 gas/ 170885 * testsuite/gas/riscv/insn.d: Remove 0x57 since it is preserved 170886 for vadd.vv instruction. 170887 * testsuite/gas/riscv/insn.s: Likewise. 170888 1708892021-09-13 Jan Beulich <jbeulich@suse.com> 170890 170891 MIPS: don't use get_symbol_name() for section parsing. With s_change_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result. 170892 gas * config/tc-mips.c (s_change_section): Use obj_elf_section_name to 170893 parse the section name. 170894 170895 ia64: don't use get_symbol_name() for section parsing. With cross_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result. 170896 gas * config/tc-ia64.c (cross_section): Use obj_elf_section_name to 170897 parse the section name. 170898 1708992021-09-13 Tom de Vries <tdevries@suse.de> 170900 170901 [gdb/testsuite] Fix gdb.gdb/selftest.exp 170902 With a gdb build with CFLAGS "-O2 -g -flto=auto", I run into: 170903 ... 170904 #7 gdb_main (args=0x7fffffffd220) at src/gdb/main.c:1368^M 170905 #8 main (argc=<optimized out>, argv=<optimized out>) at src/gdb/gdb.c:32^M 170906 (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler 170907 ... 170908 which means that this regexp in proc test_with_self fails: 170909 ... 170910 -re "#0.*(read|poll).*in main \\(.*\\) at .*gdb\\.c.*$gdb_prompt $" { 170911 ... 170912 170913 The problem is that gdb_main has been inlined into main, and consequently the 170914 backtrace uses: 170915 ... 170916 #x <fn> ... 170917 ... 170918 instead of 170919 ... 170920 #x <address> in <fn> ... 170921 ... 170922 170923 Fix this by updating the regexp to not require "in" before " main". 170924 170925 Tested on x86_64-linux. 170926 1709272021-09-13 Alan Modra <amodra@gmail.com> 170928 170929 Re: Deprecate a.out support for NetBSD targets 170930 * config.bfd: Correct m68-*-*bsd* obsolete target match. 170931 1709322021-09-13 Tom de Vries <tdevries@suse.de> 170933 170934 [gdb/testsuite] Fix test name in gdb.base/batch-exit-status.exp 170935 When running gdb.base/batch-exit-status.exp I noticed that the test name 170936 contains a newline: 170937 ... 170938 PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M 170939 : No such file or directory\.: [lindex $result 2] == 0 170940 ... 170941 170942 The mistake is that I passed an output regexp argument to a parameter 170943 interpreted as testname prefix. Fix this by passing a testname prefix 170944 instead. 170945 170946 Add support for checking output, to be able to handle the output regexp 170947 argument. 170948 170949 Tested on x86_64-linux. 170950 1709512021-09-13 GDB Administrator <gdbadmin@sourceware.org> 170952 170953 Automatic date update in version.in 170954 1709552021-09-12 Tom de Vries <tdevries@suse.de> 170956 170957 [gdb/testsuite] Set sysroot earlier in local-board.exp 170958 When running test-case gdb.base/batch-exit-status.exp for native, it passes. 170959 But with target board cc-with-debug-names, we run into (added missing double 170960 quotes for clarity): 170961 ... 170962 builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ 170963 -data-directory $build/gdb/testsuite/../data-directory \ 170964 -iex "set height 0" -iex "set width 0" -ex "set sysroot" -batch ""^M 170965 : No such file or directory.^M 170966 PASS: gdb.base/batch-exit-status.exp: \ 170967 : No such file or directory\.: [lindex $result 2] == 0 170968 FAIL: gdb.base/batch-exit-status.exp: \ 170969 : No such file or directory\.: [lindex $result 3] == $expect_status 170970 ... 170971 170972 The difference between the passing and failing case is that with native we 170973 have (leaving out set height/width for brevity): 170974 ... 170975 $ gdb -batch ""; echo $? 170976 : No such file or directory. 170977 1 170978 ... 170979 and with target board cc-with-debug-names: 170980 ... 170981 $ gdb -ex "set sysroot" -batch ""; echo $? 170982 : No such file or directory. 170983 0 170984 ... 170985 170986 The difference is expected. GDB returns the exit status of the last executed 170987 command. In the former case that's 'file ""', which fails. In the latter case, 170988 that's 'set sysroot', which succeeds. 170989 170990 Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such 170991 that we have the expected: 170992 ... 170993 $ gdb -iex "set sysroot" -batch ""; echo $? 170994 : No such file or directory. 170995 1 170996 ... 170997 170998 Tested on x86_64-linux. 170999 1710002021-09-12 GDB Administrator <gdbadmin@sourceware.org> 171001 171002 Automatic date update in version.in 171003 1710042021-09-11 Mike Frysinger <vapier@gentoo.org> 171005 171006 sim: run: change help short option to -h 171007 It's unclear why -H was picked over the more standard -h, but since 171008 -h is still not used, just change -H to -h to match pretty much every 171009 other tool in the sourceware tree. 171010 1710112021-09-11 GDB Administrator <gdbadmin@sourceware.org> 171012 171013 Automatic date update in version.in 171014 1710152021-09-10 Tom de Vries <tdevries@suse.de> 171016 171017 [gdb/testsuite] Reimplement gdb.gdb/python-selftest.exp as unittest 171018 The test-case gdb.gdb/python-selftest.exp: 171019 - patches the gdb_python_initialized variable in gdb to 0 171020 - checks that the output of a python command is "Python not initialized" 171021 171022 Reimplement gdb.gdb/python-selftest.exp as unittest, using: 171023 - execute_command_to_string to capture the output 171024 - try/catch to catch the "Python not initialized" exception. 171025 171026 Tested on x86_64-linux. 171027 1710282021-09-10 Tom de Vries <tdevries@suse.de> 171029 171030 [gdb/testsuite] Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp 171031 Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp by naming commands more 171032 uniquely. 171033 1710342021-09-10 Tom de Vries <tdevries@suse.de> 171035 171036 [gdb/testsuite] Fix DUPLICATE in gdb.base/skip-solib.exp 171037 Fix DUPLICATE in gdb.base/skip-solib.exp by using with_test_prefix. 171038 171039 Also fix indentation style and long lines, remove outdated question/answer 171040 bits, and use multi_line. 171041 1710422021-09-10 Tom de Vries <tdevries@suse.de> 171043 171044 [gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_test 171045 The documentation of mi_gdb_test states that the command, pattern and message 171046 arguments are mandatory: 171047 ... 171048 # mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb; 171049 # test the result. 171050 ... 171051 171052 However, this is not checked, and when mi_gdb_test is called with less than 3 171053 arguments, it passes or fails silently. 171054 171055 Fix this by using the following semantics: 171056 - if there are 1 or 2 arguments, use the command as the message. 171057 - if there is 1 argument, use ".*" as the pattern. 171058 - if there are no or too much arguments, error out. 171059 171060 Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as 171061 message. Fix a few other trivial-looking FAILs. 171062 171063 There are 11 less trivial-looking FAILs left in gdb.mi in test-cases: 171064 - mi-nsmoribund.exp 171065 - mi-breakpoint-changed.exp 171066 - mi-break.exp. 171067 171068 Tested on x86_64-linux. 171069 1710702021-09-10 Tom de Vries <tdevries@suse.de> 171071 171072 [gdb/testsuite] Add string_list_to_regexp 171073 A regexp pattern with escapes like this is hard to read: 171074 ... 171075 set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done" 171076 ... 171077 171078 We can make it more readable by spacing out parts (which allows us to also use 171079 the curly braces where that's convenient): 171080 ... 171081 set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"] 171082 set re [join $re ""] 171083 ... 171084 or by using string_to_regexp: 171085 ... 171086 set re [list \ 171087 [string_to_regexp {~"$}] \ 171088 $decimal \ 171089 [string_to_regexp " = 1\\n\"\r\n^done"]] 171090 set re [join $re ""] 171091 ... 171092 Note: we have to avoid applying string_to_list to decimal, which is already a 171093 regexp. 171094 171095 Add a proc string_list_to_regexp to make it easy to do both: 171096 ... 171097 set re [list \ 171098 [string_list_to_regexp ~ {"} $] \ 171099 $decimal \ 171100 [string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]] 171101 ... 171102 171103 Also add a test-case gdb.testsuite/string_to_regexp.exp. 171104 1711052021-09-10 Tom de Vries <tdevries@suse.de> 171106 171107 [gdb/testsuite] Handle unrecognized command line option in gdb_compile_test 171108 When running the gdb testsuite with gnatmake-4.8, I get many fails of the 171109 following form: 171110 ... 171111 gcc: error: unrecognized command line option '-fgnat-encodings=all'^M 171112 gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M 171113 compiler exited with status 1 171114 compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb 171115 gcc: error: unrecognized command line option '-fgnat-encodings=all' 171116 gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error 171117 FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb 171118 ... 171119 171120 Fix this by marking the test unsupported instead, such that we have: 171121 ... 171122 UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \ 171123 (unsupported option '-fgnat-encodings=all') 171124 ... 171125 171126 Tested on x86_64-linux. 171127 1711282021-09-10 Alan Modra <amodra@gmail.com> 171129 171130 PowerPC, sanity check r_offset in relocate_section 171131 * elf32-ppc.c (offset_in_range): New function. 171132 (ppc_elf_vle_split16): Sanity check r_offset before accessing 171133 section contents. Return status. 171134 (ppc_elf_relocate_section): Sanity check r_offset before 171135 accessing section contents. Don't segfault on NULL howto. 171136 171137 Re: gas: Use the directory name in .file 0 171138 PR gas/28266 171139 * testsuite/gas/elf/dwarf-5-file0-2.s: Use %object rather than 171140 @object, .4byte instead of .long, and .asciz instead of .string. 171141 1711422021-09-10 Mike Frysinger <vapier@gentoo.org> 171143 171144 etc: switch to automake 171145 There's no content in here currently, so switching to automake is 171146 pretty easy with a stub file. 171147 171148 etc: rename configure.in to configure.ac 171149 The .in name has been deprecated for a long time in favor of .ac. 171150 1711512021-09-10 H.J. Lu <hjl.tools@gmail.com> 171152 171153 gas: Use the directory name in .file 0 171154 DWARF5 allows .file 0 to take an optional directory name. Set the entry 171155 0 of the directory table to the directory name in .file 0. 171156 171157 PR gas/28266 171158 * dwarf2dbg.c (get_directory_table_entry): Add an argument for 171159 the directory name in .file 0 and use it, instead of PWD. 171160 (allocate_filenum): Pass NULL to get_directory_table_entry. 171161 (allocate_filename_to_slot): Pass the incoming dirname to 171162 get_directory_table_entry. 171163 * testsuite/gas/elf/dwarf-5-file0-2.d: New file. 171164 * testsuite/gas/elf/dwarf-5-file0-2.s: Likewise. 171165 * testsuite/gas/elf/elf.exp: Run dwarf-5-file0-2. 171166 1711672021-09-10 GDB Administrator <gdbadmin@sourceware.org> 171168 171169 Automatic date update in version.in 171170 1711712021-09-09 Yoshinori Sato <ysato@users.sourceforge.jp> 171172 171173 gdb: Enable target rx-*-*linux. 171174 I added rx-*-linux in binutils few yaers ago. 171175 But missing this changes, 171176 1711772021-09-09 Tom de Vries <tdevries@suse.de> 171178 171179 [gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip 171180 On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into: 171181 ... 171182 (gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile 171183 First line of eu-unstrip: \ 171184 0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe] 171185 FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id 171186 ... 171187 171188 The test expects an actual file name instead of '[exe]', but that only got 171189 introduced with eu-unstrip 0.161. Before it printed '[exe]' or '[pie]'. 171190 171191 Fix this by updating the regexp. 171192 171193 Tested on x86_64-linux. 171194 1711952021-09-09 Tom de Vries <tdevries@suse.de> 171196 171197 [gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp 171198 I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8: 171199 ... 171200 FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \ 171201 (unexpected output) 171202 ... 171203 due to function f2 instead of f3 being listed. 171204 171205 AFAICT, this is caused by a difference in debug info: 171206 ... 171207 $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ 171208 | egrep "DW_AT_name.*: f[1-3]" 171209 <72> DW_AT_name : f1 171210 <a1> DW_AT_name : f2 171211 <d0> DW_AT_name : f3 171212 ... 171213 vs: 171214 ... 171215 $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \ 171216 | egrep "DW_AT_name.*: f[1-3]" 171217 <f4> DW_AT_name : f3 171218 <123> DW_AT_name : f2 171219 <152> DW_AT_name : f1 171220 ... 171221 and the command documentation does not mention an imposed order, so fix this 171222 by allowing f2 as well. 171223 171224 Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re 171225 variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern 171226 overall. 171227 171228 Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix 171229 by updating the regexp. 171230 171231 Then I ran with clang and found another FAIL, fix by updating the regexp. 171232 171233 Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and 171234 clang-12.0.1. 171235 1712362021-09-09 Tom de Vries <tdevries@suse.de> 171237 171238 [gdb/testsuite] Reimplement gdb.gdb/complaints.exp as unittest 171239 When building gdb with "-Wall -O2 -g -flto=auto", I run into: 171240 ... 171241 (gdb) call clear_complaints()^M 171242 No symbol "clear_complaints" in current context.^M 171243 (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints 171244 ... 171245 171246 The problem is that lto has optimized away the clear_complaints function 171247 and consequently the selftest doesn't work. 171248 171249 Fix this by reimplementing the selftest as a unit test. 171250 171251 Factor out two new functions: 171252 - void 171253 execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn); 171254 - std::string 171255 execute_fn_to_string (std::function<void(void)> fn, bool term_out); 171256 and use the latter to capture the complaints output. 171257 171258 Tested on x86_64-linux. 171259 1712602021-09-09 Andrew Burgess <andrew.burgess@embecosm.com> 171261 171262 gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITER 171263 Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as 171264 part of the tp_flags field when defining a new object type. This flag 171265 is not defined in Python 3 and so we define it to 0 in 171266 python-internal.h (when IS_PY3K is defined). 171267 171268 The meaning of this flag is that the object has the fields tp_iter and 171269 tp_iternext. Note the use of "has" here, the flag says nothing about 171270 the values in those fields, just that the type object has the fields. 171271 171272 In early versions of Python 2 these fields were no part of the 171273 PyTypeObject struct, they were added in version 2.2 (see 171274 https://docs.python.org/release/2.3/api/type-structs.html). And so, 171275 there could be a some code compiled out there which has a PyTypeObject 171276 structure within it that doesn't even have the tp_iter and tp_iternext 171277 fields, attempting to access these fields would be undefined 171278 behaviour. 171279 171280 And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is 171281 present then Python is free to access the tp_iter and tp_iternext 171282 fields. 171283 171284 If we consider GDB then we always assume that the tp_iter and 171285 tp_iternext fields are part of PyTypeObject. If someone was crazy 171286 enough to try and compile GDB against Python 2.1 then we'd get lots of 171287 build errors saying that we were passing too many fields when 171288 initializing PyTypeObject structures. And so, I claim, we can be sure 171289 that GDB will always be compiled with a version of Python that has the 171290 tp_iter and tp_iternext fields in PyTypeObject. 171291 171292 Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each 171293 time additional fields are added to PyTypeObject a new Py_TPFLAGS_* 171294 flag would be defined to indicate whether those flags are present or 171295 not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And 171296 so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag 171297 includes Py_TPFLAGS_HAVE_ITER (see 171298 https://docs.python.org/2.7/c-api/typeobj.html). 171299 171300 In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all 171301 objects we define. 171302 171303 And so, in this commit, I propose to remove all uses of 171304 Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed. 171305 171306 There should be no user visible changes after this commit. 171307 1713082021-09-09 Mike Frysinger <vapier@gentoo.org> 171309 171310 sim: accept -EB/-EL short options 171311 Many GNU tools accept -EB/-EL as short options for selecting big & 171312 little endian modes. While the sim has an -E option, it requires 171313 spelling out "big" and "little". Adding support for -EB & -EL is 171314 thus quite trivial, so lets round it out to be less annoying. 171315 171316 sim: ppc: drop support for std-config.h overrides 171317 Only the ppc arch supports this kind of source file override logic. 171318 All the others expose knobs via configure flags, and for some of 171319 these, the ppc code does as well. For others, it doesn't make sense 171320 to ever change them. Since it's unlikely anyone is using this, drop 171321 it all to simplify the code (and to get us a little closer to the 171322 common sim code). 171323 171324 sim: ppc: enable use of gnulib 171325 All other sim arches are using this now, so finish up the logic in 171326 the ppc arch to enable gnulib usage here too. 171327 171328 sim: drop old O_NDELAY & FNBLOCK support 171329 We use these older names inconsistently in the sim codebase, and time 171330 has moved on long ago, so drop support for these non-standard names. 171331 POSIX provides O_NONBLOCK for us, so use it everywhere. 171332 1713332021-09-09 Mike Frysinger <vapier@gentoo.org> 171334 171335 sim: dv-sockser: enable for mingw targets too 171336 We have enough functionality from gnulib now to build sockser on 171337 all platforms. 171338 171339 Non-blocking I/O is supported when F_GETFL/F_SETFL are unavailable, 171340 but we can address that in a follow up commit. This mirrors what 171341 is done in other places in the sim already. 171342 1713432021-09-09 Mike Frysinger <vapier@gentoo.org> 171344 171345 sim: cgen: workaround Windows VOID define 171346 The cgen framework provides a "VOID" type for code to use, but this 171347 defines ends up conflicting with the standard Windows VOID define. 171348 Since they actually define to the same thing ("void"), undef it here 171349 to fix the Windows build. 171350 171351 We might want to reconsider the need for "VOID" in cgen, but that 171352 will take larger discussion & coordination with the cgen project. 171353 1713542021-09-09 Mike Frysinger <vapier@gentoo.org> 171355 171356 sim: dv-sockser: move sim-main.h include after system includes 171357 The sim-main.h header is a bit of a dumping ground. Every arch can 171358 (and many do) define all sorts of weird & common names that end up 171359 conflicting with system headers. So including it before the system 171360 headers sets us up for pain. v850 is a good example of this -- when 171361 building for mingw, we see weird failures: 171362 171363 $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/v850/../common/dv-sockser.c 171364 In file included from ../../../../sim/v850/sim-main.h:11, 171365 from ../../../../sim/v850/../common/dv-sockser.c:24: 171366 ../../../../sim/v850/../common/sim-base.h:97:32: error: expected ')' before '->' token 171367 97 | # define STATE_CPU(sd, n) ((sd)->cpu[0]) 171368 | ^~ 171369 171370 While gcc is unhelpful at first, running it through the preprocessor 171371 by hand shows more details: 171372 171373 $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/v850/../common/dv-sockser.c 171374 $ i686-w64-mingw32-gcc -c dv-sockser.i 171375 In file included from /usr/i686-w64-mingw32/usr/include/minwindef.h:163, 171376 from /usr/i686-w64-mingw32/usr/include/windef.h:9, 171377 from /usr/i686-w64-mingw32/usr/include/windows.h:69, 171378 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, 171379 from ../../gnulib/import/sys/socket.h:684, 171380 from ../../gnulib/import/netinet/in.h:43, 171381 from ../../../../sim/v850/../common/dv-sockser.c:39: 171382 /usr/i686-w64-mingw32/usr/include/winnt.h:4803:25: error: expected ')' before '->' token 171383 4803 | DWORD State; 171384 | ^ 171385 | ) 171386 171387 This is because v850 sets up this common name: 171388 171389 All of this needs cleaning up someday, but since the dv-sockser code 171390 definitely should be fixed in this way, lets do that now and unblock 171391 the v850 code. 171392 1713932021-09-09 Mike Frysinger <vapier@gentoo.org> 171394 171395 sim: mips: delete unused PSIZE define 171396 It's unclear what this define is for as it appears to be unused, and 171397 has never been used in the history of the mips sim. Delete it to tidy 171398 up, and to fix build errors for Windows targets that have a standard 171399 "PSIZE" struct in their system headers. This doesn't show up yet as 171400 most sim files don't include many system headers, but enabling sockser 171401 code for mingw uncovers the conflict. 171402 171403 Unfortunately the error produced by gcc is inscrutable, but running 171404 it through the preprocessor manually manages to provide a pointer to 171405 the underlying issue. 171406 171407 $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/mips/../common/dv-sockser.c 171408 <command-line>: error: expected identifier or '(' before numeric constant 171409 In file included from /usr/i686-w64-mingw32/usr/include/windows.h:71, 171410 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, 171411 from ../../gnulib/import/sys/socket.h:684, 171412 from ../../gnulib/import/netinet/in.h:43, 171413 from ../../../../sim/mips/../common/dv-sockser.c:39: 171414 /usr/i686-w64-mingw32/usr/include/wingdi.h:2934:59: error: unknown type name 'LPSIZE'; did you mean 'LPSIZEL'? 171415 2934 | WINGDIAPI WINBOOL WINAPI GetAspectRatioFilterEx(HDC hdc,LPSIZE lpsize); 171416 | ^~~~~~ 171417 | LPSIZEL 171418 ... 171419 171420 $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/mips/../common/dv-sockser.c 171421 $ i686-w64-mingw32-gcc -c dv-sockser.i 171422 In file included from /usr/i686-w64-mingw32/usr/include/windows.h:69, 171423 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, 171424 from ../../gnulib/import/sys/socket.h:684, 171425 from ../../gnulib/import/netinet/in.h:43, 171426 from ../../../../sim/mips/../common/dv-sockser.c:39: 171427 /usr/i686-w64-mingw32/usr/include/windef.h:104:9: error: expected identifier or '(' before numeric constant 171428 104 | } SIZE,*PSIZE,*LPSIZE; 171429 | ^~ 171430 1714312021-09-09 Mike Frysinger <vapier@gentoo.org> 171432 171433 sim: ppc: switch to common warning flags 171434 Now that the ppc code has been cleaned up enough to use the same set 171435 of warning flags as the common code, delete the ppc-specific configure 171436 logic so we can leverage what the common code already defined for us. 171437 1714382021-09-09 Tom de Vries <tdevries@suse.de> 171439 171440 sim: ppc: enable -Wpointer-sign warnings 171441 When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into: 171442 ... 171443 src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address': 171444 src/sim/ppc/hw_memory.c:204:7: error: pointer targets in passing argument 4 \ 171445 of 'device_find_integer_array_property' differ in signedness \ 171446 [-Werror=pointer-sign] 171447 &new_chunk->size); 171448 ^ 171449 ... 171450 171451 Fix these by adding an explicit pointer cast. It's a bit ugly to use APIs 171452 based on signed integers to read out unsigned values, but in practice, this 171453 is par for the course in the ppc code. 171454 171455 We already use signed APIs and assign the result to unsigned values a lot: 171456 see how device_find_integer_property returns a signed integer (cell), but 171457 then assign it to unsigned types. The array APIs are not used that often 171458 which is why we don't see many warnings, and we disable warnings when we 171459 assign signed integers to unsigned integers in general. 171460 171461 The dtc/libfdt project (which is the standard in other projects) processes 171462 the fdt blob as a series of bytes without any type information. Typing is 171463 left to the caller. They have core APIs that read/write bytes, and a few 171464 helper functions to cast/convert those bytes to the right value (e.g. u32). 171465 In this ppc sim code, the core APIs use signed integers, and the callers 171466 convert to unsigned, usually implicitly. 171467 171468 We could add some core APIs to the ppc sim that deal with raw bytes and then 171469 add some helpers to convert to the right type, but that seems like a lot of 171470 lifting for what boils down to a cast, and is effectively equivalent to all 171471 the implicit assignments we use elsewhere. Long term, a lot of the ppc code 171472 should either get converted to existing sim common code, or we should stand 171473 up proper APIs in the common code first, or use standard libraries to do all 171474 the processing (e.g. libfdt). Either way, this device.c code would all get 171475 deleted, and callers (like these hw_*.c files) would get converted. Which 171476 is also why we go with a cast rather new (but largely unused) APIs. 171477 1714782021-09-09 Mike Frysinger <vapier@gentoo.org> 171479 171480 sim: ppc: enable -Wmissing-declarations & -Wmissing-prototypes 171481 This aligns with common code which already uses this flag. We have 171482 to add another local prototype to fix the failure, and add another 171483 local decl for the SIM_DESC type. Unwinding these will require a 171484 lot more work & conversions in the process, so going with the decl 171485 for now unblocks the warning unification. 171486 1714872021-09-09 Mike Frysinger <vapier@gentoo.org> 171488 171489 sim: microblaze: replace custom basic types with common ones 171490 The basic "byte" type conflicts with Windows headers, and we already 171491 have common types that provide the right sizes. So replace these with 171492 the common ones to avoid issues. 171493 171494 CC dv-sockser.o 171495 In file included from /usr/i686-w64-mingw32/usr/include/wtypes.h:8, 171496 from /usr/i686-w64-mingw32/usr/include/winscard.h:10, 171497 from /usr/i686-w64-mingw32/usr/include/windows.h:97, 171498 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23, 171499 from ../../gnulib/import/sys/socket.h:684, 171500 from ../../gnulib/import/netinet/in.h:43, 171501 from .../build/sim/../../../sim/microblaze/../common/dv-sockser.c:39: 171502 /usr/i686-w64-mingw32/usr/include/rpcndr.h:63:25: error: conflicting types for 'byte'; have 'unsigned char' 171503 63 | typedef unsigned char byte; 171504 | ^~~~ 171505 In file included from .../buildsim/../../../sim/microblaze/sim-main.h:21, 171506 from .../buildsim/../../../sim/microblaze/../common/dv-sockser.c:24: 171507 .../buildsim/../../../sim/microblaze/microblaze.h:94:25: note: previous declaration of 'byte' with type 'byte' {aka 'char'} 171508 94 | typedef char byte; 171509 | ^~~~ 171510 make: *** [Makefile:513: dv-sockser.o] Error 1 171511 1715122021-09-09 Jim Wilson <jimw@sifive.com> 171513 171514 RISC-V: Pretty print values formed with lui and addiw. 171515 The disassembler has support to pretty print values created by an lui/addi 171516 pair, but there is no support for addiw. There is also no support for 171517 c.addi and c.addiw. This patch extends the pretty printing support to 171518 handle these 3 instructions in addition to addi. Existing testcases serve 171519 as tests for the new feature. 171520 171521 opcodes/ 171522 * riscv-dis.c (maybe_print_address): New arg wide. Sign extend when 171523 wide is true. 171524 (print_insn_args): Fix calls to maybe_print_address. Add checks for 171525 c.addi, c.addiw, and addiw, and call maybe_print_address for them. 171526 171527 gas/ 171528 * testsuite/gas/riscv/insn.d: Update for disassembler change. 171529 * testsuite/gas/li32.d, testsuite/gas/li64.d: Likwise. 171530 * testsuite/gas/lla64.d: Likewise. 171531 1715322021-09-09 Mike Frysinger <vapier@gentoo.org> 171533 171534 sim: ppc: align format string settings with common code 171535 This copies logic used in the common sim warning configure code to fix 171536 build errors for mingw targets. Turning format warnings on triggers 171537 a failure in the debug.c file, so apply a minor fix at the same time. 171538 171539 sim: ppc: drop unnecessary config includes 171540 This file is compiled for the --host & --build system which leads to 171541 including the configure generated config.h in both environments. 171542 This obviously doesn't work when the two targets don't look alike at 171543 all and can cause build failures here (e.g. a mingw host & a linux 171544 build). Since we don't actually need any config settings in this 171545 very simple file, drop the includes entirely. 171546 1715472021-09-09 GDB Administrator <gdbadmin@sourceware.org> 171548 171549 Automatic date update in version.in 171550 1715512021-09-08 Mike Frysinger <vapier@gentoo.org> 171552 171553 gnulib: import various network functions 171554 Some sim ports use these to provide networking functionality via the 171555 dv-sockser module or via direct emulation for a few ports. 171556 171557 Gdb seems to build just fine still too. 171558 1715592021-09-08 Tom Tromey <tromey@adacore.com> 171560 171561 Fix unit test build on Windows 171562 Like Tom de Vries' earlier patch to fix the no-CXX_STD_THREAD case in 171563 maint.c, this patch fixes a similar problem in 171564 parallel-for-selftests.c. This fixes a build failure on Windows. 171565 1715662021-09-08 Alan Modra <amodra@gmail.com> 171567 171568 PowerPC64, sanity check r_offset in relocate_section 171569 This hardens the powerpc64 linker code transformations. 171570 171571 * elf64-ppc.c (is_8byte_reloc, offset_in_range): New functions. 171572 (ppc64_elf_relocate_section): Sanity check r_offset before 171573 accessing section contents for various code transformations. 171574 1715752021-09-08 Alan Modra <amodra@gmail.com> 171576 171577 PowerPC64: Avoid useless work on R_PPC64_TPREL34 171578 _bfd_elf_ppc_at_tprel_transform doesn't handle prefix instructions, 171579 and I'm not inclined to implement code editing for them. 171580 171581 * elf64-ppc.c (ppc64_elf_relocate_section): Don't attempt tprel 171582 transform for R_PPC64_TPREL34. 171583 1715842021-09-08 Andrew Burgess <andrew.burgess@embecosm.com> 171585 171586 gdb: make thread_suspend_state::stop_pc optional 171587 Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and 171588 when we want to indicate that there is no stop_pc available we set 171589 this field back to a special value. 171590 171591 There are actually two special values used, in post_create_inferior 171592 the stop_pc is set to 0. This is a little unfortunate, there are 171593 plenty of embedded targets where 0 is a valid pc value. The more 171594 common special value for stop_pc though, is set in 171595 thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used. 171596 171597 This commit changes things so that the stop_pc is instead a 171598 gdb::optional. We can now explicitly reset the field to an 171599 uninitialised state, we also have asserts that we don't read the 171600 stop_pc when its in an uninitialised state (both in 171601 gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG 171602 defined, and in thread_info::stop_pc). 171603 171604 One situation where a thread will not have a stop_pc value is when the 171605 thread is stopped as a consequence of GDB being in all stop mode, and 171606 some other thread stopped at an interesting event. When GDB brings 171607 all the other threads to a stop those other threads will not have a 171608 stop_pc set (thus avoiding an unnecessary read of the pc register). 171609 171610 Previously, when GDB passed through handle_one (in infrun.c) the 171611 threads executing flag was set to false and the stop_pc field was left 171612 unchanged, i.e. it would (previous) have been left as ~0. 171613 171614 Now, handle_one leaves the stop_pc with no value. 171615 171616 This caused a problem when we later try to set these threads running 171617 again, in proceed() we compare the current pc with the cached stop_pc. 171618 If the thread was stopped via handle_one then the stop_pc would have 171619 been left as ~0, and the compare (in proceed) would (likely) fail. 171620 Now however, this compare tries to read the stop_pc when it has no 171621 value and this would trigger an assert. 171622 171623 To resolve this I've added thread_info::stop_pc_p() which returns true 171624 if the thread has a cached stop_pc. We should only ever call 171625 thread_info::stop_pc() if we know that there is a cached stop_pc, 171626 however, this doesn't mean that every call to thread_info::stop_pc() 171627 needs to be guarded with a call to thread_info::stop_pc_p(), in most 171628 cases we know that the thread we are looking at stopped due to some 171629 interesting event in that thread, and so, we know that the stop_pc is 171630 valid. 171631 171632 After running the testsuite I've seen no other situations where 171633 stop_pc is read uninitialised. 171634 171635 There should be no user visible changes after this commit. 171636 1716372021-09-08 Tom de Vries <tdevries@suse.de> 171638 171639 [gdb/build] Fix build with undefined CXX_STD_THREAD 171640 When building gdb on openSUSE Leap 42.3, we trigger the case that 171641 CXX_STD_THREAD is undefined, and run into: 171642 ... 171643 gdb/maint.c: In function 'void maintenance_show_worker_threads \ 171644 (ui_file*, int, cmd_list_element*, const char*)': 171645 gdb/maint.c:877:14: error: 'gdb::thread_pool' has not been declared 171646 gdb::thread_pool::g_thread_pool->thread_count ()); 171647 ^ 171648 Makefile:1647: recipe for target 'maint.o' failed 171649 make[1]: *** [maint.o] Error 1 171650 ... 171651 171652 Fix this by handling the undefined CXX_STD_THREAD case in 171653 maintenance_show_worker_threads, such that we get: 171654 ... 171655 $ gdb -q -batch -ex "maint show worker-thread" 171656 The number of worker threads GDB can use is 0. 171657 ... 171658 171659 Tested on x86_64-linux. 171660 171661 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28312 171662 1716632021-09-08 Mike Frysinger <vapier@gentoo.org> 171664 171665 sim: update configure target list 171666 Fix sorting of the list, and update the globs to match the list used 171667 in gdb's configure script. 171668 171669 gdb: cris: enable sim integration 171670 The sim side is already ready to go for cris, so wire it up. 171671 171672 gdb: aarch64: enable sim integration 171673 The sim side is already ready to go for aarch64, so wire it up. 171674 171675 gdb: sim: consolidate configure settings 171676 Moving all the sim settings to one section makes it easier to track, 171677 and makes it easier to keep it aligned with the sim target tests. 171678 The gdb logic was duplicating this when handling different OS targets 171679 instead of having a single cpu check. Now it's more obvious that the 171680 sim is tied to a cpu and not related to the OS. 171681 1716822021-09-08 GDB Administrator <gdbadmin@sourceware.org> 171683 171684 Automatic date update in version.in 171685 1716862021-09-07 Tom Tromey <tromey@adacore.com> 171687 171688 Remove unused declaration from gdbserver/win32-low.h 171689 I noticed that gdbserver/win32-low.h has an unused declaration. This 171690 code was changed a while ago, but this declaration slipped through. 171691 This patch removes it. Tested by rebuilding. 171692 1716932021-09-07 Andrew Burgess <andrew.burgess@embecosm.com> 171694 171695 gdb: make use of std::string in utils.c 171696 Replace some of the manual string management (malloc/free) with 171697 std::string when creating commands in utils.c. 171698 171699 Things are a little bit messy as, creating the prefix commands (using 171700 add_basic_prefix_cmd and add_show_prefix_cmd), doesn't copy the doc 171701 string, while creating the actual set/show commands (using 171702 add_setshow_enum_cmd) does copy the doc string. 171703 171704 As a result, I have retained the use of xstrprintf when creating the 171705 prefix command doc strings, but switched to using std::string when 171706 creating the actual set/show commands. 171707 171708 There should be no user visible changes after this commit. 171709 1717102021-09-07 Luis Machado <luis.machado@linaro.org> 171711 171712 Revert: [AArch64] MTE corefile support 171713 bfd * elf.c (elfcore_make_memtag_note_section): New function. 171714 (elfcore_grok_note): Handle NT_MEMTAG note types. 171715 171716 binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types. 171717 171718 include * elf/common.h (NT_MEMTAG): New constant. 171719 (NT_MEMTAG_TYPE_AARCH_MTE): New constant. 171720 1717212021-09-07 Andrew Burgess <andrew.burgess@embecosm.com> 171722 171723 gdb: use bool instead of int in struct internal_problem 171724 Change struct internal_problem (gdb/utils.c) to use bool instead of 171725 int, update the 3 static instances of this structure that we create to 171726 use true/false instead of 1/0. 171727 171728 I've also updated the comments on struct internal_problem as the 171729 existing comment doesn't seem to be referring to the structure, it 171730 talks about returning something, which doesn't make sense in this 171731 context. 171732 171733 There should be no user visible changes after this commit. 171734 1717352021-09-07 Andrew Burgess <andrew.burgess@embecosm.com> 171736 171737 gdb: make thread_info::executing private 171738 Rename thread_info::executing to thread_info::m_executing, and make it 171739 private. Add a new get/set member functions, and convert GDB to make 171740 use of these. 171741 171742 The only real change of interest in this patch is in thread.c where I 171743 have deleted the helper function set_executing_thread, and now just 171744 use the new set function thread_info::set_executing. However, the old 171745 helper function set_executing_thread included some code to reset the 171746 thread's stop_pc, so I moved this code into the new function 171747 thread_info::set_executing. However, I don't believe there is 171748 anywhere that this results in a change of behaviour, previously the 171749 executing flag was always set true through a call to 171750 set_executing_thread anyway. 171751 1717522021-09-07 Nick Clifton <nickc@redhat.com> 171753 171754 Fix an illegal memory access triggered by an atempt to disassemble a corrupt xtensa binary. 171755 PR 28305 171756 * elf32-xtensa.c (elf_xtensa_do_reloc): Add check for put of range 171757 reloc. 171758 1717592021-09-07 Andrew Burgess <andrew.burgess@embecosm.com> 171760 171761 gdb/python: new function to add values into GDB's history 171762 The guile API has (history-append! <value>) to add values into GDB's 171763 history list. There is currently no equivalent in the Python API. 171764 171765 This commit adds gdb.add_history(<value>) to the Python API, this 171766 function takes <value> a gdb.Value (or anything that can be passed to 171767 the constructor of gdb.Value), and adds the value it represents to 171768 GDB's history list. The index of the newly added value is returned. 171769 1717702021-09-07 Nick Clifton <nickc@redhat.com> 171771 171772 Fix illegal memory access triggered by an attempt to disassemble a corrupt RISC-V binary. 171773 PR 28303 171774 * elfxx-riscv.c (riscv_elf_add_sub_reloc): Add check for out of 171775 range relocs. 171776 1717772021-09-07 Tom de Vries <tdevries@suse.de> 171778 171779 [gdb/testsuite] Handle internal-error in gdb_unload 171780 When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar" 171781 to trigger the internal-error in test-case 171782 gdb.dwarf2/locexpr-data-member-location.exp, we run into: 171783 ... 171784 ERROR: couldn't unload file in $gdb (timeout). 171785 ... 171786 and the test-case takes about 1 minute. 171787 171788 Fix this by handling internal-error in gdb_unload, such that we have: 171789 ... 171790 ERROR: Couldn't unload file in $gdb (GDB internal error). 171791 ERROR: Could not resync from internal error (eof) 171792 ... 171793 within 2 seconds. 171794 171795 Tested on x86_64-linux. 171796 1717972021-09-07 Alan Modra <amodra@gmail.com> 171798 171799 PR28307, segfault in ppc64_elf_toc64_reloc 171800 Adds missing bfd_reloc_offset_in_range checks to various relocation 171801 special_functions. 171802 171803 PR 28307 171804 * elf32-ppc.c (ppc_elf_addr16_ha_reloc): Range check reloc offset. 171805 * elf64-ppc.c (ppc64_elf_ha_reloc, ppc64_elf_brtaken_reloc): Likewise. 171806 (ppc64_elf_toc64_reloc, ppc64_elf_prefix_reloc): Likewise. 171807 1718082021-09-07 GDB Administrator <gdbadmin@sourceware.org> 171809 171810 Automatic date update in version.in 171811 1718122021-09-07 Tom de Vries <tdevries@suse.de> 171813 171814 [gdb/testsuite] Handle internal-error in gdb_run_cmd 171815 When reverting commit 5a20fadc841 the test-case 171816 gdb.dwarf2/locexpr-data-member-location.exp fails like this: 171817 ... 171818 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ 171819 (GDB internal error) 171820 ERROR: Could not resync from internal error (eof) 171821 ... 171822 and takes 1 minute to run. 171823 171824 The long running time is caused by running into a timeout in gdb_run_cmd, at 171825 this point: 171826 ... 171827 (gdb) run ^M 171828 The program being debugged has been started already.^M 171829 Start it from the beginning? (y or n) y^M 171830 /home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \ 171831 Unexpected type field location kind: 4^M 171832 A problem internal to GDB has been detected,^M 171833 further debugging may prove unreliable.^M 171834 Quit this debugging session? (y or n) 171835 ... 171836 171837 Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it 171838 in gdb_run_cmd, but stash the gdb output back into the buffer using 171839 -notransfer, and let the caller proc runto deal with it. 171840 171841 After the fix, the test-case just takes 2 seconds. 171842 171843 Tested on x86_64-linux. 171844 1718452021-09-06 Lancelot SIX <lsix@lancelotsix.com> 171846 171847 gdb: rename gdb/testsuite/gdb.arch/riscv64-unwind-prologue-with-ld-lw.c 171848 A previous commit added the 171849 gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its 171850 associated file was named after a previous version of the test. 171851 171852 This commit fixes this and makes sure that all the files linked to this 171853 testcase share the same prefix in the name. 171854 171855 Tested on riscv64 GNU/Linux. 171856 1718572021-09-06 Tom de Vries <tdevries@suse.de> 171858 171859 [gdb/testsuite] Handle eof in gdb_internal_error_resync 171860 Before commit 5a20fadc841 the test-case 171861 gdb.dwarf2/locexpr-data-member-location.exp fails like this: 171862 ... 171863 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ 171864 (GDB internal error) 171865 ERROR: : spawn id exp9 not open 171866 while executing 171867 "expect { 171868 -i exp9 -timeout 10 171869 -re "Quit this debugging session\\? \\(y or n\\) $" { 171870 send_gdb "n\n" answer 171871 incr count 171872 } 171873 -re "Create ..." 171874 ("uplevel" body line 1) 171875 invoked from within 171876 "uplevel $body" NONE : spawn id exp9 not open 171877 ERROR: Could not resync from internal error (timeout) 171878 ... 171879 171880 Fix the: 171881 ... 171882 ERROR: : spawn id exp9 not open 171883 ... 171884 by handling eof in gdb_internal_error_resync, such that we have instead: 171885 ... 171886 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \ 171887 (GDB internal error) 171888 ERROR: Could not resync from internal error (eof) 171889 ... 171890 171891 Tested on x86_64-linux. 171892 1718932021-09-06 Tom Tromey <tom@tromey.com> 171894 171895 Remove some complaints.h includes 171896 There are a few includes of complaints.h that aren't necessary. This 171897 patch removes them. Tested by rebuilding. 171898 1718992021-09-06 Nick Clifton <nickc@redhat.com> 171900 171901 Fix an illegal memory access triggered by disassembling corrupt s390x binaries. 171902 PR 28304 171903 * elfxx-score7.c (score_elf_gprel15_reloc): If there is no output bfd 171904 treat the reloc as undefined. 171905 171906 Fix potential use on an uninitialised vairable in the MCore assembler. 171907 171908 Fix potential uninitialised variable in microblaze assembler code. 171909 1719102021-09-06 Yinjun Zhang <yinjun.zhang@corigine.com> 171911 171912 Add a sanity check to the init_nfp6000_mecsr_sec() function in the NFP disassembler. 171913 1719142021-09-06 Alexandra Hájková <ahajkova@redhat.com> 171915 171916 gdbtypes.c: Add the case for FIELD_LOC_KIND_DWARF_BLOCK 171917 The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for 171918 switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error 171919 under some circumstances. 171920 171921 Fixes bug 28030. 171922 1719232021-09-06 GDB Administrator <gdbadmin@sourceware.org> 171924 171925 Automatic date update in version.in 171926 1719272021-09-05 GDB Administrator <gdbadmin@sourceware.org> 171928 171929 Automatic date update in version.in 171930 1719312021-09-04 Tom de Vries <tdevries@suse.de> 171932 171933 [gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp 171934 On a machine on Open Build Service I'm running into a SIGILL for test-case 171935 gdb.arch/amd64-disp-step-avx.exp: 171936 ... 171937 Program received signal SIGILL, Illegal instruction.^M 171938 test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M 171939 40 vmovsd ro_var(%rip),%xmm0^M 171940 (gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \ 171941 continue to test_rip_vex2_end 171942 ... 171943 The SIGILL happens when trying to execute the first avx instruction in the 171944 executable. 171945 171946 I can't directly access the machine, but looking at the log for test-case 171947 gdb.arch/i386-avx.exp, it seems that there's no avx support: 171948 ... 171949 Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M 171950 68 if (have_avx ())^M 171951 (gdb) print have_avx ()^M 171952 $1 = 0^M 171953 ... 171954 171955 Fix this by: 171956 - adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx 171957 function from gdb.arch/i386-avx.c 171958 - using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp 171959 and gdb/testsuite/gdb.arch/i386-avx.exp. 171960 171961 Tested on my x86_64-linux laptop with avx support, where both test-cases pass. 171962 171963 gdb/testsuite/ChangeLog: 171964 171965 2021-09-04 Tom de Vries <tdevries@suse.de> 171966 171967 PR testsuite/26950 171968 * gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx. 171969 (have_avx): Move ... 171970 * gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc. 171971 * gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx. 171972 * gdb/testsuite/gdb.arch/i386-avx.exp: Same. 171973 1719742021-09-04 Mike Frysinger <vapier@gentoo.org> 171975 171976 gnulib: import sys_wait 171977 A few sims use this to emulate process syscalls. 171978 Gdb builds seem to still be fine. 171979 1719802021-09-04 GDB Administrator <gdbadmin@sourceware.org> 171981 171982 Automatic date update in version.in 171983 1719842021-09-03 Tom Tromey <tromey@adacore.com> 171985 171986 Use CORE_ADDR as return type from x86_dr_low_get_addr 171987 On a Windows build locally, watchpoints started failing. I tracked 171988 this down to x86_dr_low_get_addr returning an 'unsigned long'... in 171989 this particular build, this is a 32-bit type, but the inferior is a 171990 64-bit program. 171991 171992 This patch fixes the problem by changing the return type. No other 171993 change is required, because this matches the function pointer in 171994 struct x86_dr_low_type. 171995 1719962021-09-03 Kevin Buettner <kevinb@redhat.com> 171997 171998 Test case reproducing PR28030 bug 171999 The original reproducer for PR28030 required use of a specific 172000 compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR, 172001 though it seems probable that other gcc versions might also be able to 172002 reproduce the bug as well. This commit introduces a test case which, 172003 using the DWARF assembler, provides a reproducer which is independent 172004 of the compiler version. (Well, it'll work with whatever compilers 172005 the DWARF assembler works with.) 172006 172007 To the best of my knowledge, it's also the first test case which uses 172008 the DWARF assembler to provide debug info for a shared object. That 172009 being the case, I provided more than the usual commentary which should 172010 allow this case to be used as a template when a combo shared 172011 library / DWARF assembler test case is required in the future. 172012 172013 I provide some details regarding the bug in a comment near the 172014 beginning of locexpr-dml.exp. 172015 172016 This problem was difficult to reproduce; I found myself constantly 172017 referring to the backtrace while trying to figure out what (else) I 172018 might be missing while trying to create a reproducer. Below is a 172019 partial backtrace which I include for posterity. 172020 172021 #0 internal_error ( 172022 file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575, 172023 fmt=0xc520c0 "Unexpected type field location kind: %d") 172024 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51 172025 #1 0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930, 172026 type=0x274c260, copied_types=0x30bb290) 172027 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575 172028 #2 0x00000000006ef382 in copy_type_recursive (objfile=0x1635930, 172029 type=0x274ca10, copied_types=0x30bb290) 172030 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602 172031 #3 0x0000000000a7409a in preserve_one_value (value=0x24269f0, 172032 objfile=0x1635930, copied_types=0x30bb290) 172033 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529 172034 #4 0x000000000072012a in gdbscm_preserve_values ( 172035 extlang=0xc55720 <extension_language_guile>, objfile=0x1635930, 172036 copied_types=0x30bb290) 172037 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94 172038 #5 0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930, 172039 copied_types=0x30bb290) 172040 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568 172041 #6 0x0000000000a7428d in preserve_values (objfile=0x1635930) 172042 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579 172043 #7 0x000000000082d514 in objfile::~objfile (this=0x1635930, 172044 __in_chrg=<optimized out>) 172045 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549 172046 #8 0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580) 172047 at /usr/include/c++/11/bits/shared_ptr_base.h:348 172048 #9 0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168 172049 #10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>) 172050 at /usr/include/c++/11/bits/shared_ptr_base.h:705 172051 #11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>) 172052 at /usr/include/c++/11/bits/shared_ptr_base.h:1154 172053 #12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr ( 172054 this=0x190bb80, __in_chrg=<optimized out>) 172055 at /usr/include/c++/11/bits/shared_ptr.h:122 172056 #13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00, 172057 __p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168 172058 #14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., 172059 __p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531 172060 #15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position= 172061 std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930}) 172062 at /usr/include/c++/11/bits/stl_list.h:1925 172063 #16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position= 172064 std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930}) 172065 at /usr/include/c++/11/bits/list.tcc:158 172066 #17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0, 172067 objfile=0x1635930) 172068 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210 172069 #18 0x000000000082d3ae in objfile::unlink (this=0x1635930) 172070 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487 172071 #19 0x000000000082e68c in objfile_purge_solibs () 172072 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875 172073 #20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1) 172074 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236 172075 #21 0x00000000009a37fe in target_pre_inferior (from_tty=1) 172076 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496 172077 #22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1, 172078 run_how=RUN_NORMAL) 172079 at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437 172080 172081 I'll note a few points regarding this backtrace: 172082 172083 Frame #1 is where the internal error occurs. It's caused by an 172084 unhandled case for FIELD_LOC_KIND_DWARF_BLOCK. The fix for this bug 172085 adds support for this case. 172086 172087 Frame #22 - it's a partial backtrace - shows that GDB is attempting to 172088 (re)run the program. You can see the exact command sequence that was 172089 used for reproducing this problem in the PR (at 172090 https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a 172091 nutshell, after starting the program and advancing to the appropriate 172092 source line, GDB was asked to step into libstdc++; a "finish" command 172093 was issued, returning a value. The fact that a value was returned is 172094 very important. GDB was then used to step back into libstdc++. A 172095 breakpoint was set on a source line in the library after which a "run" 172096 command was issued. 172097 172098 Frame #19 shows a call to objfile_purge_solibs. It's aptly named. 172099 172100 Frame #7 is a call to the destructor for one of the objfile solibs; it 172101 turned out to be the one for libstdc++. 172102 172103 Frames #6 thru #3 show various value preservation frames. If you look 172104 at preserve_values() in gdb/value.c, the value history is preserved 172105 first, followed by internal variables, followed by values for the 172106 extension languages (python and guile). 172107 1721082021-09-03 Tom de Vries <tdevries@suse.de> 172109 172110 [gdb/testsuite] Add untested case in gdb.gdb/complaints.exp 172111 When building gdb with "-Wall -O2 -g -flto=auto", I run into: 172112 ... 172113 (gdb) call clear_complaints()^M 172114 No symbol "clear_complaints" in current context.^M 172115 (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints 172116 ... 172117 172118 The problem is that lto has optimized away clear_complaints, and consequently 172119 the selftests cannot run. 172120 172121 Fix this by: 172122 - using info function to detect presence of clear_complaints 172123 - handling the absence of clear_complaints by calling untested 172124 ... 172125 (gdb) UNTESTED: gdb.gdb/complaints.exp: \ 172126 Cannot find clear_complaints, skipping test 172127 ... 172128 172129 Tested on x86_64-linux. 172130 172131 gdb/testsuite/ChangeLog: 172132 172133 2021-09-03 Tom de Vries <tdevries@suse.de> 172134 172135 * gdb.gdb/complaints.exp: Use untested if clear_complaints cannot 172136 be found. 172137 1721382021-09-03 Felix Willgerodt <felix.willgerodt@intel.com> 172139 172140 gdb: Enable finish command and inferior calls for _Float16 on amd64 and i386. 172141 Values of type _Float16 and _Float16 _Complex can now be used on CPUs with 172142 AVX512-FP16 support. Return values of those types are located in XMM0. 172143 Compiler support for gcc and clang is in progress, see e.g.: 172144 https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html 172145 172146 gdb/ChangeLog: 172147 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172148 172149 * amd64-tdep.c (amd64_classify): Classify _Float16 and 172150 _Float16 _Complex as AMD64_SSE. 172151 * i386-tdep.c (i386_extract_return_value): Read _Float16 and 172152 _Float16 _Complex from xmm0. 172153 172154 gdb/testsuite/ChangeLog: 172155 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172156 172157 * gdb.arch/x86-avx512fp16-abi.c: New file. 172158 * gdb.arch/x86-avx512fp16-abi.exp: New file. 172159 1721602021-09-03 Felix Willgerodt <felix.willgerodt@intel.com> 172161 172162 Add half support for AVX512 register view. 172163 This adds support for the half datatype, FP16, to the AVX512 register printing. 172164 172165 gdb/ChangeLog: 172166 2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172167 172168 * i386-tdep.c (i386_zmm_type) <v32_half>: New field. 172169 (i386_ymm_type) <v16_half>: New field. 172170 (i386_gdbarch_init): Add set_gdbarch_half_format. 172171 * features/i386/64bit-avx512.xml: Add half type. 172172 * features/i386/64bit-avx512.c: Regenerated. 172173 * features/i386/64bit-sse.xml: Add half type. 172174 * features/i386/64bit-sse.c: Regenerated. 172175 172176 gdb/testsuite/ChangeLog: 172177 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172178 172179 * gdb.arch/x86-avx512fp16.c: New file. 172180 * gdb.arch/x86-avx512fp16.exp: New file. 172181 * lib/gdb.exp (skip_avx512fp16_tests): New function. 172182 1721832021-09-03 Felix Willgerodt <felix.willgerodt@intel.com> 172184 172185 gdb, i386: Enable AVX512-bfloat16 for i386 targets. 172186 Values of type bfloat16 can also be used on 32-bit targets, which was missed 172187 in the original enablement. This also adjusts the testcase to pass with 172188 "unix/-m32", where only the lower 8 AVX registers are available. 172189 172190 gdb/ChangeLog: 172191 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172192 172193 * features/i386/32bit-sse.xml: Add bfloat16 type. 172194 * features/i386/32bit-sse.c: Regenerated. 172195 172196 gdb/testsuite/ChangeLog: 172197 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> 172198 172199 * gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7. 172200 1722012021-09-03 Tom de Vries <tdevries@suse.de> 172202 172203 [gdb/testsuite] Add untested case in selftest_setup 172204 When building gdb with "-Wall -O2 -g -flto=auto", I run into: 172205 ... 172206 FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \ 172207 (got interactive prompt) 172208 FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main 172209 WARNING: Couldn't test self 172210 ... 172211 and similar in gdb.gdb/selftest.exp. 172212 172213 The first FAIL in more detail: 172214 ... 172215 (gdb) break captured_main^M 172216 Function "captured_main" not defined.^M 172217 Make breakpoint pending on future shared library load? (y or [n]) n^M 172218 (gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \ 172219 (got interactive prompt) 172220 ... 172221 172222 The problem is that lto has optimized away the captured_main function 172223 and consequently the selftests dependent on that cannot run. 172224 172225 Fix this by: 172226 - using gdb_breakpoint to detect failure to set the breakpoint 172227 - handling the failure to set a breakpoint by calling untested 172228 - not emitting the warning if we've already got untested 172229 such that we have: 172230 ... 172231 (gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \ 172232 captured_main, skipping testcase. 172233 ... 172234 172235 gdb/testsuite/ChangeLog: 172236 172237 2021-09-02 Tom de Vries <tdevries@suse.de> 172238 172239 * lib/selftest-support.exp: Emit untested when not being able to set 172240 breakpoint. 172241 1722422021-09-03 Alan Modra <amodra@gmail.com> 172243 172244 ld testsuite tidy 172245 Fixes a few issues: 172246 1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile 172247 attempt to trim off -fsanitize options left us with ",undefined". 172248 2) ld_compile adds CFLAGS_FOR_TARGET itself, no need to pass it. 172249 3) CFLAGS might be needed linking bootstrap test. 172250 172251 * Makefile.am (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Trim off 172252 all -fsanitize=*. 172253 * Makefile.in: Regenerate. 172254 * testsuite/ld-bootstrap/bootstrap.exp: Use CFLAGS when linking. 172255 * testsuite/ld-cdtest/cdtest.exp: Use CFLAGS_FOR_TARGET when 172256 linking. 172257 * testsuite/ld-auto-import/auto-import.exp: Don't pass 172258 CFLAGS_FOR_TARGET to ld_compile. 172259 * testsuite/ld-cygwin/exe-export.exp: Likewise. 172260 * testsuite/ld-elfvers/vers.exp: Likewise. 172261 * testsuite/ld-elfvsb/elfvsb.exp: Likewise. 172262 * testsuite/ld-elfweak/elfweak.exp: Likewise. 172263 * testsuite/ld-gc/gc.exp: Likewise. 172264 * testsuite/ld-pe/pe-compile.exp: Likewise. 172265 * testsuite/ld-pe/pe-run.exp: Likewise. 172266 * testsuite/ld-pe/pe-run2.exp: Likewise. 172267 * testsuite/ld-plugin/plugin.exp: Likewise. 172268 * testsuite/ld-shared/shared.exp: Likewise. 172269 * testsuite/ld-elfcomm/elfcomm.exp: Likewise, and don't allow 172270 nios2 testing to trash CFLAGS_FOR_TARGET. 172271 * testsuite/ld-scripts/crossref.exp: Don't pass options in 172272 CC_FOR_TARGET, do so in CFLAGS_FOR_TARGET instead. 172273 * testsuite/ld-srec/srec.exp: Likewise, and for CXX. 172274 1722752021-09-03 Alan Modra <amodra@gmail.com> 172276 172277 CC_FOR_TARGET et al 172278 The top level Makefile, the ld Makefile and others, define 172279 CC_FOR_TARGET to be a compiler for the binutils target machine. This 172280 is the compiler that should be used for almost all tests with C 172281 source. There are _FOR_TARGET versions of CFLAGS, CXX, and CXXFLAGS 172282 too. This was all supposed to work with the testsuite .exp files 172283 using CC for the target compiler, and CC_FOR_HOST for the host 172284 compiler, with the makefiles passing CC=$CC_FOR_TARGET and 172285 CC_FOR_HOST=$CC to the runtest invocation. 172286 172287 One exception to the rule of using CC_FOR_TARGET is the native-only ld 172288 bootstrap test, which uses the newly built ld to link a copy of 172289 itself. Since the files being linked were created with the host 172290 compiler, the boostrap test should use CC and CFLAGS, in case some 172291 host compiler option provides needed libraries automatically. 172292 However, bootstrap.exp used CC where it should have used CC_FOR_HOST. 172293 I set about fixing that problem, then decided that playing games in 172294 the makefiles with CC was a bad idea. Not only is it confusing, but 172295 other dejagnu code knows about CC_FOR_TARGET. See dejagnu/target.exp. 172296 172297 So this patch gets rid of the makefile variable renaming and changes 172298 all the .exp files to use the correct _FOR_TARGET variables. 172299 CC_FOR_HOST and CFLAGS_FOR_HOST disappear. A followup patch will 172300 correct bootstrap.exp to use CFLAGS, and a number of other things I 172301 noticed. 172302 172303 binutils/ 172304 * testsuite/lib/binutils-common.exp (run_dump_test): Use 172305 CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS. 172306 ld/ 172307 * Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET 172308 and similar. Pass variables with unchanged names. Don't set 172309 CC_FOR_HOST or CFLAGS_FOR_HOST. 172310 * Makefile.in: Regenerate. 172311 * testsuite/config/default.exp: Update default CC and similar. 172312 (compiler_supports, plug_opt): Use CC_FOR_TARGET. 172313 * testsuite/ld-cdtest/cdtest.exp: Replace all uses of CC with 172314 CC_FOR_TARGET, and similarly for CFLAGS, CXX and CXXFLAGS. 172315 * testsuite/ld-auto-import/auto-import.exp: Likewise. 172316 * testsuite/ld-cygwin/exe-export.exp: Likewise. 172317 * testsuite/ld-elf/dwarf.exp: Likewise. 172318 * testsuite/ld-elf/indirect.exp: Likewise. 172319 * testsuite/ld-elf/shared.exp: Likewise. 172320 * testsuite/ld-elfcomm/elfcomm.exp: Likewise. 172321 * testsuite/ld-elfvers/vers.exp: Likewise. 172322 * testsuite/ld-elfvsb/elfvsb.exp: Likewise. 172323 * testsuite/ld-elfweak/elfweak.exp: Likewise. 172324 * testsuite/ld-gc/gc.exp: Likewise. 172325 * testsuite/ld-ifunc/ifunc.exp: Likewise. 172326 * testsuite/ld-mn10300/mn10300.exp: Likewise. 172327 * testsuite/ld-pe/pe-compile.exp: Likewise. 172328 * testsuite/ld-pe/pe-run.exp: Likewise. 172329 * testsuite/ld-pe/pe-run2.exp: Likewise. 172330 * testsuite/ld-pie/pie.exp: Likewise. 172331 * testsuite/ld-plugin/lto.exp: Likewise. 172332 * testsuite/ld-plugin/plugin.exp: Likewise. 172333 * testsuite/ld-scripts/crossref.exp: Likewise. 172334 * testsuite/ld-selective/selective.exp: Likewise. 172335 * testsuite/ld-sh/sh.exp: Likewise. 172336 * testsuite/ld-shared/shared.exp: Likewise. 172337 * testsuite/ld-srec/srec.exp: Likewise. 172338 * testsuite/ld-undefined/undefined.exp: Likewise. 172339 * testsuite/ld-unique/unique.exp: Likewise. 172340 * testsuite/ld-x86-64/tls.exp: Likewise. 172341 * testsuite/lib/ld-lib.exp: Likewise. 172342 libctf/ 172343 * Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET. 172344 Pass CC and CC_FOR_TARGET. Don't set CC_FOR_HOST. 172345 * Makefile.in: Regenerate. 172346 * testsuite/config/default.exp: Update default CC and similar. 172347 * testsuite/lib/ctf-lib.exp (run_native_host_cmd): Use CC rather 172348 than CC_FOR_HOST. 172349 (run_lookup_test): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET. 172350 1723512021-09-03 Alan Modra <amodra@gmail.com> 172352 172353 pj: asan: out of bounds, ubsan: left shift of negative 172354 * pj-dis.c: Include libiberty.h. 172355 (print_insn_pj): Don't index op->arg past array bound. Don't 172356 left shift negative int. 172357 172358 ubsan: alpha: member access within null pointer 172359 * elf64-alpha.c (elf64_alpha_relax_with_lituse): Avoid UB. 172360 172361 ubsan: libctf: applying zero offset to null pointer 172362 * ctf-open.c (init_symtab): Avoid ubsan error. 172363 1723642021-09-03 Alan Modra <amodra@gmail.com> 172365 172366 haiku tidy 172367 --enable-maintainer-mode showed a number of files needing to be 172368 regenerated, and in the case of ld/Makefile.in that the file was 172369 regenerated by hand. Nothing to see here really. 172370 172371 ld/ 172372 * Makefile.am (ALL_64_EMULATION_SOURCES): Sort haiku entry. 172373 * Makefile.in: Regenerate. 172374 * po/BLD-POTFILES.in: Regenerate. 172375 libctf/ 172376 * configure: Regenerate. 172377 zlib/ 172378 * configure: Regenerate. 172379 1723802021-09-03 Fangrui Song <maskray@google.com> 172381 172382 gold: --export-dynamic-symbol: don't imply -u 172383 to match GNU ld. 172384 172385 gold/ 172386 * archive.cc (Library_base::should_include_member): Don't handle 172387 --export-dynamic-symbol. 172388 * symtab.cc (Symbol_table::do_add_undefined_symbols_from_command_line): 172389 Likewise. 172390 1723912021-09-03 GDB Administrator <gdbadmin@sourceware.org> 172392 172393 Automatic date update in version.in 172394 1723952021-09-02 Alexander von Gluck IV <kallisti5@unixzen.com> 172396 172397 Add support for the haiku operating system. These are the os support patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org. All of these architectures are working and most have been stable for quite some time. 172398 1723992021-09-02 Nick Clifton <nickc@redhat.com> 172400 172401 Fix the V850 assembler's generation of relocations for the st.b instruction. 172402 PR 28292 172403 gas * config/tc-v850.c (handle_lo16): Also accept 172404 BFD_RELOC_V850_LO16_SPLIT_OFFSET. 172405 * testsuite/gas/v850/split-lo16.s: Add extra line. 172406 * testsuite/gas/v850/split-lo16.d: Update expected disassembly. 172407 172408 opcodes * v850-opc.c (D16): Use BFD_RELOC_V850_LO16_SPLIT_OFFSET in place 172409 of BFD_RELOC_16. 172410 1724112021-09-02 Alan Modra <amodra@gmail.com> 172412 172413 SHT_SYMTAB_SHNDX handling 172414 .symtab_shndx section contents is an array, one entry for each symbol 172415 in .symtab, present when the number of symbols exceeds a little less 172416 than 64k. Since the mapping is 1-1 with symbols there is no need to 172417 keep both dest_index and destshndx_index in elf_sym_strtab. Instead, 172418 just make sure that the shndx pointers to the swap functions are kept 172419 NULL when .symtab_shndx does not exist. Also, strtabcount in the 172420 linker's elf hash table is incremented in lock-step with the output 172421 symcount, so that can disappear too. 172422 1724232021-09-02 Alan Modra <amodra@gmail.com> 172424 172425 PTR_ADD and NPTR_ADD for bfd.h 172426 This defines a couple of macros used to avoid ubsan complaints about 172427 calculations involving NULL pointers. PTR_ADD should be used in the 172428 case where it is known that the offset is always zero with a NULL 172429 pointer, and you'd like to know if a non-zero offset is ever used. 172430 NPTR_ADD should be rarely used, but is defined for cases where a 172431 non-zero offset is expected and should be ignored if the pointer is 172432 NULL. 172433 172434 bfd/ 172435 * bfd-in.h (PTR_ADD, NPTR_ADD): Define. 172436 * bfd-in2.h: Regenerate. 172437 * elf-eh-frame.c (adjust_eh_frame_local_symbols): Avoid NULL 172438 pointer calculations. 172439 * elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise. 172440 (bfd_elf_add_dt_needed_tag, elf_finalize_dynstr): Likewise. 172441 (elf_link_add_object_symbols, elf_link_input_bfd): Likewise. 172442 (bfd_elf_final_link, bfd_elf_gc_record_vtinherit): Likewise. 172443 binutils/ 172444 * objdump.c (disassemble_section): Use PTR_ADD for rel_ppend. 172445 1724462021-09-02 Alan Modra <amodra@gmail.com> 172447 172448 obstack.h __PTR_ALIGN vs. ubsan 172449 Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is 172450 as large as a pointer), due to making calculations relative to a NULL 172451 pointer. This patch avoids the problem by extracting out and 172452 simplifying __BPTR_ALIGN for the usual case. I've continued to use 172453 ptrdiff_t here, where it might be better to throw away __BPTR_ALIGN 172454 entirely and just assume uintptr_t exists. 172455 172456 * obstack.h (__PTR_ALIGN): Expand and simplify __BPTR_ALIGN 172457 rather than calculating relative to a NULL pointer. 172458 1724592021-09-02 GDB Administrator <gdbadmin@sourceware.org> 172460 172461 Automatic date update in version.in 172462 1724632021-09-01 Tom de Vries <tdevries@suse.de> 172464 172465 [gdb/testsuite] Fix dwo path in fission-*.S 172466 [ Using $build for /home/vries/gdb_versions/devel/build to make things a bit 172467 more readable. ] 172468 172469 When using make check// to run test-case gdb.dwarf2/fission-base.exp: 172470 ... 172471 ( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" ) 172472 ... 172473 we run into: 172474 ... 172475 (gdb) file \ 172476 $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M 172477 Reading symbols from \ 172478 $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M 172479 warning: Could not find DWO CU \ 172480 $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \ 172481 (0x807060504030201) referenced by CU at offset 0xc7 [in module \ 172482 $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M 172483 ... 172484 172485 The problem is that the executable refers to the dwo file using path name 172486 $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo, 172487 while the actual dwo file is at 172488 $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo. 172489 172490 This is caused by this trick in fission-base.S: 172491 ... 172492 #define XSTR(s) STR(s) 172493 #define STR(s) #s 172494 ... 172495 .asciz XSTR(DWO) # DW_AT_GNU_dwo_name 172496 ... 172497 and: 172498 ... 172499 $ echo | gcc -E -dD - | grep "define unix" 172500 ... 172501 172502 I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was 172503 concerned that there could be quoting issues. 172504 172505 However, I've found other uses of this pattern, f.i. in 172506 gdb/testsuite/gdb.base/corefile-buildid.exp: 172507 ... 172508 additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"] 172509 ... 172510 172511 So, fix this by: 172512 - using additional_flags=-DDWO=\"$dwo\" and 172513 - using plain DWO instead of XSTR(DWO) 172514 172515 Likewise in other gdb.dwarf2/fission*.exp test-cases. 172516 172517 Tested on x86_64-linux, using make check//unix. 172518 172519 gdb/testsuite/ChangeLog: 172520 172521 2021-09-01 Tom de Vries <tdevries@suse.de> 172522 172523 PR testsuite/28298 172524 * gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO). 172525 * gdb.dwarf2/fission-loclists-pie.S: Same. 172526 * gdb.dwarf2/fission-loclists.S: Same. 172527 * gdb.dwarf2/fission-reread.S: Same. 172528 * gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\". 172529 * gdb.dwarf2/fission-loclists-pie.exp: Same. 172530 * gdb.dwarf2/fission-loclists.exp: Same. 172531 * gdb.dwarf2/fission-reread.exp: Same. 172532 1725332021-09-01 Tom de Vries <tdevries@suse.de> 172534 172535 [gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol search 172536 On openSUSE Tumbleweed I ran into: 172537 ... 172538 (gdb) ptype outstring_func.part^M 172539 No symbol "outstring_func" in current context.^M 172540 (gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part 172541 ... 172542 while on openSUSE Leap 15.2 I have instead: 172543 ... 172544 (gdb) ptype string_func_^M 172545 type = <unknown return type> ()^M 172546 (gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_ 172547 ... 172548 172549 The difference is caused by the result for "info function string_func", which 172550 is this for the latter: 172551 ... 172552 (gdb) info function string_func^M 172553 All functions matching regular expression "string_func":^M 172554 ^M 172555 Non-debugging symbols:^M 172556 0x000000000040089c string_func_^M 172557 ... 172558 but this for the former: 172559 ... 172560 (gdb) info function string_func^M 172561 All functions matching regular expression "string_func":^M 172562 ^M 172563 Non-debugging symbols:^M 172564 0x00000000004012bb string_func_^M 172565 0x00007ffff7bac5b0 outstring_func.part^M 172566 0x00007ffff7bb1a00 outstring_func.part^M 172567 ... 172568 172569 The extra symbols are part of glibc: 172570 ... 172571 $ nm /lib64/libc.so.6 | grep string_func 172572 00000000000695b0 t outstring_func.part.0 172573 000000000006ea00 t outstring_func.part.0 172574 ... 172575 172576 If glibc debug info is installed, we get instead: 172577 ... 172578 (gdb) info function string_func^M 172579 All functions matching regular expression "string_func":^M 172580 ^M 172581 File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M 172582 236: static int outstring_func(int, size_t, const unsigned int *, FILE *);^M 172583 ^M 172584 File vfprintf-internal.c:^M 172585 236: static int outstring_func(int, size_t, const unsigned char *, FILE *);^M 172586 ^M 172587 Non-debugging symbols:^M 172588 0x00000000004012bb string_func_^M 172589 ... 172590 and the FAIL doesn't trigger. 172591 172592 Fix this by calling "info function string_func" before starting the exec, such 172593 that only symbols of the exec are taken into account. 172594 172595 Tested on x86_64-linux. 172596 172597 gdb/testsuite/ChangeLog: 172598 172599 2021-09-01 Tom de Vries <tdevries@suse.de> 172600 172601 * gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for 172602 find_mangled_name calls. 172603 1726042021-09-01 Yinjun Zhang <yinjun.zhang@corigine.com> 172605 172606 nfp: add validity check of island and me 172607 AddressSanitizer detects heap-buffer-overflow when running 172608 "objdump -D" for nfp .nffw files. 172609 172610 PR 27854 172611 * nfp-dis.c (_NFP_ISLAND_MAX, _NFP_ME_MAX): Define. 172612 (nfp_priv_data): ..and use here. 172613 (_print_instrs): Sanity check island and menum. 172614 1726152021-09-01 Alan Modra <amodra@gmail.com> 172616 172617 PR28250, Null pointer dereference in debug_class_type_samep 172618 Typo fix, obviously should be m1->variants != NULL, not 172619 m1->variants == NULL. 172620 172621 PR 28250 172622 * debug.c (debug_class_type_samep): Correct m1->variants test. 172623 1726242021-09-01 GDB Administrator <gdbadmin@sourceware.org> 172625 172626 Automatic date update in version.in 172627 1726282021-08-31 Simon Marchi <simon.marchi@polymtl.ca> 172629 172630 gdb: remove breakpoint_find_if 172631 Remove breakpoint_find_if, replace its sole usage with using 172632 all_breakpoints directly instead. At the same time, change return 172633 types to use bool. 172634 172635 Change-Id: I9ec392236b4804b362d16ab563330b9c07311106 172636 1726372021-08-31 Nick Clifton <nickc@redhat.com> 172638 172639 Update the how-to-make-a-release document so that a check for empty manual pages is included. cf PR 28144 172640 1726412021-08-31 Nelson Chu <nelson.chu@sifive.com> 172642 172643 RISC-V: Extend .insn directive to support hardcode encoding. 172644 The .insn directive can let users use their own instructions, or 172645 some new instruction, which haven't supported in the old binutils. 172646 For example, if users want to use sifive cache instruction, they 172647 cannot just write "cflush.d1.l1" in the assembly code, they should 172648 use ".insn i SYSTEM, 0, x0, x10, -0x40". But the .insn directive 172649 may not easy to use for some cases, and not so friendly to users. 172650 Therefore, I believe most of the users will use ".word 0xfc050073", 172651 to encode the instructions directly, rather than use .insn. But 172652 once we have supported the mapping symbols, the .word directives 172653 are marked as data, so disassembler won't dump them as instructions 172654 as usual. I have discussed this with Kito many times, we all think 172655 extend the .insn direcitve to support the hardcode encoding, is the 172656 easiest way to resolve the problem. Therefore, there are two more 172657 .insn formats are proposed as follows, 172658 172659 (original) .insn <type>, <operand1>, <operand2>, ... 172660 .insn <insn-length>, <value> 172661 .insn <value> 172662 172663 The <type> is string, and the <insn-length> and <value> are constants. 172664 172665 gas/ 172666 * config/tc-riscv.c (riscv_ip_hardcode): Similar to riscv_ip, 172667 but assembles an instruction according to the hardcode values 172668 of .insn directive. 172669 * doc/c-riscv.texi: Document two new .insn formats. 172670 * testsuite/gas/riscv/insn-fail.d: New testcases. 172671 * testsuite/gas/riscv/insn-fail.l: Likewise. 172672 * testsuite/gas/riscv/insn-fail.s: Likewise. 172673 * testsuite/gas/riscv/insn.d: Updated. 172674 * testsuite/gas/riscv/insn.s: Likewise. 172675 1726762021-08-31 John Baldwin <jhb@FreeBSD.org> 172677 172678 Use gdbfmt for vprintf_filtered. 172679 gdbfmt was already used for printf_filtered, so using it for 172680 vprintf_filtered is more consistent. 172681 172682 As a result, all callers of vfprintf_maybe_filtered now use gdbfmt, so 172683 the function can be simplified to assume the gdbfmt case and remove 172684 the associated bool argument. Similary, vprintf_filtered is now a 172685 simple wrapper around vfprintf_filtered. 172686 1726872021-08-31 GDB Administrator <gdbadmin@sourceware.org> 172688 172689 Automatic date update in version.in 172690 1726912021-08-30 John Baldwin <jhb@FreeBSD.org> 172692 172693 fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered. 172694 The handler for 'info proc status' for native processes on FreeBSD 172695 uses the 'j' size modifier along with uintmax_t / intmax_t casts to 172696 output integer values for types such as off_t that are not aliases of 172697 a basic C type such as 'int' or 'long'. printf_filtered does not 172698 support the 'j' modifer, so this resulted in runtime errors in 172699 practice: 172700 172701 (gdb) info proc stat 172702 process 8674 172703 Name: ls 172704 State: T (stopped) 172705 Parent process: 8673 172706 Process group: 8674 172707 Session id: 2779 172708 Unrecognized format specifier 'j' in printf 172709 172710 Instead, use plongest and pulongest to generate the output strings of 172711 these integer values. 172712 1727132021-08-30 Simon Marchi <simon.marchi@polymtl.ca> 172714 172715 gdb: fix build error in unittests/parallel-for-selftests.c 172716 We get this error when building GDB on some platforms. I get it using 172717 g++-10 on Ubuntu 20.04 (installed using the distro package). It was 172718 also reported by John Baldwin, using a clang that uses libc++. 172719 172720 CXX unittests/parallel-for-selftests.o 172721 cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ 172722 /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c: In function 'void selftests::parallel_for::test(int)': 172723 /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:53:30: error: use of deleted function 'std::atomic<int>::atomic(const std::atomic<int>&)' 172724 53 | std::atomic<int> counter = 0; 172725 | ^ 172726 In file included from /usr/include/c++/9/future:42, 172727 from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/thread-pool.h:29, 172728 from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:26, 172729 from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22: 172730 /usr/include/c++/9/atomic:755:7: note: declared here 172731 755 | atomic(const atomic&) = delete; 172732 | ^~~~~~ 172733 /usr/include/c++/9/atomic:759:17: note: after user-defined conversion: 'constexpr std::atomic<int>::atomic(std::atomic<int>::__integral_type)' 172734 759 | constexpr atomic(__integral_type __i) noexcept : __base_type(__i) { } 172735 | ^~~~~~ 172736 172737 I haven't dug to know why it does not happen everywhere, but this patch 172738 fixes it by using the constructor to initialize the variable, rather 172739 than the assignment operator. 172740 172741 Change-Id: I6b27958171bf6187f6a875657395fd10441db7e6 172742 1727432021-08-30 Nelson Chu <nelson.chu@sifive.com> 172744 172745 RISC-V: PR28291, Fix the gdb fails that PR27916 caused. 172746 * According to PR28291, we get the following unexpected gdb behavior, 172747 172748 (gdb) disassemble 0x0,+4 172749 Dump of assembler code from 0x0 to 0x4: 172750 0x0000000000000000: 172751 0x0000000000000001: 172752 0x0000000000000002: 172753 0x0000000000000003: 172754 End of assembler dump. 172755 172756 * This patch should fix it to the right behavior, 172757 172758 (gdb) disassemble 0x0,+4 172759 Dump of assembler code from 0x0 to 0x4: 172760 0x0000000000000000: Cannot access memory at address 0x0 172761 172762 opcodes/ 172763 pr 28291 172764 * riscv-dis.c (print_insn_riscv): Return STATUS if it is not zero. 172765 1727662021-08-30 Tom Tromey <tom@tromey.com> 172767 172768 Add some parallel_for_each tests 172769 Tom de Vries noticed that a patch in the DWARF scanner rewrite series 172770 caused a regression in parallel_for_each -- it started crashing in the 172771 case where the number of threads is 0 (there was an unchecked use of 172772 "n-1" that was used to size an array). 172773 172774 He also pointed out that there were no tests of parallel_for_each. 172775 This adds a few tests of parallel_for_each, primarily testing that 172776 different settings for the number of threads will work. This test 172777 catches the bug that he found in that series. 172778 1727792021-08-30 Tom Tromey <tom@tromey.com> 172780 172781 Add a show function for "maint show worker-threads" 172782 I wanted to see how many threads gdb thought it was using, but 172783 "maint show worker-threads" only reported "unlimited". This patch 172784 adds a show function so that it will now report the number of threads 172785 gdb has started. 172786 172787 Regression tested on x86-64 Fedora 34. 172788 1727892021-08-30 Tom de Vries <tdevries@suse.de> 172790 172791 [gdb/cli] Don't assert on empty string for core-file 172792 With current gdb we run into: 172793 ... 172794 $ gdb -batch '' '' 172795 : No such file or directory. 172796 pathstuff.cc:132: internal-error: \ 172797 gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \ 172798 Assertion `path != NULL && path[0] != '\0'' failed. 172799 ... 172800 172801 Fix this by skipping the call to gdb_abspath in core_target_open in the 172802 empty-string case, such that we have instead: 172803 ... 172804 $ gdb -batch '' '' 172805 : No such file or directory. 172806 : No such file or directory. 172807 $ 172808 ... 172809 172810 Tested on x86_64-linux. 172811 172812 gdb/ChangeLog: 172813 172814 2021-08-30 Tom de Vries <tdevries@suse.de> 172815 172816 PR cli/28290 172817 * gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the 172818 empty-string case. 172819 172820 gdb/testsuite/ChangeLog: 172821 172822 2021-08-30 Tom de Vries <tdevries@suse.de> 172823 172824 PR cli/28290 172825 * gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests. 172826 1728272021-08-30 Nelson Chu <nelson.chu@sifive.com> 172828 172829 RISC-V: PR27916, Support mapping symbols. 172830 Similar to ARM/AARCH64, we add mapping symbols in the symbol table, 172831 to mark the start addresses of data and instructions. The $d means 172832 data, and the $x means instruction. Then the disassembler uses these 172833 symbols to decide whether we should dump data or instruction. 172834 172835 Consider the mapping-04 test case, 172836 $ cat tmp.s 172837 .text 172838 .option norelax 172839 .option norvc 172840 .fill 2, 4, 0x1001 172841 .byte 1 172842 .word 0 172843 .balign 8 172844 add a0, a0, a0 172845 .fill 5, 2, 0x2002 172846 add a1, a1, a1 172847 .data 172848 .word 0x1 # No need to add mapping symbols. 172849 .word 0x2 172850 172851 $ riscv64-unknown-elf-as tmp.s -o tmp.o 172852 $ riscv64-unknown-elf-objdump -d tmp.o 172853 172854 Disassembly of section .text: 172855 172856 0000000000000000 <.text>: 172857 0: 00001001 .word 0x00001001 # Marked $d, .fill directive. 172858 4: 00001001 .word 0x00001001 172859 8: 00000001 .word 0x00000001 # .byte + part of .word. 172860 c: 00 .byte 0x00 # remaining .word. 172861 d: 00 .byte 0x00 # Marked $d, odd byte of alignment. 172862 e: 0001 nop # Marked $x, nops for alignment. 172863 10: 00a50533 add a0,a0,a0 172864 14: 20022002 .word 0x20022002 # Marked $d, .fill directive. 172865 18: 20022002 .word 0x20022002 172866 1c: 2002 .short 0x2002 172867 1e: 00b585b3 add a1,a1,a1 # Marked $x. 172868 22: 0001 nop # Section tail alignment. 172869 24: 00000013 nop 172870 172871 * Use $d and $x to mark the distribution of data and instructions. 172872 Alignments of code are recognized as instructions, since we usually 172873 fill nops for them. 172874 172875 * If the alignment have odd bytes, then we cannot just fill the nops 172876 into the spaces. We always fill an odd byte 0x00 at the start of 172877 the spaces. Therefore, add a $d mapping symbol for the odd byte, 172878 to tell disassembler that it isn't an instruction. The behavior 172879 is same as Arm and Aarch64. 172880 172881 The elf/linux toolchain regressions all passed. Besides, I also 172882 disable the mapping symbols internally, but use the new objudmp, the 172883 regressions passed, too. Therefore, the new objudmp should dump 172884 the objects corretly, even if they don't have any mapping symbols. 172885 172886 bfd/ 172887 pr 27916 172888 * cpu-riscv.c (riscv_elf_is_mapping_symbols): Define mapping symbols. 172889 * cpu-riscv.h: extern riscv_elf_is_mapping_symbols. 172890 * elfnn-riscv.c (riscv_maybe_function_sym): Do not choose mapping 172891 symbols as a function name. 172892 (riscv_elf_is_target_special_symbol): Add mapping symbols. 172893 binutils/ 172894 pr 27916 172895 * testsuite/binutils-all/readelf.s: Updated. 172896 * testsuite/binutils-all/readelf.s-64: Likewise. 172897 * testsuite/binutils-all/readelf.s-64-unused: Likewise. 172898 * testsuite/binutils-all/readelf.ss: Likewise. 172899 * testsuite/binutils-all/readelf.ss-64: Likewise. 172900 * testsuite/binutils-all/readelf.ss-64-unused: Likewise. 172901 gas/ 172902 pr 27916 172903 * config/tc-riscv.c (make_mapping_symbol): Create a new mapping symbol. 172904 (riscv_mapping_state): Decide whether to create mapping symbol for 172905 frag_now. Only add the mapping symbols to text sections. 172906 (riscv_add_odd_padding_symbol): Add the mapping symbols for the 172907 riscv_handle_align, which have odd bytes spaces. 172908 (riscv_check_mapping_symbols): Remove any excess mapping symbols. 172909 (md_assemble): Marked as MAP_INSN. 172910 (riscv_frag_align_code): Marked as MAP_INSN. 172911 (riscv_init_frag): Add mapping symbols for frag, it usually called 172912 by frag_var. Marked as MAP_DATA for rs_align and rs_fill, and 172913 marked as MAP_INSN for rs_align_code. 172914 (s_riscv_insn): Marked as MAP_INSN. 172915 (riscv_adjust_symtab): Call riscv_check_mapping_symbols. 172916 * config/tc-riscv.h (md_cons_align): Defined to riscv_mapping_state 172917 with MAP_DATA. 172918 (TC_SEGMENT_INFO_TYPE): Record mapping state for each segment. 172919 (TC_FRAG_TYPE): Record the first and last mapping symbols for the 172920 fragments. The first mapping symbol must be placed at the start 172921 of the fragment. 172922 (TC_FRAG_INIT): Defined to riscv_init_frag. 172923 * testsuite/gas/riscv/mapping-01.s: New testcase. 172924 * testsuite/gas/riscv/mapping-01a.d: Likewise. 172925 * testsuite/gas/riscv/mapping-01b.d: Likewise. 172926 * testsuite/gas/riscv/mapping-02.s: Likewise. 172927 * testsuite/gas/riscv/mapping-02a.d: Likewise. 172928 * testsuite/gas/riscv/mapping-02b.d: Likewise. 172929 * testsuite/gas/riscv/mapping-03.s: Likewise. 172930 * testsuite/gas/riscv/mapping-03a.d: Likewise. 172931 * testsuite/gas/riscv/mapping-03b.d: Likewise. 172932 * testsuite/gas/riscv/mapping-04.s: Likewise. 172933 * testsuite/gas/riscv/mapping-04a.d: Likewise. 172934 * testsuite/gas/riscv/mapping-04b.d: Likewise. 172935 * testsuite/gas/riscv/mapping-norelax-04a.d: Likewise. 172936 * testsuite/gas/riscv/mapping-norelax-04b.d: Likewise. 172937 * testsuite/gas/riscv/no-relax-align.d: Updated. 172938 * testsuite/gas/riscv/no-relax-align-2.d: Likewise. 172939 include/ 172940 pr 27916 172941 * opcode/riscv.h (enum riscv_seg_mstate): Added. 172942 172943 opcodes/ 172944 pr 27916 172945 * riscv-dis.c (last_map_symbol, last_stop_offset, last_map_state): 172946 Added to dump sections with mapping symbols. 172947 (riscv_get_map_state): Get the mapping state from the symbol. 172948 (riscv_search_mapping_symbol): Check the sorted symbol table, and 172949 then find the suitable mapping symbol. 172950 (riscv_data_length): Decide which data size we should print. 172951 (riscv_disassemble_data): Dump the data contents. 172952 (print_insn_riscv): Handle the mapping symbols. 172953 (riscv_symbol_is_valid): Marked mapping symbols as invalid. 172954 1729552021-08-30 Tom de Vries <tdevries@suse.de> 172956 172957 [gdb/testsuite] Improve argument syntax of proc arange 172958 The current syntax of proc arange is: 172959 ... 172960 proc arange { arange_start arange_length {comment ""} {seg_sel ""} } { 172961 ... 172962 and a typical call looks like: 172963 ... 172964 arange $start $len 172965 ... 172966 172967 This style is somewhat annoying because if you want to specify the last 172968 parameter, you need to give the default values of all the other optional ones 172969 before as well: 172970 ... 172971 arange $start $len "" $seg_sel 172972 ... 172973 172974 Update the syntax to: 172975 ... 172976 proc arange { options arange_start arange_length } { 172977 parse_options { 172978 { comment "" } 172979 { seg_sel "" } 172980 } 172981 ... 172982 such that a typical call looks like: 172983 ... 172984 arange {} $start $len 172985 ... 172986 and a call using seg_sel looks like: 172987 ... 172988 arange { 172989 seg_sel $seg_sel 172990 } $start $len 172991 ... 172992 172993 Also update proc aranges, which already has an options argument, to use the 172994 new proc parse_options. 172995 172996 Tested on x86_64-linux. 172997 172998 Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> 172999 1730002021-08-30 GDB Administrator <gdbadmin@sourceware.org> 173001 173002 Automatic date update in version.in 173003 1730042021-08-29 GDB Administrator <gdbadmin@sourceware.org> 173005 173006 Automatic date update in version.in 173007 1730082021-08-28 H.J. Lu <hjl.tools@gmail.com> 173009 173010 ld: Change indirect symbol from IR to undefined 173011 bfd/ 173012 173013 PR ld/28264 173014 * elflink.c (_bfd_elf_merge_symbol): Change indirect symbol from 173015 IR to undefined. 173016 173017 ld/ 173018 173019 PR ld/28264 173020 * testsuite/ld-plugin/lto.exp: Run PR ld/28264 test. 173021 * testsuite/ld-plugin/pr28264-1.d: New file. 173022 * testsuite/ld-plugin/pr28264-2.d: Likewise. 173023 * testsuite/ld-plugin/pr28264-3.d: Likewise. 173024 * testsuite/ld-plugin/pr28264-4.d: Likewise. 173025 * testsuite/ld-plugin/pr28264.c: Likewise. 173026 * testsuite/ld-plugin/pr28264.ver: Likewise. 173027 1730282021-08-28 Alan Modra <amodra@gmail.com> 173029 173030 PR28264, ld.bfd crash on linking efivar with LTO 173031 PR 28264 173032 PR 26978 173033 * linker.c (_bfd_generic_link_add_one_symbol <MIND>): Check 173034 that string is non-NULL. 173035 1730362021-08-28 GDB Administrator <gdbadmin@sourceware.org> 173037 173038 Automatic date update in version.in 173039 1730402021-08-27 Tom de Vries <tdevries@suse.de> 173041 173042 [gdb/symtab] Don't write .gdb_index symbol table with empty entries 173043 When comparing the sizes of the index files generated for shlib 173044 outputs/gdb.dwarf2/dw2-zero-range/shr1.sl, I noticed a large difference 173045 between .debug_names: 173046 ... 173047 $ gdb -q -batch $shlib -ex "save gdb-index -dwarf-5 ." 173048 $ du -b -h shr1.sl.debug_names shr1.sl.debug_str 173049 61 shr1.sl.debug_names 173050 0 shr1.sl.debug_str 173051 ... 173052 and .gdb_index: 173053 ... 173054 $ gdb -q -batch $shlib -ex "save gdb-index ." 173055 $ du -b -h shr1.sl.gdb-index 173056 8.2K shr1.sl.gdb-index 173057 ... 173058 173059 The problem is that the .gdb_index contains a non-empty symbol table with only 173060 empty entries. 173061 173062 Fix this by making the symbol table empty, such that we have instead: 173063 ... 173064 $ du -b -h shr1.sl.gdb-index 173065 184 shr1.sl.gdb-index 173066 ... 173067 173068 Tested on x86_64-linux. 173069 1730702021-08-27 Tom de Vries <tdevries@suse.de> 173071 173072 [gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.exp 173073 Before commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in 173074 dwarf assembly" we had in exec outputs/gdb.dlang/watch-loc/watch-loc a D 173075 compilation unit at offset 0xc7: 173076 ... 173077 Compilation Unit @ offset 0xc7: 173078 Length: 0x4c (32-bit) 173079 Version: 4 173080 Abbrev Offset: 0x64 173081 Pointer Size: 8 173082 <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit) 173083 <d3> DW_AT_language : 19 (D) 173084 ... 173085 with a corresponding .debug_aranges entry: 173086 ... 173087 Offset into .debug_info: 0xc7 173088 Pointer Size: 4 173089 Segment Size: 0 173090 173091 Address Length 173092 004004a7 0000000b 173093 00000000 00000000 173094 ... 173095 173096 After that commit we have a dummy CU at offset 0xc7 and the D compilation unit 173097 at offset 0xd2: 173098 ... 173099 Compilation Unit @ offset 0xc7: 173100 Length: 0x7 (32-bit) 173101 Version: 4 173102 Abbrev Offset: 0x64 173103 Pointer Size: 8 173104 Compilation Unit @ offset 0xd2: 173105 Length: 0x4c (32-bit) 173106 Version: 4 173107 Abbrev Offset: 0x65 173108 Pointer Size: 8 173109 <0><dd>: Abbrev Number: 2 (DW_TAG_compile_unit) 173110 <de> DW_AT_language : 19 (D) 173111 ... 173112 while the .debug_aranges entry still points to 0xc7. 173113 173114 The problem is that the test-case uses a hack (quoting from 173115 commit 75f06e9dc59): 173116 ... 173117 [ Note: this is a non-trivial test-case. The file watch-loc-dw.S contains a 173118 .debug_info section, but not an .debug_aranges section or any actual code. 173119 The file watch-loc.c contains code and a .debug_aranges section, but no other 173120 debug section. So, the intent for the .debug_aranges section in watch-loc.c 173121 is to refer to a compilation unit in the .debug_info section in 173122 watch-loc-dw.S. ] 173123 ... 173124 and adding the dummy CU caused that hack to stop working. 173125 173126 Fix this by moving the generation of .debug_aranges from watch-loc.c to 173127 watch-loc.exp, such that we have: 173128 ... 173129 Offset into .debug_info: 0xd2 173130 Pointer Size: 4 173131 Segment Size: 0 173132 173133 Address Length 173134 004004a7 0000000b 173135 00000000 00000000 173136 ... 173137 173138 Tested on x86_64-linux. 173139 1731402021-08-27 Tom de Vries <tdevries@suse.de> 173141 173142 [gdb/testsuite] Generate .debug_aranges entry for dummy CU 173143 A best practise for DWARF [1] is to generate .debug_aranges entries for CUs 173144 even if they have no address range. 173145 173146 Generate .debug_arange entries for the dummy CUs added by the DWARF assembler. 173147 173148 Tested on x86_64-linux. 173149 173150 [1] http://wiki.dwarfstd.org/index.php?title=Best_Practices 173151 1731522021-08-27 Tom de Vries <tdevries@suse.de> 173153 173154 [gdb/testsuite] Add .debug_aranges in more test-cases 173155 A couple of test-cases fail when run with target board cc-with-debug-names due 173156 to missing .debug_aranges entries for the CUs added by the dwarf assembler. 173157 173158 Add a .debug_aranges entry for those CUs. 173159 173160 Tested on x86_64-linux. 173161 1731622021-08-27 Tom de Vries <tdevries@suse.de> 173163 173164 [gdb/testsuite] Support .debug_aranges in dwarf assembly 173165 Add a proc aranges such that we can generate .debug_aranges sections in dwarf 173166 assembly using: 173167 ... 173168 cu { label cu_label } { 173169 ... 173170 } 173171 173172 aranges {} cu_label { 173173 arange $addr $len [<comment>] [$segment_selector] 173174 } 173175 ... 173176 173177 Tested on x86_64-linux. 173178 1731792021-08-27 Tom de Vries <tdevries@suse.de> 173180 173181 [gdb/testsuite] Add label option to proc cu 173182 We can use current dwarf assembly infrastructure to declare a label that marks 173183 the start of the CU header: 173184 ... 173185 declare_labels header_start_cu_a 173186 _section ".debug_info" 173187 header_start_cu_a : cu {} { 173188 } 173189 _section ".debug_info" 173190 header_start_cu_b : cu {} { 173191 } 173192 ... 173193 on the condition that we switch to the .debug_info section before, which makes 173194 this style of use fragile. 173195 173196 Another way to achieve the same is to use the label as generated by the cu 173197 proc itself: 173198 ... 173199 variable _cu_label 173200 cu {} { 173201 } 173202 set header_start_cu_a $_cu_label 173203 cu {} { 173204 } 173205 set header_start_cu_b $_cu_label 173206 ... 173207 but again that seems fragile given that adding a new CU inbetween will 173208 silently result in the wrong value for the label. 173209 173210 Add a label option to proc cu such that we can simply do: 173211 ... 173212 cu { label header_start_cu_a } { 173213 } 173214 cu { label header_start_cu_b } { 173215 } 173216 ... 173217 173218 Tested on x86_64-linux. 173219 1732202021-08-27 GDB Administrator <gdbadmin@sourceware.org> 173221 173222 Automatic date update in version.in 173223 1732242021-08-26 Andrew Burgess <andrew.burgess@embecosm.com> 173225 173226 gdb: remove some stray newlines in debug output 173227 I spotted a couple of stray newlines that were left at the end of 173228 debug message during conversion to the new debug output scheme. These 173229 messages are part of the 'set debug lin-lwp 1' output. 173230 1732312021-08-26 GDB Administrator <gdbadmin@sourceware.org> 173232 173233 Automatic date update in version.in 173234 1732352021-08-25 GDB Administrator <gdbadmin@sourceware.org> 173236 173237 Automatic date update in version.in 173238 1732392021-08-24 Tom Tromey <tom@tromey.com> 173240 173241 Fix two regressions caused by CU / TU merging 173242 PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test 173243 suite when using the "fission" target board. They are both caused by 173244 the patches that merge the list of CUs with the list of TUs (and to a 173245 lesser degree by the patches to share DWARF data across objfiles), and 173246 the underlying issue is the same: it turns out that reading a DWO can 173247 cause new type units to be created. This means that the list of 173248 dwarf2_per_cu_data objects depends on precisely which CUs have been 173249 expanded. However, because the type units can be created while 173250 expanding a CU means that the vector of CUs can expand while it is 173251 being iterated over -- a classic mistake. Also, because a TU can be 173252 added later, it means the resize_symtabs approach is incorrect. 173253 173254 This patch fixes resize_symtabs by removing it, and having set_symtab 173255 resize the vector on demand. It fixes the iteration problem by 173256 introducing a safe (index-based) iterator and changing the relevant 173257 spots to use it. 173258 173259 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160 173260 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893 173261 1732622021-08-24 Alan Modra <amodra@gmail.com> 173263 173264 Real programmers don't configure gcc using --with-ld 173265 * testsuite/lib/ld-lib.exp (run_host_cmd): Give a clue as to why 173266 gcc -B doesn't pick up the ld under test. 173267 1732682021-08-24 Alan Modra <amodra@gmail.com> 173269 173270 objdump -S test fail on mingw 173271 FAIL: objdump -S 173272 FAIL: objdump --source-comment 173273 is seen on mingw for the simple reason that gcc adds a .exe suffix on 173274 the output file if not already present. Fix that, and tidy some objcopy 173275 tests. 173276 173277 * testsuite/lib/binutils-common.exp (exeext): New proc. 173278 * testsuite/binutils-all/objcopy.exp (exe, test_prog): Use it here. 173279 (objcopy_remove_relocations_from_executable): Catch objcopy errors. 173280 Only run on ELF targets. 173281 * testsuite/binutils-all/objdump.exp (exe): Set variable. 173282 (test_build_id_debuglink, test_objdump_S): Use exe file suffix. 173283 1732842021-08-24 James Bowman (FTDI-UK) <james.bowman@ftdichip.com> 173285 173286 FT32: Remove recursion in ft32_opcode 173287 The function ft32_opcode used recursion. This could cause a stack 173288 overflow. Replaced with a pair of non-recursive functions. 173289 173290 PR 28169 173291 * ft32-dis.c: Formatting. 173292 (ft32_opcode1): Split out from.. 173293 (ft32_opcode): ..here. 173294 1732952021-08-24 GDB Administrator <gdbadmin@sourceware.org> 173296 173297 Automatic date update in version.in 173298 1732992021-08-23 Tom Tromey <tom@tromey.com> 173300 173301 Fix a latent bug in dw2-ranges-overlap.exp 173302 dw2-ranges-overlap.exp creates a program where a psymtab has two 173303 address ranges, and a function without debug info whose address is 173304 between these two ranges. Then it sets a breakpoint on this function 173305 and runs to it, expecting that the language should remain "auto; c" 173306 when stopped. 173307 173308 However, this test case also has a "main" function described (briefly) 173309 in the DWARF, and this function is given language C++. Also, a 173310 breakpoint stop sets the current language to the language that was 173311 used when setting the breakpoint. 173312 173313 My new DWARF scanner decides that this "main" is the main program and 173314 sets the current language to C++ at startup, causing this test to 173315 fail. 173316 173317 This patch fixes the test in a simple way, by introducing a new 173318 function that takes the place of "main" in the DWARF. I think this 173319 still exercises the original problem, but also avoids problems with my 173320 branch. 173321 173322 It seemed safe to me to submit this separately. 173323 1733242021-08-23 Tom de Vries <tdevries@suse.de> 173325 173326 [gdb] Fix 'not in executable format' error message 173327 With trying to load a non-executable file into gdb, we run into PR26880: 173328 ... 173329 $ gdb -q -batch test.c 173330 "0x7ffc87bfc8d0s": not in executable format: \ 173331 file format not recognized 173332 ... 173333 173334 The problem is caused by using %ps in combination with the error function 173335 (note that confusingly, it does work in combination with the warning 173336 function). 173337 173338 Fix this by using plain "%s" instead. 173339 173340 Tested on x86_64-linux. 173341 173342 gdb/ChangeLog: 173343 173344 2021-08-22 Tom de Vries <tdevries@suse.de> 173345 173346 PR gdb/26880 173347 * gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to 173348 error function. 173349 173350 gdb/testsuite/ChangeLog: 173351 173352 2021-08-22 Tom de Vries <tdevries@suse.de> 173353 173354 PR gdb/26880 173355 * gdb.base/non-executable.exp: New file. 173356 1733572021-08-23 Tom de Vries <tdevries@suse.de> 173358 173359 [gdb/testsuite] Use compiler-generated instead of gas-generated stabs 173360 The test-case gdb.dwarf2/dw2-ranges.exp is the only one in the gdb testsuite 173361 that uses gas-generated stabs. 173362 173363 While the use seems natural alongside the use of gas-generated dwarf in the 173364 same test-case, there are a few known issues, filed on the gdb side as: 173365 - PR symtab/12497 - "stabs: PIE relocation does not work" 173366 - PR symtab/28221 - "[readnow, stabs] FAIL: gdb.dwarf2/dw2-ranges.exp: \ 173367 info line func" 173368 and on the gas side as: 173369 - PR gas/28233 - "[gas, --gstabs] Generate stabs more similar to gcc" 173370 173371 The test-case contains a KFAIL for PR12497, but it's outdated and fails to 173372 trigger. 173373 173374 The intention of the test-case is to test gas-generated dwarf, and using 173375 gcc-generated stabs instead of gas-generated stabs works fine. 173376 173377 Supporting compiler-generated stabs is already a corner-case for gdb, and 173378 there's no current commitment/incentive to support/workaround gas-generated 173379 stabs, which can be considered a corner-case of a corner-case. 173380 173381 Work around these problem by using compiler-generated stabs in the test-case. 173382 173383 Tested on x86_64-linux. 173384 173385 gdb/testsuite/ChangeLog: 173386 173387 2021-08-22 Tom de Vries <tdevries@suse.de> 173388 173389 * gdb.dwarf2/dw2-ranges.exp: Use compiler-generated stabs. 173390 1733912021-08-23 Tom de Vries <tdevries@suse.de> 173392 173393 [gdb/testsuite] Add dummy start and end CUs in dwarf assembly 173394 Say one compiles a hello.c: 173395 ... 173396 $ gcc -g hello.c 173397 ... 173398 173399 On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the 173400 first in .debug_info, nor the last, due to presence of debug information in 173401 objects for sources like: 173402 - ../sysdeps/x86_64/start.S 173403 - init.c 173404 - ../sysdeps/x86_64/crti.S 173405 - elf-init.c 173406 - ../sysdeps/x86_64/crtn.S. 173407 173408 On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the 173409 first and the last in .debug_info. 173410 173411 This difference has caused me to find some errors in the dwarf assembly 173412 using openSUSE, that didn't show up on other platforms. 173413 173414 Force the same situation on other platforms by adding a dummy start 173415 and end CU. 173416 173417 Tested on x86_64-linux. 173418 173419 gdb/testsuite/ChangeLog: 173420 173421 2021-08-22 Tom de Vries <tdevries@suse.de> 173422 173423 PR testsuite/28235 173424 * lib/dwarf.exp (Dwarf::dummy_cu): New proc. 173425 (Dwarf::assemble): Add dummy start and end CU. 173426 1734272021-08-23 Tom de Vries <tdevries@suse.de> 173428 173429 [gdb/testsuite] Fix dw2-ranges-psym.exp with -readnow 173430 When running test-case gdb.dwarf2/dw2-ranges-psym.exp with target board 173431 -readnow, I run into: 173432 ... 173433 (gdb) file dw2-ranges-psym^M 173434 Reading symbols from dw2-ranges-psym...^M 173435 Expanding full symbols from dw2-ranges-psym...^M 173436 (gdb) set complaints 0^M 173437 (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints 173438 ... 173439 173440 The problem is that the regexp expects a gdb prompt immediately after the 173441 "Reading symbols" line. 173442 173443 Fix this by updating the regexp. 173444 173445 Tested on x86_64-linux. 173446 173447 gdb/testsuite/ChangeLog: 173448 173449 2021-08-22 Tom de Vries <tdevries@suse.de> 173450 173451 * lib/gdb.exp (gdb_load_no_complaints): Update regexp to allow 173452 "Expanding full symbols" Line. 173453 1734542021-08-23 GDB Administrator <gdbadmin@sourceware.org> 173455 173456 Automatic date update in version.in 173457 1734582021-08-22 Mike Frysinger <vapier@gentoo.org> 173459 173460 sim: m32r: add __linux__ hack for non-Linux hosts 173461 The m32r Linux syscall emulation logic assumes the host environment 173462 directly matches -- it's being run on 32-bit little endian Linux. 173463 This breaks building for non-Linux systems, so put all the code in 173464 __linux__ ifdef checks. This code needs a lot of love to make it 173465 work everywhere, but let's at least unbreak it for non-Linux hosts. 173466 1734672021-08-22 GDB Administrator <gdbadmin@sourceware.org> 173468 173469 Automatic date update in version.in 173470 1734712021-08-21 GDB Administrator <gdbadmin@sourceware.org> 173472 173473 Automatic date update in version.in 173474 1734752021-08-20 Mike Frysinger <vapier@gentoo.org> 173476 173477 sim: nltvals: switch output mode to a directory 173478 In preparation for this script generating more files, change the output 173479 argument to specify a directory. This drops the stdout behavior, but 173480 since no one really runs this tool directly, it's not a big deal. 173481 1734822021-08-20 GDB Administrator <gdbadmin@sourceware.org> 173483 173484 Automatic date update in version.in 173485 1734862021-08-19 Simon Marchi <simon.marchi@polymtl.ca> 173487 173488 gdb: use bool in notify_command_param_changed_p and do_set_command 173489 Trivial patch to use bool instead of int. 173490 173491 Change-Id: I9e5f8ee4305272a6671cbaaaf2f0484eff0d1ea5 173492 1734932021-08-19 H.J. Lu <hjl.tools@gmail.com> 173494 173495 x86: Put back 3 aborts in OP_E_memory 173496 Put back 3 aborts where invalid lengths should have been filtered out. 173497 173498 gas/ 173499 173500 PR binutils/28247 173501 * testsuite/gas/i386/bad-bcast.s: Add a comment. 173502 173503 opcodes/ 173504 173505 PR binutils/28247 173506 * * i386-dis.c (OP_E_memory): Put back 3 aborts. 173507 1735082021-08-19 H.J. Lu <hjl.tools@gmail.com> 173509 173510 x86: Avoid abort on invalid broadcast 173511 Print "{bad}" on invalid broadcast instead of abort. 173512 173513 gas/ 173514 173515 PR binutils/28247 173516 * testsuite/gas/i386/bad-bcast.d: New file. 173517 * testsuite/gas/i386/bad-bcast.s: Likewise. 173518 * testsuite/gas/i386/i386.exp: Run bad-bcast. 173519 173520 opcodes/ 173521 173522 PR binutils/28247 173523 * i386-dis.c (OP_E_memory): Print "{bad}" on invalid broadcast 173524 instead of abort. 173525 1735262021-08-19 Aaron Merey <amerey@redhat.com> 173527 173528 gdb/solib: Refactor scan_dyntag 173529 scan_dyntag is unnecessarily duplicated in solib-svr4.c and solib-dsbt.c. 173530 173531 Move this function to solib.c and rename it to gdb_bfd_scan_elf_dyntag. 173532 Also add it to solib.h so it is included in both solib-svr4 and solib-dsbt. 173533 1735342021-08-19 GDB Administrator <gdbadmin@sourceware.org> 173535 173536 Automatic date update in version.in 173537 1735382021-08-18 Will Schmidt <will_schmidt@vnet.ibm.com> 173539 173540 [gdb] [rs6000] Add ppc64_linux_gcc_target_options method. 173541 Add a method to set the gcc target options for the ppc64 targets. 173542 This change sets an empty value, which allows the gcc 173543 default values (-mcmodel=medium) be used, instead of -mcmodel=large 173544 which is set by the default_gcc_target_options hook. 173545 173546 [gdb] [rs6000] Add ppc64*_gnu_triplet_regexp methods. 173547 Add methods to set the target triplet so we can 173548 find the proper gcc when our gcc is named of 173549 the form powerpc64{le}-<foo>-gcc or ppc64{le}-<foo>-gcc. 173550 1735512021-08-18 Alan Modra <amodra@gmail.com> 173552 173553 Re: as: Replace the removed symbol with the versioned symbol 173554 Some targets, typically embedded without shared libraries, replace the 173555 relocation symbol with a section symbol (see tc_fix_adjustable). 173556 Allow the test to pass for such targets. Fixes the following. 173557 173558 avr-elf +FAIL: symver symver16 173559 d10v-elf +FAIL: symver symver16 173560 dlx-elf +FAIL: symver symver16 173561 ip2k-elf +FAIL: symver symver16 173562 m68k-elf +FAIL: symver symver16 173563 mcore-elf +FAIL: symver symver16 173564 pj-elf +FAIL: symver symver16 173565 s12z-elf +FAIL: symver symver16 173566 visium-elf +FAIL: symver symver16 173567 z80-elf +FAIL: symver symver16 173568 173569 PR gas/28157 173570 * testsuite/gas/symver/symver16.d: Relax reloc match. 173571 1735722021-08-18 Alan Modra <amodra@gmail.com> 173573 173574 [GOLD] PowerPC64 relocation overflow for -Os register save/restore funcs 173575 Fixes a silly mistake in calculating the address of -Os out-of-line 173576 register save/restore function copies. Copies of these linker defined 173577 functions are added to stub sections when the original (in 173578 target->savres_section) can't be reached. 173579 173580 * powerpc.cc (Target_powerpc::Relocate::relocate): Correct address 173581 calculation of out-of-line save/restore function copies. 173582 1735832021-08-18 Alan Modra <amodra@gmail.com> 173584 173585 Another ld script backtrack 173586 * ldgram.y (length_spec): Throw away look-ahead NAME. 173587 1735882021-08-18 Mike Frysinger <vapier@gentoo.org> 173589 173590 gdb: fix spacing on CCLD silent rules 173591 173592 sim: nltvals: localize TARGET_<ERRNO> defines 173593 Code should not be using these directly, instead they should be 173594 resolving these dynamically via cb_host_to_target_errno maps. 173595 Fix the Blackfin code and remove the defines out of the header 173596 so no new code can rely on them. 173597 1735982021-08-18 Mike Frysinger <vapier@gentoo.org> 173599 173600 sim: rename ChangeLog files to ChangeLog-2021 173601 Now that ChangeLog entries are no longer used for sim patches, 173602 this commit renames all relevant sim ChangeLog to ChangeLog-2021, 173603 similar to what we would do in the context of the "Start of New 173604 Year" procedure. 173605 173606 The purpose of this change is to avoid people merging ChangeLog 173607 entries by mistake when applying existing commits that they are 173608 currently working on. 173609 173610 Also throw in a .gitignore entry to keep people from adding new 173611 ChangeLog files anywhere in the sim tree. 173612 1736132021-08-18 GDB Administrator <gdbadmin@sourceware.org> 173614 173615 Automatic date update in version.in 173616 1736172021-08-17 Simon Marchi <simon.marchi@polymtl.ca> 173618 173619 gdb: fix thread_step_over_chain_length 173620 If I debug a single-thread program and look at the infrun debug logs, I 173621 see: 173622 173623 [infrun] start_step_over: stealing global queue of threads to step, length = 2 173624 173625 That makes no sense... turns out there's a buglet in 173626 thread_step_over_chain_length, "num" should be initialized to 0. I 173627 think this bug is a leftover from an earlier version of the code (not 173628 merged upstream) that manually walked the list, where the first item was 173629 implicitly counted (hence the 1). 173630 173631 Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce 173632 1736332021-08-17 Shahab Vahedi <shahab@synopsys.com> 173634 173635 opcodes: Fix the auxiliary register numbers for ARC HS 173636 The numbers for the auxiliary registers "tlbindex" and 173637 "tlbcommand" of ARCv2HS are incorrect. This patch makes 173638 the following changes to correct that error. 173639 173640 ,------------.-----------------.---------------. 173641 | aux. reg. | old (incorrect) | new (correct) | 173642 |------------+-----------------+---------------| 173643 | tlbindex | 0x463 | 0x464 | 173644 | tlbcommand | 0x464 | 0x465 | 173645 `------------^-----------------^---------------' 173646 173647 opcodes/ 173648 2021-08-17 Shahab Vahedi <shahab@synopsys.com> 173649 173650 * arc-regs.h (DEF): Fix the register numbers. 173651 1736522021-08-17 H.J. Lu <hjl.tools@gmail.com> 173653 173654 gdb: Don't assume r_ldsomap when r_version > 1 on Linux 173655 The r_ldsomap field is specific to Solaris (part of librtld_db), and 173656 should never be accessed for Linux. glibc is planning to add a field 173657 to support multiple namespaces. But there will be no r_ldsomap when 173658 r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets 173659 to set r_ldsomap_offset to -1 and use them for Linux targets. 173660 173661 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236 173662 1736632021-08-17 H.J. Lu <hjl.tools@gmail.com> 173664 173665 gdbserver: Check r_version < 1 for Linux debugger interface 173666 Update gdbserver to check r_version < 1 instead of r_version != 1 so 173667 that r_version can be bumped for a new field in the glibc debugger 173668 interface to support multiple namespaces. Since so far, the gdbserver 173669 only reads fields defined for r_version == 1, it is compatible with 173670 r_version >= 1. 173671 173672 All future glibc debugger interface changes will be backward compatible. 173673 If there is ever the need for backward incompatible change to the glibc 173674 debugger interface, a new DT_XXX element will be provided to access the 173675 new incompatible interface. 173676 173677 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11839 173678 1736792021-08-17 Andrea Corallo <andrea.corallo@arm.com> 173680 173681 PATCH [4/4] arm: Add Tag_PACRET_use build attribute 173682 bfd/ 173683 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173684 173685 * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 173686 'Tag_PACRET_use' case. 173687 173688 binutils/ 173689 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173690 173691 * readelf.c (arm_attr_tag_PAC_extension): Declare. 173692 (arm_attr_public_tags): Add 'PAC_extension' lookup. 173693 173694 elfcpp/ 173695 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173696 173697 * arm.h: Define 'Tag_PACRET_use' enum. 173698 173699 gas/ 173700 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173701 173702 * config/tc-arm.c (arm_convert_symbolic_attribute): Add 173703 'Tag_PACRET_use' to the attribute_table. 173704 173705 include/ 173706 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173707 173708 * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PACRET_use'. 173709 1737102021-08-17 Andrea Corallo <andrea.corallo@arm.com> 173711 173712 PATCH [3/4] arm: Add Tag_BTI_use build attribute 173713 bfd/ 173714 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173715 173716 * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 173717 'Tag_BTI_use' case. 173718 173719 binutils/ 173720 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173721 173722 * readelf.c (arm_attr_tag_PAC_extension): Declare. 173723 (arm_attr_public_tags): Add 'PAC_extension' lookup. 173724 173725 elfcpp/ 173726 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173727 173728 * arm.h: Define 'Tag_BTI_use' enum. 173729 173730 gas/ 173731 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173732 173733 * config/tc-arm.c (arm_convert_symbolic_attribute): Add 173734 'Tag_BTI_use' to the attribute_table. 173735 173736 include/ 173737 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173738 173739 * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_use'. 173740 1737412021-08-17 Andrea Corallo <andrea.corallo@arm.com> 173742 173743 PATCH [2/4] arm: Add Tag_BTI_extension build attribute 173744 bfd/ 173745 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173746 173747 * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 173748 'Tag_BTI_extension' case. 173749 173750 binutils/ 173751 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173752 173753 * readelf.c (arm_attr_tag_PAC_extension): Declare. 173754 (arm_attr_public_tags): Add 'PAC_extension' lookup. 173755 173756 elfcpp/ 173757 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173758 173759 * arm.h: Define 'Tag_BTI_extension' enum. 173760 173761 gas/ 173762 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173763 173764 * config/tc-arm.c (arm_convert_symbolic_attribute): Add 173765 'Tag_BTI_extension' to the attribute_table. 173766 173767 include/ 173768 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173769 173770 * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_extension'. 173771 1737722021-08-17 Andrea Corallo <andrea.corallo@arm.com> 173773 173774 PATCH [1/4] arm: Add Tag_PAC_extension build attribute 173775 bfd/ 173776 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173777 173778 * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 173779 'Tag_PAC_extension' case. 173780 173781 binutils/ 173782 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173783 173784 * readelf.c (arm_attr_tag_PAC_extension): Declare. 173785 (arm_attr_public_tags): Add 'PAC_extension' lookup. 173786 173787 elfcpp/ 173788 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173789 173790 * arm.h: Define 'Tag_PAC_extension' enum. 173791 173792 gas/ 173793 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173794 173795 * config/tc-arm.c (arm_convert_symbolic_attribute): Add 173796 'Tag_PAC_extension' to the attribute_table. 173797 173798 include/ 173799 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> 173800 173801 * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PAC_extension'. 173802 1738032021-08-17 H.J. Lu <hjl.tools@gmail.com> 173804 173805 x86: Always run fp tests 173806 Always run fp tests since the size of .tfloat, .ds.x, .dc.x and .dcb.x 173807 directive outputs is always 10 bytes. There is no need for fp-elf32 nor 173808 fp-elf64. 173809 173810 PR gas/28230 173811 * testsuite/gas/i386/fp-elf32.d: Removed. 173812 * testsuite/gas/i386/fp-elf64.d: Likewise. 173813 * testsuite/gas/i386/fp.s: Remove NO_TFLOAT_PADDING codes. 173814 * testsuite/gas/i386/i386.exp: Don't run fp-elf32 nor fp-elf64. 173815 Always run fp. 173816 1738172021-08-17 GDB Administrator <gdbadmin@sourceware.org> 173818 173819 Automatic date update in version.in 173820 1738212021-08-16 H.J. Lu <hjl.tools@gmail.com> 173822 173823 x86: Don't pad .tfloat directive output 173824 .tfloat output should always be 10 bytes without padding, independent 173825 of psABIs. In glibc, x86 assembly codes expect 10-byte .tfloat output. 173826 This also reduces .ds.x output and .tfloat output with hex input from 173827 12 bytes to 10 bytes to match .tfloat output. 173828 173829 PR gas/28230 173830 * NEWS: Mention changes of .ds.x output and .tfloat output with 173831 hex input. 173832 * config/tc-i386.c (x86_tfloat_pad): Removed. 173833 * config/tc-i386.h (X_PRECISION_PAD): Changed to 0. 173834 (x86_tfloat_pad): Removed. 173835 * testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined, 173836 add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x 173837 directives. 173838 * testsuite/gas/i386/i386.exp (ASFLAGS): Append 173839 "--defsym NO_TFLOAT_PADDING=1" when running the fp test. 173840 1738412021-08-16 Tom Tromey <tromey@adacore.com> 173842 173843 Fix register regression in DWARF evaluator 173844 On an internal test case, using an arm-elf target, commit ba5bc3e5a92 173845 ("Make DWARF evaluator return a single struct value") causes a 173846 regression. (It doesn't happen for any of the other cross targets 173847 that I test when importing upstream gdb.) 173848 173849 I don't know if there's an upstream gdb test case showing the same 173850 problem... I can only really run native tests with dejagnu AFAIK. 173851 173852 The failure manifests like this: 173853 173854 Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5 173855 173856 Whereas when it works it looks like: 173857 173858 Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5 173859 173860 The difference is that the new code uses the passed-in gdbarch, 173861 whereas the old code used the frame's gdbarch, when handling 173862 DWARF_VALUE_REGISTER. 173863 173864 This patch restores the use of the frame's arch. 173865 1738662021-08-16 Tom Tromey <tromey@adacore.com> 173867 173868 Fix Ada regression due to DWARF expression series 173869 Commit 0579205aec4 ("Simplify dwarf_expr_context class interface") 173870 caused a regression in the internal AdaCore test suite. I didn't try 173871 to reproduce this with the GDB test suite, but the test is identical 173872 to gdb.dwarf2/dynarr-ptr.exp. 173873 173874 The problem is that this change: 173875 173876 case DW_OP_push_object_address: 173877 /* Return the address of the object we are currently observing. */ 173878 - if (this->data_view.data () == nullptr 173879 - && this->obj_address == 0) 173880 + if (this->m_addr_info == nullptr) 173881 173882 ... slightly changes the logic here. In particular, it's possible for 173883 the caller to pass in a non-NULL m_addr_info, but one that looks like: 173884 173885 (top) p *this.m_addr_info 173886 $15 = { 173887 type = 0x29b7a70, 173888 valaddr = { 173889 m_array = 0x0, 173890 m_size = 0 173891 }, 173892 addr = 0, 173893 next = 0x0 173894 } 173895 173896 In this case, an additional check is needed. With the current code, 173897 what happens instead is that the computation computes an incorrect 173898 address -- but one that does not fail in read_memory, due to the 173899 precise memory map of the embedded target in question. 173900 173901 This patch restores the old logic. 173902 1739032021-08-16 Patrick Monnerat <patrick@monnerat.net> 173904 173905 Notify observer of breakpoint auto-disabling 173906 As breakpoint_modified observer is currently notified upon breakpoint stop 173907 before handling auto-disabling when enable count is reached, the observer 173908 is never notified of the disabling. 173909 173910 The problem affects: 173911 - The MI interpreter enabled= value when reporting =breakpoint-modified 173912 - A Python event handler for breakpoint_modified using the "enabled" 173913 member of its parameter 173914 - insight: breakpoint GUI window is not properly updated upon auto-disable 173915 173916 This patch moves the observer notification after the auto-disabling 173917 code and implements corresponding tests for the MI and Python cases. 173918 173919 Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=23336 173920 173921 Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61 173922 1739232021-08-16 H.J. Lu <hjl.tools@gmail.com> 173924 173925 as: Replace the removed symbol with the versioned symbol 173926 When a symbol removed by .symver is used in relocation and there is one 173927 and only one versioned symbol, don't remove the symbol. Instead, mark 173928 it to be removed and replace the removed symbol used in relocation with 173929 the versioned symbol before generating relocation. 173930 173931 PR gas/28157 173932 * symbols.c (symbol_flags): Add removed. 173933 (symbol_entry_find): Updated. 173934 (symbol_mark_removed): New function. 173935 (symbol_removed_p): Likewise. 173936 * symbols.h (symbol_mark_removed): New prototype. 173937 (symbol_removed_p): Likewise. 173938 * write.c (write_relocs): Call obj_fixup_removed_symbol on 173939 removed fixp->fx_addsy and fixp->fx_subsy if defined. 173940 (set_symtab): Don't add a symbol if symbol_removed_p returns true. 173941 * config/obj-elf.c (elf_frob_symbol): Don't remove the symbol 173942 if it is used on relocation. Instead, mark it as to be removed 173943 and issue an error if the symbol has more than one versioned name. 173944 (elf_fixup_removed_symbol): New function. 173945 * config/obj-elf.h (elf_fixup_removed_symbol): New prototype. 173946 (obj_fixup_removed_symbol): New. 173947 * testsuite/gas/symver/symver11.d: Updated expected error 173948 message. 173949 * testsuite/gas/symver/symver16.d: New file. 173950 * testsuite/gas/symver/symver16.s: Likewise. 173951 1739522021-08-16 GDB Administrator <gdbadmin@sourceware.org> 173953 173954 Automatic date update in version.in 173955 1739562021-08-15 GDB Administrator <gdbadmin@sourceware.org> 173957 173958 Automatic date update in version.in 173959 1739602021-08-14 Alan Modra <amodra@gmail.com> 173961 173962 ld script fill pattern expression 173963 It turns out we do need to backtrack when parsing after all. The 173964 fill_opt component in the section rule swiches to EXPRESSION and back 173965 to SCRIPT, and to find the end of an expression it is necessary to 173966 look ahead one token. 173967 173968 * ldgram.y (section): Throw away lookahead NAME token. 173969 (overlay_section): Likewise. 173970 * testsuite/ld-elf/overlay.t: Add fill pattern on overlays. 173971 Test fill pattern before stupidly named normal sections too, 173972 and before /DISCARD/. 173973 1739742021-08-14 GDB Administrator <gdbadmin@sourceware.org> 173975 173976 Automatic date update in version.in 173977 1739782021-08-13 Alan Modra <amodra@gmail.com> 173979 173980 ld lexer tidy, possibly break the world 173981 This tidies the states in which ld lexer rules are enabled. 173982 This change will quite likely trip over issues similar to those 173983 mentioned in the new ldlex.l comments, so please test it out. 173984 173985 * ldgram.y (wildcard_name): Remove now unnecessary components. 173986 * ldlex.l: Restrict many rules' states. Remove -l expression 173987 state rule. Comment on lookahead state madness and need for 173988 /DISCARD/ in expression state. 173989 1739902021-08-13 Alan Modra <amodra@gmail.com> 173991 173992 ld script lower-case absolute and sizeof_headers 173993 I think these happened by accident, so let's see what breaks if they 173994 are removed. 173995 173996 * ldlex.l: Remove lower case "absolute" and "sizeof_headers" 173997 in non-mri mode. 173998 * ld.texi: Remove sizeof_headers index. 173999 * testsuite/ld-mmix/mmohdr1.ld: Use SIZEOF_HEADERS. 174000 1740012021-08-13 Alan Modra <amodra@gmail.com> 174002 174003 tidy mri script extern 174004 MRI mode generally doesn't flip lexer states, so let's make MRI mode 174005 "extern" not do so either. 174006 174007 * ldgram.y (extern_name_list): Don't change lex state here. 174008 (ifile_p1): Change state here on EXTERN instead. 174009 1740102021-08-13 Alan Modra <amodra@gmail.com> 174011 174012 Re: PR28217, Syntax error when memory region contains a hyphen 174013 I discovered some more errors when tightening up the lexer rules. 174014 Just because we INCLUDE a file doesn't mean we've switched states. 174015 174016 PR 28217 174017 * ldgram.y (statement): Don't switch lexer state on INCLUDE. 174018 (mri_script_command, ifile_p1, memory_spec, section): Likewise. 174019 1740202021-08-13 Lifang Xia <lifang_xia@c-sky.com> 174021 174022 PR28168: [CSKY] Fix stack overflow in disassembler 174023 PR 28168: 174024 Stack overflow with a large float. %f is not a goot choice for this. 174025 %f should be replaced with %.7g. 174026 174027 gas/ 174028 * testsuite/gas/csky/pr28168.d: New testcase for PR 28168. 174029 * testsuite/gas/csky/pr28168.s: Likewise. 174030 * testsuite/gas/csky/v2_float_part2.d: Following the new format. 174031 * opcodes/csky-dis.c (csky_output_operand): %.7g replaces %f. 174032 1740332021-08-13 Alan Modra <amodra@gmail.com> 174034 174035 PR28217, Syntax error when memory region contains a hyphen 174036 The saga of commit 40726f16a8d7 continues. This attacks the problem 174037 of switching between SCRIPT and EXPRESSION state lexing by removing 174038 the need to do so for phdrs like ":text". Instead {WILDCHAR}* 174039 matching, the reason why ":text" lexed as one token, is restricted to 174040 within the braces of a section or overlay statement. The new WILD 174041 lexer state is switched at the non-optional brace tokens, so 174042 ldlex_backup is no longer needed. I've also removed the BOTH state, 174043 which doesn't seem to be needed any more. Besides rules involving 174044 error reporting, there was just one place where SCRIPT appeared 174045 without BOTH, the {WILDCHAR}* rule, three where BOTH appears without 174046 SCRIPT for tokens that only need EXPRESSION state, and two where BOTH 174047 appears alongside INPUT_LIST. (Since I'm editing the wild and 174048 filename rules, removing BOTH and adding WILD can also be seen as 174049 renaming the old BOTH state to SCRIPT and renaming the old SCRIPT 174050 state to WILD with a reduced scope.) 174051 174052 As a followup, I'll look at removing EXPRESSION state from some lexer 174053 rules that no longer need it due to this cleanup. 174054 174055 PR 28217 174056 * ldgram.y (exp <ORIGIN, LENGTH>): Use paren_script_name. 174057 (section): Parse within braces of section in wild mode, and 174058 after brace back in script mode. Remove ldlex_backup call. 174059 Similarly for OVERLAY. 174060 (overlay_section): Similarly. 174061 (script_file): Replace ldlex_both with ldlex_script. 174062 * ldlex.h (ldlex_wild): Declare. 174063 (ldlex_both): Delete. 174064 * ldlex.l (BOTH): Delete. Remove state from all rules. 174065 (WILD): New state. Enable many tokens in this state. 174066 Enable filename match in SCRIPT mode. Enable WILDCHAR match 174067 in WILD state, disable in SCRIPT mode. 174068 (ldlex_wild): New function. 174069 * ldfile.c (ldfile_try_open_bfd): Replace ldlex_both call with 174070 ldlex_script. 174071 1740722021-08-13 Alan Modra <amodra@gmail.com> 174073 174074 ns32k configury 174075 Since ns32k-netbsd is as yet not removed, just marked obsolete, 174076 the target should still be accepted with --enable-obsolete. 174077 174078 I also enabled ns32k-openbsd in ld since there doesn't seem to be a 174079 good reason why that target is not supported there but is elsewhere. 174080 174081 bfd/ 174082 * config.bfd: Allow ns32k-netbsd. 174083 ld/ 174084 * configure.tgt: Allow ns32k-openbsd. 174085 1740862021-08-13 GDB Administrator <gdbadmin@sourceware.org> 174087 174088 Automatic date update in version.in 174089 1740902021-08-13 Lancelot SIX <lsix@lancelotsix.com> 174091 174092 gdb: riscv_scan_prologue: handle LD and LW instructions 174093 While working on the testsuite, I ended up noticing that GDB fails to 174094 produce a full backtrace from a thread waiting in pthread_join. When 174095 selecting the waiting thread and using the 'bt' command, the following 174096 result can be observed: 174097 174098 (gdb) bt 174099 #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 174100 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 174101 Backtrace stopped: frame did not save the PC 174102 174103 On my platform, I do not have debug symbols for glibc, so I need to rely 174104 on prologue analysis in order to unwind stack. 174105 174106 Here is what the function prologue looks like: 174107 174108 (gdb) disassemble __pthread_clockjoin_ex 174109 Dump of assembler code for function __pthread_clockjoin_ex: 174110 0x0000003ff7fc42de <+0>: addi sp,sp,-144 174111 0x0000003ff7fc42e0 <+2>: sd s5,88(sp) 174112 0x0000003ff7fc42e2 <+4>: auipc s5,0xd 174113 0x0000003ff7fc42e6 <+8>: ld s5,-2(s5) # 0x3ff7fd12e0 174114 0x0000003ff7fc42ea <+12>: ld a5,0(s5) 174115 0x0000003ff7fc42ee <+16>: sd ra,136(sp) 174116 0x0000003ff7fc42f0 <+18>: sd s0,128(sp) 174117 0x0000003ff7fc42f2 <+20>: sd s1,120(sp) 174118 0x0000003ff7fc42f4 <+22>: sd s2,112(sp) 174119 0x0000003ff7fc42f6 <+24>: sd s3,104(sp) 174120 0x0000003ff7fc42f8 <+26>: sd s4,96(sp) 174121 0x0000003ff7fc42fa <+28>: sd s6,80(sp) 174122 0x0000003ff7fc42fc <+30>: sd s7,72(sp) 174123 0x0000003ff7fc42fe <+32>: sd s8,64(sp) 174124 0x0000003ff7fc4300 <+34>: sd s9,56(sp) 174125 0x0000003ff7fc4302 <+36>: sd a5,40(sp) 174126 174127 As far as prologue analysis is concerned, the most interesting part is 174128 done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores 174129 the RA (return address) register on the stack, which is the information 174130 we are looking for in order to identify the caller. 174131 174132 In the current implementation of the prologue scanner, GDB stops when 174133 hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do 174134 with the 'ld' instruction. GDB thinks it reached the end of the 174135 prologue but have not yet reached the important part, which explain 174136 GDB's inability to unwind past this point. 174137 174138 The section of the prologue starting at <+4> until <+12> is used to load 174139 the stack canary[1], which will then be placed on the stack at <+36> at 174140 the end of the prologue. 174141 174142 In order to have the prologue properly handled, this commit proposes to 174143 add support for the ld instruction in the RISC-V prologue scanner. 174144 I guess riscv32 would use lw in such situation so this patch also adds 174145 support for this instruction. 174146 174147 With this patch applied, gdb is now able to unwind past pthread_join: 174148 174149 (gdb) bt 174150 #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 174151 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 174152 #2 0x0000002aaaaaa88e in bar() () 174153 #3 0x0000002aaaaaa8c4 in foo() () 174154 #4 0x0000002aaaaaa8da in main () 174155 174156 I have had a look to see if I could reproduce this easily, but in my 174157 simple testcases using '-fstack-protector-all', the canary is loaded 174158 after the RA register is saved. I do not have a reliable way of 174159 generating a prologue similar to the problematic one so I forged one 174160 instead. 174161 174162 The testsuite have been run on riscv64 ubuntu 21.01 with no regression 174163 observed. 174164 174165 [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries 174166 1741672021-08-12 Tom Tromey <tromey@adacore.com> 174168 174169 Update documentation to mention Pygments 174170 Philippe Blain pointed out that the gdb documentation does not mention 174171 that Pygments may be used for source highlighting. This patch updates 174172 the docs to reflect how highlighting is actually done. 174173 1741742021-08-12 Simon Marchi <simon.marchi@polymtl.ca> 174175 174176 gdb: make gdbarch_printable_names return a vector 174177 I noticed that gdbarch_selftest::operator() leaked the value returned by 174178 gdbarch_printable_names. Make gdbarch_printable_names return an 174179 std::vector and update callers. That makes it easier for everyone 174180 involved, less manual memory management. 174181 174182 Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498 174183 1741842021-08-12 Carl Love <cel@us.ibm.com> 174185 174186 Improve forward progress test in python.exp 174187 The test steps into func2 and than does an up to get back to the previous 174188 frame. The test checks that the line number you are at after the up command 174189 is greater than the line where the function was called from. The 174190 assembly/codegen for the powerpc target includes a NOP after the 174191 branch-link. 174192 174193 func2 (); /* Break at func2 call site. / 174194 10000694: 59 00 00 48 bl 100006ec 174195 10000698: 00 00 00 60 nop 174196 return 0; / Break to end. */ 174197 1000069c: 00 00 20 39 li r9,0 174198 174199 The PC at the instruction following the branch-link is 0x10000698 which 174200 GDB.find_pc_line() maps to the same line number as the bl instruction. 174201 GDB did move past the branch-link location thus making forward progress. 174202 174203 The following proposed fix adds an additional PC check to see if forward 174204 progress was made. The line test is changed from greater than to greater 174205 than or equal. 174206 1742072021-08-12 Jiangshuai Li <jiangshuai_li@c-sky.com> 174208 174209 gdb:csky rm tdesc_has_registers in csky_register_name 174210 As CSKY arch has not parsed target-description.xml in csky_gdbarch_init, 174211 when a remote server, like csky-qemu or gdbserver, send a target-description.xml 174212 to gdb, tdesc_has_registers will return ture, but tdesc_register_name (gdbarch, 0) 174213 will return NULL, so a cmd "info registers r0" will not work. 174214 174215 Function of parsing target-description.xml will be add later for CSKY arch, 174216 now it is temporarily removed to allow me to do other supported tests. 174217 174218 2021-07-15 Jiangshuai Li <jiangshuai_li@c-sky.com> 174219 174220 * csky-tdep.c : not using tdesc funtions in csky_register_name 174221 1742222021-08-12 Alan Modra <amodra@gmail.com> 174223 174224 Re: gas: support NaN flavors 174225 Fixes tic4x-coff FAIL: simple FP constants 174226 174227 * testsuite/gas/all/float.s: Make NaN tests conditional on hasnan. 174228 * testsuite/gas/all/gas.exp: Define hasnan. 174229 1742302021-08-12 GDB Administrator <gdbadmin@sourceware.org> 174231 174232 Automatic date update in version.in 174233 1742342021-08-11 H.J. Lu <hjl.tools@gmail.com> 174235 174236 ld: Update the pass and fail strings of PR ld/28138 test 174237 PR ld/28138 174238 * testsuite/ld-plugin/lto.exp: Update the pass and fail strings 174239 of PR ld/28138 test to indicate which part of the test passed 174240 and failed. 174241 1742422021-08-11 Darius Galis <darius.galis@cyberthorstudios.com> 174243 174244 Fix a typo in the RX asse,bler. The Double-precision floating-point exception handling control register name is DECNT not DCENT. 174245 * config/rx-parse.y (DECNT): Fixed typo. 174246 * testsuite/gas/rx/dpopm.sm (DECNT): Fixed typo. 174247 * testsuite/gas/rx/dpushm.sm (DECNT): Fixed typo. 174248 * testsuite/gas/rx/macros.inc (DECNT): Fixed typo. 174249 1742502021-08-11 Nick Clifton <nickc@redhat.com> 174251 174252 Fix an internal error in the CSKY assembler when asked to resolve an overlarge constant. 174253 PR 28215 174254 * config/tc-csky.c (md_apply_fix): Correctly handle a fixup that 174255 involves an overlarge constant. 174256 1742572021-08-11 Luis Machado <luis.machado@linaro.org> 174258 174259 Add 3 new PAC-related ARM note types 174260 The following patch synchronizes includes/objdump/readelf with the Linux 174261 Kernel in terms of ARM regset notes. 174262 174263 We're currently missing 3 of them: 174264 174265 NT_ARM_PACA_KEYS 174266 NT_ARM_PACG_KEYS 174267 NT_ARM_PAC_ENABLED_KEYS 174268 174269 We don't need GDB to bother with this at the moment, so this doesn't update 174270 bfd/elf.c. If needed, we can do it in the future. 174271 174272 binutils/ 174273 174274 * readelf.c (get_note_type): Handle new ARM PAC notes. 174275 174276 include/elf/ 174277 174278 * common.h (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) 174279 (NT_ARM_PAC_ENABLED_KEYS): New constants. 174280 1742812021-08-11 Nick Clifton <nickc@redhat.com> 174282 174283 Updated Portuguese translation for the binutils sub-directory. 174284 1742852021-08-11 John Ericson <git@JohnEricson.me> 174286 174287 Deprecate a.out support for NetBSD targets. 174288 As discussed previously, a.out support is now quite deprecated, and in 174289 some cases removed, in both Binutils itself and NetBSD, so this legacy 174290 default makes little sense. `netbsdelf*` and `netbsdaout*` still work 174291 allowing the user to be explicit about there choice. Additionally, the 174292 configure script warns about the change as Nick Clifton requested. 174293 174294 One possible concern was the status of NetBSD on NS32K, where only a.out 174295 was supported. But per [1] NetBSD has removed support, and if it were to 174296 come back, it would be with ELF. The binutils implementation is 174297 therefore marked obsolete, per the instructions in the last message. 174298 174299 With that patch and this one applied, I have confirmed the following: 174300 174301 --target=i686-unknown-netbsd 174302 --target=i686-unknown-netbsdelf 174303 builds completely 174304 174305 --target=i686-unknown-netbsdaout 174306 properly fails because target is deprecated. 174307 174308 --target=vax-unknown-netbsdaout builds completely except for gas, where 174309 the target is deprecated. 174310 174311 [1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html 174312 --- 174313 bfd/config.bfd | 43 +++++++++++++-------- 174314 bfd/configure.ac | 5 +-- 174315 binutils/testsuite/binutils-all/nm.exp | 2 +- 174316 binutils/testsuite/lib/binutils-common.exp | 7 +--- 174317 config/picflag.m4 | 4 +- 174318 gas/configure.tgt | 9 +++-- 174319 gas/testsuite/gas/arm/blx-bl-convert.d | 2 +- 174320 gas/testsuite/gas/arm/blx-local-thumb.d | 2 +- 174321 gas/testsuite/gas/sh/basic.exp | 2 +- 174322 gdb/configure.host | 34 +++++++---------- 174323 gdb/configure.tgt | 2 +- 174324 gdb/testsuite/gdb.asm/asm-source.exp | 6 +-- 174325 intl/configure | 2 +- 174326 ld/configure.tgt | 44 +++++++++++----------- 174327 ld/testsuite/ld-arm/arm-elf.exp | 4 +- 174328 ld/testsuite/ld-elf/elf.exp | 2 +- 174329 ld/testsuite/ld-elf/shared.exp | 4 +- 174330 libiberty/configure | 4 +- 174331 1743322021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174333 174334 gdb: don't print backtrace when dumping core after an internal error 174335 Currently, when GDB hits an internal error, and the user selects to 174336 dump core, the recently added feature to write a backtrace to the 174337 console will kick in, and print a backtrace as well as dumping the 174338 core. 174339 174340 This was certainly not my intention when adding the backtrace on fatal 174341 signal functionality, this feature was intended to produce a backtrace 174342 when GDB crashes due to some fatal signal, internal errors should have 174343 continued to behave as they did before, unchanged. 174344 174345 In this commit I set the signal disposition of SIGABRT back to SIG_DFL 174346 just prior to the call to abort() that GDB uses to trigger the core 174347 dump, this prevents GDB reaching the code that writes the backtrace to 174348 the console. 174349 174350 I've also added a test that checks we don't see a backtrace on the 174351 console after an internal error. 174352 1743532021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174354 174355 gdb: register SIGBUS, SIGFPE, and SIGABRT handlers 174356 Register handlers for SIGBUS, SIGFPE, and SIGABRT. All of these 174357 signals are setup as fatal signals that will cause GDB to terminate. 174358 However, by passing these signals through the handle_fatal_signal 174359 function, a user can arrange to see a backtrace when GDB 174360 terminates (see maint set backtrace-on-fatal-signal). 174361 174362 In normal use of GDB there should be no user visible changes after 174363 this commit. Only if GDB terminates with one of the above signals 174364 will GDB change slightly, potentially printing a backtrace before 174365 aborting. 174366 174367 I've added new tests for SIGFPE, SIGBUS, and SIGABRT. 174368 1743692021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174370 174371 gdb: print backtrace on fatal SIGSEGV 174372 This commit adds a new maintenance feature, the ability to print 174373 a (limited) backtrace if GDB dies due to a fatal signal. 174374 174375 The backtrace is produced using the backtrace and backtrace_symbols_fd 174376 functions which are declared in the execinfo.h header, and both of 174377 which are async signal safe. A configure check has been added to 174378 check for these features, if they are not available then the new code 174379 is not compiled into GDB and the backtrace will not be printed. 174380 174381 The motivation for this new feature is to aid in debugging GDB in 174382 situations where GDB has crashed at a users site, but the user is 174383 reluctant to share core files, possibly due to concerns about what 174384 might be in the memory image within the core file. Such a user might 174385 be happy to share a simple backtrace that was written to stderr. 174386 174387 The production of the backtrace is on by default, but can switched off 174388 using the new commands: 174389 174390 maintenance set backtrace-on-fatal-signal on|off 174391 maintenance show backtrace-on-fatal-signal 174392 174393 Right now, I have hooked this feature in to GDB's existing handling of 174394 SIGSEGV only, but this will be extended to more signals in a later 174395 commit. 174396 174397 One additional change I have made in this commit is that, when we 174398 decide GDB should terminate due to the fatal signal, we now 174399 raise the same fatal signal rather than raising SIGABRT. 174400 174401 Currently, this is only effecting our handling of SIGSEGV. So, 174402 previously, if GDB hit a SEGV then we would terminate GDB with a 174403 SIGABRT. After this commit we will terminate GDB with a SIGSEGV. 174404 174405 This feels like an improvement to me, we should still get a core dump, 174406 but in many shells, the user will see a more specific message once GDB 174407 exits, in bash for example "Segmentation fault" rather than "Aborted". 174408 174409 Finally then, here is an example of the output a user would see if GDB 174410 should hit an internal SIGSEGV: 174411 174412 Fatal signal: Segmentation fault 174413 ----- Backtrace ----- 174414 ./gdb/gdb[0x8078e6] 174415 ./gdb/gdb[0x807b20] 174416 /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20] 174417 /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f] 174418 ./gdb/gdb[0x1540f4c] 174419 ./gdb/gdb[0x154034a] 174420 ./gdb/gdb[0x9b002d] 174421 ./gdb/gdb[0x9b014d] 174422 ./gdb/gdb[0x9b1aa6] 174423 ./gdb/gdb[0x9b1b0c] 174424 ./gdb/gdb[0x41756d] 174425 /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3] 174426 ./gdb/gdb[0x41746e] 174427 --------------------- 174428 A fatal error internal to GDB has been detected, further 174429 debugging is not possible. GDB will now terminate. 174430 174431 This is a bug, please report it. For instructions, see: 174432 <https://www.gnu.org/software/gdb/bugs/>. 174433 174434 Segmentation fault (core dumped) 174435 174436 It is disappointing that backtrace_symbols_fd does not actually map 174437 the addresses back to symbols, this appears, in part, to be due to GDB 174438 not being built with -rdynamic as the manual page for 174439 backtrace_symbols_fd suggests, however, even when I do add -rdynamic 174440 to the build of GDB I only see symbols for some addresses. 174441 174442 We could potentially look at alternative libraries to provide the 174443 backtrace (e.g. libunwind) however, the solution presented here, which 174444 is available as part of glibc is probably a good baseline from which 174445 we might improve things in future. 174446 1744472021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174448 174449 gdb: rename async_init_signals to gdb_init_signals 174450 The async_init_signals has, for some time, dealt with async and sync 174451 signals, so removing the async prefix makes sense I think. 174452 174453 Additionally, as pointed out by Pedro: 174454 174455 ..... 174456 174457 The comments relating to SIGTRAP and SIGQUIT within this function are 174458 out of date. 174459 174460 The comments for SIGTRAP talk about the signal disposition (SIG_IGN) 174461 being passed to the inferior, meaning the signal disposition being 174462 inherited by GDB's fork children. However, we now call 174463 restore_original_signals_state prior to forking, so the comment on 174464 SIGTRAP is redundant. 174465 174466 The comments for SIGQUIT are similarly out of date, further, the 174467 comment on SIGQUIT talks about problems with BSD4.3 and vfork, 174468 however, we have not supported BSD4.3 for several years now. 174469 174470 Given the above, it seems that changing the disposition of SIGTRAP is 174471 no longer needed, so I've deleted the signal() call for SIGTRAP. 174472 174473 Finally, the header comment on the function now called 174474 gdb_init_signals was getting quite out of date, so I've updated it 174475 to (hopefully) better reflect reality. 174476 174477 There should be no user visible change after this commit. 174478 1744792021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174480 174481 gdb: register signal handler after setting up event token 174482 This commit fixes the smallest of small possible bug related to signal 174483 handling. If we look in async_init_signals we see code like this: 174484 174485 signal (SIGQUIT, handle_sigquit); 174486 sigquit_token = 174487 create_async_signal_handler (async_do_nothing, NULL, "sigquit"); 174488 174489 Then if we look in handle_sigquit we see code like this: 174490 174491 mark_async_signal_handler (sigquit_token); 174492 signal (sig, handle_sigquit); 174493 174494 Finally, in mark_async_signal_handler we have: 174495 174496 async_handler_ptr->ready = 1; 174497 174498 Where async_handler_ptr will be sigquit_token. 174499 174500 What this means is that if a SIGQUIT arrive in async_init_signals 174501 after handle_sigquit has been registered, but before sigquit_token has 174502 been initialised, then GDB will most likely crash. 174503 174504 The chance of this happening is tiny, but fixing this is trivial, just 174505 ensure we call create_async_signal_handler before calling signal, so 174506 lets do that. 174507 174508 There are no tests for this. Trying to land a signal in the right 174509 spot is pretty hit and miss. I did try changing the current HEAD GDB 174510 like this: 174511 174512 signal (SIGQUIT, handle_sigquit); 174513 raise (SIGQUIT); 174514 sigquit_token = 174515 create_async_signal_handler (async_do_nothing, NULL, "sigquit"); 174516 174517 And confirmed that this did result in a crash, after my change I tried 174518 this: 174519 174520 sigquit_token = 174521 create_async_signal_handler (async_do_nothing, NULL, "sigquit"); 174522 signal (SIGQUIT, handle_sigquit); 174523 raise (SIGQUIT); 174524 174525 And GDB now starts up just fine. 174526 174527 gdb/ChangeLog: 174528 174529 * event-top.c (async_init_signals): For each signal, call signal 174530 only after calling create_async_signal_handler. 174531 1745322021-08-11 Andrew Burgess <andrew.burgess@embecosm.com> 174533 174534 gdb: terminate upon receipt of SIGFPE 174535 GDB's SIGFPE handling is broken, this is PR gdb/16505 and 174536 PR gdb/17891. 174537 174538 We currently try to use an async event token to process SIGFPE. So, 174539 when a SIGFPE arrives the signal handler calls 174540 mark_async_signal_handler then returns, effectively ignoring the 174541 signal (for now). 174542 174543 The intention is that later the event loop will see that the async 174544 token associated with SIGFPE has been marked and will call the async 174545 handler, which just throws an error. 174546 174547 The problem is that SIGFPE is not safe to ignore. Ignoring a 174548 SIGFPE (unless it is generated artificially, e.g. by raise()) is 174549 undefined behaviour, after ignoring the signal on many targets we 174550 return to the instruction that caused the SIGFPE to be raised, which 174551 immediately causes another SIGFPE to be raised, we get stuck in an 174552 infinite loop. The behaviour is certainly true on x86-64. 174553 174554 To view this behaviour I simply added some dummy code to GDB that 174555 performed an integer divide by zero, compiled this on x86-64 174556 GNU/Linux, ran GDB and saw GDB hang. 174557 174558 In this commit, I propose to remove all special handling of SIGFPE and 174559 instead just let GDB make use of the default SIGFPE action, that is, 174560 to terminate the process. 174561 174562 The only user visible change here should be: 174563 174564 - If a user sends a SIGFPE to GDB using something like kill, 174565 previously GDB would just print an error and remain alive, now GDB 174566 will terminate. This is inline with what happens if the user 174567 sends GDB a SIGSEGV from kill though, so I don't see this as an 174568 issue. 174569 174570 - If a bug in GDB causes a real SIGFPE, previously the users GDB 174571 session would hang. Now the GDB session will terminate. Again, 174572 this is inline with what happens if GDB receives a SIGSEGV due to 174573 an internal bug. 174574 174575 In bug gdb/16505 there is mention that it would be nice if GDB did 174576 more than just terminate when receiving a fatal signal. I haven't 174577 done that in this commit, but later commits will move in that 174578 direction. 174579 174580 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505 174581 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891 174582 1745832021-08-11 Alan Modra <amodra@gmail.com> 174584 174585 PR28198, Support # as linker script comment marker 174586 PR 28198 174587 * ldlex.l: Combine rules for handling newline, whitespace and 174588 comments. Extend # comment handling to all states. 174589 1745902021-08-11 Alan Modra <amodra@gmail.com> 174591 174592 ldgram.y tidies 174593 I've been tripped up before thinking the "end" rule was the "END" 174594 token. Let's use a better name. The formatting changes are for 174595 consistency within rules, and making it a little easier to visually 174596 separate tokens from mid-rule actions. 174597 174598 * ldgram.y (separator): Rename from "end". Update uses. 174599 (statement): Formatting. Move ';' match to beginning. 174600 (paren_script_name): Formatting. Simplify. 174601 (must_be_exp, section): Formatting. 174602 1746032021-08-11 Alan Modra <amodra@gmail.com> 174604 174605 Mention whitespace in script expressions 174606 Inside an output section statement, ld's parser can't tell whether a 174607 line 174608 .+=4; 174609 is an assignment to dot or a file named ".+=4". 174610 174611 * ld.texi (expressions): Mention need for whitespace. 174612 1746132021-08-11 Matt Jacobson <mhjacobson@me.com> 174614 174615 Add a -mno-dollar-line-separator command line option to the AVR assembler. 174616 Some frontends, like the gcc Objective-C frontend, emit symbols with $ 174617 characters in them. The AVR target code in gas treats $ as a line separator, 174618 so the code doesn?t assemble correctly. 174619 174620 Provide a machine-specific option to disable treating $ as a line separator. 174621 174622 * config/tc-avr.c (enum options): Add option flag. 174623 (struct option): Add option -mno-dollar-line-separator. 174624 (md_parse_option): Adjust treatment of $ when option is present. 174625 * config/tc-avr.h: Use avr_line_separator_chars. 174626 1746272021-08-11 Nick Clifton <nickc@redhat.com> 174628 174629 Fix typo in previous delta 174630 1746312021-08-11 Jan Beulich <jbeulich@suse.com> 174632 174633 gas: fold IEEE encoding of -Inf with that of +Inf 174634 The respective results differ only by the sign bits - there's no need to 174635 have basically identical (partially even arch-specific) logic twice. 174636 Simply set the sign bit at the end of encoding the various formats. 174637 1746382021-08-11 Jan Beulich <jbeulich@suse.com> 174639 174640 gas: support NaN flavors 174641 Like for infinity, there isn't just a single NaN. The sign bit may be 174642 of interest and, going beyond infinity, whether the value is quiet or 174643 signalling may be even more relevant to be able to encode. 174644 174645 Note that an anomaly with x86'es double extended precision NaN values 174646 gets taken care of at the same time: For all other formats a positive 174647 value with all mantissa bits set was used, while here a negative value 174648 with all non-significant mantissa bits clear was chose for an unknown 174649 reason. 174650 174651 For m68k, since I don't know their X_PRECISION floating point value 174652 layout, a warning gets issued if any of the new flavors was attempted 174653 to be encoded that way. However likely it may be that, given that the 174654 code lives in a source file supposedly implementing IEEE-compliant 174655 formats, the bit patterns of the individual words match x86'es, I didn't 174656 want to guess so. And my very, very old paper doc doesn't even mention 174657 floating point formats other than single and double. 174658 1746592021-08-11 Jan Beulich <jbeulich@suse.com> 174660 174661 Arm64: leave .bfloat16 processing to common code 174662 With x86 support having been implemented by extending atof-ieee.c, avoid 174663 unnecessary code duplication in md_atof(). This will then also allow to 174664 take advantage of adjustments made there without needing to mirror them 174665 here. 174666 174667 Arm32: leave more .bfloat16 processing to common code 174668 With x86 support having been implemented by extending atof-ieee.c, avoid 174669 unnecessary code duplication in md_atof(). This will then also allow to 174670 take advantage of adjustments made there without needing to mirror them 174671 here. 174672 174673 gas: make 2nd argument of .dcb.* consistently optional 174674 Unlike the forms consuming/producing integer data, the floating point 174675 ones so far required the 2nd argument to be present, contrary to 174676 documentation. To avoid code duplication, split float_length() out of 174677 hex_float() (taking the opportunity to adjust error message wording). 174678 1746792021-08-11 Jan Beulich <jbeulich@suse.com> 174680 174681 x86: introduce .bfloat16 directive 174682 This is to be able to generate data acted upon by AVX512-BF16 and 174683 AMX-BF16 insns. While not part of the IEEE standard, the format is 174684 sufficiently standardized to warrant handling in config/atof-ieee.c. 174685 Arm, where custom handling was implemented, may want to leverage this as 174686 well. To be able to also use the hex forms supported for other floating 174687 point formats, a small addition to the generic hex_float() is needed. 174688 174689 Extend existing x86 testcases. 174690 1746912021-08-11 Jan Beulich <jbeulich@suse.com> 174692 174693 x86: introduce .hfloat directive 174694 This is to be able to generate data passed to {,V}CVTPH2PS and acted 174695 upon by AVX512-FP16 insns. To be able to also use the hex forms 174696 supported for other floating point formats, a small addition to the 174697 generic hex_float() is needed. 174698 174699 Extend existing x86 testcases. 174700 1747012021-08-11 Jan Beulich <jbeulich@suse.com> 174702 174703 x86/ELF: fix .tfloat output with hex input 174704 The ELF psABI-s are quite clear here: On 32-bit the data type is 12 174705 bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16 174706 bytes long (with 6 bytes of padding). Make hex_float() capable of 174707 handling such padding. 174708 174709 Note that this brings the emitted data size of .dc.x / .dcb.x in line 174710 also for non-ELF targets; so far they were different depending on input 174711 format (dec vs hex). 174712 174713 Extend the existing x86 testcases. 174714 1747152021-08-11 Jan Beulich <jbeulich@suse.com> 174716 174717 x86/ELF: fix .ds.x output 174718 The ELF psABI-s are quite clear here: On 32-bit the underlying data type 174719 is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it 174720 is 16 bytes long (with 6 bytes of padding). Make s_space() capable of 174721 handling 'x' (and 'p') type floating point being other than 12 bytes 174722 wide (also adjusting documentation). This requires duplicating the 174723 definition of X_PRECISION in the target speciifc header; the compiler 174724 would complain if this was out of sync with config/atof-ieee.c. 174725 174726 Note that for now padding space doesn't get separated from actual 174727 storage, which means that things will work correctly only for little- 174728 endian cases, and which also means that by specifying large enough 174729 numbers padding space can be set to non-zero. Since the logic is needed 174730 for a single little-endian architecture only for now, I'm hoping that 174731 this might be acceptable for the time being; otherwise the change will 174732 become more intrusive. 174733 174734 Note also that this brings the emitted data size of .ds.x vs .tfloat in 174735 line for non-ELF targets as well; the issue will be even more obvious 174736 when further taking into account a subsequent patch fixing .dc.x/.dcb.x 174737 (where output sizes currently differ depending on input format). 174738 174739 Extend existing x86 testcases. 174740 1747412021-08-11 Jan Beulich <jbeulich@suse.com> 174742 174743 x86/ELF: fix .tfloat output 174744 The ELF psABI-s are quite clear here: On 32-bit the data type is 12 174745 bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16 174746 bytes long (with 6 bytes of padding). Make ieee_md_atof() capable of 174747 handling such padding, and specify the needed padding for x86 (leaving 174748 non-ELF targets alone for now). Split the existing x86 testcase. 174749 174750 x86: have non-PE/COFF BEOS be recognized as ELF 174751 BEOS, unless explicitly requesting *-*-beospe* targets, uses standard 174752 ELF. None of the newly enabled tests in the testsuite fail for me. 174753 1747542021-08-11 Alan Modra <amodra@gmail.com> 174755 174756 PR28163, Segment fault in function rl78_special_reloc 174757 Relocation offset checks were completely missing in the rl78 backend, 174758 allowing a relocation to write over memory anywhere. This was true 174759 for rl78_special_reloc, a function primarily used when applying debug 174760 relocations, and in rl78_elf_relocate_section used by the linker. 174761 174762 This patch fixes those problems by correcting inaccuracies in the 174763 relocation howtos, then uses those howtos to sanity check relocation 174764 offsets before applying relocations. In addition, the patch 174765 implements overflow checking using the howto information rather than 174766 the ad-hoc scheme implemented in relocate_section. I implemented the 174767 overflow checking in rl78_special_reloc too. 174768 174769 * elf32-rl78.c (RL78REL, RL78_OP_REL): Add mask parameter. 174770 (rl78_elf_howto_table): Set destination masks. Correct size and 174771 bitsize of DIR32_REV. Correct complain_on_overflow for many relocs 174772 as per tests in relocate_section. Add RH_SFR. Correct bitsize 174773 for RH_SADDR. Set size to 3 and bitsize to 0 for all OP relocs. 174774 (check_overflow): New function. 174775 (rl78_special_reloc): Check that reloc address is within section. 174776 Apply relocations using reloc howto. Check for overflow. 174777 (RANGE): Delete. 174778 (rl78_elf_relocate_section): Sanity check r_offset. Perform 174779 overflow checking using reloc howto. 174780 1747812021-08-11 GDB Administrator <gdbadmin@sourceware.org> 174782 174783 Automatic date update in version.in 174784 1747852021-08-10 Tom Tromey <tom@tromey.com> 174786 174787 Ignore .debug_types when reading .debug_aranges 174788 I noticed that the fission-reread.exp test case can cause a complaint 174789 when run with --target_board=cc-with-debug-names: 174790 174791 warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges. 174792 174793 The bug here is that this executable has both .debug_info and 174794 .debug_types, and both have a CU at offset 0x0. This triggers the 174795 duplicate warning. 174796 174797 Because .debug_types doesn't provide any address ranges, these CUs can 174798 be ignored. That is, this bug turns out to be another regression from 174799 the info/types merger patch. 174800 174801 This patch fixes the problem by having this loop igore type units. 174802 fission-reread.exp is updated to test for the bug. 174803 1748042021-08-10 Tom Tromey <tom@tromey.com> 174805 174806 Generalize addrmap dumping 174807 While debugging another patch series, I wanted to dump an addrmap. I 174808 came up with this patch, which generalizes the addrmap-dumping code 174809 from psymtab.c and moves it to addrmap.c. psymtab.c is changed to use 174810 the new code. 174811 1748122021-08-10 Simon Marchi <simon.marchi@polymtl.ca> 174813 174814 gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit 174815 I spotted what I think is a buglet in proceed_after_vfork_done. After a 174816 vfork child exits or execs, we resume all the threads of the parent. To 174817 do so, we iterate on all threads using iterate_over_threads with the 174818 proceed_after_vfork_done callback. Each thread is resumed if the 174819 following condition is true: 174820 174821 if (thread->ptid.pid () == pid 174822 && thread->state == THREAD_RUNNING 174823 && !thread->executing 174824 && !thread->stop_requested 174825 && thread->stop_signal () == GDB_SIGNAL_0) 174826 174827 where `pid` is the pid of the vfork parent. This is not multi-target 174828 aware: since it only filters on pid, if there is an inferior with the 174829 same pid in another target, we could end up resuming a thread of that 174830 other inferior. The chances of the stars aligning for this to happen 174831 are tiny, but still. 174832 174833 Fix that by iterating only on the vfork parent's threads, instead of on 174834 all threads. This is more efficient, as we iterate on just the required 174835 threads (inferiors have their own thread list), and we can drop the pid 174836 check. The resulting code is also more straightforward in my opinion, 174837 so it's a win-win. 174838 174839 Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a 174840 1748412021-08-10 Nick Clifton <nickc@redhat.com> 174842 174843 Updated Serbian and Russian translations for various sub-directories 174844 1748452021-08-10 George Barrett <bob@bob131.so> 174846 174847 guile: fix smob exports 174848 Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added 174849 the created class to the exports list of (oop goops); v2.1+ does not 174850 implicitly create bindings in any modules. This means that the GDB 174851 manual subsection documenting exported types is not quite right when GDB 174852 is linked against Guile <v2.1 (types are exported from (oop goops)) 174853 instead of (gdb)) and incorrect when linked against Guile v2.1+ (types 174854 are not bound to any variables at all!). 174855 174856 There is a range of cases in which it's necessary or convenient to be 174857 able to refer to a GDB smob type, for instance: 174858 174859 - Pattern matching based on the type of a value. 174860 - Defining GOOPS methods handling values from GDB (GOOPS methods 174861 typically use dynamic dispatch based on the types of the arguments). 174862 - Type-checking assertions when applying some defensive programming on 174863 an interface. 174864 - Generally any other situation one might encounter in a dynamically 174865 typed language that might need some introspection. 174866 174867 If you're more familiar with Python, it would be quite similar to being 174868 unable to refer to the classes exported from the GDB module (which is to 174869 say: not crippling for the most part, but makes certain tasks more 174870 difficult than necessary). 174871 174872 This commit makes a small change to GDB's smob registration machinery 174873 to make sure registered smobs get exported from the current 174874 module. This will likely cause warnings to the user about conflicting 174875 exports if they load both (gdb) and (oop goops) from a GDB linked 174876 against Guile v2.0, but it shouldn't impact functionality (and seemed 174877 preferable to trying to un-export bindings from (oop goops) if v2.0 174878 was detected). 174879 174880 [1]: This changed with Guile commit 174881 28d0871b553a3959a6c59e2e4caec1c1509f8595 174882 174883 gdb/ChangeLog: 174884 174885 2021-06-07 George Barrett <bob@bob131.so> 174886 174887 * guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered 174888 smob type from the current module. 174889 174890 gdb/testsuite/ChangeLog: 174891 174892 2021-06-07 George Barrett <bob@bob131.so> 174893 174894 * gdb.guile/scm-gsmob.exp (test exports): Add tests to make 174895 sure the smob types currently listed in the GDB manual get 174896 exported from the (gdb) module. 174897 174898 Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7 174899 1749002021-08-10 GDB Administrator <gdbadmin@sourceware.org> 174901 174902 Automatic date update in version.in 174903 1749042021-08-09 Nick Clifton <nickc@redhat.com> 174905 174906 GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory. 174907 * dwarf2dbg.c (get_directory_table_entry): Ensure that dir[0] 174908 contains current working directory. 174909 (out_dir_and_file_list): Likewise. 174910 * testsuite/gas/elf/dwarf-5-dir0.s: New test source file. 174911 * testsuite/gas/elf/dwarf-5-dir0.d: New test driver. 174912 * testsuite/gas/elf/elf.exp: Run the new test. 174913 * testsuite/gas/elf/dwarf-5-file0.d: Adjust expected output. 174914 * testsuite/gas/i386/dwarf5-line-1.d: Likewise. 174915 * testsuite/gas/i386/dwarf5-line-2.d: Likewise. 174916 1749172021-08-09 GDB Administrator <gdbadmin@sourceware.org> 174918 174919 Automatic date update in version.in 174920 1749212021-08-08 Tom Tromey <tom@tromey.com> 174922 174923 Include objfiles.h in a few .c files 174924 I found a few .c files that rely on objfiles.h, but that only include 174925 it indirectly, via dwarf2/read.h -> psympriv.h. If that include is 174926 removed (something my new DWARF indexer series does), then the build 174927 will break. 174928 174929 It seemed harmless and correct to add these includes now, making the 174930 eventual series a little smaller. 174931 1749322021-08-08 GDB Administrator <gdbadmin@sourceware.org> 174933 174934 Automatic date update in version.in 174935 1749362021-08-07 Alan Modra <amodra@gmail.com> 174937 174938 PR28186, SEGV elf.c:7991:30 in _bfd_elf_fixup_group_sections 174939 PR 28186 174940 * elf.c (_bfd_elf_fixup_group_sections): Don't segfault on 174941 objcopy/strip with NULL output_section. 174942 1749432021-08-07 Alan Modra <amodra@gmail.com> 174944 174945 PR28176, rl78 complex reloc divide by zero 174946 This is a bit more than just preventing the divide by zero. Most of 174947 the patch is tidying up error reporting, so that for example, linking 174948 an object file with a reloc stack underflow produces a linker error 174949 rather than just displaying a message that might be ignored. 174950 174951 PR 28176 174952 * elf32-rl78.c (RL78_STACK_PUSH, RL78_STACK_POP): Delete. 174953 (rl78_stack_push, rl78_stack_pop): New inline functions. 174954 (rl78_compute_complex_reloc): Add status and error message params. 174955 Use new inline stack handling functions. Report stack overflow 174956 or underflow, and divide by zero. 174957 (rl78_special_reloc): Return status and error message from 174958 rl78_compute_complex_reloc. 174959 (rl78_elf_relocate_section): Similarly. Modernise reloc error 174960 reporting. Delete unused bfd_reloc_other case. Don't assume 174961 DIR24S_PCREL overflow is due to undefined function. 174962 (rl78_offset_for_reloc): Adjust to suit rl78_compute_complex_reloc. 174963 1749642021-08-07 GDB Administrator <gdbadmin@sourceware.org> 174965 174966 Automatic date update in version.in 174967 1749682021-08-06 Tom de Vries <tdevries@suse.de> 174969 174970 [gdb/symtab] Recognize .gdb_index symbol table with empty entries as empty 174971 When reading a .gdb_index that contains a non-empty symbol table with only 174972 empty entries, gdb doesn't recognize it as empty. 174973 174974 Fix this by recognizing that the constant pool is empty, and then setting the 174975 symbol table to empty. 174976 174977 Tested on x86_64-linux. 174978 174979 gdb/ChangeLog: 174980 174981 2021-08-01 Tom de Vries <tdevries@suse.de> 174982 174983 PR symtab/28159 174984 * dwarf2/read.c (read_gdb_index_from_buffer): Handle symbol table 174985 filled with empty entries. 174986 174987 gdb/testsuite/ChangeLog: 174988 174989 2021-08-01 Tom de Vries <tdevries@suse.de> 174990 174991 PR symtab/28159 174992 * gdb.dwarf2/dw2-zero-range.exp: Remove kfail. 174993 1749942021-08-06 Tom Tromey <tromey@adacore.com> 174995 174996 Unconditionally define _initialize_addrmap 174997 The way that init.c is generated does not allow for an initialization 174998 function to be conditionally defined -- doing so will result in a link 174999 error. 175000 175001 This patch fixes a build problem that arises from such a conditional 175002 definition. It can be reproduce with --disable-unit-tests. 175003 1750042021-08-06 Tom de Vries <tdevries@suse.de> 175005 175006 [gdb/symtab] Fix zero address complaint for shlib 175007 In PR28004 the following warning / Internal error is reported: 175008 ... 175009 $ gdb -q -batch \ 175010 -iex "set sysroot $(pwd -P)/repro" \ 175011 ./repro/gdb \ 175012 ./repro/core \ 175013 -ex bt 175014 ... 175015 Program terminated with signal SIGABRT, Aborted. 175016 #0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6 175017 [Current thread is 1 (LWP 1762498)] 175018 #1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6 175019 warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \ 175020 but not in symtab.) 175021 warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \ 175022 but not in symtab.) 175023 ... 175024 #2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \ 175025 [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \ 175026 psymtab, but not in symtab.) 175027 175028 ) from repro/usr/lib/libstdc++.so.6 175029 ... 175030 175031 The warning is about the following: 175032 - in find_pc_sect_compunit_symtab we try to find the address 175033 (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs. 175034 - that fails, so we try again in the partial symtabs. 175035 - we find a matching partial symtab 175036 - however, the partial symtab has a full symtab, so 175037 we should have found a matching symtab in the first step. 175038 175039 The addresses are: 175040 ... 175041 (gdb) info sym 0x7ff8feb2c218 175042 __gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \ 175043 section .text of repro/usr/lib/libstdc++.so.6 175044 (gdb) info sym 0x7ff8feb2c21d 175045 __gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \ 175046 section .text of repro/usr/lib/libstdc++.so.6 175047 ... 175048 which correspond to unrelocated addresses 0x9c218 and 0x9c21d: 175049 ... 175050 $ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218 175051 000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \ 175052 [clone .cold] 175053 ... 175054 which belong to function __gnu_debug::_Error_formatter::_M_error() in 175055 /build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc. 175056 175057 The partial symtab that is found for the addresses is instead the one for 175058 /build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is 175059 incorrect. 175060 175061 This happens as follows. 175062 175063 The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50: 175064 ... 175065 00004b50 0000000000000000 0000000000000056 175066 00004b5a 00000000000a4790 00000000000a479c 175067 00004b64 00000000000a47a0 00000000000a47ac 175068 ... 175069 175070 When reading the first range 0x0..0x56, it doesn't trigger the "start address 175071 of zero" complaint here: 175072 ... 175073 /* A not-uncommon case of bad debug info. 175074 Don't pollute the addrmap with bad data. */ 175075 if (range_beginning + baseaddr == 0 175076 && !per_objfile->per_bfd->has_section_at_zero) 175077 { 175078 complaint (_(".debug_rnglists entry has start address of zero" 175079 " [in module %s]"), objfile_name (objfile)); 175080 continue; 175081 } 175082 ... 175083 because baseaddr != 0, which seems incorrect given that when loading the 175084 shared library individually in gdb (and consequently baseaddr == 0), we do see 175085 the complaint. 175086 175087 Consequently, we run into this case in dwarf2_get_pc_bounds: 175088 ... 175089 if (low == 0 && !per_objfile->per_bfd->has_section_at_zero) 175090 return PC_BOUNDS_INVALID; 175091 ... 175092 which then results in this code in process_psymtab_comp_unit_reader being 175093 called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap 175094 argument to 1: 175095 ... 175096 scan_partial_symbols (first_die, &lowpc, &highpc, 175097 cu_bounds_kind <= PC_BOUNDS_INVALID, cu); 175098 ... 175099 and consequently, the CU addrmap gets build using address info from the 175100 functions. 175101 175102 During that process, addrmap_set_empty is called with a range that includes 175103 0x9c218 and 0x9c21d: 175104 ... 175105 (gdb) p /x start 175106 $7 = 0x9989c 175107 (gdb) p /x end_inclusive 175108 $8 = 0xb200d 175109 ... 175110 but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae: 175111 ... 175112 000040ae 00000000000b1ee0 00000000000b200e 175113 000040b9 000000000009989c 00000000000998c4 175114 000040c3 <End of list> 175115 ... 175116 and neither range includes 0x9c218 and 0x9c21d. 175117 175118 This is caused by this code in partial_die_info::read: 175119 ... 175120 if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu, 175121 nullptr, tag)) 175122 has_pc_info = 1; 175123 ... 175124 which pretends that the function is located at addresses 0x9989c..0xb200d, 175125 which is indeed not the case. 175126 175127 This patch fixes the first problem encountered: fix the "start address of 175128 zero" complaint warning by removing the baseaddr part from the condition. 175129 Same for dwarf2_ranges_process. 175130 175131 The effect is that: 175132 - the complaint is triggered, and 175133 - the warning / Internal error is no longer triggered. 175134 175135 This does not fix the observed problem in partial_die_info::read, which is 175136 filed as PR28200. 175137 175138 Tested on x86_64-linux. 175139 175140 Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> 175141 175142 gdb/ChangeLog: 175143 175144 2021-07-29 Simon Marchi <simon.marchi@polymtl.ca> 175145 Tom de Vries <tdevries@suse.de> 175146 175147 PR symtab/28004 175148 * gdb/dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process): 175149 Fix zero address complaint. 175150 * gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test. 175151 * gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test. 175152 * gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file. 175153 1751542021-08-06 Alan Modra <amodra@gmail.com> 175155 175156 Re: Add tests for Intel AVX512_FP16 instructions 175157 * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Pass with 175158 mingw section padding. 175159 1751602021-08-06 Alan Modra <amodra@gmail.com> 175161 175162 chew ubsan warning 175163 It matters not at all if pc is incremented from its initial NULL 175164 value, but avoid this silly runtime ubsan error. 175165 175166 * doc/chew.c (perform): Avoid incrementing NULL pc. 175167 1751682021-08-06 Alan Modra <amodra@gmail.com> 175169 175170 bfd_reloc_offset_in_range overflow 175171 This patch is more about the style of bounds checking we ought to use, 175172 rather than a real problem. An overflow of "octet + reloc_size" can 175173 only happen with huge sections which would certainly cause out of 175174 memory errors. 175175 175176 * reloc.c (bfd_reloc_offset_in_range): Avoid possible overflow. 175177 1751782021-08-06 Alan Modra <amodra@gmail.com> 175179 175180 PR28175, Segment fault in coff-tic30.c reloc_processing 175181 The obj_convert table shouldn't be accessed without first checking the 175182 index against the table size. 175183 175184 PR 28175 175185 * coff-tic30.c (reloc_processing): Sanity check reloc symbol index. 175186 * coff-z80.c (reloc_processing): Likewise. 175187 * coff-z8k.c (reloc_processing): Likewise. 175188 1751892021-08-06 Alan Modra <amodra@gmail.com> 175190 175191 PR28173, nds32_elf_howto_table index out of bounds 175192 Indexing the howto table was seriously broken by a missing entry, and 175193 use of assertions about user input rather than testing the input. 175194 175195 PR 28173 175196 * elf32-nds32.c (nds32_elf_howto_table): Add missing empty howto. 175197 (bfd_elf32_bfd_reloc_type_table_lookup): Replace assertions with 175198 range checks. Return NULL if unsupported reloc type. Remove 175199 dead code. Take an unsigned int param. 175200 (nds32_info_to_howto_rel): Test for NULL howto or howto name 175201 return from lookup. Remove assertion. 175202 (nds32_info_to_howto): Remove unnecessary ATTRIBUTE_UNUSED. 175203 Test for NULL howto or howto name return from lookup. 175204 1752052021-08-06 Alan Modra <amodra@gmail.com> 175206 175207 PR28172, bfin_pcrel24_reloc heap-buffer-overflow 175208 bfin pcrel24 relocs are weird, they apply to the reloc address minus 175209 two. That means reloc addresses of 0 and 1 are invalid. Check that, 175210 and fix other reloc range checking. 175211 175212 PR 28172 175213 * elf32-bfin.c (bfin_pcrel24_reloc): Correct reloc range check. 175214 (bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc): Likewise. 175215 (bfin_final_link_relocate): Likewise. 175216 1752172021-08-06 GDB Administrator <gdbadmin@sourceware.org> 175218 175219 Automatic date update in version.in 175220 1752212021-08-05 Will Schmidt <will_schmidt@vnet.ibm.com> 175222 175223 [PATCH] GDB Testsuite, update compile-cplus.exp 175224 [PATCH] GDB Testsuite, update compile-cplus.exp 175225 175226 Update the gdb.compile/compile-cplus.exp test to 175227 handle errors generated when passing bad arguments 175228 into the gdb-compile command. 175229 This matches changes made to gdb.compile/compile.exp 175230 in the past as part of 175231 "Migrate rest of compile commands to new options framework" 175232 e6ed716cd5514c08b9d7c469d185b1aa177dbc22 175233 1752342021-08-05 Will Schmidt <will_schmidt@vnet.ibm.com> 175235 175236 [gdb] Handle .TOC. sections during gdb-compile for rs6000 target. 175237 [gdb] Handle .TOC. sections during gdb-compile for rs6000 target. 175238 175239 When we encounter a .TOC. symbol in the object we are loading, 175240 we need to associate this with the .toc section in order to 175241 properly resolve other symbols in the object. IF a .toc section 175242 is not found, iterate the sections until we find one with the 175243 SEC_ALLOC flag. If that also fails, fall back to using 175244 the *ABS* section, pointed to by bfd_abs_section_ptr. 175245 1752462021-08-05 Simon Marchi <simon.marchi@polymtl.ca> 175247 175248 gdb/testsuite: gdb.base/attach.exp: expose bug when testing with native-extended-gdbserver 175249 In gdb.base/attach.exp, proc do_attach_failure_tests, we attach to a 175250 process. When then try to attach to the same process in another 175251 inferior, expecting it to fail. We then come back to the first inferior 175252 and try to kill it, to clean up the test. When using the 175253 native-extended-gdbserver board, this "kill" test passes, even though it 175254 didn't actually work: 175255 175256 add-inferior 175257 [New inferior 2] 175258 Added inferior 2 on connection 1 (extended-remote localhost:2347) 175259 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: add empty inferior 2 175260 inferior 2 175261 [Switching to inferior 2 [<null>] (<noexec>)] 175262 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 2 175263 attach 817032 175264 Attaching to process 817032 175265 Attaching to process 817032 failed 175266 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again 175267 inferior 1 175268 [Switching to inferior 1 [process 817032] (/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/attach/attach)] 175269 [Switching to thread 1.1 (Thread 817032.817032)] 175270 #0 main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19 175271 19 while (! should_exit) 175272 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1 175273 kill 175274 Kill the program being debugged? (y or n) y 175275 Remote connection closed <==== That's unexpected 175276 (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures 175277 175278 When the second attach fails, gdbserver seems to break the connection 175279 (it hangs up on the existing remote target) and start listening again 175280 for incoming connections. This is documented in PR 19558 [1]. 175281 175282 Make the expected output regexp for the kill command tighter (it 175283 currently accepts anything). Use "set confirm off" so we don't have to 175284 deal with the confirmation. And to be really sure the extended-remote 175285 target still works, try to run the inferior again after killing. The 175286 now tests are kfail'ed when the target is gdbserver. 175287 175288 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19558 175289 175290 gdb/testsuite/ChangeLog: 175291 175292 * gdb.base/attach.exp (do_attach_failure_tests): Make kill 175293 regexp tighter, run inferior after killing it. Kfail when 175294 target is gdbserver. 175295 175296 Change-Id: I99c5cd3968ce2ec962ace35b016f842a243b7a0d 175297 1752982021-08-05 Simon Marchi <simon.marchi@polymtl.ca> 175299 175300 gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run 175301 When running this test with the native-extended-gdbserver, we get: 175302 175303 main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19 175304 19 while (! should_exit) 175305 The program being debugged has been started already. 175306 Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt 175307 y 175308 Don't know how to run. Try "help target". 175309 (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main 175310 175311 This test tests using both "-p <pid>" and "-ex start" on the command line, 175312 making sure that we first attach and then run. 175313 175314 Normally, after that "y", we should see the program running again. 175315 However, a particuliarity of the native-extended-gdbserver is that it 175316 uses "set auto-connect-native-target off" on the command line. The full 175317 GDB command line is: 175318 175319 ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \ 175320 -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \ 175321 -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start 175322 175323 The attach succeeds. I guess it is done before "set 175324 auto-connect-native-target off", or it somehow bypasses it. When the 175325 "start" is executed, the native target is unpushed, while killing the 175326 existing process, but not re-pushed, due to "set 175327 auto-connect-native-target off". So we get that "Don't know how to run" 175328 message. 175329 175330 Really, I think it's a case of the test doing things incompatible with 175331 the board, I think it should just be skipped. And as we can see with 175332 the current code, there were some attempts at doing this, just using the 175333 wrong checks: 175334 175335 - isnative: this is a dejagnu proc which checks if the target board has 175336 the same triplet as the build machine. In the case of 175337 native-extended-gdbserver, it does. 175338 - is_remote target: this checks whether the target board is remote, as 175339 in executing on a different machin. native-extended-gdbserver is not 175340 remote. 175341 175342 Since the --pid option specifically attaches to a process using the 175343 native target, change the test to use gdb_is_target_native instead. 175344 175345 gdb/testsuite/ChangeLog: 175346 175347 * gdb.base/attach.exp (test_command_line_attach_run): Use 175348 gdb_is_target_native to check if test is supported. 175349 175350 Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0 175351 1753522021-08-05 Simon Marchi <simon.marchi@polymtl.ca> 175353 175354 gdb: target_waitstatus_to_string: print extra info for FORKED, VFORKED, EXECD 175355 Print the extra information contained in target_waitstatus for these 175356 events. For TARGET_WAITKIND_{FORKED,VFORKED}, the extra information is 175357 contained in related_pid, and is the ptid of the new process. For 175358 TARGET_WAITKIND_EXECD, it,s the exec'd path name in execd_pathname. 175359 Print it using the same format used for TARGET_WAITKIND_STOPPED and 175360 others. 175361 175362 Here are sample outputs for all three events: 175363 175364 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 175365 [infrun] print_target_wait_results: 726890.726890.0 [process 726890], 175366 [infrun] print_target_wait_results: status->kind = vforked, related_pid = 726894.726894.0 175367 175368 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 175369 [infrun] print_target_wait_results: 727045.727045.0 [process 727045], 175370 [infrun] print_target_wait_results: status->kind = forked, related_pid = 727049.727049.0 175371 175372 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 175373 [infrun] print_target_wait_results: 727119.727119.0 [process 727119], 175374 [infrun] print_target_wait_results: status->kind = execd, execd_pathname = /usr/bin/ls 175375 175376 Change-Id: I4416a74e3bf792a625a68bf26c51689e170f2184 175377 1753782021-08-05 Simon Marchi <simon.marchi@polymtl.ca> 175379 175380 gdb: use ptid_t::to_string in print_target_wait_results 175381 The ptid_t::to_string method was introduced recently, to format a ptid_t 175382 for debug purposes. It formats the ptid exactly as is done in 175383 print_target_wait_results, so make print_target_wait_results use it. 175384 175385 Change-Id: I0a81c8040d3e1858fb304cb28366b34d94eefe4d 175386 1753872021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175388 175389 Add as_lval argument to expression evaluator 175390 There are cases where the result of the expression evaluation is 175391 expected to be in a form of a value and not location description. 175392 175393 One place that has this requirement is dwarf_entry_parameter_to_value 175394 function, but more are expected in the future. Until now, this 175395 requirement was fulfilled by extending the evaluated expression with 175396 a DW_OP_stack_value operation at the end. 175397 175398 New implementation, introduces a new evaluation argument instead. 175399 175400 * dwarf2/expr.c (dwarf_expr_context::fetch_result): Add as_lval 175401 argument. 175402 (dwarf_expr_context::eval_exp): Add as_lval argument. 175403 * dwarf2/expr.h (struct dwarf_expr_context): Add as_lval 175404 argument to fetch_result and eval_exp methods. 175405 * dwarf2/frame.c (execute_stack_op): Add as_lval argument. 175406 * dwarf2/loc.c (dwarf_entry_parameter_to_value): Remove 175407 DWARF expression extension. 175408 (dwarf2_evaluate_loc_desc_full): Add as_lval argument support. 175409 (dwarf2_evaluate_loc_desc): Add as_lval argument support. 175410 (dwarf2_locexpr_baton_eval): Add as_lval argument support. 175411 1754122021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175413 175414 Simplify dwarf_expr_context class interface 175415 Idea of this patch is to get a clean and simple public interface for 175416 the dwarf_expr_context class, looking like: 175417 175418 - constructor, 175419 - destructor, 175420 - push_address method and 175421 - evaluate method. 175422 175423 Where constructor should only ever require a target architecture 175424 information. This information is held in per object file 175425 (dwarf2_per_objfile) structure, so it makes sense to keep that 175426 structure as a constructor argument. It also makes sense to get the 175427 address size from that structure, but unfortunately that interface 175428 doesn't exist at the moment, so the dwarf_expr_context class user 175429 needs to provide that information. 175430 175431 The push_address method is used to push a CORE_ADDR as a value on 175432 top of the DWARF stack before the evaluation. This method can be 175433 later changed to push any struct value object on the stack. 175434 175435 The evaluate method is the method that evaluates a DWARF expression 175436 and provides the evaluation result, in a form of a single struct 175437 value object that describes a location. To do this, the method requires 175438 a context of the evaluation, as well as expected result type 175439 information. If the type information is not provided, the DWARF generic 175440 type will be used instead. 175441 175442 To avoid storing the gdbarch information in the evaluator object, that 175443 information is now always acquired from the per_objfile object. 175444 175445 All data members are now private and only visible to the evaluator 175446 class, so a m_ prefix was added to all of their names to reflect that. 175447 To make this distinction clear, they are also accessed through objects 175448 this pointer, wherever that was not the case before. 175449 175450 gdb/ChangeLog: 175451 175452 * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add 175453 address size argument. 175454 (dwarf_expr_context::read_mem): Change to use property_addr_info 175455 structure. 175456 (dwarf_expr_context::evaluate): New function. 175457 (dwarf_expr_context::execute_stack_op): Change to use 175458 property_addr_info structure. 175459 * dwarf2/expr.h (struct dwarf_expr_context): New evaluate 175460 declaration. Change eval and fetch_result method to private. 175461 (dwarf_expr_context::gdbarch): Remove member. 175462 (dwarf_expr_context::stack): Make private and add m_ prefix. 175463 (dwarf_expr_context::addr_size): Make private and add 175464 m_ prefix. 175465 (dwarf_expr_context::recursion_depth): Make private and add 175466 m_ prefix. 175467 (dwarf_expr_context::max_recursion_depth): Make private and 175468 add m_ prefix. 175469 (dwarf_expr_context::len): Make private and add m_ prefix. 175470 (dwarf_expr_context::data): Make private and add m_ prefix. 175471 (dwarf_expr_context::initialized): Make private and add 175472 m_ prefix. 175473 (dwarf_expr_context::pieces): Make private and add m_ prefix. 175474 (dwarf_expr_context::per_objfile): Make private and add 175475 m_ prefix. 175476 (dwarf_expr_context::frame): Make private and add m_ prefix. 175477 (dwarf_expr_context::per_cu): Make private and add m_ prefix. 175478 (dwarf_expr_context::addr_info): Make private and add 175479 m_ prefix. 175480 * dwarf2/frame.c (execute_stack_op): Change to call evaluate 175481 method. 175482 * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to call 175483 evaluate method. 175484 (dwarf2_locexpr_baton_eval): Change to call evaluate method. 175485 1754862021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175487 175488 Make DWARF evaluator return a single struct value 175489 The patch is addressing the issue of class users writing and reading 175490 the internal data of the dwarf_expr_context class. 175491 175492 At this point, all conditions are met for the DWARF evaluator to return 175493 an evaluation result in a form of a single struct value object. 175494 175495 gdb/ChangeLog: 175496 175497 * dwarf2/expr.c (pieced_value_funcs): Chenge to static 175498 function. 175499 (allocate_piece_closure): Change to static function. 175500 (dwarf_expr_context::fetch_result): New function. 175501 * dwarf2/expr.h (struct piece_closure): Remove declaration. 175502 (struct dwarf_expr_context): fetch_result new declaration. 175503 fetch, fetch_address and fetch_in_stack_memory members move 175504 to private. 175505 (allocate_piece_closure): Remove. 175506 * dwarf2/frame.c (execute_stack_op): Change to use 175507 fetch_result. 175508 * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to use 175509 fetch_result. 175510 (dwarf2_locexpr_baton_eval): Change to use fetch_result. 175511 * dwarf2/loc.h (invalid_synthetic_pointer): Expose function. 175512 1755132021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175514 175515 Make value_copy also copy the stack data member 175516 Fixing a bug where the value_copy function did not copy the stack data 175517 and initialized members of the struct value. This is needed for the 175518 next patch where the DWARF expression evaluator is changed to return a 175519 single struct value object. 175520 175521 * value.c (value_copy): Change to also copy the stack data 175522 and initialized members. 175523 1755242021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175525 175526 Move piece_closure and its support to expr.c 175527 Following 5 patches series is trying to clean up the interface of the 175528 DWARF expression evaluator class (dwarf_expr_context). 175529 175530 After merging all expression evaluators into one class, the next 175531 logical step is to make a clean user interface for that class. To do 175532 that, we first need to address the issue of class users writing and 175533 reading the internal data of the class directly. 175534 175535 Fixing the case of writing is simple, it makes sense for an evaluator 175536 instance to be per architecture basis. Currently, the best separation 175537 seems to be per object file, so having that data (dwarf2_per_objfile) 175538 as a constructor argument makes sense. It also makes sense to get the 175539 address size from that object file, but unfortunately that interface 175540 does not exist at the moment. 175541 175542 Luckily, address size information is already available to the users 175543 through other means. As a result, the address size also needs to be a 175544 class constructor argument, at least until a better interface for 175545 acquiring that information from an object file is implemented. 175546 175547 The rest of the user written data comes down to a context of an 175548 evaluated expression (compilation unit context, frame context and 175549 passed in buffer context) and a source type information that a result 175550 of evaluating expression is representing. So, it makes sense for all of 175551 these to be arguments of an evaluation method. 175552 175553 To address the problem of reading the dwarf_expr_context class 175554 internal data, we first need to understand why it is implemented that 175555 way? 175556 175557 This is actualy a question of which existing class can be used to 175558 represent both values and a location descriptions and why it is not 175559 used currently? 175560 175561 The answer is in a struct value class/structure, but the problem is 175562 that before the evaluators were merged, only one evaluator had an 175563 infrastructure to resolve composite and implicit pointer location 175564 descriptions. 175565 175566 After the merge, we are now able to use the struct value to represent 175567 any result of the expression evaluation. It also makes sense to move 175568 all infrastructure for those location descriptions to the expr.c file 175569 considering that that is the only place using that infrastructure. 175570 175571 What we are left with in the end is a clean public interface of the 175572 dwarf_expr_context class containing: 175573 175574 - constructor, 175575 - destructor, 175576 - push_address method and 175577 - eval_exp method. 175578 175579 The idea with this particular patch is to move piece_closure structure 175580 and the interface that handles it (lval_funcs) to expr.c file. 175581 175582 While implicit pointer location descriptions are still not useful in 175583 the CFI context (of the AMD's DWARF standard extensions), the composite 175584 location descriptions are certainly necessary to describe a results of 175585 specific compiler optimizations. 175586 175587 Considering that a piece_closure structure is used to represent both, 175588 there was no benefit in splitting them. 175589 175590 gdb/ChangeLog: 175591 175592 * dwarf2/expr.c (struct piece_closure): Add from loc.c. 175593 (allocate_piece_closure): Add from loc.c. 175594 (bits_to_bytes): Add from loc.c. 175595 (rw_pieced_value): Add from loc.c. 175596 (read_pieced_value): Add from loc.c. 175597 (write_pieced_value): Add from loc.c. 175598 (check_pieced_synthetic_pointer): Add from loc.c. 175599 (indirect_pieced_value): Add from loc.c. 175600 (coerce_pieced_ref): Add from loc.c. 175601 (copy_pieced_value_closure): Add from loc.c. 175602 (free_pieced_value_closure): Add from loc.c. 175603 (sect_variable_value): Add from loc.c. 175604 * dwarf2/loc.c (sect_variable_value): Move to expr.c. 175605 (struct piece_closure): Move to expr.c. 175606 (allocate_piece_closure): Move to expr.c. 175607 (bits_to_bytes): Move to expr.c. 175608 (rw_pieced_value): Move to expr.c. 175609 (read_pieced_value): Move to expr.c. 175610 (write_pieced_value): Move to expr.c. 175611 (check_pieced_synthetic_pointer): Move to expr.c. 175612 (indirect_pieced_value): Move to expr.c. 175613 (coerce_pieced_ref): Move to expr.c. 175614 (copy_pieced_value_closure): Move to expr.c. 175615 (free_pieced_value_closure): Move to expr.c. 175616 1756172021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175618 175619 Merge evaluate_for_locexpr_baton evaluator 175620 The evaluate_for_locexpr_baton is the last derived class from the 175621 dwarf_expr_context class. It's purpose is to support the passed in 175622 buffer functionality. 175623 175624 Although, it is not really necessary to merge this class with it's 175625 base class, doing that simplifies new expression evaluator design. 175626 175627 Considering that this functionality is going around the DWARF standard, 175628 it is also reasonable to expect that with a new evaluator design and 175629 extending the push object address functionality to accept any location 175630 description, there will be no need to support passed in buffers. 175631 175632 Alternatively, it would also makes sense to abstract the interaction 175633 between the evaluator and a given resource in the near future. The 175634 passed in buffer would then be a specialization of that abstraction. 175635 175636 gdb/ChangeLog: 175637 175638 * dwarf2/expr.c (dwarf_expr_context::read_mem): Merge with 175639 evaluate_for_locexpr_baton implementation. 175640 * dwarf2/loc.c (class evaluate_for_locexpr_baton): Remove 175641 class. 175642 (evaluate_for_locexpr_baton::read_mem): Move to 175643 dwarf_expr_context. 175644 (dwarf2_locexpr_baton_eval): Instantiate dwarf_expr_context 175645 instead of evaluate_for_locexpr_baton class. 175646 1756472021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175648 175649 Remove empty frame and full evaluators 175650 There are no virtual methods that require different specialization in 175651 dwarf_expr_context class. This means that derived classes 175652 dwarf_expr_executor and dwarf_evaluate_loc_desc are not needed any 175653 more. 175654 175655 As a result of this, the evaluate_for_locexpr_baton class base class 175656 is now the dwarf_expr_context class. 175657 175658 There might be a need for a better class hierarchy when we know more 175659 about the direction of the future DWARF versions and gdb extensions, 175660 but that is out of the scope of this patch series. 175661 175662 gdb/ChangeLog: 175663 175664 * dwarf2/frame.c (class dwarf_expr_executor): Remove class. 175665 (execute_stack_op): Instantiate dwarf_expr_context instead of 175666 dwarf_evaluate_loc_desc class. 175667 * dwarf2/loc.c (class dwarf_evaluate_loc_desc): Remove class. 175668 (dwarf2_evaluate_loc_desc_full): Instantiate dwarf_expr_context 175669 instead of dwarf_evaluate_loc_desc class. 175670 (struct evaluate_for_locexpr_baton): Derive from 175671 dwarf_expr_context. 175672 1756732021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175674 175675 Inline get_reg_value method of dwarf_expr_context 175676 The get_reg_value method is a small function that is only called once, 175677 so it can be inlined to simplify the dwarf_expr_context class. 175678 175679 gdb/ChangeLog: 175680 175681 * dwarf2/expr.c (dwarf_expr_context::get_reg_value): Remove 175682 method. 175683 (dwarf_expr_context::execute_stack_op): Inline get_reg_value 175684 method. 175685 * dwarf2/expr.h (dwarf_expr_context::get_reg_value): Remove 175686 method. 175687 1756882021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175689 175690 Move push_dwarf_reg_entry_value to expr.c 175691 Following the idea of merging the evaluators, the 175692 push_dwarf_reg_entry_value method can be moved from 175693 dwarf_expr_executor and dwarf_evaluate_loc_desc classes 175694 to their base class dwarf_expr_context. 175695 175696 gdb/ChangeLog: 175697 175698 * dwarf2/expr.c 175699 (dwarf_expr_context::push_dwarf_reg_entry_value): Move from 175700 dwarf_evaluate_loc_desc. 175701 * dwarf2/frame.c 175702 (dwarf_expr_executor::push_dwarf_reg_entry_value): Remove 175703 method. 175704 * dwarf2/loc.c (dwarf_expr_reg_to_entry_parameter): Expose 175705 function. 175706 (dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value): Move to 175707 dwarf_expr_context. 175708 * dwarf2/loc.h (dwarf_expr_reg_to_entry_parameter): Expose 175709 function. 175710 1757112021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175712 175713 Move read_mem to dwarf_expr_context 175714 Following the idea of merging the evaluators, the read_mem method can 175715 be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes 175716 to their base class dwarf_expr_context. 175717 175718 gdb/ChangeLog: 175719 175720 * dwarf2/expr.c (dwarf_expr_context::read_mem): Move from 175721 dwarf_evaluate_loc_desc. 175722 * dwarf2/frame.c (dwarf_expr_executor::read_mem): Remove 175723 method. 175724 * dwarf2/loc.c (dwarf_evaluate_loc_desc::read_mem): Move to 175725 dwarf_expr_context. 175726 1757272021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175728 175729 Move get_object_address to dwarf_expr_context 175730 Following the idea of merging the evaluators, the get_object_address 175731 and can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc 175732 classes to their base class dwarf_expr_context. 175733 175734 gdb/ChangeLog: 175735 175736 * dwarf2/expr.c (dwarf_expr_context::get_object_address): Move 175737 from dwarf_evaluate_loc_desc. 175738 (class dwarf_expr_context): Add object address member to 175739 dwarf_expr_context. 175740 * dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove 175741 method. 175742 * dwarf2/frame.c (dwarf_expr_executor::get_object_address): 175743 Remove method. 175744 * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_object_address): 175745 move to dwarf_expr_context. 175746 (class dwarf_evaluate_loc_desc): Move object address member to 175747 dwarf_expr_context. 175748 1757492021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175750 175751 Move dwarf_call to dwarf_expr_context 175752 Following the idea of merging the evaluators, the dwarf_call and 175753 get_frame_pc method can be moved from dwarf_expr_executor and 175754 dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context. 175755 Once this is done, the get_frame_pc can be replace with lambda 175756 function. 175757 175758 gdb/ChangeLog: 175759 175760 * dwarf2/expr.c (dwarf_expr_context::dwarf_call): Move from 175761 dwarf_evaluate_loc_desc. 175762 (dwarf_expr_context::get_frame_pc): Replace with lambda. 175763 * dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove 175764 method. 175765 * dwarf2/frame.c (dwarf_expr_executor::dwarf_call): Remove 175766 method. 175767 (dwarf_expr_executor::get_frame_pc): Remove method. 175768 * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_pc): Remove 175769 method. 175770 (dwarf_evaluate_loc_desc::dwarf_call): Move to 175771 dwarf_expr_context. 175772 (per_cu_dwarf_call): Inline function. 175773 1757742021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175775 175776 Move compilation unit info to dwarf_expr_context 175777 This patch moves the compilation unit context information and support 175778 from dwarf_expr_executor and dwarf_evaluate_loc_desc to 175779 dwarf_expr_context evaluator. The idea is to report an error when a 175780 given operation requires a compilation unit information to be resolved, 175781 which is not available. 175782 175783 With this change, it also makes sense to always acquire ref_addr_size 175784 information from the compilation unit context, considering that all 175785 DWARF operations that refer to that information require a compilation 175786 unit context to be present during their evaluation. 175787 175788 gdb/ChangeLog: 175789 175790 * dwarf2/expr.c (ensure_have_per_cu): New function. 175791 (dwarf_expr_context::dwarf_expr_context): Add compilation unit 175792 context information. 175793 (dwarf_expr_context::get_base_type): Move from 175794 dwarf_evaluate_loc_desc. 175795 (dwarf_expr_context::get_addr_index): Remove method. 175796 (dwarf_expr_context::dwarf_variable_value): Remove method. 175797 (dwarf_expr_context::execute_stack_op): Call compilation unit 175798 context info check. Inline get_addr_index and 175799 dwarf_variable_value methods. 175800 * dwarf2/expr.h (struct dwarf_expr_context): Add compilation 175801 context info. 175802 (dwarf_expr_context::get_addr_index): Remove method. 175803 (dwarf_expr_context::dwarf_variable_value): Remove method. 175804 (dwarf_expr_context::ref_addr_size): Remove member. 175805 * dwarf2/frame.c (dwarf_expr_executor::get_addr_index): Remove 175806 method. 175807 (dwarf_expr_executor::dwarf_variable_value): Remove method. 175808 * dwarf2/loc.c (sect_variable_value): Expose function. 175809 (dwarf_evaluate_loc_desc::get_addr_index): Remove method. 175810 (dwarf_evaluate_loc_desc::dwarf_variable_value): Remove method. 175811 (class dwarf_evaluate_loc_desc): Move compilation unit context 175812 information to dwarf_expr_context class. 175813 * dwarf2/loc.h (sect_variable_value): Expose function. 175814 1758152021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175816 175817 Remove get_frame_cfa from dwarf_expr_context 175818 Following the idea of merging the evaluators, the get_frame_cfa method 175819 can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc 175820 classes to their base class dwarf_expr_context. Once this is done, 175821 it becomes apparent that the method is only called once and it can be 175822 inlined. 175823 175824 It is also necessary to check if the frame context information was 175825 provided before the DW_OP_call_frame_cfa operation is executed. 175826 175827 gdb/ChangeLog: 175828 175829 * dwarf2/expr.c (dwarf_expr_context::get_frame_cfa): Remove 175830 method. 175831 (dwarf_expr_context::execute_stack_op): Call frame context info 175832 check for DW_OP_call_frame_cfa. Remove use of get_frame_cfa. 175833 * dwarf2/expr.h (dwarf_expr_context::get_frame_cfa): Remove 175834 method. 175835 * dwarf2/frame.c (dwarf_expr_context::get_frame_cfa): Remove 175836 method. 175837 * dwarf2/loc.c (dwarf_expr_context::get_frame_cfa): Remove 175838 method. 175839 1758402021-08-05 Zoran Zaric <zoran.zaric@amd.com> 175841 175842 Move frame context info to dwarf_expr_context 175843 Following 15 patches in this patch series is cleaning up the design of 175844 the DWARF expression evaluator (dwarf_expr_context) to make future 175845 extensions of that evaluator easier and cleaner to implement. 175846 175847 There are three subclasses of the dwarf_expr_context class 175848 (dwarf_expr_executor, dwarf_evaluate_loc_desc and 175849 evaluate_for_locexpr_baton). Here is a short description of each class: 175850 175851 - dwarf_expr_executor is evaluating a DWARF expression in a context 175852 of a Call Frame Information. The overridden methods of this subclass 175853 report an error if a specific DWARF operation, represented by that 175854 method, is not allowed in a CFI context. The source code of this 175855 subclass lacks the support for composite as well as implicit pointer 175856 location description. 175857 175858 - dwarf_evaluate_loc_desc can evaluate any expression with no 175859 restrictions. All of the methods that this subclass overrides are 175860 actually doing what they are intended to do. This subclass contains 175861 a full support for all location description types. 175862 175863 - evaluate_for_locexpr_baton subclass is a specialization of the 175864 dwarf_evaluate_loc_desc subclass and it's function is to add 175865 support for passed in buffers. This seems to be a way to go around 175866 the fact that DWARF standard lacks a bit offset support for memory 175867 location descriptions as well as using any location description for 175868 the push object address functionality. 175869 175870 It all comes down to this question: what is a function of a DWARF 175871 expression evaluator? 175872 175873 Is it to evaluate the expression in a given context or to check the 175874 correctness of that expression in that context? 175875 175876 Currently, the only reason why there is a dwarf_expr_executor subclass 175877 is to report an invalid DWARF expression in a context of a CFI, but is 175878 that what the evaluator is supposed to do considering that the evaluator 175879 is not tied to a given DWARF version? 175880 175881 There are more and more vendor and GNU extensions that are not part of 175882 the DWARF standard, so is it that impossible to expect that some of the 175883 extensions could actually lift the previously imposed restrictions of 175884 the CFI context? Not to mention that every new DWARF version is lifting 175885 some restrictions anyway. 175886 175887 The thing that makes more sense for an evaluator to do, is to take the 175888 context of an evaluation and checks the requirements of every operation 175889 evaluated against that context. With this approach, the evaluator would 175890 report an error only if parts of the context, necessary for the 175891 evaluation, are missing. 175892 175893 If this approach is taken, then the unification of the 175894 dwarf_evaluate_loc_desc, dwarf_expr_executor and dwarf_expr_context 175895 is the next logical step. This makes a design of the DWARF expression 175896 evaluator cleaner and allows more flexibility when supporting future 175897 vendor and GNU extensions. 175898 175899 Additional benefit here is that now all evaluators have access to all 175900 location description types, which means that a vendor extended CFI 175901 rules could support composite location description as well. This also 175902 means that a new evaluator interface can be changed to return a single 175903 struct value (that describes the result of the evaluation) instead of 175904 a caller poking around the dwarf_expr_context internal data for answers 175905 (like it is done currently). 175906 175907 This patch starts the merging process by moving the frame context 175908 information and support from dwarf_expr_executor and 175909 dwarf_evaluate_loc_desc to dwarf_expr_context evaluator. The idea 175910 is to report an error when a given operation requires a frame 175911 information to be resolved, if that information is not present. 175912 175913 gdb/ChangeLog: 175914 175915 * dwarf2/expr.c (ensure_have_frame): New function. 175916 (read_addr_from_reg): Add from frame.c. 175917 (dwarf_expr_context::dwarf_expr_context): Add frame info to 175918 dwarf_expr_context. 175919 (dwarf_expr_context::read_addr_from_reg): Remove. 175920 (dwarf_expr_context::get_reg_value): Move from 175921 dwarf_evaluate_loc_desc. 175922 (dwarf_expr_context::get_frame_base): Move from 175923 dwarf_evaluate_loc_desc. 175924 (dwarf_expr_context::execute_stack_op): Call frame context info 175925 check. Remove use of read_addr_from_reg method. 175926 * dwarf2/expr.h (struct dwarf_expr_context): Add frame info 175927 member, read_addr_from_reg, get_reg_value and get_frame_base 175928 declaration. 175929 (read_addr_from_reg): Move to expr.c. 175930 * dwarf2/frame.c (read_addr_from_reg): Move to 175931 dwarf_expr_context. 175932 (dwarf_expr_executor::read_addr_from_reg): Remove. 175933 (dwarf_expr_executor::get_frame_base): Remove. 175934 (dwarf_expr_executor::get_reg_value): Remove. 175935 (execute_stack_op): Use read_addr_from_reg function instead of 175936 read_addr_from_reg method. 175937 * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_base): Move 175938 to dwarf_expr_context. 175939 (dwarf_evaluate_loc_desc::get_reg_value): Move to 175940 dwarf_expr_context. 175941 (dwarf_evaluate_loc_desc::read_addr_from_reg): Remove. 175942 (dwarf2_locexpr_baton_eval):Use read_addr_from_reg function 175943 instead of read_addr_from_reg method. 175944 1759452021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175946 175947 Cleanup of the dwarf_expr_context constructor 175948 Move the initial values for dwarf_expr_context class data members 175949 to the class declaration in expr.h. 175950 175951 gdb/ChangeLog: 175952 175953 * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): 175954 Remove initial data members values. 175955 * dwarf2/expr.h (dwarf_expr_context): Add initial values 175956 to the class data members. 175957 1759582021-08-05 Zoran Zaric <Zoran.Zaric@amd.com> 175959 175960 Replace the symbol needs evaluator with a parser 175961 This patch addresses a design problem with the symbol_needs_eval_context 175962 class. It exposes the problem by introducing two new testsuite test 175963 cases. 175964 175965 To explain the issue, I first need to explain the dwarf_expr_context 175966 class that the symbol_needs_eval_context class derives from. 175967 175968 The intention behind the dwarf_expr_context class is to commonize the 175969 DWARF expression evaluation mechanism for different evaluation 175970 contexts. Currently in gdb, the evaluation context can contain some or 175971 all of the following information: architecture, object file, frame and 175972 compilation unit. 175973 175974 Depending on the information needed to evaluate a given expression, 175975 there are currently three distinct DWARF expression evaluators: 175976 175977 - Frame: designed to evaluate an expression in the context of a call 175978 frame information (dwarf_expr_executor class). This evaluator doesn't 175979 need a compilation unit information. 175980 175981 - Location description: designed to evaluate an expression in the 175982 context of a source level information (dwarf_evaluate_loc_desc 175983 class). This evaluator expects all information needed for the 175984 evaluation of the given expression to be present. 175985 175986 - Symbol needs: designed to answer a question about the parts of the 175987 context information required to evaluate a DWARF expression behind a 175988 given symbol (symbol_needs_eval_context class). This evaluator 175989 doesn't need a frame information. 175990 175991 The functional difference between the symbol needs evaluator and the 175992 others is that this evaluator is not meant to interact with the actual 175993 target. Instead, it is supposed to check which parts of the context 175994 information are needed for the given DWARF expression to be evaluated by 175995 the location description evaluator. 175996 175997 The idea is to take advantage of the existing dwarf_expr_context 175998 evaluation mechanism and to fake all required interactions with the 175999 actual target, by returning back dummy values. The evaluation result is 176000 returned as one of three possible values, based on operations found in a 176001 given expression: 176002 176003 - SYMBOL_NEEDS_NONE, 176004 - SYMBOL_NEEDS_REGISTERS and 176005 - SYMBOL_NEEDS_FRAME. 176006 176007 The problem here is that faking results of target interactions can yield 176008 an incorrect evaluation result. 176009 176010 For example, if we have a conditional DWARF expression, where the 176011 condition depends on a value read from an actual target, and the true 176012 branch of the condition requires a frame information to be evaluated, 176013 while the false branch doesn't, fake target reads could conclude that a 176014 frame information is not needed, where in fact it is. This wrong 176015 information would then cause the expression to be actually evaluated (by 176016 the location description evaluator) with a missing frame information. 176017 This would then crash the debugger. 176018 176019 The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this 176020 scenario, with the following DWARF expression: 176021 176022 DW_OP_addr $some_variable 176023 DW_OP_deref 176024 176025 # conditional jump to DW_OP_bregx 176026 DW_OP_bra 4 176027 DW_OP_lit0 176028 176029 # jump to DW_OP_stack_value 176030 DW_OP_skip 3 176031 DW_OP_bregx $dwarf_regnum 0 176032 DW_OP_stack_value 176033 176034 This expression describes a case where some variable dictates the 176035 location of another variable. Depending on a value of some_variable, the 176036 variable whose location is described by this expression is either read 176037 from a register or it is defined as a constant value 0. In both cases, 176038 the value will be returned as an implicit location description on the 176039 DWARF stack. 176040 176041 Currently, when the symbol needs evaluator fakes a memory read from the 176042 address behind the some_variable variable, the constant value 0 is used 176043 as the value of the variable A, and the check returns the 176044 SYMBOL_NEEDS_NONE result. 176045 176046 This is clearly a wrong result and it causes the debugger to crash. 176047 176048 The scenario might sound strange to some people, but it comes from a 176049 SIMD/SIMT architecture where $some_variable is an execution mask. In 176050 any case, it is a valid DWARF expression, and GDB shouldn't crash while 176051 evaluating it. Also, a similar example could be made based on a 176052 condition of the frame base value, where if that value is concluded to 176053 be 0, the variable location could be defaulted to a TLS based memory 176054 address. 176055 176056 The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second 176057 scenario. This scenario is a bit more abstract due to the DWARF 176058 assembler lacking the CFI support, but it exposes a different 176059 manifestation of the same problem. Like in the previous scenario, the 176060 DWARF expression used in the test is valid: 176061 176062 DW_OP_lit1 176063 DW_OP_addr $some_variable 176064 DW_OP_deref 176065 176066 # jump to DW_OP_fbreg 176067 DW_OP_skip 4 176068 DW_OP_drop 176069 DW_OP_fbreg 0 176070 DW_OP_dup 176071 DW_OP_lit0 176072 DW_OP_eq 176073 176074 # conditional jump to DW_OP_drop 176075 DW_OP_bra -9 176076 DW_OP_stack_value 176077 176078 Similarly to the previous scenario, the location of a variable A is an 176079 implicit location description with a constant value that depends on a 176080 value held by a global variable. The difference from the previous case 176081 is that DWARF expression contains a loop instead of just one branch. The 176082 end condition of that loop depends on the expectation that a frame base 176083 value is never zero. Currently, the act of faking the target reads will 176084 cause the symbol needs evaluator to get stuck in an infinite loop. 176085 176086 Somebody could argue that we could change the fake reads to return 176087 something else, but that would only hide the real problem. 176088 176089 The general impression seems to be that the desired design is to have 176090 one class that deals with parsing of the DWARF expression, while there 176091 are virtual methods that deal with specifics of some operations. 176092 176093 Using an evaluator mechanism here doesn't seem to be correct, because 176094 the act of evaluation relies on accessing the data from the actual 176095 target with the possibility of skipping the evaluation of some parts of 176096 the expression. 176097 176098 To better explain the proposed solution for the issue, I first need to 176099 explain a couple more details behind the current design: 176100 176101 There are multiple places in gdb that handle DWARF expression parsing 176102 for different purposes. Some are in charge of converting the expression 176103 to some other internal representation (decode_location_expression, 176104 disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are 176105 analysing the expression for specific information 176106 (compute_stack_depth_worker) and some are in charge of evaluating the 176107 expression in a given context (dwarf_expr_context::execute_stack_op 176108 and decode_locdesc). 176109 176110 The problem is that all those functions have a similar (large) switch 176111 statement that handles each DWARF expression operation. The result of 176112 this is a code duplication and harder maintenance. 176113 176114 As a step into the right direction to solve this problem (at least for 176115 the purpose of a DWARF expression evaluation) the expression parsing was 176116 commonized inside of an evaluator base class (dwarf_expr_context). This 176117 makes sense for all derived classes, except for the symbol needs 176118 evaluator (symbol_needs_eval_context) class. 176119 176120 As described previously the problem with this evaluator is that if the 176121 evaluator is not allowed to access the actual target, it is not really 176122 evaluating. 176123 176124 Instead, the desired function of a symbol needs evaluator seems to fall 176125 more into expression analysis category. This means that a more natural 176126 fit for this evaluator is to be a symbol needs analysis, similar to the 176127 existing compute_stack_depth_worker analysis. 176128 176129 Another problem is that using a heavyweight mechanism of an evaluator 176130 to do an expression analysis seems to be an unneeded overhead. It also 176131 requires a more complicated design of the parent class to support fake 176132 target reads. 176133 176134 The reality is that the whole symbol_needs_eval_context class can be 176135 replaced with a lightweight recursive analysis function, that will give 176136 more correct result without compromising the design of the 176137 dwarf_expr_context class. The analysis treats the expression byte 176138 stream as a DWARF operation graph, where each graph node can be 176139 visited only once and each operation can decide if the frame context 176140 is needed for their evaluation. 176141 176142 The downside of this approach is adding of one more similar switch 176143 statement, but at least this way the new symbol needs analysis will be 176144 a lightweight mechnism and it will provide a correct result for any 176145 given DWARF expression. 176146 176147 A more desired long term design would be to have one class that deals 176148 with parsing of the DWARF expression, while there would be a virtual 176149 methods that deal with specifics of some DWARF operations. Then that 176150 class would be used as a base for all DWARF expression parsing mentioned 176151 at the beginning. 176152 176153 This however, requires a far bigger changes that are out of the scope 176154 of this patch series. 176155 176156 The new analysis requires the DWARF location description for the 176157 argc argument of the main function to change in the assembly file 176158 gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression 176159 ended with a 0 value byte, which was never reached by the symbol needs 176160 evaluator, because it was detecting a stack underflow when evaluating 176161 the operation before. The new approach does not simulate a DWARF 176162 stack anymore, so the 0 value byte needs to be removed because it 176163 makes the DWARF expression invalid. 176164 176165 gdb/ChangeLog: 176166 176167 * dwarf2/loc.c (class symbol_needs_eval_context): Remove. 176168 (dwarf2_get_symbol_read_needs): New function. 176169 (dwarf2_loc_desc_get_symbol_read_needs): Remove. 176170 (locexpr_get_symbol_read_needs): Use 176171 dwarf2_get_symbol_read_needs. 176172 176173 gdb/testsuite/ChangeLog: 176174 176175 * gdb.python/amd64-py-framefilter-invalidarg.S : Update argc 176176 DWARF location expression. 176177 * lib/dwarf.exp (_location): Handle DW_OP_fbreg. 176178 * gdb.dwarf2/symbol_needs_eval.c: New file. 176179 * gdb.dwarf2/symbol_needs_eval_fail.exp: New file. 176180 * gdb.dwarf2/symbol_needs_eval_timeout.exp: New file. 176181 1761822021-08-05 Cui,Lili <lili.cui@intel.com> 176183 176184 [PATCH 2/2] Add tests for Intel AVX512_FP16 instructions 176185 Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits 176186 in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32 176187 in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx). 176188 There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8 176189 operands predated our current conventions; those instructions moved to map 3. 176190 FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3 176191 is very sparsely populated. Most of the FP16 instructions share opcodes and 176192 prefix (EVEX.pp) bits with the related FP32 operations. 176193 176194 Intel AVX512 FP16 instructions has new displacements scaling rules, please refer 176195 to the public software developer manual for detail information. 176196 176197 gas/ 176198 176199 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com> 176200 H.J. Lu <hongjiu.lu@intel.com> 176201 Wei Xiao <wei3.xiao@intel.com> 176202 Lili Cui <lili.cui@intel.com> 176203 176204 * testsuite/gas/i386/i386.exp: Run FP16 tests. 176205 * testsuite/gas/i386/avx512_fp16-intel.d: New test. 176206 * testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto. 176207 * testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto. 176208 * testsuite/gas/i386/avx512_fp16.d: Ditto. 176209 * testsuite/gas/i386/avx512_fp16.s: Ditto. 176210 * testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto. 176211 * testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto. 176212 * testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto. 176213 * testsuite/gas/i386/avx512_fp16_vl.d: Ditto. 176214 * testsuite/gas/i386/avx512_fp16_vl.s: Ditto. 176215 * testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto. 176216 * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto. 176217 * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto. 176218 * testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto. 176219 * testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto. 176220 * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto. 176221 * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto. 176222 * testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto. 176223 * testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto. 176224 * testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto. 176225 * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto. 176226 * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto. 176227 * testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto. 176228 * testsuite/gas/i386/x86-64-avx512_fp16-bad.s: Ditto. 176229 * testsuite/gas/i386/x86-64-default-suffix-avx.d: Add new testcase. 176230 * testsuite/gas/i386/x86-64-default-suffix.d: Ditto. 176231 * testsuite/gas/i386/x86-64-default-suffix.s: Ditto. 176232 * testsuite/gas/i386/xmmword.l: Ditto. 176233 * testsuite/gas/i386/xmmword.s: Ditto. 176234 1762352021-08-05 Cui,Lili <lili.cui@intel.com> 176236 176237 [PATCH 1/2] Enable Intel AVX512_FP16 instructions 176238 Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits 176239 in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32 176240 in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx). 176241 There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8 176242 operands predated our current conventions; those instructions moved to map 3. 176243 FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3 176244 is very sparsely populated. Most of the FP16 instructions share opcodes and 176245 prefix (EVEX.pp) bits with the related FP32 operations. 176246 176247 Intel AVX512 FP16 instructions has new displacements scaling rules, please refer 176248 to the public software developer manual for detail information. 176249 176250 gas/ 176251 176252 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com> 176253 H.J. Lu <hongjiu.lu@intel.com> 176254 Wei Xiao <wei3.xiao@intel.com> 176255 Lili Cui <lili.cui@intel.com> 176256 176257 * config/tc-i386.c (struct Broadcast_Operation): Adjust comment. 176258 (cpu_arch): Add .avx512_fp16. 176259 (cpu_noarch): Add noavx512_fp16. 176260 (pte): Add evexmap5 and evexmap6. 176261 (build_evex_prefix): Handle EVEXMAP5 and EVEXMAP6. 176262 (check_VecOperations): Handle {1to32}. 176263 (check_VecOperands): Handle CheckRegNumb. 176264 (check_word_reg): Handle Toqword. 176265 (i386_error): Add invalid_dest_and_src_register_set. 176266 (match_template): Handle invalid_dest_and_src_register_set. 176267 * doc/c-i386.texi: Document avx512_fp16, noavx512_fp16. 176268 176269 opcodes/ 176270 176271 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com> 176272 H.J. Lu <hongjiu.lu@intel.com> 176273 Wei Xiao <wei3.xiao@intel.com> 176274 Lili Cui <lili.cui@intel.com> 176275 176276 * i386-dis.c (EXwScalarS): New. 176277 (EXxh): Ditto. 176278 (EXxhc): Ditto. 176279 (EXxmmqh): Ditto. 176280 (EXxmmqdh): Ditto. 176281 (EXEvexXwb): Ditto. 176282 (DistinctDest_Fixup): Ditto. 176283 (enum): Add xh_mode, evex_half_bcst_xmmqh_mode, evex_half_bcst_xmmqdh_mode 176284 and w_swap_mode. 176285 (enum): Add PREFIX_EVEX_0F3A08_W_0, PREFIX_EVEX_0F3A0A_W_0, 176286 PREFIX_EVEX_0F3A26, PREFIX_EVEX_0F3A27, PREFIX_EVEX_0F3A56, 176287 PREFIX_EVEX_0F3A57, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3A67, 176288 PREFIX_EVEX_0F3AC2, PREFIX_EVEX_MAP5_10, PREFIX_EVEX_MAP5_11, 176289 PREFIX_EVEX_MAP5_1D, PREFIX_EVEX_MAP5_2A, PREFIX_EVEX_MAP5_2C, 176290 PREFIX_EVEX_MAP5_2D, PREFIX_EVEX_MAP5_2E, PREFIX_EVEX_MAP5_2F, 176291 PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, PREFIX_EVEX_MAP5_59, 176292 PREFIX_EVEX_MAP5_5A_W_0, PREFIX_EVEX_MAP5_5A_W_1, 176293 PREFIX_EVEX_MAP5_5B_W_0, PREFIX_EVEX_MAP5_5B_W_1, 176294 PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, PREFIX_EVEX_MAP5_5E, 176295 PREFIX_EVEX_MAP5_5F, PREFIX_EVEX_MAP5_78, PREFIX_EVEX_MAP5_79, 176296 PREFIX_EVEX_MAP5_7A, PREFIX_EVEX_MAP5_7B, PREFIX_EVEX_MAP5_7C, 176297 PREFIX_EVEX_MAP5_7D_W_0, PREFIX_EVEX_MAP6_13, PREFIX_EVEX_MAP6_56, 176298 PREFIX_EVEX_MAP6_57, PREFIX_EVEX_MAP6_D6, PREFIX_EVEX_MAP6_D7 176299 (enum): Add EVEX_MAP5 and EVEX_MAP6. 176300 (enum): Add EVEX_W_MAP5_5A, EVEX_W_MAP5_5B, 176301 EVEX_W_MAP5_78_P_0, EVEX_W_MAP5_78_P_2, EVEX_W_MAP5_79_P_0, 176302 EVEX_W_MAP5_79_P_2, EVEX_W_MAP5_7A_P_2, EVEX_W_MAP5_7A_P_3, 176303 EVEX_W_MAP5_7B_P_2, EVEX_W_MAP5_7C_P_0, EVEX_W_MAP5_7C_P_2, 176304 EVEX_W_MAP5_7D, EVEX_W_MAP6_13_P_0, EVEX_W_MAP6_13_P_2, 176305 (get_valid_dis386): Properly handle new instructions. 176306 (intel_operand_size): Handle new modes. 176307 (OP_E_memory): Ditto. 176308 (OP_EX): Ditto. 176309 * i386-dis-evex.h: Updated for AVX512_FP16. 176310 * i386-dis-evex-mod.h: Updated for AVX512_FP16. 176311 * i386-dis-evex-prefix.h: Updated for AVX512_FP16. 176312 * i386-dis-evex-reg.h : Updated for AVX512_FP16. 176313 * i386-dis-evex-w.h : Updated for AVX512_FP16. 176314 * i386-gen.c (cpu_flag_init): Add CPU_AVX512_FP16_FLAGS, 176315 and CPU_ANY_AVX512_FP16_FLAGS. Update CPU_ANY_AVX512F_FLAGS 176316 and CPU_ANY_AVX512BW_FLAGS. 176317 (cpu_flags): Add CpuAVX512_FP16. 176318 (opcode_modifiers): Add DistinctDest. 176319 * i386-opc.h (enum): (AVX512_FP16): New. 176320 (i386_opcode_modifier): Add reqdistinctreg. 176321 (i386_cpu_flags): Add cpuavx512_fp16. 176322 (EVEXMAP5): Defined as a macro. 176323 (EVEXMAP6): Ditto. 176324 * i386-opc.tbl: Add Intel AVX512_FP16 instructions. 176325 * i386-init.h: Regenerated. 176326 * i386-tbl.h: Ditto. 176327 1763282021-08-05 Alan Modra <amodra@gmail.com> 176329 176330 PR28167, vms-alpha build_module_list 176331 PR 28167 176332 * vms-alpha.c (build_module_list): Malloc and free section contents. 176333 Don't read past end of section. 176334 1763352021-08-05 Alan Modra <amodra@gmail.com> 176336 176337 PR28166, _bfd_elf_mips_get_relocated_section_contents 176338 Some of the code paths unpacking mips relocs left arelent->sym_ptr_ptr 176339 uninitialised. 176340 176341 PR 28166 176342 * elf64-mips.c (mips_elf64_slurp_one_reloc_table): Don't leave 176343 sym_ptr_ptr uninitialised. 176344 1763452021-08-05 Alan Modra <amodra@gmail.com> 176346 176347 PR28165, buffer overflow in elf32-rx.c:rx_info_to_howto_rela 176348 PR 28165 176349 * elf32-rx.c (rx_elf_howto_table): Add missing empty entries. 176350 (rx_info_to_howto_rela): Assert rx_elf_howto_table is correct size. 176351 Use actual size when sanity checking r_type. 176352 1763532021-08-05 Alan Modra <amodra@gmail.com> 176354 176355 Re: elf: Treat undefined version as hidden 176356 Fix fallout in cris testsuite 176357 176358 PR binutils/28158 176359 * ld-cris/libdso-1c.d: Update for version display change. 176360 * ld-cris/libdso-15b.d: Likewise. 176361 1763622021-08-05 Andrew Burgess <andrew.burgess@embecosm.com> 176363 176364 gdb/testsuite: update test gdb.base/step-over-syscall.exp 176365 I was looking at PR gdb/19675 and the related test 176366 gdb.base/step-over-syscall.exp. This test includes a call to kfail 176367 when we are testing a displaced step over a clone syscall. 176368 176369 While looking at the test I removed the call to kfail and ran the 176370 test, and was surprised that the test passed. 176371 176372 I ran the test a few times and it does sometimes fail, but mostly it 176373 passed fine. 176374 176375 PR gdb/19675 describes how, when we displaced step over a clone, the 176376 new thread is created with a $pc in the displaced step buffer. GDB 176377 then fails to "fix" this $pc (for the new thread), and the thread will 176378 be set running with its current $pc value. This means that the new 176379 thread will just start executing from whatever happens to be after the 176380 displaced stepping buffer. 176381 176382 In the original PR gdb/19675 bug report Yao Qi was seeing the new 176383 thread cause a segfault, the problem is, what actually happens is 176384 totally undefined. 176385 176386 On my machine, I'm seeing the new thread reenter main, it then starts 176387 trying to run the test again (in the new thread). This just happens 176388 to be safe enough (in this simple test) that most of the time the 176389 inferior doesn't crash. 176390 176391 In this commit I try to make the test slightly more likely to fail by 176392 doing a couple of things. 176393 176394 First, I added a static variable to main, this is set true when the 176395 first thread enters main, if a second thread ever enters main then I 176396 force an abort. 176397 176398 Second, when the test is finishing I want to ensure that the new 176399 threads have had a chance to do "something bad" if they are going to. 176400 So I added a global counter, as each thread starts successfully it 176401 decrements the counter. The main thread does not proceed to the final 176402 marker function (where GDB has placed a breakpoint) until all threads 176403 have started successfully. This means that if the newly created 176404 thread doesn't successfully enter clone_fn then the counter will never 176405 reach zero and the test will timeout. 176406 176407 With these two changes my hope is that the test should fail more 176408 reliably, and so, I have also changed the test to call setup_kfail 176409 before the specific steps that we expect to misbehave instead of just 176410 calling kfail and skipping parts of the test completely. The benefit 176411 of this is that if/when we fix GDB this test will start to KPASS and 176412 we'll know to update this test to remove the setup_kfail call. 176413 1764142021-08-05 GDB Administrator <gdbadmin@sourceware.org> 176415 176416 Automatic date update in version.in 176417 1764182021-08-05 Lancelot SIX <lsix@lancelotsix.com> 176419 176420 gdb: Use unwinder name in frame_info::to_string 176421 While working on a stack unwinding issue using 'set debug frame on', I 176422 noticed the frame_info::to_string method could be slightly improved. 176423 176424 Unwinders have been given a name in 176425 a154d838a70e96d888620c072e2d6ea8bdf044ca. Before this patch, frame_info 176426 debug output prints the host address of the used unwinder, which is not 176427 easy to interpret. This patch proposes to use the unwinder name 176428 instead since we now have it. 176429 176430 Before the patch: 176431 176432 {level=1,type=NORMAL_FRAME,unwind=0x2ac1763ec0,pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac} 176433 176434 With the patch: 176435 176436 {level=1,type=NORMAL_FRAME,unwinder="riscv prologue",pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac} 176437 176438 Tested on riscv64-linux-gnu. 176439 1764402021-08-04 Simon Marchi <simon.marchi@polymtl.ca> 176441 176442 gdb/testsuite: fix gdb.base/info-macros.exp with clang 176443 The test gdb.base/info-macros.exp says that it doesn't pass the "debug" 176444 option to prepare_for_testing because that would cause -g to appear 176445 after -g3 on the command line, and that would cause some gcc versions to 176446 not include macro info. I don't know what gcc versions this refers to. 176447 I tested with gcc 4.8, and that works fine with -g after -g3. 176448 176449 The current state is problematic when testing with CC_FOR_TARGET=clang, 176450 because then only -fdebug-macro is included. No -g switch if included, 176451 meaning we get a binary without any debug info, and the test fails. 176452 176453 One way to fix it would be to add "debug" to the options when the 176454 compiler is clang. 176455 176456 However, the solution I chose was to specify "debug" in any case, even 176457 for gcc. Other macro tests such as gdb.base/macscp.exp do perfectly 176458 fine with it. Also, this lets the test use the debug flag specified by 176459 the board file. For example, we can test with GCC and DWARF 5, with: 176460 176461 $ make check RUNTESTFLAGS="--target_board unix/gdb:debug_flags=-gdwarf-5" TESTS="gdb.base/info-macros.exp" 176462 176463 With the hard-coded -g3, this wouldn't actually test with DWARF 5. 176464 176465 Change-Id: I33fa92ee545007d3ae9c52c4bb2d5be6b5b698f1 176466 1764672021-08-04 Simon Marchi <simon.marchi@polymtl.ca> 176468 176469 gdb: avoid dereferencing empty str_offsets_base optional in dwarf_decode_macros 176470 Since 4d7188abfdf2 ("gdbsupport: add debug assertions in 176471 gdb::optional::get"), some macro-related tests fail on Ubuntu 20.04 with 176472 the system gcc 9.3.0 compiler when building with _GLIBCXX_DEBUG. For 176473 example, gdb.base/info-macros.exp results in: 176474 176475 (gdb) break -qualified main 176476 /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = long unsigned int]: Assertion `this->has_value ()' failed. 176477 176478 The binary contains DWARF 4 debug info and includes a pre-standard 176479 (pre-DWARF 5) .debug_macro section. The CU doesn't have a 176480 DW_AT_str_offsets_base attribute (which doesn't exist in DWARF 4). The 176481 field dwarf2_cu::str_offsets_base is therefore empty. At 176482 dwarf2/read.c:24138, we unconditionally read the value in the optional, 176483 which triggers the assertion shown above. 176484 176485 The same thing happens when building the test program with DWARF 5 with 176486 the same gcc compiler, as that version of gcc doesn't use indirect 176487 string forms, even with DWARF 5. So it still doesn't add a 176488 DW_AT_str_offsets_base attribute on the CU. 176489 176490 Fix that by propagating down a gdb::optional<ULONGEST> for the str 176491 offsets base instead of ULONGEST. That value is only used in 176492 dwarf_decode_macro_bytes, when encountering an "strx" macro operation 176493 (DW_MACRO_define_strx or DW_MACRO_undef_strx). Add a check there that 176494 we indeed have a value in the optional before reading it. This is 176495 unlikely to happen, but could happen in theory with an erroneous file 176496 that uses DW_MACRO_define_strx but does not provide a 176497 DW_AT_str_offsets_base (in practice, some things would probably have 176498 failed before and stopped processing of debug info). I tested the 176499 complaint by inverting the condition and using a clang-compiled binary, 176500 which uses the strx operators. This is the result: 176501 176502 During symbol reading: use of DW_MACRO_define_strx with unknown string offsets base [in module /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/info-macros/info-macros] 176503 176504 The test now passes cleanly with the setup mentioned above, and the 176505 testsuite looks on par with how it was before 4d7188abfdf2. 176506 176507 Change-Id: I7ebd2724beb7b9b4178872374c2a177aea696e77 176508 1765092021-08-04 Simon Marchi <simon.marchi@polymtl.ca> 176510 176511 gdb: fix typo in complaint in dwarf2/macro.c 176512 I saw this complaint when my code had some bug, and spotted the typo. 176513 Fix it, and while at it mention DW_MACRO as well (it would be confusing 176514 to only see DW_MACINFO with a file that uses a DWARF 5 .debug_macro 176515 section). I contemplated the idea of passing the knowledge of whether 176516 we are dealing with a .debug_macro section or .debug_macinfo section, to 176517 print only the right one. But in the end, I don't think that trouble is 176518 necessary for a complaint nobody is going to see. 176519 176520 Change-Id: I276ce8da65c3eac5304f64a1e246358ed29cdbbc 176521 1765222021-08-04 Simon Marchi <simon.marchi@polymtl.ca> 176523 176524 gdb: fix warnings in bsd-kvm.c 176525 Building on OpenBSD, I get warnings like: 176526 176527 CXX bsd-kvm.o 176528 /home/simark/src/binutils-gdb/gdb/bsd-kvm.c:241:18: error: ISO C++11 does not allow conversion from string literal to 'char *' [-Werror,-Wwritable-strings] 176529 nl[0].n_name = "_dumppcb"; 176530 ^ 176531 176532 Silence those by adding casts. 176533 176534 Change-Id: I2bef4eebcc306762a4e3e5b5c52f67ecf2820503 176535 1765362021-08-04 Andreas Krebbel <krebbel@linux.ibm.com> 176537 176538 IBM Z: Remove lpswey parameter 176539 opcodes/ 176540 * s390-opc.c (INSTR_SIY_RD): New instruction format. 176541 (MASK_SIY_RD): New instruction mask. 176542 * s390-opc.txt: Change instruction format of lpswey to SIY_RD. 176543 176544 gas/ 176545 * testsuite/gas/s390/zarch-arch14.d: Remove last operand of 176546 lpswey. 176547 * testsuite/gas/s390/zarch-arch14.s: Likewise. 176548 1765492021-08-04 Alan Modra <amodra@gmail.com> 176550 176551 PR28162, segment fault in mips_elf_assign_gp 176552 For the testcase in the PR, _bfd_mips_elf32_gprel16_reloc is passed a 176553 NULL output_bfd. As expected for reloc special functions if called by 176554 objdump or when final linking. The function attempts to find the 176555 output by 176556 output_bfd = symbol->section->output_section->owner; 176557 That makes some sense, since when handling a gp-relative reloc we need 176558 the relevant gp to which the symbol is relative. Possibly the gp 176559 value can be one for a shared library? But that doesn't seem useful 176560 or supported by the various abi docs and won't work as written. 176561 Symbols defined in shared libraries have section->output_section 176562 NULL, and what's more the code in mips_elf_assign_gp isn't set up to 176563 look at shared library symbols. 176564 176565 Also, if the symbol is a SHN_ABS one the owner of *ABS* section is 176566 NULL, which will result in the testcase segfault. The only gp to 176567 which an absolute symbol can be relative is the linker output bfd when 176568 linking, or the input bfd when not. This patch arranges to do that 176569 for all gp-relative reloc symbols. 176570 176571 * elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Don't use the 176572 section symbol to find the output bfd, use input_section. 176573 (mips_elf_gprel32_reloc, mips16_gprel_reloc): Likewise. 176574 * elf64-mips.c (mips_elf64_gprel16_reloc): Likewise. 176575 (mips_elf64_literal_reloc, mips_elf64_gprel32_reloc): Likewise. 176576 (mips16_gprel_reloc): Likewise. 176577 1765782021-08-04 Tom de Vries <tdevries@suse.de> 176579 176580 [gdb/symtab] Use lambda function instead of addrmap_foreach_check 176581 Use a lambda function instead of addrmap_foreach_check, 176582 which removes the need for static variables. 176583 176584 Also remove unnecessary static on local var temp_obstack in test_addrmap. 176585 176586 gdb/ChangeLog: 176587 176588 2021-08-04 Tom de Vries <tdevries@suse.de> 176589 176590 * addrmap.c (addrmap_foreach_check): Remove. 176591 (array, val1, val2): Move ... 176592 (test_addrmap): ... here. Remove static on temp_obstack. Use lambda 176593 function instead of addrmap_foreach_check. 176594 1765952021-08-04 H.J. Lu <hjl.tools@gmail.com> 176596 176597 elf: Treat undefined version as hidden 176598 Since undefined version can't be used to resolve any references without 176599 the original definition, treat it as hidden. 176600 176601 bfd/ 176602 176603 PR binutils/28158 176604 * elf.c (_bfd_elf_get_symbol_version_string): Treat undefined 176605 version as hidden. 176606 176607 ld/ 176608 176609 PR binutils/28158 176610 * testsuite/ld-elf/linux-x86.exp: Run PR binutils/28158 tests. 176611 * testsuite/ld-elf/pr28158-1.c: New file. 176612 * testsuite/ld-elf/pr28158-2.S: Likewise. 176613 * testsuite/ld-elf/pr28158.nd: Likewise. 176614 * testsuite/ld-elf/pr28158.rd: Likewise. 176615 * testsuite/ld-elf/pr28158.t: Likewise. 176616 * testsuite/ld-elfvers/vers2.dsym: Updated. 176617 * testsuite/ld-elfvers/vers3.dsym: Likewise. 176618 * testsuite/ld-elfvers/vers6.dsym: Likewise. 176619 * testsuite/ld-elfvers/vers19.dsym: Likewise. 176620 * testsuite/ld-elfvers/vers22.dsym: Likewise. 176621 * testsuite/ld-elfvers/vers23.dsym: Likewise. 176622 * testsuite/ld-elfvers/vers23d.dsym: Likewise. 176623 * testsuite/ld-elfvers/vers27d4.dsym: Likewise. 176624 * testsuite/ld-elfvers/vers28c.dsym: Likewise. 176625 1766262021-08-04 Tom de Vries <tdevries@suse.de> 176627 176628 [gdb/symtab] Implement addrmap_mutable_find 176629 Currently addrmap_mutable_find is not implemented: 176630 ... 176631 static void * 176632 addrmap_mutable_find (struct addrmap *self, CORE_ADDR addr) 176633 { 176634 /* Not needed yet. */ 176635 internal_error (__FILE__, __LINE__, 176636 _("addrmap_find is not implemented yet " 176637 "for mutable addrmaps")); 176638 } 176639 ... 176640 176641 I implemented this because I needed it during debugging, to be able to do: 176642 ... 176643 (gdb) p ((dwarf2_psymtab *)addrmap_find (map, addr))->filename 176644 ... 176645 before and after a call to addrmap_set_empty. 176646 176647 Since this is not used otherwise, added addrmap unit test. 176648 176649 Build on x86_64-linux, tested by doing: 176650 ... 176651 $ gdb -q -batch -ex "maint selftest addrmap" 176652 Running selftest addrmap. 176653 Ran 1 unit tests, 0 failed 176654 ... 176655 176656 gdb/ChangeLog: 176657 176658 2021-08-03 Tom de Vries <tdevries@suse.de> 176659 176660 * gdb/addrmap.c (addrmap_mutable_find): Implement 176661 [GDB_SELF_TESTS] (CHECK_ADDRMAP_FIND): New macro. 176662 [GDB_SELF_TESTS] (core_addr, addrmap_foreach_check, test_addrmap) 176663 (_initialize_addrmap): New function. 176664 1766652021-08-04 Clément Chigot <clement.chigot@atos.net> 176666 176667 gas: correctly output XCOFF tbss symbols with XTY_CM type. 176668 Global tbss symbols weren't correctly handled and were generating 176669 a symbol with XTY_SD instead of XTY_CM as expected. 176670 176671 gas/ 176672 * config/tc-ppc.c (ppc_frog_symbol): Generate a XTY_CM when 176673 a symbol has a storage class of XMC_UL. 176674 1766752021-08-04 Clément Chigot <clement.chigot@atos.net> 176676 176677 gas: always add dummy symbols when creating XCOFF sections. 176678 Most of the algorithms for XCOFF in tc-ppc.c assume that 176679 the csects field of a ppc_xcoff_section isn't NULL. 176680 This was already made for most of the sections with the creation 176681 of a dummy symbol. 176682 This patch simply mades it default when creating a xcoff_section. 176683 176684 gas/ 176685 * config/tc-ppc.c (ppc_init_xcoff_section): Always create 176686 the dummy symbol. 176687 (md_begin): Adjust ppc_init_xcoff_section call. 176688 (ppc_comm): Likewise. 176689 (ppc_change_csect): Likewise. 176690 1766912021-08-04 Alan Modra <amodra@gmail.com> 176692 176693 PR28156, rename.c doesn't compile with MinGW 176694 Guard against lack of struct timespec definition. 176695 176696 PR 28156 176697 * rename.c (get_stat_atime, get_stat_mtime): Don't compile 176698 unless HAVE_UTIMENSAT is defined. 176699 1767002021-08-04 Alan Modra <amodra@gmail.com> 176701 176702 PR28155, Superfluous "the" in the man page 176703 PR 28155 176704 * ld.texi (Options <runtime library name>): Correct grammar. 176705 176706 revise PE IMAGE_SCN_LNK_NRELOC_OVFL test 176707 * coffcode.h (coff_set_alignment_hook): Test that the resulting 176708 reloc count is not less than 0xffff. 176709 1767102021-08-04 Simon Marchi <simon.marchi@polymtl.ca> 176711 176712 gdb: follow-fork: push target and add thread in target_follow_fork 176713 In the context of ROCm-gdb [1], the ROCm target sits on top of the 176714 linux-nat target. when a process forks, it needs to carry over some 176715 data from the forking inferior to the fork child inferior. Ideally, the 176716 ROCm target would implement the follow_fork target_ops method, but there 176717 are some small problems. This patch fixes these, which helps the ROCm 176718 target, but also makes things more consistent and a bit nicer in 176719 general, I believe. 176720 176721 The main problem is: when follow-fork-mode is "parent", 176722 target_follow_fork is called with the parent as the current inferior. 176723 When it's "child", target_follow_fork is called with the child as the 176724 current inferior. This means that target_follow_fork is sometimes 176725 called on the parent's target stack and sometimes on the child's target 176726 stack. 176727 176728 The parent's target stack may contain targets above the process target, 176729 such as the ROCm target. So if follow-fork-child is "parent", the ROCm 176730 target would get notified of the fork and do whatever is needed. But 176731 the child's target stack, at that moment, only contains the exec and 176732 process target copied over from the parent. The child's target stack is 176733 set up by follow_fork_inferior, before calling target_follow_fork. In 176734 that case, the ROCm target wouldn't get notified of the fork. 176735 176736 For consistency, I think it would be good to always call 176737 target_follow_fork on the parent inferior's target stack. I think it 176738 makes sense as a way to indicate "this inferior has called fork, do 176739 whatever is needed". The desired outcome of the fork (whether an 176740 inferior is created for the child, do we need to detach from the child) 176741 can be indicated by passed parameter. 176742 176743 I therefore propose these changes: 176744 176745 - make follow_fork_inferior always call target_follow_fork with the 176746 parent as the current inferior. That lets all targets present on the 176747 parent's target stack do some fork-related handling and push 176748 themselves on the fork child's target stack if needed. 176749 176750 For this purpose, pass the child inferior down to target_follow_fork 176751 and follow_fork implementations. This is nullptr if no inferior is 176752 created for the child, because we want to detach from it. 176753 176754 - as a result, in follow_fork_inferior, detach from the parent inferior 176755 (if needed) only after the target_follow_fork call. This is needed 176756 because we want to call target_follow_fork before the parent's 176757 target stack is torn down. 176758 176759 - hand over to the targets in the parent's target stack (including the 176760 process target) the responsibility to push themselves, if needed, to 176761 the child's target stack. Also hand over the responsibility to the 176762 process target, at the same time, to create the child's initial 176763 thread (just like we do for follow_exec). 176764 176765 - pass the child inferior to exec_on_vfork, so we don't need to swap 176766 the current inferior between parent and child. Nothing in 176767 exec_on_vfork depends on the current inferior, after this change. 176768 176769 Although this could perhaps be replaced with just having the exec 176770 target implement follow_fork and push itself in the child's target 176771 stack, like the process target does... We would just need to make 176772 sure the process target calls beneath()->follow_fork(...). I'm not 176773 sure about this one. 176774 176775 gdb/ChangeLog: 176776 176777 * target.h (struct target_ops) <follow_fork>: Add inferior* 176778 parameter. 176779 (target_follow_fork): Likewise. 176780 * target.c (default_follow_fork): Likewise. 176781 (target_follow_fork): Likewise. 176782 * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. 176783 (fbsd_nat_target::follow_fork): Likewise, and call 176784 inf_ptrace_target::follow_fork. 176785 * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. 176786 * linux-nat.c (linux_nat_target::follow_fork): Likewise, and 176787 call inf_ptrace_target::follow_fork. 176788 * obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise. 176789 * obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call 176790 inf_ptrace_target::follow_fork. 176791 * remote.c (class remote_target) <follow_fork>: Likewise. 176792 (remote_target::follow_fork): Likewise, and call 176793 process_stratum_target::follow_fork. 176794 * process-stratum-target.h (class process_stratum_target) 176795 <follow_fork>: New. 176796 * process-stratum-target.c 176797 (process_stratum_target::follow_fork): New. 176798 * target-delegates.c: Re-generate. 176799 176800 [1] https://github.com/ROCm-Developer-Tools/ROCgdb 176801 176802 Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929 176803 1768042021-08-04 GDB Administrator <gdbadmin@sourceware.org> 176805 176806 Automatic date update in version.in 176807 1768082021-08-03 Carl Love <cel@us.ibm.com> 176809 176810 Fixes for mi-fortran-modules.exp fixes 176811 Output has additional information for a given filename. 176812 176813 gdb/testsuite/ChangeLog 176814 * gdb.mi/mi-fortran-modules.exp (system_modules_pattern, 176815 system_module_symbols_pattern): Add check for additional symbols 176816 on the line 176817 1768182021-08-03 Simon Marchi <simon.marchi@polymtl.ca> 176819 176820 gdbsupport: add debug assertions in gdb::optional::get 176821 The libstdc++ version of optional contains some runtime checks enabled 176822 when _GLIBCXX_DEBUG is defined. I think it would be useful if our 176823 version contained similar checks. 176824 176825 Add checks in the two `get` methods, also conditional on _GLIBCXX_DEBUG. 176826 I think it's simpler to use that macro rather than introducing a new 176827 GDB-specific one, as I think that if somebody is interested in enabling 176828 these runtime checks, they'll also be interested in enabling the 176829 libstdc++ runtime checks (and vice-versa). 176830 176831 I implemented these checks using gdb_assert. Note that gdb_assert 176832 throws (after querying the user), and we are in noexcept methods. That 176833 means that std::terminate / abort will immediately be called. I think 176834 this is ok, since if those were "real" _GLIBCXX_DEBUG checks, abort 176835 would be called straight away. 176836 176837 If I add a dummy failure, it looks like so: 176838 176839 $ ./gdb -q -nx --data-directory=data-directory 176840 /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = int]: Assertion `this->has_value ()' failed. 176841 A problem internal to GDB has been detected, 176842 further debugging may prove unreliable. 176843 Quit this debugging session? (y or n) n 176844 [1] 658767 abort (core dumped) ./gdb -q -nx --data-directory=data-directory 176845 176846 Change-Id: Iadfdcd131425bd2ca6a2de30d7b22e9b3cc67793 176847 1768482021-08-03 Alok Kumar Sharma <AlokKumar.Sharma@amd.com> 176849 176850 [gdb/testsuite] templates.exp to accept clang++ output 176851 Please consider below testcase with intended error. 176852 `````````` 176853 constexpr const char cstring[] = "Eta"; 176854 template <const char*, typename T> class Column {}; 176855 using quick = Column<cstring,double>; // cstring without '&' 176856 176857 void lookup() { 176858 quick c1; 176859 c1.ls(); 176860 } 176861 `````````` 176862 It produces below error. 176863 `````````` 176864 no member named 'ls' in 'Column<&cstring, double>'. 176865 `````````` 176866 Please note that error message contains '&' for cstring, which is absent 176867 in actual program. 176868 Clang++ does not generate & in such cases and this should also be 176869 accepted as correct output. 176870 176871 gdb/testsuite/ChangeLog: 176872 176873 * gdb.cp/templates.exp: Accept different but correct output 176874 from the Clang++ compiled binary also. 176875 1768762021-08-03 GDB Administrator <gdbadmin@sourceware.org> 176877 176878 Automatic date update in version.in 176879 1768802021-08-02 Tom Tromey <tromey@adacore.com> 176881 176882 Handle compiler-generated suffixes in Ada names 176883 The compiler may add a suffix to a mangled name. A typical example 176884 would be splitting a function and creating a ".cold" variant. 176885 176886 This patch changes Ada decoding (aka demangling) to handle these 176887 suffixes. It also changes the encoding process to handle them as 176888 well. 176889 176890 A symbol like "function.cold" will now be displayed to the user as 176891 "function[cold]". The "." is not simply preserved because that is 176892 already used in Ada. 176893 1768942021-08-02 Tom Tromey <tromey@adacore.com> 176895 176896 Remove uses of fprintf_symbol_filtered 176897 I believe that many calls to fprintf_symbol_filtered are incorrect. 176898 In particular, there are some that pass a symbol's print name, like: 176899 176900 fprintf_symbol_filtered (gdb_stdout, sym->print_name (), 176901 current_language->la_language, DMGL_ANSI); 176902 176903 fprintf_symbol_filtered uses the "demangle" global to decide whether 176904 or not to demangle -- but print_name does this as well. This can lead 176905 to double-demangling. Normally this could be innocuous, except I also 176906 plan to change Ada demangling in a way that causes this to fail. 176907 1769082021-08-02 Tom Tromey <tromey@adacore.com> 176909 176910 Handle type qualifier for enumeration name 176911 Pierre-Marie noticed that the Ada expression "TYPE'(NAME)" resolved 176912 incorrectly when "TYPE" was an enumeration type. Here, "NAME" should 176913 be unambiguous. 176914 176915 This patch fixes this problem. Note that the patch is not perfect -- 176916 it does not give an error if TYPE is an enumeration type but NAME is 176917 not an enumerator but does have some other meaning in scope. Fixing 176918 this proved difficult, and so I've left it out. 176919 1769202021-08-02 Tom Tromey <tromey@adacore.com> 176921 176922 Remove the type_qualifier global 176923 The type_qualifier global is no longer needed in the Ada expression 176924 parser, so this removes it. 176925 1769262021-08-02 Tom Tromey <tromey@adacore.com> 176927 176928 Defer Ada character literal resolution 176929 In Ada, an enumeration type can use a character literal as one of the 176930 enumerators. The Ada expression parser handles the appropriate 176931 conversion. 176932 176933 It turns out, though, that this conversion was handled incorrectly. 176934 For an expression like TYPE'(EXP), the conversion would be done for 176935 any such literal appearing in EXP -- but only the outermost such 176936 expression should really be affected. 176937 176938 This patch defers the conversion until the resolution phase, fixing 176939 the bug. 176940 1769412021-08-02 Tom Tromey <tromey@adacore.com> 176942 176943 Refactor Ada resolution 176944 In a subsequent patch, it will be convenient if an Ada expression 176945 operation can supply its own replacement object. This patch refactors 176946 Ada expression resolution to make this possible. 176947 176948 Remove add_symbols_from_enclosing_procs 176949 I noticed that add_symbols_from_enclosing_procs is empty, and can be 176950 removed. The one caller, ada_add_local_symbols, can also be 176951 simplified, removing some code that, I think, was an incorrect attempt 176952 to handle nested functions. 176953 1769542021-08-02 Tom Tromey <tromey@adacore.com> 176955 176956 Avoid crash in varobj deletion 176957 PR varobj/28131 points out a crash in the varobj deletion code. It 176958 took a while to reproduce this, but essentially what happens is that a 176959 top-level varobj deletes its root object, then deletes the "dynamic" 176960 object. However, deletion of the dynamic object may cause 176961 ~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj: 176962 176963 gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var) 176964 : gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn) 176965 { 176966 } 176967 176968 However, because var->root has already been destroyed, this is 176969 invalid. 176970 176971 I've added a new test case. This doesn't reliably crash, but the 176972 problem can easily be seen under valgrind (and, I presume, with ASAN, 176973 though I did not try this). 176974 176975 Tested on x86-64 Fedora 32. I also propose putting this on the GDB 11 176976 branch, with a suitable ChangeLog entry of course. 176977 176978 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131 176979 1769802021-08-02 Tom de Vries <tdevries@suse.de> 176981 176982 [gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-dwz-m 176983 When running with target board cc-with-dwz-m, we run into: 176984 ... 176985 (gdb) file dw2-using-debug-str-no-debug-str^M 176986 Reading symbols from dw2-using-debug-str-no-debug-str...^M 176987 (gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str 176988 ... 176989 176990 With native, the .debug_str section is present in the 176991 dw2-using-debug-str executable, and removed from the 176992 dw2-using-debug-str-no-debug-str executable. When loading the latter, a dwarf 176993 error is triggered. 176994 176995 With cc-with-dwz-m, the .debug_str section is not present in the 176996 dw2-using-debug-str executable, because it's already moved to 176997 .tmp/dw2-using-debug-str.dwz. Consequently, the removal has no effect, and no 176998 dwarf error is triggered, which causes the FAIL. 176999 177000 The same problem arises with target board cc-with-gnu-debuglink. 177001 177002 Fix this by detecting whether the .debug_str section is missing, and skipping 177003 the remainder of the test-case. 177004 177005 Tested on x86_64-linux. 177006 177007 gdb/testsuite/ChangeLog: 177008 177009 2021-08-02 Tom de Vries <tdevries@suse.de> 177010 177011 * gdb.dwarf2/dw2-using-debug-str.exp: Handle missing .debug_str 177012 section in dw2-using-debug-str. 177013 1770142021-08-02 Tom de Vries <tdevries@suse.de> 177015 177016 [gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-gdb-index 177017 When running with target board cc-with-gdb-index, we run into: 177018 ... 177019 (gdb) file dw2-using-debug-str-no-debug-str^M 177020 Reading symbols from dw2-using-debug-str-no-debug-str...^M 177021 Dwarf Error: DW_FORM_strp used without required section^M 177022 (gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str 177023 ... 177024 177025 The test expects the dwarf error, but has no matching pattern for the entire 177026 output. 177027 177028 Fix this by updating the regexp. 177029 177030 Tested on x86_64-linux. 177031 177032 gdb/testsuite/ChangeLog: 177033 177034 2021-08-02 Tom de Vries <tdevries@suse.de> 177035 177036 * gdb.dwarf2/dw2-using-debug-str.exp: Update regexp to match 177037 cc-with-gdb-index output. 177038 1770392021-08-02 Tom de Vries <tdevries@suse.de> 177040 177041 [gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp with cc-with-gdb-index 177042 When running with target board cc-with-gdb-index, we run into: 177043 ... 177044 rm: cannot remove '/tmp/tmp.JmYTeiuFjj/*.gdb-index': \ 177045 No such file or directory^M 177046 FAIL: gdb.dwarf2/per-bfd-sharing.exp: \ 177047 couldn't remove files in temporary cache dir 177048 ... 177049 177050 Fix this, as in gdb.base/index-cache.exp, by only FAILing when 177051 $expecting_index_cache_use. 177052 177053 Tested on x86_64-linux. 177054 177055 gdb/testsuite/ChangeLog: 177056 177057 2021-08-02 Tom de Vries <tdevries@suse.de> 177058 177059 * gdb.dwarf2/per-bfd-sharing.exp: Only expect index-cache files 177060 when $expecting_index_cache_use. 177061 1770622021-08-02 Tom de Vries <tdevries@suse.de> 177063 177064 [gdb/testsuite] Fix gdb.dwarf2/gdb-index-nodebug.exp with cc-with-gdb-index 177065 When running with target board cc-with-gdb-index, we run into: 177066 ... 177067 (gdb) save gdb-index .^M 177068 Error while writing index for `gdb-index-nodebug': \ 177069 Cannot use an index to create the index^M 177070 (gdb) FAIL: gdb.dwarf2/gdb-index-nodebug.exp: try to save gdb index 177071 ... 177072 177073 Fix this by detecting an already present index, and marking the test 177074 unsupported. 177075 177076 Tested on x86_64-linux. 177077 177078 gdb/testsuite/ChangeLog: 177079 177080 2021-08-02 Tom de Vries <tdevries@suse.de> 177081 177082 * gdb.dwarf2/gdb-index-nodebug.exp: Mark unsupported when index 177083 already present. 177084 1770852021-08-02 Tom de Vries <tdevries@suse.de> 177086 177087 [gdb/testsuite] Fix gdb.dwarf2/fission-relative-dwo.exp with cc-with-gdb-index 177088 When running with target board cc-with-gdb-index, we run into: 177089 ... 177090 gdb compile failed, warning: Could not find DWO CU \ 177091 fission-relative-dwo.dwo(0x1234) referenced by CU at offset 0xc7 \ 177092 [in module outputs/gdb.dwarf2/fission-relative-dwo/.tmp/fission-relative-dwo] 177093 UNTESTED: gdb.dwarf2/fission-relative-dwo.exp: fission-relative-dwo.exp 177094 ERROR: failed to compile fission-relative-dwo 177095 ... 177096 177097 The problem is that: 177098 - the .dwo file is found relative to the executable, and 177099 - cc-with-tweaks.sh moves the executable to a temp dir, but not 177100 the .dwo file. 177101 177102 Fix this by copying the .dwo file alongside the executable in the temp dir. 177103 177104 Verified changes using shellcheck. 177105 177106 Tested on x86_64-linux. 177107 177108 gdb/ChangeLog: 177109 177110 2021-08-02 Tom de Vries <tdevries@suse.de> 177111 177112 * contrib/cc-with-tweaks.sh: Copy .dwo files alongside executable. 177113 1771142021-08-02 Shahab Vahedi <shahab@synopsys.com> 177115 177116 gdb: Make the builtin "boolean" type an unsigned type 177117 When printing the fields of a register that is of a custom struct type, 177118 the "unpack_bits_as_long ()" function is used: 177119 177120 do_val_print (...) 177121 cp_print_value_fields (...) 177122 value_field_bitfield (...) 177123 unpack_value_bitfield (...) 177124 unpack_bits_as_long (...) 177125 177126 This function may sign-extend the extracted field while returning it: 177127 177128 val >>= lsbcount; 177129 177130 if (...) 177131 { 177132 valmask = (((ULONGEST) 1) << bitsize) - 1; 177133 val &= valmask; 177134 if (!field_type->is_unsigned ()) 177135 if (val & (valmask ^ (valmask >> 1))) 177136 val |= ~valmask; 177137 } 177138 177139 return val; 177140 177141 lsbcount: Number of lower bits to get rid of. 177142 bitsize: The bit length of the field to be extracted. 177143 val: The register value. 177144 field_type: The type of field that is being handled. 177145 177146 While the logic here is correct, there is a problem when it is 177147 handling "field_type"s of "boolean". Those types are NOT marked 177148 as "unsigned" and therefore they end up being sign extended. 177149 Although this is not a problem for "false" (0), it definitely 177150 causes trouble for "true". 177151 177152 This patch constructs the builtin boolean type as such that it is 177153 marked as an "unsigned" entity. 177154 177155 The issue tackled here was first encountered for arc-elf32 target 177156 running on an x86_64 machine. The unit-test introduced in this change 177157 has passed for all the targets (--enable-targets=all) running on the 177158 same x86_64 host. 177159 177160 Fixes: https://sourceware.org/PR28104 177161 1771622021-08-02 GDB Administrator <gdbadmin@sourceware.org> 177163 177164 Automatic date update in version.in 177165 1771662021-08-01 Tom de Vries <tdevries@suse.de> 177167 177168 [gdb/testsuite] Fix gdb.base/maint.exp with cc-with-gdb-index 177169 With target board cc-with-gdb-index we run into: 177170 ... 177171 FAIL: gdb.base/maint.exp: maint print statistics 177172 ... 177173 177174 The output that is checked is: 177175 ... 177176 Statistics for 'maint':^M 177177 Number of "minimal" symbols read: 53^M 177178 Number of "full" symbols read: 40^M 177179 Number of "types" defined: 60^M 177180 Number of symbol tables: 7^M 177181 Number of symbol tables with line tables: 2^M 177182 Number of symbol tables with blockvectors: 2^M 177183 Number of read CUs: 2^M 177184 Number of unread CUs: 5^M 177185 Total memory used for objfile obstack: 20320^M 177186 Total memory used for BFD obstack: 4064^M 177187 Total memory used for string cache: 4064^M 177188 ... 177189 and the regexp doesn't match because it expects the "Number of read/unread 177190 CUs" lines in a different place. 177191 177192 Fix this by updating the regexp. 177193 177194 Tested on x86_64-linux. 177195 177196 gdb/testsuite/ChangeLog: 177197 177198 2021-08-01 Tom de Vries <tdevries@suse.de> 177199 177200 * gdb.base/maint.exp: Update "maint print statistics" to match 177201 output with target board cc-with-gdb-index. 177202 1772032021-08-01 Tom de Vries <tdevries@suse.de> 177204 177205 [gdb/testsuite] Fix gdb.base/index-cache.exp with cc-with-gdb-index 177206 With target board cc-with-gdb-index we run into: 177207 ... 177208 FAIL: gdb.base/index-cache.exp: couldn't remove files in temporary cache dir 177209 ... 177210 177211 The problem is that there are no files to remove, because the index cache 177212 isn't used, as indicated by $expecting_index_cache_use. 177213 177214 Fix this by only FAILing when $expecting_index_cache_use. 177215 177216 Tested on x86_64-linux. 177217 177218 gdb/testsuite/ChangeLog: 177219 177220 2021-08-01 Tom de Vries <tdevries@suse.de> 177221 177222 * gdb.base/index-cache.exp: 177223 1772242021-08-01 GDB Administrator <gdbadmin@sourceware.org> 177225 177226 Automatic date update in version.in 177227 1772282021-07-31 GDB Administrator <gdbadmin@sourceware.org> 177229 177230 Automatic date update in version.in 177231 1772322021-07-30 Tom Tromey <tom@tromey.com> 177233 177234 Use iterator_range in more places 177235 This changes a couple of spots to replace custom iterator range 177236 classes with a specialization of iterator_range. 177237 177238 Regression tested on x86-64 Fedora 34. 177239 1772402021-07-30 Tom Tromey <tom@tromey.com> 177241 177242 Replace exception_print_same with operator!= 177243 I noticed that exception_print_same is only used in a single spot, and 177244 it seemed to be better as an operator!= method attached to 177245 gdb_exception. 177246 177247 Regression tested on x86-64 Fedora 34. 177248 1772492021-07-30 Tom de Vries <tdevries@suse.de> 177250 177251 [gdb/build] Disable attribute nonnull 177252 With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build 177253 breaker in gdb, which caused a broader review of the usage of the nonnull 177254 attribute. 177255 177256 The current conclusion is that it's best to disable this. This is explained 177257 at length in the gdbsupport/common-defs.h comment. 177258 177259 Tested by building with trunk gcc. 177260 177261 gdb/ChangeLog: 177262 177263 2021-07-29 Tom de Vries <tdevries@suse.de> 177264 177265 * gdbsupport/common-defs.h (ATTRIBUTE_NONNULL): Disable. 177266 1772672021-07-30 Clément Chigot <clement.chigot@atos.net> 177268 177269 gas: ensure XCOFF DWARF subsection are initialized to 0 177270 debug_abbrev doesn't use end_exp to compute its size. However, it must 177271 be NULL. Otherwise, ppc_xcoff_end might try to access uninitialized 177272 memory. 177273 177274 gas/ 177275 * config/tc-ppc.c (ppc_dwsect): Use XCNEW instead of XNEW when creating 177276 a new subsection. 177277 1772782021-07-30 Clément Chigot <clement.chigot@atos.net> 177279 177280 bfd: ensure that symbols targeted by DWARF relocations are kept in XCOFF 177281 This patch improves XCOFF garbage collector pass, in order to keep 177282 symbols being referenced only by special sections like DWARF sections. 177283 177284 bfd/ 177285 * xcofflink.c (xcoff_mark): Replace SEC_MARK by gc_mark. 177286 Look through relocations even if xcoff_section_data is NULL. 177287 (xcoff_sweep): Check if any sections of a file is kept before 177288 adding its special sections. 177289 Call xcoff_mark for special sessions being kept instead of just 177290 marking them. 177291 (SEC_MARK): Remove 177292 (xcoff_mark_symbol): Replace SEC_MARK by gc_mark. 177293 (xcoff_keep_symbol_p): Likewise. 177294 (bfd_xcoff_size_dynamic_sections): Likewise. 177295 (xcoff_find_tc0): Likewise. 177296 1772972021-07-30 Clément Chigot <clement.chigot@atos.net> 177298 177299 bfd: avoid a crash when debug_section isn't created in XCOFF 177300 bfd/ 177301 * xcofflink.c (bfd_xcoff_size_dynamic_sections): 177302 Add check to know if debug_section is initialized. 177303 1773042021-07-30 Alan Modra <amodra@gmail.com> 177305 177306 readelf: catch archive_file_size of -1 177307 Fuzzers might put -1 in arhdr.ar_size. If the size is rounded up to 177308 and even number of bytes we get zero. 177309 177310 * readelf.c (process_archive): Don't round up archive_file_size. 177311 Do round up next_arhdr_offset calculation. 177312 1773132021-07-30 Alan Modra <amodra@gmail.com> 177314 177315 reloc_upper_bound size calculations 177316 Section reloc_count is an unsigned int. Adding one for a NULL 177317 terminator to an array of arelent pointers can wrap the count to 177318 zero. Avoid that by doing the addition as longs. 177319 177320 * coffgen.c (coff_get_reloc_upper_bound): Don't overflow unsigned 177321 int expression. 177322 * elf.c (_bfd_elf_get_reloc_upper_bound): Likewise. 177323 * elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Likewise. 177324 * mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise. 177325 * vms-alpha.c (alpha_vms_get_reloc_upper_bound): Likewise. 177326 1773272021-07-30 Alan Modra <amodra@gmail.com> 177328 177329 Sanity check _bfd_coff_read_string_table 177330 * coffgen.c (_bfd_coff_read_string_table): Catch overflows 177331 when calculating string table file location. 177332 1773332021-07-30 Alan Modra <amodra@gmail.com> 177334 177335 IMAGE_SCN_LNK_NRELOC_OVFL 177336 From microsoft docs: It is an error if IMAGE_SCN_LNK_NRELOC_OVFL is 177337 set and there are fewer than 0xffff relocations in the section. 177338 177339 * coffcode.h (coff_set_alignment_hook): Sanity check overflow 177340 reloc count. 177341 1773422021-07-30 Simon Marchi <simon.marchi@polymtl.ca> 177343 177344 gdb: fix nr_bits gdb_assert in append_flags_type_field 177345 The assertion 177346 177347 gdb_assert (nr_bits >= 1 && nr_bits <= type_bitsize); 177348 177349 is not correct. Well, it's correct in that we do want the number of 177350 bits to be in the range [1, type_bitsize]. But we don't check anywhere 177351 that the end of the specified flag is within the containing type. 177352 177353 The following code should generate a failed assertion, as the flag goes 177354 past the 32 bits of the underlying type, but it's currently not caught: 177355 177356 static void 177357 test_print_flag (gdbarch *arch) 177358 { 177359 type *flags_type = arch_flags_type (arch, "test_type", 32); 177360 type *field_type = builtin_type (arch)->builtin_uint32; 177361 append_flags_type_field (flags_type, 31, 2, field_type, "invalid"); 177362 } 177363 177364 (You can test this by registering it as a selftest using 177365 selftests::register_test_foreach_arc and running.) 177366 177367 Change the assertion to verify that the end bit is within the range of 177368 the underlying type. This implicitly verifies that nr_bits is not 177369 too big as well, so we don't need a separate assertion for that. 177370 177371 Change-Id: I9be79e5fd7a5917bf25b03b598727e6274c892e8 177372 Co-Authored-By: Tony Tye <Tony.Tye@amd.com> 177373 1773742021-07-30 GDB Administrator <gdbadmin@sourceware.org> 177375 177376 Automatic date update in version.in 177377 1773782021-07-29 John Baldwin <jhb@FreeBSD.org> 177379 177380 obsd-nat: Report both thread and PID in ::pid_to_str. 177381 This improves the output of info threads when debugging multiple 177382 inferiors (e.g. after a fork with detach_on_fork disabled). 177383 1773842021-07-29 John Baldwin <jhb@FreeBSD.org> 177385 177386 obsd-nat: Various fixes for fork following. 177387 - Don't use #ifdef's on ptrace ops. obsd-nat.h didn't include 177388 <sys/ptrace.h>, so the virtual methods weren't always overridden 177389 causing the fork following to not work. In addition, the thread and 177390 fork code is intertwined in ::wait and and the lack of #ifdef's 177391 there already assumed both were present. Finally, both of these 177392 ptrace ops have been present in OpenBSD for at least 10 years. 177393 177394 - Move duplicated code to enable PTRACE_FORK event reporting to a 177395 single function and invoke it on new child processes reported via 177396 PTRACE_FORK. 177397 177398 - Don't return early from PTRACE_FORK handling, but instead reset 177399 wptid to the correct ptid if the child reports its event before the 177400 parent. This allows the ptid fixup code to add thread IDs if the 177401 first event for a process is a PTRACE_FORK event. This also 177402 properly returns ptid's with thread IDs when reporting PTRACE_FORK 177403 events. 177404 177405 - Handle detach_fork by skipping the PT_DETACH. 177406 1774072021-07-29 John Baldwin <jhb@FreeBSD.org> 177408 177409 obsd-nat: Various fixes to obsd_nat_target::wait. 177410 - Call inf_ptrace_target::wait instead of duplicating the code. 177411 Replace a check for WIFSTOPPED on the returned status from waitpid 177412 by checking for TARGET_WAITKIND_STOPPED in the parsed status as is 177413 done in fbsd_nat_target::wait. 177414 177415 - Don't use inferior_ptid when deciding if a new process is a child vs 177416 parent of the fork. Instead, use find_inferior_pid and assume that 177417 if an inferior already exists, the pid in question is the parent; 177418 otherwise, the pid is the child. 177419 177420 - Don't use inferior_ptid when deciding if the ptid of the process 177421 needs to be updated with an LWP ID, or if this is a new thread. 177422 Instead, use the approach from fbsd-nat which is to check if a ptid 177423 without an LWP exists and if so update the ptid of that thread 177424 instead of adding a new thread. 177425 1774262021-07-29 John Baldwin <jhb@FreeBSD.org> 177427 177428 x86-bsd-nat: Only define gdb_ptrace when using debug registers. 177429 This fixes an unused function warning on OpenBSD which does not 177430 support PT_GETDBREGS. 177431 1774322021-07-29 John Baldwin <jhb@FreeBSD.org> 177433 177434 Don't compile x86 debug register support on OpenBSD. 177435 Simon Marchi tried gdb on OpenBSD, and it immediately segfaults when 177436 running a program. Simon tracked down the problem to x86_dr_low.get_status 177437 being nullptr at this point: 177438 177439 (lldb) print x86_dr_low.get_status 177440 (unsigned long (*)()) $0 = 0x0000000000000000 177441 (lldb) bt 177442 * thread #1, stop reason = step over 177443 * frame #0: 0x0000033b64b764aa gdb`x86_dr_stopped_data_address(state=0x0000033d7162a310, addr_p=0x00007f7ffffc5688) at x86-dregs.c:645:12 177444 frame #1: 0x0000033b64b766de gdb`x86_dr_stopped_by_watchpoint(state=0x0000033d7162a310) at x86-dregs.c:687:10 177445 frame #2: 0x0000033b64ea5f72 gdb`x86_stopped_by_watchpoint() at x86-nat.c:206:10 177446 frame #3: 0x0000033b64637fbb gdb`x86_nat_target<obsd_nat_target>::stopped_by_watchpoint(this=0x0000033b65252820) at x86-nat.h:100:12 177447 frame #4: 0x0000033b64d3ff11 gdb`target_stopped_by_watchpoint() at target.c:468:46 177448 frame #5: 0x0000033b6469b001 gdb`watchpoints_triggered(ws=0x00007f7ffffc61c8) at breakpoint.c:4790:32 177449 frame #6: 0x0000033b64a8bb8b gdb`handle_signal_stop(ecs=0x00007f7ffffc61a0) at infrun.c:6072:29 177450 frame #7: 0x0000033b64a7e3a7 gdb`handle_inferior_event(ecs=0x00007f7ffffc61a0) at infrun.c:5694:7 177451 frame #8: 0x0000033b64a7c1a0 gdb`fetch_inferior_event() at infrun.c:4090:5 177452 frame #9: 0x0000033b64a51921 gdb`inferior_event_handler(event_type=INF_REG_EVENT) at inf-loop.c:41:7 177453 frame #10: 0x0000033b64a827c9 gdb`infrun_async_inferior_event_handler(data=0x0000000000000000) at infrun.c:9384:3 177454 frame #11: 0x0000033b6465bd4f gdb`check_async_event_handlers() at async-event.c:335:4 177455 frame #12: 0x0000033b65070917 gdb`gdb_do_one_event() at event-loop.cc:216:10 177456 frame #13: 0x0000033b64af0db1 gdb`start_event_loop() at main.c:421:13 177457 frame #14: 0x0000033b64aefe9a gdb`captured_command_loop() at main.c:481:3 177458 frame #15: 0x0000033b64aed5c2 gdb`captured_main(data=0x00007f7ffffc6470) at main.c:1353:4 177459 frame #16: 0x0000033b64aed4f2 gdb`gdb_main(args=0x00007f7ffffc6470) at main.c:1368:7 177460 frame #17: 0x0000033b6459d787 gdb`main(argc=5, argv=0x00007f7ffffc6518) at gdb.c:32:10 177461 frame #18: 0x0000033b6459d521 gdb`___start + 321 177462 177463 On BSDs, get_status is set in _initialize_x86_bsd_nat, but only if 177464 HAVE_PT_GETDBREGS is defined. PT_GETDBREGS doesn't exist on OpenBSD, so 177465 get_status (and the other fields of x86_dr_low) are left as nullptr. 177466 177467 OpenBSD doesn't support getting or setting the x86 debug registers, so 177468 fix by omitting debug register support entirely on OpenBSD: 177469 177470 - Change x86bsd_nat_target to only inherit from x86_nat_target if 177471 PT_GETDBREGS is supported. 177472 177473 - Don't include x86-nat.o and nat/x86-dregs.o for OpenBSD/amd64. They 177474 were already omitted for OpenBSD/i386. 177475 1774762021-07-29 Carl Love <cel@us.ibm.com> 177477 177478 Fix for gdb.tui/tui-layout-asm.exp 177479 The width of the window is too narrow to display the entire assembly line. 177480 The width of the columns in the window changes as the test walks thru the 177481 terminal window output. The column change results in the first and second 177482 reads of the same line to differ thus causing the test to fail. Increasing 177483 the width of the window keeps the column width consistent thru the test. 177484 177485 If the test fails, the added check prints an message to the log file if 177486 the failure may be due to the window being too narrow. 177487 177488 gdb/testsuite/ChangeLog 177489 177490 * gdb.tui/tui-layout-asm.exp: Replace window width of 80 with the 177491 tui_asm_window_width variable for the width. Add if 177492 count_whitespace check. 177493 (count_whitespace): New proc 177494 1774952021-07-29 George Barrett <bob@bob131.so> 177496 177497 guile/scm-math: indentation fixes 177498 Changes the indenting of a few expressions in 177499 vlscm_convert_typed_number to be better in line with the prevailing 177500 code style. 177501 177502 gdb/ChangeLog: 177503 177504 2021-07-30 George Barrett <bob@bob131.so> 177505 177506 * guile/scm-math.c (vlscm_convert_typed_number): Fix the 177507 indentation of calls to gdbscm_make_out_of_range_error. 177508 177509 Change-Id: I7463998b77c17a00e88058e89b52fa029ee40e03 177510 1775112021-07-29 George Barrett <bob@bob131.so> 177512 177513 guile: fix make-value with pointer type 177514 Calling the `make-value' procedure with an integer value and a pointer 177515 type for the #:type argument triggers a failed assertion in 177516 `get_unsigned_type_max', as that function doesn't consider pointers to 177517 be an unsigned type. This commit fixes the issue by adding a separate 177518 code path for pointers. 177519 177520 As previously suggested, range checking is done using a new helper 177521 function in gdbtypes. 177522 177523 gdb/ChangeLog: 177524 177525 2021-07-30 George Barrett <bob@bob131.so> 177526 177527 * gdbtypes.h (get_pointer_type_max): Add declaration. 177528 * gdbtypes.c (get_pointer_type_max): Add definition for new 177529 helper function. 177530 * guile/scm-math.c (vlscm_convert_typed_number): Add code path 177531 for handling conversions to pointer types without failing an 177532 assert. 177533 177534 gdb/testsuite/ChangeLog: 177535 177536 2021-07-30 George Barrett <bob@bob131.so> 177537 177538 * gdb.guile/scm-math.exp (test_value_numeric_ops): Add test 177539 for creating pointers with make-value. 177540 (test_make_pointer_value, test_pointer_numeric_range): Add 177541 test procedures containing checks for integer-to-pointer 177542 validation. 177543 177544 Change-Id: I9994dd1c848840a3d995f745e6d72867732049f0 177545 1775462021-07-29 George Barrett <bob@bob131.so> 177547 177548 gdbtypes: return value from get_unsigned_type_max 177549 Changes the signature of get_unsigned_type_max to return the computed 177550 value rather than returning void and writing the value into a pointer 177551 passed by the caller. 177552 177553 gdb/ChangeLog: 177554 177555 2021-07-30 George Barrett <bob@bob131.so> 177556 177557 * gdbtypes.h (get_unsigned_type_max): Change signature to 177558 return the result instead of accepting a pointer argument in 177559 which to store the result. 177560 * gdbtypes.c (get_unsigned_type_max): Likewise. 177561 * guile/scm-math.c (vlscm_convert_typed_number): Update caller 177562 of get_unsigned_type_max. 177563 (vlscm_integer_fits_p): Likewise. 177564 177565 Change-Id: Ibb1bf0c0fa181fac7853147dfde082a7d1ae2323 177566 1775672021-07-29 Clément Chigot <clement.chigot@atos.net> 177568 177569 gas: improve C_BSTAT and C_STSYM symbols handling on XCOFF 177570 A C_BSTAT debug symbol specifies the beginning of a static block. 177571 Its n_value is the index of the csect containing static symbols. 177572 A C_STSYM debug symbol represents the stabstring of a statically 177573 allocated symbol. Its n_value is the offset in the csect pointed 177574 by the containing C_BSTAT. 177575 177576 These two special n_value were not correctly handled both when 177577 generating object files with gas or when reading them with objdump. 177578 This patch tries to improve that and, above all, to allow gas-generated 177579 object files with such symbols to be accepted by AIX ld. 177580 177581 bfd/ 177582 * coff-bfd.c (bfd_coff_get_syment): Adjust n_value of symbols 177583 having fix_value = 1 in order to be an index and not a memory 177584 offset. 177585 * coffgen.c (coff_get_symbol_info): Likewize. 177586 (coff_print_symbol): Likewize. 177587 177588 gas/ 177589 * config/tc-ppc.c (ppc_frob_label): Don't change within if 177590 already set. 177591 (ppc_stabx): Remove workaround changing exp.X_add_symbol's 177592 within. 177593 * config/tc-ppc.h (struct ppc_tc_sy): Update comments. 177594 * symbols.c (resolve_symbol_value): Remove symbol update 177595 when final_val is 0 and it's an AIX debug symbol. 177596 * testsuite/gas/ppc/aix.exp: Add new tests. 177597 * testsuite/gas/ppc/xcoff-stsym-32.d: New test. 177598 * testsuite/gas/ppc/xcoff-stsym-64.d: New test. 177599 * testsuite/gas/ppc/xcoff-stsym.s: New test. 177600 1776012021-07-29 George Barrett <bob@bob131.so> 177602 177603 Guile: temporary breakpoints 177604 Adds API to the Guile bindings for creating temporary breakpoints and 177605 querying whether an existing breakpoint object is temporary. This is 177606 effectively a transliteration of the Python implementation. 177607 177608 It's worth noting that the added `is_temporary' flag is ignored in the 177609 watchpoint registration path. This replicates the behaviour of the 177610 Python implementation, but might be a bit surprising for users. 177611 177612 gdb/ChangeLog: 177613 177614 2021-06-09 George Barrett <bob@bob131.so> 177615 177616 * guile/scm-breakpoint.c (gdbscm_breakpoint_object::spec): Add 177617 is_temporary field. 177618 (temporary_keyword): Add keyword object for make-breakpoint 177619 argument parsing. 177620 (gdbscm_make_breakpoint): Accept #:temporary keyword argument 177621 and store the value in the allocated object's 177622 spec.is_temporary. 177623 (gdbscm_register_breakpoint_x): Pass the breakpoint's 177624 spec.is_temporary value to create_breakpoint. 177625 (gdbscm_breakpoint_temporary): Add breakpoint-temporary? 177626 procedure implementation. 177627 (breakpoint_functions::make-breakpoint): Update documentation 177628 string and fix a typo. 177629 (breakpoint_functions::breakpoint-temporary?): Add 177630 breakpoint-temporary? procedure. 177631 (gdbscm_initialize_breakpoints): Initialise temporary_keyword 177632 variable. 177633 NEWS (Guile API): Mention new temporary breakpoints API. 177634 177635 gdb/doc/ChangeLog: 177636 177637 2021-06-09 George Barrett <bob@bob131.so> 177638 177639 * guile.texi (Breakpoints In Guile): Update make-breakpoint 177640 documentation to reflect new #:temporary argument. 177641 Add documentation for new breakpoint-temporary? procedure. 177642 177643 gdb/testsuite/ChangeLog: 177644 177645 2021-06-09 George Barrett <bob@bob131.so> 177646 177647 * gdb.guile/scm-breakpoint.exp: Add additional tests for 177648 temporary breakpoints. 177649 177650 Change-Id: I2de332ee7c256f5591d7141ab3ad50d31b871d17 177651 1776522021-07-29 GDB Administrator <gdbadmin@sourceware.org> 177653 177654 Automatic date update in version.in 177655 1776562021-07-28 Simon Marchi <simon.marchi@polymtl.ca> 177657 177658 gdb: clean up some things in features/Makefile 177659 Clean up some things I noticed: 177660 177661 - we generate a regformats/microblaze-with-stack-protect.dat file. I 177662 don't think this is used. It could be used by a GDBserver built for 177663 Microblaze, but GDBserver isn't ported to Microblaze. So I don't 177664 think that's used at all. Remove the entry in features/Makefile and 177665 the file itself. 177666 177667 - There are a bunch of *-expedite values in features/Makefile for 177668 architectures for which we don't generate dat files. AFAIK, these 177669 *-expedite values are only used when generating dat files. Remove 177670 those that are not necessary. 177671 177672 - 32bit-segments.xml is not listed in the Makfile, but it's used. This 177673 means that it wouldn't get re-generated if we were to change how C 177674 files are generated from the XML. It looks like it was simply 177675 forgotten, add it. 177676 177677 Change-Id: I112d00db317102270e1df924473c37122ccb6c3a 177678 1776792021-07-28 H.J. Lu <hjl.tools@gmail.com> 177680 177681 x86: Simplify check for distinct TMM register operands 177682 If any pair of operands in AMX instructions with 3 TMM register operands 177683 are the same, the instruction will UD. Don't call register_number to 177684 check for distinct TMM register operands since all TMM register operands 177685 have the same size. 177686 177687 * config/tc-i386.c (check_VecOperands): Remove register_number 177688 call when checking for distinct TMM register operands. 177689 1776902021-07-28 H.J. Lu <hjl.tools@gmail.com> 177691 177692 ld: Run tmpdir/pr28138 only for native build 177693 * PR ld/28138 177694 * testsuite/ld-plugin/lto.exp: Run tmpdir/pr28138 only for 177695 native build. 177696 1776972021-07-28 H.J. Lu <hjl.tools@gmail.com> 177698 177699 bfd: Close the file descriptor if there is no archive fd 177700 Close the file descriptor if there is no archive plugin file descriptor 177701 to avoid running out of file descriptors on thin archives with many 177702 archive members. 177703 177704 bfd/ 177705 177706 PR ld/28138 177707 * plugin.c (bfd_plugin_close_file_descriptor): Close the file 177708 descriptor there is no archive plugin file descriptor. 177709 177710 ld/ 177711 177712 PR ld/28138 177713 * testsuite/ld-plugin/lto.exp: Run ld/28138 tests. 177714 * testsuite/ld-plugin/pr28138.c: New file. 177715 * testsuite/ld-plugin/pr28138-1.c: Likewise. 177716 * testsuite/ld-plugin/pr28138-2.c: Likewise. 177717 * testsuite/ld-plugin/pr28138-3.c: Likewise. 177718 * testsuite/ld-plugin/pr28138-4.c: Likewise. 177719 * testsuite/ld-plugin/pr28138-5.c: Likewise. 177720 * testsuite/ld-plugin/pr28138-6.c: Likewise. 177721 * testsuite/ld-plugin/pr28138-7.c: Likewise. 177722 1777232021-07-28 H.J. Lu <hjl.tools@gmail.com> 177724 177725 ld: Report error reason when a library cannot be found 177726 With "ulimit -n 20", report: 177727 177728 ld: cannot find -lgcc: Too many open files 177729 177730 instead of 177731 177732 ld: cannot find -lgcc 177733 177734 * ldfile.c (ldfile_open_file): Rport error reason when a library 177735 cannot be found. 177736 1777372021-07-28 Sergei Trofimovich <siarheit@google.com> 177738 177739 texi2pod.pl: add no-op --no-split option support [PR28144] 177740 Change 2faf902da ("generate single html manual page by default") 177741 added use of --no-split option to makeinfo. binutils reuses 177742 makeinfo options for texi2pod.pl wrapper. Unsupported option 177743 led to silent manpage truncation. 177744 177745 The change adds no-op option support. 177746 177747 etc/ 177748 177749 * texi2pod.pl: Handle no-op --no-split option. 177750 1777512021-07-28 Andrew Burgess <andrew.burgess@embecosm.com> 177752 177753 gdb: fix missing space in some info variables output 177754 Fixes PR gdb/28121. When a user declares an array like this: 177755 177756 int * const foo_1[3]; 177757 177758 And in GDB the user does this: 177759 177760 (gdb) info variables foo 177761 All variables matching regular expression "foo": 177762 177763 File test.c: 177764 1: int * constfoo_1[3]; 177765 177766 Notice the missing space between 'const' and 'foo_1'. This is fixed 177767 in c_type_print_varspec_prefix (c-typeprint.c) by passing through the 177768 flag that indicates if a trailing space is needed, rather than hard 177769 coding the flag to false as we currently do. 177770 177771 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28121 177772 1777732021-07-28 Tom de Vries <tdevries@suse.de> 177774 177775 [gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5 177776 [ I've confused things by forgetting to add -gdwarf-4 in $subject of 177777 commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with 177778 gcc-11". So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is 177779 the default for gcc-11. I keep getting confused because of working with a 177780 system gcc-11 compiler that was patched to switch the default back to 177781 -gdwarf-4. ] 177782 177783 When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default 177784 -gdwarf-5), I run into: 177785 ... 177786 (gdb) print pa_ptr.all^M 177787 Unhandled dwarf expression opcode 0xff^M 177788 (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all 177789 ... 177790 177791 What happens is that pa_ptr: 177792 ... 177793 <2><1523>: Abbrev Number: 3 (DW_TAG_variable) 177794 <1524> DW_AT_name : pa_ptr 177795 <1529> DW_AT_type : <0x14fa> 177796 ... 177797 has type: 177798 ... 177799 <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef) 177800 <14fb> DW_AT_name : foo__packed_array_ptr 177801 <1500> DW_AT_type : <0x1504> 177802 <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type) 177803 <1505> DW_AT_byte_size : 8 177804 <1505> DW_AT_type : <0x1509> 177805 ... 177806 which is a pointer to a subrange: 177807 ... 177808 <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type) 177809 <150a> DW_AT_lower_bound : 0 177810 <150b> DW_AT_upper_bound : 0x3fffffffffffffffff 177811 <151b> DW_AT_name : foo__packed_array 177812 <151f> DW_AT_type : <0x15cc> 177813 <1523> DW_AT_artificial : 1 177814 <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type) 177815 <15cd> DW_AT_byte_size : 16 177816 <15ce> DW_AT_encoding : 7 (unsigned) 177817 <15cf> DW_AT_name : long_long_long_unsigned 177818 <15d3> DW_AT_artificial : 1 177819 ... 177820 with upper bound of form DW_FORM_data16. 177821 177822 In gdb/dwarf/attribute.h we have: 177823 ... 177824 /* Return non-zero if ATTR's value falls in the 'constant' class, or 177825 zero otherwise. When this function returns true, you can apply 177826 the constant_value method to it. 177827 ... 177828 DW_FORM_data16 is not considered as constant_value cannot handle 177829 that. */ 177830 bool form_is_constant () const; 177831 ... 177832 so instead we have attribute::form_is_block (DW_FORM_data16) == true. 177833 177834 Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR 177835 instead of a PROP_CONST and end up trying to evaluate the constant 177836 0x3fffffffffffffffff as if it were a locexpr, which causes the 177837 "Unhandled dwarf expression opcode 0xff". 177838 177839 In contrast, with -gdwarf-4 we have: 177840 ... 177841 <164c> DW_AT_upper_bound : 18 byte block: \ 177842 9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \ 177843 (DW_OP_implicit_value 16 byte block: \ 177844 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 ) 177845 ... 177846 177847 Fix the dwarf error by translating the DW_FORM_data16 constant into a 177848 PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same 177849 result as with -gdwarf-4: 177850 ... 177851 (gdb) print pa_ptr.all^M 177852 That operation is not available on integers of more than 8 bytes.^M 177853 (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \ 177854 (PRMS: gdb/20991) 177855 ... 177856 177857 Tested on x86_64-linux, with gcc-11 and target board 177858 unix/gdb:debug_flags=-gdwarf-5. 177859 177860 gdb/ChangeLog: 177861 177862 2021-07-25 Tom de Vries <tdevries@suse.de> 177863 177864 * dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16. 177865 1778662021-07-28 will schmidt <will_schmidt@vnet.ibm.com> 177867 177868 Externalize the _bfd_set_gp_value function 177869 This change adds an external-visible wrapper for the _bfd_set_gp_value 177870 function. This is a prerequisite for some gdb patches that better 177871 handle powerpc64le relocations against ".TOC.". 177872 177873 * bfd.c (bfd_set_gp_value): New externally visible wrapper 177874 for _bfd_set_gp_value. 177875 * bfd-in2.h: Regenerate. 177876 1778772021-07-28 Alan Modra <amodra@gmail.com> 177878 177879 PowerPC: ignore sticky options for .machine 177880 PowerPC gas and objdump for a long time have allowed certain -m/-M 177881 options that extend a base cpu with extra functional units to be 177882 specified before the base cpu. For example, "-maltivec -mpower4" is 177883 the same as "-mpower4 -maltivec". See 177884 https://sourceware.org/pipermail/binutils/2008-January/054935.html 177885 177886 It doesn't make as much sense that .machine keep any of these 177887 "sticky" flags when handling a new base cpu. See gcc PR101393. I 177888 think that instead .machine ought to override the command line. 177889 That's what this patch does. It is still possible to extend cpu 177890 functionality with .machine. For example the following can be 177891 assembled when selecting a basic -mppc on the command line: 177892 .machine power5 177893 .machine altivec 177894 frin 1,2 177895 lvsr 3,4,5 177896 Here, ".machine altivec" extends the ".machine power5" so that both 177897 the power5 "frin" instruction and the altivec "lvsr" instruction are 177898 enabled. Swapping the two ".machine" directives would result in 177899 failure to assemble "lvsr". 177900 177901 This change will expose some assembly errors, such as the one in 177902 glibc/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c, a file 177903 compiled with -maltivec but containing 177904 asm volatile (".machine push;\n" 177905 ".machine \"power5\";\n" 177906 "vspltisb %0,0;\n" 177907 "vspltisb %1,-1;\n" 177908 "vpkuwus %0,%0,%1;\n" 177909 "mfvscr %0;\n" 177910 "stvx %0,0,%2;\n" 177911 ".machine pop;" 177912 : "=v" (v0), "=v" (v1) 177913 : "r" (vscr_ptr) 177914 : "memory"); 177915 It's just wrong to choose power5 for a bunch of altivec instructions 177916 and in fact all of those .machine directives are unnecessary. 177917 177918 * config/tc-ppc.c (ppc_machine): Don't use command line 177919 sticky options. 177920 1779212021-07-28 GDB Administrator <gdbadmin@sourceware.org> 177922 177923 Automatic date update in version.in 177924 1779252021-07-27 Tom de Vries <tdevries@suse.de> 177926 177927 [gdb/testsuite] Add xfail for PR gcc/101643 177928 With gcc 8.5.0 I run into: 177929 ... 177930 (gdb) print bad^M 177931 $2 = (0 => 0 <repeats 25 times>)^M 177932 (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad 177933 ... 177934 while with gcc 9.3.1 we have instead: 177935 ... 177936 (gdb) print bad^M 177937 $2 = (false <repeats 196 times>)^M 177938 (gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad 177939 ... 177940 177941 This is caused by gcc PR, which I've filed at 177942 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array 177943 not described as packed". 177944 177945 Fix by marking this as XFAIL. 177946 177947 Tested on x86_64-linux. 177948 177949 gdb/ChangeLog: 177950 177951 2021-07-27 Tom de Vries <tdevries@suse.de> 177952 177953 PR testsuite/26904 177954 * gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail. 177955 1779562021-07-27 Tom de Vries <tdevries@suse.de> 177957 177958 [gdb/testsuite] Add xfail for PR gcc/101633 177959 With gcc 7.5.0, I run into: 177960 ... 177961 (gdb) print objects^M 177962 $1 = ((tag => object, values => ()), (tag => unused))^M 177963 (gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array 177964 ... 177965 while with gcc 8.5.0 we have: 177966 ... 177967 (gdb) print objects^M 177968 $1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M 177969 (gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array 177970 ... 177971 177972 This is due to a gcc PR, which I've filed at 177973 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug] 177974 DW_TAG_subrange_type missing DW_AT_upper_bound". 177975 177976 Fix by marking this and related FAILs as XFAIL. 177977 177978 Tested on x86_64-linux. 177979 177980 gdb/ChangeLog: 177981 177982 2021-07-27 Tom de Vries <tdevries@suse.de> 177983 177984 PR testsuite/26903 177985 * gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails. 177986 1779872021-07-27 Andrew Burgess <andrew.burgess@embecosm.com> 177988 177989 gdb: remove VALUE_FRAME_ID and fix another frame debug issue 177990 This commit was originally part of this patch series: 177991 177992 (v1): https://sourceware.org/pipermail/gdb-patches/2021-May/179357.html 177993 (v2): https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html 177994 (v3): https://sourceware.org/pipermail/gdb-patches/2021-July/181028.html 177995 177996 However, that series is being held up in review, so I wanted to break 177997 out some of the non-related fixes in order to get these merged. 177998 177999 This commit addresses two semi-related issues, both of which are 178000 problems exposed by using 'set debug frame on'. 178001 178002 The first issue is in frame.c in get_prev_frame_always_1, and was 178003 introduced by this commit: 178004 178005 commit a05a883fbaba69d0f80806e46a9457727fcbe74c 178006 Date: Tue Jun 29 12:03:50 2021 -0400 178007 178008 gdb: introduce frame_debug_printf 178009 178010 This commit replaced fprint_frame with frame_info::to_string. 178011 However, the former could handle taking a nullptr while the later, a 178012 member function, obviously requires a non-nullptr in order to make the 178013 function call. In one place we are not-guaranteed to have a 178014 non-nullptr, and so, there is the possibility of triggering undefined 178015 behaviour. 178016 178017 The second issue addressed in this commit has existed for a while in 178018 GDB, and would cause this assertion: 178019 178020 gdb/frame.c:622: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed. 178021 178022 We attempt to get the frame_id for a frame while we are computing the 178023 frame_id for that same frame. 178024 178025 What happens is that when GDB stops we create a frame_info object for 178026 the sentinel frame (frame #-1) and then we attempt to unwind this 178027 frame to create a frame_info object for frame #0. 178028 178029 In the test case used here to expose the issue we have created a 178030 Python frame unwinder. In the Python unwinder we attemt to read the 178031 program counter register. 178032 178033 Reading this register will initially create a lazy register value. 178034 The frame-id stored in the lazy register value will be for the 178035 sentinel frame (lazy register values hold the frame-id for the frame 178036 from which the register will be unwound). 178037 178038 However, the Python unwinder does actually want to examine the value 178039 of the program counter, and so the lazy register value is resolved 178040 into a non-lazy value. This sends GDB into value_fetch_lazy_register 178041 in value.c. 178042 178043 Now, inside this function, if 'set debug frame on' is in effect, then 178044 we want to print something like: 178045 178046 frame=%d, regnum=%d(%s), .... 178047 178048 Where 'frame=%d' will be the relative frame level of the frame for 178049 which the register is being fetched, so, in this case we would expect 178050 to see 'frame=0', i.e. we are reading a register as it would be in 178051 frame #0. But, remember, the lazy register value actually holds the 178052 frame-id for frame #-1 (the sentinel frame). 178053 178054 So, to get the frame_info for frame #0 we used to call: 178055 178056 frame = frame_find_by_id (VALUE_FRAME_ID (val)); 178057 178058 Where VALUE_FRAME_ID is: 178059 178060 #define VALUE_FRAME_ID(val) (get_prev_frame_id_by_id (VALUE_NEXT_FRAME_ID (val))) 178061 178062 That is, we start with the frame-id for the next frame as obtained by 178063 VALUE_NEXT_FRAME_ID, then call get_prev_frame_id_by_id to get the 178064 frame-id of the previous frame. 178065 178066 The get_prev_frame_id_by_id function finds the frame_info for the 178067 given frame-id (in this case frame #-1), calls get_prev_frame to get 178068 the previous frame, and then calls get_frame_id. 178069 178070 The problem here is that calling get_frame_id requires that we know 178071 the frame unwinder, so then have to try each frame unwinder in turn, 178072 which would include the Python unwinder.... which is where we started, 178073 and thus we have a loop! 178074 178075 To prevent this loop GDB has an assertion in place, which is what 178076 actually triggers. 178077 178078 Solving the assertion failure is pretty easy, if we consider the code 178079 in value_fetch_lazy_register and get_prev_frame_id_by_id then what we 178080 do is: 178081 178082 1. Start with a frame_id taken from a value, 178083 2. Lookup the corresponding frame, 178084 3. Find the previous frame, 178085 4. Get the frame_id for that frame, and 178086 5. Lookup the corresponding frame 178087 6. Print the frame's level 178088 178089 Notice that steps 3 and 5 give us the exact same result, step 4 is 178090 just wasted effort. We could shorten this process such that we drop 178091 steps 4 and 5, thus: 178092 178093 1. Start with a frame_id taken from a value, 178094 2. Lookup the corresponding frame, 178095 3. Find the previous frame, 178096 6. Print the frame's level 178097 178098 This will give the exact same frame as a result, and this is what I 178099 have done in this patch by removing the use of VALUE_FRAME_ID from 178100 value_fetch_lazy_register. 178101 178102 Out of curiosity I looked to see how widely VALUE_FRAME_ID was used, 178103 and saw it was only used in one other place in valops.c:value_assign, 178104 where, once again, we take the result of VALUE_FRAME_ID and pass it to 178105 frame_find_by_id, thus introducing a redundant frame_id lookup. 178106 178107 I don't think the value_assign case risks triggering the assertion 178108 though, as we are unlikely to call value_assign while computing the 178109 frame_id for a frame, however, we could make value_assign slightly 178110 more efficient, with no real additional complexity, by removing the 178111 use of VALUE_FRAME_ID. 178112 178113 So, in this commit, I completely remove VALUE_FRAME_ID, and replace it 178114 with a use of VALUE_NEXT_FRAME_ID, followed by a direct call to 178115 get_prev_frame_always, this should make no difference in either case, 178116 and resolves the assertion issue from value.c. 178117 178118 As I said, this patch was originally part of another series, the 178119 original test relied on the fixes in that original series. However, I 178120 was able to create an alternative test for this issue by enabling 178121 frame debug within an existing test script. 178122 178123 This commit probably fixes bug PR gdb/27938, though the bug doesn't 178124 have a reproducer attached so it is not possible to know for sure. 178125 178126 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27938 178127 1781282021-07-27 Chenghua Xu <xuchenghua@loongson.cn> 178129 178130 Correct gs264e bfd_mach in mips_arch_choices. 178131 opcodes/ 178132 * mips-dis.c (mips_arch_choices): Correct gs264e bfd_mach. 178133 1781342021-07-27 Roland McGrath <mcgrathr@google.com> 178135 178136 Fix ld test case that assumes --enable-textrel-check 178137 ld/ 178138 * testsuite/ld-x86-64/x86-64.exp (Build textrel-1): Use --warn-textrel. 178139 1781402021-07-27 GDB Administrator <gdbadmin@sourceware.org> 178141 178142 Automatic date update in version.in 178143 1781442021-07-27 H.J. Lu <hjl.tools@gmail.com> 178145 178146 bfd: Set error to bfd_error_malformed_archive only if unset 178147 When reading an archive member, set error to bfd_error_malformed_archive 178148 on open_nested_file failure only if the error is unset. 178149 178150 PR ld/28138 178151 * archive.c (_bfd_get_elt_at_filepos): Don't set error to 178152 bfd_error_malformed_archive if it has been set. 178153 1781542021-07-26 Carl Love <cel@us.ibm.com> 178155 178156 Fix for mi-reverse.exp 178157 This test fails on PPC64 because PPC64 prints the value of 3.5 with 178158 more significant digits than on Intel. The patch updates the regular 178159 expression to allow for more significant digits on the constant. 178160 178161 gdb/testsuite/ChangeLog 178162 178163 * gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check 178164 for additional digits. 178165 1781662021-07-26 Tom Tromey <tromey@adacore.com> 178167 178168 Fix the Windows build 178169 The gdb build was broken on Windows after the patch to change 178170 get_inferior_cwd. This patch fixes the build. 178171 1781722021-07-26 Shahab Vahedi <shahab@synopsys.com> 178173 178174 gdb: Fix numerical field extraction for target description "flags" 178175 The "val_print_type_code_flags ()" function is responsible for 178176 extraction of fields for "flags" data type. These data types are 178177 used when describing a custom register type in a target description 178178 XML. The logic used for the extraction though is not sound: 178179 178180 unsigned field_len = TYPE_FIELD_BITSIZE (type, field); 178181 ULONGEST field_val 178182 = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1); 178183 178184 TYPE_FIELD_BITSIZE: The bit length of the field to be extracted. 178185 TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB. 178186 val: The register value. 178187 178188 Imagine you have a field that starts at position 1 and its length 178189 is 4 bits. According to the third line of the code snippet the 178190 shifting right would become "val >> -2", or "val >> 0xfff...fe" 178191 to be precise. That will result in a "field_val" of 0. 178192 178193 The correct extraction should be: 178194 178195 ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field); 178196 178197 The rest of the algorithm that masks out the higher bits is OK. 178198 178199 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 178200 1782012021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178202 178203 PATCH [10/10] arm: Alias 'ra_auth_code' to r12 for pacbti. 178204 gas/ 178205 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178206 178207 * config/tc-arm.c (reg_names): Alias 'ra_auth_code' to r12. 178208 1782092021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178210 178211 PATCH [9/10] arm: add 'pacg' instruction for Armv8.1-M pacbti extension 178212 gas/ 178213 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178214 178215 * config/tc-arm.c (T16_32_TAB): Add '_pacg'. 178216 (do_t_pacbti_pacg): New function. 178217 (insns): Define 'pacg' insn. 178218 * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacg' test. 178219 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178220 178221 opcodes/ 178222 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178223 178224 * arm-dis.c (thumb32_opcodes): Add 'pacg'. 178225 1782262021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178227 178228 PATCH [8/10] arm: add 'autg' instruction for Armv8.1-M pacbti extension 178229 gas/ 178230 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178231 178232 * config/tc-arm.c (T16_32_TAB): Add '_autg'. 178233 (insns): Define 'autg' insn. 178234 * testsuite/gas/arm/armv8_1-m-pacbti.d: Add autg test. 178235 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178236 178237 opcodes/ 178238 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178239 178240 * arm-dis.c (thumb32_opcodes): Add 'autg'. 178241 1782422021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178243 178244 PATCH [7/10] arm: add 'bxaut' instruction for Armv8.1-M pacbti extension 178245 gas/ 178246 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178247 178248 * config/tc-arm.c (T16_32_TAB): Add '_bxaut'. 178249 (do_t_pacbti_nonop): New function. 178250 (insns): Define 'bxaut' insn. 178251 * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'bxaut' test. 178252 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178253 178254 opcodes/ 178255 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178256 178257 * arm-dis.c (thumb32_opcodes): Add 'bxaut'. 178258 1782592021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178260 178261 PATCH [6/10] arm: Add -march=armv8.1-m.main+pacbti flag 178262 gas/ 178263 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178264 178265 * config/tc-arm.c (pacbti_ext): Define. 178266 (BAD_PACBTI): New macro. 178267 (armv8_1m_main_ext_table): Add 'pacbti' extension. 178268 178269 include/ 178270 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178271 178272 * opcode/arm.h (ARM_EXT3_PACBTI, ARM_AEXT3_V8_1M_MAIN_PACBTI): New 178273 macro. 178274 1782752021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178276 178277 PATCH [5/10] arm: Extend again arm_feature_set struct to provide more bits 178278 include/ 178279 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178280 178281 * opcode/arm.h (arm_feature_set): Extend 'core' field. 178282 (ARM_CPU_HAS_FEATURE, ARM_FSET_CPU_SUBSET, ARM_CPU_IS_ANY) 178283 (ARM_MERGE_FEATURE_SETS, ARM_CLEAR_FEATURE, ARM_FEATURE_EQUAL) 178284 (ARM_FEATURE_ZERO, ARM_FEATURE_CORE_EQUAL): Account for 178285 'core[2]'. 178286 (ARM_FEATURE_CORE_HIGH_HIGH): New macro. 178287 1782882021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178289 178290 PATCH [4/10] arm: add 'pac' instruction for Armv8.1-M pacbti extension 178291 gas/ 178292 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178293 178294 * config/tc-arm.c (T16_32_TAB): Add '_pac'. 178295 (insns): Add 'pac' insn. 178296 * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add pac tests. 178297 * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise. 178298 * testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise. 178299 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178300 178301 opcodes/ 178302 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178303 178304 * arm-dis.c (thumb32_opcodes): Add 'pac'. 178305 1783062021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178307 178308 PATCH [3/10] arm: add 'aut' instruction for Armv8.1-M pacbti extension 178309 gas/ 178310 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178311 178312 * config/tc-arm.c (insns): Add 'aut.' 178313 (T16_32_TAB): Add '_aut'. 178314 * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add 'aut' tests. 178315 * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise. 178316 * testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise. 178317 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178318 178319 opcodes/ 178320 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178321 178322 * arm-dis.c (thumb32_opcodes): Add 'aut'. 178323 1783242021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178325 178326 PATCH [2/10] arm: add 'pacbti' instruction for Armv8.1-M pacbti extension 178327 gas/ 178328 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178329 178330 * config/tc-arm.c 178331 (enum operand_parse_code): Add OP_SP and OP_R12. 178332 (parse_operands): Add switch cases for OP_SP and OP_R12. 178333 (T16_32_TAB): Add '_pacbti'. 178334 (do_t_pacbti): New function. 178335 (insns): Add 'pacbti'. 178336 * testsuite/gas/arm/armv8_1-m-pacbti-bad.d: New file. 178337 * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Likewise. 178338 * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise. 178339 * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacbti' to testcase. 178340 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178341 178342 opcodes/ 178343 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178344 178345 * arm-dis.c (thumb32_opcodes): Add 'pacbti' instruction. 178346 1783472021-07-26 Andrea Corallo <andrea.corallo@arm.com> 178348 178349 PATCH [1/10] arm: add 'bti' instruction for Armv8.1-M pacbti extension 178350 gas/ 178351 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178352 178353 * config/tc-arm.c (insns): Add 'bti' insn. 178354 * testsuite/gas/arm/armv8_1-m-pacbti.d: New file. 178355 * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise. 178356 178357 opcodes/ 178358 2021-06-11 Andrea Corallo <andrea.corallo@arm.com> 178359 178360 * arm-dis.c (thumb32_opcodes): Add bti instruction. 178361 1783622021-07-26 Andrew Burgess <andrew.burgess@embecosm.com> 178363 178364 gdb: move remaining ChangeLogs to legacy files 178365 In commit: 178366 178367 commit f069ea46a03ae868581d1c852da28e979ea1245a 178368 Date: Sat Jul 3 16:29:08 2021 -0700 178369 178370 Rename gdb/ChangeLog to gdb/ChangeLog-2021 178371 178372 The gdb/ChangeLog file was renamed, but all of the other ChangeLog 178373 files relating to gdb were left in place. 178374 178375 As I understand things, the no ChangeLogs policy applies to all the 178376 GDB related directories, so this commit renames all of the remaining 178377 GDB related ChangeLog files. 178378 178379 As with the original commit, the intention behind this commit is to 178380 hopefully stop people merging ChangeLog entries by mistake. 178381 178382 The renames carried out in this commit are: 178383 178384 gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021 178385 gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020 178386 gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021 178387 gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021 178388 gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021 178389 1783902021-07-26 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 178391 178392 gdb/mi: handle no condition argument case for -break-condition 178393 As reported in PR gdb/28076 [1], passing no condition argument to the 178394 -break-condition command (e.g.: "-break-condition 2") should clear the 178395 condition for breakpoint 2, just like CLI's "condition 2", but instead 178396 an error message is returned: 178397 178398 ^error,msg="-break-condition: Missing the <number> and/or <expr> argument" 178399 178400 The current implementation of the -break-condition command's argument 178401 handling (79aabb7308c "gdb/mi: add a '--force' flag to the 178402 '-break-condition' command") was done according to the documentation, 178403 where the condition argument seemed mandatory. However, the 178404 -break-condition command originally (i.e. before the 79aabb7308c 178405 patch) used the CLI's "cond" command, and back then not passing a 178406 condition argument was clearing out the condition. So, this is a 178407 regression in terms of the behavior. 178408 178409 Fix the argument handling of the -break-condition command to allow not 178410 having a condition argument, and also update the document to make the 178411 behavior clear. Also add test cases to test the scenarios which were 178412 previously not covered. 178413 178414 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076 178415 1784162021-07-26 GDB Administrator <gdbadmin@sourceware.org> 178417 178418 Automatic date update in version.in 178419 1784202021-07-25 GDB Administrator <gdbadmin@sourceware.org> 178421 178422 Automatic date update in version.in 178423 1784242021-07-24 Alan Modra <amodra@gmail.com> 178425 178426 Revert: PowerPC: Don't generate unused section symbols 178427 Blindly following x86 broke linux kernel builds. 178428 178429 bfd/ 178430 * elf32-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define as true. 178431 * elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Likewise. 178432 gas/ 178433 * testsuite/gas/ppc/power4.d: Adjust for section sym change. 178434 * testsuite/gas/ppc/test1elf32.d: Likewise. 178435 * testsuite/gas/ppc/test1elf64.d: Likewise. 178436 ld/ 178437 * testsuite/ld-powerpc/tlsexe.r: Adjust for section sym change. 178438 * testsuite/ld-powerpc/tlsexe32.r: Likewise. 178439 * testsuite/ld-powerpc/tlsexe32no.r: Likewise. 178440 * testsuite/ld-powerpc/tlsexeno.r: Likewise. 178441 * testsuite/ld-powerpc/tlsexenors.r: Likewise. 178442 * testsuite/ld-powerpc/tlsexers.r: Likewise. 178443 * testsuite/ld-powerpc/tlsexetoc.r: Likewise. 178444 * testsuite/ld-powerpc/tlsexetocrs.r: Likewise. 178445 * testsuite/ld-powerpc/tlsget.d: Likewise. 178446 * testsuite/ld-powerpc/tlsget.wf: Likewise. 178447 * testsuite/ld-powerpc/tlsget2.d: Likewise. 178448 * testsuite/ld-powerpc/tlsget2.wf: Likewise. 178449 * testsuite/ld-powerpc/tlsso.r: Likewise. 178450 * testsuite/ld-powerpc/tlsso32.r: Likewise. 178451 * testsuite/ld-powerpc/tlstocso.r: Likewise. 178452 1784532021-07-24 Alan Modra <amodra@gmail.com> 178454 178455 Re: ld script expression parsing 178456 Commit 40726f16a8d7 broke references to sections within ADDR(), and 178457 overlays with weird section names. 178458 178459 * ldgram.y (paren_script_name): New rule. 178460 (exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR. Similarly 178461 ensure script mode parsing for section name in SEGMENT_START. 178462 (overlay_section): Delete unnecessary ldlex_script call. Backup 178463 on a lookahead NAME parsed in expression mode. 178464 * testsuite/ld-elf/overlay.s: Add more sections. 178465 * testsuite/ld-elf/overlay.t: Test '-' in section names. 178466 1784672021-07-24 Frederic Cambus <fred@statdns.com> 178468 178469 Update the NetBSD system call table to match NetBSD-current. 178470 Generated from sys/sys/syscall.h revision 1.319. 178471 178472 We can safely remove the _lwp_gettid syscall, which was never exposed 178473 in libc and never made it into a release. 178474 178475 gdb/ChangeLog: 178476 178477 2021-07-23 Frederic Cambus <fred@statdns.com> 178478 178479 * syscalls/netbsd.xml: Regenerate. 178480 1784812021-07-24 GDB Administrator <gdbadmin@sourceware.org> 178482 178483 Automatic date update in version.in 178484 1784852021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178486 178487 gdb/testsuite: test get/set value of unregistered Guile parameter 178488 When creating a parameter in Guile, you have to create it using 178489 make-parameter and then register it with GDB with register-parameter!. 178490 In between, it's still possible (though not documented) to set the 178491 parameter's value. I broke this use case by mistake while writing this 178492 series, so thought it would be good to have a test for it. 178493 178494 I suppose that people could use this "feature" to give their parameter 178495 an initial value, even though make-parameter has an initial-value 178496 parameter for this. Nevertheless, changing this behavior could break 178497 some scripts, which is why I think it's important for it to be tested. 178498 178499 Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d 178500 1785012021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178502 178503 gdb: remove cmd_list_element::function::sfunc 178504 I don't understand what the sfunc function type in 178505 cmd_list_element::function is for. Compared to cmd_simple_func_ftype, 178506 it has an extra cmd_list_element parameter, giving the callback access 178507 to the cmd_list_element for the command being invoked. This allows 178508 registering the same callback with many commands, and alter the behavior 178509 using the cmd_list_element's context. 178510 178511 From the comment in cmd_list_element, it sounds like at some point it 178512 was the callback function type for set and show functions, hence the 178513 "s". But nowadays, it's used for many more commands that need to access 178514 the cmd_list_element object (see add_catch_command for example). 178515 178516 I don't really see the point of having sfunc at all, since do_sfunc is 178517 just a trivial shim that changes the order of the arguments. All 178518 commands using sfunc could just as well set cmd_list_element::func to 178519 their callback directly. 178520 178521 Therefore, remove the sfunc field in cmd_list_element and everything 178522 that goes with it. Rename cmd_const_sfunc_ftype to cmd_func_ftype and 178523 use it for cmd_list_element::func, as well as for the add_setshow 178524 commands. 178525 178526 Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0 178527 1785282021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178529 178530 gdb: rename cfunc to simple_func 178531 After browsing the CLI code for quite a while and trying really hard, I 178532 reached the conclusion that I can't give a meaningful explanation of 178533 what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't 178534 see a logic at all. That makes it very difficult to do any kind of 178535 change. Unless somebody can make sense out of all that, I'd like to try 178536 to retro-fit some logic in the cmd_list_element callback function code 178537 so that we can understand what is going on, do some cleanups and add new 178538 features. 178539 178540 The first change is about "cfunc". I can't figure out what the "c" in 178541 cfunc means. It's not const, because there's already "const" in 178542 "cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing 178543 const.. It's not "cmd" or "command", because there's already "cmd" in 178544 "cmd_const_cfunc_ftype". 178545 178546 The "main" command callback, cmd_list_element::func, has three 178547 parameters, whereas cfunc has two. It is missing the cmd_list_element 178548 parameter. So the only reason I see for cfunc to exist is to be a shim 178549 between the three and two parameter versions. Most commands don't need 178550 to receive the cmd_list_element object, so adding it everywhere would be 178551 long and would just add more unnecessary boilerplate. So since this is 178552 the "simple" version of the callback, compared to the "full", I suggest 178553 renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as 178554 everything (like the utility functions) that goes with it. 178555 178556 Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868 178557 1785582021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178559 178560 gdb: make inferior::m_terminal an std::string 178561 Same idea as the previous patch, but for m_terminal. 178562 178563 Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2 178564 1785652021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178566 178567 gdb: make inferior::m_cwd an std::string 178568 Same idea as the previous patch, but for m_cwd. 178569 178570 To keep things consistent across the board, change get_inferior_cwd as 178571 well, which is shared with GDBserver. So update the related GDBserver 178572 code too. 178573 178574 Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e 178575 1785762021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178577 178578 gdb: make inferior::m_args an std::string 178579 With the current code, both a NULL pointer and an empty string can mean 178580 "no arguments". We don't need this distinction. Changing to a string 178581 has the advantage that there is now a single state for that (an empty 178582 string), which makes the code a bit simpler in my opinion. 178583 178584 Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced 178585 1785862021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178587 178588 gdb: add setter/getter for inferior cwd 178589 Add cwd/set_cwd to the inferior class, remove set_inferior_args. 178590 Keep get_inferior_args, because it is used from fork_inferior, in shared 178591 code. The cwd could eventually be passed as a parameter eventually, 178592 though, I think that would be cleaner. 178593 178594 Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e 178595 1785962021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178597 178598 gdb: add setter/getter for inferior arguments 178599 Add args/set_args to the inferior class, remove the set_inferior_args 178600 and get_inferior_args functions, that would just be wrappers around 178601 them. 178602 178603 Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3 178604 1786052021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178606 178607 gdb: remove inferior::{argc,argv} 178608 There are currently two states that the inferior args can be stored. 178609 The main one is the `args` field, where they are stored as a single 178610 string. The other one is the `argc`/`argv` fields. 178611 178612 This last one is only used for arguments passed in GDB's 178613 command line. And the only outcome is that when get_inferior_args is 178614 called, `argc`/`argv` are serialized into `args`. So really, 178615 `argc`/`argv` is just a staging area before moving the arguments in 178616 `args`. 178617 178618 Simplify this by only keeping the `args` field. Change 178619 set_inferior_args_vector to immediately serialize the arguments into 178620 `args`, work that would be done in get_inferior_args later anyway. 178621 178622 The only time where this work would be "wasted" is when the user passes 178623 some arguments on the command line, but does not end up running the 178624 program. But that just seems unlikely. And it's not that much work. 178625 178626 Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a 178627 1786282021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178629 178630 gdb: un-share set_inferior_cwd declaration 178631 The declaration of set_inferior_cwd is currently shared between gdb and 178632 gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as 178633 set_inferior_cwd is not called from common code. Only get_inferior_cwd 178634 needs to. 178635 178636 The motivation for this is that a future patch will change the prototype 178637 of set_inferior_cwd in gdb, and I don't want to change it for gdbserver 178638 unnecessarily. I see this as a good cleanup in any case, to reduce to 178639 just the essential what is shared between GDB and GDBserver. 178640 178641 Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73 178642 1786432021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178644 178645 gdb.base/setshow.exp: fix duplicate test name 178646 Fix: 178647 178648 DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args 178649 178650 by giving some explicit test names. 178651 178652 Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072 178653 1786542021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178655 178656 gdb.base/setshow.exp: split in procs 178657 Split in multiple procs, one per topic, and start with a fresh GDB in 178658 each. I find it easier to work on a test with multiple smaller 178659 independent test procedures. For example, it's possible to comment all 178660 but one when working on one. It's also easier to add things without 178661 having to think about the impact on existing tests, and vice-versa. 178662 178663 Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2 178664 1786652021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178666 178667 gdb.base/setshow.exp: use save_vars to save/restore gdb_prompt 178668 Using save_vars is a bit better than what we have now, as it ensures the 178669 variable gets restored if the code within it throws an error. 178670 178671 Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27 178672 1786732021-07-23 Simon Marchi <simon.marchi@polymtl.ca> 178674 178675 gdb/testsuite: split gdb.python/py-parameter.exp in procs 178676 Split the file into multiple independent test procs, where each proc 178677 starts with a fresh GDB. I find it easier to understand what a test is 178678 doing when each part of the test is isolated and self-contained. It 178679 makes it easier to comment out some parts of the test while working / 178680 debugging a specific part. It also makes it easier to add new things 178681 (which a subsequent patch will do) without fear of impacting another part 178682 of the test. 178683 178684 Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d 178685 1786862021-07-23 Carl Love <cel@us.ibm.com> 178687 178688 Fix for gdb.python/py-breakpoint.exp 178689 Not all systems have hardware breakpoint support. Add a check 178690 to see if the system supports hardware breakpoints. 178691 178692 gdb/testsuite/ChangeLog 178693 178694 * gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add 178695 check for hardware breakpoint support. 178696 1786972021-07-23 Andrew Burgess <andrew.burgess@embecosm.com> 178698 178699 gdb/testsuite: don't error when trying to unset last_spawn_tty_name 178700 In spawn_capture_tty_name (lib/gdb.exp) we either set or unset 178701 last_spawn_tty_name depending on whether spawn_out(slave,name) exists 178702 or not. 178703 178704 One situation that might cause spawn_out(slave,name) to not exists is 178705 if the spawn function is called with the argument -leaveopen, which is 178706 how it is called when processes are created as part of a pipeline, the 178707 created process has no tty, instead its output is written to a file 178708 descriptor. 178709 178710 If a pipeline is created consisting of multiple processes then there 178711 will be multiple sequential calls to spawn, all using -leaveopen. The 178712 first of these calls is fine, spawn_out(slave,name) is not set, and so 178713 in spawn_capture_tty_name we unset last_spawn_tty_name. However, on 178714 the second call to spawn, spawn_out(slave,name) is still not set and 178715 so in spawn_capture_tty_name we again try to unset 178716 last_spawn_tty_name, this now throws an error (as last_spawn_tty_name 178717 is already unset). 178718 178719 Fix this issue by using -nocomplain with the call to unset in 178720 spawn_capture_tty_name. 178721 178722 Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1 178723 pass, and 1 unsupported test. After this commit I now see 16 passes 178724 from this test script. 178725 178726 I have also improved the code that used to do this: 178727 178728 if { [info exists spawn_out] } { 178729 set ::last_spawn_tty_name $spawn_out(slave,name) 178730 } else { 178731 ... 178732 } 178733 178734 The problem here is that we check for the existence of spawn_out, and 178735 then unconditionally read spawn_out(slave,name). A situation could 178736 arise where some other element of spawn_out is set, 178737 e.g. spawn_out(foo), in which case we would enter the if block and try 178738 to read a non-existent variable. After this commit we now check 178739 specifically for spawn_out(slave,name). 178740 178741 Finally, it is worth noting that before this issue was fixed runtest 178742 itself, or rather the expect process behind runtest, would segfault 178743 while exiting. I haven't looked at all into what the problem is here 178744 that caused expect to crash, as fixing the bug in GDB's testing 178745 scripts made the segfault go away. 178746 1787472021-07-23 Jan Beulich <jbeulich@suse.com> 178748 178749 x86: express unduly set rounding control bits in disassembly 178750 While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE, 178751 EVEX.b itself is not ignored when an insn permits neither rounding 178752 control nor SAE. 178753 178754 While changing this aspect of EVEX.b handling, also alter unduly set 178755 embedded broadcast: Don't call BadOp(), screwing up subsequent 178756 disassembly, but emit "{bad}" instead. 178757 1787582021-07-23 GDB Administrator <gdbadmin@sourceware.org> 178759 178760 Automatic date update in version.in 178761 1787622021-07-22 Tom de Vries <tdevries@suse.de> 178763 178764 [gdb/testsuite] Fix FAILs due to PR gcc/101575 178765 When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board 178766 unix/gdb:debug_flags=-gdwarf-4 we run into: 178767 ... 178768 (gdb) print/x s^M 178769 No definition of "s" in current context.^M 178770 (gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s 178771 ... 178772 which is caused by "runto defs.adb:20" taking us to defs__struct1IP: 178773 ... 178774 (gdb) break defs.adb:20^M 178775 Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M 178776 (gdb) run ^M 178777 Starting program: formatted_ref ^M 178778 ^M 178779 Breakpoint 1, defs__struct1IP () at defs.adb:20^M 178780 20 return s.x; -- Set breakpoint marker here.^M 178781 (gdb) print s1'access^M 178782 ... 178783 instead of the expected defs.f1: 178784 ... 178785 (gdb) break defs.adb:20^M 178786 Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M 178787 (gdb) run ^M 178788 Starting program: formatted_ref ^M 178789 ^M 178790 Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M 178791 20 return s.x; -- Set breakpoint marker here.^M 178792 ... 178793 178794 This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11, 178795 -gdwarf-4] Missing .file <n> directive causes invalid line info". 178796 178797 Fix this by when landing in defs__struct1IP: 178798 - xfailing the runto, and 178799 - issuing a continue to land in defs.f1. 178800 178801 Likewise in a few other test-cases. 178802 178803 Tested on x86_64-linux, with: 178804 - system gcc. 178805 - gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and 178806 unix/gdb:debug_flags=-gdwarf-5. 178807 178808 gdb/testsuite/ChangeLog: 178809 178810 2021-07-22 Tom de Vries <tdevries@suse.de> 178811 178812 * gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575. 178813 * gdb.ada/iwide.exp: Same. 178814 * gdb.ada/pkd_arr_elem.exp: Same. 178815 1788162021-07-22 Jan Beulich <jbeulich@suse.com> 178817 178818 x86: drop dq{b,d}_mode 178819 Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for 178820 consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly 178821 reflecting REX.W / VEX.W is not in line with the assembler's opcode 178822 table having NoRex64 / VexWIG in all respective templates, i.e. assembly 178823 input isn't being honored there either. Obviously the 0FC5 encodings of 178824 {,V}PEXTRW then also need adjustment for consistency reasons. 178825 178826 x86: drop vex_scalar_w_dq_mode 178827 It has only a single use and can easily be represented by dq_mode 178828 instead. Plus its handling in intel_operand_size() was duplicating 178829 that of vex_vsib_{d,q}_w_dq_mode anyway. 178830 178831 x86: drop xmm_m{b,w,d,q}_mode 178832 They're effectively redundant with {b,w,d,q}_mode. 178833 178834 x86: fold duplicate vector register printing code 178835 The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the 178836 shared logic out of the function, and invoke the new helper from both 178837 places. 178838 178839 x86: drop vex_mode and vex_scalar_mode 178840 These are fully redundant with, respectively, x_mode and scalar_mode. 178841 178842 x86: correct EVEX.V' handling outside of 64-bit mode 178843 Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored 178844 outside of 64-bit mode. Oddly enough there already are tests for these 178845 cases, but their expectations were wrong. (This may have been based on 178846 an old SDM version, where the restriction wasn't properly spelled out.) 178847 178848 x86: fold duplicate code in MOVSXD_Fixup() 178849 There's no need to have two paths printing the "xd" mnemonic suffix. 178850 178851 x86: fold duplicate register printing code 178852 What so far was OP_E_register() can be easily reused also for OP_G(). 178853 Add suitable parameters to the function and move the invocation of 178854 swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was 178855 a need to use movsxd_mode there, and its use gets in the way of the code 178856 folding. 178857 178858 x86-64: properly bounds-check %bnd<N> in OP_G() 178859 The restriction to %bnd0-%bnd3 requires to also check REX.R is clear, 178860 just like OP_E_Register() also includes REX.B in its check. 178861 178862 x86-64: generalize OP_G()'s EVEX.R' handling 178863 EVEX.R' is invalid to be clear not only for mask registers, but also for 178864 GPRs - IOW everything handled in this function. 178865 1788662021-07-22 Jan Beulich <jbeulich@suse.com> 178867 178868 x86: correct VCVT{,U}SI2SD rounding mode handling 178869 With EVEX.W clear the instruction doesn't ignore the rounding mode, but 178870 (like for other insns without rounding semantics) EVEX.b set causes #UD. 178871 Hence the handling of EVEX.W needs to be done when processing 178872 evex_rounding_64_mode, not at the decode stages. 178873 178874 Derive a new 64-bit testcase from the 32-bit one to cover the different 178875 EVEX.W treatment in both cases. 178876 1788772021-07-22 Jan Beulich <jbeulich@suse.com> 178878 178879 x86: drop OP_Mask() 178880 By moving its vex.r check there it becomes fully redundant with OP_G(). 178881 1788822021-07-22 GDB Administrator <gdbadmin@sourceware.org> 178883 178884 Automatic date update in version.in 178885 1788862021-07-21 Tom de Vries <tdevries@suse.de> 178887 178888 [gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11 178889 When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run 178890 into: 178891 ... 178892 KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \ 178893 (PRMS symtab/25507) 178894 FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2 178895 KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \ 178896 (PRMS symtab/25507) 178897 ... 178898 178899 [ Note that I get the same result with gcc-11 and target board 178900 unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ] 178901 178902 With gcc-10, I have this trace: 178903 ... 178904 64 get_alias_set (&xx); 178905 get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51 178906 51 if (t != NULL 178907 40 if (t->x != i) 178908 52 && TREE_TYPE (t).z != 1 178909 43 return x; 178910 53 && TREE_TYPE (t).z != 2 178911 43 return x; 178912 54 && TREE_TYPE (t).z != 3) 178913 43 return x; 178914 main () at step-and-next-inline.cc:65 178915 65 return 0; 178916 ... 178917 and with gcc-11, I have instead: 178918 ... 178919 64 get_alias_set (&xx); 178920 get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51 178921 51 if (t != NULL 178922 52 && TREE_TYPE (t).z != 1 178923 43 return x; 178924 53 && TREE_TYPE (t).z != 2 178925 43 return x; 178926 54 && TREE_TYPE (t).z != 3) 178927 43 return x; 178928 main () at step-and-next-inline.cc:65 178929 65 return 0; 178930 ... 178931 and with clang-10, I have instead: 178932 ... 178933 64 get_alias_set (&xx); 178934 get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51 178935 51 if (t != NULL 178936 52 && TREE_TYPE (t).z != 1 178937 53 && TREE_TYPE (t).z != 2 178938 54 && TREE_TYPE (t).z != 3) 178939 51 if (t != NULL 178940 57 } 178941 main () at step-and-next-inline.cc:65 178942 65 return 0; 178943 ... 178944 178945 The test-case tries to verify that we don't step into inlined function 178946 tree_check (lines 40-43) (so, with the clang trace we get that right). 178947 178948 The test-case then tries to kfail the problems when using gcc, but this is 178949 done in such a way that the testing still gets out of sync after a failure. 178950 That is: the "next step 2" check that is supposed to match 178951 "TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1": 178952 ... 178953 (gdb) next^M 178954 52 && TREE_TYPE (t).z != 1^M 178955 (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2 178956 ... 178957 178958 Fix this by issuing extra nexts to arrive at the required lines. 178959 178960 Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10 178961 and clang-12. 178962 178963 gdb/testsuite/ChangeLog: 178964 178965 2021-07-20 Tom de Vries <tdevries@suse.de> 178966 178967 * gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main): 178968 Tag closing brace with comment. 178969 * gdb.cp/step-and-next-inline.h: Update to keep identical with 178970 step-and-next-inline.cc. 178971 * gdb.cp/step-and-next-inline.exp: Issue extra next when required. 178972 1789732021-07-21 Nick Clifton <nickc@redhat.com> 178974 178975 Updated Russian translation for the bfd library 178976 1789772021-07-21 Luca Boccassi <luca.boccassi@microsoft.com> 178978 178979 Allows linker scripts to set the SEC_READONLY flag. 178980 * ld.texi: Document new output section type. 178981 * ldgram.y: Add new token. 178982 * ldlang.c: Handle the new flag. 178983 * ldlang.h: Add readonly_section to list of section types. 178984 * ldlex.l: Add a new identifier. 178985 * testsuite/ld-scripts/output-section-types.t: New example linker script. 178986 * testsuite/ld-scripts/output-section-types.d: Test driver. 178987 * testsyute/ld-scripts/script.exp: Run the new test. 178988 1789892021-07-21 Tom de Vries <tdevries@suse.de> 178990 178991 [gdb/testsuite] Fix FAILs due to PR gcc/101452 178992 When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5 178993 default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run 178994 into this regression: 178995 ... 178996 (gdb) ptype/o static_member^M 178997 /* offset | size */ type = struct static_member {^M 178998 - static static_member Empty;^M 178999 /* 0 | 4 */ int abc;^M 179000 ^M 179001 /* total size (bytes): 4 */^M 179002 }^M 179003 -(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member 179004 +(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member 179005 ... 179006 179007 This is caused by missing debug info, which I filed as gcc PR101452 - "[debug, 179008 dwarf-5] undefined static member removed by 179009 -feliminate-unused-debug-symbols". 179010 179011 It's not clear yet whether this is a bug or a feature, but work around this in 179012 the test-cases by: 179013 - defining the static member 179014 - adding additional_flags=-fno-eliminate-unused-debug-types. 179015 179016 Tested on x86_64-linux. 179017 179018 gdb/testsuite/ChangeLog: 179019 179020 2021-07-20 Tom de Vries <tdevries@suse.de> 179021 179022 * lib/gdb.exp (gcc_major_version): New proc. 179023 * gdb.base/ptype-offsets.cc: Define static member static_member::Empty. 179024 * gdb.cp/templates.exp: Define static member using -DGCC_BUG. 179025 * gdb.cp/m-static.exp: Add 179026 additional_flags=-fno-eliminate-unused-debug-types. 179027 * gdb.cp/pr-574.exp: Same. 179028 * gdb.cp/pr9167.exp: Same. 179029 1790302021-07-21 Tom de Vries <tdevries@suse.de> 179031 179032 [gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11 179033 With gcc-11 we run into: 179034 ... 179035 (gdb) print pa_ptr.all^M 179036 That operation is not available on integers of more than 8 bytes.^M 179037 (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991) 179038 ... 179039 179040 This is due to PR exp/20991 - "__int128 type support". Mark this and similar 179041 FAILs as KFAIL. 179042 179043 Also mark this FAIL: 179044 .... 179045 (gdb) print pa_ptr(3)^M 179046 cannot subscript or call something of type `foo__packed_array_ptr'^M 179047 (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) 179048 ... 179049 as a KFAIL for PR ada/28115 - "Support packed array encoded as 179050 DW_TAG_subrange_type". 179051 179052 Tested on x86_64-linux, with gcc-10 and gcc-11. 179053 179054 gdb/testsuite/ChangeLog: 179055 179056 2021-07-21 Tom de Vries <tdevries@suse.de> 179057 179058 * gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115. 179059 * gdb.ada/exprs.exp: Add KFAILs for PR20991. 179060 * gdb.ada/packed_array_assign.exp: Same. 179061 1790622021-07-21 Alan Modra <amodra@gmail.com> 179063 179064 as_bad_subtract 179065 Many places report errors of the nature "can't resolve a - b". 179066 This provides a utility function to report such errors consistently. 179067 I removed the section reporting and quotes around symbol names while I 179068 was at it. Compare 179069 ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section} 179070 with 179071 ifunc-2.s:4: Error: can't resolve bar1 - foo1 179072 179073 In many cases the section names don't help the user very much in 179074 figuring out what went wrong, and the quotes if present arguably ought 179075 to be placed around the entire expression: 179076 can't resolve `bar1 - foo1' 179077 179078 The patch also tidies some tc_get_reloc functions that leak memory on 179079 error paths. 179080 179081 * write.h (as_bad_subtract): Declare. 179082 * write.c (as_bad_subtract): New function. 179083 (fixup_segment): Use as_bad_subtract. 179084 * config/tc-arc.c (md_apply_fix): Likewise. 179085 * config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise. 179086 * config/tc-cris.c (md_apply_fix): Likewise. 179087 * config/tc-d10v.c (md_apply_fix): Likewise. 179088 * config/tc-d30v.c (md_apply_fix): Likewise. 179089 * config/tc-ft32.c (md_apply_fix): Likewise. 179090 * config/tc-h8300.c (tc_gen_reloc): Likewise. 179091 * config/tc-m68hc11.c (md_apply_fix): Likewise. 179092 * config/tc-mmix.c (mmix_frob_file): Likewise. 179093 * config/tc-mn10200.c (tc_gen_reloc): Likewise. 179094 * config/tc-nds32.c (nds32_apply_fix): Likewise. 179095 * config/tc-pru.c (md_apply_fix): Likewise. 179096 * config/tc-riscv.c (md_apply_fix): Likewise. 179097 * config/tc-s12z.c (md_apply_fix): Likewise. 179098 * config/tc-s390.c (md_apply_fix): Likewise. 179099 * config/tc-tilegx.c (md_apply_fix): Likewise. 179100 * config/tc-tilepro.c (md_apply_fix): Likewise. 179101 * config/tc-v850.c (md_apply_fix): Likewise. 179102 * config/tc-vax.c (md_apply_fix): Likewise. 179103 * config/tc-xc16x.c (tc_gen_reloc): Likewise. 179104 * config/tc-xgate.c (md_apply_fix): Likewise. 179105 * config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise. 179106 * config/tc-xtensa.c (md_apply_fix): Likewise. 179107 * config/tc-z80.c (tc_gen_reloc): Likewise. 179108 * config/tc-spu.c (md_apply_fix): Likewise. 179109 (tc_gen_reloc): Delete dead code. Free memory on error. 179110 * config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract. Free 179111 on error. 179112 * config/tc-crx.c (tc_gen_reloc): Likewise. 179113 * config/tc-ppc.c (tc_gen_reloc): Likewise. 179114 * testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message. 179115 * testsuite/gas/mips/lui-2.l: Likewise. 179116 * testsuite/gas/tic6x/reloc-bad-1.l: Likewise. 179117 1791182021-07-21 John Ericson <git@JohnEricson.me> 179119 179120 Remove `netbsdpe` support 179121 netbsdpe was deprecated in c2ce831330e10dab4703094491f80b6b9a5c2289. 179122 Since then, a release has passed (2.37), and it was marked obselete in 179123 5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that 179124 means we can now remove support altogether. 179125 179126 All branches in the "active" code are remove, and the target is 179127 additionally marked as obsolete next to the other removed ones for 179128 libbfd and gdb. 179129 179130 Per [1] from the NetBSD toolchain list, PE/COFF support was removed a 179131 decade ago. Furthermore, the sole mention of this target in the binutils 179132 commit history was in 2002. Together, I'm led to believe this target 179133 hasn't seen much attention in quite a while. 179134 179135 [1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html 179136 179137 bfd/ 179138 * config.bfd: Remove netbsdpe entry. 179139 binutils/ 179140 * configure.ac: Remove netbsdpe entry. 179141 * testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise. 179142 * configure: Regenerate. 179143 gas/ 179144 * configure.tgt: Remove netbsdpe entry. 179145 gdb/ 179146 * configure.tgt: Add netbsdpe to removed targets. 179147 ld/ 179148 * configure.tgt: Remove netbsdpe entry. 179149 * testsuite/ld-bootstrap/bootstrap.exp: Likewise. 179150 1791512021-07-21 GDB Administrator <gdbadmin@sourceware.org> 179152 179153 Automatic date update in version.in 179154 1791552021-07-20 Alan Modra <amodra@gmail.com> 179156 179157 PR28106, build of 2.37 fails on FreeBSD and Clang 179158 https://en.cppreference.com/w/cpp/types/NULL says NULL might be 179159 defined as nullptr. 179160 https://en.cppreference.com/w/cpp/language/reinterpret_cast says 179161 reinterpret_cast can't be used on nullptr. 179162 179163 PR gold/28106 179164 PR gold/27815 179165 * gc.h (gc_process_relocs): Use static_cast in Section_id constructor. 179166 1791672021-07-20 Luis Machado <luis.machado@linaro.org> 179168 179169 Fix printing of non-address types when memory tagging is enabled 179170 When the architecture supports memory tagging, we handle 179171 pointer/reference types in a special way, so we can validate tags and 179172 show mismatches. 179173 179174 Unfortunately, the currently implementation errors out when the user 179175 prints non-address values: composite types, floats, references, member 179176 functions and other things. 179177 179178 Vector registers: 179179 179180 (gdb) p $v0 179181 Value can't be converted to integer. 179182 179183 Non-existent internal variables: 179184 179185 (gdb) p $foo 179186 Value can't be converted to integer. 179187 179188 The same happens for complex types and printing struct/union types. 179189 179190 There are a few problems here. 179191 179192 The first one is that after print_command_1 evaluates the expression 179193 to print, the tag validation code call value_as_address 179194 unconditionally, without making sure we have have a suitable type 179195 where it makes to sense to call it. That results in value_as_address 179196 (if it isn't given a pointer-like type) trying to treat the value as 179197 an integer and convert it to an address, which #1 - doesn't make sense 179198 (i.e., no sense in validating tags after "print 1"), and throws for 179199 non-integer-convertible types. We fix this by making sure we have a 179200 pointer or reference type first, and only if so then proceed to check 179201 if the address-like value has tags. 179202 179203 The second is that we're calling value_as_address even if we have an 179204 optimized out or unavailable value, which throws, because the value's 179205 contents aren't fully accessible/readable. This error currently 179206 escapes out and aborts the print. This case is fixed by checking for 179207 optimized out / unavailable explicitly. 179208 179209 Third, the tag checking process does not gracefully handle exceptions. 179210 If any exception is thrown from the tag validation code, we abort the 179211 print. E.g., the target may fail to access tags via a running thread. 179212 Or the needed /proc files aren't available. Or some other untold 179213 reason. This is a bit too rigid. This commit changes print_command_1 179214 to catch errors, print them, and still continue with the normal 179215 expression printing path instead of erroring out and printing nothing 179216 useful. 179217 179218 With this patch, printing works correctly again: 179219 179220 (gdb) p $v0 179221 $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = { 179222 3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = { 179223 791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10, 179224 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224, 179225 0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079, 179226 12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = { 179227 62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}} 179228 (gdb) p $foo 179229 $2 = void 179230 (gdb) p 2 + 2i 179231 $3 = 2 + 2i 179232 179233 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110 179234 1792352021-07-20 Nelson Chu <nelson.chu@sifive.com> 179236 179237 RISC-V: Minor updates for architecture parser. 179238 * Two add subset functions is redundant. Keep the riscv_add_implicit_subset, 179239 and renamed it to riscv_add_subset. Besides, if the subset is added in order, 179240 then we just add it at the tail of the subset list. 179241 179242 * Removed the "-march:" prefix from the error messages. Since not only the 179243 -march= option will use the parser, but also the architecture elf attributes, 179244 the default architecture setting and linker will use the same parser. 179245 179246 * Use a function, riscv_parse_check_conflicts, to check the conflicts 179247 of extensions, including the rv64e and rv32q. 179248 179249 The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions 179250 are tested and passed. 179251 179252 bfd/ 179253 * elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list 179254 first. If the subset is added in order, then we can just add it to 179255 the tail without searching the whole list. 179256 (riscv_add_subset): Replaced by riscv_add_implicit_subset. 179257 (riscv_add_implicit_subset): Renamed to riscv_add_subset. 179258 (riscv_parse_add_subset): Updated. 179259 (riscv_parsing_subset_version): Removed the "-march:" prefix from 179260 the error message. 179261 (riscv_parse_prefixed_ext): Likewise. 179262 (riscv_parse_std_ext): Likewise. And move the rv<xlen>e check 179263 to riscv_parse_check_conflicts. 179264 (riscv_parse_check_conflicts): New function used to check conflicts. 179265 (riscv_parse_subset): Updated. 179266 gas/ 179267 * testsuite/gas/riscv/march-fail-base-02.l: Updated. 179268 * testsuite/gas/riscv/march-fail-unknown-std.l: Likewise. 179269 1792702021-07-20 GDB Administrator <gdbadmin@sourceware.org> 179271 179272 Automatic date update in version.in 179273 1792742021-07-19 Simon Marchi <simon.marchi@polymtl.ca> 179275 179276 gdb: set current thread in btrace_compute_ftrace_{bts,pt} 179277 As documented in bug 28086, test gdb.btrace/enable-new-thread.exp 179278 started failing with commit 0618ae414979 ("gdb: optimize 179279 all_matching_threads_iterator"): 179280 179281 (gdb) record btrace^M 179282 (gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace 179283 break 24^M 179284 Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M 179285 (gdb) continue^M 179286 Continuing.^M 179287 /home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M 179288 A problem internal to GDB has been detected,^M 179289 further debugging may prove unreliable.^M 179290 Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error) 179291 179292 Note that I only see the failure if GDB is compiled without libipt 179293 support. This is because GDB then makes use BTS instead of PT, so 179294 exercises different code paths. 179295 179296 I think that the commit above just exposed an existing problem. The 179297 stack trace of the internal error is: 179298 179299 #8 0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55 179300 #9 0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303 179301 #10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317 179302 #11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487 179303 #12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125 179304 #13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42 179305 #14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243 179306 #15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411 179307 #16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437 179308 #17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504 179309 #18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635 179310 #19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664 179311 #20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721 179312 #21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974 179313 #22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014 179314 #23 0x0000561cb7ef809f in target_read_code (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869 179315 #24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139 179316 #25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194 179317 #26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628 179318 #27 0x0000561cb80adbd8 in print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587 179319 #28 0x0000561cb80abe4f in print_insn_i386 (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894 179320 #29 0x0000561cb7744a19 in default_print_insn (memaddr=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029 179321 #30 0x0000561cb7b33067 in i386_print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013 179322 #31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478 179323 #32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795 179324 #33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850 179325 #34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859 179326 #35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107 179327 #36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527 179328 #37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560 179329 #38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589 179330 #39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629 179331 #40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294 179332 #41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60 179333 #42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153 179334 #43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291 179335 #44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622 179336 #45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150 179337 #46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263 179338 #47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272 179339 #48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380 179340 #49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429 179341 #50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447 179342 #51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981 179343 #52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920 179344 #53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202 179345 #54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440 179346 #55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412 179347 #56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547 179348 #57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608 179349 #58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640 179350 #59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701 179351 #60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720 179352 #61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069 179353 #62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41 179354 #63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227 179355 #64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575 179356 #65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701 179357 #66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212 179358 #67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421 179359 #68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481 179360 #69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353 179361 #70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368 179362 #71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32 179363 179364 At frame 45, the new_thread observable is fired. At this moment, the 179365 new thread isn't the current thread, inferior_ptid is null_ptid. I 179366 think this is ok: the new_thread observable doesn't give any guarantee 179367 on the global context when observers are invoked. Frame 35, 179368 btrace_compute_ftrace_bts, calls gdb_insn_length. gdb_insn_length 179369 doesn't have a thread_info or other parameter what could indicate where 179370 to read memory from, it implicitly uses the global context 179371 (inferior_ptid). 179372 179373 So we reach the all_non_exited_threads_range in 179374 record_btrace_target::record_is_replaying with a null inferior_ptid. 179375 The previous implemention of all_non_exited_threads_range didn't care, 179376 but the new one does. The problem of calling gdb_insn_length and 179377 ultimately trying to read memory with a null inferior_ptid already 179378 existed, but the commit mentioned above made it visible. 179379 179380 Something between frames 40 (record_btrace_enable_warn) and 35 179381 (btrace_compute_ftrace_bts) needs to be switching the global context to 179382 make TP the current thread. Since btrace_compute_ftrace_bts takes the 179383 thread_info to work with as a parameter, that typically means that it 179384 doesn't require its caller to also set the global current context 179385 (current thread) when calling. If it needs to call other functions 179386 that do require the global current thread to be set, then it needs to 179387 temporarily change the current thread while calling these other 179388 functions. Therefore, switch and restore the current thread in 179389 btrace_compute_ftrace_bts. 179390 179391 By inspection, it looks like btrace_compute_ftrace_pt may also call 179392 functions sensitive to the global context: it installs the 179393 btrace_pt_readmem_callback callback in the PT instruction decoder. When 179394 this function gets called, inferior_ptid must be set appropriately. Add 179395 a switch and restore in there too. 179396 179397 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28086 179398 Change-Id: I407fbfe41aab990068bd102491aa3709b0a034b3 179399 1794002021-07-19 GDB Administrator <gdbadmin@sourceware.org> 179401 179402 Automatic date update in version.in 179403 1794042021-07-18 Nick Clifton <nickc@redhat.com> 179405 179406 Move pending-obsolesence targets onto the obsolete list. 179407 * config.bfd: Move pending obsoletion targets to obsolete list. 179408 179409 Update how-to-make-a-release checklist with latest changes from 2.37 release 179410 1794112021-07-18 Michael Krasnyk <mkrasnyk@argo.ai> 179412 179413 PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting 179414 PR gold/28098 179415 * reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries 179416 with r_sym of zero without counting in advance method. 179417 1794182021-07-18 Simon Marchi <simon.marchi@polymtl.ca> 179419 179420 gdb: convert nat/x86-dregs.c macros to functions 179421 I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because 179422 x86_dr_low.get_status is nullptr. It would have been useful to be able 179423 to break on x86_dr_low_get_status, so I thought it would be a good 179424 reason to convert these function-like macros into functions. 179425 179426 Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721 179427 1794282021-07-18 GDB Administrator <gdbadmin@sourceware.org> 179429 179430 Automatic date update in version.in 179431 1794322021-07-17 Tom Tromey <tom@tromey.com> 179433 179434 Fix file-name handling regression with DWARF index 179435 When run with the gdb-index or debug-names target boards, dup-psym.exp 179436 fails. This came up for me because my new DWARF scanner reuses this 179437 part of the existing index code, and so it registers as a regression. 179438 This is PR symtab/25834. 179439 179440 Looking into this, I found that the DWARF index code here is fairly 179441 different from the psymtab code. I don't think there's a deep reason 179442 for this, and in fact, it seemed to me that the index code could 179443 simply mimic what the psymtab code already does. 179444 179445 That is what this patch implements. The DW_AT_name and DW_AT_comp_dir 179446 are now stored in the quick file names table. This may require 179447 allocating a quick file names table even when DW_AT_stmt_list does not 179448 exist. Then, the functions that work with this data are changed to 179449 use find_source_or_rewrite, just as the psymbol code does. Finally, 179450 line_header::file_full_name is removed, as it is no longer needed. 179451 179452 Currently, the index maintains a hash table of "quick file names". 179453 The hash table uses a deletion function to free the "real name" 179454 components when necessary. There's also a second such function to 179455 implement the forget_cached_source_info method. 179456 179457 This bug fix patch will create a quick file name object even when 179458 there is no DW_AT_stmt_list, meaning that the object won't be entered 179459 in the hash table. So, this patch changes the memory management 179460 approach so that the entries are cleared when the per-BFD object is 179461 destroyed. (A dwarf2_per_cu_data destructor is not introduced, 179462 because we have been avoiding adding a vtable to that class.) 179463 179464 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834 179465 1794662021-07-17 Tom Tromey <tom@tromey.com> 179467 179468 Check for debug-types in map_symbol_filenames 179469 map_symbol_filenames can skip type units -- in fact I think it has to, 179470 due to the assertion at the top of dw2_get_file_names. This may be a 179471 regression due to the TU/CU unification patch, I did not check. 179472 179473 Simplify DWARF file name caching 179474 The DWARF index file name caching code only records when a line table 179475 has been read and the reading failed. However, the code would be 179476 simpler if it recorded any attempt, which is what this patch 179477 implements. 179478 179479 Introduce find_source_or_rewrite 179480 The final bug fix in this series would duplicate the logic in 179481 psymtab_to_fullname, so this patch extracts the body of this function 179482 into a new function. 179483 179484 Simplify file_and_directory storage management 179485 file_and_directory carries a std::string in case the compilation 179486 directory is computed, but a subsequent patch wants to preserve this 179487 string without also having to maintain the storage for it. So, this 179488 patch arranges for the compilation directory string to be stored in 179489 the per-BFD string bcache instead. 179490 179491 Pass file_and_directory through DWARF line-decoding code 179492 This patch removes the redundant "comp_unit" parameter from 179493 compute_include_file_name, and arranges to pass a file_and_directory 179494 object from the readers down to this function. It also changes the 179495 partial symtab reader to use find_file_and_directory, rather than 179496 reimplement this functionality by hand. 179497 179498 Rename and refactor psymtab_include_file_name 179499 In order to fix an index-related regression, I want to use 179500 psymtab_include_file_name in the DWARF index file-handling code. This 179501 patch renames this function and changes it to no longer require a 179502 partial symtab to be passed in. A subsequent patch will further 179503 refactor this code to remove the redundant parameter (which was always 179504 there but is now more obvious). 179505 1795062021-07-17 Sergey Belyashov <Sergey.Belyashov@gmail.com> 179507 179508 Add basic Z80 CPU support 179509 Supported ISAs: 179510 - Z80 (all undocumented instructions) 179511 - Z180 179512 - eZ80 (Z80 mode only) 179513 179514 Datasheets: 179515 Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf 179516 Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf 179517 eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt 179518 179519 To debug Z80 programs using GDB you must configure and embed 179520 z80-stub.c to your program (SDCC compiler is required). Or 179521 you may use some simulator with GDB support. 179522 179523 gdb/ChangeLog: 179524 179525 * Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c. 179526 * NEWS: Mention z80 support. 179527 * configure.tgt: Handle z80*. 179528 * features/Makefile (XMLTOC): Add z80.xml. 179529 * features/z80-cpu.xml: New. 179530 * features/z80.c: Generate. 179531 * features/z80.xml: New. 179532 * z80-tdep.c: New file. 179533 * z80-tdep.h: New file. 179534 179535 gdb/stubs/ChangeLog: 179536 179537 * z80-stub.c: New file. 179538 179539 Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9 179540 1795412021-07-17 Simon Marchi <simon.marchi@polymtl.ca> 179542 179543 gdb: make all_inferiors_safe actually work 179544 The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78 179545 ("gdb: make inferior_list use intrusive_list"): 179546 179547 FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left 179548 179549 Looking at the log, we see that we are left with a bunch of inferiors in 179550 the detach-on-fork=off case: 179551 179552 info inferiors^M 179553 Num Description Connection Executable ^M 179554 * 1 <null> <snip>/fork-plus-threads ^M 179555 2 <null> <snip>/fork-plus-threads ^M 179556 3 <null> <snip>/fork-plus-threads ^M 179557 4 <null> <snip>/fork-plus-threads ^M 179558 5 <null> <snip>/fork-plus-threads ^M 179559 6 <null> <snip>/fork-plus-threads ^M 179560 7 <null> <snip>/fork-plus-threads ^M 179561 8 <null> <snip>/fork-plus-threads ^M 179562 9 <null> <snip>/fork-plus-threads ^M 179563 10 <null> <snip>/fork-plus-threads ^M 179564 11 <null> <snip>/fork-plus-threads ^M 179565 (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left 179566 179567 when we expect to have just one. The problem is prune_inferiors not 179568 pruning inferiors. And this is caused by all_inferiors_safe not 179569 actually iterating on inferiors. The current implementation: 179570 179571 inline all_inferiors_safe_range 179572 all_inferiors_safe () 179573 { 179574 return {}; 179575 } 179576 179577 default-constructs an all_inferiors_safe_range, which default-constructs 179578 an all_inferiors_safe_iterator as its m_begin field, which 179579 default-constructs a all_inferiors_iterator. A default-constructed 179580 all_inferiors_iterator is an end iterator, which means we have 179581 constructed an (end,end) all_inferiors_safe_range. 179582 179583 We actually need to pass down the list on which we want to iterator 179584 (that is the inferior_list global), so that all_inferiors_iterator's 179585 first constructor is chosen. We also pass nullptr as the proc_target 179586 filter. In this case, we don't do any filtering, but if in the future 179587 all_inferiors_safe needed to allow filtering on process target (like 179588 all_inferiors does), we could pass down a process target pointer. 179589 179590 basic_safe_iterator's constructor needs to be changed to allow 179591 constructing the wrapped iterator with multiple arguments, not just one. 179592 179593 With this, gdb.threads/fork-plus-threads.exp is passing once again for 179594 me. 179595 179596 Change-Id: I650552ede596e3590c4b7606ce403690a0278a01 179597 1795982021-07-17 GDB Administrator <gdbadmin@sourceware.org> 179599 179600 Automatic date update in version.in 179601 1796022021-07-16 Lancelot SIX <lsix@lancelotsix.com> 179603 179604 gdb: Support stepping out from signal handler on riscv*-linux 179605 Currently, gdb cannot step outside of a signal handler on RISC-V 179606 platforms. This causes multiple failures in gdb.base/sigstep.exp: 179607 179608 FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout) 179609 FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout) 179610 FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout) 179611 FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout) 179612 FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline 179613 FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline 179614 179615 === gdb Summary === 179616 179617 # of expected passes 587 179618 # of unexpected failures 6 179619 179620 This patch adds support for stepping outside of a signal handler on 179621 riscv*-*-linux*. 179622 179623 Implementation is heavily inspired from mips_linux_syscall_next_pc and 179624 surroundings as advised by Pedro Alves. 179625 179626 After this patch, all tests in gdb.base/sigstep.exp pass. 179627 179628 Build and tested on riscv64-linux-gnu. 179629 1796302021-07-16 Lancelot SIX <lsix@lancelotsix.com> 179631 179632 gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_step 179633 Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on 179634 riscv64-linux-gnu. Those tests check that when stepping, if the 179635 debuggee received a signal it should step inside the signal handler. 179636 179637 This feature requires hardware support for single stepping (or at least 179638 kernel support), but none are available on riscv*-linux-gnu hosts, at 179639 the moment at least. 179640 179641 This patch adds RISC-V to the list of configurations that does not 179642 have hardware single step capability, disabling tests relying on such 179643 feature. 179644 179645 Tested on riscv64-linux-gnu. 179646 1796472021-07-16 Tom Tromey <tom@tromey.com> 179648 179649 Document quick_symbol_functions::expand_symtabs_matching invariant 179650 While working on my series to replace the DWARF psymbol reader, I 179651 noticed that the expand_symtabs_matching has an undocumented 179652 invariant. I think that, if this invariant is not followed, then GDB 179653 will crash. So, this patch documents this in the relevant spots and 179654 introduces some asserts to make it clear. 179655 179656 Regression tested on x86-64 Fedora 32. 179657 1796582021-07-16 Tom Tromey <tromey@adacore.com> 179659 179660 Fix array stride bug 179661 Investigation of using the Python API with an Ada program showed that 179662 an array of dynamic types was not being handled properly. I tracked 179663 this down to an oddity of how array strides are handled. 179664 179665 In gdb, an array stride can be attached to the range type, via the 179666 range_bounds object. However, the stride can also be put into the 179667 array's first field. From create_range_type_with_stride: 179668 179669 else if (bit_stride > 0) 179670 TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride; 179671 179672 It's hard to be sure why this is done, but I would guess a combination 179673 of historical reasons plus a desire (mentioned in a comment somewhere) 179674 to avoid modifying the range type. 179675 179676 This patch fixes the problem by changing type::bit_stride to 179677 understand this convention. It also fixes one spot that reproduces 179678 this logic. 179679 179680 Regression tested on x86-64 Fedora 32. 179681 1796822021-07-16 Giulio Benetti <giulio.benetti@benettiengineering.com> 179683 179684 or1k: fix pc-relative relocation against dynamic on PC relative 26 bit relocation. 179685 bfd * elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry 179686 in switch case R_OR1K_INSN_REL_26 where we need to check for 179687 !SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL(). 179688 1796892021-07-16 Nick Clifton <nickc@redhat.com> 179690 179691 Updated Swedish translation for the binutils sub-directory 179692 1796932021-07-16 GDB Administrator <gdbadmin@sourceware.org> 179694 179695 Automatic date update in version.in 179696 1796972021-07-15 Tom Tromey <tromey@adacore.com> 179698 179699 Avoid expression parsing crash with unknown language 179700 PR gdb/28093 points out that gdb crashes when language is set to 179701 "unknown" and expression parsing is attempted. At first I thought 179702 this was a regression due to the expression rewrite, but it turns out 179703 that older versions crash as well. 179704 179705 This patch avoids the crash by changing the default expression parser 179706 to throw an exception. I think this is preferable -- the current 179707 behavior of silently doing nothing does not really make sense. 179708 179709 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093 179710 1797112021-07-15 Simon Marchi <simon.marchi@polymtl.ca> 179712 179713 gdb: pass child_ptid and fork kind to target_ops::follow_fork 179714 This is a small cleanup I think would be nice, that I spotted while 179715 doing the following patch. 179716 179717 gdb/ChangeLog: 179718 179719 * target.h (struct target_ops) <follow_fork>: Add ptid and 179720 target_waitkind parameters. 179721 (target_follow_fork): Likewise. 179722 * target.c (default_follow_fork): Likewise. 179723 (target_follow_fork): Likewise. 179724 * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. 179725 * fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise. 179726 * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. 179727 * linux-nat.c (linux_nat_target::follow_fork): Likewise. 179728 * obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise. 179729 * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. 179730 * remote.c (class remote_target) <follow_fork>: Likewise. 179731 * target-debug.h (target_debug_print_target_waitkind): New. 179732 * target-delegates.c: Re-generate. 179733 179734 Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8 179735 1797362021-07-15 Simon Marchi <simon.marchi@polymtl.ca> 179737 179738 gdb: call post_create_inferior at end of follow_fork_inferior 179739 GDB doesn't handle well the case of an inferior using the JIT interface 179740 to register JIT-ed objfiles and forking. If an inferior registers a 179741 code object using the JIT interface and then forks, the child process 179742 conceptually has the same code object loaded, so GDB should look it up 179743 and learn about it (it currently doesn't). 179744 179745 To achieve this, I think it would make sense to have the 179746 inferior_created observable called when an inferior is created due to a 179747 fork in follow_fork_inferior. The inferior_created observable is 179748 currently called both after starting a new inferior and after attaching 179749 to an inferior, allowing various sub-components to learn about that new 179750 executing inferior. We can see handling a fork child just like 179751 attaching to it, so any work done when attaching should also be done in 179752 the case of a fork child. 179753 179754 Instead of just calling the inferior_created observable, this patch 179755 makes follow_fork_inferior call the whole post_create_inferior function. 179756 This way, the attach and follow-fork code code paths are more alike. 179757 179758 Given that post_create_inferior calls solib_create_inferior_hook, 179759 follow_fork_inferior doesn't need to do it itself, so those calls to 179760 solib_create_inferior_hook are removed. 179761 179762 One question you may have: why not just call post_create_inferior at the 179763 places where solib_create_inferior_hook is currently called, instead of 179764 after target_follow_fork? 179765 179766 - there's something fishy for the second solib_create_inferior_hook 179767 call site: at this point we have switched the current program space 179768 to the child's, but not the current inferior nor the current thread. 179769 So solib_create_inferior_hook (and everything under, including 179770 check_for_thread_db, for example) is called with inferior 1 as the 179771 current inferior and inferior 2's program space as the current 179772 program space. I think that's wrong, because at this point we are 179773 setting up inferior 2, and all that code relies on the current 179774 inferior. We could just add a switch_to_thread call before it to 179775 make inferior 2 the current one, but there are other problems (see 179776 below). 179777 179778 - solib_create_inferior_hook is currently not called on the 179779 `follow_child && detach_fork` path. I think we need to call it, 179780 because we still get a new inferior in that case (even though we 179781 detach the parent). If we only call post_create_inferior where 179782 solib_create_inferior_hook used to be called, then the JIT 179783 subcomponent doesn't get informed about the new inferior, and that 179784 introduces a failure in the new gdb.base/jit-elf-fork.exp test. 179785 179786 - if we try to put the post_create_inferior just after the 179787 switch_to_thread that was originally at line 662, or just before the 179788 call to target_follow_fork, we introduce a subtle failure in 179789 gdb.threads/fork-thread-pending.exp. What happens then is that 179790 libthread_db gets loaded (somewhere under post_create_inferior) 179791 before the linux-nat target learns about the LWPs (which happens in 179792 linux_nat_target::follow_fork). As a result, the ALL_LWPS loop in 179793 try_thread_db_load_1 doesn't see the child LWP, and the thread-db 179794 target doesn't have the chance to fill in thread_info::priv. A bit 179795 later, when the test does "info threads", and 179796 thread_db_target::pid_to_str is called, the thread-db target doesn't 179797 recognize the thread as one of its own, and delegates the request to 179798 the target below. Because the pid_to_str output is not the expected 179799 one, the test fails. 179800 179801 This tells me that we need to call the process target's follow_fork 179802 first, to make the process target create the necessary LWP and thread 179803 structures. Then, we can call post_create_inferior to let the other 179804 components of GDB do their thing. 179805 179806 But then you may ask: check_for_thread_db is already called today, 179807 somewhere under solib_create_inferior_hook, and that is before 179808 target_follow_fork, why don't we see this ordering problem!? Well, 179809 because of the first bullet point: when check_for_thread_db / 179810 thread_db_load are called, the current inferior is (erroneously) 179811 inferior 1, the parent. Because libthread_db is already loaded for 179812 the parent, thread_db_load early returns. check_for_thread_db later 179813 gets called by linux_nat_target::follow_fork. At this point, the 179814 current inferior is the correct one and the child's LWP exists, so 179815 all is well. 179816 179817 Since we now call post_create_inferior after target_follow_fork, which 179818 calls the inferior_created observable, which calls check_for_thread_db, 179819 I don't think linux_nat_target needs to explicitly call 179820 check_for_thread_db itself, so that is removed. 179821 179822 In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp 179823 test. It makes an inferior register a JIT code object and then fork. 179824 It then verifies that whatever the detach-on-fork and follow-fork-child 179825 parameters are, GDB knows about the JIT code object in all the inferiors 179826 that survive the fork. It verifies that the inferiors can unload that 179827 code object. 179828 179829 There isn't currently a way to get visibility into GDB's idea of the JIT 179830 code objects for each inferior. For the purpose of this test, add the 179831 "maintenance info jit" command. There isn't much we can print about the 179832 JIT code objects except their load address. So the output looks a bit 179833 bare, but it's good enough for the test. 179834 179835 gdb/ChangeLog: 179836 179837 * NEWS: Mention "maint info jit" command. 179838 * infrun.c (follow_fork_inferior): Don't call 179839 solib_create_inferior_hook, call post_create_inferior if a new 179840 inferior was created. 179841 * jit.c (maint_info_jit_cmd): New. 179842 (_initialize_jit): Register new command. 179843 * linux-nat.c (linux_nat_target::follow_fork): Don't call 179844 check_for_thread_db. 179845 * linux-nat.h (check_for_thread_db): Remove declaration. 179846 * linux-thread-db.c (check_thread_signals): Make static. 179847 179848 gdb/doc/ChangeLog: 179849 179850 * gdb.texinfo (Maintenance Commands): Mention "maint info jit". 179851 179852 gdb/testsuite/ChangeLog: 179853 179854 * gdb.base/jit-elf-fork-main.c: New test. 179855 * gdb.base/jit-elf-fork-solib.c: New test. 179856 * gdb.base/jit-elf-fork.exp: New test. 179857 179858 Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c 179859 1798602021-07-15 Libor Bukata <libor.bukata@oracle.com> 179861 179862 [gdb/procfs.c] Fix build failure in find_stop_signal 179863 It fixes a regression caused by commit 179864 1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was 179865 made private. 179866 179867 The public thread_info API has to be used to get stop signal and avoid 179868 build failures. 179869 179870 gdb/ChangeLog: 179871 179872 2021-07-14 Libor Bukata <libor.bukata@oracle.com> 179873 179874 * gdb/procfs.c (find_stop_signal): Use thread_info API. 179875 179876 Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904 179877 1798782021-07-15 GDB Administrator <gdbadmin@sourceware.org> 179879 179880 Automatic date update in version.in 179881 1798822021-07-14 H.J. Lu <hjl.tools@gmail.com> 179883 179884 x86: Add int1 as one byte opcode 0xf1 179885 Also change the x86 disassembler to disassemble 0xf1 as int1, instead of 179886 icebp. 179887 179888 gas/ 179889 179890 PR gas/28088 179891 * testsuite/gas/i386/opcode.s: Add int1. 179892 * testsuite/gas/i386/x86-64-opcode.s: Add int1, int3 and int. 179893 * testsuite/gas/i386/opcode-intel.d: Updated. 179894 * testsuite/gas/i386/opcode-suffix.d: Likewise. 179895 * testsuite/gas/i386/opcode.d: Likewise. 179896 * testsuite/gas/i386/x86-64-opcode.d: Likewise. 179897 179898 opcodes/ 179899 179900 PR gas/28088 179901 * i386-dis.c (dis386): Replace icebp with int1. 179902 * i386-opc.tbl: Add int1. 179903 * i386-tbl.h: Regenerate. 179904 1799052021-07-14 Alan Modra <amodra@gmail.com> 179906 179907 gas: default TC_VALIDATE_FIX_SUB to 0 179908 gas/write.c provides a fallback TC_VALIDATE_FIX_SUB define that can be 179909 a problem for some targets, the problem being that a non-zero 179910 definition of TC_VALIDATE_FIX_SUB says that some uses of fx_subsy are 179911 OK, in effect that the target will handle fx_subsy in md_apply_fix 179912 and/or tc_gen_reloc. A lot of targets don't have the necessary 179913 md_apply_fix and tc_gen_reloc support. So a safer default is to 179914 disallow fx_subsy by default. 179915 179916 I've had a good look over target usage of fx_subsy, and think I've 179917 caught all the cases where targets need TC_VALIDATE_FIX_SUB. Possible 179918 failures would be limited to alpha, microblaze, ppc and s390 (the 179919 targets that define UNDEFINED_DIFFERENCE_OK), or targets that generate 179920 fixups with BFD_RELOC_GPREL32/16 and use a syntax explicitly showing 179921 a difference expression. 179922 179923 * write.c (TC_VALIDATE_FIX_SUB): Default to 0. 179924 * config/tc-hppa.h (TC_VALIDATE_FIX_SUB): Define. 179925 * config/tc-microblaze.h (TC_VALIDATE_FIX_SUB): Define. 179926 * config/tc-alpha.h (TC_VALIDATE_FIX_SUB): Define for ECOFF. 179927 * config/tc-ppc.h (TC_VALIDATE_FIX_SUB): Don't define for ELF. 179928 Do define for XCOFF. 179929 1799302021-07-14 Clément Chigot <clement.chigot@atos.net> 179931 179932 objdump: add DWARF support for AIX 179933 DWARF sections have special names on AIX which need be handled 179934 by objdump in order to correctly print them. 179935 This patch also adds the correlation in bfd for future uses. 179936 179937 bfd/ 179938 * libxcoff.h (struct xcoff_dwsect_name): Add DWARF name. 179939 * coff-rs6000.c (xcoff_dwsect_names): Update. 179940 * coffcode.h (sec_to_styp_flags): Likewise. 179941 (coff_new_section_hook): Likewise. 179942 binutils/ 179943 * dwarf.h (struct dwarf_section): Add XCOFF name. 179944 * dwarf.c (struct dwarf_section_display): Update. 179945 * objdump.c (load_debug_section): Add XCOFF name handler. 179946 (dump_dwarf_section): Likewise. 179947 gas/ 179948 * config/tc-ppc.c (ppc_change_debug_section): Update to 179949 match new name's field. 179950 1799512021-07-14 Tom de Vries <tdevries@suse.de> 179952 179953 [gdb/testsuite] Fix gdb.base/gold-gdb-index.exp 179954 When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed, 179955 I run into: 179956 ... 179957 FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs 179958 ... 179959 179960 This is due to a dummy .gdb_index: 179961 ... 179962 Contents of the .gdb_index section: 179963 179964 Version 7 179965 179966 CU table: 179967 179968 TU table: 179969 179970 Address table: 179971 179972 Symbol table: 179973 ... 179974 179975 The dummy .gdb_index is ignored when loading the symbols, and instead partial 179976 symbols are used. Consequently, we get the same result as if we'd removed 179977 -Wl,--gdb-index from the compilation. 179978 179979 Presumably, gold fails to generate a proper .gdb_index because it lacks 179980 DWARF5 support. 179981 179982 Anyway, without a proper .gdb_index we can't test the gdb behaviour we're 179983 trying to excercise. Fix this by detecting whether we actually used a 179984 .gdb_index for symbol loading. 179985 179986 Tested on x86_64-linux. 179987 179988 gdb/testsuite/ChangeLog: 179989 179990 2021-07-14 Tom de Vries <tdevries@suse.de> 179991 179992 * lib/gdb.exp (have_index): New proc. 179993 * gdb.base/gold-gdb-index.exp: Use have_index. 179994 1799952021-07-14 Tom de Vries <tdevries@suse.de> 179996 179997 [gdb/testsuite] Add missing skip_tui_tests 179998 When building gdb with --disable-tui, we run into: 179999 ... 180000 (gdb) frame apply all -- -^M 180001 Undefined command: "-". Try "help".^M 180002 (gdb) ERROR: Undefined command "frame apply all -- -". 180003 UNRESOLVED: gdb.base/options.exp: test-frame-apply: frame apply all -- - 180004 ... 180005 180006 Fix this by detecting whether tui is supported, and skipping the tui-related 180007 tests otherwise. Same in some gdb.tui test-cases. 180008 180009 Tested on x86_64-linux. 180010 180011 gdb/testsuite/ChangeLog: 180012 180013 2021-07-13 Tom de Vries <tdevries@suse.de> 180014 180015 * gdb.base/options.exp: Skip tui-related tests when tui is not 180016 supported. 180017 * gdb.python/tui-window-disabled.exp: Same. 180018 * gdb.python/tui-window.exp: Same. 180019 1800202021-07-14 GDB Administrator <gdbadmin@sourceware.org> 180021 180022 Automatic date update in version.in 180023 1800242021-07-13 Lancelot SIX <lsix@lancelotsix.com> 180025 180026 Use /bin/sh as shebang in gdb/make-init-c 180027 While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the 180028 following error: 180029 180030 [...] 180031 CXX aarch32-tdep.o 180032 CXX gdb.o 180033 GEN init.c 180034 /nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory 180035 make[2]: *** [Makefile:1866: stamp-init] Error 126 180036 make[2]: *** Waiting for unfinished jobs.... 180037 make[2]: Leaving directory '/build/gdb-11.0.90/gdb' 180038 make[1]: *** [Makefile:9814: all-gdb] Error 2 180039 make[1]: Leaving directory '/build/gdb-11.0.90' 180040 make: *** [Makefile:903: all] Error 2 180041 builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2 180042 error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed 180043 180044 In the nix build environment, /usr/bin/env is not present, only /bin/sh 180045 is. This patch makes sure that gdb/make-init-c uses '/bin/sh' as 180046 interpreter as this is the only one available on this platform. 180047 180048 I do not think this change will cause regressions on any other 180049 configuration. 180050 180051 [1] https://nixos.org/ 180052 180053 gdb/Changelog 180054 180055 * make-init-c: Use /bin/sh as shebang. 180056 1800572021-07-13 John Baldwin <jhb@FreeBSD.org> 180058 180059 arm-fbsd-nat: Use fetch_register_set and store_register_set. 180060 180061 aarch64-fbsd-nat: Use fetch_register_set and store_register_set. 180062 180063 riscv-fbsd-nat: Use fetch_register_set and store_register_set. 180064 180065 fbsd-nat: Add helper functions to fetch and store register sets. 180066 In particular, this supports register sets described by a regcache_map 180067 which are fetched and stored with dedicated ptrace operations. These 180068 functions are intended to be used in architecture-specific 180069 fetch_registers and store_registers target methods. 180070 180071 Add regcache_map_supplies helper routine. 180072 This helper can be used in the fetch_registers and store_registers 180073 target methods to determine if a register set includes a specific 180074 register. 180075 1800762021-07-13 Pedro Alves <pedro@palves.net> 180077 180078 Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080) 180079 Before PR gdb/28080 was fixed by the previous patch, GDB was crashing 180080 like this: 180081 180082 (gdb) detach 180083 Detaching from program: target:/any/program, process 3671843 180084 Detaching from process 3671843 180085 Ending remote debugging. 180086 [Inferior 1 (process 3671843) detached] 180087 In main 180088 terminate called after throwing an instance of 'gdb_exception_error' 180089 Aborted (core dumped) 180090 180091 Here's the exception above being thrown: 180092 180093 (top-gdb) bt 180094 #0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222 180095 #1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440 180096 #2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928 180097 #3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030 180098 #4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137 180099 #5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455 180100 #6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb] 180101 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462 180102 #7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365 180103 #8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439 180104 #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599 180105 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847 180106 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814 180107 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626 180108 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715 180109 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573 180110 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377 180111 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155 180112 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730 180113 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169 180114 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103 180115 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153 180116 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497 180117 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921 180118 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158 180119 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210 180120 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487 180121 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875 180122 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236 180123 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769 180124 180125 Note frame #14: 180126 180127 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573 180128 180129 That's a dtor, thus noexcept. That's the reason for the 180130 std::terminate. 180131 180132 The previous patch fixed things such that the exception above isn't 180133 thrown anymore. However, it's possible that e.g., the remote 180134 connection drops just while a user types "nosharedlibrary", or some 180135 other reason that leads to objfile::~objfile, and then we end up the 180136 same std::terminate problem. 180137 180138 Also notice that frames #9-#11 are BFD frames: 180139 180140 #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599 180141 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847 180142 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814 180143 180144 BFD is written in C and thus throwing exceptions over such frames may 180145 either not clean up properly, or, may abort if bfd is not compiled 180146 with -fasynchronous-unwind-tables (x86-64 defaults that on, but not 180147 all GCC ports do). 180148 180149 Thus frame #8 seems like a good place to swallow exceptions. More so 180150 since in this spot we already ignore target_fileio_close return 180151 errors. That's what this commit does. Without the previous fix, we'd 180152 see: 180153 180154 (gdb) detach 180155 Detaching from program: target:/any/program, process 2197701 180156 Ending remote debugging. 180157 [Inferior 1 (process 2197701) detached] 180158 warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed 180159 180160 Note it prints a warning, which would still be a regression compared 180161 to GDB 10, if it weren't for the previous fix. 180162 180163 gdb/ChangeLog: 180164 yyyy-mm-dd Pedro Alves <pedro@palves.net> 180165 180166 PR gdb/28080 180167 * gdb_bfd.c (gdb_bfd_close_warning): New. 180168 (gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in 180169 try/catch and print warning on exception. 180170 (gdb_bfd_close_or_warn): Use gdb_bfd_close_warning. 180171 180172 Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7 180173 1801742021-07-13 Pedro Alves <pedro@palves.net> 180175 180176 Fix detach with target remote (PR gdb/28080) 180177 Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop 180178 with threads running") regressed "detach" with "target remote": 180179 180180 (gdb) detach 180181 Detaching from program: target:/any/program, process 3671843 180182 Detaching from process 3671843 180183 Ending remote debugging. 180184 [Inferior 1 (process 3671843) detached] 180185 In main 180186 terminate called after throwing an instance of 'gdb_exception_error' 180187 Aborted (core dumped) 180188 180189 Here's the exception above being thrown: 180190 180191 (top-gdb) bt 180192 #0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222 180193 #1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440 180194 #2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928 180195 #3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030 180196 #4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137 180197 #5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455 180198 #6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb] 180199 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462 180200 #7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365 180201 #8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439 180202 #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599 180203 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847 180204 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814 180205 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626 180206 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715 180207 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573 180208 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377 180209 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155 180210 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730 180211 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169 180212 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103 180213 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153 180214 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497 180215 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921 180216 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158 180217 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210 180218 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487 180219 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875 180220 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236 180221 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769 180222 180223 So frame #28 already detached the remote process, and then we're 180224 purging the shared libraries. GDB had opened remote shared libraries 180225 via the target: sysroot, so it tries closing them. GDBserver is 180226 tearing down already, so remote communication breaks down and we close 180227 the remote target and throw TARGET_CLOSE_ERROR. 180228 180229 Note frame #14: 180230 180231 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573 180232 180233 That's a dtor, thus noexcept. That's the reason for the 180234 std::terminate. 180235 180236 Stepping back a bit, why do we still have open remote files if we've 180237 managed to detach already, and, we're debugging with "target remote"? 180238 The reason is that commit 408f66864a1a823591b26420410c982174c239a2 180239 makes detach_command hold a reference to the target, so the remote 180240 target won't be finally closed until frame #28 returns. It's closing 180241 the target that invalidates target file I/O handles. 180242 180243 This commit fixes the issue by not relying on target_close to 180244 invalidate the target file I/O handles, instead invalidate them 180245 immediately in remote_unpush_target. So when GDB purges the solibs, 180246 and we end up in target_fileio_close (frame #7 above), there's nothing 180247 to do, and we don't try to talk with the remote target anymore. 180248 180249 The regression isn't seen when testing with 180250 --target_board=native-gdbserver, because that does "set sysroot" to 180251 disable the "target:" sysroot, for test run speed reasons. So this 180252 commit adds a testcase that explicitly tests detach with "set sysroot 180253 target:". 180254 180255 gdb/ChangeLog: 180256 yyyy-mm-dd Pedro Alves <pedro@palves.net> 180257 180258 PR gdb/28080 180259 * remote.c (remote_unpush_target): Invalidate file I/O target 180260 handles. 180261 * target.c (fileio_handles_invalidate_target): Make extern. 180262 * target.h (fileio_handles_invalidate_target): Declare. 180263 180264 gdb/testsuite/ChangeLog: 180265 yyyy-mm-dd Pedro Alves <pedro@palves.net> 180266 180267 PR gdb/28080 180268 * gdb.base/detach-sysroot-target.exp: New. 180269 * gdb.base/detach-sysroot-target.c: New. 180270 180271 Reported-By: Jonah Graham <jonah@kichwacoders.com> 180272 180273 Change-Id: I851234910172f42a1b30e731161376c344d2727d 180274 1802752021-07-13 Tom de Vries <tdevries@suse.de> 180276 180277 [gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33 180278 When running test-case gdb.threads/check-libthread-db.exp on openSUSE 180279 Tumbleweed with glibc 2.33, I get: 180280 ... 180281 (gdb) maint check libthread-db^M 180282 Running libthread_db integrity checks:^M 180283 Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M 180284 libthread_db integrity checks passed.^M 180285 (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \ 180286 libpthread.so not initialized (pattern 2) 180287 ... 180288 180289 The test-case expects instead: 180290 ... 180291 Got thread 0x0 => 9354 => 0x0 ... OK^M 180292 ... 180293 which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is 180294 described in the test-case like this: 180295 ... 180296 # libthread_db should fake a single thread with th_unique == NULL. 180297 ... 180298 180299 Using a breakpoint on check_thread_db_callback we can compare the two 180300 scenarios, and find that in the latter case we hit this code in glibc function 180301 iterate_thread_list in nptl_db/td_ta_thr_iter.c: 180302 ... 180303 if (next == 0 && fake_empty) 180304 { 180305 /* __pthread_initialize_minimal has not run. There is just the main 180306 thread to return. We cannot rely on its thread register. They 180307 sometimes contain garbage that would confuse us, left by the 180308 kernel at exec. So if it looks like initialization is incomplete, 180309 we only fake a special descriptor for the initial thread. */ 180310 td_thrhandle_t th = { ta, 0 }; 180311 return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK; 180312 } 180313 ... 180314 while in the former case we don't because this preceding statement doesn't 180315 result in next == 0: 180316 ... 180317 err = DB_GET_FIELD (next, ta, head, list_t, next, 0); 180318 ... 180319 180320 Note that the comment mentions __pthread_initialize_minimal, but in both cases 180321 it has already run before we hit the callback, so it's possible the comment is 180322 no longer accurate. 180323 180324 The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack 180325 list variables into _rtld_global", which moves the initialization of stack 180326 list variables such as __stack_user to an earlier moment, which explains well 180327 enough the observed difference. 180328 180329 Fix this by updating the regexp patterns to agree with what libthread-db is 180330 telling us. 180331 180332 Tested on x86_64-linux, both with glibc 2.33 and 2.26. 180333 180334 gdb/testsuite/ChangeLog: 180335 180336 2021-07-07 Tom de Vries <tdevries@suse.de> 180337 180338 PR testsuite/27690 180339 * gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33. 180340 1803412021-07-13 Felix Willgerodt <felix.willgerodt@intel.com> 180342 180343 gdb, dwarf: Don't follow the parent of a subprogram to get a prefix. 180344 During prefix resolution, if the parent is a subprogram, there is no need 180345 to go to the parent of the subprogram. The DIE will be local. 180346 180347 For a program like: 180348 ~~~ 180349 class F1 180350 { 180351 public: 180352 int a; 180353 int 180354 vvv () 180355 { 180356 class F2 180357 { 180358 int f; 180359 }; 180360 F2 abcd; 180361 return 1; 180362 } 180363 }; 180364 ~~~ 180365 180366 The class F2 should not be seen as a member of F1. 180367 180368 Before: 180369 ~~~ 180370 (gdb) ptype abcd 180371 type = class F1::F2 { 180372 private: 180373 int f; 180374 } 180375 ~~~ 180376 180377 After: 180378 ~~~ 180379 (gdb) ptype abcd 180380 type = class F2 { 180381 private: 180382 int f; 180383 } 180384 ~~~ 180385 180386 gdb/ChangeLog: 180387 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com> 180388 180389 * dwarf2/read.c (determine_prefix): Return an empty prefix if the 180390 parent is a subprogram. 180391 180392 gdb/testsuite/ChangeLog: 180393 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com> 180394 180395 * gdb.cp/nested-class-func-class.cc: New file. 180396 * gdb.cp/nested-class-func-class.exp: New file. 180397 1803982021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180399 180400 gdb: disable commit-resumed on -exec-interrupt --thread-group 180401 As reported in PR gdb/28077, we hit an internal error when using 180402 -exec-interrupt with --thread-group: 180403 180404 info threads 180405 &"info threads\n" 180406 ~" Id Target Id Frame \n" 180407 ~"* 1 process 403312 \"loop\" (running)\n" 180408 ^done 180409 (gdb) 180410 -exec-interrupt --thread-group i1 180411 ~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) " 180412 180413 This is because this code path never disables commit-resumed (a 180414 requirement for calling target_stop, as documented in 180415 process_stratum_target::»commit_resumed_state) before calling 180416 target_stop. 180417 180418 The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1, 180419 which does it. But the --thread-group code path uses its own thing 180420 which doesn't do it. Fix this by adding a scoped_disable_commit_resumed 180421 in this code path. 180422 180423 Calling -exec-interrupt with --thread-group is apparently not tested at 180424 the moment (which is why this bug could creep in). Add a new test for 180425 that. The test runs two inferiors and tries to interrupt them with 180426 "-exec-interrupt --thread-group X". 180427 180428 This will need to be merged in the gdb-11-branch, so here are ChangeLog 180429 entries: 180430 180431 gdb/ChangeLog: 180432 180433 * mi/mi-main.c (mi_cmd_exec_interrupt): Use 180434 scoped_disable_commit_resumed in the --thread-group case. 180435 180436 gdb/testsuite/ChangeLog: 180437 180438 * gdb.mi/interrupt-thread-group.c: New. 180439 * gdb.mi/interrupt-thread-group.exp: New. 180440 180441 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077 180442 Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb 180443 1804442021-07-13 Nelson Chu <nelson.chu@sifive.com> 180445 180446 RISC-V: Enable elf attributes when default configure option isn't set. 180447 Since gcc commit, 3c70b3ca1ef58f302bf8c16d9e7c7bb8626408bf, we now enable 180448 elf attributes for all riscv targets by default in gcc. Therefore, I 180449 think binutils should have the same behavior, in case users are writing 180450 assembly files. If --enable-default-riscv-attribute isn't set, then we 180451 enable the elf attributes for all riscv targets by default. 180452 180453 ChangLog: 180454 180455 binutils/ 180456 180457 * testsuite/binutils-all/readelf.s: Add comments for riscv. 180458 * testsuite/binutils-all/readelf.s-64: Likewise. 180459 * testsuite/binutils-all/readelf.s-64-unused: Likewise. 180460 * testsuite/binutils-all/readelf.ss: Likewise. 180461 * testsuite/binutils-all/readelf.ss-64: Likewise. 180462 * testsuite/binutils-all/readelf.ss-64-unused: Likewise. 180463 180464 gas/ 180465 180466 * configure.ac: If --enable-default-riscv-attribute isn't set, 180467 then we enable the elf attributes for all riscv targets by 180468 default. 180469 * configure: Regenerated. 180470 1804712021-07-13 John Ericson <git@JohnEricson.me> 180472 180473 Fix some dangling references to `netbsd-tdep` 180474 These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10, 180475 but evidentially a few dangling references were left behind. This causes 180476 builds to fail: 180477 180478 $ ./configure --target i686-netbsdelf 180479 $ make 180480 make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'. Stop. 180481 1804822021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180483 180484 gdb: optimize all_matching_threads_iterator 180485 all_matching_threads_iterator is used extensively in some pretty fast 180486 paths, often under the all_non_exited_threads function. 180487 180488 If a filter target and thread-specific ptid are given, it iterates on 180489 all threads of all inferiors of that target, to ultimately yield exactly 180490 on thread. And this happens quite often, which means we unnecessarily 180491 spend time iterating on threads to find the one we are looking for. The 180492 same thing happens if an inferior-specific ptid is given, although there 180493 the iterator yields all the threads of that inferior. 180494 180495 In those cases, the callers of all_non_exited_threads could have 180496 different behaviors depending on the kind of ptid, to avoid this 180497 inefficiency, but that would be very tedious. Using 180498 all_non_exited_threads has the advantage that one simple implementation 180499 can work seamlessly on multiple threads or on one specific thread, just 180500 by playing with the ptid. 180501 180502 Instead, optimize all_matching_threads_iterator directly to detect these 180503 different cases and limiting what we iterate on to just what we need. 180504 180505 - if filter_ptid is minus_one_ptid, do as we do now: filter inferiors 180506 based on filter_target, iterate on all of the matching inferiors' 180507 threads 180508 - if filter_ptid is a pid-only ptid (then a filter_target must 180509 necessarily be given), look up that inferior and iterate on all its 180510 threads 180511 - otherwise, filter_ptid is a thread-specific ptid, so look up that 180512 specific thread and "iterate" only on it 180513 180514 For the last case, what was an iteration on all threads of the filter 180515 target now becomes a call to find_thread_ptid, which is quite efficient 180516 now thanks to inferior::ptid_thread_map. 180517 180518 gdb/ChangeLog: 180519 180520 * thread-iter.h (class all_matching_threads_iterator) 180521 <all_matching_threads_iterator>: Use default. 180522 <enum class mode>: New. 180523 <m_inf, m_thr>: Initialize. 180524 <m_filter_ptid>: Remove. 180525 * thread-iter.c (all_matching_threads_iterator::m_inf_matches): 180526 Don't filter on m_filter_ptid. 180527 (all_matching_threads_iterator::all_matching_threads_iterator): 180528 Choose path based on filter_ptid (all threads, all threads of 180529 inferior, single thread). 180530 (all_matching_threads_iterator::advance): Likewise. 180531 180532 Change-Id: Ic6a19845f5f760fa1b8eac8145793c0ff431bbc9 180533 1805342021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180535 180536 gdb: maintain ptid -> thread map, optimize find_thread_ptid 180537 When debugging a large number of threads (thousands), looking up a 180538 thread by ptid_t using the inferior::thread_list linked list can add up. 180539 180540 Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and 180541 change the find_thread_ptid function to look up a thread using 180542 std::unordered_map::find, instead of iterating on all of the 180543 inferior's threads. This should make it faster to look up a thread 180544 from its ptid. 180545 180546 Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c 180547 Co-Authored-By: Pedro Alves <pedro@palves.net> 180548 1805492021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180550 180551 gdb: optimize selection of resumed thread with pending event 180552 Consider a case where many threads (thousands) keep hitting a breakpoint 180553 whose condition evaluates to false. random_pending_event_thread is 180554 responsible for selecting a thread from an inferior among all that are 180555 resumed with a pending wait status. It is currently implemented by 180556 walking the inferior's thread list twice: once to count the number of 180557 candidates and once to select a random one. 180558 180559 Since we now maintain a per target list of resumed threads with pending 180560 event, we can implement this more efficiently by walking that list and 180561 selecting the first thread that matches the criteria 180562 (random_pending_event_thread looks for an thread from a specific 180563 inferior, and possibly a filter ptid). It will be faster especially in 180564 the common case where there isn't any resumed thread with pending 180565 event. Currently, we have to iterate the thread list to figure this 180566 out. With this patch, the list of resumed threads with pending event 180567 will be empty, so it's quick to figure out. 180568 180569 The random selection is kept, but is moved to 180570 process_stratum_target::random_resumed_with_pending_wait_status. The 180571 same technique is used: do a first pass to count the number of 180572 candidates, and do a second pass to select a random one. But given that 180573 the list of resumed threads with pending wait statuses will generally be 180574 short, or at least shorter than the full thread list, it should be 180575 quicker. 180576 180577 Note that this isn't completely true, in case there are multiple 180578 inferiors on the same target. Imagine that inferior A has 10k resumed 180579 threads with pending wait statuses, and random_pending_event_thread is 180580 called with inferior B. We'll need to go through the list that contains 180581 inferior A's threads to realize that inferior B has no resumed threads 180582 with pending wait status. But I think that this is a corner / 180583 pathological case. And a possible fix for this situation would be to 180584 make random_pending_event_thread work per-process-target, rather than 180585 per-inferior. 180586 180587 Change-Id: I1b71d01beaa500a148b5b9797745103e13917325 180588 1805892021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180590 180591 gdb: optimize check for resumed threads with pending wait status in maybe_set_commit_resumed_all_targets 180592 Consider a test case where many threads (thousands) keep hitting a 180593 breakpoint whose condition evaluates to false. 180594 maybe_set_commit_resumed_all_targets is called at each handled event, 180595 when the scoped_disable_commit_resumed object in fetch_inferior_event is 180596 reset_and_commit-ed. One particularly expensive check in there is 180597 whether the target has at least one resumed thread with a pending wait 180598 status (in which case, we don't want to commit the resumed threads, as 180599 we want to consume this status first). It is currently implemented as 180600 walking all threads of the target. 180601 180602 Since we now maintain a per-target list of resumed threads with pending 180603 status, we can do this check efficiently, by checking whether that list 180604 is empty or not. 180605 180606 Add the process_stratum_target::has_resumed_with_pending_wait_status 180607 method for this, and use it in maybe_set_commit_resumed_all_targets. 180608 180609 Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6 180610 1806112021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180612 180613 gdb: maintain per-process-target list of resumed threads with pending wait status 180614 Looking up threads that are both resumed and have a pending wait 180615 status to report is something that we do quite often in the fast path 180616 and is expensive if there are many threads, since it currently requires 180617 walking whole thread lists. 180618 180619 The first instance is in maybe_set_commit_resumed_all_targets. This is 180620 called after handling each event in fetch_inferior_event, to see if we 180621 should ask targets to commit their resumed threads or not. If at least 180622 one thread is resumed but has a pending wait status, we don't ask the 180623 targets to commit their resumed threads, because we want to consume and 180624 handle the pending wait status first. 180625 180626 The second instance is in random_pending_event_thread, where we want to 180627 select a random thread among all those that are resumed and have a 180628 pending wait status. This is called every time we try to consume 180629 events, to see if there are any pending events that we we want to 180630 consume, before asking the targets for more events. 180631 180632 To allow optimizing these cases, maintain a per-process-target list of 180633 threads that are resumed and have a pending wait status. 180634 180635 In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1) 180636 if there are any such threads simply by checking whether the list is 180637 empty. 180638 180639 In random_pending_event_thread, we'll be able to use that list, which 180640 will be quicker than iterating the list of threads, especially when 180641 there are no resumed with pending wait status threads. 180642 180643 About implementation details: using the new setters on class 180644 thread_info, it's relatively easy to maintain that list. Any time the 180645 "resumed" or "pending wait status" property is changed, we check whether 180646 that should cause the thread to be added or removed from the list. 180647 180648 In set_thread_exited, we try to remove the thread from the list, because 180649 keeping an exited thread in that list would make no sense (especially if 180650 the thread is freed). My first implementation assumed that a process 180651 stratum target was always present when set_thread_exited is called. 180652 That's however, not the case: in some cases, targets unpush themselves 180653 from an inferior and then call "exit_inferior", which exits all the 180654 threads. If the target is unpushed before set_thread_exited is called 180655 on the threads, it means we could mistakenly leave some threads in the 180656 list. I tried to see how hard it would be to make it such that targets 180657 have to exit all threads before unpushing themselves from the inferior 180658 (that would seem logical to me, we don't want threads belonging to an 180659 inferior that has no process target). That seemed quite difficult and 180660 not worth the time at the moment. Instead, I changed 180661 inferior::unpush_target to remove all threads of that inferior from the 180662 list. 180663 180664 As of this patch, the list is not used, this is done in the subsequent 180665 patches. 180666 180667 The debug messages in process-stratum-target.c need to print some ptids. 180668 However, they can't use target_pid_to_str to print them without 180669 introducing a dependency on the current inferior (the current inferior 180670 is used to get the current target stack). For debug messages, I find it 180671 clearer to print the spelled out ptid anyway (the pid, lwp and tid 180672 values). Add a ptid_t::to_string method that returns a string 180673 representation of the ptid that is meant for debug messages, a bit like 180674 we already have frame_id::to_string. 180675 180676 Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67 180677 1806782021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180679 180680 gdb: make thread_info::suspend private, add getters / setters 180681 A following patch will want to take some action when a pending wait 180682 status is set on or removed from a thread. Add a getter and a setter on 180683 thread_info for the pending waitstatus, so that we can add some code in 180684 the setter later. 180685 180686 The thing is, the pending wait status field is in the 180687 thread_suspend_state, along with other fields that we need to backup 180688 before and restore after the thread does an inferior function call. 180689 Therefore, make the thread_suspend_state member private 180690 (thread_info::suspend becomes thread_info::m_suspend), and add getters / 180691 setters for all of its fields: 180692 180693 - pending wait status 180694 - stop signal 180695 - stop reason 180696 - stop pc 180697 180698 For the pending wait status, add the additional has_pending_waitstatus 180699 and clear_pending_waitstatus methods. 180700 180701 I think this makes the thread_info interface a bit nicer, because we 180702 now access the fields as: 180703 180704 thread->stop_pc () 180705 180706 rather than 180707 180708 thread->suspend.stop_pc 180709 180710 The stop_pc field being in the `suspend` structure is an implementation 180711 detail of thread_info that callers don't need to be aware of. 180712 180713 For the backup / restore of the thread_suspend_state structure, add 180714 save_suspend_to and restore_suspend_from methods. You might wonder why 180715 `save_suspend_to`, as opposed to a simple getter like 180716 180717 thread_suspend_state &suspend (); 180718 180719 I want to make it clear that this is to be used only for backing up and 180720 restoring the suspend state, _not_ to access fields like: 180721 180722 thread->suspend ()->stop_pc 180723 180724 Adding some getters / setters allows adding some assertions. I find 180725 that this helps understand how things are supposed to work. Add: 180726 180727 - When getting the pending status (pending_waitstatus method), ensure 180728 that there is a pending status. 180729 - When setting a pending status (set_pending_waitstatus method), ensure 180730 there is no pending status. 180731 180732 There is one case I found where this wasn't true - in 180733 remote_target::process_initial_stop_replies - which needed adjustments 180734 to respect that contract. I think it's because 180735 process_initial_stop_replies is kind of (ab)using the 180736 thread_info::suspend::waitstatus to store some statuses temporarily, for 180737 its internal use (statuses it doesn't intent on leaving pending). 180738 180739 process_initial_stop_replies pulls out stop replies received during the 180740 initial connection using target_wait. It always stores the received 180741 event in `evthread->suspend.waitstatus`. But it only sets 180742 waitstatus_pending_p, if it deems the event interesting enough to leave 180743 pending, to be reported to the core: 180744 180745 if (ws.kind != TARGET_WAITKIND_STOPPED 180746 || ws.value.sig != GDB_SIGNAL_0) 180747 evthread->suspend.waitstatus_pending_p = 1; 180748 180749 It later uses this flag a bit below, to choose which thread to make the 180750 "selected" one: 180751 180752 if (selected == NULL 180753 && thread->suspend.waitstatus_pending_p) 180754 selected = thread; 180755 180756 And ultimately that's used if the user-visible mode is all-stop, so that 180757 we print the stop for that interesting thread: 180758 180759 /* In all-stop, we only print the status of one thread, and leave 180760 others with their status pending. */ 180761 if (!non_stop) 180762 { 180763 thread_info *thread = selected; 180764 if (thread == NULL) 180765 thread = lowest_stopped; 180766 if (thread == NULL) 180767 thread = first; 180768 180769 print_one_stopped_thread (thread); 180770 } 180771 180772 But in any case (all-stop or non-stop), print_one_stopped_thread needs 180773 to access the waitstatus value of these threads that don't have a 180774 pending waitstatus (those that had TARGET_WAITKIND_STOPPED + 180775 GDB_SIGNAL_0). This doesn't work with the assertions I've 180776 put. 180777 180778 So, change the code to only set the thread's wait status if it is an 180779 interesting one that we are going to leave pending. If the thread 180780 stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED + 180781 GDB_SIGNAL_0), don't store it. Adjust print_one_stopped_thread to 180782 understand that if a thread has no pending waitstatus, it's because it 180783 stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0. 180784 180785 The call to set_last_target_status also uses the pending waitstatus. 180786 However, given that the pending waitstatus for the thread may have been 180787 cleared in print_one_stopped_thread (and that there might not even be a 180788 pending waitstatus in the first place, as explained above), it is no 180789 longer possible to do it at this point. To fix that, move the call to 180790 set_last_target_status in print_one_stopped_thread. I think this will 180791 preserve the existing behavior, because set_last_target_status is 180792 currently using the current thread's wait status. And the current 180793 thread is the last one for which print_one_stopped_thread is called. So 180794 by calling set_last_target_status in print_one_stopped_thread, we'll get 180795 the same result. set_last_target_status will possibly be called 180796 multiple times, but only the last call will matter. It just means 180797 possibly more calls to set_last_target_status, but those are cheap. 180798 180799 Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7 180800 1808012021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180802 180803 gdb: add setter / getter for thread_info resumed state 180804 A following patch will want to do things when a thread's resumed state 180805 changes. Make the `resumed` field private (renamed to `m_resumed`) and 180806 add a getter and a setter for it. The following patch in question will 180807 therefore be able to add some code to the setter. 180808 180809 Change-Id: I360c48cc55a036503174313261ce4e757d795319 180810 1808112021-07-13 Simon Marchi <simon.marchi@polymtl.ca> 180812 180813 gdb: use intrusive list for step-over chain 180814 The threads that need a step-over are currently linked using an 180815 hand-written intrusive doubly-linked list, so that seems a very good 180816 candidate for intrusive_list, convert it. 180817 180818 For this, we have a use case of appending a list to another one (in 180819 start_step_over). Based on the std::list and Boost APIs, add a splice 180820 method. However, only support splicing the other list at the end of the 180821 `this` list, since that's all we need. 180822 180823 Add explicit default assignment operators to 180824 reference_to_pointer_iterator, which are otherwise implicitly deleted. 180825 This is needed because to define thread_step_over_list_safe_iterator, we 180826 wrap reference_to_pointer_iterator inside a basic_safe_iterator, and 180827 basic_safe_iterator needs to be able to copy-assign the wrapped 180828 iterator. The move-assignment operator is therefore not needed, only 180829 the copy-assignment operator is. But for completeness, add both. 180830 180831 Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c 180832 1808332021-07-13 Pedro Alves <pedro@palves.net> 180834 180835 gdb: make inferior_list use intrusive_list 180836 Change inferior_list, the global list of inferiors, to use 180837 intrusive_list. I think most other changes are somewhat obvious 180838 fallouts from this change. 180839 180840 There is a small change in behavior in scoped_mock_context. Before this 180841 patch, constructing a scoped_mock_context would replace the whole 180842 inferior list with only the new mock inferior. Tests using two 180843 scoped_mock_contexts therefore needed to manually link the two inferiors 180844 together, as the second scoped_mock_context would bump the first mock 180845 inferior from the thread list. With this patch, a scoped_mock_context 180846 adds its mock inferior to the inferior list on construction, and removes 180847 it on destruction. This means that tests run with mock inferiors in the 180848 inferior list in addition to any pre-existing inferiors (there is always 180849 at least one). There is no possible pid clash problem, since each 180850 scoped mock inferior uses its own process target, and pids are per 180851 process target. 180852 180853 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 180854 Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018 180855 1808562021-07-13 Pedro Alves <pedro@palves.net> 180857 180858 gdb: introduce intrusive_list, make thread_info use it 180859 GDB currently has several objects that are put in a singly linked list, 180860 by having the object's type have a "next" pointer directly. For 180861 example, struct thread_info and struct inferior. Because these are 180862 simply-linked lists, and we don't keep track of a "tail" pointer, when 180863 we want to append a new element on the list, we need to walk the whole 180864 list to find the current tail. It would be nice to get rid of that 180865 walk. Removing elements from such lists also requires a walk, to find 180866 the "previous" position relative to the element being removed. To 180867 eliminate the need for that walk, we could make those lists 180868 doubly-linked, by adding a "prev" pointer alongside "next". It would be 180869 nice to avoid the boilerplate associated with maintaining such a list 180870 manually, though. That is what the new intrusive_list type addresses. 180871 180872 With an intrusive list, it's also possible to move items out of the 180873 list without destroying them, which is interesting in our case for 180874 example for threads, when we exit them, but can't destroy them 180875 immediately. We currently keep exited threads on the thread list, but 180876 we could change that which would simplify some things. 180877 180878 Note that with std::list, element removal is O(N). I.e., with 180879 std::list, we need to walk the list to find the iterator pointing to 180880 the position to remove. However, we could store a list iterator 180881 inside the object as soon as we put the object in the list, to address 180882 it, because std::list iterators are not invalidated when other 180883 elements are added/removed. However, if you need to put the same 180884 object in more than one list, then std::list<object> doesn't work. 180885 You need to instead use std::list<object *>, which is less efficient 180886 for requiring extra memory allocations. For an example of an object 180887 in multiple lists, see the step_over_next/step_over_prev fields in 180888 thread_info: 180889 180890 /* Step-over chain. A thread is in the step-over queue if these are 180891 non-NULL. If only a single thread is in the chain, then these 180892 fields point to self. */ 180893 struct thread_info *step_over_prev = NULL; 180894 struct thread_info *step_over_next = NULL; 180895 180896 The new intrusive_list type gives us the advantages of an intrusive 180897 linked list, while avoiding the boilerplate associated with manually 180898 maintaining it. 180899 180900 intrusive_list's API follows the standard container interface, and thus 180901 std::list's interface. It is based the API of Boost's intrusive list, 180902 here: 180903 180904 https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html 180905 180906 Our implementation is relatively simple, while Boost's is complicated 180907 and intertwined due to a lot of customization options, which our version 180908 doesn't have. 180909 180910 The easiest way to use an intrusive_list is to make the list's element 180911 type inherit from intrusive_node. This adds a prev/next pointers to 180912 the element type. However, to support putting the same object in more 180913 than one list, intrusive_list supports putting the "node" info as a 180914 field member, so you can have more than one such nodes, one per list. 180915 180916 As a first guinea pig, this patch makes the per-inferior thread list use 180917 intrusive_list using the base class method. 180918 180919 Unlike Boost's implementation, ours is not a circular list. An earlier 180920 version of the patch was circular: the intrusive_list type included an 180921 intrusive_list_node "head". In this design, a node contained pointers 180922 to the previous and next nodes, not the previous and next elements. 180923 This wasn't great for when debugging GDB with GDB, as it was difficult 180924 to get from a pointer to the node to a pointer to the element. With the 180925 design proposed in this patch, nodes contain pointers to the previous 180926 and next elements, making it easy to traverse the list by hand and 180927 inspect each element. 180928 180929 The intrusive_list object contains pointers to the first and last 180930 elements of the list. They are nullptr if the list is empty. 180931 Each element's node contains a pointer to the previous and next 180932 elements. The first element's previous pointer is nullptr and the last 180933 element's next pointer is nullptr. Therefore, if there's a single 180934 element in the list, both its previous and next pointers are nullptr. 180935 To differentiate such an element from an element that is not linked into 180936 a list, the previous and next pointers contain a special value (-1) when 180937 the node is not linked. This is necessary to be able to reliably tell 180938 if a given node is currently linked or not. 180939 180940 A begin() iterator points to the first item in the list. An end() 180941 iterator contains nullptr. This makes iteration until end naturally 180942 work, as advancing past the last element will make the iterator contain 180943 nullptr, making it equal to the end iterator. If the list is empty, 180944 a begin() iterator will contain nullptr from the start, and therefore be 180945 immediately equal to the end. 180946 180947 Iterating on an intrusive_list yields references to objects (e.g. 180948 `thread_info&`). The rest of GDB currently expects iterators and ranges 180949 to yield pointers (e.g. `thread_info*`). To bridge the gap, add the 180950 reference_to_pointer_iterator type. It is used to define 180951 inf_threads_iterator. 180952 180953 Add a Python pretty-printer, to help inspecting intrusive lists when 180954 debugging GDB with GDB. Here's an example of the output: 180955 180956 (top-gdb) p current_inferior_.m_obj.thread_list 180957 $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80} 180958 180959 It's not possible with current master, but with this patch [1] that I 180960 hope will be merged eventually, it's possible to index the list and 180961 access the pretty-printed value's children: 180962 180963 (top-gdb) p current_inferior_.m_obj.thread_list[1] 180964 $2 = (thread_info *) 0x617000069080 180965 (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid 180966 $3 = { 180967 m_pid = 406499, 180968 m_lwp = 406503, 180969 m_tid = 0 180970 } 180971 180972 Even though iterating the list in C++ yields references, the Python 180973 pretty-printer yields pointers. The reason for this is that the output 180974 of printing the thread list above would be unreadable, IMO, if each 180975 thread_info object was printed in-line, since they contain so much 180976 information. I think it's more useful to print pointers, and let the 180977 user drill down as needed. 180978 180979 [1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html 180980 180981 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> 180982 Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0 180983 1809842021-07-13 GDB Administrator <gdbadmin@sourceware.org> 180985 180986 Automatic date update in version.in 180987 1809882021-07-12 Tucker <tuckkern@sourceware@gmail.com> 180989 180990 Add the SEC_ELF_OCTETS flag to debug sections created by the assembler. 180991 PR 28054 180992 gas * config/obj-elf.c (obj_elf_change_section): Set the 180993 SEF_ELF_OCTETS flag on debug sections. 180994 1809952021-07-12 Tom de Vries <tdevries@suse.de> 180996 180997 [gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcode 180998 Recently I started to see this fail with trunk: 180999 ... 181000 (gdb) record instruction-history^M 181001 1 0x00000000004004ab <main+4>: call 0x4004b7 <test>^M 181002 2 0x00000000004004c6 <test+15>: mov $0x1,%eax^M 181003 3 0x00000000004004cb <test+20>: ret ^M 181004 (gdb) FAIL: gdb.btrace/tsx.exp: speculation indication 181005 ... 181006 181007 This is due to an intel microcode update (1) that disables Intel TSX by default. 181008 181009 Fix this by updating the pattern. 181010 181011 Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1. 181012 181013 [1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html 181014 181015 gdb/testsuite/ChangeLog: 181016 181017 2021-07-12 Tom de Vries <tdevries@suse.de> 181018 181019 PR testsuite/28057 181020 * gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in 181021 microcode. 181022 1810232021-07-12 Nick Clifton <nickc@redhat.com> 181024 181025 Updated French translation for the binutils sub-directory 181026 181027 Fix a translation problem for the text generated by readelf at the start of a dump of a dynamic section. 181028 PR 28072 181029 binutils * readelf.c (process_dynamic_section): Use ngettext to help with translation of header text. 181030 1810312021-07-12 Tom de Vries <tdevries@suse.de> 181032 181033 [gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug info 181034 When running test-case gdb.mi/mi-info-sources.exp, I run into: 181035 ... 181036 Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ... 181037 ERROR: internal buffer is full. 181038 ... 181039 due to extra debug info from the shared libraries. 181040 181041 Fix this by using "nosharedlibrary". 181042 181043 Then I run into these FAILs: 181044 ... 181045 FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \ 181046 -file-list-exec-source-files (unexpected output) 181047 FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \ 181048 -file-list-exec-source-files (unexpected output) 181049 FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \ 181050 -file-list-exec-source-files --group-by-objfile, look for \ 181051 mi-info-sources.c (unexpected output) 181052 FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \ 181053 -file-list-exec-source-files --group-by-objfile, look for \ 181054 mi-info-sources-base.c (unexpected output) 181055 ... 181056 due to openSUSE executables which have debug info for objects from sources 181057 like sysdeps/x86_64/crtn.S. 181058 181059 Fix these by updating the patterns, and adding "maint expand-symtabs" to 181060 reliably get fully-read objfiles. 181061 181062 Then I run into FAILs when using the readnow target board. Fix these by 181063 skipping the relevant tests. 181064 181065 Then I run into FAILs when using the cc-with-gnu-debuglink board. Fix these 181066 by updating the patterns. 181067 181068 Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index, 181069 cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m. 181070 181071 gdb/testsuite/ChangeLog: 181072 181073 2021-07-05 Tom de Vries <tdevries@suse.de> 181074 181075 * lib/mi-support.exp (mi_readnow): New proc. 181076 * gdb.mi/mi-info-sources.exp: Use nosharedlibrary. Update patterns. 181077 Skip tests for readnow. Use "maint expand-symtabs". 181078 1810792021-07-12 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> 181080 181081 testsuite: fix whitespace problems in gdb.mi/mi-break.exp 181082 Replace leading 8-spaces with tab and remove trailing space in 181083 gdb.mi/mi-break.exp. 181084 1810852021-07-12 GDB Administrator <gdbadmin@sourceware.org> 181086 181087 Automatic date update in version.in 181088 1810892021-07-11 GDB Administrator <gdbadmin@sourceware.org> 181090 181091 Automatic date update in version.in 181092 1810932021-07-10 Alan Modra <amodra@gmail.com> 181094 181095 Tidy commit 49910fd88dcd 181096 Pointer range checking is UB if the values compared are outside the 181097 underlying array elements (plus one). 181098 181099 * dwarf2.c (read_address): Remove accidental commit. 181100 (read_ranges): Compare offset rather than pointers. 181101 1811022021-07-10 Alan Modra <amodra@gmail.com> 181103 181104 PR28069, assertion fail in dwarf.c:display_discr_list 181105 We shouldn't be asserting on anything to do with leb128 values, or 181106 reporting file and line numbers when something unexpected happens. 181107 leb128 data is of indeterminate length, perfect for fuzzer mayhem. 181108 It would only make sense to assert or report dwarf.c/readelf.c source 181109 lines if the code had already sized and sanity checked the leb128 181110 values. 181111 181112 After removing the assertions, the testcase then gave: 181113 181114 <37> DW_AT_discr_list : 5 byte block: 0 0 0 0 0 (label 0, label 0, label 0, label 0, <corrupt> 181115 readelf: Warning: corrupt discr_list - unrecognized discriminant byte 0x5 181116 181117 <3d> DW_AT_encoding : 0 (void) 181118 <3e> DW_AT_identifier_case: 0 (case_sensitive) 181119 <3f> DW_AT_virtuality : 0 (none) 181120 <40> DW_AT_decimal_sign: 5 (trailing separate) 181121 181122 So the DW_AT_discr_list was showing more data than just the 5 byte 181123 block. That happened due to "end" pointing a long way past the end of 181124 block, and uvalue decrementing past zero on one of the leb128 bytes. 181125 181126 PR 28069 181127 * dwarf.c (display_discr_list): Remove assertions. Delete "end" 181128 parameter, use initial "data" pointer as the end. Formatting. 181129 Don't count down bytes as they are read. 181130 (read_and_display_attr_value): Adjust display_discr_list call. 181131 (read_and_print_leb128): Don't pass __FILE__ and __LINE__ to 181132 report_leb_status. 181133 * dwarf.h (report_leb_status): Don't report file and line 181134 numbers. Delete file and lnum parameters, 181135 (READ_ULEB, READ_SLEB): Adjust. 181136 1811372021-07-10 GDB Administrator <gdbadmin@sourceware.org> 181138 181139 Automatic date update in version.in 181140 1811412021-07-09 H.J. Lu <hjl.tools@gmail.com> 181142 181143 ld/NEWS: Clarify -z [no]indirect-extern-access 181144 -z [no]indirect-extern-access are only for x86 ELF linker. 181145 1811462021-07-09 H.J. Lu <hjl.tools@gmail.com> 181147 181148 elf: Limits 2 GNU_PROPERTY_1_NEEDED tests to Linux/x86 181149 Run property-1_needed-1b.d and property-1_needed-1c.d, which pass 181150 -z [no]indirect-extern-access to linker, only run for Linux/x86 targets. 181151 181152 * testsuite/ld-elf/property-1_needed-1b.d: Only run for 181153 Linux/x86 targets. 181154 * testsuite/ld-elf/property-1_needed-1c.d: Likewise. 181155 1811562021-07-09 H.J. Lu <hjl.tools@gmail.com> 181157 181158 elf: Add GNU_PROPERTY_1_NEEDED check 181159 If GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS is set on any input 181160 relocatable files: 181161 181162 1. Don't generate copy relocations. 181163 2. Turn off extern_protected_data since it implies 181164 GNU_PROPERTY_NO_COPY_ON_PROTECTED. 181165 3. Treate reference to protected symbols with indirect external access 181166 as local. 181167 4. Set GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS on output. 181168 5. When generating executable, clear this bit when there are non-GOT or 181169 non-PLT relocations in input relocatable files without the bit set. 181170 6. Add -z [no]indirect-extern-access to control indirect external access. 181171 181172 bfd/ 181173 181174 * elf-bfd (elf_obj_tdata): Add has_indirect_extern_access. 181175 (elf_has_indirect_extern_access): New. 181176 * elf-properties.c (_bfd_elf_parse_gnu_properties): Set 181177 elf_has_indirect_extern_access and elf_has_no_copy_on_protected 181178 when seeing GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. 181179 (elf_write_gnu_propertie): Add an argument to pass link_info. 181180 Set needed_1_p for GNU_PROPERTY_1_NEEDED in memory. 181181 (_bfd_elf_link_setup_gnu_properties): Handle 181182 GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS for 181183 -z indirect-extern-access. Set nocopyreloc to true and 181184 extern_protected_data to false for indirect external access. 181185 (_bfd_elf_convert_gnu_properties): Updated. 181186 * elf32-i386.c (elf_i386_check_relocs): Set 181187 non_got_ref_without_indirect_extern_access on legacy non-GOT or 181188 non-PLT references. 181189 * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise. 181190 * elflink.c (_bfd_elf_symbol_refs_local_p): Return true for 181191 STV_PROTECTED symbols with indirect external access. 181192 * elfxx-x86.c (_bfd_x86_elf_adjust_dynamic_symbol): Clear 181193 indirect_extern_access for legacy non-GOT/non-PLT references. 181194 * elfxx-x86.h (elf_x86_link_hash_entry): Add 181195 non_got_ref_without_indirect_extern_access. 181196 181197 include/ 181198 181199 * bfdlink.h (bfd_link_info): Add indirect_extern_access and 181200 needed_1_p. Change nocopyreloc to int. 181201 181202 ld/ 181203 181204 * NEWS: Mention -z [no]indirect-extern-access 181205 * ld.texi: Document -z [no]indirect-extern-access 181206 * ldmain.c (main): Initialize link_info.indirect_extern_access 181207 to -1. 181208 * emulparams/extern_protected_data.sh: Support 181209 -z [no]indirect-extern-access. 181210 * testsuite/ld-elf/indirect-extern-access-1.rd: New file 181211 * testsuite/ld-elf/indirect-extern-access-1a.c: Likewise. 181212 * testsuite/ld-elf/indirect-extern-access-1b.c: Likewise. 181213 * testsuite/ld-elf/indirect-extern-access-2.rd: Likewise. 181214 * testsuite/ld-elf/indirect-extern-access-2a.c: Likewise. 181215 * testsuite/ld-elf/indirect-extern-access-2b.c: Likewise. 181216 * testsuite/ld-elf/indirect-extern-access-3.rd: Likewise. 181217 * testsuite/ld-elf/indirect-extern-access.S: Likewise. 181218 * testsuite/ld-elf/property-1_needed-1b.d: Likewise. 181219 * testsuite/ld-elf/property-1_needed-1c.d: Likewise. 181220 * testsuite/ld-x86-64/indirect-extern-access.rd: Likewise. 181221 * testsuite/ld-x86-64/protected-data-1.h: Likewise. 181222 * testsuite/ld-x86-64/protected-data-1a.c: Likewise. 181223 * testsuite/ld-x86-64/protected-data-1b.c: Likewise. 181224 * testsuite/ld-x86-64/protected-data-2a.S: Likewise. 181225 * testsuite/ld-x86-64/protected-data-2b.S: Likewise. 181226 * testsuite/ld-x86-64/protected-func-2a.S: Likewise. 181227 * testsuite/ld-x86-64/protected-func-2b.S: Likewise. 181228 * testsuite/ld-x86-64/protected-func-2c.c: Likewise. 181229 * testsuite/ld-elf/linux-x86.exp: Run test with 181230 GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. 181231 * testsuite/ld-x86-64/x86-64.exp: Run tests for protected 181232 function and data with indirect external access. 181233 1812342021-07-09 H.J. Lu <hjl.tools@gmail.com> 181235 181236 elf: Add GNU_PROPERTY_1_NEEDED 181237 Add GNU_PROPERTY_1_NEEDED: 181238 181239 #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO 181240 181241 to indicate the needed properties by the object file. 181242 181243 Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: 181244 181245 #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) 181246 181247 to indicate that the object file requires canonical function pointers and 181248 cannot be used with copy relocation. 181249 181250 binutils/ 181251 181252 * readelf.c (decode_1_needed): New. 181253 (print_gnu_property_note): Handle GNU_PROPERTY_1_NEEDED. 181254 181255 include/ 181256 181257 * elf/common.h (GNU_PROPERTY_1_NEEDED): New. 181258 (GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS): Likewise. 181259 181260 ld/ 181261 181262 * testsuite/ld-elf/property-1_needed-1a.d: New file. 181263 * testsuite/ld-elf/property-1_needed-1.s: Likewise. 181264 1812652021-07-09 GDB Administrator <gdbadmin@sourceware.org> 181266 181267 Automatic date update in version.in 181268 1812692021-07-09 Lancelot SIX <lsix@lancelotsix.com> 181270 181271 Remove unused parameter in maybe_software_singlestep 181272 While working around, I noticed that the last parameter of 181273 maybe_software_singlestep is never used. This path removes 181274 it. 181275 181276 Built on x86_64-linux-gnu and riscv64-linux-gnu. 181277 181278 gdb/ChangeLog: 181279 181280 * infrun.c (maybe_software_singlestep): Remove unused PC 181281 parameter. 181282 (resume_1): Update calls to maybe_software_singlestep. 181283 1812842021-07-08 H.J. Lu <hjl.tools@gmail.com> 181285 181286 x86-64: Disallow PC reloc against weak undefined symbols in PIE 181287 Disallow PC relocations against weak undefined symbols in PIE since they 181288 can lead to non-zero address at run-time. 181289 181290 bfd/ 181291 181292 PR ld/21782 181293 * elf64-x86-64.c (elf_x86_64_relocate_section): Disallow PC 181294 relocations against weak undefined symbols in PIE. 181295 181296 ld/ 181297 181298 PR ld/21782 181299 * testsuite/ld-x86-64/pie3.d: Expect linker error. 181300 1813012021-07-08 H.J. Lu <hjl.tools@gmail.com> 181302 181303 ld: Limit cache size and add --max-cache-size=SIZE 181304 When link_info.keep_memory is true, linker caches the relocation 181305 information and symbol tables of input files in memory. When there 181306 are many input files with many relocations, we may run out of memory. 181307 Add --max-cache-size=SIZE to set the maximum cache size. 181308 181309 bfd/ 181310 181311 PR ld/18028 181312 * bfd.c (bfd): Add alloc_size. 181313 * elf-bfd.h (_bfd_elf_link_info_read_relocs): New. 181314 * elf32-i386.c (elf_i386_check_relocs): Use _bfd_link_keep_memory. 181315 Update cache_size. 181316 * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise. 181317 * elflink.c (_bfd_elf_link_read_relocs): Renamed to ... 181318 (_bfd_elf_link_info_read_relocs): This. Update cache_size. 181319 (_bfd_elf_link_read_relocs): New. 181320 (_bfd_elf_link_check_relocs): Call _bfd_elf_link_info_read_relocs 181321 instead of _bfd_elf_link_read_relocs. 181322 (elf_link_add_object_symbols): Likewise. 181323 (elf_link_input_bfd): Likewise. 181324 (init_reloc_cookie_rels): Likewise. 181325 (init_reloc_cookie): Update cache_size. Call 181326 _bfd_elf_link_info_read_relocs instead of 181327 _bfd_elf_link_read_relocs. 181328 (link_info_ok): New. 181329 (elf_gc_smash_unused_vtentry_relocs): Updated. Call 181330 _bfd_elf_link_info_read_relocs instead of 181331 _bfd_elf_link_read_relocs. 181332 (bfd_elf_gc_sections): Use link_info_ok. Pass &link_info_ok 181333 to elf_gc_smash_unused_vtentry_relocs. 181334 * libbfd-in.h (_bfd_link_keep_memory): New. 181335 * linker.c (_bfd_link_keep_memory): New. 181336 * opncls.c (bfd_alloc): Update alloc_size. 181337 * bfd-in2.h: Regenerated. 181338 * libbfd.h: Likewise. 181339 181340 include/ 181341 181342 PR ld/18028 181343 * bfdlink.h (bfd_link_info): Add cache_size and max_cache_size. 181344 181345 ld/ 181346 181347 PR ld/18028 181348 * NEWS: Mention --max-cache-size=SIZE. 181349 * ld.texi: Document --max-cache-size=SIZE. 181350 * ldlex.h (option_values): Add OPTION_MAX_CACHE_SIZE. 181351 * ldmain.c: (main): Set link_info.max_cache_size to -1. 181352 * lexsup.c (ld_options): Add --max-cache-size=SIZE. 181353 (parse_args): Support OPTION_MAX_CACHE_SIZE. 181354 * testsuite/ld-bootstrap/bootstrap.exp: Add test for 181355 --max-cache-size=-1. 181356 1813572021-07-08 Simon Marchi <simon.marchi@polymtl.ca> 181358 181359 gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_init 181360 According to bug 28056, running an s390x binary gives: 181361 181362 (gdb) run 181363 Starting program: /usr/bin/ls 181364 /home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: internal-error: displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' failed. 181365 181366 This is because the s390 architecture registers some Linux-specific 181367 displaced stepping callbacks in the OS-agnostic s390_gdbarch_init: 181368 181369 set_gdbarch_displaced_step_prepare (gdbarch, linux_displaced_step_prepare); 181370 set_gdbarch_displaced_step_finish (gdbarch, linux_displaced_step_finish); 181371 set_gdbarch_displaced_step_restore_all_in_ptid 181372 (gdbarch, linux_displaced_step_restore_all_in_ptid); 181373 181374 But then the Linux-specific s390_linux_init_abi_any passes 181375 num_disp_step_buffers=0 to linux_init_abi: 181376 181377 linux_init_abi (info, gdbarch, 0); 181378 181379 The problem happens when linux_displaced_step_prepare is called for the 181380 first time. It tries to allocate the displaced stepping buffers, but 181381 sees that the number of displaced stepping buffers for that architecture 181382 is 0, which is unexpected / invalid. 181383 181384 s390_gdbarch_init should not register the linux_* callbacks, that is 181385 expected to be done by linux_init_abi. If debugging a bare-metal s390 181386 program, or an s390 program on another OS GDB doesn't know about, we 181387 wouldn't want to use them. We would either register no callbacks, if 181388 displaced stepping isn't supported, or register a different set of 181389 callbacks if we wanted to support displaced stepping in those cases. 181390 181391 The commit that refactored the displaced stepping machinery and 181392 introduced these set_gdbarch_displaced_step_* calls is 187b041e2514 181393 ("gdb: move displaced stepping logic to gdbarch, allow starting 181394 concurrent displaced steps"). However, even before that, 181395 s390_gdbarch_init did: 181396 181397 set_gdbarch_displaced_step_location (gdbarch, linux_displaced_step_location); 181398 181399 ... which already seemed wrong. The Linux-specific callback was used 181400 even for non-Linux system. Maybe that was on purpose, because it would 181401 also happen to work in some other non-Linux case, or maybe it was simply 181402 a mistake. I'll assume that this was a small mistake when 181403 s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475 181404 ("s390: Split up s390-linux-tdep.c into two files"). 181405 181406 Fix this by removing the setting of these displaced step callbacks from 181407 s390_gdbarch_init. Instead, pass num_disp_step_buffers=1 to 181408 linux_init_abi, in s390_linux_init_abi_any. Doing so will cause 181409 linux_init_abi to register these same callbacks. It will also mean that 181410 when debugging a bare-metal s390 executable or an executable on another 181411 OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be 181412 set, so displaced stepping won't be used. 181413 181414 This patch will need to be merged in the gdb-11-branch, since this is a 181415 GDB 11 regression, so here's the ChangeLog entry: 181416 181417 gdb/ChangeLog: 181418 181419 * s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number 181420 of displaced stepping buffers to linux_init_abi. 181421 * s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific 181422 displaced-stepping gdbarch callbacks. 181423 181424 Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5 181425 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056 181426 1814272021-07-08 Simon Marchi <simon.marchi@polymtl.ca> 181428 181429 gdb/Makefile.in: remove testsuite from SUBDIRS 181430 When distclean-ing a configured / built gdb directory, like so: 181431 181432 $ ./configure && make all-gdb && make distclean 181433 181434 The distclean operation fails with: 181435 181436 Missing testsuite/Makefile 181437 181438 If we look at the SUBDIRS variable in the generated gdb/Makefile, 181439 testsuite is there twice: 181440 181441 SUBDIRS = doc testsuite data-directory testsuite 181442 181443 So we try distclean-ing the testsuite directory twice. The second time, 181444 gdb/testsuite/Makefile doesn't exist, so it fails. 181445 181446 The first "testsuite" comes from the @subdirs@ replacement, because of 181447 the `AC_CONFIG_SUBDIRS` macro in gdb/configure.ac. The second one is 181448 hard-coded in gdb/Makefile.in: 181449 181450 SUBDIRS = doc @subdirs@ data-directory testsuite 181451 181452 The hard-coded was added by: 181453 181454 bdbbcd577460 ("Always build 'all' in gdb/testsuite") 181455 181456 which came after `testsuite` was removed from @subdirs@ by: 181457 181458 f99d1d37496f ("Remove gdb/testsuite/configure") 181459 181460 My commit a100a94530eb ("gdb/testsuite: restore configure script") 181461 should have removed the hard-coded `testsuite`, since it added it back 181462 as a "subdir", but I missed it because I only looked f99d1d37496f to 181463 write my patch. 181464 181465 Fix this by removing the hard-coded one. 181466 181467 This patch should be pushed to both master and gdb-11-branch, hence the 181468 ChangeLog entry: 181469 181470 gdb/ChangeLog: 181471 181472 * Makefile.in (SUBDIRS): Remove testsuite. 181473 181474 Change-Id: I63e5590b1a08673c646510b3ecc74600eae9f92d 181475 1814762021-07-08 Nick Clifton <nickc@redhat.com> 181477 181478 Updated Portuguese translation for the BFD sub-directory 181479 1814802021-07-08 Tom de Vries <tdevries@suse.de> 181481 181482 [gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0 181483 When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed 181484 with guile 3.0, I run into: 181485 ... 181486 (gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M 181487 ERROR: In procedure make-breakpoint:^M 181488 In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \ 181489 position 3: "BP_CATCHPOINT"^M 181490 Error while executing Scheme code.^M 181491 (gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \ 181492 create a catchpoint via the api 181493 ... 181494 181495 The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second 181496 line of the error message starts with the same prefix as the first: 181497 ... 181498 ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \ 181499 position 3: "BP_CATCHPOINT"^M 181500 ... 181501 181502 I observe the same difference in many other tests, f.i.: 181503 ... 181504 (gdb) gu (print (value-add i '()))^M 181505 ERROR: In procedure value-add:^M 181506 In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M 181507 Error while executing Scheme code.^M 181508 (gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion 181509 ... 181510 but it doesn't cause FAILs anywhere else. 181511 181512 Fix this by updating the regexp to make the "ERROR: " prefix optional. 181513 181514 Tested on x86_64-linux, with both guile 2.0 and 3.0. 181515 181516 gdb/testsuite/ChangeLog: 181517 181518 2021-07-07 Tom de Vries <tdevries@suse.de> 181519 181520 * gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in 181521 exception printing optional. 181522 1815232021-07-08 Mike Frysinger <vapier@gentoo.org> 181524 181525 sim: erc32: use libsim.a for common objects 181526 We're starting to move more objects to the common build that sis did 181527 not need before, so linking them is causing problems (when common 181528 objects end up needing symbols from non-common objects). Switch it 181529 to the libsim.a archive which will allow the link to pull out only 181530 what it needs. 181531 1815322021-07-08 GDB Administrator <gdbadmin@sourceware.org> 181533 181534 Automatic date update in version.in 181535 1815362021-07-07 Nick Clifton <nickc@redhat.com> 181537 181538 Remove an accidental change to elfcode.h included as part of commit 6e0dfbf420. 181539 PR 27659 181540 * elfcode.h (elf_swap_symbol_out): Revert accidental change that 181541 removed an abort if the shndx pointer is NULL. 181542 1815432021-07-07 H.J. Lu <hjl.tools@gmail.com> 181544 181545 ld: Check archive only for archive member 181546 Since plugin_maybe_claim calls bfd_close on the original input BFD if it 181547 isn't an archive member, pass NULL to bfd_plugin_close_file_descriptor 181548 to indicate that the BFD isn't an archive member. 181549 181550 bfd/ 181551 181552 PR ld/18028 181553 * plugin.c (bfd_plugin_close_file_descriptor): Check archive 181554 only of abfd != NULL. 181555 (try_claim): Pass NULL to bfd_plugin_close_file_descriptor if 181556 it isn't an archive member. 181557 181558 ld/ 181559 181560 PR ld/18028 181561 * plugin.c (plugin_input_file): Add comments for abfd and ibfd. 181562 (plugin_object_p): Set input->ibfd to NULL if it isn't an 181563 archive member. 181564 1815652021-07-07 Andreas Krebbel <krebbel@linux.ibm.com> 181566 181567 Add changelog entries for last commit 181568 1815692021-07-07 Andreas Krebbel <krebbel@linux.ibm.com> 181570 181571 IBM Z: Add another arch14 instruction 181572 opcodes/ 181573 181574 * opcodes/s390-opc.txt: Add qpaci. 181575 181576 gas/ 181577 181578 * testsuite/gas/s390/zarch-arch14.d: Add qpaci. 181579 * testsuite/gas/s390/zarch-arch14.s: Add qpaci. 181580 1815812021-07-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 181582 181583 Fix Solaris gprof build with --disable-nls 181584 gprof fails to compile on Solaris 10 and 11.3 with --disable-nls: 181585 181586 In file included from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/gprof.h:33, 181587 from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/basic_blocks.c:24: 181588 /usr/include/libintl.h:45:14: error: expected identifier or '(' before 'const' 181589 45 | extern char *dcgettext(const char *, const char *, const int); 181590 | ^~~~~~~~~ 181591 /usr/include/libintl.h:46:14: error: expected identifier or '(' before 'const' 181592 46 | extern char *dgettext(const char *, const char *); 181593 | ^~~~~~~~ 181594 /usr/include/libintl.h:47:14: error: expected identifier or '(' before 'const' 181595 47 | extern char *gettext(const char *); 181596 | ^~~~~~~ 181597 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:33: 181598 error: expected identifier or '(' before 'do' 181599 165 | # define textdomain(Domainname) do {} while (0) 181600 | ^~ 181601 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:39: 181602 error: expected identifier or '(' before 'while' 181603 165 | # define textdomain(Domainname) do {} while (0) 181604 | ^~~~~ 181605 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:46: 181606 error: expected identifier or '(' before 'do' 181607 166 | # define bindtextdomain(Domainname, Dirname) do {} while (0) 181608 | ^~ 181609 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:52: 181610 error: expected identifier or '(' before 'while' 181611 166 | # define bindtextdomain(Domainname, Dirname) do {} while (0) 181612 | ^~~~~ 181613 /usr/include/libintl.h:55:14: error: expected identifier or '(' before 'unsigned' 181614 55 | extern char *dcngettext(const char *, const char *, 181615 | ^~~~~~~~~~ 181616 /usr/include/libintl.h:57:14: error: expected identifier or '(' before 'unsigned' 181617 57 | extern char *dngettext(const char *, const char *, 181618 | ^~~~~~~~~ 181619 /usr/include/libintl.h:59:14: error: expected identifier or '(' before 'unsigned' 181620 59 | extern char *ngettext(const char *, const char *, unsigned long int); 181621 | ^~~~~~~~ 181622 181623 This is a known issue already partially fixed in binutils/sysdep.h. For 181624 gprof, the same fix needs to be applied in bfd/sysdep.h, as the 181625 following patch does. Tested on i386-pc-solaris2.10 and 181626 i386-pc-solaris2.11. 181627 181628 2021-07-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 181629 181630 bfd: 181631 * sysdep.h [!ENABLE_NLS]: Prevent inclusion of <libintl.h> on 181632 Solaris. 181633 1816342021-07-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 181635 181636 Check for strnlen declaration to fix Solaris 10 build 181637 binutils currently fails to compile on Solaris 10: 181638 181639 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_debug_link_info_1': 181640 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: implicit declaration of function 'strnlen' [-Werror=implicit-function-declaration] 181641 1231 | crc_offset = strnlen (name, size) + 1; 181642 | ^~~~~~~ 181643 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror] 181644 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_alt_debug_link_info': 181645 /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1319:20: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror] 181646 1319 | buildid_offset = strnlen (name, size) + 1; 181647 | ^~~~~~~ 181648 181649 and in a couple of other places. The platform lacks strnlen, and while 181650 libiberty.h can provide a fallback declaration, the necessary configure 181651 test isn't run. 181652 181653 Fixed with the following patch. Tested on i386-pc-solaris2.10. 181654 181655 2021-07-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 181656 181657 bfd: 181658 * configure.ac: Check for strnlen declaration. 181659 * configure, config.in: Regenerate. 181660 181661 binutils: 181662 * configure.ac: Check for strnlen declaration. 181663 * configure, config.in: Regenerate. 181664 1816652021-07-07 Nick Clifton <nickc@redhat.com> 181666 181667 Fix problems translating messages when a percentage sign appears at the end of a string. 181668 PR 28051 181669 gas * config/tc-i386.c (offset_in_range): Reformat error messages in 181670 order to fix problems when translating. 181671 (md_assemble): Likewise. 181672 * messages.c (as_internal_value_out_of_range): Likewise. 181673 * read.c (emit_expr_with_reloc): Likewise. 181674 * testsuite/gas/all/overflow.l Change expected output format. 181675 * po/gas.pot: Regenerate. 181676 181677 bfd * coff-rs6000.c (xcoff_reloc_type_tls): Reformat error messages in 181678 order to fix problems when translating. 181679 * cofflink.c (_bfd_coff_write_global_sym): Likewise. 181680 * elfnn-aarch64.c (_bfd_aarch64_erratum_843419_branch_to_stub): 181681 Likewise. 181682 * po/bfd.pot: Regenerate. 181683 1816842021-07-07 GDB Administrator <gdbadmin@sourceware.org> 181685 181686 Automatic date update in version.in 181687 1816882021-07-06 Simon Marchi <simon.marchi@polymtl.ca> 181689 181690 gdb: introduce iterator_range, remove next_adapter 181691 I was always a bit confused by next_adapter, because it kind of mixes 181692 the element type and the iterator type. In reality, it is not much more 181693 than a class that wraps two iterators (begin and end). However, it 181694 assumes that: 181695 181696 - you can construct the begin iterator by passing a pointer to the 181697 first element of the iterable 181698 - you can default-construct iterator to make the end iterator 181699 181700 I think that by generalizing it a little bit, we can re-use it at more 181701 places. 181702 181703 Rename it to "iterator_range". I think it describes a bit better: it's 181704 a range made by wrapping a begin and end iterator. Move it to its own 181705 file, since it's not related to next_iterator anymore. 181706 181707 iterator_range has two constructors. The variadic one, where arguments 181708 are forwarded to construct the underlying begin iterator. The end 181709 iterator is constructed through default construction. This is a 181710 generalization of what we have today. 181711 181712 There is another constructor which receives already constructed begin 181713 and end iterators, useful if the end iterator can't be obtained by 181714 default-construction. Or, if you wanted to make a range that does not 181715 end at the end of the container, you could pass any iterator as the 181716 "end". 181717 181718 This generalization allows removing some "range" classes, like 181719 all_inferiors_range. These classes existed only to pass some arguments 181720 when constructing the begin iterator. With iterator_range, those same 181721 arguments are passed to the iterator_range constructed and then 181722 forwarded to the constructed begin iterator. 181723 181724 There is a small functional difference in how iterator_range works 181725 compared to next_adapter. next_adapter stored the pointer it received 181726 as argument and constructeur an iterator in the `begin` method. 181727 iterator_range constructs the begin iterator and stores it as a member. 181728 Its `begin` method returns a copy of that iterator. 181729 181730 With just iterator_range, uses of next_adapter<foo> would be replaced 181731 with: 181732 181733 using foo_iterator = next_iterator<foo>; 181734 using foo_range = iterator_range<foo_iterator>; 181735 181736 However, I added a `next_range` wrapper as a direct replacement for 181737 next_adapter<foo>. IMO, next_range is a slightly better name than 181738 next_adapter. 181739 181740 The rest of the changes are applications of this new class. 181741 181742 gdbsupport/ChangeLog: 181743 181744 * next-iterator.h (class next_adapter): Remove. 181745 * iterator-range.h: New. 181746 181747 gdb/ChangeLog: 181748 181749 * breakpoint.h (bp_locations_range): Remove. 181750 (bp_location_range): New. 181751 (struct breakpoint) <locations>: Adjust type. 181752 (breakpoint_range): Use iterator_range. 181753 (tracepoint_range): Use iterator_range. 181754 * breakpoint.c (breakpoint::locations): Adjust return type. 181755 * gdb_bfd.h (gdb_bfd_section_range): Use iterator_range. 181756 * gdbthread.h (all_threads_safe): Pass argument to 181757 all_threads_safe_range. 181758 * inferior-iter.h (all_inferiors_range): Use iterator_range. 181759 (all_inferiors_safe_range): Use iterator_range. 181760 (all_non_exited_inferiors_range): Use iterator_range. 181761 * inferior.h (all_inferiors, all_non_exited_inferiors): Pass 181762 inferior_list as argument. 181763 * objfiles.h (struct objfile) <compunits_range>: Remove. 181764 <compunits>: Return compunit_symtab_range. 181765 * progspace.h (unwrapping_objfile_iterator) 181766 <unwrapping_objfile_iterator>: Take parameter by value. 181767 (unwrapping_objfile_range): Use iterator_range. 181768 (struct program_space) <objfiles_range>: Define with "using". 181769 <objfiles>: Adjust. 181770 <objfiles_safe_range>: Define with "using". 181771 <objfiles_safe>: Adjust. 181772 <solibs>: Return so_list_range, define here. 181773 * progspace.c (program_space::solibs): Remove. 181774 * psymtab.h (class psymtab_storage) <partial_symtab_iterator>: 181775 New. 181776 <partial_symtab_range>: Use iterator_range. 181777 * solist.h (so_list_range): New. 181778 * symtab.h (compunit_symtab_range): 181779 New. 181780 (symtab_range): New. 181781 (compunit_filetabs): Change to a function. 181782 * thread-iter.h (inf_threads_range, 181783 inf_non_exited_threads_range, safe_inf_threads_range, 181784 all_threads_safe_range): Use iterator_range. 181785 * top.h (ui_range): New. 181786 (all_uis): Use ui_range. 181787 181788 Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854 181789 1817902021-07-06 Simon Marchi <simon.marchi@polymtl.ca> 181791 181792 gdb/testsuite: restore configure script 181793 Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed 181794 gdb/testsuite/configure, as anything gdb/testsuite/configure did could 181795 be done by gdb/configure. 181796 181797 There is however one use case that popped up when this changed 181798 propagated to downstream consumers, to run the testsuite on an already 181799 built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built 181800 in a CI job. This GDB package is then tested on different machines / 181801 hardware configurations as part of other CI jobs. To achieve this, 181802 those CI jobs only configure the testsuite directory and run "make 181803 check" with an appropriate board file. 181804 181805 In light of this use case, the way I see it is that gdb/testsuite could 181806 be considered its own project. It could be stored in a completely 181807 different repo if we want to, it just happens to be stored inside gdb/. 181808 181809 Since the only downside of having gdb/testsuite/configure is that it 181810 takes a few more seconds to run, but on the other hand it's quite useful 181811 for some people, I propose re-adding it. 181812 181813 In a sense, this is revert of f99d1d37496f, but it's not a direct 181814 git-revert, as some things have changed since. 181815 181816 gdb/ChangeLog: 181817 181818 * configure.ac: Remove things that were moved from 181819 testsuite/configure.ac. 181820 * configure: Re-generate. 181821 181822 gdb/testsuite/ChangeLog: 181823 181824 * configure.ac: Restore. 181825 * configure: Re-generate. 181826 * aclocal.m4: Re-generate. 181827 * Makefile.in (distclean): Add config.status. 181828 (Makefile): Adjust paths. 181829 (lib/pdtrace): Adjust paths. 181830 (config.status): Add. 181831 181832 Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1 181833 1818342021-07-06 Joel Brobecker <brobecker@adacore.com> 181835 181836 Rename gdb/ChangeLog to gdb/ChangeLog-2021 181837 Now that ChangeLog entries are no longer used for GDB patches, 181838 this commit renames the file gdb/ChangeLog to gdb/ChangeLog-2021, 181839 similar to what we would do in the context of the "Start of New 181840 Year" procedure. 181841 181842 The purpose of this change is to avoid people merging ChangeLog 181843 entries by mistake when applying existing commits that they are 181844 currently working on. 181845 1818462021-07-06 Dan Streetman <ddstreet@canonical.com> 181847 181848 sim: ppc: add missing empty targets 181849 These are copied from sim/common/Make-common.in. 181850 181851 On ppc the build fails without at least the 'info' target, e.g.: 181852 181853 Making info in ppc 181854 make[4]: Entering directory '/<<BUILDDIR>>/gdb-10.2.2974.g5b45e89f56d+21.10.20210510155809/build/default/sim/ppc' 181855 make[4]: *** No rule to make target 'info'. Stop. 181856 1818572021-07-06 Yuri Chornoivan <yurchor@ukr.net> 181858 181859 PR 28053: Fix spelling mistakes: usupported -> unsupported and relocatation -> relocation. 181860 1818612021-07-06 Michael Matz <matz@suse.de> 181862 181863 elf/riscv: Fix relaxation with aliases [PR28021] 181864 the fix for PR22756 only changed behaviour for hidden aliases, 181865 but the same situation exists for non-hidden aliases: sym_hashes[] 181866 can contain multiple entries pointing to the same symbol structure 181867 leading to relaxation adjustment to be applied twice. 181868 181869 Fix this by testing for duplicates for everything that looks like it 181870 has a version. 181871 181872 PR ld/28021 181873 181874 bfd/ 181875 * elfnn-riscv.c (riscv_relax_delete_bytes): Check for any 181876 versioning. 181877 181878 ld/ 181879 * testsuite/ld-riscv-elf/relax-twice.ver: New. 181880 * testsuite/ld-riscv-elf/relax-twice-1.s: New. 181881 * testsuite/ld-riscv-elf/relax-twice-2.s: New. 181882 * testsuite/ld-riscv-elf/ld-riscv-elf.exp 181883 (run_relax_twice_test): New, and call it. 181884 1818852021-07-06 Pedro Alves <pedro@palves.net> 181886 Qingchuan Shi <qingchuan.shi@amd.com> 181887 181888 Update gdb performance testsuite to be compatible with Python 3.8 181889 Running "make check-perf" on a system with Python 3.8 (e.g., Ubuntu 181890 20.04) runs into this Python problem: 181891 181892 Traceback (most recent call last): 181893 File "<string>", line 1, in <module> 181894 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run 181895 self.execute_test() 181896 File "<string>", line 35, in execute_test 181897 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure 181898 m.start(id) 181899 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start 181900 self.start_time = time.clock() 181901 AttributeError: module 'time' has no attribute 'clock' 181902 Error while executing Python code. 181903 (gdb) FAIL: gdb.perf/single-step.exp: python SingleStep(1000).run() 181904 181905 ... many times over. 181906 181907 The problem is that the testsuite is using time.clock(), deprecated in 181908 Python 3.3 and finaly removed in Python 3.8. The guidelines say to 181909 use time.perf_counter() or time.process_time() instead depending on 181910 requirements. Looking at the current description of those functions, 181911 at: 181912 181913 https://docs.python.org/3.10/library/time.html 181914 181915 we have: 181916 181917 time.perf_counter() -> float 181918 181919 Return the value (in fractional seconds) of a performance 181920 counter, i.e. a clock with the highest available resolution to 181921 measure a short duration. It does include time elapsed during 181922 sleep and is system-wide. (...) 181923 181924 time.process_time() -> float 181925 181926 Return the value (in fractional seconds) of the sum of the 181927 system and user CPU time of the current process. It does not 181928 include time elapsed during sleep. It is process-wide by 181929 definition. (...) 181930 181931 I'm thinking that it's just best to record both instead of picking 181932 one. So this patch replaces the MeasurementCpuTime measurement class 181933 with two new classes -- MeasurementPerfCounter and 181934 MeasurementProcessTime. Correspondingly, this changes the reports in 181935 testsuite/perftest.log -- we have two new "perf_counter" and 181936 "process_time" measurements and the "cpu_time" measurement is gone. I 181937 don't suppose breaking backward compatibility here is a big problem. 181938 I suspect no one is really tracking long term performance using the 181939 perf testsuite today. And if they are, it shouldn't be hard to adjust. 181940 181941 For backward compatility, with Python < 3.3, both perf_counter and 181942 process_time use the old time.clock. 181943 181944 gdb/testsuite/ChangeLog: 181945 yyyy-mm-dd Qingchuan Shi <qingchuan.shi@amd.com> 181946 Pedro Alves <pedro@palves.net> 181947 181948 * gdb.perf/lib/perftest/perftest.py: Import sys. 181949 (time.perf_counter, time.process_time): Map to time.clock on 181950 Python < 3.3. 181951 (MeasurementCpuTime): Delete, replaced by... 181952 (MeasurementPerfCounter, MeasurementProcessTime): .. these two new 181953 classes. 181954 * gdb.perf/lib/perftest/perftest.py: Import MeasurementPerfCounter 181955 and MeasurementProcessTime instead of MeasurementCpuTime. 181956 (TestCaseWithBasicMeasurements): Use MeasurementPerfCounter and 181957 MeasurementProcessTime instead of MeasurementCpuTime. 181958 181959 181960 Change-Id: Ia850c05d5ce57d2dada70ba5b0061f566444aa2b 181961 1819622021-07-06 Pedro Alves <pedro@palves.net> 181963 181964 gdb.perf/: FAIL on Python errors, avoid "ERROR: internal buffer is full" 181965 Currently, if you run make check-perf on a system with Python 3.8, 181966 tests seen to PASS, but they actually test a lot less than intended, 181967 due to: 181968 181969 PerfTest::assemble, run ... 181970 python BackTrace(64).run() 181971 Traceback (most recent call last): 181972 File "<string>", line 1, in <module> 181973 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run 181974 self.execute_test() 181975 File "<string>", line 49, in execute_test 181976 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure 181977 m.start(id) 181978 File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start 181979 self.start_time = time.clock() 181980 AttributeError: module 'time' has no attribute 'clock' 181981 Error while executing Python code. 181982 (gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run() 181983 181984 And then, after fixing the above Python compatibility issues (which 181985 will be a separate patch), I get 86 instances of overflowing expect's 181986 buffer, like: 181987 181988 ERROR: internal buffer is full. 181989 UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run() 181990 181991 This patch fixes both problems by adding & using a gdb_test_python_run 181992 routine that: 181993 181994 - checks for Python errors 181995 - consumes output line by line 181996 181997 gdb/testsuite/ChangeLog: 181998 yyyy-mm-dd Pedro Alves <pedro@palves.net> 181999 182000 * gdb.perf/backtrace.exp: Use gdb_test_python_run. 182001 * gdb.perf/disassemble.exp: Use gdb_test_python_run. 182002 * gdb.perf/single-step.exp: Use gdb_test_python_run. 182003 * gdb.perf/skip-command.exp: Use gdb_test_python_run. 182004 * gdb.perf/skip-prologue.exp: Use gdb_test_python_run. 182005 * gdb.perf/solib.exp: Use gdb_test_python_run. 182006 * gdb.perf/template-breakpoints.exp: Use gdb_test_python_run. 182007 * lib/perftest.exp (gdb_test_python_run): New. 182008 182009 Change-Id: I007af36f164b3f4cda41033616eaaa4e268dfd2f 182010 1820112021-07-06 Tom de Vries <tdevries@suse.de> 182012 182013 [gdb/testsuite] Remove read1 timeout factor from gdb.base/info-macros.exp 182014 At the moment some check-read1 timeouts are handled like this in 182015 gdb.base/info-macros.exp: 182016 ... 182017 gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname { 182018 -re "$r1$r2$r3" { 182019 pass $testname 182020 } 182021 -re ".*#define TWO.*\r\n$gdb_prompt" { 182022 fail $testname 182023 } 182024 -re ".*#define THREE.*\r\n$gdb_prompt" { 182025 fail $testname 182026 } 182027 -re ".*#define FOUR.*\r\n$gdb_prompt" { 182028 fail $testname 182029 } 182030 } 182031 ... 182032 which is not ideal. 182033 182034 We could use gdb_test_lines, but it currently doesn't support verifying 182035 the absence of regexps, which is done using the clauses above calling fail. 182036 182037 Fix this by using gdb_test_lines and adding a -re-not syntax to 182038 gdb_test_lines, such that we can do: 182039 ... 182040 gdb_test_lines $test $testname $r1.*$r2 \ 182041 -re-not "#define TWO" \ 182042 -re-not "#define THREE" \ 182043 -re-not "#define FOUR" 182044 ... 182045 182046 Tested on x86_64-linux, whith make targets check and check-read1. 182047 182048 Also observed that check-read1 execution time is reduced from 6m35s to 13s. 182049 182050 gdb/testsuite/ChangeLog: 182051 182052 2021-07-06 Tom de Vries <tdevries@suse.de> 182053 182054 * gdb.base/info-macros.exp: Replace use of 182055 gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines. 182056 (gdb_test_multiple_with_read1_timeout_factor): Remove. 182057 * lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>. 182058 1820592021-07-06 Nelson Chu <nelson.chu@sifive.com> 182060 182061 RISC-V: Fix the build broken with -Werror. 182062 ChangeLog: 182063 182064 bfd/ 182065 182066 * elfnn-riscv.c(riscv_elf_additional_program_headers): Removed the 182067 unused variable s. 182068 (riscv_elf_modify_segment_map): Added ATTRIBUTE_UNUSED for the 182069 unused parameter info. 182070 1820712021-07-06 Tom de Vries <tdevries@suse.de> 182072 182073 [gdb/symtab] Fix skipping of import of C++ CU 182074 Tom Tromey observed that when changing the language in 182075 gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed. 182076 182077 This is due to this code in process_imported_unit_die: 182078 ... 182079 /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit 182080 into another compilation unit, at root level. Regard this as a hint, 182081 and ignore it. */ 182082 if (die->parent && die->parent->parent == NULL 182083 && per_cu->unit_type == DW_UT_compile 182084 && per_cu->lang == language_cplus) 182085 return; 182086 ... 182087 which should have a partial symtabs counterpart. 182088 182089 Add the missing counterpart in process_psymtab_comp_unit. 182090 182091 Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config: 182092 - using default gcc version 7.5.0 182093 (with 5 unexpected FAILs) 182094 - gcc 10.3.0 and target board 182095 unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects 182096 (with 1000 unexpected FAILs) 182097 182098 gdb/ChangeLog: 182099 182100 2021-07-06 Tom de Vries <tdevries@suse.de> 182101 182102 * dwarf2/read.c (scan_partial_symbols): Skip top-level imports of 182103 c++ CU. 182104 * testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ... 182105 * testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here. 182106 * testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test. 182107 * testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test. 182108 * testsuite/gdb.dwarf2/imported-unit.exp: Update. 182109 1821102021-07-06 Kito Cheng <kito.cheng@sifive.com> 182111 182112 RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR. 182113 We added PT_RISCV_ATTRIBUTES to program header to make 182114 .riscv.attribute easier to find in dynamic loader or kernel. 182115 182116 Ref: 182117 https://github.com/riscv/riscv-elf-psabi-doc/pull/71 182118 182119 ChangeLog: 182120 182121 bfd/ 182122 182123 * elfnn-riscv.c(RISCV_ATTRIBUTES_SECTION_NAME): New. 182124 (riscv_elf_additional_program_headers): Ditto. 182125 (riscv_elf_modify_segment_map): Ditto. 182126 (elf_backend_additional_program_headers): Ditto. 182127 (elf_backend_modify_segment_map): Ditto. 182128 (elf_backend_obj_attrs_section): Use RISCV_ATTRIBUTES_SECTION_NAME 182129 rather than string literal. 182130 182131 binutils/ 182132 182133 * readelf.c(get_riscv_segment_type): New. 182134 (get_segment_type): Handle EM_RISCV. 182135 182136 include/ 182137 182138 * elf/riscv.h (PT_RISCV_ATTRIBUTES): New. 182139 * testsuite/ld-elf/orphan-region.ld: Discard .riscv.attributes 182140 section for simplify testcase. 182141 * testsuite/ld-riscv-elf/attr-phdr.d: New. 182142 * testsuite/ld-riscv-elf/attr-phdr.s: Ditto. 182143 * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Add attr-phdr to 182144 testcase. 182145 1821462021-07-06 Alan Modra <amodra@gmail.com> 182147 182148 Re: PR28055, segfault in bpf special reloc function 182149 PR 28055 182150 * elf64-bpf.c (bpf_elf_generic_reloc): Add missing ATTRIBUTE_UNUSED. 182151 1821522021-07-06 GDB Administrator <gdbadmin@sourceware.org> 182153 182154 Automatic date update in version.in 182155 1821562021-07-05 Tom Tromey <tom@tromey.com> 182157 182158 Simplify debug_names index writing 182159 This changes the .debug_names writer to find the TU indices in the 182160 main loop over all CUs and TUs. (An earlier patch applied this same 182161 treatment to the .gdb_index writer.) 182162 182163 Simplify gdb_index writing 182164 write_gdbindex writes the CUs first, then walks the signatured type 182165 hash table to write out the TUs. However, now that CUs and TUs are 182166 unified in the DWARF reader, it's simpler to handle both of these in 182167 the same loop. 182168 182169 Minor cleanup to addrmap_index_data::previous_valid 182170 This changes addrmap_index_data::previous_valid to a bool, and 182171 initializes it inline. 182172 1821732021-07-05 Tom Tromey <tom@tromey.com> 182174 182175 Fix oddity in write_gdbindex 182176 My recent patch to unify CUs and TUs introduced an oddity in 182177 write_gdbindex. Here, we pass 'i' to recursively_write_psymbols, but 182178 we must instead pass 'counter', to handle the situation where a TU is 182179 mixed in with the CUs. 182180 182181 I am not sure a test case for this is possible. I think it can only 182182 happen when using DWARF 5, where a TU appears in .debug_info. 182183 However, this situation is already not handled correctly by 182184 .gdb_index. I filed a bug about this. 182185 1821862021-07-05 Tom Tromey <tom@tromey.com> 182187 182188 Fix warning in symtab.c 182189 The compiler gives this warning when building symtab.c: 182190 182191 ../../binutils-gdb/gdb/symtab.c:4247:28: warning: 'to_match' may be used uninitialized in this function [-Wmaybe-uninitialized] 182192 182193 This patch fixes the warning by adding a gdb_assert_not_reached. 182194 1821952021-07-05 H.J. Lu <hjl.tools@gmail.com> 182196 182197 ld: Cache and reuse the IR archive file descriptor 182198 Linker plugin_object_p opens the IR archive for each IR archive member. 182199 For GCC plugin, plugin_object_p closes the archive file descriptor. But 182200 for LLVM plugin, the archive file descriptor remains open. If there are 182201 3000 IR archive members, there are 3000 file descriptors for them. We 182202 can run out of file descriptors petty easily. 182203 182204 1. Add archive_plugin_fd and archive_plugin_fd_open_count to bfd so that 182205 we can cache and reuse the IR archive file descriptor for all IR archive 182206 members in the archive. 182207 2. Add bfd_plugin_close_file_descriptor to properly close the IR archive 182208 file descriptor. 182209 182210 bfd/ 182211 182212 PR ld/28040 182213 * archive.c (_bfd_archive_close_and_cleanup): Close the archive 182214 plugin file descriptor if needed. 182215 * bfd.c (bfd): Add archive_plugin_fd and 182216 archive_plugin_fd_open_count. 182217 * opncls.c (_bfd_new_bfd): Initialize to -1. 182218 * plugin.c (bfd_plugin_open_input): Cache and reuse the archive 182219 plugin file descriptor. 182220 (bfd_plugin_close_file_descriptor): New function. 182221 (try_claim): Call bfd_plugin_close_file_descriptor. 182222 * plugin.h (bfd_plugin_close_file_descriptor): New. 182223 * bfd-in2.h: Regenerated. 182224 182225 ld/ 182226 182227 PR ld/28040 182228 * plugin.c (plugin_input_file): Add ibfd. 182229 (release_plugin_file_descriptor): New function. 182230 (release_input_file): Call release_plugin_file_descriptor to 182231 close input->fd. 182232 (plugin_object_p): Call release_plugin_file_descriptor to close 182233 input->fd. Also call release_plugin_file_descriptor if not 182234 claimed. 182235 * testsuite/config/default.exp (RANLIB): New. 182236 * testsuite/ld-plugin/lto.exp: Run ranlib test. 182237 1822382021-07-05 Nick Clifton <nickc@redhat.com> 182239 182240 Restore the libiberty component of commit 50ad1254d5030d0804cbf89c758359ae202e8d55. 182241 This commit has not yet been applied to the master sources in the gcc repository. 182242 It was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html 182243 The commit allows options to be set for the AR and RANLIB programs used when building libiberty, which in turn allows building with LTO enabled. 182244 182245 Updated translations (mainly Ukranian and French) triggered by creation of 2.37 branch. 182246 1822472021-07-05 Tom de Vries <tdevries@suse.de> 182248 182249 [gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7 182250 Since commit 05b85772061 "gdb/fortran: Add type info of formal parameter for 182251 clang" I see: 182252 ... 182253 (gdb) ptype say_string^M 182254 type = void (character*(*), integer(kind=4))^M 182255 (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string 182256 ... 182257 182258 The part of the commit causing the fail is: 182259 ... 182260 gdb_test "ptype say_string" \ 182261 - "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)" 182262 + "type = void \\(character\[^,\]+, $integer8\\)" 182263 ... 182264 which fails to take into account that for gcc-7 and before, the type for 182265 string length of a string argument is int, not size_t. 182266 182267 Fix this by allowing both $integer8 and $integer4. 182268 182269 Tested on x86_64-linux, with gcc-7 and gcc-10. 182270 182271 gdb/testsuite/ChangeLog: 182272 182273 2021-07-05 Tom de Vries <tdevries@suse.de> 182274 182275 * gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and 182276 $integer4 for size of string length. 182277 1822782021-07-05 Simon Marchi <simon.marchi@polymtl.ca> 182279 182280 gdb: fall back on sigpending + sigwait if sigtimedwait is not available 182281 The macOS platform does not provide sigtimedwait, so we get: 182282 182283 CXX compile/compile.o 182284 In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46: 182285 /Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait' 182286 sigtimedwait (&set, nullptr, &zero_timeout); 182287 ^ 182288 182289 An alternative to sigtimedwait with a timeout of 0 is to use sigpending, 182290 to first check which signals are pending, and then sigwait, to consume 182291 them. Since that's slightly more expensive (2 syscalls instead of 1), 182292 keep using sigtimedwait for the platforms that provide it, and fall back 182293 to sigpending + sigwait for the others. 182294 182295 gdbsupport/ChangeLog: 182296 182297 * scoped_ignore_signal.h (struct scoped_ignore_signal) 182298 <~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT 182299 is defined, else use sigpending + sigwait. 182300 182301 Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87 182302 Co-Authored-By: John Baldwin <jhb@FreeBSD.org> 182303 1823042021-07-05 Simon Marchi <simon.marchi@polymtl.ca> 182305 182306 gdbsupport/common.m4: check for sigtimedwait 182307 The next patch will make the use of sigtimedwait conditional to whether 182308 the platform provides it. Start by adding a configure check for it. 182309 182310 gdbsupport/ChangeLog: 182311 182312 * common.m4 (GDB_AC_COMMON): Check for sigtimedwait. 182313 * config.in, configure: Re-generate. 182314 182315 gdb/ChangeLog: 182316 182317 * config.in, configure: Re-generate. 182318 182319 gdbserver/ChangeLog: 182320 182321 * config.in, configure: Re-generate. 182322 182323 Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05 182324 1823252021-07-05 Alan Modra <amodra@gmail.com> 182326 182327 Re: opcodes: constify & local meps macros 182328 Commit f375d32b35ce changed a generated file. Edit the source instead. 182329 182330 * mep.opc (macros): Make static and const. 182331 (lookup_macro): Return and use const pointer. 182332 (expand_macro): Make mac param const. 182333 (expand_string): Make pmacro const. 182334 1823352021-07-05 Alan Modra <amodra@gmail.com> 182336 182337 PR28055, segfault in bpf special reloc function 182338 The testcase in this PR tickled two bugs fixed here. output_bfd is 182339 NULL when a reloc special_function is called for final linking and 182340 when called from bfd_generic_get_relocated_section_contents. Clearly 182341 using output_bfd is wrong as it results in segfaults. Not only that, 182342 the endianness of the reloc field really should be that of the input. 182343 The second bug was not checking that the entire reloc field was 182344 contained in the section contents. 182345 182346 PR 28055 182347 * elf64-bpf.c (bpf_elf_generic_reloc): Use correct bfd for bfd_put 182348 and bfd_put_32 calls. Correct section limit checks. 182349 1823502021-07-05 Alan Modra <amodra@gmail.com> 182351 182352 PR28047, readelf crash due to assertion failure 182353 DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref1, and 182354 DW_FORM_ref_udata are all supposed to be within the containing unit. 182355 182356 PR 28047 182357 * dwarf.c (get_type_abbrev_from_form): Add cu_end parameter. 182358 Check DW_FORM_ref1 etc. arg against cu_end rather than end of 182359 section. Adjust all callers. 182360 1823612021-07-05 GDB Administrator <gdbadmin@sourceware.org> 182362 182363 Automatic date update in version.in 182364 1823652021-07-04 Simon Marchi <simon.marchi@polymtl.ca> 182366 182367 gdb: return early if no execution in darwin_solib_create_inferior_hook 182368 When loading a file using the file command on macOS, we get: 182369 182370 $ ./gdb -nx --data-directory=data-directory -q -ex "file ./test" 182371 Reading symbols from ./test... 182372 Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test... 182373 /Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed. 182374 A problem internal to GDB has been detected, 182375 further debugging may prove unreliable. 182376 Quit this debugging session? (y or n) 182377 182378 The backtrace is: 182379 182380 * frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3 182381 frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3 182382 frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31 182383 frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34 182384 frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5 182385 frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3 182386 frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7 182387 frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3 182388 frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3 182389 frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7 182390 frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2 182391 frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7 182392 frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9 182393 frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3 182394 frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3 182395 frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7 182396 frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10 182397 frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1 182398 182399 The solib_create_inferior_hook call in symbol_file_command was added by 182400 commit ea142fbfc9c1 ("Fix breakpoints on file reloads for PIE 182401 binaries"). It causes solib_create_inferior_hook to be called while 182402 the inferior is not running, which darwin_solib_create_inferior_hook 182403 does not expect. darwin_solib_get_all_image_info_addr_at_init, in 182404 particular, assumes that there is a current thread, as it tries to get 182405 the current thread's regcache. 182406 182407 Fix it by adding a target_has_execution check and returning early. Note 182408 that there is a similar check in svr4_solib_create_inferior_hook. 182409 182410 gdb/ChangeLog: 182411 182412 * solib-darwin.c (darwin_solib_create_inferior_hook): Return 182413 early if no execution. 182414 182415 Change-Id: Ia11dd983a1e29786e5ce663d0fcaa6846dc611bb 182416 1824172021-07-04 GDB Administrator <gdbadmin@sourceware.org> 182418 182419 Automatic date update in version.in 182420 1824212021-07-03 H.J. Lu <hjl.tools@gmail.com> 182422 182423 gprof: Regenerate configure 182424 * configure: Regenerated. 182425 1824262021-07-03 Joel Brobecker <brobecker@adacore.com> 182427 182428 Update NEWS post GDB 11 branch creation. 182429 gdb/ChangeLog: 182430 182431 * NEWS: Create a new section for the next release branch. 182432 Rename the section of the current branch, now that it has 182433 been cut. 182434 1824352021-07-03 Joel Brobecker <brobecker@adacore.com> 182436 182437 Bump version to 12.0.50.DATE-git. 182438 Now that the GDB 11 branch has been created, we can 182439 bump the version number. 182440 182441 gdb/ChangeLog: 182442 182443 GDB 11 branch created (4b51505e33441c6165e7789fa2b6d21930242927): 182444 * version.in: Bump version to 12.0.50.DATE-git. 182445 182446 gdb/testsuite/ChangeLog: 182447 182448 * gdb.base/default.exp: Change $_gdb_major to 12. 182449 1824502021-07-03 Tom Tromey <tom@tromey.com> 182451 182452 Use 'bool' more idiomatically in dwarf_decode_lines 182453 I noticed a couple of spots related to dwarf_decode_lines where the 182454 'include_p' field was not being used idiomatically -- it is of type 182455 bool now, so treat it as such. 182456 182457 gdb/ChangeLog 182458 2021-07-03 Tom Tromey <tom@tromey.com> 182459 182460 * dwarf2/read.c (lnp_state_machine::record_line): Use 'true'. 182461 (dwarf_decode_lines): Remove '=='. 182462 1824632021-07-03 Nick Clifton <nickc@redhat.com> 182464 182465 More minor updates to the how-to-make-a-release documentation 182466