binutils-gdb

Commit Graph

Author	SHA1	Message	Date
John Ericson	ab4f385b3c	Deprecate a.out support for NetBSD targets. 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 +-	5 years ago
Andrew Burgess	0e6e4b599a	gdb: don't print backtrace when dumping core after an internal error 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.	5 years ago
Andrew Burgess	d03277b797	gdb: register SIGBUS, SIGFPE, and SIGABRT handlers 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.	5 years ago
Andrew Burgess	6aa4f97c2b	gdb: print backtrace on fatal SIGSEGV 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.	5 years ago
Andrew Burgess	270135645b	gdb: rename async_init_signals to gdb_init_signals 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.	5 years ago
Andrew Burgess	bbefac7df9	gdb: register signal handler after setting up event token 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.	5 years ago
Andrew Burgess	fb550a919a	gdb: terminate upon receipt of SIGFPE 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	5 years ago
Alan Modra	cc9faa98ad	PR28198, Support # as linker script comment marker PR 28198 * ldlex.l: Combine rules for handling newline, whitespace and comments. Extend # comment handling to all states.	5 years ago
Alan Modra	6c93cebf2d	ldgram.y tidies 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.	5 years ago
Alan Modra	fb0afe4cca	Mention whitespace in script expressions 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.	5 years ago
Matt Jacobson	d86d1fc7f9	Add a -mno-dollar-line-separator command line option to the AVR assembler. 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.	5 years ago
Nick Clifton	bda3d9fbc8	Fix typo in previous delta	5 years ago
Jan Beulich	199bbc7a4c	gas: fold IEEE encoding of -Inf with that of +Inf The respective results differ only by the sign bits - there's no need to have basically identical (partially even arch-specific) logic twice. Simply set the sign bit at the end of encoding the various formats.	5 years ago
Jan Beulich	f0dec3f488	gas: support NaN flavors Like for infinity, there isn't just a single NaN. The sign bit may be of interest and, going beyond infinity, whether the value is quiet or signalling may be even more relevant to be able to encode. Note that an anomaly with x86'es double extended precision NaN values gets taken care of at the same time: For all other formats a positive value with all mantissa bits set was used, while here a negative value with all non-significant mantissa bits clear was chose for an unknown reason. For m68k, since I don't know their X_PRECISION floating point value layout, a warning gets issued if any of the new flavors was attempted to be encoded that way. However likely it may be that, given that the code lives in a source file supposedly implementing IEEE-compliant formats, the bit patterns of the individual words match x86'es, I didn't want to guess so. And my very, very old paper doc doesn't even mention floating point formats other than single and double.	5 years ago
Jan Beulich	7727283e51	Arm64: leave .bfloat16 processing to common code With x86 support having been implemented by extending atof-ieee.c, avoid unnecessary code duplication in md_atof(). This will then also allow to take advantage of adjustments made there without needing to mirror them here.	5 years ago
Jan Beulich	2557e081af	Arm32: leave more .bfloat16 processing to common code With x86 support having been implemented by extending atof-ieee.c, avoid unnecessary code duplication in md_atof(). This will then also allow to take advantage of adjustments made there without needing to mirror them here.	5 years ago
Jan Beulich	bcd17d4f51	gas: make 2nd argument of .dcb.* consistently optional Unlike the forms consuming/producing integer data, the floating point ones so far required the 2nd argument to be present, contrary to documentation. To avoid code duplication, split float_length() out of hex_float() (taking the opportunity to adjust error message wording).	5 years ago
Jan Beulich	de133cf98c	x86: introduce .bfloat16 directive This is to be able to generate data acted upon by AVX512-BF16 and AMX-BF16 insns. While not part of the IEEE standard, the format is sufficiently standardized to warrant handling in config/atof-ieee.c. Arm, where custom handling was implemented, may want to leverage this as well. To be able to also use the hex forms supported for other floating point formats, a small addition to the generic hex_float() is needed. Extend existing x86 testcases.	5 years ago
Jan Beulich	7d19d09629	x86: introduce .hfloat directive This is to be able to generate data passed to {,V}CVTPH2PS and acted upon by AVX512-FP16 insns. To be able to also use the hex forms supported for other floating point formats, a small addition to the generic hex_float() is needed. Extend existing x86 testcases.	5 years ago
Jan Beulich	8f2200fe8e	x86/ELF: fix .tfloat output with hex input The ELF psABI-s are quite clear here: On 32-bit the data type is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16 bytes long (with 6 bytes of padding). Make hex_float() capable of handling such padding. Note that this brings the emitted data size of .dc.x / .dcb.x in line also for non-ELF targets; so far they were different depending on input format (dec vs hex). Extend the existing x86 testcases.	5 years ago
Jan Beulich	e74e2b4c33	x86/ELF: fix .ds.x output The ELF psABI-s are quite clear here: On 32-bit the underlying data type is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16 bytes long (with 6 bytes of padding). Make s_space() capable of handling 'x' (and 'p') type floating point being other than 12 bytes wide (also adjusting documentation). This requires duplicating the definition of X_PRECISION in the target speciifc header; the compiler would complain if this was out of sync with config/atof-ieee.c. Note that for now padding space doesn't get separated from actual storage, which means that things will work correctly only for little- endian cases, and which also means that by specifying large enough numbers padding space can be set to non-zero. Since the logic is needed for a single little-endian architecture only for now, I'm hoping that this might be acceptable for the time being; otherwise the change will become more intrusive. Note also that this brings the emitted data size of .ds.x vs .tfloat in line for non-ELF targets as well; the issue will be even more obvious when further taking into account a subsequent patch fixing .dc.x/.dcb.x (where output sizes currently differ depending on input format). Extend existing x86 testcases.	5 years ago
Jan Beulich	e2295dade8	x86/ELF: fix .tfloat output The ELF psABI-s are quite clear here: On 32-bit the data type is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16 bytes long (with 6 bytes of padding). Make ieee_md_atof() capable of handling such padding, and specify the needed padding for x86 (leaving non-ELF targets alone for now). Split the existing x86 testcase.	5 years ago
Jan Beulich	e7e57d02fb	x86: have non-PE/COFF BEOS be recognized as ELF BEOS, unless explicitly requesting --beospe* targets, uses standard ELF. None of the newly enabled tests in the testsuite fail for me.	5 years ago
Alan Modra	2ad55ffca1	PR28163, Segment fault in function rl78_special_reloc Relocation offset checks were completely missing in the rl78 backend, allowing a relocation to write over memory anywhere. This was true for rl78_special_reloc, a function primarily used when applying debug relocations, and in rl78_elf_relocate_section used by the linker. This patch fixes those problems by correcting inaccuracies in the relocation howtos, then uses those howtos to sanity check relocation offsets before applying relocations. In addition, the patch implements overflow checking using the howto information rather than the ad-hoc scheme implemented in relocate_section. I implemented the overflow checking in rl78_special_reloc too. * elf32-rl78.c (RL78REL, RL78_OP_REL): Add mask parameter. (rl78_elf_howto_table): Set destination masks. Correct size and bitsize of DIR32_REV. Correct complain_on_overflow for many relocs as per tests in relocate_section. Add RH_SFR. Correct bitsize for RH_SADDR. Set size to 3 and bitsize to 0 for all OP relocs. (check_overflow): New function. (rl78_special_reloc): Check that reloc address is within section. Apply relocations using reloc howto. Check for overflow. (RANGE): Delete. (rl78_elf_relocate_section): Sanity check r_offset. Perform overflow checking using reloc howto.	5 years ago
GDB Administrator	c0e94211e1	Automatic date update in version.in	5 years ago
Tom Tromey	2c1db96b66	Ignore .debug_types when reading .debug_aranges I noticed that the fission-reread.exp test case can cause a complaint when run with --target_board=cc-with-debug-names: warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges. The bug here is that this executable has both .debug_info and .debug_types, and both have a CU at offset 0x0. This triggers the duplicate warning. Because .debug_types doesn't provide any address ranges, these CUs can be ignored. That is, this bug turns out to be another regression from the info/types merger patch. This patch fixes the problem by having this loop igore type units. fission-reread.exp is updated to test for the bug.	5 years ago
Tom Tromey	192786c72a	Generalize addrmap dumping While debugging another patch series, I wanted to dump an addrmap. I came up with this patch, which generalizes the addrmap-dumping code from psymtab.c and moves it to addrmap.c. psymtab.c is changed to use the new code.	5 years ago
Simon Marchi	69eadcc9ea	gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit I spotted what I think is a buglet in proceed_after_vfork_done. After a vfork child exits or execs, we resume all the threads of the parent. To do so, we iterate on all threads using iterate_over_threads with the proceed_after_vfork_done callback. Each thread is resumed if the following condition is true: if (thread->ptid.pid () == pid && thread->state == THREAD_RUNNING && !thread->executing && !thread->stop_requested && thread->stop_signal () == GDB_SIGNAL_0) where `pid` is the pid of the vfork parent. This is not multi-target aware: since it only filters on pid, if there is an inferior with the same pid in another target, we could end up resuming a thread of that other inferior. The chances of the stars aligning for this to happen are tiny, but still. Fix that by iterating only on the vfork parent's threads, instead of on all threads. This is more efficient, as we iterate on just the required threads (inferiors have their own thread list), and we can drop the pid check. The resulting code is also more straightforward in my opinion, so it's a win-win. Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a	5 years ago
Nick Clifton	3ee0cd9e55	Updated Serbian and Russian translations for various sub-directories	5 years ago
George Barrett	c173cc8a66	guile: fix smob exports Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added the created class to the exports list of (oop goops); v2.1+ does not implicitly create bindings in any modules. This means that the GDB manual subsection documenting exported types is not quite right when GDB is linked against Guile <v2.1 (types are exported from (oop goops)) instead of (gdb)) and incorrect when linked against Guile v2.1+ (types are not bound to any variables at all!). There is a range of cases in which it's necessary or convenient to be able to refer to a GDB smob type, for instance: - Pattern matching based on the type of a value. - Defining GOOPS methods handling values from GDB (GOOPS methods typically use dynamic dispatch based on the types of the arguments). - Type-checking assertions when applying some defensive programming on an interface. - Generally any other situation one might encounter in a dynamically typed language that might need some introspection. If you're more familiar with Python, it would be quite similar to being unable to refer to the classes exported from the GDB module (which is to say: not crippling for the most part, but makes certain tasks more difficult than necessary). This commit makes a small change to GDB's smob registration machinery to make sure registered smobs get exported from the current module. This will likely cause warnings to the user about conflicting exports if they load both (gdb) and (oop goops) from a GDB linked against Guile v2.0, but it shouldn't impact functionality (and seemed preferable to trying to un-export bindings from (oop goops) if v2.0 was detected). [1]: This changed with Guile commit 28d0871b553a3959a6c59e2e4caec1c1509f8595 gdb/ChangeLog: 2021-06-07 George Barrett <bob@bob131.so> * guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered smob type from the current module. gdb/testsuite/ChangeLog: 2021-06-07 George Barrett <bob@bob131.so> * gdb.guile/scm-gsmob.exp (test exports): Add tests to make sure the smob types currently listed in the GDB manual get exported from the (gdb) module. Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7	5 years ago
GDB Administrator	d2a2c939f1	Automatic date update in version.in	5 years ago
Nick Clifton	3417bfca67	GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory. * dwarf2dbg.c (get_directory_table_entry): Ensure that dir[0] contains current working directory. (out_dir_and_file_list): Likewise. * testsuite/gas/elf/dwarf-5-dir0.s: New test source file. * testsuite/gas/elf/dwarf-5-dir0.d: New test driver. * testsuite/gas/elf/elf.exp: Run the new test. * testsuite/gas/elf/dwarf-5-file0.d: Adjust expected output. * testsuite/gas/i386/dwarf5-line-1.d: Likewise. * testsuite/gas/i386/dwarf5-line-2.d: Likewise.	5 years ago
GDB Administrator	b18bfc0946	Automatic date update in version.in	5 years ago
Tom Tromey	a8624232b1	Include objfiles.h in a few .c files I found a few .c files that rely on objfiles.h, but that only include it indirectly, via dwarf2/read.h -> psympriv.h. If that include is removed (something my new DWARF indexer series does), then the build will break. It seemed harmless and correct to add these includes now, making the eventual series a little smaller.	5 years ago
GDB Administrator	42ddfd0b7a	Automatic date update in version.in	5 years ago
Alan Modra	182ad37589	PR28186, SEGV elf.c:7991:30 in _bfd_elf_fixup_group_sections PR 28186 * elf.c (_bfd_elf_fixup_group_sections): Don't segfault on objcopy/strip with NULL output_section.	5 years ago
Alan Modra	983cdaecc1	PR28176, rl78 complex reloc divide by zero This is a bit more than just preventing the divide by zero. Most of the patch is tidying up error reporting, so that for example, linking an object file with a reloc stack underflow produces a linker error rather than just displaying a message that might be ignored. PR 28176 * elf32-rl78.c (RL78_STACK_PUSH, RL78_STACK_POP): Delete. (rl78_stack_push, rl78_stack_pop): New inline functions. (rl78_compute_complex_reloc): Add status and error message params. Use new inline stack handling functions. Report stack overflow or underflow, and divide by zero. (rl78_special_reloc): Return status and error message from rl78_compute_complex_reloc. (rl78_elf_relocate_section): Similarly. Modernise reloc error reporting. Delete unused bfd_reloc_other case. Don't assume DIR24S_PCREL overflow is due to undefined function. (rl78_offset_for_reloc): Adjust to suit rl78_compute_complex_reloc.	5 years ago
GDB Administrator	0175375faa	Automatic date update in version.in	5 years ago
Tom de Vries	cc6b3d766d	[gdb/symtab] Recognize .gdb_index symbol table with empty entries as empty When reading a .gdb_index that contains a non-empty symbol table with only empty entries, gdb doesn't recognize it as empty. Fix this by recognizing that the constant pool is empty, and then setting the symbol table to empty. Tested on x86_64-linux. gdb/ChangeLog: 2021-08-01 Tom de Vries <tdevries@suse.de> PR symtab/28159 * dwarf2/read.c (read_gdb_index_from_buffer): Handle symbol table filled with empty entries. gdb/testsuite/ChangeLog: 2021-08-01 Tom de Vries <tdevries@suse.de> PR symtab/28159 * gdb.dwarf2/dw2-zero-range.exp: Remove kfail.	5 years ago
Tom Tromey	fd98618334	Unconditionally define _initialize_addrmap The way that init.c is generated does not allow for an initialization function to be conditionally defined -- doing so will result in a link error. This patch fixes a build problem that arises from such a conditional definition. It can be reproduce with --disable-unit-tests.	5 years ago
Tom de Vries	b9f3fbc9f3	[gdb/symtab] Fix zero address complaint for shlib In PR28004 the following warning / Internal error is reported: ... $ gdb -q -batch \ -iex "set sysroot $(pwd -P)/repro" \ ./repro/gdb \ ./repro/core \ -ex bt ... Program terminated with signal SIGABRT, Aborted. #0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6 [Current thread is 1 (LWP 1762498)] #1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6 warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \ but not in symtab.) warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \ but not in symtab.) ... #2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \ [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \ psymtab, but not in symtab.) ) from repro/usr/lib/libstdc++.so.6 ... The warning is about the following: - in find_pc_sect_compunit_symtab we try to find the address (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs. - that fails, so we try again in the partial symtabs. - we find a matching partial symtab - however, the partial symtab has a full symtab, so we should have found a matching symtab in the first step. The addresses are: ... (gdb) info sym 0x7ff8feb2c218 __gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \ section .text of repro/usr/lib/libstdc++.so.6 (gdb) info sym 0x7ff8feb2c21d __gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \ section .text of repro/usr/lib/libstdc++.so.6 ... which correspond to unrelocated addresses 0x9c218 and 0x9c21d: ... $ nm -C repro/usr/lib/libstdc++.so.6.0.29 \| grep 000000000009c218 000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \ [clone .cold] ... which belong to function __gnu_debug::_Error_formatter::_M_error() in /build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc. The partial symtab that is found for the addresses is instead the one for /build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is incorrect. This happens as follows. The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50: ... 00004b50 0000000000000000 0000000000000056 00004b5a 00000000000a4790 00000000000a479c 00004b64 00000000000a47a0 00000000000a47ac ... When reading the first range 0x0..0x56, it doesn't trigger the "start address of zero" complaint here: ... /* A not-uncommon case of bad debug info. Don't pollute the addrmap with bad data. / if (range_beginning + baseaddr == 0 && !per_objfile->per_bfd->has_section_at_zero) { complaint (_(".debug_rnglists entry has start address of zero" " [in module %s]"), objfile_name (objfile)); continue; } ... because baseaddr != 0, which seems incorrect given that when loading the shared library individually in gdb (and consequently baseaddr == 0), we do see the complaint. Consequently, we run into this case in dwarf2_get_pc_bounds: ... if (low == 0 && !per_objfile->per_bfd->has_section_at_zero) return PC_BOUNDS_INVALID; ... which then results in this code in process_psymtab_comp_unit_reader being called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap argument to 1: ... scan_partial_symbols (first_die, &lowpc, &highpc, cu_bounds_kind <= PC_BOUNDS_INVALID, cu); ... and consequently, the CU addrmap gets build using address info from the functions. During that process, addrmap_set_empty is called with a range that includes 0x9c218 and 0x9c21d: ... (gdb) p /x start $7 = 0x9989c (gdb) p /x end_inclusive $8 = 0xb200d ... but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae: ... 000040ae 00000000000b1ee0 00000000000b200e 000040b9 000000000009989c 00000000000998c4 000040c3 <End of list> ... and neither range includes 0x9c218 and 0x9c21d. This is caused by this code in partial_die_info::read: ... if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu, nullptr, tag)) has_pc_info = 1; ... which pretends that the function is located at addresses 0x9989c..0xb200d, which is indeed not the case. This patch fixes the first problem encountered: fix the "start address of zero" complaint warning by removing the baseaddr part from the condition. Same for dwarf2_ranges_process. The effect is that: - the complaint is triggered, and - the warning / Internal error is no longer triggered. This does not fix the observed problem in partial_die_info::read, which is filed as PR28200. Tested on x86_64-linux. Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> gdb/ChangeLog: 2021-07-29 Simon Marchi <simon.marchi@polymtl.ca> Tom de Vries <tdevries@suse.de> PR symtab/28004 gdb/dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process): Fix zero address complaint. * gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test. * gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test. * gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.	5 years ago
Alan Modra	7fc8d4f48b	Re: Add tests for Intel AVX512_FP16 instructions * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Pass with mingw section padding.	5 years ago
Alan Modra	7eb7e4cdcc	chew ubsan warning It matters not at all if pc is incremented from its initial NULL value, but avoid this silly runtime ubsan error. * doc/chew.c (perform): Avoid incrementing NULL pc.	5 years ago
Alan Modra	856c1545ce	bfd_reloc_offset_in_range overflow This patch is more about the style of bounds checking we ought to use, rather than a real problem. An overflow of "octet + reloc_size" can only happen with huge sections which would certainly cause out of memory errors. * reloc.c (bfd_reloc_offset_in_range): Avoid possible overflow.	5 years ago
Alan Modra	e039f7ed86	PR28175, Segment fault in coff-tic30.c reloc_processing The obj_convert table shouldn't be accessed without first checking the index against the table size. PR 28175 * coff-tic30.c (reloc_processing): Sanity check reloc symbol index. * coff-z80.c (reloc_processing): Likewise. * coff-z8k.c (reloc_processing): Likewise.	5 years ago
Alan Modra	a379e7588c	PR28173, nds32_elf_howto_table index out of bounds Indexing the howto table was seriously broken by a missing entry, and use of assertions about user input rather than testing the input. PR 28173 * elf32-nds32.c (nds32_elf_howto_table): Add missing empty howto. (bfd_elf32_bfd_reloc_type_table_lookup): Replace assertions with range checks. Return NULL if unsupported reloc type. Remove dead code. Take an unsigned int param. (nds32_info_to_howto_rel): Test for NULL howto or howto name return from lookup. Remove assertion. (nds32_info_to_howto): Remove unnecessary ATTRIBUTE_UNUSED. Test for NULL howto or howto name return from lookup.	5 years ago
Alan Modra	352bd3aa1c	PR28172, bfin_pcrel24_reloc heap-buffer-overflow bfin pcrel24 relocs are weird, they apply to the reloc address minus two. That means reloc addresses of 0 and 1 are invalid. Check that, and fix other reloc range checking. PR 28172 * elf32-bfin.c (bfin_pcrel24_reloc): Correct reloc range check. (bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc): Likewise. (bfin_final_link_relocate): Likewise.	5 years ago
GDB Administrator	8179e388b6	Automatic date update in version.in	5 years ago
Will Schmidt	c2bc854c8b	[PATCH] GDB Testsuite, update compile-cplus.exp [PATCH] GDB Testsuite, update compile-cplus.exp Update the gdb.compile/compile-cplus.exp test to handle errors generated when passing bad arguments into the gdb-compile command. This matches changes made to gdb.compile/compile.exp in the past as part of "Migrate rest of compile commands to new options framework" `e6ed716cd5`	5 years ago
Will Schmidt	bad23de354	[gdb] Handle .TOC. sections during gdb-compile for rs6000 target. [gdb] Handle .TOC. sections during gdb-compile for rs6000 target. When we encounter a .TOC. symbol in the object we are loading, we need to associate this with the .toc section in order to properly resolve other symbols in the object. IF a .toc section is not found, iterate the sections until we find one with the SEC_ALLOC flag. If that also fails, fall back to using the ABS section, pointed to by bfd_abs_section_ptr.	5 years ago

1 2 3 4 5 ...

107235 Commits (ab4f385b3c31e6bca198d2eef1a8c5268e28cd76) All Branches Search

107235 Commits (ab4f385b3c31e6bca198d2eef1a8c5268e28cd76)

All Branches