[Bug gdb/17384] android arm gdb "Cannot access memory at address" when I "stepi" over "blx"

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #16 from Pedro Alves <palves at redhat dot com> ---
> Further, in my particular case I'm stepping inside 
> blink::RenderFullScreen::createPlaceholder() which is located in 
> libblink_web.cr.so and "info sharedlibrary" confirms that I do have debug 
> symbols loaded for this .so file. I guess this might be because of the "stack 
> frame detection heuristics" you mentioned?
> What can I do to debug that part further?

Let me try to clear terminology a bit.

GDB has several unwinders installed.  If there's debug/unwind/dwarf info, we'll
pick that one, and that should fully describe how to unwind correctly at each
instruction's address.  If GDB can't unwind correctly with dwarf info
available, then either we have a bug in the dwarf unwinder, or the debug/unwind
info is incomplete or incorrect (which is more often correct, though reader
bugs do happen).  The "heuristics" part kicks in when no debug/unwind info is
available.  GDB then has to fall back to parsing the function prologue's
instructions, looking for something that looks like a new frame being set up,
and tries to figure out where in memory that starts, and where in the stack has
each register been saved, etc.  It'll break down if the compiler did something
too clever.  This is the part that is heuristic, as it's impossible to handle
all possible input.

Because we saw this:

#7  0x000000000041122a in arm_scan_prologue (cache=0x1e51ec0,
this_frame=0x1e51e00) at arm-tdep.c:1996
#8  arm_make_prologue_cache (this_frame=0x1e51e00) at arm-tdep.c:2022
#9  0x000000000041142a in arm_prologue_this_id (this_frame=0x1e51e00,
this_cache=0x1e51e18, this_id=0x1e51e60) at arm-tdep.c:2052
#10 0x00000000005e4ea4 in compute_frame_id (fi=0x1e51e00) at frame.c:459
#11 get_prev_frame_if_no_cycle (this_frame=this_frame@entry=0x1e51470) at
frame.c:1781
#12 0x00000000005e72ca in get_prev_frame_always_1 (this_frame=0x1e51470) at
frame.c:1955

that is, you're reaching arm_scan_prologue, we can tell that GDB fell back to
the ARM's heuristic unwinder.  arm_analyze_prologue, its callee, is where the
the prologue parsing and finding out of where registers have been saved is. 
But in order for that to be reached, GDB needs to at least know where the
function starts/ends.  And it doesn not.  We can tell, because you're reaching
this part:

  else
    {
      /* We have no symbol information.  Our only option is to assume this
     function has a standard stack frame and the normal frame register.
     Then, we can find the value of our frame pointer on entrance to
     the callee (or at the present moment if this is the innermost frame).
     The value stored there should be the address of the stmfd + 8.  */
      CORE_ADDR frame_loc;
      LONGEST return_value;

      frame_loc = get_frame_register_unsigned (this_frame, ARM_FP_REGNUM);
      if (!safe_read_memory_integer (frame_loc, 4, byte_order, &return_value))
        return;  <<<<<<<<<<<<<<<<<<<
      else
        {
          prologue_start = gdbarch_addr_bits_remove
                 (gdbarch, return_value) - 8;
          prologue_end = prologue_start + 64;    /* See above.  */
        }
    }

and hitting that early return, which means that GDB thinks you have _no_ symbol
information whatsoever for that address, not even minimal elf info, and then
the function doesn't appear to have been built with a frame pointer
(-fomit-frame-pointer), as the frame pointer points at 1.

We also know that GDB believes you don't have debug info for that function by
another mechanism -- "next" complains about it (the "Cannot find bounds of
current function" error).

So it all indicates GDB doesn't believe you have any debug info for that
address.  Is libblink_web.cr.so fully stripped?

What does "info symbol $pc" say in the problem case?

In order to see the unwinder selection process, you can set a breakpoint at
frame_unwind_try_unwinder, and see GDB trying the dwarf2 unwinder first, and
check why that unwinder refuses the frame.  There's also "set debug frame", but
unfortunately that doesn't show anything about the unwinder selection process. 
But that seems irrelevant, as we can tell from other means that you have no
debug info for that function.

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