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]

Frame dereferencing causing problems for remote target


Hi,

(Sorry, i sent from the wrong email account, please reply to this email, not the previous)

Im trying to use GDB 6.3 at the moment.

I have a remote target, which I am connecting to with "target remote ....."

When I assign registers, or do other things, immediatley after
connecting, GDB attempts to call "frame_register_unwind"

the problem is, this causes GDB to read memory from the target, based on
the values of registers, that at this stage do not contain any
information about the frame or stack.

So sometimes, depending on what random junk happens to be in
memory/registers, GDB just goes off on an infinite loop (at least it
went for 10 minutes or so, before i gave up) sending $m packets, for 4
bytes, and incrementing by 4, and continuing.

It is not crashing my target, my target is happily returning the values
of the memory GDB is requesting, its just that the data is
(a) garbage, as i havent even loaded the program yet with "load"
(b) causing GDB to act up.

other times, GDB just refuses to behave, because the random junk in
memory is causing GDB to generate errors, and so wont execute the
commands in my "hook-load" macro, because one of them gets an error, so
the "load" is terminated.  I could try and do them manually, and I have,
but this is tedious, and just seems wrong.

Is there anyway to tell GDB "Dont worry about the frame, there isnt one
yet?" and if not, what would be the best way to add this.  I understand
"GDB must always have a frame" well thats fine for GDB, but targets dont
always have frames, and this isnt a useful answer to the problem.  This
is a problem i highly suspect would be unique to the embedded space.
Especially with advanced Remote interfaces, that do not use any
resources of the target board (such as those connected through JTAG, or
BDM's or In Circuit Emulators).

I have tried setting "to_has"stack" in remote.c to "0" for a test, but
that doesnt work.
I also tried forcing a sentinel frame in "get_current_frame" and that
doesnt work either.

Both produce errors, that effectively prevent debugging.

I suppose what i am thinking about is a "Dummy Frame" so that GDB is
happy (because it has a frame), but isnt coming from the target, cause
the target doesnt have a frame.

I cant fix this in the stub, because the stub doesnt know when GDB is
performing frame accesses, and so can not decide when to report the
actual contents of memory, or faked values to satisfy GDB about the
frame, when there isnt one.

Any suggestions would be appreciated.

Steven Johnson


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