public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
@ 2020-11-24  1:07 vries at gcc dot gnu.org
  2020-11-24  9:57 ` [Bug mi/26935] " vries at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2020-11-24  1:07 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

            Bug ID: 26935
           Summary: [gdb/testsuite] Using gold in gdb.base/morestack.exp
                    causes incorrect debug info
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mi
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case morestack.exp, compiled with target board
unix/-m32/-fPIE/-pie.

When running the test-case, it passes, but there are warnings, as mentioned in
PR26933.

The executable debug info contains the following info:
...
CU: ../../../../libgcc/config/i386/morestack.S:
File name    Line number       Starting address    View    Stmt
morestack.S  109               0xd0c               x
morestack.S  113               0xd0d               x
  ...
morestack.S  830               0xe66               x
morestack.S  831               0xe6a               x
morestack.S  832               0xe6e               x
morestack.S  838               0xe73               x
morestack.S  -                 0xe74               x

morestack.S  636                   0               x
morestack.S  637                 0x3               x
morestack.S  -                   0x4               x
...

Note that at 0xdc, we find:
...
00000d0c <__morestack_non_split>:
     d0c:       50                      push   %eax
...
but at address 0, there's no text section.

Looking at morestack.o, we see two relocations for .debug_line:
...
Relocation section '.rel.debug_line' at offset 0x8f4 contains 2 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name
0000004e  00000101 R_386_32               00000000   .text
000000de  00000501 R_386_32               00000000  
.text.__x86.get_pc_thunk.bx
...

The first one to be applied here:
...
 Line Number Statements:
  [0x0000004b]  Extended opcode 2: set Address to 0x0
...
referring to:
...
Disassembly of section .text:

00000000 <__morestack_non_split>:
...

And the second one to be applied here:
...
  [0x000000db]  Extended opcode 2: set Address to 0x0
...
referring to:
...
Disassembly of section .text.__x86.get_pc_thunk.bx:

00000000 <__x86.get_pc_thunk.bx>:
...

In the executable we have correctly applied the first:
...
 Line Number Statements:
  [0x0000013b]  Extended opcode 2: set Address to 0xd0c
...
but not the second, it's still stuck at address 0:
...
  [0x000001ca]  Extended opcode 2: set Address to 0x0
...

The executable is build with gold.  If we use ld.bfd instead (and remove the
printf, which requires gold, from the test-case), the test-case also passes and
the warnings are gone.

However, the debug info problem described above is still there with ld.bfd.

With ld.bfd though, we have correct ranges:
...
    00000028 ffffffff 00000000 (base address)
    00000028 00000c9c 00000e04
    00000028 000009a0 000009a4
    00000028 <End of list>
...
while with gold we have the incorrect:
...
    00000028 ffffffff 00000000 (base address)
    00000028 00000d0c 00000e74
    00000028 00000000 00000004
    00000028 <End of list>
...
Likewise for .debug_aranges.

This is probably the cause for difference in behaviour between using ld.gold vs
ld.bfd.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug mi/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
@ 2020-11-24  9:57 ` vries at gcc dot gnu.org
  2020-11-24 10:36 ` vries at gcc dot gnu.org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2020-11-24  9:57 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Corresponding gold and ld PRs filed at:
- PR26936 - [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx
- PR26937 - [gold, PIE] ld drops relocations for .text.__x86.get_pc_thunk.bx

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug mi/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
  2020-11-24  9:57 ` [Bug mi/26935] " vries at gcc dot gnu.org
@ 2020-11-24 10:36 ` vries at gcc dot gnu.org
  2020-11-24 12:32 ` vries at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2020-11-24 10:36 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
As for the gdb testsuite, we could stop using gold for the test-case, since
that gives us better debug info, and gets rid of the warning(s).

As for gdb itself, the following looks interesting.

With gold, we have:
...
linetable: ((struct linetable *) 0x25732b0):
INDEX  LINE   ADDRESS            IS-STMT
0      636    0x56555000         Y
1      637    0x56555003         Y
2      END    0x56555004         Y
3      109    0x56555bbb         Y
...

But with ld, we have:
...
linetable: ((struct linetable *) 0x2f18420):
INDEX  LINE   ADDRESS            IS-STMT
0      END    0x56555004         Y
1      109    0x56555b8b         Y
...
If we're dropping lines 636 and 637 because the addresses are out of range, I'd
say it makes sense to drop the corresponding END as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug mi/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
  2020-11-24  9:57 ` [Bug mi/26935] " vries at gcc dot gnu.org
  2020-11-24 10:36 ` vries at gcc dot gnu.org
@ 2020-11-24 12:32 ` vries at gcc dot gnu.org
  2020-11-24 13:36 ` vries at gcc dot gnu.org
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2020-11-24 12:32 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> But with ld, we have:
> ...
> linetable: ((struct linetable *) 0x2f18420):
> INDEX  LINE   ADDRESS            IS-STMT
> 0      END    0x56555004         Y
> 1      109    0x56555b8b         Y
> ...
> If we're dropping lines 636 and 637 because the addresses are out of range,
> I'd say it makes sense to drop the corresponding END as well.

This seems to work:
...
diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 9525962d966..f2560dd7fe7 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -714,6 +714,14 @@ buildsym_compunit::record_line (struct subfile *subfile,
int line
,
            break;
          subfile->line_vector->nitems--;
        }
