Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-19 Thread Laura Abbott 

On 04/19/2017 04:22 AM, Mark Wielaard wrote:

On Sun, 2017-04-16 at 20:04 +0200, Mark Wielaard wrote:

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


Both patches were accepted upstream and I added them to the fedora
rawhide rpm package (rpm-4.13.0.1-19.fc27).

Cheers,

Mark


Thanks! I did a test with your scratch build and the results look good.
I'll send a v3 based on that.

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

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-19 Thread Mark Wielaard 
On Sun, 2017-04-16 at 20:04 +0200, Mark Wielaard wrote:
> 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.
> [...]
> 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

Both patches were accepted upstream and I added them to the fedora
rawhide rpm package (rpm-4.13.0.1-19.fc27).

Cheers,

Mark
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2] Switch to more standard debuginfo generation

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

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-13 Thread Laura Abbott 
On 04/12/2017 01:16 PM, Mark Wielaard wrote:
> 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 :)
> 

Yeah it doesn't match with my patches, so much for my optimism :(

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

Sounds good.

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

I don't think so as long as everything follows the usual branching
policy.

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 

> 
> Cheers,
> 
> Mark
> 

Thanks,
Laura
___
kernel mailing list --

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-12 Thread Mark Wielaard 
Hi Don,

On Wed, 2017-04-12 at 13:45 -0400, Don Zickus wrote:
> Thanks for responding.  Laura already provided some good feedback.
> I was curious if some of this would correctly for our non-kernel package
> stuff we build.  I might be reading Laura's patch wrong, but I think some of
> the options applied to the kernel _and_ the userspace applications too.

Yes, it would be nice if the user space sub-packages didn't use any of
the "special settings". But at least the splitting of the sub-debuginfo
package needs special handling for now (hopefully not needed in the
future, see below). But the settings should really hurt either. The user
space packages just wouldn't have have all the features they could have.
But the mini symtab and dwz compression for those small tools are IMHO
not major features.

> Also, I was trying to understand Laura's previous patch with the -p changes.
> It looked like the output of the application's debuginfo binaries did not
> match with other programs.  I was curious if you had some thoughts on that
> patch (it was split out of this one; you would have to see the original
> patch to understand).

Yes, that is for the subpackage debuginfo splitting. We are working on
that in a more generic way for all packages, so hopefully that will all
become easier in the future:
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
(Yes, that was originally proposed for Fedora 26, obviously we missed
that...)

Cheers,

Mark
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2] Switch to more standard debuginfo generation

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

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-12 Thread Don Zickus 
On Wed, Apr 12, 2017 at 12:55:34PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Tue, 2017-04-11 at 11:01 -0400, Don Zickus wrote:
> > Mark W.,
> > 
> > Do you have much insight into how the below definitions would interact with
> > the kernel?
> > 
> > > @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
> > >  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
> > >  %if %{with_debuginfo}
> > >  BuildRequires: rpm-build, elfutils
> > > -%define debuginfo_args --strict-build-id -r
> 
> 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.

Hi Mark,

Thanks for responding.  Laura already provided some good feedback.
I was curious if some of this would correctly for our non-kernel package
stuff we build.  I might be reading Laura's patch wrong, but I think some of
the options applied to the kernel _and_ the userspace applications too.


Also, I was trying to understand Laura's previous patch with the -p changes.
It looked like the output of the application's debuginfo binaries did not
match with other programs.  I was curious if you had some thoughts on that
patch (it was split out of this one; you would have to see the original
patch to understand).

Cheers,
Don

