This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB and ARM Frame Pointer strangeness
- From: Daniel Jacobowitz <drow at false dot org>
- To: Steven Johnson <sjohnson at neurizon dot net>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 8 Jun 2004 00:29:36 -0400
- Subject: Re: GDB and ARM Frame Pointer strangeness
- References: <40C42C75.5020208@neurizon.net> <40C53F70.8030101@neurizon.net>
On Tue, Jun 08, 2004 at 02:24:16PM +1000, Steven Johnson wrote:
> This is all well and good, but at the beginning of the world, when the
> target is not yet properly initialised, the frame is corrupt.
> Dereferencing R11 (on an ARM) and then looking at that Memory is BAD.
> R11 at the beginning of the world doesnt contain anything valid.
It is the responsibility of the stub to be robust against bad reads, in
general. Most stubs manage this without trouble.
> This seems to be a worse problem (to me) than the one supposedly solved
> by the piece of code here. I would have thought it would only need to
> do this if:
> 1. The frame was valid. AND
> 2. You modify a frame register OR
> 3. You modify any memory within the current Frame.
GDB has no concept of "valid" in the sense that you're using it.
"There is always a frame" - if we're connected to a target that has
registers and memory, it has a frame.
If your stub is going to fall down like this I recommend having the
stub initialize registers to point to memory that won't trap when read.
--
Daniel Jacobowitz