Re: [PATCH] objcopy --only-keep-debug vs SHT_NOTE

[Roland McGrath <roland at redhat dot com>]

In elfutils we create the stripped and separate debug files in a single
operation (a strip option).  That makes it much clearer to define the debug
file as containing everything that was removed from the stripped file, and
that's how we describe it.  More or less, the stripped file loses all the
allocated sections, and so that's what it is (the symtab story makes it
more complex than this in reality).  However, we always had an exception
for notes, which are preserved in the stripped file even when unallocated,
and for .gnu.warning.* sections (which probably would have been SHT_NOTE
sections or another special sh_type value if we'd invented the feature in a
purely ELF-centric world originally).  To me, it is not at all unnatural to
add another SHT_NOTE exception, i.e. the recent (unreleased) change to copy
all SHT_NOTE sections into the debug file.

Given the name of the option and the style of the objcopy program's
interface, I don't object in the abstract to Alan's rationale that a
separate option should control something not predicated on SEC_DEBUGGING.
However, my real concern is with the separate debug files that get created
in practice by automated packaging facilities already in use.  Those are
existing scripts that either use eu-strip or use objcopy twice (or objcopy
once and strip once).  Personally, the only such things I am responsible
for and subject to are ones that use eu-strip.  But I would like things
using either elfutils or binutils tools to behave compatibly.  It is only
pragmatic and friendly towards users and packaging infrastructure
maintainers for eu-strip without any new options to continue to do what we
as toolchain maintainers deem the most useful thing for separate debuginfo
generation (even as the details of that expand).  Likewise, it is easiest
on the world if the existing incantation "objcopy --only-keep-debug"
automagically does the new best thing, IMHO.

I don't have any special opinions on the implementation details in
binutils, and defer completely to consensus on those questions.


Thanks,
Roland