[Bug symtab/29318] New: [gdb] FAIL: gdb.base/gcore-relro-pie.exp: x/i $pc

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

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

On a rather specific setup (SLE 15 SP4 with binutils from the development
package in OBS), I ran into:
...
FAIL: gdb.base/gcore-relro-pie.exp: x/i $pc
FAIL: gdb.base/gcore-relro-pie.exp: unstripped + core ok
...

More specifically:
...
(gdb) x/i $pc^M
=> 0x55555555466e:      mov    $0x0,%eax^M
(gdb) FAIL: gdb.base/gcore-relro-pie.exp: x/i $pc
frame^M
#0  0x000055555555466e in ?? ()^M
(gdb) FAIL: gdb.base/gcore-relro-pie.exp: unstripped + core ok
...

I managed to reproduce the same without the "ldflags=-Wl,-z,relro" in the
test-case, so it doesn't seem to be specific to that setting.

After some debugging, I found that with "set verbose on", and a passing setup I
have:
...
Using PIE (Position Independent Executable) displacement 0x555555554000 for
"/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/gcore-relro-pie/gcore-relro-pie".
...
but this is missing, so we're failing in svr4_exec_displacement.

That seems to be caused by this alignment mismatch introduced by strip:
...
$ readelf -l -W  gcore-relro-pie | grep GNU_ST
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW  0x10
$ readelf -l -W  gcore-relro-pie.stripped | grep GNU_ST
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW  0x8
...

I have not been able to reproduce this outside the specific setup, so the strip
problem may be specific to the package.

Anyway, so we're failing to match core file with unstripped file due to this
difference, and we've already matched buildid, confirming the match.

So, we may be too eager to mismatch.  We could just match based on the buildid,
and produce warnings about unexpected mismatches like the one mentioned above.

A similar idea was mentioned earlier at PR21126.

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