Trying to port libffi to OpenVMS.

Trying to port libffi to OpenVMS.

[John E. Malmberg]

Hello,

I am one of the current developers of the GNV and VMS-PORTS Sourceforge 
projects.  References below:

The build of cPython from the mercurial repository on VMS now 
effectively requires a port of libffi in order to complete.

I was able to apply Philippe Vouters patches for Libffi 3.0.9 to libffi 
3.1 and get the code building.  I was unable to get the tests to run 
under GNV though.

I am now trying to build master from a git checkout, and have gotten 
lost with the changes to src/alpha/ffi.c since then, so I am looking for 
some guidance on how to get libffi from master building.

I have been unable to locate the WIKI for libffi.  The link at github 
just gives a 404, not found.

On VMS, the compilers do not support the "asm" directive.

I have e-mailed Philippe, but so far I have not received a response from 
him.

Regards,
-John



References:

https://sourceforge.net/projects/gnv/
https://sourceforge.net/projects/vms-ports/

GNV is the GNU on VMS tool kit and tries to simulate a Linux build 
environment on VMS.

VMS-PORTS is for other programs ported to OpenVMS such as cPython 3.5a.

VMS has free hobby licenses for non-commercial hobby use, or free 
software developers Alliance One licenses for commercial software 
companies.  Free VAX and Alpha emulators are also available.

Re: Trying to port libffi to OpenVMS.

[Richard Henderson]

On 02/13/2015 06:00 AM, John E. Malmberg wrote:
> I was able to apply Philippe Vouters patches for Libffi 3.0.9 to libffi 3.1 and
> get the code building.  I was unable to get the tests to run under GNV though.

I've never seen those patches but...

> I am now trying to build master from a git checkout, and have gotten lost with
> the changes to src/alpha/ffi.c since then, so I am looking for some guidance on
> how to get libffi from master building.

... I know that the ABI for vms is significantly different from unix.
I'd be surprised if the patches were small.

> I have been unable to locate the WIKI for libffi.  The link at github just
> gives a 404, not found.

https://sourceware.org/libffi/

I don't know that there's a wiki, per se...


r~

Re: Trying to port libffi to OpenVMS.

[John E. Malmberg]

On 2/13/2015 8:41 AM, Richard Henderson wrote:
> On 02/13/2015 06:00 AM, John E. Malmberg wrote:
>> I was able to apply Philippe Vouters patches for Libffi 3.0.9 to libffi 3.1 and
>> get the code building.  I was unable to get the tests to run under GNV though.
>
> I've never seen those patches but...

Not sure if I got them via E-mail from someone else, or from his site. 
His site is not responding at this time.

The readme says that they include HP-UX/ia64 and VMS/Alpha and VMS/ia64. 
  What I have appears to be bunch of concatenated unified diffs.  I can 
gzip it and forward it to anyone that is interested, uncompressed it is 
126 KB.

>> I am now trying to build master from a git checkout, and have gotten lost with
>> the changes to src/alpha/ffi.c since then, so I am looking for some guidance on
>> how to get libffi from master building.
>
> ... I know that the ABI for vms is significantly different from unix.
> I'd be surprised if the patches were small.

I think VMS and Tru64 share a calling standard on Alpha, but I am not 
sure.  VMS on Itanium uses ELF binaries and calling standard with a few 
extensions to ELF.

In any case, on VMS, the "int lib$callg(void **args, int (*func)())" 
hides all that though.

> I don't know that there's a wiki, per se...

That is what the text at that web site says.  It actually implies that 
it is posted on a WIKI.

What I should have done is read the libffi online manual instead of 
trying just to understand what Philippe did.

The use of the lib$callg() routine means I should not need any assembly 
language code at all.  Probably almost the same source for all three 
current VMS harware platforms.

Thanks for the reply.

Regards,
-John

Re: Trying to port libffi to OpenVMS.

[Richard Henderson]

On 02/13/2015 03:48 PM, John E. Malmberg wrote:
> On 2/13/2015 8:41 AM, Richard Henderson wrote:
>> On 02/13/2015 06:00 AM, John E. Malmberg wrote:
>>> I was able to apply Philippe Vouters patches for Libffi 3.0.9 to libffi 3.1 and
>>> get the code building.  I was unable to get the tests to run under GNV though.
>>
>> I've never seen those patches but...
> 
> Not sure if I got them via E-mail from someone else, or from his site. His site
> is not responding at this time.
> 
> The readme says that they include HP-UX/ia64 and VMS/Alpha and VMS/ia64.  What
> I have appears to be bunch of concatenated unified diffs.  I can gzip it and
> forward it to anyone that is interested, uncompressed it is 126 KB.

