[Info-vax] GCC for VMS, was: Re: fortran compiler roadmap?

[Simon Clubley]

On 2013-04-26, Bernard Giroud <bgiroud3 at free.fr> wrote:
> Le 25/04/2013 14:07, Simon Clubley a écrit :
>> On 2013-04-25, gingold at adacore.com <gingold at adacore.com> wrote:
>>> Congrats!
>>
>> Thank you.
>>
>
> Congratulations too! You gave me the desire to tackle the beast again ! 
> (Do you remember our exchange in this newsgroup started 2004-09-09 ?).
>

Not at first, but I did find some of my old postings upon looking.

>> As I wanted to try building a larger program, I tried to use the cross
>> compiler to build binutils in VMS hosted mode. I got through a large
>> part of the process (with mainly header related issues) before ld failed
>> with a internal error in vms-alpha.c while building size.
>>
>> However, it looks like the section of code in vms-alpha.c which failed
>> has been worked on since the version of binutils I am using[*], so I will
>> have another play with it sometime.
>>

I moved past this problem shortly after posting this.

This problem was fixed sometime after binutils version I was using (2.21.1)
and is not present in the current binutils kit. However, using the current
binutils with gcc-4.6.2 causes gas to fail with a missing .end type error
message so I fitted the patch back into 2.21.1 which worked.

>> [*] When building gcc/binutils over the years, I've traditionally liked to
>> stay a couple of versions behind when possible as the issues I trip over
>> tend to have made it to Bugzilla and elsewhere by then.
>>
>> When I started looking at this, it looked like the majority of public
>> commits for VMS Alpha had happened several years ago, so I thought a
>> gcc/binutils from a year or two ago would not make any difference.
>> I'm currently rethinking that given come of the recent commits I've now
>> come across. :-)
>>

The above reasoning has served me well over the years, but I have now moved
to a new base of binutils 2.23.2 and gcc 4.7.3. (I'm not going anywhere
near the rewritten gcc 4.8 until it's had a few versions to settle. :-))

The support for CRTL name mapping in 4.6.2 was been bypassed in some
circumstances so you ended up with both decc$* translated version and
and the original untranslated version in the same object module.

This problem does not exist in 4.7.3; the only problem I've had with CRTL
translation mapping in 4.7.3 is I had to add to the existing map for the
functions which were not in there already.

>
> I'm pretty sure that, given the work already done on Bash, GNV and al.,
> we can have the latest binutils running on Alpha.
>

I spent a bit more time on it this weekend and I have now managed to use
the Linux cross compiler to build binutils as VMS hosted executables. The
binaries I've tried (nm and size) run on Eisner:

$ mcr []nm. --version
GNU nm (GNU Binutils) 2.23.2
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

but they do not run correctly:

$ mcr []nm. hello.o
eisner$dra2:[usr_scratch.][clubley.test]nm.;1: Warning: 'hello.o' is not an ordinary file
$ mcr []nm. hello.exe
eisner$dra2:[usr_scratch.][clubley.test]nm.;1: Warning: 'hello.exe' is not an ordinary file

This specific problem is due to a difference between gcc and the compiler
used to build the DEC C sharable image when using the stat struct. (gcc
code is linked against the DEC C sharable image). The following program,
which uses the problem code from binutils and also a cut down version of
the stat struct illustrates the problem:

============================================================================
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

/* A cut down version of the pragmas and stat structure found in VMS stat.h. */
#  pragma __member_alignment __save
#  pragma __nomember_alignment
struct simon_stat
{
        __dev_t      st_dev;          /* pointer to physical device name */
        __ino16_t    st_ino[3];       /* 3 words to receive fid */
        __mode_t     st_mode;         /* file "mode" i.e. prot, dir, reg, etc. $
        __nlink_t    st_nlink;        /* number of hard links */
        __uid_t      st_uid;          /* from ACP - QIO uic field */
};
#  pragma __member_alignment __restore

off_t get_file_size (const char * file_name)
{
  struct stat statbuf;

  if (stat (file_name, &statbuf) < 0)
    {
      if (errno == ENOENT)
        printf ("'%s': No such file\n", file_name);
      else
        printf ("Warning: could not locate '%s'.  reason: %s",
                   file_name, strerror (errno));
    }
  else if (! S_ISREG (statbuf.st_mode))
    printf ("Warning: '%s' is not an ordinary file\n", file_name);
  else if (statbuf.st_size < 0)
    printf ("Warning: '%s' has negative size, probably it is too large\n",
               file_name);
  else
    return statbuf.st_size;

  return (off_t) -1;
}

main()
	{
	off_t fsize;

	printf("sizeof(struct simon_stat) = %lu\n",
		(unsigned long int) sizeof(struct simon_stat));
	printf("sizeof(struct stat) = %lu\n",
		(unsigned long int) sizeof(struct stat));
	fsize = get_file_size("hello.exe");
	printf("fsize = %lu\n", (unsigned long int) fsize);
	}
============================================================================

The following is from a terminal session on Eisner.

The first statt.exe was cross compiled under Linux using the C headers
from Eisner and transferred to Eisner using sftp. The second statt.exe,
as you can see, was compiled and run on Eisner.

$ r statt    
sizeof(struct simon_stat) = 20
sizeof(struct stat) = 69
Warning: 'hello.exe' is not an ordinary file
fsize = 4294967295
$ cc statt
$ link statt
$ r statt
sizeof(struct simon_stat) = 16
sizeof(struct stat) = 49
fsize = 10566
$

Look at the differences in the sizes of the structs. I see 3 possibilities:

(a) I've made a mistake while altering the VMS C headers to be usable
with the Linux gcc cross compiler, but a review of my changes did not
see anything obvious in this area,

(b) There is some data type size difference between the compilers,

(c) gcc is not aligning the structure as requested (gcc has had support
for some DEC C pragmas added)

If I find this one I suspect there are going to be alignment problems
in other structs given the warnings I received while building binutils
using the cross compiler.

Been restricted to using the information about the VMS gcc port which
is publicly available, getting to the stage of actually been able to
run the binutils nm binary under VMS is a major step, but I suspect
there's a lot more work ahead before it (and the rest of binutils)
functions correctly on VMS when using gcc as the compiler.

I'm going to spend a bit more time on this (there's something else
I want to try), but I am coming to the end of my time on this.

> Do you know by chance how well Integrity is supported in binutils ?
>

I have no knowledge of IA64 support; it's listed as supported, but I don't
know how good that support is.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world