[gentoo-dev] fix binary debug support, part elevenity billion

[gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

this topic has come up before too many times and has yet to be solved, and we 
have too many hacks in place

the issues:
- USE=debug is way too vague; sometimes it builds different code (i.e. 
additional runtime checks, debugging output, yada yada) and sometimes it 
forces debugging gcc flags into CFLAGS
- debug.eclass: it sucks, we all know it, enough said
- no easy way for users/developers to quickly emerge a package and have it 
contain useful debugging information, running `FEATURES=nostrip CFLAGS="-g 
-O" emerge booga` is petarded

the one true solution:
- USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
enables additional runtime code (such as assert()'s or helpful debug 
output) ... if you're confused by what i mean, run `USE=debug emerge nano` 
and then run `nano`
- we add an emerge flag (say '--debug-build') which adds "nostrip" to FEATURES 
and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS
- portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g" 
and DEBUG_LDFLAGS="")

so what have i missed ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Joshua Baergen]

Mike Frysinger wrote:
> - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g" 
> and DEBUG_LDFLAGS="")
>   
Nothing huge, but won't this fry certain systems (SPARC iirc, among 
others) that need the -march information for the code to even run?  If 
so, the solution would have to grab march/mcpu/mtune values and add them 
to the debug cflags.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

On Sunday 15 January 2006 01:19, Joshua Baergen wrote:
> Mike Frysinger wrote:
> > - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O
> > -g" and DEBUG_LDFLAGS="")
>
> Nothing huge, but won't this fry certain systems (SPARC iirc, among
> others) that need the -march information for the code to even run?  If
> so, the solution would have to grab march/mcpu/mtune values and add them
> to the debug cflags.

then we could set default DEBUG_CFLAGS in the profiles
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Henrik Brix Andersen]

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

On Sun, Jan 15, 2006 at 01:11:54AM -0500, Mike Frysinger wrote:
> the one true solution:
> - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
> enables additional runtime code (such as assert()'s or helpful debug 
> output)

Some packages automatically appends stuff to CFLAGS when turning on
package specific debug options - should this be kept or removed
following your approach?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

On Sunday 15 January 2006 06:52, Henrik Brix Andersen wrote:
> On Sun, Jan 15, 2006 at 01:11:54AM -0500, Mike Frysinger wrote:
> > the one true solution:
> > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> > enables additional runtime code (such as assert()'s or helpful debug
> > output)
>
> Some packages automatically appends stuff to CFLAGS when turning on
> package specific debug options - should this be kept or removed
> following your approach?

removed

ive seen many packages where `./configure --enable-debug` simply did:
CFLAGS="-g"

now, imho, that has no place in portage
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Olivier Crête]

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

On Sun, 2006-15-01 at 01:11 -0500, Mike Frysinger wrote:
> the one true solution:
> - we add an emerge flag (say '--debug-build') which adds "nostrip" to FEATURES 
> and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS

Why not use the splitdebug instead of nostrip? And make building with -g
the default, then tell small HD users how to disable it in the docs. And
it needs to disable -fomit-frame-pointer at least on x86. I've been
building my whole system with splitdebug and yes it does take a lot of
space, but its really useful.

-- 
Olivier Crête
tester@gentoo.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Dan Meltzer]

On 1/15/06, Mike Frysinger <vapier@gentoo.org> wrote:
> this topic has come up before too many times and has yet to be solved, and we
> have too many hacks in place
>
> the issues:
> - USE=debug is way too vague; sometimes it builds different code (i.e.
> additional runtime checks, debugging output, yada yada) and sometimes it
> forces debugging gcc flags into CFLAGS
> - debug.eclass: it sucks, we all know it, enough said
> - no easy way for users/developers to quickly emerge a package and have it
> contain useful debugging information, running `FEATURES=nostrip CFLAGS="-g
> -O" emerge booga` is petarded
>
> the one true solution:
> - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> enables additional runtime code (such as assert()'s or helpful debug
> output) ... if you're confused by what i mean, run `USE=debug emerge nano`
> and then run `nano`
> - we add an emerge flag (say '--debug-build') which adds "nostrip" to FEATURES
> and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS
> - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g"
> and DEBUG_LDFLAGS="")

