| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The DWARF standard states for the line register in the line number information
state machine the following:
...
An unsigned integer indicating a source line number. Lines are numbered
beginning at 1. The compiler may emit the value 0 in cases where an
instruction cannot be attributed to any source line.
...
So, it's possible to have a zero line number in the DWARF line table.
This is currently not handled by GDB. The zero value is read in as any other
line number, but internally the zero value has a special meaning:
end-of-sequence, so the line table entry ends up having a different
interpretation than intended in some situations.
I've created a test-case where various aspects are tested, which has these 4
interesting tests.
1. Next-step through a zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
2. Next-step through a zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
3. Show source location at zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
4. Show source location at zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
And we have the following results:
8.3.1, 9.2:
...
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt
field":
...
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting",
master:
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243,
where clang emits zero line numbers.
The way to fix all tests is to make sure line number zero internally doesn't
clash with special meaning values, and by handling it appropriately
everywhere. That however looks too intrusive for the GDB 10 release.
Instead, we decide to ensure defined behaviour for line number zero by
ignoring it. This gives us back the test results from before commit
d8cc8af6a1, fixing PR26243.
We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for
the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb
10 the cost for having defined behaviour.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-07-25 Tom de Vries <tdevries@suse.de>
PR symtab/26243
* dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line
entries.
gdb/testsuite/ChangeLog:
2020-07-25 Tom de Vries <tdevries@suse.de>
PR symtab/26243
* gdb.dwarf2/dw2-line-number-zero.c: New test.
* gdb.dwarf2/dw2-line-number-zero.exp: New file.
|
|
While experimenting with GDB on DWARF 5 with split debug (dwo files),
I discovered that GDB was not reading the rnglist index
properly (it needed to be reprocessed in the same way the loclist
index does), and that there was no code for reading rnglists out of
dwo files at all. Also, the rnglist address reading function
(dwarf2_rnglists_process) was adding the base address to all rnglist
entries, when it's only supposed to add it to the DW_RLE_offset_pair
entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not
handling several entry types.
- Added 'reprocessing' for reading rnglist index (as is done for loclist
index).
- Added code for reading rnglists out of .dwo files.
- Added several missing rnglist forms to dwarf2_rnglists_process.
- Fixed bug that was alwayas adding base address for rnglists (only
one form needs that).
- Updated dwarf2_rnglists_process to read rnglist out of dwo file when
appropriate.
- Added new functions cu_debug_rnglist_section & read_rnglist_index.
- Added new testcase, dw5-rnglist-test.{cc,exp}
Special note about the new testcase:
In order for the test case to test anything meaningful, it must be
compiled with clang, not GCC. The way to do this is as follows:
$ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp"
This following version of clang was used for this testing:
clang version 9.0.1-11
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d
|
|
Add setters, to ensure that the kind and value of the property are
always kept in sync (a caller can't forget one or the other). Add
getters, such that we can assert that when a caller accesses a data bit
of the property, the property is indeed of the corresponding kind.
Note that because of the way `struct dynamic_prop` is allocated
currently, we can't make the `m_kind` and `m_data` fields private. That
would make the type non-default-constructible, and we would have to call
the constructor when allocating them. However, I still prefixed them
with `m_` to indicate that they should not be accessed from outside the
class (and also to be able to use the name `kind` for the method).
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop) <kind, set_undefined,
const_val, set_const_val, baton, set_locexpr, set_loclist,
set_addr_offset, variant_parts, set_variant_parts,
original_type, set_original_type>: New methods.
<kind>: Rename to...
<m_kind>: ... this. Update all users to use the new methods
instead.
<data>: Rename to...
<m_data>: ... this. Update all users to use the new methods
instead.
Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
|
|
Remove it in favor of using type::bounds directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_RANGE_DATA): Remove. Update callers to use
the type::bounds method directly.
Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2
|
|
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.
|
|
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 5939967b355ba6a940887d19847b7893a4506067
Date: Tue Apr 14 17:26:22 2020 -0300
Fix inline frame unwinding breakage
commit 991a3e2e9944a4b3a27bd989ac03c18285bd545d
Date: Sat Apr 25 00:32:44 2020 -0300
Fix remaining inline/tailcall unwinding breakage for x86_64
gdb/ChangeLog:
PR python/22748
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove
special handling for inline frames.
* findvar.c (value_of_register_lazy): Skip inline frames when
creating lazy register values.
* frame.c (frame_id_computed_p): Delete definition.
* frame.h (frame_id_computed_p): Delete declaration.
gdb/testsuite/ChangeLog:
PR python/22748
* gdb.opt/inline-frame-tailcall.c: New file.
* gdb.opt/inline-frame-tailcall.exp: New file.
* gdb.python/py-unwind-inline.c: New file.
* gdb.python/py-unwind-inline.exp: New file.
* gdb.python/py-unwind-inline.py: New file.
|
|
LLD from 11 onwards (https://reviews.llvm.org/D81784) uses -1 to
represent a relocation in .debug_line referencing a discarded symbol.
Recognize -1 to fix gdb.base/break-on-linker-gcd-function.exp when the
linker is a newer LLD.
gdb/ChangeLog:
* dwarf2/read.c (lnp_state_machine::check_line_address): Test -1.
|
|
Currently, GDB rejects the (die) reference form while it accepts exprloc
form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings"
in DWARF5 standard. Flang compiler assigns (die) reference to
DW_AT_associated and DW_AT_allocated for some cases.
gdb/ChangeLog
* dwarf2/read.c (set_die_type): Removed conditions to restrict
forms for DW_AT_associated and DW_AT_allocated attributes,
which is already checked in function attr_to_dynamic_prop.
|
|
Tom de Vries pointed out that some Rust tests were failing after the
variant part rewrite. He sent an executable, which helped track down
this bug.
quirk_rust_enum was passing 1 to alloc_rust_variant in one case.
However, a comment earlier says:
/* We don't need a range entry for the discriminant, but we do
need one for every other field, as there is no default
variant. */
In this case, we must pass -1 for this parameter. That is what this
patch implements.
gdb/ChangeLog
2020-06-30 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (quirk_rust_enum): Correctly call
alloc_rust_variant for default-less enum.
|
|
Add some empty lines at places I forgot in the previous patch.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loclists_addresses): Add empty
lines.
Change-Id: I8a9f3766ede1ce750e0703023285dca873bce0da
|
|
I always found that some switch statements in this file were a bit too
packed. I think having empty lines between each case helps with
reading. I'm pushing this as obvious, I hope it won't be too
controversial.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loc_dwo_addresses): Add empty
lines.
(dwarf2_find_location_expression): Likewise.
(call_site_parameter_matches): Likewise.
(dwarf2_compile_expr_to_ax): Likewise.
(disassemble_dwarf_expression): Likewise.
(loclist_describe_location): Likewise.
Change-Id: I381366a0468ff1793faa612c46ef48a9d4773192
|
|
This patch fixes an internal error that is triggered when loading the
same binary twice with the index-cache on:
$ ./gdb -q -nx --data-directory=data-directory
(gdb) set index-cache on
(gdb) shell mktemp -d
/tmp/tmp.BLgouVoPq4
(gdb) set index-cache directory /tmp/tmp.BLgouVoPq4
(gdb) file a.out
Reading symbols from a.out...
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2540: internal-error: void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, const gdb_byte*, offset_type): Assertion `per_bfd->all_comp_units.empty ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is what happens:
1. We load the binary the first time, partial symtabs are created,
per_bfd->all_comp_units is filled from those.
2. Because index-cache is on, we also generate an index in the cache.
3. We load the binary a second time, in dwarf2_initialize_objfile we
check: was an index already loaded for this BFD? No, so we try to
read the index and fill the per-bfd using it. We do find an index,
it's in the cache.
4. The function create_cus_from_index asserts (rightfully) that
per_cu->all_comp_units is empty, and the assertion fails.
This assertion verifies that we are not reading an index for a BFD for
which we have already built partial symtabs or read another index.
The index-cache gives a situation that isn't currently accounted for: a
BFD for which we have built the partial symtabs the first time, but has
an index the second time.
This patch addresses it by checking for the presence of partial symtabs
in dwarf2_initialize_objfile. If there are, we don't try reading the
index.
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_initialize_objfile): Check for presence
of partial symtabs.
gdb/testsuite/ChangeLog:
* gdb.base/index-cache-load-twice.c: New.
* gdb.base/index-cache-load-twice.exp: New.
Change-Id: Ie05474c44823fcdff852b73170dd28dfd66cb6a2
|
|
This commit changes the language_data::la_get_symbol_name_matcher
function pointer member variable into a member function of
language_defn.
There should be no user visible changes after this commit.
Before this commit access to the la_get_symbol_name_matcher function
pointer was through the get_symbol_name_matcher function, which looked
something like this (is pseudo-code):
<return-type>
get_symbol_name_matcher (language_defn *lang, <other args>)
{
if (current_language == ada)
current_language->la_get_symbol_name_matcher (<other args>);
else
lang->la_get_symbol_name_matcher (<other args>);
}
In this commit I moved the get_symbol_name_matcher as a non-virtual
function in the language_defn base class, I then add a new virtual
method that is only used from within get_symbol_name_matcher, this can
then be overridden by specific languages as needed. So we now have:
class language_defn
{
<return-type> get_symbol_name_matcher (<args>)
{
if (current_language == ada)
return current_language->get_symbol_name_matcher_inner (<args>);
else
return this->get_symbol_name_matcher_inner (<args>);
}
virtual <return-type> get_symbol_name_matcher_inner (<args>)
{
....
}
}
gdb/ChangeLog:
* ada-lang.c (ada_get_symbol_name_matcher): Update header comment.
(ada_language_data): Delete la_get_symbol_name_matcher
initializer.
(language_defn::get_symbol_name_matcher_inner): New member
function.
* c-lang.c (c_language_data): Delete la_get_symbol_name_matcher
initializer.
(cplus_language_data): Likewise.
(cplus_language::get_symbol_name_matcher_inner): New member
function.
(asm_language_data): Delete la_get_symbol_name_matcher initializer.
(minimal_language_data): Likewise.
* cp-support.h (cp_get_symbol_name_matcher): Update header comment.
* d-lang.c (d_language_data): Delete la_get_symbol_name_matcher
initializer.
* dictionary.c (iter_match_first_hashed): Update call to
get_symbol_name_matcher.
(iter_match_next_hashed): Likewise.
(iter_match_next_linear): Likewise.
* dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Likewise.
* f-lang.c (f_language_data): Delete la_get_symbol_name_matcher
initializer.
(f_language::get_symbol_name_matcher_inner): New member function.
* go-lang.c (go_language_data): Delete la_get_symbol_name_matcher
initializer.
* language.c (default_symbol_name_matcher): Update header comment,
make static.
(language_defn::get_symbol_name_matcher): New definition.
(language_defn::get_symbol_name_matcher_inner): Likewise.
(get_symbol_name_matcher): Delete.
(unknown_language_data): Delete la_get_symbol_name_matcher
initializer.
(auto_language_data): Likewise.
* language.h (language_data): Delete la_get_symbol_name_matcher
field.
(language_defn::get_symbol_name_matcher): New member function.
(language_defn::get_symbol_name_matcher_inner): Likewise.
(default_symbol_name_matcher): Delete declaration.
* linespec.c (find_methods): Update call to
get_symbol_name_matcher.
* m2-lang.c (m2_language_data): Delete la_get_symbol_name_matcher
initializer.
* minsyms.c (lookup_minimal_symbol): Update call to
get_symbol_name_matcher.
(iterate_over_minimal_symbols): Likewise.
* objc-lang.c (objc_language_data): Delete
la_get_symbol_name_matcher initializer.
* opencl-lang.c (opencl_language_data): Likewise.
* p-lang.c (pascal_language_data): Likewise.
* psymtab.c (psymbol_name_matches): Update call to
get_symbol_name_matcher.
* rust-lang.c (rust_language_data): Delete
la_get_symbol_name_matcher initializer.
* symtab.c (symbol_matches_search_name): Update call to
get_symbol_name_matcher.
(compare_symbol_name): Likewise.
|
|
This commit changes the language_data::la_class_name_from_physname function
pointer member variable into a member function of language_defn.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data) Delete
la_class_name_from_physname initializer.
* c-lang.c (c_language_data): Likewise.
(cplus_language_data): Likewise.
(cplus_language::class_name_from_physname): New member function.
(asm_language_data): Delete la_class_name_from_physname
initializer.
(minimal_language_data): Likewise.
* d-lang.c (d_language_data): Likewise.
* dwarf2/read.c (guess_partial_die_structure_name): Update to call
method on language_defn class.
(guess_full_die_structure_name): Likewise.
* f-lang.c (f_language_data): Delete la_class_name_from_physname
initializer.
* go-lang.c (go_language_data): Likewise.
* language.c (language_class_name_from_physname): Delete.
(unk_lang_class_name): Delete.
(unknown_language_data): Delete la_class_name_from_physname
initializer.
(auto_language_data): Likewise.
* language.h (language_data): Delete la_class_name_from_physname
field.
(language_defn::class_name_from_physname): New function.
(language_class_name_from_physname): Delete declaration.
* m2-lang.c (m2_language_data): Delete la_class_name_from_physname
initializer.
* objc-lang.c (objc_language_data): Likewise.
* opencl-lang.c (opencl_language_data): Likewise.
* p-lang.c (pascal_language_data): Likewise.
* rust-lang.c (rust_language_data): Likewise.
|
|
Currently the .gdb_index is not enabled for ada executables (PR24713).
Fix this by adding the required support in write_psymbols, similar to how that
is done for .debug_names in debug_names::insert.
Tested on x86_64-linux, with native and target board cc-with-gdb-index.
gdb/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
PR ada/24713
* dwarf2/index-write.c (struct mapped_symtab): Add m_string_obstack.
(write_psymbols): Enable .gdb_index for ada.
* dwarf2/read.c: Remove comment stating .gdb_index is unsupported for
ada.
gdb/testsuite/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
* gdb.ada/ptype_union.exp: Remove PR24713 workaround.
|
|
In commit 9a0bacfb08 "[gdb/symtab] Handle .gdb_index in ada language mode", a
missing part of dw2_map_matching_symbols was added, containing a call to
dw2_expand_symtabs_matching_symbol.
However, the callback passed to that call has one problem: the callback has an
argument "offset_type namei", which is ignored. Instead, match_name is passed
as argument to dw2_symtab_iter_init, where a name lookup is done, which may or
may not yield the same value as namei.
Fix this by creating a new version of dw2_symtab_iter_init that takes a
"offset_type namei" argument instead of "const char *name", and passing namei.
Tested on x86_64-linux, with native and target board cc-with-gdb-index.
gdb/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (dw2_symtab_iter_init_common): Factor out of ...
(dw2_symtab_iter_init): ... here. Add variant with "offset_type
namei" instead of "const char *name" argument.
(dw2_map_matching_symbols): Use "offset_type namei" variant of
dw2_symtab_iter_init.
|
|
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use
`type::field` and `field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites
to use type::field and field::type instead.
Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
|
|
Remove the `FIELD_TYPE` macro, changing all the call sites to use
`field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (FIELD_TYPE): Remove. Change all call sites
to use field::type instead.
Change-Id: I7673fedaa276e485189c87991a9043495da22ef5
|
|
Add the `type` and `set_type` methods on `struct field`, in order to
remoremove the `FIELD_TYPE` macro. In this patch, the `FIELD_TYPE`
macro is changed to use `field::type`, so all the call sites that are
useused to set the field's type are changed to use `field::set_type`.
The next patch will remove `FIELD_TYPE` completely.
Note that because of the name clash between the existing field named
`type` and the new method, I renamed the field `m_type`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
gdb/ChangeLog:
* gdbtypes.h (struct field) <type, set_type>: New methods.
Rename `type` field to...
<m_type>: ... this. Change references throughout to use type or
set_type methods.
(FIELD_TYPE): Use field::type. Change call sites that modify
the field's type to use field::set_type instead.
Change-Id: Ie21f866e3b7f8a51ea49b722d07d272a724459a0
|
|
Fix/follow-up to commit 17ee85fc2a ("Share DWARF partial symtabs").
In the non-index case, where GDB builds partial symbols from scratch,
two objfiles around the same BFD correctly share partial symtabs. The
first objfile, which has to do all the work, saves a reference to the
created partial symtabs in the shared per_bfd object (at the end of
dwarf2_build_psymtabs). The second objfile, when it reaches
dwarf2_build_psymtabs, sees that there are already partial symtabs built
for this BFD and just uses it.
However, that commit missed implementing the same sharing for cases
where GDB uses .gdb_index or .debug_names to build the partial symtabs.
This patch fixes it by having the first objfile to use the BFD set
per_bfd->partial_symtabs at the end of dwarf2_read_gdb_index /
dwarf2_read_debug_names. For the subsequent objfiles using that BFD,
the partial symtabs are then picked up in dwarf2_initialize_objfile.
This patch adds a test that mimics how the issue was originally
triggered:
1. Load the test file twice, such that the second objfile re-uses the
per_bfd object created for the first objfile.
2. Run to some point where in the backtrace there is a frame for a
function that's in a CU that's not yet read in.
3. Check that this frame's information is complete in the "backtrace"
output.
Step 2 requires an address -> symbol lookup which uses the addrmap at
objfile->partial_symtabs->psymtabs_addrmap. If the
objfile->partial_symtabs link is not properly setup (as is the case
before this patch), the symbol for that frame won't be found and we'll
get a frame with incomplete information.
The test fails without the fix when using boards "cc-with-gdb-index" and
"cc-with-debug-names".
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_read_gdb_index): Save partial_symtabs in
the per_bfd object.
(dwarf2_read_debug_names): Likewise.
(dwarf2_initialize_objfile): Use partial_symtabs from per_bfd
object when re-using a per_bfd object with an index.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/share-psymtabs-bt.exp: New file.
* gdb.dwarf2/share-psymtabs-bt.c: New file.
* gdb.dwarf2/share-psymtabs-bt-2.c: New file.
Change-Id: Ibb26210e2dfc03b80ba9fa56b875ba4cc58c0352
|
|
Consider the test-case contained in this patch.
With -readnow, we have two breakpoint locations:
...
$ gdb -readnow -batch breakpoint-locs -ex "b N1::C1::baz" -ex "info break"
Breakpoint 1 at 0x4004cb: N1::C1::baz. (2 locations)
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004004cb in N1::C1::baz() \
at breakpoint-locs.h:6
1.2 y 0x00000000004004f0 in N1::C1::baz() \
at breakpoint-locs.h:6
...
But without -readnow, we have instead only one breakpoint location:
...
$ gdb -batch breakpoint-locs -ex "b N1::C1::baz" -ex "info break"
Breakpoint 1 at 0x4004f0: file breakpoint-locs.h, line 6.
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004004f0 in N1::C1::baz() \
at breakpoint-locs.h:6
...
The relevant dwarf is this bit:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : breakpoint-locs.cc
<1><f4>: Abbrev Number: 2 (DW_TAG_namespace)
<f5> DW_AT_name : N1
<2><fe>: Abbrev Number: 3 (DW_TAG_class_type)
<ff> DW_AT_name : C1
<3><109>: Abbrev Number: 4 (DW_TAG_subprogram)
<10a> DW_AT_name : baz
<110> DW_AT_linkage_name: _ZN2N12C13bazEv
<2><116>: Abbrev Number: 5 (DW_TAG_subprogram)
<117> DW_AT_name : foo
<11d> DW_AT_linkage_name: _ZN2N13fooEv
<1><146>: Abbrev Number: 8 (DW_TAG_subprogram)
<147> DW_AT_specification: <0x116>
<14b> DW_AT_low_pc : 0x4004c7
<153> DW_AT_high_pc : 0x10
<2><161>: Abbrev Number: 9 (DW_TAG_inlined_subroutine)
<162> DW_AT_abstract_origin: <0x194>
<166> DW_AT_low_pc : 0x4004cb
<16e> DW_AT_high_pc : 0x9
<1><194>: Abbrev Number: 12 (DW_TAG_subprogram)
<195> DW_AT_specification: <0x109>
<199> DW_AT_inline : 3 (declared as inline and inlined)
...
The missing breakpoint location is specified by DIE 0x161, which is ignored by
the partial DIE reader because it's a child of a DW_TAG_subprogram DIE (at
0x146, for foo).
Fix this by not ignoring the DIE during partial DIE reading.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-06-03 Tom de Vries <tdevries@suse.de>
PR symtab/26046
* dwarf2/read.c (scan_partial_symbols): Recurse into DW_TAG_subprogram
children for C++.
(load_partial_dies): Don't skip DW_TAG_inlined_subroutine child of
DW_TAG_subprogram.
gdb/testsuite/ChangeLog:
2020-06-03 Tom de Vries <tdevries@suse.de>
PR symtab/26046
* gdb.cp/breakpoint-locs-2.cc: New test.
* gdb.cp/breakpoint-locs.cc: New test.
* gdb.cp/breakpoint-locs.exp: New file.
* gdb.cp/breakpoint-locs.h: New test.
|
|
After the is-stmt support commit:
commit 8c95582da858ac981f689a6f599acacb8c5c490f
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
A regression was observed where a breakpoint could no longer be placed
in some cases.
Consider a line table like this:
File 1: test.c
File 2: test.h
| Addr | File | Line | Stmt |
|------|------|------|------|
| 1 | 1 | 16 | Y |
| 2 | 1 | 17 | Y |
| 3 | 2 | 21 | Y |
| 4 | 2 | 22 | Y |
| 4 | 1 | 18 | N |
| 5 | 2 | 23 | N |
| 6 | 1 | 24 | Y |
| 7 | 1 | END | Y |
|------|------|------|------|
Before the is-stmt patch GDB would ignore any non-stmt lines, so GDB
built two line table structures:
File 1 File 2
------ ------
| Addr | Line | | Addr | Line |
|------|------| |------|------|
| 1 | 16 | | 3 | 21 |
| 2 | 17 | | 4 | 22 |
| 3 | END | | 6 | END |
| 6 | 24 | |------|------|
| 7 | END |
|------|------|
After the is-stmt patch GDB now records non-stmt lines, so the
generated line table structures look like this:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 4 | END | Y |
| 4 | 18 | N | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
The problem is that in 'File 2', end END marker at address 4 causes
the previous line table entry to be discarded, so we actually end up
with this:
File 2
------
| Addr | Line | Stmt |
|------|------|------|
| 3 | 21 | Y |
| 4 | END | Y |
| 5 | 23 | N |
| 6 | END | Y |
|------|------|------|
When a user tries to place a breakpoint in file 2 at line 22, this is
no longer possible.
The solution I propose here is that we ignore line table entries that
would trigger a change of file if:
1. The new line being added is at the same address as the previous
line, and
2. We have previously seen an is-stmt line at the current address.
The result of this is that GDB switches file, and knows that some line
entry (or entries) are going to be discarded, prefer to keep is-stmt
lines and discard non-stmt lines.
After this commit the lines tables are now:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
We've lost the non-stmt entry for file 1, line 18, but retained the
is-stmt entry for file 2, line 22. The user can now place a
breakpoint at that location.
One problem that came from this commit was the test
gdb.cp/step-and-next-inline.exp, which broke in several places. After
looking at this test again I think that in some cases this test was
only ever passing by pure luck. The debug GCC is producing for this
test is pretty broken. I raised this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
for this and disabled one entire half of the test. There are still
some cases in here that do pass, and if/when GCC is fixed it would be
great to enable this test again.
gdb/ChangeLog:
* dwarf2/read.c (class lnp_state_machine) <m_last_address>: New
member variable.
<m_stmt_at_address>: New member variable.
(lnp_state_machine::record_line): Don't record some lines, update
tracking of is_stmt at the same address.
(lnp_state_machine::lnp_state_machine): Initialise new member
variables.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.exp (do_test): Skip all tests in the
use_header case.
* gdb.dwarf2/dw2-inline-header-1.exp: New file.
* gdb.dwarf2/dw2-inline-header-2.exp: New file.
* gdb.dwarf2/dw2-inline-header-3.exp: New file.
* gdb.dwarf2/dw2-inline-header-lbls.c: New file.
* gdb.dwarf2/dw2-inline-header.c: New file.
* gdb.dwarf2/dw2-inline-header.h: New file.
|
|
While doing the psymtab-sharing patchset, I avoided renaming variables
unnecessarily to avoid adding noise to patches, but I'd like to do it
now. Basically, we have these dwarf2 per-something structures:
- dwarf2_per_objfile
- dwarf2_per_bfd
- dwarf2_per_cu_data
I named the instances of dwarf2_per_bfd `per_bfd` and most of instances
of dwarf2_per_cu_data are called `per_cu`. Most pre-existing instances
of dwarf2_per_objfile are named `dwarf2_per_objfile`. For consistency
with the other type, I'd like to rename them to just `per_objfile`. The
`dwarf2_` prefix is superfluous, since it's already clear we are in
dwarf2 code. It also helps reducing the line wrapping by saving 7
precious columns.
gdb/ChangeLog:
* dwarf2/comp-unit.c, dwarf2/comp-unit.h, dwarf2/index-cache.c,
dwarf2/index-cache.h, dwarf2/index-write.c,
dwarf2/index-write.h, dwarf2/line-header.c,
dwarf2/line-header.h, dwarf2/macro.c, dwarf2/macro.h,
dwarf2/read.c, dwarf2/read.h: Rename struct dwarf2_per_objfile
variables and fields from `dwarf2_per_objfile` to just
`per_objfile` throughout.
Change-Id: I3c45cdcc561265e90df82cbd36b4b4ef2fa73aef
|
|
Add a comment to clarify why we temporarily override some of the
context's fields, and especially the per_objfile field. A longer
explanation can be found in this previous commit
44486dcf19b ("gdb: use caller objfile in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value")
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Add comment.
Change-Id: I60c6e1062799f729b30a9db78bcb6448783324b4
|
|
In commit
89b07335fe ("Add dwarf2_per_objfile to dwarf_expr_context and dwarf2_frame_cache")
I replaced the offset property of dwarf_expr_context by a per_objfile
property (since we can get the text offset from the objfile). The
previous code in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value
(dwarf_evaluate_loc_desc derives from dwarf_expr_context) did
temporarily override the offset property while evaluating a DWARF
sub-expression. I speculated that this sub-expression always came from
the same objfile as the outer expression, so I didn't see the need to
temporarily override the per_objfile property in the new code. A later
commit:
9f47c70716 ("Remove dwarf2_per_cu_data::objfile ()")
added the following assertion to verify this:
gdb_assert (this->per_objfile == caller_per_objfile);
It turns out that this is not true. Call sites can refer to function in
another objfile, and therefore the caller's objfile can be different
from the callee's objfile. This can happen when the call site DIE in the
DWARF represents a function call done through a function pointer. The
DIE can't describe statically which function is being called, since it's
variable and not known at compile time. Instead, it provides an
expression that evaluates to the address of the function being called.
In this case, the called function can very well be in a separate
objfile.
Fix this by overriding the per_objfile property while evaluating the
sub-expression.
This was exposed by the gdb.base/catch-load.exp test failing on openSUSE
Tumbleweed with the glibc debug info installed. It was also reported to
fail on Fedora.
When I investigated the problem, the particular call site on which we
did hit the assert was coming from this DIE, in
/usr/lib/debug/lib64/libc-2.31.so-2.31-5.1.x86_64.debug on openSUSE
Tumbleweed:
0x0091aa10: DW_TAG_GNU_call_site
DW_AT_low_pc [DW_FORM_addr] (0x00000000001398e0)
DW_AT_GNU_call_site_target [DW_FORM_exprloc] (DW_OP_fbreg -272, DW_OP_deref)
DW_AT_sibling [DW_FORM_ref4] (0x0091aa2b)
And for you curious out there, this call site is found in this function:
0x0091a91d: DW_TAG_subprogram
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_name [DW_FORM_strp] ("_dl_catch_exception")
DW_AT_decl_file [DW_FORM_data1] ("/usr/src/debug/glibc-2.31-5.1.x86_64/elf/dl-error-skeleton.c")
...
Which is a function that indeed uses a function pointer.
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Remove assert. Override
per_objfile with caller_per_objfile.
Change-Id: Ib227d767ce525c10607ab6621a373aaae982c67a
|
|
There's a PR gold/15646 - "gold-generated .gdb_index has duplicated
symbols that gdb-generated index doesn't", that causes gold to generate
duplicate symbols in the index.
F.i., a namespace N1 declared in a header file can be listed for two CUs that
include the header file:
...
[759] N1:
2 [global type]
3 [global type]
...
This causes a gdb performance problem: f.i. when attempting to set a
breakpoint on a non-existing function N1::misspelled, the symtab for both CUs
will be expanded.
Gdb contains a workaround for this, added in commit 8943b87476 "Work around
gold/15646", that skips duplicate global symbols in the index.
However, the workaround does not check for the symbol kind ("type" in the
example above).
Make the workaround more precise by limiting it to symbol kind "type".
Tested on x86_64-linux, with target boards cc-with-gdb-index and
gold-gdb-index.
gdb/ChangeLog:
2020-05-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (dw2_symtab_iter_next, dw2_expand_marked_cus): Limit
PR gold/15646 workaround to symbol kind "type".
|
|
An earlier patch added the add_partial_symbol helper function to
dwarf2/read.c. However, a couple of calls to add_psymbol_to_list were
left in place. It turns out that these calls slow down partial symbol
reading, because they still go via the path that tries to needlessly
demangle already-demangled names.
This patch improves the performance of partial symbol reading by
changing this code to use add_partial_symbol instead.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.64
libxul 1.99
Ada 2.47
This patch improves the times to:
gdb 1.47
libxul 1.89
Ada 2.39
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (load_partial_dies): Use add_partial_symbol.
|
|
Profiling showed that calls to abbrev_table::lookup_abbrev were "too
visible". As these are just forwarding calls to the hash table, this
patch inlines the lookup. Also, htab_find_with_hash is used, avoiding
another call.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.69
libxul 2.02
Ada 2.52
This patch improves the times to:
gdb 1.64
libxul 1.99
Ada 2.47
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/abbrev.h (struct abbrev_table) <lookup_abbrev>: Inline.
Use htab_find_with_hash.
<add_abbrev>: Remove "abbrev_number" parameter.
* dwarf2/abbrev.c (abbrev_table::add_abbrev): Remove
"abbrev_number" parameter. Use htab_find_slot_with_hash.
(hash_abbrev): Add comment.
(abbrev_table::lookup_abbrev): Move to header file.
(abbrev_table::read): Update.
|
|
Currently the name of a partial DIE is computed eagerly. However, the
name is not always needed. This patch changes partial DIEs to compute
their name lazily, improving performance by avoiding unnecessary name
computations.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.88
libxul 2.11
Ada 2.60
This patch improves the times to:
gdb 1.69
libxul 2.02
Ada 2.52
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct partial_die_info) <name>: Declare new
method.
<canonical_name>: New member.
<raw_name>: Rename from "name".
(partial_die_info): Initialize canonical_name.
(scan_partial_symbols): Check raw_name.
(partial_die_parent_scope, partial_die_full_name)
(add_partial_symbol, add_partial_subprogram)
(add_partial_enumeration, load_partial_dies): Use "name" method.
(partial_die_info::name): New method.
(partial_die_info::read, guess_partial_die_structure_name)
(partial_die_info::fixup): Update.
|
|
This inlines a couple of methods on struct attribute, improving the
performance of DWARF partial symbol reading. These methods were
discovered as hot spots using callgrind.
For this patch, and for all the patches in this series, I tested gdb's
performance on three programs:
1. gdb itself -- I built gdb and copied it to /tmp, ensuring that the
same version was used in all tests.
2. The system libxul.so, the main library of Firefox. I installed the
separate debuginfo and ensured that gdb read it.
3. A large-ish Ada program that I happen to have.
I ran gdb 10 times like:
/bin/time -f %e \
./gdb/gdb --data-directory ./gdb/data-directory -nx \
-iex 'set debug-file-directory /usr/lib/debug' \
-batch $X
... where $X was the test executable. Then I computed the mean time.
This was all done with a standard (-g -O2) build of gdb.
The baseline times were
gdb 1.90
libxul 2.12
Ada 2.61
This patch brings the numbers down to
gdb 1.88
libxul 2.11
Ada 2.60
Not a huge change, but still visible in the results.
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/attribute.h (struct attribute) <form_is_ref>: Inline.
<get_ref_die_offset>: Inline.
<get_ref_die_offset_complaint>: New method.
* dwarf2/attribute.c (attribute::form_is_ref): Move to header.
(attribute::get_ref_die_offset_complaint): Rename from
get_ref_die_offset. Just issue complaint.
|
|
This changes the DWARF reader to share partial symtabs (or indices if
they are available) across objfiles. This has a few parts.
* If multiple objfiles backed by the same BFD can share partial symtabs
(see below), a single dwarf2_per_bfd is created. It is stored in the
per-bfd `dwarf2_per_bfd_bfd_data_key` registry. Multiple
dwarf2_per_objfile objects will point to the same instance. The
lifetime of these dwarf2_per_bfd objects is naturally handled. When
all the objfiles using the BFD are destroyed, the BFD's refount drops
to 0, which triggers the removal of the corresponding dwarf2_per_bfd
object from the registry and its destruction.
* If multiple objfiles backed by the same BFD can't share partial
symtabs (see below), one dwarf2_per_bfd object is created for each
objfile. Each dwarf2_per_objfile will point to their own instance of
dwarf2_per_bfd. These instances of dwarf2_per_bfd are kept in a
per-objfile registry, meaning that when the objfile gets destroyed,
the dwarf2_per_bfd instance gets destroyed as well.
* objfile::partial_symtabs is changed to be a shared_ptr again. This
lets us stash a second reference in dwarf2_per_bfd; if the DWARF
data is being shared, we can simply copy this value to the new
objfile.
* Two dwarf2_per_objfile objects backed by the same BFD may share a
dwarf2_per_bfd instance if:
* No other symbol reader has found symbols, and
* No BFD section rqeuires relocation
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* objfiles.h (struct objfile) <partial_symtabs>: Now a
shared_ptr.
* dwarf2/read.h (struct dwarf2_per_objfile) <partial_symtabs>: New
member.
* dwarf2/read.c (dwarf2_per_bfd_bfd_data_key,
dwarf2_per_bfd_objfile_data_key>: New globals.
(dwarf2_has_info): Use shared dwarf2_per_bfd if possible.
(dwarf2_get_section_info): Use get_dwarf2_per_objfile.
(dwarf2_initialize_objfile): Consider cases where per_bfd can be
shared.
(dwarf2_build_psymtabs): Set objfile::partial_symtabs and
short-circuit when sharing.
(dwarf2_build_psymtabs): Set dwarf2_per_objfile::partial_symtabs.
(dwarf2_psymtab::expand_psymtab): Use free_cached_comp_units.
Change-Id: I868c64448589102ab8cbb8f06c31a8de50a14004
|
|
The `line_header_hash` field of `struct dwarf2_per_bfd` contains some
`struct line_header` objects. A `struct line_header` objects contains
some `file_entry` objects. A `file_entry` object contains a pointer to
the `symtab` object created from it. The `line_header_hash` is
therefore ultimately objfile-dependent and can't be shared as-is between
objfiles.
Move it from `dwarf2_per_bfd` to `dwarf2_per_objfile`.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_bfd) <line_header_hash>: Move
to...
(struct dwarf2_per_objfile) <line_header_hash>: ... here.
* dwarf2/read.c (handle_DW_AT_stmt_list): Update.
Change-Id: I8d2ee04df4f4847c2db99061fc976c35af98ac71
|
|
mapped_debug_names currently has a dwarf2_per_objfile field. Since we
want it to become objfile-independent, this field must be removed.
This patch removes it, and then arranges for all methods that needed it
to accept a dwarf2_per_objfile parameter. This trickles down at various
places, like the dw2_debug_names_iterator type.
Ultimately, the objfile only seems to be needed because we might need to
read a string from the string section. For that, we might need to read
in the section, and if it's a relocatable section, the objfile is needed
in order to do the relocation. This pattern happens often (that we to
pass an objfile only because a section might be read). I think it's a
bit ugly, but I don't have a good alternative right now.
gdb/ChangeLog:
* dwarf2/read.c (struct mapped_index_base) <symbol_name_at,
build_name_components, find_name_components_bounds>:
Add per_objfile parameter.
(struct mapped_index) <symbol_name_at>: Likewise.
(struct mapped_debug_names): Remove constructor.
<dwarf2_per_objfile>: Remove field.
<namei_to_name, symbol_name_at>: Add per_objfile parameter.
(mapped_index_base::find_name_components_bounds,
mapped_index_base::build_name_components,
dw2_expand_symtabs_matching_symbol): Likewise.
(class mock_mapped_index) <symbol_name_at>: Likewise.
(check_match): Likewise.
(check_find_bounds_finds): Likewise.
(test_mapped_index_find_name_component_bounds): Update.
(CHECK_MATCH): Update.
(dw2_expand_symtabs_matching): Update.
(class dw2_debug_names_iterator) <dw2_debug_names_iterator>: Add
per_objfile parameter.
<find_vec_in_debug_names>: Likewise.
<m_per_objfile>: New field.
(mapped_debug_names::namei_to_name): Add dwarf2_per_objfile
parameter.
(dw2_debug_names_iterator::find_vec_in_debug_names): Likewise.
(dw2_debug_names_iterator::next): Update.
(dw2_debug_names_lookup_symbol): Update.
(dw2_debug_names_expand_symtabs_for_function): Update.
(dw2_debug_names_map_matching_symbols): Update.
(dw2_debug_names_expand_symtabs_matching): Update.
(dwarf2_read_debug_names): Update.
Change-Id: I00ee0d939390d353442675c7d400a261307c57a1
|
|
The dwarf2_per_cu_data type is going to become objfile-independent,
while the dwarf2_cu type will stay object-dependent. This patch removes
the backlink from dwarf2_per_cu_data to dwarf2_cu, in favor of the
dwarf2_per_objfile::m_dwarf2_cus map. It maps dwarf2_per_cu_data
objects to the corresponding dwarf2_cu objects for this objfile. If a
CU has been read in in the context of this objfile, then an entry will
be present in the map.
The dwarf2_cu objects that are read in are currently kept in a linked
list rooted in the dwarf2_per_bfd. Except that the dwarf2_cu objects
are not simply linked together, they are interleaved with their
corresponding dwarf2_per_cu_data objects. So if we have CUs A and B
read in, the dwarf2_per_bfd::read_in_chain will point to a chain like
this (DPCD == dwarf2_per_cu_data, DC == dwarf2_cu):
DPCD A -> DC A -> DPCD B -> DC B
Obviously, this can't stay as is, since a same CU can be read in for an
objfile but not read in for another objfile sharing the same BFD, and
the dwarf2_per_cu_data::cu link is removed. This is all replaced by
the dwarf2_per_objfile::m_dwarf2_cus map.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_cu): Forward-declare.
(struct dwarf2_per_bfd) <free_cached_comp_units>: Remove,
move to dwarf2_per_objfile.
<read_in_chain>: Remove.
(struct dwarf2_per_objfile) <get_cu, set_cu, remove_cu,
remove_all_cus, age_comp_units>: New methods.
<m_dwarf2_cus>: New member.
(struct dwarf2_per_cu_data) <cu>: Remove.
* dwarf2/read.c (struct dwarf2_cu) <read_in_chain>: Remove.
(age_cached_comp_units, free_one_cached_comp_unit): Remove,
moved to methods of dwarf2_per_objfile.
(dwarf2_clear_marks): Remove.
(dwarf2_queue_item::~dwarf2_queue_item): Update.
(dwarf2_per_bfd::~dwarf2_per_bfd): Don't free dwarf2_cus.
(dwarf2_per_bfd::free_cached_comp_units): Remove.
(dwarf2_per_objfile::remove_all_cus): New.
(class free_cached_comp_units) <~free_cached_comp_units>:
Update.
(load_cu): Update.
(dw2_do_instantiate_symtab): Adjust.
(fill_in_sig_entry_from_dwo_entry): Adjust.
(cutu_reader::init_tu_and_read_dwo_dies): Update.
(cutu_reader::cutu_reader): Likewise.
(cutu_reader::keep): Use dwarf2_per_objfile::set_cu.
(cutu_reader::cutu_reader): Use dwarf2_per_objfile::get_cu.
(process_psymtab_comp_unit): Use dwarf2_per_objfile::remove_cu
and dwarf2_per_objfile::age_comp_units.
(load_partial_comp_unit): Update.
(maybe_queue_comp_unit): Use dwarf2_per_objfile::get_cu.
(process_queue): Likewise.
(find_partial_die): Use dwarf2_per_objfile::get_cu instead of cu
backlink.
(dwarf2_read_addr_index): Likewise.
(follow_die_offset): Likewise.
(dwarf2_fetch_die_loc_sect_off): Likewise.
(dwarf2_fetch_constant_bytes): Likewise.
(dwarf2_fetch_die_type_sect_off): Likewise.
(follow_die_sig_1): Likewise.
(load_full_type_unit): Likewise.
(read_signatured_type): Likewise.
(dwarf2_cu::dwarf2_cu): Don't set cu field.
(dwarf2_cu::~dwarf2_cu): Remove.
(dwarf2_per_objfile::get_cu): New.
(dwarf2_per_objfile::set_cu): New.
(age_cached_comp_units): Rename to...
(dwarf2_per_objfile::age_comp_units): ... this. Adjust
to std::unordered_map.
(free_one_cached_comp_unit): Rename to...
(dwarf2_per_objfile::remove_cu): ... this. Adjust
to std::unordered_map.
(dwarf2_per_objfile::~dwarf2_per_objfile): New.
(dwarf2_mark_helper): Use dwarf2_per_objfile::get_cu, expect
a dwarf2_per_objfile in data.
(dwarf2_mark): Pass dwarf2_per_objfile in data to htab_traverse.
(dwarf2_clear_marks): Remove.
Change-Id: Ia33ac71c79b2de4710569008e22a6563a1505cde
|
|
It is possible, seemingly for a special case described in
find_partial_die, for cutu_reader to re-use an existing dwarf2_cu
instead of creating a new one. This happens when running this test, for
example:
make check TESTS="gdb.dwarf2/fission-reread.exp"
Right now the, `use_existing_cu` flag tells cutu_reader to use the
dwarf2_cu object at dwarf2_per_cu_data::cu. However, we'll remove that
field, so we need to find another solution.
This situation arises when some caller up the stack has already created
the dwarf2_cu to read a dwarf2_per_cu_data, but needs to re-read it with
some other parameters. Therefore, it's possible to just have that
caller pass down the dwarf2_cu object to use as a `existing_cu`
parameter. If `existing_cu` is NULL, it tells cutu_reader that it needs
to instantiate a new one.
gdb/ChangeLog:
* dwarf2/read.c (class cutu_reader) <cutu_reader>: Replace
`int use_existing_cu` parameter with `dwarf2_cu *existing_cu`.
(init_tu_and_read_dwo_dies): Likewise.
(cutu_reader::init_tu_and_read_dwo_dies): Likewise.
(cutu_reader::cutu_reader): Likewise.
(load_partial_comp_unit): Likewise.
(process_psymtab_comp_unit): Update.
(build_type_psymtabs_1): Update.
(process_skeletonless_type_unit): Update.
(load_full_comp_unit): Update.
(find_partial_die): Update.
(dwarf2_read_addr_index): Update.
(read_signatured_type): Update.
Change-Id: Id03e3bc3de3cf99d9e4b4080ad83b029c93bf434
|
|
The per_cu_header_read_in function allows obtaining a filled
comp_unit_head object for a given dwarf2_per_cu_data object. If a
dwarf2_cu object exists for this dwarf2_per_cu_data, then it just
returns a pointer to the comp_unit_head from that dwarf2_cu. Otherwise,
it reads the header into a temporary buffer provided by the caller, and
returns a pointer to that.
Since the dwarf2_per_cu_data::cu link is going to be removed
(dwarf2_per_cu_data will become objfile-independent while dwarf2_cu
stays objfile-dependent), we cannot rely anymore on returning the header
from the dwarf2_cu object.
The not too complex solution implemented by this patch is to keep a copy
of the header in the dwarf2_per_cu_data object, independent from the
copy in dwarf2_cu. The new copy is only used in the addr_size,
offset_size and ref_addr_size methods of dwarf2_per_cu_data.
There's nothing intrinsic to the comp_unit_head object that prevents it
to be shared between two dwarf2_cu objects (belonging to different
objfiles) representing the same CU. In other words, I think we could
eventually get rid of the copy in dwarf2_cu to only keep the one in
dwarf2_per_cu_data. It is not trivial, however, so I have decided not
to do it for the moment.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <m_header,
m_header_read_in>: New fields.
<get_header>: New method.
* dwarf2/read.c (per_cu_header_read_in): Remove.
(dwarf2_per_cu_data::get_header): New.
(dwarf2_per_cu_data::addr_size): Update.
(dwarf2_per_cu_data::offset_size): Update.
(dwarf2_per_cu_data::ref_addr_size): Update.
Change-Id: Id7541fca7562843eba110ece21c4df38d45fca23
|
|
In a subsequent patch, the dwarf2_per_cu_data::cu link will be removed.
dwarf2_cu objects will instead need to be looked up from a per-objfile
map, using the dwarf2_per_cu_data object as the key.
To make it easier for some callers, this patch makes load_cu return the
dwarf2_cu it creates. If the caller needs to use the created dwarf2_cu,
it will have it available right away, rather than having to do a map
lookup.
At the same time, this allows changing queue_and_load_all_dwo_tus to
take a dwarf2_cu instead of a dwarf2_per_cu_data.
gdb/ChangeLog:
* dwarf2/read.c (load_cu): Return dwarf2_cu.
(dw2_do_instantiate_symtab): Update.
(queue_and_load_all_dwo_tus): Change parameter from
dwarf2_per_cu_data to dwarf2_cu.
(dwarf2_fetch_die_loc_sect_off): Update.
(dwarf2_fetch_constant_bytes): Update.
(dwarf2_fetch_die_type_sect_off): Update.
Change-Id: I8a04c5d1b8cc661b8203f97999258ba8e04e1765
|
|
These two functions work on a dwarf2_cu. It is currently obtained from
the per_cu->cu link, which we want to remove. Make them accept the
dwarf2_cu directly as a parameter. This moves the per_cu->cu references
one level up, but that one will be removed too in a subsequent patch.
gdb/ChangeLog:
* dwarf2/read.c (process_full_comp_unit,
process_full_type_unit): Remove per_cu, per_objfile paramters.
Add dwarf2_cu parameter.
(process_queue): Update.
Change-Id: I1027d36986073ac991e198e06f9d51341dc19c6e
|
|
functions
All these functions actually only need to receive a dwarf2_per_bfd, pass
that instead of dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.c (create_cu_from_index_list): Replace
dwarf2_per_objfile parameter with dwarf2_per_bfd.
(create_cus_from_index_list): Likewise.
(create_cus_from_index): Likewise.
(create_signatured_type_table_from_index): Likewise.
(create_cus_from_debug_names_list): Likewise.
(create_cus_from_debug_names): Likewise.
(dwarf2_read_gdb_index): Update.
(dwarf2_read_debug_names): Update.
Change-Id: I8cd7dc04bf815723a48745e7e9b283663dccc1ac
|
|
signatured_type has a link to the "struct type". However, types are
inherently objfile-specific, so once sharing is implemented, this will
be incorrect.
This patch moves the type to a new map in the DWARF unshareable
object.
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* dwarf2/read.h (struct dwarf2_per_objfile)
<get_type_for_signatured_type, set_type_for_signatured_type>:
New methods.
<m_type_map>: New member.
(struct signatured_type) <type>: Remove.
* dwarf2/read.c
(dwarf2_per_objfile::get_type_for_signatured_type,
dwarf2_per_objfile::set_type_for_signatured_type): New.
(get_signatured_type): Use new methods.
Change-Id: I765ae3c43fae1064f51ced352167a57638609f02
|
|
type_unit_group has links to the compunit_symtab and other symtabs.
However, once this object is shared across objfiles, this will no
longer be ok.
This patch introduces a new type_unit_group_unshareable and arranges to
store a map from type unit groups to type_unit_group_unshareable objects
in dwarf2_per_objfile.
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* dwarf2/read.h (struct type_unit_group_unshareable): New.
(struct dwarf2_per_objfile) <type_units>: New member.
<get_type_unit_group_unshareable>: New method.
* dwarf2/read.c (struct type_unit_group) <compunit_symtab,
num_symtabs, symtabs>: Remove; move to
type_unit_group_unshareable.
(dwarf2_per_objfile::get_type_unit_group_unshareable): New.
(process_full_type_unit, dwarf2_cu::setup_type_unit_groups)
(dwarf2_cu::setup_type_unit_groups): Use type_unit_group_unshareable.
Change-Id: I1fec2fab59e0ec40fee3614fc821172a469c0e41
|
|
Nothing references this field anymore, remove it.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data):
<dwarf2_per_objfile>: Remove.
* dwarf2/read.c (create_cu_from_index_list): Don't assign
dwarf2_per_objfile.
(create_signatured_type_table_from_index): Likewise.
(create_signatured_type_table_from_debug_names): Likewise.
(create_debug_type_hash_table): Likewise.
(fill_in_sig_entry_from_dwo_entry): Likewise.
(create_type_unit_group): Likewise.
(read_comp_units_from_section): Likewise.
(create_cus_hash_table): Likewise.
Change-Id: Icf0b657a6beec953fe17cbe0fb2ae2c6e744d3ed
|
|
This patch removes the remaining references to that field in obvious
ways (the same object is already available some other way in these
contexts).
gdb/ChangeLog:
* dwarf2/read.c (process_psymtab_comp_unit): Remove reference to
dwarf2_per_cu_data::dwarf2_per_objfile.
(compute_compunit_symtab_includes): Likewise.
(dwarf2_cu::start_symtab): Likewise.
Change-Id: I965700fa793d8457711a2d6ae448aaefd779eb96
|
|
This allows removing some dwarf2_per_cu_data::dwarf2_per_objfile
references.
gdb/ChangeLog:
* dwarf2/read.h (dwarf2_get_die_type): Add dwarf2_per_objfile
parameter.
* dwarf2/read.c (get_die_type_at_offset): Likewise.
(read_namespace_alias): Update.
(lookup_die_type): Update.
(dwarf2_get_die_type): Add dwarf2_per_objfile parameter.
* dwarf2/loc.c (class dwarf_evaluate_loc_desc) <get_base_type>:
Update.
(disassemble_dwarf_expression): Update.
Change-Id: Ibaf5b684cb0a8eb8f0b23e62bd0283c295410aa5
|
|
This allows removing some references to
dwarf2_per_cu_data::dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_queue_item): Add
dwarf2_per_objfile parameter, assign new parameter.
<per_objfile>: New field.
* dwarf2/read.c (free_one_cached_comp_unit): Add
dwarf2_per_objfile parameter.
(queue_comp_unit): Likewise.
(dw2_do_instantiate_symtab): Update.
(process_psymtab_comp_unit): Update.
(maybe_queue_comp_unit): Add dwarf2_per_objfile parameter.
(process_imported_unit_die): Update.
(queue_and_load_dwo_tu): Update.
(follow_die_offset): Update.
(follow_die_sig_1): Update.
Change-Id: Ibb4a4ea28eeac5ebcbf73c0d2a13f9391e15c235
|
|
Since dwarf2_per_cu_data objects are going to become
objfile-independent, the backlink from dwarf2_per_cu_data to one
particular objfile must be removed. Instead, users of
dwarf2_per_cu_data that need an objfile must know from somewhere else in
the context of which objfile they are using this CU.
This also helps remove a dwarf2_per_cu_data::dwarf2_per_objfile
reference (from where the objfile was obtained).
Note that the dwarf2_per_cu_data::objfile method has a special case to
make sure to return the main objfile, if the objfile associated to the
dwarf2_per_cu_data is a separate debug objfile. I don't really know if
this is necessary: I ignored that, and didn't see any regression when
testing with the various Dejagnu boards with separate debug info, so I
presume it wasn't needed. If it turns out this was needed, then we can
have a helper method on the objfile type for that.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <objfile>: Remove.
* dwarf2/read.c (dwarf2_compute_name): Pass per_objfile down.
(read_call_site_scope): Assign per_objfile.
(dwarf2_per_cu_data::objfile): Remove.
* gdbtypes.h (struct call_site) <per_objfile>: New member.
* dwarf2/loc.h (dwarf2_evaluate_loc_desc): Add
dwarf2_per_objfile parameter.
* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Add
dwarf2_per_objfile parameter.
(dwarf_expr_reg_to_entry_parameter): Add output
dwarf2_per_objfile parameter.
(locexpr_get_frame_base): Update.
(class dwarf_evaluate_loc_desc) <get_tls_address>: Update.
<push_dwarf_reg_entry_value>: Update.
<call_site_to_target_addr>: Update.
(dwarf_entry_parameter_to_value): Add dwarf2_per_objfile
parameter.
(value_of_dwarf_reg_entry): Update.
(rw_pieced_value): Update.
(indirect_synthetic_pointer): Update.
(dwarf2_evaluate_property): Update.
(dwarf2_loc_desc_get_symbol_read_needs): Add dwarf2_per_objfile
parameter.
(locexpr_read_variable): Update.
(locexpr_get_symbol_read_needs): Update.
(loclist_read_variable): Update.
Change-Id: Idb40d1a94995af305054d463967bb6ce11a08f25
|
|
This allows removing dwarf2_per_cu_data references.
gdb/ChangeLog:
* dwarf2/read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Add dwarf2_per_objfile
parameter.
* dwarf2/read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off, dwarf2_fetch_constant_bytes,
dwarf2_fetch_die_type_sect_off): Add dwarf2_per_objfile
parameter.
* dwarf2/loc.c (indirect_synthetic_pointer, per_cu_dwarf_call,
sect_variable_value): Add dwarf2_per_objfile parameter.
(class dwarf_evaluate_loc_desc) <dwarf_call,
dwarf_variable_value>: Update.
(fetch_const_value_from_synthetic_pointer): Add
dwarf2_per_objfile parameter.
(fetch_const_value_from_synthetic_pointer): Update.
(coerced_pieced_ref): Update.
(class symbol_needs_eval_context) <dwarf_call,
dwarf_variable_value>: Update.
(dwarf2_compile_expr_to_ax): Update.
Change-Id: I07cf1806380633d0572304cea049a1fa5e9ea67f
|
|
This allows removing a dwarf2_per_cu_data::dwarf2_per_objfile reference.
gdb/ChangeLog:
* dwarf2/loc.c (allocate_piece_closure): Add dwarf2_per_objfile
parameter.
(dwarf2_evaluate_loc_desc_full): Update.
Change-Id: Ic4a694a3fc763360a131ee4e3aaf5a5b4735c813
|
|
Pass it all the way from the symbol batons. This allows removing a
dwarf2_per_cu_data::dwarf2_per_objfile reference.
gdb/ChangeLog:
* dwarf2/read.h (dwarf2_read_addr_index): Add dwarf2_per_objfile
parameter.
* dwarf2/read.c (dwarf2_read_addr_index): Likewise.
* dwarf2/loc.c (decode_debug_loclists_addresses): Add
dwarf2_per_objfile parameter.
(decode_debug_loc_dwo_addresses): Likewise.
(dwarf2_find_location_expression): Update.
(class dwarf_evaluate_loc_desc) <get_addr_index>: Update.
(locexpr_describe_location_piece): Add dwarf2_per_objfile
parameter.
(disassemble_dwarf_expression): Add dwarf2_per_objfile
parameter.
(locexpr_describe_location_1): Likewise.
(locexpr_describe_location): Update.
Change-Id: I8414755e41a87c92f96e408524cc7aaccf086cda
|
|
This method simply returns the text offset of the objfile associated to
the dwarf2_per_cu_data object. Since dwarf2_per_cu_data objects are
going to become objfile-independent, we can't keep this method. This
patch removes it.
Existing callers need to figure out the in the context of which objfile
this is being used, and call text_offset on it. Typically, this comes
from a symbol baton, where we store the corresponding
dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <text_offset>:
Remove.
* dwarf2/read.c (dwarf2_per_cu_data::text_offset): Remove.
* dwarf2/loc.c (dwarf2_find_location_expression): Update.
(dwarf2_compile_property_to_c): Update.
(dwarf2_compile_expr_to_ax): Add dwarf2_per_objfile parameter,
use text offset from objfile.
(locexpr_tracepoint_var_ref): Update.
(locexpr_generate_c_location): Update.
(loclist_describe_location): Update.
(loclist_tracepoint_var_ref): Update.
* dwarf2/compile.h (compile_dwarf_bounds_to_c): Add
dwarf2_per_objfile parameter.
* dwarf2/loc2c.c (do_compile_dwarf_expr_to_c): Likewise,
use text offset from objfile.
(compile_dwarf_expr_to_c): Add dwarf2_per_objfile parameter.
Change-Id: I56b01ba294733362a3562426a96d48ae051a776f
|
