Re: frame theory, was pointer madness

[Accounts <accounts at sakuraindustries dot com>]

Daniel Jacobowitz wrote:

>He's connecting to basically a standard gdbserver, poised at
>the first instruction of the program.  Memory has garbage
>and/or is invalid - no MMU so reading from garbage memory
>is a bit more serious than is typical for GDB.
>
>The best thing here would be, if the stub can find out from
>the kernel what constitutes "valid" RAM, to refuse reads to
>it.  Then ignore the ugliness when you type backtrace and
>don't have a stack yet - it's not real surprising that doesn't
>work!
>
>  
>
This sort of issue can be a BIG problem for embedded targets (it has
been for every embedded target ive used ARM and PowerPC/MPC8XX).

Ive talked about it before in previous posts.  Its worse when you use a
hardware interface for your "Stub" like a JTAG pod, BDM, or the like,
because then there is no Kernel to tell you if you have valid memory or
not (The kernel hasnt run yet).  There are also times on embedded
devices when the nominal stack pointer register isnt a stack pointer
register at all (for example immediately after reset of a cpu, before
the boot code has had a chance to set up the system), and dereferences
of it are "Bad News", can cause corruption of the target under the
certain circumstances and generally make embedded systems development
hell (at that level).

On Thu, Jan 26, 2006 at 11:40:07PM +0100, Mark Kettenis wrote:

>To me, it looks like you're connecting to a buggy stub.
>  
>
I dont think its fair to say these things are "Buggy Stubs" just because
GDB lately has the view there is ALWAYS a stack, which just isnt
correct. Also, the stubs probably pre-date GDB's new frame unwinding
code, so really its GDB that has changed in an incompatible way with
previously working stubs. Having to work around this in a stub is a real
pain.  The issue is the stub cant determine whats a memory access
command the user wants to do, and what is an automatic GDB generated
memory access, as it does a frame unwind.  So there is no nice way to
make a stub say "No Stack memory yet" even if it knew it.

Ive often thought GDB should have a "No ABI" option that completely
prevents any stack/frame unwinding operations from working, so these
sorts of problems go away when there is no ABI, and then when the user
knows the target is properly set up, the user can re-enable the targets
ABI, which allows these stack memory accesses to occur.  Ive even looked
at how it could be done, but it seems a very complicated thing, and i
could never quite work out a way to achieve it. (Due to a complete lack
of understanding of the frame code).

Also, for the record, my experience is GDB does this stuff even if you
dont execute a backtrace, it is done automatically when the stub
connects.  Its like it is unwinding the frame to set up a cache or
something.

Steven Johnson