This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB and ARM Frame Pointer strangeness


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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]