This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Debugging arm-eabi - no stack frame?
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Stanislav Meduna <stano at meduna dot org>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: 28 May 2009 10:04:27 +0100
- Subject: Re: [ECOS] Debugging arm-eabi - no stack frame?
- References: <4A1E4CEC.8000407@meduna.org>
Stanislav Meduna <stano@meduna.org> writes:
> Hi,
>
> I am trying to debug an ARM9 code compiled using arm-eabi-*
> compilers installed with ecos 3.0 release. The code is
> running in a skyeye emulator and is using its gdbserver.
> As I don't have the real hardware, I am not able to test
> how the internal eCos gdb support works - anyway,
> I'd like to be able to debug the eCos kernel itself.
>
> I am unable to do any backtraces (the emulator barfs
> at trying to access adresses 0xfffffffc - f).
Exactly how does it barf?
GDB has a somewhat nasty heuristic to try and do backtraces in the
presence of compiler optimization. To do this it may access memory by
treating values it finds on the stack and in registers as
pointers. Sometimes these will point at invalid locations.
When debugging via RedBoot there are mechanisms to prevent it making
these accesses if they can cause problems. RedBoot can also catch
memory access execptions and generate a proper response. Perhaps
skyeye's gdbserver has similar mechanisms.
Alternatively, look at the GDB mem command, which may allow you to
prevent GDB accessing particular memory ranges.
--
Nick Garnett eCos Kernel Architect
eCosCentric Limited http://www.eCosCentric.com The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No: 4422071
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss