On 04/05/2017 07:52 AM, Don Zickus wrote: > On Tue, Apr 04, 2017 at 02:36:48PM -0700, Laura Abbott wrote: >> From: Laura Abbott <labbott@xxxxxxxxxx> >> >> Once upon a time, the kernel needed a lot of special handling to >> generate proper debuginfo as the kernel was ahead in technology. These >> days, rpm has improved debuginfo support. The kernel has not kept up >> with this and it's forward looking calls are now out of date. Switch to >> more standard invocations of debuginfo calls. >> --- >> Bringing this out from the previous thread. This drops the special invocations >> of find-debuginfo.sh and debugedit. The results seem to be reasonable as far >> as I can tell. > > > Looking at the /usr/lib/rpm/macros and the find_debuginfo stuff in > particular, those pieces of your patch makes sense to drop and replace with > the find_debuginfo_opts[1]. > > I am curious about the AFTER_LINK patch. What is the reason to drop it? > The patch probably needs to be dropped as either stale or integrated > differently upstream, just thought it would be nice to have it documented. > The purpose of AFTER_LINK was to run the debugedit command. If we're running the standard find-debuginfo.sh, it calls debugedit already so there should be no reason to need the command at all. > > Can I assume your testing was install the debuginfo package and have an > application like gdb or crash read in the symbols to verify the contents? > Yes, that's roughly what I did. > > I think this patch is a good direction forward, just a little nitpick in > [1]. > > Cheers, > Don > > > [1] - Adding the VERSION and RELEASE stuff to find_debuginfo_opts must have > been painful. It also makes it hard to read. I was curious if a macro > would work there, where we pass a list of files and the macro spits out the > files with the VERSION, RELEASE, _arch, _debug junk appended to it? > > This might make it easier to add to later and maintain? > > It's really not pretty, I spent at least a full day figuring out the regexes because I had no idea how they work. I'm sorely tempted to put some ascii art warning of the horrors within. More macros might help things, I'll see what I can do. What I'd really like is a find-debuginfo.sh flag to add the buildid automatically for the filtering. This might turn into a feature request or a patch if I get around to it. Thanks, Laura _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