+
+      /* Ignore an end-of-sequence marker marking an empty sequence.  */
+      struct linetable_entry *last
+       = (subfile->line_vector->nitems == 0
+          ? nullptr
+          : &subfile->line_vector->item[subfile->line_vector->nitems - 1]);
+      if (last == nullptr || last->line == 0)
+       return;
     }

   e = subfile->line_vector->item + subfile->line_vector->nitems++;
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug mi/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2020-11-24 12:32 ` vries at gcc dot gnu.org
@ 2020-11-24 13:36 ` vries at gcc dot gnu.org
  2021-01-04 14:01 ` [Bug win32/26935] " vries at gcc dot gnu.org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2020-11-24 13:36 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> (In reply to Tom de Vries from comment #2)
> > But with ld, we have:
> > ...
> > linetable: ((struct linetable *) 0x2f18420):
> > INDEX  LINE   ADDRESS            IS-STMT
> > 0      END    0x56555004         Y
> > 1      109    0x56555b8b         Y
> > ...
> > If we're dropping lines 636 and 637 because the addresses are out of range,
> > I'd say it makes sense to drop the corresponding END as well.
> 
> This seems to work:
> ...
> diff --git a/gdb/buildsym.c b/gdb/buildsym.c
> index 9525962d966..f2560dd7fe7 100644
> --- a/gdb/buildsym.c
> +++ b/gdb/buildsym.c
> @@ -714,6 +714,14 @@ buildsym_compunit::record_line (struct subfile
> *subfile, int line
> ,
>             break;
>           subfile->line_vector->nitems--;
>         }
> +
> +      /* Ignore an end-of-sequence marker marking an empty sequence.  */
> +      struct linetable_entry *last
> +       = (subfile->line_vector->nitems == 0
> +          ? nullptr
> +          : &subfile->line_vector->item[subfile->line_vector->nitems - 1]);
> +      if (last == nullptr || last->line == 0)
> +       return;
>      }
>  
>    e = subfile->line_vector->item + subfile->line_vector->nitems++;
> ...

Patch survives testsuite run.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug win32/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2020-11-24 13:36 ` vries at gcc dot gnu.org
@ 2021-01-04 14:01 ` vries at gcc dot gnu.org
  2021-01-04 14:02 ` vries at gcc dot gnu.org
  2021-01-07  8:42 ` [Bug external/26935] " vries at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2021-01-04 14:01 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|mi                          |win32

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #3)
> > (In reply to Tom de Vries from comment #2)
> > > But with ld, we have:
> > > ...
> > > linetable: ((struct linetable *) 0x2f18420):
> > > INDEX  LINE   ADDRESS            IS-STMT
> > > 0      END    0x56555004         Y
> > > 1      109    0x56555b8b         Y
> > > ...
> > > If we're dropping lines 636 and 637 because the addresses are out of range,
> > > I'd say it makes sense to drop the corresponding END as well.
> > 
> > This seems to work:
> > ...
> > diff --git a/gdb/buildsym.c b/gdb/buildsym.c
> > index 9525962d966..f2560dd7fe7 100644
> > --- a/gdb/buildsym.c
> > +++ b/gdb/buildsym.c
> > @@ -714,6 +714,14 @@ buildsym_compunit::record_line (struct subfile
> > *subfile, int line
> > ,
> >             break;
> >           subfile->line_vector->nitems--;
> >         }
> > +
> > +      /* Ignore an end-of-sequence marker marking an empty sequence.  */
> > +      struct linetable_entry *last
> > +       = (subfile->line_vector->nitems == 0
> > +          ? nullptr
> > +          : &subfile->line_vector->item[subfile->line_vector->nitems - 1]);
> > +      if (last == nullptr || last->line == 0)
> > +       return;
> >      }
> >  
> >    e = subfile->line_vector->item + subfile->line_vector->nitems++;
> > ...
> 
> Patch survives testsuite run.

Submitted:
https://sourceware.org/pipermail/gdb-patches/2021-January/174668.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug win32/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2021-01-04 14:01 ` [Bug win32/26935] " vries at gcc dot gnu.org
@ 2021-01-04 14:02 ` vries at gcc dot gnu.org
  2021-01-07  8:42 ` [Bug external/26935] " vries at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2021-01-04 14:02 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> As for the gdb testsuite, we could stop using gold for the test-case, since
> that gives us better debug info, and gets rid of the warning(s).

https://sourceware.org/pipermail/gdb-patches/2021-January/174667.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug external/26935] [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info
  2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2021-01-04 14:02 ` vries at gcc dot gnu.org
@ 2021-01-07  8:42 ` vries at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: vries at gcc dot gnu.org @ 2021-01-07  8:42 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=26935

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
          Component|win32                       |external
             Status|NEW                         |RESOLVED

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
The originally filed problem has been filed as PRs for ld and gold.

Marking this resolved-moved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-01-07  8:42 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-24  1:07 [Bug mi/26935] New: [gdb/testsuite] Using gold in gdb.base/morestack.exp causes incorrect debug info vries at gcc dot gnu.org
2020-11-24  9:57 ` [Bug mi/26935] " vries at gcc dot gnu.org
2020-11-24 10:36 ` vries at gcc dot gnu.org
2020-11-24 12:32 ` vries at gcc dot gnu.org
2020-11-24 13:36 ` vries at gcc dot gnu.org
2021-01-04 14:01 ` [Bug win32/26935] " vries at gcc dot gnu.org
2021-01-04 14:02 ` vries at gcc dot gnu.org
2021-01-07  8:42 ` [Bug external/26935] " vries at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).