[Bug corefiles/27689] New: FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[Bug corefiles/27689] New: FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

            Bug ID: 27689
           Summary: FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: corefiles
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On openSUSE tumbleweed, I see:
...
FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc
FAIL: gdb.base/gcore-tls-pie.exp: unstripped + core ok
...

In more detail:
...
(gdb) file
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/gcore-tls-pie/gcore-tls-pie^M
Reading symbols from
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/gcore-tls-pie/gcore-tls-pie...^M
(gdb) core
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/gcore-tls-pie/gcore-tls-pie.gcore^M
warning: core file may not match specified executable file.^M
[New LWP 7361]^M
Core was generated by
`/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/gcore-tls-pie/gcor'.^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
#0  0x00005555555546dd in ?? ()^M
(gdb) PASS: gdb.base/gcore-tls-pie.exp: re-load generated corefile
x/i $pc^M
=> 0x5555555546dd:      mov    $0x0,%eax^M
(gdb) FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc
...

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> warning: core file may not match specified executable file.^M

I looked into this warning.  It's due to a mismatch in buildid, which is caused
by incorrect reading of the buildid for the core.

We're trying to read the following 3 notes from the core:
...
                      04 00 00 00  10 00 00 00 01 00 00 00  |o.2.............|
00000770  47 4e 55 00 00 00 00 00  03 00 00 00 02 00 00 00  |GNU.............|
00000780  00 00 00 00

                       00 00 00 00

                                   04 00 00 00 20 00 00 00  |............ ...|
00000790  05 00 00 00 47 4e 55 00  02 80 00 c0 04 00 00 00  |....GNU.........|
000007a0  01 00 00 00 00 00 00 00  01 00 01 c0 04 00 00 00  |................|
000007b0  01 00 00 00 00 00 00 00

                                   04 00 00 00 14 00 00 00  |................|
000007c0  03 00 00 00 47 4e 55 00  79 c4 e9 5a c4 c0 5c ce  |....GNU.y..Z..\.|
000007d0  95 e9 38 e2 13 58 41 4e  2e fa 5f c7
...

[ Note format: First word is name size (4 in all cases), second words is data
size (0x10, 0x20 and 0x14), third word is type (1,5,3, see NT_GNU constants in
include/elf/common.h), then there's the name, "GNU\0", followed by the data. ]

First we have a NT_GNU_ABI_TAG note, then a NT_GNU_PROPERTY_TYPE_0 note, then a
NT_GNU_BUILD_ID note.

However, the NT_GNU_PROPERTY_TYPE_0 note has alignment 8:
... 
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  ...
  [16] .note.gnu.property NOTE            0000000000000000 000390 000030 00   A
 0   0  8
...
to it doesn't start immediately after the NT_GNU_ABI_TAG note, instead we have
4 bytes padding (00 00 00 00).

The padding throws off the note reader in bfd, so the last two notes are not
read correctly.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Using this demonstrator patch, the warning is gone:
...
diff --git a/bfd/elf.c b/bfd/elf.c
index 276fa14c0dd..1d6c0d59e17 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -12150,6 +12150,12 @@ elf_parse_notes (bfd *abfd, char *buf, size_t size,
file
_ptr offset,
       Elf_External_Note *xnp = (Elf_External_Note *) p;
       Elf_Internal_Note in;

+      if (xnp->namesz[0] == 0 && xnp->namesz[1] == 0 && xnp->namesz[2] == 0
+         && xnp->namesz[3] == 0)
+       {
+         p += 4;
+         xnp = (Elf_External_Note *) p;
+       }
       if (offsetof (Elf_External_Note, name) > buf - p + size)
        return false;
...

Likely not a fix though, given that the name size is actually allowed to be 0. 

Though the warning is gone, the FAIL is not.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
When running the test-case without -fuse-ld=gold, the NT_GNU_PROPERTY_TYPE_0 is
the first note, which probably allows us to avoid this problem.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> Though the warning is gone, the FAIL is not.

That may be a pie thing, the test passes with nopie.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- 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 #2)
> > Though the warning is gone, the FAIL is not.
> 
> That may be a pie thing, the test passes with nopie.

So, things fail in svr4_exec_displacement when comparing program headers.

After pinpointing the unequal section to a NOTE section,  we can find back a
difference in the unstripped and stripped file (MemSiz 0x74 vs 0x78):
...
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
unstripped:
  NOTE           0x00000000000002c4 0x00000000000002c4 0x00000000000002c4
                 0x0000000000000078 0x0000000000000078  R      0x4
stripped:
  NOTE           0x00000000000002c4 0x00000000000002c4 0x00000000000002c4
                 0x0000000000000078 0x0000000000000074  R      0x4
...

Also, we find that stripping dropped (listing of) .note.gnu.build-id for
segment 6:
...
 Section to Segment mapping:
  Segment Sections...
unstripped:
   05     .note.gnu.property
   06     .note.ABI-tag .note.gnu.property .note.gnu.build-id
stripped:
   05     .note.gnu.property
   06     .note.ABI-tag .note.gnu.property
...

BTW, I'm not sure how usual the overlapping notes layout is, that is, before
stripping we have:
...
  NOTE           0x00000000000002e8 0x00000000000002e8 0x00000000000002e8
                 0x0000000000000030 0x0000000000000030  R      0x8
  NOTE           0x00000000000002c4 0x00000000000002c4 0x00000000000002c4
                 0x0000000000000078 0x0000000000000078  R      0x4
...
The first NOTE is contained in the second (but probably listed separately
because of different alignment), that may be confusing things for strip.

Anyway, using eu-strip instead of strip fixes the issue.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, it looks like strip just calculated the size (0x74) by adding up the sizes
of the notes:
...
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
 ...
  [ 2] .note.ABI-tag     NOTE             00000000000002c4  000002c4
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.pr[...] NOTE             00000000000002e8  000002e8
       0000000000000030  0000000000000000   A       0     0     8
  [ 4] .note.gnu.bu[...] NOTE             0000000000000318  00000318
       0000000000000024  0000000000000000   A       0     0     4
...
that is: 0x20+0x30+0x24, without taking care of the padding between
note.ABI-tag and .note.gnu.property

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Filed binutils PR 27708 - strip mishandles padding between notes.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |27708

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
As for gdb, the patch I was testing was:
...
diff --git a/bfd/elf.c b/bfd/elf.c
index 276fa14c0dd..8f245d59fef 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -12160,6 +12160,13 @@ elf_parse_notes (bfd *abfd, char *buf, size_t size,
file
_ptr offset,
       if (in.namesz > buf - in.namedata + size)
        return false;

+      if (in.namesz == 0)
+       {
+         /* Assume it's padding, try again.  */
+         p += 4;
+         continue;
+       }
+      
       in.descsz = H_GET_32 (abfd, xnp->descsz);
       in.descdata = p + ELF_NOTE_DESC_OFFSET (in.namesz, align);
       in.descpos = offset + (in.descdata - buf);
...

But having verified that the test passes with eu-readelf without this patch,
I'm not sure if it will turn out to be necessary.

So, we'll just have to retest after the strip PR has been fixed.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=27708
[Bug 27708] strip mishandles padding between notes
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> As for gdb, the patch I was testing was:
> ...
> diff --git a/bfd/elf.c b/bfd/elf.c
> index 276fa14c0dd..8f245d59fef 100644
> --- a/bfd/elf.c
> +++ b/bfd/elf.c
> @@ -12160,6 +12160,13 @@ elf_parse_notes (bfd *abfd, char *buf, size_t size,
> file
> _ptr offset,
>        if (in.namesz > buf - in.namedata + size)
>         return false;
>  
> +      if (in.namesz == 0)
> +       {
> +         /* Assume it's padding, try again.  */
> +         p += 4;
> +         continue;
> +       }
> +      
>        in.descsz = H_GET_32 (abfd, xnp->descsz);
>        in.descdata = p + ELF_NOTE_DESC_OFFSET (in.namesz, align);
>        in.descpos = offset + (in.descdata - buf);
> ...
> 
> But having verified that the test passes with eu-readelf without this patch,
> I'm not sure if it will turn out to be necessary.
> 
> So, we'll just have to retest after the strip PR has been fixed.

Though still the patch might be worth submitting.

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

[Bug corefiles/27689] FAIL: gdb.base/gcore-tls-pie.exp: x/i $pc

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27689
Bug 27689 depends on bug 27708, which changed state.

Bug 27708 Summary: strip mishandles padding between notes
https://sourceware.org/bugzilla/show_bug.cgi?id=27708

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

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