[Bug tdep/32424] New: [gdb/tdep, s390x] FAIL: gdb.rust/finish.exp: print dei

[Bug tdep/32424] New: [gdb/tdep, s390x] FAIL: gdb.rust/finish.exp: print dei

[vries at gcc dot gnu.org]

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

            Bug ID: 32424
           Summary: [gdb/tdep, s390x] FAIL: gdb.rust/finish.exp: print dei
           Product: gdb
           Version: 14.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On s390x-linux, I run into:
...
(gdb) break finish.rs:24^M
Breakpoint 1 at 0x740a: file finish.rs, line 24.^M
(gdb) run ^M
Starting program: finish ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
Breakpoint 1, finish::return_some () at finish.rs:24^M
24          MyResult::Some(97)  // BREAK^M
(gdb) finish^M
Run till exit from #0  finish::return_some () at finish.rs:24^M
^M
Breakpoint 1, finish::return_some () at finish.rs:24^M
24          MyResult::Some(97)  // BREAK^M
(gdb) XFAIL: gdb.rust/finish.exp: finish
next^M
25      }^M
(gdb) PASS: gdb.rust/finish.exp: next
print dei^M
No symbol 'dei' in current context^M
(gdb) FAIL: gdb.rust/finish.exp: print dei
...

The FAIL is caused by an earlier problem: the finish breakpoint didn't trigger.

Consequently we run again into breakpoint 1.

The XFAIL is there for finish returning the wrong result, but that's not the
case here.

The call to finish::return_some is done here:
...
0000000000007430 <_ZN6finish4main17h78158afdd9f1d820E>:
    7430:       eb ef f0 70 00 24       stmg    %r14,%r15,112(%r15)
    7436:       a7 fb ff 50             aghi    %r15,-176
    743a:       c0 e5 ff ff ff e3       brasl   %r14,7400
<_ZN6finish11return_some17h276912a59248052fE>
    7440:       50 20 f0 a0             st      %r2,160(%r15)
...
so the finish breakpoint is set on 7440.

Using "set debug infra on" we get:
...
  [infrun] handle_signal_stop: stop_pc=0x2aa00007440
  [infrun] bpstat_check_breakpoint_conditions: enter
    [infrun] bpstat_check_breakpoint_conditions: thread = 357.357.0, breakpoint
0.1
    [infrun] bpstat_check_breakpoint_conditions: incorrect frame
{stack=0x3ffffffeb78,code=0x000002aa00007430,!special} not
{stack=0x3ffffffead0,code=0x000002aa00007430,!special}, not stopping
  [infrun] bpstat_check_breakpoint_conditions: exit
  [infrun] process_event_stop_test: BPSTAT_WHAT_SINGLE
  [infrun] process_event_stop_test: no stepping, continue
...
so AFAIU the finish breakpoint doesn't trigger because the actual frame id
doesn't match the expected frame id.

I can reproduce this without finish, using "maint print frame-id":
...
$ gdb -q -batch -iex "set trace-commands on" \
    ./outputs/gdb.rust/finish/finish \
    -ex "break 24" \
    -ex run \
    -ex "maint print frame-id" \
    -ex "up" \
    -ex "maint print frame-id" \
    -ex down \
    -ex "n 2" \
    -ex "maint print frame-id" 
+break 24
Breakpoint 1 at 0x740a: file finish.rs, line 24.
+run

Breakpoint 1, finish::return_some () at finish.rs:24
24          MyResult::Some(97)  // BREAK
+maint print frame-id
frame-id for frame #0: {stack=0x3ffffffeac8,code=0x000002aa00007400,!special}
+up
#1  0x000002aa00007440 in finish::main () at finish.rs:28
28          let dei = return_some();
+maint print frame-id
frame-id for frame #1: {stack=0x3ffffffead0,code=0x000002aa00007430,!special}
+down
#0  finish::return_some () at finish.rs:24
24          MyResult::Some(97)  // BREAK
+n 2
finish::main () at finish.rs:29
29          let another = return_some();
+maint print frame-id
frame-id for frame #0: {stack=0x3ffffffeb78,code=0x000002aa00007430,!special}
...

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