From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Verification on how TARGET_CFLAGS is set
Date: Mon, 30 Mar 2015 22:43:28 +0100 [thread overview]
Message-ID: <1427751808.14020.327.camel@linuxfoundation.org> (raw)
In-Reply-To: <5519B425.1040906@windriver.com>
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
next prev parent reply other threads:[~2015-03-30 21:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 13:09 Verification on how TARGET_CFLAGS is set Bryan Evenson
2015-03-30 20:27 ` Richard Purdie
2015-03-30 20:37 ` Mark Hatle
2015-03-30 21:43 ` Richard Purdie [this message]
2015-03-31 12:28 ` Bryan Evenson
2015-03-31 13:06 ` Burton, Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1427751808.14020.327.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.