[LV] Initial port of glibc available for VAX/Linux

[Maciej W. Rozycki]

Hello everybody interested!

 As the outcome of the recent Essen Linux Developers Meeting, following 
four months of development and followed by two weeks of cleaning up and 
bug squishing, I am pleased to announce the initial port of the GNU C 
library, version 2.4, to the VAX/Linux platform.  The port comprises the C 
library itself, the dynamic linker, C run-time startup files as well as 
system headers, and is accompanied by updates to binutils, version 2.19.1, 
and GCC, version 4.1.2, required to build the library as well as make use 
of it.  Additionally some changes are required for the Linux kernel.

 I have made source and binary packages available at my FTP site.  The 
packages have been designed to form a cross-compilation environment, where 
you can build programs for the VAX/Linux target system using your host 
system of choice.  Mine is i386/Linux and hence the binutils and GCC 
binary packages are meant for such a system.  However the corresponding 
source packages can be rebuilt on any host system if need be.  The C 
library itself has no host-system dependency of any kind and hence its 
binary package is compatible with any host system.

 To get the sources, navigate to:

ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/SRPMS/

and download these files:

vax-linux-binutils-2.19.1-8.src.rpm
vax-linux-boot-gcc-4.1.2-19.src.rpm
vax-linux-glibc-2.4-8.src.rpm

To get the binaries, navigate to:

ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/RPMS/

and download these files:

i386/vax-linux-binutils-2.19.1-8.i386.rpm
i386/vax-linux-boot-gcc-4.1.2-19.i386.rpm
noarch/vax-linux-glibc-debug-2.4-8.noarch.rpm
noarch/vax-linux-glibc-devel-2.4-8.noarch.rpm
noarch/vax-linux-glibc-profile-2.4-8.noarch.rpm
noarch/vax-linux-glibc-static-2.4-8.noarch.rpm

I will post changes required for the Linux kernel here shortly.

 Please note the shared objects from the binary glibc package, that is 
ld-2.4.so and libc-2.4.so, and their associated symlinks, can be copied 
and used on the target system.  Their usability was verified this way, by 
building and installing bash, version 3.2.  Statically linked bash was 
tested too.  Both ran correctly to the point of accepting user commands 
and were capable of starting a "Hello World!" program.  Some built-in 
commands were manually tested too.  No readline or history library was 
included in testing, and job control was not tested either (which would be 
useful to verify signal handling) due to the lack of the controlling 
terminal.

 Advance warning: there is an impending temporary closure of the
ftp://ftp.linux-mips.org/ site, which is due to relocation.  The exact 
time when it is going to happen is not known yet.  I will post details 
when available.


 Further development plan (tentative):

 Here is a brief list of things to do in the coming months.  I have tried 
to put the tasks more or less in the order I envisage they might be done.  
Some overlap may happen.

 1. Porting of the rest of the C library.  This includes in particular the 
    maths library (because of the non-IEEE754 FPU VAX provides), the 
    threads (LinuxThreads) library (because of low-level platform 
    dependencies, such as atomic primitives), and all the other libraries 
    and tools included with the distribution.

    I have already started some work on the maths library and the initial 
    port contains most if not all parts required for LinuxThreads.  A full 
    release is expected in several weeks' time.

 2. Porting of platform support (run-time and library, as appropriate) for 
    languages other than C provided by GCC; this includes Ada, C++ and 
    Java.

 3. Adding support for the VAX/Linux platform to GDB.

 4. Implementation of C library functions which due to the lack of 
    platform-specific code for VAX/Linux are provided as non-functional 
    stubs only.

 5. Design and implementation of Native POSIX Thread Library (NPTL) 
    support.  This mostly comprises the Thread Local Storage (TLS) model 
    and the surrounding infrastructure.  All of binutils, GCC and glibc 
    have to be updated simultaneously for TLS to be correctly supported.

 6. Adding profiling support to the C library.  Although profiling 
    libraries are built as a part of glibc compilation, some essential 
    low-level platform glue code is missing making profiling 
    non-functional.

 7. Porting of C library changes to the then current head of glibc and 
    upstream submission of all the changes to glibc as well as NPTL 
    changes for binutils and GCC.

 8. Porting of other libraries or programs utilising handwritten assembly 
    code for performance reasons; this includes at least the GNU Multiple 
    Precision (GMP) library.

 9. Adding long double support -- based on the H-floating format -- both 
    in GCC and in glibc; an update to binutils may be required too.  Right 
    now the type aliases to double.