> 
> > > +# 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.
> 
> > > +%undefine _find_debuginfo_dwz_opts
> 
> This prevents running dwz (the DWARF compressor) which doesn't work for
> the kernel and kernel modules. The problem is that kernel modules are
> not normal ET_EXEC or ET_DYN, but look like ET_REL object files. object
> files contain relocations between ELF sections that dwz cannot handle.
> It would be nice to fix this because kernel modules are ideal for DWARF
> deduplication. They all contain the same basic debug type information
> that could be shared. eu-strip --reloc-debug-sections (-r, see below)
> could help with this, but hasn't been integrated. I'll try to make some
> time (no promises!) to look at it, because getting dwz working against
> the kernel modules would probably provide a huge saving.
> 
> > > +%undefine _unique_build_ids
> > > +%undefine _unique_debug_names
> > > +%undefine _unique_debug_srcs
> 
> It is somewhat unfortunate these don't work with the kernel build. The
> idea is that the package nvra is used to make all of the above unique
> between all versions of the package/debuginfo.
> 
> 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.
> 
> If you don't have _unique_build_ids you should also set:
> %global _build_id_links alldebug
> to make sure build-ids are only used for the debuginfo packages
> (otherwise your main packages stops being parallel installable, which
> the kernel needs).
> 
> I think _unique_debug_names and _unique_debug_srcs should in theory
> still work. But they aren't very useful if the build-ids aren't unique.
> 
> > > +%global _find_debuginfo_opts -r
> 
> This was specifically designed for the kernel. It makes sure relocations
> between debug sections are removed in ET_REL files. Which normally would
> not be correct if those ET_REL object files would be linked together
> again. But kernel modules are not real/normal object files. It should
> save a couple of 100MBs when installing the debuginfo for the .ko files.
> (As said above we really should figure out a way to combine this with
> dwz processing so we can safe even more space.)
> 
> > > +%global _missing_build_ids_terminate_build 1
> 
> Yes please. It should show if any ELF file rpm processes doesn't have a
> build-id, which would be a bug in the toolchain.
> 
> > I am only poking you because it seems like you spent a lot of time cleaning
> > up some of the rpm macros in the rpm pkg.
> 
> Thanks. I am really interested in this. I did see one of the earlier
> patches, but missed that I had been CCed on the followups. My email
> setup is a bit of a mess currently. My employer recently decided on
> short notice that my engineering group didn't need normal email, removed
> all our filters and forced us to adopt a "email provider" that
> "helpfully" removes any emails it believes you have already received and
> that hides everything behind a proprietary

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-12 Thread Laura Abbott 
On 04/12/2017 03:55 AM, Mark Wielaard wrote:
> Hi,
> 
> On Tue, 2017-04-11 at 11:01 -0400, Don Zickus wrote:
>> Mark W.,
>>
>> Do you have much insight into how the below definitions would interact with
>> the kernel?
>>
>>> @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
>>>  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
>>>  %if %{with_debuginfo}
>>>  BuildRequires: rpm-build, elfutils
>>> -%define debuginfo_args --strict-build-id -r
> 
> 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.

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

>>> +%undefine _find_debuginfo_dwz_opts
> 
> This prevents running dwz (the DWARF compressor) which doesn't work for
> the kernel and kernel modules. The problem is that kernel modules are
> not normal ET_EXEC or ET_DYN, but look like ET_REL object files. object
> files contain relocations between ELF sections that dwz cannot handle.
> It would be nice to fix this because kernel modules are ideal for DWARF
> deduplication. They all contain the same basic debug type information
> that could be shared. eu-strip --reloc-debug-sections (-r, see below)
> could help with this, but hasn't been integrated. I'll try to make some
> time (no promises!) to look at it, because getting dwz working against
> the kernel modules would probably provide a huge saving.
> 
>>> +%undefine _unique_build_ids
>>> +%undefine _unique_debug_names
>>> +%undefine _unique_debug_srcs
> 
> It is somewhat unfortunate these don't work with the kernel build. The
> idea is that the package nvra is used to make all of the above unique
> between all versions of the package/debuginfo.
> 

These were working from what I could see, there was just some
discussion about why we didn't have it for everything so I went
with a smaller change first.

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

I'm really tempted to just throw this patch in and see what happens
but I also don't want to completely break anything unless I have
to.

> If you don't have _unique_build_ids you should also set:
> %global _build_id_links alldebug
> to make sure build-ids are only used for the debuginfo packages
> (otherwise your main packages stops being parallel installable, which
> the kernel needs).
> 

Yes, that's still there after you suggested it before.

> I think _unique_debug_names and _unique_debug_srcs should in theory
> still work. But they aren't very useful if the build-ids aren't unique.
> 
>>> +%global _find_debuginfo_opts -r
> 
> This was specifically designed for the kernel. It makes sure relocations
> between debug sections are removed in ET_REL files. Which normally would
> not be correct if those ET_REL object files would be linked together
> again. But kernel modules are not real/normal object files. It should
> save a couple of 100MBs when installing the debuginfo for the .ko files.
> (As said above we really should figure out a way to combine this with
> dwz processing so we can safe even more space.)
> 
>>> +%global _missing_build_ids_terminate_build 1
> 
> Yes please. It should show if any ELF file rpm processes doesn't have a
> build-id, which would be a bug in the toolchain.
> 
>> I am only poking you because it seems like you spent a lot of time cleaning
>> up some of the rpm macros in the rpm pkg.
> 
> Thanks. I am really interested in this. I did see one of the earlier
> patches, but missed that I had been CCed on the followups. My email
>

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-12 Thread Mark Wielaard 
Hi,

