Hello list,
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
Thank you for your time!
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
just don't do that and read compiler warnings the debuginfo package is your smallest problem you just kill security features like D_FORTIFY_SOURCE with -O0
warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
just don't do that
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
and read compiler warnings
Thank you very much for your very helpful advice! :-)
the debuginfo package is your smallest problem
I'm afraid it is not.
you just kill security features like D_FORTIFY_SOURCE with -O0
warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
I think my use case justifies it.
Am 25.04.2014 16:43, schrieb Petr Spacek:
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
just don't do that
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
no but then don't include $CFLAGS $RPM_OPT_FLAGS
and read compiler warnings
Thank you very much for your very helpful advice! :-)
the debuginfo package is your smallest problem
I'm afraid it is not
please look at the whole picture of the FLAGS you are using
you just kill security features like D_FORTIFY_SOURCE with -O0
warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
I think my use case justifies it
but it don't justify incompatible flags IMHO you enter the area of "undefined behavior" with that
-D_FORTIFY_SOURCE=2 is part of the Fedora default flags
On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
but it don't justify incompatible flags IMHO you enter the area of "undefined behavior" with that
Your humble opinion is misguided, building without _FORTIFY_SOURCE is an entirely reasonable thing for an end developer to want to do on their machine, and one we should support. More importantly I can't think of any way it would affect debuginfo construction at all.
My first instinct here would be to vary the compiler. Can you mockbuild this package against F19's toolchain? Does that produce working debuginfo?
- ajax
Am 25.04.2014 17:10, schrieb Adam Jackson:
On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
but it don't justify incompatible flags IMHO you enter the area of "undefined behavior" with that
Your humble opinion is misguided, building without _FORTIFY_SOURCE is an entirely reasonable thing for an end developer to want to do on their machine, and one we should support
sorry, but you misunderstood me
what i said was the combination of -O0 *and* -D_FORTIFY_SOURCE=2 or specifically "$CFLAGS $RPM_OPT_FLAGS -O0"at the same time feels like undefined behavior because that contains a lot of default flags including -D_FORTIFY_SOURCE=2
On 25.4.2014 16:50, Reindl Harald wrote:
Am 25.04.2014 16:43, schrieb Petr Spacek:
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
just don't do that
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
no but then don't include $CFLAGS $RPM_OPT_FLAGS
and read compiler warnings
Thank you very much for your very helpful advice! :-)
the debuginfo package is your smallest problem
I'm afraid it is not
please look at the whole picture of the FLAGS you are using
you just kill security features like D_FORTIFY_SOURCE with -O0
warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
I think my use case justifies it
but it don't justify incompatible flags IMHO you enter the area of "undefined behavior" with that
-D_FORTIFY_SOURCE=2 is part of the Fedora default flags
For the record, replacing
export CFLAGS="$CFLAGS $RPM_OPT_FLAGS"
with
export CFLAGS="-O0 -g"
doesn't fix the problem.
Petr Spacek wrote:
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
IMHO, you should always debug with optimization enabled. GDB can cope quite well with it, and it is the only way to actually debug the real code that gets executed. -O0 makes the code very different from production code, e.g., you can get away with more abuse of undefined behavior (and thus, if that was the cause of the crashes, you won't find them when debugging under -O0). Often, broken code only actually breaks under optimized compilation. This is all the more the case for issues triggered by an updated GCC. Even in those rare cases where the bug really is in GCC, it is often in an optimization pass and thus won't happen under -O0 either.
Kevin Kofler
On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
Petr Spacek wrote:
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
IMHO, you should always debug with optimization enabled. GDB can cope quite well with it,
ha ha ha ha ha ha ha ha ha ha
No, seriously, he's trying something completely reasonable. Maybe think about how to diagnose what's going wrong and fix the bug instead of philosophizing.
- ajax
On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:
On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
Petr Spacek wrote:
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
IMHO, you should always debug with optimization enabled. GDB can cope quite well with it,
ha ha ha ha ha ha ha ha ha ha
Sorry I think you missed a few, I'll add my part.
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA
Kevin, have you ever debugged with -O2 ?
It's more than reasonable to want -O0. At -O2 some code becomes really annoying to follow because gcc will optimize away way too much of it into registers (and gdb will not print you the values you need to see) or will make stepping a nightmare with gdb jumping in an out of the function as it gets inlined and then some stuff moved "out of the original function" and things like that.
I've been more than once in gdb with -O2, it is *not* pretty, nor useful.
debug symbols at -O2 are mostly useful to get backtraces, but if you need to really step through with gdb in some complicated, highly optimizable code, often it does not cut it, you have to rebuild with -O0 to regain debuggability and sanity.
Simo.
On 25/04/14 20:10, Simo Sorce wrote:
On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:
On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
Petr Spacek wrote:
I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions?
IMHO, you should always debug with optimization enabled.
s/debug/test/ IMHO.
Kevin, have you ever debugged with -O2 ?
It's more than reasonable to want -O0. At -O2 some code becomes really annoying to follow because gcc will optimize away way too much of it into registers (and gdb will not print you the values you need to see) or will make stepping a nightmare with gdb jumping in an out of the function as it gets inlined and then some stuff moved "out of the original function" and things like that.
I've been more than once in gdb with -O2, it is *not* pretty, nor useful.
+1
debug symbols at -O2 are mostly useful to get backtraces, but if you need to really step through with gdb in some complicated, highly optimizable code, often it does not cut it, you have to rebuild with -O0 to regain debuggability and sanity.
-Og (new in gcc 4.8) is meant to enable only optimizations which won't confuse gdb but I've not found a need to optimize my code just a little bit while debugging yet, so -O0 is still my --enable-debug flag.
Andy
Simo Sorce wrote:
Kevin, have you ever debugged with -O2 ?
Yes. In fact, almost always.
It's more than reasonable to want -O0. At -O2 some code becomes really annoying to follow because gcc will optimize away way too much of it into registers (and gdb will not print you the values you need to see) or will make stepping a nightmare with gdb jumping in an out of the function as it gets inlined and then some stuff moved "out of the original function" and things like that.
I know the "mad jumping" and "value optimized out" problems very well. You learn to deal with those after the initial annoyance, and it's much better than debugging totally different machine code from the production one.
I've been more than once in gdb with -O2, it is *not* pretty, nor useful.
Strange, me too (in fact, as I wrote above, that's how I normally use GDB), but I find it very useful.
debug symbols at -O2 are mostly useful to get backtraces, but if you need to really step through with gdb in some complicated, highly optimizable code, often it does not cut it, you have to rebuild with -O0 to regain debuggability and sanity.
You just need to get used to the jumping around. After a bunch of times, it stops bothering you.
Kevin Kofler
On 25.4.2014 20:03, Adam Jackson wrote:
Maybe think about how to diagnose what's going wrong and fix the bug instead of philosophizing.
It seems that /usr/lib/rpm/find-debuginfo.sh experts don't read this thread so I have filled bug: https://bugzilla.redhat.com/show_bug.cgi?id=1091989
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Andrew Price -
Kevin Kofler -
Petr Spacek -
Reindl Harald -
Simo Sorce