This is the mail archive of the binutils@sources.redhat.com 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. > H.J.
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] |