9:10 a.m.
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!
--
Petr^2 Spacek
9:28 a.m.
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]
9:43 a.m.
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.
--
Petr^2 Spacek
9:50 a.m.
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
10:10 a.m.
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
10:48 a.m.
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
10:44 a.m.
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^2 Spacek
11:10 a.m.
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
1:03 p.m.
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
2:10 p.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
3:11 p.m.
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
5:22 p.m.
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
7:53 a.m.
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
--
Petr^2 Spacek
3626
days inactive
3659
days old
12 comments
6 participants
participants (6)
-
Adam Jackson -
Andrew Price -
Kevin Kofler -
Petr Spacek -
Reindl Harald -
Simo Sorce