binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Simon Marchi	13084383e8	gdbsupport: make gdb_open_cloexec return scoped_fd Make gdb_open_cloexec return a scoped_fd, to encourage using automatic management of the file descriptor closing. Except in the most trivial cases, I changed the callers to just release the fd, which retains their existing behavior. That will allow the transition to using scoped_fd more to go gradually, one caller at a time. Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554	5 years ago
Simon Marchi	e6e51c9c4b	gdbsupport: move gdb_file_up to its own file The following patches wants to change gdb_fopen_cloexec and gdb_mkostemp_cloexec to return a scoped_fd. Doing this causes a cyclic include between scoped_fd.h and filestuff.h, that both want to include each other. scoped_fd.h includes filestuff.h because of the scoped_fd::to_file method's return value. filestuff.h would then include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's return values. To fix that, move gdb_file_up to its own file, gdb_file.h. Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d	5 years ago
Dimitar Dimitrov	5109a7bd9b	ld: pru: Fix resource_table output section alignment My commit `261980de18` added alignment for the resource table symbol. But it is wrong. The Linux remoteproc driver loads and interprets the contents of the .resource_table ELF section, not of a table symbol. Without this patch, if the linker happens to output padding for symbol alignment, then the resource table contents as viewed by the kernel loader would "shift" and look corrupted. ld/ChangeLog: * scripttempl/pru.sc (.resource_table): Align the output section, not the first symbol. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>	5 years ago
Tom Tromey	9279eb5c2c	Fix Windows crash from stop_pc change The "make thread_suspend_state::stop_pc optional" patch caused a regression on Windows when using shared libraries. I tracked this down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED case of handle_inferior_event. This patch fixes the bug by ensuring that the stop PC is set at this point.	5 years ago
Tom de Vries	7264ba8331	[gdb/testsuite] Use untested in gdb.debuginfod/fetch_src_and_symbols.exp With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target board unix/-bad, I get: ... gcc: error: unrecognized command line option '-bad'^M compiler exited with status 1 gdb compile failed, gcc: error: unrecognized command line option '-bad' FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile ... Replace the FAIL with the usual: ... UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile ... Tested on x86_64-linux.	5 years ago
Tom de Vries	243c0950e2	[gdb/testsuite] Remove redundant FAIL in gdb.base/info-os.exp When running test-case gdb.base/info-os.exp with target board unix/-bad, I run into: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.base/info-os.exp: failed to prepare FAIL: gdb.base/info-os.exp: cannot compile test program ... Remove the redundant FAIL. Tested on x86_64-linux.	5 years ago
Tom de Vries	50f9e7d853	[gdb/testsuite] Fix DUPLICATE in gdb.base/info-os.exp When running test-case gdb.base/info-os.exp, I run into: ... PASS: gdb.base/info-os.exp: get threads PASS: gdb.base/info-os.exp: get threads DUPLICATE: gdb.base/info-os.exp: get threads ... Fix this not doing pass followed by exp_continue in gdb_test_multiple. Tested on x86_64-linux.	5 years ago
Tom de Vries	9ebd290966	[gdb/testsuite] Check compilation result in gdb.dwarf2/dw2-opt-structptr.exp When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board unix/-bad, I get: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile ERROR: (dw2-opt-structptr) No such file or directory UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on ... Merge the two UNTESTEDs. Fix the UNRESOLVED by checking result of compilation. Tested on x86_64-linux.	5 years ago
Tom de Vries	c2fd8824c8	[gdb/testsuite] Check compilation result in gdb.base/structs.exp When running test-case gdb.base/structs.exp with target board unix/-bad, I get: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.base/structs.exp: failed to prepare ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp. ERROR: can't read "use_gdb_stub": no such variable ... Fix this by checking the compilation result. Fix the resulting DUPLICATEs using with_test_prefix. Tested on x86_64-linux.	5 years ago
Tom de Vries	dc412de5e9	[gdb/testsuite] Prepare nodebug exec in gdb.base/cvexpr.exp When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp. ERROR: can't read "use_gdb_stub": no such variable ... This is triggered in a part of the test that claims to require no debug information, but uses the exec containing either dwarf or ctf. Fix this by preparing another executable compiled with nodebug, and using that one instead. Also use with_test_prefix to mark the nodebug part, such that we have: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare ... Tested on x86_64-linux.	5 years ago
Tom de Vries	85d74f2936	[gdb/testsuite] Fix DUPLICATE in gdb.base/cvexpr.exp Fix: ... DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict ... using with_test_prefix. Tested on x86_64-linux.	5 years ago
Tom de Vries	e46da7ec1b	[gdb/testsuite] Check compilation result in gdb.base/call-sc.exp When running test-case gdb.base/call-sc.exp with target board unix/-bad, I get: ... gdb compile failed, gcc: error: unrecognized command line option '-bad' UNTESTED: gdb.base/call-sc.exp: failed to prepare ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp. ERROR: can't read "use_gdb_stub": no such variable ... Fix this by checking the compilation result. Fix the resulting DUPLICATE: ... DUPLICATE: gdb.base/call-sc.exp: failed to prepare ... using with_test_prefix. Tested on x86_64-linux.	5 years ago
Tom de Vries	b6107a72ba	[gdb/testsuite] Fix untested messages in gdb.mi/.exp The effect of: ... untested "y.exp" ... in a gdb.x/y.exp is: ... UNTESTED: gdb.x/y.exp: y.exp ... which is a bit pointless. Replace these untested messages in gdb.mi/.exp with the usual "failed to compile". Likewise for an: ... untested $testname ... where the variable is undefined. Tested on x86_64-linux.	5 years ago
Nick Clifton	7325ba796b	make objcopy fail if it is asked to redefine symbols in an object file containing LTO information. * objcopy.c (filter_symbols): Fail if attempting to dredefine symbols in an LTO object file.	5 years ago
Tom de Vries	6010fb0c49	[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp On ubuntu 18.04.5, I run into: ... (gdb) mt print objfiles dwindex^M ^M Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex: \ Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M ^M Psymtabs:^M vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M ... library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M ERROR: internal buffer is full. UNRESOLVED: gdb.rust/dwindex.exp: check if index present ... Fix this by using -lbl in proc ensure_gdb_index. Tested on x86_64-linux.	5 years ago
Libor Bukata	6420dd27cb	Add Solaris specific ELF note processing Add elfcore_grok_solaris_note function that enables to obtain process status, register values, and program info from Solaris's core files. bfd/ * elf.c (elfcore_grok_solaris_note): Solaris specific ELF note parser. Better GDB's coredump analysis on Solaris... (elfcore_grok_solaris_note_impl): New function. (elfcore_grok_solaris_prstatus): New function. (elfcore_grok_solaris_info): New function. (elfcore_grok_solaris_lwpstatus): New function. (elf_parse_notes): Added "CORE" groker element. include/ * elf/common.h: Add note segment constants for core files on Solaris systems.	5 years ago
Frederic Cambus	98ca73afe5	Add support to readelf for reading OpenBSD ELF core notes. * readelf.c (get_openbsd_elfcore_note_type): New function. (process_note): Add support for OpenBSD core notes.	5 years ago
GDB Administrator	f141837642	Automatic date update in version.in	5 years ago
Tom de Vries	215b6d107c	[gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get: ... (gdb) info addr dl_main^M Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M (gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main ... while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\." Fix this by also accepting this variant. Tested on x86_64-linux.	5 years ago
H.J. Lu	689580daaa	Add a testcase for PR binutils/27202 PR binutils/27202 * testsuite/gas/elf/dwarf-5-loc0.d: New file. * testsuite/gas/elf/dwarf-5-loc0.s: Likewise. * testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.	5 years ago
Pedro Alves	8e4e0c7a49	Fix gdb.multi/multi-term-settings.exp race The gdb.multi/multi-term-settings.exp testcase sometimes fails like so: Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ... FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) It's easier to reproduce if you stress the machine at the same time, like e.g.: $ stress -c 24 Looking at gdb.log, we see: (gdb) attach 60422 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422 [New Thread 60422.60422] Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so... Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory. (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach set schedule-multiple on (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on info inferiors Num Description Connection Executable 1 process 60404 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings * 2 process 60422 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors pid=60422, count=46 pid=60422, count=47 pid=60422, count=48 pid=60422, count=49 pid=60422, count=50 pid=60422, count=51 pid=60422, count=52 pid=60422, count=53 pid=60422, count=54 pid=60422, count=55 pid=60422, count=56 pid=60422, count=57 pid=60422, count=58 pid=60422, count=59 pid=60422, count=60 pid=60422, count=61 pid=60422, count=62 pid=60422, count=63 pid=60422, count=64 pid=60422, count=65 pid=60422, count=66 pid=60422, count=67 pid=60422, count=68 pid=60422, count=69 pid=60404, count=54 pid=60404, count=55 pid=60404, count=56 pid=60404, count=57 pid=60404, count=58 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue Quit (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) If you look at the testcase's sources, you'll see that the intention is to resumes the program with "continue", wait to see a few of those "pid=..., count=..." lines, and then interrupt the program with Ctrl-C. But somehow, that resulted in GDB printing "Quit", instead of the Ctrl-C stopping the program with SIGINT. Here's what is happening: #1 - those "pid=..., count=..." lines we see above weren't actually output by the inferior after it has been continued (see #1). Note that "inf1_how" and "inf2_how" are "attach". What happened is that those "pid=..., count=..." lines were output by the inferiors _before_ they were attached to. We see them at that point instead of earlier, because that's where the testcase reads from the inferiors' spawn_ids. #2 - The testcase mistakenly thinks those "pid=..., count=..." lines happened after the continue was processed by GDB, meaning it has waited enough, and so sends the Ctrl-C. GDB hasn't yet passed the terminal to the inferior, so the Ctrl-C results in that Quit. The fix here is twofold: #1 - flush inferior output right after attaching #2 - consume the "Continuing" printed by "continue", indicating the inferior has the terminal. This is the same as done throughout the testsuite to handle this exact problem of sending Ctrl-C too soon. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net <mailto:pedro@palves.net>> * gdb.multi/multi-term-settings.exp (create_inferior): Flush inferior output. (coretest): Use $gdb_test_name. After issuing "continue", wait for "Continuing". Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9	5 years ago
Tom de Vries	607679092f	[gdb/testsuite] Disable vgdb tests if xml not supported I build gdb without xml support using --without-expat, and ran into: ... (gdb) target remote \| vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M Remote debugging using \| vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M relaying data between gdb and process 22032^M warning: Can not parse XML target description; XML support was disabled at \ compile time^M ... (gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1 p gdb_test_infcall ()^M Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M (gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall () ... After googling the error message with context valgrind gdbserver, I found indications that the Remote 'g' packet reply error is due to missing xml support. And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I found: ... GDB version needed for ARM and PPC32/64. You must use a GDB version which is able to read XML target description sent by a gdbserver. This is the standard setup if GDB was configured and built with the "expat" library. If your GDB was not configured with XML support, it will report an error message when using the "target" command. Debugging will not work because GDB will then not be able to fetch the registers from the Valgrind gdbserver. ... So I guess I'm running into the same problem for x86_64. Fix this by skipping all gdb.base/valgrind-.exp tests if xml support is not available. Although only the gdb.base/valgrind-infcall.exp produce fails, the Remote 'g' packet reply error occurs in all tests, so it seems prudent to disable them all. Tested on x86_64-linux.	5 years ago
Tom de Vries	6767cc642c	[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2 With a gdb build using python 2.7, I run into: ... (gdb) python \ gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M File "<string>", line 1^M gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M ^^M SyntaxError: invalid syntax^M Error while executing Python code.^M (gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \ trap breakpoint_modified event ... This is caused by the following: - a lambda function body needs to be an expression - in python 2, print is a statement, while in python 3 it's a function - a function call is an expression, and a statement is not. Fix this by defining a function print_bp_enabled: ... def print_bp_enabled (bp): print (bp.enabled) end ... and using that instead. Tested on x86_64-linux.	5 years ago
Tom de Vries	f15ec499bf	[gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp With a gdb configured to be somewhat minimal, while still supporting python: ... $ gdb --configuration This GDB was configured as follows: configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --without-expat --with-gdb-datadir=$install/share/gdb (relocatable) --with-jit-reader-dir=$install/lib64/gdb (relocatable) --without-libunwind-ia64 --without-lzma --without-babeltrace --without-intel-pt --with-mpfr --without-xxhash --with-python=/usr --with-python-libdir=/usr/lib --with-debuginfod --without-guile --disable-source-highlight --with-separate-debug-dir=/usr/lib/debug --with-system-gdbinit=$devel/system-gdbinit ... and using gcc 4.8 to build gdb (causing std::thread not to be used due to PR28318) I ran into: ... (gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb print 1^M ^M Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M 1174 scoped_value_mark free_values;^M (xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout) ... The problem is that the regexp expects "hit Breakpoint $decimal". The "hit" part is missing. The "hit" is printed by maybe_print_thread_hit_breakpoint, when show_thread_that_caused_stop returns true: ... int show_thread_that_caused_stop (void) { return highest_thread_num > 1; } ... Apparently, that's not the case. Fix this by removing "hit" from the regexp, making the regexp more similar to what is used in say, continue_to_breakpoint. Tested on x86_64-linux.	5 years ago
Andrew Burgess	74ea3b51c3	gdb: fix build when libbacktrace and execinfo backtrace are not available In this commit: commit `abbbd4a3e0` Date: Wed Aug 11 13:24:33 2021 +0100 gdb: use libbacktrace to create a better backtrace for fatal signals The build of GDB was broken iff, the execinfo backtrace API is not available, and, libbacktrace is either disabled, or not usable. In this case you'll see build errors like this: CXX bt-utils.o /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()': /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope gdb_internal_backtrace_1 (); ^~~~~~~~~~~~~~~~~~~~~~~~ This commit fixes the issue by guarding the call to gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE', which is only defined when one of the backtrace libraries are available.	5 years ago
Andrew Burgess	4180173142	gdb/doc: use 'standard error stream' instead of 'stderr' in some places With this commit: commit `91f2597bd2` Date: Thu Aug 12 18:24:59 2021 +0100 gdb: print backtrace for internal error/warning I included some references to 'stderr', which, it was pointed out, would be better written as 'standard error stream'. See: https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html This commit replaces the two instances of 'stderr' that I introduced.	5 years ago
Andrew Burgess	80656a8e4b	gdb: fix manor -> manner typo in some comments In a recent commit I used 'manor' in some comments rather than 'manner'. This commit fixes those two mistakes. I also looked through the gdb/ tree and found one additional instance of this mistake that this commit also fixes.	5 years ago
Alan Modra	fba9460f7c	PR27202, readelf -wL doesn't work on ".loc 0" For DWARF revision 4 and earlier, display_debug_lines_decoded populates the file_table array with entries read from .debug_line after the directory table. file_table[0] contains the first entry. DWARF rev 4 line number programs index this entry as file number one. DWARF revision 5 changes .debug_line format quite extensively, and in particular gives file number zero a meaning. PR 27202 * dwarf.c (display_debug_lines_decoded): Correct indexing used for DWARF5 files.	5 years ago
Simon Marchi	abe8cab7cb	gdb: enable target_async around stop_all_threads call in process_initial_stop_replies The following scenario hangs: - maint set target-non-stop on - `gdbserver --attach` - a multi-threaded program For example: Terminal 1: $ gnome-calculator& [1] 495731 $ ../gdbserver/gdbserver --once --attach :1234 495731 Attached; pid = 495731 Listening on port 1234 Terminal 2: $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234" Reading symbols from /usr/bin/gnome-calculator... (No debugging symbols found in /usr/bin/gnome-calculator) Remote debugging using :1234 * hangs * What happens is: - The protocol between gdb and gdbserver is in non-stop mode, but the user-visible behavior is all-stop - On connect, gdbserver sends one stop reply for one thread that is stops, the others stay running - In process_initial_stop_replies, gdb calls stop_all_threads to stop these other threads, because we are using the all-stop user-visible mode - stop_all_threads sends a stop request for all the running threads and then waits for resulting events - At this point, the remote target is in target_async(0) mode, which makes stop_all_threads not consider it for events - stop_all_threads loops indefinitely (it does not even block indefinitely, it is in an infinite busy loop) because there are no event sources. wait_one_event returns a TARGET_WAITKIND_NO_RESUMED wait status. Fix that by making the remote target async around the stop_all_threads call. I haven't implemented it because I'm not sure how to do it, but I think it would be a good idea to have, in stop_all_threads / wait_one / handle_one, an assert to check that if we are expecting one or more event, then there are some targets that are in a state where they can supply some events. Otherwise, we'll necessarily be stuck in this infinite loop, and it's probably due to a bug in GDB. I'm not too sure where to put this or how to express it though. Perhaps in stop_all_threads, here: for (int i = 0; i < waits_needed; i++) { wait_one_event event = wait_one (); here if (handle_one (event)) break; } If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED, there's a problem. We expect some event, because we've asked some threads to stop, but all targets are answering that they won't have any events for us. That's a contradiction, and a sign that something has gone wrong. It could perhaps event be: gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED); in handle_one, as the idea is the same in prepare_for_detach. A bit more sophisticated would be: we know which targets we are expecting waits from, since we know which threads we have asked to stop. So if any of these targets returns TARGET_WAITKIND_NO_RESUMED, something is fishy. Add a test that tests attaching with gdbserver's --attach flag to a multi-threaded program, and then connecting to it. Without the fix, the test reproduces the hang. Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f	5 years ago
GDB Administrator	f08d6b8e02	Automatic date update in version.in	5 years ago
Simon Marchi	b5572c42cc	gdb: fix darwin-nat build (again) I made a mistake in the previous patch. Adjust the format string to match the arguments. Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba	5 years ago
Simon Marchi	8c12140439	gdb: fix darwin-nat build There are two errors of this kind: CXX darwin-nat.o /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat] ptid.pid (), ptid.tid ()); ^~~~~~~~~~~ Fix them by using ptid_t's to_string method. Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7	5 years ago
Simon Marchi	4872f9a1b5	gdb.base/foll-fork.exp: accept "info breakpoints" output in any order The test currently requires the "inf 1" breakpoint to be before the "inf 2" breakpoint. This is not always the case: info breakpoints 2 Num Type Disp Enb Address What 2 breakpoint keep y <MULTIPLE> 2.1 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2 2.2 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1 (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints Since add_location_to_breakpoint uses only the address as a criterion to sort locations, the order of locations at the same address is not stable: it will depend on the insertion order. Here, the insertion order comes from the order of SALs when creating the breakpoint, which can vary from machine to machine. While it would be more user-friendly to have a more stable order for printed breakpoint locations, it doesn't really matter for this test, and it would be hard to define an order that will be the same everywhere, all the time. So, loosen the regexp to accept "inf 1" and "inf 2" in any order. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16	5 years ago
Cooper Qu	3a6a0158ee	RISC-V: Fix wrong version number when arch contains 'p'. When specify a default version for p extension in riscv_supported_std_ext[](elfxx-riscv.c) and assembling with -march=rv32imacp, the c extension's version in attribute will become 0p0, the expectation is 2p0. TODO: Remember to add testcase when we have supported standrad p in the future. bfd/ PR gas/28372 * elfxx-riscv.c (riscv_parsing_subset_version): Break if p represent the 'p' extension. Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59	5 years ago
Nelson Chu	69a61890cb	RISC-V: Allow to add numbers in the prefixed extension names. We need to allow adding numbers in the prefixed extension names, since the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec recently. But there are two restrictions as follows, * The extension name ends with <number>p is invalid, since this may be confused with extension with <number>.0 version. We report errors for this case. Invalid format: [z\|h\|s\|zvm\|x][0-9a-z]+[0-9]+p * The extension name ends with numbers is valid, but the numbers will be parsed as major version, so try to avoid naming extensions like this. bfd/ * elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from riscv_valid_prefixed_ext/ (riscv_parsing_subset_version): The extensions end with <number>p is forbidden, we already report the detailed errors in the riscv_parse_prefixed_ext, so clean the code and unused parameters. (riscv_parse_std_ext): Updated. (riscv_parse_prefixed_ext): Rewrite the parser to allow numbers in the prefixed extension names. gas/ * testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases. * testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise. * testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise. * testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise. * testsuite/gas/riscv/march-fail-invalid.l: Likewise. * testsuite/gas/riscv/march-fail-version-x.d: Removed. * testsuite/gas/riscv/march-fail-version-z.d: Likewise. * testsuite/gas/riscv/march-fail-version.l: Likewise.	5 years ago
Andrew Burgess	91f2597bd2	gdb: print backtrace for internal error/warning This commit builds on previous work to allow GDB to print a backtrace of itself when GDB encounters an internal-error or internal-warning. This fixes PR gdb/26377. There's not many places where we call internal_warning, and I guess in most cases the user would probably continue their debug session. And so, in order to avoid cluttering up the output, by default, printing of a backtrace is off for internal-warnings. In contrast, printing of a backtrace is on by default for internal-errors, as I figure that in most cases hitting an internal-error is going to be the end of the debug session. Whether a backtrace is printed or not can be controlled with the new settings: maintenance set internal-error backtrace on\|off maintenance show internal-error backtrace maintenance set internal-warning backtrace on\|off maintenance show internal-warning backtrace Here is an example of what an internal-error now looks like with the backtrace included: (gdb) maintenance internal-error blah ../../src.dev-3/gdb/maint.c:82: internal-error: blah A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x5c61ca gdb_internal_backtrace_1 ../../src.dev-3/gdb/bt-utils.c:123 0x5c626d _Z22gdb_internal_backtracev ../../src.dev-3/gdb/bt-utils.c:165 0xe33237 internal_vproblem ../../src.dev-3/gdb/utils.c:393 0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag ../../src.dev-3/gdb/utils.c:470 0x1549652 _Z14internal_errorPKciS0_z ../../src.dev-3/gdbsupport/errors.cc:55 0x9c7982 maintenance_internal_error ../../src.dev-3/gdb/maint.c:82 0x636f57 do_simple_func ../../src.dev-3/gdb/cli/cli-decode.c:97 .... snip, lots more backtrace lines .... --------------------- ../../src.dev-3/gdb/maint.c:82: internal-error: blah A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. ../../src.dev-3/gdb/maint.c:82: internal-error: blah A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n My hope is that this backtrace might make it slightly easier to diagnose GDB issues if all that is provided is the console output, I find that we frequently get reports of an assert being hit that is located in pretty generic code (frame.c, value.c, etc) and it is not always obvious how we might have arrived at the assert. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377	5 years ago
Andrew Burgess	abbbd4a3e0	gdb: use libbacktrace to create a better backtrace for fatal signals GDB recently gained the ability to print a backtrace when a fatal signal is encountered. This backtrace is produced using the backtrace and backtrace_symbols_fd API available in glibc. However, in order for this API to actually map addresses to symbol names it is required that the application (GDB) be compiled with -rdynamic, which GDB is not by default. As a result, the backtrace produced often looks like this: Fatal signal: Bus error ----- Backtrace ----- ./gdb/gdb[0x80ec00] ./gdb/gdb[0x80ed56] /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0] /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f] ./gdb/gdb[0x15495ba] ./gdb/gdb[0x15489b8] ./gdb/gdb[0x9b794d] ./gdb/gdb[0x9b7a6d] ./gdb/gdb[0x9b943b] ./gdb/gdb[0x9b94a1] ./gdb/gdb[0x4175dd] /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3] ./gdb/gdb[0x4174de] --------------------- This is OK if you have access to the exact same build of GDB, you can manually map the addresses back to symbols, however, it is next to useless if all you have is a backtrace copied into a bug report. GCC uses libbacktrace for printing a backtrace when it encounters an error. In recent commits I added this library into the binutils-gdb repository, and in this commit I allow this library to be used by GDB. Now (when GDB is compiled with debug information) the backtrace looks like this: ----- Backtrace ----- 0x80ee08 gdb_internal_backtrace ../../src/gdb/event-top.c:989 0x80ef0b handle_fatal_signal ../../src/gdb/event-top.c:1036 0x7f24539dd6af ??? 0x7f2453a97a5f ??? 0x154976f gdb_wait_for_event ../../src/gdbsupport/event-loop.cc:613 0x1548b6d _Z16gdb_do_one_eventv ../../src/gdbsupport/event-loop.cc:237 0x9b7b02 start_event_loop ../../src/gdb/main.c:421 0x9b7c22 captured_command_loop ../../src/gdb/main.c:481 0x9b95f0 captured_main ../../src/gdb/main.c:1353 0x9b9656 _Z8gdb_mainP18captured_main_args ../../src/gdb/main.c:1368 0x4175ec main ../../src/gdb/gdb.c:32 --------------------- Which seems much more useful. Use of libbacktrace is optional. If GDB is configured with --disable-libbacktrace then the libbacktrace directory will not be built, and GDB will not try to use this library. In this case GDB would try to use the old backtrace and backtrace_symbols_fd API. All of the functions related to writing the backtrace of GDB itself have been moved into the new files gdb/by-utils.{c,h}.	5 years ago
Andrew Burgess	890026e317	src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS After the previous commit that imported libbacktrace from gcc, this commit updates src-release.sh so that the libbacktrace directory is included in the gdb release tar file. ChangeLog: * src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace.	5 years ago
Andrew Burgess	63a4b10683	Copy in libbacktrace from gcc This copies in libbacktrace from the gcc repository as it was in the commit 62e420293a293608f383d9b9c7f2debd666e9fc9. GDB is going to start using this library soon. A dependency between GDB and libbacktrace has already been added to the top level Makefile, so, after this commit, when building GDB, libbacktrace will be built first. However, libbacktrace is not yet linked into GDB, or used by GDB in any way. It is possible to stop libbacktrace being built by configuring the tree with --disable-libbacktrace. This commit does NOT update src-release.sh, that will be done in the next commit, this commit ONLY imports libbacktrace from gcc. This means that if you try to make a release of GDB from exactly this commit then the release tar file will not include libbacktrace. However, as libbacktrace is an optional dependency this is fine.	5 years ago
Andrew Burgess	fbe3443dcf	gdb: Add a dependency between gdb and libbacktrace GDB is going to start using libbacktrace, so add a build dependency. ChangeLog: * Makefile.def: Add all-gdb dependency on all-libbacktrace. * Makefile.in: Regenerate.	5 years ago
Andrew Burgess	d33228c946	top-level configure: setup target_configdirs based on repository The top-level configure script is shared between the gcc repository and the binutils-gdb repository. The target_configdirs variable in the configure.ac script, defines sub-directories that contain components that should be built for the target using the target tools. Some components, e.g. zlib, are built as both host and target libraries. This causes problems for binutils-gdb. If we run 'make all' in the binutils-gdb repository we end up trying to build a target version of the zlib library, which requires the target compiler be available. Often the target compiler isn't immediately available, and so the build fails. The problem with zlib impacted a previous attempt to synchronise the top-level configure scripts from gcc to binutils-gdb, see this thread: https://sourceware.org/pipermail/binutils/2019-May/107094.html And I'm in the process of importing libbacktrace in to binutils-gdb, which is also a host and target library, and triggers the same issues. I believe that for binutils-gdb, at least at the moment, there are no target libraries that we need to build. In the configure script we build three lists of things we want to build, $configdirs, $build_configdirs, and $target_configdirs, we also build two lists of things we don't want to build, $skipdirs and $noconfigdirs. We then remove anything that is in the lists of things not to build, from the list of things that should be built. My proposal is to add everything in target_configdirs into skipdirs, if the source tree doesn't contain a gcc/ sub-directory. The result is that for binutils-gdb no target tools or libraries will be built, while for the gcc repository, nothing should change. If a user builds a unified source tree, then the target tools and libraries should still be built as the gcc/ directory will be present. I've tested a build of gcc on x86-64, and the same set of target libraries still seem to get built. On binutils-gdb this change resolves the issues with 'make all'. ChangeLog: * configure: Regenerate. * configure.ac (skipdirs): Add the contents of target_configdirs if we are not building gcc.	5 years ago
Gleb Fotengauer-Malinovskiy	0d62064867	PR28391, strip/objcopy --preserve-dates .a: cannot set time After commit `985e026451` copy_archive function began to pass invalid values to the utimensat(2) function when it tries to preserve timestamps in ar archives. This happens because the bfd_stat_arch_elt implementation for ar archives fills only the st_mtim.tv_sec part of the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part and the whole st_atim timespec untouched leaving them uninitialized PR 28391 ar.c (extract_file): Clear buf for preserve_dates. * objcopy.c (copy_archive): Likewise.	5 years ago
Mike Frysinger	cee4c731af	sim: drop weak func attrs on module inits When I first wrote this, I was thinking we'd scan all source files that existed and generate a complete init list. That means for any particular build, we'd probably have a few functions that didn't exist, so weak attributes was necessary. What I ended up scanning though was only the source files that went into a particular build. There was another concern too: a source file might be included, but the build settings would cause all of its contents to be skipped (via CPP defines). So scanning via naive grep would pick up names not actually available. A check of the source tree shows that we never do this, and it's pretty easy to institute a policy that we don't start (by at the very least including a stub init func). The use of weak symbols ends up causing a problem in practice: for a few modules (like profiling), nothing else pulls it in, so the linker omits it entirely, which leads to the profiling module never being available. So drop the weak markings since we know all these funcs will be available.	5 years ago
Cui,Lili	2c02075a8e	x86: Print {bad} on invalid broadcast in OP_E_memory Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast. gas/ PR binutils/28381 * testsuite/gas/i386/bad-bcast.s: Add a new testcase. * testsuite/gas/i386/bad-bcast.d: Likewise. * testsuite/gas/i386/bad-bcast-intel.d: New. opcodes/ PR binutils/28381 * i386-dis.c (static struct): Add no_broadcast. (OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it. (intel_operand_size): mark invalid broadcast with no_broadcast=1. (OP_XMM): Mark scalar_mode with no_broadcast=1.	5 years ago
Simon Marchi	901b98215e	gdb: use intrusive_list for linux-nat lwp_list Replace the manually maintained linked list of lwp_info objects with intrusive_list. Replace the ALL_LWPS macro with all_lwps, which returns a range. Add all_lwps_safe as well, for use in iterate_over_lwps, which currently iterates in a safe manner. Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c	5 years ago
Simon Marchi	676362df18	gdb: add destructor to lwp_info Replace the lwp_free function with a destructor. Make lwp_info non-copyable, since there is now a destructor (we wouldn't want an lwp_info object getting copied and this->arch_private getting deleted twice). Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa	5 years ago
Simon Marchi	b0f6c8d247	gdb: make lwp_info non-POD Initialize all fields in the class declaration directly. This opens the door to using intrusive_list, done in the following patch. Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05	5 years ago
GDB Administrator	a58f2d262b	Automatic date update in version.in	5 years ago
Simon Marchi	da474da158	gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child" We found that when handling forks, two inferiors can unexpectedly share their program space and address space. To reproduce: 1. Using a test program that forks... 2. "set follow-fork-mode child" 3. "set detach-on-fork on" (the default) 4. run to a breakpoint somewhere after the fork Step 4 should have created a new inferior: (gdb) info inferiors Num Description Connection Executable 1 <null> /home/smarchi/build/wt/amd/gdb/fork * 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork By inspecting the state of GDB, we can see that the two inferiors now share one program space and one address space: Inferior 1: (top-gdb) p inferior_list.m_front.num $2 = 1 (top-gdb) p inferior_list.m_front.aspace $3 = (struct address_space ) 0x5595e2520400 (top-gdb) p inferior_list.m_front.pspace $4 = (struct program_space ) 0x5595e2520440 Inferior 2: (top-gdb) p inferior_list.m_front.next.num $5 = 2 (top-gdb) p inferior_list.m_front.next.aspace $6 = (struct address_space ) 0x5595e2520400 (top-gdb) p inferior_list.m_front.next.pspace $7 = (struct program_space ) 0x5595e2520440 You can then run inferior 1 again and the two inferiors will still erroneously share their spaces, but already at this point this is wrong. The cause of the bad {a,p}space sharing is in follow_fork_inferior. When following the child and detaching from the parent, we just re-use the parent's spaces, rather than cloning them. When we switch back to inferior 1 and run again, we find ourselves with two unrelated inferiors sharing spaces. Fix that by creating new spaces for the parent after having moved them to the child. My initial implementation created new spaces for the child instead. Doing this breaks doing "next" over fork(). When "next" start, we record the symtab of the starting location. When the program stops, we compare that symtab with the symtab the program has stopped at. If the symtab or the line number has changed, we conclude the "next" is done. If we create a new program space for the child and copy the parent's program space to it with clone_program_space, it creates new symtabs for the child as well. When the child stop, but still on the fork() line, GDB thinks the "next" is done because the symtab pointers no longer match. In reality they are two symtab instances that represent the same file. But moving the spaces to the child and creating new spaces for the parent, we avoid this problem. Note that the problem described above happens today with "detach-on-fork off" and "follow-fork-mode child", because we create new spaces for the child. This will have to be addressed later. Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is expected to have a location in each inferiors. Without the fix, when the two inferiors erroneously share a program space, GDB reports a single location. Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e	5 years ago
Simon Marchi	8188f382a1	gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixes No behavior change in the test expected, other than in the test names. Change-Id: I111137483858ab0f23138439f2930009779a2b3d	5 years ago

1 2 3 4 5 ...

107605 Commits (13084383e8955c2ff7017ac8839301688a9ee34d) All Branches Search

107605 Commits (13084383e8955c2ff7017ac8839301688a9ee34d)

All Branches