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 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.
> 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.
> 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:
x.o
Description: Binary data
Attachment:
y.o
Description: Binary data
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |