Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.os.vms    |    DEC's VAX* line of computers & VMS.    |    264,096 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 263,442 of 264,096    |
|    Waldek Hebisch to All    |
|    Cross gcc targeting VMS    |
|    29 Sep 25 16:17:10    |
      From: antispam@fricas.org              As I wrote in another post I am trying to compile cress gcc targeting       Alpha VMS. In a sense I am in similar situation as Simon. But       I think I made some progress and I collected some information.              First, I think it is worth to be more precise about what is working.       Typicaly programming languages need a compiler and a support       library. My tests indicate that compilers proper for all languages       included in gcc-15, except for D build without errors. Currently       C++ compiler has trouble, compiling some (many) C++ files leads       to compliants from assembler.              Problematic is compilation of support libraries. Currently for me       runtime support libraries for C, Fortran and Objective C build OK.       Building C++ runtime library fails due to compiler problem mentioned       above. Cobol, Go, Modula 2 and Rust runtime libraries have       C++ runtime library as a dependence, so building those libraries       fails. I think that I managed to build part of Ada runtime library       that is written in C, but VMS-specific code in part of Ada runtime       that is written in Ada is removed from reasonably recent gcc versions       (this probably happended around gcc-6.5). Worse, current Ada       backend seem to support only "zero cost exception handing" while       old VMS port seemed to use setjmp-longjmp exception handing.       So probably one needs to write some new VMS-specific code to make       fully working Ada runtime.              So what works? As I wrote I have my own header files. I also       wrote a tool to create fake shared libraries. So I have now set       of libraries that allow linking of C and Fortran programs. Header       file have substantial gaps, they contain what is needed to build       gcc runtime but otherwise miss a lot. Fake libraries have slots       for majority of documented VMS C functions, functions from LIBRTL       and SYS$PUBLIC_VECTORS. There is also bunch of slots for       undocumented functions used by gcc. But majority of positions       in symbol vectors is taken by dummies, so there may be a lot       missing functions. Concerning missing documented functions:       some of them apparently are not functions but macros, some may       use strange renaming tricks. In general each requires specific       attention to find out what happens.              I have now preliminary support for _USE_STD_STAT in my header files.       It uses gcc-specific features (precifically pragma redefine_extname).       I do not know how DEC/HP/VSI handle the issue, but solution adapted       in VMS headers almost surely depends on specific compiler extentions       and needed extention is probably not supported by gcc.              Using my header files and fake libraries I can compile simple C       programs and they work on VMS. I also compiled a simple Fortran       subroutine, calling it from C gives expected effect. ATM I did not       try other languages, but based on experience in other setups I       expect that calling code in other languages will work as long as       that code does not need runtime support.              Now about troubles. VMS C functions use different name at C level       and different in libraries. Moreover, while offically function is       available in "imagelib.olb", actual function is in a different library       and this library is needed for succesful linking. So, one needs       to know real name of a given function and teach gcc to use it.       Fortunately, gcc knows about most VMS C functions. But one may       need to add newer ones. And some functions (like stat) apparently       need handling in header files. To create fake libraries I needed       to know which library defines given function and corresponding       slot number (this info can be extracted from executables calling       the function).              Renaming and GNU compiler/assembler features may cause spurious       errors: runtimes included in gcc in some cases try to provide       replacements for missing "standard" functions. But attempts to       compile a replacement definition for function which is renamed       leads to assembler error. Such attemps at replacemnt are typically       due to mismatch between C headers and libraries, one needs to       make sure that all function which gets renamed are properly       defined in header files (OK, all that gcc runtimes may want to       replace).              Another possible trouble is that in case of missing target features       gcc runtimes may try to compile alternative implementation needing       less features. Unfortunatly, alternative implementations may       easily fail to compile (I observed a few failures of this sort).              When building Fortran runtime I obseved one case of wrong assembly:       generated assembly code references (no existiong) register number 63.       I worked around the problem by loweering optimization level for       affected function. This is troubling, but not too much: AFAICS       such error will be reliably detected by assembler (so will not       lead to wrong object code) and it seem to be rare enough that       workarounds need only little work.              Concerning C++, as I wrote C++ compiler depends on creating aliased       names. There seem to be 3 (or more) cases. One case is data       aliases, in such case '=' construct seem to work OK. Second       case are alternative names for functions, here '==' seem to work.       But apparently there is other case (or cases) where logic       using '=' for data and '==' for functions fails.              In case of Fortran essentialy empty program:               program n        end              pulls in substantial part of Fortran runtime and attempting to run       it leads to failure. VMS message indicates that program is executing       data, ATM I do not know how it gets there. It seems that trouble       happens during runtime initialization, but currently I do not know       which code is run for initialization.              --        Waldek Hebisch              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca