[OE-core] Verification on how TARGET_CFLAGS is set

[Bryan Evenson]

Richard and Mark,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf
> Of Richard Purdie
> Sent: Monday, March 30, 2015 5:43 PM
> To: Mark Hatle
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] Verification on how TARGET_CFLAGS is set
> 
> On Mon, 2015-03-30 at 15:37 -0500, Mark Hatle wrote:
> > On 3/30/15 3:27 PM, Richard Purdie wrote:
> > > On Mon, 2015-03-30 at 13:09 +0000, Bryan Evenson wrote:
> > >> I am about to upgrade to the dizzy branch.  I have a built a bootable
> > >> image on my test build machine, and now I'm going to be applying
> > >> changes to the system I use for building production images.  I'm
> > >> planning on deleting my tmp directory to force a re-build of
> > >> everything.  Since I'm rebuilding everything anyway, I'm taking a
> > >> deeper look at the CFLAGS related settings and I'm getting a little
> > >> lost in the logic.  I'd like to verify these settings before I start
> > >> rebuilding everything.
> > >>
> > >> If I'm following the default logic correctly in bitbake.conf, by
> > >> default TARGET_CFLAGS will be set to "-O2 -pipe -g
> > >> -feliminate-unused-debug-types".  I want the default TARGET_CFLAGS
> for
> > >> my production image to be "-O2 -pipe".  What's the suggested variable
> > >> to change, and where, to get this final value?  Do I set TARGET_CFLAGS
> > >> directly, or do I set SELECTED_OPTIMIZATIONS or even
> > >> FULL_OPTIMIZATIONS?  Do I set it in local.conf or should I be setting
> > >> it somewhere else?
> > >
> > > If I remember rightly, you need the -g option there to generate the -dbg
> > > packages correctly. The target system binaries won't change since we
> > > separate out the debug data into separate files as part of the packaging
> > > process.
> > >
> > > You therefore can gain some build performance from turning that off but
> > > your runtime won't alter much (other than the debuglink ID which is a
> > > few bytes).
> >
> > I strongly caution people against removing '-g' from their production builds.
> > If you do, you will no longer have any way to do any type of production/field
> > debug.  As Richard indicated the -g will cause the symbols and debug information
> > to get separated into special -dbg packages that you generally don't distribute
> > on a production device -- but those same -dbg package (preserved) can be later
> > used for debugging of production devices.

In my situation this is kind of a moot point, as I've never been able to successfully get gdb to work.  It has been a while since I've tried, so I guess I could give it another go.

> >
> > This is why the default is what it is.
> >
> > The difference in executable size between -g (split debug) and w/o -g, is
> > usually around 15 - 30 bytes.  Roughly the length of the path to the
> executable
> > and/or library plus ".debug/" (7 characters)
> 
> Are you sure its even that? I thought it was literally just the debug ID
> code and the paths to debug were assumed by the debug tools which would
> search several locations for a matching ID?

Is that all that it is?  I was under the impression that adding -g adds the debug symbols to the executable, not just the hooks to include the debug symbols.  If the -g flag really does just add a few bytes to each executable, then I won't worry about it.

Regards,
Bryan

> 
> Cheers,
> 
> Richard
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core