Re: untangling c & tcl code

[Duane Ellis <duane_ellis at franklin dot com>]

keith> What is the exact procedure you're using? File->Open... of file
       and the Run button connecting to target "Remote/tcp" with
       "localhost" and port?

The simulator is "compiled in", there is no need to establish a tcp/ip
connection, and nothing will be listening anyway. GDB thinks that it
is a remote device though, it was how I figured out how to hook it up.

We normally load the .coff file from the command line, ie:

  bash$ /some/path/snk32-gdb FooBar.coff &

Other times, we use the "file" command in a script because loading the
actual run time image is complicated, I'll explain:

 I have 2 or more roms in my device. Each is built independently.

 Think about the PC BIOS roms and how they discover other roms.

 Rom 1 is at the reset vector (loaded as a coff file from the command
 line, or "file" command). When it starts, it sniffs around and
 discovers the other roms via signatures at specific addresses. Then
 blindly jumps into them via some jump table.

 The code for the other "roms" is actually loaded via a load_bin_file
 command unique to my simulator. We use 'add-symbol-file' to tell GDB
 about the symbols in it so you can source level debug it.

keiths> These are used by SrcWin::set_execution_status, which has been
	a major PITA since it was first written.

Really, I would have never guessed that :->

One thing I'm really glad about though is the number of warnings have
decreased, somebody started fixing warings *YEA* *YEA* *YEA* and
warnings are basically errors in some places, *YEA* *YEA* *YEA*

keiths> Usually your symptoms are a sign that you have a null_ptid for
	inferior_ptid, which indicates that there is no inferior.

This is a problem area, I see that this has changed in the new
versions of GDB, the ptid was an int, now it is a struct.

In my case, there is and there isn't, a "ptid", it depends on what you
are doing. And during the debug session this can change: Example: you
are debugging a thread or task under an OS that makes calls into a
common BIOS. Or maybe, you are debugging BIOS sections. 

Other times, a plain old simple app... 

Its just messy.

my solution was to tell GDB, yep you got a ptid, and it's valid and
never touch that variable again... and do what I need outside of GDB.

I've gotten into the situations where I've have added knowledge of the
OS to the simulator so that I could set conditional break points based
upon the task/thread you are in.

ie; Set a break point in the shared library at strcpy(). But only
honor break points if task==3, and thread==4

-Duane.