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
