Re: [PATCHv2] Switch to more standard debuginfo generation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/12/2017 01:16 PM, Mark Wielaard wrote:
> On Wed, 2017-04-12 at 10:20 -0700, Laura Abbott wrote:
>> On 04/12/2017 03:55 AM, Mark Wielaard wrote:
>>> I am happy you seem able to use the defines instead of having to
>>> override the whole find-debuginfo call. Please let me know if there are
>>> other defines you need/want.
>>>
>>
>> I brought this up in the previous version but a macro for the
>> default arguments to --ver-rel and --unique-debug-arch would
>> be useful for packages like kernel that do filtering with
>> -p. My previous solution required knowing what the arguments
>> are to filter.
> 
> Aha. I see what you are doing. You are creating separate debuginfo file
> lists for the separate subpackages. And with unique debug name it gets
> hard to predict which .debug file names to match.
> 
> The good news is that we are working on doing that automagically from
> rpmbuild (and then you also get a separate debugsources package). But I
> have to see if it will match your specific split.
> 
> For now I would indeed recommend to turn off _unique_debug_names and
> _unique_debug_srcs to not have to rely on the exact ver-rel-arch triple
> it will generate.
> 
>>>>> +# Most of these should be enabled after more investigation
>>>>> +%undefine _include_minidebuginfo
>>>
>>> This prevents adding a .gnu_debugdata section to the binaries which
>>> contains a minisymtab with just the function symbols/addresses. This is
>>> not really relevant for the kernel and modules. If added to
>>> binaries/shared libraries it allows some tools to show function names
>>> for more addresses even without having any debuginfo installed.
>>>
>> This was explicitly causing problems for me when I was working.
>> I think it was because it expected to find dynamic symbols
>> and there were none.
> 
> I'll do a kernel build with it enabled and see if I can figure out why
> it is complaining. The support is a little crude with some fairly
> generic sed matches that I can certainly believe might fail in various
> corner cases.
> 
> It isn't super important I think, so just leave it off for now.
> 
>>> If I understand correctly we "uniqueify" too late assuming nothing
>>> depends on the build-id till we start handling the debuginfo. But the
>>> kernel builds seem to already pick out build-ids to store and embeds
>>> some ELF images in other ELF images and then those build-ids shouldn't
>>> be touched anymore. The AFTER_LINK hack was used to counter this, but it
>>> is somewhat fragile/doesn't really seem to interact correctly anymore.
>>>
>>
>> Thanks for the history. I'm a bit concerned we shouldn't actually
>> be dropping the AFTER_LINK call even if everything seems to be
>> generated okay. Do you have a suggestion of something more specific
>> I can check besides throwing selected modules into gdb?
> 
> One tricky one is the build-id of the vdso. The vdso is inserted in the
> process by the kernel from the kernel image, the debugger can find the
> matching vdso.debug by checking the build-id (and following the
> symlink). You could check if the version found in a running process is
> the same as the one in the vdso.debug file on disk.
> 
> $ eu-unstrip -n -p $$ | grep vdso
> 0x7ffe4a89a000+0x2000 50d1ccf000162361f74a9d7c2ecea856f7881f07@0x7ffe4a89a340 . /usr/lib/debug/usr/lib/modules/3.10.0-514.10.2.el7.x86_64/vdso/vdso.so.debug [vdso: 29852]
> 
> $ eu-readelf -n /usr/lib/debug/lib/modules/`uname -r`/vdso/vdso.so.debug | grep "Build ID"
>     Build ID: 50d1ccf000162361f74a9d7c2ecea856f7881f07
> 
> The above matches, but that is on RHEL. I guess I really should be
> running Fedora :)
> 

Yeah it doesn't match with my patches, so much for my optimism :(

> To be absolutely sure I think you need an explicit way to tell not to
> touch build-ids ever. Currently it is hardcoded to always check and
> update them. There is no way to say that you only want to check they are
> there, but never to update them because you know what you are doing. I
> think it is this way because originally we couldn't rely on the
> toolchain to generate the build-ids correctly, so we would always use
> the debuginfo to calculate one. But now with
> _missing_build_ids_terminate_build you can rely on them I think (well
> not, if we want to uniqueify them against nvra build, but we are not
> doing that for the kernel for now). I'll propose some update upstream so
> you can set _do_not_update_build_ids or something.

Sounds good.

> 
> The only issue with that is that because it is currently hard-coded to
> always update, that would only work for rawhide. Which would make the
> spec file fedora version specific. Is that a problem?

I don't think so as long as everything follows the usual branching
policy.

I'm going to look at a v3 that keeps the AFTER_LINK but still moves
to a more default invocation of find-debuginfo.sh 

> 
> Cheers,
> 
> Mark
> 

Thanks,
Laura
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux