Re: [PATCH] <Overlapping Dwarf Compile Units with non-overlapping subranges gives incorrect line information>

[Tom de Vries <tdevries@suse.de>]

On 03-06-2020 06:18, Mitch Souders wrote:
> Hi Tom,
> 
> Sorry about the overlooked test failure.

Hi,

Np, it happens :)

> I have updated the patch
> (attached) to provide the parent block, rather than one of the block sub
> ranges which fixes the test failure you encountered and matches the test
> behavior of a clean sandbox for the remaining ones. Thanks for taking
> the time to review it.
> 

I wanted to look in detail at the code, but got distracted by other
.debug_line-related issues, and now I got to shift my attention away for
a bit, so a short reaction for now.

I think this requires a dwarf assembly test-case. If you'd like, you can
try to create one (look in gdb.dwarf2/*.exp for examples).  Otherwise, I
can do this, but, as mentioned, a bit later.

Thanks,
- Tom

> On Tue, Jun 2, 2020 at 4:26 AM Tom de Vries <tdevries@suse.de
> <mailto:tdevries@suse.de>> wrote:
> 
>     On 15-05-2020 04:43, Mitch Souders wrote:
>     > RE: GDB Bugz 25980
>     >
>     > CHANGELOG:
>     >
>     > 2020-05-14  Mitch Souders  <mitch@runsafesecurity>
>     >       * symtab.c : Find correct compilation unit for regions with
>     overlapping
>     >       regions that contain non-overlapping subregions.
>     >       
>     > In cases where two compilation units have overlapping ranges (with
>     > non-overlapping subranges), gdb gets a bit confused and reports line
>     > positions from the wrong compilation unit.
>     >
>     > The bugz has an attached out.dwarf as an example testcase.
>     >
>     > main.c has a top-level range of 0x1129-0x1253.
>     > i.c has a top-level range of 0x11e5-0x1273.
>     > Though these two ranges overlap, none of their child subprograms
>     > overlap. This should mean that the line numbers for specific addresses
>     > are unambiguous.
>     >> gdb out.dwarf --batch --ex="set trace-commands on" --command=gdb.cmd
>     >> +symbol-file
>     >> +add-symbol-file -readnow ~/proj/LFR/dwarf/test/out.dwarf
>     >> add symbol table from file
>     "/home/crzysdrs/proj/LFR/dwarf/test/out.dwarf"
>     >> + info line *main
>     >> Line 11 of "i.c" starts at address 0x1210 <f+20> and ends at
>     0x1265 <d>.
>     >> +info line *a
>     >> Line 3 of "main.c" starts at address 0x1129 <a> and ends at
>     0x1131 <a+8>.
>     >> +info line *b
>     >> Line 6 of "main.c" starts at address 0x1157 <b> and ends at
>     0x115f <b+8>.
>     >> +info line *c
>     >> Line 9 of "main.c" starts at address 0x1140 <c> and ends at
>     0x1148 <c+8>.
>     >> +info line *d
>     >> Line 3 of "i.c" starts at address 0x1265 <d> and ends at 0x126d
>     <d+8>.
>     >> +info line *e
>     >> Line 6 of "i.c" starts at address 0x11e5 <e> and ends at 0x11ed
>     <e+8>.
>     >> +info line *f
>     >> Line 9 of "i.c" starts at address 0x11fc <f> and ends at 0x1204
>     <f+8>.
>     > As shown above, the line information is mistakenly found in i.c, when
>     > it should in fact be in main.c.
>     >
>     > (Corrected)> +info line *main
>     >> Line 12 of "main.c" starts at address 0x1213 <main> and ends at
>     0x121b <main+8>.
>     > This appears to be related to mistaken assumption in
>     > symtab.c:find_pc_sect_compunit_symtab where in the absence of a
>     > partial symbol table it tries to find the smallest compilation unit
>     > where the address resides without considering the valid subranges of
>     > the compilation unit. If the compilation unit that matched is the
>     > smallest, all future compilation units containing that address will be
>     > ignored.
>     >
>     > It should also be noted that removing -readnow for adding the symbol
>     > file does correct the output. Additionally lldb and addr2line report
>     > the correct position.> $ addr2line -e out.dwarf 0x1213
>     >> /home/crzysdrs/proj/LFR/dwarf/test/main.c:12
>     > The attached patch searches through valid subranges of a compilation
>     > in order to correctly identify the target subrange, rather than
>     > incorrectly identify the smallest compilation unit with an enclosing
>     > range that may or may not include the targeted subrange. In the event
>     > there are no subranges, the behavior is the same as always.
>     >
> 
>     Hi,
> 
>     I applied this patch and did a testsuite run.  I run into a segv here:
>     ...
>     (gdb) b 24^M
>     ERROR: GDB process no longer exists
>     GDB process exited with wait status 32518 exp9 0 0 CHILDKILLED SIGABRT
>     SIGABRT
>     UNRESOLVED: gdb.base/break-on-linker-gcd-function.exp: readnow: b 24
>     ...
> 
>     Reproduce on command line:
>     ...
>     $ gdb -readnow \
>       gdb.base/break-on-linker-gcd-function/break-on-linker-gcd-function \
>       -ex 'b 24'
>     Reading symbols from break-on-linker-gcd-function...
>     Expanding full symbols from break-on-linker-gcd-function...
>     Aborted (core dumped)
>     ...
> 
>     The problem happens while executing:
>     ...
>     Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
>     0x0000000000709322 in create_sals_line_offset (self=0x7fffffffcf20,
>     ls=0x7fffffffcf70)
>         at /data/gdb_versions/devel/src/gdb/linespec.c:2105
>     2105            = collect_symtabs_from_filename
>     (self->default_symtab->filename,
>     ...
>     with:
>     ...
>     (gdb) p self->default_symtab
>     $1 = (symtab *) 0x0
>     ...
> 
>     Thanks,
>     - Tom
> 
> 
> 
> -- 
> -Mitch