[Bug tdep/31278] GDB on arm-linux-gnueabihf fails gdb.reverse/func-map-to-same-line.exp

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

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
I compared with -marm and x86_64, and in both cases we have:
...
$ gdb -q -batch outputs/gdb.reverse/func-map-to-same-line/func-map-to-same-line
-ex start -ex record -ex "break 36" -ex continue -ex "set debug infrun 1" -ex
"reverse-step" 2>&1 | grep process_event_stop_test
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: stepped into subroutine
...
but with -mthumb:
...
  [infrun] process_event_stop_test: stepped into subroutine
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4f2, end
= 0xaaaaa4fc, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: reverse stepping, left a recursive call,
don't update step info so we remember we left a frame
  [infrun] process_event_stop_test: updated step range, start = 0xaaaaa4ee, end
= 0xaaaaa4f2, may_range_step = 1
  [infrun] process_event_stop_test: keep going
  [infrun] process_event_stop_test: stepped to a different line
...

So, the deviation starts when the second call to process_event_stop_test
doesn't detect "stepped into subroutine".

The condition looks like this:
...
  if ((get_stack_frame_id (frame)
       != ecs->event_thread->control.step_stack_frame_id)
      && get_frame_type (frame) != SIGTRAMP_FRAME
      && ((frame_unwind_caller_id (get_current_frame ())
           == ecs->event_thread->control.step_stack_frame_id)
          && ((ecs->event_thread->control.step_stack_frame_id
               != outer_frame_id)
              || (ecs->event_thread->control.step_start_function
                  != find_pc_function (ecs->event_thread->stop_pc ())))))
    {
...
and it fails because these two are not equal:
...
(gdb) p /x frame_unwind_caller_id (get_current_frame ())
$1 = {stack_addr = 0x12, code_addr = 0xaaaaa4fc, special_addr = 0x0,
stack_status = 0x1, code_addr_p = 0x1, 
  special_addr_p = 0x0, user_created_p = 0x0, artificial_depth = 0x0}
(gdb) p /x ecs->event_thread->control.step_stack_frame_id          
$2 = {stack_addr = 0xfffef4d8, code_addr = 0xaaaaa4fc, special_addr = 0x0,
stack_status = 0x1, code_addr_p = 0x1, 
  special_addr_p = 0x0, user_created_p = 0x0, artificial_depth = 0x0}
...
Note the difference in stack_addr.

With this demonstrator patch, limiting the comparison to code_addr, the
test-case passes:
...
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 87965fb1274..600dda6b5c5 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -7816,8 +7816,8 @@ process_event_stop_test (struct execution_control_state
*ecs)
   if ((get_stack_frame_id (frame)
        != ecs->event_thread->control.step_stack_frame_id)
       && get_frame_type (frame) != SIGTRAMP_FRAME
-      && ((frame_unwind_caller_id (get_current_frame ())
-          == ecs->event_thread->control.step_stack_frame_id)
+      && ((frame_unwind_caller_id (get_current_frame ()).code_addr
+          == ecs->event_thread->control.step_stack_frame_id.code_addr)
          && ((ecs->event_thread->control.step_stack_frame_id
               != outer_frame_id)
              || (ecs->event_thread->control.step_start_function
...

So I guess the question is why the frame id has that strange stack_addr.

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