Re: GDB and ARM Frame Pointer strangeness

[Steven Johnson <sjohnson@neurizon.net>]

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