[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 #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> So I guess the question is why the frame id has that strange stack_addr.

I added this debug patch:
...
diff --git a/gdb/dwarf2/frame.c b/gdb/dwarf2/frame.c
index fc6704f434e..1f6a0a17305 100644
--- a/gdb/dwarf2/frame.c
+++ b/gdb/dwarf2/frame.c
@@ -980,6 +980,8 @@ dwarf2_frame_cache (frame_info_ptr this_frame, void
**this_cache)

   try
     {
+      frame_debug_printf ("Calculating CFA ... ");
+
       /* Calculate the CFA.  */
       switch (fs.regs.cfa_how)
        {
@@ -1001,6 +1003,9 @@ dwarf2_frame_cache (frame_info_ptr this_frame, void
**this_cache)
        default:
          internal_error (_("Unknown CFA rule."));
        }
+
+      frame_debug_printf (" ... CFA calculated: %llx", (unsigned long
long)cache->cfa);
+       
     }
   catch (const gdb_exception_error &ex)
     {
...

And then using:
...
$ gdb.sh -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 reverse-stepi \
  -ex "set debug frame 1" \
  -ex reverse-stepi
...
I find:
...
    [frame] frame_unwind_register_value: enter
      [frame] frame_unwind_register_value: frame=0, regnum=7(r7)
      [frame] frame_unwind_register_value:   -> address=0xfffef4d8 lazy
    [frame] frame_unwind_register_value: exit
    [frame] dwarf2_frame_cache:  ... CFA calculated: 12
    [frame] frame_unwind_arch: next_frame=1 -> armv7
    [frame] frame_unwind_register_value: enter
      [frame] frame_unwind_register_value: frame=1, regnum=15(pc)
      [frame] frame_unwind_register_value: enter
        [frame] frame_unwind_register_value: frame=1, regnum=14(lr)
        [frame] frame_unwind_register_value:   -> address=0xe lazy
      [frame] frame_unwind_register_value: exit
    [frame] frame_unwind_register_value: exit
...

So r14 is read from address 0xe, which is caused by an incorrect CFA, of 0x12.

The CFA is calculated based on r7, which is read from to 0xfffef4d8, resulting
in '2'.

When stepping through func2, r7 is actually saved at 0xfffef4d4.

In the .s file we have:
...
        nop
        mov     sp, r7
        .cfi_def_cfa_register 13
        @ sp needed
        ldr     r7, [sp], #4
        .cfi_restore 7
        .cfi_def_cfa_offset 0
        bx      lr
        .cfi_endproc
...

I'm not sure why when stopped at the start of ldr we try to read from 7, though
cfa reg 13 also doesn't sound right for a thumb function.  Regardless, we're
reading r7 from the wrong place.

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