[ECOS] Debugging arm-eabi - no stack frame?

[ECOS] Debugging arm-eabi - no stack frame?

[Stanislav Meduna]

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).

If I understand this correctly, the gdb expects r11 as
the frame pointer. However, this register is null -
no wonder this does not work.

Specifying -mapcs-frame and/or -fno-omit-frame-pointer
does not help.

Is this a known problem?

$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: /gnutools/src/toolchains/gcc/gcc-4.3.2/configure -v
--target=arm-eabi --prefix=/gnutools/builds/toolchains/arm-eabi/tools
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--disable-__cxa_atexit --enable-threads
--with-bugurl=http://bugs.ecos.sourceware.org/
--with-pkgversion='eCosCentric GNU tools 4.3.2-sw'
--with-cpu=arm7tdmi
Thread model: single
gcc version 4.3.2 (eCosCentric GNU tools 4.3.2-sw)

$ arm-eabi-gdb -v
GNU gdb (eCosCentric GNU tools 4.3.2-sw) 6.8.50.20080706
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=arm-eabi".
For bug reporting instructions, please see:
<http://bugs.ecos.sourceware.org/>.


eCos v3.0 Template: Samsung ARM9/SMDK2410 development board

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

Re: [ECOS] Debugging arm-eabi - no stack frame?

[Nick Garnett]

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

Re: [ECOS] Debugging arm-eabi - no stack frame?

[Stanislav Meduna]

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

Re: [ECOS] Debugging arm-eabi - no stack frame?

[Nick Garnett]

Stanislav Meduna <stano@meduna.org> writes:

> 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

Presumably these come from skyeye itself.

> 
> 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.

Returning zero should cause GDB to eventually stop trying. You could
try returning a value that corresponds to a valid address that would
be outside your executable. That might also make GDB behave properly.

> 
> > 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.

In my experience of using the same set of tools, albeit mainly for
Cortex-M, they seem to generate backtraces correctly. So I'm afraid
I'm out of ideas. Perhaps someone else has seen the same problem and
can help.


-- 
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

Re: [ECOS] Debugging arm-eabi - no stack frame?

[Stanislav Meduna]

Nick Garnett wrote:

> In my experience of using the same set of tools, albeit mainly for
> Cortex-M, they seem to generate backtraces correctly. So I'm afraid
> I'm out of ideas. Perhaps someone else has seen the same problem and
> can help.

OK, this was in fact a funny combination of the emulator and
eCos platform setup code not quite agreeing on how the MMU
is set up, resulting in not accessing the correct data
in certain circumstances. After sorting this out the gdb
works as expected.

Sorry for the confusion.
-- 
                                      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