Sure.

> I think VMS and Tru64 share a calling standard on Alpha, but I am not sure. 

Definitely not.

> VMS on Itanium uses ELF binaries and calling standard with a few extensions to
> ELF.

The calling standard is different enough that you'll definitely need changes to
the C code, and at least a small change to the assembly to set up the r25
"argument information" register.

> In any case, on VMS, the "int lib$callg(void **args, int (*func)())" hides all
> that though.

I'd be very surprised if this actually passes the testsuite, as you're not
giving lib$callg any information about the types of the arguments.

This is probably one of those things that worked find on VAX, but only works on
Alpha and IA-64 for integer arguments, and a limited number of them at that.

> The use of the lib$callg() routine means I should not need any assembly
> language code at all.  Probably almost the same source for all three current
> VMS harware platforms.

I'm sure you're going to have to write assembly, at least for Alpha.


r~

Re: Trying to port libffi to OpenVMS.

[John E. Malmberg]

On 2/16/2015 11:13 AM, Richard Henderson wrote:
> On 02/13/2015 03:48 PM, John E. Malmberg wrote:
>> On 2/13/2015 8:41 AM, Richard Henderson wrote:
>>> On 02/13/2015 06:00 AM, John E. Malmberg wrote:
>>>> I was able to apply Philippe Vouters patches for Libffi 3.0.9 to libffi 3.1 and
>>>> get the code building.  I was unable to get the tests to run under GNV though.
>>>
>>> I've never seen those patches but...
>>
>> Not sure if I got them via E-mail from someone else, or from his site. His site
>> is not responding at this time.
>>
>> The readme says that they include HP-UX/ia64 and VMS/Alpha and VMS/ia64.  What
>> I have appears to be bunch of concatenated unified diffs.  I can gzip it and
>> forward it to anyone that is interested, uncompressed it is 126 KB.
>
> Sure.

Forwarded via e-mail.

>> In any case, on VMS, the "int lib$callg(void **args, int (*func)())" hides all
>> that though.
>
> I'd be very surprised if this actually passes the testsuite, as you're not
> giving lib$callg any information about the types of the arguments.

I am a bit concerned about that, so am setting up some experiments.

I can not run the testsuite at this time.  The components for Deja-Gnu 
do not appear to have been ported to VMS.

> This is probably one of those things that worked find on VAX, but only works on
> Alpha and IA-64 for integer arguments, and a limited number of them at that.

The puts() example just worked.  Using the atof() call is not putting 
the correct values in the floating point return registers.  That is 
interesting because both are being passed a single string parameter.

I will try to get some more documentation on lib$callg.

>> The use of the lib$callg() routine means I should not need any assembly
>> language code at all.  Probably almost the same source for all three current
>> VMS harware platforms.
>
> I'm sure you're going to have to write assembly, at least for Alpha.

Quite possibly.  I think though that the entire assembly module may be 
better off being VMS specific instead of trying to use the osf modules 
as in the patch.

Regards,
-John

Re: Trying to port libffi to OpenVMS.

[John E. Malmberg]

On 2/16/2015 1:42 PM, John E. Malmberg wrote:
> On 2/16/2015 11:13 AM, Richard Henderson wrote:
>> On 02/13/2015 03:48 PM, John E. Malmberg wrote:
>>> On 2/13/2015 8:41 AM, Richard Henderson wrote:
>>>> On 02/13/2015 06:00 AM, John E. Malmberg wrote:
>
>>> In any case, on VMS, the "int lib$callg(void **args, int (*func)())"
>>> hides all that though.
>>
>> I'd be very surprised if this actually passes the testsuite, as you're
>> not giving lib$callg any information about the types of the arguments.
>
>> This is probably one of those things that worked find on VAX, but only
>> works on Alpha and IA-64 for integer arguments, and a limited number of
 >> them at that.

As stated before, that has turned out to be the case.  A more 
experienced Macro-64/VMS programmer on comp.os.vms has confirmed using 
lib$callg on other than VAX is a lost cause.

>> I'm sure you're going to have to write assembly, at least for Alpha.

It is starting to look like the best approach is to find out how to get 
the osf-1/alpha assembler to be conditionally compiled/assembled on VMS 
and the same for HP-UX/itanium as Philippe did.

I got the "master" ffi.c to build against Phillipe's macro code, but 
there still are significant differences between it and master.

The "puts" example worked though.

A test with "atof" did not work.  Unlike the lib$callg() case, once it 
the assembler called the routine, the correct result was in the F0 register.

The old code was expecting a different flag format, so did not translate 
the result back.

Regards,
-John