Frame dereferencing causing problems for remote target

[Accounts <accounts at sakuraindustries dot com>]

Hi,

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