| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
init_ada_exception_breakpoint is only ever passed a single
breakpoint_ops structure, so remove the parameter.
|
|
Right now, probe tracepoints are handled by a separate ops object.
However, they differ only in a small way from ordinary tracepoints,
and furthermore can be distinguished by their event location.
This patch merges the two cases, just as was done for breakpoints.
|
|
Right now, probe breakpoints are handled by a separate ops object.
However, they differ only in a small way from ordinary breakpoints,
and furthermore can be distinguished by their "probe" object.
This patch merges the two cases. This avoids having to introduce a
new bp_ constant (which can be quite subtle to do correctly) and a new
subclass.
|
|
An earlier patch removed the last use of bkpt_base_breakpoint_ops, so
remove the object entirely.
|
|
This converts static marker tracepoints to use vtable_breakpoint_ops.
|
|
Because the actual construction of a breakpoint is buried deep in
create_breakpoint, at present it's necessary to have a new bp_
enumerator constant any time a new subclass is needed. Static marker
tracepoints are one such case, so this patch introduces
bp_static_marker_tracepoint and updates various spots to recognize it.
|
|
This converts ranged breakpoints to use vtable_breakpoint_ops. This
requires introducing a new ranged_breakpoint type, but this is
relatively simple because ranged breakpoints can only be created by
break_range_command.
|
|
This converts dprintf to use vtable_breakpoint_ops.
|
|
This converts Ada catchpoints to use vtable_breakpoint_ops.
|
|
This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
Recall that an ordinary breakpoint is both the kind normally created
by users, and also a base class used by other classes.
|
|
The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops,
except it's written out explicitly -- and, importantly, there's
nothing that bpkt_breakpoint_ops overrides that dprintf does not.
This changes dprintf to simply inherit directly, and updates struct
dprintf_breakpoint to reflect the change as well.
|
|
This converts momentary breakpoints to use vtable_breakpoint_ops.
|
|
This converts internal breakpoints to use vtable_breakpoint_ops.
|
|
This converts break-catch-throw.c to use vtable_breakpoint_ops.
|
|
This converts base breakpoints to use vtable_breakpoint_ops.
|
|
This adds a few new subclasses of breakpoint. The inheritance
hierarchy is chosen to reflect what's already present in
initialize_breakpoint_ops -- it mirrors the way that the _ops
structures are filled in.
This patch also changes new_breakpoint_from_type to create the correct
sublcass based on bptype. This is important due to the somewhat
inverted way in which create_breakpoint works; and in particular later
patches will change some of these entries.
|
|
This converts tracepoints to use vtable_breakpoint_ops.
|
|
This converts watchpoints and masked watchpoints. to use
vtable_breakpoint_ops. For masked watchpoints, a new subclass must be
introduced, and watch_command_1 is changed to create one.
|
|
This converts break-catch-load.c to use vtable_breakpoint_ops.
|
|
This converts break-catch-fork.c to use vtable_breakpoint_ops.
|
|
This converts break-catch-exec.c to use vtable_breakpoint_ops.
|
|
This converts break-catch-syscall.c to use vtable_breakpoint_ops.
|
|
This converts break-catch-sig.c to use vtable_breakpoint_ops.
|
|
This adds methods to struct breakpoint. Each method has a similar
signature to a corresponding function in breakpoint_ops, with the
exceptions of create_sals_from_location and create_breakpoints_sal,
which can't be virtual methods on breakpoint -- they are only used
during the construction of breakpoints.
Then, this adds a new vtable_breakpoint_ops structure and populates it
with functions that simply forward a call from breakpoint_ops to the
corresponding virtual method. These are all done with lambdas,
because they are just a stepping stone -- by the end of the series,
this structure will be deleted.
|
|
This changes breakpoint_ops::print_one to return bool, and updates all
the implementations and the caller. The caller is changed so that a
NULL check is no longer needed -- something that will be impossible
with a real method.
|
|
This patch deletes a few unnecessary wrapper functions from
breakpoint.c.
|
|
This adds an assertion to clone_momentary_breakpoint. This will
eventually be removed, but in the meantime is is useful for helping
convince oneself that momentary breakpoints will always use
momentary_breakpoint_ops. This understanding will help when cleaning
up the code later.
|
|
Change print_solib_event to accept a bool parameter and update the
callers.
|
|
The "catch load" code is reasonably self-contained, and so this patch
moves it out of breakpoint.c and into a new file, break-catch-load.c.
One function from breakpoint.c, print_solib_event, now has to be
exposed, but this seems pretty reasonable.
|
|
This de-duplicates variables and types in .gdb_index, making the new
index closer to what gdb generated before the new DWARF scanner
series. Spot-checking the resulting index for gdb itself, it seems
that the new scanner picks up some extra symbols not detected by the
old one. I tested both the new and old versions of gdb on both new
and old versions of the index, and startup time in all cases is
roughly the same (it's worth noting that, for gdb itself, the index no
longer provides any benefit over the DWARF scanner). So, I think this
fixes the size issue with the new index writer.
Regression tested on x86-64 Fedora 34.
|
|
At AdaCore, we run the internal gdb test suite in several modes,
including one using the .debug_names index. This caught a regression
caused by the new DWARF indexer.
First, the psymtabs-based .debug_names generator was completely wrong.
However, to avoid making the rewrite series even bigger (fixing the
writer will also require rewriting the .debug_names reader), it
attempted to preserve the weirdness.
However, this was not done properly. For example the old writer did
this:
- case STRUCT_DOMAIN:
- return DW_TAG_structure_type;
The new code, instead, simply preserves the actual DWARF tag -- but
this makes future lookups fail, because the .debug_names reader only
looks for DW_TAG_structure_type.
This patch attempts to revert to the old behavior in the writer.
|
|
Commit 152a1749566 ("gdb: prune inferiors at end of
fetch_inferior_event, fix intermittent failure of
gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related
test failures, such as:
info inferiors^M
Num Description Connection Executable ^M
* 1 process 634972 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
2 process 634975 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
(gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors
inferior 2^M
[Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M
[Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M
#0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M
(gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2
continue^M
Continuing.^M
[Inferior 2 (process 634975) exited normally]^M
[Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M
(gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end
break callee^M
Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M
(gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee
What happens here is:
- inferior 2 is selected
- we continue, leading to inferior 2's exit
- we set breakpoint, expect 2 locations, but only one location is
resolved
Reading between the lines, we understand that inferior 2 got pruned,
when it shouldn't have been.
The issue can be reproduced by hand with:
$ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun"
...
Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14
14 int v = 5;
[New inferior 2 (process 637627)]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
17 if (pid == 0) /* set breakpoint here */
[Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]
[Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))]
#0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6
(gdb) continue
Continuing.
[infrun] clear_proceed_status_thread: 637627.637627.0
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming 637627.637627.0
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7
[infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
[infrun] proceed: exit
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #1
[infrun] random_pending_event_thread: None found.
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 637627.637627.0 [process 637627],
[infrun] print_target_wait_results: status->kind = EXITED, exit_status = 0
[infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0
[Inferior 2 (process 637627) exited normally]
[infrun] stop_waiting: stop_waiting
[infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1
[infrun] stop_all_threads: pass=0, iterations=0
[infrun] stop_all_threads: 637624.637624.0 not executing
[infrun] stop_all_threads: pass=1, iterations=1
[infrun] stop_all_threads: 637624.637624.0 not executing
[infrun] stop_all_threads: done
[infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1
[Switching to Thread 0x7ffff7c9a740 (LWP 637624)]
[infrun] infrun_async: enable=0
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
(gdb) [infrun] fetch_inferior_event: exit
(gdb) info inferiors
Num Description Connection Executable
* 1 process 637624 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork
(gdb) i th
Id Target Id Frame
* 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17
After handling the EXITED event for inferior 2, inferior 2 should have
stayed the current inferior, which should have prevented it from getting
pruned. When debugging, we find that when getting at the
prune_inferiors call, the current inferior is inferior 1. Further
debugging shows that prior to the call to
clean_up_just_stopped_threads_fsms, the current inferior is inferior 2,
and after, it's inferior 1. Then, back in fetch_inferior_event, the
restore_thread object is disabled, due to:
/* If we got a TARGET_WAITKIND_NO_RESUMED event, then the
previously selected thread is gone. We have two
choices - switch to no thread selected, or restore the
previously selected thread (now exited). We chose the
later, just because that's what GDB used to do. After
this, "info threads" says "The current thread <Thread
ID 2> has terminated." instead of "No thread
selected.". */
if (!non_stop
&& cmd_done
&& ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED)
restore_thread.dont_restore ();
So in the end, inferior 1 stays current, and inferior 2 gets wrongfully
pruned.
I'd say clean_up_just_stopped_threads_fsms is the culprit here. It
actually attempts to restore the event_thread to be current at the end,
after the loop (I presume the current thread on entry is always supposed
to be the event thread). But in this case, the event is of kind EXITED,
and ecs->event_thread is not set, so the current inferior isn't
restored.
Fix that by using scoped_restore_current_thread. If there is no current
thread, scoped_restore_current_thread will still restore the current
inferior, and that's what we want.
Random note: the thread_info object for inferior 2's thread is never
freed. It is held (by refcount) by the restore_thread object in
fetch_inferior_event, while the inferior's thread list gets cleared, in
the exit event processing. When the refcount reaches 0 (when the
restore_thread object is destroyed), there's nothing that actually
deletes the thread_info object. And I think that nothing in GDB points
to it anymore, so it leaks. I don't want to fix that in this patch, but
thought it would be good to mention it, in case somebody has an idea for
how to fix that.
Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8
|
|
The current target_resume interface is a bit odd & non-intuitive.
I've found myself explaining it a couple times the recent past, while
reviewing patches that assumed STEP/SIGNAL always applied to the
passed in PTID. It goes like this today:
- if the passed in PTID is a thread, then the step/signal request is
for that thread.
- otherwise, if PTID is a wildcard (all threads or all threads of
process), the step/signal request is for inferior_ptid, and PTID
indicates which set of threads run free.
Because GDB always switches the current thread to "leader" thread
being resumed/stepped/signalled, we can simplify this a bit to:
- step/signal are always for inferior_ptid.
- PTID indicates the set of threads that run free.
Still not ideal, but it's a minimal change and at least there are no
special cases this way.
That's what this patch does. It renames the PTID parameter to
SCOPE_PTID, adds some assertions to target_resume, and tweaks
target_resume's description. In addition, it also renames PTID to
SCOPE_PTID in the remote and linux-nat targets, and simplifies their
implementation a little bit. Other targets could do the same, but
they don't have to.
Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
|
|
The DWARF index code currently uses 'stat' to see if an objfile
represents a real file. However, I think it's more correct to check
OBJF_NOT_FILENAME instead.
Regression tested on x86-64 Fedora 34.
|
|
I noticed a few spots in GDB that use "typedef enum". However, in C++
this isn't as useful, as the tag is automatically entered as a
typedef. This patch removes most uses of "typedef enum" -- the
exceptions being in some nat-* code I can't compile, and
glibc_thread_db.h, which I think is more or less a copy of some C code
from elsewhere.
Tested by rebuilding.
|
|
This commit:
commit f5cb8afdd297dd68273d98a10fbfd350dff918d8
Date: Sun Feb 6 22:27:53 2022 -0500
gdb: remove BLOCK_RANGES macro
introduces a potential nullptr dereference in block::ranges, this is
breaking most tests, e.g. gdb.base/break.exp is failing for me.
In the above patch BLOCK_CONTIGUOUS_P is changed from this:
#define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \
|| BLOCK_NRANGES (bl) <= 1)
to this:
#define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \
|| (bl)->ranges ().size () == 1)
So, before the commit we checked for the block ranges being nullptr,
but afterwards we just call block::ranges() in all cases.
The problem is that block::ranges() looks like this:
/* Return a view on this block's ranges. */
gdb::array_view<blockrange> ranges ()
{ return gdb::make_array_view (m_ranges->range, m_ranges->nranges); }
where m_ranges is:
struct blockranges *m_ranges;
And so, we see that the nullptr check has been lost, and we might end
up dereferencing a nullptr.
My proposed fix is to move the nullptr check into block::ranges, and
return an explicit empty array_view if m_ranges is nullptr.
After this, everything seems fine again.
|
|
Replace with equivalent methods.
Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
|
|
addrmap_find shouldn't need to modify the addrmap, so constify the
addrmap parameter. This helps for the following patch, where getting
the map of a const blockvector will return a const addrmap.
Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
|
|
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
|
|
Replace with equivalent method.
Change-Id: I0e033095e7358799930775e61028b48246971a7d
|
|
Replace with an equivalent method.
Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
|
|
Replace with access through the block::ranges method.
Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
|
|
Replace with range for loops.
Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
|
|
Replace with an equivalent method on struct block.
Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
|
|
Replace with equivalent methods on blockrange.
Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
|
|
Replace with equivalent methods.
Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
|
|
Replace with equivalent methods.
Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
|
|
Replace with equivalent methods.
Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
|
|
Replace with equivalent methods.
Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
|
|
Replace with equivalent methods.
Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
|
