[Bug testsuite/30633] New: [gdb/testsuite, native-gdbserver] FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main

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

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

            Bug ID: 30633
           Summary: [gdb/testsuite, native-gdbserver] FAIL:
                    gdb.dwarf2/typeddwarf.exp: runto: run to main
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On ubuntu 22.04.2 I run into:
...
make check RUNTESTFLAGS="--target_board=native-gdbserver/
gdb.dwarf2/typeddwarf.exp"
   ...
FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
...

In more detail:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000000001 in ?? ()^M
(gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
...

Previously reported here:
https://sourceware.org/pipermail/gdb-patches/2023-July/200591.html .

It's a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie in a few
test-cases").

Without nopie we have:
...
$ file outputs/gdb.dwarf2/typeddwarf/typeddwarf
outputs/gdb.dwarf2/typeddwarf/typeddwarf: ELF 64-bit LSB pie executable,
x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=1f4dde6f634075d45b39826931f143ae350f45ea, with debug_info, not
stripped
...

With nopie we have:
...
outputs/gdb.dwarf2/typeddwarf/typeddwarf: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), statically linked,
BuildID[sha1]=f99a83c0cb6e5ce8281978bd9e69b05c559fee81, with debug_info, not
stripped
...

Using this information, I can also reproduce the FAIL on openSUSE Leap 15.4, by
adding -static.

We run into the FAIL as follows:
- due to using gdbserver, we attach at the point of the first instruction, in
  _start
- we then set a breakpoint at main
- the test-case is a .s file, that has main renamed to _start in the assembly,
  but not in the debuginfo.
- setting a breakpoint at main sets the breakpoint at the same instruction
  we're currently stopped at (for the amd64 case.  For the i386 case, the
  breakpoint is set one instruction after that).
- continue doesn't hit the breakpoint, and we return out of _start, which
  causes a sigsegv

Without nopie, the executable is not static, and consequently we attach at
_start in the dynamic linker, which means that continue will hit the breakpoint
in main.

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