What would happen on subsequent merges or upgrades if --debug-build
was omitted?  Would there be a way (/etc/portage file perhaps?) to
enable debug builds on a permanent basis?

>
> so what have i missed ?
> -mike
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

On Sunday 15 January 2006 13:25, Dan Meltzer wrote:
> What would happen on subsequent merges or upgrades if --debug-build
> was omitted?  Would there be a way (/etc/portage file perhaps?) to
> enable debug builds on a permanent basis?

i didnt think anyone would want this but it'd be trivial to add a new feature 
(say "debug-build") which you could then use with per-package-env
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Richard Fish]

On 1/15/06, Olivier Crête <tester@gentoo.org> wrote:
> Why not use the splitdebug instead of nostrip? And make building with -g
> the default, then tell small HD users how to disable it in the docs. And
> it needs to disable -fomit-frame-pointer at least on x86. I've been
> building my whole system with splitdebug and yes it does take a lot of
> space, but its really useful.

No argument against splitdebug, but my guess is that it would be
useless for 99.97% of users, and would lead to complaints on -user
about how much disk space gentoo consumes compared to <insert least
favorite distribution here>, so it should not be the default.

-Richard

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

On Tuesday 17 January 2006 10:11, Richard Fish wrote:
> On 1/15/06, Olivier Crête <tester@gentoo.org> wrote:
> > Why not use the splitdebug instead of nostrip? And make building with -g
> > the default, then tell small HD users how to disable it in the docs. And
> > it needs to disable -fomit-frame-pointer at least on x86. I've been
> > building my whole system with splitdebug and yes it does take a lot of
> > space, but its really useful.

a good idea ...

> No argument against splitdebug, but my guess is that it would be
> useless for 99.97% of users, and would lead to complaints on -user
> about how much disk space gentoo consumes compared to <insert least
> favorite distribution here>, so it should not be the default.

... and we just make it dynamic to get best of both worlds

if user has splitdebug in FEATURES, then we skip adding nostrip to FEATURES, 
but if user has -splitdebug in FEATURES, we add nostrip to FEATURES
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Olivier Crete]

On Tue, 2006-17-01 at 08:11 -0700, Richard Fish wrote:
> On 1/15/06, Olivier Crête <tester@gentoo.org> wrote:
> > Why not use the splitdebug instead of nostrip? And make building with -g
> > the default, then tell small HD users how to disable it in the docs. And
> > it needs to disable -fomit-frame-pointer at least on x86. I've been
> > building my whole system with splitdebug and yes it does take a lot of
> > space, but its really useful.
> 
> No argument against splitdebug, but my guess is that it would be
> useless for 99.97% of users, and would lead to complaints on -user
> about how much disk space gentoo consumes compared to <insert least
> favorite distribution here>, so it should not be the default.

The argument in favor of splitdebug is that it allows users to give
useful bugreports when using tools such as gnome's bug-buddy. Currently,
gentoo users provide very little useful information because everything
is stripped. And it only adds a few hundred megs and its easy to
disable. Probably should be explained in the handbook if we make it the
default.


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
> The argument in favor of splitdebug is that it allows users to give
> useful bugreports when using tools such as gnome's bug-buddy.
Erm actually it does not. Unless gnome herd fixed it recently.
The same goes for KCrashHandler/Dr Konqui.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Olivier Crete]

On Tue, 2006-17-01 at 18:03 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
> > The argument in favor of splitdebug is that it allows users to give
> > useful bugreports when using tools such as gnome's bug-buddy.
> Erm actually it does not. Unless gnome herd fixed it recently.
> The same goes for KCrashHandler/Dr Konqui.

It does on my system, bug-buddy just spawned GDB (and it has worked that
way for as long as I can remember). So you just need gdb 5/6 and it
should work without problems with splitdebug.


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: fix binary debug support, part elevenity billion

[R Hill]

