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

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

[Mitch Souders]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

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.

-- 
-Mitch

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1970 bytes --]

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 4f948d57a0..43110dfdfb 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2020-05-14  Mitch Souders  <mitch@runsafesecurity>
+	* symtab.c : Find correct compilation unit for regions with overlapping regions
+	that contain non-overlapping subregions.
+	
 2020-05-13  Tom Tromey  <tromey@adacore.com>
 
 	* ada-lang.c (align_value): Remove.
diff --git a/gdb/symtab.c b/gdb/symtab.c
index b765a583c4..4bbfcd66e2 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -2933,15 +2933,39 @@ find_pc_sect_compunit_symtab (CORE_ADDR pc, struct obj_section *section)
 	{
 	  const struct block *b;
 	  const struct blockvector *bv;
-
+	  const struct block *best_block = NULL;
 	  bv = COMPUNIT_BLOCKVECTOR (cust);
 	  b = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
-
+	  
 	  if (BLOCK_START (b) <= pc
-	      && BLOCK_END (b) > pc
-	      && (distance == 0
-		  || BLOCK_END (b) - BLOCK_START (b) < distance))
+	      && BLOCK_END (b) > pc)
+	    {
+	      int block_start = GLOBAL_BLOCK;
+	      /* skip global region when sub-regions exist, when block_start is zero,
+		 it's effectively the old behavior.
+	      */
+	      if (BLOCKVECTOR_NBLOCKS(bv) > 1)
+		{
+		  block_start++;
+		}
+	      /* in the event that non-contiguous regions cause overlaps with other regions,
+		 we need to check within the subregions which are valid */
+	      for (int block_id = block_start; block_id < BLOCKVECTOR_NBLOCKS(bv); block_id++)
+	        {
+		  b = BLOCKVECTOR_BLOCK (bv, block_id);
+		  if (BLOCK_START (b) <= pc
+		      && BLOCK_END (b) > pc
+		      && (distance == 0
+			  || BLOCK_END (b) - BLOCK_START (b) < distance))
+		    {
+		      best_block = b;
+		      break;
+		    }
+		}
+	    }
+	  if (best_block)
 	    {
+	      b = best_block;
 	      /* For an objfile that has its functions reordered,
 		 find_pc_psymtab will find the proper partial symbol table
 		 and we simply return its corresponding symtab.  */

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

[Mitch Souders]

On Thu, May 14, 2020 at 7:43 PM Mitch Souders <mitch@runsafesecurity.com>
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.
>
> --
> -Mitch
>


-- 
-Mitch

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

[Tom de Vries]

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

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

[Mitch Souders]

[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]

Hi Tom,

Sorry about the overlooked test failure. 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.

On Tue, Jun 2, 2020 at 4:26 AM Tom de Vries <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

[-- Attachment #2: updated_patch --]
[-- Type: application/octet-stream, Size: 2232 bytes --]

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 393651799e..6bdba44de5 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+=======
+2020-06-02  Mitch Souders  <mitch@runsafesecurity.com>
+	* symtab.c : Find correct compilation unit for regions with overlapping regions
+	that contain non-overlapping subregions.
+	
 2020-06-02  Andrew Burgess  <andrew.burgess@embecosm.com>
 
 	* ada-lang.c (ada_language_data): Delete skip_trampoline
@@ -1988,6 +1993,7 @@
 	instead of 'regcache_read_pc'.
 	(keep_going_pass_signal): Ditto.
 
+
 2020-05-13  Tom Tromey  <tromey@adacore.com>
 
 	* ada-lang.c (align_value): Remove.
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 791ce11a73..1e47911fcb 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -2917,15 +2917,39 @@ find_pc_sect_compunit_symtab (CORE_ADDR pc, struct obj_section *section)
 	{
 	  const struct block *b;
 	  const struct blockvector *bv;
-
+	  const struct block *best_block = NULL;
 	  bv = COMPUNIT_BLOCKVECTOR (cust);
 	  b = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
-
+	  
 	  if (BLOCK_START (b) <= pc
-	      && BLOCK_END (b) > pc
-	      && (distance == 0
-		  || BLOCK_END (b) - BLOCK_START (b) < distance))
+	      && BLOCK_END (b) > pc)
+	    {
+	      int block_start = GLOBAL_BLOCK;
+	      /* skip global region when sub-regions exist, when block_start is zero,
+		 it's effectively the old behavior.
+	      */
+	      if (BLOCKVECTOR_NBLOCKS(bv) > 1)
+		{
+		  block_start++;
+		}
+	      /* in the event that non-contiguous regions cause overlaps with other regions,
+		 we need to check within the subregions which are valid */
+	      for (int block_id = block_start; block_id < BLOCKVECTOR_NBLOCKS(bv); block_id++)
+	        {
+		  b = BLOCKVECTOR_BLOCK (bv, block_id);
+		  if (BLOCK_START (b) <= pc
+		      && BLOCK_END (b) > pc
+		      && (distance == 0
+			  || BLOCK_END (b) - BLOCK_START (b) < distance))
+		    {
+		      best_block = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
+		      break;
+		    }
+		}
+	    }
+	  if (best_block)
 	    {
+	      b = best_block;
 	      /* For an objfile that has its functions reordered,
 		 find_pc_psymtab will find the proper partial symbol table
 		 and we simply return its corresponding symtab.  */

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

[Tom de Vries]

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

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

[Tom de Vries]

On 6/8/20 6:04 PM, Tom de Vries wrote:
> 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.

Hi,

sorry for taking so long to get back on this.

I ran into a similar problem (PR26772), where this patch did non help.

I then committed a patch for that PR, which also fixed this problem
(PR25980).

So, atm I don't see a need to apply this patch.

Thanks,
- Tom