Debug version

Till Straumann strauman at slac.stanford.edu
Mon Feb 26 19:49:11 UTC 2007


Leon Pollak wrote:
> On Monday 26 February 2007, you wrote:
>   
>> I don't know if that's the correct/recommended method
>> but I found that I can pass
>>
>> RTEMS_CFLAGS=-g
>>
>> to the 'configure' script, i.e.,
>>
>> configure    RTEMS_CFLAGS=-g  <other 'configure' options>
>>
>> I believe that editing <mybsp>.cfg should work, too.
>> However, changes in that file are not picked up easily
>> - you might have to purge your build tree entirely
>> and start over with 'configure'.
>>     
> Thank you, Till.
> Yes, the editing of mybsp.cfg worked, but is very hard option as everything 
> must be redone.
>   
No way around redoing everything. Wonderful 'configure'
creates all the Makefiles where this flag is hardcoded.

You could do a 'make clean' then 'make XXX=-g' [the XXX variable
must be one that ends up in the cflags but I don't remember out
of my head what you could use there]. However, the problem with
this approach is that you have to remember supplying this every
time you invoke make or you'll end up with some bits w/o debug
info. I happen to rebuild a lot and therefore want the flags to be
present in the Makefiles. Just bite the bullet - purge, reconfigure,
rebuild and have a coffee ;-)
> Two questions, please:
> 1. Does the case of configure option require running 'make 
> clean', 'configure', 'make install' again or only the 'make install' be done?
> 2. How do you store these two different versions (debug/release)? I move now 
> from old version from 2003 and there were two build directories and one 
> directory with both kinds of libraries (*.a and *_g.a). How do you solve this 
> in your approach?
>   
I always want debug info (with optimization turned on). Sometimes,
optimized code is a little bit harder to debug but I'm used to it.
Nevertheless, you always want it. There comes the day when your
application crashes and you wish you had it. It doesn't affect
program execution (since -O is also turned on), it doesn't affect
the size of the pure binary on your target. Just the object files
on my host are bigger - who cares...

T.

PS: Another reason for me not using -g without -O is that
optimized code is quite a bit different from unoptimized
code. I don't want to lose time hunting down things that 'work'
without -O (and with -g) but break with -O. I want to debug
exactly what is normally running.
> Thank you.
>   




More information about the users mailing list