mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-01 05:55:23 +08:00
fb7331ae2b
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Simon Marchi
|
97916bfedf |
gdb: use bool in frame code
Change instances of int variables and return values used as boolean values to use the bool type. Shorten the comments of a few functions, because I think they go a bit too much in implementation details, which appear out of date anyway. Make other misc changes to the functions that are already being changed, such as using nullptr instead of NULL, dropping `struct` keywords and declaring variables when first used. gdb/ChangeLog: * frame.h (frame_id_p): Return bool. (frame_id_artificial_p): Return bool. (frame_id_eq): Return bool. (has_stack_frames): Return bool. (get_selected_frame): Fix typo in comment. (get_frame_pc_if_available): Return bool. (get_frame_address_in_block_if_available): Return bool. (get_frame_func_if_available): Return bool. (read_frame_register_unsigned): Return bool. (get_frame_register_bytes): Return bool. (safe_frame_unwind_memory): Return bool. (deprecated_frame_register_read): Return bool. (frame_unwinder_is): Return bool. * frame.c (struct frame_info) <prev_arch::p>: Change type to bool. <this_id::p>: Likewise. <prev_p>: Likewise. (frame_stash_add): Return bool. (get_frame_id): Use bool. (frame_id_build_special) Use bool. (frame_id_build_unavailable_stack): Use bool. (frame_id_build): Use bool. (frame_id_p): Return bool, use true/false instead of 1/0. (frame_id_artificial_p): Likewise. (frame_id_eq): Likewise. (frame_id_inner): Likewise. (get_frame_func_if_available): Likewise. (read_frame_register_unsigned): Likewise. (deprecated_frame_register_read): Likewise. (get_frame_register_bytes): Likewise. (has_stack_frames): Likewise. (inside_main_func): Likewise. (inside_entry_func): Likewise. (get_frame_pc_if_available): Likewise. (get_frame_address_in_block_if_available): Likewise. (frame_unwinder_is): Likewise. (safe_frame_unwind_memory): Likewise. (frame_unwind_arch): Likewise. Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a |
||
Pedro Alves
|
6d7aa59270 |
Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1
Running the testsuite against an Asan-enabled build of GDB makes gdb.base/multi-target.exp expose this bug. scoped_restore_current_thread's ctor calls get_frame_id to record the selected frame's ID to restore later. If the frame ID hasn't been computed yet, it will be computed on the spot, and that will usually require accessing the target's memory and registers, which requires remote accesses. If the remote connection closes while we're computing the frame ID, the remote target exits its inferiors, unpushes itself, and throws a TARGET_CLOSE_ERROR error. If that happens, GDB can currently crash, here: > ==18555==ERROR: AddressSanitizer: heap-use-after-free on address 0x621004670aa8 at pc 0x0000007ab125 bp 0x7ffdecaecd20 sp 0x7ffdecaecd10 > READ of size 4 at 0x621004670aa8 thread T0 > #0 0x7ab124 in dwarf2_frame_this_id src/binutils-gdb/gdb/dwarf2/frame.c:1228 > #1 0x983ec5 in compute_frame_id src/binutils-gdb/gdb/frame.c:550 > #2 0x9841ee in get_frame_id(frame_info*) src/binutils-gdb/gdb/frame.c:582 > #3 0x1093faa in scoped_restore_current_thread::scoped_restore_current_thread() src/binutils-gdb/gdb/thread.c:1462 > #4 0xaee5ba in fetch_inferior_event(void*) src/binutils-gdb/gdb/infrun.c:3968 > #5 0xaa990b in inferior_event_handler(inferior_event_type, void*) src/binutils-gdb/gdb/inf-loop.c:43 > #6 0xea61b6 in remote_async_serial_handler src/binutils-gdb/gdb/remote.c:14161 > #7 0xefca8a in run_async_handler_and_reschedule src/binutils-gdb/gdb/ser-base.c:137 > #8 0xefcd23 in fd_event src/binutils-gdb/gdb/ser-base.c:188 > #9 0x15a7416 in handle_file_event src/binutils-gdb/gdbsupport/event-loop.cc:548 > #10 0x15a7c36 in gdb_wait_for_event src/binutils-gdb/gdbsupport/event-loop.cc:673 > #11 0x15a5dbb in gdb_do_one_event() src/binutils-gdb/gdbsupport/event-loop.cc:215 > #12 0xbfe62d in start_event_loop src/binutils-gdb/gdb/main.c:356 > #13 0xbfe935 in captured_command_loop src/binutils-gdb/gdb/main.c:416 > #14 0xc01d39 in captured_main src/binutils-gdb/gdb/main.c:1253 > #15 0xc01dc9 in gdb_main(captured_main_args*) src/binutils-gdb/gdb/main.c:1268 > #16 0x414ddd in main src/binutils-gdb/gdb/gdb.c:32 > #17 0x7f590110b82f in __libc_start_main ../csu/libc-start.c:291 > #18 0x414bd8 in _start (build/binutils-gdb/gdb/gdb+0x414bd8) What happens is that above, we're in dwarf2_frame_this_id, just after the dwarf2_frame_cache call. The "cache" variable that the dwarf2_frame_cache function returned is already stale. It's been released here, from within the dwarf2_frame_cache: (top-gdb) bt #0 reinit_frame_cache () at src/gdb/frame.c:1855 #1 0x00000000014ff7b0 in switch_to_no_thread () at src/gdb/thread.c:1301 #2 0x0000000000f66d3e in switch_to_inferior_no_thread (inf=0x615000338180) at src/gdb/inferior.c:626 #3 0x00000000012f3826 in remote_unpush_target (target=0x6170000c5900) at src/gdb/remote.c:5521 #4 0x00000000013097e0 in remote_target::readchar (this=0x6170000c5900, timeout=2) at src/gdb/remote.c:9137 #5 0x000000000130be4d in remote_target::getpkt_or_notif_sane_1 (this=0x6170000c5900, buf=0x6170000c5918, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9683 #6 0x000000000130c8ab in remote_target::getpkt_sane (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9790 #7 0x000000000130bc0d in remote_target::getpkt (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9623 #8 0x000000000130838e in remote_target::remote_read_bytes_1 (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len_units=64, unit_size=1, xfered_len_units=0x7fff6a29b9a0) at src/gdb/remote.c:8860 #9 0x0000000001308bd2 in remote_target::remote_read_bytes (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64, unit_size=1, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:8987 #10 0x0000000001311ed1 in remote_target::xfer_partial (this=0x6170000c5900, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:10988 #11 0x00000000014ba969 in raw_memory_xfer_partial (ops=0x6170000c5900, readbuf=0x6080000ad3bc "", writebuf=0x0, memaddr=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:918 #12 0x00000000014bb720 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1148 #13 0x00000000014bc3b5 in target_read_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1380 #14 0x00000000014bc593 in target_read (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64) at src/gdb/target.c:1419 #15 0x00000000014bbd4d in target_read_raw_memory (memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64) at src/gdb/target.c:1252 #16 0x0000000000bf27df in dcache_read_line (dcache=0x6060001eddc0, db=0x6080000ad3a0) at src/gdb/dcache.c:336 #17 0x0000000000bf2b72 in dcache_peek_byte (dcache=0x6060001eddc0, addr=0x7fffffffcdd8, ptr=0x6020001231b0 "") at src/gdb/dcache.c:403 #18 0x0000000000bf3103 in dcache_read_memory_partial (ops=0x6170000c5900, dcache=0x6060001eddc0, memaddr=0x7fffffffcdd8, myaddr=0x6020001231b0 "", len=8, xfered_len=0x7fff6a29bf20) at src/gdb/dcache.c:484 #19 0x00000000014bafe9 in memory_xfer_partial_1 (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1034 #20 0x00000000014bb212 in memory_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1076 #21 0x00000000014bb6b3 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, annex=0x0, readbuf=0x6020001231b0 "", writebuf=0x0, offset=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1133 #22 0x000000000164564d in read_value_memory (val=0x60f000029440, bit_offset=0, stack=1, memaddr=0x7fffffffcdd8, buffer=0x6020001231b0 "", length=8) at src/gdb/valops.c:956 #23 0x0000000001680fff in value_fetch_lazy_memory (val=0x60f000029440) at src/gdb/value.c:3764 #24 0x0000000001681efd in value_fetch_lazy (val=0x60f000029440) at src/gdb/value.c:3910 #25 0x0000000001676143 in value_optimized_out (value=0x60f000029440) at src/gdb/value.c:1411 #26 0x0000000000e0fcb8 in frame_register_unwind (next_frame=0x6210066bfde0, regnum=16, optimizedp=0x7fff6a29c200, unavailablep=0x7fff6a29c240, lvalp=0x7fff6a29c2c0, addrp=0x7fff6a29c300, realnump=0x7fff6a29c280, bufferp=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1144 #27 0x0000000000e10418 in frame_unwind_register (next_frame=0x6210066bfde0, regnum=16, buf=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1196 #28 0x0000000000f00431 in i386_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/i386-tdep.c:1969 #29 0x0000000000e39724 in gdbarch_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/gdbarch.c:3056 #30 0x0000000000c2ea90 in dwarf2_tailcall_sniffer_first (this_frame=0x6210066bfde0, tailcall_cachep=0x6210066bfee0, entry_cfa_sp_offsetp=0x0) at src/gdb/dwarf2/frame-tailcall.c:423 #31 0x0000000000c36bdb in dwarf2_frame_cache (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8) at src/gdb/dwarf2/frame.c:1198 #32 0x0000000000c36eb3 in dwarf2_frame_this_id (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8, this_id=0x6210066bfe40) at src/gdb/dwarf2/frame.c:1226 Note that remote_target::readchar in frame #4 throws TARGET_CLOSE_ERROR after the remote_unpush_target in frame #3 returns. The problem is that the TARGET_CLOSE_ERROR is swallowed by value_optimized_out in frame #25. If we fix that one, then we run into dwarf2_tailcall_sniffer_first swallowing the exception in frame #30 too. The attached patch fixes it by making those spots swallow fewer kinds of errors. gdb/ChangeLog: * frame-tailcall.c (dwarf2_tailcall_sniffer_first): Only swallow NO_ENTRY_VALUE_ERROR / MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR. * value.c (value_optimized_out): Only swallow MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR. |
||
Andrew Burgess
|
9fc501fdfe |
gdb: Python unwinders, inline frames, and tail-call frames
This started with me running into the bug described in python/22748,
in summary, if the frame sniffing code accessed any registers within
an inline frame then GDB would crash with this error:
gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
The problem is that, when in the Python unwinder I write this:
pending_frame.read_register ("register-name")
This is translated internally into a call to `value_of_register',
which in turn becomes a call to `value_of_register_lazy'.
Usually this isn't a problem, `value_of_register_lazy' requires the
next frame (more inner) to have a valid frame_id, which will be the
case (if we're sniffing frame #1, then frame #0 will have had its
frame-id figured out).
Unfortunately if frame #0 is inline within frame #1, then the frame-id
for frame #0 can't be computed until we have the frame-id for #1. As
a result we can't create a lazy register for frame #1 when frame #0 is
inline.
Initially I proposed a solution inline with that proposed in bugzilla,
changing value_of_register to avoid creating a lazy register value.
However, when this was discussed on the mailing list I got this reply:
https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html
Which led me to look at these two patches:
[1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html
[2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html
When I considered patches [1] and [2] I saw that all of the issues
being addressed here were related, and that there was a single
solution that could address all of these issues.
First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which
shows that [1] and [2] regress the inline tail-call unwinder, the
reason for this is that these two patches replace a call to
gdbarch_unwind_pc with a call to get_frame_register, however, this is
not correct. The previous call to gdbarch_unwind_pc takes THIS_FRAME
and returns the $pc value in the previous frame. In contrast
get_frame_register takes THIS_FRAME and returns the value of the $pc
in THIS_FRAME; these calls are not equivalent.
The reason these patches appear (or do) fix the regressions listed in
[1] is that the tail call sniffer depends on identifying the address
of a caller and a callee, GDB then looks for a tail-call sequence that
takes us from the caller address to the callee, if such a series is
found then tail-call frames are added.
The bug that was being hit, and which was address in patch [1] is that
in order to find the address of the caller, GDB ended up creating a
lazy register value for an inline frame with to frame-id. The
solution in patch [1] is to instead take the address of the callee and
treat this as the address of the caller. Getting the address of the
callee works, but we then end up looking for a tail-call series from
the callee to the callee, which obviously doesn't return any sane
results, so we don't insert any tail call frames.
The original patch [1] did cause some breakage, so patch [2] undid
patch [1] in all cases except those where we had an inline frame with
no frame-id. It just so happens that there were no tests that fitted
this description _and_ which required tail-call frames to be
successfully spotted, as a result patch [2] appeared to work.
The new test inline-frame-tailcall.exp, exposes the flaw in patch [2].
This commit undoes patch [1] and [2], and replaces them with a new
solution, which is also different to the solution proposed in the
python/22748 bug report.
In this solution I propose that we introduce some special case logic
to value_of_register_lazy. To understand what this logic is we must
first look at how inline frames unwind registers, this is very simple,
they do this:
static struct value *
inline_frame_prev_register (struct frame_info *this_frame,
void **this_cache, int regnum)
{
return get_frame_register_value (this_frame, regnum);
}
And remember:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
}
So in all cases, unwinding a register in an inline frame just asks the
next frame to unwind the register, this makes sense, as an inline
frame doesn't really exist, when we unwind a register in an inline
frame, we're really just asking the next frame for the value of the
register in the previous, non-inline frame.
So, if we assume that we only get into the missing frame-id situation
when we try to unwind a register from an inline frame during the frame
sniffing process, then we can change value_of_register_lazy to not
create lazy register values for an inline frame.
Imagine this stack setup, where #1 is inline within #2.
#3 -> #2 -> #1 -> #0
\______/
inline
Now when trying to figure out the frame-id for #1, we need to compute
the frame-id for #2. If the frame sniffer for #2 causes a lazy
register read in #2, either due to a Python Unwinder, or for the
tail-call sniffer, then we call value_of_register_lazy passing in
frame #2.
In value_of_register_lazy, we grab the next frame, which is #1, and we
used to then ask for the frame-id of #1, which was not computed, and
this was our bug.
Now, I propose we spot that #1 is an inline frame, and so lookup the
next frame of #1, which is #0. As #0 is not inline it will have a
valid frame-id, and so we create a lazy register value using #0 as the
next-frame-id. This will give us the exact same result we had
previously (thanks to the code we inspected above).
Encoding into value_of_register_lazy the knowledge that reading an
inline frame register will always just forward to the next frame
feels.... not ideal, but this seems like the cleanest solution to this
recursive frame-id computation/sniffing issue that appears to crop
up.
The following two commits are fully reverted with this commit, these
correspond to patches [1] and [2] respectively:
commit
|
||
Luis Machado
|
991a3e2e99 |
Fix remaining inline/tailcall unwinding breakage for x86_64
Commit |
||
|
Luis Machado
|
5939967b35 |
Fix inline frame unwinding breakage
There has been some breakage for aarch64-linux, arm-linux and s390-linux in terms of inline frame unwinding. There may be other targets, but these are the ones i'm aware of. The following testcases started to show numerous failures and trigger internal errors in GDB after commit |
||
Tom Tromey
|
8084e579e1 |
Return unique_xmalloc_ptr from call_site_find_chain
call_site_find_chain returns a pointer that the caller must deallocate. It seemed better here to return a unique_xmalloc_ptr instead. gdb/ChangeLog 2020-02-14 Tom Tromey <tromey@adacore.com> * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Update. * dwarf2/loc.h (call_site_find_chain): Return unique_xmalloc_ptr. * dwarf2/loc.c (call_site_find_chain_1): Return unique_xmalloc_ptr. (call_site_find_chain): Likewise. |
||
Tom Tromey
|
82ca895718 |
Move DWARF code to dwarf2/ subdirectory
This moves all the remaining DWARF code to the new dwarf2 subdirectory. This is just a simple renaming, with updates to includes as needed. gdb/ChangeLog 2020-02-08 Tom Tromey <tom@tromey.com> * dwarf2/expr.c: Rename from dwarf2expr.c. * dwarf2/expr.h: Rename from dwarf2expr.h. * dwarf2/frame-tailcall.c: Rename from dwarf2-frame-tailcall.c. * dwarf2/frame-tailcall.h: Rename from dwarf2-frame-tailcall.h. * dwarf2/frame.c: Rename from dwarf2-frame.c. * dwarf2/frame.h: Rename from dwarf2-frame.h. * dwarf2/index-cache.c: Rename from dwarf-index-cache.c. * dwarf2/index-cache.h: Rename from dwarf-index-cache.h. * dwarf2/index-common.c: Rename from dwarf-index-common.c. * dwarf2/index-common.h: Rename from dwarf-index-common.h. * dwarf2/index-write.c: Rename from dwarf-index-write.c. * dwarf2/index-write.h: Rename from dwarf-index-write.h. * dwarf2/loc.c: Rename from dwarf2loc.c. * dwarf2/loc.h: Rename from dwarf2loc.h. * dwarf2/read.c: Rename from dwarf2read.c. * dwarf2/read.h: Rename from dwarf2read.h. * dwarf2/abbrev.c, aarch64-tdep.c, alpha-tdep.c, amd64-darwin-tdep.c, arc-tdep.c, arm-tdep.c, bfin-tdep.c, compile/compile-c-symbols.c, compile/compile-cplus-symbols.c, compile/compile-loc2c.c, cris-tdep.c, csky-tdep.c, findvar.c, gdbtypes.c, guile/scm-type.c, h8300-tdep.c, hppa-bsd-tdep.c, hppa-linux-tdep.c, i386-darwin-tdep.c, i386-linux-tdep.c, i386-tdep.c, iq2000-tdep.c, m32c-tdep.c, m68hc11-tdep.c, m68k-tdep.c, microblaze-tdep.c, mips-tdep.c, mn10300-tdep.c, msp430-tdep.c, nds32-tdep.c, nios2-tdep.c, or1k-tdep.c, riscv-tdep.c, rl78-tdep.c, rs6000-tdep.c, rx-tdep.c, s12z-tdep.c, s390-tdep.c, score-tdep.c, sh-tdep.c, sparc-linux-tdep.c, sparc-tdep.c, sparc64-linux-tdep.c, sparc64-tdep.c, tic6x-tdep.c, tilegx-tdep.c, v850-tdep.c, xstormy16-tdep.c, xtensa-tdep.c: Update. * Makefile.in (COMMON_SFILES): Update. (HFILES_NO_SRCDIR): Update. Change-Id: Ied9ce1436cd27ac4a4cffef10ec92e396f181928 |