This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Objcopy --only-keep-debug update
- From: Mark Wielaard <mjw at redhat dot com>
- To: Nicholas Clifton <nickc at redhat dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 29 Jul 2015 21:00:35 +0200
- Subject: Re: RFC: Objcopy --only-keep-debug update
- Authentication-results: sourceware.org; auth=none
- References: <55B8D362 dot 9070004 at redhat dot com>
On Wed, 2015-07-29 at 14:21 +0100, Nicholas Clifton wrote:
> One problem I did have with this part of the patch was in determining
> which sections should have their sh_link fields preserved. In the
> end I had to encode the section names directly, but I feel that their
> ought to be a better way.
I should prefix this with noting that eu-unstrip only got confused
because the sh_flags weren't preserved. In particular the missing
SHF_INFO_LINK on .plt.rela sections caused it to not match those in the
main and debug file. I have a workaround for that now:
The sh_link and sh_info flags were not matched (which theoretically is
also a bug) but just assumed to be similar to the section indexes in the
I also realize that binutils/bfd handles more than just ELF files and I
know next to nothing about the binutils/bfd implementation. So the
following might all be a little theoretical.
It would be nice if objdump preserved everything (sh_flags, sh_link and
sh_info) though. So tools get a more consistent view of the separate
In theory, for ELF files, the sh_link should always be preserved since
it always contains a section index. Depending on the section type it
points to different sections:
(Missing from that table are the GNU extensions GNU_HASH,
SHT_GNU_versym, SHT_GNU_verdef and SHT_GNU_verneed.)
Note that an ELF file can contain multiple different string or symbol
sections and each section sh_link can point to a different one.
The patch doesn't seem to preserve the ELF sh_info section idx. This is
a bit harder since this isn't done completely consistent in practice. In
theory each section that has a sh_info value that is a section index
should have SHF_INFO_LINK set in sh_flags. But in practice this is not
done for SHT_REL and SHT_RELA sections (except in the .plt.rela case for
some reason). So here the check to see if the sh_info field is a section
index that should be preserved is to see if sh_flags contains
SHF_INFO_LINK or the section type is SHT_REL or SHT_RELA. If it isn't
then the sh_info value isn't a section index (but it would still be good
to preserve the value in the debug file).
(Again missing from that table are the SHT_GNU extensions, but none of
them use sh_info as section index.)
> +Note - the section headers of the stripped sections are preserved,
> +including their sizes, but the contents of the section are set to
> +zero. On some file systems this means that the section contents will
> +not occupy any space on disk.
Does it really matter what the underlying file system is? I think this
last sentence should say "For some object formats..." or specifically
"For ELF files this means...".