Re: GDB and ARM Frame Pointer strangeness

[Steven Johnson <sjohnson@neurizon.net>]

Ian,

Thankyou for your response.  Yes writing JTAG Interfaces can be 
challenging, as sometimes the documentation leaves a lot to be desired, 
but i've done it before and I am up for the challenge :)

Ian Lance Taylor wrote:

>Steven Johnson <sjohnson@neurizon.net> writes:
>
>  
>
>>In summary, if there is no ABI that GDB knows about in use, it is
>>invalid for GDB to assume a register is the Frame Pointer and then to
>>start de-referencing it.  The same can be said for the stack pointer
>>on architectures that do not have a "Hardware" stack pointer, but just
>>use an arbitrary register as one.
>>    
>>
>
>gdb isn't written for such environments.  It expects stack frames and
>frame pointers.  When it first attaches, it tries to figure out what
>the stack frame looks like.  gdb doesn't have an "assembly mode" in
>which it presumes that code is not in any sort of function context.
>
>  
>
Finally, the nub of the problem.  As a comment, GDB is becomming less 
and less so inclined to like such targets.  We have 2 other JTAG/BDM 
targets, one of which we created, both use GDB V5.1 as their debug 
interface.  These are both operating at the same low level, without 
problem.  GDB V5.1 doesnt seem to do as much automatic target sniffing 
(ive never noticed any that wasnt the direct and predictable result of a 
command I had instigated).  Although I specifically dont do stack traces 
when I know the target isnt in a state to do it properly using GDB V5.1.

>>Setting the ABI to "none" doesn't appear to do anything.  Should it?
>>    
>>
>
>I don't think so.  Changing the ABI in general doesn't do much.  For
>some targets it affects stuff like where parameters should be passed.
>Setting the ABI to "none" means that gdb has no information about the
>ABI at all.
>
>  
>
Ok, maybe ABI='none' can do more than it does now.

>>At
>>the very least there needs to be some control over these "high level"
>>operations so that "low level" things can be debugged without
>>interference from them.
>>    
>>
>
>Sounds reasonable to me: an assembly mode.  Of course, somebody has to
>volunteer to do the work.
>
>  
>
As I stated in a previous message, I dont mind doing work on GDB and 
contributing code. Ive done that already in the past (the assignments 
are already in place) [post hooks are one of my previous contributions, 
which I introduced so that I could automatically set GDB up to program 
the Flash in my target when I downloaded my code through GDB. :)].  All 
I need is some friendly advice when I propose my suggested sollution.  
The suggested solution is as follows:

1.  For the case of the memory write causing a FP De-reference, a check 
is added to determine if the ABI is "none".  ABI="none" meaning the high 
level operations GDB performs are blocked.  If it is none, the FP 
handling at that stage is just skipped.
2. For the case of a stack trace operation, early in the stack trace 
operation, a check is made to see if the ABI = "none" if it does a 
friendly message is printed informing the user that Stack Traces are not 
possible with the ABI set to "none" as there is no known context.

These are the 2 areas that come to mind with regard to this problem.  
Are there others?  I Propose that I work on adding these 2 changes, and 
if there are any other GDB Operations that also require knowledge of the 
ABI and could cause unwanted accesses to the target they are blocked 
accordingy.

In this way, GDB will have moved closer to being "assembly mode" 
friendly.  Im not really sure what is meant by "assembly mode" btw. GDB 
will happilly connect to a target, single step etc, without knowing what 
the code in the target is (ie, without having first loaded any symbol 
information).  It can disassemble no problem.  I have a "S" macro, that 
makes GDB look a bit like DOS "debug" , steps one instruction, prints up 
the registers and the next 8 instructions are disassembled.  Nice and 
easy.  And as I say, when doing this with GDB V5.1 I never had a problem 
with unexpected memory accesses caused by GDB.  To me I never considered 
before that GDB wasnt very good at working at this level, it was always 
capable of doing everything I wanted of it at this level.  Even to the 
point of debugging Assembly code in ROM, and using hardware breakpoints.

What I want to do, is add an option so I can return it to "less 
intelligent" mode, when that mode is appropriate.

Any comments on this proposal before I start on it?

Steven.