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
> 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.
No problem. Thanks for replying.
>
> 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
