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
