Home Original page

ia64 status

Jim Wilson wilson@cygnus.com
Mon Feb 12 17:01:00 GMT 2001 
>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
More information about the Binutils mailing list