home bbs files messages ]

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