Re: [PATCHv2] Switch to more standard debuginfo generation

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

 



On Thu, Apr 13, 2017 at 06:59:38PM -0700, Laura Abbott wrote:
> >> 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.

Found the issue and posted a patch upstream:
http://lists.rpm.org/pipermail/rpm-maint/2017-April/005441.html
That makes sure the minisymtab support skips kernel modules, which
is what generated the errors.

> > 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 :(

You need rpmbuild/debugedit to NOT touch build-ids ever. I wrote a
patch for that so when a package sets %global _no_recompute_build_ids 1
it will not do that. Patch also submitted upstream:
http://lists.rpm.org/pipermail/rpm-maint/2017-April/005442.html

With that the above does match for me.

When upstream accepts both patches I will add them to the fedora rpm.
If you are interested in testing with them you can find a scratch build
here: https://koji.fedoraproject.org/koji/taskinfo?taskID=19029567

> 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 

I think it would be really nice if we could drop the AFTER_LINK patch
it looks really intrusive and messy. I think we can drop it with the
above two patches to rpm. Then there are only 2 issues left as far as
I can see:

1) The kbuild-AFTER_LINK.patch generated a file that contained vmlinux
   buildid in $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/vmlinux.id
   With the _no_recompute_build_ids setting that should be easy to add
   back with some simple scripting (systemtap seems to check that file).
   eu-readelf -n vmlinux | grep "Build ID" | awk '{print $NF}' > vmlinux.id

2) The build-id symlinks for the kernel modules are not there.
   But... This is already broken in rawhide. I "fixed" rpmbuild to
   generate those after the file list was generated instead of through
   find-debuginfo.sh. This is too late for the kernel because it will
   xz compress all .ko files and rpmbuild doesn't know it should handle
   .ko.xz files too. Surprisingly this is already partly broken in f25.
   The build-id symlinks are there, but they point to non-existing files
   because after the symlink was created to the .ko file the file gets
   compressed to .ko.xz. I am slightly surprised this hasn't broken
   more things like systemtap which should rely on the build-ids. But it
   might fall back to finding the modules by name.

   Anyway, this is something that was broken without the AFTER_LINK patch
   removal. So it needs a separate fix. I think I know a trick. Instead
   of just compressing each .ko file with xz we should add a script that
   at the same time generates the symlinks. I'll try to come up with a
   patch for that.

Cheers,

Mark
_______________________________________________
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