aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-23PR30437 aarch64: make RELA relocs idempotentMichael Matz4-104/+139
normally RELA relocs in BFD should not consider the contents of the relocated place. The aarch64 psABI is even stricter, it specifies (section 5.7.16) that all RELA relocs _must_ be idempotent. Since the inception of the aarch64 BFD backend all the relocs have a non-zero src_mask, and hence break this invariant. It's normally not a very visible problem as one can see it only when the relocated place already contains a non-zero value, which usually only happens sometimes when using 'ld -r' (or as in the testcase when jumping through hoops to generate the relocations). Or with alternative toolchains that do encode stuff in the relocated places with the assumption that a relocation to that place ignores whatever is there (as they can according to the psABI). Golang is such a toolchain and https://github.com/golang/go/issues/39927 is ultimately caused by this problem: the testcase testGCData failing is caused by the garbage collection data-structure to describe a type containing pointers to be wrong. It's wrong because a field that's supposed to contain a file-relative offset (to some gcbits) has a relocation applied and that relocation has an addend which also is already part of the go-produced object file (so the addend is implicitely applied twice). bfd/ PR ld/30437 * elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask if all relocation descriptors. ld/ * testsuite/ld-aarch64/rela-idempotent.s: New testcase. * testsuite/ld-aarch64/rela-idempotent.d: New. * testsuite/ld-aarch64/aarch64-elf.exp: Run it.
2023-05-23Updated Swedish translation for the opcodes directoryNick Clifton2-238/+255
2023-05-23gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.expBruno Larsen1-4/+2
When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64 machine, the compiled test case would segfault when returning from the function can_relocate_call, with a suggestion of a broken stack. The example assembly in the commment was the following: f: MOV $1, %[ok] JMP end set_point0: CALL f ; tracepoint here. end: And the segmentation fault happening at the final "ret" instruction of can_relocate_call. Looking at the disassembled version of the later half of the important function, we see: Clang version (f starting at 11a4): 00000000000011ae <set_point0>: 11ae: e8 f1 ff ff ff callq 11a4 <can_relocate_call+0x14> 11b3: 89 45 fc mov %eax,-0x4(%rbp) 11b6: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 11ba: 0f 85 0a 00 00 00 jne 11ca <set_point0+0x1c> 11c0: e8 5b 00 00 00 callq 1220 <pass> 11c5: e9 05 00 00 00 jmpq 11cf <set_point0+0x21> 11ca: e8 61 00 00 00 callq 1230 <fail> 11cf: 48 83 c4 10 add $0x10,%rsp 11d3: 5d pop %rbp 11d4: c3 retq 11d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) 11dc: 00 00 00 00 gcc version (f starting at 401125): 000000000040112c <set_point0>: 40112c: e8 f4 ff ff ff callq 401125 <can_relocate_call+0x11> 401131: 89 45 fc mov %eax,-0x4(%rbp) 401134: 83 7d fc 01 cmpl $0x1,-0x4(%rbp) 401138: 75 07 jne 401141 <set_point0+0x15> 40113a: e8 c7 ff ff ff callq 401106 <pass> 40113f: eb 05 jmp 401146 <set_point0+0x1a> 401141: e8 c7 ff ff ff callq 40110d <fail> 401146: 90 nop 401147: c9 leaveq 401148: c3 retq The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main difference: GCC's version uses the leaveq instruction, which resets rsp based on rbp, while clang adds the same constant to rsp that it subtracted in the prologue. Clang fails because the return address that is added by the "call f" instruction isn't accounted for. This commit fixes that by adding a return instruction to f, which leaves the rsp as the compilers would expect. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-05-23x86/Intel: address quoted-symbol related FIXMEsJan Beulich1-8/+4
If in a "word ptr <address>" or alike construct the "ptr" part is double-quoted, it shouldn't be recognized as the specific keyword we're looking for (just like we don't recognize double-quoted operator or register names anymore). Be careful though to tell closing from opening double-quotes, as a quoted symbol may follow right afterwards.
2023-05-23x86: don't recognize quoted symbol names as registers or operatorsJan Beulich7-0/+53
The concept of quoted symbols names was introduced pretty late. Utilize it to allow access to symbols with names matching that of a register (or, in Intel syntax, also an identifier-like operator). This is primarily to aid gcc when generating Intel syntax output; see their bug target/53929.
2023-05-23Support Intel FRED LKGSZhang, Jun19-4797/+5100
gas/ChangeLog: * NEWS: Support Intel FRED LKGS. * config/tc-i386.c: Add fred lkgs * doc/c-i386.texi: Document .fred, .lkgs. * testsuite/gas/i386/i386.exp: Add FRED LKGS tests * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. * testsuite/gas/i386/x86-64-fred.d: Ditto. * testsuite/gas/i386/x86-64-fred.s: Ditto. * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. * testsuite/gas/i386/x86-64-lkgs.d: Ditto. * testsuite/gas/i386/x86-64-lkgs.s: Ditto. opcodes/ChangeLog: * i386-dis.c: New entry for fred, lkgs. * i386-gen.c: Add CPU_FRED CPU_LKGS. * i386-init.h : Regenerated. * i386-mnem.h : Regenerated. * i386-opc.h: Add fred, lkgs. * i386-opc.tbl: Add FRED, LKGS instructions. * i386-tbl.h: Regenerated.
2023-05-23Revert "Support Intel FRED LKGS"liuhongt16-212/+2
This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.
2023-05-23Support Intel FRED LKGSZhang, Jun16-2/+212
gas/ChangeLog: * NEWS: Support Intel FRED LKGS. * config/tc-i386.c: Add fred lkgs * doc/c-i386.texi: Document .fred, .lkgs. * testsuite/gas/i386/i386.exp: Add FRED LKGS tests * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. * testsuite/gas/i386/x86-64-fred.d: Ditto. * testsuite/gas/i386/x86-64-fred.s: Ditto. * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. * testsuite/gas/i386/x86-64-lkgs.d: Ditto. * testsuite/gas/i386/x86-64-lkgs.s: Ditto. opcodes/ChangeLog: * i386-dis.c: New entry for fred, lkgs. * i386-gen.c: Add CPU_FRED CPU_LKGS. * i386-init.h : Regenerated. * i386-mnem.h : Regenerated. * i386-opc.h: Add fred, lkgs. * i386-opc.tbl: Add FRED, LKGS instructions. * i386-tbl.h: Regenerated.
2023-05-23Automatic date update in version.inGDB Administrator1-1/+1
2023-05-22[gdb/tui] Fix buglet in tui_update_variablesTom de Vries1-2/+3
I noticed a buglet in tui_update_variables: ... entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner); if (tui_border_lrcorner != (chtype) entry->value) { tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value; ... When assigning the new value to tui_border_lrcorner, an entry->value of -1 is taken into account, but not when comparing to the current value of tui_border_lrcorner. Fix this by introducing: ... int val = (entry->value < 0) ? ACS_LRCORNER : entry->value; ... and using this in both comparison and assignment. Tested on x86_64-linux.
2023-05-22Remove some FIXME comments from DAPTom Tromey4-7/+0
I recently added a 'dap' component to bugzilla, and I filed a few bugs there. This patch removes the corresponding FIXME comments. A few such comments still exist. In at least one case, I have a fix I'll be submitting eventually; in others I think I need to do a bit of investigation to properly file a bug report.
2023-05-22gdb: add Richard Bunt to gdb/MAINTAINERSRichard Bunt1-0/+1
2023-05-22[gdb/testsuite] Add Term::get_line_with_attrsTom de Vries2-7/+59
Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that annotates a tuiterm line with the active attributes. For instance, the line representing the TUI status window with attribute mode standout looks like this with Term::get_line: ... exec No process In: ... L?? PC: ?? ... but like this with Term::get_line_with_attrs: ... <reverse:1>exec No process In: ... L?? PC: ?? <reverse:0> ... Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses Term::get_line_with_attrs instead of Term::get_line. Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) on x86_64-linux.
2023-05-22[gdb/testsuite] Factor out Term::_reset_attrsTom de Vries1-12/+14
Factor out new proc Term::_reset_attrs. Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) on x86_64-linux.
2023-05-22Re: readelf: Support SHT_RELR/DT_RELR for -rAlan Modra2-2/+5
Revert value of DT_ENCODING to as it was before commit a7fd118627, and adjust readelf. include/ * elf/common.h (DT_ENCODING): Set back to 32. binutils/ * readelf.c (struct filedata): Don't size dynamic_info array using DT_ENCODING.
2023-05-22PowerPC64 report number of stub iterationsAlan Modra1-4/+4
As a developer it is sometimes useful to know how many times stubs have been resized. Report the count for users too, in ld --stats.
2023-05-22Automatic date update in version.inGDB Administrator1-1/+1
2023-05-21Automatic date update in version.inGDB Administrator1-1/+1
2023-05-20Re: Bug 23686, two segment faults in nmAlan Modra1-1/+1
The fix for pr23686 had a hole in the reloc address sanity check, the calculation could overflow. Note that stabsize is known to be a non-zero multiple of 12 so stabsize - 4 can't underflow. PR 23686 * syms.c (_bfd_stab_section_find_nearest_line): Correct r->address sanity check.
2023-05-20coffcode.h handle_COMDAT tidyAlan Modra1-58/+51
I started down the path of attempting to fix https://sourceware.org/pipermail/binutils/2023-April/127263.html but decided after a while that I didn't want to mess with this code.. This patch is a just a few things that I thought worth doing, the main one being reporting of errors up the call chain. The while loop to for loop change is shamelessly stolen from Oleg. * coffcode.h (handle_COMDAT): Return bool. Make sec_flags a flagword*, and adjust to suit. Replace while loop with for loop. Check isym.n_numaux before reading aux entries. Alloc coff_comdat_info and name in one call to bfd_alloc. Remove goto breakloop. (styp_to_sec_flags): Adjust handle_COMDAT call.
2023-05-20tic54x set_arch_machAlan Modra2-88/+6
The tic54x backend provides its own coff_set_arch_mach, but wants to use the standard coff_set_section_contents. BFD_JUMP_TABLE_WRITE defines both of these functions, so the code also provides a wrapper for coff_set_section_contents. This is all quite OK, but I was on a mission to remove unnecessary declarations in coffcode.h, and on deleting the one for coff_set_arch_mach ran into a warning about the function being unused. I could have kept that declaration with its ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the definition but the latter is not usual and looks odd to me. So I had a closer look at tic54x_set_arch_mach and decided the function is very likely wrong to allow bfd_arch_unknown. Thus the backend should be using the standard coff_set_arch_mach. * coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs. (tic54x_coff_set_arch_mach): Delete. (tic54x_set_section_contents): Delete. * coffcode.h: Delete unnecessary forward declarations.
2023-05-20Automatic date update in version.inGDB Administrator1-1/+1
2023-05-19Update documentation for Python Frame.older and Frame.newerTom Tromey2-3/+5
I noticed that Frame.older and Frame.newer don't document that they return None at the ends of the stack. This patch updates the documentation, and also fixes a somewhat related typo in a comment that I noticed while digging into this. Approved-By: Eli Zaretskii <eliz@gnu.org>
2023-05-19ld: drop stray blank from ld.texiJan Beulich1-1/+1
At least older makeinfo complains about it. Also fix an apparent typo while touching that line.
2023-05-19gdb: fix post-hook execution for remote targetsJan Vrany1-1/+3
Commit b5661ff2 ("gdb: fix possible use-after-free when executing commands") attempted to fix possible use-after-free in case command redefines itself. Commit 37e5833d ("gdb: fix command lookup in execute_command ()") updated the previous fix to handle subcommands as well by using the original command string to lookup the command again after its execution. This fixed the test in gdb.base/define.exp but it turned out that it does not work (at least) for "target remote" and "target extended-remote". The problem is that the command buffer P passed to execute_command () gets overwritten in dont_repeat () while executing "target remote" command itself: #0 dont_repeat () at top.c:822 #1 0x000055555730982a in target_preopen (from_tty=1) at target.c:2483 #2 0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0) at remote.c:5946 #3 0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272 #4 0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490) at target.c:853 #5 0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1) at cli/cli-decode.c:2737 #6 0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688 Therefore the second call to lookup_cmd () at line 697 fails to find command because the original command string is gone. This commit addresses this particular problem by creating a *copy* of original command string for the sole purpose of using it after command execution to lookup the command again. It may not be the most efficient way but it's safer given that command buffer is shared and overwritten in hard-to-foresee situations. Tested on x86_64-linux. PR 30249 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249 Approved-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb: Remove redundant frame switchingRichard Bunt2-6/+12
547ce8f00b fixed an issue where dynamic types were not being resolved correctly prior to printing a value. The same issue was discovered when printing the value using mi-mode, which was not covered by the fix. Porting the fix to the mi-mode code path resolved the issue. However, it was discovered that a later patch series, ending 2fc3b8a4cb8, independently fixed the issue in both the cli- and mi-mode code paths, making the original fix unneeded. This commit removes this extra frame switch and adds test coverage for the mi-mode scenario to protect against any future divergence in this area. GDB built with GCC 11. No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1, Intel 22.1; Platforms: x86_64, aarch64. Approved-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb: safety checks in skip_prologue_using_salAndrew Burgess1-3/+5
While working on the previous patch I reverted this commit: commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff Date: Tue Nov 28 16:23:32 2006 +0000 * symtab.c (find_pc_sect_line): Do not return a line before the start of a symtab. When I re-ran the testsuite I saw some GDB crashes in the tests: gdb.dwarf2/dw2-line-number-zero.exp gdb.dwarf2/dw2-lines.exp gdb.dwarf2/dw2-vendor-extended-opcode.exp GDB was reading beyond the end of an array in the function skip_prologue_using_sal. Now, without the above commit reverted I don't believe that this should ever happen. Reverting the above commit effectively breaks GDB's symtab_and_line lookup, we try to find a result for an address, and return the wrong symtab and line-table. In skip_prologue_using_sal we then walk the line table looking for an appropriate entry, except we never find one, and GDB just keeps going, wandering off the end of the array. However, I think adding extra protection to prevent walking off the end of the array is pretty cheap, and if something does go wrong in the future then this should prevent a random crash. Obviously, I have no reproducer for this, as I said, I don't think this should impact GDB at all, this is just adding a little extra caution. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb/testsuite: test for a function with no line tableAndrew Burgess2-0/+154
This commit adds a test for the following commit: commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff Date: Tue Nov 28 16:23:32 2006 +0000 * symtab.c (find_pc_sect_line): Do not return a line before the start of a symtab. We have been carrying a test for that commit in the Fedora GDB tree since that commit was added to GDB. I don't know why the test wasn't added along with the original commit, but as was written, the test is pretty gross, it uses objcopy to pull the .text section from an object file, which was then injected into another source file within a .asm statement... ... these days we can just make use of the DWARF assembler to achieve the same results, so I've rewritten the test and think it is worth adding this to upstream GDB. The original patch was about about how we find the best symtab and line table entry, and what to do when GDB can't find a good match. The new test creates a CU with two functions, only one of which is covered by the line table. With the above patch reverted GDB returns an invalid address. With the above patch reverted I did run the testsuite to see what other tests might already be exercising this functionality, and I found two tests: gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp gdb.dwarf2/dw2-vendor-extended-opcode.exp These are pretty similar, they either create minimal, or no line table for one of the functions in the source file, and as a consequence GDB returns an unexpected address at some point during the test. However, both of those tests are really focused on other issues, so I think this new test does add some value. Plus the new test is not large, so it's not a huge cost to also run this new test. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb/breakpoint: use warning function instead of gdb_printfAndrew Burgess3-6/+6
Noticed that in breakpoint.c, in one place, we do this: gdb_printf (_("warning: Error removing " "breakpoint %d\n"), old_loc->owner->number); Instead of using the `warning` function. There are a number of differences between using gdb_printf like this and calling `warning`, the main one is probably that real warnings are sent to gdb_stderr, while the above gdb_printf call will go to gdb_stdout. In this commit I: 1. Change to call `warning`, we can drop the "warning: " prefix from the string in breakpoint.c, 2. Update the warning text, I now start with a lower case 'e', which I believe is the GDB style for warnings, 3. And I have included the address of the bp_location in the warning messsage, 4. Finally, I update all the tests (2) that include this error message. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb/testsuite: handle older Python versions in gdb.python/py-disasm.expAndrew Burgess1-5/+15
It was pointed out on the mailing list that the new tests added in this commit: commit 4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1 Date: Tue Jan 24 15:35:45 2023 +0000 gdb/python: extend the Python Disassembler API to allow for styling will fail when GDB is built with Python 3.6 or earlier. This is because the error that is emitted when a function argument is missing changed in Python 3.7, instead of an error like this: Python Exception <class 'TypeError'>: function missing required argument 'style' (pos 1) earlier versions of Python emit: Python Exception <class 'TypeError'>: Required argument 'style' (pos 1) not found and the new tests didn't allow for this. This commit fixes this by allowing either pattern. I've tested this building GDB against Python 3.7.9 and 3.6.15, with this commit all tests in gdb.python/py-disasm.exp now pass.
2023-05-19RISC-V: Support subtraction of .uleb128.Kuan-Lin Chen11-4/+239
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/96d6e190e9fc04a8517f9ff7fb9aed3e9876cbd6 There are some known limitations for now, * Do not shrink the length of the uleb128 value, even if the value is reduced after relaxations. Also reports error if the length grows up. * The R_RISCV_SET_ULEB128 needs to be paired with and be placed before the R_RISCV_SUB_ULEB128. bfd/ * bfd-in2.h: Regenerated. * elfnn-riscv.c (perform_relocation): Perform R_RISCV_SUB_ULEB128 and R_RISCV_SET_ULEB128 relocations. Do not shrink the length of the uleb128 value, and report error if the length grows up. Called the generic functions, _bfd_read_unsigned_leb128 and _bfd_write_unsigned_leb128, to encode the uleb128 into the section contents. (riscv_elf_relocate_section): Make sure that the R_RISCV_SET_ULEB128 must be paired with and be placed before the R_RISCV_SUB_ULEB128. * elfxx-riscv.c (howto_table): Added R_RISCV_SUB_ULEB128 and R_RISCV_SET_ULEB128. (riscv_reloc_map): Likewise. (riscv_elf_ignore_reloc): New function. * libbfd.h: Regenerated. * reloc.c (BFD_RELOC_RISCV_SET_ULEB128, BFD_RELOC_RISCV_SUB_ULEB128): New relocations to support .uleb128 subtraction. gas/ * config/tc-riscv.c (md_apply_fix): Added BFD_RELOC_RISCV_SET_ULEB128 and BFD_RELOC_RISCV_SUB_ULEB128. (s_riscv_leb128): Updated to allow uleb128 subtraction. (riscv_insert_uleb128_fixes): New function, scan uleb128 subtraction expressions and insert fixups for them. (riscv_md_finish): Called riscv_insert_uleb128_fixes for all sections. include/ * elf/riscv.h ((R_RISCV_SET_ULEB128, (R_RISCV_SUB_ULEB128): Defined. ld/ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. * testsuite/ld-riscv-elf/uleb128*: New testcase for uleb128 subtraction. binutils/ * testsuite/binutils-all/nm.exp: Updated since RISCV supports .uleb128.
2023-05-19RISC-V: Minor improvements for dis-assembler.Nelson Chu3-21/+40
* Extract all private_data initializations into riscv_init_disasm_info, which called from print_insn_riscv rather than riscv_disassemble_insn. * The disassemble_free_target seems like the right place to release all target private_data, also including the internal data structures, like riscv_subsets. Therefore, add a new function, disassemble_free_riscv, to release them for safe. opcodes/ * disassemble.c (disassemble_free_target): Called disassemble_free_riscv for riscv to release private_data and internal data structures. * disassemble.h: Added extern disassemble_free_riscv. * riscv-dis.c (riscv_init_disasm_info): New function, used to init riscv_private_data. (riscv_disassemble_insn): Moved riscv_private_data initializations into riscv_init_disasm_info. (print_insn_riscv): Called riscv_init_disasm_info to init riscv_private_data once time. (disassemble_free_riscv): New function, used to free the internal data structures, like riscv_subsets.
2023-05-19x86: permit all relational operators in insn operandsJan Beulich4-1/+29
Oddly enough == and != were not permitted, because of '=' not having been listed in operand_special_chars[].
2023-05-19x86: further adjust extend-to-32bit-address conditionsJan Beulich8-6/+192
While a442cac5084e ("ix86: wrap constants") helped address a number of inconsistencies between BFD64 and !BFD64 builds, it has also resulted in certain bogus uses of constants to no longer be warned about. Leverage the md_optimize_expr() hook to adjust when to actually truncate expressions to 32 bits - any involvement of binary expressions (which would be evaluated in 32 bits only when !BFD64) signals the need for doing so. Plain constants (or ones merely subject to unary operators) should remain un-truncated - they would be handled as bignums when !BFD64, and hence are okay to permit. To compensate - slightly extend optimize_imm() (to be honest I never understood why the code being added - or something similar - wasn't there in the first place), - adjust expectations of the disp-imm-32 testcase (there are now warnings, as there should be for any code which won't build [warning- free] when !BFD64, and Disp8/Imm8 are no longer used in the warned about cases).
2023-05-19gas: invoke md_optimize_expr() also for unary expressionsJan Beulich4-22/+40
Give backends a chance to see these, just as they can see binary ones. Most of those which use this hook already cope with NULL being passed for the left operand (typically because of checking the operator first). Adjust the two which don't. Take the opportunity and also document the hook.
2023-05-19gas: maintain O_constant signedness in more casesJan Beulich9-12/+73
Unary '~' doesn't really produce an unsigned result. Neither does subtraction (unless taking operand values into consideration). And an abstract operator applied to two operands which aren't both unsigned can't be assumed to yield an unsigned result; exceptions are - shifts, where only signedness of the left hand operand matters, - comparisons, which - unlike unary '!' - produce signed results (they deliver 0 or ~0, as opposed to '!', which yields 0 or 1), - logical operators (yielding 0 or 1 and hence treated like unary '!'). While doing this (specifically while extending the all/quad testcase), update .quad and .8byte documentation: With 64-bit architectures now being common, it is highly inappropriate to state that these directives unconditionally require bignums.
2023-05-19x86: tighten extend-to-32bit-address conditionsJan Beulich1-2/+2
In a442cac5084e ("ix86: wrap constants") I made the truncation condition too relaxed: Any indication of a mode that's possible with BFD64 only should avoid the truncation. Therefore, like in the other two cases of calls to extend_to_32bit_address(), also check whether we're generating a 64-bit object.
2023-05-19Automatic date update in version.inGDB Administrator1-1/+1
2023-05-18Use lower-case in @sc in the documentationTom Tromey2-19/+19
Eli pointed out that @sc only produces small caps for lower case letters in its argument, so it's weird to write it using upper-case letters. This patch fixes the instances I found. Approved-By: Eli Zaretskii <eliz@gnu.org>
2023-05-18gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function ↵Simon Marchi2-68/+18
parameters (PR 30414) gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound values by reading some output from the inferior. This is racy when running on boards where the inferior I/O is on a separate TTY than GDB's, such as native-gdbserver. I sometimes see this behavior: (gdb) continue Continuing. Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45 45 print *, "" ! Test Breakpoint (gdb) Remote debugging from host ::1, port 37496 Expected GDB Output: LBOUND = (-8, -10) UBOUND = (-1, -2) APB: Run a test here APB: Expected lbound '(-8, -10)' APB: Expected ubound '' What happened is that expect read the output from GDB before the output from the inferior, triggering this gdb_test_multiple clause: -re "$gdb_prompt $" { set found_prompt true if {$found_dealloc_breakpoint || ($expected_lbound != "" && $expected_ubound != "")} { # We're done. } else { exp_continue } } So it set found_prompt, but the gdb_test_multiple kept going because found_dealloc_breakpoint is false (this is the flag indicating that the test is finished) and we still don't have expected_lbound and expected_ubound. Then, expect reads in the inferior I/O, triggering this clause: -re ".*LBOUND = (\[^\r\n\]+)\r\n" { set expected_lbound $expect_out(1,string) if {!$found_prompt} { exp_continue } } This sets expected_lbound, but since found_prompt is true, we don't do exp_continue, and exit the gdb_test_multiple, without having an expected_ubound. Change the test to read the values from the lb and ub function parameters instead. As far as I understand, this still exercises what we want to test. These variables contain the return values of the lbound and ubound functions as computed by the program. We'll use them to check the return values of the lbound and ubound functions as computed by GDB. Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414
2023-05-18gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_Hui Li1-0/+3
In the current code, when execute the following test on LoongArch: $ make check-gdb TESTS="gdb.base/gnu-ifunc.exp" === gdb Summary === # of expected passes 111 # of unexpected failures 62 According to IFUNC's working process [1]. first time the IFUNC function is called, the dynamic linker will not simply fill the .got.plt entry with the actual address of IFUNC symbol, it will call the IFUNC resolver function and take the return address, uses it as the sym-bound address and puts it in the .got.plt entry. Initial address in .got.plt entry is not a real function addresss. Depending on the compiler implementation, some different addresses will be filled in. Most architectures will use a .plt entry address to fill in the corresponding .got.plt entry. In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real IFUNC function addresss. First check to see if the real address for the IFUNC symbol has been resolved by the following function: elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p) { if (elf_gnu_ifunc_resolve_by_cache (name, addr_p)) return true; if (elf_gnu_ifunc_resolve_by_got (name, addr_p)) return true; return false; } in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the .got.plt entry and determines if the contents is the correct address by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working principle analysis above, the address filled in the .got.plt entry is not the actual target function address initially, it would be a .plt entry address corresponding symbol like *@plt. In this case, gdb just go back to execute the resolver function and puts the return address in the .got.plt entry. After that, gdb can get a real ifun address via .got.plt entry. On LoongArch, initially, each address filled in the .got.plt entries is the first .plt entry address. Some architectures such as LoongArch define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt section. This symbol is the first plt entry, so gdb needs to check this symbol in elf_gnu_ifunc_record_cache(). On LoongArch .got.plt and .plt section as follow: $objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0 ... 0000000120010008 <.got.plt>: 120010008: ffffffff 0xffffffff 12001000c: ffffffff 0xffffffff ... 120010018: 20004000 ll.w $zero, $zero, 64(0x40) 12001001c: 00000001 0x00000001 120010020: 20004000 ll.w $zero, $zero, 64(0x40) 120010024: 00000001 0x00000001 120010028: 20004000 ll.w $zero, $zero, 64(0x40) 12001002c: 00000001 0x00000001 120010030: 20004000 ll.w $zero, $zero, 64(0x40) 120010034: 00000001 0x00000001 ... Disassembly of section .plt: 0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>: 120004000: 1c00018e pcaddu12i $t2, 12(0xc) 120004004: 0011bdad sub.d $t1, $t1, $t3 120004008: 28c021cf ld.d $t3, $t2, 8(0x8) 12000400c: 02ff51ad addi.d $t1, $t1, -44(0xfd4) 120004010: 02c021cc addi.d $t0, $t2, 8(0x8) 120004014: 004505ad srli.d $t1, $t1, 0x1 120004018: 28c0218c ld.d $t0, $t0, 8(0x8) 12000401c: 4c0001e0 jirl $zero, $t3, 0 0000000120004020 <__libc_start_main@plt>: 120004020: 1c00018f pcaddu12i $t3, 12(0xc) 120004024: 28ffe1ef ld.d $t3, $t3, -8(0xff8) 120004028: 4c0001ed jirl $t1, $t3, 0 12000402c: 03400000 andi $zero, $zero, 0x0 0000000120004030 <abort@plt>: 120004030: 1c00018f pcaddu12i $t3, 12(0xc) 120004034: 28ffc1ef ld.d $t3, $t3, -16(0xff0) 120004038: 4c0001ed jirl $t1, $t3, 0 12000403c: 03400000 andi $zero, $zero, 0x0 0000000120004040 <gnu_ifunc@plt>: 120004040: 1c00018f pcaddu12i $t3, 12(0xc) 120004044: 28ffa1ef ld.d $t3, $t3, -24(0xfe8) 120004048: 4c0001ed jirl $t1, $t3, 0 12000404c: 03400000 andi $zero, $zero, 0x0 ... With this patch: $make check-gdb TESTS="gdb.base/gnu-ifunc.exp" === gdb Summary === #of expected passes 173 [1] https://sourceware.org/glibc/wiki/GNU_IFUNC Signed-off-by: Hui Li <lihui@loongson.cn>
2023-05-18Re: Add section caches to coff_data_typeAlan Modra2-0/+5
Another thing, section target_index is renumbered in coff_compute_section_file_positions and _bfd_xcoff_bfd_final_link. I don't know that there is currently any way that the output bfd section_by_target_index could be populated before this point but clear them out so no one need worry about it. * coffcode.h (coff_compute_section_file_positions): Clear section_by_target_index hash table when changing target_index. (_bfd_xcoff_bfd_final_link): Likewise.
2023-05-18[gdb/testsuite] Fix whitespace and indentation in lib/tuiterm.expTom de Vries1-48/+48
I noticed a trailing whitespace and some indentation errors in lib/tuiterm.exp. Fix these. Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) on x86_64-linux.
2023-05-17libsframe: testsuite: add tests for sframe_get_funcdesc_with_addr APIIndu Bhagat4-5/+252
sframe_get_funcdesc_with_addr API is currently used internally by the sframe_find_fre (). In this test, we create three dummy SFrame FDEs with 4 FREs each. Then, we use few negative tests to lookup FREs with PCs not in the range of PCs covered by the FDEs, ensuring graceful return from sframe_get_funcdesc_with_addr in all cases. Some positive tests are also added that exercise further scenarios as well. libsframe/ * Makefile.in: Regenerated. * testsuite/libsframe.find/find.exp: Include new test. * testsuite/libsframe.find/findfunc-1.c: New Test. * testsuite/libsframe.find/local.mk: Include new test.
2023-05-17libsframe: testsuite: add new tests for sframe_find_fre APIIndu Bhagat5-10/+250
libsframe provides an API to find the FRE associated with a given PC in the program. This patch adds a direct test of this API. In this test, we create two dummy SFrame FDEs with 4 FREs each. Then we test that sframe_find_fre () works for the first, second, third and the last FRE from one of the FDEs. Such a test ensures better regression testing for the sframe_find_fre () function which is going to be the bread and butter of an SFrame based stack tracer. libsframe/ * Makefile.in: Regenerated. * testsuite/libsframe.find/find.exp: New test. * testsuite/libsframe.find/findfre-1.c: New test. * testsuite/libsframe.find/local.mk: Build new test. * testsuite/local.mk: Include libsframe.find.
2023-05-18Re: Add section caches to coff_data_typeAlan Modra4-84/+57
Commit 0e759f232b6d regressed these tests: rs6000-aix7.2 +FAIL: Garbage collection test 1 (32-bit) rs6000-aix7.2 +FAIL: Garbage collection test 1 (64-bit) rs6000-aix7.2 +FAIL: Glink test 1 (32-bit) rs6000-aix7.2 +FAIL: Glink test 1 (64-bit) Investigation showed segfaults in coff_section_from_bfd_index called by xcoff_write_global_symbol due to the hash table pointer being NULL. Well, yes, the hash table isn't initialised for the output bfd. mkobject_hook is the wrong place to do that. * coffcode.h: Revert 0e759f232b6d changes. * peicode.h: Likewise. * coff-x86_64.c (htab_hash_section_index, htab_eq_section_index): Moved here from coffcode.h. (coff_amd64_rtype_to_howto): Create section_by_index htab. * coffgen.c (htab_hash_section_target_index), (htab_eq_section_target_index): Moved here from coffcode.h. (coff_section_from_bfd_index): Create section_by_target_index htab. Stash newly created sections in htab.
2023-05-18PR11601, Solaris assembler compatibility doesn't workAlan Modra2-1/+5
Well, it doesn't work on x86 or ppc, which both have # starting comments anywhere on a line. I think it is therefore only useful on sparc. PR 11601 * config/obj-elf.c (obj_elf_section_word): Only compile for sparc. (obj_elf_section): Only support solaris .section directive on sparc. * doc/as.texi (Section): Mention that solaris .section directive is only supported for sparc.
2023-05-18Automatic date update in version.inGDB Administrator1-1/+1
2023-05-17Special case "&str" in Rust parserTom Tromey2-0/+13
"&str" is an important type in Rust -- it's the type of string literals. However, the compiler puts it in the DWARF in a funny way. The slice itself is present and named "&str". However, the Rust parser doesn't look for types with names like this, but instead tries to construct them from components. In this case it tries to make a pointer-to-"str" -- but "str" isn't always available, and in any case that wouldn't yield the best result. This patch adds a special case for &str. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-17Decorated symbols in import libs (BUG 30421)Luca Bacci8-9/+160
PR 30421 * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it. * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype. * libcoff.h: Regenerate. * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function. * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function. * pe-dll.c (make_one): Check for decoated symbols.
generated by cgit v1.1 at 2025-01-31 01:35:28 +0000