10. Testing and bug fixing.  There is undoubtedly plethora of bugs hidden 
    waiting to bite.  This task overlaps all the others of course.

I am fairly sure I have missed something to place the list, so I will 
appreciate any suggestions.


 FAQ:

1. Q: Version 2.4 of glibc is a very old one.  Likewise GCC 4.1.2.  What 
      was the reason behind choosing these versions?

   A: These were the last versions I felt like bringing up to date with 
      LinuxThreads support which was been abandoned upsteram a while ago.  
      The reason to insist on LinuxThreads was the ability to get a 
      fully-working environment without the need to design the NPTL ABI 
      beforehand, which is not straightforward for the VAX processor.  
      This way performance evaluation of different approaches to the NPTL 
      ABI will be possible from a full-featured system.

2. Q: What about upstream submission?  Especially given the above.

   A: Patches for binutils shall be submitted straight away, as soon as 
      validation has passed.  Patches for GCC shall follow as they are 
      believed to be compatible with the current trunk.  They have been 
      smoke-tested and will only undergo further testing once a full user 
      environment has become available.  Patches to glibc will be 
      submitted once they have been forward-ported to then current trunk, 
      which is scheduled to after NPTL support has been completed.  
      Porting effort is expected to be moderate due to the 
      self-containment of most of the patches.

3. Q: What about binary compatibility -- is the ABI defined by this 
      release guaranteed to be stable?

   A: Unfortunately the answer is no.  Some internal details may need 
      further tuning, especially as a result of the NPTL effort.  The 
      intent is to get the ABI stabilised by the time patches will be 
      submitted for inclusion with upstream glibc, but let people play 
      with the port immediately so that any problems have a greater chance 
      to be found before submission.

4. Q: Can I help with the port?  How?

   A: Certainly, you are welcome to join the team!

      If you feel competent or would like to learn about the VAX 
      architecture or the core of GNU software, then please pick a task 
      from the list above and let the list know you would like to get into 
      it, or if you have an idea to work on, then please let people on the 
      list know so that someone does not duplicate your effort, which can 
      be rather frustrating.

      If you are not that much into the details of the VAX architecture or 
      the pieces of GNU software, but you have VAX hardware and would love 
      to make a good use of it, than please do make use of the tools and 
      the library, by building your favourite pieces of software, using it 
      and reporting any anomalies seen to the list.

5. Q: Is there a wiki available for the port?

   A: There is none at the moment, although we have a site, at 
      http://linux-vax.sourceforge.net/.  It will undoubtedly be useful to 
      have a wiki at one point, preferably hosted at our site.  If you can 
      help with arranging that, it will be useful.

6. Q: Is this FAQ complete yet?

   A: No, of course not!  Please provide us with further questions and we 
      will strive to work out answers or alternatively please give us an 
      answer and we will try to find a question to fit.


 Acknowledgments:

1. Thanks to Jan-Benedict Glaw for his work on the VAX/Linux kernel as 
   well as invaluable insights in the discussion at the Essen meeting 
   about how the dynamic linker should work.

2. Thanks to Martin 'Joey' Schulze for organising the last Essen meeting, 
   as well as all the previous meetings.

3. Thanks to CodeSourcery for keeping me busy outside my free time.

4. Thanks to all the people who have supported me with this effort -- you 
   know who you are!


 If you have any questions or comments, then please do not hesitate to 
contact me, cc-ing the list if appropriate.

  Maciej
_______________________________________________
Linux-Vax mailing list
Linux-Vax at mail.pergamentum.com
http://mail.pergamentum.com/mailman/listinfo/linux-vax