This is the mail archive of the 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]


On Sat, Jul 24, 2004 at 12:20:40AM -0700, H. J. Lu wrote:
> On Fri, Jul 23, 2004 at 06:00:46PM -0700, Jim Wilson wrote:
> > 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
> > patch.
> > 1) The gABI says that SHF_LINK_ORDER causes sh_info to be set.  But you
> > are setting sh_link.  This seems wrong.
> Yes, it is confusing. The gABI says different things in different
> places. I am trying to get a clarification on that.

The gABI does say sh_link, not sh_info. But HPUX uses sh_info. We only
need to set sh_info for IA64.

> > 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?
> The psABI only says .IA64.unwind section has SHF_LINK_ORDER and nothing
> more. I will ask. I think it makes senses to have it linked to the
> corresponding text section.
> > 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.
> And fix the the gABI.
> > 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.
> For SHT_IA_64_UNWIND section, ia64_elf_section_change_hook is always
> called before link-to section is set in start_unwind_section. It is
> needed by the testcase:
>         .section .IA_64.unwind, "ao", "unwind"
> 	data8 1234
> I added this testcase. Now I am not sure if we should support it at
> all.

I updated my patch to see if elf_linked_to_section has been set before
setting it to text_section.

> > 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.
> It is for "ld -r". Try
> # ld -r -o foo.o x.o x.o
> # readelf -gS foo.o
> Watch for sh_link of SHT_IA_64_UNWIND sections. It isn't set without
> my patch.


Attachment: binutils-link-order-2.patch
Description: Text document

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