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 here. 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 doing. 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. -- Jim Wilson, GNU Tools Support, http://www.specifix.com _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
