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] |
Steven Johnson <sjohnson@neurizon.net> writes: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.
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.
Ok, maybe ABI='none' can do more than it does now.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.
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: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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |