Re: [PATCH] Switch to more standard debuginfo generation

2017-04-10 Thread Laura Abbott 

On 04/07/2017 12:56 PM, Don Zickus wrote:

On Fri, Apr 07, 2017 at 11:16:05AM -0700, Laura Abbott wrote:


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.


That was my fear, it was so painful that attempt at future changes, scares
folks off. :-(

So I just spent some time trying to explore your changes a little bit.  I
thought the VERSION and RELEASE stuff was for the kernel but in fact it
really is only for the tools (perf and kernel-tools).

Looking at current kernel-tools-debuginfo doesn't show any VERSION and
RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
you can only have one version of the tools installed at one time, what does
VERSION and RELEASE provide us?

My thinking is why don't all the other userspace applications need similar
naming?

Sorry for being picky, just trying to understand those particular changes.



Switching over to the default find-debuginfo.sh calls adds the unique
build-ids and unique debug names for the kernel. This gets added for
all files, even the userspace components. It seems like this is the
direction find-debuginfo wants to go in so I figured it was worth the
effort to move to it. I went by what needed the ids although maybe I should
take a closer look.


Ok.  I am still trying to wrap my head around your answer.  I think my
confusion comes from looking at current debuginfo output and seeing
.build-id in there currently.

Using kernel version 4.10.8-100.fc24

#rpm -ql kernel-debuginfo |less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/00
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a.debug
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528.debug


#rpm -ql kernel-tools-debuginfo|less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/0e
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7.debug
/usr/lib/debug/.build-id/17
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b.debug



I see unique .build-id stuff already there.



That may be because the kernel has the legacy option set

%global _build_id_links alldebug


Now comparing your scratch build with say glibc-debuginfo or rpm-debuginfo
info, I noticed your scratch build appends a VERSION-RELEASE to every binary
name, whereas the other packages do not.  On the flip side, the other two
packages do add a /usr/src/debug/-VERSION-RELEASE/...source files... ,
which the kernel-tools and perf does not.


So I was trying to investigate some of this stuff and noticed that Kyle went
down this road a couple of years ago, which Josh reverted the next day  in
006e9acec2708eb48b148b3f1ed3cb8e89107447.  This looks similar to your work.

It seemed to have broken on a 'fedpkg local' for some reason. :-(

And then Mark did some magic symlink cleanup in the rpm macros last year,
which leads me to wonder, if we can just remove all that ugly '-p' stuff
entirely.


The -p stuff isn't related to symlinking, it's for separating everything
out into separate debuginfo subpackages so I think we'd need that anyway



Of course, I was going to play around with this by short circuiting the
kernel build and only build kernel-tools and perf, but my laptop was
spitting out kernel config errors with 'make oldconfig' for some reason and
bypassing that lead to bizarre EXTRA_CFLAGS macro expansion problems with
perf.  So I failed there. :-(


But my initial thought was to see what happens in the binary images when all
that stuff is ripped out and see if /usr/src/debug magically reappears in
kernel-tools and perf.



At the same time, maybe it makes sense to split this patch in half.  Commit
the parts we agree on and then continue hacking on this part to include a
little later?


Yes, that sounds like a good approach. I'll disable the VERSION-RELEASE 
stuff for now and we can see about that later.




I could be completely missing something and my thoughts will fail miserably.
But at the same time Mark looks willing to help hack find-debuginfo.sh to
possible help the kernel?  Worth utilizing? :-)

Thoughts?

Cheers,
Don





Some of this comes back to the problem that the kernel repo doesn't
just have the kernel, it has a bunch of other userspace tools that should
really be a separate repo. As a result we have to keep a bunch of
stuff in the kernel.spec and treat it as a homogeneous project.
Nobody

Re: [PATCH] Switch to more standard debuginfo generation

2017-04-07 Thread Don Zickus 
On Fri, Apr 07, 2017 at 11:16:05AM -0700, Laura Abbott wrote:
> >>
> >> 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.
> > 
> > That was my fear, it was so painful that attempt at future changes, scares
> > folks off. :-(
> > 
> > So I just spent some time trying to explore your changes a little bit.  I
> > thought the VERSION and RELEASE stuff was for the kernel but in fact it
> > really is only for the tools (perf and kernel-tools).
> > 
> > Looking at current kernel-tools-debuginfo doesn't show any VERSION and
> > RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
> > you can only have one version of the tools installed at one time, what does
> > VERSION and RELEASE provide us?
> > 
> > My thinking is why don't all the other userspace applications need similar
> > naming?
> > 
> > Sorry for being picky, just trying to understand those particular changes.
> > 
> 
> Switching over to the default find-debuginfo.sh calls adds the unique
> build-ids and unique debug names for the kernel. This gets added for
> all files, even the userspace components. It seems like this is the
> direction find-debuginfo wants to go in so I figured it was worth the
> effort to move to it. I went by what needed the ids although maybe I should
> take a closer look.

Ok.  I am still trying to wrap my head around your answer.  I think my
confusion comes from looking at current debuginfo output and seeing
.build-id in there currently.

Using kernel version 4.10.8-100.fc24

#rpm -ql kernel-debuginfo |less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/00
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a.debug
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528.debug


#rpm -ql kernel-tools-debuginfo|less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/0e
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7.debug
/usr/lib/debug/.build-id/17
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b.debug



I see unique .build-id stuff already there.

Now comparing your scratch build with say glibc-debuginfo or rpm-debuginfo
info, I noticed your scratch build appends a VERSION-RELEASE to every binary
name, whereas the other packages do not.  On the flip side, the other two
packages do add a /usr/src/debug/-VERSION-RELEASE/...source files... ,
which the kernel-tools and perf does not.


So I was trying to investigate some of this stuff and noticed that Kyle went
down this road a couple of years ago, which Josh reverted the next day  in
006e9acec2708eb48b148b3f1ed3cb8e89107447.  This looks similar to your work.

It seemed to have broken on a 'fedpkg local' for some reason. :-( 

And then Mark did some magic symlink cleanup in the rpm macros last year,
which leads me to wonder, if we can just remove all that ugly '-p' stuff
entirely.

Of course, I was going to play around with this by short circuiting the
kernel build and only build kernel-tools and perf, but my laptop was
spitting out kernel config errors with 'make oldconfig' for some reason and
bypassing that lead to bizarre EXTRA_CFLAGS macro expansion problems with
perf.  So I failed there. :-(


But my initial thought was to see what happens in the binary images when all
that stuff is ripped out and see if /usr/src/debug magically reappears in
kernel-tools and perf.



At the same time, maybe it makes sense to split this patch in half.  Commit
the parts we agree on and then continue hacking on this part to include a
little later?

I could be completely missing something and my thoughts will fail miserably.
But at the same time Mark looks willing to help hack find-debuginfo.sh to
possible help the kernel?  Worth utilizing? :-)

Thoughts?

Cheers,
Don



> 
> Some of this comes back to the problem that the kernel repo doesn't
> just have the kernel, it has a bunch of other userspace tools that should
> really be a separate repo. As a result we have to keep a bunch of
> stuff in the kernel.spec and treat it as a homogeneous project.
> Nobody has put in the work to fight for moving stuff out of the kernel
> repo so alas we deal with what's there.
> 
> > The rest of the patch looks fine to me.
> > 
> 
> Thanks, I really appreciate getting a review on this.
> 
> > Cheers,
> > Don
> > 
> >>
> >> Thanks,
> >> Laura
> >>

Re: [PATCH] Switch to more standard debuginfo generation

2017-04-07 Thread Laura Abbott 
On 04/07/2017 08:07 AM, Don Zickus wrote:
> On Thu, Apr 06, 2017 at 12:53:10PM -0700, Laura Abbott wrote:
>> 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 

 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.
> 
> Ok, sounds good.  Thanks!
> 
>>
>>>
>>> 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.
> 
> That was my fear, it was so painful that attempt at future changes, scares
> folks off. :-(
> 
> So I just spent some time trying to explore your changes a little bit.  I
> thought the VERSION and RELEASE stuff was for the kernel but in fact it
> really is only for the tools (perf and kernel-tools).
> 
> Looking at current kernel-tools-debuginfo doesn't show any VERSION and
> RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
> you can only have one version of the tools installed at one time, what does
> VERSION and RELEASE provide us?
> 
> My thinking is why don't all the other userspace applications need similar
> naming?
> 
> Sorry for being picky, just trying to understand those particular changes.
> 

Switching over to the default find-debuginfo.sh calls adds the unique
build-ids and unique debug names for the kernel. This gets added for
all files, even the userspace components. It seems like this is the
direction find-debuginfo wants to go in so I figured it was worth the
effort to move to it. I went by what needed the ids although maybe I should
take a closer look.

Some of this comes back to the problem that the kernel repo doesn't
just have the kernel, it has a bunch of other userspace tools that should
really be a separate repo. As a result we have to keep a bunch of
stuff in the kernel.spec and treat it as a homogeneous project.
Nobody has put in the work to fight for moving stuff out of the kernel
repo so alas we deal with what's there.

> The rest of the patch looks fine to me.
> 

Thanks, I really appreciate getting a review on this.

> Cheers,
> Don
> 
>>
>> Thanks,
>> Laura
>> ___
>> kernel mailing list -- kernel@lists.fedoraproject.org
>> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Switch to more standard debuginfo generation

2017-04-07 Thread Don Zickus 
On Thu, Apr 06, 2017 at 12:53:10PM -0700, Laura Abbott wrote:
> 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 
> >>
> >> 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.

Ok, sounds good.  Thanks!

> 
> > 
> > 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.

That was my fear, it was so painful that attempt at future changes, scares
folks off. :-(

So I just spent some time trying to explore your changes a little bit.  I
thought the VERSION and RELEASE stuff was for the kernel but in fact it
really is only for the tools (perf and kernel-tools).

Looking at current kernel-tools-debuginfo doesn't show any VERSION and
RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
you can only have one version of the tools installed at one time, what does
VERSION and RELEASE provide us?

My thinking is why don't all the other userspace applications need similar
naming?

Sorry for being picky, just trying to understand those particular changes.

The rest of the patch looks fine to me.

Cheers,
Don

> 
> Thanks,
> Laura
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Switch to more standard debuginfo generation

2017-04-06 Thread Laura Abbott 
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 
>>
>> 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@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] Switch to more standard debuginfo generation

2017-04-05 Thread Don Zickus 
On Tue, Apr 04, 2017 at 02:36:48PM -0700, Laura Abbott wrote:
> From: Laura Abbott 
> 
> 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.


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?


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?


> ---
>  kbuild-AFTER_LINK.patch | 126 
> 
>  kernel.spec |  40 +++
>  2 files changed, 6 insertions(+), 160 deletions(-)
>  delete mode 100644 kbuild-AFTER_LINK.patch
> 
> diff --git a/kbuild-AFTER_LINK.patch b/kbuild-AFTER_LINK.patch
> deleted file mode 100644
> index ab738c6..000
> --- a/kbuild-AFTER_LINK.patch
> +++ /dev/null
> @@ -1,126 +0,0 @@
> -From 649d991ca7737dd227f2a1ca4f30247daf6a7b4b Mon Sep 17 00:00:00 2001
> -From: Roland McGrath 
> -Date: Mon, 6 Oct 2008 23:03:03 -0700
> -Subject: [PATCH] kbuild: AFTER_LINK
> -
> -If the make variable AFTER_LINK is set, it is a command line to run
> -after each final link.  This includes vmlinux itself and vDSO images.
> -
> -Bugzilla: N/A
> -Upstream-status: ??
> -
> -Signed-off-by: Roland McGrath 
> 
> - arch/arm64/kernel/vdso/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso32/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso64/Makefile | 3 ++-
> - arch/s390/kernel/vdso32/Makefile| 3 ++-
> - arch/s390/kernel/vdso64/Makefile| 3 ++-
> - arch/x86/entry/vdso/Makefile| 5 +++--
> - scripts/link-vmlinux.sh | 4 
> - 7 files changed, 17 insertions(+), 7 deletions(-)
> -
> -diff --git a/arch/arm64/kernel/vdso/Makefile 
> b/arch/arm64/kernel/vdso/Makefile
> -index 62c84f7..f44236a 100644
>  a/arch/arm64/kernel/vdso/Makefile
> -+++ b/arch/arm64/kernel/vdso/Makefile
> -@@ -54,7 +54,8 @@ $(obj-vdso): %.o: %.S FORCE
> - 
> - # Actual build commands
> - quiet_cmd_vdsold = VDSOL   $@
> --  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
> -+  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@ \
> -+$(if $(AFTER_LINK),;$(AFTER_LINK))
> - quiet_cmd_vdsoas = VDSOA   $@
> -   cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso32/Makefile 
> b/arch/powerpc/kernel/vdso32/Makefile
> -index 78a7449..c9592c0 100644
>  a/arch/powerpc/kernel/vdso32/Makefile
> -+++ b/arch/powerpc/kernel/vdso32/Makefile
> -@@ -44,7 +44,8 @@ $(obj-vdso32): %.o: %.S FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso32ld = VDSO32L $@
> --  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+ $(if $(AFTER_LINK),; $(AFTER_LINK))
> - quiet_cmd_vdso32as = VDSO32A $@
> -   cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso64/Makefile 
> b/arch/powerpc/kernel/vdso64/Makefile
> -index 31107bf..96aded3 100644
>  a/arch/powerpc/kernel/vdso64/Makefile
> -+++ b/arch/powerpc/kernel/vdso64/Makefile
> -@@ -33,7 +33,8 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso64ld = VDSO64L $@
> --  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+$(if $(AFTER_LINK),; $(AFTER_LINK))
> - 
> - # install commands for the unstripped file
> - quiet_cmd_vdso_install = INSTALL $@
> -diff --git a/arch/s390/kernel/vdso32/Makefile 
> b/arch/s390/kernel/vdso32/Makefile
> -index 6cc9478..94fb536 100644
>

[PATCH] Switch to more standard debuginfo generation

2017-04-04 Thread Laura Abbott 
From: Laura Abbott 

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.
---
 kbuild-AFTER_LINK.patch | 126 
 kernel.spec |  40 +++
 2 files changed, 6 insertions(+), 160 deletions(-)
 delete mode 100644 kbuild-AFTER_LINK.patch

diff --git a/kbuild-AFTER_LINK.patch b/kbuild-AFTER_LINK.patch
deleted file mode 100644
index ab738c6..000
--- a/kbuild-AFTER_LINK.patch
+++ /dev/null
@@ -1,126 +0,0 @@
-From 649d991ca7737dd227f2a1ca4f30247daf6a7b4b Mon Sep 17 00:00:00 2001
-From: Roland McGrath 
-Date: Mon, 6 Oct 2008 23:03:03 -0700
-Subject: [PATCH] kbuild: AFTER_LINK
-
-If the make variable AFTER_LINK is set, it is a command line to run
-after each final link.  This includes vmlinux itself and vDSO images.
-
-Bugzilla: N/A
-Upstream-status: ??
-
-Signed-off-by: Roland McGrath 

- arch/arm64/kernel/vdso/Makefile | 3 ++-
- arch/powerpc/kernel/vdso32/Makefile | 3 ++-
- arch/powerpc/kernel/vdso64/Makefile | 3 ++-
- arch/s390/kernel/vdso32/Makefile| 3 ++-
- arch/s390/kernel/vdso64/Makefile| 3 ++-
- arch/x86/entry/vdso/Makefile| 5 +++--
- scripts/link-vmlinux.sh | 4 
- 7 files changed, 17 insertions(+), 7 deletions(-)
-
-diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
-index 62c84f7..f44236a 100644
 a/arch/arm64/kernel/vdso/Makefile
-+++ b/arch/arm64/kernel/vdso/Makefile
-@@ -54,7 +54,8 @@ $(obj-vdso): %.o: %.S FORCE
- 
- # Actual build commands
- quiet_cmd_vdsold = VDSOL   $@
--  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
-+  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@ \
-+  $(if $(AFTER_LINK),;$(AFTER_LINK))
- quiet_cmd_vdsoas = VDSOA   $@
-   cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $<
- 
-diff --git a/arch/powerpc/kernel/vdso32/Makefile 
b/arch/powerpc/kernel/vdso32/Makefile
-index 78a7449..c9592c0 100644
 a/arch/powerpc/kernel/vdso32/Makefile
-+++ b/arch/powerpc/kernel/vdso32/Makefile
-@@ -44,7 +44,8 @@ $(obj-vdso32): %.o: %.S FORCE
- 
- # actual build commands
- quiet_cmd_vdso32ld = VDSO32L $@
--  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
$(filter %.o,$^)
-+  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
$(filter %.o,$^) \
-+   $(if $(AFTER_LINK),; $(AFTER_LINK))
- quiet_cmd_vdso32as = VDSO32A $@
-   cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
- 
-diff --git a/arch/powerpc/kernel/vdso64/Makefile 
b/arch/powerpc/kernel/vdso64/Makefile
-index 31107bf..96aded3 100644
 a/arch/powerpc/kernel/vdso64/Makefile
-+++ b/arch/powerpc/kernel/vdso64/Makefile
-@@ -33,7 +33,8 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
- 
- # actual build commands
- quiet_cmd_vdso64ld = VDSO64L $@
--  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) $(filter 
%.o,$^)
-+  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) $(filter 
%.o,$^) \
-+  $(if $(AFTER_LINK),; $(AFTER_LINK))
- 
- # install commands for the unstripped file
- quiet_cmd_vdso_install = INSTALL $@
-diff --git a/arch/s390/kernel/vdso32/Makefile 
b/arch/s390/kernel/vdso32/Makefile
-index 6cc9478..94fb536 100644
 a/arch/s390/kernel/vdso32/Makefile
-+++ b/arch/s390/kernel/vdso32/Makefile
-@@ -46,7 +46,8 @@ $(obj-vdso32): %.o: %.S
- 
- # actual build commands
- quiet_cmd_vdso32ld = VDSO32L $@
--  cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@
-+  cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@ \
-+   $(if $(AFTER_LINK),; $(AFTER_LINK))
- quiet_cmd_vdso32as = VDSO32A $@
-   cmd_vdso32as = $(CC) $(a_flags) -c -o $@ $<
- 
-diff --git a/arch/s390/kernel/vdso64/Makefile 
b/arch/s390/kernel/vdso64/Makefile
-index 2d54c18..a0e3e9d 100644
 a/arch/s390/kernel/vdso64/Makefile
-+++ b/arch/s390/kernel/vdso64/Makefile
-@@ -46,7 +46,8 @@ $(obj-vdso64): %.o: %.S
- 
- # actual build commands
- quiet_cmd_vdso64ld = VDSO64L $@
--  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $^ -o $@
-+  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $^ -o $@ \
-+   $(if $(AFTER_LINK),; $(AFTER_LINK))
- quiet_cmd_vdso64as = VDSO64A $@
-   cmd_vdso64as = $(CC) $(a_flags) -c -o $@ $<
- 
-diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
-index d540966..eeb47b6 100644
 a/arch/x86/entry/vdso/Makefile
-+++ b/arch/x86/entry/vdso/Makefile
-@@ -167,8 +167,9 @@ $(obj)/vdso32.so.dbg: FORCE \
- quiet_cmd_vdso