On Tue, 2017-04-11 at 11:01 -0400, Don Zickus wrote:
> Mark W.,
> 
> Do you have much insight into how the below definitions would interact with
> the kernel?
> 
> > @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
> >  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
> >  %if %{with_debuginfo}
> >  BuildRequires: rpm-build, elfutils
> > -%define debuginfo_args --strict-build-id -r

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.

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

> > +%undefine _find_debuginfo_dwz_opts

This prevents running dwz (the DWARF compressor) which doesn't work for
the kernel and kernel modules. The problem is that kernel modules are
not normal ET_EXEC or ET_DYN, but look like ET_REL object files. object
files contain relocations between ELF sections that dwz cannot handle.
It would be nice to fix this because kernel modules are ideal for DWARF
deduplication. They all contain the same basic debug type information
that could be shared. eu-strip --reloc-debug-sections (-r, see below)
could help with this, but hasn't been integrated. I'll try to make some
time (no promises!) to look at it, because getting dwz working against
the kernel modules would probably provide a huge saving.

> > +%undefine _unique_build_ids
> > +%undefine _unique_debug_names
> > +%undefine _unique_debug_srcs

It is somewhat unfortunate these don't work with the kernel build. The
idea is that the package nvra is used to make all of the above unique
between all versions of the package/debuginfo.

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.

If you don't have _unique_build_ids you should also set:
%global _build_id_links alldebug
to make sure build-ids are only used for the debuginfo packages
(otherwise your main packages stops being parallel installable, which
the kernel needs).

I think _unique_debug_names and _unique_debug_srcs should in theory
still work. But they aren't very useful if the build-ids aren't unique.

> > +%global _find_debuginfo_opts -r

This was specifically designed for the kernel. It makes sure relocations
between debug sections are removed in ET_REL files. Which normally would
not be correct if those ET_REL object files would be linked together
again. But kernel modules are not real/normal object files. It should
save a couple of 100MBs when installing the debuginfo for the .ko files.
(As said above we really should figure out a way to combine this with
dwz processing so we can safe even more space.)

> > +%global _missing_build_ids_terminate_build 1

Yes please. It should show if any ELF file rpm processes doesn't have a
build-id, which would be a bug in the toolchain.

> I am only poking you because it seems like you spent a lot of time cleaning
> up some of the rpm macros in the rpm pkg.

Thanks. I am really interested in this. I did see one of the earlier
patches, but missed that I had been CCed on the followups. My email
setup is a bit of a mess currently. My employer recently decided on
short notice that my engineering group didn't need normal email, removed
all our filters and forced us to adopt a "email provider" that
"helpfully" removes any emails it believes you have already received and
that hides everything behind a proprietary web frontend. Sigh. So I had
to switch email addresses. Sorry.

Cheers,

Mark
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2] Switch to more standard debuginfo generation

2017-04-11 Thread Don Zickus 
On Mon, Apr 10, 2017 at 06:22:06PM -0700, Laura Abbott wrote:
> 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.
> ---
> This is a slightly reduced version of the previous patch. It keeps the 
> existing
> behavior by using the standard find-debuginfo.sh call with the proper 
> undefines.

Thanks Laura!  Sorry about the previous version.

Acked-by: Don Zickus 


Mark W.,

Do you have much insight into how the below definitions would interact with
the kernel?

> @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
>  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
>  %if %{with_debuginfo}
>  BuildRequires: rpm-build, elfutils
> -%define debuginfo_args --strict-build-id -r
> +# Most of these should be enabled after more investigation
> +%undefine _include_minidebuginfo
> +%undefine _find_debuginfo_dwz_opts
> +%undefine _unique_build_ids
> +%undefine _unique_debug_names
> +%undefine _unique_debug_srcs
> +%global _find_debuginfo_opts -r
> +%global _missing_build_ids_terminate_build 1
>  %endif

I am only poking you because it seems like you spent a lot of time cleaning
up some of the rpm macros in the rpm pkg.

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