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 :)
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.
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?
Cheers,
Mark
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
