bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYN


From: ali_swbugzilla at emvision dot com
Subject: [Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections
Date: Mon, 11 Apr 2016 16:27:18 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=19938

--- Comment #7 from Ali Bahrami <ali_swbugzilla at emvision dot com> ---
   I understand your concerns. Our assumption is that sh_link
is always 0, or a section index, while the meaning of sh_info
is  somewhat more variable, and may or may not be. This is
ancient "From New Jersey" code, which is somewhat short of
a proof of correctness. In any event special case handling of
sh_info is clearly necessary.

With that in mind, this proposed fix is a step in the right
direction, but it's not enough, because we really need the
section indexes to be translated correctly for our OSABI
sections. In the examples provided by Rainer for instance,
the sh_link for both of those sections is definitely a section
index, and so in a situation where sections are added or
removed, preserving them without translating them is going to
be wrong, and perhaps even worse that just zeroing.

Can I ask you to add the necessary os-specific translations?
The list is pretty short, and can be found here in Table 13-9
(ELF sh_link and sh_info interpretation):

   
https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#scrolltoc

You will already have the gABI cases covered, so you only need
updates for the SHT_SUNW_ cases. The numeric values for these
types are as follows:

#define SHT_SUNW_ancillary      0x6fffffee
#define SHT_SUNW_cap            0x6ffffff5
#define SHT_SUNW_capinfo        0x6ffffff0
#define SHT_SUNW_symsort        0x6ffffff1
#define SHT_SUNW_tlssort        0x6ffffff2
#define SHT_SUNW_LDYNSYM        0x6ffffff3
#define SHT_SUNW_move           0x6ffffffa
#define SHT_SUNW_COMDAT         0x6ffffffb
#define SHT_SUNW_syminfo        0x6ffffffc
#define SHT_SUNW_verdef         0x6ffffffd
#define SHT_GNU_verdef          SHT_SUNW_verdef
#define SHT_SUNW_verneed        0x6ffffffe
#define SHT_GNU_verneed         SHT_SUNW_verneed
#define SHT_SUNW_versym         0x6fffffff
#define SHT_GNU_versym          SHT_SUNW_versym

It would be correct to preserve and not alter the values
for any other section types in the OS-specific range.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]