Hi all, just an onfo about huw to use gcc tree

Michael Eager eager@eagercon.com
Sun Mar 4 01:12:00 GMT 2007


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	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



More information about the Gcc mailing list