This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Debugging arm-eabi - no stack frame?
Nick Garnett wrote:
>> I am unable to do any backtraces (the emulator barfs
>> at trying to access adresses 0xfffffffc - f).
>
> Exactly how does it barf?
Bus read error, can not find corresponding bank for addr 0xfffffffc,pc=0x80000dfc
Bus read error, can not find corresponding bank for addr 0xfffffffd,pc=0x80000dfc
Bus read error, can not find corresponding bank for addr 0xfffffffe,pc=0x80000dfc
Bus read error, can not find corresponding bank for addr 0xffffffff,pc=0x80000dfc
I tried to alter values returned by the emulator for invalid memory,
this did not help.
The access itself is not a problem, the emulator informs
me of it, but does not generate any exception or such, it simply
returns something.
> 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.
OK, this is certainly a possibility. However, its heuristics
seems to fail:
(gdb) where
#0 test1 () at nxttests.cxx:34
#1 0x00000000 in ?? ()
i.e. it does not even know that the test1() was called from main()
The #1 address varies according to what the "invalid" access returns.
There is no -O in my compilation flags.
> 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.
Thanks for the hint, I'll investigate.
Thanks
--
Stano
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss