This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A couple of questions about gdb and a remote stub


Hi all,

Firstly, I apologize for such a long posting but I've been running up against a wall caused by my lack of experience with the internals and configuration details of gdb and limited familiarity with the gdb sources. I've spent some time finding and searching through documentation but I don't think that I'm using the right terminology and I'm hoping that someone will be kind enough to point me in the right direction.

I am developing for a Hitachi/Renesas SH CUP running in an embedded target with either ThreadX or uCOS handling multithreading and a TCP/IP stack for communication. I'm using gcc 3.2 and gdb 5.0. The system is running and I have added a thread that runs a simple gdb stub so that I can use gdb and gdbtk for debugging. The stub seems to up and running and I can connect to it using the command

target remote [IP Address]:1000

and it is getting what looks like valid responses. The gdb stub thread allows me to set breakpoints in other threads and to select which thread to trace, I have some checks so that I don't end up setting a breakpoint in one of the tasks that is running the TCP/IP stack or in the gdb stub task, both of which will result in breaking the communications link. Since the program in the target is running partly in Flash, I found that I needed to implement the Z commands for setting breakpoints using the hardware trace in the CPU (because gdb can't modify all the memory) and I found that I needed to implement the S instruction to be able to step through the program.

The major problem that I have is related to this restriction. Tracing the messages, I find that the gdb step commands (Step Into next C statement, Step Over next C statement, Step Out of subroutine) all seem to work by issuing a sequence of stepi (Step machine instruction) commands until the PC from the instruction reaches the correct value. This is not really a problem if I choose to Step Into a function call but can cause problems with my system for the other cases because I can't really trace into the OS or TCP/IP stack library calls without the risk of blocking the communications stack. When this happens, the stepi doesn't respond (since one of the mutexes in the stack may be blocked by the executing thread and the gdb communications thread can't transmit) and we wind up with the system needing to be reset and gdb reconnected, killing that debug session.

My current work-around is to manually set a breakpoint at the next instruction, or to use the stack trace display to find out where the current routine was called from and set a breakpoint there, since, as long as I don't put breakpoints inside mutex regions, this won't starve the gdb communications thread. 

However, all the information I'm using is known to gdb (i.e. current line or the line of calling routine) I was hoping that there was some way to get gdb to use breakpoints for stepping instead of the instruction by instruction trace, does anyone 
know of any way to do this without having to rebuild gdb.

A secondary concern is that, since the system must already be running for me to connect to it, I don't want to actually download the code to the system. I don't think I'd actually have a problem with downloading the .text sections, since there would be no change effectively, but I definitely don't want to download the initialized data sections which would restore all the data to it's initial state and effectively reset the TCP/IP stack and cut the communications link. There is also a lot of data to download, and the gdb remote protocol is not terribly efficient, so even if I can set this up as a ROM type system where the initialized data is in a read only section and is copied into RAM on startup (so that the download is not going to change any working memory), it still adds over 2 minutes to the load process.

Using the GUI, I can load the file and under the target configuration there is a checkbox to select "Download Program" which is checked by default. If I uncheck it, then when I connect to the remote target, the program is not downloaded (as I want) and everything works as I want it to.

I seem to run into a problem however when I try to set everything up using a .gdbinit file. I have to use the 'file' command in the initialization file so that gdb will load the memory data, and I use the 'target remote' command to connect to the target. However, this tried to download the program, regardless of the state of the "Download Program" checkbox  in the GUI because I assume it is processing the initialization file before starting the GUI. I did find the gdb internal variable called "download_write_size" and if I set it to 0, then it seems to disable the download. I was concerned however if this was the only thing that it does. There doesn't seem to be a corresponding variable for simply writing to the target memory, so I was concerned that this may affect some other operations.

I did try to look at the sources to see what the "Download Program" checkbox affects but it is a long time since I used ticl and I was not an expert then and I couldn't find what the checkbox affects.

Does anyone know the "correct" way to only disable downloading to the target but not to affect any other gdb operations, from the initialization file (or command line gdb) or point me to where it is handled by the GUI.

A final question - when I'm tracing, the system will sometimes trace into library calls. Of course, since there isn't any source (and I don't think there's debugging information either) it only debugs in assembly. Some of the debuggers I've used (including some versions of gdb) can ignore tracing into system calls and library functions and I was wondering if it is possible to do the same for my version of gdb. This is not a serious problem but it can get confusing and I would be surprised if there was not some way to stop gdb tracing into system calls and such.

Once again, my apologies for the long posting, I wanted to make sure that anyone reading this would understand what I needed even if I was using incorrect terminology.

Thanks
Stan Katz

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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