This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC, PATCH] gdb/arm-tdep.c: Add sanity check on fp before trying to, access memory.
- From: Will Newton <will dot newton at linaro dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, Patch Tracking <patches at linaro dot org>
- Date: Mon, 27 May 2013 14:07:31 +0100
- Subject: Re: [RFC, PATCH] gdb/arm-tdep.c: Add sanity check on fp before trying to, access memory.
- References: <5195EE16 dot 9020700 at linaro dot org> <CANu=DmgS1nQqQbT5uGLHE2C7sjs-WXxEitFXHHxWWuJgfDFi5w at mail dot gmail dot com> <20130527094652 dot GA5751 at adacore dot com>
On 27 May 2013 10:46, Joel Brobecker <brobecker@adacore.com> wrote:
Hi Joel,
>> I'm not sure if this is the right approach to the problem, but if
>> anyone has any better ideas I would be interested.
>
> As you said, I suspect that this is not the right place for fixing
> the problem. I think something wrong happened, and my first instinct
> is that this should be caught earlier.
>
> We'd need more info as to why you get there...
The call stack to get here is:
#2 0x001c69c2 in read_memory_unsigned_integer (memaddr=936, len=4,
byte_order=BFD_ENDIAN_LITTLE) at /root/gdb-7.5/gdb/corefile.c:312
#3 0x0004c3ea in arm_analyze_prologue (gdbarch=0x4c5690,
prologue_start=936, prologue_end=1000, cache=0x4c9950) at
/root/gdb-7.5/gdb/arm-tdep.c:1695
#4 0x0004cf1e in arm_scan_prologue (this_frame=0x3f9cf0,
cache=0x4c9950) at /root/gdb-7.5/gdb/arm-tdep.c:1998
#5 0x0004cf4c in arm_make_prologue_cache (this_frame=0x3f9cf0) at
/root/gdb-7.5/gdb/arm-tdep.c:2011
#6 0x0004cffe in arm_prologue_this_id (this_frame=0x3f9cf0,
this_cache=0x3f9cfc, this_id=0x3f9d20) at
/root/gdb-7.5/gdb/arm-tdep.c:2041
#7 0x0021ee44 in get_frame_id (fi=0x3f9cf0) at /root/gdb-7.5/gdb/frame.c:338
#8 0x00108c80 in value_of_register (regnum=15, frame=0x3f9cf0) at
/root/gdb-7.5/gdb/findvar.c:298
There are no symbols available (this is the KVM stub) so
find_pc_partial_function fails, which drops us into the else in
arm_scan_prologue. At which point the code tries to unwind using the
frame pointer. However there is no guarantee that the frame pointer is
valid here as far as I can tell - in the case I have seen it is 0, but
it could be any value.
The worst case is the frame pointer is not valid and we get an error
printed. This is not the end of the world, but seems a bit excessive
when all we tried to do was "print $pc".
--
Will Newton
Toolchain Working Group, Linaro