Verification on how TARGET_CFLAGS is set

Verification on how TARGET_CFLAGS is set

[Bryan Evenson]

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?

Any other related tips are welcome.

Thanks,
Bryan Evenson

Re: Verification on how TARGET_CFLAGS is set

[Richard Purdie]

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).

Cheers,

Richard

Re: Verification on how TARGET_CFLAGS is set

[Mark Hatle]

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.

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)

--Mark

> Cheers,
> 
> Richard
> 

Re: Verification on how TARGET_CFLAGS is set

[Richard Purdie]

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.
> 
> 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?

Cheers,

Richard

Re: Verification on how TARGET_CFLAGS is set

[Bryan Evenson]

Richard and Mark,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of Richard Purdie
> Sent: Monday, March 30, 2015 5:43 PM
> To: Mark Hatle
> Cc: openembedded-core@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Verification on how TARGET_CFLAGS is set

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On 31 March 2015 at 13:28, Bryan Evenson <bevenson@melinkcorp.com> wrote:

> 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.
>

At build time it adds the full debug symbols to the executable, but at
packaging time we split out the debugging information to separate files and
then separate packages.  So the difference between a binary produced
without -g and with -g but with debug info split is just the identifiers so
that GDB can find the debug symbols.

Ross

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]