This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ia64 status
- To: binutils at sources dot redhat dot com
- Subject: Re: ia64 status
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Mon, 12 Feb 2001 17:05:23 -0800
>What's the status of ia64 support in the 2.11 branch and the HEAD at the
>moment? Are there still outstanding issues that should delay a release?
It works well enough to build all major linux distributions.
There are issues, but you may not want to delay a 2.11 release because of
them. It could be months before all of the known issues are fixed.
Immediate problems:
- There are bugs in the dependency violation checking support. This is a
correctness issue, so it is important to fix. However, I can't guarantee
to have it fixed anytime soon. I currently have patches for about 15 bugs,
including some behavioural changes. I have not tested the patches yet. I
have not written testsuite support yet. I have not fixed the testsuite to
deal with behavioural changes. I have about 5 more bugs to fix, one of
which will require a partial redesign; I'm leaving that one for last.
This development work is stalled because support/maintenance work is taking
up all of my time at the moment.
- There are a number of assembler and linker testsuite failures that HJ has
been commenting on. I had been ignoring these because I'm still trying to
fix bugs that users are reporting, which I consider more important than
testsuite failures. But since HJ is analyzing them and reporting them, I've
been looking at some of them. Most of the testsuite failures are pretty
innocuous, but some of them are ones that users may eventually stumble over.
- HJ has been adding patches to the mainline sources, but not to the 2.11
branch. I was puzzled over this for a while, until I noticed that HJ
recently announced his own 2.10 based binutils release. So that explains
why he didn't care whether the patches were in 2.11. We may want to move
some of the HJ patches from mainline onto the branch.
- I'm still getting bug reports of problems using GNU ld with the Intel
compiler. Unfortunately, Intel is often unwilling to give me testcases, and
hasn't given me a copy of their compiler either, so getting this working is
a long slow process. The current problem is that the gp value is wrong
sometimes. This has been a problem for several months, but I have no
testcase. Current suggestion from Intel is that we are setting the gp
value first, and then resizing sections, and if there is a lot of resizing
going on, then the gp can end up out-of-range after the section resizing
is done.
Less immediate problems:
- Jes Sorensen of LinuxCare is working on gprof patches for IA-64. Some
of them include fixes for 32-bit-x-64-bit crosses. There are also glibc
changes required, though, so just having the gprof patches isn't enough.
- The linker is supposed to automatically handle out-of-range calls, but
this is handled via linker relaxation, forcing the user to manually specify
-Wl,-relax for large binaries.
- There are syntax differences between the Intel and GNU assemblers. Some of
this is sloppiness in the GNU port. Some of this problems with the Intel
documentation. Some of this is stuff that hasn't been implemented yet in
the GNU port, and some of that is stuff we don't want to implement.
- The assembler has an arbitrary restriction of 2^15 for alignment. See
s_align in gas/read.c. IA-64 supports 64k page sizes, and thus requires
the ability to specify alignments of 2^16 bytes. 64k page sizes do not yet
work though, because of kernel bugs (actually driver bugs I think).
Long term problems:
- The ia64 binutils port needs to be rechecked against the documentation.
There have been a lot of documentation changes since the port was originally
written, and I don't think that all of them have been reflected in the
binutils port yet.
- The Intel compiler, and hence the IA-64 ABI, uses more of ELF than binutils
implements. COMDAT sections, and SHF_LINK_ORDER in particular are problems.
- Currently gas allows arbitrary unstructured code, random section switching
inside functions, emitting code outside functions, etc. The IA-64 assembler
has a number of features that would work much better if we only allowed
structured assembly code: bundling, dependency violation checking, unwind
info generation, and dwarf2 line number generation. This will require
implementing some new directives to support cross-section allocation, and
rewriting parts of the linux kernal and glibc to use structured assembly.
Jim