Re: GDB and ARM Frame Pointer strangeness

Steven Johnson
2004-06-10T07:16:40Z

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.