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