[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections

[nickc at redhat dot com]

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

--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
H Ali,

> This fix seems to be giving the section a pass based
> on its section type being in the OS-specific range.

Correct.

> That would work, but is there a reason to not simply
> translate any non-zero sh_link?

Yes - for OS and Application specific sections the BFD library
does not know the meaning/interpretation of the sh_link and sh_info
fields, so it does not know how to translate them.

The pre-patched code would just set these fields to zero, which is
pretty much guaranteed to be wrong.  The patched code copies the
values from the input binary, which will work provided that all
of the sections from the input binary are preserved in the output
binary.  (Well probably - the sh_link and sh_info fields might be
datestamps or object counts for all we know, so that even preserving
their values is wrong).

If however the binary is being stripped for example, then copying the 
link and info values is probably the wrong thing to do as well.
In this case what possibly should happen is that the code should try 
to work out where the input section whose number matches the sh_info 
or sh_link fields number has been mapped to, and use these new values.
But that presumes that the numbers are section indicies, so it could 
still be wrong.

The truly correct thing to do would be to defer this decision to target
specific code that understands the meaning of these OS specific sections.
But that would require a lot of work...

Cheers
  Nick

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