Jim Wilson
Sat Jul 24 01:00:00 GMT 2004

On Thu, 2004-07-22 at 10:12, H. J. Lu wrote:
> The current linker/assembler don't handle SHF_LINK_ORDER right. Linker
> never tries to preserve it at all. IA64 uses section name for
> SHT_IA_64_UNWIND, which has SHF_LINK_ORDER. It doesn't work with
> multiple text sections with the same same.

In general, I think this is an improvement.  Saving a pointer to the
text section in the assembler is much better than trying to deduce it in
the linker from section names.

However, I have a number of questions that came up while looking at this
1) The gABI says that SHF_LINK_ORDER causes sh_info to be set.  But you
are setting sh_link.  This seems wrong.
2) Despite the comments in the code, I can't find anyplace in the IA-64
psABI or the IA-64 SCRA that clearly says we have to set SHF_LINK_ORDER
and/or sh_link.  The psABI just refers to the SCRA, and the SCRA says
nothing about section header contents.  My copies are up to date
according to the Intel developer web site.  Can you point to anywhere
where this is documented?
3) The comments imply that HPUX got it wrong by setting sh_info, but
HPUX seems to be the right one, as it agrees with the gABI.  It looks
like we got it wrong when we thought sh_link had to be set at all.  We
can probably drop all this stuff about sh_link and HPUX, and just set
sh_info as the gABI says to.
4) The ia64_elf_section_change_hook patch looks wrong.  You are
unconditionally setting elf_linked_to_section, which might overwrite a
previous value set by start_unwind_section.  Why do you need this?  If
it is needed, then it should be somehow conditional on it not already
being set, such as the byteorder setting is already done.
5) For the elf.c change, I haven't tried to figure out if it is right
except as mentioned above that setting sh_link is wrong, as it should be
setting sh_info.  If "if" part looks fine.  The "else" part is using bfd
stuff that I am unfamiliar with.  I would need some kind of testcase to
be able to figure out what it is doing.
Jim Wilson, GNU Tools Support,

More information about the Binutils mailing list