November 2009 - Vax-linux

[LV] wiki
by richard snow 28 Dez '09

28 Dez '09

I would be willing to host a wiki for the project. Currently I have tikiwiki-2.1 installed at http://mypals.info/tikwiki-2.1/index.php but if you had a domain name pointed to my server I could virtual host a separate installation. -- http://mypals.info _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

2 1

[LV] Fully-functional port of glibc available for VAX/Linux
by Maciej W. Rozycki 16 Nov '09

16 Nov '09

Hello everybody interested! I am pleased to announce the availability of a fully-functional 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 with binutils, version 2.20, and updates to 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.20-1.src.rpm vax-linux-boot-gcc-4.1.2-22.src.rpm vax-linux-glibc-2.4-13.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.20-1.i386.rpm i386/vax-linux-boot-gcc-4.1.2-22.i386.rpm noarch/vax-linux-glibc-debug-2.4-13.noarch.rpm noarch/vax-linux-glibc-devel-2.4-13.noarch.rpm noarch/vax-linux-glibc-profile-2.4-13.noarch.rpm noarch/vax-linux-glibc-static-2.4-13.noarch.rpm Changes required for the Linux kernel were posted here recently. For the reference, I have made them available from here too: ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/linux/vax/ Please note the shared objects from the binary glibc-devel package, that is ld-2.4.so, libc-2.4.so, libm-2.4.so, etc., and their associated symlinks, can be copied to and used on the target system. As an additional bonus, the following packages are available: sources: vax-linux-zlib-1.2.3-1.src.rpm SysVinit-2.86-2.src.rpm binaries: noarch/vax-linux-zlib-devel-1.2.3-1.noarch.rpm noarch/vax-linux-zlib-static-1.2.3-1.noarch.rpm vax/SysVinit-2.86-2.vax.rpm The latter is a native VAX/Linux package! :) 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 platform support (run-time and library, as appropriate) for languages other than C provided by GCC; this includes Ada, C++, and Java. Initial investigation indicates Ada may be supported with a small effort and some work is required to support the Java library (exception handling may need to be sorted out while at it). Additionally the FFI (Foreign Function Interface) library requires porting. All the other languages and libraries coming with GCC should work as it is. 2. Adding support for the VAX/Linux platform to GDB. 3. Implementation of C library functions which due to the lack of platform-specific code for VAX/Linux are provided as non-functional stubs only. 4. 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. 5. 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. 6. 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. 7. Porting of other libraries or programs utilising handwritten assembly code for performance reasons; this includes at least the GNU Multiple Precision (GMP) library. 8. 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. 9. 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 on 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 abandoned upstream 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. There are no outstanding binutils patches at the moment. Patches for GCC shall follow as they are believed to be more or less compatible with the current trunk. They have been smoke-tested and will only undergo further testing once a full user environment has become available. GCC patches published back in May have been integrated upstream. Patches developed since then have been submitted and are pending approval. Patches to glibc will be submitted once they have been forward-ported to the 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 are 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. 2. 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(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

3 3

[LV] [PATCH] VAX/Linux: Correct tmake_file setting
by Maciej W. Rozycki 04 Nov '09

04 Nov '09

Hello, This change: 2009-07-01 Maciej W. Rozycki <macro(a)linux-mips.org> * config.gcc (vax-*-linux*): Set tmake_file to vax/t-linux. inadvertently removed generic Linux settings from the vax-linux target Makefile fragment. Probably the most notable impact from this is that crt{begin,end}S.o files are built without -fPIC, which is obviously not what we want. The following fix works for me for --target=vax-linux, emitting correct relocations in the files mentioned and removing shared library static link-time warnings that resulted from the incorrect change. The configuration is not capable enough for regression testing yet. 2009-10-29 Maciej W. Rozycki <macro(a)linux-mips.org> * config.gcc (vax-*-linux*): Keep the original contents of tmake_file while adding vax/t-linux. OK to apply? Maciej gcc-4.5.0-20091029-vax-linux-tmake.patch Index: gcc-4.5.0-20091029-vax-linux/gcc/config.gcc =================================================================== --- gcc-4.5.0-20091029-vax-linux.orig/gcc/config.gcc +++ gcc-4.5.0-20091029-vax-linux/gcc/config.gcc @@ -2503,7 +2503,7 @@ v850-*-*) ;; vax-*-linux*) tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h vax/elf.h vax/linux.h" - tmake_file=vax/t-linux + tmake_file="${tmake_file} vax/t-linux" ;; vax-*-netbsdelf*) tm_file="${tm_file} elfos.h netbsd.h netbsd-elf.h vax/elf.h vax/netbsd-elf.h" _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

2 2

[LV] [PATCH] VAX/Linux: Remove __pic__ and __PIC__ definitions
by Maciej W. Rozycki 03 Nov '09

03 Nov '09

Hello, The __PIC__ and __pic__ macros are now set in generic code and there is no need to fiddle with them in platform configuration. The change below removes the following warnings: <built-in>:0:0: warning: "__PIC__" redefined <built-in>:0:0: note: this is the location of the previous definition <built-in>:0:0: warning: "__pic__" redefined <built-in>:0:0: note: this is the location of the previous definition that were missed when porting the original change from an older version of GCC. Verified with `gcc -E -dD' built for --target=vax-linux to ensure correct behaviour. The configuration is not capable enough for regression testing yet. 2009-10-29 Maciej W. Rozycki <macro(a)linux-mips.org> * config/vax/linux.h (TARGET_OS_CPP_BUILTINS): Don't define __pic__ or __PIC__. OK to apply? Maciej gcc-4.5.0-20091029-vax-linux-pic.patch Index: gcc-4.5.0-20091029-vax-linux/gcc/config/vax/linux.h =================================================================== --- gcc-4.5.0-20091029-vax-linux.orig/gcc/config/vax/linux.h +++ gcc-4.5.0-20091029-vax-linux/gcc/config/vax/linux.h @@ -21,17 +21,7 @@ along with GCC; see the file COPYING3. #undef TARGET_VERSION #define TARGET_VERSION fprintf (stderr, " (VAX GNU/Linux with ELF)"); -#define TARGET_OS_CPP_BUILTINS() \ - do \ - { \ - LINUX_TARGET_OS_CPP_BUILTINS(); \ - if (flag_pic) \ - { \ - builtin_define ("__PIC__"); \ - builtin_define ("__pic__"); \ - } \ - } \ - while (0) +#define TARGET_OS_CPP_BUILTINS() LINUX_TARGET_OS_CPP_BUILTINS() /* We use GAS, G-float double and want new DI patterns. */ #undef TARGET_DEFAULT _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

2 1