[Bug tdep/31071] New: [gdb/tdep, arm] FAIL: gdb.base/catch-syscall.exp: execve: syscall execve has returned

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

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

            Bug ID: 31071
           Summary: [gdb/tdep, arm] FAIL: gdb.base/catch-syscall.exp:
                    execve: syscall execve has returned
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On a pinebook (aarch64 linux kernel, 32-bit user land) I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: execve: syscall(s) execve appears in
'info breakpoints'
continue^M
Continuing.^M
^M
Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from
/lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve
continue^M
Continuing.^M
process 32392 is executing new program:
/home/rock/gdb/build/gdb/testsuite/outputs/gdb.base/catch-syscall/catch-syscall^M
Cannot access memory at address 0xf77c6a7c^M
(gdb) FAIL: gdb.base/catch-syscall.exp: execve: syscall execve has returned
...

The memory error is thrown by arm_linux_get_syscall_number, when doing:
...
     /* PC gets incremented before the syscall-stop, so read the                
         previous instruction.  */
      unsigned long this_instr =
        read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
...

The reason is that we're stopped at the syscall exit of syscall execve, and the
pc is at the first insn of the new exec, which also happens to be the first
insn in the code segment, so consequently we cannot read the previous insn.

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