Stanislav Meduna <[email protected]> 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
