Fabio Giovagnini wrote:
Thanks for the answer.
I go deeper in my thought so that maybe you can give me more infos about how I
have to investagte about gcc/gdb
We are developers of embedded software on board designed and build by us;
Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / 3 ).
We write applications for automotive enviroment mainly.
We write the code using c/c++ and we compile using gcc.
Because of we do not have much memory (ram and flash) we develop in the
following way: each software we write has the same communication protocol
running on RS232 or over TCP/IP and we have a simple monitoring progarm able
to show the contents of the memory addresses in some format (char, int, long,
signed unsigned, strings, ecc).
It sounds like you are recreating the functionality in the gdb remote.
Generally we declare a global variable, we write a debug value into it and
during the run time we read at the right moment the content of such a
variable.
Good.
For avoiding to read by hand .map file produced by ld, I developed a flex /
bison simple analizer able to extract from .map file the address of a symbol.
So into my tool I load the .map file and I write the name of the variable and
I can read the content of it.
This way of working becomes very hard if I use struct and union in c and
classes in c++; I should know the offeset of each field of the struct so
addind it to the base address known from the .map file, for each istance of
such a struct I coud write "mysrtuct.myfield" into my tool, and, calculating
the rigth address, my protocol could ask the target to read/write the content
at that address.
Yes, developing a debugger it quite time-consuming and difficult. That is
essentially what you appear to be doing.
I prefer to avoid -g option because of my memory is never enough; but a good
compromise cound be if I could compile the debug infos into sections I could
remove after used by gdb for giving me the informations about the offset of
each field. Is it possible?
Why is the size of your target memory an issue? Are you trying to run
the debugger on the target?
In most cross-development environments, the debugger (gdb) runs on
a host system and only a small portion of code (gdb remote) runs on
the target. The size of your target's memory doesn't affect the host.
Where can I read more about to use gdb for embedded development with very poor
uControllers?
Try "info gdb" as a start.
--
Michael Eager [EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
