This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Objcopy --only-keep-debug update


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:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-July/005076.html

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
main file.

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
debug file.

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:
http://refspecs.linuxbase.org/elf/gabi4+/ch4.sheader.html#sh_link
(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).
http://refspecs.linuxbase.org/elf/gabi4+/ch4.sheader.html#shf_info_link
(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...".

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]