[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations

From: wilson at specifix dot com
Subject: [Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
Date: 23 Jun 2006 21:02:08 -0000

------- Additional Comments From wilson at specifix dot com  2006-06-23 21:02 
Subject: Re:  New: ld incorrect applies LTOFF22X/LDXMOV

On Mon, 2006-06-19 at 23:49, cgray at cse dot unsw dot edu dot au wrote:
> ld on ia64 applies LTOFF22X and LDXMOV relocations at linktime, voilating the 
> ABI.

If you read the documentation for LTOFF22X and LDXMOV, it clearly says
that they are link time optimizations.  So there is no ABI violation

However, you do have a point.  There is an internal consistency problem
in the IA-64 ABI.  There is one place where it says segments (not
sections) can be arbitrarily remapped at load time, and there is another
place where it says you can perform a link time optimization that
requires that the relative mapping of gp addressable segments is
preserved at load time.  I see nothing that resolves this conflict. 
This is a bug in the IA-64 ABI that should be reported to the
maintainers of the ABI.

The LTOFF22X/LDXMOV stuff was added late, long after the original ABI
was written.  I suspect that the only people who ever thought that
segment remapping at load time was a good idea was the Monterey project
folks, and that project died a long time ago.  So when people added the
LTOFF22X optimization, they didn't realize that it conflicted with the
old stuff that allowed arbitrary segment remapping.  Unfortunately, the
ABI may not be fixed in a way that helps you, since probably remapping
of segments at load time will be restricted to ensure that the LTOFF22X
reloc continues working.

Meanwhile, it appears that you have the right to remap gp addressable
data segments to different places with the current ABI.  I would
question the wisdom of doing this though.  You risk gp overflows for
large programs.  You disable a link-time optimization, resulting in
slower code.  Either you fail to perform the optimization, or you have
to do it every time the code is loaded instead of just once at link
time.  It seems an unwise choice unless you have an important reason for

But since you insist on doing it, we need to modify the linker to allow
you do to this.  However, there is no way that we are going to change
the behaviour of linux here.  We can add a configuration option for your
OS, so that it can be enabled by default.  This means we need a
configure tuple for your OS, which will then work differently than all
existing ia64 operating systems.  Since you are writing the OS, you may
need to do some of this work yourself.  I don't have your target
configure tuple, nor do I have a copy of your OS to test against, nor do
I know any other details of your OS.

What you will want to do here is add a new vector for your OS to bfd,
and then modify the elfxx-ia64.c file, in the function
elfNN_ia64_relax_section to check the vector, and disable the LTOFF22X
and LDXMOV optimizations when this vector is true.  See for instance how
the ia64_hpux_big_vec stuff works.  Just grep for that and write
something very similar for your target.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]