aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-17gdb: fix thread_step_over_chain_lengthSimon Marchi1-1/+1
If I debug a single-thread program and look at the infrun debug logs, I see: [infrun] start_step_over: stealing global queue of threads to step, length = 2 That makes no sense... turns out there's a buglet in thread_step_over_chain_length, "num" should be initialized to 0. I think this bug is a leftover from an earlier version of the code (not merged upstream) that manually walked the list, where the first item was implicitly counted (hence the 1). Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
2021-08-17opcodes: Fix the auxiliary register numbers for ARC HSShahab Vahedi2-2/+6
The numbers for the auxiliary registers "tlbindex" and "tlbcommand" of ARCv2HS are incorrect. This patch makes the following changes to correct that error. ,------------.-----------------.---------------. | aux. reg. | old (incorrect) | new (correct) | |------------+-----------------+---------------| | tlbindex | 0x463 | 0x464 | | tlbcommand | 0x464 | 0x465 | `------------^-----------------^---------------' opcodes/ 2021-08-17 Shahab Vahedi <shahab@synopsys.com> * arc-regs.h (DEF): Fix the register numbers.
2021-08-17gdb: Don't assume r_ldsomap when r_version > 1 on LinuxH.J. Lu27-32/+97
The r_ldsomap field is specific to Solaris (part of librtld_db), and should never be accessed for Linux. glibc is planning to add a field to support multiple namespaces. But there will be no r_ldsomap when r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets to set r_ldsomap_offset to -1 and use them for Linux targets. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
2021-08-17gdbserver: Check r_version < 1 for Linux debugger interfaceH.J. Lu1-1/+1
Update gdbserver to check r_version < 1 instead of r_version != 1 so that r_version can be bumped for a new field in the glibc debugger interface to support multiple namespaces. Since so far, the gdbserver only reads fields defined for r_version == 1, it is compatible with r_version >= 1. All future glibc debugger interface changes will be backward compatible. If there is ever the need for backward incompatible change to the glibc debugger interface, a new DT_XXX element will be provided to access the new incompatible interface. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11839
2021-08-17PATCH [4/4] arm: Add Tag_PACRET_use build attributeAndrea Corallo5-0/+9
bfd/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 'Tag_PACRET_use' case. binutils/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * readelf.c (arm_attr_tag_PAC_extension): Declare. (arm_attr_public_tags): Add 'PAC_extension' lookup. elfcpp/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * arm.h: Define 'Tag_PACRET_use' enum. gas/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * config/tc-arm.c (arm_convert_symbolic_attribute): Add 'Tag_PACRET_use' to the attribute_table. include/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PACRET_use'.
2021-08-17PATCH [3/4] arm: Add Tag_BTI_use build attributeAndrea Corallo5-0/+9
bfd/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 'Tag_BTI_use' case. binutils/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * readelf.c (arm_attr_tag_PAC_extension): Declare. (arm_attr_public_tags): Add 'PAC_extension' lookup. elfcpp/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * arm.h: Define 'Tag_BTI_use' enum. gas/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * config/tc-arm.c (arm_convert_symbolic_attribute): Add 'Tag_BTI_use' to the attribute_table. include/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_use'.
2021-08-17PATCH [2/4] arm: Add Tag_BTI_extension build attributeAndrea Corallo5-0/+10
bfd/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 'Tag_BTI_extension' case. binutils/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * readelf.c (arm_attr_tag_PAC_extension): Declare. (arm_attr_public_tags): Add 'PAC_extension' lookup. elfcpp/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * arm.h: Define 'Tag_BTI_extension' enum. gas/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * config/tc-arm.c (arm_convert_symbolic_attribute): Add 'Tag_BTI_extension' to the attribute_table. include/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_extension'.
2021-08-17PATCH [1/4] arm: Add Tag_PAC_extension build attributeAndrea Corallo5-0/+10
bfd/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add 'Tag_PAC_extension' case. binutils/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * readelf.c (arm_attr_tag_PAC_extension): Declare. (arm_attr_public_tags): Add 'PAC_extension' lookup. elfcpp/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * arm.h: Define 'Tag_PAC_extension' enum. gas/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * config/tc-arm.c (arm_convert_symbolic_attribute): Add 'Tag_PAC_extension' to the attribute_table. include/ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com> * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PAC_extension'.
2021-08-17x86: Always run fp testsH.J. Lu4-208/+1
Always run fp tests since the size of .tfloat, .ds.x, .dc.x and .dcb.x directive outputs is always 10 bytes. There is no need for fp-elf32 nor fp-elf64. PR gas/28230 * testsuite/gas/i386/fp-elf32.d: Removed. * testsuite/gas/i386/fp-elf64.d: Likewise. * testsuite/gas/i386/fp.s: Remove NO_TFLOAT_PADDING codes. * testsuite/gas/i386/i386.exp: Don't run fp-elf32 nor fp-elf64. Always run fp.
2021-08-17Automatic date update in version.inGDB Administrator1-1/+1
2021-08-16x86: Don't pad .tfloat directive outputH.J. Lu5-15/+127
.tfloat output should always be 10 bytes without padding, independent of psABIs. In glibc, x86 assembly codes expect 10-byte .tfloat output. This also reduces .ds.x output and .tfloat output with hex input from 12 bytes to 10 bytes to match .tfloat output. PR gas/28230 * NEWS: Mention changes of .ds.x output and .tfloat output with hex input. * config/tc-i386.c (x86_tfloat_pad): Removed. * config/tc-i386.h (X_PRECISION_PAD): Changed to 0. (x86_tfloat_pad): Removed. * testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined, add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x directives. * testsuite/gas/i386/i386.exp (ASFLAGS): Append "--defsym NO_TFLOAT_PADDING=1" when running the fp test.
2021-08-16Fix register regression in DWARF evaluatorTom Tromey1-1/+3
On an internal test case, using an arm-elf target, commit ba5bc3e5a92 ("Make DWARF evaluator return a single struct value") causes a regression. (It doesn't happen for any of the other cross targets that I test when importing upstream gdb.) I don't know if there's an upstream gdb test case showing the same problem... I can only really run native tests with dejagnu AFAIK. The failure manifests like this: Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5 Whereas when it works it looks like: Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5 The difference is that the new code uses the passed-in gdbarch, whereas the old code used the frame's gdbarch, when handling DWARF_VALUE_REGISTER. This patch restores the use of the frame's arch.
2021-08-16Fix Ada regression due to DWARF expression seriesTom Tromey1-1/+3
Commit 0579205aec4 ("Simplify dwarf_expr_context class interface") caused a regression in the internal AdaCore test suite. I didn't try to reproduce this with the GDB test suite, but the test is identical to gdb.dwarf2/dynarr-ptr.exp. The problem is that this change: case DW_OP_push_object_address: /* Return the address of the object we are currently observing. */ - if (this->data_view.data () == nullptr - && this->obj_address == 0) + if (this->m_addr_info == nullptr) ... slightly changes the logic here. In particular, it's possible for the caller to pass in a non-NULL m_addr_info, but one that looks like: (top) p *this.m_addr_info $15 = { type = 0x29b7a70, valaddr = { m_array = 0x0, m_size = 0 }, addr = 0, next = 0x0 } In this case, an additional check is needed. With the current code, what happens instead is that the computation computes an incorrect address -- but one that does not fail in read_memory, due to the precise memory map of the embedded target in question. This patch restores the old logic.
2021-08-16Notify observer of breakpoint auto-disablingPatrick Monnerat3-1/+65
As breakpoint_modified observer is currently notified upon breakpoint stop before handling auto-disabling when enable count is reached, the observer is never notified of the disabling. The problem affects: - The MI interpreter enabled= value when reporting =breakpoint-modified - A Python event handler for breakpoint_modified using the "enabled" member of its parameter - insight: breakpoint GUI window is not properly updated upon auto-disable This patch moves the observer notification after the auto-disabling code and implements corresponding tests for the MI and Python cases. Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=23336 Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61
2021-08-16as: Replace the removed symbol with the versioned symbolH.J. Lu8-10/+103
When a symbol removed by .symver is used in relocation and there is one and only one versioned symbol, don't remove the symbol. Instead, mark it to be removed and replace the removed symbol used in relocation with the versioned symbol before generating relocation. PR gas/28157 * symbols.c (symbol_flags): Add removed. (symbol_entry_find): Updated. (symbol_mark_removed): New function. (symbol_removed_p): Likewise. * symbols.h (symbol_mark_removed): New prototype. (symbol_removed_p): Likewise. * write.c (write_relocs): Call obj_fixup_removed_symbol on removed fixp->fx_addsy and fixp->fx_subsy if defined. (set_symtab): Don't add a symbol if symbol_removed_p returns true. * config/obj-elf.c (elf_frob_symbol): Don't remove the symbol if it is used on relocation. Instead, mark it as to be removed and issue an error if the symbol has more than one versioned name. (elf_fixup_removed_symbol): New function. * config/obj-elf.h (elf_fixup_removed_symbol): New prototype. (obj_fixup_removed_symbol): New. * testsuite/gas/symver/symver11.d: Updated expected error message. * testsuite/gas/symver/symver16.d: New file. * testsuite/gas/symver/symver16.s: Likewise.
2021-08-16Automatic date update in version.inGDB Administrator1-1/+1
2021-08-15Automatic date update in version.inGDB Administrator1-1/+1
2021-08-14ld script fill pattern expressionAlan Modra2-3/+27
It turns out we do need to backtrack when parsing after all. The fill_opt component in the section rule swiches to EXPRESSION and back to SCRIPT, and to find the end of an expression it is necessary to look ahead one token. * ldgram.y (section): Throw away lookahead NAME token. (overlay_section): Likewise. * testsuite/ld-elf/overlay.t: Add fill pattern on overlays. Test fill pattern before stupidly named normal sections too, and before /DISCARD/.
2021-08-14Automatic date update in version.inGDB Administrator1-1/+1
2021-08-13ld lexer tidy, possibly break the worldAlan Modra2-129/+140
This tidies the states in which ld lexer rules are enabled. This change will quite likely trip over issues similar to those mentioned in the new ldlex.l comments, so please test it out. * ldgram.y (wildcard_name): Remove now unnecessary components. * ldlex.l: Restrict many rules' states. Remove -l expression state rule. Comment on lookahead state madness and need for /DISCARD/ in expression state.
2021-08-13ld script lower-case absolute and sizeof_headersAlan Modra3-5/+4
I think these happened by accident, so let's see what breaks if they are removed. * ldlex.l: Remove lower case "absolute" and "sizeof_headers" in non-mri mode. * ld.texi: Remove sizeof_headers index. * testsuite/ld-mmix/mmohdr1.ld: Use SIZEOF_HEADERS.
2021-08-13tidy mri script externAlan Modra1-10/+5
MRI mode generally doesn't flip lexer states, so let's make MRI mode "extern" not do so either. * ldgram.y (extern_name_list): Don't change lex state here. (ifile_p1): Change state here on EXTERN instead.
2021-08-13Re: PR28217, Syntax error when memory region contains a hyphenAlan Modra1-10/+3
I discovered some more errors when tightening up the lexer rules. Just because we INCLUDE a file doesn't mean we've switched states. PR 28217 * ldgram.y (statement): Don't switch lexer state on INCLUDE. (mri_script_command, ifile_p1, memory_spec, section): Likewise.
2021-08-13PR28168: [CSKY] Fix stack overflow in disassemblerLifang Xia4-12/+25
PR 28168: Stack overflow with a large float. %f is not a goot choice for this. %f should be replaced with %.7g. gas/ * testsuite/gas/csky/pr28168.d: New testcase for PR 28168. * testsuite/gas/csky/pr28168.s: Likewise. * testsuite/gas/csky/v2_float_part2.d: Following the new format. * opcodes/csky-dis.c (csky_output_operand): %.7g replaces %f.
2021-08-13PR28217, Syntax error when memory region contains a hyphenAlan Modra4-184/+171
The saga of commit 40726f16a8d7 continues. This attacks the problem of switching between SCRIPT and EXPRESSION state lexing by removing the need to do so for phdrs like ":text". Instead {WILDCHAR}* matching, the reason why ":text" lexed as one token, is restricted to within the braces of a section or overlay statement. The new WILD lexer state is switched at the non-optional brace tokens, so ldlex_backup is no longer needed. I've also removed the BOTH state, which doesn't seem to be needed any more. Besides rules involving error reporting, there was just one place where SCRIPT appeared without BOTH, the {WILDCHAR}* rule, three where BOTH appears without SCRIPT for tokens that only need EXPRESSION state, and two where BOTH appears alongside INPUT_LIST. (Since I'm editing the wild and filename rules, removing BOTH and adding WILD can also be seen as renaming the old BOTH state to SCRIPT and renaming the old SCRIPT state to WILD with a reduced scope.) As a followup, I'll look at removing EXPRESSION state from some lexer rules that no longer need it due to this cleanup. PR 28217 * ldgram.y (exp <ORIGIN, LENGTH>): Use paren_script_name. (section): Parse within braces of section in wild mode, and after brace back in script mode. Remove ldlex_backup call. Similarly for OVERLAY. (overlay_section): Similarly. (script_file): Replace ldlex_both with ldlex_script. * ldlex.h (ldlex_wild): Declare. (ldlex_both): Delete. * ldlex.l (BOTH): Delete. Remove state from all rules. (WILD): New state. Enable many tokens in this state. Enable filename match in SCRIPT mode. Enable WILDCHAR match in WILD state, disable in SCRIPT mode. (ldlex_wild): New function. * ldfile.c (ldfile_try_open_bfd): Replace ldlex_both call with ldlex_script.
2021-08-13ns32k configuryAlan Modra2-2/+5
Since ns32k-netbsd is as yet not removed, just marked obsolete, the target should still be accepted with --enable-obsolete. I also enabled ns32k-openbsd in ld since there doesn't seem to be a good reason why that target is not supported there but is elsewhere. bfd/ * config.bfd: Allow ns32k-netbsd. ld/ * configure.tgt: Allow ns32k-openbsd.
2021-08-13Automatic date update in version.inGDB Administrator1-1/+1
2021-08-12gdb: riscv_scan_prologue: handle LD and LW instructionsLancelot SIX4-0/+182
While working on the testsuite, I ended up noticing that GDB fails to produce a full backtrace from a thread waiting in pthread_join. When selecting the waiting thread and using the 'bt' command, the following result can be observed: (gdb) bt #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 Backtrace stopped: frame did not save the PC On my platform, I do not have debug symbols for glibc, so I need to rely on prologue analysis in order to unwind stack. Here is what the function prologue looks like: (gdb) disassemble __pthread_clockjoin_ex Dump of assembler code for function __pthread_clockjoin_ex: 0x0000003ff7fc42de <+0>: addi sp,sp,-144 0x0000003ff7fc42e0 <+2>: sd s5,88(sp) 0x0000003ff7fc42e2 <+4>: auipc s5,0xd 0x0000003ff7fc42e6 <+8>: ld s5,-2(s5) # 0x3ff7fd12e0 0x0000003ff7fc42ea <+12>: ld a5,0(s5) 0x0000003ff7fc42ee <+16>: sd ra,136(sp) 0x0000003ff7fc42f0 <+18>: sd s0,128(sp) 0x0000003ff7fc42f2 <+20>: sd s1,120(sp) 0x0000003ff7fc42f4 <+22>: sd s2,112(sp) 0x0000003ff7fc42f6 <+24>: sd s3,104(sp) 0x0000003ff7fc42f8 <+26>: sd s4,96(sp) 0x0000003ff7fc42fa <+28>: sd s6,80(sp) 0x0000003ff7fc42fc <+30>: sd s7,72(sp) 0x0000003ff7fc42fe <+32>: sd s8,64(sp) 0x0000003ff7fc4300 <+34>: sd s9,56(sp) 0x0000003ff7fc4302 <+36>: sd a5,40(sp) As far as prologue analysis is concerned, the most interesting part is done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores the RA (return address) register on the stack, which is the information we are looking for in order to identify the caller. In the current implementation of the prologue scanner, GDB stops when hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do with the 'ld' instruction. GDB thinks it reached the end of the prologue but have not yet reached the important part, which explain GDB's inability to unwind past this point. The section of the prologue starting at <+4> until <+12> is used to load the stack canary[1], which will then be placed on the stack at <+36> at the end of the prologue. In order to have the prologue properly handled, this commit proposes to add support for the ld instruction in the RISC-V prologue scanner. I guess riscv32 would use lw in such situation so this patch also adds support for this instruction. With this patch applied, gdb is now able to unwind past pthread_join: (gdb) bt #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0 #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0 #2 0x0000002aaaaaa88e in bar() () #3 0x0000002aaaaaa8c4 in foo() () #4 0x0000002aaaaaa8da in main () I have had a look to see if I could reproduce this easily, but in my simple testcases using '-fstack-protector-all', the canary is loaded after the RA register is saved. I do not have a reliable way of generating a prologue similar to the problematic one so I forged one instead. The testsuite have been run on riscv64 ubuntu 21.01 with no regression observed. [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
2021-08-12Update documentation to mention PygmentsTom Tromey1-4/+10
Philippe Blain pointed out that the gdb documentation does not mention that Pygments may be used for source highlighting. This patch updates the docs to reflect how highlighting is actually done.
2021-08-12gdb: make gdbarch_printable_names return a vectorSimon Marchi5-73/+54
I noticed that gdbarch_selftest::operator() leaked the value returned by gdbarch_printable_names. Make gdbarch_printable_names return an std::vector and update callers. That makes it easier for everyone involved, less manual memory management. Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
2021-08-12Improve forward progress test in python.expCarl Love1-1/+16
The test steps into func2 and than does an up to get back to the previous frame. The test checks that the line number you are at after the up command is greater than the line where the function was called from. The assembly/codegen for the powerpc target includes a NOP after the branch-link. func2 (); /* Break at func2 call site. / 10000694: 59 00 00 48 bl 100006ec 10000698: 00 00 00 60 nop return 0; / Break to end. */ 1000069c: 00 00 20 39 li r9,0 The PC at the instruction following the branch-link is 0x10000698 which GDB.find_pc_line() maps to the same line number as the bl instruction. GDB did move past the branch-link location thus making forward progress. The following proposed fix adds an additional PC check to see if forward progress was made. The line test is changed from greater than to greater than or equal.
2021-08-12gdb:csky rm tdesc_has_registers in csky_register_nameJiangshuai Li1-3/+0
As CSKY arch has not parsed target-description.xml in csky_gdbarch_init, when a remote server, like csky-qemu or gdbserver, send a target-description.xml to gdb, tdesc_has_registers will return ture, but tdesc_register_name (gdbarch, 0) will return NULL, so a cmd "info registers r0" will not work. Function of parsing target-description.xml will be add later for CSKY arch, now it is temporarily removed to allow me to do other supported tests. 2021-07-15 Jiangshuai Li <jiangshuai_li@c-sky.com> * csky-tdep.c : not using tdesc funtions in csky_register_name
2021-08-12Re: gas: support NaN flavorsAlan Modra2-1/+10
Fixes tic4x-coff FAIL: simple FP constants * testsuite/gas/all/float.s: Make NaN tests conditional on hasnan. * testsuite/gas/all/gas.exp: Define hasnan.
2021-08-12Automatic date update in version.inGDB Administrator1-1/+1
2021-08-11ld: Update the pass and fail strings of PR ld/28138 testH.J. Lu1-4/+4
PR ld/28138 * testsuite/ld-plugin/lto.exp: Update the pass and fail strings of PR ld/28138 test to indicate which part of the test passed and failed.
2021-08-11Fix a typo in the RX asse,bler. The Double-precision floating-point ↵Darius Galis5-4/+11
exception handling control register name is DECNT not DCENT. * config/rx-parse.y (DECNT): Fixed typo. * testsuite/gas/rx/dpopm.sm (DECNT): Fixed typo. * testsuite/gas/rx/dpushm.sm (DECNT): Fixed typo. * testsuite/gas/rx/macros.inc (DECNT): Fixed typo.
2021-08-11Fix an internal error in the CSKY assembler when asked to resolve an ↵Nick Clifton2-1/+8
overlarge constant. PR 28215 * config/tc-csky.c (md_apply_fix): Correctly handle a fixup that involves an overlarge constant.
2021-08-11Add 3 new PAC-related ARM note typesLuis Machado2-0/+15
The following patch synchronizes includes/objdump/readelf with the Linux Kernel in terms of ARM regset notes. We're currently missing 3 of them: NT_ARM_PACA_KEYS NT_ARM_PACG_KEYS NT_ARM_PAC_ENABLED_KEYS We don't need GDB to bother with this at the moment, so this doesn't update bfd/elf.c. If needed, we can do it in the future. binutils/ * readelf.c (get_note_type): Handle new ARM PAC notes. include/elf/ * common.h (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) (NT_ARM_PAC_ENABLED_KEYS): New constants.
2021-08-11Updated Portuguese translation for the binutils sub-directory.Nick Clifton2-2707/+3860
2021-08-11Deprecate a.out support for NetBSD targets.John Ericson26-4579/+4604
As discussed previously, a.out support is now quite deprecated, and in some cases removed, in both Binutils itself and NetBSD, so this legacy default makes little sense. `netbsdelf*` and `netbsdaout*` still work allowing the user to be explicit about there choice. Additionally, the configure script warns about the change as Nick Clifton requested. One possible concern was the status of NetBSD on NS32K, where only a.out was supported. But per [1] NetBSD has removed support, and if it were to come back, it would be with ELF. The binutils implementation is therefore marked obsolete, per the instructions in the last message. With that patch and this one applied, I have confirmed the following: --target=i686-unknown-netbsd --target=i686-unknown-netbsdelf builds completely --target=i686-unknown-netbsdaout properly fails because target is deprecated. --target=vax-unknown-netbsdaout builds completely except for gas, where the target is deprecated. [1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html --- bfd/config.bfd | 43 +++++++++++++-------- bfd/configure.ac | 5 +-- binutils/testsuite/binutils-all/nm.exp | 2 +- binutils/testsuite/lib/binutils-common.exp | 7 +--- config/picflag.m4 | 4 +- gas/configure.tgt | 9 +++-- gas/testsuite/gas/arm/blx-bl-convert.d | 2 +- gas/testsuite/gas/arm/blx-local-thumb.d | 2 +- gas/testsuite/gas/sh/basic.exp | 2 +- gdb/configure.host | 34 +++++++---------- gdb/configure.tgt | 2 +- gdb/testsuite/gdb.asm/asm-source.exp | 6 +-- intl/configure | 2 +- ld/configure.tgt | 44 +++++++++++----------- ld/testsuite/ld-arm/arm-elf.exp | 4 +- ld/testsuite/ld-elf/elf.exp | 2 +- ld/testsuite/ld-elf/shared.exp | 4 +- libiberty/configure | 4 +-
2021-08-11gdb: don't print backtrace when dumping core after an internal errorAndrew Burgess2-0/+41
Currently, when GDB hits an internal error, and the user selects to dump core, the recently added feature to write a backtrace to the console will kick in, and print a backtrace as well as dumping the core. This was certainly not my intention when adding the backtrace on fatal signal functionality, this feature was intended to produce a backtrace when GDB crashes due to some fatal signal, internal errors should have continued to behave as they did before, unchanged. In this commit I set the signal disposition of SIGABRT back to SIG_DFL just prior to the call to abort() that GDB uses to trigger the core dump, this prevents GDB reaching the code that writes the backtrace to the console. I've also added a test that checks we don't see a backtrace on the console after an internal error.
2021-08-11gdb: register SIGBUS, SIGFPE, and SIGABRT handlersAndrew Burgess2-2/+20
Register handlers for SIGBUS, SIGFPE, and SIGABRT. All of these signals are setup as fatal signals that will cause GDB to terminate. However, by passing these signals through the handle_fatal_signal function, a user can arrange to see a backtrace when GDB terminates (see maint set backtrace-on-fatal-signal). In normal use of GDB there should be no user visible changes after this commit. Only if GDB terminates with one of the above signals will GDB change slightly, potentially printing a backtrace before aborting. I've added new tests for SIGFPE, SIGBUS, and SIGABRT.
2021-08-11gdb: print backtrace on fatal SIGSEGVAndrew Burgess9-11/+398
This commit adds a new maintenance feature, the ability to print a (limited) backtrace if GDB dies due to a fatal signal. The backtrace is produced using the backtrace and backtrace_symbols_fd functions which are declared in the execinfo.h header, and both of which are async signal safe. A configure check has been added to check for these features, if they are not available then the new code is not compiled into GDB and the backtrace will not be printed. The motivation for this new feature is to aid in debugging GDB in situations where GDB has crashed at a users site, but the user is reluctant to share core files, possibly due to concerns about what might be in the memory image within the core file. Such a user might be happy to share a simple backtrace that was written to stderr. The production of the backtrace is on by default, but can switched off using the new commands: maintenance set backtrace-on-fatal-signal on|off maintenance show backtrace-on-fatal-signal Right now, I have hooked this feature in to GDB's existing handling of SIGSEGV only, but this will be extended to more signals in a later commit. One additional change I have made in this commit is that, when we decide GDB should terminate due to the fatal signal, we now raise the same fatal signal rather than raising SIGABRT. Currently, this is only effecting our handling of SIGSEGV. So, previously, if GDB hit a SEGV then we would terminate GDB with a SIGABRT. After this commit we will terminate GDB with a SIGSEGV. This feels like an improvement to me, we should still get a core dump, but in many shells, the user will see a more specific message once GDB exits, in bash for example "Segmentation fault" rather than "Aborted". Finally then, here is an example of the output a user would see if GDB should hit an internal SIGSEGV: Fatal signal: Segmentation fault ----- Backtrace ----- ./gdb/gdb[0x8078e6] ./gdb/gdb[0x807b20] /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20] /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f] ./gdb/gdb[0x1540f4c] ./gdb/gdb[0x154034a] ./gdb/gdb[0x9b002d] ./gdb/gdb[0x9b014d] ./gdb/gdb[0x9b1aa6] ./gdb/gdb[0x9b1b0c] ./gdb/gdb[0x41756d] /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3] ./gdb/gdb[0x41746e] --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) It is disappointing that backtrace_symbols_fd does not actually map the addresses back to symbols, this appears, in part, to be due to GDB not being built with -rdynamic as the manual page for backtrace_symbols_fd suggests, however, even when I do add -rdynamic to the build of GDB I only see symbols for some addresses. We could potentially look at alternative libraries to provide the backtrace (e.g. libunwind) however, the solution presented here, which is available as part of glibc is probably a good baseline from which we might improve things in future.
2021-08-11gdb: rename async_init_signals to gdb_init_signalsAndrew Burgess3-29/+16
The async_init_signals has, for some time, dealt with async and sync signals, so removing the async prefix makes sense I think. Additionally, as pointed out by Pedro: ..... The comments relating to SIGTRAP and SIGQUIT within this function are out of date. The comments for SIGTRAP talk about the signal disposition (SIG_IGN) being passed to the inferior, meaning the signal disposition being inherited by GDB's fork children. However, we now call restore_original_signals_state prior to forking, so the comment on SIGTRAP is redundant. The comments for SIGQUIT are similarly out of date, further, the comment on SIGQUIT talks about problems with BSD4.3 and vfork, however, we have not supported BSD4.3 for several years now. Given the above, it seems that changing the disposition of SIGTRAP is no longer needed, so I've deleted the signal() call for SIGTRAP. Finally, the header comment on the function now called gdb_init_signals was getting quite out of date, so I've updated it to (hopefully) better reflect reality. There should be no user visible change after this commit.
2021-08-11gdb: register signal handler after setting up event tokenAndrew Burgess1-3/+5
This commit fixes the smallest of small possible bug related to signal handling. If we look in async_init_signals we see code like this: signal (SIGQUIT, handle_sigquit); sigquit_token = create_async_signal_handler (async_do_nothing, NULL, "sigquit"); Then if we look in handle_sigquit we see code like this: mark_async_signal_handler (sigquit_token); signal (sig, handle_sigquit); Finally, in mark_async_signal_handler we have: async_handler_ptr->ready = 1; Where async_handler_ptr will be sigquit_token. What this means is that if a SIGQUIT arrive in async_init_signals after handle_sigquit has been registered, but before sigquit_token has been initialised, then GDB will most likely crash. The chance of this happening is tiny, but fixing this is trivial, just ensure we call create_async_signal_handler before calling signal, so lets do that. There are no tests for this. Trying to land a signal in the right spot is pretty hit and miss. I did try changing the current HEAD GDB like this: signal (SIGQUIT, handle_sigquit); raise (SIGQUIT); sigquit_token = create_async_signal_handler (async_do_nothing, NULL, "sigquit"); And confirmed that this did result in a crash, after my change I tried this: sigquit_token = create_async_signal_handler (async_do_nothing, NULL, "sigquit"); signal (SIGQUIT, handle_sigquit); raise (SIGQUIT); And GDB now starts up just fine. gdb/ChangeLog: * event-top.c (async_init_signals): For each signal, call signal only after calling create_async_signal_handler.
2021-08-11gdb: terminate upon receipt of SIGFPEAndrew Burgess1-24/+1
GDB's SIGFPE handling is broken, this is PR gdb/16505 and PR gdb/17891. We currently try to use an async event token to process SIGFPE. So, when a SIGFPE arrives the signal handler calls mark_async_signal_handler then returns, effectively ignoring the signal (for now). The intention is that later the event loop will see that the async token associated with SIGFPE has been marked and will call the async handler, which just throws an error. The problem is that SIGFPE is not safe to ignore. Ignoring a SIGFPE (unless it is generated artificially, e.g. by raise()) is undefined behaviour, after ignoring the signal on many targets we return to the instruction that caused the SIGFPE to be raised, which immediately causes another SIGFPE to be raised, we get stuck in an infinite loop. The behaviour is certainly true on x86-64. To view this behaviour I simply added some dummy code to GDB that performed an integer divide by zero, compiled this on x86-64 GNU/Linux, ran GDB and saw GDB hang. In this commit, I propose to remove all special handling of SIGFPE and instead just let GDB make use of the default SIGFPE action, that is, to terminate the process. The only user visible change here should be: - If a user sends a SIGFPE to GDB using something like kill, previously GDB would just print an error and remain alive, now GDB will terminate. This is inline with what happens if the user sends GDB a SIGSEGV from kill though, so I don't see this as an issue. - If a bug in GDB causes a real SIGFPE, previously the users GDB session would hang. Now the GDB session will terminate. Again, this is inline with what happens if GDB receives a SIGSEGV due to an internal bug. In bug gdb/16505 there is mention that it would be nice if GDB did more than just terminate when receiving a fatal signal. I haven't done that in this commit, but later commits will move in that direction. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891
2021-08-11PR28198, Support # as linker script comment markerAlan Modra1-8/+7
PR 28198 * ldlex.l: Combine rules for handling newline, whitespace and comments. Extend # comment handling to all states.
2021-08-11ldgram.y tidiesAlan Modra1-41/+55
I've been tripped up before thinking the "end" rule was the "END" token. Let's use a better name. The formatting changes are for consistency within rules, and making it a little easier to visually separate tokens from mid-rule actions. * ldgram.y (separator): Rename from "end". Update uses. (statement): Formatting. Move ';' match to beginning. (paren_script_name): Formatting. Simplify. (must_be_exp, section): Formatting.
2021-08-11Mention whitespace in script expressionsAlan Modra1-3/+5
Inside an output section statement, ld's parser can't tell whether a line .+=4; is an assignment to dot or a file named ".+=4". * ld.texi (expressions): Mention need for whitespace.
2021-08-11Add a -mno-dollar-line-separator command line option to the AVR assembler.Matt Jacobson4-4/+33
Some frontends, like the gcc Objective-C frontend, emit symbols with $ characters in them. The AVR target code in gas treats $ as a line separator, so the code doesn?t assemble correctly. Provide a machine-specific option to disable treating $ as a line separator. * config/tc-avr.c (enum options): Add option flag. (struct option): Add option -mno-dollar-line-separator. (md_parse_option): Adjust treatment of $ when option is present. * config/tc-avr.h: Use avr_line_separator_chars.
generated by cgit v1.1 at 2024-11-24 03:14:17 +0000