Re: GDB and ARM Frame Pointer strangeness

[Steven Johnson <sjohnson at neurizon dot net>]

I have tracked the root cause of GDB reading invalid memory at its whim, 
but am at the moment confused as to the way to solve this problem.

The problem resides in the function: value_assign in valops.c

struct value *
value_assign (struct value *toval, struct value *fromval)
{

 [snip]

 /* Since modifying a register can trash the frame chain, and modifying 
memory
    can trash the frame cache, we save the old frame and then restore 
the new
    frame afterwards.  */
 old_frame = get_frame_id (deprecated_selected_frame);

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.

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.

Otherwise the operation is un needed. (As far as I can tell).  Is there 
any way to determine if the frame is valid, so that at least that check 
can be added to this code, to prevent GDB illegally accessing invalid 
memory?

Steven Johnson

Steven Johnson wrote:

> Hi all,
>
> I have compiled GDB 6.1 for ARM Cross Debugging. Hosted on X86 Linux.  
> Ive been doing this for a while with PowerPC, so im no stranger to 
> it.  Well, now I have an ARM target and I am writing an ARM remote 
> interface to my target communicating using the Remote Protocol over 
> TCP/IP.  The strange thing is, right after startup, if I try and write 
> an absolute memory location GDB insists on dereferencing the Frame 
> Pointer (R11) and reading the address stored there.  It then does 
> something with the result and dereferences that.
>
> The problem is, I havent got a program loaded yet. And the Registers 
> are just in any old state, a program not having been loaded and run.  
> Dereferencing the FP (R11) is causing the target to crash, becasue the 
> memory it is trying to access is a random address (being the default 
> garbage in the register) and this is causing the target to get a 
> memory exception and die.
>
> Not Good.
>
> Why is GDB insisting on de-referencing the FP when all I asked it to 
> do is write to an absolute memory location. I have not told it to do 
> anything that is frame pointer relative.  The last thing I expect to 
> see is 2 memory read packets when i execute:
>
> set (unsigned int)0x0 0x12345
>
> all i should see is the memory write packet.  The single memory write 
> packet is all i ever saw with my PowerPC target, it never dereferenced 
> the FP on a memory write operation????
>
> Is there a way to turn this undesirable operation off?
>
> Any help would be appreciated.
>
> Also, as an aside, 2 other strange things ive noticed with the ARM GDB:
>
> it seems "set architecture" causes GDB to crash for ARM targets.  eg 
> set architecture armv4t followed by the write indicated above crashes 
> GDB.  Leaving it on Auto does not.
>
> and, set osabi does not work with ARM for anything other than "none" 
> or "auto" I was trying to set an ABI to an embedded ABI, that 
> theoretically doesnt use an FP, but the command doesnt work. Eg,
> (gdb) set osabi ARM EABI v1
> Ambiguous item "ARM EABI v1 ".
>
> same goes for "ARM EABI v2" and "ARM APCS"
>
> only "none" "default" and "auto" works.
>
> Also, this is a raw GDB, meaning I havent loaded any application.  Im 
> just trying to get GDB to talk to my target, so am not interested in 
> debugging an actual application yet.  Reading and writing 
> registers/memory and disassembling are the big ticket items at the 
> moment.
>
> Steven Johnson