gcc build with -O0 results in corrupted -debuginfo package

[Petr Spacek]

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