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 web frontend. Sigh. So I had
> to switch email addresses. Sorry.
>
> Cheers,
>
> Mark
> _______________________________________________
> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
