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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
