aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-02-05[gdb/breakpoints] Fix segfault for catch syscall -1Tom de Vries4-0/+17
Using a hello world a.out, I run into a segfault: ... $ gcc hello.c $ gdb -batch a.out -ex "catch syscall -1" -ex r Catchpoint 1 (syscall -1) Aborted (core dumped) ... Fix this by erroring out if a negative syscall number is used in the catch syscall command. Tested on x86_64-linux. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR breakpoints/27313 * break-catch-syscall.c (catch_syscall_split_args): Reject negative syscall numbers. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR breakpoints/27313 * gdb.base/catch-syscall.exp: Check that "catch syscall -1" is rejected.
2021-02-05Return unique_ptr from language_defn::get_compile_contextTom Tromey7-32/+48
This changes language_defn::get_compile_context to return a unique_ptr. This makes the ownership transfer clear. gdb/ChangeLog 2021-02-05 Tom Tromey <tom@tromey.com> * compile/compile-c-support.c (get_compile_context) (c_get_compile_context, cplus_get_compile_context): Change return type. * language.c (language_defn::get_compile_instance): New method. * language.h (language_defn::get_compile_instance): Change return type. No longer inline. * c-lang.c (c_language::get_compile_instance): Change return type. (cplus_language::get_compile_instance): Change return type. * c-lang.h (c_get_compile_context, cplus_get_compile_context): Change return type. * compile/compile.c (compile_to_object): Update.
2021-02-05Extract symbol-writing function from parsersTom Tromey8-129/+78
I noticed that several parsers shared the same code to write a symbol reference to an expression. This patch factors this code out into a new function. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2021-02-05 Tom Tromey <tom@tromey.com> * parser-defs.h (write_exp_symbol_reference): Declare. * parse.c (write_exp_symbol_reference): New function. * p-exp.y (variable): Use write_exp_symbol_reference. * m2-exp.y (variable): Use write_exp_symbol_reference. * f-exp.y (variable): Use write_exp_symbol_reference. * d-exp.y (PrimaryExpression): Use write_exp_symbol_reference. * c-exp.y (variable): Use write_exp_symbol_reference.
2021-02-05[gdb/testsuite] Add KFAILs for PR symtab/24549Tom de Vries3-3/+37
When an executable contains an index such as a .gdb_index or .debug_names section, gdb ignores the DW_AT_subprogram attribute. This problem has been filed as PR symtab/24549. Add KFAILs for this PR in test-cases gdb.dwarf2/main-subprogram.exp and gdb.fortran/mixed-lang-stack.exp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/main-subprogram.exp: Add KFAIL for PR symtab/24549. * gdb.fortran/mixed-lang-stack.exp: Same.
2021-02-05[gdb/exp] Fix assert when adding ptr to imaginary unitTom de Vries6-2/+36
I'm running into this assertion failure: ... $ gdb -batch -ex "p (void *)0 - 5i" gdbtypes.c:3430: internal-error: \ type* init_complex_type(const char*, type*): Assertion \ `target_type->code () == TYPE_CODE_INT \ || target_type->code () == TYPE_CODE_FLT' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ... This is a regression since commit c34e8714662 "Implement complex arithmetic". Before that commit we had: ... (gdb) p (void *)0 - 5i Argument to arithmetic operation not a number or boolean. ... Fix this in complex_binop by throwing an error, such that we have: ... (gdb) print (void *)0 - 5i Argument to complex arithmetic operation not supported. ... Tested on x86_64-linux. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR exp/27265 * valarith.c (complex_binop): Throw an error if complex type can't be created. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR exp/27265 * gdb.base/complex-parts.exp: Add tests.
2021-02-05[gdb/symtab] Fix duplicate CUs in create_cus_from_debug_names_listTom de Vries4-0/+28
When running test-case gdb.dwarf2/clang-debug-names.exp, I run into the following warning: ... (gdb) file clang-debug-names^M Reading symbols from clang-debug-names...^M warning: Section .debug_aranges in clang-debug-names has duplicate \ debug_info_offset 0xc7, ignoring .debug_aranges.^M ... This is caused by a missing return in commit 3ee6bb113af "[gdb/symtab] Fix incomplete CU list assert in .debug_names". Fix this by adding the missing return, such that we have instead this warning: ... (gdb) file clang-debug-names^M Reading symbols from clang-debug-names...^M warning: Section .debug_aranges in clang-debug-names \ entry at offset 0 debug_info_offset 0 does not exists, \ ignoring .debug_aranges.^M ... which is a known problem filed as PR25969 - "Ignoring .debug_aranges with clang .debug_names". Tested on x86_64-linux. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR symtab/27307 * dwarf2/read.c (create_cus_from_debug_names_list): Add missing return. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR symtab/27307 * gdb.dwarf2/clang-debug-names.exp: Check file command warnings.
2021-02-05[gdb/symtab] Fix indentation in create_cus_from_debug_names_listTom de Vries2-15/+21
Fix indentation in !map.augmentation_is_gdb part of create_cus_from_debug_names_list. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (create_cus_from_debug_names_list): Fix indentation.
2021-02-04gdb: riscv: enable sim integrationMike Frysinger2-0/+5
Now the simulator can be loaded via gdb using "target sim".
2021-02-04gdb: make target_is_non_stop_p return boolSimon Marchi3-3/+8
gdb/ChangeLog: * target.c (target_is_non_stop_p): Return bool. * target.h (target_is_non_stop_p): Return bool. Change-Id: Icdb37ffe917798e59b822976794d4b1b7aafd709
2021-02-04gdb: Use correct feature in tdesc-regs for ARCShahab Vahedi2-1/+6
tdesc-regs.exp test fails for ARC because the test is not using the correct XML files as target description. With this change, the correct directory and files are used. v2 (after Andrew's remark [1]): - Update the feature file names again. Test results now: Test run by shahab on Tue Jan 26 11:31:16 2021 Target is arc-default-elf32 Host is x86_64-unknown-linux-gnu === gdb tests === Schedule of variations: arc-nsim Running target arc-nsim Running /src/gdb/testsuite/gdb.xml/tdesc-regs.exp ... PASS: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml PASS: gdb.xml/tdesc-regs.exp: cd to directory holding xml PASS: gdb.xml/tdesc-regs.exp: set tdesc filename test-extra-regs.xml... PASS: gdb.xml/tdesc-regs.exp: ptype $extrareg PASS: gdb.xml/tdesc-regs.exp: ptype $uintreg PASS: gdb.xml/tdesc-regs.exp: ptype $vecreg PASS: gdb.xml/tdesc-regs.exp: ptype $unionreg PASS: gdb.xml/tdesc-regs.exp: ptype $unionreg.v4 PASS: gdb.xml/tdesc-regs.exp: ptype $structreg PASS: gdb.xml/tdesc-regs.exp: ptype $structreg.v4 PASS: gdb.xml/tdesc-regs.exp: ptype $bitfields PASS: gdb.xml/tdesc-regs.exp: ptype $flags PASS: gdb.xml/tdesc-regs.exp: ptype $mixed_flags PASS: gdb.xml/tdesc-regs.exp: maintenance print reggroups PASS: gdb.xml/tdesc-regs.exp: core-only.xml: set tdesc filename... PASS: gdb.xml/tdesc-regs.exp: core-only.xml: ptype $extrareg === gdb Summary === # of expected passes 16 [1] https://sourceware.org/pipermail/gdb-patches/2021-January/175465.html gdb/testsuite/ChangeLog: * gdb.xml/tdesc-regs.exp: Use correct core-regs for ARC.
2021-02-04gdb: make record-full clear async handler in waitSimon Marchi2-1/+9
For the same reason explained in the previous patch (which was for the record-btrace target), move clearing of the async event handler of the record-full target to the wait method. I'm not sure if/where that target needs to re-set its async event handler in the wait method. Since it only supports a single thread, there probably can't be multiple events to report at the same time. gdb/ChangeLog: * record-full.c (record_full_async_inferior_event_handler): Don't clear async event handler. (record_full_base_target::wait): Clear async event handler at beginning. Change-Id: I146fbdb53d99e3a32766ac7cd337ac5ed7fd9adf
2021-02-04gdb: make record-btrace clear event handler in waitSimon Marchi2-1/+10
For the same reason explained in the previous patch (which was for the remote target), move clearing of the async event handler of the record-btrace target to the wait method. The record-btrace target already re-sets its async event handler in its wait method, so that part doesn't need to be changed: /* In async mode, we need to announce further events. */ if (target_is_async_p ()) record_btrace_maybe_mark_async_event (moving, no_history); gdb/ChangeLog: * record-btrace.c (record_btrace_handle_async_inferior_event): Don't clear async event handler. (record_btrace_target::wait): Clear async event handler at beginning. Change-Id: Ib32087a81bf94f1b884a938c8167ac8bbe09e362
2021-02-04gdb: make remote target clear its handler in remote_target::waitSimon Marchi2-20/+19
The remote target's remote_async_inferior_event_token is a flag that tells when it wants the infrun loop to call its wait method. The flag is cleared in the async_event_handler's callback (remote_async_inferior_event_handler), just before calling inferior_event_handler. However, since inferior_event_handler may actually call another target's wait method, there needs to be code that checks if we need to re-raise the flag. It would be simpler instead for remote_target::wait to clear the flag when it returns an event and there are no more to report after that. If another target's wait method gets called by inferior_event_handler, the remote target's flag will stay naturally stay marked. Note that this is already partially implemented in remote_target::wait, since the remote target may have multiple events to report (and it can only report one at the time): if (target_is_async_p ()) { remote_state *rs = get_remote_state (); /* If there are are events left in the queue tell the event loop to return here. */ if (!rs->stop_reply_queue.empty ()) mark_async_event_handler (rs->remote_async_inferior_event_token); } The code in remote_async_inferior_event_handler also checks for pending events as well, in addition to the stop reply queue, so I've made remote_target::wait check for that as well. I'm not completely sure this is ok, since I don't understand very well how the pending events mechanism works. But I figured it was safer to do this, worst case it just leads to unnecessary calls to remote_target::wait. gdb/ChangeLog: * remote.c (remote_target::wait): Clear async event handler at beginning, mark if needed at the end. (remote_async_inferior_event_handler): Don't set or clear async event handler. Change-Id: I20117f5b5acc8a9972c90f16280249b766c1bf37
2021-02-04gdb: make async event handlers clear themselvesSimon Marchi8-4/+33
The `ready` flag of async event handlers is cleared by the async event handler system right before invoking the associated callback, in check_async_event_handlers. This is not ideal with how the infrun subsystem consumes events: all targets' async event handler callbacks essentially just invoke `inferior_event_handler`, which eventually calls `fetch_inferior_event` and `do_target_wait`. `do_target_wait` picks an inferior at random, and thus a target at random (it could be the target whose `ready` flag was cleared, or not), and pulls one event from it. So it's possible that: - the async event handler for a target A is called - we end up consuming an event for target B - all threads of target B are stopped, target_async(0) is called on it, so its async event handler is cleared (e.g. record_btrace_target::async) As a result, target A still has events to report while its async event handler is left unmarked, so these events are not consumed. To counter this, at the end of their async event handler callbacks, targets check if they still have something to report and re-mark their async event handler (e.g. remote_async_inferior_event_handler). The linux_nat target does not suffer from this because it doesn't use an async event handler at the moment. It only uses a pipe registered with the event loop. It is written to in the SIGCHLD handler (and in other spots that want to get target wait method called) and read from in the target's wait method. So if linux_nat happened to be target A in the example above, the pipe would just stay readable, and the event loop would wake up again, until linux_nat's wait method is finally called and consumes the contents of the pipe. I think it would be nicer if targets using async_event_handler worked in a similar way, where the flag would stay set until the target's wait method is actually called. As a first step towards that, this patch moves the responsibility of clearing the ready flags of async event handlers to the invoked callback. All async event handler callbacks are modified to clear their ready flag before doing anything else. So in practice, nothing changes with this patch. It's only the responsibility of clearing the flag that is shifted toward the callee. gdb/ChangeLog: * async-event.h (async_event_handler_func): Add documentation. * async-event.c (check_async_event_handlers): Don't clear async_event_handler ready flag. * infrun.c (infrun_async_inferior_event_handler): Clear ready flag. * record-btrace.c (record_btrace_handle_async_inferior_event): Likewise. * record-full.c (record_full_async_inferior_event_handler): Likewise. * remote-notif.c (remote_async_get_pending_events_handler): Likewise. * remote.c (remote_async_inferior_event_handler): Likewise. Change-Id: I179ef8e99580eae642d332846fd13664dbddc0c1
2021-02-03gdb: infrun: move stop_soon variable to inner scoped in handle_inferior_eventSimon Marchi2-66/+71
Moving it to an inner scope makes it clearer where it's used (only while handling the TARGET_WAITKIND_LOADED event). gdb/ChangeLog: * infrun.c (handle_inferior_event): Move stop_soon variable to inner scope. Change-Id: Ic57685a21714cfbb38f1487ee96cea1d12b44652
2021-02-03Testcase for detaching while stepping over breakpointPedro Alves3-0/+407
This adds a testcase that exercises detaching while GDB is stepping over a breakpoint, in all combinations of: - maint target non-stop off/on - set non-stop on/off - displaced stepping on/off This exercises the bugs fixed in the previous 8 patches. gdb/testsuite/ChangeLog: * gdb.threads/detach-step-over.c: New file. * gdb.threads/detach-step-over.exp: New file.
2021-02-03detach in all-stop with threads runningPedro Alves4-52/+138
A following patch will add a testcase that has a number of threads constantly stepping over a breakpoint, and then has GDB detach the process, while threads are running. If we have more than one inferior running, and we detach from just one of the inferiors, we expect that the remaining inferior continues running. However, in all-stop, if GDB needs to pause the target for the detach, nothing is re-resuming the other inferiors after the detach. "info threads" shows the threads as running, but they really aren't. This fixes it. gdb/ChangeLog: * infcmd.c (detach_command): Hold strong reference to target, and if all-stop on entry, restart threads on exit. * infrun.c (switch_back_to_stepped_thread): Factor out bits to ... (restart_stepped_thread): ... this new function. Also handle trap_expected. (restart_after_all_stop_detach): New function. * infrun.h (restart_after_all_stop_detach): Declare.
2021-02-03detach with in-line step over in progressPedro Alves2-4/+46
A following patch will add a testcase that has a number of threads constantly stepping over a breakpoint, and then has GDB detach the process. That testcase exercises both "set displaced-stepping on/off". Testing with "set displaced-stepping off" reveals that GDB does not handle the case of the user typing "detach" just while some thread is in the middle of an in-line step over. If that thread belongs to the inferior that is being detached, then the step-over never finishes, and threads of other inferiors are never re-resumed. This fixes it. gdb/ChangeLog: * infrun.c (struct step_over_info): Initialize fields. (prepare_for_detach): Handle ongoing in-line step over.
2021-02-03detach and breakpoint removalPedro Alves5-9/+30
A following patch will add a testcase that has a number of threads constantly stepping over a breakpoint, and then has GDB detach the process. That testcase sometimes fails with the inferior crashing with SIGTRAP after the detach because of the bug fixed by this patch, when tested with the native target. The problem is that target_detach removes breakpoints from the target immediately, and that does not work with the native GNU/Linux target (and probably no other native target) currently. The test wouldn't fail with this issue when testing against gdbserver, because gdbserver does allow accessing memory while the current thread is running, by transparently pausing all threads temporarily, without GDB noticing. Implementing that in gdbserver was a lot of work, so I'm not looking forward right now to do the same in the native target. Instead, I came up with a simpler solution -- push the breakpoints removal down to the targets. The Linux target conveniently already pauses all threads before detaching them, since PTRACE_DETACH only works with stopped threads, so we move removing breakpoints to after that. Only the remote and GNU/Linux targets support support async execution, so no other target should really need this. gdb/ChangeLog: * linux-nat.c (linux_nat_target::detach): Remove breakpoints here... * remote.c (remote_target::remote_detach_1): ... and here ... * target.c (target_detach): ... instead of here. * target.h (target_ops::detach): Add comment.
2021-02-03prepare_for_detach and ongoing displaced steppingPedro Alves2-57/+77
I noticed that "detach" while a program was running sometimes resulted in the process crashing. I tracked it down to this change to prepare_for_detach in commit 187b041e ("gdb: move displaced stepping logic to gdbarch, allow starting concurrent displaced steps"): /* Is any thread of this process displaced stepping? If not, there's nothing else to do. */ - if (displaced->step_thread == nullptr) + if (displaced_step_in_progress (inf)) return; The problem above is that the condition was inadvertently flipped. It should have been: if (!displaced_step_in_progress (inf)) So I fixed it, and wrote a testcase to exercise it. The testcase has a number of threads constantly stepping over a breakpoint, and then GDB detaches the process, while threads are running and stepping over the breakpoint. And then I was surprised that my testcase would hang -- GDB would get stuck in an infinite loop in prepare_for_detach, here: while (displaced_step_in_progress (inf)) { ... What is going on is that since we now have two displaced stepping buffers, as one displaced step finishes, GDB starts another, and there's another one already in progress, and on and on, so the displaced_step_in_progress condition never turns false. This happens because we go via the whole handle_inferior_event, which tries to start new step overs when one finishes. And also because while we remove breakpoints from the target before prepare_for_detach is called, handle_inferior_event ends up calling insert_breakpoints via e.g. keep_going. Thinking through all this, I came to the conclusion that going through the whole handle_inferior_event isn't ideal. A _lot_ is done by that function, e.g., some thread may get a signal which is passed to the inferior, and gdb decides to try to get over the signal handler, which reinstalls breakpoints. Or some process may exit. We can end up reporting these events via normal_stop while detaching, maybe end up running some breakpoint commands, or maybe even something runs an inferior function call. Etc. All this after the user has already declared they don't want to debug the process anymore, by asking to detach. I came to the conclusion that it's better to do the minimal amount of work possible, in a more controlled fashion, without going through handle_inferior_event. So in the new approach implemented by this patch, if there are threads of the inferior that we're detaching in the middle of a displaced step, stop them, and cancel the displaced step. This is basically what stop_all_threads already does, via wait_one and (the now factored out) handle_one, so I'm reusing those. gdb/ChangeLog: * infrun.c (struct wait_one_event): Move higher up. (prepare_for_detach): Abort in-progress displaced steps instead of letting them complete. (handle_one): If the inferior is detaching, don't add the thread back to the global step-over chain. (restart_threads): Don't restart threads if detaching. (handle_signal_stop): Remove inferior::detaching reference.
2021-02-03prepare_for_detach: don't release scoped_restore at the endPedro Alves2-6/+6
After detaching from a process, the inf->detaching flag is inadvertently left set to true. If you afterwards reuse the same inferior to start a new process, GDB will mishave... The problem is that prepare_for_detach discards the scoped_restore at the end, while the intention is for the flag to be set only for the duration of prepare_for_detach. This was already a bug in the original commit that added prepare_for_detach, commit 24291992dac3 ("PR gdb/11321"), by yours truly. Back then, we still used cleanups, and the function called discard_cleanups instead of do_cleanups, by mistake. gdb/ChangeLog: * infrun.c (prepare_for_detach): Don't release scoped_restore before returning.
2021-02-03Factor out after-stop event handling code from stop_all_threadsPedro Alves2-138/+157
This moves the code handling an event out of wait_one to a separate function, to be used in another context in a following patch. gdb/ChangeLog: * infrun.c (handle_one): New function, factored out from ... (stop_all_threads): ... here.
2021-02-03Fix a couple vStopped pending ack bugsPedro Alves2-9/+20
A following patch will add a testcase that has two processes with threads stepping over a breakpoint continuously, and then detaches from one of the processes while threads are running. The other process continues stepping over its breakpoint. And then the testcase sends a SIGUSR1, expecting that GDB reports it. That would sometimes hang against gdbserver, due to the bugs fixed here. Both bugs are related, in that they're about remote protocol asynchronous Stop notifications. There's a bug in GDB, and another in GDBserver. The GDB bug: - when we detach from a process, the remote target discards any pending RSP notification related to that process, including the in-flight, yet-unacked notification. Discarding the in-flight notification is the problem. Until the in-flight notification is acked with a vStopped packet, the server won't send another %Stop notification. As a result, the debug session gets messed up. In the new testcase's case, GDB would hang inside stop_all_threads, waiting for a stop for one of the process'es threads, which never arrived -- its stop reply was permanently stuck in the stop reply queue, waiting for a vStopped packet that never arrived. In summary: 1. GDBserver sends stop notification about thread X, the remote target receives it and stores it 2. At the same time, GDB detaches thread X's inferior 3. The remote target discards the received stop notification 4. GDBserver waits forever for the ack The GDBserver bug: GDBserver has the opposite bug. It also discards notifications for the process being detached. If that discards the head of the notification queue, when gdb sends an ack, it ends up acking the _next_ notification. Meaning, gdb loses one notification. In the testcase, this results in a similar hang in stop_all_threads. So we have two very similar bugs in GDB and GDBserver, both resulting in a similar symptom. That's why I'm fixing them both at the same time. gdb/ChangeLog: * remote.c (remote_notif_stop_ack): Don't error out on TARGET_WAITKIND_IGNORE; instead, just ignore the notification. (remote_target::discard_pending_stop_replies): Don't delete in-flight notification; instead, clear its contents. gdbserver/ChangeLog: * server.cc (discard_queued_stop_replies): Don't ever discard the notification at the head of the list.
2021-02-03Testcase for attaching in non-stop modePedro Alves3-0/+211
This adds a testcase exercising attaching to a multi-threaded process, in all combinations of: - set non-stop on/off - maint target non-stop off/on - "attach" vs "attach &" This exercises the bugs fixed in the two previous patches. gdb/testsuite/ChangeLog: * gdb.threads/attach-non-stop.c: New file. * gdb.threads/attach-non-stop.exp: New file.
2021-02-03Fix "target extended-remote" + "maint set target-non-stop" + "attach"Pedro Alves2-1/+11
With "target extended-remote" + "maint set target-non-stop", attaching hangs like so: (gdb) attach 1244450 Attaching to process 1244450 [New Thread 1244450.1244450] [New Thread 1244450.1244453] [New Thread 1244450.1244454] [New Thread 1244450.1244455] [New Thread 1244450.1244456] [New Thread 1244450.1244457] [New Thread 1244450.1244458] [New Thread 1244450.1244459] [New Thread 1244450.1244461] [New Thread 1244450.1244462] [New Thread 1244450.1244463] * hang * Attaching to the hung GDB shows that GDB is busy in an infinite loop in stop_all_threads: (top-gdb) bt #0 stop_all_threads () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:4755 #1 0x000055555597b424 in stop_waiting (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:7738 #2 0x0000555555976fba in handle_signal_stop (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5868 #3 0x0000555555975f6a in handle_inferior_event (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5527 #4 0x0000555555971da4 in fetch_inferior_event () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:3910 #5 0x00005555559540b2 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/pedro/gdb/binutils-gdb/src/gdb/inf-loop.c:42 #6 0x000055555597e825 in infrun_async_inferior_event_handler (data=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:9162 #7 0x0000555555687d1d in check_async_event_handlers () at /home/pedro/gdb/binutils-gdb/src/gdb/async-event.c:328 #8 0x0000555555e48284 in gdb_do_one_event () at /home/pedro/gdb/binutils-gdb/src/gdbsupport/event-loop.cc:216 #9 0x00005555559e7512 in start_event_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:347 #10 0x00005555559e765d in captured_command_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:407 #11 0x00005555559e8f80 in captured_main (data=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1239 #12 0x00005555559e8ff2 in gdb_main (args=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1254 #13 0x0000555555627c86 in main (argc=12, argv=0x7fffffffdc88) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:32 The problem is that the remote sends stops for all the threads: Packet received: l/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/attach-non-stop/attach-non-stop Sending packet: $vStopped#55...Packet received: T0006:f06e25edec7f0000;07:f06e25edec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd2f;core:15; Sending packet: $vStopped#55...Packet received: T0006:f0dea5f0ec7f0000;07:f0dea5f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd27;core:4; Sending packet: $vStopped#55...Packet received: T0006:f0ee25f1ec7f0000;07:f0ee25f1ec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd26;core:5; Sending packet: $vStopped#55...Packet received: T0006:f0bea5efec7f0000;07:f0bea5efec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd29;core:1; Sending packet: $vStopped#55...Packet received: T0006:f0ce25f0ec7f0000;07:f0ce25f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd28;core:a; Sending packet: $vStopped#55...Packet received: T0006:f07ea5edec7f0000;07:f07ea5edec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2e;core:f; Sending packet: $vStopped#55...Packet received: T0006:f0ae25efec7f0000;07:f0ae25efec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd2a;core:6; Sending packet: $vStopped#55...Packet received: T0006:0000000000000000;07:c0e8a381fe7f0000;10:bf43b4f1ec7f0000;thread:p12fd22.12fd22;core:2; Sending packet: $vStopped#55...Packet received: T0006:f0fea5f1ec7f0000;07:f0fea5f1ec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd25;core:8; Sending packet: $vStopped#55...Packet received: T0006:f09ea5eeec7f0000;07:f09ea5eeec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2b;core:b; Sending packet: $vStopped#55...Packet received: OK But then wait_one never consumes them, always hitting this path: 4473 if (nfds == 0) 4474 { 4475 /* No waitable targets left. All must be stopped. */ 4476 return {NULL, minus_one_ptid, {TARGET_WAITKIND_NO_RESUMED}}; 4477 } Resulting in GDB constanly calling target_stop to stop threads, but the remote target never reporting back the stops to infrun. That TARGET_WAITKIND_NO_RESUMED path shown above is always taken because here, in wait_one too, just above: 4428 for (inferior *inf : all_inferiors ()) 4429 { 4430 process_stratum_target *target = inf->process_target (); 4431 if (target == NULL 4432 || !target->is_async_p () ^^^^^^^^^^^^^^^^^^^^^ 4433 || !target->threads_executing) 4434 continue; ... the remote target is not async. And in turn that happened because extended_remote_target::attach misses enabling async in the target-non-stop path. A testcase exercising this will be added in a following patch. gdb/ChangeLog: * remote.c (extended_remote_target::attach): Set target async in the target-non-stop path too.
2021-02-03Fix attaching in non-stop mode (PR gdb/27055)Pedro Alves2-15/+11
Attaching in non-stop mode currently misbehaves, like so: (gdb) attach 1244450 Attaching to process 1244450 [New LWP 1244453] [New LWP 1244454] [New LWP 1244455] [New LWP 1244456] [New LWP 1244457] [New LWP 1244458] [New LWP 1244459] [New LWP 1244461] [New LWP 1244462] [New LWP 1244463] No unwaited-for children left. At this point, GDB's stopped/running thread state is out of sync with the inferior: (gdb) info threads Id Target Id Frame * 1 LWP 1244450 "attach-non-stop" 0xf1b443bf in ?? () 2 LWP 1244453 "attach-non-stop" (running) 3 LWP 1244454 "attach-non-stop" (running) 4 LWP 1244455 "attach-non-stop" (running) 5 LWP 1244456 "attach-non-stop" (running) 6 LWP 1244457 "attach-non-stop" (running) 7 LWP 1244458 "attach-non-stop" (running) 8 LWP 1244459 "attach-non-stop" (running) 9 LWP 1244461 "attach-non-stop" (running) 10 LWP 1244462 "attach-non-stop" (running) 11 LWP 1244463 "attach-non-stop" (running) (gdb) (gdb) interrupt -a (gdb) *nothing* The problem is that attaching installs an inferior continuation, called when the target reports the initial attach stop, here, in inf-loop.c:inferior_event_handler: /* Do all continuations associated with the whole inferior (not a particular thread). */ if (inferior_ptid != null_ptid) do_all_inferior_continuations (0); However, currently in non-stop mode, inferior_ptid is still null_ptid when we get here. If you try to do "set debug infrun 1" to debug the problem, however, then the attach completes correctly, with GDB reporting a stop for each thread. The bug is that we're missing a switch_to_thread/context_switch call when handling the initial stop, here: if (stop_soon == STOP_QUIETLY_NO_SIGSTOP && (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_STOP || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_0)) { stop_print_frame = true; stop_waiting (ecs); ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0; return; } Note how the STOP_QUIETLY / STOP_QUIETLY_REMOTE case above that does call context_switch. And the reason "set debug infrun 1" "fixes" it, is that the debug path has a switch_to_thread call. This patch fixes it by moving the main context_switch call earlier. It also removes the: if (ecs->ptid != inferior_ptid) check at the same time because: #1 - that is half of what context_switch already does #2 - deprecated_context_hook is only used in Insight, and all it does is set an int. It won't care if we call it when the current thread hasn't actually changed. A testcase exercising this will be added in a following patch. gdb/ChangeLog: PR gdb/27055 * infrun.c (handle_signal_stop): Move main context_switch call earlier, before STOP_QUIETLY_NO_SIGSTOP.
2021-02-02Inferior without argument prints detail of current inferior.Lancelot SIX8-21/+135
This patch makes the inferior command display information about the current inferior when called with no argument. This behavior is similar to the one of the thread command. Before patch: (gdb) info inferior Num Description Connection Executable * 1 process 19221 1 (native) /home/lsix/tmp/a.out 2 process 19239 1 (native) /home/lsix/tmp/a.out (gdb) inferior 2 [Switching to inferior 2 [process 19239] (/home/lsix/tmp/a.out)] [Switching to thread 2.1 (process 19239)] #0 0x0000000000401146 in main () (gdb) inferior Argument required (expression to compute). After patch: (gdb) info inferior Num Description Connection Executable * 1 process 18699 1 (native) /home/lsix/tmp/a.out 2 process 18705 1 (native) /home/lsix/tmp/a.out (gdb) inferior 2 [Switching to inferior 2 [process 18705] (/home/lsix/tmp/a.out)] [Switching to thread 2.1 (process 18705)] #0 0x0000000000401146 in main () (gdb) inferior [Current inferior is 2 [process 18705] (/home/lsix/tmp/a.out)] gdb/doc/ChangeLog: * gdb.texinfo (Inferiors Connections and Programs): Document the inferior command when used without argument. gdb/ChangeLog: * NEWS: Add entry for the behavior change of the inferior command. * inferior.c (inferior_command): When no argument is given to the inferior command, display info about the currently selected inferior. gdb/testsuite/ChangeLog: * gdb.base/inferior-noarg.c: New test. * gdb.base/inferior-noarg.exp: New test.
2021-02-02gdb/testsuite: use proc_with_prefix in gdb.base/scope.expSimon Marchi2-5/+9
Fixes: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/scope.exp ... DUPLICATE: gdb.base/scope.exp: print 'scope0.c'::filelocal_ro DUPLICATE: gdb.base/scope.exp: print 'scope0.c'::filelocal_ro DUPLICATE: gdb.base/scope.exp: next gdb/testsuite/ChangeLog: * gdb.base/scope.exp: Use proc_with_prefix. Change-Id: Ic40e24a603da6f2a4f8003b74b2ff3040d2b098d
2021-02-02gdb/testsuite: add test for .debug_{rng,loc}lists section without offset arraySimon Marchi5-13/+164
It is possible for the tables in the .debug_{rng,loc}lists sections to not have an array of offsets. In that case, the offset_entry_count field of the header is 0. The forms DW_FORM_{rng,loc}listx (reference by index) can't be used with that table. Instead, the DW_FORM_sec_offset form, which references a {rng,loc}list by direct offset in the section, must be used. From what I saw, this is what GCC currently produces. Add tests for this case. I didn't see any bug related to this, I just think that it would be nice to have coverage for this. A new `-with-offset-array` option is added to the `table` procs, used when generating {rng,loc}lists, to decide whether to generate the offset array. gdb/testsuite/ChangeLog: * lib/dwarf.exp (rnglists): Add -no-offset-array option to table proc. * gdb.dwarf2/rnglists-sec-offset.exp: Add test for .debug_rnglists table without offset array. * gdb.dwarf2/loclists-sec-offset.exp: Add test for .debug_loclists table without offset array. Change-Id: I8e34a7bf68c9682215ffbbf66600da5b7db91ef7
2021-02-02gdb/dwarf: make read_{loc,rng}list_index return sect_offsetSimon Marchi2-10/+18
I think it's wrong that read_loclist_index and read_rnglist_index return a CORE_ADDR. A CORE_ADDR is an address in the program. These functions return offset in sections (.debug_loclists and .debug_rnglists). I think sect_offset is more appropriate. I'm wondering if struct attribute should have a "set_sect_offset" method, that takes a sect_offset parameter, or if it's better to be left as a simple "unsigned". gdb/ChangeLog: * dwarf2/read.c (read_loclist_index, read_rnglist_index): Return a sect_offset. (read_attribute_reprocess): Adjust. Change-Id: I0e22e0864130fb490072b41ae099762918b8ad4d
2021-02-02gdb/dwarf: split dwarf2_cu::ranges_base in twoSimon Marchi7-85/+251
Consider the test case added in this patch. It defines a compilation unit with a DW_AT_rnglists_base attribute (used for attributes of form DW_FORM_rnglistx), but also uses DW_AT_ranges of form DW_FORM_sec_offset: 0x00000027: DW_TAG_compile_unit DW_AT_ranges [DW_FORM_sec_offset] (0x0000004c [0x0000000000005000, 0x0000000000006000)) DW_AT_rnglists_base [DW_FORM_sec_offset] (0x00000044) The DW_AT_rnglists_base does not play a role in reading the DW_AT_ranges of form DW_FORM_sec_offset, but it should also not do any harm. This case is currently not handled correctly by GDB. This is not something that a compiler is likely to emit, but in my opinion there's no reason why GDB should fail reading it. The problem is that in partial_die_info::read and a few other places where the same logic is replicated, the cu->ranges_base value, containing the DW_AT_rnglists_base value, is wrongfully added to the DW_AT_ranges value. It is quite messy how to decide whether cu->ranges_base should be added to the attribute's value or not. But to summarize, the only time we want to add it is when the attribute comes from a pre-DWARF 5 split unit file (a .dwo) [1]. In this case, the DW_AT_ranges attribute from the split unit file will have form DW_FORM_sec_offset, pointing somewhere in the linked file's .debug_ranges section. *But* it's not a "true" DW_FORM_sec_offset, in that it's an offset relative to the beginning of that CU's contribution in the section, not relative to the beginning of the section. So in that case, and only that case, do we want to add the ranges base value, which we found from the DW_AT_GNU_ranges_base attribute on the skeleton unit. Almost all instances of the DW_AT_ranges attribute will be found in the split unit (on DW_TAG_subprogram, for example), and therefore need to have the ranges base added. However, the DW_TAG_compile_unit DIE in the skeleton may also have a DW_AT_ranges attribute. For that one, the ranges base must not be added. Once the DIEs have been loaded in GDB, however, the distinction between what's coming from the skeleton and what's coming from the split unit is not clear. It is all merged in one big happy tree. So how do we know if a given attribute comes from the split unit or not? We use the fact that in pre-DWARF 5 split DWARF, DW_AT_ranges is found on the skeleton's DW_TAG_compile_unit (in the linked file) and never in the split unit's DW_TAG_compile_unit. This is why you have this in partial_die_info::read: int need_ranges_base = (tag != DW_TAG_compile_unit && attr.form != DW_FORM_rnglistx); However, with the corner case described above (where we have a DW_AT_rnglists_base attribute and a DW_AT_ranges attribute of form DW_FORM_sec_offset) the condition gets it wrong when it encounters an attribute like DW_TAG_subprogram with a DW_AT_ranges attribute of DW_FORM_sec_offset form: it thinks that it is necessary to add the base, when it reality it is not. The problem boils down to failing to differentiate these cases: - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a pre-DWARF 5 split unit (in which case we need to add the base) - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a DWARF 5 non-split unit (in which case we must not add the base) What makes it unnecessarily complex is that the cu->ranges_base field is overloaded, used to hold the pre-DWARF 5, non-standard DW_AT_GNU_ranges_base and the DWARF 5 DW_AT_rnglists_base. In reality, these two are called "bases" but are not the same thing. The result is that we need twisted conditions to try to determine whether or not we should add the base to the attribute's value. To fix it, split the field in two distinct fields. I renamed everything related to the "old" ranges base to "gnu_ranges_base", to make it clear that it's about the non-standard, pre-DWARF 5 thing. And everything related to the DWARF 5 thing gets renamed "rnglists". I think it becomes much easier to reason this way. The issue described above gets fixed by the fact that the DW_AT_rnglists_base value does not end up in cu->gnu_ranges_base, so cu->gnu_ranges_base stays 0. The condition to determine whether gnu_ranges_base should be added can therefore be simplified back to: tag != DW_TAG_compile_unit ... as it was before rnglistx support was added. Extend the gdb.dwarf2/rnglists-sec-offset.exp to cover this case. I also extended the test case for loclists similarly, just to see if there would be some similar problem. There wasn't, but I think it's not a bad idea to test that case for loclists as well, so I left it in the patch. [1] https://gcc.gnu.org/wiki/DebugFission gdb/ChangeLog: * dwarf2/die.h (struct die_info) <ranges_base>: Split in... <gnu_ranges_base>: ... this... <rnglists_base>: ... and this. * dwarf2/read.c (struct dwarf2_cu) <ranges_base>: Split in... <gnu_ranges_base>: ... this... <rnglists_base>: ... and this. (read_cutu_die_from_dwo): Adjust (dwarf2_get_pc_bounds): Adjust (dwarf2_record_block_ranges): Adjust. (read_full_die_1): Adjust (partial_die_info::read): Adjust. (read_rnglist_index): Adjust. gdb/testsuite/ChangeLog: * gdb.dwarf2/rnglists-sec-offset.exp: Add test for DW_AT_ranges of DW_FORM_sec_offset form plus DW_AT_rnglists_base attribute. * gdb.dwarf2/loclists-sec-offset.exp: Add test for DW_AT_location of DW_FORM_sec_offset plus DW_AT_loclists_base attribute Change-Id: Icd109038634b75d0e6e9d7d1dcb62fb9eb951d83
2021-02-02gdb/testsuite: add .debug_loclists testsSimon Marchi6-0/+551
Add tests for the various issues fixed in the previous patches. Add a new "loclists" procedure to the DWARF assembler, to allow generating .debug_loclists sections. gdb/testsuite/ChangeLog: PR gdb/26813 * lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_loclistx. (loclists): New proc. * gdb.dwarf2/loclists-multiple-cus.c: New. * gdb.dwarf2/loclists-multiple-cus.exp: New. * gdb.dwarf2/loclists-sec-offset.c: New. * gdb.dwarf2/loclists-sec-offset.exp: New. Change-Id: I209bcb2a9482762ae943e518998d1f7761f76928
2021-02-02gdb/testsuite: DWARF assembler: add context parameters to _locationSimon Marchi2-13/+32
The _location proc is used to assemble a location description. It needs to know some contextual information: - size of an address - size of an offset (into another DWARF section) - DWARF version It currently get all this directly from global variables holding the compilation unit information. This is fine because as of now, all location descriptions are generated in the context of creating a compilation unit. However, a subsequent patch will generate location descriptions while generating a .debug_loclists section. _location should therefore no longer rely on the current compilation unit's properties. Change it to accept these values as parameters instead of accessing the values for the CU. No functional changes intended. gdb/testsuite/ChangeLog: * lib/dwarf.exp (_location): Add parameters. (_handle_DW_FORM): Adjust. Change-Id: Ib94981979c83ffbebac838081d645ad71c221637
2021-02-02gdb/testsuite: add .debug_rnglists testsSimon Marchi4-3/+375
Add tests for the various issues fixed in the previous patches. Add a new "rnglists" procedure to the DWARF assembler, to allow generating .debug_rnglists sections. A trivial change is required to support the DWARF 5 CU header layout. gdb/testsuite/ChangeLog: PR gdb/26813 * lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_rnglistx. (cu): Generate header for DWARF 5. (rnglists): New proc. * gdb.dwarf2/rnglists-multiple-cus.exp: New. * gdb.dwarf2/rnglists-sec-offset.exp: New. Change-Id: I5b297e59c370c60cf671dec19796a6c3b9a9f632
2021-02-02gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_indexSimon Marchi2-6/+47
When loading the binary from PR 26813 in GDB, we get: DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse] ... and the symbols fail to load. In read_rnglist_index and read_loclist_index, we read the header (documented in sections 7.28 and 7.29 of DWARF 5) of the CU's contribution to the .debug_rnglists / .debug_loclists sections to validate that the index we want to read makes sense. However, we always read the header at the beginning of the section, rather than the header for the contribution from which we want to read the index. To illustrate, here's what the binary from PR 26813 contains. There are two compile units: 0x0000000c: DW_TAG_compile_unit 1 DW_AT_ranges [DW_FORM_rnglistx]: 0x0 DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC 0x00003ec9: DW_TAG_compile_unit 2 DW_AT_ranges [DW_FORM_rnglistx]: 0xB DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85 The layout of the .debug_rnglists is the following: [0x00, 0x0B]: header for CU 1's contribution [0x0C, 0x0F]: list of offsets for CU 1 (1 element) [0x10, 0x78]: range lists data for CU 1 [0x79, 0x84]: header for CU 2's contribution [0x85, 0xB4]: list of offsets for CU 2 (12 elements) [0xB5, 0xBD7]: range lists data for CU 2 The DW_AT_rnglists_base attrbute points to the beginning of the list of offsets for that CU, relative to the start of the .debug_rnglists section. That's right after the header for that contribution. When we try to read the DW_AT_ranges attribute for CU 2, read_rnglist_index reads the header for CU 1 instead of the one for CU 2. Since there's only one element in CU 1's offset list, it believes (wrongfully) that the index 0xB is out of range. Fix it by reading the header just before where DW_AT_rnglists_base points to. With this patch, I am able to load GDB built with clang-11 and -gdwarf-5 in itself, with and without -readnow. gdb/ChangeLog: PR gdb/26813 * dwarf2/read.c (read_loclists_rnglists_header): Add header_offset parameter and use it. (read_loclist_index): Read header of the current contribution, not the one at the beginning of the section. (read_rnglist_index): Likewise. Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d
2021-02-02gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listxSimon Marchi4-4/+31
We hit an assertion when loading the binary from PR 26813. When fixing it, execution goes a up bit further but then hits another assert, and another, and another. With these fours fixes, I am able to load the binary and get to the prompt. An error is shown (index pointing outside of the section), because the DW_FORM_rnglistx attribute is not read correctly, but that one is taken care of by the next patch. The four fixes are: - attribute::form_requires_reprocessing needs to handle forms DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess is called for them in read_attribute_value. - read_attribute_reprocess must call set_unsigned for them, not set_address. The parameter of set_address is a CORE_ADDR, meaning it's for program addresses. Post-reprocess, DW_FORM_rnglistx and DW_FORM_loclistx are offsets into their respective sections (.debug_rnglists and .debug_loclists). set_unsigned is the current attribute value setter that fits the best. But perhaps we should have a setter that takes a sect_offset? - read_attribute_process must call as_unsigned_reprocess instead of as_unsigned to get the pre-reprocess value, otherwise we hit the assert inside as_unsigned that makes sure the attribute doesn't need reprocessing. - attribute::set_unsigned needs to clear the requires_reprocessing flag, otherwise it stays set when reprocessing DW_FORM_rnglistx and DW_FORM_loclistx attributes. There's another assert that we hit once the next patch is applied, but since it's in the same vein as the changes in this patch, I included it in this patch: - attribute::form_is_unsigned must handle form DW_FORM_loclistx, otherwise we hit the assert when trying to call set_unsigned for an attribute of this form. DW_FORM_rnglistx is already handled. gdb/ChangeLog: PR gdb/26813 * dwarf2/attribute.h (struct attribute) <set_unsigned>: Clear requires_reprocessing flag. * dwarf2/attribute.c (attribute::form_is_unsigned): Handle DW_FORM_loclistx. (attribute::form_requires_reprocessing): Handle DW_FORM_rnglistx and DW_FORM_loclistx. * dwarf2/read.c (read_attribute_reprocess): Use set_unsigned instead of set_address for DW_FORM_loclistx and DW_FORM_rnglistx. Change-Id: I06c156fa3913ca98e4e39085f4ef171645b4bc1e
2021-02-02gdb/dwarf: remove unnecessary check in read_{rng,loc}list_indexSimon Marchi2-11/+6
In read_rnglist_index and read_loclist_index, we check that both the start and end of the offset that we read from the offset table are within the section. I think it's unecessary to do both: if the end of the offset is within the section, then surely the start of the offset is within it. Remove the check for the start of the offset in both functions. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Remove bound check for start of offset. (read_rnglist_index): Likewise. Change-Id: I7b57ddf4f8a8a28971738f0e3f3af62108f9e19a
2021-02-02gdb/dwarf: add missing bound check to read_loclist_indexSimon Marchi2-4/+18
read_rnglist_index has a bound check to make sure that we don't go past the end of the section while reading the offset, but read_loclist_index doesn't. Add it to read_loclist_index. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Add bound check for the end of the offset. Change-Id: Ic4b55c88860fdc3e007740949c78ec84cdb4da60
2021-02-02gdb/dwarf: fix bound check in read_rnglist_indexSimon Marchi2-1/+7
I think this check in read_rnglist_index is wrong: /* Validate that reading won't go beyond the end of the section. */ if (start_offset + cu->header.offset_size > rnglist_base + section->size) error (_("Reading DW_FORM_rnglistx index beyond end of" ".debug_rnglists section [in module %s]"), objfile_name (objfile)); The addition `rnglist_base + section->size` doesn't make sense. rnglist_base is an offset into `section`, so it doesn't make sense to add it to `section`'s size. `start_offset` also is an offset into `section`, so we should just compare it to just `section->size`. gdb/ChangeLog: * dwarf2/read.c (read_rnglist_index): Fix bound check. Change-Id: If0ff7c73f4f80f79aac447518f4e8f131f2db8f2
2021-02-02gdb/dwarf: change read_loclist_index complaints into errorsSimon Marchi2-8/+16
Unlike read_rnglists_index, read_loclist_index uses complaints when it detects an inconsistency (a DW_FORM_loclistx value without a .debug_loclists section or an offset outside of the section). I really think they should be errors, since there's no point in continuing if this situation happens, we will likely segfault or read garbage. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Change complaints into errors. Change-Id: Ic3a1cf6e682d47cb6e739dd76fd7ca5be2637e10
2021-02-02[gdb/symtab] Fix assert in write_one_signatured_typeTom de Vries4-0/+34
When running test-case gdb.dwarf2/fission-reread.exp with target board cc-with-gdb-index, we run into an abort during the generation of the gdb-index by cc-with-tweaks.sh: ... build/gdb/testsuite/cache/gdb.sh: line 1: 27275 Aborted (core dumped) ... This can be reproduced on the command line like this: ... $ gdb -batch ./outputs/gdb.dwarf2/fission-reread/fission-reread \ -ex 'save gdb-index ./outputs/gdb.dwarf2/fission-reread' warning: Could not find DWO TU fission-reread.dwo(0x9022f1ceac7e8b19) \ referenced by TU at offset 0x0 [in module fission-reread] warning: Could not find DWO CU fission-reread.dwo(0x807060504030201) \ referenced by CU at offset 0x561 [in module fission-reread] Aborted (core dumped) ... The abort is a segfault due to a using a nullptr psymtab in write_one_signatured_type. The problem is that we're trying to write index entries for the type unit with signature: ... (gdb) p /x entry->signature $2 = 0x9022f1ceac7e8b19 ... which is a skeleton type unit: ... Contents of the .debug_types section: Compilation Unit @ offset 0x0: Length: 0x4a (32-bit) Version: 4 Abbrev Offset: 0x165 Pointer Size: 4 Signature: 0x9022f1ceac7e8b19 Type Offset: 0x0 <0><17>: Abbrev Number: 2 (DW_TAG_type_unit) <18> DW_AT_comp_dir : /tmp/src/gdb/testsuite <2f> DW_AT_GNU_dwo_name: fission-reread.dwo <42> DW_AT_GNU_pubnames: 0x0 <46> DW_AT_GNU_pubtypes: 0x0 <4a> DW_AT_GNU_addr_base: 0x0 ... referring to a .dwo file, but as the warnings show, the .dwo file is not found. Fix this by skipping the type unit in write_one_signatured_type if psymtab == nullptr. Tested on x86_64-linux. gdb/ChangeLog: 2021-02-02 Tom de Vries <tdevries@suse.de> PR symtab/24620 * dwarf2/index-write.c (write_one_signatured_type): Skip if psymtab == nullptr. gdb/testsuite/ChangeLog: 2021-02-02 Tom de Vries <tdevries@suse.de> PR symtab/24620 * gdb.dwarf2/fission-reread.exp: Add test-case.
2021-02-01[gdb/testsuite] Fix gdb.dwarf2/fission-reread.exp with .gdb_indexTom de Vries11-52/+64
When running test-case gdb.dwarf2/fission-reread.exp with target board cc-with-gdb-index, we run into: ... gdb compile failed, warning: Could not find DWO TU \ fission-reread.dwo(0x9022f1ceac7e8b19) referenced by TU at offset 0x0 \ [in module outputs/gdb.dwarf2/fission-reread/fission-reread] ... The problem is that the .dwo file is not found. There's code added in the .exp file to make sure the .dwo can be found: ... # Make sure we can find the .dwo file, regardless of whether we're # running in parallel mode. gdb_test_no_output "set debug-file-directory [file dirname $binfile]" \ "set debug-file-directory" ... This works normally, but not for the gdb invocation done by cc-with-tweaks.sh for target board cc-with-gdb-index. Fix this by finding the full path to the .dwo file and passing it to the compilation. Tested on x86_64-linux with native and target boards cc-with-gdb-index, cc-with-debug-names and readnow. gdb/testsuite/ChangeLog: 2021-02-01 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/fission-base.S: Pass -DDWO=$dwo. * gdb.dwarf2/fission-loclists-pie.S: Same. * gdb.dwarf2/fission-loclists.S: Same. * gdb.dwarf2/fission-multi-cu.S: Same. * gdb.dwarf2/fission-reread.S: Same. * gdb.dwarf2/fission-base.exp: Use DWO. * gdb.dwarf2/fission-loclists-pie.exp: Same. * gdb.dwarf2/fission-loclists.exp: Same. * gdb.dwarf2/fission-multi-cu.exp: Same. * gdb.dwarf2/fission-reread.exp: Same.
2021-02-01gdb: unify parts of the Linux and FreeBSD core dumping codeAndrew Burgess5-262/+199
While reviewing the Linux and FreeBSD core dumping code within GDB for another patch series, I noticed that the code that collects the registers for each thread and writes these into ELF note format is basically identical between Linux and FreeBSD. This commit merges this code and moves it into the gcore.c file, which seemed like the right place for generic writing a core file code. The function find_signalled_thread is moved from linux-tdep.c despite not being shared. A later commit will make use of this function. There are a couple of minor changes to the FreeBSD target after this commit, but I believe that these are changes for the better: (1) For FreeBSD we always used to record the thread-id in the core file by using ptid_t.lwp (). In contrast the Linux code did this: /* For remote targets the LWP may not be available, so use the TID. */ long lwp = ptid.lwp (); if (lwp == 0) lwp = ptid.tid (); Both target now do this: /* The LWP is often not available for bare metal target, in which case use the tid instead. */ if (ptid.lwp_p ()) lwp = ptid.lwp (); else lwp = ptid.tid (); Which is equivalent for Linux, but is a change for FreeBSD. I think that all this means is that in some cases where GDB might have previously recorded a thread-id of 0 for each thread, we might now get something more useful. (2) When collecting the registers for Linux we collected into a zero initialised buffer. By contrast on FreeBSD the buffer is left uninitialised. In the new code the buffer is always zero initialised. I suspect once the registers are copied into the buffer there's probably no gaps left so this makes no difference, but if it does then using zeros rather than random bits of GDB's memory is probably a good thing. Otherwise, there should be no other user visible changes after this commit. Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no regressions. gdb/ChangeLog: * Makefile.in (HFILES_NO_SRCDIR): Add corefile.h. * gcore.c (struct gcore_collect_regset_section_cb_data): Moved here from linux-tdep.c and given a new name. Minor cleanups. (gcore_collect_regset_section_cb): Likewise. (gcore_collect_thread_registers): Likewise. (gcore_build_thread_register_notes): Likewise. (gcore_find_signalled_thread): Likewise. * gcore.h (gcore_build_thread_register_notes): Declare. (gcore_find_signalled_thread): Declare. * fbsd-tdep.c: Add 'gcore.h' include. (struct fbsd_collect_regset_section_cb_data): Delete. (fbsd_collect_regset_section_cb): Delete. (fbsd_collect_thread_registers): Delete. (struct fbsd_corefile_thread_data): Delete. (fbsd_corefile_thread): Delete. (fbsd_make_corefile_notes): Call gcore_build_thread_register_notes instead of the now deleted FreeBSD code. * linux-tdep.c: Add 'gcore.h' include. (struct linux_collect_regset_section_cb_data): Delete. (linux_collect_regset_section_cb): Delete. (linux_collect_thread_registers): Delete. (linux_corefile_thread): Call gcore_build_thread_register_notes. (find_signalled_thread): Delete. (linux_make_corefile_notes): Call gcore_find_signalled_thread.
2021-01-29[gdb/breakpoint] Fix stepping past non-stmt line-table entriesTom de Vries5-8/+208
Consider the test-case small.c: ... $ cat -n small.c 1 __attribute__ ((noinline, noclone)) 2 int foo (char *c) 3 { 4 asm volatile ("" : : "r" (c) : "memory"); 5 return 1; 6 } 7 8 int main () 9 { 10 char tpl1[20] = "/tmp/test.XXX"; 11 char tpl2[20] = "/tmp/test.XXX"; 12 int fd1 = foo (tpl1); 13 int fd2 = foo (tpl2); 14 if (fd1 == -1) { 15 return 1; 16 } 17 18 return 0; 19 } ... Compiled with gcc-8 and optimization: ... $ gcc-8 -O2 -g small.c ... We step through the calls to foo, but fail to visit line 13: ... 12 int fd1 = foo (tpl1); (gdb) step foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5 5 return 1; (gdb) step foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5 5 return 1; (gdb) step main () at small.c:14 14 if (fd1 == -1) { (gdb) ... This is caused by the following. The calls to foo are implemented by these insns: .... 4003df: 0f 29 04 24 movaps %xmm0,(%rsp) 4003e3: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp) 4003e8: e8 03 01 00 00 callq 4004f0 <foo> 4003ed: 48 8d 7c 24 20 lea 0x20(%rsp),%rdi 4003f2: 89 c2 mov %eax,%edx 4003f4: e8 f7 00 00 00 callq 4004f0 <foo> 4003f9: 31 c0 xor %eax,%eax ... with corresponding line table entries: ... INDEX LINE ADDRESS IS-STMT 8 12 0x00000000004003df Y 9 10 0x00000000004003df 10 11 0x00000000004003e3 11 12 0x00000000004003e8 12 13 0x00000000004003ed 13 12 0x00000000004003f2 14 13 0x00000000004003f4 Y 15 13 0x00000000004003f4 16 14 0x00000000004003f9 Y 17 14 0x00000000004003f9 ... Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb enters process_event_stop_test to figure out what to do. That entry has is-stmt=n, so it's not the start of a line, so we don't stop there. However, we do update ecs->event_thread->current_line to line 13, because the frame has changed (because we stepped out of the function). Next we land at 4003f2. Again the entry has is-stmt=n, so it's not the start of a line, so we don't stop there. However, because the frame hasn't changed, we don't update update ecs->event_thread->current_line, so it stays 13. Next we land at 4003f4. Now is-stmt=y, so it's the start of a line, and we'd like to stop here. But we don't stop because this test fails: ... if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc) && (ecs->event_thread->current_line != stop_pc_sal.line || ecs->event_thread->current_symtab != stop_pc_sal.symtab)) { ... because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13. Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and the frame has changed, such that we have: ... 12 int fd1 = foo (tpl1); (gdb) step foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5 5 return 1; (gdb) step main () at small.c:13 13 int fd2 = foo (tpl2); (gdb) ... Tested on x86_64-linux, with gcc-7 and gcc-8. gdb/ChangeLog: 2021-01-29 Tom de Vries <tdevries@suse.de> PR breakpoints/26063 * infrun.c (process_event_stop_test): Reset ecs->event_thread->current_line to 0 if is-stmt=n and frame has changed. gdb/testsuite/ChangeLog: 2021-01-29 Tom de Vries <tdevries@suse.de> PR breakpoints/26063 * gdb.dwarf2/dw2-step-out-of-function-no-stmt.c: New test. * gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp: New file.
2021-01-29[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32 and gcc-10Tom de Vries2-24/+6
When running test-case gdb.opt/solib-intra-step.exp with target board unix/-m32 and gcc-10, I run into: ... (gdb) step^M __x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:68^M 68 ../sysdeps/i386/crti.S: No such file or directory.^M (gdb) step^M shlib_second (dummy=0) at solib-intra-step-lib.c:23^M 23 abort (); /* second-hit */^M (gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit ... The problem is that the test-case expects to step past the retry line, which is optional. Fix this by removing the state tracking logic from the gdb_test_multiples. It makes the test more difficult to understand, and doesn't specifically test for faulty gdb behaviour. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-29 Tom de Vries <tdevries@suse.de> * gdb.opt/solib-intra-step.exp: Remove state tracking logic.
2021-01-28gdb: remove unneeded switch_to_thread from thr_try_catch_cmdAndrew Burgess2-3/+9
I spotted that every time thr_try_catch_cmd is called GDB has already switched to the required thread. The call to switch_to_thread at the head of thr_try_catch_cmd is therefore redundant. This commit replaces the call to switch_to_thread with an assertion that we already have the required thread selected. I also extended the header comment on thr_try_catch_cmd to make it clearer when this function could throw an exception. There should be no user visible changes after this commit. gdb/ChangeLog: * thread.c (thr_try_catch_cmd): Replace swith_to_thread with an assert. Extend the header comment.
2021-01-28gdb/tui: remove special handling of locator/status windowAndrew Burgess13-138/+270
The locator window, or status window as it is sometimes called is handled differently to all the other windows. The reason for this is that the class representing this window (tui_locator_window) does two jobs, first this class represents a window just like any other that has space on the screen and fills the space with content. The second job is that this class serves as a storage area to hold information about the current location that the TUI windows represent, so the class has members like 'addr' and 'line_no', for example which are used within this class, and others when they want to know which line/address the TUI windows should be showing to the user. Because of this dual purpose we must always have an instance of the tui_locator_window so that there is somewhere to store this location information. The result of this is that the locator window must never be deleted like other windows, which results in some special case code. In this patch I propose splitting the two roles of the tui_locator_window class. The tui_locator_window class will retain just its window drawing parts, and will be treated just like any other window. This should allow all special case code for this window to be deleted. The other role, that of tracking the current tui location will be moved into a new class (tui_location_tracker), of which there will be a single global instance. All of the places where we previously use the locator window to get location information will now be updated to get this from the tui_location_tracker. There should be no user visible changes after this commit. gdb/ChangeLog: * Makefile.in (SUBDIR_TUI_SRCS): Add tui/tui-location.c. (HFILES_NO_SRCDIR): Add tui/tui-location.h. * tui/tui-data.h (TUI_STATUS_WIN): Define. (tui_locator_win_info_ptr): Delete declaration. * tui/tui-disasm.c: Add 'tui/tui-location.h' include. (tui_disasm_window::set_contents): Fetch state from tui_location global. (tui_get_begin_asm_address): Likewise. * tui/tui-layout.c (tui_apply_current_layout): Remove special case for locator window. (get_locator_window): Delete. (initialize_known_windows): Treat locator window just like all the rest. * tui/tui-source.c: Add 'tui/tui-location.h' include. (tui_source_window::set_contents): Fetch state from tui_location global. (tui_source_window::showing_source_p): Likewise. * tui/tui-stack.c: Add 'tui/tui-location.h' include. (_locator): Delete. (tui_locator_win_info_ptr): Delete. (tui_locator_window::make_status_line): Fetch state from tui_location global. (tui_locator_window::rerender): Remove check of 'handle', reindent function body. (tui_locator_window::set_locator_fullname): Delete. (tui_locator_window::set_locator_info): Delete. (tui_update_locator_fullname): Delete. (tui_show_frame_info): Likewise. (tui_show_locator_content): Access window through TUI_STATUS_WIN. * tui/tui-stack.h (tui_locator_window::set_locator_info): Moved to tui/tui-location.h and renamed to tui_location_tracker::set_location. (tui_locator_window::set_locator_fullname): Moved to tui/tui-location.h and renamed to tui_location_tracker::set_fullname. (tui_locator_window::full_name): Delete. (tui_locator_window::proc_name): Delete. (tui_locator_window::line_no): Delete. (tui_locator_window::addr): Delete. (tui_locator_window::gdbarch): Delete. (tui_update_locator_fullname): Delete declaration. * tui/tui-wingeneral.c (tui_refresh_all): Removed special handling for locator window. * tui/tui-winsource.c: Add 'tui/tui-location.h' include. (tui_display_main): Call function on tui_location directly. * tui/tui.h (enum tui_win_type): Add STATUS_WIN. * tui/tui-location.c: New file. * tui/tui-location.h: New file.
2021-01-28[gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.expTom de Vries2-7/+25
When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get: ... (gdb) up 3^M 79 abort.c: No such file or directory.^M (gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame ... The preceding backtrace looks like this: ... (gdb) bt^M #0 0xf7fcf549 in __kernel_vsyscall ()^M #1 0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \ ../sysdeps/unix/sysv/linux/internal-signals.h:104^M #2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M #3 0xf7cd0314 in __GI_abort () at abort.c:79^M #4 0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M #5 0x08049176 in main () at i386-gnu-cfi.c:27^M ... with function gate at position #4, while on another system where the test passes, I see instead function gate at position #3. Fix this by capturing the position of function gate in the backtrace, and using that in the rest of the test instead of hardcoded constant 3. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> * gdb.arch/i386-gnu-cfi.exp: Capture the position of function gate in the backtrace, and use that in the rest of the test instead of hardcoded constant 3. Use "frame" instead of "up" for robustness.
2021-01-28[gdb/testsuite] Fix g0 search in gdb.arch/i386-sse-stack-align.expTom de Vries4-27/+34
When running test-case gdb.arch/i386-sse-stack-align.exp on target board unix/-m32, I run into: ... (gdb) print (int) g0 ()^M Invalid data type for function to be called.^M (gdb) FAIL: gdb.arch/i386-sse-stack-align.exp: print (int) g0 () ... Gdb is supposed to use minimal symbol g0: ... $ nm i386-sse-stack-align | grep g0 08049194 t g0 ... but instead it finds a g0 symbol in the debug info of libm, specifically in ./sysdeps/ieee754/ldbl-96/e_lgammal_r.c. Fix this by renaming g[0-4] to test_g[0-4]. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> * gdb.arch/i386-sse-stack-align.S: Rename g[0-4] to test_g[0-4]. * gdb.arch/i386-sse-stack-align.c: Same. * gdb.arch/i386-sse-stack-align.exp: Same.
2021-01-28gdb: rename get_type_arch to type::archSimon Marchi30-110/+101
... and update all users. gdb/ChangeLog: * gdbtypes.h (get_type_arch): Rename to... (struct type) <arch>: ... this, update all users. Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f
generated by cgit v1.1 at 2024-11-20 04:13:42 +0000