Olivier Crete wrote:
> On Tue, 2006-17-01 at 18:03 +0100, Diego 'Flameeyes' Pettenò wrote:
>> On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
>>> The argument in favor of splitdebug is that it allows users to give
>>> useful bugreports when using tools such as gnome's bug-buddy.
>> Erm actually it does not. Unless gnome herd fixed it recently.
>> The same goes for KCrashHandler/Dr Konqui.

Ditto on Dr. Konqi here.

> It does on my system, bug-buddy just spawned GDB (and it has worked that
> way for as long as I can remember). So you just need gdb 5/6 and it
> should work without problems with splitdebug.

Could be i need to up the level of debug info i'm gathering.  What CFLAGS do you
happen to use?

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Sunday 15 January 2006 01:11, Mike Frysinger wrote:
> this topic has come up before too many times and has yet to be solved, and
> we have too many hacks in place

ok, so after sitting on the list for a while and accumulating feedback, how 
about this:

- USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
enables additional runtime code (such as assert()'s or helpful debug 
output) ... if you're confused by what i mean, run `USE=debug emerge nano` 
and then run `nano`

- we add an emerge flag (say '--debug-build') which adds "debug-build" to 
FEATURES

- if "debug-build" is in FEATURES, then the following happens:
 * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to 
DEBUG_CXXFLAGS (and in the future, we can add more variables as the need 
comes up)
 * if user already has FEATURES=splitdebug, then do not add "nostrip"
 * if user does not have FEATURES=splitdebug, then add "nostrip" to FEATURES

- we will set sane debug defaults in the base profile:
 * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
 * DEBUG_LDFLAGS=""
- subprofiles can tweak these values as they see fit (or as required)

i'll go ahead and start implementing framework for this in the meantime
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Olivier Crete]

On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
> - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
> enables additional runtime code (such as assert()'s or helpful debug 
> output) ... if you're confused by what i mean, run `USE=debug emerge nano` 
> and then run `nano`

This is so overdue..
+1

> - if "debug-build" is in FEATURES, then the following happens:
>  * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to 
> DEBUG_CXXFLAGS (and in the future, we can add more variables as the need 
> comes up)

What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
only appear after certain GCC optmisations may go away... 

> - we will set sane debug defaults in the base profile:
>  * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"

I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for
default... 


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Henrik Brix Andersen]

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

On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote:
> ok, so after sitting on the list for a while and accumulating feedback, how 
> about this:
[snip]
> i'll go ahead and start implementing framework for this in the meantime

Sounds like a sane approach to me - thank you for putting in the work
for getting this implemented.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Henrik Brix Andersen]

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

On Thu, Jan 19, 2006 at 06:17:11PM -0500, Olivier Crete wrote:
> What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
> only appear after certain GCC optmisations may go away... 

The user can set any DEBUG_CFLAGS she likes in make.conf.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[solar]

On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote:
DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"

Mike, 
how about
DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie"

