Re: GDB and ARM Frame Pointer strangeness

Steven Johnson
2004-06-08T05:02:15Z

I simply disagree,

The stub does not know what memory is validly accessable, It does not
seem unreasonable that if you do not access a memory location that GDB
should not attempt to read it.

I can give a number of real worl examples:
1. CPU's that have programmable Chip Selects. The stub does not have
any information about how the Chip Selects might be set up, its told to
read memory, so it does. If the Chip selects are not set up, the memory
will not be accessable and therefore not readable.
2. Assembler programs that do not conform to any high level language
ABI. I thought GDB could debug Assembler programs. The way it stands,
if you put strange (non FP) values in the Frame Pointer register, the
debugger runs the risk of de-referencing it, and reading the wrong
memory. For example, There could be a "valid" memory location, but
assembly code puts the address of a memory mapped IO Register in R11 (in
my case the FP of an ARM). When debugging, the person debugging the
code tries to write another address, and GDB conveniently reads the
address held in R11, without being instructed to. This Memory Mapped
IO, could be the sort that is read once, and the contents are lost. It
looks like GDB is becoming to bound to someones arbitrary ABI and is
becoming unsuitable for debugging Assembler.

I dont think this is the intetntion, if it is the case.

I have yet to come across a stub that validates memory addresses. Stubs
are usually Lean and Mean. What criteria would a stub use to validate
the memory addresses?

I accept that if a person debugging, instructs GDB to access an invalid
memory location they deserve what they get if that puts their target
"off the air". But unless they specifically read a memory address, I
dont see why GDB goes and does it by itself. At the very least this
sort of automatic operation should be able to be turned off.

Further, this is recently introduced, we have never experienced this
"problem" in earlier versions of GDB.

I am talking about a "set" operation of memory, there is just no
justification why that should trigger a read, especially when no
specific ABI is being used, and when the target and stack frame are not
initialised.

It is wrong to say "if we are connected to a target that has registers
and memory, it has a frame" it is only correct to say "if we are
connected to a target, and it is using an ABI GDB knows about, and it
has registers and memory, and it is initialised, it has a frame". Looks
like something is missing here.

To me, this problem is far worse than the potential of corrupting GDB's
knowledge of the stack frame. And it is obviously lately introduced
(since version 5.1).

It would be ideal if the old behaviour could be retained while still
retaining the advantages of this change.

Steven

Daniel Jacobowitz wrote:

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