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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