All Gentoo properly supported toolchains support the last two flags and 
it ensures that debugging almost works for hardened users too.
I'd say I could just run with the extra
flags in the hardened/* profiles but it seems a good portion of the 
users these days seem to be vanilla users using 'gcc-config > 1'


-- 
solar <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mark Loeser]

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

solar <solar@gentoo.org> said:
> On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote:
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
> 
> Mike, 
> how about
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie"
> 
> All Gentoo properly supported toolchains support the last two flags and 
> it ensures that debugging almost works for hardened users too.

Please lets avoid this assumption.  I'd love to make it so we never make this
assumption anywhere in the tree so that we could actually build GCC without
pie or ssp, instead of generating all of the GCC profiles for every user.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Crete schrieb:
|>- we will set sane debug defaults in the base profile:
|> * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
|
|
| I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for
| default...
Make that -fno-omit-frame-pointer for x86 only. amd64 has no problems
wrt to debuging frame-pointer-less executables.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0CumaVNL8NrtU6IRApKQAKCF4ZWSpU26lMEA8NRa8xFpWDEgWACePs4s
c4ReLSGnAciwDVgQdvHSvrw=
=BTJz
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Thursday 19 January 2006 18:52, Mark Loeser wrote:
> Please lets avoid this assumption.  I'd love to make it so we never make
> this assumption anywhere in the tree so that we could actually build GCC
> without pie or ssp, instead of generating all of the GCC profiles for every
> user.

pie is in upstream gcc so your argument here is INVALID

please move along, kthx
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Thursday 19 January 2006 18:33, solar wrote:
> On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote:
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
>
> Mike,
> how about
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie"
>
> All Gentoo properly supported toolchains support the last two flags and
> it ensures that debugging almost works for hardened users too.
> I'd say I could just run with the extra
> flags in the hardened/* profiles but it seems a good portion of the
> users these days seem to be vanilla users using 'gcc-config > 1'

to please the whiners, we can use:
-O -g -fno-pie

and keep the -fno-ssp in hardened profiles
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Thursday 19 January 2006 18:17, Olivier Crete wrote:
> On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
> > - if "debug-build" is in FEATURES, then the following happens:
> >  * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS
> > to DEBUG_CXXFLAGS (and in the future, we can add more variables as the
> > need comes up)
>
> What about: CFLAGS="${CFLAGS} ${DEBUG_CFLAGS}" .. otherwise bugs that
> only appear after certain GCC optmisations may go away...

then we'll deal with that ... we're trying to debug bad code, not bad code 
generation

> > - we will set sane debug defaults in the base profile:
> >  * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
>
> I'd propose "-fno-omit-frame-pointer -ggdb" for x86/amd64 and "-g" for
> default...

why ?  -fomit-frame-pointer is only used with -O whenever it doesnt interfere 
with debugging ... in other words, -O on x86 will not imply 
-fomit-framer-pointer

and as noted, x86_64 doesnt suck like x86, so this isnt an issue for amd64 :)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Donnie Berkholz]

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

Mike Frysinger wrote:
> - we will set sane debug defaults in the base profile:
>  * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"

On gcc-4, even -O can make it really hard to track stuff. Might want -O0
instead. 4.1 gets even crazier.

Thanks,
Donnie

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Ciaran McCreesh]

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

On Thu, 19 Jan 2006 19:24:18 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Mike Frysinger wrote:
| > - we will set sane debug defaults in the base profile:
| >  * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
| 
| On gcc-4, even -O can make it really hard to track stuff. Might want
| -O0 instead. 4.1 gets even crazier.

-O1 -fno-inline-functions will give you better results with C++ code.
Without -O1, g++ will skip some really basic optimisations that makes
it even harder than usual to figure out what STL code is doing...

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Harald van Dijk]

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

On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote:
> - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
> enables additional runtime code (such as assert()'s or helpful debug 
> output) ...

I'd like to see cases such as "use debug && append-flags -DDEBUG"
explicitly mentioned, please. I'm sure you meant that this is okay, but
to avoid confusion, could you actually say so? (Or, if I'm completely
misunderstanding, tell me it's not okay. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Kevin F. Quinn (Gentoo)]

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

On Thu, 19 Jan 2006 18:33:02 -0500
solar <solar@gentoo.org> wrote:

> On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote:
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g"
> 
> Mike, 
> how about
> DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g -fno-stack-protector -fno-pie"

It's enough to do LDFLAGS="-nopie" to get debuggable executables, which
might be better as it'd keep code closer to the non-debug code.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Kevin F. Quinn (Gentoo)]

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

On Thu, 19 Jan 2006 19:28:53 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Thursday 19 January 2006 18:52, Mark Loeser wrote:
> > Please lets avoid this assumption.  I'd love to make it so we never
> > make this assumption anywhere in the tree so that we could actually
> > build GCC without pie or ssp, instead of generating all of the GCC
> > profiles for every user.

SPLIT_SPECS="no" in make.conf causes just the profile default to be
built - is that good enough?

> pie is in upstream gcc so your argument here is INVALID

and -fno-stack-protector is only a problem if gcc-4.0 is built without
the ssp-stubs - from 4.1 onwards that'll be upstream as well.

Having said that, I don't think we need -fno-stack-protector in default
DEBUG_FLAGS anyway, as it doesn't inhibit debug (unlike -Wl,pie).

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Friday 20 January 2006 01:25, Harald van Dijk wrote:
> On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote:
> > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> > enables additional runtime code (such as assert()'s or helpful debug
> > output) ...
>
> I'd like to see cases such as "use debug && append-flags -DDEBUG"
> explicitly mentioned, please. I'm sure you meant that this is okay, but
> to avoid confusion, could you actually say so? (Or, if I'm completely
> misunderstanding, tell me it's not okay. :)

that depends, does your code actually have things like
#ifdef DEBUG
     <debug stuff>
#endif
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Harald van Dijk]

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

On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote:
> On Friday 20 January 2006 01:25, Harald van Dijk wrote:
> > On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote:
> > > - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only*
> > > enables additional runtime code (such as assert()'s or helpful debug
> > > output) ...
> >
> > I'd like to see cases such as "use debug && append-flags -DDEBUG"
> > explicitly mentioned, please. I'm sure you meant that this is okay, but
> > to avoid confusion, could you actually say so? (Or, if I'm completely
> > misunderstanding, tell me it's not okay. :)
> 
> that depends, does your code actually have things like
> #ifdef DEBUG
>      <debug stuff>
> #endif

screen (which is what I got it from) does.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Robin H. Johnson]

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

On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote:
> that depends, does your code actually have things like
> #ifdef DEBUG
>      <debug stuff>
> #endif
And likewise your code should NOT have some logic like the following in
it's build system.
if(debug mode)
	 ignore user cflags and use our own cracked out cflags

I've seen an upstream configure script where if you tell it you want
debug mode, the only thing it does is force CFLAGS to '-O -march=i386'
and not strip the binaries itself - this of course failed dismally when
you tried to enable debugging on non-x86 platforms.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Marius Mauch]

Mike Frysinger wrote:
> On Sunday 15 January 2006 01:11, Mike Frysinger wrote:
> 
> - we add an emerge flag (say '--debug-build') which adds "debug-build" to 
> FEATURES

IMO this is pointless and redundant.
But otherwise the proposal looks good.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Saturday 21 January 2006 23:12, Marius Mauch wrote:
> Mike Frysinger wrote:
> > On Sunday 15 January 2006 01:11, Mike Frysinger wrote:
> >
> > - we add an emerge flag (say '--debug-build') which adds "debug-build" to
> > FEATURES
>
> IMO this is pointless and redundant.

its purpose is to handle cases where user wants to always have a package built 
in this manner (ferringb mentioned it as a possibility and someone else 
mentioned they would like it)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Mike Frysinger]

On Sunday 22 January 2006 16:30, Marius Mauch wrote:
> I meant the option is redundant if it just triggers a feature setting,
> as it's the same as `FEATURES=debug-build emerge foo`

as noted in earlier proposal:
> - no easy way for users/developers to quickly emerge a package and have it
> contain useful debugging information, running `FEATURES=nostrip CFLAGS="-g
> -O" emerge booga` is petarded
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Marius Mauch]

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

On Sun, 22 Jan 2006 14:45:34 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Saturday 21 January 2006 23:12, Marius Mauch wrote:
> > Mike Frysinger wrote:
> > > On Sunday 15 January 2006 01:11, Mike Frysinger wrote:
> > >
> > > - we add an emerge flag (say '--debug-build') which adds
> > > "debug-build" to FEATURES
> >
> > IMO this is pointless and redundant.
> 
> its purpose is to handle cases where user wants to always have a
> package built in this manner (ferringb mentioned it as a possibility
> and someone else mentioned they would like it)

I meant the option is redundant if it just triggers a feature setting,
as it's the same as `FEATURES=debug-build emerge foo`

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Donnie Berkholz]

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

Marius Mauch wrote:
> On Sun, 22 Jan 2006 14:45:34 -0500
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
>> On Saturday 21 January 2006 23:12, Marius Mauch wrote:
>>> Mike Frysinger wrote:
>>>> On Sunday 15 January 2006 01:11, Mike Frysinger wrote:
>>>>
>>>> - we add an emerge flag (say '--debug-build') which adds
>>>> "debug-build" to FEATURES
>>> IMO this is pointless and redundant.
>> its purpose is to handle cases where user wants to always have a
>> package built in this manner (ferringb mentioned it as a possibility
>> and someone else mentioned they would like it)
> 
> I meant the option is redundant if it just triggers a feature setting,
> as it's the same as `FEATURES=debug-build emerge foo`

OK, where's my package.features and packages.cflags files then? I can do
what I want through Mike's proposal, which is to build a specific
collection of packages with debugging. I also don't need to duplicate
the same list of packages in one file with FEATURES=nostrip and in
another with debugging CFLAGS.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

"Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

[Please excuse the improper naming for this subject. I'll take any
suggestions to improve it :-) ]

Donnie Berkholz schrieb:
| Marius Mauch wrote:
|>I meant the option is redundant if it just triggers a feature setting,
|>as it's the same as `FEATURES=debug-build emerge foo`
|
| OK, where's my package.features and packages.cflags files then? I can do
| what I want through Mike's proposal, which is to build a specific
| collection of packages with debugging. I also don't need to duplicate
| the same list of packages in one file with FEATURES=nostrip and in
| another with debugging CFLAGS.

I'd love to have one package.env (or similarly named) file that can set
environmental options on a per-package-base. This is just a proposal,
but i personally would like it this way:

# First define a category of environmental options:
stable=( \
	"ACCEPT_KEYWORDS=\"arch\"" \
	"CFLAGS=\"-pipe -O -march=foo\"" \
)
debug=( \
	"FEATURES=\"debug-build keepwork\"" \
	"CFLAGS=\"-pipe -O0 -ggdb\"" \
)
# then tell portage to use a env-category for certain packages:
app-foo/totallybroken		debug
=app-bar/anotherbrokenpkg	debug
# Also, system packages should get their own category that would
# be used by default on them.
system=( \
	"ACCEPT_KEYWORDS=\"arch\"" \
	"FEATURES=\"buildpkg\"" \
)

This proposed format could even be more easily parsed when split into to
files. One file to define the categories and one to define the
package-to-category bindings. The first file would be pure bash and
could be loaded like this:

mycat=$(
	. ${CATEGORY_FILE}
	cat=${!cat}
	for i in $(seq 0 $(( ${#cat[@]} - 1)) ) ; do
		echo -e "${cat[${i}]}"
	done
)

Comments? Please keep in mind that the code snippets here are just
proof-of-concept code and not meant literally!

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD1SA1aVNL8NrtU6IRAn/eAKCl2VcCAayy6TgsU3voRZvd+JQtOgCgpXNX
+9G+//2+O/DxhcSXXyMjE6w=
=LtXA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Mike Frysinger]

On Monday 23 January 2006 13:28, Danny van Dyk wrote:
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base.

i thought this was already implemented
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Brian Harring]

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

On Mon, Jan 23, 2006 at 07:28:05PM +0100, Danny van Dyk wrote:
> Donnie Berkholz schrieb:
> | Marius Mauch wrote:
> |>I meant the option is redundant if it just triggers a feature setting,
> |>as it's the same as `FEATURES=debug-build emerge foo`
> |
> | OK, where's my package.features and packages.cflags files then? I can do
> | what I want through Mike's proposal, which is to build a specific
> | collection of packages with debugging. I also don't need to duplicate
> | the same list of packages in one file with FEATURES=nostrip and in
> | another with debugging CFLAGS.
> 
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base. This is just a proposal,
> but i personally would like it this way:
> 
> # First define a category of environmental options:
> stable=( \
> 	"ACCEPT_KEYWORDS=\"arch\"" \
> 	"CFLAGS=\"-pipe -O -march=foo\"" \
> )

We've already got package.keywords...
Not saying it's the best, but muddying up the existing configuration 
with N ways of saying the same thing imo isn't the sanest.

> debug=( \
> 	"FEATURES=\"debug-build keepwork\"" \

And there is the kicker.  Portage has globals, which are in various 
states of use- most of the features you're looking to tweak *are* 
effectively globals already.

So... you need seperate configuration instances.  This gets ugly since 
not all code uses a passed in config instance, some falls back to 
global access (just the same as not all code uses passed in dbapi's, 
they use the global portage.db).

The config representation does a nasty little dance where it pushes 
changes on, then pops them (moreso it just flat out regenerates the 
settings)- extending usage of that really isn't a good thing imo, 
since it's fundamentally the wrong design.  Hell, such an approach 
won't fly anyways for any real possibility of threaded execution 
(parallel-fetch doesn't count, it's a fork for exactly this reason).

See where I'm going with this, and why the portage crew occasionally 
make reference to design flaws? :)

Might I suggest this one just get shelved for a while?  I'm not much 
for spanky's proposal from an implementation side of things, but it 
skirts the areas I'm concerned about (thus I'm mostly neutral on it), 
but varying all configuration data per node is a whole different beast 
from spanky's proposal- it's not skirting the areas that are icky.

Realistically, need to design the bugger so configuration data is 
pushed down to each level/abstraction rather then a global obj; do 
that, and it's easy to vary settings per node; rewrite is designed 
this way, just not finished.

Personally, I'd rather revisit this a few months down the line- right 
now it's too nasty of a hack to even consider it in stable.


> This proposed format could even be more easily parsed when split into to
> files. One file to define the categories and one to define the
> package-to-category bindings. The first file would be pure bash and
> could be loaded like this:
> 
> mycat=$(
> 	. ${CATEGORY_FILE}
> 	cat=${!cat}
> 	for i in $(seq 0 $(( ${#cat[@]} - 1)) ) ; do
> 		echo -e "${cat[${i}]}"
> 	done
> )

Bash side overrides are a no go; either the resolver would have to 
spawn a shell instance for processing each node, or portage would have 
to know how to parse and execute shell (hard... very hard).

So... at least the bash side of it, not really doable imo.  Same 
reason you can't use bashrc to affect features (for the most part), 
by the time that code is executed it's too late in the game.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

[Paul de Vrieze]

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

On Saturday 21 January 2006 00:25, Robin H. Johnson wrote:
> On Fri, Jan 20, 2006 at 07:10:02AM -0500, Mike Frysinger wrote:
> > that depends, does your code actually have things like
> > #ifdef DEBUG
> >      <debug stuff>
> > #endif
>
> And likewise your code should NOT have some logic like the following in
> it's build system.
> if(debug mode)
> 	 ignore user cflags and use our own cracked out cflags
>
> I've seen an upstream configure script where if you tell it you want
> debug mode, the only thing it does is force CFLAGS to '-O -march=i386'
> and not strip the binaries itself - this of course failed dismally when
> you tried to enable debugging on non-x86 platforms.

Actually kde (and as such most kde apps) does all kinds of awkward stuff in 
it's configure script too with respect to adding the "--enable-debug" flag. 
Although it mostly involves making the compiler extremely noisy, and forcing 
in "-g" flags.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Donnie Berkholz]

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

Mike Frysinger wrote:
> - we add an emerge flag (say '--debug-build') which adds "nostrip" to FEATURES 
> and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS
> - portage will add sane debug defaults to make.globals (DEBUG_CFLAGS="-O -g" 
> and DEBUG_LDFLAGS="")

I'm having a tough time finding this in the thread -- how can I ensure a
certain group of packages are always built with debugging, if I don't
want my whole box built that way?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] fix binary debug support, part elevenity billion

[Mike Frysinger]

On Tuesday 24 January 2006 17:56, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > - we add an emerge flag (say '--debug-build') which adds "nostrip" to
> > FEATURES and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to
> > DEBUG_LDFLAGS - portage will add sane debug defaults to make.globals
> > (DEBUG_CFLAGS="-O -g" and DEBUG_LDFLAGS="")
>
> I'm having a tough time finding this in the thread -- how can I ensure a
> certain group of packages are always built with debugging, if I don't
> want my whole box built that way?

that would require per-package env:
http://bugs.gentoo.org/show_bug.cgi?id=44796

at which point you would just add 'FEATURES=debug-build' to whatever packages 
you want
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Mike Frysinger]

On Tuesday 24 January 2006 01:44, Brian Harring wrote:
> Might I suggest this one just get shelved for a while?

everything that gets shelved portage way stays that way for *quite* a while

i would be ok with implementing the back end (i.e. FEATURES=debug-build) but 
putting off the front end (i.e. emerge --debug-build)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Brian Harring]

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

On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote:
> On Tuesday 24 January 2006 01:44, Brian Harring wrote:
> > Might I suggest this one just get shelved for a while?
> 
> everything that gets shelved portage way stays that way for *quite* a while

If people don't give a damn about it, yes, that's true.  Not the case 
here.


> i would be ok with implementing the back end (i.e. FEATURES=debug-build) but 
> putting off the front end (i.e. emerge --debug-build)

Front-end doesn't matter, it's the back-end that's the concern.  Clean 
up the backend in stable, and it's fine- hence the "shelve it"; fix 
the backend instead of tagging it half way in.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Mike Frysinger]

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

On Wednesday 25 January 2006 02:26, Brian Harring wrote:
> On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote:
> > i would be ok with implementing the back end (i.e. FEATURES=debug-build)
> > but putting off the front end (i.e. emerge --debug-build)
>
> Front-end doesn't matter, it's the back-end that's the concern.  Clean
> up the backend in stable, and it's fine- hence the "shelve it"; fix
> the backend instead of tagging it half way in.

what exactly is "half way" about the attached patch ?
-mike

[-- Attachment #2: portage-debug-build-backend.patch --]
[-- Type: text/x-diff, Size: 1922 bytes --]

Index: pym/portage.py
===================================================================
--- pym/portage.py	(revision 2604)
+++ pym/portage.py	(working copy)
@@ -1263,6 +1263,23 @@
 			if "usersandbox" in self.features:
 				self.features.remove("usersandbox")
 
+		if "debug-build" in self.features:
+			# the profile should be setting these, but just in case ...
+			if not len(self["DEBUG_CFLAGS"]):
+				self["DEBUG_CFLAGS"] = "-g -O"
+				self.backup_changes("DEBUG_CFLAGS")
+			if not len(self["DEBUG_CXXFLAGS"]):
+				self["DEBUG_CXXFLAGS"] = self["DEBUG_CFLAGS"]
+				self.backup_changes("DEBUG_CXXFLAGS")
+			# replace user vars with debug version
+			for var in ["CFLAGS","CXXFLAGS","LDFLAGS"]:
+				self[var]=self["DEBUG_"+var]
+				self.backup_changes(var)
+			# if user has splitdebug, the debug info will be auto saved for
+			# gdb, otherwise we want to keep the binaries from being stripped
+			if not "splitdebug" in self.features:
+				self.features.append("nostrip")
+
 		self.features.sort()
 		self["FEATURES"] = " ".join(["-*"]+self.features)
 		self.backup_changes("FEATURES")
Index: pym/portage_const.py
===================================================================
--- pym/portage_const.py	(revision 2604)
+++ pym/portage_const.py	(working copy)
@@ -40,7 +40,7 @@
 CONFIG_MEMORY_FILE      = PRIVATE_PATH + "/config"
 
 INCREMENTALS=["USE","USE_EXPAND","USE_EXPAND_HIDDEN","FEATURES","ACCEPT_KEYWORDS","ACCEPT_LICENSE","CONFIG_PROTECT_MASK","CONFIG_PROTECT","PRELINK_PATH","PRELINK_PATH_MASK"]
-STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
+STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","LDFLAGS","DEBUG_CFLAGS","DEBUG_CXXFLAGS","DEBUG_LDFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
 EBUILD_PHASES			= ["setup","unpack","compile","test","install","preinst","postinst","prerm","postrm"]
 
 EAPI = 0